Security Confidential S14 E8 Daryl Donley

Manoj Tandon: Hello everyone, this is your host Manoj Tandon. Welcome to another episode of Dark Rhino Security Confidential. Today we are honored to have Daryl Donley join us. Daryl hails from our neck of the woods in Dublin, Ohio. He is a VP of Security and IT over at Outcomes. They’re a great medical company; he’s going to enlighten us a little bit about that. But he has a ton of experience. He’s been involved directly in the field of cybersecurity in many different roles as a tester, developer, and architect building end-user solutions. So Daryl is going to give us a lot of ideations on things that we should be looking out for as we are all on this journey to make our own environments more secure. And with that, in his spare time when he has it, he enjoys sports and enjoys tinkering with technology like blockchain and digital assets. So we’ll try and dive into some of those areas as well with him. But Daryl, welcome to the show. Thank you for being here.

Daryl Donley: Thanks, Manoj. It’s good to be here. It’s nice to be able to come on and talk with you.

Manoj Tandon: Yeah, absolutely. The pleasure is all ours. So, since we’re all in the same neighborhood—and it’s ironic I’ve not heard of Outcomes and we’re probably in the same zip code—if you could give us a little background about your company. What is Outcomes?

Daryl Donley: So, basically Outcomes is a technology company that builds software solutions in the healthcare space. So we have different solutions for end-user patients, for pharmacies, for manufacturers, and for Pharma. Where it really originated is a spin-off or a merger of two companies. In July of 2023, we merged from Cardinal Health. About 500 people was a business unit outside of Cardinal Health that merged with another company called TDS Clinical. And so now we’re right around 800 to 1244 people and coming together with similar synergies around focus on the patients and focus on making our healthcare system processes better through technology.

Manoj Tandon: That’s fantastic. So are you guys handling patient data then?

Daryl Donley: Yes, lots of patient data. We deal with it day in and day out on our platforms.

Manoj Tandon: So, unfortunately, you have a target on your back then.

Daryl Donley: Correct, yes.

Manoj Tandon: You guys are in a very high-risk sector.

Daryl Donley: Yes.

Manoj Tandon: And we’ll get to that in a second then. Let’s put a pause on that one. How did you end up in cyber then? You’ve done so many things; what was your journey like getting here?

Daryl Donley: My journey is interesting because, like you already said, I really started out as a software developer and computer scientist building software for mostly end users. We had the privilege of doing consumer-based type products. After I’d been doing it for about 18 or almost 20 years, we started building a security product, which was interesting because I hadn’t done as much. But I knew the basics and I was aware of some better engineering practices around building software. But really what kicked it off is my buddy and I went to a lunch and learn. We went to this lunch and learn probably really looking more for a free lunch than anything else. We were also interested in the technology; you know how that goes.

Manoj Tandon: Yeah.

Daryl Donley: And we’re there and the guy started hacking into his box and showing us all these vulnerabilities, of how easy it was to escalate privileges to get data that they didn’t need. My buddy and I looked at each other like, “Wow, this is interesting.” And so we went back to the office and, needless to say, within 45 minutes we’d hacked into about four or five of our systems that we used. We reported those. We’re good. We reported them to the companies and said, “Hey, we were able to escalate our privileges in 15 minutes on this product and this product.” But really, it really got me kicked off and gave me a passion around security from an application perspective, because as a software developer, you want to build quality software. So it really started for me as an education problem; this is an awareness problem. Because no developer I’ve ever worked with, including myself, would want to build software that was easy to get a defect or get a workaround. And so that really kicked off my passion and interest in how I help software developers understand security better.

Manoj Tandon: Wow. And now in your current role, are you still working with development teams in securitizing products?

Daryl Donley: Yep. So now, I mean, I have a team, but certainly as a technology company building software, it’s a good fit for me from that perspective. Now, obviously I have larger responsibilities and compliance, and over the years I’ve learned compliance and other frameworks and other things that are important. But still, if you get back to the root of my passion, it is really understanding software development. I like to build things, but I want people to build them securely. As an end-user consumer, whether it’s my PHI data that’s in our systems, or yours, or your family’s, I want it to be secure. I don’t want the bad guys to be able to get to it. And making sure the developers understand: “Hey, don’t just do the happy path; there’s a lot of bad guys out there or threat actors that are trying to get to our stuff and we’ve got to defend against them.”

