http://www.informationweek.com/news/showArticle.jhtml?articleID=199905838&pgno=2&queryText=
As I've mentioned many times before, computer security is taken too lightly by too many people. I hope the CIO of DHS doesn't think that way.
First off, we need a CISO *and* a CIO for an organization as complex and as bureaucratic as the DHS. The CIO and CISO should get together to formulate a strategy that will feed the needs of the IT dept (CIO) and balance it or temper it with the security ramifications that come with the needs (CIOSO).
My worry is that while Congress battles the powerful bureaucrats and while the bureaucrats expend energy in defending themselves, the door is left wide open for everyone to do what they want to do. In other words, the utter indifference to real security is what results in trojans, viruses, inappropriate and objectionable content invading the computers.
Another concern is that the computers are allowed to access the Internet! First off, you want to very severely restrict access to the 'Net, and if you must, make sure you have powerful tools to control both access as well as downloads.
Here's what a basic, 20-point policy would look like (for user-terminals/computers at least):
1. Disable floppy drives (or buy computers without them)
2. Disable CD drive (need special code to unlock and use - content to be disclosed first)
3. Disable USB drives
4. Disable any and all controls on the OS that will permit configuration changes (such as IE security level etc)
5. Disable all downloads from the 'Net (incl HTTP/FTP)
6. Disable all uploads to ANY location
7. Internal data transfer should happen through pre-mapped, controlled, and constantly-monitored, network drives - probabaly a departmentalized storage subsystem such as NetApp Filers or EMC CLARiiON etc
8. Use encryption as much as possible, both on disk as well as on the network
9. Use forced authentication at every entry point (no trusted hosts nonsense)
10. Disable installation of any kind of unauthorized programs
11. Use at least 2-factor authentication (password + random key as an example)
12. Go for biometric authentication whenever and wherever possible
13. Use AV software extensively, ensuring prompt and forced updates and reboots as needed
14. Use IDS (pref IPS also) software at every sensitive node
15. Control, monitor, and record ALL communication - IM, email, phone etc
16. Email clients should be tuned to only send mail to internal personnel - no external addresses should be allowed - EVER
17. Scan ALL incoming packets - and outgoing packets at sensitive nodes
18. NO ATTACHMENTS ALLOWED ANYTIME - email/IM - whatever mode of communication
19. Use hardware encryption devices and encrypt all data, everywhere. Use PKI devices to manage the keys
20. Finally, EDUCATE THE EMPLOYEES. Nothing works better than education
Watch this space for more ideas that DHS will probably never implement! Next I'll be focusing on actual employee monitoring details.
Be safe!
Friday, June 22, 2007
Tuesday, June 19, 2007
Security Companies Getting Bought Out...
http://creativemac.digitalmedianet.com/articles/viewarticle.jsp?id=153590
I think the recent buying binge demands at least some investigation into:
a. Exactly what these companies market
b. What does the software actually do
c. Is it ready to deal with, or can it be extended to deal with, latest threats
d. How easy is it to integrate with current solutions
e. Are these FIPS-compliant
In any case, it does look like the Security market is golden, and doing fantastically well. If you want to make a few million dollars, start with an idea, write up rudimentary software, say it patches up this threat and that vulnerability while scanning the network and making your morning coffee, and BOOM! your company's set for sale!
Seriously though, the real value of these acquisitions will come from how easily and painlessly the products integrate into current product offerings. HP just bought SPID, and if that could be merged into any of HP's products (logically so) then customers have one less thing to deploy, manage, patch, and keep inventory.
Overall, definitely a solid consolidation in the SS market is going on, and is long overdue, too, but quite importantly we should note WHO'S buying - that will indicate a stronger trend toward tighter bonding between existing enterprise management/monitoring tools and actual Security tools.
Now you could predict that IBM will have a significant share of Security-based revenues from its purchase of ISS, that EMC will carve out a bigger and bigger share of the market using RSA, that BT will reap the fruits of its bagging of CounterPane.
This is just the beginning of the trend - quite possibly we'll see the same and new software vendors buying more and more of such companies. Ultimately, one'd be hard-pressed to find a single Security ISV.
Hot areas will include:
a. Identity management
b. Patch management
c. Vulnerability assessment and management
d. Threat assessment (from internal and external sources based on patterns and trends)
e. Code and system-hardening
f. Security services and consulting operations
g. Compliance and regulatory assessment, management, consulting and validation
h. Outsourcing of Security tasks
and so on
Be safe!
I think the recent buying binge demands at least some investigation into:
a. Exactly what these companies market
b. What does the software actually do
c. Is it ready to deal with, or can it be extended to deal with, latest threats
d. How easy is it to integrate with current solutions
e. Are these FIPS-compliant
In any case, it does look like the Security market is golden, and doing fantastically well. If you want to make a few million dollars, start with an idea, write up rudimentary software, say it patches up this threat and that vulnerability while scanning the network and making your morning coffee, and BOOM! your company's set for sale!
Seriously though, the real value of these acquisitions will come from how easily and painlessly the products integrate into current product offerings. HP just bought SPID, and if that could be merged into any of HP's products (logically so) then customers have one less thing to deploy, manage, patch, and keep inventory.
Overall, definitely a solid consolidation in the SS market is going on, and is long overdue, too, but quite importantly we should note WHO'S buying - that will indicate a stronger trend toward tighter bonding between existing enterprise management/monitoring tools and actual Security tools.
Now you could predict that IBM will have a significant share of Security-based revenues from its purchase of ISS, that EMC will carve out a bigger and bigger share of the market using RSA, that BT will reap the fruits of its bagging of CounterPane.
This is just the beginning of the trend - quite possibly we'll see the same and new software vendors buying more and more of such companies. Ultimately, one'd be hard-pressed to find a single Security ISV.
Hot areas will include:
a. Identity management
b. Patch management
c. Vulnerability assessment and management
d. Threat assessment (from internal and external sources based on patterns and trends)
e. Code and system-hardening
f. Security services and consulting operations
g. Compliance and regulatory assessment, management, consulting and validation
h. Outsourcing of Security tasks
and so on
Be safe!
Tuesday, June 12, 2007
Privacy Concerns and Google
Quite interesting, the recent concerns over how Google mines data and how it might use it when combined with its recent acquisition, DoubleClick. Plus, now you have street-level, 360-degree, detailed snapshot views of actual happenings on streets that Google has covered.
Somewhat creepy, a little scary, but mostly harmless. For now.
How Google addresses privacy concerns raised by both small privacy groups and organizations like ACLU, EPIC etc is to be seen, but it's quite likely that G, whose main edict is 'Don't be evil' may be forced more and more to live up to its grand statements. Only, you don't want it going the way of 'We don't do finance'...
What is the Security concern here? Plenty, plenty, plenty. Imagine this fantastic goldmine of data that tells you all you want to know about someone's secrets and the makeup of their psyche - right from search terms to visited sites to how long they surfed those sites to your most private communication (email). Imagine this fantastic data in the hands of a hacker. There. You know what I'm saying.
So, G, which employs the most brilliant minds it can afford to buy on the strength of its balance sheet as well as brand name, needs to REALLY tighten up its environment. You do NOT want embarrassments like when someone stole G's own blog and it had to do some red-faced explaining. We don't have to teach G about security and how to protect its data, but we do have a RIGHT to expect that what G knows, only G knows and nobody else. Plus, you also hope (wish, pray, beseech, request, beg, fight) that G also has a bad memory (think data retention policies).
Anyway, the coming few months are going to be very intense as the search, advertising, and portal markets heat up with existing giants waking up and new, disruptive technologies start chipping away at the heels of the Big Ones.
Be safe!
Somewhat creepy, a little scary, but mostly harmless. For now.
How Google addresses privacy concerns raised by both small privacy groups and organizations like ACLU, EPIC etc is to be seen, but it's quite likely that G, whose main edict is 'Don't be evil' may be forced more and more to live up to its grand statements. Only, you don't want it going the way of 'We don't do finance'...
What is the Security concern here? Plenty, plenty, plenty. Imagine this fantastic goldmine of data that tells you all you want to know about someone's secrets and the makeup of their psyche - right from search terms to visited sites to how long they surfed those sites to your most private communication (email). Imagine this fantastic data in the hands of a hacker. There. You know what I'm saying.
So, G, which employs the most brilliant minds it can afford to buy on the strength of its balance sheet as well as brand name, needs to REALLY tighten up its environment. You do NOT want embarrassments like when someone stole G's own blog and it had to do some red-faced explaining. We don't have to teach G about security and how to protect its data, but we do have a RIGHT to expect that what G knows, only G knows and nobody else. Plus, you also hope (wish, pray, beseech, request, beg, fight) that G also has a bad memory (think data retention policies).
Anyway, the coming few months are going to be very intense as the search, advertising, and portal markets heat up with existing giants waking up and new, disruptive technologies start chipping away at the heels of the Big Ones.
Be safe!
Monday, May 28, 2007
FBI Security
...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!
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!
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!
Subscribe to:
Posts (Atom)
