ISO 27001 – Anhang A.14: Systembeschaffung, -entwicklung und -wartung

Was ist das Ziel von Anhang A.14.1?

Im Anhang A.14.1 geht es um Sicherheitsanforderungen an Informationssysteme. Das Ziel in diesem Anhang A-Bereich besteht darin, sicherzustellen, dass Informationssicherheit über den gesamten Lebenszyklus hinweg ein integraler Bestandteil von Informationssystemen ist. Dazu gehören auch Anforderungen an Informationssysteme, die Dienste über öffentliche Netze bereitstellen.

ISO 27001:2013 befasst sich mit dem Lebenszyklus von A.14.1.1 bis A.14.1.3 und ist ein wichtiger Bestandteil des Informationssicherheits-Managementsystems (ISMS), insbesondere wenn Sie eine ISO 27001-Zertifizierung erreichen möchten.

A.14.1.1 Analyse und Spezifikation der Informationssicherheitsanforderungen

Anforderungen an die Informationssicherheit müssen in alle Anforderungen für neue Informationssysteme oder Verbesserungen bestehender Informationssysteme einbezogen werden. Dies kann zusammen mit A.6.1.5 als Teil der Informationssicherheit in Projekten geschehen und sollte den Wert der gefährdeten Informationen berücksichtigen, der mit dem Informationsklassifizierungsschema in A.8.2.1 übereinstimmen könnte.

Bei jeder neuen Systementwicklung oder Änderung bestehender Systeme ist es wichtig, durch eine Risikobewertung zu verstehen, welche Geschäftsanforderungen an Sicherheitskontrollen bestehen. Dies sollte vor der Auswahl oder dem Beginn der Entwicklung einer Lösung erfolgen. Sicherheitsüberlegungen sollten so früh wie möglich erfolgen, um sicherzustellen, dass die richtigen Anforderungen identifiziert werden, bevor mit der Lösungsauswahl begonnen wird.

Die Sicherheitsanforderungen sollten dokumentiert und vereinbart werden, damit bei der Beschaffung oder Entwicklung der Lösung darauf Bezug genommen werden kann. Es ist keine gute Praxis, eine Lösung auszuwählen oder zu entwickeln und anschließend den Grad der Sicherheitsfähigkeit zu bewerten. Dies führt oft zu höheren Risiken und Kosten und kann auch zu Problemen bei der geltenden Gesetzgebung wie der DSGVO führen, die eine „Security by Design“-Philosophie und Techniken wie Datenschutz-Folgenabschätzungen (Data Protection Privacy Impact Assessments, DPIA) fördert. Es gibt auch zahlreiche Websites, die sich für sichere Entwicklungspraktiken und zu berücksichtigende Schlüsselprinzipien einsetzen, wie beispielsweise die vom National Cyber ​​Security Center (NCSC) befürworteten. ISO 27002 enthält auch Anleitungen zur Umsetzung. Alle befolgten Grundsätze sollten dokumentiert werden.

Der Prüfer wird darauf achten, dass die Sicherheit in allen Phasen eines Projektlebenszyklus berücksichtigt wird, sei es bei einem neuen System oder bei Änderungen an einem bestehenden System. Sie erwarten außerdem, dass vor Beginn des Auswahl- oder Entwicklungsprozesses mindestens Rücksicht auf Vertraulichkeit, Integrität und Verfügbarkeit genommen wird.

A.14.1.2 Sichern von Anwendungsdiensten in öffentlichen Netzwerken

Die Informationen, die bei der Übertragung von Anwendungsdiensten über öffentliche Netzwerke anfallen, müssen vor betrügerischen Aktivitäten, Vertragsstreitigkeiten und unbefugter Offenlegung und Änderung geschützt werden. Bei Diensten, die über ein öffentliches Netzwerk wie das Internet bereitgestellt werden, ist es wichtig, das damit verbundene Risikoniveau und die geschäftlichen Anforderungen zum Schutz von Informationen zu verstehen. Auch hier ist es wichtig, Vertraulichkeit, Integrität und Verfügbarkeit zu berücksichtigen.

Wenn Finanztransaktionen oder sensible persönliche Informationen Teil des Dienstes sind, ist es besonders wichtig, die Sicherheit zu berücksichtigen, um das Risiko betrügerischer Aktivitäten zu minimieren, wobei die DSGVO-Anforderungen für Verschlüsselung und andere Sicherheitsvorkehrungen die Mindestanforderungen sein müssen. Sobald diese Dienste betriebsbereit sind, muss sichergestellt werden, dass sie ständig auf Angriffe oder unerwünschte Aktivitäten überwacht werden. Der Prüfer erwartet, dass er Überlegungen dazu anstellt, „wie sicher“ Anwendungsdienste über öffentliche Netzwerke sein müssen, wobei Entscheidungen auf der Risikobewertung und anderen rechtlichen, behördlichen und vertraglichen Anforderungen basieren.