Manoj Tandon: Yeah. You know, that brings up so many questions in this arena then. When you look at software development, there was an era, at least in my era, where we would actually write our own subroutines and we would use the standard C libraries—people even remember what those are. But from my era to today, things have changed so much. We now are using so much open source, and so many of the basic functions we’re just not even building; we’re just including them in. So how do you, when someone’s managing especially PHI and health information that there’s a lot of bad guys that want it, how do you manage that third party that you’re borrowing essentially into your development?

Daryl Donley: That ends up becoming a pretty big piece of what the work needs to be, right? Understanding your software composition and what all is getting pulled in when you’re building a project today. That’s something that’s really changed over the years. In the old C days and C++ days, I knew what I was including. I had libraries; I imported them very specifically. Now, with open source and Java and other things, you pull in libraries and you have no idea. There could be 150 different dependencies that get pulled in that really aren’t that easy to find. So we leverage tools that are out on the market—some commercial tools—but OWASP also has a dependency generator tool that also can help. So there’s some free tools out there too. But it’s important that you’re continually scanning your codebases for third parties and making sure you’re managing that and making sure the teams are looking at when to upgrade it—making sure they’re planning that into their sprints or into their software development process, for sure. And a lot of the bigger ones, too, we even watch the communities. We want to make sure the communities—as people are identifying stuff even before the CVEs get identified or put out into the wild.

Manoj Tandon: I guess that brings up the question of the role of threat intelligence in software development. I’d love to get your perspective. Is there—traditionally, threat Intel tools are very much viewed as a SOC item—but is there a real place for them in the software development world?

Daryl Donley: Yeah, I definitely think so, and I think it’s expanding. To your point, over the evolution of open source and using other third parties… in the older days, as you probably remember, when we used a third-party library, we would buy it. It was commercially available. You would buy it and roll it in. If you’re doing .NET, or before .NET, some C++ or some CD library, you’d buy it or you’d build your own. Whereas now, you’re going out on the web, finding a community and thinking, “Oh wait, this helps me do this.” And so people are leveraging that. Really, you need to be managing those communities as best you can as far as monitoring them, looking for reports on bugs and things, but also using other third parties because it could take a lot of time to do that once you’re using a lot more open source.

Manoj Tandon: So, the stakeholders—the folks that are writing the checks for some of these development projects—how do you get them to understand? There’s always this pressure of getting the MVP, the minimal viable product, out the door. But that may not be a very secure application. That could have dramatic impacts if it is the source of a breach on the profitability and future of the company. What has your personal experience been in that arena? Do these stakeholders understand, or is it still very much an item of friction?

Daryl Donley: I would say it’s still an item of friction. In the old days, it was always testing, right? “Hey, if we’re behind schedule, we’d start cutting out testing,” which is probably a bad idea—not probably, it is a bad idea.

Manoj Tandon: Well, I would say today that security is falling into that testing category. Like, “Hey, if I’m cutting time and I need to make up time, let’s quit doing some of our security tests or let’s quit doing some of this type of implementation around security and hardening.” And that’s a bad choice. It really varies from the culture. It’s really getting with the leadership and, interestingly, even for me, it’s getting with the managers—the dev managers that are working with the product teams—and getting them to really understand. “Hey, your code’s going into a product that’s protecting you, me, your family, and my family’s data. It’s important. They expect us to be protecting their data.” So this is not like an optional thing to do. It’s not like, “Hey, I can cut it anytime I feel like it.” It needs to be done. It’s part of building MVP.

Manoj Tandon: Yeah. You’re right, it’s so much about culture. But the one thing that I will say—and I’m looking for this exception—when push comes to shove, you’re absolutely right: it’s testing or security, or, “Just let’s include this component and then we’ll deal with it later,” right? As long as we can upgrade it. Or if it’s a website or web app, you can always update it.

Daryl Donley: That’s a conversation I have many, many times. There’s no silver bullet for how to solve that problem. It’s putting pressure on them, getting them to understand, educating them, and getting leadership to really understand the importance. Obviously, not to go into detail, but Change Healthcare adds a lot of information and visibility to the challenges they have. I wish them the best, but those help us in our industry to realize this is a real thing. This isn’t something that I’m making up.

Manoj Tandon: No. Trust me, given some of our experiences, you’re absolutely not making it up. And unfortunately, it comes to a head when things really go wrong.

Daryl Donley: That’s correct. And that’s too late, but that’s what happens.

Manoj Tandon: Another question here in that arena: what about reverting back to developing some of those libraries? I know it’s a pain, I know it would be, but then you would know the content of it and reduce your dependency on open source. Or is that completely a non-viable, dead-on-arrival idea?

