Security Thoughts on a Cold Winter Night

Now that winter is upon us in the Northern Hemisphere (if not because of the weather, at least surely on the calendar), I reminisce about the past summer. One of the things I did was to listen to several dozen Packet Pushers episodes. Yes, it was a great summer!

In one of those episodes (show 56, then continued on show 61), Ethan and guests started a debate on how to secure an internet-facing application, starting from the host side. Great discussion, but I wanted to contribute somehow.

What I thought was missing from the discussion was that before jumping into architectural options, we need a clear understanding of what it is we want to do. In older times, this would be the infamous ‘policy’. Just like the word ‘hacker’ has been subverted, so has ‘policy’: it changed from being a description about how the organization defines its stance and goals around security to merely being the instantiation of something at a particular level – to “push” a firewall policy, to add “policy routing”, etc.

While this post is not ‘technical’, I hope that people recognize that it is not ‘management drivel’ (layer 8 or above broadcast storm…)

The philosophical approach I propose to use when thinking of security as being based around PROTECTION-DETECTION-REACTION of/for a well-defined BUSINESS asset:

  • BUSINESS: The zeroth law is that the act of securing something is done to support the business goal, whatever that it. Yes, there are things that really, really, REALLY should be done, but there also has to be a balance: how far you dial the security knob (11?) must relate to what people actually want to do with your system, how critical that system is, what it is connected to, etc. In the episode, we just hear of a ‘naked server’ out on the Internet. More details needed…
  • PROTECTION: The best defense is to not be there to be attacked in the first place. That’s the theory behind a lot of – but not all of – hardening hosts/routers/…: remove functionality that can’t be attacked. Some people call this reducing the ‘attack surface’ or ‘window of exposure’. Next up are security controls that are there to restrict access, to delay an intruder and be sources of information about something going on. Not having a compiler installed locally, proper file permissions, mandatory access control, …
  • DETECTION: Having enough monitoring in place – event collection *and* interpretation+alerting – to recognize that something is amiss. This is the area that should receive the most attention/resources, in my opinion, as the system will spend most of its useful life in a ‘production’ state.
  • REACTION: Expect that the system/component will be compromised at some point and plan accordingly. This means primarily have the mechanisms to recover, be it reimaging the server/VM (snapshots, etc…) or maybe – assuming that the other controls worked enough for you to somewhat confidently determine that the impact was limited – correct the failed component and move on. You don’t necessarily have to rebuild your entire ERP system if a user password was guessed. This is where balance/common sense/… come into play….

I like to talk about this kind of thing first because then *every* security discussion can focus on these topics. Talking to your server guys? Focus on hardening, local controls, etc…? Storage folks? Ditto. Web developers? You can easily explain how hardening, mod_security and SSL can play a part. And so on…

Ultimately, this is useful to frame the discussion to management as well – “yes, we have firewall doing X, but we’re flying blind because the logs aren’t being reviewed”, etc…

So, nothing earth-shattering, but a useful framework for discussing security and not just a laundry list of controls that may make sense to you but not to others.

As Mrs.Y aptly mentioned (I may be paraphrasing), the days of security isolated from everything else are over.

Leave a Reply

Your email address will not be published. Required fields are marked *