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):
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.
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.
Posts
0 comments:
Post a Comment