Cílem tohoto příspěvku je popsat, jak čelit APT útokům, především jak jim předcházet, jak je detekovat, jak se bránit, a jak postupovat v případě napadení.

Jestliže jsem v minulém příspěvku věnovanému popisu jednotlivých fází APT uvedl, že v první fázi, kdy dochází ke zjišťování informací a přípravě tohoto útoku, toho organizace nemůže mnoho dělat, tak bych chtěl nyní prohlásit, že už v této fázi jej lze detekovat a reagovat na něj.

Hned na úvod je nutné říci, že virtualizace a kontejnerizace řeší zcela jinou potřebu. Tyto technologie nestojí proti sobě, ale naopak se doplňují.

Z pohledu bezpečnosti řešíme problém, aby při napadení aplikace běžící v kontejneru/virtuálu nedošlo k napadení hostujícího OS nebo aplikace běžící v jiném kontejneru/virtuálu, a naopak aby při napadení hostujícího OS nedošlo k napadení aplikací běžících v jednotlivých kontejnerech/virtuálech.

Trh s roboty, konkrétně pak s těmi softwarovými, pro něž se již vžil pojem Robot Process Automation, zkr. RPA, roste.

Momentálně se na něm pohybuje nějakých 15 významných hráčů, kteří obsluhují několik tisíc klientů po celém světě. Ti jen za minulý rok vydělali prodejem RPA řešení několik stovek miliónů dolarů a očekávají další růst tržeb a to až o několik stovek procent ročně.

Organizace OWASP každý rok sestavuje žebříček nejčastějších slabin v testovaných aplikacích.

Ten byl po dobu několika let víceméně stejný, jen v něm docházelo k drobným změnám na jednotlivých pozicích, kdy si občas nějaké slabiny prostě jen vyměnily místo. Letos v něm však došlo k několika významným změnám.

Cílem tohoto příspěvku je zaujmout pokud možno objektivní stanovisko ke komiksu na XKCD, který porovnává odolnost hesla a passphrase vůči útoku hrubou silou.

Autor komiksu tvrdí, že passphrase je lepší než heslo, protože si ji uživatel mnohem snáze zapamatuje a nebude tak nucen si ji někam zapisovat. Jistě, ale bude ten samý uživatel schopen si vytvořit silnou passphrase a následně ji i několikrát za den zadat, aby se mohl přihlásit?

V jednom minulém příspěvku jsem popisoval, jak vytvořit bezpečné heslo a bezpečnou passphrase a kladl si otázku, zda je bezpečnější heslo nebo passphrase.

Abychom vůbec mohli porovnat odolnost klasického hesla o určité délce (L) a komplexitě (C) a passphrase vytvořené z určitého počtu slov (L) a nacházejících se ve slovníku o určité velikosti (C), tak musíme nejprve vyjádřit jejich entropii (En) v bitech. Tu spočteme pomocí následujícího vzorce:

Ke stávajícím úžasným technikám jako je Punycode, Ropemaker, nám přibyla další, tzv. ZeroFont.

Je neuvěřitelné, jak jsou tyhle staronové techniky účinné a jak jsou stávající řešení na detekci podvodných e-mailů bezbranné.

Slabina (weakness) a zranitelnost (vulnerability) není totéž. A byť tyto pojmy bývají dost často používány jako synonyma, znamenají oba něco trochu jiného.

Za slabinu je v informační a kybernetické bezpečnosti obecně považována jakákoliv chyba v architektuře, návrhu, kódu nebo implementaci, která může vést ke zranitelnosti přímo zneužitelné útočníkem.

Google přichází v souvislosti se stále oblíbenějšími biometrickými autentizačními metodami se dvěma zcela novými metrikami, které by měly podstatně přispět ke zvýšení jejich bezpečnosti.

K důvěrně známým metrikám jako je False Acceptance Rate, zkr. FAR a False Rejection Rate, zkr. FRR nově přibyly ještě metriky Imposter Accept Rate, zkr. IAR a Spoof Accept Rate, zkr. SAR.

Na Bug Bounty programy můžeme narazit u různých společnosti, zpravidla z oboru IT, jako je např. Google, Microsoft, Facebook, apod.

Takový Bug Bounty program funguje vcelku jednoduše. Najdete zranitelnost, nahlásíte ji dané firmě a ona vám za ní zaplatí. Jenže je tu několik úskalí, především pro firmu, co takový Bug Bounty program vyhlásí.