In this episode, Paul Duvall and Brian Jakovich cover recent DevOps on AWS news along with a discussion with Ory Segal, CTO and Co-Founder at PureSec about Serverless Architectures and Security.
Here are the show notes:

DevOps on AWS News

Episode Topics

  1. Your background, what led you to found PureSec with your co-founders…
  2. What’s unique about security when it comes to serverless and what’s the same?
  3. What are the common concerns engineers (software, systems, etc.) have in non-serverless architectures and how does this change when in serverless architectures?
  4. If I’m deploying a “Hello World” function that I’ve written in Python for AWS Lambda based on an S3 event trigger and want to make it available to others, what are the top 3 (or so) security considerations I need to make?
  5. PureSec release the first “Serverless Architectures Security Top 10” Guide – seems to based on the idea of OWASP Top 10. Will you talk about how you developed this and the process you go through in determining these top 10? Are they equally weighted or is #1 the highest risk/most common?
    1. State of Serverless Security Survey
  6. How would you incorporate security checks into a fully-automated deployment pipeline so that those top 10 are mitigated prior to software being deployed to production?
  7. On AWS, how would you incorporate security checks against a serverless application that’s already in production and who and how do you alert?
  8. How do teams and team structure change with Serverless? Where does the Security and/or the Operations function fit into these teams or organizations?
    1. Who owns serverless application security in a company?
  9. You’re at ServerlessConf in San Francisco now?
  10. You’re one of the founders of PureSec. Tell me more about what PureSec is doing, PureSec’s SSRE (Serverless Security Runtime Environment), customers, and so on
    1. Target customer, Target User
    2. How do users interact with the platform?

Additional Resources

Full Episode Transcript

NOTE: The transcript below was initially generated via Amazon Transcribe.
Paul: Welcome to our 17th Episode of DevOps on AWS radio. I’m Paul Duvall CTO of Stelligent and I’m joined by my co-host Brian Jakovich, who is a director at Stelligent. You can check out our previous episodes by searching on devOps on AWS  Radio, into Stelligent’s blog. We are hiring, we’re always hiring. We are looking for engineers who are passionate about continuous integration, continuous delivery, DevOps on the aws platforms. In this episode we’re going to be discussing recent devOps on AWS news and then I have a discussion with the Ory Segal, who’s a CTO and co-founder of a company called PureSec. Which is, PureSec provides a product that helps you secure your serverless applications.

Let’s get into some news. So, first thing I wanted to mention is our very own Chief Architect at Stelligent Casey-Lee, was announced as an AWS Container hero along with four others. Then there was also announcement for a AWS serverless heroes as well. Each of these categories within the overall a AWS heroes group was announced that at this point. So we’re really excited and proud to have casey as an AWS Hero. So that makes two from Stelligent.

We have a screencasts on continuous delivery for machine learning, with AWS-CodePipeline and Amazon SageMaker. I put this together, it is about thirty minutes and it’s based on a talk that I gave at the AWS New York City summit, so have a listen to that. The AWS systems manager parameter sort now integrates with AWS secrets manager and adds labeling for easy configuration updates. This means that you’re able to store your secrets and secrets to manager. Then use them with services that are already using parameter store, so for example CodeBuild, CloudFormation and some others. There’s a nice blog-post on medium from Julien Simon at AWS and he’s has expertise in machine learning, Amazon SageMaker and so forth. He talks about mastering the mythical art of model deployment he goes over deployment patterns for machine learning. There’s a blog-post from AWS on how to set up a multi region, multi account catalog of companies standard AWS Service Catalog products. Then there’s been the announcement of the AWS CDK, which is a cloud development kit. So, it’s in developer preview,   It an infrastructure modeling framework, that allows you to define your cloud resource, using imperative versus declared programming interface.
A couple announcements from CodeBuild. One, they’ve added build monetary and notifications with Amazon CloudWatch. Second, they’ve added local build support to speeds up the development cycle. A couple months ago, there’s been the announcement of a Golden AMI pipeline, that AWS announced and has a blog-post around that.
Then finally, AWS-CodePipeline added support for the AWS Device Farm as a test provider. Device farms allows you to run tests on mobile phones.

