ITIL 4 – Bezpečnost

Změnil se nějak náhled na bezpečnost u ITIL 4? Jaké jsou dvě hlavní praktiky v ITIL 4 zaměřené na oblast bezpečnosti? Co to je Resilia? V této části bychom si měli říct něco o bezpečnosti. Jak se již stalo v ITIL tradicí, procesy nebo praktiky ITIL týkající se bezpečnosti byly jeho tradiční součástí, a ne jinak je tomu v poslední verzi. Odlišnost nalezneme ve skutečnosti, že k bývalému procesu (dnes praktice) Information Security Management (ISM) přibyla další praktika – Risk management, ale také rozšíření působnosti do Agile/DevOps.

CIA          Risk appetite             HVIT             Risk register          ISM      
Practises            DevSecOps         Risk management

Úvod do bezpečnosti

Díváme-li se na praktiky, logicky se na první pohled nabízí proces (dnes praktika) ISM (viz Box 1).

Následující text porovná obě praktiky s předchozí verzí a zdůrazní základní koncepty. Z pohledu certifikací jsou praktiky ISM a Risk management integrální součástí sylabu na HVIT.

Praktiky v ITIL 4 zaměřené na bezpečnost

Praktika Information Security Management/ISM Účelem této praktiky je zajistit ochranu informací, které organizace potřebuje k tomu, aby mohla zajišťovat svůj business. To zahrnuje pochopení a správu rizik (viz Risk management), které se vztahují k CIA⁵, ale i k dalším faktorům, jako jsou autentizace, nepopiratelnost či autorizace.

Praktika nejprve definuje základní termíny uvedené v účelu praktiky, dále aktiva, ohrožení, zranitelnost, jako je CIA, autentizace a celé řady dalších termínů, které sice patří do praktiky Risk management, ale ISM je také využívá.

Účel procesu (resp. praktiky) se nijak neliší od V3, pouze definice rozsahu procesu je v ITIL 4 poněkud praktičtější, protože nedefinuje procesní aktivity, ale spíše komponenty či schopnosti, které hrají nějakou informační úlohu. To se vztahuje k rizikům (specifická praktika v ITIL 4), jejichž analýza, posouzení a správa nápravných opatření tvoří velkou část praktiky ISM. Je důležité, aby bezpečnostní rizika nebyla řešena separátně, ale v souladu s řešením dalších rizik (např. finanční, legislativní, projektová atd.). Útvar řešící bezpečnost se může rozhodnout držet bezpečnostní rizika v dedikovaném registru pro ISM, ale ve většině případů platí, že by to zároveň mělo být bráno v potaz v registru rizik celé organizace. Vlastníky těchto rizik mohou být pracovníci zajišťující ISM, ale také třeba vlastníci služby, vlastníci produktů či obecně seniorní management odpovídající za portfolio služeb a produktů.

Proces (praktika) ISM v sobě zahrnuje vytváření a následnou správu bezpečnostních kontrol a opatření, definici bezpečnostních politik a jejich kontinuální údržbu podle toho, jak se tato ohrožení a zranitelnosti vyvíjejí v čase. V tom se verze ITIL 4 příliš neliší od V3. V čem se naopak ITIL 4 u praktiky ISM velmi liší, je koncept zabudování dílčích bezpečnostních aktivit do celého hodnotového řetězce (např. návrh a provoz nové služby). V tomto smyslu si ISM v ITIL 4 nikterak nezadá s praktikami na DevOps, resp. DevSecOps, jako je Continuous security (viz DSM 3/2019).

Identifikace rizik lze provádět buďto na pravidelné bázi, nebo na základě bezpečnostního ohrožení či v reakci na bezpečnostní incident – role vlastníka rizika, manažera cyber security projektu a člena rizikové komise.

Příklad faktorů úspěchu u praktik a klíčových metrik (Key metrics) je uveden v Tab. 1.

Tab. 1: Faktory úspěchu u praktiky ISM a klíčové metriky

Praktika ISM uvádí další praktiky, se kterými nějak spolupracuje (v kontextu bezpečnosti):