Daryl Donley: I guess the conversation will come down to if it’s not your core business value. It ends up being a tough discussion because, “Hey, I want to spend my resources and my people’s talent on our IP, our intellectual property, or our real value as a business.” And so when these other things are out there, it’s too easy to grab them and start pulling them in. But it does add risk 100%. So pulling some of it in if it’s our value… more and more it’s, “Hey, here’s a library, let’s pull it in.” Which one should be pulled in, for sure.

Manoj Tandon: Then what about—the second part of that question is—there’s been talk in the federal government about having legislation that would hold the software developer accountable for a breach if it’s a result of their product, application, or embedded system, as the case may be? What are your thoughts about that?

Daryl Donley: That’s an interesting concept. Once the government steps in, I have lots to say about that. But would it raise the bar? Yes, potentially. But I’ll tell you what: the way teams are run today with their tight deadlines and business-driven deadlines, you would lose a lot of software developers because they would not agree to it. They would know better. It’s like, “Hey, I’m not getting proper time to build the software. I’m being forced from an environmental perspective to use it.” But I think it’d be very interesting if the government did that. It would be a huge change to the culture and the way we develop software. Guaranteed.

Manoj Tandon: Oh yeah. I mean, the implications are far-reaching. This has been talked about. They’ve been talking about it since I was coding, because they were talking about having government tests for developers—having them be more responsible, like a lawyer or a doctor. We’d have to carry liability insurance then. I mean, it’s just amazing to think. It would be a huge change.

Daryl Donley: Well, part of your hiring practices would be how much liability insurance you have as a developer.

Manoj Tandon: Yeah, sure. It falls in the area of malpractice, right?

Daryl Donley: It would end up there, yes.

Manoj Tandon: Well, I think the good news there is that, given the state of our Congress today, I don’t think anything’s getting passed anytime soon that’s going to be that controversial. But it’s certainly been discussed in committees. It’s been on the table. And I don’t know that our legislators actually understand the extent of what that would involve.

Daryl Donley: I would agree; very few of them do. Quite honestly, if you really want to get change, it’s probably—and I know there’s more that’s been happening around that—but board executives starting to get more liability around a breach or an incident. I know that’s a challenge, too, but they’re the ones a lot of times that are helping fund and picking. So making sure you’re getting proper funding and quality talent working on a product is important.

Manoj Tandon: Absolutely. So I want to get your thoughts on the general world of cybersecurity. Obviously, this is a top 10. What we run into is—I don’t know how many people even get the top three right, forget about the top 10. What’s the foundational issue, do you think, in our industry that’s still leading to so many breaches? We’re still not able to get the foundational hygiene in place. I’m not picking on you, by the way, Daryl; it’s a more general topic.

Daryl Donley: To me, I think there are two main issues. I think it’s education. I haven’t looked recently, but I did more research about 10 years ago when I was looking to go get my Master’s. The number of schools that even taught cybersecurity… now it’s changed a ton in 10 years. But even go look at how many computer science programs in college even teach secure coding. It’s increased a ton in the last five years, I would say, but even that is foundational. In school, you’re taught to get a lab done; you’re not taught to make good code or secure code. So that’s one area that to me is a big foundational piece: how we’re teaching our developers what’s the right thing to do. The second is really having proper time and leadership understanding it’s not an optional capability. Our consumers—whoever that may be, patients, hospitals, or just you and I using a mobile app on our phone—I expect it to be secure. And so it’s not an optional requirement. Why would I—if you put an app in Google Play for my Android and said, “Yep, this app is insecure”—well, I wouldn’t install it. I don’t care if it was free or not. I would never install it.

Manoj Tandon: See, I think you’re probably an exception though, Daryl. I bet you a lot of people would install it because…

Daryl Donley: Well, you’re right. You’re right. It’s once again from the consumer… I guess if we made it more public that it wasn’t secure. I think more and more the media is doing marketing to the general public. I get more and more questions from just general people around security now than I ever did.

Manoj Tandon: Но you’re right—if it meets my needs, people want convenience over security, that’s for sure.

Daryl Donley: That’s right. No, but I think this is partly the challenge we have as a security industry: people want convenience over security. So I’ve always told my teams we need to make the “easy button” the “secure button.” And I know that’s not always easy.

Manoj Tandon: It’s a challenge, but security and usability don’t always have to be contradictory.

Daryl Donley: No, it doesn’t, but it adds a time factor and a cost factor.

