Security Testing Activities

1.

Reporting
INF 203

2.

Security Testing Activities
Refresher

3.

Vulnerability Assessment (VA)
• Execute tools to identify vulnerabilities in systems and software
• Use both open-source and paid tools
• Unlike Pentesting, VA usually involves only “using tools as is”

4.

Penetration Testing (Pentesting)
• It is a more sophisticated activity that goes beyond the tools:
- you simulate behavior and capabilities of a real attacker to try to
“penetrate” into a computer system.
• It comprises several phases and has also some recommended
standards, such as Penetration Testing Execution Standard (PTES)
- http://www.pentest-standard.org

5.

Phases of a Penetration Testing(1)
According to PTES*:
1
Pre-engagement Interactions
2
Intelligence Gathering
3
Threat Modeling
4
Vulnerability Analysis
5
Exploitation
6
Post Exploitation
7
Reporting
* Penetration Testing Execution Standard (PTES): http://www.pentest-standard.org

6.

Phases of a Penetration Testing (2)
Another possible list of phases:
1. Intelligence Gathering
2. Initial Foothold
3. Local/Network Enumeration
4. Local Privilege Escalation
5. Persistence
6. Lateral Movement
7. Domain Privilege Escalation
8. Dumping Hashes
9. Data Identification/Exfiltration
10. Reporting

7.

Red Teaming
• Red Team = attackers, Blue Team = defenders
• Red Team emulates Tactics, Techniques and Procedures (TTPs) of
adversaries
• Blue Team is typically not informed that a Red Team has been hired
(whereas in penetration testing, they collaborate).
• Red Teaming is often confused with Penetration Testing, and they are
often used interchangeably.
- However, there is a distinction between the two (next slide).

8.

Pentesting vs Red Teaming
Security
Assessment
Pentesting
Red Teaming
Methodical
Flexible
Table Source: Peter Kim,
"The Hacker Playbook 3"
Scope
Restrictive Scope
1-2 weeks engagement
Generally Announced
Identify Vulnerabilities
No Rules*
2 weeks - 6 months engagement
No announcement
Test Blue teams on programs,
policies, tools, and skills
Useful to estimate organization's
Time To Detect
(TTD) and Time To Mitigate (TTM)
* Can't be illegal…

9.

Reporting Results

10.

Reporting: Objectives
• Report the findings
• Rate the vulnerabilities
• Explain how the results will affect
the customer in the real world

11.

Reporting: Recipe for a Bad Report
• If the client can’t
- Understand report
- Reproduce exploitations
- Implement remediations
‣ Then your report is useless.

12.

Reporting: Quality
• Anyone can:
- run a vulnerability scanner
- report results in a template by changing organization name at the top.
• Not everyone can understand what vulnerabilities actually mean.
- Your added value comes here.

13.

Reporting: Report Sections (Example)
• Introduction/Overview
• Scope and Objectives
• Deviations from the Statement of Work
• Methodology
• Significant Assessment Findings (critical findings)
• Positive Observations
• Findings Summary
• Detailed Summary
• Appendix
- Extra: Some personal added value (e.g., OSINT on the company)

14.

Vulnerability Details (for Each Vulnerability)
Important List
• Estimated risk and impact values consistent with the context (e.g., lowmedium-high)
- For example, httpOnly flags disabled in an application that does not
have a login is very low risk and impact.
- Whereas not having httpOnly flags enabled if there is a reflected XSS
vulnerability then it is high risk and high impact.
• Category (e.g., Data Exposure)
• Location (where is it)
• Description of the vulnerability
• Replication steps (how your client can replicate the vulnerability)
• Recommendation on how to remediate it

15.

Reporting Results
Example Report

16.

Report Title
Full Report: https://github.com/juliocesarfort/public-pentesting-reports/tree/master/iSEC

17.

Executive Summary

18.

Executive Summary

19.

Executive Summary

20.

Overview (1)

21.

Table of Vulnerabilities

22.

Overview (2)

23.

Vulnerability Details: Example

24.

Vulnerability Details: Example

25.

Vulnerability Details: Example

26.

Appendix

27.

Appendix

28.

Appendix

29.

Preventing Common Mistakes
• Don’t RE-TITLE a tool report (e.g., Nessus)
• Rate your vulnerabilities in an appropriate way
- Find a consistent and clear way to do so (e.g., Appendix)
- Refer to the CIA security triangle
• Separate Theoretical vs. Real Findings
- e.g., whether an exploit is practical/available
• Make sure vulnerabilities are actual vulnerabilities
- e.g., PHP cgi vulnerabilities on an Apache server that is not running them
• Write clear reproducibility steps
• Remediations and Solutions are just as important as the Findings
• Standardize all your templates

30.

Q&A