In der Praxis ist es für Hersteller keine leichte Aufgabe, einen ausgeprägten Sicherheitsgedanken kontinuierlich in komplexe Softwareprojekte zu integrieren. Stephan Neumann, Head of usd HeroLab, und Torsten Schlotmann, Head of PCI Security Services, sprechen in unserer Blogserie über praktikable Ansatzpunkte und Möglichkeiten, die Sicherheit von Software dennoch wirksam zu verbessern.
- Teil 1: Gründe für mehr Sicherheit
- Teil 2: Sicherheit in die Unternehmenskultur verankern
- Teil 3: Anforderungs- und Bedrohungsanalyse
- Teil 4: Statische Codeanalyse
- Teil 5: Dynamische Codeanalyse und Vulnerability Management
Heute sprechen wir in Teil 1 über externe und interne Treiber, die das Thema Software Security bei den Herstellern in den Fokus rücken.
Torsten Schlotmann: „Es gibt viele Gründe für sichere Software, doch ich möchte zunächst den Fokus auf die Regulatorik als Treiber legen. Wir führen unsere Audits nach Standards durch, in denen sichere Softwareentwicklung eine wichtige Rolle spielt. Generell ist Softwareentwicklung in allen relevanten Sicherheitsstandards ein wesentlicher Bestandteil. Regulatorische Anforderungen durch den Gesetzgeber, Compliance-Anforderungen beispielsweise aus der Kreditkartenindustrie, ISO Standards oder Kundenanforderungen müssen bei der Softwareentwicklung bedacht und umgesetzt werden. Das alles sollte zwar nicht der primäre und wichtigste Treiber sein, aber gegebenenfalls ist es für viele Unternehmen der erste. Doch durch die ständigen Veränderungen und steigende Komplexität der Standards, ist es nicht mehr damit getan, dass man sich ausschließlich in der Implementierungsphase mit Sicherheit beziehungsweise der Umsetzung dieser beschäftigt. Sicherheit muss in allen Phasen des Entwicklungsprozesses verankert und integriert werden und als ‚business as usual‘ in den Alltag mit einbezogen werden."
Stephan Neumann: „Ein weiterer Treiber für sichere Software ist der Kostenfaktor. Anwendungen sind für Angreifer aufgrund der Dichte an sensiblen Daten ein lukratives Ziel. Sollte ein Angreifer eine Schwachstelle erfolgreich ausnutzen, fallen eine Menge Folge-Aufgaben an, die leider auch mit Zeit und Kosten verbunden sind. Die Umstände müssen geklärt und größere Schäden verhindert, die Kunden informiert und neue Zertifikate sowie Passwörter vergeben werden. Wenn das erledigt ist, geht es erst um die Behebung der Schwachstelle. Vielleicht müssen neue Systeme aufgesetzt werden, die Infrastruktur ist auch beteiligt. Vielleicht macht es auch Sinn im Nachgang einen Test durchzuführen, ob die Schwachstelle endgültig behoben wurde. Diese Auswahl an Beispielen soll aufzeigen, dass wahnsinnig viel Arbeit auf einen zukommt – Arbeit, die vielleicht vermieden hätte werden können. Ich kann Ihnen daher empfehlen nicht nur auf die externen Treiber zu schauen, die mein Kollege Torsten beschrieben hat, integrieren Sie Sicherheit auch auf eigenen Wunsch. Damit schaffen Sie sich die Möglichkeit, Schwachstellen rechtzeitig zu identifizieren oder durch den Einsatz geschulter Entwicklerinnen und Entwicklern gar nicht erst entstehen zu lassen.“
