This post on sys-con.com – about using the Agile approach (often used for development projects) for threat modeling and prioritization is a really great set of ideas. If you’re not actively folding threat modeling and active thought on prioritization of threats into your development and admin cycles, it’s an almost certainty that you’re missing the boat and are going to be caught in the mistake, sooner or later.
It’s incredibly difficult to pick and choose priorities, but as the article points out, by rolling your options through an agile like process, you can idetnify which items to start with and how to begin to address them, even if you’re not completely eliminating whatever threats or issues you’ve identified. That’s a long way of saying – check out the article, it’s a good read.
But the thing that first caught my eye was the title of the post, “Even If They Hacked It, So What? …” This is a pet peeve of mine. Too many times, when things go wrong, it’s blamed on the person doing things that they shouldn’t be. In my mind, this laying of blame at the feet of the wrong-doer is a waste of time and simply serves to prevent proper steps from being taken to more preventatively address security and functionality issues.
At some point it has to be moved from “well, if they hadn’t broken in to our systems…” to proactively addressing what we know to be open issues. With an Agile approach, we can choose iteratively, we can take small, continuous steps toward doing the right things in advance of any potential attack or intrusion. We need to do this on a constant, ongoing basis.
Taking responsibility (vs. blaming the attacker) won’t really change this, but perhaps realizing it’s on us (collectively) to prevent rather than only respond to an existing issue, is step 1 in the process to better manage threats.
Reading through the article, it seems taht threat modeling is a great place to start, it gives us an excellent look at the things that are identifiable as issues. From there, we can figure out the bite size, iterative pieces that we must do.
For example, ifyou’re working through PCI issues, there are several areas to consider – here are a few:
– protection of personal information
– protection of credit card information
– security and access controls
– logging of access
– protecting data at rest, in transit, etc.
Each of these is a pretty big deal. But if you identify them, then start chipping away at them, you can make serious headway and always be getting better at addressing them. Applying the Agile approach is an excellent process for managing the cycles.
In this example, perhaps you start with the front-end encryption – ssl and doing the things necessary to protect information there. Even that will likely have to be split up into chunks that will work with your releases and processes with Agile.
In my opinion, we have to break the response-to-issues cycle and we have to take proactive (and when we miss, reactive) responsibility, but more than that, we have to work to build addressing threats directly into the deployment cycles and start iterating on the biggest bang for the buck on a piece-by-piece basis.