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
113. This week it's myself, Michael, with Sarah
and Mark. Gladys is away this week. And our guest
this week is Craig Nelson, who's here to talk
to us about the Microsoft Red Team. But before
we get to our guest, let's take a little lap
around the news. I'll kick things off. I've got
just a couple of items. The first one is in public
preview. We now have, as your virtual network
manager, high -scale private endpoints. There's
this thing called connected groups that allows
you to basically cluster together private endpoint
information, just making it considerably easier
to manage. If you've ever tried managing private
endpoints one by one, it can be a little bit
difficult. So this allows you to basically glom
together 20 ,000 private endpoints into one connected
group and manage them that way, which is absolutely
magnificent. Next one is one of my favorite topics.
You really need to make sure you guys got this
all in place because this is not just the only
product that's coming down with this, but Entra
Domain Services is switching over to TLS 1 .2
and above. and completely deprecating 1 .0 and
1 .1 on August 31st this year. That is not...
a long way away. So you need to make sure that
all your clients that are connecting to those
services are enabled for TLS 1 .2. To be frank,
I've yet to, I think I've never come across one
item where a customer had a problem and it was
some really old mobile platform with some funky
Java or Kotlin app that had some really old library.
The other mistake I've seen people make is when
they actually hard code the TLS requirements
into the client. So it can't connect to 1 .2
or 1 .3. go doing that. Okay, so me next. Couple
of things. Well, one's a big one, but first up,
we've got in Azure Container Registry public
preview of continuous patching, which is lovely
because it means we can patch things without
having to rebuild containers. So go and have
a look at that if you are using containers, which
no doubt somebody is, or most people are in their
environments nowadays. So my other bit of news
is around MCP. Now, MCP at the time... recording
this has absolutely exploded uh in the sort of
i'd say last six weeks um if you haven't heard
of it mcp is the model context protocol um it's
open source and being driven by anthropic it
allows agents and applications to discover and
invoke tools in a standardized way so you can
think of it maybe a little bit like a USB standard.
It's a client server model. It's very new. The
spec is changing regularly. And of course, there
are some security risks around any. new technology
that we introduce. So I wrote a couple of blog
posts on it. One is about general overview. Another
one is about a particular type of attack that
some researchers have found against MCP. It is
actually just indirect prompt injection. So go
and look at that. Also, we'll be definitely hearing
more about MCP. And I understand it was actually
mentioned at Blue Hat India yesterday. Also,
on that same... thread we've also gone all in
we've announced that we're going to support in
our products agent to agent protocol now agent
to agent protocol is similar to mcp it's open
source again it's being driven by google and
that is a way a standardized way that agents
can talk between themselves rather than connect
to resources so that's the difference between
the two it's all very new changing very quickly
so go and keep an eye on that but certainly if
your devs have started wanting to use MCP, that's
something that you want to go read up on and
educate yourself about ASAP. Cool. So in my area,
big thing is the MCRA, the Microsoft Cybersecurity
Reference Architecture, has been released. That's
our April 2025 edition is the current version,
replaces the December 23 edition. Mostly the
same kind of format, no like real changes like
the previous revisions where we went from kind
of a single slide to a bunch of complex slides
or to a full narrative kind of landing why end
-to -end security is important. which were kind
of previous things. In this case, it's sort of
an enhancement of the current structure and format.
And one of the big, big things that we did there
was some of the work that I and others have been
doing with the open group to define roles and
capabilities and all sorts of things in security
that have been either partially defined or not
defined well or just not defined at all. So some
of that work made it into the MCRA. So lots of
goodness there. I've been doing a lot of continuing
to do a lot of work in that. space. And it's
just really interesting when you lay out all
the different roles and responsibilities from
board members to CEOs to lawyers and finance
people and people in the security operations
or sec ops or SOC and IT engineers. And when
you bring all those things together and connect
them and list them out and say, what is the thing
you need to do? Kind of that old office space,
what would you say you do here? It's just really
interesting to... to pull all that together and
kind of see how things actually work and should
work. It's like seeing the human system as a
system, like a technical system. And so it's
been a lot of fun, a lot of challenges, and a
lot of... well, what really is the difference
between a chief digital officer and a chief technology
officer and a chief architect and a CIO? And
so there's all sorts of interesting things that
come up from that. But we're publishing as much
as we learn as we can. I'm going to include a
few links in the show notes of the stuff that
isn't quite in the standards yet, but we're looking
to get feedback on. But yeah, that's the big
one is the MCRI. So we'll drop the link for that
out there. All right. So as I mentioned at the
top of the podcast, Our guest this week is Craig
Nelson. Craig, welcome to the podcast. We'd like
to take a moment and introduce yourself to our
listeners. All right. Thank you. I'm a longtime
listener of this podcast, so I really appreciate
the chance to be here with you today. I've been
with Microsoft for about 18 years, and I started
out as one of the first engineers focused on
securing Microsoft's cloud. And back then, the
cloud was very small and the problems are very
different. And I've grown up with cloud and I've
had the privilege. of being part of the evolution
of both the technology and the threats that we
see. So today I'm the VP of Microsoft's Red Team,
and it's absolutely an awesome job because Microsoft
takes Red Team incredibly seriously, and it's
not just a checkbox. We work directly with engineers
who shape security strategy, build secure architecture,
and shape the investment decisions across the
company. So as you can imagine, Microsoft is
constantly targeted by some of the world's most
advanced threat actors and who may actually be
listening to this podcast. So I have to be very
careful about what I share. But what I can say
is that our red team is structured to view Microsoft
in the same way that real attackers do. Because
threat actors do not respect organizational boundaries.
So neither do we. We look at Microsoft end to
end. The red team is a centralized group of engineers
who run breach operations across Microsoft infrastructure.
That is the core of the team. And that's backed
by a specialist who also performed deep technical
research and exploitation so we can gain what
we call high value attack positions. We have
an intelligence team that built a security graph
so we can understand attack paths and risks and
perform things like center of gravity analysis
and an engineering team that builds the tools
and AI that we need to scale our work. But in
many ways, we operate like a nation state level
offensive team. But there is one major critical
difference. Our mission is actually entirely
defensive. We don't attack anything outside of
Microsoft. We never touch customer data. And
our goal is to proactively find and address vulnerabilities
so we can help protect Microsoft and our customers.
So let's just start with probably the most fundamental
of questions. Can you explain the role of the
Microsoft Red Team and just what is Red Teaming
in general? First, let me frame how Microsoft's
organization works so you can understand where.
Red Team and I sit. At Microsoft, we operate
with a distributed security governance model.
Our CISO sets the overall direction, and beneath
them are deputy CISOs, each responsible for core
security decisions across the different divisions
of the company. Some of the deputy CISOs are
leaders in our engineering orgs, such as Mark
Persinovich is the deputy CISO of Azure. Other
deputy CISOs span critical areas, such as Anne
Johnson being responsible for our customers.
I bring them up because both Mark and Ann are
very well known in security circles and in the
podcast community. They're great examples to
call out. Now, you know, Red Team reports to
the CISO and the work that the Red Team does
spans the entire company. And the findings often
influence multiple deputy CISOs. Now, you have
to imagine you're one of those deputy CISOs and
your job is to understand the risks of the systems
and how they behave against attackers in the
real world. So you have that problem to worry
about. Meanwhile, Microsoft is also in a very
transformational phase where AI is changing the
way people work and how systems are built. And
that means there's a lot of code being written
by AI. Products are incorporating AI very quickly.
And the internal work of how we and the industry
is going to use AI for productivity is just going
so fast. So there are so many things happening
at this moment in technology. It can either be
a blessing or a curse. And that's where red teaming
comes in. Our mission is to help those security
leaders, our deputy CISOs and CISOs truly understand
how the systems stand up under adversarial pressure.
And I hope your listeners who are thinking about
forming a red team can benefit from this and
ensure that their red team and the folks doing
this work are organizationally positioned. in
a way that the risks that are surfaced are appropriate
to their security governance model and how decisions
are made. Red teaming isn't just about breaking
in. It's about emulating a range of threat actors
from low effort, opportunistic attackers to highly
resourced nation state level adversaries. And
we look at how all the things come together in
responding to that technology, people, process
when they're under real world stress. Red teaming
is all about this challenging groupthink and
status quo assumptions. And big organizations
can quickly fall into patterns of thinking because
they think that their checklists are complete.
And red team exists to test those assumptions
and expose the gaps that matter the most. So
Craig, what are the key objectives of red team
exercise? Is it learning or... I assume maybe
there's probably a few things. Yeah, so Red Team
is about forcing the evolution of very complex
systems. You can imagine how large the Microsoft
estate is and all the complexity that's tied
into building global services that fulfill so
many workloads that our customers use. We want
to force that evolution, and that makes us learn
how do these systems respond to real lawful good
adversaries, that is the Red Team, as one of
the core objectives. So we want to understand
how a motivated attacker would move through the
environment, how they would get that initial
foothold, and then what the effectiveness of
the defenses are. And then with that, when we
see the red team having success, we know where
to invest to better harden the system, improve
detections, as well as response efforts. That
really boils down to mapping out real attack
paths across identity systems, network edges,
and cloud boundaries. And we put a lot of time
into making sure that we understand how detection
and response works in the scenario where things
fail. So, for example, in the industry, we talk
about assume breach a lot. You have to assume
that an attacker will always get in. The question
is, how long can they stay in? We want to give
our engineering teams a feedback loop as a adversary.
So they can understand that. And then we are
testing them to see if they can take the right
steps to pursue the attackers and then what they
do to minimize their success. At the end of the
day, back to your learning point, this is all
about shifting the mindset from hardening individual
systems to protecting end -to -end breach paths.
Thinking about how credentials, secrets, how
information moves, where it's stored, what policies
are applied. So you can really constrain what
an attacker can do once they compromise the system.
Can you describe a little bit more about how
red teaming enhances the overall security posture
and any kind of examples that you're able to
share, completely recognize there's limits on
what you can share? So that's a fantastic question.
To really answer it, we need to acknowledge that
humans need to have a threat materialize and
be affected by it to truly understand it. So
in security, it's easy to get stuck in hypothetical
scenarios that really do nothing because you're
overwhelmed. And today's complex systems, there
is an endless list of things that could go wrong,
from denial of surface attacks that can disrupt
a company to a full -scale compromise with serious
financial and reputational consequences. So if
you're curious to how bad things can get, ask
ChatGPT about attacks that I remember from the
past. There's one in 2014 from the Lazarus Group.
Stuxnet is also infamous. Search for NotPetya.
and you'll see that you know these weren't just
one -off events you know they revealed a pattern
often what we will see in the future and uh exposed
techniques that start with hygiene and they get
quite sophisticated and you know this forms the
foundation of how modern cyber attacks work and
uh even cyber warfare practically Most organizations
aren't worried about nation state conflict, and
that's good. They're worried about ransomware,
service outages, data leaks that can impact the
trust of their customers. And that's where red
teaming comes in. It can help you figure out
which of those risks actually matter to you in
your environments, within your systems, as well
with how the people respond. At its core, red
teaming is about running a controlled test before
a real attacker does. And it gives you that insight
into how your defenses hold up under pressure,
and just as importantly, how people respond.
And it's what happens after a breach that matters
the most. You're sitting down with those that
were impacted and the engineers that may have
created the problem, analyzing what broke down
and then figuring out how to improve. And that's
what drives the improvements to security posture.
So if you're listening and you haven't done red
teaming yet, whether you're a big company or
a small one, I strongly encourage you to learn
more. You don't need to have a full -time red
team to start. And even a small internal exercise
can be hugely valuable. It's a great way to grow
your security culture. Red teaming is designed
to challenge assumptions, spark creativity, and
it's actually a lot of fun. And it gives your
security professionals and engineers a new lens
on their work and helps the broader organization
see security for what it really is, a very dynamic,
evolving challenge and not just a checklist.
Just think about red teaming in general. I mean,
are there any ethical considerations that come
into play or does the end justify the means?
How does that all work out? Yeah, the first thing
I want to point out is as I talk through this,
we are focused on protecting Microsoft. We don't
red team customer tenants or systems. It is to
protect customer data that's sitting on top of
Microsoft's infrastructure. So ethics are non
-negotiable. So every red team operation is governed
by a very formal set of rules of engagement that
covers scope, safety, impact, and who's going
to be notified and when. And clearly, you don't
want to disrupt any business and cross into data
that you're not authorized. to touch. That is
really, really important. You have to be very
intentional about how you conduct red teaming
for your listeners that are listening to this
and they want to form a red team or they want
to have some kind of red team initiatives, even
with folks that don't do red teaming as a full
-time job. That's great, but it is really important
that you craft what we call rules of engagement.
So Craig, you've already touched on this, but
how do you define the rules of engagement for
a red team operation? Yeah, so the rules of engagement
is kind of like the constitution of an op. We
work with our legal teams, engineering teams,
and leadership to define exactly what's in scope,
what's out of bounds, and when we'll communicate
before, during, and after the exercise. So just
very clear bullet points so everyone is on the
same page. Now, in terms of when we talk about
what's in scope, it's really important that your
red team has a very broad scope. So the rules
of engagement are to set expectations that...
that the scope is large because the more you
can strain, the less breach paths you're going
to find. And then finally, in the rules of engagement,
it covers safety mechanisms. So one important
one is called de -conflict. So if alerts go off
and they're seen by the security operations center,
they have a very clear path that they can understand
whether or not it's the red team or potentially
a real threat actor. So we want to make sure
that they understand that if an alert goes off,
they just... You don't have the idea that just
attribute to red team and then perhaps no action
is taken. In the best case, everyone in the organization
responds to the red team as if it were a real
threat actor, because that's where the bulk of
learnings come from. When you talk about like
red teaming, it strikes me as a fairly broad
set of skills. Can you kind of talk about like
the skill set of red teaming and like just getting
started and then what you kind of master and
fine tune as you go? You definitely need a deep
mix of technical skills, adversarial creativity,
and the ability to clearly communicate. And we
have people that are experts in Windows internals,
identity systems, protocols, network exploitation,
cloud architecture. It's really where those skills
come together is where you find the most creative
novel breach paths through a system. But what
makes someone great being on a red team is not
just their technical depth. It's really their
ability to think like an attacker, explore the
edges, have that instinct of how things were
designed to work, and then figure out how to
kind of move around those edges and target conditions
or dependencies that may have not been thought
about in the system design. One of the things
I really appreciate is that intuition where folks
understand how to chain together little subtitle
misconfigurations. And then tie that to a breach
path and then explain to an organization why
it matters, why these things have to be fixed
and why they should invest time to get those
misconfigurations or past architectural decisions
changed to make the attackers have to navigate
more terrain and increase the cost to breach.
Or just, of course, just make the breach infeasible.
You brought up an interesting point there when
you said... The people on the red team have to
think like an attacker. It's interesting. I hear
that term all the time. It's like, oh, you know,
we make software so much better. More people
just thought like an attacker. The problem is
unless you are one, you can't think like one.
You really, really can't. However, the people,
all the people that I know on the red team are
definitely world -class attackers. They don't
just think like an attacker. They truly are attackers.
And so they have that certain mentality. So what
are the tools and techniques that are commonly
used by the red team, or at least as much as
you can talk about? And what's the role of AI
in here, both from attack and defense? So our
toolkit spans open source proprietary and system
native tools, whatever best enables the mission.
In the reconnaissance phase, we use open source
tools from GitHub, right? That's what real attackers
use. This is what we use. And we use these tools
to gather open source intelligence. enumerate
networks, and map cloud attack services. For
command and control, frameworks like Sliver from
Bishop Fox, again, available on GitHub, and custom
infrastructure gives us the flexibility and stealth
that we need to emulate real threat actors. But
just as often, I want to reinforce that it's
important that your red team... It's just living
off the land, using tools that are native and
already present in the environment and operating
system. So this is PowerShell, WMI, CertUtil,
and just classic Unix tools like SoCat remain
powerful decades later. I used SoCat 25 years
ago. I still use it today. But the landscape
is shifting, and AI is rapidly becoming central
to red teaming. So we use it to generate code,
automate repetitive tasks, and speed up complex
operations. Personally, I vibe code a lot of
stuff. I build very fast, functional scripts
that stitch together APIs, analyze data, invoke
tools on the fly. And I look at it right now
that it's less about perfection. It's more about
acceleration. But the next critical skill set,
if I were advising someone getting into red teaming
now, is really learning how to vibe code to connect
AIs together and their data streams, build lightweight
orchestration across their environments, really
centered on AI and AI platforms. Over time, this
is what's going to involve systems that take
automated action, such as triaging logs, testing
APIs, and remediating threats based upon learned
patterns. Now, this is not going to replace humans.
I look at it as you want to supercharge red team
engineers. It's going to allow engineers that
are doing red teaming to move faster, test deeper,
and simulate what real adversaries are doing.
themselves, because that data will be enhanced
through threat intelligence. And real attackers
are going to use the exact same approaches. So
looking ahead, I think that the next obvious
step is that all of the common tools that we
use as Red Team will be invocable via AI, and
they're going to be plugged into multi -agent
AI infrastructure. These agents communicating
over MCP, I know Sarah highlighted that earlier
in the news, are going to coordinate what tasks
need to be done, such as source code analysis.
They will be invoked through a common orchestration
AI platform that basically says, hey, here's
these three tasks that I need to do. Invoke these
tasks across these tools. And that data will
be brought back for that AI orchestrator to interpret
and then take the appropriate action. So across
domains, and they'll do so at speed and scale.
So I think there's going to be a big transformation
in the products that we use today in the security
world. So that's where we're going. Tools are
going to become skills. AI is going to become
the fabric. And red teams that are using this
automation are going to be able to stay on the
leading edge to help. ensure that defenders don't
fall behind. So, Craig, how do you measure the
success of a red team engagement when you're
all finished? Yeah, so it's not just about how
many systems are compromised. It's about what
the organization learns and what changes as a
result of the red team operations. We look at
how quickly actions were detected, how quick
and accurately the defenders responded. whether
or not critical issues were prioritized, and
whether or not there's lasting improvement over
time. So a successful red team engagement must
lead to real architectural, in many cases, cultural
change about how systems are built and protected
over the long run. I just have to say, I love
that answer. And thank you for saying that, because
I see way too many people celebrating that we
got in and we shamed you guys. Okay, so why are
we paying you? You're supposed to help make us
secure. So would you be able to share maybe like
a real -world example of an engagement that led
to some of those improvements? Is that something
that you'd be able to do? Well, I can't share
specifics from the internal operations, but I
can give you some ideas of the type of things
that we find and some of the patterns that we've
been able to fix at scale. I'll start with number
one, overprivileged identities and applications.
What we tend to find a lot is either identities,
either human or service principles may have very
broad assignments like owner, contributor, user
access administrator. When you see stuff like
that, that tends to mean that there's too much
privilege being assigned just within the culture
of the organization or within the specific applications.
applications are just granted far more permissions
than they're needed, as well as OAuth applications
are reviewed and monitored, and they often retain
access kind of long after their useful life.
So this matters because once an attacker gains
a foothold, that overprivilege, if they can get
those credentials, can turn a small breach into
something much larger as they get access to those
identities and those credentials and laterally
move. So what to do there? The guidance is always
goes back to the core of enforcing least privilege
and then looking at enterprise applications more
specifically and service principles for applications
like application read, write all and directory
read, write all and just very broadly scope findings.
That's number one. That's the number one finding.
After that, the second is inadequate credential
and token isolation. So this is where you tend
to find like shared credentials and DevOps pipelines
and scripts and automation accounts and its source
code. And then like long -lived tokens, such
as like a connection string or SaaS tokens that
can be used to access resources that an application
may take as a dependency, such as a storage account.
That matters a lot because those enable what
I call silent privilege escalation. Some of these
things are really hard to detect, but... There's
a lot of transitive risk that can be seen just
simply from one system having access to another
system via a credential that the attacker is
using via this lateral movement techniques. Another
area would be we just see flat network architecture
and just overall weak network isolation. You
know, one of the hardest things to get by from
a red team perspective is isolation, primarily
network isolation. You know, we tend to find
that VNets that may span multiple zones of trust
or hub and spoke models. where there is just
a central point of trust that can pivot broadly
within a network or a VNet, and then misconfigured
network security groups and overly permissive
access and data flows. This is a difficult thing
to get a hold of. It was 20 years ago. It still
is now, just because applications are designed
to want to connect to each other. And you really
have to understand your network and your flows
and make sure that if there's a problem, the
default behavior is into open rules to allow
applications to talk to each other. Because that
might not be corrected. And those are the type
of things that red teamers find. It kind of reminds
me of the old fail -safe principle in engineering
that you don't want the dam to fail open where
it's going to flood the town, right? Yeah, absolutely.
Absolutely. And to that point, weak application
boundaries and these assumptions, I think those
boundaries are that dam. And you have to really
understand your microservices and APIs that do
assume trust across tiers. sometimes without
authorization enforcement. That's a great analogy
that there are all these dams between the systems.
But at the end of the day, all those dams have
some point of failure. Then you have to understand
kind of what it is and what the consequence is
if it's defeated. Craig, so how do... Red teams
adapt to emerging threats. We know things change
all the time and different attack techniques.
And obviously I'm going to throw in, what about
AI? Yeah, red teams have to kind of live in the
future a bit and understand what's coming down
the pipe. Because AI is very powerful, defenders
are clearly going to use it. And we see that
today. And I just got back from RSA where there's
a lot of innovation in the space where the AI
is being used to sort through large volumes of
data, drive automation within the SOC. and drive
consistency across the environment. So because
it's going to get harder, at that point, the
red team is going to have to use AI as well.
And we know that real attackers are using and
getting better with AI. Right now, some of them
might be confined to crafting better spear phishing
emails. But over time, it's going to look at
things like automating recon, monitoring a target.
So for example, use generative AI to vibe code.
a script in Python to watch a particular endpoint
over a long period of time to detect subtle changes
in the attack surface, which can then raise an
alert for the red team to move in. Certainly
analyzing source code at scale and kind of looking
through source code with a new lens of where
do vulnerabilities exist, not only in the semantic
and the code flow, but also just how the human
works, right? I look at... source code that has
to -do comments or code that is just overly complex,
sometimes being passed for exploitation. I think
the other dimension of AI for both a red team
and a defender perspective is looking at code
to understand what is being detected or where
there are gaps in where telemetry is being generated.
And then those are areas that you want to target,
certainly from a defender perspective. looking
at code, and if there's a particular event, for
example, for authentication, if that is not logged,
that is something that should be fixed by the
defenders, but also targeted by the red team.
And in summary, we're doing a lot of the same
things, just much faster, using AI to find the
weak links and model attacker behavior more realistically
to understand what threat actors are looking
for, and then using that to drive quicker change
within the environment. such as implementing
more precision detection rules and understanding
where there are vulnerabilities that previously
haven't been easy to find. One of the questions
that we always like to ask is, what's a day in
the life of a red teamer? I mean, is it... always
on the keyboard? Is it in conference rooms and
meetings? What is it like to just kind of do
this day over day? Well, I'll start by saying
that at this stage in my career, I'm not the
one actively breaching the systems every day.
I spend most of my time working within Microsoft
security governance structure and understanding
what our CISOs and deputy CISOs need to make
informed security decisions, as well as our engineering
leaders. They have to get the results that they
need to be successful. But I'll share what I
see every day from the engineers that work on
my team, because that's where the action is.
And it certainly makes up a better podcast. Roughly
half of their time is spent in deep technical
work, hands -on keyboard. And that means building
tools, writing scripts, reverse engineering,
doing reconnaissance, exploiting misconfiguration,
and navigating Microsoft's vast infrastructure
as if they were real adversaries. So today, it's
also about using AI to investigate things such
as understanding the details of an API attack
surface without having to page through tons of
websites and documentation. I am in awe every
day of their technical depth, creative thinking,
and the persistence that these engineers have
to execute on a day -by -day basis so they can
chain all the research and tooling together seamlessly
to turn small weaknesses into meaningful breach
paths. The other half of the job might surprise
people. It's all about influence. It's focused
on communication, which means writing, writing
down the findings, presenting to engineers, engaging
with product teams and building long term relationships
across the company. So a red teamer just can't
find a flaw. They have to explain it, persuade
others to why it matters and drive real change
and verify that that change is effective. So
technical excellence is essential, but so is
empathy, clarity and collaboration. To summarize,
being a red teamer is part hacker, part diplomat,
and part detective. There's a video that I often
refer people to. It's about a decade old now,
and it's from a gentleman by the name of Rob
Joyce, who at the time was the director at NSA.
He gave a talk at Usenix that's infamous in red
team circles and available for YouTube if you
want to check it out. One of the things that
he says in this video has stuck with me throughout
my career, and that is, you know the technologies
that you intend to use in your network. We know
the technologies that are actually in use in
your network. And today, that quote is even more
relevant. And it's such a part of the day in
the life of the red teamer. Because with the
explosion of cloud services and APIs and open
source libraries and microservices, organizations
are assembling these super powerful systems with
countless dependencies. And red teamers have
to understand how those systems behave under
pressure and not just how they're designed on
paper. So a day in life is never routine. It's
really chasing down real world edge cases and
helping the organization learn from them to become
more resilient. So we always ask, I guess, something
else at the end of the episodes, which is if
you wanted to leave our listeners with one final
thought, what would it be? I'd say, you know,
attacks, attackers are moving fast and AI is
going to speed them up. But you always have to
remember as a defender that you control the terrain
that the attackers have to operate in. You can
slow them down, you can expose them, you can
shut them out, but only if you're designed for
that and you understand how the attacker works
so you can define and implement the right terrain
for what you're trying to accomplish. You own
the terrain. All right, let's bring this episode
to an end. Craig, thank you so much for joining
us this week. I know you're busy, guys. So we
really appreciate you taking the time to spend
time with us. And to all our listeners out there,
stay safe, and we'll see you next time. Thanks
for listening to the Azure Security Podcast.
You can find show notes and other resources at
our website, azsecuritypodcast .net. If you have
any questions, please find us on Twitter at AzureSecPod.
Background music is from ccmixter .com and licensed
under the Creative Commons License.