Google recently announced it would pay up to $1,000 per ‘leet' or elite bug found, and a mere $500 for ‘regular' bugs in its open source code - Chromium. You may ask yourself why Google would do that. There is a good reference article on Security Focus, but I think the answer is simple - because Chromium is the platform which drives Google. Chromium is what makes Google, Google. The more Google encourages hackers - ethical or not - to find issues they can fix, the better Chromium is.
This got me thinking about our client's web-facing and internal business applications and how application developers are required to now drive their business. For a smaller client, it is an e-commerce cart used for on-line purchases; for our larger Fortune 100 clients, the application drives financial client services in the tens of millions, or more. The premise is the same - if there are bugs in the code - the business is at risk. So why not engage others to find the bugs before the bad guys do?
We still tend to think of business as brick and mortar buildings with HR, Executive Row, Marketing, Operations, Finance, etc - and, oh, by the way, Information Technology (IT), Information Security (IS) and Audit departments. In most companies, IT/IS is a cost center critical to daily operations but not often thought to drive business. Unfortunately, that type of thinking is so 1990's and may be costing the company money. As more companies use applications to drive revenue, and not just to support operations, they have to invest not only in information security but more specifically, application security. I know, I hear it - we don't have any web-facing applications that could put our organization at risk so this isn't applicable to us. Not so fast...any application that supports a critical business function - think about your financial or HR application - needs a robust Application Security program.
According to SC Magazine, over 80% of all Internet vulnerabilities are caused by poor application coding and security. If exploits for major programming codes can net bounty hunters over six figures, where and on what should your company focus?
Start by thinking of information security holistically and evaluate where and how mission critical people, processes and technology currently operate to support your business. Think about your Software Development Lifecycle (SDLC). Usually developers and programmers are incented to deliver code that works and is operationally bug-free; they are not necessarily incented to develop code that works, is bug-free, and is securely coded.
Evaluate whether you need to update your current IT/IS mission and the current SDLC. Of course this is the boring part - no new software or hardware platforms to buy and implement. As we say, no "new bright and shiny objects to play with," but secure coding, while not flashy, can help add more money to your company's bottom line. Reward the developers when code is delivered on-time, on-budget and coded securely. If you use external developers, write secure coding and testing clauses into the contract as a requirement, and include warranties when you can.
Then, make sure you have evidence that they followed your requirements. Hold developers - whether internal or external - accountable. During the next release cycle, perhaps incent the testing team (or your entire IT/IS team) by using the ‘Bugs for Sale' model. If you are a high-profile, high risk target organization, I suggest you look first to internally incent the team and then validate by a third party. Our experience shows us that clients who use secure coding practices, train their developers and programmers, and provide incentives to find bugs have less exploitable vulnerabilities when they go live. Coding never looked so alluring...
Anyone have bugs for sale?