An alternate title for this post might be, “Software Security: Up Front, or Out Back?” In other words, are secure coding principles integrated into your software from the outset of development, or “tested-in” just prior to release?
It happens that a sizable—and not inconsequential—number of developers opt for the latter approach. But as the mounting data shows, that’s a really, really bad idea. “Ah, but developers have good reasons for doing so,” some may protest. And yes, they do, indeed, have reasons. But none of them, however, are particularly well-informed. The simple fact is software security just isn’t much of a priority for nearly half of software developers worldwide. Let’s take a look at five of those reasons that, in the end, turn out to be terribly misguided:
1. Secure application development is just too costly
If this sounds like you, you’ve got company. According to a recent Trust in Computing survey conducted by comScore (on behalf of Microsoft), thirty-four percent of developers say cost is the primary reason for not using a secure application development process. But wait a minute. Is no one in these organizations reporting the cost of fixing bad, insecure software after it has been released (or should we say, after it has escaped)? The fact is you’re going to pay for software security, whether it’s good, bad, or nonexistent. And bad and nonexistent cost more. A lot more.
Let’s look at the flip side to see why this is true. A study by the Aberdeen Group showed that companies adopting a “secure at the source” approach to development realized a fourfold return on their application security investments. “The clear takeaway,” the report concludes, “is that application security initiatives of any kind represent extremely good business value.” That sounds like even a mediocre effort will go a long way toward improvement.
The Aberdeen report also found that, among developers who follow secure coding practices, about four out of five application vulnerabilities are discovered and remediated before deployment. But the real import, the study claims, is this:
“The problem is not necessarily that 20% of application vulnerabilities are not discovered and remediated until after the applications have been deployed. The problem is that the total cost of remediating an actual application security-related incident is so high – about $300K, across all respondents. In other words, successful prevention of a single occurrence nearly offsets the total annual cost of the average organization’s application security initiative. A high probability of occurrence, multiplied by a high cost per occurrence, is what gives credence to the argument that application security is ‘free.’”
Still think it costs too much?
2. In the contest between adding software features and accelerating releases, application security just doesn’t make the cut.
There is no question that competition in the software space is intense. And that only increases the pressures to get releases out as quickly as possible, which also means not spending time and resources on such “extras” as security.
Granted, a secure coding approach may, depending on how one accounts for resources, take longer than developing the insecure alternative. And what’s more, burdening an application with security controls can impact usability. But look at the downstream impact of rushed, and consequently buggy, insecure code. Not only to the user, but to the reputation of your brand.
There is an obvious need to balance features, security, and user-friendliness. But also consider this: practitioners of secure application development find that training in secure coding not only helps eliminate security flaws, but other kinds of bugs, as well, yielding more robust and reliable software, and ultimately, happier customers.
This is, of course, a management call—and good managers will recognize that the outcome of higher quality, better secured software is well worth allocating appropriate resources. Resorting to shortcuts under time pressures has only reinforced the old adage, “there is never enough time to do things right, but there is always time to do them over.”
3. There’s a lack of management approval, support, and training for secure development.
Speaking of good management decisions, like all things related to security, the support of executive management is crucial to success. But, recalling the comScore research, twenty-four percent of developers say they don’t use a security development process because of a lack of management approval. A full third claim a lack of support and training.
This is not only irresponsible, it’s self-defeating. The release of vulnerable software not only ends up costing more, it also puts the entire organization at risk. And it’s simply not necessary. The training component that enables the kinds of best practices that secure not only the code, but the reputation of the organization, is the least of barriers to a state of goodness. Oracle CSO Mary Ann Davidson drives the point home: “The cost of resource time spent on [secure application development] training is small when compared to the cost of testing and installing just one security fix. Security training does change developer behavior: quality of code improves along with the security posture provided by the software.”
And that outcome ought to be a core product—and corporate—value. Indeed, the need for security-oriented mindsets and secure coding standards should not only be baked into the software, but also into the corporate culture itself, modeled and reinforced from the top down.
4. Our software sits behind a firewall, so we don’t have to worry about security.
It goes without saying that firewalls comprise an essential component of network security architecture. It also goes without saying (or at least it should) that firewalls do not solve all security problems. After all, a firewall is designed to also let traffic through! Consequently, security boils down to the applications that sit behind it. The firewall is a very precarious basket into which to place all your security eggs.
Firewalls are also only as good as their rule sets and configurations make them. They are not only complex, but error-prone. Filtering rules must be judiciously written and constructed in order to correctly implement the security policy. When they are not, those rules can be circumvented. Moreover, bad administrative practices can create gaps, and modifications to one or more rules may have repercussions for others.
What’s more, there are many ways in which cybercriminals get around firewalls altogether. For example, an unsuspecting employee (one not trained in security awareness) inside the firewall, may admit unauthorized access simply by opening a malicious email. In such client-side attacks, when a computer on the protected side of the firewall makes a valid connection to an attacker, the otherwise applicable firewall rule is simply not triggered. And vulnerable applications are exposed.
From a developer point of view, understanding how the various Web application attacks are conducted will go a long way in providing the essential “application layer” of defense. In other words, developers must code with the perspective of an attacker in mind. And that takes training.
5. We rely on “find and fix” solutions to secure our code.
Here we’re talking about the use of application scanning and penetration testing solutions to identify security vulnerabilities, which are then subsequently fixed by the application developers.
This after-the-fact approach to security is the very antithesis of making applications secure at the source, where security vulnerabilities are eliminated long before applications are deployed. And what is a security vulnerability if not a defect? The earlier you can weed out defects in the development cycle, the less schedule impact, cost, and risk for all concerned. That’s just common sense.
Summing up with a conclusion of the Aberdeen report, “Given that the average total cost of remediating an actual application security-related incident is so high, successful prevention outweighs the undeniable benefits of proactive detection and defense.” Successful prevention, built in up front, relies on developing secure coding competencies. With appropriate training, every developer can become a security-minded gatekeeper. And that makes for better products. As usual, defense in-depth begins—and ends—with people.
Learn more about how easy it is to develop secure coding practices in your organization—and help keep your organization on a strong and secure footing.