A.14.1.3 Schutz von Anwendungsdiensttransaktionen

Informationen, die an Anwendungsdiensttransaktionen beteiligt sind, müssen geschützt werden, um unvollständige Übertragung, Fehlleitung, unbefugte Nachrichtenänderung, unbefugte Offenlegung, unbefugte Vervielfältigung oder Wiedergabe von Nachrichten zu verhindern. Zusätzlicher Schutz dürfte Anwendungsdiensttransaktionen (nicht unbedingt nur Finanztransaktionen) absichern. Dazu können gehören: Verwendung elektronischer Signaturen, Verwendung von Verschlüsselung; und Verwendung sicherer Protokolle. Es dürfte auch erforderlich sein, solche Transaktionen fortlaufend und möglichst in Echtzeit zu überwachen.

Was ist das Ziel von Anhang A.14.2?

Im Anhang A.14.2 geht es um die Sicherheit in Entwicklungs- und Supportprozessen. Das Ziel in diesem Anhang A-Bereich besteht darin, sicherzustellen, dass Informationssicherheit innerhalb des Entwicklungslebenszyklus von Informationssystemen entworfen und umgesetzt wird.

A.14.2.1 Richtlinie für sichere Entwicklung

Regeln für die Entwicklung von Software und Systemen sollten festgelegt und auf Entwicklungen innerhalb der Organisation angewendet werden. Eine sichere Entwicklungsrichtlinie wird verwendet, um sicherzustellen, dass Entwicklungsumgebungen selbst sicher sind und dass die Prozesse zur Entwicklung und Implementierung von Systemen und Systemänderungen den Einsatz sicherer Codierungs- und Entwicklungspraktiken fördern.

Zu diesen Richtlinien gehört auch die Darstellung, wie Sicherheit in allen Phasen des Entwicklungslebenszyklus vom Entwurf bis zur Live-Implementierung berücksichtigt werden muss. Bestimmte Codierungssprachen und Entwicklungstools weisen unterschiedliche Schwachstellen auf und erfordern dementsprechend unterschiedliche „Härtungs“-Techniken. Es ist wichtig, dass diese identifiziert und vereinbart werden und Entwickler auf ihre Verantwortung aufmerksam gemacht werden, diese zu befolgen.

Kompatible Richtlinien berücksichtigen Sicherheitskontrollpunkte während der Entwicklung. sichere Repositorys; Sicherheit bei der Versionskontrolle; Kenntnisse im Bereich Anwendungssicherheit; und die Fähigkeit der Entwickler, Schwachstellen zu vermeiden und sie dann zu finden und zu beheben, wenn sie auftreten. Der Prüfer wird hier darauf achten, dass Sicherheitsüberlegungen dem Risikoniveau der zu entwickelnden oder geänderten Systeme angemessen sind und dass diejenigen, die die Entwicklung durchführen, die Notwendigkeit verstehen, Sicherheitsüberlegungen während des gesamten Entwicklungslebenszyklus einzubeziehen. Eine gründliche Erstauswahl bei der Einstellung dieser Fähigkeiten, Inlife-Management und Schulung der Ressourcen ist unerlässlich, und Praktiken wie Paarprogrammierung, Peer-Reviews und unabhängige Qualitätssicherung, Code-Reviews und Tests sind allesamt positive Eigenschaften.

A.14.2.2 Systemänderungskontrollverfahren

Änderungen an Systemen innerhalb des Entwicklungslebenszyklus müssen durch den Einsatz formaler Änderungskontrollverfahren kontrolliert werden. Verfahren zur Systemänderungskontrolle sollten in die betriebliche Änderungskontrolle integriert, darauf abgestimmt sein und diese unterstützen. Formelle Verfahren für das Änderungsmanagement sollen das Risiko einer versehentlichen oder absichtlichen Entwicklung von Schwachstellen verringern, die eine Kompromittierung von Systemen ermöglichen könnten, sobald die Änderungen in Kraft treten. Für die Kontrolle von Systemänderungen ist es wichtig, dass der Systembesitzer versteht, welche Änderungen an seinem System vorgenommen werden, warum und von wem. Es liegt in ihrer Verantwortung sicherzustellen, dass ihre Systeme nicht durch schlechte oder böswillige Entwicklung gefährdet werden.

