![DevSecOps: Minimizing New Attack Surfaces for DevOps [Interview with Mitchell Ashley] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F2c5da07e-8246-46f1-8643-82b5c25525d8%2Faid_field_img__e57339882c484049cc8e60dac1217efd.png%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_3EAuLccmwaq4KZ9GcZftJq5NbwLA){kind=small}
Mitchell Ashley is the CEO and Managing Analyst of Accelerated Strategies Group where he leads a team of preeminent experts in digital transformation, DevOps cloud and cybersecurity. He is a renowned strategist and technology executive who has driven successful IT, SaaS, and cybersecurity transformations. He’s led multiple teams in developing and bringing to market successful online services, cybersecurity, and networking products and services. Mitch’s popular DevOps Chats podcast—which engages with digital leaders—is one of the most widely followed in the field.
What’s the one key question you think organizations are trying to answer in the cybersecurity and DevSecOps space today?
Mitchell: The key question used to be: "Am I spending too much?" and now the key question is: "What do I have to do so that a breach doesn't appear as a boardroom issue for my company?" I work with a group of CIOs in a mastermind group, and a common topic there is how you take a security incident to the C-suite and potentially to the board of directors. They want to avoid that type of event, but it's almost inevitable now that it will happen—no matter the size of the business. When a security breach happens, board members want to know that you're going to find it, you're going to take care of it, you're going to address it and be able to tell them how big the problem is, and that there will be a team beyond the security organization and the IT organization who are also part of a response process. I think most organizations recognize now it's an executive level issue, not just a technical CISO, CIO or IT issue.
"Am I spending too much?"
Increasingly, boards understand that things happen. Even if it hasn't happened to them, fellow board members and people in the networks that they run into talk about it. They talk about breaches that happened at other organizations, how they happened and how they were handled. Executives want to know: "What's the impact on our customers? What's the impact on our business? What is the recovery? Is this an internal issue, or is this something that is going to be external facing, and how big a response do we need?" Board members are obviously not going to be involved in all the details of that, but I'm of a view that if you're going to be a CIO, you'd better have a security background or at least some very good training and expertise in security, because it isn't just something you can hand off to the CISO.
As we talk about DevSecOps and the integration of the security into software and infrastructure and architecture and operations, it's pervasive in all parts and it represents an increasingly bigger attack surface.
How do people classify different types of attack vectors?
Mitch: I think there's a common misunderstanding about security threats, in that people think they're all highly technical, all about some vulnerability in the software stack or the infrastructure of the network. While those are ever present, and certainly in volume they’re probably the largest, I think what the board room and the C-suite experiences the most are attacks on business processes.
I'll give you an example. One of the incidents that I was part of investigating was looking at how someone got into a hosted email service, redirected email unbeknownst to the end user, and from that saw invoices going out through email, or responses to email, and then faked a series of invoices and captured money that way. It was only through following up missing payments that it was discovered. CEOs and CFOs receive all kinds of phishing attacks that you and I don't receive, and they receive attacks like emails that look like a DocuSign document for approval.
I think of security threats similarly to salespeople in that salespeople work in a world where they flow like water; they flow to the path of the least resistance to get the deal. Security threats are the same way; the simpler the path, the better. Attackers get money by mimicking people and relationships and intercepting asynchronous business processes. Imagine, you can have an invoice for a couple million dollars or more very easily in a large corporation, and if you can redirect that payment to a bank in some other country that then can't be traced, that's a big payday for an attacker. I’m hearing a lot more about executives talking about attacks directly on business processes like that.
So that's the leadership level of attack vectors, what about the team level?
Mitchell: At the team level, the nature of the software stack is changing through what we call democratization of IT; that’s open source, online services, big data, the proliferation of locations and so on. We also have shadow or rogue IT; any large organization has development going on that they don't know about in the core technology teams.
One of the biggest issues for security teams is how they get into the flow of those things happening. Historically, we've treated security as being the firewall so that bad things don't happen—like bad software being created, or things going into production that shouldn't. That's too easy to get around now, and security organizations are realizing that.
They worry about operational environments and are increasingly thinking about working with development teams and finding easier ways of flowing security technology into the development process. Security engineers want to be less of a ‘cop’ in the process and more of a facilitator of what needs to be done to meet regulatory, compliance and security best practices. Rather than telling teams to run a vulnerability scanner that will tell them all the things they're doing wrong, they want to work with them to figure out how to introduce secure code into the process, how to create secure development and test environments, how to create a secure tool chain and pipeline process.
Security people have to start understanding how software is developed and how code is architected. That's a big change, but security has to work on creating new ways of working with the organization and not just saying “no” or demanding permission before anything is done.
What patterns do you see that help organizations provide policy controls, and demonstrate due care for machine identities such as SSL or TLS certificates through multi and hyper-cloud environments?
Mitchell: I have two perspectives; one is cloud infrastructure and the other is that there are end devices of infinite kinds (IoT). In a digital transformation environment, organizations are looking to radically change how they leverage technology as part of their business, and that's what's created in part the proliferation of mobile applications. For example, apps on mobile devices are much more prevalent and much more commonly used than people logging onto a website to use your service, in many cases.
When we talk about machine identity, it can be the IoT devices, it could be mobile devices, it can be sensors connected across diverse networks. There are all kinds of reasons to want to know about a device’s identity. Before we get to the cloud, let me talk about the device side of this. One of the experiences I had in my career was supplying PKI digital certificates for multiple industry ecosystems; for the global cable industry, for energy management and monitoring, on-demand response monitoring, IoT devices and wireless devices.
An example of a connected device could be one on the side of your house that monitors how much demand you're pulling from the power grid for your air conditioner. Or an energy monitoring device that's monitoring how much energy you're putting into the power grid from your solar and wind powered devices. Now you're dealing with devices that you, the service provider, don’t make, devices you don't sell, devices you don't provide to customers. And that's true of IoT and it's true of energy management, but they're still connected to your network, whether it's a mobile device or an energy monitoring device.
That's machine identity; it’s the identity of a device in the ecosystem we work in. We need to know what the device is that's connecting to the network, is the device what it says it is and what we believe it is. We need to know how much we can control it, manage it, or wall it off if needed.
Cloud infrastructure and zero-trust
Then let’s consider the cloud: the software architectures, the cloud infrastructure, the services that we're using. We're rapidly moving to cloud native and using containers and Kubernetes, and the attack surface changes because you're exposing much more through greater API-based applications, as well as through microservices and containers. The scope of this is huge and we have to think about security from each one of those points: from the bottom up, from the top down, and the outside in.
That's why things like the zero-trust reference pattern are popular, because you essentially have to trust nothing. There is no trust, because anything could be potentially compromised. The real issue is, how do you minimize what a given machine can get access to? Every attack on a network is about one thing: getting into the easiest place, and then getting to the most valuable thing, which is usually the directory, or some other way of getting credentials, keys, tokens, certificates, things like that. It allows them to essentially have carte blanche access to everything.
"not everyone is highly skilled at [PKI]"
I'm a big believer in digital certificates if they're well managed and they're well crafted. Not everyone is highly skilled at that, and sometimes you need greater skills if you're creating a PKI ecosystem for an entire industry, versus if you're doing something for your own applications and infrastructure. That's increasingly important, because you may be managing that PKI for many years, even decades. You’ll need to upgrade encryption algorithms, key lengths, and how to update devices over long periods of time, and the processes associated with running a well-managed PKI.
Products or systems that help you manage keys and security assets are increasingly popular, because now we're doing that all through the stack of the application and the infrastructure and devices.
How important is sharing and openness in DevSecOps, given that organizations are frequently very sensitive about showing weakness or vulnerabilities?
Mitchell: As a security community, one of the things we adopted early on is there's a certain amount of security through obscurity. There was a time where we didn't talk about what tools we used, you didn't tell anybody what firewall or what vulnerability scanner you used because you didn't want people to know, because you didn't want them to know how to attack you or what your security architecture looks like. We haven't had a culture of sharing, except when it comes to attacks and how to identify them. Traditionally, sharing has not been part of the security culture except in limited cases. Increasingly now though, particularly with DevSecOps, we’re seeing individuals starting to share their frameworks and their lessons and some learnings to help others. I think that’s also why we don't have a strong standard or adopted framework for DevSecOps yet.
How are regulatory changes like GDPR and CCPA changing the way organizations behave?
Mitchell: They're at different stages; GDPR has been in effect longer, but CCPA is still new and for the state of California although others are talking about adopting it. While a lot of great things happen in the state of California, it's not as big as the EU taking on privacy regulation. The stealing of credit cards and personal data is only going to increase exponentially until there are some consequences to businesses and organizations for that, more than reputational damage, more than loss of information or some of their own intellectual property.
GDPR and CCPA are responses by governments trying to give users some control back over their personal information. I think privacy regulation will continue to grow in momentum and will force change upon organizations. It forces the change away from the business model that the customer is the product, or at least challenges it significantly.
Is there a reference architecture or common toolset you look to as a model for engineering teams wanting to improve security around their product, pipeline and platform?
Mitchell: PKI is a pretty well-established reference architecture for machine identity. Cloud services are often built around digital certificates so it's a common baseline for machine identity. As you expand beyond that, there isn't one reference architecture. There isn't a NIST certification or a NIST guide for DevSecOps or for application security but some individuals that have created their own, like Larry Maccherone.
The other place that you tend to see it is around the financial industry, like PCI compliance for protection of personal information, which has essentially become a reference architecture for security.
"you have the potential to introduce a shift left approach and introduce security early"
There are a number of tools. If I were a security person, the first thing I would do is learn the DevOps processes, CICD, the tool chain, the process pipeline. Every one of those steps is a place where you have the potential to introduce a shift left approach and introduce security early into the process. If you're a security person, the good thing is you don't have to throw away everything that you know about security and security operations. All of that's still highly relevant, you can now apply that into the domain of software and software architecture and how software is created, but it's going to take a commitment by you to learn about the software development, delivery process and tools.
How do you define security debt and how can teams and organizations avoid accruing it or pay it down if they have it?
Mitchell: You're either improving at what you're doing or you're staying the same: security debt is the activities or the investments that prevent you from improving. If you're at a place where you're relatively stationary and you're not getting to the security architecture or whatever it might be that’s part of your CISO's plan, if you're at that point where you're not moving forward, then you've been overcome by security debt. What's interesting to me about technical debt and security debt is you can't always solve it by going back and working on it, sometimes you have to jettison it, taking a significantly different approach.
You can't always do that, but you may be better off, for example, changing what software you're using than trying to go back and retrofit all your changes that you made to an open source project, because you've made so many that you're three generations behind and you're not able to apply security fixes anymore. It may not be worth it to go back and try to catch it up, it may be a time just to punt and to do something else.
What does good DevSecOps posture look like?
Mitchell: Proactive, progressive security teams are working closely with development teams to identify where they can introduce security tools and improve security processes. When security teams look for ways to proactively collect information that's going to be needed for compliance reporting that can be automated into DevOps processes. The goal is to make meeting a compliance requirement simply running a report from data collected through automated processes as software is being created and managed. That’s juxtaposed to the typical scenario where dev teams have to go jump through hoops at the last minute to gather up the data necessary.
Will DevSecOps live forever?
Mitchell: No, there'll be something else that'll eventually replace DevSecOps. There'll be a new approach, just like there was Agile and now there's DevOps and DevSecOps. DevSecOps will evolve but there's still a lot of catching up to do. If security professionals really embrace software and how software is created, I think they'll accelerate their careers and their organizations. There'll be a new methodology someday but DevSecOps will be around for a long time for sure.
Why Do You Need a Control Plane for Machine Identities?
Related posts