>>this session will be reviewing the power benefits of implementing a secure software supply chain and how we can gain a cloud like experience with flexibility, speed and security off modern software delivery. Hi, I'm Matt Bentley, and I run our technical pre sales team here. Um Iran. Tous I spent the last six years working with customers on their container ization journey. One thing almost every one of my customers is focused on how they can leverage the speed and agility benefits of contain arising their applications while continuing to apply the same security controls. One of the most important things to remember is that we are all doing this for one reason, and that is for our applications. So now let's take a look at how we could provide flexibility all layers of the stack from the infrastructure on up to the application layer. When building a secure supply chain for container focus platforms, I generally see two different mindsets in terms of where the responsibilities lie between the developers of the applications and the operations teams who run the middleware platforms. Most organizations are looking to build a secure yet robust service that fits the organization's goals around how modern applications are built and delivered. Yeah. First, let's take a look at the developer or application team approach. This approach follows Mawr of the Dev ops philosophy, where a developer and application teams are the owners of their applications. From the development through their life cycle, all the way to production. I would refer this more of a self service model of application, delivery and promotion when deployed to a container platform. This is fairly common organizations where full stack responsibilities have been delegated to the application teams, even in organizations were full stack ownership doesn't exist. I see the self service application deployment model work very well in lab development or non production environments. This allows teams to experiment with newer technologies, which is one of the most effective benefits of utilizing containers and other organizations. There's a strong separation between responsibilities for developers and I T operations. This is often do the complex nature of controlled processes related to the compliance and regulatory needs. Developers are responsible for their application development. This can either include doctorate the development layer or b'more traditional throw it over the wall approach to application development. There's also quite a common experience around building a center of excellence with this approach, where we can take container platforms and be delivered as a service to other consumers inside of the I T organization. This is fairly prescriptive, in the manner of which application teams would consume it. When examining the two approaches, there are pros and cons to each process. Controls and appliance are often seen as inhibitors to speak. Self service creation, starting with the infrastructure layer, leads to inconsistency, security and control concerns, which leads to compliance issues. While self service is great without visibility into the utilization and optimization of those environments, it continues the cycles of inefficient resource utilization and the true infrastructure is a code. Experience requires Dev ops related coding skills that teams often have in pockets but maybe aren't ingrained in the company culture. Luckily for us, there is a middle ground for all of this Doc Enterprise Container Cloud provides the foundation for the cloud like experience on any infrastructure without all of the out of the box security and controls that are professional services Team and your operations team spend their time designing and implementing. This removes much of the additional work and worry Run, ensuring that your clusters and experiences are consistent while maintaining the ideal self service model, no matter if it is a full stack ownership or easing the needs of I T operations. We're also bringing the most natural kubernetes experience today with winds to allow for multi cluster visibility that is both developer and operator friendly. Let's provides immediate feedback for the health of your applications. Observe ability for your clusters. Fast context, switching between environments and allowing you to choose the best in tool for the task at hand. Whether is three graphical user interface or command line interface driven. Combining the cloud like experience with the efficiencies of a secure supply chain that meet your needs brings you the best of both worlds. You get Dave off speed with all the security controls to meet the regulations your business lives by. We're talking about more frequent deployments. Faster time to recover from application issues and better code quality, as you can see from our clusters we have worked with were able to tie these processes back to real cost savings, riel efficiency and faster adoption. This all adds up to delivering business value to end users in the overall perceived value. Now let's look at see how we're able to actually build a secure supply chain. Help deliver these sorts of initiatives in our example. Secure Supply chain. We're utilizing doctor desktop to help with consistency of developer experience. Get hub for our source Control Jenkins for a C A C D. Tooling the doctor trusted registry for our secure container registry in the universal control playing to provide us with our secure container run time with kubernetes and swarm. Providing a consistent experience no matter where are clusters are deployed. You work with our teams of developers and operators to design a system that provides a fast, consistent and secure experience for my developers that works for any application. Brownfield or Greenfield monolith or micro service on boarding teams could be simplified with integrations into enterprise authentication services. Calls to get help repositories. Jenkins Access and Jobs, Universal Control Plan and Dr Trusted registry teams and organizations. Cooper down his name space with access control, creating doctor trusted registry named spaces with access control, image scanning and promotion policies. So now let's take a look and see what it looks like from the C I c D process, including Jenkins. So let's start with Dr Desktop from the doctor desktop standpoint, what should be utilizing visual studio code and Dr Desktop to provide a consistent developer experience. So no matter if we have one developer or 100 we're gonna be able to walk through the consistent process through docker container utilization at the development layer. Once we've made our changes to our code will be able to check those into our source code repository in this case, abusing Get up. Then, when Jenkins picks up, it will check out that code from our source code repository, build our doctor containers, test the application that will build the image, and then it will take the image and push it toward doctor trusted registry. From there, we can scan the image and then make sure it doesn't have any vulnerabilities. Then we consign them. So once we signed our images, we've deployed our application to Dev. We can actually test their application deployed in our real environment. Jenkins will then test the deployed application, and if all tests show that is good, will promote the r R Dr and Mr Production. So now let's look at the process, beginning from the developer interaction. First of all, let's take a look at our application as is deployed today. Here, we can see that we have a change that we want to make on our application. So marketing Team says we need to change containerized injure next to something more Miranda's branded. So let's take a look at visual studio coat, which will be using for I D to change our application. So here's our application. We have our code loaded, and we're gonna be able to use Dr Desktop on our local environment with our doctor desktop plug in for visual studio code to be able to build our application inside of doctor without needing to run any command line. Specific tools here is our code will be able to interact with docker, make our changes, see it >>live and be able to quickly see if our changes actually made the impact that we're expecting our application. Let's find our updated tiles for application and let's go and change that to our Miranda sized into next. Instead of containerized in genetics, so will change in the title and on the front page of the application, so that we save. That changed our application. We can actually take a look at our code here in V s code. >>And as simple as this, we can right click on the docker file and build our application. We give it a name for our Docker image and V s code will take care of the automatic building of our application. So now we have a docker image that has everything we need in our application inside of that image. So here we can actually just right click on the image tag that we just created and do run this winter, actively run the container for us and then what's our containers running? We could just right click and open it up in a browser. So here we can see the change to our application as it exists live. So once we can actually verify that our applications working as expected, weaken, stop our container. And then from here, we can actually make that change live by pushing it to our source code repository. So here we're going to go ahead and make a commit message to say that we updated to our Mantis branding. We will commit that change and then we'll push it to our source code repository again. In this case we're using get Hub to be able to use our source code repository. So here in V s code will have that pushed here to our source code repository. And then we'll move on to our next environment, which is Jenkins. Jenkins is gonna be picking up those changes for our application, and it checked it out from our source code repository. So get Hub Notifies Jenkins. That there is a change checks out. The code builds our doctor image using the doctor file. So we're getting a consistent experience between the local development environment on our desktop and then and Jenkins or actually building our application, doing our tests, pushing in toward doctor trusted registry, scanning it and signing our image. And our doctor trusted registry, then 2.4 development environment. >>So let's actually take a look at that development environment as it's been deployed. So here we can see that our title has been updated on our application so we can verify that looks good and development. If we jump back here to Jenkins, will see that Jenkins go >>ahead and runs our integration tests for a development environment. Everything worked as expected, so it promoted that image for production repository and our doctor trusted registry. Where then we're going to also sign that image. So we're signing that. Yes, we have signed off that has made it through our integration tests, and it's deployed to production. So here in Jenkins, we could take a look at our deployed production environment where our application is live in production. We've made a change automated and very secure manner. >>So now let's take a look at our doctor trusted registry where we can see our game Space for application are simple in genetics repository. From here we will be able to see information about our application image that we've pushed into the registry, such as Thean Midge signature when it was pushed by who and then we'll also be able to see the scan results of our image. In this case, we can actually see that there are vulnerabilities for our image and we'll actually take a look at that. Dr Trusted registry does binary level scanning, so we get detailed information about our individual image layers. From here, these image layers give us details about where the vulnerabilities were located and what those vulnerabilities actually are. So if we click on the vulnerability, we can see specific information about that vulnerability to give us details around the severity and more information about what, exactly is vulnerable inside of our container. One of the challenges that you often face around vulnerabilities is how, exactly we would remediate that and secure supply chain. So let's take a look at that and the example that we were looking at the vulnerability is actually in the base layer of our image. In order to pull in a new base layer of our image, we need to actually find the source of that and updated. One of the ways that we can help secure that is a part of the supply chain is to actually take a look at where we get our base layers of our images. Dr. Help really >>provides a great source of content to start from, but opening up docker help within your organization opens up all sorts of security concerns around the origins of that content. Not all images are made equal when it comes to the security of those images. The official images from Docker, However, curated by docker, open source projects and other vendors, one of the most important use cases is around how you get base images into your environment. It is much easier to consume the base operating system layer images than building your own and also trying to maintain them instead of just blindly trusting the content from doctor. How we could take a set >>of content that we find useful, such as those base image layers or content from vendors, and pull that into our own Dr trusted registry using our rearing feature. Once the images have been mirrored into a staging area of our DACA trusted registry, we can then scan them to ensure that the images meet our security requirements and then, based off the scan result, promote the image toe a public repository where we can actually sign the images and make them available to our internal consumers to meet their needs. This allows us to provide a set of curated content that we know a secure and controlled within our environment. So from here we confined our updated doctor image in our doctor trust registry, where we can see that the vulnerabilities have been resolved from a developers point of view, that's about a smooth process gets. Now let's take a look at how we could provide that secure content for developers and our own Dr Trusted registry. So in this case, we're taking a look at our Alpine image that we've mirrored into our doctor trusted registry. Here we're looking at the staging area where the images get temporarily pulled because we have to pull them in order to actually be able to scan them. So here we set up nearing and we can quickly turn it on by making active. Then we can see that our image mirroring will pull our content from Dr Hub and then make it available in our doctor trusted registry in an automatic fashion. So from here, we can actually take a look at the promotions to be able to see how exactly we promote our images. In this case, we created a promotion policy within docker trusted registry that makes it so. That content gets promoted to a public repository for internal users to consume based off of the vulnerabilities that are found or not found inside of the docker image. So are actually users. How they would consume this content is by taking a look at the public to them official images that we've made available here again, Looking at our Alpine image, we can take a look at the tags that exist. We could see that we have our content that has been made available, so we've pulled in all sorts of content from Dr Hub. In this case, we have even pulled in the multi architectural images, which we can scan due to the binary level nature of our scanning solution. Now let's take a look at Len's. Lens provides capabilities to be able to give developers a quick, opinionated view that focuses around how they would want to view, manage and inspect applications to point to a Cooper Days cluster. Lindsay integrates natively out of the box with universal control playing clam bundles so you're automatically generated. Tell certificates from UCP. Just work inside our organization. We want to give our developers the ability to see their applications and a very easy to view manner. So in this case, let's actually filter down to the application that we just deployed to our development environment. Here we can see the pot for application and we click on that. We get instant, detailed feedback about the components and information that this pot is utilizing. We can also see here in Linz that it gives us the ability to quickly switch context between different clusters that we have access to. With that, we also have capabilities to be able to quickly deploy other types of components. One of those is helm charts. Helm charts are a great way to package of applications, especially those that may be more complex to make it much simpler to be able to consume inversion our applications. In this case, let's take a look at the application that we just built and deployed. This case are simple in genetics. Application has been bundled up as a helm chart and has made available through lens here. We can just click on that description of our application to be able to see more information about the helm chart so we can publish whatever information may be relevant about our application, and through one click, we can install our helm chart here. It will show us the actual details of the home charts. So before we install it, we can actually look at those individual components. So in this case, we could see that's created ingress rule. And then it's well, tell kubernetes how to create the specific components of our application. We just have to pick a name space to to employ it, too. And in this case, we're actually going to do a quick test here because in this case, we're trying to deploy the application from Dr Hub in our universal Control plane. We've turned on Dr Content Trust Policy Enforcement. So this is actually gonna fail to deploy because we're trying to deploy application from Dr Hub. The image hasn't been properly signed in our environment. So the doctor can to trust policy enforcement prevents us from deploying our doctor image from Dr Hub. In this case, we have to go through our approved process through our secure supply chain to be able to ensure that we know our image came from, and that meets our quality standards. So if we comment out the doctor Hub repository and comment in our doctor trusted registry repository and click install, it will then install the helm chart with our doctor image being pulled from our GTR, which then has a proper signature, we can see that our application has been successfully deployed through our home chart releases view. From here, we can see that simple in genetics application, and in this case we'll get details around the actual deploy and help chart. The nice thing is that Linds provides us this capability here with home. To be able to see all the components that make up our application from this view is giving us that single pane of glass into that specific application so that we know all the components that is created inside of kubernetes. There are specific details that can help us access the applications, such as that ingress world that we just talked about gives us the details of that. But it also gives us the resource is such as the service, the deployment in ingress that has been created within kubernetes to be able to actually have the application exist. So to recap, we've covered how we can offer all the benefits of a cloud like experience and offer flexibility around dev ups and operations controlled processes through the use of a secure supply chain, allowing our developers to spend more time developing and our operators mawr time designing systems that meet our security and compliance concerns

