Securing Serverless — Q&A With Protego CTO Hillel Solow
Serverless computing is the ultimate reduction in security attack surface. There is no computer, virtual machine, container infrastructure or network service to attack — just your code and the potential of a security issue introduced by mostly human configuration errors. As is tradition with our portfolio companies, I conducted an interview with the CTO of our serverless security investment, Protego Labs about how monitoring the security of a serverless infrastructure is different than traditional cyber security paradigms.
What changes in security does serverless bring?
First, there are areas where serverless makes security better almost immediately. For example, for the most part, shifting the responsibility for patching and updating platform software, including the operating system and runtime, to the cloud providers is a win for most organizations. Cloud providers will almost always do a better job at this than their customers can, and letting the cloud provider own this responsibility frees up the customers’ valuable security experts to focus on protecting actual value.
On the other hand, serverless changes the way companies should focus on security in three critical ways:
- Knowing what you have and what is going is challenging but invaluable. With no servers or containers to monitor, even just knowing what resources an attacker could try to interact with, or what the security health of those resources is, is challenging.
- Security posture becomes much more critical. Serverless applications typically comprise hundreds or even thousands of “narrow purpose” microservices (or “nanoservices”) so while it’s challenging to ensure each one is deployed with the best possible security configuration, doing so is extremely valuable, as it can significantly shrink the attack surface.
- Protecting serverless applications is essentially appsec. As we’ve ceded control and responsibility to the rest of the stack to the cloud provider, if we are going to defend our application, were going to have to do that from the stateless and ephemeral application layer.
What sort of attacks are you expecting against applications that use serverless computing?
First, it’s important to note that by and large both the goals and the techniques that attackers lean on have not changed. What has changed is their tactics. Due to the ephemeral nature of serverless workloads, attackers are less focused on creating persistence through direct insertion. Gaining code execution in a serverless environment is a very short lived victory.
Attackers primarily shift their focus in three directions:
- Repetitive attacks, which we call “Groundhog Day Attacks” are attacks where each round of the attack uses a small “kill-chain” to steal a small amount of data or do a small amount of damage. For example, a SQL injection technique might be used to steal 100 credit card numbers from the database. This attack is repeated as many thousands or millions of times as needed. Attackers take advantage of the nearly infinite transparent scaling of serverless to mitigate their inability to do a lot of damage in one shot.
- Upstream attacks, where attackers leverage the fact that your code likely uses hundreds or even thousands of 3rd party modules. Attackers find modules where they can get their malicious code included in the published library, and wait for your developers to deploy their next version, at which point the malicious code is now persistent in your function.
- Cloud infrastructure attacks, where the attacker tries to gain access directly to your cloud resources, such as the ability to launch containers, create functions or modify permissions. One common vector that is gaining momentum is where attackers find access keys to a cloud account that have been inadvertently posted somewhere on the internet, and use those to attack the cloud application.
Can these security issues and attacks be detected with traditional logs and telemetry from AWS Lambda?
Perhaps eventually. Traditional tools will need to get better in two key areas. First, serverless attacks are often repetitive. That means that a) attacks might be difficult to detect if you’re looking a single event and trying to classify it as good or bad, and b) that it’s not useful to report each of these events separately.
Second, serverless attacks manifest across more than a single resource. Identifying and investigating attacks requires analysis of the entire flow of the application, not of a single resource.
How does Protego Labs identify and stop these serverless security issues?
There are three key challenges in protecting serverless applications:
- Minimizing the attack surface to make attacks more difficult to begin with
- Detecting attacks correctly, despite the challenges mentioned above
- Defending against attacks at the application layer, without crippling serverless functions with untenable amounts of security
Unsurprisingly, Protego employs three strategies to leverage serverless to defend serverless. Protego Proact analyzes serverless applications continually during deployment and production, and detects any gaps in security posture, helping both SecOps and DevOps teams collaborate on remediating posture issues quickly.
Protego Observe analyzes real-time telemetry from application activity and logs, and isolates security events that require customer attention, collating small events across multiple resources into a single story.
Protego Defend applies elastic defense to the application, meaning that it uses all the of the detailed data on posture and behavior to compile a highly customized security defense strategy for each part of the application, so that the minimum security overhead is incurred while defending the application.
What sort of feedback do these solutions give to AWS Lambda administrators and developers?
The Protego user interface provides a detailed view into the security posture and defense status of the application, and allows security engineers, developers and administrators, to view and act upon each issue or incident. For each issue or incident, Protego provides clear information on what happened, including the evidence for that event, what the risks are, and what options there are for short and long term remediation. Giving clear and detailed information to all stakeholders is crucial to ensure that security risks are mitigated as rapidly as possible.
Are there integrations with orchestration tools?
Protego can be easily integrated with external reporting and ticketing systems, including JIRA, Splunk, Slack and PagerDuty, to help security and development engineers work together so solve problems, and to ensure that serverless security works seamlessly within organizations’ existing workflows.
How is it deployed and will it increase my monthly bill from Amazon?
Protego is integrated in two phases. First, a simple cross-account role is created during on-boarding to enable the monitoring and analysis of the serverless application. This process takes only a few clicks and several minutes, and Proact and Observe immediately start providing visibility and guidance.
A second piece, called the Function Self Protection (FSP) provider, is a tiny library and single line of code that is instrumented in some or all of the functions to enable more fine grained monitoring and inline defense. The FSP provider is typically instrumented into the application automatically during the CI/CD process using a set of plugins we provide, so that applications can be seamlessly protected.
Added costs to the customer account are typically no more that a few dollars a month, as Protego’s optimized defense incurs a tiny average overhead during function invocation.
Where can readers go to learn more?
Protego.io is full of useful resources, including our e-book on serverless security, our weekly blogs, past webinars we’ve done and more. For more detailed questions on serverless or serverless security you can also tweet at me @hsolow or @ProtegoLabs.
