SecurityFirst: IT-Sicherheit in der agilen Produktentwicklung
IT-Sicherheit ist aus der modernen Softwareentwicklung nicht mehr wegzudenken. Wer Sicherheitsaspekte hinten anstellt oder diese vergisst, von vornherein mit einzuplanen, riskiert früher oder später große Probleme. Um den schwerwiegenden Folgen von mangelnder IT-Sicherheit vorzubeugen, ist es wichtig, diese nicht einmalig, sondern als ständigen Begleiter in den agilen Produktentwicklungsprozess zu integrieren.
Cyber-Angriffe und Schwachstellen begleiten uns rund um die Uhr. So gab beispielsweise Adidas im Juni 2018 bekannt, dass unautorisierte Dritte sich über die Adidas-US-Webseite Zugang zu einigen Millionen Kundendaten, wie personenbezogenen Daten, E-Mail-Adressen und Passwörtern, verschafften [1]. Auch die Elektronikmärkte MediaMarkt und Saturn wurden kürzlich im November 2021 Opfer einer Cyber-Attacke. Von dem Ransomware-Angriff waren scheinbar die Kassen- und Warenwirtschaftssysteme der Filialen betroffen [2]. Damit solchen Angriffen künftig vorgebeugt werden kann, genügt es uns leider nicht, nur Anforderungen wie
- Die Software muss sicher sein,
- Die OWASP Top Ten müssen implementiert werden oder
- Die BaFin-Standards müssen eingehalten werden,
ins Product Backlog aufzunehmen. Stattdessen geht es um eine fortlaufende, agile Produktentwicklung: Während ein Angreifer lediglich eine Schwachstelle finden muss, müssen Sie gegen sämtliche Lücken im System abgesichert sein. IT-Sicherheit kann also nicht durch einmalige Penetrationstests getestet und damit garantiert werden. Aus diesem Grund ist es wichtig, dass Sie IT-Sicherheit als eine wiederkehrende Aktivität behandeln. Wie Sie dies erreichen können, möchten wir Ihnen anhand eines Beispielszenarios zeigen.
Bestseller GmbH
Als Frau Wälzer, Product Ownerin bei der Bestseller GmbH, feststellt, dass die Kunden immer öfter ausbleiben und die Umsätze des Einzelhandels weiter sinken, hat sie eine großartige Idee: Der Buchhandel soll digitalisiert werden. Ziel ist es, die Bücher künftig auch in einem Webshop anzubieten, um neue Kunden zu erreichen.
Da die Firma vor kurzem umstrukturiert wurde und man sich vorgenommen hat, künftig agiler vorzugehen, ist es das Ziel, nach dem Scrum Framework zu entwickeln. Da die Besteller GmbH als Scrum-Team gemeinsam noch keine Erfahrungen in der Webshop-Entwicklung gesammelt hat, entscheiden sie sich, eine Sprintlänge von zunächst 2 Wochen auszuprobieren. Die Idee ist, in kurzen Feedbackzyklen möglichst viel Produktmehrwert zu erschaffen. Ihre initiale Produktvision fasst Frau Wälzer in Form von Epics und User Stories in einem priorisierten Product Backlog zusammen, welches zunächst genug Backlog Items für 1 bis 2 Sprints enthält.
Wie kann ich meine IT-Produkte oder -Systeme schützen?
In einem Webinar hat sie bereits gelernt, dass drei wichtige Punkte zu beachten sind, um Schwachstellen zu minimieren und damit Angriffen vorzubeugen:
- Team-Awareness: Das gesamte Team sollte in Sachen IT-Sicherheit geschult sein; Verlassen Sie sich nicht auf einen einzelnen Experten. Vielmehr ist es hilfreich, einen Security-Officer zu benennen, der im geschulten Team integriert und erster Ansprechpartner bei Security-Fragen ist.
- #SecurityFirst: Es ist notwendig, IT-Sicherheit rechtzeitig und ausreichend zu Beginn der Produktentwicklung und darüber hinaus fortlaufend zu berücksichtigen.
- Investieren: Wichtig ist, vorbeugend in IT-Sicherheit zu investieren. Setzen Sie beispielsweise eine "Bug Bounty" (d. h. eine Belohnung je Bug oder Sicherheitslücke) ein, anstatt sich lediglich um die Behebung offengelegter Schwachstellen zu kümmern.
Team-Awareness: IT-Sicherheit geht alle etwas an
Gemeinsam mit ihrem Team überlegt Frau Wälzer, wie sie ihre Systeme schützen können. Das Scrum-Team merkt schnell, dass die Team-Awareness für IT-Sicherheit noch ausbaufähig ist. Gemeinsam entscheiden sie, dass Herr Schmöker die Rolle des Security- Officers übernimmt, um das Team als Experte bei der Aufgabe zu unterstützen: Sie möchten die IT-Sicherheit von Beginn an in die Produktentwicklung integrieren und die nötige Team-Awareness aufbauen. Sie setzen sich das Teamziel, dass jedes Teammitglied gleichermaßen für die IT-Sicherheit verantwortlich ist. Aus diesem Grund unterstützt Herr Schmöker das Scrum-Team dabei, sich in IT-Sicherheitsthemen fortzubilden und setzt sich sehr für das Thema IT-Sicherheitstrainings ein.
#SecurityFirst
In agilen Frameworks nutzen wir Scrum-Events, die viel Potential aufzeigen, um die IT-Sicherheit von Beginn an zu integrieren. Frau Wälzer möchte sich diese Events zu Nutze machen, um die IT-Sicherheit schon in den ersten Sprints zu berücksichtigen. Sie plant, Threat Modeling anzuwenden, um die Darstellungen des Systems zu analysieren und um Bedenken über Sicherheits- und Datenschutzmerkmale hervorzuheben [3].
Threat Modeling
Um die Sicherheits- und Datenschutzmerkmale des Online-Buchshops hervorzuheben, zerlegt das Team im ersten Schritt die Anwendung in Einzelkomponenten und ist somit in der Lage, eine Software-Architekturskizze anzufertigen (s. Abb. 3).
In einem zweiten Schritt legt das Team folgende Assets und Sicherheitsziele fest:
Assets | Sicherheitsziele |
Alle sensitiven Daten (Personenbezogene Daten, Bankdaten/ Kreditkartendaten, Logindaten und Passwörter) … | … haben besonderen Schutzbedarf und dürfen nicht vom Angreifer gestohlen oder manipuliert werden, da dies rechtliche Konsequenzen (EU-DSGVO) und Imageschäden für das Unternehmen selbst zur Folge haben kann. |
Ressourcen (z. B. Server) ... | … müssen z. B. vor Datenbankmanipulation geschützt werden: Infrastrukturkomponenten, auf denen die Datenbank läuft, dürfen nicht durch Angreifer abgeschaltet oder verlangsamt werden. |
Eines der Teammitglieder lernte im IT-Sicherheitstraining verschiedene Methoden zum Ermitteln von Bedrohungen und schlägt vor, im dritten Schritt "STRIDE" anzuwenden [4]. Bei STRIDE handelt es sich um ein Akronym für verschiedene Bedrohungskategorien. So steht beispielsweise das "T" für "Tampering with data". Ein Angriff, welcher in diese Bedrohungskategorie fallen kann, ist die unauthentifizierte Manipulation eines Buchpreises durch einen Dritten.
Mittels STRIDE ermittelt das gesamte Team zunächst die Bedrohungen. Hier eignet es sich, dass der Security-Officer oder eine security-affine Person das Team durch den Threat-Modeling-Workshop leitet.
Durch diesen Workshop erkennt das Team im vierten Schritt die Schwachstellen seines Architekturmodells (s. Abb. 4). Frau Wälzer ist aus der Product-Owner-Sicht sofort klar: Sie können nicht alle Bedrohungen gleichzeitig angehen. Daher empfiehlt sie, die gefundenen Themen aus dem Workshop zu priorisieren. Glücklicherweise kennt Herr Schmöker Threat-Risk-Assessment-Methoden und rät, priorisierte Themen im fünften Schritt mittels "DREAD" auszuwählen. Sie identifizieren folgende Top 3 Schwachstellen:
- Verschlüsselung der Kommunikation,
- Verschlüsselung von Passwörtern und
- Datenbankzugriffe.
Anschließend legen sie innerhalb des sechsten Schrittes je Bedrohung entsprechende Gegenmaßnahmen fest (s. Abb. 5):
Bedrohungen | Bildverweis (Beschreibung) | Gegenmaßnahmen |
Datenmanipulation, z. B. Warenkorbmanipulation | TA01 (Datenbankzugriff ist nicht abgesichert mittels technischem Nutzer) | Rechte: Durch einen Datenbankuser mit Schreibrechten Datenbankzugriffe verhindern. - OAuth2.0/OpenID Connect zur Authentifizierung und Autorisierung |
Datenmanipulation, z. B. Preismanipulation | TA02 (Buchverwaltungsendpunkt muss durch Loginkomponente abgesichert werden) | Durch einen Datenbank-User mit Schreibrechten Datenbankzugriffe verhindern. - Daten verschlüsselt in der Datenbank ablegen (Verschlüsselung von personenbezogenen Daten). - Der Bezahlservice sollte über die Login-Komponente laufen. - Kreditkartendaten nicht selbst zu speichern, sondern das alles dem Payment-Provider zu überlassen (sonst muss man selbst ggf. noch Standards wie PCI-DSS abdecken) |
Datenbankangriffe durch z. B. SQL-Injection | Inputvalidierung für Eingabefelder wie Formular- oder Suchfelder, um SQL- oder HTML-Statements zu unterbinden. | |
Mitlesen von unverschlüsselter Kommunikation, z. B. Kopieren oder Manipulieren von Daten durch einen "Man-in-the-middle"-Angreifer | TA03 (Kommunikation Richtung Payment-Provider muss verschlüsselt werden) | Kommunikationsverschlüsselung zum Payment Service Provider (z. B. HTTPS statt HTTP). |
Passwortverschlüsselung | Multi-Faktoren-Authentifizierung (z. B. Token, Gesichtserkennung, SMS). - via Login-Komponente: ID-Generierung / Passwortvorgaben statt Standardpasswort. | |
Account Switching | Via Login-Komponente: Nutzung von OAuth2.0 oder OpenID Connect zur Authentifizierung und Autorisierung von Logindaten. |
Für ihre priorisierten Schwachstellen leiten sie konkrete Secure User Stories sowie AbUser Stories mit konkreten Akzeptanzkriterien ab, die auf die IT-Sicherheit abzielen und im Product Backlog ergänzt werden sollen.
- Secure User Stories sind normale User Stories, die sich besonders der IT-Sicherheit widmen.
- AbUser Stories sind hingegen aus Sicht des Angreifers geschrieben, um angreifbare Aspekte des Systems zu verdeutlichen.
Beispiel: Secure User Story | Beispiel: AbUser Story |
Als Entwickler möchte ich, dass alle Kommunikationsverbindungen verschlüsselt sind, um Daten abhörsicher zu übertragen. Akzeptanzkriterien:
| Als Angreifer möchte ich die sensiblen Daten in der Datenbank manipulieren, um mir Kreditkartendaten zu verschaffen. Akzeptanzkriterien:
|
Mit ihrem Backlog Refinement hat das Team eine gute Grundlage gebildet, um den Sprint zu planen.
IT-Sicherheit in Scrum-Events
Sprint Planning
Im Sprint Planning möchte sich das Scrum-Team auf ein Sprintziel einigen und den Plan besprechen, wie das Produktinkrement umgesetzt wird. Grundlage für das Sprint Planning ist ein gut priorisiertes Product Backlog. Stories, die z. B. Rollen- und Rechtemodelle oder die Autorisierung beinhalten, sollten hoch priorisiert werden, da eine zu späte Umsetzung im Projektverlauf sehr aufwändig bzw. teuer werden kann. Außerdem werden so kritische Komponenten wie Autorisierung über einen langen Zeitraum getestet.
Dafür erinnert Frau Wälzer als Product Ownerin das Team zunächst an die Produktvision. Anschließend merkt sie an, dass ausschließlich User Stories, welche die Definition of Ready erfüllen, vom Product Backlog in das Sprint Backlog gezogen werden dürfen. Gemeinsam einigt sich das Team darauf, dass das Thema IT-Sicherheit zur Definition of Ready zählt: Eine User Story gilt dann als ready, wenn die IT-Sicherheit berücksichtigt wurde.
Da das Scrum-Team in unserem Beispielfall das Threat Model gerade erst erstellt und diskutiert hat, planen sie für ihre priorisierten Schwachstellen entsprechende Test Cases mit ein. Diese nehmen sie als Sub-Tasks mit ins Product Backlog auf, z. B.: Mittels eines Test-Users soll hinsichtlich der zuvor genannten AbUser Story geprüft werden, ob dieser nicht auf der Datenbank lesen oder schreiben kann. Das Ergebnis des Sprint Plannings ist das Sprint Backlog und der Plan, wie die ausgewählten Stories umgesetzt werden sollen. In jedem Sprint Planning sollte darauf geachtet werden, dass in jedem Sprint Stories enthalten sind, die das System sicherer machen.
Daily Scrum
Im Daily Scrum hat das Team die Chance, sich über Themen wie Hindernisse auszutauschen oder auch Wissen zu teilen. Darüber hinaus ist es eine Gelegenheit, sich über Neuigkeiten zur IT-Sicherheit auszutauschen. Zudem können bei kritischen Schwachstellen, wie z. B. Log4J [5], wichtige schnelle Aktionen diskutiert und kurzfristig geplant werden.
So könnte auch darüber gesprochen werden, dass während des Monitorings über die Logfiles des Webshops festgestellt wurde, dass ein Nutzer zehnmal versuchte, sich erfolglos mit seinen Zugangsdaten anzumelden. Aus diesem IT-Sicherheitsvorfall können dann weitere Secure User Stories oder AbUser Stories abgeleitet werden. Secure User Stories könnten berücksichtigen, dass ein System Alert in solchen Fällen ausgelöst wird, oder dass ein Nutzer nach drei erfolglosen Anmeldeversuchen eine sich entsprechend erhöhende Wartezeit abwarten muss, bevor er die Anmeldung erneut probieren kann.
Sprint Review
Ist der Sprint abgeschlossen, bietet sich dem Scrum-Team während des Sprint Reviews die Möglichkeit, den Key Stakeholdern den Fortschritt mit Hinblick auf das Produktziel zu präsentieren. Es ist eine Gelegenheit, mit Stakeholdern zu kollaborieren, Feedback zum Produkt einzuholen oder sogar die Richtung zu ändern.
Da es für Stakeholder schwierig ist, in etwas zu investieren, was man nicht sehen kann, ist es wichtig, dass während des Sprint Reviews auch das Thema IT-Sicherheit thematisiert wird. Es ist eine Chance, zu erklären, was konkret für die IT-Sicherheit getan wurde und ausprobieren bzw. testen zu lassen. Es ist empfehlenswert, auch nach dem Review das Threat Model anzupassen oder die Definition of Done, d. h. ab wann eine User Story als umgesetzt gilt, zu ergänzen.
Sprint Retrospective
In unserem Beispielfall ist der erste Sprint abgeschlossen und das Team erhielt wertvolles Feedback während des Sprint Reviews. Innerhalb einer Sprint Retrospective nutzen sie nun die Chance, den Sprint, die Zusammenarbeit und Maßnahmen für den nächsten Sprint zu besprechen. Auch die Sprint Retrospective ist eine gute Option, um die IT-Sicherheit zu berücksichtigen. Es können eventuelle Gegen- oder Minderungsmaßnahmen bei IT-Sicherheitsvorfällen besprochen werden, z. B. als letzter Schritt ergänzend zum Threat Model:
- Haben wir unseren Job gut genug erledigt?
- Wie wollen wir in Zukunft mit einem vergleichbaren IT-Sicherheitsvorfall umgehen?
Bei dem konkreten Sicherheitsvorfall wie der Anpassung der Login-Komponente, um beliebig häufige Anmeldeversuche zu unterbinden, kann die Post-Mortem-Methode eingesetzt werden. Bei der Post-Mortem-Methode wird zunächst auf dem High-level zusammengefasst, welche Services oder Kunden betroffen waren, wie lang und schwer der Vorfall war und wie das Problem behoben wurde. Anschließend erfolgt eine Ursachenanalyse. Im nächsten Schritt werden die Aktionen, welche unternommen wurden, beschrieben und es wird zusammengefasst, welche der Aktionen hilfreich, nutzlos oder sogar schädlich waren. Eine Zeitleiste mit bedeutenden Aktivitäten aus Chats, Gesprächen oder sonstigen Vorfalldetails kann unterstützen, den Vorfall nachvollziehbarer zu gestalten. Als Ergebnis der Post-Mortem-Methode werden die Erkenntnisse und nächsten Schritte zusammengefasst, d. h. was klappte gut, was nicht? Wie kann verhindert werden, dass das Problem erneut auftritt? Die nächsten Schritte könnten in diesem Zusammenhang als User Stories in das Product Backlog aufgenommen werden.
Fazit
Nach dem erfolgreichen Sprint resümiert Frau Wälzer, was sie darüber, wie IT-Sicherheit von Beginn an in die Produktentwicklung integriert und die nötige Team-Awareness aufgebaut werden kann, gelernt hat.
- IT-Sicherheit sollte von Beginn an in der Produktentwicklung mit berücksichtigt werden.
- Agile Frameworks wie Scrum bieten durch verschiedene Scrum Events viel Spielraum, um die IT-Sicherheit zu diskutieren und zu verbessern.
- Es ist hilfreich, wenn sich das gesamte Team für die IT-Sicherheit verantwortlich fühlt und gut in dem Thema aus- und fortgebildet wird.
- Der Security-Officer agiert als Experte, der als Ansprechpartner für sicherheitsrelevante Themen wahrgenommen wird und das Team dabei unterstützt, die IT-Sicherheit in die Produktentwicklung zu integrieren. Außerdem soll er auch als Multiplikator agieren, um weitere Kolleg:innen für das Security-Thema zu gewinnen und weitere Security-Officer auszubilden, welche dann in weiteren Projektteams unterstützen.
- Threat Modeling unterstützt dabei, IT-Sicherheitsrisiken zu erkennen, indem u. a. diskutiert wird, woran wir arbeiten, welche Bedrohungen lauern und welche Gegenmaßnahmen möglich sind.
- Methoden wie STRIDE sind nützlich, um Bedrohungen zu ermitteln.
- Es ist nicht möglich, alle Bedrohungen zu ermitteln und alle Gegenmaßnahmen gleichzeitig umzusetzen. Aus diesem Grund ist es wichtig, zu priorisieren.
- Methoden wie DREAD helfen, die gefundenen Bedrohungen einzustufen und Themen zu priorisieren.
- Aus dem Threat Model können Secure User Stories und AbUser Stories mit konkreten Akzeptanzkriterien abgeleitet werden.
- Die Post-Mortem-Methode ist eine gute Option, um Sicherheitsvorfälle zu diskutieren und um weitere Maßnahmen für die Zukunft zu definieren.
- Eine Bug Bounty ist eine gute Investition für die Zukunft, um Sicherheitslücken rechtzeitig zu identifizieren.
- Business Insider: Adidas
- heise online: Ransomware-Angriff auf Mediamarkt und Saturn
- Novatec: Threat Modeling
- Novatec: Security Training for Developers
- BSI: Version 1.5: Kritische Schwachstelle in log4j veröffentlicht