Episode #24: Serverless Application Security with Ory Segal (Part 2)

This is PART 2 of my conversation with Ory Segal. View PART 1.

About Ory Segal:

Ory Segal is a world-renowned expert in application security, with 20 years of experience in the field. Ory is the CTO and co-founder of PureSec (acquired by Palo Alto Networks), a start-up that enables organizations to build and maintain secure and reliable serverless applications. Prior to PureSec, Ory was Sr. Director of Threat Research at Akamai, were he led a team of top web security & big data researchers. Prior to Akamai, Ory worked at IBM as the Security Products Architect and Product Manager for the market leading application security solution IBM Security AppScan. Ory authored 20 patents in the field of application security, static analysis, dynamic analysis, threat reputation systems, etc. Ory is serving as an officer of the Web Application Security Consortium (WASC), he is a member of the W3C WebAppSec working group, and was an OWASP Israel board member.

• Twitter: @orysegal
• Prisma by Palo Alto Networks: https://www.paloaltonetworks.com/prisma
• The 12 Most Critical Risks for Serverless Applications: https://www.puresec.io/serverless-security-top-12-csa-puresec

Transcript:

Jeremy: All right. So let's move on to number four. So number four is over privileged function, permissions and roles. This is one of my favorites because I feel like this is something that people do wrong all the time because it's just easy to put a star permission.

Ory: Yeah. And this is an issue that I've been thinking about a lot of, why is it like from a psychological perspective that developers put a wild card there? So, obviously, we've talked about the very granular and very powerful IAM model in public clouds, and that's very relevant to serverless. You break your App down into functions, you assign each function you need to assign to each function, the permissions that it actually needs in order to do its task and nothing more than that, and that's the point here. How do you make sure that if somebody exploits the function, if somebody finds a problem in the function, they are not able to manipulate that function to maybe do some lateral movement inside your Cloud account, move to other data stores, etc?

So that's very important and we see that developers have a tendency, and this is one of the most common issues, to just use a wild card and allow the function to perform all of the actions on certain resources. And that, as I said, this is something that I've asked a lot of developers, why are they doing that? And I'm hearing different answers. Some are just lazy, I have to admit, I do that from time to time as well. It's much easier than actually having to go to the documentation and figure out the name, the exact name of the permission that I need. The other set of developers talked about future proofing the function. So they said, okay, now the function only puts items into database, but maybe next week I'll need it to read, which by the way violates the principle of single responsibility, but let's put that aside. And so they did just put maybe crude permissions or they put everything.

And then there are those who just either don't care, or don't know, or are not aware that this is a problem. So those are the three types of developers or answers that I've heard. But this is by far the most common and I've seen frameworks that automatically generates wildcards as well, which is also bad. And I've seen some bad examples as well in tutorials, which is the worst thing this can happen because we're trying to teach people how to write [crosstalk 00:48:21].

Jeremy: To go the other way. Yeah. Well, so the example that the document uses is the Dynamo DB star permission. And I love this example because you would think, okay, put items, get items, query items, delete items, that seems like that's what I'm giving it permission to. But, no, when you give Dynamo DB star permission, you're giving it the ability to delete tables, or change provision capacity, and you can do a lot of really bad stuff there. And obviously, this is all predicated on someone actually being able to get into your function, but that is something that is possible ... again, it's limited in how you can do that but it certainly is possible. We'll get into that more.

Just one point about about the permissions per function. One of the things that I like to do is I try to give each function the permissions that I think it needs, then I publish it to the cloud, and they try to run it. And then actually, AWS does a great job of giving you the error saying, this function doesn't have Dynamo: put item permission or something like that.

Ory: You're basically using debug branding to figure out the right permissions, right.

Jeremy: It works.

Ory: It's not nice. But they do have a service I think called, access advisor, and I think Google came out with a much better automated solution for that. Eventually, I think the access advisor would look at historical logs for, I don't know, a few days or a few executions and will tell you, it looks like you have too much permissions, you should probably reduce them. But this is something that we've done in Pure Sec with the there's the OpenSource list privilege plugin that we wrote that you can use for serverless which basically statically analyzes your code, extracts all the API calls and then maps them to the list required privileges, and will actually generate a list privilege role for you. So this is, and we'll talk about the future, but I think this is something that will eventually will have to be solved somehow or Cloud providers will probably produce better tools around that.

Jeremy: Well I think some frameworks are doing work with guard rails and stuff like that too that help a little bit but it's not quite there yet.

Ory: Mostly around the asterisks around the wild card, but actually-

Jeremy: What you actually need.

Ory: Exactly. Yeah.

Jeremy: All right, so let's move on to number five. And this is probably tied to number 10 in a way. So number five is inadequate function monitoring and logging. And I think this extends a little bit to number 10, which is improper exception handling and verbose error messaging. Whereas logging is a good thing [crosstalk 00:51:04] but can be a bad thing, right. So let's talk about inadequate function monitoring and logging first.

Ory: Well, I think looking at this issue now in hindsight and seeing that there's an entire industry of serverless monitoring vendors and solutions, I think, we already see that this is a real need. And it becomes more critical for security, not talking about performance and tracing and things like that, but being able to properly monitor your functions to log the right thing is critical. And if you look at this, for example, if somebody runs a sequel injection attack and triggers some exceptions, where would you even see that? I'm not even sure you would see that in the default logging facilities that the cloud providers give you.

So it goes back to the fact that developers have to worry about application security specific logging. And, yeah, so you have to write more into Cloud watch and if it's related to IAM and things like that, then you would see that in cloud trail, I'm talking AWS of course. But yeah, without t...