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 50.
Yes, we've made it to 50 episodes.
Not quite two years,
we have to wait for two more episodes.
But yeah, Episode 50,
this has been a real fun endeavor actually.
We've had a lot of fun,
we had some fantastic guests in the previous episodes.
I really enjoyed doing this and I think based on
the feedback that we get from people who listen,
is doing a good service out there as well.
So yeah, 50 episodes, who would have thought it?
This week, we actually have the full gang here.
It's myself, Michael.
We have Gladys, we have Sarah and Mark.
We don't have a guest this week, it's a little bit different.
Mark is going to talk about
the Microsoft Security Reference Architecture.
Because it's just the four of us,
we actually have no news.
Well, in actual fact, we weren't going to have any news,
but something popped up that I really can't help talking about,
mainly because it's in a product that's near and dear to my heart,
using a feature that is near and dear to my heart.
That is that Cosmos DB now has always encrypted,
is now generally available.
So always encrypted is client-side encryption,
basically the same technology that's used by SQL Server always encrypted.
So the client has the keys,
the encryption and decryption is done at the clients,
you can do a subset of queries against encrypted data without decrypting it.
So you're probably familiar with encryption of data at rest,
encryption of data on the wire,
or this is encryption of data while it's in use.
So it's fantastic technology, I'm a huge fan of it.
It puts no strain on the server at all
because all the crypto is done by the client.
Cosmos DB also doesn't have the keys either.
So in the case of, for example,
heaven forbid but compromise of Cosmos DB or your installation of it,
the attacker doesn't have the keys.
So great to see that, congratulations to the Cosmos DB teams.
And in fact, in a few weeks,
we'll actually have the Cosmos DB folks here to talk in depth
about some of the other stuff that's coming out
as well as talk about the always encrypted.
So now that we've got my little news item out of the way,
let's turn our attention to Mark,
who's going to talk to us about Microsoft Security Reference Architecture,
or otherwise known as the MCRA.
I would say welcome, Mark, but it's kind of not really needed.
So Mark, can you just sort of lead us through
and get us started with MCRA?
So yeah, I want to actually talk about MCRA,
Cyber Reference Architecture,
but also the CAST Secure methodology
because they're kind of two parts of the same whole.
So we've been spending a lot of time in recent months
and quite frankly years working out a lot of the details,
based on working with customers, our own IT organization, etc.
on what does a good end-to-end security program look like
and what does a good end-to-end security architecture look like.
And as it turns out, it's not just one diagram.
So the original version of that reference architecture
probably, I don't know, five, six years ago, the thing started,
you know, it was just a single diagram
that had all of Microsoft's capabilities on it
and kind of how they logically connected together
and grouped together, etc.
And so that's sort of like that core capabilities one,
that one's still there, still getting updated.
And then what we found over time
is what we had to develop sort of,
okay, well, how does the SOC or the security operations team
and all the tools related to XDR and SIM
and threat intelligence and all that,
how did those all connect with SOAR and UEBA
and all those kind of things.
SOAR is Security Orchestration, Automation and Remediation,
and UEBA is Behavior Analytics,
User and Entity Behavior Analytics.
But like, how does all that work together?
How does modern user access using Xerotrust principles,
how does that all connect together?
And what are all the native security capabilities in Azure?
So we ended up answering a lot of questions
with what became a bunch of complicated diagrams.
And so the Cyber Security Reference Architectures
is actually plural, sometimes forget to say the S,
with a bunch of those diagrams pulled together
and a few other kind of key highlights.
And then the CAF Secure Methodology is sort of that,
slightly higher level, that's more of like a CIO, CISO,
and directs kind of look at the world,
as opposed to sort of an architect, technical manager,
technical director kind of view.
So the CAF Secure Methodology is really about that,
what does an end-to-end security program look like
and how does it plug into the bigger picture business
and cloud adoption and digital transformation,
all the other stuff that's happening
that security is trying to keep up with and keep safe.
So I've read quite a, over the years,
read quite a bit of the MCRA documentation.
So what was the genesis of this?
I mean, how did it get started and how do people use it?
That's actually a little bit of a funny story.
So Ann Johnson, huge fan of hers,
and she was my boss at the time,
was speaking in front of a big portion of our field
at one of our sort of get-together internal conference events.
And she, well, she was talking,
she said, see that person over there, Mark Simos,
waved, and she's like,
he's going to build a cybersecurity reference architecture
that will show how all our security technology
works and connects with everything that y'all are working with.
And I'm like taking a note.
And so that was sort of the genesis of it.
And it ultimately answered that first most important question
as Microsoft built and got on this crazy train of cybersecurity
and the massive portfolio that we've built up since.
I think we put like a billion a year into it historically,
and we're looking to put another $5 billion in the next,
no, $20 billion over the next five years, or something like that.
Anyway, it's multiple billions of dollars of investment a year.
It's insane.
But the first question that answered at the beginning of that
is like, what do we have?
Right? And like, what does that actually look like?
And what are the different capabilities that are in there?
How do they relate?
And so that was really sort of the genesis of it,
is answering that question.
And then more questions came up over time.
So I've been watching several of the videos,
and there's a lot of interesting information in there.
Can you list some of the topics addressed?
Oh, yeah.
So the MCRA, for those that haven't seen it,
is kind of, there's like a main menu slide
with using PowerPoint zooms in the first two slides.
So there's two different pages of kind of these interactive things
you can click on.
And so what we did is we decided that each of those sections
they point to, one to three slides,
one to five slides kind of thing.
We were going to record a video around each of those.
Those are the MCRA videos.
And so we cover, let's see, what are the top ones?
There's the big one in the middle is the people.
So that's like, what are the roles and responsibilities?
How were those evolving in today's world?
In terms of what are the jobs and how are they changing?
And we got the new kind of thing emerging of posture management
that's super important.
That really complements the sock on sort of an operational function
of security, but focused on prevention rather than focused on reaction,
detect, respond, recover kind of things.
And so kind of talking about that and the roles and how does security
fit within DevOps and OT and all these other things.
So the people one is definitely one of the more popular ones.
The capabilities one, the original one,
zero trust user access is a big one.
Using Azure AD conditional access,
how do we achieve that sort of zero trust approach
to validating devices, validating users before giving you
access to those highly valuable resources?
Azure native controls is a big popular one there.
That kind of covers all of the different stuff in there
that is built in Azure.
And then the other things that also help secure your access to Azure,
the workstations you use, the accounts you use, etc.
There's one on the multi-cloud and cross-platform.
So like a lot of people think Microsoft just secures Microsoft.
And that's not the case.
We secure AWS, GCP, Linux, you name it.
I mean, we're a security company period.
And so kind of highlighting that.
Sassy, a lot of people have been asking a lot of questions about Sassy.
What is it? How does it fit? How does it compare to zero trust?
OT, how do I secure my operational technology,
my industrial control systems or ICS?
Scatter type of technology, security operations I mentioned earlier.
And then we have some other ones that we threw some other diagrams in there
that people tend to like around how our threat intelligence works,
how the different SOC tools and components connect,
how the SOC components actually,
you know, security operations components actually integrate with access control.
So you can make sure people don't log in and get access to valuable resources
when their device is infected.
A little bit of the privilege access story to, you know,
that's super important to protect the admins, ransomware,
which is just devastating and highly profitable.
It keeps growing because of that.
And, you know, the whole zero trust piece around,
you know, the rapid deminitization plan, what do I do first, next, later?
What does that look like architecturally?
So there's a bunch of different sequences there.
I always love the people and process portion that you have in there.
And I always amaze how many organizations
maybe address the people through training, but they don't address the process.
Do you want to talk a little bit about this and how it changes
when modernization is happening in a continuous basis?
The thing that I've seen is because, you know,
security has always been sort of a technical discipline
or it started out as one, you know, there's a lot of technologists,
a lot of people that just think in the frame of technology, right?
You know, it's a problem, so therefore I'm going to apply a technical
solution. It's that old proverb of, if I have a hammer,
then every problem looks like a nail.
But, you know, we have that challenge because, you know,
people are just familiar with the trend on technology they're recruited for
and hired based on their technical skills.
So we have this like massive technology bias in the security industry.
But the truth is we're protecting systems that, you know,
ultimately they're run by people.
The value that they bring is to people.
You know, that's what we're doing.
The value that they bring is to people. You know, that's what the business is there
is to serving customers that are choosing to pay.
So there's a lot of people involved in the process.
I mean, you even look at, you know, the role of cybersecurity and,
and like geopolitics and whatnot, you know, ultimately that's a very
people-centric discipline of politics, right?
Like, I mean, just people is just woven throughout it.
And so, you know, we've, for us to sort of succeed, you know,
we can't be applying a technical solution to a process problem
or a people problem.
We have to be applying the right solution, the right problem,
and we have to make sure that the teams, the security people on the teams,
are getting what they need.
And they have the process to work together.
I mean, almost all the organizations that I've worked with,
if they're not now, they were, you know, within the past probably three to five years,
broken into a bunch of individual silos,
and they have no processes to communicate across them.
Yeah, we've seen a lot of people that get a lot of value out of that sort of,
you know, this is how the roles are changing.
Well, I've actually heard a bunch of stories from some of our folks in the field
that, you know, they use that single people slide and end up talking with the CIO
and CISO about strategy and people and roles for like two hours and never looked at the
technology and never talked about a single Microsoft product.
Just to, you know, just because that was what the organization needed was to help overcome that bias.
I know that you recorded some of those videos like six months ago,
but I always remember the video talking about the people in process,
where you were mentioning about accountability and embedding security,
because that enables the processes to be updated.
Do you want to talk a little bit more about that?
We ended up doing two versions, I think two versions of videos for those sort of people things.
One was for more of a technology audience in the MCRA one, and then we had,
we covered those slides in a slightly different view at that, you know, full-on strategic level.
That's more of like CIO or CISO's sort of level.
And so we ended up covering that same slide in two very different ways,
not very different, but overlapping, but different from the,
what language we used, etc.
Yeah, we found that it was, it's really critical to understand, you know, at the very top of it,
we talk about, you know, ultimately, this is a risk, right?
Security is a risk.
It's something that, you know, the board management are used to managing risks
and overseeing risk management, right?
And so that's really the root of all of this,
and that's the huge frame that we should all be thinking about is,
you know, what's important to the organization,
and what are the risks that the organization faces.
And we don't want to be coming at them, you know,
these people that manage risks all the time, right?
And coming at them with a whole different language,
a whole different way of doing things,
and just expect them to magically understand it.
The best thing for us to do as security professionals is learn
what risk management framework they're using,
what language they're using,
how do they assess risks?
Is it, you know, a certain scoring system,
or is it, you know, entered into a risk register
when it's officially then managed and accountable
by the management team, etc.
Like understanding that as a senior security leader is critical.
So you can plug into those processes,
and then all of a sudden the funding, the attention, etc.,
that you need for security starts to magically appear
because it is, you know, being managed like any other risk
in the organization that people know how to manage.
But really kind of having that language of translation we found
is super critical,
and that's something that we emphasized a lot
in the CAF secure videos to make sure that people understand,
hey, listen, this is unique in a special discipline,
but it's also a risk discipline
that needs to be managed similar to how people are trained
and used to and have processes and have funding to manage.
Just on that topic of funding, I mean, is the,
I'm not going to say is the guidance around how to get funding,
but is there sort of hints and tips on how you can use this
to explain, you know, how you can get funding for security programs?
Yeah, I mean, I think the start of it is speaking the language
of the people that control the purse strings is the first rule, right?
So that you understand them and what's on their plate
and what's important to them.
And, you know, second, that you can speak to them in that language
and communicate your ideas and your concerns
in a way that they'll understand.
That's the number one thing we found
is really learning that language, learning the dynamics,
learning the risks and priorities.
That is the number one piece.
And of course, building the relationships, etc.,
because, you know, people make decisions.
And so that's it. And when we talk to CISOs,
oftentimes getting money actually isn't that hard.
It's feeling confident that they could spend the money
and then deliver on the results that come tied to that money.
Tends to be a concern that we hear pretty often
that like if they ask for money, they're going to get it
in today's environment anyway, you know, times could change.
Well, it definitely wasn't that way 10 years ago, 15 years ago.
You know, that's one of the key things
is sort of foundationally establish that.
And some of the advice that we do give to sort of, you know,
CISOs and sort of the folks around them
and the business leaders around them is, you know,
start thinking about how do you make sure
that you're not actually distracting the security team
with ongoing requests for funding?
Like how do you make sure that their budget is steady?
And the paradigm that we sort of think of this through
is like maintenance.
Like we don't, you know, if I managed a fleet of planes or cars,
I'm going to have downtime.
I'm going to expect that I have to go and do maintenance
and check things and change the oil
and all the various other things on it.
And that's just a part of owning it.
And technology is actually quite similar.
Like we need to be able to have some planned downtime
in the schedule to patch it and to take care of those things
because if you ignore it, sooner or later,
it's going to break down, it's going to hurt.
And that's pretty much the same dynamic we see in security
is if you don't patch for, you know, months on end,
it's just like not changing the oil.
Sooner or later, the system is going to break down,
you're going to get owned, and it's going to all happen suddenly.
And then all of a sudden, your schedule is disrupted anyway.
So it's much better to sort of proactively plan that
and integrate that in to your schedules,
your budgets and all that.
And so that's one of the ways that we're sort of recommending
that organizations think about it.
So Mark, well, you and I both know that a couple of years ago,
we spent some time doing the security compass,
which was, oh yeah, that was Paul Mark,
Paul Mark had to spend like two days recording with me.
But, so if people looked at that from a few years ago
and they were to ask the question, how is this different?
And why should I go and have a look at the CAF?
What would you tell them?
What is the distinction between those two pieces of work
that you did?
The Azure Security Compass, which is a name we actually don't use,
I think the official website is now called
the Microsoft Security Best Practices.
That was a look at how do we establish very clear best practices.
The main burning concern at the time, the burning question,
was how do I secure my Azure infrastructure and resources?
And so that was sort of like that first structured view
of how do we do that as sort of like a standalone,
you know, multi-module workshop.
That really sort of answered that question
with a very heavy bias towards the Azure resources.
The thing that's changed in addition to sort of the wisdom
and knowledge and understanding that we've picked up since
is the CAF is much more focused on an end-to-end view
of the entire security program.
So it's not really cut down for just the things
that affect your Azure infrastructure.
It's actually focused on, you know,
how do you actually structure your program right?
What are the security disciplines, you know,
your programs of record that you're going to run over,
you know, the course of multiple years on possibly decades?
And, you know, so it's really answering that programmatic
question from the CAF.
We are actually in the process that's, you know,
taking a while of sort of refreshing that.
And so we're taking a look at how do we, you know,
have a deeper end-to-end view,
because, you know, the Azure Security Compass
got pretty detailed on the technology.
How do we do that sort of on an end-to-end workshop basis?
And so we're actually looking at that now,
kind of framed out using that CAF structure.
In the CAF itself, the disciplines are actually aligned
to the open group.
And how, and the open group is where Jericho Form started,
actually defined the UNIX standards back in the day.
But it's an open standards organization.
And so we borrowed the Zero Trust Security components
from them, because the way that it approached it
was actually, you know, one of the most useful ways
to sort of structure that.
And so that's really, you know, that sort of end-to-end program view.
And just for full disclosure, I am a co-chair
of the Zero Trust Architecture Forum at the Open Group,
just so that folks know.
Pretty easy to understand how those ideas were found
on either side of the world.
So one thing we hear a lot about
is SASE Secure Access Service Edge and Zero Trust.
So how does all of this relate to those two,
let's just call them initiatives?
Let me start by framing out Zero Trust,
because there's like two different perceptions
that we've seen out in the world at large of Zero Trust.
One is that it's modernizing your access control.
If you ask an identity person, it's going to be identity-centric.
If you ask a network person, it's going to be network-centric.
But, you know, there's a whole set of people
that think of Zero Trust in terms of, you know,
how do I modernize access control using either a heavy network
or a heavy identity or combination of technologies.
And then the other, you know, 40 or 60%, depending on how you measure it,
folks are sort of look at Zero Trust as an end-to-end security strategy
that has multiple different components,
including access control, security operations,
data center modernization, OT security, and, you know,
all those kind of pieces.
And so Microsoft is very much a proponent of Zero Trust
as a larger big picture strategy.
And the reason for that is that the same things that cause this modernization
of access control like, hey, we can't count on the perimeter,
you know, phishing attacks and cloud stuff outside the perimeter
and mobile devices outside the perimeter and work from home
and all this other kind of stuff,
all those same forces that are making us go, oh my gosh,
I need to reestablish access control in a way that works outside my perimeter.
All that stuff is also influencing how we do.
Security operations, I have to detect attacks and respond and recover
to them outside the perimeter or inside the perimeter.
I have to be able to do all these other kinds of things inside and outside.
So the same forces are also transforming pretty much all of security.
And of course, the, you know, SaaS services and the cloud tools,
based security tools.
So, you know, all these forces are basically doing that.
And so that led us to say, you know, Zero Trust is more than just access control.
It's the whole kit and caboodle.
So SaaSy is a very similar thing.
And a lot of people sort of think of them as the same or similar.
But over the, you know, it started out fairly high level.
But what we've seen is that it started to come into focus in the past six to 12 months
as Gartner has released more and more guidance on it
and more and more products are, you know, sort of kind of aligning to it.
It's become more clear what SaaSy is.
The way that we're seeing SaaSy evolve is it tends to be aligned much more closer
to that access control use case.
And it tends to be very focused on the network pieces, especially as they relate to identity.
Because the service edge, the way that SaaSy names it there as a service edge
is basically the edge of your enterprise, the edge of your technical estate.
We used to call it the edge of the network, but you know, it's, you know,
what we have is no longer defined by network.
So I called it a technical state for lack of a better term.
And so that service edge essentially is what SaaSy focuses on, you know,
sort of from a cloud, a CASB perspective, from the physical networks,
like a secure web gateway and firewalls, a service perspective,
all these different types of technologies, you know, that define your,
the edge of what you control and own and care about.
It's basically how do we make sure they're secure access to it, you know,
that people can have a good performance for it, you know,
and they can, you know, get it, it's cashed around the world.
They include SD-WAN, a software defined wide area network as part of SaaSy.
But also how do you do it securely through those, you know,
security capabilities, like I mentioned.
So SaaSy tends to be on the security side of subset.
It goes beyond security because it includes performance as well.
And that sort of, you know, the WAN based kind of things that would not normally be,
you know, sort of a CISO or Zerotrust responsibility.
But that's kind of where it fits is it's that, you know, how do I secure access control with this,
you know, heavy focus on, you know, wherever your edge happens to be network or otherwise.
Does that make sense?
It does.
And this is going to sound like a really cynical response.
But I mean, how long does it take to sort of get all this?
Like to understand it, understand that big picture and like,
okay, SaaSy's over here and Zerotrust over here and MCRA is over here.
And here's what the Venn diagram looks like.
And here are the tools that map into each of those areas and here's research that's come from
Forrester and Gartner and here's research that's come from Microsoft and here's stuff that's
groundbreaking from Cisco.
I mean, how long does it take to get to understand that?
I mean, is there a place that you can go that's like the, you know, this stuff,
the security stuff 101 to sort of understand?
Like there's so much and there's so much information.
And I mean, do we feel like people understand this stuff?
I know it sounds really cynical, but I sort of want to look at it from a really practical
and pragmatic perspective.
It's a really good question and it's tricky because there's so much to it.
And quite frankly, there's so much money in our industry that everybody's trying to
claim a piece of it and own sort of part of that intellectual space by framing it out
in a way that favors them.
And this is everybody from, you know, product vendors and marketing to analysts,
houses to, I mean, everybody is trying to help with this because it's a serious problem
because security itself is complicated.
And then everybody's trying to simplify it in a way that favors them.
And so you end up having this sort of too many simplifications thing that ends up creating
more complexity in the middle.
So one of the things that we did do to try and help combat this is there's actually kind
of a third type of recording that we did around the MCRAs.
We didn't do it for every single module, but we did, I think two or three of them.
We'll include the links in the show notes where we deliberately focus the talk track
on someone new to industry.
So that would be easy for them to understand like, so say I'm an IT person, that's a career
changer or I'm learning about technology and security because I want to be in the cyber
security, you know, high pay band.
So we actually recorded some of those and they're called interactive guides.
And they're sort of, you know, like an online computer based training type of thing where
you can click, you know, between each section and go back and all that kind of stuff.
So we'll include a link to those because we actually tried to tackle some of that.
I think we started with the people, the capabilities and then one other, I've forgotten
which one, just to sort of make it a little bit easier for non geeks like us to sort of
ramp up on it.
Yeah, I think, again, I've already mentioned this, but it looks quite a bit of the
documentation over the last few months.
It's fantastic stuff.
But at the end of the day, you've sort of got a grok it, you know, you have to understand,
okay, how do I apply this?
Yep.
Great documentation is can be fantastic, but if it is not actionable, then basically worthless.
And that's actually where we did a lot of investment into the ramp.
So the rapid modernization plan, because we recognize that dynamic and we want people to
have that sort of, okay, I just want to implement, right?
Because that's one way to simplify it down.
And, you know, said, okay, do this first, then this, then this, and then your second stage is
this, and there's two steps in it.
Your third stage has three steps in it.
And just basically go do this.
And then we're in the process of actually documenting each of those initiatives with
very specific, hey, if you're doing it with Microsoft technology, here's exactly how to do it
and walk through that on our docs page.
So we're in the process of actually turning that zero trust ramp into basically documentation
that says, okay, let's just, here's how to do it.
And that cuts through a lot of the noise.
So you have all the context, which is great, but here's what to do.
I agree with Michael was saying on the complexity.
And when I look back, many customers in the past used to look or acquire functionality
and infrastructure to address a particular issue in the environment.
And unfortunately, when this confusion with SASE, with zero trust, people start thinking,
okay, do I have to invest on different infrastructure to deal with each one of these?
And this you could see it because people, when they talk about ransomware, they think that
is something different than every other attack out there.
Yes, there's a few things that are different, but not necessarily
start a different way than other type of attacks.
Do you want to comment a little bit about this?
Yeah, absolutely.
Yeah, the easiest answer to ransomware, I always start with this because it helps
create clarity really fast is defending against ransomware is pretty much the same as defending
it against anything else, because ultimately the attackers will do anything to be able to
ransom you technically.
They don't really care.
They've copied techniques from the APTs of credential theft and past the hash and past
the ticket and past the everything else.
The phishing techniques, they've created a few new ones that tend to be in hallmark of ransomware,
like buying up commodity malware access, essentially taking a botnet or some other
low-grade attack infection, and then buying access to that and then using that as an entry
point for ransomware.
But pretty much ransomware is just as flexible as an APT would be because they're just trying
to get control of the environment.
They're just making money in a different way.
They're not stealing secrets or stealing data.
Sometimes they are, but they're extorting you by turning your systems off and saying,
you can't get back to them without paying me.
And that also illustrates the root of the complexity is at the end of the day,
security is trying to stop an intelligent human from finding a crack in your system.
Because they're an intelligent human, they're going to find something in your complex
technical estate somewhere, unpatch this, misconfigured that, poor operational practice,
along with the main admin to an unsecure box, whatever.
They're going to find something and abuse it.
And you have to basically continually be burning down the risks in this huge 30-plus-year-old
technical estate that was built when security wasn't even important.
And so the reality is, security is by its nature very complicated,
and it's forcing us to clean up the hygiene of IT that's been building up and lingering for decades.
Sorry, I'm not sure if I answered the question.
I kind of wanted off there for a bit.
Actually, I like what you were mentioning, trying to stop.
The other day, I was having a conversation with somebody about the definition of security.
For them, when they were saying, okay, this infrastructure is secure,
for them, it meant that nothing could penetrate it.
And I was like, I think the focus of Microsoft is what we said,
assume compromise, detect fast and recover fast.
Right?
So I like the fact that you mentioned about us trying to stop.
But the main thing that I was trying to convey in the previous question is that,
for the most part, the infrastructure used for ransomware, for zero trust, for
suck modernization is almost the same.
There's some capability that maybe SASE uses that is different from zero trust,
but it's not a complete separate infrastructure.
As long as organizations start interconnecting and working in a
some compromise type of approach, detect fast, recover fast,
I think they're able to deal with many of these security issues that all these
SASE, zero trust, et cetera, are trying to deal with.
Yeah, that's actually an excellent point.
And that's a homework of Microsoft's approach, because we're not a,
here's one simple tool that can assemble one simple problem.
And it's all simple until you actually combine it with all your other simple tools.
And then you have a hundred simple tools and it's not simple anymore.
You know, we're actually doing that hard engineering work to, you know what,
instead of giving you six or eight or 10 different types of detection tools,
we're going to give you, we're going to do those kinds of six or eight or 10 or 12
different detections, but we're going to put it in one or two portals, right?
We're going to consolidate that and we're going to connect in, we're going to link it.
So you don't have to do that work.
You can just turn the tools on and go.
And we're going to connect it to your Azure AD and then you can just use that and go.
You know, there's a lot to it because we're kind of explaining how it all works.
You know, a lot of technical people want to understand that.
But the actual operation execution is a huge focus for us to simplify it Microsoft.
Because we don't want people to have to do, you know, we have what,
tens of thousands, hundreds of thousands of customers or whatever it is.
We don't want 10 or 100,000 different individual analysts and engineers having to figure out
how to do the same manual task.
We want to do that once, automate it, and then our entire customer base can benefit from it.
And so that's a huge, huge focus to help make it simpler and easier.
A huge reason why we invest so much is to try and solve those problems and solve them once.
So that goes directly to a question.
I have seen a lot of organizations trying to develop a solution to share threat intelligence.
And I think they're missing the point that Microsoft is already having one of the best
and most complete threat intelligence information out there.
And we are reusing it to simplify detection response to the different attacks.
Can you comment a little bit more about that?
Oh yeah, 100%.
I saw some studies out there.
I don't remember where they were that effectively when you go and take all these different paid
intelligence feeds and this, that, and the other, you always end up with a lot of overlap.
You kind of have a diminishing returns as you get these new different sources out there
from different vendors and whatnot, because they end up reusing the same sources behind
the scenes, et cetera.
And so that's sort of like one of the dynamics a lot of customers are facing.
And of course, it's very difficult to integrate multiple different feeds to a lot of different
tools, et cetera.
And so that's a good example of where Microsoft has invested to kind of make that problem
go away.
We get 24 trillion signals a day, I think is the latest statistic.
Yeah, somewhere around that.
And then of course, we do all the machine learning and reasoning over and this and that,
turn that into like normalized baselines and the other anomalies that stick out and behavior
analytics that say these are the behavior anomalies that stick out, et cetera.
But ultimately, we have a massive set of threat intelligence that's built right into
the tools.
Like you don't have to manage it, you don't have to integrate it, you don't have to configure
it, it's just there.
And that's one of the things that we do is build that in there.
So it's sort of like an ambient set of knowledge that's just built in to all the tools and
then you don't have to go through that.
Every organization has unique needs, right?
So if you're in FinServe, maybe the generic threat intelligence, once you sort of integrate
that in or use our tools, okay, that's fine and good, but I need to get to maturity level
four.
I'm at three and you got me to three easily, great.
But now I need four.
There's always going to be a need for sort of localized stuff, what you've been attacked
with, what your industry has been attacked with that might not be the exact same thing
as every other industry out there.
So there's always going to be sort of a little bit of uniqueness, sort of the, I sort of jokingly
say it's like the frosting on the cake that says happy birthday, Bobby.
Most of the cake is identical to every kid's cake, but this one says happy birthday, Bobby.
So there is a genuine need to do some personalization on threat intelligence, but the bulk of it
is going to end up being fairly common across companies, industries, et cetera.
And so we've done a lot of work at Microsoft to kind of make that problem go away and make
the bulk of the problem go away.
So that's an excellent point.
Yeah, I like the sample that you showed in the threat intelligence and CRA video.
I don't remember which attack you used, but it was some...
Emotet, if I recall correctly.
Yes.
So somebody got an email with the Emotet and they didn't even realize it because the
threat intelligence was using the backend to perform a lot of different investigations
and response.
This is the value that we're providing with embedded threat intelligence and signals from
cross services.
So I was happy about that.
Oh yeah.
It's such a powerful story.
I mean, we can't do this every time to every single thing, but we basically, the first
variant that existed of this particular trojan.
It was a Gmail on a Windows app.
So it was like right at the edge of sort of the stuff.
It wasn't even the enterprise things, but we picked it up, did the ML, the detonation,
et cetera, and deleted it before the person could ever run it within 400 milliseconds.
And so this person was automatically protected, didn't even get interrupted, and they were
the would be victim of the very first victim of this brand new variant of a banking trojan,
but the ML and all that just took care of it automatically.
And I'm like, that is the pinnacle of where we're trying to get to in as many scenarios
as we can.
So I have to ask, just because of my background, is there a sort of a secure software development
aspect to any of this?
Yes.
So within the MCRA, it's a little bit of a limited exposure.
We've got the STL links and all those kind of things.
We've got the GitHub Advanced Security highlighted in a couple of places.
So there's definitely some mentions within the cyber reference architecture, but the
thing about the DevSecOps and security development lifecycle sort of space is it tends to be
very heavy on people in process.
There's definitely tools involved 100%, but there's a lot of people in process and training
and awareness elements of it.
And so what we actually did in the CAF secure methodology, because there's five security
disciplines, access control, security operations, asset protection, security governance, and
then the last one is innovation security.
We named it innovation security instead of DevSecOps on purpose because we also want to
be able to accommodate the emerging, not, we want to be able to accommodate not only
DevSecOps, but also the emerging discipline of citizen developers, things like PowerApps
and low code, no code types of apps that are really starting to ramp up in volume.
They're small, but they're growing very quickly.
And so what we did there is we actually put in two different pages in the CAF secure methodology.
The first one is innovation security, what it is, how it works, really highlighting that
we need to bring together the different teams.
We need the business and the developer folks.
We need to bring the ops together, that your DevOps kind of combo.
But we also need to have that safety and security built in as well.
It's like having a car without seatbelts or brakes.
You're not going to drive it very fast.
You want to have that assurance and that comfort of safety and of course the reality of it as
well to feel comfortable to have that speed and agility to go and capture new business
opportunities, et cetera.
So we built innovation security, kind of focus on those kind of key themes.
And when you do the security, don't just think about developer and developer processes, which
most APSEC people will think of.
And don't just think about infrastructure and the actual build servers and the workstations
and all that, that an infrastructure security person would think about, but think about
both of them.
And so we introduced a lot of themes like that and addressed a lot of those elements
there and how do you sort of bring all the goodness of the SDL and SDLC type of things
into the age and speed of DevSecOps.
And so that's the first page.
And then the second page, we focused on specifically what kinds of technical controls to put into
your DevSecOps process to sort of support those principles and those high level ideals.
And we actually worked closely with Victoria Almazova, a very talented person that has
been working on DevSecOps for a long time and she heavily contributed in that section as
well.
Funny you should mention about DevSecOps and infrastructure people and what have you.
One thing I've been doing a lot recently with customers is talking to them.
And this isn't really security related, but just something I think is really important
is talking to customers about their ops people understanding CI CD pipeline tooling.
So for example, I've been giving me a lot of chats to IT folks about Visual Studio Code
and infrastructure is code and using as your DevOps or GitHub.
All of a sudden they've got these new words added to their lexicon around pull request
and diff and all that sort of stuff and pipelines.
And the joke is, we're sort of talking about tooling that is very familiar to developers
that may be relatively new to IT folks, but you've got to know it.
And if you don't know how to feel comfortable in front of Visual Studio Code, for example,
integrating with GitHub, making edits to Terraform files or ARM templates or Bicep files and
creating a pull request, you kind of have to know all that stuff.
Again, it's not really security related, but this is a great example, this intersection
of dev and ops.
We're adding second there for security.
So yeah, I've been spending a lot of time with customers talking about that sort of
stuff of light.
Yeah, it affects security as well because security can't function unless they understand
the process as they're trying to secure.
The last thing you want to do is say, okay, we patched the server, well, great, the CI
CT process just went and unpatched it automatically on the next build.
You don't want to be in that situation.
And so it's really important to sort of understand and embrace it.
I've learned that the DevSecOps space is almost like a microcosm of everything else you have
to do in the security program, just focused on a workload at a time at high speed, kind
of learning that environment around you and applying the principles, everything from the
app sec to the infrastructure elements and the identity and access control and the monitoring,
all that stuff applies to the DevSecOps space in miniature at speed.
And so it's a really fascinating space.
Yeah, I love it.
Again, these are the tools that I'm used to using for a long time.
And a lot of IT folks are kind of a little bit scared when all of a sudden they're sitting
in front of Visual Studio Code with a whole bunch of infrastructures carried in front
of them and they don't understand how to do things like pull requests and that sort of
stuff.
Yeah, I actually had a personal version of that because I've been doing a lot more work
in the doc site lately, right?
And so our doc site, for those that don't know, Microsoft is actually built on GitHub.
And so we have pull requests and all those kind of things and branches and repos and
all that.
And I had to learn at least the basics of that, which is very over complicated in my
opinion.
But I had to learn the basics of that just to be able to sort of edit and do docs work
and get some stuff into CAF and the MCRA site and all these others.
And by the way, for those that don't know, anyone can submit docs changes at Microsoft.
So if you find something that's wrong or you want to add something, you can just hit
the little pencil edit icon and do that.
But yeah, I live that experience.
Yeah, actually, you bring up a really important point there.
Docs.Microsoft.com, like you say, is all hosted in GitHub.
If you see an error, just go in and just either A, create an issue that can be tracked, or
actually go and make the edit yourself and create a pull request and someone can review
it.
I'm always making edits to docs.Microsoft.com, especially when any of the documentation like
refers to sort of cryptographic elements like SSL rather than TLS or they're using a certificate
for signing because you don't use a certificate for signing, you use the private key for signing.
Just silly things like that.
I mean, it may seem silly, but little things like that just make the documents better.
So yeah, that's an interesting point.
I didn't even think about that, the fact that you probably have this little baptism of fire
as well.
Yeah.
And as an architect, I was extremely frustrated.
I'm like, my God, there's a simpler way of doing this.
Well, there is.
No, there is, but it's not as tightly controlled.
That's the problem.
You want to make sure that the right edits are being made by the right people and stuff
to make sure it's true.
It has to go to the nth degree of detail.
Yeah, you're right.
I mean, but it just, I'm like, can I get a simpler version of GitHub, like just overlaid
where you don't expose all the complexity, please?
No.
So I know I don't need to tell you this, but every time we do a podcast, we always ask,
do you have a final thought?
So what would your final thought here you'd like to leave our listeners with?
The big thing I would recommend is don't get too intimidated by the complexity and also
make sure to take advantage of all the sort of supporting elements within the cyber reference
architecture and the CAF secure that we put in there.
We've documented a lot of this and the reasoning for it.
So take the time to read through that.
The slide deck itself, there's, we talked about in the videos that are associated with
it for the MCRA as well as for the CAF secure methodology.
There are extensive slide notes within the MCRA and you can also hover over all the different
product names and different boxes all over the slide deck.
And it's got a little short description of what the heck the thing is.
So it's definitely a good learning tool there.
So don't get too intimidated by it and just take your time, learn it one piece of a time.
And if you get any feedback, happy to take it.
I'm out there on Twitter and LinkedIn, pretty easy to find with a fairly unique name.
Yeah, I think that's a really good point.
When I was, in fact, whenever I'm consuming any kind of large amounts of data or documentation,
same with the MCRA, I'll set aside like an hour a day and just bite off an hour and then
next day bite off another 45 minutes, next day bite off 50 minutes, you know, that's
the old handage, right?
It's like, how do you, how do you eat an elephant, you know, one bite at a time?
So yeah, and it's good, you know, it's good stuff.
Thanks a lot for that, Mark.
That was really insightful.
Thanks for having me on the show.
Yeah, that is right.
We'll see you in a couple of weeks, right?
Well, let's, let's bring this thing to an end.
I would say thank you, Mark, but you're going to be here in a couple of weeks anyway.
So, but to all our listeners, thank you very much for listening.
Stay safe out there 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 Azure Setpod.
Music is from ccmixter.com and licensed under the Creative Commons license.