Defense-in-depth, a concept which most agree with, is where multiple layers of security are protecting the crown jewels. The idea is should any layer fail, which inevitably happens, you’re still protected. Nice. In network security there are firewalls, vulnerability assessment, IDS/IPS, patch and config management, training, encryption, anti-virus, etc. each mitigating some risk. As good as they are we know these traditional solutions they’re not perfect and don’t help much in webappsec. We need to develop a new set of layers. The problem is we haven’t figured out or agreed upon which layers the modern webappsec infrastructure is supposed to have.
It’s really important that we do or at least start the dialog about what’s working and what’s not.
Here’s what we know. Security inside the SDLC eliminates flawed code, not all. Vulnerability assessments identify vulnerabilities, and miss some. WAF’s and IDS’s spot and block attacks, some will pass through. We can train ourselves to be experts in some things, but not everything. Patching and configuration protects from the known, not the unknown. Encryption protects data from prying eyes, not all the time. Sure, these solutions are not perfect, nothing is. That’s the point of implementing defense-in-depth. Maximize the strength of the available solutions and mitigate they’re weaknesses to protect the organizational assets.
Let me put this question out there… if you could implement 3 action items to protect a website, above and beyond the normal network security stuff, what would they be?
1) Secure coding during development
2) Security as a part of the QA process (using automated tools, and a security-educated QA team)
3) Periodical security audits on post-production systems.
i prefer vulnerability management to defense-in-depth. mcgraw's "building security in" model is a classic example of what needs to be done in both camps. i saw it recently better described as "baking security in rather than icing it on".
web application vulnerability management has a lot of unknowns and fill-in-the-blanks right now. i almost feel as if web vulnerabilities have not been classified correctly, completely, and properly to any extent.
i like vulnerability management because it's a process. defense-in-depth sounds like a bunch of line items for optional products/solutions that don't end up working anyways because they can be circumvented. aka classic IPS.
i don't know about 3 items to protect a website, but i can give you one good one: security awareness.
I would prefer a WAF on using a scanner and code review, as a security officer, I don’t trust my developers and I’d like to have one place to control and audit the security of the sites I’m in charge of. We do use scanners during development, however, protecting the business logic is something that only good WAF can do.
I think a lot of defense in depth that goes into web application security is already existing, but people don't think about "defense in depth" as soon as they hear about them. One example would be requiring re-authentication for high-risk tasks. It's an effective mechanism to defend against a variety of attacks (session hijacking, XSRF, people wandering away from their desks, etc). Another example is logging. A good logging system, perhaps with some agents flagging transactions, is an excellent general-purpose backup. Credit card companies love this strategy.
Some of these are going to be general, some are going to be very specific. (Specific: user education + "is this your picture?" on login to mitigate phishing.) Un/fortunately, the application layer is much more difficult to secure, so we'll have jobs for the foreseeable future.
Post a Comment