Cloud Native
How to Best Secure All Your Cloud Native Environments
Hear from Ian Heritage about the security challenges surrounding weak configurations, container and serverless threats in cloud-native environments, and strategies that help you build secure and ship fast on AWS.
Transcript
Ian Heritage [0:02] I'm Ian Heritage, and I'm a cloud security architect at Trend Micro. The pressure is on to deliver business applications at lightning speed. There are some key considerations that you need to think about before making these changes. The considerations when transforming, businesses are looking at increasing flexibility, improving scalability, making changes very quickly, and experimenting and learning, especially from customer journeys. The benefits of containers that are up in minutes, serverless technology that can be built from the ground up from infrastructure as code within seconds.
Ian Heritage [0:42] If you take a typical pipeline in cloud native of what we see today, everything starts from the developer ecosystem, and shifts right into that runtime environment. So you'll be developing applications, whether that be images and functions. And you'll be developing the boiler templates or the blueprints out there to instantiate infrastructure as code that will be building up the cloud deployments, whether that be serverless, container platforms. And I really like this diagram from Lachlan White, that looks at the cloud native shared responsibility model. This takes what we've seen in the past where we've got traditional AI teams with on premise infrastructures, the shift to hybrid it environments. And you can see the shift in a Hybrid IT environment where we see most customers today, where that DevOps processes and teams have now been involved to abstract, separate teams into different processes. But if you shift to the right hand side, where we've got cloud native, this is really where we've got to start thinking that everything must be done as code. So take the GitOps lifecycle, where everything started from the developer, and moving to that operations team. But everyone needs to have an element of understanding where they fit in that lifecycle, in a true sense that everything is done by code. So those containers as a service, and functions as a service, they've got no user interaction whatsoever. And the key thing about that responsibility model, the core component of all of these, we're trying to keep the data safe, and the applications highly available. And I mentioned DevOps, and that has coupled the change in responsibilities, especially in the security world. And the key concept here is the application security and compliance doesn't have to be one team's responsibility. If you look at the frameworks and standards out there, you might be looking at a framework such as NIST, to look at how you're looking at securing your application, you might be under a highly regulated environment, and you're looking at PCI, and you need to know those common standards out there. You might be looking at OWASP to protect your applications, or understand how they might be attacked. You might be looking at the AWS well architected framework to use those five pillars to build your application and improve on it over time. You might be looking at the Mitre ATT&CK framework to understand how a nation state sponsored attack is going to attack your application. Out of all of the standards regulation and compliance frameworks, there's got to be an understanding of how developing applications at that lightning speed, you can incorporate all of these standards in that process. Put yourself in the position of that SecOps team, and the sec operations team need to get visibility into the pipelines that you're developing. We know from research that visibility decreases further left in that pipeline, from a sec operations point of view. It is now our opportunity to be building in relevant feedback from a security point of view, but also putting in the gates to not even get into runtime to prevent the threats from happening. The people, process and technology is one of the core concepts that we need to be thinking about when we are trying to understand the security teams challenges. Modern apps teams are now decentralized. They have very tight integrations of how their how their application works. But they are fundamentally in separate silos. And if we look at the security team, they need centralized visibility of all of these modern apps teams. So it's now our responsibility to be building, building fast, but also building secure, transformative controls with inside these pipelines.
Ian Heritage [4:44] Now if we look at the top security risk to applications. Now there's a few here that I've put up on the screen and there are many more out there. But some of the concepts where we're looking at vulnerable components being introduced in the far left. If we can prevent those vulnerable components from being added into that pipeline, there are huge benefits to be had. To prevent an exploit is the key benefit there. If you're not introducing vulnerable, vulnerable code or vulnerable libraries, then we're going to stop that attack from happening in the runtime environments. If we look at misconfigurations, if we're going with a common standard, like the AWS well architected framework, and using that as a boiler template, to make sure that all of these applications and discrete services are speaking to each other, we need to be monitoring over time, the integrations and making sure that any misconfigurations are really, we want to put the guardrails in place to stop that from ever happening, but also be alerted in real time. If that does happen. It does happen. And then we've got our web applications out there, protecting them from cross site scripting, vulnerabilities, SQL injection from exfiltrating data, these are all the top of concerns that security professionals in your business has today. One of the key attacks that we're seeing more and more is that attackers are borrowing your resources. What do we mean by that? We mean that if someone gets into your pipeline incorporates a piece of code to do some crypto mining, or something like that, if you're incorporating that, and then they're using your, your CPU cycles or your virtual CPU cycles, they're going to be monetizing that data. And the key part is to ask you a question, how are you not introducing the risk into those pipelines at every single phase, so are you putting in the relevant gates in those processes.
Ian Heritage [6:47] Now, I've called these basics, but they're not necessarily basics all the time. But it's all about from a container security point of view, sometimes just doing the basics right, or starting off with some of these key principles. The first principle is scanning your images for vulnerabilities. If we can get that highly critical advance, notice that you've got a CV, a CV within inside one of your libraries, then we can provide that fast feedback to the development team to maybe upgrade it, or if we can go even further left in the actual code, and prevent that from being incorporated even with inside an image, and the benefits are there also. Detecting configuration defects, scanning for malware, so stopping that crypto miner you might be downloading from a public source or open source library that may have been infiltrated. Checking for secrets in content. We know time and time again, unfortunately, images contain secrets. And they used in other attacks, other attacks to go into into the cloud cloud infrastructure, spin up certain workloads or to cause havoc with inside that environment. And ensuring after you've done all of those processes, ensuring that images are actually trusted. So once you've done all of those preflight checks, are you ensuring that those images are trusted, and that only trusted images can run within inside the environment itself? And are you providing that feedback in a fast way? So are you providing your developers in Slack, the automated alert that something needs to be fixed? Or are you even better providing operations team extra visibility, that they might have something to enact upon here?
Ian Heritage [8:38] And when it comes to containing security and incident investigation, I look at asking these three questions when we're looking at any threat. What was affected? What was added? And where did it spread? The key thing with that is that we want to get that instant feedback. So software in the build pipeline, if we can build those checks or build those gates in the build pipeline phase, and that's the key benefit there that we can stop that from being instantiated with inside the running runtime environment. If we're seeing attacks against running applications, could we've prevented that vulnerability from being introduced? well ahead of time, or in the runtime environment, can we make sure that we're embedding security controls that can live with the application itself, not dependent on the host attacks against the container platforms are growing more and more, and we're also seeing attacks against the operating systems, hosting those containers as well. This is an enterprise dashboard from our container security product here at Trend Micro. And this is exactly what someone in the sec operations team would want to use. That gives them the ability to identify: have all of our images been scanned? Do any items need attention? What has been scanned in that in that image layer, in all of the image layers? The benefits that you have here, is that you've got the malware information, you've got content findings that the security operations team, or the Sec ops team can actually put in inside that intelligence, for example, we've also got vulnerability information, as I said, if you can feed that vulnerability information into the scanners, and we're able to identify early on the vulnerabilities that may exist in that code. And also, we've recently teamed up with Snyk, to actually add in open source vulnerabilities into this as well. So you get those findings from within that console. But here's a console from a CI/CD or development pipeline point of view, you want those calls to be going in real time. So this is where a CLR, or an API system can provide those alerts in real time.
Ian Heritage [10:57] And I mentioned the runtime phase. So application security, if you're using containers and functions such as Lambda, you need to really choose your deployment, but also use security tooling around that. If you're looking to protect AWS Fargate, ECS, or EKS, with inside container environments, are you able to embed security controls, if that image has been instantiated, but what if it's being put under attack? Could you build in a runtime application security control with inside the application? From AWS Lambda, we know these exist for seconds, the key ability there is your sec operations team to understand what is being put under attack and where those risks are. So if I just take, you know, a scalable security for AWS, where, with this may be a typical example for one of your applications that you're looking at protecting, you might have AWS Lambda that that's being instantiated by another team, but they need to embed security to understand what's going up, what's going down, is anything being put under attack. From an Amazon S3 point of view, if you had a, I don't know, an insurance application, where if you had a car accident, and those images were being uploaded into an S3 bucket, what would happen if a code handler downloaded that and there might be a piece of malware with inside one of those documents? Our file storage scanning allows you to actually provide protection into the workflow and S3 bucket and provide our intelligence, Trend Micro threat intelligence with inside that and scan those in real time. Preventing your customers from being infected, potentially, with malicious malware.
Ian Heritage [12:45] And from a code pipeline point of view, if you're doing those code builds, and you're building those images, and you're using something like ECR, do you have an ongoing scanning ability? Or do you have the ability to stop a vulnerability that's going into an image to be prevented from when it's going into that? I would say that thinking about the future is about prepared preparation. It's about investing in integration of security as part of the application development phase. It's about helping security teams to modernize delivery, by using some of these key controls at the various different gates. And it's also about integrating security people process and tools throughout that development lifecycle.
Ian Heritage [13:31] If we look at the Trend Micro Cloud One platform, we've built a platform that caters for the cloud builder, whether you're looking to build cloud native applications, and you need to secure your cloud workloads, your containers, your servers, there's a platform to do that, and instantiate that in an API friendly way. If you're looking at lifting and shifting some of your legacy applications or monolithic applications that are on underlying Windows or on Linux hosts, we can provide a protection of security controls around that to make sure that your application is going to be compliant to the frameworks that we spoke about. And last up, at least is declared operational excellence part. Do you have a way of adding templates or blueprints around your cloud infrastructure in AWS, and making sure that that well architected framework is both assured and the ongoing governance to make sure that that's in place is adhere to, and making sure that those compliance reports are being provided when you're under tight regulations? You know, lots of these rules that we're building now are against common frameworks that you'll be familiar with.
Ian Heritage [14:52] So I just want to leave you with that. A thank you note from me, Ian Heritage, one of the cloud security architects at Trend Micro. Thank you very much.