Manoj Tandon: Exactly, to do it right. Yes, 100%. Но even there, there is a point of diminishing returns. Daryl, my data on this—having developed very specialized tools way back in the late ’80s and ’90s… that is dated beyond belief. Security at that point in time was never really a big concern for us. We wrote that stuff; it just wasn’t there. I was oblivious to security 20 or 30 years ago. In general, it was more about defensive programming; that was the term. Make it hardened programming. It wasn’t really “secure,” and they’re not the same thing. They’re similar, but they’re not the same thing. But if we go back now and we revisit some of that code—because there’s still DOS code in the Microsoft operating system…

Daryl Donley: That’s it. Scary.

Manoj Tandon: If we go and address that, where’s the point of diminishing returns? Because how much time and money do you invest in it? Foundationally, it seems like… I would argue that if it’s developed by a human being, it’s foundationally flawed because we’re not perfect beings. Everything we produce has some flaws in it. Right. So as a result, where is that line? At what point do you say, “Okay, it’s secure enough given the current threat levels?” And how would you assess that risk?

Daryl Donley: Well, I think you have to address it based on risk. Just like any other defect that you fix or don’t fix in your code, it’s risk. Whether I’m fixing this button, the way it looks or the color… that’s a risk the customer is going to complain. Or if I click that button and I can do a SQL injection because of it, that’s a risk. Way different levels of risk on those two incidents. So you need to look at it from a risk perspective and talk through it. But I think having that discussion is difficult today if people don’t even understand the implications of security or understand what is good security. Because, to your point, it’s never going to be 100%.

Manoj Tandon: No.

Daryl Donley: I know there are some philosophies out there where you can do mathematical formulas and more scientific engineering methods. There are ways to do it, but even then it’s flawed. There’s always going to be—if humans are involved—it’s potentially flawed.

Manoj Tandon: I am so glad to hear you concur on that. I think the public has that misconception. I know a lot of our listeners don’t, but if a layperson is listening: there is no such thing as 100% cybersecurity.

Daryl Donley: Exactly. Cybersecurity is a tough road because it only takes one flaw for them to get in. I could have 99.9% of everything covered. It only takes that 0.1%—one little line of code that someone made a mistake on—and they’re in.

Manoj Tandon: Exactly. And you may never even find it during your own testing because it’s something so esoteric that you wouldn’t normally think of it in the QA process.

Daryl Donley: Correct, yep. That happens a lot; that’s pretty common because you’re never going to test everything.

Manoj Tandon: No. Just like functionality, you’re always going to miss pieces and edge cases on functionality. But they could turn into security incidents. And the other side, the bad guys… they’re probably the ultimate QA testing department, because they’re going through not just your code, but everything surrounding it. They’re looking for a break in the process somewhere.

Daryl Donley: Just somewhere.

Manoj Tandon: They’re looking for a crack. So it’s not 100%. And I’m glad—thank you for concurring on that, because that is something that we get a lot: “Well, why don’t you guys just make it secure?” Even for us, we’re a managed security services provider, and we actually put it into our contracts that it’s not 100%. Nobody can get to 100%. But at least in our instance, the goal is to make it so difficult that the bad guys are like, “Well, there are enough other companies like this; let’s go find somebody else.”

Daryl Donley: That’s what layers of defense bring into play, right? You have to have layers and layers upon layers. And software development is the same way. You need layers. Some of those are infrastructure layers, but some of those layers need to be in the code themselves.

Manoj Tandon: So, let me—that’s a good segue into another area I’d love to get your feedback on. I don’t know if you’ve seen the SANS Institute’s investment scale on cybersecurity, where they have prevention on the left-hand side and they recommend everybody starts on the left-hand side, and then they go to the extreme right with proactive cybersecurity. Keeping in mind that a lot of people who listen to this are small-to-medium businesses with limited resources, where on that continuum do you make your biggest investments? What’s the best bang for your buck to create a secure environment? What would your advice be to folks?

Daryl Donley: It’s hard to make a stereotypical answer because each business is a little different. That’s where I would evaluate it and really want to understand your risks. But I would agree you should start on the preventative side and start building up your foundation. And then, whether it’s compliance or your response team, it’s what your business is where you’re going to focus first. Whether you’re a software development company or not… if you’re not a software development company, maybe it’s your vendors that are your biggest risk, and how do you build up your vendor process and program? The right level of spend in each area is not the same for everybody, even in healthcare. I don’t think it’s the same for everybody. You have to decide based on your risk and what your clients expect, but also where the risk for your business is.

