Von Scrum bis DevSecOps

Wie ist der ursprüngliche Ansatz?

Die Agilität verändert auch die Informationssicherheit in erheblichem Umfang.

Um zu verstehen, an welchen Stellen die Agilität tatsächlich hilft und welche Konsequenzen sich daraus ergeben, werfen wir einen Blick auf den normalen Ansatz: Das Wasserfallmodell

Abbildung: Das Projekt-Wasserfallmodell

Eng mit diesem Modell verbunden ist das Projektdreieck:

  • Zeit, z.B. in Form von Termintreue oder Realisierungsgeschwindigkeit
  • Kosten, z.B. in Form von Mitarbeiterressourcen oder externe Unterstützung
  • Qualität oder wahlweise Umfang, z.B. in Form von Produktmerkmalen

Dabei ist es wesentlich, dass es quasi per Definition nicht möglich ist, alle 3 Merkmale gleichzeitig zu forcieren, d.h. wenn der Termin auf jeden Fall gehalten werden muss, dass kostet das Projekt am Ende (wahrscheinlich) mehr.

Die Praxis sieht gerade bei den IT-Projekten noch ungünstiger aus. Diverse Quellen im Internet zeichnen ein übles Bild:

  • Es werden überdurchschnittlich viele Projekte ergebnislos abgebrochen
  • Eine fristgerechte Fertigstellung ist eher die Ausnahme als die Regel
  • Selbst bei Individualentwicklungen werden über 60% der speziell für diesen Kunden entwickelten Funktionalitäten nie benutzt (obwohl diese zu Beginn ausdrücklich gefordert waren)

Dabei liegt der Grund quasi auf der Hand: Welche Kunde ist bei einem diffusen Zielbild in der Lage, exakt zu bestimmen, was er in 3 Jahren möchte. Karl Valentin bringt es auf den Punkt: Prognosen sind schwierig, besonders wenn sie die Zukunft betreffen.

Hinzu kommt die Angst vor Fehlern. Wir alle haben gelernt, dass Fehler sanktioniert werden und es ist eine Tatsache, dass die Bereinigung von Fehlern in der Produktion mit erheblichen Kosten verbunden ist.

Scrum

Das Ziel ist klar definiert:

Bessere Software (Produkte), in kürzerer Zeit, zu geringeren Kosten, mit mehr Kundenorientierung. Wenn gleichzeitig die Mitarbeiterzufriedenheit auch steigt, nehmen wir das gerne mit.

Abbildung: Schematischer Ablauf von Scrum

Warum funktioniert Scrum?

  • Es ist einfach (und damit von der Methode sehr schnell zu lernen)
  • Es gibt sehr kleine eng abgestimmte Ziele (Sprints)
  • Es gibt kurze Entscheidungswege (Product Owner)
  • Es gibt zu Beginn kein detailliertes Pflichten- oder Lastenheft (sondern nur User Story auf Basis von einfachen umgangssprachlichen Sätzen)
  • Es gibt kontinuierliche Feedbackschleifen (Daily Sprints)
  • Die Teams sind recht klein (dies reduziert die Kommunikationskomplexität)
  • Fehler werden in einem kleinen Team eher akzeptiert (als in der Öffentlichkeit)
  • Der Kunde (Product Owner) und das Team lernen im Projektverlauf ständig dazu
  • Probleme, die zu Beginn fast unlösbar schienen, lösen sich im späteren Projektverlauf fast auf.
  • Unsicherheiten in den Anforderungen auf der Kundenseite werden durch ein sehr viel konkretes Zielbild im späteren Projektverlauf abgelöst.

Viele Unternehmen haben inzwischen in sehr unterschiedlichen Situationen bewiesen, dass die agile Produktentwicklung funktioniert, ohne die Mitarbeiter dabei zu überfordern.

Virtualisierung und der Einsatz von Cloud-Diensten spielen der Agilität in die Hände. Noch keine Ahnung, ob und wie Big Data einen Kundennutzen bieten könnte. Kein Problem. In der Cloud kann Big Data risikofrei ausprobiet und auf Herz und Nieren getestet werden. Noch kein Nutzen gefunden. Dann wird Big Data einfach in die Schublade gesteckt und die mit diesem Dienst verbundenen Kosten enden sofort.

Kanban

Als Ergänzung zu Scrum hat sich Kanban bewährt. Diese Methode kommt ursprünglich von Toyota und optimiert den Fluss der Arbeit.

Abbildung: Einfaches Kanban Board

