Vorbereitung

In diesem Abschnitt wird ausführlich erörtert, wie Sie Ihr Unternehmen auf den Start und die Durchführung eines erfolgreichen Programms zur Offenlegung von Sicherheitslücken vorbereiten können. Dabei erhalten Sie auch praktische Ratschläge, wie Sie die von Ihnen identifizierten Lücken schließen können.

Suchen nach Programmfehlern

Die Erweiterung Ihres bestehenden Sicherheitsprogramms mit externen Sicherheitsexperten ist eine großartige Möglichkeit, komplexe Probleme und verborgene Sicherheitslücken zu finden. Ein VDP zu verwenden, um grundlegende Sicherheitsprobleme zu finden, die intern entdeckt werden könnten, ist jedoch Ressourcenverschwendung.

Asset-Verwaltung

Wenn es darum geht, Programmfehler zu finden, müssen Sie wissen, wo Sie anfangen sollten. Sie können hundert Sicherheitstools kaufen, aber es macht keinen Unterschied, ob Teams Anwendungen, Systeme und Dienste ohne Ihr Wissen ad hoc einrichten, insbesondere wenn Sie keine Möglichkeit haben, diese Assets zu ermitteln und Sicherheitsbewertungen durchzuführen. Erkundigen Sie sich bei den Personen und Teams, die für die Entwicklung neuer Anwendungen, Systeme und Dienste verantwortlich sind, um zu sehen, ob sie einen Prozess zum Erstellen und Verwalten einer Bestandsaufnahme dessen haben, was hochgefahren wird, und wem es gehört. Wenn es keinen aktuellen Prozess gibt, ist dies eine großartige Gelegenheit, mit diesen Teams zusammenzuarbeiten, um einen Prozess zu entwickeln. Bei der Ermittlung der Angriffsfläche ist es am besten, sich ein Bild von den Assets Ihrer Organisation zu machen. Im Rahmen dieses Prozesses sollte das Sicherheitsteam an der Entwicklung der neuen Infrastrukturimplementierung beteiligt werden, um Sicherheitsüberprüfungen durchzuführen. Es empfiehlt sich, ein umfangreiches Inventar an Assets und Inhabern zu haben. Diese Art von Inventar ist nützlich, wenn neue Patches angewendet werden, für die bestimmte Systeme vorübergehend heruntergefahren werden müssen. Sie bietet einen Fahrplan für die einzelnen Personen oder Teams, die informiert werden müssen, und darüber, welche Systeme betroffen sind. Ein robuster Prozess zur Asset-Verwaltung sorgt dafür, dass Inhaber früher im Prozess identifiziert, regelmäßig aktualisiert werden und dass alle Systeme im Unternehmen wie vorgesehen funktionieren.

Überlegen Sie abgesehen von der proaktiven Asset-Verwaltung, welche reaktiven Maßnahmen Sie auch implementieren können, um Assets zu identifizieren, die zu Ihrem Unternehmen gehören, aber Ihre standardisierten Asset-Management-Prozesse nicht erfüllt haben. Dazu können dieselben Aufklärungsprozesse verwendet werden, die auch von Sicherheitsforschern genutzt werden, die an VDPs und Bug Bounty-Programmen teilnehmen. Sie können beispielsweise kostenlose Open-Source-Tools verwenden, die Internet-IP-Bereiche oder Domains scannen und aufzählen, die möglicherweise zu Ihrer Organisation gehören. Wenn Sie in Google nach Behebung von Bug Bounty suchen, erhalten Sie eine Vielzahl von Tipps und Tricks, mit denen Sie Assets aus Ihrer Organisation identifizieren können, die Ihnen nicht bekannt waren.

Grundlegendes Scannen auf Sicherheitslücken

Nachdem Sie nun eine solide Grundlage dafür haben, wo Sie Sicherheitsprobleme finden müssen, sehen wir uns an, wie Sie das tatsächlich tun. Abhängig von den Ressourcen Ihrer Organisation gibt es verschiedene Ebenen, in die Sie einsteigen können. Sie müssen jedoch über Ihr Programm zur Offenlegung von Sicherheitslücken ein Gleichgewicht zwischen Ihren internen Sicherheitsmaßnahmen und der externen Hacking-Community finden. Dieses Gleichgewicht ist je nach den verfügbaren Ressourcen für jede Organisation unterschiedlich.

Tools auswählen

Es gibt viele verschiedene Tools, die bei der Identifizierung von Sicherheitslücken helfen. Einige Tools zum Scannen auf Sicherheitslücken sind kostenlos verfügbar, während andere kostenpflichtig sind. Welche Tools Sie auswählen sollten, hängt von Ihren individuellen Anforderungen ab.

• Anforderungen Ihrer Organisation
• Wie gut jedes Tool diese Anforderungen erfüllt
• Wenn die Vorteile des Tools die Kosten überwiegen (Kosten und Implementierung)

