Ep #119: What is a Microservice Architecture and how do I secure it?

Whatever kind of software application a team is building, the identification and remediation of cybersecurity issues needs to be part of every stage of the software development lifecycle (SDLC). But making that happen takes a wealth of skills and approaches, as well as an eye on compliance and the ability to keep pace with the ever-changing online environment—microservices being a prime example.

In this episode, your host John Verry, Pivot Point Security CISO and Managing Partner, sits down with  Laura Bell Main, CEO and Founder of SafeStack to give business and security leaders a clear and logical overview of microservice security issues and more.

In this episode, join us as we discuss:

• What a microservice architecture and how it relates to other design approaches, languages, and frameworks
• The microservice software supply chain and the limitations of a Software Bill of Materials in a microservices context
• How using microservices changes the approach of securing an application
• How zero trust concepts relate to microservice architectures
• How SafeStack is helping to educate developers about application security in organizations of all sizes

To hear this episode and many more like it, we encourage you to subscribe to the Virtual CISO Podcast.

Just search for The Virtual CISO Podcast in your favorite podcast player or watch the Podcast on YouTube here.

To stay updated with the newest podcast releases, follow us on LinkedIn here

See below for the complete transcription of this episode!

John Verry  (00:00):

Uh, hey there, and welcome to yet another episode of the Virtual cisa podcast with you as always, John, very host. And with me today, Laura Bellin. Hey, Laura.

Laura Bell Main (00:09):

Hey, John. How you doing?

John Verry  (00:11):

Thank you for joining me all the way from New Zealand.

Laura Bell Main (00:15):

Yeah, it’s great to be here.

John Verry  (00:17):

Wow. Hopefully I’ll make it worth your time. Uh, I always start simple. Uh, tell us a little bit about who you are and what is it that you do every day?

Laura Bell Main (00:25):

Awesome. So, I am a bit of a strange one. Um, I am half software engineer, half security person, and that means I live half of my life being excited about the world of technology that we’re building and the other half pondering why it’s all on fire. Um, so yeah, that’s, that’s the best summary I can do of my world. Um, I’m the CEO of Safest Stack and so I’m on a bit of a mission, if you will, to, uh, try and give as many skills and security as we can to the dev community so that we can build this amazing technology safely together.

John Verry  (00:56):

So half developer, half security persons who you spend most of the day fighting with yourself?

Laura Bell Main (01:01):

Pretty much. Yeah. I think I just picked like the, the job title with most cognitive dissonance. <laugh>

John Verry  (01:06):

<laugh>. Um, so, uh, I always ask, uh, what’s your drink of choice?

Laura Bell Main (01:13):

Uh, once upon a time, it would’ve been a very different choice. Um, uh, day to day. I love, uh, you know, a good cold kocha and just chilling out or even just a glass of water, to be honest. I’m getting old. Um, and I love, I’m less of a kind of casual drinks person. I’m more of a, I like a drink experience, so something, you know, where you go to a bartender who knows how to mix cocktails and you say, Hey, I’m in this kind of mood, and they bring you out something. Um, and you can always tell that your day’s gone wrong when they bring out the absence. So, um, yeah, just something, an experience and a glass. I think that’s fine.

John Verry  (01:45):

Yeah, I like that. Um, uh, it, it’s funny that two nights ago I was at the bar. I, I walked into a bar with my wife and it was, we, I did the same exact thing. I said, you know, I’m, I’m in the mood for something, miss Scally. He asked me a couple questions and he made me something and it was awesome. Mm-hmm. <affirmative>, uh, you know, it’s like a said, you know, like a, a speakeasy style kind of.

Laura Bell Main (02:03):

Exactly. I, there’s, there’s only a special type of bartender who can do it, and I always thrilled when I meet one.

John Verry  (02:10):

Yeah, yeah. I, I agree with you. We were in a, a speakeasy, uh, crazy place down in Charlottesville, Virginia, uh, last year. And, uh, the entire night, like there was no drink menu. The guy would just come over and say, what do you like, what’s your flavor? Before, you know, and he would just bring you something mm-hmm. <affirmative>. And it was remarkable where there was five of us and we probably had three or four drinks a piece, and there wasn’t a bad drink amongst them all.

Laura Bell Main (02:32):

Exactly. And I, I think, you know, if you work hard all day and you do complex things, then it’s important to have little bits and pieces that just make you smile and enjoy the experience. Um, and you have those little moments.

John Verry  (02:43):

Couldn’t, couldn’t agree with you more. So, uh, fair warning to all of the folks that listen to this podcast. You probably realize that often I ask questions that I know the answer to, and I’m just doing it for your benefit. Uh, that is not going to be the case in this podcast. Uh, this topic is, uh, is a, is a challenging topic, and it’s one that I’m not, uh, nearly as intelligent as I would like to be on. So I was thrilled when I had an opportunity to get Laura to come on, uh, cause I’ve seen her speak on this topic and, uh, and she knows her stuff. So, um, so a microservice architecture is an increasingly popular architectural style for building apps. Uh, of course, anytime you change, uh, architecture that’s gonna impact security, which is why I’m excited to chat with you. So let’s start with the basic, uh, cuz I think that most people would struggle to define what is a microservices architecture. And then if you could at the same time talk a little bit about what makes it so different from a more monolithic architecture.

Laura Bell Main (03:45):

