Safety, Security, Privacy und Continuity –
Die Überraschung kommt zum Schluss

Wer ein Bürohaus baut, braucht die Expertise eines Architekten. Wer Informationssysteme sicher entwickeln und betreiben will, braucht ebenfalls Expertise, denn Sicherheit ist ein facettenreiches und komplexes Thema. Das zeigen die kontinuierlichen Meldungen von Sicherheitsvorfällen sowie die gesetzgeberischen und normativen Aktivitäten. Fehlt diese Expertise im Unternehmen, so ist das aus Sicht des Unternehmens zwar ungünstig, schafft jedoch die Daseinsberechtigung für Fachberater.
Der folgende Artikel stellt Sicherheit im Lebenszyklus von Informationssystemen in kompakter Form dar und fordert damit Ihre Aufmerksamkeit heraus. Seien Sie also vorgewarnt.
Da Unternehmen verschiedentlich einen Mix aus perfekten Lösungen, Lösungsansätzen und weißen Flecken haben, mögen nicht alle hier angesprochenen Aspekte für Sie relevant sein. Idealerweise sind Sie sogar schon in jeder Hinsicht perfekt aufgestellt und finden sich durch den Artikel in Ihrem Handeln bestätigt. Wenn nicht, picken Sie sich die relevanten Themen heraus und arbeiten an deren Umsetzung.
Ausgangssituation
Gesetzgeber, Aufsichtsbehörden und Wirtschaftsprüfer, aber auch Unternehmen fordern und Kunden erwarten Sicherheit, Datenschutz und Verfügbarkeit der IT-Systeme. Datenschutzgesetz und das IT-Sicherheitsgesetz sowie zunehmende regulatorische Vorgaben betonen dies und die Prüfschärfe durch die Aufsicht nimmt zu. Während die nachträgliche Beseitigung entdeckter Mängel zu Kosten- und Zeitdruck führt, verunsichern erfolgreiche Angriffe den Kunden und erzeugen Management Attention. Neue Technologien schaffen zusätzliche Angriffspunkte und erhöhen die Risiken.
Interne oder externe Auftraggeber fokussieren sich bei der Beschreibung ihrer Software- und IKT-Systemanforderungen auf funktionale Aspekte. Nichtfunktionale Anforderungen, z. B. an Safety, Security, Privacy und Continuity (SSPC) spielen für sie oftmals entweder keine oder nur eine untergeordnete Rolle. Oder der Auftraggeber sieht diesbezüglich den Auftragnehmer in der Pflicht: Er hat nicht artikulierte, d. h. implizite Anforderungen.
Als Folge dieses Vorgehens erkennen die Beteiligten die SSPC-Anforderungen nicht oder erst im späteren Verlauf des Projektes. Dann bessern sie diese entweder zeit- und kostenintensiv nach oder nehmen die Defizite, sprich Schwachstellen oder gar Sicherheitslücken, bei Inbetriebnahme in Kauf, um Zeitpläne einhalten zu können. Hinzu kommt, dass für nachträgliche Änderungen zusätzliche Change Requests gestellt und zusätzliche Genehmigungen eingeholt werden müssen, um SSPC-Anforderungen zu erfüllen.
Um dem entgegenzuwirken, muss der Lebenszyklus von IKT-Systemen SSPC durchgängig berücksichtigen [1,2]. Am Beispiel eines klassischen Vorgehensmodells skizziert der Artikel, welche Sicherheits- und Kontinuitätsmaßnahmen im Lebenszyklus beachtet werden sollten.
Herausforderungen
Sicherheit sieht sich einer Vielzahl von Herausforderungen gegenübergestellt: Da sind zum einen die diesbezüglichen Anforderungen des eigenen Unternehmens, der Kunden und der Anteilseigener, zum anderen die des Gesetzgebers und der Aufsichtsbehörden. Gesetzliche Vorgaben zum Datenschutz, das IT-Sicherheitsgesetz, das Handelsgesetzbuch mit seinen Vorgaben zur Buchführung, aber auch branchenspezifische Gesetze wie das Kreditwesengesetz, das Versicherungsaufsichtsgesetz, das Energiewirtschaftsgesetz und das Chemikaliengesetz mit seinen Grundsätzen der Guten Laborpraxis (GLP) sind Beispiele derartiger Anforderungen. Hinzu kommen z. B. Mindestanforderungen der Bundesanstalt für Finanzdienstleistungsaufsicht (BaFin) sowie der Katalog von Sicherheitsanforderungen der Bundesnetzagentur (BNetzA).
Nicht alle Anforderungen haben Auftraggeber explizit formuliert, wie die Beratungspraxis zeigt. So gehen Nutzer oftmals wie selbstverständlich davon aus, dass ein Produkt oder System sicher sowie jederzeit und überall verfügbar ist, ähnlich wie ein Autokäufer davon ausgeht, dass ein Serien-PKW eine Straßenverkehrszulassung besitzt. Auch Organisationseinheiten im Unternehmen haben oftmals Vorstellungen zum Sicherheits- und Kontinuitätsniveau ihrer IT-Systeme, ohne dies explizit formuliert und abgestimmt zu haben.
Eine weitere Herausforderung ergibt sich aus der Komplexität heutiger Informationssysteme sowie aus deren Verbindung und Kommunikation mit einer Vielzahl anderer Systeme. Die bestehende oftmals heterogene IT-Architektur erhöht die Komplexität weiter. Manchmal weist auch die IT-Architektur bereits Sicherheitslücken auf. Hinzu kommt, dass technische Kommunikationspartner nicht zwangsläufig heutige Sicherheitsstandards erfüllen. Die so entstehende Komplexität, gewachsene Strukturen, Architekturmängel und unzureichend geschützte Systeme liefern Angreifern willkommene Einfallstore.
Meldungen über Informationssicherheitsvorfälle häufen sich:
- Im Frühjahr 2016 lösen Hacker über das internationale Zahlungsverkehrssystem SWIFT dreißig gefälschte Überweisungen der Zentralbank von Bangladesch in Höhe von fast einer Milliarde Dollar aus [3].
- Im Online-Banking einer Bank gibt es ein Darstellungsproblem: Einzahlungen und Abbuchungen werden teilweise doppelt gezeigt und führen so zu tiefrot angezeigten Kontoständen [4].
- Im Mai 2017 werden mit der Verschlüsselungssoftware "WannaCry" weltweit zehntausende Computer erfolgreich angegriffen. Bei der Deutschen Bahn sind Anzeigetafeln in Bahnhöfen und Fahrkartenautomaten betroffen. In Großbritannien sind die Computer mehrerer Krankenhäuser blockiert. In den USA entschuldigt sich der US-Logistikriese FedEx für Ausfälle aufgrund von WannaCry [5].
- Der Domain Name Service eines Webdienstleisters wird Opfer einer DDoS-Attacke ungeahnter Stärke. Dadurch sind Twitter, Netflix, Paypal, Spotify und Amazon über Stunden nicht erreichbar. Hierzu hatten Angreifer internetfähige und oftmals unzureichend gesicherte Haushaltsgeräte, wie Alarmanlagen, Rolladensteuerungen, TV-Festplatten-Receiver, Babyfone, Drucker, Router und IP-Kameras des Internet of Things gekapert und zu einem Hochleistungs-Botnet zusammengeschaltet [6].
Unternehmen agieren heute international und Nutzer sind mobil, die Kommunikation erfolgt drahtlos, Cloud-Computing weckt Interesse und wird – nicht immer mit Kenntnis und im Sinne des Unternehmens – genutzt. Die Angriffsfläche vergrößert sich. Schnell stellt sich die Frage, wer ist Freund, wer Feind?
Budget- und Termindruck bei der Entwicklung neuer Informationssysteme oder auch neuer Produkte mit IT-Innenleben stellen eine zusätzliche Herausforderung dar. Werden Budget und/oder Termine eng, geht es verschiedentlich nur noch um den Abschluss des Projektes oder die Fertigstellung des Produktes. Im ungünstigsten Fall ist es dann egal, in welchem Zustand sich das Projektergebnis bzw. das Produkt befindet. Betriebssicherheit, Informationssicherheit, Datenschutz und Verfügbarkeit und nicht zuletzt die Qualität können da leicht das Nachsehen haben.
Lösung
Um diesen Herausforderungen zu begegnen, müssen nichtfunktionale Anforderungen im Hinblick auf Informationssicherheit, Datenschutz, Betriebssicherheit und Kontinuität im Projektmanagement und im Lebenszyklus von Anwendungen und Systemen von Anfang an und über den gesamten Lebenszyklus hinweg berücksichtigt werden [1,2]. Dies ist unabhängig davon, welche Projektmanagementmethode im Einsatz ist und welche Entwicklungsmethoden, seien es klassische wie das Wasserfall- oder V-Modell oder agile wie Feature oder Test Driven Development, Specification by Example oder Extreme Programming.
Unternehmen, die einen sicheren Lebenszyklus realisieren möchten, sollten Standards und Practices berücksichtigen. Orientierung geben können u. a. das Software Assurance Maturity Model (SAMM) des OWASP, die Security Considerations in the System Development Life Cycle des NIST, der Team Software ProcessSM und die Normenreihe ISO/IEC 27034 zur Anwendungssicherheit.
Die Integration von Sicherheit in den Lebenszyklus setzt zum einen voraus, dass die Beteiligten entsprechend geschult sein müssen. Zum anderen müssen Personen eingebunden werden, die für Beratung und Prüfung in Hinblick auf SSPC zur Verfügung stehen, wenn die Wissenstiefe der Beteiligten nicht ausreicht.
Fachliche Anforderungen
Ausgangspunkt im Lebenszyklus bilden die Anforderungen des jeweiligen internen oder externen Auftraggebers. Sie können methodenspezifisch unterschiedlich erhoben und beschrieben sein. Wesentlich ist, dass der Business Analyst den Kontext, z. B. in Form externer Vorgaben zu SSPC, und das Umfeld mit seinen Akteuren erfasst und berücksichtigt [1]. Er muss außerdem den Schutzbedarf und die Verfügbarkeitsanforderungen erheben, damit in den folgenden Lebenszyklusphasen geeignete Schutzmaßnahmen ergriffen werden können.
Da Überlast zu Störungen und Ausfällen sowie im ungünstigsten Fall auch zu Sicherheitslücken führen kann, sollten die Business Analysten die nichtfunktionalen Anforderungen im Hinblick auf Kapazität und Leistung ebenfalls erheben und festlegen. Der Business Analyst muss zudem ein Rollen- und Berechtigungskonzept entwickeln und nicht zuletzt festlegen, welche Aktivitäten aus fachlicher Sicht zu protokollieren sind [1], z. B. der Zugriff auf personenbezogene Daten.
Bei den fachlichen Anforderungen sollte der Business Analyst zudem darauf eingehen, welche Dokumentationen zu den Liefergegenständen gehören. Beispiele für derartige Liefergegenstände sind das Benutzerhandbuch, das Betriebshandbuch, das Datensicherungskonzept und der Notfallplan [1].
Technisches Design
Das technische Design ist dadurch gekennzeichnet, dass es sowohl die funktionalen als auch die nichtfunktionalen fachlichen Anforderungen auf technischer Ebene umsetzt. Zu beachten ist dabei, dass das neue oder erweiterte System in die bestehende IT- und Sicherheitsarchitektur so zu integrieren ist, dass keine Sicherheitslücken entstehen.
Ein weiterer Aspekt im technischen Design ist die Risikoanalyse. Welche Bedrohungen mit welcher Eintrittswahrscheinlichkeit existieren und welche Schwachstellen bestehen? Wie leicht sind die Schwachstellen auszunutzen und welcher Schaden entsteht bei einer Sicherheitsverletzung oder einem Ausfall? Abhängig von der Risikobeurteilung erfolgt dann die Risikobehandlung, z. B. in Form von Risikoakzeptanz oder Sicherheitsmaßnahmen, die im Design zu berücksichtigen sind.
Last but not least gilt es auch hier, die Akteure zu identifizieren und das dazugehörige Rollen- und Berechtigungskonzept zu entwickeln. Zu den Akteuren gehören beispielsweise Administratoren und Wartungsgeber.
Entwicklung / Beschaffung
Für die Entwicklung von Anwendungen oder Systemen sind sichere Entwicklungsstandards erforderlich, wie auch die ISO/IEC 27001 im Anhang A unter Punkt A.14.2.1 fordert. Entwicklungsstandards beziehen sich u. a. auf die Entwicklungsumgebung, die Versionskontrolle und die Codierstandards für die eingesetzten Programmiersprachen. Die Entwicklungsumgebung muss von der Test- und von der Produktionsumgebung getrennt sein. Zudem muss eine personelle Trennung zwischen diesen drei Umgebungen sichergestellt sein. Die eingesetzten Tools und Libraries in der Entwicklungsumgebung dürfen keine bekannten Schwachstellen aufweisen.
Wird Software extern entwickelt, bleibt die Letztverantwortung dennoch beim Auftraggeber.
Im Rahmen von Programmierstandards gehören zu den grundsätzlichen Anforderungen die Authentifizierung des Kommunikationspartners sowie die Zugangs- und Zugriffskontrolle. Die Eingangsdaten müssen überprüft und Fehler korrekt behandelt werden. Letzteres bedeutet, dass eine Fehlermeldung einerseits konkret sein muss und andererseits keine informationssicherheitsrelevanten Informationen preisgeben darf. Zudem muss der Stand der Technik berücksichtigt werden, z. B. bei der verschlüsselten Kommunikation und der gehashten Speicherung von Passwörtern. Beispiele für Programmierstandards liefern z. B. MISRA C++ und die Secure Coding Practice des OWASP.
Statische Code-Analyse sowie Code und Peer Reviews sind etablierte Elemente, um sich der gewünschten Sicherheit und Qualität zu nähern. So können einerseits Fehler erkannt und beseitigt werden. Andererseits lassen sich eventuelle Backdoors entdecken.
Wird Software extern im Auftrag entwickelt, verbleibt die Letztverantwortung dennoch beim Auftraggeber. Auch deswegen muss sichergestellt sein, dass beim Auftragnehmer die gleichen oder gleichwertige Entwicklungsstandards eingehalten werden. Daher muss der Auftraggeber diesbezüglich zum einen Prüfungen im Vorfeld und zum anderen während des Entwicklungsprozesses durchführen. Sowohl auf Auftraggeber- als auch auf Auftragnehmerseite gibt es, wie die Erfahrung zeigt, ein breites Spektrum in Bezug auf die sichere Entwicklung von Software und Systemen.
Parallel zur Entwicklungsphase gilt es, erforderliche Dokumentationen zu erstellen, z. B. die Testspezifikation. Diese muss insbesondere auch Tests im Hinblick auf SSPC enthalten.
Systemtest
Neben den funktionalen Tests müssen die Tester nichtfunktionale Tests durchführen. Dazu gehören Tests der Leistungsfähigkeit und Kapazität inklusive Last- und Stresstests ebenso wie Tests im Hinblick auf SSPC. Tests von SSPC beziehen sich beispielsweise auf folgende Fragestellungen
- Ist das Berechtigungskonzept korrekt umgesetzt?
- Funktioniert die Zugangs- und Zugriffskontrolle?
- Werden Passwörter nach dem Stand der Technik sicher gehasht gespeichert?
- Entsprechen die Protokollierungen den Anforderungen?
- Ist sichergestellt, dass weder PINs noch Passwörter im Klartext protokolliert werden?
- Sind Penetrationstests durchgeführt und entdeckte Sicherheitslücken geschlossen worden?
- Gibt es ein Datensicherungskonzept und funktioniert es?
- Funktioniert der Restore der Daten?
- Ist die Verfügbarkeit sichergestellt?
- Ist das Wiederanlaufkonzept dokumentiert und funktionsfähig?
Abnahme
Bei der Abnahme muss der interne oder externe Auftraggeber Abnahmetests durchführen, die auch SSPC beinhalten. Die Themenstellungen sind hierbei vergleichbar zu denen beim Systemtest, allerdings aus der Perspektive des Auftraggebers und durch ihn. In Bezug auf Security testet der Auftraggeber z. B. das umgesetzte Berechtigungsrollenmodell im Hinblick auf die Einhaltung des Grundsatzes der minimalen Rechte sowie die Funktionsfähigkeit der Zugangs- und Zugriffskontrolle. Er überprüft die Einhaltung des maximal tolerierbaren Datenverlustes sowie die Wirksamkeit der Datensicherungen und der Datenrückspeicherung. Bei hohen Verfügbarkeitsanforderungen führt der Auftraggeber eine Pfadanalyse durch und prüft damit, ob Single Points of Failure vorliegen. Außerdem überprüft er die Wirksamkeit des Wiederanlaufkonzepts.
Eine Überprüfung der Dokumentationen im Hinblick auf Vollständigkeit, Korrektheit und Verständlichkeit ist auch im Hinblick auf SSPC relevant. Zu den geforderten Dokumentationen gehören z. B. das technische Design, das Benutzerhandbuch, die Betriebsdokumentation, das Datensicherungskonzept, das Sicherheitskonzept und das Notfallkonzept.
In freien Tests bringt der Auftraggeber seine Kenntnisse aus dem Business Case ein.
Inbetriebnahme
Im Rahmen der Inbetriebnahme stellt die Organisationseinheit IT-Betrieb sicher, dass die Systeme den Sicherheitsvorgaben entsprechend konfiguriert und gehärtet sind sowie die geforderte Redundanz und das Berechtigungsmodell realisiert sind. Darüber hinaus überprüft der IT-Betrieb die Integrität der inbetriebgenommenen Software in Bezug auf die abgenommene Software.
Betrieb
Die IT-Service-Management-Prozesse müssen SSPC-Anforderungen berücksichtigen. Dementsprechend müssen u. a. die Prozesse IT-Sicherheitsmanagement und IT-Kontinuitätsmanagement vorhanden und wirksam sein. Das Incident Management muss die Erkennung SSPC-relevanter Ereignisse sowie das anschließende Vorgehen beinhalten. Schwachstellenmanagement und Patch-Management müssen etabliert und organisiert sein. Im Change Management müssen SSPC-Aspekte berücksichtigt werden: Müssen aufgrund eines Change beispielsweise das Sicherheitskonzept und/oder das Notfallkonzept aktualisiert werden? Welche Auswirkungen hat der Change im Hinblick auf das Sicherheits- und das Verfügbarkeitsniveau? Im Hinblick auf Verfügbarkeit ist die Ermittlung, Vereinbarung und Pflege der Kapazitätsanforderungen ein wesentliches Thema.
Die Integrität von Programmen und Konfigurationen muss im Betrieb sichergestellt sein. Penetrationstests müssen geplant und durchgeführt werden.
Mitarbeiter der Organisationseinheit IT-Betrieb müssen durch Schulung und Awareness auf dem aktuellen Stand gehalten und sensibilisiert werden.
Außerbetriebnahme
Auch bei der Außerbetriebnahme ergeben sich unter SSPC-Aspekten Fragestellungen:
- Wie lange müssen welche Systeme betriebsfähig gehalten werden?
- Wie lange müssen Daten archiviert werden?
- Wie wird vermieden, dass Daten aufgrund von Alterungsprozessen der Datenträger nicht mehr lesbar sind?
Fazit
Sowohl die externen und internen Anforderungen an Safety, Security, Privacy und Continuity aber auch die Bedrohungen nehmen zu. Dies macht es erforderlich, nichtfunktionale Anforderungen – insbesondere auch im Hinblick auf SSPC – ab der ersten Idee für ein neues System, mit zu erheben und in den folgenden Schritten bis hin zum Betrieb und zur Außerbetriebnahme zu realisieren. Um dies zu erreichen, muss SSPC in den Lebenszyklus von Systemen, in das Vorhaben- bzw. Projektmanagement und in die Entwicklungsmethodik integriert sein.
Die Beratungspraxis zeigt, dass manch ein Unternehmen dies bereits selbst oder mit externer Unterstützung realisiert hat, andere nähern sich der Thematik oder müssen sie aufgrund externer Vorgaben in Angriff nehmen. Aus Autorensicht ist es empfehlenswert, dass jedes Unternehmen – nicht zuletzt aus Gründen der Reputation, Sicherheit und Handlungsfähigkeit – sein Projektmanagement und seine Entwicklungsmethoden angemessen sicher gestaltet, um vor ungeahnten, folgenreichen negativen Überraschungen verschont zu bleiben. In diesem Sinne: Seien Sie sicher.
- Klaus-Rainer Müller, IT-Sicherheit mit System, Springer Vieweg, 5. Auflage, 2014
- Klaus-Rainer Müller, Handbuch Unternehmenssicherheit, Springer Vieweg, 3. Auflage, 2015
- D. AJ Sokolov, heise.de: Milliarden-Coup in NY: Zentralbank-Konto per Überweisung geleert
- M. Maisch, M. Brächer, handelsblatt.com: Mitarbeiter in den Filialen müssen länger bleiben
- Spiegel online: "WannaCry"-Attacke - Fakten zum globalen Cyberangriff
- Spiegel online: Angriff auf Twitter und Co., Cyberattacke aus dem Babyfon