Brian: Yup. Well, thanks Paul. I have a couple of as well to go over. So the first, in the spirit of discussing security solutions that you can incorporate with AWS and certainly talking with Ory later.

AWS GuardDuty is now supports support stack sets, these basically enable you to specify a master account of what you want the configuration you want for GuardDuty and then deploy across you one, ten, hundred, thousand of accounts that are part of your AWS organization. This is a pretty important feature, we use a lot when it comes to AWS Config, so it is good to see that GuardDuty is now supported by this feature.

There’s also two articles for around AWS Config, the first being AWS Config best practices. Where it has twenty or so different best practices that you should be following, when you’re setting up AWS config your accounts from you know the standard config or whether you’re using AWS Config rules. It goes over  a lot of the best practices. Then AWS Config now supports AWS private Link. I think that’s pretty big announcement there.

Lastly, in the spirit of the podcast and some of the unique things that at least we’re looking at, you know to better support the podcast with AI and such. Amazon comprehend now supports syntax analysis and this just enables it to take a look at speech, written speech and then better analyze it essentially, using adjectives and such.
Paul: So next up, I speak with the Ory Segal, who’s a co-founder and CTO of the serverless security company called, PureSec. To quote Simon Wardley, serverless is an event driven, utility based stateless code execution environment. AWS lambda, is one of the prime examples of this capability. Where you don’t need to be thinking about servers anymore and you’re only paying for the compute time that you consume ,their other services that the fit this definition as well.
So, Ory is an expert in application security. In fact he’s one of the founders of the field. In this episode, we talked about the differences and similarities with security when it comes to serverless and non-serverless architectures. We get into an example, in which Ory describes the top three things to consider from a security perspective, when it comes to serverless.

Then we cover the top ten most common weaknesses for serverless security architectures paper, that came out recently. We get into some examples, of how you can run several security checks as part of the continuous delivery pipeline. We go over the transition that is and will occur as you go to applications, in which you’re using serverless capabilities and how we’re really going through a transition. Goes over a interesting description of a different form of shadow IT when it comes to companies that are using only cloud services. Then we go over the PureSec product and its features as well. And, this is a really enlightening talk about various topics, tools, behavior and processes that we get into. We have links in the show notes on Stelligent blog. I think you’re really gonna like this one.

Paul: Okay, thanks for joining the podcast Ory! If you would start off by talking a little bit about your background, your career and what led you to found PureSec with your co-founders?

Ory: Sure, so I started this phase of my career back in the end of the nineties. In 1999, I started by joining a small start up company based out of Israel called, Sanctum. Sanctum invented the world’s first well application firewall. l actually had the patent for web application firewalling and then I joined in order to build another product called APP Scan. Which was the world’s first web application security scanner. Today people know it is as IBM APP Scan and so I basically was a part of the original group of people that founded the field of applications security.

I was also a part of the web applications security concerns teams back then and OS from its beginning. Then we got acquired in 2004 for by WatchFire. Later on we got acquired again by IBM, where I stayed as chief architect for the IBM APP Scan security products until 2012. At that point I left IBM to join Akamai. Which was just going into the web security business on Akamai, I led the third research team based out of Israel with about 12 researchers. We were responsible for developing all these security algorithms for the Akamai’s Kona site defender products. So, that’s the world’s first cloud based to WAF, web application firewall and then both manager and the client reputation.

My background was mainly in application security with a lot of emphasis on machine learning and big data analytics. Then at some point I met two original founders of PureSec Shaked and Avi. And, we started talking and this whole serverless thing got me very intrigued. I was thinking about how interesting would be too take everything I’ve learned about application security and apply it to something completely different. And, it’s not every day that you see a completely new architecture. Where everything you know that we’ve done up until that point really doesn’t apply from a technical perspective, so that was my process getting into serverless security and PureSec.

