Über mich [1/2]

Ich mache beruflich Code Audits.

Firmen zeigen mir den Quellcode ihrer Produkte.
Ich zeige ihnen Bugs, die ich darin finde.

Über mich [2/2]

Ich mache auch Security Architecture.

Firmen zeigen mir den Aufbau ihrer Produkte / Netze.
Ich zeige ihnen, wie man das besser organisieren kann.

Über diesen Vortrag

• Was ist denn überhaupt Zero Trust?
• Es gibt die technische Begriffsdefinition
• Dann gibt es Dinge, die unter Zero Trust verkauft werden

Die haben leider nicht viel miteinander zu tun.

„Was verstehen Sie unter Zero Trust?“

• Kein Intranet mehr
• Identity Management in der Cloud
• Black Cloud
• Gibt da einen NIST-Standard zu
• Bei uns haben sie das ausgerollt und dann ging gar nichts mehr
• Jeder Scheiß braucht jetzt Zweifaktor

„Was verstehen Sie unter Zero Trust?“

Ein Consultant schrieb:

• Ich gehe erstmal zum Admin
• Hole mir eine Liste, was der braucht
• Damit gehe ich zur Geschäftsführung, sage das ist für Zero Trust
• Die gucken dann den Admin an, der nickt weise
• Am Ende sind alle glücklich

Dieser Vortrag

• Unklares Thema, viel Zeit
• Daher erkläre ich erstmal die Grundlagen
• Wie man Security-Maßnahmen auswählt und bewertet
• Was falsch läuft und was man besser machen könnte
• Was Zero Trust ist und wo es reinpasst

Es gibt im Leben drei wichtige Fragen

1. Wo sind wir?

2. Wie sind wir hier hingekommen?

3. Wie geht es jetzt weiter?

Wo sind wir?

Hier sind Ihre größten Bedrohungen:

• Ransomware.

  (lange nichts)

• Datenverlust durch Softwarefehler oder Hardwareausfall.
• Innentäter.

Wie funktioniert Ransomware? [1/2]

• Jemand schickt Ihnen eine E-Mail
• Sie klicken auf den Anhang

  (Das geht, weil Sie Outlook und Office benutzen)

• Der Anhang läuft mit Ihren Berechtigungen im System
• Installiert eine Hintertür

  (Das geht, weil Sie Windows benutzen)

Wie funktioniert Ransomware? [2/2]

• Danach kommt durch die Hintertür Besuch
• Beschafft sich lokale Admin-Rechte

  (Das geht, weil Sie Windows benutzen)

• Übernimmt von da aus den Domain Controller

  (Das geht, weil Sie Active Directory benutzen)

• Dann kopiert er alles, verschlüsselt Ihre Kopie und löscht die Backups.

Da sollten wir mal was tun!

Wie geht man an sowas heran?

Wie bewertet man Security?

1. Man erstellt ein Threat Model mit Datenflussdiagramm
2. Damit misst man die TCB
3. Dann sucht man Maßnahmen, die die TCB verkleinern
4. Und Maßnahmen, die Angriffe aus dem Threat Model verhindern

Was ist ein Threat Model?

• Liste der möglichen Angriffe
• Hauptsächlich die, vor denen man sich akut fürchtet
• Aber auch alle anderen!

Ziel der Übung: Sehen, wo man angreifbar ist.

Was ist ein Datenflussdiagramm?

• Bild der Infrastruktur, nach Datenflüssen und Berechtigung
• Komponenten mit äquivalenten Zugriffsrechten bilden Inseln

Ziel der Übung: Man sieht die Mitspieler, wer mit wem redet.
Kommunikation über Inselgrenzen ("Trust Boundary") sind riskant.
Wir nennen das: Attack Surface.

Was ist die TCB? [1/3]

TCB steht für Trusted Computing Base.

• TCB meint tragende Wände
• Wenn die einstürzen, kommt die ganze Decke runter!

Ziel: TCB minimieren.
Komponenten so „ohnmächtig“ wie möglich machen.

Was ist die TCB? [2/3]

In typischen Installationen: Alles.

• Datenbank
• Webserver
• Terminalserver
• Clients
• Backupsoftware etc pp.