Sie sollten daher in die Festlegung der Regeln für die Autorisierung sowie die Tests und Überprüfungen vor der Inbetriebnahme einbezogen werden. Audit-Protokolle sind erforderlich, um den Nachweis der korrekten Anwendung von Änderungsverfahren zu erbringen. ISO 27002 dokumentiert viele Aspekte der Änderungskontrolle, die einbezogen werden sollten, angefangen von der einfachen Dokumentation der Änderungen bis hin zur Berücksichtigung der Zeit für die Bereitstellung, um negative Auswirkungen auf das Unternehmen zu vermeiden. Diese Kontrolle steht wie andere in A.14 auch im Einklang mit den dokumentierten Verfahren in A.12.1.2.

A.14.2.3 Technische Überprüfung von Anwendungen nach Änderungen der Betriebsplattform

Wenn Betriebsplattformen geändert werden, müssen geschäftskritische Anwendungen überprüft und getestet werden, um sicherzustellen, dass es keine negativen Auswirkungen auf den Unternehmensbetrieb oder die Sicherheit gibt. Bei einem Wechsel der Betriebssystemplattform kommt es häufig zu Kompatibilitätsproblemen bei manchen Anwendungen. Daher ist es wichtig, Betriebssystemänderungen in einer Entwicklungs- oder Testumgebung zu testen, in der kritische Geschäftsanwendungen auf Kompatibilität mit dem geänderten Betriebssystem überprüft werden können. Verfahren zur Kontrolle und zum Testen von Betriebssystemänderungen sollten der Standardkontrolle des Änderungsmanagements folgen.

A.14.2.4 Einschränkungen bei Änderungen an Softwarepaketen

Von Änderungen an Softwarepaketen muss abgeraten werden, sie müssen auf notwendige Änderungen beschränkt werden und alle Änderungen sollten streng kontrolliert werden. Von Anbietern bereitgestellte Softwarepakete sind für den Massenmarkt konzipiert und nicht wirklich für Unternehmen gedacht, die eigene Änderungen daran vornehmen. Tatsächlich ist die Möglichkeit, solche Änderungen vorzunehmen, meist vom Anbieter gesperrt und die Anpassung auf das Paket beschränkt. Wenn Open-Source-Software verwendet wird, ist die Wahrscheinlichkeit, dass Änderungen von der Organisation vorgenommen werden können, weitaus größer. Dies sollte jedoch eingeschränkt und kontrolliert werden, um sicherzustellen, dass die vorgenommenen Änderungen keine negativen Auswirkungen auf die interne Integrität oder Sicherheit der Organisation haben Software.

A.14.2.5 Prinzipien der sicheren Systemtechnik

Grundsätze für die Entwicklung sicherer Systeme müssen festgelegt, dokumentiert, gepflegt und auf alle Bemühungen zur Implementierung von Informationssystemen angewendet werden. Sichere Software-Engineering-Grundsätze gibt es sowohl auf allgemeiner Ebene als auch spezifisch für Entwicklungsplattformen und Programmiersprachen. Wo immer eine Entwicklung durchgeführt wird, sollten Überlegungen zur Auswahl und Anwendung solcher Grundsätze in Betracht gezogen, bewertet, formell dokumentiert und vorgeschrieben werden. Der Prüfer möchte sicherstellen, dass, wie bei vielen anderen Kontrollen, die Anwendung systemtechnischer Grundsätze anhand der ermittelten Risikostufen berücksichtigt wird, und wird nach Beweisen suchen, die die getroffenen Entscheidungen untermauern.

A.14.2.6 Sichere Entwicklungsumgebung

Unternehmen müssen sichere Entwicklungsumgebungen für Systementwicklungs- und Integrationsbemühungen einrichten und angemessen schützen, die den gesamten Systementwicklungslebenszyklus abdecken. Entwicklungsumgebungen müssen geschützt werden, um die böswillige oder versehentliche Entwicklung und Aktualisierung von Code zu verhindern, die zu Schwachstellen führen oder die Vertraulichkeit, Integrität und Verfügbarkeit gefährden könnten. Schutzanforderungen sollten anhand von Risikobewertungen, Geschäftsanforderungen und anderen internen und externen Anforderungen, einschließlich Gesetzen, Vorschriften, vertraglichen Vereinbarungen oder Richtlinien, ermittelt werden. Insbesondere wenn Live-Daten jeglicher Art in Entwicklungsumgebungen verwendet werden, müssen diese besonders geschützt und kontrolliert werden.

