A resposta a incidentes na cadeia de suprimentos é a capacidade específica de IR necessária para responder a um comprometimento do pipeline de build de software, da infraestrutura de distribuição de artefatos ou do ambiente de desenvolvimento, de forma distinta de um incidente no ambiente de produção. Os playbooks tradicionais de IR tratam de violações de dados, ransomware, comprometimentos de sistemas e incidentes de disponibilidade em ambientes operacionais. Os incidentes na cadeia de suprimentos exigem etapas de investigação diferentes, coleta de evidências diferente, comunicação diferente com as partes interessadas e sequências de correção diferentes, que os playbooks tradicionais de IR não abordam e que a maioria das equipes de IR nunca ensaiou.
O problema da identificação das versões afetadas é o primeiro desafio da IR na cadeia de suprimentos. Quando um ambiente de produção é comprometido, a equipe de IR identifica os sistemas afetados examinando os logs de acesso, as conexões de rede e os artefatos forenses da infraestrutura de produção. Quando um pipeline de build é comprometido, os artefatos afetados são as versões de software construídas durante o período de comprometimento, e identificar quais versões foram afetadas exige logs do pipeline de build, registros de publicação no registro de artefatos e atestados de proveniência SLSA que demonstrem quais versões foram construídas durante o período afetado. Equipes de IR que não têm processos preparados com antecedência para essa análise levarão muito mais tempo para identificar o escopo das versões afetadas do que equipes com um playbook de IR na cadeia de suprimentos que prescreve essas etapas.
A lacuna do inventário de implantações nos clientes é o desafio de comunicação. Um incidente no ambiente de produção afeta os próprios sistemas do fornecedor. Um incidente na cadeia de suprimentos afeta todos os clientes que implantaram uma versão de software afetada. Para notificar os clientes afetados, o fornecedor precisa saber quais clientes implantaram quais versões do seu software, um inventário de implantações que muitos fornecedores não mantêm com atualidade e completude suficientes para uma notificação rápida. O fornecedor que não consegue produzir uma lista de clientes afetados poucas horas após a confirmação do incidente não conseguirá cumprir os prazos de divulgação coordenada e pode enfrentar consequências regulatórias pelo atraso na notificação aos clientes.
Por que isso importa
A resposta a incidentes na cadeia de suprimentos é importante para a TPRM porque o fornecedor cujo programa de IR é maduro para incidentes em produção, mas que não tem um playbook para a cadeia de suprimentos, será significativamente menos eficaz na resposta a um comprometimento da cadeia de suprimentos, e a empresa cujo fornecedor foi comprometido receberá notificações mais lentas, informações menos completas e orientações de resposta menos coordenadas do que um fornecedor com uma capacidade madura de IR na cadeia de suprimentos ofereceria.
- Programa de IR avaliado sem o escopo de incidentes na cadeia de suprimentos
- Playbook para a cadeia de suprimentos ausente: comprometimento do pipeline de build fora dos cenários de IR
- Processo de identificação das versões afetadas não definido
- Inventário de implantações nos clientes não mantido para notificação rápida
- Protocolo de comunicação de incidentes na cadeia de suprimentos não estabelecido
Como é uma boa prática
Programas maduros de IR na cadeia de suprimentos incluem playbooks específicos para comprometimentos do pipeline de build, do registro de artefatos e do ambiente de desenvolvimento; mantêm processos para identificar as versões afetadas e as implantações nos clientes; estabelecem protocolos de comunicação previamente negociados com os principais clientes para incidentes na cadeia de suprimentos; e exercitam anualmente cenários de cadeia de suprimentos em exercícios de mesa.
- Playbook de incidentes na cadeia de suprimentos: cenários de comprometimento do pipeline de build, do registro e do ambiente de desenvolvimento
- Processo de identificação das versões afetadas: análise dos logs do pipeline de build, revisão dos registros de proveniência
- Inventário de implantações nos clientes: registro atualizado das versões implantadas por cliente para notificação rápida
- Protocolo de comunicação previamente negociado para notificações sobre a cadeia de suprimentos aos principais clientes
- Exercício de mesa anual sobre a cadeia de suprimentos: ensaiar o playbook antes do incidente
Ferramentas
IR na cadeia de suprimentos: orientações da Chainguard sobre resposta a incidentes na cadeia de suprimentos; recursos da CISA sobre gestão de riscos da cadeia de suprimentos
Os recursos da CISA sobre segurança da cadeia de suprimentos de software incluem orientações de resposta a incidentes específicas para comprometimentos da cadeia de suprimentos, abrangendo as etapas de investigação, os requisitos de coleta de evidências e os protocolos de notificação às partes interessadas que diferem da IR padrão em produção. Para os profissionais de TPRM, perguntar se os fornecedores revisaram e adaptaram as orientações de IR na cadeia de suprimentos da CISA para seus próprios playbooks é uma pergunta específica sobre a prontidão de IR na cadeia de suprimentos.
Desafios de governança
O desafio de governança da IR na cadeia de suprimentos é a exigência de coordenação entre equipes. A resposta a incidentes na cadeia de suprimentos exige coordenação entre a equipe de segurança (liderança da IR), DevOps (perícia forense do pipeline), engenharia (análise das versões afetadas), jurídico (obrigações de divulgação) e sucesso do cliente (notificação aos clientes). Essa coordenação multifuncional deve estar previamente estabelecida no playbook: reunir a equipe certa pela primeira vez durante um incidente ativo causará atrasos significativos.
- Desenvolver um playbook de incidentes na cadeia de suprimentos com papéis multifuncionais definidos
- Estabelecer um processo de identificação das versões afetadas usando os logs de build e a proveniência
- Manter um inventário de implantações nos clientes suficiente para notificação rápida
- Realizar um exercício de mesa anual sobre a cadeia de suprimentos com uma equipe multifuncional
- Avaliar a prontidão de IR na cadeia de suprimentos na revisão do programa de segurança do fornecedor
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores de software críticos uma pergunta que a avaliação de IR em produção não aborda: se vocês descobrissem hoje que seu pipeline de build está comprometido há seis semanas, quais seriam os três primeiros passos da sua resposta a incidentes, e como vocês identificariam quais clientes implantaram versões possivelmente afetadas? A dificuldade de responder a essa pergunta revela a lacuna de prontidão de IR na cadeia de suprimentos. Um fornecedor com um programa maduro de IR na cadeia de suprimentos responderá de imediato e com precisão.
- Fazer a pergunta sobre a resposta a um comprometimento de 6 semanas do pipeline de build
- Avaliar se o fornecedor tem um playbook específico para a cadeia de suprimentos
- Perguntar sobre o inventário de implantações nos clientes para notificação rápida
- Incluir a prontidão de IR na cadeia de suprimentos na avaliação de segurança do fornecedor
O que exigir
Pergunte diretamente:
“Vocês têm um playbook de resposta a incidentes na cadeia de suprimentos que trate especificamente do comprometimento do pipeline de build ou do registro de artefatos? E como vocês identificariam as versões afetadas e notificariam os clientes afetados em até 24 horas após confirmar um comprometimento da cadeia de suprimentos?”
O que esperar como evidência
- Existência de um playbook de incidentes na cadeia de suprimentos
- Processo de identificação das versões afetadas
- Inventário de implantações nos clientes e processo de notificação
- Registros de exercícios de mesa sobre a cadeia de suprimentos
Um fornecedor cujo programa de IR é maduro deve ser questionado se essa maturidade se estende aos incidentes na cadeia de suprimentos. A IR em produção e a IR na cadeia de suprimentos são capacidades complementares, mas distintas. Seis semanas de comprometimento do pipeline de build sem nenhum playbook para a cadeia de suprimentos são a lacuna entre uma IR madura em produção e a ausência de IR na cadeia de suprimentos.
Como comprovar
- Avaliação do playbook de IR na cadeia de suprimentos
- Revisão do inventário de implantações nos clientes
- Registros de exercícios de mesa sobre a cadeia de suprimentos
- Processo de identificação das versões afetadas
Principal conclusão
Programa de IR: maduro para incidentes em produção. Playbook para a cadeia de suprimentos: nenhum. Pipeline de build comprometido: seis semanas. Versões afetadas: onze. Inventário de implantações nos clientes: não mantido. A equipe de IR era experiente, bem equipada e estava respondendo a um tipo de incidente para o qual não havia se preparado. Incidentes na cadeia de suprimentos exigem evidências diferentes, análises diferentes, notificações diferentes. Playbooks preparados com antecedência, processos de identificação das versões afetadas, inventários de implantações nos clientes e exercícios de mesa anuais sobre a cadeia de suprimentos constroem a capacidade antes do incidente, em vez de montá-la durante ele.