Software Penetration Testing
Software Penetration Testing
Software Penetration Testing
• QA & testing organizations are tasked with the broad objective of ensuring that a software application fulfills
its functional business requirements.
• Security is not a feature! So, security testing (especially penetration testing) does not fit directly into QA.
• Security testing poses a unique problem: A majority of security defects and vulnerabilities in software are not
directly related to security functionality.
• Instead, security issues involve often unexpected but intentional misuses of an application discovered by an
attacker.
• If we characterize functional testing as "testing for positives“ then penetration testing is in some sense "testing
for negatives."
• At its heart, security testing needs to make use of both white hat and black hat concepts and approaches:
- ensuring that the security features work as advertised (a white hat undertaking) and
- intentional attacks can't easily compromise the system (a black hat undertaking).
• Thinking like a bad guy is so essential to good penetration testing.
Software Penetration Testing
• In any case, testing for a negative poses a much greater challenge than
verifying a positive.
• It is very difficult to show whether or not a system is secure enough under
malicious attack.
• Q: How many tests do you do before you give up and declare "secure
enough"?
• If negative tests do not uncover any faults, this only offers proof that no faults
occur under particular test; this by no means proves that no faults exist.
• Finding a security problem and fixing it is fine. But what about the rest of the
system?
Penetration Testing Today
• Penetration testing is the most frequently and commonly applied of all SWS best practices.
• This is not necessarily a good thing.
• Often penetration testing is positioned on software development teams by security guys and
everyone ends up angry!
• Too much driven by an outside in approach.
• One major limitation of this approach is that it almost always represents a too-little-too-late
attempt to tackle security at the end of the development cycle.
• Fixing things at this stage is, prohibitively expensive and almost always involves Band-Aids
instead of cures.
• Post-penetration-test security fixes tend to be particularly reactive and defensive in nature.
• Software security penetration tests do not currently follow a standard process of any sort.
Penetration Testing Today
• Use of security requirements, abuse cases, security risk knowledge, and attack
patterns in application design, analysis, and testing is rare in current practice.
• As a result, security findings are not repeatable across different teams and
vary widely depending on the skill and experience of the tester(s).
• In practice, a pen-test can identify only a small representative sample of all of
the possible security risks in a system.
• Pen-testing without any basis in security risk analysis leads to the "pretend
security“.
• One big benefit of pen-testing that is its obedience to a critical black hat view
in its real production environment.
Software Penetration Testing- a Better App
• Pen-testing can be used effectively. The best approach bases on security findings discovered from the
beginning of the software lifecycle:
- during requirements analysis, architectural risk analysis, and so on.
• Pen-testing is about testing a system in its final production environment.
• So, pen-testing is best suited to probing configuration problems and other environmental factors that deeply
impact software security.
• Driving tests focusing on these factors with some knowledge of risk analysis results is the most effective
approach.
• Make Use of Tools
• Tools (including the static analysis tools) should definitely be used in penetration testing.
• These tools can submit malformed, malicious, and random data to a system's entry points in an attempt to
uncover faults;
• A tool-driven approach can't be used as a replacement for review by a skilled security analyst;
• but a tool-based approach does help reducing the cost.
Tools for Penetration Testing
• Fault Injection Tools
• One of the most interesting modern fault injection engines for security is the Cenzic tool.
• Any hacker (malicious or otherwise) uses these tools.
- Disassemblers and decompilers:
- Control flow and coverage tools
- Breakpoint setters and monitors
- Buffer overflow.
- Shell code.
- Rootkits.
• Other tools include the following:
- Debuggers (user-mode)
- Kernel debuggers
Test More Than Once
• Human review is necessary to reveal flaws in the design or more complicated implementation-level
vulnerabilities (of the sort that attackers can and will exploit).
• However, review by an expert is costly, can be ineffective if the "expert" is not. More structured and cost-
effective solutions are needed.
• Penetration testing can benefit greatly from knowledge of the security risks built into a system.
• No design or implementation is perfect, and carrying risk is usually acceptable. Penetration testing can help
finding what this means to your fielded system.
• Penetration testing should focus at the system level and should be directed at properties of the integrated SW
system.
• The most common failure of the SW pen-testing is failure to identify lessons learned and propagate them back
into the organization.
• Iterative pen-tests are coming to reveal fewer and less severe defects in the system.
• Don't forget that the real value of pen-testing comes from its central role in inspecting configuration and other
essential environmental factors.
• Use pen-testing as a "last check" before code goes live instead of as a "first check" of security posture.