Sure. Now, firstly, I’m gonna set the scene, um, much like if any of you have been around the agile movement in the last 15 years. Um, there’s a lot of hype in this space. So we’re gonna kind of pull it back to as the, the kind of the fundamental parts. This isn’t about every type of possible permutation of microservices. This is, you know, your fundamentals. So a microservice is, um, an architectural choice in software where instead of having a single large application that we continue to add functionality to, that’s what we call the monolith. We decompose or restructure, uh, our application style to have separate services, each service having a particular role to play in the system. And at its simplest, um, you can sometimes hear this described as having, uh, the principle of single responsibility. So each of those services has a reason to exist and a single reason to change.

(04:40):

Now, on an architectural level, that seems quite sensible because instead of having this giant complex ball of code that you’ve built over 15 years, that you need to figure out how to, uh, do your changes to, you can add a new service on the side. Um, and that can be very focused and very targeted, and it can allow you to pull away from the inherited complexity of whatever your legacy looks like. However, there’s quite a lot of complexity in and of itself in the choice to deconstruct or decompose. So, um, the, the fundamental piece to remember is it is just a choice. And also you don’t have to be all of one thing and none of the other. So, um, there’s no, there are very few organizations that, that, that are truly only microservices. Your organization, for example, might have a monolith that is keeping the lights on, that’s, you know, your core system, that everything is hanging off, but your newer code, it’s much easier to add as microservices around the edges. So you can end up almost kind of like the sun and the planets where you have, you know, your little monolith in the middle and increasing numbers of microservices throughout your, uh, system as it expands outwards.

John Verry  (05:49):

Gotcha. That was excellent. Thank you. And in, in terms of what drives people, like, so what are the, if you will, the benefits, right? What, what drives to make those decisions? And how would you, if you were working with a client and let’s say you were consulting with them to make that decision, right, they were greenfielding a new application, what would be some of the questions you would ask? How would you help them make that decision? Hmm.

Laura Bell Main (06:10):

Well, first I’m gonna plug a little book that’s not mine. So, you know, I don’t get anything from this, but there are some excellent books in this space. So, Sam Newman wrote a couple of books with O’Reilly about this. If you wanna go deep, that’s a really good, great place to start. But let’s look at it in its simple terms. Now, let’s look at our, I’m monolith say our organization is a bank or an airline, and there are systems in there that have been there for a long time, and that’s cool. A lot of people will talk about legacy coders if it was some kind of dirty word. It’s really not. That’s the code that made your business what it is today. So we’re never ashamed of that. It’s just your foundation. But that foundation could be written in different ways, different styles than you would write it today.

(06:48):

It could be written in languages or frameworks that aren’t really keeping up to date with what is available in more modern, uh, software languages or frameworks. It could be that all of the institutional knowledge for that monolith is gone, or is collected into a very small group of people. And that makes that cart code very, very hard to work with. It’s not easy for you to then just walk in and go, all right, I’m just gonna fiddle with this little bit over here. Cuz in many cases when you do that, something over the other side is gonna break. Um, and that fragility, that brittleness can be really detrimental to system performance, to scaling. Um, and just the, the overall user experience of the folks using your app. Now, this is where microservices can be a really great place to come in. Now, if you wanna add new functionality to something that’s been there a long while, or if you want to embrace a new technology in a limited way, but without having to re-architect the entire stack that you have, microservices can allow you to add functionality around or instead of that monolith and do it in different technologies each time, have different patterns to the way you develop your code.

(07:53):

Have increased autonomy between development teams. If, say you’ve got multiple development teams all working in different ways, they can have a degree of autonomy in that. And that flexibility can be really, really useful, especially if you’re trying to go very fast if you’re trying to solve challenges that are very broad. So, you know, some people are trying to deal with real time systems problems and some people are trying to deal with the mobile experience. They’ve got very different constraints on them. So it gives you that flexibility to adjust that way. The other thing is from maintainability, um, just to finish that out, is that it’s much, much easier to maintain something that’s small. Even if you have many of them. You can read all the codes, you can go line by line and understand what that thing is doing. Now, if you try and do maintaining on a, an a legacy or foundation system you’ve inherited, that can be very challenging. So it has its benefits in terms of being able to pick up code that somebody else has written in a very concentrated form, look through it, understand what’s going on, and then make sensible changes in isolation from much of the other functionality of the application.

John Verry  (08:57):

Yeah. One thing you said that I, I hadn’t really thought about with a microservices architecture is would it would allow you, I guess, to be able to write each of those microservices in different languages if I have people who have different skill sets and or if there are particular languages that are, uh, better suited to each of those different types of, right. So, so maybe there’s third party libraries that I can just leverage directly or something of that nature. So it also sounds like it would give us a lot more flexibility from that perspective. A

Laura Bell Main (09:30):

Absolutely. If you look at, you know, what’s going on in tech at the moment, we’ve got a lot of data science going on all over the place mm-hmm. <affirmative>, um, for lots of amazing reasons. Now, most data science teams are gonna wanna choose something in the Python suite. Like I’d say 90% of the teams end up in Python, <laugh>. Cool, sweet. Let them do their Python. That’s a happy place. But conversely, you’ve got teams out there who are doing, you know, really fast paced user experience and great, uh, user experience in say, mobile applications. Did the te they could do that in Python, absolutely. But it may well be that there are other languages better suited to that or that have better integrations with the applications that you want to hook into or work better for the frameworks and the front end that you want to use.

(10:13):

So that flexibility’s really important. Now, don’t get me wrong, we’ll probably come back to it. There’s a chaos inherent with what I’ve just said, <laugh>, because I’ve just told you, you’re gonna go from being a Java shop or whatever you are now to anything goes as long as the codes gets written. And that will give at least some of your audience palpitations. But, um, there are benefits to be able to do that. It’s really hard if you’re shoehorned into just, we are at this company and we write in this language and this framework of this version that can limit your options.

