0

Incentivar os desenvolvedores é a chave para melhores práticas de segurança

O cenário de ameaças cibernéticas está se tornando mais complexo a cada dia. Os invasores estão constantemente varrendo as redes em busca de aplicativos, programas e instâncias de nuvem vulneráveis, e a última novidade do mês são as APIs, amplamente consideradas uma vitória fácil graças aos seus controles de segurança muitas vezes frouxos.

Eles são tão persistentes que novos aplicativos às vezes podem ser comprometidos e explorados horas após a implantação. O Relatório de investigações de violação de dados da Verizon 2021 deixa muito claro que as ameaças levantadas contra empresas e organizações são mais perigosas hoje do que em qualquer outro momento da história.

Está ficando muito claro que a única maneira de realmente fortalecer o software que está sendo criado é garantir que ele seja construído em um código seguro. Em outras palavras, a melhor maneira de impedir a invasão do agente de ameaça é negar a eles uma posição segura em seus aplicativos. Depois de começar a lutar nessa guerra, a maioria das vantagens é direcionada para os atacantes.

Essa situação deu origem ao Agile e DevOps, e depois a todo o movimento DevSecOps, onde a segurança é uma responsabilidade compartilhada por todos os envolvidos no processo de criação de software, desde o desenvolvimento até a implantação. Mas a base dessa pirâmide, e sem dúvida a parte mais importante, são os desenvolvedores. Embora a maioria dos desenvolvedores queira fazer sua parte e escrever um código seguro, muitas das organizações para as quais trabalham dão menos apoio às mudanças que essa grande mudança nas prioridades exige.

Derrota pelo Design

Por muitos anos, os desenvolvedores foram informados de que sua função principal em suas organizações era construir e implantar aplicativos rapidamente em um ambiente de ritmo acelerado, onde os negócios nunca param e os clientes nunca dormem. Quanto mais rápido os desenvolvedores pudessem codificar e quanto mais recursos eles pudessem implantar, mais valiosos seriam vistos em termos de suas avaliações de desempenho.

A segurança foi uma reflexão tardia, se é que foi considerada. Em vez disso, tudo isso foi deixado para as equipes de segurança de aplicativos (AppSec) descobrirem. As equipes do AppSec não eram apreciadas pela maioria dos desenvolvedores porque frequentemente enviavam aplicativos concluídos de volta ao desenvolvimento para aplicar patches de segurança ou reescrever o código para corrigir vulnerabilidades. E cada hora que um desenvolvedor passava trabalhando em um aplicativo que já estava “concluído” era uma hora em que ele não estava criando novos aplicativos e recursos, diminuindo assim seu desempenho (e seu valor, aos olhos de uma empresa particularmente punitiva).

E então o ambiente de ameaças mudou a importância e a priorização da segurança para a maioria das empresas. De acordo com o recente Relatório de custo de uma violação de dados da IBM e do Ponemon Institute, a violação de segurança cibernética média agora custa cerca de US $ 3,8 milhões por incidente, embora esse seja dificilmente o limite superior. Uma empresa sozinha sofreu perdas de US $ 1,3 bilhão após uma violação em sua rede. As empresas de hoje querem a segurança oferecida pelo DevSecOps, mas, infelizmente, têm demorado a recompensar os desenvolvedores que atendem a essa chamada.

Simplesmente dizer às equipes de desenvolvimento para considerarem a segurança não funcionará, especialmente se elas ainda estiverem sendo incentivadas apenas com base na velocidade. Na verdade, dentro de tal sistema, os desenvolvedores que dedicam tempo para aprender sobre segurança e proteger seu código podem estar perdendo em melhores avaliações de desempenho e bônus lucrativos que seus colegas menos preocupados com a segurança continuam a ganhar. É quase como se as empresas estivessem inadvertidamente manipulando o sistema para suas próprias falhas de segurança, e isso remete à percepção que têm da equipe de desenvolvimento. Se eles não os vêem como a linha de frente da segurança, é muito improvável que um plano viável para utilizar sua força de trabalho venha a ser concretizado.

