Sicher gebaut, zertifiziert, vertrauenswürdig: Das Sicherheits-Framework von Proemion

Wir verfügen über umfassende Kodierungsstandards, die über die OWASP Top 10 hinausgehen und ein breites Spektrum an sicheren Kodierungsrichtlinien abdecken. Diese Standards (die mit der ISO 27001-Kontrolle für sichere Entwicklung übereinstimmen) sind in unseren Entwicklungsprozess integriert - Code kann nicht zusammengeführt und freigegeben werden, wenn er nicht konform ist. Automatisierte sicherheitsorientierte statische Analysen und manuelle Codeüberprüfungen setzen diese Regeln durch und verhindern, dass häufige Schwachstellen jemals in unsere Codebasis gelangen.

Wir führen für alle Codeänderungen ein strenges Peer-Review-Verfahren durch. Erfahrene Ingenieure ("Gatekeeper") führen bei jeder Änderung eine sicherheitsorientierte Codeprüfung durch, bei der die Einhaltung unserer sicheren Codierungsstandards überprüft und potenzielle Schwachstellen identifiziert werden. Dieses Vier-Augen-Prinzip stellt sicher, dass die Sicherheit nicht in der Verantwortung einer einzelnen Person liegt, sondern im gesamten Entwicklungsteam gelebt wird.

Unsere Software-Lieferkette wird genau überwacht. Wir verwenden vertrauenswürdige Quellen für Bibliotheken von Drittanbietern und überwachen Open-Source-Komponenten kontinuierlich auf Schwachstellen. Unsere Versionskontrollplattform weist uns beispielsweise automatisch auf bekannte Schwachstellen in Abhängigkeiten hin, auf die wir dann je nach Schweregrad umgehend reagieren. Außerdem überprüfen wir den Code neuer Module von Drittanbietern vor der Verwendung, bewerten ihre Sicherheit und integrieren sie erst, wenn sie unsere Kriterien erfüllen.

Sicherheit ist Teil unserer "Definition of done" für jede Funktion. Wir integrieren Unit- und Sicherheitstests in die kontinuierliche Integrationspipeline. Wenn ein Fehler oder eine Schwachstelle behoben ist, fügen wir Regressionstests hinzu, um ein erneutes Auftreten zu verhindern. Außerdem testen wir unsere Anwendungen in verschiedenen Phasen des Entwicklungsprozesses, einschließlich umfangreicher automatisierter Tests während der Build- und Staging-Umgebung sowie manueller Tests.

Die Bereitstellung erfolgt durch Code und Automatisierung, um menschliche Fehler zu vermeiden und die Konsistenz zu gewährleisten. Wir stellen unsere Anwendungen in gehärteten Umgebungen bereit, die über Infrastructure-as-Code und Sicherheits-Basismodule konfiguriert werden. Jede Umgebung (Staging, Produktion) wird mit sicheren Konfigurationen bereitgestellt (z. B. Zugriff mit geringsten Rechten, gehärtete Betriebssystemeinstellungen), die den Best Practices der Branche entsprechen. Alle Änderungen an der Cloud-Infrastruktur oder der Geräte-Firmware werden von der Änderungsverwaltung geprüft, und unsere automatisierten Pipelines umfassen Sicherheitsprüfungen vor der Übergabe an die Produktion.

Die in unseren Cloud-Datenbanken und -Endpunkten gespeicherten Daten werden im Ruhezustand verschlüsselt, um sie im Falle eines physischen Verlusts oder eines unbefugten Zugriffs zu schützen. Unsere Cloud-Datenbanken, Dateispeicher und Backups verwenden AES-256-Verschlüsselung, wobei die Schlüssel von gehärteten Schlüsselverwaltungsdiensten verwaltet werden. Laptops und mobile Geräte, die von Proemion-Mitarbeitern verwendet werden, haben eine vollständige Festplattenverschlüsselung aktiviert. Wir befolgen die Branchenrichtlinien (einschließlich NIST SP 800-57) für die Stärke der kryptografischen Schlüssel und die Häufigkeit der Rotation. So werden beispielsweise Kundendaten im Ruhezustand mit AES-256 oder einer neueren Version geschützt, und die Verschlüsselungsschlüssel werden regelmäßig ausgetauscht. Passwörter werden niemals im Klartext gespeichert; wir verwenden ein starkes One-Way-Hashing in Übereinstimmung mit unserer Kryptografierichtlinie.

