Introduction to Serverless Security
Serverless is a cloud-native development methodology that enables developers to create and execute apps without worrying about managing servers. Applications rely on managed services under the serverless architecture, which abstracts the need to manage, patch, and secure infrastructure and virtual machines. Managed cloud services and function-as-a-service, or FaaS, are used in serverless applications.
There are several impacts of the serverless model:
- Agility Increased- While using serverless applications, developers don't have to focus on managing services like databases or authentication. Developers are free to focus on building the business logic of the application.
- Cost Reduction- The consumer only pays for the services they utilize in serverless applications. Customers who use AWS Lambda, for example, pay for the execution of their programs. Because businesses don't have to pay for underutilized capacity as they would with virtual machines, this has a substantial financial impact.
Why Serverless Security?
When it comes to serverless security, three challenges drive your security strategy.
- The first difficulty is rethinking how you reduce risk. Knowing where to put cloud and application security in a world where servers don't exist and auto-scaling can be difficult, but it's a vital aspect of risk mitigation.
- The second issue is technology, which provides us with new security options that were previously difficult or impossible to deploy. This certainly includes serverless technology. Most serverless applications use a fine-grained "nano-service" architecture, allowing considerably more closely imposed security controls. The visible orchestration of resources on the cloud fabric also gives a plethora of information for security solutions to protect apps.
- The third concern is implementing new technology, which introduces the new risks that must be addressed. In contrast, there are certain new types of risks to consider with serverless applications, such as perimeter fragmentation and security orchestration issues.
What are the Benefits of Serverless Security?
While serverless may seem like a new security challenge, it provides more security benefits than traditional infrastructure orchestration.
Operating system, Runtime Security, and patching handled by Cloud Provider
While deploying serverless applications, One no longer owns OS hardening, SSh, admin rights, and segmentation. AWS, Google, and Microsoft are reliable at keeping their parts patched and secured.
Stateless
Stateless nature gives hackers a hard time. Serverless functions run for a few seconds and then die. Serverless functions have no memory, reducing the risk of long-term attacks.
Smaller Microservices
Smaller Microservices enable one to do better IAM. One has the opportunity to implement security policies for small things, and this can result in reduced attack surface.
Serverless Security Threats
Event-Data Injection
Injection issues are among the most dangerous security flaws available.
When untrusted input is given straight to an interpreter and executed or evaluated, they occur. The majority of serverless architectures have a variety of event sources that can be used to initiate the execution of a serverless function.
Some common injection flaws are
- Operating System (OS) command injection
- Function runtime code injection
- SQL injection
- NoSQL injection
- Server-Side Request Forgery (SSRF)
- Object deserialization attacks
Broken Authentication
Serverless applications are built using a microservices-like system architecture, which might comprise hundreds of different serverless operations, each with its own set of requirements. Some may make public web APIs available, while others may act as a proxy for specific functions or processes. Robust authentication techniques are required to offer effective access control and protection to all essential functions, event types, and triggers.
"Exposing Unauthenticated Entry Point through S3 Bucket with Public Access" is an example of such an attack.
Deploying Insecure Serverless configurations
Serverless architecture is still in its infancy, and it offers a variety of customization and configuration options to suit any purpose, task, or environment.
Misconfiguring crucial configuration settings have a significant potential to cause catastrophic data loss.
When creating serverless architectures, it's critical to make functions stateless and ensure that sensitive data isn't exposed to unauthorized individuals.
It's also a good idea to apply cloud hardening techniques and suitable ACL configurations.
Function Permissions and Roles
Following the "Principle of Least Privilege" is usually a good idea.
Serverless functions should only be given the access required to perform the intended logic.
It's possible that handing over privileges to a serverless function can be misused to execute unwanted actions like 'Executing System Functions.'
Function Monitoring and Logging
From a security aspect, logging and monitoring security-related events in real-time are crucial since it aids in recognizing an intruder's behavior and successfully containing the situation. It will also aid in the real-time prevention of cyber-attacks.
The fact that "Monitoring and Logging" occur in a cloud environment outside the organization's data center perimeter is one of the essential elements of serverless systems.
Serverless developers and their DevOps teams must piece together logging logic that fits their organization's needs in order to accomplish effective real-time security event monitoring with a proper audit trail.
Consider the following scenario
- Collecting logs in real-time from various serverless activities and cloud services
- Using a remote security information and event management (SIEM) system to send these logs.
3rd Party Dependencies
According to the definition, a serverless function should be a short piece of code that performs a single discrete operation.
The serverless function will occasionally be required to rely on third-party software packages, open-source libraries, and even consume 3rd-party remote web services via API calls to complete this operation.
It's good to check third-party dependencies before importing their code because they could be vulnerable and expose the serverless application to cyber threats.
Storage of Application Secrets That Isn't Secure
As the application scales and grows complex, storing and maintaining the application secrets becomes vital. These may include
- API keys
- Credentials of database
- Sensitive Configuration settings
- Encryption keys
Denial of Service & Financial Resource Exhaustion
Serverless can experience Denial of Service (DoS) attacks. DoS on a serverless application lead to resource and financial unavailability. It is critical for the application developer to appropriately establish execution limitations when deploying the serverless application in the cloud to avoid such financial disasters and service outages.
The following are some resources that should be limited
- Memory allocation per-execution
- Number of processes and thread per-execution
- Execution duration per-function
- Execution limit per account
50% of data breaches and information leakage happened unintentionally due to employees' negligence. Click to explore our, Learn the Impact of Insider Threats in Cyber Security
Serverless Security Best Practices
"One role per Function" Practice
Always stick to the one-role-per-function rule, as you shouldn't use the same role for various functions.
A single function should have a 1:1 link with an IAM role in the ideal world.
Always remember to follow the Least Privilege Principle when establishing IAM policies.
For example, if a function is just designed to read things from a DynamoDB table, it should only have read access.
Excessive permissions are among the most dangerous misconfigurations that an attacker could exploit.
Securing privileged credentials
For accessing and interacting with other AWS services, use execution roles. Privileged credentials should never be embedded in plain text in function source code. Using privileged credentials must be secured in transit and at rest or use Secret Manager or SSM Parameter Store (AWS) with KMS. For Azure functions, use Key Vault.
Mindful while using dependencies
Since dependencies are prone to vulnerabilities, it is considered one of the security issues for serverless applications. Vulnerability in dependencies can leverage attackers to use them against the cloud infrastructure and your application.
Scanning of source code and vulnerabilities in dependencies should be completed at the development stage and the build stage. Vulnerability assessment should be automated.
Storing configuration in an environment variable
In some situations, you might need to use environment variables for storing configurations like hostnames. This minimizes the risks of sensitive data exposure if the lambda source code is compromised.
Access control and configurations
Events and triggers should be defined correctly about the requirement of the lambda configurations. If an S3 PUT event is required, unnecessary services from the trigger list should be removed. Strict network access control using a security group should be implemented when deployed in a VPC.
Automate CI/CD pipeline security checks
While developing serverless applications in the CI/CD pipeline, risk mitigation activities should be implemented throughout the CI/CD pipeline, including compliance and governance. These activities should include checking vulnerabilities in lambda functions.
Challenges of Serverless Security
Challenges faced by companies while planning serverless security
- Scanning tool ineffective- Scanning tools aren't designed for serverless applications, primarily when non-HTTP interfaces are used to receive information.
- Security Visibility becomes difficult- The amount of information and resources increases with serverless, which results in billions of logs every day. It becomes difficult to obtain information from the billions of logs.
- Increased resources result in more permissions to manage- An increased number of resources results in more permissions to manage, which can be difficult to manage manually.
- Vectors, Protocols, and Attack Points multiply with every function- Protocol means a potential point of attack. A unique approach is required for solving this problem for Google functions, Azure Functions, and AWS Lambda Security.
- Traditional Solutions are ineffective- Organizations don't have access to virtual servers or operating systems, so organizations cannot use endpoint protection or host-based IPS.
Conclusion
We can conclude that while implementing a security-first approach on the infrastructure layer, using serverless can help boost security. Serverless computing is a relatively new technology. It's been around long enough that its limitations and risk mitigation strategies have been thoroughly investigated. However, it is still a developing technology. Thus not all of the advantages of serverless are presently apparent. A reliable serverless function performs precisely what it says on the tin. It's too simple for us to fall into a code architecture where serverless services become closely connected, potentially resulting in a tragedy if an exception or security compromise occurs. If something goes wrong and other programs rely on it heavily, it may become too dangerous to delete. A flow-on impact of downtime can occur when a problematic serverless function is overly connected or too dependent on other serverless services or applications. The easier it is to define what your functions will accomplish, the smaller they are. As a result, any potential incoming attacks are reduced.
Related Resources
