Secure coding: the invisible elephant

The last couple of weeks, I've been trying to vaguely connect the dots between social computing, cloud computing and traditional process based systems. There are multiple legs to the story but one that had pretty much escaped my attention was the security angle. I will not claim any special expertise in this area but I do know it is a vital component in business software development. Let's look at recent event and reports:

The big news noise today is that Google has made an apps engine available for cloud computing.  Meanwhile in Las Vegas at the Gartner Emerging Technologies Conference, Larry Dignan notes that while enterprise is definitely interested in the Google cloud:

But there’s a hangup–they’re wary of hosting things in Google’s cloud...I’ve heard at least four IT types say Google isn’t ready for the enterprise, but a Google App Appliance, just like the one Garett advocated a few weeks back would get them off the fence. I’m convinced that an App Appliance would be the ingredient that could put Google on the enterprise map.

In the meantime, Dana Gardner discusses 'platform as a service' and in a transcript from a discussion between Phil Wainewright and Alex Barnett of Bungee Labs which Dana moderated, he says:

Building a robust infrastructure to do this is very, very hard. That’s one of the reasons why a lot of enterprises are holding back, and are therefore missing agile opportunities. That’s one of the roles that the PaaS can provide.

Hold those thoughts.

If you read Larry Dignan's Crimeware as a service from yesterday then you'll already know that sophisticated criminals are developing techniques to commercialize online theft. We should not be surprised because roll on to today and Finextra say that Symantec is warning about online supermarkets where anything from stolen credit cards to full identity credentials can be bought for knockdown prices. In the wake of years of security threats, such stories seem almost incidental. Then I read this blog post by Mary Ann Davidson chief security officer at Oracle. Ms Davidson is angry at what she sees as a a failure to educate computer science students about secure coding. She starts:

In the vendor community, there is a low rumble of discontent about our supply chain's current lack of a "secure development lifecycle." I'm not talking about other software suppliers (for example, vendors who supply toolkits or components we embed) though at Oracle, we do vet these suppliers' security practices before we incorporate their technologies into our code.

What I mean by supply chain is the universities who supply CS graduates to IT vendors. There is no "secure development lifecycle" in the vast majority of universities' degree programs - that is, security is not "baked into" graduates of relevant programs (e.g., computer science) throughout their degree programs. And that is a problem, perhaps the problem plaguing the software industry. All the other security remediation taking place in the software supply chain (such as multiple security point solutions, vulnerability analysis services, and patch management offerings) largely stems from the fact that most software was neither designed nor built to be secure. And to that point, developers don't code software from the perspective of an attacker. Many believe security is a task for someone else ("it's behind the firewall so we don't have to worry!"); but their code is a target and will only be more of one in the future.

Ms Davidson then goes on to say that as far as Oracle is conerned, enough is enough. In a strongly worded letter to leading universities, she says: "We strongly recommend that universities adopt secure coding practices as part of their computer science curricula, to improve the security of all commercial software, and ensure that their graduates remain competitive in the job market. In the future, Oracle plans to give hiring preference to students who have received such training and can demonstrate competence in software security principles." (My emphasis added.)

Ms Davidson's long article is well worth studying. As far as she is concerned, the universities are dragging their feet, looking for research funding to justify the additional classes where she sees them as well funded and focusing on the wrong things. I wondered whether this was Oracle saber rattling or indicative of the reality behind current (and past) software development. I went out to colleagues and asked: "Can anyone tell me about secure coding?" I received a solitary reply from a person who worked with the military and for those reasons must remain anonymous. I asked whether Ms Davidson's allegations are founded in fact or whether they have merit. These are the answers I received over email:

Regrettably Mary Davidson is right. A few examples. Things like having a very secure system from the customer side but then having an internal database maintenance web app that had *no*security.  They depended on the firewall.

