Návod na použitie softvéru AXIS Security Development Model Software

Softvér modelu vývoja zabezpečenia AXIS

Úvod

ASDM ciele
Axis Security Development Model (ASDM) je rámec, ktorý definuje proces a nástroje používané spoločnosťou Axis na vytváranie softvéru so zabudovaným zabezpečením počas celého životného cyklu, od začiatku až po vyradenie z prevádzky.

Primárne ciele, ktoré riadia úsilie ASDM, sú

• Urobte softvérovú bezpečnosť integrovanou súčasťou aktivít vývoja softvéru Axis.
• Znížte bezpečnostné riziká pre zákazníkov spoločnosti Axis.
• Meet increasing awareness of security considerations by customers and partners.
• Vytvorte potenciál na zníženie nákladov vďaka včasnému odhaleniu a vyriešeniu problémov
  Rozsah ASDM je softvér Axis zahrnutý v produktoch a riešeniach Axis. Vlastníkom a správcom ASDM je Software Security Group (SSG).

Slovník pojmov

ASDM skončilview

ASDM zahŕňa niekoľko aktivít rozložených do hlavných vývojových fáz. Bezpečnostné aktivity sú spoločne označené ako ASDM.

The SSG is responsible for governing the ASDM and evolving the toolbox over time. There is an ASDM roadmap and a rollout plan for implementing new activities and increasing ASDM maturity across the development organization. Both the roadmap and rollout plan are owned by the SSG, but the responsibility for actual implementation in practice (i.e., performing activities related to development phases) is delegated to the R&D teams.

Software Security Group (SSG)

SSG je hlavným interným kontaktným subjektom pre rozvojové organizácie pre otázky súvisiace s bezpečnosťou. Zahŕňa bezpečnostných vedúcich a ďalších so špecializovanými bezpečnostnými znalosťami v oblastiach vývoja, ako sú požiadavky, návrh, implementácia, overovanie,
ako aj medzifunkčné procesy DevOps.
SSG je zodpovedná za vývoj a údržbu ASDM pre bezpečné rozvojové postupy a povedomie o bezpečnosti vo vývojovej organizácii.

Satelity
Satelity sú členmi vývojovej organizácie, ktorí trávia časť svojho času prácou s aspektmi softvérovej bezpečnosti. Dôvody existencie satelitov sú:

• Škálujte ASDM bez budovania veľkého centrálneho SSG
• Poskytnite podporu ASDM v blízkosti vývojových tímov
• Uľahčiť zdieľanie znalostí, napr. osvedčených postupov
  Satelit bude pomáhať pri implementácii nových aktivít a udržiavaní ASDM v podskupine vývojových tímov.

Zavedenie aktivity ASDM
Zavedenie aktivít ASDM do vývojového tímu je akotaged proces:

1. Tím sa zoznámi s novou aktivitou prostredníctvom školenia špecifického pre rolu.
2. SSG spolupracuje s tímom na vykonávaní činnosti, napr. hodnotenia rizík alebo modelovania hrozieb, pre vybrané časti systému (systémov) riadených tímom.
3. Ďalšie činnosti súvisiace s integráciou súboru nástrojov do každodennej práce budú odovzdané tímu a satelitu, keď budú pripravené pracovať samostatne bez priamej účasti SSG. V tejto fáze prácu riadi tímový manažér cez status ASDM.
   Zavedenie sa opakuje, keď sú k dispozícii nové verzie ASDM s upravenými a/alebo pridanými aktivitami. Množstvo času, ktoré SSG strávi s tímom, veľmi závisí od aktivity a zložitosti kódu. Kľúčovým faktorom pre úspešné odovzdanie tímu je existencia zabudovaného satelitu, ktorý môže pokračovať v ďalšej ASDM práci s tímom. SSG riadi učenie sa a priraďovanie satelitu súbežne so zavádzaním aktivít.
   Na obrázku nižšie je zhrnutá metodika zavádzania.

   

SSG definícia „hotovo“ pre odovzdanie je:

• Vykonané školenie špecifické pre danú rolu
• Pridelený satelit
• Tím je pripravený vykonať aktivitu ASDM
• Boli vytvorené opakované stretnutia o stave ASDM
  SSG využíva vstupy od tímov na zostavovanie správ o stave smerom k vrcholovému manažmentu.

