Názory k článku
Firmy chtějí prodloužit trvání připomínkového řízení k novému zákonu o kyberbezpečnosti

Jenze pod "akceptovano jinak" jsou i fakticka odmitnuti, jednim takovym sam disponuji ;-) Aneb k pripomince, ze se ponekud neridi smernici, na kterou se sami odkazuji (NIST SP 800-63B) a vubec obecnymi trendy, ktere jsou v dane oblasti v zahranici na zapad od nas se vyjadrili tak, ze se nic proste menit nebude, proste my na urade mame svoji pravdu ;-) Aneb vsude ve svete se od vynucovanych periodickych zmen hesla ustupuje, ale nas NUKIB se tohoto archaickeho pristupu k bezpecnosti odmita vzdat...

NIST SP 800-63B jasne v clanku 5.1.1.2 rika, ze:

Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Jestli je perioda vynucene zmeny 18 nebo 24 mesicu je irelevantni, porad je to vynucena periodicka zmena a to je proste spatne. A jak uz to v Cesku byva, v korporatech se s odvolanim na tu vyhlasku nejaky "radobybezpecak" usnese, ze tu periodu jeste zkrati - protoze vyhlaska z pera NUKIB spodni meze nestanovi. A o tom, ze vynucovat periodicke zmeny je chyba jsou popsane stohy papiru. Vetsi bezpecnost se skrze podobnou nesmyslnou buzeraci uzivatelu fakt nedocili...

Pristup NUKIB je spatny, protoze aplikuje pristupy, ktere jsou v kyberneticke bezpecnosti uz davno prekonane - a bezpecnost nezvysuji, spise naopak vedou ke spatnym navykum typu hesla napsana na listeckach/v notysku... tvurci podobnych smernic vidi jen "svuj jeden system" a vubec si neuvedomuji, ze bezny uzivatel ma hromady hesel okolo. A krome americkeho NISTu to rika treba i anglicky NCSC. Dovolim si tvrdit, ze tyhle instituce jsou na tom z pohledu znalosti v oblasti kyberbezpecnosti lepe, nez nas NUKIB ;-)

Vynucená periodická změna má své opodstatnění (jsme na úrovni tak víme jaké)
Vynucená periodická změna snižuje bezpečnost, takže ve směrnici zajišťující bezpečnost žádné opodstatnění nemá.

A protože asi nejsme až tak na úrovni, bude hádám potřeba vysvětlit, proč vynucená změna hesla snižuje bezpečnost. začněme tím, proč bezpečnost nezvyšuje. Představa autorů nápadu s periodickou změnou hesla je asi taková, že pokud nějaké heslo unikne náhodou a nezjistí se to, po periodické změně hesla ten, kdo heslo náhodou znal, ztratí přístup. To je ale z bezpečnostního hlediska mylná představa. Jednak, pokud někdo získal přístup a nevíme jak, musíme předpokládat, že ho po změně hesla získá znovu. Dále pokud během periody mezi změnami hesla nezjistíme, že k úniku došlo, může útočník celou dobu nerušeně zneužívat svůj přístup – takže někdo cizí má třeba 12 měsíců přístup k nějakému systému, může z něj číst data nebo je měnit, a je to OK, protože po 12 měsících o ten přístup možná přijde? To snad ne… Za třetí, často je možné zřídit další způsoby přístupu, takže změna hesla nemusí útočníkovi zabránit v přístupu. A za čtvrté, při vynucené periodické změně hesel drtivá většina uživatelů používá nějaký systém, u kterého jde ze znalosti jednoho hesla odvodit heslo následující. Nejlepší je, když se heslo musí měnit jednou za rok a někdo teď bude mít heslo „terulka23“, tak to určitě žádného útočníka nenapadne, jaké heslo tam bude za rok.

No a proč to bezpečnost snižuje? Protože člověk má pro každý systém nastavenu nějakou hranici – podle toho, jak moc chce chránit přístup k danému systému, tolik energie je ochoten věnovat na jeho zabezpečení. Takže třeba přístup do banky většina lidí chrání lépe, než přístup na diskusní fórum. Kdyby se používala jenom hesla, budou lidé (alespoň jejich většina) používat na fórum stejné heslo, jako na spoustě dalších webů – ale do banky budou mít speciální silnější heslo. No a vynucená periodická změna hesla vede k tomu, že se nezanedbatelná část této energie vyplýtvá na tu periodickou změnu. Takže tam uživatel typicky bude mít slabší heslo, než jaké by měl nebýt té vynucené změny hesel.

