Episode 121: New Open Group Security Standards Documentation

Welcome to the Azure Security Podcast, where we discuss topics relating to security, privacy, reliability, and compliance on the Microsoft Cloud Platform. Hey everybody, welcome to episode 121. This week it's myself, Michael, with Mark and Sarah. And we don't actually have a special guest, we actually have Mark.

If you've been paying attention, you'll notice that over the years, really, Sarah and I tend to speak about low -level technologies and products and so on. And Mark tends to talk about process people, strategy, and architecture, especially with the work that he's been doing over the years with the Open Group. And we thought that since it's such an important topic, why don't we just have a special episode just on the open group and what they're doing around this kind of work? So the reason why we're recording this is in part because the open group has just published the security rules and glossary standard.

So that's going to be the topic of this week's episode, a little bit different. But I think for a lot of people out there, this will be a very important and very interesting topic. But before we get to Mark, let's take a little lap around the news. By the way, Mark will have no news because basically his whole section is the news that he has.

So I'll kick things off. Got a couple of news items about private endpoints. We've now made available in general availability, high scale private endpoints. I didn't even know this, but historically you could only have a thousand private endpoints per virtual network.

I don't know, seems like a good number to me, but apparently it's not. You can now deploy 5 ,000 private endpoints in a single VNet. It is recommended that you stick to 4 ,000 for reasons I don't know, but the max limit now is 5 ,000 using high -scale private endpoints. We're now having public preview, private link service direct connect.

So the private link service allows you to make your applications available to your customers privately and securely. I think we all know that. The way it currently works requires you to configure a private link service and place the applications behind a standard load balancer. Now with PrivateLink Service Direct Connect, you can expand that functionality.

It allows you to connect your services directly to the PrivateLink itself. So great to see a lot more flexibility there in the way you use PrivateLink. In public preview, we have signed requests on Azure Front Door. This allows you to have essentially URL signing.

It allows you to have really secure access to resources by using only signed URLs that are digitally signed by Front Door. I can think of a lot of scenarios where that would be really important. We also have, for Azure Front Door, we now have a web application, Firewall Capture. I didn't know we didn't have it, but now we do.

Azure Sphere OS 25 .10 is now available generally. This, if you're not familiar with Azure Sphere, actually it's been a while since I've spoken about Azure Sphere. It's essentially a very small chip, runs a very restricted version of Linux, and it's designed in highly secure environments that require essentially a system on a chip.

So that's available version 25 .10. Yeah, I love Azure Sphere. It's like everybody complains, like, we don't have any secure IoT devices.

Well, if you used Azure Sphere, you would. It's actually designed from the ground up using everything we learned from Xbox and everything else about keeping hardware secure in a hostile environment. Actually, that's a key thing. I'm glad you brought it up.

Actually, you're going to regret bringing up the Xbox thing. I don't know if you know it, but I actually worked on Xbox 360 security. And what was interesting about the 360, and same with all consoles, is that we treat the normal user as the adversary, which is a really interesting threat model. And literally the threat models are quite interesting that were built by the Xbox team.

But yeah, you're absolutely right. A lot of stuff that we learned from hardware security has found its way into Azure Sphere. Actually, I've got one around here somewhere. I've got an Azure Sphere SDK somewhere.

I'll dig it out. It'll be fun to play with. It's been a while. Anyway, last one, and this is my favorite thing of the whole lot, is in public preview, we now have the Azure Integrated Hardware Security Module, HSM.

I'm honestly so excited for this. When we announced that it was publicly available, sorry, in public preview, I immediately emailed the person who's running the project, saying, hey, can you give me access to the VMs that have this? So this is available, like I say, in preview on certain AMD version 7 -based VMs. They are the DAS -V7 series, the DADS -V7 series, the EAS -V7 series, and the EADS -V7 series.

All the way from little VMs up to big VMs. What it is, is essentially it's a hardware accelerator on the motherboard, on the actual hardware itself. This is really, really cool because you can use it for acceleration, right? You can do crypto in hardware as opposed to being in software.

And then also you get all the things like key isolation. It is also FIPS 140 -3 Level 3 validated hardware. So you can offload things like encryption, decryption, signing, verification operations, depending on what you're doing, all within the confines of the HSM. And the keys don't leave the HSM.

If you squint a little bit, it's like a mini Key Vault in hardware, locally accessible to the VM. The APIs that you access it, though I've been experimenting with it, they're not the Key Vault APIs. They're actually the Windows Crypto Next Generation, the CNG APIs. Either way, I mean, it's very well understood.

