Adopting serverless? Awesome! But have you thought about how to keep it secure?
Many companies are starting to test and use serverless solutions or what is called FaaS (Functions-as-a-Services). They can build new applications and innovate in some of the old apps to get the best of performance and agility for their customers and allow them to have the most cost-efficient cloud environments too. Some good examples of companies using FaaS models today are The Coca-Cola Company, Finra, iRobot, Autodesk, and other big corporations across the globe.
Why are many companies migrating applications to serverless? Below are some of the most significant advantages of serverless functions:
- No servers to provision or manage
- Never pay for idle
- Faster usage-based scaling
- Built-in availability and fault tolerance
This type of technology allows companies to write fast and small units of code associated with event-based execution making things much simpler for DevOps teams. They can deploy new code or apps without worrying about which on-premise or cloud infrastructure it is running. The functions are executed when it is needed; this way, you don’t need to be running the servers all the time while the applications are idle and not being requested by any users.
All the most significant cloud providers today have serverless functions in their service portfolio. Also, there are a good number of open-source projects around FaaS. Some of the primary players associated with serverless from the various platforms are shown below:
With the fast-growing solutions and capabilities in this space, several companies are adopting some small pieces of the new application for this new model called serverless applications. This removes the need to manage more servers and use infrastructure as a service only when it is needed. Pretty awesome, right? But how can we keep serverless applications secure and prevent possible future security issues?
The top five main security concerns when we talk about serverless applications are:
- Application Layer Protection or Runtime Application Self Protection
- Dependency tracking
- Monitoring and logging
- Secure Coding
There are a good number of configurations on the serverless application that if misconfigured, could create serious issues for your company. The examples below are directly applicable to AWS environments:
- Function Exposure (Ensure that your Amazon Lambda functions are not exposed to everyone)
- Lambda Cross Account Access (Ensure AWS Lambda functions do not allow unknown cross-account access via permission policies.)
- Lambda Function With Admin Privileges (Ensure that no Lambda function available in your AWS account has admin privileges.)
- Lambda Runtime Environment Version (Ensure that the latest version of the runtime environment is used for your AWS Lambda functions.)
- Lambda Tracing Enabled (Ensure that tracing [i.e., Lambda support for Amazon X-Ray service] is enabled for your AWS Lambda functions.)
- Using An IAM Role For More Than One Lambda Function (Ensure that AWS Lambda functions do not share the same IAM execution role.)
- VPC Access for AWS Lambda Functions (Ensure AWS Lambda functions are configured to access resources in a Virtual Private Cloud (VPC).)
“Soon most of the attacks on the cloud environment will be the result of misconfigurations, lack of customizable security profiles, and auto-remediation by organizations in their day-to-day”
Cloud Secure Posture Management or CSPM can help you in the following topics:
This kind of technology is an emerging security solution to help organizations discover, assess, and resolve cloud misconfigurations across multiple cloud providers and accounts.
“Nearly all successful attacks on cloud services are the result of customer misconfiguration, mismanagement and mistakes. CSPM offerings directly target this need.” — Gartner 2019 Innovation Insights for Cloud Security Posture Management
Application Layer Protection or RASP
In this new era of DevOps and agile development, implementing a secure software development life cycle (SSDL) is crucial to protect your applications. Still, it is essential to extend this security to provide application-layer protection at runtime.
This type of technology can be used on physical, virtual, cloud instances, containers, serverless environments. That’s why a RASP (Runtime Application Self Protection) solution is becoming essential for many companies across the globe. RASP security products integrate within an application to prevent attacks at runtime by analyzing traffic, payloads, and end-user behavior.
That means RASP can thwart attacks with high accuracy. It can distinguish between actual attacks and legitimate requests for information, which reduces false positives and allows network security engineers to spend more of their time combating real problems and less time chasing digital security dead ends.
Let’s dig a little bit more about how it can work on AWS Lambda function, for example:
Add the security layer to your serverless app, and after it will be automatically loaded every time that you invoke the serverless function. RASP solution has a protect_handler that you need to call before you start the application to be able to intercept every single call.
Make sure you can track the dependencies and open source projects used in each function. It allows you to flag vulnerabilities in the libraries and fixes it as fast as possible. It helps you to continuously monitor the services with vulnerable libraries for a better security process and audit.
Monitoring and Logging
Some technologies can help you to ensure that functions are not accessing illegal services or taking wrong paths through the cloud provider. Solutions like New Relic, DataDog, AWS X-Ray, and Azure Monitor can help in this process. They can monitor resources accessed by serverless functions such as database connections, notification systems, CPU usage, memory usage, alerts, and functions data flows like the example below:
With the significant move from organizations to serverless applications, hackers will have a hard time attacking the infrastructure of cloud providers, and they will automatically change their focus to attacks on application layers. In the past year, we have seen a lot of security issues associated with mistakes and foundational security issues in this area.
Please be aware of this threat and pay extra attention to the security of the application code from your company. OWASP Top 10 and OWASP API Security Project are excellent frameworks to start with, and links for those are provided below:
Serverless technology is fantastic and is allowing companies across the globe to achieve critical business goals of reducing cost, reducing manage infrastructure, and be more flexible for a significant number of access to the application. But sometimes they think the security is all Cloud Provider's responsibility, this is not true. The security responsibility is minor compared with a regular instance like the example below. However, the customer still has shared security responsibility for the serverless application. Please remember it and take extra care about misconfiguration and securing the application code.
I want to say a BIG thank you for some people that helped me with fantastic feedback to improve this article:
- Stephanie Laranjeira
- Vanessa Scott
- Emma Bryson
- Andre Alves
If this post was helpful, please click the clap 👏 button below a few times 😉👍! ⬇