Chapter 11: Reporting and Communication Flashcards
Communication Path
- Primary Contact: Responsible for day to day admin of the pentest
- Technical Contact: Can handle any tech issues or questions that arise during the test
- Emergency Contact: When shit hits the fan (24/365 SOC)
Comms Triggers
Completion of a Testing Stage
* SOW should include milestones that indicate the completion of one stage of testing and mark the beginning of the next
* Completion of a test stage should server as a trigger for commnicating periodic status updates to management
Discovery of a Critical Finding
* If pentest identifies a critical issue with the security of the environment, don’t wait for final deliver, say it now
* Follow procedures outlined in SOW to immediately notify management of the issue, even if it reduces the depth pentesters are able to achieve during the test
Discovery of Indicators of Previous Compromise
* If you discover evidence left behind by real attackers who have previously compromised a system
* Immediately inform managment and recommend that the org activate it’s IR process
Recommending Mitigation Strategies
Technical Controls
* Common controls like hardening systems, input sanitization, query parameterization, MFA, password encryption, hash salting, patch management, encryption key rotation, segmentation, etc
Admin Controls
* RBAC, secure software dev lifecycle, policies and procedure enforcement, minimum password requirements
Operational Controls
* Job rotation, Login time-of-day restrictions, mandatory vacations, user training
Physical Controls
* If you don’t know these you’re retarded
Structure of Pentest Report
- Executive Summary
- Scope Details
- Methodology
- Findings and Remediation
- Conclusion
- Appendix
Page 417 to 420
Post-Engagement Cleanup
- Remove shells installed on systems
- Remove tester-created accounts, credentials, or backdoors
- Remove any tools installed
Restore the system(s) to original, pre-test state in every single way
Comms Paths
Primary Contact
Party responsible for handling the project for the org
* CISO
* CIO
* IT Director
* SOC Directory
* If primary can’t answer questions, some orgs will designate a secondary contact
* More focused on business impact, governance, and oversight—less technical
Technical Contact
The party responsible for handling the technology elements of the engagement from the target org’s perspective
Emergency Contact
The person you call when shit hits the fan, for urgent matters that occur outside of normal business hours
Comms Triggers
Many things can happen that cause us to stop the test and communicate directly with the target org
Status Report
Used to provide regular progress updates to the primary, secondary, and technical contacts during an engagement
* How often will they be delivered?
* Can be as simple as an EOD email with recent tasks, current plans, and blockers
* Can be daily standups
* Tailored to needs of org
* Brief checks are when you share with them current status of your phase, and get permission to move into the next phase
Critical Findings
Occurs when a vulnerability is found that could pose a significant risk to the org
* Need to tell immediately so org can patch to prevent a real world attack
* Considered an out of cycle report
Indicators of Prior Compromise
A residual sign that an asset or network has been successfully attacked or is being attacked
* Any time there are these IOC, pause the engagement and shift to IR or recovery mode
* Talk to the contacts and figure out what’s best
Reasons for Comms
Situational Awareness
The perception of the different environment elements and events with respect to time or space, the comprehension of their meaning, and the projection of their future status
* Your ability to know what’s going on around you during the engagement
* Needs to happen for testers and targets to create shared understanding of the network and its current state
De-confliction
Used to determine if a detected activity is a real attacker acting against the target network or an authorized pentester
De-escalation
The process of decreasing the severity, intensity, or magnitude or a reported security alert
False Positives
Using a results validation process with your trusted agent to help identify what findings may be false positives
Criminal Activity
If criminal activity is discovered within the org, beyond an indicator of prior compromise, like with an employee
* In the case of criminal activity, consult with your legal counsel to determine the next steps
Goal Reprioritization
If the goals from the original planning and scoping need to change
* EX: Doing a PCI-DSS scan before a pentest, and you discover the patch and vuln management is horrible
* Doing the pentest would be useless because there’s too many vulns
* Reprioritize to consult and help the team patch better, etc
Presentation of Findings
C Suite
Keep things broad, high-level, and focused on the business and costs
Third Party Stakeholders
Meet their requirements that are focused on regulatory compliance and ensure that the org has a proper cyber baseline
Technical Staff
They want details and ways that they can change things using different operations software or security patches
Developers
They want deep technical information so they can change the code that runs the apps in order to prevent the vulns entirely
Report Formatting
Executive Summary
High-level overview written for the management and executives
* All the big things they need to know in one or two pages
* Have a conclusion: I found that this network is shit and needs help
Scope Details
Reiterates the agreed-upon scope during the pentest
* What we looked at, etc
Methodology
A high-level description of the standards or frameworks followed during the pentest
* Also contains a brief attack narrative, a short story of what you did during the pentest
* Recon
* Footprinting
* Enumeration
* Vuln scanning
* Initial attack
* Lateral movement and pivoting
* Persistence
* Event by event overview, what worked, what didn’t
Findings
A full or summarized list of issues found during an engagement
* List out the major finding, but all the tech details are in appendix
* This is the bulk of the report because it lists out all that you found and remediations on how to fix
* Also list the threat level, risk rating, and if you were able to exploit during the pentest
* Risk rating framework of likelihood of happening vs impact of it
* Final thing is to list the business impact
Metrics and Measures
* Metrics are quantifiable measurements that help illustrate the status or results of a process—what’s the amount
* Measure specific data point that contributes to a given metric—what to measure
Remediation
Summarizes the biggest priorities the org should focus on to remediate vulnerabilities
* To describe in long form what this customer should be doing to solve their issues
* There are multiple ways to solve things like weak passwords, put your recommendations in remediation
* EX: If you use MFA it will cost $5 million, but if that’s too expensive we recommend complex passwords which will cost $100k
* This section allows the org to make educated decisions based on your recommendations
Conclusion
Summarizes the report as a whole
* Key takeaways, the main things they need to know
Appendix
Acts as the catch all section to put in all of the extra details
* Supporting evidence
* Attestation of findings
* Can include screenshots, printouts, etc
Common Themes
Additional section you can choose to include or build it as an outbrief that describes what you saw, root causes, etc like:
* Lax physical security
* Corporate policy bypass
* Lack of training and certs
* Poor patch management
* Outdated protocols
* Obsolete protocols
* Improper processes
* Non-hardened OS and servers
Securing and Storing Reports
Securing Reports
* Always store reports in an offline server or in an encrypted format
* Ensure reports are only seen by those who need to see them
* Hash or digitally sign the report to ensure integrity
* People need to be approved to see the report
* Any copies need to be tracked with an audit trail
* Implement version control
Storing Reports
* How long will you store them? This depends on the client and their requirements
* Know what the lifecycle of all documents and evidence is
* If you don’t need to hold on, dispose of it properly and securely
* 12 to 24 months is usually adequate but depends on the customer
System Hardening Checklist
- Remove or disable devices that aren’t needed or used
- Install OS, app, firmware, and driver patches regularly
- Uninstall all necessary network protocols
- Uninstall or disable all unnecessary services and shared folders
- Enforce ACL on all system resources
- Restrict user accounts to least privileges needed
- Secure the local admin or root account by renaming it and changing the password
- Disable unnecessary default user and group accounts
- Verify permissions on system accounts and groups
- Install AV/AM software and update the definitions regularly
Cleaning Up Post-Test
Shells and Tools
Keep detailed notes of everything that was installed and every system that was exploited
* Remember where you put all your shells and how they’re called
* Remove schtasks, cron jobs, DLLs, daemons, etc
* Any other tools you may have installed on the tools needs to be removed as well
Test Credentials
Keep notes on what accounts you created and for what purpose
* What groups they’re part of, apps they’re for, domains, etc, etc
* If you can’t work with the org to let them know you put them there or maybe they can delete them
Test Data
You need to purge all data
* Linux you can shred the data
* Install third party tools to securely delete the data
* Or you can save to external HD and delete
* If you have SED you can cryptographic erase
* Any systems where you pivot from that are used as collection points need to be purged as well
Client Acceptance
Your pentest doesn’t stop until the client agrees you have met the SOW
* At the end, have a formal handoff where you give the report and go over the findings
* Establish an ongoing relationship with the client
