Konstantin Ziouras (Dipl. Ing.)

Endpoint Security bedeutet: Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen. Endpoint Security sorgt dafür, dass diese Türen: • nicht offenstehen • nicht mit gestohlenen Schlüsseln geöffnet werden • und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen. Warum das Thema heute wichtig ist 1. Angriffe starten fast immer am Endpoint • Phishing Mails → Klick → Malware auf dem Laptop • Ransomware → Verschlüsselung startet am Endpoint • Initial Access Broker → kompromittierte Endgeräte werden verkauft 2. Arbeitswelt hat sich verändert • Homeoffice, Remote Work, BYOD • Cloud Zugriffe von überall • Mehr Endgeräte, weniger klarer Perimeter 3. Business Relevanz • Ein kompromittierter Endpoint kann: o Zugang zu AD / Identitäten geben o Ransomware ins gesamte Netz bringen o Datenabfluss ermöglichen • Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen. Technische Grundlagen Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät. Wichtige Bausteine: • Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz • Host Firewall: Filtert eingehenden/ausgehenden Traffic • Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response • Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten • Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste) • Patch Management: Schließen von Schwachstellen Stand der Technik / Best Practices 1. Von klassischem AV zu EDR/XDR • Klassischer Virenscanner allein ist nicht mehr ausreichend. • Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen. 2. Zero Trust am Endpoint • Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist. • Kombination aus: o Gerätestatus (Compliance) o Identität (User) o Kontext (Ort, Zeit, Risiko) 3. Harter Fokus auf Identitäten • Endpoint Security ist eng mit Identity & Access Management verknüpft. • Kompromittierter Endpoint → kompromittierte Identität → lateral movement. 4. Standardisierte Baselines • CIS Benchmarks, BSI Empfehlungen, Hardening Guides • Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme. Typische Risiken & Fehler in der Praxis • Nur Antivirus, kein EDR/XDR • Kein zentrales Management der Endpoints • Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins) • Lokale Adminrechte für Benutzer • Kein Application Whitelisting (alles darf laufen) • Shadow IT (private Geräte, nicht verwaltete Systeme) • OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“ • Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt Moderne Lösungsansätze & Technologien • EDR/XDR Plattformen o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien) o Erkennen verdächtige Muster (z. B. Ransomware Verhalten) o Unterstützen Incident Response (Isolieren von Endpoints, Forensik) • Zero Trust Network Access (ZTNA) o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check) • Mobile Device Management (MDM) / Unified Endpoint Management (UEM) o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung) • Application Control / Whitelisting o Nur erlaubte Anwendungen dürfen laufen o Sehr wirksam gegen Malware und Ransomware • Hardware basierte Sicherheit o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault) Relevanz für Informationssicherheit & Compliance NIS2 • Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen. • Endpoint Security ist zentral für: o Schutz vor Ransomware o Incident Detection & Response o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden. ISO 27001:2022 • Relevante Controls u. a.: o A.5.15: Access control o A.5.23: Information security for use of mobile devices o A.8.7: Protection against malware o A.8.8: Management of technical vulnerabilities o A.8.9: Configuration management IEC 62443 (für OT) • Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen: o gehärtet sein o nur notwendige Dienste bereitstellen o überwacht werden o in Zonen/Conduits eingebettet sein. Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443. Empfehlungen für Unternehmen (konkret, priorisiert) Priorität 1 – Basis schaffen • Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile) • EDR Lösung ausrollen (mindestens auf kritischen Systemen) • Patch Management etablieren (inkl. Drittsoftware) • Plattferverschlüsselung aktivieren (Laptops, mobile Geräte) • Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin) Priorität 2 – Reifegrad erhöhen • Application Whitelisting für besonders kritische Systeme • Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint • Integration in SIEM/SOC: Alarme zentral auswerten • Standardisierte Hardening Baselines (CIS, BSI) Priorität 3 – OT & Spezialumgebungen • OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server) • Schutzkonzept definieren: o Hardening o Segmentierung o Monitoring (passiv, wo aktiv nicht möglich) • Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording. CTO Checkliste: Die 3 entscheidenden Fragen 1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“ Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten: • verhaltensbasierte Erkennung • Prozess und Speicheranalyse • Telemetrie Korrelation • automatische Isolation des Endpoints • Integration ins SOC/SIEM Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern. 2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“ Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten: • zentrales Endpoint Management (UEM/MDM) • automatisiertes Patch Management (inkl. Drittsoftware) • CIS/BSI Hardening Baselines • Compliance Checks vor Zugriff (Zero Trust) Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend. 3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“ Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten: • EDR gestützte Isolation per Klick • klare Rollen (SOC, IT Ops, Dienstleister) • forensische Daten (Prozesse, Registry, Netzwerk, Timeline) • definierte Reaktionszeiten • Playbooks Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.

