Threat actors are acutely aware of the difficulty of attacking large enterprises. They are well funded and well protected, using the most up to date defences which are managed by teams of dedicated security personnel.
Cyber criminals are becoming frustrated with attacking large enterprises that either shrug off cyber-attacks, or refuse to pay ransoms. This could be why the majority of businesses that experienced a cyber-attack in the UK last year were defined as SMEs [1]. Plain and simple, SMEs are easier targets.
Equilibrium aims to take at least some of the tools used in big enterprises, and equip SME’s with them. Giving them a fighting chance against the pervasive, relentless threat of cyber-criminals that would gladly rampage through your network for the chance at a payday.
One such tool, or rather technique, is threat modelling.
Know Thy Enemy
Threat modelling is a structured approach to thinking like an attacker. adversaries (and to some degree pen testers) tend to do this instinctively; they see a web application that manages your customer’s data with a stack of input fields and they instantly start to get some dangerous ideas.
Recognising a potential exposure isn’t so simple. The owner of the application might be there in a management capacity, the databases that support it might be sat with your infrastructure team, and your developers could be outsourced.
Very few businesses have the luxury of individuals that understand your applications and systems end-to-end AND have an understanding of Cyber Security.
How It’s Made! – Threat Models
There are many defined approaches to threat modelling, such as STRIDE, DREAD, PASTA and the MITRE Att&ck framework.
Instead of bombarding you with acronym (pasta) salads, we want to boil down the various frameworks to explain the core logic behind them:
To systematically identify threats and protect your assets.
Instead of trying to adopt a framework that is designed for large enterprise, and rigidly trying to adopt these strategies because it’s “the done thing”, we recommend you take the basic principles on board. Once you have a better understanding of the fundamentals, your organisation will have a better time of picking and adopting a framework that suits your needs.
To get started, let us ask you three simple questions:
- What have you got?
- How could someone attack it?
- What can you do to stop them?
This is a very reductionist approach, but it is a starting point, especially for an organisation that doesn’t have dedicated security personnel. Walk before you can run, right?
Dairy Dudes – A Cheesy Case Study
So let’s explore these questions as they apply to a made up cheesy story:
Dairy Dudes is an SME with 25 members of staff, they have traditionally supplied artisanal cheese products into retail businesses, but the organisation has recently pivoted to selling direct to consumers via a web application.
Customers are loving he ability to get a hunk of high quality cheddar right through their letter box. Cheese on demand – it’s the way of the future!
The application is developed by a two person development team, both are aware they should write secure code, but neither are experts in Cyber Security. One of the director’s has been doing some reading on LinkedIn of businesses of a similar size being hit with attacks that have devasted them, and has asked the IT team if their new apps are safe against that sort of thing. Time for some threat modelling!
Question 1 – What have you got?
The developers are asked to explain the technologies and functionality used in their web application. The developers explain that the web application is fairly typical in structure, it’s a React frontend, a Node JS backend that consists of a single API.
Supporting it is a database where they store their customer’s details and orders. The whole application sits in the cloud on AWS. This gives us four major components:
- Frontend
- Backend API
- Database
- Amazon Web Services
Question 2 – How could someone attack it?
This is where we drill down a little bit further, to understand how someone could attack these components, we need to understand a little better where our important data is.
To do this we can come up with very high-level ideas (it helps to have someone who is especially paranoid for this part). For example, let’s say someone puts forward the idea that it would be disastrous if a user could get direct access to the database.
To understand this kind of attack we have to understand how the application uses the database, speaking to the developers, they say that there is a few places where data is retrieved, for example on the profile page and on the orders page.
The database is using MySQL and the API makes a call to retrieve the profile information of the user that requests it by checking their ID number and entering it into a query.
So, how could someone attack it? Well, they could change the ID number that is requested, it would retrieve someone else’s data.
Question 3 – What can you do to stop them?
Now that we have an idea of what we’ve got, and how someone might choose to attack it, we can now make some decisions about how we can stop them from doing so.
In the case of the above attack, the developers need to find a way to put a check in place to make sure a user can only request the profile data for their own user ID.
Another option might be to look at the way the data is retrieved in the first place, maybe instead of getting the information with an ID, we do it based on a cookie that a user can’t change in the first place.
We’re trying to avoid getting too bogged down with technical details here, as the point of this is how you can direct these activities from a management perspective to give your team the chance to proactively identify and address threats.
Now do it again – but better!
The activity doesn’t stop here, not for this particular threat, nor for the component (or asset) as a whole. This process is something organisations should regularly execute.
By running these exercises and involving different stakeholders with differing perspectives, you can build up a large list of potential threats and mitigations.
When done properly you should end up with large lists of potential threats and mitigations, and that is when the more official and rigid frameworks come into place. Once you’re dealing with 100+ potential threats and -100 hours of resource in your team to handle them it then becomes important to assess these threats by their individual merits.
Such as what the potential impact, severity and likelihood are. Threats are then sorted into a risk register and the most severe can be prioritised for mitigations.
To Conclude
Threat modelling is a crucial tool for all businesses, not just big enterprises. No certification is required to harness its core principles. By employing three straightforward questions, you can unlock the potential of threat modelling and revolutionise your security approach.
References
[1] Half of SMEs experience surge in cyber-attacks – Vodafone research reveals, 2022,
Ready to achieve your security goals? We’re at your service.
expertise to help you shape and deliver your security strategy.
