Níveis de maturidade do PSIRT para demonstrar capacidade operacional e maturidade

Nível de Maturidade 1 (Básico) - O Início é um bom lugar para começar

Prefácio:

Há muito tempo há um interesse na resposta a incidentes cibernéticos; Os acontecimentos dos últimos anos só aumentaram esse interesse. Em 2013, a FIRST iniciou esforços na criação de Frameworks de Serviços com foco nas operações de CSIRT. Após a publicação da CSIRT Services Framework, a comunidade de Resposta a Incidentes de Segurança de Produtos se reuniu sob o guarda-chuva da FIRST para criar uma Estrutura de Serviços centrada em PSIRT que abordasse os desafios exclusivos que essas equipes enfrentam. Enquanto CSIRTs e PSIRTs compartilham comportamentos e atividades comuns, o primeiro está focado em proteger a infraestrutura de uma organização, enquanto o segundo responde a ameaças e falhas nos produtos da organização. O Conselho agradece os esforços da comunidade de segurança de produtos e quer agradecê-los por definir seus Serviços para educar a todos.

Este documento apresenta uma série de casos de uso, bem como uma visão geral de alto nível dos serviços que uma Equipe de Resposta a Incidentes de Segurança do Produto pode selecionar em um momento como parte de seu programa. Pode evoluir ao longo do tempo à medida que a missão ou necessidades mudam e à medida que a experiência da equipe cresce. Esses casos de uso referenciados cobrem um espectro de níveis de desenvolvimento de um PSIRT recém-estabelecido, passando por uma equipe de Resposta a Incidentes mais avançada que refinou constantemente seus processos e adicionou suas capacidades. À medida que essa evolução ocorre, a equipe passa de operações reativas para um modo mais proativo de operar, refletindo maior maturidade de seus processos. A estrutura não abrange tópicos como capacidade - o número de vulnerabilidades e incidentes que uma equipe pode gerenciar simultaneamente, ou um modelo de maturidade como o SIM3, que indica o quão bem uma equipe governa, documenta, executa e mede sua(s) função(ões).

Introdução:

Então você foi dito que você precisa ter um PSIRT. Yay? Talvez até recentemente você tenha tido alguns processos ad-hoc, ou pessoas designadas como um dever secundário, ou talvez você tenha o privilégio de trabalhar para uma nova organização e construir tudo do zero? Seja qual for o caso, você foi encarregado de montar uma equipe de pessoas para ajudar a gerenciar vulnerabilidades identificadas em seus produtos e ofertas. PSIRTs vêm em um monte de tamanhos e sabores diferentes, não há dois são exatamente idênticos. Em sua essência, um PSIRT recebe relatórios de vulnerabilidade, fornece a eles algum nível de revisão e análise, trabalha com as partes apropriadas para criar atualizações de segurança e, finalmente, fornecer essas atualizações aos clientes e parceiros da organização.

Este nível procura descrever os principais serviços e funções que um PSIRT precisa oferecer ao iniciar sua jornada no mundo. As lições escritas aqui são extraídas de inúmeras organizações, assim como a sua, talvez, de uma infinidade de tamanhos, indústrias, setores e nações. Todos nós demos esses primeiros passos que você está prestes a dar, e esperamos que você se beneficie de onde nós predecessores podemos ter tropeçado uma vez. Aproveitando a Estrutura de Serviços de Equipes de Resposta a Incidentes de Produto, esperamos destacar áreas-chave para instruir um PSIRT recém-criado sobre onde seus esforços produzirão os melhores resultados. O uso do termo “maturidade” neste documento destina-se a descrever um perfil de uma equipe de segurança de produto e descrever em alto nível os recursos que a equipe fornece às partes interessadas.

image

Figura 1: Listagem das áreas de serviço e serviços desejados do Nível de Maturidade 1

Introdução - Fundamentos Operacionais

No PSIRT Services Framework, temos um conceito de Fundamentos Operacionais. Esta seção identifica e descreve a base dos principais componentes que uma organização precisa para planejar, estabelecer e operar efetivamente um PSIRT.

Visão de 50.000 pés - Para ser eficaz, o PSIRT precisará ter certos pré-requisitos antes de iniciar as operações (coisas como orçamento, apoio executivo, equipamentos, etc.).

Pense nas Fundações Operacionais como você pode ver a fundação de um edifício. Esses são conceitos, processos e pessoal que devem estar no local ou planejados antes de começar a colocar o quadro do edifício em andamento (seu novo PSIRT). Obviamente, para ser totalmente funcional e eficaz, você precisará abordar cada uma das áreas sob as Fundações, mas se você tiver tempo/recursos limitados ou outras restrições, há algumas que são essenciais. Você vai querer garantir que o PSIRT tenha alguma quantidade de funcionários dedicados que ajudem a orientar a organização através das complexidades do gerenciamento de vulnerabilidades. Quanto mais foco eles tiverem, melhor eles serão capazes de servir seus eleitores.

Patrocínio executivo

Em primeiro lugar: por que você está aqui? Por que você está procurando saber mais sobre PSIRTs? Em algum momento, a liderança executiva decidiu que sua empresa precisava disso. Alcançar o patrocínio/mandato executivo é fundamental para tudo o mais que se segue. Em sua função em um PSIRT, você estará pedindo às pessoas que façam coisas que normalmente não fizeram ou que priorizem seu trabalho em detrimento do deles para resolver algum problema de segurança importante. Ter o mandato (escrito) autorizando você a cumprir esse papel é fundamental. Combinamos esses dois conceitos por brevidade, mas sabemos que em organizações maiores há nuances, mas ambos os conceitos falam sobre ter líderes apoiando os esforços do PSIRT.

Não se pode exagerar que ter uma carta clara para o PSIRT e o apoio dos líderes organizacionais é importante. Será desafiador apenas começar, mas o trabalho do PSIRT é exponencialmente simplificado com a compreensão, apoio e apoio dos líderes da organização.

Públicos de relacionamento

Pergunte a si mesmo: “Para quem estou trabalhando?” As partes interessadas são as pessoas com quem você trabalha e para as quais trabalha. Cada um terá desejos e necessidades diferentes de/de você, assim como você terá/deles. O PSIRT é melhor servido começando com a documentação de seus principais interessados. As partes interessadas estão documentadas em mais detalhes no FIRST PSIRT Services Framework. Ao entender quem são esses grupos e quais são suas necessidades, o PSIRT pode começar a se adequar para atender seus desejos e obrigações. À medida que o PSIRT amadurece e se desenvolve, você começará a entender a diferença única entre seu grupo de partes interessadas e a necessidade de personalizar relatórios ou comunicações para cada um.

Orçamento