So right now, the HSM is available only on Windows, but Linux support is coming very soon. Fantastic to see, super excited about this because now you can store secrets and so on in the VM, in the hardware, as opposed to like in software or in configuration files. So this is really great to see. Anyway, that's all I got.

Sarah, what you got? Okay, so I've got a couple of things about Azure Firewall, old faithful there. So they... We've just seen the GA of pre -scaling.

So if you're not familiar with the phrase, it's a feature that enables admins to provision and reserve capacity in advance for if you're going to have higher traffic loads. So, you know, seasonal peaks, planned business events. I always... Think of buying concert tickets for this personally, but it could be many different things.

So that's now GA if you randomly get very high peaks. And probably the flip side of that is the other thing that's GA is the observed capacity metric in Azure Firewall. So it's a new signal that you can get that lets you understand actually. how your firewalls are actually scaling in real life.

So that means that you can actually monitor your scaling, which will of course help you predict traffic patterns, et cetera. So two very cool things that as someone who was back in the day, a network engineer a very long time ago, well, I think it was a very long time ago. I do appreciate that they're quite handy to know, to be able to control your traffic. So the other one, the elephant in the room at the time that we should publish this, it's nearly time for Microsoft Ignite.

So you know me, I love my events. So of course, you should tune into Ignite. I know there will be, I can't give anything away, but of course, there are announcements in the security space. If you're going to Ignite, come and say hello.

I will be there, although I will largely be locked up in a studio, I believe. But... If you see me, come and say hello. I'll be hosting the live stream again.

And for those of you who aren't able to travel to San Francisco, of course, you can register online for the live stream for free. And if you're in a part of the world that isn't necessarily super friendly for the whole thing, because it is US friendly hours, of course, there will be things put on demand as well. So you can watch it later. So of course, make sure you do that.

All right. Now we've got the news out of the way. Let's talk to Mark. I mean, this is basically your show at this point, Mark.

So we're here to talk about, and correct me if I'm wrong here, we're here to talk about the open group and the fact that they've now released the security roles and glossary standard. So why don't we start at the very, very beginning, which is, you know, what is the open group? Why, you know, what is this standard we're talking about? Why was it put together?

If you want to just give us that lowdown and then we'll see where this thing goes. So the open group is a standards body. And they've been putting out security standards since the 1990s, actually. They also do a number of other popular standards as well as some obscure ones and industry specific ones.

The thing that they're most known for is the TOGAF standard, the Open Group Architecture Forum standard for enterprise architecture. That's one of the big ones probably going to get yelled at because I forgot a few of the other ones off the top of my head. The ones that I primarily work on are the security and zero trust standards. I actually been doing this for about, I think, three, four years.

now. And I recently actually was getting so involved in it that, hey, we need someone to be the forum chair. And I was like, what the heck? I'll run for it.

And I got it. And then I was like, I don't have a responsibility. I should probably have some sort of vision or roadmap or whatever we're trying to do because this is my forum now. And so we put together a body of knowledge and a plan for security and zero trust and how it all relates together.

And that sort of led to a lot of good thinking and strategy, including this roles and glossary standard that we're about to release. The intent of the whole body of knowledge, I'll just start with the big picture. Actually, I'll step back one more thing. The focus of the open group is really just openness, consensus.

They've actually got a really rigorous set of processes to go through and release these standards to make sure that even if you're business competitors, that people can work together, come up with a standard that works, and then everyone can use and adopt it. It's got a lot of really, really valuable attributes. from the perspective of driving the industry forward. So that's one of the reasons that I've invested a lot of my time into it.

The security rules and glossary standard, as folks from the former British Empire would say, the name is on the tin. Security glossary is the first part of it, and it just defines terms. This sounds kind of boring, like, ooh, you're writing a dictionary, yay. Well, in the security industry, there's a lot of terms that people use wrong.

There's a lot of people using the same term for various reasons. different things. There's a whole lot of conflict and just mess, quite frankly, in the terminology space. And so this one actually ended up being a much more interesting project than I thought.

Some of the things that we took from real world examples is Dart, our detection response team at Microsoft. In that glossary, we included some of the learnings from that, which is there is a very big difference between an incident, which means something happens we have to investigate just in general, versus a compromise that we know the security was violated in some way or form or fashion, versus a breach, which is there is a legally reportable event that we now have to go through a legal process on.

