Názory k článku Regulace podle NIS2: Řízení rizik počítá s analýzou logů, pomohou nástroje SIEM

Krasne se nam tu s temi SIEMy uzavira kruh. Podle americkeho NIST a nebo i anglickeho NCSC smernic by spravce nemel nutit sve uzivatele periodicky menit hesla, pokud k tomu neni objektivni duvod - tedy realny incident. Coz je presne duvod, proc se SIEMy zavadi.

NUKIB tohle boharovne ignoruje, je "chytrejsi" nez NIST i NCSC a tvrdi nam, ze na periodickych zmenach je nutne lpet, protoze subjekty se zpravidla nijak aktivne nezajimaji o to, zdali jejich hesla byla kompromitovana. Aneb nuti vas implementovat SIEM - ale rovnou predjima, ze SIEM nebude fungovat :D

Vysledkem bude krasny bezpecnostni kockopes - ktery jako celek vetsi bezpecnost znamenat nebude. Je davno prokazany presny opak - periodicky vynucovane zmeny hesel bezpecnost naopak snizuji. Dobre to vedi v NISTu i v NCSC - jenze tam se bezpecnosti skutecne zajimaji a nefunguji jen jako byrokracii opevevneny urad, ktery to hlavne chce mit jednoduche pro sebe a svou cinnost. Aneb borec, co prijde na kontrolu s checklistem... mas SIEM, mas politiku nutici lidi zmenit hesla? Ano, ne... jo, ty hesla nenutis lidi menit (i kdyz mas SIEM, co problemy detekuje) a nechces tyhle blbosti delat? Tumas pokuticku... :-)

Ale pak se ve vysledku divime, ze v tyhle zemi nikdo pricetny fungovat nechce. Chteli by mozkovnu, ale podobnymi nesmysly mozky ze zeme spise vyhani pryc do mist, kde nemaji urady takto utrzene z retezu... :-)

na periodické změně hesla je naopak celá IT bezpečnost založena.

Než frekvence změn měn třeba trápí povinnost mít 22 znaká hesla pro technické účty, spravujeme řadu síťových prvků, které nedovolí mít heslo více než 20 znaků (to jsou hesla pro lokální management, nikoliv vzdálený).

NIST (800-63-3) pořád doporučuje mít politiku pro pravidelnou změnu hesla (jednou ročně) a daleko více tlačí na to, aby se řádně a lépe sledovalo vše kolem hesel (výskyt v databázích, zero knowledge, audit použití, omezování počet pokusů atd.).

To rikaji jen ti, co vubec nesleduji trendy... ale co uz, Cesko, respektive nekteri radoby-bezpecaci holt mentalne zamrzli ve stoleti pary :-) Neverite?

https://www.ncsc.gov.uk/collection/passwords/updating-your-approach
https://www.packetlabs.net/posts/periodic-password-changes/
https://arstechnica.com/information-technology/2019/06/microsoft-says-mandatory-password-changing-is-ancient-and-obsolete/
https://gkaccess.com/why-password-change-requirements-are-bad/
https://www.ftc.gov/policy/advocacy-research/tech-at-ftc/2016/03/time-rethink-mandatory-password-changes
https://www.getanp.com/blog/5/why-forcing-frequent-password-changes-is-actually-harmful-for-security.php

Navic i ten NIST jste si precetl blbe, cituji z clanku 5.1.1.2 NIST SP 800-63B:
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.

SHOULD NOT znamena, ze byste to delat nemel... a spousta tech odkazanych textu vyse to narozdil od vas reflektuje... :D

Je dulezite casto menit hesla. Mame na stole pod sklem papirek, kde se nekolikrat do roka napise dalsi dlouhe bezpecne heslo splnujici vse co spravne heslo ma mit.
Na displeji je zobrazena tabulka s analyzou vyroby a pokud se do deseti minut nehne mysi( k cemu neni duvod), system se zamkne a je treba zadat toto heslo. Vse je vyreseno tak, ze na pozadi ve smycce bezi video a brani uzamknuti systemu (rada z vypocetniho strediska).

