S07E13 - The Infinite Game Meets Azure Security with Bojan Magušić

Sponsors

Support for this episode of The Modern .NET Show comes from the following sponsors. Please take a moment to learn more about their products and services:

• RJJ Software’s Software Development Services, whether your company is looking to elevate its UK operations or reshape its US strategy, we can provide tailored solutions that exceed expectations.

Please also see the full sponsor message(s) in the episode transcription for more details of their products and services, and offers exclusive to listeners of The Modern .NET Show.

Thank you to the sponsors for supporting the show.

Embedded Player

The Modern .NET Show

S07E13 - The Infinite Game Meets Azure Security with Bojan Magušić

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Summary

In this exclusive podcast episode with renowned security expert Bojan Magušić, author of the highly anticipated book “Azure Security”.

In their discussion, they delve into the importance of public cloud security and how it’s everyone’s responsibility. They also explore the concept of The Infinite Game and its application to security as a whole

Bojan shares his expertise on securing Azure resources, providing actionable tips and best practices for developers, architects, and security professionals alike. From understanding the risks associated with public cloud computing to implementing effective security measures, Bojan covers it all in this informative and insightful interview.

Whether you’re a seasoned security pro or just starting out, this conversation is essential listening for anyone looking to improve their knowledge on securing Azure environments. Don’t miss out on this opportunity to learn from one of the industry’s leading experts

Episode Transcription

I always believe, and this is taking my kind of Microsoft hat off, and I’m sharing my personal view here. I definitely believe regardless of the public cloud provider in question, they’re all part of a bigger ecosystem. And I emphasize the word ecosystem. I believe security as, you know, a problem statement of our time, it’s just so complex that it really can’t be solved by a single company or by a single organization or a single individual. You really need to see like collaboration and cooperation taking place across different sectors, across different public cloud providers.

Welcome friends to The Modern .NET Show; the premier .NET podcast, focusing entirely on the knowledge, tools, and frameworks that all .NET developers should have in their toolbox. We are the go-to podcast for .NET developers worldwide, and I am your host: Jamie “GaProgMan” Taylor.

In this episode, Bojan Magušić joined us to talk about both his new book “Azure Security” but also his work as part of the security team at Azure and his top tips for protecting your digital landscape (aka your apps and services) on the public cloud.

Not only did Bojan and I talk about the security aspects of protecting your public cloud digital landscape, but we also talked about how all the public cloud providers actually work together to ensure that everyone is protected from CVEs and exploits when they are discovered. An application of the Infinite Game, if you will—if you’re not sure what that is, we cover that in the episode, too.

So instead of at times you know thinking of it as a zero-sum game, I definitely believe there is opportunity to kind of expand the ecosystem and partner in meaningful ways where we can share information and share insights and guidance and even skill sets that are going to make us all as an industry and, you know, as clients more secure.

Anyway, without further ado, let’s sit back, open up a terminal, type in dotnet new podcast and we’ll dive into the core of Modern .NET.

Jamie : [0:00] Welcome to the show, Bojan. I know that this is the second time that we’ve tried this. First time we had a bit of a technology failure, so I’m very, very appreciative of you coming back to the show to be able to share your knowledge and expertise with the listeners. So welcome again to the show, but for the listeners, welcome for the first time. It’s really confusing.

Bojan : [0:20] Thank you for having me, Jamie. It’s always a pleasure to join. They usually say third time is a charm, but hopefully we’ll manage to do it right on the second try.

Jamie : [0:29] Absolutely blame the software always blame the software; I’m a software developer that’s what we do, right.

Jamie : [0:34] Awesome. So I guess before we get started then, I wonder would you be able to perhaps talk the listeners through a little bit of who you are, and your expertise, and things like that? Because, obviously, they’ve seen the title of the episode, they’ve got an idea of what we’re going to be talking about; but they may not know… they may want to know a little bit about you, and like maybe the kind of work that you do. Maybe a tiny amount, like, an elevator pitch of your history. We are going to talk about a book that you’ve released recently, but like what can they learn about you, I guess?

Bojan : [1:12] To give folks a sense of, like, a little bit of who I am and what I do: I work as a senior product manager with Microsoft. And the team that I’m part of is very, very tightly integrated with one of our Microsoft security product groups. So I would be the person working with Microsoft’s largest customers, most strategic customers, on typically the most complex and bleeding edge deployments of a part of Microsoft cybersecurity portfolio and part of its security stack. And that also helps me understand a little bit about, you know, what services work well, how do they function in the real world, and it’s giving me a lot of, you know, practical knowledge, some of which I hopefully was able to, you know, instil and translate very, very well in the book that I wrote. So I’ve been, you know, with Microsoft close to the last decade, mostly in the cybersecurity space, and mostly like started with, you know, security at the SaaS level. And then like, it usually goes with cloud computing, I, you know, started with PaaS and later on IaaS, so platform as a service, infrastructure as a service, and have been working mostly with those two cloud computing models for the last three or four years.

Jamie : [2:32] Right. There’s a lot to unpack there. I’d be very interested to dive into pretty much all of that.

Jamie : [2:43] But yeah, we’ll talk about all of that in a moment, but you’ve also got this book out at the moment. You’ve kind of alluded to it already by saying that you hope that you’ve been able to distil some of your experience into the book. So what is the book and what can folks expect from reading it, I guess?

Bojan : [3:02] So the book is called “Azure Security.” It’s published by Manning.

