Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Podcasts Cyber Security with Maxime Lamothe-Brassard

Cyber Security with Maxime Lamothe-Brassard


On this episode of the InfoQ Podcast, Thomas Betts talks with Maxime Lamothe-Brassard about cybersecurity. Understanding security is very similar to understanding software architecture, with general concepts applicable to everyone, and specific needs that depend on your situation. The discussion covers roles and responsibilities, DevSecOps, and the current and future state of cloud-native security.

Key Takeaways

  • Cybersecurity has many similarities to software architecture, most notably that it depends on your specific situation. Your business, and the type of data you have, will determine what you need to defend against.
  • DevSecOps is a helpful mindset, where your security posture can adapt in the same way your architecture adapts with DevOps.
  • By including security defenses in appropriate ways within a modular architecture, the resulting modular security can benefit the whole system. Like microservices, this brings additional challenges, but can allow your system to scale.
  • Despite many advancements, we still have not determined what defines great cloud security, and the space continues to evolve.
  • While the major cloud providers can handle general security concerns, many providers are helping to fill the gap and provide configurable solutions to meet your specific needs.



Thomas Betts: Hi everyone. Before we start today's podcast, I wanted to tell you about our upcoming QCon software development conferences. We'll be back in person with QCon London, this April 4th through the 6th and online with QCon Plus between May 10th and 20th. These are both great opportunities to learn from the world's most innovative software engineers from across many domains, as they share their real-world implementations of emerging trends and practices. You can learn more about the events at We hope to see you there.

Hello, and thanks for joining us on another episode of InfoQ Podcast. I'm Thomas Betts, one of the co-hosts of the podcast. And today, I'm joined by Maxime Lamothe-Brassard. Maxime started his career in cybersecurity with Canadian Intelligence, then worked with CrowdStrike and Google. In 2018, Max left Google to found LimaCharlie. Maxime, welcome to the InfoQ podcast.

Maxime Lamothe-Brassard: Happy to be here.

Roles and responsibilities for cybersecurity [00:52]

Thomas Betts: I want to start off with your opinion on roles and responsibilities around cybersecurity. We've all heard the cliche that security is everyone's responsibility, but the problem with saying that is, it's almost as useful saying it's no one's responsibility or it's someone else's problem. So our listeners range from software engineers to architects, to technical product managers up to CTOs. What do you see as the major needs for effective cybersecurity? And, how does that work get specifically assigned to individuals and teams and roles?

Maxime Lamothe-Brassard:I think it's the interpretation of that statement that's kind of problematic, right? Like you say, it's everyone's problem. I think the first level and maybe old school a little bit, kind of interpretation might have been that security is a single problem and it's everybody's problem. And, I think that's where the flaw is. Really, what we should be talking about is that security is many, many, many different types of problems and that all those types of problems are the responsibility of different types of people in the organization, right?

The most basic example that I can think of is sort of how we often talk at a very tactical level in cybersecurity, right? To put in really oversimplified terms, you have an antivirus deployed. The very grounded part. But, it's equally important to have kind of the right policies in place around software use and all the security policy space. And obviously, those can't be the responsibility of the same people.

Now, it is my opinion that it should roll up to ultimately one person who is responsible for the big picture within an organization of the application. Kind of that whole space. But, I think that's kind of the critical thing, Yes.

Thomas Betts: I just had this come of my company, the annual OWASP Top 10 review for engineers everyone has to go through. Is something like that a good starting point, or is it enough? And, is it just like, here's one specific example of what you need to know and someone else is going to have a different type of training and different day-to-day responsibilities?

Maxime Lamothe-Brassard: If I understand your question correctly, you're kind of talking about the basics that are kind of well-recognized in the industry, is that enough, right?

Thomas Betts: Yes.

Maxime Lamothe-Brassard:Enough is a very relative thing. It's definitely the starting point. And, I think it's a critical thing in the industry that has to keep going forward, right? One of the things that a big proponent of is that as the IT security industry matures, there is going to be more and more of those best practices. So, as we understand more and more IT, and how security relates to that, we're going to have more and more boiler plate. And, I think that boiler plate is going to come in from organizations like you're mentioning, but also from insurance and things like that.

Is it enough? I think entirely depends on what you're trying to defend. So I would make the argument that, you know what, if you cover 100% of kind of the industry best practices, you're probably ahead of the curve already. So enough is a odd term in a way, right, for that? I think where everything else will matter is really, are you trying to defend against a dentists office around the corner, or are you trying to defend a bank, right? Those are going to be drastically different kind of risk profiles. And obviously, the boiler plate or the depth of that boiler plate is going to be very different.

