Software-ul pentru modele de dezvoltare a securității AXIS

Introducere

Obiectivele ASDM
Modelul de dezvoltare a securității Axis (ASDM) este un cadru care definește procesul și instrumentele utilizate de Axis pentru a construi software cu securitate încorporată pe tot parcursul ciclului de viață, de la început până la dezafectare.

Obiectivele principale care conduc eforturile ASDM sunt

• Faceți din securitatea software o parte integrată a activităților de dezvoltare software Axis.
• Reduceți riscurile de afaceri legate de securitate pentru clienții Axis.
• Meet increasing awareness of security considerations by customers and partners.
• Creați potențial de reducere a costurilor datorită detectării timpurii și soluționării problemelor
  Domeniul ASDM este software-ul Axis inclus în produsele și soluțiile Axis. Software Security Group (SSG) este proprietarul și menținătorul ASDM.

Glosar

ASDM	Modelul de dezvoltare a securității axei
SSG	Grupul de securitate software
Firmware director grup	management R&D
Satelit	Dezvoltatori care au o afinitate naturală pentru securitatea software-ului
Vulnerabilitate bord	Punctul de contact al axei în legătură cu vulnerabilitățile găsite de cercetători externi
Bara de bug-uri	Țintă de securitate pentru un produs sau soluție
DFD	Diagrama fluxului de date

ASDM s-a terminatview

ASDM cuprinde mai multe activități repartizate în fazele majore de dezvoltare. Activitățile de securitate sunt identificate colectiv ca 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 este principala entitate de contact intern cu organizațiile de dezvoltare pentru probleme legate de securitate. Acesta cuprinde lideri de securitate și alții cu cunoștințe de securitate specializate în domenii de dezvoltare, cum ar fi cerințe, proiectare, implementare, verificare,
precum și procesele DevOps interfuncționale.
SSG este responsabil pentru dezvoltarea și întreținerea ASDM pentru practicile de dezvoltare sigure și conștientizarea securității în organizația de dezvoltare.

Sateliți
Sateliții sunt membri ai organizației de dezvoltare care își petrec o parte din timp lucrând cu aspectele de securitate software. Motivele pentru care avem sateliți sunt:

• Scalați ASDM fără a construi un SSG central mare
• Oferiți suport ASDM aproape de echipele de dezvoltare
• Facilitați schimbul de cunoștințe, de exemplu, cele mai bune practici
  Un satelit va ajuta la implementarea de noi activități și menținerea ASDM într-un subset al echipelor de dezvoltare.

Lansarea activității ASDM
Lansarea activității ASDM către o echipă de dezvoltare este catagproces ed:

1. Echipa este introdusă în noua activitate prin instruire specifică rolului.
2. SSG lucrează împreună cu echipa pentru a efectua activitatea, de exemplu, evaluarea riscurilor sau modelarea amenințărilor, pentru anumite părți ale sistemului (sistemelor) gestionate de echipă.
3. Alte activități legate de integrarea setului de instrumente în munca de zi cu zi vor fi predate echipei și satelitului atunci când aceștia sunt gata să lucreze independent, fără implicarea directă a SSG. În această fază, munca este guvernată de managerul echipei prin statutul ASDM.
   Lansarea se repetă atunci când sunt disponibile versiuni noi ale ASDM cu activități modificate și/sau adăugate. Timpul petrecut de SSG cu o echipă depinde în mare măsură de activitate și de complexitatea codului. Un factor cheie pentru predarea cu succes a echipei este existența unui satelit încorporat care poate continua munca ASDM cu echipa. SSG stimulează învățarea și atribuirea satelitului în paralel cu lansarea activității.
   Figura de mai jos rezumă metodologia de lansare.

   

Definiția SSG a „terminat” pentru predare este:

• Antrenament specific rol efectuat
• Satelit alocat
• Echipa este pregătită să desfășoare activitatea ASDM
• Stabilirea ședințelor recurente ale ASDM
  SSG folosește contribuțiile echipelor pentru a aduna rapoarte de stare către conducerea superioară.

Alte activități SSG
În paralel cu activitățile de lansare, SSG desfășoară activități de formare mai ample de conștientizare a securității, care vizează, de exemplu, noi angajați și conducerea superioară. În plus, SSG menține o hartă termică de securitate a soluțiilor Axis în scopul evaluării riscurilor generale/arhitecturale. Activitățile de analiză proactivă a securității pentru anumite module sunt efectuate pe baza hărții termice.

Roluri și responsabilități
După cum se arată în tabelul de mai jos, există câteva entități și roluri cheie care fac parte din programul ASDM. Tabelul de mai jos rezumă rolurile și responsabilitățile în legătură cu ASDM.