John Verry  (10:42):

Mm-hmm. <affirmative>, let me ask a question. So I know you said that, um, maintaining code, you know, is, is a little bit simpler. Maybe understanding code is a little bit simpler. How about understanding the flow through an application? Right. So if I’m in a monolithic application, you know, I, I, you know, I can, I can watch as this application processes if I’m in a debugger, you know, I can see how things are branching, where things are jumping to, you know, functions, other functions and coming back and how they’re returning it. You know, is it challenging in a microservices architecture because they’re all discreet to kind of know how, how that flow actually occurs. You know, cuz there’s gotta be an equivalent flow if the two apps do the same things, right?

Laura Bell Main (11:24):

Yeah, absolutely. Now monitoring and logging tools have come a long, long way now and so have our, our dvo analysis tools. So there are a lot of tools now that can help with this, but mm-hmm. <affirmative>, I think you are touching on quite an important, uh, part of where microservices can come a little unstuck or become a little bit more challenging. Now, if you’re an organization, you’ve got 10 microservices, fantastic. You can probably chart all of the maps between them. Fantastic. Good. All pathways are open. But the second you get to the scale of, you know, let’s use Netflix for example, because they’re a very public proponent of microservice architectures. They’ve done lots of talking about them publicly. Um, and you’re talking about thousands of microservices, now you’re talking a scale that gets quite difficult. Now there’s probably an argument here for, well at that kind of scale, your monolith is gonna be fairly complex as well.

(12:16):

Um, but I think what’s different is in a monolith, you would tend to be able to look in one place. So this is where I code, this is where it’s all put together. This is fine in a microservice architecture because we’re inherently embracing other technologies too. Normally containerization, normally we’re embracing a lot of the sub-components in cloud architectures. Not just, you know, our old e c two instances, which were essentially a Linux box in address. Um, we, we’ve got a lot more components to play with and a lot to keep in our head at once. Now, if any of your audience have been architects before and someone said, have you got an architecture diagram that was straightforward ish? If you had a big monolith, least hopefully you could get it onto one side of a piece of paper. But with a microservice, this could be vast, it could be complex. So, um, being able to keep and rationalize that in your head, fail to map it out and understand the connectivity between it can be challenging. Um, and I think there’s definitely an increased importance on the role of an architect when you are embracing these things.

John Verry  (13:17):

Gotcha. Another question for you. Um, do microservices architectures by their nature either tend to be used more frequently, like with other, more public microservices or microservices that are developed outside of your organization?

Laura Bell Main (13:34):

I think it’s, it’s a bit of everything right now. Um, okay. I I like to call it the, the messy middle ground that we’re in. Um, it, it’s chaos. Many organizations who are focused on a more microservice approach are decomposing their system into components and as components talk to each other via APIs mm-hmm. <affirmative>. Um, and it is very typical in those environments for them also to have integrations with third party providers. It could be partners or integrations, it could be SaaS products. And so there is definitely, um, a lot of inter-operability or interconnection between different trust areas, whether outside your network or inside the fundamental technologies remain the same though, um, you know, you wouldn’t change much of the microservice itself to talk to an external player. You would just change the controls that were around it. So I think we’re, for me, it’s an exciting time as a software engineer because historically we’ve all felt quite isolated from each other.

(14:31):

Um, you know, I built my software, it’s inside my network. I feel quite kind of contained and, and, uh, alone, but in a good way. But now we really can’t, in most circumstances say that we can. We operate like that. Um, we, all of our systems are connected to each other, whether it’s, you know, we’re sending data to a third party integration or a partner or a customer. Um, we really are now a connected ecosystem of tooling. And I think that’s sort of fundamental shift for understanding the risk of your software. Now, there is no border, there is no one place where you can just put your controls and say, yep, we’re done. Now we have true dynamic interconnectivity between organizations big and small. And while we can do due diligence and think about the risk of that in advance, that doesn’t solve the problem of how we manage that risk ongoing.

John Verry  (15:23):

Mm-hmm. <affirmative>. Yeah. Cuz I mean, you could be making a call to a microservice that’s making a call to another microservice that’s making, you know, so this chaining this, you know, supply chain risk management concept, uh, definitively comes into play here, right?

Laura Bell Main (15:35):

Uh, absolutely. And, and I think that’s why we’re seeing it echoed through the, the guidance coming out of csa. Uh, the executive orders from President Biden, um, that software supply chain thing, um, that we’ve been kind of, I think we’ve been tangently aware of for a while, but we’re now really starting to realize the impact of it. So when we see a vulnerability come out with a piece of software over here, and then we realize that by two three hops actually this 50,000 organizations connected to that one floor, that’s huge. And that means that the ripple effect, the impact, if there is something bad happen, is something we have to work together to really manage and understand.

John Verry  (16:13):

Yeah. I mean, think about log for j I mean, how many, how many organizations were, you know, by that one library having that issue. So yeah.

Laura Bell Main (16:20):

And we still see bits of it now because checking out and understanding your supply chain, understanding your dependencies is a huge ongoing, very fast e evolving place. So sometimes you’ll end up with old vulnerabilities coming back again because you’ve inherited something and they haven’t been aware. So it’s tricky.

John Verry  (16:36):

