hello and welcome everyone to another penetration. Testing, execution Standard discussion. Today we're getting into questionnaires Part two. So picking up where we left off. Our current objectives are to understand questions for physical penetration, testing to understand social engineering questions, to understand questions for business unit managers
and to understand questions for system administrators.
So with that in mind, let's go ahead and pick up where we left off
now. Physical penetration testing That's been in the news here lately, with some testers having some issues with a county government or local government with respect to what was in scope and what was not in scope on the test.
And so it is even more pertinent that we take the time to fully that out and understand what we're doing and that we involve all parties in the test.
So it is important to understand how many locations are being assessed, but also
ultimately, that's a W who
is going to be responsible. So who am I talking to for these locations? Who is going to be the point of contact because
a client may engage you to do a test, but they may not speak for all of the individuals in the organization or they may not have total authority to authorize a test on the location.
And then it's also important to understand if the facility is shared. And so the reason for that is is much like the wireless device that shared and has maybe a guest account or something, or a guest S I d.
Same thing would go for a facility. If you are breaking into a facility is a part of the test and it's approved. But the client doesn't own the facility.
Do you really have permission to try to break into the facility? So that's important to understand? And so that's why we want to know what floor's Aaron scope or how many floors in this case and then which are in scope. And so
the reason for that, again is being very specific in definitive on what is in scope and what is not, especially when the facilities not owned by the client now the use of lock picks and bump keys. We have to consider that in most areas those air considered burglary tools
and so you'd want to
make sure that you check with counsel, make sure that the building is in fact owned by the client that they have the right to give you permission to use such tools in their facility.
The way that I look at using these types of tools in a physical security or pin testing engagement is I would prefer, in these cases tohave the client present the individual that owns the building, the individual that has given authorization to do the testing
and just demonstrate whether or not the locks could be easily picked. And the reason for that is is that you have a witness.
You have someone there that has proper authorities toe authorize you to test that, especially if they own the building and, you know, provide maintenance for and everything like that. To me, that's just a safer way to do it, keeping these in your pocket and sneaking around trying to get into a building after hours or during the day.
Mike mentions in some trouble with that local law enforcement,
so just consider that when thinking about those components
and then knowing if all physical security measures air documented is great, because if they're not
and there's an alarm or you trip something or there's cameras that are monitored by the police.
Any of those things should be taken into consideration for physical testing because the last thing you want to do is tripping alarm. The police are called. They've got you on camera. They don't know that the test is happening. The client failed to mention that. Then you're spending the evening in jail because you get out of three, get out of jail. Free card didn't work and they couldn't be reached over the phone. So
be very, very critical of physical security testing. And make sure that you thoroughly document everything within scope of that to an excruciating degree, if you can.
Now, social Engineering kind of wants its own questions, you know, depending on the organization, whether there are long form health care provider, whatever the case may be, that may be a factor in how the test should be conducted. And so it's always great to get a list of e mail addresses that would be
approved for social engineering attacks, and we'll talk about pretexting and some of that later on.
But it's important to understand who this is being performed against, because if they say just performing against everybody and then you fool the CEO and you embarrass the CEO on this person
may have been able to authorize the test, but the CEO didn't want to be fished. And, uh, you trick him and get their credentials.
That can cause some issues. Is their phone numbers that they'd like to have tested? And I'd like to draw a line here.
I would not test personal devices
is a part of social engineering if they can't provide you with phone numbers that are for company assets, in that the cell phone belongs to the company or the phone number belongs to the company and the distant end, it's avoid phone or something like that.
I would be cautious because if you do social engineering against a person who has a personal device, a personal cell phone,
and you managed to maybe get them to click something that results in tthe e copying of data from a device or skimming of credentials or any number of things
you could be, you know, violating that person's rights, that person's privacy and that could put you at risk. So always be diligent masking about those components.
And then again, this could be a component of the physical test as well. But will we be doing any social engineering to gain off the unauthorized physical access to the device or to the environment? And is that approved? And so that is important to note that is, such testing approve? Because if the answer is no,
and physical access isn't a part of it, then there's really no point in trying to gain you do social engineering for physical access to the environment.
Now Business unit manager questions are also important. It's good to understand where management is at mentally with the test, what their expectations are and what their view is as far as critical systems and things of that nature. So
the first question to ask is, is the manager aware of the test? And that's very important because a person may have
administrative capability to approve a test that they may not be the system owner,
and so that can cause some internal strife and some issues that that person says, Well, yeah, Bill could say that the test could be done, but ultimately I'm responsible for the system and its well being. And if something were to happen to it. It would be my neck on the line, so I should have been the one that approved it. You want to You want to avoid those types of conversations, and so understanding that dynamic
is very important. Um, asking what the main data or what is the main data that would create the greatest risk if it were exposed, corrupted or deleted? That's two fold when you start to do risk analysis and you start to look attack vectors and what would be a high profile
information for the organization. You also want to understand
what you need to be diligent and protecting. If any of these data sets were exposed, could that cause undue harm or issue with the organization? And so knowing that up front will kind of helped you to dictate what tools you should or should not use and how you should handle data in the organization
now, are there testing their validation procedures in place to verify that business applications are functioning properly?
This is also again important from a risk management standpoint in that if you were to attack or, you know, do some type of exploit against a nap, lick a shin and it were damaged.
How would you know if it were functioning properly beforehand? How would you know if there were any special modifications that they've made to make it run and that the slightest week would cause issues?
Knowing those things that front will do, do well and protecting you and again, it also helps you in building or his profile
and then our disaster recovery procedures in place for application data again, this is important to know, to fold. From a risk management standpoint, you can give feedback on why disaster recovery planning is important and why those procedures should be in place.
And then on the other end of that, if you go to do an attack, it would be excellent to note that if they don't have those procedures in place, that the likelihood that they have working backups may not be there as well, and that recovery may be cumbersome for them. So if you damage
a system inadvertently or have issues with an application, that then needs to be recovered and they don't have that data
that could be harm to their environment or to their well being, so you want to take note of those things.
Now our last section has to do with system administration questions again, This is just kind of a primer that you can use to develop further questions. Are there any systems which would be characterized as fragile? And that's important because
if a system is scanned with a port scanner and it goes down, then is something we need to know if denial of service is not a part of the test and we don't want to bring systems down, we need to be aware of these systems if they've got an old printer that will
have issues or not work properly if it's scanned. If you attempt to attack a system that crashes, the service's and it goes down for a Knauer
or boots up slow, whatever the case may be,
it's good to know these things that we know how to proceed. Are there systems on the network which are not owned or are least that is important? If they are not the owners of the system than they do not have the ability to approve testing, you need to clearly define
if a network segment is owned by 1/3 party. If the equipment is owned by 1/3 party of the Iess PM's the firewall.
Whatever the case may be, you need to properly that that system vet its ownership and come up with a plan to either test it within the given parameters or remove it from the test entirely.
Now is any system monitoring software in place is important for two reasons. One will get into base lining response, which is a part of penetration, testing, understanding how quickly activity is detected and how a client responds to a potential threat actor. And then, if this information or these systems are managed by 1/3 party,
should we inform them? How will we inform them? Can we do testing against that system? So that's also important to know
backups being tested on a regular basis and when was the last time they were stored are important for protecting yourself and understanding whether or not if data were lost or had an issue? Could the environment recover? Could the business recover accordingly? And so that's good to know, because if you could run into an issue where data was
compromised or potentially damage, do the system rebooting or failing,
then you need to explicitly define the risks that are associated with the testing prior to the client signing off on it.
So let's do a quick check on learning
what would be a reason to use it a questionnaire or to use questionnaires for engagement scoping. So in this case, you're going to pick two responses. Take a moment to review, and we'll go from there.
All right. So looking at the first question to provide a better understanding of what the client is looking to gain.
Second, to provide a high as high Acosta's possible on the test to understand why the client is looking to have the test performed to provide legal protections for the test. Well, the 1st 2 that I would get rid of here are to provide legal protection for the test
while scoping and getting an understanding of what will be tested and agreed upon that with decline is one thing.
It is another to have legal documentation that protects you, said the questionnaires do not provide that, And then,
while you may want to charge a lot of money, it is not really ethical to try and overcharge your gown. Someone on costs you're really using these questionnaires to ensure that you provide a fair rate
and ah, set of ours. That is going to be Emma Emma, biblical to both parties and be beneficial. So
A and C are the two best answers here provided better understanding of what the client is looking to gain and to provide our understand why the client is looking to have the test performed.
All right, everyone. So in summary of today's discussion, we discuss questions for physical penetration, testing. We discuss social engineering questions. We discuss questions for business unit managers, and we looked at questions for system administrators. So with that in mind, I want to thank you for your time today, and I look forward to seeing you again soon.