Mein Name ist Charlene Spasic. Ich bin als Advisor bei KupingerCole Analysts tätig und werde heute mit Bastian Schwittay von Palo Alto Networks über Attack Service Management sprechen. Hi Bastian, schön dich dabei zu haben. Hallo Charlene. Unser heutiges Thema lautet Sicherung ihrer digitalen Grenze. Navigieren durch die sich ständig weiterentwickelnde Bedrohungslandschaft. Zunächst einige organisatorische Informationen zu diesem Webinar. Die Audio-Steuerung wird von uns übernommen. Sie sind alle zentral stumm geschaltet. Das heißt, Sie müssen sich weder stumm noch laut schalten.
Es werden während des Webinars einige Umfragen durchgeführt. Die Ergebnisse werden am Ende des Webinars in der Fragerunde diskutiert. Sie haben außerdem zu jeder Zeit die Möglichkeit, Fragen zu stellen. Das passiert über den Q&A-Bereich im Control Panel. Und last but not least, dieses Webinar wird aufgezeichnet. Die Aufnahme sowie die Folien werden in den kommenden Tagen zur Verfügung gestellt.
Ja, zur heutigen Agenda. Ich starte mit einem Überblick über das Thema Attack Service Management und präsentiere die Ergebnisse des aktuellen Leadership Compass aus 2023 zu diesem Thema. Danach gebe ich ab an Bastian, unser heutiger Gast von Palo Alto Networks und am Ende gibt es die Umfrageergebnisse und eine Q&A-Session.
Gut, ja, was ist ASM? Wie funktioniert es? Was sind die Hauptmerkmale und Trends? Zunächst mal, was ist Attack Service Management? Fangen wir an bei dem Attack Service. Das beschreibt die gesamte mögliche Angriffsfläche, welche eine Organisation bietet. Es beinhaltet alle möglichen Einstiegspunkte für einen Angreifer und zwar über die gesamte digitale Infrastruktur eines Unternehmens. Dazu gehören auch alle Tochtergesellschaften, Partnergesellschaften etc.
Das heißt, jede Hardware, Software, Storage, Identitäten, das gesamte Netzwerk, alles, was dazu gehört und was Angreifer potenziell ausnutzen könnten, um Angriffe durchzuführen. Angriffe, so wie beispielsweise Services zu stoppen oder unerlaubt Zugriff zu dem System zu erhalten und das Unternehmen möglicherweise zu kompromittieren. Und ASM-Lösungen helfen dabei, diese Angriffsfläche zu erkennen, sage ich mal, und potenzielle Bedrohungen zu reduzieren.
Im Leadership-Kompass werden viele verschiedene Funktionen, ja, sage ich mal, betrachtet, die ASM-Tools bieten und wir haben diese Funktionen in vier Hauptfunktionen unterteilt, beziehungsweise gruppiert. Zunächst haben wir Asset-Erkennung und Klassifizierung. Das sind Erkennungstechniken, um festzustellen, welche Assets überhaupt zu einer Organisation gehören. Und die ASMs finden halt quasi über diese Techniken alle Assets, die in einem Zuständigkeitsbereich liegen.
Das passiert durch Abhören, durch Portscannen, durch Netzwerkkartierung, durch Asset-Inventarscannen und andere, ja, Technologien. Und diese Assets, die gefundenen, werden auch klassifiziert im Sinne von, ist es ein IoT-Device, ist es ein IT-Device, worum handelt es sich. Nachdem die Assets bekannt sind, wird geprüft, ob diese Schwachstellen aufweisen, indem beispielsweise die Konfiguration überprüft wird. Die gefundenen Schwachstellen werden dann einer Bewertung unterzogen, wie viel Risiko diese Schwachstelle quasi explizit für meine Organisation bietet.
Da wird auch der Geschäftskontext einbezogen und schlussendlich werden die Risiken priorisiert, im Sinne von, was ist für mein Unternehmen, für mein Geschäft am kritischsten. Im nächsten Schritt, bei dem Punkt drei, geht es um Mitigation und Behebung von Schwachstellen. Da sprechen wir hauptsächlich über Patch- und Konfigurationsaktualisierungen. Allerdings lässt sich generell festhalten, dass es grundsätzlich um Ansätze zum Umgang mit Schwachstellen geht.
Wie wir wissen, können Schwachstellen halt mitigiert werden, um das Risiko zu verringern, oder im besten Fall werden Schwachstellen komplett behoben, um das Risiko zu vermeiden. Und schlussendlich, um die ganzen Informationen zu präsentieren, bieten ASM-Tools verschiedene Möglichkeiten, die Informationen zu visualisieren, in Form von Dashboards, in Form von Berichten. Und auch hier gibt es verschiedene Arten des Reportings für unterschiedliche Zielgruppen. Ist es jetzt ein Entscheider, ist es ein Analyst, diese zwei Zielgruppen brauchen gegebenenfalls unterschiedliche Informationen.
Wir haben festgestellt, dass es zwei Hauptansätze für ASM gibt, und zwar ist es einmal auf der linken Seite das Externe-ASM, kurz E-ASM, und auf der rechten Seite das Cyber-Asset-ASM, also kurz C-A-ASM. Und kurz zur Beschreibung, was diese zwei unterscheidet, Externe-ASM stellt quasi die von außen sichtbaren Assets dar, und verfügt auch über Funktionen zur Schwachstellenbewertung und Risikoanalyse. Und wie funktioniert das Ganze?
In der Regel ist es so, dass man als Anwender so ein Tool bei sich deployed und das in seine Organisation einführt und dann seinen Domänennamen eingibt, dem Tool zur Verfügung stellt, und das Tool führt eine Analyse durch und findet alle zugehörigen Subdomänen, alle IPs, alle Anwendungen, die mit dieser Domäne im Zusammenhang stehen, und überwacht diese auch.
Der andere Ansatz, den wir sehen, ist der Cyber-Asset-Attack-Surface-Management, und dieser eignet sich eher für die, in Anführungszeichen, interne Sicht, intern im Sinne von On-Prem-Systeme, Private Cloud, also quasi alle Teile, die zu diesem logischen Konstrukt von dem Unternehmen gehören. Und hierbei wird das Scannen eines Netzwerks durchgeführt, um die Assets zu finden, und es gibt auch die Möglichkeit, Informationen aus einem bestehenden Asset-Management, zum Beispiel einer CMDB, in so ein Tool zu laden.
Auch hier werden Schwachstellenanalysen durchgeführt und Risikobewertungen abgegeben durch das ASM-Tool. Ja, das waren die zwei Haupttypen, aber ASM kann darüber hinaus eine Vielzahl von Anwendungsfällen unterstützen, die wir hier sehen. Es kann unter anderem dabei helfen, Schatten-IT aufzudecken, also das sind Systeme und Anwendungen, die ohne das Wissen der IT-Abteilung im Unternehmen eingesetzt werden. Und diese Systeme können besonders kritisch sein, da diese nicht den definierten Standards der IT in diesem Unternehmen gerecht werden, den Sicherheitsstandards.
ASM kann beispielsweise auch dabei helfen, IoT-Geräte zu finden, die sich noch nicht in der CMDB finden, die noch nicht inventarisiert wurden. Ein spannender Anwendungsfall, auf den wir auch gleich nochmal im Detail eingehen werden, ist das Dark-Web-Monitoring, Dark-Web-Überwachung. Das bedeutet, dass quasi das Dark-Web auf bestimmte Inhalte geprüft wird, die dort einfach nicht sein sollten. Und des Weiteren gibt es auch die Möglichkeit, Einbruchs- und Angriffssimulationen darzustellen, was meiner Meinung nach auch sehr spannend ist.
Das bedeutet, es werden Angriffsszenarien nachgestellt, um Schwachstellen zu finden, was auch einfach sehr gute Ergebnisse liefern kann, um Risiken aufzufinden und auch Möglichkeiten aufzeigt, diese Risiken zu beheben. Und dann natürlich das Thema Compliance, die Einhaltung gesetzlicher oder regulatorischer Vorschriften, worauf wir gleich auch nochmal einen Blick werfen werden.
Ja, ASM-Tools bieten viele Möglichkeiten der Integration und arbeiten optimal, wenn sie in die bestehende IT-Landschaft eingebunden sind. Dazu liefern diese Tools, die wir im Leadership-Kompass beurteilt haben, viele verschiedene Schnittstellen und einige sehen wir jetzt hier in dieser Liste, darunter beispielsweise die Integration in ein ITSM, um Tickets zu generieren zu gewissen Vorfällen. Diese Tickets können weitergeleitet werden an verantwortliche Personen und bearbeitet werden und der Fortschritt wird auch getrackt.
Oder die Integration in Richtung ein SIEM- oder SOAR-Tool, das beispielsweise schon Informationen zu Bedrohungen sammelt. Es gibt auch die Möglichkeit der Integration mit Third-Party-Systemen, also Drittanbietern. Darüber hinaus sehen wir auch UAM, Unified Endpoint Management oder MDM, Mobile Device Management, für das Gerätemanagement. Auch Themen wie VMS, also Vulnerability Management Systeme, sind interessant für eine Integration, da dort gegebenenfalls schon Informationen über Schwachstellen gesammelt werden.
Auch Themen wie PAM, Privilege Access Management, SIEM, also Cloud Infrastructure Entitlement Management und Endpoint Protection, sprich EDPDR und XDR. Ja, sprechen wir über Schwachstellen. Unter dem Begriff Schwachstelle kann sich ja sehr viel verbergen und was wir jetzt hier sehen, ist eine Liste von Arten von Schwachstellen, die ASM-Systeme auswerfen können. Im Grunde genommen geht es in der Regel darum, festzustellen, ob Konfigurationen nicht korrekt sind, ob Patche fehlen oder ob bereits bekannte Schwachstellen im Unternehmen vorhanden sind.
Und dazu werden verschiedene Quellen einbezogen, wie beispielsweise Datenbanken mit bekannten Schwachstellen, damit zum Beispiel hier in der Liste die NVD, National Vulnerability Database. Darüber hinaus auch sehr interessant festzustellen, ob veraltete oder ausgediente Software im Einsatz ist, die natürlich aufgrund von fehlenden Sicherheitsupdates wiederum Nährboden für Angreifer bieten kann.
Und auch sehr spannend, wenn wir an Zugriffe denken, einerseits der unautorisierte Zugriff, also wer hat Zugriff, obwohl er diesen gar nicht haben sollte, und auch übermäßig bereitgestellte Berechtigungen, wer hat für die Ausführung seiner Tätigkeit zu viele Rechte, was potenziell auch wieder zu einem Risiko führen kann. Kommen wir zum Thema Dark Web Monitoring, vorhin schon kurz angekündigt.
Ja, im Dark Web können diverse Informationen über Sie oder Ihr Unternehmen vorhanden sein, oder auch gehandelt werden, und ASM-Tools helfen dabei, diese Informationen herauszufinden.
Es kann durchaus interessant sein und auch nicht absehbar, was alles an Informationen über bestimmte Personen oder über Unternehmen im Dark Web zu finden ist, und das geht von kompromittierten Anmeldedaten über durchgesickerte Informationen, Informationen wie zum Beispiel geistiges Eigentum oder auch persönlich identifizierbare Informationen, also sprich Passdaten, Fotos, also alles sehr, sehr sensible Informationen, die man im Normalfall nicht mit jedermann im Dark Web teilen möchte.
Und im Dark Web gibt es auch unterschiedliche Foren und Gruppen für Cyberkriminelle, auch Handelsforen von Malware, auch Handelsforen für unterschiedliche Informationen, wo es einfach interessant sein kann, diesen zu folgen, um über aktuelle Entwicklungen informiert zu sein, wie zum Beispiel geplante Angriffe oder geplante Attacken. Thema Compliance. Wie bereits angekündigt, gibt es eine Vielzahl von Compliance-Frameworks oder halt Rahmenwerken, welche ASM-Tools unterstützen.
Die Liste ist lang, ich werde jetzt auch nicht im Detail auf alle einzelnen Rahmenwerke eingehen, aber was sich meiner Meinung nach zusammenfassend sagen lässt, ist, dass die bekannten und etablierten internationalen Rahmenwerke unterstützt werden, wie zum Beispiel ISO 27001, sehen wir hier, das dient für die Absicherung von Systemen oder auf dem deutschen Markt immer wieder gerne gesehen, Thema Datenschutzverordnung, EU GDPR, General Data Protection Regulation haben wir hier und diese legt fest, wie personenbezogene Daten gesammelt und gespeichert werden dürfen.
Und ja, ASM-Tools haben verschiedene Möglichkeiten, bieten verschiedene Möglichkeiten, um bei der Umsetzung und Einhaltung dieser Rahmenwerke zu unterstützen. Gut, dann kommen wir zur ersten Umfrage für unser heutiges Seminar und da haben wir die Frage, verfügt Ihre Organisation bereits über eine Attack-Service-Management-Lösung? Die Antwort A ist ja, also sprich, Sie haben bereits eine, B ist nein, Sie haben noch keine und C, noch nicht, aber auf der Suche nach einer Lösung. Da sind wir sehr interessiert.
Ich lasse kurz ein paar Sekunden, dass Sie einmal die Gelegenheit haben, mich hier zu antworten und dann gehen wir weiter. Gut, was haben wir darüber hinaus in der Forschung zu ASM festgestellt? ASM ist ein Feld, was sich aktuell noch weiterentwickelt und aktuell noch nicht standardisiert ist, also im Sinne von die Funktionalitäten, die ASM bietet, innerhalb der unterschiedlichen Produkte. Einige Produkte liefern bereits eine Vielzahl an Funktionen und diese haben einen guten Entwicklungsgrad, andere sind quasi gerade dabei, diese auszubauen.
Nicht alle Anbieter entwickeln ihre Lösung komplett selber, sondern beziehen teilweise auch Drittanbieter in die Produkte mit ein oder lassen gewisse Funktionen durch Drittanbieter komplett übernehmen und verlassen sich da sehr stark auf die Drittanbieter. Es gibt zum Beispiel einen Fall, in dem ein Cyberasset-ASM von einem Third-Party-Vulnerability-Management-System abhängt, um ein Beispiel zu nennen.
Dann, was wir auch noch quasi festgestellt haben, ist, dass die Integration mit anderen IT und Security-Tools sehr wichtig ist, einfach um umfassende Informationen für die Auswertung zu generieren. Einige Anbieter verwenden Dark-Web-Monitoring, andere verwenden dieses nicht. Und es ist auch sehr interessant, meiner Meinung nach, dass einige Anbieter Services wie Penetration-Tests anbieten oder Web-Teaming, das passiert allerdings gegen einen Aufpreis. Welche Trends konnten wir beobachten?
EASM ist heute und wird perspektivisch ein wichtiger Bestandteil der Sicherheitsarchitektur von Organisationen sein, insbesondere solche mit Web-Services oder Web-erreichbaren Diensten. Die Funktionen, die wir heute sehen, werden sich perspektivisch sicherlich weiterentwickeln und zunehmend standardisiert werden. Und halt auch das Thema Markenschutz wird voraussichtlich mehr an Relevanz gewinnen. Es lässt sich auch feststellen, dass die Implementierung der Produkte sehr unterschiedlich sind.
Das liegt daran, dass die Historie der Produkte und die Art und Weise der Entwicklung dort sehr stark mit rein spielt. Das wirkt sich teilweise auf die Stärken und Schwächen der jeweiligen Produkte aus. Und last but not least, letztendlich werden EASM und CAASM voraussichtlich zu einem einzigen ASM verschmelzen, da es natürlich wirtschaftlicher ist, ein einziges Produkt zu verwenden.
Das lässt sich einfach daraus schließen, dass eine Vielzahl der Features, die in EASM und CAASM vorhanden sind, relativ ähnlich sind oder gleich sind und sich nur die darunter liegende Technologie unterscheidet. Dann kommen wir zur zweiten Umfrage. Welcher Ansatz scheint für Ihr Unternehmen der sinnvollste zu sein? Einmal haben wir hier External ASM, also eher von außen fokussiert auf von außen erreichbare Assets. Oder Cyber Asset ASM, primär fokussiert auf die interne Infrastruktur, also On Prem, Private Cloud und so weiter. Oder beides.
Wie wir in den Trends gesehen haben, wird es perspektivisch wahrscheinlich eine Zusammenführung der beiden geben. Vielleicht wäre das ja ein Anwendungsfall für Sie.
Gut, dann gehen wir auch hier einmal weiter. Kommen wir zum Leadership Compass Verfahren, also der Methodik, mit welcher die verschiedenen Anbieter analysiert wurden und die dazugehörigen Bewertungskriterien. Hier sind die vier Schritte des Verfahrens skizziert. Zunächst ist es so, dass wir, also als Copinger Call, die Analysten auf die entsprechenden Anbieter für ein Thema zugehen. Also diese werden herausgefunden, die werden kontaktiert, es werden Informationen eingeholt und die Produkte auch in einer Demonstration betrachtet.
Die Analysten sprechen mit den Anbietern und geben den Anbietern einen sehr umfangreichen technischen Fragebogen, wo sie Informationen zu ihrem Produkt abfragen. Die Informationen werden analysiert und es wird ein Entwurf erstellt. Dieser Entwurf wird im nächsten Schritt einem Faktencheck unterzogen, um sicherzugehen, dass alle Informationen korrekt dargestellt werden. Sollte das der Fall sein, wird der Report auf unserer Webseite veröffentlicht. Es gibt insgesamt neun Kategorien, anhand dessen ein Produkt im Leadership Compass bewertet wird.
Wir haben einmal fünf produktbezogene Kategorien, die wir hier sehen, und vier anbieterbezogene Kategorien, die wir auf der nächsten Seite sehen werden. Zunächst einmal sehen wir hier die Sicherheit des Produktes, das heißt, wie viele Sicherheitsfunktionen sind in dem Produkt vorhanden, also wie robust ist das Produkt. Gibt es eine Verschlüsselung innerhalb des Produktes, gibt es Zugriffskontrollen, etc. Funktionalität prüft, ob die Produktfunktionen, über die wir heute gesprochen haben, ob diese vorhanden sind, wie gut sind diese entwickelt.
Dann haben wir das Thema Deployment, wie einfach ist das Produkt zu deployen, gibt es mehrere Teile oder ist es quasi eine integrierte Lösung. Interoperabilität, wie gut funktioniert das Produkt mit anderen Diensten, werden Industriestandards unterstützt, ist es generell einfach, mit anderen Produkten zu verbinden. Und natürlich Usability, wie einfach ist die Anwendung für zum Beispiel Administratoren oder Analysten. Dann haben wir die anbieterbezogenen Bewertungskriterien. Das Thema Innovation, wie innovativ ist der Anbieter, bietet das Produkt innovative Funktionen.
Thema Marktposition, wie viele Kunden haben Produkte des Anbieters im Einsatz, in welchen Branchen befinden sich diese Kunden, in welcher Region befinden sich diese Kunden. Ökosystem, wie ist das Netzwerk des Anbieters, gibt es Partner, wie sind diese weltweit verteilt und natürlich die finanzielle Stärke, wie profitabel ist das Unternehmen, ist es ein etablierter Anbieter oder haben wir hier ein junges Startup. Und all diese Fragestellungen und Informationen fließen in unsere Analyse ein und führen schlussendlich zu einer Bewertung der einzelnen Anbieter und Produkte.
Ja, die Gruppierung der Anbieter erfolgt anhand von vier Kategorien, beziehungsweise vier Arten des Leadership. Einmal haben wir das Product Leadership mit Blick auf die Funktionen, also die Funktionalität und Vollständigkeit des Produktes. Market Leadership mit Fokus auf Marktposition, Anzahl und Verteilung von Kunden. Innovation Leadership, wie innovativ ist der Anbieter, wie innovativ sind die Funktionen, die im Produkt vorhanden sind und Overall Leadership, quasi als Kombination der drei vorangenannten. Und dann einmal die Ergebnisse aus dem Leadership Compass 2023 zum Thema ASM.
Kommen wir zunächst zu den Overall Leaders. Aufgrund der knappen Zeit können wir jetzt nicht intensiv alle Ergebnisse diskutieren. Es lässt sich allerdings zusammenfassend sagen, dass die Overall Leader also primär große und etablierte Anbieter von Security-Lösungen sind oder ASM-Spezialisten, darunter auch Palo Alto Networks, den wir heute als Gast bei uns haben. Und dann sehen wir die Grafik. Auf der rechten Seite der Grafik sehen wir die Leader in rot, in der Mitte die Challenger und auf der linken Seite die Follower. Dann haben wir das Thema Product Leadership.
Das setzt sich zusammen aus der Bewertung der Produktmerkmale und Funktionalitäten, welche ein Produkt nun mal bietet. Die Liste der Funktionalitäten sehen wir hier. Über einige haben wir bereits im Detail heute gesprochen und auch hier sehen wir auf der rechten Seite in der Grafik die bewerteten Anbieter unterteilt nach Leader, Challenger und Follower. Follower haben wir in diesem Fall tatsächlich keine. Das heißt, dass die Funktionalität bei allen Anbietern zumindest einen gewissen Reifegrad aufweist.
Ja, Market Leadership spiegelt die Marktpositionierung der Anbieter wieder. Spitzenreiter sind auch hier große Anbieter von Security-Lösungen und ASM-Spezialisten. Challenger und Follower sind zwar in erster Linie auch auf ASM fokussiert. Diese Anbieter bieten allerdings auch andere Produkte und Dienstleistungen an. Und last but not least die Innovation Leader mit Blick auf die innovativsten Lösungen und Technologien.
In der Liste sehen wir einige interessante und innovative Funktionalitäten hier links eingeblendet, wie zum Beispiel den Einsatz von KI zur Erkennung von Assets und Risikopriorisierung oder das Angebot von Playbooks und Anleitungen zur Behebung von Schwachstellen. Auch hier auf der rechten Seite wieder die Grafik mit der Übersicht über die Verteilung der Anbieter.
Ja, jeder der Anbieter wurde zusätzlich in einer Spider-Chart-Grafik dargestellt und die einzelnen Achsen in diesem Spider-Chart, das sind acht Stück in dem Fall, die spiegeln die produktbezogenen Funktionalitäten wieder und zeigen jeweils die Bewertung pro Kriterium. In dieser Grafik sehen wir jetzt das Spider-Chart von Palo Alto Networks und wie wir sehen, ist der Anbieter in jeder der Kriterien recht stark.
Ja, und in diesem Sinne gebe ich gerne weiter an unseren heutigen Gast, Bastian von Palo Alto Networks. Ja, vielen Dank.
Ja, ich freue mich sehr, hier zu sein heute und die Gelegenheit zu haben, unsere Tech Service Management-Lösungen vorstellen zu dürfen. Sie heißt Cortex Expanse und Cortex, das ist sowas wie der Geschäftsbereich bei Palo Alto Networks, der sich komplett mit dem Thema Security Operations beschäftigt. Hier ordnen wir das ein und die Anbieter auch von Firewalls, Cloud Security und viel mehr. Aber heute geht es allein um Tech Service Management und ich bin Systems Engineer bei Palo Alto Networks.
Ein kleines Spezialzusatzwort habe ich hier hinzugefügt, nämlich das Active Tech Service Management und ich hoffe, in den nächsten 15 Minuten so ein bisschen erklären zu können, warum wir meinen, dass das ein wichtiger Bestandteil ist, eine aktive Lösung zu haben und werde auch versuchen, nicht zu viel zu wiederholen, was in der hervorragenden Einleitung schon alles erklärt wurde. Vielleicht ganz zu Beginn ein kleines bisschen, der Grund, warum sich Unternehmen mit dem Thema Angriffsfläche beschäftigen, wurde, glaube ich, sehr gut erklärt.
Kleiner Aspekt, der uns, glaube ich, recht wichtig ist, ist, dass es einfach extrem unübersichtlich geworden ist, was Unternehmen heutzutage an schützenswerten Systemen extern exponiert haben. Und das kommt durch verschiedene Megatrends, denen wir alle unterworfen sind. Nicht nur das mobile Arbeiten, befeuert durch auch Pandemien und so weiter. Überhaupt die Transformation in Richtung Cloud, Digitalisierung im Allgemeinen und die immer stärkere Vernetzung. Immer mehr Applikationen werden entwickelt und sind auch öffentlich verfügbar.
Mir macht es einfach extrem schwierig, für Sicherheitsteams hier den Überblick zu behalten. Und das sind einige wesentliche Herausforderungen, die wir zum Anlass genommen haben, Cortex Expanse quasi zu designen und zu bauen und auf eine ganz bestimmte Weise dem entgegenzutreten. Die vier Probleme, die ich so rauspicken würde, das sind Cluster, könnte man sagen, könnte man sich wie folgt vorstellen. Es geht zum einen darum, das tatsächlich ist Fakt, nicht alle Assets sind Unternehmen heutzutage mehr bekannt.
Wo man noch vor 10 bis 15 Jahren mit einem sehr gut gepflegten Excel-Sheet wahrscheinlich seine Infrastruktur beschreiben konnte und managen konnte, ist das komplett fragmentiert. Und diese begrenzte Transparenz ist eigentlich der Ausgangspunkt des Problems. Dazu kommt, dass eine schnelle Reaktion auf Schwachstellen, insbesondere Zero-Day-Exploits, also solche, die bekannt werden ohne Verfügbarkeit von Patches, aber womöglich schon mit ausnutzbarem Exploit-Code, das ist wirklich zurück.
Einige Jahre lang war es da sehr ruhig, aber mittlerweile sind Angreifer wieder sehr stark dazu übergegangen, das als ersten Eintrittspunkt zu suchen und zu finden, wo Schwachstellen existieren, für die noch keine Absicherung existiert, die womöglich auch von Sicherheitsfachstellenscans nur langsam oder schlecht gefunden werden können. Wenn man das Ganze ein bisschen weiter verfolgt, selbst wenn man seine Angriffsfläche kennen würde und auch Zero-Day-Exploits im Griff hätte, dann wäre es trotzdem noch problematisch, diese Vielzahl von Alarmen zu priorisieren.
Denn wir stellen fest in Evaluierungen und Tests, dass das Volumen an Angriffsflächenproblemen erheblich ist. Und dazu kommt, die Probleme werden quasi offenbart, aber den nächsten Schritt zu gehen und zu sagen, wie wahrscheinlich ist denn die Ausnutzung dieser Schwachstelle, was sind potenzielle Folgen, ist extrem diffizil. Und zu guter Letzt, es geht ja letztendlich um Reaktion. Attack Surface Management ist eines der wenigen wirklich proaktiven Security-Felder. Man möchte eigentlich Angriffen vorbeugen, indem man die Angriffsfläche vorher schon kennt und absichert.
Das geht aber nur, wenn ich auch vernünftig reagieren kann, wenn ich eine vernünftige Behebung imstande bin zu leisten. Und dazu gehört zum einen, ohne festzustellen, irgendwie eine Verknüpfung festzustellen zwischen diesen Assets oder Diensten oder Schwachstellen, die ich gefunden habe, und dem Verantwortlichen, um dann auch die richtigen Maßnahmen zu ermitteln und durchzuführen. Und auch in einer Art und Weise durchzuführen, die natürlich nicht den Betrieb des Unternehmens gefährdet oder wichtige Geschäftsprozesse unterbricht.
Und all dieses Spiel zusammen macht es Security-Teams extrem schwierig, Angriffsfläche zu verwalten und aktiv zu absichern, während es Angreifern ungeahnte Möglichkeiten bietet. Diese Kombination aus der großen Welt des Unbekannten sozusagen, gar nicht zu wissen, wie verwundbar und auf welche Art und Weise ist mein Unternehmen angreifbar, gepaart mit einer hohen Dynamik in der Angriffsfläche. Wir haben unter anderem in Studien festgestellt, dass schwerwiegende Gefahren täglich mehrmals auftreten können und auch wieder verschwinden.
Also es ist eine Menge los und es ist kein statisches Bild mehr. Die führt dazu, dass Angreifer das auch erkannt haben und mit Scans relativ schnell auf den Plan treten. In 2022 gab es einige spektakuläre dieser Zero-Day-Schwachstellen, die sehr schlimm waren, könnte man mal so sagen. Vereinfacht gesagt, innerhalb von Minuten nach Bekanntgabe von neuen Exploits wurde gescannt. Und auch Angreifer haben mittlerweile die Mittel und die Infrastruktur, um Scans auch schnell durchzuführen. Sie finden vielleicht sogar unsere Probleme schneller als wir selbst.
Ziemlich toxische Kombination und auch nochmal Motivation, in dieses Feld ASM zu investieren. Eine Statistik habe ich noch, um dem Ganzen noch so einen kleinen, eine wichtige Facette vielleicht mal aufzubringen. Das Thema Cloud. Wir haben in unserem Attack Surface Report, wir jedes Jahr durchführen, viele Umfragen und Datenanalysen fahren, festgestellt, dass die Angriffsfläche, die auf Cloud Services beheimatet ist, sagen wir mal so, also Public Cloud, dass sich da gut 20 Prozent jeden Monat ändert.
Das ist mal ein Wort herkömmlicher IT-Infrastruktur, da ändert sich bestimmt nicht jeden Monat 20 Prozent aller Services, Versionen, Assets und so weiter. In der Cloud ist das so die Benchmark. Und auf der anderen Seite steht dem entgegen, dass gerade Neuerungen, Updates, aktualisierte Konfigurationen für die Hälfte aller schwerwiegenden Risiken verantwortlich sind. Das ist der Treiber. Es ist nicht so sehr die alte, gut bekannte Infrastruktur, wo dann vielleicht hin und wieder mal eine neue Schwachstelle gefunden wird.
Es ist gerade die Veränderung, die Dynamik und Cloud ist ein Riesentreiber. Also da Agile mit DevOps-Prozessen Sachen zu entwickeln, zu testen und immer wieder zu aktualisieren, das haben wir als wesentlichen Treiber gesehen von Risiken in der externen Angriffsfläche. So viel zu dem Problem. Wie wollen wir dem entgegentreten? Ich kann es quasi auf einen Blick darstellen. Es sind fünf wichtige Facetten, die wir versuchen mit Cortex Expans zu gewährleisten und natürlich kontinuierlich zu verbessern.
Denn das Ziel ist hier, ich habe es eingangs schon gesagt, das ist eine wirklich proaktive Security-Lösung. Wie wenige es tatsächlich sind, die wir tagtäglich in unserem Security Operations Umfeld betreiben. Die alarmieren meistens, wenn Angriffe erfolgen oder schon erfolgt sind. Wir wollen also umfassende Erkennung von Angriffsflächen gewährleisten, alle über das Internet zugänglichen Assets finden. Wir sind hier in der Kategorie External ASM, um das ganz klar zu sagen. Wir wollen auch einen besseren Job machen, was Zero-Day Bedrohung angeht.
Sofortigen Überblick, schnellen Überblick, nicht quasi auch nur wenige Tage verlieren, denn das ist in solchen Situationen kritisch. Das Thema Priorisierung kam auch schon auf. Wie kann ich bei hunderten, tausenden, zigtausenden potenziellen Problemen vernünftig priorisieren? Die Bereiche mit den größten Auswirkungen feststellen, um sie dann zu beheben mit einer Orientierung in Richtung Automatisierung. Alles kann vollständig automatisiert ausgeräumt werden, aber das muss Grundbestandteil sein, um dem Herr zu werden.
Dann ist es quasi eine unternehmensfähige Lösung, eine Enterprise-fähige Lösung. Wir machen einen kleinen Doppelklick auf jeden dieser Bereiche zur Abrundung, um auch ein bisschen hinter die Kulissen zu schauen. Wie funktioniert Expanse? Was macht das Tool? Und Sie kriegen einen kleinen Einblick, wie wir das versuchen zu lösen.
Punkt 1, das wäre die umfassende Erkennung von Angriffsflächen. Was ist uns so wichtig? Man kann es, glaube ich, runterbrechen auf drei wesentliche Merkmale. Die Erkennung von Angriffsflächen soll ja jetzt von einem Tool gewährleistet werden, nicht von mir durch gute Buchführung. Wie muss sie sein? Vollständig, aktuell und genau. Vollständig in dem Sinne, dass nichts verpasst wird. Hierzu haben wir eine Indexing-Infrastruktur aufgebaut, betreiben sie seit vielen Jahren, die extrem leistungsfähig ist.
Das Scannen ist da vertikal integriert, da werden zigmal mehr Ports und Banner abgegriffen, als viele andere Scanner oder Open-Source-Tools in der Lage sind zu tun. Auf verschiedenen Wegen, wurde schon erwähnt, gibt es Portscans, gibt es Webcrawling. Manchmal nutzen wir auch Integrationen, öffentliche Datenbanken, private Datenbanken, IP-Registrierung, DNS-Domain und, und, und. Was man halt so bekommen kann, um diese Form, diese Art von Assets hier heraus zu kristallisieren.
Man kann sich vorstellen, dass wir quasi permanent ein Abbild des IPv4 und IPv6-Internets aktuell halten, bis hin zu Zertifikaten, Services, Domains und Webseiten. Außerdem muss das Ganze natürlich genau sein. Es hilft ja nichts, Assets zu melden oder Alarme zu generieren für Dinge, die mir gar nicht gehören. Und gleichzeitig aktuell, also diese Fluktuation herzuwerden. Hier nutzen wir eine Kombination aus sowohl KI-Methoden oder Machine-Learning-Methoden, um diese permanente Fluktuation und Zuordnung erstmal in Grundzügen zu gewährleisten.
Und dann gibt es aber auch den Human-in-the-Loop. Also wie in vielen Fällen ist Machine-Learning nicht fehlerfrei. Und wir brauchen quasi diese menschliche Komponente, um diese Zuordnung, das Scheibchen aus dem Internet, Ihnen zu präsentieren, was wirklich Ihres ist, genau zu halten. Und das führt so dazu, dass wir auch hohe Fluktuationsraten und eine extrem gute Abdeckung von Assets mal genau in Art und Weise in Expans bringen können. Das Ganze ist übrigens vollkommen Cloud-basiert. Sie müssen dafür nichts installieren. Es ist quasi nur eine Webseite, die man benutzt.
Zero-Day-Bedrohung, da habe ich sehr stark darauf hingewiesen, ist eine Riesenherausforderung. Wer erinnert sich nicht manchmal an die Nachtschichten zur Zeit von Lock4J, als quasi jeder IT-Leiter oder sogar Vorstand wissen wollte, sind wir betroffen und wie stark betroffen und wie werden wir das wieder los?
Das ist quasi mit Auslöser gewesen für eine spezielle Ansicht im Produkt, dem Security-Response-Center, wie eine Datenbank, eine von uns gepflegte Datenbank, der wirklich globalen Cyber-Events hochkritischer Schwachstellen, die mir da zum einen Research-Ergebnisse, Informationen, Kontext, Links, Infos und sowas bietet, also quasi im Produkt eingebettete Intelligenz, als auch natürlich diese offensichtliche Frage zu beantworten, sind wir betroffen und das quasi ohne Zeitverlust. Also wie konkret ist das Risiko für das Unternehmen?
Haben wir da Assets, die ausnutzbar sind, wo diese Schwachstellen vorliegen? Und wie ist es überhaupt, um diese Schwachstelle zu beschaffen? Ist die bloß bekannt oder gibt es dafür schon Proof-of-Concept-Code? Wird das Ganze schon ausgenutzt? Gibt es Reports darüber, dass das Ganze wirklich aktiv kompromittiert wird? Bisschen zur Behebung, Status-Tracking, wenn diese Dinge gelöst werden, verschwinden sie auch wieder aus dem Security-Response-Center, ist also auch eine dynamische Ansicht.
Um mal einen Vergleich zu ziehen mit einem Vulnerability-Management-Ansatz, der hier natürlich auch oft gefahren wird, haben wir eine Falschstudie rausgesucht, nämlich eine Ivanti-Sentry-Schwachstelle. Und es ist jetzt ein führendes Vulnerability-Management-Tool genommen, absichtlich anonym, aber denn das spielt eigentlich keine Rolle. Da hat es nach Veröffentlichung des CVEs keinen Tag gedauert, bis die CISA, sowas wie das amerikanische BSI, das als Known Exploited Vulnerability markiert hat.
Also, Schwachstelle, kaum dass sie ausgeschrieben wurde, wird sie schon ausgenutzt. In Expanse hatten wir nach 22 Stunden das komplette Abbild, bin ich betroffen in den Instanzen unserer Kunden. Der Vulnerability-Management-Vendor konnte nach 70 Stunden anfangen, Scans durchzuführen nach dieser Schwachstelle. Es klingt vielleicht nicht viel, aber diese zwei, drei Tage könnten sehr nervenaufreibend sein für ein Security-Analystenteam, das einfach keine Mittel hat, Risiko abzuschätzen, es zu bewerten für die Organisation oder grünes Licht zu geben, auch ans eigene Management.
Hier sind wir nicht betroffen, also besteht kein Risiko. Reden wir auch über Priorisierung, dann ist das auch etwas, wo wir viel Informationen verwenden wollen. Zum Beispiel, werden Schwachstellen ausgenutzt? Sind sie bekannt? Wie zuverlässig sind die? Das heißt, EPSS-Score, CVE-Scores und die gängigen, auch schon genannten, Metriken werden genutzt. Die Asset-Kritikalität wird mit einbezogen und das ist alles sehr spezifisch für diesen Alarm, dieses Asset, diese Services. Es gibt aber auch eine Art Security-Rating.
Das wird halt auch gefordert und wenn es für die Cyber-Versicherung ist, dass man sich einen Branchenvergleich heranzieht und raten lassen kann, wie gut bin ich aufgestellt gegenüber vergleichbaren Unternehmen in meinem vertikalen Bereich. Da gibt es auch eine Dynamik und das ist ebenfalls hier, wir haben es versucht, an einem Beispiel zu verdeutlichen, also Schwachstellen werden veröffentlicht, dann gibt es sicherlich einen Inzident in Cortex-Expans dazu, wenn ich denn verwundbare Assets habe.
Sobald dann der Exploit-Code verfügbar ist, öffentlich, hier ist jetzt GitHub genannt, steigt die Priorität und der Risk-Score. Das muss also angepasst werden, denn jetzt ist das Ganze viel brisanter. Und wenn dann auch noch die aktive Ausnutzung dazu kommt, also Ausnutzung in freier Wildbahn, hier in the wild, dann kriegt das Ganze die höchste Priorität und wird auf meiner Startseite quasi ganz oben stehen, wenn ich mich wieder mal einlogge und darum kümmere, meine Risiken zu bewerten.
Zum Abschluss die Behebung und diese ganzen drei Punkte bis dahin, die werden auch von anderen Tools, glaube ich, gut getan. Also jeder liefert Alarme, priorisiert die, gibt einen Risk-Score und tut da sein Möglichstes und auch wenn es da Unterschiede gibt, ist das wahrscheinlich schon eine standardisierte Funktionalität. Automatisierungsorientierte Behebung ist aber ein Alleinstellungsmerkmal von Expanse. Denn die meisten Tools, die sich ASM nennen, wir würden sie mehr Visibility nennen. Also die Scans werden durchgeführt, Alarme werden erstellt und dann stoppt das Ganze.
Und jemand geht an die Konsole, guckt sich diesen Report an und muss auf den Risiken anfangen zu arbeiten. Mit unserem Active Response Feature können wir stattdessen ein fertiges Playbook starten. Zum Beispiel ist jetzt ein Remote Desktop Server genommen, das automatisch die richtigen Schritte tritt. Also quasi nach Best Practices vorgeht, um dieses RDP Risiko zu analysieren. Das kann sein, mit anderen IT-Tools Informationen auszutauschen. Anreicherungen aus dem Splunk, aus dem SIEM, aus der CMDB, um festzustellen. Letztendlich ist nämlich das eines der vorrangigen Ziele.
Wer ist denn der Service Owner und in welchem Kontext wird das hier benutzt? Ist das eine Testumgebung oder ist das eine Produktivumgebung? Unglaublich wichtige Informationen für alle weiteren Schritte, wenn ich auch über Behebung zum Beispiel nachdenke. In der Testumgebung kann man ja vielleicht ohne große Umschweife stilllegen oder Zugriffe blockieren. Im produktiven Umfeld sollte man sich da wahrscheinlich hüten. Da muss man mit dem Service Owner in Kontakt treten. Und so wird das auch innerhalb dieses Playbooks und über sogenannte Remediation Path Rules gesteuert.
Es kann in den Weg reinlaufen, automatisch Ports zu schließen. Bei RDP allemal. Es gibt ja kaum einen legitimen Businessgrund, das wirklich zu exponieren. Oder auch gleichzeitig oder ausschließlich Tickets zu erstellen im gängigen ITSM-System, zum Beispiel ServiceNow. Wir können dann auch, nachdem jemand behauptet, dieses Risiko beseitigt zu haben, mit einem sogenannten Validation Scanning bestätigen, ob das Service wirklich nicht mehr existiert oder ob das eigentlich nur vorgetäuscht ist. Wenn der Inzident geschlossen wird, gibt es einen automatischen Report.
Es wird also gut dokumentiert, automatisch, was für Schritte unternommen wurden, um dieses Risiko zu adressieren. Auch sonst ein ziemlicher Zeitfresser, weswegen wir uns auch erlauben, diese Charts unten zu zeigen, wie lange müssen Analysten Dinge untersuchen oder wie viel Zeit vergeht bis zur Behebung. Wir können das in den Minutenbereich bringen, unter den richtigen Voraussetzungen, wo das oft sonst Stunden, Tage oder Wochen dauern kann.
Wenn man erstmal in einem großen Konzern auf die Suche gegangen ist, wer ist verantwortlich für diese und jene Website oder diesen und jenen Service oder Cloud-Workload, kann davon ein Lied singen. Das soll soweit reichen für diesen High-Level-Überblick über Cortex Expanse.
Ich hoffe, es war einigermaßen kurzweilig und ich gebe zurück an Charlene. Kommen wir zu den Umfrageergebnissen und Q&A. Die erste Frage, die wir betrachtet haben, ist, ob Ihre Organisation bereits über eine Attack-Service-Management-Lösung verfügt. Hier sehen wir 100% Ja, 0% Nein und 0% noch nicht, aber auf der Suche nach einer Lösung. Die Antwort überrascht mich etwas, also das ist sehr vorbildlich, dass scheinbar alle Teilnehmer über so eine Lösung verfügen. Ich sehe das allerdings etwas kritisch und ich glaube, das muss man reflektieren und differenzieren.
Ich denke, wenn man sich den Markt in der Breite betrachtet, können wir nicht davon ausgehen, dass alle Unternehmen bereits über so eine Lösung verfügen, sondern es wird sicherlich Unternehmen geben, die das noch nicht haben, auch Unternehmen, die auf der Suche sind. Nichtsdestotrotz lässt sich festhalten, dass diese Technologie relativ neu ist im Verhältnis zu anderen Schwachstellenlösungen. Spannend.
Bastian, was sagst du dazu? Ja, überrascht mich auch ein bisschen, so eine 100 zu 0 Statistik, wobei man sagen muss, wenn man es breit fasst, Attack-Service-Management, da gibt es auch viele Do-it-yourself-Ansätze. Das muss ja nicht immer ein kommerzielles Produkt sein und mit Skripten, Open-Source-Services, Shodan usw. kann man auch eine Art Attack-Service-Management-Lösung stricken. Vielleicht ist ja da auch jemand dabei gewesen. Aber grundsätzlich auch überraschend.
Ja, möglicherweise. Dann kommen wir zur zweiten Umfrage. Das war die Frage, welcher Ansatz, welcher ASM-Ansatz scheint für Ihr Unternehmen der sinnvollste zu sein? Wir hatten hier die Option A, eASM, Option B, Cyber-Asset-ASM und Option C, beides. Und hier sehen wir Option B, 33% und Option C, beides mit 67%. Auch sehr interessant. Scheinbar scheint Externe-ASM nicht wirklich im Fokus zu sein. Dafür eher die Kombination aus beidem.
Wir hatten gelernt in dem Webinar, in der Forschung, die wir als Guckinger Kur betrieben haben, dass perspektivisch wahrscheinlich auch die Richtung in eine Kombination von beidem gehen wird. Ist natürlich aus unternehmerischer Sicht nachzuvollziehen, dass es am meisten Sinn macht, eine Kombination zu wählen. Trotzdem überrascht mich das ein bisschen, weil es teilweise ja so ist, dass viele Unternehmen bereits gewisse Arten von Vulnerability-Management-Systemen oder anderen SIEM-Lösungen oder Ähnlichem im Einsatz haben.
Und daher hätte ich jetzt schon gedacht, dass der eine oder andere vielleicht auch Option A präferieren würde. Aber ja, das ist auch ein spannendes Ergebnis.
Bastian, wie siehst du das vielleicht aus deiner Sicht? Hast du da ein Kundenfeedback oder irgendwas wahrgenommen? Ich habe jetzt auch erst mal gestürzt, aber man könnte es auch so interpretieren, dass zwei Drittel sagen, External-ISM gehört auch jeden Fall auch dazu, ist sinnvoll. Denn wir haben ja beides quasi gesehen. Es stimmt schon, in unseren Gesprächen bekommen wir auch mit, dass selbst das Management von internen Assets noch eine Herausforderung darstellt über IoT als Treiber. Das Externe ist sicherlich Cloud und intern viel IoT, alles ist vernetzt.
Und das explodiert gerade in vielen produzierenden Gewerbe und in manchen Branchen ganz massiv. Also ich kann nachvollziehen, dass auch das Cyberasset-ISM ein Painpoint ist, den Kunden sehen und der als wichtig angesehen wird. Oder eben beides. Wobei es ist wirklich nicht ganz so einfach zu vereinigen, denn die Datenquellen sind oft ganz andere. Also intern muss man vielleicht ganz anders scannen oder kann sich an Datentöpfen bedienen oder Logs, die schon anfallen, statt so eine komplett externe Sicht quasi einzubringen.
Also ja, wir sehen definitiv beides in unseren Gesprächen. Heute habe ich über das Externe-Experience gesprochen, aber das andere auch immer mal wieder.
Ja, sehr spannend. Dankeschön. Dann wechsle ich noch einmal kurz in die Übersicht. Und wir haben auch einige Fragen im Chat gestellt bekommen.
Und zwar, wie entscheidet Expanse, ob ein Asset ein Risiko darstellt? Bastian, kannst du uns dazu was sagen?
Ja, kann ich. Gute Frage. Die sehr gute Frage, bloße Existenz eines Assets im Internet ist ja nicht gleich ein Risiko. Und manche sind ja auch wissentlich, wo man es will, Dinge öffentlich zu publizieren. Das Element in unserer Lösung, was das gewährleistet, sind sogenannte Attack Surface Rules. Das heißt, mein Asset ist erstmal ganz wertfrei. IP-Adresse, Eindienst, meine Website. Es muss irgendeinen Faktor geben, der es zum Problem macht. Manchmal ist es bloße Natur des Services. Remote Desktop Protocol wäre ein Beispiel.
Das sehen wir als kritisches Risiko an, egal wie es konfiguriert ist und in welchem Kontext. Bei anderen Dingen kommt es vielleicht auf die Version an von Webservern, ob die veraltet sind. Oder es sind Komponenten einer komplexen Applikation, wo bestimmte eigentlich nicht online sein sollten, wie Jenkins und Entwicklungstools. Also es sind Attack Surface Rules, wie so eine extra Ebene, die drübergelegt wird über dieses Inventar, was man als Basis sammelt.
Ja, sehr spannend. Dankeschön. Ich habe hier direkt auch zwei Anschlussfragen zum Thema Risiken. Und zwar einmal, wie wird der Risk Score berechnet für die Risiken? Also quasi jetzt hast du einmal erzählt, wie wird das erkannt und wie wird dann der Risiko Score berechnet?
Ja, auch eine gute Frage. Also es ist ein proprietäres System, das vorweg. Und das funktioniert auch automatisch. Ich muss dem System nicht beibringen, wie Scores gesetzt werden. Grundsätzlich spielt eine Rolle die Regel, die getriggert wurde. Und dann die verschiedenen Eigenschaften von zum Beispiel Schwachstellen der Exploit. Ist der überhaupt bekannt? Gibt es ein Proof of Concept Code? Wurde das gemeldet, als wird in freier Wildbahn ausgenutzt? Also was gibt dann Punkte drauf, wenn man so will? Ich kann das auch veredeln, noch mit zusätzlichen Bedingungen.
Ich kann zum Beispiel sagen, wenn es in dieser Business Unit auftritt, immer plus 500. Also der Score geht von 0 bis 1000. Addiere was hinzu oder nehme was weg. Wenn es eine Testumgebung ist, sinkt der Score. Das sind so verschiedene Logiken, die da zusammen spielen, kann man sagen.
Ja, sehr spannend. Dankeschön. Und auch hier noch die dritte Frage zum Thema Risiken. Welche Art von Risiken wird für die automatisierte Behebung unterstützt? Gute Frage. Das ist tatsächlich relativ gut dokumentiert. Es sind also nicht alle, das vorweg. Und im Moment beschränken wir uns auf Testumgebung. Es gibt wirklich, die meisten Kunden haben auch Bedenken, automatische Behebungen überhaupt einzusetzen. Das muss man dazu sagen. Aber auf Testumgebung scheint das oft ein guter Ansatz zu sein. Und dann sind es knapp ein Dutzend.
Also es geht um unsichere SSH-Server, RDP, Telnet-Server, unverschlüsselte FTP, Datenbank-Server, die im Internet erscheinen und nicht geklämmte S3-Buckets. Das ist recht speziell, aber bei AWS S3 ist das sehr gut ausnutzbar, wenn da schlecht konfigurierte Speicher-Buckets aufgefunden werden. Das wäre so. Es sind ungefähr zehn bis zwölf. Es ist gut öffentlich dokumentiert und ständig wachsend natürlich. Das heißt, wir bieten immer mehr Integration an mit Cloud-Service-Providern. Neu jetzt dazugekommen ist die Paloalto Networks Firewall, um Ports dicht zu machen.
Und es gibt das ständige Roadmap, das auszubauen. Sehr gut.
Ich denke, du hast auch einen interessanten Punkt angesprochen, dass einige Kunden bei der automatischen Behebung von Risiken oder von Schwachstellen einfach vorsichtig sind. Weil klar, das Tool arbeitet mit einer gewissen Logik und hat auch einen gewissen Kontext, der angewandt wird. Nichtsdestotrotz macht es sicherlich immer Sinn, nochmal ein paar Augen drüber schauen zu lassen, ob das jetzt tatsächlich ein Risiko ist, was auch behoben werden soll, oder ob gegebenenfalls ein Fehler vorliegt, oder ob andere Konstellationen einfach dazu führen könnten, dass solche Risiken akzeptiert werden.
Das kann ja sicherlich auch in dem einen oder anderen Geschäftskontext einfach der Fall sein. Absolut. Und Security-Automatisierung kann man sich nicht immer wie Ende zu Ende 100 Prozent vorstellen. Da ist teilweise schon viel gewonnen durch das Anreichern von Informationen, was man sich sonst händisch zusammensuchen müsste. Und das wieder und wieder aus Drittsystemen. Und vielleicht geht es in die Richtung, dass man so ein Hybrid-Modell fährt. Viele Infos werden automatisch integriert, enriched, ein Owner festgestellt, womöglich mit dieser ML-Engine unterstützt.
Und ein Analyst kann dann die richtige Entscheidung treffen. Ticket aufmachen, jemanden benachrichtigen oder vielleicht automatisierte Behebung in Gang setzen. Diesen Human-in-the-Loop sollten sich die meisten Kunden wahrscheinlich zu Beginn auch dort gönnen. Und allein das schaufelt schon unglaublich kapazitätenfrei und die ganzen anderen Tätigkeiten automatisch erfolgen können.
Ja, sehr spannend. Kommen wir zu einer weiteren Frage. Wir haben noch ein paar Minuten. Unsere Firma führt zweimal im Jahr Penetration-Tests durch. Und die Tester finden immer etwas. Könnten wir mit ASM Penetration-Tests eliminieren beziehungsweise ersetzen? Wie siehst du das?
Nein, können sie nicht. Aber es kommt auch auf die Art des Penetration-Tests an. Denn auch bei aller Angriffsfläche, die wir erkennen und beseitigen, gibt es ja Schwachstellen, die auch unser Tool nicht finden wird. Also in der Logik einer Applikation beispielsweise. Penetration-Tester nutzen Dinge wie SQL Injections. Also Dinge, die so weit hinten passieren in der Applikation, dass unser Tool das durch einen externen Scan nicht tut. Das ist uns auch nicht gestattet.
Also wir machen keine aktiven Pen-Tests von Schwachstellen, sondern es wird anhand von frei verfügbaren Informationen festgestellt. Bannern, Headern und solchen Dingen. Also ich würde sagen nicht. Es könnte sehr guten Input geben, was der Scope eines Pen-Tests sein könnte. Also das glaube ich schon. Aber ersetzen nicht. Das heißt, dass es oft auch viel mehr in die Tiefe geht und dann nach Kompromittierung des ersten Schrittes auch weitergehen kann. Kann ja auch dann noch die internen Kontrollmechanismen, Seitwärtsbewegungen und all sowas tun. Also ich sehe es nicht als Ersatz.
Ja, ich denke auch, dass wir hier eher eine Ergänzung sehen. Ein weiteres Mittel, um die Sicherheit zu gewährleisten, zu unterstützen, zu verbessern. Bei Ersätzen bin ich immer etwas vorsichtig, weil der Blickwinkel, der Umfang einfach unterschiedlich sein kann. Du hast auch von der Detailtiefe der zwei Verfahren gesprochen. Das sind schon sehr wichtige Punkte. Die Ergänzung ist durchaus aber was, was man sich vielleicht durch den Kopf gehen lassen kann. Zweimal im Jahr ein Pen-Test ist gut und ist wahrscheinlich schon doppelt so oft, wie das viele Unternehmen machen.
Da ist es auch eine jährliche Übung. Angriffsfläche ändert sich aber stündlich. Ich würde über das Thema ASM vielmehr als Art Monitoring und Live-Echtzeitgeschehen denken, als geplante Aktionen in beauftragter Penetration-Testing.
Sehr gut, vielen Dank. Auch gut, nochmal den Unterschied ein bisschen rauszustellen. Wir haben noch die Frage, führt Expanse einen Vulnerability-Scan durch?
Nein, tut es nicht. Wenn wir Vulnerabilities melden, und das teilweise funktioniert auch extrem genau, dann liegt es daran, dass die Applikation, auf die man zugreifen kann, über Webcrawling, Banner oder den Lock-in-Screen zumindest aufzumachen, genug Informationen hergibt, um das festzustellen. Wir machen aber kein aktives Testen der Vulnerability mit einem Exploit-Code, auch nicht mit einem harmlosen Exploit-Code, wie das angeboten wird. Wir denken darüber nach, aber aktuell ist es nicht so, und es wäre im Übrigen auch illegal, würden wir das tun, zumindest ungefragt bei Kunden.
Dieses Indexing läuft aber die ganze Zeit, und es hat auch schon ihre Systeme indexiert, ohne dass es als Pentest aufgefallen wäre, in den meisten Fällen. Super, vielen Dank. Die letzte Frage, die ich gern noch stellen würde, ist, welche Integration zu Third-Party-Lösungen existieren out of the box? Ich nehme mal an, die Frage bezieht sich jetzt auf Palo Alto mit dem Tool Cortex Expanse. Wir hatten ja vorhin eine lange Liste gesehen mit verschiedenen Integrationsmöglichkeiten.
Vielleicht gibt es da noch eine kurze Übersicht, die du uns geben kannst, was ihr jetzt genau mit Cortex Expanse out of the box liefert für Third-Party-Lösungen. Kann ich tatsächlich. Es gibt verschiedene Bereiche. Einmal Inventar-Lösungen wie CMDBs, zum Beispiel von ServiceNow, oder die drei AWS, GCP und Microsoft Azure Cloud-Anbieter. Das ist zur Integration und Anreicherung von Assets. Wir haben Integrationen auch zu Splunk, im Übrigen. Dann gibt es so Ticket-Systeme. ITSM-System ist ein großer Bereich. Dazu gehört Jira und auch wieder ServiceNow.
Vulnerability-Management-Systeme, Qualys, Tenable sind zu nennen. Das ist eins zu eins dokumentiert. Ich rattere gerade so runter, was ich aus dem Kopf weiß. Es sind einige, also so an die 20, stetig wachsend. Wobei es wird nicht einen Grad erreichen einer vollkommen Security-Orchestration-Lösung, wie sie auch von Palo Alto Networks angeboten wird, XOR, wo wir von knapp 1.000 Third-Party-Produkten reden. Das ist schon spezifisch.
Also, eigentlich passte es sehr gut, war gar nicht abgesprochen mit den Kategorien CM, ITSM und Cloud-Anbieter. Cloud-Inventar, sowohl für dieses Inventar, aber auch zu Restaurants. Also auch Network Security Groups strikter zu reglementieren. Das ist dann auch für AWS, Google und Azure verfügbar. Super. Ich danke dir, Bastian, für die Einblicke, für deine Zeit. Danke für deinen Vortrag. Dann würde ich das Webinar jetzt gerne abschließen mit zwei Folien. Einmal haben wir die European Identity und Cloud Conference dieses Jahr im Juni in Berlin.
Falls dort Interesse besteht, finden Sie alle Infos auf der KupingerCole-Website. Und einmal das Tool KC Open Select, worüber Sie relativ komfortabel Produktbewertungen machen können zu verschiedenen Kategorien und Ihren Entscheidungsprozess verbessern können. Dann bedanke ich mich bei allen Teilnehmern. Nochmal einen herzlichen Dank an Bastian für das gute Webinar und wünsche Ihnen allen einen schönen Abend. Dankeschön.
Tschüss, schönen Abend, vielen Dank.
