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.