PSIRT: o que faz uma equipa de resposta a incidentes

O que é uma PSIRT?

Uma Product Security Incident Response Team (PSIRT) é a função que trata das vulnerabilidades de segurança nos produtos que uma empresa fabrica e vende. A FIRST define-a como uma entidade centrada na identificação, avaliação e resolução dos riscos associados às vulnerabilidades de segurança nos produtos, incluindo ofertas, soluções, componentes e serviços.

Na prática, uma PSIRT:

gere o canal através do qual investigadores, clientes e parceiros reportam vulnerabilidades;
vigia as vulnerabilidades nos componentes de terceiros e open source dos seus produtos;
faz a triagem de cada relatório: é real, que produtos e versões afeta, qual a sua gravidade;
leva a equipa de engenharia responsável a corrigir a vulnerabilidade, num prazo adequado ao risco;
publica avisos de segurança e coordena a divulgação com quem descobriu a vulnerabilidade e com os fornecedores a jusante;
reporta métricas à direção e dá formação às pessoas que constroem os produtos.

A maior parte do trabalho acontece após o lançamento. A FIRST nota que a maioria das vulnerabilidades de produto é reportada como falhas de qualidade detetadas depois de o produto chegar ao mercado, embora uma PSIRT também acrescente valor mais cedo, em revisões de design e modelação de ameaças.

Onde se situa uma PSIRT na organização

A diferença em relação a outras equipas de segurança é o foco nos produtos. Um CSIRT empresarial protege os sistemas e as redes da própria empresa; uma PSIRT protege os clientes que utilizam os produtos da empresa. As duas equipas partilham competências e, muitas vezes, uma linha hierárquica, e encontram-se quando um incidente na infraestrutura da própria empresa, como um sistema de build comprometido, chega a um produto. A comparação completa está em PSIRT vs CSIRT.

A FIRST descreve três modelos operacionais:

Distribuído: uma pequena PSIRT central define a política e coordena, e os representantes de segurança de cada equipa de produto fazem a triagem e as correções. Escala bem num portefólio grande e variado, mas as pessoas que fazem o trabalho não respondem perante a PSIRT.
Centralizado: uma PSIRT maior, com a sua própria gestão de programa, triagem e pessoal de remediação, que responde perante um executivo sénior de segurança de produto. Adequa-se a empresas mais pequenas ou a um portefólio uniforme e torna-se mais caro à medida que o portefólio cresce.
Híbrido: uma combinação dos dois, escolhida em função da dimensão da empresa, do portefólio e da estratégia de desenvolvimento.

Seja qual for o modelo, a FIRST sublinha a independência: a PSIRT deve responder perante um executivo que confirme a sua autoridade, para que possa assumir uma posição objetiva sobre as vulnerabilidades nos produtos da própria empresa.

O PSIRT Services Framework da FIRST

O PSIRT Services Framework, publicado gratuitamente pela FIRST e agora na versão 1.1, é a referência em que a maioria das PSIRT baseia o seu catálogo de serviços. Define fundamentos operacionais (mandato, partes interessadas, orçamento, políticas) e depois seis áreas de serviço:

Área de serviço	O que abrange
1. Gestão do ecossistema de partes interessadas	Partes interessadas internas, comunidade de descobridores, fornecedores a jusante e clientes, comunicações de incidentes, reconhecimento dos descobridores, métricas de partes interessadas
2. Descoberta de vulnerabilidades	Receção de relatórios de vulnerabilidades, deteção de vulnerabilidades não reportadas, monitorização de vulnerabilidades nos componentes do produto, identificação de novas vulnerabilidades, métricas de descoberta
3. Triagem e análise de vulnerabilidades	Qualificação de relatórios, trabalho com descobridores estabelecidos, reprodução de vulnerabilidades
4. Remediação	Plano de gestão do lançamento de correções, remediação, tratamento de incidentes, métricas de lançamento
5. Divulgação de vulnerabilidades	Notificação, coordenação, divulgação através de avisos de segurança, métricas de divulgação
6. Formação e educação	Formação da PSIRT, das equipas de desenvolvimento e validação e de outras partes interessadas; mecanismos de feedback

