Bug Bounty Lifecycle und SDLC im Vergleich Sichere Software-Entwicklung mit Hacker-Support

Anbieter zum Thema

Arvato Systems

TXOne Networks

Outpost24 GmbH

Ein permanent kritischer Aspekt in der Software-Entwicklung ist die Sicherheit. Mit DevOps-Praktiken wie Continuous-Integration und -Delivery hat sich die Schwachstellen-Problematik allerdings verschärft. Doch woe lassen sich diese am besten aufdecken?

Galt es in der Vergangenheit, die Sicherheit erst am Tag der Verfügbarkeit gewährleisten zu müssen, ist dies heute mit CD (Continuous Delivery) und CI (Continuous Integration) ein nie endender Prozess. So erfordern Cloud-, agile DevOps- und CI/CD-Pipelines, dass die Sicherheit zu einem routinemäßigen Teil des Software Development Lifecycle (SDLC) wird – und die Security folglich ein kontinuierlicher Prozess der Software-Entwicklung.

Glücklicherweise hat die Qualität von Software in den vergangenen Jahren deutlich zugenommen, aber die regelmäßigen Patchdays nahezu aller großen Anbieter von Software zeigen, dass Sicherheit ein relativer Begriff ist, Verbesserung ist immer möglich. Eine der Herausforderung dabei sind sicherlich die begrenzten Kapazitäten der Software-Entwickler, in jedem Sprint ausreichend Zeit für ausführliche und umfassende Security-Tests aufbringen zu können.

Eine Möglichkeit, hier bessere Ergebnisse zu erzielen, ist zweifelsohne der Einsatz von White-Hat-Hackern, also nicht kriminellen Hackern. Diese können nicht erst im Falle fertiggestellter Apps, Plattformen oder Websites ihren Beitrag leisten, sondern schon in den SDLC integriert werden. Analog zum SDLC spricht Verizon Media hier von einem BBLC, einem Bug Bounty Lifecycle.

Der wichtigste Unterschied gegenüber einem Standard-Bug-Bounty-Programm: Die im Rahmen des BBLC gefundenen Schwachstellen werden nicht nur dafür genutzt, genau diesen Fehler zu beseitigen, sondern die gewonnenen Erkenntnisse auch in den Software-Entwicklungsprozess zu integrieren. Herkömmliche Bug-Bounty-Initiativen zielen auf installierten Code ab, der in Produktionsanwendungen läuft.

Die Hacker suchen hier nach Fehlern und Schwachstellen, dementsprechend werden die Fehlerberichte aus der (fast fertigen) Live-/Produktiv-Umgebung stammen. Das Software-Entwicklungsteam erstellt eine Lösung für diesen Fehler und spielt diese ins System ein. Dies ist der klassische Ansatz „Bugs in, Bugs out“, nach dem viele Unternehmen arbeiten. Mit der Beseitigung des Fehlers ist der Prozess beendet.

Sicherheit in umgekehrter Reihenfolge

Beim BBLC ist das jedoch anders. Im Prinzip besteht der BBLC aus genau den gleichen Schritten wie der SDLC, aber in umgekehrter Reihenfolge. Beim traditionellen Software-Entwicklungsprozess stehen am Anfang die Anforderungen, es folgen Design, die eigentliche Entwicklung (Build), das Testen und schließlich das Deployment.

Der Bug Bounty Lifecycle arbeitet folglich in genau umgekehrter Reihenfolge. Man beginnt mit der Analyse des fertigen Produkts, also dem Hacken der implementierten Lösung und arbeitet dann Schritt für Schritt mit den Entwicklerteams daran, von der fertigen Lösung Ebene für Ebene bis zum Design und der Konzeption vorzudringen.

