Serverless computing is an abstraction of infrastructure, servers, and operating systems. The term serverless doesn’t mean that servers are not any longer involved. It straight away means that developers no longer have time to think that much about them. Serverless lets developers switch their focus from the server level to the task level. However, this merely reduces the safety burden shouldered by the developer and doesn’t nullify it. From the appliance side, the appliance developer will still liable for application logic, code, data, and application-layer configurations, making it’s a shared security responsibility. Serverless brings with its new security challenges for developers. Given are TEN of the top security risks we have encountered in serverless architecture:
RISK 1: Defective logging and inadequate monitoring
From a security point of view, it is critical to log in and monitor security-related events in real time as it will help in detecting an intruder’s action and containing the situation much more effectively. It will also help debar cyber breaches in real time. Two of the key aspects of serverless architectures are the incontrovertible fact that Monitoring and Logging reside in a cloud environment, outside the organizational data centre perimeter.
RISK 2: Denial of Service (DoS)& Financial Resource Exhaustion
During the past decade, we have seen a dramatic increase in the frequency and volume of Denial of Service (DoS) attacks. Such attacks became the primary risks facing almost every company exposed to the Internet. In 2016, a distributed Denial of Service attack reached its peak of one Terabit per second. The attack originated from a Botnet made of millions of infected IoT devices. Most of the server-less architecture vendors define default limits on the execution of serverless functions such as:
- Per-execution memory allocation
- Per-execution ephemeral disk capacity
- Per-execution number of processes and threads
- Maximum execution duration per function
- Maximum payload size
- Per-account concurrent execution limit
- Per-function concurrent execution limit depending on the type of limit and activity, poorly designed or configured applications may be abusing it in such a way that will eventually cause latency to become unacceptable for other users
RISK 3: Dishonest 3RD party dependencies
While the problem of insecure third-party libraries is just not specific to serverless, being able to detect malicious packages is way more complex in serverless environments given the shortage of ability to use the network and behavioural security controls. It is suggested to look at 3rd party dependencies before importing their code as they could be vulnerable and can make the serverless application permitting to cyber-attacks.
RISK 4: Insecure application secret storage
one of the foremost frequently committed mistakes is, storing application secrets in plain text within configuration files, database configurations etc. Any user with read permission can gain access to those secrets. It is advisable to encrypt or not store plain text secrets containing API private keys, passwords, environment variables etc. Environment variables are a common way to persist data across serverless function executions, and in certain cases, such variables could leak data to unauthorized entities.
RISK 5: Unused Functions & Cloud Resources
Time and a half, serverless functions and related cloud resources may become disused and should be decommissioned. The main reason behind pruning obsolete components is to reduce unnecessary costs and eliminate avoidable attack surfaces. Obsolete serverless application components might include deprecated serverless function versions, unused cloud resources, unnecessary event sources, unused roles or identities, and unused dependencies.
RISK 6: Over-privileged permissions
Another risk that arises in security with serverless brings with it is overextended access to permission. When granting permission for particular serverless functions, be sure to minimize them according to the task assigned. Furthermore, constantly monitoring the functions for suspicious activities to avoid security breaches is advisable.
RISK 7: Function Event-Data Injection
Serverless functions consume input from various event sources, and every event source has its own message format and encoding schemes. Various parts of these event messages may contain attacker-controlled or untrusted input that should be carefully inspected.
RISK 8: Business Logic Manipulation
Business logic manipulation is a very common risk in many types of software. However, serverless applications are unique as they often follow the microservices design and contain numerous functions chained together to make the general logic. Without exact enforcement, attackers may be able to tamper with the intended logic.
RISK 9: Evaluating Vulnerabilities and Risks
Evaluating vulnerabilities and risks in a serverless application are challenging compared to a traditional application as most existing security tools only focus on traditional applications. Serverless Application developers have to utilize all the resources they have to make sure the application is hacker-proof and vulnerabilities are identified and evaluated from time to time.
RISK 10: Broken Authentication
Serverless applications are architected in microservice-like system design which frequently contains many distinct serverless functions with their own purposes. Some may reveal public web APIs, while others may function as a proxy for different functions or processes. It is mandatory to put in robust authentication schemes, which provide proper access control and protection to every relevant function, event type and trigger. An example of broken authentication is passwords are not properly hashed or salted. An insider or external attacker gains access to the system’s password database. User passwords aren’t properly hashed or are salted, exposing every user’s password.