Intimamente ligado à liderança e ao envolvimento das partes interessadas, o PSIRT precisa ter um orçamento para pessoal e provisão para si mesmo. O tamanho do orçamento e o número de recursos que o PSIRT terá varia amplamente em toda a comunidade do PSIRT, mas, em última análise, o PSIRT deve ter financiamento suficiente para atender aos objetivos de negócios da organização. A liderança do PSIRT deve estar ciente de que, à medida que a equipe e os serviços crescem, o mesmo acontecerá com o financiamento e a contratação de pessoal.

Políticas e Procedimentos

Assim, você tem sua orientação de alto nível da liderança da sua empresa e seu apoio eterno. E agora? Você deve ter um conjunto documentado de regras com as quais o PSIRT trabalhará e aplicará. Apenas começando, você pode ter apenas uma ou duas políticas, mas com o tempo, à medida que a organização ganha mais experiência, a lista pode crescer. Além disso, como você está apenas começando, espera-se que você NÃO terá muitos procedimentos documentados… AINDA. Essa falta de documentação e processo nessa fase da vida do PSIRT pode levar a inconsistências na resposta reativa. Uma coisa fundamental a fazer quando o PSIRT começa a trabalhar em procedimentos é capturar como ele se comporta e como reage a determinadas circunstâncias. Você pode dar o pontapé inicial no PSIRT tomando emprestado as boas práticas existentes de gerenciamento de projetos/programas, engenharia ou suporte dentro de sua própria empresa.

Alguns exemplos de padrões reconhecidos internacionalmente que podem ser úteis para PSIRTs iniciantes (ou que procuram fechar quaisquer lacunas) são ISO/IEC 29147 Tecnologia da Informação – Técnicas de segurança – Divulgação de vulnerabilidades e ISO/IEC 30111 Tecnologia da informação – Técnicas de segurança – Processos de tratamento de vulnerabilidades. Além de revisar esses padrões, os PSIRTs também poderiam estabelecer as seguintes políticas:

  • Política de Gerenciamento de Vulnerabilidades (conforme abordado em ISO30111)
  • Política de Tratamento de Informações (conforme abordado na ISO/IEC 29147)
  • Política de pontuação/priorização de vulnerabilidades
  • Acordo de Nível de Serviço de Correção
  • Política de divulgação de vulnerabilidades (geralmente uma documentação pública)

Ponto de entrada PSIRT - Descoberta de vulnerabilidade

Você tem uma vulnerabilidade se ninguém a conhece? Com a base estabelecida, o primeiro passo para resolver um problema é saber que você tem um problema. No PSIRT Services Framework temos a Área de Serviço de Descoberta de Vulnerabilidade.

Vista de 50.000 pés - Depois de ter alguns processos e pessoas, você precisa encontrar coisas para eles fazerem.

Ter esse recurso permite que o PSIRT receba relatórios para que ações posteriores possam ser tomadas a partir deles.

Recebimento de relatórios de vulnerabilidade

Existem muitos métodos ou caminhos que isso pode tomar, mas para começar a trabalhar na correção de uma falha de segurança, o PSIRT deve primeiro ser informado da vulnerabilidade. Você provavelmente ainda não busca proativamente vulnerabilidades ou tais relatórios, mas precisa garantir que outras pessoas (internas e externas) saibam como entrar em contato com você (por exemplo, publicar seu endereço de e-mail) quando encontrarem um problema de segurança. Além de publicar seu endereço de e-mail, também é recomendável fornecer a chave pgp para receber relatórios de vulnerabilidade. Também é comum configurar um formulário da Web para a entrada de relatórios.

Apenas começando, o PSIRT pode estar aberto apenas para negócios para pesquisadores de terceiros ou vulnerabilidades relatadas internamente. Você provavelmente vai querer trabalhar em estreita colaboração com esse grupo para obter mais eficiência no tratamento de sua comunicação e rapidamente obter problemas encaminhados para as equipes apropriadas para corrigir. À medida que amadurece, você começará a assumir mais e diferentes tipos de localizador (por exemplo, ser capaz de receber relatórios de bugs de segurança de clientes ou de suas organizações de suporte ou vendas).

O Próximo Passo - Triagem e Análise de Vulnerabilidades

A ingestão e a triagem de vulnerabilidades iniciam a função de gerenciamento de casos de um PSIRT. Embora a ordem das operações seja muito semelhante entre os PSIRTs, há variações internas, como o ponto exato de quando um “caso” é criado ou o pessoal desempenhando diferentes funções dentro de um caso. Quando as organizações recebem um alto volume de relatórios de vulnerabilidade, elas podem considerar a realização de triagem inicial para validar relatórios antes que os casos sejam criados. Vice-versa, um caso pode ser criado antes da triagem em organizações onde o volume de relatórios de vulnerabilidade é baixo. O objetivo final entre o PSIRT é criar um processo eficiente e definido.

Dependendo do produto e/ou serviço e das tecnologias que compõem esses itens, essa etapa pode variar muito entre os PSIRTs. Os fornecedores de hardware podem envolver máquinas complexas que vão “bing” ou alavancam práticas de engenharia elétrica ou mecânica, enquanto uma empresa que desenvolve e lança software pode usar matrizes de scanners ou revisões manuais de código para entender melhor o problema.

Vista de 50.000 pés - Qual o tamanho do problema? É maior que uma caixa de pão? Isso realmente te afeta?

Qualificação de vulnerabilidade

Uma vez que o PSIRT tenha recebido o relatório, alguém precisa validar que o relatório é válido. O repórter errou suas conclusões? O relatório é, de facto, uma característica desejada que está a ser mal interpretada? O PSIRT deve ser capaz de visualizar e entender o que foi relatado a eles e tomar uma decisão se aceita o problema como uma vulnerabilidade de segurança ou o rejeita por quaisquer qualificações que eles estabeleçam. Às vezes, isso pode não estar dentro do alcance do Espírito, e a etapa de qualificação é concluída por uma equipe de engenharia de produto. Idealmente, com todo o trabalho colocado nos serviços de Fundações Organizacionais desde o início, ajudará a ter esses papéis e responsabilidades claramente documentados, comunicados e compreendidos por todas as partes envolvidas.

Considere capturar as principais informações de vulnerabilidade desde o início para evitar pontos problemáticos.

Ajuda de formatos legíveis por máquina ou um formato que capture informações técnicas importantes

pode ajudá-lo a entender o que está escrito para a tomada de decisão sobre o conteúdo, pode evitar redundância e reduzir o tempo no processo.

Alguns dos principais recursos que os PSIRTs podem usar para ajudar a documentar e comunicar vulnerabilidades são:

Consulte o anexo para obter mais detalhes.

Análise de Vulnerabilidades

Agora que o PSIRT tem uma vulnerabilidade de segurança válida, alguém deve se aprofundar no problema, entender como a falha funciona, como ela é acionada, quais versões de produtos são afetadas e quais são as consequências quando a vulnerabilidade pode ser explorada com sucesso. O PSIRT pode conduzir a análise, mas muitas vezes o bug é encaminhado para um especialista no assunto no produto afetado ou oferecendo uma revisão mais aprofundada. Minimamente, o PSIRT cataloga o problema, passa-o para alguém que possa compreendê-lo e revisá-lo com autoridade, e o PSIRT rastreia as ações tomadas para garantir que o relatório seja abordado em algum nível (o risco precisa ser remediado, mitigado, transferido ou aceito).