1. Was ist eine Firewall? Stell dir dein Netzwerk wie ein Gebäude vor. Eine Firewall ist: • Der Türsteher: Prüft, wer rein darf. • Der Sicherheitszaun: Hält unerwünschte Besucher draußen. • Die Schleuse: Kontrolliert jeden, der das Gelände betreten oder verlassen will. Sie entscheidet basierend auf Regeln: Wer darf mit wem worüber sprechen? 2. Was ist ein Gateway? Ein Gateway ist wie ein Grenzübergang zwischen zwei Bereichen: • zwischen internem Netzwerk und Internet • zwischen IT und OT • zwischen Cloud und On Premises • zwischen verschiedenen Sicherheitszonen Es kontrolliert: • welche Daten passieren dürfen • wie sie geprüft werden • ob sie sicher sind 3. Warum braucht man Firewalls und Gateways? Weil Netzwerke ohne sie offene Häuser wären. Sie schützen vor: • Hackern • Malware • Ransomware • Datenklau • unbefugten Zugriffen • Angriffen auf OT Systeme Ohne Firewalls wäre jedes Gerät direkt aus dem Internet erreichbar — ein Albtraum. 4. Welche Arten von Firewalls gibt es? 1) Klassische Firewalls • prüfen IP Adressen und Ports • wie ein Türsteher, der nur auf die Eintrittskarte schaut 2) Next Generation Firewalls (NGFW) • prüfen Inhalte • erkennen Angriffe • filtern Apps (z. B. „erlaube nur Teams, blockiere Torrent“) • wie ein Türsteher, der auch Taschen kontrolliert 3) Web Application Firewalls (WAF) • schützen Webseiten und APIs • blockieren SQL Injection, XSS, Bots 4) OT Firewalls • verstehen industrielle Protokolle (Modbus, OPC UA) • blockieren gefährliche Befehle • schützen Produktionsanlagen 5) Cloud Firewalls • steuern Traffic in AWS, Azure, GCP • sind Teil moderner Cloud Architekturen 5. Wie schützen Firewalls uns? Sie: • blockieren Angriffe • verhindern unbefugte Zugriffe • segmentieren Netzwerke • überwachen Datenverkehr • erkennen Anomalien • stoppen Malware • schützen kritische Systeme 6. Typische Fehler (die in der Praxis noch vorkommen) • „Allow ANY ANY“ (alles erlaubt) • keine Segmentierung (Flat Network) • keine Dokumentation • veraltete Regeln • keine Überwachung • keine TLS Inspection → Blindflug • OT Netze ohne Protokollfilter 7. Was bedeutet das für Unternehmen? Sie brauchen: • klare Netzwerkzonen • moderne Firewalls • regelmäßige Regelwerks Reviews • Monitoring & Logging • Zero Trust Prinzipien • OT spezifische Schutzmaßnahmen • Cloud Firewalls für moderne Umgebungen 8. Verbindung zu Standards • NIS2 verlangt „angemessene technische Maßnahmen“ → Firewalls sind Pflicht • ISO 27001 verlangt Netzwerksegmentierung und Zugriffskontrollen • IEC 62443 verlangt Zonen/Conduits und OT Firewalls • ISO 22301 verlangt Schutz kritischer Systeme Kurz gesagt Firewall und Gateway Sicherheit bedeutet: • Netzwerke in sichere Bereiche aufteilen • nur erlaubten Verkehr zulassen • Angriffe erkennen und blockieren • OT und Cloud Systeme speziell schützen • Regeln regelmäßig prüfen • Monitoring aktiv betreiben Es ist die Grundlage jeder modernen Sicherheitsarchitektur. Checkliste für Firewall und Gateway Sicherheit 1. Architektur & Netzwerkdesign • Netzwerk in Sicherheitszonen segmentiert (z. B. IT, OT, DMZ, Cloud) • Klare Trust Boundaries definiert • Firewalls an allen Übergängen zwischen Zonen platziert • Redundante Firewall Cluster vorhanden • Zero Trust Prinzipien berücksichtigt • OT Netze strikt von IT getrennt • Remote Zugänge nur über gesicherte Gateways 2. Regelwerk & Policies • „Deny by default“ als Grundprinzip • Nur explizit erlaubte Verbindungen freigeschaltet • Keine ANY Regeln (Any Source, Any Destination, Any Service) • Identity-based Rules (Regeln basieren auf User-Gruppen, nicht nur IPs) • Regeln nach Least Privilege Prinzip • Regelwerk dokumentiert und versioniert • Regelwerk regelmäßig überprüft (mind. quartalsweise) • Alte oder ungenutzte Regeln entfernt • Regeln nach Zonen, Services und Verantwortlichkeiten strukturiert 3. Traffic Analyse & Inspektion • Deep Packet Inspection (DPI) aktiviert • TLS Inspection für relevante Verbindungen aktiviert • Intrusion Prevention System (IPS) aktiv • Virtual Patching (WAF/IPS schützt vor Lücken, für die es noch kein Software-Update gibt). • Malware Scanning aktiviert • Bot und Anomalie Erkennung aktiv • Geo Blocking (falls sinnvoll) • Rate Limiting für kritische Services 4. Web , API und Cloud Gateways • Web Application Firewall (WAF) für Web Anwendungen aktiv • API Gateway mit Auth, Rate Limit, Input Validation • Schutz vor OWASP API Top 10 • Cloud Firewalls (AWS/Azure/GCP) korrekt konfiguriert • Keine offenen Cloud Security Groups • CDN /Edge Security integriert (falls genutzt) 5. OT /ICS spezifische Firewall Sicherheit • OT Firewalls verstehen industrielle Protokolle (Modbus, OPC UA, S7) • Protokoll Whitelisting aktiv • Unidirektionale Gateways (Data Diodes) für kritische Systeme • Engineering Ports nur temporär freigeschaltet • Keine direkten Verbindungen zwischen IT und OT • OT Zonen nach IEC 62443 modelliert 6. Zugriffskontrolle & Administration • Administrationszugänge nur über Jump Server • MFA für alle Admin Zugänge • RBAC für Firewall Management • Änderungen nur über Change Management • Konfigurations Backups vorhanden • Firmware aktuell und signiert • Admin Sessions geloggt 7. Logging, Monitoring & SIEM • Zentrales Logging aller Firewall Events • Logs werden mindestens 12 Monate aufbewahrt • SIEM Integration vorhanden • Alerts für kritische Ereignisse (z. B. Port Scans, Blocked Traffic) • Anomalie Erkennung aktiv • Regelmäßige Auswertung der Logs • Forensik Daten vollständig 8. Tests & Qualitätssicherung • Regelmäßige Penetrationstests • Firewall Regelwerk wird automatisiert geprüft • Konfigurations Drift Erkennung aktiv • Notfall Szenarien getestet (Failover, Cluster Switch) • Testumgebung für Regeländerungen vorhanden • Regelmäßige Überprüfung der TLS Inspection 9. Dokumentation & Compliance • Vollständige Dokumentation der Firewall Topologie • Regelwerk dokumentiert und nachvollziehbar • Verantwortlichkeiten definiert • Audit Trails vorhanden • Konformität zu Standards geprüft, z.B. o NIS2 o ISO 27001 (A.8.20, A.8.16, A.5.17/18) o IEC 62443 (Zonen/Conduits, SR 3.x, SR 5.x, SR 7.x) o ISO 22301 (Schutz kritischer Systeme) 10. Typische Fehler, die vermieden werden müssen • Keine ANY Regeln • Keine offenen Ports „zur Sicherheit“ • Keine unüberwachten Remote Zugänge • Keine veralteten Firewall Versionen • Keine ungenutzten Regeln • Keine direkte IT ↔OT Kommunikation • Keine / fehlende TLS Inspection

