Home / Aktuelles & Termine / it.sec blog

„Ransomware“ sollte auch durch die mediale Verbreitung niemandem mehr ein Fremdwort sein. Kurz erklärt ist Ransomware ein Schadprogramm, das eine kritische Lücke im System ausnutzt, um bspw. alle greifbaren Daten (lokal auf dem Rechner, aber auch auf Netzwerkfreigaben) zu verschlüsseln, die dann - laut Angreifer - nur gegen Bezahlung (vorwiegend in Bitcoins) wieder entschlüsselt werden. Dass Ransomware also keine leichtzunehmende Bedrohung ist, hat sich spätestens seit WannaCry & Co. gezeigt. Allein davon waren weltweit über 300.000 Geräte infiziert und der Schaden wird auf ca. 4 Milliarden US-Dollar geschätzt. Bei solch einem immensen Schaden blieben selbst deutsche Unternehmen nicht verschont. So war u.a. die Deutsche Bahn von der Ransomware betroffen. Damit wäre nun auch im globalen Maße bewiesen, dass ein Zusammenbrechen von realer Infrastruktur durch Software nicht mehr nur die Fantasie eines Hollywood-Films ist.

Ein weiteres erschreckendes Beispiel ist, dass eine Variante namens "SamSam", u.a. die komplette IT eines ganzen Krankenhauses in den USA lahm legte. Hier forderten die Angreifer 4 Bitcoins (zu dem damaligen Zeitpunkt umgerechnet ca. 55.000 US-Dollar). Das Krankenhaus war anfangs gegen eine Bezahlung und musste daher auf Papier und Stift umsteigen, entschied sich aber nach zwei Tagen das Lösegeld zu bezahlen. In diesem Fall kam der Erpresser seinem Versprechen nach und entschlüsselte die Dateien.

Doch ist dies immer der Fall? Leider nein!
Des Öfteren werden die Daten so verschlüsselt, dass ein Entschlüsseln nicht mehr möglich ist und auch gar nicht erst von den Angreifern eingeplant wird. Unzählige Opfer verfügen darüber nicht genügend Kenntnisse und wissen sich oft nicht anders zu helfen und greifen somit zur Geldbörse. Wie der "Telstra Security Report" zeigt, konnten in ca. 80 % der Vorfälle die Daten entschlüsselt werden.

Der Report enthält aber auch das erschreckende Ergebnis einer Umfrage, dass vier von fünf Ransomware-Opfer bei einer erneuten erfolgreichen Attacke den Erpresserbetrag wieder bezahlen würden, sofern keine Backups vorhanden sind. Das Signalwort hierbei ist "erneut". Bedeutet dies nun, dass diejenigen, die bereits einmal Opfer einer Ransomware-Attacke wurden, sich kaum bis keine Gedanken über die Sicherheit ihrer Daten machen und wie die Daten gegen Angriffe von außen besser geschützt werden können?!? Unserer Erfahrung nach leider ja!

Ob nun von Hand oder mittels Software, tägliche Backups von kritischen Daten sollten heutzutage zum Standard gehören. Dabei ist es wichtig mit Blick auf Ransomware, dass mindestens ein Backup-Medium offline ist, d.h. abgekoppelt von allen Verbindungen, z.B. eine externe und manuell abschaltbare Festplatte.

Neben dem Backup der Daten, empfiehlt es sich auch jegliche eingesetzte Software auf dem neuesten Stand zu halten, um sich gegen Ransomware zu schützen. Auch sollte das Bewusstsein der Mitarbeiter oder von Freunden und Verwandten geschult werden und lieber zweimal überlegt werden, bevor man Links oder Anhänge in E-Mails anklickt oder öffnet. Dadurch wird das Risiko eines erfolgreichen Ransomware-Angriffs deutlich verringert. Der damit einhergehende Imageverlust bei Unternehmen fällt weg und es spart eine Menge Geld (und Nerven).

