About This Episode:
If you don't fix your security vulnerabilities, attackers will exploit them. As testers, we have a responsibility to help to secure our applications. In this episode, Ted Harrington, author of Hackable: How to Do Application Security Right, shares how to defend against attackers by learning to think like them. Discover how to eradicate security vulnerabilities, establish a threat model, and build security into your development process. Listen up!
Exclusive Sponsor
The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs. Try it for free today!
About Ted Harrington
Ted Harrington is the author of HACKABLE: How to Do Application Security Right and the Executive Partner at Independent Security Evaluators (ISE), the company of ethical hackers famous for hacking cars, medical devices, and password managers. He’s helped hundreds of companies fix tens of thousands of security vulnerabilities, including Google, Amazon, Microsoft, Netflix, and more.
Connect with Ted Harrington
- Company: tedharrington.com
- LinkedIn: securityted
- Twitter: @securityted
- YouTube:https://www.youtube.com/channel/UCJBZ9vwvp2A4z18JifO8kDw
- *** Get HACKABLE Now ***
Full Transcript Ted Harrington
Joe Colantonio[00:00:01] Welcome to the Test Guild security podcast, where we all get together to learn more about security testing, with your host Joe Colantonio.
Joe Colantonio[00:00:11] Hey, it's Joe and welcome to another episode of the Test Guild security podcast. Today, we'll talk with Ted Harrington, all about his new book, Hackable How to Do Application Security Right.
Joe Colantonio[00:00:20] Besides being an author, Ted is an executive partner at Independent Security Evaluators, the company of ethical hackers famous for hacking cars, medical devices, and password managers. He's also helped hundreds of companies fix thousands of security vulnerabilities, including companies like Google, Amazon, Microsoft, Netflix, and more. Ted also leads a team that started an organized IoT village, an event whose hacking contest is a three-time DEFCON Black Badge winner, representing the discovery of more than 300 zero-day vulnerabilities in counting. So listen up to discover how to do application security, right?
Joe Colantonio[00:01:01] It's no secret that the number and complexity of applications are growing. But what is alarming is that 90 percent of security incidents result from exploits against defects in software. The need for better application security has never been higher and MicroFocus Fortify is here to help. Fortify is the recognized market leader in application security, and it is the most comprehensive and scalable application security solution that works with your current development tools and processes. With Fortify, you could start security applications in a single day, including custom code, opensource or commercial components and scale as your needs grow with an on-premise as a service or a hybrid implementation. Check them out, head on over to MicroFocus.com/appsecurity.
Joe Colantonio[00:0:51]Hey, Ted, welcome to the Guild.
Ted Harrington[00:01:54] Hey, thanks for having me. I'm excited to be here.
Joe Colantonio[00:01:56] Awesome to have you. Before we get into it, is there anything in your bio that I missed that you want the guild to know more about?
Ted Harrington[00:02:02] I think you nailed it. I mean, I'm a leader of ethical hackers, and I hope that I can share some insights and stories from what we've learned along the way of doing this for many years.
Joe Colantonio[00:02:12] Awesome. So I guess before we get into it, the first thing is writing a book is very difficult. So I always ask authors why put the effort to write a book? Why write this book? Was there something you saw missing in the industry that you thought people needed to know more about?
Ted Harrington[00:02:26] Yeah, that's a great question. Writing a book is it is really hard and it takes a really long time. And one thing that is really interesting about writing a book is that motivation alone won't get a book written. And a lot of people think like, “Oh, once I'm inspired to write, I'll sit down and write.” But like, that's just not going to happen over a multi-year process unless there is a larger mission. And in my case, what really forced me and I'm using that word maybe a little loosely, but I do kind of feel like it was I was, I had to write this book. It definitely crossed the threshold where it was no longer I want to write this book. It was like you must write this book when I noticed a few things that were happening. I mean, first of all, this is all against this sort of baseline context that I'm the kind of person who likes doing hard things and likes the challenge and kind of always had a book in me. So that's kind of where I started from. But what made me write this book was there were two things that I noticed. The first thing was I noticed that we kept having the same conversations over and over and over again. And as you mentioned, when you're introducing me, we serve all these major technology enterprises as well as, you know, funded startups that are much, much smaller. And then, of course, everyone in between. And I notice that no matter the size, the revenue, the headcount, the market, they were focused on the problem. They're focused on all of these different companies. They kind of all struggle with the same thing when it comes to securing software systems. And what I noticed that and of course, the way I noticed it was I was like, I keep having the same conversation over and over again. This is interesting. And once I noticed that then I started thinking about how do you solve those common problems that all of these different types of companies have. And that was really the moment that was like, OK, you must do this because when I looked at what are the conventional solutions like, what do most people talk about in terms of how you address those problems?
Ted Harrington[00:04:14] I realized they were largely backward. The conventional approach, the way that most people talk about addressing these challenges, in my opinion, and not just my opinion, scientifically were incorrect. And that was when I said I have to write a book that addresses those misconceptions, it not only identifies them but says, “Hey, here's why that's wrong and here's what you should do instead.” And so that's why this book is organized the way that it is. It's organized around these different types of problems. But it also is written as even though I'm certainly making a case for some maybe ways of thinking that not everybody holds today, I still wrote it to be practical and to be a guide and to be useful and actionable. And quite frankly, the advice it's in here is like the exact same advice that we give to all of our customers.
Joe Colantonio[00:05:01] Absolutely. It's very accessible because it's written really in a down-to-earth type of manner as well. So it's not, you don't need to be I don't think you wrote it sounds like a super geek security kind of expert. It's almost like anyone, you can give this to a CEO or to an engineer. I think both would get value from it. I assume you wrote it from that perspective as well.
Ted Harrington[00:05:19] Yeah, that was very intentional. And that was also very difficult to do because if you think about it, I mean, of course, we're oversimplifying things here. Right. But if you think about it in the simplest sense as the way I thought was a really good distinction you just drew. So you've got the, you know, the super in the weeds technical like the security nerds right on one end and on the other end, you got the business people. And can you communicate in a way that helps both of them? That's really the challenge that you have to think about. And so you have to write in one voice or another. So if you write in a super complex, super technical way, you, of course, alienate and exclude the business folks. But you might also exclude the practitioners, too, because who needs to read a book about these ideas, the people who are struggling with the ideas. And so for that reason, I invested a lot of care and effort into how to communicate these ideas. So in the book, I mean, you obviously notice this from reading it, but I tell a lot of stories, a lot of metaphors. I really try to simplify the core ideas in the way that I did that was first, of course, identifying who did I want to write this book for. And I was writing the book for essentially three kinds of people. One is what I call the technology leader. So like a CTO or a VP of engineering or equivalent. You know those titles, whoever's responsible for security, the title is different based on the size of the company. But those types of roles, like they're in charge of more than just security, but ultimately the buck stops with them. So that was one audience. The second audience is software developers and the third audience was security professionals. So that's who I wrote it for. But how to actually communicate those ideas the way that I did that was by visualizing describing these ideas to my, who was at the time 12, my 12-year-old nephew, who is, he's not a security professional, he's not a CEO or a CTO. He's none of these people but he is smart and he is curious. And so that was a really helpful guide to be able to say, OK, well, any time I arrive at a concept that we might assume, you know, those of us who work every day and this might assume, like, of course, somebody knows what this is, of course, somebody knows what a cloud is. Of course, somebody knows what penetration testing is. Does a 12-year-old know? So now that helps me, like, really simplify. What does it mean? What's the definition? What's a metaphor to help explain the idea? And so what that does is that means that even the people who do know these things already, at a minimum, they're like, “Yes, OK, I know exactly we're talking about.” And most likely it gives them a new way to think about it. I mean, that's what I've been hearing almost every day since the book came out, there are people who have been doing this for a long time saying, “Wow, I never thought about it like that. That's awesome. You helped me think about it differently.” And that to me was that's like that's what you live for, you know?
Joe Colantonio[00:07:57] Absolutely. And I think sometimes if people take security they take it like it's like a specialty group, an organization that handles it, and you kind of demystify a lot of these topics to make it for the every person type of approach. So I think you start off, you have 10 different chapters. And so you mentioned each chapter kind of relates to something a lot of organizations struggle with. And the first one is the mindset. So what did you see about a mindset that you saw from company to company that people were struggling with?
Ted Harrington[00:08:22] Yeah, what's really fascinating about that particular idea is that you know, all of these different problems that are identified in the book, some of them are companies understand that they have this problem like they'll say, “Hey, I don't know how to deal with when I get my security assessment results back, how do I deal with all of that work?” Like, that's a stated problem people have and I dedicate a whole chapter to that question. But then there are other problems that are unstated that people don't realize they have. And this is definitely one of them, like “How should I even think about this?” And I grappled with whether how to approach that, because if someone picks up a book and the first thing out the gate addresses a problem they don't realize they have, are you helping them or alienating them? And that was something that I really spent a lot of time thinking about. How do I help the person who doesn't realize they have this problem realize it. And so that's why I told, you know, a few stories in here that we're like, well, here's how a company thought. And here was the result. And it was a good result. And here's how a company thought. And it was a bad way to think about it. And so it was a bad result. And it's really as simple as are you trying to get better? Are you using security as a way to be better tomorrow than you are today? And to me, as a security professional and I think to many of the people who are listening, this probably like, “Yeah, of course.” I mean, that's the point of security. But you'd be surprised how many companies that's actually not the way that they think about security. They think about it as well. Here's this exercise I have to do, even though I don't really want to do it, but I'm going to do it because I got to do it. And so I'm going to do it. But I'm going to like when your mindset is that what ends up happening is anywhere a corner presents itself, that corner will be cut. It's like I use fitness as a metaphor for security. And I think if you use that as a metaphor like if you were going to the gym because someone told you to do it, not because you wanted to do it, someone told you to do it, you know, when you're starting to hurt on that, you're trying to get to ten reps and you're on like the eighth rep. No one is counting. You'd be like, that's good enough. That's ten reps because you don't care about it. You're doing it because you're doing it to satisfy someone else. You go tell that person like, “Yeah, I did ten reps.” And that sort of what's going to happen for organizations who aren't trying to actually use security to get better. And that's a remarkable distinction between companies who get it right and those who don't.
Joe Colantonio[00:10:27] So when you talk about security, is it from a compliance perspective coz I know a lot of companies just go through the motion because they have compliance issues they need to meet. But I think you have security from the risk type of perspective. So how does a company deal with that? Do they usually deal with compliance in-house? And then for more technical types of security things like actually Pen Testing, do they, should, it was better to meet with a partner outside the organization. How does that typically work?
Ted Harrington[00:10:52] Well, it's important to note the compliance and security are not the same things and they are very commonly interchanged and they should not be, even if they're not explicitly like we're compliant, thus we're secure, although a lot of companies will do that like we're, you know, fill in the blanks compliant. And that's obviously a problem. I mean, you need to look no further than the breach headlines. And you look at, say, any major credit card breach originated from an organization that was compliant with PCI, which is the, you know, the regulatory framework around how what you have to comply with in order to process credit cards. And so that right there tells us that, “Hey, well, compliance doesn't necessarily deliver security.” Well, compliance is really good in terms of it sort of sets the baseline. It's a starting point. It's also really good as a motivator in order to drive investment in security. Right. Because, yeah, in many organizations you must be compliant. So, for example, let's say you're in health care, you must comply with some of the health care regulations. Well, that's great. to be able to say, “Well, we are now going to invest time, effort, and money in complying with this regulatory framework. How do we want to spend that time, effort, and money? Do we want to spend it to literally do the minimum and just check whatever the boxes are that are presented to us because we could do that? Or do we want to invest the time, effort, and money and saying we're going to actually secure this thing and then as a result will be compliant?” And that is definitely the case that I argue in this book with our customers, with any breathing person that I'll talk to. That's not just the question about the book. And then the part of the question you were asking, who does that? Should that be done in-house versus external? Well, to a certain extent, that depends on the organization. But I'm a big advocate of having both internal teams as well as hiring outside experts. And that, I think, surprises people sometimes because they're like, “Well, Ted, aren't you literally one of those companies that outside experts shouldn't you…isn't this your moment to be like and you should only hire companies like me?” And that would be very self-serving to do that, but would also not be the right advice over a long enough lifespan for companies. Now, at the earlier, less mature end of the spectrum, you should start with hiring outside because it's a way to fast-track getting the resources and skills that you need. And it takes a long time to build in-house capabilities in smaller companies. Frankly, don't need a very diverse security team right out the gate. They need the capabilities, but they don't need them as employees necessarily. Over time, you ultimately need both. And so whether you're talking about achieving security, achieving compliance, dealing with how you approach risk management, third party management, third party risk vendor management, all these different issues ultimately come down to security is the objective. And you do it in partnership with an outside organization.
Joe Colantonio[00:13:37] Absolutely. I think another thing people struggle with is just like with automation or functional testing is sometimes they wait till after something's developed to start testing it. And, you know, there's a thing in development now shift left to trying to push things earlier, the order in the software development lifecycle. So because security, if it's not big, tends to be secure, then at the end, the end result is they're going to be secure. So you have a chapter on the white box and white box that's choosing the assessment methodology and you have white box versus the black box. So what's the typical breakdown that you recommend for companies to focus their energy on?
Ted Harrington[00:14:09] Yeah, so this particular topic is definitely one of those ones where people, once they hear about it, feel like, “Oh, wow, I never thought about it that way.” And this is one of my big soapboxes that I've always started on. So for people who are in the audience that might not understand the distinction, I'll just quickly define the distinction. So white box is a testing methodology. Black box is a testing methodology. And basically, they both boil down to the information that is or is not shared. And in black box approaches, security testing is done where an organization, a company whose buildings say a software system and they want to understand its security implications, they'll hire some outside firm and in a black box model. They won't share any information with that company. They'll say like, “Hey, I need you to emulate an attacker and just see if you can break in. And in a white box methodology, you do the opposite. You actually collaborate very closely with them. You share a lot of information, access to design documents, access to engineers, access to source code. And the reason that people often want black is one that on its surface sounds valid. But the way that it actually manifests is quite flawed. And the reasoning is people say, “Well, the attacker doesn't have information about how the system works. The attacker can't ask my engineer how the system works.” So that's what we need our security partner to do, too. And that's what most people think now, that on its surface level, that sounds correct, but it's actually very, very flawed, because when the goal is and this is an important distinction because there are cases where black box makes sense if you have a different goal. But when the goal is to be able to find and understand the security issues in the system and then fix them black boxes in a great way to do that, because ultimately what you're doing in a black box model is you're really testing the security tester more than you're testing the system. And there's a metaphor, the wove throughout this particular chapter. And I'm always sort of talking about this castle metaphor to explain these concepts. And it's sort of like the medieval king who wants to understand, can he be assassinated? And so he orders one of the nobles in his kingdom to send some knights and see if those knights can break in and could they get to him and that will help him understand, could he be assassinated by his actual enemies? And so in a black box model that would essentially be having the knights show up and don't tell them anything about the castle defenses. So think about what that means. Boots on the ground, right. The knights show up. They see a moat encircling the castle and they start trying to count the alligators that are in the moat. Well, the king already knows how many alligators are in the moat. What has the king just achieved by the knights spending the time and effort by doing that? He has achieved nothing. And so literally the king has wasted time and his own money to find out things that he already knew, and it probably isn't even exactly correct anyway, because to a certain extent with black box, there's some you know, you're guessing at some points. And so that's why white box is a lot more powerful because the king could just say, “Hey, look, we've got 17 get alligators, we've got this many archers. Here's how the drawbridge works. Here's what the interior compartments look like. If someone wanted to get in, what would they do?” And now the knights can be like, “Oh, OK. Well, here's where I think the weaknesses. Let me go look at that real quick and see if that weakness is, in fact, exploitable.” And that's why white box testing is so much more effective if the goal is to find your issues and then ultimately improve the security of the system.
Joe Colantonio[00:17:32] Interesting. Most people I talked to TechOps with the approach the black box, like you mentioned from an engagement perspective and then they just give a report and say, “Here's your vulnerabilities, go at it.” But it sounds like white boxes, definitely say white box is more common is that maybe I'm not talking to the right people, whereas black box, which one's more common? I guess you see in the industry people using?
Ted Harrington[00:17:52] Well, I'm sitting in a corner of the world where I am in the fortunate position that I get to work with companies that are progressive companies who are trying to actually level up. And so when I think of my client list and even prospective client list, they're all the ones who are like, “That's the right approach.” So in my little corner of the world, it's the majority. But in the broader sense of the world, it's still there's this misconception that still runs rampant. I mean, again, like, this is why I had to write this book was to try to advocate that I can only talk to so many people on a given day. But if I write a book and it gets into more hands, then maybe we can better advocate for this problem. And I would say that, yeah, the majority of companies in the world today are still pursuing black box because of that misconception where they think that, “Hey, let's emulate a real-world attack scenario. Have these organizations come in completely blind?” See what happens without realizing, though, that there's a lot of drawbacks to the results they might get. So if they in black box, if something is found, doesn't mean you found everything. If nothing is found, doesn't mean nothing exists. And all of the things that are found, there's no remediation attached to it, because since you don't know how the system works, you can't quite articulate or understand why a certain input caused a certain output. You just know that “Hey, that output was not good.” And that's really that's difficult for an organization because put yourself in the sort of the shoes of the person who buys that service. If their goal is to level up and to improve their security, understand what their vulnerabilities might look like, fix them, be able to articulate this ultimately to their customers, and say, “Look, here's why our security is OK. Here's why you should trust us to use our service or whatever. They don't get that from black box. They get something, but they don't have the proper context around it. And that itself is a real problem. And so just by changing the methodology, just by saying, “OK, well, we'll still spend the same amount of time and effort and money with the same type of expert.” The results fundamentally change because now in white box, when you get the results, the results of the issues they found that are found, you can have reasonable confidence that that's most or maybe even in some cases, all of them. And of course, all of this comes with the condition that you didn't cut the budget down to nothing, which is its own problem. That happens all the time, too. But assuming an appropriate budget, if you find issues, you can say, “Hey, we found most of the issues.” If you don't find issues, you can say, “Hey, that means those things are tighter than others.” And of all the issues you found, now, you could do something about it. You're actually handed the remediation steps. And that's really, really valuable to organizations whose goal is to improve the security of their solution and then also may be able to prove it to their customers or other stakeholders.
Joe Colantonio[00:20:35] And I think another misconception people have is the type of technique they use for security testing. This is another chapter, the security testing. Right. What tools to use or techniques. Once again, when I think of security testing or Penetration Testing, I don't know if that's the norm, I think probably a lot of companies are missing out like the front line, low hanging fruit, like a vulnerability scanner for their code that they're using, being checked in to the codebase. So how do you see what's the right mix? Do people focus more on one than another and how does that normally work?
Ted Harrington[00:21:03] Yeah, so the biggest challenge around this idea is the misunderstanding about the different terms even after. And so when I was writing about this particular problem, the way that I was approaching it was that there are multiple different things. They entail different investments of time and effort and money, and they deliver different outcomes. Yet they're often described the terms are actually used interchangeably when they shouldn't be. And so, for example, what I see most organizations are really looking for is and there are different goals based on different services, but many organizations, when they seek Penetration Testing and you're exactly right, that Penetration Testing is one of the most commonly referenced types of security testing, but it's not the only one and the three that are really focused on where that Penetration Testing is what many organizations wind up asking for the reason for that or a few, but it's of course, the one that has sort of been latched on to and nomenclature, a lot of regulatory bodies specifically require it. That's what they usually ask for. But they're usually sold something else. They're usually sold vulnerability scanning. It's presented as Penetration Testing, but it's actually vulnerability scanning and vulnerability scanning has a role, but it's not a Penetration Test. Those are two different things. And then the thing that further compounds it is that what most organizations tend to actually be looking for is more like vulnerability assessments and vulnerability assessments are more comprehensive and holistic views on all the different security issues, how they might all interplay with each other, how severe they actually are and how to fix them. And so the way that I approach this idea is this is already confusing for people who spend their profession doing it. All right. So how do I simplify that? And I thought about there's sort of a maybe a metaphor that can explain the three is I think about cars and Penetration Testing is kind of like when the automaker wants to understand how does a vehicle perform in a crash situation, they'll literally crash the car. So they want to see how does it deal with it head-on collision. They'll crash the car head-on into a wall. And that's kind of like Penetration Testing, right. It takes a very defined, specific scenario and it's trying to measure sort of binary outcome like did or did not X happen? And then it will actually run the simulation. And that's really what Penetration Testing is like. But it's just like with cars, it only makes sense for the thing that's already been through. All the testing is already built, right? Like you only going to crash test the car that is very far along. Like the car actually has to be built, like a lot of engineering has already gone into it. But when organizations are presenting a vulnerability scan as a penetration test, which happens all day long, like every Google search today of Penetration Testing is going to mostly spit back vulnerability scans. That's something different. And that's kind of like when the check engine light comes on your car, you go to the oil change place, they stick that little thing in the dash. It comes back saying, “OK, here's how you turn off the check engine light.” You have to do whatever. And that's kind of like vulnerability scanning. It's very easy, very quick, very inexpensive. It checks for the proverbial low-hanging fruit, but it's not the same thing as crashing the car into the wall. If those are two really different things and yet most companies actually tend to be looking for is they're trying to say like, “How do I make sure the passenger will survive?” And so that's more like the entire Department of Safety, Automotive Safety Engineering, which is like, “OK, how did the seatbelts work with airbags, with the side impact beams, with the roll cage, with the lane departure warnings, how severe are the issues that we identify and how do we fix all of them comprehensively?” And the point isn't that any one of those approaches is better or worse than others, but that they're different. And that's really critically important because if you think about the person who buys these services, they have a goal in mind. And that goal might not line up to whatever the service is that they just bought. And that is the thing that I'm trying to tackle head-on is say, “Hey, start with the goal, understand what you want to achieve, and then give the service that does that because these terms are commonly misused. And that in itself is a real problem.”
Joe Colantonio[00:25:03] I think another problem or misconception would be, all right, we did a written report on security. We went through compliance. We got Penetration Testing, vulnerability assessment scanning. We're done. But then two-week sprints, developers are adding more code, more infrastructure is being added over time. How do you know what is security testing has ever done or how do you make sure that you make security testing is always involved and you're just offered from the lifecycle? It's not just a one-off event every now and then.
Ted Harrington[00:25:31] Yeah, there's this VP of product for one of the very, very large tech companies that every single one of us uses. And I was before everything shut down with the pandemic, I found myself over in Amsterdam. We were both there for a conference. And we're having drinks at this cool bar there in Amsterdam. And he says this thing like, “Yes, that's it. It's so perfect. He says there's no finish line for security.” It's like, yeah, that is such a good way to think about it because a lot of engineering efforts do have a finish line. Right? It's like once we have these things, once its feature complete in these ways, we are done with this thing and we can now move on to whatever the next thing is. And so that's something sometimes a very difficult mindset for organizations to adopt that like, no, security isn't a line. It doesn't start at point A and then and a point B, it's a loop. Yeah, it goes from point A to point B, but then it loops back to point A and then you go to point B again and then you loop on itself. And so once organizations recognize that, that it's a constantly evolving process, just like any other part of your business that you're trying to get better. So training yourself, leadership development of your leadership team, how you improve really any department of your company, you're constantly working on how to improve it. And then once you get to that level, if you think you improved it, you're doing it again. You're never like I am now, the perfect leader like that just doesn't have I am now the perfect penetration tester. There doesn't have been and so that's what security is really like, is that it's this constant and relentless march in this sort of looping fashion-forward. It never ends. There is no finish line.
Joe Colantonio[00:27:04] And to tie this all up, when you first start an introduction, you talked about how security could be a competitive advantage. Then in the very last chapter, I think, is actually on can security be a competitive advantage to turn into sales? So I don't think a lot of people think of that. So I guess what are your thoughts on what is what do you mean by the competitive advantage of the security and how does it really translate into sales? Because it seems almost like a nonfunctional activity that has no you can't measure to say we did this, therefore, revenue increased by this.
Ted Harrington[00:27:31] Yeah, this was when I sat down to write the book. My focus at first was really on these first nine chapters that were about how do you actually do the security part? Right. But as I'm outlining it, I realized it's really missing a key piece because I started thinking about the kinds of companies who hire us. I'm like, “Well, why do they do that?” You know, what motivates them? Why does a company that is in some cases may be smaller by headcount or by revenue or in some cases some of the largest in the world, hire us. Like why? And for most of them, it really came to this point that it helps them with their business. So the sort of fundamental baseline is it's the right thing to do. I mean, anyone who invests appropriately in security is like I'm doing it because it's the right thing to do and I want to do it. But we don't live in this utopian society. We live in a capitalist society. And so you have to take the right thing to do and you have to figure out, well, what's the business reason for it? And really, as I looked at all these organizations that I'm fortunate to serve, all of them or almost all of them anyway, it's they're trying to seek this competitive advantage and think about what it means, like, “Why is security a competitive advantage?” I'm going to come back to defining that in a minute. But first, I want to address part of your question, which is this idea of like, can we measure it, it's nonfunctional, etcetera. Those are all real problems in the way that most people think about measuring success and security is there are two ways that you can measure anything. And security, typically, people only choose to pursue one of them. And the two ways to measure something is, did we avoid bad things or did we pursue good things? Now, that's, of course, a very like layman's terms way to think about it. But in its simplest sense, those are the things that every business is trying to do, avoid bad things or pursue good things. And most people think about security in the avoid bad things category, rightly so. The entire field of risk is about that, right? Like, well, if it's this bad of an impact if it happens, then is this likely to happen? And this is the result of how much money we should spend to try to reduce the likelihood it happens. That's avoiding a bad thing. But it becomes very hard to measure because now you're saying, “Well, we didn't get hacked. Is that because this investment worked or because we just dodged a bullet? We were lucky.” It's really hard to measure that. And I'm not advocating against that as a way to think about security, because fundamentally that is the way we have to still think about security. But the gap is that most organizations don't think about how security can help them pursue a good thing. And the case that I make is that and I don't really hear a lot of people talking about this, you're totally right, is that security helps you pursue a good thing, which is earning trust with your customers or with the community that you're trying to sell into. It helps you smooth the bumps along the sales process because think about what it's like in enterprise buying today. And I'm talking about a company that buys services or products from another company. It's a little bit different when you're selling to consumers, but many of the principles carry over. But a company, an enterprise who buys something from another company, they're expecting, they demand they want those services, those products. They want them to be secure. So that's where the buyers starting from. They say, “Hey, yeah, of course, I want the business advantages that come from this thing. But, you know, it really does. I really need to make sure this thing doesn't expose me. It doesn't hurt me by doing business with this company.” So that's the buyer side. The buyer wants this thing. So the buyer wants to let's just call that X. The buyer wants X. Yet most companies today struggle to actually give them X. Most companies struggle to secure their software solutions. And then even the ones who do really struggle to be able to prove it, they don't know how to demonstrate it. They don't talk about it. There's so much of this like, “Oh, we take security seriously. We use bank-level security, we use military-grade, like all this stuff.” That's like you're really not talking about security right now. And so think about those two things side by side. The buyer wants X. Almost nobody can deliver them X. If you can deliver them X, that's hugely differentiating. So being able to be in those buying conversations and make the customer say, “OK, these guys get it, they understand security, not just because they said so, but because of everything I'm seeing them demonstrate and show me and the way they talk about it and the depth and the level of rigor and the way they share information like all these things. OK, I feel more comfortable moving forward. Let's pivot back to how we can do business together.” And so that's a really, really powerful thing that most companies overlook. They try to shortcut it, right? They try to get right to the security benefit without doing the hard work of being secure. They try to, “Oh, yeah, we're secure, you're secure don't ask any questions, we're secure, we're secure now.” It needs to be a little more transparent than that, but it's an enormous competitive advantage. And most organizations are really not capitalizing on it yet.
Joe Colantonio[00:32:05] Great stuff. OK Ted, before we go, is there one piece of actionable advice you'd give to someone to help them with their security testing efforts? And what's the best way to find, contact you and get a copy of Hackable?
Ted Harrington[00:32:15] Yeah, I think the one actionable piece of advice would be to focus on this idea that we talked about it like what is the actual security testing that's happening? And really to peel back the layers, like, what are we actually doing? How are we doing it? And sort of do that own assessment of your own processes. Chapter three goes into great depth about this. If there's anybody out there who doesn't want to buy the book or is in a financial position, you can just hit me up. I'll send you that specific chapter. And the easiest way to get a hold of me is you can just head up my website, TedHarington.com. And if you need to figure out where to follow me on social media or you want to talk to me about us helping you with your security testing needs, you want to learn more about the book. Do you want to ask me to come to speak at one of your events? Any of that stuff? You can all find it at TedHaringtonDotcom.
Joe Colantonio[00:33:01] Thanks again for your security testing awesomeness and helping our friends at bitcoin casino sverige in the process. For everything of value we covered in this episode, head on over to testguildcom.kinsta.cloud/s49, and while you're there, make sure to click on the Try Today link under the exclusive sponsor's section. To learn more about MicroFocus Fortify, which is the recognized market leader in application security. And if the show has helped you in any way, why not rate and review it on iTunes? Reviews really do matter in the rankings of the show and I read each and every one of them. So that's it for this episode of the Test Guild security podcast.
Joe Colantonio[00:33:36] I'm Joe, my mission is to help you succeed in creating end-to-end full-stack security testing awesomeness. As always, test everything and keep the good. Cheers.
[00:33:45] Thanks for listening to the Test Guild security podcast. Head on over to testguildcom.kinsta.cloud for full show note. Amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.
Rate and Review TestGuild
Thanks again for listening to the show. If it has helped you in any way, shape or form, please share it using the social media buttons you see on the page. Additionally, reviews for the podcast on iTunes are extremely helpful and greatly appreciated! They do matter in the rankings of the show and I read each and every one of them.
