Welcome to Crying Out Cloud, the podcast that will make you
laugh, cry, and reconsider all of your cloud security fears.
I'm Eden. I'm here with my amazing Co host
Amitai. Hello.
And today we have a super special guest, Eric Block.
Welcome, Eric. Hi, appreciate you guys having
me on. We're pumped to have you here.
Where are you calling us from? I'm in the Bay Area here in
California. Today was the first day of
school for my kids so they were up pretty early running around
and I had to get them out the door so.
Nice, so you already had your natural pump of coffee.
Oh yeah, I'm, I'm still working on my next cup here still.
Love it. Eric is currently the VP of
Security at Alumio, previously having held leadership positions
across some of the largest tech companies he built and LED
detection and response and security operation teams at
Cisco, Salesforce, Atlassian, and Sprinkler.
Eric also serves as an advisor on the BCV Cyber Leaders
Advisory Board at Bain Capital Ventures.
He has a wealth of knowledge and we're super excited to get to
speak with him today. OK.
So we like to do this thing when we have guests on while cloud
confessions. Good to know you a bit.
It's not as scary as it sounds. I've seen a few episodes so I'm
I'm familiar with. Yeah.
If you're familiar, can we ask you some questions?
Sure, far away. OK.
So you started out in a very unique corner of security,
reverse engineering hardware in the military.
How did that shape your perspective on the digital side
of things later on in your career?
You know, it, it was kind of my first foray into kind of what
security was going to become way back then.
I mean, I mean, not to, to date myself.
I mean, this was in the early 1990s.
You know, I joined the the military out of high school just
in time for the the first Gulf War, right?
And this is when the military was just starting to use
computers. They were transitioning from,
you know, paper forms to using, you know, 286 computers.
And at the time, as we started to to modernize, the military
assumed that, you know, a lot of our our friends and foes was
hard to modernize as well. So it made sense to them to form
a new branch of military intelligence called Technical
Military Intelligence. And we work with special forces
who went out and basically stole stuff from everyone, friends,
foes, went to war zones, you know, wherever they could.
And they stole stuff. And they brought it back to us
at Aberdeen Proving Grounds in Maryland.
And from there, they'd ask us to figure out kind of what it was
if we hadn't, you know, seen it before.
And that's where I kind of got my, you know, first taste of,
you know, why we were doing this, the importance of it.
That's also where I realized that we were pretty far ahead of
everybody else. I mean, we're using 280-6386
computers and the rest of the world was still using vacuum
tubes. It's kind of what lit my fuse to
to get me into security later on.
So how was the transition from like working the more physical
side to these more SAS security world like what was the most
surprising or or unexpecting unexpected aspect of that for
you I. Mean it was a gradual kind of
transition, you know, coming out of, you know, you had a little
286 base computer at home, then you started, you know, putting
these things in your data centers and racks and whatever.
And it started to slowly evolve over time.
So I mean, I came out of, you know, the the early days of the
Internet where we're running, you know, arc site networks with
the mobile 312 systems running IPX protocols, you over coax
cable and then it and it transition over to Ethernet
using, you know, the conventional, you know, cables
we have today. And then I saw all the, you
know, the kind of the, the cloud for the spin up and people
moving things to the cloud initially.
And then from there it kind of made sense to, you know, go from
having your enterprise software, you deployed a, you know, a
giant monolithic thing that you'd buy to offering as a
service. And so I kind of watched the
transition from, I mean, that the early days to where we're at
today, where everything's SAS. And now I'm watching kind of AI
eat that kind of market and we'll see what's left of SAS,
you know, in, in 5 or 10 years. But it's been really interesting
to kind of, you know, see the progression of it all.
As a motorcycle enthusiast, why Ducatis?
When I lived up in the mountains, I used to ride dirt
bikes all the time. You know, they were cheap.
You could throw them around. You know, they were they were
pretty fun that in my biking when I moved back to the Bay
Area here when I got, you know, called back to the office for
for Salesforce, you know, obviously being in the city, you
don't have those opportunities available.
So I transitioned to riding a street bike to kind of commute
to work is far faster than sitting in a car for, you know,
an hour, hour and a half for anyone who's in the Bay Area.
And so I just, yeah, I appreciated the the look of the
bike, the sound of the bike and kind of the culture that goes
along with it. I'm trying to figure out what
what those things are on your shelf behind you.
Are those planes or those are those paintball guns?
Yeah, those are those are are paintball markers back here
ranging from this. This blue one is from 1998.
This is from 2006, 2009, 2011. It's back from my from my days
when I used to play professional paintball.
OK, last question. This is a classic.
You are a vulnerability. Which type would you be and why?
Man, I'm trying to think of like what is like the the lamest
vulnerability out there That'd probably that'd.
Probably be me. I'm thinking of like an old
like, you know, back in like the late 90s when they used to ship,
you know, Linux distros with like default passwords for your
printer demons or whatnot. That'd probably be me like some.
You could be like the OG bug, you could be like the the bug
the moth in the mainframe. Yeah, it's whatever is some,
some service or some account got shipped out-of-the-box that was
on with a default password. Everybody knew, you know, or
there was the fault service that was on with no password, you
know, that'd be me. You killed it in cloud
confessions. We're on to the big the big
questions. Uh.
Oh, OK. Let's start by talking about
metrics. I think something that's really
important is how security leaders translate risk into
business language, and it's not so easily done.
How do you translate it to dollars?
Can you speak to like concrete data points or frameworks or
mechanisms you've seen work well in doing this?
I'm sure metrics is something that I've put a lot of time into
thinking about here. You know, the last, you know,
since 2015 or so, I guess last 10 years, I got a, a really good
kind of front row seat into kind of how this stuff works.
When I was at Salesforce, when they were building up the team
there, when I first started, the security team was about 200 and
2050 people or so. And when I left it was 2000
people. So it grew, you know,
exponentially. And I kind of watched our senior
leaders, you know, the CSO and, and the, the SVPS there
struggled to keep their hands kind of wrapped around
everything was going on. So they rolled out a, a, a huge
metrics program across our entire organization to help them
kind of measure these things. And one of the one of the things
I took away from that and I've kind of brought to my last few
roles here too, is, you know, how critical metrics are in kind
of showing kind of what the what the outcomes are you're
delivering to the business. And also framing the metrics in
a way where whoever looks at them, like hopefully just these
metrics are targeted at somebody, you're making them for
somebody to consume. And these metrics either have to
give them enough information to be able to ask the next question
or they have to be actionable where I can see this metric and
I have a choice of doing you A or B.
If they don't lead to that next question or next decision or
they're not leading to a pivot point where you make a decision,
they're not really providing any value to anybody.
I mean, there are some metrics, you know, like, oh, you know,
how many, you know, widgets do we have or you know, how many
things happened that that will be useful to feed into those
part of a metrics. So you have to collect those
things. So I'm not saying all those
metrics are, are worthless, but as far as you know what, what's
actionable and what's not, what do you want to show to your
executives? And what don't you want to show
your executives any things that again, will either lead them to
asking the next question or making the next decision.
At my last role, my sock team was buried in alerts and they
were all burning out and I had a couple guys disability.
I went to my CSO and I said, Oh my God, I need help.
He's like, you know what's wrong?
And I'm like, my, my team worked 2000 incidents last month and
the CSO kind of sat back in his chair for a second, looked at me
and goes, Eric, like, I don't know if I should promote you or
fire you. What does that mean?
Like I've no 2000. What does that mean?
Right. And then I realized I was part
of the problem where I'm giving him information to to me, it
seemed relevant. I'm like, Hey, there's 2000s a
lot. You know, I got a team of, you
know, X amount of people. Tim, it meant nothing because he
didn't have the insects or the the context or insights and what
it means. And so I had to figure out, you
know, how do I make this data actionable where I can give him
a clear decision path? And so I went back and started
measuring like like engineering teams do, measuring my team's
capacity, how much work can they do?
How many people do I have and how much work are they doing?
Once I measured my capacity, I could actually show that my team
on a day-to-day basis was being leveraged between 130 to 200% of
capacity every day. From there, from there, I was a
clear decision point. If your team's over capacity,
you have two choices. You can either add resources or
reduce the work. It armed him with the
information he needed to make the next decision of what do I
do to help support him. And again, it's thinking about,
you know, who wants to consume that and what action is it that
they, you want to drive off of that?
And that bubbles all the way to, you know, talking about budget
numbers and doing kind of road map for the year.
You know, I'm looking at, you know, what are the, what are the
company's initiatives for next year?
You know, what are the numbers and goals you want to hit?
How many customers are going on board, what products we're going
to launch, what cloud environments we're going to go
into? How do I align my team to help
facilitate and support those business outcomes they want to
drive? And then tying my wagon to that
and saying, hey, look, if you want to do XY and Z in business,
I need AB and C to support you. Yeah.
Also, I think a lot of the time it has to translate to dollars,
right? Because at a certain point you
need budget. And there's a phrase you
mentioned, I think, in something you wrote about the security
poverty line. And I think it'd be interesting
to hear you speak a little bit about how organizations above
that poverty line optimize effectively and those below it
are still able to be resilient and effective.
Well, it's, it's kind of a loaded question because I know
there, there are strong opinions about the security poverty line.
It doesn't exist, First off. And you kind of what are the
impacts of it, You know, having been at both, you know, your
fortune ones all the way down to, you know, seed state
startups. I can definitely say from my
experience, there is a, a line, you know, it's kind of fuzzy
where it's at because it kind of depends company by company.
You know, like I got a, you know, kind of a front row seat
when I was at Cisco and at Salesforce where we've had blank
checks. I mean, you know, it's all if
you justify the thing, we had the money to do it again, the
Salesforce going from 250 people to over 2000 people, you know,
in just a matter of, you know, 3 1/2 years, that's blank check as
fast as we could do the things we were doing them like hiring
people, you know, you know, bringing people on board was was
tough. Bringing things up to speed
quickly. I mean, our time became our most
valuable commodity. Was it money?
The same thing at Cisco, we're rolling out, you know, in the
early days, we have the largest idea sensor network in the whole
world. You know, time was our most
critical resource. It wasn't money versus other
places I've been where, you know, you didn't have the the
budget of the money. You had to kind of ruthlessly
choose like, what are we going to do?
What do I think will make the most impact because I can't do
all the things, you know, you know, do I, do you know, IAM or
do I do DLP? You know, how much money should
I invest in my application security program versus my
operational kind of operational teams?
It all comes down to being a trade off and kind of you're
doing kind of, you know, calculated gambles because you
know, you can't cover all the things, you know, you're not
going to have all your bases covered.
And so you're trying to do your best, you know, via whatever
data you have or your kind of your gut feelings of what you
should cover. And again, the disparity is, is
huge. A lot of the, a lot of the
frameworks that are out there are kind of designed around
larger companies where they assume you can do the things,
you know, and I hear it, I heard a lot from, you know, especially
people that are making the frameworks, everything from this
to miter. I'm like, no, I can't do that.
Actually, right now your, your framework is becoming a
distraction to me because I'm having ruthlessly prioritize XY
and Z, you know, a / B and this and that.
And I have people coming in, hey, how, how is your coverage
of this framework? And I'm like, doesn't really
apply to Louis because we're too small.
And you having worked and having runs through operations teams
for various sized companies, you know, one of the things I, I, I
saw from that is, you know, while the inputs are very
similar and the outputs are very similar, you kind of how the
sausage is made in between is vastly different.
Every company does it completely different, even though again,
the outcomes are the same, like you've resolved the incident if
you you've fixed the thing, whatever it is.
How they get from A to B varies wildly.
And that comes down to kind of what, you know, what sector are
you in and how much budget do you have, which again, the
budget drives a lot of things. And if you're above the security
poverty line, like you have things like, you know, threat
intelligence and threat hunters and you have all the all the
latest shiny objects, you have teams, you have your own data
science teams building things, you know, versus below the
poverty line, like you're buying whatever vendor you can afford.
And hopefully it covers as many of the boxes you need to check
as possible. And for the things that you
don't, you just kind of cross your fingers and, you know, hope
for the best. I wonder if there are customer
like companies that make very extreme decisions just because
they specifically because they can't afford to do, they can't
afford to deal with the consequences.
Like like just to, to give an extreme example, they might say,
you know, we don't use laptops because, you know, we can't
afford endpoint security, which I guess like in and under and
under very extreme and very unique circumstances that might
make sense. You know, like, you know, we
think we only use phones or we only use typewriters, but I
guess that would start harming the business at some point.
Yeah. I mean, you still be able to do
business, right? But I've been places where, hey,
we need endpoint protection for our systems in the cloud for PCI
and they're like, hey, you know, use clam AV or some free thing,
right? I'm like, isn't that a virus?
Like, Are you sure you don't want to install that?
Anything you check the box, anything to, you know, not
provide more funding at the same time telling you to just go
figure it out, you know, or kind of fudge things, whatever.
While the smaller environments can be fun because you do have
the, you know, kind of the wiggle room, you can also be
kind of stressful as well versus, you know, a large
company where you can do all the things and you're probably doing
most of them correctly. At the same time, you're at a
big company and you're kind of locked into, you know, how they
do things and you're in your lane and that's about it.
So, you know, there's trade-offs on both sides, so.
I think one of the things that exists in in most big companies
and I think it's become sort of a household name over the years
is soccer team. And a few years ago, I think you
you sort of declared the sock was deceased.
So do you think that that still holds true today?
Have we resurrected the sock somehow?
Is it is it somehow on life support?
Like it looks like socks still exist.
Have they changed enough to still be relevant in your eyes?
What do you think? Yeah, Also just to jump in on
that, like also with the rise of AI, has it doubled down on its
death or is it giving it a new chance at life?
It's kind of a loaded question. So first I I kind of break this
into two worlds. There's kind of the enterprise
world and then there's the, the kind of the managed service
provider world. You know, the MSS PS of the
world who have their managed socks, even when they're both
called socks for the operation centers, how they operate is
vastly different in the world. And so when I refer to kind of
the, the death of the sock, I'm, I'm kind of referring to
enterprises, tech companies versus demand service providers
in, in enterprises. It used to be very similar to
MSSP to be a giant room with a bunch of screens in it.
You know, kind of came out of the knock world.
We just kind of cloned it. It was a, a physical location
where people were at looking behind screens, You know, as
kind of the, the rise of SAS has come around and the way we are
able to kind of distribute our teams anymore.
You know, first I was kind of pushing for a distributed model,
which kind of made sense. Everyone else was distributed.
Why should a sock have to be a physical place anymore?
And now I've kind of changed a little bit to saying, hey, look,
the sock is no longer a noun. It's a verb, it's an action,
It's a capability, right? In my last couple roles,
wherever I had my kind of SoC function, which is kind of like
your, your Tier 1 triage functions, your 24/7.
It's kind of like the security is equivalent to an IT help
desk. And it doesn't matter where in
the world that's at. If you think about the IT help
desk, if you open a ticket with IT help desk because whatever
your VPN is broken, whatever it is, right?
You don't care where they're at all you want your problems
fixed. Or if you're having one Slack,
right? You don't care where in the
world they're at as long as your problem gets fixed.
And these kind of tier one teams are the kind of the same thing
for enterprises because you've actually look at all the things
that these SoC teams do for enterprises.
Only about half of their work is actually dealing with alerts
generated from security tools. The other half of the work they
do is dealing with people, you know, if you have a, you know,
help security channel on Slack or if you have a ticketing
system, open tickets with security, if you people are
reporting issues or reporting phishing emails or what not.
Like there's a lot of volume that comes from people that's
also landing in your, in your tier one function rate or your
enterprise sock. And the, the bigger your company
gets, the more prevalent that becomes.
When I was at, you know, Salesforce, we had a, a pretty
large sock there and over 60% of the, what they did was dealing
with people and people reports versus machine based detections.
And if you actually, you know, kind of double click on that for
a second, it kind of makes sense where the larger you get, the
more resources you have, the better you get it kind of
refining your alerts, get your detection pipelines running, you
know, you're more mature in, in making your detections or what
not, and you become better automating things away.
So on the machine side, you start getting better at it On
the human side, human noise scales literally, right.
If you have, you know, 1 complaint for every 100 people,
if you go from, you know, 30,000 to 60,000 people, those
complaints go up literally. And so that noise coming to your
sock grows, but you know, literally as well.
And there's not a really good way to automate that away.
There's no sore platform to, to automate a way people
complaining about things, you know, it just doesn't exist yet.
But you know, I wish it would. Maybe AI bots will solve that
for us, but that's a big chunk of what they do in in
enterprises. Again, that's why I kind of draw
the analogy like IT help desk for security, because they are
routing a lot of issues. OK, I have a, you know,
questionnaire from a vendor. Where does it go?
It goes to GRC team. You know, hope I have a, you
know, XYZ problem up it goes to IT.
Oh, that goes to dev OPS, not us or a phishing e-mail.
Yep, Yep, it's legit phishing e-mail.
I'm going to go into the e-mail boxes now and delete it from the
company, add a block list, you know, blah, blah, blah.
And so half again, half what they do is that and half is
dealing with the alerts coming from, you know, tools like Wiz
or Crowdstrike or whatnot and triaging those as well.
And out of all the work they do, when, when I've taken the
metrics from Salesforce in spring car and last year my last
few Rolls and kind of bubbled them down.
One of the universal kind of themes I saw running across all
three of those is the actual ones where you catch the bad
guys when there's an incident, things escalated.
That's only about 5% of what they do.
And and that's why they want to be there.
They want to be there to catch the bad guys, right?
And it's a small fraction what they do.
The other 95% of it is the crap work they don't really want to
do. Again, phishing emails, tickets,
you know, benigns, false positives, you know, blah, blah,
blah, blah. All the things we hear about all
day long. And they wade through that 95%,
you know, of the junk all day long to get to that 5% of the
things they want to do. If this is what those guys are
doing, it doesn't make any sense for the sock to be a noun.
You know, it can be a verb. It's a capability where they're
delivering this, this function to the company.
Doesn't matter where in the world they're at, as long as you
have a process in place where you can distribute the work,
cool, you're set. And you contrast that to an MSSP
where it's a profit center versus a cost center.
They're delivering a a unifying service to all their customers.
They know exactly what they're doing.
They know, you know how much it cost to process an alert, how
much time people spend on it. You know how much it costs from
end to end for the entire life cycle because that's their
business and their customers want to know what am I paying
for? So if you look at it from the
kind of the two contrasting lenses, what these guys do is,
is vastly different. The responsibilities they have
is vastly different. So applying that conventional
sock model MSS PS Sure, it makes sense, right?
Again, because you're uniform service, they're dealing with
customers, they have to have that kind of central location or
the central capability enterprises doesn't make sense
anymore. And we're seeing that today.
People call, you know, I have my sock team, where they at?
Well, there's a guy in Europe, there's a guy in Asia, there's a
guy in South America, there's a guy out here there wherever it's
a verb versus a nail. You had mentioned that you might
write a sock manifesto. Did you ever do it?
I did. I got about 80% of the way
through it and I was actually writing it with the help of
Anton Chouvakin, who I saw was on here a couple weeks ago.
Also has opinions. Opinions on socks?
Yeah, I've known Anton for a couple decades now, so I'm
constantly bouncing things off him.
And he was helping me write this manifesto.
And part of it was kind of what levels of maturity can you be at
if you're below the poverty line?
And what level of maturity are you at if you're above the
poverty line? And we come up with kind of four
levels of maturity and each one of those levels of maturity had,
you know, kind of certain things tied to it, The things that you
you should do and can do or, or the kind of options you get, the
trade-offs you can have probably like the, the, the team size
that you have, you know, kind of rough budgets compared to the
size of your company. Because again, like I was saying
earlier, a lot of the frameworks we use today, you know, they're
kind of one-size-fits-all and they're kind of tethered towards
big companies. Of course, you can do all the
things your Google, right? You can just do all the things
you want you to do. And for, you know, probably 90%
of the companies in the world, they they can't do that.
And so I'll strike them over the way to to kind of bucket those
into different categories and say, Hey, if this is the size of
the company you're at, this is kind of the team makeup and
composition and and numbers people you have.
Like what's the right fit for you?
Yeah, exactly. I want to make something that
wasn't one-size-fits-all, that was a little more tailored to
the size that you're at, the budget that you're at, and kind
of realistic expectations. I'm curious cause also you've
done detection and response at multiple companies.
What's kind of surprised you when you've switched between
them were the things that were standard, maybe like securities
reputation, that have changed or evolved in the past many years.
When I've gone from org to org and whether that be a, a big
company to another big company or a big company or a small
company or a small company to a big company, you know, one of
the things that I've, I've realized is it kind of what I
raised earlier is every place does it different?
I mean, the inputs are the same as much noise comes in, the
outputs are the same. You fix whatever the issue was
or you need the risk, whatever it is.
But how you get from point A to point B is different from every
single company to every other company I've ever been in.
Yes, to, OK, these ticketing systems, they might have
something in common, right? But what thinking system they
use Salesforce. We use Salesforce.
So the last time we use Jira, you know, I use ServiceNow here.
I mean, it all varies. So how the sausage is made is is
completely different between every company I've been to.
The level of maturity is completely different everywhere
you go, depending on what the priorities were, the person that
was in the chair before you, what the company wanted them to
do. There's no one-size-fits-all
kind of best practice for how you do, you know, DNR or on a
sock or do incident response. Everybody kind of makes up their
own IR plan, you know, You know, to give an example, and
everywhere I've been, it could be a check box, it could be an
outline, it could be a 20 page document, you know, with
pictures. So when you start working in a
new company, never probably don't assume anything.
I've made that mistake a few places I've walked into.
Oh, of course we're going to have this or we should be doing
it this way. Why are we doing it this way?
Oh, because XYZ. That's why we're not doing it
that way. I'm like, oh, yeah, OK, that
makes sense. I I should shut up now?
We have one last question for you, which I think we're one of
the things we found really exciting and interesting about
your career is that it's very much doused with like your
entrepreneurial mindset. You had a cool company that did
work for paintball something or another.
You could tell us more and you had a security startup for a
moment. And I would love if I think it's
like an amazing outlook to have on the world.
But I'm also curious what drives you to build and what you think
maybe is still missing in the world that you want to create.
Besides the Sock Manifesto. You know, but, but you know,
I've had a, a couple, you know, start-ups.
I've, I've tried on my own. I've had, you know, one a long
time ago that was successful. We exited after a year back in
early 2000s. I want to say it's a lot of fun.
You're doing something you're very passionate about because
again, it's, it doesn't become work, it becomes fun, you know,
in a lot of ways. And that's how I kind of felt
about, you know, most of my startup ideas.
It was something I was very passionate about, something that
I, I actually enjoyed doing. And so of course, you, you, you
pour yourself into it until you, you know, run out of money and
have to go back to get a regular day job, which is what's
happened the last couple times. But I mean, eventually what of
them is going to stick? Amazing, Eric, what a joy to
have you on. Thank you so much for joining us
and talking with us today. Sure I'm I'm glad I was just
awake after only One Cup of coffee.
I think your maybe your drop off of the kids may have helped.
Yeah, they, they were running around like 6:00 this morning
all, you know, panicking. Oh, I can't find my shoe.
Where's my pencil? And, you know, all the things I
arranged for them yesterday were all magically missing this
morning. So.
Lovely. Amazing.
Yeah, parent life. If you enjoyed the show, be sure
to subscribe and share a link to the podcast, but not your cloud
keys. And as always, if your cloud
security strategy is making you cry, don't worry.
Just cry out loud.