Rol/Entitate	O parte din	Responsabilitate	Comentariu
Expert în securitate	SSG	Guvernați ASDM, evoluați setul de instrumente și conduceți lansarea ASDM	100% atribuit SSG
Satelit	Linia de dezvoltare	Ajută SSG să implementeze ASDM prima dată, antrenează echipe, efectuează training-uri și asigură-te că echipa poate continua să folosească Toolbox ca parte a muncii zilnice, independent de SSG. Responsabilitatea între echipe (mai multe echipe) necesară pentru a limita numărul total de sateliți.	Dezvoltatori, arhitecți, manageri, testeri și roluri similare interesați și implicați, care au o afinitate naturală pentru securitatea software-ului. Sateliții alocă cel puțin 20% din timpul lor lucrărilor legate de ASDM.
Managerii	Linia de dezvoltare	Securizarea resurselor pentru implementarea practicilor ASDM. Conduceți urmărirea și raportarea privind starea și acoperirea ASDM.	Echipele de dezvoltare dețin implementarea ASDM, cu SSG ca resursă de suport.
Firmware Steering Group (FW SG)	management R&D	Decide cu privire la strategia de securitate și acționează ca principal canal de raportare SSG.	SSG raportează la FW SG în mod regulat.

Guvernarea ASDM

Sistemul de guvernare cuprinde următoarele părți:

• Harta termică a riscurilor sistemului pentru a ajuta la prioritizarea activităților ASDM
• Plan de lansare și stare pentru a se concentra pe eforturile de formare
• Foaia de parcurs pentru a evolua setul de instrumente
• Status pentru a măsura cât de bine sunt integrate activitățile ASDM în organizație

Sistemul ASDM este astfel susținut atât din perspectivă tactică/operațională, cât și din perspectivă strategică/executivă.
Îndrumările executive din partea dreaptă din figură se concentrează asupra modului de dezvoltare a organizației pentru o eficiență optimă în conformitate cu obiectivele de afaceri ale Axei. O contribuție importantă în acest sens este raportarea stării ASDM efectuată de SSG către Grupul de Direcție pentru Firmware, CTO și Managementul Produsului.

Structura statutului ASDM

Structura statutului ASDM are două perspective: una centrată pe echipă, care imită structura noastră de echipă și departament, și una centrată pe soluții, concentrându-se pe soluțiile pe care le aducem pe piață.
Figura de mai jos ilustrează structura stării ASDM.

Statutul echipei
Starea echipei conține autoevaluarea echipei a maturității sale ASDM, metrici legate de activitățile lor de analiză de securitate, precum și o agregare a stării de securitate a componentelor pentru care sunt responsabile.

Axis definește maturitatea ASDM ca versiunea ASDM pe care echipa o folosește în prezent. Deoarece ASDM evoluează, am definit versiunea ASDM în care fiecare versiune a ASDM conține un set unic de activități. De example, prima noastră versiune a ASDM este axată pe modelarea amenințărilor.
Axis a definit următoarele versiuni ASDM:

Versiunea ASDM	Activități noi
ASDM 1.0	Evaluarea riscurilor și modelarea amenințărilor
ASDM 2.0	Cod static review
ASDM 2.1	Confidențialitate prin design
ASDM 2.2	Analiza compoziției software
ASDM 2.3	Testare de penetrare externă
ASDM 2.4	Scanarea vulnerabilităților și exercițiul de incendiu
ASDM 2.5	Starea securității produsului/soluției

Oferirea echipei de proprietate asupra versiunii ASDM pe care o utilizează înseamnă că managerul de linie este responsabil pentru adoptarea noilor versiuni ASDM. Deci, în loc de o configurație în care SSG împinge un plan central de lansare ASDM, acesta devine acum bazat pe pull și controlat de manageri.

Starea componentelor

• Avem o definiție largă a componentei, deoarece trebuie să acoperim tot felul de entități arhitecturale, de la demonii Linux din platformă, prin software-ul server până la serviciile cloud (micro).
• Fiecare echipă trebuie să-și decidă un nivel de abstractizare care funcționează pentru ei în mediul și arhitectura lor. Ca regulă generală, echipele ar trebui să evite inventarea unui nou nivel de abstractizare și să păstreze tot ceea ce folosesc deja în munca lor zilnică.
• Ideea este ca fiecare echipa sa aiba un clar view dintre toate componentele lor cu risc ridicat, care include componente noi, precum și componente vechi. Motivația pentru acest interes sporit pentru componentele vechi este legată de capacitatea noastră de a analiza starea de securitate a soluțiilor. În cazul unei soluții, dorim să avem vizibilitate asupra stării de securitate a tuturor părților soluției noi și vechi.
• În practică, aceasta înseamnă că fiecare echipă trebuie să se uite la inventarul lor de componente și să facă o evaluare a riscurilor.
• Primul lucru pe care trebuie să-l știm este dacă componenta a fost supusă unei analize de securitate. Dacă nu a făcut-o, chiar nu știm nimic despre calitatea securității componentei.

