This document outlines the process and methodology for security testing, including info gathering, planning, execution, and closeout. It details the testing methodology of recon, mapping, discovery, and exploitation. It provides a testing checklist and describes best practices for the different phases of testing, writing issues, and creating a final report. The document emphasizes finding root causes, verification, and focusing on what is most important to protect.

1. Security Testing

2. Test Process Flow
•
•
•
•
Info gathering
Planning
Execution
Closeout

3. Testing Methodology
•
•
•
•
Recon
Mapping
Discovery
Exploitation
– Post-exploitation
• Reporting
Recon
Exploitation
Mapping
Discovery

4. Testing Checklist

5. Info Gathering/Planning
Recon
Reporting
Mapping
Risk
Analysis
Discovery
Postexploitation
Exploitation
•
•
•
Functional Analysis
Process Flow Mapping
Request/Response
Mapping
Security Testing
Checklist

6. Info Gathering
Planning
Execution
Closeout
Notification of a request for testing
Questionnaire and checklist is sent
Questionnaire is returned with project documentation
Tester assigned to project (if not already assigned)

7. Info Gathering
Planning
Execution
Closeout
Review documentation
Conduct interview with analyst/developer
Application walkthrough
Set the schedule
Write Ready for Test
Conduct a kickoff meeting
Verify necessary access
Recon phase of testing
Checklist - Recon and analysis

8. Info Gathering
Planning
Execution
Closeout
Host Assessment
Patches and updates
Ports/Services
CIS Benchmarks
OS/Web Server/DB configuration
Checklist – Assess application hosting & Configuration
management
Web Application
Mapping
Functional Analysis
Process flow mapping
Request/response mapping
Discovery (Covered by TSB checklist)
Configuration Management Testing
Authentication Testing
Session Management Testing
Authorization Testing
Business Logic Testing
Data Validation Testing
Exploitation
Post-exploitation

9. Info Gathering
Planning
Execution
Closeout
Remove false positives
Risk analysis
Compute CVSS score
Conduct a findings meeting with the project
Write final report

10. Weekly Status Reports
• Follow the template
• Set verbosity to “3”
• Include where you are in the process and the
methodology
• Show progress
• Include non-test related items (demos,
research, etc)

11. Post Testing Findings
• Schedule it for after the test, while writing the
final report
• May provide helpful insight that is useful
during the reporting process
• Assures that there are no surprises in the Final
Report

12. Automated tool output
•
•
•
•
•
Verify issues
Provide clearer explanations
Tune risk levels
Provide custom recommendations
Prioritize recommendations

13. Writing of Issues
• Be concise and direct
• Include
–
–
–
–
–
description of the issue (how it is)
how to reproduce it
why it occurred (i.e. root cause)
why it is a security issue (significance of the impact)
recommendations on how to remediate the issue
(how it should be)
– CVSS risk
• Should be able to fill out a CVSS calculator

14. Questions that should be taken into
consideration and answered
• What assets are affected?
• What population of people have access to this
exploit?
• What is the level of difficulty?
• What is the frequency that this exploit
happens “in the wild”?
• What controls are in place that would mitigate
the ability of someone to exploit this?

15. The issue is not written until these 2
questions can be answered by the
audience:
– Will the reader understand why this is a security
risk?
– Will the reader understand how to fix the issue?

16. Why exploit?
• Find things that automated tools can’t or won’t
• Reduces false positives
• Improves the report
– Saying that the password policy is weak and passwords and PII
shouldn’t be stored in plain text
• True, but understated
– Saying we were able to crack a user’s password and then obtain
user IDs, passwords and PII (in detail)
• More powerful
• Identifies root causes efficient and effectively
• Leads to more security issues that otherwise may have been missed
• Threat modeling is important
• CVSS scores each vulnerability separate

17. Final Report
• Executive Summary
– 3-6 key findings (root causes)
– Highlight business impact
– Explain the levers management can pull to change
root causes

18. Non-Technical Skills
• Project Management
• Education
– Staying up to date and learning new technologies
• Teaching
– Being able to explain new concepts and share knowledge
• Research
• BS Management (people skills & business skills)
• Writing
– Being able to explain and influence other people
• Attack modeling
– Having a security mindset

19. Technical Skills (The Baseline)
• Master of an OS (and some web server knowledge)
– Linux
– Windows
• In depth knowledge of TCP/IP
• Basic Scripting
– BASH, Perl, Python
– JavaScript
• Databases and SQL
• Lean how to program!
– Recommend python or Java
• Ability to complete the Security Testing Checklist

20. Basic tools
–
–
–
–
–
–
–
–
–
–
–
–
–
NMAP
NetCat
TCPDump/Wireshark
Metasploit Framework
Burpsuite Pro
Nessus
Cenzic Hailstorm
Core Impact
Firefox plugins
Backtrack/Samurai WTF
SQLmap
Command line tools
Many, many more

21. Best Practices
•
•
•
•
•
•
•
•
•
•
Run tcpdump when testing, especially with tools
Use Burp as a proxy when browsing
Disable firewall and A/V on attack system (and no PII)
Start writing the report as you go
Ask the project what is important and what needs to be protected
Take notes as you test, include dates
Save logs and checklist (especially burp logs)
Update tools before the test begins
Tune your tools
Always verify results – especially verify results discovered by an
automated tool with manual verification
• Stick to Mapping -> Discovery -> Exploit
• When in Discovery phase, don’t get side-tracked into exploits
– 5 attempts or 5 minutes
• Break vulnerabilities down until you hit root cause(s)

22. Ideas for Future Research
–
–
–
–
–
–
–
–
–
–
ASP.net & Powershell
Web Services
Cloud Computing
Mobile
Remediation recommendations
Design input
Attack analysis and forensics
Code reviews
Tool “tuning”
HTML5