Bojan : [3:06] And when Manning first reached out to me about writing a book with them, I was hugely intrigued because there are a lot of books out there that allow people to understand and individuals who read them, like, “how can I configure this?” or, “how does a specific technology work?” What I however felt was, and I call this a depth of gratitude. In my close to last decade working with Microsoft, I’ve been working along and alongside some really brilliant minds in not just Microsoft security, but cybersecurity in general. And they invested a lot of you know knowledge in me they invested a lot of time in helping me understand you know how to do some things. And deep down I knew I’ll never be able to repay them. That’s why I say, “depth of gratitude.” But what I am committed to do is to pay it forward.

Bojan : [4:01] So when Manning reached out and said, “look. How about we write, like, you want to write a book for us?” I was intrigued because I didn’t want to write any book. I wanted to write the book, which is really the book that I wrote serves as a practical guide. Instead of showing you like Azure security and its many, many services and how to configure like specific portions of each security service, which on its own could be like, I don’t know, 1200, 1500 pages. I wanted to actually do something different.

Bojan : [4:35] Based on my real world experience of helping organizations secure their Azure environments, I wanted to write a recipe of sort; of, you know, instead of diving deeper into all of Azure security and what it has to offer, I wanted to focus on a particular set of services. Which I, in the book, refer to as Azure security, and how those can be implemented it in the real world to help organizations secure their Azure environment. So the book speaks about a subset of Azure security services, as well as practical guidance on how to actually implement it in the real world, all with the hope that organizations, by reading it, are going to be able not just to understand of how it works, but more importantly, what they need to do to configure it so that it works properly.

Jamie : [5:25] That makes total sense, right. Because, like, if I open up the Azure portal and start looking around, and even if I’m just hosting a web app on that, there’s, you know, there is tab there for security, snd you know a whole bunch of features and check boxes and things that I can enable and disable and things like WAF, and things like private networks and stuff like that. But I feel like if you were to try and cover everything that Azure allows you to do, you’d end up writing something that’s maybe multiple volumes, something like The Art of Programming, which is currently on volume 4B. We may not get to volume 5. It may never happen. It’s like the Game of Thrones of programming, right?

Bojan : [6:11] I love that analogy. And it’s something against writing a book like the one that you mentioned. It’s just I felt, I definitely see with organizations, there’s a need to do more with less. They have less resources. They have at times, you know, even less actually time to spend, you know, configuring things. So instead of just saying, like, “let me take a particular service and let me like, you know, show or teach them how to configure everything inside of it.” Some of those things might not actually be as you know effectively used in the real world. So I wanted to say like, “out of these services, these are the things that I believe and that I saw first hand that you should be looking to configure first, because they are the ones that are going to have the biggest positive impact when it comes to overall security of your environment.”

Bojan : [7:03] So at times I compare it to a recipe. And the line of thinking there is: if I give someone a recipe, they can use it to make a dish. That doesn’t mean they need to stick by it blindly, like they might actually add an ingredient or two by themselves. But the majority of the insides and the majority of, you know, the meat is already there. So they can use that to get a head start and to really secure their environment and obviously then later on build upon it.

Jamie : [7:34] I absolutely love that metaphor, I really do. Because from my perspective your security deployment, your security stuff is likely going to be different based on what you require for that particular setup, right. So, for instance, my live application will probably need something like, you know, some form of access control on there; but that access control will likely be weaker than my access control for my dev environment, right. So if all I’m making… I say all… but if all I’m making is a public facing web application that I’m going to allow anyone to access, then the live version is probably going to have slightly different security concerns than the dev one, because I probably don’t want a member of the public accidentally finding the dev version of the the website, right. So I’ll probably have something like IP lockdowns or some kind of, maybe, a rudimentary password system or something like that.

Jamie : [8:39] That will be different to my live site, and I probably want some kind of DNS thing on there, some custom records, and maybe some custom TLS certificates. And so I can imagine that, yeah, the–and I’m talking from a 10 000 foot view level right. I’m not talking about, “what are the nitty-gritty requirements?” So I can imagine that it will be different for… and that’s just the one app right. I can imagine that my app will be hosted differently to say an app that maybe you build, or an app that is internal but needs to, for some reason, live on the cloud right. The the security “playbook,” I guess, will be different for every project. Is that correct?

Bojan : [9:20] It definitely is.

Bojan : [9:21] And Jamie, I believe you captured it so well. It also is one of the things I was actually, kind of thinking and debating internally when I set out to write the book. because you gave such a good example of a web app, that can even its security configurations can differ depending on the type of environment in which it’s deployed; be it you, know dev, or be it prod–like the development or test environment and production. So I, initially, even considered like let me potentially start by writing how to, you know, to secure a web app. But then what I realized, because you have so many different permutations, the book itself could then, you know, seem endless. And it might actually be very unfriendly for someone just to pick it up and get like real value, if you start already going in the nitty gritty. So instead of that, what I decided to do is I honed in on a specific subset of Azure services, and I organize those in chapters.

Bojan : [10:21] So imagine if you already have something like a web application firewall in front of your application or a web app. So chances are, maybe you’re not as interested in that specific part of securing your web app. You might be, to your point, more intrigued about what else can you do that’s going to be effective. And the way I organized and wrote the book in chapters allows someone to see, “okay, maybe if I’m not interested in a chapter about the web application firewall, I can still get a lot of value in some other chapters,” be [it] chapters that speak more around identity and access management, for example, or potential later chapters, which speak around clockwork or protection for the web app or potentially even like having a SIEM.

Jamie : [11:08] Hmm. Yeah. And I think that’s really important to be able to sort of… I’m not suggesting for a moment that readers should pick and choose which part of the book that they read from. But as a, if you wanted to use it as a reference manual, then that kind of fits, right. Rather than, like you said, rather than a journey of, “I will create a web app and we will secure it together. “You know, having a sort of reference manual type of thing where it’s like, “hey you’ve done this step, so have you thought about doing this thing? And if you do, cool; let me show you how to do it.”

