Serverless Security- What are the Security Risks & Best Practices?
Since you’ve landed on this blog, it’s likely that you’re either using a serverless architecture or exploring the cloud computing model– Serverless. In either case, application security remains a top concern.
While many cloud providers offer powerful serverless services, accompanied by robust security features. serverless applications are not immune to security risks and challenges that come with any web or software applications.
In this article, we will delve into the world of serverless security, covering what it is, the risks and challenges involved, and most importantly, best practices and expert tips for securing your serverless functions.
What is Serverless Security?
It refers to the practice of securing applications and services that utilize serverless computing architectures.
In a serverless computing model, applications are developed and deployed as individual functions or microservices, which are executed in response to specific events or triggers, without the need for managing infrastructure or underlying servers. Though organizations don’t need to worry about infrastructure-related operations in this model, specific security concerns still need to be addressed. Here’s why:
- The serverless model doesn’t use firewalls, detection system software (IDS/IPS tools), or any kind of server-based protection methods.
- The architecture doesn’t have instrumentation agents or protection methods like file transfer protocols or key authentication.
Hence, serverless security focuses on protecting serverless applications from potential threats, vulnerability assessment, and ensuring the confidentiality, integrity, and availability of data and resources. It involves implementing security practices and measures at various levels, including the application code, the serverless platform, and the associated services and APIs.
In this architecture, the data requested by a user is stored on the client-side––for example, Twitter. When you load more tweets, the page is refreshed on the client-side, and the tweets are cached in the device. This means that the focus is on permissions, behavioral protection, data security, and strong code that shields applications from coding and library vulnerabilities.
Moreover, serverless architecture uses an even smaller approach than microservices. It uses independent, miniature pieces of software that interact using multiple APIs that become public upon interaction with cloud providers. This mechanism creates a severe loophole where attackers could access the APIs and pose security challenges for complex enterprise softwares that use serverless technology.
Here’s the graphical representation of how the serverless model works in comparison with traditional virtual machines:
Check how we helped Food Truck Spaces build a secure app with AWS stack
You might’ve considered adopting a serverless model and wanted to know more about its impacts and security concerns. For instance,
- How does the serverless model protect an application without a physical server?
- Who provides this function as a service?
- What are some common security risks?
- What are the security best practices one could follow?
Before we explore these points, it is also essential to understand that cloud providers offer serverless models in the form of two distinct services: i). Functions as a Service (FaaS) ii). Backend as a Service (BaaS).
FaaS involves executing business logic through cloud computing services such as AWS Lambda Functions, Microsoft Azure Functions, Google Cloud Functions, IBM Cloud Functions, etc. Whereas, a BaaS model involves outsourcing all backend services of mobile and web applications to BaaS vendors.
Serverless Security Risks & Challenges
1) Insecure configurations, Function permissions, & Event Injections
- Insecure configuration:
Cloud service providers offer multiple out-of-the-box settings and features. These settings should provide reliable, authenticated offerings. And if configurations are left unattended, it may result in big security threats.
- Function permissions:
The serverless ecosystem has many independent functions, and each function has its services and responsibilities for a particular task. This interaction among functions is massive, and it may sometimes create a situation where functions become overprivileged with the permissions/rights–– say, a function to send messages to get access to database inventory.
- Event-data Injection:
Different types of input from different event sources have an encrypted message format. And hence, multiple parts of these messages may contain untrusted inputs that need a careful assessment.
Here’s how you can avoid this security risk:
- Keep your data separate from commands and queries.
- Make sure that the code is running with minimum permissions required for successful execution.
- Use a safe API to invoke your function, which avoids the use of the interpreter entirely.
Use SELECT LIMIT and other SQL commands (if your function is dealing with SQL database) to prevent mass disclosure of records in case of SQL injection.
[ORDER BY expression [ ASC | DESC ]]
LIMIT number_rows [ OFFSET offset_value ];
2) Insecure storage, Function monitoring & logging
- Insecure Storage:
Sometimes, developers prefer to keep application secret storage in plain text configuration, making the application storage environment insecure. These tiny flaws sometimes result in bigger threats of insecurity in serverless hosting.
- Function monitoring & logging:
Cloud providers may not provide adequate cloud security facilities in logging and monitoring for applications. It may result in risk factors at the application layer.
Here are some of the report examples that you should generate on a regular basis for effective monitoring and logging. It’s recommended by SANS Essential Categories of Log Reports. You can also set alarms on Amazon CloudWatch so that suspicious activity on any of the below-mentioned reports is notified to you––
- A report containing all login failures and successes by user, system and business unit
- Login attempts (success & failures) to disabled/service/non-existing/default/suspended accounts
- All logins after office hours or “off” hours
- User authentication failures by the count of unique attempted systems
- VPN authentication and other remote access logins
- Privileged account access
- Multiple login failures followed by success via the same account
3) Broken authentication
Unlike traditional applications, your serverless application is accessible for all once it’s published on the cloud. Also, it promotes even smaller design than microservices and, hence, contains thousands of functions. So, you must apply robust authentication for end-users’ access and carefully execute multiple functions.
Below is how you can make sure if every endpoint is authenticated:
Incorporating an extensive authentication system that exercises control and authentication over these APIs is highly critical.
- We store user’s active tokens in the database and authenticate them against every request. This will let you exercise token authentication, invocation count and expiration time limit. If you’re just starting with the serverless architecture, Amazon Cognito is an easy solution which will suffice.
- If at all user authentication is not an option, developers are recommended to use secure API keys or SAML assertions.
4) Automatic resource allocation
The serverless application doesn’t get blocked or unavailable when bombarded with fake requests as part of a cyber attack. Instead, the application receives automatic scaling of resources by the cloud provider as a part of the “autoscaling” and “pay for what you use” concept. So the situation becomes unlike with traditional architecture where applications stop serving the requests and make services unavailable during such attacks.
This may be difficult to tackle, but here are some proactive measures you can take to avoid the above risk:
- Set up automated monitoring tools and security analytics to continuously monitor for abnormal patterns of requests, unusual behavior, or signs of malicious activity.
- Set alerts to notify security teams promptly so that they can take necessary actions to mitigate the attack.
- Implement WAF (Web Application Firewall) to protect against common web-based attacks, such as SQL injection, cross-site scripting (XSS), and cross-site request forgery (CSRF). WAF can be configured to filter and block malicious requests, ensuring that only legitimate requests are processed by the serverless application.
- Implement Intrusion Detection and Prevention System (IDPS) as an additional layer of network security and network inspection to continuously monitor traffic and system behavior for signs of cyber attacks. IDPS can detect and block suspicious or malicious traffic, helping to prevent attacks from affecting the serverless app.
- Implement DDoS protection.
- Keep Function code secure with best practices.
5) Poor execution of verbose error messages
Sometimes, developers forget to clean the code while moving the applications to production, leaving verbose error messages in place if the functions’ code is written in an insecure manner. It results in a breach of secret information and other security attacks.
Here’s what you can do to address this challenge:
It must be withheld within the system as confidential data to protect the apps from attackers. Additionally, it is essential to have a proactive approach to code hygiene, logging, and error handling, and continuously monitor for potential exposures of sensitive information to ensure the security of serverless applications. Also,
- Use automated tools and scripts to scan and identify sensitive information.
- Conduct regular code reviews and audits.
- Implement proper data sanitization techniques when new input or data is received such as data masking, data redaction, or data anonymization.
- Implement Role-Based Access Control (RBAC)
6) System Complexity & lack of security testing
- System complexity:
System’s overall complexity increases while handling multiple functions and dealing with third-party dependencies compared to traditional infrastructure. Thus, it is difficult to detect malicious packages because of the inability to apply behavioral security controls.
- Complex attack surface:
Serverless application has an expanded attack surface because of the vast range of event sources and smaller parts of the application. It deals with different functions which are triggered through multiple interactions. It uses API gateway commands, cloud-storage events, and many others. Therefore, the risk elimination of malicious event-data injections becomes difficult.
- Lack of security testing
Standard apps are rather easy to test without the added complexity of serverless architectures. This is because serverless apps deal with third-party integrations of database services, back-end cloud services, and other dependencies. As a result, it falls short in security testing.
Here’s what you can do about dependencies in serverless applications:
- Remove unnecessary dependencies, unused features, components, files, and documentation. Continuously monitor versions of frameworks, libraries and their dependencies on both client and server-side.
- Components should be obtained from official sources with signed packages to reduce the chance of malicious data, components, or functions.
- Create security patches for the older versions of libraries and its components.
Adnan Rahic, developer advocate at Dashbird, says that the practice of serverless security tends to come with time. When you’re young and eager to build new software, security takes a back-seat ride. You build the app and hope you don’t get hacked. As a developer matures, this mindset changes.
The first step is to learn the standard best practices in programming. Validating input is, by far, the most important. Learning that an input to your system can be malicious regardless of who sends it. Parse it correctly, don’t cut corners here.
Once this is done, the following crucial steps are permissions and secrets. Using AWS services such as AWS KMS is a must for efficient secrets and key management while permissions can be managed with ease through IAM Users and Roles. Bear in mind, this is most crucial for S3 buckets. Secure your buckets immediately because they are the most vulnerable part of the whole system.
Once you have these key steps taken care of, the rest is just keeping it all working flawlessly. This is where monitoring tools come into play. You also need to learn how to utilize Dashbird, Cloudwatch, IOPipe, Thundra, or any other similar tool.
AWS Lambda vs Azure Functions vs Google Cloud Functions: Comparing serverless providers
Serverless Security Best Practices & How to Better Secure Serverless Functions
When you go serverless, you don’t need to think about securing a server unlike with a server-hosted application. However, you need to practice the best methods that protect the whole serverless environment and don’t just detect intrusion on firewalls like in server-hosted apps.
There are several best practices you can undertake to secure your serverless apps, such as:
1. Limit permissions access
The serverless ecosystem is made up of various functions. Organizations may mistakenly grant permissions to functions by giving them the access to multiple parts of the application. Organizations also need to limit the functions access toemployees working closely on the projects.
So, they’d be setting permissions and limiting access for two entities:
i) Give limited rights to employees about accessing functions:
You have to limit the permissions to specific roles. For example, you are using AWS or Microsoft Azure as your cloud-service vendor. You can set limits or do a role-based setup for accessing features of functions. Organizations have to decide the roles of their function and distribute them among the employees based on their responsibilities.
ii) Give functions limited access to confidential information:
This is about restricting resources per function. Much like limiting access to a team member, you could also regulate what part of your application a serverless function can access.
It sets a barrier for the functions that cause security breaches. It especially helps when attackers succeed in decoding one function but further fail to access the entire system.
When enterprise systems are in danger, this segmentation of functions becomes a safety net that doesn’t let disasters happen. Permissions granted to particular functions influence its performance on runtime; thus, you should consider limiting access to permissions.
How to create roles and segregate functions to avoid these pitfalls?
- Create custom roles as per the needs and apply them to functions and on individual accounts or to a group.
- Set limits for one account or multiple accounts.
- Create identity-based roles and separate permissions for one user or apply a set of permissions for different roles.
Listed below are some of the resources which can come handy for you:
- Serverless “Least Privilege” Plugin by PureSec
- AWS Identity & Access Management Best Practices Guide
- Microsoft Azure Identity Management and Access Control Best Practices Guide
- Leverage principle of least privilege
2. Monitor serverless functions
You should regularly assess all functions. This enhances your visibility into functions by tracing them end-to-end, quickly detects problems, and focuses on actionable insights. Security teams should also focus on taking audits and network logs at regular intervals.
These are some ways you can manage security logs:
- Keep track of the number of failing executions.
- Track the number of functions executed.
- Assess the performance of functions based on the time taken for code execution.
- Measure the concurrency based on the number of times a particular function is executed.
- Measure the amount of provisioned concurrency in use.
- Centralize logs from multiple accounts for real-time analysis.
3. Automate security controls
Security teams should automate processes for configuration and test-driven checks. Automating these checks saves you from the complexity and a bigger attack-surface of serverless architecture. You can integrate tools for continuous monitoring and access management. For example, there are several dependency scanners like snyk.io. Development teams can also write codes that automate scanning of confidential information and checking of permissions.
Refer to this potential checklist to automate security controls:
- Check if the function permissions are allowing excessive provisions for attackers.
- Involve security analysis at the development stage as well as pre-build or build stage in CI/CD pipeline; automate continuous checking for vulnerabilities.
- Educate development teams on moving infrastructure as code.
- Implement audit-logging policy and network configuration to detect compromised functions.
4. Third-party dependencies
Developers often derive components from various third-party platforms. However, using unprotected application functions from public repositories like GitHub can cause DoW attacks leakage or sensitive data exposure.
It’s a best practice to check the reliability of sources, and ensure that the links are secure. What’s more, remember to check the latest versions of components used from open-source platforms to stay ahead of potential vulnerabilities and zero-day attacks.
How to do it?
- Regularly check for updates on development forums.
- Avoid using third-party software with too many dependencies.
- Use automated dependency scanner tools.
5. Handle credentials
It’s recommended to store sensitive credentials like databases in safer places and keep their accesses extremely secure and limited. Furthermore, be extra careful with critical credentials like API keys. Set environment variables to run time-evaluation settings; then, deploy time in configuration files. It could be a nightmare if the same configuration file is used in multiple functions, and you have to redeploy services if variables are set at deployment time.
What are some ideal practices?
- First and foremost, rotate the keys on a regular basis. Even if you’re hacked, this ensures that access to hackers is cut-off.
- Use separate keys for every developer, project, and component to prevent unauthorized access.
- Encrypt environments variables and sensitive data using encryption helpers
6. Deploy at a specific time
You should see what’s the best time to deploy an application module that creates a bug-free platform for users. Deploy modules when users are not actively engaging with the platform, and traffic is minimal. To protect applications against attackers, you could restrict the deployment to certain time intervals.
What should be an ideal deployment practice?
- Deploy at idle times.
- Avoid rush hours like Black Friday.
- Avoid huge system updates in real-time; set specific time slots for upgrades.
7. Consider geography
While deploying app, developers should keep in mind certain geographic considerations that could create code-related issues. For example, a developer located in New York uses US-East-1 timezone while a developer from Asia uses a different time zone in deployment settings, it can lead to unexpected problems in development. To avoid such issues, it is recommended to:
- Use a single region or a suitable time zone for deployment.
- Use Safeguard measures while handling serverless framework to avoid unexpected problems in contentious development and manage dependencies of work.
What to do Next?
Serverless architectures require extra care because the focus shifts from infrastructure operations to developing quality code. And a lot of responsibilities, including security aspects, are given to the cloud providers to handle your application infrastructure.
Thus, it is critical to consider security as an integral part of your serverless application development and deployment process. Remember to:
- Adopt a proactive and comprehensive approach to identify, mitigate, and manage security risks.
- Prioritize serverless security as an ongoing process and stay informed about evolving threats and new attack vectors to keep your applications safe and secure.
What’s more, with companies increasingly going serverless, cloud providers have become sure to offer robust cloud services and impenetrable security features from their end.
Do you have experience with serverless security and security best practices about this architecture? Share your insights in the comments section or join me on Twitter @RohitAkiwatkar to take the discussion further.