PSIRT: qué hace un equipo de respuesta a incidentes de seguridad de producto

¿Qué es un PSIRT?

Un Product Security Incident Response Team (PSIRT, equipo de respuesta a incidentes de seguridad de producto) es la función que gestiona las vulnerabilidades de seguridad de los productos que una empresa fabrica y vende. FIRST lo define como una entidad centrada en identificar, evaluar y resolver los riesgos asociados a las vulnerabilidades de seguridad de los productos, lo que incluye ofertas, soluciones, componentes y servicios.

En la práctica, un PSIRT:

• gestiona el canal por el que investigadores, clientes y socios notifican vulnerabilidades;
• vigila las vulnerabilidades de los componentes de terceros y de código abierto de sus productos;
• hace el triaje de cada informe: si es real, a qué productos y versiones afecta, qué gravedad tiene;
• consigue que el equipo de ingeniería responsable lo corrija, en un plazo acorde con el riesgo;
• publica avisos y coordina la divulgación con quienes descubren las vulnerabilidades y con los proveedores posteriores;
• informa de las métricas a la dirección y forma a las personas que construyen los productos.

La mayor parte del trabajo ocurre después del lanzamiento. FIRST señala que la mayoría de las vulnerabilidades de producto se notifican como fallos de calidad que se escapan una vez que el producto está en el mercado, aunque un PSIRT también aporta valor antes, en las revisiones de diseño y el modelado de amenazas.

Dónde se sitúa un PSIRT en la organización

La diferencia con otros equipos de seguridad es el enfoque en los productos. Un CSIRT corporativo protege los propios sistemas y redes de la empresa; un PSIRT protege a los clientes que utilizan los productos de la empresa. Ambos comparten habilidades y a menudo una línea jerárquica, y se encuentran cuando un incidente en la propia infraestructura de la empresa, como un sistema de build comprometido, llega a un producto. La comparación completa está en PSIRT frente a CSIRT.

FIRST describe tres modelos operativos:

• Distribuido: un pequeño PSIRT central fija la política y coordina, y los representantes de seguridad de cada equipo de producto hacen el triaje y las correcciones. Escala en una cartera grande y variada, pero las personas que hacen el trabajo no dependen del PSIRT.
• Centralizado: un PSIRT más grande con su propio personal de gestión de programas, triaje y corrección, que depende de un alto directivo de seguridad de producto. Encaja en empresas más pequeñas o con una cartera uniforme, y cuesta más a medida que crece la cartera.
• Híbrido: una mezcla de ambos, elegida según el tamaño de la empresa, la cartera y la estrategia de desarrollo.

Sea cual sea el modelo, FIRST insiste en la independencia: el PSIRT debe depender de un directivo que confirme su autoridad, para poder adoptar una posición objetiva sobre las vulnerabilidades de los productos de la propia empresa.

El FIRST PSIRT Services Framework

El PSIRT Services Framework, publicado gratuitamente por FIRST y ahora en su versión 1.1, es la referencia sobre la que la mayoría de los PSIRT construyen su catálogo de servicios. Establece unas bases operativas (mandato, partes interesadas, presupuesto, políticas) y después seis áreas de servicio:

Área de servicio	Qué cubre
1. Gestión del ecosistema de partes interesadas	Partes interesadas internas, la comunidad de descubridores, proveedores posteriores y clientes, comunicaciones de incidentes, reconocimiento de los descubridores, métricas de partes interesadas
2. Descubrimiento de vulnerabilidades	Recepción de informes de vulnerabilidades, búsqueda de vulnerabilidades no notificadas, monitorización de vulnerabilidades en los componentes del producto, identificación de nuevas vulnerabilidades, métricas de descubrimiento
3. Triaje y análisis de vulnerabilidades	Calificación de informes, colaboración con descubridores establecidos, reproducción de vulnerabilidades
4. Corrección	Plan de gestión del lanzamiento de correcciones, corrección, gestión de incidentes, métricas de lanzamiento
5. Divulgación de vulnerabilidades	Notificación, coordinación, divulgación mediante avisos, métricas de divulgación
6. Formación y educación	Formación del PSIRT, de los equipos de desarrollo y validación y de otras partes interesadas; mecanismos de retroalimentación

