Serverless computing has made a big splash on the cloud scene and is being readily adopted by DevOps teams across enterprises. Serverless computing refers to the offloading of code execution to a cloud platform. Developers can focus on developing their code without having to worry about the infrastructure to run their code. This code consists of various triggers or functions, and the cloud providers allocate warm servers to these functions and execute them in a target location of the developers’ choosing. Since development teams don’t have to work on server allocation and infrastructure management, serverless computing helps save money, time, and resources.
In certain respects, serverless microservices are more secure than traditional applications because they have a smaller attack surface. By eliminating the server environment — or at least abstracting it away from the end-user — serverless helps to reduce some inherent security risks.
Yet, even if serverless computing is theoretically more secure than traditional development environments, it poses new challenges concerning security. Traditional monitoring tools can’t work with serverless applications as they lack specific alerts where vulnerability is a concern. In the event of an attack, the attacker can cause major damage. They may be able to cause disruptions and use up cloud resources, leading to big bills.
With that challenge in mind, here is a list of practices every developer should avoid if they want to secure their serverless functions.
- Assigning function permissions carelessly
Serverless applications communicate with external resources using functions. Leaving the scope of a function larger than it needs to be is an easy mistake to make, but it opens the door for possible threats. Since the attack surface is already large because the application is multitasking, not limiting function permissions just adds to the vulnerability. Security teams need to properly communicate with the developers in order to understand what each function does, and assign appropriate, minimal roles to them. - Assuming a Web Application Firewall is all that’s needed to ensure security
When users develop applications, they need to keep in mind that they can’t just rely on WAF, as it can only provide security for functions that use API gateway triggers. The WAF provides no security for functions performing tasks related to cloud storage, streaming, code modifications, and database changes. - Reusing code without prior thought
Developers don’t necessarily write code entirely on their own and they might take help from older projects and open source code. Since the application may require a plethora of external libraries, developers need to make sure that the code they are using comes from reliable sources. This can ensure that the code is not used by attackers to gain access to the system from outside. - Assuming that you have absolute control over functions
While continuous integration and continuous deployment are happening, bad functions can slip through the cracks and can go totally unnoticed. These functions can be written by rogue developers and can lead to security violations. Developers’ workstations need to be properly secured to ensure they aren’t compromised. Attackers can use a compromised workstation to sneak in a bad function that can lead to huge security issues. - Giving functions excessive runtime
Another common mistake is that developers assign maximum runtime to functions, because it’s convenient. But, function runtime should be specific to that function, and short. Developers should spend time understanding how long the function takes, traditionally, and assign the minimum possible runtime to that function. In case of an attack, if an attacker gets hold of a function, they’ll have less time to make use of that function to cause any damage. With longer runtime, the attacker may get away with an injection because it may go undetected. But, with shorter runtime, the attacks can easily be detected, plus the damage can be minimized. - Manually accessing logs to determine attack indicators
A serverless application can generate heaps of log data, but due to these applications not relying on the traditional components, this data can be hard to understand. This gets especially tricky if we take into consideration the number of functions an application may consist of, and the myriad of events these functions log. Developers need to employ log tools that can help make logging their application easier. These logs can be extremely large, and hence, assessing them manually is not just impractical but it can also lead to anomalies going unnoticed. - Not adhering to best practices
It’s needless to say that best practices should be followed no matter what platform or environment is used to develop applications. Nonadherence to best practices can leave the applications open to a number of attacks, such as DDoS attacks or SQL injections. It’s vital that developers are fully aware of the fact that a serverless environment still relies on external libraries, and no matter where the developers host these files, they should adhere to security protocols and use best practices. This includes testing and validation of the code. Developers should be assessed on a regular basis to make sure the team is efficient.Conclusion
A serverless environment has its perks, but understanding how to keep your application secure in this environment is critical. Development teams should have stringent protocols in place, and developers should strictly adhere to them. Since serverless functions reference a number of external libraries and external databases, it becomes really important that every external source is keenly monitored to prevent security violations. Developers and security teams should work together and spend a good amount of time devising strategies to help improve application security. At the same time, teams should look for serverless security tools best suited to their applications.
