ISO 27001 - Anhang A.12: Operations -Sicherheit

Was ist das Ziel von Anhang A.12.1?

In Anhang A.12.1 geht es um betriebliche Abläufe und Verantwortlichkeiten. Das Ziel dieses Anhang-A-Bereichs besteht darin, den korrekten und sicheren Betrieb von Informationsverarbeitungsanlagen sicherzustellen. Es ist ein wichtiger Bestandteil des Informationssicherheits-Managementsystems (ISMS), insbesondere wenn Sie eine ISO 27001-Zertifizierung erreichen möchten. Lassen Sie uns diese Anforderungen und ihre Bedeutung nun etwas genauer verstehen.

A.12.1.1 Dokumentierte Betriebsabläufe

Betriebsabläufe müssen dokumentiert und dann allen Benutzern zur Verfügung gestellt werden, die sie benötigen. Dokumentierte Betriebsabläufe tragen dazu bei, einen konsistenten und effektiven Betrieb von Systemen für neue Mitarbeiter oder sich ändernde Ressourcen sicherzustellen, und können oft von entscheidender Bedeutung für die Notfallwiederherstellung, die Geschäftskontinuität und für den Fall sein, dass die Personalverfügbarkeit beeinträchtigt ist. Wenn Informationssysteme „cloudbasiert“ sind, verlieren traditionelle Betriebsaktivitäten wie das Starten, Herunterfahren, Sichern usw. des Systems an Bedeutung und werden häufig an einen Cloud-Anbieter ausgelagert. In traditionelleren Computerumgebungen und -architekturen sind mit größerer Wahrscheinlichkeit Betriebsabläufe erforderlich.

Es ist wichtig, dass die Dokumente in einem korrekten und aktuellen Zustand gehalten werden und daher einem formellen Änderungsmanagement und regelmäßigen Überprüfungsverfahren unterliegen – dies ist von entscheidender Bedeutung, da der Prüfer speziell darauf achten wird.

Wir werden oft gefragt, wie viele Details erforderlich sind und in welchen Unternehmensbereichen dokumentierte Verfahren erforderlich sind. Gehen Sie mit gesundem Menschenverstand vor. Wenn Sie beispielsweise über echte Personalstabilität verfügen, die impliziten Verfahren sehr gut verstanden sind und die Belastbarkeit im gesamten Ressourcenpool vorhanden ist, können einfache Aufzählungspunkte ausreichen, um ein dokumentiertes Verfahren im Checklistenstil zu erstellen.

Auch wenn sich Verfahren weiterentwickeln oder sich regelmäßig ändern, beispielsweise aufgrund eines schnellen Wachstums, möchten Sie über Verfahren verfügen, die ebenfalls einfach und schnell aktualisiert werden können. Wenn wiederum viele neue Ressourcen hinzugefügt werden und der Bereich mit Risiken und Komplexität behaftet ist, ist möglicherweise eine tiefere Ausarbeitung der Verfahren erforderlich, damit eindeutig festgelegt ist, was, wann, wie, wer usw.

Die Bereiche des Unternehmens, die für dokumentierte Verfahren in Betracht gezogen werden müssen, sollten dort liegen, wo Ihre Informationsbestände durch fehlerhafte Bedienung gefährdet sind, was selbstverständlich im Rahmen der Risikobewertung gemäß 6.1 identifiziert wird. Dies kann je nach Art des Unternehmens Softwareentwicklung, IT-Management, Finanzbuchhaltung, Kundenmanagement, Beratungs- oder Fertigungstätigkeiten usw. umfassen.

A.12.1.2 Änderungsmanagement

Die Organisation, Geschäftsabläufe, Informationsverarbeitungsanlagen und Systeme, die Auswirkungen auf die Informationssicherheit haben, müssen kontrolliert werden. In den meisten Umgebungen ist ein ordnungsgemäß kontrolliertes Änderungsmanagement unerlässlich, um sicherzustellen, dass Änderungen angemessen, wirksam, ordnungsgemäß genehmigt und so durchgeführt werden, dass die Möglichkeit einer böswilligen oder versehentlichen Kompromittierung minimiert wird. Das Änderungsmanagement gilt für die gesamte Organisation, ihre Prozesse, Informationsverarbeitungseinrichtungen, Netzwerke, Systeme und Anwendungen.

