Agile IT-Entwicklung für DevOps: In 6 Schritten zu sicherer Banking-Software

Agiles Development mit kurzen Software-Release-Zyklen ist ein guter Weg, um sich von langsameren Wettbewerbern abzugrenzen. Nun gilt es für DevOps bei der Software-Security mit dem Tempo dieser Entwicklung mitzuhalten und Anwendungen in nur wenigen Schritten rundum abzusichern.

von Gunner Winkenwerder, Checkmarx

Moderne Entwicklungsverfahren wie Agile Development und DevOps setzen auf eng integrierte Teams, in denen Software-Architekten, Entwickler sowie Funktions- und Security-Tester zusammenarbeiten, um Finanzsoftware schneller zu entwickeln und bereitzustellen. Zeitgemäße DevOps-Ansätze wie Continuous Integration und Continuous Delivery (CI/CD) verzahnen die Software-Entwicklung dabei nahtlos mit dem Software-Betrieb, um den Anwendern nahezu in Echtzeit den Zugriff auf inkrementelle Verbesserungen zu erschließen.

In 6 Schritten zu sicheren Anwendungen

Die neuen Paradigmen in der Software-Entwicklung zwingen auch die Security-Teams, ihre bisherigen Ansätze zu überdenken.

Um die eng getakteten Abläufe in der DevOps-Umgebung aufrechtzuerhalten, ist es erforderlich, die Funktions- und Security-Tests zu automatisieren und nahtlos in die Prozesse einzubinden – und so die Teams zu DevSecOps zu erweitern.”

Mit den folgenden Schritten optimieren FinTech-Entwickler nachhaltig die Sicherheit ihrer Anwendungen:

1. Ranking der Risiken

In den Entwicklungsabteilungen vieler Banken zeichnen mitunter zehntausende von Software-Entwicklern für die Programmierung und Pflege Tausender individueller Anwendungen verantwortlich. Der erste Schritt zur Risikominimierung ist es daher zu verstehen, welche Gefahren mit welcher Anwendung einhergehen, und zunächst das Schadenspotenzial jeder Software-Lösung zu ermitteln. So ist die Sicherheit einer Online-Banking-App, mit der die Kunden Überweisungen tätigen, größere Transaktionen anstoßen und ihre Konten verwalten können, in hohem Maße geschäftskritisch. Ein erfolgreicher Angriff auf diese App würde enorme Kosten verursachen, gegen gesetzliche Auflagen verstoßen und den Ruf des Instituts nachhaltig schädigen. Als ähnlich kritisch sind alle Anwendungen zu bewerten, in denen regulierte Daten verarbeitet werden.

Umgekehrt gibt es aber auch interne Anwendungen, die keinerlei Zugriff auf sensible Informationen haben und nur eine kleine Angriffsfläche aufweisen. Das Schadenspotenzial dieser Apps ist wesentlich geringer und ihre Absicherung hat nicht den gleichen Stellenwert. Ein Risiko-Ranking der Anwendungen ermöglicht es den Security-Experten der Bank, ihre Aufmerksamkeit und Ressourcen auf die wirklich kritischen Dienste zu fokussieren.

2. Definition der Security-Anforderungen

Die Weichen für sichere Anwendungen müssen von den Entwicklern, den Security-Teams und den Operations-Teams gemeinsam gestellt werden. Wie sie im Einzelfall aussehen, hängt dabei ganz davon ab, wie geschäftskritisch die jeweiligen Anwendungen für das Unternehmen sind und welche Risiken das Unternehmen zu tragen bereit ist.

Um sicherheitsrelevante Schwachstellen im eigenentwickelten Code (und natürlich in der fertigen Anwendung) zu verhindern, muss das Projektteam vom ersten Tag an verbindlich festlegen, in welchen Phasen und mit welchen Werkzeugen die Security-Tests erfolgen werden und unter welchen Umständen der Rollout des Builds abgebrochen werden muss.”

Hierzu gehört es beispielsweise, verbindliche Leitplanken für den Umgang mit als „kritisch“ eingestuften Schwachstellen zu definieren. Manche Kreditinstitute werden eine solche Lücke zum Anlass nehmen, die weitere Entwicklung zunächst einzustellen und gründlich nach Ursachen zu forschen. Andere werden selbst dann an Versionen weiterarbeiten, wenn diese mehrere kritische Lücken aufweisen, solange diese nicht in naher Zukunft zum Release anstehen.

3. Security Testing über den gesamten SDLC hinweg

Um mit der Geschwindigkeit und Agilität der DevOps-Umgebung Schritt zu halten, muss die Security nahtlos in alle Phasen des Software Development Lifecycles integriert werden. Finanzdienstleister können auf diese Weise ihre Time-to-Market nachhaltig verkürzen und die Kosten der Software-Entwicklung senken. Denn je früher im SDLC eine Schwachstelle identifiziert wird, desto einfacher und günstiger ist es, sie zu beheben.