Those three things are very, very, very different, but people use them interchangeably. And so it was really kind of an interesting project to go through the glossary piece of it. And then the roles is defining the roles in security. We initially set out to do the security roles.

But what we found is that security is not just the security team's job. Think about it from an IT perspective. Is the IT team going to let someone patch and reboot their servers on the security team because it needs a patch? And the answer is, oh, heck no, because they have other requirements.

They have availability, resiliency, meeting the business requirements, and all sorts of stuff. And they're going to get blamed if something goes wrong. And so, well, the only people that can actually apply those patches are the security people. And it goes a lot deeper than that.

So we ended up covering all these roles. And we got to this point where we sort of realized that, you know, I was doing this work on my Zero Trust Playbook series, as well as all my Microsoft work. And I'm like, you know what, we just need to all be operating off the same set of roles. And so my co -author and I, Nikhil Kumar, who was on the show before, we just decided to contribute that list of roles to the open group and then, you know, develop those there.

into an open standard for all to use. So Mark, what is actually being released then? Very good question. There's about 73 roles so far total that we've found.

And there's been a lot of interesting things like... You know, as we go through it, because that list does go up and down as we sort of define the details of it. So everybody knows that there's a CIO role and that's sort of the existing, you know, job that you have to do. And then there's a CTO role, which is the new technology versus, you know, the CIO running the existing stuff.

But, you know, what is a chief digital officer? And we're still kind of working through that. And is it an overlap or a combination of the two? Is it a virtual role or is it just a title that some people take?

And so there's an interesting sort of number change thing to it. But at the end of the day, there's about 73 roles total. And we knew we couldn't get all the details out for all of them on the first pass. And so we wanted to start with the ones that were the most important, the highest impact.

And those are in two areas. One is in the depth and the heart of security and the security operations center or SecOps or SOC. Um, and there's a lot of mystery, a lot of confusion. It's, I mean, it's, it's essentially the front line, right?

It's where the actual real time conflict happens with the adversaries that you've been prepping for, or hopefully been prepping for. Um, and there's a lot of confusion around that. So we spent a lot of time, you know, uh, making sure that that one was clean and clear. And so that, that section came out first.

Um, and of course the glossary I mentioned earlier. So we have the first version of the glossary and we expect that to have additional terms added as we go. And then the other one that we decided to focus on is the business leader roles. Because one of the things that we've found is it's not just within the IT versus security that there's a lot of confusion and there's a lot of security responsibilities that people don't realize are their accountabilities, actually.

We also realize that if you think about it this way, a business leader can create security risk through their decisions without even knowing. Anything about security or without even knowing that they're creating that risk to the organization, to the shareholders' value, right? So say I'm a business leader and I set a target that I want to get this particular revenue level, which means I have to run my systems at 100 % uptime. And that seems like it's a business decision on its face, right?

You're going to be aggressive about it, right? And that seems like a valid business decision. But what's not in the mix is like, well, that means there's no maintenance windows. That means that we can't apply patches for things that we know adversaries can use to take those systems down.

Business leader says, you know, I want 100 % uptime, you know, and they say, well, we don't have any maintenance once it was too bad. Well, can we get some money to fund some redundancy or cloud systems or something that's modern like that, that we can patch it on the fly and hot patch it? And they say, no, they have just created security risk. And at that point in time, if the security team doesn't stand up and push back, then that risk is going to go forward.

And what happens when there's an incident? Well, they're going to blame the security team, right? Because why didn't you stop these attackers? And that just doesn't make sense because the security team doesn't have any control or influence over the decisions and actions that led to the breach, to the exploitation of that very well -known.

attack path, essentially. And so we really wanted to demystify that aspect of where security goes wrong and really kind of correct that. And so that led to two different things. One is the literal business leaders like, hey, member of a board of directors, CEO, chief executive officer, chief operating officer, chief financial officer, chief counsel, chief legal officer, et cetera.

For those senior leadership roles, what is your security job to do? And then that also led us to... that we had to tie this in so that they understood that this is part of their fiduciary duty. Now, I know a lot of people don't know that term fiduciary.

Essentially, a fiduciary is someone that is an agent that is acting in a trusted way. So as a shareholder, say I own a company and then I appoint a CEO to run it, I am trusting that that CEO is going to take good care of the assets that I own, that they're running on my behalf. And that's essentially the relationship between shareholders and a CEO, and of course the board that oversees them. And so that fiduciary relationship and the fiduciary duty that they have to the owners of the company is super, super important because that is a legal and ethical obligation in many countries.

