Over the course of a few years, enterprises have been exploring serverless technology for application development, system automation and a host of other use cases. After initial research and experimentation on smaller projects, companies are now realizing the viability of the serverless model for their core, business-critical workloads. Serverless technology is being adopted by enterprises at a rapid rate. According to surveys conducted by serverless.com, “67% of enterprise respondents said that serverless was either ‘critical’ or ‘important’ for the work they did at their jobs.” Sumo Logic says that the adoption of serverless architecture continues to grow among their customers, reporting, “one in three enterprises use AWS Lambda technologies.”
One of the foremost drivers for this adoption is the economic savings derived from the consumption-based pay model. Other business benefits afforded by serverless architectures include reduced operational overhead and faster time to market. Serverless architectures take full advantage of the managed platform services, eliminating the cost and overhead associated with operating infrastructure components within classic cloud application models. (Yes, we now call non-serverless applications “classic”!). Simply put, serverless allows companies to get to their business value faster, with less time spent on “plumbing” and more on core business functionality.
But — there is always a “but” — with all these savings and productivity gains come a new challenge: how to secure those serverless applications. The technology is relatively new, the architecture has its own nuances and complexities and, if adoption is not properly managed, sprawl can become an issue and security may suffer.
Challenges to serverless security range from the increased attack surface to the complexity of the attack, to the overall intricacy of the system itself. Also, as we will discuss further, some traditional security controls simply are not applicable or suitable for serverless. Do not panic — we can get through this!
As serverless adoption is beginning to grow and become widespread in the organization, our enterprise clients are faced with some key questions from management: “Great, we see all the benefits of serverless, but how do we make sure we implement it securely?”; “How do we maintain our security posture?”; and, “How do we maintain compliance?!”
Our intent in this white paper is to guide you in thinking about securing your serverless applications and services — to show you what has changed, what is more complicated, what has remained the same and what has become much simpler. Ultimately, we will show you how we build a structured methodology to secure serverless applications.
Lions and Tigers and Bears…Oh My
The Open Web Application Security Project (OWASP) lists the Top 10 Risks for serverless. These should not be considered the only potential risks, but for the purposes of this paper, the list serves as a good foundation to make our case.
The Top 10 Risks to Serverless Architecture, enumerated by OWASP:
- A1:2017 Injection
- A2:2017 Broken Authentication
- A3:2017 Sensitive Data Exposure
- A4:2017 XML External Entities (XXE)
- A5:2017 Broken Access Control
- A6:2017 Security Misconfiguration
- A7:2017 Cross-Site Scripting (XSS)
- A8:2017 Insecure Deserialization
- A9:2017 Using Components with Known Vulnerabilities
- A10:2017 Insufficient Logging and Monitoring
As you can see, the risks in this list are not unique to serverless technologies. They almost exactly overlap with the standard (“classic”) OWASP Top 10 Risks. However, serverless applications have an increased attack surface, due to a much larger set of input sources.
- SAS-1: Function Event Data Injection
- SAS-2: Broken Authentication
- SAS-3: Insecure Serverless Deployment Configuration
- SAS-4: Over-Privileged Function Permissions and Roles
- SAS-5: Inadequate Function Monitoring and Logging
- SAS-6: Insecure Third-Party Dependencies
- SAS-7: Insecure Application Secrets Storage
- SAS-8: Denial of Service and Financial Resource Exhaustion
- SAS-9: Serverless Business Logic Manipulation
- SAS-10: Improper Exception Handling and Verbose Error Messages
- SAS-11: Obsolete Functions, Cloud Resources and Event Triggers
- SAS-12: Cross-Execution Data Persistency
All these risks, as scary as they sound, are avoidable, with a structured way to identify and track the threat landscape, and proven mitigation methods. The threats themselves have not changed much; they are merely variations based on a theme that spans both classic enterprise and serverless architectures. So, how do you create a structured approach to addressing your serverless environment? Hopefully, the same way you secure everything else — by using a proven security model.
Response to Our Clients’ Needs
Our approach, in responding to client and technology needs, is to build a serverless cloud security model. This model considers: the top 10 critical risks to serverless architecture; function as a service (FaaS) / backend as a service (BaaS) shared responsibility; serverless tooling vendors’ contributions; our customers’ input; industry use cases; and our own security and architecture intellectual property. The goal is to enable a well structured, secure architecture, as well as to design and implement serverless applications.
Our serverless cloud security model is based on our security reference architecture (SRA), which is an extension of the CSA SRA.
Our model maps to SRA domains that are applicable to serverless architecture, and to those frameworks and standards detailed in the footnote.Our SRA enables enterprises to secure their serverless applications in a systematic and structured way. The SRA also facilitates tracking those applications against standards and regulations on the capability level.
Before diving into the abstraction of the serverless SRA, let us take a look at how the serverless shared responsibility model has evolved.
Changes to the Cloud Security Shared Responsibility Model
With the adoption of serverless technology, the cloud shared responsibility model has evolved. In general, responsibilities have shifted from the customer to the service provider. Look at how cloud service providers (CSPs) provide FaaS, and what they take as their responsibility from architectural, operational and security perspectives (Figure 1). The chart shows the resulting shared responsibilities between the application owner and service provider.
As an example, the platform and operating systems were formally the customer’s responsibility in the classic model, but in a serverless system they are taken care of by the CSP. This does not mean that the customer is not accountable for the security of their data and applications. It only implies that the provider has responsibility for more layers.
We utilize this model to identify the domains in our SRA that are the customer’s responsibility. Hence, clients must be accountable for positioning the required controls.
It is critical for customers in regulated industries to validate that the services and applications utilizing serverless technology comply with their regulatory standards.
Developing the Serverless Cloud Security Reference Architecture
Figure 2 shows the structure of one portion of the security and risk management (SRM) domain within the SRA. The total SRA consists of six domains:
- Security and Risk Management (SRM)
- Information Technology Operation and Support (ITOS)
- Business Operation Support Services (BOSS)
- Information Services
- Infrastructure Services
- Application Services and Presentation Services
Each domain is made up of a high-level, mid-level and low-level security capability. The low-level capabilities may have multiple controls applied to them. A small portion of the SRA is shown in Figure 2.
We analyzed all domains in the SRA, and identified capabilities that are either:
- Applicable to serverless
- Impacted by the technology
- Not applicable
The following illustrates how this analysis was performed:
- Applicable capabilities: In the Security and Risk Management (SRM) domain’s Privilege Management Infrastructure high-level capability, we found that all mid-level capabilities, such as Identity Management, Authentication Services, Authorization Services and Privilege Management, are applicable to serverless.
These capabilities are part of the controls required to address the Broken Authentication risk, ranked number two in both the OWASP and PureSec lists of top critical risks to serverless. We marked applicable controls to serverless as white, in Figure 3.
- Impacted by the technology: Impacted describes the way required controls are currently implemented, or how controls used for traditional classic applications do not function. We identified capabilities that are impacted by serverless technology and marked those as yellow, in Figure 4 below.
In the Threat and Vulnerability Management high-level capability, we find under Threat Management that the Source Code Scanning low-level capability has been “impacted.” Serverless fundamentally changes this capability. This may seem obvious, but traditional static/dynamic code analysis is not suitable for serverless applications.
Other types of scanning, such as dynamic application security testing (DAST), only scans the HTTP interface, while static application security testing (SAST) relies on data flow analysis, which would be too complex in serverless. Interactive application security testing (IAST), as well, is not useful when using non-HTTP.
- Not applicable capabilities: In the SRM domain’s the Infrastructure Protection Services high-level capability, we identified as “not applicable”the Server mid-level capability and Behavioral Malware Protection low-level capabilities. All these low security capabilities — HIPS/HIDS, Antivirus, File Integrity Monitoring, Sensitive File Protection, Whitelisting and Host Firewalls — are “not applicable” controls. In other words, these capabilities are not the customer’s responsibility, and are taken care off by the FaaS provider. We grayed those out in our SRA, as shown in Figure .
This example is mapped directly from the new shared responsibility model, shown in Figure 1, where the platform responsibility has been transferred from the customer to the FaaS provider.
From Abstraction to Implementation, Serverless SRA to Security Assessment Matrix
We map all domains in the serverless SRA (security reference architecture) into a security assessment matrix (SAM). The SAM is the implementation side of the abstract SRA. Instead of looking at serverless security as domains and areas, we look at it as capabilities. Those capabilities enable us to define the required technology and processes to secure the serverless application. We first break down the required and critical capabilities under those SRA domains. The more detailed SAM targets the design and implementation layers, rather than only the abstraction layer.
As an example, looking at the Privilege Management Infrastructure’s Privilege Usage Management low-level capabilities (Figure 3), we identified the Password Vaulting capability “applicable” for serverless, and proposed a solution, based on our experience, industry trends and vendor research.
Password Vaulting is also identified as one of the controls required to overcome the Broken Authentication threat (that OWASP and PureSec top risk).
Such work is performed across domains and capabilities in the SAM in order to define the corresponding solution or recommendation to implement serverless security. A subset of the SAM is shown in Figure 6.
Where the Rubber Meets the Road
Creating a pragmatic, well thought out approach to addressing serverless security will allow your organization to track changes over time, and build on a foundation where you have a historical reference point like the SAM. When the question of “why did we do it this way?” arises, there is a clear capability matrix that gives you an understanding of the thought process that arrived at the current implementation. So now that you have done the modelling, what does the implementation look like?
Let us examine the design patterns we can apply to implement a solution for some of the top OWASP risks, as shown in Figure 7.
- Before entering a business function, the event is handled by a security module, implemented using one of these methods:
- Wrapper function
- Lambda layer
- Annotation decorator (language/runtime dependent)
- The security module ensures that upon entry onto the system, all the inputs are inspected, recorded and encrypted.
- Proper inspection and validation of the input payload will provide mitigation for the top risks related to injection and event data manipulation (OWASP A1, A4, A7, A8; CSA SAS-1, SAS-8, SAS-9).
- Tracking invocations in CloudTrail and capturing event data through CloudWatch addresses the risk of insufficient logging and monitoring (OWASP A10; CSA SAS-5).
- The security module encrypts data using a key obtained from KMS, thus preventing the exposure of sensitive data (OWASP A3, CSA SAS-3, SAS-7).
- A Lambda function is assigned an execution role with a minimal set of permissions required for its functionality. This follows the security principle of least privilege, and mitigates risks related to access control (OWASP A5, A6; CSA SAS-3, SAS-4).
- Secrets, such as credentials, are stored in a Secrets Manager. This mitigates the risks of leaked and compromized credentials (OWASP A3, A6; CSA SAS-7, SAS-12).
- The security module sanitizes outputs generated by the business function before it gets stored or returned to the client, thus addressing the risks of reflecting or storing malicious data (OWASP A7; CSA SAS-1).
To manage the execution of the serverless model, we integrate each component into a design artifact, showing the integration and how to position the technological controls into a serverless implementation, as illustrated in Figure 8. This chart includes Data Protection and Identity and Access Management, as well as a DevSecOps component.
To illustrate, we laid out the appropriate controls that satisfy each risk area. Under Threat and Vulnerability Management, we grouped risks, such as Run Time Protection, Behavioral Analysis and Vulnerability Management, and positioned the appropriate control.
The result is both a high-level and low-level logical view of serverless security, which takes the abstracted contents of the capabilities matrix and details the roll out of each component in a simple to understand diagram.
As adoption of the cloud continues and matures, securing serverless applications is an inevitable requirement, as many enterprises are adopting this approach to their cloud applications.
The serverless security model is a well structured method for security professionals, serverless developers and architects to produce a secure design and implementation of serverless technology.
The SRA (security reference architecture) provides an easy way to communicate information to all parties, including executives, application owners, architects and developers. The SAM (security assessment matrix) provides a tool for the execution of the reference architecture, and the continuous assessment of your serverles implementation. The design artifacts provide ready-to-execute controls, specific to that platform.
Our serverless security model is based on a validated and battle-tested reference architecture. It integrates communities research, vendor toolings and recommendations into the entire approach.