Testy BCP/DRP mohou být založeny na několika různých přístupech, od prosté revize plánu, přes simulaci výpadku až po skutečné plné přerušení provozu.

Každý test má své výhody a nevýhody, které jsou stručně popsány v tomto příspěvku. Nejčastěji se můžeme setkat s těmito typy testů:

Cyber resilience je tak trochu buzzword vyjadřující požadavek na zajištění odolnosti organizace vůči kybernetickým útokům, které by mohly narušit důvěrnost, integritu a dostupnost a ohrozit tak její misi a vizi.

V zásadě se vůbec nejedná o nic nového, nicméně dochází zde k určitému ne nepodstatnému myšlenkovému posunu a změně paradigmatu, kdy se již neptáme, zda k útoku vůbec dojde, ale spíš kdy k němu dojde a co budeme dělat, až taková situace nastane.

Pokud jste při hodnocení zranitelností byli zvyklí pracovat s Exploitability Subscore a Impact Subscore, tak pozor, v CVSSv3 je to trochu jinak.

Zatímco Base Subscore, zkr. BS se liší, ale ne až tak výrazně, tak zásadní rozdíl spočívá především v hodnocení vyjádřeném jako Exploitability Subscore, zkr. ES a Impact Subscore, zkr. IS.

Hned na úvod uveďme, že závažnost zranitelnost CVE-2019-6977 není kritická, nýbrž jen vysoká, jak je ostatně vidět i na odkazované stránce.

A riziko zneužití této zranitelnosti je v mnoha případech dokonce i nízké. Chcete-li vědět proč, pak čtěte dále.

Overlay malware se na platformě Android vyskytuje hojně už mnoho let.

Zatímco předchozí verze malware byly víceméně šířeny mailem jako přímý odkaz na stažení malware z neznámých zdrojů a graficky méně zdařilé, pak poslední verze a způsob útoku Android Overlay malware cca od září 2018 již vypadá jinak.

Backdoor, který de-facto představuje úmyslnou či neúmyslnou chybu se s určitou pravděpodobností nachází v každém komplexním systému.

Tato věta se může zdát nadnesená, ale vychází bohužel z reality, a to i kdybychom brali v úvahu jen odhalené a evidované zranitelnosti.

Princip fail open a fail closed popisuje, jak má systém, zpravidla nějaký síťový prvek, ale i operační systém, reagovat na chybu.

Rozhodnutí o tom, který přístup by měl být použit, by mělo vycházet z risk apetitu organizace, tedy zda je organizace ochotna tolerovat riziko nedostupnosti anebo případného napadení.

Jistě jste zaznamenali, že finální znění VoKB se nakonec příliš neliší od pracovní verze z dubna loňského roku.

V jedné podstatné věci však přeci jen liší, a tou je požadavek na délku hesla uživatele, kdy došlo k jeho zkrácení z navrhovaných 14 znaků na 12.

Je zřejmé, že i roboti budou dělat chyby a bude docházet ke škodám, stejně jako tomu je v případě lidských operátorů. Kdo však ponese odpovědnost?

Aby to nebylo tak jednoduché, tak podle současného právního řádu odpovědnost za škodu způsobenou věcí nese její uživatel, a pokud jej nelze určit, tak vlastník věci. Zároveň však platí, že pokud je škoda způsobena vadou výrobku, tak pak za ni odpovídá její výrobce. Všichni ale víme, jak je tomu u SW, a jak v takových případech rozhoduje soud, že.

NÚKIB včera vydal metodický pokyn k varování před kybernetickou bezpečnostní hrozbou v podobě produktů čínských společností Huawei a ZTE.

Tuto hrozbu NÚKIB hodnotí v souladu s metodikou uvedenou ve VoKB jako velmi pravděpodobnou až více méně jistou, tedy hrozbu kritickou, kdy předpokládaná realizace hrozby je častější než jednou za měsíc.