Change-Reviews werden im Rahmen eines Changemanagement-Prozesses immer dann durchgeführt sobald eine Veränderung im Unternehmen frei gegeben werden soll. Unternehmen die solche Freigaben durchführen, haben sich vermutlich schon einmal mit ITIL oder ISO27000 beschäftigt. Beide Standards definieren die Einführung eines sogenannten Configuration Managements sowie einen Change-Management-Prozess der Veränderungen an der Produktion kontrolliert freigeben lässt. Ziel dabei ist es sicherzustellen dass die Qualitätsstandards in der Produktion erhalten bleiben bzw. keine Fehler unkontrolliert eingebaut werden.

Freigaben erfolgen entweder direkt durch die beteiligten Prüfer (Reviewer) oder auch durch teilweise automatisierte Prüfungen der eingegebenen Informationen zum Change-Request.

Dieser Artikel beschäftigt sich einerseits mit den sicherheitsrelevanten Mindestanforderungen an die Prüfung eines Änderungsantrages sowie andererseits den Maßnahmen die helfen sollen, möglichst die Changes in das Change-Verfahren hinein zu melden, die für das Unternehmen kritisch sein könnten.

MINDESTANFORDERUNGEN AUS SICHERHEITSSTANDARDS

Das National Institute of Standards and Technology (NIST) beschreibt im Leitfaden SP 800-128 die sogenannten Configuration Changes. Hierbei handelt es sich um Änderungen an einer Produktspezifikation. Diese Änderungen ziehen in der Regel eine Veränderung des Schutzprofils nach sich und sind daher auch ein Fall für das Risikomanagement. Dieser Leitfaden teilt sicherheitsrelevante Änderungen in vier Phasen ein: Planungsphase, Umsetzungsphase, Control-Phase und Monitoring. Der Leitfaden SP 800-100 betrachtet die folgenden Änderungen als sicherheitsrelevant:

• Changes an Direktiven, Leitfäden und Policies,
• Changes an den Geschäftszielen oder -Prioritäten,
• Changes durch veränderte äußere Einwirkungen wie neue Technologien oder veränderter Angriffsvektoren.

Um also möglichst alle sicherheitsrelevanten Änderungen an Produktionsanlagen in ein ordentliches Change-Verfahren hinein zu bekommen, sollte das Management Vorgaben über ihr „Policies & Procedures“ Rahmenwerk im Unternehmen einführen. Auf Arbeitsebene sollten Handlungsanweisungen (sog. Standard-Procedures) bereits die Mitarbeiter verpflichten Änderungen in den Change-Prozess einzubringen. Direktiven ermöglichen darüber hinaus eine verbindliche Aufforderung mit Möglichkeit zu Konsequenzen bei Nichtbeachtung. Auch Änderungen an der Unternehmensstrategie müssen im Change-Verfahren betrachtet werden damit ein möglicherweise verändertes Risiko neu bewertet und adressiert werden kann.

WAS SCHLÄGT ITIL VOR?

ITIL sieht das Security Management Team als Dienstleister um bei Änderungsanträgen zur Verfügung zu stehen. Bei Präsentationen von geplanten Changes im Change-Advisory-Board muss ein Mitarbeiter des Security Management Teams beisitzen und sein Einverständnis bzw. Maßnahmen-Empfehlung abgefragt werden.

WAS SCHLÄGT ISO27001 VOR?

ISO 27001 fordert dass Unternehmen ein formelles Änderungsverfahren einführen sollten. Weiter wird gefordert dass bei Änderungen an Systemen die geschäftskritischen Anwendungen überprüft und getestet werden sollten um zu Verhindern dass die Änderung keinen Einfluss am Betrieb oder der Sicherheit im Unternehmen hat. Änderungen an Software sollten soweit als möglich auf das Notwendigste eingeschränkt werden. Außerdem wird gefordert dass alle Änderungen an Informationsverarbeitenden Anlagen kontrolliert werden müssen.

BEST PRACTICE

Eine Vorprüfung von Veränderungsanträgen hat sich bei einigen Unternehmen (2000-10.000 Mitarbeiter) bewährt. Dabei beschreibt der Antragsteller knapp welche Systeme durch diesen „Change“ betroffen sind, beschreibt mit einem Satz die Situation vor dem „Change“ und anschließend die geplante zukünftige Situation mit folgenden Informationen: welche Daten ändern sich; welche Schnittstellen oder Datenflüsse ändern sich; welche Funktionalität oder Businesslogik ändert sich in welchen Anwendungen; Beschreibung wie Nutzer, Administratoren oder andere beteiligte Personen von der Änderung betroffen sein werden (geänderte Zugriffsrechte o.ä.).

Auf Basis dieser Informationen kann ein Change-Manager feststellen ob eine detailliertere Untersuchung der Veränderung bzw. auch eine Beratung durch einen Sicherheits-Experten notwendig sein wird. Bei kritischen Veränderungen kann der Change-Manager festlegen ob diese einem größeren Gremium (dem sog. Change Advisory Board CAB) vorgelegt werden müssen.

Ergänzend bietet es sich an in dem Changeverfahren nachzufragen ob die betroffene Komponente bereits auf einer anderen Prüfungsliste für neue Software/Services geführt und bewertet wird oder wurde.

Vereinfachend sollte man regelmäßige immer wiederkehrende Veränderungen über sogenannte Standard-Changes verarbeiten. Dazu fordert man die Antragsteller dazu auf wiederkehrende Änderungsanträge zu markieren. Diese können dann im Change-Management durch schnellere Freigabemechanismen oder Standard-Operating-Procedures bearbeitet werden.

Ebenso sollte unterschieden werden zwischen einem Änderungsantrag noch vor Beginn der Änderungsarbeiten sowie dem Änderungsantrag der erstellt wird nachdem die Änderung bereits entwickelt und getestet wurde. Im zweiten Fall ist es bereits zu spät für eine Beratung durch eigene Sicherheits-Experten. Deshalb sollte der Änderungsantrag immer vor Beginn der Änderungen erstellt werden.

Als letztes empfiehlt sich die Einführung eines sog. Post-Implementation Prüf-Prozesses. Eine Prüfung nach Inbetriebnahme ermöglicht es sicher zu stellen dass die vorgegebenen Sicherheitsmaßnahmen ordentlich implementiert worden sind.

Dieser Artikel nimmt den Kernprozess ins Visier der in jedem Unternehmen latent oder auch tatsächlich gelebt vorhanden ist: Der Change-Prozess. Hier ist es möglich an zentraler Stelle sukzessiv Sicherheitsmaßnahmen in das Unternehmen hinein zu bringen. Verschiedene Standards wie ITIL oder ISO27001 beschreiben was zu tun ist, um das Sicherheitsniveau sozusagen durch die Hintertür zu erhöhen.