Manoj Tandon: So would it be okay to paraphrase and say maybe you don’t want to start with the technology first? You need to kind of get your house in order.

Daryl Donley: 100%. Technologies are always helpful, but if you don’t have a good process defined, if you don’t have administrative controls first, putting technologies behind those isn’t usually very effective. Throwing technology at a problem doesn’t solve it. Usually, if they’re not implemented properly, or if there are not processes around to handle what you find in your technologies, they’re frivolous. You’ve got to make sure you’re hitting all three: from a control side, people, process, and technology.

Manoj Tandon: In your own career, then, can you give us insight into a particularly challenging security problem you’ve encountered and what you have done with it?

Daryl Donley: Which one to pick is a good question. I think one of the biggest ones I’ve been running into for the last 1244 years is really around more of a single pane of glass. As I’m working with the security team and the development teams, how do I get to a single pane of glass to have a clear message? “Okay, you built this software; here are the vulnerabilities that I’ve identified through tools, testing, pentests, you name it.” What are the most important three things that you need to fix in your next iteration? Getting to a single pane of glass… where all the tools, processes, and outputs are disparaging and have different kinds of data. It ends up being a bunch of manual steps to bring in the data and show it. To me, that’s one thing I’ve been dealing with for over 10 years—really probably close to 15 years. Trying to narrow it down, because the development teams are used to a single backlog—a single set of storyboards or cards I’m going to work on; here are the requirements. Well, security hasn’t done a great job of saying, “Yep, here are the five things you need to do.” There’s more, but here’s your top five; go fix these first. Because there are so many different tools that give them information, they get overwhelmed. So a lot of what I’ve spent time with is consolidating that information by risk and saying, “Okay, here’s 1A, 1B, and 1C. Do these three things. You need to know how to do it; let’s talk about it, but here’s what you need to fix first.”

Manoj Tandon: When you said you do it by risk, are you getting everybody on the same page with risk, or is that something that’s done more in isolation?

Daryl Donley: Currently, it’s more done in isolation. Over time, we’ve matured the risk program a little bit more to help them get input on it. Но in general, when I first start working with the team: “Okay, there’s 150 things: critical, high, medium, low.” It’s always about, “What’s the top three? What’s the top five?” I found that development teams—any team, really—as you’re working, you only need two or three things. Focus on that, get that done, then let’s go to the next layer. Giving them 50 things overwhelms them and they start spinning out of control. They don’t know what to do.

Manoj Tandon: Do you see a role for AI in solving this problem?

Daryl Donley: I do. I definitely think AI will help. I think it’s more about common export formats, and AI can definitely help for sure.

Manoj Tandon: What about on the QA side? Do you see changes happening there with AI?

Daryl Donley: Yeah, that’s interesting. I think QA definitely can be… AI can do a lot of different things. I mean, you still have to train it and be very clear. Honestly, even just doing development testing—writing unit tests as you’re writing your code—just some of the culture changes that have happened over the last few years on that. People are writing test-driven development, where they are writing their tests first even before they write their code. Those things could help and really start getting people to think about what the output should be. And really the other big thing that I talk about when I talk to teams is, once again, back to our training. At least when I was in college—and it’s been a while—it’s more about the happy path. It’s always about the happy path. So really get with a team and talk about what’s the malicious path? What’s the error path? You need to be thinking about these because this really happens. If you don’t include those in the happy path, your code is not going to hold up to some kind of attack.

Manoj Tandon: Oh boy. What you just said… that’s a big problem. That’s part of our training, that’s part of the culture, that’s part of time—there are lots of pieces to that. And this is where I’ll go… I’m on the advisory board of some universities in their computer science department, and one of my things that I’ve been trying to get people to listen to about this is: it’s not just enough to teach good coding, but we need to be teaching about the mind of the bad actor. What are they thinking about? How do they think when they’re attacking code?

Daryl Donley: Correct.

Manoj Tandon: To date, the only organizations that I’ve seen that actually have a really good program around that are in our federal agencies. Those guys are absolutely into psychological warfare, understanding what’s going on. “How would we be compromised, and how would we compromise someone?” Но that’s not a part of any university program right now, at least in the 48 contiguous United States.

Daryl Donley: Interesting. See, that’s too bad, because I use threat modeling exercises for that.

Manoj Tandon: Really?