Paul: Okay, so was PureSec actually founded on serverless security?

Ory:  Yes

Paul: When was a started?

Ory: So, PureSec was founded in October 2016. That point we didn’t quite know what in serverless security we want to make. Everything was still very vague. In May 2017, we got the first the seed round, three million dollars seed around led by tlv partners VC based out of Israel. At that point we already know exactly, you know, everything all the thoughts and the idea started to shaping to form.

Paul: So, it sounds like you’ve been at the beginning of a number of companies. That you got started really from the ground level. Now, is this the first company that you’ve co-founded or were there others as well? Because you mentioned there was a company that got bought, WatchFire, I believe.

Ory: Right. No, this is my first round as an entrepreneur and as a co-founder up until today. I just lead research teams mostly.

Paul: Got it. So, in 1999 when you joined Sanctum, what got you into that was based on your background in school? What led you to that?

Ory: Um, well not school. And in Israel not even the army. The army was actually a tank commander so nothing to do with computers, at least not that kind of computers. My background was I had a hobby. Early on my background goes in hacking. Back in the nineties I developed this hobby and at some point Gilli Raanan, who was the founder Sanctum and I met. I actually managed to penn test the web application fire which was called, App Shield. To find some vulnerabilities in it and at some point he decided that he wants to hire me to the company.

Paul: Okay, very interesting. Okay, let’s get into this a little bit. So can you talk a little bit about what’s unique about security, when it comes to serverless and then also what’s the same?

Ory: Interesting question. What was interesting about security for serverless so, first of all I think the most challenging aspect of security for serverless is where do you apply security given that, you know, you give control over basically over everything except for your code to the cloud provider. You’re no longer in control of it, in the liberty of installing anything actually so you only deeply code and you’re responsible for your code. So, if you want to deploy any kind of applications security solutions, like the ones we’ve you know we’ve learned to love or hate in the past twenty years you’re pretty much out of luck.  If you want install a web application firewall, it needs to be in line it needs to be able to inspect layer seven traffic http or https. You can’t install anything in line, if you want install like endpoint protection IDS, IPS, or even ras applications self protection there’s no real infrastructure for you to install in. You can instrument anything. So, that’s the first challenge when we you know, when we came to think about how do we secure serverless security. Is how the heck are you going to deploy anything in that environment which doesn’t allow you to do anything other than code.That would be like the first challenge and the fact that you’re also a guest in that environment, so when you deploy code and when you’re a third party vendor, inside someone else’s code. You’re a guest, you’re not a route user. You don’t have any super user privileges and you cannot obviously instrument anything, you cannot modify the colonel or you know, true things. So, it’s really challenging how do you find places where you can weave yourself into the environment and gain enough control so that you can actually protect the serverless code.

Paul: So for example, let’s say I am deploying like a hello or a really simple function that I’ve written in python. And I want to run on with AWS-Lambda and it’s going to be based on an S3 trigger. Then I want to make it available to others. What would you say would be the top three or whatever number you want to pick, like what are the main security considerations I need to make?

Ory: That’s a good question. Usually when thinking about, I’m trying to create a project and what are the most basic three things that I can do to make sure that it’s secure. The first would be of all to make sure that you inspect event data and make no assumptions about the events that triggers your function. Whether or not it’s valid or you know legitimate people think that just because the event came for example from a S3 or from a DynamoDB table or something that they control it means that the event is trustworthy and that’s not really the case.

In your case for example, you have a the S3 buckets that triggers a function. But is that S3 bucket open to the public? Can other people manipulates the files or the filings? You have to think about, where can an attacker manipulate the data going into my function and how do I rely on the data in what way, how much do I trust it or I don’t trust it.

