LfDI Bre­men: LfDI ver­hängt gegen die BREBAU GmbH Geldbuße

Am heu­ti­gen Tage hat die Lan­des­be­auf­trag­te für Daten­schutz und Infor­ma­ti­ons­frei­heit (LfDI) als daten­schutz­recht­li­che Auf­sichts­be­hör­de die BREBAU GmbH mit einer Geld­bu­ße nach Arti­kel 83 Daten­schutz­grund­ver­ord­nung (DSGVO) belegt.

Die BREBAU GmbH hat mehr als 9.500 Daten über Mietinteressent:innen ver­ar­bei­tet, ohne dass es hier­für eine Rechts­grund­la­ge gab. Bei­spiels­wei­se Infor­ma­tio­nen über Haar­fri­su­ren, den Kör­per­ge­ruch und das per­sön­li­che Auf­tre­ten sind für den Abschluss von Miet­ver­hält­nis­sen nicht erfor­der­lich. Bei mehr als der Hälf­te der Fäl­le han­del­te es sich dar­über hin­aus um Daten, die nach der DSGVO beson­ders geschützt sind. Rechts­wid­rig ver­ar­bei­tet wur­den auch Infor­ma­tio­nen über die Haut­far­be, die eth­ni­sche Her­kunft, die Reli­gi­ons­zu­ge­hö­rig­keit, die sexu­el­le Ori­en­tie­rung und über den Gesund­heits­zu­stand. Auch hat die BREBAU GmbH Anträ­ge Betrof­fe­ner auf Trans­pa­renz über die Ver­ar­bei­tung ihrer Daten bewusst konterkariert.

Die nach Arti­kel 83 DSGVO ver­häng­te Geld­bu­ße beläuft sich auf rund 1,9 Mil­lio­nen Euro. Der außer­or­dent­li­chen Tie­fe der Ver­let­zung des Grund­rechts auf Daten­schutz wäre eine deut­lich höhe­re Geld­bu­ße ange­mes­sen gewe­sen. Weil die BREBAU GmbH im daten­schutz­recht­li­chen Auf­sichts­ver­fah­ren umfas­send koope­rier­te, sich um Scha­dens­min­de­rung, eige­ne Auf­klä­rung des Sach­ver­halts und dar­um bemüh­te, dass ent­spre­chen­de Ver­stö­ße sich nicht wie­der­ho­len, konn­te die Höhe der Geld­bu­ße erheb­lich redu­ziert werden.

Anläss­lich die­ses Auf­sichts­ver­fah­rens äußer­te die Lan­des­be­auf­trag­te für Daten­schutz und Infor­ma­ti­ons­frei­heit, Dr. Imke Som­mer: „Im Zusam­men­hang mit der öffent­li­chen Dis­kus­si­on über den Fall, der die­sem daten­schutz­recht­li­chen Auf­sichts­ver­fah­ren zugrun­de liegt, bin ich häu­fig gefragt wor­den, ob die DSGVO Dis­kri­mi­nie­run­gen ver­bie­tet. Die Ant­wort auf die­se Fra­ge ist kom­pli­ziert, weil die DSGVO in spe­zi­fi­scher Wei­se auf Sach­ver­hal­te schaut. Nach der DSGVO ist es nur in weni­gen Aus­nah­me­fäl­len über­haupt erlaubt, Daten über Haut­far­be, eth­ni­sche Her­kunft, Reli­gi­ons­zu­ge­hö­rig­keit, sexu­el­le Ori­en­tie­rung und über den Gesund­heits­zu­stand zu ver­ar­bei­ten. Damit sorgt die DSGVO dafür, dass die­se beson­ders geschütz­ten Daten in den aller­mei­sten Fäl­len gar nicht erst erho­ben und gespei­chert wer­den dür­fen. Nicht erho­be­ne Daten kön­nen nicht miss­braucht wer­den. In die­sem Sin­ne schützt die DSGVO auch vor Diskriminierungen.“

Die Web­sei­te der bre­mi­schen Lan­des­be­auf­trag­ten für Daten­schutz und Infor­ma­ti­ons­frei­heit kann hier abge­ru­fen werden.

Bit­kom: IT Sicher­heits­maß­nah­men vor Kon­flikt­aus­tra­gun­gen im Cyberraum

Kon­flik­te wer­den heut­zu­ta­ge auch im digi­ta­len Raum aus­ge­tra­gen. Zwar ist die Situa­ti­on in der Ukrai­ne in die­sem Sin­ne noch nicht hier­zu­lan­de ange­kom­men, doch soll­ten Unter­neh­men ihre IT-Sicher­heit für einen Ernst­fall prü­fen. Der Bit­kom nennt fünf Maß­nah­men, die Unter­neh­men jetzt ergrei­fen sollten.

Die Offen­si­ve Russ­lands begann im digi­ta­len Raum bereits eini­ge Zeit vor dem Ein­marsch in die Ukrai­ne. „Wäh­rend Cyber­an­grif­fe auf mili­tä­ri­sche Ziel­sy­ste­me, Behör­den und Insti­tu­tio­nen bereits seit län­ge­rem statt­fin­den, spiel­te der digi­ta­le Raum in den ersten Tagen des rus­si­schen Angriffs­kriegs nur eine nach­ge­la­ger­te Rol­le. Mit zuneh­men­der Kriegs­dau­er könn­te sich dies wie­der ändern, und das kann unmit­tel­ba­re Kon­se­quen­zen für Deutsch­land und sei­ne Wirt­schaft haben. Denn die Distan­zen im digi­ta­len Raum sind kurz und die Gren­zen nicht so klar, wie sie sein müss­ten“, erklärt Bit­kom-Sicher­heits­ex­per­te Seba­sti­an Artz. „Es gibt kei­nen Grund zur Panik, aber mit dem Angriffs­krieg Russ­lands ist auch im deut­schen Cyber­raum vol­le Auf­merk­sam­keit und größt­mög­li­che Wach­sam­keit aller Unter­neh­men, Orga­ni­sa­tio­nen und staat­li­chen Stel­len geboten.“

Der Digi­tal­ver­band Bit­kom gibt des­halb fünf kon­kre­te Hin­wei­se, wel­che Vor­be­rei­tun­gen und Vor­sichts­maß­nah­men ins­be­son­de­re klei­ne und mit­tel­stän­di­sche Unter­neh­men jetzt für ihre IT-Sicher­heit tref­fen sollten:

1. Risi­ken und Aus­wir­kun­gen von Cyber­an­grif­fen minimieren

Unter­neh­men soll­ten ihre Schutz­maß­nah­men ins­ge­samt ver­stär­ken. Betriebs­sy­ste­me und Soft­ware müs­sen auf dem aktu­el­len Stand sein, Sicher­heits­up­dates sind zügig ein­zu­spie­len. Siche­re – also kom­ple­xe und für jedes System unter­schied­li­che – Pass­wör­ter kön­nen signi­fi­kant das Schutz­ni­veau erhö­hen bei. Mög­lichst alle Log­ins mit Außen­an­bin­dung soll­ten über eine Mul­ti-Fak­tor-Authen­ti­fi­zie­rung geschützt wer­den. Pri­vi­le­gi­en und Admi­ni­stra­ti­ons­rech­te soll­ten für ein­zel­ne Nut­ze­rIn­nen ein­ge­schränkt wer­den und die Kom­ple­xi­tät von ver­wen­de­ten Dien­sten ins­ge­samt ver­rin­gert wer­den. Eine sol­che Här­tung der Syste­me ist rat­sam, obwohl sie nicht nut­zungs­freund­lich ist und die Pro­duk­ti­vi­tät ein­schränkt, denn sie schützt die eige­ne Infra­struk­tur und unter­neh­mens­sen­si­ble Daten. Zudem ist die unter­neh­mens­ei­ge­ne Back-up-Stra­te­gie zu prü­fen und nach­zu­zie­hen, sodass alle rele­van­ten Unter­neh­mens­da­ten gesi­chert sind und zusätz­lich Sicher­heits­ko­pien off­line auf einem exter­nen Daten­trä­ger existieren.

2. Ver­ant­wort­lich­kei­ten klar definieren

Unter­neh­men müs­sen in einem Angriffs­fall reak­ti­ons­fä­hig sein. Ver­ant­wort­lich­kei­ten im Sicher­heits­be­reich müs­sen klar defi­niert sein und ent­spre­chen­de Anlauf­stel­len ein­ge­rich­tet wer­den – sowohl intern als auch bei exter­nen Dienst­lei­stern. Es gilt sicher­zu­stel­len, dass zu jeder Zeit aus­rei­chend Per­so­nal ein­satz­fä­hig ist. Urlaubs­zei­ten oder Ver­tre­tun­gen bei Krank­heit müs­sen dabei ein­kal­ku­liert wer­den. Außer­dem ist es sinn­voll sich dar­auf vor­zu­be­rei­ten, auch ohne die Hil­fe exter­ner Dienst­lei­ster kurz­fri­stig reagie­ren zu kön­nen – bei groß­flä­chi­gen Cyber­an­grif­fen könn­ten Exter­ne an Kapa­zi­täts­gren­zen stoßen.

3. Beschäf­tig­te sensibilisieren

