[00:00:00] Rob Aragao: Well, welcome everyone back to another Reimagining Cyber episode. Rob here joined by Stan and Stan, we're just coming off of our Thanksgiving break. I had a wonderful time spending with the family, ate a little bit too much, of course, as always how does yours go?
[00:00:16] Stan Wisseman: It was different this year. We I, a , you know, and others may not, but I moved and so it was a different setting, but it was a very nice affair.
[00:00:24] As you say, we ate too much food and then, you know, you have the leftovers over the next few days. And then you're like, Okay, that's enough of Thanksgiving food until next year, right? I don't know about you, but it's always the same with me. It's like, you really enjoy it, but after three days of eating the same thing, you are done.
[00:00:43] Rob Aragao: I think it's also why I only eat turkey once a year. So, yeah, you get sick of it over that three-day span in essence, right? So, hey, so... I know that you were at a recent conference, you had? The Gartner conference, right, right. And you were telling me that you had an [00:01:00] interesting conversation.
[00:01:01] So why don't you kind of take us through it a little bit? So, yeah,
[00:01:03] Stan Wisseman: so I was speaking to a number of different customers, and this was an event that had a lot of CIOs, and I had an opportunity to speak to somebody about what they're doing for application security testing. And they're applying a single method, static, so we'll be throwing around some acronyms, right?
[00:01:21] But SAS, Static Application Security testing, they're doing that. And he seemed satisfied with just using that approach. And it mystified me because this day and age, I think most organizations see the value of having multiple testing. Do you remember the old Indian parable where a group of blind men sort of examine the elephant from different perspectives and each one has a different, you know, fragment of the animal.
[00:01:51] Somebody has the tail. Somebody has the trunk, somebody. And so they have different perspectives, and they have different answers as to what they're [00:02:00] they're sensing, right? Because they don't realize it's the whole, It's an elephant and it's sort of the same thing with testing as far as, you know, what it is that you're evaluating.
[00:02:11] You have to do it in different ways.
[00:02:14] Rob Aragao: You know, that's a, that's a great analogy, Stan. I never thought about that using that parable, but it's true, right? Because people do look at things kind of as individualized components. Or the elements that they're only responsible for and don't really consider and in some cases care, right, about these other components when they come all together, what the end solution is, right?
[00:02:33] And the security issues that that could actually bring forward. So that's a, that's a good way to kind of describe it
[00:02:39] Stan Wisseman: I mean, I think the broader picture of what we're trying to do is, is we're trying to ensure that the, in this case, the attack surface of your applications are not more apt to be vulnerable and breached.
[00:02:57] Right? And so if you look at that cost benefit [00:03:00] analysis of, you know, do I put in the cost to actually put these measures in place into my software development life cycle and ensure that I'm testing the applications in the pipeline or not even in the pipeline in legacy, but they're running, right?
[00:03:19] Getting that handle on the elephant and having visibility into the risk, is it worth that expense versus the direct costs of a breach? And you've, you've done a lot of analysis, and I know you've done things with Ponemon Institute and looking at the cost of breach, I mean, it's not cheap?
[00:03:37] Rob Aragao: No, I mean, you, you think about that, right?
[00:03:39] Kind of the latest findings is the, the average about just over 4 million, right? As
[00:03:44] Stan Wisseman: right. I think that's what the last report was.
[00:03:47] Rob Aragao: Right. And so, yeah, I think it's, it draws a really kind of interesting perspective, though. Maybe it's a good thing to kind of start for the audience in a, a simple comparison.
[00:03:58] And I, you know, this, this is an area you've [00:04:00] done a lot of work in, but a simple comparison, kind of how do you compare and contrast static versus dynamic, right?
[00:04:05] Stan Wisseman: So let's do that. So again, you know, there, there are two main approaches that people typically talk about static application security testing, SAST, and dynamic application security testing, or DAST.
[00:04:18] And at the top level, you can view it as static as being inside out analysis, because you're looking at the source code and it's more of a white box testing technique as a result. And then dynamic testing is a black box or outside in kind of approach. You're running tests on a running application and, you in a static analysis, you do need to have that source code and the engine that you're running your static analysis with has to be able to be aware of that.
[00:04:56] The framework or the language that you're running the test on [00:05:00] for that, that application source code, right? Whereas in the context of dynamic, you really don't have to worry about what it's written in. You're running on that. You're running tests on that running application, and it doesn't necessarily need to have awareness of the language.
[00:05:16] Now, part of the challenge there is also when you're doing static code analysis, you know, you are able to get down to the line of code where you're finding that weakness or vulnerability, right? Yeah. But whether or not that is actually exploitable is then the question. And sometimes that back and forth you have with the development team, great, you found a buffer overflow, but is it really accessible
[00:05:42] to somebody being able to do a trampoline attack or some kind of attack vector into that portion of the app that's instantially to that vulnerability. Whereas in dynamic, you really don't have an argument. I've been able to exercise that app that's running and I actually have been able to demonstrate there is a SQL [00:06:00] injection vulnerability.
[00:06:01] However, I may not be able to tell you where in the application and that line of code, you'll find it right. And the other challenge with dynamic. testing sometimes is that, hey, I can't necessarily, you know, crawl the entire application and scan the entire application, you know, so it’s that coverage question of did I really cover everything?
[00:06:25] There are advantages of them doing both, you know, so if you can have a low false positive rate with dynamic scans, right? But high confidence of coverage for your static, and then you can blend the two, have a hybrid. That's really advantageous. And that really shows in the context around API testing.
[00:06:46] Of having advantages of, with your dynamic, you're able to crawl your app and discover the APIs that are being exercised and used. But then in the static, you're actually able to do data flow analysis [00:07:00] and find some types of attacks could be exploited there.
[00:07:04] Rob Aragao: And I think, you know, you kind of alluded to this too.
[00:07:06] It is that bit of comparison where with static, right? You are working much earlier in development process to identify the security vulnerabilities, whereas dynamic, it's obviously closer towards kind of that point of Give me that stamp. Let me know It's good because then it's going to go out and get released. it's a fine balance that you're having to kind of, you know, manage as you're figuring out what makes the most sense for your particular program.
[00:07:31] Stan Wisseman: I mean, classic dynamic tests are typically run late life cycle, like you said, and they're typically by the, you know, , the quality team or again, the security team is validating could be part of a pen test and part of this, you know, some kind of discovery process
[00:07:49] of just using dynamic tests to be able to do that discovery to see what potential vulnerabilities are they could exploit in the pen test. But and the [00:08:00] other challenge has been historically, they take a long time. You know, if it's a very large application, it could take a long time to scan the way the scanners are working now and the way you can also link it to functional tests.
[00:08:10] you can actually, though, shift some of these dynamic tests earlier in the life cycle, and so, you know, functional application security testing fast is something that's some you're linking your dynamic test to a functional test script and this scanning that portion of the code that is actually being tested for functionality as well.
[00:08:31] And you can integrate that in earlier in the life cycle. So that's something that's changing the perception of where DAS can be used.
[00:08:40] Rob Aragao: And doesn't that lend well to his, this kind of shift that we've been seeing where, you know, developers, do you want to have a little bit more control of that security kind of testing aspect too? The functional testing QA and all those elements have always been traditionally part of the dev QA environment.
[00:08:56] And then there's been this kind of application security testing team that has been separate. [00:09:00] And sometimes, you know, there's friction there. Now, this brings it forward. It allowed them to actually, as developers, you know, and as they're coding, have the opportunity to identify where the security defects, are and fix them on the fly, so it'd be that much more efficient and then also making the security team happy at the same time.
[00:09:19] Stan Wisseman: I think one of the things that's happened in the last few years is in this recognition. We're no longer necessarily fighting the fight of you have to do security testing of your applications. That fight has been won, and the governance process in place many times is requiring the dev teams to do security testing.
[00:09:38] But to your point, what they need to do is then figure out where in their DevOps workflows they integrate in this security testing, and how do you reduce the friction to your developers, right? You want to do this in a way that allows them to get the results quickly in the tooling that they expect. And, [00:10:00] and again, I think that balance of, you know, velocity of dev with the need to ensure that you're, you're testing your applications thoroughly.
[00:10:10] I think another analogy that we had back in I think it was episode 64 with Dennis Hirsch with Saltworks, he was, he was talking about the fact that, again when you're testing other things, let's say an automobile you may, for safety, validate that your seatbelts and your airbags work.
[00:10:30] You also are going to be validating and have tests around the brake system. To make sure the car is going to be able to stop within the expected parameters, right? Those tests aren't really questioned anymore. We, we want them to be tested. We want to be able to drive a safe vehicle. And yet he still runs in, just like I did, into individuals that question why you need to have these other tests.
[00:10:52] And part of the reason you have that pushback is They don't want to necessarily add more friction to the development workflow and the CI [00:11:00] CD pipeline. If you can find a way to do that integration without adding that friction, I think you get the best of both worlds. Best of both
[00:11:10] Rob Aragao: worlds. You do, for sure.
[00:11:12] And, you know, I remember that conversation vividly with, with Dennis, because it was a great analogy on kind of car safety, right? And as you're manufacturing it and all the different safety checks. Recently, we talked to Tim Rohrbaugh as well. The former CSO Jet Blue, and he actually had a very similar.
[00:11:28] analogy, you know, as it related to the airplane manufacturing, all the different again, safety checks they have to go to. So I think it's, it's drawing that that parallel to, you know, looking at different kind of safety, you know, control mechanisms that need to be validated for many other things historically that we dealt with and how we can apply some of those kind of similarities into application security.
[00:11:48] Now, let's add another acronym into this discussion. S. C. A. Right. So software composition analysis, you know, it really focuses and very heavily on open-source components. And we're seeing [00:12:00] we've been seeing right for quite some time the majority of an end solution software solution is what 80 to 90 percent based off of open-source components.
[00:12:12] Stan Wisseman: at least that, you know, they have open-source components in them and it's going to be a high percentage, right?
[00:12:20] Rob Aragao: Right. And you have, you know, again security checks based upon, right. What components are you actually allowed to use?. So we were getting some more mature programs kind of have a good handle on this and saying, Hey, these are the approved quote unquote open-source components that you can, as a development team leverage for enhancing or
[00:12:38] creating a new solution, but there's again, that security aspect of it. Maybe you can talk a little bit about that side of it as well.
[00:12:45] Stan Wisseman: Yeah. So, I mean, if you look at it from the fact that when there's a zero day, like what happened with Log4j, a library that was used for years.[00:13:00] And, and then a researcher discovered that there was a flaw
[00:13:03] and then within a month there was already exploits occurring around the world. You need to understand what components you have in your applications so that you can react quickly and not spin your wheels thinking about or trying to determine where your exposure is in these different applications.
[00:13:24] You know, so the next zero day, you know, where it, and then there's the aspect of malicious injection of software into your software assets and into your code repositories and having the visibility and the protections for those code repository and different assets to ensure that they aren't being maliciously
[00:13:53] messed with, you know, and so, you know, there's there are a number of things going on there as well as far as how you can protect these [00:14:00] repose and putting place in those controls. And you mentioned licensing issues. That's another concern. You know, again, there could be all kinds of legal and financial repercussions if you use certain
[00:14:13] open-source libraries or components that have licenses that ultimately would require you to make it open or, you know, may not take you in directions that you want to. And so I think again, that's an aspect of including testings to get the visibility you need to understand what your applications are consisting of and also looking at the weaknessess
[00:14:42] that open source can the weaknesses or vulnerabilities that open-source software can introduce into your applications.
[00:14:50] Rob Aragao: Yeah, no, for sure. For sure. So I think I hope you convinced the individual that you had a conversation with that. There is more to it [00:15:00] than only SAS. I think, as you covered now, right?
[00:15:02] There's a lot of pieces to this, but again, a robust application security program does encompass coverage as it relates to both the SAS for static, the DASfor dynamic. And the SCA side of it, again, software composition analysis that really covers the open-source component to be very holistic.
[00:15:19] Everyone can kind of measure and decide what makes the most sense for them. It's kind of, you know, the mixed bag of how they're going to be most secure. But it is that kind of trade off just like anything else, right? How much are you willing to invest? To not be the next 1 of a breach with major ramifications from not only that cost of the breach from an impact again to what it may be to your end customers, but ongoing ramifications associated to brand impact and other things
[00:15:45] we've discussed many times in other episodes within our podcast. Of course. So Stan. Anything else you wanted to cover on this topic before you sign off today?
[00:15:55] Stan Wisseman: No, I don't think so. I think they're, you know, as folks dig into this, they'll find out [00:16:00] there are other types of testing. There's mobile application security testing.
[00:16:04] There's interactive application security testing, or IAST. I think the overall point is look at what testing techniques make sense for your organization to get that visibility into the risk to your application layer. It's the classic case of spend a little now to actually understand what makes sense for your organization and test them thoroughly or, you know, spend a lot later if there's actual breach and exploit of your applications.
[00:16:33] Absolutely.
[00:16:34] Rob Aragao: Excellent discussion. I know this is a very, very important kind of aspect of your background and you're a big proponent. So I'm glad we had an opportunity to really get a little bit deeper and discuss it with the audience today. As always, Stan, it's a pleasure speaking with you until the next episode.
[00:16:48] Stan Wisseman: And, and I hope, you know, you're, you're able to get some exercise and to work off some of those things. Well, I have to, I have to, I have no
[00:16:55] Rob Aragao: choice at this point, the elastic pants have to change over to regular pants in a couple of days here. [00:17:00]
[00:17:00] Stan Wisseman: Take care. Take care now.