Yeah. So that’s actually interesting when you talk about supply chain risk management, you know, the president’s executive order in this 800, 2 18 address that through, um, an sbam, right? Yeah. A software bill of materials, but a software bill of materials is going to tell me about the, the, the composition of the software and whether or not any of the libraries that are being used right. Have issues associated with them mm-hmm. <affirmative>. But is there an equivalent or, or should we be talking about an equivalent for this chaining of, you know, APIs, this chaining of, of microservices, uh, you know, because my microservice might be reliant upon microservices that I’m not aware of, that are provided by a third party.

Laura Bell Main (17:21):

Yeah. And this is where it gets very, very tricky. The, the software bill materials element, you know, this, this is a good framework and it’s something we’ve used in food manufacturing and in building for a very, very long time. You would never, ever, um, look at a manufactured physical good and not be able to see what it is manufactured from in terms of the parts and components. However, in our ecosystem, in software, we’ve got a different problem because not all of the manufacturers of code are equally mature or have the same level of resources. So whereas you as say, a national level bank might have, you know, a really well defined sbu, you’ve got, you’ve mapped out all your dependencies, the dependencies of your dependencies, those transitive dependencies that you inherit, that might be an open source project somewhere. Now, that’s not to say it is a bad thing to use open source, not at all that some of those libraries and frameworks are underpinning the internet at the moment.

(18:15):

But we have to be mindful that just because we list them on our thing, just because they’re in the sbo it doesn’t mean that they have the same approach that we do. And so as part of compiling the sbo, there’s almost a, an implied responsibility on us as organizations to then look at those components and go, right, which of these that we absolutely are reliant on need a little bit of extra help, and what support is there some kind of, can we provide funding to an open source project to help them up their game? Can we, you know, support them in some way? Um, because if we don’t do that, having the list won’t necessarily help us protect from vulnerabilities. It would just help us know what to watch for on the monitoring lists.

John Verry  (18:58):

Right. Um, so before you, you, uh, you said that, well, let me ask the question this way. I think a lot of people are confused, including mead to some level, uh, about a microservices versus an api. And I think a lot of people kind of see them as being analogous, but they’re not. Can you, can you give a, an easy description for people to understand about what’s the difference between a microservice and api?

Laura Bell Main (19:22):

No pressure, John. Like, it, it’s 9:00 AM here, John <laugh>. This,

John Verry  (19:25):

This, this is just mean, but we’re gonna give a shot. We need to take a break for you to get your second cup of coffee.

Laura Bell Main (19:29):

Oh, no, I’ll, I’ll shake it off. We’ll be good. Right. Okay. Let’s get, let, I’ll, I’ll jump into a really tangible, normal non-technology and we’ll take it from there. Okay. So think about your microservices as a house. You can design a piece of software, like you can die in the house in different dimensions. You can have a giant big house with like 27 rooms and, you know, a pool and a tennis court, fancy house right the way down to a teeny tiny, teeny tiny house. You know, the type you see on those little documentaries where they’ve got one room and, you know, no facilities at all. Think of your Microsoft as a tiny house. It’s just a very well defined functional item that gets a job done. Now, an API is a feature, if you will, of a piece of software. It is a way of exposing code to another development team, whether it is internal or external, via another programmatic interface where they can connect with and talk to it.

(20:22):

So think of it like installing a window in your tiny house. You’re saying, I’m gonna let air in and out of my tiny house via this one window. You don’t have to have windows in your tiny house, you can just have a little house. It can just do a job. You could, you know, take an import file that somebody sends you from a user interface, process it and store it in a database. That could be your microservices job in the world. But many microservices will have APIs because they would connect with other microservices to get jobs done. So where a job falls outside of what they do day to day, they expose an a p i so that they can talk to another component that does that job and can integrate and work with them.

John Verry  (21:01):

Okay. So the microservices is the function and the a p i is how we access it.

Laura Bell Main (21:06):

Yeah. And it doesn’t have to be in the form of an api, so, okay. Um, it’s very common now, but it’s not the only way to do it.

John Verry  (21:14):

What would be just a, what would be another way for a microservice to expose its capabilities?

Laura Bell Main (21:21):

So, um, it depends on how it’s being consumed. If you looked at, for example, shipping and logistics companies mm-hmm. <affirmative>, there’s a lot of microservices and APIs just springing up now. But actually underneath most of that, there’s a lot of edi, there’s a lot of electronic data exchange where they’re dumping files and directories between places. There’s a lot of really awful old processing of old file formats going on in there. And so your microservices job might just be to monitor a little thing, the little file store and say, Hey, there’s a file. Come in, I’m gonna go do my thing now. Mm-hmm. <affirmative>. Um, so it really is about the size and, and encapsulation of some functionality rather than the mechanisms it chooses to get that job done. That’s a separate affair.

John Verry  (22:03):

Okay. That was good. Thank you. Um, so it’s cool that you are a developer and a security person cuz my next question tends perfectly to that. So, um, how does a microservice architecture change the idea of securing an application? Right? It’s, you know, you think about a monolithic application and we think about things like web application firewalls, and we talk, we think about doing o os, bay svs testing of the, of the, of the, of the, the monolithic application. How do we do the same thing with dozens and hundreds of little microservices running all over the place?

Laura Bell Main (22:43):

So the, there’s a couple of sizes, I’ll kind of unpick it a little bit. So firstly, many of the same tools that you are using on your monolith work in your microservice, okay. So you can still apply the same control. So as v s the application security verification standard you mentioned is a really great framework for saying, Hey, what kind of design here have we got going on here? What kind of functionality do we have? What are the expected standards? And they can still apply to a microservice just as they could to a monolith. But the biggest change is a change in where your external exposed borders are. So if you are used to having a single application, say for example, you know, a banking app and it’s all in one big Java application for want of a better language at this point, given the age of those banks, that’s pretty standard language set now in terms of looking for all of the ways in and out of that and the places you could then put a control, like a web application firewall, it’s relatively straightforward because it was containerized, it was containerization for, it was containerization, it was just in one big box.