Understanding DevSecOps [04:15]

Thomas Betts: That all makes sense. So one of the trends we've seen making security more specifically part of the development team is the term DevSecOps. And, in a nutshell, it's saying that the team is responsible for development, security and operations, not just the DevOps model. Does that eliminate the need for dedicated security professionals? Are those people just now embedded with development teams?

Maxime Lamothe-Brassard: Every organization's going to be different. So as always, that's kind of like the base caveat. But, in general, as a general statement, I think it does not replace the need for a security team, but rather it will eat away, in a good way, to kind of some of the traditional concerns that a pure security team would've had. And, the idea is that, again, it comes back a little bit to those best practices, right? But as we have more and more of those, it makes a lot more sense to bake those into the base layer of operations, of everything that goes on as a foundation. And then, I kind of have a slightly alternative version of DevSecOps and the definition in my head, which is that the security team, yes, as part of a traditional set of concerns and things that they should be looking for, but I think that the DevOps flavor also needs to start going through the classic security teams.

Maxime Lamothe-Brassard: And, what I mean by this is, we need to be moving to a space where, if you think of the security posture in the same way as it's an IT architecture, right, in my mind, those are really two analogs. So the security posture is not an analyst having a reminder on every Friday to look at the logs of this and that, and kind of the very firefighting things, but rather the security posture is like an architecture and the changes to that occur in a similar way as we do DevOps, right?

I'll put it in very concrete terms, let's say that we have a security team, and, again, I'm kind of bypassing a whole lot of, kind of a decision making, but there's the desire to go and detect a specific type of behavior within the company, right? Maybe it's people. The classic example given by every UEBA vendor out there, right? Somebody logging in from two different spots on earth at the same time, which is a physical impossibility. There should be a process around the knowledge of having that detection as part of the security posture. Meaning that we should be deploying this detection. However, that's being done, right, whatever the mechanism, in a way that is obvious and controlled and tested, right? Just like, you don't have snowflake servers anymore in IT like this whole concept, right? We try to generalize things.

I think we want to have the same thing as an IT posture so that you can actually go in and prove that we are detecting this thing and we are doing it because of X and it's tested at recurring interval and somebody's responsible for that detection for interpreting it and all of that. So, Yes, it's kind of a more heavy process in a way from a security perspective. But, I think it's also, what's going to bring great knowledge of the security posture and will allow an organization to move forward as a whole with their security rather than kind of always be firefighting and revisiting the same issues.

A modular approach to cybersecurity [07:44]

Thomas Betts: You mentioned that every org will be different and it seems like that's where you go from general statements to specific. And so, oh, we should always defend against these types of general threats, but in our case, because we have a bank and not a dentist's office, we need to go to more specific examples. And, is that where that security posture comes in and says, you're now defining for our needs, this is what's most important, here's how we're going to attack those threats?

Maxime Lamothe-Brassard: Yes, that's absolutely right. And, that is not something that's going to get easier. I don't like to kind of, make these not sad statements, right, but, again, unless you're kind of the dentist's office, right, there's going to be more and more IT into everything that we do. There's going to be more complexity. That means that there's going to be more complexity from a security perspective as well. And, that's why it's really critical to make a very structured approach, very testable approach, and DevOps kind of approach that you layer on top of those best practices.

Thomas Betts: You need to have that follow the modular architecture mindset of every little piece is secured in its own way. And then, the whole system still has a higher level of security.

Maxime Lamothe-Brassard: That's right. And, it's understanding security, right? I think there's kind of a deep down desire, I'm going to say, in IT, to treat security as the thing I buy, this product, to be safe. And, I think there was a time where that was very, very true. And, we're kind of in that progression on that spectrum where it's becoming less and less and less true, but rather we're getting more and more to the point where, because every organization is different because there's so much more IT, the reality is that just like in IT, we kind of had to develop things like the DevOps concepts, right, and the whole lot of industry just practices. The same thing's true for cybersecurity. We have to go and understand what we're doing as security professionals.

Thomas Betts: Yes. I like how that's somewhat changed the tools you're using, but also changed the process you use to adopt those tools and say, here's how we can integrate this better. And, because our company has changed its architecture and changed our team structure, we're now going to have to change where we influence security. And, I think you made a point, it's not getting easier, there's going to be more. Going to microservices, architecture is always cited as a, oh, it's going to solve all our problems. No, it's going to create a lot of small problems. It seems like that applies here that you may have smaller challenges you can solve individually, but you still have lots of challenges to worry about.

