...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!
Showing posts with label security. Show all posts
Showing posts with label security. Show all posts
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!
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!
Friday, April 20, 2007
Universal Security Blunder?
There's been a spate of news concerning the threats posed by USB devices - including devices such as iPod, Zen etc. The main threat is that data could be very easily stolen using these seemingly harmless and innocuous devices.
Other threats may soon include viruses and trojans happily hopping from iPod to iPod, iPod to computer, and computer to computer.
When I say iPod I refer to the general class of such disk-based entertainment devices - sheer laziness and not any bias makes me refer to them so (I'm a huge fan of Apple's!).
A typical such device comes with a disk that's at least a few GBs, so it's not that difficult to steal large files using the USB ports.
Most companies permit employees to take their laptops with them - else what's the point of having one! The biggest problem is not that the laptop itself will go missing (which is an obvious threat) but that the data will be stolen (can't catch that unless you really audit the machine or install special tools to monitor data transfer). Now, with USB2.0 and FireWire, even GBs of data can be copied in minutes.
How do you protect against such an invisible, internal attack?
* Use software to lockdown the USB ports
* Educate employees on USB safety and security
* Order machines that have the ports disabled or not configured
* Glue them shut if all else fails
In any case, before we fall into this hysteria and become part of the USB-banning mob, we should give some thought to the level of crimes that occur using USB ports. How many people steal data using USB drives vs via hard copies of documents, CD-RW disks, email, illegal upload to online backup sites...the list is endless.
So, what do you learn from this? Definitely, USB ports are a threat, but maybe not to the extent that people make it out to be. At least not yet. Or maybe it already is, and we just haven't realized it yet.
Be safe!
Other threats may soon include viruses and trojans happily hopping from iPod to iPod, iPod to computer, and computer to computer.
When I say iPod I refer to the general class of such disk-based entertainment devices - sheer laziness and not any bias makes me refer to them so (I'm a huge fan of Apple's!).
A typical such device comes with a disk that's at least a few GBs, so it's not that difficult to steal large files using the USB ports.
Most companies permit employees to take their laptops with them - else what's the point of having one! The biggest problem is not that the laptop itself will go missing (which is an obvious threat) but that the data will be stolen (can't catch that unless you really audit the machine or install special tools to monitor data transfer). Now, with USB2.0 and FireWire, even GBs of data can be copied in minutes.
How do you protect against such an invisible, internal attack?
* Use software to lockdown the USB ports
* Educate employees on USB safety and security
* Order machines that have the ports disabled or not configured
* Glue them shut if all else fails
In any case, before we fall into this hysteria and become part of the USB-banning mob, we should give some thought to the level of crimes that occur using USB ports. How many people steal data using USB drives vs via hard copies of documents, CD-RW disks, email, illegal upload to online backup sites...the list is endless.
So, what do you learn from this? Definitely, USB ports are a threat, but maybe not to the extent that people make it out to be. At least not yet. Or maybe it already is, and we just haven't realized it yet.
Be safe!
Monday, March 12, 2007
Seagate Ships Secure Disk Drives
http://www.pcworld.com/article/id,129734-c,harddrives/article.html
http://news.zdnet.com/2100-1009_22-6130824.html?tag=nl
http://news.zdnet.com/2100-1009_22-6166180.html
Apparently the system has a vulnerability - it's only "ON" when the machine is fully switched OFF. Meaning, if you have authenticated yourself to the system successfully, the data is open and available, much like a regular PC. The real value comes in, ironically and unfortunately and maybe expectedly, only when the machine gets stolen or someone makes off with the disk. If you forget the password - tough luck - Seagate will only "reset" the drive but the data is as good as lost.
You boot up the machine and it asks for a password. Further to that, the encryption keys (the algorithm being AES-128 - VERY strong) can be managed by third-party software - such as Wave Systems. Not sure where the keys live though, although unquestionably they'll be in an encrypted state. They also state that the data will be in encrypted condition until/unless requested by an application.
Overall, a very sound idea and I am sure a very neat product, but definitely some improvements should be forthcoming. As they say, a system is only as secure as its password. Choose a horrible password like, HEAVENS!, "password" and neither Seagate nor AES can save you :-) Of course, having two-factor authentication should help TREMENDOUSLY.
Two-factor authentication: Any two of "What you know (password, PIN etc)" "What you have (token, temporary authentication code)" "What you are (biometric, usually, such as iris, fingerprint)"
AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
http://news.zdnet.com/2100-1009_22-6130824.html?tag=nl
http://news.zdnet.com/2100-1009_22-6166180.html
Apparently the system has a vulnerability - it's only "ON" when the machine is fully switched OFF. Meaning, if you have authenticated yourself to the system successfully, the data is open and available, much like a regular PC. The real value comes in, ironically and unfortunately and maybe expectedly, only when the machine gets stolen or someone makes off with the disk. If you forget the password - tough luck - Seagate will only "reset" the drive but the data is as good as lost.
You boot up the machine and it asks for a password. Further to that, the encryption keys (the algorithm being AES-128 - VERY strong) can be managed by third-party software - such as Wave Systems. Not sure where the keys live though, although unquestionably they'll be in an encrypted state. They also state that the data will be in encrypted condition until/unless requested by an application.
Overall, a very sound idea and I am sure a very neat product, but definitely some improvements should be forthcoming. As they say, a system is only as secure as its password. Choose a horrible password like, HEAVENS!, "password" and neither Seagate nor AES can save you :-) Of course, having two-factor authentication should help TREMENDOUSLY.
Two-factor authentication: Any two of "What you know (password, PIN etc)" "What you have (token, temporary authentication code)" "What you are (biometric, usually, such as iris, fingerprint)"
AES: http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
Subscribe to:
Posts (Atom)
