Minulý štvrtok sa o tejto vyhláške hovorilo na PS K9.8 KyB. Po tom, ako viacerí členovia skupiny dali pripomienky ku celkovej koncepcii vyhlášky, vedúci PS prisľúbil, že vyhláška musí byť zásadne prepracovaná.
Ano do vyhlasky budu dopracovane oblasti z 27000 a niektore veci viac rozpracovane. Idea baseline a specifickych opatreni tam ale zostane.
hm ja by som ak by som mal na ucte miliony pin neakceptoval ale co s tym narobim?
aj pohlad je dolezity ak sa na to divam tak ze ja sam sebe uznam ze mi kratke heslo staci je to moj problem a pripadne moja skoda.
Ale v tomto pripade organizacia stanovuje ako chranit jej údaje, preto by mala v tomto jasne definovat minimalne poziadavky, kedze ide o jej udaje…
Vo vseobecnosti je cielom vyhlasky nastavit a implementovat v jednotlivych organizaciach opatrenia tak, aby data obcanov a informacna bezpecnost organizacii boli na urovni, ze budu odolavat hrozbam, ktore tymto datam a organizaciam hrozia. Sucasne aby v ramci verejnej spravy boli chranene udaje obcanov a aby obcania dostavali kvalitne a bezpecne sluzby.
Z viacerych pripomienok co som videl aj cital mam bohuzial pocit, ze cielom niektorych pripomienkujucich nie je systematicke zavedenie bezpecnosti v organizaciach, ale minimalizacia namahy a moznosti merat uroven bezpecnosti. Mrzi ma takyto pristup mnohych.
Jedna fakticka, kedze sa bavime o verejnej sprave: Ergo nie organizacia nieco “vlastni”, ale vlastnime to my ako obcania. Najma ak su to data o nas. Co ale samozrejme nic nemeni na tom, ze organizacia ta ci henta nejake tie konkretne data realne “drzi”/spravuje (lebo ma na to poverenie/povinnost) a teda ma zabezpecit aj ich adekvatnu ochranu. Ale nerobi to ani tak pre seba, ale pre nas. 
Sorry za mierny off-topic.
Absolutne suhlasim. Cely statny aparat je tam pre obcanov nie pre seba.
Jasne, ale opatrenia nastavujem a implementujem tak, aby minimalizovali identifikovane rizika. Mame analyzu rizik sektorov ? Mame analyzu rizik previazanu s kategorizaciou a klasifikaciou ? Ja neviem, preto sa pytam. Ak chcem merat uroven bezpecnosti, rizika by som mal mat identifikovane. Nie hrozby, konkretne RIZIKA ktore chcem opatreniami minimalizovat. Toto je podla mna logicky a vysledky prinasajuci postup.
2 Likes
Tieto rizika identifikovane su.
Bez ohladu na to, ale (inak vychadza to aj z identifikovanych rizik) je potrebne zaviest zakladne bezpecnostne opatrenia podla typu organizacie (tak ako je to definovane vo vyhlaske, pricom typy organizacie boli urcene na zaklade zakonnych povinnosti a spracovavanych dat). Jedna sa o zakladny baseline.
Potom pre informacne systemy, ktore su dolezite (C3, I3, A3) sa urobi analyza rizik (ktora ale aj tak vzhladom na typy spracovavanych dat bude vyzadovat opatrenia popisane v casti specificke opatrenia vo vyhlaske) nakolko system, ktory ma byt odolny voci kybernetickemu utoku na urovni pokrocileho utocnika musi implementovat minimalne popisane opatrenia.
Zakladne bezpecnostne opatrenia su bez debaty. Baseline je bez debaty. Aj ten postup co pises dava zmysel. Az na tie specificke opatrenia typu
" 4.33 Na kritických serveroch s OS Windows ako sú doménové kontrolery, DNS servery apod. musí byť nainštalovaný a nakonfigurovaný nástroj EMET (od Microsoft) so zapnutými všetkými ochranami, ktoré je možné zapnúť. "
toto mi uz zmysel nedava. Skor sa mi to zda kontraproduktivne. To by som nechal na organizaciu, ake konkretne technicke opatrenia prijme.
Umyselne je to tam takto technicky napisane, lebo by ste neverili ake vyhovorky som uz videl od roznych institucii, ze preco to nie je.
Napriklad, ze to nie je nikde vyslovene napisane ze to musia robit, alebo ze podla nich je to v poriadku, lebo im to povedal dodavatel, alebo ze podla nich to maju osetrene technologiou XY (ktora btw robi uplne nieco ine ) a podobne. Takto technicky je to pisane len tam, kde sme sa uz s takym niecim stretli alebo je vysoky predpoklad na zaklade nasich skusenosti, zeby sme sa s tym stretli.
Sice to sem myslim uz pisal Lubor, ale:
There are no plans to offer support or security patching for EMET after
July 31, 2018. For improved security, we recommend that customers
migrate to the latest version of Windows 10. [1]
Taketo nieco je zle ci uz z pohladu formalnej, alebo aj vykonatelnej
bezpecnosti.
[1]
https://support.microsoft.com/en-us/help/2458544/the-enhanced-mitigation-experience-toolkit
r.
Dobry den,
bohuzial mnoho statnych institucii nema na prechod na nove systemy zdroje, takze budeme musiet pracovat s tym co je 
a preto este toto bude velmi dlho jedine mozne riesenie, ktore je realne implementovatelne
Lukas, ja verim. Velmi dobre viem aka je uroven bezpecnosti v statnych IS. Pohybujem sa v nich cca 20 rokov. A rovnako dobre viem, aku namahu da (v oblasti kybersec) nieco presadit, implementovat a nasledne udrziavat. A prave preto pisem co pisem. Kludne nech vnikne katalog predpisanych opatreni pre OS, standardne veci ako webserver atd. Ale nech nie je sucastou vyhlasky ako pravneho predpisu. Ak v nej budu technologicke detaily tohto typu, tak bude permamentne v legislativnej zmene (nasla sa diera v protokole, objavil sa lepsi produkt, skoncil sa support pre nariadeny nastroj atd atd). Bude v tom gulas a vznikne zivna poda pre vyhovorky. Ked v platnej vyhlaske budu predpisane obsoleted veci, bude povazovana cela za nedoveryhodnu. Pouzivat unsupported tool, najma v oblasti kybersec je citankove bezpecnostne riziko, to nam je vsetkym predsa jasne. Mozem to odporucit v metodike, kde vysvetlim kontext (ze je unsupported) ale predpisat to legislativne bude bezpecnostny faux pas.
Ked sa robi software, tak sa tvoria viacere dokumenty
- Requirements spec - teda co chceme
- Design spec - teda ako navrhujeme, ze to ma byt
- Test spec - ako skontrolujeme, ze to prve je tym druhym (plus implementaciou) naplnene.
Takze to co pise @IvanK je len poziadavka na nejake taketo rozdelenie, aby koli zmene designu nebolo treba otvarat a schvalovat nanovo requirements.
Na druhu stranu ten desing spec nemusi byt zavazny ale iba odporucaci a ak ma niekto lepsie riesenie, tak ked prejde testami, tak ho treba akceptovat.
Pre info, toto sú zhruba pripomienky, ktoré som prezentoval na PS: (väčšina je z tejto diskusie)
pripomienky.docx (17.0 KB)
Suhlas. Myslel som to tak ze ak ma napr. o mne udaje ministerstvo zdravotnictva tak ono za ne zodpoveda a pre to je povinne stanovit a dodrziavat take poziadavky na kvalitu hesla aby malo istotu ze nedojde k ich zneuzitiu. A taklto isto aj vsetky organizacie, ktore udaje spravuju.
používanie unikátnych hesiel s dĺžkou aspoň 9 znakov, ktoré je zložené z aspoň jedného veľkého písmena, jedného malého písmena, jedného čísla, jedného znaku a ktoré neobsahuje slovníkové slovo alebo jeho obmeny a jeho zmena aspoň raz ročne,
Este sa myslim ani poriadne pripomienkovat neskoncilo a uz tu mame nieco:
- Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
…
There’s no question that the state of password security is problematic and has been for a long time. When humans pick their own passwords, too often they are easy to guess or predict. When humans are assigned or forced to create passwords that are hard to remember, too often they’ll write them down where others can see them. When humans are forced to change their passwords, too often they’ll make a small and predictable alteration to their existing passwords, and/or forget their new passwords. When passwords or their corresponding hashes are stolen, it can be difficult at best to detect or restrict their unauthorized use.Recent scientific research calls into question the value of many long-standing password-security practices such as password expiration policies, and points instead to better alternatives such as enforcing banned-password lists (a great example being Azure AD password protection) and multi-factor authentication. While we recommend these alternatives, they cannot be expressed or enforced with our recommended security configuration baselines, which are built on Windows’ built-in Group Policy settings and cannot include customer-specific values.
…Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903 | Microsoft Learn
via https://twitter.com/SwiftOnSecurity/status/1134313403789369344
1 Like
@Lukas_Hlavicka ako sa mysli postavenie bezpecnostneho projektu podla navrhu vyhlasky ? Bezpecnostny projekt sa vypracuvava v sulade s identifikovanymi bezpecnostnymi potrebami pre IS/ITVS, je sucastou projektovej dokumentacie (preto sa vola projekt). Taziskova cast je analyza rizik predmetu projektu (ITVS) a navrh bezpecnostnych opatreni vratane sposobu ich implementacie. V navrhu vyhlasky vsak citam ze sucastou bezpecnostneho projektu ma byt bezpecnostna politika. Ale to je interny riadiaci akt, nie projektova dokumentacia. Navyse sa priamo pozaduje aby projekt obsahoval vnutorne predpisy - moze ich zohladnit, alebo navrhnut ich vypracovanie (ak neexistuju). Ale ako moze projekt obsahovat predpisy ? Nemylme si bezpecnostny projekt a internu predpisovu zakladnu organizacie…Nerozumiem tiez, ako velky organ riadenia s desiatkami IS moze mat jeden bezpecnostny projekt, ked zavadza Z0, Z1, Z2 a Z3 . Taky bezpecnostny projekt bude mat tisice stran. Alebo pojem “bezpecnostny projekt” je nazov “sanonu”, ktory obsahuje napr. analyzy rizik a bezpecnostnu dokumentaciu pre jednotlive IS ?
Prebehlo niekoľko stretnutí pracovných skupín, kde sa diskutovalo čo s touto vyhláškou ďalej.
Zásadné veci ktoré boli dohodnuté (podľa mojich zápiskov):
- špecifické opatrenia vo vyhláške nebudú, iba baseline level Z0 - Z3
- klasifikácia vo vyhláške nebude, ak niekde v budúcnosti, tak úplne kompatibilne k zákonu/vyhláške o KyB
- “výnimky”, resp. zabezpečenie adekvátnej ochrany inými opatrením ako v baseline, si má povinná osoba zdokumentovať, vrátane dôvodu a alternatívneho opatrenia, interne schváliť, na ÚPVII sa to bude zasielať (a ÚPVII môže ďalej riešiť ak má pocit že úroveň opatrení je slabá)
- vyhláška má rozpracovať spôsob splnenia všetkých povinností z §18-23 zITVS, zjednodušene povedané povinná osoba ak splní vyhlášku, mala by byť v súlade s touto časťou zákona - toto je dôležité najmä pre nízke levely, ÚPVII aktualizuje draft vyhlášky aby tam boli všetky povinnosti (do 15.8.)
Za mňa je takýto rámec zrozumiteľný. Teraz teda máme pripomienkovať opatrenia v Z0-Z3, do 23.8.
1 Like
Aktuálne pripomienkovaná verzia dokumentu:
Vyhlaska draft_V3 - finalna verzia_4_12_2019.docx (79.6 KB)
Za mňa som poslal iba takéto koncepčné pripomienky:
-
V rámci MPK bude predložená realistická analýza nákladov verejnej správy na zavedenie súladu s touto vyhláškou - ideálne v rámci doložky vybraných vplyvov, časť vplyvy na rozpočet verejnej správy; a súčasne budú vyčlenené dostatočné centrálne zdroje na pokrytie týchto nákladov.
-
Preformulovať §4 ods.1 nasledovne: “Za bezpečnosť ITVS zodpovedá jeho správca. Ak na tento účel je vhodné prijať iný súbor opatrení ako sú uvedené v tejto vyhláške, zmeny v rozsahu opatrení musia byť správcom zdokumentované, odôvodnené, schválené štatutárom a zaslané orgánu vedenia.”
-
V §4 pridať nový odsek, nasledovne: "(2) Povinnosť vypracovať určitý dokument podľa tejto vyhlášky správca splní do 6 mesiacov odo dňa, kedy orgán vedenia zverejní jeho vzor a súvisiaci súbor materiálov v zmysle §1 ods.5. "
-
V celom dokumente zosúladiť, ktoré dokumenty a opatrenia je povinnosť implementovať samostatne pre každý ISVS, ktoré celkovo pre organizáciu, alebo všetky jej ITVS. Pritom pre opatrenia samostatne realizované pre každý ISVS je potrebné určiť jednotiaci prvok tak, aby spoločne plošne pokrývali organizáciu na jednej úrovni. Napr. ide o vytváranie “bezpečnostných projektov ISVS” (príloha 2), versus “vypracovanie analýzy rizízk KIB” (príloha 3.B.I.a).