Sicherheit richtig umsetzen

IT-Security für Projektleiter

07.06.2016
Von 
Frank Hißen studierte an der TU Darmstadt Informatik mit Schwerpunkt IT-Sicherheit. Seit über 15 Jahren arbeitet er als Software-Entwickler und IT-Berater; machte sich 2009 selbständig. Er ist sowohl für große aber auch mittelständische Unternehmen tätig. Im Bereich IT-Security ist Frank Hißen spezialisiert auf Applikationssicherheit und Kryptographie, im Entwicklungsbereich vor allem auf Java.

IT-Sicherheit: Checkliste für Projektleiter

Die folgende Checkliste soll IT-Projektleitern als Orientierung dienen, um die oftmals unterschätzten Themen der IT-Sicherheit im Projekt umzusetzen. Die Liste erhebt keinen Anspruch auf Vollständigkeit. IT-Projekte unterscheiden sich erheblich in ihren Anforderungen. Sollten unternehmensweite Anforderungen gelten, sind diese selbstverständlich an erster Stelle zu beachten. Bei internationalen Projekten müssen gegebenenfalls länderspezifische Anforderungen, insbesondere auch an den Datenschutz, geprüft werden.

Sicherheitsanforderungen werden auf verschiedenen technischen Ebenen eines Projektes definiert. Da sich IT-Projekte stark unterscheiden, soll die folgende Aufstellung lediglich als Hilfe dienen, um frühzeitig bestimmte Sicherheitsthemen in einem Projekt aufzugreifen. Sie kann je nach Projekt nur teilweise oder auch gar nicht zutreffend sein. Ein vollständiges Sicherheitskonzept jedoch sollte mindestens all diese Ebenen abdecken.

Ähnlich des OSI-Schichtenmodells müssen die verschiedenen technischen Ebenen untersucht werden, die für ein Projekt zutreffend sein können:

  • Netzwerkebene: Hierzu zählen das Netzwerkkonzept (zum Beispiel die passende Segmentierung) und alle Netzwerkkomponenten wie Switches, Router, Netzwerk-Firewalls, VLAN-Einstellungen und WLAN-Access-Points. Erweiterte Komponenten könnten Intrusion-Detection- oder Intrusion-Prevention-Systeme sein (IDS/IPS).

  • Virtualisierungs-Ebene: Sollten virtualisierte Komponenten zum Einsatz kommen, muss die Virtualisierungsmanagement-Software geeignet konfiguriert und gehärtet werden. Es muss ebenfalls überprüft werden, ob durch die Virtualisierung ein für das Projekt angemessenes Sicherheitsniveau erreicht werden kann.

  • Betriebssystemebene & Applikationsebene: Neben der eigentlichen Anwendungen zählen hierzu auch verwendete Bibliotheken, Erweiterungen, Laufzeitumgebungen, Server-Komponenten (zum Beispiel Web-Server) und Middleware-Komponenten. Hierbei muss der Betrieb aktueller und sicherer Software genauso sichergestellt werden wie die sichere Konfiguration aller Komponenten (zum Beispiel Web-Server-Konfiguration), im Allgemeinen spricht man von der System-Härtung. Ebenfalls in diese Kategorie gehören erweiterte Sicherheitskomponenten wie Application-Level Firewalls.

Weitere Themen, die das Projekt für jeweils alle technischen Ebenen beinhalten muss, sind:

  • Rollen und Berechtigungen

  • Monitoring und Logging (etwa Systemverhalten, Login- und Zugriffsmuster)

  • Anmeldemethoden für ein angemessenes Sicherheitsniveau (zum Beispiel Passwort-Authentifizierung, Zwei-Faktor-Authentifizierung)

  • Verschlüsselungskonzept: Es ist zu klären, ob für ein angemessenes Sicherheitsniveau ein Verschlüsselungskonzept notwendig ist, etwa durch die Nutzung von Datenbank-, Datei-, Festplatten- oder E-Mail-Verschlüsselungslösungen.

  • Betriebssicherheit und Ausfallsicherheit

  • Zugangsschutz / Zutrittsschutz bei physischem Zutritt zu IT-Systemen

