Screaming in the Cloud - Celebrating Security with Fredrick ‘Flee’ Lee
Episode Date: September 24, 2020About Fredick “Flee” LeeFredrick "Flee" Lee is the CSO at Gusto, the platform that helps 100,000+ small businesses nationwide pay, insure, and provide benefits for their teams. Flee has m...ore than 15 years of experience leading global information security and privacy efforts at large financial services companies and technology startups, most recently as Square's head of information security. He previously held senior security and privacy roles at Bank of America, NetSuite, and Twilio.Links Referenced: LinkedIn: https://www.linkedin.com/in/fredrickdlee/
Transcript
Discussion (0)
Hello, and welcome to Screaming in the Cloud, with your host, cloud economist Corey Quinn.
This weekly show features conversations with people doing interesting work in the world
of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles
for which Corey refuses to apologize.
This is Screaming in the Cloud.
This episode is sponsored in the Cloud. boundaries. So it's difficult to understand what's actually happening. What Catchpoint does is makes it easier for enterprises to detect, identify, and of course, validate how reachable
their application is, and of course, how happy their users are. It helps you get visibility
into reachability, availability, performance, reliability, and of course, absorbency,
because we'll throw that one in too. And it's used by a bunch of interesting companies you
may have heard of, like Google, Verizon, Oracle, but don't hold that against them,
and many more. To learn more, visit www.catchpoint.com and tell them Corey sent you. Wait for the wince.
This episode is sponsored in part by StrongDM. Transitioning your team to work from home like
basically everyone on the planet is?
Managing gazillions of SSH keys, database passwords, and Kubernetes certificates?
Consider StrongDM.
Manage and audit access to servers, databases like Route 53, and Kubernetes clusters,
no matter where your employees happen to be. You can use StrongDM to extend your identity provider and also Cognito to manage infrastructure access, automate onboarding, offboarding, waterboarding, and moving people within roles.
Grant temporary access that automatically expires to whatever team is unlucky enough to be on call this week.
Admins get full auditability into whatever anyone does, what they connect to, what queries they run,
what commands they type,
full visibility into everything.
That includes video replays.
For databases like Route 53,
it's a single unified query log
across all of your database management systems.
It's used by companies like Hearst, Peloton,
Betterment, Greenhouse, and SoFi to manage their access.
It's more control and less hassle.
StrongDM, manage and audit remote access to infrastructure.
To get a free 14-day trial, visit strongdm.com slash S-I-T-C.
Tell them I sent you and thank them for tolerating my calling Route 53 a database.
Welcome to Screaming in the Cloud.
I'm Corey Quinn.
I'm joined this week by Frederick Lee, the CSO at Gusto.
But the world knows you as Flea.
Welcome to the show.
Thanks a lot for having me, Corey.
Yes, the entire world knows me as Flea.
As I've told other people before, pretty much the only person that calls me Frederick would
be my parents. So Flea is what I'm most comfortable with. And I appreciate you taking the time out
to actually chat with me today. No, by all means. So a few things to go into, but first you're the
CSO again, three syllables, not one, that stuff matters or two, whatever it is. Again, it's always
three, three is the right number of syllables as longtime listeners to this show are well aware. But that differs from CISO, C-I-S-O.
What's the deal? Yeah, so it's literally in the abbreviation itself. CISO is Chief Information
Security Officer. And this is actually, I think a lot of people are more familiar with that
as kind of like that role when they think of cybersecurity. I am the chief security officer, which means that I have a much broader view and a much broader mandate with
regards to security. So part of my responsibility is also the physical security and the safety
of Gusto, our assets, as well as our people along all those lines. So, you know, the nuance there
is like if you're a CISO, you get to spend a lot more time just focused on just the cyber side and punching keys on the keyboard. When you're a CSO, you have
to think about things like, hey, is this building going to be resilient towards an earthquake and
some of those other fun topics. But it's all at the end of the day, it's still risk management.
And it's just a matter of like how broad you actually want to go with that risk management.
And there are always pros and cons of which roles you want to have. I have a lot of fun being the CSO because it also just really brings
so many other things into our toolkit with regards to just security. Like one of the classic things
that I think people often forget about is that bridge between our cyber world, I mean, like the
information technology, et cetera, and the physical world. Like a common example of that is badge access, right? So you think about all the things you can
do as a CISO when you can combine information and telemetry from your badge access for buildings
into telemetry regarding like how users actually logging into endpoints, et cetera. So it's a really,
really great role. I'm very, very thankful for all the people that help support me to actually
be successful here. I have a phenomenal team. And yes, just a lot of fun being a CISO.
So in the interest of full disclosure here, here at the Duckbill Group, we are Gusto customers,
which is great. You folks are not sponsoring this episode. So basically, this is just my way of
getting trouble tickets escalated. But for those who aren't aware, so we can have a conversation
that doesn't leave everyone scratching their heads, Gusto provides effectively payroll and benefits as a service
mostly. I have better things to do with my life than sit there and click through payroll and
running all of that myself. It's awful and you never get it right, only wrong. So I pay a third
party, in this case, Gusto, to handle a lot of that for me, given that we have employees in multiple states. It handles a lot of the administrivia that is kind of awesome. Now, security is one of those areas that really matters for something like this, because security number, the validation of your legal right to work in the country, et cetera, to a third party.
And if you don't like it, you can quit is more or less the position that people are confronted with.
So everyone has to care about security, but you folks have to care about it in a way that goes beyond what, for example, my Twitter for pets
side project does. Oh, definitely. And we take it like really, really personally as well. It's
fundamentally part of our DNA without strong security and without strong privacy. We can't
really deliver the gusto service in the way that our customers deserve. And I love one of the things
you actually pointed out, Corey, which is even though we want to make gusto
as delightful as possible across the board,
but both for you as an employer,
but also for your employees,
we recognize that we have an oversized burden
to make sure that we're extra cautious
due to the nature of the data
and also because of how people get onto our platform.
Philosophically, we view ourselves as data custodians
as opposed to data owners.
And there definitely is a difference
with how we treat your data
as opposed to maybe how some other companies
would treat your data.
When you view yourself as a data custodian,
you're always thinking about the human
at the end of that data
and what would that human want done with their data.
So for the example that you
mentioned, Corey, for the people that are your employees, you're exactly right. They didn't opt
into Gusto. So I feel like we even have a higher responsibility to these individuals to make sure
that we're doing everything possible to make sure that their data is not only secure, but also
respectful of their privacy. And that includes things like not selling their data, which I wish
was just an obvious choice for other companies. All these other kinds of things that you would
actually kind of want to have as an individual when you would hand over something that's precious
to you to a third party. You want to make sure that we, Gusto, or any of your other suppliers
are always acting in your best interest and putting your interest first, as opposed to putting the interest of the company or some random advertiser or some
marketing firm that just wants to collect the data. So it really is critical for us to nail
security. And it's also critical for us to nail privacy, because this is ultimately like some of
the most sensitive data that people have in their life. And we recognize the responsibility that actually comes along with that.
And yeah, I mean, it's definitely a privilege to have people trust Gusto to not only deliver
them a great employment experience, but to also do that in a secure, private, and ultimately
respectful manner.
One of the biggest challenges I find in security is akin to what I deal with, dealing with the AWS bill and the pain that it causes.
Everyone really cares about this and tells you how much they care about this right after they really should have cared about this.
Now, the stakes are lower when it comes to cost than they are with security.
There's headline risk.
There's the actual real harm that breaches can do to people.
In some companies where a security breach could actively lead to people being killed,
depending on the circumstances. Now, Gusto is generally not at that tier, but you are the
custodian of other people's information. So I guess this is a question that I normally ask
with a very different tone, but how do you sleep at night?
How do I sleep at night?
It's an interesting thing, and actually, I want to flip that question over.
You know, obviously, I have years of experience in the security industry, and it's easy for people in security to maybe get a little, I don't want to say necessarily lazy, but jaded because of all the things that we actually see.
For me, I focus more on what gets me up in the morning.
And the reason why I say that is exactly what you said, Corey.
The nature of the data that we deal with is extremely sensitive.
Whereas you articulated that, yes, maybe Gusto isn't, you know, we're not handling nuclear secrets.
We are handling people's lives, though. Those names, those addresses,
insurance information, people's ideas about how they actually want to save for retirement,
et cetera, those are human lives. And I take that very, very personally and very seriously.
And so I wake up every morning energized about what else can we do to make this safer for people, but also easier for them to take advantage of that safety.
But you're exactly right. It is a serious thing, but it's one of those things that I believe that
we actually built a great infrastructure and a good team so that we are more energized by this
problem we need to solve, as opposed to maybe scared and apprehensive staying up at night.
I feel like if you're staying up at night, maybe you don't have great plans, but I do feel like we actually have some really good plans here at Gustav, as well as some already
great things we've already implemented from a security and privacy standpoint. So I'm not a
huge fan of actually being in the waiting game either. And this goes somewhat into my philosophy
about how to actually build and construct security teams. Yes, obviously, traditional security teams
do spend a lot of time, quote unquote, waiting, but I think that's not the best utilization of a security team.
Your security team should be much more proactive.
They should be finding new things that they can be building.
They should be finding new ways to actually improve the infrastructure.
They should be finding new ways to make it even easier for our internal employees to
build great secure products by default.
And if you are in that scenario, if you have built a security team that's kind of like an enabling team, it's really all
about engineering, building great security controls, building great security frameworks,
then you're constantly having your security team with a mission to do and not just a wait and see
what the attackers are going to do. We should always be feeling like we need to be out competing attackers at every given second. And we need
to be energized, not just at Gusto, but the industry overall and move away from this previous
model of just waiting for some blinking lights on the screen, but being more into a model of
building things to either automatically address those blinking lights slash alerts or automatically remediating issues as they pop up.
Before you wound up at Gusto, you did a number of senior privacy and security roles at small companies without a lot to lose,
like Bank of America, Twilio, and Square.
So on some level, it feels like this is okay.
Compared to some of those things, you have all the same personal information of a large number of people.
But at least this time, you don't generally hold their actual money, presumably.
Although then again, we do have bank transfers going to you folks, which are then paid out to tax authorities and to employees.
So maybe I'm speaking too soon on that.
Yeah, obviously we deal in finance as well, because we do move money.
And we do help people manage their money as well. You know, there's a product that we have,
you know, Gusto Cashout, which allows employees to have more control over their paycheck and when
they're paid. And so it's a lot of the same problems you indicated have kind of been in the
business of protecting people's really, really sensitive data for quite some time, even at those small, tiny companies like Bank of America or Square. But, you know, it is one of
those things where we're dealing with a lot of the exact same things here at Gusto. But there's
another interesting element, I believe, with the nature of the data we deal with here at Gusto is
that we're also doing this on behalf of a lot of really small, medium-sized businesses. And to that extent, I feel like there's maybe even an extra obligation that we have,
because not only do I need to be a great security person for Gusto,
I need to make sure I'm also being a great security person
and a great security team for our Gusto customers.
And that means us thinking really, really proactively
around some of our security controls that end users touch. Now, at Bank of America, that's kind of like a different situation because Bank of
America thinks that their customer and their profiles are maybe a little bit different. Bank
of America has a lot of B2B customers as well. Twilio is primarily a developer API type company,
still sensitive data, but the interactions with their end customers is a little bit different. We do know that at Gusto that it would be unfair of me as a CISO of Gusto to expect Corey to have a full-blown
security team. And it should be part of my job to help Corey solve security problems and to make
sure that your company is secure at a minimum when you're actually interacting with Gusto.
But ideally, if there are more things we can actually do along those lines, are there other things that we can do
proactively to help Corey ultimately just have a successful business? And I do believe as a
security practitioner, and I hope other security practitioners believe this, it's part of our job
and part of our calling as security professionals to make the world more secure, not just our
company, but also our customers and other people that are impacted by us in the ecosystem.
You've been focused on something that you're calling lovable security, which sounds like a ridiculous oxymoron. Partially, I experience security has not always
been great. And that's either in the form of how they interact with security, maybe at their
company, maybe how they interact with security at a provider that they have, or how they interact
with security, even in their personal life, in their personal computer, etc. The stereotype of
the security team is, oh, it's a bunch of grumpy, mean people that every
time you want to buy something or every time you want to install a new app or every time you want
to use a new technology, they immediately say no. And they're always grumpy and they're constantly
trying to find some way to essentially stop you, to essentially slow you down, to make things more
difficult. You know, they're the kind of security team that says, hey, you need a 26 character
password and you have to change that password every 90 days.
Things that ultimately just aren't good experiences.
And we know that in order for security to really be successful, we need to drive behavioral change in people.
And you get people more interested in collaborating with security when your security team, when your security philosophy, when your
security discipline is much more approachable. And that's where the lovable comes in. It's this
whole notion that security control, security people should manifest in such a way that the
end user doesn't try to avoid it. And a great example would be some of the things we're actually
seeing now in modern computing when it comes to things like authentication. So, for example, if you use an Apple device, for example, then, you know,
Apple has encouraged people to have strong passwords on their mobile devices because you
get a benefit of being able to use Touch ID or Face ID, which is a much more pleasant experience,
but it actually gives you even better security. When it comes to people inside of a workforce,
if your security team is a team that partners
with other business units inside of your company
and helps them actually build to, you know,
find great solutions for security challenges,
that becomes lovable.
This whole idea of having a security team
that you actually go to proactively
because you see them as a source of help
as opposed to a source of fear or a source
of potential trouble. Your security team should look a lot more like your personal trainer or
your fitness coach in the gym as opposed to the mean, angry bouncer at the nightclub. Actually,
I don't know that much about nightclubs, but I know that they have bouncers, but you know,
that kind of thing. So I did something for the first time earlier this year before these unprecedented times,
remember back in precedented times, which we all miss. And I went and walked the expo floor at RSA
and looked at the program and all the rest. And I learned a few things. One, you're not allowed to
give a talk at RSA without the word firewall in the title. Two, there's an awful lot of companies sitting there at the expo floor selling rewarmed versions
of the exact same thing, and none of them seem to be focused on actual security improvements.
Instead, it all seems to be directed at more or less box checking and ensuring that once you have your data breach,
you can point to having done all the right things in a fruitless effort to prevent it.
Is that an overly cynical take? Is it spot on or something else entirely?
I'm laughing because I might be one of the worst people to ask this question of,
because I don't think it's overly cynical. I do think for the majority of it, it is spot on.
This is an area where the security community should and could do much better. One, there's tons and tons of companies that are trying to sell you things that say, oh, this is going to
solve all of your problems, or you're going to magically make your data loss issues go away,
or we're going to prevent all attacks from this particular vector, when the reality is we know that that's not a real thing.
We know that a motivated attacker can definitely circumvent all kinds of various different
controls. We know that there are human elements that can make some of our security controls fail
as well. And I do agree with you, a lot of these things are almost like rehashes of each other or just clones.
But even more so, they're not really trying to help you manage and reduce risk.
They're really just trying to help you feel better about your security posture and to give maybe your execs or the board or auditors something to look at. And there's a lot of products that are also focused on trying to solve problems that probably aren't the best risk reduction return for you. You go to RSA,
you walk the expo floor or any of these other security events or just vendors in general.
And you always hear that the classic acronym that makes me cringe every single time, APT,
Advanced Persistent Threat. Some people actually do have that.
Most people don't.
You hear all these things around zero days.
Yes, zero days are an issue, but that's not generally how people get compromised.
They're getting compromised by vulnerabilities that have been living with them for 90, 180, 360-something days, et cetera.
And you don't see a lot of vendors addressing these fundamental security issues.
Some of these things that are actually more process related or just ultimately aren't as sexy.
And even more so, they don't believe they can attach a six or seven figure price tag to.
Some of the best security tools that I have found and have used have all been open source and free.
And if they weren't free, they were ridiculously cheap.
And there's so much power we can actually get out of that. It's also one of my frustrations with some of the cloud providers, with some of the security
tooling and features that they provide, where it's actually just overpriced. And so when you
think about the vendors in general, I just think security vendors can do a much better job. But it
also requires us in the broader ecosystem of technologists and consumers to force them to be more reasonable with their pricing, but even more so forcing to be more transparent and honest about what their tools actually do.
And it's perfectly fine for a tool to only solve one particular thing or to be targeted at a really, really small scope.
In fact, I actually would argue that may even be better.
So I just think that we have to start holding our vendors
a little bit more accountable
and asking for a lot more transparency.
But that's also going to require some of us
in the security industry to be more honest with ourselves.
Some of the reasons why the vendors can get away
with some of the things they do
is that we in the security industry
have often forgotten
our technical roots and we haven't put our technical hats back on and aren't keeping abreast
of modern technologies as well as we could. And because of that, yeah, vendors can kind of pull
the wool over some people's eyes and promise a product that we know from a technical standpoint
either can't work or won't work that well. I think that's actually one of the areas, or yet another area,
that there's almost like a shared responsibility, shared blame.
Blame on both the vendors for being way, way, way, way too shady,
but also blame on us in the security industry for not staying as technical as we need to be,
to not staying on top of technology in the same way that we need to be.
In what you might be forgiven for mistaking for a blast from the past, today I want to talk about
New Relic. They seem to be a relatively legacy monitoring company, and I would have agreed with
that assessment up until relatively recently. But they did something a little out there. They
reworked everything. They went open source, they made it so you can monitor your whole stack in one place, and most notably from my perspective, they simplified their pricing into something that is much more affordable for almost everyone. There's even a free of slides for all of the different security services that AWS has.
And I know more than I probably should about basically every AWS service because I have a trick memory for stuff like that.
And I fixed the AWS bill.
So I'm most familiar with all of their various pricing models.
And I'm doing the mental math figuring out how much all these things would cost.
And yeah, it's clear that just having the data breach
would be less expensive overall.
So go ahead and do that instead past a certain point.
I kid, but not by much.
I've always been very down on the concept
of charging extra for security
in a variety of different platforms.
If Gusto, for example,
charged me an extra fee to add multi-factor auth to my login, I would not be a Gusto customer,
for example. Where do you land on this? You and I are cut from the same cloth, Corey,
because yeah, I mean, I would never want to work at a company that was charging users more to be secure. I feel like that should be a default. We shouldn't charge you for 2FA.
And with AWS, it really is somewhat of a pain point
and a frustration for me.
Obviously, I do want great security,
and that means at the end of the day,
we're going to pay what we need to pay in order to get that.
At the same time, I feel like a lot of things
should be just almost just included in platforms
and almost like a bare minimum.
When you think about some of the
great things that AWS has as services, we should want every AWS customer to have those by default.
You think about things like Macy, for example, helping people discover if they have sensitive
data that they have in S3, because they're just in other areas in AWS. That should be something
that we just give to people for free. Because at the end of the day, my hope is that by making AWS or other cloud providers
or just software in general secure by default,
having those security features easy and free or really, really, really cheap,
we get more people to adopt it.
So more people would want to be on AWS if they realized they could actually have
the exact same security controls or better security controls in the cloud. And there's probably actually
maybe some edge cases where AWS may want to charge
some additional prices. I don't know Amazon's complete business model or how
they actually price things out. Anyone knows Amazon's complete business model, my lord.
The product strategy is yes, so who could say? Yes. I'm not
really sure if Amazon knows themselves. I think their business strategy is yes. So who could say? Yes. I'm not even sure if Amazon knows themselves. I think
their business strategy is making money. But, you know, there's like so many just small,
bare minimum things. And I think ultimately it can drive greater adoption. Like if we made it
even easier for people to run good tools to understand, are they under attack? Do they
have a misconfiguration? And I think everybody knows that IAM is like this great, extraordinarily sharp knife that's there for developers to cut
themselves on. And when you get it wrong, it's your fault. Yes, yes. Haven't you read the shared
responsibility model? Yes. And it's like, yeah, you know, I can have a shared responsibility
model also with my five-year-old nephew, but it doesn't really seem quite equivalent.
But, you know, when you think about some of these other AWS services, you think about things like GuardDuty.
You think about all these other things.
You think about actually just even their security hub.
And that security hub should just be free.
And it should just be for everybody.
AWS should actively encourage and want people to have better security because ultimately that could even be a competitive advantage for them. It makes it even easier for people to actually get into and drive adoption.
And the reality is a lot of people were attracted to moving to the cloud because they thought that
there was a promise, whether real or not, or articulated or not, that the cloud was going
to make it easier for them to operate at speed, with agility, and with safety.
And a lot of really, really small businesses got their starts in AWS.
And it'd be even better to encourage other small startups and other small businesses
to operate in AWS, but they need a security team or they need a security expert and they
need like a really, really, really well-tuned and DevOps engineer in order to be successful doing that.
That definitely is not lovable.
And I think one of the things that would be great to see from Amazon or even other cloud providers,
because, you know, Amazon is not the only one out there, is to make all those security features,
or at least think about some core critical ones, make those free, make those extraordinarily cheap.
Are we in a day and age where people even need to pay for
certs anymore? We should make TLS just prolific and extraordinarily easy for people that are
actually in AWS. Should we need AWS customers having to think about DDoS protection and trying
to actually figure out, well, how much should I pay for? Should I pay for it? That seems like the
kind of thing that you would just want by default, by moving to the cloud and taking advantage of that.
You know, do we need a small startup of four or five brilliant little engineers worried about how to configure Amazon Shield and Amazon's WAF or if they should even pay for those things?
I would hope that those kind of things would at some point become free or much, much cheaper than what Amazon currently offers. There's so many great things that are in Amazon that so many security
engineers or just security conscious people want to take advantage of. But there's this ceiling of
the cost and AWS bills can already be really expensive to start with. And for the uninitiated
or for the people that maybe aren't as sophisticated,
it's easy to say, well, this security thing looks really, really expensive. And I don't quite
understand what the benefit is, because often security tools are targeted at preventative
controls or helping to detect certain black swan events. And so you don't always realize the value
of it until after an attack has occurred,
even though it's actually something we want everybody to have. It's kind of like fundamental
things. Like there's so many great things. I think Amazon even has vulnerability scanning
was one of their offerings. And, you know, there's AWS Inspector, like the list of security
services, actually, as you said, Corey, it's really, really broad and it's massive. And I
think maybe an even more interesting experiment would actually be to go out
and see how do these services that Amazon offers from a security standpoint, how do they actually
cost people in the real world operating at scale? So when you're operating at quote-unquote Netflix
size or something like that, and how does that actually compare to actually buying some other
commercial alternative? Or how does that compare to using an open source project?
Or ultimately- Some cases you can pay for that particular security service
or staff a team of eight people and save money.
It's ridiculous on some level.
And I would also argue the competitive threat story.
If there's yet another S3 bucket league
that makes the headlines in the New York Times,
then the response from the world is not,
oh, Amazon is insecure. I should move to Azure instead. Instead, it's cloud isn't secure.
So whenever there's a setback like this, it affects the entire industry. And the S3 stuff
drives me up a wall because it's pernicious. I understand how it got there. But if you're
managing data that you have to be wary of, it is not that challenging
to ensure you get there. The Capital One breach, for example, was not an S3 bucket problem. It was
a series of various small misconfigurations chained together. And that's still not okay,
given that they are a bank. However, it was a sophisticated attack that exploited those
small misconfigurations, not they forgot to check the
box somewhere. Yep, definitely agree with you. And I love one of the analogies and the fact that you
also mentioned a bank at the end. So previously, we were talking about a small company I used to
work for called Bank of America. And, you know, this is the podcast that people can't see all the
gray hair that I have. But earlier, several decades ago,
online banking was a new thing. And one of the things that we recognized in the banking industry
was that it was important for all banks to be secure because we wanted customers to feel
secure using online banking. So we recognized that a customer wouldn't go and say, oh,
Bank of America is insecure, so I'm going to go
use Wells Fargo. A customer instead would just say online banking is insecure. And we're still
somewhat in that situation when it comes to cloud providers. The Capital One situation was really,
really interesting. As you said, it was very, very nuanced, but it still had somewhat of a
chilling effect. And there are still companies where mentioning the word cloud
or trying to get a migration to the cloud is still taboo. And these little small things add up and it
adds up into the decision making of other executives within those companies. So when you
think about a CFO or a CEO, they may not be following Amazon tech in the same way that we do as a CSO or a CTO or even a CIO.
And because of that,
all they hear is what they saw on the news.
They heard that, hey, a bank was compromised
and they ran in the cloud.
They don't pay attention to the rest of the nuance there.
And when there's all these stories
that are related to compromises,
as you said, like things like S3, things like some of the concerns around AWS's previous metadata service implementation.
When you hear all these problems, you can easily see how that could cause fear and this chilling effect of these larger corporations that want or at least have individuals that want to migrate and move to the cloud.
And it's a really interesting thing because I feel like Amazon definitely figured the story out with regards to scaling compute, but they had the same opportunity
to scale security. And it's not just Amazon, obviously all the cloud providers, some do better,
some do worse. But I think overall as an industry, the cloud providers can do a lot more for their
customers and a lot more for the ecosystem when it comes to security and making
it very, very, very easy for advocates of cloud technology to be able to explain to other people
inside their organizations why moving to the cloud can be done and also be done safely.
The increasing challenge that I see is that there are so many different levels and layers to
security.
Yes, this is a complicated, sophisticated space. But at the same time, as you were alluding to, you cannot have a scenario where you're a four-person startup and you need to hire three full-time security people in order to keep all of it straight and even then potentially get something wrong.
It feels almost like a losing battle.
Hopefully it's not a losing battle,
but it definitely is more complicated than it needs to be. There are some really, really good
resources for tiny companies trying to get started and free resources. Like obviously there's, you
know, OWASP or somebody just wants to be a self-motivated engineer to go learn some things.
I think everybody who's interested in cloud should be reading every single thing that Scott Piper
ever writes to help them also be a little bit more self-service. But at the end of the day,
you're still trading time. So instead of actually working on those features that you need to work on
as a small startup, you're a four or five person company. One of your biggest risks is that you're
not building fast enough and you're not building the right thing. And so to have to spend some of
that time also worried about actually solving security feels unfair or at least not as helpful as we could be or the industry as security professionals could be in the industry for cloud service providers could be.
There are some good additional resources.
I know that there is a startup security organization.
There's actually a couple of CISOs that got together that he wrote some guidance to help startups,
but it still requires that time investment.
What I would love to see instead
is Amazon being extremely opinionated
and not just Amazon, but other cloud providers as well
and making it really easy for people
to make the right security choice by default.
And I know that Amazon has made some improvements there,
like, you know, with regards to how S3 buckets work now versus, you know, with regards to public versus private, a lot of our
things actually do on the network side, but I think there's a lot more that they could do so that
all these tiny companies have security by default if they're kind of on this golden path. And this
notion of building a golden path, I think, is fundamental to this idea of supplying
lovable security. You have to make the right thing to do the easiest thing to do. And Amazon, GCP,
Azure, et cetera, they still have quite a ways to go before the right thing to do really truly is
the default and easiest thing to do, in particular for unsophisticated users.
I think one of the hardest parts of all of this is when you look at the entire landscape
of what you can do, there is always an infinite amount of work that could be done to improve
the security posture.
There's going to be an inherent trade-off in some cases between usability and security.
And it's easy to look at that entire thing and realize, the hell with it.
I'm just a small company.
No one's ever going to discover my open S3 bucket and not do any of it. It feels like
there's a 80% that takes 20 minutes and then you can spend a career getting that last 20%.
Some of you folks, for example, that handle the payroll for people like me absolutely should.
For the rest of it, Twitter for pets, not too many people want to see dogs
DMing each other and what they're talking about. It's just a lot of angry noise. So I think
understanding that that spectrum exists, there's always going to be more work to do, but that
shouldn't prevent you from starting is one of the biggest challenges I'm seeing. Definitely agree
with you. Hopefully people don't get overwhelmed and believe they can't get started at all. And
that's where this notion of pragmatic risk comes into play.
You're exactly right.
The risk profile of Twitter for pets is very different than the risk profile of Gusto.
The assets that we keep at Gusto are different.
And really what companies need to focus on is, are the security controls appropriate
for the nature of the assets that they manage
and control? So if your assets are just cat pictures, or I guess in your case, puppy pictures
on Twitter for pets, yeah, the controls you actually want to put in place are very different
than if your assets are payroll information, other finance, people's personal details, etc.
And so, you know, taking a dive into this kind of concept of pragmatic risk is really where
people have to go. And if you run a business, you're already familiar with risk management
anyway, because so much around running a business is trying to make trade-offs. Okay, what is the
most important thing to work on? What is the risk if I don't roll out this feature? What is the risk
if I don't service these kinds of customers? You also just include like, well, what are the risks
of certain kinds of security events happening to my company? And what am I willing to pay to mitigate that risk?
It's not a one size fits all kind of scenario. The nature of security that you want at a
Twitter for pets or cat picture website company is definitely very different than what you would
want even at actual Twitter. Well, after having this conversation, I am a little bit more confident, I guess, in my choice
of how I'm handling payroll at the moment. Flea, thank you so much for taking the time to speak
with me. If people want to learn more about what you have to say, where can they find you?
Yeah, I'm pretty easy to find on LinkedIn. That's probably where I'm the most active.
And it's actually a great area for me to actually get connected to other security professionals
or just anybody who wants to talk about technology, talk about Gusto, talk about diversity in
tech, or just talk about why I have the best opinion on barbecue.
So that's always a good place to actually find me.
Excellent.
And we will, of course, put links to that in the show notes.
Frederick Lee, better known as Flea, CSO, at Gusto.
I am cloud economist Corey Quinn, and this is Screaming in the Cloud.
If you've enjoyed this podcast, please leave a five-star review on Apple Podcasts.
Whereas if you've hated this podcast, please leave a five-star review on Apple Podcasts,
as well as a badly spelled comment telling me that I'm doing it
wrong with outsourcing payroll and that Gusto is just somebody else's payroll specialist. or wherever Fine Snark is sold.