Bitte bedenken Sie auch, dass jede Lösegeldzahlung das Geschäftsmodell Ransomware weiter fördert.

Christian Stehle Junior IT Security Consultant und
Christopher Schöndube Senior IT Security Consultant

Am 15.05.2018 hat ein Forscherteam ein Paper veröffentlicht, in dem verschiedene Angriffsszenarien auf verschlüsselte E-Mails beschrieben werden. [1]

Die grundsätzliche Idee ist, das Verhalten von E-Mailprogrammen bzw. das Verhalten beim Darstellen von E-Mails dahingehend zu beeinflussen, dass Daten, nach dem regulären Entschlüsseln einer E-Mail, über einen "Backchannel" (geheimer, verdeckter Rückkanal) an den Angreifer zurückgeleitet werden.

Möglicher Angriffsablauf:

  1. Ausgangssituation: Ein Angreifer (Mallory) ist im Besitz einer verschlüsselten Nachricht (A) von Alice (z.B. durch Kompromittierung des E-Mail Servers, oder durch Zugriff auf ihr E-Mail-Postfach).
  2. Mallory erzeugt eine neue manipulierte E-Mail (B), die die verschlüsselte Nachricht (A) enthält.
  3. Der Angreifer versendet die manipulierte E-Mail (B) an Alice. Dabei wird die E-Mail mit dem Public Key von Alice erneut verschlüsselt.
  4. Alice öffnet die E-Mail und kann, da sie im Besitz des privaten Schlüssels ist, die E-Mail entschlüsseln. Je nachdem wie ihr E-Mail Client konfiguriert ist, kann nun die ursprüngliche Nachricht (A) durch ausnutzen von Schwachstellen abgegriffen werden, wenn
    1. das E-Mailprogramm HTML auswertet,
    2. automatisch Ressourcen (Bilder, Stylesheets, ...) nachgeladen werden, oder
    3. der Client von Bob die Webseite des Angreifers erreichen kann.

Gegenmaßnahmen

Um solche Angriffe zu verhindern sollten folgende Gegenmaßnahmen umgesetzt werden:

  • Der E-Mail Client sollte so konfiguriert werden, dass externe Ressourcen (Bilder, Stylesheets, Schriftarten, ...) nicht automatisch geladen werden. Dies ist auch generell aus Datenschutzgesichtspunkten zu empfehlen.
  • Der Einsatz von HTML E-Mails beim Einsatz von Verschlüsselung sollte vermieden / blockiert werden.
  • Das automatische Entschlüsseln von Nachrichten sollte deaktiviert werden.
  • E-Mail Clients sollten aktuell gehalten werden.
  • E-Mail Plugins für den Einsatz von Verschlüsselung sollten aktuell gehalten werden.

Fazit:

Handelt es sich bei EFAIL um das Ende von S/MIME und PGP? Definitiv nicht, auch wenn bei S/MIME und PGP leider noch kein ausreichender Integritätsschutz implementiert ist.

Die von den Forschern dargestellten Angriffsszenarien sind größtenteils sehr aufwendig, oder leicht zu verhindern, so dass wenn die entsprechenden Gegenmaßnahmen umgesetzt sind, das Risiko auf ein akzeptables Niveau reduziert werden kann. Wer das Risiko noch weiter verringern möchte, kann das Entschlüsseln von E-Mails außerhalb des E-Mailprogramms durchführen.

[1] https://efail.de/efail-attack-paper.pdf

Anfang Januar 2018 wurden drei erhebliche Schwachstellen in den meisten modernen Prozessoren veröffentlicht. Diese wurden von drei unterschiedlichen Forscherteams entdeckt (Google Project Zero, Cyberus Technology, Graz University of Technology) und sind unter den zwei Namen

  • Meltdown (CVE-2017-5754 Rogue Data Cache Load) und
  • Spectre (CVE-2017-5715 - Branch Target Injection und CVE-2017-5753 - Bounds Check Bypass)

