Sechs dumme Ideen in der Computersicherheit (2005)

• Computersicherheit ist ein Bereich, in dem Produkte, Konferenzen, Bücher und Gesetzesvorlagen ständig zunehmen, doch an der Wurzel der wiederkehrenden Fehlschläge stehen falsche Grundannahmen wie Default Permit und Enumerating Badness
• Das Kernproblem ist eine Struktur, die nicht eng definiert, „was erlaubt sein soll“, sondern endlos dem hinterherjagt, „was blockiert werden soll“; wenn man bei Firewalls, Code-Ausführung und der Reaktion auf Würmer nicht Default Deny wählt, gerät man in ein Wettrüsten mit Angreifern
• Das Auflisten schlechter Dinge bedeutet, mehr als 75.000 Viren und monatlich 200 bis 700 neue Bedrohungen zu verfolgen, und ist damit ineffizienter als Enumerating Goodness, also die Verwaltung der rund 30 tatsächlich benötigten legitimen Anwendungen
• Strategien, die auf dem Finden und Patchen von Schwachstellen, einer Kultur, die Hacking als cool konsumiert, oder auf Nutzerschulungen beruhen, führen alle eher zu wiederholter nachträglicher Reaktion, statt Designfehler zu reduzieren
• Bei neuen Technologien kann es sicherer sein, erst abzuwarten und sie zu prüfen, statt sie sofort einzuführen; Sicherheitspraktiker sollten vernünftiges Design und eine skeptische Haltung über Trends stellen

---

„Anti-gute Ideen“, die zu Sicherheitsversagen führen

• In der Computersicherheit tauchen ständig neue Produkte, neue Konferenzen, neue Bücher und neue Gesetzesvorlagen auf, doch die Probleme wiederholen sich
• Eine „dumme Idee“ ist ein Ansatz, der auf der Gegenseite einer guten Idee steht und entsteht, wenn man Unmögliches versucht oder die Realität ignoriert
• Solche Ansätze können aus gut gemeinten Missverständnissen entstehen oder aus gut verpackten Produkten, mit denen schnell Geld verdient werden soll
• Die sechs Ideen sind in der Reihenfolge angeordnet, in der sie häufig zu beobachten sind; wer insbesondere die ersten drei vermeiden kann, gehört vermutlich zu einer kleinen Gruppe hervorragender Sicherheitspraktiker

1. Default Permit: standardmäßig erlauben

• Default Permit ist ein Modell, bei dem alles erlaubt wird, was nicht ausdrücklich verboten ist; am leichtesten erkennt man es bei Firewall-Regeln
  • Frühe Netzwerkadministratoren blockierten eingehendes telnet, rlogin und FTP und erlaubten den Rest
  • Jedes Mal, wenn eine neue Schwachstelle entdeckt wurde, musste der Administrator entscheiden, ob sie blockiert werden sollte, und musste schneller sein, bevor er gehackt wurde
  • Mit dem Auftreten der Würmer in den 1990er-Jahren hätte dieses Modell verschwinden müssen, doch viele Netzwerke haben noch immer eine offene Kernstruktur ohne Segmentierung
• Bei der Code-Ausführung wiederholt sich dasselbe Problem
  • Wenn ein Nutzer klickt, wird standardmäßig alles ausgeführt; die Ausführung wird nur verweigert, wenn Antivirus- oder Spyware-Blocker es verhindern
  • Tatsächlich häufig genutzte Anwendungen sind etwa 15, gelegentlich genutzte etwa 20 bis 30, dennoch erlauben Betriebssysteme standardmäßig die Ausführung von Viren oder Spyware
• Ein E-Banking-Sicherheitsprojekt nutzte den gegenteiligen Ansatz
  • Statt dass der Load Balancer nur bekannte Angriffe in ein Blackhole leitete, schickte er jeden Traffic, der nicht mit der Liste gültiger URLs übereinstimmte, an einen gesperrten Server, der Bilder und 404-Seiten auslieferte
  • Es ging also nicht um Default Permit, bei dem nur bekannte Angriffe blockiert werden, sondern darum, Anfragen abzulehnen, die von der legitimen Struktur abweichen
• Wenn man sich in einem Wettrüsten mit Angreifern befindet, ist das ein Zeichen dafür, dass man in Default Permit steckt
• Das Gegenkonzept Default Deny erfordert Hingabe, Nachdenken und Verständnis bei der Umsetzung, ist aber der bessere Ansatz

2. Enumerating Badness: schlechte Dinge auflisten

• Enumerating Badness ist der Ansatz, alle bekannten schlechten Dinge aufzulisten und sie dann zu erkennen oder zu blockieren
• Anfangs schien das möglich, weil es nur wenige bekannte Sicherheitslücken gab, doch etwa ab 1992 gab es im Internet weit mehr „schlechte Dinge“ als „gute Dinge“
  • Ein typisches Antivirus-Produkt kennt mehr als 75.000 Viren
  • Auf einem einzelnen Personal Computer geht man von etwa 30 legitimen Anwendungen aus
  • Wenn man diese 30 legitimen Anwendungen verfolgt und alles andere nicht ausführen lässt, kann man zugleich Probleme mit Spyware, Viren, Remote-Control-Trojanern und selten genutzten, vorinstallierten Code-Execution-Exploits verringern
