Worum geht es?
Ähnlich wie im Kapitel 8.26 geht es auch hier im Kapitel 8.27 der ISO 27002 um die aus Sicht der Informationssicherheit zu beachtenden Gesichtspunkte bei Entwicklung und Betrieb. Hier jedoch geht es nicht mehr darum, allgemeingültige Grundsätze zu finden, sondern solche für konkrete Vorhaben bzw. bestimmte Systeme.
Entscheidend ist, dass neben dem Blick auf die reine Funktionalität von Systemen von vornherein auch darauf geachtet wird, dass diese von Anfang an sicher konzipiert, implementiert und betrieben werden. Schwachstellen sollen von Beginn an vermieden und nicht im Nachhinein beseitigt werden; erst recht nicht, wenn bereits Sicherheitsvorfälle aufgetreten sind.
Was empfiehlt die ISO 27002?
Die Ratschläge der Norm zielen in Kapitel 8.27 darauf, dass die einzelnen Systeme, Anwendungen und Softwareprodukte bereits sicher entwickelt werden und eben nach Möglichkeit nicht nachträglich gepatcht.
Erreicht werden soll dies durch die im folgenden beschriebenen Maßnahmen.
In einem ersten Schritt sollen die jeweils konkret beachtlichen Grundsätze definiert und für alle Beteiligten verbindlich dokumentiert werden. Diese Grundsätze müssen mit Blick auf bestehende Geschäftsanforderungen, verwendete Daten, eingesetzte Anwendungen und die vorgesehene Technologie bestimmt werden. Betrachtet werden muss das gesamte Spektrum an Sicherheitsmaßnahmen, welche erforderlich sind, um ausreichenden Schutz gegen mögliche Bedrohungen zu bieten, indem diese Bedrohungen möglichst verhindert, mindestens aber erkannt und gegebenenfalls abgewehrt werden.
Auch zu erörtern sind möglicherweise besondere Maßnahmen, die notwendig werden, weil für bestimmte Geschäftsprozesse spezifische Anforderungen an die Vertraulichkeit (z.B. starke Verschlüsselung), die Qualität der Informationen (z.B. Validierung, Aktualität, Integrität), oder die Anwendungen (z.B. sichere Authentifizierung, least privilege) und die eingesetzte Technologie (z.B. Härtung, sichere Infrastruktur, Containerisierung) bestehen.
Neue Systeme müssen sich in eine bestehende Sicherheitsarchitektur integrieren lassen. Zudem muss die gegebenenfalls weiter nötige technische Infrastruktur bereitstehen und mit dem neuen System kompatibel sein, um beispielsweise die Identität- und Zugangsverwaltung zu unterstützen oder eine PKI verwenden zu können.
Die Organisation muss schließlich auch in der Lage sein die gewählte Technologie nicht nur zu entwickeln, sondern auch laufend zu unterstützen. Hier muss der Blick auch auf die dazu erforderlichen Ressourcen gerichtet sein: Kosten, Zeit und Fachkunde.
Neben diesen allgemeinen Gedanken gibt die Norm aber auch sehr konkrete Hinweise zur Entwicklung sicherer Systeme:
- Anwendung von Grundsätzen der Sicherheitsarchitektur, insbesondere Sicherheit durch Gestaltung, tief gestaffelte Verteidigung, Sicherheit durch Voreinstellung, Standardmäßiges Ablehnen, sicherer Ausfallzustand, Misstrauen gegenüber Eingaben von externen Anwendungen, Sicherheit bei der Bereitstellung, Assume breach, least privilege, Benutzerfreundlichkeit und Handhabbarkeit und least functionality. Systeme sollen also beispielsweise mehrere Verteidigungsschichten besitzen, standardmäßig restriktiv eingerichtet sein und im Fehlerfall besser sicher ausfallen, anstatt unsicher weiter zu laufen. Es sollen auch nur Funktionen bereitgestellt werden, die wirklich notwendig sind und es werden nur Berechtigungen vergeben, die tatsächlich benötigt werden.
- Bereits Entwürfe sollen einer sicherheitsorientierten Prüfung unterzogen werden, um mögliche Schwachstellen zu ermitteln und geeignete Sicherheitsmaßnahmen zu ergreifen.
- Alle ergriffenen Sicherheitsmaßnahmen sollen dokumentiert werden. Solche Sicherheitsmaßnahmen, die bestehende Anforderungen nicht vollständig füllen, müssen förmlich bestätigt werden.
- Zur Abrundung erfolgt die Härtung der Systeme, die ohnehin selbstverständlich sein sollte.
Organisationen werden zudem ausdrücklich zu Zero-Trust aufgerufen: Traue niemand, misstraue allem, gehe von bereits laufenden Angriffen aus. Dies resultiert in den folgenden Einzelempfehlungen:
- Selbst das eigene interne Netzwerk ist nicht sicher.
- Anfragen erfolgen nur Ende-zu-Ende verschlüsselt.
- Jeder einzelne Zugang zu einem Informationssystem wird überprüft und behandelt, als käme er aus einem externen unsicheren Netz.
- Es werden nur die jeweils geringsten möglichen Privilegien verwendet.
- Die Steuerung des Zugangs erfolgt gegebenenfalls dynamisch und in Abhängigkeit vom Kontext, in dem der Zugang begehrt wird (z.B. worauf, von wem, von wo, mit welchem Gerät und zu welcher Zeit?)
- Die ggf. auch starke Authentisierung von Anfragenden erfolgt jedes Mal.
Wie in allen anderen Bereichen auch, muss immer sichergestellt werden, dass sämtliche Grundsätze auch verbindlich an externe Partner (z.B. Entwicklung, Implementierung, Betrieb) weitergegeben und von diesen nachvollziehbar beachtet werden.
Ebenfalls müssen die angestellten Überlegungen regelmäßig hinterfragt und erforderlichenfalls angepasst werden.
Fazit
Was in diesem Kapitel von der ISO 27002 vorgegeben wird, ist sehr schnell hochkomplex. Bereits die Beurteilung der Ausgangslage und die Definition der allgemeinen Grundlagen erfordern eine Fachkunde, die Organisationen möglicherweise nicht selbst besitzen. Für die korrekte tatsächliche Umsetzung gilt das gleiche.
Organisationen sollten daher schnellstmöglich prüfen, ob die eigenen Prozesse den beschriebenen Prinzipien entsprechend aufgestellt sind. Falls nicht, müssen die Lücken schnellstmöglich und erforderlichenfalls mit externer Unterstützung geschlossen werden.