E uma nota rápida antes de seguir em frente sobre priorização e pontuação. O PSIRT deve adotar uma forma de pontuar desde o início. Boas práticas sugerem categorizar se algo é uma vulnerabilidade ou não, usando algum tipo de sistema de pontuação para todos os relatórios recebidos. Ter seus critérios documentados com antecedência ajudará a informar suas ações. Idealmente, você deve usar o Common Vulnerability Scoring System (CVSS), mas você também pode usar o seu próprio.

A mensagem principal aqui é escolher o seu critério e, em seguida, medir todas as coisas contra ele. Se você não usa CVSS, então você deve ter uma boa explicação para os clientes sobre por que você acha que seu sistema de pontuação é melhor do que CVSS.

Consertando a coisa - Remediação

Uau! A essa altura você com certeza já fez muita coisa! Você tirou o relatório do localizador. Você o validou, na verdade, como uma vulnerabilidade de segurança. Você também ajudou a conduzir ou facilitar que a questão seja totalmente explorada e compreendida. O próximo passo é realizar uma análise de custo-benefício e avaliar opções para lidar com a vulnerabilidade. Há muitas opções possíveis a serem consideradas. Alguns exemplos podem ser criar uma correção de código que elimine completamente o risco da vulnerabilidade, criar um conjunto de instruções que limitaria o risco da vulnerabilidade ou decidir não entregar uma correção.

50,000-Foot View - Agora que você encontrou algumas coisas que estão quebradas, você realmente deve tentar consertá-las.

Remediação

A saída mais importante do processo é, na verdade, resolver a vulnerabilidade. O PSIRT pode rastrear ou facilitar problemas que são resolvidos com algum tipo de correção ou mitigação. Uma vez que a equipe apropriada resolva o problema, o PSIRT pode então passar para sua missão final de conduzir o bug desde o início até o fechamento.

A contagem regressiva final - divulgação de vulnerabilidades

Este é o último estágio da vida das vulnerabilidades de segurança. Agora que a falha foi corrigida, o PSIRT ajuda a comunicar as atualizações e materiais relacionados aos stakeholders da empresa (internos e externos).

50.000 pés - Uma vez que você passou por todo esse trabalho duro para corrigir os problemas, você provavelmente deveria contar a alguém sobre isso.

Divulgação

É quando o PSIRT notifica (ou ajuda a coordenar a notificação pelo responsável) os consumidores do produto ou oferta. A divulgação pode assumir muitas formas, mas fundamentalmente os consumidores e partes interessadas recebem algum aviso de que o produto ou serviço é afetado por um problema e recebem documentação sobre como resolver ou mitigar a vulnerabilidade. Além disso, os localizadores que descobriram e relataram a vulnerabilidade são reconhecidos, dando-lhes crédito onde ela é devida. Esse entrosamento e boa vontade entrarão em jogo mais tarde.

É uma boa prática em toda a indústria garantir que o pesquisador/pesquisador seja devidamente creditado pela descoberta no aviso do PSIRT. O reconhecimento ajuda o descobridor a promover suas carreiras e construir sua reputação, e você reconhecer seus esforços gera boa vontade em relação a você deles. O ideal é que esse pequeno investimento em seu texto os encoraje a voltar para você com responsabilidade novamente à medida que descobrem problemas futuros! A ISO 29147 fornece uma boa referência para a divulgação de vulnerabilidades.

Conclusão

Em poucas palavras, é isso que um PSIRT faz e os principais passos que ele dá para cumprir sua missão. Como dito anteriormente, a execução real de todas essas etapas pode assumir muitas formas diferentes, dependendo da organização, seu tamanho, idade, etc. Uma vez que esses elementos básicos estejam em vigor, um PSIRT pode querer explorar como eles podem expandir a qualidade e o escopo de seus serviços. É importante ser consistentemente capaz de fornecer esses serviços e funções antes de pensar em assumir mais trabalho e adicionar novos recursos. Um PSIRT mais maduro pode se interessar em adicionar os recursos que são características de um PSIRT intermediário.

Nível de Maturidade 2 (Intermediário) - Sou reativo, mas já treinei para isso!

Introdução:

Depois de dominar algumas coisas e responder com sucesso a alguns relatórios de falhas, você começará a desejar (ou será instruído a) adicionar mais serviços aos consumidores internos e externos de seus serviços. Existe uma ampla gama de serviços que um PSIRT poderia oferecer, mas é importante focar nas iniciativas que mais beneficiam o seu negócio. Os fabricantes têm preocupações de negócios e riscos muito diferentes que estão tentando mitigar do que uma startup nativa da nuvem, assim como os consumidores desses tipos de ofertas.
No geral, vemos os PSIRTs neste estágio intermediário de maturidade como focados internamente. Eles estão começando a gerenciar bem as coisas, entender com quem interagir para fazer as coisas, mas não têm a quilometragem ou o pessoal talvez para expandir para a comunidade mais ampla. Espera-se que todos os serviços anteriores tenham sido implementados e examinados. Se você ainda não conseguir ingerir um relatório de bug com sucesso, revisite o Nível de Maturidade #1 e aplique essas práticas. Aprimore suas habilidades antes de passar para algumas dessas técnicas e serviços mais recentes.

Neste estágio de desenvolvimento, os PSIRTs normalmente terão recursos nas seguintes linhas:

image

Figura 2: Listagem das áreas de serviço e serviços desejados do Nível de Maturidade 2

Back to Basics - Fundamentos Organizacionais

Se você está pensando em “ir para o próximo nível”, você deve ter implementado com sucesso tudo, desde as Fundações Operacionais até algum grau. Essas etapas fundamentais estabelecem práticas, como garantir o apoio executivo e gerencial do PSIRT. É igualmente importante ter itens críticos, como políticas, padrões e diretrizes documentados e financiamento para operações seguras. Ao começar, alguns PSIRTs podem optar por estabelecer todos os aspectos, cortando alguns arestas, mas à medida que o PSIRT cresce e amadurece, essas coisas-chave DEVEM estar em vigor para garantir operações bem-sucedidas contínuas. O PSIRT Services Framework detalha cada área e função que deve estar em vigor.

(Não a) Divisão de Comunicações - Gestão do Ecossistema de Partes Interessadas

Uma das maiores áreas que separará um PSIRT imaturo de um mais maduro é a compreensão das partes interessadas que estão envolvidas ou preocupadas com a operação do PSIRT. Estes serviços-chave são realmente necessários a este nível. Espera-se que as organizações que trabalham nesse nível saibam com quem trabalham internamente para revisar e reagir às vulnerabilidades. O PSIRT gerenciou várias vulnerabilidades e, embora ainda haja espaço para melhorias, em geral, o PSIRT e seus stakeholders internos sabem o que fazer quando surge uma vulnerabilidade. O PSIRT deve ter uma compreensão básica de quem usa os produtos e serviços da empresa, bem como, em geral, quem fornece bens, código ou serviços para a organização.

