 All right, good afternoon. The energy is a bit low. Let's get warmed up. A few questions to get us started. Who's having fun? Awesome. Anybody learned anything new today? Very cool. How many developers in the room right now? How many of you actually write code on a daily basis? And some are probably writing that right now? Hopefully not. We're going to shift gears a little bit here now. I have no code to show. Quickly to introduce myself and the session and the company I'm representing here. I work for Pivotal. How many of you have heard about Pivotal? Awesome, that's great. Jerome works for Pivotal. He's our field chief security officer. So in case you have questions later, or you want to know more about stuff that we're going to talk about, Jerome's in the room. Pivotal Labs was formed over 25 years ago. Formed in the Silicon Valley in the Bay Area the early days of the agile movement. So they've been in this agile space for a very, very long time, starting with startups back in the day when Google was a startup, when Twitter was a startup, eBay was a startup, and now helping the largest Fortune 100, 500 companies. And their mission is how to help these large enterprises get awesome at software. My role at Pivotal, I lead the technology services divisions across APJ, and I'm really, really privileged because it gives me access to see all the change happening in the largest enterprises that are trying to respond to the threat of startups. And they're all trying to be great at building software and releasing software faster and doing this in a way that is so opposite of what enterprises are used to, that it's fascinating to watch all the change happen. And most of the change we see is the challenging portion is not the technology, it's everything else. So what we're gonna do here today is share lessons from the field, share what we've learned, how the balance between developing and releasing faster versus managing security is being done by these large enterprises at scale. How many of you here would identify yourself as working in an enterprise environment? Large, 100 plus in your teams? Okay, so very few. So a lot of you are very familiar with startups, is that fair? You're mostly in the startup world? Okay, that's cool. So some of these problems may seem familiar and some of these may be not so familiar. This is what we've seen in large companies. The principles, however, apply whether you're a small team or a large team, right? The concepts of solving for security applies no matter the size of the organization. The lessons here, however, are from the largest enterprises whether they've applied it at a team level or a product level or a complete enterprise level. So what we've learned is obviously what worked yesterday never works today and never works tomorrow, right? This is what all of us deal with at multiple levels. What got us here doesn't get us forward, be it in tools and technology, be it in process and culture. And I think all of us are familiar. We work in this space where we recognize that technology has enabled such powerful transformations in how customers and how companies go to market, right? The power that fast software development and release and working on really, really quick cadences has allowed a lot of non-traditional competitors against the enterprises and enterprises are learning how to respond, right? So it's a constant ongoing evolution of how do I catch up and how do I stay ahead and how do I discover new sources of revenue and how do I fight competition, et cetera, et cetera. All of us are very familiar with this. But as companies are getting faster, right, and as they are getting new tools and they are getting awesome at releasing software every day, so are the bad guys. It's not just the good guys getting better with software, it is the bad guys as well. And when being good in your business has started to mean being good in software, it does not come at the expense of security. Now, all of us have seen a lot of recent examples where not dealing with security really well cost companies millions and billions of dollars, costs the executives on these companies their jobs, and in worst cases, some of those guys have landed in jail, right? We've seen those examples. And what we have learned is it's not that the successful companies are the ones who will go extreme fast releases on point number one or extremely slow, deep amount of security built in, deep amount of technology, and deep gating processes that would be successful, it's really companies that have managed to have that balance. And it's not one or the other. One of those approaches going really heavy on being awesome at software, not caring about security, or being awesome at security, not caring about customer experience, either of those shifts are extreme, either of those positions are extreme, and they don't really help enable the business to take a solid business leadership position. It's the ability to balance these two extreme positions. Now, anybody in IT would be very familiar with what's up here, right? Not so long ago, not even a decade ago, you see the first headline up there. IT was the enemy in large organizations. These were the guys slowing everything down. There's a market to be captured, there's revenue to be made, there are business opportunities, there are competitive threats, but here's this big financial burden called IT that takes a lot of dollars from budgets and yet fails to deliver value quickly, right? And you fast forward, the industry responded. There was the DevOps movement, the Agile movement, we've sort of trained IT to respond really, really quickly. Software gets released way faster than it was released back when this article was originally published, but then the problems moved on to now, security. And that's the one now viewed as the enemy, that's the one slowing down your ability to release software faster at a cadence you want in a manner you want, right? So the problems have shifted, got an awesome at releasing software, now we need to bring that same level of awesomeness around bringing teams together, integrating tool sets and toolkits, now to the security world. So who has got this right? I mentioned at the start, we've got a lot of very, very large enterprises we work with and the rest of this talk is gonna be based on the customers and the enterprises and the organizations that we've seen do a really good job at managing fast software release cadences and great security controls. And as much as as difficult this sound, we've seen a huge amount of organizations get this right and I'll show you some cases and then our synthesis of what they have done well. And so this is rooted in reality. This is what we've seen across the largest customers across the globe. So now when done right, the customers, the enterprises that we have seen do this really, really well, they achieve huge amount of benefits. There are some numbers up on the screen, hopefully they're visible at the back. Huge amount in efficiency for how software gets released to your end customer. Huge amount of increase in where developers are spending their time versus traditional environments where processes are still very manual, security is an afterthought. So it slows down the release cadences. All the gates that security wants in a release process are all at the end of the release process. Hence the train runs and then slows down waiting to clear all the security checks and then get into production. And we've seen really, and the point of these three metrics here are they are appealing to all three different audiences. That starting with security in mind does not need to cost you your release cadence. It does not need to cost you your developers having to slow down. In fact, they can get faster. It does not mean you having to do a lot more manual tasks. In fact, you can get really faster with your platforms as well. The first example up here is the largest retailer worldwide. And so we're not talking about a small retailer, we're talking about a mom and pop shop. And the point there is about proven this approach at scale. So this very large retailer still is able to ship 2100 times a month. Which is really great for an organization that size. Global organization present in thousands and thousands of locations. IT is distributed across multiple data centers. So yet they have their fast release cadence being achieved. At the same time, they are able to deliver all the security requirements while shipping at that speed. Second example, one of the largest FSI institutions worldwide. And they are able to repave all of their entire environments on a weekly basis. As a preventative security measure while they are running 25 foundations globally. Running mission critical workloads. So again, security does not have to cost you your application experience or release cadence or your productivity. And the last one is one of the largest telcos in the world is able to increase their frequency of patching. And if you go back, everyone familiar with security knows one of the most common issues why security breaches or tags or vulnerabilities happen is just delay in patching. It's simple, right? Most of the issues can be traced back to there's a patch available. It takes us time to apply the patch that gives the attackers a window. And in that window is where most of the bad things happen. So the faster you can patch whether it be your application or your middleware or your operating system, you'd have taken most of the surface area out for an attacker, right? So this example of a telco needing only six operators to support a thousand developers. That's huge scale while still being able to apply patches automatically at a very, very fast pace. So what has enabled all these awesome results, right? These are proven at huge scale. So what really has worked for these enterprises that we can learn from? So four quick things. First, you know, security cannot be retrofitted. It cannot be an afterthought. If you're starting with security in mind right from the word get go, you're thinking about where we need security in the entire development to part to production cycle versus trying to retrofit things like identity and access management and log monitoring much later in the cycle that costs us a lot of time and effort and slow down, right? So we always start with security in mind. We cannot retrofit and there's never one size fits all. So you really have to consider what works for you and your organization. The second thing is to have developers start with secure environments to begin with. If you have reduced the security threshold for developers to create and write software in development environments that are not very secure with all the security controls built in, it's gonna cost you pain and headache when you move to production, right? So we solved the problem of development and production environments looking the same with DevOps, but now we need to put in security into the same continuum. Is your developer environments are built with security in mind? You've got all lockdown restrictions. You've got identity access management built in. You've got log monitoring access, et cetera, all built into your developer environments. Moving to production is really, really smooth. Then you need to consider automating everything. Now, all your tool sets can be built into your pipeline and you can automate everything in your delivery pipeline, such as the richness of the tool set available today, but you have to be very, very judicious about what you really need in your pipeline. So you really put in testing into your delivery pipelines. If you're sure you're not gonna produce false positives and slow the entire cycle down. And choosing that to be built into your pipeline is something that you have to consciously keep thinking and looking at. And lastly, you also have to think about this mindset of security, and we'll talk about that in a minute, is what does that really mean for you and thinking about what outcomes and why trying to get better at when I'm saying I want to be secure. Security shows up on very different metrics. It shows up in very different areas of operation and application and so on. We're not gonna talk a lot about application security here today, but I believe there's a talk on Saturday by Imran called AppSec DevOps in Practical. So I would encourage you to go to that talk if you're interested in application security. And the one other point here is while you build all of these tool sets and chains and get developer environments with security built in, it's necessary to test and build your responsiveness to when your failures happen. The difference between an attack and a breach is your ability to respond. So the more prepared you are on how should I respond once a breach happens, you can reduce that just to an attack, right? And that's a very important part of your security mentality is assuming it will fail and when it fails, how ready are you and how responsive can you be? Automation, now, obviously we're living in great times where tools give us an awesome amount of automation possibility. We can automation almost everything that's mentioned here. These are all the different things you take into account from a security perspective that you want automation on. You obviously don't want it to be manual. It's a lot more error prone. It's going to be very, very costly. People will stop following and it's gonna be creating a lot of cultural issues if you have people and not automation driving all of these behaviors into your organization. The thing that we've seen, the companies that I mentioned that are doing this really well, the question is do we do this ourselves or we find platforms that do this really well for us? Do we have pre-integrated solutions? A tendency that we see many companies tend to have is the tool-oriented mindset which is I can do all this myself. You could do this all yourself but the thought process of having security, A, when you build it, but more importantly when you start to manage this and if you build something like this on your own, you have to think about security for each one of these components. Each one of these components have a life cycle. Each one of these components have vulnerabilities and updates and patches and so on, right? So the best in class, the best in breed organizations look at pre-integrated fabricated solutions that have all of these awesome automation already pre-built in. So all you then have to worry about what's unique to your environment and your compliance requirements and you can move on to a lot more value added security features and things you wanna work on which is around your day two operations. How will you keep this going and how will you improve the detection and responsiveness versus working on the security tools? Are not the answer, right? Making sure that you've got the behavior, you've got the collaboration and you've got the responsiveness is where most organizations have the maximum benefit and not having the most awesome tools. And like we said, making sure that you've got the right security thought process at each stage of the software life cycle. There are different things that need to happen and moving from everything that you see on this slide typically coming into play in test and deployment, start to spread those out. And thinking about the appropriate tool at each stage of these different cycles of designing what needs to happen from a security perspective at the design stage, right? And you see recommendations up there, what needs to happen at the development stage and so on and so forth. So security is not punched up at the end and that slows down the whole process. So distributing these tasks out at the most relevant stage of building these awesome softwares that you guys do reduces friction at the end. And ultimately what you wanna do and our prescription is measuring the value that you create. Really the value for the developer is the most amount of time spent in writing code versus testing and regression and fixing, right? So if you're ever curious about, am I being super productive? Just look at that quick formula. How much time is spent on writing code versus the rest of the activities? And following this prescription, you will keep increasing the amount of time you spend on the code versus doing all the testing and fixing that a lot of us are getting used to. And so the last point here is we are a very metrics driven organization. So we showed you some metrics of what large organizations have achieved at scale. Our prescription learning from all of these great companies is to start with security in an outcome driven manner as well, right? What are the metrics around security that you would like to get better at? And that's going to inform everything else that we saw in the previous slides around, hey, do I need more automation? Do I need more upfront testing? Am I trying to improve compliance? How do I measure improvement in compliance? Do I know I'm really getting better or do I need to slow down my development because I'm compromising security as measured by a certain metric that we've all agreed upon? In the absence of metrics, it all becomes very subjective. And culturally, that provides a challenge because you don't have a point of alignment around what does being good at security mean or does not, right? And then as with everything, it's very important to create the right culture so that the focus on security is not just by the security team. Just like DevOps was not developers or operations, it's the entire development and operations team, it's the same thing with security and it's everybody's business. Because guess what? If your application is considered not secure, who's going to spend time fixing it, writing it, testing it, re-releasing it? It's probably going to be you, right? So having this common collaborative joint mindset around, hey, security matters for everyone and here is what it means when we say security matters. Here are the metrics we want to get better at. We are at 50% of patching within a seven-day window we want to get to 90%. That's an awesome metric everybody can align and agree upon, right? So it's not more subjective and then we all drive to common metrics and common goals. So with that, I think we have a couple of minutes left for any questions for Jerome or myself. Did anyone learn any one new thing today? There's a question? You did, that was you saying? Okay, this one here. I have one. Usually, I do much of my learning by looking at how well set up open source projects do their things. Now, do you see any open source projects that sort of embodies the best of devs? This is dev psych ops, right? Practices. Well, we obviously would be biased. So pivotal cells platform for a living, right? So I would encourage you to look at Cloud Foundry. I would also still say, and again, this is based on what we've seen, right? And we're talking from experience of these massive, large, complex organizations doing this at scale. It is rarely your focus on the best in class tools that will get you the security outcomes. So we know of many organizations that have chosen individual best in class tool for a certain security purpose, and yet it gets them nowhere. Because then you've shifted your pain in the integration of all of these components and the management of these components, and you have not aligned on what am I trying to improve by these components and could a lesser set of components to it. The other thing that we have learned is the acceptability versus resistance culturally of tool sets in a large organization. You really want developers on one side and security on the side to sort of harmonize and say this tool is achieving a specific purpose and it's not slowing anybody else in the organization now. So yes, we could follow up and give you a list of tools. Certainly encourage you to look at Cloud Foundry, but also encourage you to look beyond the tool set. Our experience says it's rarely about the tools. Lesser tools manage to well the most amount of automation you do with it and you raise the value line above the tool set. So the tool set is inconsequential. That's where you start to see results. Thank you for the question. All right, thank you. Sashen.