Ostatné činnosti SSG
Súbežne s aktivitami v oblasti zavádzania vykonáva SSG širšie školiace aktivity zamerané na zvyšovanie povedomia o bezpečnosti, ktoré sú zamerané napr. na nových zamestnancov a vyšší manažment. Okrem toho SSG udržiava bezpečnostnú tepelnú mapu riešení Axis na účely hodnotenia celkového/architektonického rizika. Aktivity proaktívnej bezpečnostnej analýzy pre konkrétne moduly sa vykonávajú na základe tepelnej mapy.

Úlohy a zodpovednosti
Ako je uvedené v tabuľke nižšie, existuje niekoľko kľúčových entít a rolí, ktoré sú súčasťou programu ASDM. V tabuľke nižšie sú zhrnuté úlohy a zodpovednosti vo vzťahu k ASDM.

Riadenie ASDM

Systém riadenia pozostáva z týchto častí:

• Tepelná mapa systémového rizika, ktorá vám pomôže uprednostniť aktivity ASDM
• Plán a stav zavádzania na zameranie sa na tréningové úsilie
• Plán vývoja súpravy nástrojov
• Stav na meranie toho, ako dobre sú aktivity ASDM integrované v organizácii

Systém ASDM je teda podporovaný tak z taktického/operačného hľadiska, ako aj zo strategického/výkonného hľadiska.
Výkonné usmernenia na pravej strane obrázku sa zameriavajú na to, ako rozvíjať organizáciu pre optimálnu efektivitu v súlade s obchodnými cieľmi spoločnosti Axis. Dôležitým vstupom je hlásenie stavu ASDM, ktoré vykonáva SSG smerom k Firmware Steering Group, CTO a Product Management.

Štruktúra stavu ASDM

Štruktúra stavu ASDM má dve perspektívy: jednu zameranú na tím napodobňujúcu štruktúru nášho tímu a oddelenia a jednu na riešenie zameranú na riešenia, ktoré prinášame na trh.
Na obrázku nižšie je znázornená štruktúra stavu ASDM.

Stav tímu
Stav tímu obsahuje tímové sebahodnotenie zrelosti ASDM, metriky súvisiace s ich aktivitami bezpečnostnej analýzy, ako aj agregáciu stavu bezpečnosti komponentov, za ktoré sú zodpovedné.

Axis definuje zrelosť ASDM ako verziu ASDM, ktorú tím momentálne používa. Keďže ASDM sa vyvíja, definovali sme ASDM verziovanie, kde každá verzia ASDM obsahuje jedinečný súbor aktivít. Naprample, naša prvá verzia ASDM je zameraná na modelovanie hrozieb.
Spoločnosť Axis definovala nasledujúce verzie ASDM:

Ak tímu priradíte, ktorú verziu ASDM používa, znamená to, že za prijatie nových verzií ASDM je zodpovedný priamy manažér. Takže namiesto nastavenia, kde SSG presadzuje centrálny plán zavádzania ASDM, sa teraz stáva založeným na ťahu a riadeným manažérmi.

Stav komponentu

• Máme širokú definíciu komponentu, pretože potrebujeme pokryť všetky druhy architektonických entít od démonov Linuxu v platforme, cez serverový softvér až po cloudové (mikro) služby.
• Každý tím si musí vytvoriť vlastný názor na úroveň abstrakcie, ktorá mu vyhovuje v jeho prostredí a architektúre. Tímy by sa spravidla mali vyhnúť vymýšľaniu novej úrovne abstrakcie a ponechať si všetko, čo už používajú pri svojej každodennej práci.
• Myšlienka je, že každý tím by mal mať jasno view všetkých ich vysokorizikových komponentov, čo zahŕňa nové aj staršie komponenty. Motivácia pre tento zvýšený záujem o staršie komponenty súvisí s našou schopnosťou pozrieť sa na stav zabezpečenia riešení. V prípade riešenia chceme mať prehľad o stave zabezpečenia všetkých nových aj starých častí riešenia.
• V praxi to znamená, že každý tím sa musí pozrieť na svoj inventár komponentov a vykonať hodnotenie rizika.
• Prvá vec, ktorú potrebujeme vedieť, je, či komponent prešiel bezpečnostnou analýzou. Ak nie, naozaj nevieme nič o kvalite zabezpečenia komponentu.

Toto pokrytie nehnuteľnosti nazývame a definovali sme nasledujúce úrovne krytia:

Metriky, ktoré používame na zachytenie kvality zabezpečenia komponentu, sú založené na pracovných položkách zabezpečenia v backlogu, ktoré sú prepojené s komponentom. Môžu to byť protiopatrenia, ktoré neboli implementované, testovacie prípady, ktoré neboli vykonané, a bezpečnostné chyby, ktoré neboli odstránené.

Stav riešenia

Stav riešenia agreguje stav zabezpečenia pre množinu komponentov, ktoré tvoria riešenie.
Prvou časťou stavu riešenia je analýza pokrytia komponentov. To pomáha vlastníkom riešení pochopiť, či je stav zabezpečenia riešenia známy alebo nie. V jednej perspektíve pomáha identifikovať slepé miesta. Zvyšok stavu riešenia obsahuje metriky, ktoré zachytávajú kvalitu zabezpečenia riešenia. Robíme to tak, že sa pozrieme na pracovné položky zabezpečenia, ktoré sú prepojené s komponentmi v riešení. Dôležitým aspektom stavu zabezpečenia je panel chýb definovaný vlastníkmi riešení. Vlastníci riešení musia definovať vhodnú úroveň zabezpečenia pre svoje riešenie. Napríkladample, to znamená, že pri uvedení na trh by riešenie nemalo mať otvorené žiadne nevyriešené kritické alebo vysoko závažné pracovné položky.

ASDM aktivity

Hodnotenie rizika
Hlavným účelom hodnotenia rizík je odfiltrovať, aké vývojové aktivity si budú vyžadovať aj bezpečnostnú prácu v rámci tímu.
Hodnotenie rizika sa vykonáva posúdením, či nový produkt alebo pridaná/upravená funkcia v existujúcich produktoch zvyšuje vystavenie riziku. Upozorňujeme, že to zahŕňa aj aspekty ochrany osobných údajov a požiadavky na súlad. NaprampMedzi zmeny, ktoré majú rizikový dopad, patria nové rozhrania API, zmeny požiadaviek na autorizáciu, nový middleware atď.

Ochrana osobných údajov
Dôvera je pre Axis kľúčovou oblasťou, a preto je dôležité dodržiavať osvedčené postupy pri práci so súkromnými údajmi zhromaždenými našimi produktmi, riešeniami a službami.
Rozsah úsilia spoločnosti Axis týkajúceho sa ochrany osobných údajov je definovaný tak, že môžeme:

• Plniť zákonné povinnosti
• Plniť zmluvné záväzky
• Pomôžte zákazníkom plniť si svoje záväzky

Činnosť ochrany osobných údajov rozdeľujeme na dve podaktivity:

• Posúdenie ochrany osobných údajov
  • Vykonáva sa počas hodnotenia rizika
  • Identifikuje, či je potrebná analýza ochrany osobných údajov
•  Analýza ochrany osobných údajov
  • V prípade potreby sa vykonáva počas modelovania hrozieb
  • Identifikuje osobné údaje a ohrozenia osobných údajov
  • Definuje požiadavky na súkromie

Modelovanie hrozieb
Skôr ako začneme s identifikáciou hrozieb, musíme sa rozhodnúť pre rozsah modelu hrozby. Spôsob, ako vyjadriť rozsah, je opísať útočníkov, ktorých musíme zvážiť. Tento prístup nám tiež umožní identifikovať povrchy útokov na vysokej úrovni, ktoré musíme zahrnúť do analýzy.

• Pri určovaní rozsahu hrozieb sa zameriavame na hľadanie a kategorizáciu útočníkov, s ktorými chceme zaobchádzať, pomocou popisu systému na vysokej úrovni. Opis sa prednostne vykonáva pomocou diagramu toku údajov (DFD), pretože to uľahčuje prepojenie podrobnejších popisov prípadov použitia, ktoré sa používajú pri vytváraní modelu hrozby.
• To neznamená, že je potrebné brať do úvahy všetkých útočníkov, ktorých identifikujeme, jednoducho to znamená, že sme jednoznační a konzistentní vo vzťahu k útočníkom, ktorých oslovíme v modeli hrozby. Takže v podstate útočníci, ktorých sa rozhodneme zvážiť, definujú úroveň zabezpečenia systému, ktorý posudzujeme.
  Upozorňujeme, že náš popis útočníka nezohľadňuje schopnosti alebo motiváciu útočníka. Tento prístup sme zvolili, aby sme čo najviac zjednodušili a zefektívnili modelovanie hrozieb.

  

