Home > Information Security, Musings > Security Mental Modeling

Security Mental Modeling

September 11th, 2009

Call me crazy, but it bothers me that information security is so “hard”. I know, I know, seems like we all say this, and we endlessly rail against the usual evils that make our lives suck on a daily basis: management doesn’t understand, infrastructure is too complex, the Dev teams don’t give a $*@#&, etc. And on. And on. I have lived this life – it’s easy to fall into the mindset of going to work each day with a frame of reference that looks a bit like this:

  1. I know my job. ***Whatever this may be***
  2. I know my organization. ***Politics, infrastructure, etc.***
  3. I know my team and their capabilities. ***Who does what***
  4. I know our tools and systems ***Security-specific tools and systems like IDS, SIEM, etc.***
  5. I *think* I know what my problems are.

One thing that’s interesting, though, is that we almost never get to build or design a security architecture from scratch. We just keep adding on or changing the Frankenstein monster that is our security machine, and gradually build up the complexity of it all and lose at least some semblance of control. Ugh. Just for the heck of it, what if you could start with a completely blank slate? I’m not talking tools, just a mindset of how to go about things? At the most simplistic level, my mental security model would probably look a little like this:

SecModel


Network Level: Create a policy based on “Deny All” and allow only what’s needed.

Host Level: Application Whitelisting and Configuration Management via imaging and policy controls.

Application Level: Secure coding and QA, with behavioral assessment and input filtering.

You’ll also notice an up arrow with the term “Behavioral Assessment” – this signifies the importance (in my mind) of behavioral analysis and comprehension as you move from network –> Host –> Application. In other words, most important at the App, least important at the network. This is NOT to say that host and network behvaioral analysis is unimportant, far from it. But as a starting point, I’d go with the App since we should be able to define the flow of business logic within it and then observe deviation.

Now, of course we want change management and patch management and monitoring tools and all of that…but as a simple mental model? I can get my arms around this thing pretty well. So given that we don’t get a “RESET” button in security…how do we return to a simplified view of things and build from there?

Categories: Information Security, Musings Tags:
  1. Chuck Jones
    September 11th, 2009 at 08:54 | #1

    I agree, if we had the luxury of starting from scratch (which we almost never do) in most cases we would look at security from the inverse direction. This perspective has rarely been the case, relative to how security architectures were implemented, since that philosophy was frequently not in place back when IP networks were being built out, and firewalls and A/V were the prime focus. I think many security organizations are taking a much more business focused view of their Enterprise Security Architecture, but retrofitting into most environments simply adds complexity. Having said this, taking a business process view of authentication and authorization is the right approach and a lot of good work is being done in the IdM area. It is going to be in incremental process to get there, it’s going to take some time, but it will be worth it.

  2. admin
    September 16th, 2009 at 11:33 | #2

    Agreed, Chuck. Honestly, taking a business process view of most security processes, if not all, would go a long way.

  3. September 17th, 2009 at 23:16 | #3

    This is an interesting model and can be applied to penetration testing reporting too. Too many pen testers focus on telling the client how to fix the current problems, without looking at the deficiencies or root causes which created the problems to prevent them reoccurring.

Comments are closed.