Programari de model de desenvolupament de seguretat AXIS

Introducció

Objectius de l'ASDM
L'Axis Security Development Model (ASDM) és un marc que defineix el procés i les eines que utilitza Axis per crear programari amb seguretat integrada al llarg del cicle de vida, des de l'inici fins a la desactivació.

Els objectius principals que impulsen els esforços de l'ASDM són

• Feu que la seguretat del programari sigui una part integrada de les activitats de desenvolupament de programari d'Axis.
• Reduïu els riscos empresarials relacionats amb la seguretat per als clients d'Axis.
• Meet increasing awareness of security considerations by customers and partners.
• Creeu potencial de reducció de costos a causa de la detecció i resolució precoç dels problemes
  L'àmbit ASDM és el programari Axis inclòs als productes i solucions Axis. El Software Security Group (SSG) és el propietari i el responsable de l'ASDM.

Glossari

ASDM	Model de desenvolupament de seguretat de l'eix
SSG	Grup de seguretat de programari
Firmware direcció grup	Gestió de l'R+D
Satèl·lit	Desenvolupadors que tenen una afinitat natural per la seguretat del programari
Vulnerabilitat tauler	Punt de contacte de l'eix en relació a vulnerabilitats trobades per investigadors externs
Barra d'errors	Objectiu de seguretat per a un producte o solució
DFD	Diagrama de flux de dades

S'ha acabat l'ASDMview

L'ASDM comprèn diverses activitats repartides en les principals fases de desenvolupament. Les activitats de seguretat s'identifiquen col·lectivament com a 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.

Grup de seguretat de programari (SSG)

SSG és la principal entitat de contacte intern amb les organitzacions de desenvolupament per a qüestions relacionades amb la seguretat. Comprèn responsables de seguretat i altres amb coneixements especialitzats en seguretat en àrees de desenvolupament com ara requisits, disseny, implementació, verificació, etc.
així com processos de DevOps transversals.
SSG és responsable del desenvolupament i manteniment de l'ASDM per a pràctiques de desenvolupament segures i consciència de seguretat a l'organització de desenvolupament.

Satèl·lits
Els satèl·lits són membres de l'organització de desenvolupament que passen una part del seu temps treballant amb aspectes de seguretat del programari. Les raons per tenir satèl·lits són:

• Escaleu ASDM sense construir un gran SSG central
• Proporcioneu suport ASDM a prop dels equips de desenvolupament
• Facilitar l'intercanvi de coneixements, per exemple, bones pràctiques
  Un satèl·lit ajudarà a implementar noves activitats i mantenir l'ASDM en un subconjunt dels equips de desenvolupament.

Desplegament de l'activitat ASDM
El desplegament de l'activitat ASDM a un equip de desenvolupament és comtagprocés d'ed:

1. L'equip s'introdueix a la nova activitat mitjançant una formació específica per a cada funció.
2. SSG treballa conjuntament amb l'equip per dur a terme l'activitat, per exemple, avaluació de riscos o modelització d'amenaces, per a parts seleccionades dels sistemes gestionats per l'equip.
3. Altres activitats relacionades amb la integració de la caixa d'eines en el treball diari es lliuraran a l'equip i al satèl·lit quan estiguin preparats per treballar de manera independent sense la implicació directa del SSG. En aquesta fase, el treball es regeix pel responsable de l'equip a través de l'estat d'ASDM.
   El llançament es repeteix quan hi ha noves versions de l'ASDM disponibles amb activitats modificades i/o afegides. La quantitat de temps que passa SSG amb un equip depèn molt de l'activitat i la complexitat del codi. Un factor clau per a un traspàs reeixit a l'equip és l'existència d'un satèl·lit incrustat que pot continuar treballant amb l'ASDM amb l'equip. SSG impulsa l'aprenentatge i l'assignació del satèl·lit en paral·lel amb el desplegament de l'activitat.
   La figura següent resumeix la metodologia de desplegament.

   

La definició SSG de "fet" per al lliurament és:

• Formació específica del rol realitzada
• Satèl·lit assignat
• L'equip està preparat per realitzar l'activitat ASDM
• S'estableixen reunions recurrents d'estat de l'ASDM
  SSG utilitza les aportacions dels equips per reunir informes d'estat per a la direcció superior.

Altres activitats de SSG
Paral·lelament a les activitats de desplegament, el SSG duu a terme activitats de formació de conscienciació sobre seguretat més àmplies dirigides, per exemple, als nous empleats i a l'alta direcció. A més, SSG manté un mapa de calor de seguretat de les solucions d'Axis amb finalitats d'avaluació del risc global/arquitectònic. Les activitats d'anàlisi de seguretat proactiva per a mòduls específics es realitzen a partir del mapa de calor.

