V poslední době lze zaznamenat zvýšený počet útoků na zaměstnance organizací, které svou komunikaci přesunuly do O365.

Ostatně Microsoft se stal díky O365 nejoblíbenější značkou mezi útočníky, kteří sázejí na phishing, a není se čemu divit, když počet firem a uživatelů v O365 roste raketovým tempem a útočník pak může ze zkompromitovaného účtu zaútočit prakticky na kohokoliv.

Je žádoucí, aby byl systém, který je součástí kritické informační infrastruktury státu provozován v public cloudu umístěném kdesi ve světě, tedy mimo území České republiky?

Odpověď kompetentních orgánů se teď zatím nese v duchu, pokud to bude zabezpečeno stejně, jako kdyby to bylo v datovém centru v ČR, tak s tím nemáme problém. Což o to, ono to možná bude zabezpečeno v některých případech i lépe, jenže problém je někde zcela jinde.

Dle Mary T. Franz z Enterprise Knowledge Partners je zde patrný určitý vzorec chování rozpoznatelný i napříč odvětvími.

Po hacku nebo úniku informací se zvýší rozpočet na bezpečnost, implementují se příslušná opatření, a když už jsou všechna opatření zavedena, tak se opět rozpočet na bezpečnost drasticky sníží.

Je zřejmé, že v okamžiku, kdy jsme zahlceni tisíci zranitelnostmi ročně, tak není možné najednou odstranit úplně všechny, a je nutné se zaměřit jen na některé z nich.

Při řízení technických zranitelností však platí jisté zákonitosti. Ty byly formulovány již v roce 2004 společností Qualys na základě dat získaných od zákazníků používajících jejich skener zranitelností. Tyto zákonitosti jsou známy pod názvem „The Laws of Vulnerabilities“ neboli „Zákony zranitelností“.

Common Weakness Risk Analysis Framework, zkr. CWRAF spravovaný organizací MITRE by měl umožňovat hodnocení závažnosti slabin s ohledem na to, v jakém odvětví daná organizace působí a za jakým účelem daný produkt obsahující slabinu používá.

CWRAF nám pomáhá stanovit hodnotu tzv. technického dopadu (Technical Impact, zkr. TI), který je jedním z klíčových faktorů používaným v hodnocení slabin CWE dle CWSS.

Když jsem načal v předchozím článku problematiku penetračních testů v otázce (zne)užívání jejich výsledků, bylo to jako říct B ale neříct A, … takže ještě pár vět k tomu A, tj. k čemu by penetrační testy měly být a jak by měly být provedeny.

Penetrační test je dost často omezen jen na jeden konkrétní systém a jsou dány jasné hranice systému, které tester nesmí překročit.

Indikátory kompromitace (Indicators of Compromise, zkr. IoC), jak již název napovídá, by měly sloužit k identifikaci kompromitovaného zařízení.

Tedy zařízení, kterým může být stejně tak server, jako pracovní stanice, notebook, tablet, mobilní telefon anebo síťový prvek.

S pojmy false positive a false negative se nejčastěji setkáme při hodnocení bezpečnostních řešení.

Někdy se můžeme rovněž setkat s pojmem type I error a type II error. Připomeňme si nejprve, co tyto pojmy znamenají.

Médii se prohnala zpráva, že Microsoft mění bezpečnostní politiku hesel a nebude již na systémech Windows 10 a serverech od verze 1903 vynucovat změnu hesla.

Toto prohlášení bylo zveřejněné na webu Microsoftu a setkalo se vesměs s pozitivní reakcí ze strany odborné i laické veřejnosti, nicméně je třeba upozornit na určité skutečnosti.

Řízení zranitelností (vulnerability management) probíhá v několika fázích, zpravidla čtyřech: identifikace, vyhodnocení, zvládání a kontrola.

Těmto fázím musí předcházet rozhodnutí o tom, jakým nástrojem, rozuměj skenerem zranitelností, v jakých intervalech, a jaké adresy budou skenovány, a jak se bude na jím zjištěné zranitelnosti následně reagovat. Netřeba snad dodávat, že i toto rozhodnutí je třeba pravidelně revidovat.