Projektmanagement im Bereich Cybersicherheit: Bedeutung und beste Tools für das Projektmanagement

Das Projektmanagement im Bereich Cybersicherheit ist die Disziplin, die strukturierte Governance-Vorgaben hinsichtlich Umfang, Zeitplan, Budget, Risiken, Ressourcen und Nachweisen für die Umsetzung von Sicherheitsinitiativen anwendet. Es schließt die Lücke zwischen den Erkenntnissen Ihres Sicherheitsteams und den tatsächlich umgesetzten, überwachten und gegenüber Auditoren nachgewiesenen Maßnahmen.

Es ist nicht dasselbe wie die Sicherung Ihrer Projektmanagementdaten, obwohl diese ebenfalls wichtig ist. Die Leitung eines Cybersicherheitsprojekts bedeutet, Erkenntnisse aus Penetrationstests, Schwachstellenscans, GRC-Audits und Architekturprüfungen in priorisierte, terminierte, eigenverantwortliche und nachweisbare Arbeitsschritte umzusetzen, die termingerecht und in jeder Phase nachvollziehbar umgesetzt werden.

Ein Projektmanager für Cybersicherheit ersetzt weder einen CISO noch einen Sicherheitsarchitekten oder Penetrationstester. Er bildet das operative Rückgrat und stellt sicher, dass die Ergebnisse jedes Spezialistenprojekts zu einem abgeschlossenen, dokumentierten und dokumentierten Arbeitsergebnis werden.

Die meisten Projektmanager, die in den Bereich IT-Sicherheit wechseln, stellen schnell fest, dass herkömmliche Projektabwicklungsmodelle an ihre Grenzen stoßen. In einem typischen IT-Projekt bedeutet „fertig“, dass die Funktion ausgeliefert und von den Nutzern abgenommen wurde. In einem Cybersicherheitsprojekt hingegen bedeutet „fertig“, dass die Kontrollmaßnahmen implementiert, validiert und dokumentiert sind und das Restrisiko von der zuständigen Stelle formell akzeptiert wurde.

Eine Firewall-Regel, die ohne Validierung implementiert wurde, eine MFA-Einführung mit ungeprüfter Abdeckung oder ein Patch, der ohne Regressionstests eingespielt wurde – all dies kann im Gantt-Diagramm eine 100%ige Aufgabenerfüllung anzeigen, ohne dass die Organisation dadurch sicherer wird als zuvor. Die Aufgabe des Security PM besteht darin, diesen Kreislauf zwischen Aufgabenerfüllung und tatsächlichem Sicherheitsergebnis zu schließen.

Auch die Stakeholder-Landschaft ist grundlegend anders. Während ein Standard-IT-Projekt einen Sponsor, eine Benutzergruppe und ein IT-Team umfasst, sind bei einem Sicherheitsprojekt der CISO, Risikoverantwortliche, Compliance-Beauftragte, Rechtsberater, interne Prüfer, externe Aufsichtsbehörden und oft ein Risikoausschuss auf Vorstandsebene beteiligt – alle mit unterschiedlichen Informationsbedürfnissen, unterschiedlichen Risikotoleranzen und unterschiedlichen Erfolgsdefinitionen.

Compliance ist selten optional. Änderungsanträge in Sicherheitsprojekten müssen nicht nur hinsichtlich ihrer Auswirkungen auf Zeitplan und Kosten bewertet werden, sondern auch danach, ob sie neue Angriffsflächen eröffnen oder die Risikolage verändern. Die Überwachung nach Projektabschluss endet nicht mit dem Go-Live, sondern wird fortgesetzt, solange die Kontrollmaßnahmen genutzt werden. Diese Unterschiede erfordern einen bewusst anderen Managementansatz, weshalb Tools und Prozesse, die für die Standard-IT-Bereitstellung entwickelt wurden, oft nicht ausreichen.

Sicherheitsprogramme scheitern nicht, weil Organisationen nicht wissen, was zu tun ist. Sie scheitern, weil die Arbeit nicht ausreichend geplant, mit den nötigen Ressourcen ausgestattet, nachverfolgt und dokumentiert wird, um erfolgreich abgeschlossen zu werden.

Die Einhaltung regulatorischer Vorgaben und Compliance ist einer der unmittelbarsten Gründe, warum sich strukturiertes Projektmanagement im Bereich IT-Sicherheit auszahlt. Rahmenwerke wie ISO/IEC 27001:2022, SOC 2 Typ II, NIST Cybersecurity Framework 2.0, PCI DSS 4.0, HIPAA und CMMC 2.0 fordern die nachweisbare Implementierung spezifischer Kontrollen innerhalb definierter Fristen. Jede Kontrollanforderung ist in der Praxis ein Projektarbeitspunkt mit Verantwortlichem, Fälligkeitstermin und Nachweispflicht. Ohne strukturiertes Projektmanagement verpassen Unternehmen regelmäßig Fristen für die Behebung von Mängeln, liefern unvollständige Prüfnachweise und sehen sich in Audits immer wieder mit denselben Feststellungen konfrontiert.

Sicherheit durch Design erfordert einen Projektmanager, der bereits in der Programmplanung und nicht erst bei der Auslieferung hinzugezogen wird. Sowohl das NIST Secure Software Development Framework als auch ISO 27001 Annex A fordern die frühzeitige Identifizierung von Sicherheitsanforderungen. Ein Sicherheits-Projektmanager stellt sicher, dass Bedrohungsmodellierung, Architekturprüfung, Anforderungen an sicheren Code und Sicherheitsprüfungen für Releases als geplante Aktivitäten mit festgelegten Verantwortlichen vorgesehen sind und nicht erst nachträglich hinzugefügt werden, wenn die Entwicklung bereits begonnen hat.

