7 SICHERHEIT VON SOFTWARE IN DER PRODUKTION 31
weitergeleitet. Grundsätzlich sollte man das Prinzip der geringstmöglichen Privilegien systematisch und konse-quent durchsetzen: Jedes Modul, ob Prozess, Nutzer oder weiteres Programm, darf nur auf diejenigen Funktionen und Daten zugreifen, für die es die notwendigen Rechte besitzt. Die Rechteverteilung ist dabei so konservativ wie möglich anzusetzen. Im obigen Beispiel ist eine dreifache, aufeinanderfolgende Sicherheitsprozedur zu erkennen:
Zunächst prüft die Software die Herkunft der Daten anhand eines digitalen Zertifikats, dann überprüft sie anhand der Zugriffsrechte, ob die Daten weiterverarbeitet werden dürfen, und dann erst wird die eigentliche Verar-beitung gestartet. Im Entwurfsprozess der Software sollte dieses Prinzip der mehrschichtigen Sicherheitsmaßnah-men („defense in depth“) systematisch angewendet werden, um die Angriffsoberfläche kritischer Softwaremodule auf ein Minimum zu reduzieren. Zusätzlich sollte der Funktions-umfang der Software weitestgehend eingeschränkt werden.
Der Betreiber sollte zugekaufte Komponenten durch Deak-tivieren nicht benötigter Softwaremodule und Funktionen selbst anpassen, vorausgesetzt die Komponente bietet eine solche Konfigurationsmöglichkeit an.
Für die Implementierung sollte auf geeignete Entwicklungs-umgebungen zurückgegriffen werden. Schon über die Wahl der Programmiersprache lassen sich viele bekannte Ein-fallstore von vornherein ausschließen. Ferner lassen sich über Einstellungen des Compilers einige Sicherheits aspekte ohne großen Aufwand realisieren. Auch sollte bei der Ent-wicklung auf möglichst sichere und aktuelle Software- Bibliotheken zurückgegriffen werden. Wird beispielsweise ein Modul zur Verschlüsselung von Daten implementiert, sollte der Entwickler auf gängige kryptographische Biblio-theken zurückgreifen, die insbesondere noch aktiv gepflegt werden.
Der Implementierung folgen Sicherheitstests, zunächst in Form von statischer und dynamischer Codeanalyse. Hier sind insbesondere Fuzzing (das Testen von Software mit randomisierten Eingabedaten) und das Testen auf Schwach-stellen in der Speicherverwaltung (z. B. mittels Address-Sanitizer und ähnlichen Werkzeugen) zu nennen. Häufig werden so bereits viele Programmierfehler erkannt. Idealer-weise findet zusätzlich ein manuelles Codereview anhand des Quellcodes statt.
Vor dem eigentlichen Release muss sichergestellt sein, dass sämtliche der im ersten Schritt identifizierten Sicherheits-anforderungen erfüllt wurden. Ausführbare Programme und sämtliche nachfolgenden Updates sollten vom Integra-tor digital signiert sein.
Für tiefergehende Informationen zur Entwicklung und Bewertung von Softwarekomponenten sei an dieser Stelle schließlich auf die Norm ISO/IEC 25000 („Software Engi-neering – Software Product Quality Requirements and Eva-luation (SQuaRE) – Guide to SQuaRE”) als auch die zugehö-rige Normenreihe ISO/IEC 250xx hingewiesen. Ferner bietet der von Microsoft definierte Security Development Lifecycle (SDL)33 detailliertere Beschreibungen zu den genannten Punkten.
7.2 Software-Pflege und -Wartung
Mindestens ebenso wichtig wie die sichere Entwicklung der Software ist deren Pflege und Wartung nach Auslieferung, soweit dies der Betrieb und die Wartungsfenster zulassen.
Um der hochdynamischen Bedrohungslage gerecht zu wer-den, sollte idealerweise eine regelmäßige Neubewertung der Risiken stattfinden: Aus dieser ergeben sich dann neue Sicherheitsanforderungen, die entsprechend als Change Request in den Entwicklungsprozess einfließen. Diese Anpassung (Change) sollte beim Entwickler der Software stattfinden, der auf neue Angriffstrends mit entsprechen-den Schutzmaßnahmen reagiert. Bei der Auswahl der Kom-ponenten sollte der Betreiber also unbedingt abklären, inwiefern diese Form der Wartung und Anpassung (also die Möglichkeit, Changes zu beantragen und einzuspielen) an aktuelle Bedrohungen vom Zulieferer unterstützt wird.
Insbesondere sollte der Softwareentwickler schnell auf bekannt gewordene Sicherheitslücken reagieren und ent-sprechende Updates ausliefern können, die dann ebenso rasch im Rahmen von Instandhaltungsarbeiten einfließen können. Die Auslieferung der Updates sollte dabei in einen fest definierten Release-Management-Prozess eingegliedert sein, der auch umfassende Tests der Softwareupdates einschließt – der Betreiber kann es sich nicht leisten, die Verfügbarkeit oder Integrität seiner Anlage durch ein Software update zu gefährden, das eine nur unwahrschein-lich an greifbare Schwachstelle absichert. Zudem ist auch der Updateprozess vor Angriffen abzusichern: Remote- updates müssen über gesicherte Kanäle erfolgen, sämtliche neu eingespielte Software muss vom Entwickler digital sig-niert und diese Signatur von der gewarteten Komponente verifiziert werden können. Besonders im Feldbereich muss zusätzlich die Kompatibilität des Updates zu weiteren abhängigen Komponenten sichergestellt sein.
33 Vgl. Microsoft (Hrsg.) (2016)
7 SICHERHEIT VON SOFTWARE IN DER PRODUKTION 32
7.3 Software-Governance
Zusätzlich zur Entwicklung und Wartung spielt Software-Governance, also die Organisation und Verwaltung der gesamten Software-Infrastruktur, eine wesentliche Rolle.
Die Komplexität moderner Anlagen erfordert eine Vielzahl aufeinander abgestimmten Softwarelösungen. Für die Ver-waltung dieser teils sehr heterogenen Softwarelandschaft innerhalb einer Anlage müssen Regelungen zur Einbrin-gung und Verwaltung von Programmen aufgestellt werden.
Als Erstes muss hierfür eine Inventarisierung und Doku-mentation aller Softwarekomponenten der Anlage stattfin-den. Diese Gesamtübersicht muss stets aktuell gehalten werden, unabhängig von den definierten Regeln zur Ein-bringung neuer Komponenten.
Die Umsetzung einer sicheren Softwareverwaltung setzt zunächst eine Regelung voraus, unter welchen Bedingungen neue Softwarekomponenten und Programme in die Anlage integriert werden dürfen. Zumindest sollen hier die defi-nierten Kriterien für sichere Software berücksichtigt werden.
Dabei sollten die Regelungen zur Einbringung der Software für jede Zone einzeln definiert werden. Beispielsweise kann für jede Zone festgelegt werden, welche Softwareklassen oder gar speziellen Programme installiert werden dürfen.
Hier ist der Einsatz von Application-Whitelisting (siehe nächsten Abschnitt) und Blacklisting zu empfehlen, auch in Kombination mit spezifischen Regeln für die relevanten Akteure und Rollen. Benötigt ein Akteur dann ein Pro-gramm oder eine spezielle ProPro-grammversion, für das er keine Installationsberechtigung besitzt, kann die Anlage durch die Etablierung eines Software-Anforderungsprozes-ses dennoch weiterhin flexibel und sicher angepasst wer-den. Ein solcher Prozess wird dann die Überprüfung der oben genannten erforderlichen Mindeststandards beinhal-ten, wodurch die Softwaresicherheit der Gesamtanlage auf einem angemessenen Niveau gehalten werden kann. Ferner ist der Einsatz von Software-Managementsystemen sinn-voll, über die der Betreiber verteilte Programme gleichzei-tig zentral einbringen, verwalten, updaten oder entfernen kann.
Die eingangs erwähnte Inventarisierung und Dokumenta-tion aller Softwarekomponenten der Anlage ist ferner Grundlage für die Beobachtung der aktuellen Bedrohungs-lage: Werden Schwachstellen oder Sicherheitslücken bekannt, so kann der Betreiber abgleichen, ob seine Anlage direkt von diesen betroffen ist. Zum gegenwärtigen Zeit-punkt stellt die Inventarisierung aller Softwarekomponen-ten Anlagenbetreiber vor große Herausforderungen, für Anlagen der Industrie 4.0 wird eine solche aber unabding-bar sein und sollte zumindest angestrebt werden.
7.4 Whitelisting und Systemhärtung
In der Office-IT ist es seit wenigen Jahren üblich, Server-systeme nur mit den unbedingt notwendigen Funktionen auszuliefern bzw. zu betreiben. Noch in den späten 90er Jahren und Anfang des Jahrtausends war es üblich, sämt-liche im Betriebssystem verfügbaren Dienste im Ausliefe-rungszustand aktiv zu haben, auch wenn diese nicht genutzt wurden. Später wurden dann nachträglich sogenannte
„Systemhärtungen“ vorgenommen, bei denen die nicht genutzten Dienste und Funktionen deaktiviert wurden.
Dies ist bis heute in den IT-Komponenten der Produktion eher unüblich und führt durch die nicht aktualisierten Sys-teme zu sehr großen Angriffsflächen. Diese Angriffsflächen sind im Kontext der Industrie 4.0 nicht mehr annehmbar, so dass für veraltete und nicht mehr in Wartung befindliche Systeme dringend Schutzmaßnahmen benötigt werden.
Neben den zum Zeitpunkt der Erstellung dieses Leitfadens aufkommenden mathematisch-prädiktiven Systemen34 haben sich Whitelisting-Lösungen als wirksam und an wend-bar erwiesen. Im einfachsten Falle bedeutet Whitelisting die Erstellung einer Liste von erlaubten Programmen: Aus-schließlich Programme dieser Liste können gestartet wer-den. Wesentlich fortgeschrittener sind Listen, die anhand des normalen Systemverhaltens automatisiert erlernt wurden.
Diese aus heutiger Sicht wichtigste Methode zum Schutz von Bestandssystemen wird als kleine Software komponente auf einem als „sauber“ eingestuften Alt-System installiert und beobachtet über einen Zeitraum das Verhalten der Systemprozesse, Dienste, die Netzwerkkommuni kation und die Interaktionen der Programme. Nach dieser Lernphase wird das System in den Überwachungsmodus geschaltet, und meldet vormals nicht protokolliertes Verhalten als außergewöhnlich. Nach einer manuellen Entscheidung, welche der neu gefundenen Muster normal oder anormal waren, wird das System aktiviert. Jegliche außergewöhnliche Aktivität (wie sie durch einen Virusbefall oder den Start von Programmen von einem USB-Stick ausgelöst werden) wird nun aktiv unterbunden.
34 Etwa die vom US-Unternehmen Cylance vorgestellten Mechanismen
33
Mit der steigenden Vernetzung von Maschinen und Anla-gen im Rahmen von Industrie 4.0 gehen neue Gefahren einher, die bislang im Einkaufsprozess kaum eine Betrach-tung finden. Der Fokus bei der Auswahl von Maschinen und Anlagen liegt bislang z. B. auf Funktionsumfang, Ver-fügbarkeit und Ausbringungsraten. Dies führt unter ande-rem dazu, dass neue Produktionsmaschinen noch heute mit Systemsoftware ausgeliefert werden, deren Wartungs-zusage durch den Integrator bereits abgelaufen ist.
Dass Securityanforderungen keine Berücksichtigung fin-den, ist insbesondere in Verbindung mit der langen Lebens-dauer (häufig länger als 20 Jahre) von Maschinen und An lagen kritisch. Eine nachträgliche Anpassung an die neue Bedrohungslage ist häufig nicht möglich, da solche Veränderungen an Maschinen und Anlagen in der Regel weitreichende Konsequenzen wie den Verlust der Unter-stützung durch den Anbieter oder die vollständige erneute Prüfung der Anlage nach der Betriebssicherheitsverord-nung (BetrSichV) nach sich ziehen würden. Der laufende Betrieb der vorgenannten abgekündigten Betriebs- und Steuerungssysteme stellt eine der größten Herausforderun-gen der heutiHerausforderun-gen Produktions-IT dar. Hier muss abgewo-gen werden, ob ein „Einfrieren“ der Systeme durch spezielle Software sinnvoll und mit dem Integrator vereinbar ist.
Erschwerend kommt die fatale und immer bestehende Denkweise hinzu, dass Maschinen die praktisch nicht am Internet hängen, unangreifbar sind. Angriffe wie Stuxnet haben hier das Gegenteil bewiesen und zeigen den nach-träglichen Anpassungsbedarf an eine veränderte Bedrohungs-lage ebenfalls auf.
Die veränderte Sicherheitslage mit einer Vielzahl neuer Malware und gezielten Angriffen auf Industrieanlagen macht deutlich, dass bei der Auswahl von Maschinen und Anlagen auch ein Mindestmaß an nachhaltiger IT-Sicher-heit gefordert werden muss, sodass eine sichere Anbindung und ein sicherer Betrieb ermöglicht werden. Hierbei ist nicht nur der Anschaffungszeitpunkt, sondern auch der komplette Lebenszyklus der Maschinen und Anlagen zu beachten. Im Rahmen der Einführung eines Sicherheits-konzepts für die IT in der Produktion muss zunächst der Einkaufsprozess betrachtet und überarbeitet werden, um die Weichen für die Zukunft richtig zu stellen. Durch die Erstellung oder Erweiterung von Einkaufsrichtlinien kön-nen Vorgaben an die IT-Sicherheit von Maschikön-nen und Anlagen eingeführt und gegenüber dem Lieferanten einge-fordert werden.
Bei der Anschaffung von neuen Maschinen oder Anlagen ist schon im Vorfeld darauf zu achten, dass gemeinsam mit dem Lieferanten eine abgestimmte und langfristige Lösung für den sicheren Betrieb der Anlage über den kompletten Lebenszyklus ausgearbeitet und vereinbart wird. Industrie-verbände wie ZVEI und VDMA weisen ihre Mitglieder in eigenen Publikationen auf diesen Bedarf hin und erstellen ihrerseits Forderungen zu mehr IT-Sicherheitskriterien bei der Beschaffung von Modulen oder Bauteilen.