Bojan : [11:43] Exactly. And because Azure is so broad and so vast, like, I’m not sure like when folks, like, listening to this started, like , with cloud computing; but I still remember like when I was starting out like there were new services like appearing literally overnight. I still remember, I was actually in a conversation with a client and they were opening their azure portal and they were like, “what’s this service?” And I was like, “I haven’t seen it yet,” you know. It appeared overnight. So and that just goes to show the amount of you know innovation taking place, investments going into the majority of public cloud platforms. So it’s not a matter of them just adding more services, but taking also existing services and either refining them, rebuilding them, adding more capabilities.

Bojan : [12:34] So it really is like an ever-evolving type of a conversation where, even if you approach something from one angle, chances are if the conversation then takes place again in a couple of months’ time, you might need to actually revisit that approach because there might be something else that you missed.

Jamie : [12:53] Absolutely, absolutely. And I think it’s worth remembering, and folks may not know this, we’ve got a point in our episode recording plan to talk about the way that all of the different public cloud providers work together with regards to security. But I have the feeling that if not directly, and I feel like, and I’m not asking for you to answer this, this is just me speaking to the ether, expressing an opinion. I feel like a lot of the innovation in the public cloud provider space is a lot of those providers working together, or at least someone coming up with an idea, and the other cloud providers going, “that’s brilliant. Can we do that? Let’s do that. That’s a really cool idea.”

Bojan : [13:45] Definitely. I always believe, and this is taking my kind of Microsoft hat off, and I’m sharing my personal view here. I definitely believe regardless of the public cloud provider in question, they’re all part of a bigger ecosystem. And I emphasize the word ecosystem. I believe security as, you know, a problem statement of our time, it’s just so complex that it really can’t be solved by a single company or by a single organization or a single individual. You really need to see like collaboration and cooperation taking place across different sectors, across different public cloud providers.

Bojan : [14:30] We could, you know, offer a simplified example of CVEs. Obviously, if I know that something is exploitable, it’s, I believe in my interest to share it also with others, because by doing that, I’m helping them also be, more secure and kind of help them fight back against the cyber bad guys or the threat actors that are looking to actually attack them or exploit the CVE in question and do harm to their environment. So instead of at times you know thinking of it as a zero-sum game, I definitely believe there is opportunity to kind of expand the ecosystem and partner in meaningful ways where we can share information and share insights and guidance and even skill sets that are going to make us all as an industry and, you know, as clients more secure.

Jamie : [15:28] 100%. I agree 100%. There’s this idea of the infinite game, which is instead of playing, imagine that life is a game, right? Instead of playing life as a game as a competitive thing, if we play it where we’re all on the same team we’re all trying to achieve the same goal, then that greatly increases our ability to achieve that goal. Because instead of it being, “me against you,” it’s now, “us working together, and we can combine our skills, our techniques, all the resources we have access to, and we’ll be able to achieve that goal.” Perhaps faster with fewer resources, maybe with requiring fewer people, you know. It greatly increases our ability to actually achieve the goal of, in this instance, securing our applications and services regardless of the cloud platform that we’re using, right?

Bojan : [16:25] I love the example you gave about the infinite game. It’s something I speak about also in the book, so I already see you read the book, Jamie. And this infinite game speaks about a concept around where one shouldn’t really think and approach security as a zero-sum equation or winner-takes-all.

Bojan : [16:47] And that’s a little bit of a challenge I see with having that kind of approaches. And there is really no level playing field, for example, when a nation-state decides to attack an organization. So as you can see, there are no set rules when a nation-state targets an organization, regardless of, you know, the solution or cybersecurity stack that they use. So by not adhering to any, you know, defined rules, this infinite game is something where it’s actually very much about staying in the game rather than, you know, winning or a winner-takes-all type of a game. So by working together and collaborating on security, it should always be like a joint imperative of you know players which are part of this infinite game, because the rules aren’t very clearly defined and it’s going to really take us all working together to make sure that you know we approach security in a meaningful way, and aim to address it. Because unfortunately I believe security is not easy to solve.

Bojan : [17:55] One comparison I’d give it’s like crime. Crime is super difficult to solve and similar with security because you’re always going to have threat actors is how do you then solve it you know how do you solve threat actors not attacking organizations? It’s similar to asking one like, “how do you solve ordinary crime?” And as we all know like in the real world it’s really difficult to do. So it’s also about addressing it and staying in the game and that’s what for me at least this infinite game mindset speaks about.

Jamie : [18:30] I love it. I love it Yeah, because then no matter who plays, we all win, right

Bojan : [18:37] Exactly. We all need to be actually helping one another. It’s not to say that you’re not going to see like across the cyber security space different organizations you know wanting to grow and accelerate their growth by going after you know companies and clients. I’m really not trying to like be naive or paint like you know an unrealistic picture. I’m just trying to say there are some things we shouldn’t look to compromise; like if I know there is a vulnerability on another public cloud providers platform I’m actually not you know happy because if that is used by you know clients they’re you know at risk.

Bojan : [19:18] Or they have a certain risk exposure. So by seeing something happening less well on, let’s say, your adversary side. It shouldn’t actually be seen as the other side being happy; you should really look at, “okay. But how can we all have a very secure foundation that we’ve built that we all can go about you know growing our business?” Because if the other competitor doesn’t have a solid you know foundation and if they’re targeted by threat actors or potentially even a nation state actor it’s really not something I believe to be happy about. It’s similar like to ambulance chasers like you should really think about, ?what am I doing to actually make this foundation that I have more secure and potentially help with guidance around you know how others could do that as well?"