Die funktionsübergreifende Koordination ist der häufigste Schwachpunkt von Sicherheitsprojekten. Die Sicherheitsarbeit erstreckt sich über Teams, die selten einer gemeinsamen Managementebene angehören: Sicherheitsentwicklung, Infrastruktur, DevOps, Compliance, Recht, Beschaffung und Lieferantenmanagement. Der Sicherheitsprojektmanager fungiert als Bindeglied, das technische Erkenntnisse in eine für Führungskräfte handlungsrelevante Sprache der Geschäftsrisiken übersetzt und Governance-Anforderungen in konkrete Aufgaben umsetzt, die von den Entwicklungsteams ausgeführt werden können.

Die Bereitschaft für Audits ist ein direktes Ergebnis guten Projektmanagements. Entscheidungsprotokolle, Genehmigungsnachweise, Nachweisregister und Änderungsanträge bilden den Prüfpfad, den eigenständige Sicherheitstools nicht erstellen können. Fragt ein Auditor, warum eine bestimmte Kontrollmaßnahme als Restrisiko akzeptiert wurde, sollte die Antwort in einem formal dokumentierten, datierten Dokument vorliegen und nicht aus dem Gedächtnis oder E-Mail-Verläufen rekonstruiert sein.

Die Priorisierung von Ressourcen und Budgets hängt von der Transparenz auf Portfolioebene ab, die nur strukturiertes Projektmanagement bietet. Sicherheitsexperten sind rar. CISOs, die anhand von Daten aufzeigen können, welche Initiativen Kapazitäten beanspruchen und welchen Nutzen die Risikominderung bringt, sind deutlich besser in der Lage, Budget- und Personalbedarf zu begründen.

Der Security Project Manager (PM) ist für die Steuerung und Durchführung einer oder mehrerer Sicherheitsinitiativen verantwortlich. Es ist wichtig, diese Rolle zu verstehen, da Unternehmen sie häufig entweder unterbesetzen (indem sie erwarten, dass ein Security Engineer auch das Projekt leitet) oder falsch definieren (indem sie erwarten, dass der PM Risikoentscheidungen trifft, die eigentlich dem CISO oder dem Risikoverantwortlichen obliegen).

Scope-Management bedeutet, gemeinsam mit dem CISO oder Risikoverantwortlichen die Grenzen von Sicherheitsprojekten und insbesondere die Sicherheitsakzeptanzkriterien festzulegen. Es geht nicht nur darum, das Tool bereitzustellen, sondern es auch bereitzustellen, die Abdeckung auf allen Produktionsendpunkten zu validieren und einen Abschlussbericht zu erstellen, der vom Sicherheitsverantwortlichen geprüft wird.

das Terminmanagement die Integration von Sicherheitskontrollpunkten in den Plan – formale Prüfpunkte, an denen die Sicherheitsakzeptanzkriterien vor Projektfortschritt bestätigt werden. Es handelt sich dabei nicht um optionale Meilensteine, die bei Terminverzögerungen verkürzt werden können.

Risikomanagement bedeutet, während der gesamten Projektlaufzeit ein aktuelles Risikoregister zu führen, regelmäßige Risikobewertungen durchzuführen und akzeptierte oder ungelöste Risiken mit den entsprechenden Unterlagen an die zuständige Stelle zu eskalieren. Der Projektmanager trifft keine Entscheidungen zur Risikoakzeptanz, ist aber dafür verantwortlich, dass diese Entscheidungen von der richtigen Person getroffen und ordnungsgemäß dokumentiert werden.

Die Beweissicherung wird in den Aufgabenbeschreibungen von Projektmanagern oft vernachlässigt, ist aber für den Erfolg von Sicherheitsprogrammen von zentraler Bedeutung. Der Projektmanager muss sicherstellen, dass nach Abschluss jeder Aufgabe die entsprechenden Nachweise gemäß den Aufbewahrungsrichtlinien der Organisation erfasst, geprüft und gespeichert werden und nicht erst bei Abschluss der jeweiligen Aufgabe erfasst werden.

Die Kommunikation auf Führungsebene in Sicherheitsprogrammen erfordert die Übersetzung von Risiko- und Kontrolldaten in Formate, auf deren Grundlage Vorstände und Führungskräfte handeln können: Prozentsatz der überfälligen kritischen Schwachstellen, Einhaltungsquote der SLA-Behebung, Alterung der Risikoakzeptanz und Erfolgsquote bei Sicherheitskontrollen – nicht nur Ampelstatus und Meilensteinprozentsätze.

Der Projektmanager führt keine Penetrationstests durch, prüft nicht die Architektur, konfiguriert keine Sicherheitskontrollen und trifft keine Risikoakzeptanzentscheidungen. Diese Aufgaben obliegen den Sicherheitsarchitekten, -ingenieuren, -analysten, dem CISO bzw. den Risikoverantwortlichen.

Das Aufgabenspektrum eines Security-Projektmanagers ist umfangreicher als die meisten Unternehmen zunächst annehmen. Die Einführung von IAM- und PAM-Systemen erfordert komplexe Systemintegrationen, intensive Abstimmung mit verschiedenen Anbietern und gestaffelte Governance-Anforderungen, die sich über Monate erstrecken. MFA-Implementierungen sind trügerisch aufwändig im Change-Management: Die Nachverfolgung von Ausnahmen und die Überprüfung der Akzeptanz erfordern ebenso viel Projektmanagement-Disziplin wie die technische Implementierung. Programme zur Behebung von Sicherheitslücken sind im Wesentlichen kontinuierliches Backlog-Management mit SLA-Verantwortlichkeit, Nachweis von Regressionstests und Abhängigkeit von Patch-Releases von Drittanbietern.

Die Behebung von Schwachstellen nach Penetrationstests wird häufig unterschätzt. Der Penetrationstest liefert zwar eine Liste der festgestellten Fehler, doch die Umwandlung dieser Liste in ein geplantes, mit Ressourcen ausgestattetes und dokumentiertes Behebungsprojekt inklusive Nachtestkoordination und formellem Abschluss stellt einen erheblichen Projektmanagementaufwand dar.