Kryptographische Schlüssel und Geheimnisse werden mit großer Sorgfalt behandelt. Private Schlüssel (für Server, Geräte, Code Signing usw.) werden in sicheren Tresoren oder Hardware-Sicherheitsmodulen mit strengen Zugangskontrollen (beschränkt auf befugtes Personal und mit Multi-Faktor-Authentifizierung) aufbewahrt. Der Zugang zu den Schlüsseln wird nach dem Prinzip der geringsten Berechtigung in Übereinstimmung mit unserer Zugangskontrollpolitik gewährt. Für besonders kritische Schlüssel, wie z. B. Offline-Schlüssel, die zum Signieren von Geräte-Firmware verwendet werden, verwenden wir ein Verfahren mit geteiltem Wissen und doppelter Kontrolle (siehe Geräte- und Firmware-Sicherheit für weitere Einzelheiten). Die gesamte Schlüsselnutzung wird protokolliert und überwacht, um jeden unbefugten Zugriff zu erkennen. Wir sorgen außerdem für eine sichere Schlüsselgenerierung mit hochwertigen Zufallszahlengeneratoren und verschlüsseln Geheimnisse niemals fest in Code oder Firmware.

Wir kategorisieren Daten (z. B. öffentlich, intern, vertraulich) und wenden für jede Klassifizierung entsprechende Kontrollen an. Personenbezogene Daten und andere vertrauliche Informationen werden in Übereinstimmung mit der GDPR und anderen relevanten Datenschutzbestimmungen behandelt. Wir minimieren die Erfassung personenbezogener Daten in unserer Telematikplattform; wenn solche Daten erforderlich sind (z. B. Angaben zum Benutzerkonto), pseudonymisieren oder anonymisieren wir sie, wo dies möglich ist. Intern werden die Mitarbeiter im ordnungsgemäßen Umgang mit Daten geschult, z. B. dass sensible Daten nicht über unsichere Kanäle übertragen werden dürfen und dass vertrauliche Dateien in einem vom Unternehmen genehmigten verschlüsselten Speicher abgelegt werden müssen.

Im Einklang mit dem Ethos "Datenschutz durch Technik" bewahren wir Daten nur so lange auf, wie es für die Erfüllung des Zwecks oder der gesetzlichen Anforderungen erforderlich ist. Wir verfügen über Verfahren zur sicheren Entsorgung oder Anonymisierung von Daten, die nicht mehr benötigt werden. Alle Speichermedien, auf denen vertrauliche Daten gespeichert sind, werden sicher gelöscht oder vernichtet, bevor sie außer Betrieb genommen werden. Wir halten uns an einen dokumentierten Zeitplan für die Datenaufbewahrung, und unsere Datenverwaltungsrichtlinie stellt sicher, dass wir sowohl den geschäftlichen Anforderungen als auch den rechtlichen Verpflichtungen nachkommen.

Alle Server (ob EC2-Instanzen, Container oder serverlose Funktionen) werden aus gehärteten Images und Konfigurationen gestartet. Wir aktualisieren die Basis-Images regelmäßig und automatisieren die Anwendung sicherer Einstellungen (z. B. Deaktivierung ungenutzter Ports und Durchsetzung von CIS-Benchmark-Konfigurationen). Bei der Konfiguration von Cloud-Diensten wie Datenbanken, Caches und Speicher-Buckets wird auf Sicherheit geachtet: aktivierte Verschlüsselung im Ruhezustand, strenge Zugriffsrichtlinien und kein öffentlicher Zugriff, wenn nicht unbedingt erforderlich. Der administrative Zugriff auf Cloud-Systeme erfordert eine Multi-Faktor-Authentifizierung (MFA) und wird über AWS Identity and Access Management (IAM)-Rollen streng kontrolliert. Wir verwenden auch automatisierte Tools zum Scannen der Konfiguration, um Fehlkonfigurationen oder Abweichungen von unserer Sicherheitsgrundlinie zu erkennen, die mit den ISO-Kontrollen für sicheres Konfigurationsmanagement übereinstimmen.

