Naše systémy jsou sledovány množstvím skriptů

Termín pro splnění požadavků zákona Sarbanes-Oxley je zde. Dokončujeme přípravy na potřebné testy. Protože neust


Termín pro splnění požadavků zákona Sarbanes-Oxley je zde. Dokončujeme přípravy
na potřebné testy.
Protože neustále dostávám velké množství e-mailů, ve kterých se mě pisatelé
ptají na zákon Sarbanes-Oxley, rozhodl jsem se věnovat mu další příspěvek.
Zajímavé pro mně přitom je, že zájem projevují i odborníci zdánlivě mimo dosah
zákona například z Evropy. Je to často proto, že pracují v zahraniční pobočce
americké firmy, nebo proto, že chtějí dát splněním podmínek zákona najevo, že
jsou důvěryhodným partnerem.
Před několika měsíci jsem se zúčastnil setkání se zástupci našich týmů z
oblastí sítí, provozů datových center, databázového a aplikačního inženýrství,
správy Unixu i Windows NT a dalších skupin. Cílem bylo prodiskutovat regulační
cíle pro jednotlivé oblasti. Pro snadnější identifikaci úkolů jsme používali
technologii COBIT (Control Objectives for Information and Related Technology).
Nabízí rámec, směrnice i některé implementační nástroje, které mají vést
společnosti správným směrem.

Hledání cíle
Nejprve jsme se museli zamyslet nad tím, kterými systémy bychom se vlastně měli
zabývat. Naše společnost má více než 500 produkčních unixových serverů a
několik stovek NT serverů, na kterých jsou provozovány různé aplikace. Přitom
neexistuje způsob, jak bychom mohli efektivně otestovat více než 700 serverů.
Protože se Sarbanes-Oxley zaměřuje na finance, vypracovali jsme seznam systémů,
jež mají vliv na naše finanční výkaznictví. Seznam více než 700 serverů se
scvrkl na přehled necelé stovky. Následně jsme je rozdělili do kategorií podle
aplikací, což nám mělo usnadnit zvládnutí pracovního zatížení. Jakmile jsme
formálně schválili cíle, nebylo už samotné testování vůbec komplikované. Jeden
cíl kontroly související s databází Oracle by například mohl znít: "Uživatelé
nesmějí přistupovat do databáze Oracle přímo pomocí ID v této aplikaci nebo
přes standardní účet." Abychom mohli určit, kdo má přístup na server a do
databáze, bylo nutné přezkoumat určité parametry v konfiguračním souboru
databáze Oracle a účtů unixových uživatelů. Vzhledem k tomu, že máme v našem
prostředí tucty serverů Oracle a úkolem je provést 32 testů, bylo smysluplné
spustit na všech serverech skript, který by získal informace z konfiguračních
souborů.
U Oraclu bylo možné nalézt výsledky testů buď v souboru init.ora nebo
listener.ora. Vývoj skriptu chvíli trval, ale nakonec jsme získali snadno
opakovatelnou metodu pro testování našeho prostředí s uvedenými servery.

Na Unix
U unixových serverů by cíl kontroly mohl znít: "Uživatelská hesla je nutné
měnit každých 90 dní." Zde by test vyhodnotil soubor /etc/default/password u
všech unixových serverů a zjistil by, zda je parametr "MAXWEEKS" nastaven na 90
dní. Protože bylo potřeba provést 25 testů na několika tuctech serverů,
vyvinuli jsme další skript. Test zahrnoval otevření konfiguračních souborů,
kontrolu práv pro přístup k souborům, vypsání záplat a instalovaných aplikací i
spuštění příkazů k získání informací o systému. Tento proces budeme muset
opakovat každý rok, takže je zcela nezbytné, abychom vytvořili standardní
metodu testování splnění cílů naší kontroly. Skripty jsou vhodnou metodou k
zajištění konzistence testů.

Sledování naší práce
Abychom měli dobrý přehled o své práci, vypracovali jsme pro jednotlivé oblasti
kontroly IT standardizované spreadsheety. Pro každý cíl kontroly jsme
identifikovali důsledek nesplnění příslušného cíle, testovací postup a
doporučení pro případ selhání. Rovněž jsme přidali sloupeček, kam byly
zaznamenávány výsledky testů. Poté, co bylo testování dokončeno, každá osoba
zodpovědná za určitou oblast testování vytvořila něco, co jsme nazvali soupisem
nedostatků. Ten uvádí cíle, které nebyly během testu splněny. Následně se
manažeři setkali, prošli si tyto dokumenty a vytvořili plán pro nápravu
nedostatků nebo určili termínovaná kompenzační opatření. Například u testu
vypršení hesla mohla být kompenzační opatření taková, že by uživatelé byli
nuceni používat dvoufaktorovou autentizaci SecurID při přístupu na unixové
servery a že by docházelo k uzamykání systému, aby se uživatelé nemohli přímo
nahlásit přes svoje uživatelské účty. Kompenzační opatření ale musejí být
používána opatrně, protože by auditoři mohli namítat, že je to naše výmluva,
proč neděláme potřebnou práci a neprovádíme modifikace systému.

Další oblasti
Ačkoliv jsem uvedl pouze Oracle a Unix, v souvislosti s bezpečností IT byly
identifikovány i další oblasti zájmu. Například reakce na incidenty,
bezpečnostní politiky, monitorování protokolů, detekce narušení a šifrování
všechny tyto oblasti měly stanovené svoje vlastní kontrolní cíle. Bohužel,
protože jsem zástupcem oddělení bezpečnosti, bylo mi zakázáno provádět
bezpečnostní testy, protože by mohl někdo namítat, že jsem podjatý. Testování
jsme dokončili a teď tvrdě pracujeme na zdokonalení našich systémů, postupů a
politik, abychom byli v souladu s identifikovanými kontrolními cíli. Zjišťujeme
přitom, že nemůžeme svévolně provádět změny jenom proto, abychom uspokojili
zkušební cíl Sarbanes-Oxley. Máme přece produkční prostředí, které generuje
tisíce dolarů příjmu za minutu. Pokud by například bylo cílem zajistit
instalování pouze nezbytných aplikací, reakcí by mohla být odinstalace
nepotřebných aplikací. Někdy se ale odinstalováním aplikace vymažou i
související systémové knihovny, což může ovlivnit jiné aplikace nebo obecný
provoz systému. Bohužel nedisponujeme tak robustním vývojovým prostředím, které
by přímo zrcadlilo naše produkční systémy takže nemůžeme takové věci dopředu
jednoduše testovat. Změna našeho prostředí tak, aby splňovalo kontrolní cíle,
bude velice časově náročná, frustrující a pro naši společnost kritická. V
nejbližší době se uskuteční oficiální audit a jsme si celkem jisti, že pokud
jsme opravdu testovali pečlivě podle současných kontrolních cílů, uspějeme.









Komentáře
K tomuto článku není připojena žádná diskuze, nebo byla zakázána.