Unhackbare Systeme? Methoden und Probleme der IT-Hochsicherheit

So komplex die IT-Welt insgesamt ist, so komplex ist auch das Gebiet der Informationssicherheit. Und je komplexer IT-Probleme werden, desto weniger beherrschbar werden sie und desto höher ist die Wahrscheinlichkeit für das Aufkommen von sicherheitsrelevanten Problemen. Ursachen dafür sind nicht selten Fehler in der Softwareentwicklung. Dieser Artikel gibt Einblicke in die Welt der IT-Hochsicherheit, in der die Entwicklung von sicheren Systemen zur Top-Priorität erhoben wird.

Zum Stand der Technik gehört es, Aspekte der Informationssicherheit systematisch auf vielen Ebenen organisatorisch und technisch anzugehen, um sie beherrschbarer zu machen. Die resultierenden Verwaltungsaufwände, z.B. durch die Implementierung eines Informationssicherheitsmanagementsystems (ISMS), sind beträchtlich.

Wozu das alles? Sind Probleme der Informationssicherheit wirklich inhärent so komplex und erscheinen täglich neue Angriffstechniken, so dass die Dauerbeschäftigung mit IT-Sicherheit als technisch bedingte Notwendigkeit akzeptiert werden muss?

Der Bericht des Bundesamts für Sicherheit in der Informationstechnik (BSI) zur Lage der IT-Sicherheit in Deutschland aus dem Jahr 2020 legte dar, dass im Berichtszeitraum die Anzahl neuer Schadprogramm-Varianten um rund 117 Millionen zugenommen hat [1]. Des Weiteren wird berichtet, dass Ransomware seit einigen Jahren eine der größten Bedrohungen für Nutzerinnen und Nutzer von IT-Systemen darstellt. Bei Ransomware werden typischerweise Daten des kompromittierten Systems verschlüsselt, um für die Freigabe der Daten Lösegeld zu erpressen. Emotet, eine Familie von Makroviren, die weiteren Schadcode nachladen, wird detaillierter erläutert und als „neue Qualität fortschrittlicher Angriffe“ bezeichnet. Außerdem werden konkrete Ransomware-Angriffe und ihre verheerenden Auswirkungen erläutert wie z. B. ein IT-Angriff auf die Stadtverwaltung einer mittelgroßen deutschen Stadt.

Es erscheint also trivial, die oben gestellte Frage zu bejahen, doch der Schein trügt. Tatsächlich sind die Angriffstechniken nicht neuartig, wenn man die initialen Angriffsvektoren betrachtet. Makroviren gibt es schon mindestens seit 1999 und die erste Form von Ransomware mit dem Namen „AIDS-Trojaner“ tauchte schon im Jahre 1989 auf. Der initiale Angriffsvektor für Ransomware, der anscheinend überwiegend durch das Öffnen von E-Mail-Anhängen oder Dateien aus dem Web besteht, ist ebenfalls schon sehr alt. Angesichts der schon fast regelmäßigen Empörung über veröffentlichte CVEs mit marketingtauglichen Eigennamen mag es verwunderlich stimmen, dass Jahrzehnte bekannte Schwächen in IT-Produkten, die mehrfach erwiesenermaßen Millionenschäden ermöglichen, anscheinend einfach hingenommen werden.

Dass das Öffnen von E-Mail-Anhängen, Webseiten oder ausführbaren Dateien relativ leicht zur Kompromittierung von vertraulichen Daten, des Systems oder einer ganzen Netzwerkinfrastruktur führen kann, kann aus IT-Sicherheitssicht als Entwurfsfehler bezeichnet werden. Es liegt im Anwendungszweck von öffentlichen E-Mail-Postfächern, dass Daten von unbekannten und nicht-vertrauenswürdigen Quellen empfangen werden können. Also sollte man sich auch darauf verlassen können, dass keine Kompromittierung stattfinden kann, wenn eine E-Mail oder ein E-Mail-Anhang geöffnet werden kann. Das Gleiche gilt für Webbrowser und Webseiten, für PDF- und auch für Office-Dokumente. Die gut gemeinte Empfehlung, man solle in diesen Fällen auf irgendeine Weise Vorsicht walten lassen, steht im Widerspruch zur gewünschten Funktionalität dieser Produkte und Protokolle und lastet Anwendern eine Bürde auf, die nicht zumutbar ist. Denn Schadcode kann durch vermeintlich vertrauenswürdige Webseiten eingeschleust werden und selbst sonst vertrauenswürdige E-Mail-Absender könnten kompromittiert worden sein und über ihren Account E-Mails mit Schadcode gesendet werden. Um solche Sicherheitsprobleme zu vermeiden muss IT-Sicherheit unbedingt im Softwareentwurf betrachtet werden.

