We’re entering the next stage of virtualisation. We’ve gone from physical servers to virtual machines and, now, to serverless apps, also known as functions as a service. At each stage, lifespans get shorter and new approaches to monitoring and security are required.
Serverless apps take data from an input, pass it through one or more proper workloads, and then direct the output to a destination. In and of themselves, serverless apps don’t generally process data. They just act as a programmable conveyor belt, shuttling the data from one location to the next. This means lifespans are no longer measured in minutes or hours, but in fractions of a second. The upshot being that security tools used to monitor the previous generations of virtualisation technology no longer cut it.
Driven by the rise in the adoption of microservices, serverless apps offer a huge degree of flexibility. Unfortunately, greater flexibility means more opportunity for attackers and would-be perpetrators to break in.
The increasing attack surface
While serverless apps enable greater granularity, such as faster billing for services, they are vulnerable to attacks exploiting privilege escalation and application dependencies. And since serverless applications are typically small, discrete functions, there’s also more data transferred across networks, another potential attack vector. The threat of brute-force denial of service attacks, in which the serverless architecture fails to scale and incurs expensive service disruptions, remains prevalent.
A recent study by PureSec found more than 20% of open-source serverless apps contain critical security vulnerabilities. Its report found 21% (of 1,000) of open-source serverless projects contained one or more critical vulnerabilities or misconfigurations, which could allow attackers to manipulate the application and perform various malicious actions. About 6% of the projects even had application secrets, such as application programming interface (API) keys or credentials, posted in their publicly accessible code repositories.
The identity crisis
Serverless apps are particularly susceptible to identity compromises. They’re acutely tied into identity and access permissions on the cloud provider side. Companies using serverless applications focus on the least privilege model to help secure them. All the major cloud providers have a serverless offering. With Amazon, it’s AWS Lambda. Microsoft has Azure Functions. Google and IBM both call it cloud functions. In a lot of cases, the exact implementation is not known – it might be a proprietary container forming at, but they’re taking care of the setup.
And that’s good, because the responsibility for the security of the serverless infrastructure, such as physical security, network security or operating system patches, falls on these huge and trusted brands. While patching is one of their core competencies, serverless does nothing to keep attackers away from data. If an attacker gains access to a businesses data through a vulnerability – leaked credentials, a compromised insider or by any other means – then serverless doesn’t help.
The application owner, however, is still completely responsible for application logic, code, data and application-layer configurations, ensuring they are secure, hardened and able to withstand attacks. Developers still have to be careful about how they write their code. If you write insecure code and put it in functions, a lot of the security problems still exist – SQL injections and similar attacks.
Trust in cloud
What all of this means is that customers have to put a lot more trust in their cloud providers. Having questions like, ‘how do you monitor the input and output in a function’, through to something as fundamental understanding how the provider is monitoring for malicious activities are completely understandable. Especially since a lot of the tools that would be deployed in an on-premise environment or a virtual machine are not in location. Ultimately, you’re trusting the provider to keep the underlying system secure.
For those not willing to put their faith in the big cloud vendors, there are on-premises alternatives. For example, IBM built its cloud functions service using the Apache OpenWhisk platform. Other options include Fission, IronFunctions, and Gestalt. As with other new technologies, there’s usually a delay before the security tools catch up.
Serverless applications aren’t for everyone. They make monitoring more difficult, while scaling and cost savings may be worth it for some developers, serverless apps come with higher test requirements and different monitoring strategies than traditional applications. That said, they open a lot of benefits to many DevOps environments. The scalability, cost-effectiveness, and compatibility with existing cloud applications are all unparalleled. Despite those benefits, there are still very serious security concerns and practices to be aware of and deploy.
Written by Antony Edwards, CTO, Eggplant