• Einigen Branchenanalysen zufolge erscheinen jeden Monat 200 bis 700 neue „schlechte Dinge“ im Internet
• Auf den Einwand, Unternehmensnetzwerke seien komplex und legitime Anwendungen daher schwer zu erfassen, wird entgegnet: Wenn ein CTO nicht einmal grob weiß, was die Technologie tut, kann er keine Kapazitäts-, Desaster- oder Sicherheitsplanung betreiben
• Die Log-Analyse eines Firewall-Produkts von 1994 suchte anfangs nach schlechten Bedingungen; die zweite Version nutzte jedoch Artificial Ignorance
  • Logs, von denen man wusste, dass sie uninteressant waren, wurden verworfen
  • Die verbleibenden Logs wurden als interessant betrachtet
  • Dieser Ansatz erkannte Betriebsbedingungen und Fehler, auf die man sonst nicht gekommen wäre
• Antivirus, Intrusion Detection, Intrusion Prevention, Anwendungssicherheit und Deep-Packet-Inspection-Firewalls stützen sich häufig auf diesen Ansatz
• Ein System, das regelmäßige Signatur-Updates benötigt oder einen erstmals auftretenden Wurm passieren lässt, zeigt Anzeichen von Enumerating Badness
• Das Heilmittel ist Enumerating Goodness, doch Betriebssysteme bieten kaum Unterstützung für eine solche Kontrolle auf Softwareebene

3. Penetrate and Patch: eindringen und patchen

• Penetrate and Patch ist ein Zyklus, bei dem Firewalls, Software, Websites usw. von außen angegriffen werden, um Fehler zu finden, diese Fehler zu beheben und dann erneut zu suchen
• Dieser Ansatz schafft kein von Grund auf besseres System, sondern nur ein System, das durch Versuch und Irrtum gehärtet wurde
• Richard Feynmans Personal Observations on the Reliability of the Space Shuttle ist eine lesenswerte Quelle dazu, wie Zuverlässigkeit in komplexen Systemen erreicht werden sollte
  • Die Kernbotschaft liegt eher bei: „Wenn ein System nicht dafür entworfen wurde, hackbar zu sein, sollte es auch nicht hackbar sein“
• Auch der Trend zu Schwachstellenveröffentlichungen und Patch-Updates beruht auf diesem Ansatz
  • Schwachstellenforscher sehen sich als hilfreich für die Community, weil sie Löcher vor Hackern finden und deren Behebung ermöglichen
  • Anbieter sehen sich im Recht, weil sie Patches veröffentlichen, bevor Hacker und Wurm-Autoren die Lücken ausnutzen
  • Wäre Code jedoch von Anfang an sicher und zuverlässig entworfen, wäre das Finden von Schwachstellen langweilig und wenig lohnend
• Wenn in Internet Explorer zehn Jahre lang jeden Monat zwei bis drei Sicherheitsbugs auftauchten, ist schwer zu behaupten, Penetrate and Patch sei wirksam gewesen
• Einige Anwendungen wie PostFix und Qmail gelten als so entworfen, dass Berechtigungen und Verarbeitung modularisiert und abgeschottet sind, weshalb ihre Historie an Sicherheitsbugs sehr gering ist
• Penetrationstests haben dieselben Grenzen
  • Netzwerke mit falschem Grunddesign oder schlechten Sicherheitspraktiken werden auch nach mehreren Penetrationstests weiter gehackt
  • Bei Netzwerken, die von Anfang an so entworfen wurden, dass nur bestimmte Richtungen, bestimmter Traffic und sorgfältig konfigurierte Server passieren dürfen, kann ein gewöhnlicher Penetrationstest sinnlos sein
• Wenn man jedes Mal für den „Bug der Woche“ anfällig ist, steckt man in Penetrate and Patch fest
• Software und Systeme sollten secure by design sein und mit Blick auf den Umgang mit Fehlern entworfen werden

4. Hacking is Cool: die Vorstellung, Hacking sei cool

• Hacking is Cool ist eine Kritik an einer Kultur, die Hacker mit Aktienoptionen, Büchern, Kursen und hochpreisigen Penetrationstests belohnt oder glorifiziert
• Donn Parker sah im Remote Computing den Wegfall der physischen Nähe als Voraussetzung für Kriminalität; Anonymität und das Fehlen der direkten Konfrontation mit dem Opfer senkten die emotionale Hemmschwelle für Straftaten
• Hacking ist weniger ein technisches als ein soziales Problem
  • Das Internet bietet Menschen mit schwacher sozialer Einbindung einen neuen Handlungsraum
  • Wenn Sicherheitspraktiker Hacker zu Helden machen, fördern sie Hacking implizit
  • Medien stellen Hacker mitunter als „whiz kids“ oder „brilliant technologists“ dar
• Auch dass Sicherheitspraktiker Hacking-Techniken lernen, wird als Teil dieser Idee betrachtet
  • Exploits und ihre Nutzung veralten schnell, sobald die jeweilige Lücke gepatcht ist
  • Die eigene Fachkompetenz hängt dann vom Wettrüsten des Penetrate-and-Patch-Ansatzes ab
  • Es ist sinnvoller zu lernen, wie man hackresistente Sicherheitssysteme entwirft, als wie man hackbare Systeme findet
