(uplifting music)
- So Hart, thank you so much for joining us today.
- Thanks for having me, Clarke.
- So if you could spend a little time telling us
about your background,
how you came to AWS and what your current role is.
- Sure.
So before AWS, I was working in the defense contractor
intelligence space, doing a lot of systems integration work,
and I really liked it.
I loved the mission.
I loved supporting the US government
and governments around the world and what they did,
and some regulated industries as well.
But I'd always kind of maintained this list
in the back of my head of the top security companies, right?
And in the early part of my career,
those were largely consumer focused.
So antivirus, personal firewalls on your desktop,
stuff like that.
But over time, that list migrated into companies
that were providing the infrastructure
that makes the world go.
And so, those companies like Amazon
and other big infrastructure providers.
And so, I was really at a point in my career
where I was looking for that next move.
And I wanted to go someplace
where they were really innovating on security
that was gonna make a difference,
not just to a few customers who are very important,
but really to the world.
And so, I had this opportunity to come to AWS and took it.
- And what is your current role at AWS today?
- These days, I'm the director
of the security and infrastructure
global specialty practice in professional services,
which is a bit of a mouthful.
But what it really means is that my job
is to help customers build the confidence
and technical capability to operate
their most sensitive workloads with us in the cloud.
- Thank you for that, Hart.
We sort of switch gears to the customer perspective.
- Yeah. - Our customer CSOs,
they're always looking for hiring security talent
and it can be very difficult to find those types of people.
When you have a shortage of security talent,
what kind of advice would you give to a CSO
or other hiring manager at a customer organization,
as far as looking for that right person,
even if they may not have the deep security skills
that you're looking for?
- Yeah, I think a lot of it
comes down to that corporate culture, right?
And we often find ourselves
in sort of two different conversations.
The first is bringing in deeply technical
engineering resources, and then developing a program
to get them comfortable
with whatever the new technology is, right?
Lambda, containers, whatever it might be, KS, right?
Or the security aspect of it.
So bringing in that deeply technical engineering resource
and helping them understand how to build securely,
how to think securely,
how, for example, to begin every sprint
by starting with a threat model
to generate your user stories
that you're then gonna sprint against,
instead of just the functional requirements
from the product manager, right?
So those sorts of skills.
And then the other end of the spectrum, of course,
is there's a lot of really talented security people
in other parts of the security community.
So they might be in audit,
they might be in compliance, right?
They might be in other areas,
and it's an opportunity to bring them
into a different part of the security community
and allow them, if they're interested,
to become more technical
to develop those engineering skills,
to develop those product development
and product management skills.
And that's really helpful as well.
The one thing I often offer, and again,
it goes back to something we look for on our team is,
the creative types tend to be the most successful, right?
The lateral thinkers, the artists, the poets, right?
They tend to be really good
at making that adjustment over time, right?
And not to stereotype anybody,
but that kind of flexibility and agility and mindset
often allows them to kind of come along quite quickly.
- Customers, they seem to really be turning towards
the security engineering, build security into applications
and infrastructure that they're managing.
As you know, there's another aspect of security,
and that's sort of operational security
and just making sure everything is operating as it should.
And let me see a red flag here,
and let me react to that sort of thing.
What's that right balance
between the sort of engineering mindset
and the operational mindset?
- Yeah, you know, that's a super important question.
And I actually spend quite a bit of time
talking to senior executives about that,
because when they're early in their journey,
not just with the cloud,
but I think with application modernization,
which many of them are doing
regardless of their involvement with AWS,
the emphasis is often on the dev part of DevOps.
And so, they're thinking about really
how do they build and deploy their workloads better?
They haven't necessarily thought
all the way through the operate part.
And then when you add in security operations,
there's a very particular nuance there
that really needs to be addressed.
One of the things that I've found is helpful
is when we start talking about operations,
we can't really talk about programs
and initiatives anymore, right?
A lot of times during a migration,
a lot of times during a new workload build,
it's really very programmatic.
You have a product manager, you have a migration lead,
but when we're talking about security operations,
you have to have that 24 by 7, 365,
reliability, security and sense and response type activity,
which comes with a conventional op center mentality.
Now, we don't need to be constrained
by the four walls of an actual operation center, right?
'Cause we have systems in the cloud
that will help us do the same thing.
But we need to sort of shift that executive mindset.
And it's often as simple as saying,
well, what metrics matter to you in operations, right?
We've talked about the migration.
We've talked about the development.
We know it's important to you and what success looks like,
but what does security operations look like to you
from a metric standpoint?
And once we have that conversation,
we can often very easily orient into what that looks like.
And now, start to truly bring dev and ops together
in a meaningful way from a security and safety standpoint.
- So, I'll ask the million dollar question.
What are some key metrics that customers
are typically looking for from an operational perspective?
- Yeah, you know, it depends, again,
on their goals and their objectives.
One of the things we'll look at are things like dwell time.
One of the really cool things
about having immutable infrastructure
is that you can have very low rehydration rates
for your entire data center in the cloud, right?
Instead of taking months or sometimes years to rebuild
and re-home an application,
many of our customers have it down to hours, right?
And some, minutes, for smaller workloads, right?
And so, if you can rebuild your entire data center
in an hour, now you can start to think about,
how do we change the conversation
about dwell time for an adversary, right?
How do we change the conversation
around vulnerability management
and the long tail of patching, right?
And we can start to really look at those metrics
that help us drive agility, scalability, reliability, right?
Which ultimately, to security.
- So a lot of our conversation today
has been around engineering, security operations,
sort of the traditional nuts and bolts
of running a security organization.
And a lot of the conversations I have with CSOs,
they're really concerned about,
how do I report security
in the appropriate business context,
and how do I frame cyber risk in business terms
that my board or my senior directors will understand?
Do you have any offerings around this, in this place,
with sort of security as a business leader,
as opposed to just sort of security operations
and the traditional metrics that we think about?
- Yeah, we do.
And it's actually another great example
of working backwards in the customer.
Early on in the days of building
the security part of the security risk
and compliance practice, we started to get
those kind of questions from customers.
And I had experience, and many of the people at the time
on my team had experience in security consulting,
but none of us had had the personal responsibility
that a CSO had in protecting the organization, right?
And so, after getting that request a few times,
we thought, well, we've gotta go find some CSOs
to come work with us, right?
And so, that's just what we did.
We built an executive security advisory practice
where we have chief information security officers,
heads of risk and audit
who have gone on the cloud journey themselves with AWS.
And they're now on our team.
And they can do that peer-level advisory work,
backed up by the strong engineering
and operational folks to actually help implement
that executive strategy, right?
And it's been really, really good.
We're able to have conversations around metrics,
and I don't mean metrics
like the operational metrics we were talking about earlier.
We're talking about key performance indicators.
We're talking about setting security expectations
for the organization
that are gonna drive year-over-year transformation,
not just hitting a particular number this year, right?
- Got it.
So with the customer CSOs that you work with,
are you seeing any trends
in their sort of business-level reporting to their boards?
When I speak to customer CSOs,
I'd like, yes, you still need to have all the metrics
of the machines we patched, and the viruses we stopped,
and the attacks we stopped, and things like that.
But what's the advice you give to articulate that
in business terms to people who may not have
the deep security expertise, yet may hold the purse strings
to your budget and other operational needs?
- I think there's a few different points of view.
One is the transformation angle that I mentioned earlier.
If you set the right goal and expectation,
there's this tremendous pull-through effect.
And an example I'll use is when you,
as the CSO, set the goal of being able to rehydrate
your entire data center in the cloud
in a few days, let's say, every 48, 72 hours, right?
Working backwards from that,
it has this massive knock on effect to how you do BCP/DR,
how you do build, deploy, and operate,
how you do test, right?
It forces everybody to automate.
It forces everybody to accelerate,
which ultimately reduces time to value
for every one of those under-the-hood
infrastructure activities, right?
So lower cost, faster to market,
greater response time for your customers, right?
So it really drives some great outcomes across the business
by having one right security expectation that,
by the way, is probably a yearly transformation.
So it might be we wanna get down to rehydration
every 45 days this year.
And then we wanna get down to 15 days next year.
And then we wanna be down to 48 hours the follow a year.
And so, year over year,
you're gonna use that one security objective
to drive all these other business outcomes.
- And then track that with the board
as you're reporting to them.
- Exactly.
- Hart, thank you so much for joining us today.
- Cool, thank you for having me.
(uplifting music)