Different law systems mean slightly different between common law and others. But that is a very, very powerful, important core part of being a member of a board of directors, being an officer of a company. And so what happens is people don't understand that there's security aspects of their fiduciary duty. And so one of the things we did was we took the fiduciary duty, and there's a certain set of duties underneath it, the duty of care.

You're going to take care of those assets, the duty of loyalty that you're going to. treat the interests of the shareholders first before you do your own personal and other interests. There's a bunch of different duties in there. And so we took those duties and then we explained what does that mean from a security standpoint?

What is the fiduciary duty of a board of director, of a CEO in regards to security when you're looking at duty of care, duty of loyalty, and what are the things you have to do to make sure you're fulfilling that duty correctly? And so we really took that time to anchor that so that all of this is coming from a really core foundational piece. And it's not just, hey, the security team is complaining. This is actually part of taking care of the shareholders because, you know, say a company loses, you know, whatever, 10 % of their revenue for the year because of these decisions.

If that was something that could be anticipated, then that's something that is really a part of those business leaders' jobs. this guidance? What is provided for each of the roles? Honestly, how are people going to use this material?

Good question. Effectively, the way we addressed each of the roles, obviously, aside from the special fiduciary duty parts of it, is we really focused on a couple different things for the roles. It's either three or four. I can't remember off the top of my head.

The first is, what are the job functions? If you're a non -security role, That's an accountability, right? Because if I own risk, I own security risk. It's like a tattoo.

It just automatically comes with it. It's not something you can decide whether or not you do. If you own risk, you own security risk. And so those job functions are accountabilities for a non -security role.

So for a CEO, for a CIO, for a developer, et cetera. What are the different job functions that you have to do for security? For example, on the CEO one. You have to set up the accountability of the organization and make sure you're holding the business leaders accountable for the decisions they make.

Because if you make a decision, you own the outcomes of it. Whether it's legal, whether it's financial, whether it's security, it doesn't matter. You own the decisions that you make. the CEO has to set that up correctly.

They have to set the culture of the organization. Nobody else can set the culture of the organization or set the accountability structure of the organization. And so there's certain things like that. In the case of a security operations, say a tier two, an investigation analyst, that's more like, hey, you're going to investigate the incidents and remediate them and then work with the...

with the IT folks and whatnot to get them remediated and cleaned up. And so the job duties is the first and most important part. And what are the different jobs that have to be done, quite frankly, as this role? And so that's the first part.

And then for each of those. We wanted to have a really powerful why so that this wasn't just here's a random opinion. So what we did was we defined a risk of neglect for each of those. So if this is not happening or it's not being executed well, what goes wrong?

Do you have more security incidents? Do you have more severe incidents? More business damage? Do you have more reputational damage because the comms person isn't explaining this well publicly or following best practices during an incident?

So that's like the first part is like what literally is the job to be done. The other things that we covered was, hey, what assets is this role accountable for? Because, for example, if I'm an IT person, I'm working on servers and cloud assets and containers, then it's my job to patch and maintain and configure those correctly, et cetera, because I'm the one that's managing that asset. If I'm a chief financial officer, there's a sort of a different.

meaning of the term asset, that I own the accounts payable process. I own the accounts receivable process. That means I own the risk of fraud, or my people do, and working through that with the organization. And so as a security team, I can't fix business email compromise because that's someone tricking someone into paying something.

That's a financial process that's owned by the CFO. or one of their delegates, and they need to make sure that that process is actually resistant to a scammer, right? Just like fax or phone or someone walking in. All those forms of fraud.

Email fraud is basically just email fraud, right? And so that's the second piece. So jobs to be done, the assets. And then the other thing that we realized is in order to actually secure these assets, You need to have some knowledge.

You can't just walk in off the street and I came out of finance school or I came out of, you know, I got my law degree and then I automatically know security. You need to have a security education. You need to have some knowledge so you know how to protect those assets and you know how to do those duties. And so that's another section that we define and, you know, provide some bullet points on this is the knowledge that you need as a business leader, as a lawyer, as a marketing person, as a comms person, as a technology person, as a developer, as a SOC person or a GRC.

C person, et cetera. So that's the third one. And then the fourth one is just how does this tie into the capabilities, which is part of a different open group standard, the Zero Trust Reference Model, because the capabilities are basically what are the things you do in security that you do all the time. So if you take like a business capability, for example, you buy raw material.

