Tuesday, March 20, 2012

Pen Testing, commodities and 0day supply and demand

Martin Bos (@purehate_) asked an intriguing question over twitter the other day. Should 0day exploits be used in "standard" penteration tests. Some rightly asked to define what a "standard" pentest truly is, since scope could literally be anything you can think of. Josh Abrams (@jabra) responded with what is probably the best answer with "0day usage should match the maturity of the target." Beautifully stated.

But the discussion got my gears turning. Josh Corman (@joshcorman) blogged back in November 2011 about the concept of HDMoore's Law (http://blog.cognitivedissidents.com/2011/11/01/intro-to-hdmoores-law/). It's a great read and I feel very pertinent and accurate. The original Moore's law roughly states, depending on who you hear it from, that technology (i.e. the number of inexpensive tranistors that can be put onto a circuit) doubles every two years.

When you look at the IT industry as a whole, this law partially explains many business related bell curves - advanced technology has the innovators, early adopters,  early majority, late majority and laggards. Everything eventually becomes commoditized. Relying on a particular technology or skillset that your organization may possess advanced skills in to keep a competitive edge over your competition over time is a losing battle. Skillsets are learned. Technology advances and improves. Competition eventually catches up. In order to remain ahead of the pack organizations must continually find the next advanced technology to specialize in.

Corman's point with the HDMoore's law concept is that the advancement of the metasploit framework is lowering the cost of admission in winning and performing successful "standard" pentests. Business histories and frameworks dictate that that the advanced technology of penetration testing will eventually become commoditized. Pentest geeks can stop your whining now, we all know you are talented and always searching for new, improved and advanced methods of testing. That's not the argument. Cutting edge is still cutting edge. But once pentesting tools advance to the point that those of us who are neither exploit hunting hobbyists nor being paid to discover 0day vulnerabilities can compete with specialists and win engagements with the majority of non-"mature" clients, could the differentiating factor result in today's hardcore pentesting community to actively pursue the acquisition of previously unknown 0day exploits?

Supply and demand. Could Whitehat(ish) practitioners eventually significantly contribute to Blackhat revenue, GP margin and Operating margin just to stay ahead of the closing pack of mediocre pentesters using advanced pentesting tools? Thereby funding the work of the evil hackers?

Martin made a good point on an unrelated thread about hey, you make a neat argument but please back that up with a recommeded solution. There is no "solution" in this case (sorry, Martin). This is simple business modeling and evolution and you need to adapt accordingly. One path in that adaptation may lead to this particular scenario.

Monday, March 12, 2012

DLP vs. Auth: More Snakeoil?

Data Loss/Leakage Prevention (DLP) has been one of the hot buzzwords over the last several years. And it's a great idea - determine where your critical business data lives and actively enforce policy around it. Data in motion, at rest and in use, absolutely critical elements in ensuring enterprise business protection.

But is it, really? In terms of protecting business critical data, the most important element is first and foremost understanding where that data lives and breathes. That is absolutely where DLP infrastructure contributes the most. But once that business critical data is discovered, wherever it may live, is it not logical to then make the business decisions to allow said data to reside in certain areas and not others? Policies redrawn to dictate where critical data should reside and then, through alternative means such as, oh, authentication and authorization, allow access to such data?

Don't get me wrong. People will send CCs and SSNs unwittingly over email. This is not that argument. Few organizations have gone out of business for such breaches, so clearly these are not true business risks. This argument is focused on innovation lifeblood. Formulas, research, sales playbooks, medical breakthroughs, etc. Everything that contributes to a strong economy that we, as infosec practitioners, are accountable in protecting.

If we know where that data lives in the first place, the overarching overhead of customizing DLP systems to actively look for your specific business critical data is, to a degree, moot, now that we know where it is confined to, by enforceable policy, and can control access to via both standard and enhanced authen/author controls. AD controls what you can and cannot access, as well as who can take data and copy to removable media. At some point you have to realize that you cannot control persons taking camera shots of monitor screens that may contain business sensitive data. Assume the breach. Digitally mantrap your data such that only persons with advanced authorization has access to the sum of the parts. Limit you threat landscape and focus your controls on such persons, no matter how high up on the food chain they may be.

DLP systems have their place, but I believe that place is simply to identify the most important variable any organization needs to know in an effort to protect their business critical data - where that data lives. At that point existing controls can be implemented to enforce the business policies, restrict access to said data, redefine where said data should live and reduce the scope of threat vectors that have the potential to exfiltrate said data.

DLP - one time insight or ongoing overhead?

Sunday, March 4, 2012

More Compliance Sham-WOW!

I've said it before and I'll say it again. Compliance is a sham. Most are vague attempts at kinda hoping you'll make appropriate security decisions and protect people's data that reside on your systems. Others have very detailed lists of what you should be doing, which, from the business side of the house, is completely impractical to comply with so most organizations adopt a "we're doing our due diligence" mentality of trying to at least show small, annual signs of compliance improvement in hopes that if that low probability event accually occurs, they will not be held accountable because they can produce the appropriate "metrics" that tell the all too familiar tale of compliance costs vs. revenue and GP.

The latest Sham-WOW compliance movement has been introduced by several congress-persons, including Joe Lieberman, and boy is it a doosey. Jody Westby's story in Forbes (here) sums up most of it very astutely, but doesn't touch upon what I feel is a larger, underlying battle. We are rapidly approaching a very complicated paradigm shift regarding our national economies and who is responsible for protecting our national assets and interests. I've previously discussed the economic dangers of the theft of our innovations and how we are no longer (for the most part) in an era where our government can protect our industries by reacting with physical force.

Yet, the antithesis of bombing the daylights out of an adversary for cyber-stealing NASA secrets and the like appears to be applying more regulatory compliance to the formula. I can hear all of the equipment vendors cheering already. "Buy this device and you will be <insert the latest govt. regulation here> compliant." It's crap like this that makes my life more hectic in my attempts to un-"educate" people who have already taken the bait and are now chasing the carrot of compliance.

Compliance almost never means Secure, Secure almost almost always means Compliant. At this point I forget who even said that first (credit anyways). There was a time I felt it might take a few levels of governmental regulation to get to some semblance of Business Security, but no longer. Litigation is king, and even that has diminishing returns in this day and age of the "international mystery man", more commonly known as the C.H.E.W. factors.

Standards, people. And the lack thereof. We spend so much money investing on systems that will "protect" us from weaknesses that should have already been vetted in the actual application it is no wonder each and every industry is overwhlemed with thousands of vendors touting the latest and greatest solution to combating <insert APT here> in your enterprise. Focus on the root causes. Awareness and coding standards. Develop them. Enforce them. Don't buy software from vendors who aren't an active contributor to such standards, etc. I realize this is as much of an uphill battle as complying with some of the regulatory standards but at least it would actually make an impact.

Just be, as good infosec professionals strive to be, proactive about it. Don't be complacent and allow a bunch of aging congressmen who aren't really sure how to turn on their "tweeter" be responsible for developing another completely erroneous and uneffective infosec regulatory compliance standard just because we can't collectively troubleshoot root cause issues and become a community dedicated to actual problem solving, debugging and solutions.