My name is Scott Snowden. What we're gonna do is we're a cover, Webb Inspect, which is dynamic scanning in the morning in the afternoon, Jimmy is going to go over static analysis with Fortify. There is some introductory portion where we'll talk a little bit about both up front. And is Tom mentioned if you guys have any questions, please feel free to ask him. You know, this is your time. We're here to help.
All right. So we're gonna talk about applications security a little bit. First we meet with a lot of people, a lot of customers, and we start asking them about application or security in general, A lot of times they start talking about some of the things that you see at the top of that circle. So they're talking about their firewalls.
Their I D s is, and their I. P s is an anti virus and endpoint protection and
all those sorts of things. That is not what we're focused on. Fortifying weapons back our application, security scanning tools. And part of the reason that we focus on the application itself is according to Gartner, over 84% of all breaches its voice software application vulnerabilities.
So that's what people are breaking into because that's the low hanging fruit,
the easiest portion that will always be people on your network that you don't think you're on your network. There will always be stolen credentials. There will always be people there given access through mobile devices and other mechanisms. You know, you have to make the assumption that people are able to get to your applications,
whether it's voluntary, you know it's a publicly facing application or it's on a VPN or something else. We need to make sure that those applications air actually secure.
One of the ways that we do that on one of the things that distinguishes fortify and weapons back from some of the other tools that you might be using is our software security research group. So it's relatively easy to build a product that scans software
all right, it's very difficult to create the research and the rules and the knowledge
to teach that skin or what it is that it's looking for. That's really kind of the secret sauce so you can see here for dynamic scanning. We have over 3000 different vulnerabilities that we check for in over 170 categories.
All right, there's a tech Somini that we are published. There's a public website that you can go to that lists all the different types of checks that we d'oh.
If you just Google 4 to 5 own cat, you can see that down there at the bottom that will bring that up there currently releasing a newer version of that Web site that has a little bit more user friendly user interface. But the information is basically the same, and as this craft mentions, that covers both static, dynamic and run time
on the static side. Recover 23 languages, 700 categories and over 800,000 AP eyes that the security research team actually tracks and writes rules for So it's a very comprehensive solution,
This is kind of just a general overview of the solutions. Like I say, we have static analysis, which is also called Source Code Review. That's our fortified product. It takes your source code, looks at it line by line by line, determines when it finds a potential vulnerability,
tells you what we found where we found it, what the potential ramifications are and how you would fix it.
So dynamic analysis tests a running Web application. That's the difference between Static, which is looking at source. Code Dynamic is actually testing a running Web application. It works in two phases, the first phases to fingerprint the application. So it crawls. The application,
identifies all the pages, sessions, form, fields, things like that,
and then it attacks them or audits them. Those are those 1,703,000 attacks that we mentioned before. If one of the attacks is successful, it's listed as a potential finding,
all right, and then the last product that we have is run time application protection. That is, a software agent that actually protects the application in real time. We're not going to be talking about that today. Oh, there is a version of that agent that can actually be used in conjunction with weapons back
toe help. You better scan the applications, and that is something that we'll talk about today.
And then all of these products. The results can be fed into a central management repositories, which is software security center. You see that down there in the middle, that gives you the ability to keep all of the information in one place. If you so choose to correlate the results and then they're usually will be too different.
Outputs of that one is remediation. So we're gonna produce a report that we can give
to the developers to say, Look, we scanned your application. This is what we found. This is what you need to fix. The 2nd 1 is application lifecycle management. So a lot of people, if they have a number of applications that do the same thing, they'll scan them and they'll choose to keep the application that's most secure
because it's cheapest to fix that application
and sustain it, then it would be to retrofit some of the other one. The other thing is, we might decide if we scan an application and we find a lot of issues. It's gonna take a while to fix those issues. Maybe we need to put that on a separate physical box or in a different network, or restrict access to or do something else once we actually know what the risk
of the application ISS.
So a lot of people say great, we can do static
or ah source code analysis. We can do dynamic analysis which tests the running application. All right, which one is better? Which one should I be doing? The answer is actually both. So there is a d. O. D. Mandate. The application Stig requires that where applicable, you perform both static and dynamic analysis,
so the key word is where applicability. So the first rule is in order to source code analysis. What do we need?
Source code. We don't have source code. We can't do static analysis. The 2nd 1 is generally speaking. In order to do dynamic analysis, we need either a Web application or a Web service. We can also do dynamic analysis against mobile applications as well.
Static analysis is usually going to find Maur issues than dynamic analysis
because it doesn't know anything about your environment. So we have to make assumptions on the static analysis side about the environment that you're actually running in. That tends to lead a more findings and also because it actually has access to your source code. It's a more detailed analysis.
The best example of this is when I run dynamic analysis. I'm not generally speaking,
going to be able to tell if your developers writing user names out to a log file because the dynamic analysis and you can't see the log file its request response based, all it can see is whatthe Web application returns back where static analysis could see all of your code so it can see everything that's actually being done
like so that goes to the next issue dynamic. Now, since this request in response based, that's also going to make it easier to replicate of finding because you can take the request on replay it and show the developer Look, when we did this test, this is what we did.
This is how we found it. You can also modify that request slightly if you need to
to be able to prove that the application is actually vulnerable
because of this static analysis is usually preferred by developers because it deals with source code. That's what developers understand for a detail that makes it a little bit easier to do. The remediation dynamic analysis. A lot of times is preferred by people that have a sock background or I a background
people. They're used to running things like Ness is scans or a cash or things like that
because it's more similar to that particular process.
And then this last column. The hybrid analysis basically links these two together. So that's the agent that we're going to install on the actual Web application under test that gives us the ability to transform what is essentially a black box purpose. Our test, where we send in a request, look at the response
to be able to see what the application is actually doing.
So that gives me the ability to say all right, weapon specs sent in a request that caused the server to crash or do something else that was unintended, well, weapons, but doesn't know what the application server actually did, cause it can't see that because it can only see the response. The agent, because it's actually profiling the running application.
Comptel. What actually happened on the back end?
It will then feed that information back to Web inspect allowed to do a better scan, and it also allows us to overlay the results of the static analysis and the dynamic analysis. So if we find something with weapons fact
and with fortify, we can say, Well, look, this is the exact same issue here is the source code. Here's how you actually exploit this issue through the request. In response, we can correlate those issues together.
All right. C v e's vs c w Ys. Alright, so C W E com A witness in new Marais Shin C v E common Bullard Vulnerability. A new Marais shin. This is an important concept, cause a lot of people are running tools like necessary cash or things like that. They're already scanning
their applications and they'll ask, Well, why do I need yet another scanner? What is the difference between weapons packed
and some of these other tools that we might already be using so necessary? And egg has are primarily focused on CV East. A C V E is a publicly known software vulnerability,
all right, What that means is, somebody discovered a vulnerability in Apache or the Spring Framework or Microsoft Windows operating system or something like that
reported it to us, sir. Us certain validated that it's actually a vulnerability. They then gave that information back to the manufacturer, gave them a certain amount of time to fix it, and then they publicly disclose it. Because of that, it's very easy to find those issues. I can check your manifest. I can look at your registry. I know exactly what I'm looking for.
Common weakness in new Marais Shin is a a vulnerability that is not publicly disclosed. Because of that, it may or may not be a vulnerability is something. It's a weakness. That software wasn't correctly written. It doesn't function properly, but nobody knows about it because it's never been publicly disclosed.
So if you have custom applications,
all right, they're not going to contain CV, ese. They're going to contain C W Ys. They're not public. No one's ever gonna tell you. Hey, look, I looked at your Internet application. It has this vulnerability in it. You know, you're not going to know about that until something bad happens. And because of that, it's more difficult
to find the common weakness in new Marais shins. We have to have a little bit more generic
patterns that we're looking for, we're looking for patterns were not necessarily looking for signatures. It's a little bit more difficult. So what we typically recommend is that you use a tool that's focused on finding CVS. All right, because we're not going to tell you that the copy of Windows,
you're running your system on his, you know, three years out of date and
has never been patched. Web inspect doesn't do that. But we will tell you, is that the software the software application that you wrote that you installed on that system is riddled with sequel injections and cross site scripting and command injection. Some of these other things that we're gonna be focused on
because of that a lot of people will ask us. Well, this weapon specs support the CVS *** and oval, will. We don't because those Onley support CV ease. And we're primarily looking for seed w He's all right. So there is a mechanism where you can try and force fit those two things together.
But that's not what Web inspector or fortify, for that matter.
Eyes intended to do out of the box