Baixar a Status
Contribuir

O que é uma auditoria de segurança, quando você deve obtê-la e como se preparar

on Privacidade e Segurança
O que é uma auditoria de segurança, quando você deve obtê-la e como se preparar

Vamos falar sobre "auditorias" ou avaliações de fornecedores externos em uma seção específica de código, produto, funcionalidade, tecnologia, etc.

Muitos usam os termos alternadamente; este documento usará o termo avaliação, pois implica (em minha opinião) a maneira apropriada de pensar sobre as coisas. O título usa a palavra “auditoria” porque essa é normalmente a palavra usada, mas geralmente dá a conotação de que os resultados são uma certificação de conformidade com padrões específicos, muitas vezes legais. O processo de fazer com que seus contratos inteligentes e infraestrutura de suporte sejam revisados ​​por profissionais de segurança, e essa mentalidade não deve ser reforçada. Aqui está um artigo que descreve algumas diferenças mais significativas entre os dois termos.

Atualmente, existe uma grande lacuna de conhecimento sobre o processo de avaliação entre desenvolvedores e revisores. Este documento é uma tentativa de reduzir essa lacuna, esclarecendo as expectativas típicas dos fornecedores e os métodos que as organizações podem usar para melhor atendê-las, durante seu processo de desenvolvimento. Mais especificamente, este documento detalha os conceitos de como uma organização:

  • deve pensar sobre uma avaliação
  • deve se preparar para uma avaliação
  • deve abordar a busca de fornecedores
  • maximizar os resultados de uma avaliação

Seguindo essas etapas, uma organização que constrói coisas pode:

  • minimizar o custo da avaliação
  • minimizar o tempo necessário para realizar o trabalho associado
  • ter uma ideia melhor coordenada entre todas as partes do trabalho que está sendo feito e seus resultados esperados
  • ter a documentação mínima exigida
  • ter uma ideia muito boa do risco associado ao projeto, onde exatamente ele se encontra e as regras em que seus usuários o acessam

Observe que este não é um guia completo sobre todas as coisas relacionadas às avaliações. Existem muitos detalhes nas relações entre a organização e o fornecedor da avaliação. Este documento deve prepará-lo para começar a desenvolver práticas dentro de sua organização para fortalecer esses relacionamentos. Este documento provavelmente mudará com o tempo, conforme nós da Status nos tornamos mais informados e experientes nesse processo, portanto, verifique novamente de vez em quando. A forma atualizada deste estará em nossa Documentação de Segurança.

Acerte sua Mentalidade

Para entender adequadamente todos os meandros que uma organização deve passar para obter uma avaliação externa, primeiro é necessário ter um processo de pensamento unificado sobre o que é uma “auditoria” ou avaliação. Uma avaliação é uma chance de obter olhos externos sobre um projeto específico, uma arquitetura proposta ou até mesmo uma parte específica de um projeto para que você possa ganhar mais confiança de que funciona da maneira que você pretende, e não de outra maneira. Ele está contratando temporariamente conhecimentos adicionais (ou de domínio específico) que sua organização não possui. Além disso, é uma chance de obter uma nova perspectiva sobre algo que está sendo desenvolvido, o que ajuda a remover o preconceito do desenvolvedor, entre outras coisas.

Normalmente, uma empresa contrata um fornecedor terceirizado para uma avaliação a fim de complementar a falta de conhecimento (ou capacidade) que a organização tem com relação a um domínio. Por exemplo, uma empresa pode se envolver em uma avaliação se:

  • eles carecem de experiência interna para avaliar adequadamente as implicações de segurança de uma tecnologia
  • eles carecem de experiência interna para operar ou licença para acessar ferramentas dedicadas a encontrar e mitigar problemas
  • o material de avaliação em questão é substancialmente de alto risco e um par adicional de olhos é garantido
  • eles estão buscando informações (de preferência no início do processo) para identificar:
  • principais riscos para mitigar com base nas especificações de sua construção de sistema
  • oportunidades para melhorar a arquitetura para segurança e auditabilidade

