https://cisoseries.com/no-need-for-chaos-engineering-since-our-architecture-is-always-failing/
This week’s episode is hosted by David Spark (@dspark), producer of CISO Series and Andy Ellis (@csoandy), operating partner, YL Ventures. Our sponsored guest is Mike Wiacek, CEO, Stairwell.
Full transcript
[Voiceover] What I love about cybersecurity. Go!
[Mike Wiacek] I love the game, that cybersecurity is almost adversarial by design. Whatever we do as defenders to try and protect systems that we’re responsible for, bad guys are always trying to adapt and evolve, and then that forces us to do that. So, some people think it’s like the eternal cat-and-mouse game, but there’s something great about watching the coyote try and chase the roadrunner. It just keeps going and gets more and more fun as time goes on.
[Voiceover] It’s time to begin the CISO Series Podcast.
[David Spark] Welcome to the CISO Series Podcast. My name is David Spark, I am the producer of said CISO Series. And joining me for this very episode as my co-host, you know him very well, his name is Andy Ellis. He’s the operating partner of YL Ventures and he’s going to be speaking at RSA, which is in just a few weeks from right now. Andy, let everyone know what the sound of your voice sounds like.
[Andy Ellis] It sounds like this and I’m eating lots of leavened bread right now because in 24 hours, Pesach starts.
[David Spark] What’s your favorite starch to consume?
[Andy Ellis] During… Well, matzah, of course, during Passover.
[David Spark] No, no, no. Before, before. Your favorite starch before and to break the fast.
[Andy Ellis] I will admit a Quarter Pounder, no cheese, at McDonald’s.
[David Spark] That’s your favorite?
[Andy Ellis] Ah!
[David Spark] Not like a bagel or a slice of pizza?
[Andy Ellis] No, I love that. That’s my lunch before we hit Pesach. Then the day before, we do spaetzle with chicken paprikash over it, fantastic! My wife is a amazing chemist, has an egg-free spaetzle recipe.
[David Spark] Our audience is very excited about that. Hey! Our audience can go to CISOseries.com and find all of our programming over there. And I do want to mention our sponsor for today’s episode and that is Stairwell. Eliminate the blind spots with Stairwell. They’re available at stairwell.com and we’re going to hear more about how exactly they do that a little bit later in the show. But first, I do want to mention RSA. We’re actually going to be doing… We’re recording this in late February but in just a few weeks, we’re going to be doing a special Super Cyber Friday talking about hacking RSA. And Andy, outside of the classic tips of, “Oh, drink a lot of water, take breaks, have comfortable shoes,” what’s your tip or tips for being super successful at RSA? And for anybody, whether you’re a practitioner or a vendor.
[Andy Ellis] Figure out where you’re going to eat and take people there because here’s the deal – within a half-mile radius of RSA, you’re going to wait like 30 minutes to get a table if you’re going at a normal lunchtime. So, you might as well take that 30 minutes, walk a little further or grab a lift and go somewhere and have a nice spot that you’re going to sit at and enjoy it. Because it used to be that you could go to all the cool little places right around Moscone. They’re all booked out now, so you’ve got to go further away.
[David Spark] And I agree 100% on that and I’ll tell you – the big, huge mistake I made last year is because everyone’s sort of offering free food at their events but it’s just table garbage that’s everywhere. And I don’t think I had – for like four days straight – I don’t think I had a single sit-down meal. I was quickly grabbing something and running and I felt awful as a result of it.
[Andy Ellis] Yeah. Put meals on your calendar and go. It used to be you could just walk up to Samovar, that was like the hidden gem, but now it’s booked out for events. So, go somewhere north of Market Street, that’s usually a safe place to go.
[David Spark] Yes. North of Market Street you will be safe.
[Andy Ellis] It’s only like two blocks from Moscone, but nobody does events on the other side of Market.
[David Spark] Yeah. If you really want adventure, go all the way to Chinatown.
[Andy Ellis] Yeah, but that’s a little long for lunch.
[David Spark] That’s long, well, take your car.
[Andy Ellis] But how about we do dinner there on like Saturday?
[David Spark] We are going to do dinner.
[Crosstalk 00:04:07]
[David Spark] We are. We’re going to do dinner. All right. Let’s bring in our guest. I’m thrilled to have him on. We had him on this show before when he was running another company that’s called Chronicle that got sold to Google. And now, he’s back again with the plans to do the same pattern, I don’t know, we’ll find out [Laughter] from him. He’ll let us know.
[Andy Ellis] Well, clearly, coming here gets him sold to Google.
[David Spark] That’s it, that’s it. And also, I do want to mention that when we did this before, his company Chronicle was the darling of RSA that year. So, I’m assuming because this is going to air just before RSA that Stairwell will become the darling of RSA again. This is my theory. Mark my word. If it happens, I get full credit, Mike, right? You get no credit; I get all the credit.
[Mike Wiacek] David, Andy, it’s great to be here. The timing is actually really coincidental because when I was on the show with Chronicle, it was right before RSA as well.
[David Spark] Yes.
[Mike Wiacek] And now here we are again…
[Andy Ellis] Well played.
[Mike Wiacek] …following a very similar pattern. [Laughter]
[David Spark] I haven’t given you a proper intro yet, Mike. Let me introduce you. It’s Mike Wiacek, he’s the CEO of Stairwell. Great to have you back again, Mike.
[Mike Wiacek] Great to be here.
Are we making the situation better or worse?
5:14.144
[David Spark] Is chaos engineering the secret sauce to creating a resilient organization? Now, Netflix built Chaos Monkey, an engineering tool that would purposefully disrupt its architecture allowing for early discovery of weak points. And Aaron Rinehart, an author of a book on chaos engineering, said in an article on TechTarget by Kyle Johnson, “We don’t know we need to adapt because the software itself doesn’t inform security about an issue until security knows there’s a problem. That is not a good way to approach engineering security.” So, chaos engineering refers mostly to software development, but can we take it even further to company environment, beyond even a tabletop exercise? How far can we go testing our limits while still allowing the business to operate? I ask you, Andy.
[Andy Ellis] So, chaos engineering, at least the way Netflix engineered it, was really sort of set up as, “Let’s just turn things off to make sure that resilience still works.” And you have to be really careful when you try to apply that to security systems. Like you don’t want to just go and deliberately turn off systems in a way that’s sort of deprovisioning them. Now, it’s fine if you’re like, “Oh, what happens if I turn off my IDS?” Like, if it crashes, it’s just another system. Or if it’s my log distribution system, “Oh, if I turn off a couple key components…” But what you shouldn’t do is go in and say, “Oh, what happens if I turn off authentication in SSH or…?”
So, this isn’t about altering configurations, which I have seen people suggest. It’s really about what happens when natural chaos hits your system, machines fail for whatever reason, do you detect it? Do you notice it? How does it affect your security systems? Does it give adversaries a way in? And that’s actually the thing you need to do when you’re doing chaos engineering, is really pair that up with penetration testing. Because if a vulnerability just appeared, if you don’t have somebody to exploit it you’re not going to know.
[David Spark] That’s a good point, and that answers my question of how far can we go. Certain things, you just can’t go that far. Mike, what say you? How far can we go on chaos engineering? Like what can we sort of mess up to test the boundaries of our resilience?
[Mike Wiacek] There’s actually a cool engineering solution you can probably tackle with some of this stuff. So, for example, would be getting technical like PAM modules on Linux. If they configure them wrong, you can end up with weird back doors in the systems by accident. And so the question is how can you maybe probe for those? What if you have an admin messing with the PAM modules on a Linux box and they put things in the wrong order or something like that? So, maybe there are concepts that you can borrow from DevOps where they have stuff like probers which try and connect to a service, just to make sure it’s online and it’s rendering your home page correctly. What if you had a prober that tried to SSH into servers with different configurations or incorrect passwords, just to prove that they fail? Bringing some of that DevOps-style production monitoring into security could allow you to detect when things get misconfigured faster. Because otherwise, you’re probably going to be notified when you start realizing someone’s mining bitcoin on some server that was misconfigured weeks ago.
[David Spark] That’s an extremely good point about bubbling up DevOps to security rather than, as they say with DevSecOps, sticking security in the middle of DevOps. Andy?
[Andy Ellis] Oh, absolutely. I think security has a lot to learn from operational practices, whether it’s traditional Ops or DevOps. And I’m a huge fan of, “If you believe things to be true, are you checking that they are true?” So, if you have a set of configuration files that tell you what all the services ought to be on all of your machines, well, are you scanning to see if there are other services that are showing up? Now, sometimes that might be somebody’s running a crypto miner, or they’ve turned on IRC for some reason. Sometimes it might be there’s a backup service that when one system fails, another thing stands up.
In the early days of Akamai, I discovered a fascinating thing we had. It was this beautiful tool. When we told the machine that it needed to reboot itself, or not reboot entirely but just the application server, you’d suspend it to get traffic to wander away. But there was a way to redirect the traffic to another machine and you could basically leave up this very simple redirector. Well, that redirector listened on a second port that wasn’t registered at the time. Like, we didn’t have it. And so we discovered it. We’re chasing it down and we thought somebody had installed something crazy.
And then we find out – no, no, no. It’s our own redirector but it’s ephemeral, it only runs at this one key point. When you’re about to install a new application server, it basically sends the traffic to another machine and then it turns itself off. And we had to be monitoring to find that. Now, we weren’t monitoring, we found it accidentally, but it helped really drive home the point of you’ve got to be watching what’s going on to detect what happens when chaos strikes. Because I think that’s actually the biggest challenge behind chaos engineering. Most people are like, “Oh, Chaos Monkey, this is great,” and the answer really is, “Well, what are you doing to notice chaos in your system?”
Well that didn’t work out the way we expected.
10:47.744
[David Spark] One of the complaints that I’ve heard about deception devices is that they end up having the same fingerprint which allows malicious hackers to easily identify and sidestep them. Couldn’t this also be said of popular security tools or just platforms in general? When something becomes popular or commonplace, then the hackers focus their effort to learning to break that certain tool, architecture, environment. That’s why we have way more vulnerabilities in a Windows environment than I would say in a Linux environment. So, if we all have the same security stack – which we don’t, but the big security vendors that offer multiple services sure wish you would – wouldn’t that actually help the attackers? Doesn’t homogeneity help attackers? Mike.
[Mike Wiacek] So, this is something that was fresh on the top of my mind as we started Stairwell, was fundamentally that as you look as time’s gone on, organizations, security stacks may be built from bricks from different vendors, but they still build a wall that looks relatively the same. And regardless of what the bricks are, people still try and just hop over it. So, there is homogeneity there. And I think, if I’m going to put on my technical security hat, I kind of personally blame sometimes a little bit of the compliance-driven security as a factor in this. It forces homogeneity because human nature is such that when you tell people, “You must do A, B, C things,” they very rarely do D, E, and F because the assumption is, “If this is what I have to do, that’s necessary and sufficient.” And what you realize is the homogeneity aspect, it’s necessary, it’s good to have basic practices and hygiene in there. The question is how far beyond that do you actually go? And that’s where a lot of organizations who are not too forward thinking, they follow what I tend to think about just like GRC checklist security.
[David Spark] Andy, first let me just ask do you think this is a real problem – being homogeneous?
[Andy Ellis] So, it’s a different problem than where you started which is around the challenge of deception devices.
[David Spark] I used that as an example because that’s a complaint a lot of people have said.
[Andy Ellis] It is, and it’s a fair complaint that doesn’t translate in this way.
[David Spark] Okay.
[Andy Ellis] The reason it’s a fair complaint is because deception devices generally are not well developed, and so they’re easy to detect because they don’t look like real devices. In the same way that, for a defender, many adversaries don’t look like real users, so they’re easy to identify. Like somebody shows up with a botnet that is doing something that none of your users do. Oh, easy to profile and block. Right? The real arms race between security in adversaries and defenders is trying to look more legitimate with every single step. And so there is a benefit towards gravitating to the best-developed location because you’re going to look more and more legitimate there. Like, does my web server look better if it’s NGINX – which sure, has some vulnerabilities – or if it’s Apache 1 that nobody’s maintaining anymore? But hey, nobody’s using Apache 1. Like, I want to be on NGINX, I don’t want to be on Apache version 1.
And so that’s what we have to look at is is the platform itself robust and do we know what the weaknesses are as defenders. The challenge isn’t like, “Oh, you’re homogeneous, like we all have the same WAF.” It’s that WAF bypass is an art and if you don’t understand how your WAF is being bypassed and working around it… Because every WAF has bypass. There is no WAF that is immune to bypass attacks. They’re just a little bit different and I think most defenders are complacent and they don’t realize that’s a problem.
[David Spark] Mike, you’re nodding your head.
[Mike Wiacek] Yep. I totally agree with what Andy’s saying there.
[Andy Ellis] Music to my ears.
[Mike Wiacek] [Laughter]
[David Spark] Anything to add…
[Crosstalk 00:14:49]
[Mike Wiacek] No, I mean, again, I think it kind of falls back to the notion of necessary but not necessarily sufficient. If you’re going to have a WAF in place to help filter, block, detect malicious activity, you still need to drive it, you still need to basically make sure that you are looking at what it sees if you see it blocking activity and you see someone actively manipulating it to try and bypass. How do you know when that’s happening? How do you get in there and how do you tune that? How do you actually take the indications you have and use that to stay a step ahead?
Sponsor – Stairwell
15:24.745
[David Spark] Mike, I have a quick question before we go on any further. Are you hiring over at Stairwell? And why would someone desperately want to work with Stairwell?
[Mike Wiacek] We are hiring at Stairwell, and I think one of the most awesome things that you have with being at a well-financed cybersecurity startup is agility and ability to make something net new. It’s no secret that I think a lot of promising security companies end up being acquired before they actually reach escape velocity. So, you have like Crowdstrike, [Inaudible 00:16:04] have managed to make it out into cybersecurity orbit and become their own celestial bodies. But then if you look at others, they become features of other amalgamations of products. And the chance to actually work at an organization that is focused on creating something net new – very powerful. And work with people who come from top tier companies, brilliant engineers from fields of distributed systems, machine learning, and bring all that into something where we’re able to give enterprises a net new security capability is really exciting and it’s game changing.
[David Spark] And that’s exactly what I wanted to talk about. I want to actually explain Stairwell to those of you listening, and we’re going to get more into this a little bit later in the show, but as I mentioned Mike, he is a repeat guest on this show. Stairwell’s a brand-new customer but Mike is a regular, for that matter. He is the one who founded Stairwell and he’s former founder of Google’s Tag and Chronicle, as I earlier mentioned. Now, Stairwell helps you stay ahead of attackers. Stairs, steps, get it? Very clever, anyways.
So, Stairwell starts with the premise that the cybersecurity blueprint doesn’t work because attackers know the defenses as well as – if not better than – you do. That’s not good. So, the very security blueprint that is supposed to protect an organization is actually a roadmap on how to evade those defenses. Stairwell took the approach of saying, “Look. How do you keep an organization’s defenses out of sight, outside of time, and out of band from the attackers?”
The answer is the industry’s first continuous intelligence, detection, and response platform. The Inception platform that Stairwell has built automatically uploads every file to a dedicated cloud environment and continuously analyzes every file looking for malware, vulnerabilities, low prevalence files, and more that you don’t even know to look for, including things that snuck past your EDR. So, this gives you better detections, confidence in response, and reduces the costs related to protecting against and responding to cyberattacks. You want to learn more? You’ve just got to go to their site, and it’s pretty easy to find. Go to stairwell.com to learn more.
It’s time to play “What’s Worse?”
18:30.553
[David Spark] All right. Mike, I know you know how to play this because you were on the show before, you’ve played before. Andy will be answering this one first. And then if you disagree with Andy, I win. If you agree with Andy, he wins. So, no pressure there, just who do you want to make happy here. All right. This one comes from Dustin Sachs, over at World Fuel Services. He’s given us lots of great “What’s Worse?” scenarios. Here we go. Andy, these are the two options. Number one – you have very well-configured security controls, but you’ve got no overall security strategy. Or the complete opposite of that – have poorly-configured security controls but a very well-defined strategy for the year. Which ones worse?
[Andy Ellis] Oh, the second one.
[David Spark] Yeah, the poorly… That’s what I thought. And why is that?
[Andy Ellis] So, look, it can be great to have this marketing description – no offense to any marketing people who are listening – about how amazing your security is going to be, but if you can’t actually implement it, that doesn’t really matter. In fact, what you’re really doing is you’re giving your executives confidence that they shouldn’t have. I would rather have great controls, that you don’t have this overarching strategy, but your controls work and you’re adding more controls. Maybe they’re a little slapdash, you might have some holes in them. That’s certainly not a great thing, but at least the controls that you have actually work, instead of having a coherent strategy without controls that work.
[David Spark] Right. Now, but let me throw this out at you – without having a strategy, you don’t know if you’ve even bought the right products to build out a security program because there’s no strategy here. So, you may have not even put on controls.
[Andy Ellis] But let’s imagine a world in which there were 10 perfect things that you needed to do. Like your security strategy would be perfect if you checked these 10 boxes correctly.
[David Spark] If you do these 10 things.
[Andy Ellis] Would you rather have 10 incorrectly checked boxes or 6 correctly checked boxes at that point? I’d rather have the 6 because at least I’ve got protection in 6 places instead of having no protection in 10.
[David Spark] But you could have some protection in 10.
[Andy Ellis] Some.
[Crosstalk 00:20:47]
[Andy Ellis] But I’d think it’s better than it is.
[David Spark] All right. Mike, I throw this to you. Do you agree or disagree with Andy?
[Mike Wiacek] I think Andy’s going to win this one
[David Spark] [Crying]
[Mike Wiacek] I’m sorry. Sorry, David.
[Andy Ellis] Thanks, Dustin.
[Laughter]
[Mike Wiacek] Does he get a prize or…?
[David Spark] No, he gets bupkis.
[Laughter]
[Mike Wiacek] No, plans that are unimplemented aren’t worth the paper that they’re printed on. At some point, even if you have some controls in place, and you can go back and pull on them when you need it, you know that there’s some value there. Was it Eisenhower had the quote that, “Plans are useless, but planning is essential”? That’s the ideal case, but fundamentally if you have no ability to implement whatever planning or plans you have, it doesn’t really matter.
[David Spark] Let me throw this out at you.
[Mike Wiacek] Sure.
[David Spark] How much does the phrase, “I’m the idea guy,” drive you crazy? Because the person who can implement is far more talented than the person who goes, “I’ve got a bazillion ideas that I can’t implement.”
[Andy Ellis] I want somebody else to say they’re the idea guy.
[David Spark] Yes.
[Andy Ellis] Right? Because that person is the implementer who’s like, “When I need more ideas, I got an idea guy.” Right? They’ll give me the ideas, they’ll give me something, and I’ll go execute on it. But if I say, “I’m the idea guy,” well, who’s your execution girl?
[Mike Wiacek] I think that’s absolutely… Again, I’m just agreeing with you again. It’s true. There are some people who are idea people, and they have a unique value to see how things get plugged together. Unfortunately, organizations tend to reward that person more than they reward the person who actually implements that stuff. And in the long run, it’s the people who actually make stuff happen that are underrecognized and underappreciated. So I’m just going to say for anyone out there who has been the person to implement a lot of the things that were other people’s ideas, you have someone here who hears your plea and wants to give you a little pat on the back virtually as much as I can.
Please. Enough. No more.
22:50.280
[David Spark] All right. Today’s topic is threat detection, and I’m going to start with you, Andy. What have you heard enough about with regards to threat detection and what would you like to hear a lot more?
[Andy Ellis] So, I think I’m tired of hearing about dwell time. I think everybody likes to think about, “Oh! How do we bring the dwell time down from 200 days to 150 days?”
[David Spark] But I must say that that is, like, when people talk about what’s the one metric, that’s the really popular one.
[Andy Ellis] But I want the metric to go up, not down. Which sounds backwards. Because I want people to find threats the same day it happens, at which point you don’t count it as dwell time. Like Simpson’s paradox. If I can take the easy 50% of the things you find in threat hunting and automate that, my dwell time just went up, not down. Because those don’t count for dwell anymore. That’s what I want to hear people talking about, which is how do I automate threat hunting so it’s not threat hunting anymore?
[David Spark] I like that. All right, I’m throwing this same question to you, Mike. What have you heard enough about with threat detection and what would you like to hear a lot more?
[Mike Wiacek] So, for me, I think when it comes to threat detection, the thing that is nails on a chalkboard is when you hear teams talk about how they’ve tuned their EDR to having a manageable level of alerts, and I know it’s a common practice.
[David Spark] We hear that a lot, actually, a lot.
[Mike Wiacek] But when you hear “tuning,” that basically says we’re going to ignore a bunch of stuff, and that’s one of those things that is like…
[David Spark] Andy agrees with you here.
[Andy Ellis] I mean, sometimes it’s stuff you should ignore.
[Mike Wiacek] Yeah. Sometimes it is.
[Andy Ellis] But most people aren’t great at tuning.
[David Spark] But it’s very interesting, this whole tuning concept because it’s not focusing on how do we solve the problem, it’s, “How do we make this less painful for the people who have to deal with it?” Because the idea is that’s there too many of these alerts and, well, they can’t deal with it, so let’s just get rid of a certain number of them. Well, who knows if those are good or bad? So, yes, my guess is you could tune it to just get two alerts a day if you wanted to, however you set it up.
[Andy Ellis] Why two? You could go to one.
[David Spark] Go to one. Go to zero.
[Andy Ellis] Zero.
[David Spark] Got no problems! There you go. Mike, go ahead.
[Mike Wiacek] No, exactly. You pick a magic number based on what your team can handle each day. And the thing that I always find most interesting is, look, if my – whatever system it is, I don’t want to pick on any one category – says, “This is bad,” then okay, look, you obviously gave that vendor money to buy said system, so you should treat that as bad and move on. I’ve always found much more interesting stuff in the gray areas. What is in between absolutely no good and absolutely no bad? And when you think about how most organizations are tuning these systems, they’re focusing on the stuff that’s much higher confidence. And if I have a limited amount of human capital, brainpower, to look at stuff, almost the question is what is the darker area of the gray for them to look at? And that’s really hard to just try and think you’ve unilaterally tuned out.
[David Spark] All right. So, let’s get the story of Stairwell here. What is it that you’re tuning in that’s not being seen?
[Mike Wiacek] Yeah. So, one of the cool things that we thought about with Stairwell was that attackers are often actively trying to evade systems. We’ve touched on it earlier in the show almost. So, we know that there’s no detection system that’s foolproof, so the fundamental approach behind Stairwell is we just accept that. And so we collect a copy of every executable file from every machine in an enterprise, and we pretty much store it for as long as you want us to. And so that means we’ll have one copy of Notepad.exe but also one copy of Suspicious.dll from every machine that has it. We can tell you when they first showed up, when they last showed up, but the most important part is we have those raw bytes.
And so now when new information comes to light, like Log4j, SolarWinds, these were perfect stories for where companies spent thousands of hours of manpower to try and understand, “Was I impacted? Was I affected by something?” and for people who are on our Inception platform, it was almost a few minutes’ worth of work, “Where do I have log4j? Where did I ever have log4j? Here’s a list of machines. Here’s a list of computers. What other files did those machines have that were rare or suspicious even in the remotest sense?” We have those files available. So, companies are able to leverage what I would think about as threat hunting-style techniques, but in the vein of SOC and incident response capabilities as well.
I often say that STAIR in Stairwell is actually SOC Threat Analysis Incident Response, it actually spells out STAIR. Because we’re combining the threat hunting techniques across those three different teams, and all three of those teams can have value whether a single one or all of them get unique value from this approach where they can study this stuff out of band, and you can do retroactive detections, understand, “Did we have this? Did we ever have that?” And getting that level of continuous operational integrity that you can go back to your CIO or CEO and say, “Hey. The Sunburst malware has never been and is not in my enterprise.” And be able to answer that question in minutes is very different than, “Hey, we have to go figure this out. We have to go scramble through logs. We have to go look for all this other data.” It’s all pre-preserved, which is the fundamental approach that we’re taking with Stairwell.
[David Spark] All right. One closing question here. What I’m always impressed with, and I think what you’ve built here with Stairwell is quite impressive, whenever you throw something like that to your customers, they will use it in a way that you didn’t expect. What way have people used Stairwell that you did not expect?
[Mike Wiacek] One of the things that happened actually, I think Uber a few months ago, they had a breach where someone got in and they found a PowerShell script that had some credentials in there. And that’s like the embedded admin tokens or keys or something that plagues every security person because it happens, it happens a lot. So, one of the things that came up as an unintended effect here is usually you can use YARA or other things to search for malware. But people started using Inception to look over their organization’s collected files for files that contained embedded OAuth tokens or embedded GitHub tokens or AWS credentials, and they were able to go and say, “Hey. Hey, this computer over here has a shell script that has AWS credentials in the clear hard-coded [Phonetic 00:29:58],” and they were able to go do that. So, imagine be able to find any file in your organization where credentials are encoded and go over and change them or remediate them and treat them properly. It’s the level of visibility and power you get in that type of environment that we offer with Inception that is really game changing. It’s almost a Swiss Army knife for security.
What’s the ROI?
30:21.771
[David Spark] Are we starting to see cybercrime not pay? So, an article on Insider by Sindhu Sundar notes that ransomware payments are going down and the US government has successfully broken up ransomware gangs. One hacking group had to lay off 45 call center operators. This is moving in the right direction, but it’s far from a success. So, Mike Johnson, the other co-host of this show, says he tries to build his security program so that it’s too costly to get his data. Andy, I’m starting with you here. What more can we do to make breaking in and stealing our data just not worth it?
[Andy Ellis] Well, I think Mike just laid out clearly which is you start by figuring out how do you make it that there are better moves for the adversary than coming after you or your data, right? So, one way is drive up the expense. Another way is drive up the consequence, so the US government’s been doing some of that on ransomware. Another is figure out are there other things that that adversary might want to do. Sometimes the adversaries are driven by a different profit. Think about like ticket scalpers, right? So, how do you engage them because they’re a security adversary if you’re a ticket site. When you think about everything that ticket sites who are in the news have to go through and all the bad PR they end up with, most of that’s created by pivoting themselves to make it more expensive for their specific business adversary.
And so I think that’s what we focus on, which is how do you minimize data so that you don’t have, “Oh, here’s the one place where you can steal all the data.” Can you encrypt data? Can you tokenize it? There’s a whole list of things you might do. Can you make it that your machines themselves aren’t valuable assets? Egress filtering so that you can’t become part of a botnet. I think most companies don’t think about how much value their cloud systems have to adversaries who are bot herders.
[David Spark] Mike, what say you?
[Mike Wiacek] You said egress filtering. I started in tech working at dial-up ISPs in the mid late ’90s.
[Andy Ellis] Oh, God, yes.
[Mike Wiacek] Right? This was a thing where a lot of people used America Online and so forth but there were lots. You’d pick up the Yellow Pages, look under Internet, and you would find people like the companies I worked for where we had 50 modems and a T1 line, which was fun. Some of the best practices from 1997 are still not adequately adopted by organizations today. Like ingress and egress filtering is just such a important concept but it often just falls by the wayside. I think that there’s a lot of security hygiene that often gets ignored because it seems too simplistic or too monotonous of sorts. Not everyone in an organization needs a real computer. I’ll openly say if you don’t need a full computer with lots of applications, you should just use a Chromebook. Don’t worry about a device that you can’t have ransomware on.
[Andy Ellis] Hey, Mike. You’re a CEO. CEOs don’t generally need that many things. Do you use a Chromebook?
[Mike Wiacek] No. But I’m also at the same time I still write code.
[Andy Ellis] Okay.
[Mike Wiacek] So, I’m sitting here with Terraform and compilers and I literally was configuring a hardware VPN device before I jumped on the call with you guys, so my hands still get dirty. I hope to get to the point where a Chromebook is all I need to do every day.
[David Spark] How many problems does it solve if everyone’s got a Chromebook at your company? In general, like if you deployed Chromebooks everywhere so nobody’s got data sitting resonant on any device, specific device, how many problems does that solve?
[Mike Wiacek] Well, in the context of ransomware, it effectively makes ransomware go away. One of the things that I actually would be really intrigued to see, stepping back from Chromebooks for a second, I’d like to see vendors like Microsoft and Apple have is there are file systems that implement what’s called copy on write. And that’s whenever you take a file and you change it, you’re effectively modifying a copy of the original file and you can go back and revert back to them. So, when you have version file systems, yeah, if you want to encrypt a file, guess what? I can always just go back and say, “Revert that file back to the state yesterday,” and it’s back. Right? There’s some technical countermeasures here that can be implemented very low level in operating systems to provide strong resilience to ransomware.
[Andy Ellis] The best resilience to ransomware is being able to instantly provision someone a new laptop when they lose one. Right? If you solve that problem, if an employee calls you up for whatever reason and says, “I have lost my laptop,” and you can have them working in the same day with access to all of their data, you’ve mostly dealt with like 90% of the ransomware issues at that point. And your employees will love you because when they have a problem, you’re not like, “Well, it’s going to wait like five days for us to get a new machine and you won’t have any of your data on it.” So, if you’re like, “Nope, here you go.” Walk down to the Apple store or the Microsoft store or the Chromebook store, pick up a machine, put in your credentials, and you’re good to go.
[Mike Wiacek] 100%. I also do want to give props to the government for taking ransomware as seriously as they have been and getting out there. You have to really think about those 45 call center operators who got laid off, if they get Unemployment or not now, that’s the real question I’m thinking about.
[David Spark] [Laughter] I’m glad you’re concerned about them, Mike.
Closing
36:12.692
[David Spark] That brings us to the very, very end of this show. That was awesome, Mike. Thank you so much. Thank you for coming back. And as I said, it’s Stairwell, remember it’s spelled the way it sounds, stairwell.com, eliminate the blind spots. If Stairwell becomes the darling of RSA this year and you get bought out again, full credit my way.
[Andy Ellis] We want a commission for the podcast.
[Mike Wiacek] If that happens, David and Andy, we will go out for a wonderful steak dinner on me, and we’ll enjoy that.
[David Spark] Okay. [Laughter]
[Andy Ellis] Sold.
[David Spark] Sold. That’s all you have to do, just sell the company, become the darling at RSA. How tough is that? All right, Mike is hiring and best way to contact you through LinkedIn, yes, no?
[Mike Wiacek] Yep. LinkedIn’s perfect and on our website. Obviously, you reach out there and not hard to find.
[David Spark] And Andy is going to be giving a talk. Quickly, what’s your day, time, location of your talk, Andy?
[Andy Ellis] Monday morning at 10:50 Pacific Time. I don’t know the location, but the talk is Telling Fairy Tales to the Board.
[David Spark] Ah. And then hence why you’re going to have your Little Red Riding…
[Andy Ellis] I will be reading from Little Red Riding Hood.
[David Spark] I’m sure the board appreciates that. They’ve read it before. You do know that, right?
[Andy Ellis] Maybe.
[David Spark] Not your version.
[Andy Ellis] I’m going to read the Brothers Grimm version.
[David Spark] Mm-hmm. Any of them going to go, “I thought I came here for a security talk”?
[Andy Ellis] Well, there will then be a security talk after that. Go read the story of Little Red Riding Hood and recognize that it is a cautionary tale about risks that need to be mitigated in an environment.
[David Spark] Yeah.
[Andy Ellis] It’s not a fairy tale. All the Brothers Grimm fairy tales are risk management stories.
[Mike Wiacek] Little Red Riding Hood has a bit of a deception angle in there too.
[Andy Ellis] There’s deception, there’s social engineering. Little Red Riding Hood is even better if you imagine that Rachel Tobac is the wolf.
[David Spark] I met Rachel last RSA I was at, actually. We spoke at the same event. Everybody, thank you so much for listening to our show. If you see Andy or I at the RSA, say hello to us.
[Andy Ellis] And bring over a copy of my book and I will sign it.
[David Spark] He will sign a copy of your book. I’m going to get a copy of your book as well. Should I get one at the event or should I just bring one with me and have you sign?
[Andy Ellis] Bring one there. Not going to be that many available at the event…
[Crosstalk 00:38:30]
[David Spark] All right. That answers everybody else’s question. Have one in hand, have one at the ready.
[Andy Ellis] Yep.
[David Spark] All right. Thank you, everybody, for listening and contributing to the CISO Series Podcast.
[Voiceover] That wraps up another episode. If you haven’t subscribed to the podcast, please do. We have lots more shows on our website, CISOseries.com. Please join us on Fridays for our live shows – Super Cyber Friday, our Virtual Meetup, and Cybersecurity Headlines Week in Review. This show thrives on your input. Go to the Participate menu on our site for plenty of ways to get involved, including recording a question or a comment for the show. If you’re interested in sponsoring the podcast, contact David Spark directly at David@CISOseries.com. Thank you for listening to the CISO Series Podcast.