Os PSIRTs que atuam nesse nível médio terão processos e canais definidos para trabalhar. O ideal é que você tenha ido além do combate básico a incêndios e seja capaz de reconhecer questões de grande importância para seus produtos e para seus clientes. Os PSIRTs devem ter processos documentados para quando esses grandes eventos surgirem e ser capazes de reunir as partes interessadas apropriadas rapidamente para começar a trabalhar na correção. Outra grande coisa é que idealmente nesta fase o PSIRT é regularmente consultado pelos membros das equipes de engenharia/desenvolvimento da organização. Essas interações ajudam a garantir um ciclo de feedback quase em tempo real que, idealmente, identifica e corrige falhas rapidamente.

Jinkies! Uma pista! - Descoberta de vulnerabilidades

Agora que a organização passou pelo processo de vulnerabilidade várias vezes, o PSIRT sabe como receber relatórios de vulnerabilidade. PSIRTs mais maduros terão vários canais para coletar relatórios de vulnerabilidade para seus produtos/componentes e terão ferramentas para ajudar no rastreamento de problemas. Neste nível, o PSIRT e outros engenheiros internos estão descobrindo vulnerabilidades de segurança (bom trabalho!). Ser capaz de fazer isso permite que a organização controle o lançamento das atualizações, em vez de trabalhar para um prazo definido externamente. Isso não significa que o PSIRT e seus parceiros de engenharia possam ignorar esses problemas encontrados internamente, mas permite que eles programem sua resolução de uma maneira que melhor se ajuste aos cronogramas de lançamento da organização ou à disponibilidade de outros recursos, em vez de serem tratados como uma emergência. Todo mundo gosta de consertar a coisa, mas também poder ir para casa a tempo e jantar com o gato é bom também. Ter oportunidades de gerenciar a liberação de falhas encontradas internamente também dá a todas as equipes envolvidas flexibilidade para quando “o grande” for relatado por um cliente ou pesquisador de segurança.

É importante nesta fase de maturidade que o PSIRT invista tempo na coleta de uma lista abrangente de todos os componentes que estão incluídos em um produto lançado. Isso pode ter vários nomes, dependendo da empresa, mas é comumente referido como um manifesto de produto ou lista de materiais (BOM). Ter essa lista ajuda o PSIRT a saber quais itens observar e testar vulnerabilidades. À medida que o PSIRT amadurece, essa lista os ajudará a entender com quais terceiros (como projetos de código aberto) o PSIRT precisa interagir para corrigir vulnerabilidades descobertas.

Uma palavra sobre SDLC

Ciclo de Vida de Desenvolvimento de Software: SDLC, SDL, SSDLC, Engenharia de Segurança, Frank em QA, seja como for que sua organização chame, ter conexões com o processo SDLC da sua empresa é importante para o PSIRT. O papel e a relação de cada PSIRT com o SDLC variam, mas ter linhas de comunicação abertas e ganchos nesse processo pode ajudar o PSIRT a fornecer feedback e obter falhas de segurança corrigidas (idealmente) antes do lançamento do produto. Saber com quem falar, quando os produtos são eliminados por fases e qual a melhor forma de fornecer informações beneficiará a missão do PSIRT ou abordará as vulnerabilidades descobertas.

Apenas os fatos, senhora - Triagem e Análise de Vulnerabilidades

As rodas de treino estão desligadas. As vulnerabilidades estão vindo de várias fontes, e o PSIRT teve a prática de investigar os relatórios e entender se eles são REALMENTE bugs ou não (às vezes não são, é muito divertido explicar isso para uma repórter entusiasmada interessada em fazer um nome para si mesma na internet….boa sorte!). Após a prática, agora você pode qualificar esses relatórios e gerenciá-los de acordo. Entendendo que todos os bugs não são criados iguais, o PSIRT deve considerar ter um processo quantificável para avaliar esses relatórios de entrada (às vezes referido como uma “Barra de Bugs”).

É aqui que entra em vigor a escolha de como o PSIRT está estruturado. O modelo operacional em torno do qual você projetou seus processos e equipe (Centralizado, Distribuído, Híbrido) afetará quem está conduzindo a triagem e análise de vulnerabilidades e como esse trabalho é gerenciado processualmente. Entender que a OMS faz o QUÊ com esses relatórios recebidos é fundamental para revisá-los rapidamente e reagir a eles. Há pontos fortes e fracos em cada modelo, e o PSIRT deve entender qual é a sua parte no fluxo de trabalho (Você é um coordenador ativo? Você faz a pesquisa? Você apenas relata os problemas?).

A essa altura, você provavelmente também tem alguns “reincidentes” relatando problemas para você. Fantástico! Quanto mais você começa a trabalhar com essas pessoas, mais felizes TODOS estão a longo prazo. É sempre aconselhável manter termos amigáveis com os localizadores, pois a internet pode rapidamente tornar sua vida miserável se você não estiver se dando bem com um repórter de vulnerabilidade. Evite essas bobagens, trate-as profissionalmente e tão rapidamente quanto seu pessoal, processo e ferramentas permitirem. Você provavelmente tem seus localizadores registrados em um banco de dados que rastreia algumas informações básicas sobre quem são, o que encontraram e a qualidade de seus relatórios.

Também será útil ao trabalhar com localizadores para fornecer atualizações sobre o progresso, normalmente feito por meio de um sistema de rastreamento de defeitos ou emissão de tickets. Fornecer dados de tickets de volta ao repórter ajuda a mostrar que você está lidando adequadamente com suas preocupações, cria um canal para colaboração com esse localizador e, em última análise, deve reduzir o risco de que eles se frustrem e divulguem a falha antes de qualquer data acordada.

Essa maturidade permite que você trabalhe melhor com todos os repórteres, treinando-os sobre o que torna um relatório facilmente acionável e o que é uma bagunça quente que levará muitas idas e vindas para ser resolvida (o que frustra TODOS). Lembre-se, quanto mais você faz, melhor você fica, mais rápido você pode fazê-lo, mais tempo você está liberando para melhorar a si mesmo em outras áreas. Nesta fase do seu desenvolvimento, o PSIRT ou os seus parceiros de engenharia terão desenvolvido alguma forma de capacidade de reprodução. É importante testar essas falhas em um local isolado (para não estragar o dia de todos na rede). Tenha processos documentados de como lidar com a exploração, como ela será testada e protegida de sair para as mãos erradas. Tenha um plano de como você pode compartilhar reprodutores com segurança internamente (e possivelmente com parceiros/partes interessadas externas).

