Frequently Asked Questions

We've put together some commonly asked questions to give you more information about PureSec and Serverless Security platform.
If you have a question that you can't find the answer to, please use the chat button.


What is serverless?

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.

The most popular public-cloud serverless computing platforms are AWS Lambda, Azure Functions, Google Cloud Functions and IBM Cloud Functions.


Does PureSec provide any free tools?

Yes. PureSec offers several free security tools aimed at helping developers with enhancing their applications’ security posture:

  1. Automatic least-privileged AWS IAM role generator (link)
  2. FunctionShield - a security library for AWS Lambda developers (link)
  3. Lambda-Proxy - a localhost proxy for SQL-Injection testing your AWS Lambda functions using SQLMap (link)
Is PureSec engaged in active serverless security research?

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:

  • Serverless Security Top 10 Guide (link)
  • Serverless crypto mining attack (link)
  • Apache Openwhisk Weakness (link)
  • ReDoS vulnerability in Node package - AWS Lambda Multipart Parser (link)

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.

Does PureSec provide a solution for AWS Lambda Security?
Yes. PureSec Serverless Security Platform was designed to provide the best and most suitable protection for AWS Lambda security. For more information see https://www.puresec.io/puresec-for-aws-lambda
Does PureSec provide a solution for Azure Functions Security?
Yes. PureSec Serverless Security Platform was designed to provide the best and most suitable protection for Azure Functions security. For more information see https://www.puresec.io/product 

Serverless Security

How do attacks on serverless applications look like?

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)

Isn’t my cloud provider already securing my application out-of-the-box?

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.

How can an attacker even access my serverless functions?

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:

  1. A cloud-native event that might trigger your serverless functions
  2. By uploading or modifying code of already-deployed functions
  3. By poisoning 3rd party code dependencies that are used by the application
  4. By manipulating or poisoning data in cloud-native resources (databases, storage buckets, etc.)
If my functions never consume input from an external facing event, are they still at risk?

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:

Can’t I use the AWS WAF to protect my functions?

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.

Have you seen any attacks on serverless applications in-the-wild?

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.

Who should be responsible for serverless application security in my organization?

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.

Security Scanning

Can I use my existing SAST solution to scan my code?

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.

Isn’t it enough to scan 3rd party libraries for known issues? What’s left to protect beyond that?

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

Isn’t it enough to apply strict IAM roles & permissions in order to protect my application?

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 Serverless Security Platform

What’s the PureSec SSP footprint in terms of memory & performance?

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.

What are the differences between FunctionShield and the PureSec SSP?

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.

Will the PureSec SSP help me with achieving my regulation compliance (PCI DSS / SOC 2 / HIPAA, etc.)

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.

After I deploy the PureSec SSP, how soon will it take to get value and improve my overall serverless security posture?

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.

Can PureSec also provide value in terms of visibility and asset inventory for serverless?

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.

What languages does PureSec’s SSP (serverless security platform) support?

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.

Does PureSec SSP supports applications that are deployed using frameworks such as Serverless framework or APEX?

Yes. Relevant parts of the PureSec SSP deployment can be done either with CloudFormation or Terraform. Static analysis of serverless code and configurations currently supports the following frameworks:  Serverless framework,  APEX and SAM

Does PureSec supports my CI/CD pipeline?

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.

Can my developers test the PureSec SSP locally (outside of the cloud)?

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.

What’s unique in the PureSec serverless application firewall compared to a WAF?

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.

What does PureSec runtime behavior protection do?

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.

How long does it take to deploy PureSec SSP?

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.

Is PureSec only relevant for large-scale serverless applications?

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.

What cloud providers does PureSec SSP support?

At the moment, PureSec SSP is offered for AWS Lambda and Azure Functions, with additional platform support planned for future releases.

Can I deploy PureSec on-premise?

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.

Does PureSec support docker containers?

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.

How does PureSec stand out compared to competitors?

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 info@puresec.io .

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.

What are the steps required in order to deploy the PureSec SSP?

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.

Does PureSec provide a free trial?

Yes. for more information, please visit our web site at https://www.puresec.io/

Recent News

May 29, 2019
  I am excited to update that Palo Alto Networks today announced that it has entered into a definitive agreement to acquire PureSec, extending their cloud security platform with the best-of-breed...
Read More
May 15, 2019
About Skyline AI Skyline AI is an artificial intelligence investment manager for commercial real estate. Skyline AI partners with leading commercial real estate firms to establish next-generation...
Read More
May 2, 2019
Like most applications, serverless apps often need access to configuration data in order to function properly. And while most configuration data is non-sensitive, some needs to remain confidential....
Read More

Do You have any other questions?

Contact Us