Letztendlich befinden sich die Software-Designer am Ende dieses BBLC-Prozesses bei der Definition der Anforderungen, sodass beispielsweise bereits bestimmte Restriktionen oder Definitionen zu Beginn des SDLC festgelegt werden müssen. Diese Restriktionen oder Definitionen müssen zwar funktionell und technisch nicht per se Teil der Anforderungen sein, da die Lösung auch ohne diese Restriktionen funktioniert, aber sie ist eben unsicher.

Bei diesem Ansatz werden somit die Erfahrungen der Hacker der jeweiligen Stufe systematisch zur Verbesserung der Sicherheit in der – aus der Perspektive des Software-Entwicklungsprozesses – vorherigen Stufe eingesetzt. Der Einfluss der Hacker ist dann längst nicht mehr an die reine Fehlersuche im Endprodukt gebunden, sondern Security beginnt damit schon bei dem Erstellen der Anforderungen an das zu entwickelnde System.

Basis dafür ist in der Regel nicht eine einzelne Form von Schwachstelle, die lediglich ein Mal gefunden wird. In vielen Fällen ist es eher so, dass im Laufe der „Hackerangriffe“ zur Fehlersuche immer wieder bestimmte Arten von Schwachstellen gefunden werden. Dabei handelt es sich dann offensichtlich um ein Problem bei der Definition der Anforderungen oder dem Design, weniger um wiederkehrende Unachtsamkeit im Build-Prozess oder gar einer späteren Stufe des SDLC.

Letztendlich bedeutet der Einsatz der Hacker in Form des Bug Bounty Lifecycle das Thema Sicherheit immer weiter nach links, also weiter an den Anfang des Entwicklungsprozesses zu verschieben. Security wird damit zu einer wichtigen Anforderung an die Software-Architekten. Das bedeutet gleichzeitig, die Security als strategischen Vorteil zu implementieren.

Während in den meisten Ansätzen lediglich das Endprodukt getestet wird und Schwachstellen erst dort beseitigt werden, ist mit dem BBLC die Wirkung deutlich breiter und verändert die Art und Weise, wie Sicherheit in die Systeme implementiert wird. So könnten beispielsweise die Hacker aufgrund ihrer Erfahrung beim Hacken nach BBLC eng mit dem Architekturteam zusammenarbeiten, um ein neues Steuerelement zu entwerfen, z.B. eine Whitelist-Validierung für alle Eingabefelder zu verlangen.

GitLab und Assembla als Beispiele

Organisationen wie Assembla und GitLab verfolgen schon heute diesen proaktiven Ansatz – die Integration der Arbeit von Hackern in den SDLC – um Sicherheitslücken zu eliminieren. Auf diese Weise tragen die Sicherheitsteams erheblich dazu bei, Unterbrechungen des SDLC zu reduzieren. Die Entwickler haben entsprechend die Möglichkeit, Schwachstellen zu beseitigen, bevor diese den Entwicklungsprozess komplett durchlaufen haben und nachträglich behoben werden müssen.

Dafür müssen jedoch Entwickler- und Security-Teams die gleiche Sprache sprechen, der Einsatz von Industriestandards ist hier von großer Bedeutung. Dies stellt sicher, dass die Entwickler die Informationen, die ihnen vom Sicherheitsteam vorgelegt werden, schnell verstehen und darauf reagieren können. Der Industriestandard Common Weakness Enumeration (CWE) eignet sich hier bestens.

Unternehmen, die sich für die Unterstützung durch Hacker entscheiden, sollten ihre Schwachstellenberichte klassifizieren. Die Hackerone-Plattform als eine Möglichkeit, Hacker an der Softwareentwicklung zu beteiligen, setzt dabei auf CWE. Dies hilft Sicherheits- und Entwicklungsteams dabei, einheitlich zu kommunizieren, wenn sie Fehlertypen und die Taktiken zur Schadensbegrenzung und -vermeidung diskutieren. Die Verwendung der CWE bedeutet einen reduzierten Zeitaufwand für die Prüfung, Validierung und Priorisierung eingehender Fehlerberichte. Im Nachhinein bedeutet es, dass Entwickler und Ingenieure schnell verstehen, womit sie es zu tun haben.

