Cisco Blogs
Share

Serverless Security for Public Cloud Workloads with Stealthwatch Cloud


March 22, 2018 - 2 Comments

[This post was created with contributions from Bo Bayles and Patrick Crowley.]

Each year goes by and we find more ways to own less and less of what it takes to operate our digital infrastructure. Information Technology began as a business having to build data centers owning everything starting with the real estate all the way to the applications, quickly it moved to public clouds whereby the infrastructure itself was a service managed by the provider and you only needed to manage the virtual servers up through your applications. The latest in this trend is serverless computing.  As you would guess, this is the latest evolution where the service provider owns and operates everything up to the application and you don’t even manage the servers running your code (thus the name “serverless”).

Businesses absolutely love serverless computing because of the reduced IT administrative burden (“Look Mom, no servers to administer!”) and the cost advantages that come with precisely matching compute spend with demand.  However, with this delegation of control to the service provider you are also delegating the detection, mitigation, and remediation of threats. How do you install security controls on the server when there is no server? Fear not my cloud-native digital business, Cisco Stealthwatch Cloud has got your back and if you have five minutes, we can explain how it works.

Stealthwatch Cloud is able to detect threats and threat actor behaviors in serverless environments because it is not dependent on agents running on servers. Stealthwatch Cloud detects threats and triggers remediation by modeling the behavior of the entities active in your public cloud workload—whether they are servers managed by you, virtual appliances managed by your service provider, or serverless compute functions—by consuming the logs and telemetry provided natively by the infrastructure itself. Here’s how it works in Amazon Web Services (AWS):

Monitoring Lambda

As the name “serverless” implies, AWS Lambda functions do not have dedicated IP addresses. Instead they are allocated temporary network interfaces (ENIs) and IP addresses when they need to communicate with a VPC resource. This makes manual monitoring and correlation difficult as a Lambda function is assigned various IP addresses over time.

But with AWS VPC Flow Logs, an import form of native telemetry available in AWS, and Stealthwatch Cloud, you can automatically correlate these IP addresses and track Lambda functions over time. ENIs can be enumerated with the EC2 API and matched to the requesting Lambda function, and once the ENIs and IP addresses are known, a Lambda function’s activity can tracked using VPC Flow Logs. Stealthwatch Cloud uses these resources to monitor Lambda functions for abuse.

Lambda functions are tracked by name, and their various ENIs and IP addresses are tracked and updated automatically.

Lambda functions are often “static,” meaning they exhibit a narrow set of predictable behaviors. This makes them a perfect candidate for security analytics, as even minor changes that may indicate a security concern are detectable. In the example below, the RDSQueryLogger Lambda function usually only connects to two internal resources, but it is observed connecting to a third resource.

Stealthwatch Cloud also makes use of CloudTrail logs, which can help detect other kinds of behavior. If a Lambda function executes an unusual API – due to code injection, for example – Stealthwatch Cloud will generate an alert.

Stealthwatch Cloud also polls CloudWatch metrics, which can help identify excessive invocations due to abuse from the outside.

What’s next?

In some cases, the natural next step after a Lambda-related alert can be automated. For example, if a Lambda function begins beaconing out to an untrusted Internet destination, it is possible to block that remote destination from communicating with any of your AWS entities or API endpoints. Here’s a blog post on this very topic, including all the source code and instruction you might need to try it yourself.

Serverless computation is an extremely useful service, and it comes with several security benefits and challenges. With Stealthwatch Cloud, you can quickly identify security risks involving your Lambda resources. Monitoring Lambda is included with Stealthwatch Cloud – you just have to enable it.

If you do not have Stealthwatch Cloud, you can try it free for 60 days. For more information, please view Stealthwatch Cloud in the AWS Marketplace, or visit us at http://cisco.com/go/stealthwatch-cloud

 

Glossary

AWS CloudTrail: AWS service that provides API event history and logs of your AWS account activity.

AWS CloudWatch: AWS service that provides log monitoring of AWS resources and delivers metrics such as CPU utilization, latency, etc.

AWS Elastic Compute Cloud (EC2): An AWS service that provides server-based compute capacity in the cloud.

AWS Elastic Network Interface (ENI): An AWS resource that is a logical networking component in a VPC that represents a virtual network card.

AWS Lambda: AWS serverless compute service that allows you to run code without provisioning or managing servers.

AWS VPC Flow Logs: AWS services that provides network flow metadata about IP traffic going to and from network interfaces in your VPC.

Serverless Computing: A service that allows you to build and run code without provisioning or managing servers.

 

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

2 Comments

  1. As u mention functions are not monitored via VPC Flows by default so what are the chances and reasons developers would decide to do this?

    • Bill, I'm not quite sure I understand your question the way it is phrased but I'll take a shot. The reason developers or devops would decide to monitor this form or telemetry is the same reason they choose to monitor all other forms of telemetry pertaining to the integrity, security, and performance of their system. The main point we are making here is that with serverless, it is necessary to find the appropriate telemetry (no way to install an agent on the server) and deliver the right analytical outcome. hope that helps address your question.