(23:48):

It was on one or more surface, but there was a boundary. Now this goes back to our old school thinking even, you know, take it back to the physical world and think about a castle. Our old school applications were the nice juicy bit inside the wall of the castle. And all of our defenses were planned around a single static border that we understood. So that’s where we would put them with our microservices as well as decomposing the system into separate components which we could host ourselves. We’ve often spread them around the cloud. So we’ve probably got some elements up in various cloud platforms. We’ve got them in, hosted in different locations. We have some that are connected externally, say through, um, to a mobile application or to a remote user experience. And we’ve got some that are purely internal facing, but instead of it looking like a box with our interesting bits in the middle, we’ve now got a graph, if you will, nodes and edges, lots of little things connecting to each other and sending traffic between them. And so planning where to put your controls and defenses is a different thing. Instead of having one big defense around the outside, you’re looking at the different trust zones inside of a much more complex network. For those of you with a networking background, this should sound familiar. Yeah. It’s,

John Verry  (24:57):

It’s, I was sitting here thinking the same thing we’re going through in the networking, right? I mean, we’ve gone, it’s exactly that. We’ve gone to a distributed, you know, like we no longer have, we no longer have network boundaries, right? We’ve got endpoints sitting everywhere mm-hmm. <affirmative>. So it almost, it it sounds like a perfect analog almost.

Laura Bell Main (25:12):

It is. And I think one of the things that we do poorly in application security is bringing the reference points closer to things that we’ve already seen before or are experiencing elsewhere in security. Um, security in app in applications is not unique. It is part of software quality. Um, and it shares many comparisons with other bits of security. We just have to kind of speak each other’s language a bit so that we can understand where those challenges are.

John Verry  (25:37):

So, so gi given that we’re seeing a big movement towards, you know, quote unquote zero trust architectures, uh, you know, in that network and maybe monolithic application world, uh, are we having, are you guys having the same conversations with regards to microservices architectures?

Laura Bell Main (25:54):

We are and we aren’t. So I’ll talk the wa to the aunt first. Um, we, um, and forgive me the audience, don’t be offended by this. Inside my little company, we have a little zero trust swagger. So it’s a really misused term at the moment. Oh, absolutely. There’s a lot of, oh, it’s, it’s, we are pe

John Verry  (26:12):

It’s not a, it’s not a product. It’s a, it’s an idea. No

Laura Bell Main (26:15):

E exactly. And, and that’s great. And there are some really good documentation even from the US defense base. There’s some really,

John Verry  (26:21):

Well, she started come out with some better

Laura Bell Main (26:22):

Stuff there. Exactly. But there’s a lot of hype. So if we kind of kind of step back from that a little bit, um, I think what we’re trying to say instead of using framing like zero trust, is that we’re trying to put our guardrails in place in our applications such that we don’t implicitly trust and that we verify everything. And that verification is just built into how we do our connections. Now in software, we talk about contracts between components. So yeah, two microservices A and B, and they want to talk to each other. They form through the, the relationships of calling each other’s APIs a form of contract. And we have an understanding that I’m gonna send you this kind of thing and you are gonna send me this kind of thing, and this is what it’s gonna look like. Now, we don’t want to just expect that that contract is met each time.

(27:13):

We want to make sure that it’s met. We also don’t want to, um, expect that, well, if my traffic is coming from inside the network, then it must be fine and trusted. We wanna make sure that every single contract is checked every single time. And so that’s not a laborious thing. It sounds like a lot of work. It’s really not. It’s just making sure that we can wrap our connections in things like middleware or in some language they call ’em interceptors. The idea that when a connection goes between two things and something is called, it does some automatic checks each time. So in software, what, rather than going into the zero trust, we’re just making sure every single request between every single service has the right checks on it. And those checks are our things like authentication, authorization. In some places we’re getting into a, uh, attribute driven, um, authorization mm-hmm. <affirmative>. But mostly it’s those basics that we expect to be happening, but sometimes we trust too, implicitly

John Verry  (28:07):

Mm-hmm. <affirmative>. So it, it definitely sounds like the fundamental principles of zero trust architecture, the way that you’re talking about. Yeah. It makes sense. Um, so one of the other things which puzzles me a little bit, and it’s interesting. So when, when you see microservices architectures, there’s two things that you see and I I can never Yeah. You’ll see sometimes tables between the two of them, right? So we have the concept of using an API gateway mm-hmm. <affirmative>, and then we’ve got this, I think it’s a newer more, uh, evolving, uh, uh, that feels a little bit like quantum super computing to me. <laugh> as super positioning, excuse me. Uh, you know, the service mesh mm-hmm. <affirmative>. So can you talk a little bit about, you know, API gateways, what they are and how does that, how is that comparable or not comparable to a service mesh? And does a, does an a service mesh and an API gateway work together? Or are they more, um, differentiated as,

Laura Bell Main (29:01):

Okay, cool. Well, there’s a lot to unpack here. So let’s start at the top again. Mm-hmm. <affirmative>. So API gateway, a single point of access to, uh, APIs. Now, if you’re building dozens of microservices that happen to connect to say, um, a mobile application. So your customers have installed a mobile app on their device, and that device then talks to your APIs as part of its process. Mm-hmm. <affirmative>, you do not wanna expose every one of those endpoints externally. That’s a lot of work and a lot of protection. So like most networking security, we put it down to a single entrance and an exit point or API gateway. So