Docker ist eine Technologie, mit der Software in Container verpackt wird. Ein Container ist wie eine kleine, abgeschlossene Box, in der alles drin ist, was ein Programm zum Laufen braucht: die Anwendung selbst Bibliotheken Konfigurationen Systemabhängigkeiten Dadurch läuft die Software überall gleich, egal ob: auf einem Laptop in der Cloud auf einem Server in einem Rechenzentrum Docker löst das klassische Problem „Bei mir läuft’s, bei dir nicht“ vollständig. Warum Container? Weil klassische Software oft abhängig ist von: • bestimmten Versionen von Bibliotheken • bestimmten Betriebssystemen • bestimmten Konfigurationen Container isolieren diese Abhängigkeiten — wie ein eigenes Mini System. Wie funktioniert Docker technisch? Docker nutzt Containerisierung, nicht Virtualisierung. Virtual Machine (VM) enthält ein komplettes Betriebssystem braucht viel Speicher startet langsam Docker Container nutzt das Host Betriebssystem mit ist extrem leichtgewichtig startet in Sekundenbruchteilen Technisch basiert Docker auf: Namespaces (Isolation) cgroups (Ressourcenbegrenzung) Union File Systems (schichtbasierte Images) Woraus besteht Docker? 1. Docker Image Ein Image ist eine Bauvorlage für Container. Beispiel: „Webserver Image“, „Python App Image“. 2. Docker Container Ein laufendes Exemplar eines Images. Beispiel: „Webserver Container läuft jetzt auf Port 80“. 3. Dockerfile Eine Textdatei, die beschreibt, wie ein Image gebaut wird. 4. Docker Engine Die Software, die Container startet und verwaltet. 5. Docker Hub Eine Art „App Store“ für fertige Images. Wofür wird Docker genutzt? 1. Softwareentwicklung Entwickler können identische Umgebungen nutzen. 2. DevOps & CI/CD Automatisierte Builds, Tests und Deployments. Ein Entwickler kann per Knopfdruck eine komplexe Datenbank-Umgebung starten, ohne sie lokal installieren zu müssen. Automatisches Testen von Code in einer sauberen Umgebung. 3. Microservices Jeder Service läuft in seinem eigenen Container. Statt einer riesigen, schweren Software nutzt man 20 kleine Container, die miteinander kommunizieren. 4. Cloud Betrieb Container sind perfekt für AWS, Azure, GCP. 5. Skalierung Container können automatisch hoch und runtergefahren werden. Sicherheitsaspekte (für Nicht Admins) Container sind isoliert, aber teilen sich den Kernel. Das bedeutet: • sie sind sicherer als klassische Apps • aber weniger isoliert als VMs Wichtige Sicherheitsmechanismen: Signierte Images Trusted Registries Schwachstellenscans (z.B. mit Trivy, Clair) Least Privilege (keine Root Container)

Hier ein paar Gedanken über mögliche Inhalte einer KI Richtlinie 1. Präambel & Geltungsbereich Zweck der Richtlinie Risikominimierung, Schutz von Unternehmenswerten, Rechtssicherheit Einhaltung von EU AI Act, DSGVO, ISO 27001, TISAX Geltungsbereich Alle Mitarbeitenden, Externe, Dienstleister Alle KI Arten: Generative KI (z. B. ChatGPT), eingebettete KI in Software, interne KI Modelle, autonome Agenten Definitionen KI-System, Generative KI, Hochrisiko-KI, Shadow AI, KI-Agenten, Trainingsdaten, Prompting 2. Klassifizierung von KI-Anwendungen (EU AI Act basiert) Verbotene KI-Anwendungen Social Scoring Biometrische Fernidentifizierung Emotionserkennung im Arbeitskontext Zulässige Standard-KI Freigegebene Tools (White List), z. B. Enterprise Copilot Einzelfallprüfung Prozess für Tools, die nicht auf der White List stehen Risikoanalyse, Datenschutzprüfung, Security Check Hochrisiko-KI Dokumentationspflicht, Audit Trail, Human Oversight 3. Datensicherheit & Datenschutz Input Verbote Keine personenbezogenen Daten Keine Geschäftsgeheimnisse Kein Quellcode Keine vertraulichen Verträge oder Kundendaten Daten Opt Out Pflicht zur Deaktivierung von „Training mit Nutzerdaten“ Anonymisierungspflicht Pseudonymisierung oder Verfremdung vor Eingabe Speicherorte & Datenflüsse Keine Speicherung von KI Outputs in nicht genehmigten Tools Rechtsgrundlagen DSGVO, Betriebsvereinbarungen, Geheimhaltungspflichten 4. Umgang mit KI-Ergebnissen (Output-Kontrolle) Verifizierungspflicht (Human in the Loop) KI Ergebnisse müssen geprüft, korrigiert und freigegeben werden Kennzeichnungspflicht KI-generierte Inhalte müssen als solche markiert werden Urheberrecht Hinweis: KI Outputs sind oft nicht urheberrechtlich geschützt Qualitätssicherung Prüfung auf Halluzinationen, Bias, Falschinformationen 5. Entwicklung & Beschaffung (Shadow AI verhindern) Zentrale Freigabe Verbot privater Accounts für geschäftliche Nutzung Nutzung nur über Unternehmensaccounts Third Party Risk Management Prüfung von SOC2, ISO 27001, DPA, Subprozessoren Secure Coding Regeln für KI gestützte Programmierung (z. B. Copilot) Kein Einfügen vertraulichen Codes in externe KI Lifecycle Management Dokumentation, Monitoring, Decommissioning von KI Systemen 6. Ethische Leitlinien & Bias-Vermeidung Diskriminierungsverbot KI darf keine Personengruppen benachteiligen Transparenz Nutzer müssen informiert werden, wenn sie mit KI interagieren Fairness & Nachvollziehbarkeit Entscheidungen müssen erklärbar sein Einsatzgrenzen Keine KI Entscheidungen ohne menschliche Kontrolle in HR, Legal, Finance 7. Incident Management & Sanktionen Meldepflicht Sofortige Meldung, wenn sensible Daten versehentlich in KI eingegeben wurden Integration in Datenschutzvorfall Prozess Reaktionsmaßnahmen Löschung, Benachrichtigung, Forensik, Risikobewertung Konsequenzen Arbeitsrechtliche Maßnahmen bei groben Verstößen Dokumentation im ISMS 8. Schulung & Awareness Regelmäßige Trainings Pflichtschulungen zu sicherem Prompting, Datenschutz, Risiken Awareness Materialien Checklisten, Poster, Fallbeispiele, E Learning Kompetenzaufbau Schulung für Entwickler zu Secure AI Coding Schulung für Führungskräfte zu KI Governance 9. Monitoring, Kontrolle & Audit Shadow AI Erkennung Technische Kontrollen (Browser DLP, Netzwerk Monitoring) Regelmäßige Reviews Jährliche Aktualisierung der Richtlinie Audit Trail Dokumentation aller KI Einsätze (Tool, Zweck, Daten, Ergebnis) KPIs Anzahl KI Nutzungen, Verstöße, Vorfälle, Schulungsquote 10. Inkrafttreten & Revision Datum der Einführung Verantwortliche Stelle Revisionszyklus (z. B. jährlich oder bei Gesetzesänderung) Viel Erfolg