Der Zugriff auf Cloud-Ressourcen wird von uns streng kontrolliert. Jeder Benutzer und jeder Dienst in unserer Cloud-Umgebung arbeitet unter einer eigenen Identität mit maßgeschneiderten Berechtigungen. Wir vermeiden langlebige statische Anmeldedaten, indem wir IAM-Rollen und temporäre Token verwenden, wo immer dies möglich ist. Die Multi-Faktor-Authentifizierung ist für alle Konsolen- und VPN-Zugriffe obligatorisch. Administrative Aktionen in Cloud-Konten sind auf eine kleine Anzahl von Technikern beschränkt, und jeder Zugriff wird protokolliert. Wir überprüfen regelmäßig die Berechtigungen und passen sie an, um sicherzustellen, dass kein Benutzer oder System mehr Zugriff als erforderlich hat (Unterstützung der geringsten Privilegien und der Identitätsmanagementkontrollen nach ISO Anhang A).

Unsere Cloud-Plattform wird kontinuierlich überwacht. Wir sammeln Protokolle von allen kritischen Systemen - einschließlich Audit-Protokollen, Netzwerkflussprotokollen, Betriebssystemprotokollen und Anwendungsprotokollen - in einem zentralisierten SIEM-System (Security Information and Event Management). Sicherheitsrelevante Ereignisse (z. B. Authentifizierungsfehler, Konfigurationsänderungen, anomaler Netzwerkverkehr) lösen Warnmeldungen aus, die von unserem Sicherheitsteam untersucht werden. Wir verwenden AWS CloudTrail und AWS Config, um Aktionen in unserer Umgebung aufzuzeichnen und zu bewerten. Darüber hinaus setzen wir Intrusion Detection und Dateiintegritätsüberwachung auf wichtigen Systemen ein, um Anzeichen einer Kompromittierung zu erkennen. Unser Betriebsteam integriert auch Bedrohungsdaten-Feeds, so dass wir über neu auftretende Bedrohungen (wie Zero-Day-Schwachstellen oder aktive Cyberangriffe) informiert sind und im Einklang mit der neuen Kontrolle zu Bedrohungsdaten in Anhang A proaktiv die Verteidigung stärken oder Patches anwenden können.

Hochverfügbarkeit und Kontinuität sind in unsere Cloud-Architektur integriert. Wir stellen kritische Dienste in mehreren Verfügbarkeitszonen bereit, um Ausfälle des Rechenzentrums zu überstehen. Die Daten werden regelmäßig gesichert (verschlüsselt), um katastrophalen Ausfällen in der Cloud-Region vorzubeugen. Wir führen regelmäßig Wiederherstellungsübungen durch, um zu überprüfen, ob die Sicherungen wiederhergestellt und die Systeme innerhalb unserer Wiederherstellungszeitziele wiederhergestellt werden können. Für den Fall einer Serviceunterbrechung verfügen unsere Teams für die Reaktion auf Vorfälle und den Betrieb über Playbooks, um die Auswirkungen schnell zu mildern und die Kunden zu informieren. (Auf die Geschäftskontinuität wird in einem späteren Abschnitt näher eingegangen, aber es ist erwähnenswert, dass unsere Cloud-Einrichtung standardmäßig so konzipiert ist, dass sie widerstandsfähig ist).

Unser Cloud-Betrieb folgt einem DevSecOps-Modell, bei dem die Sicherheit in den Arbeitsablauf integriert ist. Änderungen an der Infrastruktur (z. B. die Änderung von Netzwerkregeln oder die Bereitstellung eines neuen Dienstes) durchlaufen eine Codeüberprüfung und automatische Tests, genau wie der Anwendungscode. Wir verwenden Infrastruktur-als-Code-Vorlagen, d. h. Umgebungskonfigurationen sind versionskontrolliert und überprüfbar. Vor der Anwendung von Änderungen führen wir automatische Richtlinienprüfungen durch (z. B. "Öffnet diese Änderung Ports, die nicht geöffnet sein sollten?", "Sind Verschlüsselungseinstellungen aktiviert?"). Erst wenn diese Prüfungen und Genehmigungen bestanden sind, werden die Änderungen in der Regel automatisch übernommen. Dadurch wird das Risiko menschlicher Fehler, die eine Sicherheitslücke verursachen, verringert und die Nachvollziehbarkeit jeder Infrastrukturänderung gewährleistet.

Die Lieferantenverträge von Proemion enthalten spezifische Bestimmungen zu Sicherheit und Datenschutz. Wir verpflichten alle Anbieter, die Zugang zu unseren Daten oder Systemen haben, vertraglich dazu, angemessene Sicherheitspraktiken und Compliance-Regelungen einzuhalten. So müssen Cloud- und Software-Anbieter beispielsweise einschlägige Zertifizierungen (wie ISO 27001 oder PCI-DSS, falls zutreffend) aufrechterhalten und uns über alle Verstöße oder Änderungen ihrer Sicherheitslage informieren. Wir nehmen auch Vertraulichkeits- und Datenverarbeitungsklauseln auf (die oft mit der GDPR und unseren eigenen Datenschutzstandards übereinstimmen), um sicherzustellen, dass Dritte die Daten auf demselben Niveau schützen wie wir.