Sicherer Softwareentwurf

Kritik zu üben ist einfach, aber ist sie auch legitim und gibt es Möglichkeiten es besser zu machen? Tatsächlich sind einige Betriebssystem- und Anwendungsentwickler in vielen Bereichen mehr und mehr dabei, im Entwurf von IT-Produkten IT-Sicherheit so zu betrachten, dass bestimmte Sicherheitslücken entweder gar nicht mehr möglich sind oder bei Ausnutzung dieser Sicherheitslücken der mögliche Schaden extrem reduziert wird.

Smartphone-Betriebssystemhersteller kapseln Apps in eigenen Ausführungsumgebungen, sodass grundsätzlich weniger Privilegien, als der Systemnutzer hat, benötigt und andere Apps nicht kompromittiert werden können. Mit dieser Art von Systementwurf und Anwendungskontrolle können technische Sicherheitsrichtlinien leicht umgesetzt werden. So gehört eine Berechtigungsverwaltung zum Standard von modernen Smartphone-Betriebssystemen. Mit dieser lassen sich einfach systemseitig Berechtigungen überblicken, vergeben und entziehen. Eine kompromittierte PDF- oder Office-App würde grundsätzlich nur die App-internen Daten kompromittieren und keine Daten anderer Apps. Theoretisch müssten diesen Apps auch kein direkter Internetzugang gewährt werden, womit Datenexfiltration unterbunden werden könnte. Aktualisierungen aus dem Internet können durch die App-Verwaltungen (Playstore, Appstore) geleistet werden.

Desktop-Betriebssysteme in denen historisch bedingt Anwendungen eine Vielzahl von unnötigen Berechtigungen haben, sind in dieser Hinsicht den Smartphone-Betriebssystemen unterlegen, holen aber langsam auf. So wurden mit Universal Windows Platform Apps und dem Microsoft Store ähnliche Prinzipien implementiert.

Linuxbasierte Smartphone-Betriebssysteme wie Android belegen, dass gängige Software bzw. Betriebssystemkerne für ein höheres IT-Sicherheitsniveau ergänzt und umgebaut werden können. In der IT-Hochsicherheit spielen Sicherheitsanforderungen meist von Anfang an eine wichtige Rolle. Produkte in diesem Bereich müssen besonders hohe Anforderungen an die IT-Sicherheit erfüllen und auch gegen fortgeschrittene Angreifer Schutz bieten. IT-Hochsicherheitsprodukte legen besonders Wert darauf, dass ihre Funktionalität und Sicherheitseigenschaften klar definiert und möglichst verifizierbar sind. Die Verifikation bezieht sich dabei meist auf den Entwurf oder den Quelltext, in extremen Fällen auch bis auf den Byte-Code. Anwendungsfälle für IT-Hochsicherheitsprodukte ergeben sich bspw. bei der Verarbeitung von staatlichen Verschlusssachen oder besonders kritischen Kryptokomponenten, weswegen die Produkte üblicherweise nach bestimmten Kriterien zertifiziert und von einer Behörde für bestimmte Geheimhaltungsgrade zugelassen werden müssen [2].

Beim Softwareentwurf von sicheren Systemen kann man sich an Konstruktionsprinzipien richten, die 1975 von Saltzer und Schröder [3] formuliert wurden. Im Folgenden werden die bewährten Konstruktionsprinzipien erläutert und Beispiele aus der Praxis genannt.

Abbildung-1: Saltzer und Schröder’s Entwurfsprinzipien für sichere Systeme

IT-Hochsicherheit in der Praxis

