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
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
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
Notes de l'éditeur
Often we don’t do exploitation and post-exploitation
Who has done this in a test?
If you don’t have these, get them quick!
Knowing your tools makes a huge difference in what you might find