Váš požadavek na kontrolu, zda heslo nebylo součástí nějakého úniku, vychází z předpokladu, že někdo používá stejné heslo na více místech. Což je zásadní bezpečnostní problém sám o sobě. To je potřeba řešit používáním správců hesel – a periodická změna hesla je něco, co jde proti používání správců hesel. Protože to použití správce hesel komplikuje a protože se použitím správce hesel riziko úniku hesla na straně uživatele ještě podstatně sníží.

Tak predne, ta terminologie z RFC se tyka RFC a nikoliv smernic NIST, jak se tu mylne snazite naznacit :-)

Opodstatneni samozrejme nema zadne. Pokud dojde ke kompromitaci stroje a tedy vzniku rizika offline utoku (pomineme-li to, ze i takove uloziste hesel by melo pouzivat pricetne algoritmy a ne md5...), pak se hesla musi zmenit tak jako tak a to i NIST v dalsi vete zminuje, ze? Ano, vyzaduje to jistou malickost - treba funkcni SIEM, ale to je "moc prace", tak se hledaji obezlicky ze?

Jistotu, ze uzivatel zvoli bezpecne a unikatni heslo vam periodicky vynucovana zmena rozhodne nezaruci. Ba prave naopak se zvysuje pravdepodobnost toho, ze uzivatel pouzije neco, co uz nekde jinde ma ci mel. To je presne to, cemu se NIST, NCSC a spousta dalsich venuji - a vec, kterou NUKIB akceptovat nechce... protoze se mentalne zapomel ve stoleti pary.

Argument postaveny na tom, ze "kasleme na monitoring bezpecnostnich incidentu a proto periodicky menime hesla", ktery pouziva NUKIB a nekteri "pseudobezpecaci" validni naopak neni (budeme-li se drzet te terminologie z RFC2119), to fak0t neni akceptovatelny duvod pro to nutit uzivatele menit hesla plosne a periodicky. To jen z pohledu uradu jde jen o dalsi vec, co se snadno kontroluje (a pokutuje). Proc to delat poradne a resit skutecnou bezpecnost, kdyz si to muzeme zjednodusit, ze?

Našel jsem si ten váš požadavek ;)

Souhlas, jedná se o odmítnutí, ale není to tak u "akceptováno jinak" vždy (spíše to vaše je výjimka). Porušení NIST SP 800-63B to není, což ale víte že ano. Otázka, zda by neposunuli obnovu na 24 m, kdybyste tu připomínku položil jinak ;)

Za mě přístup NÚKIB správný, nějaká periodicita změny tam má být, rok a déle je akceptovatelný. Znám poměrně dost společností, které jsou stále na 3 mesících a neměníte si jen jedno heslo, ale dvě nebo více... to je pak teprve peklo. Bůh dej, aby se posunuli na 18 měsíců.

Realita je taková, ...zbavte se hesel a obnovu jednou za 18 mesíců nemusíte řešit.

Ano, takze jen sma potvrzujete ze namisto poradneho reseni preferujete jednoduche nesmysly, ktere sice bezpecnost vubec nezvysi, ale zastanci se aspon muzou pred laickou verejnosti snazit tvarit tak, ze to je "bezpecny", kdyz jednou za rok a pul (ci mene) donutime nasilim zmenit hesla... :-)

A ne, podobnymi obskurdnostnomi skutecne bezpecnosti procesy nahrazovat nemuzeme. Ja chapu, ze cesi by radi meli vsechno jednoduchy a nejak to ocurali, ale takhle se seriozne bezpecnost delat proste neda...

"Sešlo se mu přes 1100 připomínek, moc jich ale začleněno nebylo"

S tímto bych nesouhlasil.

• 15% Akceptováno
• 22% Akceptováno jinak
• 21% Vysvětleno
• 42% Neakceptováno

