ClearNet Security

Like everyone else I’m hearing the drum beat getting louder – penetration testing as practiced by most today is considered a moribund service for pay: its value to businesses diminishing.

The chaos and confusion besetting all involved in security work due to how each participant defines popular security services doesn’t appear to be heading toward sanity any time soon (i.e. what is a pen. test to you?).

I keep getting hit with the same type client inquiries that Chris Nickerson recently received and posted on twitter the other day:

I fired off a couple comments.

I recently watched Eric Smith’s and Dave Kennedy’s B-sides presentation on vimeo and then read Dave’s blog entry on Traditional Pen Testing is Dead.

For the last year I’ve been spending way more time within the high level recommendations section of my reports and on the phone than in previous years – this coming from my personal frustrations clueing clients in on the sheer variety of ways an attacker can cause harm to their business.

Note: I’d be remiss here not to say I have liberally borrowed content from others – much of it recently from Richard Beijtlich’s blog and Mandiant’s blog and webinar series.

Like the process others’ go through when writing a penetration test report I would spend considerable time reviewing vulnerabilities and reducing the volume of the details into something digestible.

I don’t do that so much now. For example, today if I scan a client and discover a crazy number of vulnerabilities then I try to jump out of the vulnerability mud quickly. It’s much easier to ask the client if they have a patch management program: if the answer is no, you tell them to get one, if the answer is yes, then you raise the problem flag.

More to the point, my recommendation section now reads more like a kick start to maturing incident response (I think pen. testing should be more of an activity to test incident response (aka red team, but maybe without active resistance) http://blog.clearnetsec.com/2007/09/24/flip-the-reporting-and-get-the-customer-to-speak

In any case no matter what I was originally hired to do I like to put content like below in each report to stimulate conversation:

• What do we do if we discover malware on a critical system?
• What do we do if we are unable to explain particular log events or strange activity on a critical system?
• What do we do if a critical resource becomes unavailable?
• What do we do if sensitive data we store begins showing up in public?
• What do we do if we suspect a trusted or internal person is causing harm?

I have yet to discover a client that answers the above questions as Mandiant recommends for how you should answer them.

• Mandiant’s “State of the Hack” webinar series: http://fred.mandiant.com/SOH/SOH072010/lib/playback.html
• A Mandiant blog entry on the challenges of remediation if an attacker is successful: http://blog.mandiant.com/archives/1260

I also like the threat-centric approach, so I often add in the following questions:

• What are the most important assets and why?
• What threats worry the team the most?

The chart above is great for stimulating conversations with executives. They typically start rambling immediately about what on this list worries them. Even better, it immediately adds clarity to what you’re trying to accomplish as they ponder how each of these threats may impact their business.

Obviously I’m cherry picking from various formal security activities, but for clients new to maturing their security beyond addressing vulnerability scan reports, it works.

And given the propensity of most businesses to think of security only in terms of their servers (à la Chris’ tweet), I make sure to point out what wasn’t tested:

Your business and common threat tactics:

• Servers on the public Internet: tested
• Application Security: minimal tests performed
• Social Engineer: no tests performed
• Phishing: no tests performed
• Client-side: no tests performed
• Wireless: no tests performed
• Physical Security: no tests performed