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
130. This week it's just myself, Michael, with
Mark. Mark is here to talk to us about some important
milestones in the Security Adoption Framework,
or SAF. So welcome to the podcast, Mark. So glad
to be here. Turnabout is fair play. So before
we get to your topic of SAF, why don't we take
a little lap around the news? Why don't you kick
things off with your news? Awesome. Yeah, I got
a couple of pieces of news. I did finally just
launch a YouTube channel, so I'm attempting to
enter the world of video. Please be kind and
gentle. And I kicked it off with an episode kind
of talking about all the free resources and all
the stuff that I work on for folks. I think it's
a short 15 or 17 -minute video, something like
that, to get that started. We also did launch
the ZeroTrustPlaybook .com website. It used to
just point to the Amazon website where you can
buy it. But we got some resources and some other
stuff up there. We're going to start blogging
and do some other things there to kind of help
people sort of understand and build on the playbooks
there. And of course, you know, this episode
kind of covers the other big news for me, which
is that security option framework. So I'll let
you get to your news before we jump into that.
So the first item is there is a secure boot update
from the old 2011 to the 2023 certificates for
trusted launch VMs and confidential VMs in Azure.
Even if you don't update the certificates, you
can still use the VMs, you know, still apply
patches, the whole nine yards. But there's things
that we can't do to secure the boot process.
We can't take on any more enhancements to secure
that boot process. So if that's something that's
of interest to you, which it should be, you need
to update to the 2023 root certificate. Just
bear that in mind. Again, obviously, it's going
to be in the show notes. The next one is there
is now an end -to -end toolkit for Azure HSM
scenarios. This is actually pretty cool. It's
up on GitHub, and it's a whole bunch of deployment
templates and migration scripts and validation
tests for the various products that we have on
Azure. that are sort of in the HSM camp. So for
example, managed HSM, Azure Key Vault, and there
are other ones as well. Payments HSM is another
example. So a lot of people think that the hardware
security module stuff that we have in Azure is
just Azure Key Vault. It's actually not true.
There are actually other products that are based
on very specific industries or very specific
scenarios. So it's really good to see that this
is available because it certainly takes a lot
of the mystery out of setting these things up.
All right. Well, let's now turn our attention
to our guest slash co -host, Mark Simons. So
Mark, I know you've been on just about every
single episode since the start, but perhaps some
people have, I'm not going to say forgotten,
but sort of lost track of what you actually do
and what your role is at Microsoft. So why don't
you take a couple of moments and explain that?
I suddenly feel like I'm in the room with the
Bobs in office space. What would you say you
do here? My day job is lead cybersecurity architect
at Microsoft. And so a huge amount of that work
in the past few years has been focused on the
security adoption framework or SAF. And it includes
things like the Microsoft cybersecurity reference
architecture, the MCRA, CISO workshop. Effectively,
the way I describe it to a lot of folks is...
I take a look at all the problems and challenges
that our customers face in security. To start
out, architects, CISOs, engineers, SOC analysts,
etc. And then take a look at all the challenges
they face and all the technology that Microsoft
offers and kind of boil it down to... what do
I need to do? What do I need to know? And so
I build the reference architectures and whatnot
like that and the workshops to kind of guide
through, here's the problems that we see that
challenge you. for security strategy, for security
architecture, et cetera, and then build the references
for that and then build workshops around them
to kind of help people navigate all of the many
different things, the varied things that they
face. And so that's kind of what I do. And it's
mostly been in the past couple of years focused
on workshops that we deliver directly to customers
through the Microsoft Unified. Usually most people
in IT know what a unified formerly premier is,
but most of the security folks may not have a
lot of exposure to it. But we've essentially
been building that library up to make sure that
folks, hey, I need help with this on security.
Sure, we've got a workshop for that. So that's
kind of what I do for a day job. And then I also
do standards work at the open group. And also
have interacted many times with NIST and CSA
and others in the past. And really heavily involved
in the open group to kind of... write and author
and contribute to standards. I'm a security forum
chair over there, which means I help kind of
steward the overall portfolio and set a vision
and, you know, help kind of say, hey, that's
that will be a good one to add to it. And kind
of, you know, this is what I'm thinking, you
know, adjust the charter, etc. And then, you
know, as an author of the book series. So that's
that's kind of what I what I do for a living.
All right, so let's start from the very beginning.
Let's look at the origin story and the intent
around the SAF, the Security Adoption Framework.
What problem were you trying to solve when this
work started? So from the beginning, the first
question that we really set out to answer was
from the MCRA. That was really the first piece
of it. And it was the first basic question of
what the heck do you do in security Microsoft?
And that was the question we kept getting from
customers and that people needed to actually
have the answer to. And so that's really sort
of where the MCRA started. And, you know, the
intent was to not make it just here's a list
of things, but actually a meaningful architecture
that related to what people knew about infrastructure
security and network security and identity security
and all those kind of different pieces, parts.
And so the MCRA was sort of that first kind of
core that we built on. And then over time, you
know, okay, what strategy does this support?
And, you know, do you actually know anything
about security? Microsoft kind of came up a little
bit. And so, you know, that combination of factors
led to, because this was in the early days before,
you know, when we hadn't had products on the
market for a long time. And that combination
of things led to the CISO workshop. And we kind
of... at first viewed those two different things.
But like, you know, so, you know, what strategy,
what outcome, what does the CISO need to think
about for security, et cetera. A lot of those
kind of related questions all kind of, you know,
formed together to create the CISO workshop,
which has gone through a few major revisions
since its origin. And those two kind of components
kind of lived on their own for a bit. And then
over time, as people needed to go deeper into
the SOC and start working on things like the
CDOC tour to Cyber Defense Operations Center
tour to take Microsoft's lessons learned from
what we were doing, we needed a way to do that.
And so we built some decks and some workshops
around that. But then all of a sudden we had
like three, four, five different things. Then
people asked about SDL as things were coming
along, a security development lifecycle that
you had a big part of. And so, you know, over
time, we just realized that, hey, we need to
we need to bring this together in a framework.
And we kind of took a cue from the cloud adoption
framework or CAF and the well -architected framework
or WAF and said, you know, we really do need
a security adoption framework. And so for a while,
we kind of, you know, just hosted some of this
within the cloud adoption framework. But we realized
that, you know, it wasn't just the security of
the cloud. It was actually security as its own
discipline, which was honestly sometimes a bit
more complex than the cloud is. And so that sort
of led to that, and it became a series of workshops,
and we kind of created an overall unifying framework
and brand and whatnot. We were delivering those
for years. And then we told people about it a
little bit, but it was just kind of a basic landing
page. But then this recent release, we actually
took the time. It took me several months to convert
those workshops into. documentation on Learn.
Like, hey, here's the reference strategy. Here's
the reference architectures. Here's how it all
fits together for each of the disciplines to
make it fully complete and in that sort of written
form. And so that's sort of what led us to where
we are today. And we finally just released it
a little bit before we started recording this
podcast. So where does this interact? or cross
paths with zero trust and zero trust adoption.
I've really struggled with that. Like, I'll be
frank, I've not read the SAF stuff all the way
through, but I know that you guys hint at zero
trust all the time. So where do the two intersect?
So that's a really good question. And ultimately
what... What we found is that zero trust, everybody
wants to, well, at least all the marketing and
sales people in our industry, want to package
it up and then sell it as a product, as a license,
as of this, as of that. But at the end of the
day, zero trust is a... fundamentally different
way of looking at security. And it is a transformation
in the real meaning of the word in that you're
taking something that exists the way we've been
doing cybersecurity, you're changing a few foundational
assumptions of it. And the two big assumptions
that change, which are the obvious one of, hey,
everything on the internal network is safe because
there's this network security perimeter, this
boundary that protects all the stuff in it. So
I don't have to worry about data classification
or any of this other stuff. That's hard, right?
And we know that's a bad assumption. And so the
first obvious one that everybody knows about
that changes with Zero Trust is, hey, you have
to protect the assets wherever they are, right?
It doesn't matter if it's sitting out in a cloud
service or if it's on the internal network and
the attackers can use phishing and all these
other ways and credential theft to get through.
Ultimately, you have to protect stuff where it
is. That's the mission. And so it's sort of like
bringing some clarity to that and getting rid
of that old shortcut. And the other one that
we found that was sort of a broken assumption
that Zero Trust addresses is security is a security
team's job. And so that pervades a lot of organizations.
And hey, IT and business people are like, I don't
have to worry about this stuff. I don't have
to worry about security. I'm just going to do
things the way I do. I'm going to focus on productivity.
And if there's an incident, it's security's fault.
set a financial target that leads to no maintenance
windows and you can't patch it in a vulnerable
system, as a business decision, you've just created
organizational risk through security. And so
we have to also reverse that assumption and say
security is part of everyone's job. It's not
everybody's full -time job outside of security,
but it is part of everyone's job to do their
part, just like financial, legal, et cetera.
As employees of any given company, we're not
allowed to do illegal or financially irresponsible
things. We should also not be able to do security
or irresponsible things. And so zero trust, all
it is is taking a fresh look at security through
that lens, and you're going to do a lot of the
same stuff you had before. You're going to do
some new stuff, and you're going to stop doing
some old stuff. And that's all it is, is it's
that approach. And so this, you know, Microsoft,
we have our three or four principles, you know,
the assume compromise, explicitly verify, and
least privilege. Yep. And we're also looking
at adding business enablement. We're not sure
because it's not really a security principle,
but if you don't do business enablement, you're
not going to get very far. So we're kind of discussing
that one as well as a formal fourth principle.
We're not quite sure about that. But all it is
is just looking at that fresh lens. And whether
you use the Microsoft principles, whether you
use the Zero Trust Commandments from the Open
Group, whether you use some of the stuff that
CISA and CSA and whatnot, ultimately they're
all philosophically aligned. But you've just
got to be looking at security through that clear
lens. And that's one of the things that is infused
throughout this framework. We are doing it in
that way. If you're excited about zero trust,
it follows zero trust. If you hate the term because
you've had too much marketing and sales shoved
down your throat, then it's just doing security
right. I don't care as much about the name as
I do about doing security right. When I was in
the field, I would actually hear from some customers
who thought that the notion of zero trust was
marketecture, like it wasn't actually a real
thing. If someone were to say that to you, what
would you say to them? In the early days, they
were probably right. Um, but a lot of work has
been done, you know, and I know the way I approached
it is there's so many broken things about security.
Um, and there were so many truths that were ignored.
Like I remember, uh, you had mentioned one times
in the early days of the STL, you know, Hey,
um, never trust input. All input is evil or something
like that. Right. That's zero trust, right? It's
like, you're not trusting the input. You're explicitly
verifying it. And so we've been doing some version
of it. We just haven't been doing it consistently
well, and we haven't had a name for it. And so
the way I approached it is like, let's embrace
this name because it did start out as marketing
and architecture from one of the analyst firms.
But it's evolved well beyond that into this is
the right way to do security. And so, you know,
you surf the waves that come in, you know, and
it's about let's make this thing mean something
and mean it right. And that's where all the standards
and guidance have really come in and kind of
brought us to this next generation of security.
So Word on the street is that the length of this
documentation is like a small book. So how big
is this thing? So when we converted it to Word
to make it easier for people to do some edits
and track changes and whatnot during the review
and release process, it ended up being about
215 pages, give or take. And that includes some
of the existing privilege access guidance, which
we can convert over into scenarios and some other
things as well and technical solutions. But it
was basically about 185 net new pages. So I kind
of looked back, and I was like, oh, wow, I wrote
a book over the winter. If it is basically a
small book, well, average -sized book, is this
something you can read from the beginning to
the end? Or is this something you sort of jump
around, more like an encyclopedia? It's a little
of both. So the challenge that we see that our
customers face is, one, you need to be complete.
So ideally, you want to be able to read all of
this at some point. But two, what you do based
on that single kind of unified, coherent framework
is different depending on your job. As a SOC
analyst and I'm responding to incidents, that's
very different than a red teamer that's attacking.
That's very different than a GRC person that
is working through and assessing the financial
risk to an organization and whether or not we're
meeting our compliance obligations, etc. And
it's very different than an architect or an engineer
that's designing a control or prioritizing which
ones to do, or a business leader that's trying
to figure out what risk they can accept or not.
And so they all need sort of this foundational
kind of core understanding, but the way that
people use it is very, very, very different.
And so the way that we broke it out is for the
core framework, we broke it into like a business
column on the left, a security column in the
middle. and a technology column on the right.
Because at the end of the day, you know, the
first thing is, is that does the business even
care? Because security, if there were no attackers
and the business didn't care about, you know,
things going down, then we wouldn't have a security
department because why bother? And so right now,
business kind of frames security and the security
leaders often have this implicit promise they
have to keep, which is wrong, which is if there
are breaches, it's the security team's fault.
We're going to fire and replace them with someone
who can stop the breaches. But that's a fantasy
that doesn't exist. And so what do you replace
that with? And that's where the business scenarios
come in. And so that's really what we're kind
of focused on there. And that helps guide the
business leaders. Do I expect the Fortune 500
CEOs to read that? Not necessarily. But can the
CISOs of any organization or business leaders
of smaller organizations read that and then kind
of translate it and bring it out there? And can
the CISO then use that as a way to say, these
are the promises that we're working on. I want
to be able to adopt AI effectively and safely,
et cetera, et cetera. That's kind of the way
that we, that's a core kind of use case, right?
And then the security team would look at the
security disciplines in the middle and the technology
teams would look at the technology on the right.
You know, that's kind of the core piece of it.
And we know that's not enough, right? Because
it's like, okay, this is a reference. This is
my job. Great. What do I do about it? And so
that's where we're taking those business scenarios.
And this is the work that isn't done yet because
we're continuing to do it. Privilege access is
the first one we've done. But I'm going to take
that business scenario and say, okay, what technical
solutions are required to be able to do AI safely
and security, to be able to continuously improve
my security posture and compliance, to be able
to allow people to work safely from anywhere?
to be able to handle a big incident that comes
through? What are the technical solutions that
enable each of those five, six business scenarios?
And so that's what we're working on right now
is defining that and making it actionable so
they can walk that journey through there. And
then, hey, as you do one of them, by the way,
we already did this technical solution, so it's
going to make the next scenario a lot easier
because we've got three out of four of them done.
So we're in the process of doing that. And then,
of course, on the right on the technical piece,
We call them zero -trust pillars, technical pillars,
same thing. It basically says, hey, if I own,
say I'm like an engineer, right? I own all the
identity assets, right? I'm an identity engineer
or architect, and I do that for our operations
team. I do that for a living. That tells me the
controls I need on the right. And so we're trying
to get that narrative story through there. But,
you know, the first thing is you have to have
foundation before you start designing, you know,
what mirror is going to go in the bathroom, if
that makes sense. Okay. I've never heard mirror
in the bathroom, but okay. Actually, isn't that
a song? It's a song from the old reggae song.
Perhaps I should have said sync. Fair enough.
Anyway. Okay. I want to turn a bit cynical at
this point. So look, there's plenty of frameworks
out there from folks like NIST and CISR and so
on. So what gap does this model fill? And probably
more importantly, I mean, does this model complement
or compete or replace these existing frameworks?
Sort of clue me in there. So this absolutely
builds on, connects, and maps to all of those
kind of things. The NIST, the CISA, the MITRE,
all those great standards that are put out by
those organizations. So first and foremost, we
are not trying to replace or displace those.
The challenge that a lot of our customers have
is like, how do I do this in a complete way without
being comprehensive and super detailed? They're
not trying to replicate any of that. But how
do I do this in a complete way that I can then
turn into action? and implementation with Microsoft
technology. And so that's sort of the magic of
this is it kind of gives you that strategy and
architecture layer. Here's a reference strategy.
Here's a reference architecture that supports
and enables it in multiple different ones. And
then here's all the technologies that then make
that real. And then in the future, as we go forward,
here's the solutions that then guide you through
prioritizing which controls you need to have
in case you don't have time to implement all
of them. And so that's sort of... The gap that
we're filling there is we want to definitely
play friendly with all those other ones that
are out there because people have to meet them,
they want to meet them, they've adopted them
voluntarily, etc. And this is really just the
Microsoft perspective on it that fills the gaps
that we see and connects our technology to it.
Because if you take away the technology links,
it is a vendor -neutral framework that kind of
brings all that stuff together. But we wanted
to also take it all the way into here's how to
implement and drive the controls. So as you mentioned
at the beginning, it's a large body of work,
over 200 pages. So can you walk us through the
three core elements that make up the SAF? Absolutely.
So as I mentioned, you know, I have this visual
in my head, you know, on the left. So you'll
have to kind of imagine that if you're driving,
please drive safe. But on the left is those outcomes,
right? This is what we're driving. That's the
I want to be able to do something. I want to
be able to secure the AI and do it safely and
adopt it quickly and, you know, deal with major
incidents when they happen, etc. And so that's
really the first focus. And each of those scenarios
has at least a landing page and often more guidance.
This is the first release, so we will be adding
additional guidance as we go. And so that's that
first piece, which is how do we translate what
security does into business terminology? And
then that middle part, security disciplines,
is, okay, how do we take those business outcomes,
those promises that we made, and turn that into
technical reality? And the example I always like
to use on this one is the difference between
having data security as an outcome versus security
controls that apply to data. Because if I'm trying
to keep data secure wherever it is, I need a
bunch of controls. I need it built into the infrastructure,
to the endpoints, the identity. If I don't do
that and I just have controls in the data itself,
I can't keep that secure if it's on an insecure
device, if the identity that's accessing it is
not secured and locked down, if it's not encrypted
at rest, etc. We have both a data security discipline,
but also a data pillar, along with endpoint and
infrastructure and network and so on. And so
the security disciplines are really about how
do you translate those business promises, those
things that security should be working towards,
into a coherent approach that then uses a bunch
of different controls. And then the technology
pillars are the controls. And we broke those
out by the technologies, very similar to the
CISA Zero Trust pillars. which is data endpoint,
et cetera, and making sure that you have that.
And again, a lot of this, the thing that was
really interesting as we went through this is
just... the many to many mapping. So like, it's
amazing how many technical controls support multiple
different initiatives, support multiple different
outcomes, but you can't just munch them all together.
You're going to get confused and it doesn't make
sense and stuff gets lost. You have to separate.
This is what the tech teams do versus what the
security people kind of steer with the strategy
and architecture versus the outcomes that everyone
is trying to get to. So you touched on sort of
business scenarios there. So how should a CISO
or a business leader actually use this model
in real life? I think the reason why I ask that
is I've often seen a real impedance mismatch
between security and business value and prioritizing
security. thinking about business value and how
it impacts the business. So can you just talk
to that just briefly? Yeah, it's a really challenging
space because business leaders at the end of
the day, they deal with exchange rates. They
deal with geopolitical turmoil. They deal with,
is the Strait of Hormuz going to open? And they
also deal with cybersecurity attacks. They deal
with a whole bunch of different risks and opportunities
because AI presents both. And so they don't see
the world like security people do. And so a big
part of this is to help security people build
that bridge to use those business scenarios.
We even included a whole article on communication
tips and how security people should be communicating
with business leaders to help them frame those
business scenarios and other topics well. We
also see this guidance as helping kind of improve
that communication, help develop that common
language. Because at the end of the day, we're
just humans with two different jobs. And we have
to understand and respect each other's jobs.
But we also have to recognize they're different.
And we have to do some translation. And so that's
a big thing that falls, I'd say, 80 % on security
leaders. But there's also like a 20 % on the
business leaders to understand the basics of
security. And we kind of address some of that
through the open group standards as well. what
are the basics of security for business leaders?
So that's kind of the way we approach that one.
All right, let's get down to some real practicalities.
I'm a brutally practical person. So if someone
were to start with us tomorrow, they've got the
SAF in hand, they may or may not be a manager
slash middle manager slash CISO or something,
or even a developer for that matter, an engineer.
What are the first two or three actions that
people should take? Because there's a lot of
documentation in there. First off, It really
depends on the role you're in, as you kind of
hinted at. And so it's about understanding. And
so we put guidance together for each of the kind
of main role groupings, the business folks versus
the security architects, security operations
center, SOC or SEC ops. You know, we have about,
I think, six or eight groupings, if I recall
correctly off the top of my head, that's in the
role page that basically says, here's your reading
guide. We do want to develop those in the future
releases to be a full landing page to kind of
give you a much more rich experience that is
specific to security operations and SOC, etc.
But in almost all of those, the way we basically
structure it is read up on the discipline you're
in. So if you work in the SOC, you're a threat
hunter, attack simulation, tier one, tier two,
triage investigation analyst, SOC manager, et
cetera, then you need to learn about the SOC
and the mission and the purpose and the other
people in it and all that stuff. And that's what
the security discipline is about. So it's a security
role, learn your security discipline. Technology
role, learn your technology controls and probably
the disciplines that they support. That's kind
of the first main thing is kind of get that context.
And then depending on whatever project is going
on or whatever priority the organization has
in the state that you're in, this is where the
it depends kicks in a lot. So if you're in the
access and identity space or your organization
doesn't have great MFA consistency across the
board, et cetera. then starting there with the
access and identity and the phishing resistance.
That tends to be a very popular one if you haven't
gotten that basic done. SOC -wise, getting an
XDR technology in there and getting clear outcomes,
processes, goals, and metrics. So it really kind
of depends on where you're at, but we do have
a starting point for each of the roles in there.
So I've worked in security for a long time, and
I've seen... Many people underestimate all aspects
of security from the risk to the cost to the
time frame to the work required and everything
in between. So which discipline do you think
organizations underestimate the most? I would
have to say posture management. Because when
you... Imposter management is the left of bang
or preventative version of security operations.
The right of bang is SOC or SecOps. Essentially,
when you look at SOC, it's dealing with the problems
that happen. And then imposter management is
the operational discipline focused on, let's
make sure these problems don't happen. And it's
sort of like the operational arm of governance
or GRC sometimes. It's the progression of vulnerability
management is another way to look at it. We realized
when we released the Azure Security Center, now
Defender for Cloud, the question was, who uses
this tool? And there was a bunch of people that
could use the tool, but who was the primary owner
that drove change in the organization? We're
like, oh, there kind of isn't one. We mostly
have vulnerability management teams that just
scan and send out a shameful report that you
guys suck at this, and then move on and felt
like their job was done. That's kind of the worst
case scenario. And so what we realized is, Security
just was missing an operational discipline on
left of bang. And so we spent some time working
with organizations, picking up the bright spots
of people that had figured this out. They were
active early in the cloud. And we realized that
there was a discipline they were doing called
posture management. And it's really about, hey,
we need to help the technology and other teams
understand. here's the challenges, here's the
prioritization, because these people are busy
keeping things running and they've got other
jobs to do, other thankless jobs to do. And so
how do we make sure that we're making their lives
easier and making it easier for them to do security?
And so that's really what posture management
is. So it's looking at it not just as software
vulnerabilities, but also configuration vulnerabilities.
Because, hey, if someone decided to turn off
encryption or turn off requiring a password or
set a default password, Those are configurations.
Those aren't actually a flaw in the software
themselves. Yes, you can shape that behavior
with the defaults in the software not allowing
those configurations. But at the end of the day,
there was a choice that was made during configuration.
That's a vulnerability. And then how people use
their credentials day to day. This is what led
to Pass the Hash and all the credential theft
stuff that blew up starting in 2008, 9, and 10
and continuing today. If an operator decides
to log in using a domain admin, global enterprise
admin, whatever, to a BYOD device that isn't
secured very well and already is part of a botnet,
then that's an operational decision that led
to it. It's a vulnerability there. And so posture
management, really looking at all those types
of vulnerabilities. And then what do we need
to do to fix it? Are they lacking time? Are they
lacking tools? Are they lacking visibility? What
is it about this? And we love to see people coming
from an IT ops background to graduate into master
management that have a security kind of flair
because that allows them to be able to speak
the language, communicate, understand the challenges,
and then say, how do we get security in here
smoothly? And so that's the one that we see people
underestimating the most because... You can be
great at dealing with the incidents that happen,
but if you spend all your time on that and you're
not trying to block the ones that are happening
all the time, then you're paying a whole lot
of money for SOC analysts and tools to do stuff
that you shouldn't need to do. Stuff always sneaks
through. You always need a good SOC. But you
also don't want to deal with avoidable incidents.
So, yeah, posture management is the big one I'd
say is overlooked. I'll be honest with you, I
didn't even know what posture management was
until five or six years ago. I'm so deep in the
weeds with programming and secure software development
in crypto that I didn't really consider things
like that, but now I do. All right, so let's
ask one final question, then we'll start to bring
this episode to an end. We sort of started off
at the very top talking about zero trust and
me cynically saying, you know, some people have
talked about zero trust being my architecture.
Is there one myth about zero trust that you would
really like to see killed? Yes. So it's been
starting to die off a little bit. But when people
think zero trust is just ZTNA, Very good marketing
on some vendors' parts. The Zero Trust Network
Access, now often called Security Service Edge,
SSE. When people say that that's Zero Trust...
that's the one that sort of really annoys me
because at the end of the day, we did a lot of
work to define, hey, this is the right way of
doing security because we all need it. It doesn't
work that way. And if you treat zero trust as
just that and then say, I'm going back to my
old ways of vulnerability management or this
or that, as opposed to the sort of modern thoughtful
approach that breaks the broken assumptions or
that changes the broken assumptions, it's just
not going to work. Because at the end of the
day, ZTNA and SSE are really just a really good
modern VPN. And it can do so much more than a
classic VPN, but it's not enough. It doesn't
fix the rest of it. So that's the one that I
would wish we could kill, is that believing that
ZTNA is zero trust. It is a part of it, but it
is certainly not the whole thing. Yeah, there
is definitely a lot of confusion I've seen in
the industry about zero trust in general. So
it's good to see something sort of clarify some
of those. Some of those myths. So as you are
very well aware, as we get to the end of an episode,
we always like to ask our guests a couple of
questions. So the first question is, so what
does a typical day in the life of Mark look like?
So a typical day is never a typical day. The
way I work is I generally have one or two big
projects I'm working on. Um, it was like my day
job at Microsoft. Um, in this case, you know,
this year was heavily focused on the, on the
SAF documentation and then, you know, deal with
kind of the, the, the, the hot things that come
up, you know, that, Hey, can you look at this?
Hey, can you prepare this? Hey, can you do this
training or whatever it is? And so it tends to
be kind of like a core base of I'm trying to
focus on getting something longterm done mixed
in with some short term kind of urgent, um, priorities.
And then, you know, On the side, beyond my work
hours is when I do the Zero Trust Playbook and
whatnot, which fits in the long -term strategy
piece. That's generally how I work. It shows
up as a bunch of meetings and focus time and
all that kind of stuff. I try to always be pushing
something big at any given time, despite the
interruptions. Very cool. As you also were very
well aware, the very final question we ask our
guest is, If you had one final thought to leave
our listeners with, what would it be? Other than
buy the playbook? No, just kidding. I would say
read the SAF. You don't have to read the whole
thing, but read the overall intro kind of landing
page. Read to the part that's most applicable
to you, whether it's security operations, whether
it's the business scenarios, because you're in
more of a sort of CISO or security director role.
Or if you're more of a technologist, read through
the technology pillars. But find the thing that
is your part of it. If you do AppSec, it's the
developer security. If you do identity and access,
it's the access and identity discipline. But
read through the parts that are relevant to you.
And honestly, tell us what you think. Is there
questions that come up? And I wish there was
more on this. And if there's like, oh my gosh,
I never thought about it this way. This was super
helpful. Can we have more of these? Any kind
of feedback that you have on that. So just kind
of read through the part that's applicable to
you and tell us what you think and tell us how
to make it better. All right, let's bring this
episode to an end. Again, thank you, Mark, for
coming on the podcast. Thank you for having me.
But no, it's great. I mean, I think the SAF is
such an important set of documentation. I think
a lot of people will get a lot out of it. Again,
to your point, just take a look. Just take a
look. Just jump to the parts that sort of stand
out to you. And if you have any feedback, just
provide it to Mark. So with that, let's bring
our episode to an end. We hope you found this
episode of use. Stay safe and we'll see you next
time. 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.