Die Secure Future Initiative (SFI) von Microsoft ist ein umfassendes Programm, das darauf abzielt, die digitale Sicherheit und Resilienz in einer zunehmend vernetzten Welt zu stärken. Angesichts der stetig wachsenden Bedrohungen im Cyberraum hat Microsoft diese Initiative ins Leben gerufen, um sich selbst, sowie alle anderen Unternehmen und Organisationen dabei zu unterstützen, ihre Sicherheitsinfrastrukturen zu verbessern und sich gegen zukünftige Cyberangriffe zu wappnen.

Was das konkret bedeutet, woher es kommt, was jeder¹ daraus lernen kann und wie es mich anhand eines Beispiels ganz konkret „getroffen“ [das Wort suggeriert, dass es „schlimm“ war – war es aber nicht, sondern schlicht „notwendig“] hat und wie ich damit umgegangen bin, erfahrt ihr in diesem Blogpost.  

Agenda

1. Was ist die Secure Future Initiative?
2. Passwörter – macht man das heute noch so?
3. Endlich ein sinnvoller KI Usecase
4. Was habe ich daraus gelernt? (Fazit)

Was ist die Secure Future Initiative?

In den letzten Jahren hat sich die Bedrohungslage auf der Welt signifikant verändert, ja ich möchte sagen verschlechtert (auch wenn ich sonst ein optimistisch denkender Mensch bin und sich dies normalerweise auch in meiner Sprache wiederfindet).

Spätestens mit dem Ausbruch des völkerrechtswidrigen Angriffskrieges Russlands auf die Ukraine und vor allem den damit, bzw. schon vorher, stattgefundenen Cyberangriffen, wurde uns klar:

es wird nicht besser werden, wir müssen etwas ändern!

Lesetipp an der Stelle die Aufarbeitungen der initialen Cyber-Angriffe auf die Ukraine, liest sich wie ein Krimi:

1. Defending Ukraine: Early Lessons from the Cyber War – Microsoft On the Issues
2. Ongoing Russian cyberattacks targeting Ukraine – Microsoft On the Issues

Dass sich also die Weltlage geändert hat, und damit die Cyberbedrohungslage, ist unstrittig und wird durch Microsoft mittlerweile regelmäßig im „Microsoft Digital Defense Report“ in Zahlen, Daten und Fakten dargestellt. [Zum Erscheinungsdatum dieses Posts liegt die MDDR in der Version von 2023 vor, die Version von 2024 wird voraussichtlich bald erscheinen. UPDATE: mittlerweile in Version 2024 verfügbar!]

Die größte Frage, die sich dann also stellte, ist: „was sollten WIR für UNS denn ändern?“ – Insbesondere, da Microsoft spätestens mit der Trustworthy Computing Initiative in 2002, damals noch von Bill Gates ins Leben gerufen, das Thema Security sehr hoch und in viele Prozesse und Einzelmaßnahmen gehängt hatte.

Also könnte man – durchaus entgegen der landläufig vorherrschenden, und immer noch durch die Boulevardpresse oft hochgehaltenen, aber völlig falschen Meinung „Microsoft und Security gehören nicht in einen Satz“ – denken „ist doch alles gut!“.

Und genau da liegt der Denkfehler!

Um es mit den Worten von Travis Dane, dem Bösewicht aus Under Siege 2: Dark Territory zu sagen:

„Assumption is the mother of all f*ckups!“

Travis Dane, Under Siege 2: Dark Territory

Und um es mal klarzustellen: seine Reaktion ist genau richtig, auch wenn ich Gewalt grundsätzlich ablehne, in diesem Fall eindeutig „darauf hinzuweisen“, dass man sich nicht auf sein Gefühl, sondern immer auf Zahlen, Daten und Fakten verlassen sollte, ist „genau richtig“ (auch wenn ich es persönlich anders als im Film machen würde! 🤣).

Das heißt, um mal wieder auf die SFI zurückzukommen, dass wir uns nicht darauf verlassen können, dass all das, was in der Vergangenheit geschehen und entschieden worden ist,

1. damals schon „gut“ war – also dem damaligen Stand der Technik entsprach, und
2. heute immer noch dem aktuellen Stand der Technik entspricht.

Das wiederum bedeutet, dass eine sofortige Maßnahme war und ist: jeden Stein, auf dem das „Haus“ gebaut ist, anzuheben, umzudrehen und zu überprüfen, ob dieser noch gut ist, verbessert werden muss, oder schlicht weg kann/muss.

Die zweite Maßnahme ist, dass basierend auf den definierten Prinzipien „secure by design“, „secure by default“ und „secure by operations“ für alle zukünftigen Tätigkeiten gelten muss, dass Security von vorneherein ein, wenn nicht der wesentlichste, Teil sein muss!

Und das äußert sich auch in der Aussage von Satya Nadella

„If you’re faced with the tradeoff between security and another priority, your answer is clear: Do security.”

Satya Nadella

Was im Übrigen ein Mantra von vor der SFI overruled: „never break a system“. Das heißt, bis dahin galt, dass bestehende Installationen oder Systeme nicht durch eine Änderung unterbrochen werden dürfen/sollten (natürlich war auch das nicht immer möglich, aber das Vorgehen hat dies zumindest so vorgesehen).

In der Folge bedeutet das auch, dass Partner und Kunden sich darauf einstellen müssen, dass durch Security relevante Änderungen ihre bestehenden Systeme unter Umständen verändert und angepasst werden müssen, da sie sonst nicht wie gewohnt weiter funktionieren werden!

