Less Is More

Now that the basics have been covered, it's time to set up a working example of how a serverless function can be protected by Prisma Cloud Compute. The runtime protection and the vulnerabilities and compliance protection are run separately within Prisma Cloud Compute, as mentioned earlier – partly, I suspect, because this functionality is fairly new and partly because it makes logical sense. Soon you'll see how they slot together from the Console perspective.

As an example, I have a simple Lambda function written in Python that will perform a DNS lookup of devsecops.cc (Listing 1). To begin, I set up the vulnerabilities and compliance protection, leave it to run a couple of scans, and then return to it in a little while. In reality, the Lambda functions in my AWS account aren't too complex and don't change much over time, so the initial scan results aren't going to change. However, it should convey that this functionality involves automated periodic scans once credentials are added to the Console and is separate from the runtime protection.

On AWS you'll need to add your own security credentials for this task by creating an Access Key and Secret Key in Identity and Access Management (IAM). In Prisma Cloud Compute, go to Manage | Authentication | Credentials Store (Figure 8). Although IAM roles are supported, an IAM user account is used for scanning all regions.

Figure 8: Create some creds just for the serverless Vulnerabilities and Compliance section.

Listing 2 is a redacted set of IAM permissions that essentially just lists and describes resources in an AWS account and aren't too invasive. Check the policy carefully before creating such a policy, however, and attach them to a user who has Programmatic access to the account. These permissions allow Prisma Cloud Compute to discover any AWS Lambda functions present within an account and then scan them for vulnerabilities and compliance. A word of warning is to click Save twice after creating the rule, not once.

Figure 9 shows the Console Defend | Vulnerabilities | Functions screen for adding a scanning rule that will set up the AWS account for serverless functions. In this case, the asterisk will pull in all functions, of any name, up to a Cap (limit) of five functions.

Figure 9: Scan up to five functions of any name (asterisk) with the previously created credentials.

After a quick test to make sure my test Lambda function (the simple Python test script in Listing 1) executes correctly, the next stage is to create a ZIP file of the refreshed function that includes the Prisma Cloud Compute files. (Support for other popular runtimes now includes Java, Node.js, and .NET.) To do so, first export the Lambda function and then save it as a ZIP file locally. The next task is to plug in the Prisma Cloud Compute library and certificates generated from the Console (these certs are unique to this Console).

01 import socket
02
03 def handler(event, context):
04   data = socket.gethostbyname_ex('devsecops.cc')
05   print (data)
06   return

