Hackable with Ted Harrington

Welcome to the Test Guild Automation Podcast where we all get together to learn more about automation and software testing with your host, Joe Calantonio.

Hey, it's Joe. And welcome to another episode of the Test Guild Automation Podcast. Today we'll be talking with Ted Harrington all about his new book, how to Do Application Security Right. 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 and 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 and counting. So listen up to discover how to do application right.

The Test Guild Automation Podcast is sponsored by the fantastic folks at Sauce Labs, the cloud based test platform that helps ensure you can develop with confidence at every step from code to deployment for Every framework, browser, OS, mobile device and API. Get a free trial. Visit testguild.comSourceLabs and click on the exclusive sponsor section to try it for free today. Check it out.

Hey Ted, welcome to the Guild.

Hey, thanks for having me. I'm excited to be here.

Awesome to have you. Ted, before we get into it, is there anything in your bio that I missed that you want the Guild to know more about?

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.

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 need to know more about?

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's 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 that's just not going to happen over a multi year process unless there's 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. This, 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 the sort of baseline context that I'm the kind of person who likes doing hard things and likes the challenge and you know, kind of always had a book in me. So like, 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, you know, 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 noticed that, you know, no matter the size, the revenue, the headcount, the market, they were focused on the problem. They were focused on all of these different companies. They kind of all struggle with the same thing when it comes to securing software systems. And once 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, okay, 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? I realized they were largely backwards. The conventional approach is the way that most people talk about addressing these challenges, in my opinion, and not just my opinion, just scientifically were incorrect. And that was when I said I have to write a book that addresses those misconceptions, 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 that's in here is like the exact same advice that we give to all of our customers.

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 towards like a uber geek security kind of expert. It's almost like anyone, you could give this to a CEO or to an engineer and I think both would get value from it. I just, I assume you wrote it from that perspective as well.

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, it was a really good distinction that you just drew. So you've got the, you know, the super in the weeds, technical, like the security nerds, right on one end. 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 the 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 have noticed this from reading it, but you know, I tell a lot of stories, a lot of metaphors. I really try to simplify to the core ideas. And the way that I did that was, you know, 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 the, what I call the technology leaders. So like a CTO or a VP of Engineering or equivalent, you know, those titles, whoever's responsible for security, the title's 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. 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. 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, okay, well, anytime I arrive at a concept that we might assume, you know, those of us who work every day in this might Assume like, of course somebody knows what this is. Of course somebody knows a cloud is. Of course somebody knows what penetration testing is. Does a 12 year old. No. 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, okay, I know exactly what 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 is people 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?

Absolutely. And I think sometimes when people think of security, they think of like it's a, like a specialty group in your organization that handles it. And you kind of demystify a lot of these topics to make it for the every person type 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 mindset. So what did you see about mindset that you saw from company to company that people were struggling with?

Yeah, what's really fascinating about that particular idea is that of these different problems that 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's 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 a few stories in here that were 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 to 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 winds up happening is anywhere a corner presents itself, that corner will be cut. It's like, you know, 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 10 reps and you're on like the 8th rep, no one's counting, you'd be like, that's Good enough. That's 10 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 10 reps. And that's sort of what's going to happen for organizations who aren't trying to actually get use security to get better. And that's a remarkable distinction between companies who get it right and those who don't.

So when you talk about security, is it from a compliance perspective? Because I know a lot of companies just go through the motion because they have, like, 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 type of security things like actually pen testing, do they should. Was it better that they meet with a partner outside the organization? How does that typically work?

Well, it's important to note that compliance and security are not the same thing, 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 a 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, 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 healthcare, you must comply with some of the healthcare regulations. Well that's a great example 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 in saying we're going to actually secure this thing and then as a result we'll 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 a, you know, 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, 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 it 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, 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. And 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 comes down to security is the objective. And you do it in partnership with an outside organization.

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. They're trying to push things earlier and earlier in the software development lifecycle. So across security, if it's not baked in to be secure, then at the end, the end result, how is it going to be secure? So you have a chapter on white box. Not white box. It's choosing the right, I think, assessment methodology. And you have white box versus black box. So what's the typical breakdown that you recommend for companies to focus their energy on?

Yeah, so this particular topic is definitely one of those ones where people, once they hear about it, they're like, oh, wow, I never thought about it that way. And this is one of my big soapboxes that I've always standed 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, you know, a company who's building, 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 box is one that on its surface sounds valid, but in, in 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, cause 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 box isn't 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 that I 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, you know, 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, you know, 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, you know, 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 knight spending 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 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, okay, 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.