Maxime Lamothe-Brassard: That's right. There are new and additional challenges in a way, but like microservices, it is also what allowed you ultimately to scale much bigger, right? And, that scale, that's the part that's just, it's going to go up, it's not going to go down.

Follow an ongoing, risk management approach to cybersecurity [10:19]

Thomas Betts: When I've worked on security projects personally, they've usually followed a pretty typical risk management approach. We come up with a list of possible threats and then plot them on one axis against the probability of occurrence. And, the other axis is the projected impact or cost if that happens. And, since it's impossible to defend against everything, that risk register helps you prioritize your mitigation effort, allows you to calculate more objectively, what are your big threats?

So first, is that a good approach? And two, is it something that you do once and you're done, or is it a revisit on a very regular basis and keep saying these threats have changed, we've mitigated these, these are now the new priority.

Maxime Lamothe-Brassard: That's an absolute requirement nowadays, right? The IT security industry is kind of, fascinating, I think because of its beginnings in very kind of obscure circles. And, I think there's still a lot of folks that think in very black and white terms, but that's becoming harder and harder again, because there's just so much, like you say. Protecting against everything is not going to happen. I kind of sometimes make the joke that, again, I don't know why it always become dentist's office as like this concept of a small shop, right... but, if you're a dentist's office, don't try to protect against the FSB. That's not going to happen. Like, it's just not worth the efforts.

I do think that it's a process that needs to be revisited. But, I think more importantly is that, in my opinion, it's not a process that is done once a year, right? It's not a process that kind of lives as its own separate dimension from everything that's going on. But, rather it's a process that occurs when to kind of put in very generic terms, right, there's a new launch, whatever that means for your organization. There's a new launch or the beginning of a new project to go and evaluate what those criteria are. And, I think the mitigation is a component of that. The risk, like you described it, the mitigation. 

Security bulkheads [12:14]

Maxime Lamothe-Brassard: But, I would also encourage people to kind of layer a concept on this, which is the concept of survival, right?

Meaning sometimes you may not be able to prevent something because that cost is high, but there's very often much lower cost solutions that will ensure that if it does happen, it's not this catastrophic chain reaction failure in the company, but rather you accept that you will lose this part of your infrastructure or whatnot, but it compartmentalized. And, I think that's, again, something that people often kind of forget. They think very tactically, right, I want to protect, mitigate this thing, when really, sometimes, it's an acceptable risk.

Thomas Betts: We're seeing that more with, again, with distributed architecture, you have to defend against some other component that you rely on might not be there. So we come up with patterns like bulkheads and bulkheads are modeled after a ship. You're not going to defend the ship from hitting something, but if it does hit something, it doesn't take down the ship. You're able to seal that off and contain it. And so, those are the steps you can take. And so, that mindset that we're taking with, I want my architecture, my system to stay healthy, isn't just one service went down, it could have been, this one service was attacked, but keep that blast radius minimized.

Maxime Lamothe-Brassard: Absolutely. I think we as in the cybersecurity kind of space have a whole lot to learn and a lot of reasons to look back at IT and the kind of very macroscopic lessons that it has learned from because we're not far behind. In a way we're trying to catch up, right, that's how I see it. There's a lot of new technique in surface and IT's getting developed. People start attacking it. So we're kind of the wave right behind it. The more we can play catch up and get the types of lessons like you're mentioning, right, from microservices, from DevOps, that's going to have a great impact.

Moving to cloud-native cybersecurity [14:05]

Thomas Betts: And then, I think you talked a little bit about this, but I wanted to kind of get into the trend to cloud native computing and how has that changed cybersecurity. Back when we had our own hosted data centers or co-locations, there were physical solutions. I'm going to buy this physical firewall and plug my network through it. And now, I just check a box and go through a few wizards and I have that product as a service and it's software configurable. I never would've physically installed one of those things in a rack as my job, as an engineer, but I've configured a WAF dozens of times. That tends to pull like a shift left, the responsibility of who's going to be doing the work, but also it comes with the, you need to understand it. 

So what are some of the trends you've seen about how we're watching those products and solutions evolve from physical to software solution and then also who's the responsible party for managing it.

Maxime Lamothe-Brassard: Mm-hmm (affirmative). On that topic, there's really two big things that come to mind that I think are kind of fascinating. So one is that we are barely starting to see what that means looking towards the future. What I mean is, we've seen a large shift of, I'm going to say legacy, not in a pejorative way, but just organizations that have brick and mortar that are moving to the cloud and have very specific, unique sets of limitations and implications around architecture and how they protect it and how they go to that move. And, this is a temporal thing, right? It's a temporary phase, but it's also where I think a lot of the effort has been poured into.

