 Greetings and salutations. I want to start by recognizing how disappointed I am to not be doing this in person and sharing this time and space with you, but we're going to make the most of it and there's a lot to get through. We only have 20 minutes, so let's go. I'm going to start with a little bit of an introduction about myself. I'll shorten the long version of my shtick here, but essentially been focused on open source infrastructure automation going back over 10 years. In parallel I've been working in and around the DevOps community and writing books and talking about these kind of topics, and then I joined Red Hat about two years ago. This is just a picture of my peak pandemic beard. This has been shaved and you can see we're almost back to that. Just to put this out there, if anyone wants to get a hold of me, LinkedIn or Twitter, that's probably the fastest way, and I come in various configurations of hair and beard and if you see me anywhere else, I might look very different than I do right now. With that being said, I would claim no expertise in security. I've been involved in lots of things where security was a consideration, but it's never been my job, my responsibility, my name on the line for security. Take everything I say with that as a context. What I would consider myself is an aspiring pattern matcher and puzzle solver. Security has been a goal and a constraint, but it's never been exactly the thing that I was 100% focused on. With that, I'm not going to talk about all of the buzzwords of the day. The buzzwords, you know them. There's lots of other talks about them. Some of you are probably working on them. I would hope most people listening to this know more things or know more about these things than I do, but with that being said, I'm not not talking about those things either. What I'm really going to focus on is the dynamics of how organizations change their behavior. There's a couple things that I think are really not changed here in the sense that the basics are essentially, is there an identity that we can authenticate against? Then once we have those identities authenticated, is that identity authorized to do whatever they're trying to do? You have this kind of who, what, when thing that you both want to be able to enforce and then also record. This is not really changed. The fundamentals of some of this stuff, in my opinion, isn't fundamentally changing, but what is changing is the dynamics of the tools and the dynamics of the problems we need to solve with respect to scale and the surface areas. This is something that I think is very exciting about the way a lot of these tools are emerging as we're getting into this world where instead of the theatrics of inspection, we can move into some hope of a future where everything is verified by cryptographic identity and policies enforced based on that identity instead of the theatrics that seem to dominate what most people do for security today. This is this notion of continuous, we have continuous everything, that's a buzzword which I'm going to use liberally, not just in this talk, but in lots of other talks. We want to get to this world where everything is continuously verified. Then back to the topic of the day, or the topic for at least this 20 minutes, is there's this interesting question of how you can change from what you are to become this new thing. The legacy can become cloud native and when you think about that problem, there's the legacy applications which sit on the legacy infrastructures, but underpinning all that and creating that in many ways these things are a reflection of each other, you also have these legacy cultures. I'm going to introduce an idea here which isn't something I'm making up, but there's this notion of a socio-technical system. It's not technology alone that solves these problems that develops or delivers the applications, the infrastructure, or the security. It's that socio-technical system that does so. You have to address that. Too long to read, this talk is basically the changes hard, that's the title, that the point I've already started to make that security is qualitative, it's not a condition. You're not secure or insecure, but there's qualities that are more secure and less secure. Those are qualities of a socio-technical system. You have to treat that system as a single thing. If you think about it purely as a technical problem or purely as a cultural problem, you run into these things where it's very difficult to change or move past where you get stuck. This is the new ideas I'm going to hopefully introduce that you'll find interesting and insightful is this notion of collective interests and selfish interests and how those come together. Then there's something I like to say, and sometimes I say it with swear words, but broken things tend to get fixed, but things are merely bad, can often live forever. You want to change the world. We all want to change the world. This is an exciting time. We see all the advancements in technology. Sometimes we get to make some of those. I just want to remind you of some of the ideas from the past on this topic. This is Machiavelli who some of you might have heard of, and maybe one day I'll give a talk that's just quotes from philosophers and these sort of things, but I want to point out the sentence I've made bold here. The innovator has for enemies all those who have done well under the old conditions. I'll leave the rest of it, and this is a pretty famous thing, but just think about that next time you're having conversations in your organization about how to do the new things. Then related to that, this is from a slightly different time around the transition from classical mechanics to quantum mechanics. Max Planck did some foundational seminal work there, and this is called Planck's principle, which says that a new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die. The simple version of this is that science advances one funeral at a time. There's another dynamic which I want to point out, which used to frustrate me in a lot of the work I was trying to do, getting people to kind of adopt these new ways of working and do things in a better way, is that you have this thing that we're kind of a part of innovating. I think that's something we can say is happening around the cloud need of technology. There's innovators, there's early adopters, and when they're doing that work, when you're creating those new things and you're adopting those new things, you're actually focused on doing things better, getting an advantage, and then you see that advantage is demonstrated. You see this in sort of the state of Devos report, some of these other things with automation, and then you get into this early majority, late majority, and you start to see this phenomenon where people don't actually adopt the real practices, or in some cases even the real tools, but they start using all the words and they start changing all the titles, and this is studied as a phenomena, which we don't have time to get into all the research here, but what ends up happening as you kind of cross the chasm and come into the majority is that these organizations are not actually seeking advantage, they're seeking legitimacy, and the legitimacy is because there's other people who got the advantage, but they're not seeking that, they're just seeking the words and that's enough for them. They'll just take those titles and now they're SREs or whatever, even though they change nothing. So we're worried. This is a blog post from legacy Andrew in 2010 about what Devos meant to me at the time. Developers and operators can and should work together, system administration is evolving, like software development, and this is last but not least in some ways most important is that this is evolving together as a global community, sharing solutions, and I think that's the most exciting thing. I think that's also happening with cloud native and for all intents and purposes, I feel like these are a continuation of similar things, right? So this is my definition of DevOps I've used in many conference talks that it's optimizing the human experience and performance of operating software with software and with humans, which is important in a minute, and just a piece completely buzzword compliant, continuously DevOps, microserverless, we'll check a lot of boxes for the day. So related to this definition that I use for DevOps is this theme about softwares eating the world, right? That is essentially arguing that software is optimizing everything it can, optimizing human performance and experience, and DevOps is really just an extension of that, cloud native is another level extension of that, and what we're seeing and what I think a lot of this community is about is that software is actually eating software, right? So we're seeing this sort of software platformification that's allowing all of these things to happen and I'm going to go into platforms more deeply as we go, but the other thing that's happening and this is really the point of this subconference here is that software is eating software security. So we have this situation, people always say softwares eating the world, I don't think that's entirely true, I think there's a lot of other infrastructure and circumstances that support that, so we live in this time, I'm speaking to you through the internet, supercomputers everywhere connecting all human knowledge with high speed networks, but it's also connecting all that to the adversaries, and I said this as my part of my definition coming back to it, every aspect of human performance and experience that can be optimized will be including owning you. So with that in mind, DevSecOps just to kind of rub the same pattern on it, I'll say this now and I've said it before and I'll say it again, DevSecOps is another buzzword of the day and it's really adding that consideration of security as a first class part of the equation, so security is involved to include and is included in software development. So the software of security is looking more like software development, like with the lifecycle of software development and it needs to be included in the rest of the software development lifecycle, and then here's the exciting part that we're part of right now, like I said, I wish I was together with you and we could do this a little bit more personally, but reach out to me, this is a global community, sharing solutions, I'm sure a lot of you have seen things I haven't seen, I'd like to hear about them and if you want to know my P9A thing, I'm not shy, so reach out. So this is a very famous quote from 2006, I'm just throwing it in the middle of this because I think it's relevant to some of the themes and what we're struggling with in a lot of these organizations and I'm not going to read the whole thing today, but you can read it and you know slides will be available, but Werner Vogels 2006, you build and you run it, people say that all the time, they quote that all the time, okay that's cool, but who's actually going to secure it? Yeah, that might be a little bit of a problem and if you look at the big picture of what Werner's talking about and what was it at Amazon at that time in 2006, Werner doesn't mean that these developers are going to provision bare metal, get everything racked and stacked, install operating systems, install libraries, install and manage databases, that's not what he means at all, what he really means is really that team of software developers manages this this top layer. So I'm going to go back through, this is kind of like a reprisal of some classic DevOps conversations and this notion of traditional IT being a wall of confusion between developers and operators and then I'm also going to introduce some research from my colleague, Jave, in a minute. So these are two different games, so you can kind of think of DevOps is trying to win two slightly different games, let's define what those are. So this is Jave's working on his PhD, so he likes it when people reference his language and this is related to his PhD research. So you have this notion of what we'll start with and we'll call two economies, two different games to play on the left side, you have what we'll call the differentiation economy. This is about innovation, you win this game by creating more novelty by creating new variations, you win the scale game and this is not necessarily the words I would have chosen, but this is what's in the literature and this is about efficiency, so you're reducing variation and this isn't unique to IT, right? This is just the nature of anything, so if you're trying to manufacture whatever you still have this tension, this conflict between innovation and efficiency. So just to oversimplify, back to the DevOps divide, you have create more value, drive down costs and this plays out in lots of organizations as a tension between the business units who are trying to go faster, get more customers, do things differently and the central IT who's trying to control consumption and basically reduce the variation. So this traditional framing with the wall of confusion between us sort of sets these two forces against each other, but now we're adding another consideration, right? So if we're going to consider security, then we have in a lot of cases, in a lot of organizations added a new wall of confusion, right? So you have these traditional forces, developers don't necessarily understand security, security doesn't understand operations. There's in some organizations, if you get deep enough down this rabbit hole, you start to realize the security and the compliance people don't necessarily see eye to eye on some of this either. So this is over simplification, but for the sake of the argument, we're going to go with it. So these walls are there because we don't understand the other games that these other, these are people, we're all people, and we don't understand that they're connected together, that there's really like one organizational game, there's one collective that we that we're serving. So is there a way to win all of these games together? There's a new way. And I'm going to start with this academic framing, hopefully get more and more concrete and hopefully more and more relevant. So this new game, and this is this from James language is this scope economy. So it acts a bit like a clutch or kind of like a fulcrum that balances the differentiation in the scale economy to enable innovation and efficiency and security. And the scope economy in the in the best cases of this results from these ongoing negotiations, recognizing the selfish interests in favor of the collective interests. So getting more and more concrete, you have if you've optimized everything for innovation and you allow every single team to make all the choices they want, you end up with a lot of different and varied ways to do pipelines, to do the object model, to do the databases, to do whatever. And that that is great for the innovation, but you've created all this downstream operational burden for the organization and you've created this like very broad and widening attack surface from a security perspective. So it might be more valuable to look at those patterns that were innovative and look at the commonalities that might be reused across the organization and bring those into this central platform to be reused by everyone. And then conversely, you also see this in especially in heavily regulated organizations where the resources are overly restricted and as a consequence of that restriction, you're not really getting innovation. And so figuring out kind of based on the risk and the policies that you can enforce with the platform, it might be more valuable to pre-audit and secure some of these libraries, some of these services and breathe those into the shared platform to be access and to lead more value. So I'm going to argue, I'm going to assert every cloud native company builds these platforms, has built these platforms is building and extending these platforms because they have to. You can't get to the scale and keep the promises that you need to keep if you're doing everything with this artisanal, you know, hand automation and security approach. So this is from the SRE book. This is the Google way. I'm not going to read the whole thing, but I'm just going to read this bottom part. So the development teams can focus on the business logic because the framework already takes care of correct infrastructure use. This is Google explaining in some degree how they built their shared platform that's straight from the SRE book. Borg is a scope economy construct. Kubernetes is a scope economy construct. Yay. I also think it's interesting to think about. Kubernetes is an open source global commons to build a local shared platform commons. And then establishing an SLO is a calming exercise between SREs and software engineers. So what is the equivalent negotiation for security? What is security? What are the principles of security? I'm not sure either, right? I never said I know what security even is. It's never been my job. But I do know a thing about reliability. And this is one of my favorite characters in that narrative. Shout out to Joe Armstrong, Rest in Peace and Erling. And this is the sixth laws of reliability. And I'm not saying this is the laws of security, but it's not a bad place to start. Isolation, concurrency, failure detection, fall determination, live code upgrade, unstable storage. Go look into some of his work and some of his talks on these topics. And then this is maybe in silly on Twitter. Any sufficiently complicated microservice deployment contains an ad hoc informally specified bug ridden implementation of half of Erling. I'll stand behind that. And again, this is my advice to you. Good DevOps copy, great DevOps steal. Whatever you want to call yourselves. But going back to the stealing idea, this is the chapters from the SRE book that I recommend everyone read, no matter what your job is. Security, operations, development, whatever. Embracing risk, limiting toil. Most of those ideas would translate into any domain and be a collective concern. And then what would it mean to have a security level objective? And how would you measure that? And I'm not sure I have the answers, but I really like thinking about this and measuring this and being in a position to help organizations make progress. So this is the same exact quote. The only thing I really changed here was the word security. So just to kind of read the same thing again, development teams can focus on the business logic because the framework already takes care of security considerations. That's the holy grail to me. So this platform that we're building, whatever it is for your organization has to continuously and automatically audit and enforce policy because the old style of security and inspection and theatrics cannot keep up with this microservice world we're moving into. So how does that platform get implemented? Well, it's this notion of commenting and bringing all of these selfish interests that we all have into that platform, into that manifestation of our organizational needs, risks, need for innovation, need for efficiency and building the right thing. If you get too far in one direction, you get out of balance. It doesn't really work, right? So if developers are running everything, then you're creating a lot of operational burden. If operators are stopping everything or security stopping everything, you're not really innovating. So finding that balancing point by getting those selfish interests to negotiate with each other in favor of the collective interest. So this is the holy grail we want to get to. Developers can do everything to create novelty, to create innovation. You have this platform in the middle that keeps all these promises, provides self-service access with the enabling constraints, and underlying that you have this secureable and reliable compute networking and storage infrastructure. So that's simple. It's not always easy. Believe me, I know, and I'm sure some of you know, and you hear this all the time, you know, the culture is the hard thing, but it's, yeah, it's hard to think. So security is also never done. That's the other thing. This is an ongoing negotiation. Sometimes I hear people say this. I frequently hear people say this, which is like, good luck. Good luck with that. So just keep in mind resistance to change might be the only thing more inevitable than change. And there's this dynamic, you know, where we don't want to forget how we do things here. That's what we are. This is how we do things. And going back to this that I introduced you to earlier, my advice to you is to seek advantage. Always be seeking the advantage. So coming to the end, conclusion, this is not a technical problem. This security is not a people problem. Security is a social technical system. And you have to solve both of these together. I don't have time to learn new things because I'm too busy getting things done. That's a very famous quote by the least productive person in the world. And with that, thank you. I'm not here to answer questions. I'm here to have conversations.