Alle Erfah­run­gen zei­gen: Der Mensch bleibt eines der größ­ten Sicher­heits­ri­si­ken, ist aber auch Schutz­ga­rant eines Unter­neh­mens. Alle Beschäf­tig­ten soll­ten ziel­grup­pen­ge­recht für das erhöh­te Risi­ko von Cyber­an­grif­fen sen­si­bi­li­siert wer­den. Dazu gehört, poten­zi­el­le Gefah­ren ver­ständ­lich zu erklä­ren und Schritt-für-Schritt-Anlei­tun­gen bereit­zu­stel­len, wie sich Beschäf­tig­te im Fal­le eines Angriffs ver­hält und an wen sie sich wen­den müs­sen. Gege­be­nen­falls kön­nen kurz­fri­sti­ge Sicher­heits­schu­lun­gen sinn­voll sein. Ziel ist es, die Wach­sam­keit in der Beleg­schaft zu erhö­hen. Beson­ders für den E‑Mail-Ver­kehr gilt, Hyper­links und Anhän­ge nicht vor­schnell zu öff­nen und unge­wöhn­li­che Anwei­sun­gen mit Skep­sis zu betrach­ten. An Unter­neh­men wer­den auch sehr geziel­te und gut gemach­te Phis­hing-Mails geschickt, wodurch der Fake nur anhand weni­ger Details wie etwa eines falsch geschrie­be­nen Namens oder einer fal­schen Durch­wahl in der Signa­tur ent­deckt wer­den kann.

4. Not­fall­plan erstellen

Für den Fall eines Angriffs soll­te im Unter­neh­men ein Not­fall­plan bereit­lie­gen, der das wei­te­re Vor­ge­hen doku­men­tiert. Neben den tech­ni­schen Schrit­ten, die ein­ge­lei­tet wer­den müs­sen, soll­te der Plan auch orga­ni­sa­to­ri­sche Punk­te wie die Kon­takt­da­ten rele­van­ter Ansprech­per­so­nen im Unter­neh­men sowie die Not­fall­kon­tak­te der offi­zi­el­len Anlauf­stel­len beinhal­ten. Auch recht­li­che Aspek­te wie Mel­de­pflich­ten bei Daten­schutz­ver­let­zun­gen müs­sen berück­sich­tigt wer­den. Des Wei­te­ren gehört eine vor­be­rei­te­te Kri­sen­kom­mu­ni­ka­ti­on dazu, um schnell alle rele­van­ten Sta­ke­hol­der wie Kun­den, Part­ner sowie die Öffent­lich­keit zu informieren.

5. Infor­ma­tio­nen offi­zi­el­ler Stel­len beobachten

Die Sicher­heits­la­ge ist hoch­dy­na­misch und kann sich von Tag zu Tag ändern. Unter­neh­men soll­ten daher die Mel­dun­gen von Behör­den wie dem Bun­des­amt für Sicher­heit in der Infor­ma­ti­ons­tech­nik (BSI) sowie der Alli­anz für Cyber­si­cher­heit (ACS) stets beobachten.

Foto ohne Ein­wil­li­gung – Beschäf­tig­te erhält 5.000 Euro Schadensersatz

ArbG Mün­ster, Urt. v. 25.03.2021 – 3 Ca 391/​20
Mit einem Urteil vom 25.03.2021 (3 Ca 391/​20) hat das Arbeits­ge­richt (ArbG) Mün­ster ent­schie­den, dass einer Beschäf­tig­ten einer Hoch­schu­le eine Ent­schä­di­gung in Höhe von 5.000 Euro zusteht, da die Uni­ver­si­tät ein Foto von der Mit­ar­bei­te­rin zu Mar­ke­ting­zwecken ver­wen­det hat, ohne die erfor­der­li­che Ein­wil­li­gung ein­ge­holt zu haben.

Was war gesche­hen?
Fol­gen­der Sach­ver­halt liegt der Ent­schei­dung zugrun­de: Die Mit­ar­bei­te­rin einer Uni­ver­si­tät wehr­te sich in einem arbeits­recht­li­chen Ver­fah­ren gegen die Ver­wen­dung ihres Fotos. Das Foto der Beschäf­tig­ten wur­de auf­grund ihrer Eth­nie und Haut­far­be als Aus­weis für die Inter­na­tio­na­li­sie­rung der Uni­ver­si­tät genutzt. Die Klä­ge­rin arbei­tet jedoch als Post­doc und hat somit ori­gi­när nichts mit der Inter­na­tio­na­li­sie­rung der Hoch­schu­le zu tun. Bei der Erstel­lung von Foto-Auf­nah­men der Uni­ver­si­tät hat sie aktiv teil­ge­nom­men, jedoch kei­ne Ein­wil­li­gung erteilt. Die Klä­ge­rin ließ ledig­lich münd­lich offen, dass sie mög­li­cher­wei­se zustim­men wür­de, wenn die Fotos für ihre Tätig­keit ver­wen­det wür­den. Nach Ver­öf­fent­li­chung der Fotos und Kennt­nis­nah­me der Klä­ge­rin teil­te die­se mit, dass sie mit der Art der Ver­wen­dung ihrer Bil­der nicht ein­ver­stan­den ist. Die Uni­ver­si­tät erklär­te dar­auf­hin, dass ihr Foto gelöscht wor­den sei, aber es nicht mög­lich sei, die bereits gedruck­ten Bro­schü­ren zurück­zu­zie­hen. Die Klä­ge­rin for­der­te dann Scha­dens­er­satz gemäß Art. 82 DS-GVO, aber eben­so auf Grund­la­ge des Kunst­ur­he­ber­rechts­ge­set­zes (KUG) und § 823 Bür­ger­li­ches Gesetz­buch (BGB).

Kla­ge gegen Arbeit­ge­ber hat Erfolg
Das ArbG Mün­ster ent­schied, dass der Klä­ge­rin ein imma­te­ri­el­ler Scha­dens­er­satz in Höhe von 5.000 Euro zusteht. Die­se Zah­lung wird ger­ne auch als Schmer­zens­geld bezeich­net, stellt aber im Sin­ne der DS-GVO einen imma­te­ri­el­len Scha­dens­er­satz und nach Logik des deut­schen Schuld­rechts eine bil­li­ge Ent­schä­di­gung in Geld dar. Bemer­kens­wert ist, dass die imma­te­ri­el­le Scha­dens­hö­he hier ihrem monat­li­chen Brut­to­lohn ent­spricht. Bei der rich­ter­li­chen Scha­dens­be­mes­sung wur­de aus­drück­lich auch die Bedeu­tung der eth­ni­schen Her­kunft und der Haut­far­be der Mit­ar­bei­te­rin für die Ver­öf­fent­li­chung des Fotos gewürdigt.

Die Ent­schei­dung des Arbeits­ge­richts Mün­ster hat die Fol­gen einer rechts­wid­ri­gen Daten­ver­ar­bei­tung noch ein­mal klar­ge­stellt: Wer Bild­nis­se ohne Zustim­mung der betrof­fe­nen Per­son nutzt, muss mit einer nicht uner­heb­li­chen Sum­me für die Ent­schä­di­gung nach Art. 82 DS-GVO rechnen.

DSK: neue Ori­en­tie­rungs­hil­fe für Anbieter:innen von Tele­me­di­en veröffentlicht

Pres­se­mit­tei­lung der Kon­fe­renz der unab­hän­gi­gen Daten­schutz­auf­sichts­be­hör­den des Bun­des und der Län­der vom 20.12.2021

Die Kon­fe­renz der unab­hän­gi­gen Daten­schutz­auf­sichts­be­hör­den des Bun­des und der Län­der (DSK) hat heu­te eine neue Fas­sung der Ori­en­tie­rungs­hil­fe für Anbieter:innen von Tele­me­di­en ver­öf­fent­licht. Das Papier bie­tet Betreiber:innen von Web­sei­ten, Apps oder Smar­thome-Anwen­dun­gen kon­kre­te Hil­fe­stel­lun­gen bei der Umset­zung der neu­en Vor­schrif­ten des Tele­kom­mu­ni­ka­ti­on-Tele­me­di­en-Daten­schutz-Geset­zes (TTDSG). Zudem ver­mit­telt die Ori­en­tie­rungs­hil­fe betrof­fe­nen Bürger:innen ein bes­se­res Bild der recht­li­chen Rahmenbedingungen.

Mit der Ver­öf­fent­li­chung der über­ar­bei­te­ten Ori­en­tie­rungs­hil­fe reagie­ren die Auf­sichts­be­hör­den auf die ver­än­der­te Rechts­la­ge. Seit dem 1. Dezem­ber 2021 regelt das TTDSG unter ande­rem den Schutz der Pri­vat­sphä­re bei der Nut­zung von End­ge­rä­ten. Dar­aus erge­ben sich ins­be­son­de­re pra­xis­re­le­van­te Aus­wir­kun­gen auf den Ein­satz von Coo­kies und ähn­li­chen Tech­no­lo­gien. Mit dem TTDSG hat der Bun­des­ge­setz­ge­ber nach über einem Jahr­zehnt Ver­zö­ge­rung nun­mehr die Vor­ga­ben der euro­päi­schen e‑Pri­va­cy-Richt­li­nie in natio­na­les Recht umgesetzt.