Daryl Donley: Yeah. So, a lot of times I’ve done tabletop threat modeling exercises. Not always a lot comes out of it from an output other than it’s really a training exercise to bring the whole development team in and talk through exactly what you just talked about. “Okay, let’s map out your data flows. Okay, what I’m gonna do is I’m a bad actor. I’m gonna try to get to that. Can I do it? I’m going to start attacking your thing in different places. What are you going to do? How’s your code going to react?” And then asking them, “How would you attack your code if you knew you want to get to this piece of data that’s critical, whether it’s a key or password or PHI—whatever it is? What’s valuable in your system? How would you get to that if you were a bad actor and wanted to just get through it?” And a lot of times they can tell you. It’s like, “Oh, we know we have this skeleton over here. If you do this, you do this.” Yep. I’m like, “Okay, there’s a threat. That’s a problem.” That’s what a threat actor is going to do. They’re not going to do the happy path and be nice.

Manoj Tandon: No, not at all. They’re going to be thinking very laterally—

Daryl Donley: Correct.

Manoj Tandon: —in order to move laterally, and very complex too.

Daryl Donley: Oh, absolutely. These technical problems are not trivial.

Manoj Tandon: But correct, then the adversary is not your run-of-the-mill criminal either, right?

Daryl Donley: Correct, right. I mean, these are trained people. This is their profession. That’s what people… the other thing that good education should talk about, right? In a lot of places these are their profession. So think about it: if your profession is to attack software, how would you do this?

Manoj Tandon: Well, you have thousands of PhDs at the GRU in Russia who wake up every morning to find flaws.

Daryl Donley: Yep. I mean, that’s a hell of an adversary to go up against.

Manoj Tandon: Bingo. Yep, for sure. And their job is to break it.

Daryl Donley: Correct.

Manoj Tandon: Well, you know that you’ve… could you put a college curriculum together around that topic?

Daryl Donley: I don’t know. I haven’t thought about that. I thought a lot about it. We need it. I haven’t thought about that level potentially. That’d be interesting.

Manoj Tandon: I could definitely get you an audience if you could. Because this has been a passion of mine personally, is getting, like I said, into the mind of the bad actor.

Daryl Donley: Correct. Yeah. Well, I think like you said, one of the root problems is the education and we’ve got to fix that. Not that that’s going to solve all the problems—it’s not—but at least people coming out of our education programs will be aware of bad actors, be aware they’re out there, how to defend against them. And obviously it evolves, so you’ve got to keep learning, but that’s a huge win to be able to give them… they even know that exists.

Manoj Tandon: I mean, what about end user behavior in all this, right? I mean that’s a big gap as well. That creates… a lot of times when code is being developed, I’m not sure that the development team has a view of how a user is going to interact with it, but they really don’t know how they’re going to interact.

Daryl Donley: Yeah, yeah, I would agree. I would say that’s one thing we’re doing. One of our philosophies with Outcomes is to get more exposure to development teams on how users are actually using their software, which is very important. It really helps enlighten them. Not just product managers—product managers as well—but the development teams themselves want to sit there and watch people use their software. That’s a very interesting thing that used to be more traditionally just UI/UX usability experts would do that. And so now it’s expanded like, “Hey, you need to understand how they’re using it so that it helps you really connect in how you’re coding it and how you’re making the workflows and things like that.”

Manoj Tandon: Makes sense. Yeah, and find gaps because you know what the user is going to—

Daryl Donley: Yep.

Manoj Tandon: —find a way to get their job done, right?

Daryl Donley: Period.

Manoj Tandon: Efficiently, efficiently as they can, I mean, over time.

Daryl Donley: Yeah, and they’re not going to let technology get in the way of it, right? They’ll try the shortest path. If it doesn’t work, then they’ll—

Manoj Tandon: Yep.

Daryl Donley: —try plan A, B, C, D until… and you see it all the time where end users discover gaps. “Hey, you know what? If I click this and do this, it actually lets me in and lets me shortcut this.” And maybe that was never a spec.

Manoj Tandon: Yep, exactly right. Yeah, definitely used to be with special key combinations or things like that in the old Windows desktop days or a desktop app. It was like—

Daryl Donley: Yep.

Manoj Tandon: —wait, you have that shortcut? They’re going to use it. Boom, they jumped three screens. I would bet you a dollar, Daryl, that there’s probably still key combinations and things like that that you could find in software that’s floating around there.

Daryl Donley: Oh yeah. I just look at SQL injection. We’ve known about that forever on websites, right?

Manoj Tandon: Yep.