You make a product, you sell a product, you ship a product. Now, the capability of shipping a product, you might ship it with a plane, a train, or an automobile, but you're still shipping a product. It goes from my facility to their facility. And so that was, we realized we needed to define that for security.

What is that durable outcome? And that's in this Air Trust Reference Model. And then you need people -processed tech to make that come to life. And so, you know, whether it's responding to incidents or...

or patching systems or doing secure asset management or all the different security capabilities that are defined in there, you need people, process, and tech. And so the process and tech are defined as architecture building blocks in that other Zero Trust Reference Model standard. But within the role standard, We need to map that back in and say, these people work on these capabilities. And so that's really what we're giving for each role.

So what's the job to be done? What assets do you own? What knowledge do you need? And how does this relate to the overall security capabilities that are being defined that don't change in security, regardless of AI and cloud and every other thing that's happening?

Mark, so obviously you've done a lot already, but... Is there more coming? Is this part of something bigger, a bigger piece of work? Because I know you don't do things by halves.

Yeah, the big part is really just that security and zero trust body of knowledge, right? We want to have a coherent way of looking at security and, you know, having those capabilities I mentioned, having the roles defined. These are very foundational components because security is, quite frankly, a very new discipline. It's only, what, three, four decades old compared to like, you know.

buildings and energy and all these other things that we've been doing for hundreds of years, if not thousands, as a human society. And so what we wanted to do is help professionalize this with that security and zero trust body of knowledge. And so one of the things that we're documenting there as part of this is, hey, what do the attackers do? And MITRE ATT &CK is a part of that.

It's like the technical proven attacks that are out there. But there's also a bigger picture thing with Um, What are their motivations? Because they're either doing it for money or mission or both. And there's criminals, there's nation states, there's hacktivists, right?

There's a finite amount of stable things that we've seen over the past couple of decades that have stabilized. And then what are their operating models and how do they make money off of you? And so we want to document and standardize the attackers. And not standardize because we want to make them conform to this, but standardize so that we have a standard definition of these that we can then say, okay.

is what they do, then what does that mean to us? And then we want to do the same thing on the business side. Like how does a business operate? It makes decisions about risk using money.

There's all these different things about how a business operates. And we also need to document that so that we can then say, what does the security team need to do because of that? And so those are some of the different things that we're kind of covering as part of this body of knowledge with the security matrix and enterprise risk integration. And then we have the zero trust commandments and the security principles for architecture.

There's about eight or 10 different components that we're putting together as like one holistic system. And we're embracing as much of the work out there from MITRE, from NIST, from Center for Inherent Security, OWASP, et cetera. We're really trying to connect and fill in all the gaps, but use the stuff that's out there that's great, that works, and then fill in and put all the gaps in and the foundations underneath the. those houses.

So, I mean, this has been quite a while being created, I guess. I mean, I can't imagine you guys came up with this overnight. So what sort of things did you learn along the way? I mean, things change as you're building this out.

So any sort of lessons learned along the way? This has been an intense source of learning. I'll kind of go from the top a little bit. One of the big learnings for me was the fiduciary duty aspect and how important that was.

Because I always knew that there was like this legal relationship that like officers have for a company as well as boards of directors. But I really wasn't as well versed in what fiduciary duty is, how it works, what the different duties are and whatnot. So that was a big learning. And especially because of how well it actually reflected.

what security should be at an organization because it really allowed us to show that, you know what, this is a risk to shareholder value. Now, at the end of the day, you know, those people in those seats, you know, if I'm a CEO, if I'm a board of directors, have to make judgment calls, right? Is this, you know, or even, you know, business line leaders or whatever, but is this something, a risk I want to accept? You know, because you've got different situations, right?

If I'm looking at making, you know, if I can make $100 million with this business initiative, And I could have a $2 million incident. I'm going to make a certain kind of decision. Now, if it's the other way around, and this business initiative can make $2 million, but it could cost me $100 million, and there's a good 60%, 70 % chance that it's in that $100 million or $50 to $150 million range, then... that doesn't that's going to make you drive to a different decision and so like really kind of getting in the heads of these different roles and working with them and kind of understanding that thought process as well as their fiduciary duty obligations that was like the that was one of the big ones for me because i always knew that there was a reason why people were making these bad security decisions but it was really for a lack of understanding in a way And then oftentimes a lack of understanding of the security risk.