Mencionamos os conceitos de pontuação CVSS para PSIRTs iniciais. Neste estágio, a equipe é proficiente em avaliar a vulnerabilidade de segurança e deve ser capaz de descrever vulnerabilidades de segurança usando termos padrão do setor. Alguns PSIRTs podem ter delegado a pontuação inicial a parceiros de engenharia (às vezes chamados de “campeões de segurança”) com o PSIRT fornecendo supervisão e orientação conforme necessário. A curadoria dessa rede de parceiros voltados para a segurança em toda a sua organização certamente pode ajudar o PSIRT a ser mais eficaz. Alguns PSIRTs podem melhorar sua pontuação rotulando problemas com Common Weakness Enumeration (CWE). Eles também podem criar ferramentas para fazer pontuação automática e descrições. Além disso, o PSIRT também pode desejar fornecer contexto adicional em torno da falha da perspectiva de como os produtos da organização são configurados e implantados junto com a pontuação CVSS e definir rótulos de gravidade.

Remediação

À medida que você melhora em “fazer PSIRT”, você melhorará suas ferramentas, documentação e os níveis de conforto das pessoas em relação a lidar com problemas. Agora você pode fazer mais do que apenas criar um patch ou correção, você pode fazê-lo de forma repetível, aproveitando seus processos de compilação atuais. Talvez às vezes você faça isso um pouco mais rápido do que o normal, mas você não está mais “recriando a roda” e construindo cada conserto de uma só vez e à mão. Há automação, é repetível e, embora seja uma emergência, as pessoas entendem que há um processo para lidar com isso. Espero que você tenha compartilhado esse processo com seus consumidores, para que eles recebam notificações e mecanismos para obter as atualizações rapidamente. Um PSIRT que trabalhe nesse nível deve ter políticas, padrões, diretrizes e processos documentados; Talvez você ainda não contabilize tudo, mas os cenários mais comuns em seu ambiente são contabilizados. Você também provavelmente tem política suficiente a este ponto que talvez precise ter um processo de exceção para coisas que se desviarão das regras.

Prometo dizer a verdade, toda a verdade… - Vulnerability Disclosure

Suas primeiras vulnerabilidades de segurança podem ter sido novas e assustadoras, mas agora você fez várias e sua equipe está treinada sobre o que fazer. Você está fazendo mais nesta fase do que apenas uma simples notificação. Os usuários de suas coisas sabem sobre as atualizações à medida que são lançadas, mas agora você também está fazendo um trabalho melhor na coordenação com os outros. Uma boa referência para essa coordenação pode ser encontrada nas Diretrizes de Coordenação e Divulgação Multipartidária da FIRST.

Você está mergulhando o dedo no oceano mais amplo do ecossistema ao seu redor e talvez esteja sincronizando suas atualizações com outras organizações para ajudar a limitar os riscos para os consumidores compartilhados. O PSIRT definiu circunstâncias que exigem comunicação antecipada ao cliente antes da divulgação. Eles podem ter introduzido assinaturas de e-mail e notificações para quando a divulgação for publicada. Eles amadureceram na comunicação intersetorial e na comunicação interna para as equipes de vendas e suporte antes da divulgação. Até agora, você também tem acompanhado as métricas sobre si mesmo e sua entrega de atualizações de segurança. O PSIRT Services Framework tem sugestões sobre muitas métricas que podem ser acompanhadas ao longo de cada uma dessas fases. Você retroalimenta isso em seus processos depois de analisar seu desempenho e melhorar a forma como está gerenciando esses incidentes. A PSIRT pode considerar o Protocolo de Semáforo (TLP) para compartilhamento de informações.

Formação

Este tem sido o molho secreto que o diferencia dos PSIRTs iniciais: experiência e reflexão. Você pegou o que aprendeu, aplicou e se tornou melhor. O ideal é que você tenha escrito essa nova sabedoria para poder compartilhar com outras pessoas dentro da sua organização. Você pode ter criado um treinamento educacional especificamente para determinadas partes interessadas, como relações públicas, jurídico e executivos, para que eles conheçam suas funções e o que você espera e precisa deles. À medida que você é capaz de adicionar novos associados à sua equipe ou equipe estendida, você pode fornecer treinamento consistente a eles, para que todos conheçam as mesmas informações e possam agir de forma consistente com suas práticas e políticas.

A FIRST preparou uma série de vídeos de treinamento que podem ajudar a educar novos PSIRTs e aqueles que buscam melhorar em seu ofício.

Conclusão

Toda vulnerabilidade é uma oportunidade de aprendizado para o PSIRT. Ao executar seu fluxo de trabalho, o PSIRT encontrará gradualmente áreas onde as práticas ou ferramentas podem ser otimizadas. Cada interação com o usuário final ajuda a orientar o PSIRT sobre como ajustar os resultados gerais da organização para melhor atender a essas necessidades. À medida que o PSIRT começa a executar consistentemente essas técnicas que acabamos de discutir, eles desenvolverão eficiências e começarão a ter mais tempo para se concentrar em melhorar sua situação. Com bastante tempo, prática e reflexão, o PSIRT começará a passar para um estágio mais avançado de atuação.

Nível de Maturidade 3 (Avançado) - Proativo… estamos prontos para qualquer coisa (principalmente)

Introdução

Parabéns! Você já está fazendo um tempo para resolver muitos problemas e realmente se incorporou ao tecido da sua organização! Bem legal, né? Seus clientes são (geralmente) satisfeitos e bem atendidos por sua gestão de problemas que os afetam. Você se sente imparável! Então… O que vem por aí? Você tem o básico, então agora vamos mergulhar em como fazer ajustes e melhorias para começar a fazer coisas como alguns dos PSIRTs de elite por aí.

Para chegar a esse nível, entende-se que seu processo de ingestão, análise e entrega de atualizações de segurança para seus produtos é bem compreendido dentro de sua organização. Seus colegas internos sabem quem você é e o que o PSIRT faz e todos vocês resistiram a muitos ciclos de problemas a ponto de o processo e os requisitos não serem novos ou surpreendentes para quem você interage internamente. Você também sobreviveu a várias vulnerabilidades grandes ou a um ataque maior do que um problema “típico”. Esses eventos maiores ajudaram a identificar áreas em que seus processos e documentos precisavam de melhorias.

Você implantou ferramentas, processos e pessoas suficientes para acompanhar o gerenciamento de novos trabalhos recebidos e o acompanhamento de problemas que estão em andamento. Agora você é capaz de gerenciar os problemas diários de gerenciamento de vulnerabilidades “business as usual” e também esses problemas maiores e mais consumidos.

