All
right, static application security testing.
Two categories, static and dynamic.
You'll see those actually in malware analysis, in application testing.
In static or code review, you don't run the software.
If it's static in nature, you don't run it, you analyze the source code or use dis
assemblers and code analyzers to identify security related weaknesses in the code.
Automated versus manual source review.
There are automated source code analyzers.
Again, not a developer by background, not my thing.
Can't really give you a lot of first hand experience with that.
Then manual source code review is where you're going through it manually.
The idea there is anything that's automated can definitely
analyze quickly, but it may miss some things in manual source code review.
Again, it's not automated, it's more time consuming, but it also you have a tendency
to catch things that maybe the automated source code analyzer might miss.
Dynamic application security testing means you're actually running the application.
Application is tested dynamically from the
outside when the application is running, generally performed by penetration testers
or security practitioners using tools like NetS parker, Acunetix,
vulnerability scanner, talking vulnerability scanners, HDL app scan, etc.
To perform dynamic application security testing.
Fuzzing is another option there.
We'll talk more about fuzzing.
Which you're trying to blow up the application more or less.
You're trying to find security issues
or trying to cause it to respond in an unexpected way.
Types of DAST fall into automated application
vulnerability scanning, which you get some of these application scanners run you tens
of thousands of dollars, 35 grand or higher.
Manual application security testing.
The tester uses proxy based security testing tools to craft and send responses.
So automated, fire it up, give it a URL, let it rip.
In manual, connect through a proxy,
analyze the web application manually, collect all the results.
Fuzzing testing.
A web application fuzzing testing.
In a nutshell, fuzzing is fuzzing the alliance from the expected norm.
An application expects data in a specific format, specific sequence, etc.
What happens when you feed it something
unexpected and what type of response you're going to see?
That's fuzzing testing.
It's random data
generated by a fuzzer used to target web server application, discover
vulnerabilities that can be exploited by various attacks.
Our application whitelisting is specifically allowing applications to run.
So you have an implicit deny and an explicit allow.
This is a great approach for addressing
unknown zero day vulnerabilities or unknown malware variants.
Since everything is denied and allowed one by one, only what has been allowed in the
whitelist is allowed to run, everything else is blocked.
In blacklisting, you're specifically
disallowing, and this is an explicit deny and an implicit allow.
The idea with blacklisting is you have to know what to program the blacklisting
application to watch for, and you might miss some things.
Again, antivirus
and other types of detection tools, historically, have always used
blacklisting, but they can't account for zero days or unknowns.
Sandboxing.
Sandboxing is constraining the runtime environment of the application.
So you run an application in a sealed container, we're going to call that a
sandbox, so they cannot access critical system resource or other programs.
You will be doing a lab on sandbox.
But the idea there is to test an
application and not allow it to escape the confines of the Sandbox.
Patch management, really important.
Vulnerabilities are discovered all the time.
Patches come out all the time.
Patches need to be tested and deployed in a timely fashion.
So your patch management process
is detect, assess, acquire, test, deploy, and maintain.
And you want to have a mitigation or
rollback strategy in there in case something happens that you didn't
pick up in testing and need to revert the changes.
So you need to figure out what patches are missing, assess the security issue that
the patch addresses, acquire it, download the patch for testing from a reputable
source, verify your checksums or your hashes, test, install the patch on a
testing machine, verify the consequences of the update,
deploy the patch once testing has been successful, and then maintain, subscribe
to get notifications about vulnerabilities as they get detected.
A web application firewall gives you an
additional security layer for different types of web application attacks.
So for example, web application firewall might look for it.
Sequence injection signatures, angle brackets, things like that.
The WAF should be placed before the web application, and again, it gives you a
more detailed inspection of specifically web application traffic and gives you a
lot of rule sets and analyzers targeted specifically to web attacks.
Now, typically, you're going to have a
multi tiering type of filtration environment.
You have border routers, exterior
firewalls, web application firewalls, internal firewalls.
Typically, you're going to stage these in succession.
But of course, we have talked about
unified threat management and next generation firewalls.
We're supposed to do everything in one appliance.
I think I still like the separation of duties on that.
Bug bounty programs.
Bug bounty programs are pretty popular.
They're a challenge hosted by
organizations saying, Hey, crack our code and we will give you a bounty.
So it will allow you to pin test our
resources and will pay you if you find something critical.
So it focuses on identifying latest
security flaws in software web application that most developers fail to detect.
An example of a web application security
standard, Nstocker, Acunetix, browser exploitation framework.
Some of these are primarily exploitation
tools, but they do have scanning functionality.
Metasploit, Powersplit, Watcher, and then the Almighty Web Inspect.
Some examples of proxy based security
testing tools which you are going to play with Burp and Owasp Xap and Labs.
Both of these are web proxies.
All your data is sent through the proxy.
They've got manual and automated testing available.
All right, and that's going to wrap up Module 9, application security.