Leider hat sich mit Scrum und Kanban im Softwareentwicklungsteam das Problem, dem Kunden schnelle und attraktive Produktmerkmale zu bieten nicht gelöst, sondern zunächst nur verschoben. Um eine neue Funktionalität in Betrieb zu nehmen müssen häufig auch in der Infrastruktur Änderungen durchgeführt werden:

  • Das Datenbank-Modell muss erweitert werden
  • Die Firewall braucht eine neue Regel
  • Es muss ein zusätzlicher Server aufgesetzt werden
  • Der bestehende Server braucht mehr RAM oder mehr CPUs

Hier kommt die Systemintegration ins Spiel. Die haben nicht nur den normalen Wahnsinn (ähh ich meine natürlich den normalen Betrieb) zu leisten, sondern bekommen jetzt immer häufiger und in kürzeren Abständen Änderungen auf den Tisch geschoben.

DevOps

Es ist durchaus üblich, dass ein pfiffiger Administrator, wenn er das 3. Mal eine gleichartige Aufgabe auf den Tisch bekommt, aus natürlicher Faulheit heraus ein Skript scheibt, dass diese Aufgabe für ihn automatisiert erledigt. Der systematische Ansatz dieser Bequemlichkeit nennt sich heute DevOps.

Natürlich ist DevOps sehr viel mehr. DevOps systematisiert jeden Teilschritt den notwendig ist, um aus einer Idee tatsächlich eine für den Endkunden nutzbare Funktionalität zu erstellen. Die Softwareentwicklung entwickelt die Programmteile, die Systemintegration integriert diese in die Produktion. Das Ganze ist ein zyklischer Ablauf.

 

DevOps

Abbildung: Continuous Deployment / Continuous Integration (CD/CI)

 

Und was ist jetzt DevSecOps?

Aus der Grafik oben wird deutlich, dass die Informationssicherheit nicht am Ende implementiert werden. Es gibt schlicht diesen Zeitpunkt nicht mehr. Die Konsequenz ist ebenso logisch wie einfach: Informationssicherheit muss in jeder Phase fester Bestandteil sein.

Die Begleitung jeder einzelnen Phase aus dem Blickwinkler der Informationssicherheit kann z.B. durch folgende Maßnahmen erfolgen:

  • Unterstützung der Umsetzung von IT-Compliance Anforderungen
  • Monitoring und Penetrationstests in jede Phase der Entwicklung
  • Security Training
  • Analysen, inkl. Code Analysen
  • Unterstützung des Testmanagements aus Sicht der Informationssicherheit
  • Mitwirkung bei Architekturentscheidungen
  • Unterstützung der Anforderungen aus dem ISMS
  • Unterstützung beim IAM/PAM (Identity and Access Management/Privileged Identity Management), um Benutzerkonten und Zugangsrechte im Griff zu behalten
  • Unterstützung bei der Verschlüsselung und beim Schlüsselmanagement

Abbildung: DevSecOps als integraler Bestandteil der Entwicklungsprozesse

Von Managed File Transfer zu API-Security

Der Datenaustausch zwischen Unternehmen ist nicht wirklich neu. Brief und Fax haben zu weiten Teilen ausgedient, weil diese zu langsam sind und Medienbrüche beinhalten.

Managed File Transfer war der nächste große Schritt, um zwischen Geschäftspartnern regelmäßig Daten auszutauschen. Im Kern handelt es sich um normalen Dateitransfer (so ähnlich wie Datenübertragung per FTP), allerdings

  • verschlüsselt
  • eindeutig identifizierten und untereinander getrennten Kommunikationspartnern
  • mit klar definierten Verantwortungsübergängen und
  • automatischen Verarbeitungsprozessen

Ein typisches Beispiel wäre die Zusammenarbeit mit einem Call Center:

Die Leads werden als Datei zum Auftraggeber übertragen. Dieser importiert die Adressen in sein CRM-System.

Da immer häufiger Systeme in Echtzeit zusammenarbeiten, findet der Datenaustausch mehr und mehr über API-Schnittstellen statt. Solche APIs waren die z.B. die technische Grundlage für den Facebook - Cambridge Analytica - Skandal, wobei dieser Skandal nicht als Angriff gewertet werden kann, sondern als grobe Fahrlässigkeit seitens Facebook gewertet werden muss. Wer eine API-Schnittstelle anbietet, ermöglicht den direkten Zugriff auf die eigenen Daten - durch alle Firewall Systeme hindurch.

Wie vielschichtig die API-Sicherheit ist, zeigt die nachfolgende Grafik:

Abbildung: API-Security (Quelle: KuppingerCole)

Unabhängig von jeder möglichen technischen Absicherung, rate ich dringen, die API-Schnittstelle auch in einem Vertrag mit ihren Rechten und Pflichten festzuschreiben.