Am 15. März 2022 veröffentlichte die U.S. Cybersecurity and Infrastructure Security Agency (CISA) eine Alarm über einen russischen Cyberangriff auf eine Nichtregierungsorganisation (NGO).
Der russische Akteur nutzte einen Brute-Force-Angriff zum Erraten von Passwörtern, um ein inaktives NGO-Benutzerkonto zu kompromittieren. Der Bedrohungsakteur war dann in der Lage, ein neues Gerät bei der NGO anzumelden. Multi-Faktor-Authentifizierung (MFA)-Anbieter unter Verwendung des kompromittierten Kontos. Durch Ausnutzung der "Fail-Open"-Einstellungen konnte der Bedrohungsakteur die MFA ausschalten, indem er sein Gerät vom Internet trennte.
Letztlich kombinierte der Bedrohungsakteur schwache Kennwörter, ein inaktives Benutzerkonto, Standardeinstellungen, die den Komfort über die Sicherheit stellen, und eine frühere Windows-Schwachstelle. Dies ermöglichte ihnen laut CISA den "Zugriff auf Cloud- und E-Mail-Konten für die Exfiltration von Dokumenten".
In diesem Blogbeitrag geht es nicht darum, einen anderen Anbieter zu beschimpfen. Ich bin seit fast 20 Jahren bei RSA. In dieser Zeit habe ich viele Höhen und Tiefen der Cybersicherheit aus erster Hand erlebt. Lassen Sie mich Ihnen also sagen: Schadenfreude hilft niemandem.
Was ich wird In diesem Abschnitt werden einige der Ratschläge erläutert, die RSA seinen Kunden nach der jüngsten CISA-Warnung gegeben hat. Ich werde auch erklären, wie diese Ratschläge für alle MFA-Lösungen gelten.
Kleiner Spoiler-Alarm: Jede einzelne Funktion oder Anforderung, die im Rest dieses Artikels erwähnt wird, ist Teil von RSA.
MFA ist viel mehr als eine Authentifizierungsmethode
Um Angriffe wie diesen zu verhindern, müssen Unternehmen überdenken, was MFA ist, wie sich Benutzer anfangs bei MFA anmelden sollten und wie sie diese Anmeldungen über den Lebenszyklus der Benutzer hinweg aufrechterhalten können.
Denken Sie immer daran, dass die MFA nicht nur über eine Einmaliges Passwort (OTP)-Token, eine Authentifizierungs-App oder einen FIDO-Stick zur Anmeldung. Wenn Sie glauben, dass Sie sicher sind, nur weil Sie oder Ihre Nutzer zufällig biometrische Authentifizierung auf einem Smartphone verwenden, um sich bei einer Cloud-Anwendung anzumelden, dann habe ich schlechte Nachrichten für Sie: Das ist keine MFA.
Das ist nur das absolute Minimum. Damit können Sie zwar das Kontrollkästchen "MFA verwenden" für Ihr Compliance-Audit ankreuzen, aber aus der Sicherheitsperspektive wäre dies eine Verschwendung von Zeit und Geld.
Die meisten Authentifikatoren basieren auf einem kryptografischen Seed oder Schlüssel zur Authentifizierung. Hardware-Authentifikatoren bieten in der Regel ein höheres Maß an Sicherheit, da sie diesen Seed stärker schützen als softwarebasierte Authentifikatoren. Unternehmen müssen ihre Sicherheitsbedürfnisse kennen und einen Authentifikator auswählen, der ausreichend Sicherheit bietet - sowohl hardware- als auch softwarebasierte Authentifikatoren können individuelle Anforderungen erfüllen.
Die Methode selbst - ob Hardware oder Software - ist jedoch fast irrelevant, wenn bei der Registrierung der Authentifikatoren kein ausreichendes Vertrauen aufgebaut wird. Selbst wenn Ihr Unternehmen die besten Authentifikatoren einsetzt, sind diese bei falscher Handhabung nahezu nutzlos, um einen Angriff zu verhindern oder zu verlangsamen. Denken Sie an ein Auto: Nur weil Sie einen leistungsstarken Motor einbauen und die Bremsbeläge gelb lackieren, heißt das noch lange nicht, dass Sie plötzlich hinter dem Steuer eines Rennwagens sitzen. Sie müssen auch die Bremsen, die Aufhängung und die Reifen ändern - und den Fahrer darin schulen, wie man in einem echten Rennen fährt. Es gibt noch so viel mehr zu bedenken.
Anhand eines typischen Identitätslebenszyklus erkläre ich, wie Sie das Beste aus einer MFA-Lösung herausholen und sicherstellen können, dass sie die Aufgabe erfüllt, für die sie gedacht ist: den Schutz Ihrer Benutzer und die Sicherung Ihrer digitalen Werte.
Die Registrierung ist die erste Phase im Identitätslebenszyklus: Während der Registrierung wird einer Identität (einem Benutzer) ein Authentifikator zugewiesen. Doch noch bevor eine Organisation einen bestimmten Benutzer anmeldet, sollte sie eine Reihe von Fragen berücksichtigen:
- Wer kann sich für MFA einschreiben?
- Wie kann sich ein Benutzer für MFA anmelden?
Man könnte meinen, die erste Frage sei leicht zu beantworten: Jeder sollte MFA verwenden!
Es kann jedoch Benutzer oder Gruppen geben, die nicht angemeldet werden sollten oder dürfen. Denken Sie an Konten, die zwar existieren, aber nicht aktiv sind, wie z. B. Konten von Mitarbeitern, die sich im Erziehungsurlaub befinden, oder verwaiste Konten, die nie einem bestimmten Benutzer zugewiesen waren oder nicht mehr sind. Ein Sicherheitsteam sollte diesen Konten nicht erlauben, sich für MFA zu registrieren, da neue oder geänderte Authentifikatorregistrierungen für diese Konten wahrscheinlich nicht bemerkt werden. Beispielsweise werden Benachrichtigungs-E-Mails, die über geänderte Einstellungen informieren, einfach in einem nicht überwachten Posteingang landen.
Die zweite Frage ist entscheidender, denn sie muss aus zwei Perspektiven betrachtet werden:
- Wie kann die Registrierung Ihrer Organisation das gewünschte Vertrauensniveau erreichen?
- Wie kann die Registrierung das gewünschte Vertrauensniveau auf bequeme und effiziente Weise sowohl für den Benutzer als auch für die Verwaltung/den Helpdesk erreichen?
Das Vertrauen in einen Authentifikator hängt davon ab, wie er ursprünglich registriert wurde: Der Grad der Sicherheit, den ein Benutzer bei der Registrierung genießt, legt seine Vertrauensgrenze fest, solange der Benutzer den Authentifikator verwendet.
Anders ausgedrückt: Unabhängig davon, ob Sie Hardware oder Software verwenden, können Authentifikatoren nur dann das für eine MFA-Anmeldung oder Step-up-Authentifizierung erforderliche Maß an Vertrauen bieten, wenn die ursprüngliche Anmeldung stark genug war. Wenn Sie ein wackeliges Fundament legen, dann wird Ihr Haus immer instabil sein.
Es gibt viele Möglichkeiten, um zu entscheiden, wer sich anmelden kann und wie der Prozess ablaufen soll, damit sowohl Sicherheit als auch Komfort gewährleistet sind. Aber wie auch immer sich Ihre Organisation entscheidet, stellen Sie sicher, dass Sie nicht nur die Verwendung von Passwörtern für die Anmeldung.
Warum nicht? Passwörter sind bequem. Die Benutzer kennen ihre Anmeldeinformationen bereits, so dass sich die Administratoren um nichts anderes kümmern müssen, als die MFA-Lösung auf ein Active Directory zu verweisen. Richtig?
Falsch. Das ist zwar ein einfacher Weg, um die MFA-Registrierung abzuschließen, aber die ausschließliche Verwendung von Passwörtern lässt Ihr Unternehmen für alle Arten von Angriffen offen. Das schlimmste Szenario ist, dass ein Angreifer bereits ein Konto kompromittiert hat und dieses Konto dann für MFA anmeldet. Die Registrierung eines Kontos für MFA, das sollte nicht in der MFA eingeschrieben zu sein, ist praktisch dasselbe wie die Umgehung der MFA insgesamt.
Genau das ist bei dem erfolgreichen Angriff auf die eingangs erwähnte NRO geschehen. Es gab zwar zusätzliche Schritte, die der Angreifer nutzte, um seinen Zugang zu erweitern, aber die Anmeldung selbst war der fatale Fehler.
Es gibt intelligentere und sicherere Wege, Authentifikatoren zu registrieren. SecurID rät Organisationen dringend, zusätzliche technische und verfahrenstechnische Kontrollen um die MFA-Anmeldung herum einzurichten. Die Anmeldung nur mit einem Passwort ist in SecurID standardmäßig nicht möglich. Ein Kunde müsste sich schon sehr anstrengen, um diese Art der Anmeldung zu ermöglichen - und wir würden ihm bei jedem Schritt davon abraten.
Die Bestimmung der geeigneten Registrierung hängt von den verfügbaren Authentifikatoren, den erforderlichen Vertrauensstufen, den Fähigkeiten der MFA-Lösung eines Unternehmens und den dem Unternehmen zur Verfügung stehenden Tools und Verfahren ab.
Es gibt viele technische Kontrollen, die dazu beitragen können, den Anmeldeprozess zu sichern und zu vereinfachen, ohne auf Passwörter zurückzugreifen. Zum Beispiel könnten Organisationen:
- Verlassen Sie sich auf eine SMS oder Voice-OTP an eine vorregistrierte Telefonnummer vor der Einschreibung
- Benutzer müssen den Helpdesk kontaktieren, um einen Registrierungscode zu erhalten
- Verteilen Sie einen Registrierungscode per E-Mail an den Benutzer
- Drucken Sie PIN-Briefe aus und geben Sie sie weiter, um die Benutzer zu zwingen, diese eindeutige PIN für die Anmeldung zu verwenden.
- Zuweisung und Versand von Hardware-Tokens an Benutzer (in diesem Szenario sollten die Unternehmen die Token deaktiviert lassen und den Benutzer den Helpdesk anrufen lassen, um das Hardware-Token zu aktivieren)
- Anmeldung nur innerhalb des Unternehmensnetzes zulassen
Natürlich gibt es noch mehr Kontrollmöglichkeiten und verschiedene Kombinationen sind ebenfalls möglich. Organisationen mit großen und vielfältigen Benutzergruppen sollten wahrscheinlich in Erwägung ziehen, mehr als eine Möglichkeit zur Anmeldung anzubieten, was je nach Rolle des Benutzers zu unterschiedlichen Vertrauensstufen führen könnte.
All diese Kontrollen fügen Sicherheitsebenen um den Anmeldedienst selbst hinzu. Und obwohl die Einrichtung und Pflege dieser Ebenen viel Aufwand erfordert, zahlt sich diese Investition aus: Authentifikatoren, denen man vertrauen kann.
Aber das ist nur der erste Schritt zur Sicherung des Identitätslebenszyklus eines Benutzers. Es gibt noch viele weitere Szenarien, die Bedrohungsakteuren erhebliche Chancen bieten, und noch viel mehr Situationen, auf die sich Unternehmen vorbereiten sollten. Im nächsten Teil dieser Serie, In diesem Abschnitt werden wir uns mit dem Zurücksetzen, der Ausfallsicherheit und anderen Punkten im Identitätslebenszyklus befassen, denen Unternehmen Priorität einräumen sollten, um sich und ihre Teams zu schützen.
