1 ze 100: Jak navrhnout týmy k překlenutí bezpečnostní mezery

1 ze 100

I když pracujete pro velkou organizaci, je pravděpodobné, že si budete pamatovat jména všech lidí, kteří pracují v oblasti IT. Je to proto, že podle nedávného průzkumu je poměr vývojářů k zabezpečení 100: 1 (stejná studie naznačuje poměr devs k ops 10: 1). Předchozí studie uváděly poměry od 100: 3 do 100: 6, takže došlo k určitému pokroku, ale ne dostatečně rychle.

To není dobré pro schopnost těchto organizací řešit připravovaná nařízení o ochraně osobních údajů, jako je GDPR Evropské unie, a zastavit šíření dat, které se pravidelně objevuje ve zprávách v posledních letech. Dnes tam není dost kvalifikovaných bezpečnostních lidí, aby vyplnili mezeru. Úspěšné přijetí bezpečných vývojových a provozních postupů vyžaduje nejen hluboké technické porozumění, ale také, kriticky, schopnost ovládat komunikační, přesvědčovací a vyrovnávací dovednosti, aby bylo možné získat od vývojových týmů a (častěji než ne) vyšší vedení.

Stále se nacházíme v začarovaném cyklu, kde specializace bezpečnosti není dostatečně atraktivní, protože společnosti historicky neposkytovaly zabezpečení dostatečně prioritu. Stejné společnosti nyní čelí rostoucí potřebě své bezpečnostní hry, ale postrádají lidi.

Jaké možnosti tedy musíme překlenout tuto bezpečnostní mezeru?

Nejprve si ujasníme, že automatizace základních bezpečnostních kontrol (jako jsou zranitelnosti třetích stran) a pokyny pro kódování a integrace zabezpečení do dodacího potrubí by dnes neměla být pro jakýkoli tým pro vývoj produktů naprostou záležitostí. Sada nástrojů v systému DevSecOps se neustále rozšiřuje a požadavky na komunitu i podnik jsou uspokojeny.

Tak kde je mezera? Je to „hackerské myšlení“, neustálé hledání nových potenciálních vektorů útoku v našich aplikacích („neznámé neznámé“). A je to také v těžkém úkolu smysluplné analýzy rizik a modelování hrozeb a jejich převedení do akcí a priorit. Vyžaduje to hluboké bezpečnostní myšlení a zázemí, není to něco, co týmy pro vývoj produktů mohou požádat, aby přijaly další přidanou kognitivní zátěž nad své stávající odpovědnosti.

Práce, kterou jsme s Matthewem Skeltonem provedli zkoumáním, katalogizací a vysvětlením toho, jak různé topologie DevOps mohou hrát důležitou roli při postupování nebo blokování adopce DevOps, dobře zapadá do tohoto problému.

Přicházejí v úvahu dvě odlišné (a možná doplňkové) týmové topologie:

A) Plně sdílené bezpečnostní povinnosti

B) Zabezpečení jako povolovací tým

Jaké jsou rozdíly, výhody a nevýhody každého přístupu?

Plně sdílená odpovědnost za bezpečnost znamená, že každý tým pro vývoj produktů integruje alespoň jednoho člena týmu T-tvaru zaměřeného na zabezpečení. Tento přístup je adekvátní, pokud se organizace snaží o mezifunkční autonomní týmy pro vývoj produktů. Bezpečnostní osoba musí být schopna převést složité bezpečnostní hrozby do bezpečnostních příběhů a kritérií přijatelnosti, které tým dokáže pochopit a implementovat z technického hlediska.

Musí být také schopni komunikovat rizika a možné náklady pro organizaci (dodržování předpisů, výnosy a pověst) způsobem, který mohou vlastníci podniků pochopit a stanovit si priority. Na druhou stranu by měli být připraveni v případě potřeby provádět úkoly, které se netýkají zabezpečení. V průběhu času by se v týmu mělo rozšířit vlastnictví bezpečnostní analýzy a implementace, zatímco bezpečnostní osoba ve tvaru písmene T by si mohla udržet odborné znalosti, pokud jde o to, aby zůstala na vrcholu osvědčených postupů v oblasti bezpečnosti, nových metod a nástrojů, usnadňovala workshopy související s bezpečností a vedoucí zabezpečení produktů strategie.

Cílem není, aby bezpečnostní osobě byla přidělena veškerá bezpečnostní práce, jinak přesuneme silo na makroúrovni (izolovaný bezpečnostní tým) na mikroúrovni (izolovaný člen týmu).
Každý produktový tým - zobrazený jako žlutý kruh - se 7 až 9 členy týmu, kde alespoň jeden je bezpečnostní osobou ve tvaru písmene T - zobrazený uvnitř zeleného kruhu - ale další lidé se rovněž účastní bezpečnostních prací

