Manual de usuario del software del modelo de desarrollo de seguridad de AXIS

Software del modelo de desarrollo de seguridad de AXIS

Introducción

Objetivos de la ASDM
El modelo de desarrollo de seguridad de Axis (ASDM) es un marco que define el proceso y las herramientas utilizadas por Axis para crear software con seguridad integrada durante todo el ciclo de vida, desde el inicio hasta el desmantelamiento.

Los principales objetivos que impulsan los esfuerzos de ASDM son

• Haga de la seguridad del software una parte integrada de las actividades de desarrollo de software de Axis.
• Reduzca los riesgos comerciales relacionados con la seguridad para los clientes de Axis.
• Meet increasing awareness of security considerations by customers and partners.
• Crear potencial para la reducción de costos gracias a la detección temprana y la resolución de problemas.
  El alcance de ASDM es el software de Axis incluido en los productos y soluciones de Axis. El Software Security Group (SSG) es el propietario y mantenedor del ASDM.

Glosario

ASDM terminadoview

El ASDM comprende varias actividades repartidas en las principales fases de desarrollo. Las actividades de seguridad se identifican colectivamente como 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.

Grupo de seguridad de software (SSG)

SSG es la principal entidad de contacto interno con las organizaciones de desarrollo para cuestiones relacionadas con la seguridad. Está compuesto por líderes de seguridad y otras personas con conocimientos especializados en seguridad en áreas de desarrollo como requisitos, diseño, implementación, verificación,
así como procesos DevOps multifuncionales.
SSG es responsable del desarrollo y mantenimiento del ASDM para prácticas de desarrollo seguras y conciencia de seguridad en la organización de desarrollo.

Satélites
Los satélites son miembros de la organización de desarrollo que dedican parte de su tiempo a trabajar con aspectos de seguridad del software. Las razones para tener satélites son:

• Escale ASDM sin construir un gran SSG central
• Proporcionar soporte ASDM cerca de los equipos de desarrollo.
• Facilitar el intercambio de conocimientos, por ejemplo, mejores prácticas.
  Un satélite ayudará a implementar nuevas actividades y mantener el ASDM en un subconjunto de los equipos de desarrollo.

Lanzamiento de la actividad ASDM
El lanzamiento de la actividad ASDM a un equipo de desarrollo es tantagproceso educativo:

1. Se presenta al equipo la nueva actividad a través de una formación específica para cada función.
2. SSG trabaja junto con el equipo para realizar la actividad, por ejemplo, evaluación de riesgos o modelado de amenazas, para partes seleccionadas de los sistemas administrados por el equipo.
3. Otras actividades relacionadas con la integración de la caja de herramientas en el trabajo diario se entregarán al equipo y al satélite cuando estén listos para trabajar de forma independiente sin la participación directa del SSG. En esta fase el trabajo lo rige el jefe del equipo a través del estatus ASDM.
   La implementación se repite cuando hay nuevas versiones del ASDM disponibles con actividades modificadas y/o agregadas. La cantidad de tiempo que SSG dedica a un equipo depende en gran medida de la actividad y la complejidad del código. Un factor clave para una transferencia exitosa al equipo es la existencia de un satélite integrado que pueda continuar con el trabajo de ASDM con el equipo. SSG impulsa el aprendizaje y la asignación del satélite en paralelo con el lanzamiento de la actividad.
   La siguiente figura resume la metodología de implementación.

   

La definición de SSG de "hecho" para la transferencia es:

• Capacitación específica del rol realizada
• Satélite asignado
• El equipo está listo para realizar la actividad ASDM.
• Se establecieron reuniones periódicas sobre el estado de ASDM
  SSG utiliza los aportes de los equipos para elaborar informes de estado para la alta dirección.

