Learn how SD Elements improves application security in this case study.
This is a summary of a much larger report.
To view the full report, click here to request the form.
We'll be in touch shortly.
When an organization operates in a highly regulated industry and applications are playing an increasingly important role in engaging customers and employees, reducing the number of audit findings is amenable – and perhaps a necessary goal. To this end, a not-for-profit, California-based health plan provider standardized its software development lifecycle process across the organization. But the application security analyst knew that more would need to be done to reduce the number of audit findings.
Challenge: Poor non-functional requirements process impacts application security
“We were pushing around a static 40-page Word document that outlined our non-functional requirements. It was easy to miss key security requirements while other requirements just didn’t apply to specific projects,” explains the health plan provider’s application security analyst.
The application security analyst explained to the Chief Security Officer (CSO) that automating the creation of security requirements and building them into the SDLC would enable them to be proactive about remediating audit findings. “We brought executives on board by saying, ‘this is proactive risk mitigation’,” he says.
Solution: Automated security requirements generation with SD Elements
With the CSO’s blessing, the organization chose SD Elements, a Web-based software security requirements solution navigating through secure software development. By answering a series of questions, SD Elements allows organizations to generate a focused set of prescriptive security requirements. The tool also checks against an extensive and expanding list of known software security weaknesses to determine the types of security and privacy risks to which an application may be vulnerable.
“Because SD Elements is Web-based, we know everyone is looking at the same set of requirements. But, more importantly, it is always up to date and appropriate for the project at hand,” says the application security analyst.
Benefits: More secure apps, fewer audit findings
It didn’t take long for the organization to acquire proof that Non-Functional Requirements NFRs) are the key to reducing audit findings. “Because NFRs were baked into the process, the first application that we built from scratch, without the use of any legacy code, was the first app to get a perfect score with static analysis,” says the application security analyst. “SD Elements gave us tangible evidence that the application was secure.” With that success, the organization began devoting attention to other applications that may be more of a concern, including legacy applications and those developed by third parties.
“We take the position that any application we use, be it externally developed or COTS, is subject to the same scrutiny as internally developed apps, and NFRs become part of that third-party process,” he says. SD Elements enables the organization to enforce this policy by letting the user to simply set up a project profile and user accounts for the third party. “We can’t accept code that has high vulnerabilities, and we don’t want to be blindsided. We want to be proactive when we can. SD Elements is a powerful arrow in our risk mitigation quiver,” says the application security analyst.
The application security analyst says he cannot overstate the value of SD Elements: “It’s been hugely successful in creating visibility of the merits of an application security program. Of all the things that I thought would be the most useful, this is the one I underestimated. It is the most powerful thing in our application security program.”