Transcript
and today I'll show how to make the case for a DevSecOps transformation. When I work with legacy IT staff, there's heavy resistance to adopting IAC, policy as code, pipelines, pull requests. When I engage people and explain the benefits, the reaction from people was mild. Your little demo is cool and that's nice in an ideal world, that works for you and your background. But we can't learn all those new skills. We're not developers. We're not a big tech company. We just want ClickOps so we can just get things done fast. I didn't want tools or skills to take all the oxygen in the room. The audience would fixate on the effort of learning and changing, and they'd miss the bigger picture. I just wanted to showcase the culture, the principles, and the mindset first. If they never learn the culture, they'll never touch the tools or apply the skills. So I developed two stories that illustrate the fundamental difference between on-prem and cloud, and why transformation is required to succeed in the cloud. I can tell these stories to anyone and they can instantly relate to it. Then we have a common understanding to build on when I'm evangelizing tools and practices to them. I'm gonna move quickly because if you're here, these concepts aren't new to you, but I'll explain the concepts in a way you've never heard them explained before. And then you'll be able to explain them to other people and hopefully change some minds. My first story empowers security professionals to explain why the cloud contains so many threats and showing developers why they can't have ClickOps in production. So let's begin. Your on-prem data center is like your home. You live in it, you built it, you maintain it. You have full control over everything inside it. That full control provides peace of mind and safety, but that full control is limited to a fixed physical space. If I only do business close to my data center, there's no problem. But if I do business around the world in different areas, but if I do business around the world in different countries, my data center has limited reach. So what if we started traveling abroad? Suddenly we have less control over our surroundings. We're more exposed. Safety is dynamic and relative depending on what we're currently doing. We need to have situational awareness. I wouldn't feel safe walking unarmed down a dark alley at 2 a.m. in the morning, but I'd have no problem doing it during the daytime, carrying a taser. Situational risk limits your flexibility. But you're not just gonna walk around the street carrying your luggage all day. You need a shelter to stay safe. You're going to check into a hotel. A hotel provides best-in-class shelter services without building and maintaining them yourself. Not only that, but the Hilton Hotel is a global network of hotels. Today, I can walk into the Houston Hilton, give them my credit card, and they'll provide me a room to use. Tomorrow, I check out of the room, pay my invoice. I fly to Paris, walk into the Paris Hilton, show them my Hilton membership, and I start using their services there. So we get into our hotel room, and we have similar amenities we enjoyed at home. We have gated parking for our car, locks for our doors and windows, a safe to store all our valuables. So are we safe now? Well, that depends. Safety when traveling is still very different from living at home. The hotel secures their facility, but they're not a daycare. You're not in their custody. They're not your bodyguard. They don't provide personal protection. The hotel warns guests about this. Lock your car, hide your valuables, keep your properties with you. Don't be a victim. If you get burglarized, you're not safe. You're not safe. You're not safe. You're not safe. You're not safe. You're not safe. You're not safe. If you get burglarized, the hotel simply says, yes, we see this all the time. You need to be more careful. The hotel is a difficult target for criminals. The staff are highly trained to detect and prevent crime. They have very mature tools and controls to protect the hotel. Any successful attack is going to be expensive, risky for the attacker, and just difficult to pull off. But successes do still happen. AWS, Azure, and GCP have all been breached countless times. Just watch the news. The ideal crime targets are the hotel guests. They're less familiar with the area. They have a simpler approach to security. They're prone to mistakes. They're often distracted. They're always in a rush to meet a deadline. Look at this picture. Someone propped the hotel door open using a latch. When I was a kid and my family stayed in a hotel, my mom would be in the shower and my dad would be asleep. I need to run down to the ice machine to fill a bucket of ice. I don't have a key, so I propped the door open and I do my thing. I'm sure it'll be fine. But I've introduced risk and created an opportunity for something bad to happen. The hotel is a publicly visible location. Everybody knows what it is and where it is. Everybody knows the public IP addresses used by the cloud providers. All these potential targets are huddled together here. So if I'm a career criminal, I know exactly where to go to find my victims. Look at this picture. If I was at home, I'd be fine with leaving my backpack on the breakfast table while I get some coffee. But in the hotel, I would never leave my backpack vulnerable where strangers can get it. I would take the backpack with me. In the cloud, if I create public storage with anonymous access, then hackers will immediately begin reading it as soon as it's created. 99% of security breaches in the cloud are the customer's fault. This means that even if you could prove that the cloud providers are impenetrable, their staff never make mistakes. The services have no vulnerabilities. The hackers do not have any way to defeat any of the cloud's security controls. This would only eliminate one in 100 security breaches because the other 99 are customers figuratively leaving their backpack on the table or being tricked into inviting a criminal into their room. That's how it happens. When people first think of the cloud, they naively imagine four very secure walls that cover every vulnerability you can think of. I'm just gonna put my app in the cloud and open all the services to the internet front-end, back-end, database, whatever, and the cloud has lots of technology to make this safe. Why would the cloud provider allow me to do it unless it was safe, right? Unfortunately, this is not really true. Instead, the cloud provides three very secure walls. Those three walls are extremely difficult for a criminal to breach, but there's a fourth wall which you need to build and maintain. So if you put in a velvet rope or a fence with lots of holes in it, then a criminal can just walk in and take your valuables. If hackers could breach the cloud provider's walls, then they could breach any application in the cloud anywhere, but they're not focused on those. They're checking your wall to see whether it has any of the well-known common vulnerabilities open. Let's imagine that in your hotel room, there is a closet door, and when you open the closet door, there's a magic portal into your bedroom, like Monsters, Inc., a private connection. This means that if someone breaches your hotel room, then they have access to your home as well, where you sleep. Now all the rooms and people in your home are under threat, so the stakes for securing the hotel room are very high. Now, let's suppose you're going to be living abroad. You're going to be migrating your assets from your home to the hotel and live abroad in hotels full-time. You're going to have a minimal footprint at home. Again, now the security of your hotel room is very critical. Let's look at the traditional security model we have at home on-prem. Again, we have a fixed security model. We have a fixed physical space where we own and control everything inside. There's generally a simple perimeter where once you're inside the network, once you're on the domain, you have easy access to lots of different unlocked rooms. There's lots of lateral movement. You're not repeatedly challenged by locks on every door every time you try to enter a room. You're implicitly trusted. The problem is that everything outside the perimeter is unsafe, and in order to secure something, we bring it inside the perimeter where it is safe. Now, let's look at the hotel. Everything is spread out. We don't have a dedicated space where we control everything. It's not possible to draw a single, simple perimeter line and say, we trust everything inside this perimeter. We're safe inside this perimeter. Instead, we need to put locks on every individual room, and people need to be vetted explicitly whenever they access a room because implicit trust is no longer feasible. Instead of one big flat network, we need to isolate areas according to their function. Kids in the game room don't need access to the office, so we don't allow it. Least privilege access. We restrict public access. Obviously, a parking garage is only functional if I can drive my car into it from the street, but there's no good reason for the bedroom to have a door directly open to the outside. That's a potential risk. People should come in through the parking garage past the standard security checkpoints, and there's a path from there to the bedroom in the back. But there is an increased overhead from putting deadbolts on every single door in the building, and everyone has to be challenged to present a lock key every time they want to enter a room, or they have to ask someone to let them into every room. And the solution to that is to make the locks smarter, more sophisticated, and more automated. Ideally, I should be able to walk up to a door, scan my fingerprint, and the smart lock lets me in if I have access. That's self-service automation. We have to model what is a normal and safe day in our operations, then restrict everything else. You need to classify your data, set policies around confidential business data so you can apply special controls, preventing it from being leaked. The point is the cloud is not going to somehow magically go in, discover all of our data, and make a security strategy fit for our operations and classify all of our data for us. It's not a daycare. They'll provide tools for us to do it. They'll strongly advise us to do it, but we need to put all of these controls in place and follow the proper processes to enforce it. Humans are the biggest risk factor in security. They're vulnerable to phishing, malware, social engineering. They make mistakes. But they're constantly in a rush to meet deadline after deadline. It's better to grant access to robots instead. A robot only lives for one purpose, like deploying a specific app. That robot stays in one room its entire life. It doesn't travel to high-risk countries. It doesn't get emails or text messages. It doesn't browse guilty websites. It can't be phished. It only follows orders given by code. That code is reviewed by approvers. Security tools scan the code and apply thousands of industry best practices, as well as your own custom security policies. Let's provide app developers security-approved building blocks with built-in guardrails and policy as code. Then users can model their app by connecting and stacking the building blocks together. Once their app is ready, they can submit this model to a DevSecOps platform, which will scan the model, enforce policies, and then deploy the app. Because we're using reusable, blessed patterns, changes become standard and fast-tracked. Security is like a suit of armor. It provides layers of protection, which mitigate hazards and risk. When we lower risk, we increase flexibility. Let's imagine working in a chemical plant. Safety compliance requires wearing a hazard sensor while I'm working because chemical gas is a deadly risk. But for some reason, there's no sensor equipment available right now for me. The safety manager tells me, look, I don't want to stop you from working, so I'll give you this respirator mask to wear until I have a better solution available for you. You're not going to like wearing the respirator mask. It's going to be uncomfortable, and it's going to slow you down. But I need you to live with this until we have a better solution in place. Well, I tell the safety manager, I don't want to do that. I don't need a respirator. I'm just going to hold my breath while I'm working, and everything will be fine. The safety manager will say, if I let you do that, then I'm going to lose my job. If you work without the necessary protections, then you are exposing yourself and the company to a disaster. You can do your work only if you comply with the standard necessary protections. I'll provide you with better safety measures when they're ready, and those will be easier to use, but you have to wait. It's simply a matter of protections. If the required level of protection is in place, then I see no issues here. The risks have been mitigated. Go forth and conquer. When you lower the risk, you increase the flexibility. So be street smart. Hackers only need to get past you, not the cloud. If they could breach the cloud, they'd be able to breach everyone. You can't expect the patterns and practices we followed on-prem to work in the cloud. We must adapt and change the way we work. The cloud is a pattern, not a place. It's not just a data center that we're moving all our apps to. We need modern security controls and automation. We need self-service with code and pipelines, not click-ops. So that concludes my first story. This one focused on dispelling the hype users have about cloud, so it would become clearer why they can't just get click-ops in production, and pipelines and code are necessary to stay safe. Users told me this taught them a lot about cloud security in a very short amount of time, and it was very relatable and easy to remember. Security professionals appreciate the story's ability to explain the security mindset and drive all the key points in a way that's simple to digest. It helped me build common ground with them to start talking about automating security's work. Let's move on to my next story, which illustrates how legacy IT can modernize and transform their operations by adopting DevSecOps and automating their work. When you first start in the cloud, it's like a bank lobby. There's minimal self-service automation. If a customer wants something, they wait in line behind a bunch of other customers for a bank teller to manually review and fulfill their request. In fact, you're lucky if there is a prioritized, orderly line of customers. Customers will skip the line and hassle the tellers directly, saying, hey, I need something important. Drop what you're doing and help me right now. It's chaos. It disrupts the teller's ability to get work done. The tellers are a huge bottleneck for delivering service. You can try hiring more bank tellers or optimize the bank teller process, but this gives limited results. You can't keep up with the speed of the business and the business will have to scale back their expectations on how much work can get done. But this model cannot scale. Eventually, banks developed ATMs, a self-service platform. A customer authenticates to the ATM, asks for a common request, and the ATM fulfills it. Anything unusual requires a bank teller to fulfill. At this point, it's still a manual process. A human must visit the ATM and physically interface with it using their brain, eyes, and fingers to punch in what they want. Requests can't be automated with code. This relieves some stress on the bank tellers, but innovation is still very limited. If I need to deposit a check, I still need to go into the bank and fill out a deposit form and wait for a bank teller to help me. Later, banks evolved to a digital model. So instead of visiting a bank, I just pull out my phone and bank from my couch. If I want to deposit a check, I just take a picture of it and the money shows up in my account. I don't even carry cash or write checks anymore. It's safer to send and receive money digitally with Zelle or to pay merchants by tapping my smartwatch. Banks exposed APIs that allowed innovation with third-party digital products. This spawned huge swaths of innovation in the fintech industry with platforms like Playd. Banking can be event-driven in real time instead of a human visiting an ATM or waiting for bank tellers to be available. AI and machine learning can be embedded anywhere in the workflow to perform fraud detection, optimization, trading, you name it. Achieving all of this required a total digital transformation of banking operations. A bank teller's role is no longer to toil on busy work. They graduate to building automation of their work. Once you have a mature self-service platform, you don't even need to expose a bank lobby to people. If a customer approaches a bank teller, tell them, I don't work on that. Go to the self-service platform to get what you want. Once everything is digitally automated, it's considered to be unusual and even risky to get started. And even risky for a human to directly meddle with assets. Keep assets safe by minimizing human access and letting automation do the work instead. Direct production access is for break glass scenarios and requires heavy oversight. Nobody is going to just give you the key to the bank vault and tell you, bring it back when you're done. If an important customer tells the bank, look, just let me go in the back and touch my money. I promise not to touch anything I'm not supposed to. I won't break anything. Just trust me, I'll do it however you want me to do it. But it's my money. It's my right to touch it however I want. That will only end poorly. That is anarchy. That is a mess. That does not work. And it diverts resources away from digital transformation to securing human access which shouldn't exist in the first place. Don't ask for ClickOps in production. Ask for a DevSecOps platform instead. Think about where banking started and the journey they made to digitally transform. Despite all the stringent security requirements of the finance industry, today banking is fully automated and accessible from my phone, sitting on my couch. Now think about the work you do in enterprise IT today. How can you achieve that same transformation? An organization must align itself to lead and not to lag behind competitors. It must reinvent the way it operates to accelerate service delivery. So how do we sum this up? What's our mantra for operating in the cloud? First, I'll show you something that I do not agree with but I still hear people say it. The cloud is just someone else's computer. No, no, that's no good. You've probably heard this one before or maybe you've said it. I think when people say this, what they're trying to say is the cloud is not a daycare. The cloud still needs lots of security controls. The cloud is still vulnerable to threats from everywhere. And that is absolutely true. But these words don't carry that message. Instead, try this. The cloud is technically someone else's computer. The cloud is technically someone else's computer but it's really a pattern, not a place. We treat servers as cattle, not pets. Use infrastructure as code. Pipelines deployed to production, not people. Least privilege access. Automate everything. Integrate security throughout development and operations with policy as code. Avoid requiring humans to review and green light everything. Humans are great at designing policies to fit the needs of the business but they're not good at standing at a checkpoint all day long and using their eyes, brains and hands to enforce those policies. Build automation robots that are coded with thousands of your policies. They can stand at all the gates and can instantly detect and block violations. A developer can create a package describing all the requirements of their application, the infrastructure services, app code, data classification, permissions, network policies, projected costs. Then they can submit it to a DevSecOps platform which can vet the entire solution across all concerned areas. Platform teams automate policies and guardrails into the platform and these will assess the application across all concerned areas. The platform emits warnings or rejects the solution if any policies are violated. Otherwise, automation deploys the solution. By shifting the checks left, the developers will cut their teeth on these guardrails from the very beginning of the development process and the entire lifecycle stays secure. It's important to include as many of the dependencies as possible. Otherwise, you may end up in an anti-pattern where a pipeline can only deploy half of the services for an application. Then the application team submits tickets to other teams for their dependencies and waits for those dependencies to be built. And then after those tickets are done, the application team runs a second pipeline to deploy the rest of the application. The pipeline needs to be able to provision, destroy, refactor, and replicate the entire solution by itself as much as possible. Otherwise, you've severely limited the productivity benefit the pipeline brings. Let's consider one more example. Think about all the data involved in a bank's operations. 60 years ago, that data lived on paper, sitting in file cabinets. And all the indexing and querying and maintenance was done by human brains and human eyes and human hands. Then databases were invented. Now the database is a co-pilot that handles all the grunt work for you. People can focus on writing code, telling the database what to do. You simply define a model of your solution and the database brings it to life and enforces it. It's faster, more efficient, and more secure. All the data operations are fully digital with no human intervention needed. Any query you write today can be reused tomorrow and the next day and so on. You never need to remember how to do a task. You're just running the same code you ran yesterday and the day before that. Imagine what banking would look like if they never made this transformation. You couldn't do any banking from your phone. You wouldn't have any digital wallet or e-commerce. The fintech industry wouldn't even exist. If the boss asks this guy for a monthly report, he's got to fetch 2,000 files from 200 different file cabinets and filter, correlate, collate, parse, and summarize everything with his human eyes, hands, and brain. It's terrible. In conclusion, bank tellers and file cabinets cannot scale. The cloud is a pattern, not a place. It's not just a data center where you put your existing tools and processes into. We need a digital operating model for the cloud. And that's my talk. I hope you enjoyed it. My name is Brian Moore and I'm a cloud architect based in Houston. I love thinking of ways to teach complex concepts to people. If you found my stories interesting and you'd like to hear more, feel free to connect with me on LinkedIn. Thanks again.