Was ist die TCB? [3/3]

• Ziel: Komponenten aus der TCB holen
• Selbst wenn sie wollten, können sie nichts kaputtmachen
• Beispiel: cp-Befehl unter Unix. Kopiert Dateien. Prüft nichts.
• Der Kernel prüft! Der Kernel ist in der TCB. cp nicht.

Wie verkleinert man die TCB? [1/2]

• Man schiebt Zugriffsprüfungen „nach hinten“
• Die Komponenten vorne konvertieren nur die Anfragen
• Alle Dinge, die die tun können, sind auch ohne Hack erreichbar
• Umgekehrt: Die können sonst nichts!

Wie verkleinert man die TCB? [2/2]

• Auf dem Handy: App darf nur eigene Dateien öffnen
• Aber es gibt „send to app“ aus anderen Apps
• Man kann „Datei öffnen“ sagen
• Dann kommt vom Handy-Betriebssystem ein Öffnen-Dialog

Aber einfach so beliebige Dateien öffnen geht nicht.

Anderer Ansatz: Single-Use Tokens

• Statt Username+Passwort oder SSO-Token
• Das Token erlaubt genau die Operation, die man haben will
• Z.B. „Überweise 23€ an die GEZ, ID 12345, gez. Felix“

  (schlägt fehl, wenn die ID schonmal in Benutzung war)

• Wenn jemand das Token klaut, kann er nichts anstellen
• Google-Stichwort: Idempotenz

TCB-Minimieren ist schwierig!

Ist aber das einzige, was messbar hilft.

In der Praxis sind die meisten Maßnahmen unwirksam

Weil man nicht die TCB minimiert hat (häufig sogar im Gegenteil!)

Zurück zu den Ransomware-Problemen!

1. Der Angreifer kann Ihren Account übernehmen
2. Von Ihrem Account aus kann er Admin werden
3. Als Admin kann er alle Daten sehen und verschlüsseln
4. Als Admin kann er Domain Admin werden

Das ist (in 1. Näherung) unser Threat Model!

Wie sind wir hier hingekommen?

Erklärung 1: Smart Clients

Das ist ein Terminal, kein Computer

• Früher hatten Sachbearbeiter keinen Computer
• Der Computer war groß und laut und stand im Rechenzentrum
• Der Sachbearbeiter hatte ein Terminal

Das Terminal war dumm.

Aufgepasst!

• Hätte man so ein Terminal hacken können?
• Man hätte ein böses ROM installieren können!

   

• Aber dafür muss man es physisch aufschrauben (und evtl. löten)

Sicherheitsfeatures

• Kein Speicher
• Kein Betriebssystem
• Kein Admin-Zugang
• Keine Programme (keine Sicherheitslücken in ihnen)
• Kein Netzwerkzugang (nur Serialkabel)
• Host verlangt Login

Zum Vergleich: Heutige Clients

• RAM, Festplatte/SSD
• Betriebssystem (braucht ständig Patches)
• Admin kann Trojaner persistieren
• Programme nachinstallierbar (brauchen ständig Patches)
• Netzwerkzugang (Angreifer kann von dort aus andere angreifen)
• Host nimmt auch NTLM/Kerberos-Tokens

Wichtiger Punkt fürs Verständnis [1/2]

• Der Angreifer kann genau das, was Sie auch tun konnten
• Nur ist er im Allgemeinen besser informiert

Angreifer kann Admin werden? Dann konnte das auch der Mitarbeiter!

Wichtiger Punkt fürs Verständnis [2/2]

• Der Verteidiger muss alle Schwachstellen finden und schließen
• Der Angreifer muss nur eine finden und ausnutzen

Offensichtliche Lösung: Nur ganz wenige Schnittstellen anbieten.
So wenig wie möglich. Damit wir eine Chance haben, die abzusichern.

Windows hat fünfstellig APIs

• Niemand kennt die alle
• Microsoft kämpft damit, ihr eigenes Netz abzusichern

• Office fügt nochmal vierstellig dazu

Was haben wir angerichtet?!