As I look toward the future, what we are starting to see more is truly people talk about true cloud native companies. Meaning companies that maybe don't have brick and mortar, they don't have a land. They don't have any of those things. And so, concepts like Google's BeyondCorp and kind of all these long-term concepts are going to be very much tested, right? Battle tested. But, I don't think we've reached that point yet. So for me, that's just a fascinating aspect of what's coming up. I think it's going to be a very different flavor compared to this slow move.

The other aspect that I think is kind of interesting is again, I think we're just starting to see the cloud security movement starting to appear as there's more and more infrastructure. I think security is again behind that adoption curve and it kind of makes sense. You're not going to secure something that doesn't exist yet. But, there's a great underestimation of the implication of going and working with cloud providers.

Thinking of a cloud platform as an operating system [16:40]

Maxime Lamothe-Brassard: I completely forget where this comes from, but I recall hearing about this concept that really stuck with me, which is that the more complex a system becomes, the more it ends up looking like an operating system. And to me, this is crystallized in cloud security because yes, all these things are now managed, but what started with, hey, my cloud provider just gives me a VM and I put my SSH keys, right. We've moved a lot more things through there. All of the IAM concepts, all the networked topology. There's just so much complexity that is kind of hidden a little bit behind the surface that I can't help but feel like that's just the next incarnation of the operating system. We've seen historically, right, malware living on the operating system. So I don't think we've yet seen the true implication or rather the true application of what is great cloud security. That hasn't happened yet. It's more to come. That's kind of everybody's guess in my mind.

Thomas Betts: I like the idea that it's shifting to an OS mindset and that's going from the infrastructure as a service to platform as a service. And now, you're configuring different things and you're relying on that platform being there. And, we keep finding abstraction layers, but every time it's abstracted, you lose a little bit of control. Security is one of those aspects of software that I feel like you have to have enough control, you have to have enough knowledge of what's going on, but if you spend too much time doing that, you're losing your concept of what's your actual business problem you're trying to solve.

If I'm writing the scheduling system for the dentist office, and I'm worried about hackers coming in, what's the right balance to achieve? How do we make it easier for people to still write that software and write that software securely and safely?

Maxime Lamothe-Brassard: But, I think that that complexity or that control is actually already there. In my opinion, the distinction is that in the operating system, right, if we kind of shift our mind to the operating system, we have, I'm going to say, just for simplification, for arguments sake, we have 40 years of learning how to make that trade off that you mentioned between control and understanding what parts are important to secure and how to make it easy so that people aren't spending all their time on that.

Now, if we shift that concept to the cloud, we don't have the same learning. So I think we end up with two poles of attraction. There's people trying to do things the really, really simple way, not touch anything. And then, there's also the like, no, all these controls exist, you can implement them, you can tweak them. And, we haven't found the best way to kind of bridge those two things together. And I think, for me, the perfect example that comes to mind is us talking a few months back with a large cloud integrator and talking about the adoption of a specific product, like a specific dashboard relating to some peripheral aspect of cloud deployment and deploying that in an environment and the official documentation from a large cloud integrator, right. Which you would think, and those are the masters of this platform, they know what they're doing, had their recommendation of create a service account and grant owner to everything.

And so Yes, as a security person, right, I see your reaction is like, oh, that's not great, but having the discussion with them, they understood very well what the issue was. But, the difficulty of bridging those two things was really hard because the person providing the dashboard, they did not want to go and kind of survey all the specific roles that they needed and where, and when, and then the application of those roles was being painful. So, there's a lot more work to be done there. It's security, but it's not active security as in the classical, monitoring the infrastructure for security, it's just leveraging this new operating system in a way.

Thomas Betts: It's something you can't just simplify and say, oh, you just apply this simple case and like, oh, give least trust, least privilege access. Like, well, okay, well, what's one step above that? And, it becomes really easy to turn everything off. It's the, my car doesn't get in an accident if I never drive anywhere. If you don't use the software, you don't write the software, then there's no vulnerabilities. But then, it's not useful. So if you swing from one extreme to the other. At one extreme, you can't use the software because no one has access to it. The other one and has too much control. How do we make it easy to move that slider appropriately to find the sweet spot if this has just enough control and that's built in by default?

Maxime Lamothe-Brassard: That's right. To my knowledge, that's a problem everybody has. Talking to cloud providers themselves, sometimes there's the recommendation on paper. And then, the application and there's a realization that it's just, you can't get there from here.