Tzn. v celých číslech (přibližně): 165 přijato; 242 přijato jinak; 231 vysvětelno; 462 zamítnuto.
Chápu to tak, že začleněno bylo těch 15% + 22% = 37% vůči 42 % které byly zamítnuty. Zbylých 21 % v zásadě bylo zněním zákona pokryto, proto se to jen "vysvětlilo".

Víte co znamená SHOUD NOT dle RFC 2119? Tzn. dporučujeme, aby to tak bylo, ale pokud to tak není, protože k tomu máte relevantní důvod (který Vám ostatně NÚKIB popsal, nehledě na to jestli s tím souhlasíte či nikoliv), jste stále compliant s daným předpisem alias s NIST SP 800-63B.

Jiná situace by byla, kdyby tam bylo MUST NOT...

Vynucená periodická změna má své opodstatnění (jsme na úrovni tak víme jaké) a ano ve volbě periody je třeba za počítat i to, že častá změna vede k určitému chování, které je kontraproduktivní (víme jaké).

Na druhou stranu je naivní počítat s tím, že všichni uživatelé zvolí extra kvalitní heslo, které nebylo a nebude součástní nějakých úniků, zvláště pak v situaci, kdy ve firmě pravděpodobnost tohoto problému roste lineárně s počtem uživatelů a dobou výměny hesla, že ano... Proto nejspíš NÚKIB považoval za nutnost tam nějakou tu periodu dát.

Alternativou by asi bylo tam dát povinnost aktivní kontroly, zda hesla uživatelů nebyly součástí nějakého úniku. To by asi bylo lepší, ale problém je provést to kvalitně. Z jakých databází vycházet (něco je dostupné jen přes Tor a musí se to nakoupit...) a jak často to dělat a samozřejmě je s tím spojený určitý náklad, vybavení práce. Dále je otázka, která hesla (do jakých systémů, zařízení, ...) takhle zvládnete zkontrolovat.

26. 6. 2023, 11:52 editováno autorem komentáře

Když NIST tvrdí, že uživatel nemá být nucen k periodické změně hesla, a NÚKIB tvrdí, že uživatel musí být nucen ke změně hesla alespoň každých 18 měsíců, tak NÚKIB opravdu není v souladu s NIST.

Ale jak říkám pokud oranizaci ta výměna vadí, může zkrátka jít cestou passwordless autentizace, pak jim NÚKIB nemůže přeci vyčinit za to, že nevyměňují hesla ne?
Ne každý software lze používat v passwordless režimu.

Požadavky toho zákona (a NÚKIBu) jsou nutné minimum, nikdo vám nemůže zabránit použít bezpečnější nastavení. Bylo by zajímavé, jak by dopadl případný spor, kdy by někdo nevynucoval periodickou změnu hesla a argumentoval by tím, že je to bezpečnější, než NÚKIBem požadované řešení. Když někde NÚKIB vyžaduje heslo o délce alespoň 17 znaků a někdo použije 25znakové heslo, je to v pořádku – je to bezpečnější. Tak proč by to nemělo projít v případě periodické změny? Akorát ta argumentace, proč je to bezpečnější bez vynucené změny, by byla trochu sofistikovanější, než u délky hesla.

A tak schvalne, kolik takovych incidentu realne u nas probehlo? Tedy, ze by zcela nepozorovane unikla databaze uctu, byla vystavena offline utoku a nasledne opravdu doslo skrze takto kompromitovany system k pruniku do systemu?

Ono kdyz se zactete do dalsich komentaru ze strany NUKIBu, tak se clovek nemuze zbavit dojmu, ze to tam dali hlavne proto, ze se jim to snadno kontroluje. A vlastne ve sve argumentaci tak trosku vari z vody, neb jen maji nejakou teoretickou obavu...

Z kontrolní činnosti i z dobré praxe máme rozdílné zkušenosti, pokud bychom rezignovali na pravidelnou změnu hesla, máme obavu, že by pozitiva byla velmi rychle přebita negativními následky z toho plynoucími.

