OWASP and the RSA Conference 2014

Update: 

Much has happened since. After a lot of discussion, OWASP Board voted to cancel their co-marketing agreement with RSA for RSA 2014. They also voted to deliver training and talk at the conference, if permitted to do so. 

While my disagreements with the underlying arguments remain, I must admit I am a much bigger fan of OWASP's style of functioning than I was. To put it mildly, I had grossly misunderstood OWASP openness. In retrospect, I wouldn't have used the same strong words as I had, if I were to do it now. 

To preserve what was, and the nature of my misunderstanding, I'm leaving the post below as is. Instead of messing here, I'll write a separate post on the developments.

The OWASP Board apparently decided to participate in RSAC 2014 by way of offering a 4 hour free-of-cost AppSec training. Apparently "developers' benefit won out". 

Here is a twitter conversation on this topic: https://twitter.com/EoinKeary/status/419111748424454145

This was an opportunity for the world's most influential and inspirational AppSec organization to take a principled stand that:

1. the industry will not stand by and watch the foundations of trust and technology be eroded by patently malicious intent (such as that of subverting crypto products and standards); and
2. the industry will not stand for unwarranted universal surveillance using national interest and anti-terrorism as flimsy excuses.

However, the wise old men/women of the board have chosen not to take the high road. They didn't say, "what's a few developers' one lost-opportunity when the whole world is reeling?". They didn't say "this will only encourage other pillagers of infosec public trust, assuring them that OWASP and others will find glib rationalizations to look the other side while they earn a few bucks on the side". 

In short, they copped out.[edit: I was under the impression that the decision was made, done, closed. However, in a welcome development, the matter has been re-opened for wider discussion within OWASP. I will update this post when the status changes.]

Update: The OWASP email discussion on this topic is available at: http://lists.owasp.org/pipermail/owasp-leaders/2014-January/010549.html

Relevant blog post: Robert Graham's Why we have to boycott RSA

I've never been invited there as a speaker. My protest and opinion may neither dent RSAC nor OWASP. Yet, I believe it is important for me and other like-minded people to clearly say NO.

As a first step, I've offered (to my co-leads) to step down from the local OWASP Chapter leadership, unless the situation changes. It is a sad day for me, as I worked hard to establish this chapter only recently. We are doing a very important public service. The principles of open community and open source are as dear to me as the InfoSec profession. Yet, I don't believe I can compromise and tell RSA or OWASP that "it's okay".

At this time, I haven't considered any other possible action. I'm looking out for more though. 

On a Slippery Road in the Name of National Security

Two very important things happened at the recently concluded Cocon 2013. Not surprisingly, the media missed these, in favor of more "mainstream" news focusing on the celebrities and visible initiatives.

1. The Deputy National Security Advisor, Sh. Nehchal Sandhu gave a largely statistics & routine talk with the notable exception of a superb pronouncement:
   

   "We will not go down that road" 

   He was referring to the recent events surrounding NSA's surveillance and its fallout in the US (civil rights outrage) and in the rest of the world (Brazil, anyone?), including India (such as new guidelines on email usage, etc.). This statement was made to convey that the Indian Government would not indulge in the kind of tactics that NSA and FBI are being accused of.
   
   Why is this important? It portrays a commitment from the Government to act with a level of wisdom and maturity that has been hard to find recently not just here, but in most parts of the world.
   
   
