Kybernetické hrozby se zvyšují
Kybernetické útoky se stávají stále častějšími a sofistikovanějšími. Představují hrozbu nejen pro podnikatelské subjekty a veřejnou správu, ale i pro společnost jako celek, zejména v kontextu současných geopolitických událostí. Zajištění kybernetické bezpečnosti se stalo nutnou podmínkou pro fungování moderní společnosti. Požadavky na různé prvky ochrany proti kybernetickým hrozbám definovány v řadě dokumentů charakteru norem, standardů, metodologií a směrnic anebo jsou přímo implementovány do legislativního rámce.
Jednou z metod ochrany proti kybernetickým hrozbám je použití principů „Secure by Design“ při vývoji softwarových produktů. Tento princip se dá aplikovat pro vývoj aplikací, webových stránek nebo jiných nástrojů dostupných běžným uživatelům, ale i dalších technických nebo back-endových nástrojů.
Uplatnění principu Secure by Design velmi dobře popisuje dokument „Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software (cisa.gov)“ připravený ve spolupráci řady bezpečnostních složek a kyberbezpečnostních úřadů, od amerických, přes australského, izraelské, německé až po český NÚKIB.
Tento dokument obsahuje základní principy kybernetické bezpečnosti pro organizace zabývající se vývojem software. S ohledem na počet autorů je dokument do jisté míry obecný, resp. přináší zejména základní principy, jak k této oblasti přistupovat. Ale právě proto je využitelný v zásadě pro každého, kdo se vývojem software, byť třeba okrajově, zabývá.
Co znamená princip „Secure by Design“?
Pojem „Secure by Design“, který bychom mohli přeložit jako "Bezpečný již od návrhu", se používá v oblasti vývoje softwarových produktů a představuje postup, při kterém je kybernetická bezpečnost produktu zohledňována už během počátečních fází vývoje. To znamená na úrovni návrhu architektury softwarového produktu.
Princip „Secure by Design“ zahrnuje různé techniky, například provedení důkladné analýzy hrozeb navrhovaného software, návrh bezpečné architektury a implementaci bezpečnostních kontrol. Implementace tohoto principu představuje pro týmy vývojářů nejen požadavek na hluboké znalosti v oblasti kybernetické bezpečnosti, ale také na jejich neustálý rozvoj.
Vznik dokumentu a jeho kontext
Dokument publikovala americká asociace (agentura) CISA – Cybersecurity & Infrastructure Security Agency v dubnu a k jeho aktualizaci došlo v říjnu tohoto roku. Dokument je určen primárně pro výrobce software a jeho cílem je definovat základní principy a doporučení pro bezpečný vývoj softwarových produktů tak, aby byly zákazníkům dodávány pouze produkty, které v sobě mají implementovány prvky pro zajištění kybernetické bezpečnosti.
Dokument nepředstavuje metodiku pro bezpečný vývoj (SDL – Secure Development Lifecycle), jakými jsou například rámec pro bezpečný vývoj SW vyvinutý a publikovaný americkou agenturou NIST „NIST Special Publication 800-218 Secure Software Development Framework (SSDF) Version 1.1“ nebo metodika pro bezpečný vývoj společnosti Microsoft.
Dokument blíže popisuje tři základní principy, kterými by se měli řídit výrobci software při vývoji softwarových produktů. Všechny si je představíme dále v článku.
Secury by Design z pohledu regulace
Na tomto místě je třeba připomenout, že principy „Secure by design“ nejsou v odborné komunitě ničím novým. Jsou již rovněž delší dobu široce diskutovány na úrovni EU a je jen otázkou času, kdy budou implementovány do regulatorního rámce EU.
Princip „Secure by Desing“ je do velké míry uplatněn v oblasti ochrany osobních údajů a dále v oblasti požadavků na kybernetickou bezpečnost „produktů s digitálními prvky“.
V GDPR známe princip „Data Protection by Design and by Default“. Článek 25 GDPR definuje obecný požadavek pro správce osobních údajů na zavedení vhodných technických a organizačních opatření tak, aby docházelo ke zpracování osobních údajů pouze v nezbytně nutném rozsahu. Princip uvedený v GDPR je formulován dosti obecně, nicméně je podrobně rozpracován ve vodítkách Evropského sboru pro ochranu osobních údajů č. 4/2019.
Druhou oblastí, která má vztah k principu „Secure by Design“, je bezpečnost „produktů s digitálními prvky“. Jedná se o návrh nařízení o horizontálních požadavcích na kybernetickou bezpečnost produktů s digitálními prvky. Toto nařízení, které čeká na projednání v Evropském parlamentu, má za cíl nadefinovat požadavky pro výrobce software tak, aby softwarové produkty byly uváděny na trh s minimem kybernetických bezpečnostních zranitelností a aby výrobci integrovali bezpečnost do celého životního cyklu produktu, včetně jeho návrhu a vývoje. Principy „Secure by Design“ a některé další požadavky na kybernetickou bezpečnost softwarových produktů nalezneme v příloze č. 1 (Základní požadavky na kybernetickou bezpečnost) a v příloze č. 2 (Informace a pokyny pro uživatele) návrhu nařízení.
3 základní prvky Secure by Design
Vraťme se ale k analyzovanému dokumentu. Jedná se o relativně stručný materiál (36 stran), který definuje tři základní principy z oblasti „Secure by Design“. Každý princip je podrobně vysvětlen včetně příkladů, jak tyto principy implementovat. Příklady jsou různého charakteru, dokument obsahuje například doporučení pro bezpečné výchozí nastavení aplikací nebo doporučení v oblasti transparentnosti a odpovědnosti v procesu vývoje produktů, ale i doporučení v oblasti obchodních politik týkajících se plateb za některé bezpečnostní funkcionality produktů.
3 základní prvky prvky Secure by Design jsou:
Princip 1: Take Ownership of Customer Security Outcomes - Přijmutí odpovědnosti za kybernetickou bezpečnost produktů
Princip 2: Embrace Radical Transparency and Accountability – Silná transparentnost a odpovědnost
Princip 3: Lead from the Top – Zapojení top managementu do kybernetické bezpečnosti produktů
První dva principy Dokument podrobně rozepisuje v následující struktuře:
Vysvětlení a popis principu
Postupy a příklady implementace
Příklady postupů pro bezpečný vývoj produktů
Související obchodní politiky
Třetí princip, který se týká role vrcholového vedení výrobce softwaru, obsahuje pouze vysvětlení principu a popis příkladů implementace.
Princip 1: Přijmutí odpovědnosti za kybernetickou bezpečnost produktů
První a základní princip je jednoduchý: Je jím přijmutí odpovědnosti výrobců za zajištění kybernetické bezpečnosti jejich produktů. Nehovoříme zde o odpovědnosti ve smyslu odpovědnosti za škodu, ale o obecném principu, při kterém je zajištění kybernetické bezpečnosti nedílnou součástí řádného vývoje a dodání softwarového produktu.
Tento požadavek se na první pohled může jevit jako triviální, nicméně v současnosti není zdaleka akceptován všemi výrobci software. Současný stav je takový, že řada výrobců se zaměřuje primárně na základní funkcionalitu svých softwarových produktů a jejich zabezpečení ponechávají na straně zákazníka. Důvod pro tento stav je zřejmý: Je jím nákladová efektivnost vývoje produktů, neboť zavedení principů kybernetické bezpečnosti do vývoje softwarových produktů může pro výrobce znamenat dodatečné finanční náklady.
Nabízí se otázka, proč by měl být za kybernetickou bezpečnost vyvinutého software odpovědný jeho tvůrce? Odpovědnost za kybernetickou bezpečnost softwarových produktů by měla být přenesena na výrobce proto, že mají ve svých rukou nejúčinnější metody, jak mohou snížit zranitelnosti svých produktů vůči kybernetickým hrozbám. Implementace prvků kybernetické bezpečnosti již ve fázi návrhu softwarových produktů je zdaleka nejúčinnější (ale i nákladově nejefektivnější) pro zajištění dostatečné úrovně kybernetické bezpečnosti produktu.
Pro současný stav je charakteristické, že kybernetickou bezpečnost softwarového produktu zajišťuje zákazník, často prostřednictvím dalších produktů třetích stran. Tento způsob zajištění kybernetické bezpečnosti je neefektivní a často dochází pouze k řešení „symptomů“, bezpečnostních problémů. Tímto přístupem však není možno odstranit příčiny bezpečnostních chyb a nedostatků, a proto může docházet k opakování bezpečnostních incidentů.
Příklady špatné praxe
Defaultní hesla. Výrobci dodávají své produkty často tak, že při jejich instalaci dochází k vytvoření administrátorských účtů, které jsou zabezpečeny defaultním heslem. Tato konfigurace představuje velkou bezpečnostní slabinu, zejména proto, že relativně běžným jevem je opomenutí přenastavení hesel při instalaci produktu zákazníkem. Použití defaultních hesel představuje nejjednodušší způsob kompromitace systému.
Aktivní komunikace bezpečnostních slabin a aktualizace produktu. Výrobci software by měli aktivně komunikovat se zákazníky o funkcionalitách produktu, jejichž bezpečnost byla kompromitována, a o způsobech zvýšení úrovně bezpečnosti produktů. Bezpečnostní aktualizace produktů by měla probíhat centralizovaně a měla by být zajišťována výrobcem software tak, aby bezpečnostní opravy probíhaly včasně a bezproblémově.
Upozornění na bezpečnostní hrozby. Softwarový produkt by měl mít implementovánu funkcionalitu bezpečnostních upozornění. Zákazníka by měl automaticky upozorňovat na nastavení, která představují bezpečnostní hrozbu (například nepoužívání vícefaktorové autentizace pro účty administrátorů).
Vytvoření šablon pro bezpečnou konfiguraci systému. Tento příklad doporučuje výrobcům software poskytnout zákazníkům několik šablon pro bezpečnostní konfiguraci systému, aby si mohl zákazník produkt nakonfigurovat v souladu se svým systémem řízení rizik a ochotou akceptovat bezpečnostní rizika (šablona pro nízkou/střední/vysokou bezpečnostní konfiguraci systému).
Doporučené postupy výrobce software
V oblasti praktik doporučených pro bezpečný vývoj produktů dokument ilustruje tento princip následujícími příklady:
Doložení souladu s rámcem pro bezpečný vývoj produktu SDL – Secure Development Lifecycle. Dokument výrobcům doporučuje, aby zdokumentovali a zveřejnili rámec, podle kterého probíhal bezpečný vývoj a aby zveřejňovali detailní popis SDL kontrol, které byly implementovány při návrhu a vývoji softwarového produktu.
Testování řízení bezpečnostních incidentů. Dokument doporučuje v rámci testování systému testovat i způsob identifikace bezpečnostního incidentů pomocí nástrojů typu SIEM a rovněž způsob reakce na bezpečnostní incident pomocí nástrojů typu SOAR. Cílem je ověřit, že vyvíjený sytém poskytuje monitorovacím a bezpečnostním systémům správné informace (logy) tak, aby došlo k efektivní identifikaci případného bezpečnostního incidentu a jeho rychlému zvládnutí.
Použití bezpečnostní architektury Zero Trust (ZTA). Dokument doporučuje výrobcům software, aby při návrhu bezpečnostní architektury produktu postupovali v souladu s principy ZTA. (ZTA představuje návrh integrované bezpečnostní architektury, který je založen na principu nedůvěry k jednotlivým prvkům informačního systému, bez ohledu na to, , jestli se nacházejí vně nebo uvnitř bezpečnostního perimetru. Bezpečnost na bázi nulové důvěry je zajišťována prostřednictvím technologií ověřování identity jak uživatele, tak zařízení před udělení přístupu k prvkům informačního systému.)
Doporučované obchodní politiky jsou například tyto:
Poskytovat funkcionalitu bezpečnostního logování v rámci základní ceny produktu. Softwarové produkty by měly defaultně zaznamenávat (logovat) bezpečnostní události a tato funkcionalita by neměla být zpoplatněna.
Odstranění plateb za bezpečnostní funkcionality. Dokument doporučuje výrobcům software přijmout závazek nevyžadovat další platby za bezpečnostní funkcionality sytému. Například se může jednat o dodatečné zpoplatnění integrace do systému řízení identit prostřednictvím SSO (Single Sign On) nebo zpoplatnění funkcionality vícefaktorové autentizace (MFA). Bezpečnost by neměla být považována za něco navíc, za „luxusní“ zboží, za které si je třeba připlatit, ale měla by být integrální součástí produktu a jeho ceny (podobně jako bezpečnostní pásy v autě nebo různé elektronické systémy pro zvýšení bezpečnosti jízdy).
Použití otevřených standardů. Dokument doporučuje výrobcům používaní otevřených standardů zejména v oblasti síťových protokolů a protokolů pro identifikaci a autentizaci.
Princip 2: Silná transparentnost a odpovědnost
Výrobci software by měli být v oblasti svého přístupu k zajištění bezpečnosti vyvíjených produktů transparentní, a tím se aktivně podílet na ochraně zákazníků. Dokument klade na transparentnost velký důraz a zastává názor, že transparentnost výrobců v této oblasti přináší benefity jak zákazníkům, tak celému softwarovému průmyslu. Transparentnost pomáhá definovat bezpečnostní standardy a podporuje jejich vývoj a adaptaci na měnící se potřeby zákazníků a měnící se hrozby. Snadná dostupnost relevantních informací rovněž pomáhá určit, co znamená best-practice, jinými slovy, jak vypadá "dobrý" bezpečný výrobek a pomáhá tyto konvence měnit v průběhu času v reakci na měnící se potřeby zákazníků, změny kybernetických bezpečnostních hrozeb či vývoj technologií.
Dokument obsahuje několik doporučení, jak transparentně komunikovat s klienty:
Zveřejňovat souhrnné statistiky a trendy o bezpečnosti produktu. Dokument doporučuje například zveřejňovat rozsah implementace MFA u zákazníků a administrátorů nebo používání zastaralých nezabezpečených protokolů.
Zveřejňovat statistiky týkající se bezpečnostních záplat. Dokument doporučuje publikovat informace o tom, kolik procent zákazníků používá aktualizované verze produktů. Dokument dále doporučuje zveřejnovat, jaké kroky výrobce činí, aby implementace bezpečnostních záplat probíhala co nejjednodušeji a nejspolehlivěji.
Zveřejňovat agregované informace o využívání oprávnění v aplikaci. Dokument doporučuje zveřejňovat agregované informace o používání příliš rozsáhlých oprávnění v aplikaci a naopak o nevyužívání některých oprávnění. Tyto informace mohou pro zákazníky představovat vodítko pro posouzení správného nastavení rolí a oprávnění.
Transparentnost výrobce software
V oblasti praktik doporučených pro bezpečný vývoj produktů dokument ilustruje druhý princip např. následujícími příklady:
Zveřejnit vybrané statistiky z vnitřního kontrolního systému. Dokument doporučuje výrobcům software nebo poskytovatelům služeb typ SaaS (Software as a Service) zveřejňovat statistiky týkající se efektivnosti jejich vnitřního kontrolního systému v oblasti kybernetické bezpečnosti (například statistiky týkající se úrovně nasazení MFA).
Publikovat model hrozeb. Dokument doporučuje zveřejnit model hrozeb, který byl použit při vývoji softwarového produktu.
Zveřejnit certifikaci o bezpečném vývoji SDL. Dokument doporučuje zveřejňovat certifikace prokazující soulad s použitou metodologií pro bezpečný vývoj softwarového produktu.
Doporučované obchodní politiky v oblasti principu transparentnost a odpovědnost jsou například:
Jmenovat a zveřejnit sponzora programu bezpečného vývoje, který je součástí vrcholného managementu společnosti. Dokument doporučuje jmenovat osobu z vedení společnosti odpovědnou za program bezpečného vývoje produktu. Tento krok zajistí, že program bezpečného vývoje bude součástí priorit vedení společnosti a bude mu tedy věnována adekvátní pozornost.
Zveřejnit plán rozvoje bezpečného vývoje produktů. Dokument doporučuje zveřejnit dlouhodobý plán rozvoje v oblasti bezpečného vývoje produktů (roadmapu). Tento krok posílí důvěru zákazníků v bezpečnost produktů a umožní organizaci po dosažení jednotlivých cílů v plánu rozvoje průběžně zveřejňovat postup plnění cílů. Tento krok přispívá nejen k demonstraci plnění závazků společnosti v této oblasti, ale může inspirovat další společnosti pro přijmutí obdobných plánů.
Princip 3: Zapojení top managementu do kybernetické bezpečnosti produktů
Tento princip je postaven na předpokladu, že bezpečnost vývoje produktů má být prioritou top managementu společnosti. Zavedení „kultury bezpečnosti“ a nastavení interních procesů společnosti tak, aby bezpečný vývoj produktů byl prioritou, není možné bez zapojení vrcholného vedení společnosti.
Cílem je, aby bezpečnost produktů byla součástí obchodních cílů společnosti, podobně jako v oblasti zajištění kvality produktů. Je třeba stanovit strategii a cíle v oblasti bezpečnosti produktů a vrcholné vedení společností by mělo tuto strategii aktivně podporovat.
Zajímavým prvkem je, že zde dokument zmiňuje pojem CCR – Corporate Cyber Responsibility a dává ho do analogického vztahu k již existující a zavedené oblasti CSR – Corporate Social Responsibility.
Dokument ilustruje implementaci třetího principu na následujících příkladech:
Zahrnout informace o programu bezpečného vývoje produktů do výroční zprávy společnosti. Představení programu kybernetické bezpečnosti produktů ve výroční zprávě společnosti ukáže veřejně, že organizace spojuje bezpečnost zákazníků se svými finančními výsledky a posílí tím důvěru zákazníků.
Zpráva CISO vedení společnosti. Manažer zodpovědný za kybernetickou bezpečnost společnosti (CISO) by měl pravidelně poskytovat vrcholovému vedení společnosti nejen informace o stavu kybernetické bezpečnosti společnosti ale i o úrovní bezpečnosti produktů a jejich dopadu na kybernetickou bezpečnost zákazníků.
Vytvořit smysluplné vnitřní pobídky. Management by měl do systému řízení firmy a do hodnocení výkonu zaměstnanců implementovat motivační pobídky podporující program bezpečného vývoje produktů.
Bezpečnost není nadstavba ani luxus
Dokument „Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software“ je poměrně obecným návodem pro výrobce softwarových produktů, jako do jejich praxe implementovat tři základní principy:
Princip odpovědnosti ze kybernetickou bezpečnost produktů
Princip silné transparentnosti a odpovědnosti
Princip zapojení top managementu do kybernetické bezpečnosti produktů
Dokument má charakter doporučení a „apelu“ na výrobce software. Nejedná se o metodiku pro bezpečný vývoj produktů. Opatření pro implementaci jednotlivých principů je nutno považovat pouze za příklady, které ilustrují použití principu v praxi.
Samozřejmě se všemi uvedenými principy nelze než souhlasit. Za velmi zajímavé a pro praxi potencionálně velmi přínosné považuji zejména doporučení týkající se obchodních politik společností, především v oblasti cenotvorby softwarových produktů. Bezpečnost by měla být považována za základní součást ceny produktu, nikoliv za „luxusní“ nadstavbu, za kterou je třeba si připlatit.
Z pohledu uživatele z České republiky je zajímavé, že se do tvorby dokumenty zapojil i NÚKIB. To ukazuje, že NÚKIB je v této oblasti aktivní a je považován za relevantní autoritu i v globálním měřítku.