Mit dieser Vorlage für Anforderungen (OpenDocument .ods, Microsoft Excel .xlsx) können Sie verschiedene Tools anhand Ihrer Anforderungen bewerten. Die Vorlage enthält einige Beispielanforderungen. Sie sollten sich jedoch mit Ihren Sicherheits-, IT- und Engineering-Teams über die erforderlichen Funktionen abstimmen. Bevor Sie ein Programm zur Offenlegung von Sicherheitslücken starten, sollten Sie zumindest in der Lage sein, Scans auf Sicherheitslücken für alle extern zugänglichen Assets wie Websites, APIs und mobile Apps durchzuführen. So können Sie leicht erkennbare Sicherheitslücken finden und beheben, bevor Sie externe Sicherheitsforscher zum Testen dieser Assets und Dienste einladen.

Scaneinrichtung

Automatisierte Scans auf Sicherheitslücken können viele Probleme finden, aber sie können auch zu falsch positiven Ergebnissen führen. Deshalb sind Ressourcen erforderlich, um die Ergebnisse zu validieren, bevor sie an die betroffenen Teams weitergegeben werden. Sie müssen Prozesse implementieren, um sicherzustellen, dass Scans regelmäßig ausgeführt werden und die Ergebnisse dieser Scans tatsächlich bearbeitet werden. Dies sieht für jede Organisation anders aus, aber Sie sollten mindestens Folgendes bestimmen:

• Suchlaufhäufigkeit
  • Kontinuierlich
  • Wöchentlich
  • Monatlich
• Welche Assets werden gescannt?
• Anmeldedaten
  • Authentifizierte und nicht authentifizierte Scans
  • (Tipp: Wenn du nicht mit Anmeldedaten scannst und ein Sicherheitsforscher beim Start deines VDP mit Anmeldedaten testet, kann es zu einer großen Anzahl erkannter Sicherheitslücken kommen.)
• Rollen und Pflichten
  • Teammitglieder identifizieren, die für die Durchführung der Scans verantwortlich sind
  • Bei Bedarf eine Rotation einrichten
• Scanergebnisse
  • Scanergebnisse überprüfen
  • Programmfehler nach verifizierten Sicherheitslücken melden
  • Identifizierung von Inhabern zur Behebung von Fehlern
  • Inhaber bezüglich Korrektur kontaktieren

Weiter unten in diesem Leitfaden erfahren Sie im Abschnitt Fehler beheben, wie Sie erkannte Sicherheitsprobleme beheben können.

Prozess der Sicherheitsüberprüfung

Das Scannen auf Sicherheitslücken ist zwar eine großartige Möglichkeit, reaktiv Sicherheitsprobleme in Ihrer Organisation zu identifizieren, aber die Implementierung von Sicherheitsüberprüfungsprozessen kann dazu beitragen, die Entstehung von Sicherheitslücken von vornherein zu verhindern. In diesem Leitfaden bezieht sich der Begriff Sicherheitsüberprüfung auf jede Situation, in der eine manuelle Überprüfung durch ein Mitglied Ihres Sicherheitsteams ausgelöst wird. Dazu gehört in der Regel die Befugnis, eine Änderung zu blockieren, wenn diese als zu riskant eingestuft wird. Wenn Ihr Sicherheitsteam keine riskanten Änderungen blockieren kann, benötigen Sie dennoch Prozesse zur Dokumentation des Risikos. So kann sichergestellt werden, dass die Personen, die auf die Änderung drängen, das damit verbundene Risiko kennen und es proaktiv akzeptieren.

Kriterien der Sicherheitsüberprüfung

Wann sollten Sicherheitsüberprüfungen durchgeführt werden? Wenn Sie Kriterien zum Auslösen einer Sicherheitsüberprüfung erstellen, können Sie dafür sorgen, dass alle auf dem gleichen Stand sind. Im Folgenden finden Sie einige Beispiele für Szenarien, die eine Sicherheitsüberprüfung auslösen können.

• Neue Funktion im Zusammenhang mit sensiblen Nutzerdaten wird vorgeschlagen
  • Eine neue Funktion, mit der Nutzer ihren Standort auf der Karte teilen können
  • Anforderung potenziell vertraulicher Daten von Nutzern wie Privatadresse, Geburtsdatum oder Telefonnummer
• Bestehende Funktionalität wird umfassend aktualisiert.
  • Vorhandene Nutzerdaten auf eine neue Art und Weise zu verwenden, die die Nutzer möglicherweise nicht erwarten, ohne ihnen die Möglichkeit zu geben,
  • Änderungen an Funktionen in Bezug auf Authentifizierung, Autorisierung und Sitzungsverwaltung
• Änderungen an der Produktionsumgebung des Unternehmens
  • Änderungen der Netzwerkkonfiguration, insbesondere solche, die dazu führen können, dass Dienste extern verfügbar gemacht werden
  • Installation neuer Software zur Verarbeitung sensibler Nutzerdaten, die bei Kompromittierung indirekt für den Zugriff auf sensible Nutzerdaten verwendet werden könnte
  • Neue Systeme oder Dienste einrichten
