Vyhláška o klasfikácií informačných systémov a bezpečnostných opatreniach - pripomienkovanie

Dobry den,

pripravujeme novu vyhlasku o klasifikacii IS vo Verejnej sprave a bezpecnostnych opatreniach. Chcem Vas poziadat o pripomienky k tomuto dokumentu.
Momentalne je to rpacovna verzia. Prosim o zaslanie pripomienok na : lukas.hlavicka(at)csirt.sk do 24.5. Potom sa budu pripomienky zapracovavat a koncom juna/jula do pojde do MPK
Dakujem
Vyhlaska o klasifikacii a ochrane ITVS v0.14.docx (170.0 KB)

5 Likes

Ja teda nechcem hneď od začiatku vyzerať ako kverulant, ale hneď na prvé pozretie:

  • kľúčová vec je určenie klasifikačnej úrovne, avšak k tomu vyhláška nedáva absolútne žiadne objektívne vodítko, iba strohú informáciu “žiadny / obmedzený / závažný / obzvlášť závažný negatívny vplyv” - čiže každý si to môže vyložiť ako chce, napr. nepochybujem že moji libertariánski kamaráti (pôsobiaci v IT security) by zničenie akejkoľvek štátnej informácie nepovažovali za obzvlášť negatívne a ÚPVII nemá žiadny nástroj ako im protirečiť

  • presne ako som očakával, príklady klasifikácie obsahujú položky typu “prihlasovacie údaje” vo vysokých kategóriách, a celková klasifikácia sa pomocou takýchto položiek bude tlačiť hore - čo je smiešne, lebo je to presne naopak: škody, ktoré môžu byť spôsobené narušením bezpečnosti prihlasovacích údajov, sú priamo určené škodami na “skutočných” aktívach v systéme

  • vyhláška obsahuje cca. 60 strán opatrení, z čoho je jasné že buď sa to masovo nebude dodržiavať, alebo objem služieb externých IT dodávateľov bezpečnosti nie že poklesne, ale rapídne stúpne, alebo oboje súčasne

  • osobne si myslím (a rád praktickými skúsenosťami doložím), že predpísať plošne opatrenia na takejto úrovni detailu je skrátka neefektívne a kontraproduktívne. Povedzme hneď prvé opatrenie: “automatická aktualizácia operačného systému a aplikácií” - poznám mnoho systémov, kde automatická aktualizácia nie je zapnutá a je to dobre. Vrátane vysoko bezpečných prostredí, napr. systémy ktoré sú dostatočne izolované od internetu aj vstupov používateľov.

  • časť opatrení vyzerá náhodne, povedzme príloha 5 / politika hesiel - heslo k “neprivilegovanému účtu” musí byť minimálne 12 znakov + povinne špeciálny znak v hesle + meniť heslá raz za rok + nové heslo nesmie byť rovnaké ako 5 predošlých + heslo je možné meniť max. 1 krát za deň - po mnohoročných celosvetových diskusiách o politikách hesiel sa na to dá povedať iba: wtf? na patobnú kartu máme všetci PIN, ktorý nespĺňa z tohto nič, a zjavne je to akceptovateľná úroveň bezpečnosti

6 Likes

Plus samozrejme očakávam, že toto bude podrobne prezentované, diskutované a pripomienkované v niektorej z pracovných skupín k bezpečnosti na ÚPVII.

Lukas to nie je dobry smer. Taketo detaily nemaju vo vyhlaske co hladat. Mozu byt niekde v metodike, ale nie v legislativnom dokumente. Vznikne gap, ked sa zrusi Vynos o standardoch, toto co je v momentalnom drafte vyhlasky, nie su bezpecnostne standardy.

4 Likes

Aha, práve som si všimol že v utorok bola PS KyB, ktorej stretnutie som si nejako zle zaznačil a teda som tam nebol. Moja chyba. Tam sa aj zrejme prezentoval tento dokument.