Funcions i responsabilitats
Com es mostra a la taula següent, hi ha algunes entitats i funcions clau que formen part del programa ASDM. La taula següent resumeix les funcions i les responsabilitats en relació amb l'ASDM.

Rol/Entitat	Part de	Responsabilitat	Comenta
Expert en seguretat	SSG	Governa ASDM, evoluciona la caixa d'eines i impulsa el desplegament de l'ASDM	100% assignat a SSG
Satèl·lit	Línia de desenvolupament	Ajudeu SSG a implementar ASDM per primera vegada, entreneu equips, realitzeu entrenaments i assegureu-vos que l'equip pugui continuar utilitzant Toolbox com a part del treball diari, independentment de SSG. Es requereix responsabilitat entre equips (diversos equips) per limitar el nombre total de satèl·lits.	Desenvolupadors, arquitectes, gestors, provadors i funcions similars interessats i compromesos que tenen una afinitat natural per la seguretat del programari. Els satèl·lits destinen almenys el 20% del seu temps a treballs relacionats amb ASDM.
Gestors	Línia de desenvolupament	Recursos segurs per a la implementació de pràctiques ASDM. Seguiment i informes sobre l'estat i la cobertura de l'ASDM.	Els equips de desenvolupament posseeixen la implementació d'ASDM, amb SSG com a recurs de suport.
Grup de direcció de firmware (FW SG)	Gestió de l'R+D	Decideix l'estratègia de seguretat i actua com a canal principal d'informació de SSG.	SSG informa a FW SG de manera regular.

Govern de l'ASDM

El sistema de govern consta de les parts següents:

• Mapa de calor de risc del sistema per ajudar a prioritzar les activitats de l'ASDM
• Pla de desplegament i estat per centrar-se en els esforços de formació
• Full de ruta per evolucionar la caixa d'eines
• Estat per mesurar la integració de les activitats de l'ASDM a l'organització

Així, el sistema ASDM es recolza tant des d'una perspectiva tàctica/operativa com des d'una perspectiva estratègica/executiva.
La guia executiva a la part dreta de la figura se centra en com desenvolupar l'organització per obtenir una eficàcia òptima d'acord amb els objectius empresarials d'Axis. Una entrada important a això és l'informe d'estat de l'ASDM realitzat per SSG cap al grup de direcció del firmware, el CTO i la gestió de productes.

Estructura d'estat de l'ASDM

L'estructura d'estat de l'ASDM té dues perspectives: una centrada en l'equip que imita l'estructura del nostre equip i departament, i una altra centrada en la solució centrada en les solucions que aportem al mercat.
La figura següent il·lustra l'estructura d'estat de l'ASDM.

Estat de l'equip
L'estat de l'equip conté l'autoavaluació de l'equip de la seva maduresa ASDM, mètriques relacionades amb les seves activitats d'anàlisi de seguretat, així com una agregació de l'estat de seguretat dels components dels quals són responsables.

Axis defineix la maduresa de l'ASDM com la versió d'ASDM que l'equip utilitza actualment. Com que l'ASDM està evolucionant, hem definit la versió de l'ASDM on cada versió de l'ASDM conté un conjunt únic d'activitats. Per exampi, la nostra primera versió de l'ASDM se centra en el modelatge d'amenaces.
Axis ha definit les següents versions d'ASDM:

Versió ASDM	Noves activitats
ASDM 1.0	Avaluació de riscos i modelització d'amenaces
ASDM 2.0	Codi estàtic review
ASDM 2.1	Privadesa per disseny
ASDM 2.2	Anàlisi de la composició del programari
ASDM 2.3	Proves de penetració externa
ASDM 2.4	Escaneig de vulnerabilitats i simulacre d'incendi
ASDM 2.5	Estat de seguretat del producte/solució

Donar a l'equip la propietat de quina versió d'ASDM utilitzen significa que és el responsable de línia el responsable de l'adopció de noves versions d'ASDM. Així, en lloc d'una configuració on SSG impulsa un pla central de desplegament d'ASDM, ara es basa en l'extracció i el controlen els gestors.

Estat dels components

