Every year, nearly 7 billion public transportation rides are taken worldwide and nearly 25 billion transactions are processed using Cubic payment and information systems.
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.
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.