Não se pode exagerar que uma avaliação externa NÃO dá garantias de qualidade / segurança do código ou dá um selo de aprovação. Muitos acreditam que uma avaliação é um selo de confiança de que podem comercializar para uma ampla comunidade, provando um nível específico de segurança e “qualidade de produção”. Essa mentalidade deve ser evitada a todo custo. Uma avaliação de segurança deve ser considerada simplesmente como obter atenção adicional e especialização em uma funcionalidade ou seção de código específica e uma oportunidade de obter insight e sabedoria em um campo de conhecimento para que o desenvolvimento futuro possa ter uma qualidade superior. De maneira mais geral, o nível de garantia deve aumentar como resultado de uma avaliação. No entanto, a ausência de evidência não é evidência de ausência em relação às vulnerabilidades detectadas durante a avaliação.

Muitos fatores entram em jogo e ditarão a qualidade de qualquer avaliação. Aqui estão algumas coisas que você deve manter que afetam a qualidade geral da avaliação.

Experiência do Fornecedor

A experiência do fornecedor que realiza uma avaliação com o respectivo código ou tecnologia. Os fornecedores geralmente têm especialidades específicas nas quais se destacam e anunciam como tal. A equipe disponível, a experiência anterior e o profissionalismo afetarão o resultado de uma avaliação. É importante perceber isso quando é hora de começar a procurar um fornecedor para uma avaliação. Não se deve esperar que um fornecedor líder em design e experiência do usuário faça avaliações importantes sobre a arquitetura de infraestrutura distribuída.

Recursos Disponíveis do Fornecedor

Os recursos que o fornecedor pode alocar para a avaliação. Isso geralmente é uma função de quão ocupados eles estão, seus recursos disponíveis na tecnologia e se o orçamento de avaliação disponível está ou não alinhado com o nível apropriado de esforço necessário para realizar um trabalho adequado. Isso não se refere apenas às horas de trabalho disponíveis do fornecedor, mas também às suas ferramentas internas e especialização com ferramentas e práticas recomendadas padrão da indústria.

Documentação Disponível

A documentação e qualidade do respectivo código e tecnologia em avaliação. Você pode considerar um fornecedor como um novo contratado em um projeto, e ele precisa ir do zero a especialista em um período de tempo muito curto. Sua capacidade de fazer isso é fortemente influenciada pelos recursos que são dados a eles para fazer esse trabalho. Se for inadequado, um fornecedor gastará uma parte substancial do tempo de avaliação pago para acelerar e ajudar a fazer esses recursos. Isso significa que eles irão estender o tempo de avaliação necessário para fazer um trabalho adequado (aumentando assim o preço exigido) ou diminuir drasticamente o tempo disponível para fazer seu trabalho especializado (diminuindo assim a qualidade geral).

Desenvolvimento

O número de problemas conhecidos com o código, tecnologia ou funcionalidade associada que está sendo avaliada. Os fornecedores de avaliação agrupam os problemas conhecidos no passado para aumentar a maré de conhecimento em toda a linha. Se uma determinada tecnologia for relativamente nova, os fornecedores estarão menos equipados para encontrar problemas potencialmente profundos que ainda não foram descobertos no ecossistema. Na verdade, muitas vezes, problemas amplos com relação a uma determinada tecnologia são descobertos durante as avaliações. Se esses problemas existem e ainda precisam ser descobertos, a probabilidade de que isso aconteça depende muito de quão bem você está preparado.

Como se Preparar

Pode ser bastante desanimador ao se preparar para uma avaliação, pois há muitas etapas que você deve seguir para se preparar. Além disso, às vezes é difícil até mesmo avaliar se o material em questão justifica uma avaliação externa. Muitos dos itens necessários para a preparação para a avaliação são, na verdade, apenas boas práticas de desenvolvimento. Aqui, discutimos vários procedimentos e métodos úteis ao considerar uma avaliação. Essas coisas não apenas ajudarão a identificar se você pode ou não precisar de uma avaliação, o que exatamente deve ser avaliado e quem e como abordar as empresas, estar preparado também ajudará todas as partes em todos os aspectos de uma avaliação (como os itens declarados na introdução).

Na verdade, uma preparação adequada o colocará em uma posição decente para seguir em frente, se você não tiver fundos para fazer uma avaliação externa. Preparar-se para uma auditoria é o mesmo que auditar você mesmo o projeto e consertar tudo o que for capaz. Além disso, mostrar formalmente que você está bem preparado e executou todos os métodos disponíveis com os recursos fornecidos pode melhorar drasticamente sua capacidade de levantar fundos adicionais necessários para uma avaliação, pois o trabalho necessário é explicitamente destacado e mais fácil de raciocinar a partir de uma perspectiva de fora.

