Die D.A.CH Security fand dieses Jahr vom 26.-27. September in Klagenfurt (Österreich) direkt beim Veranstalter der Alpen-Adria-Universität statt. Ziel der Veranstaltung war es wie in jedem Jahr eine interdisziplinäre Übersicht zum aktuellen Stand der IT-Sicherheit in Industrie, Dienstleistung, Verwaltung und Wissenschaft in Deutschland, Österreich und der Schweiz zu geben. In diesem Jahr fand die Veranstaltung in Kooperation mit der 46. Jahrestagung der Gesellschaft für Informatik statt. Die DECOIT^® GmbH war traditionsgemäß anwesend, um ihre Forschungsergebnisse vorzustellen und die Session „Sicherheitsmanagement“ zu leiten.

Vorgestellte Neuigkeiten auf der D.A.CH Security im Überblick (siehe unten für Berichte)

• Open Source SIEM
• ISACA-konformen Cyber-Security-Check
• KRITIS-Betreiber
• Schwachstellen in SAML 2.0-Implementierungen
• Sicherheit von SDN-Controllern
• Absicherung von mobilen Endgeräten
• Untersuchung und Analyse von mobilen Apps
• Privatsphäre in sozialen Netzwerken
• Smart-Grid
• Resultate des SPIDER-Projektes
• Industrie 4.0
• Industrieroboter
• Smart Home System

Open Source SIEM

Mit dieser Session, die von Prof. Dr. Kai-Oliver Detken koordiniert wurde, begann denn auch die Tagung und startete gleich mit dem interessanten Vortrag „Open Source SIEM“. Da kommerzielle Lösungen oft sehr teuer in der Anschaffung sind, kam man ebenfalls hier die Idee, Open-Source-Lösungen zu verwenden. Dabei wurden Datenschutzaspekte mit berücksichtigt, da die Logging-Auswertung ohne Beachtung des Datenschutzes kaum möglich ist. Dabei stellt sich allerdings die Herausforderung, dass die gesammelten Daten für ein SIEM-System verwendbar sein müssen, um eine Datenkorrelation zu ermöglichen. Es konnte durch die Realisierung in Unternehmen dabei bewiesen werden, dass die Eigenentwicklung eines SIEM-Systems durchaus möglich ist, bei der 1000 Events/sec kein Problem darstellen. Wartung und Trainings sind dabei enorm wichtig und sollten am besten mit den Entwicklern zusammen vorgenommen werden.

ISACA-konformen Cyber-Security-Check

Wenn man einen ISACA-konformen Cyber-Security-Check durchführen möchte, sollte man die entsprechenden Leitfäden vom BSI mit berücksichtigen, wie ein anderer Vortrag aufzeigte. IT-Sicherheitsthemen haben sich heute verselbstständigt und die IT-Abteilungen haben teilweise keine Übersicht mehr, weshalb Sicherheitsüberprüfungen unerlässlich sind. Hinzu kommt, dass wesentlich mehr Tools heute im Einsatz sind, aber meistens durch die gleiche Anzahl von IT-Mitarbeitern administriert werden. Daher werden Richtlinien heute nicht unternehmensweit umgesetzt. Ein Sicherheitscheck kann daher helfen, einen Maßnahmenkatalog zu definieren und Audits regelmäßig durchzuführen.

KRITIS-Betreiber

Dies ist auch für KRITIS-Betreiber (wie z.B. Stadtwerke) notwendig, da es seit Mitte 2015 neue regularische Vorgaben durch das Sicherheitsgesetz zu beachten gilt. Spätestens im Jahre 2018 müssen KRITIS-Betreiber entsprechende Zertifikate einreichen bzw. ausweisen können. Zusätzlich gibt es diverse Anforderungen seitens der ISO 27001-Norm. Es gibt aber leider keine Beschreibungen, wie man eine solche Norm einführt. Auch fehlt es ihr an Prozessorientierung.  Es müssen daher die Aktivitäten und der Betrieb eines Information Security Management System (ISMS) definiert und strukturiert werden, weshalb ISO27-SP definiert wurde. Ziel sollte es sein, ein normkonformes, natives ISMS aufzubauen und betreiben zu können, um in Unternehmen IT-Sicherheit „by Design“ einzuführen. Davon sind die Unternehmen allerdings noch ein Stück weit entfernt.