A vendor I contracted with once to do xml processing for data flows had all kinds of security for things over the commercial WAN used between vendors but almost none for the portal they opened to allow travelling salesmen to access the same WAN to save money.

But by far the biggest and simplest thing that still exists is that a lot of SQL injection attacks are possible because most people only think of that attack vector for public/internet facing attacks and don't realize that secondary databases which feed data to the primary are unprotected.

Most of the press/attention are to the frontline/direct - SQL injection, DOS, spoofs, etc - all kinds of books on those but yet most computer developers *never* read them until they work for a company where someone was bitten by a failure. But in my experience it's the indirect issues that are the "fun" ones. When your in the commercial space and your using commercial tools, the security *most* of the time is pretty good.  But sales people normally push for access to indirect data and if you use any type of data farming, that's also a source of indirect data.  Realize it's a security breach even if you don't have data modified - all I need is a single backup tape to harvest hundreds of userid's and/or passwords.

Don't even get me started with laptop theft and the number of times a developer took the easy way to give sales people their data by copying the whole database but only giving the sales person a filtered view. Fortunately now databases are just too big for that to be common - but it happens.

Perhaps after years of hearing security stories, we're too numb to care and simply hand over the cost in higher insurance premiums and remediation costs that are hidden inside IT budgets. I then turned my attention to SANS, an organization referenced in Ms Davidson's tirade. Here I found a top 20 list of security vulnerabilities, among which was:

Web-based applications such as Content Management Systems (CMS), Wikis, Portals, Bulletin Boards, and Discussion Forums are used by small and large organizations. A large number of organizations also develop and maintain custom-built web applications for their businesses (indeed, in many cases, such applications are the business). Every week hundreds of vulnerabilities are reported in commercially available and open source web applications, and are actively exploited. Please note that the custom-built web applications are also attacked and exploited even though the vulnerabilities in these applications are not reported and tracked by public vulnerability databases such as @RISK, CVE or BugTraq. The number of attempted attacks for some of the large web hosting farms range from hundreds of thousands to even millions every day.

I'm sure that readers will agree the reported scale of vulnerability is staggering. Especially as the development technologies referred to relate directly to the current wave of 'web 2.0/enterprise 2.0' style applications that marketers and social media pundits are throwing at anyone who will listen.

Do any of these well intentioned people stop to think for one second about what they might be unleashing on the enterprise? Has it occurred to anyone that by introducing potentially insecure systems in a bottom up revolution that IT might be handed a rat's nest of problems for the future? Is anyone giving serious thought as to how these informal systems will be integrated (as they surely will) with the transaction systems which are already subject to problem? How will those problems be mitigated in a cloud computing world? Is it any surprise that IT is skeptical about cloud and social computing?

I don't want anyone to think for one second that I am raining on anyone's parade as we move towards more open forms of communication, learn to share and collaborate in fresh ways or start to experience the promise of lower cost computing. But let us not forget that all these good things live in the context of an existing and evolving software ecosystem. The outward facing social computing trend is not going away but I see precious little evidence of it being thought through beyond the ability to help companies market more effectively. If we cannot securely integrate with robust transaction systems, whether traditional on-premise or operated in the cloud, then as an industry we will have utterly failed.

Enterprise has invested trillions of dollars in software, sometimes robust, often fragile. You can argue that Ms Davidson's assessment is a belated reaction to years of neglect by the industry itself and a possible reflection of what might come at IT in the future. But the very fact she is prepared to stand firm for that future indicates to me that at least one senior software company executive recognizes the need to get serious about developing securely compliant software in which we can all have confidence. That should be applauded, even though I know colleagues will shoot back with tales about software bugs that are routinely released in new software.

In the meantime, I note that Alex Iskold has set out what he sees as the top ten traits of a rockstar software engineer. The ability to write secure code isn't mentioned once.

Endnote: I had hoped to speak with Ms Davidson to answer lingering questions but was unable to get a response before publishing. It is a topic to which I hope to return.