Are you worried that the recently revealed Heartbleed OpenSSL vulnerability will expose your customers and application data? Well, there is good reason to worry. 2013 was dominated by the largest ever attack on 152 million Adobe records, followed by a South Korea event in August that leaked another 140 million. The Target breach, which compromised 110 million credit cards, rounded out this scary trio.
Only part way through 2014, this year is already shaping up to be another horrible year for compromised data. With the widely publicized large-scale data leaks, there has to be a better way to secure sensitive data and applications. Secure programming, combined with more sophisticated network separation, might well be the answer we have been looking for.
Traditionally, IT security has been a combination of user authentication, network firewalling, and data integrity testing. The so-called defense in depth approach to security treats threats as if they come from outside a network. Most networks are still fundamentally architected with a hardened exterior and a relatively soft interior—think toasted marshmallow rather than hard candy.
The truth is that the threats come from anywhere and by any means. In 2013, hacking accounted for close to 60 percent of the incidents and 72 percent of the exposed data. Unfortunately—and surprisingly—17 percent of the incidents were self-inflicted accidents. Still, there is a clear pattern of pursuing large pools of valuable sensitive data. Hackers are smart; going after big targets such as large retailers and financial institutions takes about the same amount of work and is far more rewarding.
Looking at the data as it flows through the systems, the most likely source of data breaches is a combination of flawed applications vulnerabilities (Adobe, Heartbleed, SQL injection, Pinterest API) and cracks in network protocols caused by various forms of IP address (DNS exploits) and port spoofing (Denial of Service Attacks).
Since networks by their very nature are designed to be at least somewhat open, securing the underlying programming platform seems like a more promising approach. There are a few options to choose from. The best option is Opa, a secure coding platform built from the ground up with security auditing as part of the compile process. Most of the popular languages have widely available methods for writing secure code, but they need to be applied rigorously by developers who understand the risks.
Sadly, it looks like Heartbleed is far from the first—and will surely not be the last—of the vulnerabilities uncovered in the escalating cyber data war. Securing your applications at the code level by using secure programming techniques combined with a security-oriented programming language goes a long way to close a long standing gap in data and application protection.