Tools and techniques [21:34]

Thomas Betts: So what are some of the current tools, or what do you see coming that can help us find... Use that as a specific example, is it static code analysis to go through and say, oh, I can figure out that you are doing this and you haven't specified any security? Are we looking at the API layer? Are we looking at the infrastructure layer? And is it just, I hope that I bought the right thing from the cloud provider, or I had to find a third party to do this, or I outsourced all of my security and brought an external consulting firm to analyze and paid them a lot of money to find any of the vulnerabilities?

Maxime Lamothe-Brassard: I think the answer is yes. Meaning it's not because we've added that part of that complexity that we've removed the other, right? So you mentioned code analysis, it's a perfect example. I mean, it's gotten a lot better. Generally speaking, we're not writing C anymore, right? Like, C microservices. So I think software, app security's gotten a lot better, but it's still definitely a requirement. Things at the architecture level as well, right, sometimes it's not in the code, it's the logical layer. And, as we keep going on up into stack, I think is when we've reached that transition. It's like, if you're looking at the ocean, right, there's different salinity and density in the ocean.

And, I think we kind of cross that from the space that we understand very well, meaning whether it's a microservice or it's a server, I run on-prem, it's still software. All the way into that meaty middle, which is the configuration itself at the cloud provider level. And if you keep going up where we end up is in yet another layer that is sort of new, which is the ability of security teams to reason and adapt with the cloud infrastructure, right? At a very concrete example, we used to live in a world where you could say, I'm going to buy a license for this security product and deploy it on this server and job well done. Like, that was a done thing.

But now, I say, well, there's 5,000 replicas of this server and they're churning every 30 minutes. You have to reason about things completely differently, all the way from patch management, which I think has some fascinating aspects of people no longer patching because they're able to just redeploy. So, very different implications for a security team there as well.

So, yes to all the things that meaty middle in terms of configuration. I know that at least some cloud providers are doing a lot of effort putting out solutions that will kind of help with that, kind of security centers. But realistically, I think cloud providers do what they're best suited at, which is very engineering-centric security posture stuff. And so, there's definitely a lot of products that are popping up to help you kind of tame that complexity in the middle.

Again, and I've just been thinking about this, but I kind of like the analogy of the operating system. And, if we look and try to map the progression of antivirus and operating systems, we may be thinking in an analog way with this configuration stuff where there's a lot of low level capabilities, but people come up with antivirus, like configuration management, make it simple. And then, over time, is when those cloud providers kind of learn and end up having better solutions that then apply for everybody.

Thomas Betts: I think some of us are waiting for the cloud providers to solve the problem. And, I think they can only solve those general problems if you start to look at your specific case. I do like the look at the history of antivirus. I remember my first antivirus, it's hard to download things where they'd send out a disc with the latest monthly or quarterly updates. Like, here are the new virus definition files. And, now we've gotten to a lot more machine learning. We can detect that this file looks corrupted or we're watching the behavior.

And so, going back to that idea of the risk analysis of risk register and looking at it, not just on an annual basis, but I think we get to start throwing things off of that. Like, we don't need to worry about this problem. We still need to recognize there is a problem with, we might have patches out of date, but we have mitigated that by, we can just redeploy the software as opposed to how do we have an instruction manual to how to patch all the servers. Or, what are the scripts I'm going to write? And, someone has to write those scripts. We could just redeploy and it gets the new thing.

So it's going to be interesting to see how, as we get some things more automated and become less of our responsibility, there's also new things that are popping up. Like, it doesn't go away. It's just changing and there'll be more little things.

Focus on the fundamentals [25:58]

Maxime Lamothe-Brassard: Absolutely. And, I think the patching is also interesting because it goes back a little bit in a way to the fundamentals, right? That whole concept does not rely on a vendor. That's what I like about it, is that it relies on a security professional, taking a step back, looking at the whole landscape and saying, is this still an issue? And if it is, how do we best address it for our organization today and do that? I'd like to see cyber security kind of relying more on fundamentals and moving away from the kind of, shiny, here's the box product that gives me security, whatever that is.

Thomas Betts: And, that's a great point to end on. Focus on the fundamentals, move away from just finding a product to solve your needs. So I want to say thanks again to Maxime Lamothe-Brassard for joining me here on the InfoQ podcast.

Maxime Lamothe-Brassard: My pleasure. It was great to be here.

Thomas Betts: And, we hope you'll join us again soon.

About the Author

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p