Warum Kryptografie in einer SBOM unverzichtbar ist Moderne Software nutzt an vielen Stellen kryptografische Komponenten – oft tief in Frameworks, Bibliotheken oder Protokollen verborgen. Dazu gehören u. a.: • TLS Bibliotheken • Hash Funktionen • Verschlüsselungsalgorithmen • Zertifikate • Schlüsselmaterial • Token Signaturen • Kryptografische Frameworks (OpenSSL, BouncyCastle, libsodium …) Sobald in einem dieser Bausteine eine Schwachstelle entsteht (z. B. Heartbleed, Logjam, SHA 1 Risiken), muss ein Unternehmen sofort erkennen können, ob es betroffen ist. Eine SBOM, die Kryptografie Informationen enthält, macht genau das möglich. A ) Wie CycloneDX Kryptografie abbildet CycloneDX bietet ein eigenes Cryptographic Components Model, mit dem kryptografische Elemente strukturiert erfasst werden können. 1. Kryptografische Algorithmen Beispiele: • AES • RSA • ECDSA • SHA 256 • PBKDF2 • ChaCha20 CycloneDX dokumentiert: • verwendeter Algorithmus • Version • Modus (z. B. AES GCM vs. AES CBC) 2. Kryptografische Bibliotheken Jede Bibliothek kann als Komponente erfasst werden, z. B.: • OpenSSL • BouncyCastle • libsodium • WolfSSL • Microsoft CNG • Java Cryptography Architecture (JCA) Mit Metadaten wie: • Version • Quelle • Hash • Lizenz • CVE Bezug 3. Zertifikate CycloneDX kann Zertifikate als eigene Objekte abbilden: • X.509 Zertifikate • TLS Zertifikate • Code Signing Zertifikate Mit: • Fingerprint • Aussteller • Ablaufdatum • Key Usage • Public Key Algorithmus 4. Schlüsselmaterial (nur Metadaten!) CycloneDX erfasst keine Schlüssel, sondern ausschließlich Metadaten: • Schlüssellänge • Algorithmus • Verwendungszweck (Signatur, Verschlüsselung, TLS Handshake) Das ermöglicht Compliance Nachweise, ohne Sicherheitsrisiken zu erzeugen. 5. Kryptografische Services Auch kryptografische Dienste können modelliert werden, z. B.: • TLS Terminator • HSM Nutzung • Token Signaturdienste • Key Management Systeme B ) Wie CycloneDX Kryptografie erkennt CycloneDX ist ein Format, kein Scanner. Die Erkennung erfolgt durch Tools wie: • Syft • Trivy • CycloneDX CLI • Snyk • OWASP Dependency Track Diese analysieren u. a.: • Bibliotheken • Container • Build Artefakte • Konfigurationsdateien • Zertifikate • Laufzeitumgebungen und erzeugen daraus eine SBOM mit Kryptografie Einträgen. C ) Wie man CycloneDX für Kryptografie sinnvoll nutzt 1. Kryptografische Inventarisierung Frage: „Welche Kryptobibliotheken und Algorithmen verwenden wir überhaupt?“ CycloneDX liefert: • vollständige Liste • Versionen • CVE Risiken 2. Compliance & Regulierung Regulatorien wie NIS2, DORA, ISO 27001, ETSI EN 303 645 verlangen: • sichere Algorithmen • keine veralteten Hashes • keine unsicheren Cipher Suites CycloneDX zeigt z. B.: • ob SHA 1 noch genutzt wird • ob TLS 1.0/1.1 aktiv ist • ob schwache RSA Schlüssel existieren 3. Schwachstellenmanagement Wenn eine Kryptobibliothek eine CVE hat (z. B. OpenSSL): • Wo wird sie verwendet? • In welcher Version? • In welchen Produkten oder Komponenten? CycloneDX ermöglicht sofortige Impact Analysen. 4. Lieferkettensicherheit CycloneDX zeigt, ob Drittanbieter: • unsichere Algorithmen nutzen • abgelaufene Zertifikate einsetzen • veraltete Bibliotheken einbinden Damit wird Kryptografie zu einem prüfbaren Bestandteil des Software Supply Chain Risikos. D ) Checkliste für SBOM Kryptografie Check (für CycloneDX, NIS2, Secure SDLC, Lieferkettensicherheit) 1. Vollständigkeit der Kryptografie Erfassung • Enthält die SBOM kryptografische Komponenten gemäß CycloneDX Crypto Model? • Werden alle relevanten Kryptoelemente erfasst: o Algorithmen o Bibliotheken o Zertifikate o Schlüsselmaterial (nur Metadaten) o Kryptografische Services • Sind auch transitive Abhängigkeiten berücksichtigt? • Prüfen, ob Tools wie Syft/Trivy/Snyk korrekt konfiguriert sind. • Prüfen, ob Container Images und Build Artefakte gescannt wurden. 2. Kryptografische Algorithmen • Sind alle verwendeten Algorithmen dokumentiert? • Werden unsichere oder veraltete Algorithmen genutzt? o SHA 1 o MD5 o RSA < 2048 Bit o AES CBC ohne zusätzliche Integrität • Sind die Betriebsmodi korrekt dokumentiert (z. B. AES GCM vs. AES CBC)? • Abgleich mit BSI TR 02102, NIST SP 800 131A, ETSI Empfehlungen. 3. Kryptografische Bibliotheken • Sind alle Kryptobibliotheken als Komponenten erfasst? • Sind Version, Hash, Lizenz und Quelle dokumentiert? • Gibt es bekannte CVEs zu diesen Bibliotheken? • Werden veraltete oder ungepatchte Versionen eingesetzt? • Speziell prüfen: OpenSSL, BouncyCastle, libsodium, WolfSSL. 4. Zertifikate • Sind alle Zertifikate in der SBOM enthalten? • Sind folgende Metadaten vollständig: o Fingerprint o Aussteller o Ablaufdatum o Key Usage o Public Key Algorithmus • Gibt es abgelaufene oder bald ablaufende Zertifikate? • Werden schwache Schlüssel verwendet? • Prüfen auf TLS 1.0/1.1, Self Signed Certificates, SHA 1 Signaturen. 5. Schlüsselmaterial (Metadaten) • Werden nur Metadaten erfasst (keine Schlüssel selbst)? • Sind Schlüssellängen und Algorithmen dokumentiert? • Ist der Verwendungszweck klar (Signatur, Verschlüsselung, TLS Handshake)? • Gibt es Hinweise auf schwache Schlüssel? • Prüfen auf RSA < 2048 Bit, ECC < 256 Bit. 6. Kryptografische Services • Sind externe oder interne Kryptoservices dokumentiert? o HSM o Key Management Systeme o Token Signaturdienste o TLS Terminatoren • Sind deren Versionen und Konfigurationen nachvollziehbar? • Prüfen, ob Schlüsselrotation dokumentiert ist. 7. Schwachstellenmanagement • Werden kryptografische Komponenten regelmäßig auf CVEs geprüft? • Gibt es Prozesse zur Bewertung kryptografischer Schwachstellen? • Ist dokumentiert, wo eine betroffene Bibliothek eingesetzt wird? • Gibt es definierte Reaktionszeiten (MTTD/MTTR)? • Prüfen, ob Dependency Track oder Snyk Alerts genutzt werden. 8. Lieferkettensicherheit • Enthält die SBOM kryptografische Informationen von Drittanbietern? • Werden unsichere Algorithmen oder abgelaufene Zertifikate in Fremdkomponenten erkannt? • Gibt es Anforderungen an Lieferanten zur Kryptografie Hygiene? • Prüfen, ob AV Verträge oder SLA kryptografische Mindeststandards enthalten. 9. Compliance & Regulierung • Erfüllt die Kryptografie die Anforderungen aus: o NIS2 o DORA o ISO 27001 o DSGVO Art. 32 o BSI Empfehlungen • Werden unsichere Cipher Suites aktiv verhindert? • Gibt es dokumentierte Kryptografie Policies? • Prüfen, ob „Crypto Agility“ vorgesehen ist (schneller Algorithmuswechsel). 10. Dokumentation & Governance • Ist die Kryptografie SBOM vollständig versioniert? • Gibt es Verantwortlichkeiten (Owner, Maintainer)? • Ist die SBOM in CI/CD integriert? • Werden Änderungen an Kryptokomponenten automatisch erkannt? • Prüfen, ob SBOM Updates Teil des Release Prozesses sind. Kurzversion : 10 Punkte Check 1. Alle Kryptokomponenten vollständig erfasst? 2. Sichere Algorithmen und Betriebsmodi? 3. Kryptobibliotheken aktuell und ohne CVEs? 4. Zertifikate gültig und sicher? 5. Schlüsselmetadaten vollständig und sicher? 6. Kryptoservices dokumentiert? 7. Schwachstellenmanagement aktiv? 8. Lieferkette kryptografisch bewertet? 9. Compliance Anforderungen erfüllt? 10. SBOM Governance etabliert?