• Interaktion mit einem neuen Anbieter oder Änderung der Arbeitsweise mit einem vorhandenen Anbieter
  • Einen neuen Anbieter einrichten, der vertrauliche Nutzerdaten verarbeitet
  • Änderungen an Ihrer Zusammenarbeit mit einem vorhandenen Anbieter, die dazu führen, dass dieser mit sensiblen Nutzerdaten umgeht

Diese Liste ist nicht vollständig, aber sie sollte Ihnen dabei helfen, darüber nachzudenken, welche Änderungen eine Sicherheitsüberprüfung erfordern sollten. Wenn Sie die Kriterien dafür definieren, was eine Sicherheitsüberprüfung erforderlich ist und was nicht, besprechen Sie dies mit den wichtigsten Stakeholdern im Unternehmen, um Folgendes sicherzustellen:

• Die Stakeholder haben die Möglichkeit, die Kriterien zu überprüfen und Feedback
• Die Stakeholder stimmen den Kriterien zu,
• Stakeholder vereinbaren, proaktiv Sicherheitsüberprüfungen anzufordern

Dokumentieren Sie diese Kriterien und wie Sie eine Sicherheitsüberprüfung anfordern (z. B. Melden eines Fehlers in einer Warteschlange, die das Sicherheitsteam überwacht), um es Ihrer Organisation so einfach wie möglich zu machen, diesen Prozess zu befolgen.

Ressourcen für Sicherheitsprüfungen

Im Gegensatz zu automatisierten Scans können Sicherheitsüberprüfungen ressourcenintensiver sein. Jedes Sicherheitsteam hat am Tag nur so viel Zeit, um eine Vielzahl von Aufgaben zu erledigen, sodass Sie abschätzen müssen, wie viele Sicherheitsüberprüfungen auf der Grundlage Ihrer Kriterien generiert werden können. Wenn Sie der Meinung sind, dass Ihr Team überlastet ist und hinterherhinkt, werden diejenigen, die auf die Einführung ihrer Funktionen warten, vom Sicherheitsteam verärgert. Dies kann zu einem kulturellen Wandel in der Organisation führen, bei dem das Sicherheitsteam als Blocker und nicht als Partner angesehen wird. Wenn der Prozess der Sicherheitsprüfung nicht effizient ist, werden viele Personen und Teams versuchen, ihn vollständig zu umgehen. Wenn die Ressourcen eng gefasst sind, sollten Sie die Kriterien für eine Sicherheitsprüfung lockern und bereit sein, ein größeres Restrisiko in Kauf zu nehmen. Wenn Vorfälle aufgrund fehlender Ressourcen für Sicherheitsüberprüfungen auftreten, rechtfertigt dies den Bedarf an zusätzlichen Sicherheitsressourcen.

Sicherheitsüberprüfungen durchführen

Bei der Entscheidung, welche Sicherheitsüberprüfungen und wie sie durchgeführt werden sollen, benötigen Sie eine priorisierte Warteschlange, aus der Sie Daten abrufen können. Schaffen Sie eine standardisierte Möglichkeit, mit der andere in Ihrem Unternehmen eine Sicherheitsüberprüfung mit allen Informationen anfordern können, die Sie für eine angemessene Priorisierung benötigen. Betrachten Sie beispielsweise einen Fragebogen, der Aspekte wie die Art der Änderung enthält, einschließlich einer kurzen Zusammenfassung der Änderung und der Arten von Nutzerdaten, die betroffen sein könnten. Anhand der Antworten auf diese Fragen können Sie potenzielle Sicherheitsüberprüfungen automatisch in Änderungen mit hohem, mittlerem oder geringem Risiko einstufen. Wenn eine Änderung ein hohes Risiko darstellt, ist möglicherweise eine umfassendere Sicherheitsüberprüfung erforderlich. Wenn eine Änderung ein geringeres Risiko mit sich bringt, können Sie möglicherweise einen einfacheren Sicherheitsüberprüfungsprozess implementieren, um die erforderlichen Ressourcen zu reduzieren und den Prozess zu beschleunigen, wodurch das Unternehmen besser unterstützt wird. Sie können in Ihrem Team eine Rotation einrichten, die für die Verwaltung der Warteschlange für Sicherheitsüberprüfungen verantwortlich ist, dafür sorgt, dass neue Sicherheitsprüfungen von Mitgliedern Ihres Teams aufgenommen werden, und um den Fortschritt bestehender Sicherheitsprüfungen zu verfolgen. Der tatsächliche Ablauf der Sicherheitsüberprüfung hängt davon ab, was untersucht wird. Beispielsweise kann eine neue Funktion in Ihrer mobilen App dazu führen, dass ein Sicherheitstechniker den Code überprüft und nach potenziellen Sicherheitslücken sucht. Neu installierte Software muss möglicherweise überprüft werden, um sicherzustellen, dass die Zugriffssteuerung ordnungsgemäß eingerichtet ist. Die Zusammenarbeit mit externen Anbietern kann einen völlig anderen Prozess darstellen. Weitere Informationen finden Sie im Fragebogen zur Bewertung der Anwender-Sicherheitsrisiken von Google.

