Insights der Dubius Payment Ltd.

Die Dubius Payment Ltd. ist ein vor Kurzem gegründeter Zahlungsdienstleister. Da das Unternehmen Kreditkarteninformationen in seinen Systemen verarbeitet, unterliegt es dem Sicherheitsstandard der Kreditkartenindustrie, dem PCI DSS (Payment Card Industry Data Security Standard). Im Rahmen einer PCI-Zertifizierung war der Dienstleister erstmals verpflichtet, seine IT-Systeme einem Penetrationstest zu unterziehen. Schon nach kurzer Zeit meldete die zu diesem Zweck beauftragte Sicherheitsfirma binsec GmbH kritische Sicherheitslücken im Payment-Gateway, woraufhin ein vorläufiger Penetrationstestbericht erstellt wurde. Diesen haben wir Ihnen zur Einsicht auf unserer Lernplattform bereitgestellt. Doch wie konnte es zu solch einem katastrophalen Ergebnis kommen?

Clyde Simmons ist Chief Information Security Officer (CISO) der Dubius Payment Ltd. und ursprünglich sollte er die Architektur des Payment-Gateways entwerfen. Als der Audit zum Nachweis der PCI-Compliance terminlich vorverlegt wurde, stellte man kurzerhand noch einen Studienabgänger als Softwarearchitekten ein: Marc Caulder. Auch wenn Marc noch keine Berufserfahrung vorweisen konnte, überzeugte er dennoch mit seinen sehr guten Leistungen in Fächern wie „Software-Architektur“ und „Fortgeschrittene Webentwicklung“ - und das an einer der angesehensten Universitäten für Informationstechnik des Landes. Genau dieser Ruf war es, der den Blick auf Marcs tatsächliches Know-how trübte, wie die Findings des Penetrationstests offenlegten. Marcs Unerfahrenheit, die bei der Dubius Payment Ltd. auch noch auf einen Mangel an Sicherheitsrichtlinien und -vorkehrungen traf, führte dazu, dass Marc ungeprüften Code in das Produktionssystem deployte.

Eine Secure-Coding-Guideline hätte zum Beispiel die Durchführung von Code Reviews anstoßen können, die die Prüfung der am meisten verbreiteten Sicherheitslücken in Webanwendungen beinhalten. So fordert es auch der PCI DSS unter „Develop and maintain secure systems and applications“ und nennt dabei den Vorreiter in Sachen Sicherheit von Webanwendungen namentlich: die Non-Profit-Organisation Open Web Application Security Project (OWASP), welche in ihrem Projekt OWASP TOP 10 die zehn häufigsten Schwachstellen in Webanwendungen auflistet: https://owasp.org/www-project-top-ten/

Da die Zeit bis zum Audit knapp bemessen ist, unterstützt Philip seinen Stiefvater Clyde Simmons bei der Umsetzung aller PCI-DSS-Anforderungen in seiner Rolle als Werkstudent der Dubius Payment Ltd. So hat er erst letzte Woche die Vulnerability-Scans von der IT-Infrastruktur durchgeführt, angetrieben von seinem großen Interesse an der IT-Sicherheit. Für ihn als Werkstudent ist das seine Chance, in die verschiedenen Bereiche der Informationssicherheit hineinzuschnuppern, weshalb sich Philip auch dazu bereit erklärt hat, eine Richtlinie zur sicheren Softwareentwicklung anzufertigen. Auf diese Weise könne er sich mit dem vorgestellten Secure Software Development Life Cycle (SSDLC) aus seiner Lehrveranstaltung „Software-Sicherheit“ vertraut machen, sagt er.

Gemäß SSDLC spielt die Sicherheit in jeder Phase der Softwareentwicklung eine Rolle, weshalb sie bereits in der Anforderungsanalyse zu berücksichtigen ist. So sollten Risiken schon in der Planungsphase identifiziert und bewertet werden, um Anforderungen an die Sicherheit einer Software ableiten zu können. Eine Beschränkung der Anmeldeversuche auf sechs fehlgeschlagene Logins stellt zum Beispiel eine funktionale Anforderung dar, welche das Risiko eines schwachen Benutzerpassworts minimiert. Wie Anforderungen an sicherere Software definiert werden können, zeigt die vom Networked Systems Survivability (NSS) Program entwickelte Methodik SQUARE (Security Quality Requirements Engineering). Das Dokument kann über unsere Lernplattform heruntergeladen werden.

Bereits Philips erster Entwurf seiner „Software Development Security Policy“ hätte Marc in seiner Architekturplanung des Payment-Gateways an generische Designgrundsätze gebunden. Schwachstellen wie die der fehlenden Autorisierung (vgl. Penetrationstestbericht 4.2) hätten zum Beispiel nach dem Prinzip von „Least Privilege“ vermieden werden können, da bei solch einer Implementierung jeder Benutzer ausschließlich die geringstmöglichen Rechte zur Ausführung von Operationen zugewiesen bekommt. Üblicherweise sorgt die alleinige Kenntnisnahme von Richtlinien nicht für sichere Software, es müssen Maßnahmen ergriffen werden. In Anlehnung an die zehn Best Practices von (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,

fordert Philip in seiner Richtlinie neben einer jährlichen Sicherheitsschulung der Programmierer auch die Verwendung eines Versionskontrollsystems sowie Code-Reviews bei der Softwareentwicklung. An dieser Stelle kommen Sie ins Spiel:

Als neu eingestellter Teamleiter der Softwareentwicklung wurde Ihnen die Aufgabe zugeteilt, den Code von Marcs Anwendungen zu prüfen und alle Schwachstellen zu bereinigen. Auch wenn bis dato fast alle identifizierten Schwachstellen des Penetrationstests behoben worden sind, könnte ein Code-Review weitere Sicherheitslücken zum Vorschein bringen. Zu diesem Zweck wurde von der binsec GmbH eine Secure-Code-Review-Checkliste für die von der Dubius Payment Ltd. eingesetzten Technologien bereitgestellt. Wir empfehlen Ihnen, sich an dieser Checkliste zu orientieren.

Als neu eingestellter Teamleiter der Softwareentwicklung wurde Ihnen die Aufgabe zugeteilt, den Code von Marcs Anwendungen zu prüfen und alle Schwachstellen zu bereinigen. Auch wenn bis dato fast alle identifizierten Schwachstellen des Penetrationstests behoben worden sind, könnte ein Code-Review weitere Sicherheitslücken zum Vorschein bringen. Zu diesem Zweck wurde von der binsec GmbH eine Secure-Code-Review-Checkliste für die von der Dubius Payment Ltd. eingesetzten Technologien bereitgestellt. Wir empfehlen Ihnen, sich an dieser Checkliste zu orientieren.