Oh no, you're thinking, yet another cookie pop-up. Well, sorry, it's the law. We measure how many people read us, and ensure you see relevant ads, by storing cookies on your device. If you're cool with that, hit “Accept all Cookies”. For more info and to customize your settings, hit “Customize Settings”.

Review and manage your consent

Here's an overview of our use of cookies, similar technologies and how to manage them. You can also change your choices at any time, by hitting the “Your Consent Options” link on the site's footer.

Manage Cookie Preferences
  • These cookies are strictly necessary so that you can navigate the site as normal and use all features. Without these cookies we cannot provide you with the service that you expect.

  • These cookies are used to make advertising messages more relevant to you. They perform functions like preventing the same ad from continuously reappearing, ensuring that ads are properly displayed for advertisers, and in some cases selecting advertisements that are based on your interests.

  • These cookies collect information in aggregate form to help us understand how our websites are being used. They allow us to count visits and traffic sources so that we can measure and improve the performance of our sites. If people say no to these cookies, we do not know how many people have visited and we cannot monitor performance.

See also our Cookie policy and Privacy policy.

This article is more than 1 year old

A code injection to stop code injection could solve serverless security

PureSec tries to make serverless less defenseless

Serverless computing is not quite carefree computing. Those using it don't have to worry about servers, apart from the cloud service provider's bill. But they would be well advised to give some thought to application security.

Under the serverless model – which isn't actually serverless... think platform-as-a-service but billed when the application is running rather than on a recurring period of time – developers still have to take responsibility for their code.

The security worries are fewer, since AWS and its ilk have a legion of operations people on staff to safeguard the hidden infrastructure. But those creating serverless functions can't simply assume all's well.

"The application itself and all of its interfaces are the responsibly of the customer running the application," explained Ran Nahmias, VP of sales and business development for PureSec, a two-year-old security startup based in Tel Aviv, Israel, in a phone briefing with The Register.

Last week, in conjunction with the AWS Summit in San Francisco, PureSec made its Serverless Security Runtime Environment (SSRE) available in beta form – sign up required – as a way to exercise that responsibility.

Sad man in server room

Going serverless? Tell us how, then tell the world

READ MORE

PureSec's software offers those running serverless code – whether you call it an application or a function – the ability to detect and mitigate common app vulnerabilities, such as injection attacks, path traversal attacks, misconfigured resources, dependency bugs, and exposed secrets, among others, in real time.

In contrast to the rackable enterprise hardware of yore, aptly ridiculed in current season of HBO's Silicon Valley, PureSec sells security in software form.

The code comes as a library that can be included in a project with a single import line. And the billing, as befits the serverless model, scales with active usage rather than time. If no one is using your cloud function, no one is paying.

As an example of a serverless function threat, consider a maliciously crafted command to invoke a function on AWS Lambda with SQL injection:

sls invoke -f insecure_app -d "{\"username\":\"foo' union select password from usersTable;--"}" -l

PureSec's SSRE would intercept the request and prevent it from executing, while passing information about the attack to the log files and dashboard.

The software also includes a behavioral engine to detect patterns that deviate from trainable norms.

CTO Ory Segal observed that developers don't always follow the least-privilege principle all the time. In the case of an AWS S3 bucket with write permission, called by code needing only read permission, PureSec's software would catch the discrepancy.

Segal also cited as an example an application that utilizes the AWS DynamoDB database. If the app needed only a specific table, but was configured to allow broader access, that too would be detected.

According to a scan of 1000 open-source serverless projects conducted by PureSec, 21 per cent had one or more critical vulnerabilities or misconfigurations. (Arguably, the most noteworthy finding was the DotNet projects had twice as many vulnerabilities as projects written in the other runtimes: Go, Java, Python, and NodeJS.)

Segal said the challenge developing PureSec's software was figuring out how to make it work without root access.

"Existing security solutions just don't fit the serverless model," he said. "The main technological barrier here is we are also guest users [in the cloud]."

General availability, he said, is planned for July. ®

 

Similar topics

TIP US OFF

Send us news


Other stories you might like