Hello and welcome to another penetration testing execution Standard discussion. Today we're going to be talking about establishing lines of communication within the pre engagement interactions. Now a quick disclaimer. The Pee test videos do cover tools. At times it could be used for system hacking,
so any tools discussed or during the demonstration that we may provide
should be researched and understood by the user.
Please research your laws and regulations regarding the use on such tools.
So looking are at our objectives for today's discussion. We want to discuss the importance of establishing lines of communication within your testing and with your customer. We want to discuss some emergency contact, does practices and look at ways that we can set that up and perform that.
We also want to discuss incident reporting. We're going to look at the definition of an incident.
We're going to discuss status report frequency as well as discuss protected communications and why that is important. So let's go ahead and jump into establishing lines of communication. So
communication is key to any successful engagement. Whether we're scoping discussing a contract, looking a payment terms, communication is critical and the customer interaction and approach to communications influences, customer satisfaction. And so
when you choose not to communicate, when you communicate at a bare minimum standard, it can really create former customers or create an environment where your customer does not feel comfortable or your client doesn't feel comfortable. And so it's best to remember that communications are a two way street.
Um, you have to be able to talk to your client and vice verse. If your business owner you have to be able to communicate with your tester.
It doesn't make sense that one party would have to do all the talking or would be the sole bearer of communications throughout the process. And so it is definitely a two way street. And so we'll talk about establishing lines of communication between ourselves as well as,
um, the customer having the capability to communicate back with us.
And then we have to be able to adapt readily to any situation. And so there are at Tom's circumstances that come out where communication may not be comfortable, where we need to think on our feet
and kind of be ready to provide feedback at that point in time, with maybe limited information and so we need to be ready and flexible
We need to respond in a timely manner. And so if we are given a circumstance or situation that maybe we don't have all of the answers up front,
we need to be ready to communicate what we do know comfortably on dhe. Then be able to provide a time frame
that we will get back with the client
on that particular topic or subject. And it's best at the time of giving them the initial bit of information to have a plan for follow up or a way to communicate Follow up.
let's talk about emergency contact. Best practices. So in this case, we're contacting a customer or target, and doing so in an emergency is a vital thing to remember. So having established methods for how you reach the customer and how the customer reaches you is a must.
In any engagement, we have to be able to do this, and so contact information should be included for all parties in scope of testing. Such a list should be shared with everyone
in that list, so everyone should have the capability to communicate with everyone that's involved in the scope of testing as well as, um, the individuals who may be responsible for certain parts of the test or formal enough with us.
So let's look at the first area with respect to putting that together. So with each contact, we want to know the full name of the individual. If it's a larger organization and there are seven bills, are there three Bob's or theirs to souse? We've got to know the full name of the person
as well as their title and operational responsibility.
And so the first person on your list may not be the CEO. They may be one of five emergency contacts, but we may not want to contact the CEO first. There's usually a chain of commander
ah way that certain things should be done within an organization based on the client's feedback. But those two things are going to be critical to ensure that we identify the appropriate party and then authorization to discuss details of the testing. Activities have not already specified should be provided and understood.
Two forms of immediate contact is recommended for 24 7 feedback, so this could be a cell if they still use a pager? Ah, home phone. If possible, we should have at least two ways that we can immediately get in touch with this given person. And then if we test the two
ways and we find that they're not reachable, then we circle back around to the next person on the list
and then one form of secure communications and data transferred. So we'll talk about some ways that that works. But essentially, this would be like a secure mailbox, a secure platform in which we can drop data or information, so a way that we can do that that is not plain text and would put that data set at risk
is going to be critical here. The last thing we want to do is share
plain text information or share information in a state of emergency.
And then we accidentally suppose, exposed data and put that client's confidentiality integrity of that data set at risk, especially when it's our information that we're sharing
now in lieu of a specific group.
I'm sorry, in lieu of a specific person, a group is acceptable, and so notice that we're specifying a person so this could be the help desk or operations can replace one emergency contact on Lee. If it is staffed 24 7 again, we have to be able to reach someone
24 7 during the testing period. And the reason for that is that the longer we let something sit,
the worst the problem could become. And this includes the testers. And so in this period, that 24 7 availability is applicable to the testers Well,
and so this list should include all testers in the test group for the engagement. So not all the testers that the organization has is a home.
But the testers within that group that air performing the work for the client
there should also be the manager of the test group. And so that way, there's an escalation point. If the testers cannot provide feedback or they're not available, they can step up to the manager
now, to technical contacts at each organization is also appropriate. So if, um, I need to get in touch with somebody who has some where with all of the far wall infrastructure or if I need some assistance because we think that a server has crashed,
we need to technical resource is there. And then, um,
too technical contacts at the customer's sight are important. So this would be like my organization's technical contacts as well as the customers and then one upper management or business contact at the customer. And so if I need an escalation point outside of the operations group or the help desk group,
then that person needs to be specified in this particular list as well. Now, incident reporting is a component of penetration, testing and understanding. How the organization that you're testing responds to an incident is a part of that. So
procedures for the target should be discussed prior to engaging in the test.
This is a way to evaluate current incident response capabilities of the organization. And so
again, we're not just trying to break into a system as penetration. Testers were trying to establish
the ability of an organization to respond to a threat actor and to mitigate that risk or to reduce the impact of that that threat as quickly as possible. And so
it's important to also have those members aware of when testing may occur. So the security team doesn't call upper management in the middle of the night
thinking that they're under attack.
And this is important because again it can establish the maturity level of the organization with respect to its security practices. Um, and it can be taken into account in the overall final report that you would deliver to the organization again. Our goal
is to reduce risk. Our primary goal is risk reduction, and so incident response capability,
the ability to detect to identify a threat, contain it, eradicated all important
to the organization being tested and to the overall risk profile of that organization. And so
if we go through the entire process and they have a security team that never detects anomalous activity,
then that could be problematic for the organization that we tested. Because if they didn't see what we were doing and we were given permission and maybe we were noisy in that process,
then what could be, um, something that you know could have gotten in there prior to us? So, you know, there could be other issues, so that's important to note.
All right, everyone. So in summary today, we discussed the importance of establishing lines of communication. We discussed emergency contact, best practices, and we discussed incident reporting. So with that in mind, I want to thank you for your time today. And I look forward to seeing you again soon.