Eine Software Bill of Materials (SBOM) ist eine Stückliste aller Bauteile einer Software — ähnlich wie die Zutatenliste auf einer Lebensmittelverpackung. Sie zeigt: • Welche Komponenten in einer Software enthalten sind • Welche Versionen verwendet werden • Woher die Komponenten stammen • Welche Risiken (z. B. CVEs) damit verbunden sind Warum das wichtig ist: Moderne Software besteht zu 70–90% aus Fremdkomponente n (Open Source, Bibliotheken, Frameworks). Wenn dort eine Schwachstelle auftaucht, muss man wissen: Sind wir betroffen? Wo genau? Wie kritisch? Eine SBOM liefert genau diese Transparenz. Wer fordert eine SBOM? • NIS2 (EU) • DORA (Finanzsektor) • US Executive Order 14028 • ISO 27001 / TISAX (indirekt über Lieferketten Sicherheit) • Viele Kunden in Automotive, Health, KRITIS SBOMs sind also längst ein Pflichtbestandteil moderner Software Sicherheit. Was muss mindestens in einer SBOM enthalten sein? (Mindestanforderungen) Die Mindestanforderungen orientieren sich an NTIA und CycloneDX/SPDX Standards. 1. Komponenteninformationen • Name der Komponente • Version • Hersteller / Quelle • Lizenztyp 2. Identifikatoren • Package URL (purl) • Hash (z. B. SHA 256) • SPDX ID oder CycloneDX ID 3. Abhängigkeiten • Welche Komponenten hängen voneinander ab? 4. Metadaten • Erstellungsdatum • Ersteller (Firma/Tool) • SBOM Format (SPDX, CycloneDX) Was enthält eine ideale SBOM? (Best Practice) Eine ideale SBOM geht deutlich weiter: 5. Sicherheitsinformationen • Bekannte CVEs pro Komponente • CVSS Scores • Exploit Status (z. B. CISA KEV) • Patch Status 6. Integritätsinformationen • Signaturen • Hashes aller Dateien • Lieferketten Nachweise (SLSA Level) 7. Build Informationen • Build Server • Build Pipeline • Compiler Version • verwendete Flags 8. Lizenz Compliance • Lizenztyp • Lizenzrisiken • Nutzungseinschränkungen 9. Runtime Informationen • Welche Komponenten werden tatsächlich genutzt? • Welche sind nur „mitgeliefert“? 10. Abhängigkeitsgraph • Visualisierung aller Beziehungen • Erkennung kritischer Ketten Wichtige Tools zur Erstellung einer SBOM Automatisierte SBOM Generatoren • CycloneDX CLI • SPDX Tools • Syft (Anchore) • Trivy • Snyk • GitHub SBOM Export • GitLab Dependency Scanning CI/CD Integration • GitHub Actions • GitLab CI • Azure DevOps Pipelines

