+STM.2.1 Erstellung eines Anforderungspakets
---+STM.2.1.1 ISMS-Anforderungen
---+STM.2.1.2 Erfassung relevanter Assets
---+STM.2.1.3 Mapping der Assets auf Zielobjektkategorien
---+STM.2.1.4 Modellierung der Anforderungen mit Zielobjektkategorie
------+STM.2.1.4.1 Vererbung von Zielobjektkategorien
------+STM.2.1.4.2 Konsolidierung und Redundanzprüfung
---+STM.2.1.5 Modellierung der Anforderungen ohne Zielobjektkategorie
---+STM.2.1.6 Aufgrund anforderungsloser Assets
---+STM.2.1.7 Aufgrund externer Verpflichtungen
|
STM.2.1 Erstellung eines Anforderungspakets
Strukturmodellierung MUSS ein Anforderungspaket für den betrachteten Informationsverbund modellieren. Erläuterung Das Anforderungspaket enthält alle Anforderungen, die für den betrachteten Informationsverbund und den priorisierten Geschäftsprozess relevant sind. Diese stammen zum Großteil aus dem GS++, können jedoch bei Bedarf durch individuelle Anforderungen ergänzt werden. Diese Anforderung dient der grundsätzlichen Vorgabe ein Anforderungspaket zu erstellen. Weitere Details sind den folgenden Anforderungen dieser Praktik zu entnehmen.
1. Ħarsa ġenerali
| Titlu |
Standard |
|
STM.2.1.1 ISMS-Anforderungen
|
Strukturmodellierung MUSS alle Anforderungen der ISMS-Praktiken auf den vorliegenden Informationsverbund modellieren. Erläuterung Neben den zielobjektkategoriegebundenen Anforderungen enthält der GS++ auch Anforderungen ohne explizite Zuordnung zu Zielobjektkategorien. Diese werden im Anforderungspaket ergänzend berücksichtigt. Für die Anforderungen der ISMS-Praktiken (GC, STM, PERF, VRB, UMS) gilt dabei Folgendes: Die Anforderungen der ISMS-Praktiken sind übergreifend und keiner einzelnen Zielobjektkategorie zugewiesen. Sie bauen den PDCA-Zyklus des Managementsystems auf und gelten deshalb einmalig für den gesamten Informationsverbund. Alle Anforderungen der ISMS-Praktiken werden ohne weitere Selektion auf den Informationsverbund modelliert. Sie werden als „verbundweite Anforderungen“ im Anforderungspaket geführt, da sie Governance-, Steuerungs-, Kontroll- und Verbesserungsprozesse definieren.
|
|
STM.2.1.2 Erfassung relevanter Assets
|
Strukturmodellierung MUSS alle relevanten Assets für die betrachteten Geschäftsprozesse festlegen. Erläuterung Die Asset-Modellierung ist der zentrale Schritt, um den zuvor festgelegten Informationsverbund strukturiert und nachvollziehbar in sicherheitsrelevante Bestandteile zu zerlegen. Im ersten Durchgang des PDCA-Zyklus ist es ausreichend, die Assets zu erfassen, die für den wichtigsten Geschäftsprozess erforderlich sind. Weitere Geschäftsprozesse und zugehörige Assets können iterativ in nachfolgenden Zyklen oder parallel ergänzt werden. Relevante Assets können insbesondere Informationen, Systeme und Anwendungen (System Assets), Netz- und Kommunikationskomponenten, Infrastrukturelle und physische Assets, Personelle und organisatorische Assets. Für jedes Asset wird eine eindeutige Bezeichnung/ID, eine kurze Beschreibung und ihr Zweck sowie eine Zuordnung zu Geschäftsprozess(en) festgehalten. Zuletzt wird jedem Asset eine verantwortliche Rolle bzw. ein Asset-Owner zugewiesen. Ggfs. ist ebenfalls der Standort bzw. die logische Einordnung (Netz, Anwendungskontext etc.) des Assets festzuhalten. Abhängigkeiten zwischen Assets werden ebenfalls notiert.
|
|
STM.2.1.3 Mapping der Assets auf Zielobjektkategorien
|
Strukturmodellierung MUSS allen relevanten Assets eine oder mehrere Zielobjektkategorien zuweisen. Erläuterung Zielobjektkategorien sind standardisierte Klassen für die im GS++ beschriebenen Anforderungen. Durch das Mapping werden Assets damit in die Systematik des GS++ überführt. Für jedes Asset wird geprüft, welche Kategorie(n) seine Funktion und seinen Einsatz im Geschäftsprozess am besten abbilden. Die Zuordnung erfolgt funktionsorientiert, nicht nur nach technischen Merkmalen. Entscheidend ist, wie das Asset im Geschäftsprozess wirkt. Schwer zuordenbare Assets werden im Rahmen der Risikobetrachtung analysiert, um sicherzustellen, dass auch hierfür Anforderungen bzw. Maßnahmen abgeleitet werden können.
|
|
STM.2.1.4 Modellierung der Anforderungen mit Zielobjektkategorie
|
Strukturmodellierung MUSS die den Zielobjektkategorien zugehörigen Anforderungen auf die zugewiesenen Assets modellieren. Erläuterung Nun werden die Anforderungen aus dem GS++ auf die identifizierten Zielobjektkategorien modelliert. Die modellierten Anforderungen bilden das individuelle Anforderungspaket des festgelegten Informationsverbunds in Bezug auf den ausgewählten Geschäftsprozess.
|
|
STM.2.1.5 Modellierung der Anforderungen ohne Zielobjektkategorie
|
Strukturmodellierung MUSS alle weiteren Anforderungen denen keine Zielobjektkategorie zugeordnet ist modellieren. Erläuterung Für jede zielobjektkategorielose Anforderung in den vorliegenden Geschäftsprozessen ist eine Relevanzentscheidung vorzunehmen. Für jede Anforderung ohne Zielobjektkategorie wird entschieden, ob sie für den Geschäftsprozess bzw. die zugehörigen Assets erforderlich ist. Maßstab ist hier wiederum das Sicherheitsniveau sowie die konkrete Nutzung für den Geschäftsprozess. Daraufhin erfolgt eine Zuordnung auf die betroffenenen Geschäftsprozesse: Hierbei werden diese Anforderungen auch federführend zuständigen Personen oder Rollen (sog. Prozess-Owner) zugewiesen. Für die vorliegenden Geschäftsprozesse nicht relevante Anforderungen werden aus dem Anforderungspaket gestrichen, was mit einer Begründung zu dokumentieren ist, um Nachvollziehbarkeit bei einem späteren Audit bzw. Zertifizierung zu sichern.
|
|
STM.2.1.6 Aufgrund anforderungsloser Assets
|
Strukturmodellierung MUSS für Assets, für die es noch keine passenden GS++-Anforderungen gibt, zusätzliche Anforderungen dem Anforderungspaket zuweisen. Erläuterung Falls es für Assets oder Themen im GS++ derzeit noch keine Anforderungen gibt, können diese von der Institution erstellt werden. Möglicherweise befinden sich in der SdT-Bibliothek Anforderungen, die diese Lücke schließen können. Die Anforderungsmodellierung für Assets ohne Anforderungen umfasst folgende Schritte: Zuerst erfolgt die Identifikation und Dokumentation von Assets, für die es keine Anforderungen im Anforderungskatalog-GS++ gibt. Daraufhin ist nachvollziehbar zu begründen, warum die Anforderungen aus dem GS++ nicht ausreichen. Dann erfolgt (ggfs.) die Erstellung von neuen Anforderungen in Bezug auf die Schutzziele (Vertraulichkeit, Integrität und Verfügbarkeit), für diese Assets. Zuletzt wird das Anforderungspaket um die neuen Anforderungen erweitert. Im Ergebnis liegen individuelle und bedarfsgerechte Anforderungen für die Assets, für die der GS++ keine Anforderungen enthält, vor. Diese werden als fester Bestandteil in das Anforderungspaket integriert und dem BSI zugestellt. Zur Formulierung der Anforderungen ist die Durchführung einer Risikobetrachtung hinsichtlich ebendieser Assets hilfreich.
|
|
STM.2.1.7 Aufgrund externer Verpflichtungen
|
Strukturmodellierung MUSS für das individuelle Compliance-Umfeld der Institution zusätzliche Anforderungen dem Anforderungspaket zuweisen. Erläuterung Dieser Schritt ergänzt das Anforderungspaket, um Anforderungen, die sich aus dem individuellen Compliance-Umfeld der Institution ergeben. Die Integration von externen Compliance-Verpflichtungen stellt sicher, dass alle relevanten gesetzlichen und vertraglichen Pflichten berücksichtigt werden, die erfasst wurden. Hierzu zählen z.B. gesetzliche Verpflichtungen, welche die Verarbeitung von Informationen durch die Institution betreffen oder auch vertragliche Verpflichtungen mit Relevanz für die Informationsverarbeitung. Vor eigener Erstellung von Anforderungen empfiehlt sich ein Blick in die SdT-Bibliothek.
|
1.1 Referenzi
1.2 Rekwiżiti identifikati
1.3 Regolamenti relatati
2. Rekwiżiti identifikati
3. Regolamenti relatati
Regolamenti
| Sors |
Regolamentazzjoni |
|