Názory k článku Regulace podle NIS2: Rozdělení telco firem podle množství provozovaných SIM karet z vyhlášek zmizelo

Je prokazano, ze periodicky vynucovane zmeny hesel bezpecnost nijak nezvysuji a rikaji to i NUKIBu ekvivalentni organizace, jako treba NIST v USA nebo NCSC v Anglii, rika to treba uz i Microsoft, najit toho lze za poslednich nekolik let spoustu. Ale holt nas urad v tomto zastydnul ve stoleti pary a porad si jede tu svou pisnicku a tlaci nesmyslne povinne zmeny, zastarale koncepty. Vubec jim nedochazi, ze tech hesel ma kazdy uzivatel desitky a ze svym pristupem bezpecnost snizuji. A je fuk, ze ta perioda je relativne dlouha.

Jediny motiv tady muze byt fakt, ze podobne blbosti se urednikum snadno kontroluji - vytahnou si svuj checklist a delaji si carky. Kontrolovat do hloubky, jak jsou hesla ulozena je pracnejsi a to se linym urednikum zjevne nechce resit. Coz doklada uz jen "oduvodneni", ze ty hashe hesel muzou uniknout a proto se "pry" musi jednou za cas zmenit. Ale s touhle zcela hloupou logikou radoby-bezpecnostnich expertu by clovek musel menit heslo kazdy tyden...kdy se beztak neresi pricina (spatne ukladani hesel v aplikacich), ale jen hypoteticke nasledky.

Přesně jako v tom vtipu

Zadejte nové heslo:
zelí

Heslo musí obsahovat více než 8 znaků
kyselý zelí

Heslo musí obsahovat alespoň jednu číslici
3 kyselý zelí

Heslo nesmí obsahovat diakritiku
3 kysely zeli

Heslo nesmí obsahovat mezery
3blbykyselyzeli

Heslo musí obsahovat alespoň jedno velké písmeno
3BLBYkyselyzeli

Heslo nesmí obsahovat více velkých písmen jdoucích po sobě
3BlbyKyselyZe­li,DejMiTenBlbej­Pristup

Heslo nesmí obsahovat interpunkci
TakTedJsemSeA­leUzFaktNastval3Blby­KyselyZeliDej­MiTenBlbejPris­tup

Omlouváme se, ale toto heslo už někdo používá. Vymyslete jiné!

Papirovy draci litaji o sto sest - ale jen tehdy, pokud je rec o cizich systemech. Jakmile dojde na samotny urad, tak pravidla co on stanovi druhym pro jine zda se uz neplati. Nebo cim nam NUKIB ospravedlni, ze jimi provozovany system nedodrzuje jejich vlastni vyhlasku? :-)

Ne, na NUKIBu nepremysli - jen hledaji zpusoby, jak vykazovat cinnost na poli kyberneticke bezpecnosti a pritom se u toho nenadrit. A to splnuje jednoduchy checklist, kde si muzou pri kontrole odskrtavat ano/ne.

Jo, ze si clovek zhodnoti rizika ke kazdemu systemu a umerne rizikum zvoli adekvatni opatreni u kazdeho systemu individualne - to proverovat by uz zase bylo moc prace.

Kdyby skutecne implementovali na sobe to, co sami vymysli, tak by se chovali jinak. Jo, mozna resi takove ty jednoduche veci, jako vynucene zmeny hesla skrze GPO ve Windows... ale cokoliv slozitejsiho na znalosti u nich uz kulha, lze souhlasit ze netusi nic o praktickych dopadech svych teoretickych napadu :-) A dost sazi na to, ze hlidace nikdo nehlida. Prece urad pres kyberbezpecnost te bezpecnosti rozumi, ty hlidat nemusime ;-)

On s tím ale kdysi NIST přišel, pak se to rozporovalo a došli k tomu, že to naopak bezpečnost snižuje (kdo by to byl čekal co?) :-)
Checklisty a papíry to je budoucnost. Už teď vidím samý nesmysl na ntou, který nic neřeší, ale papíroví draci lítají o sto šest.

