Willkommen zu Teil II unserer Zero Trust Blog-Serie. Falls Sie noch keine Gelegenheit hatten, Teil I über die Ursprünge von Zero Trust zu lesen, können Sie dies hier nachholen.
Warum habe ich all diese Worte in meinem ersten Beitrag darauf verwendet, die Geschichte eines scheinbar nicht verwandten Rahmens von Zero Trust zu beschreiben? Ich bin froh, dass Sie fragen. Um dorthin zu gelangen, müssen wir uns damit befassen, was den Bedarf an Attack Surface Management überhaupt erst ausgelöst hat.
Obwohl der Begriff wahrscheinlich irgendwann vor dieser Ressource entstanden ist, fand ich die erste Erwähnung des Begriffs "Angriffsfläche" in einem Dokument mit dem Titel "Attack Surface Analysis Cheat Sheet" aus dem Juli 2013. In diesem Artikel wird ausdrücklich darauf hingewiesen, dass "der Schwerpunkt hier auf dem Schutz einer Anwendung vor externen Angriffen liegt", und weiter heißt es, dass "der Sinn der Angriffsflächenanalyse darin besteht, die Risikobereiche in einer Anwendung zu verstehen ... und zu erkennen, wann und wie sich die Angriffsfläche verändert und was dies aus einer Risikoperspektive bedeutet." Es überrascht nicht, dass sich dies mit einem Großteil der Inhalte überschneidet, die von der Open Web Application Security Project (OWASP)-Community zu dieser Zeit und seitdem veröffentlicht wurden. Die aktuelle Version dieses Dokuments finden Sie hier.
Ohne den gesamten Inhalt des oben genannten Spickzettels aus dem Jahr 2013 auspacken zu wollen, konzentriert sich dieses erste konzeptionelle Modell der Angriffsfläche strikt auf Anwendungen, ist aber breit genug angelegt, um auch andere Punkte einzubeziehen, über die ein Angreifer in ein System eindringen könnte. Die Autoren weisen ausdrücklich darauf hin, dass "die Analyse der Angriffsoberfläche in der Regel von Sicherheitsarchitekten und Pen-Testern durchgeführt wird". Was ist das Ziel? Pen-Tester haben es auf jeden einzelnen Vermögenswert abgesehen, den sie beim Sondieren des Sicherheitsbereichs einer Organisation (innerhalb ihres Bereichs) ausfindig machen können. Server hosten laufende Anwendungen, und zu wissen, a.) dass diese Server laufen und b.) was auf diesen Servern läuft, wird weithin als einer der ersten Schritte zur Sicherung eines Unternehmens angesehen. Es hat sich jedoch immer wieder gezeigt, dass Unternehmen nicht immer wissen, was auf ihren sich ständig ausdehnenden und schwindenden Perimetern läuft.
Die vielen Interpretationen von Attack Surface Management
Wie bei vielen Sicherheitstools sah jemand die Möglichkeit, Lösungen zu automatisieren und zu entwickeln, um die Herausforderung der Verwaltung eines komplexen Hardware- und Softwarebestands zu lösen. Einige Unternehmen erweiterten ihr Angebot (RiskIQ) und andere wie CyCognito (2017) wurden gegründet, um sich speziell darauf zu konzentrieren, was Angreifer, die Unternehmen aus dem offenen Internet auskundschaften, sehen würden. Trotzdem wurde dieser Artikel von Juli 2017 bis Dezember 2018 kuratiert und im Information and Software Technology Journal Volume 104 veröffentlicht, in dem 644 frühere Arbeiten analysiert wurden, in denen der Begriff "Angriffsfläche" verwendet wurde, und festgestellt wurde: "71 % der Arbeiten verwendeten den Begriff, ohne ihn zu definieren oder eine andere Arbeit zu zitieren. Darüber hinaus fanden wir sechs Themen für Definitionen des Begriffs "Angriffsfläche". Die Schlussfolgerung lautete, dass Praktiker "eine für ihren Bereich geeignete Definition der Angriffsfläche wählen sollten".
Laut den oben genannten Forschern haben sich bis Ende 2018 sechs Themen unter dem Dach der Angriffsfläche entwickelt: Methoden, Angreifer, Abläufe, Merkmale, Barrieren und erreichbare Schwachstellen. Bei einem Begriff, der absichtlich geprägt wurde, um viele Aspekte von Schwachstellen zu umfassen, ist es nicht überraschend, dass viele Lösungen nuancierte Ansichten darüber entwickeln, wie man das Problem angehen kann. Erschwerend kommt hinzu, dass jedes Mal, wenn eine neue Kategorie auf dem Markt auftaucht, unweigerlich eine Menge Verwirrung herrscht. Es ist ein Kampf auf Messers Schneide zwischen Unternehmen, die um jedes noch so kleine Stückchen Aufmerksamkeit wetteifern, das sie bekommen können - und wenn auch nur die geringste Chance besteht, dass der neueste Trend-Hashtag auf das zutrifft, was das eigene Produkt leisten kann, wird es aus allen möglichen Blickwinkeln in die Zange genommen. Als also die Begriffe "Angriffsfläche" und "Attack Surface Management" immer populärer wurden, begannen immer mehr Unternehmen, sich bis zu einem gewissen Grad der ASM-Kategorie anzuschließen. Dies geschah (und geschieht bis zu einem gewissen Grad immer noch) in der Zero-Trust-Welt und geschieht auch jetzt in Bezug auf die Kategorie Attack Surface Management.
Wenn man heute googelt, was "Angriffsflächenmanagement" ist, erhält man eine allgemein konsistente Antwort, die sich um den oben erwähnten Originalartikel "Cheat Sheet" herum konsolidiert hat. Die Themen konzentrieren sich auf das Scannen bekannter Assets, die Entdeckung unbekannter Assets, das Scannen bzw. die Entdeckung interner bzw. externer Assets und die kontinuierliche Überwachung dieser Assets - alles mit dem Schwerpunkt auf ausnutzbaren Schwachstellen.
Parallelen zu Zero Trust werden deutlich
Auch wenn ein breiter Konsens besteht, so sind es doch die Einzelheiten, die für Verwirrung sorgen und die Parallele zum Zero Trust aufzeigen. Hat das Schwachstellenmanagement einen legitimen Bezug zum Angriffsflächenmanagement? Ausgehend von den obigen Ausführungen ja. Es ist jedoch ein Aspekt des Attack Surface Management, der sich ausschließlich auf das konzentriert, was bekannt ist. Andere Aspekte des Attack Surface Management sind: Cloud Security Posture Management (CSPM), Cloud Application Security Management (CASM), Cloud Attack Surface Management (auch CASM), Cyber Asset Attack Surface Management (CAASM) und eine Reihe anderer.
Grundsätzlich muss das Attack Surface Management mehr umfassen als nur das wöchentliche oder monatliche Scannen bekannter Assets. Fehlkonfigurationen passieren und werden exponentiell schneller ausgenutzt als früher - in nur 7 Minuten, wie ich kürzlich bei einem realen Incident Response-Ereignis erfahren habe. Das Attack Surface Management muss dynamisch und proaktiv sein und umfangreiche Daten aus dem gesamten Internet nutzen, um die Verteidiger in Rekordzeit und ohne Unterbrechung zu den schlimmsten und am schwersten zu lokalisierenden Angreifern in ihrem Netzwerk zu führen.
Es ist an der Zeit, das Management von Angriffsflächen anders zu betrachten
So wie Zero Trust ein Rahmenwerk und ein Weg ist, so ist es auch das Attack Surface Management. Da ASM eng mit der Entdeckung und Behebung von Schwachstellen verbunden ist, passt es außerdem gut zum Mantra "Don't Trust Anything" von Zero Trust. Auf diese Weise ist Attack Surface Management eine wichtige Ergänzung des Zero-Trust-Frameworks und stellt die perfekte Ergänzung für die Unternehmenssicherheit dar. Mehr dazu in der nächsten Ausgabe.