Audit-Protokolle sind erforderlich, um den Nachweis der korrekten Anwendung von Änderungsverfahren zu erbringen. Der Prüfer möchte darauf hinweisen, dass Änderungsverfahren nicht übermäßig kompliziert sein müssen, sondern der Art der in Betracht gezogenen Änderung angemessen sein müssen. Sie könnten einfach unterwegs Beweise für Ergänzungen und Versionskontrolländerungen erfassen oder ein viel tiefergehendes, komplexeres Änderungsmanagement durchführen und Umschulungen und Kommunikation einbeziehen sowie umfangreichere Investitions- und Genehmigungsprozesse durchführen.

A.12.1.3 Kapazitätsmanagement

Der Einsatz von Ressourcen muss überwacht und abgestimmt werden und es müssen Prognosen für zukünftige Kapazitätsanforderungen erstellt werden, um die erforderliche Systemleistung zum Erreichen der Geschäftsziele sicherzustellen. Beim Kapazitätsmanagement werden in der Regel drei Haupttypen berücksichtigt: Datenspeicherkapazität – (z. B. in Datenbanksystemen, Dateispeicherbereichen usw.); Verarbeitungsleistungskapazität – (z. B. ausreichende Rechenleistung, um zeitnahe Verarbeitungsvorgänge sicherzustellen); und Kommunikationskapazität – (oft als „Bandbreite“ bezeichnet, um sicherzustellen, dass die Kommunikation zeitnah erfolgt).

Auch das Kapazitätsmanagement muss sein; Proaktiv – zum Beispiel durch die Nutzung von Kapazitätsüberlegungen als Teil des Änderungsmanagements; Reaktiv – z. B. Auslöser und Warnungen, wenn die Kapazitätsauslastung einen kritischen Punkt erreicht, sodass rechtzeitig vorübergehende oder dauerhafte Erhöhungen vorgenommen werden können.

A.12.1.4 Trennung von Entwicklungs-, Test- und Betriebsumgebungen

Gute Richtlinien für Entwicklungs-, Test- und Betriebsumgebungen würden bestätigen, dass diese getrennt werden müssen, um das Risiko unbefugter Zugriffe oder Änderungen an der Betriebsumgebung zu verringern. Es empfiehlt sich, Entwicklungs-, Test- und Live-Betriebs-IT-Umgebungen getrennt zu halten, da dies zur Aufgabentrennung und zum unbefugten Zugriff auf die Live-Umgebung und Daten beiträgt. Änderungen und Neuentwicklungen sollten in einem separaten Bereich gründlich getestet werden, bevor sie in die Live-Betriebsumgebung übernommen werden.

Idealerweise sollte das Entwicklungspersonal keinen Zugriff auf die Live-Umgebung haben. Dies ist jedoch möglicherweise nicht möglich, insbesondere in kleinen Organisationen. Nach der Trennung ist es wichtig zu überprüfen, dass Tester die Testumgebungen nicht versehentlich (oder absichtlich) als Live-Umgebungen nutzen. Der Prüfer prüft, ob Entwicklungs-, Test- und Live-Umgebungen getrennt sind und ob es formelle Verfahren gibt, einschließlich angemessener Autorisierungsebenen für die Übertragung von Änderungen und Entwicklungen von einer Umgebung in eine andere.

Was ist das Ziel von Anhang A.12.2?

In Anhang A.12.2 geht es um den Schutz vor Schadsoftware. Ziel ist es, sicherzustellen, dass Informationen und Informationsverarbeitungsanlagen vor Schadsoftware geschützt sind.

A.12.2.1 Kontrollen gegen Malware

Es müssen Erkennungs-, Präventions- und Wiederherstellungskontrollen zum Schutz vor Malware implementiert werden, kombiniert mit einem entsprechenden Benutzerbewusstsein. Dies ist ein Abschnitt, für den die meisten Organisationen ein gewisses Maß an Bewusstsein, Verständnis und Umsetzung haben. Abgesehen von der offensichtlichen „Antivirensoftware“ kann der Malware-Schutz jedoch viele verschiedene Formen annehmen.

