Vlákno názorů k článku Regulace podle NIS2: NÚKIB hodlá trestat přísně, u přestupků vyloučil ustanovení ve prospěch pachatele od RRŠ - Taky máte někdy pocit, že nám tu pomalu...
-
tam, kde je možné vysvětlení lidská hloupost, to zpravidla ta hloupost opravdu je.
Drtivá většina věcí co Núkib vyžaduje v novém ZoKB opravdu bezpečnost zvýší, jen toho zavádí příliš najednou, příliš násilně, ignorují (doslova) sporné části a zapomínají, že realizace může ukázat nové problémy, nesnaží se vyjít vstříc a vše jde na vrub firem, nedostatek lidí a času jim připadá jako nic. Z nějakého důvodu si myslí, že bezpečnost je binární a vše se musí zavést najednou a co nejpřísněji, neuznávají postupnou implementaci a snad i čekají, že to je konečné řešení a už se nebude měnit.
Ono už jen taková maličkost, že jedním z hlavním pilířů bezpečného systému je ideálně nula nalezených zranitelností automatickým skenem. Zranitelnost je v podstatě pouze to, co má CVE. No a databáze CVE jsou dnes rozbité, NIST přestal fungovat a dělá restrukturalizaci a ENISA ještě nefunguje. Už teď je to sakra papírování, když nám Qualys hlásí false positive a že toho hlásí tunu, přitom patří mezi ty lepší nástroje.
-
Především ty nástroje (Qualys...) pro automatické skenování hlásí kdejakou blbost, například dva dny zastaralý Google Chrome (
včera opravili CVE...
)... Každá středa po druhém úterý v měsíci znamená stovky nových zranitelných serverů, protože Microsoft uvolnil nové patche a ty se budou instalovat v průběhu týdne.
Kdybychom museli všechny tyhle maličkosti hlásit, tak pro samé vyplňování hlášení je nestačíme opravovat.
Podle toho se opravdu nedá bezpečnost infrastruktury reálně hodnotit. -
To je ale problem toho jak skenujete. Normalne oskenujes po vydani patchu, pak patchujes a oskenujes pred vydanim dalsich patchu kde si overis ze jsi ty patche implementoval. A pokud nebudes pouzivat zastaraly qualys(ty jejich reporty jsou snad z 1980) tak muzes mit agenta ktery ti zranitelnosti odreportuje, na to mit navazany deployment chybejicich patchu a ve finale jenom koukas na dashboardy a resis chyby. Jak si to udelas tak to mas.
3. 4. 2024, 04:05 editováno autorem komentáře
-
To je v pořádku, pak za měsíc výjde kumulativní patch, který přepíše všechny ty předchozí, ale Qualys o tom ještě neví a začne ti hlásit, že máš zase nezáplatovaný systém a doporučuje ti instalovat ten starý patch, protože zpětně (ještě) neupravil všechny své QID a nepřidal tam nový patch jako řešení.
Nebo máš dodavatele, který sice patchuje java závislosti, ale kvůli určitým důvodům správně neuvádí verzi do jar názvu souborů a Qualys zrovna kouká jen na ten název souboru uvnitř nějakého archivu.
Nebo pokud máš SW, který se skládá ze stovek modulů (např. konektory v Kafka Connect) a jeden z nich má zranitelnost, Qualys to hodí na celý produkt a křičí dokud ten produkt neaktualizuješ, ona ale aktualizace celého produktu není, jen konektoru, který ještě nepoužíváš.
Ve výsledku je to mravenční práce s přípravou sad QIDů pro skenování a ne vždy jí všichni dělají s pečlivostí a znalostí toho co skenují, naopak výsledky rádi intepretují všichni a Núkib se tím pořád ohání. Ztrácí se pak strašně moc času odůvodňováním rozporu s automatem, který má být spíše nástrojem než konečným auditem.
-
My si tohle nevybíráme: co nám mateřská firma předepsala, to tam jede.
A vlastně vůbec není důležité, jak kvalitní ten program je, protože ve výsledku z toho vylezou reporty, kde je co nesplněno, a ty se předhodí našim manažroutům, kteří nám pak dělají nohy, že tam nemáme samé nuly, protože oni jsou podle toho hodnocení svými nadřízenými, kteří tomu nerozumí vůbec, nechtějí tomu rozumět a odmítají řešit cokoliv, co není jednoznačné a snadno vyslovitelné číslo.
Na takové použití je opravu úplně jedno, jaký software máte... -
Kdyby jen objevil, já je žiju, bohužel si nevyberu, co používají klienti, takže se potkávám s Tanable Nessus, Rapid7, MS XDR.
Nessus také zrovna není výhra, víděl jsi jeho api a dokumentanci k němu? Zkoušel jsi jeho agendy spouštět na opravdu velkých serverech, kde běží databáze? Voloviny s hlášením zranitelného produktu, protože je na jednu jeho komponentu psané CVE má také (zrovna kafka connect vyskakuje jak přes kopírák). Neuástále řešení aktualizace agentů, jejich zasekávání, timeouty při stahování reportů přes api atd. atd. Je dost drahej, zejména, když toho člověk má opravdu hodně (desítky tisíc VM).
Nemluvě o tom, že Qualys se daleko lépe integruje do AWS/Azure, takže to tam klienti strkají.
Ono to je asi jedno, co se používá, podstata je v tom, že ty skeny jsou jistým způsobem nepřesné, výsledky se musí pečlivě intepretovat a rozhodně se podle nich nesmí dávat pokuty, jak to tak Núkib asi zamýšlí.
-
Kdyby to tak fungovalo... aspon u NUKIBu, ze ty patche se na servery jejich systemu nainstaluji v prubehu tydne. Zrovna tohle se zautomatizovat i da... no, oni k tomu nejsou schopni dokopat sveho dodavatele spoustu mesicu aspon jako one-shot na security patche pouzite distribuce ;-)
Se stejnym metrem ala prisnost a pokuty by takto mel prijit Kintr minimalne o vsechny bonusy na nekolik mesicu, protoze to viditelne neni schopny uridit a sve teorie neni schopen v praxi aplikovat ani na svou vlastni organizaci. A s nim dalsi, treba jisty Jakub, co tyhle diskuze take cte, ale uz radsi nikam nic nepise, protoze holt na ten bordel se objektivni omluva hleda jen tezko...
-
"patche a ty se budou instalovat v průběhu týdne"
A kdyz je nekdo takto aktivni, dopadne viz nize.
MS na to sice uz vydal nejaky extraburt, ale ten se treba pres wsus nestahne. Tudiz to klidne muze znamenat, ze firma v ramci sve bezpenostni politiky ... musi klidne i nekolikrat denne restartovat AD.
Mimochodem, zacalo se to ve vetsim resit az cca 14 dnu po vydani tech patchu, coz je prave ta lhuta, kdy se nejodvaznejsi admini odvazuji instalovat aktualizace prave na produkty MS. Do te doby cekaji, zda se neco podobneho nevyvrbi.
Pro uzivatele/firmy je totiz radove dulezitejsi, zda ten ci onen system funguje, nez to, zda obsahuje z drtive vetsiny ciste hypotetickou diru.
-
To je v podstatě nesmysl. Pokud to hodláte srovnávat s Роскомнадзор, tak tu máme spíš ČTÚ. Ze zákona ovšem ČTÚ neřeší obsah služeb el. komunikací a ochranu GDPR, jen se do toho snaží fušovat nezákonnými doporučeními a výzvami. Nekňub je daleko nebezpečnější orgán na jedno použití. Takový Roskomnadzor se například stará i ochranu osobních dat a ochranu osobnostních práv v informačním poli. Součástí práce je tedy i přístup k centrálnímu registru jmenných a IP adres pro případné blokování. Nicméně tento proces si nic nezadá s blokováním přístupu k informačním zdrojům, tak jak to dnes provádní MFČR, SÚKL, EK, které v rámci nařízení komise 2015/2120 provádí obdobné intervence. Svoboda slova je garantována ústavou RF, nejsou ale vyloučeny omezení vyplývající se zákazů, nebo zachování integrity a bezpečnosti členských států stejně jako v EU. Tím se nelišíme. Problém Nekňubu vzniká v momentě, kdy se tato intervenšní opatření odehrávají na národní úrovni. V RF je tato služba zavedena na federální úrovni a jednotliví oligarchové a regionální mafiáni na to nemají vliv. CO je zajímavá změna je například zákaz na reklamu na VPN sítě v RF, ale jejich samotné používání nezákonné není. Podobně to mají ale i s propagací tabákových a alkoholických nápojů.
ČLÁNKY DO MAILU