Tales from Dubius Payment Ltd.

Dubius Payment Ltd. is a relatively new payment service provider. As the company processes credit card information in its systems, it is subject to the security standards of the credit card industry, the PCI DSS (Payment Card Industry Data Security). As part of a PCI certification, the service provider was initially required to subject his IT systems to a penetration test. The security firm binsec GmbH - who was commissioned for this purpose - identified critical security vulnerabilities in the payment gateway after just a short time, which resulted in a preliminary penetration test report. This report is provided on our learning platform for you. But what lead up to such a disastrous result?

Clyde Simmons is the Chief Information Security Officer (CISO) of Dubius Payment Ltd., and he was originally tasked with designing the architecture of the payment gateway. When the date for the audit to prove PCI compliance was moved up, the company quickly hired a graduate student to work as a software architect: Marc Caulder. Even though Marc had no previous work experience, he managed to impress with his very good performance in study courses such as “Software architecture“ and “Advance web development“ - and of all things at one of the most prestigious universities for IT in the country. It was precisely this reputation that obfuscated Marc’s actual know-how, as the findings of the penetration test would later show. Marc’s inexperience in conjunction with the lack of security policies and precautions at Dubius Payment Ltd. lead to the deployment of unverified code into the production system by Marc.

A secure coding guideline could have triggered code reviews, for example, which includes examining the most common security vulnerabilities in web applications. This is also stipulated by the PCI DSS under “Develop and maintain secure systems and applications“ and even calls the pioneer of web applications by its name: the non-profit organisation Open Web Application Project (OWASP), which lists the ten most common web application vulnerabilities in its OWASP TOP 10 project: https://owasp.org/www-project-top-ten/

As there is little time left until the audit, Philip supports his stepfather Clyde Simmons with the implementation of all PCI-DSS requirements in his role a working student at Dubius Payment Ltd. It was just last week that he carried out vulnerability scans on the IT infrastructure, driven by his passion for IT security. As a student trainee, this is a perfect opportunity for him to learn all about the different aspects of IT security, which is why Philip also agreed to establish a policy for the secure development of software. This would allow him to familiarise himself with the Secure Software Development Life Cycle (SSDLC) presented in his training course “Software security“.

According to the SSDLC, security is important throughout all phases of software development, which is why it must already be considered in the requirements analysis. This would make it possible to identify risks already during the planning phase in order to derive security requirements for the software. Limiting login attempts to six failed logins, for example, represents a functional requirement that minimises the inherit risk with weak user passwords. Just how requirements for secure software can be defined is demonstrated by the SQUARE Security Quality Requirements Engineering) methodology developed by the Networked Systems Survivability (NSS) program. The document can be downloaded on our learning platform.

Even Philip’s first draft of his “Software Development Security Policy“ would have bound Marc to generic design principles for the architecture planning of the payment gateway. For example, vulnerabilities such as the lack of authorisation (see Penetration Test Report 4.2) could have been avoided with the ’least privilege’ principle, as each user would only be assigned the most minimal rights to perform operations if the former would have been implemented. Generally speaking, mere knowledge of policy does not suffice for secure software. Measures are required. Based on the ten best practices of (ISC)2,

1. Protect the Brand Your Customers Trust,
2. Know Your Business and Support it with Secure Solutions,
3. Understand the Technology of the Software,
4. Ensure Compliance to Governance, Regulations, and Privacy,
5. Know the Basic Tenets of Software Security,
6. Ensure the Protection of Sensitive Information,
7. Design Software with Secure Features,
8. Develop Software with Secure Features,
9. Deploy Software with Secure Features,
10. Educate Yourself and Others on How to Build Secure Software,

Philip’s policy calls for the use of version control and code reviews during the software development, on top of annual security training for programmers. This is where you come in:

As the newly hired team leader for software development, it is your job to check the code of Marc’s applications and wipe out any vulnerabilities. Even though almost all of the vulnerabilities identified during the penetration test have been resolved, a code review could reveal additional security vulnerabilities. This is why binsec GmbH provides a Secure Code Review Checklist for the technologies deployed by Dubius Payment Ltd. We recommend you adhere to this checklist.

PS: As the team leader for software development, you are only responsible for eliminating vulnerabilities in the web application. Vulnerabilities at the network and system level, such as missing transport encryption (HTTPS) or the use of outdated libraries, are the job of the administrators.