E isso nem explica a falta de treinamento. Alguns desenvolvedores muito qualificados têm décadas de experiência em codificação, mas muito pouco quando se trata de segurança … afinal, isso nunca foi exigido deles. A menos que uma empresa forneça um bom programa de treinamento para seus programadores qualificados, dificilmente poderá esperar que seus desenvolvedores obtenham repentinamente novas habilidades e as coloquem em ação de uma forma significativa que reduza ativamente as vulnerabilidades.

Recompensando os desenvolvedores por boas práticas de segurança

A boa notícia é que a grande maioria dos desenvolvedores faz seu trabalho porque o considera desafiador e recompensador e porque gosta do respeito que sua posição acarreta.

O codificador profissional de longa data Michael Shpilt escreveu recentemente sobre todas as coisas que o motivam e a seus colegas de programação em seu trabalho de desenvolvimento. Sim, ele lista a compensação monetária entre esses incentivos, mas é surpreendentemente bem no final da lista. Em vez disso, ele prioriza a emoção de criar algo novo, aprender novas habilidades e a satisfação de saber que seu trabalho será usado diretamente para ajudar outras pessoas. Ele também fala sobre querer se sentir valorizado dentro de sua empresa e comunidade. Resumindo, os desenvolvedores são como muitas pessoas boas que se orgulham de seu trabalho.

Desenvolvedores como Shpilt e outros não querem que os agentes de ameaças comprometam seu código e o usem para prejudicar sua empresa ou os próprios usuários que estão tentando ajudar. Mas, eles não podem mudar repentinamente suas prioridades para segurança sem suporte. Caso contrário, é quase como se o sistema trabalhasse contra eles.

Para ajudar as equipes de desenvolvimento a melhorar suas habilidades em segurança cibernética, elas devem primeiro aprender as habilidades necessárias. Utilizar o aprendizado por andaime e ferramentas como o treinamento Just-in-Time (JiT) pode tornar esse processo muito menos doloroso e ajuda a desenvolver o conhecimento existente no contexto certo.

O princípio do JiT é que os desenvolvedores recebem o conhecimento certo no momento certo, por exemplo, se uma ferramenta de treinamento de desenvolvedor JiT detecta que um programador está criando um código inseguro ou introduzindo acidentalmente uma vulnerabilidade em seu aplicativo. podem ativar e mostrar ao desenvolvedor como eles podem corrigir esse problema e como escrever um código mais seguro para executar a mesma função no futuro.

Com o compromisso de melhorar as habilidades, os velhos métodos de avaliação de desenvolvedores com base apenas na velocidade precisam ser eliminados. Em vez disso, os programadores devem ser recompensados ​​com base em sua capacidade de criar código seguro, com os melhores desenvolvedores se tornando campeões de segurança que ajudam o restante da equipe a aprimorar suas habilidades. E esses campeões precisam ser recompensados ​​com o prestígio da empresa e com uma compensação monetária. Também é importante lembrar que os desenvolvedores normalmente não têm uma experiência positiva com segurança, e edificá-los com um aprendizado positivo e divertido e incentivos que atendam aos seus interesses ajudará muito a garantir a retenção de conhecimento e o desejo de continuar desenvolvendo habilidades .

As empresas ainda podem incluir a velocidade de codificação como uma parte da avaliação do desenvolvedor, mas com a expectativa de que o desenvolvimento de aplicativos seguros possa demorar um pouco mais, especialmente porque os programadores estão aprendendo essas novas habilidades.

DevSecOps pode ser a defesa definitiva contra as artes das trevas de um cenário de ameaças cada vez mais perigoso. Só não se esqueça que os campeões deste novo mundo, os desenvolvedores que estão criando novos códigos de forma consistente, precisam ser respeitados e recompensados ​​por seu trabalho.

fonte THN

charles

Deixe um comentário

O seu endereço de e-mail não será publicado.