Je offshorig opravdu tak výhodný, jak se na první pohled zdá?

Pokud se např. rozhodnete přesunout své výpočetní středisko do jiné země z důvodů snížení nákladů na jeho provoz, měli byste výběru vhodné lokality věnovat nemalou pozornost a především si položit otázku, jaká je návratnost této investice a zda se vám to opravdu vyplatí.

Je možné nechat odpovědnost za kvalitu hesla zcela na uživateli nebo by to měl být systém, který by měl použití silného hesla vynucovat?

Jsme přesvědčeni, že na uživatele se nelze zcela spolehnout a že by systém sám měl kontrolovat, zda zadávané heslo obsahuje velká a malá písmena, čísla, speciální znaky a neobsahuje slova uvedená ve slovníku. Dále by měl systém kontrolovat, jakou má heslo délku, zda již nebylo uživatelem jednou použito nebo zda není jen drobnou obměnou hesla předchozího.

Cílem tohoto příspěvku je zamyslet se nad tím, jak stanovit hodnotu dopadu ve finančních jednotkách.

Chtěl bych předeslat, že hodnotu dopadu není možné stanovit přesně, protože ač jsou některé hodnoty, které do výpočtu celkové výše dopadu vstupují, dané, tak jsou zde i takové, u kterých je jejich výši nutné stanovit za použití statistických metod. První, co každého CIO napadne, je spočítat náklady na:

Je možné nahlížet na samotné zařízení, ze kterého uživatel přistupuje do aplikace, jako na autentizační faktor, kdy uživatel „něco má“?

Na internetu lze narazit na několik firem, které prosazují myšlenku využít samotného zařízení, ze kterého se uživatel hlásí, jako dalšího autentizačního faktoru. Bohužel většina z nich řešení, které nabízí, nazývá různě. Setkat se tak lze např. s pojmem Virtual token nebo CDI. Informace o tom, jak přesně jejich řešení fungují, však tyto firmy tají. Je zde patrný „security by obscurity“ přístup. Přitom princip, na jakém tato řešení fungují, je velice jednoduchý.

Co je to autentizace a jakými způsoby může proběhnout, jsme si uvedli již v prvním díle našeho seriálu.

Řekli jsme si, že autentizace může být založena na tom, že uživatel „něco ví“, „něco má“ nebo „něco je“. V dalších dílech jsme se pak věnovali jednotlivým autentizačním metodám. Dnes bychom mohli upřít svůj pohled směrem k vícefaktorové autentizaci.

Tvrdím, že přístup „security through obscurity“ nebo chcete-li „security by obscurity“ má své opodstatnění, byť je mnohými bezpečnostními experty kategoricky odmítán.

Samozřejmě, pokud by byla bezpečnost postavená jen na tomto opatření, jednalo by se o špatný přístup. Ovšem při budování vícevrstvé ochrany plní toto opatření nezanedbatelnou roli a celkovou bezpečnost zvyšuje.

Pokud máme zajistit bezpečnost dat během celého jejich životního cyklu a to jak v úložišti, při přenosů a během použití, musíme zavést vhodná bezpečnostní opatření.

Najít odpověď na otázku, která bezpečností opatření by měla být zavedena v konkrétním případě, není možné bez provedení analýzy rizik. Obecně ale platí, že by měla být zavedena minimálně ta opatření, která patří do základní sady opatření.

Myslíte si, že když úspěšně otestujete přechod na novou verzi systému a v rámci testování se neobjeví žádné problémy, že máte vyhráno?

Vězte, že problémy se obvykle objeví až po nějaké době používání a v některých případech jsou dokonce takového rázu, že není jiné cesty, než se zase vrátit k předchozí funkční verzi. Možná si teď říkáte, v čem je problém, máte přeci zpracovaný a otestovaný DRP a sekundární server pro případ výpadku. Nainstalujete na něj předchozí verzi, uživatele přesměrujete na něj a nikdo si ničeho ani nevšimne. 

Tento příspěvek se zabývá doporučením ohledně autentizace v internetovém bankovnictví, které před několika lety vydal FFIEC (Federal Financial Institutions Examination Council).

V dokumentu Guidance on Authentication in an Internet Banking Environment se uvádí, že finanční instituce by měly efektivně ověřovat identitu svých klientů a že finanční podvody a krádeže identit jsou často výsledkem používání jednofaktorové autentizace (ID a hesla), kterou FFIEC považuje za nevhodnou.

Je SIEM něco, čím bychom se měli vážně zabývat nebo je to jen další buzzword?

V počátcích informatiky nepředstavoval auditing a monitoring informačního systému téměř žádný problém, neboť každá organizace měla zpravidla jen jeden informační systém, ke kterému se uživatelé připojovali prostřednictvím terminálů a vytvářel se tak pouze jeden log. Správce takového systému pak nastavil, které události se mají do logu zaznamenávat, a log pak pravidelně vyhodnocoval.