Jamie : [20:08] Yeah. A thousand percent. I can keep saying it, but yeah you’re absolutely right I tend to agree with you a hundred percent, and I guess that leads on to, we’ll come back to a little bit more about the book and a little bit about some of the security things that we’d thought about asking about first. We’ll come back to those in a moment, sorry.

Jamie : [20:30] But you know I have this note in our conversation plan if you will that is about how it’s a shared responsibility across the public cloud providers; it’s what we’ve just been saying. And I have this quote from you from when we were planning it out and you know, “if an issue is discovered in cloud platform A, then the engineers at cloud platform B aren’t making fun of cloud platform A for having found the problem. They are , you know, looking for ways to help cloud platforms fix the problem.” It’s not a case of, “well, we’ll leave them to worry about it themselves. " It’s about, “how can we all help out?”

Jamie : [21:17] I think I have another quote from you from our planning session that says, “it shouldn’t be about compromising on security to withhold information on threat actors. It should be about collaborating.” And I feel like that fits both the public cloud providers and obviously engineers within a team regardless of whether that is a team that is internal to a company or a team that is global or a team that is split across two separate companies perhaps one’s a consulting team and one’s internal team it should be about everyone collaborating to help everyone out, right

Bojan : [21:51] Definitely. I was recently at an event where I spoke at, and I mentioned and shared my view that security is a team sport and some even say like, “it takes a village.” Like, depending on the geo and region in question, people might use a different phrase for it; but it just goes to, and I’d like to kind of go back to what I was saying initially: when you look at security security as a problem it’s very complex and it’s very hard to solve. You can address it and that’s where this infinite game mindset comes in. Because, in security, you don’t have a defined, you don’t have set rules or defined rules of the game. So you gotta actually live in day in day out, and kind of still be in the game. And if you’re still in the game after a while with everything you know happening around you, with no defined rule set, then you’re still in the game. So that’s actually a big success. But what makes it very, very difficult is security is inherently very, very challenging to address. So it’s not like we can tick the box and say, “even with a lot of work, we, you know, we solved security,” because it’s ever evolving as being part of that infinite game. It’s very much around, you know, always, always working on it, always iterating, always evolving.

Bojan : [23:13] Some even compared to like going to the gym. So you can go to the gym for a week but then if you don’t go for a month, obviously the muscles you were building are going to atrophy; so they’re not going to be as strong if you need to kind of use them to dwarf a cyber attack. So it’s not very appealing at times to say to folks that security is like a gym, because they’re going to say, “Boajn, this means like every day we need to do something about it. Like who wants to go to the gym like every day?”

Bojan : [23:42] But there’s a lot of truth in that, like, you never really can get complacent. You always need to look at how can you actually look to iterate, how can you evolve, how can you improve. And when you look at the competitor and when something like bad happens on their side. I, for one, am not one to cheer and say, you know, “this is great. " No, it’s actually, they were hit by something. And it’s always important to understand, like, what happened. And, Jamie, you and I know this best. Like, there’s a lot, a lot of libraries that are used, like, in different software, you know, and different, like, products. So in case someone is using something and they’re less secure because of it, it’s also doing your due diligence and understanding like what it is that made them less secure. “Is it potentially something that’s affecting our organization as well? And if so, can we actually solve this? But if we’re solving this, wouldn’t it make more sense for us to solve it as an industry together, and work on it while, at the same time, understanding there are going to be times where we’re going to competing for, you know, a specific line of business or a specific customer?” And that’s fine. But there are some things we shouldn’t actually look to compromise on. And that’s security, be it sharing information about different threat actors, about CVEs, like common vulnerabilities and exposures. Those are the things I believe we need to really come together as an industry to address security in a meaningful way. Because solving it, it’s really, as I see it, the challenge of our time. And it’s similar to like ordinary crime. You really can’t solve it. It’s always going to be there.

Jamie : [25:20] Sure, sure. And I guess that’s why things like the CVE databases, and things like the NIST NVD, and things like that they’re all the… so that’s the the National Vulnerability Database, I believe that’s what NVD stands for. They’re completely open so that you know anyone can read through it and go, “oh wow. I have a vulnerability in some package, in some service, in some thing that Im taking a direct or indirect dependency on.” And I guess that’s kind of where the idea, and you know this is, I feel like more of a development topic, so it’s totally fine if we can’t touch on it; but I think that’s where reproducible builds and is it provenance and things like that, and attestations–about, “how I built my software,”–and building up a full software build of bill of materials, and having a list of things like dependencies and all that kind of stuff. So that you can be ready for when a CVE is announced, you don’t have to go, “everybody, abandon ship while we figure out whether this affects us!” Tou can actually go, “no, that doesn’t affect us because we already know what is in our system, and we already know which dependencies we have.”

Bojan : [26:40] And I believe, to your point, that discovery, some call it like an inventory, it’s hugely important. Like, even very, very simplified, to your point, like, even, “I understand, like, these are the, I’ll call them assets that I need to ensure are protected because they’re important to, you know, the organization,” to how, at the end of the day, we make a living, how we, you know like, pay for pay checks, etc.

Bojan : [27:09] So these assets could be web apps, it could be like servers, it could be like cloud resources. And those assets need to be inventorised. So you need to know what you have, what’s on it, so you can actually understand what’s the potential risk. And that risk could be evolving, it could change over time, you could discover something tomorrow you weren’t aware about yesterday. So your risk exposure might also change over time. And then depending on that, there are certain step of countermeasures or security controls you can actually put in place to minimize your risk to an acceptable level for the organization to be able to continue doing you know what it is they’re striving to do, and what they set out to do.

