(upbeat music)
- Lena, thank you so much for joining us today.
- You're welcome.
Thank you for having me.
- So if you'd be so kind
just please talk a little bit
about your your career at MongoDB and your role there.
- So, I'm the CISO.
I'm the first CISO there.
I've been the first CISO at my, this is 1, 2, 3 jobs now,
which is awesome 'cause I'm not stepping
into anyone else's shoes.
I think CJ is doing a marvelous job of stepping
into Steve Schmitz very large, hard to fill shoes.
So hat's off to him.
I've been extremely lucky in being the first CISO
at the Power Authority where I worked
in critical infrastructure, then in FinTech,
and then I finally at MongoDB.
So it's a lot of fun 'cause you make your own rules,
but you're the one throat to choke, which I don't mind.
That's one of the reasons I took the job.
So I've been there for about three and a half years.
When I started, there was a really good
security presence in place.
It just wasn't under that one umbrella, that panacea.
And to be honest, I didn't walk around
and say everyone with the word security
in their job title now reports to me.
I wanted to get the lay of the land
and I'm still, the land is ever shifting
and I'm still looking at the lay of the land
and I really do like the separation that we have
of product security, cloud security, server security,
and I talk regularly with folks who run those systems
down to the engineering level,
up to the EVP level just to get that feeling of where are we
and I really love that part of the job.
And then I'm also responsible
for governance risk and compliance.
So that's my second team.
Very distinct teams, but there's obviously
a lot of collaboration and yeah, I love it.
And this is for anyone who knows me,
I'm absolutely passionate about what I do
and I've always said the day that I wake up
and say I just wanna do this anymore, I won't do it anymore.
- Fantastic. So over the last few years,
I think it's fair to say that the role of the CISO
has evolved from being that technical security expert
to really being a business leader.
So can you describe an opportunity
that you envisioned at MongoDB?
Were you able to solve a business problem through
security risk compliance or privacy programs?
- I'm always trying to see the big picture
and get it down into something that's,
someone mentioned recently eating
an elephant chunk by chunk.
So it's go and interest in compliance
sometimes it's like chunk by chunk.
And we basically took all of the controls
that we have to comply with
of which there are over I think 1200 now.
And we mapped them to where we had evidence,
which we have evidence for all of them.
But what we tried to do was,
if one piece of evidence serves for five controls
for five different qualifications
we only have to ask the question once
and they supply it five times.
And so that's what we've been doing
and we've now saved our engineering teams
probably 80% of the time they used to spend
on showing me the screenshot for the antivirus,
for this regulatory rule.
And they have a lot of respect for what the GRC team did.
And I think that's a big business benefit
that engineering really appreciates
'cause everyone's time is valuable,
but they're the folks that get the product out the door.
They get the patches in place,
they get the security and they maintain it.
So the more time they have to do their jobs
rather than giving me evidence for compliance,
the better it is.
- And that's spot on.
So the less time that they're spending
on undifferentiated work,
they can actually add value back to the business,
which I'm sure the larger business appreciates.
- I think as well though,
with them seeing that we are being proactive with their time
and we're being respectful of what they do as engineers.
I think sometimes, and this is just my opinion,
but I think sometimes engineering is like,
oh, they're just engineers.
Just throw them some red meat and some code
and they'll be happy.
Our engineers are amazing bunch of people
and the more time they have to collaborate
and work with people like AWS is like,
that's a business profit for me.
- Absolutely.
- They're using their time in an affordable
and a good manner and we're getting so much more out of it
and my team's interested as well.
My team gets to see, they'll now meet
with the engineering person for an hour instead of a day.
And that hour is productive and it's enjoyable
'cause they can see later the end of the tunnel, both teams.
- There's been a shift in the last few years
as more companies have been adopting cloud
and investing in security as code
and much more of an engineering effort.
So security teams are going from that point
and click console operations to actually build and code
that will do things for them in the cloud at scale.
Can you talk a little bit about how you view that
and how you've implemented that shift at MongoDB?
- So obviously we have specific tool sets
both from AWS and from other third parties.
And I'm always very keen to get a real feeling
of what my team has used before.
So obviously we're a new team,
we're a couple years old,
and getting all this new blood has been super interesting
because people have used stuff I've never heard of.
And it's like, okay, show us what it can do.
And been able to share that knowledge
with our security champions,
with the other engineering teams,
the hardcore server security engineering folks
who obviously security is always part
of their systems development lifecycle,
but they can now bounce real ideas
and really collaborate with security engineers
who this is all they've done their life
and they love it and they want to just imbue
the sense of we can really work together.
It doesn't have to be siloed.
And I think we've been really, really, really successful
at breaking a lot of the silos that occur everywhere.
I wouldn't say there was that many
when I started at MongoDB,
but I think any residual silos are gone,
which I think is rare.
- That's great to hear.
And I guess on that same track,
as CISOs we always have a limited amount
of security personnel that are actually
in the security department working for us
under our control and what we have to do,
because you can't hire a whole company
full of security engineers is spread that knowledge
throughout the company,
make sure that you have effectively security eyes
and ears throughout the business.
- CISOs we're a secretive bunch of the best of times.
And so my role has been to really
get the word out there about security,
get people excited about it as excited as I am anyway.
And just to like enjoy it and don't be scared of it.
I've told my team, we're not the team that says no
'cause sometimes you find that.
We're the team that says yes,
but here's the risk, here's the cost, here's the ROI.
If we can give you it,
here's your business reason for doing it.
And by the way, here's the person
who's gonna be responsible for it when it goes live.
So when you start bringing money, responsibility,
accountability into the discussion
instead of just saying no,
people are like, oh, okay, you know what?
You've actually thought about this.
There's thoughtfulness behind that leadership.
So yeah, okay, we're with you in this.
Let's work together for a solution.
And I'm making it sound
as though we live in this perfect world, we don't.
We have people who say, well, I wanna buy it
just because I'm that person and I can just do what I want.
And I'm like, you know what?
Absolutely you can do that.
You're 100% responsible for it.
And by the way, you're now on my risk register as a risk.
And then they're like,
oh, well, that's focused my mind a bit,
but maybe I don't need it that much.
- Well, that's spot on.
The idea of security being a business partner
and stepping up to the plate,
that absolutely will support you,
but you have to understand the risks.
- Yeah. I mean there's risks with everything,
but if you're introducing a new tool set that requires
and you probably heard this,
oh, I need admin access to everything.
I need rules like, why?
For something that is marketing emails.
- So switching gears a little bit to security operations
and security engineering a little bit.
How do you ensure with your product teams at MongoDB
that security is considered what I'll call early and often
in the development stage so that any security issues
that pop up, you can get them in dev or test
as opposed to the night before it goes into production?
- Oh yeah, I mean security has been baked
into the SDLC for MongoDB
for way longer than I've been there.
We like to say MongoDB Atlas is secure out the box.
We do everything that we can to ensure that that is true.
And that goes back to having engineers
who understand security,
having that team mind to bounce ideas off of it
if they have to.
There's no judgment.
Sometimes people can be a bit judgy when it comes to code.
And being able to have that open discussion
of, hey, we're seeing this, should that be normal?
It's eyeopening to me that people get into such a level,
a deep level of uncovering possible security issues
and getting them way before anybody would ever see them.
Not just this, I used to handle some QA teams a few jobs ago
and it was always interesting
just the lobbing of fire grenades above you.
QA to production, QA to production, oh, back to dev now.
Oh, okay.
And you've got this hellish triangle
of just trying to get out the door,
whereas is here is very much
because it's built into the SDLC,
because it's run by engineers for engineers.
There's so much fluff has just been removed
from the whole process.
And our CTO, of course, Mark Porter, technical genius.
I meet with him regularly and I can talk to him.
He's got a team of experts in his office of the CTO, OCTO,
including an ex-CISO, which I love
and I can bounce ideas off this person
and say, when you were a CISO, what did you see?
Because I've never had that before.
I've never been able to talk to,
within my own company another CISO.
And so that was brilliant.
I mean, I love that.
I love that kind of relationship.
- So what drove that level of security ownership
in the development teams then?
Is it just because we must build
and release a secure product?
But at the human factor,
if I'm a development engineer at MongoDB,
what drives me to make sure
that I'm releasing the most secure code I can?
- I think basically, and this is again my opinion,
it's the reputation that we have
for having the security out the box
and having so many options to further secure it.
Queryable Encryption is out there now.
We have a product security team that's just amazing
and again, staff by engineers for engineers,
they get what they're talking about.
They're developers.
They come from a development background.
We just hired a new VP of development productivity.
And this person's responsibility is to cast a lens
over all of development.
What are they do?
Where can they, and I hate to sound
like a time and motion person
'cause I used to work in a shipyard many years ago
and we these time and motion people
who would literally walk around
and measure how long it took me to drink a cup of tea.
And I kind of joked with Tara
when I was speaking to them last week about their job.
And I guess, they time me when I'm at my cup of tea.
And they were like, nope, couldn't be further from that.
It's basically talking at a developer level
and an engineering level on how they feel
they can be more productive.
How can we get more product as well out the door
in a more timely fashion?
'Cause everyone wants to be out the door
as quickly as possible, but remaining securely as possible.
That's the important thing.
And that takes time.
There's always that trade off.
- That's a great story.
Lena, thank you so much for joining us today.
- Thank you very much for having me.
(upbeat music)