This is another learning for me, is the lack of it being communicated well. I threw something out on social media for the fun of it a couple weeks back. I've learned that when a security leader or a technology leader is talking a bunch of technical terms that business leaders don't understand, they kind of sound like Charlie Brown's mom. um or charlie brown's teacher um so you know there's this you know cartoon series called um peanuts um and they had some various movies and tv specials and whatnot and it was all about kids talking to each other and so when the adults talk they didn't really want the adults to take over the show so they had this like kind of sound that they made from a trumpet and When security people are talking to the business leaders, it sounds like that.

And the security leaders are thinking in their head, I'm sorry, the business leaders are thinking in their head, I don't understand a word they said. I have no idea what they mean because we're talking about all sorts of IP addresses and port scans and crap that I have no idea what it is. So the only thing I'm taking away from this is it's a technical problem. And therefore, I'm expecting you to solve this technical problem.

And so if there's an incident, I'm just going to blame you and hire someone that can solve this technical problem. But it's actually not a technical problem. It's a problem. And so you end up with this.

The miscommunication is a huge, huge part of it. So that was a big thing that I saw. And then, of course, that accountability responsibility thing of the business leader making that decision and causing that risk. And then the security people being blamed for it.

What that helped me understand was just that people don't understand a RACI, an R -A -C -I, or responsible, accountable, consulted, informed. People don't understand the difference between the decision maker and the experts that advise them and recommend things for them. And so there's a lot of confusion around that. That actually led to an entire part in the security rules and glossary standard.

So the part one is the glossary, part two is... basically how to think about responsibility and accountability because we so often see security blame for things out of their control because they aren't able to communicate in terms that make sense and or those business leaders just don't feel accountable for it and don't feel like it's part of their job and it's just easier to blame the CISO or blame the security team. So those kind of things really kind of came into focus was some big learnings.

Another one is These things are complicated, and you can't really effectively manage security risk without a security counsel. So when you think about a ransomware incident, for example, and this is either preparing for one and getting the organization ready and fixing the process ahead of time or dealing with one in a crisis, a ransomware attack is technical because it's going to affect the technical systems. You have to recover them. It's security because there's the threats and what do they do and what are they likely to ask for and this and that and can we negotiate with all that kind of security stuff, right?

And then it's financial because they want to be paid on it and you have to figure out how to actually pay them Bitcoin and transfer the money from your accounts or whatever into it if you need to. We have to pay these criminals in order to do it. And, you know, are they associated with the terrorists? We're paying criminals, right?

Is there legal aspects? Is that even legal, right? So, like, you can't possibly deal with security risk without all of those stakeholders working together and figuring out a policy and a process and how you're going to deal with this. And so, like, the importance of a security council is not just a nice -to -have thing.

It's not like, oh, it would be good if they talked. No, it's, like, existential if you're going to be able to actually deal with these. business -disrupting types of attacks. I mentioned earlier the words matter, right?

That was a big learning about the incident, the compromise, the breach. I picked up some interesting learnings about trust and trustworthiness, because trust is a human feeling about whether or not I'm going to trust you and take your information at face value. But trustworthiness is much more of a technical specific thing that you can actually have measurable attributes of. These are some different things about trustworthiness that then inform that decision of trust by somebody else.

And so that was a really interesting insight I picked up along the way. Oh, this one was really interesting. Going through the SOC one. I didn't realize until we were writing up some of the things that, hey.

Security operations really needs to be part of your architecture review board, your solution review board, whatever you call it when your solutions go through and they get approved to go on the production environment. If you don't have security operations either as a stakeholder there or as represented by an architect that knows about it, they're not going to turn on logs. That's just going to often happen. People skip the logs.

And the interesting thing that we learned there is if you don't turn on the logs, you're signing up for a minimum of two incidents because you're going to have one. You're not going to know what happens. You can't investigate it. And therefore, you know, after you get the very, very sloppy cleanup done, you can't do a root cause analysis to figure out what the heck went wrong and how did they get into that system.

And so you're signing up for a second one after you turn on the logs or enable the logs or turn it on in the code or actually put the logging code into your software. And then you're going to have a second incident where you're actually going to find out what it was. Then you can do the root cause analysis. Then you can block it.

So even if you do everything right when you don't have logs, you're signing up for two incidents. And that one was like a whoa kind of moment, like wow. Logs are really, really important. So those are kind of the big learnings that I picked up.

Yeah, I'm working on some material right now for the red team. And I think I mentioned this before, but when we do a readout of a red team operation, it's amazing how many times there are weaknesses in the log files. Something's not logged, or perhaps there's a column missing in the logs that would have been really interesting, or perhaps there's not a correct alert set up on the logs. One thing that we have, an event is deemed, air quotes, detected when someone is actually alerted to it and responds to it, accepts that they've received it.

