Deckblatt
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 | Unnamed: 3 | Unnamed: 4 |
|---|---|---|---|---|
| Anhang 3.1: Anforderungskatalog Informationssicherheit | ||||
| Version 0.9 | ||||
| Ansprechpartner | Angaben zum Dienstleister | |||
| Helaba - Information Security Management | Name und Adresse des Dienstleisters: | Bitte einfügen | ||
| Hr. Christian Talmon | is-governance@helaba.de | Ansprechpartner (inkl. E-Mail-Adresse): | ||
| Angaben zur Dienstleistung | ||||
| Kurzbeschreibung der Dienstleistung: | Bitte einfügen gemäß Vertrag | |||
| Art der eingesetzten IT-Infrastruktur | 2. Zugriff über VDI/Citrix | |||
| Erfolgt die Dienstleistungserbringung mit Unterstützung von eigenen oder beauftragten Rechenzentren? | Bitte begründen. Falls ja relevante Rechenzentren mit kurzer Erläuterung ergänzen. | |||
| Erfolgt die Dienstleistungserbringung mit Unterstützung von EUC/IDV? | Nein | |||
| Sind eine oder mehrere der folgenden Anwendungsarten Gegenstand der Dienstleistungserbringung? | ||||
| - Transktionsbasierte Anwendungen | Bitte begründen. Falls ja relevante Anwendungen angeben | |||
| - Mandantenfähige Anwendungen | Bitte begründen. Falls ja relevante Anwendungen angeben | |||
| - Internetapplikationen | Bitte begründen. Falls ja relevante Anwendungen angeben | |||
| - Online-Zahlungsdienste | Bitte begründen. Falls ja relevante Anwendungen angeben | |||
| - Cloud-Services | Bitte begründen. Falls ja relevante Anwendungen angeben | |||
| Angaben zum Schutzbedarf | ||||
| Schutzbedarfsklassifizierung (gesamt): | Bitte einfügen | |||
| Vertraulichkeit (C): | Bitte einfügen | |||
| Integrität (I): | Bitte einfügen | |||
| Verfügbarkeit (A): | Bitte einfügen | |||
| Begründung Schutzbedarfsklassifizierung: | Bitte einfügen | |||
| Einleitung | Der vorliegende Anhang 3.1 soll sicherstellen, dass ein angemessenes Sicherheitsniveau definiert, implementiert und während der Laufzeit des Rahmenvertrages aufrechterhalten wird. Dieser Anhang ist vom Auftragnehmer zu befüllen und wird Vertragsbestandteil. Er enthält ergänzend zum Vertrag und weiterer Anlagen zur Informationssicherheit die für die Dienstleistungserbringung verbindlichen Vorgaben zur Informationssicherheit. Die Regelungen finden Anwendung auf alle im Rahmen der ausgelagerten Prozesse und Aktivitäten durch den Dienstleister eingesetzte Informationstechnik (IT), IT-Systeme (alle technischen Anlagen, die der Informationsverarbeitung dienen und eine abgeschlossene Funktionseinheit bilden), Infrastruktur (die für die Informationsverarbeitung und IT genutzten Gebäude, Räume, Energieversorgung, Klimatisierung und die Verkabelung) und sonstige Zielobjekte (z.B. Personal). Grundsätzlich ist bei allen relevanten Fragestellungen der Informationssicherheit der Rahmenvertrag, diese Anlage zum Rahmenvertrag und die Detailregelungen in den Servicescheinen zu berücksichtigen. Abweichungen von diesen Regelungen müssen nachvollziehbar dokumentiert werden und bedürfen der schriftlichen Zustimmung der Helaba. Bei Widersprüchen zwischen den Regelungen des Rahmenvertrages und dieser Anlage, haben die Regelungen dieser Anlage Vorrang vor denen des Rahmenvertrages. | |||
| Regulatorische Grundlage des Dokuments | o Mindestanfoderungen an das Risikomanagement (MaRisk) o Digital Operational Resilience Act (DORA) o EBA Guidelines on Outsourcing |
Bearbeitungshinweise
| Unnamed: 0 | Unnamed: 1 | Unnamed: 2 |
|---|---|---|
| Hinweise zur Bearbeitung Tabellenblatt "Anforderungskatalog" | ||
| Wenn die Sicherheitsvorgabe für die Auslagerung bzw. Dienstleistung "relevant" oder "teilweise relevant" ist, sind die Felder in den Spalten "Erfüllungsgrad des Auftragnehmers" sowie "Referenzdokumente des Auftragnehmers" verpflichtend auszufüllen. | ||
| Wenn die Sicherheitsvorgabe für die Auslagerung bzw. Dienstleistung "nicht relevant - Hinweistext" ist, sind die Felder in den Spalten "Erfüllungsgrad des Auftragnehmers" sowie "Referenzdokumente des Auftragnehmers" nicht auszufüllen. Dabei handelt es sich lediglich um Erörterungen für den Bieter. | ||
| Beim Erfüllungsgrad tragen Sie bitte vollständig erfüllt, teilweise erfüllt oder nicht erfüllt ein. Sollte der Erfüllungsgrad nur teilweise erfüllt oder nicht erfüllt sein, erläutern Sie bitte die Abweichung in der darauffolgenden Spalte. | ||
| Wenn eine Sicherheitsvorgabe "vollständig erfüllt" oder "teilweise erfüllt" ist sind die passenden Referenzdokumente anzugeben. Bei der Referenzierung der Nachweisdokumentation, achten Sie bitte darauf, dass diese für Dritte nachvollziehbar ist und sich genau auf die vorgegebene Sicherheitsvorgabe bezieht. Die Referenzdokumente selbst sind nur auf Anforderung der Helaba vorzulegen. Die ISO 27001-Zertifizierung allein ist nicht als Referenzdokument ausreichend. | ||
| Die Bieter sind angehalten, die Angaben möglichst vollständig und erschöpfend mit dem Erstangebot beizubringen. Sollten Angaben fehlen, unvollständig oder unklar sein, behält sich der Auftraggeber vor, diese entweder im laufenden Vergabeverfahren nachzufordern bzw. aufzuklären oder hierauf erst nach Zuschlagserteilung zurückzukommen. Der Auftragnehmer ist verpflichtet, die insoweit erforderlichen Angaben spätestens innerhalb von zwei Wochen auf gesonderte Aufforderung durch den Auftraggeber nachzureichen. |
Anforderungskatalog
| Kapitel | Control Objective ID | Control Objective Title | SBK | Inhalt | Scope | Referenz DORA EU 2022_2554 | Referenz DORA EU 2024_1774 | Relevant für den Auftragnehmer | Begründung bei "teilweise relevant" oder "nicht relevant" | Erfüllungsgrad des Auftragnehmers | Erläuterung der Abweichungen bei "teilweise erfüllt" oder "nicht erfüllt" | Ergänzende Bemerkungen des Auftragnehmers | Referenzdokumente des Auftragnehmers | Ergänzende Bemerkungen des Auftraggebers |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Generell gilt: Bei der Schutzbedarfsklasse (SBK) 4 können durch den Auftraggeber weitere - über die bestehenden Sicherheitsvorgaben hinaus - Sicherheitsmaßnahmen beauftragt werden. | ||||||||||||||
| 0 | R.0100 – Klassifizierung und Kennzeichnung von Informationen | |||||||||||||
| R.0100.001 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 1. Die Informationen sind im Kontext mit den Geschäftsprozessen, in denen sie verwendet, verarbeitet oder gespeichert werden, sowie der geltenden gesetzlichen Anforderungen auf ihren Schutzbedarf hinsichtlich der Vertraulichkeit, Integrität und Verfügbarkeit nach einem einheitlichen Schema zu klassifizieren. Für diesen Zweck sind zentral definierte Kriterien für die Klassifizierung in 4 Schutzbedarfsklassen bzgl. der Schutzbedarfsziele Vertraulichkeit, Integrität und Verfügbarkeit zu verwenden. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | Artikel 05: Verfahren für das Management von IKT-Assets (2) -., Artikel 05: Verfahren für das Management von IKT-Assets (2) a)., Artikel 05: Verfahren für das Management von IKT-Assets (2) b)., Artikel 14: Sicherung von Informationen bei der Übermittlung (2) -. | nicht relevant | |||||||
| R.0100.002 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 2. Die Klassifizierung muss mindestens hinsichtlich des finanziellen Schadens, des Verlustes der Reputation und des Verstoßes gegen Vorgaben (gesetzlich, aufsichtsrechtlich) erfolgen. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.003 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 3. Die Klassifizierung von Informationen muss durch den Informationseigentümer erfolgen. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.004 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 4. Wenn sich die Kritikalität der Information im Laufe ihres Lebenszyklusses verändert, ist diese neu zu bewerten (z. B. die Bilanz vor und nach Veröffentlichung). | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.005 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 5. Die Klassifizierung ist regelmäßig durch den Informationseigentümer auf Aktualität und Vollständigkeit zu prüfen. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.006 | C.0100.001 | Informationen sind in Abhängigkeit Ihres Schutzbedarfs je Schutzziel nach einem einheitlichen Schema klassifiziert. | SBK 1 | 6. Informationen ohne nachvollziehbare Vertraulichkeitseinstufung sind als C2 eingestufte Informationen zu behandeln. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.018 | C.0100.002 | Informationen sind gemäß ihrer Vertraulichkeitsstufe gekennzeichnet. Die Mitarbeitenden sind über die Durchführung der Kennzeichnung informiert. | SBK 2 | 1. Dokumente sind mit ihrer Vertraulichkeitsstufe explizit zu kennzeichnen. Ausnahmen sind nur aufgrund wichtiger betrieblicher Gründe zulässig. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.007 | C.0100.002 | Informationen sind gemäß ihrer Vertraulichkeitsstufe gekennzeichnet. Die Mitarbeitenden sind über die Durchführung der Kennzeichnung informiert. | SBK 2 | 2. Bei der Verarbeitung von Informationen mit unterschiedlichen Vertraulichkeitsstufen ist das Maximalprinzip anzuwenden. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.0100.008 | C.0100.002 | Informationen sind gemäß ihrer Vertraulichkeitsstufe gekennzeichnet. Die Mitarbeitenden sind über die Durchführung der Kennzeichnung informiert. | SBK 2 | 3. Es muss in Rahmen der schriftlich fixierten Ordnung beschrieben sein, wie die Kennzeichnung durchzuführen ist. | Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| 1 | R.0110 - Informationsrisikomanagement | |||||||||||||
| R.0110.001 | C.0110.001 | Anforderungen bei Nichteinhaltung bzw. Abweichungen von Sicherheitsvorgaben sind definiert und werden im Rahmen von angemessenen Risikomanagementprozessen weiterverfolgt. | SBK 1 | 1. Es ist ein Prozess für die Identifizierung, Bewertung und Behandlung von Informationsrisiken zu definieren. Dabei müssen mindestens die folgenden Punkte berücksichtigt sein: a) Die Informationsrisiken müssen als Teil der Non Financial Risks den Vorgaben des übergeordneten Risikocontrolling folgen; b) Das mit der Abweichung verbundene Risiko ist zu ermitteln und unter Berücksichtigung des Risikoprozesses zu bewerten und für sachkundige Dritte nachvollziehbar zu dokumentieren. c) Identifizierte Risiken und akzeptierte (Rest-)Risiken müssen in einem Risikoinventar gepflegt werden. Die Gründe für die Akzeptanz von (Rest-)Risiken sind zu dokumentieren. d) Bei Nichteinhaltungen bzw. Abweichungen von Sicherheitsvorgaben muss der fachlich verantwortliche Risikoträger ermittelt und die Nichteinhaltungen bzw. Abweichung an diesen kommuniziert werden. e) Das Schadensausmaß des Risikos ist auf die bankfachlichen Geschäftsprozesse zu beziehen und hinsichtlich aller relevanter Kategorien (Finanzielle Schäden und regulatorische Auswirkungen) zu bewerten. f) Es müssen angemessene Risikobehandlungsstrategien (Risikovermeidung, Risikotransfer, Risikoreduktion und/oder Risikoakzeptanz) und entsprechende Korrekturmaßnahmen vom fachlich verantwortliche Risikoträger mit Unterstützung des technisch Verantwortlichen abgestimmt und umgesetzt werden; g) Die geplanten Korrekturmaßnahmen müssen vom fachlich verantwortlichen Risikoträger freigegeben werden. h) Die wirksame Umsetzung der ergriffenen Korrekturmaßnahmen ist zu überwachen i) Sollten die Korrekturmaßnahmen nicht zur vollständigen Umsetzung der Sicherheitsvorgaben führen, ist eine kompetenzgerechte (Rest-)Risikoakzeptanz gemäß dem Prozess für Informationsrisiken herbeizuführen und nachvollziehbar zu begründen. Diese ist zu plausibilisieren und dem CISO zur Kenntnis zu geben. j) Risiken, welche gegen das geltende Recht verstoßen, dürfen nicht akzeptiert werden, sofern Sicherheitsvorkehrungen nach Stand der Technik möglich und angemessen sind. Erst für das dann noch verbleibende Restrisiko ist eine Risikoakzeptanz möglich. k) Die Akzeptanz von (Rest-)Risiken ist zeitlich auf maximal 12 Monate zu befristen, anschließend sind die Risiken neu zu bewerten und eine Anpassung oder erneute (Rest-)Risikoakzeptanz herbeizuführen. Die zugehörigen Maßnahmen sind ebenfalls mindestens jährlich zu aktualisieren und zu revalidieren. l) Die Ergebnisse der Risikobewertung und -behandlung sind für sachkundige Dritte nachvollziehbar zu dokumentieren. | Artikel 13: Lernprozesse und Weiterentwicklungen (3)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 03: IKT-Risikomanagement.-., Artikel 03: IKT-Risikomanagement.a)., Artikel 03: IKT-Risikomanagement.b)., Artikel 03: IKT-Risikomanagement.b) ii), Artikel 03: IKT-Risikomanagement.c)., Artikel 03: IKT-Risikomanagement.c) a), Artikel 03: IKT-Risikomanagement.c) b), Artikel 03: IKT-Risikomanagement.c) c), Artikel 03: IKT-Risikomanagement.d)., Artikel 03: IKT-Risikomanagement.d) i), Artikel 03: IKT-Risikomanagement.d) ii), Artikel 03: IKT-Risikomanagement.d) ii) 1., Artikel 03: IKT-Risikomanagement.d) ii) 2., Artikel 03: IKT-Risikomanagement.d) iii), Artikel 03: IKT-Risikomanagement.d) iv), Artikel 03: IKT-Risikomanagement.d) iv) 1., Artikel 03: IKT-Risikomanagement.d) iv) 2., Artikel 03: IKT-Risikomanagement.d) iv) 3., Artikel 03: IKT-Risikomanagement.e)., Artikel 03: IKT-Risikomanagement.e) i), Artikel 06: Verschlüsselung und kryptografische Kontrollen (3) -., Artikel 06: Verschlüsselung und kryptografische Kontrollen (5) -. | nicht relevant | |||||||
| 2 | R.0200 - Assetmanagement | |||||||||||||
| R.0200.001 | C.0200.001 | Alle relevanten Assets sind unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information vollständig und aktuell inventarisiert. | SBK 1 | 1. Es müssen dokumentierte Prozesse etabliert werden, welche vollständige und aktuelle Übersichten der Werte des Unternehmens im Kontext mit den Informationen und Prozessen sowie deren Abhängigkeiten und Schnittstellen ausweisen (Strukturanalyse). Hierbei sind mindestens die Erfassung und Dokumentation der folgenden Unternehmenswerte unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information (z. B. Erstellung/Erfassung, Verarbeitung, Speicherung/Archivierung, Übermittlung, Löschung, Zerstörung) zu regeln (Asset Management): a) Anwendungen b) System-/Systemnahe-/Sonstige-Software c) Informationsspeicher/Dokumenttypen/Datenträger d) IT-Infrastruktur e) Gebäude/Räume f) Personal (Rollen) g) Externe Dienstleister inkl. ggf. genutzter Subdienstleister h) Dienstleistungen/Verträge | Artikel 08: Identifizierung (1)., Artikel 08: Identifizierung (4)., Artikel 08: Identifizierung (5)., Artikel 08: Identifizierung (6). | Artikel 04: Richtlinie für das Management von IKT-Assets (1) -., Artikel 04: Richtlinie für das Management von IKT-Assets (2) -., Artikel 04: Richtlinie für das Management von IKT-Assets (2) a)., Artikel 05: Verfahren für das Management von IKT-Assets (2) b). | nicht relevant | |||||||
| R.0200.002 | C.0200.001 | Alle relevanten Assets sind unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information vollständig und aktuell inventarisiert. | SBK 1 | 2. Es sind die im Betrieb eingesetzten Assets zu verwalten und zu dokumentieren. | Artikel 08: Identifizierung (1)., Artikel 08: Identifizierung (6). | Artikel 04: Richtlinie für das Management von IKT-Assets (2) -. | nicht relevant | |||||||
| R.0200.003 | C.0200.001 | Alle relevanten Assets sind unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information vollständig und aktuell inventarisiert. | SBK 1 | 3. Die im Konfigurationsmanagement erhobenen Informationen müssen für die gespeicherten Unternehmenswerte neben dem erkennbaren Verwendungszweck mindestens die folgenden Punkte beinhalten:_x000D_ a) Eindeutiges Identifikationskriterium bzw. eindeutiger Name_x000D_ b) CI-Typ_x000D_ c) Version_x000D_ d) Hersteller_x000D_ e) Status _x000D_ f) KRITIS-Flag_x000D_ g) Flag - Personenbezogene Daten_x000D_ h) Dienstleister / Betreiber_x000D_ i) Beziehungen zu anderen CIs_x000D_ j) Verantwortlicher_x000D_ k) zugeordnete Änderungsanfragen (Changes)_x000D_ l) zugeordnete Incidents und Problems und bekannten Fehler (sog. "Known Errors")_x000D_ m) Schutzbedarfsklasse Vertraulichkeit_x000D_ n) Schutzbedarfsklasse Integrität_x000D_ o) Schutzbedarfsklasse Verfügbarkeit_x000D_ p) Der Standort jedes physischen oder logischen CIs muss über einen direkten Eintrag bzw. durch die Beziehung zwischen CIs ableitbar/definiert sein_x000D_ q) maximale Zeit bis zur vollständigen Wiederherstellung im Regelbetrieb (Recovery Time Objective, RTO) unter Berücksichtigung der maximal tolerierbaren Ausfallzeit _x000D_ r) maximal tolerierbarer Datenverlust im Regelbetrieb (Recovery Point Objective, RPO)_x000D_ s) Unterstützt kritische oder wichtige Funktionen_x000D_ t) Direkt verbunden mit externen Netzen _x000D_ u) Informationen zum Lebenszyklus des CI, z.B. Angaben zu voraussichtlichem Ende der Support-Zeiten des Herstellers/Providers und damit ggf. Status als „IT-Altsystem“_x000D_ v) Unterstützt von KI, inklusive KI-Risikoklasse | Artikel 08: Identifizierung (1)., Artikel 08: Identifizierung (4)., Artikel 08: Identifizierung (5)., Artikel 08: Identifizierung (6)., Artikel 08: Identifizierung (7). | Artikel 04: Richtlinie für das Management von IKT-Assets (2) b)., Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) i), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) ii), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) iii), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) iv), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) v), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) vi), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) vii), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) viii), Artikel 04: Richtlinie für das Management von IKT-Assets (2) b) ix), Artikel 04: Richtlinie für das Management von IKT-Assets (2) c)., Artikel 05: Verfahren für das Management von IKT-Assets (2) -., Artikel 05: Verfahren für das Management von IKT-Assets (2) a)., Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) iii) | nicht relevant | |||||||
| R.0200.005 | C.0200.001 | Alle relevanten Assets sind unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information vollständig und aktuell inventarisiert. | SBK 1 | 4. Es müssen Kontrollaktivitäten etabliert sein, welche regelmäßig, mindestens jedoch einmal jährlich oder falls erforderlich, die Daten der führenden Inventare (u.a. CMS, CMDB) und der Daten-zuliefernden Systeme auf Richtigkeit und Vollständigkeit überprüfen. | Artikel 08: Identifizierung (1)., Artikel 08: Identifizierung (6). | nicht relevant | ||||||||
| R.0200.006 | C.0200.001 | Alle relevanten Assets sind unter Berücksichtigung ihrer Aufgabe im Lebenszyklus der Information vollständig und aktuell inventarisiert. | SBK 1 | 5. Es ist ein angemessener Prozess für Änderungen an den Asset- bzw. CI-Daten zu definieren inkl. Verantwortlichkeiten, der die Integrität der Daten sicherstellt. | Artikel 08: Identifizierung (1). | nicht relevant | ||||||||
| R.0200.011 | C.0200.002 | Zu allen Assets sind eindeutige Verantwortlichkeiten zugeordnet. | SBK 1 | 1. Jeder Wert (Asset) muss - neben seiner eindeutigen Bezeichnung und Beschreibung – einem Verantwortlichen (z. B. Informationseigentümer, Prozesseigentümer, Anwendungseigentümer) zugeordnet sein, der für die Identifikation von Anforderungen bei der Beschaffung, Entwicklung sowie Pflege des Wertes (Assets) verantwortlich ist. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii) | nicht relevant | ||||||||
| 3 | R.0300 - Berechtigungsmanagement (Zutritt, Zugang, Zugriff) | |||||||||||||
| R.0300.001 | C.0300.001 | Bei der Vergabe von Berechtigungen ist die Funktionstrennung sichergestellt. | SBK 1 | 1. Durch geeignete Organisationsstrukturen muss sichergestellt werden, dass Funktionen und Rollen (disziplinarisch und/oder fachlich) getrennt werden, wenn deren gemeinsame Ausübung a) zu Interessenkonflikten führt, b) das Risiko schadhafter Handlungen erhöht, c) das Ergebnis der einzelnen Funktion oder d) das des gesamten Prozesses beeinträchtigt. Dies muss sowohl bei der Zusammenfassung von Tätigkeiten zu Rollen (durch Funktionstrennung) als auch bei der Zuweisung von Rollen zu Personen (durch Rollentrennung) umgesetzt werden. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.b). | nicht relevant | |||||||
| R.0300.002 | C.0300.001 | Bei der Vergabe von Berechtigungen ist die Funktionstrennung sichergestellt. | SBK 1 | 2. Zur Dokumentation und Verwaltung von potentiellen Funktionskonfliktrisiken muss eine Funktionstrennungsmatrix erstellt werden, die mindestens die regulatorischen Funktionstrennungsanforderungen erfüllt. Dabei ist mindestens Folgendes sicherzustellen: a) Die Berechtigungen der Tätigkeitsbereiche „Frontoffice Handel“ sowie „Markt Kredit“ sind zu trennen von den Berechtigungen der Bereiche „Marktfolge Kredit“, „Backoffice Handel“, „Risikomanagement“ sowie „Bilanzen und Steuern“. b) Die Berechtigungen des Tätigkeitsbereichs „IT-Betrieb“ sind zu trennen von den Berechtigungen des Bereichs „IT-Entwicklung“. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.b). | nicht relevant | |||||||
| R.0300.003 | C.0300.001 | Bei der Vergabe von Berechtigungen ist die Funktionstrennung sichergestellt. | SBK 1 | 3. Die Funktionstrennungsmatrix ist im Rahmen der Rezertifizierung der Berechtigungen auf ihre Aktualität zu überprüfen. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.b). | nicht relevant | |||||||
| R.0300.005 | C.0300.001 | Bei der Vergabe von Berechtigungen ist die Funktionstrennung sichergestellt. | SBK 2 | 1. Erhält ein Anwender gleichzeitig Berechtigungen, die nach dem Prinzip der Funktionstrennung zu separieren sind, müssen mindestens folgende Anforderungen erfüllt werden: a) Sie sind nachvollziehbar zu dokumentieren. b) Risikomindernde Kontrollen müssen etabliert werden (z. B. Überwachung von Tätigkeiten). c) Im Rahmen der Rezertifizierung sind diese konfliktären Berechtigungen explizit erneut zu prüfen. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.b). | nicht relevant | |||||||
| R.0300.009 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 1. Dokumentierte Prozesse zur Vergabe (Antrag und Freigabe), Änderung, Entzug (Sperrung, Deaktivierung, Löschung) und Reaktivierung von Benutzerkonten sind zu definieren und einzurichten. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.b)., Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.060 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 2. Es müssen eindeutige Zuständigkeiten in den Prozessen definiert sein, die eine Trennung der Aufgaben zur Beantragung, Genehmigung und Einrichtung (auch temporär) der Zutritts-, Zugangs- und Zugriffssteuerung sicherstellen (Vieraugenprinzip). | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.061 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 3. Jeder einzelne Vorgang bzgl. Vergabe, Änderung, Entzug und Reaktivierung von Berechtigungen muss nachvollziehbar dokumentiert sein. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.062 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 4. Die Erstellung und Pflege von Berechtigungskonzepten inkl. der Definition von unvereinbaren Berechtigungen ist zu regeln. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.063 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 5. Die Zuordnung von Benutzern zu geltenden Rollen und Berechtigungen ist zu dokumentieren und entsprechend der geltenden Gesetzgebung aufzubewahren. Prüfer, Auditoren und berechtigte Dritte müssen sich jederzeit hierüber informieren können. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii), Artikel 20: Identitätsmanagement (2) a). | nicht relevant | |||||||
| R.0300.064 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 6. Die Verwaltung von digitalen Identitäten, Berechtigungen, inkl. administrativen Berechtigungen, muss grundsätzlich über ein Berechtigungsmanagementsystem erfolgen. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.065 | C.0300.002 | Berechtigungen werden gemäß angemessener und nachvollziehbarer Prozesse vergeben und verwaltet. | SBK 1 | 7. Es ist eine nachvollziehbare Verwendung von Clearance Accounts (z. B. für den Einsatz im IT-Notfall) zu regeln. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c). | Artikel 21: Zugangskontrolle.e)., Artikel 21: Zugangskontrolle.e) i), Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | |||||||
| R.0300.013 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 1. Ein Prozess zum Lebenszyklus von Identitäten und Benutzerkonten (u. a. Erstellung, Änderung, Sperrung, Löschung) ist zu dokumentieren und zu implementieren. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c)., Artikel 09: Schutz und Prävention.(4) c). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b)., Artikel 21: Zugangskontrolle.e). | nicht relevant | |||||||
| R.0300.066 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 2. Vor der Vergabe von Berechtigungen sind die vorgesehenen Mitarbeiter (inkl. Externer) zu erfassen/registrieren. | Artikel 09: Schutz und Prävention.(3) b)., Artikel 09: Schutz und Prävention.(3) c). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b). | nicht relevant | |||||||
| R.0300.067 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 3. Es muss sichergestellt werden, dass jedes Benutzerkonto auf einen Mitarbeiter zurückgeführt werden kann (z. B. über die ID), um die Zuordenbarkeit von Aktivitäten zu erhalten und nicht autorisierte Zugriffe zu verhindern. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b). | nicht relevant | |||||||
| R.0300.068 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 4. Es ist zwingend ein eindeutiges und unternehmensweit gültiges Identitätskennzeichen (ID) nach einem definierten Schema festzulegen. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b). | nicht relevant | |||||||
| R.0300.069 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 5. IDs sind nachvollziehbar (z. B. durch die Verknüpfung von Name, Vorname und Personalnummer) jeweils nur einem Mitarbeiter zuzuordnen. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b). | nicht relevant | |||||||
| R.0300.070 | C.0300.003 | Das Registrieren und Löschen bzw. De-registrieren von Benutzern ist nachvollziehbar und eindeutig im Rahmen eines Prozesses zum Lebenszyklus von Identitäten und Benutzerkonten geregelt. | SBK 1 | 6. Änderungen (bspw. Bereichswechsel) oder De-Registrierungen (z.B. Im Falle Beschäftigungsende / Vertragsende) von Mitarbeitern sind zu regeln. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 20: Identitätsmanagement (1) -., Artikel 20: Identitätsmanagement (2) a)., Artikel 20: Identitätsmanagement (2) b). | nicht relevant | |||||||
| R.0300.018 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 1 | 1. Ein nachvollziehbares Antrags- und Genehmigungsverfahren (Vieraugenprinzip) ist einzurichten. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 21: Zugangskontrolle.c)., Artikel 21: Zugangskontrolle.e) ii) | nicht relevant | |||||||
| R.0300.071 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 1 | 2. Bei jedem Berechtigungsantrag ist zu dokumentieren, für welchen Mitarbeiter zu welchem Zeitpunkt welche Berechtigungen beantragt und genehmigt wurden. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 21: Zugangskontrolle.c)., Artikel 21: Zugangskontrolle.e) ii) | nicht relevant | |||||||
| R.0300.072 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 1 | 3. Bei der Genehmigung von Berechtigungen muss sichergestellt werden, dass jeder Benutzer (z.B. Mitarbeiter, technischer Benutzer) nur die Rechte erhält, die er für seine Tätigkeit benötigt (Need-to-Know, Need-to-Use, Least Priviliges). | Artikel 09: Schutz und Prävention.(3) b). | Artikel 21: Zugangskontrolle.a)., Artikel 21: Zugangskontrolle.c)., Artikel 21: Zugangskontrolle.e) ii) | nicht relevant | |||||||
| R.0300.073 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 1 | 4. Wird ein Benutzerkonto von mehreren Personen genutzt (Mehrbenutzerkonto), muss eine explizite fachliche Begründung dafür vorliegen. Es muss nachvollziehbar sein, wer der verantwortliche Eigentümer des Benutzerkontos ist. Es ist nachvollziehbar zu dokumentieren, welche Benutzer in welchem Zeitraum Zugriff auf das Mehrbenutzerkonto hatten. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 21: Zugangskontrolle.c)., Artikel 21: Zugangskontrolle.e) ii) | nicht relevant | |||||||
| R.0300.074 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 1 | 5. Berechtigungen, die Externen oder befristet beschäftigten Mitarbeitern zugeordnet sind, müssen im Rahmen der fachlichen Notwendigkeit zeitlich befristet sein und dürfen nicht an andere Mitarbeiter oder Externe übertragen werden. | Artikel 09: Schutz und Prävention.(3) b). | Artikel 21: Zugangskontrolle.c)., Artikel 21: Zugangskontrolle.e) ii), Artikel 12: Datenaufzeichnung (2) f). | nicht relevant | |||||||
| R.0300.019 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 2 | 1. Die Einrichtung der Berechtigungen ist im Vieraugenprinzip durchzuführen. | Artikel 09: Schutz und Prävention.(3) b). | nicht relevant | ||||||||
| R.0300.020 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 2 | 2. Die Einrichtung der Berechtigungen darf erst nach Abschluss des Antrags- und Genehmigungsverfahrens erfolgen. | Artikel 09: Schutz und Prävention.(3) b). | nicht relevant | ||||||||
| R.0300.023 | C.0300.004 | Das Genehmigen und Einrichten von Berechtigungen erfolgt im Rahmen eines nachvollziehbaren Antrags- und Genehmigungsverfahren nach den Prinzipien von Need-to-Know, Need-to-Use sowie Least Priviliges. | SBK 4 | 1. Mehrbenutzerkonten dürfen keinen direkten Zugriff auf streng vertrauliche Informationen haben. | Artikel 09: Schutz und Prävention.(3) b). | nicht relevant | ||||||||
| R.0300.024 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 1. Für die Vergabe, Sperrung, Rückgabe und Verwaltung von Zutrittskarten sind angemessene Prozesse zu definieren und dokumentieren. | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | ||||||||
| R.0300.075 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 2. Um den Zutritt zu kontrollieren, bzw. auf bestimmte Bereiche entsprechend der Zutrittsberechtigungen zu begrenzen, werden interne Mitarbeiter, externe Mitarbeiter, Dienstleister und Gäste/Besucher mit Zutrittsmitteln (z. B. Zutrittskarten, Schlüssel) ausgestattet. | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | ||||||||
| R.0300.076 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 3. Zutrittskarten haben eine optische Unterscheidungsmöglichkeit von Personengruppen. Dabei sind mindestens für die folgenden Personengruppen ein separates Unterscheidungsmerkmal aufzubringen: Interne Mitarbeiter, externe Mitarbeitern, Dienstleister und Gäste/Besucher. | nicht relevant | |||||||||
| R.0300.077 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 4. Personen sind dazu zu verpflichten, die Zutrittsausweise gut sichtbar zu tragen. | nicht relevant | |||||||||
| R.0300.078 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 5. Eine Zuordnung der Zutrittskarten zum ausstellenden Unternehmen darf nicht ohne Vorkenntnisse möglich sein. | nicht relevant | |||||||||
| R.0300.079 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 6. Die bei den Zutrittskarten verwendete Technologie muss gewährleisten, dass die Zutrittskarten bzw. die Informationen nicht kopierbar bzw. simulierbar sind und eine ungebrochene und zeitgemäße Verschlüsselung unterstützen. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | nicht relevant | ||||||||
| R.0300.080 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 7. Die Zutrittskarten für alle internen und externen Mitarbeiter und Dienstleister (die fest am Objekt eingesetzt sind) müssen ergänzend ein optisches Merkmal mit der Möglichkeit einer 1:1 Zuordnung zum Karteninhaber aufgedruckt haben. | nicht relevant | |||||||||
| R.0300.081 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 8. Bei Zutrittskarten von Externen/Dienstleistern sind diese zusätzlich mit mindestens dem Ablaufdatum zu bedrucken. Die Gültigkeit muss mit dem voraussichtlichen Projektende/Arbeitsende, spätestens aber nach 2 Jahren, ablaufen. Dieser Zutritt muss eigens genehmigt und überwacht werden. | nicht relevant | |||||||||
| R.0300.082 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 9. Nicht personalisierte Zutrittskarten für Dienstleister sind mit einem optischen Merkmal zur Identifizierung der Dienstleisterfirma zu bedrucken. | nicht relevant | |||||||||
| R.0300.083 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 10. Die Aushändigung von (nicht personalisierten) Zutrittskarten für Dienstleister erfolgt ausschließlich gegen Identifikation mittels Lichtbildausweis sowie Dokumentation von Vor- und Zuname, Firma, Kartennummer, Datum, Uhrzeit Ausgabe und Uhrzeit Rückgabe in einer Ausgabeliste. | nicht relevant | |||||||||
| R.0300.084 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 11. Die Zutrittskarten haben eine eindeutige Nummer aufgedruckt, sowie einen Kontakt in Falle des Fundes einer Karte. | nicht relevant | |||||||||
| R.0300.085 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 12. Bei Verlust der Zutrittskarte muss der Inhaber den Verlust sofort an die zuständige Stelle melden. Nach Kenntnisname durch die zuständige Stelle ist die Zutrittskarte unverzüglich zu sperren. | nicht relevant | |||||||||
| R.0300.086 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 13. Bei Vergessen der Zutrittskarte ist eine vorübergehende Ersatzkarte mit einer maximalen Gültigkeit von 5 Werktagen auszustellen. | nicht relevant | |||||||||
| R.0300.025 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 14. Die Vergabe und Rückgabe von Schlüsseln muss in einer Schlüsseldokumentation registriert werden. | nicht relevant | |||||||||
| R.0300.087 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 15. Es sind regelmäßige Kontrollen auf Vollständigkeit der Dokumentation und Vollständigkeit der Ersatzschlüssel durchzuführen. | nicht relevant | |||||||||
| R.0300.088 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 1 | 16. Die Ausgabe von Schlüsseln für zentrale Schließanlagen ist auf ein Minimum zu reduzieren. | nicht relevant | |||||||||
| R.0300.027 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 2 | 1. Die Vergabe von Zutrittsausweisen und Schlüsseln darf erst nach Abschluss des Antrags- und Genehmigungsverfahrens erfolgen. | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | ||||||||
| R.0300.028 | C.0300.005 | Der Zutritt zu Räumlichkeiten, in denen sich Informationen oder IT-Systeme befinden, ist restriktiv vergeben. Prozesse für den Umgang mit Zutrittsmitteln sowie Schlüsseln sind etabliert. | SBK 3 | 1. Externen Mitarbeitern ist nur dann ein zeitlich beschränkter Zutritt zu Sicherheitsbereichen oder Einrichtungen zur Verarbeitung dieser Informationen zu gewähren, wenn dies für die Erfüllung der betrieblichen Zwecke erforderlich ist. | nicht relevant | |||||||||
| R.0300.031 | C.0300.006 | Privilegierter Berechtigungen werden nachvollziehbar verwaltet. Sie werden besonders restriktiv vergeben und die deren Tätigkeiten werden risikoorientiert überwacht. | SBK 2 | 1. Bei der Vergabe von privilegierten Berechtigungen ist, ergänzend zu den weiteren Sicherheitsvorgaben zur Verwaltung von Berechtigungen, mindestens Folgendes zu regeln: a) Definition von privilegierten Berechtigungen und geeignete Prozesse zum Umgang b) Privilegierte Berechtigungen sind grundsätzlich besonders restriktiv zu vergeben. c) Besondere Sorgfalt ist bei privilegierten Berechtigungen geboten, mittels derer Sicherheitsmaßnahmen umgangen werden können. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | nicht relevant | ||||||||
| R.0300.032 | C.0300.006 | Privilegierter Berechtigungen werden nachvollziehbar verwaltet. Sie werden besonders restriktiv vergeben und die deren Tätigkeiten werden risikoorientiert überwacht. | SBK 2 | 2. Die Nutzung von Clearance Accounts (z.B. im Falle eines IT-Notfalls) ist nur dann zulässig, wenn besondere Eingriffe bzw. Administrationstätigkeiten erforderlich sind, die durch die im Regelbetrieb genutzten administrativen Benutzerkonten nicht abgebildet werden können. Folgende Aspekte bei der Nutzung von Clearance Accounts zu regeln: a) Der zur Nutzung berechtigte Mitarbeiterkreis. b) Die Ausgabe der Benutzerdaten an einen Mitarbeiter. c) Die Änderung der Benutzerdaten nach Verwendung im Klartext. d) Die Passwörter sind gesichert zu hinterlegen (z. B. Tresor oder PAM-Safe). e) Die Aktivitäten sind zu protokollieren. | Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.0300.033 | C.0300.006 | Privilegierter Berechtigungen werden nachvollziehbar verwaltet. Sie werden besonders restriktiv vergeben und die deren Tätigkeiten werden risikoorientiert überwacht. | SBK 3 | 1. Tätigkeiten von Benutzern mit privilegierten Berechtigungen müssen gesondert protokolliert und wenn nötig überwacht werden. | Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.0300.034 | C.0300.006 | Privilegierter Berechtigungen werden nachvollziehbar verwaltet. Sie werden besonders restriktiv vergeben und die deren Tätigkeiten werden risikoorientiert überwacht. | SBK 3 | 2. Die Nutzung von Clearance Accounts darf nur im Vieraugenprinzip erfolgen. Sofern ein 4-Augenprinzip im Einzelfall nicht eingehalten werden kann, sind die Aktivitäten zur Nutzung unverzüglich auszuwerten. Die Nutzung und Auswertung sind nachvollziehbar zu dokumentieren | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | nicht relevant | ||||||||
| R.0300.035 | C.0300.006 | Privilegierter Berechtigungen werden nachvollziehbar verwaltet. Sie werden besonders restriktiv vergeben und die deren Tätigkeiten werden risikoorientiert überwacht. | SBK 4 | 1. Für die Nutzung von Clearance Accounts sind folgende ergänzende Anforderungen zu erfüllen: a) Das vollständige Kennwort von Clearance Accounts darf nie einer einzelnen Person bekannt sein. Sicherzustellen ist dies z. B. durch Teilen des Passworts oder durch technische Maßnahmen. b) Die Aktivitäten sind technisch zu protokollieren. | Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.0300.036 | C.0300.007 | Eine regelmäßige Überprüfung von Berechtigungen (Rezertifizierung) wird im Rahmen von nachvollziehbaren Prozessen durchgeführt. | SBK 1 | 1. Es sind im Unternehmen dokumentierte Prozesse zu implementieren, anhand derer eine regelmäßige Überprüfung (Rezertifizierung) der Berechtigungen durchgeführt werden kann. | Artikel 21: Zugangskontrolle.e) ii), Artikel 21: Zugangskontrolle.e) iv) | nicht relevant | ||||||||
| R.0300.040 | C.0300.007 | Eine regelmäßige Überprüfung von Berechtigungen (Rezertifizierung) wird im Rahmen von nachvollziehbaren Prozessen durchgeführt. | SBK 1 | 2. Die Überprüfung der Berechtigungen für Zugang oder Zugriff muss mindestens in folgenden Intervallen erfolgen: a) halbjährlich: besonders kritische (privilegierte) Berechtigungen und Berechtigungen auf IT-Systeme, die kritische/wichtige Funktionen unterstützen b) jährlich: alle weiteren Berechtigungen. | Artikel 21: Zugangskontrolle.e) iv) | nicht relevant | ||||||||
| R.0300.041 | C.0300.007 | Eine regelmäßige Überprüfung von Berechtigungen (Rezertifizierung) wird im Rahmen von nachvollziehbaren Prozessen durchgeführt. | SBK 1 | 3. Werden im Rahmen der Rezertifizierung Änderungsbedarfe erkannt, so sind diese im Rahmen der Sicherheitsvorgaben zum Entzug oder Anpassung von Berechtigungen umzusetzen. | Artikel 21: Zugangskontrolle.e) iv) | nicht relevant | ||||||||
| R.0300.039 | C.0300.007 | Eine regelmäßige Überprüfung von Berechtigungen (Rezertifizierung) wird im Rahmen von nachvollziehbaren Prozessen durchgeführt. | SBK 2 | 1. Im Rahmen der Rezertifizierung für Zugang oder Zugriff sind angemessene Kontrollen durchzuführen und zu dokumentieren. | Artikel 21: Zugangskontrolle.e) iv) | nicht relevant | ||||||||
| R.0300.045 | C.0300.007 | Eine regelmäßige Überprüfung von Berechtigungen (Rezertifizierung) wird im Rahmen von nachvollziehbaren Prozessen durchgeführt. | SBK 4 | 1. Bei Informationsspeichern (z. B. Laufwerke, Verzeichnisse) sind durch den fachlich Verantwortlichen jährlich alle Aspekte der Rezertifizierung zu überprüfen. | nicht relevant | |||||||||
| R.0300.046 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 1. Es sind dokumentierte Prozesse für den Entzug oder die Anpassung von Berechtigungen zu implementieren. | Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | ||||||||
| R.0300.089 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 2. Bei Wechsel der Funktion/fachlichen Rolle von Mitarbeitern oder Externen (z. B. durch Versetzung) sind die Individualberechtigungen daraufhin zu prüfen, ob die fachliche Anforderung für die Nutzung weiterhin besteht. | Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | ||||||||
| R.0300.090 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 3. Die Berechtigungen sind für sämtliche physische Bereiche, IT-Systeme und Anwendungen zu ändern, anzupassen oder zu löschen. | Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | ||||||||
| R.0300.091 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 4. Mit Verlassen des Unternehmens bzw. Beendigung des Vertragsverhältnisses von Mitarbeitenden müssen die Benutzerkonten umgehend deaktiviert oder gelöscht werden. | Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | ||||||||
| R.0300.092 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 5. Durch geeignete Kontrollen sind die Risiken bei einem Wechsel eines Mitarbeiters, dem kritische (privilegierte Benutzer-) Berechtigungen zugeordnet sind, zu minimieren. | Artikel 21: Zugangskontrolle.e) iii) | nicht relevant | ||||||||
| R.0300.093 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 1 | 6. Der Entzug und die Anpassung von Berechtigungen sind nachvollziehbar zu protokollieren. | Artikel 21: Zugangskontrolle.e) iii), Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.0300.049 | C.0300.008 | Die Anpassung und der Entzug von Berechtigungen erfolgt im Rahmen von Prozessen nachvollziehbar und zeitnah und wird entsprechend dokumentiert. | SBK 4 | 1. In besonderen Fällen (z. B. sofortige Freistellung, fristlose Kündigung) muss darauf geachtet werden, dass Berechtigungen zu Sicherheitsbereichen, Anwendungen und Ressourcen zeitlich vor dem tatsächlichen Vertragsende reduziert oder gelöscht werden, um Risiken von Informationsabfluss, Missbrauch oder Sabotage zu reduzieren. | nicht relevant | |||||||||
| R.0300.051 | C.0300.009 | Es sind Maßnahmen implementiert, um die Unterlaufung der Benutzerverwaltung von IT-Systemen zu verhindern. | SBK 2 | 1. Die Benutzerverwaltung einer Anwendung darf nicht durch ein darunterliegendes bzw. unterstützendes IT-System außer Kraft gesetzt werden. | Artikel 09: Schutz und Prävention.(3) b). | nicht relevant | ||||||||
| R.0300.094 | C.0300.009 | Es sind Maßnahmen implementiert, um die Unterlaufung der Benutzerverwaltung von IT-Systemen zu verhindern. | SBK 2 | 2. Der Mitarbeiter darf nicht die Möglichkeit haben, die an ihn vergebenen Rechte zu überschreiben, oder über einen direkten Zugriff (z. B. auf eine Datenbank) die auf Anwendungsebene vergebenen Rechte zu umgehen. | Artikel 09: Schutz und Prävention.(3) b). | nicht relevant | ||||||||
| R.0300.055 | C.0300.010 | Quellcode und Programme sind angemessen vor Änderungen und Manipulationen geschützt. | SBK 1 | 1. Der Quellcode von Anwendungen ist in einem System mit einer Versions- und Änderungskontrolle zu verwalten. | nicht relevant | |||||||||
| R.0300.057 | C.0300.010 | Quellcode und Programme sind angemessen vor Änderungen und Manipulationen geschützt. | SBK 1 | 2. Das Verwaltungssystem muss so eingerichtet sein, dass nur die verantwortlichen Entwickler/Softwarebetreuer einen schreibenden Zugriff auf die von ihnen verantworteten Quellcodes haben. | nicht relevant | |||||||||
| R.0300.059 | C.0300.010 | Quellcode und Programme sind angemessen vor Änderungen und Manipulationen geschützt. | SBK 1 | 3. Eine nachträgliche Veränderung bereits archivierter Quellcodes darf nicht erfolgen. | nicht relevant | |||||||||
| 4 | R.0400 - Change- und Patchmanagement | |||||||||||||
| R.0400.001 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 1. Die Prozesse für das IT-Änderungsmanagement müssen alle Änderungen an Software, Hardware, Firmware-Komponenten, Systemen oder Sicherheitsparametern umfassen , dazu gehören auch Updates und Patches. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 17: IKT-Änderungsmangement (1) -., Artikel 17: IKT-Änderungsmangement (1) -.1) | relevant | |||||||
| R.0400.011 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 2. Die Prozesse für das IT-Änderungsmanagement müssen die folgenden Mindestanforderungen erfüllen: a) wesentliche Änderungen feststellen, klassifizieren und protokollieren; b) Änderungen sind unter Berücksichtigung der Abhängigkeiten zwischen den IT-Systemen zu planen und zu prüfen; c) möglichen Risiken von Änderungen (z.B. im Rahmen einer Risikoanalyse), sind zu bewerten und zu dokumentieren; d) die Auswirkungen auf die Sicherheit der Assets feststellen und eine Bewertung, ob zusätzliche Sicherheitsmaßnahmen erforderlich sind; e) ein formelles Antrags- und Genehmigungsverfahren für vorgeschlagene Änderungen ist vorzugeben; f) die Ergebnisse eines Changes müssen einer Qualitätssicherung unterzogen und ggfls. die daraus gezogene Schlussfolgerungen dokumentiert werden. | Artikel 08: Identifizierung (3)., Artikel 09: Schutz und Prävention.(4) e). | Artikel 12: Datenaufzeichnung (2) c) iii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 17: IKT-Änderungsmangement (1) c)., Artikel 17: IKT-Änderungsmangement (1) c) i), Artikel 17: IKT-Änderungsmangement (1) c) ii), Artikel 17: IKT-Änderungsmangement (1) c) iv) | relevant | |||||||
| R.0400.002 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 3. Changes sind zu planen, priorisieren, testen, implementieren und zu dokumentieren. Hierbei sind mindestens Änderungen, die Schwachstellen und Sicherheitslücken beseitigen, die ein besonders hohes Gefährdungspotential haben, mit höchster Priorität durchzuführen. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 10: Schwachstellen- und Patch-Management (2) f)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 17: IKT-Änderungsmangement (1) c) iii), Artikel 17: IKT-Änderungsmangement (1) d)., Artikel 17: IKT-Änderungsmangement (1) d) i), Artikel 17: IKT-Änderungsmangement (1) d) iii) | relevant | |||||||
| R.0400.003 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 4. Für die Prozesse des IT-Änderungsmanagement müssen Rollen und Verantwortlichkeiten definiert und kommuniziert werden. Die Prozesse müssen mindestens sicherstellen, dass a) ein Entscheidungsträger etabliert wird, der grundsätzlich Änderungen im Regelbetrieb und Notfall-Änderungen unter Berücksichtigung der anzuwendenden Sicherheitsvorgaben und den Prozessvorgaben an IT-Systeme und Anwendungen freigibt; b) die Unabhängigkeit zwischen den Verantwortlichen, die Änderungen genehmigen, und denjenigen, die für ihre Beantragung und Durchführung zuständig sind, gewährleistet ist. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 17: IKT-Änderungsmangement (1) b)., Artikel 17: IKT-Änderungsmangement (1) c). | relevant | |||||||
| R.0400.012 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 5. Die Dokumentation und Kommunikation der Einzelheiten des Changes muss in geeigneter Form an relevante Stakeholder, einschließlich Zweck und Umfang der Änderung, Zeitplan für die Umsetzung und der erwarteten Ergebnisse, erfolgen. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 17: IKT-Änderungsmangement (1) d)., Artikel 17: IKT-Änderungsmangement (1) d) i), Artikel 17: IKT-Änderungsmangement (1) d) ii), Artikel 17: IKT-Änderungsmangement (1) d) iii) | relevant | |||||||
| R.0400.006 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 6. Es müssen Verfahren (Roll-Back) und Verantwortlichkeiten etabliert sein, um die Änderung – für den Fall, dass sie fehlschlägt oder die Sicherheit einer Anwendung oder eines Systems beeinträchtigt – rückgängig zu machen und den vorherigen Zustand wiederherzustellen. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 10: Schwachstellen- und Patch-Management (4) d), Artikel 17: IKT-Änderungsmangement (1) e). | relevant | |||||||
| R.0400.007 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 7. Der Prozess muss einen Änderungsprozess für den Notfall (Emergency Change) beschreiben, um die schnelle und kontrollierte Umsetzung von Änderungen zur Behebung eines Security Incidents zu ermöglichen. Der Prozess muss dabei Verfahren zur nachträglichen Dokumentation und Genehmigung sowie ggf. einer Neubewertung von Notfalländerungen beinhalten. Dabei sind auch implementierte Workarounds und Patches zu berücksichtigen. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 17: IKT-Änderungsmangement (1) f)., Artikel 17: IKT-Änderungsmangement (1) g) | relevant | |||||||
| R.0400.013 | C.0400.001 | Änderungen an informationsverarbeitenden Systemen werden strukturiert, zuverlässig und nachvollziehbar im Rahmen von dokumentierten Prozessen, Richtlinien, Verfahren und Kontrollen durchgeführt. Mögliche Auswirkungen auf das Sicherheitsniveau werden evaluiert und bewertet. Verfahren für Notfalländerungen und Fall-Backs sind definiert. | SBK 1 | 8. Bei jeder wesentlichen Änderung der Netzwerk- und Informationssysteminfrastruktur, der Prozesse oder Verfahren, die sich auf ihre IT-gestützten Unternehmensfunktionen, Informations- oder IT-Assets auswirken, ist eine Risikobewertung durchzuführen. | Artikel 08: Identifizierung (3)., Artikel 09: Schutz und Prävention.(4) e). | relevant | ||||||||
| R.0400.014 | C.0400.002 | Sicherheitskonzepte sind aktualisiert und nach Durchführung eines Changes ordnungsgemäß umgesetzt. | SBK 1 | 1. Die entsprechenden Sicherheitskonzepte müssen vor produktiver Umsetzung der Änderung unter Berücksichtigung der geltenden Sicherheitsvorgaben (z. B. auch bei Änderung des Schutzbedarfs) aktualisiert werden. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 17: IKT-Änderungsmangement (1) a). | relevant | |||||||
| R.0400.015 | C.0400.002 | Sicherheitskonzepte sind aktualisiert und nach Durchführung eines Changes ordnungsgemäß umgesetzt. | SBK 1 | 2. Die im Sicherheitskonzept beschriebenen und von einer Änderung betroffenen Sicherheitsmaßnahmen für die betroffenen Assets müssen nach einem Change auf eine ordnungsgemäße Umsetzung geprüft werden. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 17: IKT-Änderungsmangement (1) a). | relevant | |||||||
| R.0400.010 | C.0400.003 | CISO ist wird bei wesentlichen Änderungen mit Auswirkungen auf das Informationssicherheitsniveau frühzeitig einbezogen. | SBK 4 | 1. Über geplante Änderungen bei informationsverarbeitenden Systemen sowie Prozessen und Aufbauorganisation mit Auswirkungen auf das Informationssicherheitsniveau des Unternehmens ist die Abteilung Information Security Management frühzeitig in geeigneter Weise miteinzubeziehen. | Artikel 09: Schutz und Prävention.(4) e). | Artikel 17: IKT-Änderungsmangement (1) -., Artikel 17: IKT-Änderungsmangement (1) a). | relevant | |||||||
| R.0400.016 | C.0400.004 | Es sind Verfahren zum Management von Patches dokumentiert und implementiert, welche relevante Updates/Patches identifizieren, analysieren, priorisieren und bereitstellen. Die Patches werden getestet und ein Notfallverfahren ist etabliert. Altsysteme können nur nach erfolgter Risikoanalyse weiterbetrieben werden. | SBK 1 | 1. Es sind dokumentierte Prozesse zu implementieren, die folgendes sicherstellen: a) Ermittlung und Bewertung verfügbarer Software- und Hardware-Patches und -Updates aus vertrauenswürdigen Quellen (insbesondere von Herstellern der betroffenen Software), soweit möglich unter Verwendung automatisierter Werkzeuge; b) Es müssen Kriterien für die Priorisierung der Installation von Patches zur Behebung von Schwachstellen bestimmt werden. Dabei sind mindestens die Kritikalität der Schwachstelle sowie der Schutzbedarf und die reale Gefährdungssituation der betroffenen Anwendungen und IT-Systeme zu berücksichtigen (z.B. Zugänglichkeit aus dem Internet); c) Festlegung von Fristen für die Installation von Software- und Hardware-Patches und -Updates unter Berücksichtigung der Fristen aus dem Schwachstellenmanagement sowie Eskalationsverfahren für den Fall, dass die Fristen nicht eingehalten werden können; d) Patches müssen vor der Installation getestet und beurteilt werden, um sicherzustellen, dass sie die gewünschte Wirkung entfalten und zu keinen nicht hinnehmbaren Nebeneffekten führen. Hierbei kann eine Abwägung zwischen der Dringlichkeit der Behebung der Schwachstelle und des Testumfangs getroffen werden; e) Notfallverfahren für das Patchen und Aktualisieren von Anwendungen und IT-Systemen. | Artikel 09: Schutz und Prävention.(4) f). | Artikel 10: Schwachstellen- und Patch-Management (2) f)., Artikel 10: Schwachstellen- und Patch-Management (3) -., Artikel 10: Schwachstellen- und Patch-Management (4) a)., Artikel 10: Schwachstellen- und Patch-Management (4) b)., Artikel 10: Schwachstellen- und Patch-Management (4) c)., Artikel 17: IKT-Änderungsmangement (1) f)., Artikel 26: IKT-Reaktions- und Wiederherstellungspläne (2) -, Artikel 10: Schwachstellen- und Patch-Management (4) c)., Artikel 10: Schwachstellen- und Patch-Management (4) d)., Artikel 17: IKT-Änderungsmangement (1) f). | relevant | |||||||
| R.0400.017 | C.0400.004 | Es sind Verfahren zum Management von Patches dokumentiert und implementiert, welche relevante Updates/Patches identifizieren, analysieren, priorisieren und bereitstellen. Die Patches werden getestet und ein Notfallverfahren ist etabliert. Altsysteme können nur nach erfolgter Risikoanalyse weiterbetrieben werden. | SBK 2 | 1. Steht für eine Anwendung oder ein IT-System dauerhaft kein Patch zur Verfügung bzw. ist ein Herstellersupport nicht mehr gewährleistet, ist die Anwendung bzw. das IT-System außer Betrieb zu nehmen (IT-Altsystem). Bei Weiterbetrieb eines IT-Altsystems entgegen dieser Vorgabe ist eine Aktualisierung der zu erstellenden Risikoanalyse mindestens bei Anschluss von zusätzlichen Technologien, Anwendungen oder Systemen durchzuführen. | Artikel 08: Identifizierung (7)., Artikel 09: Schutz und Prävention.(4) f). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) iii), Artikel 10: Schwachstellen- und Patch-Management (3) -. | relevant | |||||||
| 5 | R.0500 - Schwachstellenmanagement | |||||||||||||
| R.0500.001 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 1 | 1. Es ist ein dokumentierter Prozess zum Management technischer Schwachstellen unter Vermeidung von Interessenkonflikten zu etablieren. Hierbei sind die folgenden Punkte zu beachten: a) Aspekte zu Request-, Change-, Patch, Incident und Problemmanagement b) Rollen und Verantwortlichkeiten (u. a. für die Überwachung, Risikobeurteilung und Nachverfolgung der Behebung von Schwachstellen bei den betroffenen Assets, so wie die damit verbundene Koordination im Unternehmen und bei Auslagerungen an einen Dienstleister) c) Informationsquellen (u. a. zur Identifikation relevanter technischer Schwachstellen und zur Aufrechterhaltung des Bewusstseins für mögliche Schwachstellen in Softwareprodukten und Anwendungen) d) Detektionsmechanismen für Schwachstellen e) Nachverfolgung der Nutzung von Bibliotheken Dritter, einschließlich Open-Source-Bibliotheken, die für IT-Dienstleistungen zur Unterstützung kritischer oder wichtiger Funktionen genutzt werden. Im Falle der Nutzung von „ready to use (off the shelf)“ Bibliotheken von Dritten erfolgt die Nachverfolgung risikoorientiert soweit wie möglich | Artikel 08: Identifizierung (2)., Artikel 08: Identifizierung (2)., Artikel 10: Erkennung.(1)., Artikel 13: Lernprozesse und Weiterentwicklungen (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2). | Artikel 03: IKT-Risikomanagement.b) i), Artikel 10: Schwachstellen- und Patch-Management (2) a)., Artikel 10: Schwachstellen- und Patch-Management (2) b)., Artikel 10: Schwachstellen- und Patch-Management (2) c)., Artikel 10: Schwachstellen- und Patch-Management (2) c) i), Artikel 10: Schwachstellen- und Patch-Management (2) d) i), Artikel 10: Schwachstellen- und Patch-Management (2) d) ii), Artikel 03: IKT-Risikomanagement.e) ii), Artikel 19: Richtlinien für Personalpolitik.a). | relevant | |||||||
| R.0500.002 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 1 | 2. Informationen über Schwachstellen aus den Assessmentmethoden Schwachstellenscanner, Penetrationstest, Policy-Check, Web-App-Scanner oder manuell gemeldete Schwachstellen wie z. B. Meldungen des angebundenen CERTs, müssen anhand des dokumentierten Prozesses analysiert und bewertet werden. Hierbei sind mindestens die folgenden Aspekte zu beachten: a) Definition der Reaktionszeiten zur Schließung einer Schwachstelle b) Kritikalität der gemeldeten Schwachstellen im Unternehmenskontext c) Dringlichkeit der Behebung (u. a. unter Berücksichtigung von Anwendbarkeit bzw. Ausnutzbarkeit der Schwachstelle) d) Abstimmung der Handlungsoptionen | Artikel 10: Erkennung.(1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (2). | Artikel 10: Schwachstellen- und Patch-Management (2) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) ii) | relevant | |||||||
| R.0500.005 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 1 | 3. Alle durchgeführten Maßnahmen zur Behebung der Schwachstelle müssen nachvollziehbar dokumentiert werden. Die Schließung der Schwachstelle ist zu überwachen. | Artikel 10: Schwachstellen- und Patch-Management (2) g)., Artikel 10: Schwachstellen- und Patch-Management (2) h)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c). | relevant | ||||||||
| R.0500.016 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 1 | 4. Der CISO ist sowohl über die Ergebnisse der Schwachstellenanalysen, als auch über die Maßnahmenpläne und deren Umsetzung in angemessener Form zu informieren. | relevant | |||||||||
| R.0500.017 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 1 | 5. Verfahren für die verantwortungsvolle Offenlegung von Schwachstellen gegenüber Kunden und Geschäftspartnern sowie gegebenenfalls der Öffentlichkeit sind zu etablieren. | Artikel 14: Kommunikation (1)., Artikel 14: Kommunikation (2). | Artikel 10: Schwachstellen- und Patch-Management (2) e). | relevant | |||||||
| R.0500.008 | C.0500.001 | Ein Prozess zur Erkennung technischer Schwachstellen ist etabliert. Informationen über Schwachstellen werden analysiert, bewertet und angemessen adressiert. Die Maßnahmen zur Behebung von Schwachstellen werden nachvollziehbar dokumentiert und überwacht. | SBK 3 | 1. Schwachstellen, die nicht innerhalb der definierten Reaktionszeiten behandelt werden können, müssen dem für die betroffene Anwendung/IT-System fachlich Verantwortlichen gemeldet werden, damit diese in die Risikoberichterstattung aufgenommen werden. | relevant | |||||||||
| R.0500.010 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 1. Es ist ein geeignetes risikoorientiertes Verfahren für die Durchführung von automatisierten, und wenn nicht anders möglich, manuellen Schwachstellenanalysen von IT-Systemen zu implementieren (Vulnerability-Scanning). Dabei sind mindestens die folgenden IT-Systeme zu berücksichtigen : a) Arbeitsplatz-PCs/Notebooks b) Serversysteme c) Netzwerkkomponenten d) andere IP-fähige Geräte | Artikel 09: Schutz und Prävention.(1)., Artikel 10: Erkennung.(1). | Artikel 10: Schwachstellen- und Patch-Management (2) b). | relevant | |||||||
| R.0500.018 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 2. Es ist ein geeignetes Verfahren zu implementieren, mit dem die sicherheitsrelevanten Systemeinstellungen von IT-Systemen nach Möglichkeit automatisiert sowie risikoorientiert und nach jeder wesentlichen Änderung gegenüber einer definierten Soll-Konfiguration überprüft werden (Policy-Check). Dabei sind mindestens folgende IT-Systeme zu berücksichtigen: a) Zentrale Verzeichnisdienste b) Server c) Datenbanksysteme d) Office Produkte e) Mainframe f) Arbeitsplatz-PCs g) Notebooks h) Mobile Endgeräte i) Managebare Netzwerkkomponenten j) Virtualisierungssysteme k) Cloud-Instanzen l) Browser | Artikel 03: IKT-Risikomanagement.b) i), Artikel 11: Daten- und Systemsicherheit (2) b). | relevant | ||||||||
| R.0500.019 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 3. Automatisierte Schwachstellenscans/-bewertungen von IT Systemen, die kritische und wichtige Funktionen unterstützen, sind mindestens wöchentlich durchzuführen (Vulnerability-Scanning). | Artikel 03: IKT-Risikomanagement.b) i), Artikel 10: Schwachstellen- und Patch-Management (2) b). | relevant | ||||||||
| R.0500.011 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 4. Pentests sind jährlich ergänzend zu automatisierten Schwachstellenanalysen für aus dem Internet erreichbare IT-Systeme durchzuführen, um die etwaige Verwundbarkeit der IT-Systeme gegenüber durchgeführten Hackerangriffen und insbesondere gegen Angriffe aus dem Internet (Cyber Angriffe) feststellen und zusätzliche Härtungsmaßnahmen umsetzen zu können. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | relevant | ||||||||
| R.0500.020 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 5. Die Durchführung von Pentests muss aktuelle Methoden, Werkzeuge und Technologien von Angreifern einbeziehen. Hierbei sind die folgenden Aspekte zu beachten: a) Unabhängigkeit der durchführenden Dienstleister, b) regelmäßiger Wechsel der Dienstleister, c) ein Planungshorizont von 3 Jahren, d) Angemessenheit der zeitlichen Abstände von Penetrationstests e) Etwaige regulatorische Vorgaben in Bezug auf die Durchführung | relevant | |||||||||
| R.0500.014 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 6. Identifizierte Abweichungen und Schwachstellen sind zu bewerten und zu dokumentieren. Darauf basierend ist ein Maßnahmenplan zur Beseitigung der Abweichungen und Schwachstellen mit Nennung der Verantwortlichen und Termine zu erstellen. Die Wirksamkeit der umgesetzten Maßnahmen ist im Rahmen des nachfolgenden Analysedurchlaufs nachzuweisen. Der CISO ist sowohl über die Ergebnisse der Schwachstellenanalysen, der Pentests und der Health-Checks als auch über die Maßnahmenpläne und deren Umsetzung zu informieren. | Artikel 10: Schwachstellen- und Patch-Management (2) f)., Artikel 10: Schwachstellen- und Patch-Management (2) h). | relevant | ||||||||
| R.0500.021 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 1 | 7. Der CISO ist sowohl über die Ergebnisse der Schwachstellenanalysen, der Pentests und der Policy-Checks als auch über die Maßnahmenpläne und deren Umsetzung in angemessener aggregierter Form zu informieren. | relevant | |||||||||
| R.0500.022 | C.0500.002 | Anhand von automatisierten, risikoorientierten Überprüfungen sowie Pentests werden etwaige Schwachstellen identifiziert und anschließend bewertet und dokumentiert. Maßnahmenpläne zur Behebung von Schwachstellen sind erstellt. Die Wirksamkeit wird nachgewiesen. | SBK 4 | 1. Penetrationstests müssen alle drei Jahre oder bei gesonderter Beauftragung durch den Assetverantwortlichen (z.B. bei Neueinführung bzw. wesentlicher Änderung) durchgeführt werden. | Artikel 25: Testen von IKT-Tools und -Systemen (1). | relevant | ||||||||
| 6 | R.0600 - Security Incident Management | |||||||||||||
| R.0600.002 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 1. Das Security Incident Management (SIM) beschreibt eine organisierte und standardisierte Reaktion in Bezug auf einen potenziellen Verstoß gegen die Informationssicherheit. Das Security Incident Management unterscheidet zwischen den Ausprägungen allgemeiner Störfall, Security Event und Security Incident von Ereignissen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.055 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 2. Der CISO muss über alle meldepflichtigen Security Incidents informiert werden. | Artikel 11: Reaktion und Wiederherstellung.(2) e)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 19: Meldung schwerwiegender IKT-bezogener Vorfälle und freiwillige Meldung erheblicher Cyberbedrohungen (1). | relevant | ||||||||
| R.0600.003 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 3. Abgrenzung zu verwandten oder überschneidenden Arten von Incidents/Events: a) Protokollierung und Monitoring von IT Systemen erzeugt in vielen Fällen auch Sicherheitsmeldungen (Events), die für sich allein keinen Verdacht auf einen Security Incident begründen und zunächst weitergehend maschinell oder manuell ausgewertet werden müssen. Diese Events werden nicht als Verdacht auf einen Security Incident geführt, können aber nach entsprechender Auswertung in einzelnen Fällen den Verdacht auf einen Security Incident begründen. b) Zur Behandlung von Störungen, die auf Hardware oder Software Fehler oder menschliches Versagen zurückzuführen sind und die nur Verfügbarkeitsauswirkungen zeigen, sind Prozesse zur Eindämmung, Wiederherstellung der Services zu etablieren. Diese sind im Rahmen des Incident- bzw. Problem-Managementverfahrens zu bearbeiten. Das in diesem Fall durch das Incident und Problemmanagement etablierte Verfahren wird nicht zusätzlich durch die Dokumentation eines Security Incidents im Verfügbarkeitsbereich erweitert. Sollte sich jedoch während der Bearbeitung eines solchen Falles Verdachtsmomente ergeben, die auf einen Vorsatz, einen Angriff oder eine unbefugte Verletzung der Sicherheitsziele Integrität und Vertraulichkeit hindeuten, sind die Prozesse zur Dokumentation eines Security Incidents parallel und abgestimmt mit dem Prozess zur Behandlung von Incidents aufzunehmen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.004 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 4. Im Prozess zur Behandlung von Security Incidents müssen Verantwortlichkeiten und Abläufe festgelegt werden, um eine schnelle, wirksame und ordnungsgemäße Reaktion auf Security Incidents sicherzustellen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) f). | Artikel 19: Richtlinien für Personalpolitik.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (1) -. | relevant | |||||||
| R.0600.043 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 5. Es muss definiert sein, welche Rollen und Verantwortlichkeiten zur Umsetzung des Security Incident Managements bestimmt sind. Hierzu gehören: a) Stellen, die Allgemeine Störfalle, Security Events und Security Incidents entgegennehmen b) Stellen für die Analyse und Bewertung von Security Incidents sowie für die Berichterstattung c) Zentrales Entscheidungsgremium für die Steuerung und Bearbeitung von Security Incidents. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 19: Richtlinien für Personalpolitik.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.044 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 6. Mitarbeiter, die Security Incidents bearbeiten, sind regelmäßig zu schulen. Die Mitarbeiter im Prozess müssen im Bedarfsfall kurzfristig Zugang zu allen relevanten Informationen bekommen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.045 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 7. Ein Reaktionsverfahren einschließlich jener zur Eskalation, kontrollierten Wiederherstellung nach einem Security Incident sowie zur Kommunikation an relevante, interne und externe Personen oder Organisationen ist zu etablieren. Hierbei ist sicherzustellen, dass auch extern (z. B. durch SLAs eingebundene) Dienstleister, Behörden, Interessengruppen oder anderweitig beteiligte Dritte -sofern erforderlich – in Information und Koordination von Security Incidents miteinbezogen sind. | Artikel 11: Reaktion und Wiederherstellung (2) b)., Artikel 11: Reaktion und Wiederherstellung (2) c)., Artikel 11: Reaktion und Wiederherstellung.(3)., Artikel 11: Reaktion und Wiederherstellung.(8)., Artikel 14: Kommunikation (1)., Artikel 14: Kommunikation (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) d)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) e)., Artikel 19: Meldung schwerwiegender IKT-bezogener Vorfälle und freiwillige Meldung erheblicher Cyberbedrohungen (3). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.046 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 8. Ein Verfahren für die Planung, Vorbereitung und Durchführung von Abhilfemaßnahmen bei Vorfällen das gewährleistet, dass der Security Incident unter Kontrolle gebracht und ggf. vorhandene Schwachstellen geschlossen werden, bevor er sich ausweitet und Assets bzw. Prozesse zu stark beeinträchtigt (Incident Response Methodologies). | Artikel 11: Reaktion und Wiederherstellung (2) b)., Artikel 11: Reaktion und Wiederherstellung (2) c)., Artikel 11: Reaktion und Wiederherstellung.(3)., Artikel 11: Reaktion und Wiederherstellung.(8)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.047 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 9. Sobald ein Security Incident unter Kontrolle ist, müssen die Wiederherstellungsmaßnahmen eingeleitet werden. Zu den Wiederherstellungsmaßnahmen gehören ggf. Wiederherstellung von Backups, Installation von Patches, Anpassung der Sicherheitskonfigurationseinstellungen, Änderung von Passwörtern/Zertifikaten, Anpassung der Netzwerk Perimeter-Sicherheit, Neuinstallation eines IT-Systems; | Artikel 11: Reaktion und Wiederherstellung (2) b)., Artikel 11: Reaktion und Wiederherstellung (2) c)., Artikel 11: Reaktion und Wiederherstellung.(3)., Artikel 11: Reaktion und Wiederherstellung.(8)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.048 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 10. Es sind Verfahren zur Erkennung von Security Incidents, (inkl. Definition von Frühwarnindikatoren ) zu etablieren, so dass sog. "false positives" möglichst vermieden aber Anomalien schnell erkannt werden. | Artikel 10: Erkennung.(1)., Artikel 10: Erkennung.(2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) a)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.049 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 11. Es muss Regelungen zur Initiierung forensischer Analysen sowie zur Protokollierung von Security Incidents geben. Hierbei dürfen die Originale des Beweises nicht verfälscht werden und sind sicher aufzubewahren. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.050 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 12. Es muss ein Verfahren zur Analyse, Bewertung/situativen Neubewertung und Entscheidung der Security Incidents nach zu definierenden Kriterien und unter Berücksichtigung des Schutzbedarfs geben. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.052 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 14. Kontrollen zur kontinuierlichen Überprüfung der Effektivität des Security Incident Managements sind zu definieren. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.053 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 15. Verfahren zur Berichterstattung über Security Incidents. Hierbei sind Kriterien für zu berichtende Incidents zu definieren. Hierbei ist auch ein Vorgehen zur Rückmeldung zu etablieren, um sicherzustellen, dass Personen, die Security Events berichten, nach Abschluss des daraus resultierenden Security Incidents eine qualifizierte Rückmeldung erhalten. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.005 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 16. Ein Security Incident ist zu dokumentieren, sobald er erkannt oder vermutet wird. Die Dokumentation ist sukzessive zu ergänzen, bis der Security Incident abgeschlossen wird. Es ist zu definieren, welche Informationen die abschließende Dokumentation enthalten muss. Mindestinhalte sind Ursache und Auswirkung, Klassifizierung, Zusammenfassung des Security Incidents, eingeleitete Maßnahmen, Datum und Uhrzeit. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.006 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 17. Die Aufbewahrungsfristen für die Dokumentation zu einem Security Incident sind entsprechend der gesetzlichen (u. a. DfS 500) und operativen Notwendigkeiten festzulegen. Sofern die Dokumentationen bei der Verfolgung strafrechtlicher oder zivilrechtlicher Ansprüche beweiserheblich sein können, ist im Einzelfall gesondert über die Aufbewahrungsdauer zu entscheiden. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.d). | relevant | |||||||
| R.0600.007 | C.0600.001 | Es ist ein Security Incident Management-Prozess etabliert, mit dem potenzielle Cyberangriffe schnell eingeordnet, behandelt und dokumentiert werden. | SBK 1 | 18. Der Prozess zur Behandlung von Security Incidents ist im Rahmen des Notfallmanagements zu testen. Der Test ist nachvollziehbar zu dokumentieren | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c). | relevant | |||||||
| R.0600.011 | C.0600.002 | Security Events werden korrekt erkannt und gemeldet. | SBK 1 | 1. Um die Auswirkungen potenzieller Security Incidents möglichst zu minimieren, sind Mitarbeiter und (externe) Auftragnehmer zur Meldung aller beobachteten oder vermuteten Security Events zu verpflichten. Zusätzlich sind externe Informationsquellen zur Identifikation von Sicherheitsereignissen (z. B. Kompromittierungsindikatoren) auszuwählen und zu nutzen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 03: IKT-Risikomanagement.e) iii), Artikel 19: Richtlinien für Personalpolitik.b) ii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) i), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) ii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) d). | relevant | |||||||
| R.0600.014 | C.0600.002 | Security Events werden korrekt erkannt und gemeldet. | SBK 1 | 2. Fehlfunktionen und abweichendes Systemverhalten sind grundsätzlich als Indikatoren für eine Beeinträchtigung der Systemsicherheit anzusehen und als Security Events zu bewerten. Mitarbeiter sind darauf zu sensibilisieren, mindestens folgende Situationen an die dafür vorgesehene Stelle zu melden: a) Unwirksame Sicherheitsmaßnahmen (z. B. nicht funktionierende Zutrittskontrolle); b) Verstöße gegen die erwartete Integrität, Vertraulichkeit oder Verfügbarkeit von Informationen; c) Menschliches Versagen; d) Nichteinhaltung von Vorgaben oder Leitlinien; e) Verstöße gegen physische Sicherungsvorkehrungen; f) unkontrollierte Systemänderungen; g) Fehlfunktionen von Software oder Hardware; h) Zugriffsverstöße. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b). | Artikel 19: Richtlinien für Personalpolitik.b) ii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) i), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) d). | relevant | |||||||
| R.0600.018 | C.0600.003 | Potentielle Schwachstellen werden von Mitarbeitenden gemeldet. | SBK 1 | 1. Um das Auftreten von Security Incidents zu verhindern, sind Mitarbeiter und (externe) Auftragnehmer zur Meldung aller beobachteten oder vermuteten Schwachstellen der Informationssicherheit zu verpflichten, um diese im Rahmen des Schwachstellenmanagements behandeln zu können. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 03: IKT-Risikomanagement.b) i) | relevant | |||||||
| R.0600.019 | C.0600.003 | Potentielle Schwachstellen werden von Mitarbeitenden gemeldet. | SBK 1 | 2. Das Meldeverfahren für Schwachstellen hat folgende Vorgaben zu erfüllen: a) Die Mitarbeiter und Auftragnehmer müssen diese Informationen so schnell wie möglich der dafür vorgesehen Stelle mitteilen. b) Für die Meldung von Schwachstellen müssen geeignete Formulare oder Eingabemasken zur Verfügung stehen. c) Mitarbeiter und Auftragnehmer sind darauf hinzuweisen, vermutete Schwachstellen nicht hinsichtlich ihrer tatsächlichen Nutzbarkeit zu testen, um Schäden an Systemen und Anwendungen sowie eine rechtliche Haftung der ausführenden Person zu vermeiden | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 03: IKT-Risikomanagement.b) i) | relevant | |||||||
| R.0600.023 | C.0600.004 | Security Events und Security Incidents werden nach einem einheitlichen Schema priorisiert und, bewertet und zeitnah bearbeitet. | SBK 1 | 1. Alle Security Events müssen durch die vorgesehene Stelle anhand eines einheitlichen Schemas bewertet und priorisiert werden. SIEM Alarmierungen müssen innerhalb von zu definierenden Reaktionszeiten während und außerhalb der Arbeitszeiten bearbeitet werden (24/7). Hierbei ist zu entscheiden, ob die Security Events als Security Incident einzustufen sind. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (6) -. | relevant | |||||||
| R.0600.025 | C.0600.004 | Security Events und Security Incidents werden nach einem einheitlichen Schema priorisiert und, bewertet und zeitnah bearbeitet. | SBK 1 | 2. Die Ergebnisse der Bewertung und Klassifizierung sind ausführlich zu dokumentieren, um die Nachvollziehbarkeit zu gewährleisten. Es sind Faktoren zu entwickeln und einzubeziehen, die Einfluss auf die Bewertung und Klassifizierung haben können | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (6) -. | relevant | |||||||
| R.0600.026 | C.0600.004 | Security Events und Security Incidents werden nach einem einheitlichen Schema priorisiert und, bewertet und zeitnah bearbeitet. | SBK 1 | 3. Existiert ein Information Security Incident Response Team (ISIRT), muss die Bewertung und Entscheidung an das ISIRT weitergeleitet werden, um eine Neubewertung oder eine Bestätigung zu erhalten. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) b)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (6) -. | relevant | |||||||
| R.0600.030 | C.0600.005 | Es werden Sofortmaßnahmen und ergänzende Maßnahmen ergriffen um nach einem Security Incident wieder das normale Sicherheitsniveau herzustellen. Bei wiederholten Security Incidents wird das Problem Management eingebunden. | SBK 1 | 1. Oberstes Ziel der Reaktion auf Security Incidents muss sein, zunächst ein "normales" Sicherheitsniveau herzustellen und anschließend notwendige Maßnahmen zur Wiederherstellung einzuleiten. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) f). | relevant | ||||||||
| R.0600.031 | C.0600.005 | Es werden Sofortmaßnahmen und ergänzende Maßnahmen ergriffen um nach einem Security Incident wieder das normale Sicherheitsniveau herzustellen. Bei wiederholten Security Incidents wird das Problem Management eingebunden. | SBK 1 | 2. Die Handlungsoptionen sind jeweils neu zu erarbeiten, sie müssen aus Sofortmaßnahmen und ergänzenden Maßnahmen bestehen. Die notwendigen Zeitspannen für die Durchführung dieser Maßnahmen und die erforderlichen Kosten und Ressourcen für die Problembehebung und Wiederherstellung sind abzuschätzen. Übersteigen Schadenshöhe, Zeit und Kosten eine vorbestimmte Grenze, ist vor der Entscheidung über die Maßnahmenauswahl die nächsthöhere Eskalations- und Entscheidungsebene miteinzubeziehen. Im Ergebnis müssen nach einer so strukturierten Analyse und Bewertung eines Security Incidents die Handlungsoptionen vorliegen | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) f). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.e). | relevant | |||||||
| R.0600.032 | C.0600.005 | Es werden Sofortmaßnahmen und ergänzende Maßnahmen ergriffen um nach einem Security Incident wieder das normale Sicherheitsniveau herzustellen. Bei wiederholten Security Incidents wird das Problem Management eingebunden. | SBK 1 | 3. Bei wiederholtem Auftreten oder größerem Umfang der Störung ist eine Analyse der Ursachen erforderlich. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | relevant | ||||||||
| R.0600.036 | C.0600.006 | Nach einem Security Incident werden Lessons Learned und wenn notwendig ergänzende Kontrollen umgesetzt. | SBK 1 | 1. Bevor der Security Incident geschlossen werden kann, ist sicherzustellen, dass die Ursache für den Security Incident vollständig behoben wurde, sofern die Ursachenanalyse nicht im Rahmen des Incident- oder Problemmanagements erfolgt. Die Entscheidung darüber, ob ein Security Incident geschlossen wird oder nicht, muss durch die Incident Management-Einheit erfolgen. | relevant | |||||||||
| R.0600.037 | C.0600.006 | Nach einem Security Incident werden Lessons Learned und wenn notwendig ergänzende Kontrollen umgesetzt. | SBK 1 | 2. Die aus den Security Incidents und deren Analyse gewonnenen Erkenntnisse sind zu nutzen, um die Wahrscheinlichkeit des Eintretens oder die Auswirkungen zukünftiger gleichartiger Ereignisse wirksam zu verringern ("Lessons Learned"), sowie eine schnelle Wiederherstellung zu ermöglichen. Dazu sind Prozesse und Maßnahmen zu etablieren, die sicherstellen, dass Art, Umfang und Kosten von Security Incidents bewertet und überwacht werden, um insbesondere wiederkehrende Security Incidents mit schwerwiegenden Auswirkungen zu ermitteln. | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.e). | relevant | ||||||||
| R.0600.038 | C.0600.006 | Nach einem Security Incident werden Lessons Learned und wenn notwendig ergänzende Kontrollen umgesetzt. | SBK 1 | 3. Es muss im Rahmen der Bewertung identifiziert werden, ob vorhandene Kontrollen ausgeweitet oder ergänzende Kontrollen umzusetzen sind, um Häufigkeit, Schadenpotenzial und Kosten von Vorfällen zu minimieren. | relevant | |||||||||
| R.0600.042 | C.0600.007 | Es ist ein Prozess zur Sicherung von Beweismaterial etabliert. | SBK 1 | 1. Zur Sicherung von Beweismaterial bei der Ermittlung von Ursachen von Security Incidents muss ein dokumentierter Prozess definiert und implementiert werden. | relevant | |||||||||
| R.0600.054 | C.0600.006 | Nach einem Security Incident werden Lessons Learned und wenn notwendig ergänzende Kontrollen umgesetzt. | SBK 1 | 4. Bei meldepflichtigen Security Incidents sind im Rahmen des „Lessons Learned“ zusätzlich die folgenden Punkte zu berücksichtigen: a) die Schnelligkeit bei der Reaktion auf Sicherheitsmeldungen und -warnungen; b) die Qualität und Schnelligkeit bei der Durchführung forensischer Analysen, sofern dies als zweckmäßig erachtet wird c) die Wirksamkeit der Eskalation von Vorfällen innerhalb des Unternehmens; d) die Wirksamkeit interner und externer Kommunikation e) Wirksamkeit der Prozesse. | Artikel 13: Lernprozesse und Weiterentwicklungen (2)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) a)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) b)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) c)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) d). | relevant | ||||||||
| 7 | R.0700 - Incident- und Problemmanagement | |||||||||||||
| R.0700.001 | C.0700.001 | Es ist ein Prozess zur Problemerkennung, Problem-Aufzeichnung, Kategorisierung und Priorisierung etabliert. | SBK 1 | 1. Es ist ein dokumentierter Prozess inkl. Rollen und Verantwortlichkeiten zum Problemmanagement zu etablieren, um die Ursachen von Incidents sowie Schwachstellen in der Servicelandschaft zu identifizieren und deren Beseitigung zu initiieren. | Artikel 19: Richtlinien für Personalpolitik.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) iii) | nicht relevant | ||||||||
| R.0700.013 | C.0700.001 | Es ist ein Prozess zur Problemerkennung, Problem-Aufzeichnung, Kategorisierung und Priorisierung etabliert. | SBK 1 | 2. Innerhalb des Prozesses zum Problemmanagement müssen Schnittstellen im Sinne eines Informationsaustausches und/oder einer Einbindung zu den nachfolgend aufgeführten Bereichen etabliert werden: a)\tIncident Management sowie Security Incident Management b)\tExternen Dienstleistern oder Herstellern c)\tInformation Security Management. | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a). | nicht relevant | ||||||||
| R.0700.014 | C.0700.001 | Es ist ein Prozess zur Problemerkennung, Problem-Aufzeichnung, Kategorisierung und Priorisierung etabliert. | SBK 1 | 3. Informationen aus dem Incident Management (z. B. Incident Reports) müssen mindestens monatlich auf wiederkehrende, vermehrt auftretende Incidents bzw. Incidents mit gleicher Ursache analysiert werden, die zu einer Meldepflicht führen könnten. Die für die Problembearbeitung relevanten Daten müssen in einem Datensatz (Problem Record) erfasst und während der Bearbeitung regelmäßig aktualisiert werden. | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a). | nicht relevant | ||||||||
| R.0700.015 | C.0700.002 | Es sind Prozesse zur Untersuchung, Diagnose, Lösung und Problemabschluss von Problemen etabliert. | SBK 1 | 1. Es sind dokumentierte Prozesse zur Diagnose und Lösung von Problemen zu etablieren, die mindestens die folgenden Anforderungen erfüllen: a) Die temporären Möglichkeiten zur Vermeidung von Auswirkungen der, auf dem behandelten Problem basierenden, Incidents müssen als Workaround erfasst, definiert und dokumentiert werden. b) Die identifizierten Ursachen müssen bewertet und nach passenden Lösungen zur Beseitigung des Problems gesucht werden. c) Es ist zu prüfen, ob die gefundene Lösung gegebenenfalls andere Services beeinträchtigt und ob beispielsweise ausreichend Ressourcen zur Verfügung stehen. d) Planung der Implementierung der Lösung zur Vermeidung eines erneuten Vorkommens im Kontext des Anforderungs- und Change-Managements. | nicht relevant | |||||||||
| R.0700.011 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 1. Es ist ein dokumentierter Prozess inkl. Rollen und Verantwortlichkeiten zum Incident Management zu etablieren, um Störungen zu erfassen und behandeln mit dem Ziel der schnellstmöglichen Wiederherstellung der gestörten Dienste. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 19: Richtlinien für Personalpolitik.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (1) -. | nicht relevant | |||||||
| R.0700.017 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 2. Es müssen im Rahmen des Prozesses, unter Berücksichtigung der verschiedenen Arten und Szenarien der Vorfälle, mindestens die folgenden Aspekte berücksichtigt werden: a)\tSecurity Incident Management; b)\tIT-Eventmanagement; c)\tBusiness Continuity Management, Notfall- und Krisenmanagement sowie IT-Service Continuity Management d)\texterne Dienstleister oder Hersteller e)\tIT-Knowledge Management (Wissensdatenbank für Entstörungen). | Artikel 11: Reaktion und Wiederherstellung.(2) e)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a). | nicht relevant | |||||||
| R.0700.012 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 3. Der Incident Management Prozess muss mindestens Verfahren zur Identifikation, Nachverfolgung, Protokollierung, Klassifikation und Priorisierung von Vorfällen, in Abhängigkeit von Geschäftsprozesskritikalität und Service-Vereinbarungen, umfassen. | Artikel 10: Erkennung.(2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) iii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (6) -. | nicht relevant | |||||||
| R.0700.018 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 4. Die Klassifizierung und Priorisierung von Incidents muss durch die vorgesehene Stelle nach einem einheitlichen Schema während und außerhalb der Arbeitszeiten (24/7) erfolgen, um sicherzustellen, dass die definierten Reaktionszeiten eingehalten werden. | Artikel 10: Erkennung.(2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (6) -. | nicht relevant | |||||||
| R.0700.019 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 5. Bei der Klassifizierung von IKT-bezogenen Vorfällen müssen mindestens die folgenden Kriterien berücksichtigt werden: a)\tKritikalität der betroffenen Services und Prozesse b)\tAnzahl und/oder Relevanz der Kunden oder Geschäftspartner, die von dem Vorfall betroffen sind, und der betroffenen Transaktionen c)\t(Potenzieller) Reputationsschaden d)\tDauer des Vorfalls einschließlich der Ausfallzeiten des Services e)\tgeografische Ausbreitung f)\tVerfügbarkeits-, Authentizitäts-, Integritäts- oder Vertraulichkeitsverluste von Informationen und Daten g)\twirtschaftliche Auswirkungen (inkl. direkte und indirekte Kosten und Verluste auf absoluter und relativer Basis) | Artikel 11: Reaktion und Wiederherstellung.(2) d)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) a)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) b)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) c)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) d)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) e)., Artikel 18: Klassifizierung von IKT-bezogenen Vorfällen und Cyberbedrohungen (1) f). | nicht relevant | ||||||||
| R.0700.020 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 6. Es müssen geeignete Verfahren/Pläne zur Reaktion auf Vorfälle etabliert sein, mit dem Ziel die Auswirkungen von Vorfällen zu minimieren und weitere Schäden zu vermeiden. Als Teil dieser interdisziplinären oder fachspezifischen Eindämmungsmaßnahmen, müssen mindestens Verfahren/Pläne zur Adressierung der wesentlichen Cyber-Bedrohungen vorliegen. | Artikel 11: Reaktion und Wiederherstellung (2) b)., Artikel 11: Reaktion und Wiederherstellung (2) c)., Artikel 11: Reaktion und Wiederherstellung.(3)., Artikel 11: Reaktion und Wiederherstellung.(8)., Artikel 14: Kommunikation (1)., Artikel 14: Kommunikation (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) f). | Artikel 13: Management der Netzwerksicherheit.j). | nicht relevant | |||||||
| R.0700.021 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 7. Unternehmensinterne Kommunikationspläne und Eskalationsprozesse müssen etabliert sein, welche in Abhängigkeit von der Kritikalität die Information des Managements (Fachbereich und IT) und der Geschäftsleitung gewährleisten. | Artikel 11: Reaktion und Wiederherstellung.(2) e)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) c)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) d)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) e)., Artikel 19: Meldung schwerwiegender IKT-bezogener Vorfälle und freiwillige Meldung erheblicher Cyberbedrohungen (3). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) ii) | nicht relevant | |||||||
| R.0700.022 | C.0700.003 | Es ist ein Prozess zur Störungserfassung, -dokumentation und -behandlung etabliert. Ein Lessons Learned wird nach Beendigung von Major Incidents und meldepflichtigen IKT bezogenen Vorfällen durchgeführt. | SBK 1 | 8. Für Incidents mit kritischer Einstufung (z.B. Major Incidents) muss nach Beendigung des Incidents unter Einbeziehung der beteiligten Parteien eine Nachschaubetrachtung durchgeführt und dokumentiert werden. Für meldepflichtige Incidents sind dabei zusätzlich die Wirksamkeit der Eskalation von Vorfällen innerhalb des Unternehmens, die Wirksamkeit Kommunikation sowie die Wirksamkeit der Prozesse zu berücksichtigen. | Artikel 13: Lernprozesse und Weiterentwicklungen (2)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) a)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) b)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) c)., Artikel 13: Lernprozesse und Weiterentwicklungen (2) d)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (2). | nicht relevant | ||||||||
| 8 | R.0800 - Kapazitäts- und Performancemanagement | |||||||||||||
| R.0800.001 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 1 | 1. Es sind dokumentierte Prozesse und Techniken zu implementieren, welche die Bereitstellung und Optimierung von Systemressourcen und Kapazitäten für den Betrieb sowie deren Überwachung regelt. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c)., Artikel 10: Erkennung.(3). | Artikel 09: Kapazitäts- und Leistungsmanagement (1) -., Artikel 09: Kapazitäts- und Leistungsmanagement (1) a)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) b)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) i), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) ii), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) iii) | nicht relevant | |||||||
| R.0800.002 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 1 | 2. Risikoorientiert sind diejenigen IT-Systeme auszuwählen, die einem Kapazitäts- und Performancemanagement unterzogen werden sollen. Für diese Systeme sind Nutzungstrends für alle Komponenten und Anwendungen zu ermitteln, die für die Aufrechterhaltung der von diesen bereitgestellten Diensten notwendig sind. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c)., Artikel 10: Erkennung.(3). | Artikel 09: Kapazitäts- und Leistungsmanagement (1) -., Artikel 09: Kapazitäts- und Leistungsmanagement (1) a)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) b)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) i), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) ii), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) iii) | nicht relevant | |||||||
| R.0800.005 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 4 | 3. Ein dokumentierter und systemspezifischer Kapazitätsmanagementplan muss je ausgewähltem Anwendungssystem erstellt werden und dieser muss mindestens folgende Aspekte berücksichtigen: a) Aktuelle und erwartete Anzahl von Transaktionen; b) Aktuelle und erwartete Spitzenlasten in Nutzung und Übertragung; c) Aktuelle Anzahl Nutzer; d) Erwartetes Wachstum der Nutzerzahl . | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c). | Artikel 09: Kapazitäts- und Leistungsmanagement (1) -., Artikel 09: Kapazitäts- und Leistungsmanagement (1) a)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) b)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) i), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) ii), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) iii) | nicht relevant | |||||||
| R.0800.006 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 1 | 4. Es müssen für die ausgewählten IT-Systeme Überwachungsmaßnahmen und Kontrollen eingerichtet werden, mit denen Kapazitäts- und Performanceengpässe rechtzeitig erkannt werden . | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c)., Artikel 10: Erkennung.(1)., Artikel 10: Erkennung.(2). | Artikel 09: Kapazitäts- und Leistungsmanagement (1) -., Artikel 09: Kapazitäts- und Leistungsmanagement (1) a)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) b)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) i), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) ii), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) iii), Artikel 12: Datenaufzeichnung (2) c) ii) | nicht relevant | |||||||
| R.0800.007 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 1 | 5. Bei Prognosen zu zukünftigen Kapazitätsanforderungen sind neue geschäftliche und systembezogene Anforderungen sowie aktuelle und zukünftige Trends bezüglich der informationsverarbeitenden Einrichtungen des Unternehmens in Betracht zu ziehen . | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c). | Artikel 09: Kapazitäts- und Leistungsmanagement (1) -., Artikel 09: Kapazitäts- und Leistungsmanagement (1) a)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) b)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c)., Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) i), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) ii), Artikel 09: Kapazitäts- und Leistungsmanagement (1) c) iii) | nicht relevant | |||||||
| R.0800.008 | C.0800.001 | Es sind Verfahren zur Ermittlung, Optimierung und Überwachung der IKT-Kapazität zur Gewährleistung der Systemeffizienz und- Verfügbarkeit etabliert (Kapazitäts- und Performancemanagement). | SBK 1 | 6. Die Kapazitäts- und Performanceanforderungen müssen unter Berücksichtigung der Betriebswichtigkeit und etwaiger Besonderheiten des betroffenen Systems (bspw. lange und komplexe Beschaffungs- und Freigabeprozesse) ermittelt werden . | Artikel 07: IKT-Systeme, -Protokolle und -Tools.c). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) -. | nicht relevant | |||||||
| 9 | R.0900 - Informationssicherheitsaspekte im Notfallmanagement | |||||||||||||
| R.0900.001 | C.0900.001 | Es sind Prozesse zur Berücksichtigung von Informationssicherheitsaspekten im Notfallmanagement etabliert und es wird eine Business Impact Analyse zur Bestimmung der Anforderungen an die Wiederherstellungszeiten durchgeführt. Zudem werden Wiederanlaufpläne für IT-Systeme erstellt. | SBK 1 | 1. Prozesse im Rahmen des Notfall- (Business Continuity Management (BCM)) und Krisenmanagements (IT-Service Continuity Management (IT-SCM)) müssen auch Maßnahmen zur Wahrung der Informationssicherheit und des Datenschutzes sowie zur Aufrechterhaltung des Informationssicherheitsmanagements umfassen. Aspekte der Informationssicherheit sind bereits während der Planungsphase zu berücksichtigen. | Artikel 11: Reaktion und Wiederherstellung.(7). | nicht relevant | ||||||||
| R.0900.002 | C.0900.001 | Es sind Prozesse zur Berücksichtigung von Informationssicherheitsaspekten im Notfallmanagement etabliert und es wird eine Business Impact Analyse zur Bestimmung der Anforderungen an die Wiederherstellungszeiten durchgeführt. Zudem werden Wiederanlaufpläne für IT-Systeme erstellt. | SBK 1 | 2. Die identifizierten Schutzbedarfe bzgl. Vertraulichkeit und Integrität von Informationen gelten unverändert auch im Falle eines Notfalls oder einer Krise und sind durch entsprechende zeitlich begrenzte Maßnahmen kontinuierlich zu decken. | nicht relevant | |||||||||
| R.0900.003 | C.0900.001 | Es sind Prozesse zur Berücksichtigung von Informationssicherheitsaspekten im Notfallmanagement etabliert und es wird eine Business Impact Analyse zur Bestimmung der Anforderungen an die Wiederherstellungszeiten durchgeführt. Zudem werden Wiederanlaufpläne für IT-Systeme erstellt. | SBK 1 | 3. Zur Bestimmung der Anforderungen an die Wiederherstellungszeiten (RTO) der IT-Services ist über einen definierten Prozess eine Business Impact Analyse durchzuführen. | Artikel 11: Reaktion und Wiederherstellung.(5). | nicht relevant | ||||||||
| R.0900.004 | C.0900.001 | Es sind Prozesse zur Berücksichtigung von Informationssicherheitsaspekten im Notfallmanagement etabliert und es wird eine Business Impact Analyse zur Bestimmung der Anforderungen an die Wiederherstellungszeiten durchgeführt. Zudem werden Wiederanlaufpläne für IT-Systeme erstellt. | SBK 1 | 4. Im Rahmen des IT-SCM sind für alle IT-Systeme (alle relevanten Bestandteile der Elementenkette aus IT-Systemen, Komponenten, Anwendungen und Daten), die zur Aufrechterhaltung des Geschäftsbetriebs notwendig sind, Wiederanlaufpläne zu erstellen. | Artikel 11: Reaktion und Wiederherstellung (2) b)., Artikel 11: Reaktion und Wiederherstellung (2) c)., Artikel 11: Reaktion und Wiederherstellung.(3)., Artikel 11: Reaktion und Wiederherstellung.(7)., Artikel 11: Reaktion und Wiederherstellung.(8). | nicht relevant | ||||||||
| R.0900.023 | C.0900.001 | Es sind Prozesse zur Berücksichtigung von Informationssicherheitsaspekten im Notfallmanagement etabliert und es wird eine Business Impact Analyse zur Bestimmung der Anforderungen an die Wiederherstellungszeiten durchgeführt. Zudem werden Wiederanlaufpläne für IT-Systeme erstellt. | SBK 1 | 5. Krisenkommunikationspläne müssen etabliert sein, welche in Abhängigkeit von der Kritikalität die Information des Managements (Fachbereich und IT), externer Interessensgruppen (z. B. Kunden, Marktteilnehmer, Regulierungsbehörden) und der Geschäftsleitung gewährleisten. | Artikel 11: Reaktion und Wiederherstellung.(2) e)., Artikel 14: Kommunikation (2)., Artikel 19: Meldung schwerwiegender IKT-bezogener Vorfälle und freiwillige Meldung erheblicher Cyberbedrohungen (3). | nicht relevant | ||||||||
| R.0900.008 | C.0900.002 | Es sind Rollen und Verantwortlichkeiten etabliert für das BCM und IT-SCM etabliert. Aspekte der Informationssicherheit sind in den Prozessen zu berücksichtigen. | SBK 1 | 1. Für BCM und IT-SCM sind Rollen und Verantwortlichkeiten zu etablieren. Im Rahmen der folgenden themenspezifischen Prozesse sind jeweils Aspekte der Informationssicherheit zu berücksichtigen: a) Erstellung einer Dreijahres- und Jahresplanung für Notfallübungen und Tests. b) Sicherstellung, dass Mitarbeiter, die Rollen im jeweiligen Themenfeld ausfüllen, über ausreichende Ausbildung, Training und Erfahrung verfügen. c) Überprüfung eventueller Korrekturmaßnahmen zur Sicherstellung der Angemessenheit und der Erfüllung interner und externer Vorgaben für das jeweilige Themengebiet. | Artikel 11: Reaktion und Wiederherstellung (4)., Artikel 11: Reaktion und Wiederherstellung (6) a)., Artikel 11: Reaktion und Wiederherstellung (6) b)., Artikel 11: Reaktion und Wiederherstellung., Artikel 11: Reaktion und Wiederherstellung., Artikel 25: Testen von IKT-Tools und -Systemen (1). | nicht relevant | ||||||||
| R.0900.009 | C.0900.002 | Es sind Rollen und Verantwortlichkeiten etabliert für das BCM und IT-SCM etabliert. Aspekte der Informationssicherheit sind in den Prozessen zu berücksichtigen. | SBK 1 | 2. Die Aufrechterhaltung der Informationssicherheit im BCM und IT-SCM ist durch geeignete, vollständig dokumentierte Prozesse und Maßnahmen sicherzustellen. | nicht relevant | |||||||||
| R.0900.013 | C.0900.003 | Kontinuierliche Überwachung der Aufrechterhaltung der Informationssicherheit | SBK 1 | 1. Die Verantwortlichen für das BCM und IT-SCM müssen die von ihnen dokumentierten Prozesse und Maßnahmen zur Aufrechterhaltung der Informationssicherheit regelmäßig jährlich auf Aktualität und Vollständigkeit kontrollieren und bei Bedarf an veränderte Anforderungen anpassen. | Artikel 19: Richtlinien für Personalpolitik.a). | nicht relevant | ||||||||
| R.0900.014 | C.0900.003 | Kontinuierliche Überwachung der Aufrechterhaltung der Informationssicherheit | SBK 1 | 2. Die Kontrolle der Prozesse und Maßnahmen im BCM und IT-SCM zur Aufrechterhaltung der Informationssicherheit zielt auf die Sicherstellung der Angemessenheit und Wirksamkeit der Prozesse und Maßnahmen im Fall eines Notfalls oder einer Krise ab. Dazu sind Übungen und Tests bzgl. der Funktionalität durchzuführen, die der Revalidierung der Prozesse dienen und auf regelmäßig überprüften Szenarien (inkl. Cyberangriffe, der zugehörigen Eindämmungs- und Sofortmaßnahmen sowie die Umstellung der primären IT-Infrastruktur auf die redundanten Kapazitäten) basieren, geplant sein und klar definierte Aufgaben und Ziele enthalten. | Artikel 08: Identifizierung (2)., Artikel 11: Reaktion und Wiederherstellung (4)., Artikel 11: Reaktion und Wiederherstellung (6) a)., Artikel 11: Reaktion und Wiederherstellung (6) b)., Artikel 11: Reaktion und Wiederherstellung., Artikel 11: Reaktion und Wiederherstellung., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 17: IKT-Änderungsmangement (1) g)., Artikel 25: Test des IKT-Geschäftsfortführungsplans (2) a)., Artikel 25: Test des IKT-Geschäftsfortführungsplans (2) b)., Artikel 25: Test des IKT-Geschäftsfortführungsplans (2) c)., Artikel 25: Test des IKT-Geschäftsfortführungsplans (2) e)., Artikel 26: IKT-Reaktions- und Wiederherstellungspläne (2) -., Artikel 26: IKT-Reaktions- und Wiederherstellungspläne (2) a)., Artikel 10: Schwachstellen- und Patch-Management (4) d)., Artikel 25: Test des IKT-Geschäftsfortführungsplans (2) e)., Artikel 26: IKT-Reaktions- und Wiederherstellungspläne (2) -. | nicht relevant | |||||||
| R.0900.018 | C.0900.004 | Die Verfügbarkeit und Redundanz für informationsverarbeitende Systeme wird sichergestellt. Es werden Tests durchgeführt, um die Wirksamkeit der Maßnahmen sicherzustellen. | SBK 1 | 1. Anhand von Kriterien (z.B. des Schutzbedarfs, kritische/wichtige Funktionen) der Anwendungen ist eine Verfügbarkeitsübersicht von Anwendungen mit folgenden Inhalten zu erstellen: a) geforderte Verfügbarkeit je Anwendung und unterstützende IT-Systeme; b) Recovery Time Objective, RTO; c) Recovery Point Objective, RPO. | Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (6). | Artikel 24: Komponenten der IKT-Geschäftsfortführungsleitlinie (1) b) ii) 2. | nicht relevant | |||||||
| R.0900.019 | C.0900.004 | Die Verfügbarkeit und Redundanz für informationsverarbeitende Systeme wird sichergestellt. Es werden Tests durchgeführt, um die Wirksamkeit der Maßnahmen sicherzustellen. | SBK 1 | 2. Kann bei einem Asset durch Nutzung der vorhandenen Systemarchitektur keine ausreichende Verfügbarkeit gewährleistet werden, müssen redundante Bestandteile oder Architekturen einbezogen werden. Daher ist auf Basis der identifizierten erforderlichen Verfügbarkeit von Komponenten die Maßnahmen zur Schaffung von Redundanzen zu dokumentieren. | Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (4). | nicht relevant | ||||||||
| R.0900.022 | C.0900.004 | Die Verfügbarkeit und Redundanz für informationsverarbeitende Systeme wird sichergestellt. Es werden Tests durchgeführt, um die Wirksamkeit der Maßnahmen sicherzustellen. | SBK 1 | 3. Sowohl im Rahmen der Implementierung einer Redundanzlösung als auch regelmäßig während ihres Betriebs sind Tests durchzuführen, um die Wirksamkeit der Maßnahmen zur Schaffung von Redundanzen sicherzustellen. | Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (4). | nicht relevant | ||||||||
| 33 | R.1000 Geistige Eigentumsrechte | |||||||||||||
| R.1000.020 | C.1000.001 | Gesetzliche, regulatorische und vertragliche Anforderungen mit Relevanz für Informationssicherheit sind identifiziert und dokumentiert. | SBK 1 | 1. Es sind Verfahren zu dokumentieren und zu etablieren, um die Einhaltung gesetzlicher, regulatorischer und vertraglicher Anforderungen in Bezug auf Informationssicherheit sicherzustellen. | relevant | |||||||||
| R.1000.005 | C.1000.002 | Gesetzliche Vorgaben in Bezug auf geistige Eigentumsrechte sind identifiziert und dokumentiert. | SBK 1 | 1. Es sind Verfahren zu dokumentieren und zu etablieren, um die Einhaltung gesetzlicher, regulatorischer und vertraglicher Anforderungen mit Bezug auf geistige Eigentumsrechte und die Verwendung urheberrechtlich geschützter Software sicherzustellen. | relevant | |||||||||
| R.1000.013 | C.1000.003 | Die jeweils geltenden nationalen und internationalen Regelungen zum Schutze personenbezogener Daten werden eingehalten. | SBK 1 | 1. Technische wie auch organisatorische Maßnahmen zur Sicherstellung eines rechts-konformen und nachhaltigen Schutzes von personenbezogenen Daten müssen etabliert und umgesetzt werden. | relevant | |||||||||
| R.1000.018 | C.1000.004 | Der Einsatz von digitalen Signaturen nachvollziehbar geregelt. | SBK 1 | 1. Beim Einsatz von digitalen Signaturen muss ein dokumentierter Prozess zum Einsatz etabliert und umgesetzt werden. | relevant | |||||||||
| R.1000.019 | C.1000.004 | Der Einsatz von digitalen Signaturen nachvollziehbar geregelt. | SBK 1 | 2. Es dürfen ausschließlich digitale Signaturzertifikate verwendet werden, die zentral bereitgestellt werden. | relevant | |||||||||
| R.1000.022 | C.1000.004 | Der Einsatz von digitalen Signaturen nachvollziehbar geregelt. | SBK 1 | 4. Digitale Signaturzertifikate dürfen ausschließlich zum festgelegten Anwendungszweck genutzt werden. | relevant | |||||||||
| 10 | R.1100 - Sicherheit in Projekten | |||||||||||||
| R.1100.001 | C.1100.001 | Informationssicherheitsanforderungen werden in Projekten berücksichtigt. | SBK 1 | 1. Über Projekte die direkt oder indirekt Auswirkungen auf die Organisation, Geschäftsprozesse, Datenverarbeitungseinrichtungen und –systeme und das Gebäudemanagement haben, und sich auf das Informationssicherheitsniveau des Unternehmens auswirken, ist die Abteilung Information Security Management zu Projektbeginn zu informieren. | nicht relevant | |||||||||
| R.1100.003 | C.1100.001 | Informationssicherheitsanforderungen werden in Projekten berücksichtigt. | SBK 4 | 1. Bei Projekten, in den Informationen dieser Schutzbedarfsklasse verarbeitet werden, kann die Abteilung Information Security Management entscheiden, ob sie als Mitglied der Projektorganisation (z. B. Steuerungsgremien im Projekt, Empfänger von Berichterstattungen aus dem Projekt) einbezogen sein möchte. | nicht relevant | |||||||||
| 11 | R.1200 - Personalsicherheit | |||||||||||||
| R.1200.001 | C.1200.001 | Mitarbeitende werden im Vorfeld der Einstellung einer Hintergrundüberprüfung unterzogen. | SBK 1 | 1. Hintergrundüberprüfungen sind vorzunehmen, um im Vorfeld der Einstellung Personen mit betrügerischen Absichten zu erkennen. | relevant | |||||||||
| R.1200.004 | C.1200.002 | Interne und externe Mitarbeitende sind zur Einhaltung der Leitlinien für Informationssicherheit und zur Vertraulichkeit verpflichtet sowie über etwaige Folgen bei nNchteinhaltung informiert. | SBK 1 | 1. Die vertraglichen Vereinbarungen mit den Mitarbeitern und externen Arbeitskräften müssen folgende Punkte abdecken: a) Die Mitarbeiter und externen Arbeitskräfte sind auf die Einhaltung der Leitlinie zur Informationssicherheit des Unternehmens zu verpflichten, sofern die Leistungserbringung bzw. die Verarbeitung der Informationen ausschließlich innerhalb des Unternehmens (auch im Rahmen von mobilem Arbeiten) erfolgt. b) Mitarbeiter und externe Arbeitskräfte sind darüber zu informieren, dass ggf. disziplinarische bzw. arbeitsrechtliche Maßnahmen bei vorsätzlichen oder (grob) fahrlässigen eingeleitet werden. | Artikel 19: Richtlinien für Personalpolitik.b) i) | relevant | ||||||||
| R.1200.005 | C.1200.002 | Interne und externe Mitarbeitende sind zur Einhaltung der Leitlinien für Informationssicherheit und zur Vertraulichkeit verpflichtet sowie über etwaige Folgen bei nNchteinhaltung informiert. | SBK 2 | 2. Alle Mitarbeiter und externe Arbeitskräfte, die Zugang zu nicht öffentlichen Informationen erhalten, müssen eine Vertraulichkeitserklärung unterzeichnen, bevor sie Zugang zu Einrichtungen zur Informationsverarbeitung erhalten. | relevant | |||||||||
| R.1200.007 | C.1200.002 | Interne und externe Mitarbeitende sind zur Einhaltung der Leitlinien für Informationssicherheit und zur Vertraulichkeit verpflichtet sowie über etwaige Folgen bei nNchteinhaltung informiert. | SBK 2 | 3. Mitarbeiter und externe Arbeitskräfte sind vor Zugriff auf nicht öffentliche Informationen bzw. Zugang zu Informationssystemen über ihre Funktionen und Zuständigkeiten hinsichtlich der Informationssicherheit zu informieren. | relevant | |||||||||
| R.1200.008 | C.1200.003 | Interne und externe Mitarbeiter werden regelmäßig im Hinblick auf relevante Themen der Informationssicherheit geschult. | SBK 1 | 1. Mitarbeiter und externe Arbeitskräfte sind entsprechend dem jeweiligen Bedarf zu schulen, um a) an sie gestellte Informationssicherheitsanforderungen zu kennen und zu beachten; b) Informationssicherheitsprobleme und -vorfälle zu erkennen und c) im Einklang mit den Erfordernissen ihres Aufgabengebiets reagieren zu können. | Artikel 05: Governance und Organisation (4)., Artikel 05: Governance und Organisation (4)., Artikel 13: Lernprozesse und Weiterentwicklungen (6). | relevant | ||||||||
| R.1200.009 | C.1200.003 | Interne und externe Mitarbeiter werden regelmäßig im Hinblick auf relevante Themen der Informationssicherheit geschult. | SBK 1 | 2. Die Schulung eines neuen Mitarbeiters muss mindestens folgende Punkte umfassen: a) Schulungsmaßnahmen, die Bezug auf Aspekte der Informationssicherheit am Arbeitsplatz des Mitarbeiters nehmen b) Kenntnisgabe relevanter Ansprechpartner für mindestens die folgenden Themen: - Fragen zum Informationssicherheitsmanagementsystem bzw. zur Informationssicherheit - Meldung von Schwachstellen - Meldung von Informationssicherheitsvorfällen c) Erläuterung der relevanten Vorgaben zur Informationssicherheit | Artikel 13: Lernprozesse und Weiterentwicklungen (6). | Artikel 19: Richtlinien für Personalpolitik.b) ii) | relevant | |||||||
| R.1200.014 | C.1200.003 | Interne und externe Mitarbeiter werden regelmäßig im Hinblick auf relevante Themen der Informationssicherheit geschult. | SBK 1 | 3. Die Schulung muss mindestens bei Neueinstellung, jährlich oder bei Bedarf absolviert werden. Die Absolvierung ist zu dokumentieren und von der Führungskraft bzw. dem Auftraggeber nachzuhalten. | Artikel 05: Governance und Organisation (4). | relevant | ||||||||
| R.1200.016 | C.1200.003 | Interne und externe Mitarbeiter werden regelmäßig im Hinblick auf relevante Themen der Informationssicherheit geschult. | SBK 1 | 4. Die Inhalte der Awarenessmaßnahmen (inklusive Schulung) zur Informationssicherheit werden regelmäßig auf Aktualität und Angemessenheit überprüft. | Artikel 05: Governance und Organisation (4). | relevant | ||||||||
| R.1200.012 | C.1200.004 | Es sind ausreichende personelle Ressourcen in der Informationssicherheit vorhanden. | SBK 1 | 1. Es muss sichergestellt sein, dass eine personelle Abdeckung für die Tätigkeiten in Verbindung mit der Umsetzung von Themenfeldern der Informationssicherheit vorhanden ist. | Artikel 10: Erkennung.(3). | relevant | ||||||||
| R.1200.013 | C.1200.004 | Es sind ausreichende personelle Ressourcen in der Informationssicherheit vorhanden. | SBK 1 | 2. Die berufliche Weiterbildung zum Erhalt von angemessenen Fähigkeiten und Qualifikationen im Bereich der Informationssicherheit muss geregelt sein. | Artikel 10: Erkennung.(3). | relevant | ||||||||
| R.1200.015 | C.1200.005 | Alle Assets werden vor Beendigung des Beschäftigungs-, Arbeits- oder Vertragsverhältnisses zurückgegeben. | SBK 1 | 1. Es müssen dokumentierte Prozesse etabliert werden, welche regeln, dass von allen Beschäftigten und externen Parteien bei Beendigung des Beschäftigungs-, Arbeits- oder Vertragsverhältnisses sämtliche Assets zurückzugeben sind. Es ist sicherzustellen, dass ein geregelter Prozess zur Rückgabe bzw. Vernichtung von Assets bei Beendigung des Beschäftigungs-, Arbeits- oder Vertragsverhältnisses implementiert ist. | Artikel 19: Richtlinien für Personalpolitik.b) iii) | relevant | ||||||||
| 12 | R.1300 - Überprüfung der Informationssicherheit durch Fachbereiche oder Prüfer | |||||||||||||
| R.1300.002 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 1. Alle Prüfungs- und Audit-Aktivitäten, die eine technische Überprüfung der produktiven IT-Systeme und Anwendungen beinhalten (z. B. Pentest, Schwachstellenscan, manueller Zugang zu den Systemen bzw. Zugriff auf Konfigurationen durch den Prüfer) müssen geplant, abgestimmt und von einem Kompetenzträger vor Einsatz genehmigt werden. Es ist bei der Genehmigung darauf zu achten, dass eingesetzte Tools/Werkzeuge im Einklang mit dem lokal geltenden Recht angewendet werden. | Artikel 25: Testen von IKT-Tools und -Systemen (1). | nicht relevant | ||||||||
| R.1300.008 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 2. Der Auditumfang (inkl. Zeitpunkt, Dauer, eingesetzte Tools/Werkzeuge etc.) muss dokumentiert und rechtzeitig vor Auditbeginn mit den fachlich verantwortlichen Organisationseinheiten sowie der Informationstechnologie abgestimmt werden. | nicht relevant | |||||||||
| R.1300.009 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 3. Audits und Prüfungen sind durch fachkundige und unabhängige Personen durchzuführen. | nicht relevant | |||||||||
| R.1300.010 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 4. Der Zugriff auf Informationen, Anwendungen und Systeme im Rahmen des Audits darf nur nach dem Need-to-Know-Prinzip erfolgen und muss mit den zuständigen Fachverantwortlichen abgestimmt werden. | nicht relevant | |||||||||
| R.1300.011 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 5. Die in den Prüfungen eingeräumten Berechtigungen sind grundsätzlich auf einen lesenden Zugriff auf Informationen, Anwendungen und Systeme zu beschränken. | nicht relevant | |||||||||
| R.1300.012 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 6. Ein über den Lesezugriff hinausgehender Zugang darf nur in Bezug auf isolierte Kopien gestattet werden, die nach Beendigung des Audits bzw. der Prüfung gelöscht, oder angemessen geschützt werden müssen, wenn diese Dateien aufgrund von Dokumentationsanforderungen aufzubewahren sind. | nicht relevant | |||||||||
| R.1300.013 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 7. Die Prüfungsaktivitäten sind in der Prüfungs- oder Auditdokumentation unter Nennung von Datum und Uhrzeit zu protokollieren. | nicht relevant | |||||||||
| R.1300.014 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 8. Audits und Prüfungen, die Einfluss auf die Systemverfügbarkeit haben können, sind so zu planen, dass negative Auswirkungen auf den Geschäftsbetrieb vermieden bzw. minimiert werden. | Artikel 26: Erweiterte Tests von IKT-Tools, -Systemen und -Prozessen auf Basis von TLPT (5). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) iv) | nicht relevant | |||||||
| R.1300.015 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 9. Werden im Rahmen von Audits oder Prüfungen Schwachstellen in Bezug auf Anwendungen oder Systeme erkannt, müssen diese unverzüglich gemäß den etablierten Meldewesen für Schwachstellen gemeldet werden. | nicht relevant | |||||||||
| R.1300.016 | C.1300.001 | Betriebliche Aspekte bei der Durchführung von Prüfungen und Audits für Informationssysteme werden berücksichtigt. | SBK 2 | 10. Erkannte Schwachstellen dürfen erst nach Freigabe des Auftraggebers und unter Abwägung der Risikosituation ausgenutzt werden. | nicht relevant | |||||||||
| R.1300.007 | C.1300.002 | Maßnahmen zu Sicherheitsvorgaben und –standards werden angemessen und wirksam umgesetzt. | SBK 1 | 1. Die umsetzungsverantwortlichen, sicherheitsgebenden Bereiche (z. B. Informationstechnologie, Personal, Infrastruktur- und Gebäudemanagement, Berechtigungsmanagement) müssen regelmäßig in den von ihnen verantworteten Prozessen des Unternehmens (z. B. Berechtigungsprozess, Incidentprozess, Entwicklungsprozess) überprüfen und dokumentieren, ob die aus den Sicherheitsvorgaben abgeleiteten Maßnahmen in den jeweiligen Prozessen angemessen und wirksam umgesetzt wurden. | nicht relevant | |||||||||
| 13 | R.1400 - Sicherheit im Anwendungsbetrieb | |||||||||||||
| R.1400.001 | C.1400.001 | Direkt mit dem Internet in Verbindung stehende Applikationen sind gesondert geschützt | SBK 1 | 1. Es sind mindestens Gegenmaßnahmen zu ergreifen, die sich an der aktuellen Bedrohungssituation orientieren (z. B. OWASP Top 10, BSI-Leitfaden zur Entwicklung sicherer Webanwendungen). | Internetapplikationen | nicht relevant | ||||||||
| R.1400.002 | C.1400.001 | Direkt mit dem Internet in Verbindung stehende Applikationen sind gesondert geschützt | SBK 2 | 1. Bei Anwendungen, die Dienste über öffentliche Netze bereitstellen bzw. über öffentliche Netze aufrufbar sind, müssen ergänzend Methoden zur Identifizierung und Authentifizierung der beteiligten Parteien etabliert sein. | Internetapplikationen | nicht relevant | ||||||||
| R.1400.034 | C.1400.001 | Direkt mit dem Internet in Verbindung stehende Applikationen sind gesondert geschützt | SBK 3 | 1. Die Anmeldung an Anwendungen und IT-Systemen, die über öffentliche Netze aufrufbar bzw. Dienste über öffentliche Netze bereitstellen , hat mittels einer starken Authentifizierung oder einer Authentifizierung aus dem Unternehmensnetz (SSO) zu erfolgen. | Internetapplikationen | Artikel 09: Schutz und Prävention.(4) d). | Artikel 21: Zugangskontrolle.f) ii) | nicht relevant | ||||||
| R.1400.009 | C.1400.001 | Direkt mit dem Internet in Verbindung stehende Applikationen sind gesondert geschützt | SBK 3 | 2. Informationssysteme, die Kundenschnittstellen hosten, dürfen keine Kundeninformationen persistent vorhalten. | Internetapplikationen | nicht relevant | ||||||||
| R.1400.033 | C.1400.001 | Direkt mit dem Internet in Verbindung stehende Applikationen sind gesondert geschützt | SBK 3 | 3. Die Auslösung von Internetzahlungen muss durch eine starke Authentifizierung erfolgen. | Internetapplikationen | Artikel 09: Schutz und Prävention.(4) d). | nicht relevant | |||||||
| R.1400.015 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 1. Die Regeln zum sicheren und angemessenen Umgang der Mitarbeiter mit dem Internet sind zu dokumentieren. Diese müssen mindestens die folgenden Aspekte umfassen: a) Die Nutzung des Internets ist ausschließlich für dienstliche Zwecke vorgesehen. Aus diesem Grund hat das Unternehmen das Recht, den Internetverkehr zum Schutz der System- und Netzwerksicherheit bei Bedarf zu überwachen und zu analysieren. b) Beschränkungen für unerwünschte oder ungeeignete Websites und webbasierte Anwendungen sind festzulegen. c) Sämtliche Unregelmäßigkeiten und Auffälligkeiten sind unverzüglich durch die Benutzer an den jeweiligen Helpdesk zu melden um ggf. auftretende Security Incidents erkennen zu können. d) Das Herunterladen von ausführbaren Programmen ist nicht gestattet. Werden ausführbare Programme für den betrieblichen Einsatz benötigt, sind diese über die IT bereitzustellen. | nicht relevant | |||||||||
| R.1400.016 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 2. Für die unterschiedlichen Einsatzszenarien, wie das "Surfen im Internet" und "Zugriff auf Anwendungen mittels Browser", muss eine einheitliche Vorgabe für die Bereitstellung von Browsern definiert sein. | nicht relevant | |||||||||
| R.1400.035 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 3. Die Zugänge zum Internet müssen durch Sicherheitsgateways (z. B. Internet-Proxy) gesichert werden, - um Schadsoftware und aktive Inhalte zu filtern - um den Zugriff auf unerwünschte Seiten zu verhindern - um die Authentisierung der IT-Systeme und Nutzer zu gewährleisten - um den Download potenziell unsicherer Dateien (z. B. ausführbare Dateien) zu unterbinden bzw. auf den berechtigten Benutzerkreis einzuschränken. | nicht relevant | |||||||||
| R.1400.036 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 4. Die Sicherheitseinstellungen für den Browser müssen über zentrale Gruppenrichtlinien (wie dem Active Directory) verwaltet werden. | nicht relevant | |||||||||
| R.1400.037 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 5. Um den Schutz von browserbasierenden Anwendungen zu gewährleisten, muss ein alternativer Browser bereitgestellt werden, wenn der Standardbrowser wegen bekanntgewordener Sicherheitslücken nicht zum Einsatz kommen darf und alternative Schutzmaßnahmen ausgeschlossen sind. | nicht relevant | |||||||||
| R.1400.038 | C.1400.002 | Regeln stellen sicher, dass Risiken im Zusammenhang mit der Nutzung des Internets auf das Notwendige reduziert sind. | SBK 1 | 6. In den MS-Office-Programmen muss die geschützte Ansicht für Daten aus Internet und Outlook-Anlagen aktiviert werden. Zur Bearbeitung muss der Anwender die geschützte Ansicht explizit deaktivieren. | nicht relevant | |||||||||
| R.1400.020 | C.1400.003 | Zu transaktionsbasierten Anwendungsdiensten sind erhöhte Sicherheitsmaßnahmen implementiert. | SBK 1 | 1. Bei transaktionsbasierten Anwendungsdiensten, die aus dem Internet erreichbar sind, muss sichergestellt werden, dass die Speicherung der Transaktionsdaten an einem nicht öffentlich zugänglichen Ort erfolgt. Sie dürfen nicht auf einem Speichermedium aufbewahrt und zur Verfügung gestellt werden, das direkt über das Internet zugänglich ist. | Transaktionsbasierte Anwendungsdienste | nicht relevant | ||||||||
| R.1400.022 | C.1400.003 | Zu transaktionsbasierten Anwendungsdiensten sind erhöhte Sicherheitsmaßnahmen implementiert. | SBK 3 | 1. Informationen, die im Zuge von Transaktionen im Zusammenhang mit Anwendungsdiensten übertragen werden, sind vor Vervielfältigung oder wiederholter Wiedergabe (Replay-Angriff) zu schützen. | Transaktionsbasierte Anwendungsdienste | nicht relevant | ||||||||
| R.1400.026 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 1. Wird verschiedenen Mandanten Zugriff auf dieselbe IT-Anwendung gewährt, muss die IT-Anwendung mandantenfähig sein, d. h. sie muss gewährleisten, dass Daten unterschiedlicher Mandanten so getrennt und unabhängig voneinander verarbeitet werden, dass die Daten der Mandanten untereinander nicht einsehbar oder veränderbar sind. | Mandantensysteme | nicht relevant | ||||||||
| R.1400.039 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 2. Wird verschiedenen Mandanten Zugriff auf dieselbe IT-Anwendung gewährt, müssen sich die Benutzer der Mandanten beim Anmeldevorgang über pseudonymisierte Mandantenmerkmale in der Benutzerkennung (z. B. durch eine Mandantennummer) oder andere eindeutige Authentisierungsmerkmale (z. B. Zertifikat) authentisieren. | Mandantensysteme | nicht relevant | ||||||||
| R.1400.040 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 3. Sämtliche administrative Tätigkeiten und Verfahren (z. B. Konfiguration, Berechtigungs- und Benutzerverwaltung, Datensicherung, Datenrücksicherung, Wiederherstellung, Aktualisierung von Software und Hardware) bei IT-Anwendungen mit Mandantentrennung müssen so ausgestaltet sein, dass zu jeder Zeit die Mandantentrennung aufrechterhalten bleibt. | Mandantensysteme | nicht relevant | ||||||||
| R.1400.041 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 4. Sofern externe Verbindungen von Mandanten auf Serverebene terminieren bzw. dem Mandanten administrative Berechtigungen für spezifische Server gewährt werden, ist sicherzustellen, dass Verbindungen von diesem Server auf andere IT-Systeme im Netz des Unternehmens nicht möglich sind. Dies ist grundsätzlich durch geeignete Segmentierung im Netzwerk sicherzustellen. | Mandantensysteme | nicht relevant | ||||||||
| R.1400.028 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 5. Bei Einsatz einer nicht mandantenfähigen Anwendung für mehrere Mandanten ist eine Trennung auf Serverebene erforderlich (dedizierte Anwendungsserver, Webserver, Datenbankserver, Middleware-Server, etc.). | Mandantensysteme | nicht relevant | ||||||||
| R.1400.030 | C.1400.004 | Die Trennung der Daten verschiedener Kunden ist durch angemessene Maßnahmen immer gewährleistet. | SBK 2 | 6. Die Mandantenfähigkeit der zugrundeliegenden Software muss vom Hersteller/Entwickler (z. B. durch ein IDW PS 880) attestiert werden. | Mandantensysteme | nicht relevant | ||||||||
| R.1400.042 | C.1400.005 | KI-unterstützte Systeme sind gesondert geschützt. | SBK 2 | 1. Bei KI-Systemen sind geeignete Gegenmaßnahmen zu ergreifen, die sich an der aktuellen Bedrohungssituation und den für KI-Systeme spezifischen Bedrohungen, insbesondere zur Manipulation und/oder Beeinträchtigung des KI-Systems oder der Extraktion von Informationen aus dem KI-System (z. B. Prompt Injection, Data and Model Poisoning, Evasion Attacks), gemäß gängigen Standards (z. B. OWASP, NIST, BSI) orientieren. | KI-Systeme | nicht relevant | ||||||||
| 14 | R.1500 - Anwendungs- und Betriebsdokumentation | |||||||||||||
| R.1500.001 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 1. Für die eingesetzten IT-Systeme und Telekommunikationseinrichtungen müssen mindestens die folgenden Dokumentationen vorhanden sein: a) technische Betriebsdokumentation (IT-Konzept, Betriebshandbuch); b) fachliche Benutzerdokumentation (Anwenderdokumentation); c) Sicherheitskonzept; d) Berechtigungskonzept; e) Löschkonzept bei personenbezogenen Daten; f) Dokumentation "Data Protection by Design and Data Protection by Default" bei personenbezogenen Daten. | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a). | nicht relevant | ||||||||
| R.1500.002 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 2. Änderungen an den Dokumentationen sind zu versionieren und durch den fachlich Verantwortlichen zu genehmigen. | nicht relevant | |||||||||
| R.1500.003 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 3. Die Dokumentationen müssen verständlich und damit für einen sachverständigen Dritten in angemessener Zeit nachprüfbar sein. | nicht relevant | |||||||||
| R.1500.004 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 4. Die Dokumentationen sind bei Änderungen an den IT-Systemen und Anwendungen auf ihre Aktualität zu überprüfen. | nicht relevant | |||||||||
| R.1500.005 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 5. Die technische Betriebsdokumentation muss - sofern nicht bereits in einem separaten Dokument geregelt - mindestens die folgenden Punkte regeln: a) Die Installation, Wartung, Konfiguration und Deinstallation der Systeme (Konfigurationsdokumentation) inkl. einer Kennzeichnung der sicherheitsrelevanten Konfigurationen; b) Die automatisierte und manuelle Verarbeitung von Informationen, inkl. Schnittstellen und Kommunikation; c) Datensicherungsverfahren inkl. Art und Häufigkeit von Backups; d) Abläufe und Abhängigkeiten in Betriebsroutinen (z. B. Batchläufe); e) Umgang mit bereits bekannten Fehlersituationen ("known errors"); f) Die Ansprechpartner für Support (intern/extern) und Eskalation; g) Die Anforderungen an RPO und RTO bei einem Systemausfall und/oder einem Datenverlust; h) Die Anforderungen an den System-Start und-Neustart. | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) i), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) ii), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) ii) | nicht relevant | ||||||||
| R.1500.006 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 1 | 6. Die Sicherheitskonzepte müssen - sofern nicht bereits in einem separaten Dokument geregelt - mindestens die folgenden Punkte regeln bzw. darüber Auskunft geben: a) Schutzbedarfsklasse der Verfügbarkeit, Vertraulichkeit und Integrität; b) Beschreibung der technischen und administrativen Sicherheitsmaßnahmen inkl. Referenz zu den jeweiligen Sicherheitsvorgaben; c) Beschreibung der Anwendungs- und Systemhärtung; d) Sicherheitsrelevante Protokollinformationen und deren Auswertung; e) Vorhandene Abweichungen von den Sicherheitsvorgaben; f) Ggf. vorhandene (Rest)risiken (z. B. in Form eines Verweises auf das Risikoinventar). | nicht relevant | |||||||||
| R.1500.007 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 2 | 1. Die technischen Betriebsdokumentationen müssen - sofern nicht bereits in einem separaten Dokument geregelt - mindestens die folgenden Punkte ergänzend regeln: a) Die Verwaltung von Systemprotokollinformationen; b) Die eingesetzten Überwachungsverfahren (Systemmonitoring); c) Die technische Administration; d) Wiederherstellungsprozeduren. | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) ii), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) iii), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) iii) | nicht relevant | ||||||||
| R.1500.008 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 2 | 2. Bei der Verwendung von TIA sind mindestens die folgenden Anforderungen bei der Dokumentation zu erfüllen: a) Alle Datenquellen, Logiken und erwarteten Ergebnisse der Anwendung sind zu dokumentieren. b) Quellcodes sind verständlich und nachvollziehbar zu dokumentieren (z. B. durch Kommentierungen im Quellcode). | nicht relevant | |||||||||
| R.1500.009 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 2 | 3. Die Dokumentationen sind regelmäßig auf ihre Aktualität zu überprüfen. | nicht relevant | |||||||||
| R.1500.010 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 2 | 4. Bei der Verwendung von TIA's ist eine Anwenderdokumentation zu erstellen. | nicht relevant | |||||||||
| R.1500.011 | C.1500.001 | Anwendungssysteme müssen eine umfassende und aktuelle Dokumentation vorweisen, die klar verständlich für Dritte ist und eine Versionskontrolle beinhaltet. | SBK 3 | 1. Bei Integritätsanforderungen dieser Stufe muss die technische Betriebsdokumentation folgende Punkte definieren: a) Datenorganisation und Datenstrukturen inkl. Datensatzaufbau bzw. Tabellenaufbau bei Datenbanken. b) Veränderbare Tabelleninhalte, die bei der Erzeugung von Werten oder Kalkulationen herangezogen werden. c) Programmierte Verarbeitungsregeln einschließlich der implementierten Eingabe- und Verarbeitungskontrollen. d) programminterne Fehlerbehandlungsverfahren. e) Schnittstellen zu anderen Anwendungen und Systemen. | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) a) ii) | nicht relevant | ||||||||
| 29 | R.1600 – Sicherheitsanforderungen an Dienstleister/Lieferanten | |||||||||||||
| R.1600.001 | C.1600.001 | Die Informationssicherheit in einem Dienstleistungsverhältnis ist geregelt. | SBK 1 | 1. Es sind Prozesse zum Management von Dienstleistungen zu dokumentieren und umzusetzen. | Artikel 05: Governance und Organisation (3)., Artikel 28: Allgemeine Prinzipien (5). | Artikel 11: Daten- und Systemsicherheit (2) k). | nicht relevant | |||||||
| R.1600.027 | C.1600.001 | Die Informationssicherheit in einem Dienstleistungsverhältnis ist geregelt. | SBK 1 | 2. Das Information Security Management und Datenschutz ist vor Abschluss von IT-Dienstleistungsverhältnissen in die erforderliche Vorab-Risikobewertung einzubeziehen. | Artikel 05: Governance und Organisation (3)., Artikel 28: Allgemeine Prinzipien (5). | nicht relevant | ||||||||
| R.1600.028 | C.1600.001 | Die Informationssicherheit in einem Dienstleistungsverhältnis ist geregelt. | SBK 1 | 3. Die relevanten Aspekte zur Einhaltung der Informationssicherheitsvorgaben und der Vorgaben des Datenschutzes sind im Kontext der Dienstleistungsverhältnisse zu vereinbaren. | Artikel 05: Governance und Organisation (3)., Artikel 28: Allgemeine Prinzipien (5). | nicht relevant | ||||||||
| R.1600.029 | C.1600.001 | Die Informationssicherheit in einem Dienstleistungsverhältnis ist geregelt. | SBK 1 | 4. Die aus der Vorab-Risikoanalyse abgeleiteten risikomindernden Informationssicherheitsmaßnahmen sowie ggf. Datenschutzmaßnahmen sind im Kontext der Dienstleistungsverhältnisse zu vereinbaren. | Artikel 05: Governance und Organisation (3)., Artikel 28: Allgemeine Prinzipien (5). | nicht relevant | ||||||||
| R.1600.030 | C.1600.001 | Die Informationssicherheit in einem Dienstleistungsverhältnis ist geregelt. | SBK 1 | 5. In Bezug auf die Informationssicherheit müssen die Verantwortlichkeiten des Unternehmens, des Dienstleisters und gemeinsame Verantwortungen sowie alle hierfür notwendige Schnittstellen festgelegt und umgesetzt werden. Angemessene Kompetenzen für das Management und die Sicherheit der in Anspruch genommenen Dienstleistungen sind sicherzustellen und aufrechtzuerhalten. Die geteilten Verantwortungen müssen insbesondere bei der Absicherung des genutzten Dienstes und bei sicherheitsbezogenen Prozessen, wie dem Security Incident Management, berücksichtigt werden, da es hier vorkommen kann, dass das Unternehmen nicht die Möglichkeiten und Zugriffe hat, um ohne die Unterstützung des Dienstleisters angemessen zu agieren. | Artikel 05: Governance und Organisation (3)., Artikel 28: Allgemeine Prinzipien (5). | Artikel 11: Daten- und Systemsicherheit (2) k)., Artikel 11: Daten- und Systemsicherheit (2) k) a), Artikel 11: Daten- und Systemsicherheit (2) k) b), Artikel 11: Daten- und Systemsicherheit (2) k) c), Artikel 11: Daten- und Systemsicherheit (2) k) d) | nicht relevant | |||||||
| R.1600.003 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 1 | 6. Generell darf ein Dienstleister erst dann Berechtigungen bzgl. Räumen, Systemen und Informationen erhalten, wenn ein Vertrag unterschrieben wurde, der die Bedingungen für einen Zutritt, Zugang und Zugriff regelt. | nicht relevant | |||||||||
| R.1600.008 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 1. Es sind vertragliche Aspekte bei Auslagerungen, bei denen die Leistungserbringung bzw. die Verarbeitung der Informationen nicht innerhalb des Unternehmens erfolgt, mit den Dienstleistern zu vereinbaren. | nicht relevant | |||||||||
| R.1600.031 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 2. Der Dienstleister ist zu verpflichten, ein ISMS auf Basis eines anerkannten Standards gemäß AT 7.2 der MaRisk (z. B. ISO27001, BSI Grundschutz) zu betreiben. Der Informationssicherheitsstandard umfasst mindestens Aufgaben der Planung, der Implementierung, des Betriebs, der Überwachung, des Reportings, der Pflege und Durchführung kontinuierlicher Verbesserungen von Maßnahmen, die zur Gewährleistung der Verfügbarkeit, der Vertraulichkeit, der Integrität und der Authentizität der vom Dienstleister sowie dessen Subdienstleistern im Auftrag des Unternehmens verwalteten Informationen/Daten und Ressourcen dienen. | Artikel 11: Daten- und Systemsicherheit (2) k) d) | nicht relevant | ||||||||
| R.1600.032 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 3. Der Dienstleister ist zu verpflichten, Sicherheitsvorgaben des Unternehmens unter Berücksichtigung der Schutzbedarfsklassifizierung einzuhalten. | Artikel 19: Richtlinien für Personalpolitik.b) i) | nicht relevant | ||||||||
| R.1600.033 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 4. Der Dienstleister ist zu verpflichten, dem Unternehmen mindestens einmal pro Kalenderjahr einen Informationssicherheitsbericht zur Verfügung zu stellen, der aussagekräftige Informationen zu Aktualität, Angemessenheit und Funktionsfähigkeit des ISMS in Bezug auf die Leistungserbringung beinhaltet. | nicht relevant | |||||||||
| R.1600.034 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 5. Der Dienstleister ist zu verpflichten, dem Unternehmen mindestens jährlich einen Risikobericht mit allen die Leistungserbringung betreffenden Informationssicherheitsrisiken zur Verfügung zu stellen. | nicht relevant | |||||||||
| R.1600.035 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 6. Der Dienstleister ist zu verpflichten, dem Unternehmen die jeweils aktuellen Kontaktinformationen für Themen der Informationssicherheit zur Verfügung zu stellen. | Artikel 19: Richtlinien für Personalpolitik.b) ii) | nicht relevant | ||||||||
| R.1600.036 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 7. Der Dienstleister ist zu verpflichten, das Unternehmen auf Anfrage bei Untersuchungen von Informationssicherheitsvorfällen und kritischen Schwachstellen zu unterstützen und sicherheitsrelevante Informationen auf Anfrage an das Unternehmen herauszugeben, sofern sie für das Vertragsverhältnis relevant sind. | Artikel 10: Schwachstellen- und Patch-Management (2) c)., Artikel 10: Schwachstellen- und Patch-Management (2) c) i), Artikel 11: Daten- und Systemsicherheit (2) k). | nicht relevant | ||||||||
| R.1600.037 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 8. Der Dienstleister ist zu verpflichten, Schwachstellen in Zusammenhang mit den genutzten IT Assets von erbrachten Dienstleistungen zu untersuchen, die Ursachen zu ermitteln sowie geeignete Maßnahmen zu ergreifen. | Artikel 10: Schwachstellen- und Patch-Management (2) c)., Artikel 10: Schwachstellen- und Patch-Management (2) c) i) | nicht relevant | ||||||||
| R.1600.038 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 2 | 9. Der Dienstleister ist zu verpflichten, kritische Schwachstellen zeitnah zu melden. | Artikel 08: Identifizierung (2). | Artikel 10: Schwachstellen- und Patch-Management (2) c) ii) | nicht relevant | |||||||
| R.1600.009 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 3 | 1. Der Dienstleister ist vertraglich zu verpflichten: a) sofern erforderlich, bei der Erstellung von Risikoanalysen und Sicherheitskonzepten durch Bereitstellung der notwendigen Informationen zu unterstützen, und b) ein Sicherheitskonzept inkl. organisatorischer, technischer, physischer und prozessualer Vorgaben für seine im Rahmen der Leistungserbringung für das Unternehmen genutzten IT-Systeme und Infrastrukturen zu erstellen. | nicht relevant | |||||||||
| R.1600.011 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 3 | 2. Mit dem Dienstleister sind, sofern es sich um zeitkritische Geschäftsprozesse handelt: a) Notfallkonzepte gemäß der MaRisk AT 7.3 abzustimmen und b) die Wiederherstellung und Wiederherstellungsübungen sowie deren Durchführung und Dokumentation zu vereinbaren. | nicht relevant | |||||||||
| R.1600.039 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 3 | 3. Das Recht zur Überprüfung der Einhaltung der vertraglich vereinbarten Informationssicherheitsvorgaben durch z.B. Audits muss vom externen Dienstleister gegenüber der Helaba gewährt werden. | Artikel 28: Allgemeine Prinzipien (6). | nicht relevant | ||||||||
| R.1600.040 | C.1600.002 | Die Anforderungen an die Informationssicherheit im Rahmen von Dienstleistungsverträgen sind berücksichtigt. | SBK 4 | 1. Der Dienstleister ist zu verpflichten, regelmäßig Statistiken und Trends bezogen auf Schwachstellen zu berichten. | Artikel 10: Schwachstellen- und Patch-Management (2) c) ii) | nicht relevant | ||||||||
| R.1600.017 | C.1600.003 | Leistungserbringung durch Subdienstleister (Unterbeauftragungen) sind geregelt. | SBK 2 | 1. Der Dienstleister ist zu verpflichten, die vertraglich vereinbarten Regelungen und Sicherheitsanforderungen ebenfalls bei der Leistungserbringung durch einen Subdienstleister zu gewährleisten. Die beauftragten Subdienstleister sind mindestens dem Unternehmen bekannt zu geben. | nicht relevant | |||||||||
| R.1600.022 | C.1600.004 | Überwachung der Informationssicherheitsanforderungen bei Dienstleistern sind geregelt. | SBK 2 | 1. Der auslagernde Fachbereich muss die Berichte zur Informationssicherheit und zum Datenschutz auf vorhandene Informationssicherheitsrisiken bzw. Datenschutzrisiken hin überprüfen und diese in das Risikomanagement des Unternehmens überführen. | nicht relevant | |||||||||
| R.1600.042 | C.1600.004 | Überwachung der Informationssicherheitsanforderungen bei Dienstleistern sind geregelt. | SBK 2 | 2. Im Rahmen der Dienstleistungserbringung ist mindestens jährlich eine Überprüfung auf Aktualität und Konsistenz der vertraglich festgelegten Sicherheitsvorgaben durchzuführen. | nicht relevant | |||||||||
| R.1600.026 | C.1600.005 | Veränderung des Dienstleistungsumfanges/-angebotes und die Prüfung auf Auswirkungen sind geregelt. | SBK 2 | 1. Der auslagernde Fachbereich muss vertragliche Änderungen an der Bereitstellung von Diensten durch Dienstleister auf ihre Auswirkungen auf die Informationssicherheit prüfen. | nicht relevant | |||||||||
| 15 | R.1700 - Informationsübertragung | |||||||||||||
| R.1700.001 | C.1700.001 | Policies und Prozesse zur Informationsübertragung sind etabliert. Maßnahmen zur Verhinderung von unzulässigen Datenabflüssen sind etabliert. | SBK 1 | 1. Die Anforderungen bei Nutzung von Kommunikationseinrichtungen oder der Übertragung von Informationen müssen dokumentiert sein, dazu gehören mindestens E-Mail, TK-Anlagen und Cloud Services. Folgende Angaben sind mindestens zu definieren: a) Verantwortlichkeiten von Mitarbeitern und Auftragnehmern bei Übertragung unternehmenseigener Informationen; b) Erlaubte Kommunikationskanäle und -einrichtungen; c) Rollen und Ansprechpartner; d) Zugehörige Maßnahmen, um eine sichere Informationsübertragung ohne größere Unterbrechungen und unangemessene Verzögerungen zu gewährleisten. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(3) c). | Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.002 | C.1700.001 | Policies und Prozesse zur Informationsübertragung sind etabliert. Maßnahmen zur Verhinderung von unzulässigen Datenabflüssen sind etabliert. | SBK 1 | 2. Unabhängig von der Art der Informationsübertragung dürfen Informationen nur im Rahmen der geschäftlichen Notwendigkeit weitergegeben werden. Die unkontrollierte Weiterleitung von Geschäftsinformationen (z. B. durch E-Mail-Regeln) ist untersagt. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(3) c). | relevant | ||||||||
| R.1700.044 | C.1700.001 | Policies und Prozesse zur Informationsübertragung sind etabliert. Maßnahmen zur Verhinderung von unzulässigen Datenabflüssen sind etabliert. | SBK 2 | 1. Es müssen für potenzielle Datenabflusskanäle prozessuale, organisatorische oder technische Maßnahmen gegen unzulässige Übertragung von Informationen („Data Leakage“) etabliert werden. Dabei sind insbesondere die Vorgaben gemäß „R.0100 - Klassifizierung und Kennzeichnung von Informationen“ zu beachten. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(3) c). | Artikel 11: Daten- und Systemsicherheit (2) i)., Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.046 | C.1700.001 | Policies und Prozesse zur Informationsübertragung sind etabliert. Maßnahmen zur Verhinderung von unzulässigen Datenabflüssen sind etabliert. | SBK 4 | 1. Bei Weitergabe von Informationen muss die Zustimmung des Informationseigentümers vorliegen. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(3) c). | relevant | ||||||||
| R.1700.008 | C.1700.002 | Vereinbarungen zur wiederkehrenden technischen Informationsübertragung an Externe sind getroffen. | SBK 2 | 1. Zur wiederkehrenden sicheren Übertragung von Geschäftsinformationen mit externen Parteien über automatisierte Schnittstellen sind entsprechende Vereinbarungen zu treffen und zu dokumentieren. Diese müssen mindestens die folgenden Aspekte umfassen: a) Verantwortlichkeiten zur Kontrolle und Benachrichtigung über die erfolgte Übertragung, Weiterleitung und Erhalt; b) Technische Anforderungen an die Informationsübertragung; c) Verantwortlichkeiten und Haftung im Fall eines Security Incidents, z. B. durch einen Datenverlust; d) Vereinbarungen zum Einsatz von Verschlüsselungstechniken. | Artikel 09: Schutz und Prävention.(3) a). | Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.011 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 1 | 1. Die Übertragung von Informationen über nicht genehmigte Kommunikationskanäle (z. B. private E-Mail, nicht genehmigte Cloud-Services) ist nicht gestattet. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.012 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 2 | 2. Die Übertragung von Informationen auf elektronischem Weg ist vor unautorisiertem Zugriff, unberechtigte Veränderung oder Zerstörung entsprechend der identifizierten Schutzbedarfe der übertragenen Informationen zu schützen. | Artikel 09: Schutz und Prävention.(3) a). | Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.045 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 2 | 3. Die Zuverlässigkeit und Verfügbarkeit der Kommunikationsdienste muss sichergestellt werden. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.013 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 2 | 4. Bei der Übertragung von Informationen über öffentliche Netze müssen die Integrität und die Vertraulichkeit elektronisch übermittelter Informationen gemäß ihrem Schutzbedarf durch den Einsatz von kryptografischen Verfahren sichergestellt werden. Bei E-Mails muss eine Transportverschlüsselung (mindestens TLS oder Vergleichbares) eingesetzt werden. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.016 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 4 | 1. Bei Übertragung von Daten über interne Netze müssen kryptographische Verfahren verwendet werden, um die Integrität und die Vertraulichkeit elektronisch übermittelter Daten sicherzustellen. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | relevant | |||||||
| R.1700.047 | C.1700.003 | Die elektronische Übertragung von Informationen ist angemessen gesichert. | SBK 4 | 2. E-Mails müssen mittels einer Ende-zu-Ende-Verschlüsselung (PGP, S-MIME oder Vergleichbares) geschützt werden. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 12: Datenaufzeichnung (2) d). | relevant | |||||||
| R.1700.019 | C.1700.004 | Der Betrieb von TK-Anlagen ist angemessen gesichert. | SBK 2 | 1. Beim Betrieb von TK-Anlagen und deren Komponenten sind mindestens die folgenden Anforderungen zu erfüllen: a) Alle Komponenten der TK-Anlage, insbesondere ISDN-Karte/Modems, dürfen nicht von außen direkt erreichbar sein, sofern dies nicht explizit für betriebliche Zwecke erforderlich ist. Sofern die Schnittstellen aus betrieblichen Gründen nicht deaktiviert werden können, ist der Zugang auf ein Minimum zu reduzieren. Zugänge sind zu protokollieren. b) ISDN- oder Modem-Anschlüsse sind so zu konfigurieren, dass nicht berechtigte Nummern abgelehnt werden. c) Die anwählbaren Anschlüsse sind regelmäßig daraufhin zu überprüfen, ob diese für betriebliche Zwecke noch genutzt werden. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.021 | C.1700.004 | Der Betrieb von TK-Anlagen ist angemessen gesichert. | SBK 3 | 1. Die TK-Anlage ist an eine Notstromversorgung anzubinden. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.026 | C.1700.005 | Die Sicherheit in Mailsystemen wird durch geeignete Maßnahmen sichergestellt. | SBK 1 | 1. Für den Einsatz von Systemen für den externen E-Mail-Verkehr über das Internet gelten folgende, technisch zu unterstützende, Anforderungen: a) Es ist festzulegen, welche Dateitypen aus sicherheitsrelevanten Gründen von den Benutzern unmittelbar als Anlagen versendet / empfangen werden dürfen. Generell ist das Einspielen ausführbarer Programme in die internen Netze via E-Mail zu unterbinden. b) Jeder Nutzer erhält grundsätzlich ein eigenes elektronisches Postfach in Verbindung mit einer persönlichen E-Mailadresse, die über eine Zugriffsberechtigung gegen Missbrauch zu schützen ist. c) Es ist ein Filter einzusetzen, der alle von extern eingehenden E-Mails mittels technischer Verfahren hinsichtlich schadhafter bzw. betrügerischer Inhalte und Links überprüft und ggfls. aussortiert. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.027 | C.1700.005 | Die Sicherheit in Mailsystemen wird durch geeignete Maßnahmen sichergestellt. | SBK 1 | 2. Multifunktionsgeräte sind so zu konfigurieren, dass durch Scans generierte E-Mails nur an interne Adressen und nicht direkt an externe Empfängeradressen gesendet werden können. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.028 | C.1700.005 | Die Sicherheit in Mailsystemen wird durch geeignete Maßnahmen sichergestellt. | SBK 1 | 3. Die Regeln zum Umgang der Mitarbeiter mit dem Mailsystem sind in einer Arbeitsanweisung zu dokumentieren. Diese muss mindestens die folgenden Aspekte umfassen: a) Die verschlüsselte Übertragung von E-Mails b) Eine automatische Weiterleitung von E-Mails auf externe Postfächer außerhalb der Kontrolle des Unternehmens ist grundsätzlich nicht gestattet. c) Sämtliche Unregelmäßigkeiten und Auffälligkeiten sind unverzüglich durch die Benutzer an den jeweiligen Helpdesk zu melden. d) Regelungen zum Einrichten von Funktionspostfächern (Sammelpostfächer) sind zu definieren. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.1700.048 | C.1700.005 | Die Sicherheit in Mailsystemen wird durch geeignete Maßnahmen sichergestellt. | SBK 1 | 4. Das Vortäuschen (Spoofing) von unternehmenseigenen E-Mail-Adressen muss durch geeignete technische Maßnahmen verhindert werden. | relevant | |||||||||
| R.1700.033 | C.1700.006 | Vertraulichkeits- oder Geheimhaltungsvereinbarungen sind etabliert. | SBK 2 | 1. Vertraulichkeits- oder Geheimhaltungsvereinbarungen müssen mindestens die folgenden Aspekte umfassen: a) zu schützende Informationen; b) Gültigkeitszeitraum der Vereinbarung, inkl. Anwendungsfälle, in denen die Vertraulichkeit der übertragenen Informationen über den Gültigkeitszeitraum hinaus sicherzustellen ist; c) Vorgehensweise bei Beendigung oder Auslaufen der Vereinbarung; d) Verantwortlichkeiten der Vertragsparteien, um unautorisierte Offenlegung von Informationen zu vermeiden; e) Eigentum von Informationen und Geschäftsgeheimnissen sowie Regelungen zu geistigem Eigentum; f) einen Prozess für die Meldung bei unautorisierter Offenlegung oder Verlust vertraulicher Informationen, bei dem der Mitarbeiter, welcher den Verlust entdeckt, den Vorfall unmittelbar an eine zentrale Stelle meldet. g) Regelungen zur Rückgabe und Vernichtung von Informationen bei Beendigung der Vereinbarung. | Artikel 14: Sicherung von Informationen bei der Übermittlung (1) c). | relevant | ||||||||
| R.1700.037 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 1 | 1. Werden von Dienstleistern bereitgestellte Cloud-Services genutzt, sind die folgenden Aspekte vertraglich zu vereinbaren und vom Anbieter zu gewährleisten: a) Eine Systembeschreibung mit nachvollziehbaren und transparenten Angaben zum bezogenen Cloud-Dienst b) Bei einem (kurzfristigen) Vertragsende (z. B. auch bei Insolvenz) muss sichergestellt sein, dass der Cloud-Anbieter dem Unternehmen alle in der Cloud gespeicherten Daten in einem weiterverarbeitbaren elektronischen Format (z. B. CSV, XML) zur Verfügung stellt. c) Der Cloud-Anbieter muss sichere Netzwerkprotokolle für die Nutzung sowie für den Import und Export von Informationen bereitstellen. Diese müssen von Organisationen wie ENISTA, NIST, BSI und ISO als sichere Technologien eingestuft werden. | Cloud | relevant | ||||||||
| R.1700.038 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 1 | 2. Der Zugriff auf den Cloud-Service muss über eine starke Authentifizierung oder eine Authentifizierung aus dem Unternehmensnetz (SSO) erfolgen. | Cloud | Artikel 09: Schutz und Prävention.(3) a)., Artikel 09: Schutz und Prävention.(4) d). | relevant | |||||||
| R.1700.040 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 2 | 1. Je nach gesetzlichen Anforderungen muss der Ort der Datenspeicherung eingeschränkt werden (z. B. Cloud-Dienst in Deutschland oder der Europäischen Union). | Cloud | Artikel 09: Schutz und Prävention.(3) a). | relevant | |||||||
| R.1700.043 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 2 | 2. Sofern es sich nicht um Kopien von Dateien handelt, die in dem Online-Speicher abgelegt werden, muss ein Backup dieser Dateien sichergestellt werden. | Cloud | Artikel 09: Schutz und Prävention.(3) a). | relevant | |||||||
| R.1700.041 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 2 | 3. In der Cloud gespeicherte Daten sind zu verschlüsseln. Der Schlüssel muss sicher verwahrt werden. Dies umfasst die Speicherung des Schlüssels als auch die Nachvollziehbarkeit über die Nutzung, Zugriff und Änderungen. | Cloud | Artikel 09: Schutz und Prävention.(3) a). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||
| R.1700.042 | C.1700.007 | Die Sicherheit bei der Verwendung von Cloud-Services von Dienstleistern ist durch vertragliche Aspekte, einer starken Authentifizierung sowie durch kryptografische Maßnahmen sichergestellt. | SBK 4 | 1. Es muss ein „Customer Managed Key“ Verfahren für das Schlüsselmanagement verwendet werden, das die Hoheit über den Schlüssel sicherstellt. Im Falle von personenbezogenen Daten (P4) ist ein „Hold your own Key“ Verfahren für das Schlüsselmanagement zu verwenden, das den Zugriff des Dienstleisters auf den Schlüssel verhindert. Ist dies nicht möglich, so ist eine Einzelprüfung mit dem Datenschutzbeauftragten durchzuführen. | Cloud | Artikel 09: Schutz und Prävention.(3) a). | relevant | |||||||
| 16 | R.1800 - Kryptographische Verfahren | |||||||||||||
| R.1800.002 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 1. In einer zentralen Kryptographie-Richtlinie ist mindestens das Vorgehen und die Verantwortlichkeiten für die Verwendung adäquater asymmetrischer und symmetrischer kryptographischer Verfahren (Verschlüsselungsalgorithmen und Hash-Verfahren) und Verfahren des Schlüsselmanagements für verschiedene Anwendungsfelder zu definieren. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (1) -. | nicht relevant | ||||||||
| R.1800.011 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 2. Die Kryptographie-Richtlinie muss mindestens jährlich sowie anlassbezogen bei Änderungen überprüft und bei Bedarf aktualisiert bzw. angepasst und anschließend veröffentlicht werden. | Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (4) -. | nicht relevant | |||||||
| R.1800.012 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 3. Bei Neueinführung von Algorithmen sind ausschließlich dem Stand der Technik entsprechende, nicht wesentlich geschwächte bzw. nicht gebrochene kryptographische Verfahren einzusetzen. Darüber hinaus, sollte bei der Auswahl des kryptografischen Verfahrens, unter Einbeziehung betrieblicher Aspekte, der im Sinne des Stands der Technik als sicher prognostizierte Zeitraum so weit als möglich in der Zukunft liegen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (3) -. | nicht relevant | |||||||
| R.1800.013 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 4. Gebrochene Verfahren sind für den Betrieb nicht zulässig. Für bestehende, wesentlich geschwächte oder gebrochene Algorithmen, die sich im Betrieb befinden, sind im Rahmen des Schwachstellenmanagementprozesses zu überwachen. Identifizierte Abweichungen sind im Rahmen des Risikomanagementprozesses zu behandeln. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (3) -. ,Artikel 06: Verschlüsselung und kryptografische Kontrollen (4) -. | nicht relevant | ||||||||
| R.1800.003 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 5. Beim Einsatz kryptographischer Verfahren muss sichergestellt werden, dass das angestrebte Ergebnis eines Geschäftsprozesses auch unter Einsatz von kryptographischen Verfahren erzielt wird. | nicht relevant | |||||||||
| R.1800.014 | C.1800.001 | Die eingesetzten kryptographischer Verfahren sind im Rahmen eines Kryptokonzepts dokumentiert und entsprechen dem Stand der Technik. Die Verfahren sind nicht gebrochen und ermöglichen die Wiederherstellbarkeit von verschlüsselten Originalinformationen. | SBK 1 | 6. Verschlüsselte Informationen müssen jederzeit durch Berechtigte wiederherstellbar sind sein und die Originalinformationen für das Unternehmen verfügbar bleiben. | nicht relevant | |||||||||
| R.1800.008 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 1. Im Rahmen der Verwendung von kryptographischen Sicherheitsmaßnahmen ist die vertrauliche und authentische Erzeugung, Verteilung/Austausch, Installation und Verwaltung von geeigneten Schlüsseln sicherzustellen. | Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) d)., Artikel 07: Management kryptografischer Schlüssel (1) -., Artikel 07: Management kryptografischer Schlüssel (2) -. | nicht relevant | |||||||
| R.1800.015 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 2. Bei Verwendung von Zertifikaten (z. B. bei digitalen Signaturen) sind zuverlässige und vertrauenswürdige Quellen zu verwenden. | Artikel 07: Management kryptografischer Schlüssel (4) -., Artikel 07: Management kryptografischer Schlüssel (5) -. | nicht relevant | ||||||||
| R.1800.016 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 3. Beim Einsatz von Zertifikaten sind Gültigkeitsprüfungen durchzuführen. Es muss sichergestellt werden, dass diese rechtzeitig vor Ablauf ihrer Gültigkeit erneuert werden. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 12: Datenaufzeichnung (2) d)., Artikel 07: Management kryptografischer Schlüssel (5) -. | nicht relevant | ||||||||
| R.1800.017 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 4. Der Schlüssel muss einer natürlichen Person zugeordnet sein. Ist ein System zugeordnet, muss die entsprechende verantwortliche natürliche Person dokumentiert sein. | nicht relevant | |||||||||
| R.1800.018 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 5. Die Schlüsselerzeugung muss in einer sicheren Umgebung unter dem Einsatz geeigneter, dem Stand der Technik angemessener Schlüsselgeneratoren erfolgen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 07: Management kryptografischer Schlüssel (2) -. | nicht relevant | |||||||
| R.1800.019 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 6. Schlüssel sind durch geeignete Verfahren vor unbefugtem Zugriff zu schützen. | Artikel 09: Schutz und Prävention.(4) d). | Artikel 07: Management kryptografischer Schlüssel (2) -. | nicht relevant | |||||||
| R.1800.020 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 7. Bei der Wahl eines symmetrischen Verschlüsselungsverfahrens muss die Übertragung des Schlüssels über einen sicheren Kommunikationskanal erfolgen, so dass ausschließlich der berechtigte Empfänger diesen zur Kenntnis bekommt. | Artikel 07: Management kryptografischer Schlüssel (2) -. | nicht relevant | ||||||||
| R.1800.021 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 8. Kompromittierte Schlüssel müssen unverzüglich gesperrt bzw. deaktiviert werden. | Artikel 07: Management kryptografischer Schlüssel (3) -. | nicht relevant | ||||||||
| R.1800.022 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 9. Abgelaufene Schlüssel sind gemäß einem festgelegten Verfahren zu ersetzen und unverzüglich zu sperren. | Artikel 07: Management kryptografischer Schlüssel (3) -. | nicht relevant | ||||||||
| R.1800.023 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 10. Nicht mehr im Einsatz befindliche Schlüssel müssen archiviert werden und im Anschluss daran unter Nutzung des festgelegten Verfahrens zur sicheren Datenvernichtung gelöscht werden. | Artikel 07: Management kryptografischer Schlüssel (3) -. | nicht relevant | ||||||||
| R.1800.024 | C.1800.002 | Die Schlüsselerzeugung erfolgt im Rahmen vertraulicher Prozesse aus vertrauenswürdigen und zuverlässigen Quellen. Verwendete Zertifikate sind gültig und dokumentiert und kompromittierte Schlüssel werden unmittelbar deaktiviert. Die Übertragung symmetrischen Schlüsselmaterials erfolgt über einen sicheren Kommunikationskanal. Schlüssel werden vor unbefugten Zugriffen geschützt und in einer sicheren Umgebung generiert. | SBK 2 | 11. Zertifikate sowie Geräte, in denen die zugehörigen privaten Schlüssel gespeichert werden, sind in einem zentralen Register zu führen. Das Register muss mindestens diejenigen IT-Systeme abdecken, die kritische/wichtige Funktionen unterstützen. Das Register ist aktuell zu halten. Mindestinhalte des Registers sind eine eindeutige Kennzeichnung, der verwendete Krypto-Algorithmus, der Zertifikateherausgeber sowie der Verantwortliche für das Zertifikat. | Artikel 07: Management kryptografischer Schlüssel (4) -. | nicht relevant | ||||||||
| R.1800.009 | C.1800.003 | Verfahren für die sichere Verwaltung von asymmetrischen Schlüsseln sind dokumentiert und etabliert. | SBK 2 | 1. Zur Verwaltung asymmetrischer Schlüsselzertifikate und zugehöriger Informationen ist eine PKI (z. B. gem. RFC 3647) zu verwenden. Im Rahmen dieser sind Verfahren / Vorgaben zu dokumentieren. | nicht relevant | |||||||||
| R.1800.025 | C.1800.003 | Verfahren für die sichere Verwaltung von asymmetrischen Schlüsseln sind dokumentiert und etabliert. | SBK 2 | 2. Die nachfolgenden Aspekte müssen bei der Verwaltung von asymmetrischen Schlüsseln innerhalb einer PKI geregelt werden: a) Aufbau der Zertifizierungsstruktur b) Erstellung von Zertifikaten inkl. der eindeutigen Zuordnung von Signaturschlüsseln zu natürlichen Personen oder Systemen c) Verteilung/Austausch von Zertifikaten d) Prüfung der Vertrauenswürdigkeit von Zertifikaten e) Sperrung von Zertifikaten inkl. Anweisung, wann und wie Schlüssel zu sperren bzw. zu deaktivieren sind f) Verteilung/Austausch von Schlüsseln, inkl. Anweisungen für die Mitarbeiter, wie mit den erhaltenen Schlüsseln umzugehen ist g) Importieren von Schlüsseln h) Exportieren von Schlüsseln i) Umschlüsselung bzw. Wechsel von Schlüsseln j) Wiederherstellen von nicht verfügbaren bzw. Ersetzung von kompromittierten Schlüsseln. k) Archivierung und Löschung von Schlüsseln, inkl. Umgang mit Schlüsseln ausgeschiedener Mitarbeiter l) Protokollierung und Prüfung der Schlüsselverwaltung m) Treuhändische Schlüsselhinterlegung (Key-Escrow). | Artikel 07: Management kryptografischer Schlüssel (1) -. | nicht relevant | ||||||||
| R.1800.010 | C.1800.004 | Verfahren für die sichere Verwaltung von symmetrischen Schlüsseln sind dokumentiert und etabliert. | SBK 2 | 1. Zur Verwaltung von symmetrischen Schlüsseln sind anwendungsspezifisch folgende Aspekten zu regeln und zu dokumentieren: a) Verteilung/Austausch von Schlüsseln b) Sichere Aufbewahrung der verwendeten Schlüssel und Geheimnisse (Passphrase, PIN etc.) c) Importieren von Schlüsseln d) Exportieren von Schlüsseln e) Wiederherstellen von nicht verfügbaren bzw. Ersetzung von kompromittierten Schlüsseln f) Ersetzen der bisherigen Verschlüsselung (Umschlüsselung) von Daten g) Treuhändische Schlüsselhinterlegung (Key-Escrow) h) Archivierung von Schlüsseln. | Artikel 07: Management kryptografischer Schlüssel (1) -. | nicht relevant | ||||||||
| 17 | R.1900 - Datensicherung und Archivierung | |||||||||||||
| R.1900.001 | C.1900.001 | Prozesse zur Datensicherung und –wiederherstellung stellen die vollständige und richtige Rücksicherung von Daten sicher | SBK 1 | 1. Zur Datensicherung und –wiederherstellung sind dokumentierte Verfahren und Vorgaben zu etablieren, die mindestens die folgenden Aspekte unter Berücksichtigung des Schutzbedarfs umfassen: a) Rollen und Verantwortlichkeiten; b) Häufigkeit, Ausprägung und Umfang der Datensicherung; c) Art der Datensicherung inkl. Trennung der gesicherten Daten (physisch/logisch) und deren Verschlüsselung; d) Qualitätssicherung und Kontrollen von Datensicherung; e) Regelungen zur Auslagerung von Datensicherungsmedien bzw. zur redundanten Datenhaltung; f) Überwachung der ordnungsgemäßen Datensicherung; g) Integritätsprüfungen (integrity checks) nach Datenwiederherstellung h) Testen der Datensicherungsverfahren sowie die Wiedergewinnungs- und Wiederherstellungsverfahren und -methoden. | Artikel 09: Schutz und Prävention.(3) d)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (1) a)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (1) b)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (2)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (3)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (2)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (3)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (4)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (6)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (7)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) i) | nicht relevant | |||||||
| R.1900.014 | C.1900.001 | Prozesse zur Datensicherung und –wiederherstellung stellen die vollständige und richtige Rücksicherung von Daten sicher | SBK 1 | 2. Der Zeitpunkt der Durchführung der Datensicherung muss so gewählt werden, dass die Verfügbarkeit der Systeme sowie die konfliktfreie Durchführung sichergestellt ist. | Artikel 09: Schutz und Prävention.(3) d)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (2)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (3). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) i) | nicht relevant | |||||||
| R.1900.003 | C.1900.001 | Prozesse zur Datensicherung und –wiederherstellung stellen die vollständige und richtige Rücksicherung von Daten sicher | SBK 2 | 1. Für Anwendungen und IT-Systeme ist ein Datensicherungskonzept zu erstellen, welches mindestens die folgenden Aspekte umfasst: a) Art der Datensicherung inkl. Trennung der gesicherten Daten (physisch/logisch) und deren Verschlüsselung; b) Häufigkeit, Ausprägung, Umfang und Zeitpunkt der Datensicherung; c) Anzahl der Generationen, Aufbewahrungsdauer und Löschfristen; d) Festlegung der zu verwendenden/zu nutzenden Speichermedien (unter Beachtung der Abwärtskompatibilität); e) Wiederherstellung-/Recovery-Tests; f) Integritätskontrolle der gesicherten Daten. | Artikel 09: Schutz und Prävention.(3) d)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (1) a)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (7). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) i) | nicht relevant | |||||||
| R.1900.005 | C.1900.001 | Prozesse zur Datensicherung und –wiederherstellung stellen die vollständige und richtige Rücksicherung von Daten sicher | SBK 3 | 1. Für Anwendungen und IT-Systeme muss geregelt werden, welche neu erzeugten und geänderten Daten bzw. Dateien im Rahmen des mindestens täglichen Sicherungslaufs gesichert werden müssen. | Artikel 09: Schutz und Prävention.(3) d)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (1) a). | nicht relevant | ||||||||
| R.1900.013 | C.1900.001 | Prozesse zur Datensicherung und –wiederherstellung stellen die vollständige und richtige Rücksicherung von Daten sicher | SBK 3 | 2. Datensicherungen müssen vor unberechtigten Änderungen, z.B. durch Ransomware, geschützt werden (beispielsweise durch Offline Backups, Air-Gapping). | Artikel 09: Schutz und Prävention.(3) d)., Artikel 12: Richtlinie und Verfahren zum Backup sowie Verfahren und Methoden zur Wiedergewinnung und Wiederherstellung (3). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) i) | nicht relevant | |||||||
| R.1900.007 | C.1900.002 | Verfahren zur Archivierung stellen sicher, dass Daten entsprechend ihrer Aufbewahrungsfristen gespeichert und wiederhergestellt werden. | SBK 1 | 1. Die innerhalb des Unternehmens aufzubewahrenden bzw. zu archivierenden Dokumente und Daten (z. B. auch Soft- und Hardwarelizenzen, Handbücher) sowie deren Aufbewahrungsfristen und Ziele müssen unter Berücksichtigung der gesetzlichen und regulatorischen Anforderungen und Vorgaben an die Auswertbarkeit (z. B. Handelsgesetzbuch, Abgabenordnung, Wertpapierhandelsgesetz) zentral festgelegt werden. | Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| R.1900.008 | C.1900.002 | Verfahren zur Archivierung stellen sicher, dass Daten entsprechend ihrer Aufbewahrungsfristen gespeichert und wiederhergestellt werden. | SBK 1 | 2. Es sind dokumentierte Prozesse zur Archivierung von Daten/Dokumenten sowie zur Überwachung der Archivierung zu etablieren. | Artikel 09: Schutz und Prävention.(3) d). | nicht relevant | ||||||||
| 18 | R.2000 - Passwortmanagement und Authentisierung | |||||||||||||
| R.2000.003 | C.2000.001 | Passwortlänge, -komplexität und -gültigkeit und Verwendung sind gemäß eines technischen Standards in Form einer Passwortlichtlinie definiert und dokumentiert und werden im Rahmen ihrer Verwendung technisch erzwungen. | SBK 2 | 1. Bei der Verwendung von Benutzerkonten (Standardbenutzer, technische Benutzer, HPU etc.) zur Anmeldung an IT-Systemen und Anwendungen oder bei der Verschlüsselung von Dateien sind Passwörter gemäß eines gängigen Standards (z. B. NIST Special Publication 800-63B Digital Identity Guidelines) technisch zu erzwingen. Dies betrifft unter anderem die Ausgestaltung der Passwortlänge, Komplexität und Gültigkeit. Abgeleitet aus dem gewählten gängigen Standard sind Passwortrichtlinien zu definieren und dokumentieren. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.008 | C.2000.002 | Passwörter werden sicher übermittelt. | SBK 2 | 1. Vorläufige (Initial-)Passwörter müssen individuell und zufällig erzeugt sowie dem Benutzer auf sichere Art und Weise übergeben werden, sodass unberechtigte Dritte keinen Zugriff auf die (Initial-)Passwörter erhalten. | relevant | |||||||||
| R.2000.009 | C.2000.002 | Passwörter werden sicher übermittelt. | SBK 2 | 2. Es muss ein dokumentierter Prozess zur eindeutigen Identifizierung des Empfängers implementiert sein. | relevant | |||||||||
| R.2000.010 | C.2000.002 | Passwörter werden sicher übermittelt. | SBK 2 | 3. Es ist sicherzustellen, dass die Nutzer das Initial-Passwort bei der ersten Verwendung ändern. | relevant | |||||||||
| R.2000.014 | C.2000.003 | Verfahren zu sicheren Passwortänderungen sind etabliert. | SBK 2 | 1. Standardpasswörter/Initialpasswörter von IT-Systemen und Anwendungen sind vor Inbetriebnahme der Produktionsumgebung zu ändern. Bei (Verdacht auf) Kenntnis des Passwortes durch einen unberechtigten Dritten ist dieses sofort zu ändern. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.015 | C.2000.003 | Verfahren zu sicheren Passwortänderungen sind etabliert. | SBK 2 | 2. Passwörter dürfen nur durch administrative Eingriffe über die Benutzerverwaltung oder durch den Benutzer selbst geändert werden. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.016 | C.2000.003 | Verfahren zu sicheren Passwortänderungen sind etabliert. | SBK 3 | 1. Zur Änderung eines Passworts durch den Benutzer selbst muss das zurzeit aktuelle Passwort mit angegeben werden. Die Umsetzung der Anforderung ist technisch sicherzustellen. | relevant | |||||||||
| R.2000.024 | C.2000.004 | Angemessene Verfahren und Regelungen zur automatischen Sperrung/Freigabe von Benutzerkonten sind etabliert | SBK 2 | 1. Es sind Regeln zur automatisierten Sperrung von (unbenutzten) Benutzerkonten festzulegen. | relevant | |||||||||
| R.2000.026 | C.2000.004 | Angemessene Verfahren und Regelungen zur automatischen Sperrung/Freigabe von Benutzerkonten sind etabliert | SBK 2 | 2. Ein dauerhaft gesperrtes Benutzerkonto darf nur nach Identifizierung des Benutzers entsperrt werden. Hierbei darf ein Administrator bzw. ein Benutzerkontenverwalter sein eigenes Benutzerkonto nicht unter Nutzung seiner administrativen Rechte selbst aktivieren. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.027 | C.2000.004 | Angemessene Verfahren und Regelungen zur automatischen Sperrung/Freigabe von Benutzerkonten sind etabliert | SBK 3 | 1. Es muss sichergestellt sein, dass ein Verfahren bzgl. der Freischaltung von gesperrten Benutzerkennungen etabliert ist, um in einem definierten Zeitraum gesperrte Benutzer wieder zu entsperren. | relevant | |||||||||
| R.2000.036 | C.2000.005 | Regelungen zur technische Passwortverarbeitung, inklusive des Verbots der Ablage im Klartext sowie Maßnahmen zur Verschlüsselung und Hashen sind etabliert. | SBK 2 | 1. Passwörter dürfen in IT-Systemen nicht im Klartext abgelegt, zwischengespeichert oder übertragen werden. Die Maßnahmen zur Verschlüsselung bzw. zum Hashen der Passwörter sind zu dokumentieren. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2000.040 | C.2000.006 | Zugang zum internen Netzwerk ist über einen zentralen Authentisierungsmechanismus geregelt und der Zugriff auf IT-Systeme erfolgt nach dem aktuellen Stand der Technik ausgestalteten Mechanismus zur Authentisierung und Autorisierung eines Benutzers. | SBK 1 | 1. Der Zugang zum internen Netzwerk des Unternehmens ist über einen zentralen Authentisierungsmechanismus (z. B. Benutzername und Passwort) zu realisieren. | Artikel 21: Zugangskontrolle.d)., Artikel 21: Zugangskontrolle.f) i) | relevant | ||||||||
| R.2000.042 | C.2000.006 | Zugang zum internen Netzwerk ist über einen zentralen Authentisierungsmechanismus geregelt und der Zugriff auf IT-Systeme erfolgt nach dem aktuellen Stand der Technik ausgestalteten Mechanismus zur Authentisierung und Autorisierung eines Benutzers. | SBK 2 | 1. Es muss sichergestellt sein, dass der Zugriff auf eine Anwendung/IT-System ausschließlich über einen dokumentierten und nach dem aktuellen Stand der Technik ausgestalteten Mechanismus zur Authentisierung und Autorisierung eines Benutzers erfolgt (z. B. Benutzername und Passwort, Smartcard, Token). | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 21: Zugangskontrolle.d)., Artikel 21: Zugangskontrolle.f) i), Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | |||||||
| R.2000.047 | C.2000.007 | Regelungen zur Passwortaufbewahrung sowie Faktorenaufbewahrung bei der Verwendung von Multi-Faktor-Authentisierung Verfahren sind getroffen. | SBK 2 | 1. Wird ein Passwort dokumentiert ist sicherzustellen, dass das Passwort keinem Unberechtigten zur Kenntnis gelangt. Sollte es notwendig sein, ein Passwort schriftlich vorzuhalten, so ist dieses sicher vor unbefugtem Zugriff in einem verschlossenen Umschlag unzugänglich für nicht berechtigte Dritte zu lagern. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.048 | C.2000.007 | Regelungen zur Passwortaufbewahrung sowie Faktorenaufbewahrung bei der Verwendung von Multi-Faktor-Authentisierung Verfahren sind getroffen. | SBK 2 | 2. Bei der Nutzung einer Multi-Faktor-Authentisierung ist eine getrennte Aufbewahrung der beiden Faktoren (z. B. Passwort, Chipkarte, Token) sicherzustellen. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2000.066 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 1 | 1. Der Zugriff auf Anwendungen und IT-Systeme ist in folgenden Fällen mittels einer starken Authentifizierung abzusichern: a)\tZugriff von Benutzern mit privilegierten Berechtigungen, b)\tZugriffe auf Anwendungen und IT-Systeme, die kritische oder wichtige Funktionen unterstützen. | Artikel 09: Schutz und Prävention.(4) d). | Artikel 21: Zugangskontrolle.f) ii) | relevant | |||||||
| R.2000.052 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 2 | 1. Ein Benutzer muss nachvollziehen können, wann (Datum und Uhrzeit) die letzte Anmeldung mit seinem Benutzerkonto stattfand. | relevant | |||||||||
| R.2000.054 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 2 | 2. Bei fehlerhaften Anmeldungen darf es keinen Hinweis geben, welcher Teil der eingegebenen Anmeldedaten fehlerhaft ist. | relevant | |||||||||
| R.2000.055 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 2 | 3. Bei der Eingabe sind Authentifizierungsinformationen wie Passwörter, PIN etc. nicht im Klartext anzuzeigen. | relevant | |||||||||
| R.2000.064 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 2 | 4. Für Anwendungen und IT-Systeme ist risikoorientiert eine maximale Zeitspanne nach erfolgreicher Authentifizierung festzulegen, nach der ein Benutzer ohne Aktivität abgemeldet wird. Diese Zeitspanne darf bei Internetzahlungsdiensten maximal fünf Minuten betragen. | Artikel 13: Management der Netzwerksicherheit.l). | relevant | ||||||||
| R.2000.058 | C.2000.008 | Sichere Anmeldeverfahren sind etabliert. | SBK 4 | 1. Die Anmeldung an Anwendungen und IT-Systemen hat mittels einer starken Authentifizierung zu erfolgen, sofern die Anmeldung am Unternehmensnetzwerk nicht bereits über eine starke Authentifizierung erfolgt ist. | Artikel 09: Schutz und Prävention.(4) d). | relevant | ||||||||
| R.2000.060 | C.2000.009 | Es ist System zur Verwaltung von Kennwörtern etabliert. | SBK 2 | 1. Bei Anwendungen sind die Kennwörter getrennt von den Nutzdaten der Anwendung zu speichern, um den Zugriff auf diese Daten angemessen einzuschränken. | relevant | |||||||||
| 19 | R.2100 - Systemhärtung | |||||||||||||
| R.2100.001 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 1. IT-Systeme (z. B. Server, Arbeitsplatz-PCs, Mobile Endgeräte), die Informationen des Unternehmens verarbeiten oder speichern, sind vor produktiver Inbetriebnahme mindestens nach den folgenden Kriterien zu härten: a) Sämtliche Dienste, Hard- und Softwareschnittstellen, Protokolle bzw. Komponenten eines Betriebssystems und Softwareprogramme und -tools sind auf ihre Notwendigkeit hin zu überprüfen. Sie sind zu entfernen bzw. zu deaktivieren, sofern sie nicht zwingend für den Betrieb benötigt werden. Nach Stand der Technik unsichere Software muss durch sichere Varianten ersetzt werden. b) Schreibende Zugriffe der Standardbenutzer auf die Systempartitionen müssen unterbunden werden. c) Berechtigungen zur Änderung sicherheitsrelevanter Einstellungen sind auf Administratorkonten zu beschränken. | Artikel 09: Schutz und Prävention.(3) a)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 13: Management der Netzwerksicherheit.k). | relevant | |||||||
| R.2100.002 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 2. Bei netzwerkfähigen, papierverarbeitenden Geräten wie Drucker, Scanner, Fax-Geräte und Multifunktionsgeräte (Druck-, Fax-, Kopier- und Scanner-Funktion in einem Gerät) sind ergänzend die Schnittstellen, administrative Zugriffsprotokolle, Fileservices und temporäre Ablagen zu deaktivieren bzw. wenn diese notwendig sind, so abzusichern, dass unberechtigte Dritte keinen Zugriff darauf erhalten. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.2100.003 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 3. Die Härtungsmaßnahmen sind nachvollziehbar zu dokumentieren. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.2100.011 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 4. Für mindestens folgende IT-Systeme muss jeweils eine „Secure Configuration Baseline“ erstellt werden: a) Zentrale Verzeichnisdienste b) Server c) Datenbanksysteme d) Office Produkte e) Mainframe f) Arbeitsplatz-PCs g) Notebooks h) Mobile Endgeräte i) Managebare Netzwerkkomponenten j) Virtualisierungssysteme k) Cloud-Instanzen l) Browser Dafür muss das „Secure Configuration Baseline Template“ verwendet werden. | relevant | |||||||||
| R.2100.012 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 5. Für mindestens folgende IT-Systeme ist die jeweilige Secure Configuration Baseline in Betrieb und Entwicklung anzuwenden. a) Zentrale Verzeichnisdienste b) Server c) Datenbanksysteme d) Office Produkte e) Mainframe f) Arbeitsplatz-PCs g) Notebooks h) Mobile Endgeräte i) Virtualisierungssysteme j) Cloud-Instanzen k) \tBrowser | relevant | |||||||||
| R.2100.013 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 1 | 6. Für Betriebssysteme müssen journaling-fähige Dateisysteme verwendet werden. | relevant | |||||||||
| R.2100.004 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 1. Alle nicht benötigten, vom Hersteller vorgegebenen Benutzer müssen entfernt werden. Sofern ein Löschen nicht möglich ist, sind diese zu deaktivieren. | Artikel 09: Schutz und Prävention.(3) a). | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | |||||||
| R.2100.014 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 2. Die Zugriffsrechte aller vom Hersteller vorgegebenen Benutzer - insbesondere der technischen Benutzerkonten, unter deren Namen Dienste aktiv sind - sind auf das tatsächlich notwendige Maß im Rahmen der dienstlichen Notwendigkeit zu minimieren (Need-to-Know, Need-to-Use, Least Privilige). | Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 21: Zugangskontrolle.a). | relevant | ||||||||
| R.2100.015 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 3. Sicherheitsempfehlungen der Hersteller müssen geprüft und risikoorientiert umgesetzt werden. | Artikel 11: Daten- und Systemsicherheit (2) k) a) | relevant | ||||||||
| R.2100.016 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 4. Zur Härtung von IT-Systemen müssen dem Stand der Technik entsprechende und etablierte Standards herangezogen, geprüft und risikoorientiert umgesetzt werden. Als Stand der Technik sollten die CIS-Benchmarks herangezogen. Abweichungen hiervon sind mit dem Schwachstellenmanagement abzustimmen und zu dokumentieren | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 11: Daten- und Systemsicherheit (2) b). | relevant | |||||||
| R.2100.017 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 5. Durch regelmäßige Überprüfungen ist sicherzustellen, dass die definierten Härtungsmaßnahmen effektiv umgesetzt sind. | Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 11: Daten- und Systemsicherheit (2) b). | relevant | |||||||
| R.2100.005 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 6. Geräte mit Diagnose- und Konfigurationsports (z. B. Managementport bei aktiven Netzwerkkomponenten) sind gegen einen unberechtigten Zugang abzusichern. | Artikel 09: Schutz und Prävention.(3) a). | relevant | ||||||||
| R.2100.006 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 7. Die Nutzung von durch den Hersteller/Anbieter vorinstallierten Admin-Accounts (Administrator, root, etc.) darf nicht direkt beim Login an einem System möglich sein (z. B. direkter root-login), sondern muss in Form eines Benutzerwechsels (z. B. sudo bzw. runas) nach einer erfolgreichen personalisierten Anmeldung am Zielsystem erfolgen. | relevant | |||||||||
| R.2100.018 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 8. Administratoren des Betriebssystems dürfen nicht automatisch auch Anwendungen und Middleware wie z. B. Datenbanken administrieren können. Wenn dies technisch nicht möglich ist, muss dies organisatorisch verboten werden. | relevant | |||||||||
| R.2100.020 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 2 | 9. Zur Härtung von KI-Systemen müssen zusätzliche dem Stand der Technik entsprechende und etablierte Standards herangezogen, geprüft und risikoorientiert umgesetzt werden, falls diese nicht bereits in den Standards für non-AI-Systeme berücksichtigt sind (z.B. „Test Criteria Catalogue for AI-Systems in Finance“ des BSI)." | KI-Systeme | relevant | ||||||||
| R.2100.009 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 3 | 1. IT-Systeme, die über einen Webservice erreichbar sind, dürfen über diesen keine Informationen über die verwendeten IT-Systeme und Softwarekomponenten geben (z. B. über phpinfo, status.cgi, stacktraces). | relevant | |||||||||
| R.2100.010 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 3 | 2. Verwendete Dienste sind so zu konfigurieren, dass Zusatzinformationen, die nicht für betriebliche Zwecke erforderlich sind (z. B. über Versionsstände, Hardware, Software), nicht über die Dienste ausgelesen werden können. | relevant | |||||||||
| R.2100.019 | C.2100.001 | IT-Systeme werden angemessen gehärtet. Dafür wird ein anerkannter Standard nach Stand der Technik risikoorientiert angewendet. Für diese Zwecke der Härtung wird eine Secure Configuration Baseline erstellt. Die effektive Umsetzung der definierten Härtungsmaßnahmen wird regelmäßig überprüft. | SBK 3 | 3. Alle nicht benötigten Netzwerkadapter müssen physisch entfernt werden. Sofern ein Entfernen nicht möglich ist, müssen diese deaktiviert werden. | relevant | |||||||||
| 20 | R.2200 - Netzwerk- und Systemmanagement | |||||||||||||
| R.2200.001 | C.2200.001 | Der netzwerktechnische Zugang zu Netzwerken und Netzwerkdiensten ist geschützt. | SBK 1 | 1. Es sind dokumentierte Prozesse zu implementieren, die eine kontrollierte Benutzung der Netzwerkdienste (physisch und logisch) umfassen und die für den Benutzer verfügbaren Netzwerkdienste vollständig dokumentieren. Dazu gehört mindestens: a) Die jeweiligen im internen Netzwerk verwendeten Authentisierungsverfahren sind aufzuführen; b) Jede Nutzung von Netzen und Netzwerkdiensten muss an eine Autorisierung gebunden sein; c) Eine kontrollierte Beschränkung der Nutzung von Netzwerkdiensten, z. B. durch Einsatz eines Proxies für den Zugriff auf Internetdienste muss vorhanden sein. d) Es dürfen nur solche Autorisierungen vergeben werden, die im Rahmen der dokumentierten Prozesse tatsächlich benötigt werden (Need-to-Know, Need-to-Use, Least Privilege need-to-know Prinzip). e) Netzwerkpläne müssen vorhanden sein. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.l) i), Artikel 13: Management der Netzwerksicherheit.b)., Artikel 13: Management der Netzwerksicherheit.d)., Artikel 13: Management der Netzwerksicherheit.f)., Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.002 | C.2200.001 | Der netzwerktechnische Zugang zu Netzwerken und Netzwerkdiensten ist geschützt. | SBK 1 | 2. Anforderungen bei Verbindungen aus öffentlichen Netzen zu internen Netzen: a) Der Zugang über ein Benutzerkonto, das von mehreren Benutzern genutzt wird, ist aus öffentlichen Netzen nicht zugelassen. b) Die Netzverbindung zwischen externen und internen Systemen darf erst nach erfolgter Zugangskontrolle mittels starker Authentifizierung erfolgen. c) Es ist eine erneute Authentisierung, analog zur Bildschirmsperre, vom Benutzer durchzuführen, wenn während einer Sitzung über einen definierten Zeitraum keine Ein- bzw. Ausgaben stattgefunden haben. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.l)., Artikel 13: Management der Netzwerksicherheit.d)., Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.003 | C.2200.001 | Der netzwerktechnische Zugang zu Netzwerken und Netzwerkdiensten ist geschützt. | SBK 2 | 1. Der Zugang zum Netzwerk ist mittels einer Netzzugangskontrolle (z. B. Network Access Control (NAC)) zu realisieren, die den Zugang/Zugriff von unautorisierten Geräten oder von Geräten, die nicht den Sicherheitsanforderungen entsprechen, auf Ressourcen des Unternehmens erkennt und verhindert. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.d)., Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.004 | C.2200.001 | Der netzwerktechnische Zugang zu Netzwerken und Netzwerkdiensten ist geschützt. | SBK 2 | 2. Die Zugriffe auf Netzwerke und Netzwerkdienste müssen protokolliert und fortlaufend nach Anomalien/Angriffsszenarien ausgewertet werden. | Artikel 08: Identifizierung (2)., Artikel 09: Schutz und Prävention.(4) b)., Artikel 10: Erkennung.(1). | Artikel 13: Management der Netzwerksicherheit.d)., Artikel 13: Management der Netzwerksicherheit.g)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b). | nicht relevant | |||||||
| R.2200.050 | C.2200.001 | Der netzwerktechnische Zugang zu Netzwerken und Netzwerkdiensten ist geschützt. | SBK 4 | 1. Der Zugang zu Ressourcen im Netzwerk des Unternehmens muss mittels zertifikatsbasierter Authentifizierungsverfahren (z. B. 802.1X) realisiert werden, außer die Netzwerke befinden sich in besonders gesicherten Räumen. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.007 | C.2200.002 | Der Fernzugang zu Unternehmensressourcen (Remote Access) ist durch zusätzliche Maßnahmen vor unautorisiertem Zugang zum Unternehmensnetzwerk geschützt. | SBK 1 | 1. Fernzugriffe dürfen nur für die folgenden Anwendungsgebiete zum Einsatz kommen: a) Telearbeitsplätze (Zugriff auf Endanwendungen durch eigene Mitarbeiter oder Dritte), b) mobile Arbeitsplätze (z. B. Home Office) und c) Fernwartung/-administration einzelner dedizierter Systeme (z. B. TK-Anlage) durch eigene Mitarbeiter oder Dritte. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.008 | C.2200.002 | Der Fernzugang zu Unternehmensressourcen (Remote Access) ist durch zusätzliche Maßnahmen vor unautorisiertem Zugang zum Unternehmensnetzwerk geschützt. | SBK 1 | 2. Bei der Verwendung von Fernzugängen sind mindestens die folgenden Aspekte zu regeln: a) Festlegung der erlaubten Zugriffe/Berechtigungen für die Nutzung der technischen Lösung für Fernzugänge inkl. Nutzung von starker Authentisierungsmaßnahmen; b) Einrichtung eines Prozesses zur Genehmigung von Remote-Zugängen; c) Dokumentation der Remote-Zugänge und Berechtigungen für Remote-Zugriffe auf Daten; d) Sicherungsmaßnahmen zum Schutz der Remote-Verbindungen (z. B. durch VPN). | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 12: Datenaufzeichnung (2) d)., Artikel 13: Management der Netzwerksicherheit.g)., Artikel 21: Zugangskontrolle.f) ii) | nicht relevant | |||||||
| R.2200.011 | C.2200.002 | Der Fernzugang zu Unternehmensressourcen (Remote Access) ist durch zusätzliche Maßnahmen vor unautorisiertem Zugang zum Unternehmensnetzwerk geschützt. | SBK 1 | 3. Die Freischaltung des Zuganges für einen Fernwartungsdienstleister (Fremdadministrator) ist nur anlassbezogen und hat nur über die tatsächliche Nutzungsdauer zu erfolgen. Die übertragenen Daten und durchgeführten Tätigkeiten sind zu dokumentieren. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.013 | C.2200.002 | Der Fernzugang zu Unternehmensressourcen (Remote Access) ist durch zusätzliche Maßnahmen vor unautorisiertem Zugang zum Unternehmensnetzwerk geschützt. | SBK 1 | 4. Werden Wählverbindungen aufgrund betrieblicher Notwendigkeiten eingesetzt, sind die notwendigen Dial-Out- bzw. Dial-In-Systeme in die Firewall-Umgebung zu integrieren. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.015 | C.2200.002 | Der Fernzugang zu Unternehmensressourcen (Remote Access) ist durch zusätzliche Maßnahmen vor unautorisiertem Zugang zum Unternehmensnetzwerk geschützt. | SBK 1 | 5. Bei eingehenden Verbindungen sind die notwendigen Einwahlsysteme (z. B. VPN-Gateway und/oder Einwahl-Router für klassische Wählverbindungen) in einer separaten Sicherheitszone der Firewall (DMZ) zu positionieren. Die Verbindungen und Verbindungsversuche sind zu kontrollieren, zu protokollieren und auszuwerten. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.g). | nicht relevant | |||||||
| R.2200.019 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 1. Es sind Rollen und Verantwortlichkeiten für das operative Netzwerk- und das Netzwerksicherheitsmanagement zu definieren. | Artikel 09: Schutz und Prävention.(4) b). | nicht relevant | ||||||||
| R.2200.020 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 2. Über drahtlose Netzwerke übertragenen Daten sind mittels kryptographischer Techniken abzusichern. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 12: Datenaufzeichnung (2) d)., Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | nicht relevant | |||||||
| R.2200.021 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 3. Verbindungen zu/aus dem internen Netzwerk aus/zu externen Netzwerken müssen auf ein notwendiges Minimum eingeschränkt werden. | Artikel 09: Schutz und Prävention.(4) b). | nicht relevant | ||||||||
| R.2200.022 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 4. Es ist eine Dokumentation, erstellen, die mindestens folgende Punkte beinhaltet: a) IP-Adresskonzept inkl. Anforderungen zum Einsatz von Internet Protokollversionen. Unter anderem sind bei der ausschließlichen Verwendung von IPv4, die technischen Parameter für die Verhinderung von Verbindungen über IPv6 zu benennen. b) DNS-Konzept, das die Nutzung von getrennten internen und externen DNS Servern berücksichtigt. c) Dokumentation der Netzwerkverbindungen. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.b). | nicht relevant | |||||||
| R.2200.058 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 5. Die bestehenden Datenflüsse sind zu dokumentieren. | Artikel 09: Schutz und Prävention.(4) b). | Artikel 13: Management der Netzwerksicherheit.b). | nicht relevant | |||||||
| R.2200.052 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 1 | 6. Das Netzwerkdesign muss nach dem Stand der Technik zur Sicherstellung der Schutzziele ausgestaltet sein. Die Netzwerkarchitektur und das Sicherheitsdesign der Netze sind jährlich zu überprüfen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 09: Schutz und Prävention.(4) b)., Artikel 13: Lernprozesse und Weiterentwicklungen (7)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 13: Management der Netzwerksicherheit.f)., Artikel 13: Management der Netzwerksicherheit.i). | nicht relevant | |||||||
| R.2200.023 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 2 | 1. Die Datenübertragung über öffentliche Netzwerke ist kryptographisch abzusichern, z. B. durch den Einsatz von Virtual Private Networks (VPN). Tunnel-Technologien müssen in Firewall-Umgebungen (Firewall oder DMZ) terminieren. Die für den betrieblichen Zweck benötigten und freigegebenen Verbindungen zum öffentlichen Netz müssen nachvollziehbar und fortlaufend dokumentiert werden. Hierbei sind mindestens die folgende Aspekte zu berücksichtigen: a) Die betriebliche Notwendigkeit der Verbindung; b) Die existierenden Filterregeln (Minimalprinzip); c) Die zur Kopplung eingesetzte Technologie inkl. aller notwendigen Konfigurationsparameter; d) Mechanismen zur Authentifizierung der Kommunikationspartner. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) c)., Artikel 12: Datenaufzeichnung (2) d)., Artikel 13: Management der Netzwerksicherheit.e)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) a)., Artikel 14: Sicherung von Informationen bei der Übermittlung (1) b). | nicht relevant | |||||||
| R.2200.027 | C.2200.003 | Der Betrieb der Netzwerke erfolgt sicher und geregelt. Die Anzahl der Verbindungen vom Netzwerk nach außerhalb sind auf ein Minimum reduziert. Datenübertragungen über öffentliche Netze erfolgen nur verschlüsselt. | SBK 2 | 1. Zur frühzeitigen Erkennung von Security Events und Incidents müssen IT-Systeme und Netzsegment auf sicherheitsrelevante Ereignisse überwacht werden. Alle Systeme zur Überwachung sicherheitsrelevanter Ereignisse müssen in ein SIEM eingebunden werden. Der Überwachungs- und Erkennungsprozess muss dabei automatisiert erfolgen. Aktuelle Indikatoren aus externen Quellen müssen berücksichtigt werden. Zielsetzung ist die Minimierung von möglichen Schäden, die durch einen Angriff auf ein IT-System entstehen können. | Artikel 09: Schutz und Prävention.(1)., Artikel 09: Schutz und Prävention., Artikel 10: Erkennung.(1)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) a). | Artikel 03: IKT-Risikomanagement.e) iii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) iii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) d). | nicht relevant | |||||||
| R.2200.029 | C.2200.004 | Die Nutzung der Netzwerke wird überwacht, um sicherheitsrelevante Auffälligkeiten zu entdecken.. Erhöhte Schutzmaßnahmen für Systeme, die direkt aus dem Internet erreichbar sind inkl. dem Internetauftritt sind definiert und umgesetzt. | SBK 2 | 2. Der Internetaufritt, aus dem Internet erreichbare Anwendungen und Services und Verbindungen zu externen Partnern/Kunden oder zum Internet müssen durch mehrstufige Firewall-Architekturen abgesichert werden. Dabei sind folgende Anforderungen zu erfüllen: a) Anomalien im Netzverkehr müssen erkannt und ausgefiltert werden. Dabei sind sämtliche Verbindungen über Firewalls so zu überwachen und auszuwerten, dass Angriffe erkannt und nachverfolgt werden können, etwa durch die Auswertung von Protokolldaten, Alarmierungsregeln für ungewöhnliche Verbindungsversuche oder die Verwendung von Intrusion-Detection-Systemen. b) Zur Erkennung von Anomalien und Abwehr von Angriffen sind an Netzwerkübergängen ergänzende Schutzmaßnahmen zu implementieren (z. B. IDS/IPS-Systeme, Maßnahmen zur Mitigation von Distributed Denial of Service (DDoS) Attacken bzw. vergleichbare Technologien). Hierbei sind mindestens die folgenden Aspekte zu regeln: - Kriterien für die Ausgestaltung der Schutzmaßnahme (Einsatzszenario), - Einsatz von Techniken und Methoden zur Eindämmung - Prüfung auf Aktualisierung der Pattern, - Zeitnahe Aktualisierung der Versionsstände, - Risikoorientierte Anpassung der Regelwerke unter Berücksichtigung der Bedrohungslage - Einrichtung starker Authentisierungsmaßnahmen. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 10: Erkennung.(1)., Artikel 10: Erkennung.(2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (3) a). | Artikel 13: Management der Netzwerksicherheit.j)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b). | nicht relevant | |||||||
| R.2200.033 | C.2200.005 | Firewalls werden gezielt an Übergangsstellen von Netzwerken eingesetzt, um den Netzwerkverkehr zu steuern und zu regeln. | SBK 2 | 1. Beim Einsatz von Firewalls (einschließlich gleichartig verwendeter IP basierter Verbindungsfilter in Netzwerkkomponenten) sind mindestens die folgenden Anforderungen zu erfüllen: a) Die grundsätzliche Einstellung der Firewall ist die Sperrung des Verbindungsaufbaus („deny all“ bzw. Whitelisting), soweit die jeweilige Verbindung nicht aus betrieblichen Gründen erforderlich und ausdrücklich zugelassen ist. Hierzu muss ein Freigabeprozess definiert werden, dessen Ergebnisse dokumentiert werden müssen. b) Die Ausgestaltung der Firewall (z. B. Typ der Firewall, ein- oder mehrstufige Architektur der Firewallsysteme, Redundanz der Systeme) muss sich nach dem jeweiligen Zweck und den abgesicherten Netzbereichen richten. Beim Design der Installation ist eine entsprechende Risikoabwägung durchzuführen. Soweit nicht abdeckbare Restrisiken bestehen, sind diese im Rahmen des Risikomanagements zu steuern. Die Ergebnisse sind mit dem CISO abzustimmen. c) Ein Ausfall von Firewallkomponenten darf nicht dazu führen, dass unerwünschte Verbindungen zugelassen werden. d) Die Regelbasis ist regelmäßig auf Aktualität, Vollständigkeit und betriebliche Notwendigkeit zu überprüfen. Bei Firewallregeln für für IT-Systeme, die kritische/wichtige Funktionen unterstützen, ist die Überprüfung mindestens alle sechs Monate durchzuführen. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.g)., Artikel 13: Management der Netzwerksicherheit.h). | nicht relevant | |||||||
| R.2200.054 | C.2200.005 | Firewalls werden gezielt an Übergangsstellen von Netzwerken eingesetzt, um den Netzwerkverkehr zu steuern und zu regeln. | SBK 2 | 2. Das Vortäuschen (Spoofing) von Netzwerkbasisdiensten im LAN-Verbund MUSS durch geeignete technische Sicherheitsmaßnahmen verhindert werden. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.g)., Artikel 13: Management der Netzwerksicherheit.h). | nicht relevant | |||||||
| R.2200.036 | C.2200.006 | Nur gezielt ausgewählte Netzwerkdienste werden eingesetzt, die regelmäßig überprüft werden. | SBK 1 | 1. Für eingesetzte Netzwerkdienste müssen Sicherheitsmaßnahmen, Dienstgüte und Anforderungen an das Dienstemanagement definiert, dokumentiert und regelmäßig überprüft werden. Dies betrifft sowohl Netzwerkbasisdienste wie DNS, DHCP, Printservices oder Verzeichnisdienste als auch erweiterte Dienste wie Bandbreitendienste, Managed-Network-Sicherheitslösungen etc. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.l) i), Artikel 13: Management der Netzwerksicherheit.l) ii) | nicht relevant | |||||||
| R.2200.044 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 1 | 1. Das Netzwerk muss in separate Netzwerkdomänen (i.d.R. unterschiedliche IP-Adressbereiche) aufgeteilt werden. Die Vorgehensweise und die Kriterien zur Trennung (z. B. anhand von Schutzbedarfen, nach Organisationseinheiten oder einer Kombination daraus, physisch und/oder logisch) müssen vom operativen Netzwerk- bzw. Netzwerksicherheitsmanagement verantwortet, konzipiert, dokumentiert und umgesetzt werden. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii), Artikel 13: Management der Netzwerksicherheit.c). | nicht relevant | |||||||
| R.2200.045 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 1 | 2. Drahtlos-Netzwerke müssen von den internen Netzwerken getrennt werden. Der Zugang zu internen Systemen darf erst gewährt werden, wenn ein Gateway zur Kontrolle des Netzwerkverkehrs passiert wurde. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii) | nicht relevant | |||||||
| R.2200.053 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 1 | 3. Die Infrastruktur für Netzanbindung und Netzwerkverbindung muss so konzipiert sein, dass diese unmittelbar im Falle eines Cyber-Angriffs getrennt oder segmentiert werden kann. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention., Artikel 11: Reaktion und Wiederherstellung (2) c). | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii) | nicht relevant | |||||||
| R.2200.046 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 2 | 1. Netzübergänge zu vertrauenswürdigen und nicht vertrauenswürdigen anderen Netzen sind mit Firewallsystemen abzusichern. | Artikel 09: Schutz und Prävention.(4) b)., Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii) | nicht relevant | |||||||
| R.2200.047 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 2 | 2. Der Bereich der einzelnen Netzwerkdomänen muss genau definiert und dokumentiert werden. Die Administration der IT-Systeme darf nur aus einem dafür vorgesehenen und freigegebenen Administrationsnetz erfolgen. Für den Zugang von einer Netzwerkdomäne zu einer anderen ist zu definieren wie er technisch ausgestaltet ist und welche Trennungsgebote zwischen den konkreten Netzwerkdomänen gelten sollen. | Artikel 09: Schutz und Prävention., Artikel 09: Schutz und Prävention.(4) d). | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii) | nicht relevant | |||||||
| R.2200.049 | C.2200.007 | Unterschiedliche Netzwerksegmente sind definiert und umgesetzt. Die Übergänge zwischen den Netzwerksegmenten werden über Regeln gesteuert. | SBK 4 | 1. IT-Systeme dieser Schutzbedarfsklasse müssen in einer eigenen, mindestens logisch separierten Netzwerkdomäne beinhaltet sein, für die angemessene Sicherheitsmechanismen implementiert werden muss. | Artikel 09: Schutz und Prävention. | Artikel 13: Management der Netzwerksicherheit.a)., Artikel 13: Management der Netzwerksicherheit.a) i), Artikel 13: Management der Netzwerksicherheit.a) ii), Artikel 13: Management der Netzwerksicherheit.a) iii) | nicht relevant | |||||||
| 21 | R.2300 - Protokollierung und Überwachung | |||||||||||||
| R.2300.001 | C.2300.001 | Angaben zu erfolgenden Protokollierungen von IT-Systemen und Anwendungen in Bezug auf den Umfang, Berechtigungen auf Zugriff, Ablage sowie Auswertungen sind durch die Asset-Verantwortlichen nachvollziehbar dokumentiert und erfolgen gemäß den gesetzlichen Anforderungen. | SBK 1 | 1. Im Sicherheitskonzept der IT-Systeme und Anwendungen müssen alle Aspekte zur Umsetzung der nachfolgenden Vorgaben zur Protokollierung und Auswertung dokumentiert werden. Dabei sind mindestens die folgenden Anforderungen zu berücksichtigen: a) Was wird zu welchem Zweck protokolliert? b) Wer hat die Berechtigung, die Protokolleinstellungen zu verändern? c) Wo und wie werden die Protokolldaten auf den jeweiligen IT-Systemen abgelegt? d) Wer hat Zugriff auf die erstellten Protokolldaten und wie sind diese vor unbefugter Veränderung geschützt? e) Wie lange werden die Protokolldaten unter Berücksichtigung der gesetzlichen Anforderungen aufbewahrt? f) Wie und in welchen Intervallen erfolgt eine regelmäßige Auswertung? | Artikel 09: Schutz und Prävention.(1)., Artikel 10: Erkennung.(1). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) iii), Artikel 12: Datenaufzeichnung (2) a)., Artikel 12: Datenaufzeichnung (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | |||||||
| R.2300.002 | C.2300.001 | Angaben zu erfolgenden Protokollierungen von IT-Systemen und Anwendungen in Bezug auf den Umfang, Berechtigungen auf Zugriff, Ablage sowie Auswertungen sind durch die Asset-Verantwortlichen nachvollziehbar dokumentiert und erfolgen gemäß den gesetzlichen Anforderungen. | SBK 1 | 2. Es muss sichergestellt werden, dass nur Informationen erhoben, gespeichert und ausgewertet werden, die aus gesetzlicher oder aufsichtsrechtlicher Sicht zulässig sind. | Artikel 09: Schutz und Prävention.(1). | Artikel 12: Datenaufzeichnung (2) a)., Artikel 12: Datenaufzeichnung (2) b). | nicht relevant | |||||||
| R.2300.003 | C.2300.001 | Angaben zu erfolgenden Protokollierungen von IT-Systemen und Anwendungen in Bezug auf den Umfang, Berechtigungen auf Zugriff, Ablage sowie Auswertungen sind durch die Asset-Verantwortlichen nachvollziehbar dokumentiert und erfolgen gemäß den gesetzlichen Anforderungen. | SBK 1 | 3. Zur Einhaltung der Mitbestimmungspflichten und Datenschutzaspekte müssen Art und Umfang der Protokollierung mit dem Datenschutzbeauftragten, dem Bereich Personal sowie mit der zuständigen Arbeitnehmervertretung (Personalrat) abgestimmt werden, sofern personenbezogene Daten gem. Datenschutzrecht hiervon oder durch die Arbeitnehmervertretung mitbestimmungspflichtige Sachverhalte betroffen sind. | Artikel 09: Schutz und Prävention.(1). | Artikel 12: Datenaufzeichnung (2) a)., Artikel 12: Datenaufzeichnung (2) b). | nicht relevant | |||||||
| R.2300.007 | C.2300.002 | Ausreichende Protokollierungen und Ereignisse auf Betriebssystemebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 1 | 1. Sofern Zugriffe auf Betriebssystemressourcen und Daten über Anmeldeverfahren abgesichert werden, sind mindestens folgende Ereignisse zu protokollieren: a) Fehlerhafte Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Deaktivierung/Sperrung von Konten aufgrund von fehlerhaften Eingaben von Anmeldedaten | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.008 | C.2300.002 | Ausreichende Protokollierungen und Ereignisse auf Betriebssystemebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 2 | 1. Mindestens folgende Aktivitäten auf Betriebssystemebene sind zu protokollieren: a) Erfolgreiche Anmeldung von Benutzern inkl. Benutzerkennung, Datum und Uhrzeit b) Trennung von Sitzungen bzw. Abmeldungen des Benutzers c) Aktivierung und Deaktivierung von Systemdiensten/Sicherheitsfunktionen d) Herunterfahren/Neustart des Systems e) Aktivierung/Deaktivierung der Protokollierung f) Vergabe und Änderungen von Berechtigungen | Artikel 09: Schutz und Prävention.(1). | Artikel 12: Datenaufzeichnung (2) b). | nicht relevant | |||||||
| R.2300.009 | C.2300.002 | Ausreichende Protokollierungen und Ereignisse auf Betriebssystemebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 1. Mindestens folgende Systemereignisse sind zu protokollieren: a) Erfolgreiche/Fehlerhafte Zugriffe auf die Sicherheitseinstellungen b) Erfolgreiche/Fehlerhafte Zugriffe auf die Benutzerverwaltung. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.010 | C.2300.002 | Ausreichende Protokollierungen und Ereignisse auf Betriebssystemebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 2. Die Ereignisse innerhalb des Protokolls muss Informationen beinhalten, welche Rückschlüsse auf das genutzte Endgerät und die Fehlerursache ermöglichen sowie forensische Analyse sicherheitsrelevanter Ereignisse unterstützt. Dazu gehören z. B. Netzwerkadresse, Gerätekennung, detaillierte Fehlerursachen, Datum und Uhrzeit . | Artikel 09: Schutz und Prävention.(1). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) c). | nicht relevant | |||||||
| R.2300.015 | C.2300.003 | Ausreichende Protokollierungen auf Anwendungsebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 1. Mindestens folgende Aktivitäten auf Anwendungsebene sind zu protokollieren: a) Erfolgreiche Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Trennung von Sitzungen bzw. Abmeldungen des Benutzers c) Beenden/Neustart der Anwendung d) Aktivierung/Deaktivierung der Protokollierung | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.016 | C.2300.003 | Ausreichende Protokollierungen auf Anwendungsebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 4 | 1. Mindestens folgende Ereignisse sind zu protokollieren: a) Erfolgreiche/Fehlerhafte Zugriffe auf die Sicherheitseinstellungen b) Erfolgreiche/Fehlerhafte Zugriffe auf die Benutzer- und Rechteverwaltung. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.017 | C.2300.003 | Ausreichende Protokollierungen auf Anwendungsebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 2. Die Ereignisse innerhalb des Protokolls müssen Informationen beinhalten, welche Rückschlüsse auf das genutzte Endgerät erlauben, die Analyse der Fehlerursache ermöglichen und eine forensische Analyse sicherheitsrelevanter Ereignisse im Sinne des Security Incident Managements unterstützen. Dazu gehören z. B. Netzwerkadresse, Gerätekennung, detaillierte Fehlerursachen, Datum und Uhrzeit . | Artikel 09: Schutz und Prävention.(1). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) c). | nicht relevant | |||||||
| R.2300.020 | C.2300.004 | Ausreichende Protokollierungen auf Middlewareebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 1 | 1. Sofern Zugriffe auf Middleware über Anmeldeverfahren abgesichert werden sind mindestens folgende Ereignisse zu protokollieren: a) Fehlerhafte Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Deaktivierung/Sperrung von Konten aufgrund von fehlerhaften Eingaben von Anmeldedaten | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.021 | C.2300.004 | Ausreichende Protokollierungen auf Middlewareebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 1 | 2. Erfolgt die Protokollierung von Ereignissen bereits auf Betriebssystemebene, ist eine zusätzliche Protokollierung auf Middlewareebene nicht notwendig. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.022 | C.2300.004 | Ausreichende Protokollierungen auf Middlewareebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 2 | 1. Mindestens folgende Aktivitäten auf Middlewareebene sind zu protokollieren: a) Erfolgreiche Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Trennung von Sitzungen bzw. Abmeldungen des Benutzers c) Beenden/Neustart der Middleware d) Aktivierung/Deaktivierung der Protokollierung | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.023 | C.2300.004 | Ausreichende Protokollierungen auf Middlewareebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 1. Mindestens folgende Ereignisse sind zu protokollieren: a) Erfolgreiche/Fehlerhafte Zugriffe auf die Sicherheitseinstellungen b) Erfolgreiche/Fehlerhafte Zugriffe auf die Benutzer- und Rechteverwaltung. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.024 | C.2300.004 | Ausreichende Protokollierungen auf Middlewareebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 2. Die Ereignisse innerhalb des Protokolls müssen Informationen beinhalten, welche Rückschlüsse auf das genutzte Endgerät und die Fehlerursache ermöglichen und eine forensische Analyse sicherheitsrelevanter Ereignisse unterstützen. Dazu gehören z. B. Netzwerkadresse, Gerätekennung, detaillierte Fehlerursachen, Datum und Uhrzeit. | Artikel 09: Schutz und Prävention.(1). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) c). | nicht relevant | |||||||
| R.2300.027 | C.2300.005 | Ausreichende Protokollierungen auf Datenbankebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 1 | 1. Sofern Zugriffe auf Datenbanken und -speicher über Anmeldeverfahren abgesichert werden sind mindestens folgende Ereignisse zu protokollieren: a) Fehlerhafte Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Deaktivierung/Sperrung von Konten aufgrund von fehlerhaften Eingaben von Anmeldedaten | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.029 | C.2300.005 | Ausreichende Protokollierungen auf Datenbankebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 2 | 1. Mindestens folgende Aktivitäten auf Datenbankebene sind zu protokollieren: a) Erfolgreiche Anmeldung eines Benutzers inkl. Benutzerkennung, Datum und Uhrzeit b) Beenden/Neustart der Datenbank c) Aktivierung/Deaktivierung der Protokollierung auf Datenbankebene | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.030 | C.2300.005 | Ausreichende Protokollierungen auf Datenbankebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 1. Mindestens folgende Ereignisse sind zu protokollieren: a) Erfolgreiche/Fehlerhafte Zugriffe auf die Sicherheitseinstellungen b) Erfolgreiche/Fehlerhafte Zugriffe auf die Benutzer- und Rechteverwaltung. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.031 | C.2300.005 | Ausreichende Protokollierungen auf Datenbankebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 2. Mindestens ändernde und schreibende Zugriffe auf kritische Tabellen in Datenbanken sind zu protokollieren. Dazu gehören mindestens Zugriffe auf: a) Tabellen mit Benutzerdaten b) Tabellen mit Passwörtern c) sicherheitskritische Konfigurationstabellen | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.032 | C.2300.005 | Ausreichende Protokollierungen auf Datenbankebene als Basis für das Sicherheitsmonitoring werden erzeugt. | SBK 3 | 3. Die Ereignisse innerhalb des Protokolls müssen Informationen beinhalten, welche die Ermittlung der Fehlerursache und eine forensische Analyse sicherheitsrelevanter Ereignisse unterstützen. | Artikel 09: Schutz und Prävention.(1). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (4) c). | nicht relevant | |||||||
| R.2300.037 | C.2300.006 | Im Online Zahlungsverkehr werden zusätzliche Protokolldaten für die Nachvollziehbarkeit von Transaktionen erhoben. | SBK 3 | 1. Für Anwendungen des elektronischen Zahlungsverkehrs ist unabhängig vom Schutzbedarf neben den Sicherheitsvorgaben zur Protokollierung allgemeiner sicherheitsrelevanter Ereignisse auf Anwendungsebene die Protokollierung mindestens folgender spezifischer Ereignisse sicherzustellen: a) Zugriffe auf Daten zu Transaktionen und elektronischen Einzugsermächtigungen. b) Protokollierung von Transaktionen und elektronischen Einzugsermächtigungen, einschließlich fortlaufender Transaktionsnummern, Zeitstempel für Transaktionsdaten, Parameteränderungen. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.038 | C.2300.006 | Im Online Zahlungsverkehr werden zusätzliche Protokolldaten für die Nachvollziehbarkeit von Transaktionen erhoben. | SBK 3 | 2. Auf Basis der Protokollierung muss eine Rückverfolgung für mindestens folgende Fälle gewährleistet sein: a) Transaktionen sowie der Prozessablauf elektronischer Einzugsermächtigungen. b) Jegliche Ergänzung, Änderung oder Löschung von Daten zu Transaktionen und elektronischen Einzugsermächtigungen. | Artikel 09: Schutz und Prävention.(1). | nicht relevant | ||||||||
| R.2300.041 | C.2300.007 | Ausreichende Protokollierungen auf Netzwerkebene als Basis für das Sicherheitsmonitoring werden erzeugt | SBK 2 | 1. Sicherheitsgateways müssen mindestens folgende Ereignisse in Bezug auf den Netzverkehr protokollieren: a) Verbindungversuche, die gegen die Filterregeln verstoßen und abgewiesen wurden. | Artikel 09: Schutz und Prävention.(1). | Artikel 12: Datenaufzeichnung (2) c) v) | nicht relevant | |||||||
| R.2300.042 | C.2300.007 | Ausreichende Protokollierungen auf Netzwerkebene als Basis für das Sicherheitsmonitoring werden erzeugt | SBK 2 | 2. Sicherheitsgateways, welche an einem Netzübergang Einwahl- oder VPN-basierte oder ähnliche Zugangsmöglichkeiten in einen gesicherten Netzwerkbereich zur Verfügung stellen, müssen mindestens folgende Ereignisse protokollieren: a) Jeder erfolgreiche und erfolglose Zugriffsversuch mit Informationen zur Netzverbindung b) Sperrung einer Benutzerkennung nach mehrmals fehlgeschlagenen Authentisierungsversuchen c) Trennung von Sitzungen d) Deaktivierung/Sperren von Zugangskonten aufgrund von fehlerhaften Eingaben von Anmeldedaten e) Aktivierung/Deaktivierung der Protokollierung. | Artikel 12: Datenaufzeichnung (2) c) i), Artikel 12: Datenaufzeichnung (2) c) v) | nicht relevant | ||||||||
| R.2300.043 | C.2300.007 | Ausreichende Protokollierungen auf Netzwerkebene als Basis für das Sicherheitsmonitoring werden erzeugt | SBK 3 | 1. Der Netzverkehr zwischen geschütztem Netz und dem Internet ist zentral zu protokollieren. Die Protokolle müssen alle relevanten Adressinformationen (z. B. URL, IP) und die verwendeten Dienste (Ports) beinhalten sowie Erfolgs- und Fehlerfälle beinhalten. | Artikel 12: Datenaufzeichnung (2) c) v), Artikel 13: Management der Netzwerksicherheit d) | nicht relevant | ||||||||
| R.2300.044 | C.2300.007 | Ausreichende Protokollierungen auf Netzwerkebene als Basis für das Sicherheitsmonitoring werden erzeugt | SBK 3 | 2. Die Verbindungsversuche bzw. Verbindungen von unberechtigten Endgeräten mit dem Netzwerk sind zu protokollieren. | Artikel 12: Datenaufzeichnung (2) c) v) | nicht relevant | ||||||||
| R.2300.047 | C.2300.008 | Aufbewahrungsfristen von Protokollanten sind unter Berücksichtigung gesetzlicher Vorgaben definiert. Davon in Einzelfällen abweichende längere Aufbewahrungen sind begründet dokumentiert. | SBK 1 | 1. Anforderungen an die Aufbewahrungs- und Löschfristen von Protokolldaten und Security Events aufgrund nationaler oder internationaler gesetzlicher Anforderungen sowie operativer Notwendigkeiten sind festzulegen. Hierbei sind ebenfalls die Geschäfts- und Informationssicherheits¬anforderungen sowie die Aufzeichnungsgründe berücksichtigen. | Artikel 12: Datenaufzeichnung (2) a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.d). | nicht relevant | ||||||||
| R.2300.049 | C.2300.008 | Aufbewahrungsfristen von Protokollanten sind unter Berücksichtigung gesetzlicher Vorgaben definiert. Davon in Einzelfällen abweichende längere Aufbewahrungen sind begründet dokumentiert. | SBK 3 | 1. Die definierten Aufbewahrungsfristen der Protokolldaten und Security Events sind im Rahmen der Erstellung des Sicherheitskonzepts für die IT-Komponente zu analysieren, festzulegen und zu dokumentieren. | Artikel 12: Datenaufzeichnung (2) a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.d). | nicht relevant | ||||||||
| R.2300.051 | C.2300.009 | Die Auswertung von Protokollen erfolgt zweckgebunden. Die Zwecke sind definiert. Die Auswertbarkeit von Protokollen ist sichergestellt. | SBK 1 | 1. Eine Auswertung von Protokollen bei Bedarf/Anlass ist ausreichend (z. B. Verdacht auf einen Sicherheitsvorfall). | nicht relevant | |||||||||
| R.2300.053 | C.2300.009 | Die Auswertung von Protokollen erfolgt zweckgebunden. Die Zwecke sind definiert. Die Auswertbarkeit von Protokollen ist sichergestellt. | SBK 1 | 2. Die Auswertbarkeit der Protokolldateien, einschließlich der Verfügbarkeit etwaiger dazu benötigten Werkzeuge, ist im Rahmen der definierten Aufbewahrungsfristen zu gewährleisten. | nicht relevant | |||||||||
| R.2300.054 | C.2300.009 | Die Auswertung von Protokollen erfolgt zweckgebunden. Die Zwecke sind definiert. Die Auswertbarkeit von Protokollen ist sichergestellt. | SBK 2 | 1. Die Auswertung von Protokollen ist grundsätzlich zu folgenden Zwecken zulässig: a) Problemanalyse b) Proaktive Analyse auf Angriffsversuche c) Identifikation sicherheitsrelevanter Vorfälle d) Beweissicherungssicherungsverfahren. | nicht relevant | |||||||||
| R.2300.085 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 1 | 1. Es sind automatisierte Verfahren zur Auswertung von Systemereignissen und Anomalien zu etablieren. Diese sind an eine sich ständig verändernde Bedrohungslandschaft anzupassen und müssen eine unmittelbare Benachrichtigung ermöglichen. Außerdem müssen sie in der Lage sein, bestimmte Signaturen und Daten oder Verhaltensmuster von Netzwerken oder Anwendungen zu erkennen. | Artikel 08: Identifizierung (2)., Artikel 10: Erkennung.(1)., Artikel 10: Erkennung.(2)., Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1). | Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.-.1), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.a)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) i), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) ii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.b) iii), Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.c)., Artikel 22: Richtlinien für die Behandlung IKT-bezogener Vorfälle.e)., Artikel 12: Datenaufzeichnung (2) c) iv), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) i), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) a) ii), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) a)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) c)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (5) d). | nicht relevant | |||||||
| R.2300.086 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 1 | 2. Die Erkennungsmechanismen sind jährlich zu testen. | Artikel 10: Erkennung.(1)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | nicht relevant | ||||||||
| R.2300.055 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 2 | 2. Mindestens folgende Ereignisse sind im Rahmen eines kontinuierlichen Sicherheitsmonitorings auszuwerten: a) Fehlerhafte Zugangsversuche zum Netzwerk. b) Anmeldeversuche an administrativ deaktivierten oder gelöschten Benutzerkonten. c) Mehrfachansprache von Ports durch externe Adressen in einem zu definierenden Zeitraum um Portscans aufzudecken. d) Das Austesten auf das Vorhandensein von ggf. standardisierten Benutzerkonten. e) Anmeldungen administrativer Benutzer zu ungewöhnlichen Zeiten (z. B. nachts). | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1). | Artikel 12: Datenaufzeichnung (2) c) i), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) d). | nicht relevant | |||||||
| R.2300.056 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 1. Mindestens ändernde und schreibende Zugriffe auf kritische Tabellen in Datenbanken sind auszuwerten. Dazu gehören mindestens: a) Tabellen mit Benutzerdaten b) Tabellen mit Passwörtern c) sicherheitskritische Konfigurationstabellen | nicht relevant | |||||||||
| R.2300.057 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 2. Die Protokolle der IT-Systeme und Anwendungen sind in einer Risikoanalyse im Rahmen der Erstellung des Sicherheitskonzepts hinsichtlich des Bedarfs einer regelmäßigen Auswertung zu bewerten. In die Analyse sind mindestens folgende sicherheitsrelevanten Ereignisse einzubeziehen: a) Fehlerhafte Anmeldungen an Benutzerkonten b) Administration von Benutzern- und Rechten c) Änderungen an sicherheitsrelevanten Einstellungen d) Stoppen oder Ändern der Protokollierungsfunktionen e) Löschung der Protokolldaten f) Herunterfahren/Beenden und Starten von Systemen und Anwendungen g) Meldungen der gestarteten, deaktivierten oder aktivierten Dienste h) Fehlerüberwachung von Systemereignissen i) Erfolgsüberwachung von Systemereignissen j) Lesende Zugriffe von Administratoren auf kritische Tabellen in Datenbanken | Artikel 12: Datenaufzeichnung (2) c) i), Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) d). | nicht relevant | ||||||||
| R.2300.058 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 3. Unabhängig von der Risikoanalyse sind mindestens die folgenden Ereignisse in zentralen Verzeichnisdiensten auszuwerten: a) Mehrfach fehlerhafte Anmeldungen von Administratoren innerhalb eines kurzen – zu definierenden - Zeitraums. b) Taggleiches Anlegen, Verwenden und Löschen eines Benutzerkontos. c) Mehrfache Zugriffsversuche auf vom Hersteller/Anbieter voreingestellte Benutzerkonten. | Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.2300.059 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 4. Mehrfach fehlerhafte Anmeldungen von Administratoren innerhalb eines kurzen – zu definierenden - Zeitraums sind auswerten. | Artikel 12: Datenaufzeichnung (2) c) i) | nicht relevant | ||||||||
| R.2300.060 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 5. Protokollierte Daten zu Transaktionen und elektronischen Einzugsermächtigungen sind über eine Anwendung zur Auswertung von Protokolldateien zu analysieren, die nur befugten Mitarbeitern zur Verfügung stehen. | nicht relevant | |||||||||
| R.2300.082 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 3 | 6. Protokolle von Anwendungen und IT-Systemen sind risikoorientiert automatisiert auf Anomalien auszuwerten. Mindestens für Anwendungen und IT-Systeme, die kritische/wichtige Funktionen unterstützen, müssen die Auswertungen automatisiert erfolgen. | Artikel 17: Prozesse für die Behandlung IKT-bezogener Vorfälle (1). | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b). | nicht relevant | |||||||
| R.2300.061 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 4 | 1. Zusätzlich sind lesende Zugriffe auf kritische Tabellen in Datenbanken auszuwerten. | nicht relevant | |||||||||
| R.2300.084 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 4 | 2. Protokolle von Anwendungen und IT-Systemen sind automatisiert auf Anomalien durch ein SIEM-System auszuwerten. | Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (2) b). | nicht relevant | ||||||||
| R.2300.087 | C.2300.010 | Auswertungen von Protokollierungen werden durchgeführt, um relevante Cyberangriffe, Bedrohungen oder anomale Aktivitäten zu erkennen. | SBK 4 | 3. Es müssen zusätzlich die anwendungsbezogenen Ereignisse ausgewertet werden, sofern diese nicht bereits durch die technische Grundüberwachung von der zugrundeliegenden Betriebssystemebene, Middleware, Datenbank und –speicher und Netzwerkebene abgedeckt ist. | nicht relevant | |||||||||
| R.2300.063 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 1 | 1. Der Zugriff auf Protokolldaten und Protokollierungseinstellungen ist auf definierte Benutzer zu beschränken. Protokolldaten und Protokollierungssysteme sind vor unbefugten Veränderungen und Zugriffen zu schützen. | Artikel 12: Datenaufzeichnung (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.064 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 2 | 2. Verändernde Eingriffe an den Protokollierungseinstellungen sind selbst zu protokollieren, mindestens aber zu dokumentieren . | Artikel 12: Datenaufzeichnung (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.065 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 2 | 3. Die Protokollierungssysteme müssen mindestens folgende Anforderungen erfüllen: a) Der zur Ablage der Protokolle vorgesehene Speicher muss ausreichend dimensioniert sein, um die geforderten Aufbewahrungsfristen zu gewährleisten. b) Bei Überlauf des Protokollspeichers dürfen nur die jeweils zeitlich ältesten Einträge überschrieben werden. c) Der Ausfall von Protokollierungsfunktionen muss erkannt werden | Artikel 12: Datenaufzeichnung (2) d)., Artikel 12: Datenaufzeichnung (2) e)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.066 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 3 | 1. Zum Schutz vor unbefugten Änderungen an den Protokollierungseinstellungen sowie den erzeugten Protokollen, sowie zum Nachweis durchgeführter Eingriffe sind mindestens folgende Vorgaben umzusetzen. Verändernde Eingriffe: a) müssen auf Administratorkonten beschränkt sein, die nicht für administrative Regelaufgaben (z. B. Benutzeradministration, fachliche Administration) der IT-Systeme und Anwendungen verwendet werden), b) sind zu dokumentieren. | Artikel 12: Datenaufzeichnung (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.068 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 3 | 2. Die Protokolldaten müssen vor Veränderungen von den für die betreffende IT-Systemen und Anwendungen zuständigen Administratoren geschützt werden. | Artikel 12: Datenaufzeichnung (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.079 | C.2300.011 | Die Protokolldateien sind ausreichend vor unbefugten Zugriffen geschützt. | SBK 3 | 3. Die Auswertbarkeit der Protokolldaten, einschließlich der Verfügbarkeit etwaiger dazu eingesetzter Werkzeuge, ist sicherzustellen. Die Vollständigkeit der lokalen Protokollkonfiguration und Auswertbarkeit der Protokolldaten muss in regelmäßigen Abständen kontrolliert werden. | Artikel 12: Datenaufzeichnung (2) d)., Artikel 23 Erkennung anormaler Aktivitäten und Kriterien für die Erkennung IKT-bezogener Vorfälle und die Reaktion auf solche Vorfälle (3) -. | nicht relevant | ||||||||
| R.2300.074 | C.2300.012 | Maßnahmen zur Zeitsynchronisation stellen sicher, dass Protokolldaten auf unterschiedlichen Systemen mit gleichen Zeiteinträgen miteinander korreliert werden können | SBK 1 | 1. Es ist eine Standard-Zeitreferenz festzulegen, welche im Unternehmen einheitlich zur Zeit-Synchronisation der IT-Systeme und Anwendungen eingesetzt wird. Die Verfügbarkeit und Genauigkeit des dafür genutzten externen Zeitdienstes muss auf den maximalen Schutzbedarf der IT-Komponenten abgestimmt sein. | Artikel 12: Datenaufzeichnung (2) f). | nicht relevant | ||||||||
| R.2300.075 | C.2300.012 | Maßnahmen zur Zeitsynchronisation stellen sicher, dass Protokolldaten auf unterschiedlichen Systemen mit gleichen Zeiteinträgen miteinander korreliert werden können | SBK 1 | 2. Im Netzwerk ist die Uhrensynchronisation der IT-Systeme und Anwendungen mit dem definierten zentralen Zeitdienst zu gewährleisten. | Artikel 12: Datenaufzeichnung (2) f). | nicht relevant | ||||||||
| 22 | R.2400 - Malwareschutz | |||||||||||||
| R.2400.001 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 1. Alle IT-Systeme, auf denen Informationen verarbeitet oder gespeichert werden sowie Schnittstellen zu nicht vertrauenswürdigen Netzen sind im Rahmen eines dokumentierten und strukturierten Vorgehens (z. B. Malwareschutzkonzept) durch den Einsatz eines aktuellen Malwareschutzes abzusichern. Hierzu gehören mindestens: a) zentrale Internetzugänge/Proxy (eingehend und ausgehend) b) zentrale E-Mail-Zugänge/-Systeme (eingehend und ausgehend) c) jegliche Server, auf denen Dateien zur Kollaboration bereitgestellt werden, sowohl im internen Netz als auch zwischen dem geschützten Netz und Dritten d) NAS-Systeme und Systeme, die als Austauschplattform fungieren, sofern das Hoch- bzw. Herunterladen von Dateien durch Personen möglich ist (z.B. Datenräume, FTP-Server).) e) Client-Systeme (PCs, Laptops, VDI etc.) mit Schnittstellen, über die Daten in das Netz eingespielt werden können f) Mobiltelefone/Smartphones, insofern nicht eine Sandbox-Lösung für den Zugriff auf Daten genutzt wird. | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.003 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 2. Es ist sicherzustellen, dass IT-Systeme, auf denen Informationen verarbeitet oder gespeichert werden, auf Malwarefreiheit überprüft werden. Dabei sind mindestens folgende Kriterien zu berücksichtigen: a) Die Malwarescanner müssen alle transferierten Daten auf Malwarefreiheit prüfen. Dabei ist risikoorientiert die Art, Tiefe und Frequenz zu definieren. b) Eine vollständige Überprüfung des Betriebssystems sowie der Nutzerdaten muss regelmäßig erfolgen. c) Es ist sicherzustellen, dass im Malwarekonzept der Umgang mit folgenden Aspekten geregelt ist: - On-Access-Scanning - On-Demand-Scanning - Scannen von Archivdateien (z. B. Zip Files) - Scannen von externen Datenträgern | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.004 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 3. Ist eine Malwareprüfung von Downloads oder eingehenden E-Mails aus dem Internet nicht möglich (z. B. bei verschlüsselten oder kennwortgeschützten Dateien) müssen die Daten abgelehnt und in Quarantäne gestellt werden. Ausnahmen sind aus begründeten betrieblichen Gründen unter Berücksichtigung der Zuverlässigkeit des Absenders (z. B. Behörden) und einer Risikoanalyse zulässig. | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.005 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 4. Der Malwarescanner muss die Ausführung infizierter Dateien unterbinden, sie z.B. löschen oder in Quarantäne stellen. Handelt es sich um E-Mails oder Dateianhänge, ist der Empfänger zu informieren. | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.007 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 5 Wird eine Malware bei ausgehenden E-Mails identifiziert, ist dieser zu blocken und darf nicht gesendet werden. Die Datei muss in Quarantäne verschoben werden. | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.020 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 6. In Quarantäne isolierte Objekte sind für einen definierten Zeitraum vorzuhalten, bevor sie gelöscht werden. | relevant | |||||||||
| R.2400.021 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 1 | 7. Beim Wiederherstellen von Objekten aus der Quarantäne muss die Malwarefreiheit sichergestellt sein. | relevant | |||||||||
| R.2400.010 | C.2400.001 | Es sind Maßnahmen zum Schutz vor Schadsoftware von IT-Systemen und Schnittstellen zu nicht vertrauenswürdigen Netzen etabliert, sowie Maßnahmen zur Überprüfung von Schadsoftwarefreiheit. | SBK 4 | 1. Wird Schadsoftware auf Anwendungen oder IT-Systemen dieser Schutzbedarfsstufe identifiziert, sind auch die relevanten Datensicherungen und zugreifbare Backups auf das Vorhandensein von Schadsoftware spätestens bei der Wiederherstellung/Wiederverwendung zu überprüfen. | Artikel 11: Daten- und Systemsicherheit (2) d). | relevant | ||||||||
| R.2400.011 | C.2400.002 | Systeme zum Schutz vor Schadsoftware sind etabliert. | SBK 1 | 1. Systeme zum Schutz vor Malware müssen über Methoden verfügen, die grundsätzlich bekannte und bislang unbekannte Schadsoftware erkennen können (z. B. über patternbasierte und merkmalbasierte (heuristische) Erkennungstechnologien) und das unerlaubte Einbringen von ausführbaren Dateien unterbinden. | relevant | |||||||||
| R.2400.012 | C.2400.002 | Systeme zum Schutz vor Schadsoftware sind etabliert. | SBK 1 | 2. Der Malwareschutz muss bei einem Transport von Daten aus externen Netzen mindestens zweistufig (mindestens zwei unterschiedliche Methoden zur Erkennung von Malware (z. B. Scan-Engines verschiedener Hersteller)) ausgelegt sein. | relevant | |||||||||
| R.2400.016 | C.2400.002 | Systeme zum Schutz vor Schadsoftware sind etabliert. | SBK 1 | 3. Malwarescanner sind so einzustellen, dass Nutzer diese nicht deaktivieren und keine sicherheitsrelevanten Änderungen vornehmen können, sofern dieses nicht temporär zu administrationszwecken erforderlich ist. | relevant | |||||||||
| R.2400.017 | C.2400.002 | Systeme zum Schutz vor Schadsoftware sind etabliert. | SBK 1 | 4. Die Software zur Erkennung von Malware ist zentral und auf Basis toolgestützter Verfahren automatisiert zu aktualisieren und zu überwachen. Die Überwachung muss folgende Punkte umfassen: a) Ordnungsgemäße Funktion. b) Aktualität der Malwaresignaturen. c) Malwarefunde und deren Behandlung d) Die Software zur Erkennung von Malware muss auf einem aktuellen Versionsstand gehalten werden. | relevant | |||||||||
| R.2400.019 | C.2400.002 | Systeme zum Schutz vor Schadsoftware sind etabliert. | SBK 1 | 5. Software zur Erkennung von Malware darf nicht über den definierten Software-Lifecycle des Herstellers hinaus betrieben werden. | relevant | |||||||||
| 23 | R.2500 - Sicherheit in der Anwendungs- und Systementwicklung | |||||||||||||
| R.2500.001 | C.2500.001 | Entwicklungs-, Test- und Produktionsumgebungen sind angemessen voneinander getrennt. | SBK 1 | 1. Durch Bereitstellung getrennter Umgebungen für die Entwicklung, die Tests (auch Abnahmeumgebung genannt) und die Produktion muss sichergestellt werden, dass das operative Geschäft frei von Entwickler- und Testtätigkeiten gehalten wird, um unnötige Gefährdungen in Bezug auf Vertraulichkeit, Verfügbarkeit und Integrität der Informationen zu vermeiden. Hierzu muss eine Umgebung das zur Verarbeitung der dort genutzten Daten notwendige Schutzniveau gemäß Schutzbedarfsfeststellung bereitstellen. Weiterhin ist die Testumgebung produktionsnah auszugestalten. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) v), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) vi), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) vii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c). | nicht relevant | |||||||
| R.2500.086 | C.2500.001 | Entwicklungs-, Test- und Produktionsumgebungen sind angemessen voneinander getrennt. | SBK 1 | 2. Der Verwendungszweck der einzelnen Umgebungen muss klar definiert und dokumentiert sein (z. B. Funktionstest in der Entwicklungsumgebung, fachliche Funktionstests und Fehlersuche in der Testumgebung, keine Tests in der Produktionsumgebung). | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) v), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) vi), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c). | nicht relevant | |||||||
| R.2500.002 | C.2500.001 | Entwicklungs-, Test- und Produktionsumgebungen sind angemessen voneinander getrennt. | SBK 1 | 3. Jede Anwendung muss vor ihrer Überführung in die Produktion auf die Einhaltung ihrer Spezifikationen, besonders hinsichtlich Sicherheit, getestet werden (Systemabnahmetest). Ebenso muss die Konfiguration der unterschiedlichen Systemkomponenten vor der Installation in die produktive Umgebung getestet werden. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c). | nicht relevant | |||||||
| R.2500.005 | C.2500.001 | Entwicklungs-, Test- und Produktionsumgebungen sind angemessen voneinander getrennt. | SBK 4 | 1. Der Zugriff aus den produktiven Systemen auf Entwicklungswerkzeuge (z. B. Compiler, Hex-Editoren) darf nicht möglich sein. _x0007_ | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) v), Artikel 08: Richtlinien und Verfahren für IKT-Vorgänge (2) b) vi), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c). | nicht relevant | |||||||
| R.2500.006 | C.2500.002 | Tätigkeiten in der Anwendungsentwicklung sind angemessen voneinander getrennt, um Interessenskonflikte zu vermeiden. | SBK 1 | 1. Die Zuständigkeiten und Verantwortlichkeiten im Rahmen von Anwendungsentwicklung und -test müssen eindeutig geregelt und dokumentiert werden. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | nicht relevant | ||||||||
| R.2500.087 | C.2500.002 | Tätigkeiten in der Anwendungsentwicklung sind angemessen voneinander getrennt, um Interessenskonflikte zu vermeiden. | SBK 1 | 2. Entwicklungsfunktionen müssen so ausgestaltet sein, dass Änderungen an Anwendungen weder in Produktions- noch in Testumgebungen vorgenommen werden können. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | nicht relevant | ||||||||
| R.2500.088 | C.2500.002 | Tätigkeiten in der Anwendungsentwicklung sind angemessen voneinander getrennt, um Interessenskonflikte zu vermeiden. | SBK 1 | 3. Funktionen, die das fachliche Testen von Anwendungen betreffen, müssen von denen in der Entwicklung getrennt werden. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | nicht relevant | ||||||||
| R.2500.010 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 1 | 1. Zu Beginn (Planungs- und Entwurfsphase) der Anwendungsentwicklung ist der Schutzbedarf der geplanten Anwendung zu erheben und zu ermitteln, welche Risiken/Bedrohungen im Zusammenhang mit den geplanten _x000D_ Anwendungsspezifikationen berücksichtigt werden müssen. Hieraus sind insbesondere die zu implementierenden Sicherheitsmaßnahmen herzuleiten. Die Maßnahmen haben sich an der aktuellen Bedrohungssituation zu orientieren (z. B. OWASP Top 10, BSI-Leitfaden zur Entwicklung sicherer Webanwendungen, Test Criteria Catalogue for AI Systems in Finance des BSI für AI-Systeme). | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.089 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 1 | 2. Die Entwickler sind auf die Anwendung der zu implementierenden Sicherheitsmaßnahmen zu schulen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.012 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 1 | 3. Es müssen Vorgaben und Prozesse zur sicheren Entwicklung von Software und IT-Systemen zum Aufbau eines sicheren Dienstes, einer sicheren Architektur sowie eines sicheren IT-Systems dokumentiert und implementiert sein. Hierbei sind insbesondere die Phasen der Planung der Softwareentwicklung, der Softwareentwicklung selbst sowie der Überprüfung und Wartung der Software zu berücksichtigen. Diesbezüglich sind folgende Aspekte zu regeln: a) Grundsätze zur sicheren Systementwicklung, b) Genehmigte Entwicklungswerkzeuge, c) Sichere Verwendung der genutzten Programmiersprachen, d) Whitelist genehmigter Bibliotheken, Funktionen und APIs. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.045 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 1 | 4. Es sind angemessene Prozesse und Vorgaben in Bezug auf sichere Entwicklungsverfahren, inklusive sicherer Entwicklungsumgebungen, zu etablieren. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.090 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 1 | 5. Anforderungen an die Funktionalität der Anwendung (z.B. Fachkonzepte (Lastenheft), Technisches Fachkonzept (Pflichtenheft)) müssen ebenso erhoben, bewertet und dokumentiert werden wie nichtfunktionale Anforderungen (z.B. Ergebnisse der Schutzbedarfsfeststellung, Zugriffsregelungen, Ergonomie, Wartbarkeit, Antwortzeiten, Resilienz). | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.015 | C.2500.003 | Die Entwicklung von Software und IT-Systemen erfolgt in sicherer Art und Weise. | SBK 2 | 1. Die Entwicklungsergebnisse sind fortlaufend, spätestens aber abschließend vor Produktivnahme, Sicherheitsüberprüfungen nach gängigen Standards, inklusive risikoorientiert festzulegender statischer und dynamischer Testverfahren (einschließlich Code-Reviews), zu unterziehen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) b)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) c)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2500.018 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 1. Anwendungs- und Systemänderungen (u. a. Patches, Service Packs und andere Aktualisierungen) sind vor dem produktiven Einsatz technisch und fachlich zu testen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.063 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 2. Für neue Informationssysteme, Upgrades und neue Versionen müssen Testpläne und dazugehörige Abnahmekriterien bezüglich der Anforderungen der Informationssicherheit und der sicheren Anwendungsentwicklung festgelegt sein. Hierzu sind folgende Aspekte zu beachten: a) Verantwortlichkeiten b) Definition der Testfälle c) Informationssicherheit | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.053 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 3. Während der Entwicklung muss die Funktion der erwarteten und zuvor festgelegten Sicherheitsfunktionen nach gängigen Testvefahren getestet und dokumentiert werden. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.091 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 4. Bei webbasierten IT-Systemen, die aus dem Internet erreichbar sind, müssen zusätzlich die folgenden Funktionen getestet werden: a) Mechanismen zum Sessionmanagement, b) Verarbeitung manipulierter Daten über Schnittstellen (z. B. im Rahmen von Cross-Site-Scripting), c) Absicherung von Implementierungsobjekte (z. B. Dateien, Ordner), sofern diese von außen zugänglich sind (Unsichere direkte Objektreferenzen), d) Umgang mit manipulierten HTTP-Requests, e) Umgang mit manipulierten Ziel-URLs bei Um- und Weiterleitungen, f) Einspielen manipulierter Daten als Teil von Kommandos oder einer Abfrage (Injection). | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d)., Artikel 25: Testen von IKT-Tools und -Systemen (1). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.092 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 5. Es muss sichergestellt werden, dass die Freigabe der Informationssysteme für die Produktion erst erfolgt, wenn: a) die Anwendungsfunktionen und -regeln erfolgreich getestet wurden, b) die Schnittstellen zu vor- und nachgelagerten Anwendungen funktionsfähig sind, c) die Betriebs- und Anwendungsdokumentation aktualisiert wurde und eine Freigabeerklärung von den technisch und fachlich Verantwortlichen vorliegt, aus der sich ergibt, welche Anwendungs-/Programmversion ab welchem Zeitpunkt für den produktiven Einsatz vorgesehen ist. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.069 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 1 | 6. Für im Internet exponierte Systeme und Anwendungen ist im Rahmen der Ersteinführung ein Penetrationstest durchzuführen. Bei funktionalen oder sicherheitsrelevanten Änderungen ist die Notwendigkeit für die Durchführung eines Penetrationstests zu ermitteln. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.023 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 2 | 1. Die Codeänderungen sind von einem anderen Mitarbeiter zu prüfen als dem ursprünglichen Ersteller des Codes (Vier-Augen-Prinzip). Die Mitarbeiter müssen mit dem Verfahren zur Codeprüfung und sicheren Programmiertechniken vertraut sein. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.093 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 2 | 2. Mindestens folgende Sicherheitsfunktionen müssen getestet werden: a) Authentifizierungsmechanismen, b) Zugriffsfunktionen, c) Protokollierung, d) Sicherheitskonfiguration. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.094 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 3 | 1. Mindestens folgende Sicherheitsfunktionen müssen getestet werden: a)\tVerhalten bei fehlerhaften Eingaben in Erfassungsfeldern, b)\tVerhalten von Schnittstellen bei Eingang fehlerhafter Daten (Unexpected Input). | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.096 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 3 | 2. Bei KI-Systemen müssen zusätzlich mindestens die folgenden Mechanismen getestet werden: a) Verhinderung von Prompt Injection / Jailbreaking / Manipulation des Modells durch Prompting (OWASP LLM01), b) Verhinderung von unerwünschter Datenextraktion (OWASP LLM02), c) Verhinderung von Data and Model Poisoning / Model Theft / unerwünschte Manipulation des Modells durch Verfälschung von (Trainings-) Daten (OWASP LLM04). | KI-Systeme | nicht relevant | ||||||||
| R.2500.076 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 4 | 1. Bei wesentlichen Änderungen ist während des Software-Entwicklungsprozesses der Ist-Zustand des Sicherheitsniveaus des IT-Systems ist zu bewerten.. Weiterhin sind automatische Tools wie Codeanalyse-Tools oder Schwachstellen-Scanner zu nutzen. Etwaige sicherheitsbezogene Defizite sind zu beheben und die Behebung zu kontrollieren. | Artikel 07: IKT-Systeme, -Protokolle und -Tools.b)., Artikel 07: IKT-Systeme, -Protokolle und -Tools.d). | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (3) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2500.097 | C.2500.004 | Änderungen erfolgen in einem geordneten Verfahren, das angemessene Tests und Sicherheitsüberprüfungen einschließt. | SBK 4 | 2. Bei KI-Systemen müssen zusätzlich mindestens die folgenden Mechanismen getestet werden: a) Verhinderung von Unbounded Consumption / übermäßigem Ressourcenverbrauch (OWASP LLM10), b) Verhinderung von unerwünschten Ergebnissen durch kompromittierte Drittanbieter Modelle (OWASP LLM03), c) Verhinderung von Excessive Agency / übermäßige Autonomie (OWASP LLM06). | KI-Systeme | nicht relevant | ||||||||
| R.2500.038 | C.2500.005 | Grundsätze zur sicheren Systementwicklung sind definiert und werden eingehalten. | SBK 1 | 1. Grundsätze für die sichere Analyse, Entwicklung und Pflege von Systemen sind festzulegen, zu dokumentieren und für jedes Informationssystem anzuwenden. Hierzu sind folgende Aspekte zu berücksichtigen: a) Benutzerauthentifizierung, b) Sitzungssteuerung, c) Datenvalidierung, d) Sämtliche Architekturschichten. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | ||||||||
| R.2500.039 | C.2500.005 | Grundsätze zur sicheren Systementwicklung sind definiert und werden eingehalten. | SBK 1 | 2. Die definierten Grundsätze müssen regelmäßig auf Angemessenheit, Plausibilität und Umsetzung überprüft werden. Dabei sind mindestens neue Anforderungen aus Sicherheitsvorgaben und Best Practices zu berücksichtigen. _x0007_ | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | ||||||||
| R.2500.049 | C.2500.006 | Die Software- und Systementwicklungen durch Dritte unterliegen gesonderten Anforderungen. | SBK 1 | 1. Software, die im Auftrag durch Dritte entwickelt wird, muss erst eine sorgfältigen Abnahme- und Freigabeprozess durchlaufen, bevor diese auf den produktiven IT-Systemen installiert wird. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | ||||||||
| R.2500.095 | C.2500.006 | Die Software- und Systementwicklungen durch Dritte unterliegen gesonderten Anforderungen. | SBK 1 | 2. An externe Dritte vergebene Anwendungs- und Systementwicklungstätigkeiten müssen überwacht und beaufsichtigt werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | ||||||||
| R.2500.078 | C.2500.007 | Die Verwendung von Testdaten ist angemessen geregelt. Echtdaten werden nur in eingeschränktem Maß und unter besonderen Bedingungen als Testdaten verwendet. | SBK 1 | 1. Handelt es sich um personenbezogene Daten, so sind die Vorgaben zur Verwendung von Echtdaten bei Tests für die Schutzbedarfsklassen 2 und 3 schon ab Schutzbedarfsklasse 1 verpflichtend. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | ||||||||
| R.2500.080 | C.2500.007 | Die Verwendung von Testdaten ist angemessen geregelt. Echtdaten werden nur in eingeschränktem Maß und unter besonderen Bedingungen als Testdaten verwendet. | SBK 2 | 1. Wenn mit Echtdaten getestet wird, müssen die gleichen Sicherheitsmechanismen und Rahmenbedingungen gelten wie in der Produktion. Die Nutzung der Daten für Testzwecke ist zu dokumentieren und die Echtdaten aus der Testumgebung zu entfernen, sobald sie nicht mehr benötigt werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | ||||||||
| R.2500.081 | C.2500.007 | Die Verwendung von Testdaten ist angemessen geregelt. Echtdaten werden nur in eingeschränktem Maß und unter besonderen Bedingungen als Testdaten verwendet. | SBK 3 | 1. Ein Test mit Echtdaten ist grundsätzlich nicht zulässig. Sollte ein Test mit selbst generierten Testdaten nicht möglich sein, sind die Echtdaten zu anonymisieren. Ist ein Test mit anonymisierten Daten nicht möglich, sind Echtdaten zu pseudonymisieren. Ist ein Test nur mit Echtdaten oder pseudonymisierten Echtdaten möglich, ist der Sachverhalt im Rahmen der Risikoprozesse im Risikoinventar zu erfassen und die Notwendigkeit für die Nutzung von Echtdaten zu begründen (Nachvollziehbarkeit, Aufwand für die Testdatengenerierung, Qualitätssicherung). Erst dann ist unter Abwägung und Begründung der Verhältnismäßigkeit und des berechtigten Interesses des Unternehmens ein Test mit Echtdaten im Testsystem zulässig. Die Interessenabwägung ist im Einzelfall durchzuführen und zu dokumentieren. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | ||||||||
| R.2500.085 | C.2500.007 | Die Verwendung von Testdaten ist angemessen geregelt. Echtdaten werden nur in eingeschränktem Maß und unter besonderen Bedingungen als Testdaten verwendet. | SBK 4 | 1. Ein Test mit Echtdaten sowie pseudonymisierten Echtdaten ist nicht zulässig. Sollte ein Test mit selbst generierten Testdaten nicht möglich sein, sind die Echtdaten zu anonymisieren. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | ||||||||
| 32 | R.2510 - SICHERHEIT IN DER ENTWICKLUNG VON IDV/EUC | |||||||||||||
| R.2510.002 | C.2510.001 | Die Trennung von Entwicklungs-, Test- und Produktionsumgebungen bei TIA ist sichergestellt. | SBK 2 | 1. Entwicklungs-, Test- und Produktionsumgebungen müssen bei der Entwicklung von TIA voneinander getrennt werden. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c). | nicht relevant | |||||||
| R.2510.065 | C.2510.001 | Die Trennung von Entwicklungs-, Test- und Produktionsumgebungen bei TIA ist sichergestellt. | SBK 2 | 2. Der Verwendungszweck der einzelnen Umgebungen muss klar definiert und dokumentiert sein (z. B. Funktionstest in der Entwicklungsumgebung, fachliche Funktionstests und Fehlersuche in der Testumgebung, keine Tests in der Produktionsumgebung). | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c). | nicht relevant | |||||||
| R.2510.066 | C.2510.001 | Die Trennung von Entwicklungs-, Test- und Produktionsumgebungen bei TIA ist sichergestellt. | SBK 2 | 3. Die Regeln für den Transfer von Software von Entwicklungs- zum Produktionsstatus müssen festgelegt und dokumentiert werden. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c). | nicht relevant | |||||||
| R.2510.004 | C.2510.001 | Die Trennung von Entwicklungs-, Test- und Produktionsumgebungen bei TIA ist sichergestellt. | SBK 4 | 1. Entwicklungen im Rahmen von TIA sind untersagt._x000D_ | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c). | nicht relevant | |||||||
| R.2510.006 | C.2510.002 | Tätigkeiten in der Entwicklung von TIA sind zur Vermeidung von Interessenkonflikten getrennt. | SBK 2 | 1. Bei der Entwicklung von TIA müssen Funktionen derart auf verschiedene Mitarbeiter übertragen werden, dass ihre Ausübung nicht zu einem Interessenkonflikt bei dem ausführenden Mitarbeiter führt. | IDV/EUC | nicht relevant | ||||||||
| R.2510.068 | C.2510.002 | Tätigkeiten in der Entwicklung von TIA sind zur Vermeidung von Interessenkonflikten getrennt. | SBK 2 | 2. Die Zuständigkeiten und Verantwortlichkeiten im Rahmen von Entwicklung und Tests von TIA müssen eindeutig geregelt werden. | IDV/EUC | nicht relevant | ||||||||
| R.2510.070 | C.2510.002 | Tätigkeiten in der Entwicklung von TIA sind zur Vermeidung von Interessenkonflikten getrennt. | SBK 3 | 1. Entwicklungsfunktionen müssen so ausgestaltet sein, dass Entwickler keine unkontrollierten Änderungen in Produktionsumgebung und fachlichen Testumgebungen vornehmen können. | IDV/EUC | nicht relevant | ||||||||
| R.2510.071 | C.2510.002 | Tätigkeiten in der Entwicklung von TIA sind zur Vermeidung von Interessenkonflikten getrennt. | SBK 3 | 2. Die fachlichen Tests dürfen nicht von Personen vorgenommen werden, welche die TIA entwickelt haben. | IDV/EUC | nicht relevant | ||||||||
| R.2510.031 | C.2510.002 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 1 | 1. Grundsätze für die Analyse, Entwicklung und Pflege sicherer TIA sind festzulegen, zu dokumentieren und anzuwenden. Dabei sind mindestens Programmierstandards für die Entwicklung von TIA festzulegen. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.009 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 1 | 1. TIA-Anwendungen dürfen nicht direkt mit dem Internet verbunden werden oder aus dem Internet erreichbar sein. | IDV/EUC | nicht relevant | ||||||||
| R.2510.010 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 2 | 1. Es müssen Vorgaben und Prozesse zur sicheren Entwicklung von TIA dokumentiert und implementiert sein. Es sind mindestens die folgenden Aspekte zu beschreiben: a) Grundsätze zur sicheren Entwicklung sind unter Berücksichtigung der Sicherheitsvorgaben zu defineiren. b) Genehmigte Entwicklungswerkzeuge/Trägersysteme c) Die genutzten Programmiersprachen, Bibliotheken und APIs inkl. zugehöriger Vorgaben zur sicheren Verwendung d) Sicherheitsanforderungen (z. B. Berechtigungskonzept) unter Berücksichtigung der Schutzbedarfsklassifizierung e) Archivierungskonzept für Source Code und Programmversionen f) Rollback-Prozess | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) b). | nicht relevant | |||||||
| R.2510.032 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 2 | 2. Für TIA ist festzulegen, aus welchen bestandsführenden Anwendungen TIA Daten importiert werden. | IDV/EUC | nicht relevant | ||||||||
| R.2510.069 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 2 | 3. Für TIA, die in einem Geschäftsprozess aus DV-Anwendungen Daten importieren, ist sicherzustellen, dass der entwickelnde Fachbereich über Änderungen des bestandführenden Systems, die sich auf die TIA auswirken können, informiert wird. | IDV/EUC | nicht relevant | ||||||||
| R.2510.033 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 2 | 4. Ergänzend sind für die Aufrechterhaltung der Integrität geeignete Mittel für die jeweilige Technologie einzusetzen. | IDV/EUC | nicht relevant | ||||||||
| R.2510.011 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 3 | 1. Bevor eine TIA entwickelt wird ist gemeinsam mit dem IT-Architekturmanagement zu prüfen, ob die geplanten Aufgaben der TIA über bereits bestehende Anwendungen abgedeckt werden können. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.072 | C.2510.003 | Prozesse zur sicheren Entwicklung von TIA sind etabliert. | SBK 3 | 2. Die Entwicklungsergebnisse sind fortlaufend, spätestens aber vor Produktivnahme, Sicherheitsüberprüfungen nach gängigen Standards zu unterziehen (z. B. Code-Reviews). | IDV/EUC | nicht relevant | ||||||||
| R.2510.014 | C.2510.004 | Prozesse zur formellen Änderungskontrolle bei TIA sind etabliert, die insbesondere strukturierte Freigabe Prozesse und Sicherheitsfunktionstests im Rahmen der Entwicklung umfassen. | SBK 1 | 1. Anpassungen bei TIA sind vor dem produktiven Einsatz zu dokumentieren und Tests zur Sicherstellung der fachlichen und technischen Funktionsfähigkeit durchzuführen. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.016 | C.2510.004 | Prozesse zur formellen Änderungskontrolle bei TIA sind etabliert, die insbesondere strukturierte Freigabe Prozesse und Sicherheitsfunktionstests im Rahmen der Entwicklung umfassen. | SBK 2 | 1. Bevor die neue oder geänderte TIA in die Produktionsumgebung überführt werden, ist ein Freigabeverfahren zu durchlaufen, das mindestens die folgende Aspekte regelt: a) Durchführung von Tests b) Sicherheitsfunktionstests im Rahmen der Entwicklung von TIA c) Verwendung von Testdaten. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -. | nicht relevant | |||||||
| R.2510.073 | C.2510.004 | Prozesse zur formellen Änderungskontrolle bei TIA sind etabliert, die insbesondere strukturierte Freigabe Prozesse und Sicherheitsfunktionstests im Rahmen der Entwicklung umfassen. | SBK 2 | 2. Änderungen von TIA müssen nachvollziehbar dokumentiert, kontrolliert und freigegeben werden. | IDV/EUC | nicht relevant | ||||||||
| R.2510.074 | C.2510.004 | Prozesse zur formellen Änderungskontrolle bei TIA sind etabliert, die insbesondere strukturierte Freigabe Prozesse und Sicherheitsfunktionstests im Rahmen der Entwicklung umfassen. | SBK 3 | 1. Die Codeänderungen sind von einem anderen Mitarbeiter zu prüfen als dem ursprünglichen Ersteller des Codes (Vier-Augen-Prinzip). Die Mitarbeiter müssen mit dem Verfahren zur Codeprüfung und sicheren Programmiertechniken vertraut sein. | IDV/EUC | nicht relevant | ||||||||
| R.2510.075 | C.2510.004 | Prozesse zur formellen Änderungskontrolle bei TIA sind etabliert, die insbesondere strukturierte Freigabe Prozesse und Sicherheitsfunktionstests im Rahmen der Entwicklung umfassen. | SBK 3 | 2. Müssen Programmänderungen in Ausnahmesituationen (z. B. Notfall, Fehler bei der Programmübergabe) vorgenommen werden, sind diese unmittelbar im Anschluss in Entwicklung- und Testumgebung nachzuziehen, dem Produktionsfreigabeverfahren zuzuführen und nachträglich freizugeben. | IDV/EUC | nicht relevant | ||||||||
| R.2510.041 | C.2510.005 | Durch Dritte entwickelte TIA werden erst nach einem Abnahme- und Freigabeprozess auf den produktiven IT-Systemen installiert und vertragliche Vereinbarungen zu Überprüfungen sowie Dokumentation und Leistungserbringungen sind getroffen. | SBK 1 | 1. TIA die im Auftrag des Unternehmens durch Dritte entwickelt wird, ist erst nach einem sorgfältigen Abnahme- und Freigabeprozess auf den produktiven IT-Systemen zu installieren. Daher müssen an externe Dritte vergebene Entwicklungstätigkeiten überwacht und beaufsichtigt werden. Dabei sind die folgenden Punkte zu berücksichtigen:_x000D_ a) Die internen Anforderungen an die Entwicklung von TIA müssen vereinbart werden._x000D_ b) Die Lizenzierungsmodelle, die Eigentümerschaft an sowie die Nutzungs-/Überlassungs- und Hinterlegungsvereinbarungen zum Programmcode und die geistigen Eigentumsrechte in Bezug auf die beauftragten Inhalte müssen geregelt sein._x000D_ c) Die Kriterien für die Abnahmeprüfung bezüglich der Qualität und Genauigkeit (Testumfang und -tiefe, sowie spezielle Testwerkzeuge) der bereitgestellten Leistungen müssen schriftlich fixiert werden._x000D_ d) Das vertragliche Recht zur Überprüfung der Entwicklungsprozesse, -umgebung und Kontrollmaßnahmen muss eingeräumt sein._x000D_ e) Die vom Auftragnehmer zu erstellenden Dokumentationen, die zur ordnungsgemäßen Leistungserbringung erforderlich sind (Handbücher, technische Beschreibungen, etc.), sind vertraglich zu vereinbaren._x000D_ f) Vertragliche Vereinbarungen zur Archivierung von Sourcecode und TIA-Dokumentation gemäß den gültigen gesetzlichen und aufsichtsrechtlichen Anforderungen und Aufbewahrungsfristen sind zu treffen. _x0007_ | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (7) -. Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (8) -. | nicht relevant | |||||||
| R.2510.045 | C.2510.006 | Sicherheitsfunktionstests im Rahmen der Entwicklung von TIA werden durchgeführt. | SBK 1 | 1. Während der Entwicklung muss die Funktion der erwarteten und zuvor festgelegten Sicherheitsfunktionen getestet und dokumentiert werden. | IDV/EUC | nicht relevant | ||||||||
| R.2510.047 | C.2510.006 | Sicherheitsfunktionstests im Rahmen der Entwicklung von TIA werden durchgeführt. | SBK 2 | 1. Es muss eine Planung der Aktivitäten, Testeingaben und erwarteten Ausgaben unter verschiedenen Bedingungen für definierte Sicherheitsfunktionen vorliegen. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.076 | C.2510.006 | Sicherheitsfunktionstests im Rahmen der Entwicklung von TIA werden durchgeführt. | SBK 3 | 1. Folgende Sicherheitsfunktionen sind mindestens zu testen: a) Verhalten bei fehlerhaften Eingaben in Erfassungsfeldern; b) Verhalten von Schnittstellen bei Eingang fehlerhafter Daten (Unexpected Input). | IDV/EUC | nicht relevant | ||||||||
| R.2510.051 | C.2510.007 | Die Durchführung von Abnahmetests sowie Freigaben von TIA sind prozessual nach gängigen Standards etabliert und berücksichtigen insbesondere Aspekte der Informationssicherheit. | SBK 1 | 1. Für neue TIA, Upgrades und neue Versionen müssen Testpläne und dazugehörige Abnahmekriterien bezüglich der Anforderungen der Informationssicherheit und der sicheren Anwendungsentwicklung festgelegt sein. Hierzu sind folgende Aspekte zu beachten: a) Verantwortlichkeiten b) Definition der Testfälle c) Informationssicherheit | IDV/EUC | nicht relevant | ||||||||
| R.2510.052 | C.2510.007 | Die Durchführung von Abnahmetests sowie Freigaben von TIA sind prozessual nach gängigen Standards etabliert und berücksichtigen insbesondere Aspekte der Informationssicherheit. | SBK 2 | 2. Die Tests müssen in einer produktionsnahen Testumgebung durchgeführt werden. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.053 | C.2510.007 | Die Durchführung von Abnahmetests sowie Freigaben von TIA sind prozessual nach gängigen Standards etabliert und berücksichtigen insbesondere Aspekte der Informationssicherheit. | SBK 2 | 3. Die Freigabe der TIA für die Produktion darf erst erfolgen, wenn:_x000D_ a) die Anwendungsfunktionen und -regeln erfolgreich getestet wurden und stabil funktionieren,_x000D_ b) die Schnittstellen zu vor- und nachgelagerten Anwendungen funktionsfähig sind,_x000D_ c) die Anwendungsdokumentation (z. B. fachliche Anwendungsbeschreibung) aktualisiert wurde und_x000D_ d) eine Freigabeerklärung vorliegt, aus der sich ergibt, welche TIA-Version ab welchem Zeitpunkt für den produktiven Einsatz vorgesehen ist. _x0007_ | IDV/EUC | nicht relevant | ||||||||
| R.2510.054 | C.2510.007 | Die Durchführung von Abnahmetests sowie Freigaben von TIA sind prozessual nach gängigen Standards etabliert und berücksichtigen insbesondere Aspekte der Informationssicherheit. | SBK 2 | 3. Die Testprozesse- und Dokumentationen sind nach gängigen Standards zu definieren und durchzuführen. | IDV/EUC | nicht relevant | ||||||||
| R.2510.062 | C.2510.008 | Die Verwendung von Testdaten bei TIA ist geregelt. Dabei ist insbesondere die Verwendung von Echtdaten restriktiv zu regeln. | SBK 1 | 1. Handelt es sich um personenbezogene Daten, so sind die Vorgaben zur Verwendung von Echtdaten bei fachlichen Tests für die Schutzbedarfsklassen 2 und 3 schon ab Schutzbedarfsklasse 1 verpflichtend. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | |||||||
| R.2510.063 | C.2510.008 | Die Verwendung von Testdaten bei TIA ist geregelt. Dabei ist insbesondere die Verwendung von Echtdaten restriktiv zu regeln. | SBK 2 | 1. Wenn mit Echtdaten getestet wird, müssen die gleichen Sicherheitsmechanismen und Rahmenbedingungen gelten wie in der Produktion._x000D_ Die Nutzung der Daten für Testzwecke ist zu dokumentieren und die Echtdaten aus der Testumgebung zu entfernen, sobald sie nicht mehr benötigt werden. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | |||||||
| R.2510.064 | C.2510.008 | Die Verwendung von Testdaten bei TIA ist geregelt. Dabei ist insbesondere die Verwendung von Echtdaten restriktiv zu regeln. | SBK 3 | 1. Ein Test mit Echtdaten ist grundsätzlich nicht zulässig. Sollte ein Test mit selbst generierten Testdaten nicht möglich sein, sind die Echtdaten zu anonymisieren. Ist ein Test mit anonymisierten Daten nicht möglich, sind Echtdaten zu pseudonymisieren. Ist ein Test nur mit Echtdaten oder pseudonymisierten Echtdaten möglich, ist der Sachverhalt im Rahmen der Risikoprozesse im Risikoinventar zu erfassen und die Notwendigkeit für die Nutzung von Echtdaten zu begründen (Nachvollziehbarkeit, Aufwand für die Testdatengenerierung, Qualitätssicherung). Erst dann ist unter Abwägung und Begründung der Verhältnismäßigkeit und des berechtigten Interesses des Unternehmens ein Test mit Echtdaten im Testsystem zulässig. Die Interessenabwägung ist im Einzelfall durchzuführen und zu dokumentieren. | IDV/EUC | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (5) a)., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (6) -. | nicht relevant | |||||||
| 24 | R.2600 - Einsatz von Software | |||||||||||||
| R.2600.001 | C.2600.001 | Die Nutzung administrativer Dienst- oder Hilfsprogramme erfolgt restriktiv und ist besonders eingeschränkt. | SBK 1 | 1. Die Verwendung von Dienst- oder Hilfsprogrammen, die in der Lage sein könnten, System- und Sicherheitsfunktionen zu umgehen (z. B. Diagnose-, Patching-, Antivirus-, Festplatten-Defragmentierer, Debugger, Sniffer, Backup- und Netzwerk-Tools), ist ausschließlich für administrative Zwecke in der IT-Organisation zulässig. | relevant | |||||||||
| R.2600.016 | C.2600.001 | Die Nutzung administrativer Dienst- oder Hilfsprogramme erfolgt restriktiv und ist besonders eingeschränkt. | SBK 1 | 2. Die Nutzung ist auf einen begrenzten Personenkreis einzuschränken. | relevant | |||||||||
| R.2600.017 | C.2600.001 | Die Nutzung administrativer Dienst- oder Hilfsprogramme erfolgt restriktiv und ist besonders eingeschränkt. | SBK 1 | 3. Die Nutzung darf ausschließlich für den geplanten und dokumentierten Verwendungszweck erfolgen. | relevant | |||||||||
| R.2600.018 | C.2600.001 | Die Nutzung administrativer Dienst- oder Hilfsprogramme erfolgt restriktiv und ist besonders eingeschränkt. | SBK 1 | 4. Bei jeder Verwendung solcher Programme sind folgende Punkte mindestens zu protokollieren: a) nutzende Benutzer, b) Nutzungszeitraum, c) Nutzungszweck. | relevant | |||||||||
| R.2600.005 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 1. Die Aktivierung automatisierter Softwareupdates/-patches auf produktiven Systemen ist grundsätzlich nicht zulässig. Unter Abwägung und Begründung der Verhältnismäßigkeit und des berechtigten Interesses des Unternehmens kann im Einzelfall eine Aktivierung automatisierter Softwareupdates/-patches unter folgenden Voraussetzungen erfolgen: - Weit verbreitete Standardsoftware - Geringes Risiko von Störungen nach der Einspielung der automatischen Softwareupdates Die Freigabe muss im Rahmen des geregelten Änderungsprozesses erfolgen und ist jährlich zu revalidieren. | relevant | |||||||||
| R.2600.019 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 2. Produktivsysteme dürfen nur zugelassenen ausführbaren Code enthalten und keinen Entwicklungscode oder Compiler. | relevant | |||||||||
| R.2600.020 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 3. Alle Änderungen an einem produktiven Asset durch Neuinstallation oder Updates sind im Rahmen des Konfigurationsmanagements zu dokumentieren. | relevant | |||||||||
| R.2600.021 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 4. Alle eingespielten produktiven Softwarestände sind in einem Repository zu hinterlegen. | relevant | |||||||||
| R.2600.022 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 5. Die produktive Software ist so abzusichern, dass das automatisierte Ausführen oder Nachladen von Code aus fremden Quellen (z. B. Externes Office Dokument mit Makros) verhindert wird. Sofern eine betriebliche Notwendigkeit besteht, ist für das Ausführen/das Nachladen eine explizite Benutzerbestätigung erforderlich. | relevant | |||||||||
| R.2600.006 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 6. Die eingesetzten Softwarestände müssen durch den Hersteller unterstützt und damit mit Sicherheitsupdates versorgt werden. | relevant | |||||||||
| R.2600.023 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 1 | 7. Die Versionen der verwendeten Bibliotheken von Drittanbietern sind in auswertbarer Form zu dokumentieren. Abweichend hiervon ist die Nutzung von Bibliotheken von Drittanbietern bei Anwendungen und IT-Systemen, die keine kritischen/wichtigen Funktionen unterstützen und bei Standardsoftware nur nach Möglichkeit zu dokumentieren. | Artikel 10: Schwachstellen- und Patch-Management (2) d) i), Artikel 10: Schwachstellen- und Patch-Management (2) d) ii) | relevant | ||||||||
| R.2600.009 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 3 | 1. Anwendungen dieser Schutzbedarfsstufe dürfen in folgenden Umgebungen grundsätzlich nicht mit anderen Anwendungen, welche niedrigere Schutzbedarfsstufen haben, installiert und betrieben werden: a) innerhalb einer virtuellen Umgebung; b) bei direkter Installation auf einem physischen IT-System. Sofern dies aus z. B. wirtschaftlichen Gründen nicht sinnvoll ist, ist sicherzustellen, dass der gemeinsame Betrieb keine negativen Auswirkungen auf Anwendungen der höheren Schutzbedarfsklassen nach sich zieht. Die technischen Systemabnahmetests sind dementsprechend gem. der Anforderungen der Anwendung mit dem höchsten Schutzbedarf durchzuführen. | relevant | |||||||||
| R.2600.024 | C.2600.002 | Der Einsatz von Software auf Systemen im produktiven Betrieb erfolgt unter kontrollierten Bedingungen. Nur zugelassene Software ist installiert und die genutzten Softwarevarianten sind nachvollziehbar dokumentiert | SBK 4 | 1. Daten sind während ihrer Verwendung im Arbeitsspeicher (RAM), in CPU-Caches oder CPU-Registern („Data in Use“) zu verschlüsseln. Wenn dies nicht erfolgt, ist im Rahmen einer Analyse zu bewerten und zu dokumentieren, ob zusätzlich zu den bestehenden Schutzmaßnahmen (insbesondere Maßnahmen zur Separierung von Systemen und geschützten Umgebungen) weitere Schutzmaßnahmen erforderlich sind. | Artikel 09: Schutz und Prävention.(4) d). | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) b)., Artikel 12: Datenaufzeichnung (2) d). | relevant | |||||||
| R.2600.011 | C.2600.003 | Der Einsatz von Software (inklusive TIAs) kann nur im Rahmen des regulären Änderungsprozesses erfolgen. | SBK 1 | 1. Es darf ausschließlich durch das Unternehmen freigegebene Software installiert werden. | Artikel 11: Daten- und Systemsicherheit (2) c). | relevant | ||||||||
| R.2600.012 | C.2600.003 | Der Einsatz von Software (inklusive TIAs) kann nur im Rahmen des regulären Änderungsprozesses erfolgen. | SBK 1 | 2. Es ist technisch zu unterbinden und zu untersagen, dass Nutzer eigenmächtig Software auf den Systemen des Unternehmens installieren, ausführen oder einbringen. | Artikel 11: Daten- und Systemsicherheit (2) c). | relevant | ||||||||
| R.2600.013 | C.2600.003 | Der Einsatz von Software (inklusive TIAs) kann nur im Rahmen des regulären Änderungsprozesses erfolgen. | SBK 1 | 3. Jede anfallende Installation (inkl. Installationen durch externes Wartungs- und Servicepersonal) muss über den geregelten Change-Prozess erfolgen. | Artikel 11: Daten- und Systemsicherheit (2) c). | relevant | ||||||||
| R.2600.015 | C.2600.003 | Der Einsatz von Software (inklusive TIAs) kann nur im Rahmen des regulären Änderungsprozesses erfolgen. | SBK 1 | 4. Nicht genehmigte Installationen, Ausführen oder Einbringen von Software auf den Systemen des Unternehmens sind dem Security Incident Management zu melden. | Artikel 11: Daten- und Systemsicherheit (2) c). | relevant | ||||||||
| R.2600.025 | C.2600.003 | Der Einsatz von Software (inklusive TIAs) kann nur im Rahmen des regulären Änderungsprozesses erfolgen. | SBK 1 | 5. Eigenentwicklungen im Rahmen von TIA müssen vom entwickelnden Fachbereich an eine zentrale Stelle in der IT gemeldet werden. | Artikel 11: Daten- und Systemsicherheit (2) c). | relevant | ||||||||
| 30 | R.2700 – Mobile Endgeräte | |||||||||||||
| R.2700.001 | C.2700.001 | Verfahren zur Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten stellen die Einhaltung eines angemessenen Sicherheitsniveaus auch bei Nutzung von mobilen Endgeräten sicher | SBK 1 | 1. Die Anforderungen und Prozesse bei einer Nutzung von mobilen Endgeräten müssen dokumentiert sein. Hierbei sind die folgenden Aspekte zu beachten: a) Zentrales Mobile Device Management (MDM) b) Handhabung und Schutz geschäftlicher Daten auf mobilen Endgeräten c) Zugangs- und Zugriffsschutz d) Verschlüsselung e) Remote Wipe f) Entsorgung g) Handhabung von Sicherheitsverstößen | Artikel 11: Daten- und Systemsicherheit (2) c)., Artikel 11: Daten- und Systemsicherheit (2) e)., Artikel 11: Daten- und Systemsicherheit (2) f)., Artikel 11: Daten- und Systemsicherheit (2) f) i), Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 11: Daten- und Systemsicherheit (2) i)., Artikel 11: Daten- und Systemsicherheit (2) j). | relevant | ||||||||
| R.2700.003 | C.2700.001 | Verfahren zur Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten stellen die Einhaltung eines angemessenen Sicherheitsniveaus auch bei Nutzung von mobilen Endgeräten sicher | SBK 1 | 2. Grundsätzlich ist nur die Nutzung dienstlich bereitgestellter Endgeräte zulässig. Die Nutzung von privaten mobilen Endgeräten ist unter Risikogesichtspunkten zu bewerten und separat zu entscheiden. Sofern die Nutzung von privaten mobilen Endgeräten erlaubt wird, sind mindestens folgende Punkte zu regeln a) Schriftliche Vereinbarung zur Nutzung privater Endgeräte b) Prüfung des einzusetzenden Endgerätetyps für die Eignung der Nutzung und der Einhaltung der Sicherheitsvorgaben c) Einbindung in das MDM d) Strikte und dauerhafte Trennung von privaten und dienstlichen Daten e) Data Leakage Prevention f) Softwareaktualisierung | Artikel 11: Daten- und Systemsicherheit (2) f)., Artikel 11: Daten- und Systemsicherheit (2) f) i), Artikel 11: Daten- und Systemsicherheit (2) f) ii), Artikel 11: Daten- und Systemsicherheit (2) i)., Artikel 11: Daten- und Systemsicherheit (2) j). | relevant | ||||||||
| R.2700.004 | C.2700.001 | Verfahren zur Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten stellen die Einhaltung eines angemessenen Sicherheitsniveaus auch bei Nutzung von mobilen Endgeräten sicher | SBK 1 | 3. Die Nutzer der mobilen Endgeräte sind auf die Einhaltung der Anforderungen zu verpflichten. Folgende Punkte sind mindestens zu regeln und vor dem Erhalt des mobilen Endgeräts durch den Mitarbeiter zu bestätigen: a) Sicht- und Zugriffschutz b) Meldung bei Verlust c) Private Nutzung | relevant | |||||||||
| R.2700.006 | C.2700.001 | Verfahren zur Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten stellen die Einhaltung eines angemessenen Sicherheitsniveaus auch bei Nutzung von mobilen Endgeräten sicher | SBK 2 | 1. Speichermedien von allen mobilen Endgeräten (z. B. Notebooks, Laptops, Smartphones) sind zu verschlüsseln. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2700.007 | C.2700.001 | Verfahren zur Ausgabe, Nutzung und Rückgabe von mobilen Endgeräten stellen die Einhaltung eines angemessenen Sicherheitsniveaus auch bei Nutzung von mobilen Endgeräten sicher | SBK 3 | 1. Bevor eine Weitergabe bzw. Wiederverwendung oder Entsorgung von mobilen Endgeräten in Frage kommt, müssen sämtliche enthaltenen Daten durch eine zentrale Stelle sicher gelöscht oder unlesbar gemacht werden. | Artikel 11: Daten- und Systemsicherheit (2) g)., Artikel 11: Daten- und Systemsicherheit (2) h). | relevant | ||||||||
| 25 | R.2800 - Sicherheit von Geräten und Betriebsmitteln | |||||||||||||
| R.2800.001 | C.2800.001 | Regelmäßige Service- und Wartungsmaßnahmen stellen sicher, dass Geräte und Betriebsmittel funktionsfähig und auf aktuellem Stand sind. | SBK 1 | 1. Die Instandhaltung von Geräten und Betriebsmitteln hat gemäß den Serviceintervallen und Spezifikationen des Herstellers durch autorisiertes Personal zu erfolgen. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | relevant | ||||||||
| R.2800.030 | C.2800.001 | Regelmäßige Service- und Wartungsmaßnahmen stellen sicher, dass Geräte und Betriebsmittel funktionsfähig und auf aktuellem Stand sind. | SBK 1 | 2. Die jeweiligen Serviceintervalle und Spezifikationen sind nachvollziehbar zu dokumentieren und zu pflegen. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | relevant | ||||||||
| R.2800.031 | C.2800.001 | Regelmäßige Service- und Wartungsmaßnahmen stellen sicher, dass Geräte und Betriebsmittel funktionsfähig und auf aktuellem Stand sind. | SBK 1 | 3. Durchgeführte Wartungs- und Reparaturarbeiten müssen nachweislich dokumentiert werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) c)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | relevant | ||||||||
| R.2800.006 | C.2800.001 | Regelmäßige Service- und Wartungsmaßnahmen stellen sicher, dass Geräte und Betriebsmittel funktionsfähig und auf aktuellem Stand sind. | SBK 3 | 1. Vertrauliche Informationen sind vor externer Wartung (z. B. bei Einsenden einer defekten Komponente an den Hersteller) von den Geräten und Betriebsmitteln zu entfernen. _x0007_ | relevant | |||||||||
| R.2800.009 | C.2800.002 | Die Mitnahme von Geräten, Betriebsmitteln und Dokumenten ist nur in spezifischen Fällen für betriebliche Zwecke gestattet. | SBK 1 | 1. Die Mitnahme von Geräten, Betriebsmitteln und Dokumenten vom Unternehmensstandort ist ausschließlich für betriebliche Zwecke zugelassen. | relevant | |||||||||
| R.2800.014 | C.2800.003 | Geräte und Betriebsmittel, die sich außerhalb des Unternehmens befinden, werden gesondert geschützt. | SBK 2 | 1. Alle Geräte und Betriebsmittel, die das Unternehmensgelände verlassen, sind in der Öffentlichkeit zu schützen, z. B. gegen Verlust oder unbefugte Einsichtnahme. | Artikel 11: Daten- und Systemsicherheit (2) f) ii) | relevant | ||||||||
| R.2800.032 | C.2800.003 | Geräte und Betriebsmittel, die sich außerhalb des Unternehmens befinden, werden gesondert geschützt. | SBK 2 | 2. Maßnahmen für Bereiche außerhalb des Betriebsgeländes wie mobiles Arbeiten und temporäre Standorte (z. B. abschließbare Aktenschränke, Grundsatz des aufgeräumten Schreibtisches, Zugriffskontrollen für Computer und sichere Kommunikation mit dem Büro) sind zu definieren. | relevant | |||||||||
| R.2800.033 | C.2800.003 | Geräte und Betriebsmittel, die sich außerhalb des Unternehmens befinden, werden gesondert geschützt. | SBK 2 | 3. Geräte und Betriebsmittel dürfen nur für Wartungszwecke weitergegeben werden. | relevant | |||||||||
| R.2800.017 | C.2800.004 | Nicht mehr benötigte Geräte und Betriebsmittel, die Datenträger enthalten, werden so entsorgt, dass die sich darauf befindlichen Daten nicht unbefugt genutzt werden können. | SBK 1 | 1. Alle Geräte und Betriebsmittel die Datenträger enthalten (im Folgenden „Datenträger“), auf denen Informationen gespeichert sind/waren, sind über einen definierten Prozess unter Berücksichtigung des Schutzbedarfs und den gelten gesetzlichen Anforderungen (z.B. Datenschutzrecht) zu entsorgen. Dabei müssen folgende Punkte geregelt sein: a) Sichere Entsorgung der Datenträger im Unternehmen b) Dokumentation der Entsorgung c) Meldung des Verlusts von Datenträgern vor oder während des Entsorgungsprozesses u. a. an den Datenschutzbeauftragten d) Sichere Aufbewahrung der Datenträger bis zur Vernichtung e) Entsorgung der Datenträger durch einen externen Dienstleister | Artikel 11: Daten- und Systemsicherheit (2) g)., Artikel 11: Daten- und Systemsicherheit (2) h). | relevant | ||||||||
| R.2800.019 | C.2800.004 | Datenträger sowie nicht mehr benötigte Geräte und Betriebsmittel, die Datenträger enthalten, werden so entsorgt, dass die sich darauf befindlichen Daten nicht unbefugt genutzt werden können. | SBK 1 | 2. Sollte der Schutzbedarf von Informationen auf einem Datenträger unbekannt sein bzw. keine Klassifizierung vorliegen, so muss dieser gemäß den Anforderungen der SBK 4 behandelt werden. | relevant | |||||||||
| R.2800.020 | C.2800.004 | Datenträger sowie nicht mehr benötigte Geräte und Betriebsmittel, die Datenträger enthalten, werden so entsorgt, dass die sich darauf befindlichen Daten nicht unbefugt genutzt werden können. | SBK 2 | 1. Sobald die Informationen auf wiederbeschreibbaren mobilen Datenträgern nicht mehr benötigt werden, müssen diese umgehend sicher gelöscht werden. Kann ein Datenträger nicht entsprechend dieser Vorgaben gelöscht werden, darf er nicht wiederverwendet oder weitergegeben werden und muss sicher entsorgt werden. _x0007_ | Artikel 11: Daten- und Systemsicherheit (2) g)., Artikel 11: Daten- und Systemsicherheit (2) h). | relevant | ||||||||
| R.2800.021 | C.2800.004 | Datenträger sowie nicht mehr benötigte Geräte und Betriebsmittel, die Datenträger enthalten, werden so entsorgt, dass die sich darauf befindlichen Daten nicht unbefugt genutzt werden können. | SBK 2 | 2. Grundlage für die Entsorgung von Datenträgern bzw. Löschung der enthaltenen Informationen ist die Art und Beschaffenheit des Datenträgers sowie der Schutzbedarf der jeweiligen Information. Die Klassifizierung der Information muss bei der Entsorgung von Datenträgern berücksichtigt werden. | Artikel 11: Daten- und Systemsicherheit (2) g)., Artikel 11: Daten- und Systemsicherheit (2) h). | relevant | ||||||||
| R.2800.022 | C.2800.004 | Datenträger sowie nicht mehr benötigte Geräte und Betriebsmittel, die Datenträger enthalten, werden so entsorgt, dass die sich darauf befindlichen Daten nicht unbefugt genutzt werden können. | SBK 2 | 3. Die Entsorgung von Datenträgern muss sicher und vollständig erfolgen (z. B. durch ein zertifiziertes Löschverfahren oder Zerstörung). Das Löschen von Informationen auf Datenträgern muss mit geeigneten Löschtechniken erfolgen, die dem aktuellen Stand der Technik entsprechen. Sofern Datenträger nicht intern vernichtet werden, ist die Entsorgung durch ein geeignetes (zertifiziertes) Entsorgungsunternehmen zu gewährleisten und zu dokumentieren. | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | relevant | ||||||||
| R.2800.034 | C.2800.005 | Informationen auf Datenträgern sind angemessen geschützt. | SBK 1 | 1. Es ist zu regeln, wie mit Datenträgern unter Berücksichtigung des Schutzbedarfs umzugehen ist. Dabei sind mindestens folgende Aspekte zu berücksichtigen: a) Zugelassene Datenträger/Datenträgertypen b) Zugelassene Schnittstellen zum Verbinden mit Datenträgern c) Protokollierung der Übertragung von Informationen bei freigegebenen Schnittstellen d) Lebenszyklen von Datenträgern (inkl. sichere Löschung) und Datenübertragung vor Ende des Lebenszyklus e) Wiederverwendung von Datenträgern (u. a. mehrfaches Überschreiben / formatieren) f) Sichere Aufbewahrung von Datenträgern g) Verschlüsselung der Datenträger | Artikel 11: Daten- und Systemsicherheit (2) e). | relevant | ||||||||
| R.2800.035 | C.2800.005 | Informationen auf Datenträgern sind angemessen geschützt. | SBK 1 | 2. Eine Genehmigung bzw. Freigabe zur Verwendung von Wechseldatenträgern darf nur nach Abwägung der Risiken und positiver Risikobewertung erfolgen, d. h. die im Unternehmen festgelegte Risikotoleranzschwelle darf durch die Verwendung des Wechseldatenträgers nicht überschritten werden. | Artikel 11: Daten- und Systemsicherheit (2) f) iii) | relevant | ||||||||
| R.2800.036 | C.2800.005 | Informationen auf Datenträgern sind angemessen geschützt. | SBK 2 | 1. Wechseldatenträger müssen verschlüsselt werden. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2800.044 | C.2800.005 | Informationen auf Datenträgern sind angemessen geschützt. | SBK 3 | 1. Die auf Datenträger gespeicherten Daten oder die Datenträger selbst, die im Anwendungsbereich der Regulierung "NYC RR 500" liegen, müssen verschlüsselt sein. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2800.037 | C.2800.005 | Informationen auf Datenträgern sind angemessen geschützt. | SBK 4 | 1. Die auf den Datenträgern gespeicherten Daten sind zu verschlüsseln. Die Ablage muss in verschlüsselter Form oder in verschlüsselten Dateiablagen erfolgen. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2800.038 | C.2800.006 | Datenträger werden sicher transportiert. | SBK 1 | 1. Es ist zu regeln, wie unter Berücksichtigung des Schutzbedarfes der Austausch bzw. Transport von Datenträgern zu erfolgen hat. Dabei sind mindestens folgende Aspekte zu berücksichtigen: a) Verschlüsselung inkl. Schlüsselaustausch b) Vertragliche Regelungen bei wiederkehrendem Austausch bzw. Transport c) Sichere Verwahrung während des Transportes | relevant | |||||||||
| R.2800.039 | C.2800.006 | Datenträger werden sicher transportiert. | SBK 4 | 1. Der Versand oder Transport von physischen Datenträgern muss durch eigene Mitarbeiter oder über einen zuverlässigen Kurierdienst (z. B. nach ISO9001 zertifiziertes Unternehmen) erfolgen. | relevant | |||||||||
| R.2800.040 | C.2800.006 | Datenträger werden sicher transportiert. | SBK 4 | 2. Der Versand/Transport ist angemessen zu dokumentieren (u. a. transportierte Inhalte, Schutzmaßnahmen, Entgegennahme). | relevant | |||||||||
| R.2800.025 | C.2800.007 | Unbeaufsichtigte Geräte und Betriebsmittel sind vor unbefugtem Zugriff geschützt. | SBK 1 | 1. Beim Verlassen des Arbeitsplatzes sind dort verbleibende mobile Geräte und Betriebsmittel so zu sichern, dass eine unbefugte Nutzung oder ein Entwenden unterbunden wird. | relevant | |||||||||
| R.2800.026 | C.2800.007 | Unbeaufsichtigte Geräte und Betriebsmittel sind vor unbefugtem Zugriff geschützt. | SBK 2 | 1. Zum Schutz von unbeaufsichtigten Benutzergeräten sind geeignete technische Maßnahmen zu implementieren. Die eingebauten Speichermedien von am Arbeitsplatz befindlichen Personal Computern sind zu verschlüsseln. | Artikel 06: Verschlüsselung und kryptografische Kontrollen (2) a)., Artikel 12: Datenaufzeichnung (2) d). | relevant | ||||||||
| R.2800.041 | C.2800.007 | Unbeaufsichtigte Geräte und Betriebsmittel sind vor unbefugtem Zugriff geschützt. | SBK 2 | 2. Bei Benutzergeräten muss ein Sperrmechanismus aktiviert sein, der nach maximal 10 Minuten Inaktivität das Gerät automatisch sperrt. | relevant | |||||||||
| R.2800.029 | C.2800.008 | Die Arbeitsumgebung ist so gestaltet, dass kein unbefugter Zugriff auf Informationen möglich ist (Clear Desk & Clear Screen). | SBK 1 | 1. Die Anforderungen für eine aufgeräumte Arbeitsumgebung (Clear Desk) und Bildschirmsperren (Clear Screen) müssen definiert sein und umgesetzt werden. Hierbei sind insbesondere folgende Aspekte zu berücksichtigen: a) Schutzbedarfsgerechter Zugriffsschutz für Informationen sowohl auf Papier als auch in elektronischen Speichermedien b) Sperren von IT-Systemen und Terminals c) Drucken und Kopieren von vertraulichen oder streng vertraulichen Dokumenten | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) e)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) e) i), Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) e) ii) | relevant | ||||||||
| R.2800.042 | C.2800.009 | Für Telearbeit bzw. dem mobilen Arbeiten werden den Mitarbeitenden geeignete Betriebsmittel zur Verfügung gestellt. Die Mitarbeitenden sind für die einhergehenden Risiken und Themen der Informationssicherheit sensibilisiert. | SBK 1 | 1. Für die Telearbeit sowie dem mobilen Arbeiten sind den Mitarbeitenden Betriebsmittel unter Berücksichtigung der Sicherheitsanforderungen gemäß dem Schutzbedarf zur Verfügung gestellt. | Artikel 11: Daten- und Systemsicherheit (2) j). | relevant | ||||||||
| R.2800.043 | C.2800.009 | Für Telearbeit bzw. dem mobilen Arbeiten werden den Mitarbeitenden geeignete Betriebsmittel zur Verfügung gestellt. Die Mitarbeitenden sind für die einhergehenden Risiken und Themen der Informationssicherheit sensibilisiert. | SBK 1 | 2. Die Mitarbeitenden werden verpflichtet, unbefugten Dritten keinen Zugang zu Informationen oder Ressourcen des Unternehmens zu gestatten. Zudem müssen die Mitarbeitenden über Risiken zur Informationssicherheit im Kontext Telearbeit sowie des mobilen Arbeitens informiert und sensibilisiert werden. | relevant | |||||||||
| 26 | R.3000 - Beschaffung von Hard- und Software | |||||||||||||
| R.3000.001 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 1. Es ist ein dokumentierter Prozess für die Beschaffung von Anwendungen und IT-Systemen zu etablieren, um sicherzustellen, dass die einschlägigen Sicherheitsanforderungen an zu beschaffende Produkte bewertet und erfüllt werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -. | nicht relevant | ||||||||
| R.3000.003 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 2. Innerhalb des Prozesses für die Beschaffung von Anwendungen und IT-Systemen muss die Kompatibilität mit der aktuellen IT-Architektur, inklusive Update-Prozesse und Wartungsverfahren, geprüft und sichergestellt werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (2) -., Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -. | nicht relevant | ||||||||
| R.3000.004 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 3. Vereinbarungen zu Sicherheitsfunktionalitäten müssen vertraglich geregelt sein. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -. | nicht relevant | ||||||||
| R.3000.005 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 4. Die technischen Spezifikationen zur Erfüllung der Sicherheitsanforderungen müssen dokumentiert werden. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -. | nicht relevant | ||||||||
| R.3000.006 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 5. Identifizierbare Informationsrisiken aus vorgelagerten Lieferketten müssen berücksichtigt werden. | nicht relevant | |||||||||
| R.3000.007 | C.3000.001 | Ein dokumentierter Beschaffungsprozess ist etabliert, der gewährleistet, dass alle relevanten Sicherheitsanforderungen bewertet und erfüllt werden und, Sicherheits- und Vertragsaspekte geregelt sind. | SBK 1 | 6. Für die Anwendungen und IT-Systeme muss eine Unterstützung durch den Hersteller/Anbieter bestehen. | Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) i), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (1) b) ii), Artikel 16: Beschaffung, Entwicklung und Wartung von IKT-Systemen (4) -. | nicht relevant | ||||||||
| 27 | R.8000 - Physische Sicherheit | |||||||||||||
| R.8000.001 | C.8000.001 | Physische Sicherheitszonen sind in Abhängigkeit vom Schutzbedarf definiert und voneinander abgetrennt. | SBK 1 | 1. Standorte bzw. Gebäude sind in Sicherheitszonen (z. B. Außenbereich, Kontrollierter Innenbereich, Interner Bereich, Sicherheitsbereich) zu unterteilen. Ort und Sicherungsumfang der einzelnen Zonen sind von den Schutzbedarfsklassen der Assets abhängig, die sich dauerhaft in der jeweiligen Zone befinden. Der Schutzbedarf jeder Sicherheitszone ist in einem Sicherheitszonenkonzept zu dokumentieren. Das Zonenkonzept ist regelmäßig zu überprüfen. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | |||||||
| R.8000.003 | C.8000.001 | Physische Sicherheitszonen sind in Abhängigkeit vom Schutzbedarf definiert und voneinander abgetrennt. | SBK 1 | 2 .Übergänge von einer Sicherheitszone in eine Sicherheitszone mit höherem Schutzbedarf sind auf berechtigtes Personal zu beschränken und durch risikoorientiert festzulegende Zutrittssteuerungsmaßnahmen abzugrenzen und zu schützen. Zutritte sind zu protokollieren. | Artikel 09: Schutz und Prävention.(4) c). | nicht relevant | ||||||||
| R.8000.005 | C.8000.001 | Physische Sicherheitszonen sind in Abhängigkeit vom Schutzbedarf definiert und voneinander abgetrennt. | SBK 1 | 3. Bei der Ausgestaltung der physischen Sicherheitszonen sind sowohl aktuelle als auch zukünftige Anforderungen, die aus geplanten Projektvorhaben resultieren können, zu beachten. | Artikel 09: Schutz und Prävention.(4) c). | nicht relevant | ||||||||
| R.8000.006 | C.8000.001 | Physische Sicherheitszonen sind in Abhängigkeit vom Schutzbedarf definiert und voneinander abgetrennt. | SBK 2 | 4. Die Gebäudeaußenhaut (inkl. Fenster, Türen, Notausgängen, etc.) ist angemessen zum Schutzbedarf der direkt angrenzenden Sicherheitszonen gegen unbefugtes Eindringen zu schützen. | Artikel 09: Schutz und Prävention.(4) c). | nicht relevant | ||||||||
| R.8000.111 | C.8000.001 | Physische Sicherheitszonen sind in Abhängigkeit vom Schutzbedarf definiert und voneinander abgetrennt. | SBK 4 | 1. Räumlichkeiten / Bereiche dieser Schutzbedarfsklasse sind im Zonenkonzept als Sicherheitsbereiche auszuweisen. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | |||||||
| R.8000.097 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 1 | 1. Ein Zutrittskonzept muss vorhanden sein, dass sicherstellt, dass nur Mitarbeiter und berechtigte Dritte Zutritt zu den für sie autorisierten Bereichen erhalten. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | |||||||
| R.8000.098 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 1 | 2. Im Fall der Nutzung eines Zutrittskontrollsystems sind Verfahren und Techniken gemäß dem Stand der Technik einzusetzen. | Artikel 07: IKT-Systeme, -Protokolle und -Tools., Artikel 07: IKT-Systeme, -Protokolle und -Tools.a)., Artikel 09: Schutz und Prävention.(4) c)., Artikel 13: Lernprozesse und Weiterentwicklungen (7). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | |||||||
| R.8000.014 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 2 | 1. Externe, für die keine Zutrittsberechtigungen eingerichtet wurden (bspw. Gäste, Wartungstechniker) dürfen Zutritt nur durch zutrittsberechtigte Mitarbeiter erhalten und müssen kenntlich gemacht werden (z. B. durch einen Besucherausweis) | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b)., Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | |||||||
| R.8000.099 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 4 | 3. Der Zutritt zu Räumen / Bereichen muss mittels Zutrittskontrollsystem gesichert und protokolliert werden. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | |||||||
| R.8000.019 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 4 | 1. Externe, für die keine Zutrittsberechtigungen eingerichtet wurden (bspw. Gäste, Wartungstechniker) , sind zu beaufsichtigen. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b)., Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | |||||||
| R.8000.112 | C.8000.002 | Der Zutritt ist angemessen beschränkt. | SBK 4 | 2. Die Zugangsberechtigungen müssen so vergeben, verwaltet und überwacht werden, dass nur Personen mit zugeordneten Aufgaben (Funktionen) in diese Räume / Bereiche gelangen können. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | |||||||
| R.8000.101 | C.8000.003 | Die Gebäude werden risikoorientiert überwacht. | SBK 1 | 1. Für Gebäude sind risikoorientiert Überwachungsmaßnahmen zu implementieren, wie zum Beispiel der Einsatz von Wachpersonal, Alarmanlagen oder Video-Überwachungsanlagen. | Artikel 21: Zugangskontrolle.g) iii) | nicht relevant | ||||||||
| R.8000.100 | C.8000.003 | Die Gebäude werden risikoorientiert überwacht. | SBK 4 | 1. Wenn Außentüren und -fenster von Gebäuden öffentlich zugänglich sind, MUSS die Außenhaut des Gebäudes in eine Gefahrenmeldeanlage (GMA) integriert sein. | Artikel 21: Zugangskontrolle.g) iii) | nicht relevant | ||||||||
| R.8000.022 | C.8000.004 | Sicherheitsbereiche sind besonders geschützt. | SBK 3 | 1. Räume für den IT-Betrieb (z. B. Serverraum, Verteilerraum) dürfen nicht von außen einsehbar sein. | nicht relevant | |||||||||
| R.8000.024 | C.8000.005 | Maßnahmen zum Schutz der Standorte und Gebäude vor externen und umweltbedingten Gefährdungen sind definiert | SBK 1 | 1. Für die Infrastruktur- und Gebäudesicherheit werden Standorte und Gebäude im Rahmen einer Risikoanalyse hinsichtlich der relevanten aktuellen sowie zu erwartenden internen, externen und umweltbedingten Gefährdungen (u. a. Überschwemmung, Blitzschutz) bewertet und die identifizierten Risiken mit risikosenkenden Maßnahmen unter Berücksichtigung der physischen Sicherheitszonen unterlegt. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | ||||||||
| R.8000.034 | C.8000.006 | IT- und Technikräume sind gegen Brand/Feuer geschützt. | SBK 4 | 1. IT- und Technikräume sind gegen Brandausbruch und -ausbreitung abzusichern. | nicht relevant | |||||||||
| R.8000.054 | C.8000.007 | Externe dürfen in besonderen Sicherheitsbereichen nur befristet Zutritt erhalten. Bild-, Ton- und Videoaufnahmen sind dort nicht gestattet | SBK 4 | 1. Es muss sichergestellt werden, dass Externe, für die keine Zutrittsberechtigungen eingerichtet wurden (z.B. Techniker, Fremdpersonal), Zutritt nur befristet und nur in dem zur Erfüllung der Aufgaben notwendigen Maß erhalten. | nicht relevant | |||||||||
| R.8000.055 | C.8000.007 | Externe dürfen in besonderen Sicherheitsbereichen nur befristet Zutritt erhalten. Bild-, Ton- und Videoaufnahmen sind dort nicht gestattet | SBK 4 | 2. Das Anfertigen von Bild-, Ton- und Videoaufnahmen ist nicht zu gestatten. Hierunter sind nicht betrieblich notwendige Aktivitäten (z. B. Aufzeichnung von Handelsgesprächen) zu verstehen. | nicht relevant | |||||||||
| R.8000.056 | C.8000.008 | Anlieferungs- und Ladezonen müssen gesondert kontrolliert und überwacht werden | SBK 1 | 1. Zutrittspunkte wie Anlieferungs- und Ladezonen sowie andere Orte, über die sich nicht autorisierte Personen Zutritt zu den Betriebsgebäuden verschaffen könnten, müssen kontrolliert und von informationsverarbeitenden Einrichtungen isoliert werden. | nicht relevant | |||||||||
| R.8000.060 | C.8000.009 | Für die Informationssicherheit relevante Betriebsmittel sind vor physischen und umweltbezogenen Gefährdungen geschützt | SBK 1 | 1. Für die Informationssicherheit relevante Betriebsmittel (z. B. Rechner, Switches, Verkabelungen) sind risikoorientiert vor physischen und umweltbezogenen Gefährdungen (Ausspähen, Diebstahl, Feuer, Sprengstoff, Rauch, Wasser oder Ausfall der Wasserversorgung, Staub, Vibrationen, chemische Auswirkungen, Störungen der Stromversorgung und Telekommunikationseinrichtungen, elektromagnetische Strahlung, Temperatur, Luftfeuchtigkeit und Vandalismus, etc.) zu schützen. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) c). | nicht relevant | ||||||||
| R.8000.069 | C.8000.010 | Versorgungseinrichtungen werden angemessen betrieben, gewartet und überwacht sowie vor umweltbezogenen Gefährdungen geschützt | SBK 1 | 1. Versorgungseinrichtungen sind gemäß ihrer Spezifikationen zu betreiben, zu warten und hinsichtlich Ihrer Funktion und Kapazität zu überwachen. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | nicht relevant | ||||||||
| R.8000.102 | C.8000.010 | Versorgungseinrichtungen werden angemessen betrieben, gewartet und überwacht sowie vor umweltbezogenen Gefährdungen geschützt | SBK 1 | 2. Sie sind vor umweltbezogenen Gefährdungen zu schützen. | nicht relevant | |||||||||
| R.8000.075 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 1 | 1. IT-Räume sind im Zonenkonzept als Sicherheitsbereiche auszuweisen. | nicht relevant | |||||||||
| R.8000.103 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 1 | 2. Verteilerschränke sind verschlossen zu halten und dürfen nur von den autorisierten Personen geöffnet werden können. | nicht relevant | |||||||||
| R.8000.104 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 1 | 3. Flüssigkeitsführende Leitungen, ausgenommen von Klimatisierungseinrichtungen, müssen in IT-Räumen vermieden werden. | nicht relevant | |||||||||
| R.8000.105 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 1 | 4. Mögliche Brandlasten (u. a. Ersatzteile, Ersatzkabel, Verpackungen) dürfen nicht im IT-Raum gelagert werden. | nicht relevant | |||||||||
| R.8000.106 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 1 | 5. Eine Klimatisierungseinrichtung muss die Raumtemperatur und die Luftfeuchte innerhalb der für den Betrieb der IT-Komponenten angemessenen Toleranzgrenzen einhalten. | nicht relevant | |||||||||
| R.8000.107 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 3 | 1. Die Türen in IT-Räumen müssen einem Feuerwiderstand von mindestens 30 Minuten standhalten. | nicht relevant | |||||||||
| R.8000.108 | C.8000.011 | IT-Räume sind wie Sicherheitsbereiche geschützt | SBK 3 | 2. IT-Räume sowie IT-Systeme der Basis-Infrastruktur (z.B. aktive Netzwerktechnik, Serversysteme) müssen an einer unterbrechungsfreien Stromversorgung (USV) angeschlossen werden, so dass ein geordnetes Herunterfahren bei einem Stromausfall sichergestellt ist. | nicht relevant | |||||||||
| R.8000.109 | C.8000.012 | Die Verkabelung ist vor Unterbrechung, Störung und Beschädigung geschützt | SBK 1 | 2. Die Verkabelung darf nicht durch öffentlich zugängliche Bereiche geführt werden, wenn diese nicht angemessen geschützt sind. | nicht relevant | |||||||||
| R.8000.096 | C.8000.012 | Die Verkabelung ist vor Unterbrechung, Störung und Beschädigung geschützt | SBK 1 | 1. Die Telekommunikationsverkabelung, die Daten trägt oder Informationsdienste unterstützt, sowie die Stromverkabelung sind vor Unterbrechung, Störung oder Beschädigung zu schützen. | nicht relevant | |||||||||
| 28 | R.8100 - Rechenzentren | |||||||||||||
| R.8100.001 | C.8100.001 | Der Standort des Rechenzentrums wird auf etwaige geographische und nachbarliche Risiken überprüft und die Ergebnisse dokumentiert. Mindestabstände zu risikoreichen Einrichtungen/Lokationen und zu Ausweichrechenzentren sind gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert. | SBK 1 | 1. Der Standort des Rechenzentrums ist auf geographische und nachbarliche Risiken zu prüfen und das Ergebnis zu dokumentieren. Dabei sind mindestens folgende Aspekte zu berücksichtigen: a) Risiken durch Hochwasser b) Erdbeben und andere Formen von Naturkatastrophen c) Flugverkehr d) Explosionsgefährdungen e) Unruhen f) politische Risiken | nicht relevant | |||||||||
| R.8100.269 | C.8100.001 | Der Standort des Rechenzentrums wird auf etwaige geographische und nachbarliche Risiken überprüft und die Ergebnisse dokumentiert. Mindestabstände zu risikoreichen Einrichtungen/Lokationen und zu Ausweichrechenzentren sind gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert. | SBK 1 | 2. Es sind Mindestabstände zu risikoreichen Einrichtungen/Lokationen und zu Ausweichrechenzentren zu definieren, die sich an etablierte Standards zu RZ-Sicherheit halten. | nicht relevant | |||||||||
| R.8100.005 | C.8100.002 | Die Gebäudestruktur und Bauweise des Rechenzentrums erfolgen auf Basis etablierter Standards. | SBK 1 | 1. Für Gebäudestruktur und Bauweise des Rechenzentrums ist ein Konzept zu erstellen, dass auf Basis anerkannter Standards (z.B. DIN EN 50600, oder vergleichbar) die konkreten Vorgaben zu mindestens folgenden Themen definiert und dokumentiert: a) Ausgestaltung des Struktursystems des Gebäudes b) Schutz vor zum Ausfall führenden physischen Ereignissen c) Bauausführung und Feuerwiderstand der raumumfassenden Wände d) Redundanz der Gebäudezugänge, Sicherheitszonenkonzept e) EMV-Schutz, Außenwände der IT-Fläche f) Eignungsnachweise bezüglich Gebäudestatik g) Physische Barrieren h) Vermeidung äußerlicher Hinweise auf RZ i) Parkplätze und Anlieferungsbereich | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) b). | nicht relevant | ||||||||
| R.8100.016 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 1 | 1. Sicherheitszonen (z. B. Außenbereich, kontrollierter Innenbereich, interner Bereich, Sicherheitsbereich) sind festzulegen und zu dokumentieren. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a). | nicht relevant | |||||||
| R.8100.270 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 1 | 2. Der Ort und Sicherungsumfang der verschiedenen Zonen muss unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse beurteilt werden. | nicht relevant | |||||||||
| R.8100.017 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 1 | 3. Exklusiv dem Unternehmen unterstehende Einrichtungen zur Informationsverarbeitung sind physisch von jenen Einrichtungen zu trennen, die von externen Parteien verwaltet werden. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a). | nicht relevant | |||||||
| R.8100.018 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 1 | 4. Die Zonen in einem Gebäude oder an einem Standort, in denen sich Einrichtungen zur Verarbeitung von Informationen befinden, sind physisch einwandfrei auszugestalten. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a). | nicht relevant | |||||||
| R.8100.019 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 1 | 5. Alle Außentüren sind ausreichend mit Hilfe von Kontrollmechanismen (z. B. Schranken, Alarmvorrichtungen, Verriegelungen usw.) vor unbefugtem Zutritt zu schützen. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a). | nicht relevant | |||||||
| R.8100.021 | C.8100.003 | Sicherheitszonen sind unter Berücksichtigung der darin befindlichen Assets sowie der Ergebnisse einer Risikoanalyse auf Basis eines etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet. | SBK 3 | 1. Zur Sicherung des Werkgeländes sind zusätzlich Werkschutzmitarbeiter einzusetzen, die regelmäßige Rundgänge machen. | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a). | nicht relevant | |||||||
| R.8100.023 | C.8100.004 | Vorgänge an Anlieferungs- und Ladezonen werden kontrolliert und von informationsverarbeitenden Einrichtungen isoliert. | SBK 1 | 1. Zugangspunkte wie Anlieferungs- und Ladezonen sowie andere Punkte, über die sich nicht-autorisierte Personen Zutritt zu den Betriebsgebäuden verschaffen könnten, sind zu kontrollieren und von informationsverarbeitenden Einrichtungen zu isolieren, um nicht autorisierten Zugang zu verhindern. a) Der Zutritt zu einer Anlieferungs- und Ladezone von außerhalb des Gebäudes ist nur identifizierten und autorisierten Mitarbeitern zu ermöglichen; b) Die Anlieferungs- und Ladezone muss so beschaffen sein, dass Waren beladen und entladen werden können, ohne dass das Lieferpersonal Zutritt zu anderen Teilen des Gebäudes erhält; c) Die Außentüren einer Anlieferungs- und Ladezone müssen gesichert sein, wenn die Innentüren geöffnet sind; d) Eingehendes Material muss auf Auffälligkeiten (z. B. Manipulationen während des Transports) und eine Kennzeichnung auf Gefahrstoffe geprüft werden, bevor es aus der Anlieferungs- und Ladezone weitertransportiert wird. Sofern sich Anzeichen für Manipulationen finden, sind diese unverzüglich dem Sicherheitspersonal zu melden. e) Eingehendes Material muss beim Eingang am Standort registriert werden; f) Eingehende und ausgehende Lieferungen sind physisch zu trennen. | nicht relevant | |||||||||
| R.8100.027 | C.8100.005 | Anforderungen an Wartungszugänge, Zutrittswege und Zugänge für Telekommunikationsanbieter sowie die Kommunikation im Rechenzentrum sind nach einem etablierten Standard (z.B. DIN EN 50600, oder vergleichbar) konzeptionell geregelt. | SBK 1 | 1. Die Anforderungen an Wartungszugänge, Zutrittswege und Zugänge für Telekommunikationsanbieter sowie die Kommunikation im Rechenzentrum sind auf Basis von etablierten Standards konzeptionell zu regeln. Dabei sind mindestens folgende zu berücksichtigen: a) Redundanz, Verortung der Zutrittswege b) Redundanz der Versorgungssicherheit der Telekommunikationsanbieter c) Sicherstellung von unterschiedlichen Zuleitungen d) Sicherstellung ausreichender Abstand redundanter Leitungen e) Redundanz der Infrastruktur zum Betrieb des RZ f) Netzwerktopologie und Verkabelung g) Unterbrechungsfreie Stromversorgung | nicht relevant | |||||||||
| R.8100.043 | C.8100.006 | Anforderungen an den Rechnerraum, Horizontal Distribution Area (HDA) und Main Distribution Area (MDA) im Rechenzentrum sind auf Basis von etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) definiert. | SBK 1 | 1. Die Anforderungen an Rechnerräume, HDA und MDA im Rechenzentrum sind auf Basis von anerkannten Standards in einem Konzept zu definieren und dokumentieren. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) c). | nicht relevant | ||||||||
| R.8100.056 | C.8100.007 | Technikräume und Telekommunikationsräume sind nach etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) eingerichtet und werden gemäß dieser risikoorientiert überwacht. | SBK 1 | 1. Technikräume und Telekommunikationsräume sind nach etablierten Standards eingerichtet und werden gemäß dieser risikoorientiert überwacht. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) c). | nicht relevant | ||||||||
| R.8100.062 | C.8100.008 | Die Anforderungen an die Struktur der RZ Racks und Schränke sind auf Basis von etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) in einem Konzept definiert und dokumentiert. | SBK 1 | 1. Die Anforderungen an die Struktur der RZ Racks und Schränke sind auf Basis von etablierten Standards in einem Konzept zu definieren und dokumentieren. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) c). | nicht relevant | ||||||||
| R.8100.076 | C.8100.009 | Alarmvorrichtungen und Videoüberwachung sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) risikoorientiert eingerichtet. | SBK 1 | 1. Die Anforderungen an die Alarmvorrichtungen und Videoüberwachung sind auf Basis von etablierten Standards risikoorientiert in einem Konzept zu definieren und dokumentieren. | Artikel 21: Zugangskontrolle.g) iii) | nicht relevant | ||||||||
| R.8100.084 | C.8100.010 | Verfahren in Bezug auf Zutrittsregelungen inklusive angemessener Zutrittskontrollen sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und eingerichtet. | SBK 1 | 1. Die Zutrittsberechtigungen für Mitarbeiter, externe Mitarbeiter und Besucher müssen in einem geregelten Verfahren definiert werden. Auf Basis von etablierten Standards sind dabei folgende Aspekte in einem Konzept zu regeln: a) Besucherzutritt b) Vergabe, Entziehung und Rezertifizierung von Zutrittsberechtigungen/Zutrittskarten c) Protokollierung und Überwachung der Zutritte d) Umgang mit Schlüsseln e) Sicherheitsbereiche und Kontrollen zwischen ihnen f) Zutrittskontrollen zwischen unterschiedlichen Sicherheitsbereichen | Artikel 09: Schutz und Prävention.(4) c). | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) a)., Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | |||||||
| R.8100.109 | C.8100.011 | Arbeiten in Sicherheitsbereichen ist nach etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) geregelt. | SBK 1 | 1. Die Regeln für Arbeiten in Sicherheitsbereichen sind auf Basis von anerkannten Standards für mindestens folgende Aspekte festzulegen und zu dokumentieren: a) Aufenthalt in Sicherheitsbereichen b) Belehrung zu Verhaltensregeln c) Befristete Berechtigungen und dokumentierte Freigabe d) Begleitung von Fremdpersonal e) Umgang mit mitgeführten Gegenständen f) Anfertigen von Bild-/Ton-/Videoaufnahmen. | Artikel 21: Zugangskontrolle.g) i), Artikel 21: Zugangskontrolle.g) ii), Artikel 21: Zugangskontrolle.g) iii), Artikel 21: Zugangskontrolle.g) iv) | nicht relevant | ||||||||
| R.8100.120 | C.8100.012 | Anforderungen an Versorgungseinrichtungen sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert. | SBK 1 | 1. Die Anforderungen an Versorgungseinrichtungen (z. B. Elektrizität, Telekommunikation, Wasserversorgung, Gas, Abwasserkanäle, Belüftung und Klimatisierungseinrichtung) müssen nach etablierten Standards definiert werden. a) Sie müssen den Spezifikationen des Herstellers der Einrichtungen sowie den vor Ort geltenden gesetzlichen Vorschriften entsprechen; a) Sie müssen regelmäßig auf ihre ausreichende Auslegung hinsichtlich steigender geschäftlicher Anforderungen sowie ihrer Interaktion mit den anderen Versorgungseinrichtungen begutachtet werden; b) Sie müssen regelmäßig untersucht und geprüft werden, um ihre ordnungsgemäße Funktion sicherzustellen; c) Unter Risikogesichtspunkten ist zu entscheiden, ob sie mit Alarmvorrichtungen versehen werden, damit Fehlfunktionen schnell erkannt werden; d) Unter Risikogesichtspunkten ist zu entscheiden, ob mehrere Zuführungen über unterschiedliche Zuleitungswege eingerichtet werden; e) Die Notschalter und Notventile zur Abschaltung der Strom-, Wasser-, Gas- und anderer Versorgungseinrichtungen müssen sich in der Nähe der Notausgänge oder Geräteräume befinden. | nicht relevant | |||||||||
| R.8100.125 | C.8100.013 | Angemessene Maßnahmen für Blitzschutz/Erdung sind gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 1. Eine Konzeption des Blitzschutzes ist unter Berücksichtigung der geltenden Normen bzw. etablierter Standards zu entwickeln und zu implementieren, welches auch einen EMV-Schutz berücksichtigt. Dabei muss mindestens eine Risikobeurteilung, die Berücksichtigung baurechtlicher Besonderheiten und die Umsetzung eines mehrstufigen Schutzes beinhaltet sein. | nicht relevant | |||||||||
| R.8100.136 | C.8100.014 | Angemessene Maßnahmen zur Verhinderung von Wassereintritt sind gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) getroffen. | SBK 1 | 1. Anforderungen bzgl. flüssigkeitsführender Leitungen und der Gefährdung durch Wassereintritt (z. B. für Gefahrenmeldeanlage, Entwässerung und deren Kontrolle) sind auf Basis von etablierter Standards zu definieren und dokumentieren. | nicht relevant | |||||||||
| R.8100.145 | C.8100.015 | Angemessene Maßnahmen zum Brandschutz sind gemäß der geltenden Brandschutzregeln sowie etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 1. Es sind mindestens sämtliche standortrelevanten gesetzlichen, behördlichen und versicherungstechnischen Brandschutzregelungen einzuhalten. | nicht relevant | |||||||||
| R.8100.146 | C.8100.015 | Angemessene Maßnahmen zum Brandschutz sind gemäß der geltenden Brandschutzregeln sowie anerkannter Standards (z.B. DIN EN 50600, oder vergleichbar) etabliert. | SBK 1 | 2. Eine betriebliche Brandschutzorganisation ist zu etablieren und Mitarbeitern die brandschutztechnischen Zusammenhänge zu erläutern. | nicht relevant | |||||||||
| R.8100.147 | C.8100.015 | Angemessene Maßnahmen zum Brandschutz sind gemäß der geltenden Brandschutzregeln sowie anerkannter Standards (z.B. DIN EN 50600, oder vergleichbar) etabliert. | SBK 1 | 3. Die organisatorischen Regelungen und Pläne zum Brandschutz sind gemäß anerkannter Standards in die betrieblichen Abläufe zu integrieren. | nicht relevant | |||||||||
| R.8100.151 | C.8100.015 | Angemessene Maßnahmen zum Brandschutz sind gemäß der geltenden Brandschutzregeln sowie anerkannter Standards (z.B. DIN EN 50600, oder vergleichbar) etabliert. | SBK 1 | 4. Es ist eine flächendeckende Brandmeldeanlage nach dem Stand der Technik mit automatischen Brandmeldern zu installieren. | Artikel 13: Lernprozesse und Weiterentwicklungen (7). | nicht relevant | ||||||||
| R.8100.163 | C.8100.016 | Anforderungen an Kabel und Kabelstruktur, Kabelführung sowie Backboneverkabelung sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und entsprechende Maßnahmen umgesetzt. | SBK 1 | 1. Die Anforderungen an Kabel und Kabelstruktur sind auf Basis von etablierten Standards für mindestens folgende Aspekte zu dokumentieren: a) Kabelführung b) Luftzirkulation bei Überkopfverkabelungsschienen c) Kabeltypen und Brandschutzvorrichtungen d) Absicherung der Kabel in öffentlichen Bereichen e) Absicherung von Wartungsöffnungen, Kabeleinziehboxen und Spleißboxen. | nicht relevant | |||||||||
| R.8100.184 | C.8100.016 | Anforderungen an Kabel und Kabelstruktur, Kabelführung sowie Backboneverkabelung sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und entsprechende Maßnahmen umgesetzt. | SBK 1 | 2. Es muss eine getrennte Kabelführung von Strom- und Datenverkabelung, sowohl horizontal als auch vertikal (Abschirmung der jeweiligen Kabel oder eine Führung in getrennten Kabelkanälen) erfolgen, um Interferenzen zu verhindern. Dabei sind die verschiedenen Kabeltypen und Verkabelungssysteme bei der Definition und Dokumentation von Anforderungen an ein Trennungskonzept zu betrachten. | nicht relevant | |||||||||
| R.8100.193 | C.8100.016 | Anforderungen an Kabel und Kabelstruktur, Kabelführung sowie Backboneverkabelung sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und entsprechende Maßnahmen umgesetzt. | SBK 1 | 3. Die Anforderungen an die Backboneverkabelung sind auf Basis von anerkannten Standards in einem Konzept zu definieren und dokumentieren. | nicht relevant | |||||||||
| R.8100.201 | C.8100.017 | Anforderungen an die Klimatisierung sind auf Basis von etablierten Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und entsprechende Maßnahmen umgesetzt. | SBK 1 | 1. Anforderungen bzgl. des eingesetzten Klimatisierungssystems einer Einrichtung sind auf Basis von etablierten Standards zu definieren und dokumentieren. Dabei sind u. a. folgende Aspekte zu betrachten: a) Redundanz und Resilienz des Klimatisierungssystems b) Ausreichender Luftwechsel, Luftversorgung c) Redundante, ausfallgesicherte Stromverkabelung (inkl. USV, Generatoren) d) Ausreichende und auf Stromversorgung abgestimmte Kühlkapazität e) Umweltbedingungen, die den Betrieb beeinträchtigen können f) Anordnung der Serverschränke/Racks hinsichtlich Kühlung g) Isolierung der Kühlwasserkreisläufe | nicht relevant | |||||||||
| R.8100.217 | C.8100.018 | Anforderungen an Stromversorgung und USV sind auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) definiert und entsprechende Maßnahmen umgesetzt. | SBK 1 | 1. Anforderungen bzgl. der Stromversorgung und USV sind auf Basis von etablierten Standards zu definieren und dokumentieren. Dabei sind u. a. folgende Aspekte zu betrachten: a) Redundanz von Stromanbieter und Stromtrassen b) Redundante, getrennte Stromkreise für Geräteschränke und Stromkreise für anderweitige Gerätschaften c) Notstromversorgung (USV-Module, Generatoren) d) Wartungsarbeiten an Infrastruktur e) Test der Notstromversorgungsinfrastruktur f) Einsatz von PDUs g) Kraftstoffbevorratung h) Überwachung der Elemente der Stromversorgung i) Vertragliche Vereinbarung zu kontinuierlichen Kraftstofflieferungen | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | nicht relevant | ||||||||
| R.8100.243 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 1. Die Betriebsmittel sind so zu platzieren, dass ein nicht notwendiger Zutritt zu den Arbeitsbereichen verhindert wird. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) c). | nicht relevant | ||||||||
| R.8100.271 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 2. Es sind Maßnahmen zu ergreifen, um das Risiko möglicher physischer oder umweltbezogener Bedrohungen wie z. B. Diebstahl, Feuer, Sprengstoff, Rauch, Wasser (oder Ausfall der Wasserversorgung), Staub, Vibrationen, chemische Auswirkungen, Störungen der Stromversorgung und Telekommunikationseinrichtungen, elektromagnetische Strahlung und Vandalismus möglichst gering zu halten. | nicht relevant | |||||||||
| R.8100.272 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 3. Essen, Trinken und Rauchen in der Nähe von Einrichtungen zur Informationsverarbeitung ist nicht zulässig. | nicht relevant | |||||||||
| R.8100.273 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 4. Betriebseinrichtungen, in denen vertrauliche Informationen verarbeitet werden, sind so zu schützen, dass das Risiko von Informationsverlusten aufgrund elektromagnetischer Abstrahlung möglichst gering ist. | nicht relevant | |||||||||
| R.8100.244 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 2. Die Betriebsmittel sind entsprechend den empfohlenen Serviceintervallen und Spezifikationen des Lieferanten zu warten. | Artikel 18: Physische Sicherheit und Sicherheit vor Umweltereignissen (2) d). | nicht relevant | ||||||||
| R.8100.245 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 3. Reparaturen und Wartungsarbeiten sind ausschließlich von autorisierten Mitarbeitern durchzuführen. | nicht relevant | |||||||||
| R.8100.246 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 4. Alle vermuteten und tatsächlichen Fehler sowie alle vorbeugenden und Korrekturmaßnahmen sind zu dokumentieren. | nicht relevant | |||||||||
| R.8100.247 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 1 | 5. Vor der Wiederinbetriebnahme von Betriebsmitteln nach der Wartung sind diese zu untersuchen, um sicherzustellen, dass sie nicht manipuliert wurden und keine Fehlfunktionen zu befürchten sind. | nicht relevant | |||||||||
| R.8100.248 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 2 | 1. Einrichtungen zur Speicherung von Daten sind vor unberechtigtem Zutritt zu sichern. | nicht relevant | |||||||||
| R.8100.249 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 2 | 2. Der Standort von Einrichtungen zur Informationsverarbeitung ist sorgfältig zu wählen, um das Risiko zu verringern, dass nicht autorisierte Personen während der Verarbeitung Einblick in Informationen erhalten. | nicht relevant | |||||||||
| R.8100.250 | C.8100.019 | Es sind angemessene Maßnahmen zur Platzierung, Schutz und Instandhaltung von Betriebsmitteln gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt. | SBK 2 | 3. Informationen sind von den Betriebsmitteln zu entfernen, es sei denn, das Wartungspersonal benötigt die Unterlagen für die Wartungsarbeiten. | nicht relevant | |||||||||
| R.8100.253 | C.8100.020 | Die Dokumentation von Gebäudestruktur, Raumaufteilung und Gebäudetechnik ist aktuell und nachvollziehbar. | SBK 1 | 1. Gebäudestruktur, Raumaufteilung und Gebäudetechnik sind auf aktuellem Stand nachvollziehbar zu dokumentieren. | nicht relevant | |||||||||
| R.8100.257 | C.8100.021 | Ein Notfallkonzept ist auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt und wird regelmäßig getestet. | SBK 1 | 1. Um Schäden aus Störungen und Notfällen zu minimieren, ist ein Konzept zum Umgang mit Störungen und Notfällen auf Basis etablierter Standards zu erstellen und zu dokumentieren. Es muss mindestens Eskalationspläne, die auch die Kundenkommunikation abdecken, enthalten. | nicht relevant | |||||||||
| R.8100.258 | C.8100.021 | Ein Notfallkonzept ist auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt und wird regelmäßig getestet. | SBK 1 | 2. Notfallpläne und Eskalationspläne sind regelmäßig zu testen, Auftretende Störungen und Notfälle sowie die daraufhin eingeleiteten Maßnahmen zu dokumentieren. | nicht relevant | |||||||||
| R.8100.259 | C.8100.021 | Ein Notfallkonzept ist auf Basis etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) umgesetzt und wird regelmäßig getestet. | SBK 1 | 3. Zur Vermeidung von Störungen und Notfällen ist eine mindestens halbjährlich aktualisierte und dokumentierte Analyse bezüglich sogenannter single points of failure durchzuführen. Darin erkannte Probleme sind anhand angemessener Maßnahmen zu beheben. | nicht relevant | |||||||||
| R.8100.274 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 1 | 1. Ein Rechenzentrum muss mindestens gemäß einer N+1-Redundanz ausgelegt sein, um den Ausfall einer Komponente angemessen kompensieren zu können. | nicht relevant | |||||||||
| R.8100.275 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 1 | 2. Alle für den Betrieb essenziellen Komponenten müssen mindestens eine N+1-Redundanz aufweisen. | nicht relevant | |||||||||
| R.8100.265 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 3 | 1. Für das Erreichen der 2N Redundanz sind zwei komplette Einheiten, Module, Kommunikationswege oder Systeme bereit zu halten, die für ein Basis-System benötigt werden. | nicht relevant | |||||||||
| R.8100.266 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 3 | 2. Der Ausfall oder die Wartung von einer vollständigen Einheit, einem vollständigen Modul, Kommunikationsweg oder System darf nicht zu einem operativen Ausfall führen. | nicht relevant | |||||||||
| R.8100.267 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 3 | 3. Das Rechenzentrum muss beliebige geplante Arbeiten an der Infrastruktur ermöglichen, ohne den Betrieb der Rechner Hardware in irgendeiner Weise zu beeinträchtigen. | nicht relevant | |||||||||
| R.8100.268 | C.8100.022 | Das Rechenzentrum ist redundant gemäß etablierter Standards (z.B. DIN EN 50600, oder vergleichbar) ausgelegt. | SBK 3 | 4. Ausreichende Kapazitäten und deren Verteilung sind zu gewährleisten, um gleichzeitig die Last auf einem Versorgungspfad zu bewältigen während der andere Pfad gewartet oder getestet wird. | nicht relevant |