Skutečně dobrý nápad je především záležitostí správného načasování. Vezměme si například ten, se kterým za mnou minulý týden přišel vedoucí oddělení řízení projektů.
Jeho doporučení, jak zvládnout požadavky na zabezpečení u nových projektů, by mi před rokem připadalo jako neproveditelné. V podstatě tvrdil, že bychom všichni mohli ušetřit mnoho času, pokud bychom zdokumentovali všechna bezpečnostní opatření, které by můj tým teoreticky mohl požadovat ještě před tím, než by mohl být libovolný nový IT projekt spuštěn do ostrého provozu.
Je pravda, že naše oddělení je zavaleno prací na projektech a strávili jsme pořádný kus času sezením na různých projektových poradách se zástupci z mnoha jiných IT oddělení a pokoušeli se pochopit technickou architekturu a promyslet vše potřebné, aby byl projekt rozumně zabezpečen. Nicméně nebýt nedávných událostí, pravděpodobně bych nad tímto nápadem pokrčil rameny a držel se dále přesvědčení, že musíme plně pochopit, co se podnik snaží udělat, předtím, než můžeme stanovit, jak to má udělat s ohledem na ochranu.
Změnilo se samozřejmě tím, že jsme jakožto tým zabezpečení prošli zároveň s oddělením IT výraznou redukcí personálu. Musíme se zbytkem lidí udělat to nejlepší, co se dá. Tento nápad ukázal minimálně jeden způsob, jak to provést. Po dalším přemýšlení jsem si uvědomil, že skutečně máme sadu docela konzistentních zabezpečovacích požadavků pro specifické oblasti.
Pokud například projekt zahrnuje informace, jež dovolují identifikovat konkrétní osoby, vždy to vede k nasazení jedné metody zabezpečení – k šifrování. Neustále však zjišťujeme, že musíme potřebu kódování dat odůvodňovat. Pokud tedy standardizujeme své požadavky na šifrování pro informace s možnosti osobní identifikace, může se nám podařit zkrátit některé diskuse na minimum.
Začneme třeba s pravidly, standardy a směrnicemi, které se týkají osobních údajů, přejít pak na naše interní zásady zabezpečení a potom říci, kde a kdy bude šifrování potřebné. Kódování souborů i přenosů informací lze těmito požadavky pokrýt v závislosti na tom, kde a jak jsou příslušná data uložena a kde jsou vyslána a přijata.
Zajištění základů
Aby se z toho udělalo něco, co by mohli naši projektoví manažeři použít jako obecnou příručku, budu muset promyslet všechny možné kombinace klasifikací dat, transportních typů či umístění úložišť a také rozepsat, co se má ve kterém případě udělat.
Pokud například projekt zahrnuje důvěrná data posílaná přes internet z příslušné databáze do webového prohlížeče, bude standardním požadavkem šifrování databáze a k tomu použití protokolu SSL.
S uspokojením zjišťuji, že vytvoření výsledné sady obecných požadavků bylo nakonec o něco snadnější, než jsem původně očekával. Už mám dokončeny požadavky na zabezpečení pro oblasti jako je ověřování, autorizace, řízení přístupu nebo obnovení systému. Odezva od našeho oddělení řízení projektů byla velmi kladná.
Začíná to vypadat, že tímto způsobem nakonec pokryjeme větší oblast, než by se podařilo vysíláním člena týmu na poradu ke každému projektu a požadavkem, aby tato osoba vše řešila za pochodu.
Těžké časy někdy vyžadují nové způsoby myšlení a také vás mohou příznivěji naladit vůči různým postřehům či nápadům. Standardizace našich požadavků zabezpečení by měla ušetřit čas při diskusi o projektu a poskytnout konzistentnější i srozumitelnější základ projektovým manažerům a personálu IT, aby s námi spolupracovali při zvyšování ochrany implementací našich technologií.