Samozřejmě stále existuje důležité místo pro centralizovaný pohled na bezpečnost napříč různými produkty a obchodními oblastmi v organizaci. Sdílení zkušeností, přístupů a výsledků je zásadní. Ale to může mít formu společenství praktik nebo cechu (v Spotify parlance) motivovaných jednotlivců, kteří se pravidelně scházejí, než specializovaný tým (i když to může také fungovat, pokud máte prostředky).

Klady

  • Vlastnictví bezpečnosti týmu vzroste, což povede k rychlejšímu (netriviálnímu) řešení bezpečnostních incidentů a možná ještě důležitější je od nich se poučit, aby se v budoucnu bolest nezopakovala.
  • Protože týmy mají přirozené omezení velikosti (8–9 lidí), měl by se poměr IT zaměstnanců k bezpečnosti (ve tvaru T) během této topologie týmu pohybovat mnohem blíže k 10: 1. Samotná rozmanitost technického zázemí přinese výhody, pokud jde o přístup k problémům a prioritám.
  • Přechod na tuto topologii vysílá nepopiratelný signál všem v organizaci, že bezpečnost je nyní v našich produktech prvotřídním občanem.

Nevýhody

  • Náklady na nalezení a nábor (což by mohlo vyžadovat štědré balíčky) a zvýšení počtu těchto dalších 9 bezpečnostních osob (v org se 100 vývojáři) budou vážným problémem (podle úvodního bodu tohoto příspěvku). Očekávejte, že tento přechod zabere značné množství času, během kterého budete potřebovat kombinaci modelů (některé autonomní týmy produktů a některé stále v závislosti na centralizovaném týmu), a přemýšlejte o strategii výběru týmů, které jdou jako první. Například začněte přiřazováním zkušenějších bezpečnostních skupin týmům, které pracují na rizikovějších produktech ve vaší organizaci.
  • Výkonné autonomní týmy jsou založeny na stabilitě a vzájemné znalosti silných a slabých stránek. Jakákoli změna složení týmu, dokonce i jediná osoba, nevyhnutelně způsobí nějaké narušení. Tým by mohl mít pocit, že přináší méně a stává se méně produktivní, přičemž se dívá na nový bezpečnostní úhel. Je zásadní, aby si každý uvědomil, že je to normální a přijatelné.
  • Nedostatek centralizovaného kontaktního místa pro obavy o bezpečnost. Zejména vedoucí pracovníci se mohou cítit, že v decentralizované struktuře není „nikdo za volantem bezpečnosti“. Zde může pomoci zajistit, aby existovaly komunikační kanály a lidé, kteří mohou nasměrovat žádosti o bezpečnostní informace do správných týmů (nebo do komunity praktických).

Heuristika

  • Má vaše organizace již k dispozici mezifunkční týmy, které integrují vlastníky podniků a vlastní odpovědnost za zajištění kvality a sledování a provozování aplikací, které vyvíjejí?
  • Zobrazují produkty (nebo služby) velmi odlišné rizikové profily?
  • Fungují produkty (nebo služby) na heterogenních technologických balíčcích a infrastruktuře?

Pokud je odpověď na ještě jednu z výše uvedených otázek kladná, pak by se tato topologie mohla ukázat jako vhodná k vyřešení bezpečnostní mezery.

Zabezpečení jako povolovacího týmu znamená tým vyhrazený pro zabezpečení, který týmům pro vývoj produktů poskytuje podporu a vedení (například vytváří pokyny pro bezpečný vývoj).

Je důležité, že centralizovaný bezpečnostní tým neprovádí skutečnou bezpečnostní analýzu a implementační práci, místo toho ji propaguje a vede tam, kde je to nutné.

Stejně důležité je, aby se tento tým zapojil od samého začátku projektu nebo vydání, aby pomohl produktovému týmu posoudit bezpečnostní důsledky, přístupy a postupy v každé fázi životního cyklu.

Průřezový bezpečnostní tým - zobrazený svisle šedě - podporuje tři týmy produktů - zobrazený vodorovně oranžově - což má za následek sdílenou odpovědnost za bezpečnost - zobrazený jako světle zelený kruh

Mnoho organizací přijalo tento přístup, včetně Spotify a Sportradar. Vyžaduje mnohem méně drastickou strukturální změnu oproti tradičnímu „bezpečnostnímu týmu silo“, protože v podstatě přesouváme odpovědnosti tohoto týmu (vedení a podpora spíše než implementace). To by však mohlo ostatním organizacím ztěžovat plně si uvědomit, že se očekává, že týmy produktů převezmou větší odpovědnost za zabezpečení svých systémů.