• Es wird vorhergesagt, dass „Hacking is Cool“ innerhalb von zehn Jahren verschwinden wird; es gebe jedoch keine Anzeichen, dass das Gegenteil, „Good Engineering is Cool“, an seine Stelle tritt

5. Educating Users: Nutzerschulung

• Educating Users ähnelt Penetrate and Patch, angewandt auf Menschen
• Schulung an sich wirkt gut, doch wenn sie wirksam wäre, hätte man ihre Wirkung bereits sehen müssen
  • Mehrere Studien hätten gezeigt, dass ein erheblicher Anteil der Nutzer sein Passwort für ein Bonbon herausgibt
  • Der Anna-Kournikova-Wurm wird als Beispiel dafür angeführt, dass fast die Hälfte der Menschheit auf alles klickt, was so aussieht, als enthalte es Nacktfotos einer halbwegs berühmten Frau
  • Wenn Nutzerschulung die Strategie ist, muss man Nutzer womöglich jede Woche „patchen“
• Die eigentliche Frage lautet nicht: „Kann man Nutzer sicherer schulen?“, sondern: „Warum müssen Nutzer überhaupt geschult werden?“
  • Warum erhalten Nutzer ausführbare Anhänge?
  • Warum erwarten Nutzer E-Mails von einer Bank, bei der sie gar kein Konto haben?
• Auch der Umgang mit Anhängen und Phishing ist ein Default-Permit-Problem
  • Wenn allen Nutzern erlaubt wird, E-Mail-Anhänge zu erhalten, erlaubt man standardmäßig alles, was gesendet wird
  • Ein besserer Ansatz wäre, alle Anhänge zu isolieren, ausführbare Dateien zu löschen und nur erlaubte Dateitypen auf einem Staging-Server aufzubewahren
  • Nutzer könnten sich mit einem SSL-fähigen Browser einloggen und die Dateien abholen; die Passwortanforderung schwächt viele Verbreitungsmechanismen von Würmern sofort
• Kostenlose Tools wie MIMEDefang können genutzt werden, um Anhänge aus eingehenden E-Mails zu entfernen, sie in nutzerspezifischen Verzeichnissen zu speichern und den Anhang in der Mail durch die entsprechende URL zu ersetzen
• Beim Betrieb eines kleinen Sicherheits-Startups mussten Mitarbeiter, die Windows nutzen wollten, es selbst installieren und verwalten können; andernfalls wurden sie nicht eingestellt
• Es wird vorhergesagt, dass Nutzer, die Schulung benötigen, innerhalb von zehn Jahren aus dem Hightech-Arbeitsmarkt ausscheiden oder sich zu Hause selbst weiterbilden werden, um wettbewerbsfähig zu bleiben

6. Action is Better Than Inaction: der Glaube, Handeln sei besser als Nichthandeln

• IT-Führungskräfte lassen sich in „early adopters“ und „pause and thinkers“ einteilen; diejenigen, die erfolgreiche und sichere missionskritische Systeme gebaut haben, gehörten eher zur zweiten Gruppe
• Wenn eine neue Technologie erscheint, kann es sicherer sein, nicht sofort zu installieren, sondern abzuwarten, die Ergebnisse anderer früher Anwender zu beobachten und erst nach dem Entstehen von Erfahrung auszurollen
  • Ein hochrangiger IT-Manager formulierte seinen Plan zur Einführung eines drahtlosen Unternehmensnetzwerks so: „Zwei Jahre warten und dann jemanden einstellen, der bei einem größeren Unternehmen als unserem erfolgreich Wireless ausgerollt hat“
  • In der Zwischenzeit wird die Technologie ausgereifter und die Preise sinken deutlich
• Die zentrale Nebenannahme lautet: „Oft ist es leichter, keine dummen Dinge zu tun, als kluge Dinge zu tun“
• Auch beim Security-Outsourcing folgt der Rat, ein bis zwei Jahre zu warten und die Empfehlungen und Meinungen der Organisationen einzuholen, die überlebt haben
• In einem Kundenfall, in dem ohne Prüfung viel Geld ausgegeben werden sollte, wurde vorgeschlagen, Mitarbeitende zur einschlägigen Konferenz LISA zu schicken, um Personen mit praktischer Erfahrung zu finden
  • Diese Mitarbeitenden konnten Produkterfahrene zum Abendessen einladen und informelle Einschätzungen hören
  • Ein IT-Manager berichtete, dass ein Abendessen für 200 Dollar mehr als 400.000 Dollar an technischem Schmerz erspart habe
• Professionelles „Kung-Fu“ besteht darin, durch Nichtstun dumme Dinge zu vermeiden und vom Vorgesetzten Anerkennung für diese Vermeidung zu bekommen

Weitere kleine Dummheiten

• „Wir sind kein Ziel“
  • Würmer sind nicht klug genug, um zu beurteilen, ob eine Website oder ein Heimnetzwerk interessant ist
• „Wenn alle ein bestimmtes angesagtes Sicherheits-OS nutzen, sind wir sicher“
  • Betriebssysteme sind komplex, deshalb haben sie Sicherheitsprobleme, und Systemadministration ist noch kein gelöstes Problem
  • Wechselt man einem Trend folgend, kann es schwieriger werden, die Expertise aufzubauen, die Administratoren über Zeit gewinnen
