Regardless of the project type, there are certain items that should be included in service deliverable documents. All documents should explain their purpose, advertise your brand, identify parties involved, list work that was performed, and conclude with an expected result. This section will provide some pointers and examples for meeting formatting goals in a professional manner.
A cover page at a minimal will provide a report name, version, date, author, service provider name, and intended party. Cover pages can also list additional items such as the document security classification or highlight results from other sections.
The information obtained during the majority of penetration services will be sensitive. It is critical to identify the level of security expected to protect information captured during the engagement, as well as name who is permitted to view such data. Certain levels of clearance may require special handling or secured locations for storage such as a Sensitive Compartmented Information Facility (SCIF) for storing classified material. Violations of data privacy can have financial, brand, and legal repercussions.
A Confidentiality statement should explain what level of security is involved with the document, who is authorized to view it, what is and what is not permitted to be copied, distribution rights, and other legal language. We recommend having an individual with a legal background develop your standard Confidentiality Statement.
Example 1: Confidentiality Statement
This document contains confidential and privileged information from SERVICE PROVIDER. The information is intended for the private use of CUSTOMER for their understanding of the current state of security of their organization. By accepting this document, CUSTOMER agrees to keep the contents of this document in confidence and not copy, disclose, or distribute it to any parties, other than those that will provide services and/or products directly to CUSTOMER as a result of the recommendations of this document, without written request to and written confirmation from SERVICE PROVIDER. If you are not the intended recipient, be aware that any disclosure, copying, or distribution of this document or its parts is prohibited.
Example 2: Statement of Confidentiality
This confidential information is being provided to SERVICE PROVIDER as a deliverable of this consulting engagement. The sole purpose of this document is to provide CUSTOMER with the results and recommendations from this engagement. Each recipient agrees that they will follow the distribution restrictions according to the agreement between this consulting agent and SERVICE PROVIDER.
It is important to list what version and edits are made to a delivery proposal. Most likely, many people with a variety of skillsets will be reviewing a document. Labeling changes with dates and type of modification will help readers leverage the latest version.
Timelines provide an estimate of hours for each phase of a project. Timelines should include the phase name, tasks to be completed, and expected duration for that phase. Typically, the duration is displayed in billable hours so the client can estimate the cost for each phase of the project. It is recommended to include language for which phases are mandatory to avoid requests to remove critical phases such as the project kickoff.
Following is an estimated timeline and high-level implementation plan:
Service Rrovider will begin this engagement starting two weeks after receiving the signed statement of work (SOW), and customer purchase order subject to resource availability. If the Customer requests an expedited engagement start date, this must be negotiated with Service Provider, Project Management, and Account Team.
The project launch phase and remediation presentation phases are mandatory phases for all other phases.
The goal of an Executive report is providing a high-level overview of why services were performed. Executive summaries should cover what led up to the issue being addressed, the problematic situation, and proposed solution with expected results. Executive reports don't require technical details and should target leadership rather than technical staff.
Example 1: Executive Summary
Background:
CUSTOMER engaged SERVICE PROVIDER to conduct a vulnerability assessment and Penetration Test of its systems. The purpose of the engagement was to assess the security of CUSTOMER networks and systems by identifying potential security flaws in them by utilizing SERVICE PROVIDER's proven testing methodology. The project was conducted on a number of systems on CUSTOMER's network segments by a team of SERVICE PROVIDER experts during DATE OF ENGAGEMENT.
This project included Penetration Testing nine (9) internal hosts. For the testing, SERVICE PROVIDER focused on the following:
- Attempt to determine what system-level vulnerabilities could be discovered and exploited with no prior knowledge of the environment or notification to administrators.
- Attempt to exploit vulnerabilities found and access confidential information that may be stored on systems.
- Document and report on all findings.
All tests took into consideration the actual business processes implemented by the systems and their potential threats; therefore, the results of this assessment reflect a realistic picture of the actual exposure levels to online hackers.
This document contains the results of that assessment.
Project Information:
The primary goal of this assessment was to provide an analysis of security flaws present in CUSTOMER's networks and systems. This assessment was conducted to identify possible vulnerabilities and provide actionable recommendations on remediating the vulnerabilities to provide a greater level of security for the environment.
SERVICE PROVIDER used its proven Penetration Testing methodology to assess the systems' security and identify potential security flaws.
Example 2: Executive Summary
SERVICE PROVIDER engaged CUSTOMER to conduct a Network Penetration Test on a quantified number of systems in their network. These systems were identified by the host numbers 192.168.1.X, 10.1.1.X, and 172.16.1.X. The purpose of this engagement was to identify and prioritize the security vulnerabilities on the identified systems. The engagement was launched on [START DATE] and included four (4) days of testing, analysis, and documentation.
It is highly recommended to provide an overview of how you deliver services. Highlights should include your process for each phase of an engagement, tools used, and how you handle identified threats. It is common to develop diagrams showcasing process flow and resource reporting structures for this section.
Certifications can help showcase a service provider's ability to provide quality results. There are certifications that highlight a company's ability to follow proven methodology for business flow such as the International Organization for Standards (ISO) certifications (For example, ISO 9001 or 14001). Other certifications could be focused on a specific technology, such as having engineers certified to install the technology being requested. Popular Penetration Testing certifications are the Certified Ethical Hacker (CEH) and GIAC Penetration Tester (GPEN), which help qualify the resources being contracted.
For Example: Methodology
SERVICE PROVIDER used custom and publicly available tools to gain perspective of the network's security posture from a hacker's point of view. These methods provide CUSTOMER with an understanding of the risks that threaten its information, and also the strengths and weaknesses of its current controls protecting those systems. The results were achieved and exacted by profiling CUSTOMER internal networks using publicly available information, mapping the network architecture, identifying hosts and services, enumerating network and system level vulnerabilities, discovering unexpected hosts within the environment, and eliminating false positives that might have arisen from scanning.
This section covers details from the service engagement. The target audience is typically the technical staff, and the goal is to provide as much information as possible around identified areas of concern. Customers may want to challenge a highlighted item and repeat the steps used to validate the vulnerability, meaning they want to know how things are discovered, accessed, and exploited. This data also verifies all requested network areas labeled in the scope of work have been addressed by the service provider.
Typically, subjects to include are targets discovery, mapping, vulnerability assessment, architecture analysis, exploiting, and reporting. How far a service provider goes in any area is based on what the statement of work defines as the focus of the engagement.
For example,
SERVICE PROVIDER was able to access the Legacy EMR host using the default system administrator credentials for MS SQL. This access allowed us to create an administrator account, expose system processes, user accounts, database files, and enable the transfer and execution of files. An attacker with this level of access would be able to disrupt all business processes that rely on this host.
SERVICE PROVIDER was also able to use the Server Message Block (SMB) Null User account to enumerate user account names and groups from the Domain Name Server (DNS). An attacker could use this information for targeted phishing attacks on CUSTOMER employees or to conduct brute force password guessing attacks. An attacker who gains administrative credentials successfully to create other user accounts and assign them to target business roles could use user group information.
Overall, the findings identify threats that can be mitigated through simple device/software configuration settings along with supporting policies.
Vulnerability assessment and Penetration Testing summary:
CUSTOMER provided SERVICE PROVIDER with the eight (8) IP addresses are listed in the following table. This range was scanned to determine open ports and services running on the related hosts.
The Summary of findings is the meat behind the proposal. This is where the findings from the services are explained, including how items identified may impact business. How these results are formatted will determine your customer's reaction, so be aware of not only what is said, but also how data is presented.
Best practice is including a risk ranking to help customers understand how to react to items identified. Common ranking characteristics are likelihood, risk evaluation, charts, color schemes, and so on. We recommend including both a summary chart and detailed section on all individually identified items. To back up your findings, best practice is having references to public sources on why the identified asset has an issue to further validate your claim. Public sources could be violations in compliance, not meeting a mandated standard or explanation of a known vulnerability from a reputable source.
Example:
The current risk level of systems tested, based on the highest risk level of findings in systems is Critical during the testing, a total of one (1) Critical, two (2) Medium, and two (2) Low vulnerabilities were identified as shown in the following screenshot:
Vulnerabilities found should include a clear description about the source of the weakness, impact to business operations and likelihood of being exploited. Reports should also list how the vulnerability was identified along with, if it was validated, meaning was the vulnerability exploited or just identified as a possible vulnerability during a scan. Vulnerabilities in a customer's architecture could include a diagram explaining the problem with captured traffic flow so customers can qualify the recommendation.
Some details that could be included for identified Vulnerabilities in a delivery report are as follows:
- Vulnerability name
- Business criticality
- Vulnerability description
- Technical details
- Affected systems
- Affected ports
- Recommended action
There may be general findings you would want to include beyond vulnerable systems to show additional value. For example, there is a mandate that all US federal agencies have equipment capable of supporting IPv6. Not having this isn't necessarily a vulnerability; however, something a US federal customer would be interested in knowing. Another example would be supporting future technologies, such as capabilities for Voice over IP (VoIP), and video.
Following is a suggested list for items to include in Penetration Testing services to show additional value:
- Difference in start-up and running configurations for devices
- Best practice deviation
- Support for IPv6
- End of sale or end of life devices
- Support for capabilities required for VoIP and video
- Compliance to common standards such as FISMA, PCI
- List of serial numbers, IP address, MAC, and so on of devices found
- Network topology
- Available protocols and public facing data
This section explains recommendations to remediate items found from services provided. Recommendations can range from high-level suggestions, such as "patch this system", to very detailed steps to close a vulnerability. Some remediation steps could impact other services, such as closing ports to defend from a specific attack, which also cripples another system that utilizes that channel for communication. It is important to include warnings of possible negative impact with any suggested remediation along with confirming that steps provided do not guarantee to fix the problem or bring a system into compliance with a specific regulation. The last thing you would want is a customer being compromised post services and point blame at you for not providing successful remediation steps to a vulnerability identified during your services.
Note
It is very important to state in a deliverable report what guarantees or coverages are included post services. Customers that fail an audit may assume your previous services are liable if you do not state your services, do not guarantee meeting specific mandates or requirements. For example, there is a huge difference between having a PCI report included with services, compared to actually contracting a PCI expert in reviewing all aspects of the regulation with the customer's network, in a similar method used by auditors.
There are many levels of remediation. Sometimes how the network in architecture exposes a weakness, but other times it's a gap in policy, configuration, or missing patch. Items to include for recommendations are summary of findings, high-level and detailed recommendations for remediation, other useful data outside of requested items, such as IPv6 capabilities, changes in network design, recommendations for hardware, software, patches, and compliance summary.
Example:
We commend CUSTOMER for being proactive in managing technology risk and network security through procuring our services. Due to the impact to the overall organization as uncovered by this Penetration test, appropriate resources are recommended to be allocated to ensure that remediation efforts are accomplished in a timely manner. Although a comprehensive list of items that should be implemented is beyond the scope of this engagement, some high level items are important to mention.
- Implement a patch management program: Many identified vulnerabilities could be avoided with proper patch management. We recommend following the guidelines outlined in NIST SP 800-408 as a source for developing security policies for proper patch management. This will reduce the risk of running vulnerable systems.
- Enforce change control across all systems: Common vulnerabilities are caused by human error. Many misconfiguration issues could be avoided through a strong change and control process on all active systems
- Leverage multifactor and role-based access control: Some critical systems were found leveraging password security as the only means of validating authorized individuals. Best practice is having at least two forms of authentication, along with limiting administration account access.
- Restrict access to critical systems: Critical systems should be isolated from other systems using whitelists, ACLs, VLANs and other means. The design concept of least privilege will limit the amount of damage an attacker can inflict using a compromised resource. Consult NIST SP 800-27 RevA11 for guidelines on achieving a security baseline for IT systems.
- Conduct regular vulnerability assessments: Vulnerability assessments should be conducted on a regular basis as a means to validate the current state of risk to the organization. Consult NIST SP 800-309 for guidelines on operating an effective risk management program.
- Include High Availability for critical systems and networks: During our assessment, we found single points of failure for mission-critical systems. Best practice is developing failover options in the event of network failure. An example for an improved traffic to the core datacenter is adding redundant systems to the data center network as shown below.
An appendix lists additional information related to the deliverable report typically not essential to the main findings. This is for reference purposes and could contain results from scanning, captured screenshots, and other information.
Example:
Appendix 001- Nessus Vulnerability Scanning Reports
<Captured Nessus Report Printout>