• Wir haben ein saftiges Ziel geschaffen (den Windows-PC)
• Wir halten es schön verwundbar (Patch Management)
• Wir sorgen für Angriffsoberfläche (E-Mail, Web)
• Da liegen attraktive Daten
• Von dort aus kann man das ganze Netz übernehmen
• Dann kommt man an alles andere heran

Erklärung 2: Management

Management

• Techniker möchten Probleme lösen
• Manager möchten Probleme managen

   

• In IT-Abteilungen haben Manager das Sagen

   

• Also kriegen wir lauter Kram, der gemanaged werden muss

Management klingt gut für Manager!

• Identitäts-Management
• Schwachstellen-Management
• Software Lifecycle Management
• Rollout Management
• Change Management
• Patch Management

Management klingt gut für Manager!

• Customer Relationship Management
• Document Management
• Database Management
• Backup Management
• Information Leakage Management
• Security Management

Management klingt gut für Manager!

• Threat Management
• Quality Management
• Standards Management
• Sales Management
• Account Management
• Compliance Management

Management klingt gut für Manager!

• Power Management
• Storage Management
• Network Management
• Attack Surface Management (früher: Vulnerability Management)

(Die Liste ließe sich bestimmt fortsetzen)

Alle investieren in Management

Niemand investiert in Lösungen.

Alle investieren in Prozesse, niemand verbessert irgendwas.

ISO 27001 verlangt nur Prozesse, nicht dass sie funktionieren!

Erklärung 3: Lohnt sich einfach mehr

Lohnt sich einfach mehr

• Früher lohnten sich Cyberangriffe nicht so, weil alles Fax + Drucker war
• Softwarequalität war auch früher mies
• Aber jetzt digitalisieren wir!

Heute kann man mit der Schrotflinte irgendwo hin schießen und trifft was Lohnendes.

Stützargument

• Bei Kryptowährungen kann man direkt Millionen raustragen
• Die haben mehr Sicherheitsvorfälle als der Rest zusammen!

Wo geht es jetzt hin?

• Kommt auf das Weltbild an
• Gibt mehrere Ansätze

Zurück zum Threat Model

1. Der Angreifer kann Ihren Account übernehmen
2. Von Ihrem Account aus kann er Admin werden
3. Als Admin kann er alle Daten sehen und verschlüsseln
4. Als Admin kann er Netzwerk-Admin werden

Angreifer kann Account übernehmen

• Ab jetzt verwenden wir nur noch sichere Software!!
• Von Anfang an der Hauptansatz
• Bessere Tools, bessere Warnungen
• Statische Codeanalyse, Fuzzing, Code Audits
• „Sichere Programmiersprachen“

Ab jetzt sichere Software!

• Das machen wir jetzt seit 50 Jahren
• Hilft, aber reicht nicht!

Wir haben immer weniger Schwachstellen pro kg Code

Die Codegröße wächst schneller als die Fehlerrate sinkt

Wir müssen mehr tun!

• Wir brauchen zusätzliche Schadensbegrenzung

   

• Annahme: Was, wenn diese Software gehackt wird?
• Was kann der Angreifer von da aus machen?

Da kann man doch was machen?

• Schiffe haben Schotten gegen Wassereinbruch
• Gebäude haben Brandschutztüren gegen Feuer
• Elektrische Schaltungen haben Dioden und Sicherungen
• Krankenhäuser haben niedrigeren Luftdruck in Seuchenabteilungen
• Autos haben Knautschzonen und Airbags

Da kann man doch was machen?

Code kann man auch isolieren!

1. Virtuelle Maschine
2. Container
3. Emulator / Instrumentierung
4. Microservices

Container

• Im Moment packen wir die Anwendung in den Container
• Das schützt den Hypervisor / Host vor der Anwendung

   

• Die Daten, die wir retten wollten, sind in der Anwendung
• Völlig sinnloses, absurdes Theater
• Plus: Aus dem Container kann man häufig AD und SSO sehen / angreifen

Container

• Stattdessen sollten wir Anwender 1 von Anwender 2 isolieren
• Wenn der eine die App hackt, sieht er nicht das Passwort des anderen
• Sieht nur seine eigenen Daten und Credentials
• Kann nicht jemand anderes offene Datenbankverbindung mitnutzen