Como um benefício adicional não específico para uma avaliação de segurança, gastar a quantidade necessária de atenção em informações periféricas de modo que um colaborador externo possa obter tudo o que precisa saber para contribuir com sucesso, reduzindo assim a barreira de entrada para qualquer crescimento da empresa ou contribuidores de código aberto (quando apropriado), bem como minimizando seu tempo para se tornarem produtivos (o que economiza dinheiro e aumenta sua comunidade!).

Então, o que você deve fazer antes de procurar uma avaliação externa? As seções a seguir descreverão vários esforços que ajudam a preparar seu projeto para revisão.

Documente Tudo!

Tenha uma especificação

Qualquer produto deve ter documentação que detalha técnica e explicitamente os requisitos que precisam ser atendidos. O formato disso pode mudar dependendo da natureza do material, mas as especificações técnicas permitem que alguém de fora entenda completamente os fundamentos da funcionalidade do material. É crucial entender se a implementação técnica satisfaz ou não os requisitos do projeto e quais consequências não intencionais podem existir com base nessa implementação.

Por exemplo, a escolha de uma tecnologia específica dentro de um produto pode produzir a funcionalidade desejada, mas sua implementação técnica pode resultar em consequências indesejadas que um especialista notará imediatamente e relatará com base em sutilezas que os desenvolvedores podem não estar cientes. Ter uma especificação ajuda a detalhar o que é usado e como é usado, para que os fornecedores externos sejam capazes de identificar exatamente onde está um problema, e também ajuda a capacitá-los e a dar recomendações específicas sobre como mitigá-lo.

Quanto menos detalhado for o seu produto especificado, mais recomendações ambíguas terão em relação a qualquer problema.

Descreva como interagir com ele

Portanto, todo produto precisa de documentação (todos sabemos que a maioria odeia essa parte). Lembre-se, um fornecedor (ou novo contribuidor!) Precisa ir de zero a herói no menor tempo possível, e a documentação é o caminho usado para chegar lá. Você pode estar dizendo "mas já fizemos uma especificação!" Bom, mas uma especificação trata de detalhes minuciosos sobre os aspectos técnicos do projeto. A documentação é de alto nível e explica como as coisas se encaixam, como é usado, etc. A especificação detalha o que o produto deve fazer (e como) para atender aos requisitos, enquanto a documentação descreve o que ele realmente faz.

Se você estiver construindo um produto, um fornecedor precisará construí-lo e, potencialmente, verificar esse processo. Certifique-se de que o processo esteja totalmente atualizado e documentado para que eles não tenham que parar e fazer perguntas toda vez que encontrarem um obstáculo na construção.

Tenha histórias de usuários exaustivas

As pessoas usam o que você está construindo? Em caso afirmativo, para quê? Um produto deve delinear em detalhes os atores que interagem de todas as maneiras possíveis que se pretendem. Ao permitir que um fornecedor entenda quais são os usuários pretendidos, suas possíveis interações e o resultado de suas ações (chamada de história), você agiliza a identificação de casos de uso não intencionais, interações e resultados que devem ser levantados como um problema, e potencialmente corrigido. Ou talvez você tenha sorte e algo não intencional se torne um novo recurso, e não um bug (mas provavelmente não)!

Execute modelagem de ameaças

OK! Você documentou como usá-lo, especificou exatamente como é construído e detalhou os usuários pretendidos que interagem com ele. Agora é hora de ver as coisas de uma lente diferente, a de um "invasor". Uma breve descrição da modelagem de ameaças é pensar sobre o que um adversário do seu sistema tentaria fazer, onde tentaria fazer coisas “ruins” e o que teria que quebrar para “ter sucesso” nisso.

Mais formalmente, a modelagem de ameaças é o processo de identificar ativamente onde está o risco (valor) de um projeto, como ele é acessado, quem tem acesso e quais processos de segurança existem para controlar tudo isso. Esta é uma parte importante da preparação para uma avaliação externa por muitos motivos.