bekannt geworden. Sie betreffen nicht nur Desktop- und Serverrechner, sondern auch Mobilgeräte. [1] [2]

Diese Schwachstellen ermöglichen es einem Angreifer potenziell den gesamten Arbeitsspeicher eines Systems auszulesen - inklusive beispielsweise Passwörtern, Krypto-Schlüsseln oder persönlichen und vertraulichen Daten.

Bei den drei Sicherheitslücken handelt es sich um Designprobleme in den Prozessoren. Daher sind sie praktisch für alle Betriebssysteme (Windows, MacOS, Linux, AIX, Android, iOS, etc.) relevant. Meltdown kann zwar durch Softwarepatches vollständig behoben werden, Spectre jedoch – zumindest mit Stand heute – nicht. Ein vollständiger Schutz vor Spectre ist durch die jetzigen Patches nicht gegeben, der Angriff wird nur erschwert, bzw. die Erfolgsquote reduziert.

Wording in Veröffentlichungen

Man liest sehr oft, dass durch aktuelle Patches ein Spectre-Angriff erschwert würde. Diese Aussage ist zwar richtig, man muss sie aber richtig lesen. Leider bleibt dann nicht mehr viel an Sicherheit davon übrig:

Ein einzelner Angriff zielt darauf ab, einen Datenblock aus dem CPU-Speicher auszulesen, der einem nicht gehört. Das dauert vielleicht einige Millisekunden. Der Erfolg eines einzelnen Angriffs ist nicht garantiert, man kann es aber immer wieder probieren, irgendwann klappt es.

Nach dem Patch sinkt die Chance, dass es klappt, was aber leider nicht mehr heisst, als dass ein Angreifer es halt ein paar mal mehr versuchen muss, bis es klappt.

Die Folge ist nur, dass man es nur schwer schaffen wird sich in kurzer Zeit (Sekunden oder Minuten) ein zusammenhängendes, vollständiges und zeitlich integres Speicherabbild des Hosts zusammenzubauen. In längerer Zeit bekommt man aber trotzdem alle möglichen Speicherfragmente zu sehen - und das kann reichen. Es ist ein wenig wie Fliegen fangen. Es ist schwer, aber irgendwann kriegt man sie schon.

Zur Darstellung der möglichen Auswirkungen haben wir verschiedene Szenarien unterschieden:

- Einzelplatz-PC bzw. Smartphones

Mit Hilfe einer der Schwachstellen kann ein Angreifer Zugriff auf Daten erhalten, auf die er sonst keinen Zugriff hätte. Hierzu muss er Code auf dem System ausführen dürfen ohne besondere Rechte dafür haben zu müssen, was im Grunde überall, z.B. durch JavaScript, oder durch eine präparierte App auf einem Smartphone, möglich ist. Dabei können Datenfragmente auch aus Speicherbereichen anderer Prozesse oder virtueller Maschinen ausgelesen werden und zu einem Gesamtbild zusammengesetzt werden. Aber auch schon einzelne Speicherfragmente können Informationen wie Passwörter, Verschlüsselungs-Keys, E-Mails oder dergleichen enthalten.

- Client-Server Architektur

Mit Hilfe von Meltdown & Spectre können nur Daten aus dem Speicher des physischen Servers ausgelesen werden, auf dem der Angriffscode ausgeführt wird. Somit besteht bei physisch dedizierten Systemen keine direkte Gefahr für Angriffe vom Client aus, solange kein Code vom Client aus auf dem Server ausgeführt werden kann. Dies ist zumindest bei Fileserver Anwendungen i.d.R. nicht der Fall. Anders sieht es aus, wenn man RDP oder Citrix (oder ssh oder anderen interaktiven) Zugriff auf einen Rechner hat.

- Virtualisierte Systeme