Merece la pena destacar un servicio porque se ha convertido en una parte importante del trabajo: la monitorización de vulnerabilidades en los componentes del producto. Su primera función es un inventario de componentes del producto, una lista de los proveedores, productos y versiones incluidos en cada producto, que FIRST considera esencial para identificar rápidamente los productos afectados por vulnerabilidades heredadas. En el software moderno, ese inventario es una lista de materiales de software (SBOM).

El proceso de un PSIRT de un vistazo

Dos normas ISO/IEC describen el proceso. ISO/IEC 30111:2019 cubre cómo gestiona internamente un proveedor las vulnerabilidades. ISO/IEC 29147:2018 cubre cómo recibe informes del exterior y publica la información de corrección. 30111 está pensada para usarse con 29147, y las fases que describe ofrecen un esquema útil:

1. Preparación. Política, funciones, una vía publicada para notificar vulnerabilidades, un método de puntuación, un inventario de lo que se distribuye.
2. Recepción. Reciba informes de investigadores, clientes, socios y sus propias pruebas, y de avisos sobre los componentes que utiliza. Acuse recibo a quien la descubrió.
3. Verificación. Confirme la vulnerabilidad, reprodúzcala, puntúela y determine todos los productos y versiones afectados. Registre también los productos no afectados y el motivo.
4. Desarrollo de la corrección. El equipo responsable crea y prueba una corrección o una mitigación. El PSIRT hace el seguimiento según el calendario acordado.
5. Lanzamiento. Distribuya la corrección y publique el aviso, en coordinación con quien la descubrió y con los proveedores posteriores que integran su producto.
6. Poslanzamiento. Vigile los problemas de la corrección, responda a los clientes y traslade las causas raíz al desarrollo.

Cada etapa, con lo que hay que registrar y quién la asume, se trata en el ciclo de vida de la gestión de vulnerabilidades. Para decidir qué hallazgos van primero, consulte la priorización de vulnerabilidades, con señales de explotación de EPSS y el catálogo CISA KEV. Una vulnerabilidad explotada antes de que exista una corrección es un zero-day, y el PSIRT la gestiona como un incidente. Cómo pasar de un aviso a un build corregido y distribuido se explica en la corrección de CVE.

Divulgación y avisos

La divulgación es la parte del PSIRT que ven los clientes. La práctica habitual es la divulgación coordinada de vulnerabilidades: quien la descubre la notifica en privado, el proveedor la corrige y ambos publican en una fecha acordada, con reconocimiento a quien la descubrió. Empieza con una política pública de divulgación de vulnerabilidades que indica cómo notificarlas, qué pueden esperar quienes las descubren y durante cuánto tiempo reciben soporte los productos. Consulte la divulgación coordinada de vulnerabilidades.

Un buen aviso indica a un cliente, sin necesidad de una llamada:

• qué productos y versiones están afectados, y cuáles no;
• el identificador CVE y una puntuación de gravedad;
• la versión corregida, o una mitigación si aún no hay corrección;
• quién la descubrió.

Los grandes clientes quieren cada vez más avisos en un formato legible por máquina que puedan cotejar automáticamente con su propio inventario de activos. CSAF es el formato estándar de OASIS para avisos, y VEX es la forma de declarar que un producto no está afectado por una vulnerabilidad de uno de sus componentes, lo que ahorra un ticket a ambas partes.

Métricas y madurez de un PSIRT

El marco incluye métricas en cada área de servicio. Las más habituales:

• tiempo para acusar recibo de un informe, para hacer su triaje y para lanzar una corrección, por gravedad;
• vulnerabilidades abiertas por producto, gravedad y antigüedad;
• proporción de correcciones entregadas dentro de los objetivos de corrección publicados;
• vulnerabilidades encontradas internamente frente a las notificadas desde fuera;
• avisos publicados y correcciones de avisos.