• Tenim una definició àmplia de component, ja que necessitem cobrir tot tipus d'entitats arquitectòniques que van des de dimonis Linux a la plataforma, passant per programari de servidor fins a serveis (micro) al núvol.
• Cada equip ha de decidir un nivell d'abstracció que li funcioni en el seu entorn i arquitectura. Com a regla general, els equips haurien d'evitar inventar un nou nivell d'abstracció i mantenir el que ja estan utilitzant en el seu treball diari.
• La idea és que cada equip ho tingui clar view de tots els seus components d'alt risc, que inclou components nous i antics. La motivació d'aquest interès creixent pels components heretats està lligada a la nostra capacitat per analitzar l'estat de seguretat de les solucions. En el cas d'una solució, volem tenir visibilitat de l'estat de seguretat de totes les parts de la solució, tant noves com antigues.
• A la pràctica, això significa que cada equip ha de mirar el seu inventari de components i fer una avaluació de riscos.
• El primer que hem de saber és si el component ha estat sotmès a una anàlisi de seguretat. Si no és així, realment no sabem res sobre la qualitat de seguretat del component.

Anomenem aquesta cobertura de propietat i hem definit els nivells de cobertura següents:

Cobertura	Descripció
Anàlisi no feta	El component encara no s'ha analitzat
Anàlisi en curs	S'està analitzant el component
Anàlisi feta	S'ha analitzat el component

Les mètriques que utilitzem per capturar la qualitat de seguretat del component es basen en els elements de treball de seguretat del backlog que estan vinculats al component. Això poden ser contramesures que no s'han implementat, casos de prova que no s'han executat i errors de seguretat que no s'han resolt.

Estat de la solució

L'estat de la solució agrega l'estat de seguretat d'un conjunt de components que componen la solució.
La primera part de l'estat de la solució és la cobertura d'anàlisi dels components. Això ajuda els propietaris de la solució a entendre si es coneix l'estat de seguretat de la solució o si no. En una perspectiva, ajuda a identificar els punts cecs. La resta de l'estat de la solució conté mètriques que capturen la qualitat de seguretat de la solució. Ho fem mirant els elements de treball de seguretat que estan vinculats als components de la solució. Un aspecte important de l'estat de seguretat és la barra d'errors definida pels propietaris de la solució. Els propietaris de la solució han de definir un nivell de seguretat adequat per a la seva solució. Per exampAixò vol dir que la solució no hauria de tenir oberts elements de treball crítics o d'alta gravetat pendents quan es llanci al mercat.

Activitats de l'ASDM

Avaluació de riscos
L'objectiu principal de l'avaluació de riscos és filtrar quines activitats de desenvolupament també requeriran treball de seguretat dins de l'equip.
L'avaluació del risc es fa jutjant si un producte nou o una característica afegit/modificada en productes existents augmenta l'exposició al risc. Tingueu en compte que això també inclou aspectes de privadesa de dades i requisits de compliment. ExampEls fitxers de canvis que tenen un impacte en el risc són noves API, canvis en els requisits d'autorització, programari intermedi nou, etc.

Privadesa de les dades
La confiança és una àrea d'enfocament clau per a Axis i, per tant, és important seguir les millors pràctiques quan es treballa amb dades privades recopilades pels nostres productes, solucions i serveis.
L'abast dels esforços d'Axis relacionats amb la privadesa de dades es defineix de manera que puguem:

• Complir obligacions legals
• Complir les obligacions contractuals
• Ajudar els clients a complir amb les seves obligacions

Dividim l'activitat de privadesa de dades en dues subactivitats:

• Avaluació de la privadesa de les dades
  • Fet durant l'avaluació de riscos
  • Identifica si és necessària una anàlisi de privadesa de dades
•  Anàlisi de la privadesa de les dades
  • Fet, quan escaigui, durant la modelització d'amenaces
  • Identifica dades personals i amenaces a les dades personals
  • Defineix els requisits de privadesa

Modelatge de l'amenaça
Abans de començar a identificar les amenaces, hem de decidir l'abast del model d'amenaça. Una manera d'articular l'abast és descriure els atacants que hem de tenir en compte. Aquest enfocament també ens permetrà identificar les superfícies d'atac d'alt nivell que hem d'incloure en l'anàlisi.

• Durant l'abast de l'amenaça, l'objectiu és trobar i categoritzar els atacants que volem gestionar mitjançant una descripció d'alt nivell del sistema. Preferiblement, la descripció es fa mitjançant un diagrama de flux de dades (DFD) ja que facilita relacionar les descripcions de casos d'ús més detallades que s'utilitzen quan es fa el model d'amenaça.
• Això no vol dir que tots els atacants que identifiquem hagin de ser considerats, simplement vol dir que som explícits i coherents amb els atacants als quals abordarem en el model d'amenaça. Així, bàsicament, els atacants que triem considerar definiran el nivell de seguretat del sistema que estem avaluant.
  Tingueu en compte que la nostra descripció de l'atacant no té en compte les capacitats o la motivació de l'atacant. Hem escollit aquest enfocament per simplificar i racionalitzar el modelatge d'amenaces tant com sigui possible.

  

