Threat modeling is the process to layout a system with a security risk point of view to answer the question, “What can go wrong with this?”. The process of threat modeling has been around for a very long time yet it is not a common inclusion to application development or infrastructure projects. As the world shifts how applications are made and deployed, threat modeling is becoming a critical security component to all projects no matter the size.
Moving from an on-premise environment to a cloud, especially when there is cross-environment communications, a threat model will help identify all the security areas of concern and focus. If you take a step back and look at the data flow, each time data moves from one area across a boundary, whether it’s a VLAN or across the Internet, that is a risk that needs to be reviewed and designed properly. Cloud migrations introduce more data flows across untrusted areas than ever before which makes threat modeling more important than ever before if you don’t want to miss anything.
Similar to an architecture model, a threat model looks at an environment or platform to follow how the data flows, components, or actors involved and the environments used. Laying those out into a logical picture you can begin to conduct a risk assessment of each part to help identify any threats and design in remediation before any code is written.
There are many styles of threat modeling but the most common is called the STRIDE method. STRIDE is an acronym (S.T.R.I.D.E.) that stands for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privileges. A threat model helps identify risks in each one of the STRIDE categories.
Here’s how the categories break down –
Spoofing
Spoofing is the act of pretending or posing as someone else. Basically is using the account is that it is not yours where the system thinks it’s the owner but in reality, it’s a malicious actor.
Mitigation of Spoofing is done best with a well-designed authentication system.
Tampering
Tampering is malicious or unauthorized modification of data, processes and/or systems. Tampering can happen on the process, data in transit or data at rest.
Examples of tampering are injection attacks, modifying data on disk or in a database or bit-flipping or other modification to data in transit.
Mitigation of tampering typically involves proper validation of user input and encoding outputs, using prepared SQL statements or stored procedures, parameterization, use static code analyzers and use 3rd party dependency security tools.
Repudiation
Repudiation is the ability to deny an action really happened. The reverse is the term non-repudiation which you want to design into your applications.
Simply explained, “This account did X. Here’s the proof.”
Repudiation can happen by an actor delete all the logs or records in a database, removing any ability to see what a system is doing and removing any record of the actions or manipulating logs to show something else. Simply leave no trace a malicious actor was there and what they were doing.
Information Disclosure
Information Disclosure is data leaks. The leaks can happen in transit, at rest, or through a process.
In the security triad, this is concerned with confidentiality.
Information disclosure can happen if a user is able to eavesdrop, sniff or read clear text traffic, read data on the disk in clear text, steal certificates and read traffic or read data in a database.
Mitigation practices involve encryption everywhere and not using self-signed certificates. Proper Identity and Access Management with well-defined segregation of duties policies can mitigate unauthorized users from seeing data they were not supposed to, this can also be a leak.
Denial of Service
Denial of Service (DOS) is the action of causing a service or network to be unavilable to regular processes or users.
In the security triad this is concerned with availability.
A DOS attack can be done through a SYN flood attack, filling up the storage to max, overload the CPU with cryptominers.
Mitigation efforts are tricky and vary from the areas you are trying to protect. This can be rotating and clearing logs to free disk space, network monitoring and intrusion prevention devices or putting in resource limits to prevent overloading.
Elevation of Privileges
Elevation of Privileges is getting access that you should not have.
The main example is a user exploiting a system to gain root-level privileges. Once root or superuser permissions are gained a malicious actor can do anything on a system or network.
Mitigation efforts are designing a good authentication and authorization system, use code analyzers to identify any gaps, stay current on patches, and practice the principle of least privilege. Give access needed not wanted or because ‘it’s easier’.
In summary a threat model helps a project team to systematically identify security risks in core categories across the platform, not just in the code. Building a threat model before anything is built will greatly improve your security posture from the start which will improve your development and deployment efficiency and speed as you will have less remediation later on.
In future posts, I will go through how to build a threat model using available tools.
Be aware, be safe.
