![There’s No Easy Button for Security in DevOps Tools [Interview with Ian Murphy] - cover graphic](/_next/image/?url=https%3A%2F%2Fcdn.venafi.com%2F994513b8-133f-0003-9fb3-9cbe4b61ffeb%2F47c50979-0957-4e08-a234-2e9ae75fba10%2Faid_field_img__d11a9acb7426ec8d9284e241977d174b.jpg%3Fw%3D864%26h%3D370%26fm%3Dwebp%26q%3D75%26fit%3Dcrop&w=3840&q=75&dpl=dpl_BHtzFuj7x8fHcssjFHrhmmifkwhC){kind=small}
Ian Murphy is co-founder of LMNTRIX and well-known cybersecurity strategist and speaker. I recently spoke with Ian about the importance of incorporating a security-centric mindset into all levels of DevOps, the future of automation, and strategies for keeping your head above water when it comes to security data.
How do you define DevSecOps?
Ian: I don't think I do. I don’t think there's a need for security in the development and operations side of things. We just need people to be security aware and to have a security leaning in everything they do. I don't know how many online cloud apps or how many cloud infrastructures need to be breached continuously for others to understand the challenge. Just having Sec within DevSecOps seems to offload that responsibility to some kind of security guru who's got your back when, in reality, they seem to be the people who you beat up after the sticky stuff has hit the fan.
How do organizations stop themselves drowning in security data?
Ian: The first thing we could do is stop buying stupid technology that promises to solve this nonsense for organizations. Data is data. They need to work out what's good and bad data in the data they have. Thinking that you can buy a tool you can throw everything at and it will just magically come out with some kind of security stuff isn’t helpful and often doesn’t get an organization any closer to their end goal. But most people don't know what that end goal actually is. It’s better to offer people the chance to sit down and explore their business, the risks and the big-ticket items within that business. If they're a fish and chip shop, they shouldn’t really be worried about an APT from some unknown country somewhere, therefore they don't need a massive SIEM to collect all their data from their deep fat fryers. It's just not necessary. People must take it back to basics and understand:
- What they are in business for
- Who's interested in their business
- Where attacks are going to come from
- How valuable their data is
- Who is connected to their network
- What is connected to that network
- What states those connections are in
- Who has permission to do what
It's about scaling it back and asking the basic questions that people don't because they're either too busy or too important; if we have a more pragmatic approach to securing our systems, then people won't be drowning in the data. There will still be a lot of it, but they won't be drowning. And they’ll have a better chance of spotting the perennial ‘needle in a haystack’ that so many tools or service providers offer, but very few deliver.
What is intelligence-led threat detection?
Ian: It's great to go hunting for and detect threats, but you want to know what you're going after; you want to know whether it's specific to your industry or your business or you as an individual. There's no point detecting or going after things that have no relevance to you. Threats are only important if they are relevant to you and timely and you can do something with them. It's almost like drinking from a fire hose and it comes back to the security data. You're going to be swamped with indicators of compromise that mean nothing to you, so you need to make it specific and relevant. Then ask yourself the question: do I have the right people doing this? It’s proactive threat detection rather than sitting back waiting for bad things to happen—and some clever clogs with an intelligence feed says: “Well, I told you that. I told you it was going to happen.” When, in reality, the intelligence data was buried in a mine of other intelligence data that was useless. Then you don't have the proactive capability or the expertise to make sense of all that information coming towards you. Intelligence-led threat detection is an absolute must if you're going to do this proactively, but it has to be timely, accurate and relevant to what you're doing and the sphere in which you operate.
We talk a lot in this industry about the cybersecurity skill shortage. How do you address that?
Ian: I’m an ex-footballer. When I think about my football career and of being a defender, I refer to the strategies we used as a team. We would base the team around the goal of what we wanted to achieve; winning a game, league or cup, for example. Then we built a spine of the team of experienced players. We would spend a little bit more money on those people. We would treat them right and make them feel wanted. We would allow them to do what they do on the pitch; avoiding stifling them but instead empowering them to have autonomy. Then we surrounded them with young, hungry, talented individuals. Taking the analogy a bit further, you may want a left-winger who is quick and can go past players and provide ammunition for the forwards. If you have this talent in the team but they lack some experience then it is the job of the more experienced players to coach them. As leaders, what we must do is create a strong spine to the team, then bring in young, hungry, passionate people. It's the only way we keep the lifeblood of any industry flowing.
What are the foundations of a strong security posture?
Ian: Paranoia. It's a horrible, gut feeling, but I've always found if something doesn't seem quite right it probably isn't. It's difficult to explain how you develop that; I think it generally only comes with experience. My background is ten years in the UK Ministry of Defence then out into the civilian world. At the time, the threat to the defence forces on the UK mainland was the IRA and we were skilled in understanding what to look for and this generated a paranoia from a personal security perspective. Then you move into technical security and you can take that with you and you then understand. When you digest that and align it with today's modern world, it's about understanding the assets you're protecting and the value of those assets to other people. Then there is a sense of purpose in what people should be doing and how they should be doing it, as well as helping the business take positive risks. More often than not, people see the security function as the team who like to say “no”, when actually we should be the team that is there, in the background, helping business leaders take calculated risks—and there's a positive side to that.
How can organizations make sure they buy the cybersecurity products that are right for them and that they receive a return on their investment?
Ian: There's a lot of stuff out there that people don't need. A lot of people go with what’s on-trend, what somebody else has bought. Go to any security vendor or service provider’s website and you'll see a list of their customers and their testimonials. That gives people the thought and confidence that they should be doing it too. I've spoken to a lot of CISOs recently, and what they're doing more and more, rather than referring to a Gartner magic quadrant or testimonials on websites, is asking their peers what their experiences are with tools. They are looking more into newer and innovative startup organizations who can offer them more than just one product or just one service and who can offer them turnkey solutions, with several use cases that they solve.
Anybody who's led by ‘blinky lights’ or the promise of a trip to RSA in San Francisco needs to rethink their approach. People need to be more savvy about it. People also shouldn't do it through an RFP because, when you run an RFP, you end up with the cheapest product that solves about 60 to 70% of your requirements and people lower their price to be able to sell to you. But with the lower end of that price comes the lower end of the requirements, so if one of your requirements is mandatory, you're possibly going to get 50% of that because you forced that vendor or service provider to lower to a point where it's not really acceptable to them and it shouldn't be acceptable to you. Cheap doesn't mean value.
How much of our application and infrastructure security can be automated?
Ian: As much as the business is comfortable with. We need to try to automate the tasks that can easily be performed by machines without the intervention of a human being, whatever they may be. When it comes to the security sphere and automatically preventing issues, that needs careful planning and careful consideration. Here’s why: Unwittingly you could potentially cause your own internal denial of service by adding things that had been seen on your SIEM that are potentially a threat on them to your blacklist, on the firewall or alternatively adding them to the white list.
Do vendors spend enough on security?
Ian: No. If vendors spent more on security than marketing, our job would be a lot more difficult. Vendors come out with MVPs because they want to hit the market and get ahead of the curve. They want to be the first to market on stuff, despite a lot of evidence that says first to market isn't always the winner. In my mind, MVP isn't ‘Minimal Viable Product’, it's ‘Maximum Vulnerabilities Permitted’. I think vendors are too quick to pull the trigger. I think a lot of the marketing departments are cashing checks that they can't pay. So when people come back and say: “You told me this was AI, next gen and would cure all my ills, but somebody just strolled in past all your defenses and has taken the entire contents of my customer database,” security vendors will just retreat and claim it wasn’t configured properly. There's an incumbency upon us, as vendors and service providers, to actually make the customer aware that if they buy into this, if they're going to buy a SIEM or a managed service, that's the beginning of that journey. It still needs integrating with internal processes. It still needs that trusted relationship between the vendor and the customer to make sure it's working. It still needs the use case building. A lot of people are either not told this or are downright lied to.
Why are (TLS/SSL) certificates still a challenge for DevOps?
Ian: It's always been the case. Possibly it’s a result of the approach of initially setting up a test system with the intention of producing an MVP. So people plan to just have a test system with some self-signed certificates, and mock it up without any of the real-world infrastructure that will be there in live, such as the load balancers and the proxies. Then, when the system goes live, and people try to connect a service to a third-party provider, they either discover thatcertificates aren't working, that they don't have the same relationship or they can't build a VPN tunnel.
From a certificate point of view, it always seems to me that people are running to get the service, the product, the app, whatever it is, out. So, when they're building and testing, they want to use self-signed certs and all of that good stuff to make their job easier and they think it will be really simple. They plan to worry about that when they get to the end. It's always been my experience that these are the things that trip people up, especially when they want to go live. Then issues arise where people want you to take on necessary risks with the certificates, whatever they may be. When teams build new applications and the full infrastructure isn't there (the load balancers, the proxies, the security devices) while they test it end-to-end with their own self signed certs, it appears to work. But at go-live, when it’s tested with a third-party app for example, that's the bit that comes back to bite you because nobody had put any forethought into it beforehand. And then everybody's just screaming that they can't go live, and it becomes security's problem again.
Will DevSecOps live forever?
Ian: Probably. It'll be called something different next year, I would imagine. That's what we do. I don't see any revolution in our industry. I see evolution and I see regurgitation of the past. If I'm being cynical, cloud is just mainframe. Zero trust is no different from the paranoia we had in the past around compartmentalization. There’s a lot of marketing around artificial intelligence and machine learning that in reality have been around for decades. DevSecOps will probably migrate to a funkier title to get the kids involved and get them coding furiously. I don't mind what they call it and, even though I’ve said we shouldn't need ‘Sec’ in the middle, I understand why it’s there. As long as we have a security mindset and a security leaning, we will be better off moving forward. There are three truisms around what we do: we are stupid as human beings; we will make mistakes and there's no patch for stupidity. There will be criminals that want to prey on the unknown; they've been there for time immemorial no matter what medium they do it through—whether it's breaking into your house or breaking into your network. And vendors will provide bad code because of time pressures and poor processes. We need to accept and live by these truisms.
Machine Identity Security Architecture
Related posts
- DevSecOps: Minimizing New Attack Surfaces for DevOps [Interview with Mitchell Ashley]
- What Is Your DevSecOps Manifesto? [Interview with Larry Maccherone]
- US DoD Reference Design for DevSecOps [Interview with Nicolas Chaillan]
- DevSecOps, SecDevOps, or RainbowMonkeyUnicornPony? [Interview with DJ Schleen]