Mit "Sicherheit" gewinnen
Bedingt durch den beschleunigten Wandel der Softwarelandschaft, der zunehmenden Integration heterogener Systeme und die Öffnung von Diensten zur Anbindung von Partnerunternehmen und Kunden ergeben sich täglich neue Herausforderungen an die Sicherheit.
Sicherheit besteht aus vielen Bausteinen. Für einige gibt es Werkzeugunterstützung am Markt für andere muss man - je nach Anspruch - selbst tätig werden.
Obwohl Maßnahmen zur Steigerung der Betriebssicherheit häufig als lästiges Übel angesehen werden, stecken hier versteckte Chancen um die Verfügbarkeit und Robustheit von Anwendungen und Systemlandschaften nachhaltig zu verbessern.
Abhängigkeiten
Werden sensible Daten über externe Dienste ausgewertet bzw. zugänglich gemacht, hat man die Hoheit über diese Daten aufgegeben.
Aktuell als sicher geltende Verschlüsselungen von Daten kann in wenigen Monaten oder Jahren gebrochen sein. Backups müssen genauso wie produktive Daten vollständig in Ihren Händen liegen.
Die Nutzung von Frameworks oder Code aus fremden Laufzeitquellen Dritter stellen ohne weitere Maßnahmen ein unkalkulierbare Risiko dar.
Passive Sicherheit
Holen Sie sich die Hoheit über ihre Daten und Anwendungen zurück in Ihr Haus: Viele Lösungen beseitigen bestenfalls die Symptome von selbst verursachten Problemen.
Kein Backup - kein Mitleid ... ist einfach 'gesagt', aber ein Backup alleine ist auch nicht genug. Für zentrale Maschinen wird ein Image-basiertes Deployment benötigt um nach einem Ausfall oder Kompromittierung das System in kurzer Zeit mit einem definierten Stand wieder aktivieren zu können. Virtualisieren Sie Dienste, da diese bei Ausfall eines Servers einfach verlagert werden können.
Besitzen (sensible) Daten einen Fingerprint, der sich im Rahmen der Verarbeitung in einer definierten Art verändert, kann dieser bei der Analyse von geleakten Daten hilfreich sein um die genutzte Schwachstelle zu identifizieren.
Externe Dienste - Migration
Die von internen oder externen Diensten aus zugreifbaren Ressourcen und Daten müssen generell auf das notwendige Minimum reduziert sein. Ggf. werden benötigte Daten aus DB-Backends oder der Laufzeitumgebung extrahiert und gesondert für den Dienst bereitgestellt.
Der Umzug externer Dienste in interne (virtuelle) Server-Instanzen kann notwendig werden, wenn diese sensible Daten verarbeiten bzw. - z.B. technisch bedingt - Zugriff auf sensible Daten erlangen können.
Intern bereitgestellte Dienste müssen zuverlässig eingerichtet und dauerhaft gewartet werden. Ein nicht ausreichend konfigurierter Dienst kann selbst ein Sicherheitsrisiko darstellen. Verfügbare Updates müssen in ein Release-Management integriert werden.
Unabhängig davon, ob für die beteiligten Anwendungen ein Review vorliegt, sollten Dienste zusätzlich in einer abgeschotteten Umgebung laufen.
Bevor neue Infrastruktur Zugriff auf Ressourcen erhält oder selbst am internen Netz erreichbar ist, sind ausreichende Test obligatorisch. Auch für den späteren Betrieb müssen (provozierte) Fehlersituationen optional protokolliert bzw. an ein Monitoring übergeben werden können.
Im Rahmen des Setups sollte auch ein Monitoring der beteiligten Anwendungen aufgesetzt und - z.B. durch Auswertung und Anzeige von Fehlersituationen - überprüft werden.
Pentesting
Pentesting löst keine strukturellen Probleme. Aber ohne kontinuierliches Pentesting als Bestandteil des Monitorings können vorhandene Schwachstellen der Infrastruktur unerkannt bleiben.
Software muss heutzutage nicht mehr nur die rein fachspezifischen Aufgabenstellungen lösen, sondern sich auch einer veränderten stark vernetzen Systemlandschaft stellen. Implementierte und genutzte Dienste sind dabei ebenso relevant wie die genutzte/installierte OS-Infrastruktur und entscheidend für die Sicherheit von Anwendungspaketen.
Nur eine kontinuierliche Aktualisierung der Testsets und fortlaufende Innen-Tests ermöglichen das frühzeitige Aufspüren von bislang unbekannten Lücken und Schwachstellen.
Werden gefundene Lücken zeitnah geschlossen, reduziert sich die Gefahr einer Nutzung durch Dritte erheblich, da erst mit der Veröffentlichung eines neuen Test die breite Masse aufmerksam wird. Können Lücken nicht unmittelbar geschlossen werden, können betroffene Dienste vorübergehend z.B. in einem eigenen Netzwerk isoliert oder auch deaktiviert werden.
Eigenentwicklungen - Robustheit und Rechtemanagement
Die wichtigste Maßnahme bringt Ihnen aber auch zusätzlichen Gewinn für Ihre eigenen Prozesse: Testen von Eigenentwicklungen auf Vollständigkeit der Funktionalitäten und Robustheit gegenüber Laufzeitfehlern.
Hierdurch nimmt auch die Verlässlichkeit von Anwendungen und Diensten für die fachliche Nutzung zu.
Werden Funktionalitäten und Dienste mit einem abgestuften Rechtemanagement versehen, ist ein wesentlicher Schritt zur Absicherung von Systemen erreicht; Rechte und benötigte Funktionalität lassen sich als Metadaten von Klassen und Diensten beschreiben.
Liegen Metadaten zum Rechtemanagement vor, können Nutzungsschnittstellen gezielt für unterschiedliche Use-Cases generiert werden. Für sensible Daten können abgestufte Zugriffsrechte generiert werden.
Fehlende oder eingeschränkte Funktionalität und Daten können selbst in einem kompromittiertem System nicht zum Erlangen sensibler Daten oder deren Änderung bzw. zum Ausweiten von Nutzerrechten genutzt werden.
Durch Nutzung von Basis-Implementierungen lassen sich Laufzeitfehler genauso wie Zugriffsfehler durchgehend und einheitlich behandeln ohne den generierten Code zu überfrachten. Insbesondere bei Zugriffsfehlern lassen sich spezifische Aktionen realisieren.
Whitebox-Tests von Interna erhöhen allgemein die Robustheit einer Anwendung. Ein gezielter Umgang mit Fehlersituationen erhöht die Hürde auch für einen ungewollten/verbotenen Zugriff.
Hierarchische finite-state machines sind gut geeignet das gewünschte Verhalten und die Reaktion in Ausnahmesituationen zu verwalten. Sie sind zudem ideal zum Steuern von Anwendungszuständen, da der Automat die zulässigen Zustandsübergänge definiert und die notwendigen Operationen für den Übergang ohne externe Parametrisierung durchführen kann.
Updates und Release-Management
Software ist per Definition nicht fehlerfrei. Werden Sicherheitsupdates zur Verfügung gestellt, müssen dies nach einer Testfreigabe integriert werden.
Kann Software nicht signiert werden, müssen zusätzliche Maßnahme zum Sicherstellen der korrekten Verteilung und beim Monitoring von Systemen getroffen werden.
Werden Dienste als virtuelle Server-Instanzen genutzt, kann ein Clone erstellt und aktualisiert werden. Der Wechsel zwischen den Versionsständen erfordert dann lediglich einen Wechsel der Instanzen.
Die Nutzung einer chroot-Umgebung ermöglicht auch einen direkten Soll-Ist-Vergleich von Versionen bzgl. Unterschiede in System- und Konfigurationsänderungen, die u.U. mehr Aufschluss geben als eine Release-Note.
"ungepflegte" Software
Ein organisatorisches Problem mit Aktualisierungen stellen Release-Stände nicht mehr aktiv gepflegter Softwareprodukte dar, die aber immer noch in Nutzung sind.
Die Software kann z.B. nach einem Update von Systembestandteilen nicht mehr oder nicht mehr korrekt funktionieren. Ein Zugriff oder eine Änderung von entsprechenden Daten oder Funktionen steht nicht mehr zur Verfügung.
Jede compilierte Software besteht immer auch aus einem Satz von potentiell veralteten oder verwundbaren Anteilen statischer Bibliotheken. Entsprechend müssen Anwendungen beim Vorliegen von Sicherheitspatches neu erstellt werden.
Ist für betroffene Software kein Update möglich, kann diese nicht dauerhaft ohne zusätzliche Maßnahmen weiter verwendet werden
Die Sicherheit eines Systems oder einer Systemlandschaft steht und fällt mit dem schwächsten Glied in der Kette.