But how can it be achieved? Wisegate, a practitioner-based IT organization that publishes research based on the real-life experience of its members, has now published its latest report: CISO Tips for Baking Better Security into Applications. It takes as its starting point Barry Boehm’s seminal work showing the exponential rise in the cost of fixing/managing flaws as the SDLC progresses. McGraw and Routh made the same point in a separate study later: “As an example of early lifecycle savings, the Firm's numbers show that fixing a defect post-production takes on average 32 hours of development time. By contrast, fixing a defect in development takes on average 3.2 hours of development time. This factor of ten adds up quickly.”
The traditional response to the inevitable bugs in software is simply to explain that security is usually an afterthought to a good business idea; but Wisegate shows that it is not that simple. “In reality,” it says, “conditions such as budget and resource constraints, lack of awareness, tight development timelines, and even company politics can get in the way of incorporating security into applications throughout the software development life cycle (SDLC), especially in the early phases.”
The purpose of this latest report is to show how its CISO members attempt to build security into the beginning rather than the end of the SDLC. It highlights three specific areas for “the best ways to promote better security practices throughout the SDLC:” selling the need for security in the early stages of development; asserting authority to influence software development; and demonstrating how security controls can be built in.
One tip that crosses all of these areas is to use compliance as an argument. As one CISO explains, “It’s one thing for the security team to advise on building in security, but it’s another thing to say it’s required by law.” The legal requirement sells the idea of security; it asserts the CISO’s authority; and it demonstrates his ability to build security controls – encryption, for example – into the design stage of development.
With a foot in the door, the CISO can then begin to ensure that wider security concerns are baked into application development from the earliest requirements phase. “Stakeholders need to understand that there are different types of application vulnerabilities, which put the company at risk – code problems, logic errors, controls, etc,” said Martin Zinaich, Information Security Officer at City of Tampa. “Downtime for any reason often results in revenue losses. These are real risks that executives can understand, and good governance guides them to get behind the security measures necessary to mitigate the risks.”
One of the keys is to become an enabler rather than an inhibitor. The role of the CISO is to show how security can be done; not just to demand that it is done. “By integrating what we do directly into what the rest of the company does to develop the product,” says another CISO, “we ensure security is done early, which is where the cost savings come in and it allows us to enable the business instead of slowing them down. We’re there early more as a stakeholder, or a teammate, rather than there late as a gate.”
But, of course, as with so much else in business, it requires top-level support. “We sell or influence the leaders of the development teams on the concept of baked in security and eventually that trickles down to the actual developer but by the time it gets there, it’s not a, ‘Can you do this for us?’ It’s, “Here’s the new direction and work with the security team in getting it done.’”
The underlying principle is that the security team must be involved in software development from the very beginning, rather than a plasterer trying to cover up cracks when the wall is finished. This report gives some of the methods used by practicing CISOs to achieve that end in their own organization’s SDLC.