Bei virtualisierten Systemen muss zwischen voll-virtualisierten Systemen (z.B. VMware, Hyper-V) und para-virtualisierten (bei der Para-Virtualisierung steht dem Gastsystem lediglich ein API-Zugriff auf die Host-Hardware zur Verfügung, z.B. Xen) bzw. Betriebssystemvirtualisierung (hierbei teilen sich das Gastsystem und das Hostsystem den Kernel, z.B. Docker, Linux Container LXC) unterschieden werden.

Para-Virtualisierung und Betriebssytemvirtualisierung können sowohl durch Meltdown als auch durch Spectre angegriffen werden. Hierbei kann u.U. der gesamte Arbeitsspeicher des Hosts ausgelesen werden - und damit auch der aller virtuellen Maschinen.

Voll-virtualisierte Systeme sind für Meltdown nur dahingehend verwundbar, dass innerhalb eines virtuellen Systems Daten ausgelesen werden können, innerhalb von diesem aber wiederum aus dem gesamten dieser virtuellen Maschine zugeordneten Speicher - also auch der anderer Prozesse und Benutzer oder des Kernels.

Spectre kann theoretisch auch hier die Grenzen zwischen den virtuellen Systemen überwinden und von anderen Systemen und dem Host Daten auslesen. Google hat nach eigenen Angaben in einem PoC bereits gezeigt, dass bei einer virtuellen Maschine Daten aus dem Kernelspeicher des Hosts ausgelesen werden konnten. [2]

- Cloud

Für Cloud Anbieter, welche (Para-)Virtualisierung nutzen, gelten die gleichen Aussagen von oben für virtualisierte Systeme. Allerdings ist der Impact möglicherweise noch größer als innerhalb einer Institution: es können unter Umständen Daten von anderen Kunden ausgelesen werden. Wirklich wirksame Gegenmaßnahmen gibt es derzeit nicht.

Diesen Aspekt darf man sich getrost auf der Zunge zergehen lassen und das erste Aha-Erlebnis noch ein wenig mit Risiko- und Compliance-Aspekten nachwürzen.

Komplexität eines Angriffs

Die Schwachstellen können ausgenutzt werden, wenn ein Angreifer irgendwelchen Code auf einem System ausführen kann, ohne besondere Rechte. Dies ist aber immer der Fall (er benutzt ja Programme) und kann z.B. auch schon über den vorhandenen Webbrowser geschehen, z.B. durch JavaScript. Bei Meltdown sind nicht einmal genaue Kenntnisse des angegriffenen Prozesses notwendig, bei Spectre hingegen sind tiefgründige Kenntnisse über den eingesetzten Prozessor, dessen Branch Prediction Unit, sowie den anzugreifenden Prozess notwendig. Dieses Wissen ist derzeit nicht öffentlich verfügbar. Die vorgestellten Proof-of-Concepts wurden bisher nur unter Laborbedingungen durchgeführt. Aber eben nur "bisher".

Bis heute sind offenbar keine Exploits (Ausnutzen der Schwachstellen von einem Angreifer) in Umlauf. Da der Angriff jedoch keine Spuren hinterlässt, kann nicht mit Sicherheit gesagt werden, dass keine Angriffe stattfanden. Insbesondere durch das Bekanntwerden des Angriffs ist mit Sicherheit davon auszugehen, dass früher oder später neue Exploits entwickelt und verbreitet werden.

Das Szenario, dass nach und nach immer bessere Angriffswerkzeuge („Exploits“) öffentlich verfügbar sein werden und der Werkstudent oder die Sekretärin in ihrer Citrix-Sitzung den Serverspeicher des Virtualisierungs-Hosts per Skript in einer E-Mail auslesen können, ist nicht so sehr weit hergeholt. Aber auch Remote Angriffe per Web-Seite sind möglich.

Antivirus

Virenscanner werden vermutlich nur eingeschränkt - wenn überhaupt - in der Lage sein, Angriffe zu erkennen, da diese weitgehend dem normalen Verhalten von Programmen entsprechen. Klar es wird Heuristiken geben, aber auch klar, die kann man austricksen.