Das TTDSG wur­de nah am Wort­laut der euro­päi­schen Vor­ga­ben for­mu­liert und for­dert grund­sätz­lich eine Ein­wil­li­gung der Nutzer:innen, wenn Infor­ma­tio­nen auf deren End­ein­rich­tun­gen gespei­chert wer­den oder auf die­se zuge­grif­fen wird. Aus­nah­men von die­sem Ein­wil­li­gungs­er­for­der­nis sind eng begrenzt auf Fäl­le, in denen das Spei­chern und Aus­le­sen der Infor­ma­tio­nen unbe­dingt erfor­der­lich ist, damit ein aus­drück­lich von Nutzer:innen gewünsch­ter Tele­me­di­en­dienst zur Ver­fü­gung gestellt wer­den kann. In der Ori­en­tie­rungs­hil­fe fin­den sich maß­geb­li­che Kri­te­ri­en, wie der ent­spre­chen­de Nut­zer­wunsch fest­ge­stellt und sodann rea­li­siert wer­den kann.

Bei der Prü­fung, ob aus­nahms­wei­se eine Ein­wil­li­gung ent­behr­lich ist, ist zu beach­ten, dass die Vor­aus­set­zun­gen sich wesent­lich vom Kri­te­ri­um des berech­tig­ten Inter­es­ses in der Daten­schutz-Grund­ver­ord­nung (DS-GVO) unter­schei­den. Bis zum 30. Novem­ber 2021 wur­de das berech­tig­te Inter­es­se von den Auf­sichts­be­hör­den unter engen Vor­aus­set­zun­gen als mög­li­che Rechts­grund­la­ge ange­se­hen. Eine bis­he­ri­ge Inter­es­sen­ab­wä­gung nach der DS-GVO erfüllt jedoch nicht auto­ma­tisch die engen Vor­aus­set­zun­gen des TTDSG. Zur Umset­zung der neu­en Rechts­la­ge ist es daher bei­spiels­wei­se nicht aus­rei­chend, wenn ledig­lich die Bezeich­nun­gen der Rechts­grund­la­gen in einer Daten­schutz­er­klä­rung aus­ge­tauscht werden.

Seit dem 1. Dezem­ber 2021 fin­den für das Spei­chern und Aus­le­sen von Infor­ma­tio­nen auf bzw. aus End­ge­rä­ten die stren­ge­ren Vor­schrif­ten des TTDSG Anwen­dung. Für die Wei­ter­ver­ar­bei­tung der so erho­be­nen per­so­nen­be­zo­ge­nen Daten gel­ten wei­ter­hin die Vor­schrif­ten der DS-GVO. Auch hier­zu fin­den sich eini­ge Hin­wei­se in der neu­en Orientierungshilfe.

Betreiber:innen von Web­sei­ten, Apps und ande­ren Tele­me­di­en soll­ten die Ver­wen­dung von Coo­kies und ande­ren Tech­no­lo­gien drin­gend über­prü­fen. Ins­be­son­de­re sind die genaue Aus­ge­stal­tung der Tech­no­lo­gien und deren Not­wen­dig­keit einer Revi­si­on zu unter­zie­hen. Zeit­punkt, Art und Dau­er der Spei­che­rung sowie die nach­ge­la­ger­te Daten­ver­ar­bei­tung müs­sen den Anfor­de­run­gen des TTDSG bzw. der DS-GVO ent­spre­chen. Dabei soll die nun vor­lie­gen­de Ori­en­tie­rungs­hil­fe eine Hil­fe­stel­lung geben.

Das Doku­ment ersetzt in wei­ten Tei­len die bis­he­ri­ge Fas­sung aus dem Jahr 2019 und wur­de auf der Home­page der DSK ver­öf­fent­licht. Es ist geplant, zeit­nah auch eine eng­li­sche Fas­sung der Ori­en­tie­rungs­hil­fe zur Ver­fü­gung zu stellen.

Des Wei­te­ren wird ein öffent­li­ches Kon­sul­ta­ti­ons­ver­fah­ren zur neu­en Fas­sung der Ori­en­tie­rungs­hil­fe durch­ge­führt wer­den. Details hin­sicht­lich der zeit­li­chen Pla­nung und des Ablaufs wer­den im Janu­ar 2022 bekannt gegeben.

Wei­te­re Infor­ma­tio­nen zur DSK: www​.daten​schutz​kon​fe​renz​-online​.de

Daten­schutz ist Chef­sa­che – Infor­ma­tio­nen für klei­ne und mitt­le­re Unter­neh­men veröffentlicht

Pres­se­mit­tei­lung des Lan­des­be­auf­trag­ten für den Daten­schutz Sach­sen-Anhalt vom 15.12.2021 Die Wirt­schaft von Sach­sen-Anhalt ist geprägt von klei­nen und mitt­le­ren Unter­neh­men (KMU). Hand­wer­ker, Kauf­leu­te und Frei­be­ruf­ler ver­schie­de­ner Bran­chen erhe­ben, spei­chern und nut­zen in oft viel­fäl­ti­ger Wei­se per­so­nen­be­zo­ge­ne Daten von Kun­den, Beschäf­tig­ten oder Lie­fe­ran­ten – und müs­sen den Daten­schutz beach­ten. Der Lan­des­be­auf­trag­te erhält daher seit lan­ger Zeit zahl­rei­che Anfra­gen die­ser Unter­neh­men: Wel­che Kun­den- oder Beschäf­tig­ten­da­ten darf ein Unter­neh­men erhe­ben? Wozu darf es die­se Daten nut­zen? Wie lan­ge dür­fen die Daten gespei­chert wer­den? Was ist zu tun, wenn Kun­den ihre Betrof­fe­nen­rech­te wahr­neh­men oder durch einen Cyber­an­griff Beschäf­tig­ten­da­ten ver­schlüs­selt wur­den? Ant­wor­ten auf die­se und vie­le wei­te­re typi­sche Fra­gen gibt der Lan­des­be­auf­trag­te in sei­nem jetzt ver­öf­fent­lich­ten Leit­fa­den „Daten­schutz ist Chef­sa­che“. Albert Cohaus, der die Auf­ga­ben und Befug­nis­se des Lan­des­be­auf­trag­ten wahr­nimmt, erklärt: „Die vie­len daten­schutz­recht­li­chen Anfra­gen der KMU ver­deut­li­chen einen gro­ßen Infor­ma­ti­ons­be­darf hin­sicht­lich prak­ti­ka­bler daten­schutz­ge­rech­ter Lösun­gen. In dem Leit­fa­den ‚Daten­schutz ist Chef­sa­che‘ wer­den grund­le­gen­de Infor­ma­tio­nen zusam­men­ge­fasst. Zudem ent­hält er Links zu zahl­rei­chen Mustern, Arbeits­hil­fen und Ver­tie­fungs­hin­wei­sen, die alle auf mei­ner Home­page bereit­ge­stellt wer­den.“ Der Leit­fa­den ist auf der Home­page des Lan­des­be­auf­trag­ten unter https://​lsaurl​.de/​C​h​e​f​s​a​c​h​eDS zu fin­den. Eine Druck­ver­si­on soll im kom­men­den Jahr ver­öf­fent­licht wer­den. Die in der Bro­schü­re ent­hal­te­nen Links sind in dem eben­falls auf der Home­page des Lan­des­be­auf­trag­ten bereit­ge­stell­ten „Info­pa­ket KMU“ auf­ruf­bar unter https://​lsaurl​.de/​I​n​f​o​p​a​k​e​t​KMU. Cohaus: „Mit dem Leit­fa­den und dem Info­pa­ket geben wir den KMU eine über­sicht­li­che Arbeits­hil­fe zur Bewäl­ti­gung daten­schutz­rech­li­cher Anfor­de­run­gen.“ Die Pres­se­mit­tei­lun­gen des Lan­des­be­auf­trag­ten für den Daten­schutz Sach­sen-Anhalt kön­nen hier abge­ru­fen werden. 

BayL­DA: Check­li­ste zu daten­schutz­recht­li­chem Hand­lungs­be­darf bei der Java-Sicher­heits­lücke „Log4Shell“

Pres­se­mit­tei­lung des Baye­ri­schen Lan­des­amts für Daten­schutz­auf­sicht vom 14.12.2021

Die Java-Pro­to­kol­lie­rungs­bi­blio­thek „Log4j“ ist weit ver­brei­tet. Sie ist Bestand­teil vie­ler kom­mer­zi­el­ler Pro­duk­te genau­so wie von Open-Source-Soft­ware, aber auch selbst ent­wickel­ter Java-Anwen­dun­gen. Durch die kürz­lich auf­ge­deck­te Schwach­stel­le „Log4Shell“ (CVE-2021 – 44228) kön­nen Angrei­fer über das Inter­net eige­ne Pro­gramm­codes aus­füh­ren und damit einen Brücken­kopf für wei­te­re Cyber­at­tacken instal­lie­ren. Dadurch droht auch län­ger­fri­stig die Kom­pro­mit­tie­rung vie­ler Dien­ste und viel­fach sogar Ein­schrän­kun­gen des Regel­be­triebs wich­ti­ger Systeme.

