A divulgação coordenada de vulnerabilidade (DCV) começa quando pelo menos um indivíduo se conscientiza de uma vulnerabilidade. Não pode prosseguir, no entanto, sem a cooperação de muitos. Cadeias de fornecimento de software, bibliotecas de software e vulnerabilidades de componentes evoluíram em complexidade e se tornaram tanto parte do processo CVD quanto vulnerabilidades no código proprietário dos fornecedores. Muitos casos de DCV agora requerem coordenação entre vários fornecedores. Este post, que se baseia emum relatório especial recentemente publicado, introduzo Vultron, um protocolo para divulgação de vulnerabilidade coordenada multipartidária (MPCVD).

Fundações em Divulgação coordenada de Vulnerabilidades

Desde que lançounossa primeira assessoria, em 1988, o CERT/CC tem buscado melhorar a profissionalização das práticas mundiais de DCV. A partir do trabalho ao longo das décadas, nossa abordagem tem sido destilar e formalizar o que sabemos sobre esse processo. Este trabalho surgiu de numerosos esforços individuais_ad hoc_para educar os fornecedores de software e a comunidade de pesquisa de segurança à medida que eles contratavam nossos serviços na coordenação, análise e publicação de relatórios de vulnerabilidade, incluindo os seguintes:

Além de nossos próprios esforços, também participamos (e, por vezes, lideramos) o desenvolvimento de padrões iso/IEC relacionados em torno da divulgação de vulnerabilidades, incluindo

  • ISO/IEC 29147:2018 Tecnologia da informação — técnicas de segurança — divulgação de vulnerabilidades
  • ISO/IEC 30111:2019 Tecnologia da informação — técnicas de segurança — processos de tratamento de vulnerabilidades

O Protocolo Vultron

Em setembro de 2022, introduzimos o Vultron, um protocolo proposto para mpcvd. O relatório completo, Designing Vultron: A Protocol for Multi-Party Coordinated Vulnerability Disclosure (MPCVD) descreve um protocolo de alto nível que acreditamos fornecer uma base para a interoperabilidade de processos entre as partes interessadas da DCV e aponta o caminho para a implementação técnica em ferramentas como VINCE e outras plataformas de serviços CVD.

Embora eu tenha liderado esforços para desenvolver o protocolo Vultron, ele representa apenas uma parte de um esforço mais amplo para melhorar as práticas de DCV. O relatório não teria sido possível sem diálogo contínuo com meus colegas da Divisão CERT, incluindo Eric Hatleback, Art Manion, Brad Runyon, Vijay Sarvepalli, Sam Perl, Jonathan Spring, Laurie Tyzenhaus e Chuck Yarbrough.

O protocolo Vultron começa com a interoperabilidadesemânticaporque os participantes da DCV precisam primeiro concordar com o que significam quando falam sobre seus processos. Nenhuma quantidade de interoperabilidadesintática(por exemplo, especificações de formato de troca de dados ou APIs) pode ajudar se a interpretação desses dados difere para o remetente e o receptor. O protocolo Vultron foi projetado para lidar com casos de CVD e MPCVD. Na verdade, o protocolo não discrimina entre eles; ele simplesmente trata o CVD “normal” como um caso especial de MPCVD no qual o número de fornecedores é 1.

Especificamente, o protocolo Vultron é construído em torno de três processos distintos, mas interagindo, que descrevemos no relatório comoautômatos finitos determinísticos (DFAs):

  1. Gerenciamento de relatórios — um processo enraizado noGERENCIAMENTO de serviços de TI (ITSM) que descreve um fluxo de trabalho de alto nível pelo qual os participantes individuais de casos de DCV podem lidar e acompanhar relatórios desde o recebimento inicial por meio de validação, priorização e conclusão do trabalho.
  2. Gerenciamento de embargos — um processo baseado na coordenação de calendário e cronograma que contém um fluxo de trabalho para propor, aceitar, revisar e sair de um período de coordenação privada antes da divulgação pública de informações sobre vulnerabilidades. Os embargos em DCV destinam-se a proporcionar uma oportunidade de permitir aos fornecedores de produtos afetados tempo suficiente para elaborar um conselho de correção ou mitigação antes da conscientização pública sobre a vulnerabilidade em questão.
  3. Estado de caso — um processo que descreve o ciclo de vida de um caso DE DCV através de seus principais marcos: conscientização do fornecedor, correção pronta, correção implantada, conscientização pública, exploração pública e ataques observados. Descrevemos esse modelo anteriormente em “Somos Hábeis ou Apenas Sortudos? Interpretando as Possíveis Histórias das Divulgações de Vulnerabilidades” e expandiu a ideia em nossareportagem especial de 2021.

