Serverless Security
Secure Cloud Infrastructures with Application Security
Watch this video to see how applications can be simplified with serverless technologies and how security and monitoring controls can be seamlessly maintained in these constrained environments.
Transcript
[00:03] Vance:
And welcome to the Trend Micro session for the application architecture summit. Let me introduce you to our speaker today. Mike Milner Global Director of Application Security Technologies for Trend Micro, Mike, welcome.
[00:14] Mike:
Thank you, Vance. Happy to be here.
[00:16] Vance:
Yeah, we're really glad to have Mike with us this morning. He is an experienced expert in enterprise class app security for hacks and data breaches, and a frequent speaker at app security and developer conferences. So, we're very pleased to have him with us today. His session this morning, microservices without containers, why code is the new infrastructure. As DevOps enters the mainstream developers are using containers to let them isolate apps from underlying infrastructure, and serverless goes even further, and abstracts infrastructure completely. But sometimes these abstractions can often mean a loss of control and access for important functions like monitoring and protection. So today, Mike is going to show us how Trend Micro allows your team to maintain app security and monitoring controls when working with containers and even serverless. Just a quick note, before I hand it to Mike, you can download the slides I highly recommend you do. You can just hit that big red button under the view screen. And there you are right away. You'll see some other links there. We've assembled some great resources from Trend Micro thanks to Mike and his team hit the link that most appeals and you'll get that right away. No registration required. You did that to join us today. And we love to communicate between you and their speaker. So, any questions for Mike just type in the submit a question box. So that Mike, let me turn to you and tell us about microservices without containers.
[01:38] Mike:
Thank you, Vance. I wanted to start with a bit of history. In the beginning, we had a server and it was good. We wrote an application, put it on the server, we plugged it into the internet, maybe it was sitting on the floor by your desk, or in a closet just happily serving way requests.
[01:59] Mike:
Over time, if the application grew, we started to need maybe more capacity or more resiliency. So we added more servers.
[02:12] Mike:
As we added more servers, we started putting them in big racks to allow our application to grow. Over the years, we got better and better at this, we had staff to take care and nurture the servers to add more racks and then add more servers into the racks.
[02:27] Mike:
And eventually, this kind of grew and grew. And we started to need another abstraction layer. So we started to virtualize our servers. So the developers didn't really need to think quite as much about the physical hardware and the racks. Instead of specifying a physical server with certain capabilities for their applications, that might take weeks or even months to order, and then install and then provision. Instead, they could request a virtual server, which could be ready much quicker, and tend to make better use of the underlying hardware. Over time, some companies got so good at this that they actually started offering these virtual servers and other resources as a service. And this gave rise to the public cloud. Here we see a photo of one of Google's data centers. As you can see a lot of servers available. The key capabilities that these public clouds offered were elasticity to rapidly spin up additional capacity without those long procurement cycles, and an API to control the infrastructure. So instead of developers having to maybe write an email and explain in words what they needed. Now they had an API, and they could write code, and directly provision the capacity they needed on demand.
[03:54] Mike:
Now, these public clouds continue to grow and add more capability and more services and more abstraction levels to allow developers to focus on their application code, instead of focusing on the infrastructure that supports them. And these abstractions become a key factor of growth for application developers. They allow them to focus on the code without worrying about the underlying layers. The next big abstraction is the container. These containerized services allow you to deploy applications as a smaller unit of delivery, a little bit smaller than a virtual machine. more lightweight, but they still provide the ability to customize the operating system inside the container to allow you to choose the relevant packages and native libraries that your application needs, but still keeping isolation from other containers. that are running on the same host. Now, these containers are pretty much a natural fit for the public clouds and adoption has really taken off containerized applications are one of the most popular way to deliver applications today. But not being content with just one level of abstraction, the public clouds are continuing to push even further. And now we have this idea of focusing on just the code with Functions as a Service. And all their major cloud providers now have a capability of writing your applications just at the code level with these function as a service capability.
[05:46] Mike:
And when we focus just on the application function, it's part of this continued push to allow developers to focus on just the business value that they're offering to their customers. And really outsourcing all of the infrastructure management, of course, to the cloud providers. Now, this sounds great, developers are focusing just on the code. But what happens is we end up with two different kinds of code. So, on the left, you've got your actual application code that developers have been writing for a long time. And this is where the business logic is contained. But now, instead of asking for infrastructure, in an email, they're now writing code to encapsulate the infrastructure that their application needs. And as the public cloud start providing more and more pieces of infrastructure, this infrastructure code grows and grows. So now developers, yes, can focus on the code, but they now have to consider a broader type of code. And this has really been the impetus that's given us the rise of DevOps, that one person, one rule, this DevOps developer, is focusing on the application code, like traditionally developers have, but they're also, through code, managing the infrastructure, to allow them to organize their application, pull in all the resources that they need, so that their application will work efficiently, while still scaling to meet capacity needs. Definitely a faraway along past that little server sitting on your desk.
[07:37] Mike:
So if we start to kind of look at this trend over time, what I'm showing on this slide is the changes from the traditional server on the left, to containers in the middle, to serverless at the end. So you can see, if you look at the size of these rectangles, the overall effort to deliver an app is decreasing over time, which is great. And the size of the rectangle, the amount of effort and focus on the application, which is actually carrying your business value is also increasing, which is great for your customers, because they see the actual benefits, as opposed to spending time on managing the infrastructure. But as you can see, it also introduces this other type of effort, this cloud effort, you need to organize your cloud, use the resources in the cloud, and pull them all together in order to allow your application to run efficiently on the cloud.
[08:42] Mike:
And of course, at Trend Micro our focus is on the security of all of these application environments. Looking at a similar progression. On the left, I've added these red bars to represent the security effort. And you can see each layer has security requirements. On the far left, when we were dealing with physical hardware, we had a lot of security for the hardware itself. This is things like data center security, personnel security, who has access to the data centers, where are the servers located? Are they in racks? Do they need locks on the racks? How can we audit that the right network cables are plugged into the right switches and the right ports, a huge amount of effort to make sure that the physical infrastructure was secure. That is the first to go as we move to cloud computing, which offers big savings there. There's also operating system security, making sure that the operating system is up to date, that it's patched, that everything looks secure from that side. Files haven't been modified no malware on the file system, and then the application security itself and this is more at the application-level things like SQL injection. Making sure your authentication system works, making sure there are no bugs in your code.
[10:06] Mike:
Moving forward, you can see we now also introduce cloud security, another aspect to be paid attention to something again, that needs to be secured. And as we go fully over, you can see yes, we do drop a lot of the requirements of operating systems security when we move to serverless. So that's great, we no longer need to worry that our operating system is running all the latest patched operating system packages, the public clouds take care of that for us.
[10:38] Mike:
But what's a little bit different about the security changes, is there are some functions that are offered or managed at the OS layer, that we still need, we still depend on. And now when we move to a fully serverless environment, we no longer have access to the host to implement those protections. A common example, is securing the network traffic coming in and out of your application. At a host level, you've got the ability to run network inspection, you can see the network traffic, inspected for kind of known exploits or anything like that, and report on that and monitor that. By removing the operating system or abstracting it to the public cloud, we no longer have that access. So I've represented here, the effort you need to add at the higher levels grows, because you also need to replicate or replace some of the controls that used to be offered at the lower level, the operating system level. So now you've got a bigger burden on making sure that your application is secure at the application level, and that your cloud is secure.
[11:55] Mike:
Any discussion about cloud security wouldn't be complete without looking at the shared responsibility model. The idea that the cloud provider, they take care of managing the security of the cloud, they make sure that the cloud infrastructure is secure and works the way it's supposed to. But it's still in your responsibility, the developer or the DevOps engineer, to manage the security on the cloud. The cloud providers give you tools to make sure that your environment is secure. But it's up to you to use them effectively, to make sure that your cloud environment is secure.
[12:38] Mike:
I've highlighted here, in my view, the four really key points to focus on when you're looking at serverless, application security in particular. But really any application making heavy use of cloud resources. The first three are all squarely on the cloud management layer. The first, the access management, or IAM, the cloud providers give you advanced controls to restrict access. So that you can give your application or your developers very specific capabilities or very specific access to your cloud environment. So that when used properly, you can really give just the minimal amount of access that's required for your application to run and block everything else. This IAM capability is something we never really had in the old physical data center world. So the cloud allows us to be much more accurate and much more fine grained here. So definitely focus on this IAM capability.
[13:48] Mike:
The second is the audit capability of the cloud API's. The cloud API, that really is the point of control for your infrastructure, any changes to your cloud infrastructure, what resources are connected, how they're connected, who has access, all has to go through this cloud API. So auditing who is doing what with this API, whether that's people changing the infrastructure, or probably have more concern is if application roles are modifying the infrastructure, the audit capabilities in the public clouds give you the ability to track, monitor and look back historically, at everything that's happening in your cloud management layer. So that's another key point of focus for securing the cloud.
[14:43] Mike:
The third one, cloud posture, is really down to best practices of using the cloud. You need to make sure that the way that you've set up your cloud resources is done securely. You need to make sure that you haven't given access where you shouldn't have. This is one area where the cloud is very, very good, but also very, very bad. On the good side, it's giving you excellent tools to set this up, and then inspect and monitor that it's done securely. And there are many tools that will help you do this offered by security vendors. But the bad is, it's kind of made it much easier when you do make a mistake for that mistake to be very big. And there's definitely been reports in the news from many companies leaving, say, S3 buckets in AWS, unprotected and accidentally leaking large quantities of data. So this posture, how you set up your cloud is another key point of focus.
[15:47] Mike:
And the fourth one is really looking at the application itself, you need to make sure that your application code is secure. This is both the same as it always has been, you always need to make sure your application even if you're developing on a bare metal, you need to make sure that application is secure. But with the cloud, it's introduced new aspects and also new capabilities and tools to protect them. As the application itself becomes a major part of the cloud infrastructure or your cloud application, it becomes even more important to ensure that it's secure.
[16:29] Mike:
And what I want to do now is actually show you a demo of securing, in this case an AWS lambda function, using Trend Micro’s Application Security product, to give you an example of how you can really focus on the application security, even in these cloud environments with serverless infrastructures. So let's take a look at that now. Alright, so what we have here is an AWS lambda function. And this function is connected to an API gateway. And what that allows is, by making an HTTP request to the API gateway, it's actually going to invoke my lambda function and execute the application code. This application, you can see written here in Python, it's very short, just a simple example. Just a Hello World example. I'm going to execute right here. So just by loading this URL, it's going to invoke my lambda function and execute that lambda code. Hello world. And, in this lambda function code, we've added an intentional vulnerability. And it's a pretty obvious one, just for demo purposes, you probably wouldn't have a vulnerability like this in your code, but it's representative of what a vulnerability impact could be like if you had a bug like this in your code, or in a third party library that your application uses. And this vulnerability is, basically if I add a file, query string parameter, and give it a file name, it's going to open up any file I asked it to and just serve out the contents. So let's take a look at that now.
[18:28] Mike:
So if I add my file string, and just load that page, you can see it loads the ETC password file and serves it up. Now, the ETC password file itself in a lambda environment isn't actually that sensitive. This is just an example. But this could just as easily be something from the proc file system, which might give access to the environment variables available to your application. Or it could be from the task directory, which would give you access to the application source code itself. So definitely a very real risk here if there were a vulnerability like this. So what we're going to do now is actually protect this lambda function with Trend Micros Cloud One Application Security.
[19:20] Mike:
So the first thing we do is we're going to add our protection layer to this lambda function. So I click Add Layer. We're going to specify an ARN and put in the ARN provided by Trend Micro.
[19:44] Mike:
Within this layer, we have the full application security library, as well as a custom runtime to activate it. So what we're going to do now is change our function, to use the custom runtime. The third step is to add authentication information so that our lambda function can retrieve the correct policy from our cloud service. I've done this already with this key and secret as environment variables. And that's all there is to it. The lambda function is now running with protection. So, if I go back here, and remove my exploit, and just load the page, you can see the function works just like it did before, no change to its behavior. But in the background, the application security library is protecting all access to this function.
[20:54] Mike:
So, what I'm going to do now is run that same exploit I did before. And by default, our library is just in a monitor mode. So, this should work just like it did before. You can see we're still getting the contents of ETC password. But now I'm going to take you to our Cloud Console, and give you an idea of the information we see. First up, you can see right away my lambda function written in Python, we've now identified that an attack has happened. What we're looking at here is the overall events for all my protected applications. But what I'm going to do is I'm going to zero in on first, this malicious payload from my lambda function. You can see I clicked on it to get these details. And you can see the application security library has detected from within the lambda function environment, a request that looks like a local file inclusion. And you can see, there's my file parameter that I typed in my exploit. So, this is identifying that the request looks bad and likely, is malicious.
[22:11] Mike:
But we also have this second event here an illegal file access. And this is even more interesting, it's the same request. But because of where we are within the application code, we can get a lot more detail, not just that the request looks bad, but that it has actually found a real vulnerability. In our application, you can see that it actually opened the target file, ETC password. And that's violated one of our default rules that blocks read access to slash ETC. you can see we've got information about the lambda function itself, the function name, the AWS request ID that allows us to correlate this event with our CloudWatch logs, and the full details of the invoked function, including our account ID, and the function that's running in one region. So, this gives us everything to find out where this code is running that has the vulnerability. And because this is a code vulnerability, we also have information on the source code level detail of the source code file name, index.py. And the line number line eight in the handler function. So, this gives us information on where in the code this vulnerability is. And if we look back to our AWS console, we can see index.py, line eight, that's where the actual open call is that allowed access to that file. So, this gives us all the information we need for our developers to understand where this application is running. And where in the code to start looking at this vulnerability, whether it's code that you've written yourself, or a third-party library.
[24:00] Mike:
So, this has given us all that information. But what we really want is to protect our application. So, I'm going to go into the policy settings for this application. And I'm going to set the illegal file access to actually mitigate the vulnerability to block the bad request. And by changing that setting in the policy, that new policy is going to be sent automatically to my lambda function, no need to redeploy or edit my lambda function. And if I go back and remove my exploit, you can see good requests still go through as normal, just like before, but if I try my exploit now, you can see just like before, it's actually now blocked by the application security library. And if we look back at our application, you can see that this top illegal file access is reported as blocked. So now we have all the information, we need to find out where the vulnerability is, including the source code level details. And we're protected. So this is no longer an emergency situation, we don't need to bring down the application or scramble the team of engineers, we have all the details we need. But the application is protected, allowing us to fix the underlying vulnerability and our schedule.
[25:32] Mike:
So what you've seen here in a very short demo is a vulnerable lambda function being protected very quickly with Trend Micro’s Cloud One Application Security. And you've seen the details we've been able to get about the vulnerability in the code, and then actually patching the vulnerability to protect our application and allow it to continue to run and serve our customers while we fix the underlying vulnerability properly. So that's the end of the demo, we've seen the value of protecting with application security, we see how quick and easy it is. I want to thank you very much for your time. Now I'm going to pass it over to Vance to see if there any questions.
[26:16] Vance:
Mike, great demo and great session overall really important insight in putting all different stakeholders on the same page when it comes to App Security and monitoring threats and issues. So really terrific.
[26:29] Mike:
Thank you very much.
[26:30] Vance:
And you mentioned questions, no surprise, we've got a couple here. And it reflects both high level kind of vision for the team lead, but also implementation. So, let's get right to it. First off, so many different capabilities that you talked about, that a well-trained or well-oiled organization really should be aware of when it comes to securing apps, especially in the cloud era. We've got a couple questions here. Let me see if I can boil them down into one. How can folks be sure that their application development teams, and even folks in the runtime side follow security best practices and compliance?
[27:09] Mike:
Yeah, great question. It is a very complex environment, there is a lot of capability, which has great power, but also gives you big responsibility to make sure it's all secured. Generally, the way we advise people is to look at adding safety nets to your environments. When you have a public cloud, I mentioned those points of focus. Look at the posture of the cloud, can you set up rules and detections so that if anybody deploy something that is violating or not following best practices, make sure you're getting notified so that you can investigate, you might not want to block the developers. But you do want to pay attention, and make sure that they're aware that they might not be following best practices. So that's a safety net at the cloud posture level. And as you saw in the demo here, that's an example where you can add a security safety net at the application level, again, giving a broad level of protection, that is going to be active, even if the developers maybe are focused on something else, you know that that security safety net is present there as well. So that again, you get notified. And you can work with the developers to make sure they're using the cloud securely.
[28:39] Vance:
Yeah, it's really important. In fact, let's drill into that just a bit. During the demo, it was really noticeable to some people that there was very little code in there seemed like there was an awful lot of pre-existing library componentry, or maybe even some automation, that's go under the hood a little bit and talk about what Tread Micro has done to kind of facilitate this team approach to security with little code and lots of automation.
[29:06] Mike:
Yeah, that's a great point, during the demo to be visual and interactive. You saw me clicking through the AWS console. But of course, in larger scales, everything that I did was actually just interacting with the configuration of the lambda function, which, as you say, really lends itself to automation. And I think maybe more importantly, audit, it's very easy. With a tool like this, if you're using this as your application safety net, you can scan across all of your public cloud accounts, and audit that the system is being used everywhere, so that it not only protects where your focus is, but really gives you a view across the board to make sure that you're protected. And if you're not protected so that you have a view as to where and can manage that risk. As you say we didn't have to modify the code. That's important as well, so that developers can continue to use the tooling that they've already been using. This is a security layer that's added on. And also, it really lends itself to protecting existing applications that maybe don't have an active development team attached to them. You're able to add security, get that visibility, get that protection, without having to rewrite or replatform or really steal resources from other projects. It's something that can be added directly in and giving you all of that protection, with very little effort.
[30:38] Vance:
Really great, really great, Mike, you know, you had a great use case. Here's another one that maybe you run into a lot there at Trend Micro, our team needs to manage and secure cloud database apps that use microservices across multiple hybrid clouds. How does Trend Micro recommend maintaining security for this diverse and distributed environment?
[31:00] Mike:
Yeah, good point. This is one of the product strategies that we've been following behind this application security product is to focus on the application itself. So we want to protect the application and where it's deployed and how its deployed, becomes more of an implementation and instrumentation detail. So it's important to us that all of the security that you saw in this demo with AWS lambda, you can actually deploy the exact same protection with the exact same policies in a containerized app. And we have instrumentation and tools for installing that are focused on containers. And as well, other cloud providers. Lambda has the lambda layers approach, which allows instrumentation very easily. But other cloud providers have other tools that allows this instrumentation to happen, that feels natural in that environment. It's important to us that our tool fits our customers, development environments. We're not asking our customers to adapt their processes to fit us.
[32:12] Vance:
It's a really good point, Mike. And just to enumerate this, because I think it might have passed by some folks. The approaches that Trend Micro has used are applicable in just about any flavor of cloud that I'm working with, whether it be hybrid, or multi cloud or cloud native, or even serverless. Is that a fair statement?
[32:32] Mike:
Yeah, absolutely. Some of our biggest customers aren't actually using public clouds, but their private clouds are so large that they can operate them in very much the same way. And just like in the public clouds, we optimize our deployments as well to fit those cases with more on prem data centers. And as you say, hybrid environments where one application might be based in an on prem environment, but might surge the cloud to handle peaks and spikes for special events, or you know, those good old black friday shopping holidays.
[33:11] Vance:
Yeah, excellent, Mike. Excellent. You know, I think time is just flying by such a great session, great conversation here in the q&a, but I think we can squeeze one or two more questions in one of them goes to the idea of the nature of a cloud native application. Can you talk about the threat types or attack vectors specific to a cloud native application that folks working in traditional cloud environments might not think of?
[33:36] Mike:
Yeah, good question. This I always answer in kind of a two phase approach. The first is really just to remind people, that it's not all new, you still need to be concerned with application threats that we've been thinking about and talking about for decades. So you still need to be aware of things like SQL injection, authentication bypasses, even though the cloud is very different. We can't forget about those existing best practices. So I always caution people, that even though there's lots of exciting new stuff to look at, don't forget about those basics, those foundational things. But there are definitely aspects that are specific to cloud native applications that really weren't so much of an issue before. One of the biggest ones and this is really a trend emerging in kind of the past year is increasingly attackers are becoming less focused on the actual applications and the data they contain. That's definitely still a concern. But the biggest attack vectors now are really looking at your compute capacity. The cloud gives you the developer access to effectively unlimited compute capacity. Now If an attacker can get access to that compute capacity through your account, then they're going to use your account to do things like Bitcoin and other cryptocurrency mining, or using your infrastructure to launch attacks on other targets. So this is something that's a little bit new in cloud environments that didn't really exist in more traditional IT environments. But it's not always your application in your data, that's the target anymore. Sometimes it's your infrastructure. And in a sense, your cloud account, billing, they want to use your resources to launch their attacks and to generate money for themselves. That's something that's really emerging as a new trend in this more modern environment. So this broadening threat vector, really these traditional attacks and these new attacks is really the core or the heart of a lot of the strategies that we're taking at Trend Micro to address these threats. Our cloud one platform is a collection of not just one tool, but many tools to cover all of these different aspects, from cloud posture management, to container security, application security, which you saw earlier, and also traditional host based security and network security. This is not a single point solution problem, you need a very comprehensive collection of products to protect against this really varied environment of attacks. And like you said earlier in one of your questions, people aren't just using one environment. It's not just one public cloud or one private cloud. In almost all cases, it's a mix. So you really need tools that can pull all of that information across multiple cloud providers, to give you really a single view of your overall posture, and threat environment. So getting that unified view is also really important to help you as an organization manage this variety of threats.
[37:06] Vance:
Fantastic, Mike, I see time is right up against it here. But before you go, we can't let you leave without having to tell us how folks can learn more about Trend Micros Cloud One, whether there are free trial opportunities or ways to get a more deep dive into the architecture. Give us some next steps suggestions.
[37:25] Mike:
Yeah, in terms of next steps. If you want to learn more about application security, or cloud one as a whole, you can check out the Trend Micro website. And we also have available free trials of Cloud One and application security. If you go to cloud one.trendmicro.com. You can sign up for a trial for free and get started. And we also have a team of sales engineers available to help you out get started and answer any questions you might have about this product, or anything else the Trend Micro offers.
[37:59] Vance:
Excellent, Mike. Excellent. And as it happens, thanks to you and your team members, we've got links to many of those resources, including the free trial and some extra resources that let people do a little extra research on Trend Micro solutions before they get too far down the track. So thanks very much for a great session and especially for terrific QA, like milnor, global director of application security technology at Trend Micro fantastic system.
[38:26] Mike:
Thank you, Vance. And thanks everyone for watching.
[38:29] Vance:
And one quick note, as I mentioned, we've got these links here but we couldn't fit everything here in the Trend Micro breakout room. There's so much going on and at the company. So here is a slide that is full of links that will take you to some other great deeper dive resources at Trend Micro to get this great list. Just download my slides and all these links will be live. Thanks again, everyone.