The second thing would be the IAM and permissions that you assigned to the function. In your case, I think the function doesn’t really do much. It does get involved, then it’s S3 bucket but you didn’t really specify what is it doing. But if it does something, make sure that you granted the least privileges it actually needs in order to do its operation. Don’t use all sorts of a wild card permissions because that would allow an attacker to eventually do some lateral movements inside your cloud account.

And, the last thing would be visibility. You know everything would be terrific  if even if you know secured your code, you wrote a robust code, you don’t know if you’re being at that act. And, you don’t know where you’re being attacked and how is your function being used. So, I would definitely put an emphasis and how do again visibility, on how is the function running. What is it doing? What is it interacting with? What kind of actions is it doing on external resources and things like that?

Paul: Yeah, it just makes me think of something, when we’re talking about you know, the event triggered. In this case, I gave the example S3 and you were kind of alluding to this as well. So, there’s a lot of other event triggers. For, example that could trigger this function. I might have written it to accept an S3 event and who knows what the payload is inside that and whether it’s exposed like you said. But, then later on someone else could, you could have Kinesis or who knows what write that code. So, you’re not changing anything to the python code. In that case, you’re just changing the event that comes into it, in the data that gets passed into it. So, you sort of have to account for all the different types of triggers even if it’s not written that way yet.

Ory: Correct, it’s actually even where I’ll make things worse… Some event triggers except data nodes that are encoded in all sorts of weird encodings and each event type has its own encoding. For example, you know some event data fields could be zipped, some could be encoded in Base64. So, each event has its own format and structure and you have to keep that in mind and make no assumptions about you know, the format of the data and obviously it’s validity.
We actually developed a really nice demo which I think emphasizes this.  Where you have like a Cv management system for the HR department, and somebody sends an email with the PDF Cv file, that gets accepted by Amazon ECS, which is then generating a sns message. That triggers a lambda, which analyzes the PDF file for that matter, and then transforms the PDF into text, and there’s all sorts of analytics on the data and on the candidates. So, there you can actually clearly see how somebody can manipulate the filing off the PDF, which then gets embedded inside the sns message, it invokes the lambda and at the end of the day the vulnerability lies in the name of the PDF, which would be probably the last thing you would expect to see where the last place you would expect to see an attack at.

Paul: Yeah, wow.

Ory: Yeah, it’s scary.

Paul: So, you’re talking about the of the top 3 considerations, in this you know a simple “hello world” example. I noticed that PureSec has come out with a serverless architectures security top ten, which you know looks very similar in style to the OWASP Top 10, but specifically for serverless. Can you talk a little bit about the process that you used to determine that top ten and then how are they ranked? By most critical, most common, less risk things like that.
Ory: Right. So, this was I think, the first project I wanted to launch when we started PureSec. Given that it’s been a few years already since the launch of for that matter AWS-Lambda I haven’t seen anything very elaborate or thorough about application security in serverless. It was clear that people were deploying functions to the cloud without following best practices guide. I thought maybe there’s like a disconnect between all the work that was done in OS and in the web applications security consulting and all that and the up and coming serverless world. I thought maybe people didn’t do the connection between the two. Even though at the end of the day, we’re still talking about application security. So by having contributed to the OWASP Top 10 and the sands Top 25 and CWE.  
I decided that, I think it was time to contribute back to the community. With some sort of some sort of a guide, that will help developers that are really just starting with serverless, to develop the guide that helps them to not go through all the pitfalls and learned the hard way. So, we came up with serverless security Top 10 guide, obviously we drew a lot of inspiration from the OWASP Top 10. I think the main reason was because it was so successful. I’ve seen the OWASP Top 10 really grow in the last ten fifteen years on so. I said you know it’s a terrific model and it seems the top  X or top N lists seem to be working well for developers. So, I said that would be a good thing to work with.

