Serverless Threat Modeling
Before designing a comprehensive security strategy for any serverless application, it is crucial to understand the attack vectors and model potential threats. This can be done by clearly defining the surface area of the application, the assets worth securing, and the threats, both internal and external, to the application’s security.
As previously stated, security is a continuous process: there is no final state. In order to maintain the security of an application as it grows, threats must be constantly reviewed and attack vectors regularly assessed. New features are added over time, more users serviced and more data collected. Threats will change, their severity will rise and fall, and application behavior will evolve. The tools available and industry best practices will also evolve, becoming more effective and focused in reaction to these changes.
Introduction to threat modeling
By this point you should have a fairly clear understanding of your security respon‐ sibilities, a foundational security framework, and the primary threats to serverless applications. Next, you need to map the framework and threats to your application and its services.
Threat modeling is a process that can help your team to identify attack vectors, threats, and mitigations through discussion and collaboration. It can support a shift-left (or even start-left) approach to security, where security is primarily owned bythe team designing, building, and operating the application and is treated as a pri‐ mary concern throughout the software development lifecycle. This is also sometimes referred to as DevSecOps.
To ensure continuous hardening of your security posture, threat modeling should be a process that you conduct regularly, for example at task refinement sessions. Threats should initially be modeled early in the solution design process (see Chapter 6) and focused at the feature or service level.
Threat Composer is a tool from AWS Labs that can help guide and visualize your threat modeling process.
Next you will be introduced to a framework that adds structure to the threat model‐ ing process: STRIDE.
STRIDE
The STRIDE acronym describes six threat categories:
Spoofing
Pretending to be something or somebody other than who you are
Tampering
Changing data on disk, in memory, on the network, or elsewhere
Repudiation
Claiming that you were not responsible for an action
Information disclosure
Obtaining information that was not intended for you
Denial of service
Destruction or excessive consumption of finite resources
Elevation of privilege
Performing actions on protected resources that you should not be allowed to perform
STRIDE-per-element, or STRIDE/element for short, is a way to apply the STRIDE threat categories to elements in your application. It can help to further focus the threat modeling process.
The elements are targets of potential threats and are defined as:
- Human actors/external entities
- Processes
- Data stores
- Data flows
It is important not to get overwhelmed by the threat modeling process. Securing an application can be daunting, but remember, as outlined at the beginning of this chap‐ ter, it can also be simple, especially with serverless. Start small, work as a team, and follow the process one stage at a time. Identifying one threat for each element/threat combination in the matrix in Figure 4-4 would represent a great start.
Figure 4-4. Applying the STRIDE threat categories per element in your application