I. Lösungen für das Static Application Security Testing (SAST) setzen ganz am Anfang des SDLC an und nutzen ein konsequentes Checkin-&-Build-Modell, um die Code-Qualität zu prüfen.
II. Open-Source-Analysen (OSA) lassen sich von den frühesten Builds bis weit in die Test- und Quality-Assessment (QA)-Phase hinein nutzen, um integrierte Open-Source-Komponenten zu evaluieren und auf bekannt gewordene Schwachstellen hin zu untersuchen.
III. Um die Qualität des kompilierten Codes zu evaluieren, sollten in der Test- und QA-Phase zudem dedizierte Lösungen für das Interactive Application Security Testing (IAST) eingebunden werden.

Von entscheidender Bedeutung ist es dabei, SAST und OSA möglichst eng in die CI-Orchestrierung einzubinden. Denn das ermöglicht dem Team, seine Prozesse zu automatisieren und inkrementelle Scans durchzuführen, bei denen nur der neu entwickelte oder geänderte Code untersucht wird. Lösungen, die über mehrere Stunden hinweg den vollständigen Build analysieren, haben in modernen DevOps-Umgebungen schlichtweg keinen Platz.

4. Training am lebenden Objekt

Um die Application Security bereits zu Beginn des SDLC fest in den Abläufen zu verankern, hat es sich bewährt, den Entwicklern integrierte Trainingstools an die Hand zu geben, die sie bereits während des Codens auf Fehler und Schwachstellen hinweisen.

Dieses nahezu in Echtzeit bereitgestellte Feedback erlaubt es dem Team, Lücken wesentlich schneller zu schließen, die Qualität der Software spürbar zu verbessern und die Bereitstellung wesentlich effizienter abzuwickeln.”

Die Erfahrung zeigt, dass ein solches Training von den Programmierern als fester Bestandteil des Entwicklungsprozesses wahrgenommen wird. Diese Form der Schulung am „lebenden Objekt“ kommt bei den Teilnehmern sehr gut an – und die entsprechenden Lektionen bleiben dauerhaft im Gedächtnis.

5. Open-Source-Code-Validierung nach Abschluss der Entwicklung

Die Arbeit mit lizenzfreien Komponenten und Frameworks hat viele Vorzüge – vor allem mit Blick auf die niedrigeren Entwicklungskosten und die kürzere Time-to-Market. Voraussetzung für eine erfolgreiche Open-Source-Integration ist aber, dass mittels Software Composition Analysis (SCA) die verwendeten quelloffenen Code-Bestandteile durchgehend auf potenzielle Sicherheitslücken hin analysiert werden – auch nach Abschluss der eigentlichen Entwicklung. Einige der gefährlichsten Open-Source-Schwachstellen wie ShellShock (CVE-2014-6271) wurden erst Jahrzehnte nach der Veröffentlichung des Codes identifiziert.

Ohne volle Transparenz über den Open Source Code, dessen Historie und dessen Rolle im Gesamt-Code ist es nahezu unmöglich, diese Art von Sicherheitslücken zu finden und zu schließen.”

6. Einbindung von Managed Security Services

In Zeiten des Fachkräftemangels fehlt es vielen kleinen und mittelständischen FinTech-Unternehmen an IT-Ressourcen oder am nötigen Security-Know-how. In der Mehrzahl der DevSecOps-Teams herrscht zudem ein Ungleichgewicht in der Verteilung: Auf 100 Entwickler kommen im Schnitt 10 Mitarbeiter im Operations-Bereich – und nur ein einziger Security-Spezialist. In Anbetracht dieses alarmierenden Ungleichgewichts sollten sich IT-Verantwortliche die Frage stellen, ob ihr Team die nötige Absicherung der Software-Entwicklung leisten kann oder ob das Hinzuziehen eines Managed Security Service Providers (MSSP) sinnvoll ist. Die externen Security-Experten führen die Mitarbeiter in die Security-Software ein und zeigen ihnen, wie sie die Zahl der False Positives vom ersten Tag an minimieren. Alternativ übernimmt der MSSP auf Wunsch auch die Durchführung der Sicherheits-Scans sowie die Priorisierung und Auswertung der Findings. So kann sich das Team vollständig auf seine Kernkompetenzen fokussieren.

Fazit

Die Software-Entwicklung hat sich in den vergangenen zehn Jahren radikal verändert. Neue Entwicklungsansätze ermöglichen es Unternehmen, maßgeschneiderte Software wesentlich schneller bereitzustellen – und sich so erfolgreich von ihren Wettbewerbern abzugrenzen. Dies setzt aber gerade in streng regulierten Märkten wie der Finanzindustrie voraus, dass die Software über den gesamten SDLC hinweg sorgfältig auf mögliche Sicherheitslücken hin analysiert wird. Denn Tag für Tag nehmen Tausende von Angreifern die Banking-Software ins Visier, um wertvolle personenbezogene Daten und Identitäten zu stehlen. Wenn ihnen das gelingt, ist nicht nur der Ruf des Unternehmens gefährdet. Es drohen auch enorme finanzielle Schäden und hohe Strafzahlungen für Compliance-Verstöße.

 

Auf Silos verteilte, manuelle Security-Tests sind in modernen DevOps-Umgebungen keine Option mehr.”

Zuverlässigen Schutz bieten ausschließlich ganzheitliche, automatisierte Software-Security-Plattformen, die statische und interaktive Tests, Quellcode-Analysen und Entwickler-Trainings in einer Lösung bündeln und den gesamten SDLC abdecken.Gunner Winkenwerder, Checkmarx