Sergej Epp, Ashley Ward: Need for Speed: How DevOps is Changing Cybersecurity

You know, two weeks ago, me and my wife were driving for the first time in a full electric car. And I don't know how many of you did this already, but my wife is considering to buy a new car.

And, you know, she was interested in trying out the, the golf from Volkswagen, but also Tesla. So we've signed up for Tesla test drive and, you know, being a German and German highway, I had really to try out the acceleration speed of this Tesla model three, and, you know, really turning this off to the sports mode. It took literally three seconds for my wife to lose her interest in a Tesla right now, for me, it was a lot of fun, but I think, you know, we as humans, we experience acceleration and speed, pretty similar, you know, driving fast. You want to feel still yourself more secure.

So you wanna ask for better breaks. You wanna, you know, drive much more forward looking and be more vigilant, even not to fall into, into sleep. And in security, I think it was traditionally always very, very different. If something had to be developed very fast, typically security was not really part of the equation as we now, right. Especially if you have in place, you know, who's really having time to check for all the security aspects and, you know, to stay with their knowledge.

I think it's like really building a new car with doubled acceleration, double the speed, and then, you know, driving this on the highway and then recognizing, oh, potentially I need better breaks. Right? So the question is really how can security keep up with, and that's the question we would like to address today with Ashley? I think we're all now the is more about culture rather than about technology. So security is too about culture, right? And we need really to have a, a different mindset, a mindset shift and the best to achieve this is really to have some principles.

And this is what we would like to, to propose today, not just three principles, we're going to break the rules three and propose four principles from a security point of view and from a developer point of view. Now let me, first of all, be very clear, DevOps is in your tax surface. And why is that simply because most of the organizational there on 80% of them are using already containing our cloud. And so on and based on our research, which we've performed our unit 42, we have, we've identified nearly 200,000 infrastructures, a court templates, which have severe critical vulnerabilities.

And as we, now, this is about 42% of the total, you know, open, openly available infrastructures, a core templates now looking at containers, which are available on Titan internet, the different database, which are not encrypted. You know, it's really shocking to see that this model new environment is posing so many security threats on us.

Now, looking back at my, you know, before I was working Palo Alto networks, I was heading up cyber defense investigation, forensic teams at a financial service institution and literally 90 to 95% of my time. And the time of my group, we focused on governance of production systems, governance of, of the existing infrastructure and production data. And I think in DevOps, we have to sing differently.

We have, there's only one chance really to keep up with the speed to be proactive. So we have really to turn this around and, and stop doing production security and focusing more on design and building phase. And as you know, we're calling this potentially of heard, already shift left principle in cybersecurity, right? Really shifting security to ZLA and, and spending more time in this, in this area.

Now, a lot of companies are talking about this, but most of the companies are not still doing that properly. So I would really advocate for everybody to sit down once a week and spend time with your team and try to understand how much of your efforts of your focus have you really invested into design and build phase this week and should be really like for mature container cloud organization around 80%, but even doing that, there could be still some vulnerability left, right?

I would like just to give you another example here, a story where we were asked by one of the largest SAS companies in the road to do a red team on the infrastructure. Now, typically we are not doing any, you know, red team exercises for customers, but because they were asking nicely and pushing us to do that, we did this and we literally found just one identity misconfiguration this environment. And we're able to bypass almost all the security controls and take over completely this large scale environment.

Now, as said, if I would tell you this SA name of this company, then the name of this company, you will all recognize which company it is. I think it teaches us clearly one thing. So systematic risks are very dangerous in the cloud, right? And we also all know how to mitigate that from security point of view, it's nothing new, right? It's called zero trust.

Of course, everybody's talking about that. And it's really centered about around the belief that organization should not really automatically trust anything inside or outside of the perimeter, because really the sort of cast model is not working anymore. The data center is not the center of the universe anymore. So today the data, the assets are decentralized and any trust in a user, in a device or in a network is really a vulnerability because it could be an inside user or it could be, you know, a compromised machine. So if in the past you would use your laptop in the office.

And once you authenticated your laptop, you could, you know, access all of your assets or your application today. You wanna have identity based policy for the user. So if the user is working from home, he can just only access application. He's allowed to access same for the office, of course, and all this principle segmentation list, privilege list access, they're all known to us and available to us. But people claim that zero trust is not realistic. It doesn't really scale because of, you know, technical adapt, right?

You have free to redesign your entire environment or legacy systems who are not supporting authentication. But on the other hand, why we're complaining, I mean, there's this new environment around DevOps and multi-cloud, so we have the chance now to rebuild this from scratch, using zero trust, right? So implementing all this list, list, access scenario, starting to do policy based on IP, but based on application. And there's no real as we've with exercise, we have to reduce the systematic, systematic risks as much as possible.

Now the next principle is really about the, the costs and the money, right? Security costs money. So we cannot infinitely invest in security. We have to consider the impact on profitability. The most successful companies we see out there have one thing in common, how they're addresses. And most of them are tech companies, by the way they standardize, right? And they do this by reducing the cost of control in order to increase the cost of baseline. And also also coverage of baseline, right?