Integration mit beliebten Entwicklungswerkzeugen

Da die Fehlerberichte im SDLC zusammengeführt werden, ist es weniger störend, wenn diese Informationen direkt in die Tools integriert werden, die die Entwickler bereits verwenden. Dazu gehören Fehlerverfolgungs-, Projektmanagement- und Ticketingsysteme, aber auch Versionskontroll-, Repository-, Kollaborations-, Kommunikations- und Support-Tools.

Plattformen wie Hackerone bieten hierfür vorgefertigte Integrationen in die beliebtesten Werkzeuge, die im SDLC verwendet werden. Dazu gehören Jira, Assembla, Bugzilla, MantisBT, GitLab, GitHub oder auch Slack, um Reibungsverluste zu vermeiden, wenn Teams zusammenarbeiten und kommunizieren, während sie daran arbeiten, Fehler zu beheben und Sicherheitslücken zu schließen.

Die Integration mit Jira synchronisiert Informationen zwischen einem Schwachstellen-Bericht und dem entsprechenden Datensatz innerhalb von Jira. Sie können dann die Workflows von Jira mit der CWE-Plattform und umgekehrt synchronisieren, was den Entwicklungs- und Sicherheitsteams hilft, aufeinander abgestimmt zu bleiben. Sie trägt auch zur Standardisierung Ihres Prozesses zur Behebung von Sicherheitslücken bei und eliminiert die mühsame Dateneingabe und das Risiko menschlicher Fehler.

Schwachstellen schon in der Architektur vermeiden

Letztendlich kann das Unternehmen auch Lehren aus einer ganzen Klasse von Schwachstellen ziehen, wenn diese wiederholt auftreten und damit neue Anforderungen, Richtlinien oder Standards schreiben, um diese Lücken erst gar nicht mehr entstehen zu lassen. Dieser Ansatz unterstützt die Unternehmen, Verbesserungen in ihrem Software-Produktionsprozess voranzutreiben, um sicherzustellen, dass zukünftiger Code kontinuierlich sicherer wird. Dies sorgt dann nicht nur für Sicherheit in einer neuen Lösung, sondern betrifft in der Regel sodann das gesamte Software-Portfolio.

Die Unterstützung eines solchen BBLC erhalten Software-Entwickler meist über Bug-Bounty-Plattformen. Diese helfen den Unternehmen dabei, mittels eines Prämiensystems mit White-Hat-Hackern zusammenzuarbeiten, also Hackern, die ihr Können nicht für kriminelle Zwecke einsetzen. Auf diese Weise erhalten die Firmen einen einfachen und hürdenlosen Zugang, um die Hacker als Dienstleister in den Entwicklungsprozess zu integrieren.

Dabei muss jedoch beachtet werden, dass beide Seiten für das rechtlich grundsätzlich illegale Hacken einen entsprechenden Vertrag schließen, um für den genannten Ansatz einen legalen Rahmen zu schaffen. In diesem sogenannten VDP (Vulnerability Disclosure Program) werden die Auftragskriterien genau definiert, sodass beide Seiten klare Vorstellungen und Grenzen des Zusammenarbeit festlegen und vor Missbrauch der gewonnenen Erkenntnisse oder Missverständnisse, die zu falschen Anschuldigungen führen können, bestmöglich geschützt sind.

Die Zusammenarbeit mit White-Hat Hackern liefert somit eine sinnvolle Ergänzung der eigenen Sicherheitsstrategie, um sich im harten Wettbewerb durch besonders sichere Lösungen gegen andere Anbieter zu behaupten.

* Laurie Mercer ist Security Engineer bei Hackerone. Er verfügt über einen starken technischen Hintergrund, da er sowohl als Entwickler als auch als Penetrationstester gearbeitet hat. Zuletzt arbeitete er als Solution Engineer für große SAST-Programme.

(ID:47060874)