My Response to a Dangerous Idea

This post is in response to Jeremiah Grossman's latest entry titled "Legalize It (Hacking GOV and MIL websites)". Before reading the rest of my post, please read his first, which is here.

So to sum it up, such an initiative as the one he has described would be far from free, and I intend to explain my theory within the next few paragraphs.

One thing I'd like to state upfront is that I acknowledge similar activities are ongoing as we speak. I am not taking a naive and utopian view of how this stuff wouldn't happen regardless of whether or not it is legalized or encouraged. My underlying theme should be interpreted to be that opening this stuff up to the general public from legality and encouragement perspectives may not be the most cost-effective solution afterall, nor the safest, which I will tie up with recommendations for better solutions at the end of this post.

So why is this both a dangerous suggestion and an irresponsible one at best? First, Department of Defense systems aren't Paypal. They aren't intended to drive profits, but rather intended to support the needs of warfighters. It really all starts off with understanding the needs of the organizations in question, before making recommendations for what they need. Unlike Paypal, who can allocate as much funding as possible to tolerate increased loads being placed on their systems (downtime = lost revenue), many groups within the government survive on shoestring budgets, believe it or not. As someone who has been around the DoD for quite some time in his career, I can attest to the fact that legalizing such behavior would likely require many entities to upgrade their infrastructures to even come close to handling the likely volume of traffic that would be generated. Every script kiddie, and every researcher trying to make a name for himself, would be throwing tons and tons of traffic at targets that were never intended to handle such a considerable load. So rather than finding a few holes and smiling at the end of the day, you'll be denying legitimate and in many instances, critical applications, from being utilized for their original intent. An alternate solution to this would involve tons and tons of red-tape being placed around the initiatives in order to maintain some type of positive control, which in government terms = sucking the value out of the process. The very first time someone messes up by either testing during off-limit production hours, testing from an alternate source address that isn't registered, or DoS'ing a site, it'll be a real nightmare.

Secondly, consider what the ramifications would be for both legal and incident handling personnel. Imagine being an incident handler on an already undermanned team that was already overloaded with say X unique and credible leads to follow per day. Suddenly, you have X plus a million daily, with most of them being the result of loud and obnoxious traffic generated by automated tools. So should these groups simply say "ok, its legal...better not investigate this", or should they still do their jobs, which is to determine what may or may not be live and ongoing attacks, or what may or may not be pre-attack probing? Wouldn't this lead to attack identification efforts being increased exponentially? If this were to occur, what would be a definite side effect? INCREASED MANNING REQUIREMENTS!! The last time I checked, adding team members wasn't free.

Surely it isn't feasible to think that opening up and encouraging pentesting efforts by the general public would be without the risk of questionable entities going above and beyond the "engagement rules" set forth by the respective agencies. So instead of being able to state with confidence that any incidents that may occur are inherently true incidents, there would be a sudden blurring of what is real and what isn't. As if it wasn't already borderline impossible to keep up with pre-attack probing and actual attacks in the average security operations center (SOC), it would only get much worse. The result would not only increase the loads placed on incident handling groups, but also on legal personnel as well. Each case could have its own set of unique twists and turns based on the type of technology in use, and could quickly become very costly to pursue offenders.

There are some companies in this world that I'll agree that this type of open environment is well suited for. Twitter, Facebook, Google's myriad of online services....yes. These "big 3" are all in existence for the sole purpose of generating revenue. They are also very homogenous organizations in comparision to the government and DoD, which have very intricate reporting structures both within, and to external agencies as well. The "big 3" do not deter anyone from accessing them, and never will do so, because they are all profit-driven. Therefore, it wouldn't make sense to discourage this behavior. For government systems, it pretty much will never be the intent for the general public to have a want/need to access them. Public companies encouraging researchers and anyone else in between to test their applications, enable a collaborative community in doing so. It results in publicity, both good and bad. Publicity = garners interest. This is exactly what profit-driven companies want.

Government systems do not exist for these same reasons. The information contained within them is often classified or considered "sensitive","for official use", or "secret" and above for a reason. The collaborative communities putting forth research efforts and pentesting efforts should therefore come from within as well. Rather than opening pentesting and security initiatives up to the general public, it should be done in a controlled manner, such as paying for the talent to perform the work. In doing so, the work can be coordinated and optimized, so that testing is not detrimental to critical operations. My view is that if there is a considerable cost associated either way, it might as well be invested in a way that will ultimately lead to better processes being created internally, vice the same widespread dangerous coding and general lack of security that exists today. It doesn't make sense to spend a ton of money developing an application, only to place it online and then get knocked over 3 hours later by a script kiddie. The cleanup efforts are enormous, and the wasted time and resources in fixing bugs that should have been identified in development, is downright sinful. Bringing the true talent in, and paying for it, could prevent this stuff in the development lifecycle, as well as in pre-deployment testing. Repeatable processes lead to greater cost savings, as opposed to leaving it in the hands of the unknown and simply hoping for the best.

I do not disagree with Jeremiah's point that too few organizations within the government have the capability to perform rigorous testing on their applications. In fact, I praise him for making this point, and reiterating it many times through his blogging, Twittering, and press statements. It is certainly an issue that affects everyone, whether we realize it or not. You certainly don't have to be a warfighter to benefit from the increased security afforded to the ones keeping us safe day in, and day out.

-Jack