Damit ist eine permanente „Überwachung“ und Monitoring der jeweils angekündigten Änderungen und der eigenen Produktivsysteme notwendig!
– Moment! Das war es doch vorher eigentlich auch schon so!? Ja, aber nicht immer überall stringent umgesetzt – *winkMitDemZaunpfahl*

Die obige Änderung im Vorgehen hat auch mich direkt betroffen, erwischt, oder besser: angeregt ein bestehendes System, welches einwandfrei funktioniert hat, anzupassen! Stichwort: „always change a running system“.

Und hier kommt die Story dazu:

Passwörter – macht man das heute noch so?

Wer mich kennt, der weiß: neben meiner Windmühle „VPN“ existiert noch eine zweite, nämlich „Passwörter“, bzw. positiv dargestellt: der Kampf für #gopasswordless.

Kurz gesagt: nein. Es gibt bessere Methoden – insbesondere im Enterprise Kontext – um Identitäten abzusichern, Stichworte sind: Passkeys (z.B. FIDO2), Windows Hello for Business, Managed Workload Identities in Microsoft Entra, etc.

Das gilt natürlich auch für die Verbindung zwischen einer Web App und einer Datenbank.

Worüber rede ich? Natürlich über „meine“ Group Policy Search! (siehe dazu auch die Hintergrundgeschichte: Eine kleine Geschichte der Group Policy Search ).

Denn, über die letzten 16 Jahre hat die Authentifizierung der „Middleware“ an der Datenbank über genau das funktioniert: ein Benutzername+Passwort. (es gab/gibt noch weitere Absicherungen, wie Netzwerkisolation, etc., darum soll es hier aber gar nicht gehen)

Und eben genau dieses Vorgehen entspricht nicht mehr dem „aktuellen Stand der Technik“. 😮

D.h. im Zuge der SFI ist die Vorschrift erlassen (und technisch umgesetzt) worden, dass ein Passwort nicht mehr reicht, sondern, dass die Authentifizierung über Microsoft Entra ID zu erfolgen hat.

Wie das so ist: „Mache ich morgen, wenn ich Zeit habe…“ – Zeit habe ich natürlich dafür eigentlich nie, also kam es, wie es kommen musste: der Tag mit der Scharfschaltung der Policy „keine Passworte mehr für Auth an Datenbanken“ kam und führte dazu, dass sich einige (danke für die, die sich gemeldet haben!) User bei mir meldeten, dass die GPS nicht mehr funktioniert. Na toll, ich habe doch keine Zeit!

Tja, und jetzt?

Endlich ein sinnvoller KI Usecase

Wie ihr vielleicht wisst, befolge ich mein Mantra: „wenn ich nicht weiß, wie etwas geht, dann frage ich KI“. So auch in diesem Fall:

Microsoft 365 Copilot, du bist ein erfahrener C# Visual Studio Programmierer für Azure Web Apps. Du möchtest mir beibringen, wie ich von einer Benutzernamen+Passwort basierten Authentication gegen eine Azure SQL Datenbank umsteige auf eine auf Entra ID basierende Authentication. Du erklärst mir mit Hilfe einer Step by Step Anleitung, was ich wie zu tun habe und auf welche Stolpersteine ich achten muss.

Und natürlich konnte ich über dieses Vorgehen und weiterer, gezielter Fragen an die Copilot Instanz während der Umsetzung die Herausforderung relativ schnell anpacken und lösen.

Funfact: das, was mich am längsten aufgehalten hat, ist meine Vergesslichkeit. Ich hatte verdrängt, dass für die Ausführung meiner relevanten Stored Procedure ein User entsprechende Rechte benötigt und die nicht automatisch mit den Rollen, die ich dem neu angelegten User gegeben hatte, mitkommen. Dummerweise hat mich Copilot darauf auch nicht hingewiesen – ok, hätte ich ihm vielleicht sagen müssen, dass ich Stored Procedures nutze und, dass ich einen neuen User angelegt habe und eben keine Berechtigungen verteilt hatte.

Was habe ich daraus gelernt?

1. Authentifizierung einer Web App für die Nutzung einer Azure SQL DB über Entra ist ziemlich einfach (das ging mit der Step by Step Anleitung überraschend schnell)
2. Copilot kann mir am besten helfen, wenn ich ihm/ihr/es so viel wie möglich Details gebe, auch wenn ich vielleicht der Meinung bin, dass diese gar nicht so wichtig sind
3. Stored Procedures brauchen für den User ein Execute Recht
4. Gutes Error Handling und Debugging der Exceptions helfen bei der schnelleren Lösung der Herausforderungen 😉
5. Meine Güte kann der Github Copilot gut programmieren! 🙀

Abschließend bleibt zu sagen: bevor ihr selber durch Schmerzen – aka erfolgreichen Cyberangriff- lernt, lernt doch lieber von anderen! Nutzt die Informationen, die jetzt schon durch Microsoft und die SFI verfügbar sind und auch weiterhin durch (un)regelmäßige Updates erweitert und vertieft werden.

Fangt selber an jeden eurer „Steine“ zu hinterfragen und überlegt, ob die aktuellen (Produktiv-) Systeme noch dem aktuell(st)en Stand der Technik entsprechen, oder ob nicht „Dinge, die wir schon immer so gemacht haben“ nicht ein Update brauchen!

¹ Wie immer gilt: ich schließe explizit niemanden aus und beziehe in jegliches Genus alle anderen mit ein – für die Inklusion und die Lesbarkeit verwende ich immer nur genau ein Genus in beliebiger Reihenfolge! 🔙