Bojan : [27:53] One of the things I tried to actually do in the book, and I hope you and your readers are gonna you know, let me know when you read it if I was able to: I wanted to make it hugely practical. Like instead of now saying, “I’m going to teach you about one particular service, and how you configure everything.” I wanted to teach folks how to configure the things that I felt mattered the most, because those are the things that have the highest probability of their environments being, you know, secure. And environments here, meaning Azure environments, because the book is obviously focused very much on Azure security. But there are times also some concepts which go outside of Azure security, like the defence in depth, this infinite game mindset, etc.

Bojan : [28:36] One other is obviously infrastructure as code, which you and I also spoke about, that it’s hugely important to discover any vulnerabilities very, very early on in the software development lifecycle.

Bojan : [28:49] And regardless of the reason, like you can even speak about, even beside putting it like this is the right thing to do, there’s obviously a lot of also cost benefits in doing this discovery very early on. Because the sooner in your software development lifecycle you can actually detect the security weakness or vulnerability and the more likely it is, the sooner you can fix it and the less downtime you’re going to have on those assets that the business needs to you know generate revenue through a web app, or through a server, or through cloud resources. And that’s where I also believe like one huge area that should be highlighted even further is actually discovering these vulnerabilities and code very, very early on. Ideally like at the beginning of the software development life cycle

Jamie : [29:44] 100%. And I feel like that kind of leads us nicely onto to something else that we had in our conversation plan, which is that it’s a point about that there is something that we’ve both noticed and that there is a gap, maybe it’s a substantial gap, maybe it’s a tiny gap, but it is a gap nonetheless, between those of us who are developing the code and those of us who are supporting and deploying it. And those of us who are designing it, those of us who are architecting it, those of us who are doing security audits on it.

Jamie : [30:21] Like you said, I am a very big proponent of pushing the conversation about security as far to the left of the software development lifecycle as possible. So that is, in a left to right culture, you start the software development lifecycle with maybe business analysis, and then maybe some design or architecture, and then eventually you get to building the code and deploying it, and showing it to the customer on the right hand side.

Jamie : [30:51] You need to be having those conversations as far to the left as possible. And then continually, throughout those conversations with the security experts, with the security advisors, with people like yourselves who are helping with, “how do we, in this instance, secure our Azure stuff?” You know, those conversations need to be had nearly constantly in my opinion. And we need to make sure that, if I decide to build an app with a particular library or framework, or something, or host it somewhere specific in a specific way, I need to know what the security risks are. And there was a talk that I went to last year where the chap was from a cyber security company, and he was talking about, “we can produce you a list of CVEs and a list of things that your application is not compliant with. But what we actually do we give you, we have a chat with you about, what your application does and what your use cases are, and of where your core audience, are and all that kind of thing. Your customer list and things like that, who it is that’s using the app? And get an idea of the situation around your applications and your systems.

Jamie : [32:11] And then they said, “what we do is we produce a list of CVEs that are relevant to you. So for instance, if you’re hosting on some public cloud hosting provider and you have no control over say the version of Linux that is running on the server that your application is running on, and there is a CVE for that version of Linux. You can’t do anything about it, so we won’t tell you, but we’ll go and tell your public cloud provider ‘hey this particular customer of yours is running this particular thing which seems to be vulnerable, you know. You’re going to need to put some effort into fixing that. ‘” A nd so it reduces the amount of burden, and the amount of stress. But as a dev, if I don’t know that my software isn’t secure, then I’m not going to be able to actually make it secure. Right.

Bojan : [33:03] Mm-hmm. It’s such an important, also, I believe, topic in general when you think about that. Typically the folks who are tasked with remediating vulnerabilities in code are different than the folks who discover, you know, weaknesses. You might have different teams altogether. One team, typically it’s the, I’ll call them the central security team. They might be on point for you know discovering weaknesses for nobilities inside of you know an organization’s environment.

Bojan : [33:35] And after they discover it, rarely can the central you know security team go and fix it. Especially, you know, inside of a code of an application they need to work together with like devs, and with folks inside of the company, or whoever you know built that application to begin with. And, to your point, I still see like a divide between these two teams; because, firstly I don’t believe they have the same visibility, so they’re not looking at the same thing which impairs the conversation they’re later going to have around you know, “how are we going to fix it?” Like, “who’s going to be on point for this to fix it? Whose responsibility is to fix this like to begin with?” etc.

Bojan : [34:20] But another one that I see is at times it can also be around the different tooling used. To give you a sense, the tool that the central security folks use might be actually different than the tooling that you know the developers use. So how do you then get a developer to look at the other tooling and vice versa. And that’s also I see a behavioural challenge that’s also preventing these teams from working better and more effectively when it comes to, not just discovering vulnerabilities in code, but also later on fixing them.

Jamie : [34:57] 100%. Because you know a lot of the folks that I know in software development who are deploying things in a fast manner will just be like, “hey. I’ll just throw it up on the cloud provider that we’re using, and just throw a WAF in front of it and it’s secure, right? That’s totally fine, and then I never have to think about it again. I’ll just put my fingers in my ears and go ’la la la la la’ because I’m not using the tools that will tell me whether my system is under attack or not.” And there’s a whole conversation, a whole separate conversation, about metrics, and logging, and analytics, and stuff about security related things.

Jamie : [35:35] But you’re absolutely right, going into a an organization, and joining those two teams together, or multiple teams together, and saying, “we all need to be speaking this ubiquitous language, right?” We’ve all decided, or a a large enough subset of us developers have decided to adopt domain-driven design and talk about a ubiquitous language and use the words and phrases that our customers use, those who are buying the software, so that we can build the software such that it uses those words and phrases by default in the design.