Um serviço merece destaque, porque se tornou uma grande parte do trabalho: a monitorização de vulnerabilidades nos componentes do produto. A sua primeira função é um inventário dos componentes do produto, uma lista dos fornecedores, produtos e versões incluídos em cada produto, que a FIRST considera essencial para identificar rapidamente os produtos afetados por vulnerabilidades herdadas. No software moderno, esse inventário é uma software bill of materials (SBOM).

O processo de PSIRT em resumo

Duas normas ISO/IEC descrevem o processo. A ISO/IEC 30111:2019 aborda a forma como um fornecedor trata internamente as vulnerabilidades. A ISO/IEC 29147:2018 aborda a forma como recebe relatórios do exterior e publica informações de remediação. A 30111 destina-se a ser usada com a 29147, e as fases que descreve dão um esquema útil:

Preparação. Política, funções, uma forma publicada de reportar vulnerabilidades, um método de pontuação, um inventário do que é distribuído.
Receção. Receba relatórios de investigadores, clientes, parceiros e dos seus próprios testes, bem como avisos de segurança sobre os componentes que usa. Acuse a receção a quem reportou.
Verificação. Confirme a vulnerabilidade, reproduza-a, pontue-a e determine todos os produtos e versões afetados. Registe também os produtos não afetados, e porquê.
Desenvolvimento da remediação. A equipa responsável constrói e testa uma correção ou uma mitigação. A PSIRT acompanha-a face ao prazo acordado.
Lançamento. Distribua a correção e publique o aviso de segurança, em coordenação com quem descobriu a vulnerabilidade e com os fornecedores a jusante que incorporam o seu produto.
Pós-lançamento. Vigie problemas com a correção, responda aos clientes e devolva as causas de raiz ao desenvolvimento.

Cada fase, com o que deve ser registado e quem é responsável, é abordada no ciclo de vida da gestão de vulnerabilidades. Para decidir que conclusões vêm primeiro, consulte a priorização de vulnerabilidades, com sinais de exploração do EPSS e do catálogo CISA KEV. Uma vulnerabilidade explorada antes de existir uma correção é um zero-day, e a PSIRT trata-a como um incidente. O percurso desde o aviso de segurança até um build corrigido e distribuído é abordado em remediação de CVE.

Divulgação e avisos de segurança

A divulgação é a parte da PSIRT que os clientes veem. A prática habitual é a divulgação coordenada de vulnerabilidades: quem descobre reporta em privado, o fornecedor corrige e ambos publicam numa data acordada, com crédito a quem descobriu. Começa com uma política pública de divulgação de vulnerabilidades que diz como reportar, o que podem esperar os descobridores e durante quanto tempo os produtos têm suporte. Consulte a divulgação coordenada de vulnerabilidades.

Um bom aviso de segurança diz a um cliente, sem necessidade de um telefonema:

que produtos e versões estão afetados, e quais não estão;
o ID da CVE e uma pontuação de gravidade;
a versão corrigida, ou uma mitigação se ainda não houver correção;
quem a descobriu.

Os grandes clientes querem cada vez mais avisos de segurança num formato legível por máquina que possam cruzar automaticamente com o seu inventário de ativos. O CSAF é o formato normalizado da OASIS para avisos de segurança, e o VEX é a forma de declarar que um produto não é afetado por uma vulnerabilidade num dos seus componentes, o que poupa um ticket a ambas as partes.

Métricas e maturidade de uma PSIRT

O referencial coloca métricas em todas as áreas de serviço. As mais comuns:

tempo para acusar a receção de um relatório, para fazer a triagem e para lançar uma correção, por gravidade;
vulnerabilidades em aberto por produto, gravidade e antiguidade;
percentagem de correções entregues dentro dos objetivos de remediação que publicou;
vulnerabilidades encontradas internamente face às reportadas do exterior;
avisos de segurança publicados e correções a avisos.

O documento complementar da FIRST, o PSIRT Maturity Document, organiza os serviços em três níveis:

Nível 1, básico: patrocínio executivo, partes interessadas, orçamento e políticas; uma forma de receber relatórios; um workflow de triagem; correções documentadas; avisos de segurança que usam CVE e CVSS e dão crédito a quem descobriu.
Nível 2, intermédio: uma carta de missão e um modelo organizacional, métricas de base, um registo de produtos com mapeamento de dependências, um plano formal de correção, um sistema de notificação das partes interessadas e formação para a equipa.
Nível 3, avançado: envolvimento direto com a comunidade de descobridores, monitorização de vulnerabilidades nos componentes do produto, métricas de descoberta e de lançamento, tratamento avançado de incidentes e playbooks para a coordenação no setor.

A evolução entre níveis vai do reativo ao proativo.

Como criar uma PSIRT: comece pequeno

Obtenha um mandato escrito de um executivo, com autoridade para pedir às equipas de produto que corrijam problemas.
Publique como reportar uma vulnerabilidade: um endereço de contacto de segurança, um formulário web ou um ficheiro security.txt, e uma política de divulgação curta.
Defina a triagem e a pontuação: quem decide se um relatório é válido, como é pontuada a gravidade e os objetivos de remediação por gravidade.
Saiba o que distribui. Para cada versão de produto, os componentes e as versões que contém. Sem isto, cada nova CVE numa biblioteca popular transforma-se em dias de perguntas às equipas de engenharia.
Nomeie um responsável por produto que receba as conclusões e agende as correções.
Escreva um modelo de aviso de segurança e publique o primeiro, mesmo para um problema pequeno.
Meça alguns prazos desde o início, para poder demonstrar melhorias.

A página para equipas PSIRT analisa a função do lado do responsável de segurança de produto, e os fornecedores industriais podem mapear estes passos para a IEC 62443-4-1, cujos requisitos de ciclo de vida de desenvolvimento seguro incluem a gestão de defeitos e a gestão de patches.

Regulamentos que esperam uma PSIRT

Uma PSIRT era, em tempos, um sinal de fornecedor maduro. Hoje, vários referenciais exigem os seus resultados. O artigo 21.º, n.º 2, alínea e), da NIS2 inclui o tratamento e a divulgação de vulnerabilidades entre as medidas que as entidades essenciais e importantes têm de adotar. Nos EUA, a secção 524B exige que os fabricantes de dispositivos médicos apresentem um plano para monitorizar, identificar e resolver vulnerabilidades pós-comercialização, incluindo a divulgação coordenada de vulnerabilidades, juntamente com uma SBOM. E o Cyber Resilience Act da UE exige que os fabricantes reportem às autoridades as vulnerabilidades ativamente exploradas e os incidentes graves, começando por um alerta precoce no prazo de 24 horas; consulte o que é o CRA.

As ferramentas de que uma PSIRT precisa

Necessidade	Porquê
Receção de relatórios e acompanhamento de casos	Cada relatório tem um responsável, um estado e um prazo
Inventário do que é distribuído	Uma SBOM exata por versão de produto, incluindo dependências transitivas
Monitorização contínua	Novas CVE cruzadas com os componentes de todas as versões lançadas, não apenas da próxima
Triagem e encaminhamento	As conclusões seguem para a equipa responsável pela correção, com o contexto necessário para agir
Declarações de afetado e não afetado	O VEX regista que produtos uma vulnerabilidade afeta e porque é que os outros não são afetados
Publicação de avisos de segurança	Avisos legíveis por humanos, e CSAF legível por máquina para os grandes clientes