{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": [
"apigateway:GET",
"cloudfront:ListDistributions",
"elasticloadbalancing:DescribeListeners",
[...snip]

From Manage | Defenders | Single Defender | Option 2-Serverless | Python , you can download the ZIP file from the Console (or via the API), extract the files from that compressed ZIP file, and add the code that performs DNS lookups after the Prisma Cloud Compute wrapping code (Listing 3). Save the file as function.py. Make sure the twistlock/ directory contains all the code from the Console's ZIP file and your function code is at the upper level; then, compress all the files into a new ZIP file. Next, import that new ZIP into AWS as the Lambda function's new payload, first making sure the handler is pointing at the correct place.

01 import socket
02 import twistlock.serverless
03 @twistlock.serverless.handler
04 def handler(event, context):
05     data = socket.gethostbyname_ex('devsecops.cc')
06     print (data)
07     return

Now that the freshly zipped Lambda function has been imported, you can run it to generate some logs. If the Console does not enforce any rules from CloudWatch logs, the DNS lookup will be successful.

As you might guess, the next test is applying a rule from the Console that matches the function's name (asterisks to cover all names are permitted here, too). To add rules to a Lambda function, you need to create an environment variable in the AWS config.

The environment variable for Prisma Cloud Compute uses a key called TW_POLICY and a Base64-encoded set of rules (coming in at around 24 lines) that deal with the network stack, process table, and filesystem of serverless functions (mostly with block/alert and whitelist/blacklist options). It's very clever in its simplicity. Other useful additions include detection of crypto mining and the ability to monitor and potentially block certain DNS lookups. By default, only the main process will be allowed to execute; other processes are blocked, which apparently helps to mitigate against command injection attacks.

In Defend | Runtime | Serverless Policy , you now create a rule (Figure 10) that alerts on devsecops.cc lookups. Figure 11 shows what CloudWatch says when the Lambda function is invoked again, now having pasted the environment variable details into the AWS configuration. The line to pay attention to is:

Figure 10: The Lambda function does not welcome any DNS lookups with *.devsecops.cc.

Figure 11: Good news: The rules are working and sending alerts about unwanted DNS lookups.

[Twistlock] (ALERT) /var/lang/bin/python3.7triggered a DNS resolution ofsuspicious name devsecops.cc

With the correct plumbing in place, this runtime protection data will feed back to the Console for analysis and easier digestion. A handy tip is that if you are using a Console in EC2 and want to forward data back from Lambda functions to the Console, you should attach the Lambda function in question to a virtual private cloud (VPC), a private subnet, and a security group with suitable permissions. From within the private subnet, add a network address translation (NAT) gateway, which is the AWS-recommended way of speaking securely and internally to non-public instances from AWS Lambda.

Feeling Vulnerable and Non-Compliant

Now that you know runtime protection works, go back to your Console and check that the serverless vulnerabilities analysis and compliance functionality is working with the user and policy added earlier (see Figure 8 and Listing 2).

If you look at Monitor | Vulnerabilities | Functions (Figure 12), you can see that all five Lambda functions received the all-clear for known vulnerabilities. It's not uncommon to see payloads with older libraries triggering alerts to remind you to patch and update your Lambda functions, as well as your other software.

Figure 12: The five Lambda functions get the all-clear.

When checking the compliance of the five discovered Lambda functions, the results for the prisma-dns-lookup function created for the runtime protection example registers a high alert (Figure 13). The certificate key used to communicate back to the Console, which was analyzed from inside the ZIP file payload uploaded in the runtime protection example, has been flagged as the issue.

Figure 13: Having secret keys inside a Lambda function isn't wise. In this case, that's okay, though, because Prisma Cloud Compute knows what it's doing.

Inside another Lambda function, Prisma Cloud Compute is flagging a number of other useful issues that would have almost certainly been missed otherwise (Figure 14). One problem is a potential denial-of-service risk because of permissions that allow EC2 instances to be stopped and started. Additionally, other permissions – such as being allowed access to AWS Systems Manager (SSM), which can wield all sorts of power within an AWS account – might cause headaches.

Figure 14: Not all is well within one of the Lambda functions.

After seeing the three areas of serverless protection provided by Prisma Cloud Compute, I hope you can see the power serverless protection brings to an estate when used in tandem with Host Defenders that protect and monitor your host machines and Container Defenders that inspect the innards of your containers. Along with a range of other impressive features, to my mind it's an invaluable product when you consider how expensive a security compromise to both online and offline services can be.

The End

As pioneers of the container security market, Twistlock – now Prisma Cloud Compute Edition – has matured into an exceptionally comprehensive security suite. This space moves quickly, so the occasional crinkle can appear when new features are released. However, the ability to improve the security posture of all cloud-native components and integrate them into one security suite is difficult at the best of times.

Notice that I didn't look at the continuous integration-continuous delivery options that are available to users who want to plug their builds into Prisma Cloud Compute. Needless to say, the security suite considers the whole DevSecOps life cycle. A (slightly outdated) document [7] can give you an idea of how the Jenkins plugin works, for example. A binary called twistcli also allows the scanning of data, and you can find more information about tracking "… vulnerability findings for each build, in each layer, and whether the function or image passed or failed …" [8].

You can explore the Prisma Cloud Compute SaaS version in more detail by requesting a demo from the main website [9].