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.