Ad: na pozadi ve smycce bezi video a brani uzamknuti systemu.
To jsme používali přesně do doby, než nám sebrali videopřehrávač a zakázali spouštět jiné, než nainstalované programy. Pak nastoupil powershellový script...
...který fungoval do okamžiku, kdy zakázali spouštět scripty a baťáky.
Takže jsme si museli pomoct jinak. ;o)

čti to celé a ne jen kousky, vždyť i na tebou poskytnutých odkazech píšou o třeba roční změně hesla.

NIST tam přidává spousty podmínek navíc, opětovné přihlášení po 30 dnech, kontrola na úniky, práce s logy a zámky, geolokace, captcha atd. atd. Jakmile z nějakých důvodů nejsem schopný ten mix dodržet, musím hejbat s jinými parametry, aby celek měl určitou bezpečnost a ne si ztoho vytahovat jediný údaj (periodicita změny hesla) a celou argumentaci založit nad tím.

Jinak NIST výrazně tlačí na nepoužívá hesel jako hesel či obecně nepředávání hesel třetí straně (aplikaci, kam se přihlašuji), pak se dá bavit i o delším intervalu. Tady v CZ se ustalujeme na cca 1 - 3 roční platnosti hesla, podle prostředí. Naštěstí ty měsíční změny jsou už většinou pryč snad všude.

Osobní útoky si nech stranou, prosím.

Já jsem narážel třeba na perfect forward secrecy, který tvoří středobod bezpečné komunikace pravidelnou změnou klíčů pro symetrické šifrování.

Toto neni kandidat, ale rovnou vitez "blabol milenia".

Password0) ... priklad dokonale bezpecneho hesla ktere projde prakticky naprosto vzdy pres vsechny kontroly bezpecnosti hesla...

Pokud se heslo bude muset menit, bude to vypadat tak, ze abych si nemuzel pamatovat kolikrat sem ho uz menil

Password2023)

Vivat bezpecnost!

A presne takto vynucene menena hesla vypadaji, naprosto vzdy a naprosto vsude!

A copak je ten (povinny) SIEM? Aha, kontrola na uniky, prace s logy... :-) Tak bud zustaneme ve stoleti pary a budeme lidi nutit periodicky menit hesla se vsemi negativnimi dusledky, co to ma (hesla na papirkach, ne to se vubec nedeje) - to je z pohledu "bezpecaka" samozrejme jednodussi cesta, moc se u toho nenadre :-) A nebo ten bezpecak poradne naimplementuje SIEM... a bude poradne delat praci, za kterou je placen (a nikoliv hledat cesty, jak se u sve prace moc nenadrit). Lenost tech pseudo-bezpecaku je skutecny problem - kde ale obeti jejich prezentovane lenosti je koncovy uzivatel.

NUKIB tam cpe 18 mesicu, to znamena ze i s triletou periodicitou u sebe budete mit uz formalni problem. A samozrejme se vzdycky nekde najde blbec, co tu periodu zkrati - protoze jinej blbec nekde rekl, ze nutit lidi k periodickym zmenam bezpecnost pry zvysi, rikali to... :-) Protoze NUKIB samozrejme v tech vyhlaskach urcuje jen horni mez - ale spodni tam neni a je na uvazeni kazdeho soudruha. Problem je samozrejme i to, ze si vsichni hraji tak, jakoby se ten koncovy uzivatel hlasil jen k jednomu systemu, mel jedno heslo. Kazdy smrtelnik jich dnes ma desitky... a treba u datovych schranek je ta perioda vynucene zmeny hesla nastavena na krasnych 90 dni presne.

