Secure Serverless CI/CD with Codeship, PureSec, and AWS Lambda

When you develop, build, and deploy applications using a serverless architecture, you have no access to the infrastructure on which traditional security controls used to exist. This means that you cannot deploy any traditional security protections such as firewalls, intrusion prevention, web application firewalls (WAF), threat prevention, or even runtime application self-protection (RASP) solutions.

Nonetheless, serverless applications may contain application layer vulnerabilities, which may enable a malicious user to mount application layer attacks, such as SQL injection, cross-site scripting, or remote code execution. In addition, malicious users could tamper with or leak sensitive data by manipulating serverless function logic through business logic attacks.

PureSec provides an end-to-end serverless security solution and is the only Security Partner of AWS Lambda.

The PureSec solution can statically scan serverless projects for known vulnerabilities, over-permissive IAM roles, and security policies and insecure application secrets storage. The purpose of the static analysis component of the PureSec solution is to make sure that organizations build and deploy robust serverless applications.

In addition to serverless project hardening, the PureSec solution also provides a unique runtime application layer protection, which is capable of accurately detecting attacks or malicious behaviors and blocking them in real time.

Using a simple five-minute integration between the PureSec serverless security solution and Codeship's cloud CI/CD solution, customers can quickly and painlessly build, deploy, and test serverless applications with security baked in from the get-go.

PureSec's SSRE (Serverless Security Runtime Environment) provides a trusted and safe computing environment for secure serverless function operation, with the following benefits:

• Protocol agnostic: SSRE protects serverless functions from attacks coming in from any type of serverless event triggers such as:

  • NoSQL events (eg, AWS DynamoDB)

  • Stream processing events (eg, AWS Kinesis)

  • Code Repository changes (eg, GitHub)

  • Message queue events (eg, AWS SNS)

  • Cloud Storage events (eg, Azure Blob Storage)

  • HTTP APIs

  • Emails

  • SMS messages

  • IoT telemetry events (eg, MQTT or WebSockets)

• Supports all runtime languages: PureSec SSRE provides protections for serverless functions written in all major supported language such as:

  • Java

  • Python

  • JavaScript (Node.js)

  • and in the near future, support for Golang, C#, and other languages

• Cloud vendor agnostic: SSRE technology can protect serverless functions on any FaaS platform, with current support provided for AWS Lambda and Azure Functions.

The PureSec SSRE provides full-stack, end-to-end serverless security protection for your applications.

This feature provides a deep application layer inspection of event-trigger data; it detects the most sophisticated attack payloads consumed from any type of serverless events.

This unique behavioral protection for serverless function execution blocks 0-day exploits and unknown attack vectors. It creates a trusted and secure computing environment for the function to execute in.

PureSec SSRE detects and blocks any attempt to subvert serverless function logic. For example, it blocks:

• attempts to leak data

• unauthorized outbound traffic

• attempts to download and execute malware

• malicious code from executing as part of the function's normal execution

• unauthorized access to files

From build to deployment, SSRE integrates into your CI/CD process seamlessly. During build time, serverless projects are statically scanned to pinpoint risks related to over-permissive IAM roles and access rights.

The CI/CD scanner also detects insecure storage of application secrets and flags known vulnerable third-party dependencies. With the CI/CD integration, customers can decide to fail a build that does not meet corporate security policy.

SSRE provides unparalleled deep monitoring of your serverless functions. Always keep an eye on your functions behavior in real time, including function inventory, invocation data, runtime behavior, event data, security alerts, and threat intelligence.

In our sample project, we will use the Codeship GitHub SCM integration and trigger the build once our GitHub project has changed.

As an example, we will use the Serverless “examples” project titled aws-python-simple-http-endpoint, which you can download from the Serverless examples GitHub repository.

First, make sure you clone this repository. Then go on to configure CodeShip to connect to your GitHub repository as follows:

Next, we will configure our project with the following setup commands (line wrapped):

