Today, most cloud service providers are offering robust cloud services through serverless security apps or serverless architecture to provide impenetrable security features. However, security threats are still present in software or web applications, regardless of what architectural pattern has been implemented for data storage. If you want to know about the security of the serverless cloud computing model or are using a serverless architecture or serverless framework security, you have come to the right place.
LogicMonitor conducted a study, which showed that by 2020, the number of applications hosted on-premises would be reduced by 10% to 27%. In comparison, the number of cloud-native, specifically serverless hosted applications such as Microsoft Azure, AWS Lambda, and Google Cloud will increase by 41%. The trend of shifting to the cloud, specifically serverless and away from on-premises, isn’t new and shouldn’t come as a surprise.
That’s because serverless hosted applications improve security, as you no longer need to patch servers and allows developers to release new functionality with greater ease and frequency. It also saves infrastructure costs for organizations, but security and DevSecOps are left in a quandary. Although they don’t want to disrupt development efforts, they have no choice but to let someone else handle serverless application security.
To alleviate the issue, we will be sharing 10 serverless security best practices that you must employ to secure serverless apps.
What is Serverless Security?
Even though organizations don’t need to worry about infrastructure-related operations in serverless models, specific security concerns must be addressed. Here’s why serverless architecture or model needs protection:
- The serverless model doesn’t use detection system software (IDS tools) or firewalls
- The architecture doesn’t have protection methods or instrumentation agents such as keys authentication or file transfer protocols
User requested data is stored at the client-side in this architecture. For example, when you load more tweets on Twitter, the client-side page is refreshed, as the tweets are cached in the device. The client-side holds the data, which is why the focus is on strong code, data security, behavioral protection, and permissions that protect applications from library and coding vulnerabilities.
That means the organization will be focusing more on:
- The product’s core functionalities
- Improvement in quality
- Customer satisfaction
- Reduction of time to market
- Increasing productivity
- Development practices
There will be less focus placed on tasks such as:
- Infrastructure complexity and operability
- Runtime environment
- Operating system
Modern technology’s security aspect must be assessed despite the advanced features it offers.
Cloud computing has transformed the world of web, software, and mobile apps, but is it offering protection to your apps?
Organizations need to take precautions to secure serverless apps as this architecture uses an approach smaller than even microservices.
It uses miniature and independent software pieces that interact with multiple APIs and become public when they interact with cloud providers. The mechanism creates a severe loophole for security, making it easier for attackers to access the APIs and challenge the serverless app security.
10 Best Practices for Serverless Security
You don’t have to think about server security when you go serverless, unlike a server-hosted application. However, you will still share responsibility with a serverless model for securing your application. As it is a serverless architecture, you must practice the best methods for protecting and securing serverless apps.
Organizations can undertake several serverless application security best practices, but here are the ten best practices we have chosen to highlight. These include:
1. Don’t Rely Solely on WAF Protection
Application layer firewalls can only inspect HTTP(s) traffic, which means that a WAF will only protect functions that are API Gateway-triggered functions. It won’t protect against other event trigger types and won’t help if your functions are triggered from different event sources, like the following:
- Notifications (IoT, SMS, and Emails)
- Code modifications (AWS CodeCommit)
- Database changes (Azure CosmosDB, AWS DynamoDB)
- Stream data processing (AWS Kinesis)
- Cloud storage events (Google Cloud Storage, Azure Blob Storage, and AWS S3)
It’s still important to have a WAF in place, but it shouldn’t be your only line of defense to secure serverless applications. Your security may have gaping holes if you rely solely on WAP protection.
2. Use Custom Function Permissions
It’s a fact that over 90% of permissions in serverless applications have been over-permissioned. Although setting up permissions can feel daunting when considering serverless app function levels, you shouldn’t use a one-size-fits-all approach. A common serverless security mistake is setting policies that are more permissive and larger in function. Failure to minimize individual permissions and function roles makes the attack surface larger than it should be.
Your DevSecOps team must sit down with developers who have written the functions to review each function’s purpose and create a proper function level permission. Once you’ve determined each function’s purpose, you can create a suitable permission policy and unique role for each function. The good news is that there are various tools you can use to automate the process.
3. Conduct a Code Audit
Black Duck Software surveyed 1,000 commonly-used applications in enterprises and found that 96% use open-source software. The researchers also found that 60% of that software contained security vulnerabilities, and some of the bugs were more than four years old. That made code ownership and authenticity a critical security risk because you can’t trust what isn’t yours.
It is called “Poisoning the Well”, as attackers employ an upstream attack to gain more long-term persistence in your application. Cloud-native applications have many libraries and modules, including other modules, which is why a single serverless function may include thousands of lines of code from different external sources.
Attackers want to include their malicious code in common projects, and once they have poisoned the well, they wait patiently as the newer version enters and takes control of your cloud applications. If you want to improve AWS security, it’s vital to conduct a code security audit.
4. Retain Control Over Your Functions
Code vulnerability can be mitigated by careful CI/CD, even though it may sound like a utopian dream. Malicious functions may slip in through various means, like being deployed by a rogue employee. Attackers tend to target developer workstations instead of the deployed apps as that allows them to deploy malicious functions through legitimate channels.
These functions can be sneaked inside undetected to wreak havoc. To ensure this doesn’t happen, you must create a strategy and policy to conduct a code analysis during the build before it goes live and ensures that every function has gone through CI/CD.
5. Keep an Eye on All Attack Indicators
Serverless makes visibility harder, as shifting to serverless architecture increases the number of resources and information. That makes it harder for DevSecOps and security teams to make sense of all the data. As the number of functions rises, it is even harder to determine whether everything is behaving in the supposed manner.
Only a few hundred functions can generate billions of events every day in your log, making it tough to identify which ones are important. Even if you’re familiar with attack patterns unique to serverless apps, scanning all of them is impossible, which is why you must use AI tools for added serverless security, efficiency, and visibility.
6. Time Out Your Functions
All functions should have a tight runtime profile, but often it’s not intuitive to craft appropriate serverless function timeouts. The maximum duration of a function can be specific to that function. DevSecOps teams need to consider the configured timeout versus the actual timeout. Most developers set the timeout to the maximum allowed, as the unused time doesn’t create an additional expense.
However, this approach may create an enormous security risk because if attackers are successful with a code injection, they have more time to do damage. Shorter timeouts mean they can attack more often, which is known as a “Groundhog Day” attack, but it also makes the attack more visible. Therefore, you must time out your functions as a serverless security best practice.
7. Cut Down on Third-Party Dependencies
Developers often derive components from third-party platforms. It’s best to check whether your sources are reliable and whether the links they are referring to are secure. Taking this precaution saves you from unexpected vulnerabilities. You must remember to check the latest versions of components being used from open-source platforms.
Most developers prefer using open-source components in modern apps, making it harder to detect any issues or trace vulnerability in the code. It’s best to use the latest versions and get timely updates since that helps avoid unexpected or sudden threats and keeps you ahead of time. You can do that by regularly checking updates on development forums, using automated dependency tools, and avoiding using third-party software with too many dependencies.
8. Handling Credentials
The best practices for serverless security advise storing sensitive credentials such as databases in safe places and keeping their accessibility extremely limited and secure. Extra attention must be paid to credentials such as API keys. You should set environment variables to run time-evaluation settings and then deploy time in configuration files.
It will be a nightmare if the same configuration file is used in multiple functions, and you need to redeploy services if variables are set at deployment time. The best method is to rotate the keys regularly, even if you’re hacked, as it ensures that access to hackers is cut off. Every component, developer, and project must have separate keys and encrypt sensitive data and environment variables using encryption helpers.
9. Secure the Software Development Lifecycle
Your Software Development Lifecycle (SDLC) defines building an application, managing it through the lifecycle, and streamlining the development process. However, insecure applications may pose substantial business risks. Your vulnerable apps can result in loss of personal data, and cause irreparable damage to your business reputation.
Unfortunately, security-related activities are carried out often in the testing phase, which is further along the Software Development Lifecycle. That process is flawed because it multiplies the costs and risks to your business by up to six times more.
Integrating security during the development phase guarantees authorization and ensures proper working of the serverless application. It also involves continuously reviewing conditions for weakness and ensuring the application integrates with security practices.
10. Geographic Considerations
Developers should remember that certain geographic considerations could negatively impact serverless security when deploying app modules. The code deployed from different geographic locations can create code-related problems. For instance, a developer in New York will be using the US-East-1 time zone, while a developer from Asia will be using an entirely different time zone in deployment settings.
The best practices here are to use a single region or a suitable time zone for deployment. You can also use a safeguard while handling a serverless framework to avoid unexpected contentious development problems and manage work dependencies.
Serverless architecture has introduced a new application development paradigm, and there’s no doubt that new opportunities come with unique challenges. However, it can also offer incredible benefits like ease of managing infrastructure, efficiency, and scalability. This architecture shifts the organization’s focus from infrastructure operations to developing quality code, so people must be extra responsible when handling application infrastructure.
Therefore, you need to be careful and sensible when adopting serverless security application best practices. The best part is that as more enterprises shift towards and adopt ‘serverless’ architecture, cloud providers have started offering exceptional security features from their end.