Ein Container pro Anfrage!

Kann man das nicht besser machen?

• Klar kann man!
• Aber ordentlich isolieren kostet Performance und RAM
• Man braucht mehr / teurere Hardware
• Mehr CAPEX, mehr OPEX
• Praxis: Microservices, aber nicht isoliert
• Praxis: Container, aber alle Anfragen im selben Container

Fazit

• Abwehr des initialen Angriffs scheitert an uns selbst.
• Wir wissen, was man tun müsste, aber tun es nicht.

Zurück zum Threat Model

1. Der Angreifer kann Ihren Account übernehmen
2. Von Ihrem Account aus kann er Admin werden
3. Als Admin kann er alle Daten sehen und verschlüsseln
4. Als Admin kann er Netzwerk-Admin werden

„Der kann Admin werden“

• Man könnte eine Smartphone-App bauen
• Die wird in den meisten Fällen sogar deutlich sicherer sein

Warum wäre eine App sicherer?

• Ausbrechen ist schwerer (aber nicht unmöglich!)
• Dem Smartphone traut erstmal niemand im Netz
• Vielleicht kommt es gar nicht erst ins Netz sondern ins Gäste-WLAN
• Das Smartphone ist nicht domain joined (AD-Angriff schwieriger)
• App kann nicht einfach Daten anderer Apps sehen
• Auf dem Phone liegen nicht so viele Geschäftsdokumente

Können wir uns bei Apps was abgucken? [1/2]

• Windows 10 hat den Store und UWP und AppContainer
• AppContainer isoliert ähnlich gut wie Smartphones
• Der PC ist immer noch domain joined
• Das Netzwerk ist nur „alles oder nichts“-einschränkbar
• Aber ansonsten ein riesiger Schritt vorwärts!

Können wir uns bei Apps was abgucken? [2/2]

• Microsoft hat das (mit Gewalt) in den Markt zu drücken versucht
• Der Markt wollte es nicht
• Ist jetzt vergiftet, wird gemieden

Schade eigentlich!

Fazit

• Abwehr der Privilegienausweitung scheitert an uns selbst.
• Wir wissen, was man tun müsste, aber tun es nicht.

Zurück zum Threat Model

1. Der Angreifer kann Ihren Account übernehmen
2. Von Ihrem Account aus kann er Admin werden
3. Als Admin kann er alle Daten sehen und verschlüsseln
4. Als Admin kann er Netzwerk-Admin werden

„Der kann alle Daten abgreifen!“

Die Daten liegen auf dem Rechner? Admin kann sie abgreifen.

Verschlüsseln hilft nicht. Admin kann Schlüssel sehen.

Passwort hilft nicht. Admin kann Tastatureingaben mitlesen.

Schutz vor dem lokalen Admin

Wenn die Daten „im SAP“ liegen, kann der lokale Admin „nur“ anstellen, was der angemeldete Nutzer darf.

Immer noch schlimm aber kein Totalschaden mehr.

Der SAP-Admin kann immer noch alles sehen und kaputtmachen.

Schutz vor dem lokalen Admin

Lösungsansatz:

• Datenhaltung remote
• Zugriff nur via API
• API kann nur lesen und macht append-only Datenhaltung

Auch der lokale Admin kann die Daten nicht verschlüsseln!

Traditionelle Datenablage

In der Datenbank steht: Name=Fred, Abteilung=Security

Fred wechselt die Abteilung: Name=Fred, Abteilung=Inkasso

Nachdem der Wert gewechselt ist, ist der vorige Wert futsch.

Man müsste ein Backup einspielen.

Append-only Datenablage

Nach Freds Abteilungswechsel:

Name=Fred, Abteilung=Security

Änderung 2022-06-15 UID 123: Name=Fred, Abteilung=Inkasso

Änderungen werden hinten angehängt.

Jemand hackt uns? Dann rollen wir das manuell zurück.

Fazit

• Abwehr des lokalen Admins scheitert an uns selbst.
• Wir wissen, was man tun müsste, aber tun es nicht.

Zurück zum Threat Model