• Relationship management/Organizational change management – komunikace se zákazníky, sponzory, regulátory, orgány zajišťující governance.
• Service desk – provozní komunikace s uživateli.
• Supplier management – přístup ke zdrojům a nástrojům; ustanovení a následná údržba kontraktů o poskytování služeb.
• Service design/Software development and management/ Infrastructure and platform management/Service validation and testing/Deployment management/Release management – návrh a implementace služeb a produktů.
• Monitoring and event management – monitoring zajišťující detekci potenciálních bezpečnostních incidentů.
• Service request management – zajišťuje, že oprávnění lidé dostanou přístup ke službám (či aplikacím a prvkům infrastruktury).

Další novinkou či odlišností u praktiky ISM je kontextová mapa (tzv. heat map), která praktice ISM přisuzuje vysokou důležitost u všech šesti klíčových aktivit v rámci hodnotového řetězce služby.

Praktika ISM zahrnuje dva procesy:

• Proces správy bezpečnostních incidentů
• Audit a revize

Příklad prvního procesu je uveden na Obr. 1.

Dále praktika navrhuje role v rámci ISM, zde silně rozšiřuje počet rolí v ITIL V3 a navrhuje cca až 12 různých rolí (pro každou z nich doporučuje tzv. kompetenční profil – novinka v ITIL 4, konkrétně v praktikách). U některých z těchto rolí jde však o přenesené role z jiných praktik.

ISM zdůrazňuje důležitost znalosti základních bezpečnostních konceptů i pro všechny role, diskutuje o problematice školení, zahrnutí požadavků na bezpečnost i do procesů najímání zaměstnanců a v neposlední řadě posílení disciplíny v oblasti bezpečnosti pomocí různých prvků – postery, e-maily, korporátní intranet, pravidelné schůzky atd.

Praktika rovněž odkazuje na použití různých informačních nástrojů, jako jsou CMDB⁶, katalog služeb, různé znalostní systémy, SIEM⁷, DML⁸ atd.

Obr. 1: Proces správy bezpečnostních incidentů v ITIL 4

Praktika Risk management

Tato praktika, která se primárně zabývá správou rizik, patří v ITIL 4 k těm nejrozsáhlejším (38 stran).

Účelem této praktiky je porozumění a správa rizik, což by mělo umožnit udržení organizace na trhu a spoluvytváření hodnoty pro zákazníky. Správa rizik je prováděna na různých úrovních organizace – od strategické úrovně přes taktickou (PMO⁹).

Některé užitečné termíny:

• Kapacita rizik (risk capacity) – pomyslná hranice, maximální množství rizik, které organizace je schopna tolerovat, aniž by došlo k narušení jejího provozu (obvykle vztaženo ke ztrátě reputace či aktiv).
• Apetit k rizikům (risk appetite) – množství rizik, které je organizace ještě ochotna akceptovat, je vždy nižší než kapacita rizik.
• Registr rizik (risk register) – evidence záznamů o rizicích.
• Vlastník rizika (risk owner) – osoba, která je odpovědná za pochopení a následnou správu rizika.
• Zbytkové riziko (residual risk) – riziko po uplatnění specifických opatření na eliminaci/redukci rizika.

Alternativy, jak se vyrovnat s riziky, jsou uvedeny v Tab. 2.

Tab. 2: Alternativy řešení rizik

Abychom mohli eliminovat nebo alespoň redukovat rizika, je nutná realizace opatření (controls). Tato opatření mohou být technická, organizační, procesní či na straně dodavatelů.

Rozsah praktiky Risk management je definován pomocí ostatních praktik, na které se opatření vztahují. Patří sem různé praktiky, rozsah je daleko širší, než tomu bylo v případě ITIL V3:

• Project management
• ISM
• Portfolio management
• Capacity and performance management
• Availability management
• Problem management
• Incident management
• Service continuity management
• Continual improvement
• SLM

Risk management doporučuje tyto faktory úspěchu praktiky/ PSF a klíčové metriky (viz Tab. 3).

Tab. 3: PSF a klíčové metriky pro Risk management

Praktika se dále rozpadává na tři procesy:

• Governance praktiky Risk management
• Identifikace rizik, jejich analýza a ošetření (viz Obr. 2)
• Monitorování a revize rizik

Je třeba zdůraznit, že jak ISM, tak i Risk management jsou v ITIL čtyři praktiky, které patří do odpovědnosti každého zaměstnance.

Obr. 2: Proces identifikace, analýzy a ošetření rizik v rámci praktiky Risk managementu v ITIL 4

Bezpečnostní aktivity a kroky v ostatních praktikách ITIL 4

Kromě výše uvedených dvou praktik se bezpečností ještě zabývají některé další praktiky (u některých z nich bychom to možná ani nečekali; uváděno v abecedním pořadí):

• Architecture management – jednou z charakteristik je právě bezpečnost, shoda s regulativními omezeními; každá nová služba či produkt by měly být navrhovány s ohledem na bezpečnostní standardy a specifické požadavky.
• Availability management/AVM – kromě logických vazeb na kapacitu a kontinuitu je zde také vazba na information security; operuje se zde s termínem „nezabezpečená“ služba. Hackerské útoky typu DDoS¹⁰ mohou způsobit nedostupnost služby, takže i tato praktika je velmi úzce spojena s ISM a patří do kategorie „technických rizikových“ praktik (kromě AVM sem ještě patří Capacity and performance management a Service continuity management).
• Business analysis management jen krátce zmiňuje analýzu rizik a optimalizaci těchto rizik, ale (podle mého názoru špatně) neřeší explicitně bezpečnost (část tzv. business security).
• Continual improvement samozřejmě řeší možná rizika a implementaci jejich zmírnění (mitigation), popř. úplnou eliminaci. Rizika se doporučeně porovnávají s očekávanými přínosy.
• Deployment management řeší problematiku bezpečnostních (ideálně automatizovaných) testů při rozmisťování softwaru do produkčního prostředí. Přitom předpokládá existenci bezpečnostních politik spřažených právě s rozmisťováním softwaru. Tady je viditelný přístup technik stylu HVIT, které na jedné straně přispívají k rapidnímu zvyšování počtu releasů rozmístěných do produkčního prostředí a na straně druhé zase ke snižování rizik díky tomu, že rozsah releasů je většinou velmi malý (tzv. standardní změna v ITIL).
• Change enablement uvažuje mezi základními charakteristikami kvality i bezpečnost a podobně jako u předchozí praktiky uvažuje vstupy bezpečnostních politik. Je asi samozřejmostí, že tato praktika počítá s využitím posouzení rizik při schvalování změn. Koneckonců tato praktika patří společně s dedikovanou praktikou Risk management k těm z nich, které mají identifikaci, klasifikaci a eliminaci/mitigaci rizik ve svém poslání (viz Box 3). Je potřeba zdůraznit, že se to zdaleka netýká pouze IT, ale hlavně rizik pro business.

