DevSec – Importância e metodologias mais comuns

fevereiro 19, 2024
8:54 am

Desenvolvimento seguro (Dev-Sec): O que é?

Muito se ouve falar na industria sobre desenvolvimento seguro (DevSec) e suas variantes, DevSecOps e AppSec, no entanto não há um consenso exato sobre o que essa area representa e mesmo se elas são a mesma coisa ou não. Para os fins desse artigo usaremos as seguintes definições para evitar mal entendidos. DevSec será usado quando o objetivo for o código da aplicação ser seguro. Treinamentos e metodologias com essa intenção. DevSecOps envolve o fluxo de desenvolvimento, controle de qualidade, e, deploy da aplicação.

AppSec por sua vez sera usado para se referir a segurança da aplicação durante o seu tempo de vida, isto é, vetores de ataque, vulnerabilidades de todas as categorias, sejam originarias em código proprietário, infraestrutura, ou bibliotecas.

Quando olhamos para DevSec em particular, temos uma gama de desafios enorme naturalmente. As diferentes linguagens de programação, arquiteturas de sistemas, bibliotecas utilizadas que podem ou não ser vulneráveis são os principais elementos de um projeto de DevSec.

Como abordar a questão de DevSec?

Por mais que a tendência natural seja buscar uma solução rápida, única e milagrosa, a chamada bala de prata, a realidade nos mostra que não existe tal alternativa. Em última instancia sempre vai depender das especificidades do negócio, da organização e dos colaboradores da mesma, esse grupo que vai definir a melhor abordagem para o fluxo de DevSec.

Quais são os principais fatores a se considerar?

Perfil de Risco Organizacional;
Tamanho da organização;
Maturidade de segurança;
Capacidade de investimento;
Necessidade para o negócio.

No caso do Risco, ele é definido majoritariamente pelo setor de atuação da mesma, junto com o fluxo de caixa, número de ex-colaboradores que podem ter alguma motivação para tentar alveja-la, questões político-sociais fecham os fatores de risco principais. Outro fator que deve ser levado em conta é o tamanho da mesma, uma organização com 10.000 funcionários é mais fácil de ser alvejada do que uma de 5 por exemplo, visto que com o número de funcionários, também aumenta o número de vetores possíveis para um ataque. Na sequência vamos para a maturidade de segurança que é um indicador do quanto as pessoas estão conscientes e os processos são robustos e confiáveis.

Quando falamos em capacidade de investimento é um tópico um pouco mais complexo no geral, porque depende diretamente da vontade dos controladores da organização e da verba total disponível para investimentos naquele período. Por fim chegamos a parte mais crítica de todas: necessidade do negócio, mas o que isso quer dizer?

Um banco por exemplo tem uma necessidade de segurança, que não está só atrelada à dificuldade de exploração das vulnerabilidades, mas também aos vetores que eles estão sujeitos, as proteções que eles tem, a ao que apresenta o maior risco para ele, já se olharmos uma varejista, os vetores são diferentes, os tipos de ataques são diferentes muitas vezes, e acima de tudo, o interesse de um ator de ameaça vai variar de forma drástica dependendo do setor industrial e da forma de atuação da organização.

Estabelecendo uma metodologia de DevSec

Agora que já entendemos o que é e o que considerar quando falamos de DevSec, vamos entrar em como estabelecer uma metodologia, essa é a parte mais difícil, visto a gama de alternativas de ferramentas e abordagens no mercado atualmente.

Uma das abordagens que se mostra mais bem sucedida no mercado atual é a priorização da necessidade real em detrimento de uma ferramenta pré-definida. Priorizar o entendimento do fluxo de desenvolvimento real do time de programadores permite aos profissionais que estão implementando o programa de DevSec.

Um dos maiores desafios dos times de segurança cibernética e da informação é o atrito com os outros setores, visto que muitas vezes para os devs os pedidos de segurança significam, muitas vezes, trabalho extra não previsto no cronograma inicial, que vem com demandas de variados níveis de complexidade e dificuldade e tradicionalmente como prioridade alta ou urgente. É compreensível o porque esse tipo de histórico não é produtivo para uma organização. Quando entramos em DevSec ainda tem a questão do ego dos devs, que sentem que estão dizendo a ele como fazer o trabalho dele, na gíria brasileira, ensinando o padre a rezar missa.

Para minimizar esse tipo de impacto a estratégia que vem mostrando o maior sucesso é inserir o profissional de DevSec junto dos desenvolvedores para que ele possa entender a real necessidade do time. E com base nisso a criação do fluxo de codificação segura é feita em conjunto, levando em consideração os pontos levantados por todos os envolvidos. Claro que é impossível chegar à um consenso absoluto sobre o fluxo a ser adotado, porém é de vital importância para o sucesso do projeto que o sentimento seja de trabalho em equipe entre todos os times, squads e unidades envolvidas.

Depois que a metodologia foi alinhada, entramos em detalhes mais técnicos que se relacionam com a maturidade da organização. O principal deles é Quality Gates.

Quality Gates

São critérios que agem como pontos de quebra da pipeline de desenvolvimento. Geralmente estão associados a quantidade e criticidade das vulnerabilidades encontradas no código. Os mesmos são tradicionalmente definidos como letras de A à F.