1. Der Angreifer kann Ihren Account übernehmen
2. Von Ihrem Account aus kann er Admin werden
3. Als Admin kann er alle Daten sehen und verschlüsseln
4. Als Admin kann er Netzwerk-Admin werden

„Er kann Netzwerk-Admin werden“

• Das liegt vor allem an NTLM und Kerberos
• Google-Stichworte: mimikatz, golden ticket, rainbow tables

   

• Kerberos kommt aus einer anderen Zeit
• Gedacht gegen unprivilegierte User, nicht gegen lokale Admins

Kann man da nichts machen?

• Man kann ordentliche public-key Krypto machen
• Vielleicht mit MFA oben drüber

   

• Admin-Rolle aufteilen, jeweils Least Privilege

   

• Ganz wichtig: Netz-Admin hat keinen Zugriff auf Datenbanken!

Kann man da nichts machen?

• Kerberos/AD kann sogar seit Windows 2016 public key
• Aber nur für Rechner-Authentisierung, nicht Benutzer (AFAIK)
• Habe ich noch nie angeschaltet gesehen

https://docs.microsoft.com/en-us/windows-server/security/kerberos/domain-joined-device-public-key-authentication

Fazit

• Abwehr des Netz-Admins scheitert an uns selbst.
• Wir wissen, was man tun müsste, aber tun es nicht.

Was ist denn jetzt Zero Trust?

Warum wäre eine App sicherer?

• Ausbrechen ist schwerer (aber nicht unmöglich!)
• Dem Smartphone traut erstmal niemand im Netz
• Vielleicht kommt es gar nicht erst ins Netz sondern ins Gäste-WLAN
• Das Smartphone ist nicht domain joined (AD-Angriff schwieriger)
• App kann nicht einfach Daten anderer Apps sehen
• Auf dem Phone liegen nicht so viele Geschäftsdokumente

Das ist Zero Trust [1/4]

• Niemandem trauen, bloß weil er aus dem Intranet kommt
• Auch im Intranet ordentlich verschlüsseln
• Dienste und Nutzer ordentlich authentisieren (nicht Rechner!)

Das ist alles.

Behandelt alle Zugriffe, als kämen Sie aus dem Internet.

Das ist Zero Trust [2/4]

• Ursprünglich popularisiert 2009/2010 von Google
• Die nannten es „BeyondCorp“

Das ist Zero Trust [3/4]

• Heißt das, wir brauchen keine Firewalls mehr? Kein Intranet?
• Wir können alles in die Cloud schieben?

   

• NEIN!! Google hat noch ein Intranet!
• Google schiebt Daten nur in die Cloud, weil sie die Cloudbetreiber sind!

Das ist Zero Trust [4/4]

• Amazon schiebt Dinge in die Cloud.
• In ihre eigene Cloud!

   

• Microsoft schiebt Dinge in die Cloud.
• In ihre eigene Cloud!

Was ist mit Apple?

• Apple hat iCloud, aber schiebt da nur Daten ihrer Kunden hin!

   

• Weil iCloud bloß eine Marke ist.
• Die Server stehen bei Azure und AWS.
• Denen traut Apple nicht.

Aber aber aber …

„Aber die Hersteller wollen uns als Zero Trust alle Managed Cloud Services und Identity Management verkaufen!“

Das ist nicht Zero Trust.

Das ist das Gegenteil von Zero Trust.

Dann muss man dem Cloud-Dienst 100% vertrauen!

Wieso verkaufen die uns das dann?!

Management

• Techniker möchten Probleme lösen
• Manager möchten Probleme managen

   

• In IT-Abteilungen haben Manager das Sagen

   

• Also kriegen wir lauter Kram, der gemanaged werden muss

Jetzt haben wir das Rüstzeug, …

… mal ein paar Verkaufsangebote zu evaluieren!

1. Mikrosegmentierung [1/3]

• Minimiert das die TCB? Nein! Es vergrößert sie!
• Vorher dumme Switches, jetzt programmierbare Router.
• Denen müssen wir trauen, dass sie nicht umprogrammiert wurden.

  Die sind in der TCB.

Wie ist es mit dem Threat Model?

1. Mikrosegmentierung [2/3]

