PSIRT
PSIRT vs CSIRT: vulnerabilidades de producto e incidentes en su propia TI
Un CSIRT responde cuando se ataca a sus propios sistemas. Un PSIRT responde cuando los productos que usted vende tienen una vulnerabilidad a la que están expuestos sus clientes. Ambos son equipos de respuesta a incidentes, ambos siguen marcos de FIRST y, en un incidente real, a menudo se necesitan mutuamente.
Actualizado el
¿Qué es un CSIRT?
Un CSIRT (Computer Security Incident Response Team, equipo de respuesta a incidentes de seguridad informática) es el equipo que gestiona los incidentes de seguridad de un grupo definido de personas u organizaciones, denominado su comunidad de referencia. El CSIRT Services Framework de FIRST lo define como una unidad organizativa, que puede ser virtual, o una capacidad que presta servicios a esa comunidad para prevenir, detectar, gestionar y responder a incidentes de seguridad informática.
La comunidad de referencia determina de qué tipo de CSIRT se trata:
- CSIRT corporativo: las redes, los sistemas, las cuentas y los datos de una empresa.
- CSIRT sectorial: un grupo de organizaciones de un sector, como las finanzas o la energía.
- CSIRT nacional: todo un país, a menudo con un papel en la coordinación transfronteriza.
- Equipo del proveedor: los clientes de una empresa, para problemas en sus productos. Este es el PSIRT.
El CSIRT Services Framework (versión 2.1) agrupa los servicios de un CSIRT en cinco áreas: gestión de eventos de seguridad de la información, gestión de incidentes de seguridad de la información, gestión de vulnerabilidades, conciencia situacional y transferencia de conocimiento.
¿Qué es un PSIRT?
Un PSIRT (Product Security Incident Response Team, equipo de respuesta a incidentes de seguridad de producto) es, según FIRST, la entidad de una organización que se centra en identificar, evaluar y resolver los riesgos asociados a las vulnerabilidades de seguridad de los productos que esa organización fabrica o vende. Recibe los informes de vulnerabilidades, determina qué productos y versiones están afectados, consigue que se desarrolle y distribuya una corrección e informa a los clientes mediante avisos de seguridad.
Su marco, el PSIRT Services Framework (versión 1.1), tiene 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.
La diferencia clave
La diferencia está en de quién son los sistemas en riesgo. Un CSIRT protege a la organización: el incidente está en su entorno y usted lo contiene. Un PSIRT protege a sus clientes: la vulnerabilidad está en su producto, que se ejecuta en los entornos de ellos, y usted no puede parchearla por ellos. Usted distribuye una corrección y les indica que la instalen.
FIRST lo expresa con claridad: el enfoque en los productos es el factor diferenciador clave entre un PSIRT y otros equipos de respuesta a incidentes de la misma organización, y un CSIRT corporativo se centra por lo general en los sistemas y las redes que componen la infraestructura propia de la organización.
Comparativa de PSIRT y CSIRT
| CSIRT corporativo | PSIRT | |
|---|---|---|
| Alcance | Incidentes en las redes, los sistemas y los datos propios de la organización | Vulnerabilidades en los productos que distribuye la organización |
| Comunidad de referencia | Empleados y sistemas internos | Clientes y usuarios de los productos |
| Entradas habituales | Alertas, registros, informes de usuarios, inteligencia de amenazas | Informes de investigadores, avisos sobre componentes de terceros, pruebas internas, coordinadores |
| Resultados habituales | Incidentes contenidos, sistemas recuperados, revisiones posteriores al incidente | Versiones corregidas, avisos de seguridad, registros CVE, notificaciones a clientes |
| Inicio del plazo | Cuando se detecta un incidente | Cuando se notifica o se publica una vulnerabilidad |
| Responsable habitual | El CISO o la seguridad de TI | Seguridad de producto o ingeniería |
| Marco de FIRST | CSIRT Services Framework 2.1 | PSIRT Services Framework 1.1 |
| Normas | ISO/IEC 27035 (gestión de incidentes) | ISO/IEC 29147 (divulgación de vulnerabilidades), ISO/IEC 30111 (gestión de vulnerabilidades) |
Ambos marcos subrayan que los equipos no trabajan de forma aislada. El marco de PSIRT describe a los CSIRT, incluidos los nacionales, como partes interesadas con las que un PSIRT debe establecer relaciones, porque a menudo son la vía por la que un proveedor se entera pronto de una vulnerabilidad.
CERT vs CSIRT
El primer equipo de este tipo fue el CERT Coordination Center, que, según el SEI, surgió de la respuesta al gusano Morris en 1988, con financiación de DARPA, en el Software Engineering Institute de Carnegie Mellon. CERT es una marca registrada en Estados Unidos por la Universidad Carnegie Mellon, y el SEI autoriza a los equipos estadounidenses a usarla en sus nombres. Ya no concede licencias de la marca fuera de Estados Unidos.
Por tanto, «CERT» y «CSIRT» describen el mismo tipo de equipo. CSIRT es el término neutro, utilizado por FIRST y en la legislación de la UE; muchos equipos, sobre todo los nacionales, siguen llevando CERT en su nombre.
CSIRT nacionales y coordinadores
Algunas organizaciones son importantes para un equipo de producto porque se sitúan entre quienes encuentran vulnerabilidades, los proveedores y los usuarios:
- CERT/CC coordina la divulgación de vulnerabilidades de software desde 1988 y publica una guía de divulgación coordinada de vulnerabilidades para las organizaciones que crean su propio proceso.
- CISA coordina la divulgación entre notificadores, fabricantes y usuarios en Estados Unidos, y puede publicar a partir de los 45 días desde el primer intento de contactar con un proveedor que no responde, exista o no una corrección.
- CSIRT nacionales de la UE. NIS2 exige a cada Estado miembro designar o crear uno o varios CSIRT, que cooperan en la red de CSIRT junto con CERT-EU. ENISA, la agencia de ciberseguridad de la UE, se encarga de su secretaría.
Los CSIRT nacionales también tienen un papel formal en la notificación de vulnerabilidades. Con arreglo al artículo 12 de NIS2, cada Estado miembro designa un CSIRT como coordinador de la divulgación coordinada de vulnerabilidades: un intermediario de confianza entre quien notifica una vulnerabilidad y el fabricante, que puede identificar a los proveedores afectados, ayudar a quien la notifica y negociar los plazos de divulgación. El Cyber Resilience Act se apoya en ese mismo papel: los fabricantes notifican las vulnerabilidades explotadas activamente en sus productos al CSIRT designado como coordinador y a ENISA al mismo tiempo.
Cómo colaboran un PSIRT y un CSIRT
Piense en un componente de código abierto vulnerable que se está explotando y que se utiliza tanto en su producto como en sus sistemas internos. Ambos equipos reciben el mismo aviso, y cada uno tiene su propio trabajo:
- CSIRT: localiza el componente en servidores y portátiles internos, revisa los registros en busca de explotación, aplica parches o aísla, y gestiona un incidente si algo se ha visto comprometido.
- PSIRT: determina qué productos, versiones y builds incluyen el componente, evalúa si el producto está afectado, distribuye una versión corregida y publica un aviso, con una declaración VEX para las versiones que no están afectadas.
- Ambos: comparten indicadores y cronologías. Si el CSIRT descubre que el ataque llegó al sistema de build, el PSIRT tiene que comprobar si se manipuló alguna versión distribuida, lo que convierte un incidente interno en uno de producto. Un ataque a la cadena de suministro suele cruzar esta línea.
El paso que frena al PSIRT es el segundo. Un CSIRT puede escanear su propio parque. Un PSIRT tiene que responder por software que ya está en manos de los clientes, lo que significa saber qué contiene cada versión que ha distribuido. Las páginas sobre el ciclo de vida de la gestión de vulnerabilidades y la divulgación coordinada de vulnerabilidades cubren el resto del camino del PSIRT hasta una corrección.
CSIRT vs SOC
Un centro de operaciones de seguridad (SOC) vigila: monitoriza alertas y registros las 24 horas, filtra el ruido y escala lo que parece real. Un CSIRT responde: se hace cargo del incidente confirmado, lo contiene, lo investiga, se coordina con los equipos legal y de comunicación, y dirige la recuperación. En las organizaciones más pequeñas, el SOC y el CSIRT suelen ser las mismas personas, y el SEI señala que importa menos si un equipo se llama CSIRT, SOC o de otro modo que las funciones que desempeña.
Ninguno de los dos sustituye a un PSIRT. Un SOC monitoriza su entorno; no puede ver una vulnerabilidad en un dispositivo que utiliza un cliente.
¿Necesita ambos?
Si fabrica software o dispositivos y además gestiona su propia TI, necesita ambas funciones. No necesita dos departamentos. Los proveedores pequeños suelen empezar con un responsable de seguridad que dirige la respuesta a incidentes de la empresa y un proceso de PSIRT por escrito para los productos, con ingeniería de guardia para las correcciones. Lo que debe estar separado es el proceso: un incidente interno y una vulnerabilidad de producto tienen responsables distintos, plazos distintos y personas distintas a las que informar.
Dónde encaja CRACI
CRACI da soporte al lado del PSIRT: saber qué contiene el software que usted distribuye. Ejecuta sus builds de GitHub Actions en los runners de CRACI y registra los paquetes que cada job descargó realmente, incluidas las dependencias transitivas y los paquetes restaurados desde cachés, y exporta las SBOM en CycloneDX o SPDX.
Las SBOM monitorizadas se reevalúan continuamente, y el historial de builds muestra qué builds anteriores contenían una dependencia vulnerable. La vista de inventario muestra qué versiones están desplegadas en qué productos, y los equipos de seguridad hacen el triaje de los hallazgos y los dirigen a los equipos responsables de la corrección. Consulte el seguimiento de vulnerabilidades y CRACI para PSIRT.
PSIRT vs CSIRT: preguntas frecuentes
¿Qué es un CSIRT?
Un equipo de respuesta a incidentes de seguridad informática (Computer Security Incident Response Team). FIRST lo define como una unidad organizativa, que puede ser virtual, o una capacidad que presta servicios y apoyo a una comunidad de referencia definida para prevenir, detectar, gestionar y responder a incidentes de seguridad informática. La comunidad de referencia puede ser una empresa, un sector o todo un país.
¿Cuál es la diferencia entre un PSIRT y un CSIRT?
Un PSIRT gestiona las vulnerabilidades de los productos que vende una empresa, a las que están expuestos sus clientes. Un CSIRT corporativo gestiona los incidentes de seguridad en los sistemas y las redes propios de la empresa. FIRST califica el enfoque en los productos como el factor diferenciador clave entre ambos.
¿Un CERT es lo mismo que un CSIRT?
Funcionalmente, sí. CERT es una marca registrada en Estados Unidos por la Universidad Carnegie Mellon, cuyo CERT Coordination Center fue el primer equipo de este tipo, creado en 1988 tras el gusano Morris. CSIRT es el término genérico. Muchos equipos nacionales usan CERT en su nombre, y la UE utiliza CSIRT en su legislación.
¿Cuál es la diferencia entre un SOC y un CSIRT?
Un SOC monitoriza y detecta las 24 horas: vigila alertas y registros y escala lo que parece real. Un CSIRT se encarga de la respuesta a los incidentes confirmados: contención, investigación, coordinación y recuperación. En muchas organizaciones ambos se solapan o comparten personal, y el SEI señala que lo que importa son las funciones que desempeña un equipo, no cómo se llama.
¿Necesitamos tanto un PSIRT como un CSIRT?
Si vende software o dispositivos y además gestiona su propia TI, necesita ambas funciones, aunque no necesariamente dos departamentos. En una empresa pequeña, unas pocas personas suelen cubrir ambas, con procesos separados: uno para los incidentes en su entorno y otro para las vulnerabilidades de lo que distribuye.
¿Qué hace un CSIRT nacional?
Gestiona incidentes para una comunidad de referencia nacional, comparte alertas y coordina a través de las fronteras. Con arreglo a NIS2, cada Estado miembro de la UE designa al menos un CSIRT, y uno de ellos actúa como coordinador de la divulgación coordinada de vulnerabilidades: un intermediario de confianza entre quien notifica una vulnerabilidad y el fabricante.
Sepa qué builds contienen un componente vulnerable
Cuando llega un aviso, su PSIRT necesita saber dónde se distribuye el componente. Reserve una demo para verlo a partir del registro de lo que descargó cada build.
Reservar una demo