Beziehungen zu Drittanbietern sind nicht "einmalig". Wir überprüfen regelmäßig die Leistung und Sicherheit der wichtigsten Lieferanten. Dazu kann die jährliche Überprüfung ihrer aktualisierten Audit-Berichte und die Überwachung ihrer Ankündigungen auf Vorfälle oder Schwachstellen gehören (wenn unser Cloud-Anbieter beispielsweise einen Sicherheitshinweis herausgibt, überprüfen wir, dass unsere Umgebung nicht betroffen ist, oder wenden die erforderlichen Patches an). Für kritische Anbieter unterhalten wir Kontaktstellen und führen regelmäßige Treffen durch, um Sicherheitsfragen zu besprechen. Wir verfolgen auch, wann Verträge zur Erneuerung anstehen, um das Risiko neu zu bewerten und die Bedingungen bei Bedarf zu aktualisieren. Neue und sich entwickelnde Risiken (z. B. Angriffe auf die Lieferkette oder Änderungen in der Geschäftstätigkeit eines Lieferanten) werden bei diesen Überprüfungen berücksichtigt.

Bei der Integration mit APIs oder Hardware von Drittanbietern (z. B. den Systemen eines Kunden oder der Plattform eines Partners) sorgen wir für sichere Interaktionen. Dies kann die Verwendung von VPNs oder dedizierten sicheren Kanälen für Systemintegrationen, die Verwaltung von API-Authentifizierungsschlüsseln mit angemessenem Umfang und Rotation sowie das Testen der Integration auf Sicherheitslücken beinhalten. Wir behandeln den Austausch von Daten nach außen mit der gleichen Sorgfalt wie unsere internen Daten und stellen sicher, dass sie bei der Übertragung verschlüsselt und auf das notwendige Minimum beschränkt werden. Wenn ein Partner Zugriff auf unsere Systeme benötigt (z. B. für Supportzwecke), stellen wir ihm spezielle Konten mit begrenzten Berechtigungen zur Verfügung und ermöglichen eine detaillierte Protokollierung seiner Aktivitäten.

Unsere Produkte enthalten zwangsläufig Komponenten von Drittanbietern und Open-Source-Komponenten. Wir wählen diese Komponenten sorgfältig aus und bevorzugen gut gewartete und weithin vertrauenswürdige Bibliotheken. Die gesamte Software und Firmware von Drittanbietern, die in unseren Lösungen enthalten ist, wird katalogisiert. Wir überwachen Schwachstellen-Feeds (z. B. CVE-Datenbanken) auf Probleme in diesen Komponenten und aktualisieren oder patchen sie umgehend über unseren Patch-Management-Prozess. Darüber hinaus enthält unsere Richtlinie für sichere Entwicklung Richtlinien für Entwickler zur Bewertung von Open-Source-Komponenten (z. B. Überprüfung der Codesignierung, Verifizierung von Prüfsummen und Überprüfung von Lizenzen), bevor diese in unsere Lösungen aufgenommen werden. Indem wir festlegen, was in unsere Software einfließt, verringern wir das Risiko versteckter Schwachstellen oder bösartigen Codes aus Drittquellen.

Wenn ein Sicherheitsvorfall einen Drittanbieter betrifft oder von ihm verursacht wird, arbeiten wir eng mit diesem Anbieter zusammen, um ihn zu lösen. Unser Plan für die Reaktion auf einen Vorfall umfasst die Kontaktaufnahme mit dem Anbieter, den Austausch der erforderlichen Informationen und die Sicherstellung, dass dieser seinerseits angemessene Maßnahmen ergreift. Wir dokumentieren die Kontakte zu Drittanbietern für Notfälle. Nach einem Vorfall können wir die Eignung des Anbieters neu bewerten oder Korrekturmaßnahmen verlangen, wenn er die Erwartungen nicht erfüllt hat.

