Controls: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „Die deutsche Normfassung spricht hier in der dt. Fassung von <i>Maßnahmen</i>, es handelt sich aber um einzelne Sicherheitsanforderungen, die eine Organisatio…“) |
|||
| (11 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | Die deutsche Normfassung spricht hier in der dt. Fassung von <i>Maßnahmen</i>, es handelt sich aber um einzelne Sicherheitsanforderungen, die eine Organisation zu erfüllen hat. <b>Immer dann, wenn sie im geschäftlichen Umfeld relevant ist.</b> | + | Die deutsche Normfassung spricht hier in der dt. Fassung von <i>Maßnahmen</i>, es handelt sich aber um einzelne Sicherheitsanforderungen, die eine Organisation zu erfüllen hat. <b>Immer dann, wenn sie im geschäftlichen Umfeld relevant ist.</b><br> |
| + | Sollten Controls für meine Organisation irrelevant sein, so muss ich das zum Mindes begründen. <i>Vgl. Buch - Abschnitt 8.2</i><br> | ||
| + | Beispiele für solche Maßnahmen sind in der ISO27002 zu finden. Ggf. können auch die [[Kataloge des IT-Grundschutzes]] oder das [[Grundschutz-Kompendium]] verwendet werden.<br> | ||
| + | Streng genommen muss man die 114 Controls für jedes Asset aus der Inventarisierung abarbeiten. Das verursacht einen erheblichen Aufwand. | ||
| + | Hat man jedoch bei der Inventarisierung eine Hierarchie mit Top Level Assets und Ressourcen eingeführt, kann man die Vorgehensweise vereinfachen:<br> | ||
| + | Die Praxis hat gezeigt, dass es ausreicht, die Controls für die einzelnen Top Level Assets durchzuspielen - was fast immer eine überschaubare Liste darstellt.<br> | ||
| + | <br> | ||
| + | Die praktische Vorgehensweise sieht nun so aus, dass eine Tabelle erzeugt wird, in der in der ersten Spalte die 114 Controls eintragen werden und anschließend für jedes [[Top Level Asset]] eine weitere Spalte vorgesehen wird.<br> | ||
| + | Für jedes Top Level Asset und jedes Control wird dann eingetragen, ob das betreffende Control relevant ist: | ||
| + | * wenn nein: eine Begründung | ||
| + | * wenn ja: welche konkreten Maßnahmen (ggf. auch [[Optionen zur Risikobehandlung|Optionen]]) zur Umsetzung des Controls geplant oder bereits vorhanden sind<br> | ||
| + | Praxistipp: Statt alles in einer Tabelle zu vereinen, verweise auf Begründungen oder Maßnahmen in separaten Tabellen bzw. Tabellenblättern.<br> | ||
| + | >>Bei DIGITALPRINZIP separate Wiki-Seiten verwenden.<br><br> | ||
| + | Es können auch weitere Spalten für den [[Realisierungszustand der Maßnahmen|Realisierungszustand]] o.ä. hinzugefügt werden. Hieraus lassen sich auch [[Umsetzungs- und Prüfpläne]] generieren.<br><br> | ||
| + | Es kann sein, dass die Controls aus der Norm nicht alle [[Sicherheitsziele]] von DIGITALPRINZIP abdecken - es steht uns frei, auch weitere, eigene Controls hinzuzufügen.<br><br> | ||
| + | <b>Die Tabelle ist nach Fertigstellung der zentrale Baustein der [[Risikobehandlung]].</b><br> | ||
| + | <br> | ||
| + | Tipp: Für die geplanten Optionen oder Maßnahmen können auch Kosten geschätzt und in der Tabelle vermerkt werden. Das kann dann durch die Leitung genehmigt werden.<br> | ||
| + | <br> | ||
| + | Diese Zusammenfassung dieser Daten wird als [[Statement of Applicability (SoA)]] bezeichnet. | ||
| + | TODO | ||
Aktuelle Version vom 4. Februar 2021, 11:47 Uhr
Die deutsche Normfassung spricht hier in der dt. Fassung von Maßnahmen, es handelt sich aber um einzelne Sicherheitsanforderungen, die eine Organisation zu erfüllen hat. Immer dann, wenn sie im geschäftlichen Umfeld relevant ist.
Sollten Controls für meine Organisation irrelevant sein, so muss ich das zum Mindes begründen. Vgl. Buch - Abschnitt 8.2
Beispiele für solche Maßnahmen sind in der ISO27002 zu finden. Ggf. können auch die Kataloge des IT-Grundschutzes oder das Grundschutz-Kompendium verwendet werden.
Streng genommen muss man die 114 Controls für jedes Asset aus der Inventarisierung abarbeiten. Das verursacht einen erheblichen Aufwand.
Hat man jedoch bei der Inventarisierung eine Hierarchie mit Top Level Assets und Ressourcen eingeführt, kann man die Vorgehensweise vereinfachen:
Die Praxis hat gezeigt, dass es ausreicht, die Controls für die einzelnen Top Level Assets durchzuspielen - was fast immer eine überschaubare Liste darstellt.
Die praktische Vorgehensweise sieht nun so aus, dass eine Tabelle erzeugt wird, in der in der ersten Spalte die 114 Controls eintragen werden und anschließend für jedes Top Level Asset eine weitere Spalte vorgesehen wird.
Für jedes Top Level Asset und jedes Control wird dann eingetragen, ob das betreffende Control relevant ist:
- wenn nein: eine Begründung
- wenn ja: welche konkreten Maßnahmen (ggf. auch Optionen) zur Umsetzung des Controls geplant oder bereits vorhanden sind
Praxistipp: Statt alles in einer Tabelle zu vereinen, verweise auf Begründungen oder Maßnahmen in separaten Tabellen bzw. Tabellenblättern.
>>Bei DIGITALPRINZIP separate Wiki-Seiten verwenden.
Es können auch weitere Spalten für den Realisierungszustand o.ä. hinzugefügt werden. Hieraus lassen sich auch Umsetzungs- und Prüfpläne generieren.
Es kann sein, dass die Controls aus der Norm nicht alle Sicherheitsziele von DIGITALPRINZIP abdecken - es steht uns frei, auch weitere, eigene Controls hinzuzufügen.
Die Tabelle ist nach Fertigstellung der zentrale Baustein der Risikobehandlung.
Tipp: Für die geplanten Optionen oder Maßnahmen können auch Kosten geschätzt und in der Tabelle vermerkt werden. Das kann dann durch die Leitung genehmigt werden.
Diese Zusammenfassung dieser Daten wird als Statement of Applicability (SoA) bezeichnet.
TODO