Para começar, o fornecedor provavelmente fará isso! Ao iniciar esse processo por conta própria e documentar os resultados, você elimina a necessidade de criar os documentos resultantes associados (exemplos abaixo). É mais do que provável que tenham perguntas e queiram alterá-las com base nas descobertas, mas este é um processo de melhoria, não de criação.

Uma forma básica, mas muito valiosa de comunicar um modelo de ameaça é listar os vários atores (ou seja, administrador, portador de token, outros usuários Ethereum) e seus recursos pretendidos dentro do sistema (exemplo).

A modelagem de ameaças é uma forma sistemática de identificar onde o valor (portanto, o risco) reside em um determinado sistema. A documentação resultante desse processo geralmente leva a um diagrama de risco em todos os componentes disponíveis de um sistema e a uma visão geral de como tudo está conectado. Esses diagramas servem como uma compreensão central para a arquitetura por todas as partes que contribuem para ela, bem como uma visão panorâmica de "como tudo se encaixa".

Se você tiver um mapa de risco para um sistema, será mais fácil avaliar se um determinado sistema justifica ou não uma avaliação externa e, em caso afirmativo, ele indica exatamente onde o foco deve ser feito. Muitas vezes as organizações abordam os fornecedores para uma avaliação e, quando questionadas sobre o escopo do projeto, a organização simplesmente diz "Não sei, diga você!" Isso não apenas aumenta drasticamente o preço potencial de uma avaliação, mas também pode levar um fornecedor a realizar uma avaliação sobre coisas que nem mesmo são seu foco principal, porque eles não sabem onde está o risco (ou pelo menos como você vê isto).

Teste Você Mesmo

Realizar histórias de usuários

Então você tem um sistema funcionando. Você acha que ele faz o que você se propôs a fazer. Bom, agora certifique-se disso. Se você fez o processo de planejamento anterior corretamente, deve ter um conjunto de histórias de usuário que detalham o caminho ideal de uso do sistema. Faça-os, explicitamente. Certifique-se de que a experiência seja a que você espera para casos de uso individuais. Uma boa lista de verificação inicial de coisas a fazer é o que a especificação precisa detalhar.

Teste de forma aleatória

Essa é a primeira parte, certificando-se de que o sistema faça o que foi projetado com uma experiência aceitável. O próximo passo é tentar quebrá-lo de qualquer maneira que você possa vê-lo quebrando. Tente acessar coisas que não devem ser acessadas. Coloque em caracteres aleatórios onde deveria haver números. O sistema deve falhar normalmente em todas as tentativas fora do escopo definido porque os usuários TENTARÃO fazer coisas fora do que você espera que eles façam.

Crie Teste Corpus

Não vou insistir com você sobre os vários tipos de frameworks de teste disponíveis, mas apontarei algumas coisas que devem ser feitas. Você não deve apenas testar o que o sistema deve e não deve fazer, mas esses testes devem ser codificados e executados sempre que forem feitas alterações. Dessa forma, se a introdução de uma alteração interromper algo que estava funcionando anteriormente, você poderá detectá-lo rapidamente e corrigi-lo antes que se torne um problema.

O processo de testar seu sistema (e documentar seu teste) ajuda você de várias maneiras. Primeiro, ele permite que você tenha um nível mais alto de confiança de que o código funciona conforme o planejado e é resiliente a novas alterações que quebram essa confiança. Quanto mais robusta for uma estrutura de teste, maior será a confiança. Além disso, também fornece clareza, cobertura e contexto do que já foi feito para aqueles que avaliariam a base de código. Quanto mais você testa, mais informações você dá sobre a intenção do sistema e sua implementação para aqueles que irão avaliá-lo.

Use Testes Automatizados

Também é aconselhável tirar proveito de vários softwares de teste automatizados para aumentar seu corpus de teste de uma maneira que não seja viável por teste manual. O teste manual é feito para capturar as coisas que você pode intuir sobre como o sistema funciona, o teste automatizado é usado para tentar capturar as outras coisas. Por exemplo, o processo de implementação de um fuzzer de software pode ajudá-lo a ver como o sistema trava quando uma entrada aleatória é alimentada no sistema, e a uma taxa de teste que é apenas razoável para um computador fazer. Implicitamente, os locais em que você configura um fuzzer também ajudam terceiros a entender os pontos de entrada potenciais de um sistema.