Ku tejto vyhlaske bude este viacer sedeni. Mozno tie specificke opatrenia dame do metodickeho materialu.
podstatne je, ze toto je uroven ktoru by sme ocakavali od statnych systemov.

Co sa tyka externych dodavatelov, vacsina by mala byt implementovana internym staffom … ale o tom niekedy nabuduce :slight_smile:

Ak budu vazne pripomienky, co predpokladam budu tak si dame k tomu zaciatkom juna niekolko pracovnych stretnuti kde to vsetko vydiskutujeme. Ale bolo by fajn, keby uz boli pripomienky aby sme to mohli cele prejst.

Ja sa skusim spytat naopak, ked zoberiem AWS, Azure, Google public cloudy. Ake statne udaje a systemy tam mozeme dat? Ako je to kompatibilne s kadejakymi security certifikaciami, co tie cloudy maju?

1 Like

Ono by to malo zmysel pripomienkovať na dve časti: najprv vyriešiť podstatné veci k obsahu, nastaveniu a rozsahu materiálu a keď toto bude uzavreté, tak v druhom kole pripomienkovať konkrétne opatrenia.

Takto ako je to navrhnuté to bude uplatňované v podstate naopak - pozriem si čo ktorá kategória opatrení predpisuje, nájdem tú čo mi najviac vyhovuje (nech už mám akúkoľvek motiváciu), a podľa toho napasujem klasifikáciu.

Plus pre opatrenia je dôležité, ako bude fungovať režim “výnimiek”. Teoreticky si viem predstaviť že táto vyhláška nebude znamenať “spravte to povinne takto”, ale “toto je default a ak chcete čokoľvek ináč, zdokumentujte a ÚPVII schvaľuje” - a tam závisí na vôli a kapacite všetky tie špecifické prípady riešiť. Potom ale vzniká otázka, prečo rovno nepoužiť ISO 27002, či už ako framework, alebo chcecklist základných opatrení.

2 Likes

Na klasifikaciu udajov momentalne UPVII pracuje aj z pohladu ukladania dat v public cloudoch. Vo vseobecnosti by to malo by nieco co je napriklad Nizsie (zatial len vystrel od boku, momentalne sa na tom pracuje takze sa to moze este menit) alebo rovne ako C(1)I(2)A(2)

Presne takto to bude vizerat… ISO27002 je ako framework super, a boli sme nim inspirovany, ale nieco bolo potrebne ubrat nieco pridat a plus to ma rozne organizacne vyzvy nakolko sa jedna o plateny standard.

Čiže aby som použil príhlad z tabuľky vo vyhláške - v public cloude bude zakázané mať napr:

  • hocičo kde hrozí právny postih úradu
  • elektronické služby občanom
  • webové aplikácie pre služby občanom
  • mail server
  • hocičo kde sú heslá
  • hocičo kde hrozí právny postih úradu - samozrejme
  • elektronické služby občanom - samozrejme
  • webové aplikácie pre služby občanom - nie, tie su C0 (lebo su verejne :D)
  • mail server - ano
  • hocičo kde sú heslá - ano, okrem verejnych webovych portalov

Toto je pozicia ktoru podla mna stat nemoze dlhodobo udrzat a tusi to asi vela bezpecakov co funguju v komercii… Vzhladom na ndacky nemozem menovat, ale mnohe banky a uz aj na Slovensku bezia casti kritickej infrastruktury v public cloude. Tento trend Slovensko nemoze zvratit ani ignorovat.
Ale ved skomplikujme si situaciu dalsou regulaciou.

2 Likes

Asi tomu uplne prestavam rozumiet. Akoze dnes, ked dodavatel hardveru, softveru co zabezpecuje celu prevadzku statneho systemu nieco pokazi, tak tam nehrozi pravny postih uradu? Ved to by sme nemohli dat nic vobec nikde.

