V tomto příspěvku se dozvíte, proč by měl nést každý odpovědnost za stav svého počítače.

Pan Nápravník ve své zprávě říká, že takový lékař nebo právník počítačům nerozumí, a proto za bezpečnost svého počítače nemůže nést zodpovědnost a pozastavuje se nad tím, jak je možné, že se např. banky nebo státní orgány snaží své odpovědnosti zbavit a přenést ji na občany nebo své klienty. Jako příklad používá excelentní příměr, uživatel je řidič a počítač to je takové jeho auto.

V tomto příspěvku se dozvíte, kdo by měl vést vyšetřování závažných bezpečnostních incidentů a jakými pravomocemi a oprávněními v informačním systému by měl vyšetřovatel disponovat.

Způsob vedení vyšetřování závažného bezpečnostního incidentu, který má na svědomí vlastní zaměstnanec společnosti, vykazuje určité odlišnosti od způsobu vedení vyšetřování incidentu, který byl veden útočníkem mimo organizaci a jehož totožnost neznáme a ani netušíme.

V tomto příspěvku se dozvíte, co je to autentizace, jaké metody autentizace máme a jaké jsou jejich výhody a nevýhody.

V příspěvku nazvaném Informační bezpečnost jsme si řekli, že cílem informační bezpečnosti je zajistit důvěrnost, integritu a dostupnost informací během celého jejich životního cyklu. Základním předpokladem k zajištění důvěrnosti, integrity a dostupnosti informací je použití vhodné metody autentizace (authentication), která spočívá v ověření identity uživatele nebo stroje, dále jen entity.

Na první pohled se funkce Mimo kancelář nebo chcete-li Out of office jeví jako velice užitečná. Koneckonců je zabudovaná ve většině aplikací pro práci s elektronickou poštou, tak proč ji nepoužívat?

Z průzkumu, který jsme provedli, vyplynulo, že naprostá většina automatických odpovědí, které jsme analyzovali, obsahovala poměrně zajímavé informace.

Pokud máte funkční aplikaci a uživatelé jsou s ní spokojeni, tak všechny požadavky na nové vlastnosti zamítejte a nové vlastnosti nepřidávejte. Proč?

Protože aplikace by měla obsahovat jen ty vlastnosti, které jsou opravdu potřeba. Zaměřte se spíš na to, aby vám ty stávající vlastnosti fungovaly naprosto perfektně a obsluha vaší aplikace byla co nejjednodušší a nejintuitivnější. Jestliže musí uživatel absolvovat školení nebo číst nějaký manuál, aby vůbec mohl začít s vaší aplikací pracovat, znamená to, že někde je něco špatně.

Tento článek přináší odpověď na otázku, jak zajistit bezpečnost dat ve vývojovém, testovacím a produkčním prostředí a úspěšně zvládat rizika, která jsou s provozem těchto prostředí spojena.

Je třeba si uvědomit, že každý SW prochází zpravidla během svého vývoje několika různými prostředími. Běžně se jedná o vývojové, testovací a produkční prostředí. Vzhledem k tomu, že testovací prostředí se může ve velkých společnostech dále dělit na integrační a akceptační, jsme postaveni před poměrně nelehký úkol:

Co je to test status report? Jednoduše řečeno, jedná se o zprávu o výsledcích testování, kterou zpravidla Test manager předkládá vlastníkovi.

Stejně jako všechny ostatní dokumenty, které v rámci testování vzniknou, i tento dokument by měl obsahovat jednoznačný identifikátor. Vzhledem k tomu, že ne vždy se povede plán testování dodržet, mělo by se ve výsledné zprávě objevit, co přesně se testovalo a kdo, kdy, kde a jak testování prováděl. Jedině tak je možné splnit podmínku opakovatelnosti a měřitelnosti.

Společnost je v období krize velice zranitelná, její informační aktiva jsou více než kdy jindy ohrožena neboť výrazně roste riziko narušení důvěrnosti, integrity a dostupnosti dat ze strany vlastních zaměstnanců i konkurenčních firem.

Vzhledem k tomu, že v období krize obecně klesá poptávka po určitých produktech a službách, snaží se společnosti nabízet jen ty produkty a služby, o které je zájem a udržují jen takový stav zaměstnanců, aby byly schopny tuto poptávku uspokojit. Vyšší než nezbytně nutný počet zaměstnanců udržují jen kapitálově silné společnosti nebo ty, co jsou ochotni se dočasně spokojit s minimálním nebo žádným ziskem. Naprostá většina společnosti však nadbytečné zaměstnance propouští.

V tomto příspěvku se dozvíte, co je to defect management, jaký je životní cyklus defektu. Co je to test incident report a jaké informace by měl obsahovat.

Vzhledem k tomu, že ne vždy test projde, je potřeba mít definován závazný postup, jak tento stav řešit. Vznešeně se této činnosti říká defekt management (defect management). V podstatě jde o to určit, kdo, komu a jakým způsobem by měl defekty hlásit a jak by s nimi mělo být dále nakládáno. Pokud se nepoužívá na správu defektů žádný pokročilý SW nástroj, vytváří se tzv. test incident report, ve kterém by mělo být uvedeno:

V tomto krátkém příspěvku se dozvíte, k čemu slouží Testovací log a jaké informace by měl obsahovat.

Testovací log poskytuje informace o průběhu jednotlivých testů. Testovací log by měl mít jedinečný název, aby nedošlo k záměně s logem z jiných testů, z jiného časového období nebo od jiného testera.