Offen heisst nicht zwangsläufig besser
Seit Anfang Mai läuft eine Attacke auf Computer des Bundestages. Umfang und Art sind bislang nicht publiziert und die beauftragten Behörden, das Bundesamt für Sicherheit in der Informationstechnik und das Bundesamt für Verfassungsschutz, ermitteln. Im Zuge der derzeit noch immer unklaren Ermittlungen ist der Ruf nach Umstellung der Anwendungen und Betriebssysteme auf Open Source-Systeme nur eine Frage der Zeit und aus einzelnen Fraktionen auch schon erfolgt.
Das Beispiel Venom zeigt aber, dass die reine Tatsache, dass Software Open Source-lizenziert ist, noch keinerlei Aussage über deren Sicherheit impliziert. Nur dass man eine Kontrolle des Codes (Code inspection) durchführen könnte, weil der Quelltext verfügbar ist, bedeutet nicht, dass das auch jemand unternimmt. Viel zu einfach ist es, sich auf bestehende Bibliotheken zu verlassen, diese als Blackbox zu betrachten und ihre Funktion implizit als validiert und sicher zu betrachten.
Nur falls die notwendigen Analysen auch durchgeführt werden, kann quelloffene Software diese sonst nur vermeintliche Stärke auch tatsächlich ausspielen. Nur dann kann offene Software durch den Rückfluss der Analyseergebnisse in neue Versionen kontinuierlich verbessert werden.
Es geht nicht um Closed Source gegen Open Source: Unabhängig vom verwendeten Lizenzmodell und der damit verbundenen ideologischen und kommerziellen Interessenlage lenken beide aktuellen Ereignisse das Augenmerk auf hier wie dort gerne konsequent vernachlässigte Eigenschaften von IT-Systemen: Die Codequalität und die Gesamtsicherheit von Anwendungssystemen.
- Woran Sie einen Angriff erkennen
Nach Analysen von McAfee weisen vor allem acht Indikatoren darauf hin, dass ein Unternehmensnetz in die Schusslinie von Hackern geraten ist. Hans-Peter Bauer, Vice President Zentraleuropa bei McAfee, stellt sie vor. - Interne Hosts kommunizieren mit bösartigen oder unbekannten Zieladressen
In jedem Fall verdächtig ist, wenn ein Host-Rechner auf externe Systeme zugreift, deren IP-Adressen auf "Schwarzen Listen" von IT-Sicherheitsfirmen zu finden sind. Vorsicht ist auch dann geboten, wenn Rechner häufig Verbindungen zu Systemen in Ländern aufbauen, zu denen ein Unternehmen keine geschäftlichen Beziehungen unterhält. Dabei kann es sich um den Versuch handeln, Daten aus dem Unternehmen hinauszuschmuggeln. - Interne Hosts kommunizieren mit externen Hosts über ungewöhnliche Ports
Auffällig ist beispielsweise, wenn interne Rechner über Port 80 eine SSH-Verbindung (Secure Shell) zu einem System außerhalb des Firmennetzes aufbauen. SSH nutzt normalerweise Port 22 (TCP). Port 80 ist dagegen die Standardschnittstelle für HTTP-Datenverkehr, also den Zugriff auf das Internet. Wenn ein Host einen ungewöhnlichen Port verwendet, kann dies ein Indiz dafür sein, dass ein Angreifer das System unter seine Kontrolle gebracht hat. Um IT-Sicherheitssysteme zu täuschen, tarnt ein Hacker dann die Kommunikation mit seinem Command-and-Control-Server (C&C) als Anwendung, die jedoch nicht den Standard-Port verwendet. - Öffentlich zugängliche Hosts oder Hosts in entmilitarisierten Zonen (DMZ) kommunizieren mit internen Hosts
Mithilfe solcher Hosts kann es Angreifern gelingen, gewissermaßen "huckepack" in ein Unternehmensnetz einzudringen, Daten zu stehlen oder IT-Systeme zu infizieren. - Warnungen von Malware-Scannern außerhalb der Geschäftszeiten
Verdächtig ist, wenn Antiviren-Programme in der Nacht oder am Wochenende Alarm schlagen, also außerhalb der normalen Arbeitszeiten. Solche Vorkommnisse deuten auf einen Angriff auf einen Host-Rechner hin. - Verdächtige Netzwerk-Scans
Führt ein interner Host-Rechner Scans des Netzwerks durch und nimmt er anschließend Verbindung zu anderen Rechnern im Firmennetz auf, sollten bei Administratoren die Alarmglocken schrillen. Denn dieses Verhalten deutet auf einen Angreifer hin, der sich durch das Netzwerk "hangelt". Vielen Firewalls und Intrusion-Prevention-Systemen (IPS) entgehen solche Aktionen, wie sie nicht entsprechend konfiguriert sind. - Häufung identischer verdächtiger Ereignisse
Ein klassischer Hinweis auf Angriffe ist, wenn mehrere sicherheitsrelevante Events innerhalb kurzer Zeit auftreten. Das können mehrere Alarmereignisse auf einem einzelnen Host sein, aber auch Events auf mehreren Rechnern im selben Subnetz. Ein Beispiel sind Fehler beim Authentifizieren. - Schnelle Re-Infektion mit Malware
Nach dem Scannen mit einer Antiviren-Software und dem Beseitigen eventuell vorhandener Schadsoftware sollte ein IT-System eigentlich längere Zeit "sauber" bleiben. Wird ein System jedoch innerhalb weniger Minuten erneut von Malware befallen, deutet dies beispielsweise auf die Aktivitäten eines Rootkit hin. - Dubiose Log-in-Versuche eines Nutzers
Eigenartig ist, wenn derselbe User innerhalb kurzer Zeit von unterschiedlichen Orten aus Log-in-Versuche in ein Firmennetz startet oder wenn solche Aktionen von Systemen mit unterschiedlichen IP-Adressen aus erfolgen. Eine Erklärung ist, dass die Account-Daten des Nutzers in falsche Hände gefallen sind. Denkbar ist allerdings auch, dass sich ein illoyaler oder ehemaliger Mitarbeiter Zugang zu verwertbaren Daten verschaffen will.
Kritische Infrastruktur Software
Software ist heute mehr denn je eine kritische Infrastruktur. Ihre Qualität, Sicherheit und Verfügbarkeit sind essentielle und überlebensnotwendige Faktoren für jedes moderne Unternehmen. Um diese Faktoren zu gewährleisten, müssen Softwaresysteme mehr denn je angemessen erstellt, getestet und analysiert werden. Das gilt für die einzelnen Komponenten, wie etwa Softwarebibliotheken, und für das Gesamtsystem im Verbund.
Viele Ansätze sind hier möglich und die meisten auch nötig. Diese beginnen bei angemessenen Strukturen für moderne Entwicklungsteams, die auch hochaktuelle Cybersecurity-Skills integrieren müssen. Kontinuierliches Training und Weiterbildung sind unabdingbar. Neben traditionellen Softwaretests im Entwicklungszyklus sind heute leistungsfähige Werkzeuge zur Code-Analyse in der Lage, beim Test und dem Härten von Softwaresystemen zu unterstützen.
Code-Qualität und "Security by Design" sind nicht weit oben auf der Liste der Anforderungen an Unternehmenssoftware. Dies ist um so mehr im aktuellen Trend der "schneller mehr Funktionalität liefern"-Mentalität der DevOps-Evangelisten der Fall.
Aktuelle Fehlentwicklungen wie die genannten bedrohten Virtualisierungsplattformen und die gefährdete Regierungs-IT, aber auch unsichere SSL-Kommunikation in Webservern und kompromittierbare Funktionen in Router-Firmware belegen jedoch nachdrücklich, dass hier bislang kurzsichtig priorisiert wird.
Die strategische Verankerung von angemessen hohen Sicherheitsanforderungen in jeder Softwarespezifikation ist nicht zuletzt auch eine Managementaufgabe, denn sie erfordert Geld, Zeit und Ressourcen jenseits von "Time to Market". Die genannten Beispiele sollten helfen können, hier die notwendige Bereitschaft zu schaffen.
- Konfusion
Wenn der Entwickler selbst nicht mehr weiß, was er da getrieben hat. - Fluchen ...
... können Entwickler ja bekanntlich besonders gut. - Eine wahre Geschichte
Was, das wussten Sie nicht?? - Das Ende
Das kontrollierte Ende eines möglicherweise unkontrollierten Programmablaufs. - Schnipp und Schnapp
Über die Benennung von Variablen lässt sich wahrlich trefflich streiten. - Optimist
Ach ja ... - Weihnachtsbaum
Ein schöner Weihnachtsbaum bei der Definition von Variablenwerten. - Star Trek
Star-Wars-Fans sind überall unter uns und hinterlassen ihre Spuren. - Meinung
Freie Meinungsäußerung, auch wenn sie "eher robuster" ausfällt, ist stets zulässig. - Im Fall des Falles
Ein Fehler-Handler ohne Inhalt: Oh Schreck - eigentlich sollten wir hier was unternehmen. - Hübsch anzusehen
Künstlerische Aspekte dürfen auch im Quellcode-Kommentar nicht zu kurz kommen. - Kurz ...
... und prägnant. - Drachen
ASCII-Malerei - ein Relikt aus den 1980er Jahren. - Kafka
Zwar soll Franz K. Prag nicht wirklich verlassen haben, in den Quellcode hat er es dennoch geschafft. - Genie
Ob es dieser Entwickler wirklich ernst meint? - Ohne Inhalt
Das Grundgerüst ist zumindest schon mal erstellt - Zeit für einen Kaffee. - Null oder Null?
Die Implementierung ist wohl nicht so ganz im Sinne des Entwicklers. - Wirklich gemein
Die Freundlichkeit in diesem Kommentar ist wahrlich spürbar. Wahr als Unwahr zu definieren, ist auch ein ganz freundlicher Akt. - Der Beste
Möglicherweise der beste Kommentar den es gibt: Wie viel Zeit haben wir schon bei der Optimierung des Codes verschwendet? - Den Mutigen
Den Mutigen gehört die Welt. - Ehrlichkeit
Hoffentlich ist der Rest vom Programm in einem günstigeren Geisteszustand verfasst worden. - Aha!
Alles klar? - Vertrauen
Nur weil es im Kommentar steht, heißt es nicht, dass es auch wirklich stimmt. - Mehr Zeit
Natürlich ist es falsch die XML-Datei so zu erzeugen, aber es klappt und wir haben mehr Zeit für ein paar Getränke.
(bw)