• Incident management samozřejmě obsahuje také ošetření bezpečnostních incidentů – zpravidla předáním praktice ISM. Abychom byli schopni určit, zda jde o bezpečnostní incident, musíme mít definované bezpečnostní politiky.
• Infrastructure and platform management je novou praktikou, která definuje, jak stavět, konfigurovat a v případě chyb podporovat práci s infrastrukturou (včetně cloudu ve formě IaaS¹¹) a platformami (včetně PaaS¹²). Kromě definovaných politik pro oblast sítí, hardwaru a dalších zařízení datových center (v případě modelu on premise) se zde ještě objevují kontrolní opatření (jako např. záplatování) a opravné procedury, jejichž cílem je zajistit přijatelnou úroveň rizika pramenící z infrastruktury díky pravidelnému testování. To se samozřejmě týká i dodavatelů. Infrastrukturu, resp. platformy můžeme z pohledu softwaru vnímat jako jakýsi podvozek, na kterém software běží. Čím stabilnější a robustnější bude tento podvozek, tím samozřejmě bude vyšší i kvalita softwaru poskytovaného cílovým zákazníkům.
• IT Asset management je praktikou, která na první pohled vypadá jako něco zaměřeného pouze na finance a správu aktiv. Fakticky tomu tak však není, patří sem také správa rizik a soulad s bezpečnostními politikami a audity. Tuto praktiku bychom určitě měli zařadit mezi ty, které patří do oblasti běžně označované jako GRC¹³. Praktika balancuje rizika a náklady.
• Knowledge management (KM) – bezpečnostní rizika spojená se ztrátou znalostí či naopak prozrazení důvěrných dat v případě bezpečnostního narušení (security breach), správa informací a znalostí ve shodě s bezpečnostními požadavky. Klíčovými vstupy do KM jsou bezpečnostní politiky z ISM. KM obsahuje sub-proces správy znalostních aktiv, který velmi silně vychází z potřeb a principů ISM. Participují zde role Information security team, Information security manager. KM patří mezi praktiky, které mají k tématu bezpečnosti hodně blízko – vždyť např. ztráta dat při hackerském útoku typu Ransomware či odcizení dat o zákaznících je typickým pojmem v oblasti KM. Součástí správy znalostí musí být i jejich ochrana před neschváleným přístupem. Ke klasické trojici CIA přibývají další aspekty, jako je věrohodnost dat, aktuálnost, redundance či konflikt obsahu.
• Measurement and reporting zajišťuje měření a reporting pro praktiku ISM.
• Monitoring and event management detekuje bezpečnostní události pro ISM a umožňuje nastavení prahových hodnot pro vybrané bezpečnostní požadavky, při jejichž překročení jsou generována varování.
• Portfolio management zajišťuje přístup k portfoliu pro partnery a dodavatele (třeba NDA).
• Project management pouze odkazuje na různé standardy, např. na cybersecurity (CYBoK).
• Release management diskutuje o úloze kritických bezpečnostních záplat a faktu, že vstupem do této praktiky jsou bezpečnostní politiky, na praktice participují bezpečnostní role z praktiky ISM.
• Service catalog diskutuje o úloze bezpečnostních politik v kontextu dodavatelů (např. sdílení dat o zákaznících apod.).
• Service configuration management provádí analýzy dopadů u bezpečnostních incidentů v CMDB.
• Service continuity management patří k technickým praktikám, kde se silně uplatňují analýzy a správy rizik (v případě velkého kybernetického útoku může dojít k výpadku celého datového centra či sdílené platformy v cloudu, což má velmi neblahý vliv na business continuity management). Při výpadku ISM patří k praktikám, které se uplatní při obnově služeb po havárii.
• Service Design musí zabezpečit, že se při návrhu berou v potaz bezpečnostní politiky, standardy a specifické bezpečnostní požadavky kladené na novou službu či produkt.
• Service desk – dříve funkce v ITIL V3, dnes praktika zajišťující podporu koncových uživatelů a komunikaci s uživateli řeší přirozeně i bezpečnostní incidenty, příp. požadavky na služby, které se dotýkají bezpečnosti (např. propůjčování a odjímání přístupových práv). Praktika ISM velmi často vydává nejen bezpečnostní politiky a standardy, ale také zadává bezpečnostní kontrolní opatření (security controls), které se pak využívají při interakcích se zákazníkem.
• Service financial management na první pohled nemá nic společného s bezpečností, ale ono to tak úplně není – typicky náklady na bezpečnost patří mezi tzv. režijní (nepřímé) náklady.
• Service level management – každé SLA¹⁴ logicky obsahuje i celou řadu bezpečnostních požadavků či naopak garancí.
• Service request management – některé požadavky na službu požadují autorizaci – manažerskou nebo technickou (např. z pohledu architektury), příp. finanční.
• Service validation and testing – typické (ideálně automatické) bezpečnostní testy (velmi často zaměřené na autentizaci a autorizaci uživatelů) a stanovení možných bezpečnostních rizik u služeb.
• Software development and management se týká kvality softwaru, jehož součástí je vždy bezpečnost. Funkční požadavky by vždy měly reflektovat bezpečnostní standardy, politiky a specifické potřeby u dané služby, která je předmětem vývoje. Patří sem i řešení bezpečnostních softwarových bugů.
• Strategy management diskutuje o manažerských a generických bezpečnostních rizicích jako součásti firemní strategie.

