IT-Sicherheit von Anfang an

Der kritische Faktor für das Thema Sicherheit bei IT-Projekten ist der Zeitpunkt. Zu oft werden Projekte aus kaufmännischer oder funktionaler Sicht betrachtet und als Proof-of-Concept realisiert, ohne IT-Security-Themen auch nur in Betracht zu ziehen. Erfolgsaussichten und finanzielle Forecasts werden erstellt, dann kommt es zur Realisierungsphase in der Sicherheits- und Datenschutzanforderungen zum Vorschein kommen. Diese können im schlimmsten Falle den gesamten Business Case zerstören. Zumindest sind aber für gewöhnlich Anpassungen vonnöten, die den Projektplan beeinflussen und für die Beteiligten zum Störfaktor werden können. Je nachdem, wie weit der Proof-of-Concept als technische Basis für die Realisierung dienen soll, kann aufgrund der Sicherheitsanforderung eine komplette Neuentwicklung notwendig sein. Sollte man Sicherheitsanforderungen auf das nächste Release nach dem Go-Live verschieben, vergrößern sich die Probleme massiv, was sich selbstverständlich auch beim Budget entsprechend bemerkbar macht. Ein scheidender Projektleiter kann so auch seinem Nachfolger eine entsprechende Bürde "vererben". Wie die Praxis zeigt, werden sich jegliche Kompromisse bei der Realisierung langfristig als nicht tragbar und teuer erweisen.

Sollten bereits Verträge mit Lieferanten und anderen Partnern - zum Beispiel für Entwicklungs- oder Hosting-Leistungen - geschlossen worden sein, bevor Sicherheitsanforderungen betrachtet wurden, entstehen ebenfalls massive Probleme für das Gesamtprojekt. Alle Lieferanten müssen nämlich auf die Sicherheitsanforderungen vertraglich verpflichtet, Standard-Verträge entsprechend inhaltlich geprüft werden. Sollten diese ohnehin nicht anpassbar sein, etwa weil eine gewisse Abhängigkeit besteht, muss selbstständig Vorsorge getroffen werden - schlimmstenfalls durch das eigene Risikomanagement. Viele Web-Agenturen beispielsweise, die knappe Preiskalkulationen vornehmen um konkurrenzfähig sein zu können, werden Anforderungen aus Sicherheitskatalogen gesondert berechnen müssen. Auch hier ist es wichtig, entsprechende Planungen frühzeitig in das Projekt einzubinden.

Ein praktisches Beispiel: In einem IT-Projekt soll ein Web-Shop unter Verwendung einer Standard-Software aufgebaut werden. Dies umfasst unter anderem Installation und Hosting. Änderungen an der Shop-Software sind nicht vereinbart. Das Hosting muss neben einer Härtung der IT-Systeme auch Patch-Management beinhalten. Dieses muss für die gesamte Betriebszeit des Web-Shops vorgesehen sein und bei kritischen Sicherheitsupdates der Shop-Software zeitnah erfolgen. Sollte dies vertraglich nicht vereinbart sein, werden Mehrkosten entstehen. Alternativ muss der Inhaber des Shops einen eigenen Prozess dafür betreiben und entsprechend Personal abstellen.

In der Praxis lässt sich beobachten, das selbst Unternehmen mit einer eigenen IT-Sicherheits-Abteilung, diese oft zu spät nutzen. Meetings von potentiellen Projektteams sollten beispielsweise durch einen Sicherheitsberater - und übrigens auch einen Datenschutzberater - begleitet werden. So können Sicherheits- und Datenschutzanforderungen frühzeitig erkannt und No-Gos vermieden werden. Zudem sind IT-Sicherheitsberater aufgrund ihrer Projekterfahrung in der Regel auch in der Lage, einfachere technische Alternativen vorzuschlagen. Die Begleitung durch einen Sicherheitsberater ist bereits bei Meetings zur Ideenentwicklung - also ohne technischen Charakter - ratsam. Scheitern Projekte am Thema IT-Sicherheit, dann in der Regel an lange existierenden, aber dem Projektteam unbekannten (oder nicht-beachteten) Anforderungen.

Sicherheit ist immer als Prozess zu verstehen

IT-Sicherheit verursacht laufende Kosten und benötigt Personal. Letzteres muss aber nicht zwangsläufig in Vollzeit angestellt sein, denn Sicherheit ist ein Prozess. Dies gilt für IT-Projekte aller Art.

• Beispiel A: Eine eigens entwickelte Web-Anwendung wird in Betrieb genommen. Im Laufe des Betriebs werden Sicherheitslücken gemeldet. Es muss ein Prozess existieren, diese Meldungen entgegenzunehmen, zu prüfen und zu bereinigen. Ist die Software selbst entwickelt, muss dieser Prozess im Unternehmen selbst etabliert werden. Handelt es sich bei der Software um eine externe Auftragsleistung, muss mit dem Lieferanten eine entsprechende Vereinbarung getroffen sein. Die Schnittstelle der internen und externen Prozesse muss definiert sein, ebenso wie entsprechende Service Level Agreements, etwa zur maximalen Bearbeitungsdauer und generellen Kostenübernahme.

• Beispiel B: Eine Standard-Anwendung wird im Internet gehostet. Die Systeme wurden initial gehärtet. Durch das Auftreten neu entdeckter Sicherheitslücken in Standard-Software muss ein Patch-Management-Prozess etabliert sein. Dieser beinhaltet unter anderem die Sichtung und Einspielung von Patches. Sicherheitskritische Patches müssen zeitnah gesichtet und vorgenommen werden können. Je nach der Komplexität der Anwendung ist hierfür ein gesondertes Test-System neben dem eigentlichen Produktivsystem notwendig, um die einwandfreie Funktionsweise des Systems nach dem Patchen garantieren zu können. Auch sollten regelmäßige Penetrationstests obligatorisch sein, um sicherzustellen, dass keine Komponente beim Patchen ausgelassen wird.

• Beispiel C: Ein System erlaubt nicht nur Systemadministratoren, sondern auch bestimmten applikativen Rollen Zugriff auf Kundendaten. Dazu wurde ein angemessenes Logging von Zugriffsaktionen umgesetzt. Selbst wenn ein Automatismus etabliert wurde, der eine Missbrauchserkennung beinhaltet, muss eine entsprechende Detektion an eine Person gemeldet und von dieser geprüft werden. Hierfür ist ein Prozess zu etablieren. Unabhängig davon sind regelmäßige Audits aus Datenschutzsicht durchzuführen.

• Beispiel D: Für das Hosting von Systemen wird eine Intrusion Detection eingerichtet. Diese erlaubt ein Monitoring über ungewöhnliche Ereignisse und potentielle Angriffe. Von gewissen Automatismen abgesehen, ist es notwendig, dass geeignetes Personal dieses Monitoring überwacht und gegebenenfalls Gegenmaßnahmen einleitet.

Neben diesen praktischen Beispielen gilt beim Thema IT-Sicherheit das gleiche wie in allen anderen Bereichen: Mit jedem neuen Projekt lernt man dazu und passt die eigene Prozesse entsprechend an.