Establishing Lines of Communication Part 2

Video Activity
Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *

Already have an account? Sign In »

13 hours 9 minutes
Video Transcription
hello and welcome to another penetration. Testing, execution Standard discussion. Today we're looking at part two of establishing lines of communication and so picking up where we left off. Our objectives are to discuss incident definition, to discuss status, report frequency and to discuss protected communications.
So with that,
let's go ahead and pick up where we left off.
So let's talk about incident. What is an incident by definition? So the National Institute of Standards and Technology
defines an incident as a violation
or imminent threat of violation of computer security policies, acceptable use or standard security practices. And so this is not just the scans, testing and activity that we do in real time. This could be a person violates acceptable use from an administrative standpoint. They go to a site they shouldn't have gone to.
That's an incident.
Um, they attempt to access a folder that they should have accessed.
That's an incident. Whether or not that was done maliciously or accidentally is, you know, classified First is an event where we try to figure out what happened, and then if we find it was done maliciously, that's an incident.
But that is a totally different discussion than what we're having here on incident can only occur or I'm sorry. An incident can also occur on a physical level. So when we do physical penetration, testing and we attempt to access the facility, um is that reported?
Do they know that I tried to get into the facility? How does that reach the security team? How is that reported on Documented all of those things playing into incident response and kind of threat mitigation, risk mitigation activities. So the target organization should have different categories.
So different categories and levels for different types of incidents. And so I've seen
folks do that from 1 to 5 where one is low, fives high are very high. They do it on a scale of load a high
s. So it just depends on what the organization does.
And, uh, what categories?
Incidents are put into each of those levels or whether or not they do it based on financial impact. I have seen where
a critical incident or event is when a certain monetary value is hit with respect to recovery and damages. And so
when you're evaluating an organization's incident response plan, taking into account acceptable use, security policies, standard practices and whether or not they scale
incidents on this could be a factor in determining overall majority.
Now let's talk about status report frequency. So this is important because
we initially established that communications is key to success in customer satisfaction and client satisfaction.
So in this case, reporting to the client regularly is a way to keep them engaged. So it keeps them aware of testing progress, where things are and how things were going and whether or not they'll be surprised by something is key.
Um, now, frequency really is set by both parties and should be fulfilled by the tester once that is established. So this is really based on overall test length
and stop.
But once you establish, um, these procedures air this reporting frequency, you should ensure that all reports are delivered on time. Nothing's more unprofessional than committing yourself to a report report frequency to find that you're missing those deadlines or that you're not reporting it all
That could lead to client dissatisfaction and overall kind of
distrust of your capability. And so if you're going to establish reporting frequencies, just make sure that you can meet those
and again there's there's something that I used to be told and that I believe in, and it's not surprising the boss in this case, the client is the person that you're providing a service to. And so if you can avoid surprises, if you can give them kind of a heads up,
you know preliminary results indicate that we may have the capability to compromise the system, and we're currently going through
the process of attempting to do so. If that's a part of the scope and you're providing that feed back in good faith,
then if it shows up on the report and it doesn't surprise him, that allows them to prepare themselves for kind of how they're going to respond to their supervisors to their executive team and how that's going to look so
definitely a way to keep customer satisfaction up there.
Now let's talk about protected communications for a moment. So it's best to remember that there is the potential for testing information and communications to be misused by a threat, actor or malicious insider. So while you're trying to build a risk profile while you're trying to understand
what could go wrong within an organization,
it's best to also remember that someone may be there
already. You may not test or c all systems that this organization uses in your scope. And so there could be a malicious entity that is already present in the network. Now, if they've got access to mail servers, things of that nature of some of this stuff will be in vain.
But all communications in a digital fashion should be encrypted. Methods can include encrypted mail, email separate, secure mailboxes can be used here. You could have, you know,
repositories that set up that is encrypted and secure telephone communication face to face meetings. And then if you deliver
a final report, that report can be encrypted with A S and provided in a secure method. So all of these things have to be considered, and you should always establish clear terms on what should be communicated and how it should be communicated upfront. So I have worked in scenarios where
client attorney privilege
has to be maintained. And then I'm working with
a legal representative for an organization, and that dictates very much so. The text that must be included in my emails, the manner in which I communicate information is key. The manner in which I read write my report and do the footer and the footnotes on those reports
is key to keeping them maintaining that privilege
so that all has to be taken into account up front. So establishing clear lines of communication upfront in writing in the contract in the scope
is key. The last thing you want to do
is accidentally provide sensitive information, confidential information in a manner that was not discussed her that was not approved. And then you inadvertently exposed that information. It's also important to remember that in most cases, subject lines taglines, things of that nature are in clear text.
So if you're using email communication
or providing files for review,
that you not provide context in that subject line or in that file that could be extrapolated and then used for malicious purpose, like in a report naming the name of an exposure or vulnerability as the subject of
the email or the name of the file that is the report
a threat actor could use an information or 1/3 party can use that information to potentially cause harm to the organization. So always keep those things in mind when you're communicating with your client.
So let's do a quick check on learning. True or false, it is not necessary to report the status of the project to the client.
So take a moment to think about that.
And in this case, we're saying it is not necessary to report the status of the project to the client. So in this case, that is
kind of false. It could be true, depending on whether or not you and the client have a discussion in the current says, I don't want to know anything about the project, but in most terms communication is key.
Reporting on a regular basis is keep. Providing a status update is key to keep in the client engaged and satisfying. So in the context of this particular question and discussion in his false
now, true or false,
it is necessary to ensure that data encryption and all communications follow the client's requirements and that those requirements are clearly defined up front.
So several components to this question to take a moment to review,
pause the video if need be. So in this case, we're saying that it is necessary to ensure that data encryption
and all communications follow the client's requirements. And then those requirements aren't clearly defined up front. In this case, that is a true statement. We must ensure
that the clients
communication intentions
as faras reporting how we report in what format we report, whether that be a phone call, whether that be a face to face meeting once every two weeks, whether that beak encrypted email communications, whether that be a printed, not printed but a digital status report in a secure container be provided once a week.
However, the client wants to communicate that
and receive those updates should be established up front
and understood upfront.
If we were to make a mistake and exposed confidential information or communicate in a manner that was contrary to what the client requested, that could open us up to issues. So understanding those things up front and establishing them in a contract and in writing is critical to success and client satisfaction.
All right, everyone. So in summary, we discussed incident definition. We looked at status report frequency, and we looked at protected communications and why that's important. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again. Sin
Up Next