Konstantin Ziouras (Dipl. Ing.)

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

Ein integriertes Managementsystem vereint unterschiedliche Disziplinen wie Informationssicherheit, Qualitätsmanagement und Datenschutz. Jede dieser Disziplinen verfolgt eigene Schutzziele, Qualitätsziele und regulatorische Anforderungen. Gleichzeitig gibt es zahlreiche Überschneidungen, Synergien und gemeinsame Erfolgsfaktoren. Die folgende Zielmatrix zeigt beispielhaft, wie sich Ziele aus ISMS, QMS und Datenschutz miteinander verbinden lassen. Sie dient als Orientierung, um eigene Zieldefinitionen zu entwickeln, passende KPIs auszuwählen und konkrete Metriken festzulegen. So entsteht ein harmonisiertes Zielsystem, das Transparenz schafft, Redundanzen reduziert und die Wirksamkeit des gesamten IMS stärkt. 1. Prozessqualität & Prozesssicherheit ISMS: Sichere, stabile und kontrollierte Prozesse QMS: Fehlerarme, effiziente und standardisierte Abläufe Datenschutz: DSGVO konforme Verarbeitung in allen Prozessschritten KPIs / Metriken: • Fehlerquote pro Prozess • Anzahl Sicherheitsvorfälle pro Prozess • Anteil DSGVO konformer Prozessschritte (%) 2. Verfügbarkeit & Kontinuität ISMS: Hohe Systemverfügbarkeit, Notfallmanagement QMS: Termintreue, stabile Lieferfähigkeit Datenschutz: Sicherstellung der Datenverfügbarkeit (Art. 32 DSGVO) KPIs / Metriken: • Verfügbarkeit (%) • RTO / RPO • Pünktliche Lieferungen (%) 3. Vertraulichkeit & Datenschutz ISMS: Schutz sensibler Informationen QMS: Schutz vertraulicher Kunden und Produktdaten Datenschutz: Schutz personenbezogener Daten (Privacy by Design) KPIs / Metriken: • Anzahl Datenschutzvorfälle • MFA Quote (%) • Klassifizierte Datenbestände (%) 4. Integrität & Datenqualität ISMS: Schutz vor Manipulation QMS: Korrekte, vollständige und aktuelle Daten Datenschutz: Richtigkeit personenbezogener Daten (Art. 5 DSGVO) KPIs / Metriken: • Fehlerquote in Datensätzen • Anzahl Integritätsverletzungen • Aktualitätsrate (%) 5. Nachvollziehbarkeit & Auditierbarkeit ISMS: Logging, Monitoring, Non Repudiation QMS: Revisionssichere Dokumentation Datenschutz: Nachweisbarkeit der DSGVO Konformität KPIs / Metriken: • Logging Abdeckung (%) • Audit Findings • Anzahl dokumentierter Verarbeitungstätigkeiten 6. Kontinuierliche Verbesserung ISMS: Verbesserung der Sicherheitsmaßnahmen QMS: Kaizen, Lean, Prozessoptimierung Datenschutz: Verbesserung von TOMs und Datenschutzprozessen KPIs / Metriken: • Anzahl umgesetzter Verbesserungen • Reduktion von Risiken (%) • Anzahl aktualisierter TOMs 7. Mitarbeiterkompetenz & Awareness ISMS: Security Awareness, Phishing Resilienz QMS: Qualifikation und Engagement Datenschutz: Datenschutzschulungen KPIs / Metriken: • Awareness Durchdringung (%) • Schulungsstunden pro Mitarbeitendem • Phishing Erfolgsquote (%) 8. Risikomanagement ISMS: Informationssicherheitsrisiken QMS: Prozess und Produktrisiken Datenschutz: Datenschutz Folgenabschätzungen (DSFA) KPIs / Metriken: • Anzahl kritischer Risiken • Risikobehebungsquote (%) • Anzahl DSFA durchgeführt 9. Lieferkettensicherheit & Lieferantenqualität ISMS: Third Party Risk Management QMS: Qualität der Zulieferer Datenschutz: Auftragsverarbeitung (AVV), Drittlandtransfers KPIs / Metriken: • Third Party Risk Score • Fehlerfreie Lieferungen (%) • Anteil geprüfter AV Verträge (%) 10. Nachhaltigkeit & Compliance ISMS: Einhaltung von Normen (ISO 27001, NIS 2) QMS: Normkonformität (ISO 9001) Datenschutz: DSGVO Compliance KPIs / Metriken: • Anzahl Compliance Verstöße • Audit Abweichungen • Anteil recycelter Materialien Kurzfassung als Management Übersicht

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

