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
116. This week is myself, Michael, with Sarah
and Mark. And our guest this week is Mark Kendrick,
who's here to talk to us about Microsoft Sentinel
Dead Lake. But before we get to our guest, let's
take a little lap around the news. Mark, why
don't you kick things off? Cool. So yeah, I got
a couple of items. One of them is for folks with
Microsoft Unified, formerly Microsoft Premiere.
Folks that have that are Security Option Framework
Module 5, or SAF as we like to call it. The one
on data security is out there, available, ready
to be dispatched for anybody that wants and has
Unified. This one is a really, really hot and
in -demand one because when it comes down to
data security, what we've found is that organizations
have always sort of treated data security as
they've given it a lot of lip service, hey, the
data is the most important thing, etc. But oftentimes,
whether it's an EDR or an XDR or a SIM or something
else, always took priority. MFA, something like
that. And so data security was always important
on people's mind, but it never actually got executed.
And so the challenge, of course, is that AI comes
along and you need to have your data labeled
because otherwise there's no... way for the AI
to know whether it's sensitive or not. And so
it can start feeding it into all the sorts of
different places it's not supposed to go. So
we found this one's really, really important.
And so we prioritize getting that one out there
quick to support people that have to help get
some AI stuff out there and do it securely. So
that one's out. And then the other stuff, so
this is news that's coming. It's not quite out
yet, but we finished the primary development
for the first release of our security roles and
glossary standards from the open group. So this
is me putting on my open group hat. And so this
is, roles and glossary is the overall standard
that we're putting out there. It should be out
hopefully in October. We're shooting to get it
out there before the November conference in Houston
that the open group hosts. Glossary defines a
lot of different terms. Some of them we just
had to clear up some stuff about risk and governance
and stuff like that, just standard glossary stuff.
And some of it was sort of some new additions
from learnings from the Dart team. There's a
very big difference between an Incident, something
happens. A compromise, something went wrong in
security. And a breach, something went wrong
that might be legally defined in your jurisdiction
by legal authorities. And so we got some very
specific clarity out there and some other lessons
learned and stuff like that. So the glossary
is actually more interesting than a normal glossary.
Then we talk about the difference between accountability
and responsibility, essentially who's to blame
versus who does the work. And there's a lot of
interesting insights on that. Something like
75 or 80 roles, I've sort of lost track at this
point in time. that we found that have to do
security work. maybe like less than a quarter
of those are actually in the security team because
IT has to do security work. The business has
to do security work and has accountability for
the decisions they make that affect the security
of the org, all the way up to the board of directors.
And so we really wanted to show that chain and
are in the process of showing that chain, everything
from the fiduciary duty of the board members
that represent the shareholders, all the way
into the management team CEOs and down, all the
way into technology teams, business teams, security
teams. So we're really trying to... round out
the full set of things there. And so the first
two that we focused on was the organizational
leaders, because oftentimes they just don't know
what their security job is or how to set up the
accountability structure right, et cetera. So
we got some guidance there. And then the SOC,
we kind of went to the other extreme of really
in the depths of security, dealing on the front
line, the tip of the spear, as it were, kind
of defining those roles, responsibilities. And
we found that there's about 11 different roles
and specializations in the SOC. And so to find
all those and what are the tasks, the job duties
that they have to do. So we've got some links
for those and people can check those out. Some
LinkedIn articles that I put together sort of
previewing and showing some of the content and
the approach. And then anyone that's actually
a member of the open group, and there's I think
like 500 organizations or something around the
world that are members of it, can go ahead and
review that as it goes through the review period.
And otherwise, check out the LinkedIn stuff.
So that's my news. So I have a couple of bits
of news. Now in public preview, WAF or the Web
Application Firewall is... running on application
gateway for containers so you probably know hopefully
you know that WAF has to run on an application
gateway or it needs to run on front door but
now you can do it in a container which is lovely
if you have something that is facing an application
that is facing the internet you should have a
WAF in front of it so application gateway for
containers means that if you're containerizing
everything you can still have WAF which is lovely
and then the other new I have is that it started
to be released at the time of recording this
last week. Michael and I did a series. Michael
and I harassed people at Microsoft Build a couple
of months ago and were asking developer security
questions. And they've started to be released
on YouTube and they're pretty funny. We got to
talk to a lot of well -known Microsoft faces
and just attendees at the audience. So we're
asking pertinent developer security questions.
I'm biased, but they're pretty fun. So I'll put
a link to a couple of them in the show notes
and keep an eye out because you'll be seeing
them come out for probably at least a couple
of months because we did quite a few of them
and they're good fun. So take a look. Yeah, they're
certainly fun. Although one of the comments on
YouTube was they thought that we were holding
people at gunpoint when we're asking them questions
or under duress. which is absolutely not true,
but it was a lot of fun doing them. A lot of
series of sort of security related questions.
Yeah, it was a lot of fun. Anyway, so onto my
news. First one is we now have VNet encryption
with Azure managed luster. If you're anything
like me, I had no idea what Managed Lustre is,
but apparently it is a very high -speed file
system for high -performance environments. So
now we support VNet encryption, which means that
the connection between the VM, the high -performance
VM, or any VM for that matter, and the actual
storage is protected by DTLS, which is Datagram
Transport Layer Security, or just like TLS, but
rather than TCP, it's using UDP. And that is
used to secure the traffic. So it authenticates
the endpoints as well as protecting the data
on the wire. Next one is we've now added transformations
in Azure Monitor so that you can take, actually
more accurately, data coming out of a firewall,
logs coming out of a firewall can now be transformed
before putting it into Azure Monitor logs. The
reason for doing this is so that you can do some
initial cut at the data before you store it in
the log files, which you can then use as your
monitor to analyze it, which is really kind of
timely based on the conversation that we're about
to go through about Microsoft Sentinel Data Lake.
Sort of pause disbelief just for a moment, and
hopefully Mark can cover some of those stories
about costs and so on for storing log data. Next
one is that we have now released a new hardware
security module called Azure Cloud HSM. This
is a replacement for dedicated HSM. I'm not going
to get into all the details, but we basically
have essentially four different key management
systems now. We have Azure Key Vault, which,
you know, everyone... kind of knows we have managed
hsm and now we have cloud hsm and we have as
your payment hsm which has been around for a
while i'm not going to go into all the details
here there's actually a flow chart which is actually
really useful to work out whether you use key
vault whether you use payment hsm whether you
use cloud hsm or whether you use managed hsm
but essentially cloud hsm is your own piece of
hardware which is the same for dedicated hsm
which is you know cloud hsm is replacing Next
one is PostgreSQL now allows Power BI to connect
to it using a Microsoft account. In other words,
Microsoft Entry ID. This is really, really cool
because that way you don't have to use a username
and password. For those of you who've been following
the Secure Future initiative, you will all know
that one of the big things that we're doing is
getting rid of usernames and passwords or passwords
or keys or tokens that are used for authentication
and potentially authorization. So this is great
to see. Again, we're seeing a lot of products
move away from using usernames and passwords
to using EntraID. That way, the credential is
not in the firing line in the case of an attack.
All right, so that's my news. So with that out
of the way, let's turn our attention to our guests.
As I mentioned at the top of this episode, we
have our guest this week is Mark Kendrick, who
is here to talk to us about Microsoft Sentinel
Data Lake. So Mark, thank you so much for joining
us this week. We'd like to take a moment and
introduce yourself to our listeners. Certainly.
So I have been at Microsoft, oh gracious now,
approaching five years. I came into Microsoft
with the RISC -IQ acquisition. Prior to that,
spent a lot of time in the threat intelligence
space. and working with large organizations,
actually doing some things that are somewhat
similar to the topic at hand, some early iterations
of trying to solve that. So that was one of the
reasons why when I had an opportunity to be involved
in Sentinel Data Lake, I certainly raised my
hand for that. Last few years here at Microsoft
have been super exciting, really busy. There's
a lot of this AI thing going on, in case anybody
might not have noticed. I was actually incredibly
fortunate to be part of the founding product
management team that helped bring Security Copilot
to market. And that was a tremendous learning
experience for all of us, a tremendous amount
of potential then and now. It's hard to believe
that that was a mere 24 months back. which is
basically 24 years in AI terms. But that has
sort of led me to the present moment where I
am now a principal product manager focused on
the Microsoft Sentinel Data Lake, working in
our customer experience engineering team, aligned
side by side with our product engineering teams
and extension of that team, really helping to
bring the customer's voice into the product management
process here. and also really just learning a
lot about what our customer expectations are
for data management, what some of the opportunities
are, and how we can begin to address that always
with an eye towards the advances that are happening
in AI. So super exciting space, and yeah. All
right, let's start with the most obvious question,
at least obvious question to me. I spent quite
a bit of time in Azure Data, so working on SQL
and Cosmos DB. and so on. I heard the word data
lake thrown around, but as a security nerd, I
still do not know what a data lake is. So can
you just start with that? What is a data lake
and why should anybody care before we actually
move on to the security ramifications of all
this stuff? There's a concept that has persisted
for a while of... and of creating an infrastructure
that allows us to retain as much security data
as possible. And this applies, I said security
data, it really applies even beyond that. How
can we be less selective in the data that we
want to ingest? And one of the things that is
a potential solution to that is something that
would natively leverage the low -cost storage
available with cloud infrastructure. The concept
of a data lake generally has come to mean, at
least at a foundational level, a place where
you can inexpensively ingest and store a tremendous
amount of data. and take advantage of the cloud
scale abilities to do that. Over time, the architecture
has evolved a little bit. In the business world,
a data lake is perhaps a place that combines
both transaction data as well as analytical data.
It is an intentional rendering of data for specific
business outcomes. You see some patterns emerging
when people interact with a data lake. Usually
you might find some data scientists doing some
really great stuff with machine learning algorithms
running maybe in PySpark notebooks. So you have
that sort of activity happening on the business
side. There has been a recognition over time
that, as I said at the outset, definitely want
to store a lot of data for security. I think
in my history, I've seen people do all kinds
of ways to try to solve that problem. I remember
Purple Rain, I think, was one that stands out
to me. And that was the name of the home -built
data platform at a major financial institution
that they had created, presumably because the
architect was a Prince fan. But learning about
all the different names for these infrastructures,
learning about how they ended up building these
things, we had like the Elk Stack, Log Stash,
we had all this sort of things over the history
of everything. And it never did really quite...
meet the expectations that folks really had.
And so the most recent manifestation of that
is something you might have heard of Databricks,
for example. Databricks is actually a project
of which one of the core founders is somebody
who is a security incident responder. And so...
That has kind of taken us to the present moment
where a data lake is actually a really well -established
concept within a lot of organizations for business
analytics. And now we have an opportunity to
apply that directly here within security. So,
Michael, does that somewhat answer your question
or does it create more questions? No, no, it
doesn't. So basically, it's just a way of a dumping
ground, essentially a cost -effective dumping
ground for data. You know, ironically, that is
actually the right way to describe it. Even though
it sounds somewhat pejorative, it is actually
accurate. Because whereas previously, we kind
of do a lot of... I see teams doing a lot of
hand -wringing about, oh, goodness, well, we
can't really store that data. We can't ingest
that data. Maybe it's too expensive. Or, okay,
we can ingest that data, but we need to cut out
all these columns, and hopefully we don't need
them later. Or we can ingest that data, but we
can't retain it longer than 30 days. And maybe
once they get it in, maybe they do some complex
transformations on it and some other things.
But for the most part, they're trying to essentially...
prune and route and condense and generally mangle,
frankly, the data before it even goes in. The
architecture of a data lake, again, because it's
built on low -cost cloud storage at the deepest
level, it's actually typically Delta Parquet
files on, say, something like ADLSv2, Azure Data
Lake Storage. the architecture actually encourages
you to just ingest everything, ingest it raw.
This also allows you to scale because sometimes
transformations or any of the other things that
we do, parsing, normalization, if we try to do
those things in ingestion time, we start creating
bottlenecks. We start creating... complex infrastructure
because we want to make sure we have enough scale
to not drop records. It gets really messy. The
idea with the proverbial dumping ground, as you
said here, is let's ingest it raw and then let's
have that single one copy of the data that we
access through different modalities, through
different ways of querying into it. And we apply
transformations directly on the data in place
that maybe creates new aggregations of that data.
Folks can maybe do some research on the medallion
architecture. That's less relevant necessarily
into the Sentinel data lake, but it does give
you some foundational ideas to how that architecture
is. And that progressive rendering or progressive
improvement of the data over time. is really
the future. Instead of looking at tiering your
data or putting it into different storage levels
and all this, just bring it all into the lake
and then work with it once it's there. I was
really excited to see this before it was coming
and then as it launched into public preview.
One of the recommendations that we have when
we talk about the security operations workshops
and whatnot and the best practices that we put
out to customers is really kind of a three -part
strategy, right? You want XDR, you know, start
as EDR, and then we realize it's more than endpoint,
it's identity, it's cloud, it's everything else.
But you need to have like an XDR because, hey,
if a Microsoft or a CrowdStrike or a Proofpoint
or whoever is, you know, going to engineer and
support a bunch of detections, take those. You
know, you don't have to engineer them, you have
to reinvent the wheel. And then a SIEM, because
you need to do analytics to promote other stuff
to that level and do custom detections. And then
the problem is a SIEM is expensive, right? Whether
you run it on -prem or whether you do it in the
cloud, you need a cheap dumping ground, right?
You need a data lake. And so XTR SIEM data lake
is what we recommend. Because the worst thing
you can do is have the data or have the ability
to get the data and then not have it. And so
I loved to see the launch of the Sentinel data
lake, especially the close integration within
Sentinel. Because that just makes life so much
easier for our customers because they can work
with one console and get the benefit of all these
different types of analytics. and not have to
do the swivel chair analytics. That was just
me. I guess it was more of a compensator question.
I was really excited. I'm curious, is it just
the cheap dumping ground? Do you have any other
comments on the problem it's aiming to solve?
I want to get your thoughts on that. Yeah, certainly.
I think the fundamental step for us here is this
is a platform play. By that, I mean we are...
Sentinel has kind of always been a platform in
practice, but maybe not quite as overt or intentional
as what we could make it. And we're really leaning
into that. And so having Sentinel as that data
platform, that's the sort of foundational step
and providing this foundational capability of
low cost storage and ingestion, but doing so.
right next to all of the capabilities that Sentinel
has today. So on day one, one of the first things
customers usually ask me about is, hey, how do
I get data in the data lake? I've got some data
going into Sentinel. I want to go put it in the
data lake. Well, hey, guess what? As soon as
you onboard to the data lake, then your data
that is going into Sentinel is actually mirrored
in real time into the data lake. So all of your
existing connectors, all of your existing infrastructures,
everything that you have for getting data into
Sentinel, we're reusing that, essentially, and
routing that data into the data lake. So on day
one, you get some interesting benefits. So one
of the things, of course, is all of your existing
Sentinel bits, everything that is the SIM in
Sentinel, all that continues to function as expected.
But what you now get is this data that's starting
to collect in the data lake. And because of the
architecture, the underlying architecture of
the data lake, you can query that data through
multiple different modalities, meaning you can
run KQL queries on the data in the lake. Our
friends maybe who are more familiar with running
Spark jobs over in, maybe as I said, in data
analytics world, those are ready to be used on
the lake directly. You know, Michael, you mentioned
some of your experience in data world there.
If you're just missing SQL and you've just been
doing KQL for just way too long, you really want
to just write some SQL. Well, now or at least
some point very near in the future, you can write
SQL against the data lake. And I'm being a little
silly there, but... A very common use case for
our customers is providing visibility to their
security operations, providing reporting and
telemetry. And that can often result in even
just a very practical level. You have some practical
challenges of, well, hold on, I've got this great
little Sentinel workbooks feature. It shows some
really cool dashboards. I don't really want to
give, you know, my CFO or my CEO security reader
because that's terrifying. And so what do I do
instead? Well, I'd love to use Power BI. Great
solution, but now how do you make that connection
into there? Well, because the data lake is on
architecture optimally suited for that, your
data is actually ready to be queried in that
modality right away. And those are just, of course,
the traditional ways. As we start looking at
our evolution to AI, as we start... bringing
on new agentic experiences. All of those things
that can query into the lake become other different
ways of accessing it. So all that begins. Now
that presumes that the data that we have going
into the sim is maybe all the data that we need,
but of course we know it's not. We know that
there's... Within organizations, very often,
there is data that we know would afford really
useful security insights, but we just maybe can't
quite justify and make the business case for
ingesting it into a full -on SIM. But again,
we know it's useful. Historically, that's led
us to essentially fork our infrastructure to
go put that data someplace else. Some organizations
might leave the data in an on -prem SIM. or an
on -prem data platform. Maybe you have, I mentioned
Logstash earlier, maybe there's some other open
source tools that you've deployed. So maybe that's
a solution. But however those solutions work,
when you have the data in two separate places,
you miss out on opportunities for what I think
of as data adjacency. You know, I actually was
talking with a customer recently where they were
saying that they had some data in Azure Data
Explorer and they had some data in Sentinel and
then they had some data in another traditional
SIM, cloud SIM. And I'm like, wow, that's all
really useful security data. How do you join
that together? And there was silence on the call.
And finally, one courageous soul spoke up and
admitted Excel. which was just tragic. So I can
just imagine trying to do joins in Excel with
VLOOKUPs. But this is the reality that so many
teams are in, and that's the reality that's changing
with Microsoft Sentinel data lake. So now, if
you are at that stage where you're just not quite
ready to make the business case to apply full
analytics to a given data set, let's just pick,
say, DNS logs, then you can instead bring that
data in directly to the data lake. You can do
so with the existing connectors and the existing
infrastructure inside of Sentinel. Once that's
in the data lake, you can query it using KQL
that you're already familiar with. You can do
that inside the XDR portal. So there's a lake
explorer integrated into that experience. And
because you also have that adjacent to the rest
of the data that's there, everything begins to
sort of come together. So that is really what
this is starting to bring together in that structure.
So, Mark, this might sound like an obvious question,
but do we have to have a Sentinel to use Data
Lake? I mean, you've talked about running KQL
across it. Do they have to operate with each
other? Tell me all the things, just for clarity's
sake. Yeah, no, that's a good question. And we
do have some folks that have asked that question
before. The key thing is to realize the way in
which Microsoft is evolving the concept of Microsoft
Sentinel. Microsoft Sentinel is our security
data platform, and you will continue to see that.
coming into and converging with our other solutions.
So whereas a lot of us that know and love Sentinel
inside of Azure, and we use that term to describe
that specific experience, then it might seem
a little peculiar, like, what do I have to have
that to just have the data lake? But really,
we're evolving not just the product, but also
how we communicate about this and indeed how
we build it. So the direction that we are heading
is that If you want to benefit from the things
that we're talking about here, from the data
lake, then you'll want to activate the Microsoft
Sentinel data lake, and you'll want to bring
that data in through the Microsoft Sentinel connectors.
You do, of course, have the option of bringing
that data directly into the data lake only, and
then maybe making a decision later that you want
to present it for the real -time analytics in
the sim. So in that way, that... element of it
is is mostly optional but of course highly recommended
and it also gives you the option in fact of even
taking the result of your queries and presenting
those directly into the analytics tier as we
call it within the sentinel what we know and
love is sentinel today and so it's the adjacency
of those two technical experiences connected
together unified together into that that really
makes the difference. And again, the experience
of this is going to be happening inside of security
.microsoft .com. It's going to be happening inside
of the Defender portal, and it is just an extension
of that overall experience. So, Mark, one thing
I wanted to sort of run by you, because I had
this sort of interesting insight as I was helping
write the standards that I mentioned in the earlier
news section. Because we were basically going
through, for each of the different SOC roles
and organizational leader roles, here's your
job, and if you don't do this, then here's the
risk of neglect. What goes wrong? And it really
helps bring things in a real clear perspective
of why it's important to do something. And one
of the things that we were talking about is,
hey, SOC should be reviewing... the solutions
that go through your architecture review board
or your solution review board, whatever you call
it, as different folks review it to make sure
that this thing isn't going to break something
in your enterprise. And of course, one of the
big things there is logs. And one of the interesting
insights that I had on why logs are so important
is as we're writing that risk and neglect out,
I realized you can't... actually do root cause
analysis without logs so if you don't turn the
logs on if you don't have the logs and you know
like a sentinel data lake or something else or
just anywhere when you have an incident then
one you can't detect it and it's really hard
to investigate and you can't do a root cause
analysis of it and you're like well something
happened we don't know what or why or how and
then so you can't do the root cause analysis
you don't know actually what happened or how
it happened so you can't prevent the next version
of the exact same attack And so, you know, assuming
you do turn it on after that first one because
you learned your lesson, you know, then you can
actually start to do root cause analysis and
then, you know, prevent that and block whatever
happened that first time. And so it was really
interesting that I didn't quite realize that
when you don't have logs, you're signing up for
at least two more incidents because you simply
don't understand what happened the first time.
And so you're bound to have the second one because
the attackers always try the same thing over
and over again. And so I'm just curious on your
thoughts on that. But that was one of those things
that really sort of came home on how important
logs are. Absolutely. Our good friend, good fellow,
John Lambert, is fond of saying that it's all
security data, right? People sometimes look at
it like, well, is that log security data? Well,
it might be someday. Sorry, but it might be.
So you're exactly right in that the... The inability
to have the logs that you need has a direct impact
on your ability to do blast radius assessment.
It has a direct correlation, as you said, to
prevention. And it, of course, also for what
I think of as historical detections, right? Finding
the evil that you did not know was evil that
actually happened six months ago when somebody
clicked on something and experienced an event.
Because it was a novel event or maybe because
they hadn't had Mark enough of your sessions
that they were listening to. So maybe there were
some gaps in their protection. There were some
pieces that maybe they hadn't deployed yet. But
that happened six months ago. Nobody knows that.
Nobody knows maybe at this point that it is a
problem. But now suddenly there's a publication
that comes out and says, hey, there's this terrible
thing called password sprays. They're scary.
Here's how you go look for them. Or even if it's
something as simple as. Here's a list of five
IP addresses, three hashes, and two host names.
Just go see if your organization ever interacted
with any of these things, ever, in any context,
any time over the last six months. Well, that
all sounds... wonderful on paper, but if you've
ever had to actually do that, you quickly encounter,
it's like, well, hey, guess what? We were gathering
our DNS logs, we were gathering our firewall
logs in our sim, but they aged out after 30 days.
And oh, actually, somebody was doing some really
cool projects around some machine learning, around
files in SharePoint, and it was really kind of
cool, but it was expensive to maintain that cluster
and they didn't really see an outcome from it,
so yeah, that data's not there anymore. And the
end result is you find that you're actually impacting
your ability, as I said, to do retroactive detections,
to search historically. We sometimes talk about
threat hunting in the abstract, and sometimes
it can be. You just have a hypothesis of something
that maybe you can go find some evil. That's
absolutely useful, and having a data lake to
help you with that and store the data is good.
But sometimes threat hunting is actually fairly
targeted. You know the IOCs you're looking for.
The question is whether or not you have the data
for it. And so our vision with the Microsoft
Sentinel Data Lake is to go directly after that
problem and provide low -cost retention, provide
something that is operating adjacent to the rest
of your infrastructure, and allows you to...
to sort of incrementally build the case to ingest
that data. And I think maybe sometimes that's
also why folks don't have the visibility that
they need is because they know that it might
be useful, but we all want to be good stewards
of our organization's budgets. And if I'm going
to go and say, hey, I want to ingest these DNS
logs, but... They're like, okay, great. What
are the detections that are going to surface?
How is this going to inform my existing real
-time detections? Well, I'm pretty confident
that it's going to do that. I'm pretty sure I
can show that case, but it's going to take me
a little while. And you get into these poultry
sequencing problems, chicken or the egg thing,
right? How do I build the business case for this
if I can't get it into the data platform? Yeah,
I was thinking that's like the data version of
the you can't get experience without a job and
you can't get a job without experience. It's
very much that. No, you're exactly right. And
so our thinking is that for some of these data
sets, let's just bring this into the data lake
and then turn people loose on it and see what
they're able to find. So, Mark, I have a question
for you, actually. Now, you talked about the
recommendations and things that you've put out
there. One of the pieces that I'm really excited
about with the data lake is the fact that we're
ingesting not just the activity data and the
logs you were talking about, but we're also ingesting
assets. And when we talk about assets... into
the platform. What we're talking about are, say,
the enter identities, the various users and groups
that people are a member of, think snapshots
of things that you might maybe pull off of the
Graph API. We're also bringing in periodic snapshots
from Azure Resource Graph, from ARG, and even
some additional attributes from SharePoint and
Office 365, all rendered as these periodic snapshots
of asset data. I'm curious, what do you imagine
that you could do with that data combined with
log data together in sort of the same world?
So I think there's a huge amount of possibilities.
The funny thing is, as you're describing that,
I was connecting it to in the open group when
we were trying to describe what is a modern SOC,
right? Because the old -fashioned SOC is... is
basically a network perimeter centric, right?
Let's try and catch the stuff as it tries to
traverse the firewall, the network perimeter,
the IDS, the IPS, whatever, intrusion detection,
intrusion prevention, et cetera, you know, all
in the network perimeter. And then after we do
that, okay, let's come up with a detection. Then
let's like block it so that they can't get in
the perimeter. That's kind of the old way of
doing SOC. And we were trying to figure out like,
how do you frame the new way of doing? security
operations, right? And the term we ended up settling
on was asset -centric because ultimately what
you need to do is you need to protect something,
whether it is valuable or not. You need to know
how valuable it is so you can do the most valuable
stuff first. And you've got to protect it regardless
of wherever it is, inside, outside the firewall,
the perimeter, the corporate network, whatever
you want to say. And so we ended up settling
on asset -centric security operations. And so
it's really funny that you mentioned even use
the term assets as you're describing that. So
I have a huge amount of hope for what we can
do with that. I know hope's not a plan, but there's
an amazing amount of things you can do that once
you actually are focused on the things that matter
and you can tag those and you can establish relationships.
And I understand that y 'all aren't first release,
so I'm not expecting that any of this is necessarily
in the product already. But the more that you
can get it to that asset -centric thing, because...
Assets are a thing, right? And that's what's
happening is the thing is being attacked, right?
Whether it's a user identity or an endpoint or
a cloud container or an API or whatever it happens
to be. All of those things are what are being
attacked, taken over, and then used as a launching
point for the next thing. Because logs, at the
end of the day, logs are just something happened.
Something happened to this thing, and this is
the data that we gathered, the attributes, the
other observed information about it. But at the
end of the day, Activities and events about an
asset, and that asset is what the attackers are
targeting and using and trying to steal and corrupt
and take down and extort you for ransomware -wise.
I'm really excited about that concept. I recognize,
again, you're literally the first release public
preview, but I think that's an amazing approach.
Well, it's good to hear the validation on that.
And yes, we also are super excited. I'm not sure
if folks like Michael who are focused on the
red team side of things are quite as excited
about that. For obvious reasons, we are always
interested in making his job harder. So we're
excited about that possibility too. I don't know,
Michael, if any of this is making you nervous
from your perspective here. Well, actually, it's
funny you should bring that up. I mean, we found
that basically one of the biggest indicators
about whether the red team is successful or not
is logs. Absolutely. And we're all about making
sure that Michael has a bad day as his red team
persona. What is a day in the life of Mark Hendrick
look like? What do you do day to day in your
job? The day usually starts fairly early for
me because I'm in the West Coast and we have,
of course, teams and customers all over the place.
But that often does mean there's some early calls.
So actually this morning was fairly early for
me. Lots of conversations directly with some
of our customers. We usually have some key design
partners we're collaborating with on early versions
of features. Certainly collaboration among our
team, learning from each other, what we are hearing
from customers. providing some order and some
structure to that, then joining with our engineering
colleagues, listening to the efforts that they
have been making and the progress that they've
been making on various features and capabilities,
and then preparing, of course, to get the word
out with that. And at that point, my brain is
kind of starting to get to the end of itself
because it's been functioning at least at some
level for about six or eight hours at that point.
But afternoons do tend to be... full of a lot
of collaboration with my colleagues. Microsoft
is still blessedly committed to remote work.
Everybody's all over the place, but the afternoons
when things kind of calm down with customer conversations,
lots of collaboration and conversation there.
So that's roughly the day in the life, if that
helps. Then the very last thing we ask people,
Mark, because we love to grill people, is if
you had a final thought for our listeners, what
would it be? So I think the one other thing that
I would say is this product right now, Sentinel
Data Lake, is in public preview, which means
it's available for you to get your hands on right
away. And if you look really closely at the way
that the deployment strategy works, the way that
the pricing works even, you can find a pretty
affordable way to begin trying this product out.
So please, whatever you do, don't tell anybody
on the sales side that I said that. But you can
actually find incremental ways of engaging with
this. I know sometimes you're thinking, wow,
huge data platform, SIM migration. I'm going
to have to talk to those terrifying people over
there in purchasing. Take a look at the product.
Take a look at how it is offered, how it's packaged.
I think you'll find a pretty clear path to how
you can actually get started with it in the near
term and start kind of building the case around
it. All right, so let's bring this episode to
an end. Thank you, Mark, for joining us this
week. I always say this, but I always learn something,
but I learned a heck of a lot actually on this
one. It makes a lot of sense, this whole data
lake idea, which again was kind of funny seeing
as I was in Azure Data for such a long time,
but there you go. All right, so let's bring it
to an end. Again, thanks for joining us and to
all our listeners out there, we hope you found
this episode of use. Stay safe and we will 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.