O quality gate a ser aplicado varia de acordo com a aplicação em particular que está sendo desenvolvida de forma direta. Por exemplo um sistema de transações bancárias tradicionalmente precisa de um A para ir para o deploy, já uma aplicação de biblioteca por exemplo pode ter um valor limitrofe C por exemplo. Cabe ressaltar que o valor real a ser definido como o limite de aceitação é relativo a aplicação, maturidade dos times de desenvolvimento e infraestrutura e do risco do negócio.

Lidando com conflitos entre os times

Quando estamos lidando com desenvolvimento seguro, sempre vão haver atritos entre desenvolvedores e profissionais de segurança. Muitos desses atritos serão por questão de tempo disponível para uma sprint, outros serão por divergências de entendimento do risco de uma vulnerabilidade. Para o sucesso do projeto e da organização é fundamental que ambos os times consigam dialogar e resolver os atritos de forma amistosa e entendam os pontos levantados pelo outro lado, o que embora seja raro é o principal elemento que leva ao sucesso das organizações que implementam um fluxo de devsec de forma adequada.

A comunicação aberta entre os times e demais stakeholders do projeto é a principal ferramenta para a resolução de tais conflitos. O bom planejamento também é importante para manter o entendimento do fluxo de trabalho, volume de demandas e ritmo das sprints para que seja feito o alinhamento de quando implementar as correções.

Que ferramenta usar?

Essa é possivelmente a pergunta que mais se faz quando se fala de código seguro, e infelizmente não existe uma resposta. Depende do cenário em que aquela organização está inserida, qual stack tecnológico ela usa, qual ferramenta de cloud, WAF, e outras estão implementadas já. Como funciona a pipeline, orçamento disponível, e o fluxo atual de desenvolvimento usado.

Não adianta recomendar uma ferramenta de 100 milhões de euros para uma empresa de médio porte

A escolha da ferramenta ideal é algo muito particular das necessidades da organização em si, e por isso seria leviano citar nomes nesse momento. Porém seguem alguns critérios que podem nortear o processo decisório.

Compatibilidade com o stack tecnológico;
Recursos disponíveis*;
Escalabilidade;
Custo operacional;
Disponibilidade de mão de obra;
Documentação;
Usabilidade.

*Por recursos disponíveis entende-se funcionalidades que a ferramenta oferece além do básico esperado de análise estática. Alguns exemplos são análises dinâmicas, análise de legibilidade do código, entre tantas outras opções.

Mas no final o peso de cada um desses fatores vai depender da necessidade do negócio e não existe fórmula pronta.

Métricas de sucesso

Outro ponto crucial para a gerência é como metrificar os resultados do projeto. Esse é um tópico um pouco delicado tendo em vista que a implementação de fluxos de desenvolvimento seguro é um projeto de longo prazo que perpassa diversos setores organizacionais. Porém as métricas utilizadas pela maioria dos projetos de alto impacto em organizações são:

Número de vulnerabilidades reportadas;
Tempo médio de mitigação/correção;
taxa de vulnerabilidades encontradas em tempo de codificação / produção;
Custo médio de correção por vulnerabilidade;
Nível de conformidade.

Essas métricas mostram tanto a efetividade do projeto, como o impacto financeiro do mesmo. A combinação de métricas técnicas e financeiras se faz útil, em especial quando olhamos para a alta gerência e c-level. O nível de conformidade é ainda mais importante em organizações de setores com regulamentação extra, como saúde e financeiro. Regulamentações como o PCI-DSS e a HIPAA, além das legislações padrão dos países como a LGPD e a GDPR que cobram um certo nível de conformidade regulamentar para que a operação possa continuar.

Considerações Finais

Foi falado sobre definições, metodologia, quality gates e algumas ferramentas que podem ser utilizadas, também abordamos alguns problemas mais comuns enfrentados pelos times de DevSec e de cyber security no geral. Mas no final o que define o sucesso de uma aplicação e sua segurança é a capacidade de dialogo e comunicação entre os times, bem como um fluxo robusto o suficiente para conseguir se encaixar na real necessidade.

E para isso também temos a necessidade de um programa de conscientização continuo e de treinamento de código seguro, bem como a implementação do máximo de verificações ainda durante a escrita do código. Por exemplo o SonarLint é uma ferramenta ligada ao SonarQube que pode ser instalada na maioria das IDEs e já notifica os desenvolvedores de código inseguro ou de baixa manutenibilidade enquanto ele está escrevendo. E isso é fundamental para a redução de custos, visto que de acordo com o GitLab, uma vulnerabilidade pode custar até 30 vezes mais para ser corrigida se for encontrada já em produção do que se fosse descoberta na fase de arquitetura ou escrita do código.

Com isso temos a principal filosofia ligada a segurança cibernética e da informação hoje, o SHIFT LEFT que consiste em focar o máximo dos controles de segurança o mais cedo possível no ciclo de vida da aplicação com o intuito de minimizar o retrabalho e com isso os custos de correção.

Desenvolvimento seguro é um dos fatores mais cruciais para a robustez de uma aplicação no cenário atual de milhões de ataques por ano, e nesse contexto a necessidade cada vez maior do alinhamento entre os times, dos treinamentos e da conscientização, dos programadores, dos líderes, gestores, e do staff de produto e vendas é um dos pilares de sustentação de qualquer organização moderna.

Todas essas boas práticas podem ser encontradas em soluções de ciber security de ponta, disponíveis para empresas de todos tamanhos. Quer entender melhor como aderir a essas tecnologias e evitar incidentes de segurança? clique aqui