Jamie : [36:09] So why are we not using this ubiquitous language idea with the internal teams talking to QA, talking to security, talking to these experts, and using the different tools? Because, I mean, what does it take for me to download one of the like OWASP Zap or something like that right, and just run it. It’s an executable I can download, and I double click it, and there’s the tool right. I don’t have to actually… I may have to take some time to learn the tool, but that’s a trivial amount of time versus the amount of time and effort that was required to build that tool right.

Bojan : [36:45] Absolutely.

Bojan : [36:46] At times I believe it’s also one of the additional challenges. As I see it is, you might not just have this divide between the two teams but you might actually have challenges in how they bridge that gap, and how they actually are going about you know bridging that divide. You might, instead of having a meaningful conversation, you might have internal either politics, it might be, “we don’t want to use the tool that you’re giving us to use, like why can’t we have it inside of a tool like GitHub or whatever platform we are using?” So I also see a lot of challenges with that. But effectively, what it goes back to is security. And security is a team sport. And there’s very little, I believe, advantages in having an organization and having people inside of an organization throw the ball from one court to the other and saying, “no, it’s not our problem, it’s the problem of team, you know, so-and-so.“Where security is actually a shared responsibility.

Bojan : [37:51] In a sense, when the security team discovers a vulnerability, someone needs to fix it. But at times the people who need to fix it they also need help in understanding like what needs to be fixed I believe you also gave a really good example around the times there are also organizations that mandate, you know they need to put a web application firewall in front of their application. But as we all know, when it comes to security, it’s always wise to have several security controls; because if one of them you know falls out then at least you have other security controls to mitigate the risk and mitigate, you know, a threat actor finding success with their attacks. So the developers also need help in understanding how to effectively fix something and need to work together with the folks who discovered these vulnerabilities as one team, and even work if they’re different teams across teams to ensure that whatever it is that’s actually introducing risk into the environment for an organization is fixed.

Jamie : [38:56] 100%. Because if I, as a software developer, no actually let me put it this way: if I have a single lock to beat, if I’m a malicious actor right, and I have it I know that some treasure is hidden behind a door with a single lock on it, I only have to destroy that one lock or get around that one lock. Whereas, and you said it earlier on, this defence in depth idea of, you know let’s use our example of using a web application firewall right? I throw a WAF in front of my app but behind the firewall is all of the things right: the database, the application, maybe some kind of super secret stuff right. If everything is behind the WAF, and I defeat the WAF, I have access to everything right. And so that’s why, I think you mentioned things about defence in depth and things like that, but like you said, you know, a lot of developer training doesn’t focus on specifically on security, and I appreciate that a lot of security training does

Jamie : [40:06] I also appreciate your point about, :we need to be able to, sort of, share the knowledge and allow people to understand, right, this particular CVE, this warning, this issue that we’ve just discovered affects us in X, Y, and Z ways. And so we need to think about how we’re going to fix that, " right? Because like you said, whose responsibility is it? It’s everyone’s responsibility, right?

Bojan : [40:31] It really is. It goes back to security being a team sport or, you know, as people in America say, it takes the village. I believe you also captured it quite well around, you know, defence and depth with the different logs.

Bojan : [40:44] I hope you’ll appreciate the analogy I typically use for this is football, which in America they call soccer, but we in Europe, we call it football. And I always say, like, “how difficult is it to score a goal when you only have the goalkeeper in front of you?” Like, it’s probably difficult, but you need to get past the goalkeeper and you can score the goal. But when you add a defender between you and the goalkeeper, now all of a sudden it’s more challenging to score a goal; because in addition to getting past the goalkeeper, you also need to get past the defender. And then when you add two defenders it’s even more complex and more tricky to score a goal. Now you, all of a sudden need, to go get past two defenders and a goalkeeper. And that for me captures also defence in depth like adding in a meaningful way, not just adding for the sake of adding different products. Because that with itself brings a whole different set of challenges. But when you add in meaningful ways, layers of security, so that you have different security controls, you’re able to mitigate risk in a meaningful way for your organization.

Bojan : [41:55] And I believe going back to the conversation we’re having around, you know, detecting these things early on, I don’t believe organizations have time to just, you know, catch everything in a sense to deploy everything to production as is and we’re just going to figure out things as we go. We’re going to have a lot of solutions that do a lot of great things around detection around you know some might even do automated response but there’s just too much of it.

Bojan : [42:26] So you really got to be as an organization thinking like instead of then drowning in noise of security alerts, vulnerabilities, weaknesses, whatnot. It’s like, how do you go about, “okay, there’s some things I probably need to, you know, deploy, but how do I reduce all of the noise around, you know, vulnerabilities, security alerts, et cetera?”

Bojan : [42:51] And I believe a very important piece of that puzzle is shifting it as far left as possible. It’s ensuring that when you’re developing code, that you have processes and tools in place that allow developers, as they’re writing code, to write it in a more secure way. That way, you might not be eliminating all of the weaknesses that find its way to production. There’s always going to be zero days, meaning there’s always going to be vulnerabilities that are going to be discovered, you know, tomorrow or the day after next, which we are not aware of, you know, at this point in time. And that’s okay.

Bojan : [43:29] But you can still, by having security implemented and being part of the software development lifecycle early on, you can still minimize a lot of vulnerabilities and a lot of security issues, I’ll call them, that find their way into production. Which allows you to have more time, which allows you to have more resources to focus on other you know areas of the organization and the business. So when you look at who’s actually on point for security, it’s actually everyone. There is value in the security team discovering these things in production, but you can even consider the devs the superheroes because those teams that discover the issues they’re not able to fix them they’re not able to necessarily remediate those issues, they rely on the help of the developers.

