|
I'm not referring to cryptography, I'm referring to security in the general sense. Security is fundamentally about placing obstacles between your assets and those who you don't want to use/alter/control those assets. When you design software, you have all sorts of assets you'd like to protect, even for the simplest cases. Administrative access, general data, CPU cycles, workflow, network bandwidth, and maybe even passwords, secrets, etc. Your job (with a security design hat on) is to place the firmest obstacles you can between those assets and those you don't want to use them (usually prioritized by a combination of probable risk, severity of loss, and cost to protect). Thinking in terms of assets you need to protect is a highly recommended way to design securely, regardless of whether you're talking about military, bodyguards, buildings, software, cryptography, or systems. You then proceed to put up your best obstacles and then reshore/rebuild/redesign those obstacles when they are known to be compromised or compromisable. All the while ensuring that the system operates as efficiently as you can reasonably manage. Fixing "a buffer overflow" is just a method for repairing the software obstacles you already had in place. Sanitizing inputs is, indeed, adding an obstacle for attackers. "Proving code paths" takes into account that your obstacles remain in place to protect your data with certain assumptions about the systems involved. If you're interested in security engineering in general, I recommend picking up some of the latest (last 5-10 years) literature on Threat Modeling as it really can change one's perspective on what security is all about. A lot of engineers I've worked with think of it in terms of "using the best string library", when it's more about designing systems to protect your assets as best as you can and still get your job done. There are all sorts of practices, tools, fixes, libraries, etc that help improve existing "bricks" in your obstacles, but they're absolutely no replacement for actually understanding what you're trying to protect and having a strategy for preventing those from being compromised. The best security is designing such that you never put your assets at risk than that you use the right libraries to, for example, manage them during transit. |
An obstacle is something you overcome. I don't think you mean it that way, but that's what a lot of people think. So, for instance, a Javascript hashing scheme backed by a Greasemonkey script that tries to verify that passwords actually make it through the hash function. That's good, because it "adds obstacles". The security of the system is the sum of the value of all the obstacles.
No. The security of the system is inevitably the value of the 1-2 most important controls and constraints. Think of it like the difference between O(log n) and an O(n) algorithms: the constant factors don't mean much. So, you can do all sorts of gymnastics with hashes and nonces and salts (and timestamps and sequence numbers and MACs), but you turn SSL on, and now the only thing that matters is SSL.
The "obstacle" mindset, also known as "defense in depth", is what gets us IPS, web application firewalls, and antivirus. None of these $50,000 products work. But they're defended by managers and purchasers and vendors as "another layer in a defense in depth strategy". What we need is software that works, with defenses that are clear and fundamentally sound. What we get, too often, is band-aids.
Again, I apologize, because I'm turning you into a straw man and I don't mean to. The word "obstacle" sets me off. It shouldn't, because obstacles pay for my consulting team and my development team. I should say, "more obstacles, please!" "Please, build another ActiveX control to implement an AES challenge-response protocol with a compiled-in key!" "Please, build another web filter for which every nonminimal UTF-8 encoding variant is another security advisory for!"
Oh well. I'm old.
By the way, being somewhat close to the drama here, I want to note that the "new Threat Modeling" is a bit controversial, the terms are still up in the air, and if you want to learn more about security, you'd be far better off reading Ferguson's "Practical Cryptography" and McDonald, Dowd, and Schuh's "Art of Software Security Assessment".
Don't build obstacle courses. Design stuff that works.