Micha­el Will, Prä­si­dent des BayL­DA, bewer­tet die Lage aus Daten­schutz­sicht als alar­mie­rend: „Das Bedro­hungs­po­ten­ti­al der Schwach­stel­le Log4Shell kann kaum ernst genug genom­men wer­den. Ver­ant­wort­li­che müs­sen nun umge­hend aktiv wer­den, um die eige­nen Syste­me zu prü­fen und die Schwach­stel­le zu besei­ti­gen. Bereits in der jün­ge­ren Ver­gan­gen­heit haben Cyber­an­grif­fe über ande­re Sicher­heits­lücken zu enor­men Schä­den geführt. Log4Shell hat das Poten­ti­al, die­se Risi­ken zu über­tref­fen und bran­chen­über­grei­fend zahl­rei­che Betrie­be in ihrem Arbeits­all­tag mas­siv zu stö­ren. Wir beob­ach­ten die Ent­wick­lung daher inten­siv und mit größ­ter Sor­ge. Unser erstes Augen­merk gilt wirk­sa­men Abhil­fe­maß­nah­men, für die wir eine Check­li­ste bereit­stel­len. Unse­re Erfah­run­gen mit der Nach­läs­sig­keit zahl­rei­cher Ver­ant­wort­li­cher trotz schwer­wie­gen­der Cyber­ge­fah­ren – zuletzt etwa der Schwach­stel­le bei Exchan­ge-Ser­vern im Früh­jahr die­sen Jah­res – zei­gen aber auch, dass Nach­kon­trol­len zur Gewähr­lei­stung des Daten­schut­zes uner­läss­lich sind. Daher prü­fen wir bereits, wie baye­ri­sche Ver­ant­wort­li­che einer auto­ma­ti­sier­ten Daten­schutz­kon­trol­le unter­zo­gen wer­den kön­nen, die Ver­säum­nis­se bei der Java-Sicher­heits­lücke auf­decken wird. Ver­stö­ße gegen die Sicher­heits­an­for­de­run­gen der Daten­schutz-Grund­ver­ord­nung kön­nen von uns mit emp­find­li­chen Geld­bu­ßen geahn­det werden.“

Wel­ches Aus­maß die Java-Sicher­heits­lücke Log4Shell für baye­ri­sche Unter­neh­men, Ver­ei­ne und Ver­bän­de, Ärz­te, Rechts­an­wäl­te etc. haben wird, ist trotz all­sei­ti­ger Auf­klä­rungs­be­mü­hun­gen längst noch nicht abseh­bar. Jedoch ist bereits zum jet­zi­gen Zeit­punkt bekannt, dass flä­chen­decken­de Scans nach ver­wund­ba­ren Syste­men statt­fin­den und auch schon gezielt Angrif­fe durch­ge­führt wer­den. Es ist somit nur noch eine Fra­ge der Zeit, wann Ver­ant­wort­li­che, die von der Lücke betrof­fen sind, einen Scha­den fest­stel­len. Nicht nur wirt­schaft­lich, son­dern auch daten­schutz­recht­lich ist ein sol­ches Sze­na­rio mit schwer­wie­gen­den Kon­se­quen­zen ver­bun­den. Letzt­end­lich dro­hen Ver­ant­wort­li­chen ins­be­son­de­re ein Abfluss per­so­nen­be­zo­ge­ner Daten, eine Nicht-Ver­füg­bar­keit wich­ti­ger Syste­me und Dien­ste oder eine Ein­rich­tung von Back­doors für spä­te­re Cyber­at­tacken. Selbst Angrif­fe mit Ran­som­wa­re zur Erpres­sung der betrof­fe­nen Betrie­be sind wahr­schein­lich. Ver­brau­che­rin­nen und Ver­brau­cher sind im Nor­mal­fall zwar nicht direkt von der Schwach­stel­le betrof­fen, könn­ten aber Aus­wir­kun­gen spü­ren, etwa wenn Dien­ste wie Apps oder Web­ser­vices nicht mehr erreich­bar sind oder eige­ne per­sön­li­che Daten durch Angrif­fe gestoh­len werden.

Baye­ri­sche Ver­ant­wort­li­che müs­sen auf­grund der erhöh­ten Gefähr­dungs­la­ge zur Ein­hal­tung daten­schutz­recht­li­cher Ver­pflich­tun­gen unver­züg­lich prü­fen, ob deren IT-Syste­me und Anwen­dun­gen von der Java-Sicher­heits­lücke Log4Shell betrof­fen sind. Hier­zu steht unter www​.lda​.bay​ern​.de/​l​o​g​4​s​h​ell eine Check­li­ste zur Ver­fü­gung. Ist bereits eine Sicher­heits­ver­let­zung ein­ge­tre­ten, z. B. weil die Sicher­heits­lücke aktiv aus­ge­nutzt wur­de und IT-Syste­me mit per­so­nen­be­zo­ge­nen Daten betrof­fen sind, besteht nach Art. 33 DS-GVO für Ver­ant­wort­li­che regel­mä­ßig eine Mel­de­ver­pflich­tung bei der zustän­di­gen Datenschutzaufsichtsbehörde.

Coo­kie­bot: Unzu­läs­sig auf­grund Daten­ver­ar­bei­tung in den USA

Das Ver­wal­tungs­ge­richt (VG) Wies­ba­den erklärt in sei­nem Urteil die Nut­zung des Ein­wil­li­gungs­tools Coo­kie­bot für rechts­wid­rig und wirft in sei­ner Ent­schei­dung inter­es­san­te Rechts­fra­gen auf. Lesen Sie in die­sem Bei­trag mehr zum Eilverfahren.

Was ist passiert?

Im Eil­ver­fah­ren vor dem VG Wies­ba­den (Beschl. v. 1.12.2021 – 6 L 738/21.WI) monier­te der Antrag­stel­ler, ein regel­mä­ßi­ger Nut­zer des Online­ka­ta­logs der Hoch­schul­bi­blio­thek auf der Web­site der Antrags­geg­ne­rin, dass der Ein­wil­li­gungs­ma­na­ger Coo­kie­bot des däni­schen Anbie­ters Cybot, per­so­nen­be­zo­ge­ne Daten wie sei­ne IP-Adres­se auf einen Ser­ver des in den USA ansäs­si­gen Cloud-Unter­neh­mens Aka­mai Tech­no­lo­gies Inc. („Aka­mai“) rechts­wid­rig übermittle.
Die Hoch­schu­le hat­te kei­nen Auf­trags­ver­ar­bei­tungs­ver­trag mit Cybot geschlos­sen, da Cybot der Auf­fas­sung war, dass sie kein Auf­trags­ver­ar­bei­ter sind, da eine Ver­ar­bei­tung per­so­nen­be­zo­ge­ner Daten nicht stattfinde.

Daten­über­mitt­lung in ein sog. Drittland

Nach dem „Schrems-II-Urteil“ des Euro­päi­schen Gerichts­hofs (EuGH) vom 16.07.2020 steht die Daten­über­mitt­lung in die USA auf wack­li­gen Bei­nen. Das Urteil kipp­te das sog. „Pri­va­cy Shield“ auf dem die Daten­über­mitt­lung in die USA mit zer­ti­fi­zier­ten Unter­neh­men gestützt wer­den konn­te. Die USA sind damit seit­dem ein sog. „unsi­che­res Dritt­land“, da kein Ange­mes­sen­heits­be­schluss nach Art. 45 DSGVO für die Über­tra­gung von per­so­nen­be­zo­ge­nen Daten besteht.
Neben der Rechts­grund­la­ge für die grund­sätz­li­che Ver­ar­bei­tung der Daten müs­sen zusätz­lich, für die Über­mitt­lung in ein Dritt­land, die Anfor­de­run­gen der Art. 45 ff. DSGVO erfüllt wer­den. In dem Urteil des EuGHs wur­de ins­be­son­de­re ange­führt, dass eine Daten­über­mitt­lung auf sog. Garan­tien nach Art. 46 DSGVO, wie Stan­dard­ver­trags­klau­seln, gestützt wer­den kön­nen. Es muss dann jedoch geprüft wer­den, ob ein gleich­wer­ti­ges Daten­schutz­ni­veau besteht und ob ggf. noch wei­te­re Maß­nah­men zu tref­fen sind.
Der Euro­päi­sche Daten­schutz­aus­schuss („EDSA“) hat hier­zu ein Papier her­aus­ge­ge­ben. Im Papier wer­den typi­sche Sze­na­ri­en („Use Cases“) und Hin­wei­se gege­ben, wie sol­che Maß­nah­men aus­se­hen kön­nen. Hier kön­nen Sie das Papier der EDSA aufrufen.

Ent­schei­dung des VG Wiesbaden