Schwachstellen in SAML 2.0-Implementierungen

Anschließend gab es eine Hacker-Demo, die Schwachstellen in SAML 2.0-Implementierungen aufzeigte. Der Demonstrator basiert dabei auf einer echten Schwachstelle. Er basiert auf dem Open-Source-Tool SAMLRaider (https://github.com/SAMLRaider/SAMLRaider), dass sich SAML-Schwachstellen automatisiert annehmen. So konnte anhand eines geklonten Zertifikats eine Schwäche ausgenutzt werden, da diese auch nicht immer korrekt überprüft werden. Über das entwickelte Tool können Zertifikate geklont und gefälscht werden. Weitere Maßnahmen sind einstellbar. Das Tool kann kostenfrei für eigene Penetrationstests verwendet werden.

Sicherheit von SDN-Controllern

Die  Sicherheit von SDN-Controllern stand bei einem weiteren Vortrag im Fokus. Ziel eines SDN-Systems ist es, eine Vereinfachung der Konfiguration, Wartung und Steuerung von Netzwerken durchzusetzen, und zwar herstellerunabhängig. Die Administration wird dabei über eine zentrale Instanz (den Controller) vorgenommen. Intelligente und flexiblere Netze sollen dadurch ermöglicht werden. Das Kommunikationsprotokoll zwischen SDN-Geräten ist dabei meistens OpenFlow. Der Vorteil der größeren Flexibilität, wird aber durch einen Single-Point-of-Failure erkauft: die Störung des Controllers wirkt sich auf das gesamte Netzwerk aus. Daher wurden im ersten Schritt Angriffsziele identifiziert (Controller, Protokolle und Netzwerkkomponenten) und diverse Angriffsarten ausprobiert. Auch kamen verschiedene Controller (u.a. BEACON/IRIS) zum Einsatz. Dabei stellte sich heraus, dass OpenDaylight (Open Source) die Grundlage für viele kommerzielle Controller ist. Hier sind Brute-Force-Attacken möglich, aber alle Zugriffe werden geloggt. Es kam bei der Untersuchung heraus, dass nicht alle Controller sich adäquat absichern lassen und dass, obwohl OpenFlow empfohlen wird, es nicht bei allen Herstellern implementiert ist. Die Entwicklung von SDN ist daher noch lange nicht abgeschlossen.

Absicherung von mobilen Endgeräten

Die Absicherung von mobilen Endgeräten bleibt ebenfalls ein wichtiges Thema innerhalb der IT-Sicherheit. Eine Möglichkeit ist die Verteilung von Benutzerzertifikaten auf die Mobilgeräte. Die Zielsetzung ist dabei, den privaten Schlüssel und den Partner-Schlüssel auf die Endgeräte zu bringen. Die Herausforderung besteht dabei darin, dass der private Benutzerschlüssel zwar manuell importiert werden kann, aber die Handhabung zu umständlich für den Normalbenutzer ist. Auch mittels MDM-Systemen können beim Betriebssystem iOS Probleme auftreten, da ein Import des privaten Schlüssels nicht zugelassen wird (es werden nur Verteilungen über das MDM-System zugelassen). Weiteres Problem: MDM-Systeme liegen meistens in der Cloud, so dass die privaten Schlüssel ebenfalls in dieser liegen. Mit Google kann der Proxy-Ansatz, der hier vorgestellt wurde, nicht gefahren werden, da kein Protokoll hierfür spezifiziert wurde (klappt daher nur bei Apple und Windows Mobile). Die Umsetzung wurde so gewählt, dass der Benutzer keinerlei Zertifikatsberührung hat. Ein MDM-Proxy verteilt private Schlüssel mittels MDM-Protokoll: das EAS-Protokoll ruf im AD-Protokoll Partnerzertifikate von öffentlichen LDAP-Servern ab. Fazit: eine Ende-zu-Ende-Verschlüsselung ist nun möglich, wird aber quasi als Man-in-the-Middle-Attacke ausgeführt durch den MDM-Proxy.

Untersuchung und Analyse von mobilen Apps

Bei der Untersuchung und Analyse von mobilen Apps wurde weiterhin festgestellt, dass 90% aller Maleware werden für Android hergestellt werden. Das ist auch nicht verwunderlich, da Android den größten Verbreitungsgrad besitzt und gerne Apps an dem Google-Store vorbei angeboten werden. Zudem akzeptiert der Benutzer oftmals App-Berechtigungen, ohne diese zu lesen. Das Identifizieren von modifizierten Apps ist letztendlich auch nur manuell möglich. Als Beispiel-App wurde Tiny Flashlight (Taschenlampe) genannt, welches eine Vielzahl von Informationen abgreift. Probleme der Analyse: die Verschlüsselung erschwert das Auffinden von Informationen, Informationen können dynamisch aufs Handy gelangen und die Obfuskierung des Quellcodes. Trotzdem wurde eine Methode vorgestellt, die es einer Sicherungsinstanz nun einfacher ermöglicht, mobile Endgeräte zu überprüfen.

Privatsphäre in sozialen Netzwerken

Am zweiten Tag stand anfangs die Privatsphäre in sozialen Netzwerken im Vordergrund. Hierbei wurde die Modellierung von Informationsflüssen in sozialen Netzwerken gezeigt und ein Zugriffssteuerungsmodell, welches sich durch ein Informationsflussmodell ausdrückt. Soziale Grafen zeigen dabei Kommunikationsbeziehung von verschiedenen Menschen auf, weshalb eine Privatsphäre sich schwer umsetzen lässt. Aber es wurde trotzdem eine Lösung präsentiert, die die Anbieter/Betreiber implementieren könnten: über ein Live Monitoring Framework wurde dabei auf geteilte Beiträge geachtet und mehr Privatsphäre geschaffen. Nur leider scheinen die Betreiber, daran wenig Interesse zu haben.

Smart-Grid

In der Smart-Grid-Session, an der auch die DECOIT^® GmbH aktiv mit einem Vortrag teilnahm, wurde zuerst die Situation in Österreich aufzeigt. Auch dort ist es so, dass viele Komponenten in den Stromnetzen nicht für zukünftige Sicherheitsanforderungen ausgelegt sind. Betriebssicherheit, Angriffssicherheit und Schutz der Privatsphäre von Konsumenten müssen unter einen Hut gekriegt werden. Daher wurde die Definition einer Referenzarchitektur für sichere Smart Grids in Österreich zur Reduzierung/Vermeidung von Angriffen vorangetrieben. Eine Risikoanalyse wurde ebenfalls durchgeführt, basierend auf dem Bedrohungskatalog, und Penetrationstests wurden vorgenommen zur Beurteilung der Sicherheit. Fazit: viele Normen und Richtlinien sind für Smart Grids vorhanden, die aber alle vernünftig zusammenspielen müssen. Dies ist kein leichter Weg.

Resultate des SPIDER-Projektes

Die DECOIT^® GmbH stellte die Resultate des SPIDER-Projektes (http://www.spider-smartmetergateway.de/deutsch/projekt/projekt.html) vor und dessen Weiterentwicklung zu einem Produkt. In dem Projekt, welches Mitte 2015 endete, wurde ein Smart Meter Gateway (SMGW) von der DECOIT^® GmbH mit der Hochschule Bremen zusammen entwickelt. Ziel war es, einen funktionsfähigen Prototypen zu entwickeln, der zeitnah in ein zertifiziertes Produkt überführt werden kann. Dieses Vorhaben verzögerte sich aber zum einen durch fehlende Spezifikationen und zum anderen durch verzögerte Hersteller-Zulieferungen. Es konnten trotzdem innerhalb des Projektes Feldtests mit anderen Herstellern durchgeführt werden. Dabei unterstützte kein anderer Hersteller den innovativen TNC-Ansatz der Trusted Computing Group (TCG), der eine Remote Attestation ermöglicht, um aus der Ferne die Integrität des SMGW abzufragen. Die Produktentwicklung ist bislang nicht abgeschlossen worden, so dass das SPIDER-Projekt trotz des eigentlichen Ablaufdatums immer noch durch die Industriepartner am Leben gehalten wird. Ein erster Feldtest bei einem Energieversorger soll dieses Jahr noch erfolgreich abgeschlossen werden.

Industrie 4.0

Ein weiteres wichtiges Sicherheitsthema stellt Industrie 4.0 dar. Hier kann eine zunehmende Anzahl und ansteigende Komplexität eingesetzter IT-Komponenten beobachtet werden. Es ist aktuell ein Wandel, von geschlossenen, isolierten Anlagen hin zu vernetzten und interagierenden Anlagenverbünden auszumachen. Cyberkriminalität entsteht dabei durch Unachtsamkeit, zunehmende Komplexität und unzureichendes Verständnis. Zusätzlich werden neue Komponenten in alte Infrastrukturen eingebettet. Im Forschungsprojekt SMARTEST (http://www.p2psmartest-h2020.eu/) wurde daher eine Modellierung der Systemlandschaft vorgenommen. Dabei wurden die Netzwerk- und Steuerlogikeigenschaften von Industrie4.0-Umgebungen berücksichtigt. Generell findet eine Segmentierung der Zonen nach Funktionen dabei statt. Ein erster Vorschlag eines ganzheitlichen, anlagenunabhängigen Ansatzes zur systematischen Sicherheitsuntersuchung und Identifizierung möglicher Bedrohungsszenarien sowie Angriffsstrategien wurde ebenfalls erarbeitet. Ziel ist es, einen einheitlichen Ansatz zur strukturierten Abbildung von Systemlandschaften zu finden.

Industrieroboter

Auch Industrieroboter können eine neue Gefahrenquelle bei Industrie 4.0 ausmachen. Sie sind neuerdings vernetzt und die notwendigen Sicherheitsmaßnahmen werden oftmals ignoriert. Auch werden Schweißroboter teilweise absichtlich manipuliert, um weniger Schweißpunkte zu setzen. Zusätzlich werden kollaborative Roboter nicht mehr eingezäunt, da sie mehr mit dem Menschen zusammenarbeiten sollen. Aber diese Roboter bleiben gefährlich, wenn sie nicht abgesichert werden. Es gibt im Robotik-Bereich ein Open-Source-Projekt seit 2008: Robot Operating System (http://www.ros.org). Allerdings besitzt ROS keinerlei Sicherheitsmechanismen. Daher wurden Authentifizierung und Vertraulichkeit eingebaut. Auf der Anwendungsebene wurden einige Sicherheitsmerkmale eingeplant. Eine Hardware-Sicherheit ist aber wesentlich schwerer herzustellen.

Smart Home System

Abschließend wurde ein Angriff auf ein Smart Home System eines Babymonitorsystems durchgeführt, denn auch die Vernetzung von Heimkomponenten stellt ein neues Sicherheitsrisiko dar, was vielen Herstellern nicht bewusst ist. Früher gab es den isolierten Betrieb, während heute eine Vernetzung, teilweise per App mit dem Mobilfunkgerät, vorherrscht. Früher konnte man mit dem Babyphone Tonübertragung über kurze Distanzen ermöglichen. Heute handelt es sich um High Tech Systeme mit Bild- und Tonübertragung, Kamerasteuerung, Aufnahmefunktionen etc. Mittels Shodan-Suchmaschine (https://www.shodan.io) können unsichere (offene) Systeme ausfindig gemacht werden. Hersteller haben meistens keine Sicherheitsfunktionen eingeplant oder bieten diese nicht dem Anwender explizit an. Es wurde daher ausgiebig das Herausfinden eines Root-Passworts aufgezeigt und wie man an die sensiblen Daten herankommt bzw. eine direkte Videoaufzeichnung ermöglicht. Allgemeines Problem: es werden alte Techniken verwendet und mit der IT-Infrastruktur vernetzt. Dies betrifft auch sensiblere Systeme als ein Babyphone, was deutlich werden sollte.

Die DACH Security war wieder einmal sehr informativ und gab Anregungen zum Thema IT-Sicherheit mit auf den Weg. Zusätzlich konnte die DECOIT^® GmbH wieder einmal ihre Arbeiten in diesem Bereich einer größeren Öffentlichkeit präsentieren, was durchaus auch nach dem Vortrag noch rege diskutiert wurde. Die nächste DACH Security für nächstes Jahr im September geplant – dieses Mal in München. Dort werden wir sicherlich auch wieder mit einem interessanten Thema vertreten sein.