|
||
|
6 April 2013 Why Digital Security Sucks
Date: Sat, 6 Apr 2013 13:28:30 -0400 On Sat, Apr 6, 2013 at 7:34 AM, ianG <iang[at]iang.org> wrote:
> On 6/04/13 07:27 AM, Nico Williams wrote: I think you're giving the NSA way too much credit on why security sucks. Even if we were to restrict 'security' to the scope of cryptography, even there, I think the NSA has much less to do with dumbing down crypto security than other factors. IMO, the biggest factor is that 95% or more of developers are completely ignorant of best practices in cryptography. They good to some security book or beginning crypto book and emulate the first example that they see which is using something like AES with ECB mode and no padding and they copy it. Done. Cross that off their list. When I've spoken to them, they aren't even aware of what cipher modes are let alone why they should be using authenticated encryption! I blame a lot of that on API design. Great example of poor design is Java's JCE. It exposes cryptographic primitives as the expected low level that developers want to deal with where what the really need is a much higher level API. Furthermore, the defaults in JCE are just wrong (e.g., ECB mode with no padding, no authenticated encryption modes supported in the reference SunJCE implementation, etc.) However, the real reasons that security sucks goes way beyond crypto. In fact, only a small part of application security has to do with crypto. As has been repeated several times on this list, even bad crypto is seldom the weakest link. And I don't even believe that the root cause for poor security is even developer ignorance or apathy. Most developers want to write code that is secure. The reason they don't is that it is just not a priority for them. There are two things that I think are fueling our poor application security. The first is, that the sponsoring business units see not value per se in building systems that are secure nor even maintaining secure systems (e.g., through regular patching and operational reviews, etc.). They typically see security only has an additional cost that contributes nothing to their bottom line. Because of that they are not willing to provide additional budget nor additional time in schedules to bolster security. This also somewhat explains the developer crypto ignorance in that they seldom are willing to fund developers to be trained in application security, including applied cryptography. Second, but somewhat related to this, is that developers are not rewarded for developing secure designs and/or writing secure code. They are rewarded for writing efficient and fast code that reduces hardware needs (thus lowering costs) and for writing fault-tolerant code (thus reducing outages and increasing availability), but it is rare to see anyone *rewarded* for writing secure code. (Note that the reverse may be true though...developers may be punished [through dismissal, etc.] for writing really bad, insecure code, especially if the organizational culture is to find a scapegoats when a security breach is discovered.) In many ways it is even very difficult to identify those who write secure code; it is much easier to identify those who write insecure code. Generally, only the test of time helps identity those who regularly produce secure code, but because it takes so long, there is no near term feedback and those developers are not rewarded for it. Consequently, it is not a priority with them. Note that these are only observations that I've seen that have been consistent through all the places where I've been employed. YMMV, but I expect there will generally be more similarities than differences. Just my $.02, -kevin --
Blog:
http://off-the-wall-security.blogspot.com/ _______________________________________________
cryptography mailing
list
|