Ohne Anspruch auf Vollständigkeit

Die Auswahl eines Developer Tools oder Code Repository Systems ist längst keine rein technische Entscheidung mehr. Moderne Softwareentwicklung ist komplex, global verteilt und sicherheitskritisch. Unternehmen müssen daher Plattformen wählen, die nicht nur funktional überzeugen, sondern auch höchsten Anforderungen an Informationssicherheit, Compliance und strategische Zukunftsfähigkeit gerecht werden. 1. Funktionale Anforderungen: Die Basis für effiziente Entwicklung Ein leistungsfähiges Developer Tool muss moderne Git Workflows unterstützen, flexible Code Review Prozesse ermöglichen und sich nahtlos in bestehende Toolchains integrieren. Besonders wichtig sind: • Versionierung & Branching Modelle wie Git Flow oder trunk based Development • Integrierte CI/CD Pipelines, die Builds und Deployments automatisieren • Integrationen zu IDEs, Ticketing Systemen, Container Registries und Secrets Management • Skalierbarkeit, um große Monorepos und tausende parallele Build Jobs zu bewältigen • Betriebsmodell: Self Hosting für maximale Kontrolle oder SaaS für schnelle Skalierung Diese Kriterien bestimmen, wie produktiv Teams arbeiten können und wie gut sich die Plattform in bestehende Entwicklungsprozesse einfügt. 2. Informationssicherheit: Der entscheidende Faktor Da Source Code ein zentrales Unternehmensasset ist, stehen Sicherheitsanforderungen im Mittelpunkt. Moderne Plattformen müssen umfassende Schutzmechanismen bieten, darunter: • Identity & Access Management mit SSO, SAML, SCIM, MFA und fein granularen RBAC Modellen • Security Scanning wie SAST, SCA, DAST und IaC Analysen • Supply Chain Security, etwa signierte Commits, SBOM Unterstützung und automatisierte Dependency Updates • Audit & Compliance durch unveränderbare Logs und SIEM Anbindung • Zero Trust Prinzipien wie Least Privilege, Branch Protection und verpflichtende Reviews Diese Funktionen sind entscheidend, um Risiken wie Code Manipulation, Credential Leaks oder Supply Chain Angriffe zu minimieren. 3. Strategische Kriterien: Zukunftssicherheit und Unternehmensrisiken Neben Funktionalität und Sicherheit spielen strategische Überlegungen eine immer größere Rolle: • Datenhoheit: Dürfen Quellcodes in einer US Cloud liegen oder ist EU Hosting bzw. On Premise erforderlich • Skalierbarkeit: Wie verhält sich das System bei extremen Lastspitzen • Vendor Lock in: Wie einfach ist eine spätere Migration • Erweiterbarkeit: Gibt es APIs und ein Plugin Ökosystem für interne Tools Diese Faktoren entscheiden darüber, ob die Plattform langfristig tragfähig ist und sich an zukünftige Anforderungen anpassen lässt. 4. Kritische Sicherheitsfeatures: Must Haves für moderne DevSecOps Einige Funktionen gelten heute als unverzichtbar: • Fine grained RBAC für präzise Zugriffskontrolle • Branch Protection zur Durchsetzung des Vier Augen Prinzips • Secret Scanning zur Vermeidung von Credential Leaks • Audit Logging für Compliance und forensische Analysen • SCA & SAST für automatisierte Schwachstellenerkennung • SAML/SSO & SCIM für zentrale Identitätsverwaltung Diese Features bilden das Fundament einer sicheren und skalierbaren Entwicklungsumgebung. Übersicht der Entscheidungskriterien für Developer Tools & Code Repositories, etwas detaillierter 1. Funktionale Kriterien Versionierung & Branching-Modell • Git Flow • Trunk based Development • Granulare Berechtigungen (fein abgestufte Zugriffsrechte) Code Review Workflows • PRs (Pull Requests) • Merge Checks • Reviewer Zuweisung CI/CD Integration • CI (Continuous Integration) • CD (Continuous Delivery / Continuous Deployment) • Nativ oder über Plugins Integrationen • IDE (Integrated Development Environment) • Ticketing-Systeme • Secrets Management • Container Registry Skalierbarkeit & Performance • Große Monorepos • LFS (Large File Storage) • Verteilte Teams / globale Standorte Betriebsmodell • Self Hosting • SaaS (Software as a Service) • Compliance Anforderungen • Kosten & Kontrolle 2. Informationssicherheitsrelevante Kriterien Identity & Access Management • SSO (Single Sign-On) • SAML (Security Assertion Markup Language) • SCIM (System for Cross-domain Identity Management) • MFA (Multi-Factor Authentication) • RBAC (Role-Based Access Control) • Fein granulare Rechte Security Scanning • SAST (Static Application Security Testing) • SCA (Software Composition Analysis) • DAST (Dynamic Application Security Testing) • Secret Scanning • IaC Scanning (Infrastructure as Code Scanning) Supply Chain Security • Signierte Commits (GPG – GNU Privacy Guard / Sigstore) • SBOM (Software Bill of Materials) • Automatisierte Dependency Updates Audit & Compliance • Audit Logs • Unveränderbare Logs (Immutable Logging) • Exportfähigkeit • SIEM Integration (Security Information and Event Management) Data Governance • Verschlüsselung at rest (Daten im Ruhezustand) • Verschlüsselung in transit (Daten während der Übertragung) • Geo Hosting • Backup & Restore Zero Trust Fähigkeiten • Least Privilege (Minimalprinzip) • Branch Protection • Mandatory Reviews (erzwungene Vier Augen Prinzipien) Betriebsmodell für regulierte Branchen • On Prem (On-Premise) für Banking, Automotive, Defense Security Hardening • Secret Leak Prevention • Automatisierte Fixes • Policy as Code (Sicherheitsrichtlinien als Code) 3. Strategische Entscheidungskriterien 1. Sovereignty (Datenhoheit) • Cloud vs. On Premise • Dürfen Source Code Daten (IP = Intellectual Property) in einer US Cloud liegen • Bedarf an EU Hosting oder eigenem Rechenzentrum 2. Scalability & Performance • Verhalten bei 10.000+ parallelen Build Jobs • Monorepos im Terabyte Bereich • Build Pipeline Durchsatz 3. Vendor Lock in • Aufwand einer Migration • Risiken bei steigenden Lizenzkosten • Export /Import Fähigkeiten 4. Extensibility • API (Application Programming Interface) • Plugin Ökosystem • Integration interner Tools 4. Kritische Informationssicherheits Features (konkret & operativ) Fine grained RBAC (Role-Based Access Control) • Rollenbasierte Zugriffskontrolle bis auf Branch Ebene Branch Protection • Erzwungene Reviews • Status Checks vor Merge • Keine direkten Pushes auf kritische Branches Secret Scanning • Automatisches Blockieren von Commits mit Passwörtern, API Keys oder Tokens Audit Logging • Lückenlose, manipulationssichere Protokollierung • SIEM Anbindung (Security Information and Event Management) SCA & SAST Integration • Automatisierte Schwachstellenscans in Bibliotheken (SCA) • Statische Codeanalyse (SAST) SAML/SSO & SCIM • Zentrale Identitätsverwaltung • Automatische De Provisionierung bei Mitarbeiter Austritt