PSIRTs operando nesse nível são exemplificados por comportamentos proativos e consistentes. Você não deixa mais apenas as coisas acontecerem com sua organização e produtos, agora está tomando medidas PROATIVAS para buscar problemas e pessoas. Você já passou por incidentes suficientes que agora também está tomando medidas para prever quando as coisas podem ocorrer. Talvez você tenha alguma ferramenta legal e esteja baseando ações em eventos históricos para prever o que pode acontecer? Talvez você esteja gerenciando riscos de forma muito eficaz e entenda quais tipos de comportamento podem impactar o seu negócio… e você está trabalhando para mitigá-los antes que se tornem problemas. Os recursos que os PSIRTs nesse nível executam falam de um processo adaptativo bem gerenciado. Uma lista de serviços que uma equipe nesse nível estaria prestando poderia ter a seguinte aparência:

image

Figura 3: Listagem das áreas de serviço e serviços desejados do Nível de Maturidade 3

Vamos nos aprofundar nas capacidades que um PSIRT experiente exibe.

Fundações sólidas

Para se considerar maduro, todos esses processos e serviços precisam ser de longa data. Cada um desses serviços é vital para a operação, financiamento e direção do PSIRT. Se você está perdendo coisas aqui, volte e reflita sobre o que você pode não ter ficado consistentemente para baixo ou que você pode estar perdendo. Adquira suporte interno para que essas coisas se estabeleçam. Você deve ser tão alto para montar o passeio. Volte e leia mais depois de ter feito tudo isso.

Colocando a Participação em Stakeholder… Mmmm… bife

Os PSIRTs nesta fase avançada operam com confiança. Essa confiança é parcialmente desenvolvida por conversas frequentes e ativas com as partes envolvidas nos produtos e processos da empresa (e olhando para fora também). Por esta altura, o PSIRT investiu no desenvolvimento de relações abertas e honestas com todas as partes interessadas… a lista é longa. Neste estágio de evolução, o PSIRT criou comunicações padronizadas, aproveitando playbooks e modelos, e as partes interessadas terão vários caminhos para fornecer e receber feedback sobre o processo. O PSIRT deve participar de reuniões regulares do programa de produtos que são essenciais para a organização e deve ser bem versado no próximo cronograma de lançamento.

Como acontece com todas as partes do Framework que o PSIRT usa nesse nível, métricas e relatórios são fundamentais para o sucesso contínuo. O PSIRT e as suas partes interessadas terão objectivos claramente definidos e medidas de sucesso. Assim, os indicadores-chave de produtividade podem ser coisas como “Satisfação do cliente”, Net Promoter Score, entrega de patches de vulnerabilidade de segurança, objetivos/acordos de nível de serviço ou similares que são revisados pelo PSIRT e suas partes interessadas para garantir o sucesso contínuo da operação. Essas métricas ajudam a informar o PSIRT para fazer escolhas comerciais positivas e influenciar o comportamento interno de todos os participantes do processo de remediação.

Uma das principais características dos PSIRTs que operam nesse nível é um entendimento robusto e engajamento com partes interessadas externas. Seja ajudando a estabelecer mecanismos e processos de resposta a vulnerabilidades, integrando ou supervisionando alguma forma de Ciclo de Vida de Desenvolvimento de Software Seguro, ou mesmo simplesmente reagindo ao suporte interno das organizações de vendas. Agora que o PSIRT tem uma base forte, eles começarão a deixar de ser principalmente focados internamente para se envolver mais com partidos externos.

O PSIRT deve procurar alinhar-se melhor com os pares da indústria, ou pesquisadores de segurança; Talvez programas de extensão de alguma forma sejam criados para ajudar a construir relacionamentos fortes. O maior benefício seria construir relacionamentos com provedores externos “upstream” e entender completamente como eles reagem a questões de segurança, o que, por sua vez, causaria impacto em bens e serviços que o PSIRT ajuda a governar. Esse gerenciamento de componentes de terceiros (como tudo o que a estrutura detalha) pode assumir muitas formas diferentes.

Descobrindo o Desconhecido (ou pelo menos não era sabido por você para começar)

À medida que os PSIRTs entram nessa fase de sua existência, eles estão se tornando mestres de seu próprio domínio. Boas relações com as partes interessadas internas dão ao PSIRT uma melhor visão sobre o pipeline de lançamento. Eles estarão cientes dos próximos recursos/funções/pacotes e estarão mais bem preparados para o futuro. O PSIRT desenvolveu ou adquiriu ferramentas para gerenciar o influxo de relatórios de vulnerabilidade de várias fontes. Idealmente, neste estágio de evolução, o PSIRT está ajudando ativamente na busca por vulnerabilidades do produto. Este comportamento tornou-se parte integrante do processo de desenvolvimento e manutenção.

O PSIRT influenciou a organização a conduzir uma melhor análise e varredura de vulnerabilidades durante todo o processo de desenvolvimento da oferta para que mais bugs de segurança sejam detectados antes do lançamento do produto e sejam corrigidos antes que um usuário final possa ser afetado por eles. À medida que os problemas são relatados, cada um precisa ser analisado para ver se variantes adicionais podem existir (esses pesquisadores são inteligentes, mas nem sempre sabem tudo). O conhecimento detalhado do produto que as equipes de PSIRT e de Engenharia de Produto têm pode permitir que eles descubram maneiras adicionais de explorar. O PSIRT está gerenciando riscos de segurança em componentes de terceiros e monitorando ativamente as fontes de relatórios de vulnerabilidade (mídias sociais, veículos de notícias, artigos de conferência, etc.). Esses podem ser indicadores iniciais vitais de ataques futuros ou classes de vulnerabilidades ainda não descobertas pela organização.

Qual é o diagnóstico, doutor?

A equipe está junta há algum tempo e entende o cenário de produtos que eles ajudam a supervisionar. O PSIRT desenvolveu processos para avaliar relatórios de vulnerabilidade de forma rápida e precisa, aproveitando os buscadores anteriores ou uma melhor compreensão de como os produtos da organização poderiam ser explorados. A experiência e a reflexão ajudam a fornecer eficiências em processos e ferramentas para que a equipe possa continuar a refletir sobre seu desempenho e buscar melhorar as ofertas.

Tendo reagido a falhas relatadas antes, o PSIRT tem insights sobre muitos pesquisadores de segurança e repórteres em sua área específica. Alguns desses pesquisadores têm se mostrado extremamente qualificados. Eles podem receber sinalização de prioridade e passar direto para a fase de análise, ignorando etapas de triagem corretiva que repórteres não comprovados ainda podem ter que enfrentar. O PSIRT deve ter fortes sentimentos sobre o que faz um relatório “bom” e quais elementos/pontos de dados os ajudam a validar (ou refutar) mais rapidamente as descobertas de um pesquisador.

O PSIRT também deve ter um processo para encaminhar problemas para alguma forma de sistema de reprodução segura para recriar ataques e vulnerabilidades. Isso permite que a equipe jogue cenários de “e se”.

O PSIRT pode consultar as equipes de desenvolvimento e ajudar a fornecer feedback para evitar erros comuns de codificação e falhas de segurança. Ferramentas como o CWE permitem que os engenheiros analisem falhas históricas para ajudar a evitar comportamentos futuros. Essa orientação ajuda a evitar correções dispendiosas após uma versão, integrando esse feedback no início de um ciclo de vida de desenvolvimento.