Because if you have one next generation five, or if you have one endpoint product, if you have an identity system, which is only you centralized, and you can of course reduce your operational efforts, but also you your time to market. So some might say as well, you know, it's easier to say than to do, but I still hear a lot of, a lot of, you know, excuses like, oh, there's a lock in effect, or we have not, no real principles to implement, you know, platform. And therefore companies are still ending up in this product zoom environment, right.

And the, the other way would be really to try to understand how can you reduce your vendor fragmentation? How can you standardize ask simply your vendors to come up with a, with an architecture proposal and then standardize also on common platform. If you're using platforms, try to understand how can you increase the penetration rate of this platform? How can you really measure yourself based on the, you know, feature adoption, velocity and things like that in order to be successful and increase the baseline.

Now, still as a security teams, we might be very often behind the DevOps teams, right? Simply because traditionally secured experts half manage the environment by EY by tool, not really by piece of code. So security experts are also not, not often called as they're coming from the system administrator world. And that's why it's not surprising to see that security operation is failing because just looking at, you know, Amazon AWS environment, there are more than 500 new services being introduced every year by this environment.

So how do you really keep up with this by using a good, it's almost impossible. And looking at the stats here, it's clearly that, you know, more than half of the teams are saying that they even not prepared from security operation point of view to deal with this incidents in the cloud. Now that's why there's a clear recommendation, which is a force principles. You have really, to adopt automation, if you cannot automate because you, your, your, your platforms lacking certain features of capabilities, you have to invest into an engineering team to lose automation.

The beauty about our industry is there also great solutions to automate, even if you don't have engineering knowledge. So you can invest in security, orchestration, automation tools, and really, you know, ban all the manual playbooks and goods and embrace end to end automation.

Now, I think we've learned this, this four principles of pharmacy, so point of view, right. But we also understand that it's, it's just one side, one half of this story, because it's a team sport, right. So let's hear really how DevOps would approach this from a seasoned practitioner, actually, who is our cloud CTO actually over to you? Thank you.

Say again, seasoned practitioner. I think I'll put that on my CV here makes me sound very professional. Yes.

And, and I think for everybody here, we all know that I now have about an hour and a half to talk to you. So lots of slides and lots of time. I'm joking. Of course. Yeah. Everything that Serge has gone through has, has really points the, from a security point of view and that there are real consequences to those things. This is where we do need something that's integrated and comprehensive. Now the I'm not gonna go through all of these ones here.

Really the one I want to focus on is that third one change is the only constant, regardless of whether we think that we will pick one cloud and stick with that and never use multi-cloud, there will be mergers and acquisitions. There will be changes in business requirements. And so we need to plan for future, which is what we are all about in the DevOps space. So first of all, looking at the cost effects and why we do all these DevOps things in the first place, well, this is information from, from missed, they've published this.

And what it's really showing is that if you try to fix something in production, it costs 30 times as much as if you fixed it in the requirements section or in architecture, or even in coding, it would be six times as much. And the same is true, not just for bugs or features that we have, but actually for security issues that that may come in. And so what we want to do is we want to bring security into the DevOps life cycle. So we're not just saying shift left, which is kind of pushing, pushing things into development. But from a DevOps point of view, I want to pull security into that world.

I want them to be part of what I'm doing, and that's the first principle. We want to have security as a first class member of our DevOps pipeline. So if I look at then what we can do from a second principle, well, let's have policy is code in this new world of working. We're doing everything as code as a DevOps team. It's the only way that I can manage those huge complex infrastructures that we have out there. So I'm using infrastructure as code. I'm using new technologies that can be there. And I'm using that in order to spin up those environments.

If there's something wrong with my environment, I will blow away and I'll spin up another one. And so how can we then use policy as code? And this is this idea of, of leveraging securities expertise to enable me to have information in a development environment. So let's not open up S3 buckets to the world. And let me have something in test. That's telling me this wouldn't be allowed to go into production.

Perhaps I've got containers running with certain privileges or something else that might be overly privileged, and then in a production environment or subsections of that, let's further split that down and say, actually, you're not going to be allowed to do that. And that way I can still develop fast, but I'm still constrained and make sure I don't do anything untoward. And when we look at this slide, which you'll recognize because I, I stole it from Serge.

When you look at this slide, we can see here that all that stuff on the left, which is, you know, the world that, that, that security lives in and that S is involved in. That's all quite alien to me, as someone operating in DevOps, I'm much more in that circle area. I am looking at things and saying, well, I appreciate that there, there should be SSL inspection. That was never my problem. That was somebody else's problem. But when I'm in control of that infrastructure and operating in that DevOps way, then suddenly it does become my problem.

If I'm using operating systems that are, are cloud operating systems, then have they been hardened to the enterprises standards or probably not. But previously that was the Unix teams problem or the windows team's problem. So it's not something I've needed to worry about. So just as we want to use that policy as code across all the different environments are there.