Bei Zulassungsverfahren spielen oft die Common Criteria (standardisiert in der ISO/IEC 15408), ein internationaler Standard zur Prüfung und Bewertung der Sicherheitseigenschaften von IT-Produkten, eine wichtige Rolle. Ein Produkt kann in Bezug auf ein Schutzprofil (Protection Profile) zertifiziert werden, aus der ein produktspezifisches Schutzprofil, das Security Target erstellt wird. Wichtig ist im Standard die Unterscheidung zwischen den Anforderungen an die Sicherheitsfunktionalität (security functional requirements, SFR) und die Vertrauenswürdigkeit (security assurance requirements, SAR) von Produkten. Während die Sicherheitsfunktionalität auf funktionale Eigenschaften mit IT-Sicherheitsbezug wie z.B. Zugriffskontrolle, Authentisierung und Autorisierung aufbaut, bezieht sich die Vertrauenswürdigkeit darauf, in welcher Qualität diese implementiert wurden. Der Fokus auf die Vertrauenswürdigkeit der Sicherheitsfunktionalität soll hierbei die Wirksamkeit untersuchen und sicherstellen, dass Implementierungsfehler nicht die Sicherheitsfunktionalität aushebeln können. Zur Klassifizierung der Prüftiefe von Sicherheitsfunktionen werden sieben Stufen (Evaluation Assurance Level, EAL) von EAL1 bis EAL7 verwendet, wobei die Kriterien sich z.B. funktionale Tests (EAL1), methodische Entwicklung, Testung und Durchsicht (EAL4) oder auf den formal verifizierten Entwurf und Testung (EAL7) beziehen. Einige IT-Sicherheitsexperten gehen davon aus, dass IT-Produkte erst ab der fünften Stufe als hochsichere IT-Produkte angesehen werden können.

Können nun nach Common Criteria zertifizierte Produkte als unhackbar oder mindestens als sicherer angesehen werden? Ein aktuelles Beispiel eines Unternehmens für IT-Sicherheitsprodukte widerlegt zumindest die Unhackbarkeit in Bezug auf ein „EAL4+“-zertifiziertes Produkt. „EAL4+“ bedeutet hier, dass das Produkt EAL4-zertifiziert wurde, aber einzelne Eigenschaften eine höhere Vertrauenswürdigkeit besitzen. Sicherheitsforscher entdeckten bei der als „high resistance firewall“ beworbenen OpenBSD-basierten Firewall [3] die Möglichkeit zur unauthentifizierten Systemübernahme über die Web-Verwaltungsschnittstelle (CVE-2021-27215, CVSS: 7.5). Dabei wurde das Produkt auf der Produktseite nicht nur als „highly resistant“ beworben, sondern es wurde auch behauptet, dass eine maximale Resistenz gegen direkte Angriffe gegeben sei und die Sicherheitsfunktionalität EAL7-Anforderungen genügt. Offenbar wurden für die Web-Verwaltungsschnittstelle aber gängige Industrienormen wie der OWASP ASVS (Application Security Verification Standard) nicht ausreichend beachtet. Wer die Firewall nach den Zertifizierungsdokumenten korrekt betrieb, war von der Schwachstelle eher mittelbar betroffen, da der Betrieb der Web-Verwaltungsschnittstelle nur in einem physisch gesicherten Administrationsnetzwerk vorgesehen ist. Dies geht direkt aus zertifizierungsrelevanten Dokumenten hervor, in denen die Betriebsumgebung und sonstige Annahmen für das Produkt explizit dokumentiert sind.

Trotz allem ist davon auszugehen, dass in der Entwicklung des Produktes viel Aufwand für die IT-Sicherheit betrieben wurde. Sicherheitskritische Sicherheitslücken wurden auch schon bei Produkten gefunden, die nach „EAL-6+“ zertifiziert wurden (siehe CVE-2019-7715). Doch für manche Anforderungen ist der Aufwand nicht hoch genug. Der Einsatz eines monolithischen in der Programmiersprache C entwickelten Betriebssystemkerns wie bei der betreffenden Firewall schließt Schwachstellen nicht aus. Aus diesem und vielen anderen Gründen begann die australische Forschergruppe NICTA 2006 die Entwicklung des formal verifizierten Mikrokernels seL4. In diesem Projekt wurde die funktionale Korrektheit eines Mikrokernels mittels formalen Werkzeugen wie u.a. Isabelle/HOL, ein Theorembeweiser, bis auf die Bytecode-Ebene bewiesen und erfüllt damit bedeutend höhere Anforderungen als EAL7. Das Projekt erforderte ca. 25 Personenjahre und wurde beim DARPA-finanzierten Retrofit-Projekt HACMS (High-Assurance Cyber Military Systems) als technologische Basis zur Steuerung eines autonomen Helikopters eingesetzt [4]. Als Komplettersatz für universelle Betriebssysteme wie Desktop- oder Smartphonebetriebssysteme kann seL4 ohne Weiteres nicht verwendet werden, da es sich um einen Betriebssystemkern mit vergleichsweise sehr begrenzter Funktionalität handelt. Aus diesem Grund werden sich die Einsatzzwecke in Zukunft vermutlich eher auf eingebettete Systeme oder die Separierung von mehreren Standardbetriebssystemen fokussieren.