Za klienta jsem se účastnil několika diskuzí, nikam to nevedlo. Klient má asi 2 000 aktivních síťových prvků, kde heslo pro lokální správu může být pouze 20 znaké, nepodařilo se nám vyjednat vyjímku, požadují 22 znaků pro technické účty a změnu po 18 měsících. Problém je, že tohle pravidlo se vztahuje na veškerá použitá hesla vč. tokenů či jiných přístupových údajů, které nemají 2FA.

Stejně tak se to vztahuje i na šifrovací klíče, které jsou součástí různých protokolů pro symetrické šifrování. Z diskuzí mě to připadá, že NÚKIB to zaměňuje. Tam je prostě celá bezpečnost na jejich pravidelné transparentní změně založena (probíhá to ale na pozadí, takže o tom nikdo neví), tady se ale bavíme o hodinách a ne měsících.

Už ten režim pomalu implementujeme a tohle je právě peklo, uživatelé mě nějak netrápí, tam jsou jiné cesty jak to udělat, aniž by uživatel tím trpěl a musel něco změnit (o tom jsme debatovali tady nedávno a nepochopili se), všechny ty ale technické účty, to je problém, u řady míst to nelze vůbec snadno automatizovat, jsou buď offline nebo to ty technologie neumožňují.

Prakticky to třeba znamená i pravidelnou změnu ftp přihlášení u hostingu nebo změnu hesla do databáze u Wordpressu, která se dělá ručně.

Stejný problém jsou třeba i různé přístupy per aplikace, které se dnes řeší párem application id a secret id jako nějaký dlouhý a-z0-9 řetězec (např. smtp účet u gmailu, přístup na s3 u aws), to nesplňuje požadavky. Stejný je problém po změně neumožnit 30 minut další změnu, což třeba u hesel k HW prvkům nelze vůbec dnes zajistit.

Mně někdy připadá, že si NÚKIB není vědom důsledků. Pravidlo se třeba týká i autorizačního token pro externí přístup do datových schránek, opět je nutné ho každý rok a půl změnit, nesplňuje podmínky na složitost a nelze změnu udělat jinak než aplikace odebrat a pak zase složitě přidat.

Ale sám vault potřebuje také admin přístup do databáze, aby tam mohl hesla měnit či generovat dočasné účty, změnit tohle heslo už právě nelze tak snadno a ne bez výpadku. Nebo můžeš mít hesla uložená ve Vaultu a při změně je tam aktualizovat, ale aplikace se ti do vaultu přihlašuje přes application id a secret id, které nesplňují pravidla pro hesla. Jsme v kruhu, který právě řeším.

S timhle vyjmecne nejak pocitaji. Aneb kdyz budete mit HW token typu Yubikey a prihlasovat se pomoci nej, problem nebude. Akorat je teda problem to dostat do vsech aplikaci :-) A samozrejme prusvih jsou treba ty technicke ucty - tedy ucty, ktere treba pouziva aplikace pro pristup do databaze. I tam budete heslo kazdy rok a pul povinne menit... coz bude sranda, jak ostatne je videt obcas i pri vymenach certifikatu, kdy pak trva i pulden, nez to nekdo da dohromady :-)

Jinak jsem si na github zapnul passkeys a jsem stastny jako blecha. Jsem zvedavy jak cesky urad bude v budoucnosti resit situaci ze system nebude mit zadna hesla, ale neco bezpečnějšího - pokutou ?

To vam ale univerzalne nevyresi vsechny situace. Aneb treba pristup k API treti strany, kde ten pristupovy token vam nejakym zpusobem generuje protistrana. Jasne ze jsou mista, kde vault fungovat bude ale to "se da" neplati univerzalne.

Nekomerční výzkumníci - již jsem se chtěl radovat, že vysoké školy nebudou spadat po nový zákon. Ale zůstaly tam explicitně vyjmenovány. A také gumová podmínka pro zařazení do režimu vyšších povinností "většina prováděných výzkumných projektů je financována z více než 50 % z veřejných zdrojů.".
Co znamená většina? Je to 50% nebo 80% nebo 95%? A které projekty se budou počítat (např. škola dostane institucionální podporu a z ní vytvoří x interních projektů - je to jeden projekt či x projektů?). A co když jeden rok splní podmínky pro vyšši povinnosti a následující ne. Nejspíše to skončí byrokratickým rozhodnutím úředníka NÚKIB bez možnosti odvolání (nevztahuje se na to správní řád ...).