Die Ent­schei­dung hat­te schon nach der Pres­se­mit­tei­lung gro­ße Wel­len geschla­gen. Die­se wur­den auch nicht durch die kurz danach ver­öf­fent­lich­ten Ent­schei­dungs­grün­de geglät­tet. Soll­te die Ent­schei­dung in der Pra­xis Fuß fas­sen, so hät­te dies für vie­le Dien­ste (wie z.B. Fonts, Cap­t­chas, CDNs, Coo­kie-Ban­nern und vie­len ande­ren) weit­rei­chen­de Fol­gen. Doch was hat das VG Wies­ba­den eigent­lich entschieden?
Das Ver­wal­tungs­ge­richt urteil­te, dass Coo­kie­bot unge­kürz­te IP-Adres­sen und damit per­so­nen­be­zo­ge­ne Daten ver­ar­bei­te­tet hat. Cybot nutzt das Con­tent Deli­very Net­work („CDN“, ist kurz­ge­sagt ein Ver­bund von Ser­vern, der es ermög­licht auf Daten schnel­ler zuzu­grei­fen und ver­hin­dert so eine Über­la­stung des eigent­li­chen Ser­vers) von Aka­mai des­sen Ser­ver in den USA liegt. Es kommt hier­bei zu einer Dritt­land­über­mitt­lung gemäß Art. 44 ff. DSGVO. Das Gericht hat sich in den Ent­schei­dungs­grün­den selbst nicht mit Stan­dard­ver­trags­klau­seln befasst, son­dern stützt sei­ne Ent­schei­dung dar­auf, dass kei­ne Rechts­hil­fe­ab­kom­men nach Art. 48 DSGVO vor­lie­ge, womit nur noch eine Ein­wil­li­gung nach Art. 49 Abs. 1 S. 1 lit. a DSGVO in Fra­ge käme. Eine Ein­wil­li­gung läge hier nicht vor.
Hin­sicht­lich der Daten­ver­ar­bei­tung sei die Hoch­schu­le daten­schutz­recht­lich Ver­ant­wort­li­che gem. Art. 4 Nr.7 DSGVO, da sie sich dafür oder dage­gen ent­schei­den kann, dass der Dienst auf ihrer Web­sei­te ein­ge­setzt wird und damit eine Daten­ver­ar­bei­tung mög­li­cher­wei­se auch zu den von Cybot bzw. Aka­mai fest­ge­leg­ten Zwecken stattfindet.

Ein­wil­li­gungs­tools

Die Ver­wen­dung von Coo­kie-Ban­nern bzw. Ein­wil­li­gungs­tools kann grds. als tech­nisch erfor­der­lich ange­se­hen wer­den, da sie dafür sor­gen, dass erfor­der­li­che Ein­wil­li­gun­gen für Coo­kies und ande­re Tools, wie z.B. Tracking oder You­Tube, ein­ge­holt wer­den. Die Rechts­grund­la­ge für die Nut­zung des Coo­kie-Ban­ners ist damit Art. 6 Abs. 1 S. 1 lit. f DSGVO sowie § 25 Abs. 2 Nr. 2 TTDSG.
Eine Ein­wil­li­gung nach Art. 49 Abs.1 S. 1 lit. a DSGVO für eine Dritt­land­über­mitt­lung eines tech­nisch erfor­der­li­chen Dien­stes ist in den mei­sten Fäl­len nicht oder nur sehr umständ­lich umsetz­bar. Hier wäre es im Fal­le eines Coo­kie-Ban­ners erfor­der­lich vor dem Zugriff eine Ein­wil­li­gung ein­zu­ho­len, da eine Ein­wil­li­gung zum Zeit­punkt der Ver­ar­bei­tung bereits vor­lie­gen muss. Es wäre also ein Coo­kie-Ban­ner für den Coo­kie-Ban­ner nötig.
Die­ser Fall kann sinn­voll nur mit Stan­dard­ver­trags­klau­seln und einem TIA (Trans­fer-Impact-Assess­ment) abge­deckt wer­den. Eine Ein­wil­li­gung als Rechts­grund­la­ge für eine Dritt­land­über­mitt­lung ist schon tech­nisch wenig sinn­voll. Wei­ter wird teil­wei­se von Auf­sichts­be­hör­den ver­tre­ten, dass sich Dritt­land­über­mitt­lun­gen nur im Aus­nah­me­fall auf Art. 49 DSGVO stüt­zen las­sen und eine regel­mä­ßi­ge Daten­über­tra­gung, wie bei einem Coo­kie-Ban­ner, gera­de nicht zuläs­sig ist.

Cybot und die Auftragsverarbeitung

In der Ver­gan­gen­heit stand Cybot schon öfter in der Dis­kus­si­on mit ihrem „Kunst­griff“ kein Auf­trags­ver­ar­bei­ter zu sein. Die voll­stän­di­ge IP-Adres­se wird unfrag­lich durch Cybot zwangs­läu­fig ver­ar­bei­tet und bedarf damit, als per­so­nen­be­zo­ge­nes Datum, einer Rechts­grund­la­ge. Im Rah­men einer Auf­trags­ver­ar­bei­tung ist dies der Auf­trags­ver­ar­bei­tungs­ver­trag (AVV) für den Auf­trags­ver­ar­bei­ter, nur der Ver­ant­wort­li­che (hier der Web­sei­ten­be­trei­ber) selbst braucht eine Rechts­grund­la­ge. Liegt kein AVV vor ist die Ver­ar­bei­tung grds. rechts­wid­rig und das selbst, wenn man annimmt, dass Cybot die per­so­nen­be­zo­ge­nen Daten im Anschluss kom­plett anony­mi­siert werden.

Aus­sicht für die Zukunft

Es ist unwahr­schein­lich, dass sich die Rechts­mei­nung des VG Wies­ba­den durch­set­zen wird. Die Antrags­geg­ne­rin hat 2 Wochen nach der Ver­öf­fent­li­chung der Ent­schei­dung Zeit, um Beschwer­de beim Ver­wal­tungs­ge­richts­hof Kas­sel ein­zu­le­gen. Die end­gül­ti­ge Ent­schei­dung über den gel­tend gemach­ten Anspruch wird erst im Haupt­sa­che­ver­fah­ren getroffen.
Die Mei­nung des Gerichts, Coo­kie-Ban­ner nur auf eine aus­drück­li­che Ein­wil­li­gung nach Art. 49 Abs. 1 S. 1 lit. a DSGVO zu stüt­zen erscheint abwe­gig. Dies ist tech­nisch nicht umsetz­bar und recht­lich frag­lich, wie oben dar­ge­stellt. Wei­te­re Ent­schei­dun­gen in die­ser Rich­tung wer­den vor­aus­sicht­lich fol­gen. Es ist ins­be­son­de­re wahr­schein­lich, dass zukünf­tig noch genau­er geprüft wird wel­che zusätz­li­chen Maß­nah­men getrof­fen wur­den und ob die­se für eine Dritt­land­über­mitt­lung aus­rei­chend sind. Es bleibt abzu­war­ten, wel­che Ent­wick­lung die neu­en Stan­dard­ver­trags­klau­seln in Ver­bin­dung mit einem TIA brin­gen und wel­che kon­kre­ten zusätz­li­chen Maß­nah­men für eine Dritt­land­über­mitt­lung als aus­rei­chend ange­se­hen werden.

BSI: Kri­ti­sche Schwach­stel­le in log4j ver­öf­fent­licht (CVE-2021 – 44228)

Sach­ver­halt

Log4j ist eine belieb­te Pro­to­kol­lie­rungs­bi­blio­thek für Java-Anwen­dun­gen. Sie dient der per­for­man­ten Aggre­ga­ti­on von Pro­to­koll­da­ten einer Anwendung.

Das Blog eines Dienst­lei­sters für IT-Sicher­heit [LUN2021] berich­tet über die Schwach­stel­le CVE-2021 – 44228 [MIT2021] in log4j in den Ver­sio­nen 2.0 bis 2.14.1, die es Angrei­fern gege­be­nen­falls ermög­licht, auf dem Ziel­sy­stem eige­nen Pro­gramm­code aus­zu­füh­ren und so den Ser­ver zu kom­pro­mit­tie­ren. Die­se Gefahr besteht dann, wenn log4j ver­wen­det wird, um eine vom Angrei­fer kon­trol­lier­te Zei­chen­ket­te wie bei­spiels­wei­se den HTTP User Agent zu protokollieren.

Ein Pro­of-of-Con­cept (PoC) der Schwach­stel­le wur­de auf Git­hub ver­öf­fent­licht [GIT2021a] und auf Twit­ter geteilt [TWI2021]. Neben dem PoC exi­stie­ren auch Bei­spie­le für Skrip­te, die Syste­me stich­pro­ben­ar­tig auf Ver­wund­bar­keit hin unter­su­chen [GIT2021b]. Skrip­te sol­cher Art kön­nen zwar Admi­ni­stra­to­ren kei­ne Sicher­heit über die Ver­wund­bar­keit geben, aber erlau­ben Angrei­fern kurz­fri­stig rudi­men­tä­re Scans nach ver­wund­ba­ren Systemen.

Die­se kri­ti­sche Schwach­stel­le hat dem­nach mög­li­cher­wei­se Aus­wir­kun­gen auf alle aus dem Inter­net erreich­ba­ren Java-Anwen­dun­gen, die mit Hil­fe von log4j Tei­le der Nut­zer­an­fra­gen protokollieren.

Update 1:
Der Schwach­stel­le wur­de nach Ver­öf­fent­li­chung des Blog-Posts ein CVSS-Wert von 10.0 zuge­wie­sen.
Erste öffent­li­che Quel­len wei­sen auf breit­flä­chi­ges Scan­nen nach ver­wund­ba­ren Syste­men hin. Das BSI kann der­ar­ti­ge
Scan-Akti­vi­tä­ten bestätigen.

