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
119. This week it's myself, Michael, with Sarah
and Mark, and our guest this week is Ryan Makababa.
And we're here to talk about kind of what Ryan's
been up to over the last few years. We actually
interviewed Ryan about five years ago now. And
I'm saying this with a bit of a smile on my face
because I couldn't get Ryan's last name right
at all. The good news is we actually still have
a recording of that. So at the very end, if you
want to have a bit of a laugh, go and listen
to me completely messing up Ryan's last name.
But before we get to our guest, let's take a
little lap around the news. Sarah, why don't
you kick things off? Okay, well, it's that time
of year where the AI tour is starting again.
So the day that we're recording this, I am packing
my bags to go away to start the AI tour for the
financial year. 2026. So if you've been to the
AI tour in previous years, you'll know it's a
one day event. We do it in various different
cities around the globe. It's usually about 40
of them. So there could well be one near you.
So I'll put the link. They are still being all
planned out at the moment. So you can have a
look at the link to see if there's one coming
near you. It does get updated. I know not every
city is on there immediately. So go and have
a look. And depending on when we release this
one, if you happen to be in Chicago, Toronto,
or Ottawa for the AI tour, I will be there. So
yeah, go and have a look. There is security stuff.
You can obviously go learn more about AI and
just have fun at Microsoft events. I'm biased.
I love a Microsoft event, of course. So yeah,
just that one for me. Cool. So a couple updates
in my part of the world. We did... Update the
access and identity module of the security adoption
framework or SAF. So these are workshops that
any Microsoft Unified customer can get delivered.
And so we just did a refresh of that. We're working
on the security operations or SOC ones now as
we speak. Recently published some of the learnings
that we've made around AI anti -patterns and
best practices. Obviously focused on security,
but the anti -patterns are just common mistakes.
Pattern is anything you do over and over. Anti
-pattern is one that you don't want to do because
it's ineffective or counterproductive. And so
I'll pop a link to the LinkedIn feed on that
one so you can check that out. And then just
in general, it had been a little while since
I had updated the marks list. So it's an article
I maintain on LinkedIn with kind of a list of
a bunch of different resources that. A bunch
of different resources that I provide, as well
as other ones that I refer people to and use
all the time. And so it's just aka .ms .markslist.
Again, the link is going to be in the show notes.
But, you know, I just kind of organized it, cleaned
up some of the older links, the dead links, added
a bunch of the work on the open group standards.
That's one of the big updates there. And, you
know, a couple of newer Ignite session recordings
and, you know, Zero Trust in AI White Paper.
You know, some of the phenomenal work for the
Zero Trust Practice Guide and a few others. So
that's what I got this week. All right, I have
a couple of, actually I have three items. The
first one is Azure Databricks. Automatic identity
management is now generally available. I'm going
to be honest, I'm not an expert in Azure Databricks,
even though I was in Azure Data for a long time.
It was a bit of a mystery to me. But apparently
it now has automated user provisioning and deprovisioning
through native integration with Microsoft Entry
ID. Anything that integrates with Microsoft Entry
ID, so you've got access to those identities,
as well as support for all the nice things like
conditional access and what have you that come
with that, is always a good thing. Ultimately,
this is all about simplifying that workflow of
managing identities. Next one, also from my old,
my old stomping ground is Azure Cosmos DB for
MongoDB encryption with customer managed keys
is now generally available. I know we've mentioned
it in the past, but now it's generally available.
So this allows you to control the encryption
keys or more accurately, the wrapping keys that
actually wrap the symmetric encryption keys.
You can now control those because some compliance
requirements require that. But remember, if you
lose that key, Microsoft does not have a backup.
So make sure you control that key. The last one,
which is a bit of a mystery. Look, I've got to
be very careful what I say here, and I'm going
to be really honest with you. I'm a bit of a
TLS nerd, and I'm also a bit of a TLS purist
as well. So this is generally available as backend
TLS validation controls in Azure Application
Gateway. And essentially what it allows you to
do is control certain aspects of validation of
certificates. I have a philosophical issue with
this. Again, I'm sure that there are customers
out there that need this while they're experimenting.
I completely get that. But I do want to make
sure people are aware of what they're doing when
they do this. So it essentially allows you to
enable and disable things like certificate chain
validation and expiry date. So if you've got
a certificate that's expired, then you can still
go ahead and use it. The application gateway
will still allow the connection to occur even
though the certificate has expired. Things like
validating SNIs. There's a few other options
in there as well. I don't like it. I mean, I
get it. Look, I get that there's some customers
who may have issues and this will get them out
of a hole. I get that. Even the documentation
says, we recommend keeping all validations enabled
for production environments. Disabling some or
all of these validations is suggested only for
testing and development purposes, such as when
self -signed certificates are used. I get that,
but I still don't agree with it. Because if you're
using self -signed certificates in development
or in testing, you're not actually, especially
in testing, you're not actually testing what
is going to be rolled out into production. You
should be using a real certificate in testing.
and production and development. It doesn't have
to be the certificate that's used in production.
It can be a certificate that's used in development
and testing, but it's still a valid certificate.
It still chains up to a trusted route. It may
be one that's issued separately. That's completely
fine, but it still chains up to a trusted route.
You're doing all the certificate validation.
Because if you turn this off in testing and you're
not doing, say, date validation, And then in
the future, the date becomes incorrect in production.
Now your system fails in production. Again, I
get why that's there. Just be really super, super
careful if you're doing all this stuff. And again,
I despise self -signed certificates with every
fiber in my being because they're useless. And
again, I hear people say all the time, you know,
oh, we just use them in testing. It's like, no,
don't use real certificates. that chain up to
a real trusted root, but it's not the same one
necessarily as used in development, but it's
still a valid certificate with valid dates and
valid names, everything. And I realize someone's
going to probably comment on what I just said,
but anyway, that's just my philosophical perspective,
but I'm right. Anyway, let's move on. I'm right
with you on the self -signed thing. I never really
liked the self -signed thing. So we're right.
So we're right, not just me. So we'll both get
a lot of that comment. We'll both get the flag.
Fair enough. All right, let's move on to our
guest. Now that I've got my news out of the way,
as I mentioned, our guest this week, who's actually
coming back from, so we're at episode 119. We
last had Ryan on the podcast, episode seven.
So that was July 20th. That was five years ago.
So basically what we're trying to do here is
just catch up with Ryan, see what's going on,
what's changed for Ryan and what sort of stuff
she's working on, especially in the area of enterprise
strategy and enterprise architecture and strategy
from a security perspective. So Ryan, thank you
so much for coming back. I'm very happy you've
come back, but would you like to take a moment
and introduce yourself to our listeners? Sure.
I will say that my name is Ryan Makababad. So
you're still getting it wrong, but you're much,
much closer. So good job. And I'm a principal
security program manager. I'm at Microsoft and
I'm part of the enterprise security team. And
basically what I'm doing right now is working
across the company to ensure that everyone is
aligned on taxonomy and in understanding exactly
what our requirements are from a legal or contractual
or regulatory perspective, as well as what best
practices when it comes to how we as Microsoft
use the cloud. So yeah, that's what I'm up to
these days. So I know I still got your name wrong,
but I said the name better than the very first
time we first met. I mean, that was just that
was atrocious. Yes, you did. You did a lot better.
There's only the one the one syllable that you
got wrong this time. Oh, well, I'll call that
improvement. Ryan, you're obviously you're a
very busy person. I know this because we talked
about this and I like pre -record brief. But
I mean. What is the hardest part of your role
nowadays? What do you find the most challenging?
So I think that one of the things that I find
most challenging and why I'm working on it right
now, it's like whenever you say like getting
people to align on what policy is or what. you
know, our requirements are, like, that can sound
really scary. But the thing is, is that everybody
understands language differently. And we, we
all use language differently. And so like, when
one person talks about production, they might
be talking about first party. And when another
person is talking about production, they might
be talking about the stage in the development
life cycle that something is in, right? And so
if you use the same word within a policy, then
now you have to provide the context of what you
mean. And if you don't provide the context of
what you mean, then now what you've done is zone
confusion and discord. amongst the folks that
on that your audience that actually have to use
and implement whatever policy or standard or
communication that you've put out right so like
that's that's probably one of my biggest I don't
know, things in just life in general is how we
use language. Because we use words in ways that
they aren't intended to be used for. Or we use
words in ways that where we're assuming the knowledge
or experience or that the understanding of the
other party that is part of that communication.
So much gets lost in translation because of that
assumption. Can I just add something here? So
I'm a big stickler for getting words correct
in general, but certainly in security and absolutely
when it comes to cryptography. But let me give
an example. So I'll review things and people
say, well, we're encrypting the certificate.
I'm like, are you really encrypting the certificate
or are you encrypting the private key? Because
I don't really care that much about the certificate
because the certificate is public information
and it's protected with a digital signature so
it can't be tampered with. So there's nothing
to see there because there's nothing sensitive
in there and it can't be tampered with. So do
you actually really mean the certificate or do
you mean the private key? And I say, oh, we mean
the private key. Well, say that. And that sounds
horrible to say, but I'm like, just be really
pedantic about what you mean. And again, to your
point about assumptions, I assume, but I'm usually
wrong, I assume that people know the difference
between a certificate and a private key. But
surprisingly, a lot of people don't. Actually,
that ties into a lot of the stuff we're doing
with the roles in Glossary at the Open Group.
there's some things in precision within security,
but there's also, when you talk about governance
to a security person, that means something. When
you talk it to an IT person and you say governance,
it means something very different. When you talk
to a board member who has a fiduciary duty, a
relationship of trust to the shareholders, governance
has an entirely different meaning to them and
the CEO and CFO and chief operating officer,
et cetera. And the business operations people
also have a different view of it. And so that
was one of the interesting things as security
becomes a mainstream part of an organization.
And if a business person demands 100 % uptime
and doesn't fund anything for redundancy or patching
or whatever, and then you're going to blame the
security team for something that was out of their
control that you made a decision on. As we sort
of realize that security is a part of everyone's
job. all of these worlds and these assumptions
are colliding. It's not just within the security
space, but just like language is so, so important.
So a hundred percent agree with you, Ryan. Yeah.
And I don't, I don't think that it's pedantic
to say, like, say what you mean. Right. And,
and maybe that's because I'm autistic. And so
I need people. I like literally need people to
say what they mean, because if they don't say
what they mean, then like, I'm going to completely
miss. Like whatever passive and underlying communication
is going on, whatever nuance is going on that
they are assuming that I am following, right?
And there's nothing wrong with being pedantic
either. Like that's actually a good thing to
be focused on the facts and the meaning. Yeah,
but it has a negative connotation to it, right?
Yeah, that's true. But it's one worth breaking,
I would say. Yeah, I mean, I was in a conversation
just recently, and I can't talk about all the
details, but somebody on the call said, and we
need a security review. And my response to that
was, what do you actually mean by security review?
And again, I even said, I'm not trying to be
difficult to deal with, but what do you actually
mean? Do you want a review and feedback, or do
you want a sign -off? No, I'm going to go one
level below that. Code review, static analysis,
dynamic analysis, red team, pen test, privacy
review. I mean, what do you, you know, compliance
review? What does that actually mean? It turns
out that the actual answer was all of the above.
Well, in which case we need to work out who is
doing all that work and when, because all of
the above is actually a lot of work. Yeah, so
I think that I got really comfortable with asking
people what they mean. when I got really comfortable
with saying, I don't know what that means. And
I'll tell you that it was actually watching bones,
which was a, uh, a TV show about a, uh, like
a scientist who she's definitely autistic, who
doesn't understand like nuance. And, um, and
when, you know, people are, uh, kind of trying
to lead into something. And so like, I think
that I have had a lot of practice on asking people
like, what do you mean? I don't understand, but
leading with like, I don't understand what that
means. Can you explain it to me in a different
way? Or can you, can you provide me with more
context or can you expand on that? And also like
just telling people straight up, like, Hey, I'm
autistic and I need. I need more information
than maybe you might be used to giving so that
I can ensure that I fully understand what it
is that you're saying. And I think that that
helps a lot because then people think, you know,
like they are really interested in what I'm saying.
And so they're really putting in effort to understand
what I say. Yeah. And I think no reasonable person
would. would uh would disagree with what you
just said i'll give you a really good example
as well is because of the role that i'm in now
in the red team um i get to deal with a lot of
the as your back end like you know that thing
is full of code names and abbreviations and you
know heaven only knows what else right and i
don't know them all i mean i'm learning a lot
but i don't know them all and so i make a point
of actually saying to people hey i don't know
what the awful baffle gloop is would you mind
just taking you know Could you please explain
what that is? Or I'll send a little message to
someone and say, hey, what the heck's an awful
baffle gloop? No one has a problem telling me
what the things are. And in fact, there's a meeting,
there's a call that we have every day. The person
who hosts the call, it's a very important call,
by the way, the person who hosts the call doesn't
just explain for the first 15 seconds the purpose
of this meeting. She explains what the purpose
of the meeting is. And then there is after that,
if you have any... three letter acronyms, or
in the case of Azure, 17 letter acronyms, spell
them out, spell them out on first use, because
that's really important. And if you use a code
name, explain on first use what that code, what
that actually is, because not everyone on the
call knows what all those things are. It's like
the old meme, right? It's like, I don't know
what ABC is. this point I'm too afraid to ask.
We need to not do that. We need to make sure
that everyone understands exactly what all the
acronyms and code names and product names are,
are certainly on first use. Yeah. I mean, like
people are afraid to look, you know, like quote
unquote dumb and they're, they're afraid to ask
a quote unquote stupid question. And so like
I try, I, and I try to do this a lot with, with.
Just being like the advocate, saying like, hey,
I'm going to ask what might seem like known information
or what might seem like stupid questions. I might
be asking for myself, but I also might be asking
because I know that there are other people that
don't know what that means. Oh, 100%. Especially
early in career, people are more afraid of that.
So I think it's part. Part of our obligation
as experienced people in the industry to help
make that okay. I remember, this is a while ago
now, but I remember it like it was yesterday.
I actually said, hey, I'm going to ask this question
because I know full well that probably 20 people
on this call are asking the exact same question.
So I asked the question. So I took the hit, air
quotes, took the hit. You'd be amazed how many
messages I got asynchronously saying, thank you
for asking because I had no idea what that thing
was either. And I've been around long enough
that people, I don't even know how to put it,
I've been around long enough that I can ask the
question without putting anybody, you know, no
one's going to feel bad about me asking a question.
I'm so glad Michael asked that question because
I've been in the company for three weeks and
I have no idea what it is. It's funny you say
that because I have started. I have moved teams
recently and there are a lot of acronyms being
used that I don't understand. And I do ask most
of the time, though I can understand the reluctance.
And though I did have a couple of people tell
me afterwards, people who've been there a lot
longer saying, oh, yeah, I didn't understand
that either. So, yeah, I feel this very much
so. Well, and the thing is, is that that's that's
really common, you know, that like people, nobody
wants to put their reputation online and some
people can't. Right. Or they feel like they can't
for whatever reason or because of the environment
that they're in. And that's totally OK. You know,
like we're all at different places in our journeys
to be able to ask the questions that. may make
us feel self -conscious or or that ask questions
that like may make make other people have a certain
perception of us and I'm at a point in my career
and just in my my life that I can ask questions
and recognize that people might have opinions
about me because of it but Their opinions don't
matter that much to me if they can't give me
grace for learning, right? If they can't give
me grace for making a mistake. You know, it's
funny you should say that as well because I think
most people that know me well know that I make
fun of everything. I'm always laughing at things
and I always find humor in things. So when I
say I don't know something, I always do it with
a smile on my face. And I even say, hey, you
know, I'm asking this because I know a lot of
other people have no idea what the heck you're
talking about either. In a nice way. But yeah,
you're absolutely right. So I think that's such
an important thing is don't assume that everyone
knows. all the backstory, all the inside baseball
stuff. That's even inside baseball, unless you're
in the US, you don't even know what inside baseball
even means. So, Mark, would you mind explaining
what inside baseball is? I'm in the US and I
don't know what that means. Well, there you go.
Mark, do you know what inside baseball means?
If not, I'll give you my really bad interpretation.
Just inside knowledge, I think, is probably the
best way to describe it, is that only people
who are in the in -group would understand this
terminology. And that could be deliberate or
it could be accidental. But that's really what
it means. It's just inside, not so much inside
information, but just inside context to interpret
the information you just got. And I would argue
that AI is in that position right now. There
is so much technical stuff about AI that... You
know, there's new words that are popping up constantly
and you need to understand what those words are
if you're working in AI and the odds are extremely
good you don't know what many of those words
are. I certainly don't. I still read articles
once in a while which are basically AI 101 because
the AI 101 this year changed from the AI 101
three years ago. There's things that didn't exist
in AI. especially from a security perspective
so it's really important you stay on top of some
of that wording yeah and it's moving really really
quickly and i think like the same thing needs
to happen with so like when i when i say that
i'm I'm you know trying to align everyone across
the company on on you know these different requirements
and policies and stuff it's it's because it's
it's difficult to understand it's because like
there has been so much growth and evolution and
and innovation in the technologies that we've
um that we've been working with but also in in
you know In the different laws that we have to
exist in and the different markets that we that
we operate in. And so it's like you have to be
able to distill these things down into easily
digestible information like the one on one on
one articles that you're reading, Michael. Right.
So when you look at these at these like a company
policy, for example. you have like three different
people that have three different interpretations,
even though they're all reading the same thing
because of the language that's used. Like it's
not, it's, it's legalese and there's nothing
that, that translates it for you. So I will use,
I will use things like Copilot or, you know,
whatever I'm using in, in my, in my personal
life. I use this, I use a tool called goblins,
goblin .tools to, change the way that I'm saying
something and the tone of what I'm saying it
in so that it's friendlier or more social or
more professional because I need that in my life.
I just try to speak directly and sometimes that
comes off aggressively, I guess. I was actually
just having a conversation the other day with
someone because When someone learns English as
a second language, the first words you learn
in English, because there's usually five or ten
ways of saying anything in English, are the most
direct and clear and simple ones. And sometimes
those are interpreted as rude or overly direct
as well. And so this actually hits English as
a second language speakers extra hard. Yeah,
because, well, it's a regional thing, right?
It's based off of, like, if you grew up in the
Midwest, there are certain things that you can
say that you can't say elsewhere and vice versa,
right? You can't, in some cultures, right, someone
will refuse something. For example, if you offer
something to them, they'll refuse it and they'll
refuse it like three times. And you have to keep
on offering it because that's the expectation,
even though they said they didn't want it. they
were being polite. And if they do the same thing
to you, you have to do it in the reverse, right?
I can give you a great example of this, which
is from my part, well, from my part of the world.
So in the UK, and for our UK -based listeners,
you can feel, you can agree or disagree with
me, but What we do is if you are, and I realize
I'm stereotyping here, but if you've gone around
to someone's house and you've got tea and biscuits,
if you say, would you like the last biscuit?
Basically, you're not asking if anyone would
like the last biscuit. You're basically saying,
do you care if I have the last biscuit? Or it's
really more of a statement of I'm going to take
the last biscuit. FYI, but it's phrased as a
question. And I would be very upset. Well, I'd
get over it. But I would be very upset if I said,
hey, does anyone want the last biscuit? Because
the correct, correct, I say in inverted commas
answer to that is no, you have it. But I think
it's something you would only know probably if
you grew up in the UK. Yeah, if someone took
my last biscuit when I've asked that question,
I'd be. A little bit disappointed. Yeah, because
I would totally say, oh, yeah, I would love it,
especially if, like, I would love it. But, you
know, like, I've learned also that when somebody
offers you something, that they're being polite,
and so you should accept it. So that would totally
not work in that situation. I actually taught
my daughter, and this is probably an example
of bad parenting more than anything else, but
I taught my daughter to not ask that question
because if you want that biscuit, one of the
US cookie, and you want it, then if you say,
you know, whatever you just said, Sarah, that
you run the risk of someone actually saying yes,
someone like Ryan saying, yes, I want the biscuit.
Whereas, so I taught her to say, no one wants
that biscuit, do they? Because that's a more
direct way of saying, I want the biscuit. No,
it is. And you're not wrong, Michael. But yeah,
I was definitely brought up to be like, would
anybody like the last biscuit? I don't actually
want you to take the biscuit. Why can't you just
say, I would like the last biscuit. Would anybody
like to share it with me? Would you mind if I
had it? Yeah, I wouldn't mind. Still rude. The
correct response is, oh, no, no, no, you have
it. That's the correct response. So, Ryan, so.
This has been a really, really fun conversation
where we kind of wandered a little bit away from
the, I'm trying to think of a baseball analogy,
but I will fail. But off of the point, can you
talk a little bit about where you see this happening
in the real world and industry? I'd love to hear
some stories, if you could share. So I've worked
with literally hundreds of customers across various
different industries, markets, all over the world.
And some of that was in identity when I was working
in identity. Some of that was when I was working
on Microsoft Defender team. And so I've worked
with all of these different companies and different
teams within their organizations. It's so funny
when you get security and IT and security and
legal or all three of them all in the same room
because they all have what? at the surface level,
is the same requirements. But then when you start
digging deep into it, they completely do not
understand what each other's requirements are.
Because security is looking at things from a
hardening point of view, right? Compliance is
looking at things from a proof and attestation
point of view. Right. Legal is is looking at
things from a how do I keep my company out of
hot water type of view? And then you've got privacy,
which is like, OK, we need to make sure that
we are in compliance with GDPR so that four percent
of our our global annual turnover is not something
that is on the table for, you know, fines and
penalties. And and so like the language that
they're using internally, though. completely
conflicts with each other uh because the definitions
of the language that they're using the words
that they're using is not centralized right and
and that's that's been at whatever company i've
been uh working at and also whatever company
i've been working with like i can even tell you
like in the army where things are supposed to
be you know um distilled down to the the lowest
level so that you know even a a private can understand
the language like you will get a reuse of terms
and reuse of acronyms and you'll get language
that is used in different ways but it is the
same word or the same acronym and so now you
have different requirements based off of the
understanding of what that word is within that
organization, within that business unit at that
company. And I have yet to see centralized taxonomy
that has actually been saturated. throughout
a company. I mean, even at Microsoft, you have
so many different glossaries, you have the security
glossary, and then the Microsoft glossary and,
and each, you know, organization, the sales organization
has their own glossary. And And that makes it
really difficult for us to all speak the same
language and reach the same goals, I think, because
we're not understanding exactly what each other
is saying. Isn't the open group working on some
of that stuff, Mark? Funny you should mention
that. Yes, we have a security roles and glossary
standard that should be, all things going well,
should be out by the end of October. We're going
to be talking about it at the open group conference
in early November. So we should at least have
some basic baseline out there for a clear glossary
on what a lot of these meant. And it honestly
took a lot of work to get some of these things
locked in. Risk was one of the ones that was
interesting. We found that there's risk as a
noun, which is a very specific thing because
it has to be measurable. So probable loss, probable
frequency, I think something like that. But then
risk is also an adjective. And so we ended up
doing... a lot of work to just make sure there's
clarity. We look through the NIST definitions
and the dictionary and a number of other different
sources as well to, to resolve it. So, you know,
we were, I can't guarantee that every word that,
that, that you need is in there, but we are,
we are making some progress on, on burning down
that problem. So Ryan, if you could rewrite every
company's security policy, what would be the
first thing that you would fix? I think that's
going back to the word production that I was
talking about because we have, I think, a responsibility.
Not just Microsoft as a company, but like all
companies that are in any way a SaaS provider
or a cloud solution provider, right? To fulfill
the promises that we have made to our customers
and the expectations that we have aligned on
how we set things up internally. And again, I'm
not talking about Microsoft. I'm talking about
like generally speaking, in my experience. If
you don't have the same definition being used
of production of, and when I say production,
okay, I'm saying the environment that is customer
facing and is hosting your first party apps,
services, and tools that you are offering to
your customers. That's production. That's your
production environment. And then you have your
enterprise environment and that's where you conduct
all of your operations. That's where all of your
business is going on. Right. But that's probably
the first thing that I would fix is just that
that word. It's it's it's a thorn in my side.
So Ryan, the last last couple of things that
we ask are, you know, first, you know, what's
a day in the life look like for you? Kind of,
you know, just. average annual life aggregate
whatever works for you and then any final thoughts
you have for our listeners sure um that's actually
that's pretty neat um a day in the my life for
for work usually involves a lot of research.
I actually use Copilot a lot when I'm trying
to put together my thoughts and put together
my research into a cohesive message because I
suffer very greatly from the... blank page syndrome
so like if I don't have something to edit then
it's really difficult for me to get started so
I would say like doing a lot of research a lot
of writing but also just communicating with with
folks and trying to get them to understand what
the different meanings of things are and and
convince them a lot like a lot of my job is really
influencing without authority And taking what
I know to be true and distilling it into the
language and not just the language, but also
the factors that are important to that person
and how it pertains to what their KPIs are, what
their objectives are. So that's my day to day.
In terms of final thoughts, I would say that
whatever it is that we... we are doing whatever
it is that we are experts in like we can't expect
other people to be experts in the same thing
and if we really want other people to to be successful
in doing the things that they are experts in
when it comes to the things that we are experts
in we put up the the guardrails for them so that
there isn't an option of straying outside of
outside of the left and right boundaries, right?
Because we have used our own expertise to make
it easy for them. So for those folks who... Yeah,
everyone should be security conscious and security
aware, but everyone should not have to be a security
expert in order to do their jobs securely. As
security professionals, we should make it easy.
We should enable and empower end users to do
their jobs securely. Instead of being the department
of no, we should be the department of yes, and
here is how you do it securely. That would be
my final thought and kind of what I live my professional
life by. How can I make this easier on folks?
Yeah, I think that's really important. I mean,
it's such a dynamic area full of three -letter
acronyms, full of code names, full of products,
full of technical jargon. You just can't expect
everyone to understand those sorts of things.
I had a similar problem when I was in Azure Data.
They would throw around database acronyms. things
and technology and code names. I had to keep
going to my boss to say, you know, what the heck's
this thing? I have no clue. So yeah, I agree
100%. This has been a really interesting episode,
actually. We've never really spoken much about
sort of security language, whether spoken or
written down. So I think this is a very interesting
episode. So yeah, so thanks for joining us, Ryan.
I think this has been really, really cool. So
yeah, so let's wrap this episode up. As I said,
thank you so much for joining us again, Ryan.
Thank you for coming back. And to all our listeners
out there, we hope you found this episode of
use. Do the outtake. Yeah. Stick around and we'll
do the outtake from five years ago where I terribly
messed up Ryan's last name. I just couldn't get
it right. Can you get it right now? Mark Ababad.
Hey, there you go. I learn quickly. All right.
Again, thank you for joining us. Stay safe and
we'll see you next time. Makubabad. Makubabad.
No. No. Makubabad. Makubabad. Makubabad. What
is wrong with me? Makubabad. Makubabad. I'm just
slower. Makubabad. Makubabad. There's no R there.
Makubabad. Did I say Makubabad? It's not bar.
It's ba. Like Bah Humbug. Like Baa Baa Black
Sheep. Yes. Marku Babad. Marku Babad. Marku Babad.
Why don't we just have the whole podcast, me
just saying your last name? 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.