A cely problem tady je take v tom, ze tady urad striktne rika, co mam delat - aniz by skutecne znal soubor mych bezpecnostnich opatreni. Protoze ono vzit ten vyse zmineny checklist a na papiru si delat carky je pro byrokrata snazsi, nez skutecne ty systemy prolezt a podivat se, jak se bezpecnost fakticky resena. Pujde se jen po papirech, dopadne to jak s BOZP - jen formalisticka bezpecnost.

No papir snese vsechno :-) A skonci to ala RSD, ktere se take pysnilo certifikaci dle ISO 27001, ze? :-) A najednou error, data fuc... :-)

SIEM je abstraktní pojem, každý dělá něco jiného. Žádný SIEM, který jsme implementovali přímo neřeší kontrolu na úniky hesel, může to být pro něj ale jeden ze vstupů jako jakýkoliv jiný event.

Ani těch 18 měsíců není nepřekonatelný parametr, pořád tady můžeš udělat prohlášení o aplikovatelnosti, zohlednit to v systému řízení rizik a řádně odůvodnit, pak si to můžeš nastavit podle svých obhajitelných představ, tak to i děláme a dělat budeme. Ne všechny systémy, které navrhuji spadají a budou spadat pod NÚKIB.

Kdybys pozorně četl celý ten NIST, viděl bys tam poměrně rozsáhl diskuzi a odůvodně, není to jen o tom, že přestaneš expirovat hesla, ale že vyřešíš ty problémy, které vedly k nastavení platnosti hesla. Pořád to je doporučení a musíš to číst jako celek, ne si z toho vyzobávat třešničky.

Jsou tady i důvody, které NIST nepokrývá a to je třeba problém přehešování dlouho nepoužitých hesel a tak se často volí kompromis v podobě rozumného dlouhé období.

Každopádně i těch 18 měsíců dalo dost práce s argumentací a vyjednávání, bohužel tohle je spíše politická než technická otázka. Já raději energii věnuji minimalizaci systémů, kam heslo musím zadávat (čti SSO), v tomhle se udělal třeba v bankovním prostředí za poslední roky neskutečný pokrok. A také se soustředí na prodloužení délky sezení, aby každý zaměstnanec nemusel svoje hlavní heslo zadávat několikrát denně před očima spousty lidí a kamer, pak ztrácí obestřetnost, nahrazujeme to piny nebo jen 2FA pro obnovení sezení jednou za pár dní. A v tomhle jsem rád, že do toho nezačal NÚKIB víc vrtat, to má potenciál daleko více zpříjemnit prožitek pro uživatele a zvýšit bezpečnost než se hádat o expiraci hesla.

Mimochodem, u datovek to můžeš vypnout a pak ti nechají heslo neomezeně dlouho.

Dělám vyloženě i zahraniční projekty přímo pro zahraniční klienty, tam NÚKIB nešahá, tam je zase jen jiný "NÚKIB" a vlastně nejsou moc rozdílní.

Ano, s tím, že tam spadne vše nesouhlasím a to bude velká třecí plocha, protože nikdo zatím nevyčíslil náklady, jakmile je vyčíslí aspoň úřady, budou to asi na vládě stejně měnit. Klienti se na to ale už připravují, přesouvají aktiva do dceřiných společností a zavádějí smluvní vztah dodavatel<>od­běratel.

S tím souhlasím, to bude šílené papírování. Také obecně se nám ty bezpečnostní týmy rozdělily na dva, jeden jsou papírovači bez znalosti hard skills, zato se znalostí procesů a legislativy. Druhý tým jsou zase hard skilled kluci/holky, kteří reálně problémy řeší. Jinak to ani nepůjde. Já se řadím do toho druhého, ale projektově musím s prvním komunikovat.

V případě kontroly asi nechceš ověřovat, jestli zrovna tenhle sestavený balíček má aplikovanou konkrétní záplatu, ale chceš vidět graf jak rychle se která zranitelnost vyřešila a kolik jich ještě svítí, jestli se to vůbec sleduje. Běžně zabere 1 - 2 FTE třeba jen probíráním se Qualys skenů, rozebíráním false positive, komentováním, nastavením pravidel. Tohle malé úřady a firmy ubije.

