hello and welcome to a penetration testing execution standard discussion. Today we're going to go over the technical report areas and components within the reporting section of the Pee test standard. So let's jump straight into our objectives. So we're going to discuss what the technical report is and these sections within that report.
So let's start with what the technical report is. So the technical report will communicate to the reader, the technical details of the test
and all aspects I'm components agreed upon as key success indicators within the pre engagement exercise. The technical report section will describe in detail the scope, information, attack, path impact and remediation suggestions of the test. Now
this is being written for a technical audience. And so, unlike the executive summary, this is a very detailed on an in depth
all of the areas that we previously mentioned in the goals everything that we talked about as far as exploitation post exploitation, you're gonna cover all of those facets with evidence and information in this report. So some of the sections as follows Introduction section of the technical report is intended to be an initial inventory of
personnel involved in the testing
from both the client and penetration testing team
contact information assets involved in testing, objectives of test, scope of test, strength of tests, approach and threat grading structure. So all of this is a general introduction to the overall technical report. The people that were involved, the things that we were trying to achieve,
what the overall aggressiveness of the test was in the approach
and the grading scale we used to quantify risk and are threats
now information gathering. This is where we provide intelligence gathering and information assessments are the foundation of a good pen tests, as we have discussed. And so the more information the tester eyes about the environment or the more informed the testers about the environment, the better The results of the test will be so in this section,
a number of items should be written up to show the client the extent
of public and private information available through the execution of intelligence gathering. And then we get into passive and active intelligence again,
conveying to the client
how much data did we get without sending traffic to the network through Google through d. N s and things of that nature how much information did we get sending things to the network and so both passive and active reconnaissance and intelligence gathering?
We want to lay out exactly what we were able to find and what was of concern and what should be noted and addressed. Now. The vulnerability assessment again
is the act of identifying the potential vulnerabilities, which exists in a in a test and the threat classifications of each threat.
In this section, a definition of the methods used to identify vulnerabilities as well as evidence and classifications vulnerabilities should be present. So in addition, this should include the classifications levels,
technical vulnerabilities, logical vulnerabilities and an overall summary of the results for that particular assessment.
Now exploitation and vulnerability confirmation. So that should be confirmation. Is the act again of triggering the vulnerabilities identified on the previous section to gain a specific level of access to the target asset? So once we validate that vulnerabilities air good,
we move into the exploitation phase. All of that we want a document. Timestamp provide snippets of and Ford to confirm the status of skins and scan results from our vulnerability analysis phase
post exploitation. We
one of the most critical items in all testing, of course, his connection to an actual
impact on the client being tested. So we want to sink on vulnerability to an export to a result that could produce impacts a while. The section above relates the technical nature of the vulnerability and the ability to successfully take action against the full post. Exploitation
helps us to tie the ability of exploitation to actual risk,
right, so there could be risks with a vulnerability. There could be risk with an exploit, but showing someone that we exploited a system and what we could get to provides risk
now risk exposure wants the direct impact of the businesses qualified through the evidence. Of course, in an existing vulnerability, exploitation and post exploitation section, the risk quantification can be conducted. So in this section, the results from the above areas
our combined with risk values, information, criticality, corporate valuation and derive business impact from pre engagement areas.
Then this will give the client the ability to identify, visualize and monetize the vulnerabilities found throughout the testing and weigh those okay resolutions against their business objectives. And so again, if we don't provide them with something to measure our way these things against,
they'll make the decisions that they think are best, and if they're not sure, they may not take any action. So by being able to provide risk scores and await,
we can then give them the tools they need to be successful and to mitigate risk.
And then you'll provide an overall conclusion. So this is the final overview of the test. It's suggested that this section echoes portions of the overall test as well as support the growth of the client security posture. So it should end on a positive note
with the support and guidance to enable progress in the security program and a regime of testing sash security activity in the future to come. So you want to do kind of a comment? Sand, which opened with good notes,
give him all the stuff in between that could be good, bad and ugly. Give him something good at the end to closing off a good comment sandwiches, I like to say and make sure that they walk away from the engagement feeling empowered, aware of what's going on and with the tools to make change and reduce risk if we've given them those things and they could walk away and make an impact.
Then we have met our goal of risk identification and risk reduction.
Now, in summary, we discussed what a technical report is,
and we went through each of the given sections just doing Ah hi overview of information that should be in each. The introduction, information gathering passive and active intelligence, vulnerability, assessment, exploitation, vulnerability, confirmation, post exploitation, risk exposure and the conclusion
All of these things are important in a very strong
and powerful report. But again, modify this based on your company's best practices mount if I this based on what you're currently doing, look at some different templates and then make a decision on what you think is going to be most beneficial to your client meeting their goals as well as your goals to reduce risk and assist
your clients. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.