Muen-Separationskernel und Ada/SPARK

Neben sicherheitsfokussierten monolithischen Systemen wie OpenBSD oder formal verifizierten Mikrokernels wie seL4 gibt es auch andere Ansätze zur Entwicklung sicherer Systeme. So wird bei manchen IT-Hochsicherheitsprojekten auf Muen gesetzt, ein quelloffener in Ada/SPARK geschriebener Separationskernel. Bei einem Separationskernel handelt es sich um einen spezialisierte Mikrokernel, dessen Aufgabe es ist, Ressourcen wie CPU-Zeit, Hauptspeicher und Peripherie für die auf dem System laufenden Anwendungen zu trennen. Mit dieser technologischen Basis ist es möglich, komponentenbasierte Systeme zu entwickeln, deren einzelne Komponenten nur über definierte Kanäle kommunizieren und somit nicht das ganze System blockieren können. Abbildung-1 veranschaulicht das Funktionsprinzip eines Separationskernels. Auf diesem können bspw. Anwendungen unterschiedlicher Vertrauenswürdigkeit oder Kritikalität laufen.

Abbildung-2: Separationskernel mit Anwendungen unterschiedlicher Vertrauenswürdigkeit

Dabei kann es sich bei den Anwendungen um übliche vollwertige Betriebssysteme handeln, aber auch um schlanke Anwendungen, die direkt auf die freigegebenen Hardwareressourcen zugreifen können. Separationskernel können als besonders sichere und schlanke Form eines Hypervisors mit Sicherheitsfokus betrachtet werden.

Eine Besonderheit von Muen ist die Implementierung und die geringe Größe der Trusted Computing Base, kurz TCB. Bei der TCB handelt es sich um den Teil eines Systems, der die Sicherheitsgarantien umsetzt und dem vertraut werden muss. IT-Sicherheitstechnisch ist daher eine kleine und korrekt implementierte TCB vorteilhaft, so dass diese leichter auditiert werden kann. Mit ca. 3000 Zeilen Code ist der Kernel im Vergleich zu anderen Kernels relativ klein. Die geringe Anzahl Codezeilen liegt auch in der Auslagerung der Funktionalität in die Kompilierzeit statt in die Ausführungszeit begründet: Der Prozess-Scheduler, Kommunikationskanäle, Speicherverwaltung, Hardwareressourcenzuweisung werden zur Kompilierzeit statisch in einer Systemrichtlinie festgelegt und werden dann ins System fest eingebaut. Eine nachträgliche Veränderung der Systemstruktur ist ohne weiteres nicht mehr möglich.

Bei SPARK handelt es sich um eine Untermenge der Systemprogrammiersprache Ada, die um einige Eigenschaften erweitert wurde, um die formale Verifikation zu unterstützen. Im Gegensatz zu anderen weit verbreiteten Systemprogrammiersprachen wie C ist SPARK stark typisiert, was bedeutet, dass u.a. bei der Typisierung zur Kompilierzeit strengere Regeln gelten und weniger implizite Typkonvertierungen stattfinden. Nicht unbedeutender sind die Analyse- und Verifikationsaspekte, die in den Quelltexten eingebaut werden und von Entwicklungswerkzeugen automatisch geprüft und verifiziert werden können. So kann durch Vor- und Nachbedingungen bei Funktionen das Design-by-Contract-Paradigma umgesetzt und zusätzliche Vertrauenswürdigkeit in die Implementierung geschaffen werden. Außerdem können die Entwicklungswerkzeuge so eingestellt werden, dass die erfolgreiche Kompilierung eines SPARK-Programms automatisch die Abwesenheit von Laufzeitfehlern garantiert. Bei der Kompilierung eines SPARK-Programms werden verschiedene Datenfluss-Analysen durchgeführt, um uninitialisierte Variablen, ineffektive Anweisungen und falsche Datenflüsse zu erkennen. Damit können ganze Klassen von potenziellen Sicherheitslücken wie Pufferüberlaufe oder arithmetische Überläufe ausgeschlossen und weiter die Vertrauenswürdigkeit in die Korrektheit der Implementierung erhöht werden. Programmierstandards- oder -richtlinien, wie sie bspw. durch C im Nachhinein durch Programmierstandards wie MISRA (Motor Industry Software Reliability Association) umgesetzt werden, sind so schon im Vorhinein im Entwicklungsprozess eingebettet.

