IT-Sicherheit im Projekt: Warum sie nicht ans Ende gehört
Werfen Sie einen Blick in den nächsten Projektplan, der auf Ihrem Schreibtisch liegt. Irgendwo zwischen "Abnahme" und "Go-live" steht vermutlich ein Punkt namens "Sicherheitsfreigabe" oder "Pentest" (ein simulierter Hackerangriff, der gezielt nach Schwachstellen sucht). Meist ganz am Ende, kurz vor dem großen Knopfdruck. Genau dort liegt das Problem: Sicherheit wird behandelt wie eine Endkontrolle, nicht wie eine Anforderung. Dabei entscheidet sich der größte Teil des Sicherheitsniveaus eines Projekts bereits in der Konzeptphase – lange bevor überhaupt jemand an einen Test denkt.
Warum Sicherheit meist ganz am Schluss landet
Das hat selten mit Nachlässigkeit zu tun, sondern mit der Logik von Projekten. Sicherheit erzeugt in der Anfangsphase keinen sichtbaren Fortschritt – sie bremst eher, weil sie Fragen aufwirft, die noch niemand beantworten will: Wer greift wie auf welche Daten zu? Was passiert, wenn eine Schnittstelle kompromittiert wird? Solche Fragen passen schlecht zu einem Kickoff, bei dem alle über Meilensteine und schnelle Ergebnisse sprechen wollen. Also wird Sicherheit vertagt – "das klären wir später mit der IT" – und taucht erst wieder auf, wenn das System technisch fertig ist und eine Abnahme ansteht. Zu diesem Zeitpunkt sind Architekturentscheidungen längst getroffen, Schnittstellen längst gebaut. Was der Pentest dann findet, lässt sich nicht mehr elegant beheben, sondern nur noch teuer nachrüsten.
Was sich ändert, wenn Sicherheit von Anfang an mitgeplant wird
In der Softwareentwicklung hat sich dafür der Begriff "Shift-Left-Security" etabliert: Sicherheitsfragen wandern von der Testphase zurück an den Anfang, in die Design- und Anforderungsphase. Übertragen auf klassisches und agiles Projektmanagement heißt das vor allem eines: Ein einfaches Bedrohungsmodell gehört in die Konzeptphase, nicht in den Testplan. Wer schon beim Entwurf grob durchspielt, welche Daten, Zugänge und Schnittstellen besonders schützenswert sind, trifft bessere Architekturentscheidungen – und muss sie später nicht mehr revidieren. Ein solches Bedrohungsmodell muss dabei nicht aufwendig sein: Oft reicht eine halbe Stunde im Kernteam mit drei einfachen Fragen – Was wollen wir schützen? Wer könnte ein Interesse daran haben, es anzugreifen? Und was würde im schlimmsten Fall passieren? Diese halbe Stunde verändert häufig schon die Architekturentscheidungen der folgenden Wochen.
Der Effekt ist nicht nur qualitativer Natur: Ein Fehler, der in der Planungsphase auffällt, lässt sich in aller Regel mit einer Anpassung auf dem Papier lösen. Derselbe Fehler, erst beim Pentest entdeckt, bedeutet oft Nacharbeit an bereits gebauter Software oder Infrastruktur – mit allem, was das an Zeit, Budget und Nerven kostet. Genau dieses Ungleichgewicht ist einer der Gründe, warum sich frühe Sicherheitsarbeit in aller Regel auszahlt, obwohl sie zu Beginn wie ein Umweg wirkt.
Vier Stellschrauben für die Praxis
Wer Sicherheit strukturell früher verankern will, kommt mit vier Punkten schon ein gutes Stück weiter. Erstens: eine feste Rolle statt einer Nebenaufgabe. Jemand im Projekt – nicht "die IT" als anonyme Instanz – trägt sichtbar die Verantwortung dafür, dass Sicherheitsfragen gestellt und beantwortet werden, von Anfang an. Zweitens: Sicherheitskriterien gehören in die Definition of Done, nicht in eine separate Freigabeschleife danach. Ein Feature ist erst fertig, wenn auch die dazugehörigen Sicherheitsanforderungen erfüllt sind – nicht vorher. Drittens: Ein einfaches Register für Drittanbieter und externe Zugänge hilft, Berechtigungen von Beginn an nach dem Prinzip der minimalen Rechtevergabe zu vergeben, statt sie im Projektverlauf immer weiter aufzuweichen. Viertens: klare Eskalationswege für den Fall, dass während des Projekts eine Auffälligkeit entdeckt wird – wer wird informiert, in welcher Reihenfolge, mit welcher Frist. Für Unternehmen, die unter das NIS-2-Umsetzungsgesetz fallen (die deutsche Umsetzung der EU-Richtlinie zur Cybersicherheit kritischer und wichtiger Einrichtungen) oder eine ISO-27001-Zertifizierung anstreben, ist das ohnehin keine Kür mehr, sondern Teil der Sorgfaltspflicht – Informationssicherheit als fester Bestandteil von Prozessen statt als nachträgliche Ergänzung.
Kurz durchgespielt: Fünf Wochen bis zur Überraschung
Ein Interim-Projektleiter übernimmt bei einem regionalen Energieversorger ein Programm zur Modernisierung der Netzleitstelle. Woche 1: Kickoff, ambitionierter Zeitplan, Sicherheitsanforderungen werden auf die Agenda der nächsten Sitzung vertagt. Woche 3: Die Architektur für die Fernwartungsschnittstelle steht, ein kurzer Einwand aus der IT-Sicherheit dazu wird als "kein Blocker für den Meilenstein" protokolliert. Woche 5, kurz vor der geplanten Abnahme: Der Pentest findet eine Schwachstelle genau in dieser Schnittstelle, die aus Kostengründen nie ernsthaft geprüft wurde. Die Netzleitstelle ging schließlich einige Wochen später ans Netz als ursprünglich geplant – mit genau den Sicherheitsanforderungen, die in Woche 1 niemand terminieren wollte.
Auf den Punkt
Sicherheit, die erst am Ende eines Projekts auftaucht, ist keine Kontrolle mehr, sondern eine teure Überraschung. Wer Bedrohungsmodelle, Zugriffsrechte und Eskalationswege schon in der Konzeptphase mitdenkt, verschiebt keine Arbeit – er verlagert sie nur an den Punkt, an dem sie am wenigsten kostet.
(Erstellt mit KI-Unterstützung, redaktionell geprüft)