If you know me, you know I’m not a fan of firewalls.

Well, that’s not strictly true. Maybe I should say I’m not a fan of people who equate firewalls with security.

Firewalls are perfectly good devices for performing the function they were designed to do: make a broad-based decision to allow certain packets in or out of a network. The trouble is these days, that our networks are a lot like your local shop… and the firewall is like the shop door.

Let me explain.

You see, down at your local shop, the door (remember door == firewall) is open during business hours allowing a constant stream of customers in who just can’t wait to part with their money. However, when the shop is closed, so is the door. It keeps those customers out, no doubt upset at their inability to spend money at the local shop.

Aha… but it’s not just customers that come into the shop through that door. Unfortunately there are also thieves, spies (well, let’s call them ‘competitors’ doing a little ‘market research’), delivery people, suppliers, etc. The door doesn’t do anything but let everyone in, or let nobody in.

Today, I was once again reminded of the shop door. After reviewing a specific architecture design for a web-based application I was promptly shown that there was a firewall in place in front of the web server, to make sure the only traffic getting through was on good old TCP port 80, which new-fangled kids these days sometimes call HTTP [I'll refrain from having one of my 'get off my lawn' moments about the difference between ports and protocols]. Sure, the firewall serves a purpose–like the shop door–but it’s also letting all those would-be web hacker types have a crack at your shiny new web site.

So, following the analogy, I extended it a bit further… telling the architect that he needed a ‘bouncer’.

You see a bouncer (or ‘doorman’ to use the correct term) is often found outside a nightclub. They work hand-in-hand with the door, performing additional checks to see that only ‘acceptable’ customers are permitted entry. And so in looking at this weird and wonderful analogy, the architect concluded that additional protections might be warranted. Good call.

So ask yourself… is your business running out of a local shop, or a nightclub? It just might be time to hire a bouncer

I was recently invited to take part in a session being run by a project team looking to determine security-related Non-Functional Requirements (or NFRs) for their project. In essence, the project team were wanting to identify a number of security considerations ahead of designing the system. These considerations would be structured to become the security requirements, and the system design would be such that these requirements be met, or risks mitigated.

In my experience, it is rare to find this level of planning early-on in projects; certainly it is something more often found in large established companies, than in small businesses. What made this exercise so worthwhile was the planning that had gone into the session beforehand. Before we even came together, the chairperson had organized a mind-map with some of the thought-avenues we’d be taking. In this particular exercise, we started with the Horror Story–what is the worst scenario we could picture that could arise as a result of some security failure?

That is where the fun starts. The people in the meeting have to shift their mindset, and begin thinking like an attacker. This comes more naturally for some; with others it takes time–but universally it is a source of fun! The Horror Story starts with a scenario, with the team floating ideas of how that horror story could be a reality. These are expressed and recorded as anti-requirements: e.g. Passwords will not be complex, making it easy for attackers to guess.

After the session, the team regroups and looks at each of the anti-requirements. They are then ‘flipped’ to form a positive, security-related requirement for the project.

This brainstorming approach is a good first step. At the very least, it means the project team is thinking about security from the outset–and as any security practitioner will tell you, “building security in” is the best approach. However, it doesn’t mean it’s the end of the journey. Teams, such as the one I worked with recently, should consider extending this practice to incorporate structured Threat Modeling techniques.

Threat Modeling can be accomplished in several ways, but at it’s most basic, it is the exercise of looking at a Horror Story and working back to the preconditions that would make the Horror Story realizable. These preconditions can be arranged into trees–showing how they must be combined to make a specific outcome possible. What we are left with is a simple graph of conditions that must hold true, in order for the Horror Story to become a reality. Thinking about this a different way: we have a graph showing what conditions we need to take care of to prevent the Horror Story coming true!

Threat Modeling can be a very powerful technique for quickly identifying the major causes of security failures. More importantly, it can help your team invest wisely in addressing those conditions that present the most risk.