Muitas empresas ainda não estão totalmente cientes das vantagens de usar a difusão no desenvolvimento de seus produtos de software. Mas a segurança do produto deve acompanhar o desenvolvimento. Porque corrigir o que já foi feito é trabalhoso e muito mais caro do que fazer o bem imediatamente.
E isso apesar do fato de que conceitos como SDLC (Ciclo de Vida de Desenvolvimento de Segurança) e, relativamente recentemente, como DevSecOps ou SecDevOps, aparecem no mundo do desenvolvimento há muito tempo, mas nem todos usam essas técnicas. Eles têm uma essência - implementar abordagens para melhorar a segurança desde os primeiros estágios de desenvolvimento, e é melhor começar com o treinamento dos funcionários. E, é claro, é importante prestar atenção à segurança do produto contra ataques durante todo o seu ciclo de vida. Para detalhes - bem-vindo ao gato.
Uma das etapas mais importantes no desenvolvimento seguro é a difusão. Fuzzing é uma técnica de teste de software, cuja essência é a detecção automatizada de erros de implementação, enviando dados conscientemente incorretos e analisando a reação do programa a eles.
Enquanto escrevia um artigo no Twitter, as notas tremeluziam sobre o uso de fuzzing de Dmitry Vyukov.
Ele apenas chama a atenção para o fato de que, ao usar a difusão, é possível detectar um grande número de erros no código, que, de outra forma, não desapareceriam mesmo depois de um lapso de tempo.
Normalmente, a difusão completa o processo de desenvolvimento, mas também pode separar funções do produto desenvolvido.
Vantagens da difusão sobre outros métodos de teste:
- Você pode iniciar o fuzzer e esquecê-lo até o final do teste e trabalhar com os resultados
- o teste automatizado pode identificar os erros que não foram encontrados pelo teste manual, devido à maior cobertura do código;
- permite coletar uma idéia geral da segurança do código testado.
Um dos casos sensacionais em que a difusão fez sua boa ação é a descoberta de cinquenta CVEs no Adobe Reader em 50 dias. Os pesquisadores conseguiram encontrar tantas vulnerabilidades sem acesso ao código fonte, e é difícil imaginar quantas delas teriam sido descobertas se tivessem a fonte.
Se você procurar em fontes abertas informações sobre o uso de fuzzing entre desenvolvedores, a Microsoft será a primeira. Esta empresa é uma das pioneiras na difusão no SDLC. Eles possuem o Security Risk Detection , um serviço que permite que os usuários baixem arquivos binários para a difusão. Quais dados serão alimentados na entrada, o usuário decide. O resultado do fuzzer são os erros encontrados e os dados que os geraram.
O Google também usa difusão, e eles têm muitas ferramentas de domínio público. O mais interessante deles é o OSS-Fuzz . Sua essência é que qualquer pessoa pode fazer uma solicitação de recebimento com seu fuzzer. Geralmente, esses são os fuzzers, criados pelos desenvolvedores para seus pequenos projetos. Além desses difusores, o Google usa o ClusterFuzz para detectar erros no Chrome. Por vários anos, mais de 16 mil vulnerabilidades no navegador e mais de 11 mil em 160 projetos de código aberto foram descobertas.
Algumas empresas que desenvolvem software fornecem a todos os conjuntos noturnos para fuzzing. O mesmo acontece com o Mozilla e o VLC . Qualquer pessoa pode baixar o assembly e tentar procurar por erros e vulnerabilidades nele.
Obviamente, muitos desenvolvedores de software proprietário não falam sobre como eles aumentam a segurança de seus produtos. Mas o fato de muitos deles não prestarem a devida atenção à segurança de seus produtos é evidente no número de vulnerabilidades detectadas. Portanto, decidimos realizar uma pesquisa de amostra com os desenvolvedores para descobrir sua atitude em relação à confusão.
Fizemos as seguintes perguntas:
Você usa difusão no seu processo de desenvolvimento de produto?
Um terço dos entrevistados respondeu a essa pergunta positivamente.
Se não estiver usando, então por quê? Ou o que, na sua opinião, normalmente impede você de incorporar a fase de confusão no processo de desenvolvimento do produto?
Possíveis respostas:
- Nada a mexer
- A segurança do produto não é uma prioridade
- Nenhuma ferramenta adequada
- Nenhum especialista relevante
- Falta de infraestrutura apropriada
- Outros
Os entrevistados podem escolher vários motivos para se recusar a usar a difusão no processo de desenvolvimento.
O diagrama mostra a porcentagem de relevância dos motivos para recusar a difusão no processo de desenvolvimento.
O motivo mais comum para NÃO usar fuzzing foi a falta de funcionários qualificados nessa área. Mas nem sempre é necessário ter seus próprios especialistas em segurança da informação, você pode atrair especialistas externos que auditarão os produtos desenvolvidos.
Alguns dos entrevistados que escolheram a opção de resposta "Outro" forneceram respostas detalhadas interessantes. Aqui estão algumas das razões para recusar a difusão:
- o departamento de segurança da informação não gostou da iniciativa de um dos desenvolvedores de escrever seu fuzzer;
- falta de técnicas de pesquisa de vulnerabilidades do FSTEC.
Entre as respostas estavam esclarecimentos sobre o uso de fuzzers AFL e libfuzzer , o que é uma boa notícia .
Como especialistas em segurança, recomendamos que você não negligencie o desenvolvimento seguro, incluindo o uso de fuzzing, para aumentar a segurança de seus produtos.