Etapas para uma Avaliação

Você projetou o trabalho, fez o trabalho, documentou o trabalho, testou o trabalho. Agora é hora de fazer com que o trabalho seja examinado por outras pessoas. Vamos falar sobre como você fará isso e talvez o motivo por trás do porque você pode querer fazer isso.

Você deve pelo menos fazer uma auditoria?

Quando e se você deve fazer uma auditoria ou avaliação é algo subjetivo, e há muitas variáveis ​​que entram em jogo para ajudar uma empresa a descobrir isso. Muito do processo definido anteriormente não só ajuda a criar sistemas seguros que são mais facilmente acessíveis a outras pessoas, mas também ajuda a maximizar a capacidade de uma equipe de avaliar se deve ou não empregar terceiros para ajudar com essa avaliação.

Aqui estão algumas das questões que você deve considerar ao analisar se uma avaliação é necessária:

  • Quanto risco existe no sistema e como isso se compara ao risco geral na organização ou ecossistema do qual faz parte?
  • Quão complexo é o sistema?
  • O sistema faz uso de tecnologias que exigem conhecimentos específicos para implementação, e você tem esses recursos internamente?
  • Como o custo potencial de uma avaliação se compara ao valor (ou risco) que o sistema manterá?
  • Qual é o custo potencial de falha do sistema?

Se você forneceu respostas detalhadas a essas perguntas, então você tem mais material para justificar se uma avaliação adicional é necessária ou não. Vamos discutir um pouco sobre como definir o que parece e alguns métodos para abordar aqueles que são capazes de realizar a avaliação.

Defina o escopo

Para que você se envolva adequadamente com alguém para auditar sua base de código, primeiro você deve definir qual seria a tarefa dela. Os auditores não são oniscientes. Eles são pessoas com conjuntos de habilidades especializadas para alugar. É seu trabalho chegar à mesa com expectativas.

Isso significa que, antes de envolvê-los, você deve definir explicitamente o que deseja que eles vejam e os tipos de perguntas que deseja responder como resultado. Se você seguiu as recomendações anteriores, já fez a maior parte do trabalho necessário para isso. A tarefa agora é restringir a base de código às seções que requerem um exame mais minucioso.

Normalmente, isso se refere a áreas dentro do sistema que carregam a maior parte do risco (que você já definiu convenientemente) ou as partes mais complexas do sistema que requerem mão de obra altamente qualificada para criar, ou tecnologia especializada para implementar.

Em suma, definir o escopo é uma declaração para os potenciais auditores de "sentimos que esta parte da base de código merece mais atenção e não temos os recursos internos para fazê-lo o suficiente por nós mesmos." Observe que não ter os recursos internos apropriados não é pouca coisa, mas simplesmente uma inevitabilidade ao construir software complexo. É extremamente raro que um novo sistema que pode gerar riscos seja construído do zero sem o uso de tecnologias desenvolvidas em outro lugar.

Tenha um orçamento preparado

Agora que você sabe o que quer e chega à conclusão de que não pode fazer sozinho, é preciso ter um orçamento para pagar alguém para fazer isso. Esta não é uma tarefa fácil, pois os preços flutuam drasticamente entre setores, empresas e épocas. Não vou especular aqui quanto ao porquê.

Felizmente, como você seguiu todos esses conselhos, já trabalhou muito para definir com precisão o que um candidato a auditor faria e criou os materiais necessários para fazê-lo com eficiência. Esse é um benefício adicional de desenvolver software dessa maneira, pois reduz drasticamente o custo das avaliações e aumenta sua eficácia para você como organização e para a comunidade em geral.

[ENCONTRE RECURSOS AQUI PARA AJUDAR AS PESSOAS A ESTIMAR OS CUSTOS DAS AUDITORIAS]

Escreva um documento de solicitação de propostas (RfP)