Secure Programming:

  • Bei Eigenentwicklungen, unabhängig davon ob diese Inhouse stattfinden oder beauftragt werden, müssen zusätzlich Maßnahmen ergriffen werden, die ein "Secure Programming" sicherstellen. Dazu sollte man auf die zuvor genannten Sicherheitsstandards zurückgreifen. Die Anforderungen, die sich hier ergeben, sind stark abhängig vom jeweiligen Entwicklungskontext und der gewählten Programmierumgebung. So unterscheiden sich beispielsweise die Sicherheitsanforderungen an Windows-Programme, mobile Apps, Web-Anwendungen oder ABAP-Anwendungen für SAP im Vergleich erheblich. Selbst bei mobilen Apps alleine muss man abhängig von den unterschiedlichen mobilen Betriebssystemen verschiedene Sicherheitskonzepte vorsehen (zum Beispiel für iOS, Android oder Windows).

  • Es können auch branchenspezifische Sicherheitsanforderungen existieren, etwa PCI-PA-DSS für Kreditkarten-Applikationen. Bei Web-basierten Anwendungen können die allgemeinen Standards des zuvor genannten OWASP herangezogen werden.

Projektidee und -entwicklung:

  • Nach der Entstehung der Projekt- oder Produktidee werden erste Entwürfe mit IT-Sicherheitsspezialisten und Datenschutzspezialisten diskutiert.

  • Anforderungen und Anmerkungen der Spezialisten werden aufgenommen und im Projektteam vorgestellt. Daraus entstehende Fragen und abgeänderte Realisierungsideen werden gegebenenfalls mit den Spezialisten erneut diskutiert.

Projekt-Kick-Off:

  • Zum Projekt-Kick-Off werden alle Projektbeteiligten geladen - inklusive der Sicherheits- und Datenschutzspezialisten. Im Idealfall dienen die Spezialisten dem Projektteam als direkt oder zumindest als indirekte Ansprechpartner über den gesamten Projektzeitraum.

Definition des Sicherheitskonzeptes:

  • Sind Sie Teil eines großen Unternehmens mit etabliertem IT-Sicherheitsprozess, dann werden Sie bereits die Sicherheitsanforderungen für IT-Projekte kennen. In der Regel muss für jedes IT-Projekt ein passender Katalog an Anforderungen zusammengestellt werden, da sich IT-Projekte in Art und Inhalt stark unterscheiden und daher nicht alle Anforderungen für alle Projekte gelten. Auch können Projekte aufgrund ihrer Thematik neue Anforderungen notwendig machen, etwa um gesetzliche Auflagen zu erfüllen.

  • Haben Sie keine vorgegebenen Sicherheitsanforderungen, müssen Sie selbst einen Anforderungskatalog erstellen oder durch externe Hilfe erstellen lassen. Dabei ist es ratsam, die Rolle des Sicherheitsspezialisten von der ausführenden Rolle zu trennen. Es macht zum Beispiel keinen Sinn, eine Web-Agentur ihre selbst-definierten Sicherheitsanforderungen kontrollieren zu lassen. Dies ist für die Agentur intern natürlich sinnvoll, aber für Sie als Abnehmer einer Dienstleistung keineswegs. Beachten Sie, dass in der Regel ein externer Sicherheitsspezialist den kleinsten Anteil an Ihrem Gesamtprojektbudget haben wird. Definieren Sie den Katalog an Sicherheitsanforderungen selbst, können Sie sich an einem der zuvor genannten etablierten Sicherheitsstandards orientieren oder sich auf diesen beziehen. Je nach Projektumfang kann eine bestimmte Untermenge sinnvoll sein. Alternativ können Sie auch nach weiteren, in Ihrer Branche etablierten Sicherheitsstandards suchen.

  • Als kleineres Unternehmen beispielsweise, dass sich von einer Web-Agentur einen Web-Shop realisieren lässt, sollte die zuvor genannte "OWASP Top Ten" als Mindestanforderung in den Vertrag aufnehmen. Dazu kommen Fragen nach der Sicherheit beim Web-Hosting: Hostet die Agentur selbst oder wird dafür ein etablierter Dienstleister genutzt? Wer setzt das Patch-Management um (Betriebssystemebene, Applikationsebene)?

Externe Dienstleister:

  • Werden externe Dienstleister für das Projekt eingebunden, zum Beispiel für Hosting, Aufbau, Installation, Software-Entwicklung oder Lieferung von Standard-Software, werden diese auch auf IT-Sicherheit vertraglich verpflichtet. In der Ausgestaltung der Verträge sollten gewisse Mindestanforderungen konkret spezifiziert werden. Sollten Sicherheitslücken nach Inbetriebnahme auftreten, muss - gegebenenfalls unter Berücksichtigung zusätzlicher Kosten - ein entsprechendes Bugfixing vorgesehen werden. Sollte etwa gelieferte Software schon bei Abnahme gegen die vereinbarten Sicherheitskriterien verstoßen, sollte eine für den Auftraggeber kostenfreie Behebung der Sicherheitslücken vorgesehen sein.