John Verry  (29:35):

It’s an api, it’s a proxy, effectively,

Laura Bell Main (29:37):

It, it is essentially that. But with, we have some added functionality that’s been built on top to centralize some components. So some API gateways can take care of authorization, for example mm-hmm. <affirmative>, um, they can have rudimentary logging, um, and monitoring built into them. And that can help simplify some of the shared requirements your microservices might have. Because one of the things we haven’t spoken about is we’ve got this tightly defined little microservice that does three jobs, a, B, and Z. But then there’s all these other shared things it needs to do, like logging and monitoring and authorization authentication. And so you don’t necessarily want to bundle that all into the little module. That’s way too much. And so it gives you a shared point at which to do some of those things in certain circumstances. Now it does, uh, I’ll come back to it.

(30:23):

Change the risk a little bit because if you’re an attacker, right? And you want to get into, um, the company’s, you know, shiny treasure chest, if you will, in the middle of that application, then you’ve got now one piece that controls a massive scope of the external presence of your applications. That API gateway becomes very powerful in terms of an attacker. Um, as an attacker, I’m not gonna bother if attacking your tiny, tiny microservices, if I can get a foothold in that API gateway, then my life is golden. I, I control the access to everything that’s behind it. So it’s a very powerful, uh, thing that we have to protect very carefully. The difference, therefore with the, the service mesh. So service mesh is, is solving that problem of those shared components I just mentioned. So the bits you need for your apps to work, but you don’t wanna bundle into microservice so that you’re logging in your monitoring and all of those kind of things.

(31:18):

And you can build what in some frameworks is called a sidecar. It’s a like a little tiny add-on that you put into your microservice that says, okay, I’m now one of the microservice crew and anyone who has this little sidecar is going to in inherit all of the services provided by the service mesh. So this is kind of like your plumbing and shared facilities. Your little microservice is doing its job. It’s got its little sidecar that gets you access to the service mesh, which does its communications between other microservices, logging, monitoring, all of those kinds of things. Um, now that typically would live within, inside your architecture, it’s unlikely you would expose that externally. Sometimes you can have an API gateway and service mesh mangled into one, but mostly you’d keep them separate. So one is about protecting your in, uh, in, in and out from your network and, um, keeping that single point. That’s your API gateway. And one is about shared services that traditionally you would just host internally inside, uh, your trust network, whether that’s in your own natural local network or not, is by the buy, but inside that defined, trusted area.

John Verry  (32:24):

But it does sound like where they kind of overlap a little bit is that they, the API gateway and or the service mesh might provide some of those shared services.

Laura Bell Main (32:32):

Yeah. And the key difference is that in a service mesh, a service mesh will or dynamically update when it figures out there’s a new sidecar in the mix. So if you’ve got a new microservices, oh, that’s kind of cool, and you add the service mesh to it, the service mesh will go, oh, new person. Hey, welcome friend. So it’s

John Verry  (32:45):

Sort of

Laura Bell Main (32:46):

Way goes, I dunno what you are.

John Verry  (32:47):

Right. Sort as as it spins up itself, registers with the service desk. Exactly. Okay. So the service, the service mesh is a sort of a management and, uh, shared services overlay Yeah. To a microservices architecture.

Laura Bell Main (33:04):

Exactly that. Oh, that’s

John Verry  (33:05):

Pretty cool. That’s shared common services. Thank you. I I, I actually almost understand it, which is a lot further than I was before I got here today, <laugh>. Um, so you’ve been awesome. Um, did we miss anything in terms of like, you know, like you, you speak every day and you speak to everyone from developers and security people down to business people. So like, what are the questions that I didn’t ask that I should have asked, if any?

Laura Bell Main (33:32):

I think the important part is understanding this is really great, but the trick for us as security people is how we then put security inside it, right? How do we support that becoming a more secure thing? And I would kind of is, is worth having a think about in, uh, for your audience that, um, when you are putting a security control in these architectures are now very dynamic. They’re very fast moving. So things for, you know, how long does it take for messages to get through my network? What’s the performance and scaling of that? How many requests per second can I handle? These are all very pertinent questions to a development team right now, especially if they’re decomposing into services. So if you’re doing that, if you are trying to propose putting a security control in, please remember that the operating space that you’re putting into may not be the same as it would’ve been 10 years ago.

(34:30):

And so when we’re doing our analysis, is this the right tool or is this the right approach? You need to be asking and working very closely with your development teams and asking, well, what’s the impact if I put this in? What are the metrics that you are measuring that say, Hey, we’re doing this well versus, um, what are they gonna be after we’ve done this change? Because what we see is occasionally a security folk were like, Hey, we wanna protect you and we give you this shiny new device that’s gonna save the world, whether it’s a source code analysis tool or a monitoring and logging tool. But if that’s gonna slow things down, if it’s going to interrupt the, the connections between services, if it’s gonna get in the way of the performance and scaling of what they’ve built, it’s gonna be very, very difficult for them to keep in place.

(35:12):

So go and work alongside, go and listen to your, your engineering teams and really understand for every change you wanna make, be clear with the what am I trying to achieve with this? What’s the outcome? What’s the benefit for security? And then try and understand what the impacts would be in their world and find that middle ground. Because if we don’t come closer together to plan those controls, our architecture and software development is only gonna get faster and more demanding. And it’s already difficult for us to keep track of that and provide responsive and appropriate control. So get stuck in there. Don’t be afraid. There’s no silly questions. In fact, most dev teams will really enjoy being listened to and, and explaining what they’ve built. They’re normally very, very proud of it. Um, so go work with them, um, yeah. And see how you can di dynamically secure that.