>>law from Las Vegas. It's the Q covering a ws re invent 2019. Brought to you by Amazon Web service is and in along with its ecosystem partners. >>Okay, Welcome back, everyone. Cube coverage. Las Vegas live action. It was re invent 2019 3rd day of a massive show where our seventh year of the eight years of Abel documenting the history and the rise in the changing landscape of the business. I'm John for Bruce. To Minutemen, my co host. Our next guest Bill McGee, senior vice president, general manager of the Hybrid Cloud Security group within Trend Micro. So, this company, those guys now lead executive of the Cloud Hybrid. I have rid Cloud Security hybrid in there looking cute. >>And I've been to every reinvent, every single one. >>Congratulations. Thank you. >>Thank you. Nice to be >>here. So, eight years, what's changed in your mind? Real quick. >>Uh, wow. The Yeah, certainly. The amount of a dot Uh, the amount of adoption is now massive mainstream. You don't have the question. Should I go to the cloud? It's all about how and how much. Probably the biggest change we've seen is how it's really being embraced all around the world where a global company we saw initially a US on Australia type focused you K. Now it's all over the place and it's really relevant everywhere, >>you know, at least from my standpoint. And I have enough friends of mine in the security industry. When we first started coming to show, I mean security was here. Security is not only is so front and center in the discussion of cloud that they had all show for it here, so you know, it gives the 2019 view of security inside that the broader hybrid cloud discussion here, a re >>investor. Let me tell you a couple of things, kind of what we're seeing within our customer base and then what matters from a security perspective. So we see, you know, some organizations doing cloud migration moving. We're close to the cloud of various forms. Had a couple of meetings yesterday. One was college evacuating their data center. The other one was celebrating that two weeks ago they closed their data center, So that's a big step. Windows and Lennox workloads moving to the cloud and really changing existing security controls toe work better in the cloud. But certainly what a lot of these cloud builders are here for is, you know, developing cloud native applications. Originally back 78 years ago, that was on top of what's now seem like pretty simple. Service is like s three E. C two. I've got containers and server lists and other platforms that that people are using. And then the last thing. A lot of companies are establishing a cloud centre of excellence, and they're trying to optimize the use of the cloud. They still have compliance requirements that they need to achieve. So these are what we see happening and really the challenge for the customer. How do we secure all this? How do we secure the aggressive, aggressive cloud Native application development? How do we help a customer achieve compliance easily from a cloud centre of excellence? So that's where we see us fitting. And we made a big announcement a couple of weeks ago about a new platform that we've created. I would love to talk to >>love that. Let's dig into that. But first we were at reinforces Amazons First security, Carver's David Locked and I were talking about cloud security was on Prem security and then what's happening here and had a conversation with someone who was close to the C I. A. Can't say his or her name. And they said Cloud has changed the game for them because they're cost line was pretty much flat. But the demand for missions were squirrels going scaling. So we're seeing that same dynamic. You were referring to it earlier that costs and data centers is kind of flat. But the demand for application new stuff's happened, so there's a real increased her demand for APS. Sure, this is the real driver, how people are flexing and deploying technology. So the security becomes really the built in conversation, cracked comment on that dynamic. And what do you recommend? Well, so here's a couple >>of things we've seen, Really? You know, again, we've been doing private security for about a decade, and really it was primarily focused on one service of eight of us, which is easy to now that's a pretty darn big service and widely used within their customer base. There's no 170 service's, I think is the most recent number. So the developers are embracing all these new service is we acquired a new capability in October. Company called Cloud Conformity, based in Sydney, Australia, very focused on AWS, analyzes implementations against the eight of US well-architected framework. So the first step we see for customers is you gotta get visibility into use of the cloud for the security team. What service is air being used, then? Can you set up a set of security guard rails to allow those service is to be used in a secure manner. Then we help our customers turn to more detailed, specialized protection of easy to or containers or server list. So that's what we've recognized ourselves. We had to create a very modest version of what Amazon has created themselves, which is a platform that allows builders to connect to and choose what security service is they want. >>Road is your service bases and all the service's air. You guys now pick and choose the wall. Yeah, there's a main ones. What does highlight? So >>there's Yeah, I'll give you the ones where we provide a very large breath of protection. So in the what we're calling Cloud one conformity service. So that's this technology we acquired a couple months ago. It cuts across about 70 service is right now and gives you visibility of potential security configuration errors that you have in your environment now if it's in a deaf team, maybe not such a big deal. But if it's in production, that is a big deal. Even better, you can scan your cloud formacion templates on the way to being live. Then we have a set of specialized protection that you know will run on a workload and protect it protected containerized environment. A library that can sit within a server lis application. That's kind of how we look at it. All right, >>So, Bill, one of things of going to the more and more cloud for customers is that there's that shared responsibility. Modern. We know that security is everyone's responsibility. It needs to be built in from the ground up. How are your customers doing with that shift? And are they understanding what they need to do? There have been some pretty visible, like a weight. I really had to configure that. I've thought about that Amazons trying to close the gap on song. But for some of those, >>we've seen a big positive change over the years. Initially I would say that there was what I would call a naive perception that the cloud with magic and it was perfectly secure and that I don't have to worry about it, right. Amazon data did the industry a real favor by establishing the shared responsibility model and making crystal clear what they've got covered that you don't need to worry about anymore as a customer. And then what are the capabilities you still need? Toe worry about? They've delivered a set of security tools that help their customers, and then they rely on partners like us. Thio deliver a set of more in depth tools. Thio, you know, specialized market. >>You actually used a word that we've been talking about a lot this week. Naive. Yeah. So we said, there's, you know, the one letter difference between being cloud native meeting Cloud naive there. Yeah. What does it mean to be cloud native in the security world? >>Well, I would say what allows you to be so first, the most important thing in every customer's mind. I don't care how good the security capabilities you're helping with me with. If you're going to slow down the improvements that I've just made to my development lifecycle. I'm not interested. So that is the most important thing is, are you able to inject your security technology and allow the customer to deliver at the rate that they're currently or continuing to improve? That is by far the most important thing. Then it's our your controls, fitting into an environment in a way that that are as easy as possible for the customer. One part that's been very critical for us. We've been a lead adopter of the AWS marketplace, allowing customers too procure security technology easily. They don't actually have to talk to us to buy our product. That's pretty revolutionary >>about the number of breaches that I'm going on, What's changed with you guys over the year because new vectors air coming out at this more surface area. Obviously, it's been discussed. What's changed most in your I'll >>tell you what we're worried about and what we expect to see, although I would say the evidence. It's early, uh, the reality in our traditional data centers. They were so porous at runtime in terms of the infrastructure and vulnerabilities that it was relatively easy for Attackers to get in the cloud has actually improved the level of security because of automation, less configuration errors. Unfortunately, what we expect his Attackers >>to move to. >>The developers moved to the depth pipeline, injecting code not a run time, but injecting it earlier in the life cycle. We've seen evidence of container images up on Dr Hub getting infected and then developers just pulling in without thinking about it. That's where Attackers are going to move to the depth pipeline. And we need to move some of our security technology to the dead pipeline toe, help customers defend themselves. >>What about International Geo Geo issues around compliance. How is that changing the game or slowing it down? Or I'm sailing it or you talk about that dynamic with regions? Are you >>sure you know us is the most innovative market and the most risk taking market, and therefore people moved to the cloud quite bravely over this over this decade. Some of the markets So, for example, were Japanese headquarters company. In general, Japanese companies, you know, really taken to a lot of considerations before they make that type of big bet. But now we're seeing it. We're seeing auto manufacturers embrace the cloud. So I think those it was a struggle for us in the early days. How regional the adoption of Cloud was. That's not the case anymore. It's really a relevant conversation in every one of our markets. >>Bill. Thank you for coming on the Cuban Sharing your insights Hybrid Cloud Security Got to ask you to end the segment. Yeah, What is going on for you This year? I'll see hybrids in your title. Operating models. Cloud center, gravity clouds going to the edge or data center. Just operate model. What's on your mind this year? What are you trying to do? Accomplish what you excited >>about? What? We're really excited about what this product announcement we made, called Cloud One. And what Cloud one is, is a set of Security Service's, which customers can access through common common access common building infrastructure, common cloud account management and choose what to use. You know, Andy put it pretty well in his keynote where you know he talked about He doesn't think of aws, a Swiss Army knife. He thinks of it as a specialized set of tools that builders get to adopt. We want to create a set of security tools in a similar way where customers can choose which of these specialized security service is that they want to adopt >>Bill. Great pleasure to meet you and have this conversation pro and then security area entrepreneur sold his company to Trend Micro. This is the hybrid world. It's all about the cloud operating model. So about agility and getting things done with application developers. This cube bringing all the data from reinvent stables for more coverage after this short break.