Achten Sie auf die Lücke! Wer ist in Ihrem Unternehmen für den Schutz vor Identitätsbedrohungen verantwortlich?

Identitätsbedrohungen (d. h. die Verwendung kompromittierter Anmeldeinformationen für den böswilligen Zugriff auf gezielte Ressourcen) sind zum dominierenden Element der heutigen Bedrohungslandschaft geworden. Darüber hinaus sind dies die Bedrohungen, vor denen sich Unternehmen am schwersten schützen können seitliche Bewegung und die Verbreitung von Ransomware verursacht scheinbar täglich großen Schaden. Dennoch besteht in den meisten Organisationen tatsächlich eine Lücke in der Frage, wer tatsächlich für die Verhinderung dieser Angriffe verantwortlich ist. Und diese Lücke ist einer der Hauptgründe dafür, dass Unternehmen Schwierigkeiten haben, gegen Identitätsbedrohungen die Oberhand zu gewinnen.

In diesem Beitrag besprechen wir diese Lücke anhand eines Beispielanwendungsfalls. Ziel ist es, alle Cybersicherheitsexperten dazu anzuregen, darüber nachzudenken, wie präsent diese Lücke in ihrem Unternehmen ist und wie sie behoben werden kann.

Identitätsteams sind nicht dafür verantwortlich, Cyberangriffe zu verhindern

Treffen Sie Jack. Jack ist ein Experte für Identitäts- und Zugriffsmanagement (IAM) Ingenieur in seiner Firma. Ein Teil von Jacks Rolle besteht darin, die Multifaktor-Authentifizierung zu implementieren (MFA) Schutz für den Zugriff seiner Benutzer. Als absoluter Profi bewertet, kauft und implementiert Jack ein MFA-Lösung für alle SaaS- und Web-Apps seines Unternehmens sowie für den Remote-VPN-Zugriff auf die lokale Umgebung und den darin enthaltenen Remote Desktop Protocol (RDP)-Zugriff.

Aber weil MFA für RDP Da die Installation eines Agenten auf jedem Server in der Umgebung erforderlich ist, wird die Entscheidung getroffen, diesen nicht auf einer bestimmten Gruppe älterer Server bereitzustellen, die mehrere geschäftskritische Anwendungen unterstützen. Hier besteht die Sorge, dass die zusätzliche Auslastung der MFA-Agenten zum Absturz dieser Server führt, was zu inakzeptablen Ausfallzeiten führt. Unter diesen Gesichtspunkten gilt das Projekt als erfolgreich.

Sicherheitsteams sind nicht für die Bewertung und Bereitstellung von Identitätsschutzprodukten verantwortlich

Lernen Sie jetzt Jill kennen, eine Security Operations Center (SOC)-Managerin im Sicherheitsteam ihres Unternehmens. Ihr KPI besteht darin, Cyberangriffe zu verhindern, zu erkennen und darauf zu reagieren. Jill ist sich dessen bewusst Ransomware Angriffe, die sich über die gesamte Unternehmensumgebung ausbreiten, stellen eine kritische Bedrohung dar. Angreifer erreichen diese Verbreitung, indem sie kompromittierte Benutzeranmeldeinformationen verwenden, um sich bei so vielen Computern wie möglich anzumelden. Um dies zu verhindern, investiert Jills Team erhebliche Anstrengungen, um auf Warnungen zu reagieren und proaktiv nach anormalen Benutzerzugriffen zu suchen, die auf eine solche Ausbreitung hinweisen könnten.

Allerdings waren weder Jill noch irgendjemand aus ihrem Team an der Evaluierung, dem Testen und der Einführung der MFA-Lösung beteiligt, die jetzt in der gesamten Unternehmensumgebung eingesetzt wird. Da ihr Fokus voll und ganz auf Cyberangriffe liegt, ist ihre einzige Reaktion die Freude über den erfolgreichen Abschluss des MFA-Projekts.

Das Ergebnis: Cyberangriffe, die Identitätsbedrohungen beinhalten, stoßen auf wenig Abwehr

Eines Tages schlägt Ransomware zu. Die Gegner erkennen, dass die App-Server der Organisation das beste Ziel für die Geiselnahme sind. Um die Kontrolle über diese Server zu erlangen und die darauf befindlichen Daten zu verschlüsseln, versuchen sie, sich über RDP mit den Anmeldeinformationen eines kompromittierten Benutzers anzumelden. Und da es auf diesen Servern kein MFA gibt, ist der Versuch erfolgreich. Jetzt haben die Angreifer die volle Kontrolle und können dem Unternehmen ihre Ransomware-Anforderungen aufzwingen.