NÚKIB (a ani nikdo obecně) ti nebude dělat kontrolu, jestli jsi tenhle kokrétní server restartovat po aktualizaci nebo jen aktualizoval, ale bude se kontrolovat, jestli se dělá pravidelně aktualizace, jestli se pravidelně sledují zranitelnosti, jestli se systémy reskenují, jestli se objevují již jednou vyřešené věci, jestli je někdo, kdo to validuje, jestli existuje školení a předávání znalostí, jestli funguje dobře směnný provoz, jestli mají všichni potřebné kontakty atd. atd. Pro stát to je jednodušší (přístup ala hygiena s týmem v terénu a vlastní laboratoří asi čekat nemůžeme, tady bude přístup ala stavební úřad, pouze z kanceláře).

To s temi systemy prave neni pravdive - NUKIB si to v ramci zjednodusovani sve prace pri transpozici NIS2 nastavil tak, ze kdyz spadne organizaci byt jen jedine aktivum do rezimu vyssich povinnosti, pak do toho razem spadnou systemy vsechny. Protoze je pro urad systemem vyssi bere jednodussi aplikovat kriteria na celou organizaci a vsechny jeji systemy a nikoliv jen na konkretni skutecne kriticky system takto identifikovany (aneb odpadne rozlisovani toho, co kriticke je a co ne). Proste klasika - mit to jednoduche pro urad, zato z toho udelat pakarnu pro povinnou osobu.

U datovek to sice vypnout muzu, ale pak ve smyslu tech politik z NUKIBu uz nebudu compliant. Uz vidim, jak prijde kontrola a v ramci auditu si necha zrovna tohle policko ukazat... :D Presne veci, co se kontroluji (a sankcionuji) snadno. Zato do hloubky proverit treba uz jen to, cimze se ty hesla teda realne hashuji da uz podstatne vic prace. A zkouset bruteforce na unikle Argon2, no to vam preju hodne stesti a pevne nervy... :D Stejne tak do hloubky proverit, jestli v te kriticke infrastrukture jsou skutecne aplikovane vsechny nutne bezpecnostni zaplaty, to opet da vic prace. Ne, skonci to u te kontroly papiru a veci, co jsou na prvni pohled lehce videt ;-) Takova ta bezpecnost... jen naoko. Na papire. A ostatne i stav nekterych verejne dostupnych systemu kyberuradu dava tusit, jak moc tam bezpecnost zvladaji - kovarova kobyla chodi bosa.

Tak ISO 27001 je o implementaci řízení rizik, ISMS, nezaručuje, že systém nemám zranitelnost nebo není špatně navržený. I T-mobile má ISO 27001 a stejně si nechá jedno diskové pole a příjde o data při jeho havárii, to ale není v rozporu s ISO 27001. To je dost nepochopení co ta certifikace zaručuje.

Reálná bezpečnost se zajišťuje a ověřuje jinak. To, co se stalo ŘSD není vlastně nic, co by nemohlo postihnout ostatní, zákony, normy a legislativa tenhle stav neřeší, ne dostatečně. Však i sám si opakovaně stěžuješ, že bys čekal, že právě NÚKIB bude řešit tu reálnou bezpečnost, bude sdílet informace a pomáhat s mitigací probíhajících útoků.

Ale tak přece ISO27001 a ani NIS2 ti nezaručí, že máš systém bezpečný, ale jen to, že se k němu bezpečně a odpovědně chováš, tj. že v rámci BAU na to nekašleš, ale už to nic neříká o kvalitě nebo úplnosti. To je dobré pro manažery a politiky, že udělali nutný krok k bezpečnosti, nikoliv ale postačující krok.

Sjednotí se aspoň způsob fungování jednotlivých firem a týmů.