Die Vorbereitung auf SOC 2 und die Implementierung von ISO 27001 sind Compliance-Projekte, die eine Zuordnung von Kontrollen zu Nachweisen über Dutzende oder Hunderte von Anforderungen hinweg, eine funktionsübergreifende Koordination der Verantwortlichen und ein effektives Kommunikationsmanagement mit den Auditoren erfordern. SIEM-Implementierungen umfassen klar definierte Infrastruktur-, Integrations- und Anwendungsfall-Bereitstellungsphasen, die sorgfältig aufeinander abgestimmt werden müssen. Zero-Trust-Programme sind mehrjährige Portfolio-Projekte, die eine detaillierte Planung der Arbeitsabläufe in den Bereichen Identität, Netzwerk, Geräte und Daten mit erheblichen Abhängigkeiten erfordern.

Allen diesen Anforderungen ist gemeinsam, dass sie mehr als nur die reine Aufgabenverfolgung erfordern. Sie benötigen risikobewusste Planung, Nachweisführung, Abhängigkeitsmanagement, funktionsübergreifende Verantwortlichkeit und Berichterstattung an die Geschäftsleitung – und genau hier setzt Celoxis an.

Die meisten Sicherheitsprogramme verfügen über angemessene Governance-Rahmen und geeignete technische Werkzeuge. Die Lücke besteht nicht darin, zu wissen, was zu tun ist, sondern in der disziplinierten Umsetzung der Governance-Ergebnisse in geplante, mit Ressourcen ausgestattete, dokumentierte und abgeschlossene Projektarbeit. SECURE bietet eine sechsstufige Struktur, um genau dies zu erreichen.

S

Sicherheitsziel festlegen

Die erste Phase definiert nicht nur die Projektergebnisse, sondern auch das zu erreichende Sicherheitsziel. Dazu gehört die Dokumentation des Geschäftsziels, des Sicherheitsziels, der betroffenen Systeme und Daten, des Projektumfangs und – besonders wichtig – der Sicherheitsakzeptanzkriterien. Diese Kriterien definieren den minimalen Kontrollzustand, der als „Fertigstellung“ gilt, und müssen vor Beginn der Planung mit dem CISO oder dem Risikoverantwortlichen abgestimmt werden.

Wichtigstes Artefakt: Charta des Cybersicherheitsprojekts

Austrittskriterium: Eine vom Sponsor genehmigte Charta mit expliziten Sicherheitsakzeptanzkriterien und einer bestätigten Liste der in den Geltungsbereich fallenden Vermögenswerte.

E

Risiken und Verpflichtungen bewerten

Bevor der Zeitplan erstellt wird, muss die Bedrohungslandschaft analysiert werden. In dieser Phase werden Bedrohungen, Schwachstellen, regulatorische Verpflichtungen, Kontrolllücken, Abhängigkeiten von Drittanbietern, inhärente Risiken, Restrisiken und die Risikobereitschaft des Unternehmens identifiziert. Regulatorische Fristen wie ein ISO-27001-Überwachungsaudit, ein CMMC-Bewertungszeitraum und ein vierteljährlicher PCI-DSS-Scan müssen bestätigt und in die Zeitplangrundlage aufgenommen werden.

Wichtigstes Artefakt: Risikoregister

Ausstiegskriterium: Ein Basisregister, in dem alle hohen und kritischen Risiken einem Eigentümer und einem Behandlungsplan zugeordnet sind.

C

Steuerelemente in ausführbaren Code umwandeln

Dies ist die Phase, die die meisten Sicherheitsprogramme vernachlässigen. NIST-Ergebnisse, ISO 27001 Annex A-Kontrollen, Auditfeststellungen und Architekturanforderungen müssen in konkrete, eigenverantwortliche und terminierte Arbeitspakete umgesetzt werden und dürfen nicht als Governance-Dokumente in einer GRC-Plattform verbleiben. Jede Kontrolle ist einer oder mehreren Aufgaben zugeordnet, jede Aufgabe hat einen Verantwortlichen und eine Fälligkeitsfrist sowie definierte Akzeptanzkriterien und Nachweisanforderungen.

Schlüsselartefakt: Kontroll-Arbeits-Matrix

Abbruchkriterium: 100 % der erforderlichen Kontrollen müssen mindestens einem zugeordneten, geplanten Arbeitselement zugeordnet sein.

U

Eigentümer, Ressourcen und Abhängigkeiten vereinen

Sicherheitsprojekte scheitern am häufigsten bei der Übergabe zwischen den Teams. In dieser Phase werden Ressourcenzusagen und Kapazitäten in den Bereichen Sicherheit, Entwicklung, Infrastruktur, DevOps, Compliance, Recht, Beschaffung und bei den Lieferanten geprüft. Es wird die integrierte Abhängigkeitsmatrix erstellt und der Eskalationsweg festgelegt, bevor Probleme auftreten.

Wichtigstes Artefakt: Abhängigkeitsdiagramm und RACI

Abbruchkriterium: Alle Verantwortlichen der Arbeitsabläufe bestätigt, Ressourcenplan festgelegt und Eskalationsweg dokumentiert.

R

Risiken, Beweise und Abhilfemaßnahmen kontinuierlich überprüfen

Die Bereitstellung ist keine passive Phase. In dieser Phase finden wöchentliche Risiko- und Statusprüfungen statt, die Einhaltung der SLAs zur Behebung von Mängeln wird überwacht, Änderungsanträge werden inklusive Sicherheitsfolgenabschätzung bearbeitet, überfällige Punkte werden eskaliert und die Bereitschaft der Sicherheitskontrollen wird überwacht. Nachweise werden nach Abschluss der Aufgaben gesammelt, nicht erst nach deren Abschluss.

Wichtigste Artefakte: Register der lebenden Risiken und Beweisregister

Austrittskriterium: Alle Sicherheitskontrollen wurden mit dokumentierten Nachweisen passiert, und es gab keine überfälligen kritischen Gegenstände ohne formell akzeptiertes Risiko.

E

Beweise sammeln, eskalieren und weiterentwickeln

