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 responsibilities, 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 by the team designing, building, and operating the application and is treated as a primary 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.
Tip
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 modeling 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 chapter, 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
A process for threat modeling
As preparation for your threat modeling sessions, you may find it conducive to productive meetings to have the following information prepared:
- High-level architecture of the application
- Solution design documents
- Data models and schemas
- Data flow diagrams
- Domain-specific industry compliance standards
A typical threat modeling process will comprise the following steps:
- Identify the elements in your application that could be targets for potential threats, including data assets, external actors, externally accessible entry points, and infrastructure resources.
- Identify a list of threats for each element identified in step 1. Be sure to focus on threats and not mitigations at this stage.
- For each threat identified in step 2, identify appropriate steps that can be taken to mitigate the threat. This could include encryption of sensitive data assets, applying access control to external actors and entry points, and ensuring each resource is granted only the minimum permissions required to perform its operations.
- Finally, assess whether the agreed remediation adequately mitigates the threat or if there is any residual risk that should be addressed.
For a comprehensive threat modeling template, see Appendix C.