Doing More with Less

Regardless of the industry you're in, whether it’s healthcare, energy, telecommunications, finance, or anything else, if you're reading this article, you've been affected by the current economic downturn. Thousands of information technology professionals have been laid off from their jobs in the past year. Even Microsoft announced that they will be cutting up to 5,000 jobs over the next eighteen months. Those fortunate enough to keep their jobs will be struggling with reduced budgets across the board and will have more work to do and less money with which to do it than you've ever had before. In trying times like these, it may be tempting to cut corners by reducing or eliminating your application security budget. Like skipping visits to the dentist, though, the dollar you save today may cost you ten tomorrow, or worse.

First, consider that in hard economic times, the ranks of criminals don't decrease; in fact, it's likely that as more people lose their jobs and benefits, some will become desperate and turn to crime. There have been widely reported stories of recently laid-off workers burgling homes and robbing banks. Admittedly, we're not going to stop these types of violent crimes with increased software-security spending. However, several organizations are seeing a similar increase in the rate of white-collar cybercrime. In October, the FTC issued a warning stating that "online scammers are taking advantage of tough economic times" by sending phishing emails tied to bank mergers. Special agent Darren Mott of the FBI Cyber Division stated that the FBI has seen increased attacks on specific, high-profile targets like CEOs and CFOs, noting that "cybercrime is recession-proof."

Given that it's likely that attacks against your applications will increase and also unlikely that your security budget will see a corresponding increase, how can you continue to improve application security? The answer is simple: you can save money and be more secure by adding security earlier in the development lifecycle. Far too often, organizations think of security like frosting on a cake.  It’s something that can just be “brushed on” at the very end of the development process. These are often the same organizations that cut security altogether when release schedules threaten to slip, but that's a subject for another article. The problem with this is that the further you are into the development process, the more costly it is to fix security vulnerabilities.

For example, suppose that you developed a shopping cart Web application that keeps data about the current state of the cart in hidden HTML form fields in the page. You ironed out all the bugs and then sent it to your security penetration testers to be checked for security before it shipped. Fifteen minutes after you sent it, they noticed that one of the parameters being stored in the hidden (but user-changeable) form fields was the item price. Thirty seconds later, they were filling up their shopping carts with brand new plasma TVs for one dollar each. You're now forced to go back and redesign the application, potentially throwing away weeks or months of work, thus requiring a whole new cycle of architecture, implementation, verification, and penetration testing.

Again, the solution to this problem is to introduce security earlier in the development lifecycle. Instead of brushing security on at the end, you need to "bake in" security from the start. Before you even write a line of code, spend some time threat modeling your proposed design. Use the STRIDE threat category system (Spoofing/Tampering/Repudiation/Information disclosure/Denial of service/Elevation of privilege) to help brainstorm potential threats to your application. There are several threat-modeling tools that can help walk you through this process and that are free to download, so they won't break your budget. After your design work is complete, continue baking in security during implementation. Use secure coding libraries and avoid dangerous methods such as JavaScript eval. Perform static and dynamic analysis as often as possible, preferably every day or even every build, by integrating your analysis engines with your build server. Again, there are excellent, free security-analysis tools if you don't have the budget for commercial ones.

You should also resist the temptation to save money by skimping on security. Not only is it penny-wise and pound-foolish-the criminals certainly won't be scaling back their efforts any time soon-but it's also unnecessary. By spending a little more time thinking about security up front and integrating secure coding practices and tools into your development lifecycle, you can help prevent big expenses down the road.