Poucos produtos cobrem todas as linhas; ferramentas de PSIRT comparadas mostra que ferramenta faz o quê. O inventário é onde a maioria das PSIRT tem mais dificuldades. Um scanner que lê lockfiles a posteriori lista dependências de desenvolvimento que nunca são distribuídas e não vê pacotes que o build descarregou fora do gestor de pacotes, pelo que a resposta a "estamos afetados?" começa com dúvidas.

O CRACI obtém esse inventário do próprio build. Executa builds de GitHub Actions em runners próprios e regista os pacotes que cada job efetivamente obteve, incluindo dependências transitivas, pacotes restaurados de caches de CI e dependências que nenhum lockfile lista. Cada SBOM traz um estado de completude e é exportada em CycloneDX ou SPDX. As SBOM monitorizadas são reavaliadas continuamente à medida que são publicadas novas vulnerabilidades, o histórico de builds mostra que builds anteriores continham uma dependência vulnerável, e a vista de inventário mostra que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem das conclusões e enviam-nas às equipas responsáveis pela correção, e o CRACI suporta VEX. Consulte o acompanhamento de vulnerabilidades e o CRACI para equipas PSIRT.

PSIRT: perguntas frequentes

O que significa PSIRT?

PSIRT significa Product Security Incident Response Team. A FIRST define-a como uma entidade dentro de uma organização centrada na identificação, avaliação e resolução dos riscos associados às vulnerabilidades de segurança nos produtos, ofertas, soluções, componentes e serviços que a organização produz ou vende.

Qual é a diferença entre uma PSIRT e uma CSIRT?

Uma PSIRT trata das vulnerabilidades nos produtos que uma empresa distribui aos clientes. Um CSIRT empresarial trata dos incidentes de segurança nos sistemas e nas redes da própria empresa. As duas equipas trabalham em conjunto, por exemplo quando uma violação da infraestrutura de build afeta um produto. Consulte PSIRT vs CSIRT.

O que é o PSIRT Services Framework da FIRST?

Um guia gratuito da FIRST, o Forum of Incident Response and Security Teams, que enumera os serviços que uma PSIRT pode prestar. A versão 1.1 agrupa-os em seis áreas de serviço: gestão do ecossistema de partes interessadas, descoberta de vulnerabilidades, triagem e análise de vulnerabilidades, remediação, divulgação de vulnerabilidades, e formação e educação. Um documento complementar de maturidade organiza os serviços em três níveis.

Que normas descrevem o processo de PSIRT?

A ISO/IEC 30111:2019 aborda a forma como um fornecedor trata internamente os relatórios de vulnerabilidades, desde a preparação e a receção até à verificação, ao desenvolvimento da remediação, ao lançamento e ao pós-lançamento. A ISO/IEC 29147:2018 aborda a interface com o exterior: a receção de relatórios e a publicação de informações de remediação. A 30111 destina-se a ser usada com a 29147. A IEC 62443-4-1 define requisitos de ciclo de vida de desenvolvimento seguro, incluindo a gestão de defeitos e de patches, para produtos de automação industrial.

Uma pequena empresa precisa de uma PSIRT?

Precisa da função, não necessariamente de um departamento. O documento de maturidade da FIRST começa com patrocínio executivo, partes interessadas identificadas, um orçamento, algumas políticas, uma forma publicada de reportar vulnerabilidades, um workflow de triagem, correções documentadas e avisos de segurança que dão crédito a quem descobriu. Uma ou duas pessoas com um mandato escrito conseguem fazê-lo.

De que ferramentas precisa uma PSIRT?

No mínimo: uma forma de receber relatórios, um sistema de acompanhamento de casos, um método de pontuação de vulnerabilidades, um inventário dos componentes distribuídos em cada versão de produto, a monitorização desses componentes face a novas vulnerabilidades, uma forma de registar se cada produto é afetado (muitas vezes como VEX) e uma forma de publicar avisos de segurança, cada vez mais em CSAF.

PSIRT: o que faz uma equipa de resposta a incidentes de segurança de produto