• „Wir haben gute Host-Sicherheit, also brauchen wir keine Firewall“
  • Wenn man dem Netzwerk-Fabric nicht vertrauen kann, ist jede Anwendung, die das Netzwerk durchquert, ein potenzielles Ziel
  • Als Beispiel wird das Domain Naming System genannt
• „Wir haben eine gute Firewall, also brauchen wir keine Host-Sicherheit“
  • Wenn die Firewall Traffic zu den dahinterliegenden Hosts durchlässt, muss auch die Host-Sicherheit dieser Systeme berücksichtigt werden
• „Lass es uns jetzt in Produktion bringen und Security später machen“
  • Wenn man jetzt keine Zeit hat, es richtig zu machen, sollte man fragen, ob man nach dem Bruch Zeit hat, es noch einmal zu machen
  • Es kann passieren, dass man die ersten paar Tage nicht investiert und dann jahrelang weiter repariert
• „Gelegentliche Probleme lassen sich nicht verhindern“
  • Darauf folgt die Gegenfrage, ob man ein Verkehrsflugzeug besteigen würde, wenn die Luftfahrtindustrie bei Menschenleben so vorginge

Die Haltung, die Sicherheitspraktiker brauchen

• Computersicherheit habe sich zu sehr in „die neue Technologie dieser Woche“ verliebt und dabei den gesunden Menschenverstand aufgegeben
• Aufgabe von Sicherheitspraktikern ist es, Konventionen und den Status quo zu hinterfragen und sie, wenn nötig, frontal herauszufordern
• Der Text endet mit dem Problembewusstsein: Wenn die gängigen Annahmen wirksam wären, müsste die Rate kompromittierter Systeme sinken

[GN⁺]

Hacker-News-Kommentare

• Schon wieder dieses Thema: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
  An diesem Text gibt es viel auseinanderzunehmen, aber was ich immer ansprechen möchte, ist Ranums Haltung zu Schwachstellenforschung, gegen die er war. Ende der 90er bis Anfang der 2000er waren Marcus Ranum und Bruce Schneier prominente Stimmen der Ansicht, dass die Offenlegung von Schwachstellen mehr schade als nütze und dass nicht externe Forscher, sondern die Hersteller diese Arbeit machen sollten. Diese Sichtweise hat sich letztlich als falsch erwiesen; 2002 konnte man externe, vollständige Offenlegung in der Schwachstellenforschung noch unter „Hacking“ fassen, heute aber ganz und gar nicht mehr. Nicht nur die vier großen Konferenzen im Sicherheitsbereich, sondern sogar die kryptografische Literatur behandeln Angriffsforschung.

  • Damals könnten sie recht gehabt haben. Wenn man Entscheidungen aus der Vergangenheit nachträglich rationalisieren will, muss man sie anhand der damaligen Evidenz beurteilen. Seitdem sind die Größe der Netzwerke und die Zahl der Beteiligten explosionsartig gewachsen.
  • Ich frage mich, welche „vier großen Konferenzen“ im Sicherheitsbereich gemeint sind.
  • Es stimmt, dass Angriffsforschung auf den wichtigsten Konferenzen zu einem Kernthema geworden ist. In der Folge sehen wir nach der Veröffentlichung weiterhin negative Externalitäten in Form realer Ausnutzung, und oft fehlt Herstellern die Kompetenz oder der Wille, angemessen auf Veröffentlichungen aus der Wissenschaft zu reagieren. Auch die Wissenschaft kann sich verbessern; statt dass die Richtung wieder zurückgedreht wird, ist es wahrscheinlicher, dass die großen Konferenzen konkretere Erwartungen setzen, um Schäden durch Offenlegung zu reduzieren. Zum Beispiel, indem der Begriff „Hersteller“ auf Akteure ausgeweitet wird, die mitigieren können, etwa Betriebssystem- oder Firewall-Anbieter.