John Verry  (35:59):

Yeah. The the, the problem is that, you know, please don’t take this the wrong way. I mean, this is a compliment, but that’s a hell of a lot easier for you because you speak both languages. You know, someone like myself, I mean, I did application development, you know, a long, long time ago. It was visual basic six. I mean, probably the last time I wrote code. So it gives you an idea how long ago, that’s when visual interd dev was still in beta, I was writing code. So, you know, yet that’s how far by active server pages. Gosh. Um, so the, the problem I think we all have as, as security folks is that, um, it’s hard. Like, it’s hard to get to a point where we’re speaking a common lingua. And I think that’s where, I think that’s where we struggle. Um, you know, I know, like I, I was thrilled to have this conversation because I know that I wouldn’t, I wouldn’t be able to even remotely hold the conversation with the developer, you know, talking about microservices architectures and API gateways and the service mesh. I mean, now I’ve got a fighting chance. Um, but I, I do think that’s the challenge. I think you live in a privileged world. Cause cause you wear both hat so well.

Laura Bell Main (37:00):

But, so, you know, there’s one thing I’d love to call out a little bit is the idea that you have to know what the model languages are. My first language was cobal. Mm-hmm. <affirmative>. Um, I get thrown into an environment probably every two or three weeks with a completely new language there, with a new, you know, somebody’s doing something new and novel. And a lot of what helps me get through that is coming to it with some foundations, which, you know, we already have. Or even if they’re rusty and just asking good questions and listening and being okay with the idea that I don’t know mm-hmm. <affirmative>. Um, and you know, I think on both sides, I know security folk we can be sometimes difficult to connect with too. Mm-hmm. <affirmative>, you know, because our, our incentives that our world is differently aligned with development. So maybe I’m just a dreamer, but I’ll, I’ll live with that. But I would love to see a time where we can come a little bit closer together because I think to help solve a few things,

John Verry  (37:56):

You’re not a dreamer, you’re a pragmatist. Because if we don’t do it, you know, like, I mean that’s one of the reasons why, you know, software, you know, still, you know, why every day there’s a breach, right? Because people, people don’t write secure software. And that’s just

Laura Bell Main (38:10):

Yeah. And why the O top 10 has barely changed in

John Verry  (38:11):

15 years. It isn’t. Yeah. It, it’s insane that injection is <laugh> has been <laugh>, you know, the first of the OWA top 10 for 13 years or something crazy like that. So I couldn’t agree with you. I couldn’t agree with you more. So, so let me ask you a question. So, so you’re, you’re, you, you are obviously a, a wonderful, um, educator. You, you were able to take complex topics and speak to them pretty simply. Um, safest stack. Uh, I was looking at some of the stuff that you guys are doing. Uh, talk a little bit about what you’re trying to accomplish at Safest Stack with, with your education programs and, and just let people know, like I, you know, I, I know you’ve got some, what looks like phenomenal stuff out there that people can access at little at no cost.

Laura Bell Main (38:52):

Yeah, absolutely. So we’re an education platform. Um, we started about two and a half years ago. Um, myself and my co-founder Erica, and before that we’d been the virtual CISOs for dozens of high growth companies all around the world. And our job was to, um, some of them even called us Mary Poppins. But our job was to come in and to bridge the chaos between what was very fast paced, software development and security so that we could weave security through without getting in the way. And as consultants, that’s, that’s fine. But what frustrated us was we could see amazing technology being built everywhere, not just by companies with budget. And so we wanted to be able to teach how we think about software security, um, and all of the practical steps you can take from having an idea or no code all the way through its life, um, in a way that organizations big and small can use it.

(39:42):

So we have organizations we work with that are two people out of New York doing non-profit stuff all the way through to banks and airlines. Um, we teach their developers, their testers, analysts, architects, all of those roles involved with software where security fits into their world, how to do threat assessment and modeling security for things like microservice architectures. Um, and we deliver new content every month. So it’s a very interactive kind of community approach to saying, Hey, there’s 30 million software developers in the world right now. Wouldn’t it be cool if all of us were a little bit more security minded? And we built this in by default, so we have a free plan so your audience can get stuck in no strings, no gimmicks. I get to say that as ceo, that’s my promise. And there’s essential training there that you can train up to 50 engineers free of charge.

(40:31):

Um, and that will cover your, you know, your basics of your O osp and how to think about, uh, security as a software tester. And then for our larger organizations, we have learning pathways and experiences in there that you can, whatever your team is building, however old the code, however new and shiny, they can kind of come a bit closer to our world. Um, so we’re in about 1400 organizations now. Wow. In 76 countries. Um, and we we’re super excited to be working with, you know, everyone from folks doing technology in eSports through to giant banks, to, we’ve got a company who’s helping diagnose cancer through ai. So it’s a really powerful way to view security. We see security AppSec in particular as, have you ever John inherited a cookbook or recipe book from a family member mm-hmm. <affirmative> and it’s kind of old and gray and you’re kind of looking down the pages and somewhere down the cake recipe, there’s a scribbled out bit and that says, do not do this.

(41:28):

Add sugar <laugh>. And you have no idea who wrote that and why, but you know that the cake at the end of that is going to be really amazing because you’ve had that cake before. Now that’s what AppSec is to us. We are not the recipe, we are not the, the digital cathedral that are being built. We are there to be the best supporting cast in an inobtrusive way to make sure that security is woven in through every time we build one of those things. So yeah, people can check us out [email protected], um, sign up to the free plan, um, and come and have a chat with us. We’d love to see how it works in your world because there is some incredible technology being built all over the place. Um, and we’re just excited to meet them all.