Numim această acoperire a proprietății și am definit următoarele niveluri de acoperire:

Acoperire	Descriere
Analiza nu a fost facuta	Componenta nu a fost încă analizată
Analiza in curs	Componenta este în curs de analiză
Analiza facuta	Componenta a fost analizată

Valorile pe care le folosim pentru a captura calitatea securității componentei se bazează pe elementele de lucru de securitate din backlog care sunt legate de componentă. Acestea pot fi contramăsuri care nu au fost implementate, cazuri de testare care nu au fost executate și erori de securitate care nu au fost rezolvate.

Starea soluției

Starea soluției adună starea de securitate pentru un set de componente care alcătuiesc soluția.
Prima parte a stării soluției este acoperirea analizei componentelor. Acest lucru îi ajută pe proprietarii de soluții să înțeleagă dacă starea de securitate a soluției este cunoscută sau nu. Într-o perspectivă, ajută la identificarea punctelor moarte. Restul stării soluției conține valori care surprind calitatea securității soluției. Facem asta analizând elementele de lucru de securitate care sunt legate de componentele din soluție. Un aspect important al stării de securitate este bara de erori definită de proprietarii soluției. Proprietarii soluției trebuie să definească un nivel de securitate adecvat pentru soluția lor. De exampasta înseamnă că soluția nu ar trebui să aibă obiecte de lucru critice sau de mare severitate deschise atunci când este lansată pe piață.

Activitati ASDM

Evaluare a riscurilor
Scopul principal al evaluării riscurilor este de a filtra activitățile de dezvoltare care vor necesita, de asemenea, munca de securitate în cadrul echipei.
Evaluarea riscurilor se face prin evaluarea dacă un produs nou sau o caracteristică adăugată/modificată în produsele existente mărește expunerea la risc. Rețineți că aceasta include și aspectele privind confidențialitatea datelor și cerințele de conformitate. Exampfișierele modificărilor care au un impact asupra riscului sunt noile API-uri, modificări ale cerințelor de autorizare, noi middleware etc.

Confidențialitatea datelor
Încrederea este un domeniu cheie de interes pentru Axis și, ca atare, este important să urmați cele mai bune practici atunci când lucrați cu date private colectate de produsele, soluțiile și serviciile noastre.
Sfera eforturilor Axis legate de confidențialitatea datelor sunt definite astfel încât să putem:

• Îndepliniți obligațiile legale
• Îndepliniți obligațiile contractuale
• Ajutați clienții să-și îndeplinească obligațiile

Împărțim activitatea de confidențialitate a datelor în două sub-activități:

• Evaluarea confidențialității datelor
  • Efectuat în timpul evaluării riscului
  • Identifică dacă este necesară analiza confidențialității datelor
•  Analiza confidențialității datelor
  • Efectuat, atunci când este cazul, în timpul modelării amenințărilor
  • Identifică datele personale și amenințările la adresa datelor personale
  • Definește cerințele de confidențialitate

Modelarea amenințărilor
Înainte de a începe identificarea amenințărilor, trebuie să decidem asupra domeniului de aplicare al modelului de amenințări. O modalitate de a articula domeniul de aplicare este de a descrie atacatorii pe care trebuie să-i luăm în considerare. Această abordare ne va permite, de asemenea, să identificăm suprafețele de atac la nivel înalt pe care trebuie să le includem în analiză.

• În timpul delimitării amenințărilor se concentrează pe găsirea și clasificarea atacatorilor pe care vrem să-i gestionăm folosind o descriere la nivel înalt a sistemului. De preferință, descrierea se face folosind o diagramă a fluxului de date (DFD), deoarece facilitează relația cu descrierile mai detaliate ale cazurilor de utilizare care sunt utilizate atunci când se realizează modelul de amenințare.
• Acest lucru nu înseamnă că toți atacatorii pe care îi identificăm trebuie luați în considerare, înseamnă pur și simplu că suntem expliciți și consecvenți cu privire la atacatorii pe care îi vom aborda în modelul de amenințare. Deci, în esență, atacatorii pe care alegem să îi luăm în considerare vor defini nivelul de securitate al sistemului pe care îl evaluăm.
  Rețineți că descrierea atacatorului nu ține cont de capabilitățile sau motivația atacatorului. Am ales această abordare pentru a simplifica și eficientiza pe cât posibil modelarea amenințărilor.

  