nvm install 8.10
npm install -g serverless
mkdir lib
cd lib
pip install puresec-awslambda --extra-index-url=https://**********************************:@packagecloud.io/puresec/puresec-awslambda/pypi/simple -t .
cd ../
pip3 install puresec-cli-enterprise --extra-index-url=https://********.puresec.io/************************/puresec-cli-enterprise/python
pyenv local 3.6
puresec test-roles --fail-findings 1
serverless deploy

The build steps above perform the following:

• Update the Node runtime to the latest, required for installing the serverless framework.

• Install the serverless framework.

• Create a /lib/ directory in your project, which will host the PureSec protection library.

• Install the PureSec protection library.

• Install the PureSec CI/CD static analyzer.

• Perform the static analysis of your serverless project, while instructing PureSec to fail the build in case any vulnerabilities were detected -- this will make sure that you only deploy hardened and robust serverless functions.

• In case everything succeeds, the build will continue to deploy your AWS Lambda function in your respective AWS account.

Next, we will configure the following test pipeline:

serverless invoke -f currentTime -d "{\"username\":\"foobar\"}" -l | tee legitimate.txt
serverless invoke -f currentTime -d "{\"username\":\"foobar' UNION SELECT password from tblUsers;--\"}" -l | tee attack.txt
grep "current time" legitimate.txt
grep "SQLi" attack.txt

The test pipeline above includes the following steps:

• Invoke your serverless function with legitimate input in order to verify that the function was deployed and works properly.

• Invoke your serverless function with a sample SQL injection attack payload, which should trigger the PureSec serverless application firewall. If the test succeeds, this means that your serverless function is now protected by PureSec. If this fails, you probably forgot to secure your function with PureSec.

  • Success criteria is defined as follows: if the function returns the string “current time” it means it worked properly.

  • Fail criteria is defined as follows: if the function returns the string “SQLi”, it means that PureSec caught the attack and raised a security exception with the attack_type = SQLi

In order to be able to deploy and test our AWS Lambda function, we will need to configure the following environment variables:

PURESEC_CLIENT_ID = (your PureSec Client ID)
AWS_ACCESS_KEY_ID = (your AWS access key ID)
AWS_SECRET_ACCESS_KEY = (your AWS secret access key)
AWS_DEFAULT_REGION = (your AWS deployment region)
PYENV_VERSION = 3.6

The final step is to actually secure our AWS Lambda function with PureSec. This is done through adding three lines of code (lines 6, 7, and 9 in the screenshot below) in the beginning of our function.

That’s it -- all we have to do now is push some changes to our project, and watch how Codeship does its thing:

Our build finished successfully.

Here’s how the final steps of the test pipeline look in the dashboard:

Now, let’s deploy an insecure function, which contains an over-permissive IAM security policy. It will grant the function unnecessary PutObject permissions on all S3 buckets in the AWS account:

- Effect: Allow
  Action:
  - "s3:PutObject"
  Resource: "arn:aws:s3:*"

The build should fail and return the following security vulnerabilities:

PureSec also goes the extra step and provides insights into the risks involved with these insecure permissions:

Now, let’s deploy our function with the proper IAM roles and permissions. However, we will “forget” to include the PureSec runtime protection library as a dependency, and see what happens to our build.

Looking at the build output, we can see that our sample SQL injection attack managed to reach our application, and no protection was applied.

After the deployment is done properly, PureSec provides unparalleled visibility into your serverless security posture through its SaaS dashboard. This not only flags attacks in near real-time but also provides a cross-account/cross-region inventory of all your deployed serverless functions, their version, runtime information, and whether or not they are secured by PureSec.

Customers may also integrate the PureSec solution with Splunk in order to analyze and perform security forensics when something bad happens.

Serverless applications can easily become the target of application layer attacks, which can lead to devastating outcomes.

Prior to building and deploying serverless projects, you should make sure that your serverless applications are scanned for serverless layer vulnerabilities, insecure IAM permissions, and known issues. In addition, serverless functions should always be protected using a serverless security runtime environment solution, such as the PureSec SSRE.

With a simple hassle-free integration between PureSec and Codeship, you can automate the security of your serverless projects, build, and deploy with piece of mind and confidence that your functions are robust and can withstand any type of serverless application layer attacks.