Der Projektabschluss im Sicherheitskontext erfordert mehr als nur die Genehmigung. In dieser Phase werden alle Sicherheitsakzeptanzkriterien validiert, die Vollständigkeit und ordnungsgemäße Aufbewahrung des Nachweisregisters gemäß den Richtlinien bestätigt, die formale Risikoakzeptanz für verbleibende Punkte eingeholt, die Verantwortung für die operative Überwachung übertragen und die gewonnenen Erkenntnisse dokumentiert.

Wichtigstes Artefakt: Checkliste zum Schließen des Sicherheitstors

Abbruchkriterium: Alle Akzeptanzkriterien erfüllt oder formell akzeptiert, Nachweisregister vollständig und operative Eigentumsverhältnisse bestätigt.

Der Unterschied zwischen einem Sicherheitsprogramm, das die Prüfung besteht, und einem, das sie nicht besteht, liegt oft nicht in den Sicherheitsmaßnahmen selbst, sondern in der Sorgfalt bei deren Dokumentation. Dies sind die zentralen Dokumente, die ein Sicherheitsprojektmanager in jedem Projekt pflegen sollte.

Die Projektcharta für Cybersicherheit ist das grundlegende Dokument. Sie definiert Umfang, Ziele, Sicherheitsakzeptanzkriterien, Verantwortlichkeiten des Projektträgers und den Eskalationsweg. Sie sollte vor Beginn jeglicher weiterer Planung vereinbart und nur im Rahmen eines formellen Änderungsverfahrens geändert werden.

Das Risikoregister ist ein dynamisches Dokument und keine einmalige Angelegenheit. Es erfasst identifizierte Risiken, deren Eintrittswahrscheinlichkeit, Auswirkungen, Behandlungsansatz, Verantwortliche und Restrisiken während des gesamten Projektverlaufs. In Celoxis lassen sich Risiko- und Problemregister als konfigurierbare, benutzerdefinierte Workflows erstellen. So bleiben die Risiken direkt im Projektplan sichtbar und nicht in einer isolierten Tabelle.

Die RAID-Protokollierung von Risiken, Annahmen, Problemen und Abhängigkeiten in einem einzigen verwalteten Datensatz gewährleistet, dass Blockaden, offene Fragen und teamübergreifende Abhängigkeiten erfasst, zugeordnet und eskaliert werden, anstatt zwischen den Team-Updates unterzugehen.

Die Kontroll-zu-Arbeits-Matrix ist das Dokument, das Governance in die Praxis umsetzt. Sie ordnet jede erforderliche Kontrolle den entsprechenden Aufgaben, dem Verantwortlichen, den benötigten Nachweisen, dem Fälligkeitstermin und den Akzeptanzkriterien zu. Sie ist das wichtigste Dokument, das ein Sicherheitsprojektmanager verwaltet, und gleichzeitig das, das in unausgereiften Programmen am häufigsten fehlt.

Der Sicherheitsrückstand zur Schwachstellenbehebung erfasst offene Ergebnisse von Schwachstellenscans und Penetrationstests, priorisiert nach Schweregrad, mit SLA-Zielen, Verantwortlichkeit und Status. In Celoxis lässt sich dies als Projekt-Backlog mit benutzerdefinierten Schweregradfeldern, SLA-Tracking und Dashboard-Berichten nach Risikostufe verwalten.

Das Nachweisregister dokumentiert, welche Nachweise für jede Kontrollmaßnahme gesammelt wurden, wo diese gespeichert sind, welche Version vorliegt und wer sie geprüft hat. Ohne dieses Register wird die Auditvorbereitung zu einer hektischen Suche in Netzlaufwerken und E-Mail-Archiven.

Das Risikoakzeptanzprotokoll ist die formale Dokumentation aller akzeptierten, aber nicht behandelten Risiken. Es enthält die Begründung, den Genehmiger, das Ablaufdatum und alle damit verbundenen Bedingungen. Dieses Dokument dient der internen Steuerung und ist nicht nur ein Hilfsmittel für das Projektmanagement. Es muss gemäß den Aufbewahrungsrichtlinien des Unternehmens aufbewahrt werden.

Die Sicherheitscheckliste bestätigt an jedem Meilenstein, dass die Sicherheitskriterien für die jeweilige Phase erfüllt sind, bevor das Projekt fortschreitet. In Celoxis lassen sich Meilensteine ​​als Genehmigungsworkflows erstellen, die die Freigabe durch benannte Genehmiger erfordern, bevor die nächste Phase freigeschaltet wird.

Anmerkungen der einzelnen Anbieter 

Celoxis

Celoxis positioniert sich in diesem Vergleich als Plattform, die Portfolio-Governance, Gantt-Planung mit kritischer Pfadanalyse, projektübergreifende Abhängigkeitsverfolgung, Ressourcenkapazitätsplanung und Finanzverfolgung nativ in einem System vereint, mit der zusätzlichen Flexibilität einer On-Premises-Bereitstellung für Organisationen, die dies benötigen.

Speziell für das Projektmanagement im Bereich Cybersicherheit dient Celoxis als Ausführungs- und Portfolio-Governance-Ebene, die die Ergebnisse der Sicherheits-Governance mit der Verantwortlichkeit für die Projektabwicklung verknüpft. Risiko- und RAID-Workflows lassen sich als strukturierte, benutzerdefinierte Workflows konfigurieren und nicht als Freitextfelder. Dadurch sind Risikoregister, Nachweisregister und Risikoakzeptanzprotokolle Teil des normalen Projektabwicklungsprozesses und nicht separate Verwaltungsdokumente. Sicherheitsfreigaben werden als geroutete Genehmigungsworkflows mit zeitgestempelten Datensätzen erstellt, wodurch der für evidenzbasierte Sicherheitsprogramme erforderliche Prüfpfad entsteht.

Die Integration von Jira und Azure DevOps ist bidirektional, was insbesondere in Sicherheitsprogrammen wichtig ist, da Ergebnisse in Jira erfasst und die Umsetzung über Celoxis-Statusflüsse zwischen beiden Systemen ohne manuelle Synchronisierung gesteuert wird. Für Organisationen mit Anforderungen an den Datenstandort steht neben der Cloud-Option auch eine lokale Bereitstellung zur Verfügung. Dadurch müssen Sicherheits-PMOs nicht zwischen Funktionalität und Compliance wählen.