Auch andere Kontrollen wie Einschränkungen bei der Verwendung von Wechselmedien oder Einschränkungen bei der Installation von Software durch Benutzer, die dazu beitragen, die Verwendung nicht autorisierter Software zu verhindern, sind wertvoll. Das rechtzeitige Patchen bekannter System- und Softwareschwachstellen ist ebenfalls von entscheidender Bedeutung. Häufig sind Viren darauf ausgelegt, nach nicht gepatchten Systemen und Software zu suchen, in denen bekannte Schwachstellen bestehen könnten. Es ist wichtig, dass jeder Malware-Schutz auf dem neuesten Stand gehalten wird, sowohl in Bezug auf relevante „Signaturdateien“ als auch auf die Software selbst.

Was ist das Ziel von Anhang A.12.3?

In Anhang A.12.3 geht es um Backup. Ziel ist der Schutz vor Datenverlust.

A.12.3.1 Informationssicherung

Um die wertvollen Informationen vor Verlust zu schützen, beschreibt eine gute Kontrolle, wie Sicherungskopien von Informationen, Software und Systemabbildern erstellt und gemäß einer vereinbarten Sicherungsrichtlinie regelmäßig getestet werden.

Backup-Systeme müssen entsprechend den Geschäftsanforderungen und dem Risikoniveau im Zusammenhang mit der Nichtverfügbarkeit von Informationen entworfen werden. Daher ist es wichtig sicherzustellen, dass solche Systeme tatsächliche Bedürfnisse unterstützen und nicht nur „wir machen Backups“. Wenn Backups erstellt werden, sollten die Informationen mindestens auf dem gleichen Niveau wie die Live-Daten geschützt und außerhalb der Live-Umgebung gespeichert werden, um das Risiko zu minimieren, dass eine einzelne Kompromittierung sowohl die Live-Umgebung als auch die Backups lahmlegt.

Regelmäßige Tests von Backups sind von entscheidender Bedeutung, um sicherzustellen, dass Wiederherstellungen erfolgreich sind und zeitnah durchgeführt werden. Die Überwachung und Aufzeichnung von Backups sollte implementiert werden, um sicherzustellen, dass sie im Einklang mit der Backup-Richtlinie erfolgen. Kluge Prüfer möchten Berichte über fehlgeschlagene Backups und durchgeführte Tests sehen, um sicherzustellen, dass sie wie erwartet funktionieren. Es müssen Backup-Richtlinien in Bezug auf „Was“, „Woher“ und „Wohin“, „Wer“ und „Wann“ berücksichtigt werden – unter Berücksichtigung von Büro- und Heimarbeitern, Mobilgeräten usw., bei denen es Überlegungen zu mobilen und externen Speichersicherungen gibt, die im Falle eines möglichen Verlusts ein erhöhtes Risiko bergen durch Verschlüsselung oder andere Kontrollen angegangen werden.

Was ist das Ziel von Anhang A.12.4?

In Anhang A.12.4 geht es um Protokollierung und Überwachung. Das Ziel in diesem Anhang A-Bereich ist die Aufzeichnung von Ereignissen und die Generierung von Beweisen.

A.12.4.1 Ereignisprotokollierung

Ereignisprotokolle, die Benutzeraktivitäten, Ausnahmen, Fehler und Informationssicherheitsereignisse aufzeichnen, müssen regelmäßig erstellt, aufbewahrt und überprüft werden. Protokollierungs- und Überwachungsmechanismen sind ein wichtiger Bestandteil einer „Defense-in-Depth“-Strategie für das Sicherheitsmanagement, indem sie sowohl Detektiv- als auch Ermittlungsfunktionen bieten. Möglicherweise sind Ereignisprotokolle aller Art erforderlich, z. B. Systemprotokolle, Zugriffskontrollprotokolle usw., insbesondere im Hinblick auf das Vorfallmanagement und die Prüfung. In Protokollen müssen häufig potenziell große Informationsmengen gespeichert werden. Daher ist es wichtig, Kapazitätsüberlegungen anzustellen.

A.12.4.2 Schutz von Protokollinformationen