So yeah, we found that just simple logging is incredibly beneficial. By logging, I mean like secure logging. So for example, storing logs in perhaps immutable storage or having them shipped off to some kind of monitoring environment so that are away from the actual air quotes, you know, sort of battle zone. Yeah, logging is huge, absolutely huge.

Oh, yeah, and the adversaries love to wipe those, right? Because, I mean, it's just like, you know, they wipe the security cameras and all the, you know, the badge ins and the badge outs of the building for a physical break -in so that people don't know when and how they got in, right? Like, it's the same exact concept. Like, if you don't have a record, you don't know what the heck happened.

But remember, collection is not detection, Mark, which is your favorite phrase. Yeah, and logging off is blindness. And that's why the red team has a very hard definition of if something's been responded to or not detected. It's not just the fact that it's logged, it's the fact that someone was alerted to it and someone actually responded to it.

When you think about the overall industry at large, security and the level of knowledge that we have today about how determined the attackers are. That was not a priority, and we didn't know that much about where the threats would actually go to 20, 30, 40 years ago. So all these systems are built with the assumption that it's a safe internet, right? And so it takes a while to retrofit that stuff back into every system that we designed as a society for the past 20, 30 years, and the people that are doing it, because it's ultimately the people that are coding this stuff.

Yeah, actually talking about coding stuff and alerting and et cetera, et cetera. Under the Secure Future initiative at Microsoft, there's a huge initiative going on to get product groups to focus on using OpenTelemetry or OTEL for their logging infrastructure. And the reason for doing that is that way it's a very well -respected library and format. And it also allows you to log to all sorts of different, and you can change it on the fly without changing code.

So that's actually really cool as well. So yeah, if you're looking at a way of logging in your own applications, then do look at OpenTelemetry. So what do we expect people to use this glossary, all of this for? What's the vision there, Mark?

We're fairly ambitious on this because the number one thing, and it's not the one that's literally written into the standards, but we want to have people have better and more informed conversations. So instead of the CISO sort of being on the defense and being stuck with trying to influence people that don't care and aren't paid to care. We want to see the conversation change where, listen, this is a part of your fiduciary duty and I'm here to help you. Think of me as a subject matter expert to help keep you from going into jail.

I'm your friend to help you here. As opposed to, I'm the scapegoat you're going to fire every 18 to 24 months when something goes wrong. We really want to catalyze that different kind of conversation to a much more healthy, productive conversation. A more professional way of describing that is just doing organizational planning better for those business leaders and technology leaders and security leaders as well.

We want to see people use these to influence how they do the entire life cycle of security jobs, right? Because you want to make sure that you're structuring the jobs that you're going to be hiring people for and as you're creating for, that you're evaluating people of can you as a candidate actually do this? And these are some objective things that you can learn and master and get good at so that the expectations are a lot clearer for candidates and employers, et cetera. And then how are you doing as an employee against?

from a performance -wise, and are you actually meeting what the requirements of the job are? And then if I'm an individual, my career planning, where do I go next after this job, and how do I plan for it, and what skills do I learn? And even if you're doing outsourcing, the jobs to be done don't change, whether it's done by a contractor or done by an external company or an organization. So this gives you a lot of clarity for what...

what am I actually asking for when I'm trying to do an outsourcing contractor? They gave me a proposal. So which jobs are you actually doing and how much of these are you doing? So we were really trying to get to much clearer, much more effective conversations on this.

And then the other thing I've been thinking about a lot lately is as AI comes in and it's starting to be able to automate some tasks, A job is just a collection of functions, right? It's just those responsibilities or accountabilities that you do as a tier one triage analyst or a tier two investigation analyst or a threat hunter or a threat intelligence role or whatever. And so as these things, you know, as you define it, that's the role. And then they have these tasks, right?

Because it's that collection of tasks. But then, I'm sorry. The role is a collection of functions, responsibilities or accountabilities. And so those functions, in order to do them, you need to have and execute a bunch of different tasks, which depend on your organization and your tools and your process and whatever.

What are the tasks to actually investigate are going to be a little different depending on that. And then the AI is what is going to be partially or fully automating the task. So this helps give you a structure that's a little bit clearer that says, at least I know what this person's job is and the functions of it. Then I can say, these are the tasks to do it in our world, in our company.