Auf G2 hat Celoxis aktuell eine Bewertung von 4,6 von 5 Sternen basierend auf über 650 Rezensionen. Rezensenten aus IT- und Sicherheits-PMO-Bereichen nennen am häufigsten die Kombination aus Ressourcenplanung, projektübergreifendem Abhängigkeitsmanagement und Portfolio-Reporting auf einer einzigen Plattform als Grund für die Umstellung von separaten Tools. Der am häufigsten genannte Nachteil ist der höhere Konfigurationsumfang, der im Vergleich zu schlankeren Tools wie Wrike oder Smartsheet eine steilere anfängliche Einrichtungskurve zur Folge haben kann. Rezensenten bewerten diesen Aufwand jedoch im Allgemeinen als lohnenswert, sobald die Plattform gemäß den Programmanforderungen konfiguriert ist.

Celoxis ist die richtige Wahl, wenn Ihr Sicherheitsprogramm mehrere gleichzeitig laufende Initiativen umfasst, die eine Governance auf Portfolioebene, Ressourcenkapazitätsmanagement sowie formale Risiko- und Genehmigungsworkflows erfordern, und wenn Sie eine Plattform benötigen, die neben GRC und Jira eingesetzt werden kann, ohne diese zu duplizieren.

Jira (Atlassian)

Jira ist der gängigste Ausgangspunkt für Sicherheitsteams, die bereits im Atlassian-Ökosystem arbeiten. Seine Flexibilität und der breite Markt machen es zu einer glaubwürdigen Wahl für die Verwaltung von Sicherheitslückenbehebungs-Backlogs, das Sprintmanagement im DevSecOps-Bereich und die Nachverfolgung von Penetrationstestergebnissen, insbesondere wenn Sicherheitsarbeit und Softwareentwicklung im selben Tool integriert sind.

Die Einschränkung wird auf Portfolioebene deutlich. Jira ist ein Issue-Tracker, keine PPM-Plattform. Ressourcenplanung auf Portfolioebene, Finanzsteuerung und projektübergreifendes Management-Reporting erfordern erweiterte Roadmaps oder Drittanbieter-Plugins, was zusätzlichen Konfigurationsaufwand und Kosten verursacht. Risikoregister und RAID-Protokolle sind in Jira zwar möglich, erfordern aber eine benutzerdefinierte Konfiguration anstelle nativer Workflows. Dadurch entstehen im Laufe der Zeit häufig Inkonsistenzen zwischen den Teams. Jira Government Cloud ist FedRAMP-zertifiziert für US-Bundesbehörden. Wie bei jeder Autorisierung sollten Organisationen jedoch sicherstellen, dass ihre spezifische Konfiguration und Datenverarbeitung den Compliance-Anforderungen entsprechen, anstatt anzunehmen, dass die Infrastruktur-Autorisierung auch für ihre Nutzung gilt.

Jira ist die richtige Wahl, wenn Ihre Sicherheitsarbeit untrennbar mit Ihrer Softwareentwicklungspipeline verbunden ist und Ihr Team bereits tief in die Atlassian-Technologie eingearbeitet ist. Weniger geeignet ist Jira hingegen, wenn der Hauptbedarf in der Portfolio-Governance, der Ressourcenplanung und dem formalen Risikomanagement über mehrere parallel laufende Sicherheitsprogramme hinweg liegt.

Wrike

Wrike positioniert sich als glaubwürdige Zwischenlösung zwischen leichtgewichtigem Projektmanagement und umfassendem Enterprise-PPM. Dank seiner konfigurierbaren Workflow-Automatisierung und der Funktionen für die funktionsübergreifende Zusammenarbeit ist es eine sinnvolle Wahl für Sicherheitsteams, die eine stärkere Governance-Struktur als Jira benötigen, aber noch kein umfangreiches Portfolio mit mehreren Programmen verwalten.

Wrike ist SOC 2 Typ II- und ISO 27001-zertifiziert, unterstützt SAML SSO, Zwei-Faktor-Authentifizierung und bietet Optionen für den Datenspeicherort in der EU und den USA. Wrike Lock, das Unternehmen kundenverwaltete Verschlüsselungsschlüssel zur Verfügung stellt, ist in ausgewählten Enterprise-Tarifen verfügbar. Bitte prüfen Sie die aktuelle Verfügbarkeit und die Anforderungen des jeweiligen Tarifs, bevor Sie Wrike Lock in Ihre Evaluierung einbeziehen.

Der Nachteil besteht darin, dass Wrikes Ressourcenmanagement auf Portfolioebene und die Finanzsteuerung weniger ausgereift sind als spezialisierte PPM-Plattformen für Organisationen mit großen, komplexen Sicherheitsprogrammen. Risikoregister, RAID-Protokolle und Beweismittel-Workflows sind zwar konfigurierbar, aber nicht nativ integriert. Das bedeutet, dass sie sorgfältig eingerichtet und regelmäßig gewartet werden müssen, um nutzbar zu bleiben. Wrike bietet derzeit keine On-Premises-Bereitstellung an, was für Rüstungsunternehmen und staatliche Sicherheitsprogramme mit strengen Anforderungen an den Datenstandort eine Einschränkung darstellt.

Smartsheet

Smartsheets rasterbasierte Benutzeroberfläche macht es zu einem der am schnellsten einzuführenden Tools für Teams, die von Tabellenkalkulationen umsteigen. Dies ist ein echter Vorteil in Organisationen, in denen Change-Management ebenso wichtig ist wie Funktionalität. Die Stärke von Smartsheet liegt in seiner strukturierten Flexibilität: Mit ausreichendem Konfigurationsaufwand lässt sich nahezu jeder Workflow in Smartsheet abbilden, und die Plattform verbreitet sich in der Regel organisch, sobald ein Team sie eingeführt hat.

