Episode Transcript
[00:00:00] Speaker A: Greg, welcome aboard to the show today. It's a pleasure to have you.
[00:00:04] Speaker B: Thank you, Ari. Great to be here.
[00:00:06] Speaker A: I want to ask what pulled you into the security industry? Like what was your first experience?
[00:00:13] Speaker B: Great question. Security has just always been my passion. When I was a teenager I loved to tinker with computers and so at the time there really wasn't a good track to learn security. Thankfully now there's many more avenues for people to get into the industry. But I think it started with a curiosity, honestly, when I was a teenager.
[00:00:39] Speaker A: And you actually started pretty hardcore as really thinking about hacking and malware, if I'm not mistaken. Give us some more information about that.
[00:00:49] Speaker B: Yeah, I went into the deep end fairly quickly. I went to school at the University of Texas and I was fortunate to also be hired by the security department at Utah. We had access to the supercomputers, first Ranger and then Stampede, which was a joint effort with the CIA. And then from there I went to work at Rackspace at sort of the beginning of the cloud, if you will. And so when cloud was just getting formed, those were some tough days in security, but it was an incredible experience. We got to see a wide array ranging from elementary things and security all the way to being attacked by nation based actors.
[00:01:34] Speaker A: When you had your first dramatic from your own experience or from your customers experience of really your first security crisis, what did that look like?
[00:01:46] Speaker B: The one that I can talk about was Heartbleed, I think for those that were in the industry at the time, particularly in cloud, because for those who don't REM or don't have experience, Heartbleed was essentially a vulnerability that let you read memory from any server on the Internet that had the exploit. And so if you did it enough, you could eventually dump passwords or other secret information. And so for companies not in cloud, it was a fairly simple patching procedure. But for Rackspace with all this infrastructure, it was a challenge. It was incredibly difficult. When that vulnerability broke, there wasn't even a way to test and validate for it at the time. So we had this vulnerability that we knew people were taking advantage of and not even an initial way to test for it. And so I think that was probably one of the more longer and stressful stints that I experienced. I don't think we've seen anything since that by comparison, at least in my career.
[00:02:55] Speaker A: What do you feel when you look at the risk ecosystem? What do you feel like is the big risk that companies and maybe even individuals are really facing today?
[00:03:05] Speaker B: Oh goodness, lots of risk. So when we look at the security landscape in its entirety.
Software is unfortunately like milk in that it doesn't get better with age, it tends to spoil. And so there are more exploitable vulnerabilities CVEs than there have ever been in history. I also think things are getting very interesting in the AI space and people's reliance with AI. I don't know if you saw the article about people who were successfully manipulating AIs to not recommend their favorite restaurant. Well, that has some very interesting security implications too, because if I can get an AI to recommend code that I know is vulnerable or I know has a back door, that is, I think, going to be the next big treasure trove and next big target.
[00:04:00] Speaker A: How is this different, let's say from, you know, we're searching the Internet, we're going anywhere basically, and there could be malicious players on all kinds of websites that we get to. Are we, is this technology just new so we don't have the firewalls and the protection? It's just not in place for AI yet. What do you think this looks like?
[00:04:23] Speaker B: That's a great question. I think it has to do with the surface of AI. So when we fix a vulnerability, we're typically saying, here's the hole, here's how we're going to patch it, here's how we're going to change this behavior so it goes away. But with AI, the implications and the scraping are so broad that I think it's hard to put something that is a blanket fix because it is almost fundamental to the technology with how they scrape information. And so I don't know of a good way to say, I mean, you could do trusted sources, but anytime you're consuming, you know, user generated content, you're subject to the quality standards of that user content.
[00:05:11] Speaker A: And have we seen anything where people are like hacking AI? Is that a thing yet or not just yet.
[00:05:18] Speaker B: Everything that I've seen is primarily getting AIs to say things that do brand damage so far. But I think actually exploiting the AIs is certainly the next step. And we see these kind of attacks already without AI in the loop. So there's a known type of attack called name squatting where we're essentially betting that a programmer will make a spell check error on a popular repository. And so you put a spelling mistake in a repo and then I essentially put malicious code at that name and then they download it and I get a notification and then I can get access to their systems that way. And so it's the type of attack already exists. AI is just going to be a new delivery method for those types of attacks.
[00:06:11] Speaker A: So, I mean, what I'm seeing is that really the industry is accelerating, right? AI automation on the malicious side is just making it.
And I heard this, that there's support lines to basically allow hackers to use software that was built to allow them to hack. And they can call up a support line and say, hey, I'm trying to use this hacking software. How do I do it? It's really been turned into a business for many years now.
What are we doing on the defensive side? What are the advances that are happening, the new things that we're bringing forth in order to do this? The changes in the industry, the security.
[00:06:53] Speaker B: Industry is coming around to automation. So when I started my career in pen testing, automation was kind of like a dirty word. It was a badge of honor to do manual testing. And so there was a ton of resistance to security automation in the early days, partially because security tools are very noisy by their nature. And so that's something that's rapidly evolving in the industry. But to actually make scalable security a reality, which is what I see as the solution, right? So you have all these vulnerabilities and companies are only testing, say 10% of their applications.
It looks really good to your leadership and security to build a shiny tower. So you can say, look, that's what I built.
That's why I deserve to keep my job. But the reality is you're much better building a moat that isn't shiny, it's not particularly exciting. But the only way to create a moat is through scalable security automation, making the security tools better. You have to lean into it and accept and work around the flaws. Rather than trying to scale security programs with headcount, which was the old way of doing it.
What I saw and what my experience was is there was this endless cycle of a big breach occurring. Companies deciding to invest in security, they hate paying that bill on headcount year over year to scale, you have to hire someone in a one to one ratio for every piece of scale you want to achieve when you're just doing manual testing. And so they would get tired of doing that, they'd reduce the headcount and then another breach would occur. And so I think embracing security automation is really what's changing and what's making an impact both for businesses and consumers and safety online in general.
[00:08:50] Speaker A: So I want to attack this concept of pen testing for a second.
Do you think, let me start from an extreme perspective. Do you think companies should Be doing pen testing today?
[00:09:04] Speaker B: Yes. Yeah, absolutely. I think there will always be security vulnerabilities that tools cannot find. I think it's a vital part of the process to find some of the more interesting issues.
[00:09:20] Speaker A: So I have heard experts say instead of pen testing, do white box testing, which is basically have different experts review your inner architecture as opposed to basically trying to hit you with the latest exploit that hasn't been patched yet. What would you say to that argument?
[00:09:42] Speaker B: It's a time efficient argument, to be honest with you. Right. So when a malicious actor that is sophisticated takes a serious interest in you, there is no time limit for them to get in. If the prize is big enough, they will spend years.
And a pen tester never has a year to do an assessment. They have a month, if you're lucky, two weeks, sometimes a day on short notice if there's a release going out. And so it's good to be able to see the whole picture. Right. Like seeing architecture can help you to spot where security flaws may exist. But when it comes to the sophistication of testing, I just, I don't think it's a perfect substitute for, you know, complete and thorough pen testing.
[00:10:34] Speaker A: Is there? I mean, considering that, you know, if we're attacked by, you know, somebody that's really out to get us, right there, there, there's no money limitations, there's no time limitations. Right. Like government attackers. Really anything that we can do.
[00:10:51] Speaker B: I'd like to say, yes, I think, yes, there are some absolute defenses to at least make it more inconvenient. Right. So when we talk about the extreme of extremes, you have extremely valuable trade secrets that a foreign adversary, a foreign nation is interested in, then the first and sort of best step is just having an air gap in place. If you do not have to service.
[00:11:24] Speaker A: That part, explain what an air gap is. So we all are kind of in tow.
[00:11:30] Speaker B: Yes, just some sort of separation from a network perspective. So typically a firewall. So if you do not have employees or a business presence in a certain part of the world, there isn't a need to make your services available to that part of the world and then those services can't be attacked. So if it's the case that the actor has to relocate, that provides some level of defense. But with the rise of cloud, it's sort of easier and easier to get pivot points. And so there are no absolute defenses. I mean, you have to take a defense in depth strategy. If you truly don't want to be the victim of a cyber attack, you have to have, you know, good testing, you know, multiple layers and outs to isolate yourselves and give yourself as many outs to not have data exfiltrated. At the end of the day, if.
[00:12:29] Speaker A: You don't need to really actually save and keep that information, just don't have it.
I think that's one thing that just architecting your system to have less information from a transactional perspective can be a, you know, sometimes a simple but overlooked solution.
But you know, honestly, if some big government who has the funding and the know how is trying to get you, then you're in trouble. But the truth of the matter is that most of these security breaches are organized crime and other kind of organizations. And what they're going to do, and keep me honest here, if you see it differently, they're going after the path of least resistance. If you're better than everybody else, they're going to go after everybody else first.
[00:13:14] Speaker B: Agreed? Agreed. Yeah. At the end of the day it's just a business decision of how much profit can these nefarious individuals make versus how much time do they need to put in. You have one group of malicious actors that is essentially just always scanning the open Internet looking for low hanging fruit. They want to get software on random PCs to say mine cryptocurrency. And then in the say 1%, you have these sophisticated actors that are backed by governments and have access to tools, time and money. That is honestly not the typical cause of a breach. The majority of the breach is honestly just being impacted by known vulnerabilities. You think of going back in time a little bit like Equifax and Struts, that was a known vulnerability that was just sitting there.
[00:14:08] Speaker A: Yeah, we kind of think about hackers figuring something out, something new, but a lot of what happens today is actually a derivative of the fact that a patch was just released, a security patch. They're just reverse engineering the security patch and like, okay, not everybody is going to patch that immediately and they're taking advantage of that interim in the time basically that lag in fixing the patch, which is kind of an easy way to hack systems. So in some way. Right. The security work is creating the security breach, which is completely counterintuitive.
[00:14:47] Speaker B: That's extremely true, especially if the fix is public. So if it's in a popular piece of open source software that's used by a ton of servers, it makes it even easier. Or when a piece of software comes to end of life, it can be like Hacker Christmas because they know once it's end of life, it'll never be patched. And so you'll always see these big waves and exploitation, particularly once a software is end of life.
[00:15:17] Speaker A: Yeah, sometimes I see, like in hospitals or places like that, I can see Windows XP or sometimes nt. And it kind of horrifies me to my core that those things are still out there.
[00:15:32] Speaker B: Oh, it's terrifying. It's nothing short of terrifying. I feel for consumers. I just got a breach notification two weeks ago from one of my healthcare providers and the thing that just makes my hair stand up is I'll be at a doctor's appointment and they will leave me alone in the room with the computer unlocked that is connected to the entire hospital system. And there's always that itch of if I just plugged in my usb, we're going to have some fun here or put in a keylogger. I mean, the possibilities are endless. They're only subject to your creativity. But it's terrifying, to be honest with you.
[00:16:16] Speaker A: And I want to pivot a little bit and this is a difficult topic, but a lot of the. If you kind of think about where these vulnerabilities are coming from, they're coming from the development process.
I want you to walk us through at the most simplistic level. What is DevSec? What does that even mean?
What is the problem that is created and how we're trying to solve it?
[00:16:43] Speaker B: Yeah, so when we think about how modern software is built today, I do think it's better overall. When you look back 10 years ago, PHP was very popular and if you showed me a PHP application, people are quick to forget, but it wasn't that long ago, you know, in, in terms of history. But it is near impossible to secure a PHP app. It is just not designed for security. And so we've gotten a lot better about adding harnesses around software, typically called frameworks, which are designed to be more secure by design. But when we look at the sophistication of how software is developed to today, many developers are relying on dependencies. They're not writing all the code themselves. And so as that code ages, those vulnerabilities from their dependencies become present in any software that it is used in. And, you know, we're starting to see an even more extreme case where we're having AIs write that software. So it may be the case that, you know, those dependencies get harder and harder to review. But to essentially increase the speed of software, we started to rely on dependencies more and more. And when those dependencies become vulnerable, we have this opportunity to exploit that in any of the software or servers where that dependency is present.
[00:18:12] Speaker A: So what's the solution? I mean, as a software developer myself, I know that going back and rewriting code is incredibly difficult, especially if maybe the original developer, you know, has gone to a different job. So you're coming into something that you don't understand. You've, you've never seen it before potentially, and you don't even maybe understand the logic of what the software is supposed to do. How can you even address a problem like this?
[00:18:39] Speaker B: It's a great question. There's a lot of different ways to approach it. None of them, I don't think we have a winner yet in that space. So when you look at like what banks are doing, who. And when you think about a bank, their business is money, so they really care about security. You'll see cases where they have a set of sort of golden dependencies that you are allowed to pull from. But what happens if your dependency isn't in there? What happens if you don't have an option? Is the software developer going to try to subvert those controls to try and make their job easier? I probably would, to be honest with you. And so I don't know if there is a great solution. We can get better about scanning, right? So getting visibility at every step that a piece of software is developed I think is the best answer right now. And it can even be a low cost answer. But that's sort of the goal of the DevSecOps movement. So we had the DevOps movement, which was primarily focused on how software is built, deployed and ultimately ends up in production. And then security, which is typically five, six years behind development. In terms of sophistication, we have DevSecOps which is about bringing testing and visibility to each of those stages. And so I think that is the best solution. But there's still these big questions of, well, what do you do when there's a vulnerability in your dependency and there are no alternatives and it isn't being maintained and there isn't an update coming, what do you do? Do you stop developing? Do you take business cycles away?
Those are difficult questions. There's pluses and minuses with whatever you choose to do. But I do think visibility and testing in every stage through DevSecOps is probably the best option we have right now.
[00:20:35] Speaker A: So I mean, it's really hard to solve a problem once it's happened. I think we would agree to that, but there is value in the processes that we use as organizations. So from that perspective, if you kind of think about best practices for organizations. Make sure you're doing abc. What would that look like?
[00:20:56] Speaker B: Great question. So when we think about building security programs from the ground up and what are the easiest bases to cover to give you the most coverage? Right. So I think about in terms of how do I get to 80% coverage or what's the single win I can get to with regard to A, B and C. And so on the testing side, you need to bring in some level of testing for your software. So typically that's a dynamic tool, a static tool, and a tool that evaluates dependencies. So just three pillars of a really rudimentary application security program. And then you also need means for detection. I would say that that's B. So what's the simplest IDS system you can get in place? So when things do go wrong, you visibility to do containment. And then three, I think that comes down to process and where you store data. So if you have a very lax process in which you say don't follow privileges of least principle, so everyone has access to all the sensitive data, cleaning up a security incident is going to be much more difficult. So I think those would be the three that come to mind for me is rudimentary AppSec program, some level of IDF test and then having the correct policies to protect and restrict data so incidents don't snowball.
[00:22:32] Speaker A: This idea of identity, I think it's incredibly important because I mean, even dealing with false alarms is a big thing of what we do. And if you can just track that an action happened by a certain individual, then you can say, well, what were you doing here? Was this real? So I remember countless instances we know, oh, it's Developer X. And we went and you know, we didn't know if it was a real security incident or not. And we wanted to say, hey, this was, this guy's name was Ron. Ron. What were like, is this you? And he was like, oh yeah, that was me. Like I, you know, I had to restart some databases for development purpose. And then you just know this is not a real incident. So by just having that identity information, you can either figure out that it's a real issue or not really quickly. So I think it's, it's often by immature development organizations, you know, oh, here's the password. This how we access the database. That is a, that is a recipe for disaster in many different ways.
I wanted to ask you another question on identity. Do you, do you think that there's a gap in the industry when it comes to identity in regards to tools, infrastructure or maybe even the requirements of software companies around the world to really verify identity. What's your perspective there?
[00:23:51] Speaker B: I think there are good solutions for security of identity, particularly in the behavioral analytics space. So for example, if you have someone that works in Florida and you see them try to log in from South America, that's a behavioral indicator that maybe it wasn't that person.
I think they're good solutions, they're just expensive. They're expensive, they're complicated, they can be difficult to deploy.
Even some of these zero trust offerings, they're accessible to large enterprises, but unfortunately mid sized enterprises, small cap companies, startups, sometimes those tools are inaccessible for them, has been my experience. And so I do think the solutions are out there. I think one of the problems with the security industry is that we're constantly catering to large enterprise because that is the easiest way to honestly build a public company in security or to have a trajectory towards having an IPO and being that security company. Very few are catering to mid market small cap companies, et cetera. And so I think there's good solutions. I just, I worry about their accessibility.
[00:25:12] Speaker A: From a certain perspective. We could say, look, if you are a small company or a startup, you're, you might not even be a target because the amounts of data that you have and your ability to maybe, you know, try and pay some kind of ransomware is low. So maybe you're in less risk. Is that a fair assessment or, or is there a real problem with our ability to cater for the small to medium sized businesses?
[00:25:38] Speaker B: I think breaches can still be extremely costly for small companies.
I've seen some data that if a small company is breached, I believe it's something to the nature of you're 60% likely to go bankrupt from that breach. I think it depends on your industry, what regulations you can be subject to because some of these fines definitely have the opportunity to bankrupt small businesses. And so I think it's, you know, overlooked problem, to be honest with you. I think it's a real problem. I think it impacts a lot of businesses and unfortunately it's just an underserved area of the market. And so in some cases it may be possible for small businesses to more easily recover because of their footprint. But unfortunately the data that I've seen suggests that the impacts can still be devastating and can lead to the end of the business. Unfortunately.
[00:26:37] Speaker A: Yeah, I think an important point here, a counterpoint to my own, is that, you know, the malicious attackers are not necessarily differentiating between big business and small business all the time. They're just scanning and seeing what they can get. So there's definitely a phishing approach of, you know, what can we get? And if they. They get you, even if you're a small fish, they might try and fry you.
That's. That's an unfortunate truth. So you aren't necessarily immune. I appreciate that. Greg, our final question. If you had to give a recommendation to young engineers coming into the security industry, what would that be?
[00:27:14] Speaker B: I would recommend to learn some programming. I think that is the key area to really round out security experience. It will give you a better understanding of what you're testing, it will make you more effective in your security work, and it will also give you something to lean on for the purposes of automating things that you don't like doing.
I think that's sort of the number one key to being successful these days. Unfortunately, it's not enough these days to understand vulnerabilities and be able to run security tools. I think if you want to push your career as far as possible, you have to have that background and experience in programming to maximize your potential in the field.
[00:28:02] Speaker A: Greg, I appreciate you. Thank you so much for joining today. This was really great.
[00:28:07] Speaker B: Thank you so much for having me. Ari, it was such a pleasure.