So, we built that thing, we actually invited a large group of thought leaders and vendors from the space. Every big name and every company that is all in on serverless like iRobot, Nordstrom and obviously Microsoft, Amazon and IBM. So, we gather this group of people to do a lot of peer reviews and the feedback and we came up with the paper. The Top 10 themselves are listed in order of importance obviously. When I say importance, I mean based on how common these issues are. So, it’s not just a Top 10, I think we’re missing the whole point of the title. It’s the Top 10 most common weaknesses. So, these are things that when we talked to partners, design partners, customers, and prospects these are the things that top ten things that we are seeing people doing like the mistakes that we actually see people doing based on the criticality and you know how privileged they are. Yeah that’s the story behind it.

Paul: Okay we’ll definitely check it out, for  anyone who is listening. So you put together,  I mean they’re quite descriptive. Each item is about a page and a half or so you have a brief introduction and then you go through the considerations in terms of comparison to serverless and traditional and then you have mitigations at the end of it. And like you said if you put it out to the whole community so you know the companies mentioned Capital One, lots of input seems to be provided. So, it’s a it’s a great resource.

Ory: We didn’t plan it to be like a twenty five long page long document. It started like an experiment that I thought would end up being like two three pages. But, then people started asking for more and more things, like okay can you specify mitigations, can use spaces by how this is different from traditional applications security, and so we started adding more and more things based on the feedback from the community and that’s how it it became to being like such a huge project.

Paul: Right. I mean it’s really actionable on it’s not focus on any you know it’s not even focus on how does PureSec help with this it’s just really good general advice.

Ory: Yeah, we tried to make sure that it’s completely vendor neutral early on. Yes.

Paul: Right, okay. So, let’s talk about continuous delivery. You know, it’s a focus of something that we do it at Stelligent. So you know, I want to talk about it as if you’re putting together a fully automated deployment pipeline and you’re maybe considering some of these top ten. How would you incorporate some of these checks into the deployment pipeline on its way to production? Then once it gets deployed to production, what kinds of ways in which you go about runtime mitigation?

Ory: Good question. So, in general you know everything you can do statically pre-build time  from the top ten can definitely be automated. Things like scanning for known vulnerabilities in third party libraries, that’s something that you definitely can automate and put the gate before you ship anything. To make sure that it doesn’t contain any, you know low hanging fruit vulnerabilities that might be in there. Making sure that you’re using list privilege rolls and permissions against something that you can automate. In fact, PureSec actually has open-source, free library to like a command line utility that you can use to generate least privilege rolls. So, you can actually incorporate that into the builds process. Scanning your code for application secrets is another problem that we’re seeing. Well now, maybe a little less because of secrets manager and people are starting to get more aware, of how to manage your secrets using KMS and things like that. But, what you do still see is credentials and APIs being embedded inside the code and that’s very simple to scan during the building developed that process. So, all of these are things that you can do.
Another thing is and I haven’t seen a lot of that is, fast testing and dynamic application security testing tools being integrated into the process. So, that’s another thing and I actually had the blog-post while ago about how to use sequel map which is like the world’s leading sequel map injection exploitation and testing tool on automated tool how to integrate it into your CICD process and actually test your your lambda  functions before you deploy them for a sequel injection and it can probably do that for other vulnerability types as well. Obviously, static analysis study code analysis are using tools like a traditional SaaS tools. Like, forty five and checkmarks and all of those. To scan your code it’s not much different than traditional application security static analysis, there are some challenges there but definitely something that you need to consider doing his part of your CICD. And then again, I’m trying to keep this vendor neutral but find a way to make sure that your code is robust. I mean your your functions that deployed functions are robust and they have some kind of random protections installed on them.

Last but not least, visibility. So, talking about continuous process you wouldn’t really improve over time if you didn’t know what’s going on. Again, it’s always going back to disability when it comes to security especially now in serverless where things are a bit more limiting. So,being able to receive signals back from the functions in you know that are deployed to the cloud understanding whether or not they’re failing whether another receiving unexpected inputs or you know, timing out all of these will help you to make the continuous deployment and the development more robust over time.