Update 2:
Im Gegen­satz zur ursprüng­li­chen Ein­schät­zung kann die kri­ti­sche Schwach­stel­le ggf. auch auf inter­nen Syste­men
aus­ge­nutzt wer­den, sofern die­se exter­ne Daten ent­ge­gen­neh­men oder ver­ar­bei­ten.
Eini­ge Pro­duk­t­her­stel­ler haben bereits öffent­lich bzgl. einer mög­li­chen (Nicht-)Betroffenheit ihrer Pro­duk­te
hin­ge­wie­sen und teil­wei­se bereits Updates ver­öf­fent­licht ([APA2021c], [BRO2021], [CIS2021], [FSE2021], [MCA2021],
[SOP2021], [TRE2021], [VMW2021a], [VMW2021b], [UNI2021]). Zu den betrof­fe­nen Her­stel­lern gehö­ren z. B.:
• VMWare
• Apa­che
• Uni­Fi
Die­se Liste ist nicht abschlie­ßend und erhebt kei­nen Anspruch auf Voll­stän­dig­keit. Zahl­rei­che wei­te­re Her­stel­ler prü­fen
aktu­ell noch eine Betroffenheit.

Update 3:
Auf Git­hub wur­de unter [GIT2021e] eine Liste mit Sicher­heits­war­nun­gen für Pro­duk­te von über 140 Her­stel­lern
ver­öf­fent­licht. Eini­ge der Links ver­wei­sen direkt auf Her­stel­ler­sei­ten, die neben Infor­ma­tio­nen zur Betrof­fen­heit auch
Updates für Ihre Pro­duk­te bereit­stel­len. Die Inhal­te wur­den durch das BSI stich­pro­ben­ar­tig veri­fi­ziert und sol­len als
erste Ori­en­tie­rungs­hil­fe die­nen.
Das NCSC NL (Natio­naal Cyber Secu­ri­ty Cen­trum Nether­lands) plant im Lau­fe des Nach­mit­ta­ges die Ver­öf­fent­li­chung
eines Git­hub-Repo­si­to­ries unter [NCSC2021] mit gesi­cher­ten Infor­ma­tio­nen zu betrof­fe­nen Her­stel­lern. Zum
Redak­ti­ons­schluss war das Repo­si­to­ry noch nicht veröffentlicht.

Bewer­tung

Log4j wird in vie­len Java-Anwen­dun­gen ein­ge­setzt. Der Schutz gegen eine akti­ve, brei­te Aus­nut­zung ist durch die
Ver­füg­bar­keit eines PoC sehr gering. Das Patch­ma­nage­ment von Java-Anwen­dun­gen ist nicht tri­vi­al, sodass bis zu einer
Update-Mög­lich­keit die kurz­fri­sti­gen Miti­ga­tio­nen emp­foh­len wer­den.
Wenn­gleich das Nach­la­den von Schad­code über den im PoC auf­ge­zeig­ten Weg bei Grund­schutz-kon­form
ein­ge­rich­te­ten Syste­men fehl­schla­gen soll­te, sind auch ande­re Wege denk­bar, ggf. auch auto­ma­ti­siert und ohne
Nach­la­den Schad­code zur Aus­füh­rung zu brin­gen. Hier­bei ist die Kom­ple­xi­tät im Ver­gleich zum PoC deut­lich erhöht.
Update 1:
Auf­grund der wei­ten Ver­brei­tung der Biblio­thek ist es nur schwer abseh­bar, wel­che Pro­duk­te alle betrof­fen sind.
Das BSI sieht aktu­ell eine Erhö­hung der IT-Bedro­hungs­la­ge für Geschäfts­pro­zes­se und Anwen­dun­gen. Durch das aktu­ell
breit­flä­chi­ge Scan­nen ist eine mög­li­che anschlie­ßen­de Infek­ti­on von anfäl­li­gen Syste­men und Anwen­dun­gen, auch auf
Grund aktu­ell oft­mals noch feh­len­den Patches, nicht aus­zu­schlie­ßen.
Update 2:
Das Aus­maß der Bedro­hungs­la­ge ist aktu­ell nicht abschlie­ßend fest­stell­bar. Die Reak­ti­ons- und Detek­ti­ons­fä­hig­keit des
IT-Betrie­bes ist kurz­fri­stig geeig­net zu erhö­hen, um ange­mes­sen die Syste­me über­wa­chen zu kön­nen bzw. zu reagie­ren.
Aus meh­re­ren CERT-Quel­len erreich­ten das BSI Benach­rich­ti­gun­gen über welt­wei­te Mas­sen­scans und ver­such­te
Kom­pro­mit­tie­run­gen. Es gibt bereits erste Mel­dun­gen über erfolg­rei­che Kom­pro­mit­tie­run­gen (bis­lang u.a. mit
Kryp­to­mi­ner).
Es sind zudem Aus­nut­zun­gen der Schwach­stel­le zu beob­ach­ten, die kein expli­zi­tes Nach­la­den eines Schad­codes
benö­ti­gen und einen mali­ziö­sen Code direkt in der Abfra­ge ent­hal­ten. Dies gefähr­det auch Grund­schutz-kon­for­me
Syste­me, die i.d.R. kei­ne Ver­bin­dung ins Inter­net auf­bau­en können.

ktu­ell ist noch nicht bekannt in wel­chen Pro­duk­ten die­se Biblio­thek ein­ge­setzt wird, was dazu führt, dass zum jet­zi­gen
Zeit­punkt noch nicht abge­schätzt wer­den kann, wel­che Pro­duk­te von der Schwach­stel­le betrof­fen sind.
Auch inter­ne Syste­me, die Infor­ma­tio­nen oder Daten von ande­ren Syste­men ver­ar­bei­ten, kön­nen ggf. kom­pro­mit­tiert
wer­den und sind daher umge­hen zu patchen.
Auf­grund der neu­en Sach­ver­hal­te hat das BSI ent­schie­den die Warn­mel­dung von der Warn­stu­fe Oran­ge auf Rot
hoch­zu­stu­fen.
Update 3:
Neben erfolg­rei­chen Kom­pro­mit­tie­run­gen mit Kryp­to­mi­nern gibt es unter [3602021] erste Hin­wei­se dar­auf, dass die
Schwach­stel­le auch von Bot­net­zen aus­ge­nutzt wird. Die Wahr­schein­lich­keit ist groß, dass die mit die­ser Schwach­stel­le
in Ver­bin­dung ste­hen­den Angrei­fer­ak­ti­vi­tä­ten in den näch­sten Tagen deut­lich zuneh­men werden.

Maß­nah­men

Ser­ver soll­ten gene­rell nur sol­che Ver­bin­dun­gen (ins­be­son­de­re in das Inter­net) auf­bau­en dür­fen, die für den
Ein­satz­zweck zwin­gend not­wen­dig sind. Ande­re Zugrif­fe soll­ten durch ent­spre­chen­de Kon­troll­in­stan­zen wie Paket­fil­ter
und App­li­ca­ti­on Lay­er Gate­ways unter­bun­den wer­den. [BSI2021b]
Es soll­te ent­spre­chend dem Grund­schutz­bau­stein [BSI2021a] ein Update auf die aktu­el­le Ver­si­on 2.15.0 [APA2021] (git-
tag: 2.15.0‑rc2 [GIT2021c]) von log4j in allen Anwen­dun­gen sicher­ge­stellt wer­den. Da Updates von Abhän­gig­kei­ten in
Java-Anwen­dun­gen häu­fig nicht zeit­nah erfol­gen kön­nen, soll­te bis dahin die fol­gen­de Miti­ga­ti­ons­maß­nah­me ergrif­fen
wer­den:
Die Opti­on “log4j2.formatMsgNoLookups” soll­te auf “true” gesetzt wer­den, indem die Java Vir­tu­al Machi­ne mit dem
Argu­ment

 – Dlog4j2.formatMsgNoLookups=True”
gestar­tet wird.
Update 2:
Alter­na­tiv kann auch die Umge­bungs­va­ria­ble LOG4J_​FORMAT_​MSG_​NO_​LOOKUPS auf true gesetzt wer­den. Die­se
bei­den Miti­ga­ti­ons­maß­nah­men funk­tio­nie­ren erst ab Log4J Ver­si­on 2.10.
Ach­tung: Die­se Maß­nah­me kann die Funk­ti­ons­wei­se der Appli­ka­ti­on beein­träch­ti­gen, wenn die Look­up-Funk­ti­on
tat­säch­lich ver­wen­det wird.
Update 2:
Die Log4J Ver­sio­nen 1.x sind von der aktu­el­len Schwach­stel­le nach aktu­el­ler Kennt­nis nicht betrof­fen [GIT2021d]. Die
Ver­si­on 1.x wird, auch wenn sie noch in diver­sen Pro­duk­ten ein­ge­setzt wird, nicht mehr vom Her­stel­ler unter­stützt. Sie
ist End-of-Life und durch ande­re Schwach­stel­len ver­wund­bar. Daher soll­ten auch noch ein­ge­setz­te Log4J Ver­sio­nen 1.x
eben­falls auf eine nicht-ver­wund­ba­re Ver­si­on 2.x aktua­li­siert wer­den.
Sofern das Log4j als eige­ne jar-Datei vor­liegt, kann die­se ggf. aus­ge­tauscht wer­den. Hier ist vor­ab die
Her­stel­ler­do­ku­men­ta­ti­on zu prü­fen, ob und unter wel­chen Umstän­den die­ses Ver­fah­ren das System absi­chert.
Als Alter­na­ti­ve, die auch in Ver­sio­nen ab 2.0‑beta9 und höher funk­tio­niert, emp­fiehlt der Her­stel­ler die Klas­se
Jndi­Look­up aus dem Klas­sen­pfad zu löschen [APA2021b]:
zip ‑q ‑d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Sofern die Her­stel­ler Updates zur Ver­fü­gung stel­len, soll­ten die­se umge­hend instal­liert wer­den.
In den jewei­lig zu ver­ant­wor­ten­den Berei­chen soll­te qua­li­fi­zier­tes IT-Per­so­nal ein­ge­setzt wer­den, um die kri­ti­schen, vor
allem von außen zu errei­chen­de Syste­me eng­ma­schig zu über­wa­chen.
Um poten­ti­ell betrof­fe­ne Syste­me leich­ter zu iden­ti­fi­zie­ren, kann zunächst über­prüft wer­den, wel­che Syste­me Java als
Instal­la­ti­ons­vor­aus­set­zung haben oder Java instal­lie­ren. Zu sol­chen Syste­men soll­ten die Mel­dun­gen des jewei­li­gen
Her­stel­lers prio­ri­tär geprüft wer­den. Sofern sei­tens des Her­stel­lers noch kein Secu­ri­ty Advi­so­ry ver­öf­fent­licht wur­de,
soll­te eine ent­spre­chen­de Anfra­ge gestellt werden.