Bojan : [44:18] So going back to the developers, they also then need help in understanding how to do this. There might even be situations where, you know, the folks who worked on the app are no longer with the company and it probably can’t find someone to fix it. So what do you do then? You could always look to mitigate it for different like controls, etc. But it’s that ensuring that whenever you’re developing apps that you have security in place as part of that development lifecycle, and that is going to pay dividends when you actually get into production; because you’re going to see that much less security issues and security vulnerabilities.

Jamie : [44:59] Absolutely. And to sort of underscore that a little bit, I guess, we as developers have put loads of effort into creating, say, suites of tests that we can run at a moment’s notice and take moments to run, right?

Jamie : [45:14] We have a lot of unit tests that we can run as long as we can agree on what a unit is, but we’ll leave that to one side. But what we can do then is we can then have security tests. All right, they might be basic security tests like, you know, “have you have you protected these endpoints?” or, “is the TLS certificate valid?” and things like that. But these are tests that we can run on perhaps a daily basis, on an hourly basis, maybe on a commit-by-commit basis, or a push basis or something like that. On a build basis, before we deploy the code, deploy it somewhere temporarily, run a barrage of security tests on it for known things that we know about, and then if it passes all of those brilliant we can promote it to the next environment.

Jamie : [45:58] And then what we can then do is add more tests to those test scripts as we know about more vulnerabilities. And then we can, sort of, we can have some kind of idea of, “well, at least when we’re protected against these things that we know about.” And that’s just one idea, off the top of my head. That’s not me saying, you know, I’m not claiming any kind of genius here; I’m just saying that is something that we can do, that we have the ability to do. Because we can write tests right, and I’m sure that that I’ve completely reduced the problem down to an almost nothing solution. But I feel like that’s a good… maybe a good place to start. Is that, in your opinion, a good place to have these sort of repeatable things? These are almost like software playbooks that we can run against the app and just say, “hey is it secure? Is our system secure? Yes, it is. Promote to the next environment.” Maybe that could be a thing right.

Bojan : [46:53] Yeah definitely, I agree with you, gotta start from some place. So I’ll call it as a baseline and it’s very difficult and I don’t, I’m not a fan of saying, “you should start here, you should start there,” because at times, organizations are in different points of their journey. So I totally understand and I agree with you. It’s important to have a baseline of security, meaning a starting place of securing things. And I believe you gave a really good example of how tests fall into tha,t and how that can be part of a defence in-depth conversation. The thing I’ll say is because and this ties it back to that infinite game mindset, because the attackers aren’t playing by, you know, any agreed upon rules, we really need to think like, “where that baseline of security is, and is it actually high enough to prevent most of these attacks you know coming in?” And if it’s not then we need to actually ensure that we raise it to that point where we’re going to feel, like, comfortable with our web apps running, you know, on Azure, or running on any other public cloud platform, or even on-prem. Because it’s going to give us that confidence that we can go about doing our business without being susceptible, in a large amount of cases, to what might happen to them.

Jamie : [48:17] Yeah, absolutely.

Jamie : [48:18] I feel like I’m going to change gears ever so slightly. I know we said, “whose responsibility is it?” earlier when we said, “it’s everyone’s.” And you said if we’re pushing something to a public cloud, I’m going to ask this question… I already know the answer because we talked about this when we planned this episode. I already know the answer. If I push my app to… so, okay, let me just dial back a bit and explain a little bit. I remember early in the, when it was Windows Azure, right? One of the big promises was, “if you run your app on our cloud infrastructure,” and this is a promise made by all the cloud infrastructure people. So, you know, I’m not picking on Microsoft or Azure. They’re big enough for me to pick on them, but I’m not picking on them.

Jamie : [49:05] I remember the promise being made that, “hey, if you run your app on our infrastructure, we will take care of ensuring that the infrastructure is up to date and the latest security patches are installed for you.” Because if you’re running on a VM or a machine that is on-prem that you’re managing, you’ve got to manage that. And the canny thing, the clever thing, about that is that they knew that… maybe through analytics or maybe just by guessing and getting it right… that the majority, because you pointed out a lot of companies don’t have the time to stop, reflect, install updates, make sure everything works, and carry on; whereas if I’m abstracting away that hosting service, I don’t have to worry so much about stop, reflect, install updates for the operating system for the whatever infrastructure I’m running and carry on. So with that bit of knowledge tucked away and so that in case the folks listening didn’t know that all of the public cloud infrastructure providers promised that as long as you’re not using a VM to host your app, they will do what they can to make sure that the underlying infrastructure is up to date.

Jamie : [50:13] So with that I might, and knowing that I already know the answer, because we discussed this earlier: I’m asking this for the listeners, so I’m going to push my app to Azure right or however you want to pronounce it, to Microsoft’s cloud system, then because it’s Microsoft’s responsibility to keep that platform to date I don’t need to do anything right? And like is that the case? I know the answer but I can’t say it, I want the listeners to hear you say it?

Bojan : [50:41] Look, I’ll acknowledge that there’s definitely a responsibility on the public cloud provider side. But at the same time, I wanna ground our conversation in the fact there is shared responsibility here. So there are things that the public cloud provider needs to do, there are things that they’re committed to do even contractually.

Jamie : [51:03] But there’s also things like an organization developing and deploying apps should be looking to do as well. And as part of this shared responsibility model, it’s so important to understand it because it outlines then the things that I need to do as a developer, and my organization needs to do to uphold our part of that bargain for that app to be as secure as possible. I believe, in one of our conversations, you also provided I believe a brilliant analogy around driving a car: so imagine if you’re driving a car, you drive it into a wall. Is it the car manufacturer’s fault or is it the driver’s fault? And it really is a shared responsibility conversation for me, where we need to be like really clear around, “who does what? "