Technische Abnahme:

  • Egal ob selbst-entwickelt oder geliefert durch externe Dienstleister, jedes Projekt muss abgenommen werden. Neben der funktionalen Abnahme ist die technische Sicherheitsabnahme ein Muss in jedem IT-Projekt. Hierzu zählt mindestens die stichprobenartige Überprüfung von Versionsständen, um zum Beispiel veraltete Software zu identifizieren und gegebenenfalls daraus sogar die grundsätzliche Qualität der abgelieferten Leistung einzuschätzen. Im Idealfall dient zur Abnahme ein echter Penetrationstest. Dieser kann im übrigen nicht nur bei Web-basierten Applikationen erfolgen, in entsprechend angepasster Form gibt es auch Sicherheitstests für Desktop-Anwendungen, mobile Apps und Server-Dienste wie Mail-Server.

  • Die Abnahme bezieht sich stets auf die zuvor vereinbarten Sicherheitsanforderungen. Was nicht vereinbart wurde, kann auch nicht eingefordert werden oder verursacht Mehrkosten.

Laufende Sicherheitsprozesse:

Als grober Überblick über die gängigen Sicherheitsprozesse im operativen Bereich von IT-Systemen soll folgende Aufstellung dienen:

  • Patch-Management: Für alle verwendeten Komponenten des Gesamtsystems müssen Patchstände überwacht und aktualisiert werden sofern dies Sicherheitsrelevanz besitzt. Dazu zählen zum Beispiel: Firewalls, Betriebssysteme, Middleware-Komponenten, Web-Server, Application-Server, Runtimes, Anwendungen allgemein.

  • Regelmäßiger Penetrationstests: Aufgrund sich ändernder Gefahrenlagen und neuer Angriffe sollte ein regelmäßiger Penetrationstest Teil des Betriebs sein. Die Häufigkeit hängt vom jeweiligen Projekt ab, empfehlenswert ist jedoch einmal jährlich. Es empfiehlt sich dabei, den ausführenden Penetrationstester in gewissen Intervallen zu wechseln, um monotones Testverhalten zu meiden. Für Nachtests ist es selbstverständlich zeit- und kosteneffizient, den gleichen Penetrationstester zu beauftragen.

  • Monitoring von sicherheitsrelevanten Zugriffen: Operative Zugriffe wie Administrator-Aktionen sowie Logs von Sicherheitskomponenten wie Intrusion-Detection-Systemen, Application-Level Firewalls oder ähnlichem müssen regelmäßig gesichtet werden. Sicherheitskritische Ereignisse müssen an geeignetes Personal geleitet und von diesen bearbeitet werden.

  • Monitoring von applikativen Zugriffen gegen Missbrauch: Datenzugriffe, etwa auf Kundendaten, durch Mitarbeiter müssen auditierbar sein, aber auch bei konkreten aktuellen Verdachtsfällen zeitnah erkannt werden. Daher müssen eingerichtete Zugriffskontrollen auf Applikationsebene in einem für das Projekt sinnvollen Prozess überprüfbar gemacht werden.

Betriebssicherheit:

  • Falls Sie Maßnahmen zur Ausfallsicherheit und Hochverfügbarkeit benötigen, werden Sie in der Regel einen weiteren Spezialisten im administrativen Bereich benötigen. Zumindest sollte im Projekt definiert sein, wo die maximal tolerierbaren Ausfallzeiten für die verwendeten IT-Systeme liegen. Sind Vertragspartner für diese Fälle vorgesehen, müssen diese vertraglich auf die entsprechenden Wiederherstellungsprozesse und Service Level Agreements verpflichtet werden.

  • Ein weiteres, zentrales Thema der Betriebssicherheit ist Backup & Wiederherstellung. Dazu zählen insbesondere alle sich ändernden (Nutzer-)Daten aus Datenbanken, NAS und sonstigen Speicherorten. Auch wenn es aufwendig ist, das korrekte Funktionieren eines Backups kann nur getestet werden, in dem eine Wiederherstellung auf einem nicht-installierten System versucht wird. Nur so kann man sicherstellen, für den Ernstfall vorbereitet zu sein. Wenngleich man diesen Prozess nicht regelmäßig durchführen möchte, sollte er zumindest einmalig vor dem Go-Live durchgeführt werden.