A próxima etapa no processo de obtenção de uma avaliação externa é reunir tudo em um único documento. Este documento é normalmente referido como documento de Solicitação de Propostas. Aqui está um esboço típico de tal documento:

  • Introdução: quem somos nós como organização
  • Descrição do projeto: contexto do projeto em questão para avaliação
  • Recursos: material e documentação útil para a compreensão do projeto
  • Escopo: o escopo do trabalho a ser feito
  • Descrição do Engajamento: como você imagina a aparência de todo o engajamento
  • Produtos: o que você espera que sejam os resultados da avaliação
  • Indenização e estrutura de taxas: como as pessoas estão sendo pagas
  • Critérios de seleção: o que você procura em uma organização de avaliação externa
  • Instruções de licitação: como enviar uma proposta
  • Conclusão: considerações finais e diversos

Aqui está um exemplo de tal documento escrito pela Status para a base de código da cadeia de sinalizador Nimbus. Este esboço de documento e processo foi emulado pelo pessoal da Sigma Prime. Achamos que aumenta drasticamente a clareza e a justiça na escolha de auditores para o trabalho. Em nossa experiência, a quantidade de feedback e resposta de fazer isso superou drasticamente as vezes em que entramos em contato diretamente com os fornecedores para um projeto. Criamos relacionamentos com empresas que não existiam anteriormente (mais sobre por que isso é importante mais tarde). Não apenas isso, mas o processo de um RfP permite que você, como empresa, não seja cegado por seu preconceito sobre o que acha que precisa ser feito. Uma proposta enviada pode justificar um trabalho adicional ou um escopo alterado que você não conhecia.

Além disso, força os fornecedores a justificar o custo do trabalho a ser feito em um mercado aberto. Se acontecer de eles serem relativamente caros, a proposta deles deve justificar por que eles cobram o que fazem e o que você ganha com isso. Se seus custos forem relativamente baixos, eles devem ser capazes de justificar que são capazes de fazer um trabalho satisfatório.

Resumindo, ao permitir que os fornecedores licitem seu projeto, você força a comunidade de segurança a vender-se nas competências que cultivaram. Quanto mais informações e detalhes você puder fornecer a eles sobre o trabalho a ser feito, melhor eles poderão fazer isso e maior será a probabilidade de você obter resultados de qualidade da avaliação com um orçamento adequado.

Estabeleça canais de comunicação

Você precisará se comunicar com os fornecedores durante o processo de seleção e durante a avaliação. Vale a pena configurar comunicações seguras com antecedência para facilitar isso, bem como preparar sua equipe para o que esperar.

Você vai querer um canal oficial de comunicação segura; isso normalmente é feito através de e-mail combinado com criptografia PGP. Crie a expectativa de que o negócio oficial da avaliação passe por esse canal para que todas as partes tenham um cadastro. Certifique-se de transmitir sua chave pública PGP no RfP e detalhar o endereço de e-mail apropriado para comunicações.

Ao longo da avaliação, mostrou-se benéfico configurar um canal de comunicação seguro e efêmero para colaboração de curto prazo. Isso permite que a equipe de avaliação tenha acesso à sua equipe no caso de quaisquer bloqueios, mal-entendidos ou atualizações que surgirem. Esteja preparado para que os especialistas de domínio internos (desenvolvedores de software na maioria dos casos) tenham tempo adequado durante a avaliação para responder às perguntas, corrigir problemas e fornecer tudo o que o fornecedor de segurança precisa para realizar seu trabalho de maneira conveniente. Você está pagando por sua experiência, maximize-a.

Em alguns casos, pode valer a pena configurar canais adicionais de comunicação. Pense com antecedência no que sua descrição de engajamento pode garantir. Em nosso caso, achamos útil configurar um processo para que as equipes de avaliação divulguem as descobertas por meio de problemas em questão no repositório do GitHub. Descrevemos esse processo em um documento vivo aqui e atualizamos com base no feedback de cada avaliação externa que realizamos.

O que procurar em um fornecedor de segurança

Existem muitas empresas disponíveis para realizar avaliações de segurança em produtos e tecnologia que uma organização lança. Alguns são excelentes, alguns são bons, outros não, alguns nem deveriam estar oferecendo serviços. Todos eles variam com seus custos associados. Como navegar por isso e escolher um fornecedor adequado por um preço razoável? Abaixo estão algumas ideias que podem ajudar a orientar sua decisão na seleção de um fornecedor apropriado para uma avaliação externa.

Se você seguiu o processo de liberação de um RfP e coletou várias propostas de fornecedores em potencial, poderá ler e escolher a partir da seleção.