And, you know, interesting. Most people I talked to take the opposite approach. They do 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 box is definitely says white box. More common, is that, like, maybe I'm not talking to the right people. Whereas black box, which one's more common, I guess that you see in the industry people using.

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 the progressive companies who are trying to actually level up. And so when I think of like 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 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 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 that output was not good. And that's really, that's difficult for an organization because put yourself in the sort of, the, 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 okay and here's why you should trust us to, you know, 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, okay, 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 that are found, you can have reasonable confidence that that's most or Maybe even in some cases all of them. Of course, all of this comes with the condition that you didn't cut the budget down to nothing, which that 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 this thing's 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 ultimately be able to prove it to their customers or other stakeholders.

Great. And I think another misconception people have is the type of technique they use for security testing. This is another chapter, get the security testing right, what tools to use or techniques. Once again, when I think of security testing, I think of penetration testing. I don't know if that's the norm. I think probably a lot of companies are missing out like the frontline, low hanging fruit, like a vulnerability scanner for their code that they're using, being checked into their code base. So how do you see it? What's the right mix? Do people focus more on one than another? And how does that normally work?

Yeah, so the biggest challenge around this idea is the misunderstanding of what the different terms even are. 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 I really focused on were that penetration testing is what many organizations wind up asking for. The reason for that are a few, but it's of course the one that has sort of like been latched onto in 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, 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 are 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, 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, right? So they want to see how does it deal with a head on collision. They'll crash the car head on into a wall. And that's kind of like a penetration test, 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're only going to crash test the car that is very far along. Like the car actually has to be built. Like you have 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 test is going to mostly spit back vulnerability scans, that's something different. And that's kind of like when the check engine light comes onto your car, you go to the oil change place, they stick that little thing in the dash, it comes back saying oh here's, 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. Those are two really different things. And yet what most companies are 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, okay, how do the seat belts work with the 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 get the service that does that. Because these terms are commonly misused and that in of itself is a real problem.

Great. And I would think another problem or misconception would be, all right, we did everything right without security. We went through compliance, we got penetration testing, vulnerability assessments, scanning, we're done. But then, you know, two week sprints, developers are adding more code, more infrastructure is being added over time. How do you know is security testing ever done? Or how do you make sure that you make. Security testing is always involved in your software development lifecycle. It's not just a one off event every now and then.

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, you know, cool bar there in Amsterdam. And he says this thing and I'm like, yes, that's it, that's so perfect. He says there's no finish line for security. I was 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 it's 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 in sometimes a very difficult mindset for organizations to adopt that like, no, security isn't aligned. It doesn't start at point A and then end at 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 constant 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 of 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. It doesn't happen. 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.

And to tie this all up, when you first started in your introduction you talked about how security could be a competitive advantage. And then your 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 do you mean by this competitive advantage of security and how does it really translate into sales? Because it seems almost like a non functional activity that has no, you can't measure to say, we did this, therefore revenue increased by this.

Yeah, this was when I sat down to write the book. My focus at first was really on these first, you know, nine chapters that were about how do you actually do the security part? Right. But as I'm outlining it, I realized, you know, 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 who is in some cases maybe a smaller by headcount or by revenue or in some cases some of the largest in the world, they 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 not functional, et cetera, et cetera those are all real problems. And the way that most people think about measuring success and security is there's two ways that you can measure anything. And in 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, and it's 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, you know, a company who 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 buyer is 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 and 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, 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 know how to talk about it. There's so much of this like, oh, we take security seriously. We use bank level security, we use military graded credit, 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, okay, 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, all these things, okay, 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, they try to get right to the security benefit without doing the hard work of being secure. They try to be like, oh yeah, we're secure, you are secure. Don't ask any questions, we're secure, we're secure. No, it needs to be a little more transparent than that. But yeah, it's an enormous competitive advantage and most organizations are really not capitalizing on it yet.

Great stuff. Okay, Ted, before we go, is there one piece of actual advice you'd give to someone to help them with the security testing efforts? And what's the best way to find contact you and get a copy of Hackable?

Yeah, I think the one actionable piece of advice would be to focus on this idea that we talked about of 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't just hit me up. I'll send you that specific chapter. And the easiest way to get ahold of me is you can just hit up my website, TedHarrington.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, you want to ask me to come speak, you know, at one of your events? Any of that stuff? You can all find it tedherrington.com thanks.

Again for your automation awesomeness. The links to everything of value we covered in this episode. Head on over to test guild.com a370 and while you're there, make sure to click on the Try for Free Today link under the Exclusive Sponsor section to learn all about Sauce Labs awesome products and services. And if the show has helped you in any way, why not rate it and review it in itunes? Reviews really help 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 Automation Podcast. I'm Joe and my mission is to help you succeed with creating end to end full stack Automation awesomeness. As always, test everything and keep the good. Cheers.

Thanks for listening to the Test Guild Automation Podcast. Head on over to test guild.com for full show notes, amazing blog articles and online testing conferences. Don't forget to subscribe to the Guild to continue your testing journey.