According to the classic film “It’s a Wonderful Life,” an angel gets its wings every time a bell rings. The modern-day corollary is that a customer loses his or her credit card data every time a programmer introduces an application security flaw into code.

Don’t be fooled by the severity or scope of the problem because of the quaint comparison: Half a billion records were compromised in 2013, according to the recently issued 2014 IBM X-Force Threat Intelligence Quarterly. Take a look at the graphic depicting publicly disclosed information compromises since 2011.

— IBM Security (@IBMSecurity) February 25, 2014

If you unfocus your vision and look at the graphic as you did those Magic Eye pictures that were popular in the 90s, you’ll notice that the number of incidents increased from 2009 through the end of 2012 and persisted through 2013. A few other observations that stand out are the following:

• SQL injection, identified by the yellow bubbles, has remained a lucrative compromise vector since we’ve begun tracking public breaches.
• There are a fair number of compromises that go undisclosed, judging from the number of gray bubbles.

What’s not called out specifically in the graphic is that there has been an almost threefold increase in Java vulnerabilities since 2012. This isn’t surprising since Java gives attackers the opportunity to create cross-platform exploits — write once, deploy everywhere. We wrote about cross-platform exploits in the X-Force 2013 Mid-Year Threat and Risk Report: Attackers are optimizing their return on investment through operational sophistication rather than technological sophistication.

I gave a presentation on this topic at [email protected] (a side conference of IBM’s Pulse conference) to the developers in attendance. They were having a grand time learning how to program Raspberry Pis to control toy cars through a mobile app, among other fun projects; then I ruined the mood by talking about application security.

Costs of a Breach: The Inconvenient Truth

I hate to be the buzzkill, but we could save a ton of grief by finding security flaws in the development process, not to mention the fact that it saves our organizations tremendous amounts of money. When you look at the cost of fixing functional defects, it’s almost 100 times more expensive to correct them in production than in development. When you add in the costs of a security breach to the business, it skyrockets to $7.2 million — increasing by almost 9,000 times — due to:

• Customer notification/care
• Government fines
• Litigation
• Reputational damage
• Brand erosion
• Forensics investigation
• Cost to repair

Five Tips for Improved Application Security

I realize that it’s easy to be an armchair quarterback — or Scrum Master, as the case may be — and that eliminating security defects is an unreasonable expectation, but we can eliminate 80 percent of the consequences by simply focusing on a few tactics. With that in mind, here are my top five development practices to reduce the application threat surface:

1. Get trained on secure coding practices. Management should support and fund this effort, and it may require some back pressure — urging from the developers, QA and product management — to get them to buy in. There are training programs specifically for secure coding, ethical hacking classes so you can channel your inner attacker, conferences, mailing lists and an abundance of other resources to get your technical staff up to speed on security threats, countermeasures and defensive programming techniques.
2. Use only stored procedures for database calls. This step will help prevent SQL injection attacks, which abuse database statements sent as SQL command strings instead of using parameterized procedures. If you don’t understand how SQL injection attacks work, see step 1.
3. Sanitize user input. This step will go a long way toward stopping cross-site scripting (XSS) and cross-site request forgery (XSRF) attacks. Whereas SQL injection targets Web servers, XSS/XSRF targets clients by tainting the HTML that’s served to the browser. Again, if you don’t understand how XSS/XSRF attacks work, see step 1.
4. Integrate source and dynamic application security testing into your development process. SAST and DAST solutions aren’t substitutes for secure coding practices, but they will help you catch what you might miss; to err is human. Beyond the benefits of catching latent security vulnerabilities, these solutions integrate with your source control solution and can help train developers by giving detailed information about how vulnerability manifests itself. Application scanning solutions can also identify chronic defects so you can focus your training efforts.
5. Instrument granular and meaningful events and errors. One of the major reasons there are so many gray bubbles in the graphic on public disclosures is because organizations are unable to perform complete and timely forensics investigations. This is in part due to a lack of technology and process — no log management, SIEM solutions or not collecting the right telemetry — but many systems also produce generic or esoteric events.

Note that both steps 2 and 3 are specific to Web-based applications. Strong security practices should be applied to traditional server or workstation applications as well as mobile apps, but let’s prioritize the areas in which the compromises are happening today.

In the final analysis, we have the knowledge and technology to prevent the most common vulnerabilities from finding their way into our code. When integrated with up-to-date threat intelligence, organizations can prioritize their efforts based on contextual risk: What is the severity of the vulnerability, what is the value of the data to the business, what is the exposure to attacks and what mitigation controls are already in place? Let’s make it a goal to eliminate SQLi and XSS/XSRF vulnerabilities from enterprise applications; then we can work on the next attack vector, and the next, until we make it so expensive for the bad guys that they move on to something more lucrative — such as stealing from each other.