Für die Arbeitslasten der US-Regierung ist Smartsheet Gov FedRAMP-autorisiert – eine aussagekräftige Berechtigung für Sicherheitsprogramme des Bundes. SOC 2 Typ II- und ISO 27001-Zertifizierungen liegen vor, und SAML SSO, SCIM-Bereitstellung und MFA sind verfügbar.

Die Einschränkung für das Management komplexer Sicherheitsprogramme liegt in der Struktur. Smartsheet basiert auf Tabellen und Tabellen, was zwar für listenbasierte Nachverfolgung gut geeignet ist, aber bei komplexen Vorgänger-Nachfolger-Planungen in großen, integrierten Projektplänen zu Problemen führt. Ressourcenplanung auf Portfolioebene und Finanzkontrolle erfordern typischerweise übergeordnete Pläne und einen höheren Aufwand für die Dashboard-Erstellung im Vergleich zu Plattformen, die von Anfang an auf PPM-Governance ausgelegt sind. Risikoakzeptanz- und RAID-Workflows sind zwar möglich, erfordern aber eine sorgfältige Konfiguration, um revisionssichere Aufzeichnungen zu gewährleisten.

OpenProject

OpenProject ist die optimale Plattform für Organisationen, für die Datensouveränität oberste Priorität hat. Als Open-Source- und selbstgehostete Plattform bietet sie Organisationen die volle Kontrolle darüber, wo ihre Projektdaten gespeichert werden, wie sie verschlüsselt werden und wer darauf zugreifen kann – ein entscheidender Vorteil für Rüstungsunternehmen, Regierungsbehörden und stark regulierte Finanzinstitute, die ihre Projektdaten nicht in einer kommerziellen Cloud speichern dürfen.

Es unterstützt LDAP- und SAML-Authentifizierung, rollenbasierte Zugriffskontrolle und eine anpassbare Arbeitspaketverfolgung, die für Risiko- und Problemmanagement konfiguriert werden kann. Die Gantt-Planung und die projektübergreifende Abhängigkeitsverfolgung bieten eine größere native Planungstiefe als die meisten anderen Arbeitsmanagement-Tools.

Die Einschränkung liegt im Reifegrad der PPM-Lösung auf Unternehmensebene. Portfolioanalysen, Ressourcenplanung für große Teams und Finanz-Governance sind weniger ausgereift als bei kommerziellen PPM-Plattformen. Support-SLAs und Wartungsverpflichtungen hängen von der gewählten Edition und dem Hosting-Modell ab. Für Organisationen, in denen eine selbstgehostete Bereitstellung zwingend erforderlich ist und die Komplexität der Portfolio-Governance moderat ist, ist OpenProject eine vielversprechende Option. Organisationen, die neben umfassender Datenkontrolle auch eine tiefgreifende Portfolio-Finanz-Governance benötigen, müssen die Vor- und Nachteile sorgfältig abwägen.

Die Berichterstattung über Sicherheitsprogramme muss zwischen Kennzahlen zur Leistungserbringung und Kennzahlen zum Sicherheitsergebnis unterscheiden. Ein Programm kann zu 95 % im Zeitplan liegen, während kritische Schwachstellen weiterhin ungelöst bleiben und wichtige Kontrollmechanismen nicht nachgewiesen werden.

Die für einen CISO relevanten KPIs sind Kennzahlen zur Sicherheitsleistung: die Anzahl kritischer Schwachstellen, die die SLA-Vorgabe überschritten haben, der Anteil der innerhalb der vereinbarten SLA behobenen Schwachstellen, die Abschlussquote der Sicherheitskontrollen zu jedem Prüftermin, die Vollständigkeit der Nachweise vor einem Audit, die Erfolgsquote bei der ersten Sicherheitsprüfung und ob Risikoakzeptanzen ihren Prüftermin überschritten haben. Diese Kennzahlen sollten separat, aber parallel zu Standardkennzahlen wie Terminabweichung, Meilensteinabweichung, Budgetabweichung und Ressourcenauslastung erfasst und berichtet werden.

In Celoxis können benutzerdefinierte Dashboards erstellt werden, die beide Kategorien gleichzeitig anzeigen und so Sicherheits-PMO-Leitern und CISOs einen einheitlichen Überblick über den Programmstatus geben, der sowohl die Umsetzungsdisziplin als auch den Fortschritt der Sicherheitsergebnisse erfasst.

Sicherheitsprojekte der Regierung und regulierter Branchen unterliegen Governance-Anforderungen, die sich wesentlich von den Standardvorgaben des kommerziellen Sektors unterscheiden, und die Wahl der Projektmanagement-Plattform muss diesen Anforderungen Rechnung tragen.

Regeln zur Datensouveränität können den Speicherort von Projektdaten, einschließlich Risikoregistern, Schwachstellenberichten und Prüfdokumenten, einschränken. Anbieter müssen konkrete Rechenzentrumsstandorte zusichern können und dürfen sich nicht nur auf die allgemeine regionale Verfügbarkeit beschränken. Die Bereitstellung in einem eigenen Rechenzentrum oder in einer behördlich zertifizierten Cloud kann durch Richtlinien oder Verträge vorgeschrieben sein. Organisationen sollten den angegebenen Autorisierungsstatus direkt bei der zuständigen Stelle überprüfen. Die Nutzung eines Cloud-Anbieters, der FedRAMP-Workloads unterstützt, führt nicht automatisch zu einer FedRAMP-Autorisierung des Produkts. Die Autorisierung bezieht sich auf das Produkt selbst, nicht auf die zugrunde liegende Infrastruktur.

Die Identitätsanforderungen im öffentlichen Sektor erfordern häufig eine PIV/CAC-Authentifizierung oder die SAML-Integration mit staatlichen Identitätsanbietern, verbunden mit einer strikten Durchsetzung des Prinzips der minimalen Berechtigungen. Aufbewahrungsfristen für Audit-Protokolle und Nachweisformate müssen den spezifischen Anforderungen der jeweiligen Regierung entsprechen, und die Protokolle müssen in prüfbaren Formaten exportierbar sein.

