Na minha empresa, estamos trabalhando para adotar o Ciclo de Vida de Desenvolvimento Seguro da Microsoft e parte do processo MSDL envolve o estabelecimento de barras de segurança e privacidade desde o início de um projeto. Eu ouvi o conceito de uma barra de bug antes da MSDL e entendo que é essencialmente uma definição de qual nível / quantidade de bugs você está disposto a aceitar em um produto final, mas eu tenho nunca entendi como criar uma barra de bug para um projeto. Existe algum processo bem documentado para estabelecer barras de bug que eu possa aprender?
Eu tentei fazer algumas buscas no Google para exemplos ou cenários do mundo real de projetos definindo barras de bug no início de um projeto, mas não consigo obter bons resultados ou dicas sobre o processo de estabelecimento de uma barra de bug. Existem exemplos de MSDL do que parecem ser barras de bugs concluídas, mas estou interessado em aprender sobre o processo de definição de algo assim. Por exemplo, para aqueles que já fizeram algo assim antes, você definiu as barras de bugs de uma maneira muito específica (por exemplo, dizendo " Não deve haver acesso não autorizado ao sistema de arquivos: leitura do sistema de arquivos "), ou você adotou uma abordagem adiada de dizer que quando encontrarmos bugs iremos classificá-los em uma escala de 1 a 5 (5 sendo o mais grave), estabeleça agora que nenhum bug acima de 3 será enviado, e deixe seu ranking de bugs até que sejam descobertos? Eu sinto que tentar fazer o primeiro é uma atividade tola e impossível, mas o último é propenso a favorecer a clemência quando um projeto está chegando ao fim.
Novamente, para encerrar tudo isso em uma pergunta sucinta, alguém pode me fornecer uma abordagem bem documentada para definir / criar barras de bug?
Resposta
Let ” s começam com uma definição básica para a barra de bug:
Portas de qualidade e barras de bug são usadas para estabelecer níveis mínimos aceitáveis de segurança e qualidade de privacidade. Uma equipe de projeto deve negociar portas de qualidade (por exemplo, todos os avisos do compilador devem ser triados e corrigidos antes do check-in do código) para cada fase de desenvolvimento. Uma barra de bug é uma porta de qualidade que é usada para definir os limites de gravidade das vulnerabilidades de segurança, por exemplo, nenhuma vulnerabilidade conhecida no aplicativo com uma classificação “crítica” ou “importante” no momento do lançamento. A barra de bug, uma vez definida, nunca deve ser relaxada.
Quando um usuário de software arquiva um relatório de bug, ele deve atribuir uma categoria STRIDE ao bug, se o bug é um cliente ou servidor, e qual escopo o bug afeta. Os usuários podem ser desenvolvedores de software e equipe de controle de qualidade. STRIDE significa:
- falsificação
- adulteração
- repúdio
- divulgação de informações
- negação de serviço (DoS)
- Elevação de privilégio (EoP)
Os valores de “escopo” relevantes são
- Cliente – IU confiável falsificada em cenário comum / padrão
- Cliente – IU confiável falsificada em outro cenário específico
- Cliente – IU falsificada como parte de um cenário de ataque maior
- Servidor – Usuário específico falsificado ou computador sobre protocolo seguro
- Servidor – Usuário aleatório falsificado ou computador sobre protocolo seguro
- Cliente – Dados confiáveis adulterados que persistem após a reinicialização
- Cliente – Dados adulterados que não persiste após reiniciar
A partir daí, é criada uma matriz que atribui um nível de gravidade a cada combinação. Os valores possíveis para o nível de gravidade são:
- Crítico
- Importante
- Moderado
- Baixo
- Nenhum
Exemplo de entrada na matriz (pode haver várias dessas entradas):
Categoria STRIDE: Spoofing
Escopo: Cliente – IU confiável falsificada em cenário comum / padrãoDescrição: Capacidade de o invasor apresentar uma IU que é diferente, mas visualmente idêntica à IU na qual os usuários devem confiar para tomar decisões de confiança válidas em um cenário padrão / comum. Uma decisão de confiança é definida como sempre que o usuário executa uma ação acreditando que alguma informação está sendo apresentada por uma entidade particular – seja o sistema ou alguma fonte local ou remota específica.
Nível de gravidade: Importante
A Microsoft afirma que corrigiu todos os bugs com importância “baixa” antes da implantação.
Leitura adicional
Adicionar uma barra de bug de segurança ao Microsoft Team Foundation Server 2010
Novo SDLC: Ciclo de Vida de Desenvolvimento de Segurança