Here's the scene; you're a startup and you're gaining good traction, or a scale-up and have just closed a decent round of funding. You're probably at least starting to think of cyber security at the back of your mind somewhere. At this stage, you're probably wondering "where do I start?".
If I said to you "George, what if I told you there was a way to prevent security vulnerabilities BEFORE they actually occur?". You would say "surely that's impossible, and my name's not George".
Well, George, it is possible, it's called threat modelling and I'm going to tell you all about it. Here's the OnSecurity guide for start-up and scale-up threat modelling!
What is Threat Modelling?
You'll often hear security types tell you that if you want to protect your business, you need to "think like an attacker". All well and good, except you're not an attacker. You might as well be told to think like a pilot or a tiger trainer. Unless you're a qualified pilot or Joe Exotic, you don't know how to think like these people.
So, how can non-attackers (i.e. the vast majority of people) adopt a mindset that helps their business stay secure? There's one thing every business needs to protect, and one thing all business owners are expert in: Assets.
Every business has assets. Be it a product, a platform, staff, stock, whatever. You have assets and you know what your assets are (or at least that's what you told investors during your last raise).
Threat modelling is thinking in a conceptual way about how to protect those assets, by thinking about all the cyber-nasty things that could conceivably happen to them. These nasty things are threats. When we know our threats and our assets, we can figure out how to mitigate those threats.
Take a simple, non-cyber example. You're a turnip grower. You have turnips. And lots of them. You store your turnips in your warehouse (Disclaimer: I don't know if turnip growers do this - I'm not into turnips). In this scenario, we've described two assets; turnips and a warehouse.
A threat to this business is somebody stealing all the lovely turnips from the warehouse.
A mitigation would be to put a decent padlock on the warehouse door, and some security cameras and guard dogs (specially bred ones that don't like turnips).
That's really the crux of it. That's how simple threat modelling is. Think through all your assets. Think about what could go wrong with those assets. And think about how to stop those things going wrong.
The likely lads
OK. Assets. Threats. Mitigations. All well and good.
There are a couple of important nuances to think about. You have a limited budget, so you can't mitigate every single threat. So we need to somehow prioritise these threats. We do this by looking at the likelihood of the threat occurring versus the impact of the threat occurring.
Back on our turnip farm, imagine the following risk:
A competitor hires a tunnel-boring machine and tunnels under your warehouse and uses the tunnel to steal all your turnips.
A mitigation strategy for this threat is to build the warehouse on a foundation of steel-reinforced concrete (or something along those lines - my knowledge of construction is worse even than my knowledge of turnip growing).
The impact of this threat becoming real is very high: you lose all your turnips.
The probability of this threat occurring in the real world is very low: the cost and difficulty of a competitor doing this versus the value of the turnips make it an infeasible attack to carry out.
Therefore the priority of this threat would be classed as very low. The mitigation cost is very high, and therefore you would accept the risk.
Apply this model to all your assets/threats/mitigations, and by the end, you will have a pretty decent prioritised list of security controls you need to implement.
Threat modelling in practice
Threat modelling is super easy to do in practice. You need a couple of hours with key people who know how your business hangs together, something to draw on, and a spreadsheet.
Step 1 - Draw your assets
Start by diagramming out all your assets and how they are theoretically connected. Anything you can think of is valid:
- Main e-commerce web app
- Internal admin applications
- Staff laptops
- 3rd party platforms
- Staff phones
- Office wifi
- Office Windows domain
- Etc
Step 2 - Define your threats
Once you have a list of all of your assets - start thinking about threats. It may be useful at this point to have someone with a security background in the meeting, but it's not necessary, do the best you can with what you know.
At this point, you can use one of the recognised frameworks (STRIDE, MITRE CAPEC) which classify attacks so you can consider threats you may not have thought or heard of before. But remember, this is a common-sense exercise.
Step 3 - Prioritise threats
When you have all the threats each asset faces, it's time to assign a priority to each threat. Do this as above, based on the likelihood of the threat occurring and the impact of the threat.
When thinking about impact - think about the various types; there could be financial, legal, reputational, operational and other impacts.
As an example; a threat would be your main e-commerce platform being subject to what is known as an "SQL injection" attack, which would enable the attacker to retrieve all information from the database behind the platform.
The impact of this would be very high. You will have lost customer information (meaning GDPR fines and the rest of it), there will be reputational damage and operational interruptions, all incurring the financial cost.
Since the platform is public-facing (and therefore hacker-facing), it is almost certain that this attack will be attempted at some point in time.
So, very high impact x very likely to occur = high priority.
Step 4 - define mitigations
OK, at this stage we have a list of threats ordered by priority. All we need to do now is work down the list from highest priority to as far as we can get, and talk about mitigations for each risk.
It can be worth assigning a mitigation effort metric here, to help you further focus your resources.
Taking the e-commerce SQL injection example above. The mitigations for this would be:
- Use a recognised framework
- Use secure coding practices
- Use parameterised queries
- Ensure input and output is escaped/encoded
- Web application firewall
- Secure coding training for developers
- Regular pen-testing
- Etc
Some of these mitigations are very low effort/cost. Some will mitigate the risk more than others.
Versus the high priority of this vulnerability, something as simple and cheap as using parameterised queries is 'no-brainer' territory. On the other hand, a web application firewall can be expensive, and you may not have the budget to adopt this mitigation, when set against the additional reduction in risk this will provide.
All this needs to be thought about in a realistic way during the exercise.
Step 5 Project Plan
At this stage, you have a list of assets, prioritised threats, and mitigations with a level of effort assigned to each. Using this you can produce a straightforward and simple project plan that will help you put measures in place which will eliminate threats to your assets before they have a chance to become a reality.
Step 6 Continue to Evolve
A threat modelling document should be live. Each time you acquire a new asset it should be added to the model and the above steps should be repeated.
The entire exercise should be carried out periodically, you will gain new insights into threats and mitigations as you go, and should apply these to your threat model regularly.
Conclusion
If a startup or scale-up owner asked me "what's the first thing I should do in cyber security?", my answer would be grow turnips threat modelling, 100% of the time. It's easy, it gets you thinking in the right mindset, and it can genuinely solve security issues before they've even had a chance to occur. What's not to love?
If you need some help carrying out your own threat modelling exercise, or you simply need some security advice, then get in touch.
Conor O Neill is head of product strategy @ OnSecurity. He has 2 cats, not by choice.