Resilia

Asi bychom neměli zapomenout na toto téma. Resilia je separátní, sesterskou praktikou, jako je ITIL, dalším „dítkem“ z dílny firmy Axelos. Zajišťuje školení, nástroje a certifikaci osob pro oblast kybernetické bezpečnosti15. Je ale primárně určena k ochraně kyberprostoru z pohledu odolnosti. „Kybernetická odolnost“ (cyber resilience) je zde určena jako schopnost bránit, detekovat a korigovat jakýkoli dopad, jaký mohou mít incidenty na informaci poskytovanou businessu.

Jedná se o „best practice“, která je popsána v stejnojmenné publikaci, školena a certifikována zkouškou. [1]

Shrnutí v oblasti bezpečnosti

Asi pořád platí, že normy řady ISO/IEC 27000 jsou tou nejdetailnější formou kolem bezpečnosti stejně jako fakt, že se proti těmto normám (konkrétně ISO/IEC 27001) provádí certifikace firem.

ITIL 4 nově přináší dedikovanou praktiku pro oblast bezpečnosti (počítáme-li Risk management, tak dvě praktiky), která je úzce provázána s dalšími praktikami použitými v oblasti správy služeb. Navíc ITIL 4 tradičně vysvětluje „jak“ ve srovnání s normami ISO 20000/270xx, které se spíše zaměřují na „co“. V tom je největší přínos ITIL 4 oblasti bezpečnosti. Co se týče bezpečnosti, pak publikace DSV a HVIT jsou klíčovými publikacemi ITIL 4, kde se tato mantra řeší nejčastěji.

Hodně hloubkově popisovanou problematikou je oblast odolnosti v provozu (resilient operations) a tzv. chaos engineeringu (náhodné testy odolnosti), viz Box 4.

BOX4

Diskutuje také o problematice specifického nasazení v organizacích typu HVIT – tedy organizacích uplatňujících Agile a DevOps. A konečně došlo k rozšíření praktik i do oblasti označované jako GRC, což u V3 nebylo. Fakticky např. celá kapitola Techniky pro zaručení shody (Compliance, conformity) v publikaci HVIT je věnována oblasti dosahování shody v oblasti bezpečnosti.

Velmi zajímavou změnou v tomto kontextu je také tzv. integrace povinností (integration of duties), což je alternativa ke známému a doposud v „klasické“ bezpečnosti uplatňovanému principu dělení povinnosti a odpovědnosti (segregation of duties) spočívajícímu v integraci činností k jedné roli nebo týmu. Můžeme tak kombinovat provozně orientované zásahy s kontrolními postupy či procedurami.

Závěrem chci sdělit, že bezpečnost ve všech svých podobách se stává čím dál důležitější, a hlavně odpovědnost za bezpečnost je v rukou nás všech (DevSecOps: „Security is everyone’s responsibility“). Bezpečnost by měla být zakomponována do celého životního cyklu vývoje služeb či produktů již od fáze definice požadavků zákazníků či businessu.

V posledním dílu si něco povíme o tom, jak implementovat ITIL 4, shrneme si přínosy a stinné stránky ITIL 4, probereme školení, typické problémy a mýty a celou sérii zakončíme finálním doporučením.

Poznámky pod čarou:

1. Správa přístupů, někdy též Identity management (správa identit) či Rights management (řízení přístupových práv)
2. Management of Risks (Axelos)
3. Kritické faktory úspěchu
4. Doslova Faktory úspěchu praktiky
5. Confidentiality, Integrity and Availability
6. Configuration Management DataBase – konfigurační databáze
7. Security Incident and Event Management – správa bezpečnostních událostí a incidentů
8. Definitive Media Library – knihovna definitivních médií
9. Project Management Office
10. Distributed denial-of-service – distribuované odmítnutí služby 11 Infrastructure as a Service
11. Platform as a Service
12. Governance, Risk, Compliance
13. Service Level Agreement
14. V ČR upraveno zákonem 181/2014 Sb., zákon o kybernetické bezpečnosti.

Použité zdroje:

[ 1 ] Axelos Resilia, https://www.axelos.com/resilia