Modelarea amenințărilor are trei pași care pot fi repetați după cum consideră echipa:

1. Descrieți sistemul folosind un set de DFD
2. Utilizați DFD-urile pentru a identifica amenințările și pentru a le descrie într-un stil de caz de abuz
3. 3. Definiți contramăsuri și verificare pentru amenințări
   Rezultatul unei activități de modelare a amenințărilor este un model de amenințare care conține amenințări și contramăsuri prioritizate. Munca de dezvoltare necesară pentru abordarea contramăsurilor este gestionată prin crearea de tichete Jira atât pentru implementarea, cât și pentru verificarea contramăsurilor.

   

Analiza codului static
În ASDM, echipele pot utiliza analiza codului static în trei moduri:

• Flux de lucru pentru dezvoltatori: dezvoltatorii analizează codul la care lucrează
• Flux de lucru Gerrit: dezvoltatorii primesc feedback în Gerrit
• Flux de lucru vechi: echipele analizează componentele moștenite cu risc ridicat

  

Scanarea vulnerabilităților
Scanarea regulată a vulnerabilităților permite echipelor de dezvoltare să identifice și să corecteze vulnerabilitățile software înainte ca produsele să fie lansate publicului, reducând riscul clienților atunci când implementează produsul sau serviciul. Scanarea este efectuată înainte de fiecare lansare de hardware, software) sau pe un program de rulare (servicii), folosind atât pachete de scanare a vulnerabilităților cu sursă deschisă, cât și comerciale. Rezultatele scanărilor sunt folosite pentru a genera bilete în platforma de urmărire a problemelor Jira. Biletele primesc o specială tag să fie identificabile de către echipele de dezvoltare ca provenind dintr-o scanare a vulnerabilităților și că ar trebui să li se acorde o prioritate ridicată. Toate scanările de vulnerabilități și biletele Jira sunt stocate central în scopuri de trasabilitate și audit. Vulnerabilitățile critice trebuie rezolvate înainte de lansare sau într-o versiune specială a serviciului cu alte vulnerabilități necritice,
urmărite și rezolvate în conformitate cu ciclul de lansare a firmware-ului sau a software-ului. Pentru mai multe informații despre cum sunt punctate și gestionate vulnerabilitățile, consultați Gestionarea vulnerabilităților la pagina 12

Testare de penetrare externă
În anumite cazuri, testele de penetrare terță parte sunt efectuate pe produse hardware sau software Axis. Scopul principal al rulării acestor teste este de a oferi informații și asigurări cu privire la securitatea platformei la un anumit moment de timp și pentru un anumit domeniu. Unul dintre obiectivele noastre principale cu ASDM este transparența, așa că ne încurajăm clienții să efectueze teste externe de penetrare a produselor noastre și suntem bucuroși să colaborăm la definirea parametrilor adecvați pentru testare, precum și la discuții despre interpretarea rezultatelor.

Managementul vulnerabilităților
Axis este, din 2021, o autoritate de denumire CVE (CNA) înregistrată și, prin urmare, este capabilă să publice rapoarte standard CVE în baza de date MITRE pentru consumul de către scanere de vulnerabilități terțe și alte instrumente. Placa de vulnerabilitate (VB) este punctul de contact intern al Axei pentru vulnerabilitățile descoperite de cercetători externi. Raportarea de
vulnerabilitățile descoperite și planurile ulterioare de remediere sunt comunicate prin intermediul product-security@axis.com Adresa de e-mail.
Responsabilitatea principală a consiliului de vulnerabilitate este să analizeze și să prioritizeze vulnerabilitățile raportate din perspectiva afacerii, pe baza

• Clasificarea tehnică oferită de SSG
• Risc potențial pentru utilizatorii finali în mediul în care funcționează dispozitivul Axis
• Disponibilitatea controalelor de securitate compensatoare și atenuarea alternativă a riscului fără corecție)

VB înregistrează numărul CVE și lucrează cu reporterul pentru a atribui un scor CVSS vulnerabilității. VB conduce, de asemenea, comunicarea externă către parteneri și clienți prin serviciul de notificare de securitate Axis, comunicate de presă și articole de știri.

Modelul de dezvoltare a securității Axis © Axis Communications AB, 2022

Documente/Resurse

Software-ul pentru modele de dezvoltare a securității AXIS [pdfManual de utilizare Model de dezvoltare de securitate, software, software de model de dezvoltare de securitate

Referințe

• Manual de utilizare