Every IPO Needs a CISO Heavybit
In this session from DevGuild: Enterprise Security, CISOs from Atlassian, Segment and Splunk come together to discuss the role of the CISO in developer and enterprise software startups. They share thoughts on topics including when founders should plan to bring in a CISO, what their role at startups pre- and post-IPO is, and how CISOs can increase your growth velocity and total valuation.
- Adrian Ludwig, CISO, Atlassian
- Coleen Coolidge, CISO, Segment
- Joel Fulton, CISO, Splunk
- Joe Ruscio, Heavybit (Moderator)
Joe Ruscio: Thanks, everyone. Real quick intro. Joining me today, like we’ve said, is Coleen. She’s a CISO at Segment, leading up and building their security teams and programs from scratch. Previously she led teams at Twilio, she was part of the team taking that company public, as well as first American Title and CoreLogic.
We have Adrian, who’s been the CISO at Atlassian for about 18 months, roughly. He previously spent time building security teams at Nest, Macromedia, Adobe, Android, and a bunch of places you’ve never heard of.
Then Joel joins us from Splunk, interesting because he’s not only a CISO but a security product at Splunk, amongst other things.
Joel Fulton: Although I, myself, am not a security product.
Joe: Joel is not a security product, yes. Not yet.
Adrian: Yeah, you are.
Joel: I kind of am.
Adrian: A little bit.
Joe: Previously at Semantic, Google, and Starbucks amongst other places. I guess the first thing, I was actually going to kick over to Joel.
Joe: What is a CISO ? How should all these people here– Actually, quick question. How many people here work in a company that has a CISO? One, two. All right, that’s about what I was expecting. Maybe four more than I was expecting. For all the people who don’t yet work at a company with a CISO, what is a CISO and why does Splunk have one?
Joel: Good question. What a CISO is not is an information security manager, but that’s probably where you’ll start. Or maybe you even started with somebody who was the security minded person that was your lead developer that had insights into where customers had problems, or where you had risks with code. Then you grow up a little and you scale up and you have a manager of information security and that person might be more operational focused or they might be more GRC focused.
You heard from Lisa earlier on what GRC is and includes, and then you grow up a little more because you need some feedback, and then once you get that feedback it tells you need to have some incident response handling as Maarten walked through. So, now we’ve got security operations and we’ve got GRC and we’ve got a little bit of incident response. You think yourself, “Holy smokes. We need somebody to take the blame for this.” That’s a CISO.
At that point, you need to affect business outcomes and not just technological vulnerabilities and small, momentary, sporadic issues. That’s when you need a CISO, and that’s what the CISO fulfills regardless of the location.
Those are pretty much the core tenants.
Joe: I like that you mentioned outcomes, because as I think you mentioned shifting from a security person to an executive, and executives own outcomes. I want to follow up with Adrian, just coming down the line here. What kind of outcomes do you own as an executive in a security-minded position? Like, what’s your top three?
Adrian: Sure. I think it’s a mix, and it really depends on the scale of your organization. I think at a certain level, a few hundred people, then your CISO is expected to own technical results. “What is the coverage of our scanning? What is the coverage of our detection network? What are the rates at which we’re closing vulnerabilities? When your organization gets bigger is really when you begin to see a CISO step into the true executive role. At that point, it’s “How do they create an environment of responsibility both within their team, but also across the broader organization where people are familiar with those goals and metrics?” But ultimately the CISO doesn’t own those, they own creating an environment where it’s possible for those to actually be achieved.
Mostly what I spend my time doing, is asking, “How do I build the team? How do I build the environment where there’s a sense of responsibility and accountability for security woven into how we produce our products and how we deliver them to our customers?”
Joe: Coleen, you’re the second straight, first person in, building up from scratch. How do you think about , what’s the right time to start that process? Is it headcount, is it revenue? What’s the right way for founders to think about when they should be tracking towards “That’s when we should put that hire in?”
Coleen Coolidge: Actually, at Segment I was the second person who was caring about security, and then at Twilio I was probably the fourth. I think there’s someone– Lisa could probably give me a better account of when I was, but thinking about “When you bring in somebody at this leadership level?”
It can be a combination of things.
I think you need to really lay out for yourself “Who are your customers? Are they all very risk averse, enterprise type customers? Are there lots of regulations on them and the data that you’re handling for them, and then how many people do you have in your company? How spread out all over the world is your population? How complex is the problem?” I would say the more messy and scary it is, you probably need to bring this person in sooner.
For reference, it could be– If it’s pretty scary, you probably want to try to grab somebody in around 200 people. I don’t know, because then you’re starting to try to close bigger and bigger
deals, and then you’re going to start getting some really uncomfortable questions from your customers that your sales team and the team that you have is just not prepared to answer. It is good to have somebody with not just a security mindset, but is security leadership that the enterprise goes “OK. Thank goodness you’re not just some fly by night operation. The company’s actually thought about this, you’re building a security program, you have a roadmap and you have a narrative. I think your enterprise customers appreciate that, so the answer is “It depends.” But you definitely have to be honest about all of those aspects.
Joe: This probably goes back to being somewhat dependent on how your risk surface area and the kind of data you handle. There are things you can do earlier, I had someone I was talking to earlier in the green room talking about “You can maybe bring in an adviser. If you’re too small for a CISO, maybe you’re like 20 or 30 people, but you know you’re going to get there–” Have you seen that done successfully? Do you work with companies that way?
Joel, what do you think about that? I know we have some companies who have security minded advisers who give people foresight to that.
Joel: It depends upon the alacrity with which the team desire and then apply that. Otherwise, your advice is a short-lived relationship.
Joel: And really, the stage of the company matters a great deal. There’s a company for whom I volunteer, they’re a nonprofit and they do census integration. When I met with them, it’s a small team. It’s 8 people and they want everything. We meet weekly, and they want the list, and they come back and they say “We did these seven things. What about this one?” They are really aggressively soaking this up, so I have to be very careful with what I’m assessing. I need to know more about them so I don’t dominate their strategy inappropriately, but in other cases there are people that ought to be that desirous of an outcome that aren’t. In which case, I wouldn’t choose to advise because then it falls on deaf ears. It’s worse to know what to do and not do it than it is to be honestly ignorant.
Adrian: Worse for whom?
Joel: For the individual.
Joel: For example, if I tell you “Here’s the issues that you’ve got and here’s the concerns.” And you’re like, “You know what? I think we’ve got it covered with this, this and that.” Then you build further on that. If you don’t know and you’re curious, you tend to investigate and understand your risks.
Adrian: I think I would also try to frame it a little bit in what expectations your customers might have relative to the data, and relative to expectations for your organization. The higher those expectations are, the less comfortable I would be with the “I didn’t know I should be securing stuff and so I didn’t look into it,” but yeah, there’s certainly some truth to it.
Joel: Those customers demand it though, too. Don’t they?
Adrian: Yeah, so if you’re getting questions that’s probably a trigger for needing to figure out where to get that advice from and how to answer those questions.
Joe: Adrian, I think you mentioned in the role shaping culture or thinking. As the CISO in that organization, how should you think that– Do you set policies? Do you pick technologies? Do you do some of both? Is there one that you stay away from? I think a lot of people naively go, “The security authorization, they pick the tools and they install them and they run them and then we’re secure.” But what does it actually fall into?
Joel: Yeah, to all of the above. I have seen that it’s particularly effective among security leaders, is that they – – Sure they do all of those things. They create policy and they select technology, et cetera. But more than anything they manipulate the people around them in a very conscious and intentional way, and everybody knows that they want to be secure but nobody wants to spend time thinking about it. So the question is, “How do you get other people to absorb what they need to do into their normal pattern of behavior?” That’s the subtle skill that the most successful senior security folks have. I’ve often pointed out that usually your first one or two or even three security folks, if they’re coming up through the ranks as a technical person, is the person that you least want to talk to about security for any number of reasons. But probably in part because they’re crazy, because what they really care about is security, and that’s scary for an organization that’s trying to grow.
A lot of the function of a good leader in the security space is to be a buffer between the rest of the business and that crazy security person, and make sure that there can be
an intentional, meaningful, valuable conversation. Albeit not necessarily an entirely honest conversation, where that security value is driven into the business and the business is able to continue doing itself.
So, a lot of the work of a senior leader in the security space of a good CISO is “How do you incorporate that and help it facilitate the business as opposed to impede the business?”
Joe: Yeah. Another thing that’s interesting as I was thinking about this role, it started to feel sort of analogous to– Honestly, like a CTO. Where in large organizations, “What does the CTO do?” And it’s like, “They work on internal technology and they work on external technology, they work on sales, they work on–” What do you find calling the split? Because I would imagine there’s– Even just for me with a software product, how do we make sure our software product is secure? Then you’ve got your IT side, where “How do we make sure our internal organization is secure?” Then, “How do we go talk to customers or analysts?” How do you find your–? Do you find yourself playing all those roles?
Coleen: Absolutely. I think that is probably the biggest distinction, is that for somebody who’s a first time CISO, you realize how much of the business that you need to get to know and start to enable. You spend a lot more time with the sales team getting to know customer success, product. And so it’s not just us on one side of the wall telling the rest of the company “You need to fix these things which we’ve clearly outlined for you, why aren’t you doing them?” It’s also tying your company’s success to your success.
What is it that we can do to enable the sales team? You start blending the security program that you have, and then maybe one thing you might do is work with the sales team and “Here’s how to talk about the security that we have, our internal security, and here’s how to talk about the product security. Here’s how customers can use it.” You might start creating documentation, and you may even shop on site with a customer or they may come on site and talk to you. Then I think you mentioned something about a CTO. I haven’t worked in a company in a while that has had a CTO. My impression of it, and I’m totally biased, but I think that’s more of an older model for companies that have been established and been around for a long time. I think a CISO type person would report to the CTO, and that CTO is a member of the executive team. I don’t know that’s necessarily the case nowadays. I know my myself, I report to an ET member who has a title, it’s VP of product development, something like that. It’s not a standard setup anymore.
Joe: Rapid fire. Adrian, who do you report to?
Joe: CTO? Old school, OK. Just according to Coleen.
Adrian: But he has two thirds of our org, so he has all of product and all of engineering.
Joe: Then Joel, who do you report to?
Joe: The CTO? OK.
Joel: Yeah, he’s an Earl actually. So it is very old school.
Coleen: Really? An Earl?
Joel: No, that’s not true.
Joe: “The Earl of Splunk,” yes.
Adrian: Is his name at least “Earl?” Come on, work with us here.
Joel: I like “The Earl of Splunk.” That’s pretty good.
Joe: It’s actually interesting that you say that, because it’s one thing I want to spend a little bit of time talking about. I just as I dug in, I just got even more confused because I was like “We’re going to talk about DevSecOps,” and then immediately someone is like, “You mean SecDevOps, right?” And it’s like “Whoa, OK.” Before we will get there, but I am curious. We are seeing maybe just saying “Shifting left.” Historically, security was the last part of the waterfall to come over. Because developers, they’re like “We want to ship code faster, so we’ll buy into this” And ops code is like “We want developers to sign up for responsibility, and they were like “But we can both agree nobody wants to talk to security, so leave them over there.”
Adrian: You all can see why now.
Joe: Yeah, in legacy models. But now that we’re seeing things like– We work with companies like Snyk, that are doing dependency scanning almost like a CI process where there’s rasped runtime applications and self-protection stuff, like signal sciences or screen or something. That’s getting more embedded. Are you seeing Joel, are you seeing that shift towards “Let’s make this less of a one off thing that’s a gate keeper, to we’re part of the team now and working tightly with DevOps and the whole rest of IT?”
Joel: I think that DevSecOps, SecDevOps, OpsDevSec, whichever way you put them in. It’s a descriptor, it’s not prescriptive. You can read the Phoenix project, you can try to align to something that models that, but you’ve still got the main problem that is most security teams are the department of “No.” Or you’ve got a reputation you didn’t earn or are working hard not to have that you’re the department of “No.” Maybe you’re the department of “Yes, if–” So you’re typically a waterfall structure surrounding the Agile, because it’s the same thing with IT Ops and the same thing with cloud.
They just want to get it done, and all you want to do is stop them from their perspective. The more that we beg the question, there is such thing as being secure. I don’t believe that’s true. I believe that there is managing our risk, seeing all of our risk, and understanding which risk we ought to manage and in what manner. That works really well integrating into the DevOps environment.
Adrian: I’m still overwhelmed by Coleen’s enumeration of all the different parts of the company I’m supposed to be familiar with.
Joel: I know, it’s depressing.
Coleen: I know. It’s not an easy job, but yeah.
Adrian: And now I’m supposed to be doing that in real time as well?
Joel: I don’t like people.
Adrian: Every single developer could potentially be shipping code?
Joel: That’s ridiculous.
Coleen: I have a comment on the “Shifting left,” and I think it just makes your entire security org’s job easier if you can shift left. Specifically what that would mean is if your security team is going after folks and saying, “We just scanned all the containers and there’s like 19,000 highs, oh my God.” So instead of figuring out how to create 19,000 tickets and then send them to the teams and have them do it, “Why can’t we create scratch containers? How do we make things so that they are secure and easy by default, and then replace what people are using with the secure and easy by default stuff?”
Same thing with “Why not use golden AMIs?” I just feel like if you have a team that’s technical enough, which I hope you will, if you’re building a security team then they can figure out how everyone does their work. They can get into that pipeline and they can insert all of the stuff that they won’t want in there, so by the time things come out of the end of the pipeline and you scan or you inspect it, there will still be problems but it’s not an overwhelming set of problems. I remember when I worked at CoreLogic many years ago and we had a physical data center, and we had to actually do patching. It was awful. We would scan, we’d find this multi page report, and we’re like “OK. That means we’re going to have to do patching 10 PM Saturday night, and that’s our maintenance window.” Some of the patches wouldn’t go well.
First we had to do testing and then sometimes it wouldn’t go well, machines wouldn’t come back up again, and it was just so bad. That’s what happens when you’re at the very end of it, so you can spare your team a lot of headache by just moving all of that stuff to the first few things that people are doing.
Adrian: Just to just to jump on the “Shift left,” I think probably the single most important thing you can do if you’re building a company at whatever scale it is, is to have yourself as an executive that’s not in security. Ask whomever, it could be your sales guy or it could be your product guy, it could be your developer girl or whatever. What are you doing about security? As soon as a CEO asks that, or as soon as the head of product asks that, you’ll realize that the engineer or whatever other function it is can go back and think about it.
They’re probably going to come up with an answer that’s better at what they’re doing than a security team being asked to answer that question. It’ll also give you an indication that your executive, or whoever is in charge of getting this thing out the door, cares about it. That’s how it becomes incorporated into the review process. Ask your architect, “What are you doing about security?” Then ask your developer, “How are you thinking about security in the context of your development process?” Then ask your testing team, “How are you testing for security?” You don’t need to know whether it’s a good answer, they will give you a good answer when they began looking into it.
When you get to a point where each one of them has answered that, you’ve now got a development process that’s more secure than any development process that’s going to be built by a security team that comes in later. It’s as simple as just asking those people to care about it, think about it and do something to demonstrate that.
Then after the fact, you can hire a CISO who realizes that they’ve got a pretty cushy job.
Joe: Are you finding–? Naively, I want to believe that in a post-GDPR world and with all these high profile breaches like Experian or Starwood, that at some level if a developer or operator or SRE has been paying any amount of attention they start to get a little bit more than maybe 4-5 years ago. Like, “OK. I probably should care about– I’m going to have a bad time if the site’s going down, if we’re up on the top of CNBC with millions of records breached that’s not going to be a good day for me.” Are you finding that people are caring more about that? Because I would think that it would make them more receptive to, again, your questions . Like, “You should care about security.”
Adrian: It’s absolutely the case that this year or last year compared to five years ago, the board is asking, “What are you doing?” The CEOs are asking, “What are you doing?” The problem in that question is it’s “What are you doing,” aimed at the CISO or aimed at other people, as opposed to “What are they doing?” One of the things I’ve been extraordinarily lucky in several of the companies that I’ve been at, inclusive of the one that I’m at right now, where the founders and the CTO– Because we still have one, even though we’re old school. They have said “Security is really important,” and they give me headcount. I don’t have to go and say “I need more people.” They’re like, “We’re thinking you’re going to need this many.” I’m like, “That’s twice as many as I was going to ask for. Sweet.” That understanding of the expectation being that it should be a push. Like, “Security is really important. We’re going to do everything we can,” simplifies getting it into the overall organization by a huge amount. Then it becomes just incumbent on me to do the right thing with the resources that I’ve been provided.
Joel: So, Adrian. You’ve presented two sides, and I agree with both sides and I know you reconcile them. I’d like you to reconcile them out loud for the folks, and that is this. Previously it’s a — And I’m summarizing: Security is everybody’s responsibility. Ask the developer what they’re doing. Develop that culture, elicit from them their active participation in securing your environment. Then there’s a centralization pushing security as a center of excellence. Again, my words not yours. I see a “Both and” there, not mutually exclusive. What do you see? How is it working for you?
Adrian: Absolutely. No, I think that’s exactly right. I think the ideal function of the CISO is to make sure that what’s going on in the organization is best of breed, but they aren’t going to be capable of actually doing it all. So that’s really the function, is to make sure you have good people that provide a counterbalance and a continuous ongoing assistance to the broader organization. But getting the broader organization to actually be secure is not something the security team can do. Like, I just don’t believe that. I do believe it’s pretty easy for a CISO or a CTO, or whatever, in their quarterly meeting to just mention it. It’s coming from the mouths of babes, right? It’s coming from that leader. It’s not the security person asking for it, so that means it’ll get done.
Joe: Yeah. This is why you tell new CEOs “You’re not allowed to ask your team any question unless you want the answer for real,” because even you say “I’m just curious,” it will be interpreted and followed out, so I think that’s smart. Thought on that, one of the ways with DevOps and going back 10 years ago, the high level test, stress test of your DevOps team was “Do you have a NOC? Because DevOps is killing the NOC.” What about calling the SOC? Is that still a thing, or is that something that’s important?
Coleen: Here’s my bias showing again, because I choose to work for smaller companies where we’re like “OK. What can we dispense with that we don’t need to invest in anymore?” And the answer is, “It depends.” If you’re a very small company and you have limited resources and you find that you need a SOC, there are services that you can employ that will provide that for you. But again, if you are very developer-heavy and so is the security team that you’re building out, they can provide a huge amount of automation.
The future of this is if you imagine a SOC right now, maybe it’s 25 people on one shift. There’s dashboards all up there, maybe they have windows that smoke over and it’s pretty cool. Each of these people are employed with run books, so there are different teams in the company that say “When this alarm happens, I want you to take the following actions. “Push these buttons, run this script, do this thing.” If you are very technology -focused and you look at that, you’re like “Why is it that there are humans who are doing this? Isn’t the best and highest use of humans figuring out how to automate these tier 1 and tier 2 types of problems?”
If it’s something that’s repetitive, if it’s something that requires them to act quickly and then act consistently, have people automate that part of the job away.
I would say that rather than have a SOC long term, then you have cert folks who are probably at tier 3 or tier 4, and they spend most of their time hunting.
Imagine all the basic stuff is taken care of. An alarm comes in, looks like so-and-so is logging in from Japan and that’s really weird because they don’t normally log in from Japan. Slack message goes to that person, “Is this you?” “Yes, it’s me.” That kind of stuff can be just automated away, but then take those same people who would be just pushing buttons and sending those messages and have them understand if it’s AWS or GCP, what that environment looks like. “What does baseline normal look like in that environment? What starts to look really weird? Pay attention to danger signs on your app. Are people abusing your app? Are people inside the company doing something they’re not supposed to?” Spend the time instead of pushing buttons, having those people threat hunting and then figuring out the bigger juicier attacks, and then later they get to a point where “Is a nation state attacking me?” That’s how you would want to use human time, and you want to use robots to do the tier 1 and 2 stuff. But that’s just my–
Joe: It’s more like threat analysts in that kind of capability.
Joe: Did you have–? Joel, I wasn’t sure if you had something else to say.
Joel: We also sell robots.
Joe: OK. Speaking of hiring, this is something I want to dig into. You mentioned, and it’s good to hear that the investment is not just in “Here’s your title and your mandate, go convince the rest of the team to be secure.” But actually building out people. Joel, these days what kind of people are you hiring into your organization? If I think, again, kind of naively and historically it’s like “We’ll hire some pen testers and they’ll poke at the app .” What kind of things are you hiring in-house versus automating, vs. maybe outsourcing to consultancies or places like Hacker One, or whatever?
Joel: I want to start the answer backwards, which is — We talked about this earlier. What’s the outcome that I’m after? The question about the SOC, “What’s the outcome that you’re after? Why is there all this interest in traceability if the NOC is gone? What’s the outcome that I’m after? I’m after fault investigation, I’m after disparate analysis. Who’s doing that, the developer? No, not ever. So who’s doing it?” What’s the outcome that we’re really after in this process?
When it comes to hiring, the tech is relatively easy. It’s a tool you can put in somebody’s hand often, and my personal belief– Which is more of a belief than a fact is that products wound employees. The more products I purchase, the more I limit the capability of my team. World War 1, we learned that if you shot to wound, you take out three of the enemy soldiers because it took two to carry the wounded, crying, screaming person off the battlefield. If you shoot to kill then you only take one out. If I bring out CrowdStrike, if I bring out carbon black, if I bring out Tanium you all have one of those probably. Now I’ve taken somebody who’s a security analyst and I’ve made them a product specialist, and their world and their advancement or their career tends to be captured by that product.
Splunk’s got the same problem, you become a ninja or you become a captain. You stop being a data analyst or risk manager in large part, and start being a tool professional.
When we hire, we don’t hire people that are good at tools. We hire people that are good at being adaptable, they’re being agile, they know how to set their own goals and they know what the business goals are.
My best SOC manager, we still have– Anyway, he came from the Peace Corps where for three years he did water reclamation in Africa. He didn’t know anything about security, but he knew crisis and he knew managing disparate people across multiple time zones, and he knew how to think long and work into it. So, what’s the goal? What are the core components of that goal? And then to me, the tools are the very bottom thing typically.
Joe: Yeah. That makes sense. It’s always part of these movements that always emphasize people and culture over tools. The tools are just the side effect of the people in the culture.
Joel: ?They’re supposed to be, tools dominate.
Joe: This is true.
Joe: It is an interesting question, I know we have a lot of people and a lot of founders in the audience building very early stage companies who are looking to build tools and sell product solutions and tools.
Adrian: They won’t wound you, they’ll fix you.
Joe: So, how are these vendors–? What’s the right way to think about this? Because I think everybody understands intuitively when they corner you somewhere and give you a cold pitch, that doesn’t work. So what does work?
Joel: It could, it could work. But you love your tool because you spent so much time with it, and it’s beautiful to you and it’s elegant, and you solved a hard problem with elegance and panache. I can’t wait for you to see this. He’s thinking, “Holy smokes, dude. I got a board meeting tomorrow and I got to go through my PowerPoint tonight, and I got to figure out that it does– What does it do?”.
Adrian: And, “You touched me.”
Joel: I’m going to do it again.
Adrian: But really, like you reached out and you got into my space. No, not in this instance. But that’s the problem, is that somebody is getting in there to talk about their thing.
Joel: Keep going, keep going. Or, Coleen–?
Joe: What is– Adrian, what is the right vector though? What’s the ideal, if someone’s thinking about getting in front, is it figuring out exactly what your initiatives are for that year?
Adrian: Marketing 101 is “Try to understand the problem, try to describe the problem, and then just end the conversation.” Really. If that’s your problem, then let’s talk more and then see whether it is engaged with how it’s explained, how it comes back at you. Go from there,”Yeah. We have a solution in that space, but I really want to understand and make sure that I know what it is that you’re dealing with and how you’re approaching and how you’re thinking about it.” That is a more meaningful type of conversation to have, and it’s the one that certainly is a good introduction . It shows that you actually care a little bit, which is nice.
Coleen: It’s also how you create champions with your customers. Because if you just show up and you’re like, “I have this thing that’s all wrapped up and I need you to buy it, ” and then you try to fit their situation to the solution that you already have it can come across a bit tone-deaf. I think that security leaders are a little bit cynical when it comes to what we say, like “We don’t want any more snake oil. We bought plenty of those in the course of our career,” and I think it’s better to think about approaching a security leader and seeing how you could partner with him or her for the next 5-10 years of their career. What is it that’s keeping them up at night? What have they not been able to solve? And can you articulate it with them even if you don’t have anything to sell to them today? Just listening to “What is that thing that’s still a blind spot for you?”
Joel: That’s really good.
Coleen: That can give you some really good insight on what it is you could build.
Joe: Switching gears a bit, or at least semi-related. We’re about 18 months into a post-GDPR world. I know at one of the last gigs things I did as an operator was help with the global GDPR rollout. Tens upon tens of executives involved across a bunch of business units. I’m just amazed at how much went into it, so how do you feel now that it’s come and gone and we’re into it? What was the biggest surprise or non-surprise about the whole thing?
Joel: It’s not gone, it’s just now real.
Joe: From an engineer’s–
Joel: “It’s gone? I’ve got to call some people.”
Joe: I was in an engineering leadership position, so once we shifted it was done.
Joel: That’s right. That’s called DevOps.
Joe: Yes. DevOps, right.
Joel: So we’ve gone through this a hundred times. Am I exaggerating? I don’t think I am.
Adrian: I’m not sure what “This” is.
Joel: We had BITS and we had HIPAA and we had high tech, and we had Massachusetts’ 201-CMR17, which was a personal identification–
Joe: The stock is in there somewhere.
Adrian: The Y2K problem.
Joel: Y2K , right? But we had these regulatory requirements that came with a penalty that was amorphous, and it would be “We will determine it later.” Then the regulatory requirements themselves are subjective. You need to execute reasonable due care to protect customer information, unless they’ve committed fraud, unless they’re likely to have, unless you need it for other reasons, or unless– What do I do with this? So it’s following the same pattern as some of these others.
Adrian: The way I would frame it is historically, both security and privacy have been areas where the core question is “Are you meeting an unstated expectation that’s been set by a customer where every one of your customers has a different set of unstated expectations?”
Joel: Did you work at Google?
Joel: All right.
Adrian: We had a few customers, they’ll tell you their expectations after the fact. The other thing that you learned, so it’s kind of nice, actually, to have some basis for minimum bar to involve in the conversation. Then the other thing that was nice is historically there’s not a really good grounding in law about what security means. For a long time, I was able to pretty convincingly argue no matter what we did, “We weren’t going to get sued because nobody’s ever been sued for not having patches, for not having–”
Now it’s beginning to change, but 10 years ago especially if you were in the package software business, there was no responsibility whatsoever to build a secure product. You had to claw your way into being able to make those arguments in a meaningful way, and then you had to begin to intuit out of a customer what their expectations were.
So GDPR at least puts a baseline on if you have customer data, there are some fundamental things that you need to do that simplifies the conversation, so I think that has helped a lot. I actually think all of the tenets that are in there are pretty straightforward and pretty consistent with what you would expect, they’re just not what was necessarily in products that have been built previously.
Joe: Right. I think what fascinated me, part of going through the process was how little– There’s not, I used to say to my team “There’s not some j-unit tests we can run that go green when we’re GDPR compliant. The whole thing is actually one giant internal negotiation between us and general counsel. Because general counsel at the end of the day is the one who’s going to sign up and say, ‘I’m willing to go defend this.'”
Joel: That’s right.
Joe: Do you find yourself, Coleen–? Does Segment have a GC at this point?
Coleen: We do.
Joe: Is there more of a FinSecOpsDev there to work with? Do you see a lot, or do you have a close relationship with them?
Coleen: What was the word you used?
Joe: We’re just going to keep adding
Coleen: We are pretty close with the GC, and it’s a relatively small legal team, but going back to your earlier point every couple of years there’s a new thing. Coming January 1st there’s–
Joe: We have 2 months, right?
Coleen: CCPA, so I think we should never get to the point where we’re like, “Compliance and privacy? Solved.” There’s no “Solved,” I think just really rebooting what you have and saying, “OK. All of these things have a ton of things in common. Based on this, are we doing these things? Is this how we’re setup? And if we’re not, then make those permanent changes.” Because then the next time something comes in you’re not going to be knocked sideways and you’re not going to panic. There might be some small changes that you need to make, but I’m betting if you as a company handle GDPR well, then you are set up very well to handle CCPA and then probably what other state is going to come up with their own privacy law. You’ll be set up well to handle that as well, and then when we at a federal level pass our own thing and it’s our own GDPR, then you’ll be set up well.
I would just encourage you to take a look at your practices, compare against each of the tenets within like the different articles. For example, one great thing would be data minimization. If your organization collects data on either your own employees or on your customers, always having a mechanism to understand “What am I collecting? Do I need to collect it? Is this personal data? Do I need to keep all of it? How quickly can I get rid of it?” And then, “Am I very transparent about this collection and how I handle it with my customers?” And just going through a cleaning cycle all of the time, and you want you want to look at data as radioactive. Which means you don’t want to hold onto a whole bunch of it for a really long time because it’s going to hurt you. Eventually, you’re going to die from it.
Adrian: One thing I would flag that I think is implicit in what Coleen was just saying is that it’s not a matter of looking at GDPR and enumerating it and then comparing against it, and then CCPing and enumerating and comparing against it.
The right approach, if I can be so bold as to say “The right approach ” is to look at the thing you’re building and define its properties relative to general principles that you find in some of those pieces of legislation, and then compare those general principles which you’re going to hold very firm to the pieces of legislation. Over time you’ll see, “When I do an ISO certification, it’s a little bit different from a SOC 2, but it’s tiny.” As opposed to a standard compliance approach. “I’m going to do this certification and make sure I hit these 100 things, and then I’m going to do another certification and I’m going to do these 100 things,” and it feels really overwhelming. But the reality is all of these rules, all of these different compliance regimes, are like 98 % the same.
If you define your model for your product from a security standpoint, from a privacy standpoint, it’s pretty easy to then see whether you need to tweak your model and then just constantly reinforce application of your model under your engineering team or your DevOps team, as opposed to pointing them to the piece of legislation.
So that’s where GDPR overwhelmed a lot of people, because we suddenly were talking to legal over and over and over again as opposed to talking to, I don’t know, the product security architect or privacy architect who should have thought about this already and incorporated those principles into their design. Now a lot of people didn’t have that, so it was necessary, but you don’t want to be constantly going back and having a negotiation with your general counsel about how you’re going to comply, or with your compliance person.
Joel: That’s totally a life hack. If you do that, you will spare yourself hours of drinking, regrettably. Check out the Security4Startups thing, the core of that. The differences you find between PCI and ISO and Fed Ramp and SOC 2, “Yeah. I store logs for 7 days, I store logs for three days. My password is 7 characters long, my password is fifteen.” All right, so what’s my highest common denominator that if I do this as my principal now all my dominoes fall?” Pick it and know it, and it’s really– You will pay a lot of money to do this six times, or you could pay no money to do it once. I’m really not exaggerating. That’s really a good tip, Adrian.
Adrian: The same thing is true with answering questionnaires from customers. If you can’t proactively answer on your own paper the first 50 questions on every one of those questionnaires, you’re doing it wrong. Because what you want to do is say is “Cool questionnaire. Here’s my answers, come back and let me know which things I missed.”
Adrian: That’ll save you a ton of time.
Coleen: But I think that you’re at larger companies–
Adrian: They’ll still ask you. They’ll still come back to you. You can’t make them–
Coleen: OK. Yeah, we still have to fill it out even if we already have all the answers. That might be the difference between a large and small company.
Joe: All right.
Coleen: You still have to do it.
Joe: I want to thank– Everybody can join me in thanking, what a great panel we’ve had to end out the day here. We’re out of time.