Datenschutzaspekte

Wie weit kann virtuellen oder Multiuser-Systemen überhaupt noch vertraut werden und wie teuer kann es unter der DSGVO werden, wenn man sich nicht ernsthaft mit der Lösung beschäftigt hat? Man kann die Situation durchaus so bewerten, dass ohne weitere Maßnahmen, die über bloßes Patchen hinausgehen, die Sicherheit der Datenverarbeitung nach Art. 32 DSGVO nicht mehr überall gewährleistet ist. Über den Art. 83 DSGVO kann man dann erahnen, wie teuer es werden könnte (nämlich bis zu theoretischen 10Mio. € oder 2% des weltweiten Vorjahresgesamtumsatzes des Unternehmens).

Andererseits wird kein Datenschutzbeauftragter seinen Mandanten raten können, die Datenverarbeitung vorübergehend auszusetzen, bis man alles umgebaut und die Daten nach Hardware sortiert getrennt verarbeiten kann.

Wir werden diese Frage der Einschätzung daher an die Aufsichtsbehörden für den Datenschutz richten und weiter berichten!

Fazit

Durch die Bemühungen der verschiedenen Soft- und Hardwarehersteller wurde in der Vergangenheit die Sicherheit stetig verbessert. Nun zeigen Meltdown und Spectre, dass sich die Risikolage von jetzt auf gleich ändern kann.

Meltdown und Spectre zeigen sehr grundlegende Schwachstellen auf, die auf Hardwaredesignproblemen beruhen. Wodurch, zumindest bei Spectre, das Patchen deutlich erschwert, wenn nicht gar unmöglich wird. Somit ist die eigentliche Herausforderung, das Risiko entsprechend (neu) zu bewerten und wie in einem Unternehmen alternative, kompensatorische Maßnahmen umgesetzt werden können. Spectre-Patches können u.E. derzeit nicht als wirksam angesehen werden.

Die Auswirkungen sind im Grunde so gewaltig, dass man gerne dazu tendiert sie nicht wahrhaben zu wollen. Bringt aber nix.

Aktuelle Empfehlungen

  • Die Schwachstellen sind im Rahmen des regulären Schwachstellen Managements zu bewerten und zu behandeln, also im Rahmen des jeweiligen Verfahrensrisikos. Wichtig: Rosa Brille weg und Risiken realistisch einschätzen! Wie Sie handeln bleibt immer noch Ihnen überlassen, aber machen Sie sich nichts vor!
  • Nach erfolgreichem Test sollten die vorhandenen Patches (Betriebssystem und Mikrocontroller) ausgerollt werden. Tests sind wichtig, da die Hersteller in der Eile auch schon nicht-funktionale Patches verteilt haben.
  • Im Rahmen des Risikomanagementprozesses sollten die Schwachstellen bzw. Patches zumindest für absehbare Zeit, in kurzen Abständen, etwa wöchentlich, neu bewertet werden.
  • Aktuell hilft wohl nur die hardwarebasierte Trennung von wirklich relevanten Daten. Wer bisher Medizindaten und die Parkplatzverwaltung auf derselben Hardware hatte, sollte umdenken!
  • Vendor Management: fordern Sie von Ihrem Cloud Anbieter Aussagen ein, wie er gedenkt Ihre Daten vor anderen zu schützen! Hier wird es auch rechtlich spannend, denn was er tun muss und was nicht, und was dann davon ihr Problem bleibt oder seins, das hängt von Ihrem Vertrag ab.
  • Wenn Sie personenbezogene oder hochsensible Daten bearbeiten, empfehlen wir einen noch strengeren Blick. Noch gibt es keine aufsichtsbehördliche Stellungnahme wie mit einer Situation umzugehen ist, in die man durchaus interpretieren kann, dass viele Verfahren auf absehbare Zeit nicht weiter betrieben werden dürften. Unter der Strafandrohung des BDSG war das nicht weiter schlimm. Die DSGVO wartet da mit ganz anderen Geschützen auf.