Paul: So, Ory. If you could talk about how do team structures change, when it comes to serverless like where do you find security in operations function fitting within teams and organizations? Like who owns the serverless application security in these organization.

Ory: It’s a good questions that I don’t have an answer to. I think nobody still cracked that one, you know are solved that problem. So, it’s interesting because you know in the traditional App security world, you have the IT/Infosec folks or applications security architect. There’s many different roles in organizations, responsible for that. But, in a sense that one thing that serverless created is the fact that developers are not relying anymore on the IT team.
In almost any kind of way they can do CICD and and deploy whenever they want, whatever they want and that is terrific. Because, you know generated amazing agility and case in which we see developers, pushing the functions of the cloud is amazing. Obviously, serverless is contributing to innovation and agility but at the same time the IT, the traditional IT we are the ones responsible for the security they were responsible for educating developers on application security best practices. They were responsible for making sure that the architecture is robust and doing threat modeling and all that and now suddenly they’re out of the loop which means that their input is first of all, not mandatory in any way the question is who’s responsible now for applications security. Now with the IT folks out of the loop when it comes to deploying serverless and maintaining serverless applications it all goes back to the developers it seems as if at least now i’m not even sure if that’s the right solution but it seems that today the folks responsible for making sure that the application is secure, are the developers. Not only from the code perspective but also from you know deploying and scanning and tightening the configurations. So, I guess we’re in a weird place in in history where it’s now up to the developers to make sure that they build secure systems until that will change maybe, with the introduction of DevSevOps, so you know whatever you wanna call that. But, yeah it’s definitely an interesting time.

Paul: So, it’s a transition in a big way it seems like. So one of things we were talking about before this reporting was shadow IT. Right shadow IT, but you were talking about shadow IT in the context of the cloud and in particular with serverless. Could you expand on that a little bit?

Ory: Something that I’m seeing a lot in corporate and in large organizations. Today, they have this corporate wide cloud account on developers can use it on build functions and, you know, deploy functions to the cloud and there’s really no visibility into what these folks they’re doing and in the sense there now developing maybe the next phase of shadow IT or you know cloud shadow IT. But basically they can develop and deploy anything without anyone really knowing what’s being deployed and so, there could be a lot off external facing sensitive business logic being deployed the cloud with not a lot of monitoring and good tracking off what’s going on out there.

Paul: Right, okay. So, you also did a study or a survey on the state of serverless security. I don’t know when that came out, but I don’t know are you planning on having that being an annual thing number one. Number two, what were the most interesting things that you found from that survey?

Ory: Well first of all, definitely annual. You know, surveys and top X-lists are things that seem to to resonate well with the right audience people like surveys. I think it’s a good approach to generate knowledge and visibility around security. I think the most interesting things we’ve learned well one of them is, definitely related to what we just talked about. That you know there was a question there, who do you think is responsible for the security? If you’re the application security, if you’re serverless apps the answers ranged between obviously the DevSevOps, the developers, IT security,  and the cloud architect. It seemed that there was another answer there. It’s I think one of the last answers in the in the survey, was it’s not my responsibility, it’s the sole responsibility of or I think that the cloud provider is responsible for the application security of my functions. Given that people are deploying functions without any kind of active protections today or thinking about application security, you might think that perhaps people are thinking that they don’t have to do application security and serverless. It’s really their responsibility off the cloud provider. But, nobody actually answered that, so it seemed as if from the survey that at least people are aware that they are responsible for securing their applications they or their IT security or cloud architects and it’s not the cloud provider.
On the other hand, you don’t see people doing much. You know they’re hoping that everything is handled by the cloud provider, but there’s a bit of a contradiction there which is interesting.

Paul: I mean, what do you think in terms of improving applications security. When it comes to serverless and that’s probably I could ask that question in general. You know applications security service or not but, is it part of education? Is it tooling? Is it a combination? What do you think?

