Monitoring

Serverless
Architectures
in AWS

The introduction of serverless architectures is a positive development from a security perspective. Splitting up
services into single-purpose functions with well-defined inputs and outputs helps reduce exposure to many types
of threats. However, the security of serverless architectures is an under-studied topic. Many practices and tools
available in more traditional architectures don’t apply.

This document will discuss methods of auditing and monitoring of AWS Lambda functions—a key component of
serverless architectures in AWS — and how Cisco® Stealthwatch Cloud puts these methods into practice.

Lambda security topics

• Access to the function: Who or what can modify or invoke a function?

• Access from the function: What can the function access when it is running?

• Unintended behavior: Can the function be made to do something unexpected?

For each area, there is a question of auditing, or looking to see whether configurations match
expectations, and monitoring, or keeping track of activities on an ongoing basis.

© 2017 Cisco and/or its affiliates. All rights reserved.

Contents Auditing
The AWS Lambda documents describe how to use the AWS Identity
Lambda security topics and Access Management (IAM) API and Lambda API for auditing
Auditing policies related to function access. It’s important to audit policies
Monitoring periodically to check:

Extending monitoring • Whether some policies are outdated. For example, they made sense in the
with VPC Flow Logs past, but haven’t been updated to reflect changes (for instance, a user
who has since moved to another team still has rights to change an Amazon
Stealthwatch Cloud Lambda function’s code)
integration • Whether some policies allow access to more resources than necessary
(for example, an Amazon Lambda function that can write to any Amazon
Conclusions and
Simple Storage Service - Amazon S3 bucket
recommendations
The AWS IAM API can be used to show which users (or roles) in an AWS
account have the ability to change a Amazon Lambda function or its
configuration. For example, we could query the AWS IAM API to see
who has the Update Function Code permission. This would show who is
allowed to change the code a function executes. The Amazon Lambda
API can be used to show who (or what) is allowed to invoke a function.
It’s common to allow other AWS services like Amazon S3 or API
Gateway to call a function. An example of something to look for would
be cross-account access for Amazon S3. Note that the AWS documents
provide this warning for this problem:

“If you add a permission for the Amazon S3 principal

without providing the source ARN, any AWS account
that creates a mapping to your function ARN can
send events to invoke your Lambda function from
Amazon S3.”

The Amazon Lambda and AWS IAM APIs together can show what an
Amazon Lambda function is allowed to do. For example, to see what
permissions a particular Amazon Lambda function is granted (for
instance, writing to an Amazon S3 bucket), you can use the Amazon
Lambda API’s GetFunction call. That will help you determine which role
to look up with the AWS IAM API.

Monitoring
The Amazon Lambda documents describe how to use AWS CloudTrail
and Amazon CloudWatch for monitoring.

AWS CloudTrail tracks API activities. We can use AWS CloudTrail logs to
look for changes to functions (for example, the UpdateFunctionCode call
described above) as well as changes made by functions. This helps keep
© 2017 Cisco and/or its affiliates. All rights reserved.
track of access between audits.
White paper
Cisco public

Amazon CloudWatch Logs track function invocations and Once the ENIs and IP addresses are known, an Amazon
their output. This can be used for billing purposes Lambda function’s activity can tracked using VPC Flow
(they include information about duration and memory Logs. These flow logs describe all of the communication
usage, which are part of Amazon Lambda pricing) as to, from, and within a VPC, so if a Lambda function
well as for monitoring purposes. For example, a function interacts with an internal resource, the associated
can be made to write its input to the log, which could be network activity will be logged.
used to help look for injection attacks.
Furthermore, Amazon Lambda functions need to use a
Amazon CloudWatch Metrics also track function usage, Network Address Translation (NAT) instance or VPC
such as the number of invocations, the duration of each NAT gateway to gain Internet access. This means their
run, and other metrics. Manual alarms can be set for Internet activity will also go through the VPC and be
things like excessive invocations. This can be used to logged as flow log records.
monitor for unintended behavior and abuse. For
example, if the function can be invoked from the outside, This level of detail helps answer other security questions
an alarm could show whether it is being abused and about Amazon Lambda. More types of unintended
wasting resources. behavior besides function invocation and API calls can
be tracked. The effects of something exotic like
Extending monitoring with VPC Flow Logs container escape (a breach of the environment that runs
The auditing and monitoring resources described in the function) could be detected if it was followed by
the AWS documentation help answer some of our access to VPC resources.
security-related questions, but miss some others. For
example, it would be difficult to use the services above
to determine whether an Amazon Lambda function is
Stealthwatch Cloud integration
accessing an internal Amazon Relational Database Cisco Stealthwatch Cloud uses each of the resources
Service (RDS) or Amazon ElastiCache instance inside a described above to track Amazon Lambda functions.
VPC. VPC Flow Logs allow monitoring of Amazon Lambda
functions with Stealthwatch Cloud’s entity modeling
We can get more detailed monitoring of an Amazon service, which helps to enable a wide variety of security
Lambda function activity by understanding how functions alert types. The screenshot below (from the
communicate. As the AWS documentation describes, Stealthwatch Cloud web portal) shows a set of VPC
Amazon Lambda functions are allocated temporary Flow Log records for a Amazon Lambda function
Elastic Network Interfaces (ENIs) and IP addresses when accessing an Amazon RDS database running MySQL.
they need to communicate with a VPC resource. These
ENIs can be enumerated with the Amazon Elastic
Compute Cloud (EC2) API and matched to the
requesting Lambda function.

© 2017 Cisco and/or its affiliates. All rights reserved.

Amazon Lambda functions are tracked by name, so as they change ENIs and IP addresses,
their activity will be updated:

Amazon Lambda functions are good examples of static devices, or entities that express a very narrow set of
behaviors. This makes identifying even subtle changes that may indicate a security concern possible. The screen-
shot below shows an alert for an Amazon Lambda function that normally connects to two internal resources
connecting to an unexpected third.

The Stealthwatch Cloud service also reads from AWS CloudTrail, so if an Amazon Lambda function executes an
unusual API call (due to code injection, for example), that can generate an alert.

© 2017 Cisco and/or its affiliates. All rights reserved.

Additionally, Stealthwatch Cloud polls CloudWatch metrics, so if the function is invoked, many more times than normal
(due to abuse from the outside), that would generate an alert.

The normal level of invocations is determined automatically, so a user doesn’t need to specify what the expected
invocation rate is.

Conclusions and recommendations

In this white paper, we have:
• Described the standard tools for auditing and monitoring Lambda function security— the Amazon Lambda and IAM
APIs, AWS CloudTrail, and Amazon CloudWatch.
• Explored details of how Amazon Lambda functions access internal resources to discover another way to monitor
behavior (VPC Flow Logs).
• Explained how Stealthwatch Cloud uses these tools to help enable entity modeling-based security alerts.
There are some simple steps Lambda users can take to improve their security stance with standard tools:

• Auditing: At the very least, use the AWS Console to look through the list of the Lambda function’s execution roles
and triggers. Check whether any seem overly broad (for instance, allowing Full Access to some service like Amazon
S3) and set a reminder to do the same again in three months.
• Monitoring: Set up some Amazon CloudWatch metrics alarms for any Amazon Lambda functions that react to
outside (such as untrusted) input. This will let you know if resources are being wasted, or if there was some latent
behavior in the function’s code that’s now being expressed. Set a reminder to do this for new functions.
Amazon Lambda is a serverless compute service that runs code in response to events and automatically manages
the underlying compute resources.

Monitoring Amazon Lambda functions is included in the Stealthwatch Cloud entity modeling service. If you’re using
Stealthwatch Cloud already, you can make sure that the Stealthwatch Cloud policy for your account is up-to-date
since this will let it use the AWS APIs for Amazon Lambda monitoring. If you’re new to Stealthwatch Cloud, you’ll be
able to check on Amazon Lambda function activity shortly after you initiate monitoring.

For more information, please view Stealthwatch Cloud in the AWS Marketplace, or visit us at [Link]
stealthwatch-cloud

© 2017 Cisco and/or its affiliates. All rights reserved. Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of
Cisco trademarks, go to this URL: [Link] Third-party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (1110R) C11-739854-00 10/17