• Hilft es gegen die Infektion des Arbeitsplatzes durch E-Mail?
• Nein.
• Hilft es gegen Admin-Beschaffung auf dem Arbeitsplatz-PC?
• Nein.
• Hilft es gegen Angriffe auf den Domain Controller?
• Nein.

1. Mikrosegmentierung [3/3]

• Hat es Nachteile? Klar!
• Kostet CAPEX und OPEX und hat Opportunitätskosten!

2. Cloud-Passwortmanager [1/3]

• Minimiert das die TCB? Nein! Es vergrößert sie!
• Jetzt müssen wir auch noch der Cloud vertrauen.

Wie ist es mit dem Threat Model?

2. Cloud-Passwortmanager [2/3]

• Hilft es gegen die Infektion des Arbeitsplatzes durch E-Mail?
• Nein.
• Hilft es gegen Admin-Beschaffung auf dem Arbeitsplatz-PC?
• Nein.
• Hilft es gegen Angriffe auf den Domain Controller?
• Nein.

2. Cloud-Passwortmanager [3/3]

• Hat es Nachteile? Klar!
• Kostet CAPEX und OPEX und hat Opportunitätskosten!

(Das gilt natürlich auch für „Cloud Identity Provider“ u.ä.)

(Und für MFA in der Cloud)

3. Netzwerküberwachung [1/3]

• Minimiert das die TCB? Nein! Es vergrößert sie!
• Jetzt müssen wir auch noch den Agenten, Sensoren und der Auswertungssoftware vertrauen.

Wie ist es mit dem Threat Model?

3. Netzwerküberwachung [2/3]

• Hilft es gegen die Infektion des Arbeitsplatzes durch E-Mail?
• Nein.
• Hilft es gegen Admin-Beschaffung auf dem Arbeitsplatz-PC?
• Nein.
• Hilft es gegen Angriffe auf den Domain Controller?
• Nein.

3. Netzwerküberwachung [3/3]

• Hat es Nachteile? Klar!
• Kostet CAPEX und OPEX und hat Opportunitätskosten!

Die Netzwerküberwachung kommt überall hin.

Der Angreifer auch, wenn er sie hackt.

4. Software Defined Perimeter [1/3]

• Minimiert das die TCB? Nein! Es vergrößert sie!
• Wo man früher für einen Angriff physisch Kabel stecken musste, ist jetzt ein Software-Angriff denkbar.

Wie ist es mit dem Threat Model?

4. Software Defined Perimeter [2/3]

• Hilft es gegen die Infektion des Arbeitsplatzes durch E-Mail?
• Nein.
• Hilft es gegen Admin-Beschaffung auf dem Arbeitsplatz-PC?
• Nein.
• Hilft es gegen Angriffe auf den Domain Controller?
• Nein.

4. Software Defined Perimeter [3/3]

• Hat es Nachteile? Klar!
• Kostet CAPEX und OPEX und hat Opportunitätskosten!

Außer es hat kein Risiko, weil wir eh Zero Trust machen.

Dann hat es aber auch keinen Nutzen.

Fertig! Jetzt kommt die Kür!

Wie kommt die Ransomware rein? [1/2]

• Problem 1: Outlook hat „aktive Inhalte“.
• Problem 2: Outlook erlaubt Öffnen von Attachments.
• Problem 3: Office-Attachments haben „aktive Inhalte“.
• Problem 4: Mit gelbem Balken schaltet man Makros ein

Mit gelbem Balken schaltet man auch Ändern ein, das haben wir den Leuten jetzt antrainiert.

Wie kommt die Ransomware rein? [2/2]

Achten Sie mal darauf:

• Microsoft hat das Problem nicht gelöst
• Sie haben es so umformuliert, dass sie nicht schuld sind
• Stattdessen ist der Nutzer schuld

Narrativ jetzt: „Nutzer ist das schwächste Glied“

Wie wird die Ransomware Admin? [1/2]

• Entweder über eine bekannte Lücke, die Sie nicht gepatcht haben
• Oder über gammelige Software, die Sie installiert haben
• Häufig triviale Angriffsvektoren wie „DLL Hijacking“
• Je mehr Angriffsoberfläche, desto einfacher!