Ory: I think it’s definitely related to education. However I think that you know the folks that are developing serverless applications today are obviously still the early adopters on and you know the thought leaders in the space. It’s still not one hundred percent, you know common practice and so these are very smart folks that everyone that I met until today that develops serverless applications is super smart. People that see definitely see the future and see you know where things are going with the software development. And, I think at this point people are still trying to see how they can innovate very quickly with serverless. How they can maybe break out off that old you know, very slowing down process. Where they have to always involve the IT folks and  think about the environment and the underlying infrastructure and the servers. So, people today are trying to innovate and developed, very quickly and perhaps they’re not paying a lot of attention to security. I don’t think they don’t I know about security you know when we talked about the serverless security Top Ten. A lot of people said hey, I know the OWASP Top 10. And I’ve heard that and so you ask yourself, why nobody think about that earlier. So, I’m not sure it’s about education is definitely there is some education that needs to be done to make sure that people understand that this is still applications security. And, that they still need to apply common sense and best practices from the application security world onto apply to serverless so that’s one problem, I think the other problem is that people understand that given that the only thing they control is code. There’s really not much they can do other than right robust code and that’s far from, you know being true. There’s still many things you can do.

Paul: So speaking of thought leaders as we’re recording this, you’re in San Francisco right now at the serverless Conf. So, I know it hasn’t really officially started yet, but what are you looking forward to the most?

Ory: There are a few really cool talks that I want to see. You know I’m actually based in Tel Aviv, Israel. So, it’s not that for me that everyday, I get to bump into these folks. You know from AWS and from A Cloud Guru, there’s a lot of people that I’m you know constantly talking to or reading their you know tweets and blog’s and the and articles. So, actually meeting these people face to face something that I personally looked too. And, there is really some terrific talks especially around security this year, that I really wanted to see. So yeah, I think i’m obviously I tend to find more interesting the security side, but they’re definitely you know, a lot of interesting talks. I think it’s two days packed with terrific talks. And by the way yesterday, there was a hackathon that was really, really interesting. I think that was terrific experience as well.

Paul: Okay, so why don’t you tell me more about what PureSec is doing. You have the serverless security runtime environment, PureSec SSRE. Maybe you talk about your customers or your customer types, your target customer or target user and and how do users interact with the platform in general.  

Ory: So, if I have to summarize what our technology or platform does is there are three places in the development life cycle where integrate with the functions. The first enduring CID during development and build. We provide an integration of our static analyzer tools where you can scan on generate least privilege IAM rolls and permissions and then scan for known vulnerable third parties and application secrets as i mentioned earlier.  The whole point of that part is to make sure that when you deploy new function and they function or an application it’s as robust as possible you know from the get go. So you don’t have to apply security later on and then the two other security layers are the runtime protection layers and that they’re two separate layers both of them are integrated into your code through the PureSec run time protection library. It’s basically a very small footprint a library that you import. Tor example in python that would be like import PureSec into your code. An, what happens is when the function starts running we basically generate a new security environment around each function that the acts both as an application firewall inspecting the event data, however, from inside your function so it doesn’t really matter what kind of events triggers the function. We scan the event data to detect injection based attacks things like sequel injection, across the scripting past reversal command injection things like that. And, then the second layer is a behavioral protection engine a very unique Machine learning based protection that monitors what the function is doing inside the container where it runs inside the runtime.

Whether it’s trying to manipulate the file system or leaked data out to the internet or execute and you know spawned malicious processes and things like that. And we constantly compare that to like a normal profile of how the function should be behaving or normally behaves. And, then we can detect where they are deviations as a result of some malicious activity on all of that integration points go back to you no visibility we report back to CloudWatch and to our own the PureSec security dashboard. To provide continuous visibility into what’s going on with the function.

Paul: Who are the target customers ,and then target users within those customers?