• Vielleicht habe ich es übersehen, aber ich war überrascht, dass Passwörter nicht erwähnt werden. Erzwingene Zusammensetzungsregeln außer einer Mindestlänge, regelmäßige Änderungen und Versuche, „Passwörter zu ersetzen“, halte ich im Kern für dumm. Zusammensetzungsregeln führen dazu, dass Passwörter auf Papier notiert, wiederverwendet oder am Ende mit einer 1 versehen werden; Ersatzverfahren haben eine furchtbare oder verwirrende UX und fallen am Ende wieder auf Passwörter zurück. Lasst mich einfach mit Zeichen meiner Wahl ein Passwort ab X Zeichen Länge erstellen, dann kann ich es mir tatsächlich merken, auch wenn ich kein Handy oder keinen Computer dabeihabe oder im Ausland bin.

  • Regelmäßige Passwortänderungen könnten damals eine gute Idee gewesen sein. Vor Jahrzehnten waren Sicherheitspraktiken sehr schlecht, etwa das Versenden von Passwörtern im Klartext, und es dauerte lange, bis das behoben wurde. Außerdem gibt es Leute, die Passwörter wie Bonbons weitergeben; ich meine damit nicht das Teilen von Streaming-Konten, sondern das Teilen von Zugriffsrechten auf wichtige Ressourcen innerhalb einer Organisation mit Kollegen. Deshalb stimme ich nicht zu, Endnutzer-Schulungen zu ignorieren. Manches lässt sich technisch lösen, aber soziale Probleme wie das Teilen von Passwörtern lassen sich allein mit Technik nicht gut lösen.
  • Wer erzwungene Passwortänderungen jeden Monat oder alle zwei Monate empfiehlt, hält oft nicht einmal mit den aktuellen Sicherheitspraktiken der Regulierungsbehörden Schritt. Sowohl das US-amerikanische NIST (https://pages.nist.gov/800-63-FAQ/) als auch das britische NCSC (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) geben ziemlich vernünftige Leitlinien heraus, die eine solche Anforderung nicht enthalten.
  • Ich sage das seit Jahren. Passwortgeneratoren erzeugen faktisch Schlüssel, die man sich nicht merken kann; daraus sind Passwortmanager entstanden, und all das wird durch ein einziges Passwort geschützt. Jetzt ist der Single Point of Failure ein einziges Passwort, und wenn ein Angreifer es bekommt, hat er Zugriff auf alle Passwörter. Da Sperrregeln nach n Versuchen in den meisten Fällen ohnehin den Weg für Brute-Force-Angriffe abschneiden, sind sie viel wirksamer. Ich bin kein Sicherheitsexperte, daher mag es Fälle geben, in denen komplexe und lange Passwörter einen Unterschied machen, aber mit Multi-Faktor-Authentifizierung wird der Großteil dieser Diskussion hinfällig.
  • Ich wollte Passwörter auch erwähnen, aber inzwischen scheinen Passkeys ein noch besserer Kandidat für eine dumme Idee zu sein. Für durchschnittliche Nutzer dürften sie endlose Verwirrung stiften.
  • Passwortregeln sind ein Witz. Wenn man fünf Websites nutzt, hat man fünf verschiedene Regeln. Manche, etwa Banken, blockieren Sonderzeichen als „Hacking-Versuch“, sodass nicht einmal der Firefox-Passwortgenerator funktioniert, und Nutzer umgehen das dann, indem sie etwas wie suckmyDICK123!! eingeben. Trotzdem werden Konten meist nicht leicht geknackt, weil der Durchsatz für Brute Force zu gering ist oder das Konto nach fünf Fehlversuchen gesperrt wird. Heute wissen die meisten zumindest, dass „Bots Passwörter mit übermenschlicher Geschwindigkeit ausprobieren“, und keine Passwortregel verhindert die Wahl schlechter Passwörter. Das ist ein Fall, in dem „verantwortungsbewusste“ Leute enorm viel Zeit verschwenden, um die Realität zu lösen. Abgesehen von ein oder zwei sensiblen Dingen wie Banken will man für Dienste, die einem erzwungene Konten abverlangen — etwa 80 Spiele, die man eine Minute ausprobiert hat — einfach dasselbe Passwort verwenden. Oft ist es eine separate GUI, in die man nicht einmal einfügen kann; man könnte zwar einen Passwortmanager benutzen, aber es gibt keinen echten Grund, das zu tun.

• Hacking kann cool sein. Nicht, wenn man auf die Daten und Systeme anderer zugreift, aber es ist cool, ein System, das mir gehört, so tief zu verstehen, dass ich Wege finde, es zu meinem Vorteil fehlfunktionieren zu lassen. Das Schloss des Nachbarn zu knacken ist nicht besonders toll, aber mein eigenes Schloss zu knacken ist cool; einen entfernten Computer zu manipulieren, um unberechtigten Zugriff zu erhalten, ist nicht besonders toll, aber meinen eigenen Computer dazu zu bringen, Dinge zu tun, die er eigentlich nicht tun sollte, ist cool. Die Haltung, die Ränder des Möglichen zu erkunden, bewegt die Welt voran, und es dürfte kaum eine erfolgreiche menschliche Gesellschaft gegeben haben, die das Verharren innerhalb des Rahmens gepriesen hat.

  • Man kann sagen, dass Kriminalität nicht cool ist, aber es hat eindeutig seinen Reiz, subversive Dinge zu kennen: Schlösser knacken, ein Auto kurzschließen, Waffen bauen, John the Ripper ausführen. Es hat den Effekt, eine Art Zauberer zu sein, der nicht an die Regeln gebunden ist, an die alle glauben.
  • Wenn ein entfernter Computer von einer Voice-Phishing-Organisation genutzt wurde, um personenbezogene Daten zahlreicher älterer Opfer zu speichern, kann auch unbefugter Zugriff cool sein. Wenn dieser Zugriff das Betrugsgeschäft stört, kann das sehr cool und auch lustig sein. Technisch wäre es illegal und eine Form von Selbstjustiz, aber hier geht es nicht um Legalität, sondern darum, ob etwas „cool“ ist. Selbstjustiz wirkt meist cool, wenn sie aus einem persönlichen Gerechtigkeitsempfinden heraus geschieht.

• In diesem Text steckt sehr viel schlechtes Urteilsvermögen. Ein Satz wie „Ich habe mein System sorgfältig entworfen, implementiert und konfiguriert, also muss ich es nicht testen“ ist womöglich die schlechteste Sicherheitsauffassung, die ich je gehört habe. Auch die Aussage „Hacking ist ein gesellschaftliches Problem, kein technisches“ kommt Security through Obscurity nahe und ist außerdem nicht immer ein gesellschaftliches Problem. Bei Wirtschaftsspionage oder staatlichen Akteuren sieht man, dass das nicht stimmt.

• Das Kernproblem ist meist der unglückliche Kompromiss Benutzbarkeit vs. Sicherheit, und die meisten der hier als dumme Ideen genannten Dinge sind das Ergebnis davon, dass man die Unannehmlichkeiten für durchschnittliche Nutzer verringern wollte und dafür Sicherheit geopfert hat. Zum Beispiel ist „standardmäßig erlauben“ für Sicherheit das Schlimmste und eine Ursache vieler Windows-Probleme, aber Nutzer mögen es nicht, jedes neue Programm explizit erlauben zu müssen. Auch als Microsoft Bestätigungsdialoge hinzufügte, hielten viele das für schlechtes Design, das die Software deutlich nerviger machte. Deshalb wurden „standardmäßig erlauben“, „Schlechtes aufzählen“ und „nach dem Eindringen patchen“ zu Defaults. Persönlich halte ich Passwörter selbst für eine der dümmsten Ideen in der Sicherheit. Denn die Definition eines guten Passworts ist praktisch, dass es schwer zu merken ist, auf Geräten ohne richtige Tastatur schwer einzugeben ist und für Nutzer in fast jeder Hinsicht unbequem ist. Aber es gibt auch keine realistische Alternative. E-Mail-Links sind komplett kompromittiert, wenn der E-Mail-Zugang kompromittiert ist, und beim Zurücksetzen von Passwörtern ist es meist genauso. Physische Authentifizierungsgeräte bedeuten, dass Nutzer sich außerhalb ihres Zuhauses nicht einloggen können oder ständig ein Zubehörteil mit sich herumtragen müssen, und fast jede Methode verlangt gute Sicherheitsgewohnheiten, für die sich 99,9 % der Bevölkerung kaum interessieren

  • Aus dieser Einsicht sind Passkeys entstanden, die mit Single Sign-on und Zwei-Faktor-Authentifizierung die Bausteine fürs Einloggen mitbringen. Apple hat cloud-synchronisierte Passkeys vollständig integriert; auf Apple-Geräten funktionieren sie auf dem Gerät selbst, und wenn man ein Apple-Gerät besitzt, nur mit Zwei-Faktor-Authentifizierung. Chrome kann ebenfalls als Passkey dienen, und Bitwarden auch. Sie lassen sich nicht austricksen, nicht umgehen, man kann den Anbieter wählen, und eine Website kann den Namen des registrierten Anbieters anzeigen, also muss man sich nichts merken
  • Ich empfehle, einen seriösen browserbasierten Passwortmanager mit einem starken Passwort zu schützen und ihn starke Passwörter generieren zu lassen, die man sich nicht merken muss. Websites, die das per JavaScript in Passwort-Eingabefeldern verhindern, sollten schadensersatzpflichtig sein und mit verschärften Strafen belegt werden. Insbesondere Banken
  • Passwörter waren lange Zeit eine gute Idee. In den ersten zehn, vielleicht sogar zwanzig Jahren gab es keine Geräte ohne richtige Tastatur. Das größere Problem war die Vorstellung, Passwörter müssten kompliziert und lang sein, also zufällige alphanumerische Zeichen und Sonderzeichen mischen und mindestens 12 Zeichen haben; ein paar Wörter wären besser gewesen. Man unterschätzt oft, wie sehr sich die technische Umgebung seit der Einführung von Smartphones verändert hat, aber in der Computer- und Laptop-Umgebung davor waren Passwörter eine gute Wahl

• Die Aussage „Mehrere Exploits und ihre Anwendung zu lernen bedeutet, Zeit darauf zu verwenden, Werkzeuge und Techniken zu lernen, die veralten, sobald sie gepatcht werden“ ist falsch. Tatsächlich lernt man praktische Aspekte zusammen mit der Theorie, und das ist sehr nützlich

  • Auch diesen Punkt halte ich für problematisch. Man kann kein Schriftsteller werden, ohne lesen zu lernen. Dass man ein Buch veröffentlicht hat, verringert nicht den Nutzen des Lesens. Man muss lernen, wie bekannte Exploits funktionieren, um auch unbekannte Exploits finden zu können. Selbst wenn eine bekannte Schwachstelle gepatcht wird, verliert das Wissen darüber, wie sie entstanden ist, nicht an Wert. Man kann sie vielleicht nicht mehr verwenden, aber ihre Verwendung war wohl ohnehin nicht der Zweck des Lernens
  • Nicht unbedingt. Es gibt viele Script Kiddies, die mit LOIC eine Website lahmlegen können, ohne auch nur zu wissen, was TCP ist oder wie ein HTTP-Request aussieht

• Aus dieser Liste würde ich „Hacking ist cool“ streichen und Vertrauen in den Client aufnehmen. In letzter Zeit gibt es mehr Versuche, dem Client zu vertrauen. Beispiele sind mobile Apps, die einen Nachweis verlangen, dass das Betriebssystem nicht modifiziert wurde, oder Googles Versuch, ein ähnliches DRM ins Web einzubauen. Wenn ein Netzwerksicherheitsmodell darauf beruht, der Client-Software zu vertrauen, ist es bereits kaputt

  • Das ist kein Sicherheitsproblem, sondern eine Frage der Kontrolle. Modifizierte Systeme können für ruchlose Zwecke wie Adblocking verwendet werden, und das dürfte Google nicht gefallen

• Zu „standardmäßig blockieren“ heißt es, es sei „nicht viel schwieriger als standardmäßig erlauben und man kann nachts besser schlafen“. Der IT-Sicherheitsbeauftragte schläft dadurch vielleicht besser, aber der Rest des Unternehmens ist extrem genervt, weil nichts funktioniert, ohne dreimal mit der IT-Abteilung hin und her zu gehen. Und je genervter Menschen sind, desto eher nutzen sie Workarounds, die das Sicherheitskonzept untergraben. Wenn man monatliche Passwortwechsel erzwingt, verwenden sie eben Dinge wie password1, password2, password3. Gute IT-Sicherheit bedeutet nicht einfach, das Netzwerkkabel zu ziehen; sie sollte für Nutzer magisch unsichtbar und unaufdringlich sein

  • Eine sehr wichtige Vendor-App in der Abteilung eines Freundes funktionierte irgendwann nicht mehr, also eröffnete er ein Ticket bei der IT. Es war so kompliziert, dass er am Ende die Erlaubnis bekam, Microsoft Packet Capture auszuführen. Auch mit dem Capture konnte die IT das Problem nicht lösen, und aus Frust schickte er es mir. Da ich Entwickler bin, habe ich auf meinem Laptop Adminrechte und MSDN, also lud ich die Microsoft-Tools herunter und sah mir den Capture an: Die App war eine Client/Server-Implementierung innerhalb der lokalen Maschine. Das Frontend kommunizierte über einen Netzwerkport mit dem Backend, und das Backend kommunizierte mit dem Server des Vendors. Als das Unternehmen mit „standardmäßig blockieren“ anfing, zerstörte das auch meinen Entwicklungsfluss auf mehrere Arten, und auch ich fand Workarounds, von denen die IT nichts wusste. Ich sagte der IT, was sie wissen musste und wie sie es auf die Whitelist setzen konnte, aber er hat immer noch Probleme. Dass ich die Details unscharf halte, liegt nicht nur an Vertraulichkeit, sondern auch daran, dass mein Freund über ein Jahr mit der IT arbeiten musste, um bis zu diesem Punkt zu kommen, und das vor zwei Jahren war, sodass ich viele Details vergessen habe. Wenn man in einem Legacy-Fertigungsunternehmen mit „standardmäßig blockieren“ anfängt, ist „drei zusätzliche Hin-und-Her-Runden“ eine Untertreibung
  • Ich wünschte, mehr IT-Administratoren würden Sicherheitsgurte und Airbags als Sicherheitsmodell nehmen. Im normalen Alltag mit dem Auto sind sie nur eine sehr kleine Unannehmlichkeit, aber bei einem Unfall ist ihr Wert enorm. Stattdessen halten viele Administratoren es für normal, die Arbeit selbst zu blockieren, um ihre eigene Unwissenheit und mangelnde Fachkompetenz zu verbergen
  • Gute IT-Sicherheit ist nicht unsichtbar. Sie ist dazu da, die Einführung miserabler Anwendungen zu verhindern, die unbegrenzten ausgehenden Internetzugang verlangen. Man muss Multi-Faktor-Authentifizierung vorantreiben und von Anfang an mit den Stakeholdern zusammenarbeiten, um Sicherheit bereits in der Startphase sicherzustellen. Meist geht es darum, Geschäftsrisiken zu identifizieren und zu mindern. Man sollte bedenken, dass jede Anwendung als Haftungsfaktor betrachtet wird und jede neue Anwendung, die vom Standard abweicht, im Einzelfall behandelt werden muss
  • Für die Sicherheitsinfrastruktur rund um Workstations halte ich eine „standardmäßig blockieren“-Policy für eine gute Idee. Der Aufwand für die IT, das Sicherheitsprofil zu ändern, wenn ein neues Tool mit neuen Ports usw. hinzukommt, ist viel geringer als die Kosten, wenn Inhalte einer bestimmten Workstation abfließen. Allerdings müssen Anwendungsserver und öffentliche Infrastruktur meiner Meinung nach zwingend standardmäßig blockieren. Mir fällt kaum eine Situation ein, in der das nicht nötig wäre
  • Die Unternehmens-IT existiert für das Unternehmen. Die Kosten dürfen den Nutzen nicht übersteigen. Es braucht ein Gleichgewicht. Es darf nicht eine Woche dauern, einen Port zu öffnen, aber man will auch nicht, dass Leute auf dem Unternehmensdesktop einen Webserver betreiben und daneben zufällig Dateien mit proprietären Plänen liegen

• Sicherheitsorientierte Texte werden meist von Menschen geschrieben, denen Sicherheit extrem wichtig ist, und blenden oft die Schwierigkeiten aus, die ein rein sicherheitszentrierter Ansatz für Nutzer sicherer Software mit sich bringt. Sicherheit betrachte ich immer als Schieberegler zwischen Sicherheit und Bequemlichkeit. Ein vollständig sicheres Design ist so unbequem, dass es kaum Nutzer hat, und ein vollständig bequemes Design ist nicht sicher genug und kann am Ende zum gleichen Ergebnis führen. Trotzdem ist dieser Text insgesamt lesenswert, aber der Vorstellung, es sei dumm, wenn Sicherheitsexperten Exploits schreiben oder lernen, wie man ein bestimmtes System missbraucht, widerspreche ich entschieden. Ich habe viel mehr über Sicherheit gelernt, indem ich Schwachstellen und Exploits untersucht und sie selbst auf White-Hat-Art implementiert habe, als durch das Studium von „sicherem Design“. Es ist ähnlich wie der Spruch: „Um den Kerl zu verstehen, musst du selbst zu ihm werden.“

  • Diese Analogie ist vermutlich zugänglicher, aber ich formuliere es gern etwas aggressiver. Wenn ich mit Leuten diskutiere, die nur Sicherheit predigen, fange ich etwa mit „Am sichersten wäre es wohl, den Laden morgen zu schließen, aber das dürfte schwer genehmigt werden“ an. Wenn wir gemeinsam gelacht haben, können wir besprechen, welchen Kompromiss wir eingehen. Ich hatte auch schon Erfolg damit, die Ausgangslage umzudrehen: „Wenn ihr Nein sagt, machen wir es einfach ohne euch, und dann steckt nur so viel Sicherheit drin, wie ich einbaue. Einen Weg finden wir immer; ich würde mich freuen, wenn ihr uns auf einen sichereren Weg führt.“ Allerdings versuche ich das zu vermeiden, weil es leicht Widerstand erzeugt.

• Das ist größtenteils eine miserable Liste von vor 19 Jahren. „Software und Systeme sollten von Grund auf sicher sein und mit Blick auf Fehlerbehandlung entworfen worden sein“ bedeutet: „In einer perfekten Welt wäre alles von Anfang an sicher gewesen.“ Das wird nie passieren, also muss man Techniken nach dem Prinzip finden und patchen einsetzen, und sie haben für Unternehmen gut funktioniert, die entdeckte Schwachstellen tatsächlich patchen und aus ihren Fehlern für künftige Coding-Praktiken lernen. Außerdem sind die meisten Systeme nicht statisch. Man veröffentlicht nicht einmal ein sicheres System und aktualisiert es nie wieder; die meisten Anwendungen und Systeme werden häufig aktualisiert, und dabei gelangen neue Schwachstellen hinein.

  • Wohlwollend interpretiert meint der Autor vielleicht das Problem, dass man nur allzu eng zugeschnittene „Patches“ vornimmt, ohne die fehlerhaften Design-Praktiken zu korrigieren, die die Schwachstelle verursacht haben. Zum Beispiel, wenn man eine Cross-Site-Scripting-Schwachstelle in einer Webanwendung dadurch „behebt“, dass man Requests blockiert, die Schlüsselwörter wie script oder onclick enthalten.
  • Das ist ein Beispiel dafür, dass viele Leute einen für klug halten, wenn man selbstbewusst Unsinn redet.
  • Der Text selbst ist ebenfalls unverhohlen töricht. Der Satz „Ein schüchterner Mensch kann zum Kriminellen werden“ missversteht Hacking, Kriminalität und die menschliche Natur zugleich. Kriminelle gehen dorthin, wo das Geld ist; man muss kein riesiger Wrestler sein, um jemanden vor einem Geldautomaten mit einer Waffe zu bedrohen und ihm Geld abzunehmen, und man muss kein typischer Nerd sein, um Computer zu verstehen. Das ist Dummheit auf dem Niveau der schlechtesten Komödien der 1980er-Jahre. Auch die Aussage, „Remote Computing habe die historische Notwendigkeit beseitigt, dass Kriminelle nahe am Tatort sein müssen“, ergibt keinen Sinn. Man muss nur daran denken, was die Post ermöglicht hat. Der spanische Gefangenenbetrug existiert seit Jahrhunderten und hat dieselbe Struktur wie 419-Betrug. Auch die Behauptung, Anonymität und das Fehlen einer direkten Konfrontation mit dem Opfer senkten die emotionale Hürde für Verbrechen, ist übertrieben. Kriminelle können jemandem auch ins Gesicht sehen und ihn betrügen oder Gewalt anwenden und ihn zwingen, sein Konto zu leeren. Und schließlich ist „Mach es von Anfang an komplett richtig, Idiot“ kein umsetzbarer Plan.
  • Häufige Updates kaschieren in hohem Maße ungeeignete Engineering-Praktiken und fördern ungeeignete Produkte. Die Welt ist nicht statisch, aber in den meisten Fällen gibt es Muster, die man erkennen und behandeln muss. Wenn man von schnellem Fix zu schnellem Fix eines MVP rennt, bekommt man dafür keine Zeit.
  • Ein paar wertvolle Kerne enthält der Text zwar, aber mindestens die Hälfte liest sich wie eine peinliche Tirade, die man gegen Ende der Firmenweihnachtsfeier von einem betrunkenen neuen Helpdesk-Praktikanten hören würde. Es ist erstaunlich, dass das von einem Fachexperten geschrieben wurde, 20 Jahre lang auf seiner Website stand und so oft empfohlen wurde.