El modelatge d'amenaces té tres passos que es poden repetir segons l'equip cregui convenient:

1. Descriu el sistema utilitzant un conjunt de DFD
2. Utilitzeu els DFD per identificar les amenaces i descriure-les amb un estil d'abús
3. 3. Definir contramesures i verificació de les amenaces
   El resultat d'una activitat de modelització d'amenaces és un model d'amenaça que conté amenaces i contramesures prioritzades. El treball de desenvolupament necessari per abordar les contramesures es gestiona mitjançant la creació de tickets Jira tant per a la implementació com per a la verificació de la contramesura.

   

Anàlisi de codi estàtic
A l'ASDM, els equips poden utilitzar l'anàlisi de codi estàtic de tres maneres:

• Flux de treball del desenvolupador: els desenvolupadors analitzen el codi en què estan treballant
• Flux de treball de Gerrit: els desenvolupadors reben comentaris a Gerrit
• Flux de treball heretat: els equips analitzen components heretats d'alt risc

  

Escaneig de vulnerabilitats
L'exploració regular de vulnerabilitats permet als equips de desenvolupament identificar i corregir les vulnerabilitats del programari abans que els productes s'alliberin al públic, reduint el risc dels clients a l'hora de desplegar el producte o servei. L'escaneig es realitza abans de cada llançament de maquinari, programari) o en un programa d'execució (serveis) utilitzant paquets d'exploració de vulnerabilitats de codi obert i comercials. Els resultats de les exploracions s'utilitzen per generar bitllets a la plataforma de seguiment de problemes Jira. Les entrades tenen un especial tag que siguin identificables pels equips de desenvolupament com a provinents d'una exploració de vulnerabilitats i que se'ls hauria de donar una prioritat elevada. Tots els escanejos de vulnerabilitats i els tiquets de Jira s'emmagatzemen de manera centralitzada amb finalitats de traçabilitat i auditoria. Les vulnerabilitats crítiques s'han de resoldre abans del llançament o en una versió de servei especial amb altres vulnerabilitats no crítiques,
rastrejat i resolt d'acord amb el cicle de llançament del microprogramari o programari. Kor més informació sobre com es puntuen i gestionen les vulnerabilitats, vegeu Gestió de vulnerabilitats a la pàgina 12

Proves de penetració externa
En casos determinats, es realitzen proves de penetració de tercers en productes de maquinari o programari d'Axis. L'objectiu principal d'executar aquestes proves és proporcionar informació i seguretat sobre la seguretat de la plataforma en un moment determinat i per a un àmbit concret. Un dels nostres objectius principals amb l'ASDM és la transparència, de manera que animem els nostres clients a realitzar proves de penetració externes als nostres productes i estem encantats de col·laborar a l'hora de definir els paràmetres adequats per a les proves, així com les discussions sobre la interpretació dels resultats.

Gestió de vulnerabilitats
Axis és, des del 2021, una autoritat de nomenclatura CVE (CNA) registrada i, per tant, capaç de publicar informes de CVE estàndard a la base de dades MITRE perquè els consumeixin escàners de vulnerabilitats de tercers i altres eines. El tauler de vulnerabilitats (VB) és el punt de contacte intern de l'Eix per a les vulnerabilitats descobertes per investigadors externs. Reportatge de
les vulnerabilitats descobertes i els plans de correcció posteriors es comuniquen a través del product-security@axis.com adreça de correu electrònic.
La responsabilitat principal del consell de vulnerabilitats és analitzar i prioritzar les vulnerabilitats denunciades des d'una perspectiva empresarial, basada en

• Classificació tècnica proporcionada per la SSG
• Risc potencial per als usuaris finals a l'entorn en què opera el dispositiu Axis
• Disponibilitat de controls de seguretat compensadors i mitigació alternativa de riscos sense pegat)

El VB registra el número de CVE i treballa amb el reporter per assignar una puntuació CVSS a la vulnerabilitat. El VB també impulsa la comunicació externa amb socis i clients mitjançant el servei de notificació de seguretat d'Axis, notes de premsa i articles de notícies.

Model de desenvolupament de seguretat d'Axis © Axis Communications AB, 2022

Documents/Recursos

Programari de model de desenvolupament de seguretat AXIS [pdfManual d'usuari Model de desenvolupament de seguretat, programari, programari de model de desenvolupament de seguretat

Referències

• Manual d'usuari