Ory: Well it really ranges right now, we mostly deal with you know CISOs, cloud architect and even some development organizations are starting to develop, you know the the understanding that they need to do something as we said given that that something is up to them because they on the code which is the only thing you can own in serverless. They understand that they’re responsible for deploying security. So, it’s mainly like either Dev manager’s, DevOps managers, CISOs, and cloud architects. Looking at verticals it’s really all across the board, which I think is terrific from serverless adoption perspective. You know, you have companies in any kind of business, ranging from media, to insurance even, financial services, and obviously IoT device vendors. I haven’t seen one specific industry vertical that has some some kind of you know, infinity towards the serviceless. It’s really all over the place which is terrific.

Paul: Oh yeah, for sure. So, it sounds like enterprises, you’re talking about CISOs is that in general or is a across different sized companies?

Ory: Well I think that’s that’s you know, maybe my interpretation. In smaller companies that would be like the security function, but that the security person inside the organization definitely in large organization that would be the CISOs but in smaller organizations it’s like a usually security architect of some sort.

Paul: Mhm, I mean do you have a target customer in terms of enterprise or it doesn’t matter?

Ory: What we hope to, maybe are you know stated the mission is to target fortune two thousand company’s given that they would be the first to deploy security early on. But, you know, usually actually the inbound traffic we’re getting through the website and the white papers and things like, that are actually smaller startups. Which is very promising as well.

Paul: Mhm,  interesting so it sounds like they can interact with the PureSec console but you can also as a developer be able to look at it all on CloudWatch or, you can run it through the command line. You can interact with it all in code, well it sounds like.

Ory: Yes, definitely and I think that by the time this you know this will be live, were also shipping a new library free library for developers called function shield. It’s you know you’re probably the first one I’m talking to about this so we’re so supposed to launch it at the conference and function shield is a free library for developers you can download it, import into your code. It has basically three things that it can do. It can you know disable outbound network traffic from your serverless function, obviously outbounds everything except traffic to a double AWS resources. Or you can disable or enable read rite,operations on slash temp on this or you can actually tell it’s to disable spawning of child processes. So these are three very interesting use cases that we keep hearing from developers you know about the need to be able to control that and we decided to create a very small footprint library. That can simply imported into your code as I said it’s free and you can just you know in code configure it to say, ok I don’t I know that my function should never generate outbound connections to the internet, other than AWS. So, I just disable that’s very quickly, and it will do that for you. And it also generates visibility into CloudWatch, so you can get feedback, or developers can actually watch and see what their functions are doing in runtime. Something that is very hard to to, to do otherwise. But that’s very similar to how the main PureSec product works as well. Yeah, you import into the code and that’s how you control it.  

About DevOps on AWS Radio

On DevOps on AWS Radio, we cover topics around applying DevOps principles and practices such as Continuous Delivery on the Amazon Web Services cloud. This is what we do at Stelligent for our customers. We’ll bring listeners into our roundtables and speak with engineers who’ve recently published on our blog and we’ll also be reaching out to the wider DevOps on AWS community to get their thoughts and insights.
The overall vision of this podcast is to describe how listeners can create a one-click (or “no click”) implementation of their software systems and infrastructure in the Amazon Web Services cloud so that teams can deliver software to users whenever there’s a business need to do so. The podcast will delve into the cultural, process, tooling, and organizational changes that can make this possible including:

  • Automation of
    • Networks (e.g. VPC)
    • Compute (EC2, Containers, Serverless, etc.)
    • Storage (e.g. S3, EBS, etc.)
    • Database and Data (RDS, DynamoDB, etc.)
  • Organizational and Team Structures and Practices
  • Team and Organization Communication and Collaboration
  • Cultural Indicators
  • Version control systems and processes
  • Deployment Pipelines
    • Orchestration of software delivery workflows
    • Execution of these workflows
  • Application/service Architectures – e.g. Microservices
  • Automation of Build and deployment processes
  • Automation of testing and other verification approaches, tools and systems
  • Automation of security practices and approaches
  • Continuous Feedback systems
  • Many other Topics…
Stelligent Amazon Pollycast
Voiced by Amazon Polly