Consertando a Coisa

Idealmente, nesta fase, com a correção repetida de problemas anteriores, o PSIRT e todos os participantes interessados agora são capazes de fornecer atualizações de forma consistente. Todas as partes envolvidas sabem o que fazer, têm expectativas claras do cronograma para entregar a mitigação e têm recursos suficientes para se dedicar à correção do problema. À medida que um problema técnico está sendo corrigido, o PSIRT está garantindo que a documentação e as comunicações apropriadas estejam sendo desenvolvidas para que, à medida que o problema é relatado ao público, parceiros, colegas e consumidores possam entender o problema, como ele foi corrigido e se havia alguma alternativa para “apenas corrigir”.

A entrega da atualização é um processo rotineiro, não um recém-cunhado no calor do momento. A entrega final pode assumir a forma de uma janela de lançamento de atualização padronizada, pode estar preparada para ir “pelo ar” por meio de mecanismos de atualização automatizados, o problema e o produto envolvidos ajudarão a moldar quais opções a organização tem disponíveis para fornecer a mitigação aos usuários finais que são afetados pelo problema. Tudo o que o usuário final deve fazer para reagir à vulnerabilidade está preparado e aguardando o tempo em que ela é divulgada publicamente.

Hark! Trago notícias de…. coisas quebradas (mas eu também vou te dizer como consertá-lo!)

O PSIRT deve garantir que todas as partes interessadas sejam alertadas quando a vulnerabilidade estiver pronta para ser tornada pública e as atualizações estiverem disponíveis. Pensando na seção anterior de Gestão de Partes Interessadas, o PSIRT entende os vários grupos que precisam ser informados e a melhor forma de se envolver com cada um. Quando chega a hora de divulgar atualizações ou uma declaração pública, o PSIRT sabe quais canais são usados para informar cada constituinte adequadamente.

Em cenários em que o PSIRT depende de um provedor a montante ou de terceiros, ou eles mesmos fornecem os produtos ou serviços a jusante, é importante que o PSIRT entenda a melhor forma de informar cada um desses diferentes grupos. Se o PSIRT fizer parte de algum ecossistema maior, onde vários fornecedores são afetados pelo mesmo bug, os PSIRTs envolvidos normalmente coordenarão um tempo mutuamente acordado (“período de embargo”) em que todos os clientes afetados podem ser informados simultaneamente. Idealmente, todas as várias atualizações são lançadas ao mesmo tempo para que nenhum grupo de usuários finais seja afetado negativamente em relação a outro, com o objetivo de minimizar o período de tempo em que atores mal-intencionados podem tirar proveito da vulnerabilidade agora pública.

Ensina-me, Sensei

Os PSIRTs nesta fase de evolução estiveram envolvidos com vários níveis de treinamento até este ponto. Eles podem ter feito treinamento tático em um produto ou técnica de segurança ou documentado procedimentos operacionais padrão em playbooks e, em seguida, trabalhado com novos associados para entendê-los.

Mais uma vez, os PSIRTs neste nível são mais proativos do que costumavam ser. O PSIRT pode participar ou possivelmente fornecer conteúdo de treinamento de desenvolvimento seguro para seus colegas internos ou outras partes interessadas (dependendo dos recursos e da missão). Eles aumentam o treinamento e a documentação para refletir boas práticas e aprendizados, ajudando a construir a “próxima geração” de associados ou parceiros da PSIRT. O PSIRT é exponencialmente mais forte se seus desenvolvedores, engenheiros e equipes de produto entenderem técnicas seguras de codificação, privacidade e segurança da informação e puderem participar da execução desses princípios.

Conclusão

Proteger os produtos e serviços da sua organização é uma jornada, não um destino. Todos os dias o cenário de ameaças muda, novas tecnologias são criadas, novas formas de pensar são desenvolvidas, novas ameaças surgem e as antigas estagnam. Espero que esses níveis de maturidade tenham ajudado a informá-lo enquanto você embarca em sua própria jornada PSIRT!

Além do “Nível 3”

Que? …. Parece impossível… mas não é!

Anexo 1: Recursos de apoio

Para obter uma lista completa de recursos de suporte e glossário, consulte o PSIRT Services Framework
https://www.first.org/education/FIRST_PSIRT_Services_Framework_v1.0.pdf.

Anexo 2: Ilustrações

  • FIGURA 1: LISTAGEM DAS ÁREAS DE SERVIÇO E SERVIÇOS DESEJADOS DO NÍVEL DE MATURIDADE 1
  • FIGURA 2: LISTAGEM DAS ÁREAS DE SERVIÇO E SERVIÇOS DESEJADOS DO NÍVEL DE MATURIDADE 2
  • FIGURA 3: LISTAGEM DAS ÁREAS DE SERVIÇO E SERVIÇOS DESEJADOS DO NÍVEL DE MATURIDADE 3

Anexo 3: Carta PSIRT

Os PSIRTs devem ter uma carta definida que descreva o que o PSIRT faz e seu escopo. A maioria dos charters tem os seguintes itens:

  • Declaração de missão
    A declaração de missão define o propósito e as atividades da equipe (ver exemplos no Anexo 3).
  • Partes interessadas
    As partes interessadas são as partes que o PSIRT serve. Consulte o Serviço 1.1: Partes Interessadas Internas no Quadro PSIRT para obter mais informações.
  • Afiliação e organização
    patrocinadora A organização patrocinadora, conforme definido no Patrocínio Executivo, apoia os objetivos, ações e fornece recursos para suas operações.
  • Escopo
    Conforme declarado nas estruturas do PSIRT, os PSIRTs são tão únicos e variados quanto os produtos que ajudam a proteger, suas partes interessadas e sua estrutura organizacional. O escopo fala da responsabilidade e influência concedida à equipe PSIRT em toda a organização.

