# wesentlichen Cybersicherheitsanforderungen Dieses Dokument bietet eine hochrangige Beschreibung, wie Dispel die **wesentlichen Cybersicherheitsanforderungen** festgelegt in **Anhang I, Teile I und II** der Verordnung (EU) 2024/2847 (Cyber Resilience Act oder „**CRA**“) für die unten aufgeführten digitalen Elemente erfüllt. Unternehmens-IT-Systeme, interne Tools und nicht zugehörige SaaS-Komponenten sind außer Betracht gelassen, außer wenn sie die Sicherheitsmerkmale der aufgeführten Produkte direkt unterstützen. #### **Digitale Elemente im Anwendungsbereich** * Dispel-Anwendungen (macOS, iOS, Windows) * Wicket ESI ## CRA-Anforderungen ### Anhang I, Teil I: Secure-by-Design und Entwicklung | CRA-Anforderung | Konformitätserklärung | | --------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Schutz vor unbefugtem Zugriff | Die Produkte implementieren authentifizierte und autorisierte Zugriffsmechanismen, die ihrem Betriebsumfeld entsprechen und unbefugten logischen Zugriff verhindern. | | Vertraulichkeit von Daten | Daten, die von den Produkten verarbeitet, gespeichert oder übertragen werden, sind standardmäßig durch branchenübliche kryptografische Mechanismen geschützt. | | Integrität von Daten, Befehlen und Code | Integritätsschutzmaßnahmen werden auf Produktcode, Konfiguration, Befehle und Updates angewendet, um unbefugte Änderungen zu verhindern. | | Verfügbarkeit und Resilienz | Die Produkte sind so konzipiert, dass sie verfügbar bleiben und unter widrigen Bedingungen sicher ausfallen, einschließlich Resilienz gegenüber gängigen Angriffstechniken. | | Sichere Standardkonfiguration | Produkte werden mit sicheren Standardkonfigurationen geliefert, die keine zusätzliche Härtung erfordern, um ein grundlegendes Sicherheitsniveau zu erreichen. | | Minimierung der Angriffsfläche | Nur notwendige Dienste, Schnittstellen und Berechtigungen sind standardmäßig aktiviert; unnötige Funktionalität ist deaktiviert oder ausgeschlossen. | | Schutz vor bekannten Schwachstellen | Bekannte Schwachstellen in Produktkomponenten werden identifiziert und vor der Freigabe behoben. | | Sichere Aktualisierungsmechanismen | Updates werden über authentifizierte und auf Integrität geschützte Mechanismen bereitgestellt, um Manipulationen zu verhindern. | | Sichere Lebenszyklusunterstützung | Sicherheitsupdates werden für einen definierten Unterstützungszeitraum bereitgestellt, der dem Produktlebenszyklus angemessen ist. | | Protokollierung und Überwachung (wo angemessen) | Sicherheitsrelevante Ereignisse werden in einer dem Produktrollen- und -umfeld angemessenen Weise aufgezeichnet oder sichtbar gemacht. | | Prinzip der minimalen Rechte | Produkte arbeiten mit den minimal erforderlichen Rechten für ihre vorgesehene Funktionalität. | | Schutz vor Ausführung schädlichen Codes | Maßnahmen sind implementiert, um unbefugte oder schädliche Codeausführung innerhalb des Produkts zu verhindern. | | Sichere Interoperabilität | Interaktionen mit Betriebssystemen und externen Komponenten sind sicher entworfen und implementiert. | | Widerstandsfähigkeit gegenüber gängigen Angriffstechniken | Das Produktdesign berücksichtigt gängige Angriffsvektoren wie Spoofing, Replay, Manipulation und Privilegieneskalation. | ### Anhang I, Teil II: Umgang mit Schwachstellen und Nachmarktpflichten | CRA-Anforderung | Konformitätserklärung | | ------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | Prozess zum Umgang mit Schwachstellen | Ein dokumentierter Prozess zum Umgang mit Schwachstellen wird für die Produkte im Anwendungsbereich gepflegt. | | Koordinierte Offenlegung von Schwachstellen (CVD) | Es existiert ein öffentlicher Kanal für die verantwortungsvolle Offenlegung von Sicherheitslücken. | | Annahme und Triage von Schwachstellen | Gemeldete Schwachstellen werden bewertet, priorisiert und basierend auf Schwere und Auswirkung verfolgt. | | Zeitnahe Behebung | Sicherheitslücken werden ohne unangemessene Verzögerung behoben. | | Sichere Verteilung von Behebungen | Sicherheitsbehebungen werden mithilfe derselben sicheren Aktualisierungsmechanismen verteilt wie Standardversionen. | | Benutzer- und Kundenkommunikation | Benutzer werden bei Bedarf über relevante Sicherheitsprobleme informiert. | | Bewusstsein für Ausnutzung | Informationen über bekannte oder vermutete Ausnutzungen werden überwacht und bei Reaktionsmaßnahmen berücksichtigt. | | Regulatorische Meldung | Verfahren existieren, um aktiv ausgenutzte Schwachstellen, sofern gesetzlich vorgeschrieben, den zuständigen EU-Behörden zu melden. | | Software-Stückliste (SBOM) | Informationen zur Softwarezusammensetzung werden für die Produkte gepflegt. | | Aufbewahrung von Aufzeichnungen | Aufzeichnungen zu Schwachstellen und Behebungsmaßnahmen werden für regulatorische Prüfungen aufbewahrt. | --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://legal.dispel.com/security-and-data-protection/security-and-data-protection-de/compliance/eu-cyber-resilience-act/wesentlichen-cybersicherheitsanforderungen.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.