Realita je totiz takova, ze popisujete relativne slozity a vypocetne i narocny scenar pruniku a ono zatim nam systemy statem provozovane infrastruktury spokojene padaji na drzku diky mnohem jednodussim utokum :-) Ale hlavne periodicky ze menime ty hesla, ze...?

Danny a Jirsak maj pravdu, NUKIB je papeztejsi nez papez. Nic jineho ale od NUKIB necekam, zaplatit odborniky na security, s aktivni znalosti jazyka nejde za to co nabizeji.

Ok NIST 800-63B si to definuje po svém, ale význam se neliší, takže nevím, proč to je třeba probírat, ale tak:

"The terms “SHOULD” and “SHOULD NOT” indicate that among several possibilities one is recommended as particularly suitable, without mentioning or excluding others, or that a certain course of action is preferred but not necessarily required , or that (in the negative form) a certain possibility or course of action is discouraged but not prohibited."

Tzn. význam stejný... přesto, že si NÚKIB vymyslel 18m, tak je stále v souladu s NIST 800-63B, protože zakázáno (SHALL NOT) to není.

SIEM a nejlépe jeho 24x7 monitoring stojí nemalé peníze, ke všemu už jen vyvinout dobré a funkční SIEM Use Case stojí nemalé peníze (lidské zdroje) a toto chtít po všech 6k (nebo více) organizací v ČR... no to navrhujete mnohem větší brutalitu, jak ten NÚKIB s obměnou hesla jednou za 18 m (pro všechny).

§24 té vyhlášky pro vyšší povinnosti zmiňuje potřebu SIEMu. Tzn. není to tak, jak naznačujete, že by NÚKIB řekl, že vše zachráníme výměnou hesla za 18m a SIEM pak už není pak potřeba...

U nižších povinností logicky SIEM není povinností, protože je to velký náklad alias organizace v nižších povinnostech se mohou svobodně rozhodnout jestli SIEM chtějí či nikoliv.

Je to pak na úvahu, zda tedy u společností, které mají SIEM povinný mohu výměnu hesla odstranit. Já bych toho názoru nebyl, protože X těchhle organizací ZoKB povinných ten SIEM sice za velký prachy pořídí, ale nekoukají do toho, natož aby v tom měli nějaké ty UC schopné detekovat prolomení hesla nebo i útok.

Z pohledu layered security přístupu je SIEM na úplně jiné úrovni, jak změna hesla... prostě je to opatření navíc společně se to doplňuje. Ale jak říkám pokud oranizaci ta výměna vadí, může zkrátka jít cestou passwordless autentizace, pak jim NÚKIB nemůže přeci vyčinit za to, že nevyměňují hesla ne?

26. 6. 2023, 16:18 editováno autorem komentáře

Ok tak se pojďme bavit v čem ta změna hesla pomůže, nikoliv jak, čem a proč nepomůže, myslím že zdůvodnění přístupu v NIST jsme četli... ale děkuji za zopakování.

Existuje určitá doba mezi tím, kdy heslo unikne a kdy jej může útočník využít (je třeba lámat hashe, najít kupce databází, oťukávat různé služby, překonat jejich limity atd.) z toho plyne určitá doba mezi únikem a úspěšným využitím. Často útočník získá kombinaci login, heslo (obrovskou databázi), tak to prostě automaticky zkouší do X služeb, aniž by to nějak modifikoval. Pokud v takové situaci v dané službě uživatel už heslo změnil, protože ho k tomu jaksi někdo donutil (klidně i tak, že pouze inkrementálně změnil číslo na začátku nebo konci hesla), tak ta změna hesla pomůže...

Ano, můžeme tu rozabírat i situace, kdy si ten útočník s tím pohraje atd. pak... to ale také pomůže v situacích, kdy uživatel není tak líný, jak píšete a nebo mu nabídnete vhodné nástroje, popř. znemožníte tu jeho lenost při změnách hesla.

Netvrdím, že to pomůže vždy, ale securita přeci není o spásných opatřeních, která pomohou v každé situaci. Samozřejmě musím porovnat náklady a účinnost a zde může mít každý jiný názor.

Nijak neobhajuji NÚKIB, že to v té vyhlášce nechal povinně, mohl to nechat na jednotlivých organizacích a jejich manažerech KB, ale určitý smysl to má.