I see other departments in my company go through several different revision cycles to review new projects, but…
when it comes to writing secure code, the programmers usually just release it when it works and worry about security later. How can I advocate for a secure code review process, and how many layers of review do you think are necessary to release secure code?
Humans are visual creatures, and what users — and the boss — all see when they look at a website is the work of the graphic design team and their interpretation of the marketing and sales departments’ brief. This is why those departments are allowed countless revisions, and usually larger budgets, than those responsible for security. They also tend to have more influence over what goes into a website, and they rarely allow security to compromise its look and feel because nobody sees security.
The benefits of good security only come into effect once the site is live and the design team is off on its next assignment. The costs of remediating a software security flaw often fall to the operations team, not development.
Even then, it’s a lot harder to assign any monetary value to security in the way the effects of a new online marketing campaign can be tracked by the hour using web analytics and goal conversion results.
Making the case for secure code reviews
Arguing for more secure code reviews can be hard. Many well-known sites have been hacked due to vulnerabilities in their design, with seemingly little damage to their public popularity. Many of these website vulnerabilities are common and preventable ones that lead to cross-site scripting and SQL injection attacks, and, often, automated code reviews can detect these flaws.
There are some cases you can refer to that highlight why security is important. For example, credit rating agency Equifax suffered a catastrophic data breach that exposed the personal data of nearly 148 million U.S. consumers; the breach was attributed to a known Apache Struts flaw that the company failed to patch.
Software app design, testing and deployment require infosec pros and system administrators to work together.
Perhaps a more persuasive argument would be the increasing number of laws and penalties that come into play if a data breach results in data being compromised. The European Union’s General Data Protection Regulation (GDPR), which is scheduled to take effect in May 2018, is one such example. GDPR proposes steep fines — as high as 4% of the organization’s global annual revenue or €20 million — for an organization’s failure to comply with basic safeguards.
U.S. health insurance company BlueCross BlueShield of Tennessee was fined $1.5 million for a data breach in 2009 that violated the HIPAA Security Rule and Health Information Technology for Economic and Clinical Health Act breach notification requirements. This fine came on top of the $17 million the company had already spent on the investigation, notification and protection.
In addition, Sony’s European arm was fined $390,000 following the hacking of its PlayStation Network online database.
Those figures have only increased in recent years as many major enterprises have been subjected to both government fines, as well as data breach lawsuits from customers, employees and users.
Could your organization survive this type of fine or the cost of cleaning up after a similarly devastating data breach?
Secure code review best practices
Stories like these — and the real monetary losses that resulted — can get the attention of senior managers. Your goal should be to persuade them to adopt a secure code review methodology or process, such as the Simplified Implementation of the Microsoft Security Development Lifecycle (SDL).
This is a version of Microsoft’s widely adopted SDL aimed at development projects with limited resources. SDL will help make security and privacy a priority throughout all the phases of the development process, with many of the associated tools, such as threat modeling tools and vulnerability scanners, being either free or open source. The Microsoft SDL can also show when and how to perform secure code reviews prior to an application’s release.
This threat modeling exercise can identify potential security issues and components of the application that should be subject to closer inspection. By finding the areas that have the most potential to introduce vulnerabilities early in a project’s lifecycle, the organization can take ownership of them while they are relatively easy and cost-effective to resolve.
You can also introduce a Model-View-Controller development framework, which splits application development into three distinct spheres so projects can move forward without different teams delaying each other, hopefully reducing the frustration of those not used to building secure applications. In addition, some organizations perform a static analysis of the software code, which is a requirement under Microsoft’s SDL.
Finally, I would aim to have a senior manager responsible for signing off on the successful completion of each security requirement, and have the appropriate developers included in the incident response plan should vulnerabilities come to light once the application is released. This is always an effective incentive to ensure everyone focuses on writing secure code the first time around.