Back-to-School: Aus dem Klassenzimmer vom CAS Information Security & Risk Management. Basis für diesen Lehrgang ist das BSI-Grundschutzhandbuch, und die Teilnehmenden bereiten sich begleitend auf die CISSP-Prüfung vor. Somit ist es ein Teil des 15-tägigen Lehrgangs, ein CISSP- oder BSI-Fachthema als Blogpost aufzubereiten:

Information Security-Aspekte im risikobasierten Projektmanagement

Der Grundschutz ist ermittelt, die IT-Strategie verabschiedet und das Informationssicherheitskonzept erstellt. Der Security Officer blickt mit Argusaugen auf die Einhaltung der Sicherheitsrichtlinien, behält die Sicherheitsziele im Auge und sorgt dafür, dass die Sicherheitsanweisungen rigoros umgesetzt werden. Jede neue Anforderung an ein produktives System löst einen Wandel aus, der, bevor produktiv gesetzt, vom Change Advisory Board (CAB) geprüft und bewilligt werden muss. Die Teilnehmer des CABs setzen sich aus Ingenieuren der verschiedenen technischen Disziplinen, dem Security Officer und einem Mitglied der erweiterten Geschäftsleitung zusammen. Neue Anforderungen können aus den unterschiedlichsten Bereichen und den unterschiedlichsten Gründen (Lifecycle, Release, Projekt, Incident oder Problem etc.) entstehen. Während Changes im Rahmen von Lifecycle-Aktivitäten und Releases in der Regel keine Anpassungen der Sicherheitspolicy zur Folge haben, und Incidents und Problems durch gefestigte Prozesse abgedeckt sind, ist dies bei Projekten komplizierter. Bei Projekten, insbesondere bei strategisch wichtigen Vorhaben, reicht es für die Bewilligung durch das CAB vor der Einführung meist nicht mehr, da die Änderungen häufig ein Ausmass angenommen haben, das nicht absehbare Folgen auf die zukünftige Sicherheitsrichtlinien haben wird. Dass diese nicht mehr mit dem aktuellen Informationssicherheitskonzept korrespondieren, interessiert nur am Rande, will doch das Vorhaben ‹on time›, ‹on quality› und ‹on budget› und natürlich zur vollen Zufriedenheit des Kunden eingeführt werden. Die Zielsetzung eines Projekts kann noch so akribisch definiert und die Projektrisiken so allumfassend wie möglich gefasst sein, neue, oder geänderte Sicherheitsaspekte werden oft als Problem des Betriebs abgetan. Häufig sind zu Beginn eines Projekts die genaueren Anforderungen an die Sicherheit eines neuen Systems oder einer neuen Anwendung noch nicht transparent. Es ist deshalb eminent wichtig, dass während des gesamten Lebenszyklus eines Projekts (von seiner Entstehung bis zum Abschluss) ein besonderes Augenmerk auf alle neuen und veränderten Sicherheitsaspekte zu richten. Im Idealfall ist bereits der Key Account Manager bei der Initiierung eines neuen Vorhabens auf das Thema Sicherheit im Groben sensibilisiert. Da es sich bei dieser Annahme aber im besten Fall um reines Wunschdenken handelt, müssen die nachgelagerten Stellen diesem Punkt umso mehr Beachtung schenken. Dies beginnt mit der jährlichen Budgetrunde, in der die neuen Projekte eingegeben werden. Hier ist der erste Zeitpunkt, um einen ersten (monetären) Sicherheitspfeiler einzuschlagen. Beim Review des Budgetantrages muss geprüft werden, ob das CC-Security das Projekt als sicherheitsrelevant eingestuft hat. Wurde das Projekt dann gestartet, muss laufend (bei jedem Quality-Gate) die Frage nach den veränderten Sicherheitsbelangen gestellt werden. Folgende Prüffragen werden deshalb in die Checkliste des Project Management Office übernommen und an jedem Projekt-Review Board (Phasenübergang am QGate) überprüft:

Quality Gate 1 – Projektantrag

• Sind das Architekturboard und der Security Officer über das Vorhaben informiert?
• Wurden die Anforderungen an die Sicherheit bei der Anforderungsanalyse berücksichtigt?

Quality Gate 2 – Projektauftrag

• Sind die Anforderungen und Einflüsse des Security Officers in der Stakeholder Analyse berücksichtigt?
• Ist der Security Officer oder ein Vertreter des CC-Security im Review Boards des Projektes?
• Sind die Berechtigungen im Projekt entsprechend der Rollen verteilt? (need to know)
• Sieht die Projektorganisation Rollen in Bezug auf Sicherheitsaspekte vor?
• Wurde eine Risiko-Kategorie ‹Security› in die Risikomatrix aufgenommen?

Quality Gate 3 – Lösungskonzept

• Werden neue Komponenten eingeführt, oder werden Komponenten verändert, die Einfluss auf das bestehende Sicherheitskonzept haben?
• Ist die Security bei der Erstellung des Test-Approachs beteiligt?
• Wurden die Security im Testkonzept berücksichtigt?
• Ist die Betriebsorganisation auf die veränderte Sicherheitssituation vorbereitet? (neue Technologien bedingen neue Skills)

Quality Gate 4 – Testkonzept

• Wurden Security-Testfälle erstellt und sind Security-Tests eingeplant?
• Wurden die Sicherheitsanweisungen aktualisiert?
• Wurden Mitarbeitende darauf geschult?

Quality Gate 5 – Einführungsfreigabe

• Hat der Security Officer die Freigabe zur Einführung erteilt?

Quality Gate 6 – Go-Live

• Wird bei erhöhten Sicherheitsrisiken die Projekteinführung durch das CC-Security begleitet?

 

Quality Gate 7 – Projektabschluss

• Was sind die Lessons Learned in Bezug auf Sicherheitsaspekte?

Diese Fragen müssen nur bei entsprechender Relevanz für das Projekt ausgefüllt werden, Diese Relevanz wird zum Zeitpunkt des Quality Gates 1 zwischen dem Projektleitenden, dem Security Officer und dem Project Management Officer geklärt.

---

Blogpost wurde erstelle von Martin Sutter (Centris AG) im Rahmen vom CAS Information Security & Risk Management. Dozenten in diesem sehr praxisorientierten Lehrgang sind: Lukas Fässler (FSDZ Rechtsanwälte & Notariat AG) Rainer Kessler (Governance Concept GmbH), Andreas Wisler (goSecurity GmbH) Beim nächsten CAS live dabei sein? Hier der Link zur Ausschreibung CAS Information Security & Risk Management Persönliche Beratung für den Lehrgang gewünscht? Einfach Prof. Martina Dalla Vecchia ein E-Mail schreiben und einen Termin vorschlagen.