Subscribe
Share
Share
Embed
Fredrick Lee is the Chief Security Officer at Gusto, a platform that helps businesses administer payroll and employee benefits. Before joining Gusto, Fredrick served as Head of Information Security at Square, Director of Security at NetSuite, Lead Security Engineer at Twilio, and VP at Bank of America, among other positions. He has a bachelor of science degree in computer engineering from the University of Oklahoma.
Join Corey and Flee as they discuss the differences between CSOs and CISOs, how Gusto thinks about security, the difference between data owners and data custodians, how security is different at companies like Bank of America, Gusto, and Twilio, how the average employee thinks about security, how successful security teams are able to drive behavioral change at their organizations, what major conferences on security get wrong, why Flee believes security should be by default and not an add-on, how more secure products can drive adoption, why providers should help customers make the right security choices by default, and more.
Screaming in the Cloud with Corey Quinn features conversations with domain experts in the world of Cloud Computing. Topics discussed include AWS, GCP, Azure, Oracle Cloud, and the "why" behind how businesses are coming to think about the Cloud.
Transcript
Announcer: 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.
Corey: This episode is sponsored in part by Catchpoint. Look, 80 percent of performance and availability issues don’t occur within your application code in your data center itself. It occurs well outside those 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, you know, 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.
Corey: 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 audit ability 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/sitc. Tell them I sent you, and thank them for tolerating my calling Route 53 a database.
Corey: Welcome to Screaming in the Cloud. I'm Corey Quinn. I'm joined this week by Fredrick Lee the CSO of Gusto, but the world knows you as Flee. Welcome to the show.
Flee: Thanks a lot for having me, Corey. Yes, the entire world knows me as Flee, and as I've told other people before, pretty much the only person that calls me Fredrick would be my parents, so Flee is what I'm most comfortable with, and I appreciate you taking the time out to actually chat with me today.
Corey: 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 of the show are well aware, but that differs from CISO: C-I-S-O. What's the deal?
Flee: Yeah, so it's literally in the abbreviation itself. A CISO is Chief Information Security Officer. In this [unintelligible] I think a lot of people are more familiar with that as, kind of, 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, the nuance there is 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 do 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. One of the classic things that I think people often forget about is that bridge between our cyber world—I mean, like, information technology, et cetera—and the physical world. A common example of that is badge access, right? So, you think about all the things you can do as a CSO when you can combine information and telemetry from your badge access for buildings into telemetry regarding how users are actually logging into endpoints, et cetera. So, it's a really, really great role. I'm very, very thankful for all the people that have helped support me to be successful here. I have a phenomenal team. And yes, it just a lot of fun being a CSO.
Corey: 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 then 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, yeah, my business partner and I got to pick who we use as a vendor, but our employees do not. So, they show up, and, “Hey, we're going to be giving all of your deeply personal information: your social 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.
Flee: Oh, definitely. And we take it 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 maybe how some other companies would treat your data. When you view yourself as a data custodian, you're always are 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've been would 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 Gusto or any of your other suppliers are always acting in your best interest, and putting your interests first, as opposed to putting the interests of the company, or some random advertiser, or some marketing firm that just wants to collect the data. So, it really is, it’s critical for us to nail security. And it's also critical for us to nail privacy because this is ultimately 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.
Corey: 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, when 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 you sleep at night?
Flee: How do I sleep at night? It’s an interesting thing, and actually I want to flip that question over. 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, or as you articulated that, yes, maybe Gusto, 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 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. I do feel like we have actually have some really good plans here at Gusto, as well some as 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 could be building, they should be finding new ways that he improved 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're 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 a 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 to a model of building things to either automatically address those blinking lights/alerts, or automatically remediating issues as they pop up.
Corey: Before you wound up a 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.
Flee: Yeah, I mean, obviously, we deal in finance as well because we do move money. And we do help people manage their money as well. There's a product that we have, Gusto Cashout, which allows employees to have more control over their paycheck and when they're paid, and so there's a lot of the same problems. You indicated I’ve 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 it is one of the things, 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 and 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 service 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 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 our end customers is a little bit different. We do know that at Gusto, that it would be unfair of me, as a CSO 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 security practitioner—and I hope the 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.
Corey: You've been focused on something that you're calling lovable security, which sounds like a ridiculous oxymoron from where I sit, like military intelligence or IBM Cloud. Tell me more about this.
Flee: Yes, yeah. Loveable security. [laughs]. I personally don't see it as an oxymoron. Partially, I love security. I've been in this, I guess, industry—it may be better actually described as I’ve been in this discipline of cybersecurity since I was a teenager. I mean, I've always loved all the problems and challenges that we get to solve.
However, how people 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 and their personal computer, et cetera. 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 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 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.
Corey: So, I did something for the first time earlier this year, before these unprecedented times—do you 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've 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 at 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?
Flee: [laughs]. 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 an auditor 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 Threats—some people actually do 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 is 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, force him 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 that 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 again, another area that there's almost 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.
Corey: 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 tier with one user and 100 gigs per month, totally free. Check it out at newrelic.com.
Corey: So, one of the things I saw somewhat recently was a list 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 fix 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 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?
Flee: You and I are cut from the same cloth in that, 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 almost just included in platforms at 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 Macie, for example; it's helping people discover if they have sensitive data that they have in S3 buckets, or 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 that they could actually have the exact same security controls or better security controls in the Cloud. And then 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 [crosstalk]—
Corey: —anyone knows Amazon's complete business model. My product strategy is, “Yes,” So, who could say?
Flee: Yes. [laughs]. I’m not even sure if Amazon knows themselves. I think their business strategy is making money. But there's so many just small, bare minimum things, and I think ultimately it can drive greater adoption. 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 this great, extraordinarily sharp knife, that's there for developers to cut themselves on, make security mistakes—
Corey: And when you get it wrong, it's your fault.
Flee: Yes, yes. [laughs]. And wouldn’t it—
Corey: Haven't you read the shared responsibility model?
Flee: Yes. [laughs]. And it's like, you know, I can have a shared responsibility model also with my five-year-old nephew, but it doesn't really seem to quite equivalent. But we think about some of these other AWS services, you think about things like GuardDuty, 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 move into 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-in 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 Amazon's 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. Do we need a small startup of four or five brilliant little engineers worried about how to configure Amazon’s 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 is a 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. There's so many great things, I think Amazon even has vulnerability scanning was one of their offerings, and there's AWS Inspector—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 also—
Corey: In some cases, you can pay for that particular security service, or staff a team of eight people and save money.
Flee: Yes.
Corey: It's ridiculous on some level. And I would also argue the competitive threat story. If there's yet another S3 bucket leak 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.”
Flee: Yep. Definitely agree with you. And I love one of the analogies and the fact that you also mentioned in a bank at the end. So, previously, we were talking about a small company I used to work for called Bank of America, and this is a podcast, so 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 at up, and it adds up into the decision-making of other executives within those companies.
So, when you think about a CFO or CEO, they may not be following Amazon tech in the same way that we do, as a CSO, or 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 nuance there. And when there's all these stories that are related to compromises, as you said, 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.
Corey: 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.
Flee: 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 OWASP if 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, that helped them also be a little bit more self-service.
But again, today, you're still trading time, so, instead of actually working on those features that you need to work on as a small startup, your 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, and 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 CSOs that got together, like he wrote some guidance to help startups but still requires at 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 with regards to how S3 buckets work now with regards to public versus private, a lot of other things they do on the network side, but I think there's a lot more they can 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.
Corey: 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, “To 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 an 80 percent that takes 20 minutes, and then you can spend a career getting that last 20 percent.
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 DM’ing 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.
Flee: Definitely agree with you. Hopefully, people don't get overwhelmed and believe that 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 want to put in place are very different than if your assets are payroll information, other finance, people's personal details, et cetera. And so, taking time to dive into this kind of this concept of pragmatic risk is really where people have to go. And if you run a business, you're already you’re 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 have to just include, 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.
Corey: 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. Flee, 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?
Flee: 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.
Corey: Excellent. And we will of course put links to that in the [show notes]. Fredrick Lee, better known as Flee, CSO at Gusto. I am Cloud Economist Corey Quinn and this 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.
Announcer: This has been this week’s episode of Screaming in the Cloud. You can also find more Corey at ScreamingintheCloud.com, or wherever fine snark is sold.
This has been a HumblePod production. Stay humble.