O fator número um ao escolher é se um determinado fornecedor é ou não capaz de fazer o trabalho que você definiu (o que enfatiza ainda mais a importância de definir o escopo). A proposta de um fornecedor deve mostrar que eles têm experiência substancial nas tecnologias específicas que estão dentro do escopo da avaliação. Lembre-se de que você está tentando contratar experiência e sabedoria que não possui em sua organização. Deve mostrar um histórico de avaliações anteriores que estão disponíveis para revisão, especificamente dentro de um domínio semelhante de especialização necessária. Se essas avaliações anteriores forem privadas, outras fontes, como material educacional relevante ou trabalho anterior de sua equipe, podem ser suficientes. Se disponível, um fornecedor deve comunicar que desenvolveu ou contribuiu para projetos semelhantes, práticas recomendadas relevantes ou ferramentas associadas à tecnologia em análise.

Os seguintes fatores são preço e cronograma. O fornecedor deve ter uma justificativa por trás de sua estrutura de taxas e por que uma avaliação proposta custou o valor que eles cotaram. Se um fornecedor não for capaz de defender o preço por trás de sua proposta, ele deve ser ignorado. Sua proposta também deve incluir o cronograma esperado para realizar o trabalho e a quantidade de recursos que eles esperam aplicar às tarefas. Esta parte da proposta deve ser pensada com cuidado, pois sua potencial alocação de recursos indica como eles vêem a distribuição de dificuldade na avaliação. Se não estiver de acordo com a forma como você vê o trabalho a ser feito, esclarecimentos e justificativas adicionais devem ser fornecidos.

Deve-se observar aqui que, se você deseja obter uma avaliação sobre o código atualizado que foi auditado, um peso adicional deve ser atribuído ao fornecedor original, já que ele tem experiência anterior em sua base de código específica, entre outros motivos.

Depois de pesar as propostas individuais, tudo se resume a uma decisão subjetiva. Sua decisão deve ser uma otimização de preço e cronograma com a ressalva de que o fornecedor escolhido é capaz de realizar a tarefa em mãos. Observe que isso significa que nem sempre é necessário escolher o fornecedor mais qualificado para o trabalho, mas um fornecedor acima de um limite de capacidade. Todos os processos explicados neste documento devem ajudá-lo a fazer esse julgamento para a organização e os sistemas a serem revisados.

Como maximizar os resultados

Você fez isso. Parabéns por envolver com sucesso a comunidade de segurança e obter uma avaliação externa. E agora?

De acordo com seu RfP, você agora terá um conjunto de entregas para realizar. Geralmente, é na forma de um relatório que detalha as descobertas da equipe e as atenuações propostas. Agora é seu trabalho abordá-los. Você gastou muito tempo, recursos e esforço se preparando para isso e passando por isso. Sua resposta aos frutos desse trabalho deve ser proporcional. Depois de recebido, você deve compreender totalmente os problemas relatados e tratá-los de forma adequada. Se houver ambigüidade no problema, peça mais esclarecimentos ao fornecedor (canais anteriores que ajudaram na configuração). Isso pode significar executar uma correção rápida de uma vulnerabilidade conhecida encontrada, renovando uma parte inteira da base de código para mitigar um tipo específico de vetor de ataque com base na arquitetura fundamental, ou até mesmo abordando o problema como irrelevante. Todas as questões devem ser tratadas de uma forma ou de outra.

Depois que isso acontecer, você deve transmitir os resultados e suas atenuações. A extensão em que você faz isso depende das práticas de sua organização. Na Status, estamos totalmente abertos e divulgamos todas as informações ao público. Uma empresa mais privada pode desejar ofuscar alguns detalhes específicos por razões de segurança.

Além disso, a empresa deve expressar as preocupações levantadas pela auditoria e como elas impactaram sua organização e produto. Isso lhe dá a chance de detalhar quais etapas você está realizando para corrigir problemas subjacentes e quais medidas proativas você está implementando dentro da organização para elevar o nível de segurança, de modo que problemas semelhantes no futuro sejam totalmente evitados ou detectados no início

Por último, você realmente tem que fazer essas coisas, em vez de apenas falar sobre elas.

Recursos adicionais




Related articles