Neben Produktqualität und Kundenzufriedenheit verfolgt das Qualitätsmanagement eine Vielzahl strategischer, operativer und organisatorischer Ziele. Die folgende Übersicht bietet klare Zieldefinitionen, passende KPIs und konkrete Metriken – ideal für IMS Kontexte, Workshops oder Zielsysteme. 1. Prozessqualität • Ziel: Interne Prozesse optimieren und Fehler minimieren • KPI: Fehlerquote pro Prozess • Metrik: z.B. Anzahl fehlerhafter Aufträge pro Monat 2. Effizienzsteigerung / Kostenreduktion • Ziel: Ressourcen effizient nutzen und Kosten senken • KPI: Produktionskosten pro Einheit • Metrik: €/Produkt oder €/Dienstleistung 3. Termintreue / Liefertreue • Ziel: Pünktliche Lieferung von Produkten und Dienstleistungen • KPI: Anteil termingerechter Lieferungen • Metrik: Pünktliche Lieferungen / Gesamtlieferungen × 100 4. Fehlervermeidung (Prevention statt Detection) • Ziel: Fehler bereits im Entstehungsprozess verhindern • KPI: Anzahl Abweichungen in internen Audits • Metrik: Abweichungen pro Audit 5. Kontinuierliche Verbesserung (Kaizen) • Ziel: Prozesse und Produkte fortlaufend verbessern • KPI: Anzahl umgesetzter Verbesserungsvorschläge • Metrik: Vorschläge pro Quartal 6. Mitarbeiterzufriedenheit / Engagement • Ziel: Motivierte, qualifizierte und engagierte Mitarbeitende • KPI: Zufriedenheitsindex aus Mitarbeiterbefragungen • Metrik: Bewertungsskala 1–5 7. Innovationsfähigkeit • Ziel: Neue Produkte und Dienstleistungen entwickeln • KPI: Anzahl eingeführter Innovationen pro Jahr • Metrik: Produkteinführungen pro Jahr 8. Risikomanagement • Ziel: Prozess- und Produktrisiken reduzieren • KPI: Anzahl identifizierter und behobener kritischer Risiken • Metrik: Risikobehebungsquote (%) 9. Lieferantenqualität • Ziel: Qualität und Zuverlässigkeit der Zulieferer sicherstellen • KPI: Anteil fehlerfreier Lieferungen • Metrik: Fehlerfreie Lieferungen / Gesamtlieferungen × 100 10. Nachhaltigkeit / Umweltbewusstsein • Ziel: Ressourcen schonen und Umweltbelastungen reduzieren • KPI: Anteil recycelter Materialien • Metrik: kg recyceltes Material pro Monat 11. Compliance / Gesetzestreue • Ziel: Einhaltung aller relevanten Normen und regulatorischen Anforderungen • KPI: Anzahl Compliance Verstöße • Metrik: Verstöße pro Jahr 12. Flexibilität / Reaktionsfähigkeit • Ziel: Schnelle Anpassung an Markt und Kundenanforderungen • KPI: Dauer zur Umsetzung neuer Anforderungen • Metrik: Tage bis zur Umsetzung 13. Prozessstabilität / Robustheit • Ziel: Konsistente und verlässliche Prozessergebnisse • KPI: Standardabweichung relevanter Prozesskennzahlen • Metrik: σ von Durchlaufzeiten oder Output 14. Dokumentationsqualität • Ziel: Vollständige, aktuelle und normgerechte QM Dokumentation • KPI: Anteil aktueller SOPs / Prozesse • Metrik: % der dokumentierten Prozesse auf aktuellem Stand 15. Wissensmanagement / Kompetenzentwicklung • Ziel: Know how sichern und kontinuierlich weiterentwickeln • KPI: Anzahl durchgeführter Schulungen • Metrik: Schulungsstunden pro Mitarbeitendem pro Jahr