Otras actividades del SSG
Paralelamente a las actividades de implementación, el SSG lleva a cabo actividades más amplias de capacitación en concientización sobre seguridad dirigidas, por ejemplo, a nuevos empleados y a la alta gerencia. Además, SSG mantiene un mapa de calor de seguridad de las soluciones de Axis con fines de evaluación de riesgos generales/arquitectónicos. Las actividades de análisis de seguridad proactivas para módulos específicos se realizan en función del mapa de calor.

Roles y responsabilidades
Como se muestra en la siguiente tabla, hay algunas entidades y roles clave que forman parte del programa ASDM. La siguiente tabla resume las funciones y responsabilidades en relación con el ASDM.

Gobernanza de la ASDM

El sistema de gobierno comprende las siguientes partes:

• Mapa de calor de riesgos del sistema para ayudar a priorizar las actividades de ASDM
• Plan de implementación y estado para centrarse en los esfuerzos de capacitación
• Hoja de ruta para evolucionar la caja de herramientas
• Estado para medir qué tan bien están integradas las actividades de ASDM en la organización.

De este modo, el sistema ASDM recibe apoyo tanto desde una perspectiva táctica/operacional como desde una perspectiva estratégica/ejecutiva.
La orientación ejecutiva en el lado derecho de la figura se centra en cómo desarrollar la organización para lograr una eficacia óptima en línea con los objetivos comerciales de Axis. Un aporte importante a esto es el informe de estado de ASDM realizado por SSG hacia el Grupo Directivo de Firmware, el CTO y la Gestión de Productos.

Estructura de estado de ASDM

La estructura de estado de ASDM tiene dos perspectivas: una centrada en el equipo que imita nuestra estructura de equipo y departamento, y una centrada en la solución que se centra en las soluciones que traemos al mercado.
La siguiente figura ilustra la estructura de estado de ASDM.

Estado del equipo
El estado del equipo contiene la autoevaluación del equipo sobre su madurez de ASDM, métricas relacionadas con sus actividades de análisis de seguridad, así como una agregación del estado de seguridad de los componentes de los que son responsables.

Axis define la madurez de ASDM como la versión de ASDM que el equipo utiliza actualmente. Dado que ASDM está evolucionando, hemos definido el control de versiones de ASDM donde cada versión de ASDM contiene un conjunto único de actividades. por ejemploampPor ejemplo, nuestra primera versión del ASDM se centra en el modelado de amenazas.
Axis ha definido las siguientes versiones de ASDM:

Darle al equipo la propiedad de qué versión de ASDM utilizan significa que es el superior directo el responsable de la adopción de nuevas versiones de ASDM. Entonces, en lugar de una configuración en la que SSG impulsa un plan de implementación de ASDM central, ahora se basa en la extracción y está controlado por los gerentes.

Estado del componente

• Tenemos una definición amplia de componente, ya que necesitamos cubrir todo tipo de entidades arquitectónicas que van desde los demonios de Linux en la plataforma, pasando por el software de servidor hasta los (micro)servicios en la nube.
• Cada equipo debe tomar su propia decisión sobre un nivel de abstracción que funcione para ellos en su entorno y arquitectura. Como regla general, los equipos deben evitar inventar un nuevo nivel de abstracción y conservar lo que ya estén usando en su trabajo diario.
• La idea es que cada equipo tenga una idea clara. view de todos sus componentes de alto riesgo, que incluyen componentes nuevos y heredados. La motivación de este mayor interés en los componentes heredados está vinculada a nuestra capacidad de observar el estado de seguridad de las soluciones. En el caso de una solución, queremos tener visibilidad del estado de seguridad de todas las partes de la solución, tanto nuevas como antiguas.
• En la práctica, esto significa que cada equipo debe examinar su inventario de componentes y realizar una evaluación de riesgos.
• Lo primero que debemos saber es si el componente ha sido sometido a análisis de seguridad. Si no es así, realmente no sabemos nada sobre la calidad de seguridad del componente.

A esto lo llamamos cobertura de propiedad y hemos definido los siguientes niveles de cobertura:

Las métricas que utilizamos para capturar la calidad de seguridad del componente se basan en los elementos de trabajo de seguridad en el trabajo pendiente que están vinculados al componente. Pueden ser contramedidas que no se han implementado, casos de prueba que no se han ejecutado y errores de seguridad que no se han solucionado.

Estado de la solución

El estado de la solución agrega el estado de seguridad de un conjunto de componentes que conforman la solución.
La primera parte del estado de la solución es la cobertura del análisis de los componentes. Esto ayuda a los propietarios de soluciones a comprender si se conoce el estado de seguridad de la solución o no. En una perspectiva, ayuda a identificar los puntos ciegos. El resto del estado de la solución contiene métricas que capturan la calidad de seguridad de la solución. Lo hacemos observando los elementos de trabajo de seguridad que están vinculados a los componentes de la solución. Un aspecto importante del estado de seguridad es la barra de errores definida por los propietarios de la solución. Los propietarios de la solución deben definir un nivel de seguridad apropiado para su solución. por ejemploampPor ejemplo, esto significa que la solución no debe tener elementos de trabajo pendientes, críticos o de alta gravedad, abiertos cuando se lance al mercado.

Actividades de ASDM

Evaluación de riesgos
El objetivo principal de la evaluación de riesgos es filtrar qué actividades de desarrollo también requerirán trabajo de seguridad dentro del equipo.
La evaluación de riesgos se realiza juzgando si un producto nuevo o una característica agregada/modificada en productos existentes aumenta la exposición al riesgo. Tenga en cuenta que esto también incluye aspectos de privacidad de datos y requisitos de cumplimiento. ExampLos archivos de cambios que tienen un impacto de riesgo son nuevas API, cambios en los requisitos de autorización, nuevo middleware, etc.

Privacidad de datos
La confianza es un área de enfoque clave para Axis y, como tal, es importante seguir las mejores prácticas al trabajar con datos privados recopilados por nuestros productos, soluciones y servicios.
El alcance de los esfuerzos de Axis relacionados con la privacidad de los datos se define de manera que podamos:

• Cumplir obligaciones legales
• Cumplir obligaciones contractuales
• Ayudar a los clientes a cumplir con sus obligaciones

Dividimos la actividad de privacidad de datos en dos subactividades:

• Evaluación de privacidad de datos
  • Realizado durante la evaluación de riesgos.
  • Identifica si es necesario un análisis de privacidad de datos
•  Análisis de privacidad de datos
  • Hecho, cuando corresponda, durante el modelado de amenazas.
  • Identifica datos personales y amenazas a datos personales.
  • Define los requisitos de privacidad.

Modelado de amenazas
Antes de comenzar a identificar amenazas, debemos decidir el alcance del modelo de amenazas. Una forma de articular el alcance es describir los atacantes que debemos considerar. Este enfoque también nos permitirá identificar las superficies de ataque de alto nivel que debemos incluir en el análisis.

• Durante el análisis del alcance de las amenazas, el foco está en encontrar y categorizar a los atacantes que queremos manejar utilizando una descripción de alto nivel del sistema. Preferiblemente, la descripción se realiza utilizando un diagrama de flujo de datos (DFD), ya que facilita relacionar las descripciones de casos de uso más detalladas que se utilizan al realizar el modelo de amenaza.
• Esto no significa que debamos considerar a todos los atacantes que identificamos, simplemente significa que somos explícitos y coherentes en cuanto a los atacantes que abordaremos en el modelo de amenazas. Entonces, esencialmente los atacantes que elijamos considerar definirán el nivel de seguridad del sistema que estemos evaluando.
  Tenga en cuenta que nuestra descripción del atacante no tiene en cuenta las capacidades ni la motivación del atacante. Hemos elegido este enfoque para simplificar y optimizar el modelado de amenazas tanto como sea posible.

  

El modelado de amenazas tiene tres pasos que se pueden repetir según lo considere conveniente el equipo:

