Overprivileged function permissions and event data injection are among two of the biggest security threats to serverless environments, according to a list of the top 10 serverless security threats , recently compiled by Ory Segal , co-founder and CTO of PureSec , a serverless tool entirely focused on serverless security.
In serverless systems, the underlying infrastructure is secured by cloud providers, Segal confirmed. So the cloud providers themselves end up being responsible for patching and upgrading that infrastructure, which is one of the biggest benefits of moving to a serverless approach.
“But you are still responsible for identity and access management and the applications themselves,” warned Segal.
When thinking about serverless application security, there are a number of attack vectors, Segal said. When an event is triggered, it carries out a function, which may interact with a third party component, and then generates an output. All of those activities represent the potential attack surface.
“There are three main ways to attack serverless systems,” according to Segal:
Through the event functions (for example, message queues, stream processing or database access), and the event data. Segal gives the example of an HTTP request which could attack via parameters or headers. Through the code itself. This attack occurs when someone deploys malicious code or if the code is changed through a phishing attack or by an insider threat, or through third-party libraries. Segal particularly noted that there has been an issue recently with malicious code in some python libraries recently, so when developers reuse this code in their serverless architecture design, they have been inadvertently introducing a security threat. By compromising one of the external components that the function interacts with. This occurs, for example, when there are insecure assets in an S3 bucket or other components that is brought in to the serverless workflow.“What dawned on us is that there is a problem with traditional security solutions and products,” said Segal. “Traditional products require infrastructure to run on to observe and monitor anomalies. But in serverless, you are no longer in control over the infrastructure, so you cannot deploy these traditional solutions. They are unsuitable to serverless today.”
Instead, Segal argues, serverless application security should not be something that “you bolt on the end”. Instead, security becomes a part of the overall serverless design. Where people talk about DevSecOps for modern application architecture designs, perhaps with serverless the idea is AppSecOps.
Segal says in serverless systems, security is partly about matching the right policies to various functions and serverless components. “For example, if you are collecting data from an S3 bucket, you need to look at the IAM roles and make sure they are granular and suited just to the access required, not wider. There are also other types of static analysis that can be carried out in the design of serverless applications to ensure there are not any security holes,” he said.
Segal gives an example of a serverless workflow where an HR candidate submits their CV as a PDF attachment to an email. A serverless workflow might trigger a lambda function to extract the attachment from the email, turn the PDF into text, check that the CV text confirms the candidate meets professional requirements and then puts all of that into an AmazonDB database. In such a case, a serverless architect would need to make sure that when a function is updating the data in the DynamoDB, it only has access to be able to update data and not access a wider range of the data.
“What we are seeing in this kind of example is two security risks. The most common ones we see are function data injunction and over-privileged functions and insecure dependencies,” said Segal.
Addressing Over-Privileged FunctionsSegal says the best way to reduce the security risks that come with over-privileged functions is to always apply the ‘least permissions concept’. “For each function, you need to know what are the absolute minimum permissions required to run, and you just allow those in the IAM policies,” Segal said this was so crucial that at PureSec, they have made it part of their solution to help users automate IAM roles.
“IAM roles on AWS is a double-edged sword,” said Segal. “The granularity gives you a lot of power, you can define what entities can actually do. The problem is that you need to learn the exact model of permissions and understand exactly what you need for your code. The architect who designs the system needs to run a threat model and then define the required roles that the devs would code into that configuration,” he advises.
Addressing Data Injection RisksSegal says data injection risks have been around with SQL injection for 20 years and is the same challenge in serverless systems. “Every piece of data that is input to your code needs to be scrutinized: code should never just trust external input,” suggested Segal. “The reason developers still make these mistakes is because validating data is not simple. You must sanitize and validate your functions, run the validation on all your inputs, and make sure entry complies with your expected inputs. You have to write a sanitizer/validator function whenever you accept inputs. It becomes complex, so analyzing inputs is not that simple. The rule should be that any data you are pulling in from the outside, you should make sure it is what you expect it to be and can’t contain any attacks,” said Segal.
As serverless systems increasingly move into production environments amongst enterprises that had previously designed proof of concept use cases, PureSec is seeing a greater focus not security, not just as a way to manage threats, but also as a part of compliance requirements. Regulations in some industries may require enterprises to demonstrate that not only the underlying cloud infrastructure is SOC2 or PCI Compliant, which is easy enough, but that now their own custom code needs to be compliant as well.
Feature image:Photo by MILKOV on Unsplash .