El documento complementario de FIRST, el PSIRT Maturity Document, ordena los servicios en tres niveles:

• Nivel 1, básico: patrocinio de la dirección, partes interesadas, presupuesto y políticas; una forma de recibir informes; un flujo de triaje; correcciones documentadas; avisos que usan CVE y CVSS y reconocen a quien descubrió la vulnerabilidad.
• Nivel 2, intermedio: un estatuto y un modelo organizativo, métricas de referencia, un registro de productos con mapa de dependencias, un plan formal de corrección, un sistema para notificar a las partes interesadas y formación para el equipo.
• Nivel 3, avanzado: relación directa con la comunidad de descubridores, monitorización de vulnerabilidades en los componentes del producto, métricas de descubrimiento y lanzamiento, gestión avanzada de incidentes y playbooks para la coordinación sectorial.

El avance entre niveles va de lo reactivo a lo proactivo.

Cómo crear un PSIRT: empiece poco a poco

1. Consiga un mandato por escrito de un directivo, con la autoridad para pedir a los equipos de producto que corrijan.
2. Publique cómo notificar una vulnerabilidad: una dirección de contacto de seguridad, un formulario web o un archivo security.txt, y una breve política de divulgación.
3. Defina el triaje y la puntuación: quién decide si un informe es válido, cómo se puntúa la gravedad y los objetivos de corrección por gravedad.
4. Sepa lo que distribuye. Para cada versión de producto, los componentes y versiones que contiene. Sin esto, cada nueva CVE en una biblioteca popular se convierte en días de preguntas a los equipos de ingeniería.
5. Nombre un responsable por producto que reciba los hallazgos y planifique las correcciones.
6. Redacte una plantilla de aviso y publique el primero, aunque sea por un problema menor.
7. Mida algunos plazos desde el principio, para poder demostrar la mejora.

La página para equipos PSIRT analiza la función desde el punto de vista del responsable de seguridad de producto, y los proveedores industriales pueden trasladar estos pasos a IEC 62443-4-1, cuyos requisitos del ciclo de vida de desarrollo seguro incluyen la gestión de defectos y la gestión de parches.

Normativas que esperan un PSIRT

Un PSIRT solía ser señal de un proveedor maduro. Ahora varios marcos piden sus resultados. El artículo 21(2)(e) de NIS2 incluye la gestión y divulgación de vulnerabilidades entre las medidas que deben adoptar las entidades esenciales e importantes. En EE. UU., la sección 524B exige a los fabricantes de dispositivos médicos presentar un plan para monitorizar, identificar y abordar las vulnerabilidades posteriores a la comercialización, incluida la divulgación coordinada de vulnerabilidades, junto con una SBOM. Y el Cyber Resilience Act de la UE exige a los fabricantes notificar a las autoridades las vulnerabilidades explotadas activamente y los incidentes graves, empezando por una alerta temprana en un plazo de 24 horas; consulte qué es el CRA.

Las herramientas que necesita un PSIRT

Necesidad	Por qué
Recepción de informes y seguimiento de casos	Cada informe tiene un responsable, un estado y un calendario
Inventario de lo que se distribuye	Una SBOM precisa por versión de producto, con las dependencias transitivas incluidas
Monitorización continua	Nuevas CVE cotejadas con los componentes de cada versión lanzada, no solo de la siguiente
Triaje y enrutamiento	Los hallazgos llegan al equipo responsable de la corrección, con el contexto necesario para actuar
Declaraciones de afectado y no afectado	VEX registra a qué productos afecta una vulnerabilidad y por qué los demás no están afectados
Publicación de avisos	Avisos legibles por personas y CSAF legible por máquina para los grandes clientes

