Serverless computing is a cloud-computing execution model in which the cloud provider acts as the server, dynamically managing the allocation of machine resources.
Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It is a form of utility computing.
Serverless computing still requires servers, hence it is a misnomer. The name "serverless computing" is used because the server management and capacity planning decisions are completely hidden from the developer or operator.
Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.
Yes. PureSec offers several free security tools aimed at helping developers with enhancing their applications’ security posture:
Of course. PureSec's threat research team has been pioneering serverless security research since the company was founded in 2016.
The team is led by our CTO, Ory Segal, who has been leading the most prolific and distinguished threat research teams at organizations such as Akamai, IBM, and Watchfire.
Since its inception, the team discovered and documented many application layer vulnerabilities related to serverless architectures, and also published highly acclaimed articles such as:
PureSec research not only provides an indispensable service to security professionals, it also delivers the foundation for PureSec product capabilities, including attack signature updates, behavioral protection algorithms, big data analytics, machine learning based defenses and so forth.
PureSec provides the industry's only complete serverless security platform. Automated feeds from the security experts at the PureSec threat research team ensure that PureSec products are always armed with the latest defenses against new threats.
Serverless-based applications can take many forms depending on their purpose, however, the most basic components of every serverless application would be the compute (functions), and the cloud-based resources with which functions interact.
In the general case, an external event would trigger a function, carrying within it information about the event itself - for example, an HTTP request from a client, a modification of a file in a cloud storage bucket, or even an IoT telemetry message.
The function will perform its compute task, oftentimes while using the event data, and will generate some output.
The output could be sent to an end-user, or it could be stored in a cloud-based storage service.
Since most attacks need to start at some entry-point into the application, which enables an attacker to manipulate code execution, it is common to see attack payloads passed via event-data fields, which the attacker controls.
In other cases, an attacker might try to gain access to the code itself and deploy changes to the application, for example by phishing for cloud account credentials and deploying code, or by poisoning 3rd party open source libraries, which the application relies on.
Another potential vector for attack is by poisoning or manipulating data in cloud resources, with which the application interacts with. For example, publicly open cloud storage buckets. Once an attacker is able to manipulate the compute logic, he/she can continue to perform any kind of application layer attack such as: bypassing authentication, stealing sensitive data, corrupting data, denying service (DoS) from other users, or abusing the cloud account for other purposes such as mining crypto-currency.
To learn more, see the following movie clip, which demonstrates how an attacker abuses a vulnerable AWS Lambda function. (link)
No. In any cloud deployment model that is not fully self-managed, the responsibility for security is a shared one, where some of responsibility for the cloud service falls under the realm of the provider, and some responsibility also falls on each customer.
In most public cloud serverless computing platforms, the provider is responsible for protecting the infrastructure that runs all of the services offered by the cloud platform. This infrastructure is composed of the hardware, software, networking, and facilities that run all relevant cloud services.
The customer is responsible for protecting the application layer, which includes - protecting application logic and code, any custom configuration, configuration of the different cloud services on which the application relies or interacts with, as well as to protect data stored in the cloud (at rest), data in transit and any client-side application logic and code.
In order to be able to attack your application, an attacker needs some sort of an entry-point, which will enable him/her to manipulate logic.
This could be through one of the following methods:
Yes. Keep in mind that event-data is not the only way for a function consumes data.
Functions may also use data coming from untrusted 3rd party internet hosts, for example, by calling RESTful API endpoints.
You can read more about this in the following PureSec blog post:
In some cases.
If your serverless application exposes an HTTP API by using API Gateway, and the AWS CloudFront service, you could protect these API endpoints with the AWS WAF.
However, keep in mind that the protection coverage provided relies on API call inspection and the quality of the inspection rules deployed.
If your serverless application consumes data other through other means - such as non-HTTP events, by consuming data from 3rd party API endpoints, or through MQTT and WebSockets, then AWS WAF will not be suitable for protecting your application.
Yes. Our threat research team constantly monitors attacks on our customers’ serverless applications as well as through use of honeypot projects we have deployed on the internet.
The intelligence gathered through these channels is fed back into the system in order to continuously enhance the PureSec SSP protection algorithms.
This really depends on the organizational structure, and the maturity of the information security process in the organization.
In some organizations this would be the responsibility of the DevSecOps team, in others it falls under the cloud architecture team, and in others it remains under the responsibility of the application security or InfoSec teams.
SAST solutions rely on static data flow analysis in order to locate vulnerabilities in applications. As such, they are incapable of properly modeling data flow in serverless applications, micro-service meshes, and discretely separate HTTP endpoints, where data flow goes in and out of user code and cloud services.
Having said that, existing SAST solutions might provide some benefit for locating vulnerabilities inside a single serverless function, and even then, they might run into severe accuracy issues.
No. Serverless applications contain many moving parts and components such as cloud databases, file storage, message queues, API endpoints, as well as the compute itself (serverless functions).
While 3rd party libraries that you might use in your functions can contain known vulnerabilities, there are many other potential weaknesses that might exist in your cloud environment.
For example - insecure service configuration, over-privileged security roles & permissions, unencrypted application secrets, and also weaknesses in your own custom code.
The Serverless Security Top 10 lists the most common weaknesses: https://www.puresec.io/blog/serverless-top-10-released
No. Applying strict IAM roles & permissions is an important part of securing cloud-native applications, and can go a long way in reducing the blast radius of an attack, however, it cannot prevent attacks altogether, or provide a full-proof solution for some types of attacks.
As an example, the severity of a SQL Injection attack can be reduced in a way that will only grant an attacker ‘read’ access to a certain table, however, an attacker would still be able to access other lines inside the same table.
PureSec invests tremendous efforts make sure the PureSec SSP is as lightweight as possible and has minimal effect on latency.
In terms of RAM, depending on the runtime being used, PureSec SSP will use up to 30MB of RAM.
The latency at the 95th percentile is approximately 21ms.
The zipped package size in terms of disk space is 4.4MB.
FunctionShield is a library for AWS Lambda security, which was created in order to help developers regain control over the behavior of serverless runtime environments and disable/enable certain behaviors such as outbound networking, child process execution and read/write disk operations on the /tmp/ directory.
The PureSec SSP is an end-to-end solution for developing, deploying and maintaining application security for serverless applications.
Yes. PureSec SSP helps addressing many regulatory requirements and industry best practices such as: maintaining full audit trails, proactively protecting your business logic against cyber attacks, applying strict IAM roles and security permissions, scanning code for known vulnerabilities and much more.
Instantly. Deploying the PureSec SSP is simple and easy and can take minutes.
Once deployed, the first and most important value is deep visibility across all of your cloud accounts and deployment regions. Real time protection against cyber attacks takes only a few minutes to apply and is a very simple process to adopt.
In addition, you can already start scanning your serverless functions for known vulnerabilities and misconfigurations and immediately start remediating issues.
Yes. From the moment you on-board the PureSec service, you gain unparalleled visibility and inventory to all of your serverless assets across all accounts and deployment regions.
Our platform supports AWS Lambda functions written in Node.js, Python, Java and C#, and Azure functions written in C#.
It should be noted that the underlying runtime protection technology that drives the PureSec SSP was designed to be platform and language agnostic and PureSec will add support for new languages/platform based on customer and market demands.
Yes. Integration of the PureSec SSP is simple and straightforward and can be done with any modern CI/CD pipeline such as Jenkins, CodeShip, GitLab and so forth. You can find more information in the installation guide.
Yes. The serverless function code and configuration scanning can be done on any machine in any environment.
Testing the runtime protection requires that it will be executed in a runtime environment that is similar to that of your cloud deployment.
This can be achieved by executing it in a container using the appropriate image.
Web Application Firewalls (WAFs) inspect HTTP traffic by being deployed in-line, between the client and the server.
WAF inspection is based on the ability to analyze HTTP messages, parameters, cookies and headers.
In a serverless, cloud-native environment, it is not possible to deploy such a device/service in-line, since the application owner is not in liberty to install anything on the underlying infrastructure.
Moreover, many serverless applications are triggered by cloud-native events other than HTTP requests - for example, cloud database changes, cloud file storage changes, message queues, emails and so forth.
WAFs cannot be positioned in a location that will allow them to inspect such events, and they were not designed to parse, analyze and detect attacks in cloud-native events.
The PureSec SSP includes a unique first-of-its-kind serverless application firewall, which resides inside the cloud-native serverless runtime environment.
As such, the PureSec serverless application firewall is capable of intercepting, decoding, classifying and parsing any type of cloud-native event that triggers your serverless functions. This serverless application firewall was designed from the ground-up to detect serverless application layer attacks.
Inspecting event-data input is the first line of defense in the PureSec SSP, however, not all malicious attack payloads will be transported through event-data.
For example, functions may consume malicious data by accessing remote APIs during execution, which might manipulate or exploit business logic.
PureSec SSP provides a secondary critical layer of defense, which continuously monitors function behavior inside the serverless runtime.
The PureSec behavioral protection engine uses a proprietary adaptive security model that was developed using machine-learning techniques, and once malicious activity, or a deviation from the normal legitimate execution profile is detected, it will be blocked in real time, while providing rich forensic data back to the application owner.
Installing the PureSec SSP is a simple and straightforward process that typically takes approximately 20 minutes in order to get the first set of functions protected.
No. PureSec SSP can protect any type of serverless application, regardless of size, scale or type.
Since the platform itself is 100% serverless, it automatically scales together with your own application and always provides protection with minimal latency.
At the moment, PureSec SSP is offered for AWS Lambda and Azure Functions, with additional platform support planned for future releases.
Even though the underlying technology is cloud & language agnostic, and was tested successfully on different platforms, PureSec is currently focused on providing application security for serverless applications only.
Even though the underlying technology is cloud & language agnostic, and was tested successfully on different platforms such as docker containers, PureSec is currently focused on providing application security for serverless applications only.
PureSec is the leader in serverless security, and the pioneer in this space.
Our Serverless Security Platform is powered by proprietary patent-pending technologies, which allow it to provide the most comprehensive end-to-end security starting as early as the development and all the way to production.
Our technology was designed and developed from the ground-up in order to support any kind of serverless environment such as public-cloud FaaS, serverless edge computing, and serverless on IoT devices.
For a detailed list of all the features and capabilities of the PureSec SSP, please contact firstname.lastname@example.org .
In addition, we believe that it takes more than just technology to make a great product - it is actually the people, talent, innovation and attitude that eventually make a product great.
The PureSec team is led by the top leading industry experts with years of proven experience in developing cutting edge application security solutions for leading companies such as: IBM, Akamai, Check Point and Trusteer.
Moreover, our threat research team actively monitors serverless attacks across the globe, feeding the data back into the system, as well as performing proprietary research into new risks and 0-day exploits related to serverless applications.
Deployments is a simple 2-step processes.
The first step is to integrate the platform into your CI/CD pipeline. At the end of this step, you can already get value by scanning your code and configurations, and mitigating any potential risks.
In addition, you already gain visibility into all of your serverless assets.
The second step is to deploy the runtime protection into your serverless functions.