Autoren: Florian Franke, Holger Heimann, Christian Stehle

[1] https://meltdownattack.com/

[2] https://googleprojectzero.blogspot.de/2018/01/reading-privileged-memory-with-side.html

Abbinder Abmahnung Abmahnungen Abo-Falle ADCERT Angemessenheitsbeschluss Angriff Anklage Anwendbarkeit Anwendung Arbeitgeber Arbeitnehmer Arbeitsrecht Art. 17 DSGVO Art. 25 DSGVO Art. 26 DSGVO Art. 32 DSGVO Art. 37 DSGVO Art. 4 Nr. 12 DSGVO Art. 45 DSGVO Art. 8 MRK Art. 9 DSGVO Auchfsichtsbehörde Audit Aufsichtsbehörde Auftragsverarbeiter Auftragsverarbeitung Auskunftei Auskunftsrecht Automatisierte Einzelentscheidung Autsch Backup BAG BayDSG Bayerisches Datenschutzgesetz BDSG-Neu BEAST Begrifflichkeiten Beherbergungsstätten BEM Benachrichtigungspflicht Beschäftigtendatenschutz besondere Kategorien personenbezogener Daten betriebliche Eingliederungsmanagement betriebliche Nutzung betrieblicher E-Mail-Account betrieblicher Internetzugang Betriebsvereinbarung Betroffenenrechte BfDI BGH Bildberichterstattung Bildrechte biometrische Daten Biometrische und genetische Daten Bitcoins Bitkom Bonitätsprüfung Brexit Browser Bund Bundesarbeitsgericht Bußgeld Bußgelder BVG Cloud CNIL Compliance Cookie Custom Audience Cyber Dashcam Daten Datenlöschung Datenminimierung Datenpanne Datenschutz Datenschutz Grundverordnung Datenschutz-Folgenabschätzung Datenschutz-Schulungen Datenschutzabkommen Datenschutzauskunft-Zentrale Datenschutzbeauftragte Datenschutzbeauftragter Datenschutzerklärung Datenschutzgrundsätze Datenschutzgrundverordnung datenschutzkonform Datenschutzprinzipien Datenschutzverletzung Datensicherheit Datenübermittlung Datenübermittlung an Dritte Datenübermittlung in Drittstaaten Datenverarbeitung Dating Dating-Portale Deutsche Bahn Dienstleister Do not track-Funktion Donald Trump Dritter Drittstaat ohne angemessenes Datenschutzniveau Drittstaaten DSAnpUG-EU DSGVO DSK dynamische IP-Adresse E-Mail e-Privacy-Verordnung E-Rechnung eCall-Technologie EES EFAIL Einwilligung Einwilligungserklärung Einwilligungserklärungen Empfänger Entsorgung Erhebung Erhebung personenbezogener Daten Erwägungsgrund 48 der DSGVO eSafety-Initiative ETIAS EU EU-Datenschutz-Grundverordnung EU-Parlament EuGH Europäische Union Extra-Bezahlung Extra-Kosten Facebook Facebook-Fanpages Facebook-Pixel Fachbereich Fahrzeugdaten Fahrzeuge Fanpage Fanpagebetreiber FBI Feedback Fernmeldegeheimnis FlugDaG Fluggastdaten Folgenabschätzung Foto Funkmäuse Funktastaturen Geldbörse Gemeinsam Verantwortliche Gericht Gesetz gegen den Unlauteren Wettbewerb Gesundheitsdaten Google Google Analytics hacken Hacker Hash-Verfahren Hausverwaltung Head of Cyber Security Architectur Home Office Immobilienmakler Informationspflicht Informationspflichten Informationssicherheit Infrastruktur Inhalteanbieter Insights interner Datenschutzbeauftragter Investition IP-Adresse Irland ISO/IEC 27001 IT Governance IT GRC IT-Forensik IT-forensische Untersuchung IT-Security IT-Sicherheit IT-Systeme ITSECX Jin-hyok Joint Control Kanada Keynote Klagebefugnis Klingelschilder Kommune Konferenz Kontaktdaten Kontakte Konzern konzerninterner Datentransfer KoSIT Kriminalität KUG Kundenbindung Kundenzufriedenheit Kunsturhebergesetz Lazarus Leistungs- und Verhaltenskontrolle Löschung personenbezogener Daten Löschungsrecht Lösegeld Malware Markennamen Markenrecht Marktortprinzip MD5 Meldepflicht Meldescheine Meldung Meltdown Messenger Microsoft Mieter Misch-Account Mitarbeiter Mitbewerber MouseJack-Angriffe Netzwerklabor NIST Nordkorea Nutzungsbedingungen Öffnungsklauseln One Stop Shop Österreich Papierrechnung Passenger Name Records Passwort Passwörter Passwörter. 2016 Passwortregeln Passwortschutz Patientendaten Penetrationstest Personalausweiskopien personenbezogene Daten Personenbilder Persönlichkeitsrechte Pflichten Plattformbetreiber PNR-Daten PNR-Instrumente POODLE Privacy by Default Privacy by Design Privacy Shield privat private Handynummer private Mobilfunknummer Privatnutzung Privatnutzungsverbot Privatsphäre Profiling Quantencomputer Ransomware reale Infrastruktur Rechenzentren Rechenzentrum Recht auf Achtung des Privat- und Familienlebens Recht auf Berichtigung Recht auf Datenübertragbarkeit Recht auf Einschränkung Recht auf Löschung Rechte Rechte der betroffenen Person Referenten Regelungsaufträge Reichweitenanalyse Risiko Risikomanagement Risk & Compliance Management Rufschädigung SamSam Sanktionen Schaden Schadprogramm Seitenbetreiber SHA1 sicher Sicherheitsvorfall Sicherheitsvorfälle kritische Infrastrukturen IT-Sicherheitsbeauftragten ISMS Sicherung der Daten Siegel Skype Smartphone Software Software-Entwicklung Sony Sony PSN Soziale Netzwerke Spectre Sponsoren Standardvertragsklauseln Strafe Strafverfolgung Studenten Supercomputer Risikolage Support Technische & organisatorische Maßnahmen technische & organisatorische Maßnahmen Telefonnummer Telemediendienst Telemediengesetz Telstra Security Report TKG TLS TMG Tracking Tracking Tools Twitter Übermittlung personenbezogener Daten Überwachungssoftware Umfrage Umsetzungsfrist unpersonalisierter Benutzer-Account Unternehmensgruppe US-Regierung USA UWG Verantwortlicher Verantwortung Vereinbarung Vernichtung von Datenträgern Veröffentlichung Verordnung (EU) 2015/758 verschlüsseln Verschlüsselte E-Mails Verschlüsselungsverfahren Verstoß Verstöße Vertrag zur Auftragsverarbeitung Verwaltungsakt Verwaltungsgericht Karlsruhe Videoüberwachung Virus Vorteile WannaCry Webseite Webseiten Webtracking Webtrecking Werbeaussage Werbung Wettbewerb Wettbewerbsrecht wettbewerbsrechtliche Abmahnung Wettbewerbsverstöße WhatsApp Whistleblowing Widerruf Widerrufsrecht Widerspruchsrecht Wohnung X-Rechnung Zertifikat Zertifizierung Zugangsdaten Zugriff zulässig Zulässigkeit § 15 TMG § 26 BDSG-Neu § 32 BDSG § 32 DSGVO § 35 BDSG-Neu § 38 BDSG-Neu § 3a UWG § 42a BDSG § 42b BDSG § 88 TKG

Tags

Mo Di Mi Do Fr Sa So
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
31