This technical deep dive highlights key capabilities released as part of Twistlock 18.11. To learn more about what’s included with Twistlock 18.11, check out our full release blog post.
As cloud adoption continues to grow it is no surprise that the use of serverless capabilities from the leading cloud providers has seen a steady uptick as well. Every year more enterprises are planning to adopt serverless as part of their cloud strategy, and we feel like making sure that enterprises use serverless functions securely is of paramount importance. As such, as part of our newest release, Twistlock 18.11, we wanted to make sure we enhanced the capabilities of our serverless protection which we began pursuing in Twistlock 2.3 in January of this year. Our previous Serverless Defenders supported process protection, but our updated Serverless Defenders v2 which are available for AWS Lambda expand this capability with much more functionality.
Why your serverless functions need protection
Serverless computing allows you to focus squarely on your code while the cloud provider focuses on the execution and scale of that application. You pick one of the supported runtimes, and the cloud providers handle the rest. While this can undoubtedly ease operations, you still do have new questions that emerge from a security perspective.
For example, if you currently utilize traditional Linux security features and toolsets, you do not have those available to monitor the application. Additionally, the security model for privileges is entirely different from a traditional containerized or virtualized deployment model. This difference in privileges is also real for any would-be attackers and can, therefore, lead to new considerations for your threat model.
To overcome some of the security limitations around serverless deployments, we created the Twistlock Serverless Defender which can be embedded directly into the zip file that you upload to AWS to protect your function. In our latest release this month, we expanded these capabilities to include expanded auditing, Defender tracking in the Console, domain resolution blocking and alerting, integration with Twistlock Incident Explorer capabilities for crypto miner detection, and a new simple process of creating a protected function directly from the console.
A deep dive with AWS Lambda
Let’s get started by creating a new runtime policy that we would like to have applied to our new Lambda function. In this example, we want to try out the new protections offered by restricting the DNS lookups that our Lambda function can make to example.com.
In the example screenshot below, I’ve added a new Serverless Policy for runtime by navigating to Defend > Runtime within Console.
When adding a new policy, we also can restrict the processes that are run to just the defined process and also can prevent our function from executing known crypto miners.
This policy is now ready to be enforced against our function that we will be exporting into AWS Lambda. To do this, we need to generate our protected Lambda function which is now available within the Twistlock Console UI.
Deploying a Defender for our function is as easy as taking an export of your Lambda function as it exists from AWS, and using the Twistlock Console to create a new protected function. You can see an example of this process in the screenshot below. After selecting the Serverless Defender type from Manage > Defenders > Deploy window within Console, we can easily upload our exported zip to the UI and create an embedded zip of our protected function to take to AWS. Both Python 3.6 and NodeJS 8.10 functions are supported in this release.
After uploading our new function, we can run a test of our function and see our protection take effect as soon as it’s first instantiated. In this case, we have a clear view of the process and network protections that we have enabled as part of our runtime policy. We get a clear view of this within our Serverless Audits section of the Twistlock Console. Over a series of tests, we can see that audits were produced to indicate both alerting and blocking based upon the policy that we configured.
We can also see within the AWS console that the return code from the function does not correspond with successful execution due to the connection block for the requested URL. As for the function itself, we can see that the appropriate Twistlock certificates have been added to the function to ensure secure TLS connections back to Twistlock for Audits and Defender tracking in the console.
Our Serverless Defenders update provides expanded capabilities for protecting your serverless functions in AWS Lambda. Going beyond process protection to also include network protection helps to mitigate another one of the significant threat vectors that serverless functions face. Also, the ability to quickly deploy this capability directly from the Twistlock UI in addition to our twistcli command line utility provides ease of use for protecting your functions to ensure that it is not a burden to secure your services.
Learn more about Securing Serverless with Twistlock
To learn more about securing serverless, read more about Twistlock serverless security.
Or, watch this CNSP podcast on securing Lambda, below.
Follow us on Twitter
Follow us on Twitter for real time updates on the cloud native ecosystem, Twistlock product, and cloud native security threats.
How to Lock Down the Kernel to Secure the Container HostRead the Blog
One Chapter Ends, Another BeginsRead the Blog
The Greatest Security Risks Lurking in Your CI/CD PipelineRead the Blog
Cloud Platform Radar: Powerful Cloud Asset IdentificationRead the Blog
Securing Serverless Functions: Visibility with Serverless RadarRead the Blog