0
0
À medida que vulnerabilidades de segurança são relatadas repetidamente, você pode se perguntar: “Por que esses desenvolvedores não aprendem a lição?” A próxima coisa que você pode pensar é: “Deveríamos treinar os desenvolvedores, para que parem de cometer esses erros”.
Por muitos anos, esses também foram meus pensamentos, pois relatei centenas de vulnerabilidades aos meus clientes após fazer revisões de código.
Mas as plataformas de treinamento de código seguro mudaram alguma coisa? Eles pressionaram esses desenvolvedores “travessos” a serem proativos em relação à segurança de seu software? Acabei relatando menos vulnerabilidades recorrentes? Infelizmente, a resposta a todas essas perguntas é “não”.
Em vez disso, muitos desenvolvedores consideram as plataformas de treinamento chatas; alguns fazem apenas o suficiente para concluir os cursos obrigatórios e outros procuram desculpas para não cursá-los. Isso porque deixamos de lado um ponto muito importante: os desenvolvedores são solucionadores de problemas.
Se você observar a rotina diária de um desenvolvedor, verá que encontrar maneiras de resolver um problema é o seu pão com manteiga. Eles recebem especificações de uma aplicação, sabem onde e como procurar maneiras de atender a cada especificação e entregam uma solução completa.
Um desenvolvedor não precisa que lhe digam “como” fazer algo, mas sim “o que” fazer.
Precisamos definir melhor o problema, em uma linguagem com a qual eles se relacionem. Esta é a parte que não fizemos bem.
A linguagem usada pelos profissionais de segurança – terminologia bizarra e títulos irregulares de vulnerabilidades de segurança – não é boa para comunicar a natureza dos problemas de segurança aos desenvolvedores. Os dois grupos simplesmente não falam a mesma língua.
Deixe-me dar um exemplo.
Uma vulnerabilidade de software é um bug ou uma falha de design. No mundo do desenvolvedor, um bug geralmente está relacionado a um problema de implementação (um problema no código) e uma falha de design está relacionada a um problema de arquitetura de software. Mas uma vulnerabilidade – um termo normalmente utilizado pela indústria de segurança – não diz imediatamente ao desenvolvedor “qual é” o problema. Se apenas explicarmos se uma vulnerabilidade é um problema na implementação ou no design, os desenvolvedores ficariam gratos.
Outro exemplo de formulação inadequada é “carga útil do invasor” – uma expressão à qual os profissionais de segurança se referem quando falamos sobre uma entrada maliciosa. O que deveríamos dizer é que é “uma entrada rara que causa uma exceção em tempo de execução”. (Exceção em tempo de execução é um estado no software que não é tratado corretamente e permanece indeterminado. Muitas vulnerabilidades de segurança são exceções em tempo de execução.)
Envolva os desenvolvedores
Acredito que antes de ensinar o “como” aos desenvolvedores, devemos primeiro interagir com eles e despertar seus interesses. Deveríamos começar definindo o problema na linguagem deles e fazer com que a busca por uma solução parecesse atraente para suas mentes curiosas e solucionadoras de problemas.
Implementamos essa ideia em nossa empresa de jogos de guerra nativa para desenvolvedores, onde transformamos vulnerabilidades de segurança em sandboxes de aplicativos totalmente funcionais que um desenvolvedor pode executar, testar e depurar.
Em vez de usar ferramentas externas para simular ações de invasores, nós as codificamos em testes de especificação de software (código que os desenvolvedores escrevem para verificar se a aplicação segue a especificação). Portanto, os desenvolvedores podem usar as mesmas ferramentas que usam em seu trabalho diário para explorar completamente a vulnerabilidade de segurança.
Com esta abordagem, colmatamos a lacuna da barreira linguística. A vulnerabilidade de segurança é traduzida em um aplicativo totalmente funcional, juntamente com testes de especificação de segurança, e define claramente o problema de segurança na linguagem dos desenvolvedores, para que eles saibam como proceder para depurar.
Este método de entrega comunica melhor o problema aos desenvolvedores e desperta seu interesse em resolvê-lo. Vemos as equipes de desenvolvimento de nossos clientes tornarem-se proativas na localização e correção de problemas de segurança. Nossos clientes veem suas equipes de desenvolvimento considerarem as vulnerabilidades de segurança um problema interessante para depurar e não uma solicitação bizarra feita pelo pessoal de segurança.
No final das contas, uma vulnerabilidade é um desafio de software divertido de explorar e divertido de resolver.
FONTE: HELP NET SECURITY