Fehlerbehebung

Es ist wichtig, Fehler zu finden, aber die Sicherheit wird erst verbessert, wenn diese behoben wurden. Es ist gut, zu wissen, welche Risiken für Ihre Organisation bestehen. Es ist jedoch besser, dieses Risiko effizient angehen zu können.

Sicherheitslückenverwaltung

Sicherheitslücken stammen aus einer Vielzahl von Ressourcen, darunter interne Bemühungen (z. B. Scans auf Sicherheitslücken und Sicherheitsüberprüfungen), Penetrationstests und Audits von Drittanbietern oder auch externe Sicherheitsforscher, die Sie über Supportkanäle informieren, bevor Ihr VDP offiziell gestartet wird. Ihre Organisation benötigt eine Möglichkeit, neue und bestehende Sicherheitslücken zu kategorisieren, damit sie an die richtigen Stakeholder weitergegeben, korrekt priorisiert und zeitnah behoben werden. Wenn Sie Ihr VDP starten, wird ein neuer Strom von Sicherheitslücken in Ihre Prozesse zur Verwaltung von Sicherheitslücken aufgenommen. Mit soliden Prozessen für die Bewältigung dieser Sicherheitslücken können Sie den Fortschritt in Bezug auf die Behebung verfolgen und auf Anfragen von externen Sicherheitsexperten nach Updates reagieren. Die Möglichkeit, eine Sicherheitslücke schnell zu priorisieren und mit VDP-Teilnehmern über den Behebungszeitpunkt zu informieren, wird die Einbindung der Sicherheitsforscher-Community erhöhen und den Ruf der Sicherheit Ihrer Organisation verbessern. In den folgenden Abschnitten werden verschiedene Aspekte Ihres Programms zur Verwaltung von Sicherheitslücken beschrieben, die Sie vor dem Start Ihres VDP einrichten sollten.

Standards für Schweregrade und Abhilfemaßnahmen festlegen

Wenn Sie eine gemeinsame Sprache für die Schwere von Sicherheitslücken und die idealen Behebungsfristen für jeden Schweregrad erstellen, ist es einfacher, Standarderwartungen an Ihre Organisation festzulegen. Wenn jede Sicherheitslücke wie ein Notfall behandelt wird, wird Ihre Organisation ihre Ressourcen erschöpfen und das Sicherheitsteam nervös machen. Wenn jede Sicherheitslücke als eine niedrige Priorität gilt, werden Sicherheitslücken nie behoben und das Risiko eines Sicherheitsverstoßes steigt. Jede Organisation hat begrenzte Ressourcen, daher müssen Sie eine Wichtigkeitsrangfolge festlegen. Dieses Ranking enthält Kriterien, anhand derer Ihre Organisation nachvollziehen kann, in welchen Schweregrad eine Sicherheitslücke fällt, sowie die mit jedem Schweregrad erwarteten Behebungsfristen. Entwerfen Sie eine Reihe von Richtlinien für Schweregrade und teilen Sie diese mit den wichtigsten Stakeholdern in Ihrer Organisation, um Feedback zu erhalten. Wenn beispielsweise das Engineering-Team an der Ausarbeitung Ihrer Schweregradstandards beteiligt ist, werden sie diese Standards mit größerer Wahrscheinlichkeit akzeptieren und sie einhalten, wenn es an der Zeit ist, eine Sicherheitslücke innerhalb eines bestimmten Zeitraums zu beheben. Diese Richtlinien für Schweregrade können je nach den spezifischen Risiken Ihres Unternehmens variieren. Sie können eine Bedrohungsmodellierung in Betracht ziehen, um darüber nachzudenken, welche Bedrohungen am wahrscheinlichsten und wirkungsvollsten für Ihre Organisation sind, und Beispiele für Probleme aufzunehmen, die unter die einzelnen Schweregrade fallen. Im Folgenden finden Sie ein Beispiel für Schweregrade und Abhilfezeitpläne für eine Finanzorganisation.

