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. ®

More about

TIP US OFF

Send us news


Other stories you might like