Serverless is generating significant interest and hype, backed up by real-world adoption, and creating a need for better security controls. I’ve been working with our customers to create the right approach and tooling to protect their FaaS environments ,and from this research, given the extremely short duration of function execution (in many cases, sub-second) and their external triggering, adopted the approach of focusing on mitigating risk in serverless using preventative measures that precede the execution of a function, then monitoring its behavior as the second layer of defense. Several common security baselines are available in the community, such as the OWASP Serverless Top 10 Project listing the most common serverless security threats and techniques for their identification and protection, as well as Serverless Goat and DVSA, both open source projects that offer vulnerable serverless applications to help developers better understand serverless application security in a controlled environment.
In previous releases of Aqua we focused on assessing the risk posed by functions, now we’ve expanded into mitigation while adding many additional check points. The new version of Aqua Serverless Security gives our customers enhanced protection of their applications without the need to embed our solution into their application source-code, eliminating conflict with developer teams and added complexity or cost.
Let’s take a quick look at what’s new in Serverless Security in Aqua 4.0.
CI/CD Pipeline Scans
Just as in containerized environments, we advise our customers to start their security journey in the CI/CD phase, in order to prevent risk in functions even before they are uploaded to the cloud. To achieve this, we developed a native serverless function scanning tool that can run in any CI/CD environment and provides developers the needed information about vulnerable packages, dependencies, or any access keys and cloud account credentials left in their code unprotected. We also created native plugins for popular environments ( Azure DevOp and Jenkins) to simplify usage, improve visibility and enable actionable results.
An example of a build failure due to security risks
To mitigate an applicative attack that exploits vulnerabilities in the function’s code, our risk assessment scans vulnerable packages or dependencies in the code. We perform this scan periodically to ensure that even newly discovered vulnerabilities will be detected, as well as changes made directly to the functions. Below is an example of the function vulnerabilities screen:
However, mitigating application code vulnerabilities is not enough. Aqua’s risk assessment verifies that the function code and environment variables don’t contain unencrypted sensitive data or account credentials (access/secret keys). Shown below is a function using AWS access keys in its environment variable:
Permissions are a critical component in the serverless security playbook and one of the major risks that require attention. Aqua verifies that functions run without excessive permissions in order to enforce the use of least-privilege roles. To achieve this, the risk assessment verifies that functions don’t use known roles such as “Owner” (Azure AD) or “Administrator Access” (AWS). It also verifies that services are defined explicitly, without any wildcards that grant broad access to multiple resources. Furthermore, in AWS we analyze the function’s activity and the resources it consumes, to further refine the IAM policies and remove services that were part of the role but are not in use. Removing those services minimizes the damage potential without sacrificing the function’s intended activity:
Still, removing vulnerabilities, sensitive data and excessive permissions is important but not sufficient on its own. We want users to feel safe, and to that end we also monitor function activity to identify anomalies that might indicate malicious activity. Monitoring function activity, correlating the frequency of invocation and the duration of each invocation, and frequent execution errors could indicate that the function has been tampered with.
Security Governance
To allow security teams to verify that developers are following their guidelines, are not uploading code that violates the organization’s security policy, nor changing functions beyond the scope of the security policy, we added the Function Assurance mechanism. Our Function Assurance periodically scans all stored functions to verify that they are aligned with the organization’s policy, to ensure the functions’ integrity, and ensure that no new vulnerabilities affect the functions that are already in use. We allow the admins to determine whether a violation would only trigger a notification on the policy violation, or in severe cases, prevent the function from being invoked (“block” the functions), thus eliminating the risk.
The results of the Function Assurance policy can be seen in this unified view:
Mitigating Risks in Serverless
As we’ve seen, serverless functions in FaaS environments present some unique security challenges. The sprawl of numerous functions across cloud accounts on the one hand, coupled with event-driven, very short execution durations, make this a unique environment that share some traits with containers, but on the other hand is quite different especially from the runtime aspect. On the positive side, the extremely short runtime duration and relatively small code footprint also make it harder for attackers to take advantage of functions or persist in their attacks.
The right approach to mitigating risk in serverless must therefore focus, as much as possible, on preventative measures that precede the execution of a function, as well as monitoring the function to detect anomalies. It provides guardrails for running functions bound by acceptable risk policies, as well as the controls to detect and prevent violations. As part of the Aqua Cloud Native Security Platform, security and DevOps teams can enforce this risk-based approach on their entire cloud native stack.