Nákup, vývoj a údržba informačního systému
12.1 Bezpečnostní požadavky systémů
Cíl: Zajistit, aby se bezpečnost stala neodlučitelnou součástí informačních systémů.
To zahrnuje provozní systémy, infrastrukturu, interní aplikace organizace, zakoupené produkty,
služby a uživatelsky vyvinuté aplikace. Návrh a implementace informačního systému na
podporu procesů organizace může být z hlediska bezpečnosti kritický. Bezpečnostní požadavky by
měly být stanoveny a odsouhlaseny ještě před zahájením vývoje informačního systému.
Všechny bezpečnostní požadavky by měly být v projektu stanoveny již ve fázi definice požadavků
a měly by být zdůvodněny, odsouhlaseny a dokumentovány jako součást vývoje informačního
systému.
12.1.1 Analýza a specifikace bezpečnostních požadavků
Opatření
Požadavky organizace na nové informační systémy nebo na rozšíření existujících systémů by
měly obsahovat také požadavky na bezpečnostní opatření.
Doporučení k realizaci
Tato specifikace by měla vzít v úvahu začlenění automatizovaných kontrol do systému, ale
i potřebu doplňujících manuálních kontrol. Stejně by se mělo postupovat i při testování,
vytvořených nebo zakoupených, programových balíků aplikací organizace.
Bezpečnostní požadavky a opatření by měly odrážet hodnotu informačních aktiv pro organizaci
(viz 7.2) a možnou škodu, která by mohla být výsledkem nedostatečné bezpečnosti nebo jejího
selhání.
Požadavky na bezpečnost informačních systémů a procesy implementace bezpečnosti by měly
být začleněny do projektu informačního systému již v jeho počáteční fázi. Opatření, která jsou
začleněna ve fázi návrhu, lze implementovat a udržovat výrazně levněji než ty, které jsou
začleňovány v průběhu nebo po implementaci.
U zakoupených produktů by měl nejprve následovat formální proces testování a zavedení do
provozu. Ve smlouvách s dodavateli by měly být specifikovány požadavky na bezpečnost. U
produktů jejichž bezpečnostní funkce nesplňují specifikované požadavky na bezpečnost by
ještě před jejich nákupem mělo být zváženo přijetí opatření na pokrytí nově zavedeného rizika.
Pokud s sebou dodatečné změna funkčnosti produktů přináší také nové riziko, měla by tato
funkčnost být buďto zrušena, a nebo by měl být přezkoumán její potenciální přínos a přijetí
dodatečných opatření.
Další informace
Vedení organizace se může, po důkladném zvážení (například z důvodů nižších nákladů),
rozhodnout používat nezávisle certifikované a ohodnocené produkty. Podrobnější informace o
požadavcích na kritéria, podle kterých je hodnocena bezpečnost IT produktů, lze nalézt v normě
ISO/IEC 1540816 a dalších normách.
Norma ISO/IEC 13335-317 poskytuje návod jak správně určit požadavky na bezpečnostní
opatření v rámci procesu řízení rizik.
12.2 Správné zpracování v aplikacích
Cíl: Předcházet chybám, ztrátě, modifikaci nebo zneužití uživatelských dat v aplikacích.
Pro zajištění bezchybného zpracování by do aplikačních systémů, včetně těch, které jsou
vytvořeny uživatelsky, měly být zahrnuty vhodné kontroly. Měly by zahrnovat potvrzení platnosti
vstupních dat, interního zpracování a výstupních dat.
Přijetí dodatečných kontrol by mělo být zváženo u systémů, které zpracovávají nebo mají vliv na
zpracování citlivých, cenných nebo kritických informací.
12.2.1 Kontrola vstupních dat
Opatření
Vstupní data aplikací by měla být kontrolována z hlediska správnosti a adekvátnosti.
Doporučení k realizaci
Kontrolovány by měly být transakční vstupy, vlastní data (např. jména a adresy, úvěrové limity,
zákaznická referenční čísla) a číselníky (např. prodejní ceny, kurzové převodní tabulky, daňové
sazby).
V úvahu by měla být vzata následující opatření:
a) zdvojený vstup nebo jiná vstupní kontrola, jako například specifikace rozsahu nebo
definovaná pole dat, pro detekování následujících chyb:
1. hodnoty mimo rozsah;
2. neplatné znaky v datových polích;
3. chybějící nebo nekompletní údaje;
4. překročení horního a dolního vymezení rozsahu dat;
5. neoprávněná nebo nekonzistentní kontrolní data;
b) pravidelná kontrola obsahu klíčových polí nebo datových souborů pro potvrzení jejich platnosti
a integrity;
c) kontrola papírových vstupních dokumentů za účelem zjištění jakýchkoliv
neoprávněných změn ve vstupních datech (všechny změny vstupních dokumentů by
měly být schváleny);
d) postupy při reakci na zjištěné chyby validace;
e) postupy pro testování hodnověrnosti vstupních dat;
f) stanovení odpovědností všeho personálu, který se účastní procesu vstupu dat;
g) vytvoření záznamu o činnostech, které jsou součástí procesu vstupu dat (viz 10.10.1).
Další informace
Pro snížení rizika chyb a zabránění běžným útokům, včetně přetečení zásobníku a podstrčení
kódu, by měla být zvážena implementace automatických kontrol a verifikace dat.
12.2.2 Kontrola vnitřního zpracování
Opatření
Pro detekci jakéhokoliv poškození nebo modifikace informací vzniklého chybami při zpracování
nebo úmyslnými zásahy, by mělo být zváženo začlenění kontroly platnosti dat.
Doporučení k realizaci
Návrh aplikací by měl zajistit implementaci těchto omezení tak, aby se minimalizovalo riziko
chyb při zpracování vedoucí ke ztrátě integrity. Za zvážení stojí následující specifické oblasti:
a) použití funkcí vstupu, modifikace a mazání za účelem provedení změn v datech;
b) postupy, které brání spuštění programům ve špatném pořadí nebo zabraňují jejich
spuštění po předchozím selhání zpracování (viz také 10.1.1);
c) použití vhodných programů na zotavení se z chyb a pro zajištění správného zpracování
dat;
d) použití ochrany proti útokům způsobujícím přetečení bufferu.
Měl by být připraven kontrolní seznam, veškeré činnosti dokumentovány a výsledky bezpečně
uchovány. Příklady kontrol, které mohou být začleněny, jsou následující:
a) relační nebo dávková kontrola pro porovnání bilancí datových souborů po transakčních
aktualizacích;
b) bilanční (balancing) kontroly pro ověření celkové hodnoty otevíraných dat oproti celkové
hodnotě předtím uzavřených dat, zejména:
1. kontrola mezi jednotlivými úlohami (run-to-run);
2. celková hodnota provedená aktualizacemi souboru;
3. kontrola mezi jednotlivými programy (program-to-program);
c) verifikace vstupních dat generovaných systémem (viz 12.2.1);
d) prověrka integrity dat nebo programů zasílaných či nahrávaných mezi centrálním
počítačem a vzdálenou stanicí;
e) výpočet celkového kontrolního součtu (hash) záznamů a souborů;
f) ověření, zda jsou programy spouštěny ve správný čas;
g) prověrka, zda jsou programy spouštěny ve správném pořadí a jsou zastaveny v případě
chyby a zda je další zpracování pozastaveno až do odstranění problému;
h) vytváření záznamů o činnostech v průběhu zpracování (viz 10.10.1).
Další informace
Správně vložená data mohou být poškozena chybami technického vybavení, při zpracování
nebo úmyslnými zásahy. Požadované kontroly platnosti dat budou záviset na podstatě aplikací
a dopadu možného poškození dat na chod organizace.
12.2.3 Integrita zprávy
Opatření
U jednotlivých aplikací by měly být stanoveny bezpečnostní požadavky na zajištění autentizace
a integrity zpráv, dle potřeby určena, a zavedena vhodná opatření.
Doporučení k realizaci
Pro stanovení nutnosti zajištění integrity zpráv a určení její nejvhodnější metody by se mělo
provést hodnocení rizik.
Další informace
Jako vhodný prostředek pro implementaci autentizace zpráv mohou být použity kryptografické
metody (viz 12.3).
12.2.4 Kontrola výstupních dat
Opatření
Pro zajištění toho, že zpracování uložených informací je bezchybné a odpovídající dané situaci, by
mělo být provedeno ověření platnosti výstupních dat.
Doporučení k realizaci
Výstupní kontrola platnosti dat může zahrnovat:
a) prověrku hodnověrnosti, tedy ověření přijatelnosti výstupních dat;
b) porovnávací kontrolní součet zajišťující, že byla zpracována všechna data;
c) poskytnutí dostatku informací pro čtenáře nebo následný proces zpracování, pro stanovení
správnosti, kompletnosti, přesnosti a klasifikace informací;
d) postupy pro reakce na výstupní testy platnosti dat;
e) definice odpovědností všeho personálu účastnícího se výstupního procesu
f) vytvoření záznamu všech činností v rámci procesu ověření platnosti výstupních dat.
Další informace
Systémy jsou zpravidla postaveny na předpokladu, že po provedení kontroly platnosti,
verifikace a testování jsou výstupní data správná. Ne vždy je však tento předpoklad správný, i
otestované systémy mohou za určitých okolností produkovat neplatná data.
12.3 Kryptografická opatření
Cíl: Ochránit důvěrnost, autentičnost a integritu informací s pomocí kryptografických prostředků.
Měla by být vytvořena pravidla pro použití kryptografických opatření. K podpoře používání
kryptografických technik by měl v organizaci existovat systém jejich správy.
12.3.1 Politika pro použití kryptografických opatření
Opatření
Měla by být vytvořena a zavedena pravidla pro používání kryptografických opatření na ochranu
informací.
Doporučení k realizaci
Při vytváření pravidel by mělo být zváženo následující:
a) manažerský přístup k zavedení kryptografických opatření v celé organizaci, včetně
základních principů, podle kterých by měly být informace chráněny (viz 5.1.1);
b) na základě výsledků hodnocení rizik by měla být stanovena požadovaná úroveň
ochrany a to s ohledem na typ, sílu a kvalitu požadovaného šifrovacího algoritmu;
c) použití šifrování na ochranu citlivých informací při přenosu na mobilních nebo
vyměnitelných počítačových médiích a zařízení a nebo komunikačními linkami;
d) přístup ke správě klíčů, včetně metod řešení ochrany šifrovacích klíčů, obnovení
šifrovaných informací v případě ztráty, vyzrazení nebo poškození klíčů;
e) úlohy a odpovědnosti, například kdo je odpovědný za:
1. implementaci pravidel;
2. správu klíčů včetně jejich generování (viz 12.3.2);
f) normy, které budou přijaty, aby implementace opatření v celé organizaci byla účinná (pro
které procesy budou použita která řešení)
g) dopad, jaký má šifrování informací na prováděné kontroly obsahu (např. detekce virů).
Při implementaci pravidel použití kryptografie v organizaci by měl být brán zřetel na předpisy
a místní omezení, která mohou platit při použití kryptografických technik v různých částech
světa a pro přenos šifrovaných informací za hranice státu (viz také 15.1.6).
Kryptografická opatření mohou být použita k dosažení různých bezpečnostních cílů, např.:
a) důvěrnosti: použití šifrování na ochranu uložených nebo přenášených citlivých nebo
kritických informací;
b) integrity/autentičnosti: použití digitálních podpisů nebo na ochranu autentičnosti
a integrity uložených nebo přenášených citlivých a kritických informací;
c) nepopiratelnosti: použití kryptografických technik k získání důkazu o tom, zda událost
nebo činnost nastala.
Další informace
Rozhodnutí, zda je vhodné použití kryptografického řešení, by mělo být součástí širšího procesu
hodnocení rizik a výběru opatření. Toto hodnocení pak může být použito při určení vhodnosti
kryptografických opatření, aplikaci konkrétních opatření a dále účelu či procesů organizace, pro
které mají být využity.
Organizace by měla vytvořit pravidla pro používání kryptografických opatření na ochranu svých
informací. Tato pravidla jsou potřebná, aby bylo možno maximalizovat výhody a minimalizovat
rizika z použití kryptografických metod a také pro vyvarování se nevhodného nebo nesprávného
použití. Při použití digitálních podpisů by měl být brán zřetel na všechny relevantní právní úpravy,
které stanovují podmínky vážící se k právní závaznosti digitálních podpisů (viz 15.1).
Při určení odpovídající úrovně ochrany, výběru vhodných produktů, které zajistí odpovídající
ochranu a implementaci bezpečného systému správy klíčů, by mělo být dáno na doporučení
specialistů (viz také 12.3.2).
Technická komise ISO/IEC JTC SC27 vytvořila řadu norem týkajících se kryptografických technik.
Další informace lze také nalézt ve standardu IEEE P136318 a směrnici OECD19.
12.3.2 Správa klíčů
Opatření
Na podporu používání kryptografických technik v organizaci by měl existovat systém jejich
správy.
Doporučení k realizaci
Všechny klíče by měly být chráněny před modifikací a zničením. Tajné a soukromé klíče je třeba
chránit proti neautorizovanému prozrazení. Pro zabezpečení prostředků určených ke generování,
ukládání a archivaci klíčů by měly být použity prostředky fyzické ochrany.
Systém správy klíčů by měl být založen na schváleném souboru norem, postupů a bezpečných
metod pro:
a) generování klíčů pro různé kryptografické metody a aplikace;
b) generování a získávání certifikátů veřejných klíčů;
c) distribuci klíčů určeným uživatelům včetně způsobu jejich aktivace po předání;
d) ukládání klíčů včetně toho, jak autorizovaní uživatelé získávají ke klíčům přístup;
e) změny nebo aktualizace klíčů včetně pravidel určujících, kdy by měly být klíče měněny
a jakým způsobem;
f) zacházení s prozrazenými klíči;
g) revokace klíčů včetně toho, jak mají být klíče staženy z oběhu nebo deaktivovány,
například v případě prozrazení nebo při odchodu uživatele z organizace (v tomto
případě by klíče měly být rovněž archivovány);
h) obnovení ztracených nebo poškozených klíčů jako součást řízení kontinuity činností
organizace, například pro obnovení šifrovaných informací;
i) archivaci klíčů, například pro informace archivované nebo zálohované;
j) ničení klíčů;
k) zaznamenávání a audit aktivit majících souvislost se správou klíčů.
Pro snížení pravděpodobnosti vyzrazení klíčů by tyto měly mít určenu dobu aktivace
a deaktivace, aby jejich použití bylo časově omezeno. Délka platnosti klíče by měla být závislá
na okolnostech, ve kterých se kryptografická opatření používají, a na předpokládaných rizicích.
Současně s bezpečnou správou tajných a privátních klíčů by měla být zvážena i ochrana
veřejných klíčů. Autentizace veřejných klíčů se zpravidla řeší certifikáty veřejných klíčů, které
jsou vydávány certifikační autoritou. Ta by měla být uznávanou organizací a pro zajištění
požadovaného stupně důvěryhodnosti by měla mít zavedena vhodná opatření a postupy.
Obsah dohod o úrovni služeb nebo smluv s externím poskytovatelem kryptografických služeb,
například s certifikační autoritou, by měl pokrývat právní závaznost, spolehlivost a dobu odezvy
zajišťovaných služeb (viz 6.2.3).
Další informace
K účinnému použití kryptografických technik je správa kryptografických klíčů nezbytná. Další
informace poskytuje norma ISO/IEC 1177020.
Kryptografické techniky jsou následující:
a) systém tajných klíčů, kdy dvě nebo více stran sdílí stejný klíč, který je použit jak
k šifrování, tak k dešifrování informací. Tento klíč musí být udržován v tajnosti, protože
kdokoliv, kdo má přístup k tomuto klíči, by mohl dešifrovat všechny informace, které
byly zašifrované tímto klíčem nebo by mohl zavést neautorizované informace;
b) systém veřejných klíčů, kde každý uživatel má pár klíčů. Veřejný klíč (který může být
přístupný každému) a soukromý klíč (který musí být držen v tajnosti). Systém veřejných
klíčů může být použit pro šifrování i pro vytváření digitálních podpisů (viz také normy
ISO/IEC 979621 a ISO/IEC 1488822).
Existuje hrozba, že někdo padělá digitální podpis výměnou veřejného klíče uživatele za svůj
veřejný klíč. Tento problém se řeší zejména certifikáty veřejných klíčů.
Na ochranu šifrovacích klíčů mohou být také použity kryptografické techniky. Mělo by být
zváženo vytvoření postupů pro vyřizování zákonných požadavků na přístup ke kryptografickým
klíčům, například šifrované informace může být zapotřebí zpřístupnit v nešifrované podobě
v případě, že by měly sloužit jako důkaz v soudním sporu.
12.4 Bezpečnost systémových souborů
Cíl: Zajistit bezpečnost systémových souborů
Přístup k systémovým souborům a zdrojovým kódům programů by měl být řízen, projekty IT
a podpůrné činnosti by měly být prováděny bezpečným způsobem. Měla by být přijata opatření
zabraňující prozrazení citlivých informací v testovacím prostředí.
12.4.1 Správa provozního programového vybavení
Opatření
Měly by být zavedeny postupy kontroly instalace programového vybavení na provozních
systémech.
Doporučení k realizaci
Pro snížení rizika poškození provozních systémů by měla být zvážena následující opatření:
a) aktualizace, provozního programového vybavení, aplikací a knihoven programů by měly
být prováděny pouze oprávněným správcem na základě schválení vedením (viz 10.4.3);
b) pokud je to možné, měly by provozní systémy obsahovat pouze spustitelný kód.
Provozní systémy by neměly obsahovat vývojový kód nebo kompilátory ;
c) spustitelný kód by neměl být implementován do provozního systému dříve, než je k
dispozici doklad o úspěšném testování a převzetí uživatelem a než jsou aktualizovány
odpovídající zdrojové knihovny. Testy by měly být prováděny na oddělených systémech
(viz také 10.1.4) a měly by zahrnovat ověření použitelnosti, bezpečnosti, vlivu na ostatní
systémy a optimálnosti pro uživatele;
d) měl by být používán systém kontroly konfigurace pro udržování přehledu
o instalovaném programovém vybavení a systémové dokumentaci;
e) měla by být připravena strategie umožňující návrat, po implementaci změn, do
původního stavu;
f) měly by být udržovány auditní záznamy všech aktualizací provozních programových
knihoven;
g) pro případ nouze by měly být uchovány předcházející verze programového vybavení;
h) staré verze programového vybavení by měly být archivovány spolu se všemi
požadovanými informacemi a parametry, postupy, konfiguracemi a podpůrnými
programy po celou dobu uchování dat v archivu.
Dodavatelsky pořízené programové vybavení použité v provozních systémech by mělo být
udržováno způsobem, který podporuje dodavatel. Na některé starší verze programového
vybavení může dodavatel přestat poskytovat podporu. Organizace by měla zvážit rizika spojená
s provozem nepodporovaného programového vybavení.
Každé rozhodnutí o povýšení verze by mělo brát v úvahu její bezpečnost, tj. její nové
bezpečnostní vlastnosti nebo počet, a závažnost bezpečnostních problémů s ní spojených.
V případě, že existují opravné dávky (záplaty) pro programové vybavení, které mohou pomoci
odstranit nebo redukovat bezpečnostní slabiny, měly by být použity (viz také 12.6.1).
Fyzický nebo logický přístup by měl být umožněn dodavatelům pouze tehdy, pokud je to třeba ze
servisních důvodů a pokud to bylo schváleno vedením. Aktivity dodavatelů by měly být
monitorovány.
Počítačové programové vybavení může záviset na externě dodávaných programech
a modulech.Ty by měly být monitorovány a kontrolovány, aby se zabránilo neoprávněným
změnám, které by mohly být příčinou vzniku bezpečnostních slabin.
Další informace
Provozní systémy by měly být aktualizovány pouze v případech, kdy existuje takový požadavek,
například pokud stávající verze operačního systému již nestačí aktuálním požadavkům
organizace. Aktualizace by neměly probíhat jen proto, že je k dispozici nová verze operačního
systému. Nové verze operačních systémů mohou být méně bezpečné, méně stabilní a méně
prověřené než stávající systém.
12.4.2 Ochrana systémových testovacích údajů
Opatření
Testovací data by měla být pečlivě vybrána, chráněna a kontrolována.
Doporučení k realizaci
Pro účely testování je vhodné se vyhnout použití provozních databází obsahujících osobní nebo
jinak citlivé údaje. Pokud se tato data použijí, je zapotřebí před tím provést jejich anonymizaci.
Pro ochranu provozních dat použitých pro testovací účely by měla být použita následující
Opatření
a) postupy řízení přístupu, které se používají v provozních aplikačních systémech, by měly
být použity i při testování aplikačních systémů;
b) každé kopírování provozních informací do testovacího aplikačního systému by mělo být
samostatně schváleno;
c) provozní informace by měly být okamžitě po ukončení testů z testovacího aplikačního
systému smazány.
d) kopírování provozních informací by mělo být zaznamenáno do auditních záznamů.
Další informace
Systémové a přejímací testování obvykle vyžaduje značné množství testovacích dat, která by
měla být co možná nejvíce podobná datům provozním.
12.4.3 Řízení přístupu ke knihovně zdrojových kódů
Opatření
Přístup ke knihovně zdrojových kódů by měl být omezen.
Doporučení k realizaci
Aby se minimalizovalo možné poškození počítačových programů (zavedení neschválených
funkčních prvků a provedení nechtěných změn), měly by se uplatnit přísné kontroly na přístup ke
knihovnám zdrojových kódů programu a souvisejících položek (jako jsou návrh, popisy, plány
přezkoušení a plány ověření platnosti. U zdrojových kódů programů toho lze dosáhnout vytvořením
kontrolovaného centrálního úložiště, nejlépe v knihovnách zdrojových kódů. Pro řízení přístupu do
těchto knihoven je možné zvážit následující doporučení (viz také 11) snižující pravděpodobnost
poškození počítačových programů:
a) kde je to možné, neměly by být knihovny zdrojových kódů uloženy v provozních
systémech;
b) zdrojové kódy programů a knihovny zdrojových kódů by měly být spravovány v souladu
se zavedenými postupy;
c) pracovníci podpory IT by neměli mít neomezený přístup ke knihovnám zdrojových kódů;
d) aktualizace zdrojových knihoven programů a souvisejících položek a předávání
zdrojových programů programátorům by mělo být prováděno pouze na základě řádného
schválení;
e) výpisy z programu by měly být uloženy na bezpečném místě (viz 10.7.4);
f) všechny přístupy ke knihovnám zdrojových kódů by měly být zaznamenány do auditního
záznamu;
g) udržování a kopírování knihoven zdrojového kódu programu by mělo být předmětem
přísných postupů změnového řízení (viz 12.5.1).
Další informace
Zdrojový kód programu je kód napsaný programátorem a následně zkompilovaný (sestavený)
do spustitelného kódu. Některé programovací jazyky formálně nerozlišují mezi zdrojovým
kódem a spustitelným kódem, protože se spustitelný kód vytváří až při požadavku na spuštění.
Normy ISO 1000723 a ISO/IEC 1220724 poskytují další informace ohledně řízení jakosti
a životního cyklu programového vybavení.
12.5 Bezpečnost procesů vývoje a podpory
Cíl: Udržovat bezpečnost programů a informací aplikačních systémů.
Projektové a podpůrné prostředí by mělo být pod přísnou kontrolou.
Vedoucí a správci, kteří jsou odpovědní za aplikační systémy, by měli mít také odpovědnost za
bezpečnost projektového a podpůrného prostředí. Měli by zajistit, že všechny plánované změny
systému budou podrobeny kontrole, aby nenarušily bezpečnost systému nebo provozního
prostředí.
12.5.1 Postupy řízení změn
Opatření
Měly by být zavedeny formální postupy řízení změn.
Doporučení k realizaci
Pro minimalizaci poškození informačních systémů by měly být prosazovány a dokumentovány
formální postupy pro řízení změn. Postupy zavádění nových a významné změny u stávajících
systémů by měly být formálně řízeny a dokumentovány včetně technických specifikací, měly by
podléhat testování a kontrole kvality. Měly by také zajišťovat, aby bezpečnostní a kontrolní
postupy nebyly narušeny, aby programátoři měli přístup pouze k těm částem systému, které
potřebují ke své práci, aby všechny změny byly potvrzeny formální dohodou a odsouhlasením.
Vždy, když je to vhodné, by měly být aplikační a provozní postupy řízení změn propojeny (viz
také 8.1.2). Tento proces by měl zahrnovat:
a) udržování záznamu schválených stupňů oprávnění;
b) zajištění toho, že požadavek na změny byl vznesen oprávněnými uživateli;
c) přezkoumaní opatření a integrity postupů proto, aby v případě změn nemohlo dojít k jejich
kompromitaci;
d) určení veškerého programového vybavení, informací, databázových entit a technického
vybavení, které vyžadují doplnění nebo změny;
e) formální schválení podrobných návrhů před zahájením práce;
f) zajištění toho, aby změny byly před provedením akceptovány oprávněnými uživateli;
g) zajištění toho, aby systémová dokumentace byla aktualizována při ukončení každé změny
a stará dokumentace byla archivována nebo zničena;
h) udržování kontroly verzí u všech aktualizací programového vybavení;
i) udržování auditního záznamu všech požadavků na změny;
j) zajištění toho, aby v případě nutnosti byly provedeny změny v provozní dokumentaci (viz
10.1.1) a uživatelských postupech;
k) zajištění toho, aby změny byly prováděny včas a nebyl narušen daný proces organizace.
Další informace
Změna aplikačního programového vybavení může ovlivnit stávající provozní prostředí.
Mezi dobré praktiky patří testování nových programů v prostředí, které je odděleno od vývojového
a provozního prostředí (viz také 10.1.4). To umožňuje získání kontroly nad novými programy
a zajišťuje další ochranu provozních informací použitých pro testovací účely. Takto by se měly
také nejprve aplikovat záplaty, opravné balíčky a další aktualizace. U kritických systémů by,
z důvodů možného selhání, neměly být nastaveny automatické aktualizace (viz 12.6).
12.5.2 Technické přezkoumání aplikací po změnách operačního systému
Opatření
V případě změny operačního systému by měly být přezkoumány a otestovány kritické aplikace,
aby bylo zajištěno, že změny nemají nepříznivý dopad na provoz nebo bezpečnost organizace.
Doporučení k realizaci
Tento proces by měl zahrnovat:
a) přezkoumání opatření a procesů zabezpečujících integritu v aplikacích, aby bylo zajištěno,
že nejsou narušeny změnami operačního systému;
b) zajištění toho, aby roční plán podpory a rozpočet na ni pokrýval přezkoumání a testování
systému vyvolané změnami operačního systému;
c) zajištění toho, aby změny operačního systému byly včas oznámeny tak, aby mohla být
provedena náležitá přezkoumání před jejich realizací;
d) zajištění toho, aby příslušné změny byly zaneseny do plánů kontinuity činností organizace
(viz 14).
Měla by být určena konkrétní odpovědnost za sledování zranitelností a dodavateli nově
vydaných záplat a oprav (viz 12.6).
12.5.3 Omezení změn programových balíků
Opatření
Modifikace programových balíků by měly být omezeny pouze na nezbytné změny, veškeré
prováděné změny musí být řízeny.
Doporučení k realizaci
Dodavatelsky pořízené programové balíky by měly být používány beze změn. V případech, kdy
je opravdu nutné modifikovat sady programového vybavení, by se měly vzít v úvahu následující
body:
a) možné riziko narušení vestavěných kontrol a procesů zajišťujících integritu;
b) zda by měl být získán souhlas dodavatele;
c) možnost získání požadovaných změn od dodavatele formou standardní aktualizace
programu;
d) důsledky toho, že se organizace stane z důvodu provedení změn odpovědnou za budoucí
udržování programů.
Pokud jsou změny nezbytné, pak by se originální programové vybavení mělo uchovat a změny by
měly být provedeny na jednoznačně označené kopii. Pro zajištění toho, že jsou vždy
instalovány nejnovější a schválené záplaty a aktualizace by měl být zaveden řízený proces
aktualizace aplikačního programového vybavení. Všechny změny by měly být plně
zdokumentovány, aby se mohly znovu použít u budoucích verzí programového vybavení.
Pokud je to vyžadováno, měly by provedené změny být nezávisle otestovány a potvrzeny.
12.5.4 Únik informací
Opatření
Mělo by být zabráněno úniku informací.
Doporučení k realizaci
Pro snížení pravděpodobnosti rizika úniku informací (např. využitím skrytých kanálů) by měly
být vzaty v úvahu následující doporučeni:
a) skenování odchozích médií a komunikací jestli neobsahují skryté informace;
b) provádět maskování, časté změny chování a komunikování systému, ke snížení
pravděpodobnosti odhalení informací;
c) využití systémů a aplikačního programového vybavení s ověřenou vysokou mírou
integrity, například produktů splňujících kritéria bezpečného vývoje (viz ISO/IEC
1540825);
d) pravidelné monitorování systému a činností zaměstnanců, pokud je to v souladu
s příslušnou legislativou a předpisy;
e) monitorování využití zdrojů v počítačových systémech.
Další informace
Skryté kanály jsou cesty, jejichž cílem není zprostředkovávat tok informací, mohou se však
v sítích nebo systémech vyskytovat. Například manipulace (změna hodnot) bitů v datových
paketech komunikačních protokolů může být využita jako skrytá metoda signalizace.
Stoprocentní ochrana proti skrytým kanálům je obtížná, ne-li nemožná. Tyto kanály jsou však
často využity trojskými koni (viz 10.4.1), proto přijetí opatření na ochranu proti trojským koňům
může výrazně snížit riziko zneužití skrytých kanálů.
Ochrana před neautorizovaným přístupem k síti (viz 11.4) spolu s politikou a postupy
odrazujícími personál od zneužití síťových služeb (viz 15.1.5)
12.5.5 Programové vybavení vyvíjené externím dodavatelem
Opatření
Vývoj programového vybavení externím dodavatelem by měl být organizací dohlížen
a monitorován.
Doporučení k realizaci
Když je vyvíjeno programové vybavení externím dodavatelem, měly by být zváženy následující
body:
a) licenční ujednání, vlastnictví kódu a práv duševního vlastnictví (viz 15.1.2);
b) osvědčení kvality a správnosti provedených prací;
c) uložení zdrojového kódu u nezávislé třetí strany pro případ problémů externího
dodavatele;
d) právo přístupu k vývoji pro audit kvality a správnosti provedené práce;
e) smluvní podmínky na kvalitu a zabezpečení kódu;
f) testování na odhalení trojských koní a škodlivých kódů před instalací.
12.6 Řízení technických zranitelností
Cíl: Snížit rizika vyplývající ze zneužití veřejně publikovaných technických zranitelností.
Řízení (správa) technických zranitelností by mělo být zavedeno efektivním, systematickým
a opakovatelným způsobem, s využitím metrik pro ověření její účinnosti. Toto by mělo
zahrnovat všechny operační systémy a použité programové vybavení.
12.6.1 Řízení, správa a kontrola technických zranitelností
Opatření
Mělo by být zajištěno včasné získání informace o existenci technické zranitelnosti
v provozovaném informačním systému, vyhodnocena úroveň ohrožení organizace vůči této
zranitelnosti a přijata příslušná opatření na pokrytí souvisejících rizik.
Doporučení k realizaci
Aktuální a kompletní evidence aktiv (viz. 7.1) je nezbytným předpokladem pro účinné řízení
technických zranitelností. Informace potřebné pro podporu řízení technických zranitelností
zahrnují dodavatele programového vybavení (pro operační systémy i aplikace), číslo verze,
aktuální stav nasazení (např. který SW je instalován na jakých počítačových systémech)
a osoby odpovědné za dané programové vybavení.
Měly by být prováděny přiměřené a včasné kroky pro nalezení potenciálních technických
zranitelností. Pro vytvoření účinného procesu řízení (správy) technických zranitelností by měla
být realizována následující doporučení :
a) organizace by měla definovat a vytvořit role a odpovědnosti související s řízením
technických zranitelností, které by měly zahrnovat sledování zranitelností, hodnocení
rizik zranitelností, záplatování (instalace opravných balíčků), sledování a evidenci aktiv
a další potřebné koordinační odpovědnosti;
b) měly by být nalezeny a evidovány informační zdroje pro identifikaci odpovídajících
technických zranitelností používaného programového vybavení a další technologie (v
závislosti na evidenci aktiv viz. 7.1.1); tyto informační zdroje by měl být aktualizovány
v závislosti na změnách v evidenci nebo v případě nálezu nových a užitečných zdrojů;
c) měl by být definován časový harmonogram pro sled činností reagujících na hlášení
o zjištěných potencionálních technických zranitelnostech;
d) jakmile je zjištěna potencionální technická zranitelnost měla by organizace ohodnotit
související rizika a provést nápravná opatření; taková opatření mohou zahrnovat
záplatování (instalaci opravných balíčků) nebo případně další aktivity;
e) v závislosti na tom, jak naléhavě musí být technická zranitelnost řešena, musí být
vybrána následná akce s přihlédnutím na postupy řízení změn (viz. 12.5.1) nebo
v závislosti na postupu pro zvládání bezpečnostních incidentů (viz. 13.2);
f) jestliže je dostupná záplata (opravný programový balíček), mělo by být ohodnoceno
riziko spojené s její instalací (mělo by být porovnáno riziko související s neošetřenou
zranitelností s rizikem instalace opravné záplaty);
g) záplaty (opravné programové balíčky) by měly být otestovány a vyhodnoceny před
jejich instalací, aby se ověřila jejich účinnost a existence nežádoucích vedlejších efektů;
pokud záplaty (opravné programové balíčky) nejsou dostupné, měla by být zváženy
další opatření, jako například:
1. vypnutí (znepřístupnění) služeb nebo vlastností (funkcí, parametrů, práv)
umožňujících využitelnost zranitelnosti;
2. přizpůsobení nebo přidání opatření pro omezení přístupových práv (např. firewallu)
na hranici sítě (viz. 11.4.5);
3. zvýšení monitorování pro detekci nebo ochranu před samotnými útoky;
4. zvýšení informovanosti o dané zranitelnosti;
h) uchovat záznamy o všech provedených procedurách;
i) proces řízení technických zranitelností by měl být pravidelně sledován a vyhodnocován
aby byla zajištěna jeho účinnost a efektivita;
j) systémy s vysokým rizikem by měly být řešeny nejdříve.
Další informace
Správná funkčnost procesu řízení (správy) technických zranitelností je kritická pro mnoho
organizací a proto by měla být pravidelně sledována. Pro identifikaci všech potencionálních
technických zranitelností, souvisejících s použitými technologiemi je nezbytná přesná evidence.
Řízení technických zranitelností může být vnímáno jako součást procesu řízení změn a jako
takové může využít jeho vlastností a postupů (viz. 10.1.2 a 12.5.1).
Na dodavatele je často vyvíjen významný tlak, aby uvolňovali záplaty (opravné programové
balíčky) pro své produkty co nejdříve. Proto se stává, že některé záplaty (opravné programové
balíčky) neřeší správně problém a mohou obsahovat nežádoucí vedlejší efekty. V některých
případech se může také stát, že odinstalování záplaty poté co byla nainstalována nelze bez
problémů provést.
Pokud není možné záplaty (opravné programové balíčky) náležitě otestovat (například
z nedostatku zdrojů), je nutno zvážit odložení jejich instalace do doby, kdy budou známy
a vyhodnoceny zkušenosti ostatních uživatelů s jejich instalací.