 Well hello everybody. My name is Ashley Ward. I work for a company called Twistlock. I've been lucky enough to come along here to talk to all of you about shift-left security and how that can actually benefit everything there. So my background, I'm an infrastructure guy where I was. I started out as a Unix admin before a utilities company before moving and working for Sky TV actually as an infrastructure architect and then more recently into financial services and now I find myself as a vendor. Now, I do a lot of talks but for some reason I'm particularly nervous about this one and I was trying to think why that was and I think it's because this is Cloud Foundry and as an X open shift, a recovering open shift chat, maybe that's where I'm getting my nerves from. But anyway, we're going to talk about shift-left security. Let's see what we've going to cover today. So what is shift-left security? We're going to go through some of that. I mean it's an overused term in my opinion but it's actually something that's very important and it's actually something that if done properly will enhances everybody's security. So yes, I'm a security vendor. Yes, I want you to keep to buy the product so that I get new t-shirts and this kind of thing. But also I have a vested interest in us all doing security better. Now in the Cloud Foundry Summit and all the vendors that you speak to, this is now a core thing. My credit card details got lost with by British Airways just recently. So it is, it's a core thing that impacts all of us. So what is shift-left security? We'll talk about that. We'll talk about why it's important. It's kind of one of those ones I always remember being battered over the head with we want to do test-driven development. We want to have automated tests at every step and it used to be very painful for me as an infrastructure guy to go, right, well I'll write some puppet code or I'll do something like this. But it's quicker for me just to write a shell script rather than do all this automated testing. So we'll talk about why it is important. We'll talk about how you enable it. So how you, as a security person, how you as a platform person, how you as a DevOps team or a developer, how you can actually enable some of this. And then we'll hopefully have some time for some Q&A as well. All right. So where, what's the stage? What are we setting here? Why is this important as we said? A lovely marketing term. Software is eating the world. I mean it is marketing term but it is true. If you think about it, every org is becoming a software organization and I don't just mean disruptors. I don't just mean Uber coming in and saying that this is now how we all order taxis. I mean things like, well my British Airways example, I certainly never book any of my flights for coming here. It's all done online. It's how we order groceries or it's how I order groceries. It's how we order birthday presents and Christmas presents. It's how we do all these different things. And of course, software organizations, they need modern tooling. Something I'll go into a few times and I want to be very clear. There's nothing wrong with how we've done stuff. It's just we have an opportunity to make things better. Okay. Then DevOps, containers, cloud native, all these kind of cool new toolings that are coming in place. Well, what are they all for? They're all to speed up that delivery that we're doing. And I know, you know, I usually get to give these talks at maybe people who are just starting out with containers. I get to these talks to people who are just entering. They see Docker coming into their enterprise or they see platforms as a service and I'm fully conscious that here I'm probably preaching to the choir on a lot of these things. We'll go through those anyway. The world is dangerous. Well, yeah, the world has always been a dangerous place. But the world, the danger and the risks are changing. We see the democratization of attacks. So what does that mean? Well, you can very easily get a hacking toolkit online. The actual way that attacks are happening now are changing as well. So we've got companies where you would be afraid before of intellectual property theft, someone trying to steal your actual hard-earned money or your user's data, customer data. And actually, we've got other risks. We've got people who are just looking to steal your CPU cycles. Tesla, it was a wonderful example. I mean, what a smart attack they had all because of that Kubernetes control plane. And then your own software is the softest target. Well, I mean, is that fair? Probably not. But it certainly is something where if you're developing your own software, as you are as a software company, then nobody else is policing that software for you. That is something that you would need to do. Another lovely little quote here. Only 20% of organizations following DevOps practices consistently integrate security into the development process. This was a survey. It was about last year. But there's that big shift of developments. We are developing faster. We are trying to meet those needs of our business customers, our external customers who have a stronger desire to see new software and new features coming out on all that business benefit. But we're not necessarily integrating security into that. Another lovely quote for you, you see? I've done all the legwork. Only 15% of organizations can remediate security vulnerabilities or address compliance violations as they arise. And that was a survey that Chef did. That was tail end of 2017. So what this is talking about is that we're delivering software faster because we have to, for all that business benefit, software eating the world, all that kind of good thing. We're sometimes embedding some security into that. And she's doing that bit of shift-lifting. But we're not actually able to respond to those threats in production. And that's a big deal. So shift-left security. Testing before you deploy. Compliance requirements when you build. So we've taken, if you think about all the agile delivery methodologies that we've got, and it is all about delivering that exact minimum viable product, that exact information that the business needs and the business wants, no longer assuming as IT that the business will want all the different bells and whistles, but actually delivering iteratively what they need. We've done a lot of work in that regard. So grooming backlogs. We've been looking at building, bringing the business into scrum teams or into development teams to try and get that actual value that's coming. But we're not necessarily doing that with security. So moving security practices left into the software development life cycle with the goal of shifting from a reactive to a proactive security posture. It is just the same as we've been doing with the business, but this time bringing security in. All right. Really great hearing me talk about it, but it's quite difficult to do. What's the reason for this? Well, if you look at traditional security, in my experience and in some of the stuff we see from a lot of our customers, security is almost a separate group. They're on a pedestal in a company. They're perhaps only being involved in that production realm and not seeing stuff that are coming through dev. And this isn't the fault. I'm not saying security is bad as security with an S for the team. They're not bad guys. This is driven by necessity. We had to be very secretive about our security. Security was hidden away and it was a separate team. So those people who are doing security, they've got a very different deliverable to those who are developing applications. So as we've got there in the second point, developers in security have very different domain expertise. And in fact, there was a cloud passage and I'm going to go and check my notes so I get the actual thing right on this one. There was a cloud passage report that came out and it was the tail end of 2016. So a little bit out. And it was talking about how of the top 50 cybersecurity graduate programs in the US, only three of them had a requirement for a cybersecurity pass rate. So sorry, computer science programs in the US. Top 50. Computer science graduate programs. Only three had a requirement to have any cybersecurity module in there. So we're actually teaching developers and DevOps people that security is a secondary thing. You've got security teams who are looking at this as a very important thing and keeping that all separate. So it's almost as if security's part of a club, whereas development's part of bringing business value in. Security by design, established criteria up front. Now if that means that you follow a methodology when you're delivering software where you have very rigid requirements that are spelled out in the beginning, and I know a lot of the industry were moving away from that because it's very difficult to know all those requirements up front, but you might still be in an industry where that's necessary. Great. In which case security should be coming into that. You might be in an industry where actually you're very iterative. You're actually looking at these things and bringing people in. Well, security should be part of that as well. And whether that's part of the compliance requirements that we all have now, or whether it's part of what the application is going to be doing. Automate, automate, automate. We've got to be automating now. We've got to bring security requirements that we've established in the beginning, and we've got to have that as part of the delivery process. Why? Well, we're no longer just having these dead projects, so it's no longer a case of define my requirements, build my project, throw out the door, and it's now operations that need to deal with it, and operational security and everybody else. We've got this ownership of the product, of the service. So without that automation for security, then we actually have a major gate problem. And talking about gates, control gates are actually your friend. So from a development point of view, and from a DevOps point of view, control gates are a pain. They've always been a pain. So I always like telling my story of a 20-year-old laddie in Scotland and getting root access and having full ownership of those big nasty Solaris servers that I worked with, Oracle servers now, I suppose not some. But having that root power and then being able to say when application developers came along and said, right, we've got this wonderful new thing that's going to make the company lots of money, and I'd look at it and say, well, there are vulnerabilities, there are compliance issues, so no. They would go away, they would do some more coding, they would make some more wonderful things, they would come back, and then they would say, right, we're going to go live with this, and I would go, no, because of these vulnerabilities and compliance. Now, more often than not, the business would win and say, well, we're just getting an exception put in place. This needs to be put out because it's going to make us lots of money. So that control gate is at the very end of the process and is delaying everything. And if you're delaying the business, the business is going to push past. But control gates can be your friend if they're brought right back up here and right to that shift left, because then you're actually fixing something before it hits prod and because the DevOps teams now own that production service as well, that control gate is their friend, sharing tooling, not siloing information. This ties back to that idea of you have a security team, you have developers, and neither the two shall talk to each other. And that obviously can't be happening. But if you come from a world where they are separate, so we're going back to those bad old days where I've got this separate security with a capital S team that's there, their requirements are very different to what a DevOps team or someone who wants to fix things is. So going back to that UNIX admin that I was, I recall often getting emails from security that would say, this CVE, tell us what it's on. What servers is this on? Well, I'll go up, right, fine. I'll go and have a look. I'd probably look up Sun's website or Red Hat's website, find out what on Earth this CVE is, then go around the whole estate, probably with an SSH and a for loop, to try and find out what is it that's out there. And then I'd come back and say, yes, I've found what it's on. It's on all these different things. They say, well, you need to resolve it. Well, I don't know how to do that. What is this? I'll try and patch it, but that's about it. But if you're sending an email in our new world to our DevOps teams to say you have CVE, blah, blah, blah, please fix it, that's helping nobody. There's no information there. There's no context. There's no risk. So if we share tooling and don't silo information, so at the time of finding a CVE, the DevOps teams get all the information that the security team would have, we're in a much better place. And then this is something that's going to come up again and again from the security and shifting left. It's not just about going right. Here are the vulnerability and compliance checks you have to do. Once that goes green, then you can deploy. And as a security person, I can sit back with my big cigar and just enjoy life. It's actually about going, no, all the learning that happens in those DevOps teams about the application, the software that we're building, that can be fed right into security. Security can actually have a better visibility of what the company is doing with that software. And doing that all the way through from dev, having that visibility, as soon as code's written, as soon as that thing gets produced, right the way through to prod. And that is better for everybody. All right. Nice white screen for everybody here, just to show you how nice white is. Containers and power security teams to shift left more successfully than traditional architectures. So where does twist up come from? This is what we believe. We believe containers do improve security. And we also believe that there's a lot of fear, uncertainty and doubt around containers. Now we can see with some of the announcements in Cloud Foundry about how the Kubernetes support those two lovely projects. I loved hearing this kind of thing. One of the things that could be causing concern is that if you go away from that platform as a service model and towards this container model, then you might be implicitly allowing, they're saying, yes, run other platforms, run other things across the estate. And you could actually be introducing that risk. Well, we believe that containers improve security such that you don't need to worry about that. Why? Just like your Cloud Foundry stuff, just that minimal single process entities. So this ties back into that. Well, what are those requirements? If we want to put security requirements in place, it's a lot easier if we've got small articles and we've got minimal things where we can say, this is what makes up our application, this part of the application. The declarative. We can do all this testing up front. We can say, this is what an image should do. This is what an image looks like. And we can police that image all the way along. And then predictability. Again, and I think this comes back to my nerves at the start of the talk. I do know that this is, you know, as a platform as a service thing, the Cloud Foundry starting out as, this is probably, you're going, yeah, of course. Well, this is actually quite new for a lot of people. And it's new for a lot of people if you think about it from a VM side of things, right? You would have a server. You would have a server that had the operating system on it. It would have any libraries that were needed for there. You would typically, especially when it was bare metal, have multiple services running in a single server. And that ties back to why I had access. I could say no to everyone because the server was more important than the service, individual service running on there. If you take that and transfer it now to containers, well, actually, the service is more important than the container itself. Because we're able to say that this is just a small unit inside it, it's got all the different DevOps teams, their libraries that they need, it's got the application code, it's so minimal, declarative and predictable that we can do better security all around that. Each artifact, security requirements for them. The conversation is easier when we go back to this idea of having, we've got this application, we want to put some testing in place, we want to have security requirements brought to the front. It's easier said than done while having these minimal artifacts really enables that. The declarative nature, automatic analysis of it for vulnerabilities and compliance, so it's easy to push those vulnerabilities and compliance scanning to the beginning. And the predictable nature, well, we can automate policy creation. Because we can say that every time something is spawned, it's the same as what that base image was. We can automate that security around there. And that's tying into that automate, automate, automate. So security by design, established criteria up front. Automate, automate, automate. Control gates are your friend. Share tooling. Don't style information. It's the same slide as before. But what is it that we're seeing here? Well, what we're trying to show you is that, yes, containers will help with much of this. So number one, number two, probably not the control gates, although you'd be able to build them in quite easily. Share tooling, well, containers themselves don't actually do that really. They're not helping us there for a security talking to DevOps thing. But they do allow us to do more learning with what's going on inside the container. So we could say that we meet kind of three out of those five. I'm sorry. They give me a t-shirt. I have to do a little bit of salesy stuff. I will keep it very light. Twistlock enables all of this and you should definitely give us lots of money so that we can keep doing that. Actually, what we're doing is even if you weren't to go for a platform like Twistlock, what we're saying is that you can, through the use of containers, get all that protection right up front and then actually onwards into what's actually running in your estate. And I was going to take out the little open shift logo that's there, but I thought I'll leave it and you guys will love that. Okay. Shift left, protection right. This is the dream. This is what we're all aiming for. This is what we want. Static analysis, vulnerability and compliance stuff there at the beginning. Machine learning, what is it that that's meant to do? We can automate what that container is doing so that regardless of what happens, if it's a bad actor, if it's something, an unknown exploit happens, what you know from that container, everything that's meant to run inside the container, all the ports that are meant to be open inside the container, you can and obviously Twistlock makes all this very easy and you should buy Twistlock, but you can actually also look and say, well, what activity should happen inside that container? So now regardless of where that container goes, regardless of how that container runs, whether it's on your lovely Cloud Foundry platform that's running Kubernetes over here, whether it's actually gone straight into AWS and their managed Kubernetes service or your own little docker machine that's running there, each container is going to do the exact same thing it was meant to do and you can automate all that learning and that gives you then this predictive model because we can predict what that container is going to do. We can take that threat intelligence information, we can combine that together and then we know not only what is the container going to do, but in running containers, if something comes out, a vulnerability is found, there's no point in just having an image scan and say, oh, my image is over here or these ones are green, these ones are red, but actually being able to have that immediate feedback back to development and this shift left thing here where we're saying this vulnerability is impacting production, it's now straight into that pipeline to come back through and be fixed. It's no longer a case of, well, this CVE is here, but I don't think it impacts us. In fact, a nice one there was going back to my being told to look at CVEs. I do remember looking at a service when I was doing stuff with a company, in fact that's all I'll say, looking at the different services that were running on our Red Hat machines and then going, I don't know why I've got this Bluetooth driver that's running. What's this for? Why is that there? That would be this information about what's in prod and easily feeding that back into dev. I keep carpet on about this, but really if we can build this in as early as possible, I genuinely think the tools are there now to do this. It's not like before where you would be saying, well, yeah, sure, by the time we have a six-week release cycle into prod, so actually if something comes up here, it will go into a different environment and then bundle through and by that point, actually patching a server as somebody else's job and they'll do it every 30 days after a scan and all this kind of stuff, we can really bring this through and automate that entire process. Questions. I've got this telling me I've got nine minutes left, so if there are any questions, I'm happy to answer any. Or you can take the advice of the nice lady before me and get more coffee. Are there any questions? Can I help anybody out with anything? Final chance? All right. Well, thank you very much for listening. If there are any questions or anything comes up, then my details are there, please send me emails, anything like this. Send me a tweet, tell me what's going on in your lives. But other than that, thank you very much, and I hope you enjoy the rest of the conference.