Die On-Premises-Bereitstellungsoption von Celoxis ist hier von direkter Relevanz. Organisationen, die Projektdaten nicht in einer kommerziellen Cloud speichern können, können Celoxis in ihrer eigenen Infrastruktur implementieren und so die volle Kontrolle über Datenstandort, Zugriff und Aufbewahrung behalten, während sie gleichzeitig von den Funktionen für Enterprise-Projektmanagement und Portfoliomanagement profitieren.

Dieses Szenario ist repräsentativ und basiert auf gängigen Mustern in Sicherheitsprogrammen von Unternehmen. Es stellt keinen spezifischen Celoxis-Kunden dar, sondern spiegelt die realen Herausforderungen wider, denen sich Sicherheitsmanager bei der Verwaltung von Compliance-Zertifizierungen und der gleichzeitigen aktiven Behebung von Sicherheitslücken gegenübersehen.

Die Situation

Ein mittelständisches Finanzdienstleistungsunternehmen hat sich zur Erlangung der ISO/IEC 27001:2022-Zertifizierung verpflichtet. Der Vorstand hat eine feste Frist gesetzt: Das externe Audit findet in 22 Wochen statt. Zwei Wochen vor dem Einsatz des Sicherheitsprojektmanagers liefert ein interner Penetrationstest Ergebnisse, die nicht ignoriert werden können: vier kritische und elf schwerwiegende Schwachstellen, die alle dokumentierte Behebungsmaßnahmen erfordern, bevor das Auditfenster beginnt.

Viele Sicherheitsprojektmanager kennen diese Situation nur zu gut. Man fängt zwar nicht bei null an, aber auch nicht bei null. Es gilt, ein Compliance-Programm umzusetzen, einen Berg an zu behebenden Sicherheitslücken abzuarbeiten, ein funktionsübergreifendes Team zu bilden, das noch nicht formell abgestimmt ist, und einen Audittermin zu haben, der sich nicht verschieben lässt.

Der erste Impuls eines Sicherheitsprojektmanagers ist oft, eine Tabelle zu erstellen und Aufgaben zuzuweisen. Dieser Impuls ist verständlich, führt aber auch häufig dazu, dass Projekte die Kontrolle verlieren. Im Folgenden wird erläutert, wie sich dieses Szenario verändert, wenn das SECURE-Framework in Celoxis angewendet wird.

Umfang und Charter

Die erste Aufgabe des Sicherheitsprojektmanagers besteht nicht darin, eine Aufgabenliste zu erstellen, sondern darin, festzulegen, was „abgeschlossen“ für dieses Programm bedeutet. In Zusammenarbeit mit dem CISO und dem benannten Risikoverantwortlichen erstellt der Projektmanager in Celoxis einen Projektauftrag, der den Geltungsbereich des ISMS (Kundendatenverarbeitungssysteme, Cloud-Infrastruktur und zentrale HR-Prozesse), die Sicherheitsakzeptanzkriterien für die Auditbereitschaft, die Nachweisanforderungen pro Kontrolle und den verbindlichen Audittermin definiert.

Diese Charta ist kein Dokument, das abgelegt und vergessen wird. Bei Celoxis dient sie als maßgebliche Grundlage für alle nachfolgenden Diskussionen zum Geltungsbereich, Änderungsanträge und Entscheidungen zur Ressourcenzuweisung. Fragt das Infrastrukturteam später, ob ein älterer Server in den Geltungsbereich des ISMS aufgenommen werden muss, findet sich die Antwort in der Charta – vereinbart, datiert und vom Sponsor unterzeichnet.

Umwandlung von 93 Kontrollpunkten in einen Lieferplan

Eine Gap-Analyse anhand von ISO/IEC 27001:2022 Anhang A identifiziert 17 Kontrolllücken, in denen die Organisation entweder über keine Kontrollmechanismen verfügt oder deren vorhandene Kontrollmechanismen derzeit keine auditfähigen Nachweise liefern können. Jede Lücke wird als Arbeitspaket im Celoxis-Projektplan definiert und mithilfe eines benutzerdefinierten Felds dem entsprechenden Kontrollmechanismus aus Anhang A zugeordnet. Diese Zuordnung wandelt ein Governance-Dokument in einen konkreten Zeitplan um.

Die vier kritischen Ergebnisse des Penetrationstests werden jeweils in Behebungsaufgaben mit zweiwöchigen SLAs umgewandelt. Die elf schwerwiegenden Ergebnisse unterliegen vierwöchigen SLAs. Jeder Aufgabe ist ein anhand des Ressourcenplans benannter Verantwortlicher zugeordnet, es werden Nachweise benötigt und ein Akzeptanzkriterium definiert, das genau festlegt, was „behoben“ bedeutet – nicht nur „Problem behoben“, sondern „Problem behoben, Regressionstest durchgeführt und DAST-Rescan bestätigt, dass keine Sicherheitslücken vorhanden sind“

An diesem Punkt verfügt der Sicherheitsprojektmanager nicht nur über eine Aufgabenliste, sondern über eine vollständige Projektbasislinie: 93 Kontrollen sind berücksichtigt, Lücken sind Arbeitspaketen zugeordnet, Ergebnisse von Penetrationstests befinden sich im Behebungsrückstand, Verantwortliche sind bestätigt und die 22-wöchige Prüfungsfrist ist als maßgeblicher Meilenstein im Gantt-Diagramm sichtbar.

Wo Abhängigkeiten ein echtes Risiko schaffen

In der Praxis zeigen Implementierungen von ISO 27001 fast immer Abhängigkeiten, die zu Beginn nicht vorhergesehen wurden. In diesem Fall tritt die bedeutendste Abhängigkeit erst nach vier Wochen auf.

Die Aktualisierung der Lieferantenvereinbarung gemäß ISO 27001 A.5.20, die die Informationssicherheit in Lieferantenbeziehungen regelt, hängt von der Überprüfung aller Drittverträge durch die Rechtsabteilung ab. Diese Überprüfung, die ursprünglich auf zwei Wochen angesetzt war, dauert nun schon drei Wochen, ohne dass ein Endtermin feststeht.