Ranzige Grafiktreiber.

Wie wird die Ransomware Admin? [2/2]

Können bei Ihnen die Mitarbeiter per UAC Admin werden?

(Lachen Sie nicht! Ist bei praktisch allen Entwicklungsabteilungen so!)

(Inklusive bei Microsoft!)

Verhindert das nicht der Antivirus?

Nein, in der Praxis nicht.

Der meldet ihnen 10000 gefährliche Cookies im Browser.

Und ein unsigniertes Programm, das Sie gerade kompiliert haben.

Hauptfunktion eines Antivirus: Sie zum Verlängern des Abos bringen.

Wie holen die sich Domain Admin?

• Windows hält Credentials im RAM
• Username, Passwörter, Kerberos-Tokens
• Local Admin darf die auslesen
• Entweder ein Admin-Account hat schon Credentials auf der Kiste
• Oder ich trete gegen eine Vase, dann kommt der Admin gucken

(Bei Pentests ruft man gerne den Helpdesk an)

Das ist ja furchtbar!

• Unter Unix macht man public key Auth mit openssh
• Da sind Host- und User-Key involviert
• Man-in-the-middle geht nicht (dann falscher Host-Key)

Microsoft hat hier seit Jahrzehnten den Schuss nicht gehört.

Und jetzt?

• Wir brauchen nicht inkrementelle Verbesserungen
• Wir brauchen fundamentale Verbesserungen

   

• Fundamentale Verbesserungen brauchen fundamentale Änderungen

   

• Das Investment will niemand machen

OK, so kann ich Sie nicht gehen lassen

Ein paar konkrete Visionen

Ein paar konkrete Visionen

Chromebooks gehen in die richtige Richtung.

• Read-Only-Image für Betriebssystem
• Daten liegen hinter APIs im Netz
• Für Updates bootet man in das neue Image
• Lokale Schreibzugriffe bietet man gar nicht erst an

Was bringt uns das?

Selbst nach erfolgreichem Hack geht Einnisten nicht!

Problem? Rechner booten! Alles wieder sauber.

Bootet nicht? Das alte Image liegt noch da!

(So machen das Chromebooks, Android und Apple-Geräte)

Ein paar konkrete Visionen

• Geschäftsanwendungen als Webseite im Intranet machen
• Mit https-Krypto und Logins
• (In die Richtung geht es eh schon flächendeckend)
• Browser auf Read-only-Image ist ein bisschen doof
• Muss man immer das ganze Image updaten
• Macht man dann halt!

Was bringt uns das?

Selbst nach erfolgreichem Hack helfen Admin-Privilegien nichts.

Kann nur Daten abgreifen, die der User im Zugriff hatte!

Alles schön Least Privilege machen!

Was bringt uns das?

• Account auf dem Client egal
• Alle Zugriffe gehen über Webserver+Login im Intranet
• Single-Sign-On geht über Browser-merkt-sich-Logins
• Achtung: Keine Cloud-Anbindung oder -Backups!
• Achtung: Ausschalten, nicht Schlafmodus!
• Laptop-Sharing ist risikolos. Einfach einmal durchbooten!

Updates

• Einfach jeden Morgen ein frisches Image booten!
• Nie wieder Ärger mit Patch-Management!

   

• Der Browser übergibt bei Zugriffen seine Version
• Da kann man auch die Image-Version reintun
• Dann können Webdienste zu alte Clients abweisen

Ist das realistisch?

Das muss jede Organisation für sich selbst entscheiden.

Meine Botschaft: Wir wissen, dass es geht, und wie es geht.

Es gibt eigentlich schon länger keine Ausreden mehr.

Was ist auf Serverseite?

Da gibt es auch einen Haufen Dinge zu beachten.

Ist ein eigener Vortrag. Der sieht aber ähnlich aus.

Wir wissen, dass es geht, und wie es geht. Aber keiner tut es.

Google-Stichwörter:

Least Privilege, TCB-Minimierung, Self Sandboxing, Privilege Separation.

Vielen Dank für die Aufmerksamkeit!

Fragen?

Wenn Sie mal IT-Security-Hilfe brauchen:

https://www.codeblau.de/