Protokollierungseinrichtungen und Protokollinformationen müssen vor Manipulation und unbefugtem Zugriff geschützt werden. Es ist außerdem wichtig, sicherzustellen, dass Protokolle sicher und manipulationssicher gespeichert werden, damit alle daraus abgeleiteten Beweise nachweisbar sind. Dies ist insbesondere bei Gerichtsverfahren jeglicher Art im Zusammenhang mit Beweismitteln aus dem Protokoll wichtig. Da Protokolle möglicherweise große Mengen sensibler Daten enthalten, ist es wichtig, dass sie angemessen geschützt und gesichert werden. Es ist auch wichtig zu bedenken, dass die Protokolle, wenn sie personenbezogene Daten enthalten, was mit ziemlicher Sicherheit der Fall sein wird, wie z. B. die Benutzer-ID und die von dieser UID durchgeführten Aktionen, wahrscheinlich unter die Anforderungen der Datenschutz- und Privatsphärengesetze, einschließlich der Datenaufbewahrung, fallen .

A.12.4.3 Administrator- und Bedienerprotokolle

Eine gute Kontrolle beschreibt, wie alle Aktivitäten von Systemadministratoren und Systembetreibern protokolliert und die Protokolle geschützt und regelmäßig überprüft werden müssen. Besonderes Augenmerk sollte auf eine umfassendere Protokollierung privilegierter Konten wie Systemadministratoren und -betreiber gelegt werden.

A.12.4.4 Uhrsynchronisation

Die Uhren aller relevanten Informationsverarbeitungssysteme innerhalb einer Organisation oder eines Sicherheitsbereichs müssen mit einer einzigen Referenzzeitquelle synchronisiert werden. Die Synchronisierung der Systemuhren ist wichtig, insbesondere wenn Ereignisse im Rahmen einer Untersuchung oder eines Gerichtsverfahrens bewiesen werden, da es oft unmöglich oder sehr schwierig ist, „Ursache und Wirkung“ nachzuweisen, wenn die Uhren nicht korrekt synchronisiert sind. Der Prüfer wird besonders darauf achten, dass dies erfolgt ist.

Was ist das Ziel von Anhang A.12.5?

Im Anhang A.12.5 geht es um die Steuerung der Betriebssoftware. Das Ziel in diesem Anhang A-Bereich besteht darin, die Integrität der Betriebssysteme sicherzustellen.

A.12.5.1 Installation von Software auf Betriebssystemen

Es müssen Verfahren implementiert werden, um die Installation von Software auf Betriebssystemen zu kontrollieren. Wie bei jeder sicherheitsrelevanten Kontrolle ist es wichtig, dass die Installation von Software auf Betriebssystemen formal kontrolliert wird. Auch wenn dies insbesondere in kleinen Organisationen nicht immer möglich ist, bleibt das Prinzip bestehen. Zu den Problemen im Zusammenhang mit der unsachgemäßen Installation oder Änderung von Software auf Betriebssystemen können gehören: Mit Schadsoftware infizierte Software wird installiert; Kapazitätsprobleme; oder Software, die die Installation bösartiger Insideraktivitäten ermöglichen kann (z. B. Hacking-Tools). Neben der Einschränkung und Begrenzung der Installation von Software auf Betriebssystemen ist es auch wichtig, die legitime Installation formal zu kontrollieren.

Es ist eine gute Praxis, wann immer möglich sicherzustellen, dass zum Beispiel: Es wurde ein formelles Änderungsmanagement durchgeführt, einschließlich angemessener Autorisierungsebenen. Rollback-Verfahren sind vorhanden; und Frühere Softwareversionen und Änderungsverläufe werden sicher aufbewahrt. Bei jeder Änderung sollten sowohl die Geschäftsanforderungen als auch die Sicherheitsanforderungen und -risiken im Einklang mit formalen Änderungsmanagementverfahren berücksichtigt werden. Der Prüfer erwartet, Aufzeichnungen über Softwareänderungen und -installationen zu sehen, die er inspizieren/probieren möchte.

Was ist das Ziel von Anhang A.12.6?

Im Anhang A.12.6 geht es um das technische Schwachstellenmanagement. Das Ziel in diesem Anhang A-Bereich besteht darin, die Ausnutzung technischer Schwachstellen zu verhindern.

A.12.6.1 Management technischer Schwachstellen

