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 72.
This week's a little different.
The podcast has been going now for almost three years.
This week, we're just going to interview everyone.
We're just going to talk between ourselves,
discuss what we've done at Microsoft.
Things have changed for all of us
career-wise within the company.
I think it would just be really useful to get an idea of what we're doing,
what drives us.
But before we get to our little discussion,
let's have a little lap around the news. I'll kick things off.
The first one is IPv6 support is coming to Azure AD.
That includes things like conditional access policies
and all sorts of policies like that,
where you can actually not just use IPv4 addresses,
but you can also use IPv6 addresses.
The other item is I wrote a blog post.
There's a feature which we talked about a lot
from this podcast called Ledger.
That's in Azure SQL DB and in SQL Server.
It's all about validating that transactions have not been tampered with.
What turns out is that it's really useful for repudiation of receipt threats.
If you're familiar with building threat models,
the R in stride,
which is how we think about what an attacker wants to do to assist them.
For example, S is spoofing.
If you've got a process, how do you know that's the real process and not a rogue?
That's a spoofing threat.
Well, one of them is repudiation and that's the R in stride.
It turns out that Ledger is actually really good at mitigating repudiation threats,
or at least repudiation of receipt.
I actually wrote a blog post on repudiation of transmission,
repudiation of origin, and repudiation of receipt,
and talk about things like immutable blood storage,
and especially the compliance requirements around that.
It's a slightly different read in as much as it's talking about an area
that a lot of people don't really think about much.
So yeah, take a look.
Next one is we're moving full steam ahead,
and I know that Mark will have an opinion on this,
but we're moving full steam ahead with using
number matching for multi-factor authentication.
This is going to be huge.
It's a really important part of MFA, I think.
So yes, keep an eye out on that.
And the last one is a colleague of mine, Buck Woody and David Seiss,
have written Soup to Nuts, Zero to Hero,
Introduction to Security in SQL Server and in Azure SQL DB.
Really well worth it, very well written, completely in-depth,
covers absolutely everything.
It's well worth the read.
So that's what I have this week.
Yeah, it's funny you mention that because I actually just did
a in-person event, first one in a while,
with Buck Woody in the Tampa office for Microsoft, Tampa, Florida.
And so it was just kind of funny.
It was all about security.
So I did the overall security thing,
and then there's a bunch of other sessions
that Buck and some others did on securing your data.
So it's kind of funny that you mention it.
It's a small world, right?
It is a small community, yes.
I think the world is still physically as big as it ever was.
It's just we're connected better.
So on my news side, the big news for me is,
and I think for Gladys and Sarah as well,
as well as Yuri Diogenes, is that the exam reference for SC100,
the cybersecurity architect, the book, the exam reference book,
is out.
Really excited about that.
I think I put my LinkedIn post the first time
my name has appeared on the front of a book, which
is kind of cool.
So that was pretty exciting.
And we put a lot into that one around really practical,
no-holds-barred advice on what an architect is and does,
as well as all the topics related to the exam.
Compliance really kind of called out the great things
about compliance, as well as the things
that compliance is not security.
And here are some examples of how it doesn't do that.
So really meant to make that as practical as possible
for both the exam and the real world.
This one, I don't have really any links or anything
to announce, but we're working hard on the zero trust
standards at the Open Group so that there
is a standard way of expressing zero trust
security, which is really just modern security
without the whole, it's behind the firewall,
so therefore it's a kind of flawed assumption.
So we're working on getting that standardized and released.
The first one out will be kind of a combination
of the core principles and the zero trust commandments
that are out there today.
A little bit of new elements and insights on it,
but mostly kind of a release those as an actual standard.
Another thing that I've been putting a lot of work into
that just finished was the architecture design
session module three, which is basically a security operations
or SOC module for the workshops that we put out
through Microsoft Unified.
And so this is in the normal Microsoft Unified catalog.
And so if you look for security architecture workshop in there,
you'll find that module one and module three are now available.
And if you don't have access to the portal or what have you,
just reach out to your account person or your CSAM
or customer service account manager,
I think they're called.
But yeah, that one's available, and we are scheduling
our first deliveries now.
The other thing I've been doing a lot of research and work on
for a number of different reasons
is how do roles in security actually evolve,
and when do the specialties or specializations actually
get created, and why and when, and who
does the specialization of the job
if you don't have a 20, 30, 50, 100-person team?
Who inherits that and does that work
until there is someone dedicated to it?
And so including a couple of links in the show notes
to some of the work there to try and discover that and validate
it.
If you all have a strong opinion there,
go forth and check them out if you're
interested in learning it.
We've got one for security operations,
and then the sort of general technical roles as well.
So that's all I got on the new side today.
Let's switch gears into kind of interviewing
each other type of mode.
We should probably start with just introducing ourselves
and kind of what we currently do,
and then we can kind of get into some questions
and interview each other.
My name is Mark Simos.
I'm lead cybersecurity architect at Microsoft.
Not a lot has changed from a job role for me.
I mean, I've actually changed where
I happen to report to within the organization,
but I've been doing the lead cybersecurity architect thing
for a number of years now.
And so in that role, I basically build guidance
to help various different roles of customers,
everything from CISOs and business leaders and board
members on occasion, and security architects
and security analysts and engineers and operations folks
in IT, et cetera.
Take a look at the broad swath of Microsoft's cyber
capabilities and features and technology.
Take a look at the changing technical platforms.
Take a look at the changing business priorities
and initiatives that are going on,
the changing threat landscape, and build reference
architectures, reference strategies, top 10 lists,
workshops, et cetera, to help people kind of make sense
of all of this stuff that most people don't have time
to kind of keep up on themselves.
So really kind of that's my job is putting out
that reference stuff and then helping our folks that
help our customers train them up,
get them ready to deliver those and take
care of our customers.
So my name is Gladys Rodriguez.
I've been in Microsoft for 16 years last week, actually.
14 years, I was mostly a customer-facing resource,
helping a customer implement architect solutions.
And the last two years, I've been in what
is called strategic mission-side technologies.
This is our organization that puts many solutions
or many services within Microsoft in order
to provide business solutions to customers.
And what I'm going to explain actually
is 180 degrees from what I used to do two years ago.
We are using all the Azure services in order
to bring, for example, telecommunications capabilities
to customers.
And some of this is using satellites,
using ground stations.
And these services, you may have heard it as Azure Orbital
or Azure Space.
There is a work that we're doing with quantum.
There's a lot of different things.
It's a lot of learning, but it's really cool trying to secure
all these capabilities.
And like Mark mentioned, I just had my first time, my name
also in the book.
So I'm really excited about that.
I am Sarah Young.
I've had a couple of roles in Microsoft
since we started this podcast.
But I am now a cloud security advocate.
So what that means is I am in the advocacy team.
You may also know it has other names.
But some organizations call it developer relations.
But of course, because I'm doing security,
I don't just talk to devs.
And the idea is that we advocate to and on behalf of communities.
So for me, of course, it's the security community.
So that means that I'm trying to talk to the community,
attend events, see people, meet people,
give you lots of stickers, but also take any feedback you have
back into our engineering teams.
Because Microsoft is a bit of a big beast.
And it can be really difficult to get feedback
into the right places.
So that's the kind of things that I do.
I also try and look for gaps in our content.
I use content in the loosest sense of the word, so blogs,
documents, videos, whatever it is.
If there are gaps and we're not addressing a particular
community's needs, we'll try help with that too.
And on that note, if anyone has any ideas,
feel free to tweet me.
If you think you see a glaring hole that we have missed.
But that's what I do nowadays.
I'm also back in Australia because I have moved countries
a few times since we've been doing this.
So if anyone hasn't caught up with what country I'm
currently in, that would be Australia.
And Michael, over to you.
Thanks for that, Sarah.
I'm Michael Howard.
I've been at Microsoft now.
Actually, last June, I just hit 30 years at Microsoft.
Right now, I'm actually working in the Azure data team.
So I'm working on engineering for Azure SQL database, SQL
server, Cosmos DB, Postgres SQL, and MySQL.
So it's all the backend stuff, all the backend security
stuff for those products.
Interesting, fun fact.
So when we had, for those of you who remember, so last year,
episode 51, on April the 18th, we interviewed Thomas Weiss
from the Cosmos DB team.
While Thomas and I were actually, sort of, in the air
quotes, in the green room, just discussing stuff,
before Mark, Gladys, and Sarah joined, he actually said to me,
he said, hey, how do you fancy moving over to Azure data?
And I said, yeah, sounds like a great idea.
And literally, so the balls started rolling then.
And by the end of May, I was actually
working for Azure data.
Great team, fantastic team, great engineering people.
And my main focus now is just on that.
So it's the engineering that goes
into securing those products, both the actual running
products, but also the infrastructure
on Azure in the backend.
So yeah, it's really great to be back in engineering.
Software engineering is my first love.
So yeah, really excited to be back doing that.
So with our sort of introductions out of the way,
Mark, why don't you sort of continue the thought?
Yeah, absolutely.
I have a curiosity for you.
It's actually, let me do a quick story first.
One of our past guests, who I won't name,
was when they came on the show, they're a great guest
and had a really good session.
And then afterwards, they made a comment to me,
like, I was so intimidated and had imposter syndrome
because you're on the podcast and whatever.
I'm like, you know who Michael is, right?
Because he was the guy that I was intimidated
with when I started at Microsoft,
because I've only been at Microsoft only 23 years.
And Michael was the big name in security.
So dialing the time machine back to that era,
I love to hear, because I know the software development
lifecycle was kicked off by that famous Bill Gates memo
that got things going.
But one of the things I'm kind of curious about
is sort of the program side of it.
I know there's a lot of technical training.
They stopped development of Windows for,
I don't know, a couple months or something like that.
And the thing I was kind of curious about is,
how did they end up doing the program side of it
in terms of, do they set up a group that did that?
Because I remember there was this trustworthy
computing group that was around for a while.
I'm just kind of curious how they approached that.
And did each team do their own kind of security?
Or was there a central center of excellence?
Or was it kind of a hybrid?
I'd love to hear more about that,
because I know a lot of organizations
are getting an application security.
And I'd love to hear how we went through that.
Yeah, I wish there was a really simple answer,
and there really isn't.
Everything you said was true, though.
So in the very early days of the Microsoft SDL,
the security development lifecycle,
we actually didn't have an SDL to start off with.
Like the team that I was in, which is run by a guy
by the name of Mike Nash,
was called the Secure Windows Initiative.
We also had, at the time,
the head of sort of security in Windows
was a guy called Doug Baer.
So he was also highly influential
in sort of what this group,
we called SWI, Secure Windows Initiative.
We were very much focused on Windows.
We looked at bugs, as we saw bugs coming in,
and then we would make recommendations,
especially if we saw trends, right?
If we saw, say, a specific API
with a bunch of vulnerabilities.
So for example, for those of you who know sort of low level C,
there's a function called stir copy,
and then there's mem copy, and there's a bunch of others.
We'd already like banned the stir copy,
but mem copy we eventually banned
when we had a good replacement.
But it was kind of very organic back then,
as we sort of learned our way,
and we sort of learned what it takes,
especially something the size of Windows, right?
But then we realized this is bigger than Windows.
We've got to go much bigger than that.
And so a whole series of things had happened.
Nimda had happened, Code Red had happened.
I was actually in a meeting with Bill Gates
to go over vulnerabilities,
and actually Doug Bale was with me,
but I was doing most of the yap-in.
And also Writing Secure Code had come out.
What was interesting there,
so David LeBlanc and I who wrote Writing Secure Code,
the reason why we wrote it was because we realized
we were getting asked the same questions
time and time and time again,
just basic engineering questions.
So we decided to sort of codify it in a book.
So I actually gave a copy of the book to Bill.
And the meeting that we had was actually on a Friday afternoon,
and on Monday morning, he emailed me to say,
hey, I read the book and absolutely loved it
over the weekend.
And so there was really a whole bunch of things
that all happened at the same time.
The.NET framework had also gone through a thing
they called the security push, sorry, security stand down.
My bad, it was called the security stand down.
And we were looking for vulnerabilities
before we finally shipped the product.
And there was a lot of things we learned from that too.
So back then it was very organic.
Now for the security push in Windows,
there was a central team that managed it
because it was so big, right?
Because Windows is just so big,
both in terms of lines of code complexity
and engineering stuff.
So it was very, there was a central team
and we had a separate bug database for tracking bugs
that were found during the security push.
And you're right, Mark, it was about two months long.
Actually more accurately, every group within Windows
was going to be done when they were done.
For some teams, that was four weeks.
For some teams, it was more than two months.
But you were done when you were done.
And we define what done was,
which is basically you've got essentially flatlining
on incoming vulnerabilities that are being found.
But the average was about two months, plus or minus.
Then we realized that we can't just build products
and then do a security push to find the bugs.
That's more like the wild, wild west
as opposed to actually engineering.
And so we decided to change things
and that became the SDL, the Microsoft SDL.
And as you mentioned, I was one of the guys behind it
with a gentleman who was my boss at the time, Steve Lipner.
He's since retired from Microsoft.
He and I, there's a lot of other people involved, obviously.
We started to sort of really codify what it means
around designing, developing, testing, coding constructs,
crypto requirements, threat modeling, fuzz testing,
static analysis, dynamic analysis, final security review,
security training, the whole nine yards, right?
And that became the SDL.
Now you could argue there's nothing new under the sun
and that's completely true.
But we documented a lot of that.
In fact, Steve and I went on to write the book
called the Microsoft Security Development Lifecycle.
Very, very proud of that book.
And at that point, we moved the SDL team out of Windows
and it became, actually it's funny as you say,
TWC, Trustworthy Computing,
because we ended up moving out of Windows
and into Scott Charney's team,
which was the Trustworthy Computing team.
So it became a corporate entity
as opposed to a product group entity.
And that has its own pros and cons.
But most importantly, funding, right?
Because if we wanted to fund an engineer,
we're not funding an engineer
that isn't going to Windows, right?
So it's not a decision like,
do we hire a security engineer
or do we hire someone who can fix device drivers
in the kernel?
That conversation never happened
because we were a corporate entity.
But then there's a problem of scale, right?
So there's no way that a hundred of us
could actually manage the whole of Microsoft.
And so one thing we ended up doing
was introducing this notion of security champs,
which was security experts
or people who had a passion or an interest in security
within the individual product groups.
And then we would liaise with them
to be the sort of the conduit of communication.
And then you sort of start breeding the skills
within the product groups.
And then it became a point where
the teams would actually just do their own thing.
So the SDL team became like a sort of a,
kind of a governance body.
And we would change the SDL.
We would update the SDL originally every six months
and then finally every 12 months.
We would add new requirements
or change things from requirements to recommendations
or vice versa.
But we became the central sort of governance team
helping all the engineering staff achieve their goals.
I don't know if that actually answered your question, Mark,
but that's kind of the history of it.
Yeah, that definitely helps.
Yeah, it sounds like we had to learn a lot of it as we go,
but like we definitely see a lot of organizations
having success with that champs,
kind of finding the interested and the willing
among their different kind of constituent teams.
You know, that sort of almost like a hub and spoke
type of approach where there's like the central authority
that's, you know, has knowledge, engineers depth, et cetera.
But then, you know, the folks that are closest
to the product, closest to the teams.
And we even do this with our security operations or SOC,
you know, using our CDOC approach, you know,
keeping those experts close to the actual products
and environments and then having that, you know,
the central thing they can rely on.
So yeah, that really helped.
I appreciate it, man.
And Gladys, I think you had a follow up question, right?
Yes, one of the things that I heard is that
there was a lot of training put together
for the different developers, for project managers
in order to learn how to embed security from the get-go.
Security threats are always evolving.
And now when we have cloud services, it just much more,
I would say bigger what you have to know.
And this is, I guess I would say it is more personal,
although I think it will impact, your answer,
it will impact many other people.
One of the things that I mentioned
when I introduced myself is I'm working
on strategic missions and technology.
And one of the things that I am doing is helping engineers,
the engineers or developers to embed security.
When they're building solutions across
the whole Azure infrastructure or Microsoft services,
overall services, in order for them to make sure
that they take into account all the security capabilities
that they could use, they have to know
about all these different services, right?
And Microsoft has hundreds of services.
So it's impossible to keep up and make sure
that you know about all the nitty gritty capabilities
that are being released, like continuous access evaluation,
that identity just released.
And I like that a lot because it's a way
to keep up because it's continuing
authenticating yourself.
There's workload identities, which now applications
that are authenticating to each other now can use
with that IP and if the request is not coming
from a particular IP, it would speed it up.
So my question is this, how would you see
the Azure organization keeping up in training
and enabling their developers to embed zero trust capabilities
or security and principles in the development?
What are your thoughts around that area?
Yeah, it's funny you should bring that up.
I've been doing a lot of threat models just recently
for SQLDB, SQL MI and Cosmos DB.
It's interesting because the threat model process,
even though the moving parts are different,
the questions are still the same.
The technology may be different.
So here's an example.
So back in the old days, we'd see an end user,
say it's in Windows, and we say,
it's a threat modeling question,
how do you authenticate that user?
Well, back then people would have said,
user username and password.
But what are you actually using?
Is it NTLM, is it Kerberos, is it basic, is it Digest?
What is it?
We still ask exactly the same question today,
the exact same question, but the big difference is,
is it AAD?
And by the way, the correct answer is yes, it's AAD.
Because that way I can apply things like conditional access
and that sort of stuff to it.
So it's interesting, the questions are kind of the same
that they were 20 something years ago,
but some of the mechanics are different.
But knowing those mechanics is really, really important.
So when I'm looking at a threat model
for some sort of Azure backend service,
basically the correct answer for server authentication
is TLS, today is always, absolutely is TLS.
Back in the old Windows sort of AAD environment,
it would have been Kerberos and potentially TLS,
because that gives you server authentication.
And then for channel protections, it's still the same, right?
It's TLS, and then for client authentication,
that's certainly changed from NTLM, Kerberos,
or whatever to AAD.
But again, the questions are still the same.
But to answer your question about how do you keep people
on board and up to date with what's going on,
this is something that the organization has to embrace.
The threats are constantly evolving.
They're just always evolving.
So for example, one thing that's raised its ugly head
a lot more over the last few years with cloud environments
has been what's called server-side request forgery
vulnerabilities.
And so there's a lot of tooling going on
and education going on and sample code
and this, that, and the other.
We're making sure that we can make sure
the engineering staff are well aware of server-side request
forgery vulnerabilities.
And there's lots of others as well.
Don't get me wrong.
That's just one example.
So yeah, I think it's incredibly important
that organizations do make it a point of training
their engineering staff.
What about your thoughts regarding developers
also taking into account any verifications
that they can do within the code instead of relying just
on Azure AD or endpoint protection
or all the other security, but the application
itself doing the verifications?
Yeah, actually, so it depends on the definition
of verification, right?
So one of the big ones that developers have control over
is the data that's coming into the system, right?
So if you've got some data coming in through a REST
endpoint or something, it's like you can't trust that data.
You've got to validate it.
So how do you validate it?
The funny thing is there's a comment
that David and I wrote in writing secure code 20-something
years ago, which is all input is evil.
When Simone Heinrich and I wrote designing and developing
secure Azure solutions, and I wrote.
Is that like the predecessor to zero trust?
Well, I mean, zero trust is obviously much bigger
than just that.
But it's the exact same concept of essentially assume evil
unless otherwise proven.
Yeah, and that's the mistake we're seeing.
We're still seeing it today.
And again, just getting back to the book, this new book,
I wrote the secure coding chapter.
And within the first paragraph I've said,
I actually say, hey, all input is evil
until proven otherwise.
It's the same that it was 20 years ago.
It doesn't matter if you're programming in Go, Rust,
or whatever today versus C, C++, and heaven forbid, VB,
back in the day.
That issue still exists today.
So there are some sorts of skills
that sort of transcend the programming
fashions of the day.
And I still believe strongly that we
should be teaching developers just that one skill,
if nothing else.
Do not trust any input into your system,
because that's where problems are going
to sort of manifest themselves.
Now with that said, that's a coding thing.
It's not a design thing.
You would not catch that as part of a threat model.
But I think from your perspective, Gladys,
about validating stuff, I think doing things
like authorization checks and authentication checks,
the threat model should show you the whole end-to-end,
like where you're doing the authentication
and where you're doing the authorization,
and more importantly, how it's being done.
But that should be in the threat model.
Thank you.
All right, so I've got a question for Sarah.
All right, so you've moved to the Antipodes, to Australia.
And I know you and I have spoken about some
of the differences between the countries, the US,
predominantly, and Australia.
But from your perspective, do you
find that the people you deal with in customers
have issues that are unique to their geography?
Or is there an approach to the way they handle cybersecurity?
What are the differences between the two countries?
Yeah, it's a super interesting question.
And I'd say probably this side of the world
is a shout out to the Antipodes.
Hello, Australia.
Well, it'd be cheesy to say good day, Australia,
and Kyoto, New Zealand.
I think something, and research does back this up.
And I think we're getting better.
But in Australia and New Zealand, for those of you
who have not traveled to this lovely part of the world,
and you should do at some point, people are very trusting,
definitely more trusting than other parts of the world.
And so for example, I know in New Zealand,
research shows that if you do a fishing exercise, generally,
maybe you'll get a 10%, 15% click through rate on, say,
your typical everyday workforce.
Whereas in New Zealand, it's more like 25%, 30%.
And that's because people are very trusting.
And they're not so used to scams,
because I think people who are doing scamming and trying
to breach things haven't traditionally always gone
for Australia and New Zealand, just because there are bigger
fish to fry, like the US and Europe.
But as time goes on and the awareness increases in the US
and in Europe, I think you definitely
are getting people targeting probably more Australia,
because there's more people here.
For those of you who don't know, I
think the population of Australia is about 25 million.
New Zealand is only 5 million.
New Zealand's a very small country.
I've been surprised at the difference
between when I was living in Australia before COVID
and now that I'm getting a lot more scam text messages
and emails than I remember here before.
It's more comparable with the US.
So I do think that I wouldn't say there's anything unique,
but I think down this part of the world, people perhaps,
to a point, have been less exposed to it.
But that's changing quite quickly.
And for those of you who are in Australia,
you'll know there's been a couple of quite high profile
breaches recently with some big companies.
So I think it's definitely top of mind.
And Australia has been making some really interesting inroads
into making cybersecurity a priority.
I mean, all countries are doing that right.
But I think given, let's say, the last six months,
it's something that's very much top of mind.
So I would say this part of the world
is definitely catching up very quickly with the awareness
and the knowledge.
It's not that it wasn't there at all.
I don't want anyone to take away from what I'm saying here.
It's just that probably the general public consciousness
perhaps wasn't as high.
But we're definitely getting there now because we have to.
Because as we know, even if we're just talking about scams
and people scamming people out of money,
it still does damage to people, right,
even if it's individuals.
So that awareness piece is definitely going up.
Michael, you've been down here.
You spent a little bit of time down here.
What's your take?
Yeah, actually, one thing that I've found
is that in Australia and New Zealand,
they're usually very, very quick to pick up new technologies
and new ideas as well.
There seems to be a little less resistance
to coming up with the reasons why not to deploy something
new.
For example, back in the day when
I was working in the IIS team, the first company
to reach out to me to try to help them with some cross-site
scripting vulnerabilities was actually an Australian bank.
They understood very quickly the ramifications
of cross-site scripting for their online presence.
They were using IIS at the time.
So I helped them out with sort of get rid of a few
that they had.
Because honestly, it wasn't really
a problem that was really known about.
And it was a bit of a mystery to a lot of people.
But the fact that the very first people
to come to me recognizing, hey, this is bad,
was actually an Australian bank.
So yeah, that's my observation.
Actually, just so you know, some of my very earliest days
at Microsoft in New Zealand, I actually
did support for Windows 3.x and then Windows NT,
but also the C compiler.
So I needed a lot of support for C and C++.
And I was always amazed at the level of expertise
of the New Zealand software developers who
were using C and C++.
They were really pushing the compiler.
And I did not expect that.
And I think that whole sort of can-do attitude,
which I know has been thrown around a lot in New Zealand,
is very real.
I'm going to switch gears here for a moment.
And I'm always trying to become a better ally and advocate
for women in technology and other underrepresented
minorities.
And Sarah and Gladys, I'd love to get your perspective on,
I know in my early days of that journey,
that it was very intimidating and very scary
to try and do the right thing, because I didn't
know what to do or what not to do.
And so I'd love to get your perspective on,
what are the things that you would recommend for men
that want to be an ally and an advocate
and help their female colleagues, what to do,
what not to do to sort of help in that space?
Oh, I have so many thoughts on this.
But my take on this is that we've still got a long way
to go.
But in fact, the majority of people
don't discriminate against minorities.
But I think because it has become socially unacceptable
to be overtly racist, sexist, is of any kind, what we see now
is it's pushed under the table a little bit.
So unless you're the recipient of that,
you wouldn't necessarily notice it was a thing.
And so the thing that I've taken away
from having many conversations with different men,
and I'm talking about this, and I'll just caveat,
I'm talking about this in the sense of being a woman in tech
only because that's the experience I can speak to.
I do realize that being a minority in tech
actually takes many forms, whether it's ethnicity,
religion, gender, et cetera.
So like I said, I'm just talking to my experience.
But I think this does apply to others as well.
Is that it's often that we need to just talk about it.
In fact, I'm doing a webinar tomorrow
with a colleague of mine called Jess Dodson, who's
been on the show, about women's stories from the tech trenches.
And we talk about recent examples
of where women have been discriminated against
or they've been talked down to.
But it's not as overt as someone just standing there and saying,
hey, sorry, you don't know anything
because you're a woman.
It's much more subtle nowadays.
And unless you're really looking out for it,
you wouldn't realize.
And I'm really surprised.
And I think we need to talk about this more,
because something that's always surprised me
is when I tell most ordinary people that I work with, hey,
yeah, this still happens.
Here's an example that's happened to me.
Just in the last week or two or whatever it is,
they're like, no, that doesn't happen anymore.
And it's not that they are consciously ignoring it.
It's because it's a little bit more subtle,
it's under the table, that a lot of folks
don't realize that this still does happen.
And so I think that awareness piece is really important.
So I'd encourage you, if they want to talk about it,
don't shove it down their throat.
Listen to the stories.
I can guarantee you that there will
be things that have happened in your workplace
or in your community where someone has said something
that's not appropriate, but you might not
have realized it, because, yeah, it happens.
But if you're not at the receiving end of it,
it can sometimes be very difficult to notice.
So I think being very aware is a thing.
The other one, and I could go on for a long time, but I won't.
My other pet peeve is that when we're talking about diversity,
and this has happened to me, you'll be like, oh,
minorities in the team, can you go do the diversity event,
please, or go and work on a diversity initiative,
when in fact, everyone in the team
should be working on the diversity initiative.
Don't just make it the women or, again,
whatever other minority.
It's not just their initiative.
We should all be doing it as good allies.
They're probably my two main bits.
And just as a final thought on this, because, as I said,
I could do a whole podcast on this,
is don't be naive in thinking that it doesn't still happen,
because it definitely does.
We're getting better.
There's a lot of initiatives, a lot of great people
out there working on it.
But if you're sitting there thinking,
oh, yeah, that's not a problem in my workplace,
I would definitely reassess, look again,
with maybe a bit of a closer lens.
Yeah, Gladys, how about you?
I have to agree that most people do not
realize when things like that happen unless it's really
happening to them.
And I have to say, there's companies
that do not really care about diversity inclusion.
Microsoft is heavily into diversity inclusion.
So I think whatever happens in Microsoft
happens less than many other organizations.
But it's something definitely important.
Look, I think even this podcast, I think Michael,
he was the original one that was put on us together.
He wanted somebody with diversity
and tried to think about, OK, how can I
bring that diversity here?
I'm hoping.
I never have asked, but I think that's the truth.
We are from different times zones, different experience,
different ages.
So I think that's the number one thing
that we need to do in order to make sure that we advocate,
not only for women, but diverse backgrounds.
The other thing that I think is really important,
I have this slide that I extracted from a Microsoft
presentation that it was talking about behaviors.
And it's 10 behaviors for diversity inclusion,
but I always love the first five or six that it mentions
because I think that helps to make sure that you include
everyone or advocate for those people, for everyone.
The first one is examine your assumptions.
When you're listening to people, sometimes we have assumptions
and we take decisions based on those assumptions.
The second one, make a habit of asking questions.
Third one, ensure all voices are heard.
That's really important because many times, Mark,
like you mentioned, everyone else also feels the same way.
We don't know what to do, when to do it.
There's something wrong, but we're not sure if we
should be raising our voice.
So there's people that stay quiet.
They're more timid.
So ensure that all voices are heard.
And there's a lot of women that stay quiet.
For example, when I first joined Microsoft,
I was in a room of 30 people and I was the only woman.
You know how intimidated that was?
Actually, I remember I was being in a meeting
that I was presenting in this company
and there were about 20 guys in technology.
And one of the guys said to me, Gladys,
it doesn't matter what ideas you bring.
We're not going to do any of them.
Imagine something like that.
So I have had experience in all areas.
And by the way, there were a lot of managers,
a lot of people in there.
And nobody did anything.
Nobody said anything.
And I stayed quiet.
It's something that I always think about.
The other one that it says, listening carefully
to the person speaking until she or he feels understood.
Because sometimes, me, I speak Spanish.
So probably some people that speak Spanish,
they understand me, but not everyone understands me.
I may use some wording that is not really
used in Australia, in New Zealand, et cetera.
Address misunderstanding and resolve disagreement.
Those are the five top behaviors that Microsoft
has in this slide that I think is really important.
And the last one is make sure you involve
different perspectives.
For the most part, the other day, I was in a project,
and I was like, oh, you know, I have this friend
and this other friend that could help out.
But then I was like, OK.
But we have similar perspectives,
similar experience, similar.
We were in the same team.
We did similar projects.
So we're not bringing that diversity in.
So just make sure that you include the woman as part
of the teams, as part of the group,
as part of the communication, meetings, et cetera.
Yes, in the interest of full disclosure,
when Mark and I were first talking about the podcast,
which was about now three years ago,
we met in a pub in downtown Seattle to talk about it.
And the decision was made almost from day one
to basically have as diverse a lineup as possible.
And I think the podcast is much better because of it.
So yeah, in case anyone doesn't realize,
there was always a decision very early on
to be as varied as possible.
And again, I think the podcast is much better because of it.
100% agree.
Yeah.
Yeah, and the other part of that,
and sort of more on the I side of D&I,
is I gave a presentation this weekend.
It's a thing called SQL Saturday in the Austin,
Microsoft office in Austin.
I discovered there's a new feature in PowerPoint
that actually does live subtitles as you're speaking.
It will even translate.
So if you're doing, say for example,
to a Spanish audience, it would actually
translate as well while you're speaking English.
But what was interesting is, so my slides were coming up,
and there was my almost perhaps a half a second delay,
maybe a second delay transcription of my audio.
And it was interesting because at the end,
these two people came up and actually
said to me, they said, hey, first of all,
what the heck just happened?
How did you manage to do that?
And I showed them.
I said, hey, it's this new feature in PowerPoint.
Then they said they actually really appreciated it
because both of them were hard of hearing.
And it made everything so much easier for them.
And the amount of effort required from my point of view,
from my standpoint, was exactly zero.
I clicked on a button, and that's basically it.
So yeah, I'm a big fan of that kind of stuff.
The other thing that I wanted to mention
is just mentor women out there.
We would like to be part of that, include us,
be part of the hiring process, bring us in.
I think it's becoming better in recent years.
And last, connecting communities.
Most of the time when I go to a community event,
there's all these guys together.
So I'm going in there.
I'm the only woman.
But there's time that I see a woman walking around,
and they don't know who to connect.
So just be conscious of that.
Yes, thank you very, very much for those perspectives.
That was awesome.
Thank you.
So Mark, you have mentioned that you
have worked on many different resources, like CISO workshop,
the NCR, Microsoft Well, architected framework,
and many others.
For somebody that is starting brand new,
what is a learning roadmap that you would recommend?
That's a really good question.
And that code for there's no simple answer.
So I'll start it with a standard consulting answer of it
depends, and then offers the way I think about that.
Because it really does depend on what your background
and experience are.
Do you have a technical background or not?
Or are you just straight into cyber?
Have you been in technology for a while, early in career,
or later in career, depth of technical experience and breadth,
et cetera?
Part of it is your background experience,
but part of it is also what you're looking for
and what you're trying to get.
The interesting thing about cybersecurity
is such a broad field.
We work on some of the deepest technology things,
like reverse engineering and the like.
But we also work with user education
and touching hearts and minds and trying
to convince people to do things, whether it's a developer
to follow secure coding practices through a CHAMS
program, or educating users so they understand
what the right answer is, or looking for insider threats,
which again is very human in nature.
And not as technical, but there's
a lot of what is the person's motivation, disgruntled,
et cetera.
So there's so, so many different areas of cybersecurity.
It really depends on what you're interested in.
So we did put together, if you're a technical person
and you're new to cyber, we created these things called
interactive guides.
And we use the MCRA, the Microsoft Cyber Reference
Architecture, as sort of the slide
backdrop for these videos.
But we completely changed the talk track from the normal one
to, hey, let me explain what the heck this part of security
is, or that part of security is.
And so that's sort of one of the things
that we put together for folks that just
have a basic technical background,
but need to learn more about security.
If you're more experienced in cyber
and you're just trying to understand the Microsoft
technologies, the newest and latest techniques,
the cyber reference videos, the Microsoft Cyber Security
Reference Architecture videos, those
are probably the right place to start.
If you have a specific thing like, hey, we just
bought Sentinel, or we just bought Defender for IoT,
or some other specific product technology,
I really, really like the Ninja training videos,
because they're kind of like going to a workshop focused on,
OK, I now need to know everything about that
particular product.
And so those are kind of the first ones that pop into mind,
depending kind of on your needs and backgrounds.
So I wanted to kind of close us on a couple of questions.
And the questions are, what are your favorite things
to talk about in security, and why?
So that's the first one.
And then the second one is any career advice
that you would offer for folks that
are looking to advance their careers in cybersecurity.
My personal favorite thing to talk about in cybersecurity
is how connected it is to everything else.
So security isn't just a technical discipline.
As I mentioned earlier, it's a human discipline.
It's got elements of economics and human behavior
and psychology, not just of our own users,
but also the attackers.
And how do they make the most money?
And what's their return on investment for an attack?
And so the thing that I love to talk about and to explore
about cybersecurity is how much of the greater
body of human knowledge that we can bring to our industry,
and things like group dynamics and economics and finance
and just anything about just what we've
learned as humans as a species.
And so that's my favorite thing to connect to it.
And the big career advice I would give folks
is to really kind of explore the full breadth of cybersecurity
and understand it, because there's
a lot of opportunities out there.
And a lot of them aren't the normal sort of well-paved paths
of, hey, I have to learn and master network technology
in order to be a good cybersecurity person.
Yes, you definitely want background information.
You need sort of a breadth of understanding
of technology and others.
But ultimately, there's so many things
that we're doing in cybersecurity,
but there's also so many things that we're not doing.
And so there's a lot of opportunities
to sort of forge new paths.
And so really bringing your creativity
and bringing your ideas to it and bringing
your diverse backgrounds to it, I mean,
that's what's going to make cybersecurity
a better discipline.
It's not doing the same stuff we've
been doing for the past 10 years,
although there is some consistency, as Mike pointed out.
But it's also about what can we bring to it
to address the things that haven't been done.
Maybe there's a psychological dynamic that explains
why we keep doing things.
And if we have the right motivation for it
or the right perspective on it or the right visual that
clarifies a particular topic, all of a sudden,
instead of 10 people out of 100 in a room
that would understand it, maybe 70 people in a room of 100
would understand that topic.
So there's just so many opportunities in cybersecurity
to bring yourself and your background,
your unique skills.
So that's the big thing is bring your whole self to cyber.
For me, I would say that my favorite thing
to talk about security would be the graph, APIs,
interconnections.
And mainly, it is the ability of interconnecting services
together.
And the reason for this is that many of the Microsoft tools
or security services take into account the interconnectivity
of different services.
And this is not just Microsoft services,
but it could be third party services.
And it enables it a lot through the graph
and through many of the other APIs.
And these, in turn, allows for automation orchestration
to be done in heritance in the toolset, in the services,
which in turns speed up resolution, I guess,
detects and responds all this through these services.
So I love talking about that and how Microsoft enables this.
Because once I start talking about that,
and then I show it like in the XDR tool or Microsoft 365 tool,
the light bulb lights up.
And you see their eyes open up and say, oh, hold on a second.
We are in a different world.
It's no longer about collecting logs in a scene.
It's no longer about having somebody manually write
automation orchestration.
So I like when people just realize something.
It differentiates the regular work that they're doing.
Career advice, I would say that the number one thing that
has helped me at Microsoft and in many places
is networking, networking with people, getting mentorships.
I actually today was asking somebody to mentor me.
That is a never ending type of thing.
Learning from others, meeting new people, doing community,
I think this is the most important thing.
Because when I don't know something,
I know who knows that thing.
So I'm able to accomplish a lot of things.
And it is funny to say this, but when I first
came into strategic mission and technologies,
everyone was saying that Gladys was a yellow page for the team.
If they had a question, who can answer this?
I had the answer.
I had somebody for them to find the answer from.
So I heavily recommend keep up with networking and mentoring.
The last thing that I have started doing in the last three
years or so is every day I take an hour just to learn something,
read something, watch a video, something like that.
Especially in security, if you're not
able to do something like that, just stay behind.
I don't say with this that I know everything,
but at least I'm able to keep up a little bit
and show that I am up to date on what is happening out there.
Yeah, I just want to concur with the whole learning thing.
So I actually keep, when I come across topics
that I'm interested in that I want to learn more about,
I actually have a Microsoft to do list.
I just add it to the list.
That way I don't forget.
Because I know full well if I don't write it down,
I'll forget.
Then what I do is every day is I'll pick something
from the list and I'll look at it.
I actually have it set aside like you.
I have some time set aside in my calendar to learn something.
It literally is called learn something.
I'll go to do pick something and just, as you say,
read a document or read a research paper
or watch a video or something.
That's how I stay on top of things.
So getting back to the original question that Mark raised.
So the thing that I like to talk about the most,
obviously anyone who knows me knows that I'm
a big fan of software development,
I'm a big fan of cryptography and cryptographic controls
in general.
But to take it one level higher than that,
I'm a big fan of telling stories.
I think that the area of security
can be very complex and quite intimidating.
But sometimes if you can bring it back
to a simple human story, then it starts to make sense.
I've had people say, well, we can't do that because blah,
blah, blah.
I'm like, well, let me tell you how another customer did that
and how they realized it wasn't the best idea.
Obviously without naming names.
And if I can jump in there for a second,
because storytelling is I changed
my personal version of my professional identity
about 10, 12 years ago.
That I'm no longer a technologist,
I'm a storyteller that tells technical and security
stories.
And the world got so much clearer for me.
Yeah, 100%.
100% agree.
Yep.
In fact, when I moved from Redmond to Austin,
I got like three emails from people saying,
I'm really going to miss story time with Michael.
I think you have to be able to tell things as stories,
because I think that can be a lot more compelling
for a lot of people.
And then second one about career advice.
I think learning is big.
I think learning is absolutely huge.
In fact, when I hit the 30 years,
I was kind of interviewed by the head of our group
in front of everybody.
And one of the questions was, how do you stay fresh
after 30 years?
And the big thing is just learning.
You've just got to keep learning.
And you've got to be willing to reinvent yourself as well,
if needed.
I'll give you an example, by way of a story.
When David and I wrote Running Secure Code,
even though David was in office and I was in Windows,
we were still writing stuff about Windows code.
So we were known as the security, so the Windows
security guys, right?
And then this thing came along, which about 10 years ago,
which I thought, this is going to be a big deal, this cloud
thing.
I ended up spending a lot more time learning about cloud
threats, cloud mitigations, cloud risks, and so on.
And then lo and behold, another book
comes out called Designing and Developing Secure Azure
Solutions.
So essentially, over the years, I sort of reinvented myself
as essentially an Azure security guy, right?
Now, what's ultimately and beautifully ironic, however,
is because I'm working on the back end of Azure now.
I'm working inside of, in many cases,
say an Azure SQL DB or a Cosmos DB instance or other things
hosted in VMs.
So I'm still working at the operating system level,
even though I'm talking about cloud threats and so on.
A lot of the work that I do on a day-to-day basis
is actually still Windows, essentially, at the back end.
But yeah, you've got to be willing to essentially not,
I'm not going to say throw things away,
but you may have to reboot your career at some point.
And you have to be willing to take those risks, I think.
So my favorite thing to talk about in security
is actually just talking to everyday people
and making them realize that security is relevant to them
and their everyday life.
I'll give you an example.
A couple of weeks ago, I was getting a blowout at a salon
and I was talking to the lady who was doing my hair.
And she was a law student.
She did the blowouts in her spare time.
And we ended up talking about security.
And she said her boyfriend was studying it.
And anyway, we just ended up for the whole time,
me getting my hair done, talking about security
and all the different parts to it
and how it's relevant to absolutely everybody.
Even if you're not a security professional
and you're getting paid to look at it,
we all have to take security precautions in our lives
and the effects of what happens in security
affects everybody.
And even if you're very anti,
I don't think anti-establishment or just anti-society.
And even if you don't even use a bank or anything
and you try and go off grid,
the fact is that someone somewhere has some information
on you on a computer in an electronic format
no matter how much you try.
And for those of us who don't choose that lifestyle,
there's a lot of information about us on computers.
So security really is everybody's problem.
And I really enjoy,
I love talking to security professionals
and people in the IT industry,
but I think just through the course of me
chatting with people, making people understand
just how much security affects absolutely everybody,
I find a really fun thing to do.
And obviously people's reactions are like,
wow, oh wow, like I didn't realize
that was going to affect me too.
So yeah, that's probably one of my favorite things.
My career advice is not too dissimilar
from what some of my other lovely colleagues have said here,
but you do have to keep learning.
I mean, this is the same for all IT technology careers
because technology goes out of date very quickly.
And security and the attackers and the techniques
and what they do also changes really quickly.
So of course that's a really important one,
but also stick with it because I have had many times,
many times in my career where it's hard work what we do.
It can be hard work, not just from a technical perspective,
but also emotionally.
We don't have easy jobs.
And I was always taught by my dad,
he was said, well, Sarah, you didn't sign up
to do an easy job.
What you do as a job is actually really difficult,
but that's why you get to do some really interesting work.
You get to travel and you get to do all these other cool
things alongside that.
So I think as well making sure work is not the only thing
in your life.
I mean, with working from home and all of those boundaries,
we don't, it can be that's dissolved the work life boundary,
I think even more, at least for some of us.
I know I certainly did more work during the pandemic,
but make sure you've got other things going on outside
as well because it's tough and it's a hard job.
It's interesting and rewarding, but it's not easy,
but you need to balance that with things going on outside.
All right, so with that, we've been going for nearly an hour.
Let's wrap this thing up.
This has been actually a lot of fun.
It's a little bit different.
It certainly makes a change from interviewing somebody
from a product team about the security implications
of their products or some security features.
So thanks everyone for taking the time
and to all our listeners out there,
we hope you found it useful.
Again, a little bit different,
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 Azure Setpod.
Background music is from ccmixtor.com
and licensed under the Creative Commons license.