Jamie : [51:54] You’ll often hear me about comparing it to children’s football or soccer. And the thing I’ll say there is: if you ever watched like grown-ups play, it’s like everyone knows their place and everyone knows what they do. When you go and see like children playing, all of us that have little ones are going to know, it’s usually like everyone runs towards the ball. It’s like they all just run towards the ball. So you don’t really have this, everyone knows what they need to do, they just run towards the ball. And I believe that’s a very important thing to avoid. We need to all know what we need to do and what our responsibility is, because at the end of the day, it is a shared responsibility model. So I hope my answer doesn’t disappoint you there, Jamie.

Jamie : [52:41] No, it was perfectly correct. exactly the answer I was looking for. Like I said, for listeners, we’d already discussed this and we already agreed that it is everyone’s responsibility. And yes, okay so from my perspective as a consumer of all of the public cloud platforms, like you said there are assurances that software updates will be patched in, and operating system hardening will be done, and things like if I’m using kubernetes they will handle the upgrading and updating and fixing the API changes and all that kind of stuff. They will handle all of that for me. All I have to worry about, and it’s a big “all” because–here come the bunny quotes–“all” I have to worry about is making sure that my application and the infrastructure that it is utilizing is set up in a secure way. And that’s the “all”, right. That’s where your book comes in, it helps people to actually figure out, “how do I set this up in a secure way?” Right?

Bojan : [53:38] It definitely does for Azure Security. And I hope everyone, you know, picking it up and finding it a happy home, either on their physical or virtual, you know, bookshelf is going to be able to take like real value out of the book. And again, it goes back to what I mentioned around, you know, depth of gratitude. There’s so many amazing people I work with and have worked with in the past who’ve shared with me knowledge that I look to, kind of, pay forward by sharing it through this book. So hopefully, you know, you’re able and everyone else picking it up, getting like real value when it comes to securing your Azure environment.

Jamie : [54:16] Absolutely, absolutely. And I’ll make sure that there is a link in the show notes, folks, for where you can go to get it if you want to get the book.

Jamie : [54:24] But as we start to wrap up, I wonder if you could give the listeners another quick, you know…. because they heard the name of the book at the beginning. And we’ve mentioned it a few times throughout, but we haven’t really stopped to say, you know, what it’s called again, so then the folks can have a listen and go ahead and do some Google or binging or whatever verb you want to use for searching the internet. But again, I’ll put a link in the show notes. And I wonder if you are contactable on social media, would you mind sharing any of those details? Like, not your username and password, obviously. But like you know if you’re on “The artist formerly known as Twitter” you know can folks reach out there? Or if you’re on LinkedIn can folks reach out there? That kind of thing.

Bojan : [55:09] It’s a great question. I’m not as active on what’s formerly known as Twitter as I used to be, because of you know everything. But I definitely am available on LinkedIn, so feel free to drop me a message over LinkedIn, or you know send me a request, and I’ll happily have a follow-up chat around you know the book or any questions you might have around this episode. So LinkedIn is probably the best way to, kind of, not just connect with me but also to keep in touch around some of the security related topics that I love, you know, discussing and speaking about.

Jamie : [55:47] Amazing. Amazing. And for the folks who are listening who are like, “I want to get this book now, because Bojan’s really, he’s got me thinking about some stuff that I need to do, and I need to go and secure my apps. " So what’s the book called? Where can I get it from?

Bojan : [55:59] The book is called Azure Security. It’s written by me and the publisher is Manning. So when you use your favourite search engine, just type in, “Azure Security Manning Publications,” and hopefully it should be the first or the second result returned. But again, if you have any trouble finding it, thank you, Jamie, for putting the direct link to it and sharing it. That can also be a huge help for folks to find it.

Jamie : [56:27] Not a problem, not a problem. I’ll get all those links and put those in the show notes. And there may even be a discount code there for folks, I don’t get anything out of it. But if it saves you a bit of money why not, right? Cool.

Jamie : [56:40] Much appreciated Jamie.

Jamie : [56:43] Amazing. No worries.

Jamie : [56:45] Well, Bojan I’ve very deeply enjoyed this conversation. There’s a lot of stuff that’s come up that I think is very, very important for folks to know about. Although, I came in knowing about the Infinite Game and knowing that it is a lot of people’s responsibility to focus on securing our applications, I feel like I’m walking away with more things to go and talk to my customers about, and my clients about. And “client” there can mean someone internal for the company you work for, someone external you’re providing services to, right? Because everyone’s a client, right?

Bojan : [57:19] Exactly, Jamie. Thank you for having me on. Truly enjoyed our conversation. And I look forward then to speaking to you again sometime soon.

Jamie : [57:30] Amazing. Amazing. Thank you very much, Bojan.

Bojan : [57:33] Thanks.

Wrapping Up

Thank you for listening to this episode of The Modern .NET Show with me, Jamie Taylor. I’d like to thank this episode’s guest for graciously sharing their time, expertise, and knowledge.

Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and full transcription of the interview. The show notes, as always, can be found at the podcast's website, and there will be a link directly to them in your podcatcher.

And don’t forget to spread the word, leave a rating or review on your podcatcher of choice—head over to dotnetcore.show/review for ways to do that—reach out via our contact page, or join our discord server at dotnetcore.show/discord—all of which are linked in the show notes.

But above all, I hope you have a fantastic rest of your day, and I hope that I’ll see you again, next time for more .NET goodness.

I will see you again real soon. See you later folks.

Useful Links

• Bojan on LinkedIn
• Azure Security
• OWASP ZAP—now owned by Checkmarx
• Supporting the show:
  • Leave a rating or review
  • Buy the show a coffee
  • Become a patron
• Getting in touch:
  • via the contact page
  • joining the Discord
• Music created by Mono Memory Music, licensed to RJJ Software for use in The Modern .NET Show