Was wir erreicht haben

  • Bereitstellung ohne Konfiguration

  • Nutzung vorhandener Prozesse im SDLC

  • Detaillierte Aufzeichnungen zu Sicherheitslücken

An wen

  • Branche: IT

  • Produkte: HCL AppScan

  • Region: Nordamerika/USA

Überblick

  • Teil 1

    Herausforderung

    Unser Kunde stand vor folgenden geschäftlichen Herausforderungen:

    Verbesserung der Produktsicherheit, ohne den aktuellen SDLC-Prozess zu unterbrechen.

    Verringerung der Wahrscheinlichkeit von Sicherheitsproblemen, die den Versand neuer Versionen verzögern könnten.

  • Teil 2

    Lösung

    Integration von IAST in den bestehenden QS-Prozess des Kunden und Nutzung automatischer, manueller sowie Sanity-Tests, um die Abdeckung von Anwendungssicherheitstests (AST) zu erweitern und DevOps in DevSecOps zu transformieren.

  • Teil 3

    Ergebnisse

    Verbesserte AST-Abdeckung und effizientere Behebungsprozesse dank informativer Aufzeichnungen zu Sicherheitsproblemen, wie vollständigen Aufrufstacks und Exploit-Beispielen, die vom IAST-Agenten gemeldet werden.

Die Herausforderung

Business Case für IAST

Das Unternehmen setzte DAST bereits als Teil seines SDLC ein, meist in der Spätphase. Diese gängige Praxis lieferte zwar gute Ergebnisse, hatte jedoch mehrere Nachteile:

  • Wenn eine erhebliche Sicherheitslücke entdeckt wurde, verzögerte sich der Release, da DAST erst als einer der letzten Schritte vor dem Versand einer neuen Version eingesetzt wurde. Die Maßnahmen zur Behebung der Sicherheitslücken waren aufgrund der detailarmen Informationen des DAST-Scanners sehr aufwendig.
  • Zwischen dem Schreiben des Codes und dem Erkennen der Schwachstellen bestand eine erhebliche Zeitlücke.

Wir waren überrascht vom Bereitstellungsprozess. Wir hatten etwas Komplizierteres erwartet als das Bereitstellen einer WAR-Datei für unser Tomcat!

Technical Manager DevOps team

Die Lösung

Integration von IAST

Aufgrund der Größe und Komplexität der Codebasis verfügt das Unternehmen über einen umfassenden Qualitätssicherungsprozess (QS-Prozess). Dieser umfasst sowohl automatisierte als auch manuelle Tests, die von einfachen Szenarien bis hin zu komplexen Fällen reichen. Mit jeder neuen Version wurden weitere Funktionen hinzugefügt, sodass der QS-Prozess kontinuierlich um zusätzliche Tests erweitert wurde.

Die QS-Infrastruktur basiert auf Docker und wird mit Jenkins orchestriert. Da das Team die bestehenden Container nicht verändern wollte, wurde IAST mittels eines einfachen Skripts integriert, das den Agent über AppScan-APIs herunterlädt und nach erfolgreichem Erstellen und Bereitstellen der Anwendungen auf dem Webserver installiert.

Die vielen Informationen, die ich bei jedem Problem erhalte, sind für die Priorisierung und Behebung von Vorteil.

System Architect

Die Ergebnisse

Auswirkungen

Ein bedeutender Vorteil, den die Entwickler sofort meldeten, war die Fülle an Informationen, die die Schwachstellen enthielten. Wenn die Codezeile, die das Problem verursacht hat, zusammen mit einem Beispiel für einen auslösenden Exploit zur Verfügung steht, wird der Aufwand für die Behebung erheblich reduziert. Da der QA-Prozess eng an den Entwicklungsprozess angrenzt, sind den Entwicklern die Codeänderungen, die zu neuen Sicherheitsschwachstellen geführt haben, noch frisch im Gedächtnis, wenn sie sich an die Behebung der Probleme machen.

Ein weiterer Vorteil, den das Sicherheitsteam berichtete, war die geringere Anzahl der beim DAST-Scannen festgestellten Probleme, da viele Schwachstellen dank des früheren Eingreifens im QS-Prozess bereits im SDLC gelöst werden.

Mit Blick auf die Wartung zeigten sich die Sicherheits- und DevOps-Teams beeindruckt, da die Integration des IAST-Agenten lediglich ein einfaches Skript erfordert und der Agent selbst kontinuierlich aktualisiert wird. Sehr positiv ist auch, dass das QA-Team für jede neu entwickelte Funktionalität Tests hinzufügen kann, um die AST-Abdeckung mit jeder neuen Version aktuell zu halten. Der Prozess verbessert sich so als Nebenprodukt des SDLC ständig selbst.

Über das Unternehmen

Aufgrund der sensiblen Natur der Cybersicherheitsdomäne hat das Unternehmen in dieser speziellen Fallstudie um Anonymität gebeten. Es handelt sich um ein Softwareunternehmen im IT-E-Markt, das Dienstleistungen für KMU und Großunternehmen anbietet.

In dieser Fallstudie wurde folgender Technologie-Stack verwendet:

  • Java
  • Tomcat
  • Docker
  • Jenkins

Verwandte Funktionen