Da eine Aus­nut­zung nicht zwin­gend ein Nach­la­den von Schad­code aus dem Inter­net benö­tigt, son­dern bereits mit
einer ein­zi­gen Anfra­ge mög­lich ist, muss für alle ver­wund­ba­ren Syste­me die Angriffs­flä­che redu­ziert wer­den. Kon­kre­te
Schrit­te hier­zu sind:
• Nicht zwin­gend benö­tig­te Syste­me abschal­ten.
• Netz­wer­ke seg­men­tie­ren, sodass ver­wund­ba­re Syste­me von nicht extern-ver­bun­de­nen/in­ter­nen Syste­men
iso­liert wer­den
Syste­me, die auf­grund der Kri­ti­ka­li­tät für unab­ding­ba­re Geschäfts­pro­zes­se nicht abge­schal­tet wer­den kön­nen:
• In Web-App­li­ca­ti­on-Fire­walls (WAF), Intru­si­on Pre­ven­ti­on Syste­men (IPS) oder Rever­se Pro­xies Ver­bin­dun­gen,
die Angriffs­mu­ster auf­wei­sen, direkt ohne Wei­ter­ga­be an die Fach­ap­pli­ka­ti­on abwei­sen oder nicht zwin­gend
benö­tig­te HTTP-Hea­der auf sta­ti­sche Wer­te set­zen.
• Blockie­ren aller nicht zwin­gend not­wen­di­gen, aus­ge­hen­den Ver­bin­dun­gen.
• Umfas­sen­des Log­ging und die Pro­to­kol­lie­rung aller ein­ge­hen­der und aus­ge­hen­der Ver­bin­dun­gen, um im
Nach­gang eine Kom­pro­mit­tie­rung leich­ter fest­stel­len zu kön­nen.
• Ano­ma­lie­de­tek­ti­on auf dem Host betrei­ben.
• Prü­fen, mit wel­chen Rech­ten der betrof­fe­ne Dienst betrie­ben wird und die­se auf das not­wen­di­ge Mini­mum
redu­zie­ren.
• Ver­bin­dun­gen zu ande­ren Syste­men soll­ten getrennt wer­den.
Für nach Bekannt­wer­den der Schwach­stel­le gepach­te Syste­me muss zusätz­lich unter­sucht wer­den, ob die­se bereits
kom­pro­mit­tiert wur­den. Dies betrifft auch Syste­me, die nicht direkt mit dem Inter­net ver­bun­den sind, da die­se über
ver­bun­de­ne Syste­me kom­pro­mit­tiert wor­den sein könn­ten.
Infor­mie­ren Sie sich auf den Web­sei­ten der von Ihnen ein­ge­setz­ten Her­stel­ler (u.a. den oben genann­ten) über Patches
und Work­arounds und spie­len sie die­se unver­züg­lich ein.
Update 3:
Unter [GIT2021e] und [NCSC2021] (mög­li­cher­wei­se erst am spä­ten Nach­mit­tag ver­füg­bar) wur­den Hin­wei­sen zu einer
mög­li­chen Betrof­fen­heit zahl­rei­cher Pro­duk­te ver­öf­fent­licht. Als erste Ori­en­tie­rungs­hil­fe ist es zu emp­feh­len, die­se
Listen mit eige­nen ein­ge­setz­ten Pro­duk­ten abzu­glei­chen. Das BSI hat die Inhal­te nicht voll­stän­dig veri­fi­ziert. Die Listen
wer­den mit hoher Wahr­schein­lich­keit fort­lau­fend aktua­li­siert, so dass eine mehr­ma­li­ge Über­prü­fung not­wen­dig ist.
Die­ser Abgleich kann die zwin­gend erfor­der­li­chen eige­nen Über­prü­fungs­maß­nah­men ergän­zen.
Da zum aktu­el­len Zeit­punkt kei­ne gesi­cher­te Aus­sa­ge dar­über getrof­fen wer­den kann, in wel­chen Pro­duk­ten die
Biblio­thek ein­ge­setzt wird, kann das unter [GIT2021h] ver­öf­fent­lich­te Tool zum Suchen von betrof­fe­nen log4j
Biblio­the­ken ver­wen­det wer­den. Das Tool durch­sucht dabei Hash­sum­men-basiert .jar und .war Archi­ve nach
ein­deu­ti­gen Java-Klas­sen. Da ledig­lich die offi­zi­ell kom­pi­lier­ten Releases erkannt wer­den, kann es ins­be­son­de­re bei
Linux-Syste­men vor­kom­men, dass betrof­fe­ne log4j Biblio­the­ken nicht erkannt wer­den.
Unter [GIT2021f] wur­de eine Auf­li­stung von Befeh­len ver­öf­fent­licht, mit denen man Log-Daten auf eine mög­li­che
Aus­nut­zung der Schwach­stel­le über­prü­fen kann. Im Fal­le von Tref­fern ist es drin­gend zu emp­feh­len wei­te­re
Maß­nah­men sofort ein­zu­lei­ten. Zu die­sen zäh­len z.B.: Netz­tren­nung, Suche nach den Schwach­stel­len, deren Schlie­ßung
(ggf. durch Neu­in­stal­la­ti­on) und dann die Feststellung/​Bereinigung einer mög­li­chen Kom­pro­mit­tie­rung mit Schad­code
unter Betrach­tung auch wei­te­rer benach­bar­ter und dahin­ter­lie­gen­der Syste­me (late­ral movement).

BayL­DA: Daten­schutz­prü­fung gegen Wel­le von Ran­som­wa­ren-Angrif­fen bei baye­ri­schen Unternehmen

Start­schuss für anlass­lo­se Prü­fun­gen der Datenschutzaufsichtsbehörde

Pres­se­mit­tei­lung des Baye­ri­schen Lan­des­amts für Daten­schutz­auf­sicht vom 01.12.2021

Baye­ri­sche Unter­neh­men – von der klei­nen Arzt­pra­xis bis zum Kon­zern – wer­den zuneh­mend von inter­na­tio­nal agie­ren­den Cyber­kri­mi­nel­len ange­grif­fen. Neben der Ver­schlüs­se­lung von Datei­en samt exor­bi­tan­ter Löse­geld­for­de­rung kommt es dabei viel­fach auch zum Dieb­stahl sen­si­bler Gesund­heits­da­ten, Kon­to­da­ten oder Bewer­bungs­un­ter­la­gen ver­bun­den mit der Dro­hung, bei einer Ver­wei­ge­rung der Zah­lung die­se im Inter­net zu ver­öf­fent­li­chen. Allei­ne inner­halb des letz­ten Jah­res wur­den dem Baye­ri­schen Lan­des­amt für Daten­schutz­auf­sicht von baye­ri­schen Unter­neh­men meh­re­re hun­dert Ran­som-Angrif­fe gemel­det, bei denen Löse­geld von 10 TSD bis zu 50 Mio. Euro gefor­dert wur­den. Prä­si­dent Micha­el Will: „Schon im eige­nen Inter­es­se müs­sen baye­ri­schen Unter­neh­men ihre Daten gegen Angrif­fe Cyber­kri­mi­nel­ler absi­chern. Die Ein­hal­tung des Daten­schutz­rechts schafft einen Sicher­heits­wall für die Daten der betrof­fe­nen Per­so­nen, der häu­fig schon mit ein­fa­chen Maß­nah­men errich­tet wer­den kann. Mit unse­rer Prüf­ak­ti­on grei­fen wir Basis­auf­ga­ben auf, die in jedem Unter­neh­men gewähr­lei­stet wer­den kön­nen und sollten.“

Die hohe Anzahl der gemel­de­ten Fäl­le, die nach einer Som­mer­pau­se ab Sep­tem­ber wie­der deut­lich ange­stie­gen sind, spie­gelt das Risi­ko für jedes Unter­neh­men wie­der, Opfer eines Cyber­an­griffs zu wer­den. Gera­de auch Unter­neh­men aus dem Mit­tel­stand sind über­pro­por­tio­nal betrof­fen und wider­le­gen damit das trü­ge­ri­sche Gefühl, nicht im Fokus der Angrei­fer zu sein.