Anexo 4: Exemplos de declarações de missão

  • O Microsoft
    Microsoft Security Response Center (MSRC) coordena e atenua os problemas de segurança que afetam os clientes, a marca e os sistemas da Microsoft. O MSRC é a ligação entre pesquisadores de segurança externos e equipes de produtos da Microsoft. O MSRC fornece uma interface crítica, coordenando com pesquisadores de segurança e equipes de produtos da Microsoft para documentar e corrigir vulnerabilidades de segurança relatadas em produtos Microsoft.

  • IBM A IBM
    Product Security Incident Response Team (PSIRT) é uma equipe global que gerencia o recebimento, a investigação e a coordenação interna de informações de vulnerabilidade de segurança relacionadas às ofertas da IBM. O IBM PSIRT é um ponto focal para pesquisadores de segurança, grupos do setor, organizações governamentais e fornecedores relatarem possíveis vulnerabilidades de segurança de produtos IBM. Essa equipe se coordenará com as equipes de produtos e soluções da IBM para investigar e, se necessário, identificar o plano de resposta apropriado. Os clientes das ofertas IBM devem continuar a relatar todos os problemas relacionados ao produto, incluindo possíveis vulnerabilidades de segurança, ao Suporte Técnico IBM. Manter a comunicação entre todas as partes envolvidas, internas e externas, é um componente-chave do nosso processo de resposta à vulnerabilidade.

  • A missão da Brocade
    Brocade Product Security Incident Response Team é proteger a Brocade e seus clientes gerenciando o recebimento, investigação e coordenação de vulnerabilidades de segurança que afetam a confidencialidade, integridade ou disponibilidade dos produtos e serviços Brocade.

  • A DELL EMC
    Dell se esforça para ajudar nossos clientes a minimizar os riscos associados às vulnerabilidades de segurança em nossos produtos. Nosso objetivo é fornecer aos clientes informações, orientações e opções de mitigação em tempo hábil para lidar com vulnerabilidades. A Dell Product Security Incident Response Team (Dell PSIRT) é responsável por coordenar a resposta e a divulgação de todas as vulnerabilidades de produtos relatadas à Dell.

  • Segurança
    de produtos Red Hat Para ajudar a proteger os clientes de preocupações significativas de segurança nos produtos, serviços e projetos da Red Hat; Ao garantir que nossos produtos estejam seguros, as vulnerabilidades sejam investigadas e os problemas importantes sejam corrigidos.
    Forneça uma experiência de qualidade superior ao cliente de segurança do produto por meio de informações claras, precisas, oportunas e confiáveis. Garantir que nosso valor seja reconhecido como uma parte importante do valor da assinatura.
    Construir e manter uma equipe coesa de colaboradores altamente bem-sucedidos, apaixonados e felizes, que trabalhem de forma eficaz e sejam considerados interna e externamente como líderes em segurança.

  • Honeywell
    A Honeywell Product Security Incident Response Team (PSIRT) gerencia vulnerabilidades e incidentes de segurança para todos os produtos, serviços e componentes da Honeywell. O PSIRT se concentra na identificação, avaliação, mitigação e eliminação dos riscos associados a incidentes de segurança e vulnerabilidades dos produtos Honeywell. Isso inclui ofertas, soluções, componentes e serviços. Os serviços PSIRT são parte integrante do Secure Development Lifecycle (SDL).

Anexo 5: Modelo de Carta

Um charter deve incluir um propósito, problema de negócios, antecedentes (opcional), estatuto de equipes e o patrocinador principal. Por exemplo:

A Equipe de Resposta a Incidentes de Segurança do Produto (PSIRT) apoia as equipes de desenvolvimento com todos os aspectos relacionados à segurança dos produtos da empresa. Isso inclui, mas não se limita a, identificação, mitigação e divulgação de vulnerabilidades que afetam os produtos, ofertas e soluções suportados desenvolvidos, vendidos ou distribuídos pela empresa. O PSIRT é patrocinado e financiado pelo [Insira o executivo apropriado aqui] para a empresa.

Anexo 6: Modelo de política

As políticas comunicam claramente “o que” é esperado dos funcionários em relação às vulnerabilidades de segurança do produto. Isso é diferente dos processos que explicam “como” os funcionários atenderiam às políticas publicadas. Cada política ou conjunto de políticas é exclusivo da empresa e da cultura de segurança. Os principais ingredientes de um documento de política também podem incluir executivo responsável, escritório responsável, data de vigência, última atualização, quem é afetado pela política e a política real. Alguns exemplos potenciais do que pode ser incluído na política são os seguintes:

  • Todas as vulnerabilidades de segurança conhecidas devem ser enviadas à PSIRT (Product Security Incident Response Team) para processamento e eliminação.
  • As vulnerabilidades de segurança devem ser triadas dentro de [#] dias após o recebimento de um relatório, com o resultado final sendo uma declaração de impacto para os produtos e clientes suportados pela empresa.
  • A empresa fornecerá correções para vulnerabilidades de segurança relatadas com base no impacto nos produtos da empresa e conforme definido pelo PSIRT.
  • A empresa divulgará publicamente as vulnerabilidades de segurança somente quando uma correção estiver disponível e a ação do cliente for necessária.

Para obter mais detalhes, revisite as políticas e procedimentos do Nível de Maturidade 1 (observação: a Política de Divulgação de Vulnerabilidades é geralmente uma documentação pública-ISO/IEC 29147).

Anexo 7: Lista de verificação de amostras

Nível de Maturidade 1

  • Fundamentos Operacionais
  • Garantir patrocínio executivo
  • Identificar as partes interessadas
  • Estabeleça orçamento
  • Estabelecer políticas
  • Descoberta de vulnerabilidades
  • Recebimento de relatórios de vulnerabilidade
  • Estabeleça o endereço de e-mail PSIRT com a chave PGP
  • Triagem de Vulnerabilidades
  • Definir o processo de admissão de vulnerabilidades
  • Estabelecer fluxos de trabalho internos para qualificação, triagem e análise de vulnerabilidades
  • Remediação
  • Analisar opções de correção
  • Documentar a correção ou atenuação
  • Divulgação de vulnerabilidades
  • Adote padrões do setor, como CVE/CVSS, para padronizar como você documentará e comunicará/divulgará vulnerabilidades
  • Criar modelos para comunicações
  • Comunicar às partes interessadas
  • Reconhecer pesquisadores/pesquisadores

Nível de Maturidade 2

  • Fundamentos Operacionais
  • Estabeleça carta
  • Construir modelo organizacional
  • Garantir a gestão e o suporte às partes interessadas
  • Identificar requisitos adicionais de pessoal
  • Identificar recursos e ferramentas adicionais
  • Garantir que as políticas de suporte de filial/versão e os ciclos de vida sejam compreendidos
  • Criar métricas de linha de base
  • Estabelecer um registro de produto com mapeamento de dependência
  • Gestão do Ecossistema de Stakeholders
  • Identificar as partes interessadas internas que serão fundamentais para o gerenciamento de vulnerabilidades
  • Identificar as partes interessadas a jusante
  • Estabelecer comunicações e coordenação de incidentes
  • Descoberta de vulnerabilidades
  • Estabelecer processo para descobrir vulnerabilidades não relatadas
  • Triagem de Vulnerabilidades
  • Identifique os localizadores que vêm repetidamente até você com relatórios de qualidade
  • Desenvolver capacidade de reprodução de vulnerabilidades internas
  • Remediação
  • Formalizar plano de gerenciamento de soluções de segurança
  • Divulgação de vulnerabilidades
  • Criar sistema para notificar as partes interessadas
  • Estabelecer métricas de vulnerabilidade
  • Treinamento & Educação
  • Fornecer treinamento para os membros da equipe PSIRT
  • Fornecer mecanismos de feedback

Nível de Maturidade 3

Artigo Original