2. A few speakers talked about the Government's collaboration with the hacker community. One of the talks included an unapologetic response to the criticism of this year's takedown of a malware's C&C Server at this year's nullcon -- announcing a new era of Government - Community partnership.
   
   On the sidelines of this talk was a much more sinister discussion. That some parts of the Government might be willing to take hackers for hire -- for ostensibly National Security engagements.
   
   On the face of it, it should not cause any concern, right? Not until you understand the implications, subtle and otherwise. How will this relationship begin, what pitstops will it make and how far will it go?
   An example: LulzSec (ex-)leader cooperating with the FBI.
   Another: Desi hackers join Indian Cyber Army. In this, there is even a mention of a lawyer wanting to change the IT Act to provide protection for "patriotic stealth operations". Of course, they might be talking about "usual" hiring of infosec professionals in cyber-defense positions... but there is enough to indicate otherwise too.
   
   There are enough rumours and murmurs on whole truckloads of East European hackers being allowed to flourish in the fond hope that they will provide the necessary "air" cover (and perhaps, tactical support) to their governments when push comes to shove in cyberwars. Are we talking about going down that route?
   
   National Security as a justification to do things that you wouldn't otherwise do is a very slippery slope. Once you start the journey, you have no control on the speed, direction or the destination. This is a route that argues that the means justify the ends. No doubt there will be people who argue that when our adversaries do it, we must do it too.
   
   However, I hope that saner voices such as Sh. Sandhu's will prevail.

On a different note, I do hope that our above-board educational hacker groups (such as garage4hackers) make every effort not to tip and fall into the wrong category. A few beers, some boasting and a vulnerable target are all the ingredients that enthusiastic young blood needs to cross the line. There are always rationalizations that can be made after the fact. Including misplaced patriotism.

The dark side of Vulnerability Research and Sale

[edit: Altered the title & reworded "Exploit Research" to "Vulnerability Research" to align with common use of the words]

Imagine this:

1. You have two neighbors, both are highly skilled in surveillance & breaking in. 
2. Both of them thoroughly scan of your home (from far, of course) voluntarily. 
3. They finds a few flaws that you wouldn't know -- but would allow a thief to bankrupt you. 
4. One of them wants to sell this information and make money that befits his expertise. To you, to your builder, or to the government. (interesting question: what happens when none of the three agree to buy?)
5. The other never mentioned any of this to you, but directly put up the "exploit" for sale to the highest bidder in an "open market" meant for highly specialized buyers (of the type that you aren't).

Is there anything wrong with this scenario? You bet there is.

This is what is building up in the InfoSec world under the garb of Vulnerability Research. I am sure we all understand the logic of "we need to make a living", "we have a right to market our skills" and even "we have a right to get rich".

That "We tried until 2010 to convince vendors to decently pay researchers without success" almost sounds noble.

But to say "L is for Liberties, and exploit sale is a liberty" as VUPEN (@VUPEN) CEO Chaouki Bekrar (@cbekrar) shamelessly tweeted is a bit too much for me.

Where is this going?

Vulnerability Research (as in the scenario above) is turning into a thriving market. Though some players are spouting KYC and self-regulation to support their activities,

"... ask your favorite vendor to pay researchers $100K per 0D ..." and
"... I confirm we don't sell to repressive regimes ..."

it rings hollow.

Of course, other players are simply discrete about what they do -- and don't promise any such restraint. That is surely no less of an issue.

Statements like

"... You are not a judge, and we are not in a court ..." and
"... we really don't care nor give a shit about your thoughts on exploit sales ..." 

just about sum up the attitude and any shatter any pretense of ethics. It appears that "there is no law against it, so we'll do what we please as long as we can get away with it" is lurking right underneath this "business model". At this rate, sooner than later, we could see specialized "Vulnerability Research" markets come up in the fields of ATMs, Credit Card terminals, and more. They would of course, begin by selling the exploits "at a decent price", "only to non-repressive governments" and with "thorough Know-Your-Customer norms".

We are witnessing the birth a thriving market of Vulnerability Research where anyone more skilled than you are is free to poke around and blackmail you.

As the market expands, people have more incentives to turn into Vulnerability Researchers (not to be befuddled by the more innocuous term "Security Research") -- and there is little or no reason to exercise any restraint.

I'm sure it has occurred to many that:

• there is no reason to cap the price at $100K per 0D
• there is no reason (yet) to commit to self-regulate

I don't think we can afford to look the other way or merely smile and indulgently admire the admittedly considerable skills of these open market "Vulnerability Researchers".

In all this, let us also not forget that Governments are paying our (taxpayer) money to actively grow this market. Oh yes, I forget. The Governments are only doing this to protect us. Strangely, I don't feel particularly safe on this account.

More on building secure IT systems

Last week, I wrote how the current system (of designing and developing IT systems) is broken. How business will simply not be able to support high-levels of post-facto InfoSec expenditure that is necessitated by increasing sophistication (and automation) of attacks. That we need to build security into our systems at design & development time.

It appears that I am not alone in this thinking. I came across a paper (in the SANS library) by Dan Lyon - apparently as a part of his GIAS GSEC Gold Certification effort - titled "Systems Engineering: Required for Cost Effective Development of Secure Products (PDF document)". In this he builds a case to take a Systems Engineering approach to build-in security into products; and that building security right from design makes more sense than otherwise.

He also refers to others writings and talks on the subject (though as a means to introducing the need for systems engineering approach), such as:

• Software Security: Building Security In (2006), by Gary McGraw
• The Security Development Lifecycle (2006), by Michael Howard and Steve Lipner
• At the SANS Rocky Mountain 2012 Conference John Strand: "... the current state of information security is broken; new approaches are needed for information security. Many current practices for achieving information security are applied after a product has been developed. Examples such as firewalls, intrusion detection, intrusion prevention and antivirus are all external systems to what organizations use to conduct business..."

While it is gratifying to see that I am not alone in this line of thinking, I wonder why so little progress has been  made in building more secure IT systems from ground-up. Perhaps it is because of one or more of these reasons:

1. Addiction by tradition: We are so deeply habituated to current development processes that we are unable to break free from them.
2. Demand-side ignorance: Businesses don't see (and consultants are unable to make them see) the perils of current approach; and hence they are not ready to pay. In the absence of demand (from businesses), supply chain isn't ready to invest and gear-up.
3. Supply-side ignorance: The word hasn't quite spread into the developer world! Yes, even in today's hyper-connected over-communicated world, this can happen. Too many people have yet to adopt new digital media consumption methods; and those who have, are subjected to information overloads that much gets filtered out.
4. Industry Ostrich posturing: This could be deliberate (vested interest by current approach's beneficiaries) and/or simple denial. 

What do you think are the reasons?

I am exploring the possibility of me doing something about it (instead of merely whining / writing about it). Stay tuned.

Built-in robustness in IT Systems

Yes, it is true. We are woefully short of InfoSec professionals. Recent events (including the spate of #5Nov attacks) bear it out. We need more (and better trained) professionals to protect our systems; better technologies and products. One-way gateways, passive DNS traffic monitoring systems, more sensors, more analytics, you name them.

Yet, we are missing something fundamental in the picture.

Would you knowingly build your home with termite-infested wood and water-soluble walls? Would you  forego doors and locks and ignore building safety codes - just because you can add a swanky swimming pool with the money you save?

Would you then insist that we hire more security guards, buy more fire sensors, build protective shields on the outside and install props to shore up the insides of this hopelessly vulnerable home?

Absolutely not. Yet, we do it every day, when building our critical IT systems. Aren't we?

Well, the problem isn't so obvious with IT systems as with our homes. Neither the systems nor the weaknesses are visible to the naked eye. We can therefore make convenient assumptions on what is good enough security and still not lose sleep at night.

For decades, innovation and IT systems have romanced each other - and focused nearly exclusively on functionality, ease of use, etc. Yes, there have been developments in security - but almost all of them are post-facto solutions. Not built-in security. Not robust-by-design. Not in every component of the system.

Thanks to this approach, we are soon reaching a point where the IT sprawl will collapse on itself in a catastrophic sequence of events. Unless we shift our focus to the process of building the systems in the first place.

Networking technologies are beginning to show this trend in a small way. Computing, not so much. Operating Systems are only scratching the surface with the notable exception of OpenBSD and Kaspersky OS (is it named yet?). Databases, Application Platforms and Application software themselves haven't even begun. How many software professionals have even heard of secure coding? 0.001%? Or less?

We must change now and change quickly. Businesses will not be able to bear the burden of spiraling costs of post-facto and ineffective security solutions for long. We may not perish yet, but that is nothing to celebrate.