Wer­den Daten und IT-System ver­schlüs­selt, dann ruht häu­fig der Betrieb. Selbst eine funk­tio­nie­ren­de Daten­si­che­rung bie­tet aber vor dem Trend, dass Angrei­fer per­so­nen­be­zo­ge­ne Daten ent­wen­den (Ran­som­wa­re 2.0), kei­nen Schutz und ver­la­gert den Scha­den auf die betrof­fe­ne Beleg­schaft und Kund­schaft. Gra­vie­rend kann es wer­den, wenn sen­si­ti­ve Infor­ma­tio­nen wie Inhal­te einer ärzt­li­chen Pati­en­ten­ak­te, Kon­to­ver­bin­dungs­da­ten oder Bewer­bungs­un­ter­la­gen im soge­nann­ten Darknet auf­tau­chen, um dort in Markt­plät­zen für ande­re Inter­net­ver­bre­cher zum Ver­kauf ange­bo­ten zu werden.

Auf­grund der sehr hohen Bedro­hungs­la­ge von Angrif­fen mit Ran­som­wa­re hat sich das BayL­DA ent­schie­den, die Auf­takt­prü­fung einer gan­zen Prü­frei­he die­sem The­ma zu wid­men. Ziel ist, mit fünf ziel­ge­rich­te­ten Prüf­fra­gen die wich­tig­sten Sicher­heits­be­rei­che abzu­fra­gen sowie wei­te­re Infor­ma­tio­nen für einen umfas­sen­den Schutz anzu­bie­ten. „IT-Sicher­heit zum Schutz vor Ran­som­wa­re gehört zu den Pflicht­auf­ga­ben für alle Unter­neh­men, die per­so­nen­be­zo­ge­ne Daten ver­ar­bei­ten. Unse­re Prü­fung zeigt gera­de für klei­ne und mit­tel­stän­di­ge Unter­neh­men ein­fa­che und wirk­sa­me Maß­nah­men auf, mit denen sie ihre Daten­schutz­an­for­de­run­gen wah­ren und sich im besten Fall zugleich erfolg­reich gegen die Angrif­fe Cyber­kri­mi­nel­ler ver­tei­di­gen.“, so Will.

Neu gegrün­de­te Stab­stel­le Prüfverfahren

Mit der Prü­fung „Ran­som­wa­re“ gibt die neu gegrün­de­te Stab­stel­le Prüf­ver­fah­ren des BayL­DA den Start­schuss für eine Rei­he anlass­lo­ser fokus­sier­ter Kon­trol­len. In kur­zen Abstän­den wer­den künf­tig stan­dar­di­sier­te schrift­li­che und auch auto­ma­ti­siert über das Inter­net aus­ge­führ­te Prü­fun­gen mit kla­rer Schwer­punkt­set­zung durch­ge­führt. Beglei­tend wer­den die Prüf­fra­gen sowie Infor­ma­tio­nen zu dem jewei­li­gen Prüf­kom­plex unter https://​www​.lda​.bay​ern​.de/​d​e​/​k​o​n​t​r​o​l​l​e​n​_​s​t​a​b​s​s​t​e​l​l​e​.​h​tml ver­öf­fent­licht. Künf­ti­ge The­men­be­rei­che wer­den zudem bereits vorangekündigt.

Ziel der regel­mä­ßi­gen fokus­sier­ten Prü­fun­gen ist einer­seits, die daten­schutz­recht­li­chen Kon­trol­len der nicht-öffent­li­chen Stel­len in Bay­ern aus­zu­wei­ten. Ande­rer­seits soll durch die beglei­ten­de Bereit­stel­lung von Infor­ma­tio­nen das Augen­merk auch der Daten­schutz­be­auf­trag­ten auf die jeweils geprüf­ten oder zur Prü­fung anste­hen­den The­ma­ti­ken gelenkt wer­den. „Wir möch­ten die betrieb­li­chen Daten­schutz­ex­per­ten als Mul­ti­pli­ka­to­ren gewin­nen, um gemein­sam den Schutz der baye­ri­schen Unter­neh­men zu erhö­hen. Unse­re fokus­sier­ten Prüf­kata­lo­ge bie­ten ihnen ein­fa­che Werk­zeu­ge für inter­ne Kon­trol­len und Schu­lun­gen.“, erläu­tert Prä­si­dent Micha­el Will.Down­load Für den Ernst­fall gewapp­net? – Daten­schutz­prü­fung gegen Wel­le von Ran­som­wa­ren-Angrif­fen bei baye­ri­schen Unter­neh­men als PDF

VirDSB: TTDSG tritt in Kraft: Kla­re Regeln für Coo­kies und ähn­li­che Technologien

Pres­se­mit­tei­lung der Ber­li­ner Beauf­trag­ten für Daten­schutz und Informationsfreiheit

Am heu­ti­gen 1. Dezem­ber 2021 tritt das Tele­kom­mu­ni­ka­ti­ons-Tele­me­di­en-Daten­schutz-Gesetz (TTDSG) in Kraft. Das Gesetz regelt unter ande­rem den Schutz der Ver­trau­lich­keit und Pri­vat­sphä­re bei der Nut­zung von inter­net­fä­hi­gen End­ge­rä­ten wie Web­sei­ten, Mes­sen­gern oder Smart-Home-Geräten.

Mit dem TTDSG ändert sich auch der recht­li­che Rah­men für den Ein­satz von Coo­kies und ver­gleich­ba­ren Tech­no­lo­gien“, erklärt Vol­ker Bro­zio, kom­mis­sa­ri­scher Dienst­stel­len­lei­ter der Ber­li­ner Beauf­trag­ten für Daten­schutz und Infor­ma­ti­ons­frei­heit. „Das Gesetz schafft Klar­heit und bestä­tigt die Auf­fas­sung der Daten­schutz­be­hör­de: Für den Ein­satz von Coo­kies und ähn­li­chen Tech­no­lo­gien braucht es im Regel­fall eine Ein­wil­li­gung der Nutzer:innen. Infol­ge­des­sen müs­sen Anbieter:innen von Tele­me­di­en über­prü­fen, ob Anpas­sungs­be­darf unter ande­rem auf ihren Web­sei­ten oder Apps besteht.“

Auf den mei­sten Web­sei­ten und Apps wer­den Tech­no­lo­gien wie Coo­kies ein­ge­setzt, um Infor­ma­tio­nen auf den Gerä­ten der Nut­zen­den abzu­le­gen und zu ver­wal­ten. Damit ein­her geht regel­mä­ßig die Ver­ar­bei­tung von per­so­nen­be­zo­ge­ner Daten, min­de­stens der IP-Adres­se der Nutzer:innen. Dies dient häu­fig nicht nur dazu, das Ver­hal­ten von Nutzer:innen zu ver­fol­gen, son­dern auch Per­sön­lich­keits­pro­fi­le über die gesam­te Inter­net­nut­zung zu erstel­len und anzureichern.

Die recht­li­chen Rah­men­be­din­gun­gen für das Set­zen und Aus­le­sen von Infor­ma­tio­nen aus End­ge­rä­ten sind in der euro­päi­schen ePri­va­cy-Richt­li­nie gere­gelt. Mit dem TTDSG hat der Bun­des­ge­setz­ge­ber nach über einem Jahr­zehnt Ver­zö­ge­rung nun­mehr die Vor­ga­ben der ePri­va­cy-Richt­li­nie in natio­na­les Recht umge­setzt. Die anschlie­ßen­de Ver­ar­bei­tung der so erho­be­nen per­so­nen­be­zo­ge­nen Daten rich­tet sich wie­der­um nach den Anfor­de­run­gen der Daten­schutz-Grund­ver­ord­nung (DS-GVO). Wer Coo­kies und ähn­li­che Tech­no­lo­gien ver­wen­det, muss daher in der Regel bei­de Geset­ze beachten.

Betrei­ben­de von Web­sei­ten und ande­ren Tele­me­di­en benö­ti­gen grund­sätz­lich eine Ein­wil­li­gung der Nutzer:innen, wenn sie Infor­ma­tio­nen auf dem End­ge­rät spei­chern oder dar­auf zugrei­fen wol­len. Einer Ein­wil­li­gung bedarf es aus­nahms­wei­se nur dann nicht, wenn die Spei­che­rung von und der Zugriff auf Infor­ma­tio­nen in den End­ge­rä­ten unbe­dingt erfor­der­lich sind, damit ein von den Nut­zen­den aus­drück­lich gewünsch­ter Tele­me­di­en­dienst zur Ver­fü­gung gestellt wer­den kann. Das ist zum Bei­spiel der Fall bei einem Coo­kie, der dazu dient, Arti­kel eines Online-Shops in einem Waren­korb zu speichern.

Um Ver­ant­wort­li­che bei der Umset­zung der neu­en Anfor­de­run­gen behilf­lich zu sein, erar­bei­ten die deut­schen Daten­schutz-Auf­sichts­be­hör­den der­zeit eine Ori­en­tie­rungs­hil­fe. Die­se soll Anfang näch­sten Jah­res ver­öf­fent­licht werden.

Down­load TTDSG tritt in Kraft: Kla­re Regeln für Coo­kies und ähn­li­che Tech­no­lo­gien als PDF