Schweregrad	Beschreibung	Zeitplan für die Problembehebung	Beispiel(e)
Kritisch	Probleme, die eine unmittelbare Gefahr für unsere Nutzer oder unser Unternehmen darstellen	Inhaber : Ein primärer Inhaber muss innerhalb von 8 Stunden ermittelt werden, um sicherzustellen, dass die Sicherheitslücke behoben wird. Anruf- und Seitenressourcen nach Bedarf, auch außerhalb der normalen Geschäftszeiten. Problembehebung: Das Problem selbst sollte so schnell wie möglich oder höchstens innerhalb von drei Arbeitstagen behoben werden oder zumindest dem Risiko ausgesetzt sein.	Manipulation einer Produktionsdatenbank, die die Finanzdaten aller Nutzer enthält. Ein Angreifer, der Zugriff auf Geschäftsgeheimnisse wie unsere firmeneigenen Investitionsalgorithmen erhält. Ein aktiver Vorfall, bei dem ein Angreifer Zugriff auf unser internes Netzwerk oder unsere vertraulichen Produktionssysteme erhält.
Hoch	Probleme, die bei ihrer Ausnutzung erheblichen Schaden verursachen können	Inhaber:Ein primärer Inhaber sollte innerhalb eines Arbeitstags angegeben werden. Problembehebung:innerhalb von 10 Arbeitstagen (ca. 2 Wochen)	Sicherheitslücken, die zum Zugriff auf vertrauliche Nutzerdaten oder -funktionen führen können (z. B. die Fähigkeit eines Nutzers, Geld von einem anderen Nutzer zu stehlen)
Medium	Probleme, die schwerer auszunutzen sind oder nicht zu direkten Schäden führen.	Inhaber:Ein primärer Inhaber muss innerhalb von fünf Arbeitstagen angegeben werden. Problembehebung:innerhalb von 20–40 Werktagen (ca. 1–2 Monate)	Überprüfte Probleme, die von automatisierten Scannern identifiziert wurden, z. B. Patches für Sicherheitsupdates ohne bekannte Exploits. Probleme bei der Offenlegung von Informationen, die wahrscheinlich für weitere Angriffe hilfreich wären Probleme mit Ratenbegrenzungen, die möglicherweise ausgenutzt werden könnten (z. B. ständige Erraten von Passwörtern für einen Nutzer)
Niedrig	Probleme mit minimalen Auswirkungen. Wird hauptsächlich zur Protokollierung bekannter Probleme verwendet.	Es ist nicht erforderlich, einen Inhaber zu finden oder innerhalb einer bestimmten Frist eine Fehlerbehebung durchzuführen.	Offenlegung von Informationen, die kein wahrscheinliches Risiko darstellt, aber nicht extern zugänglich sein muss

Insektenpflege

Hier geht es nicht um Haarschnitte, sondern um sicherzustellen, dass Fehler richtig formatiert sind, damit sie einfach behoben werden können. Legen Sie anhand der vorherigen Tabelle als Richtlinie Ihre eigenen Schweregraddefinitionen fest. Mit diesen Definitionen werden Programmfehler in verschiedene Schweregrade eingeteilt und an die Verantwortlichen übermittelt.

Neben dem Zuweisen eines Schweregrads für jede Sicherheitslücke müssen Sie dafür sorgen, dass Ihre Fehler in einem Standardformat vorliegen, das die Verarbeitung der empfangenden Teams vereinfacht. Sicherheitslücken werden in verschiedenen Formaten in Ihre Prozesse zur Sicherheitslückenverwaltung aufgenommen (z. B. automatisierte Scannerergebnisse oder manuelle Aufzeichnungen aus Sicherheitsüberprüfungen). Wenn Sie sich die Zeit nehmen, jede Sicherheitslücke in ein Standardformat umzuwandeln, erhöht sich die Wahrscheinlichkeit, dass das empfangende Team das Problem schnell verstehen und beheben kann.

Dieses Format oder diese Vorlage kann je nach Organisation und den wichtigsten Informationen variieren, um Inhaber bei der Behebung von Fehlern zu unterstützen, die ihnen zugewiesen wurden. Hier ist jedoch eine Beispielvorlage, die Sie verwenden können. Sie können diese Vorlage später wiederverwenden, wenn Sie das Formular zur Offenlegung von Sicherheitslücken für Forscher erstellen.

Titel: <einzeilige Beschreibung des Problems, normalerweise der Typ der Sicherheitslücke und der betroffene Asset/Dienst usw.; optional den Schweregrad angeben oder den Schweregrad einem Feld im Problemtracker zuordnen> Zusammenfassung: <kurze Beschreibung der Sicherheitslücke und warum sie wichtig ist> Reproduktions-Auswirkungen: <Schritt-für-Schritt-Anleitung zum Darstellen der Sicherheitslücke/der Ausbeutung der Sicherheitslücke: Die Auswirkungen der Sicherheitslücke: <Schritt-für-Schritt-Anleitung zur Veranschaulichung der Auswirkungen der Sicherheitslücke / der Ausbeutung der Sicherheitslücken: wie sich die Auswirkungen auf die Sicherheitslücke beseitigen:

Hier ist ein Beispiel für eine potenziell schwerwiegende Sicherheitslücke:

Titel: [HIGH] Unsecure Direct Object Reference (IDOR) auf Profilseiten Zusammenfassung: Die Profilseiten unserer App haben einen IDOR gefunden, der es Nutzern ermöglicht, unbefugt Zugriff auf das Profil eines anderen Nutzers zu erhalten und es zu bearbeiten, einschließlich des vollständigen Namens, der Privatadresse, der Telefonnummer und des Geburtsdatums. Wir haben die Logs überprüft und festgestellt, dass dieses Problem anscheinend noch nicht ausgenutzt wurde. Dieses Problem wurde intern entdeckt. Schritte zur Reproduktion:

