Internal PenTesting approval forms

[RoamingEmpire]

I've been trying to research the key points to include in any formal sign-off for internal redteam/pentesting activities.

The proverbial "get out of jail free" card.

I can find a number of NDA and other agreements that pentesting consultancies post on their site, but nothing for an internal resource to use.

[CISOScott]

Here is my take on these "permission slip" forms. Do we ask an external hacker to only hack us from 9 to 5 during normal business hours? Do we restrict them from using Phishing attempts or social engineering tactics during their tests? Do we require all hackers to obtain permission for any thing they do while attacking our network? If we do not ask these of any hacker trying to breach our network but we do require these from our own internal red team/penetration test teams, then we are not performing a red team/penetration test, we are performing a vulnerability assessment. There is a huge difference between the two. One shows you vulnerabilities that are on your network (vulnerability assessment)  and the other shows where your network is vulnerable (penetration test/red team test). True red team testing will expose what you need to fix on your network, restricted red team testing will check a box saying you had a "red team" test done.

Now if you are at a facility that has people that are approved to use deadly force, then you definitely want to ensure there are rules of engagement with a de-escalation explanation section. If you have an overly cautious team from upper management and legal, it can take way longer to schedule the test than to actually perform the test. 

I once had a red team engagement. Total network compromise was accomplished in 3 days. It took 6 weeks to hammer out the agreements to let the team in and begin. 5 weeks and 2 days of lost time that could have been spent in fixing the problem instead of trying to limit the potential damage of the team that they MIGHT have caused.

Of course you have to be realistic. No one wants to be the person that took down the network, but then again, if your network is that fragile that a simple red team test can break it, wouldn't you want to know that and start working on a fix to it rather than have an attacker bring you down? What would you rather be in front of the CEO explaining?

1) We performed a red team test and it broke our network. We are working on fixing the weaknesses. No internal damage was done and no data was lost. We have found out that our backup and restore processes work as planned and we will be operational again in XX hours. or

2) We were hacked and it broke our network. We do not know what we have lost yet with regards to internal company data. We do not know the extent of the damage. We do not have an estimated time of return to full functionality. I have no idea why we (which really means you) were this unprepared for the attack.

[RoamingEmpire]

Thanks CISOScott for the detailed reply.  

Without going into specifics of why I'm looking for examples of the form, these pen testing activity forms are meant to be an extension of an existing vulnerability management program. All too frequently system admins don't believe the results of vulnerability scans, even when triangulating the vulnerability scanner, vendor patch notes (with specific file version information) manual system review and the patching software solution. I'm not looking to check a box, I'm looking for shore up risk in the environment.

I agree 100% that a malicious actor would never ask for permission ahead of time. And yes, if I did bring something down during a test, while proving a point it would also cause a whirlwind of activity if nothing was known ahead of time.

Also, if I have a network that contains devices that through their failure could result in an unsafe working environment those potentials need to be communicated and planned.

Here's what I've been able to come up with so far through other research.  Key data points:

background: what the test is, what is the goal.

process: rough outline of a routine pen test workflow

rules of engagement: systems included; testing window; participants and contact information; deliverables

IT staff emergency contacts: technical system owners

Support contacts: helpdesk staff

PenTester contact information

Change Control #: if applicable

Approvals: upper management approval.

[JoePete]

I would also raise it is not just a matter of absolving internal testers from a blanket of corporate policies or liability but also possibly heightening their responsibility. For example, pentesters may very well obtain user credentials or intercept data that employees believe to be private. Perhaps they should be held to a higher standard and penalty than general employees. That's a corporate decision, but it really gets to HR more than technical issues.

Therein lies the conundrum of pentesting. While depending on your environment it may range from recommendation to a requirement, you really need to have a whole flock of ducks in a row to do it right or you end up being your own greatest security threat. 

I would also suggest corporate policy should expressly prohibit any testing activity. As example, imagine the employee cyberstalking a co-worker and his or her claim is that the spyware they played on the victim's computer was in the context of "network testing" etc. In the same vein, the form you are working on should be very specific about permitted activities. Then you should test the testers. Prep them on their methodology and the limits. Again, it is a lot of work to do it right, but it's like doing a live test of bullet-proof vest - you don't get a second chance if you screw up.

My personal view is pentesting gets overblown. Most organizations already know their weaknesses. If they don't, then management probably isn't communicating with or understanding the right people.

[CISOScott]

Pentesting should only be done by qualified individuals, not individual users. Anyone that is not a designated pentester is performing hacking (which in this context means unapproved hacking of the network).  Also, if you are hiring an outside pentesting firm you should not use the same firm more than 2 years in a row. After 2 years you should try another firm. If your firm doesn't suggest it after two years you did not hire a reputable pentesting firm in the first place.

If you think pentesting is overblown you haven't seen a good pentesting team. You may have seen individuals who were claiming to be "pentesting" (and notice I put in air quotes because what they were doing really wasn't pentesting).