Source: https://hannoverit.de/cybersicherheit/stellungnahme-niedersaechsisches-it-sicherheitsgesetz/
Timestamp: 2019-09-21 21:14:22
Document Index: 210275159

Matched Legal Cases: ['§9', '§4', '§5', '§5', '§5', '§7']

Hannover IT » Niedersächsisches IT-Sicherheitsgesetz
Nie­der­säch­si­sches IT-Sicher­heits­ge­setz
IT-Sicher­heit ist für den digi­ta­len Erfolg ein ent­schei­den­der Bau­stein, wenn es bedarfs­ori­en­tier­te Lösun­gen für unter­schied­li­che Nut­zungs­ver­hal­ten gibt.
Wir emp­feh­len, mög­lichst schnell ein Ver­fah­ren zu ent­wi­ckeln, wel­ches gem. den recht­li­chen Vor­ga­ben als „struk­tu­riert“ im Jahr 2019 aner­kannt wird. Der­zeit ist es vor­nehm­lich das ZUG­PFERD-Ver­fah­ren. Doch mit Zunah­me der eID­AS wer­den bis dahin neue Ver­fah­ren ent­wi­ckelt sein. Ins­be­son­de­re aus Sicht der Geschäfts­part­ner der öffent­li­chen Hand ist aus unse­rer Sicht noch zu dis­ku­tie­ren, wie EU-wei­te Aus­schrei­bun­gen gene­rell vom Auf­trag­neh­mer auch elek­tro­nisch aus­wert­bar zu erstel­len sind. Unse­rem Ver­ständ­nis nach bedeu­tet die­se eine Abkehr vom bis­he­ri­gen, weit ver­brei­te­ten PDF-Stan­dard hin zu ZUGFERD oder XML nach dem GoBD Beschrei­bungs­stan­dards.
Im Hin­blick auf die Umsetz­bar­keit des Geset­zes möch­ten wir zu beden­ken geben, dass bspw. §9 durch klei­ne­re Berei­che nicht umge­setzt wer­den kann. Somit wird aus unse­rer Sicht die Mög­lich­keit ent­zo­gen, die­se Sicher­heits­maß­nah­men flä­chen­de­ckend anwen­den zu kön­nen. Zudem ist die Sinn­haf­tig­keit des mehr­stu­fi­gen Sys­tems hin­sicht­lich einer Beherrsch­bar­keit rea­ler Angriffs­sze­na­ri­en frag­lich, insb. in Bezug auf Arbeits­zei­ten und Ska­lie­rung. Wir hal­ten es grund­sätz­lich für pro­ble­ma­tisch, dass mit dem Gesetz Stan­dard­ar­bei­ten ein­ge­schränkt wer­den, da nun nicht wie bis­her ein­fa­cher Zugriff auf belie­bi­ge Sys­tem­logs durch Admi­nis­tra­to­ren zuläs­sig ist. Als Gegen­ent­wurf zu der star­ken Tren­nung der Ver­ant­wort­lich­kei­ten wäre die Unter­brin­gung stär­ke­rer Audit-Tätig­kei­ten hin­sicht­lich Netz­werk­ver­kehr und Sys­tem­logs bei den vor­han­de­nen Admi­nis­tra­to­ren-Per­so­nal­res­sour­cen denk­bar und mög­li­cher­wei­se prak­ti­ka­bler.
Zu den Para­gra­phen im Ein­zel­nen:
Zu §4 Abs 2: “Spei­che­rung” vs. “Aus­wer­tung”
Für Aus­wer­tung müss­te ein max. Zeit­raum der Aus­wer­tungs­dau­er fest­ge­legt wer­den, da sonst die max. Spei­che­rungs­frist hier­über “aus­ge­he­belt” wer­den könn­te. Es wäre denk­bar und mög­lich, eine “Aus­wer­tung” über Tage, Wochen oder Jah­re durch­zu­füh­ren. Dies soll­te ein­ge­schränkt wer­den. Eine auto­ma­ti­sier­te Aus­wer­tung jeweils nur ein­zeln betrach­te­ter Daten­sät­ze bzw. Log­ein­trä­ge, also mit dem denk­bar kür­zes­ten Zeit­raum, birgt jedoch eige­ne Pro­ble­me (sie­he “Enu­me­ra­ti­on-Angrif­fe”).
Zu §5 Abs 1 Satz 2: HTTP-Meta­da­ten-Aus­wer­tung und TLS
Der Para­graph erlaubt die Aus­wer­tung der meis­ten HTTP-Meta­da­ten. Nicht geklärt ist, ob dies impli­zit ein Auf­bre­chen aus­ge­hen­der TLS-Ver­bin­dun­gen erlau­ben soll. Dies soll­te ggf. expli­zit for­mu­liert wer­den.
Zu §5 Abs 2:
Der Para­graph ver­langt, dass Aus­wer­tungs­er­geb­nis­se unver­züg­lich gelöscht wer­den, wenn nicht nach §5 ABs 1 Satz 3 ein Ver­dacht besteht. Der Satz gestat­tet Ana­ly­sen auf IP- und HTTP-Hea­der-Ebe­ne. Hier sehen wir die fol­gen­den Pro­ble­me:
Angrif­fe über ande­re Anwen­dungs­pro­to­kol­le als HTTP
Angriffs­ver­su­che über ande­re Pro­to­kol­le als HTTP las­sen sich somit i.d.R. nicht erken­nen. Hier soll­te ent­we­de­re eine all­ge­mei­ne­re For­mu­lie­rung gewählt wer­den oder zumin­dest übli­che ande­re Pro­to­kol­le mit auf­ge­führt wer­den.
Enu­me­ra­ti­on-Angrif­fe
Das gefor­der­te “unver­züg­li­che Löschen” ver­hin­dert eine Erken­nung von sog. Enu­me­ra­ti­on-Angrif­fen, wie bspw. User- oder Resour­ce-Enu­me­ra­ti­on, aber auch Bru­te Force-Angrif­fe /Dic­tion­a­ry-Attacks usw.
Ana­ly­se von Coo­kie-Hea­dern
Der gefor­der­te Aus­schluss von Coo­kies bei der Ana­ly­se ist wenig sinn­voll: ers­tens kön­nen per­so­nen­be­zo­ge­ne Iden­ti­fier auch in ande­ren Hea­dern ent­hal­ten sein (z.B. “Aut­ho­ri­za­ti­on” für HTTP Basic Auth., hier sind Benut­zer­na­men und Pass­wör­ter ent­hal­ten) – es müss­te daher aus die­sem Gesichts­punkt eine län­ge­re Black­list für Hea­der auf­ge­führt wer­den, wel­che jedoch auf­grund von tech­ni­schen Mög­lich­kei­ten und Wei­ter­ent­wick­lun­gen nie voll­stän­dig wür­de. Jedoch kön­nen auch Coo­kie-Hea­der-Daten für Angrif­fe ver­wen­det wer­den, und müss­ten daher auch auto­ma­ti­siert aus­ge­wer­tet wer­den. Letz­te­res wür­den wir emp­feh­len.
Zu §7 Abs 4 – For­mu­lie­rung “nicht mehr erfor­der­lich”
Die For­mu­lie­rung “nicht mehr erfor­der­lich” soll­te ggf. erläu­tert wer­den. Wenn Abwehr von Gefah­ren bereits erfolgt ist, müss­te hier unse­rer Ein­schät­zung nach ent­spre­chend des Geset­zes­ent­wurfs gelöscht wer­den – dann wür­den bei einer beab­sich­tig­ten Straf­an­zei­ge jedoch not­wen­di­ge Beweis­ma­te­ria­li­en feh­len. Ggf. könn­te die For­mu­lie­rung “zur Abwehr von ande­ren Schad­pro­gram­men” die erlaub­te Spei­cher­dau­er jedoch aus­deh­nen. Eine ein­deu­ti­ge Klä­rung von “erfor­der­lich” wür­de die­se Ambi­gui­tät ver­mei­den.