Für kritische Systeme definiert Proemion geeignete Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs), um die Wiederherstellungs- und Resilienzplanung zu steuern. Diese Ziele legen akzeptable Zeitpläne für die Wiederherstellung von Diensten und Erwartungen an die Datenwiederherstellung auf der Grundlage von Bewertungen der Auswirkungen auf das Geschäft und der Risiken fest. Die Wiederherstellungsziele werden im Rahmen etablierter Managementprozesse überprüft und genehmigt und sind so konzipiert, dass sie den geltenden vertraglichen, gesetzlichen und betrieblichen Anforderungen entsprechen. Zur Unterstützung dieser Ziele werden technische und organisatorische Maßnahmen implementiert, die regelmäßig überprüft werden, um ihre kontinuierliche Wirksamkeit sicherzustellen.

Wir haben einen dokumentierten technischen Notfallwiederherstellungsplan, der detailliert beschreibt, wie jedes System in verschiedenen Katastrophenszenarien wiederhergestellt werden kann. Wenn zum Beispiel eine ganze AWS-Region ausfällt, haben wir Verfahren, um unsere Dienste in einer alternativen Region mit gesicherten Daten und Infrastructure-as-Code-Skripten zu starten. Wenn eine Softwarebereitstellung das System schwerwiegend beeinträchtigt, können wir einen Rollback auf einen bekannten, guten Zustand durchführen. Unser DR-Plan wird regelmäßig in Teilen und als Ganzes getestet. Wir führen (mindestens einmal jährlich) Übungen durch, die einen größeren Ausfall simulieren. Während dieser Übungen übt das Team die Wiederherstellung von Backups, den Wechsel zu redundanten Systemen und die Überprüfung der Datenintegrität. Alle festgestellten Lücken werden umgehend behoben.

Wo immer dies möglich ist, vermeiden wir einzelne Ausfallpunkte. Unsere wichtigsten Systeme laufen in einer redundanten Konfiguration - mehrere Server, redundante Netzwerkpfade, Notstromversorgung in den Büros usw. Wir haben Failover-Prozesse für kritische Komponenten (wenn z. B. ein Dienst ausfällt, kann ein Standby-Dienst übernehmen). Die Daten werden kontinuierlich gesichert, und die Backups werden extern und verschlüsselt gespeichert. Außerdem nutzen wir Cloud-Funktionen wie Datenbank-Snapshots, um sicherzustellen, dass die Daten auch dann sicher bleiben, wenn ein einzelner Standort gefährdet ist. Durch die Kombination dieser Maßnahmen wird sichergestellt, dass viele kleinere Vorfälle (wie Serverausfälle oder Verbindungsabbrüche) transparent und ohne Ausfallzeiten bewältigt werden.

Für den Fall einer erheblichen Störung haben wir eine klare Befehlskette und einen Kommunikationsplan. Unser Incident Response Team, dem Mitglieder aus den Bereichen Sicherheit, IT, DevOps und Support angehören, fungiert gleichzeitig als Notfallteam. Sie kommen schnell zusammen (bei Bedarf auch virtuell), um die Situation zu beurteilen und entsprechende Maßnahmen einzuleiten. Wir verfügen über vorgefertigte Kommunikationsvorlagen, um Kunden, Partner und interne Stakeholder zu informieren und sicherzustellen, dass die Informationen rechtzeitig und korrekt weitergegeben werden. Bei allen Kontinuitätsereignissen haben Sicherheit (bei physischen Vorfällen) und Datenschutz Vorrang. Nach einem Vorfall führen wir eine Retrospektive durch, um daraus zu lernen und uns zu verbessern (was sowohl in unser BCMS als auch in unser Sicherheitsrisikomanagementverfahren einfließt).

Geschäftskontinuität ist kein einmaliges Projekt, sondern eine ständige Aufgabe. Wir aktualisieren unsere Kontinuitäts- und Wiederherstellungspläne immer dann, wenn sich in unserem Umfeld wesentliche Änderungen ergeben - zum Beispiel, wenn wir eine neue Technologie einführen oder wenn sich unsere geschäftlichen Prioritäten ändern. Die Mitarbeiter werden regelmäßig zu den Notfallverfahren geschult. Unser Ziel ist es, dass im Katastrophenfall jedes Teammitglied seine Rolle kennt und die Wiederherstellungsschritte geprobt wurden. Indem wir uns an Normen wie ISO 22301 orientieren, stellen wir außerdem sicher, dass unser Ansatz nicht nur die IT-Wiederherstellung, sondern auch umfassendere geschäftliche Aspekte (alternative Arbeitsorte, Kommunikation usw.) abdeckt.