Why Threat Modelling Should Be Part of Your Serverless Development
Part 1 - Incorporate it to build robust solutions!
This is the first of a two-part series on threat modeling in serverless.
This first article discusses the threats to a serverless application and makes a case for incorporating threat modeling into the development process.
In the second part, I will explain the threat modeling process with simple steps to help you understand, adapt, and expand per your domain and development practices.
“Trust nobody!” “Secure everything!” “Defend in depth!” These phrases are echoed at every tech conference, more so at cloud and serverless ones.
Most organizations take various measures to raise security awareness. Some processes and procedures convey the significance of security and, equally, raise consciousness about the consequences of an intrusion or a breach.
Several books on security exist, training courses, security tournaments, certifications, and many other resources and encouragement for everyone. Security resources are often available at different levels for engineers based on their experience and role in architecting solutions.
Infrastructure security, data protection, and secure programming practices are among a few that are familiar to most of us.
Before we explore security in serverless further, let’s briefly look at threat modeling itself to set the context for the discussion.
What Is Threat Modelling?
“Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigation can be prioritized” — Wikipedia
To me, threat modeling is more of a thought process, a thought process that works with the architecture of the serverless application that you are going to build. This process helps identify potential application threats and incorporate mitigation plans.
Threat modeling need not be the thoughts of just one person. It can be a collaborative brainstorming session that brings ideas from everyone associated with the application.
Where can I apply threat modeling?
There are no limits to where one can apply threat analysis and mitigation. Threats are everywhere! Threat modeling applies to enterprise applications, specific features, and serverless microservices.
Here is a common service that has these four main parts:
An API used by its consumers
A lambda function that performs the business logic
A data store that maintains customer data
A log storage and analysis application
As we expand further in the second part, even this simple serverless architecture can benefit from threat modeling.
If you’re considering securing the API while looking at the above diagram, your threat analysis has already begun.
STRIDE
To develop thorough threat modeling, we need relevant thoughts about the architecture. To have valuable thoughts, we need the right prompts to guide us. Methodologies often help to accomplish this.
Several methodologies and tools are used for threat modeling. One popular and widely used methodology is STRIDE. I will be following STRIDE for our discussion here.
STRIDE stands for:
Spoofing
Tampering
Repudiation
Information disclosure
Denial of service
Elevation of privilege
The above are familiar terms in cloud and security engineering. In the second part, I will expand on them further and show how they enhance the modeling process.
With this super-simplified threat modeling overview, let us shift our focus to serverless.
Security Misconceptions in Serverless
Engineers who begin their serverless journey without a clear understanding of the cloud and its protective measures are taking a shortcut. It may sound harsh, but this lack of knowledge can become a concern when building secure solutions.
I have encountered developers who write and deploy lambda functions without a clear understanding of the shared responsibility model. Often, they don’t know the meaning of the principle of least privilege. Such situations need improvement.
Yes, it is understandable that there are such awareness gaps among engineers.
True, there are no servers for engineers to manage in serverless.
True, the operating system and updates are taken care of by the cloud provider.
True, a fully managed service is managed by the vendor.
However, it is not true that everything in a serverless application is the cloud provider's responsibility, so it is secure.
Shared responsibility model for serverless
As the following diagram depicts, even though AWS’s responsibility extends further up, there is still a significant portion left for us as serverless engineers to be responsible for.
When it comes to our responsibility in serverless, it is not just about protecting the service boundaries. Resources and other entities that are very much inside these boundaries also require adequate attention.
Here, threat modeling helps us widen our thinking to arrive at a better-architected solution.
Common Best Practices
Teams engaged in building serverless applications are already following several best practices. They use these practices regardless of their familiarity with threat modeling. This is admirable and lays a strong foundation.
We follow the principle of least privilege. It guides us to build resources with the required permissions to perform their tasks.
For example, if a lambda function queries a DynamoDB table, it only requires “read” permission on that table.
We implement data protection, such as data encryption in transit and at rest.
For example, while storing an object in S3, we configure the appropriate encryption strategy, whether server-side, client-side, or custom.
We sign messages and verify the signature upon receipt of the data.
For example, we use hashing algorithms such as SHA-256 while receiving data from partner SaaS applications.
We secure APIs and authenticate the client before authorizing the client to use the service.
For example, we use Amazon Cognito to manage API clients and their scopes.
We put API quotas and rate limits in place to control the flood of unsolicited calls.
For example, with AWS API Gateway, we can configure usage plans and throttling limits.
In addition to these, teams adhere to several other best practices as part of their serverless development standards and procedures.
Is There a Need for Threat Modelling?
If we already follow the best practices, is there a real need for threat modeling?
To answer this question, let me bring the AWS well-architected framework and serverless applications lens to our discussion.
As you may be aware, the serverless applications lens is a collection of checklists to evaluate the serverless architecture. They are categorized into six pillars, as below:
Operational excellence
Security
Reliability
Performance efficiency
Cost optimization
Sustainability
While the serverless applications lens stays at a higher level, with several checkpoints to make sure the application is well-architected, threat modeling, on the other hand, goes a level deeper.
Keeping the architecture as the base, threat modeling guides us to:
identify the potential threats to the different parts of an application,
analyze the possible mitigation plans for each threat, and
take appropriate actions to protect the entire application.
In essence, threat modeling makes the application very well-architected.
Threats Inside Your Security Boundary
Traditionally, when we speak of application security, we mainly think of protecting applications from outside threats. Of course, this is important for well-known reasons. However, parts of a serverless application inside this security boundary still require protection from threats.
Example threat cases
You have a service that generates discount coupon codes. These codes are stored in a database for distribution to your customers.
As part of your design process, do you usually think:
Who needs access to this data store and why?
How do you know someone has accessed this data store?
2. Your application processes the medical records of thousands of people for research purposes.
As you architect the solution, do you always think:
What data is logged, where are the logs sent, and who can access it?
What happens to the processed records? How long are they retained, and for what purpose?
Privacy by design
Privacy by design (PbD) is an increasingly popular approach that many organizations are adopting. One of its primary purposes is to prevent information disclosure.
Similar to how security by design (SbD) is strongly associated with the principle of least privilege, when it comes to personal data, one of the core principles of privacy by design is data privacy by default.
Threat modeling allows you to bring such data visibility and information disclosure issues to the forefront so that you can identify and take the appropriate actions.
Regulatory bodies and compliance
Every serverless engineer is not expected to know the different regulatory bodies and their compliance documents. However, if we incorporate the necessary policies into the architecture and solution design, they become transparent during implementation.
Complying with PCI DSS, GDPR, HIPAA, and similar laws and standards will raise threat analysis questions such as the following:
How do you prevent someone from deliberately tampering with the payment data?
How do you ensure customer data does not leave a restricted country or continent?
How do you protect people's individually identifiable health information?
Developing serverless applications for our modern, data-driven lives has many challenges. If not addressed and prevented, the consequences can be extremely severe for the business. Hence, better processes, such as threat modeling, are needed to identify and act in advance.
Continuation
Threat modelling has been used for a long time. In serverless, it can be considered an extension of the best practices we already have.
Threat modeling helps improve our solution to protect the business and its customers. Beyond the economic benefits of serverless, its acceptance, adoption, and success also heavily depend on these core principles.
In the next part, we will see how to structure the threat modelling process. This will include ways to identify threats, document them, and take corrective actions.