In my previous blog, I discussed the serverless services spectrum and the unique security considerations of serverless functions. In this post, I’d like to elaborate on the importance of preliminary risk assessment checks and their contribution to an effective security strategy, based on lessons learned in containerized workloads environments.
Examining customer security strategies in containerized environments taught us at Aqua a valuable lesson. Unlike “classic” data-center security policies, when it comes to microservices deployments, risk assessment and risk mitigation policies are often given priority over runtime security controls. We were (initially) surprised by the weight given to image vulnerability scanning and to automated development pipeline tools. Continuous registry scans, as well as the insertion of security policies into automated image build processes (as in Red Hat OpenShift S2I) showed us the importance of adequate risk assessment and mitigation tools in the cloud native applications space. It makes sense – there’s no point trying to cover a huge attack surface, when it’s more effective to reduce it first.
Moreover, delivering effective security for serverless functions is challenging. Blocking remote-code-execution attempts without access to the functions’ hosts isn’t trivial. Sanitizing a function’s input without effective control on ingress traffic is challenging as well. To achieve an adequate security level of serverless functions while bypassing the inherent infrastructure challenges, we need to integrate security controls into the application code.
Adding a dedicated security binary or creating a secure “runtime” for each function can overcome the infrastructure challenge and provide a reasonable security level. However, such an approach is not “healthy” for operational hygiene. Code integration bears significant potential for conflicts between security and development teams. It impacts the function’s performance (longer execution time) or might delay their “cold-start” (first invocation), which is a challenge by itself. It may cause debugging and tracing challenges for the development teams. Moreover, in typical deployments many functions are used for operational tasks, not business logic or data processing tasks, and consequently require different security controls.
We therefore chose the path of developing a new and dedicated risk-assessment and mitigation offering for serverless functions. As explained in our previous blog, the risk in serverless functions stems from multiple elements, mostly in the application code or the cloud environment. The assessment must take place automatically and periodically without any dependency on, or integration into, the function’s code. It needs to provide visibility and constant assessment of the cloud environment, but without any impact on invocation or execution time. The outcome is a reduced attack surface of serverless functions, and isolation/highlighting of the functions that require additional protection of their runtime executions because preemptive threat mitigation isn’t possible (due to the importance of a specific library to the function, or due to the need to access sensitive data while enabling external user to trigger the Function, for instance).
Let’s take some real-life examples of Aqua’s risk mitigation for serverless functions. Our first stop is the AWS serverless applications repository, where people can contribute open source functions they created, for free and open use.
Opening the repository dashboard and selecting a few functions according to the “most deployed” classification reveals interesting results that demonstrate the need for rigorous risk assessment.
As we can see, several functions had security issues. Examining these findings reveals either overly permissive roles (e.g. S3*), or several medium score vulnerabilities:
We also found a few functions with an API gateway as their invocation trigger, indicating external access. We didn’t discover any function that had sensitive information (e.g., SSH keys or AWS tokens) hard-coded into it, which less common in open source libraries but is a highly recommended check for in-house developed functions.
With this information, application teams can mitigate issues before functions are used “in the wild”, and make more informed decisions on what constitutes acceptable risk vs. unacceptable risk.
We can clearly see that risk assessment and threat mitigation tools can increase the security posture of serverless users. Timely discovery of potential risk and automated mitigation options will significantly increase the security of serverless environments. Adopting a security strategy that identifies and mitigates potential risks prior to the insertion of runtime security controls, can improve the security posture of serverless-based applications.
Serverless risk assessment, along with many other new features, is part of Aqua CSP 3.5.