1012_Vultron_Blog_Graphic_2

Figura 1: Três processos (estado de caso, gerenciamento de embargos e gerenciamento de relatórios) interagem para formar o Protocolo Vultron.

O protocolo Vultron abrange aspectos locais e globais do processo de DCV. Por exemplo, considerando que o processo de gerenciamento do relatório é local para um participante específico do caso, espera-se que o processo de gerenciamento de embargos seja compartilhado entre todos os participantes do caso. Da mesma forma, partes do modelo de estado caso são globais para o caso, enquanto outras são específicas para participantes individuais. Nossa intenção, no entanto, é deixar muito espaço para as partes interessadas implementarem seus próprios processos internos para atender às suas necessidades individuais. Nosso objetivo com o protocolo Vultron é fornecer um conjunto de abstrações relevantes para mapear os processos internos de diversas organizações em um fluxo de trabalho generalizado que promova a coordenação do esforço e melhore a comunicação do status do caso entre as partes interessadas.

Nosso relatório sobre vultroninclui comentários detalhados sobre como o protocolo Vultron pode ser implementado e descreve trabalhos futuros. São fornecidos apêndices que mapeiam o protocolo Vultron no trabalho existente, incluindoSSVC v2, ISO/IEC 30111:2019,ISO/IEC 29147:2018 e ISO/IEC TR 5895:2022 (Cybersecurity — Divulgação e manuseio de vulnerabilidades coordenadas por várias partes).

E sim, os fãs de um certomecha gigante de anime colorido composto por cinco robôs discretoscom pilotos humanos podem observar mais do que uma metáfora passageira na ideia de que é preciso um esforço cooperativo e coordenado para uma parceria humana/máquina complexa para alcançar alguns objetivos defensivos.

Para onde vamos agora?

Embora tenhamos feito algum desenvolvimento interno de prova de conceito para explorar aspectos do protocolo Vultron, ele ainda não foi totalmente implementado. Também não concluímos nossa análise de suas propriedades. Devido ao tamanho e escopo do que achamos que pode se tornar, no entanto, queríamos compartilhá-lo agora como uma proposta para que possamos começar a desenvolver uma comunidade de interesse entre as partes interessadas relevantes, incluindo, mas não se limitando a

  • fornecedores de software ePSIRTs
  • pesquisadores de segurança
  • CSIRTse outros coordenadores terceirizados
  • divulgação de vulnerabilidades e provedores de plataforma de recompensa de bugs

Embora você possa esperar ouvir mais de nós sobre o protocolo Vultron no futuro, estamos interessados em seu feedback sobre o protocolo que propusemos no relatório. Algumas perguntas a considerar em seu feedback incluem o seguinte:

  • Com a previsão de que_todos os modelos estão errados, mas alguns são úteis_, como podemos tornar o protocolo Vultron mais útil para sua prática de DCV?
  • O que perdemos?
  • O que poderia ser mais claro?
  • Você tem casos importantes que você acha que devemos considerar?
  • Que suposições fizemos de que você discorda ou acha questionável ou estranho no contexto de seu próprio ambiente e experiência?

Além disso, como o Vultron toca no processo humano e no trabalho técnico da DCV, esperamos que sejam necessários trabalhos futuros para integrar o Vultron em processos de fornecedores de nível superior, como os descritos no FirstPSIRT Services Framework.

Finalmente, reconhecemos que o esforço do protocolo Vultron eventualmente precisará abordar a interoperabilidadesintática, como formatos de troca de mensagens e dados. Prevemos que essa atividade terá alguma forma de engajamento com esforços relevantes, como oCommon Security Advisory Framework (CSAF), o Open Source Vulnerability Format e váriosgrupos de trabalho da CVE, como o Grupo de Trabalho em Automação (AWG).

Não é nossa intenção suplantar o trabalho de formato existente. Na verdade, nossa preferência é que o Vultron eventualmente acomode uma variedade de formatos de troca de dados de vulnerabilidade. Embora apreciemos que os formatos de troca de dados de incidentes e malware existam e estejam relacionados à troca de dados de vulnerabilidade, estamos principalmente interessados em formatos específicos de vulnerabilidade por enquanto. Se você estiver ciente dos esforços ativos de formato de troca de dados de vulnerabilidade que não mencionamos aqui, avise-nos.

Artigo Original