Informationen über technische Schwachstellen der genutzten Informationssysteme müssen zeitnah eingeholt, die Gefährdung der Organisation durch solche Schwachstellen bewertet und geeignete Maßnahmen zur Bewältigung des damit verbundenen Risikos ergriffen werden. Jede Schwachstelle stellt eine Schwachstelle im Sicherheitsschutz dar und muss effektiv und effizient behoben werden, wenn das Risikoniveau inakzeptabel ist. Technische Schwachstellen waren der Kern vieler großer Sicherheitsverstöße, über die in den Medien berichtet wurde (und auch solche, über die dies nicht der Fall ist!). Daher ist es wichtig, dass formelle verwaltete Prozesse auf einem angemessenen und verhältnismäßigen Niveau vorhanden sind.

Es muss ein Gleichgewicht bestehen zwischen dem Sicherheitsgebot, Schwachstellen-Patches so schnell wie möglich zu implementieren, und dem Sicherheitsgebot, Patches ausreichend zu testen, um die kontinuierliche Verfügbarkeit und Integrität der Systeme sicherzustellen und Inkompatibilitäten zu minimieren. Auch das Bewusstsein kann eine wichtige Rolle spielen. Daher ist es sinnvoll, über eine Kommunikationsstrategie zu verfügen, die die Benutzer auf dem Laufenden hält, wenn Schwachstellen bestehen, die bis zu einem gewissen Grad durch das Benutzerverhalten bewältigt werden können. Der Prüfer erwartet, dass Prozesse zur Identifizierung und Erkennung von Schwachstellen vorhanden sind, insbesondere bei kritischen Systemen oder solchen, die sensible oder geheime Informationen verarbeiten oder speichern.

A.12.6.2 Einschränkungen bei der Softwareinstallation

Regeln für die Installation von Software durch Benutzer müssen festgelegt und umgesetzt werden. Diese Kontrolle bezieht sich auf die Einschränkung der Möglichkeiten von Benutzern, Software zu installieren, insbesondere auf lokalen Geräten (Workstations, Laptops usw.). Die Installation von Software durch Benutzer birgt eine Reihe von Bedrohungen und Schwachstellen, darunter die Gefahr der Einführung von Malware und die mögliche Verletzung von Softwarelizenzierungs-/IPR-Gesetzen. Im Idealfall wäre es Benutzern nicht möglich, Software auf den Geräten der Organisation zu installieren. Es kann jedoch geschäftliche oder praktische Gründe geben, warum dies nicht möglich ist.

Wenn eine vollständige Einschränkung nicht möglich ist, empfiehlt es sich, die Software, die installiert werden darf, auf eine „Whitelist“ zu setzen. Der Prüfer prüft, welche Einschränkungen der Softwareinstallation durch Benutzer auferlegt wurden. Wenn dann keine vollständige Beschränkung umgesetzt wird, möchten sie Beweise dafür sehen, dass die Risiken vollständig bewertet wurden und, wo möglich, ergänzende Kontrollen wie regelmäßige Software-Audits implementiert wurden und regelmäßig verwendet werden.

Was ist das Ziel von Anhang A.12.7?

In Anhang A.12.7 geht es um Informationssysteme und Prüfungsüberlegungen. Das Ziel in diesem Anhang A-Bereich besteht darin, die Auswirkungen von Auditaktivitäten auf betriebliche Systeme zu minimieren.

A.12.7.1 Prüfungskontrollen für Informationssysteme

Auditanforderungen und -aktivitäten zur Überprüfung betrieblicher Systeme müssen sorgfältig geplant und vereinbart werden, um Störungen der Geschäftsprozesse zu minimieren. Bei der Durchführung von Tests und Prüfaktivitäten (z. B. Schwachstellenscans, Penetrationstests usw.) an Betriebssystemen muss darauf geachtet werden, dass der Betrieb nicht negativ beeinflusst wird. Darüber hinaus müssen Umfang und Tiefe der Prüfung festgelegt werden. Eine solche Prüfung oder Prüfung von Betriebssystemen muss im Rahmen eines formellen und entsprechend autorisierten Prozesses erfolgen. Der Prüfer wird nach Beweisen dafür suchen, dass die Testplanung und das Testniveau durch einen formellen Prozess vereinbart und genehmigt wurden.