1. Richten Sie einen Proxy wie Burp Suite ein, um Traffic auf einem Mobilgerät mit installierter App abzufangen.
2. Rufen Sie Ihre Profilseite auf und fangen Sie die zugehörige HTTP-Anfrage ab.
3. Ändern Sie profileID=###### in profileID=000000 (dies ist ein Testnutzer) und senden Sie die HTTP-Anfrage mit.
4. In der Anwendung wird das Profil des Nutzers 000000 angezeigt. Sie können die zugehörigen Informationen ansehen und bearbeiten.

Angriffsszenario / Auswirkungen: Jeder Nutzer kann diese Sicherheitslücke nutzen, um das Profil eines anderen Nutzers anzusehen und zu bearbeiten. Im schlimmsten Fall könnte ein Angreifer den Prozess zum Abrufen der Profilinformationen jedes Nutzers in unserem gesamten System automatisieren. Obwohl wir der Meinung sind, dass dies noch nicht ausgenutzt wurde, ist es wichtig, dass wir es als Standardproblem mit hohem Schweregrad behandeln. Wenn wir Anzeichen für eine Ausbeutung feststellen, kann sich dies in den KRITISCH-Schweregrad eskalieren. Abhilfemaßnahmen:Implementieren Sie serverseitige Prüfungen, damit der Nutzer, der die Anfrage stellt, Zugriff auf das über den Wert von profileID angeforderte Profil haben sollte. Wenn Alice beispielsweise angemeldet ist und die Profil-ID 123456 hat, Alice jedoch die Profil-ID 333444 angefordert hat, sollte dem Nutzer eine Fehlermeldung angezeigt werden und dieser Versuch, auf das Profil eines anderen Nutzers zuzugreifen, protokolliert werden. Weitere Informationen zu IDOR und dessen Behebung finden Sie in den Materialien von OWASP zu diesem Fehler.

Sie sparen Zeit und manuellen Aufwand, wenn Sie Möglichkeiten finden, die Konvertierung von Sicherheitslücken aus verschiedenen Quellen in Ihr Standardformat zu automatisieren. Je mehr Sicherheitslücken entstehen, desto häufiger stoßen Sie in den Abhilfeschritten auf häufige Themen. Zusätzlich zu Ihrer generischen Vorlage für das Fehlerformat können Sie zusätzliche Vorlagen für gängige Arten von Sicherheitslücken erstellen.

Inhaber werden gesucht

Einer der schwierigsten Aspekte der Verwaltung von Sicherheitslücken besteht möglicherweise darin, Inhaber zu identifizieren, die bei der Behebung von Fehlern helfen, und die Zustimmung zu gewinnen, Ressourcen für die planmäßige Behebung von Fehlern einzusetzen. Wenn Sie Prozesse für die Asset-Verwaltung eingerichtet haben, geht dies etwas einfacher. Falls nicht, könnte dies als Motivation dienen. Je nach Größe Ihrer Organisation kann die Suche nach einem Inhaber einfach oder äußerst komplex sein. Wenn Ihr Unternehmen wächst, wächst auch der Aufwand, zu bestimmen, wer für die Behebung neu entdeckter Sicherheitsprobleme verantwortlich ist. Erwägen Sie die Implementierung einer Rotation im Einsatz. Der im Dienst zuständige Person ist dafür verantwortlich, nicht zugewiesene Sicherheitslücken zu prüfen, Inhaber zu ermitteln und je nach Schweregrad zu priorisieren. Selbst wenn Sie ermitteln können, wer für die Behebung einer Sicherheitslücke verantwortlich ist, und diese dem Fehler zuweisen, müssen Sie die Person davon überzeugen, Zeit in die Behebung der Sicherheitslücke zu investieren. Dieser Ansatz kann je nach Team oder Person und anderen Elementen, an denen sie arbeiten, variieren. Wenn Sie die organisatorische Unterstützung für Ihre Schwerestandards und Abhilfemaßnahmen erreicht haben, können Sie sich darauf beziehen. Manchmal kann es jedoch zusätzliche Überzeugungsarbeit erfordern, um jemanden zur Behebung eines Fehlers zu bewegen. Hier sind einige allgemeine Tipps zur Behebung von Sicherheitslücken:

