Case Study - Cubic

Leading developer of transportation systems builds security into the SDLC

Every year, nearly 7 billion public transportation rides are taken worldwide and nearly 25 billion transactions are processed using Cubic payment and information systems.

It is critical that the transaction data, including personally identifiable information (PII) and payment information, is properly protected. For Konrad Fellmann, director at Cubic Transportation Systems, that means taking a proactive approach to security and incorporating security requirements early in the software development process.

Challenge: Building secure applications from the start

Prior to adopting SD Elements, Cubic was defining security requirements based on OWASP, but there’s little context between OWASP’s suggestions and the apps the company develops. “We needed a way to generate complete security requirements for the PCI-compliant systems we build. You can assign a team to the task, but how do you know the requirements they come up with are comprehensive?” Fellmann said.

The challenge of defining security requirements came to a head when Cubic decided to hire a third party to help develop a new website. Cubic wanted to hand over code development, while retaining responsibility for testing and staging the software, and putting it into production. There was just one problem: The website needed to be PCI compliant, and Cubic didn’t have a way to generate and communicate the necessary requirements to the other company. Without the requirements, Cubic wouldn’t know what to test against.

Solution: SD Elements builds requirements in the earliest stages of the SDLC

Fellmann and his team looked at various application security solutions, but they didn’t help Cubic build security into the SDLC. “Providers like Veracode and WhiteHat Security require you to upload the code, and then they tell you what’s wrong with it,” Fellmann said. “We wanted something that would tell us from the beginning, without doing all this work, what security requirements we need to code to. We like the concept of generating requirements first so we can build to some standard or specs.”

Fellmann found what he was looking for in Security Compass’ SD Elements. The software security requirements management solution uses a short questionnaire to create a model of the application. It then automatically generates relevant security requirements, links them to test cases and delivers them into development tools.

“The capability to model an application to determine requirements and the comprehensiveness of the requirements that come out of SD Elements make it a no-brainer. It’s so much simpler than spending man hours trying to determine security requirements, only to find during a pen test that you’ve missed something,” Fellmann said.

With SD Elements, Cubic was able to deliver a report to its development partner that detailed security requirements for the PCI compliant website. These requirements were then tied to test cases, so Cubic knew what to test for. The result was a more secure application from the start.

Benefits: More secure software and security-savvy developers

Cubic performs penetration tests on all the applications it delivers. The first iteration usually results in several critical findings and the need for rework. But not this time. Thanks to SD Elements, there were no critical findings for the PCI-compliant website, and other vulnerabilities were reduced by 50%, Fellmann said.

Cubic now uses SD Elements for all new development projects, whether or not they must comply with PCI-DSS or other regulatory requirements, and is developing processes for running existing applications through SD Elements. “We’ve seen how useful SD Elements is. We want to make sure all the code we put out is secure from the beginning,” Fellmann said.

SD Elements is also helping Cubic’s developers learn the components of secure development and what to look for as they’re coding. When a developer has a question about offsite scripting or SQL injection, for example, Fellmann points them to SD Elements, which provides a good description of common application vulnerabilities.

“We’re definitely getting folks to learn more about best practices when it comes to secure coding,” Fellmann said. In the future, Fellmann looks forward to further leveraging the embedded training in SD Elements.

CLIENT: Cubic Corporation REGION: International SECTOR: Public Transportation TOOL USED: Security Compass icon for sde SD Elements

"“We wanted something that would tell us from the beginning, without doing all this work, what security requirements we need to code to. We like the concept of generating requirements first so we can build to some standard or specs.”" Konrad Fellmann Director Cubic Transportation Systems

"“The capability to model an application to determine requirements and the comprehensiveness of the requirements that come out of SD Elements make it a no-brainer.”" Konrad Fellmann Director Cubic Transportation Systems

Interested in Training? Contact our sales team for a demonstration.

Security Compass Logo