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í.