Pocos productos cubren todas las filas; la comparativa de herramientas PSIRT muestra qué herramienta hace qué. El inventario es donde más dificultades tienen la mayoría de los PSIRT. Un escáner que lee lockfiles a posteriori enumera dependencias de desarrollo que nunca se distribuyen y pasa por alto paquetes que el build descargó fuera del gestor de paquetes, de modo que la respuesta a «¿nos afecta?» empieza con dudas.

CRACI obtiene ese inventario del propio build. Ejecuta los builds de GitHub Actions en sus propios runners y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas, los paquetes restaurados desde cachés de CI y las dependencias que ningún lockfile enumera. Cada SBOM incluye un estado de completitud y se exporta en CycloneDX o SPDX. Las SBOM monitorizadas se reevalúan continuamente a medida que se publican nuevas vulnerabilidades, el historial de builds muestra qué builds anteriores contenían una dependencia vulnerable, y la vista de inventario muestra qué versiones de software están desplegadas en qué productos. Los equipos de seguridad hacen el triaje de los hallazgos y los envían a los equipos responsables de la corrección, y CRACI es compatible con VEX. Consulte el seguimiento de vulnerabilidades y CRACI para equipos PSIRT.

PSIRT: preguntas frecuentes

¿Qué significa PSIRT?

PSIRT son las siglas de Product Security Incident Response Team, equipo de respuesta a incidentes de seguridad de producto. FIRST lo define como una entidad dentro de una organización centrada en identificar, evaluar y resolver los riesgos asociados a las vulnerabilidades de seguridad de los productos, ofertas, soluciones, componentes y servicios que la organización produce o vende.

¿Cuál es la diferencia entre un PSIRT y un CSIRT?

Un PSIRT gestiona las vulnerabilidades de los productos que una empresa distribuye a sus clientes. Un CSIRT corporativo gestiona los incidentes de seguridad en los propios sistemas y redes de la empresa. Ambos colaboran, por ejemplo cuando una brecha en la infraestructura de build afecta a un producto. Consulte PSIRT frente a CSIRT.

¿Qué es el FIRST PSIRT Services Framework?

Una guía gratuita de FIRST, el Forum of Incident Response and Security Teams, que enumera los servicios que puede prestar un PSIRT. La versión 1.1 los agrupa en seis áreas de servicio: gestión del ecosistema de partes interesadas, descubrimiento de vulnerabilidades, triaje y análisis de vulnerabilidades, corrección, divulgación de vulnerabilidades, y formación y educación. Un documento de madurez complementario ordena los servicios en tres niveles.

¿Qué normas describen el proceso de un PSIRT?

ISO/IEC 30111:2019 cubre cómo gestiona internamente un proveedor los informes de vulnerabilidades, desde la preparación y la recepción hasta la verificación, el desarrollo de la corrección, el lanzamiento y el poslanzamiento. ISO/IEC 29147:2018 cubre la interfaz con el exterior: recibir informes y publicar información de corrección. 30111 está pensada para usarse con 29147. IEC 62443-4-1 establece requisitos del ciclo de vida de desarrollo seguro, incluida la gestión de defectos y parches, para productos de automatización industrial.

¿Una empresa pequeña necesita un PSIRT?

Necesita la función, no necesariamente un departamento. El documento de madurez de FIRST empieza por el patrocinio de la dirección, partes interesadas identificadas, un presupuesto, algunas políticas, una vía publicada para notificar vulnerabilidades, un flujo de triaje, correcciones documentadas y avisos que reconocen a quien descubrió la vulnerabilidad. Una o dos personas con un mandato por escrito pueden encargarse de ello.

¿Qué herramientas necesita un PSIRT?

Como mínimo: una forma de recibir informes, un sistema de seguimiento de casos, un método de puntuación de vulnerabilidades, un inventario de qué componentes se distribuyen en qué versiones de producto, monitorización de esos componentes frente a nuevas vulnerabilidades, una forma de registrar si cada producto está afectado (a menudo como VEX) y una forma de publicar avisos, cada vez más en CSAF.