The connected world of HR technology is exploding, and more and more companies are trusting employee and company information in the hands of cloud software companies. The problem? Complex, public-facing cloud systems are hard to secure. That's just a fact. So, what can providers do about it?
The answer is simple: Detect and minimize security risks and threats in your product before they are released. But to do that, you need a well-defined strategic framework—a Security Development Lifecycle (SDL)—to guide product development and help ensure that security is baked in by various teams. This is a cross-functional effort with the Product, Development, QA, Security and Release teams acting together for the common good.
The SDL concept is not new, but growing pressure on software developers to adopt a formal framework is—especially when it comes to protecting critical and private employee information. Recent high-profile data breaches involving major retailers, financial institutions and government agencies have customers asking vendors more questions about security. They want assurance that developers are doing all they can to reduce risk and make safer products.
Instilling greater confidence in your customers is an important reason to adopt an SDL process, of course, but there are other benefits. Reducing the need for firefighting is a primary one. Think of the resources you need to deploy to respond to a security incident after your product has been released—the time and cost involved can be significant.
In fact, as Microsoft notes on its website about the "Benefits of SDL," the National Institute of Standards and Technology estimates that code ï¬xes performed after release can result in 30 times the cost of ï¬xes performed during the design phase. So, the bottom line is that it can be far more cost-effective to ask questions about security and address risks in the earliest stages of product development. Here's what you need to know about creating an SDL at your company.
SDL frameworks provide inspiration and tools for reducing software security risk, but you have to make sure you implement a framework unique to your organization's processes and culture. You will need to tailor your own blend of best practices to create a relevant and effective framework. Technical controls typically require particular customization and tuning based on internal process, technology and capability.
Process-based preventative controls include verifying that project-based security activities occur prior to release, while technical controls include static analysis and dynamic analysis security testing. Technical controls often require a security toolbox including tools like SIEM (Splunk), static source code analysis (Checkmarx), static binary analysis (Fortify), and dynamic analysis security testing (WhiteHat Sentinel, Burp Suite, ZAP). We also build custom scripts and have meaningful manual processes for verifying that new features are free of severe and common kinds of security defects, including SQL injection, command injection, cross-site scripting, and authorization issues.
That's what we’ve done at our company. Cornerstone's SDL framework is actually a hybrid of leading frameworks like the Microsoft SDL and the Building Security in Maturity Model (BSIMM). We've also added a core element that is a reflection of what Cornerstone is—a learning company. Continuous learning is the cornerstone of our SDL, with product security training forming the hub of our SDL "wheel":
Our goal is to make learning fun. We believe that education and training is the best proactive security control. For example, we have developed an application security game that is part of the mandatory curriculum for all of our technology personnel. It's multiple choice, but it's tough—and we can chart the progress of every developer as they move through that curriculum.
What we are doing at Cornerstone is advanced for the talent management space. And it's enabling us to confidently answer three vital questions customers ask in security RFPs and audits:
- Do you have a strategic framework for secure product development?
- Have you implemented some level of control that indicates maturity across those practices?
- Do you conduct role-based application security training and measure the results?
We leverage our internal implementation of the Cornerstone LMS to deliver annual training on security policies and guidelines for all employees, and provide focused, role-based application security training for Dev, QA, and the technical personnel responsible for delivering code-shipping products. Additionally, we provide specialized training on SIEM, static analysis, and dynamic analysis security testing tools.
Further, Cornerstone is proud to be a member of Cloud Security Alliance, and frequently hosts monthly gathering in the Los Angeles area at Cornerstone’s Santa Monica headquarters. This educational forum helps keep Cornerstone ahead of the curve when it comes to cloud security.
More importantly, our SDL framework allows us to confirm that we have done everything we could to build security into a product before we release it, answering key questions like:
- Did we specify secure design requirements? Were they met/satisfied/followed?
- Did we conduct secure code review? What did we find?
- Did we perform dynamic security testing? What was the result?
- Did we ensure new features were covered in per-release penetration testing? What was the outcome?
- Is the product security incident response team aware of the new attack surface, and do they know who to contact in the event issues are found?
The whole concept of the SDL is to build proactive controls that reduce risk and the reactive need for firefighting. You developed a more secure product by bringing together all stakeholders at the outset—the product designer, the development lead, the quality assurance team, and others—to ask and answer, "What are we building? What are the risks? And what can we do to prevent them?"
What’s the conclusion? The program and process has to be ongoing since technology changes and employees take on new challenges. Updating the programs frequently is critically important. The process is iterative and meant to support a "Maturity Model" mindset.
Photo: Shutterstock