Já to beru jako první z kroků, které mají prostředí narovnat. Když se podívám na jiné obory, jak to funguje, kromě spousty předpisů, norem tady máš státní zkušební ústavy, které ověřují soulad konkrétních výrobků, strojů, staveb, produktů. Tam ty zkoušky jsou někdy dost zevrubné (např. krásná hydraulická mučírna pro vlaky ve VUZ Velim).

Máme něco takového v IT? Existuje Státní zkušenobní ústav bezpečnosti IT systému, s. p.? No, neexistuje a zatím se to ani legislativně neřeší. Máme tady jen obecné normy v prvních, druhých verzích a asi se čeká, co s tím obor udělá sám.

NIS2 může reálně zvednout bezpečnost u subjektů, které doteď žádné takové procesy neměly a dávaly tomu volné ruce (nebudu tady raději konkrétně jmenovat naší největší soukromou televizní stanici), ale ti co to už teď berou vážně jsou prakticky v implementaci mnohem dál.

Expirace hesla po 18 měsících beru za minoritu, je škoda, že tam ten údaj vůbec je, ale netrápí mě tolik jako jiné body. Není závazný, když si změnu obhájíš a pokud víš co děláš, změnu si obhájíš, však i teď ty doporučené expirace neplníme všude.

Ano, mame treba taky inspektorat prace... a kazdy, kdo nekdy nekde pracoval vi, jak to v praxi s BOZP chodi, ze? :-) To se take bavime o bezpecnosti, primo te fyzicke - pri praci. Myslenka NIS2 spatna neni, spatna je narodni transpozice - ktera z toho ten system ala BOZP proste udela. A jak uz to byva, cesta do pekel byva dlazdena dobrym umyslem ;-)

Navic se bavime o regulaci, co se dotkne jen nekolika vybranych subjektu. Rozhodne nejde o plosne reseni bezpecnosti. A sam jste tu popsal, jak lavirujete kolem toho, abyste se tem povinnostem nekde vyhnuli ;-) Z druhe strany ale nektere subjekty pod tu regulaci spadaji uz dnes - a rozhodne nelze rict, ze by si tam co do kyberneticke bezpecnosti vzdy pocinali skvele, zvlast pokud se bavime o IT ve statni sprave...

A pokud NUKIB selhava u mensiho mnozstvi regulovanych subjektu, vazne verite tomu, ze kdyz tech subjektu z moci uredni urcite vic, tak to zacne magicky fungovat lip? :-)

NUKIB casto verejnost chlacholi tim, ze pokud mate ISO 27001, tak organizace naplni velkou cast organizacnich a technickych opatreni ze smernice NIS2. A samozrejme co rikate plati i v pripade samotne NIS2, resp. jeji transpozice do naseho pravniho radu :-) A zvyseni bezpecnosti je argument, co se zde uziva.

A co se sdileni informaci tyce, to nefunguje - NUKIB se ochotne vymluvi na to, ze mimo svou konstituenci sdilet informace nemusi, takze to ani nedela. A treba zrovna prubeh utoku NoName057(16) naplno ukazal, ze informace napomahajici mitigaci utoku proste neprichazi. Kazdej se s tim musel poprat sam... vysledkem bylo, ze padaly banky a weby dalsich i statnich instituci jako svestky ;-) Opet... moc prace pro urad.

Obcas neco vydaji - ale ty upozorneni jsou jak mesic stary noviny - a nekdo si dal praci a peclive to zanalyzoval. A tim, ze se okruh povinnych osob dost zvysi nejde ocekavat, ze by se to zlepsilo, spis to bude horsi a vymluvi se na nedostatek lidi. Protoze urad se sam primarne utopi v kontrole toho, ze na papire splnujete vse co mate, to na uradech zvladaji skvele :-) Ale srovnejte si takovy infoservis americke CISA s tim, jak "informuje" nas kyberurad...