...or the lack of it, really, at least according to a GAO report that was on the news a couple of days ago.
Problems included lack of encryption (for sensitive data), improper or missing authentication and authorization of users before they accessed sensitive information, and improper or default configuration of network devices.
Usually, network devices come with a default password that's a pain to change because each piece of hardware has a different management interface. Let's say you have five network devices - two switches (from different vendors), a router, a bridge, and a gateway.
Each device will have a unique website, a different way to set passwords, and a different way they can be accessed. The point is that a lack of common management interface leads to some very lazy administrators.
Here's my recommendation:
All you network hardware vendors -- can't you work together to create A SINGLE interface that could be used to work with the multitude of devices!?
It'd make life a million times easier for everyone, and make the environment a lot safer. I'm not about to go into the details of what such an interface should have, and would entail, but maybe later.
For now, this is what the FBI should do:
a. Follow a proper process that would track every piece of hardware from cradle to grave
b. Make people responsible and accountable for changing passwords every 2 months (or as often as needed per the security policy)
c. Make sure the results of the password change are updated in a document that lists those devices that could not be modified (maybe they're getting serviced, or were down for some reason), and get to them ASAP
d. Provide a checklist to any manager that has people reporting to him, on whether his employees (and he himself) actually needs access to any sensitive data. Be harsh and do not be afraid of treading on egos - do what is important and necessary to keep the country safe. People who mind on the basis of ego are eminently dispensable, and could prove dangerous in their efforts to satisfy their power-hungry needs
e. Every vendor that supplies to the FBI MUST supply a password that is tough to crack (the default password should satisfy existing requirements) - maybe not ALL criteria should be revealed to the vendor, but a few, such as the length, inclusion of special characters, etc should be mandatory
f. Use a password management software to make sure these devices are in compliance at all times (as opposed to 'b') if resistance from people is high
g. All changes should go through Change Management control and sign-off must be received from the proper authorities before changes are implemented
h. Audit the entire organization every 6 months - this may seem too frequent, but it's completely worth the time and effort. After the first 3-4 audits, the time and effort required for each subsequent audit should reduce as long as compliance rules are being properly followed
i. DO NOT make exceptions at any stage - as the cliche goes: a chain is only as strong as its weakest link
j. The default access for any device in its original, default configuration should be DENY_ALL, and then it can be configured to selectively permit traffic and users
k. Use RBACs and ACLs to control, limit, and deny access
l. Use strong and detailed logging at all levels. Storage is cheap - lives are not
Be safe!
Monday, May 28, 2007
Thursday, May 24, 2007
Database Security
http://searchsecurity.techtarget.com/originalContent/0,289142,sid14_gci1255955,00.html
Quite an interesting article, and it talks about concepts that are very logical, obvious, and yet something that's hard to implement and track.
How so?
Let's say you're the CISO of a company/govt organization that has access to highly sensitive data such as taxes, divorce records, alimony and so on. What would be your first instinct relating to protecting the data? Encryption, RBAC, ACL...?
There are many choices and each comes with its own tradeoffs. 'Mindboggling' is a mild word for the conundrum you just got yourself into.
Believe it or not, people actually abuse power! Hmmm didn't know that one, did you?
Now that you do, start with the basics. Make a list of talented people who can handle the responsibilities that will be given to them. They should be held strictly accountable at all times when it comes to the ownership and privacy of the information entrusted in their hands.
Then define roles and responsibilities that will match those tasks. With the help of commercially available software, you can do that very quickly.
For especially sensitive data, institute authentication codes. Meaning, access to certain types of data should only be possible with the help of a code that's generated by a security officer who oversees the overall security aspects of the data.
Thus, you now have division of roles and a division of how the responsibilities are executed. How does this help? Two words - collusion avoidance (and detection).
Next, logging and audit control.
Make sure the software that you use can log certain types of searches and classify them as inappropriate when applicable. It should alert the manager or supervisor within a time defined by an SLA. This kind of alert is preferred to be real-time so any violation can be stopped immediately.
Audits should be performed on a regular basis, and at least 3 times a year on a surprise! basis. That will keep any potentially devious employees somewhat honest and probably catch those that have crossed the line before they could do more damage.
Rewards - any quarter/6 months/year when there have been no violations, every employee in the security team should be congratulated and rewarded for saving the CISO's reputation and bonus.
Continuous improvement -- this phrase is used so much it's almost near meaningless, but because it's almost meaningless, if I use it just once or twice it won't hurt.
But let me define it slightly differently -- CI means new ways of figuring out how to keep secure data secure (think new hacking methods, new forms of spyware/malware/adware/badware, spam, viruses, trojans - boy you have your hands full). How to keep employees from stealing data or misusing their newfound power. How to maintain the integrity of the system and its value.
How to have business running 24/7 with no bottlenecks from the DB department. How to maintain the system's authority as the final arbiter of the correctness of data that resides within.
Needless to say most of these have strong security angles, but the top rank goes to getting employees to keep the data secure and keeping themselves honest. Very honest.
Remember: Encrypted databases and password-protected sites are powerless to stop an employee with the proper key and password, but relevant training dealing in ethics and company policies pertaining to correct use and access of records, coupled with rewards for excellent and spotless conduct, should go a long way. Combined necessarily and mandatorily with the latest technology to keep data visible to only those that need to see it, this approach should be quite foolproof.
It's quite difficult, if not downright impossible, to expect 100% adherence to policy (otherwise we wouldn't have any scandals). So, the next best step to remedy and fix a potentially devastating violation in the future is to ENCOURAGE and REWARD good habits than simply discourage and penalize bad ones. This is not to say that the bad eggs should not be disciplined/terminated/penalized, but that good behavior should be recognized and made worthwhile.
Be safe!
Quite an interesting article, and it talks about concepts that are very logical, obvious, and yet something that's hard to implement and track.
How so?
Let's say you're the CISO of a company/govt organization that has access to highly sensitive data such as taxes, divorce records, alimony and so on. What would be your first instinct relating to protecting the data? Encryption, RBAC, ACL...?
There are many choices and each comes with its own tradeoffs. 'Mindboggling' is a mild word for the conundrum you just got yourself into.
Believe it or not, people actually abuse power! Hmmm didn't know that one, did you?
Now that you do, start with the basics. Make a list of talented people who can handle the responsibilities that will be given to them. They should be held strictly accountable at all times when it comes to the ownership and privacy of the information entrusted in their hands.
Then define roles and responsibilities that will match those tasks. With the help of commercially available software, you can do that very quickly.
For especially sensitive data, institute authentication codes. Meaning, access to certain types of data should only be possible with the help of a code that's generated by a security officer who oversees the overall security aspects of the data.
Thus, you now have division of roles and a division of how the responsibilities are executed. How does this help? Two words - collusion avoidance (and detection).
Next, logging and audit control.
Make sure the software that you use can log certain types of searches and classify them as inappropriate when applicable. It should alert the manager or supervisor within a time defined by an SLA. This kind of alert is preferred to be real-time so any violation can be stopped immediately.
Audits should be performed on a regular basis, and at least 3 times a year on a surprise! basis. That will keep any potentially devious employees somewhat honest and probably catch those that have crossed the line before they could do more damage.
Rewards - any quarter/6 months/year when there have been no violations, every employee in the security team should be congratulated and rewarded for saving the CISO's reputation and bonus.
Continuous improvement -- this phrase is used so much it's almost near meaningless, but because it's almost meaningless, if I use it just once or twice it won't hurt.
But let me define it slightly differently -- CI means new ways of figuring out how to keep secure data secure (think new hacking methods, new forms of spyware/malware/adware/badware, spam, viruses, trojans - boy you have your hands full). How to keep employees from stealing data or misusing their newfound power. How to maintain the integrity of the system and its value.
How to have business running 24/7 with no bottlenecks from the DB department. How to maintain the system's authority as the final arbiter of the correctness of data that resides within.
Needless to say most of these have strong security angles, but the top rank goes to getting employees to keep the data secure and keeping themselves honest. Very honest.
Remember: Encrypted databases and password-protected sites are powerless to stop an employee with the proper key and password, but relevant training dealing in ethics and company policies pertaining to correct use and access of records, coupled with rewards for excellent and spotless conduct, should go a long way. Combined necessarily and mandatorily with the latest technology to keep data visible to only those that need to see it, this approach should be quite foolproof.
It's quite difficult, if not downright impossible, to expect 100% adherence to policy (otherwise we wouldn't have any scandals). So, the next best step to remedy and fix a potentially devastating violation in the future is to ENCOURAGE and REWARD good habits than simply discourage and penalize bad ones. This is not to say that the bad eggs should not be disciplined/terminated/penalized, but that good behavior should be recognized and made worthwhile.
Be safe!
Thursday, May 17, 2007
On PCI-DSS
Every time you hear another breach of security at a retailer site you cringe. You cringe but carry on because you know it happens all the time, or that it's become too common.
I've blogged on this particular problem before, but it's quite simple to understand that standards really are not of much help unless supplemented with a lot education and awareness. I throw around these two words quite a bit - they MATTER! Educate your IT staff on proper security etiquette and you'll save yourself a whole lot of heartburn later.
Remember, 99% of such problems occur because of human error. Computer faults are also usually caused by humans, so don't go around blaming a defenceless piece of hardware or software.
How, you ask?
1. Non-secure code/programs/applications (easily subject to buffer overflow or crash, not enough checks, not enough or no authentication needed to run them and so on)
2. Misconfiguration of the application/site, including firewalls and authentication schemes
3. Poor or no training of the staff that's supposed to manage the data
4. Lack of encryption/plaintext files
Of course, the above constitutes just a very short list of possible sources of breaches, but they're probably the most common.
In any case, I looked at the 12 requirements of the PCI-DSS compliance, and I find they are too generic and lay out a framework rather than concrete instructions. I know and understand how complex the whole thing is, but it'd be good if the PCI could provide merchants with more detailed knowledge of what to do and how to go about doing it.
For all I know this must be happening (I know nothing about how these guys work behind the scenes), but from what the CISO of FirstData said, it looks like they really need some handholding or at least more clarification.
Be safe!
I've blogged on this particular problem before, but it's quite simple to understand that standards really are not of much help unless supplemented with a lot education and awareness. I throw around these two words quite a bit - they MATTER! Educate your IT staff on proper security etiquette and you'll save yourself a whole lot of heartburn later.
Remember, 99% of such problems occur because of human error. Computer faults are also usually caused by humans, so don't go around blaming a defenceless piece of hardware or software.
How, you ask?
1. Non-secure code/programs/applications (easily subject to buffer overflow or crash, not enough checks, not enough or no authentication needed to run them and so on)
2. Misconfiguration of the application/site, including firewalls and authentication schemes
3. Poor or no training of the staff that's supposed to manage the data
4. Lack of encryption/plaintext files
Of course, the above constitutes just a very short list of possible sources of breaches, but they're probably the most common.
In any case, I looked at the 12 requirements of the PCI-DSS compliance, and I find they are too generic and lay out a framework rather than concrete instructions. I know and understand how complex the whole thing is, but it'd be good if the PCI could provide merchants with more detailed knowledge of what to do and how to go about doing it.
For all I know this must be happening (I know nothing about how these guys work behind the scenes), but from what the CISO of FirstData said, it looks like they really need some handholding or at least more clarification.
Be safe!
Wednesday, May 16, 2007
Not Again! Yes, Again
http://www.networkworld.com/news/2007/051507-ibm-contractor-loses-employee.html
The link tells the story. Again. Someone. Lost. Critical. Data.
This time the information was unencrypted on some tapes - which makes retrieval a snap for those with the right tools. I think the govt should really step in immediately and pass legislation that would make encryption of all employee-related data mandatory, especially if such data were being physically transported.
I'm going to stop here.
Be safe!
The link tells the story. Again. Someone. Lost. Critical. Data.
This time the information was unencrypted on some tapes - which makes retrieval a snap for those with the right tools. I think the govt should really step in immediately and pass legislation that would make encryption of all employee-related data mandatory, especially if such data were being physically transported.
I'm going to stop here.
Be safe!
Tuesday, May 8, 2007
TSA's Misstep
http://www.technewsworld.com/story/57281.html
So what's new, right?! This expression is becoming very common nowadays, from completely unforgivable sins such as not securing hardware to exposing sensitive data to the general public on an uncontrolled/unmoderated website (the Agriculture department comes to mind).
Let's analyze for a second how such a mishap could occur. Places such as the Los Alamos lab - famous for disappearing drives and dead-end investigations, don't seem to have a clue as to what to do and look for when a critical piece of hardware goes poof!
Lifecycle of a disk (bought separately, and assuming formal processes exist):
a. Requisition for purchase
b. Approval
c. Order
d. Delivery
e. Verification
f. Change Management process approval
g. Implementation/installation
h. Usage
i. Fault - Return to sender
j. EoL
Worker W requests Manager M for extra space and submits requisition, M approves it and sends it to Purchasing for placing the order.
Disk comes through, is verified by the appropriate personnel, and the CM team authorizes the installation of the disk (might involve downtime, reboot etc).
IT installs the disk and brings it online so users can store twenty-thousand copies of the same document so they run out of space way before the projected date and then place more orders.
Say an error crops up on this new disk, which by now has a lot of data, IT will be asked to look into it. IT will try to backup the data to another disk and try to fix it. In the meantime, since most workers have filled up this new backup disk and don't have any problems with it, they're likely to push for IT to delay installing the new disk, which has been fixed by now.
So, IT just waits around, and eventually something happens that causes them to lose track of it. This 'something' is the most dangerous aspect of IT and security because nobody knows what it is (and that's why it's called 'something'). It could be an employee with malicious intent to an ID thief to an innocent misplacing to out and out loss of the disk beyond recovery. This becomes much more of an issue if the disk is to be shipped elsewhere (ironically, for safekeeping or backup) and nobody really knows whether the destination received it, or whether they got the right material, or whether the disk was even sent!
Anyway, all through the steps above, there is no TRACKING of the material. If there were a CMDB in place, then much of this could have been part of its DB and then could be made a traceable and trackale entity.
Then, when a disk went missing, all one would have to do is search for the part number/brand/custom id/tracking number/dept id/destination -- you get the idea -- and take further action. The point is that not much is unknown at that time. Auditing, which should come in between 'h' and 'i' is the one process that people love to hate, but one which may save their (and our) lives one day. As long as regular auditing is done using the CMDB as an authoritative source of existing inventory, one can be assured that such 'issues' won't be so common as one's less likely to be lackadaisical when an audit is due.
Since most people don't even know what a CMDB is, it's going to be hard to convince them or educate them on the importance of such a database. The root problem thus lies in education and awareness. Get familiar with ITIL!
Security is all about education, training, and awareness. As Fox Mulder put it, TRUST NO ONE. This doesn't mean you incur the wrath of your boss for asking him 20 questions on why he wants to see your code, but that anyone that's not in your immediate circle of trust (something like PKI) should not be privy to your sensitive data. The idea is Need to Know comes before everything else.
Coming back to this intriguing case of the missing disk, here's how I'd do it (all of these trackable details such as tracking number etc would go into the CMDB):
a. Requisition generated by user (tracking number (tn) 1234)
b. Approval by manager (tn, approval id (aid) A45)
c. Order (tn, aid, order number (on) O858)
d. Delivery (tn, aid, on, delivery date (dd) 05/08/2007, shipper id (sid), dept id (did))
e. Verification (tn, aid, on, dd, sid, deptid, verification id (vid))
f. CM approval (tn, aid, on, dd, sid, deptid, vid, chg mgr approval id (cmid))
g. Ticket to install/installation (tn, aid, on, dd, sid, deptid, vid, cmid, iticket)
h. Usage
i. Fault (tn, aid, on, dd, sid, deptid, vid, cmid, fticket)
j. Shipping (tn, aid, on, dd, sid, deptid, vid, cmid, fticket(if fault), rticket (if request to ship), sid, sender deptid, receiver deptid, slaid (service level agreement id))
k. EoL
As you can see, everything here can be traced to the finest level - nothing can escape scrutiny, and accountability is preserved.
As for data structure, when I say verification id, the id should point to a table that contains at least the original requisition id, the id of the person performing the verification, the outcome, destination dept, contact who will pick up the disk, and anything else that may matter).
I realize it sounds like overkill, but try facing 10,000 workers after 'losing' their most precious and sensitive information. Their stares alone will jolt you into becoming an evangelist for data safety, if the govt/sanctions/bad reputation don't get there first.
Be safe!
So what's new, right?! This expression is becoming very common nowadays, from completely unforgivable sins such as not securing hardware to exposing sensitive data to the general public on an uncontrolled/unmoderated website (the Agriculture department comes to mind).
Let's analyze for a second how such a mishap could occur. Places such as the Los Alamos lab - famous for disappearing drives and dead-end investigations, don't seem to have a clue as to what to do and look for when a critical piece of hardware goes poof!
Lifecycle of a disk (bought separately, and assuming formal processes exist):
a. Requisition for purchase
b. Approval
c. Order
d. Delivery
e. Verification
f. Change Management process approval
g. Implementation/installation
h. Usage
i. Fault - Return to sender
j. EoL
Worker W requests Manager M for extra space and submits requisition, M approves it and sends it to Purchasing for placing the order.
Disk comes through, is verified by the appropriate personnel, and the CM team authorizes the installation of the disk (might involve downtime, reboot etc).
IT installs the disk and brings it online so users can store twenty-thousand copies of the same document so they run out of space way before the projected date and then place more orders.
Say an error crops up on this new disk, which by now has a lot of data, IT will be asked to look into it. IT will try to backup the data to another disk and try to fix it. In the meantime, since most workers have filled up this new backup disk and don't have any problems with it, they're likely to push for IT to delay installing the new disk, which has been fixed by now.
So, IT just waits around, and eventually something happens that causes them to lose track of it. This 'something' is the most dangerous aspect of IT and security because nobody knows what it is (and that's why it's called 'something'). It could be an employee with malicious intent to an ID thief to an innocent misplacing to out and out loss of the disk beyond recovery. This becomes much more of an issue if the disk is to be shipped elsewhere (ironically, for safekeeping or backup) and nobody really knows whether the destination received it, or whether they got the right material, or whether the disk was even sent!
Anyway, all through the steps above, there is no TRACKING of the material. If there were a CMDB in place, then much of this could have been part of its DB and then could be made a traceable and trackale entity.
Then, when a disk went missing, all one would have to do is search for the part number/brand/custom id/tracking number/dept id/destination -- you get the idea -- and take further action. The point is that not much is unknown at that time. Auditing, which should come in between 'h' and 'i' is the one process that people love to hate, but one which may save their (and our) lives one day. As long as regular auditing is done using the CMDB as an authoritative source of existing inventory, one can be assured that such 'issues' won't be so common as one's less likely to be lackadaisical when an audit is due.
Since most people don't even know what a CMDB is, it's going to be hard to convince them or educate them on the importance of such a database. The root problem thus lies in education and awareness. Get familiar with ITIL!
Security is all about education, training, and awareness. As Fox Mulder put it, TRUST NO ONE. This doesn't mean you incur the wrath of your boss for asking him 20 questions on why he wants to see your code, but that anyone that's not in your immediate circle of trust (something like PKI) should not be privy to your sensitive data. The idea is Need to Know comes before everything else.
Coming back to this intriguing case of the missing disk, here's how I'd do it (all of these trackable details such as tracking number etc would go into the CMDB):
a. Requisition generated by user (tracking number (tn) 1234)
b. Approval by manager (tn, approval id (aid) A45)
c. Order (tn, aid, order number (on) O858)
d. Delivery (tn, aid, on, delivery date (dd) 05/08/2007, shipper id (sid), dept id (did))
e. Verification (tn, aid, on, dd, sid, deptid, verification id (vid))
f. CM approval (tn, aid, on, dd, sid, deptid, vid, chg mgr approval id (cmid))
g. Ticket to install/installation (tn, aid, on, dd, sid, deptid, vid, cmid, iticket)
h. Usage
i. Fault (tn, aid, on, dd, sid, deptid, vid, cmid, fticket)
j. Shipping (tn, aid, on, dd, sid, deptid, vid, cmid, fticket(if fault), rticket (if request to ship), sid, sender deptid, receiver deptid, slaid (service level agreement id))
k. EoL
As you can see, everything here can be traced to the finest level - nothing can escape scrutiny, and accountability is preserved.
As for data structure, when I say verification id, the id should point to a table that contains at least the original requisition id, the id of the person performing the verification, the outcome, destination dept, contact who will pick up the disk, and anything else that may matter).
I realize it sounds like overkill, but try facing 10,000 workers after 'losing' their most precious and sensitive information. Their stares alone will jolt you into becoming an evangelist for data safety, if the govt/sanctions/bad reputation don't get there first.
Be safe!
Thursday, May 3, 2007
VeriSign's Passcode Initiative
http://www.itwire.com.au/content/view/11775/53/
VeriSign now offers a special card that generates a one-time passcode that expires quickly, so even if someone were to steal it, it wouldn't be of much use.
The passcode is displayed on the card itself, at the push of a button. Expected to last two years or around 100000 uses, it's a nice, elegant, and compact solution.
I know you're waiting for the key word - HOWEVER - it's easily subject to the infamous MitM attack (Man in the Middle). See, after all, the passcode is just another bit of data that can be stolen along with user name and password. Nothing really more to it, in my opinion, than hype.
Although two-factor authentication schemes are very strong and should be recommended for most security applications (who you are, what you have, what you know are the three principal factors), there are severe limitations that need to be considered as well.
A nearly foolproof method would be the use of biometric systems - the iris check, fingerprints, voiceprints, facial recognition, and so on, are somewhat advanced and used in most high-security areas. The trick is to incorporate them into devices that we need access to at higher levels of security, such as ATM machines, bank lockers, safes etc.
In any case, VeriSign is doing the right thing by at least starting the process somewhere. I know Discover Card used to have a little application that one could download to one's desktop, and it'd do the same thing. Not sure what happened to it.
Also, many MasterCard and Visa issuers are also using the two-factor method to prevent phishing. For example, one site lets you pick a picture, and it'll show it to you when you enter just your username, and if you don't recognize it you simply don't supply the password. If the picture is something that you know you picked then you enter the password. How secure is this? Quite, but not foolproof. A hacker could try and randomly generate the pictures from actually using the site as a regular user and looking at the pictures, and if it matches - whoa!
A better idea would be to let the user pick their own pictures - something personal, say their dog or their home or their messy office desk or something that's not easy to duplicate.
In summary, while it's a good start, it's only a start. I look forward to seeing more biometric authentication schemes available to the general public and not just to the privileged. We pay the bills, after all!
Be safe!
VeriSign now offers a special card that generates a one-time passcode that expires quickly, so even if someone were to steal it, it wouldn't be of much use.
The passcode is displayed on the card itself, at the push of a button. Expected to last two years or around 100000 uses, it's a nice, elegant, and compact solution.
I know you're waiting for the key word - HOWEVER - it's easily subject to the infamous MitM attack (Man in the Middle). See, after all, the passcode is just another bit of data that can be stolen along with user name and password. Nothing really more to it, in my opinion, than hype.
Although two-factor authentication schemes are very strong and should be recommended for most security applications (who you are, what you have, what you know are the three principal factors), there are severe limitations that need to be considered as well.
A nearly foolproof method would be the use of biometric systems - the iris check, fingerprints, voiceprints, facial recognition, and so on, are somewhat advanced and used in most high-security areas. The trick is to incorporate them into devices that we need access to at higher levels of security, such as ATM machines, bank lockers, safes etc.
In any case, VeriSign is doing the right thing by at least starting the process somewhere. I know Discover Card used to have a little application that one could download to one's desktop, and it'd do the same thing. Not sure what happened to it.
Also, many MasterCard and Visa issuers are also using the two-factor method to prevent phishing. For example, one site lets you pick a picture, and it'll show it to you when you enter just your username, and if you don't recognize it you simply don't supply the password. If the picture is something that you know you picked then you enter the password. How secure is this? Quite, but not foolproof. A hacker could try and randomly generate the pictures from actually using the site as a regular user and looking at the pictures, and if it matches - whoa!
A better idea would be to let the user pick their own pictures - something personal, say their dog or their home or their messy office desk or something that's not easy to duplicate.
In summary, while it's a good start, it's only a start. I look forward to seeing more biometric authentication schemes available to the general public and not just to the privileged. We pay the bills, after all!
Be safe!
Subscribe to:
Posts (Atom)
