171. Communication and Reports (OBJ 4.3)
In this section of the course, we’re going to discuss the importance of communication during the penetration testing process, and the different components that you should include in your final written report that you’re going to deliver to your client. As we move through this section, we’re going to be discussing two different objectives from Domain 4. Reporting and communication. The first objective is 4.3, which states that you must explain the importance of communication during the penetration testing process. The second objective that we’re going to cover is objective 4.1, which states that you must be able to compare, and contrast important components of written reports. We’re going to begin our coverage by discussing the different communication paths, and points to contact that you’re going to engage with from your client organization during your penetration test.
Then we’re going to discuss the three different triggers that are going to cause a penetration tester to initiate communication with the target organization during an engagement. After that, we’re going to look over the six different reasons for communicating during a penetration test. Then we’re going to discuss the different audiences that you’re present your findings to at the end of your engagement, and the different methods used to gather data for the end of the engagement report. After that, we’re going to dive into the written report itself including the seven different sections that are used in these reports, including the executive summary, scope, details, methodology, findings, metrics and measures, remediation, conclusion and the appendixes. Then we’re going to look at how you can identify, and report on common themes and root causes that you’re going to discover during your engagement. As well as the best practices for securing and storing your reports. All right. Let’s get started with our coverage of Domain 4. Reporting and Communication with our coverage of communication and reports in this section of the course.
172. Communication Paths (OBJ 4.3)
In this lesson, we’re going to discuss communications before during and after a penetration test. When we conduct a penetration test, nothing is done in a vacuum. So there’s a lot of different communications that have to occur for our engagement to be successful. Especially if we’re going against a large corporation as our target, we’re likely going to be a part of a larger penetration testing team. Even if I was hired to go after the organization alone, I’m not going to be the one making all the decisions because I’m still going to need to communicate with the target organization’s representatives to ensure that everything is progressing safely and properly during our engagement. For this reason, it is important to understand the different communication paths that we’re going to be using during the engagement. So, let’s discuss the different people that may be involved in the communication path from the target organization. This includes the primary contact, the technical contact and the emergency contacts. Now, these contacts are very important for us to define, all the way back in our planning and scoping phase, because they’re going to define who on the target organization’s staff is going to be aware of the penetration test and should be informed during the engagement.
The primary contact is the party responsible for handling the project for the target organization. In my experience, this is usually a high-level executive such as the chief information security officer, the chief information officer, the IT director, or the security operation center director, depending on the organizational structure of your target organization. This primary contact should be defined in your initial planning and scoping documents, and it will usually be listed by their name or their position inside of your contract. Now, some organizations will also provide a secondary contact to answer questions and make decisions if that primary contact is unavailable. For example, if the chief information security officer is listed as the primary contact, then you’re usually going to see somebody like the IT director listed as that secondary contact for that engagement.
Now, it is important to understand that the primary and secondary contacts tend to be less technical, and they’re more focused on the business impact, the governance and the oversight during an engagement. If you have a technical question that’s focused on specific technology challenges during your engagement, you’re usually going to provide those questions to the technical contact listed in the planning documents. The technical contact is the party responsible for handling the technology elements of the engagement from the target organization’s perspective. For example, this might be the technical director or a senior information security architect that’s going to work directly for that targeted organization. It is going to be their job to know the target organization’s network inside and out, and they can help the penetration testers understand any boundaries or constraints that may appear during the engagement. While the primary, secondary and technical contacts are usually going to be available during working hours to assist your penetration testing team, they are rarely going to be the first people that you’re going to call if something bad happens at 3:00 AM during a penetration test. Instead, you’re going to contact the person or role that’s listed as the emergency contact inside of your planning documents.
Now, the emergency contact is the party from the target organization that’s going to be responsible for urgent matters that occur outside of normal business hours. Sometimes, the emergency contact may also be the technical contact or even the primary or secondary contact. But this does depend on the size and the scope of the organization. For example, many of the organizations that I’ve done engagements for in the past had people working 24/7 in the target organization’s security operation center. In those cases, our emergency contact was usually the on-call SOC lead that would be able to mobilize the proper technical experts to fix any issues that may have happened during the engagement. For example, let’s say you tried to run an exploit against a web server at 2:00 AM, but that exploit didn’t work properly and instead, it crashed their customer-facing web server. In this case, you’re going to want to contact the emergency contact to notify them that the web server is now offline and needs to be rebooted or restored from a known good backup.
Remember, when you think about the different communication paths, they’re also going to be used to dictate not just who to contact, but how to contact them. During an engagement, some organizations will have the penetration testing team contact the primary, secondary, technical and emergency points of contacts using phone calls, text messages, a private chat tool, emails, an internal website or portal, white papers, or anything else that may have been directed inside of your planning documents. For example, in one of my previous organizations where I used to run large-scale penetration tests, we had a website set up that was able to track the progress of the different penetration tests that were being conducted at different portions of our network all over the world.
That website was used for deconfliction of different engagements so that it was easy for trusted network defenders and testers to easily communicate if those defenders found something that appeared malicious, and then you need to find out if it was a known penetration tester trying to exploit that system, or if it might be a real malicious attacker from outside of our organization. Since we were a large organization that had often 5 or 10 or 15 different penetration tests happening at once, using this kind of a centralized internal web portal made a lot of sense for us, but I’ve also seen other places where a simple phone call or text message over to the organization’s point of contacts was used instead. It really depends on how the penetration testing team and the target organization want to set up their communication paths for that engagement. And this should really be decided all the way back in the planning and scoping phase of your engagement.
173. Communication Triggers (OBJ 4.3)
In this lesson we’re going to discuss the different communication triggers that may occur during a penetration test or engagement. As you can probably guess, there are lots of different things that could happen during an engagement that might cause us to stop what we’re doing and communicate directly with the target organization. We call these communication triggers and these triggers include things like the delivery of status reports, critical findings and indicators of prior compromise. Now, first we have status reports. Status reports are going to be used to provide regular progress updates to a primary, secondary and technical contact inside of a target organization during the engagement.
During your planning and scoping you and the client organization will need to determine how frequently those status reports are going to be delivered. For example, I’ve commonly seen status reports provided on a daily, weekly or monthly basis, depending on the length of the engagement and the amount of activity that’s going to be occurring. For example, when I was overseeing a long-term engagement that was designed to simulate an advanced persistent threat over a year-long period, we had agreed to provide a status report once a month for the first three months, then we moved to once a week for the next six months, and then once a day for the final three months as we started increasing the red team activity that we were performing against that organization. These status reports can take many different forms, depending on how the client prefers to receive them. Personally, I’ve used ones a are as simple as an end of day email that I send to the client with three different sections. This includes what did we do in the last 24 hours, what is the plan for the next 24 hours, and is there anything blocking us from achieving that plan or any issues that need to be raised to the client. Now in other engagements, we’ve used daily standups where a client was briefed in-person on all of those three areas. Again, this is an area that’s going to be tailored based on the needs and desires of your client organization. Another form of status reports are essentially gate checks that are going to be put in place between stages of your engagement.
In these status report briefings, the penetration testers are going to brief the client on the current status, and then ask for permission to move into the next stage or portion of an engagement. For example, you may brief them that you’ve identified 23 forward facing web servers and you believe you’ve completed all of your enumeration of those. Now you’re ready to begin moving into the attack and exploit phase against the first three web servers so you’re going to present the current status of your enumeration and provide them with your plan of attack for their concurrence and approval because those servers are all customer facing and they could have unforeseen impacts to the business during your exploitation of them. The second type of trigger involves critical findings. Critical findings occur when a vulnerability is found that could pose a significant risk to that organization.
When these are found we might need to stop our penetration test and tell the organization immediately about that vulnerability so they can mitigate or patch the vulnerability and prevent a real-world attacker from exploiting it. In these cases, we don’t want to wait a few weeks or months for us to finish our engagement and present them with our finished written report before allowing them to fix this kind of critical vulnerability. So instead we want to provide them with this out of cycle report so it can be resolved much quicker. For example, if I was running a scan against a forward facing web server that could be subject to a remote code execution vulnerability and there’s a publicly available exploit available for that vulnerability inside of Medis exploit, I would definitely want to stop and tell that organization about it immediately so they can mitigate it before a major cybersecurity breach occurs on that web server.
The third type of trigger involves the reporting of indicators of prior compromise. An indicator of compromise is a residual sign that an asset or network has been successfully attacked or is continuing to be attacked. So if you are able to exploit a given host or server on a target organization’s network, but then you discover that somebody else has already gotten there first because you identified this kind of indicator of compromise on that system, you would then want to stop immediately what you’re doing in the assessment and notify the target organization’s points of contact according to the previously agreed upon communication plan.
After all, if there’s an indication that another attacker, hacker or APT has already gained access to the network, you don’t want to confuse the situation further by continuing with your attacks and exploits as part of a penetration test. Instead, you want to pause the engagement and depending on the scope of your work you might shift to an incident response or recovery mode to help the organization contain and recover from that previous attack. Remember, anytime there’s an indication of prior compromise you need to stop, talk to the organization and figure out if they want us to continue the engagement or if they would prefer for us to begin helping them to preserve the evidence on those systems and then pass it over to a cybersecurity analyst as part of the incident response.