John Verry  (42:07):

So I love your analogy about the, about my wife is a, a phenomenal cook. And, uh, she, her, uh, tomato sauce, you know, meatballs and sauce recipes from her great great grandmother. It’s a hundred plus years old and she has a copy of it. And like, you can see, you know, like when the cans of tomatoes went from 35 ounces to 28 ounce, like, you know, and the, when the size of the bread, you know, so that, that recipe has, you know, I don’t know how my wife deciphers it anymore. I mean, she probably just makes it without even looking at it anymore. But, but anyway. So I, I can’t agree with you more. That’s a, that’s a great analogy. Uh, alright, give me a, uh, fictional character or a real world person you think would make an amazing or horrible ciso and why?

Laura Bell Main (42:51):

Oh, a fictional character Or real world now? Or real world? Well, if I pick someone in the real world, you

John Verry  (42:57):

Could pick yourself. You could pick yourself. Cuz you were the virtual CISO for all these different

Laura Bell Main (43:01):

I I have been the ciso. There you go. I’m the CISO that you call when everything is going wrong, <laugh>. Um, uh, so yeah, I’m, I’m a chaos monkey ciso. You, you want me for certain ages and stages, but not for when you are, you know, 500 people. But I think, you know, fictional characters. Do you know what, and it’s gonna seem really twe but I’ve been watching The Coronation a lot this week. Cause I live with an 80 year old and she really loves the Royal family. But I’m gonna say Paddington <laugh>, which is a really weird answer, but nevermind. Do you know why Paddington always has Marlay sandwich with him? He’s always prepared for emergencies and incident response is key. And also he is a people focused bear. He’s all about connection and how he can resolve situations with relationships and creative problem solving. So all of your audience just devalued everything I said in this episode based on that little analogy, but that’s okay. I can love with

John Verry  (43:52):

That. Well, I think, I think most of the people are running to figure out who Paddington The Bear is. <laugh>.

Laura Bell Main (43:57):

Oh, now they’re onto a wonderful adventure. You should check out the movies folks. It’s, um, as a mother of two children, they, they get me through the dark times.

John Verry  (44:04):

I’m trying to think of, there was a, a movie that I watched on Netflix or Amazon about it. It, it takes all place in New Zealand and it’s about a little boy who, uh, gets adopted by a family. He’s a, you know, a police. He gives a foster child mm-hmm. <affirmative>. And he, and he take, he and the, and the father take it on the lamb and are chased through the New Zealand

Laura Bell Main (44:29):

Outback, the hunt for the wind of Wilder people.

John Verry  (44:31):

That is, that is such a phenomenal movie.

Laura Bell Main (44:34):

It is a fantastic movie.

John Verry  (44:36):

I mean, it’s, it, it’s the, the cinematography is amazing. It makes, it made me want to go to New Zealand. Like just, just to experience it, but also just the whole story is just charming.

Laura Bell Main (44:46):

Yeah. We, we have an interesting mindset in New New Zealand. We don’t naturally have any predators, um, uh, never have done. So, you know, our birds don’t fly and our frogs don’t become tadpoles. Um, and what happens when you’re in a very safe environment with not many predators is you have this really interesting dynamic of what can be achieved. And, and it translates into everything. Our art, our culture, our movies. Um, and so the storytelling is always really very beautiful. And Tyco wa Titi who, um, has, you know, now gone on to Marvel movies and the big Hollywood thing, uh, a lot of his early movies and things like Whale Rider.

John Verry  (45:24):

Is that the Boy? Is that The Boy

Laura Bell Main (45:25):

Boy is one of them. Yeah.

John Verry  (45:27):

One. No, no, no. I’m sorry. Is that the boy in the movie that you’re talking about? That

Laura Bell Main (45:29):

Ty No. Tako y Titi, he does, uh, does Star in some of his own movies, but he’s very much a, a full grown adult. Oh, okay. Um, but the, the, the young, uh, lad who’s in hunt for the world of people is also excellent.

John Verry  (45:40):

Oh my God. The, the, the, the, the acting, everything about that was, it was one of those movies that it was like, I, I read about it and it was like quirky and I’m like, gotta give it a try and just fell in love with it. Absolutely. Yeah. So,

Laura Bell Main (45:51):

Well there we go. Something for our audience to do when they’re not pondering microservices. Get in some Kiwi

John Verry  (45:55):

Movies, <laugh>. Exactly. Um, alright, if folks want to get in touch with you, what’s the easiest way to do that?

Laura Bell Main (46:02):

Right. So you can find out about the [email protected]. Um, you can reach me on LinkedIn, Laura Bellman. Um, and on the Twitter, uh, at Lady underscore nerd, um, the underscore is important. The other lady nerd doesn’t know what security is and she, she’s not gonna be able to help you much <laugh>. Um, and also I’m, I’m at a few conferences this year, so render ATL in Atlanta, uh, in a few weeks time. Strange Loop in St. Louis, andcan in San Francisco later in the year. So if you do see me around the place, come and say hello. Um, I love connecting to new folk.

John Verry  (46:33):

Awesome. This has been fun. Thank you so much. I I really appreciate you educating me up a little bit. I feel a little bit better about myself after this call than I did before.

Laura Bell Main (46:42):

Phew,

John Verry  (46:43):

<laugh> mission accomplished.

Laura Bell Main (46:45):

Yeah, absolutely. Thanks for having me.