Da diese Aufgabe in Celoxis als Vorläufer des Meilensteins für die Einreichung der Prüfnachweise abgebildet ist, wird die Verzögerung sofort sichtbar und nicht erst in der Woche vor dem Audit entdeckt. Der Sicherheitsprojektmanager eskaliert die Angelegenheit an den CISO und dokumentiert die Abhängigkeit, quantifiziert die Auswirkungen auf den Zeitplan und skizziert zwei Optionen: die rechtliche Prüfung mit zusätzlichen Ressourcen zu beschleunigen oder formell zu akzeptieren, dass die Nachweise gemäß A.5.20 nur teilweise eingereicht werden, und dem Prüfer ein Argument für kompensierende Kontrollmaßnahmen vorzulegen.

Das ist eine Entscheidung der Unternehmensführung, keine Entscheidung des Projektmanagements. Sie kann aber nur zum richtigen Zeitpunkt und mit den richtigen Informationen getroffen werden, weil die Abhängigkeit bewusst herbeigeführt und nicht einfach angenommen wurde.

Sicherheitstore als echte Kontrollpunkte

Vier Wochen vor Beginn des Auditzeitraums wird in Celoxis die erste wichtige Sicherheitsprüfung ausgelöst. Bevor die Prüfung der Nachweise beginnen kann, müssen der Sicherheitsbeauftragte und der CISO die Vollständigkeit des Nachweisregisters formell bestätigen. Dabei muss sichergestellt sein, dass jeder relevante Kontrollpunkt einen zugehörigen Nachweis besitzt, dass jeder Nachweis von einem benannten Genehmiger geprüft wurde und dass keine Lücken ungelöst oder nicht akzeptiert sind.

Dies ist kein Meeting mit anschließender E-Mail. In Celoxis ist der Genehmigungsprozess ein Prozess: Der Sicherheitsverantwortliche prüft und genehmigt, anschließend prüft und genehmigt der CISO. Der Eintrag wird mit einem Zeitstempel versehen und als Teil des Projekt-Audit-Trails gespeichert. Meldet einer der Genehmiger eine unvollständige Kontrolle, wird der Prozess gestoppt und die Aufgabe mit dem entsprechenden Vermerk an den Verantwortlichen zurückgesendet.

Genau diese Art von Kontrollpunkt ist für revisionssichere Nachweise erforderlich und genau diese Art von Kontrollpunkt wird übersprungen, wenn Sicherheitsprogramme unter Zeitdruck in Tabellenkalkulationen verwaltet werden.

Wie das Programm endet

In Woche 22 wird das Programm abgeschlossen. Alle 93 Kontrollen gemäß Anhang A sind im Celoxis-Nachweisregister dokumentiert, jeweils mit Speicherort, Prüfstatus und Genehmiger. Drei Restrisikobereiche, die das Unternehmen akzeptiert statt zu beheben, wurden formell im Rahmen des Celoxis-Risikomanagement-Workflows bearbeitet. Die Dokumentation enthält die Begründung, den benannten Risikoverantwortlichen, das Ablaufdatum und die Genehmigung des Vorstands.

Der CISO hatte während der gesamten 22 Wochen über sein Celoxis-Dashboard einen Echtzeit-Überblick über die Kontrollabschlussrate, die SLA-Einhaltung und offene Risikopunkte. Es mussten keine wöchentlichen manuellen Berichte erstellt werden, keine Statusmeetings, in denen die Hälfte der Zeit damit verbracht wurde, die tatsächlichen Fakten zu klären, und keine hektischen Suchen nach Beweismitteln in letzter Minute, die zwar gesammelt, aber nie ordnungsgemäß abgelegt wurden.

Was dieses Szenario veranschaulicht

Das Finanzdienstleistungsunternehmen in diesem Szenario war nicht erfolgreich, weil es über besseres Sicherheitswissen oder ein kompetenteres Team verfügte als Organisationen, die bei ihrem ersten ISO-27001-Audit scheitern. Der Erfolg beruhte vielmehr auf der strukturierten Umsetzung. Die Lücke zwischen den Governance-Anforderungen und den erbrachten Nachweisen wurde durch diszipliniertes Projektmanagement geschlossen, unterstützt durch eine Plattform, die Risiko-, Abhängigkeits-, Nachweis- und Genehmigungsworkflows in den normalen Projektabwicklungsprozess integrierte, anstatt sie als zusätzliche administrative Belastung darzustellen.

Das ist der Beitrag von Celoxis zum Projektmanagement im Bereich Cybersicherheit. Nicht die Sicherheitsexpertise Ihres Teams, sondern die Struktur, die sicherstellt, dass diese Expertise auch Ergebnisse liefert.

Sicherheits-Governance gibt Organisationen vor, was zu tun ist. Technische Sicherheitstools decken Schwachstellen auf. GRC-Plattformen strukturieren Kontrollen, Risiken und Nachweise in einem Compliance-Rahmen. Keine dieser Ebenen allein gewährleistet jedoch, dass die richtigen Aufgaben von den richtigen Personen im richtigen Zeitrahmen und mit den entsprechenden Nachweisen erledigt werden.

Das ist das Ausführungsproblem, und genau hier versagen die meisten Sicherheitsprogramme.

Celoxis bietet Sicherheits-PMOs die nötige Struktur, um dieses Problem zu lösen. Von der Portfolio-Transparenz über mehrere parallel laufende Sicherheitsinitiativen hinweg über Gantt-Diagramme mit Sicherheits-Checkpoints bis hin zu konfigurierbaren RAID-Workflows, Ressourcenkapazitätsplanung, Genehmigungsprozessen mit Audit-Trails und Echtzeit-Management-Dashboards – Celoxis ist darauf ausgelegt, die Anforderungen an die Sicherheits-Governance mit den gewünschten Ergebnissen zu verknüpfen.

Sicherheitssysteme erkennen, was behoben werden muss. GRC-Plattformen definieren die Anforderungen. Celoxis sorgt für die Umsetzung.