Neben den klassischen primären Schutzzielen der Informationssicherheit – Vertraulichkeit (V) (C- Confidentiality), Integrität (I) und Verfügbarkeit (V) (Availability) – können in modernen IT Landschaften (Cloud, KI, vernetzte Systeme) weitere Ziele relevant werden. Prüfen Sie, welche davon für Ihr Unternehmen zusätzlichen Mehrwert bieten: Kernziele der Informationssicherheit • Confidentiality / Vertraulichkeit Informationen sind nur für berechtigte Personen zugänglich. • Integrity / Unveränderbarkeit Informationen bleiben vollständig, korrekt und frei von Manipulation. • Availability / Verfügbarkeit Informationen stehen dort und dann bereit, wo sie benötigt werden. Erweiterte Sicherheitsziele Diese Ziele gewinnen insbesondere in komplexen, digitalisierten und KI gestützten Umgebungen an Bedeutung: • Resilience & Recoverability – Fähigkeit, Störungen zu überstehen und den Betrieb schnell wiederherzustellen (Business Continuity). • Accountability & Auditability – Nachvollziehbarkeit von Handlungen und Entscheidungen (Governance, Compliance). • Trustworthiness & Misuse Resistance – Vertrauenswürdigkeit und Missbrauchsresistenz von KI Systemen. • Supply Chain Security – Schutz vor Risiken in zunehmend komplexen Lieferketten. Weitere mögliche Schutzziele (je nach Unternehmenskontext) • Continuity / Kontinuität – Durchgehende Verfügbarkeit von Informationen und Prozessen. • Recoverability / Wiederherstellbarkeit – Wiederherstellung nach Verlust oder Ausfall. • Authenticity / Authentizität – Echtheit von Identitäten, Daten und Systemen. • Non Repudiation / Nicht Abstreitbarkeit – Handlungen können nicht abgestritten werden (z. B. digitale Signaturen). • Attributability / Zurechenbarkeit – Klare Zuordnung von Informationen zu Ursprung, Eigentümer oder Verantwortlichen. • Controllability / Steuerbarkeit – Kontrolle über Systeme, insbesondere in OT/IoT/SCADA Umgebungen. • Anonymity / Anonymität – Schutz personenbezogener Daten im Sinne von DSGVO; Balance zwischen zu viel und zu wenig Information. • Transparency – Nachvollziehbarkeit von Systemverhalten, insbesondere bei KI. • Privacy – Schutz der Privatsphäre und personenbezogener Daten. • Data Minimization – Verarbeitung nur der notwendigsten Daten. • Purpose Limitation / Zweckbindung – Nutzung von Daten ausschließlich für definierte Zwecke. • Robustness / Robustheit – Widerstandsfähigkeit von Systemen gegen Fehler, Angriffe und Missbrauch. Die folgenden Sicherheitsziele können – je nach Unternehmenskontext, Regulierung und Technologieeinsatz (Cloud, KI, OT, IoT) – zusätzlich definiert werden. Jedes Ziel enthält eine klare Zielformulierung, eine kurze Erklärung sowie geeignete KPIs/Metriken zur Messbarkeit. 1. Authentizität (Authenticity) • Zielformulierung: Sicherstellung echter und überprüfbarer Identitäten • Erklärung: Nur legitimierte Personen und Systeme dürfen auftreten • Ziel: 100 % authentifizierte Zugriffe • KPIs: MFA Quote (%) Fehlgeschlagene Login Versuche 2. Autorisierung (Authorization) • Zielformulierung: Sicherstellung korrekter Zugriffsbeschränkungen • Erklärung: Nur berechtigte Zugriffe sind erlaubt • Ziel: Keine unautorisierten Zugriffe • KPIs: Anzahl unautorisierter Zugriffe 3. Nachvollziehbarkeit (Accountability) • Zielformulierung: Aktionen sind eindeutig zuordenbar • Erklärung: Verantwortlichkeiten sind klar dokumentiert • Ziel: 100 % Logging kritischer Aktionen • KPIs: Logging Abdeckung (%) 4. Auditierbarkeit (Auditability) • Zielformulierung: Systeme sind prüfbar und revisionssicher • Erklärung: Interne und externe Audits sind jederzeit möglich • Ziel: Alle Systeme auditierbar • KPIs: Anzahl Audit Findings 5. Transparenz (Transparency) • Zielformulierung: Prozesse sind nachvollziehbar dokumentiert • Erklärung: Entscheidungen und Abläufe sind verständlich • Ziel: Vollständige Prozessdokumentation • KPIs: Dokumentationsgrad (%) 6. Datenschutz (Privacy) • Zielformulierung: Schutz personenbezogener Daten • Erklärung: Keine unzulässige Verarbeitung • Ziel: 0 Datenschutzvorfälle • KPIs: Anzahl Datenschutzverletzungen Zeit bis zur Meldung (DSGVO: 72 h) 7. Datenminimierung (Data Minimization) • Zielformulierung: Verarbeitung nur notwendiger Daten • Erklärung: Reduktion von Datenrisiken • Ziel: Minimierung gespeicherter Daten • KPIs: Datenvolumen pro Prozess Anteil unnötiger Datenfelder (%) 8. Zweckbindung (Purpose Limitation) • Zielformulierung: Nutzung von Daten nur für definierte Zwecke • Erklärung: Keine Zweckentfremdung • Ziel: 0 Verstöße gegen Zweckbindung • KPIs: Anzahl Zweckbindungsverstöße 9. Resilienz (Resilience) • Zielformulierung: Systeme bleiben trotz Störungen funktionsfähig • Erklärung: Widerstandsfähigkeit gegen Angriffe und Ausfälle • Ziel: Minimale Ausfallzeiten • KPIs: MTBF (Mean Time Between Failures) Erfolgsquote von Wiederanlauf Tests 10. Wiederherstellbarkeit (Recoverability) • Zielformulierung: Schnelle Wiederherstellung nach Störungen • Erklärung: Minimierung von Daten- und Funktionsverlust • Ziel: RTO < 4 h, RPO < 1 h • KPIs: RTO (Recovery Time Objective) RPO (Recovery Point Objective) 11. Kontinuität (Continuity) • Zielformulierung: Durchgehende Verfügbarkeit • Erklärung: Keine ungeplanten Unterbrechungen • Ziel: ≥ 99,9 % Verfügbarkeit • KPIs: Verfügbarkeitsrate (%) 12. Robustheit (Robustness) • Zielformulierung: Systeme reagieren stabil auf Fehler • Erklärung: Fehlertoleranz und Stabilität • Ziel: Minimale Systemabstürze • KPIs: Absturzrate Fehlerquote bei Lasttests 13. Missbrauchsschutz (Misuse Resistance) • Zielformulierung: Schutz vor missbräuchlicher Nutzung • Erklärung: Systeme verhindern Fehl- und Angriffsverhalten • Ziel: Keine erfolgreichen Missbrauchsfälle • KPIs: Anzahl erkannter Missbrauchsversuche False Positive Rate von Schutzmechanismen 14. Konformität (Compliance) • Zielformulierung: Einhaltung von Gesetzen und Standards • Erklärung: Minimierung regulatorischer Risiken • Ziel: 100 % Compliance • KPIs: Anzahl Compliance Verstöße Audit Abweichungen 15. Interoperabilität (Interoperability) • Zielformulierung: Sichere Zusammenarbeit von Systemen • Erklärung: Fehlerfreie und abgesicherte Schnittstellen • Ziel: Stabile und sichere API Kommunikation • KPIs: Anzahl Schnittstellenfehler Anteil abgesicherter APIs (%) 16. Datenqualität (Data Quality) • Zielformulierung: Hohe Qualität und Aktualität von Daten • Erklärung: Verlässliche Entscheidungsgrundlagen • Ziel: Minimale Datenfehler • KPIs: Fehlerquote in Datensätzen Aktualitätsrate (%) 17. Lieferkettensicherheit (Supply Chain Security) • Zielformulierung: Sicherheit entlang der gesamten Lieferkette • Erklärung: Drittanbieter stellen kein Risiko dar • Ziel: Alle kritischen Lieferanten geprüft • KPIs: Third Party Risk Score Anzahl kritischer Lieferanten ohne Audit 18. Reaktionsfähigkeit (Responsiveness) • Zielformulierung: Schnelle Reaktion auf Sicherheitsvorfälle • Erklärung: Minimierung von Schaden und Ausfall • Ziel: Reaktionszeit < 1 h • KPIs: MTTD (Mean Time to Detect) MTTR (Mean Time to Respond) 19. Nicht Abstreitbarkeit (Non Repudiation) • Zielformulierung: Aktionen sind beweisbar • Erklärung: Digitale Signaturen und Nachweise • Ziel: Alle kritischen Aktionen nachweisbar • KPIs: Anteil signierter Aktionen 20. Zurechenbarkeit (Attributability) • Zielformulierung: Ursprung und Verantwortliche sind nachvollziehbar • Erklärung: Klare Zuordnung von Events • Ziel: 100 % attributierbare Events • KPIs: Anteil attributierbarer Events 21. Steuerbarkeit (Controllability) • Zielformulierung: Systeme bleiben kontrollierbar • Erklärung: Besonders relevant für OT, SCADA, IoT • Ziel: Keine unkontrollierten Systemzustände • KPIs: Anzahl unautorisierter Steuerungsversuche 22. Anonymität (Anonymity) • Zielformulierung: Schutz der Identität von Personen • Erklärung: Minimierung identifizierbarer Daten • Ziel: Maximale Anonymisierung • KPIs: Anteil anonymisierter Daten 23. Vertrauenswürdigkeit (Trustworthiness) • Zielformulierung: Vorhersagbares und korrektes Systemverhalten • Erklärung: Besonders wichtig bei KI Systemen • Ziel: Minimale Fehlentscheidungen • KPIs: Anzahl unerwarteter Systementscheidungen KI Halluzinationsrate (%) 24. Skalierbarkeit (Scalability) • Zielformulierung: Sicherheit auch bei Wachstum • Erklärung: Systeme bleiben performant und sicher • Ziel: Keine Sicherheitsverluste bei Last • KPIs: Performance unter Last (%) Sicherheitsvorfälle bei Lastspitzen 25. Wartbarkeit (Maintainability) • Zielformulierung: Systeme können sicher gepflegt werden • Erklärung: Schnelle und sichere Updates • Ziel: Kurze Patch Zyklen • KPIs: Mean Time to Patch Anteil Systeme mit aktuellem Patchlevel (%) Auch Prozesse sollten eigene Ziele und KPIs besitzen – z.B.: die Durchdringung der Awareness Schulungen in der Belegschaft, die Patch Aktualität der Systeme oder der Anteil vollständig dokumentierter Risikobewertungen, etc. Achtung, es gibt sicher weitere Ziele die auch nichts mit Informationssicherheit zu tun haben, Projektziele, kaufmännische Ziele, Umsatzziele, strategische Ziele ... Viele Erfolg, Ihr Konstantin Ziouras