So two, do we have a se pointed out all the different cloud providers that would be there and not just the cloud providers, but their services. So AWS, those 500 services a year, surrogate paints that picture of how do we keep up with that? And of course from my point of view, I go, yes, 500 services that I can make use of that are there to make my life easier. That are there to allow me to deliver things faster. So how can we also bring security into that?

Because ultimately as much as perhaps in the old days, it was them and us, depending on, and you can be in either camp, it could be as a, as a person, it was them or security, or they were security and the other way around. And if you're insecurity those guys, but of course, this is where we have no longer got that them and us, we need to all work together. We've seen the, the cost of breaches that have happened and not just from a, oh this, this looks bad to the brand, but real actual monetary fines that have come out.

And so we need to be able to have that principle of preparing for multi-cloud. As I mentioned, even if you hire cooperating with a private cloud, you will be looking to go into public cloud. Even if you're in a single public cloud, your organization may buy another company that uses a different one. So from the off, we need to look and say, we want to write once and consume everywhere. We want to design as a principle, we want to design for change with security, bringing security in. They're going to operate in that DevOps fashion.

We need them to be there and across these different clouds and across these different services. And then when we're looking at platforms and we're looking at those security tools that we're using, those two little boxes and the side there become quite important. As surrogate pointed out, a lot of the time, people are more comfortable with graphical user interfaces. And as long as that's a way to then automate things, then that's okay. So we need something that's available as an API for me as a EY for somebody else.

And it allows security for everyone across those clouds and across those services, because otherwise we're going to end up with this situation here. Now you will forgive me. I hope the tweet that I've put in the, the right hand side there, I really struggle to fit it in, but I, I do love this, this tweet. So this is Kelsey heter, and Kelsey's an incredible, incredibly smart chap who, who talks a lot about Kubernetes, which is kind of where my passion lies. Don't worry, we're not going into the weeds with this. Instead. We just want to look at that right hand side. Now he's pointing out.

If you're trying to run your own Kubernetes platform, here are some of the things you are going to have to consider. And just like we're talking about those multi-cloud services. When we see the 58% of people will respondents to our state of cloud native security report, they use six or more cloud security vendors. So we look at that tweet on the right, which is about application tooling. And of course the big part is at the end, bring lots of glue.

And just in the same way, if you're looking at all these different parts across all these different clouds, across all those different services, you're going to have to bring an awful lot of glue, which of course then takes us on to that fourth principle. I have rattled through all of these principles that you, you have the chance to go through these slides at your ledger, but the, the, the fourth principle is perhaps the most important one. From my point of view, we do want to adapt to be dev secs.

Now, I, I know from speaking to many people that DevOps and Patrick Dubar coined that DevOps and his view is that DevOps is something that embraces the organization. It's not just development and operations joined together.

Instead, it's a way of working for everybody, but I think it is important to say dev SecOps. And that's because what we need is security to be a first class citizen from providing access to security platform tool set. And that we're talking about trying to avoid all that glue through to providing that policy that we can consume as code. And that doesn't mean that we need to get all of our security people writing code.

We just need to have way of translating what their requirements are and what all the expertise they have knowing the regulatory requirements that we face changes in them, changes in the company, changes in what's going on because of course, security is the interface with the business, from that, that security requirements point of view, and making that available to the DevOps team. So I really do think that dev SecOps is the most important part. So we don't need to worry about the plumbing.

There are a number of different that state of cloud native security and report, which you have mentioned. And you'll see that there's a link there for that. It goes into, into much more detail about this and it's well, well worth the we. So what do we have? We have that adapt dev SecOps security in the software development life cycle from the moment code is first written. Security can be consumed there. I can have security warnings in my IDE, as I'm developing security teams can act like developers and enable speed and delivery.

If we're all trying to deliver things faster than we want security to be involved as early as possible, otherwise breaks my DevOps pipeline as well. It's, it's still me shipping code for it only to be broken at the very goal line. And of course, by security being involved like this, it means that my DevOps cycles are no longer spent maintaining point solution security tools. I don't need to go, oh, I meet this requirement by doing this one thing here. And I can report that by doing something else over there.

Instead with us all working together, we can have that security platform and I'll top the same language across all those different things. Containers, serverless, Kubernetes, user entity, behavioral analytics, all of that good stuff. We can now talk together and work towards. And that's where coming in with that idea of security is a service. If you like, it's the security is a service really it's enabling multi-cloud service, isn't it it's security being able to cope with any changes that might be coming along. So I'm conscious of time.

And thankfully, you'll be pleased to know I am coming to the end now, and here is your homework of what you need to do. So from a CSO point of view, have a look at those principles that Serge talked about, understanding shift, left, understanding zero trust and how it can now be implemented. And remember that goes hand in hand with the DevOps way of working. We can retrofit things because we're continuously delivering. You want to reduce the cost of control, have a look at this. You're now an enabler and a benefit to the business that you always were, but in a very visible way.

And that involves dev SecOps and on the dev op side of things, I've already gone through all of these, but you can see how they, how they pair with each of the things, because ultimately we are all trying to achieve the same thing. We're all trying to make the business better. Thank you very much for me and on behalf of Serge as well. Thank you very much. And I do hope you enjoy all of this wonderful conference.