Critical Control 17:Penetration Tests and Red Team Exercises

Published: 2011-10-26
Last Updated: 2011-10-28 00:09:40 UTC
by Rick Wanner (Version: 1)
1 comment(s)


Another diary compliments of Handler in training Russ McRee:
Penetration testers and red teamers rejoice! We have a control for you: Critical Control 17: Penetration Tests and Red Team Exercises (hereafter referred to as PT & RT for brevity).
A few thoughts in support of your efforts:
1)     Before taking on this activity, formalize it with management (in writing) to include vision, mission statement, and statements of work (SOW) in order to set clear expectations (and keep you from being fired or jailed). Prepare to write reports, and present findings. PT and RT activity is only as good as the dissemination of results and the subsequent remediation. Sure the fun part is going after systems and resources with permission, but the documented follow-up is just as important.
2)     A formalized process inclusive of best practices and documentation also supports PT & RT on behalf of compliance requirements (PCI, etc.). Trust me when I say, it’s a lot easier to win the argument for a PT & RT program when you can tell your leadership that it supports meeting compliance requirements. Yes, compliance is often a “min bar” but if it helps get your program underway, you’re winning right?
3)     A great resource and good starting point: Open Source Security Testing Methodology Manual 3.0
4)     If you’re going to red team, then blue team while you’re at it. A well-devised, concerted offensive engagement against your enterprise is also an ideal opportunity for your defenders to validate their monitoring and hardening practices.
5)     While it’s nice to have resident expertise, it’s hard to imagine that every organization has the resources to dedicate personnel exclusively to PT & RT, much as may be the case with dedicated IR resources. Often these duties fall on network engineers and systems administrators with a penchant for security. If so, great; how better to tune red team/blue team chops.
6)     The social engineering (SE) aspect of PT & RT activity inevitably includes an organizational political component you should be sensitive to. I’ll cut to the chase, people fall for SE tactics all the time and there is always shame associated with it. Making enemies will not help your cause. Devise SE tactics (educational intranet sites, metrics generators) that don’t necessarily automatically relegate people to the wall of shame/sheep. If you must actually compromise someone, dot your I’s and cross your T’s. Non-invasive recon for likely or ideal targets for whom management signs off before total pwnzorship is in your best interest. Again, your get out of jail free card is very important here. Malfeasance or anomalous behavior from systems belonging to your “victims” can then potentially be attributed to you.
7)     Virtual environments, while not ideal, make for an inexpensive test bed for PR & RT activity. Build attacker VMs (largely done for you; BT5 or Samurai WTF anyone?) and victim VMs (unpatched Windows, vulnerable LAMP, etc)
Have fun, but be careful.
What successes have you had structuring penetration testing and red teaming as a repeatable, sustained activity in your organizations? Let us know via the comment form.



-- Rick Wanner - rwanner at isc dot sans dot org - - Twitter:namedeplume (Protected)

1 comment(s)


Pen Test/Red Team testing will be more meaningful if it acknowledges more than 1 security layer.

I have been through 4 Pen Tests/Red Team Exercises. Every time, the summary only acknowledged 1 layer. The layer that stopped them. This is probably due to limited resources devoted to testing.

The tests would be much more effective and meaningful if it is structured to effectively test multi-layered defense.

IE, the Red Team tests until countered by a layer. Then both Red Team and Blue team acknowledge the counter. Then the layer is bypassed and the test continues.. Finally, the final write-up documents the relative effectiveness of each layer, and suggests improvements.

This may be the standard somewhere, but I have never encountered it. My experience has been that both testers and management only care that there is 1 layer preventing failure. This runs counter to everything I know about effective security.


Diary Archives