Anhand Abbildung-2 lassen sich einige Aspekte der SPARK-Philosophie an einer simplen Vertauschungsprozedur veranschaulichen. Die Abbildung zeigt die Spezifikation einer Prozedur. Bei SPARK wird streng nach Spezifikation und Implementierung unterschieden, weswegen Spezifikationen üblicherweise in separaten Dateien ausgelagert werden. Das Codebeispiel beginnt mit dem Schlüsselwort „procedure“. SPARK unterscheidet hier zwischen Prozeduren, die übergebene Variablen verändern und keinen Rückgabewert enthalten und seiteneffektfreien Funktionen, die übergebene Variablen nicht verändern und einen Rückgabewert zurückgeben und damit mathematischen Funktionen ähneln. Die Prozedur erwartet zwei Variablen X und Y vom Typ Integer. Beide Variableninhalte werden verarbeitet und verändert. Dies wird durch „in out“ ausgedrückt und besitzt damit erste Datenflusseigenschaften. Nach der Prozedursignatur werden sogenannte Aspekte definiert, in denen viele Programmeigenschaften spezifiziert werden können, die vom Compiler automatisch geprüft werden können. „Global => null“ bedeutet hier, dass keine globalen Variablen genutzt werden. In einer C-Funktion wäre das ohne Weiteres nicht sofort ersichtlich. Mit dem Depends-Aspekt lassen sich weitere Datenflüsse spezifizieren. Hier wird spezifiziert, dass der Wert von X von Y abhängt, und der Wert von Y von X abhängt. Abschließend wird durch eine Nachbedingung eine funktionale Eigenschaft der Prozedur spezifiziert.

Ähnliche Ziele wie SPARK verfolgt die relativ junge Systemprogrammiersprache Rust, die 2010 zum ersten Mal angekündigt wurde und Speichersicherheit (memory safety) zu einem Entwurfsziel gemacht hat. Wie SPARK ist auch Rust stark und statisch typisiert, hat aber zusätzlich den Vorteil, dass Konzepte der dynamischen Speicherverwaltung unterstützt und Sicherheiten in Bezug auf Nebenläufigkeit garantiert werden können (z.B. Wettlaufsituationen/race conditions). Dafür unterstützt Rust das Design-by-Contract-Paradigma von Haus aus nicht, womit ein wichtiges Werkzeug zur formalen Verifikation fehlt. Projekte, in denen Rust eingesetzt wird, sind u. a. die von Mozilla entwickelte Web-Browser-Engine namens Servo, der Chatdienst Discord, bei Microsoft Azure IoT Edge und auch bei Parsern von Industrieprotokollen [6] wie Modbus und DNP3.

Zusammengefasst kann festgehalten werden, dass Rust sich eher auf Speichersicherheit fokussiert und sich gut für performante Anwendungen mit dynamischer Speicherverwaltung eignet, während sich SPARK auf Programmanalysierbarkeit und -korrektheit fokussiert [4] und somit eher für hochkritische Anwendungsfälle wie die Implementierung einer statischen TCB eignet.

Hardware als Schwachstelle am Beispiel von Cache-Seitenkanälen

Angenommen ein Systementwickler benutzt die genannten Methoden, um ein sicheres System zu implementieren. Als Basis wird ein Separationskernel ausgewählt, die Systemspezifikation erlaubt nur freigegebene Kommunikationswege über den Hauptspeicher und besonders zu vertrauende Komponenten werden in SPARK oder Rust entwickelt. Ist das System nun sicher? Nicht im Sinne der IT-Hochsicherheit, in der meist auch keine indirekte Kommunikation zwischen sogenannten Seitenkanälen erlaubt ist. Seitenkanäle sind Kommunikationskanäle, die Implementierungsdetails des Systems ausnutzen. So sind Seitenkanalangriffe bekannt, die Sicherheitsgarantien von Kryptoimplementierungen aushebeln konnten, in dem der Stromverbrauch von Kryptooperationen gemessen wurde, der wiederum abhängig von geheimen Schlüsseln war. Auch andere Seitenkanäle wie Zeitverhalten, Caches und andere gemeinsam genutzte Ressourcen wurden schon erfolgreich ausgenutzt, um verdeckte Kanäle (Covert Channels) zu etablieren und unautorisiert Informationen zu extrahieren. Die Schwächen entstehen prinzipiell durch die Verletzung des zuvor genannten Konstruktionsprinzips „Least common mechanism“, das die Verringerung von gemeinsam genutzten Ressourcen fordert. Der Muen-Separationskernel kann zwar Rechnerressourcen wie CPU-Zeit, Hauptspeicher und Peripherie sauber zuordnen, unterstützt aber keine Separierung der Caches. Cache-Seitenkanal-Angriffe erlauben aber die Ausschleusung von vertraulichen Daten an nicht vertrauenswürdige Komponenten oder im schlimmsten Fall aus dem ganzen System. Trivialerweise könnte man bei jedem Kontextwechsel den Cache leeren (Cache-Flush). Dies würde aber enorme Geschwindigkeitseinbußen bringen. Alternativ könnte man versuchen den Cache ebenfalls zu separieren. Eine Technik, um dies zu bewerkstelligen, nennt man Page Coloring. Diese softwareseitige Technik, die keine spezielle Hardware erfordert, geht davon aus, dass die gleichen Hauptspeicherseiten immer zu den physisch gleichen Bereichen im Cache zugeordnet werden. Damit lassen sich dann Klassen (oder „Farben“) im Cache festlegen, zu denen bestimmte Hauptspeicherseiten zugeordnet werden können. Hauptspeicherseiten unterschiedlicher Farben können dann nicht im Cache interferieren.

