A bit off-topic, but I'll nibble...
The broad consensus is that Stuxnet was specifically targeted at this enrichment facility by a national intelligence organization. If a private company were the target, they'd just confiscate or destroy the computers... no worries about retaliation or violating said company's national sovereignty.
In my view, it would be an incredible waste of resources for a run-of-the-mill IT shop (or even a high-end sophisticated one) to plan for the prevention of this type of event in their security policies.
Yes. Of course you do. The catch is that's why you build your policies to be more high level and your procedures to be more technical and specific. You realize that your procedures will change as attacks evolve. Yes, it means the good guys are always playing catch-up. That's why we don't sleep.
answered Jul 15, 2011 at 11:37 AM
K. Brian Kelley
I think with so many other things the answer is: it depends.
I think every institution should take basic security practices into consideration. I have particularly written about basic steps to make a SQL Injection attack more difficult at http://www.simple-talk.com/sql/learn-sql-server/sql-injection-defense-in-depth/
Now, whether or not you need to go beyond the basics (and preparing for a highly targetted attack from a highly sophisticated attacker in any meaningful way certainly goes far beyond the basics) is a cost-benefit-analysis. While you certainly should avoid obvious security errors (storing passwords in plaintext, reusing passwords, etc) once you get past that point increasing security often comes with multiple costs, and some of these costs can be very high.
For instance, one common way to improve authentication is to issue some form of authentication token along with a password. This token may come in the form of a smart card or a device that creates single use identifiers, etc to go along with your main password (this would be Two Factor Authentication). This goes a very long way to improving authentication and strengthens security a great deal. But now you have to pay (or make your users pay) to have those tokens physically created. The user then has to actually keep track of this token and go through extra steps to use it, all of which involves costs.
Encryption, used properly, can be an enormous boon for security. It can vastly reduce the damage that is actually done by other security breaches. But it comes with multiple costs. Even if you use free software (I am a fan of TrueCrypt personally), it comes at a price in both performance and inconvenience, not to mention the risk that the decryption key will be lost which risks lost data.
And those are both still fairly straightforward, simple examples of ways to increase security. To protect against a determined, sophisticated attacker that is targeting you specifically, you need to go much further.
So, then it becomes a cost-benefit analysis. What is the likely damage of a breach? How likely are you to be targetted? How expensive are the planned security measures (and remember to include all costs in that, including inconvenience to the user)?
If you are talking about a bank or an institution that deals with highly confidential information (such as, say, medical records), then it probably makes sense to have a fairly high level of security and to be willing to pay for it. If you are dealing with less sensitive information then it is probably a bad trade off.
For isntance I would be quite willing to take the inconvenience of two factor authentication with my bank and would be willing to pay for the token myself if they made that an option. On the other hand, I am not overly worried about someone hacking my account on the servers where I play Go, and might easily look for another server if they made the sign on process even slightly annoying. I have a TrueCrypt file where I store my tax records and other records that might have my SSN or a credit card number. I do not however encrypt the notes I take in class. It all comes down to how much the security is worth versus how much it will cost.