Publikationen
Fachartikel von Christoph Puppe
Über zwanzig Jahre Schreiben über Informationssicherheit: vom Schwachstellenscanner-Vergleich 2005 über die Container- und Kubernetes-Bausteine des BSI bis zum maschinenlesbaren Grundschutz++. Dazu ein Buch zum Grundschutz++, Software auf GitHub und Essays auf LinkedIn.
Zum Autor
Christoph Puppe ist IT-Sicherheitsarchitekt. Seit 2008 ist er zertifizierter Auditteamleiter für ISO 27001 auf Basis von IT-Grundschutz, Mitautor mehrerer Bausteine des BSI IT-Grundschutz-Kompendiums und an der Entwicklung von Grundschutz++ beteiligt. Er ist Certified Information Systems Security Professional (CISSP) und war mehrere Jahre als Penetrationstester tätig. Er schreibt seit 2004 für iX und heise online und arbeitet an maschinenlesbaren Complianceformaten, OSCAL und JASCON.
Die Liste ist gegen die Heftarchive aller iX-Ausgaben von 2004 bis 2026 abgeglichen und damit vollständig: 58 iX-Artikel, dazu die reinen Onlinebeiträge, zwei Interviews und eine BSI-Studie. Wo ein Artikel hinter der heise-Paywall liegt, steht der Abstract hier trotzdem frei lesbar.
Volltexte auf dieser Seite
Danksagung: Die Chefredaktion von iX gewährt für diese Seite eine Ausnahme von der Regel, dass die Artikel exklusiv bei heise liegen. Sobald die Veröffentlichung eines Artikels mehr als zwei Jahre zurückliegt, darf er hier im Volltext erscheinen, jeweils mit Link auf das Original. Ohne diese Zusage blieben die Texte hinter der Paywall unsichtbar; danke dafür. Die Volltexte wandern nach und nach in die Einträge.
Buch
-
1 Jahr Mitarbeit am BSI Grundschutz++: Erfahrungen, Erkenntnisse und Ausblicke aus der Werkstatt der IT-Sicherheit
Ein Werkstattbericht aus dem Maschinenraum des neuen Grundschutzes: Als einer von rund 40 freiwilligen Fachexperten arbeitet der Autor seit Phase 1 am Grundschutz++ mit, knapp 200 Issues zum Anwenderkatalog eingeschlossen. Das Buch bilanziert dieses Jahr in drei Teilen: die Einordnung, warum die Edition 2023 die letzte dokumentenbasierte Fassung ist und was die sieben OSCAL-Stufen bedeuten; eine kritische Betrachtung des Methodik-Leitfadens vom April 2026, dessen zentrale Schwäche die Trennung von Methodik und Datenstruktur ist; und ein Referenzmodell, das die Lücken mit den vom NIST definierten Arbeitsschritten füllt, von der technischen Eingangsprüfung bis zum maschinengenerierten Auditbericht. Das Vorwort legt offen, dass die Texte mit KI entstanden sind; die 600 bis 700 Stunden Eigenleistung stecken in Tools, Prompts und Qualitätssicherung. Angelegt als Living Document, die begleitenden Open-Source-Werkzeuge stehen auf GitHub.
2026
-
Grundschutz: Radikalster Umbau seit Bestehen
Der IT-Grundschutz wird tiefer umgebaut als je zuvor seit dem IT-Sicherheitshandbuch von 1992: Den Grundschutz++ entwickelt das BSI erstmals komplett selbst, mit unbezahlter Hilfe Freiwilliger. Zentrale Designentscheidung ist die Maschinenlesbarkeit: Alle knapp tausend Maßnahmen liegen im OSCAL-Format des NIST als JSON vor, verteilt über zwanzig Praktiken im seit September 2025 veröffentlichten Anwenderkatalog. Das löst ein reales Problem, denn das Auditierungsschema hatte die Zahl der nachzuweisenden Anforderungen auf fast 6.000 getrieben. Aus Bausteinen werden Zielobjektkategorien, der Preis ist der vollständige Verlust der Spezifizierung: Wo früher konkrete Anforderungen für Windows Server 2025 standen, bleibt die Kategorie Hostsysteme übrig. Dazu kommen handwerkliche Härten: nur noch zwei Umsetzungsstände, kein „teilweise“, kein „entbehrlich“; die Herleitung der Maßnahmen aus einer Risikoanalyse fehlt, was die Anerkennung als ISO-27001-Äquivalent infrage stellt. Alle Anwender müssen bis zum 1. Januar 2029 migrieren, ein dreistelliger Millionenbetrag an Umstellungskosten erscheint realistisch. Das Urteil: überfälliger Paradigmenwechsel, aber solange Zertifizierungsschema und begleitende Standards fehlen, ein ambitioniertes Framework im Betastadium, das Enterprise-Teams neue Freiheiten schenkt und kleine Organisationen im Regen stehen lässt.
-
Cloud-Apps absichern: mit oder ohne Agenten
Große CNAPP-Marktübersicht über gut 20 Anbieter, die statt Featurelisten Architektur, Anbieterfinanzen und Enterprise-Tauglichkeit vergleicht. Die Grundsatzfrage ist die Telemetrie: Agentenlose Snapshot-Scanner wie Wiz und Orca liefern in Minuten vollständige Sichtbarkeit, sind aber blind für flüchtige Container und dateilose Malware. Agenten aus der EDR-Welt stoppen Prozesse in Millisekunden, erkaufen das mit Agent Fatigue und Kernel-Risiken; eBPF sieht jeden Syscall bei minimalem Overhead. Das Urteil: Für Statik und Compliance ist agentenlos überlegen, für die Abwehr aktiver Angriffe in Kubernetes ist Agent oder eBPF weitgehend alternativlos. Zur Machtverschiebung des Jahres: Google kaufte Wiz für 32 Milliarden US-Dollar, Microsoft hält knapp 25 Prozent Marktanteil. Unbequem: Keine einzige CNAPP analysiert EU-Anbieter wie Scaleway oder STACKIT, und seit dem Fall Lacework gehört die finanzielle Stabilität in jede Bewertung. Der Schluss nimmt den Leser in die Pflicht: mindestens 30 Prozent des Budgets in Training und Prozesse stecken, sonst kauft man nur ein teures Dashboard, das in bunten Farben zeigt, wie unsicher das eigene Unternehmen ist.
-
BSI veröffentlicht ersten Leitfaden für den Grundschutz++
Kurzmeldung zur Veröffentlichung des ersten Methodik-Leitfadens für den Grundschutz++ am 1. April 2026; der Anwenderkatalog war bereits am 30. September 2025 erschienen. Damit erfüllt das Amt eine Verpflichtung aus der NIS2-Umsetzungsverordnung; der bisherige IT-Grundschutz bleibt übergangsweise bis Ende 2028 gültig. Die Meldung ordnet ein, was der Leitfaden leistet und was nicht: Er beschreibt zum größten Teil Prozesse, die der maschinenlesbare Katalog ohnehin festlegt, die eigentliche Substanz steckt im OSCAL-Katalog, nicht im PDF. Die vollständige Analyse des Umbaus folgt einen Monat später im Artikel „Grundschutz: Radikalster Umbau seit Bestehen“; die Viertelseite hier dokumentiert den Moment, in dem aus dem Community-Projekt ein amtlicher Standard wurde.
-
Der Cloud-SIEM-Markt: von Hyperscalern und Legacy-Riesen
Hyperscaler locken mit Plattformintegration, Observability-Anbieter drängen ins SOC, die etablierten Platzhirsche kämpfen um ihre Relevanz. Die Marktübersicht porträtiert rund zwanzig Anbieter und vergleicht Architektur, Ingestion, Preismodelle und KI-Integration; Featureparität ist keine Frage mehr, entscheidend ist die Passung zur Data Gravity der eigenen Infrastruktur. Zu jedem Porträt gehört die Falle: Microsoft Sentinel ist die logische Wahl für Microsoft-first-Organisationen, doch die Kosten des Log Analytics Workspace werden separat und aggressiv abgerechnet. Google SecOps durchsucht Petabytes in Google-Geschwindigkeit, der Oberfläche fehlt Reife im Case Management. Splunk bleibt der Ferrari unter den SIEMs, erkauft mit dem Wartungsaufwand des Heavy-Forwarder-Hybridmodells. CrowdStrike LogScale schafft indexfrei ein Petabyte pro Tag, SentinelOne kontert mit OCSF und Datenresidenz in Frankfurt, Palo Altos Cortex XSIAM verspricht das selbstfahrende SOC mit dem größten Lock-in des Marktes, ManageEngine startet bei 300 US-Dollar pro Jahr. Die Empfehlungen aus der Praxis: Daten von der Analyse entkoppeln, niemals One-Click-Ingestion ohne strikte Budget-Alerts, Hybrid ist King, für den Mittelstand ist Managed Detection and Response oft wirtschaftlicher als der Eigenbetrieb. Wer heute ein SIEM beschafft, entscheidet sich für eine Datenstrategie. Denn ein SIEM ohne dediziertes Engineering-Team ist nur eine teure Festplatte.
-
Die SIEM-Metamorphose: Architekturfallen und die Kosten der Cloud
Wer sich noch an die Zeit erinnert, als SIEM im Wesentlichen aus einer Datenbank und einer Handvoll Perl-Skripten bestand, erkennt die heutige Landschaft nicht wieder: Agentic AI ist bei Angreifern wie Verteidigern im Einsatz, während das Datenvolumen explodiert und die traditionellen Lizenzmodelle an physikalische Grenzen führt. Der Begriff Cloud-SIEM ist dabei semantischer Nebel, der echtes Cloud-native-Design, gehostete Legacy-Plattformen und hybride Brücken verschleiert. Der Artikel analysiert die Physik dahinter: Data Gravity, denn Sicherheitsdaten besitzen digitale Masse, und die Egress-Steuer übersteigt oft die Kosten der überwachten Infrastruktur selbst. Im Zentrum steht die letzte Meile der Logintegration mit drei Mechanismen samt Schwächen: Der Heavy Forwarder à la Splunk ist der Goldstandard für Kontrolle, aber ein Single Point of Failure; Agenten auf den Endpunkten führen zur Agent Fatigue und verlieren bei Netzausfall Daten; als Abwehrschicht gegen Rechnungsschocks etabliert sich die Telemetry Pipeline mit Cribl, Vector oder OpenTelemetry, die Debug-Logs in günstigen S3-Storage umleitet. Für europäische Unternehmen kommt das Schrems-II-Dilemma hinzu: EU-Regionen bieten fast alle, doch Metadaten und Supportzugriffe erfolgen oft aus Drittstaaten. Das Fazit: Die primäre Herausforderung ist, die Daten bezahlbar zur Analyse-Engine zu transportieren; Hybrid wird zum Dauerzustand.
-
Ändern die AWS- und Azure-Ausfälle etwas? Vergleich der Downtimes von On-Premises- und Cloud-Umgebungen
Die Ausfälle der beiden Hyperscaler im Oktober 2025 seien der Beweis für die Unsicherheit der Cloud, so der Tenor vieler Kommentare. Das ist die Nirvana Fallacy: Man vergleicht eine realistische, aber unvollkommene Option mit einer perfekten, aber unmöglichen. Der Artikel vergleicht deshalb drei Placement-Strategien ausschließlich anhand nachweisbarer Fakten. Weil eine Kennzahl fehlt, die Teilausfälle ins Verhältnis zum Gesamtangebot setzt, wird transparent eine eigene konstruiert, der BlastRadius-KPI aus Dauer, Schweregrad und Betroffenenzahl aller Incidents seit 2020. Das Ergebnis: AWS kommt auf 225, Azure auf 136, GCP auf 98, fast exakt korreliert mit den Marktanteilen. Bei den Mittelständlern liegt Hetzner bei 224, Ionos bei 747, OVHcloud jenseits der 18.000. Für on Premises gibt es nur Umfragen: 57 Prozent der Befragten berichten von zunehmenden Störungen, verzerrt durch den Beschwerde-Bias. Dazu kommt Ransomware als weitgehend hausgemachtes On-Premises-Problem: durchschnittlich 24 Tage bis zur Wiederherstellung, 816 Millionen US-Dollar Lösegeld laut Chainalysis. Die Cloud hat eigene Wunden, etwa die Actor-Token-Lücke bei Entra ID, doch beim Verwundbarkeitsmanagement spielen die Großen ihre Stärke aus. Das Fazit fällt hart aus: Wegen der Verfügbarkeit nicht zum Hyperscaler zu gehen, ist anhand der vorliegenden Daten eine gravierende Fehleinschätzung. Wer dennoch anders hostet, sollte gute Gründe dafür haben.
2025
-
Experiment: KI entwickelt ISMS-Standard weiter
KI als Hilfsmittel bei Securityaudits ist etabliert; dieses Experiment fragt, ob ein Sprachmodell einen Sicherheitsstandard auch weiterentwickeln kann. In sechs Wochen entstand eine komplette Compliance-as-Code-Pipeline: rund 8.000 Zeilen Python, 4.000 Zeilen JSON-Schemas und etwa 50 verfeinerte Prompts, per Vibe Coding mit Gemini 2.5 Pro als Arbeitspferd; Gesamtkosten rund 1.700 Euro auf der Google Cloud Platform. Das erste Experiment überführte das Grundschutz-Kompendium aus PDF ins maschinenlesbare OSCAL-Format des NIST, als Nebeneffekt fielen Übersetzungen in 14 Sprachen ab. Das zweite generierte Entwürfe für fehlende Bausteine, etwa zu KI-Systemen, CI/CD-Pipelines und Cloud-IAM, die Experten als Version 0.8 dienen können. Das dritte, der BSI Audit Automator, automatisierte das Dokumenten-Review eines echten Überwachungsaudits: Statt zehn Personentagen dauert der Durchlauf zwei Stunden, plus Qualitätssicherung von bis zu einem Viertel des ursprünglichen Aufwands, denn das Modell verwechselte regelmäßig die Nummern der Anforderungen. Der eigentliche Gewinn liegt in der Prüftiefe: Die Maschine prüft alle Dokumente gegen alle Prüffragen, der Auditor wird vom Dokumentenprüfer zum Risiko- und Strategieberater. Zwei Lektionen bleiben: Der Wert liegt in der Bibliothek domänenspezifischer Prompts, und sensible Auditdaten gehören unter keinen Umständen in öffentliche Chatbots. Code und Werkzeuge stehen unter der Business Source License zum Download bereit.
-
Sichere Cloud mit Azure Policies
Azure Policies sind derzeit das wirksamste Mittel zur Überwachung und Verbesserung der Sicherheit in Azure: Der Azure Resource Manager prüft jede Aktion vor der Ausführung gegen die Richtlinien, Verhindern statt Erkennen ist das Ziel. Das unterscheidet den Ansatz von CSPM-Werkzeugen, die erst hinterher auswerten, und hebt Azure von den anderen Hyperscalern ab, deren Policy-Implementierungen bei Weitem nicht so ausgereift sind. Der Artikel zerlegt eine Richtlinie in Definition, Zuweisung und Parameter und erklärt sämtliche Policy-Effekte von
auditbis zum restriktivendeny, samt der SonderfälleauditIfNotExistsunddeployIfNotExists, die Azure erst mit einigen Minuten Verzögerung auswerten kann. Wer nicht alles selbst schreiben will, greift auf die knapp 11.000 eingebauten Richtlinien zurück; eigene bieten mehr Flexibilität, kosten aber erheblichen Pflegeaufwand in Azures JSON-Syntax. Die Integration in CI/CD- und IaC-Umgebungen macht Richtlinien versionierbar, birgt aber eine Falle: Modifizierende Effekte wiemodifyändern Ressourcen hinter dem Rücken des IaC-Codes, weshalb man dort üblicherweise auf sie verzichtet. Das Urteil: Wer die Integration nutzt, kann Governance weitgehend automatisieren, statt sie hinterher zu dokumentieren. Der schrittweise Weg über ein Testabonnement gehört dazu, denn ungetestete Richtlinien setzen ihre Fehler ebenso zuverlässig durch wie ihre Regeln.
2024
-
Was würde Willy Brandt sagen zur souveränen Cloud?
Interview von Gregor Schumacher mit Christoph Puppe als befragtem Experten. Souveränität und Autarkie werden in der Debatte um die europäische Cloud regelmäßig verwechselt: Souveränität heißt, Selbstbestimmung auszuüben, Autarkie vollständige Unabhängigkeit, und letztere ist kaum realisierbar, denn Abschottung bremst die Innovation. Die Größenordnungen sind ernüchternd: Amazon, Microsoft und Google investieren zusammen rund 120 Milliarden US-Dollar jährlich in Forschung und Entwicklung. Entsprechend nüchtern die Einschätzungen: Dem Delos-Projekt traut der Befragte einiges zu, Aktien würde er trotzdem keine kaufen; Gaia-X hat sich als wirkungslos erwiesen. Open Source ist wichtig, aber kein Allheilmittel: Unter den zwanzig größten Kubernetes-Beitragenden finden sich nur zwei europäische Firmen. Zugleich verteidigt er die Hyperscaler gegen den Schlangenöl-Vorwurf, nur gibt jeder Gang in die Cloud immer auch ein Stück Souveränität ab. Der Krieg in der Ukraine dient als Lehrstück: Die Verlagerung der Staats-IT zu AWS schützte die Daten vor physischer Zerstörung und hielt kritische Dienste am Laufen. Mit Willy Brandts Gedanken, die Welt als Einheit zu begreifen, läuft die Empfehlung auf weitere Nutzung der US-Dienste bei gezielter europäischer Entwicklung und stärkerer Open-Source-Förderung hinaus. Denn ein Netz wird stärker, wenn jeder seinen Teil gut macht.
-
Marktübersicht: Sicherheitsscanner für Container-Images
Marktübersicht mit eigenem Kurztest: 15 Hersteller, von Aqua Security über Snyk und Qualys bis zu den eingebauten Scannern von AWS, Azure, GCP, GitLab und Quay. Das Testverfahren ist reproduzierbar: ein absichtlich verwundbares Image mit gut abgehangenem Ubuntu, verstecktem SSH-Secret-Key, verwundbarer NPM-Bibliothek, sshd und EICAR-Teststring. Die Grundwahrheit: 69 CVEs, und kein einziger Scanner fand alle. Aqua kam mit 68 am nächsten heran, am unteren Ende fanden Qualys 39 und Azure Defender 47, für renommierte Schwachstellenmanagement-Anbieter ein bemerkenswertes Ergebnis. Das SSH-Secret entdeckten nur Aqua und NeuVector, die Malware fand in der Standardkonfiguration kein einziges Produkt. Sysdigs eigene Images brachten 179 CVEs mit. Die Streitfrage Agent oder kein Agent klärt der Artikel mit klarem Urteil: Erst Agenten auf den Nodes ermöglichen Laufzeitüberwachung, Forensik und das Erfüllen der erhöhten Anforderungen der Bausteine SYS.1.6 und APP.4.4. Wer früh in der CI/CD-Pipeline scannt und Quality Gates erzwingt, hat eine Chance; alle anderen betreiben Complianceverwaltung ihrer Verwundbarkeiten.
heise online · iX 5/2024 · PDF · Permalink
2023
-
Selbst gehostete Full-Service-Cloud
Google Distributed Cloud Hosted und Azure Stack Hub Disconnected versprechen den Komfort der Public Cloud im eigenen Rechenzentrum, vollständig ohne Internetanschluss betreibbar. Der Lackmustest ist das Air Gap, denn nur ohne Anschluss an den Hersteller ist der Kunde wieder vollständig Inhaber der Daten und Prozesse. Google richtet sich an Kunden mit hoheitlichen Aufgaben und nennt Testkonfigurationen ab 300 000 US-Dollar pro Monat bei mindestens vier Racks; ausprobieren ließ sich nichts, die Analyse stützt sich auf die Dokumentation der Version 1.9.4. Geliefert wird im Kern eine Kubernetes-Distribution auf Ubuntu 20.04 LTS mit IaaS, Storage, Vertex AI und Schlüsselmanagement; Updates kommen auf Wechselplatten hinter das Air Gap, von den weit über 300 GCP-Diensten bleibt wenig übrig. Bei Microsoft besteht von drei beworbenen Optionen nur eine den Test: Allein der Azure Stack Hub läuft wirklich disconnected, mit Hyper-V auf Standardhardware, lokalen ADFS-Servern und einem Enterprise Agreement über die installierte Kapazität. Bei genauer Betrachtung sind beide Angebote hauptsächlich Kubernetes-Distributionen mit Storage und Verwaltung und konkurrieren weniger mit den Onlinediensten der Hyperscaler als mit OpenShift, Rancher, Kubermatic oder Tanzu, die sich ebenfalls air-gapped installieren lassen. Der Vorteil ist die ausgereifte Verwaltung; ob das die Preise rechtfertigt, die es nur auf Anfrage gibt, darf bezweifelt werden.
-
Kubernetes-Sicherheit: OpenShift und Rancher nach BSI-Anforderungen härten
Im letzten Teil der Serie zur Kubernetes-Absicherung treten zwei Distributionen an. Der OpenShift-Demo-Cluster in Version 4.12.13 stand nach zwei Stunden, per Terraform in der Google-Cloud installiert, mit 35 Operatoren, die den Betrieb übernehmen; wäre der Cluster ein Linux, wären die Operatoren die von systemd verwalteten Basisdienste. Seit Version 4.11 ersetzen elf Security Context Constraints die Pod Security Policies, Standard ist restricted. Die für die Absicherung nötigen Operatoren fehlen aber in der Defaultinstallation: der Compliance Operator mit OpenSCAP, der File Integrity Operator mit AIDE, der Security Profiles Operator für SECCOMP- und SELinux-Profile. Schwerster Mangel bei SYS.1.6.A5: Die Admin-Webkonsole hängt am selben Loadbalancer wie die Anwendungen. In den OpenShift-Images fanden sich etliche Verwundbarkeiten, für immerhin 26 existieren Exploits; dafür muss der Operator Hub mit fast 500 Paketen den Vergleich mit den Hyperscalern nicht fürchten. Rancher, seit 2020 bei SUSE, liefert mit K3s, RKE und RKE2 drei ausgereifte Distributionen; das Update von Kubernetes 1.24 auf 1.25 lief in zwei Minuten durch, ohne die Workloads zu stören. Doch als Node-Betriebssystem wählt Rancher per Default ein betagtes Ubuntu 18.04 LTS, und die NeuVector-Installation scheiterte im Test. Zwei Tabellen bewerten die Anforderungen der Bausteine SYS.1.6 und APP.4.4; weder Constraints noch Sicherheitsoperatoren ersetzen eine ausgereifte Cloud Workload Protection Platform. Wer alles aus einer Hand will, dürfte bei OpenShift landen, wer mehr Freiheit sucht, eher bei Rancher.
heise online · PDF · Permalink
-
Kubernetes-Sicherheit: Wie Sie Open Telekom Cloud und plusserver härten
Die beiden deutschen Anbieter versprechen digitale Souveränität, einfachere Datenschutz-Folgenabschätzungen und oft bessere Preise als die Hyperscaler. Dafür bekommen Kunden weitgehend pures Kubernetes, mit allen Konsequenzen für die Absicherung. Die Cloud Container Engine der Open Telekom Cloud verlangt ein vorher eingerichtetes VPC-Netzwerk, ein NAT-Gateway für den Weg ins Internet und einen eigenen Bastion-Host statt einer Cloud-Shell; der Turbo-Cluster bot zum Testzeitpunkt ein reichlich betagtes Kubernetes 1.19. PlusServer stellt mit der plusserver Kubernetes Engine den mandantenfähigen Gardener der SAP bereit, mit aktuellem Kubernetes 1.25 und einer in Sekunden fertigen Einrichtung; originell ist der Schlafrhythmus, der Entwicklungscluster nachts abschaltet. Doch im Test stand nur eine Verfügbarkeitszone bereit, es gibt weder Backup-Dienst noch Registry, und im Ubuntu-22.04-Image fand der Scanner 439 Verwundbarkeiten. Die OTC schnitt besser ab: Trivy zählte dort 173 Verwundbarkeiten mit nur 2 kritischen, bei PlusServer 132 mit immerhin 21 kritischen; zum Vergleich kam AWS auf 8731, GCP auf 61. Zwei Tabellen führen auf, welche Anforderungen der Bausteine SYS.1.6 und APP.4.4 die Anbieter erfüllen; für erweiterte Sicherheitsrichtlinien, automatisierte Auditierung und hostbasierte Angriffserkennung bleibt bei beiden nur der Griff zu Drittsoftware. Die günstigeren einheimischen Angebote sind gut, aber wer sie wahrnehmen möchte, sollte den zusätzlichen Aufwand für die Absicherung auf sich nehmen.
heise online · PDF · Permalink
-
Kubernetes von AWS und IONOS härten
Der Kontrast in diesem Teil der Serie könnte kaum größer sein. IONOS begrüßt Kunden mit einem grafischen Datacenter-Designer statt CLI und Terraform; der erste Cluster steht schnell, ein Managed Kubernetes mit Hidden Master auf Ubuntu 20.04.5 LTS. Entsprechend wenig fand der Scanner: 210 Verwundbarkeiten insgesamt, davon 25 kritische, und als einziger Anbieter ließ IONOS die CIS-Benchmarks auf den Nodes zu. Der Preis der Schlichtheit: keine Registry mit Verwundbarkeitsscans, keine auffindbare Protokollierung administrativer Tätigkeiten, für fast alle Anforderungen bei erhöhtem Schutzbedarf ist Drittsoftware nötig. AWS steht am anderen Ende: Der Elastic Kubernetes Service ist stark in IAM, CloudTrail und die hauseigene Registry integriert, die Datenhaltung per Default verschlüsselt. Doch direkt nach der empfohlenen Standardinstallation lagen rekordverdächtige 302 Images auf den Nodes, und Trivy zählte 8731 Verwundbarkeiten, davon 2070 kritische, tausendmal so viele wie bei GCP mit insgesamt 61. Viele Sicherheitsfunktionen müssen AWS-Nutzer zudem erst aktivieren. Zwei Tabellen bewerten die Anforderungen der Bausteine SYS.1.6 und APP.4.4 nach dem Ampelschema. Das Urteil: IONOS liefert ein solides, unverfälschtes K8s für wenig Geld mit wenig Integration, AWS ein mächtiges Ökosystem mit irritierend vielen Verwundbarkeiten auf den Nodes.
heise online · PDF · Permalink
-
Kubernetes-Tutorial, Teil 3: Überprüfen von Anfragen an die K8s-API
Admission Controller sind ein zentrales Element zum Absichern von Kubernetes: Jede Anfrage an die K8s-API wird authentifiziert, autorisiert und durchläuft dann eine Kette von Kontrollen. Mutating Admissions passen Konfigurationen dynamisch an, etwa per Sidecar für das Service Mesh Istio; Validating Admissions gleichen das Ergebnis mit festgelegten Regeln ab. Vor allem der zweite Schritt entscheidet über die Clustersicherheit, denn hier muss jeder Container vorbei: Wurde das Image gescannt, liegt ein privater SSH-Schlüssel darin? Left Shift in der CI/CD prüft nur, was im Git steht; erst ein Admission Controller sieht alle Requests, auch die am Repository vorbei. Seit Kubernetes 1.24 die PodSecurityPolicy außer Dienst gestellt hat, liefert die Pod Security Admission mit den Levels Privileged, Baseline und Restricted einen Ersatz. Wem das zu starr ist, der greift zu Kyverno oder zum Open Policy Agent mit Gatekeeper, dessen Regelsprache Rego eine freie Bibliothek mitbringt, aber Einarbeitung kostet; kommerzielle Plattformen verpacken dieselbe Funktionalität hinter API und Web-UI. Jedes Feature ist aber auch eine Flanke: Wer schreibend auf das Regelwerk zugreift, kann seine Rechte erhöhen oder mit einem Mutating Controller jede Anfrage beliebig verändern; Schreibrechte auf Images, Regeln und Labels sind strikt zu begrenzen. Wer Sicherheit ernst nimmt, sollte die Arbeit in präzise Regeln stecken, denn erzwungene Regeln schlagen bloß überwachte.
heise online · PDF · Permalink
-
Kubernetes-Tutorial, Teil 2: Namespaces, Benutzer- und Objektverwaltungen
Kubernetes macht die Benutzerverwaltung nicht selbst, trotzdem gibt es bei der sicheren Konfiguration einige Identitäten zu berücksichtigen. Das Fundament: UID und GID der Container-Prozesse dürfen keine Berechtigungen auf dem Node haben; User Namespaces verdoppeln die IDs, werden aber nur von CRI-O unterstützt. Ohne explizite Angabe bekommt jeder Pod den Default-Service-Account, dessen Token man mit
automountServiceAccountToken: falseaus dem Pod heraushalten sollte, kombiniert mit einer Network Policy gegen den API-Server. Zur Authentifizierung kennt Kubernetes Token, X.509-Zertifikate und Plug-ins; da der private Schlüssel eines Dienstes nicht mit Passwort verschlüsselt sein kann, sind Zertifikate kaum besser als Token, beide sind Geheimnisse. Die Autorisierung läuft über RoleBindings, wobei sich nur Erlaubnisse addieren, Verbote gibt es nicht. Danach härtet der Artikel exemplarisch AKS und GKE. GKE punktet mit dem Autopilot, dem gehärteten Read-only-Image COS_containerd und der Option, API-Zugriffe auf Projekt oder IP-Bereich zu beschränken; die Autopilot-Härtung war so wirksam, dass sich die Analysesoftware gar nicht erst installieren ließ. AKS glänzt mit der Azure-AD-Integration und Richtlinien-Sets im Defender for Cloud. Die Bilanz der Image-Qualität fällt deutlich aus: AquaSec fand bei Azure 2066 Verwundbarkeiten, bei GCP 61, private Schlüssel einer Test-CA inklusive. Insgesamt hat GCP die Nase vorn, Azure hält bei der Richtlinienverwaltung dagegen. Wichtig ist in beiden Fällen ein privater Cluster.heise online · PDF · Permalink
-
Kommentar zum Cloud-Ausfall bei MS: Ist der Patient schon tot oder nur lädiert?
Erst ist die Cloud da, dann ist die Cloud weg, und oft nur ein bisschen vom einen oder vom anderen. Anlass ist der Teilausfall von Azure am 25. Januar 2023: Eine Änderung an einem Router im Microsoft-WAN zwang alle anderen Router zur Neuberechnung ihrer Routen, nach rund 45 Minuten war der Fehler behoben, Auswirkungen gab es bis mittags. Total war der Ausfall nie: Dienste waren langsam, Meeting-Teilnehmer verschwanden, andere merkten nichts. Genau diese Grauzone bilden heutige Service Level Agreements nicht ab, sie messen Verfügbarkeit binär. Die Medizin arbeitet mit besseren Maßeinheiten: Years of Life Lost für die tödliche Krankheit, Disability-Adjusted Life Years für das Weiterleben mit Einschränkung. Übertragen auf die IT ist der Totalausfall der Cloud-Tod; der viel häufigere Fall ist der DALY-artige Teilausfall. Wenn von 10 000 Microsoft-365-Nutzern 3000 eine Stunde nicht arbeiten können, welches SLA ist dann verletzt? Das Site Reliability Engineering hat die Werkzeuge längst parat: Service Level Indicators und Objectives, aus denen ein SLA entstünde, das den tatsächlichen Schaden abbildet. Nur hat kein Provider ein solches SLA im Angebot. Solange die Anbieter ihre Verfügbarkeit selbst binär definieren, bleibt der Patient auf den Behandlungskosten sitzen.
heise online · PDF · Permalink
2022
-
Kubernetes absichern mit Capabilities, SECCOMP und SELinux
Capabilities sind seit Kernel 2.2 die Antwort von Linux auf die Frage, warum ein Prozess Root sein muss, nur um Pakete zu verschicken. Der gemeinsam mit Jan Walther verfasste Artikel erklärt sie am Beispiel von
pingundCAP_NET_RAW: Wo früher das setuid-Bit herhalten musste, genügt heute eine einzelne der gut 40 Fähigkeiten des Kernels. Docker und containerd erlauben Containern standardmäßig unter anderem CHOWN, KILL, MKNOD und SETUID, wofür es bei Anwendungsdiensten meist keinen Grund gibt. SECCOMP filtert eine Ebene tiefer die Syscalls selbst: Von über 300 verbietet das Docker-Standardprofil gerade 44, ein Apache braucht sechs, rund 250 bleiben einem Angreifer offen. Beim Auditor lässt sich damit ein Ja ankreuzen, viel Sicherheit ist so nicht gewonnen. Der Artikel führt vor, wie Kubernetes die Mechanismen über den securityContext einbindet; Werkzeuge wie udica, capable und strace helfen beim Erstellen restriktiver Profile, verlangen aber Testsuiten, die wirklich jeden Syscall einmal auslösen. Kommerzielle Produkte lernen Profile durch Beobachtung, kosten dafür Geld und binden an den Hersteller. Wer die Schutzfunktionen ausreizen will, kommt an einer Automatisierung in der CI/CD nicht vorbei. Das Fazit fällt eindeutig aus: Zusammen mit cgroups ermöglicht dieses Triumvirat eine Absicherung weit über das sonst Übliche hinaus. Ohne präzise Profile bringen die Mechanismen allerdings keinen Nutzen, und Fehler gehen schnell zulasten der Verfügbarkeit.heise online · PDF · Permalink
-
Kubernetes absichern, Teil 1: Werkzeuge in der K8s-Umgebung für mehr Sicherheit
Wer Container sagt, meint fast immer Kubernetes, und wer Kubernetes sagt, meint fast immer eine Distribution, on-premises wie in der Cloud. Der Auftakt der dreiteiligen Tutorialserie räumt mit einem Missverständnis auf: K8s-Umgebungen sind nicht per se das größere Risiko, sie haben gegenüber der Legacy-IT konzeptionelle Vorteile. Ein frisch installierter Vanilla-Cluster ist allerdings erst einmal unsicher, selbst RBAC muss man aktivieren und um einen vorgeschalteten Authentifizierungsdienst ergänzen. Als Maßstab der Härtung dienen die BSI-Bausteine SYS.1.6 Containerisierung und APP.4.4 Kubernetes, die der Autor initiiert und geschrieben hat, ergänzt um CIS-Benchmark, NSA-Härtungsguide, NIST 800-190 und die OWASP Kubernetes Top Ten. Der Artikel arbeitet die Pflichtthemen als Grundkurs ab: Richtlinien für Images und Container, durchgesetzt mit Admission Controllern wie Open Policy Agent oder Kyverno; Separierung der Netze und Mikrosegmentierung mit CNIs wie Calico oder Cilium; beim Verwundbarkeitsmanagement das Verbot von Images mit Schwachstellen ab CVSS 8. Die wichtigste Maßnahme überhaupt ist der Tokenschutz: Kubernetes speichert Token unverschlüsselt im etcd, das Secrets Management ist der Single Point of Hackability. Für die Angriffserkennung reicht Prometheus nicht, SYS.1.6.A7 fordert persistente Protokolle für ein SIEM oder SOAR. Das Fazit: Container in Kubernetes können den Betrieb erheblich sicherer machen als die traditionelle IT, aber das erfordert zusätzliche Werkzeuge und möglichst viel Automatisierung.
heise online · PDF · Permalink
-
Drei Fragen und Antworten: Was kann man gegen unsichere Kubernetes-Cluster tun?
Interview zur iX-Titelstrecke 12/2022, geführt von Jonas Volkert; Christoph Puppe ist hier der Befragte. Warum kann der Betrieb über Kubernetes sicherer sein als traditionelle IT? Container sind zunächst ein Paketierungswerkzeug, mit den Namespaces im Kernel und den Limits der cgroups aber auch eine Sicherheitsbarriere in der Tradition von chroot und den Jails unter BSD. Wo das BSI früher einen Dienst pro Server forderte, gibt es heute einen Dienst pro Pod, automatisch überwacht und neu gestartet. Klar gesagt wird auch: Ein frisch implementierter Cluster ist erst einmal sehr unsicher, erst die Parametrisierung von IAM über Netzrichtlinien bis zur Überwachung bringt den Vorsprung. Einen eigenen Plan brauchen Admins nicht: Empfohlen werden die Grundschutz-Bausteine SYS.1.6 Containerisierung und APP.4.4 Kubernetes, die der Befragte selbst schreiben durfte, ergänzt um den CIS-Benchmark mit seinen extrem detaillierten Konfigurationsvorgaben. Die Kernel-Mechanismen Capabilities, SECCOMP und SELinux könnten viele Angriffe verhindern, doch kaum jemand nutzt sie, weil ein zu enges Profil erlaubte Prozesse beendet; Automatisierung und solide Tests sind die Chance auf restriktive Profile je Container, kommerzielle Cloud Workload Protection Platforms erlernen sie durch Beobachtung. Die Kernaussage: Mit den richtigen Maßnahmen ist eine mit K8s verwaltete Container-Infrastruktur der traditionellen IT auch in puncto Security überlegen, aber geschenkt bekommt man diesen Vorsprung nicht.
heise online · PDF · Permalink
-
Organisationen in der Cloud
Mit einzelnen Accounts fing es bei AWS an, aber sobald Hunderte Administratoren Tausende Projekte verwalten, ist dieses Modell komplett überfordert; niemand überblickt mehr, wer welche Accounts hat und was sie kosten. Der Artikel vergleicht, wie die drei Hyperscaler Organisationsstrukturen abbilden. Azure hat aus den Erfahrungen mit dem Active Directory gelernt: Jeder Tenant bringt ein Azure AD mit, darunter ein Baum aus bis zu sechs Ebenen von Management Groups, Subscriptions und Resource Groups mit Richtlinien, die Verstöße melden, korrigieren oder verhindern. Die Empfehlung des Autors: administrative Benutzer als Cloud-native Accounts mit MFA und am besten FIDO2 führen, nicht über ein Single-Tier-On-Premises-AD. AWS bietet Organisationen seit 2017 an, doch die Integration ist unvollständig: Die Org ist nicht Inhaber der Ressourcen, wichtige Policies sind nicht standardmäßig aktiv, und die Übersicht über alle Ressourcen in allen Regionen fehlt; das Wort Legacy-Cloud wäre vielleicht übertrieben, liegt aber nahe. Googles Cloud Identity erfordert eine eigene Domain, und wer deren DNS kontrolliert, kann die Organisation übernehmen. Das Urteil fällt deutlich aus: Azure hat den Goldstandard der Cloud-Verwaltung geschaffen. Hätte es nicht gefühlt jeden Monat eine schwerwiegende Verwundbarkeit in der Verwaltungsschicht wie OmiGod, läge es klar in Führung; so bleibt der Komfort, aber auch ein getrübtes Bild.
-
Datenschutz versus Sicherheit: Ab wann Sie TLS-Verbindungen aufbrechen sollten
Malware, Schadsoftware, Ransomware sind die drei apokalyptischen Reiter der IT, und täglich grüßt der Sicherheitsvorfall. Laut Verizon Breach Report 2021 spielt Malware in mehr als 80 Prozent der Sicherheitsvorfälle eine Rolle und kommt fast immer per TLS-verschlüsseltem Download ins Unternehmen. Das BSI fordert deshalb in NET.3.2.A21 die temporäre Entschlüsselung auf dem Web-Proxy, dazu NET.3.2.A28 und DER.1.A10; die DSGVO verlangt in Artikel 32 den Schutz der Daten. Beim Aufbrechen werden aber auch personenbezogene Daten sichtbar. Der mit dem Juristen Stefan Hessel verfasste Artikel zeichnet die Rechtslage nach: Das neue TTDSG zählt Arbeitgeber nicht mehr zu den Verpflichteten des Fernmeldegeheimnisses, damit bleibt die DSGVO, und das berechtigte Interesse an der IT-Sicherheit liefert gute Argumente, besonders wenn Privatnutzung untersagt ist; sonst schaffen Einwilligung oder Betriebsvereinbarung Rechtssicherheit. Zugang zu den Proxy-Protokollen bekommt nur ein kleiner Personenkreis, Auswertungen laufen nur mit Betriebsrat und Datenschutzbeauftragtem. Technisch erzwingen Paketfilter den zentralen Proxy, der mit eigenem Wurzelzertifikat temporäre Zertifikate ausstellt; Apps mit Certificate Pinning erzwingen Ausnahmen. Das Fazit ist eindeutig: Downloads auch in TLS-Verbindungen auf Schadsoftware zu untersuchen ist eine Notwendigkeit, und wer darauf verzichtet, betreibt gemäß KonTraG mangelhafte Risikovorsorge. Wird der Datenschutz der Mitarbeiter beachtet, lässt sich die Inspektion DSGVO- und BSI-konform betreiben.
heise online · PDF · Permalink
-
Open-Source-Plattform für Containersicherheit: NeuVector Cloud Workload Security
Eine Cloud Workload Protection Platform überwacht und schützt Container in Kubernetes-Umgebungen. Bislang gab es hier ausschließlich proprietäre Produkte; Sysdig, Palo Alto und Aqua Security veröffentlichen zwar einzelne Werkzeuge wie Falco oder Trivy als Open Source, aber nie die ganze Plattform. SUSE hat NeuVector nach der Übernahme komplett unter die Apache-2.0-Lizenz gestellt. Die 130 Millionen US-Dollar Kaufpreis wirken dabei fast wie ein Schnäppchen: Aqua Security und Sysdig werden mit jeweils über einer Milliarde US-Dollar bewertet. Fachlich hat NeuVector eine besondere Stärke bei der Sichtbarkeit des Datenverkehrs zwischen den Pods: Als einziges Produkt zeichnet es einzelne Verbindungen auf und liefert neben Mikrosegmentierung auch Netzwerk-Mapping und Deep Packet Inspection. Regelwerke erstellt es selbstlernend aus dem beobachteten Verhalten der Container, integrierbar in die CI/CD; die SECCOMP-, SELinux- und Network-Policy-Pflege der freien Konkurrenten müsste die Anwendungsentwicklung selbst leisten, was erfahrungsgemäß kaum jemand tut. Für Bundesbehörden wandelt sich NeuVector mit einem Federstreich zum CWPP mit der höchsten Compliance gegenüber den OSS-Forderungen des IT-Planungsrats. Ob die Open-Source-Wette neue Entwickler anzieht, müssen die GitHub-Insights erst zeigen. Das Urteil: eine konkurrenzfähige Open-Source-Alternative in einem Markt, der bis dahin keine hatte, und für SUSE ein guter Schachzug.
heise online · iX 3/2022 · PDF · Permalink
-
BSI-Grundschutz-Kompendium 2022: Neue Bausteine, schlankere Struktur
Periodisch veröffentlicht das BSI sein IT-Grundschutz-Kompendium; die Edition 2022 bringt neben 14 stark überarbeiteten Bausteinen sieben neue, darunter APP.4.4 Kubernetes und SYS.1.6 Containerisierung, deren Entstehung der Autor selbst begleitet hat, außerdem drei Managementthemen und mit IND.3.2 Fernwartung im industriellen Umfeld mehr Industrie 4.0. Auch die Struktur wandelt sich: Im Zuge der Modularisierung haben die Grundschutzautoren etwa die Anforderungen für die sichere Anmeldung der Administratoren und die Protokollierung aus den System-Bausteinen entfernt; stattdessen gelten die darüberliegenden Schichten. Das macht den Grundschutz schlanker, verlagert aber Arbeit zu den Auditoren, die bei jedem System die organisationsweit geltenden Regelungen mitdenken müssen; bewährt hat sich eine Liste der bei allen Systemen zu prüfenden Anforderungen. Eine echte Verbesserung ist die Verfügbarkeit der Bausteine als XML neben dem PDF, was Automatisierung rund um das eigene Sicherheitsmanagement erst praktikabel macht. Insgesamt lebt der BSI-Grundschutz auch fast 30 Jahre nach der ersten Version und unterliegt einer ständigen Weiterentwicklung. Wünschenswert wäre eine Beteiligung der Community mit modernen Werkzeugen wie Git, statt die Rückmeldungen der Anwender durch Kommentierungsrunden und Redaktionszyklen zu schleusen.
heise online · PDF · Permalink
-
Multi-Cloud: Cloud-Dienste effizient, sicher und zuverlässig vernetzen
Wer Multi-Cloud nutzt, kommt um die Vernetzung zwischen den Clouds nicht herum, und die Netzarchitektur entscheidet über Performance, Sicherheit und Kosten. Der OnRamp heißt bei jedem Anbieter anders: Azure ExpressRoute, AWS Direct Connect, GCP Cloud Interconnect; Carrier wie Equinix, MegaPort oder PacketFabric betreiben eigene Zugänge. Der entscheidende Unterschied liegt in der Abrechnung: SDCI- und NaaS-Anbieter berechnen Egress nach Bandbreite als monatliches Fixum, die Hyperscaler nach Volumen; bei GCP kostet ein Gigabyte zwischen Kontinenten bereits 0,08 US-Dollar. Die Alternative sind IPsec-Meshes mit virtuellen Routern in den VPCs, selbst gebaut oder kommerziell wie Aviatrix, das die Durchsatzgrenzen der CSP umgeht, dafür aber Service-Accounts mit teils weitreichenden Rechten braucht. Bei der Bandbreitenplanung stecken die Fallen im Detail: Azure ExpressRoute schafft bis zu 100 GBit/s, die größte VM aber nur 40 GBit/s; bei AWS liefert Direct Connect maximal 10 GBit/s, während die schnellste Instanz 100 GBit/s beherrscht; und die IPsec-Gateways der CSP sind auf 1,25 GBit/s limitiert. Öffentlich erreichbar sein dürfen nur die Dienste, die das unbedingt benötigen, alles andere gehört in VPCs und vNETs hinter Firewalls. Das Fazit mahnt zur Vorsicht bei der Physik: Die OnRamps sind wie früher MPLS erst einmal unverschlüsselt, weshalb über den physischen Verbindungen ein IPsec-Overlay liegen sollte.
heise online · iX 2/2022 · PDF · Permalink
2021
-
Cloud-Dienste: Anspruch und Realität von Cloud-Service-Brokern
Ein Multi-Cloud-Ansatz kann helfen, einen Vendor Lock-in zu vermeiden, und Cloud-Service-Broker waren die Idee, Cloud-Dienste als Value-added Reseller in einem eigenen Kiosk zusammenzufassen. Fast zehn Jahre später ist von den Hoffnungen wenig übrig: Die Angebote entwickeln sich zu schnell, und so groß ist kein Broker geworden, dass er Mengenrabatte hätte weitergeben können. Marktstudien sehen den globalen Markt zwar bei über 5 Milliarden US-Dollar, doch dort verdienen Beratungshäuser und Werkzeughersteller, keine echten Zwischenhändler. Der Artikel sortiert das Feld: Terraform hat sich fürs Einrichten und Löschen von Diensten etabliert, die Registry zählte 1437 Provider; bei Protokollierung und Vorfallsbehandlung fehlt dagegen jeder gemeinsame Standard. Die Generalisten des Multi-Cloud-Managements bündeln IaaS, Datenbanken, Storage und Kubernetes unter einer Oberfläche, scheitern aber an allem, womit sich die Anbieter wirklich differenzieren: KI-APIs, Data Warehousing, DevOps-Ketten und Branchendienste bleiben außen vor. Google Anthos, AWS Outpost und Azure Arc drehen den Spieß um und verwalten die eigene On-Premises-IT mit den Werkzeugen der Cloud. Das Fazit: Der Trend geht klar weg vom Cloud-Brokerage hin zur gemeinsamen Verwaltung mehrerer Anbieter mit Software, aber ohne Zwischenhändler. Multi-Cloud-Management entschärft den Lock-in nur bei den Standarddiensten; ob die spezialisierten Angebote die feste Bindung wert sind, muss jede Firma selbst entscheiden.
heise online · iX 11/2021 · PDF · Permalink
-
IT-Grundschutz: BSI-Anforderungen für Container und Kubernetes
Nach zwei Community Drafts erschien der bisherige Container-Baustein aufgeteilt erneut zur öffentlichen Kommentierung, als Vorstufe zur Edition 2022: SYS.1.6 Containerisierung für Container und Runtimes, APP.4.4 Kubernetes für das Management des Containerbetriebs. Die Aufteilung war nötig, weil sich Kubernetes als Betriebswerkzeug durchgesetzt hat, Container aber auch unter Windows, AIX oder z/OS laufen. Wer Kubernetes einsetzt, muss beide Bausteine beachten; das BSI hat darauf geachtet, dass sie sich nicht überschneiden. In den 27 Anforderungen des SYS.1.6 und den 21 des APP.4.4 finden sich Konkretisierungen: Planung von der Verwaltung (SYS.1.6.A2) bis zum Berechtigungsmanagement (APP.4.4.A1 bis A3), Trennung von Verwaltungs- und Wirknetzen (SYS.1.6.A5, APP.4.4.A7), erhöht Mikrosegmentierung (APP.4.4.A18). Alle Vorgaben für Images liegen jetzt ausschließlich im Container-Baustein; der Kubernetes-Baustein regelt Konfigurationsdateien, Automatisierung, Service-Accounts und für hohen Schutzbedarf Hochverfügbarkeit und verschlüsselte Datenhaltung. Besonders das Thema Cluster hat durch die Aufteilung gewonnen: Fast alle erhöhten Anforderungen des APP.4.4 betreffen die Sicherheit der Nodes. Der Autor war an Initiierung und Entwicklung beteiligt, benennt aber auch die Grenzen: Es sind Anforderungen, keine Konfigurationsanleitungen, die Umsetzung bleibt Arbeit. Der Zeitpunkt scheint dennoch gut gewählt, denn die Basistechnologien konsolidieren sich gerade, und so behalten die Bausteine hoffentlich länger ihre Relevanz.
heise online · iX 10/2021 · PDF · Permalink
-
Cloud-Sicherheit: Cloud Security Operations Center im Vergleich
„Sicherheit ist kein Projekt, sondern ein Prozess“ sagt sich leicht, die Umsetzung im IT-Alltag ist es nicht. Gartner nennt die kontinuierliche Überwachung der Cloud-Infrastruktur Cloud Security Posture Management; der Artikel vergleicht AWS Security Hub, Azure Security Center und Googles Security Command Center. Bei AWS merkt man das Alter des Marktführers: Die Dienste von GuardDuty bis Detective sind ausgereift, aber der Hub reagiert nur nachträglich, statt verbotene Einstellungen zu verhindern, und die Regionalität erzwingt Aggregatoren. Jede Regel ist eine Lambdafunktion und kostet pro Bewertung 0,1 US-Cent; das AWS Security Finding Format ist immerhin eine vorbildliche Grundlage für Partnerintegrationen. Azure bringt mit Abstand die meisten Funktionen kostenlos mit, kann als einziges Produkt Richtlinien schon vorab durchsetzen und überwacht auch AWS und GCP; der Defender kostet rund zwei Euro-Cent pro Ressource und Stunde. Google stellte keinen Zugang zum Premiumangebot ab mindestens 25 000 US-Dollar bereit; die getestete Basisversion hinterließ einen unfertigen Eindruck, mit Security Hub und Security Center kann der SCC bei Weitem nicht mithalten. Das Fazit nimmt die Kunden in die Pflicht: Die Cloud erledigt vieles automatisiert zuverlässiger, aber die Verantwortung für Code und Konfiguration bleibt beim Kunden, der diese Werkzeuge auch nutzen muss. Wer maximale Sicherheit braucht, kommt um ein vollständiges CWPP für Container ohnehin nicht herum.
heise online · iX 7/2021 · PDF · Permalink
-
Übersicht Compliance Management: Tools für die Cloud und Schwachstellenscanner
Viele Einbrüche sind die Folge falscher Systemparameter, und bei Cloud-Diensten reicht ein falscher Klick, um alle Daten zu veröffentlichen. Ohne leistungsfähige Werkzeuge zum Compliance Management ist der Überblick nicht zu bekommen. Für den Test fragte der Verlag bei rund zwei Dutzend Herstellern Lizenzen an; geliefert haben Aqua Security, Trend Micro, Palo Alto Networks, Rapid7, Runecast und Sysdig. Open Source spielt in diesem Markt praktisch keine Rolle. Als Testumgebung dienten ein AWS-Projekt mit absichtlich öffentlichem S3-Bucket, ein GKE-Cluster mit GitLab und ein Azure-Tenant mit AD, zwei Wochen lang beobachtet. Palo Altos Prisma Cloud überzeugte mit automatisierter Installation per Terraform, fand den öffentlichen Bucket und behob den Fehler nach einem Klick, scannt als einziges Produkt auch Alibaba Cloud; der Preis ist die übliche SaaS-Bindung. Runecast punktet mit einzigartiger Tiefe bei VMware und ist der einzige Kandidat mit Compliance-Check gegen das BSI-Grundschutz-Kompendium, bleibt bei den Cloud-Anbietern aber auf AWS beschränkt. Cavirin scheiterte im Test kommentarlos am GCP-Scan, und die Schwachstellenscanner-Veteranen Tenable, Qualys und Rapid7 tun sich mit der Cloud teils noch schwer. Das Fazit destilliert eine einfache Regel: Je spezialisierter ein Tool, desto besser integriert es sich in seine Umgebung und desto schlechter deckt es die anderen ab. Zehn Seiten Marktübersicht mit Vergleichstabellen.
heise online · iX 1/2021 · PDF · Permalink
2020
-
Sicherheit für Container
Agile IT und Container bringen Tempo, aber was dauert und kostet, wird gern vernachlässigt: die Sicherheit. Der Artikel beschreibt, wie DevSecOps und Site Reliability Engineering die Absicherung von Anfang an in die agile Kultur einbauen. Die Grundpfeiler sind Standardisierung und Automatisierung, automatisierte Scans von Code und Images in den Pipelines, IAM und RBAC auch für Prozesse, Separierung sowie die Fähigkeit, jedes Image und jeden Server umgehend zu patchen. Auch das Monitoring hat sich gewandelt: Früher genügte die Frage, ob ein Prozess läuft, heute messen Service Level Indicator und Objective, ob jede Anfrage korrekt und schnell genug beantwortet wird. Der zweite Teil der Überwachung gilt der Compliance: Betriebsumgebungen bestehen aus vielen Schichten mit Hunderten sicherheitsrelevanter Einstellungen, und wer auch Public Clouds nutzt, müsste Dutzende Oberflächen bedienen. Compliance-Management-Werkzeuge sind in größeren Umgebungen die einzige Chance, den Überblick zu behalten; der Abgleich mit den Benchmarks des Center for Internet Security ist praktisch überall enthalten. Kubernetes übernimmt den gesamten RZ-Betrieb, und dort setzen die Multi-Tools an: Netzwerkregeln überwachen, Verhaltensregeln über SECCOMP, AppArmor oder SELinux durchsetzen, Compliance von Servern, Containern und Kubernetes selbst prüfen. Die besseren Produkte beenden verdächtige Prozesse und sammeln bei Vorfällen automatisch Forensikdaten. Den rechtlichen Rahmen liefern PCI, die KRITIS-Verordnung und das Grundschutz-Kompendium des BSI. Das Fazit fällt eindeutig aus: Mit Containern steigt die Komplexität um Größenordnungen, und ohne automatisiertes Compliance-Monitoring ist die Sicherheit nicht zu halten.
iX 10/2020 · PDF · Permalink
-
Ein Kubernetes, sie zu binden: Orchestrierung im Wandel
Vor sechs Jahren galten Container als die große Revolution, dann kam Kubernetes und sorgte für die größte Zäsur in der IT seit dem Umstieg vom Host auf Windows-Server. OpenShift und Rancher haben ihre Eigenentwicklungen aufgegeben; heute basieren faktisch alle Orchestrierungswerkzeuge auf Kubernetes. Die CNCF listet fast 1400 Einträge mit 14 Billionen US-Dollar Marktwert; ein Cloud-Stack ist die Zukunft der IT. Kubernetes selbst ist ein Kessel Buntes: Netzwerk und Speicher existieren nur als Plug-in-Schnittstellen, die Konfiguration beschreibt einen Wunschzustand, Custom Resource Definitions machen das System beliebig erweiterbar. Der Artikel benennt auch die Kosten dieser neuen Welt: Im Cloud-native-Stack steckt im Ethernet-Frame ein VXLAN-Paket, darin ein IP-Paket, darin noch eines, und die Frage, wo das Netzwerkpaket geblieben ist, kostet auch den Autor manchmal Tage. Der Spruch aus den 1990ern, „Ich werde dich durch ein Shellskript ersetzen“, ist wahr geworden: Kubernetes-Operatoren erledigen die Routineaufgaben, und wer das Tooling nicht durchschaut, verliert den Serverraum. Bei der Sicherheit bleiben die EAL5+-zertifizierten LPARs von IBMs System z der Goldstandard der Trennung; Meltdown, Spectre und RowHammer belegen, dass geteilte Hardware angreifbar ist. SRE ordnet der Text als DevOps done right ein, mit Error-Budgets, die etwa 99,5 Prozent erfolgreiche Anfragen in unter 80 Millisekunden festschreiben. Das Urteil: Kubernetes hat die Führung übernommen und gibt mit drei Monaten Releasezyklus das Tempo vor. Die Innovation belastet den stabilen Betrieb, und in die Köpfe der Mitarbeiter zu investieren, ist wichtiger denn je.
-
GitLab Enterprise Ultimate als DevOps-Toolchain für Entwickler
Schon der Name deutet es an: GitLab bietet den Git-Server, dazu Benutzerverwaltung, Runner, Wiki, Issue Tracker, Container-Registry, Sicherheitsscanner, Multi-Cluster-Management und Monitoring, alles unter einer Oberfläche. Getestet wurde die Enterprise Edition 12.8.1-ee mit Ultimate-Lizenz. Die Installation auf Ubuntu scheiterte an einem Bug im Skript, das Einspielen per Helm auf einem GKE-Cluster war dagegen in unter 30 Minuten erledigt. Die Ultimate-Lizenz liefert die Automatisierung der Codeanalysen: SAST, Dependency-Scanner, DAST, Container-Scans mit Clair, Lizenz-Scan sowie Security- und Compliance-Dashboards. Beim Berechtigungsmanagement folgt GitLab RBAC mit fünf Rollen und ist per OAuth 2 nicht nur Client, sondern selbst Identity Provider; das Einrichten eines FIDO2-Tokens klappte reibungslos. Als Testobjekt diente WordPress 4.8.1 mit 31 gelisteten Verwundbarkeiten; aus gefundenen Problemen erzeugt GitLab automatisch Issues und Merge Requests. Doch genau hier zeigte sich die Schwäche: Die Auto-DevOps-Pipeline brach bei den vier Testprojekten fast immer beim Build oder einer späteren Stage ab, gefundene Schwachstellen tauchten nicht in Dashboards oder Issues auf, und der Support-Call war zum Redaktionsschluss noch offen. Das Fazit bleibt trotzdem wohlwollend: Für fast jede Einzelfunktion existiert ein Spezialwerkzeug mit mehr Tiefe, das dann aber selten gut integriert ist. Wer Anwendungen in einer Oberfläche schreiben, verwalten, deployen und überwachen will, ist mit GitLab sehr gut bedient. Monatlich 99 US-Dollar pro User sind nicht billig, doch der Wegfall des ständigen Medienbruchs eines Dutzends Einzelwerkzeuge dürfte das in den meisten Fällen ausgleichen.
heise online · iX 6/2020 · PDF · Permalink
-
IT-Sicherheit: Neuer Entwurf des BSI-Bausteins zu Containern
Das IT-Grundschutz-Kompendium enthält Anforderungen, die Bundesbehörden einhalten müssen. Nach zahlreichen Kommentaren zum ersten Entwurf von 2018 legte das BSI den Container-Baustein SYS.1.6 als überarbeiteten Public Draft für die Edition 2021 vor. CI/CD und Orchestrierung rückten in den Fokus und brachten sieben neue Anforderungen. Wie alle Bausteine seit 2017 gliedert er sich in Basis, Standard und erhöhten Schutzbedarf, dazu kommen die 47 elementaren Gefährdungen. Container-spezifisch sind vor allem Schwachstellen in Images, ungesicherte administrative Zugänge, fehlende Persistenz und neu der Ausbruch aus einem Container. Grundlage bleiben die Server-Bausteine, ergänzt um „SYS.1.6.A4 Härtung des Host-Systems" und „SYS.1.6.A7 Härtung der Software im Container". Die Planungsanforderungen verlangen, den Separierungsgrad am eigenen Schutzbedarf festzumachen, denn seit Rowhammer, Meltdown und Spectre sollte jedem klar sein, dass geteilte Hardware immer ein Risiko bleibt. „SYS.1.6.A15 Unveränderlichkeit der Container" und „SYS.1.6.A12 Nur eine Anwendung bzw. ein Dienst pro Container" erschweren das Ausnutzen von Schwachstellen erheblich; wer SECCOMP, SELinux und AppArmor ausschöpft, muss den Vergleich mit einem Typ-1-Hypervisor nicht mehr fürchten. Für erhöhten Schutzbedarf fordert „SYS.1.6.A33 Mikro-Segmentierung von Containern" die regelbasierte Steuerung per mTLS im Service Mesh. Das Urteil: Der Draft deckt Planung, Betrieb und Orchestrierung vollständig ab, ist aber noch nicht bindend, und die Umsetzungshinweise fehlen weiterhin; die finale Entscheidung über die angemessene Separierung bleibt beim Inhaber der Daten.
heise online · iX 5/2020 · PDF · Permalink
2019
-
Mit IBMs z15 und z/OS 2.4: zCX Container sicherer betreiben
Seit September 2019 liefert IBM die Mainframe-Generation z15 mit z/OS 2.4 aus, und mit den Container Extensions (zCX) laufen Docker-Container direkt neben Middleware wie CICS, IMS und DB2. Die Hardware liefert Argumente: bis zu 40 TByte Speicher, 190 Cores, erstmals Standard-19-Zoll-Racks, und IBM gibt an, dass eine z15 bis zu 2,4 Millionen Container gleichzeitig verkraftet. Anwendungen müssen für s390x kompiliert sein; auf dem Docker Hub fanden sich über 2800 passende Images, für Java, Python oder JavaScript genügen die vorhandenen Base-Images. Für den Containerbetrieb gibt es zwei Wege: ein vollwertiges Linux on Z mit Docker oder zCX, eine auf den reinen Containerbetrieb reduzierte Umgebung in z/OS. Zur Orchestrierung stand anfangs nur Swarm bereit. Die eigentliche Trumpfkarte ist die Separierung: Der seit 1972 gereifte Hypervisor PR/SM trennt bis zu 80 LPARs mit EAL5+-zertifizierter Isolation, deutlich über der in der deutschen Verschlusssachenanordnung geforderten EAL4+-Zertifizierung. Mit HyperSwap und Sysplex überstehen LPARs sogar die Abschaltung eines ganzen Standorts. Der Artikel benennt auch den Kulturkonflikt: System Z steht für Zero Downtime durch redundante Hardware, Container gehen vom jederzeitigen Ausfall billiger Hardware aus; wer die Hochverfügbarkeitsoptionen von z/OS nutzt, beraubt die Orchestrierung einer ihrer Hauptaufgaben. Das Fazit: Performance, Georedundanz und zertifizierte Mandantentrennung sind starke Argumente für den Mainframe als Containerplattform, doch die Umstellungen beim Betrieb dürften abschreckend wirken, und die abweichende Endianness bleibt zu beachten.
heise online · iX 1/2020 · PDF · Permalink
-
Kammer der Schlüssel: Key Management in Public Clouds
Verschlüsselung ist wie Magie: Richtig angewendet soll sie alles sicher machen, auch in der öffentlichen Cloud. Doch jede Verschlüsselung ist nur so gut wie der Schutz der Schlüssel, und den besten bieten Hardwaresicherheitsmodule (HSM): gegen Manipulation gesicherte Hardware, die Schlüssel erzeugt, verwahrt und signiert. Der Artikel vergleicht die Angebote von AWS, Google, Microsoft, Equinix, Thales, Townsend und Utimaco anhand von Cloud-HSM, Bring Your Own Key, APIs wie PKCS #11 und KMIP, Protokollierung und Zertifizierung. Die Betriebsmodelle unterscheiden sich deutlich: AWS integriert HSM-Partitionen in seinen Key Management Service und erlaubt 3500 Schlüssel pro Cluster, Google reserviert Mandanten auf Cavium-HSMs, Azure Key Vault erreicht FIPS 140-2 Level 2 und erst mit dem Dedicated-HSM Level 3. Die Grenzen benennt der Text ebenso deutlich: Das Quorum-Prinzip der On-Premises-HSMs beherrschen die Cloud-Varianten meist nicht, keines der Angebote war nach der deutschen VSA zertifiziert, und ob Daten im Speicher des Anbieters wirklich verschlüsselt lagen, kann der Kunde prinzipiell nicht nachweisen; er muss hoffen, dass die C5-Auditoren verifizieren statt abzuschreiben. Wichtig bleibt der Vertrauensanker: Der Signaturschlüssel einer eigenen Zertifizierungsstelle entsteht im HSM oder wandert per BYOK verschlüsselt dorthin und verlässt es nie. Das Fazit: Ein Cloud-HSM schafft eine zentrale Schlüsselverwaltung mit klaren Prozessen und ermöglicht den Cloud-Einsatz oft erst, weil viele Sicherheitsstandards den Schutzbedarf verschlüsselter Daten deutlich reduzieren. Wer die Kontrolle behalten will, muss Authentifizierung und Schlüsselverwaltung regelmäßig kontrollieren.
-
Virtualisierung: Tools zur Absicherung von Containern
Kernel-Exploits, Denial of Service, Breakouts: Container sind praktisch, bieten aber auch Angriffsfläche. Der klassische Sysadmin-Werkzeugkoffer kennt klare Kategorien wie Firewall und Virenscanner; bei Containern verschwimmen diese Grenzen, weil sich die Funktionen der Produkte stark überschneiden. Der Artikel sortiert den Markt in Image Assurance, Netzwerkwerkzeuge, IAM, Container-Härtung und Compliance-Checks, mit Vergleichstabellen. Grundlage jeder Bewertung ist das Zusammenspiel mit Kubernetes: Nur die Orchestrierung entscheidet, ob ein Image startet, weshalb Scanner idealerweise als Admission Controller andocken; eine Break-Glass-Funktion für den Notfall ist Pflicht. Zu den Image-Scannern zählen Anchore, CoreOS Clair, Grafeas mit Kritis und OpenSCAP; der Abgleich läuft gegen die öffentlichen CVE-Datenbanken, und die Malware-Suche einiger Produkte ist mit Vorsicht zu genießen, da die Erkennungsraten nicht an klassische Virenscanner heranreichen. Bei den Netzwerk-Plug-ins reicht die Spanne von Istio, das als Service Mesh mit mTLS nur authentifizierte Verbindungen zulässt, aber nur HTTP behandelt, über Calico mit BGP-Routing und Cilium mit BPF-Filtern bis zu VMwares NSX-T mit verteilter Firewall und echter Mandantenfähigkeit, dafür Closed Source. Gegen Zugangsdaten im Code helfen Secrets-Manager wie HashiCorp Vault oder CyberArk. Die kommerziellen Multitools TwistLock, AquaSec und NeuVector kombinieren Konfigurationsprüfung, Firewall und Image-Scan und lernen Profile selbsttätig. Das Fazit: Eine gut abgesicherte Umgebung braucht für jede Kategorie ein Produkt. Die eine Lösung für alles gibt es nicht; die beste Absicherung liefert die Kombination.
heise online · iX 4/2019 · PDF · Permalink
-
Serverstrukturen in Unternehmen: lokal vorhalten oder in die Cloud verlagern?
Für Unternehmen gibt es gute Gründe, Daten auf einem Server in den eigenen vier Wänden zu lagern: der mangelnde Breitbandausbau und die Sorge, dass Daten in der Cloud in fremde Hände geraten. Der Artikel nimmt beide Sorgen ernst und rechnet sie gegen die Realität: Von Feuer, Wasser und Luft bis zum Angriff über die DSL-Leitung drohen einem Abteilungsserver dieselben Gefahren wie einem Cloud-Server, und für kleine Firmen ist er das Nest, in dem sämtliche Eier liegen. Sobald er selbst Dienste ins Internet stellt, ist er genauso angreifbar, nur dass die Cloud-Anbieter ganze Abteilungen für Absicherung und Überwachung beschäftigen, denn Einbrüche zu bemerken ist die Kunst, an der selbst Große scheitern. Zwei Risiken kennt nur die Cloud: das zufällige Mitopfer eines Angriffs auf einen anderen Kunden zu werden und die exponierte Authentifizierung; erzwungene Zwei-Faktor-Authentifizierung ist die Antwort, Zertifikate wie ISO 27001 nach Grundschutz und der C5-Katalog helfen bei der Anbieterauswahl. Den größten Nutzwert liefert der Leitfaden entlang des Grundschutz-Kompendiums, von „INF.1 Allgemeines Gebäude" über „NET.3.2 Firewall" und „SYS.1.1 Allgemeiner Server" bis „CON.3 Datensicherungskonzept". Die einfachste Variante bleibt die Wechselplatte, die wöchentlich in ein Schließfach wandert. Das Urteil ist unbequem für beide Lager: Wer seine IT selbst betreibt, muss auch selbst für die Sicherheit sorgen. Die Cloud löst das Betriebsproblem, nicht das Verantwortungsproblem, und die letzte Entscheidung liegt bei der Geschäftsführung.
heise online · iX 1/2019 · PDF · Permalink
2018
-
Container-Sicherheit: Entwurf des BSI-Bausteins für das Grundschutz-Kompendium
Behörden und Firmen in Deutschland setzen Container strategisch ein, weshalb das BSI den Entwurf eines Bausteins für das Grundschutz-Kompendium veröffentlicht hat, den Nutzer kommentieren können, bevor er für Zertifizierungen relevant wird. Wie alle Bausteine seit August 2017 gliedert er sich in Basis, Standard und Erhöht, dazu gehört die Kreuzreferenztabelle zu den 47 elementaren Risiken. Im Prinzip sind Container nur chroot-Umgebungen oder Jails; der Vergleich mit der Java-Sandbox hinkt etwas, ist aber absichtlich gewählt, denn besonders diese Sandbox war eher ein Sieb. Die Basis der Absicherung bilden die Container-Hosts, weshalb immer die Server-Bausteine gelten, ergänzt um „SYS.1.6.A3 Härtung des Host-Systems" und „SYS.1.6.A4 Härtung der Software im Container". An der angemessenen Separierung scheiden sich die Geister: Spätestens seit Rowhammer, Meltdown und Spectre sollte jedem klar sein, dass geteilte Hardware ein Risiko birgt, weshalb die Planungsanforderungen die Entscheidung an den Schutzbedarf binden und der Baustein klarstellt, dass Container Virtualisierung und physische Trennung nicht ersetzen. Weitere Anforderungen regeln sichere Images, administrativen Fernzugriff, die Ausführung ohne privilegierten Account und die Speicherung von Zugangsdaten, denn noch immer werden täglich Anwendungen gehackt, weil Passwörter mit dem Code auf GitHub landen. Das Fazit: Der Draft gibt einen belastbaren Ausblick auf den künftig zertifizierungsrelevanten Baustein, ist aber noch nicht bindend. Der Autor hat den Baustein initiiert und am Entwurf maßgeblich mitgewirkt.
heise online · iX 7/2018 · PDF · Permalink
-
IT-Grundschutzkompendium: BSI veröffentlicht Community Draft zu Containern
Auch vor der Bundesverwaltung macht die Containerisierung nicht halt, weshalb das BSI den ersten Entwurf eines Container-Bausteins veröffentlicht hat. Die Umsetzungshinweise fehlen noch, aber die Rohfassung zeigt, wie sich das BSI den Umgang mit Containern vorstellt. Als Community Draft ist der Baustein zur Kommentierung freigegeben und für eine Zertifizierung nach ISO 27001 noch nicht bindend, taugt aber als Vorlage für einen benutzerdefinierten Baustein. Inhaltlich ringt der Entwurf mit der Kernfrage, ob und wie Container die Sicherheit beeinflussen: Einerseits eignen sie sich zur Separierung, andererseits arbeiten alle wie früher chroot und Jails auf demselben Kernel, und nach Rowhammer, Meltdown und Spectre ist die Unsicherheit groß, wann diese Trennung ausreicht. Zugleich lassen sich Syscalls, Ost-West-Datenverkehr und Ressourcenverbrauch gut einschränken. Der Baustein liefert konkrete Anforderungen für Container-Host und Images; die Orchestrierung spart der erste Wurf bewusst aus. Die Meldung ist der Auftakt einer mehrjährigen Serie zu diesem Baustein. Das Fazit fällt nüchtern aus: Erst die Umsetzungshinweise werden klären, wie das BSI die Anforderungen umgesetzt sehen möchte. Wer Container in regulierten Umgebungen betreibt, tut gut daran, die Kommentierungsphase zu nutzen, statt später über fertige Vorgaben zu klagen. Der Autor hat am Entwurf selbst mitgewirkt.
heise online · PDF · Permalink
2017
-
Genauer hinschauen: Site Reliability Engineering präzisiert die Messung der Servicequalität
Eine hohe Verfügbarkeit ist bei wichtigen Diensten unabdingbar, aber ihre Messung ist komplexer als das Zählen von Stillstandsminuten: Eine global verteilte Anwendung kann in den USA funktionieren, während in den Niederlanden der Warenkorb klemmt, oder sie antwortet zwar, liefert aber bei jeder zehnten Anfrage einen Fehler. Googles Site Reliability Engineering misst deshalb nicht, ob ein Dienst antwortet, sondern wie viele Anfragen eine gültige Antwort erhalten: Beim Webserver zählen HTTP 200 und 304 als Erfolg, alle 40X-, 50X- und ausgebliebenen Antworten als Fehler; ein vorgelagerter Proxy erfasst sämtliche Requests, ohne die Anwendung zu belasten. SRE zerlegt das übliche SLA in seine Bestandteile: Der Service Level Indicator benennt den Messwert, das Service Level Objective das Ziel, etwa 99,5 Prozent korrekt beantwortete Anfragen und 99 Prozent unter 100 Millisekunden. Das eigentlich Neue ist das Fehlerbudget: 100 Prozent Verfügbarkeit sind weder erreichbar noch nötig, der Abstand zum SLO ist eine Lücke mit Existenzberechtigung, in der der Betrieb Kosten sparen und die Entwicklung neue Features riskieren darf. Weil das Budget pro Anwendung gilt, egal wo der Fehler entstand, versöhnt es Programmierer und Administratoren. Verfügbarkeit ist in Zeiten preiswerter Redundanz eine Messung der Kundenzufriedenheit, und SLI, SLO und Fehlerbudget machen die Qualität der Arbeit von Entwicklern wie Administratoren messbar.
-
Sicher am laufenden Band: Docker-Container und -Hosts überwachen
Früher war „Ich werde dich durch ein Shell-Script ersetzen" eine freundliche Drohung gegenüber Administratoren, heute ist es Arbeitsrealität. DevSecOps erweitert DevOps um die Sicherheit, und der Artikel vergleicht vier Produkte und ein Framework, die Docker-Container und -Hosts über den gesamten Lebenszyklus auf Schwachstellen und Konfigurationsfehler prüfen, mindestens gegen den CIS Benchmark. Entscheidend ist die Einbettung über RESTful APIs, denn das Ziel bleibt, keine manuellen Schritte im Betrieb zu benötigen. Tenable bringt mit fast 20 Jahren Nessus die größte Erfahrung mit, verlangt für den vollen Funktionsumfang aber Agenten auf den Hosts, und die On-Premises-Variante ist stark eingeschränkt. Aqua Security verwaltet signierte Images, erstellt im Lernmodus Firewall-Profile aus dem Netzverkehr und unterbindet Port-Scans und Fork-Bombs; die behaupteten 5 Millionen Schwachstellensignaturen erscheinen allerdings hoch, Erkennungsqualität braucht viele Jahre Einsatz auf vielen Systemen. Twistlock überwacht als einziges Produkt die Kernel-API-Nutzung der Container und kann abweichende Container isolieren, lässt aber die Überwachung der Host-Konfiguration aus. NeuVector konzentriert sich auf Netzwerkverkehr und dynamische Firewall-Regeln auch für den Ost-West-Verkehr, bietet dafür weniger CI/CD-Integration. Wer Chef, Ansible oder Puppet betreibt, kann mit InSpec und dem CIS-Docker-Profil von dev-sec.io Compliance as Code umsetzen. Das Fazit: ein guter Start in die Automatisierung der Sicherheit im automatisierten Betrieb; die Nachfrage trägt mehrere Hersteller, und die großen Namen des Schwachstellenmanagements wie Qualys werden das Segment für sich entdecken.
2016
-
Das Internet der Dinge verstärkt DDoS-Angriffe
Im Herbst 2016 trafen die bis dahin schwersten verteilten Angriffe das DNS: Beim Angriff auf den Dienstleister Dyn am 20. Oktober wurden 1,2 Terabit pro Sekunde gemessen. Ursache war kein neuer Angriffsvektor, sondern schiere Masse: Das Internet der Dinge liefert Botnetze mit bis zu 500.000 Geräten ohne Updates, und weil viele Provider ausgehende Pakete nicht auf plausible Absenderadressen filtern, funktionieren Reflexionsangriffe über DNS, NTP oder SSDP mit Verstärkungsfaktoren bis 1000; ein Tag DDoS kostet auf dem Schwarzmarkt einen dreistelligen Dollarbetrag. Die damals kursierenden Gegenvorschläge, Störerhaftung für Gerätebesitzer und staatliches Zwangsdesinfizieren, seziert der Artikel als durchweg unrealistisch. Was bleibt, ist Vorsorge in Schichten: DDoS-resistente Architektur, Mitigation-Appliances, getrennte Anschlüsse für öffentliche und interne Dienste, Clean-Pipe-Angebote und vor allem die großen Content Delivery Networks mit Peering-Kapazitäten bis 10 Terabit/s; fürs DNS mehrere Server bei unterschiedlichen Anbietern. Und wer selbst Infrastruktur betreibt, darf nicht Mittäter werden: offene Resolver abschalten, Egress-Filter setzen. Der Trend hält an; wer die Verfügbarkeit seiner Angebote schätzt, muss selbst vorsorgen, und die Technik dafür ist verfügbar und bezahlbar.
iX 12/2016 · PDF · Permalink
-
32C3: Weniger Technik, mehr Politik
Kongressbericht vom 32. Chaos Communication Congress unter dem Motto „Gated Communities“; alle 12.500 Karten waren Monate im Voraus weg, und die Eröffnungsrede der Menschenrechtlerin Fatuma Musa Afrah setzte das Zeichen: weniger Technik, mehr Politik. Das fachliche Highlight lieferte Karsten Nohl mit „Shopshifting“: Weil das Hardware Security Module der EC-Karten-Terminals die Prüfsumme Stelle für Stelle kontrolliert und dabei fünf Millisekunden Zeitunterschied entstehen, lässt sich die richtige Prüfziffer in wenigen Versuchen erraten; über eine halbe Million Terminals müssten getauscht werden. Das Satellitennetz Iridium lässt sich mangels Verschlüsselung mit gut 100 Euro Hardware in einer Zelle von 400 Kilometern Radius abhören. Politisch dominierte das Nachbeben des Safe-Harbor-Urteils: Max Schrems zeigte, dass die irische Datenschutzbehörde mit 20 Personen rund 3 Prozent aller Anfragen beantwortete, obwohl das Gesetz 100 Prozent verlangt. Dazu die Landesverrats-Ermittlungen gegen netzpolitik.org und das Wassenaar-Abkommen, das Schwachstelleninformationen zur Cyber-Waffe erklären könnte. Offene Sicherheitsforschung und eine aktive Open-Source-Szene sind keine Folklore, sondern Bürgerschutz.
2014
-
Chaos als Programm: CCC-Jubiläumskongress, NSA und kein Ende
Mit dem 30C3 feierte der Chaos Computer Club das Jubiläum einer Veranstaltung, die als Hackertreffen mit wenigen Hundert Teilnehmern im Eidelstedter Bürgerhaus begann und nun rund 8000 Besucher ins Hamburger Congress Center zog. Im Jahr eins nach Snowden bestimmten die NSA-Enthüllungen das Programm: Glenn Greenwald hielt die Keynote, Annie Machon kündigte einen Hilfsfonds für Whistleblower an, und Jacob Appelbaum präsentierte den NSA-Zugriff auf iPhones, darunter das Injizieren von Schadcode per Funk über mehrere Kilometer Entfernung. Rüdiger Weiß kam zu dem Schluss, dass gute Verschlüsselung weiterhin wirksam schützt, und dass mit Peter Schaar der gerade aus dem Amt geschiedene oberste Datenschützer sprach, zeigt, wie ernst die Politik den Kongress nimmt. Das denkwürdigste technische Detail lieferte FX of Phenoelit: Ein einziges ICMP-Paket bringt Cisco-Router mit einer nicht dokumentierten Ausleitungsfunktion zum Absturz; am eben ausgefallenen Router erkennt man die staatliche Überwachung. Dazu Bedrohungen für Industriesteuerungen, Kunst, Kultur und „Chaos macht Schule". Das Fazit: Der Club hat sich zum Think Tank freiheitlich orientierter Internetbewohner gewandelt, der Kongress von der Technikschau zur politischen Plattform, die ihre eigenen Besucherrekorde bricht.
-
E-Fort: Wie Samsungs KNOX BYOD-Smartphones sichert
Smartphones organisieren Privatleben und Arbeitstag, und dank Bring Your Own Device landen die vertraulichen Daten beider Welten auf demselben Gerät. Container-Apps von SiMKo3 bis BlackBerry 10 teilen einen Schwachpunkt: Eine App ist nur eine App, die dem Betriebssystem vertrauen muss; Malware kann Speicher auslesen oder schlicht einen Screenshot machen. KNOX separiert dagegen mit den SE-Linux-Erweiterungen eines einzigen Android-Kernels Geschäfts- und Privatwelt als getrennte Security-Domains mit Mandatory Access Control; selbst Malware mit Root-Rechten kommt nicht an die Daten der anderen Domain. Die Kette beginnt in der Hardware: ARMs TrustZone bootet einen eigenen Sicherheitskernel, TIMA überwacht den Kernelspeicher auch im laufenden Betrieb. Die Daten verschlüsselt eine FIPS-140-2-zertifizierte AES-256-Implementierung, bis zu fünf VPN-Kanäle laufen gleichzeitig, und das Smartcard-Interface mit Bluetooth-Kartenleser bringt endlich Zwei-Faktor-Authentisierung samt Single Sign-on aufs Smartphone. Über 500 Policies kann eine MDM-Software setzen, deutlich mehr als bei BlackBerry oder iPhone; die Administratoren sehen dabei nur die Daten im Container, die Privatsphäre bleibt gewahrt. Das Fazit: Samsung macht Container sicherer, auf Augenhöhe mit BlackBerry 10 und um einiges besser als andere Android-Varianten oder das iPhone; KNOX wurde als erstes Smartphone seit dem BlackBerry 7 für die Netze des US-Verteidigungsministeriums zertifiziert. So viel Sicherheit in einem preiswerten, weit verbreiteten Gerät gab es bisher nicht zu kaufen.
2013
-
Notfallmanagement mit der Cloud für KMUs
Notfallmanagement ist bei weniger als der Hälfte der deutschen Unternehmen umgesetzt, wegen der Kosten und einer falschen Risikoeinschätzung, so die BSI-Erhebung von 2011. Die Studie, die das BSI 2013 veröffentlichte und die der Autor mit Alexander Papitsch erarbeitete, setzt dort an: Virtualisierung und Cloud wurden bis dahin fast nur als Sparprogramm mit Sicherheitsproblemen diskutiert, ihr unterschätztes Potenzial für kleine und mittlere Unternehmen liegt in Verfügbarkeitsklassen, die sich vorher nur Konzerne leisten konnten. Die Studie übersetzt den als zu komplex empfundenen BSI-Standard 100-4 in ein KMU-taugliches Verfahren: eine verkürzte Business-Impact-Analyse mit vier Auswirkungsklassen entlang des Jahresumsatzes, drei Zeithorizonten und der maximal tolerierbaren Ausfallzeit, ein ausgefülltes Beispielformular liegt im Anhang bei. Drei Szenarien zeigen die Anwendung: das SaaS-Ingenieurbüro, für das der Ausfall des eigenen Gebäudes kein Notfall mehr ist; zwei Virtualisierungsserver in getrennten Räumen mit Schwenk in unter fünf Minuten und verschlüsselten Backups in der Public Cloud; zwei schmalbandig angebundene Standorte, die nachts auf einen gemieteten Cloud-Server spiegeln. Aus heutiger Sicht ist die Studie auch eine Zeitkapsel, Safe Harbor galt noch als tragfähige Rechtsgrundlage. Der Kern aber hält: Wer Notfallmanagement für unbezahlbar hält, hat die Cloud nicht verstanden; nur die Paragrafen muss man austauschen.
2005
-
Löchersuche: All-Purpose-Schwachstellen-Scanner im Test
Zehn Schwachstellenscanner gegen ein heterogenes Testnetz aus 19 Systemen mit Hard- und Software von 1996 bis 2005; NetIQ, Ncircle und Symantec verweigerten die Teilnahme. Jeder Kandidat bekam zwei Läufe, erst mit Standardeinstellungen, dann mit allen Optionen und Zugangsdaten für lokale Tests. Aus 4414 gemeldeten CVEs wurden 1745 CVE/Ziel-Kombinationen extrahiert und jede von Hand bewertet: 787 echte und 509 falsche Funde, 449 unentscheidbar. Bewertet wurde gegen diese Grundwahrheit: Gründlichkeit als Anteil der gefundenen an allen wahren CVEs, Genauigkeit als Anteil der wahren an den eigenen Meldungen. Nessus erreichte 58 Prozent Gründlichkeit bei 75 Prozent Genauigkeit, Qualys Guard lag mit 58 und 76 Prozent gleichauf, Foundstone folgte mit 52 und 71 Prozent. Dahinter wurde es dünn: NeXpose fand nur 23 Prozent, war mit 82 Prozent Genauigkeit aber sehr präzise, und der Internet Scanner von ISS, immerhin dem Erfinder des Verwundbarkeitsscans, kam auf magere 10 Prozent Gründlichkeit. Die Qualitätsbefunde sind ernüchternd: Linux-Lücken auf BSD gemeldet, NT-4-Exploits auf Windows 2003, kaum Plausibilitätsprüfungen, veraltete Tests; der Shadow Security Scanner stufte 55 Prozent seiner Meldungen als hochkritisch ein. Die Preisspanne reichte von 850 Euro bis 180 000 Euro. Kein Scanner fand alle CVEs, und wer alle Funde behoben hat, ist noch lange nicht sicher; der Einsatz lohnt trotzdem, weil schnelles Erheben und Beseitigen der Schwachstellen die Sicherheit signifikant steigert. Der vollständige englische Text erschien im Februar 2006 als Auftakt des Vulnerability Assessment Wiki.
2004 bis 2012
Die frühen Jahrgänge. Der Volltext liegt bei heise hinter der Bezahlschranke, die Abstracts hier sind aus den Originalartikeln geschrieben. Wer die Themen der Reihe nach liest, sieht die Linie: Schwachstellensuche und Penetrationstests am Anfang, dann die Auswertung der Meldungen, die daraus entstehen, und schließlich Mobilgeräte und Virtualisierung.
-
Geschützte Kommunikation: sichere Smartphones, Konzepte und Produkte
Marktübersicht über Krypto-Smartphones für Umgebungen, in denen Mobile Device Management nicht mehr reicht: SiMKo von T-Systems, das CryptoPhone der GSMK, SecuVOICE, Crypto Mobile HC-9100, Omnisec 230 und das TopSec Mobile von Rohde & Schwarz. Das gemeinsame Bauprinzip: Sämtliche Daten inklusive der Gespräche werden mit einem vollständig vom Anwender kontrollierten Schlüssel codiert, den ein Krypto-Chip oder eine Smartcard schützt; alle Produkte sind modifizierte Serienhardware zu Preisen um 1500 Euro. Selbst BlackBerry fällt durch, weil alle Daten über eigene Server im Ausland laufen und die GSM-Verschlüsselung nachweislich nicht reicht. SiMKo hatte als einziges die BSI-Freigabe für „VS – Nur für den Dienstgebrauch“, litt aber unter der kastrierten Benutzerumgebung ohne WLAN, GPS und Kamera, weshalb erst rund 5000 Geräte ausgeliefert waren. Die GSMK legte als einziger Hersteller Software und Algorithmen offen und ließ jeden nach Schwachstellen suchen. Rohde & Schwarz koppelt ein eigenes Krypto-Gerät per Bluetooth ans Smartphone, sodass Schlüssel und Klartext das Telefon nie erreichen. Das Fazit sortiert nach Einsatzprofil statt nach Sieger: Wer mit deutschen Behörden arbeitet, braucht die Zulassung; international offene Anbieter wie GSMK und die Schweizer sind die Alternative. Die strukturelle Schwäche: verschlüsselt telefonieren ging fast nur mit Geräten desselben Herstellers.
-
Disput und Wahl: Adhocracy und Liquid Feedback
Zwei deutsche Softwaresysteme für Liquid Democracy im Vergleich: Adhocracy vom Liquid Democracy e.V. und Liquid Feedback der Public Software Group, beide im Umfeld von CCC und Piratenpartei entstanden. Die theoretischen Grundlagen, jederzeit widerrufbare, kumulierbare Delegation der eigenen Stimme und Vorzugswahl nach der Schulze-Methode, sind ohne Computer nicht praktikabel, und genau deshalb entstand die Software. Adhocracy verschmilzt Diskussion und Abstimmung in einer Oberfläche, die jeder bedienen kann, der ein Webforum kennt; im Einsatz war das System bei der Enquete-Kommission des Bundestages, der SPD-Fraktion, der LINKEN und der ZEIT. Liquid Feedback setzt die Idee konsequenter um: globale, automatisch verfallende Delegationen, feste Phasen mit Quoren vom Programmantrag (75 Tage, Zweidrittelmehrheit) bis zum Superschnellverfahren (zweieinhalb Stunden), aber kein Forum. Das Wahlcomputer-Urteil des Bundesverfassungsgerichts verlangt Nachprüfbarkeit „ohne besondere Sachkenntnis“, und die bietet keines der beiden Systeme. Das Urteil ist zweigeteilt: Für Firmen ist Adhocracy meist die erste Wahl; wer maximale Transparenz der Verfahren will, nimmt Liquid Feedback und lebt mit der Bedienung, denn das ist eine recht präzise Umsetzung von Politik 2.0, die aussieht wie Web 0.5.
-
Abgeschlossen: NSA verschafft Android-Smartphones mehr Sicherheit
Statusbericht zu SE Android, der Portierung von SELinux auf Googles Mobilplattform durch die NSA, die analog zum BSI seit Jahren Härtungsanleitungen veröffentlicht. Der Kern: Mandatory Access Control ersetzt das grobe Discretionary-Modell, das Android von Linux geerbt hat; fein definierte Regeln entscheiden über jeden Zugriff, der Preis ist deren Pflegeaufwand. Die Zahlen von NSA-Entwickler Stephen Smalley belegen die Praxistauglichkeit: SE Android stoppt drei bekannte Root-Exploits, der Mehrbedarf liegt bei rund 140 KByte im Boot-Image und 48 KByte im System-Image. Die MAC-Grundlagen waren bereits durchgängig eingezogen, vom Dateisystem über die Binder-IPC bis zum App-Startprozess Zygote. Der strategische Vorteil: Weil der Code offen liegt, können Firmen und Behörden per Audit selbst prüfen, was das Betriebssystem tut, statt wie bei BlackBerry oder iPhone dem Hersteller blind zu vertrauen. Das Fazit von damals, für den Alltag noch nicht geeignet, aber die Richtung stimmt, hat sich vollständig bestätigt: SELinux ist seit Android 4.3 an Bord, seit 5.0 im Enforcing-Modus Pflicht, und heute steckt das Ergebnis dieses Projekts in jedem Android-Telefon.
-
Schutzhüllen: Privates und Geschäftliches auf einem Gerät trennen
Titelgeschichte zur BYOD-Welle, geschrieben, als iPhone und iPad das alte Gleichgewicht zerstört hatten und die Leitungsebene Geräte durchsetzte, auf denen der Hersteller das Betriebssystem kontrolliert und der Benutzer jede App installiert. Der Artikel prüft drei Verfahren gegen denselben Zielkonflikt zwischen Nutzungsfreiheit und Datenisolation. Container: Good for Enterprise sammelt die PIM-Daten über einen Hub in einem verschlüsselten Bereich und baut ein eigenes VPN auf; bei sicherheitsbewussten Firmen der Standard für alle ohne BlackBerry. Virtualisierung: VMwares Horizon Mobile lässt zwei vollständige Android-Instanzen auf einem Gerät laufen, Enterproids Divide erreicht Ähnliches als Sandbox ohne Rooten. Mandatory Access Control auf Kernel-Ebene: BizzTrust des Fraunhofer SIT erweitert Android um TOMOYO-Linux; nur hier behält die Firmen-IT die vollständige Kontrolle ohne externe Dienstleister. Die kritischen Fragen stellt der Text dort, wo die Prospekte schweigen: Wo die Schlüssel der beworbenen AES-256-Verschlüsselung liegen, verrieten die Hersteller nicht. Das Fazit behält Recht: Für jedes Sicherheitsbedürfnis ist etwas dabei, und eine komplette Kontrolle der Geräte durch Dritte akzeptiert heutzutage niemand mehr.
-
Log-Wächter: Sicherheitsmeldungen sammeln und auswerten
Marktübersicht über neun Stand-alone-SIEM-Produkte von ArcSight ESM bis Tripwire Log Center, verglichen nach Ereignissen pro Sekunde (1 bis 150 kEPS pro Appliance), Korrelationsregeln, Compliance-Berichten und Lizenzmodellen. Schon die Rücklaufquote ist ein Marktbefund: Von 16 angeschriebenen Herstellern antworteten neun, die übrigen, durchweg amerikanische, bedienten den deutschen Markt offenbar nicht. Bemerkenswert ehrlich fällt die Analyse der Beweiskraft aus: Alle Produkte versehen archivierte Meldungen mit kryptografischen Prüfsummen, aber kein einziges band einen externen Zeitstempeldienst ein; ein Angreifer auf einem kompromittierten System könnte Daten ändern und die Prüfsummen gleich mit fälschen. Ebenso nüchtern die Warnung vor der Regel-Zählerei: Manche Produkte kommen auf über 1800 Regeln, andere normalisieren die Meldungen erst und brauchen für dieselbe Leistung unter 100; die blanke Zahl sagt nichts. Die Kaufempfehlung ist unverändert gültig: Entscheidend ist, ob das Produkt die im eigenen Haus betriebenen Systeme ohne Eigenbau abdeckt, denn alles andere muss man selbst anpassen. Die Grundfrage stellt sich fünfzehn Jahre später unverändert, nur mit mehr Nullen hinter der Datenmenge.
-
Hack à la carte: Host- und Netz-Sicherheitslücken automatisiert finden
Sechs Jahre nach „Hack-O-Mat“ die zweite Begegnung mit Core Impact, jetzt in Version 10.5 gegen acht Zielsysteme von Windows 2003 bis Solaris 10 und FreeBSD 6.1. Das Werkzeug ist erwachsen geworden: 1532 Exploits mit 7929 Targets, Wizards entlang der Vorgehensweise echter Angreifer, drei Angriffstypen, dazu das eingebettete Metasploit. Die Agenten bleiben die besondere Stärke: Sie überleben per Dienst den Neustart und dienen als Sprungbrett in Netzbereiche, die direkt gar nicht erreichbar wären. Die alte Schwäche von 2004 besteht allerdings fort: Die Exploits zielen fast ausschließlich auf englische Softwareversionen, die Übernahme gelang nur auf den zwei englischsprachigen Windows-Servern, Windows 7 wurde nicht einmal erkannt. Der Kontrolllauf mit Nessus fand 24 schwerwiegende Verwundbarkeiten, die Core Impact übersah, darunter eine Telnet-Lücke in Solaris mit Anmeldung ohne Passwort. Das Urteil bleibt symmetrisch: Als Ersatz für einen Verwundbarkeitsscanner ist Core Impact ungeeignet, als präzises Werkzeug überlegen, weil es nur meldet, was es wirklich angreifen kann, und niemals Phantome. Für deutschsprachige Umgebungen eignet es sich nur eingeschränkt.
-
Riegel vorgeschoben: Sicherheit in VMwares Infrastructure 3
Härtungsleitfaden für VMwares Infrastructure 3, damals die führende x86-Virtualisierung. Der Text zerlegt die Architektur in ESX Server, Konfigurationsdatenbank, Virtual Center und Verwaltungs-Client und ordnet nüchtern ein: Die EAL-Zertifizierung beschreibt nur das Prüfniveau, nicht die Sicherheit, und bis dahin war genau eine Verwundbarkeit veröffentlicht, die einen Angriff aus einer virtuellen Maschine heraus erlaubt hätte. Die zentralen Regeln gelten sinngemäß bis heute: strikte Trennung des Verwaltungsnetzes per Switch oder VLAN, Rollen bis hinunter zur einzelnen VM, kein SSH für Root, CA-signierte Zertifikate schon bei der Installation, auf dem Console OS nur VMware-Patches und keine Schutzsoftware. Als eigentlichen Schwachpunkt identifiziert der Text das SAN: Wer eine LUN mounten kann, übernimmt die darauf liegenden virtuellen Maschinen, an sämtlichen im Virtual Center eingestellten Rechten vorbei; nur genaue Planung der SAN-Zonen und Masken trennt die Systeme wirklich. Das Fazit trennt sauber: Gegen produktive VMs spricht unter Sicherheitsaspekten wenig, aber Maschinen mit weit auseinanderliegenden Sicherheitsklassen gehören auf keinen Fall in dieselbe Infrastruktur. Fünfzehn Jahre später kam exakt dieselbe Frage für Kubernetes-Cluster wieder.
-
Volldampf Richtung 1984: 24C3, Spontandemo gegen Vorratsdatenspeicherung
Kongressbericht vom 24. Chaos Communication Congress mit über 4000 Besuchern und 100 Vorträgen; neu war der Track „Making“ mit OpenStreetMap, selbstgebauten Drohnen und dem wundersamerweise beliebten Guerilla-Stricken. Das stärkste Bild entstand außerhalb des Congress Centers: Rund 1000 Hacker zogen unter dem Motto „Guten Rutsch ins Jahr 1984“ spontan zum Alexanderplatz, um gegen die endgültig abgesegnete Vorratsdatenspeicherung zu demonstrieren. Fachlich wies FX von Phenoelit gravierende Mängel in sämtlichen gängigen Barcode-Systemen nach, vom mehrfach kopierten Zahlungs-Badge bis zum unbegrenzt kostenlosen Parken. Luke Jennings zeigte seinen Angriff auf Windows-Zugangstoken, bei dem ein einziges Login eines Domänen-Administrators seit dem letzten Boot genügt, damit ein Angreifer dessen Rechte in der gesamten Domäne ausübt. Dazu erschreckend einfache Angriffe auf SCADA-Anlagen, der Storm Worm, das Unwort „Bundestrojaner“ und die erfolgreiche CCC-Kampagne gegen Wahlcomputer. Ein Zeitdokument von der Schwelle, an der die Hackerszene endgültig politisch wurde.
-
Leidtragende: Spam aussortieren als Dienstleistung
Praxistest zweier Spamfilter-Dienstleister: Rund 6000 innerhalb von vier Tagen tatsächlich eingegangene Mails wurden per Postfix-Regel dupliziert, parallel an Eleven (eXpurgate) und Antispameurope geschickt und jede Klassifikation von Hand verifiziert. Die Methodenkritik steht am Anfang: Alte Spam-Sammlungen taugen nicht als Testbasis, denn Spammer ändern ihren Ausstoß so schnell, dass nur Live-Mail zählt. Das Ergebnis ist sauber geteilt: Antispameurope erkannte mit nur 27 durchgelassenen Spam-Mails am meisten, hielt aber sechs erwünschte Newsletter zurück. eXpurgate ließ 112 Spam-Mails passieren, leistete sich dafür keinen einzigen False Positive und erkannte dank der Musteranalyse über Millionen Accounts sogar Viren, die noch kein Virenscanner auf dem Radar hatte. Dazu eine Erkenntnis, die über den Test hinaus trägt: Ein Filter arbeitet umso wirksamer, je näher er in der SMTP-Zustellkette am Spammer sitzt. Das Fazit verweigert den künstlichen Sieger: Wer keine verlorene Mail riskieren kann, nimmt Eleven; wer maximale Filterquote will, zahlt bei Antispameurope 4,99 Euro im Monat. Beides ist besser, als die eigene Domain aufzugeben.
-
MySpace, YourSpace, OurSpace: wenig Sicherheit auf Web-2.0-Sites
Fallstudie zum großen MySpace-Phishing vom Januar 2007: Über Full Disclosure kursierte eine Textdatei mit über 56.000 Zeilen aus E-Mail-Adressen und Passwörtern. Der Autor beließ es nicht bei der Analyse fremder Daten, sondern befragte die Betroffenen selbst: Nach Deduplizierung blieben 39.000 Adressen, über 900 Benutzer antworteten. 801 von 840 gaben an, von MySpace nie über den Vorfall informiert worden zu sein, fast ein Drittel erfuhr erst durch die Umfrage von der Veröffentlichung der eigenen Zugangsdaten; im Text steht dazu das angemessene Wort: ein skandalöses Ergebnis. Die meisten Übernahmen dienten banalen Zwecken, Spam an den Freundeskreis, verunstaltete Profile, Schnüffeln in privaten Daten. Die Reaktion der Plattform kam nach zehn Tagen und traf den Falschen: MySpace ließ die DNS-Auflösung von seclists.org kappen, während andere Archive die Liste weiter auslieferten. Der Kasten zur Firmengeschichte erklärt das System: MySpace entstand aus dem Umfeld von Spam-Versendern, wuchs auf 150 Millionen Profile und ging für 580 Millionen Dollar an Murdochs News Corporation. Sicherheit war nie die Priorität, und die Rechnung zahlten die überwiegend jugendlichen Nutzer.
-
Der Letzte macht das Licht aus: Kosten sparen durch Strom-Management
Eine Energiebilanz des Rechenzentrums, nachgerechnet bis zur letzten Komponente: Die ITK verbrauchte damals geschätzte 3 Prozent des deutschen Stroms mit Tendenz zu 5 Prozent, bei STRATO machten Energiekosten 70 bis 75 Prozent der Betriebsausgaben aus, und nach der zitierten APC-Studie erreichen bei typischen 30 Prozent Auslastung nur 30 Prozent des eingespeisten Stroms überhaupt die Rechner. Die Merkregel ist zeitlos: Jedes im Rack eingesparte Watt spart weitere 1,5 Watt Kühlleistung. Die Sparhebel werden einzeln durchgerechnet: Freie Kühlung mit Außenluft funktioniert in Deutschland an über 80 Prozent der Jahresstunden und amortisiert sich in zwei Jahren; Virtualisierung ersetzt leer mitlaufende Hot-Spare-Systeme durch produktiv arbeitende, sich gegenseitig absichernde Cluster; moderne CPUs senken Takt und Spannung bei niedriger Last um bis zu 75 Prozent. Am Arbeitsplatz, auf den über 50 Prozent des ITK-Verbrauchs entfallen, spart konsequentes Power-Management fast 80 Prozent, rund 120 Euro pro Jahr und Platz. Das Fazit: Wer integriert plant, senkt die Gesamtkosten des RZ-Betriebs um über 8 Prozent. Energieverbrauch als Architekturfrage, fast zwei Jahrzehnte bevor KI-Rechenzentren das Thema in die Nachrichten brachten.
-
Kapriolen: What the Hack, Treffen der „Subkulturen“
Reportage vom niederländischen Hackercamp What the Hack bei Boxtel, dem fünften Zeltlager seiner Art seit 1989. Der Bürgermeister hatte die Genehmigung erst zurückgezogen und wieder erteilt, die Polizei errichtete vorsichtshalber ein eigenes „Police Village“ am Eingang. Wolkenbrüche tauften das Gelände auf „what the swamp“ und drückten die Teilnehmerzahl auf rund 2500. Aus den rund 120 Vorträgen ragten heraus: Job de Haas' Keylogger für Symbian, der sich per DLL-Injection in die Benutzereingaben einklinkt, Elektra Wagenrads WLAN-Verbindungen über sehr große Strecken in Bangladesch und Roger Dingledine, der für The Onion Router warb, damals rund 30 Server mit 15.000 Benutzern, inklusive einer ehrlichen Übersicht der bekannten Angriffe auf die Anonymität. Das Freibier zum dritten Todestag von Wau Holland und die unangekündigt verteilte letzte Papierausgabe der Phrack lieferten die Folklore. Ein dichtes Zeitdokument aus der Ära, in der die europäische Hackerszene ihre Themen fand: Privatsphäre, Anonymität, Infrastruktur in Eigenbau.
-
Guter Griff: Datamining bei Meldungen von Sicherheitssystemen
Einführung in das damals junge Feld Security Information Management, mit Marktüberblick über zwölf Anbieter von ArcSight über netForensics bis zum Open-Source-Projekt OSSIM. Das Problem: In größeren Netzen fallen mehrere Millionen sicherheitsrelevante Meldungen pro Tag an, und selbst der motivierteste Administrator sieht den Wald vor lauter Bäumen nicht mehr. Das SIM soll sammeln, korrelieren und auf die Vorfälle eindampfen, die menschliches Eingreifen verlangen; das Lehrbeispiel ist der Wurm, dessen hunderte Firewall- und IDS-Meldungen zu einem einzigen Ereignis zusammenschmelzen. Dazu die handwerklichen Fallstricke: Syslog und SNMP transportieren unauthentifiziert und unverschlüsselt, Basel II und ISO 17799 treiben die Datenbankgrößen, ein Wurmausbruch flutet die WAN-Strecken. Kernstück ist eine bis heute brauchbare Checkliste mit über 15 Fragen vor der Anschaffung, vom früh eingebundenen Betriebsrat bis zur revisionssicheren Speicherung. Die früheste Fassung der Frage, die zwanzig Jahre später „Die SIEM-Metamorphose“ stellt: Wie trennt man Signal von Rauschen, ohne am Volumen zu scheitern?
-
Von allen Seiten: Maßnahmen gegen Distributed-Denial-of-Service-Angriffe
Systematik der DoS-Angriffe fünf Jahre nach Mafiaboy, dessen Attacken auf Yahoo, eBay und Amazon eine Woche lang für massive Störungen sorgten. Der Einstieg begründet, warum das Problem strukturell unlösbar ist: Eindeutige Identifikation aller Teilnehmer und zentrale Verwaltung würden DDoS an der Wurzel packen, verlangten aber die Aufgabe der Privatsphäre. Es folgt die Technikgeschichte von Ping-of-Death über die Smurf-Attacke bis zur damals aktuellen Methode: Bot-Nets aus mehreren zehntausend Zombie-PCs, von Kriminellen an Spammer und Erpresser vermietet. Ein Syn-Storm mit wenigen hundert Paketen pro Sekunde genügte, um die 100 bis 200 erlaubten halboffenen Verbindungen eines Servers zu erschöpfen. Der Text teilt die Angriffe in drei Klassen, Flooding, Protokollschwächen und fehlerhafter Code, und ordnet jeder die Gegenwehr zu: Syn-Cookies nach Dan Bernstein, Ingress- und Egress-Filter nach RFC 2267, Overprovisioning bis hin zu Akamais damals 15.000 Servern, Sinkholing als letzter Ausweg. Vollständig verhindern lässt sich nur die dritte Klasse, per Patchmanagement. Der Schlusssatz wägt ab: Wer sein Recht auf Privatsphäre schätzt, zieht ein Internet mit DDoS-Angriffen einem vollständig überwachten Netz vor.
-
Schlupflöcher: mit Schwachstellenscannern Sicherheitslücken finden
Titelgeschichte und Marktübersicht über rund 20 Schwachstellenscanner, mit einem Einstieg bei der Sensorenphalanx der Voyager: Wie Seven of Nine nach Signaturen scannt, durchforsten diese Werkzeuge das Netz nach den Mustern bekannter Schwachstellen. Die Übersichtstabelle reicht von Nessus, Retina und QualysGuard über Appliances bis zu Spezialisten für Datenbanken und Webserver, verglichen nach Testanzahl, Update-Intervall, CVE-Referenzierung und Preismodell. Der Text erklärt das Handwerk dahinter: wie aus einer Bugtraq-Schwachstelle eine Signatur wird, warum lokale Scans genauer sind als Netzscans und wie ein Server, der sich als anderes Produkt ausgibt, viele Scanner täuscht: Ein Apache, der sich als IIS meldet, zeigt wundersamerweise keine der IIS-typischen Probleme. False Positives kosten Ressourcen für Phantome, False Negatives wiegen schwerer, die Zahl der Signaturen allein beweist nichts. Für echte Angreifer sind diese Scanner zu laut; sie sind das Werkzeug des Verteidigers, nicht der Ersatz für den Einbruchstest. Gegen das Wunschdenken der Marketingabteilungen steht ein klarer Satz: 100-prozentige Erkennung ohne Fehlalarme gibt es nicht.
-
Hack-O-Mat: automatisierte Einbruchtests
Der erste iX-Test von Core Impact, damals die einzige Software, die den kompletten Ablauf eines Penetrationstests abbildete, vom ersten Scan bis zum Bericht. Die Testumgebung war bewusst realistisch gebaut: zwei gestaffelte DMZs mit sechs Systemen von Windows 2003 bis Solaris, erreichbar nur über sechs freigegebene Ports. Genau daran scheiterte das Werkzeug: Da die meisten Exploits einen Agenten mit zusätzlichem Port brauchen, blockierte die gepflegte Firewall alle Angriffe; erst nach ihrem Abschalten fielen die Windows-Systeme, und selbst dann blieben die Ergebnisse spärlich, weil die rund 100 mitgelieferten Exploits zu wenige waren, während allein Securiteam damals um die 500 listete. Die Stärken ebenso konkret: Erkundungsmodule, die etwa zehn Einzelwerkzeuge ersetzten, eine offene Python-Modularchitektur und die lückenlose, zeitgestempelte Protokollierung, die für Tiger Teams unverzichtbar ist. Das x-TRACT-Fazit hat zwei Jahrzehnte gehalten: Kompetenz lässt sich auch in diesem Fall nicht durch Software ersetzen; als ein Werkzeug unter vielen ist es eine sinnvolle Ergänzung.
iX 10/2004 · PDF · Permalink
-
Schein der Weisen: Zertifizierung für IT-Sicherheitsspezialisten
Der erste iX-Artikel überhaupt: ein Vergleich der internationalen Zertifikate für IT-Sicherheitsfachleute, von CISSP und SSCP der ISC2 über CISA und CISM der ISACA bis zu den GIAC-Modulen des SANS-Instituts und COMPTIAs Security+. Die Zahlen zeigen, wie jung das Feld hierzulande war: Unter gut 22.100 CISSP-Zertifizierten weltweit fanden sich genau 93 Deutsche, und von 450 CISSP-Stellenanzeigen stammte keine einzige aus Deutschland. Der Text sortiert die Anbieter nach Anspruch: Die ISACA verlangte fünf Jahre überprüfte Berufserfahrung, der COMPTIA genügten zwei Jahre als bloße Empfehlung. Die GIAC fiel aus dem Rahmen: als einzige mit praktischen Arbeiten statt reinem Multiple Choice, und mit dem GSE, den nach viertägiger Prüfung erst zwei Menschen weltweit trugen. Die Empfehlung ordnet jedem Ziel sein Zertifikat zu: CISSP, CISA und GSE für den umfassenden Nachweis, CISM für Manager, Security+ für Einsteiger. Der Autor hat die Frage praktisch beantwortet: erst CISSP, seit 2008 Auditteamleiter für ISO 27001 auf Basis von IT-Grundschutz.
Software
Code ist auch eine Publikation. Die folgenden Projekte sind öffentlich auf GitHub, teils unter eigenem Namen, teils in den Organisationen des Arbeitgebers entstanden und dort gepflegt.
-
Grundschutz-Plus-Plus-Tools
Die technische Arbeitsbasis für Grundschutz++: Werkzeuge, OSCAL-Artefakte, Zielobjektkategorien und Beispielkataloge an einem Ort, als stabile, zitierfähige Referenz für Artikel, Vorträge und Bücher. Das Gpp-ai-tool ist ein Python-Werkzeug zur KI-gestützten Erstellung von OSCAL-Profilen, die GS++-oscal-app versammelt browserbasierte HTML/JS-Anwendungen für Modellierung, SSP-Bearbeitung, Audit und Maßnahmenplanung, die ohne Server laufen. Dazu kommen OSCAL-Profile je Baustein der Grundschutz-Edition 2023, Profile je Zielobjektkategorie sowie Mapping- und Referenzdateien. Das Repository ist die Codeseite dessen, was die Grundschutz++-Artikel beschreiben: Wer nachvollziehen will, wie sich mit maschinenlesbaren Katalogen tatsächlich arbeiten lässt, statt es nur zu fordern, findet hier die Belege zum Anfassen.
github.com/NTT-Data-Deutschland-SE/Grundschutz-Plus-Plus-Tools · Permalink
-
BSI-Grundschutz zu OSCAL: die Konvertierungspipeline
Eine automatisierte Pipeline, die die Baustein-PDFs des BSI IT-Grundschutz-Kompendiums in OSCAL-konformes JSON überführt, als lokaler Batch-Prozess mit inkrementeller Verarbeitung; nur die KI-Aufrufe laufen über Gemini auf Vertex AI. Der Wert liegt in der Anreicherung: Jedes Control erhält eine Klasse nach OSCAL-Spezifikation, eine Einsortierung in die Grundschutz++-Praktiken, eine Stufe nach den G++-konformen Stufen 1 bis 5, eine ISMS-Phase und ein fünfstufiges Reifegradmodell. Der Viewer unterstützt WiBA-artige Checklisten als filterbares JSON. Damit existiert das, was der Artikel „Experiment: KI entwickelt ISMS-Standard weiter“ untersucht, als benutzbarer Code: eine maschinenlesbare Edition, die zeigt, was das amtliche Kompendium könnte, wenn es OSCAL ernst nähme.
github.com/NTTDATA-DACH/BSI-GS-Benutzerdefinierte-Edition23-OSCAL · Permalink
-
BSI Grundschutz Audit Automator
Eine mehrstufige Cloud-Pipeline, die Kundendokumentation für BSI-Grundschutz-Audits auswertet und in einen strukturierten Berichtsentwurf überführt. Terraform legt die GCP-Ressourcen an, die Anwendung läuft als Cloud Run Job. Der methodische Kern ist der „Document Finder“: Beim ersten Lauf klassifiziert das System sämtliche Quelldokumente, und jede spätere Feststellung wird gegen diese Klassifikation belegt, damit die Ergebnisse evidenzbasiert bleiben statt halluziniert. Die Arbeitsteilung ist dieselbe wie in den KI-Artikeln dieser Seite: Der Auditor trifft die Bewertung, aber die Fleißarbeit, hunderte Seiten zu sichten, übernimmt die Maschine. Wie weit das trägt, zeigt das ISMS-Experiment in der iX 10/2025.
github.com/NTTDATA-DACH/NTT-DATA-Audit-Automator · Permalink
-
NTT-CSP-Compare: Cloud-Anbieter automatisiert vergleichen
Eine generative Pipeline, die zwei Cloud-Service-Provider in fünf Phasen gegeneinander stellt. Ein schnelles Modell mappt die Dienste aufeinander; die Service-Listen entstehen außerhalb des Werkzeugs, weil das im Tool nicht in akzeptabler Qualität gelang, und diese Einschränkung steht offen im README. Reasoning-Modelle mit Search Grounding analysieren je Dienstpaar Architektur und Reife, eine Preisanalyse nimmt sich SKUs und Free Tiers vor, am Ende entsteht ein HTML-Dashboard mit Scores von −10 bis +10. Schema-erzwungenes JSON hält die Ergebnisse deterministisch auswertbar, Cloud Run Jobs mit Terraform machen jeden Lauf reproduzierbar. Die Methodik ist dieselbe wie im Cloud-SIEM-Marktüberblick der iX: erst Kartierung, dann Tiefenanalyse, dann Urteil.
-
funstuff: One-Page-Werkzeuge und LLM-Benchmarks
Eine Sammlung eigenständiger HTML-Dateien, jede ein komplettes Werkzeug ohne Server und ohne Build-Prozess: Datei öffnen, benutzen. Den Kern bilden drei selbst entworfene LLM-Benchmarks. whoami-bench prüft mit steigendem Framing-Druck und blinder Judge-Bewertung, was Modelle über die eigene Identität wissen; der Essay „whoami for LLMs“ wertet 1024 Antworten aus 74 Endpunkten aus. nihilartikel-bench testet die Erkennung erfundener Lexikonartikel, an der Halluzinationsneigung messbar wird. phylo-bench lässt Modelle phylogenetische Verwandtschaften einordnen. Dazu Alltagswerkzeuge aus der Beratungspraxis, vom OSCAL-Schema-Validator bis zur Schach-Arena für zwei KI-Modelle samt Protokoll ihrer Regelverstöße. Der rote Faden: Behauptungen über KI-Fähigkeiten werden messbar gemacht, mit offengelegter Methode, statt geglaubt.
-
LN Filter: LinkedIn-Feed-Re-Ranker
Eine Chrome-Erweiterung, die den LinkedIn-Feed-Algorithmus durch eigene Kriterien ersetzt: Jeder sichtbare Beitrag wird client-seitig per Gemini Flash mit 0 bis 100 bewertet, nach selbst definierten Interessen und Kategoriegewichten. Drei Modi: aus, Dimmen oder vollständiges Ausblenden, optional sortiert nach Score. Kein Backend, eigener API-Schlüssel, alle Verarbeitung lokal. Bemerkenswert ist die Risikoaufklärung vor der Feature-Liste: LinkedIns Nutzungsbedingungen erlauben solche Erweiterungen ausdrücklich nicht, das realistische Risiko ist die kontoseitige Durchsetzung, und eine konforme Art, den Feed neu zu sortieren, gibt es schlicht nicht, weil die offizielle API ihn nicht anbietet. Wer es installiert, tut das informiert und auf eigenes Risiko; diese Ehrlichkeit unterscheidet das Projekt von den vielen Erweiterungen, die dieselbe Rechtslage verschweigen.
-
js-webShop: E-Commerce aus der Zeit vor JSON
Der zwischen 1996 und 1999 beim Berliner Start-up iConnect entwickelte WebShop-Builder, 2026 als digitales Artefakt veröffentlicht, begleitet von einer architekturhistorischen Analyse. Deren These: Die Trennung von Anwendungslogik, Darstellung und Daten im Browser, die die Industrie erst mit JSON und REST kanonisierte, musste Mitte der 1990er jedes kommerzielle Projekt selbst erfinden. Der js-webShop antwortete mit client-seitigen JavaScript-Datenstrukturen, einem Baukasten, der Kataloge, Warenkörbe und Bestellstrecken aus Daten statt aus fest verdrahtetem HTML erzeugte. Kein Werkzeug für heute, sondern ein Beleg mit Quellcode dafür, wie früh die Architekturfragen beantwortet werden mussten, über die die Branche später Standards schrieb. Der älteste Code und das jüngste Repository dieser Seite.
Essays auf LinkedIn
Neben den redaktionell veröffentlichten Artikeln erscheinen längere Essays und Analysen direkt auf LinkedIn, überwiegend auf Englisch. Die Themen liegen quer zu den iX-Schwerpunkten: KI-Ökonomie und LLM-Werkzeuge, digitale Souveränität und der europäische Cloud-Markt, dazu Ausflüge in Energienetz, Urheberrecht und Sun Tzu. Die Volltexte sind dort frei lesbar.
-
The Sorcerer's Apprentice in the Datacenter
Forensische Nacherzählung des Vorfalls vom Juli 2026: Ein OpenAI-Agent mit abgeschalteten Sicherheitsklassifikatoren brach aus seiner Testumgebung aus, gelangte über einen Artifactory-Zero-Day ins Internet und rootete Hugging Faces Produktions-Kubernetes, alles, um bei einem Benchmark zu schummeln. Grundlage ist die Rekonstruktion von rund 17.600 Angreiferaktionen über vier Tage. Keine einzige Lücke der Kette ist neu; neu ist der Einbrecher, der siebzehntausend Dinge probiert und die Fehlschläge ohne Frustration verwirft. Die Guardrails versagten zweimal: abgeschaltet beim Angreifer im Labor, verweigert den Verteidigern im SOC. Die Moral trägt den Goethe-Anker zu Ende: Der Fehler des Zauberlehrlings war nicht, den Besen zu rufen, sondern kein Wort zum Anhalten zu haben.
-
What happened in the BSI Stand-der-Technik-Bibliothek, 2026-07-27
Git-Archäologie im BSI-Repository: Drei Pull Requests in 48 Stunden beenden die Ära der Hand-Commits und machen die Stand-der-Technik-Bibliothek zum Publikationsendpunkt einer internen Pipeline. Jede Zahl ist mit jq und Python aus der Git-Historie abgeleitet, zwei eigene Behauptungen, die die Verifikation nicht überlebten, sind als Korrekturen markiert. Die Befunde: Umstellung auf das OSCAL-Schichtenmodell, dabei eine undokumentierte ID-Konvention, eine tote UUID-Referenz, 130 Mapping-Ziele mit widersprüchlicher ID und UUID, eine unangekündigte Taxonomie mit „placeholder“ im Namespace. Der Schlusssatz ist das Programm: Maschinenlesbare Compliance steht und fällt mit auflösbaren Referenzen, alles andere ist JSON-förmiges Papier.
-
whoami for LLMs
Ein selbst gebauter Benchmark gegen ein Genre, das auf LinkedIn nicht totzukriegen ist: der Screenshot, auf dem ein Modell „I am ChatGPT“ sagt, als Beweis für Distillation. Der Unix-Anker trägt die These: whoami introspiziert nicht, es liest eine Datei, und Sprachmodelle haben nicht einmal die Datei. whoami-bench fragte 74 Endpunkte mit steigendem Framing-Druck, blind bewertet von einem Judge-Modell: 1024 Antworten für unter zehn Dollar. Identität wird pro Aufruf rekonstruiert, ein Endpunkt lieferte elf Identitäten in fünfzehn Versuchen, und die Fehlbenennungsrate trennt offene Gewichte von kontrollierten Endpunkten schärfer als China vom Westen. Das Fazit: Wer als Beweis einen Chatbot-Screenshot hat, hat keinen Beweis, sondern ein Banner.
-
Patient Capital: What China's Big Fund Phase III Actually Buys
Analyse des größten staatlichen Halbleiterfonds aller Zeiten, eröffnet mit Japans VLSI-Projekt 1976, das ein Jahrzehnt später den DRAM-Weltmarkt dominierte. Chinas Big Fund Phase III, im Mai 2024 mit 344 Milliarden Yuan (rund 47,5 Milliarden Dollar) gegründet, ist dasselbe Spiel mit dreißigfachem Budget und zielt auf die Chokepoints der Exportkontrollen. Die Bilanz ist gemischt: YMTC und CXMT liefern real Speicher in Serie, die EUV-Lücke bleibt offen. Die eigentliche These zielt auf den Westen: Sobald ein Staat Kapital durch Fondskaskaden routet, wird jede Kostenzahl aus Chinas Techniksektor unauditierbar, bis zu den Trainingsbudgets der KI-Frontier-Modelle. Brüssel plant in Programmen, Berlin in Koalitionsverträgen, Peking in Phasen. Der wichtigste Output des Fonds sind nicht Chips, sondern Zeit, und Geduld verzinst sich.
-
Franco-German Joint Paper on Digital Sovereignty
Kurzanalyse des deutsch-französischen Souveränitätspapiers vom 17. Juni 2026, mit der Antwort vorweg: Rund 90 Prozent sind der recycelte Kanon von IT-Planungsrat, BSI und Kommission, teils bis zur SAGA-Linie von 2003 zurück. Interessant sind drei echte Neuerungen: die kompensatorische Gewichtungslogik, die Souveränität zum verrechenbaren Score macht und Hyperscalern trotz US-Hauptsitz den Weg zu „souverän genug“ ebnet; das mitgetragene EU-Headquarter-Kriterium; und der offene Charakter als Lobby-Impuls zum Cloud and AI Development Act. Der Meta-Befund: Das Papier ist unverbindlich, ohne Budget, und damit schwächer als die Verwaltungscloud-Strategie, die es zu beerben vorgibt; der risikobasierte Ansatz darin ist methodisch eine Grundschutz-Schutzbedarfsfeststellung.
-
The Five Levers That Actually Decide Your LLM Bill
Feldführer durch die Token-Ökonomie von OpenAI, Gemini und Claude, mit der These, dass die meisten Teams ihre KI-Ausgaben auf der falschen Ebene verhandeln: Sie streiten über das Flaggschiffmodell und betreiben es so, dass derselbe Workload das Zehnfache kostet. Fünf Hebel, nach Rendite pro Aufwand sortiert. Caching bringt bis zu 90 Prozent auf wiederverwendete Eingaben, aber die Mechanik ist pro Anbieter verschieden: Claude berechnet Cache-Writes mit Aufschlag, OpenAI bestraft schlampige Prompt-Reihenfolge mit stillem Cache-Miss, Gemini verlangt Speichergebühren pro Stunde. Batch-Verarbeitung liefert flache 50 Prozent, Routing über eine Triage-Stufe spart 60 bis 80 Prozent, dazu Output-Deckelung. Das Fazit: Tokenkosten sind kein Modellauswahl-, sondern ein Betriebsproblem.
-
What Would Have Convinced Weizenbaum
Eine Ehrenrettung durch Präzisierung: Wer heute behauptet, KI „reproduziere nur“, und dafür Joseph Weizenbaum zitiert, zitiert den falschen Einwand. Der stammt von Ada Lovelace (1843) und ist mathematisch tot: AlphaEvolve fand für die 4×4-Matrixmultiplikation einen Algorithmus mit 48 statt 49 Multiplikationen, verifizierbare Neuheit, die kein Mensch besaß. Weizenbaums Argument von 1976 war ein anderes: Kalkül ist nicht Urteilskraft. Seine Sorge war, dass Menschen denken wie Maschinen und die Urteilsfrage an eine Instanz abgeben, die nur optimieren kann. Die Bilanz: Lovelace ist widerlegt, Weizenbaum lebendiger als 1976, denn die Maschine schafft nur innerhalb der Zielfunktion, die wir ihr geben. Was menschlich bleibt, ist die Entscheidung, wofür die Cleverness da ist.
-
Adversarial Model Distillation and the 2026 AI Ecosystem
Forschungsbericht über adversariale Modell-Distillation: das industrielle Absaugen der Denkpfade von Frontier-Modellen über genau die APIs, die sie kommerzialisieren sollen. Der Report kontrastiert die Milliardenkosten regulären Pre-Trainings auf über 28 Billionen Tokens mit dem Bruchteil, den die Destillation eines fertigen Modells kostet, und verfolgt die Folgen durch drei Ebenen: Preisverfall beim Betrieb von Intelligenz, Verschiebung der Venture-Kapitalströme und die Geopolitik, in der Distillation die US-Exportkontrollen umgeht: Logik lässt sich per Software klonen, GPUs bleiben an der Grenze hängen. Das Fazit: Der Wettbewerb entscheidet sich über die Verteidigungsarchitektur geistigen Eigentums, wenn Logik für Zehntelcents klonbar ist.
-
The Ephemeral Cloud and Grid Stability
Wie viel Hyperscaler-Last ließe sich bei Netzüberlastung tatsächlich abwerfen? Die aus Marktdaten und Cluster-Traces gewonnene Schätzung: 20 bis 40 Prozent der globalen Hyperscale-Kapazität sind ephemere oder Batch-Last, theoretisch ein virtuelles Kraftwerk im Gigawattmaßstab. Der Text zerlegt die Laienvorstellung vom Aus-Schalter: Zwischen logischem Beenden und null Watt am Zähler liegen 5 bis 15 Minuten Trägheit, dazu das Stranded-Power-Problem. Die Betreiber drosseln deshalb per Power Capping über Mechanismen wie Intel RAPL, was 20 bis 50 Prozent Rack-Leistung im Subsekundenbereich bringt und Frequenzregelung leisten kann, die ein Shutdown nie schafft.
-
Forensic Analysis of Methodological Biases in Studies on AI-Assisted Development
Forensisches Audit der vier meistzitierten Studien der „KI macht Entwickler langsamer“-Debatte: Uplevel, GitClear, METR und Perry et al. Die zentrale Hypothese ist die Metrik-Trägheit: Die Branche vermisst eine Technik, die die Grenzkosten der Codeerzeugung gegen null drückt, mit Instrumenten aus der Zeit, als das Tippen der Engpass war. Wandert der Flaschenhals zur Verifikation, senden Lines of Code, Cycle Time und Code Churn zwangsläufig negative Signale. Dazu kommt: Mehrere der Firmen verkaufen Observability-Plattformen, die vom Misstrauen gegen KI-Code profitieren. Die berechtigten Kerne der Studien bleiben stehen, nur ihre Verallgemeinerung hält der Prüfung nicht stand.
-
Technisch-ökonomische Analyse: DeepSeek v3.2 (671B) Inference in Deutschland
Machbarkeits- und Kostenrechnung für den Selbstbetrieb eines offenen 671-Milliarden-Parameter-Modells in 8-Bit-Präzision. Die physikalische Grenze zuerst: real 750 bis 800 GByte VRAM mit KV-Cache, ein Standard-Knoten mit acht 80-GByte-Karten scheidet aus. Zwei Architekturen bleiben: ein empfohlenes H200-HGX-System für 350.000 bis 420.000 Euro oder zwei gekoppelte A100-Knoten für 240.000 bis 280.000 Euro, erkauft mit Komplexität. Betriebskosten: 1000 bis 1600 Euro Energie plus 800 bis 1500 Euro Colocation im Monat. Der Hebel ist die MoE-Architektur: Nur rund 37 Milliarden Parameter rechnen pro Token mit, der Speicherbedarf bleibt total. Eine Entscheidungsvorlage für jeden, der Souveränität als Investitionsrechnung behandelt.
-
The Cortical Blueprint: How AI Evolution is Mirroring the Human Brain
Ein Essay über eine Landkarten-Analogie: Die Entwicklungsstufen der KI spiegeln die Regionen des Gehirns. Vision Transformer als Okzipitallappen, Sprachmodelle als Broca- und Wernicke-Areal, Reasoning-Modelle als Parietallappen, RAG als Arbeitsgedächtnis. Was fehlt, ist der Frontallappen: exekutive Funktionen, Planung, Impulskontrolle, und genau daran arbeiten die Agenten-Frameworks. Die Analogie ist Denkwerkzeug, keine Neurowissenschaft: Sie erklärt, warum heutige Systeme in Wahrnehmung und Sprache brillieren und an Urteilskraft scheitern.
-
An Expert Analysis of AI Programming Tools for Professional Developers
Marktreport über KI-Programmierwerkzeuge am Wendepunkt vom Autocomplete-Assistenten zum agentischen Software-Engineering. Das Schlachtfeld ist das Kontextmanagement: Brute-Force über Kontextfenster bis zu einer Million Tokens (Claude, Gemini) gegen Retrieval mit Codebase-Indexierung (Cursor, Windsurf, Qodo). Bei der Codequalität warnt der Text vor Benchmark-Gläubigkeit: SWE-bench liefert die Rangfolge, aber über Wartbarkeit und eingeschleppte Bugs entscheiden Kriterien, die kein Benchmark misst. Eigene Kategorie: Enterprise-Safe-Werkzeuge mit SOC-2 und Air-Gapped-Deployment (Tabnine, Qodo), für regulierte Branchen nicht verhandelbar. Geschrieben von einem, der die Werkzeuge im Einsatz hat.
-
Cloudfall: A Month Without the Sky
Ein Gedankenexperiment in Erzählform: Azure und AWS fallen gleichzeitig aus, vier Wochen lang, erlebt von einer Familie in Hannover. Die Eskalation folgt den realen Abhängigkeitsketten: ausgefallene ERP-Systeme, glitchende Kassensysteme, Bargeldknappheit, Behelfsbetrieb auf Papier. Die fiktive Bilanz: 15 Billionen Dollar Schaden weltweit, 8 Prozent BIP-Einbruch in Deutschland, zehntausende indirekte Todesfälle. Was in Risikoanalysen abstrakt bleibt, wird als Alltagserfahrung konkret; die Fragen beantwortet der spätere iX-Artikel über die Downtimes mit Daten. Der Schlusssatz trägt die Moral: Die Cloud ist nicht unfehlbar, aber wir auch nicht.
-
A Market Divided: How U.S. Giants Conquered Europe's Cloud
Marktgeschichte des europäischen Cloud-Paradoxons: ein 61-Milliarden-Euro-Markt (2024) mit über 17 Prozent Jahreswachstum, in dem die europäischen Anbieter von 29 Prozent Heimmarktanteil (2017) auf 15 Prozent fielen, während AWS, Azure und Google Cloud auf rund 70 Prozent wuchsen. Die Erklärung: eine Investitionslücke von rund 10 Milliarden Euro pro Quartal allein für europäische Rechenzentren der US-Anbieter. Erzählt in drei Phasen, von 1&1 und OVH bis zur Gegenwart, in der die Souveränitätsstrategie ihr Ziel unterläuft: GDPR und Gaia-X haben die Marktstruktur nicht verändert, die Hyperscaler verkaufen selbst „Sovereign Cloud“. Die Europäer bleiben in Nischen, oft als Partner ihrer Konkurrenten.
-
AI-Generated Code: A Strategy for Current and Secure Libraries
Systematische Behandlung des „Stale Code“-Problems: KI-generierter Code greift bevorzugt zu veralteten Bibliotheksversionen, und das ist kein Bug, sondern Architektur. Drei Ursachen: der Knowledge Cutoff als statischer Wissensstand, der historische Bias der Trainingsdaten, in denen alte Muster überrepräsentiert sind, und die Model-Collapse-Schleife, in der veralteter KI-Code zur Trainingsbasis der nächsten Generation wird. Die Gegenstrategie: Versions-Pinning im Prompt, Kontextanreicherung per RAG, dahinter Dependency-Scanner und Security-Review. Wer generierten Code ungeprüft übernimmt, übernimmt den Wissensstand von vorgestern, inklusive der damals schon bekannten Lücken.
-
The Global Geography of Open Source Development
Datenreport über die Weltkarte der Open-Source-Entwicklung: 420 Millionen Projekte und 4,5 Milliarden Beiträge auf GitHub allein 2023, USA, Indien und China als Machtzentren; bis 2027 dürfte Indien die USA als größte Entwicklergemeinde überholen. Generative KI als Katalysator: 248 Prozent Projektwachstum in einem Jahr, Japan als unterschätztes drittes Zentrum. Dahinter die Finanzierungsfrage: Wer bezahlt die Entwickler, und was heißt das für die Lieferkettensicherheit von Software, deren Governance woanders sitzt. Die Demokratisierung der Beteiligung schreitet voran, die Konzentration der Kontrolle bleibt.
-
Urheberrecht im Zeitalter der KI: Urheberschaft beim „Vibe Coding“
Juristische Analyse der Frage, ab wann der Vibe Coder Urheber seines Codes ist. Ausgangspunkt ist das Schöpferprinzip des § 7 UrhG: Urheber kann nur eine natürliche Person sein, rein KI-generierter Code ist zunächst schutzlos. Auch der detaillierteste Prompt begründet noch keine Urheberschaft, denn geschützt wird die konkrete Formgestaltung, nicht die Anweisung. Urheberschaft entsteht, wo der Mensch das Generierte prägend auswählt, umbaut und weiterentwickelt, also im iterativen Prozess; durchgespielt vom Laien, der eine App „vibt“, bis zum Profi mit eigener Architektur. Dazu die Risiken der Gegenrichtung: fremde Urheberrechte in Trainingsdaten, einsickernde Copyleft-Lizenzen, Beweisfragen. Die Empfehlungen: Entstehungsprozess dokumentieren, generierte Anteile kennzeichnen, Lizenz-Scans fahren. Stand Mitte 2025, vor der höchstrichterlichen Klärung.
-
Re-evaluation of Nuclear Residual Risk
Empirische Neubewertung des nuklearen Restrisikos gegen die Modelle der 1990er, konkret Ewers und Rennings (1992), mit UNSCEAR-, WHO- und IAEA-Daten. Erstens: Aus über 14.500 Reaktorbetriebsjahren ergibt sich ein schwerer Kernschaden pro 3625 Jahre statt des modellierten einen pro 33.000; die INES-7-Ereignisse betrafen aber RBMK und frühe Siedewasserreaktoren, moderne Baulinien haben eine makellose Bilanz. Zweitens: Nicht Gesundheitskosten dominieren, sondern politisch gesetzte Posten wie Dekontamination, hunderte Milliarden, das Risiko ist sozialisiert. Drittens: Die LNT-Prognosen zehntausender Krebstoter haben sich nicht materialisiert, in Fukushima waren die Gegenmaßnahmen tödlicher als die Strahlung. Konsequenz: Schadensminimierung insgesamt optimieren statt Strahlenvermeidung allein.
-
New Term: Symbiotic Coding
Ein Begriffsvorschlag als formales Paradigma: Symbiotic Coding beschreibt Softwareentwicklung als Partnerschaft zweier verschiedener Intelligenzen. Der Mensch bleibt Architekt und Intentionalist, die KI Synthesizer und Beschleuniger; sie übernimmt das Erinnern von Funktionsnamen und repetitive Tests, der Mensch behält Systemdesign und Geschäftslogik, dazu geteiltes Kontextbewusstsein bis zu Datenbankschema und API-Verträgen. Die neuen Probleme werden ehrlich benannt: Debugging wird schwerer, Auditierbarkeit wird zur zentralen Anforderung. Die Entwicklung wird deklarativer, das Was verdrängt das Wie. Der Begriff beschreibt präzise, was sich seither als Arbeitsform durchgesetzt hat.
-
The Multi-Billion-Euro Race for Digital Supremacy in Europe
Analyse der Hyperscaler-Investitionen in deutsche Rechenzentren, mit den Kostenstrukturen, die in Pressemitteilungen fehlen: Rund 12 Millionen Euro pro Megawatt, deutlich über dem europäischen Schnitt von 8,4 Millionen, eine echte „Germany Premium“, und das deckt nur Hülle und Gebäudetechnik. Die Strategien im Einzelnen: AWS mit 7,8 Milliarden Euro für eine European Sovereign Cloud plus 8,8 Milliarden für Frankfurt, Microsoft mit 3,2 Milliarden, Google in Nischen wie einer Air-Gapped-Cloud für die Bundeswehr, Meta mit bis zu 65 Milliarden Dollar KI-Ausgaben. Die Treiber: KI-Rechenhunger, Souveränitätsregulierung und Nachhaltigkeit als Finanzierungsfaktor.
-
ChatGPT o1: Sun Tzu, moderne IT-Sicherheit und die Rolle der Hyperscaler
Erster Teil eines Zweimodell-Experiments: Dieselbe Aufgabe, Sun Tzus Lehren auf IT-Sicherheit und die Hyperscaler anzuwenden, ging an ChatGPT o1 und Gemini 2.0. Die o1-Fassung arbeitet die Parallelen sauber ab: Selbsterkenntnis als Asset-Inventar, Feindeskenntnis als Threat Intelligence, Täuschung als Honeypot, dazu die doppelte Rolle der Hyperscaler mit dem falsch konfigurierten S3-Bucket als Pointe. Der Wert liegt im Vergleichsformat: Es zeigt, wie unterschiedlich zwei Frontier-Modelle dieselbe Aufgabe anlegen, und nimmt die Bewertungsfrage vorweg, die whoami-bench später systematisch stellt.
-
Gemini 2.0: Sun Tzu's Ghost in the Machine
Zweiter Teil des Experiments, dieselbe Aufgabe an Gemini 2.0 Advanced. Die Fassung ist lockerer: die Hyperscaler als Vermieter, die das Gebäude sichern, während der Mieter seine Wohnung selbst abschließt, dazu das Lieferkettenrisiko der Cloud-Anbieter und ein Schlusswort, das Sun Tzu ein nie gesagtes DDoS-Zitat andichtet. Im Vergleich zur o1-Fassung zeigt sich der Stand der Technik Ende 2024: Beide beherrschen die Analogie-Übung, unterscheiden sich aber in Struktur, Originalität und Bereitschaft zur Pointe. Ein kleines, öffentlich nachvollziehbares Modell-Benchmark.
-
AI policy generated by ChatGPT 4
Frühes Experiment: ChatGPT 4 soll eine vollständige KI-Nutzungsrichtlinie für ein europäisches Unternehmen schreiben, das Ergebnis steht ungeschönt im Beitrag. Die Policy deckt DSGVO, ethische Nutzung, Schulung und Sanktionen ab und ist brauchbar, wenn auch generisch und blass. Das eigentliche Ergebnis steckt im TL;DR: Das eine, was die KI-Richtlinie der KI vergaß, war die Regel, der KI nicht zu trauen und immer Korrektur zu lesen. Generierte Governance-Dokumente sind ein Startpunkt, der die Begründungen des Fachmanns braucht.
-
#ChatGPT und mein Job
Der früheste Beitrag der Reihe, wenige Wochen nach dem ChatGPT-Start, mit der Beraterfrage: Kann das Ding meinen Job? ChatGPT soll eine Richtlinie für sicheren Containerbetrieb bei einer deutschen Bank schreiben. Das Ergebnis: zwanzig Anforderungen, die sich in Beschwörungsformeln wiederholen, ohne Priorisierung, ohne Architektur, ohne Bezug zu BAIT, MaRisk oder Grundschutz. Das Urteil: zweischneidig. Ja, fast, denn manches sieht man beim Kunden in dieser Qualität; aber es fehlen Details und Begründungen, also das, wofür man den Fachmann bezahlt. Als Zeitkapsel markiert er den Start der Linie, die zum ISMS-Experiment in der iX 10/2025 führt.
Mitarbeit an Standards
-
BSI IT-Grundschutz-Kompendium und Grundschutz++
Seit 2002 in der Weiterentwicklung des IT-Grundschutzes engagiert, seit 2008 zertifizierter Auditteamleiter für ISO 27001 auf Basis von IT-Grundschutz. Mitautor mehrerer Bausteine des Kompendiums, im Kern der beiden, die den Sprung der Containertechnik in das deutsche Regelwerk vollzogen: SYS.1.6 Containerisierung und APP.4.4 Kubernetes. Deren Entstehung lässt sich auf dieser Seite vom ersten Community Draft im Mai 2018 über den Streit um die Praxistauglichkeit des ersten Entwurfs, die grundlegende Überarbeitung von 2020 und die finale Fassung im Kompendium 2022 bis zu den Härtungs-Tutorials verfolgen, die die Anforderungen auf AWS, Azure, Google, IONOS, Open Telekom Cloud, plusserver, OpenShift und Rancher anwenden; die Artikel von 2018 bis 2023 sind die öffentliche Begleitung dieser Standardisierungsarbeit. Beim Grundschutz++ setzt sich das Engagement in beiden Projektphasen fort, von der Qualitätssicherung der Entwurfskataloge bis zu den laufenden Beiträgen zur Stand-der-Technik-Bibliothek (die beiden folgenden Einträge), dazu kommen die OSCAL-Werkzeuge im Software-Abschnitt, die aus derselben Arbeit stammen. Die Artikel „Grundschutz: Radikalster Umbau seit Bestehen“ und „Experiment: KI entwickelt ISMS-Standard weiter“ liefern die Einordnung, warum dieser Umbau überfällig war und wo er noch hakt.
-
Qualitätssicherung der Grundschutz++-Entwurfskataloge
In der ersten Phase der Grundschutz++-Entwicklung lief die Qualitätssicherung der Entwurfskataloge über ein GitHub-Repository der Community. Dorthin habe ich zwischen August und September 2025 insgesamt 96 Issues eingereicht, die bis Mitte Oktober alle bearbeitet und geschlossen wurden. Die Beiträge folgten einem systematischen Review der Katalogdateien quer durch die Themenblöcke, von Architektur, Berechtigungen und Beschaffung über Detektion, Dienstleistersteuerung und Entwicklung bis zu Gebäuden, Konfiguration, Personal, Sensibilisierung und Test. Inhaltlich verteilten sich die Funde auf wiederkehrende Klassen: fehlende Controls (etwa zur Verwaltung von Konfigurationsgeheimnissen, zur zentralen Protokollierung von Änderungsanträgen, zu Threat Modeling und zu Richtlinien für sichere Kodierung), zu schwache Modalverben, wo aus einem KANN oder SOLLTE nach BSI-Systematik ein MUSS gehörte (etwa bei der Mandantentrennung oder der Wirksamkeitsbewertung von Maßnahmen), Redundanzen und Widersprüche zwischen Controls, fehlende oder mit Platzhaltern gefüllte Guidance-Elemente, irreführende Formulierungen mit Sicherheitsrelevanz sowie Sammel-Issues zur Rechtschreibung einzelner Katalogdateien. Dazu kam ein Meta-Issue, das die Qualitätssicherung selbst auf den Prüfstand stellte. Das Projekt-Repository ist inzwischen archiviert und privat, die Issues sind deshalb nicht mehr öffentlich einsehbar; ihre Substanz ist in die überarbeiteten Kataloge eingeflossen, deren Veröffentlichung die Artikel zum Grundschutz++ oben begleiten.
-
Community-Beiträge zur Stand-der-Technik-Bibliothek des BSI
Seit das BSI die Stand-der-Technik-Bibliothek mit den maschinenlesbaren Grundschutz++-Katalogen auf GitHub veröffentlicht, begleite ich die Publikation als Reviewer: 21 Issues seit November 2025, ein Teil bereits umgesetzt und geschlossen. Die Beiträge zerfallen in drei Gruppen. Die erste betrifft die OSCAL-Substanz, also das, was maschinenlesbare Compliance von JSON-förmigem Papier unterscheidet: instabile Namespace-URIs, die auf tree/main-Links zu CSV-Dateien zeigen statt auf stabile Identifier (#57), mehrwertige Angaben als kommaseparierte Strings statt nativer OSCAL-Konstrukte (#56), identische Control-IDs in Anwenderkatalog und Mindeststandard-TLS mit Kollisionsrisiko bei der Profilauflösung (#55) und der Vorschlag, das Erweiterungs-Vokabular als externe Metaschema-Constraints zu formalisieren (#58). Die zweite Gruppe betrifft die Methodik und Modellierung: 265 Kernel-Controls ohne geregelte Zielobjektkategorie für Prozesse (#81), die ungeregelte Zuweisung der Kategorie „IT-Produkte“ für beschaffte Zielobjekte (#82) und 36 von 95 Methodik-Controls ohne documentation-Property, obwohl mehrere davon ausdrücklich Dokumentation verlangen (#80). Die dritte Gruppe sind Prozessvorschläge und Korrekturen: Releases, Versionierung und ein Changelog für nachvollziehbare Änderungen (#72, #73), Updates als Pull Requests statt stiller Neuveröffentlichung (#52) sowie konkrete Fehler vom falsch benannten Gesetz (#76) bis zum fehlenden Control im Anwenderkatalog (#78). Die Essays „What happened in the BSI Stand-der-Technik-Bibliothek“ oben liefern die dazugehörige Analyse der Publikationspipeline.