CVE bedeutet „Common Vulnerabilities and Exposures“, Eine CVE ist einmalig wie eine ISBN Nummer für Sicherheitslücken Sie sorgt dafür, dass alle Hersteller, Sicherheitsfirmen und Behörden über dieselbe Schwachstelle sprechen — ohne Verwirrung. Beispiel: CVE 2021 44228 = Log4Shell (eine der gefährlichsten Lücken der letzten Jahre) Woher kommt die Nummerierung? Jede CVE hat das Format: Code CVE-JAHR-Laufende Nummer Beispiel: CVE 2024-12345 • 2024 = Jahr der Registrierung • 12345 = eindeutige ID Die Nummern werden nicht nach Schwere sortiert, sondern einfach fortlaufend vergeben. Wer verwaltet das CVE System? Das CVE Programm wird betrieben von: 1. MITRE Corporation • eine Non Profit Organisation in den USA • arbeitet im Auftrag der US Regierung • verwaltet die CVE Datenbank • koordiniert die Vergabe der IDs • https://attack.mitre.org/ 2. US Behörde CISA • unterstützt das Programm • veröffentlicht Warnungen • betreibt die „Known Exploited Vulnerabilities“ (KEV) Liste 3. CNA Organisationen (CVE Numbering Authorities) Das sind Firmen, die selbst CVEs vergeben dürfen, z. B.: • Microsoft • Google • Cisco • Intel • Red Hat • Siemens • GitHub • Palo Alto Networks Insgesamt über 300 CNAs weltweit. Wie entsteht eine CVE? (Der Prozess) 1. Forscher oder Hersteller entdeckt eine Schwachstelle 2. Meldung an MITRE oder eine CNA 3. Prüfung, ob es eine neue, eigenständige Lücke ist 4. Vergabe einer CVE Nummer 5. Veröffentlichung der Details (ohne Exploit Code) 6. Hersteller veröffentlicht Updates / Patches 7. CVSS Bewertung (Schweregrad) wird vergeben Wie wird die Schwere bewertet? (CVSS) CVSS = Common Vulnerability Scoring System Skala von 0.0 bis 10.0 Bereich Bedeutung 0.0–3.9 Niedrig 4.0–6.9 Mittel 7.0–8.9 Hoch 9.0–10.0 Kritisch Beispiel: Log4Shell → CVSS 10.0 (kritisch) Kategorien von CVEs CVE Einträge werden nicht offiziell nach Kategorien sortiert, aber in der Praxis unterscheidet man: 1. Betriebssysteme • Windows • Linux (Ubuntu, Debian, Red Hat) • macOS 2. Netzwerkgeräte • Firewalls (Fortinet, Palo Alto, Cisco ASA) • Router & Switches • VPN Gateways 3. Cloud Dienste • AWS • Azure • Google Cloud 4. Web Anwendungen • WordPress • Drupal • Apache • Nginx 5. Software Bibliotheken • Log4j • OpenSSL • Python Pakete • Node.js Module 6. Mobile Systeme • Android • iOS 7. Industrielle Systeme (OT/ICS) • Siemens • Schneider Electric • Rockwell Automation Wichtige Tools & Module zur Arbeit mit CVEs 1. Schwachstellenscanner (automatisch), z.B. • Nessus • Qualys • Rapid7 InsightVM • OpenVAS Diese Tools scannen Systeme und melden bekannte CVEs. 2. Paket und Dependency Scanner • GitHub Dependabot • GitLab Dependency Scanning • Snyk • Mend (WhiteSource) Sie prüfen Bibliotheken in Softwareprojekten. 3. Container Scanner • Trivy • Anchore • Clair Sie prüfen Docker Images auf CVEs. 4. Betriebssystem Scanner • Microsoft Defender Vulnerability Management • Lynis (Linux) • OSQuery 5. Offizielle CVE Datenbanken • MITRE CVE Database • NVD (National Vulnerability Database) • CISA KEV Catalog (besonders wichtig für Exploits in freier Wildbahn) Kurz erklärt: Warum CVEs wichtig sind • Sie schaffen Transparenz über Sicherheitslücken • Sie ermöglichen Vergleichbarkeit • Sie sind Grundlage für Patch Management • Sie sind Pflichtbestandteil von ISO 27001, TISAX, NIS2 • Sie helfen Unternehmen, Risiken zu priorisieren