As the need to develop applications more quickly – at the pace of innovation – has increased and as government agencies have looked to introduce more scalability into the application development process, software development teams have moved away from developing massive, monolithic applications. Today, the monoliths of the past are being replaced by applications that are composites of multiple microservices – smaller components with unique functions.
There are a number of benefits of developing applications with a microservices architecture. They can be deployed more quickly and efficiently. Microservices can be developed once and used in multiple applications. Each individual microservice can be upgraded or serviced individually. And any failure with an application can be more quickly and easily identified and repaired.
But are microservices always better? Or are there security risks and challenges that arise from embracing a microservice architecture?
In the most recent episode of the ContinuousX Podcast, hosts Rick Stewart and Mike Fitzurka have another fascinating discussion with Peter Chestna, CISO of North America at Checkmarx, on how security layers in microservices differ from the old monolith being broken down, and how to establish each microservice as its own security island.
Transcript: ContinuousX Podcast (Season 3, Episode 5) Checkmarx’s Peter Chestna on Security Risks with Microservices
Rick Stewart: Welcome back to another episode of the ContinuousX podcast where we try to “Solve for X in the SDLC equation.” We’re back with Pete Chestna, North America’s Chief Information Security Officer at Checkmarx. Pete, welcome back.
Peter Chestna: It’s a pleasure.
Rick Stewart: Terrific. Pete, we have another question for you. As enterprises move towards microservices architecture, which we alluded to on our last episode, what challenges do you see resulting in the fragmentation of monolithic applications into many services with potentially many different language choices that development teams can choose from? Does that increase security vulnerabilities, and if so, how can they be addressed?
Peter Chestna: I think it is less about the language choice. What we want is for them to be comfortable in the language that they choose. Certainly, there are certain languages that are better at certain things. So, there is a rightness to the choice. And as you break things into smaller and smaller chunks, and they become more specialized, then you should expect that there are different language choices that could be deployed as part of that as well.
But it comes to – What is your workforce capable of doing? What languages are they good at doing that in? And how much risk do you want to take on with taking on some of that burden? I think more of it is about, as you break… and I’ve done this before, I’ve been part of teams that have broken monoliths into microservices. If you think about from a security implementation and a security design standpoint, when you take a look at a monolith there are very few gazintas (goes in to). So, as you go through those gazintas, that’s where your security controls live, and I do things like, cleansing, etc., either in the gazinta or gazouta (goes out of) side.
And as I start to fracture that into more pieces, If I just take the code that did that function and say, okay, now you’re on microservices. Poof. Well, what did it think of what happened upstream? Did it say, well, I’m counting on the gazinta that was four levels above me to have done cleansing? So, by the time it got to me, it was supposed to be clean, but now I’m exposing it as its own bespoke API. And if someone attacks that, and someone comes there, and I make an assumption that I can trust it, but I can’t, now I’ve got a problem.
So, there is a way that you need to think about the secure implementation of the fractured monolith to microservice, especially as resulting in the APIs. You have to think about each microservice as its own security island, as its own application, that does certain things. It’s got its own gazintas and gazoutas and those have to be secured.
So that’s probably the biggest mistake that I see in the industry; is people say, Oh well, I’m just going to move it and now it’s a microservice. And while that’s true, and now it can be deployed separately, and quickly, it doesn’t mean that it was secure. It may have been secure in the context of the monolith, but no longer when it sits on its own. It’s like hey, come talk to me. I’m over here.
There are reasons that there are layers in the security and that in a monolith you wouldn’t impose those security controls at every level. Because it’s not practical, and it degrades the performance of the monolith. But in a microservice architecture, those controls are now all gone and now it’s the Wild West, and you need to be thinking about that. Understand that your attack surface has changed, and that the decisions that you made previously, still need to be applied at every level, and not just the initial level where they came in.
You think about even a client server type application, that I do client level checking and I do server level checking again. The same is true at the microservice level, each micro service has to do its own thing, and validate and understand the risks. So, threat modelling is really key here to walk through those.
Rick Stewart: I’d only say that the language choices may have an impact because you could have X number of teams that are supporting X number of microservices that would constitute one monolithic system. And let’s say that a monolithic system was written in Java, then you only have to worry about the dependencies of that particular language, or that system.
Now you have a proliferation of many different language choices, and all those dependencies that you need to be now responsible for in your context, like you said. The advent of service meshes and whatnot can be controlled around a particular microservice, but you still have those vulnerability potentials. And now a fragmented set of languages that now constitutes your system instead of one.
Peter Chestna: That’s true. It’s definitely true. And the tooling is still evolving in the API space to think about understanding what you have. So, do I have the full picture of all of the assets? Being able to group and have attribution by application? Understand the risk that’s being taken by that application being deployed? As well as that outside entity, you also need the inside out? Am I doing static analysis on those? Eventually we’ll get to the world where dynamic analysis is easier.
But really, if you think about what an API does, that very segmented piece of functionality, those usually need to be chained together with very specific contexts passed between them. And that’s what makes testing APIs very difficult, is that you got to get it in the right order, pass it the right input, or it says, I don’t know what you’re talking about.
So that’s a no-go – those aren’t really valid tests. So those become… That’s the place where we’re stretching the testing side of the controls, to get the vendors to come in and help you identify the landscape that you have and is it really secure.
Rick Stewart: I agree. Think of a sentence being a monolith that you have all these words that can pop off and they’re just words. They’re not cohesive in context, and they’re not completing a thought as a sentence would. So, that’s the analogy I couldn’t take with it.
Peter Chestna: Or even worse a chapter.
Rick Stewart: That’s true.
Peter Chestna: A paragraph – If you take a paragraph or a page or a chapter, and dump that out, that’s what microservices look like. And you can’t just arrange those words in any order.
Rick Stewart: Exactly.
Peter Chestna: They have a specific order to bring meaning to the customer and bring value to the customer. I love that analogy.
Michael Fitzurka: And page two gets to first because page four and page one are in different processes, and you get them all out of order.
Peter Chestna: Right.
Michael Fitzurka: Yeah, exactly.
Rick Stewart: I think that’s the challenge with microservices is to harness. How do you make sure that it’s operating in context.
Peter Chestna: And you also think about some of the timing-type attacks. In the context of a monolith, very hard to see with very big, long tails on the process. But if you start to go API by API, now, some of that timing is really standing out. Where you find the right one, you’re like ah-ha, I’ve got something here. So, when you put a smart person that can intuit properly, they’re gonna look at those things and say, I think I found something here. That’s where you get into trouble.
Rick Stewart: Well, Terrific. Pete, always a pleasure talking to with you. We appreciate your time. And we appreciate the audience’s time for listening, as we try to “Solve for X in the SDLC equation”.
