Konstantin Ziouras (Dipl. Ing.)

Unterschiede zwischen EULA, SLA und AVV

Risiken bezüglich Lieferanten

Lieferanten, Auswahl und Bewertung

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