Daryl Donley: 1998. How many—just reading of the breaches—how many SQL injection hacks have we even seen in the last year? Forget about the last decade.

Manoj Tandon: Yeah.

Daryl Donley: So it’s still happening, right? And that’s… yeah, exactly. That’s really—I use that as our litmus test of like, “Hey, we’re not where we need to be.” 1998—was it discovered over 20 years ago and it’s still happening? And it’s really not that hard to remediate if you know what you’re doing. It’s really not that hard to remediate.

Manoj Tandon: Yeah, but you have to do it very deliberately and do it right.

Daryl Donley: Yeah.

Manoj Tandon: Not hardcode certain things into your code you’re passing into your database.

Daryl Donley: Correct.

Manoj Tandon: I’m not going to get deep into it, but another thing on the reporting of bugs and vulnerabilities: one of the things we’ve seen in the state of Ohio, the Secretary of State’s office actually gives you leeway that if you hack them and you tell them how you hacked them, they won’t press charges. They won’t press any charges, right? Is that generally a good idea? Is that something more of a policy position we should adopt across the nation? That says, look, if you find a gap, report a gap. Because right now if you go to the TSA website and you go hack it, well, you’re going to jail, right?

Daryl Donley: Right. The problem—yeah, it’s interesting because you certainly need… the more testers we can get, the more eyes, the more creative people, the more you’re going to find. And so yes, we should encourage people to report them. Obviously, the problem is thinking at the other side of it is now I’m trying to defend that website. How do I know it’s a good person or a bad person trying to hack into me? And so if they go ahead and get in and don’t report it, now what do you do? So I don’t know, it’s just an interesting behavior to potentially reinforce.

Manoj Tandon: Okay, so if they’re not a good person and they get in, I mean how is that different from an incident response plan today, right?

Daryl Donley: Yeah, it’s true. I guess treat them like a threat actor and issue them, right? And then all of a sudden… like they come…

Manoj Tandon: Yeah, I don’t know. Yeah, it’s interesting. But I agree with you that more eyes, more creative people are going to find more things and so we should definitely incent them to report them effectively. Yeah. I mean right now in so many industries, like I’ll pick on the legal profession for a second, those guys don’t want to know if they necessarily have a lot of vulnerabilities in their environment because once they know about it and they don’t correct it, they’re liable by default. Whereas we met all the compliance checks, right, and we have proper procedures that were followed.

Daryl Donley: Yep.

Manoj Tandon: Yeah, but once again just because you don’t know about it doesn’t mean you’re not vulnerable.

Daryl Donley: But yeah.

Manoj Tandon: But it’s certainly from a liability… it changes liability. It changes… that’s right. And is it any different on the healthcare side?

Daryl Donley: Not really. But instead, the other side with HIPAA, HITECH out there, I mean we’re… I mean you’re still… I mean you still have that regulation you’re dealing with. So if someone does disclose information through a vulnerability or something, you’re going to be dealing with that anyways. It doesn’t matter if you knew about it or didn’t know about it. It happened; you’re going to have to deal with it.

Manoj Tandon: So a little bit maybe. Daryl, how do we get compliance to actually benefit security?

Daryl Donley: Like I would argue that it does benefit some to a point. This is the challenge. To a point it definitely benefits because it can raise the bar. It can make a common ground on the bar. The other challenge, the other side of it, is it can potentially also be twisted as “good enough” and it gets confused with security. So that’s the challenge. Compliance and security are not the same thing. Do they overlap? Yes. The biggest thing that I’ve seen compliance do in my career is really help up the bar on processes—really around documentation of processes and more administrative controls. How effective some of the technical controls are—yes, it helps some. But once again there’s a diminishing return. You get to a point and then after that you’re more focused on the compliance than on what really security is.

Manoj Tandon: That concurs with our experience very much so. And that’s why it’s tough when the government has to step in or do something. It helps raise the bar initially, but overall it ends up being not as secure in the end. Yeah, because you look at all these… look at all the major corporations that have been breached. I can assure you that every one of them met every compliance that—or they definitely have reports that prove that they were compliant to whatever standard they could get through an auditor. They get through an auditor.

Daryl Donley: Yep.

Manoj Tandon: But a hacker still gets in.

Daryl Donley: Correct. And yeah, and it’s back to I could protect 99…. and it’s only that 0.1 thing that’s not protected the hacker finds and gets in. That’s the diminishing returns. That’s a tough…