• Erklären Sie den Grund: Wenn einem Nutzer eine Sicherheitslücke zugewiesen wird, die behoben werden muss, ist das in der Regel unerwartete Arbeit. Erläutere, warum dieses Problem zeitnah behoben werden muss (z.B. das Auswirkungs-/Angriffsszenario) und versichere dem Inhaber, dass er es versteht.
• Kontext einholen: Manchmal verfügt nur eine Person über das Wissen, das zur Behebung eines Fehlers erforderlich ist, und sie arbeiten möglicherweise gerade an anderen Aufgaben. Nehmen Sie sich Zeit und finden Sie heraus, welche das sind. Möglicherweise sind die anderen Aufgaben wichtiger als die kurzfristige Behebung dieser Sicherheitslücke. Einfühlungsvermögen und Flexibilität bei den Behebungsfristen zu zeigen, trägt dazu bei, Wohlwollen zu erzielen und die Beziehung zu denjenigen zu stärken, die Sie zur Behebung von Sicherheitslücken benötigen. Achten Sie aber darauf, nicht zu viel Spielraum zu lassen, da Ihr Unternehmen sonst die Fristen für die Korrektur nicht ernst nimmt.
• Erklären Sie, wie:Auch wenn Sie dem Fehler Hinweise zur Fehlerbehebung hinzufügen, ist der Inhaber der Fehlerbehebung möglicherweise verwirrt oder benötigt Hilfe, um zu erfahren, wie der Fehler behoben werden kann. Wenn sie Hilfe bei der Fehlerbehebung brauchen, hilf ihnen, sie beizubringen. Wenn Sie den Inhabern Fehler melden, ohne sie zu unterstützen, beeinträchtigt dies die Beziehung des Unternehmens zum Sicherheitsteam. Wenn Sie anderen so viel wie möglich helfen, erhalten sie die Möglichkeit, aktuelle und zukünftige Sicherheitslücken zu schließen und andere zu informieren.
• Anfrage anpassen: Verschiedene Teams und Einzelpersonen haben möglicherweise bereits Prozesse für die Annahme und Priorisierung eingehender Arbeitsanfragen. Einige Teams möchten vielleicht, dass alle eingehenden Anfragen über ihre Vorgesetzten gesendet werden. Andere wiederum möchten, dass Hilfeanfragen in einem Standardformat gesendet werden. Einige arbeiten nur an dem, was in einem Sprint definiert wurde. In jedem Fall ist es wahrscheinlicher, dass Ihre Anfrage priorisiert und bearbeitet wird, wenn Sie sich etwas Zeit nehmen, um Ihre Anfrage an das Format anzupassen, das das Team oder die Person normalerweise für Hilfeanfragen verwendet.
• Eskalieren als letzten Ausweg: Wenn Sie alle oben genannten Maßnahmen ergriffen haben und die Person oder das Team, das für die Behebung einer Sicherheitslücke verantwortlich ist, sich nicht die Zeit nimmt, ein schwerwiegendes Sicherheitsproblem zu beheben, können Sie bei Bedarf an die Führung eskalieren. Dies sollte immer nur das letzte Mittel sein, da es Ihre Beziehung zu der betreffenden Person oder dem betreffenden Team schädigen kann.

Ursachenanalyse

Mit einer Ursachenanalyse (RCA) können Sie nicht nur einzelne Sicherheitslücken ermitteln und beheben, sondern auch systemische Sicherheitsprobleme identifizieren und beheben. Die Ressourcen sind begrenzt, daher ist es verlockend, diesen Schritt zu überspringen. Wenn Sie jedoch Zeit in die Analyse von Trends in Ihren Sicherheitslückendaten sowie in die Untersuchung kritischer und schwerwiegender Fehler investieren, können Sie Zeit sparen und das Risiko auf lange Sicht reduzieren. Angenommen, Sie bemerken in Ihrer App immer wieder, dass dieselbe Sicherheitslücke (z. B. Intent-Weiterleitung) immer wieder auftritt. Sie beschließen, mit den Teams zu sprechen, die diese Sicherheitslücke in Ihre App einschleusen, und stellen fest, dass die meisten nicht verstehen, was Intent-Weiterleitung ist, warum sie wichtig ist oder wie sie verhindert werden kann. Sie haben einen Vortrag und einen Leitfaden zusammengestellt, um Entwickler in Ihrer Organisation über diese Sicherheitslücke zu informieren. Diese Sicherheitslücke wird wahrscheinlich nicht vollständig verschwinden, aber ihre Häufigkeit wird wahrscheinlich abnehmen. Wenn du dein VDP startest, ist jede von Dritten gemeldete Sicherheitslücke deine bestehenden internen Sicherheitsprozesse durchgegangen. Wenn du eine Untersuchung von Fehlern aus deinem VDP durchführst, erhältst du noch mehr Einblicke in die systematische Verbesserung deines Sicherheitsprogramms.

Erkennung und Reaktion