Modelovanie hrozieb má tri kroky, ktoré je možné opakovať, ako tím uzná za vhodné:

1. Popíšte systém pomocou sady DFD
2. Použite DFD na identifikáciu hrozieb a popíšte ich v štýle zneužitia
3. 3. Definujte protiopatrenia a overenie hrozieb
   Výsledkom aktivity modelovania hrozieb je model hrozieb, ktorý obsahuje prioritné hrozby a protiopatrenia. Vývojové práce potrebné na riešenie protiopatrení sú riadené vytvorením lístkov Jira na implementáciu a overenie protiopatrenia.

   

Statická analýza kódu
V ASDM môžu tímy využívať analýzu statického kódu tromi spôsobmi:

• Pracovný postup vývojára: vývojári analyzujú kód, na ktorom pracujú
• Pracovný postup Gerrit: vývojári dostávajú spätnú väzbu v Gerrit
• Starý pracovný postup: tímy analyzujú vysoko rizikové staršie komponenty

  

Skenovanie zraniteľnosti
Pravidelné skenovanie zraniteľností umožňuje vývojovým tímom identifikovať a opravovať softvérové ​​zraniteľnosti pred uvedením produktov na trh, čím sa znižuje riziko zákazníkov pri nasadzovaní produktu alebo služby. Skenovanie sa vykonáva pred každým vydaním hardvéru, softvéru) alebo podľa spusteného plánu (služby) pomocou balíkov na skenovanie zraniteľností s otvoreným zdrojom aj komerčných. Výsledky skenov sa používajú na generovanie lístkov v platforme na sledovanie problémov Jira. Vstupenky sú dané špeciálne tag aby ich vývojové tímy identifikovali ako pochádzajúce zo skenovania zraniteľností a mali by mať vyššiu prioritu. Všetky skeny zraniteľností a lístky Jira sú uložené centrálne na účely sledovateľnosti a auditu. Kritické zraniteľnosti by mali byť vyriešené pred vydaním alebo v špeciálnom vydaní služby s inými, nekritickými zraniteľnosťami,
sledované a vyriešené v súlade s cyklom vydania firmvéru alebo softvéru. Ďalšie informácie o tom, ako sa bodujú a spravujú zraniteľnosti, nájdete v časti Správa zraniteľností na strane 12

Externé penetračné testovanie
Vo vybraných prípadoch sa na hardvérových alebo softvérových produktoch Axis vykonáva penetračné testovanie tretích strán. Hlavným účelom spustenia týchto testov je poskytnúť prehľad a uistenie o bezpečnosti platformy v určitom časovom bode a pre určitý rozsah. Jedným z našich primárnych cieľov v rámci ASDM je transparentnosť, preto povzbudzujeme našich zákazníkov, aby vykonávali externé penetračné testovanie našich produktov, a sme radi, že môžeme spolupracovať pri definovaní vhodných parametrov pre testovanie, ako aj pri diskusiách o interpretácii výsledkov.

Manažment zraniteľnosti
Spoločnosť Axis je od roku 2021 registrovanou autoritou pre pomenovanie CVE (CNA), a preto je schopná publikovať štandardné správy CVE do databázy MITER na použitie skenermi zraniteľnosti tretích strán a inými nástrojmi. Tabuľa zraniteľnosti (VB) je interným kontaktným bodom spoločnosti Axis pre zraniteľnosti objavené externými výskumníkmi. Hlásenie o
objavené slabiny a následné plány nápravy sú komunikované prostredníctvom product-security@axis.com emailová adresa.
Hlavnou zodpovednosťou rady pre zraniteľnosti je analyzovať a uprednostňovať nahlásené zraniteľnosti z obchodného hľadiska na základe

• Technickú klasifikáciu poskytuje SSG
• Potenciálne riziko pre koncových používateľov v prostredí, v ktorom zariadenie Axis pracuje
• Dostupnosť kompenzačných bezpečnostných kontrol, alternatívne zmiernenie rizika bez opravy)

VB zaregistruje číslo CVE a spolupracuje s reportérom na priradení skóre CVSS k zraniteľnosti. VB tiež riadi externú komunikáciu s partnermi a zákazníkmi prostredníctvom služby bezpečnostných upozornení Axis, tlačových správ a novinových článkov.

Model rozvoja bezpečnosti Axis © Axis Communications AB, 2022