Tu sa to mysli, tak, ze zodpoveda v zmysle zakona za nejake cinnosti. Ergo vykon verejnej moci. Samozrejme aj tam hrozi postih, ale organizacie maju dosah na to, ze ako si to prevadzkuju a su za to zodpovedne.

Skusim priklad, pred dvoma tyzdnami som siel na policiu vybavit si novy pas. Cely system im par hodin nefungoval. Netusim aky na to mali dosah, ale asi museli nieco riesit s dodavatelom. Keby cele toto bolo v public cloude, co by sa zmenilo? Odkial je toto KO kriterium? Public cloudy nemaju support/SLA?

1 Like

Práve som pozrel na portál školy kde chodí moja dcéra. Je tam mrte dosť osobných údajov, občas aj nejaký ten výkon verejnej moci (prijímačky, vysvedčenia), zrejme teda v prípade prúseru škole “hrozí právny postih”, je tam kopa elektronických služieb občanom, posielame si tadiaľ s učiteľmi “správy” (teda mail server), všetci tam majú svoje heslá.

Celé je to nie že v cloude, ale robí to nejaká súkromná firma u seba, web je pod doménou .org, lebo to funguje aj v iných krajinách.

Problémy s bezpečnosťou som nezaznamenal žiadne. Problémy že by “orgán riadenia (škola) nemal na to organizačný dosah” nielen že žiadne neboli, ale ak by som takúto otázku položil riaditeľke, asi by začala pochybovať o mojom zdraví.

Capture

Zároveň je tu krásny príklad iného nezmyslu. “Publikovaná legislatíva” síce môže mať zásadné negatívne dopady ak bude mať narušenú integritu (t.j. niekto pôjde podľa falošného zákona). Ale

  • pravdepodobnosť že sa to stane je tým menšia čím vážnejšej veci by sa to týkalo - rozumej že ak mám zákon s nejakým vážnym/čudným znením, overím si či je to naozaj tak - pritom táto vyhláška s pravdepodobnosťou realizácie hrozby vôbec nenarába, zjednodušili ste si život že veľkosť škôd = veľkosť rizika
  • sú známe, jednoduché a používané nástroje, ako sa integrita “legislatívy” chráni - je elektronicky podpísaná

Skrátka v tomto prípade sa urobí 1 opatrenie, poriadne - zákony sa už aj teraz na slovlexe publikujú podpísané - a celý zvyšok vyhlášky môžem ignorovať. A mám systém s klasifikáciou I3, z ktorej žiadne reálne požiadavky na nejaké vysoké opatrenia (vrátane zákazu public cloudu) nevyplývajú.

2 Likes

Dobry den, preto sme to dali na pripomienkovanie aby sme ziskali feedback a potom spolocne dosli k takemu alebo onakemu zaveru.

PO druhe. Co sa tyka Cloudu : Problemov cloudu je niekolko (nielen privatneho) a to ze centralizujem velke mnozstvo zaujimavych informacii na jednom mieste a ze system sa musi prisposobit bezpecnostnym opatreniam, ktore cloud poskytuje a nie opacne. Problem verejneho cloudu je potom okrem uvedeneho aj v tom, ze nemam moznost si realne bezpecnostne opatrenia otestovat, nemam moznost kontrolovat personal, ktory ma pristup k fyzickym zariadeniam (a teda aj spracovavynm datam, co neriesi ani sifrovanie) a som vendor-locknuty na male mnozstvo cloudovych providerov, ktorym sucasne musim platit az do skoncenia prevadzky systemu, Sucasne su z Internetu dostupne systemy (minimalne prostrednictvom manazmentovej konzoly niekde v cloud) servery, ktore nikdy pristupne z internetu nemali byt, nemozem budovat pre bezpecne systemy hlbkovu ochranu a kopu dalsich.
Do cloudu aj verejneho ma zmysel davat systemy, ktore nemaju vysoke naroky na dovernost, ale mozno vysoke naroky na dostupnost.