„Erkennung und Reaktion“ bezieht sich auf alle Tools und Prozesse, die Sie eingerichtet haben, um potenzielle Angriffe auf Ihre Organisation zu erkennen und darauf zu reagieren. Dies kann in Form von gekauften oder selbst entwickelten Lösungen erfolgen, die Daten analysieren, um verdächtiges Verhalten zu identifizieren. Im Abschnitt Grooming Bugs haben wir beispielsweise darüber gesprochen, jedes Mal zu protokollieren, wenn ein Nutzer versucht, nicht autorisierten Zugriff auf das Profil eines anderen Nutzers zu erhalten. Möglicherweise wird ein Signal oder eine Benachrichtigung generiert, wenn Sie feststellen, dass ein Nutzer eine große Anzahl von fehlgeschlagenen Versuchen, innerhalb kurzer Zeit auf die Profile anderer Nutzer zuzugreifen, generiert. Sie können sogar den Prozess des Blockierens dieses Nutzers für den Zugriff auf Ihre Dienste für einen bestimmten Zeitraum oder für unbestimmte Zeit automatisieren, bis die Situation überprüft und der Zugriff manuell wiederhergestellt werden kann. Wenn Sie noch keine Erkennungs- und Reaktionsmechanismen haben, können Sie mit einem Berater zusammenarbeiten, der Sie bei der Entwicklung eines DFIR-Programms (Digital Forensics and Incident Response, DFIR) für Ihre Organisation unterstützt. Wenn Sie bereits Erkennungs- und Reaktionsmechanismen implementiert haben, sollten Sie bedenken, welche Konsequenzen es haben kann, wenn fünf, zehn oder sogar hundert Sicherheitsforscher auf Ihre mit dem Internet verbundenen Angriffsflächen testen. Dies kann große Auswirkungen auf Ihre vorhandenen IDS/IPS-Systeme (Intrusion Detection and Prevention) haben.

Zu den potenziellen Risiken gehören:

• Überlastung bei Benachrichtigungen:Eine Flut von Warnungen oder Signalen, die wie schädliche Angriffe aussehen, in Wirklichkeit aber normale, genehmigte Tests von Sicherheitsexperten, die an deinem VDP teilnehmen. Es kann so viel Rauschen erzeugt werden, dass es schwierig wird, echte Angriffe von legitimen Sicherheitstests zu unterscheiden.
• Fehlalarme für die Reaktion auf Vorfälle:Wenn auf einer Webseite am Samstag um 2:00 Uhr Prozesse eingerichtet sind, sind diese nicht gerne bereit, einen potenziellen Verstoß zu untersuchen, bei dem es sich eigentlich nur um einen Sicherheitsforscher handelt, der legitime Tests durchführt.
• Blockierung von Sicherheitsexperten: Wenn Sie aggressive IPS-Systeme (Intrusion Prevention-Systeme) eingerichtet haben, blockieren Sie möglicherweise die IP-Adresse eines Sicherheitsforschers, der versucht, Scans, manuelle Tests usw. auszuführen, um Sicherheitslücken zu identifizieren und Ihnen zu melden. Wenn ein Sicherheitsforscher im Rahmen eines VDP nach fünf Minuten gesperrt wird, verliert er unter Umständen das Interesse und kann sich stattdessen auf das Programm einer anderen Organisation konzentrieren. Dies kann dazu führen, dass Sicherheitsforscher generell nicht an Ihrem Programm teilnehmen, was das Risiko erhöht, dass Sicherheitslücken unentdeckt bleiben und daher Ihrer Organisation nicht bekannt sind. Auch wenn Sie Ihr IPS an sich nicht abschwächen möchten, gibt es andere Maßnahmen, die Sie ergreifen können, um das Risiko einer Abkopplung von Forschern zu minimieren.

Wie Sie mit diesen Risiken umgehen können, hängt größtenteils davon ab, welchen Ansatz Sie für die Zusammenarbeit mit externen Sicherheitsforschern verfolgen möchten. Wenn Sie eher Blackbox-Tests wünschen, die echte Angriffe simulieren, müssen Sie nichts unternehmen. In diesem Fall werden durch den Traffic des Forschungsteams Benachrichtigungen generiert. Ihr Team kann Maßnahmen ergreifen, um den Fall zu untersuchen und entsprechend zu reagieren. Dadurch kann Ihr Team üben, wie es bei echten Angriffen aussieht, kann aber die Einbindung von Sicherheitsforschern verringern, insbesondere wenn sie von Tests blockiert werden. Dies kann auch dazu führen, dass ein echter Angriff übersehen wird und Sie Zeit mit der Untersuchung legitimer Tests verbringen. Wenn Sie einen eher Graybox-Ansatz bevorzugen, können Sie mit Sicherheitsforschern zusammenarbeiten, um ihren Testtraffic selbst zu identifizieren. Auf diese Weise können Sie Traffic auf die weiße Liste setzen oder anderweitig aus den Tests und den daraus resultierenden Benachrichtigungen herausfiltern. Ihr Team wird in der Lage sein, echte Angriffe besser von genehmigten Tests zu unterscheiden, und die Forscher können Sicherheitslücken finden und melden, ohne von Ihren Systemen zur Einbruchsprävention behindert zu werden. Einige Organisationen bitten Sicherheitsforscher, ein Formular einzureichen, um eine eindeutige Kennung zu beantragen, die an Header in von ihnen generierten Anfragen angehängt werden kann. Auf diese Weise kann die Organisation Traffic für den Forscher auf die weiße Liste setzen und feststellen, ob der Forscher damit beginnt, den vereinbarten Testumfang zu überschreiten. In diesem Fall können Sie sich an die Forschenden wenden und sie bitten, so lange zu warten, bis Sie gemeinsam einen Testplan ausarbeiten können.