Abbildung-4: Beispiel eines Separationskernels auf einer Hardware mit vier CPUs, drei Cache-Ebenen und fünf Anwendungen (Subjects) aus unterschiedlichen Sicherheitsdomänen.

Abbildung-4 zeigt ein System mit vier CPUs und vier Anwendungen (Subjekte), die auf einem Separationskernel betrieben werden sollen. Die Subjekte sind verschiedenen Sicherheitsdomänen und CPUs zugeordnet. Subjekte aus verschiedenen Sicherheitsdomänen dürfen nicht im Cache interferieren. Umgekehrt dürfen Subjekte aus der gleichen Sicherheitsdomäne im Cache interferieren. Zusätzlich dürfen, sofern von der Systemrichtlinie erlaubt, Subjekte über definierte Kanäle kommunizieren, wie in der Abbildung zwischen den Anwendungen Subjekt 2 und Subjekt 3 zu sehen ist. Die Caches können mehrere Ebenen haben und zwischen CPUs geteilt, aber auch exklusiv einer CPU zugeordnet werden. Dies muss alles beachtet werden, wenn Page Coloring implementiert wird.

Diese ganzen Informationen bzw. Einschränkungen können bspw. durch ein Logikprogramm aufgenommen und verarbeitet werden. Falls eine Lösung existiert, kann das Logikprogramm eine Zuordnung zwischen Subjekten und Cache-Farben ausgeben. Andernfalls kann der Fall eintreten, dass das System schon theoretisch nicht umgesetzt werden kann. Das Problem wird noch komplexer, wenn man erweiterte Geschwindigkeitsanforderungen an Subjekte stellt, so dass auch die minimale oder maximale Anzahl an zu zugeordneten Farben spezifiziert werden kann.

Fazit

Hochsichere Systeme zu entwickeln ist schwer. Sie erfordern tiefe System- und Security-Engineering-Kenntnisse und für die Zulassung in bestimmten sicherheitskritischen Bereichen sind teure und aufwändige Zertifizierungsverfahren notwendig. Mit verschiedenen technischen und organisatorischen Maßnahmen versucht man daher, fernab der Softwaresicherheit ein höheres IT-Sicherheitsniveau in Organisationen zu gewährleisten. Trotzdem muss man sich früher oder später auf die Sicherheit von Software, insbesondere bei besonders kritischen Systemen und kritischen Infrastrukturen verlassen. Durch spezielle Methoden in der Softwaretechnik können Systeme mit einem ausreichenden Schutz vor Angriffen entwickelt werden. Ganze Klassen von Sicherheitslücken sind auf diesen Systemen entweder nicht mehr existent oder durch den Entwurf des Systems berücksichtigt, so dass keine bedeutenden Schäden an anderen Komponenten oder am Gesamtsystem verursacht werden können. Durch einen sicheren Softwareentwicklungsprozess lassen sich zusätzlich auch in andere Ebenen im Softwareentwicklungsprozess IT-Sicherheitsaspekte berücksichtigen. Die so entwickelten Systeme mögen nicht unhackbar sein, aber Angriffe werden aller Wahrscheinlichkeit nach nicht im Verhältnis zu ihrem potenziellen Nutzen stehen, sodass es für Angreifer lohnenswerter wäre, andere Systeme anzugreifen.

Autor: Marl Joos (GAI NetConsult GmbH)

Literaturverzeichnis