Vlastní NIS2 se nevztahuje na vysoké školy, NIS2 pouze umožňuje členským státům rozšířít platnost i na vzdělávací instituce. NÚKIB je rovnou zařadil do režimu vyšších povinností.

Jedna věc mi vrtá hlavou....: jak se ta délka hesla dá reálně zkontrolovat?
Jasně, můžu mít systém, který běžnému uživateli nedovolí zadat slabé heslo, ale stále je možnost, že to heslo vygeneruji nějak bokem - a pokud to bdělý občan nenahlásí, podle hashe se to pozná stěží.

Samotne politiky pro hesla se vynucuji pri jejich zadani/zmene, to technicky resitelne je - aneb muzete se i dozvedet, ze heslo mate hustodemonsky krutoprisne. A samozrejme nastaveni takove politiky se kontroluje snadno :-)

passkey nesplňuje žádný z bodů přímo, protože klíč může být uložen nebezpečně. Buď to budeš brát jako OTP, takže to je nedostatečné nebo klíč jako heslo, takže vlastně bezpečné heslo, ale musíš to měnit co rok a půl.

pred par lety jsem si hral s hashicorp vault a zmenu hesla do databaze nastavil na 15 minut. Taky se da...

prakticky nedá, dokonce se často nedá snadno ani interně zjistit.

Všichni tady mluví o uživatelých, ale tyhle pravidla se budou vztahovat na veškerá hesla, tj. vč. hesel do databází, do switchů (které již s nějakými na štítku příjdou), do trezorů (kde jsou zpravidla číselná a není možné splnit požadavek na složitost), dokonce se to týká i hesel k čipovým vstupním kartičkám. Tady je i problém držet tu historii o změnách, aby se heslo neopakovalo.

Prokazuje se to formálně, tj. jestli je dálka evidována, jaká je průměrná, jak probíhá (a kde kontrola na délku a opakovatelnost). Ten, kdo udělá pravidla a systém a na vynucování se vykašle, nejspíš se to nemusí poznat (dokud nejde k úniku), ten kdo to chce řešit podle pravidel má problémy v jejich nerealizovatel­nosti.

Staci zkontrolovat dve veci - politikou vynucovanou delku hesla a politikou vynucovanou periodicitu zmeny. To udelate s papirovym checklistem v ruce. A urad tady neargumentuje bruteforce utoky... ale tim, ze vam muzou hypoteticky ty hashe uniknout. Ze kdyz se neco takoveho opravdu stane a hashe nekudy utecou, tak mate mnohem vetsi prusvih se prehlizi... a pak samozrejme ani ta zmena po 18 mesicich kriticky system rozhodne neochrani.

při registraci noveho uzivatele

Já už na to kašlu a koupíme si antivir KAV znova.

Tohle, ale nejde dělat bez malého výpadku, pokud ta databáze (nebo něco jiného) neumožňuje mít dvě různá hesla současně.

Už jsem se potkal se situací, že pravidla pro hesla byla natolik přísná a komplikovaná, že pro jejich změnu měli uživatelé extra aplikaci, která heslo nejprve validovala proti politikám, a pro jistotu neělo ani změnit heslo po stisku [ctrl]+[alt]+[del]­...
...ale napsat net user nebo passwd fungovalo - jen to obyčejný uživatel prostě neznal, nevěděl nebo nezkusil.
Ne, že by to umožnilo měkká hesla, ale přeci jen to bylo tak o dva řády použitelnější.

Chapu to narozdil od nekterych diskuteru tak, ze rec je o tom, japa bude ourad kontrolovat existujici hesla ....

A da se to, treba slovnik/bruteforce na ta kratka. Pokud se najde, ...

Co se tyce kontroly pri zadavani, tak ani to nemusi byt mozne, protoze pokud to ma fungovat spravne, nejaky srv kde je ulozeno, se open heslo nikdy nedovi, k tomu doputuje az nejaky hash. Je to tutiz na nejakem zdrojovem systemu, a ten toho nemusi byt, a v 99% ani neni, schopen.

Musel by existovat nejaky univerzalni jediny povine implementovany system, a ten jaksi neexistuje.