Lassen wir unsere Geschichte hinter uns und denken wir darüber nach, was hier passiert ist.

Gelernte Lektionen: Wenn niemand das Risiko besitzt, gehört das Risiko Ihnen

Was hat diesen Verstoß also möglich gemacht, obwohl engagierte und talentierte Identitäts- und Sicherheitsteams im Einsatz waren? Die Antwort liegt darin, wie Jack und Jill die Rolle wahrnehmen, die ihnen in ihrer Organisation zugewiesen wurde.

Jack seinerseits hatte nicht die Aufgabe, die Verbreitung von Ransomware zu verhindern, sondern vielmehr die Bereitstellung einer MFA-Lösung. Aus seiner Sicht wurden die Server ohne MFA-Schutz nicht als Sicherheitsrisiko, sondern als fehlender Prozentsatz der gesamten MFA-Abdeckungsrate des Projekts angesehen. Und eine Abdeckungsquote von 90 % ist deutlich besser als die bisherige Quote von 0 %. Es wurden alle Anstrengungen unternommen und die Ergebnisse waren zwar nicht perfekt, aber auf jeden Fall gut genug.

Jill hingegen war überhaupt nicht am MFA-Projekt beteiligt. Im Gegensatz zu SIEM oder EDR wird MFA nicht als Sicherheitsprodukt betrachtet, sondern vielmehr als Schwerpunkt des Identitätsteams. Wäre Jill an den MFA-Diskussionen beteiligt gewesen, hätte sie möglicherweise herausgefunden, dass die App-Server offengelegt wurden, und sie dazu gedrängt, sie zu aktualisieren, so dass das MFA-Projekt nicht als abgeschlossen betrachtet werden würde, bevor diese Server vollständig geschützt wären.

Ist Jack also für den Verstoß verantwortlich? Nicht wirklich, denn das lag nie in seiner Verantwortung. Bedeutet das, dass Jill für die teilweise MFA-Abdeckung verantwortlich ist? Nicht wirklich, denn MFA war nie Teil ihres Zuständigkeitsbereichs.

Und das ist genau die Rechenschaftslücke, von der wir sprechen.

Besteht in Ihrer Umgebung möglicherweise eine Rechenschaftslücke?

Diese Geschichte ist ein gutes Beispiel für den Zustand von Identitätsschutz Heute. Wie sich diese Rechenschaftslücke entwickelte und warum sie nur beim Identitätsschutz auftritt (im Gegensatz zum Endpunkt- oder Netzwerkschutz), ist eine gesonderte Diskussion wert. Wichtiger ist, dass Sie sich fragen, ob in Ihrer Umgebung ein ähnliches Szenario stattfinden könnte.

Hier sind einige wichtige Fragen, die Sie sich stellen sollten:

• Sind Ihre SecOps-Teams an der Implementierung von Identitätsschutzkontrollen wie MFA beteiligt? PAM?
• Hat Ihr CISO ein Mitspracherecht bei der Gestaltung und Implementierung der IAM-Infrastruktur?
• Ist Ihrem Identitätsteam bewusst, dass die Lösungen, die es evaluiert und bereitstellt, tatsächlich die letzte Verteidigungslinie gegen Angriffe sind, die das gesamte Unternehmen gefährden könnten?

Und die wichtigste Frage: Gibt es in Ihrer Organisation einen einzelnen Interessenvertreter, der sowohl die Verantwortung trägt, Identitätsbedrohungen zu verhindern, als auch die Autorität und das Wissen hat, die Sicherheitsmaßnahmen festzulegen, die zu diesem Zweck ergriffen werden sollten? Das bedeutet nicht, dass der Identitätsschutz nach der Beseitigung der Rechenschaftslücke vollständig sein wird. Sicherlich müssen noch andere Herausforderungen bewältigt werden, bevor man dorthin gelangt. Aber es ist ein wesentlicher erster Schritt, um diesen Schutz zu ermöglichen. Letztendlich spielt es keine Rolle, ob die verantwortliche Person von der Identitätsseite oder von den Sicherheitsteams kommt. Solange es in Ihrem Unternehmen einen klaren Verantwortlichen gibt, ist der erste Meilenstein zur Beherrschung von Identitätsbedrohungen erreicht.