A.14.2.7 Ausgelagerte Entwicklung

Die Organisation muss die Aktivitäten der ausgelagerten Systementwicklung überwachen und überwachen. Wenn die System- und Softwareentwicklung ganz oder teilweise an externe Parteien ausgelagert wird, müssen die Sicherheitsanforderungen in einem Vertrag oder einer beigefügten Vereinbarung festgelegt werden. Hier ist es wichtig, dass Anhang A 15.1 sowie A.13.2.4 zur Geheimhaltung und Vertraulichkeit korrekt sind.

Es ist auch wichtig, die Entwicklung zu überwachen und zu überwachen, um sicherzustellen, dass organisatorische Standards und Anforderungen an die Sicherheit innerhalb der Systeme erreicht werden. Je nachdem, wie stark die Outsourcing-Partner in der Organisation verankert sind, insbesondere wenn sich die Mitarbeiter auf dem Gelände der Organisation befinden, ist es wichtig, ihre Mitarbeiter in Schulungen und Sensibilisierungsprogramme und -kommunikationen für das Sicherheitsbewusstsein einzubeziehen. Es ist von entscheidender Bedeutung, sicherzustellen, dass die internen Sicherheitspraktiken des Outsourcing-Partners, z. B. Personalüberprüfungen, mindestens die Sicherheitsanforderungen erfüllen, die für die Risikostufen im Zusammenhang mit den Entwicklungen, an denen er arbeiten wird, relevant sind.

Der Prüfer wird darauf achten, dass beim Einsatz von Outsourcing vor, während und nach der Beauftragung des Outsourcing-Partners Nachweise für die gebotene Sorgfalt vorliegen und auch die Bestimmungen zur Informationssicherheit berücksichtigt werden.

A.14.2.8 Systemsicherheitstests

Das Testen der Sicherheitsfunktionalität muss während der Entwicklung durchgeführt werden. Spezifische Tests der Sicherheitsfunktionalität für jede Entwicklung müssen von einer zuständigen Behörde mit Sicherheitskompetenz und -verantwortung durchgeführt und genehmigt werden. Die erwarteten Ergebnisse von Sicherheitstests sollten vor Beginn des Tests dokumentiert werden und auf den geschäftlichen Sicherheitsanforderungen basieren. Der Prüfer möchte sehen, dass es Beweise dafür gibt, dass bei jeder sicherheitsrelevanten Entwicklung sicherheitsspezifische Tests durchgeführt wurden.

A.14.2.9 Systemabnahmetests

Für neue Informationssysteme, Upgrades und neue Versionen müssen Abnahmetestprogramme und zugehörige Kriterien festgelegt werden. Für Abnahmetests sollten die Tests und die Kriterien zum Nachweis eines erfolgreichen Tests auf der Grundlage der Geschäftsanforderungen entworfen und entwickelt werden, bevor die Tests durchgeführt werden. Abnahmetests sollten auch Sicherheitstests umfassen. Der Prüfer wird nach Beweisen suchen, die zeigen, dass die Kriterien und Methoden für Abnahmetests entsprechend den Geschäftsanforderungen entwickelt wurden und Bestimmungen für Sicherheitsabnahmetests enthalten.

Was ist das Ziel von Anhang A.14.3?

Im Anhang A.14.3 geht es um Testdaten. Das Ziel in diesem Anhang A-Bereich besteht darin, den Schutz der für Tests verwendeten Daten sicherzustellen.

A.14.3.1 Schutz von Testdaten

Testdaten müssen sorgfältig ausgewählt, geschützt und kontrolliert werden. Testdaten sollten idealerweise in einer generischen Form ohne Bezug zu Live-Systemdaten erstellt werden. Es ist jedoch anerkannt, dass für die Durchführung genauer Tests häufig Live-Daten verwendet werden müssen. Wenn Live-Daten zum Testen verwendet werden, sollte dies der Fall sein. Soweit möglich anonymisiert; Sorgfältig ausgewählt und für den Testzeitraum gesichert; Nach Abschluss des Tests sicher gelöscht. Die Nutzung von Live-Daten muss vorab autorisiert, protokolliert und überwacht werden. Der Prüfer erwartet, dass robuste Verfahren zum Schutz der in Testumgebungen verwendeten Daten vorhanden sind, insbesondere wenn es sich dabei ganz oder teilweise um Live-Daten handelt.

Weitere Hilfe zu den ISO 27001-Anforderungen und Annex A-Kontrollen finden Sie im ISMS.online Virtual Coach, der unsere Frameworks, Tools und Richtlinieninhalte ergänzt.