1. Describir el sistema utilizando un conjunto de DFD.
2. Utilice los DFD para identificar amenazas y describirlas en un estilo de caso de abuso.
3. 3. Definir contramedidas y verificación de las amenazas.
   El resultado de una actividad de modelado de amenazas es un modelo de amenazas que contiene amenazas y contramedidas priorizadas. El trabajo de desarrollo necesario para abordar las contramedidas se gestiona mediante la creación de tickets de Jira tanto para la implementación como para la verificación de la contramedida.

   

Análisis de código estático
En ASDM, los equipos pueden utilizar el análisis de código estático de tres maneras:

• Flujo de trabajo del desarrollador: los desarrolladores analizan el código en el que están trabajando
• Flujo de trabajo de Gerrit: los desarrolladores obtienen comentarios en Gerrit
• Flujo de trabajo heredado: los equipos analizan componentes heredados de alto riesgo

  

Análisis de vulnerabilidades
El escaneo regular de vulnerabilidades permite a los equipos de desarrollo identificar y parchear las vulnerabilidades del software antes de que los productos se lancen al público, lo que reduce el riesgo de los clientes al implementar el producto o servicio. El escaneo se realiza antes de cada lanzamiento de hardware, software) o según un cronograma continuo (servicios) utilizando paquetes de escaneo de vulnerabilidades comerciales y de código abierto. Los resultados de los escaneos se utilizan para generar tickets en la plataforma de seguimiento de problemas de Jira. Los boletos reciben un precio especial. tag ser identificables por los equipos de desarrollo como provenientes de un escaneo de vulnerabilidades y que se les debe dar una prioridad elevada. Todos los análisis de vulnerabilidades y tickets de Jira se almacenan de forma centralizada con fines de trazabilidad y auditoría. Las vulnerabilidades críticas deben resolverse antes del lanzamiento o en una versión de servicio especial con otras vulnerabilidades no críticas.
rastreados y resueltos de acuerdo con el ciclo de lanzamiento de firmware o software. Para obtener más información sobre cómo se califican y gestionan las vulnerabilidades, consulte Gestión de vulnerabilidades en la página 12.

Pruebas de penetración externa
En casos seleccionados, se realizan pruebas de penetración de terceros en productos de hardware o software de Axis. El objetivo principal de ejecutar estas pruebas es proporcionar información y garantía sobre la seguridad de la plataforma en un momento determinado y para un alcance particular. Uno de nuestros principales objetivos con ASDM es la transparencia, por lo que animamos a nuestros clientes a realizar pruebas de penetración externas en nuestros productos y estaremos encantados de colaborar a la hora de definir los parámetros adecuados para las pruebas, así como discusiones sobre la interpretación de los resultados.

Gestión de vulnerabilidades
Axis es, desde 2021, una autoridad de nombres CVE (CNA) registrada y, por lo tanto, es capaz de publicar informes CVE estándar en la base de datos MITRE para que los utilicen escáneres de vulnerabilidades de terceros y otras herramientas. La placa de vulnerabilidad (VB) es el punto de contacto interno de Axis para las vulnerabilidades descubiertas por investigadores externos. Informes de
Las vulnerabilidades descubiertas y los planes de remediación posteriores se comunican a través del seguridad-producto@axis.com dirección de correo electrónico.
La principal responsabilidad de la junta de vulnerabilidad es analizar y priorizar las vulnerabilidades reportadas desde una perspectiva empresarial, en función de

• Clasificación técnica proporcionada por la SSG
• Riesgo potencial para los usuarios finales en el entorno en el que opera el dispositivo Axis
• Disponibilidad de controles de seguridad compensatorios (mitigación de riesgos alternativos sin parches)

El VB registra el número CVE y trabaja con el reportero para asignar una puntuación CVSS a la vulnerabilidad. El VB también impulsa la comunicación externa con socios y clientes a través del servicio de notificaciones de seguridad, comunicados de prensa y artículos de noticias de Axis.

Modelo de desarrollo de seguridad de Axis © Axis Communications AB, 2022