Manoj Tandon: Yeah. In the medical world, do you… if we were to categorize breaches as those being caused by technical vulnerabilities that have been exploited versus social engineering, where do you think that balance lies and where is it going in the future? And I’ll give you the example like you know, Okta recently—they had a breach, or not, it was MGM I think—they had a breach and it was the help desk. That was socially engineered. It had nothing to do with the software per se. It was a process hack, right? So where do you… on that threat landscape where’s your experience saying this is going to go?

Daryl Donley: I think that’s a great question. And I’m just… so I think with AI and all the deepfake stuff, I think that’s going to be our next challenge for social engineering. I think it’s already—not even “it’s going to be”—it’s already started.

Manoj Tandon: Oh yeah.

Daryl Donley: So you’re really going to have to have lock down—and we’ve even looked and started reviewing some of our processes around how would we defend against that? Would our processes hold up against that? Because you’re going to see that more and more, right? As they’re doing… I mean the typical scenario is, yep, you know, your grandson’s on the phone saying, “I need money and I’m in somewhere in some country that can’t get out,” to his grandmother, right? And I need that money, and it sounds exactly like him because they have his voice faked. So what do you do to that? That’s a tough problem when people want to help, people want to do the right thing, but they have to have very tight processes and follow them always.

Manoj Tandon: Well, there was that bank in Hong Kong where, over a deepfaked Zoom call, the fellow sent $25 million of the bank’s money, right? So not only did they fake the voice, they actually faked the video.

Daryl Donley: Video, yep. I guess $25 million reasons is a lot of good reasons to…

Manoj Tandon: Yeah, exactly. I mean once again the money drives the solutions. I mean they’ve… so you know, it’s interesting. I think… I mean obviously technical vulnerabilities are still always going to be there. You’re always still going to have to fight with them. I would say even some of this in my thought—once again, I don’t know—some of the third… you know, some of the other nation states, some of that’s a little more challenging for the social because their accents are already common dead things like that, so you may be easier to defend against it. But the AI stuff that’s going to come out is going to be the tough stuff, tougher stuff. And then there’s always going to be technical vulnerabilities because there’s no, like you said, like we started out, there’s no 100% secure software. So you have to look at mitigating controls all around it and build software throughout to be secure as possible.

Daryl Donley: Absolutely, yeah.

Manoj Tandon: Well, Daryl, we’re coming up on the hour. We want to give you a couple minutes to talk about whatever it is, plug whatever it is you’d like to do. So you know, you have the mic. I’ll stop asking questions. Let our listeners know whatever you’d like to let them know about.

Daryl Donley: Yeah, I don’t really have anything special specific. I mean to me it’s still, you know, this is a great industry to be in. It’s still… we’re chasing our tails a bit. We’re not mature as we need to be to really defend against the threat actors. We need to keep plugging away. And I always tell my team this is a marathon. There’s short sprints within that marathon always, but we got to keep fight… running the race and continue the marathon, you know, protecting your company, protecting your person every day when you get out of bed. And that’s what it ends up being. So keep fighting.

Manoj Tandon: Now, Daryl, do you participate in the Columbus B-Sides or any of the local conferences?

Daryl Donley: Yeah, I have some, yep. I have ISSA things like that and some of them, yeah, over time as time permits, I do. Yes.

Manoj Tandon: That’s the key part. Is there any that you’re going to be appearing at or if someone…

Daryl Donley: I’ll be at the Central Ohio ISSA here in May. I’ll be going and also I’m going to be on a panel, application security panel.

Manoj Tandon: Oh fantastic. If anybody in our audience wants to hit you up with anything, what’s the best way to reach you?

Daryl Donley: Yeah, I’m old school. I’m not on social media. So I’m still… so yeah, I mean you could send an email or hit me up on LinkedIn is probably the best way. Hit me on LinkedIn. It’s probably the best way.

Manoj Tandon: Okay. Where is really the main social media that I use. And speaking of social media, I do want to take this moment to remind all our listeners that if you like what you’re hearing and like what our show does, please hit the like and subscribe button. Let us know about it. We know we have a large audience, but you just got to reach with your hand and click that little…

Daryl Donley: Right.

Manoj Tandon: That little button. Bump it up. But Daryl, it’s been a pleasure. I would hope, as time goes on here, you’re always welcome back. Anything that you want to let our audience know about, would love to share. Thank you for doing this.

Daryl Donley: Yeah, awesome. Thanks for inviting me. It’s nice to be on and chat with you about some pretty important topics.