And then you can say, okay, is AI going to do 10 % of this task, 20 % of this, 60 % of this, 0 % of this, 100 % of this task. And you can make those much more informed decisions because you can put those tasks against. one of those job functions for a role and see, okay, well, this is on average about 12 % impact for AI that they can automate this as opposed to, oh, this looks like something we can just outsource and dump. And so it gives you the ability to have a much more informed and thoughtful and structured conversation.

Now, the standards don't take it down to that task level, but at least you have something to map the tasks in your organization too. And then you can say how much of AI is doing this and do we want to outsource it to AI? Because great, it makes everything faster or do we actually really really want to pay a human to do this because if we lose this institutional knowledge on how to do this we're toast or you know do if we take a human out of the loop then are they going to be making immoral unethical and or um decisions we can't actually defend in a court of law if something goes wrong right like because you need to have a human in there to approve that otherwise why did you trust the computer to do this when it wouldn't when it wouldn't do the same thing every time and so you know we're really looking to help bring a lot of clarity for like both the human side of it, but also like what AI is starting to do to those roles to give it some structure so you can understand that impact and having meaningful structured conversation rather than kind of an ad hoc.

I don't know. It seems like it does what Joe does, right? Like that's not a good way to do stuff. So, Mark, seeing as you are technically our guest this week, we're going to hit you with the...

But I'm not a special guest, as Michael reminded me, by the way. No, you're not a special guest, but you are the guest. So, I'm going to hit you with the questions we hit everyone with, which is, what's a day in the life of Mark like? And you can take them in whichever order you want.

If you had a final thought for the listeners, what would it be? I'm going to be a bit of a rebel and I'm going to take the final thought first because, you know, what the hey, I'm not a special guest, but I am a host normally. The big thing, my final thought on this one is really, I would just ask people to take a look at these. and give us some feedback and think through this and tell us how you would use it.

That's sort of my big thing on this one is that we're really, really interested to see how people are seeing this, how they're going to use it. That's my big thing is we're hoping that this has a significant positive impact in the industry and makes everybody's lives better. But in order to do that, We need folks to read it, to share it, to talk about it, to use it in their conversations at work. And so very, very interested in people's thoughts and feedback on that.

So a day in the life for me is very interesting. I'm sure like every other architect, there isn't one day in the life. It's sort of an aggregate and each day is a little bit or a lot different than the other ones. For me, it's kind of a mix of different things.

There's a lot of different kinds of content creation. So either for my Microsoft day job in the security adoption framework and MCRA and CISO workshop and whatnot, creating content there to help our field help our customers, quite frankly. Sometimes I'm doing some training and readiness events. Sometimes I'm working directly with customers on how do we plan our AI security and whatnot.

I've got a couple of customer engagements coming up on that. So there's a lot of those kind of things. There's the field readiness, the customer direct pieces. There's the working on these standards as well.

And then sometimes mapping to those standards with the Microsoft guidance and whatnot to make sure that we're staying compliant with both, not compliant, but mapping to and aligned with the various different standards from the open group, from CIS, from NIST, et cetera, and helping people connect the dots on that. Just random internal kind of administrative stuff like every job has. I've got some events here and there from the open group and announcing this at the open group conference and whatnot.

So it's just kind of a hodgepodge of different things, all sort of thematically aligned around how do we help customers get better at security and then see how to use Microsoft products to do that. So yeah, it's kind of a day in the life. Very cool. All right, let's wrap this episode up.

As always, we always learn something on each episode. I think what sets this episode apart is we didn't really talk about products, other than in the news. And this is such an important part of the overarching cybersecurity landscape. Certainly when I was in Microsoft Services, I certainly learned a lot about this kind of stuff, basically from customers.

And most people learned it from a lot of the material that you had written. I know that guy. So anyway, let's bring this episode to an end. Again, thank you, Mark, for joining us, even though you were going to be here anyway because you're a co -host.

But hey, you're not a special guest. You're just a guest. I'm just saying that tongue -in -cheek. And to all our listeners out there, we hope you found this episode of interest.

If you'd like to hear more stuff that's not just product -related, let us know. We will go. wherever people want to take us. I mean, if they want to learn certain things, then we will happily cover those topics.

So stay safe and we'll see you next time. Thanks for listening to the Azure Security Podcast. You can find show notes and other resources at our website, azsecuritypodcast .net.

If you have any questions, please find us on Twitter at AzureSecPod. Background music is from ccmixter .com and licensed under the Creative Commons License.