Pablo Jensen, technický ředitel společnosti Sportradar, nedávno hovořil o úloze svého týmu věnovaného informačnímu zabezpečení, který spočívá v podpoře bezpečnostních pokynů a politik v úzké spolupráci s týmy produktů, nasloucháním jejich zpětné vazbě a iteraci v průběhu času. Jednou z jejich bran v životním cyklu projektu je „způsobilost k zahájení vývoje“, která vyžaduje schválení bezpečnostním týmem, že bezpečnostním důsledkům byla věnována dostatečná pozornost a podle toho byla naplánována práce. Tento tým odpovídá přímo generálnímu řediteli a má v případě potřeby oprávnění k zastavení uvádění produktu na trh.

Role centralizovaného bezpečnostního týmu, který poskytuje vedení spíše než práci na zabezpečení produktu (Credit: Pablo Jensen, CTO ve společnosti Sportradar - snímky ze své prezentace QCon London 2018)

Klady

  • Kratší časový rámec pro přechod k modelu aktivace od tradičního izolovaného bezpečnostního týmu provádějícího většinu bezpečnostních prací.
  • Nebude vyžadovat velké množství nových najímání, čímž se vyhneme veškerému souvisejícímu úsilí a potencionálnímu narušení týmu. Zde by se mělo zaměřit na to, aby umožňující tým jako celek měl všechny potřebné měkké dovednosti, kromě technických dovedností.

Nevýhody

  • Tento tým musí zvládnout efektivní komunikaci, což samo o sobě je dobrá věc. Toto je dovednost, kterou je třeba časem honit, a proto může být vyžadováno počáteční investování do externí nebo interní pomoci při definování komunikačních strategií a obsahu kurátorů.
  • Přechod na tento model vysílá slabý signál o změně v zaměření zabezpečení. Signál musí být zesílen a může vyžadovat opakování po dlouhou dobu, dokud se nezapadne jako součást orgánové kultury.
  • Zavedení nových odpovědností, postupů a nástrojů může být pro týmy pro vývoj produktů náročné již na vrcholu své kapacity. Centralizovaný tým pro povolení by mohl být ohromen požadavky na pomoc a být vystaven tlaku, aby pomohl s implementací zabezpečení produktu, což by porazilo celý účel modelu.
  • V průběhu času by se bezpečnostní zaměření uvnitř produktových týmů mohlo vytrácet, aniž by se bezpečnostní osoba účastnila plánování uvolnění / sprintu týmu a denních standupů. Aby se tomu zabránilo, bude třeba zavést nějaký druh řízení.

Heuristika

  • Existuje malý počet týmů pro vývoj produktů (umožňujících užší spolupráci s týmem pro bezpečnost)?
  • Projevují členové produktového týmu zájem o bezpečnostní témata a chuť k učení (například účast na technických konferencích nebo setkáních)?
  • Zahrnuje řešení incidentů souvisejících s bezpečností ve výrobě přirozeně jak lidi zabývající se bezpečností, tak rozvojem (na rozdíl od hry viny, kde se každá strana vyhýbá odpovědnosti)?

Pokud je odpověď na ještě jednu z výše uvedených otázek kladná, pak by se tato topologie mohla ukázat jako vhodná k vyřešení bezpečnostní mezery.

Závěr

DevSecOps zvětšil profil bezpečnosti v IT a pravidelný proud vážných porušení dat odhalil bezpečnostní mezeru ve většině organizací. V tomto příspěvku jsem uvedl několik možných přístupů k překlenutí této mezery (plně sdílená odpovědnost za bezpečnost vs bezpečnost jako povolující tým), spolu s jejich klady a zápory a heuristikou založenou na kontextu.

Pamatujte, že týmový design by neměl být statický. Organizace, lidé a procesy se postupem času vyvíjejí přirozeně a to, co se dnes nejlépe hodí, může být zítřejší překážkou rychlejšího a bezpečnějšího softwaru. Je docela pravděpodobné, že by organizace nejprve přešla od tradičního přístupu k bezpečnostnímu silo k modelu „zabezpečení jako umožnění týmu“ při přechodu na čas a čas na strukturu „plně sdílených bezpečnostních povinností“, protože povědomí o bezpečnosti a odborné znalosti se šíří napříč týmy produktů.

Jaké další týmové topologie a bezpečnostní strategie jste viděli ve svých organizacích nebo klientech? Prosím komentář níže nebo napište mi na:

mě na manuelpais dot net