Antes de explicarmos sobre DevSecOps Assessment, vamos relembrar o que é DevSecOps: uma abordagem de desenvolvimento de sistemas que integra segurança desde o início do processo de desenvolvimento (também conhecido como Secure Shift Left).
Essa abordagem é uma evolução do DevOps, que enfatiza a colaboração entre pessoas desenvolvedoras e a operação de sistemas para criar um fluxo de trabalho contínuo, eficiente e ágil.
Neste artigo, vamos nos aprofundar no tema e relembrar conceitos importantes relacionados à segurança da informação! Acompanhe:
DevOps e segurança
No livro DevSecOps de Glenn Wilson, ao explicar o DevOps para introduzir o SEC, o autor ressalta sobre três princípios fundamentais:
- Fluxo do processo da esquerda para direita: o foco está na entrega de requisitos em versões de baixo risco, incorporando testes automatizados e CI no pipeline de implantação;
- Mecanismo de feedback da direita para a esquerda: permite às pessoas engenheiras desenvolvedoras que antecipem problemas em vez de esperar que impasses ocorram no ambiente de produção;
- Fornecer um ambiente para aprendizado e experimentação contínuos: possibilita que profissionais de engenharia melhorem continuamente o desenvolvimento e as operações como parte incorporada do processo.
O DevSecOps, por sua vez, inclui a segurança em todo esse processo, desde o planejamento até a implantação, para garantir que a segurança esteja presente em cada etapa do ciclo de vida do sistema e promover o SSDLC, sigla em inglês que se refere a Secure System Development Life Cycle.
Seria como se, como vimos acima, usássemos os conhecimentos já adquiridos do processo de DevOps e acrescentássemos os processo de segurança de forma natural.
Desafios do DevSecOps nos times de Engenharia
A partir dessas informações, vamos lembrar que a integração de segurança no processo de desenvolvimento de sistemas não é uma tarefa fácil. É por isso que as organizações precisam realizar avaliações de segurança para garantir que seus processos de desenvolvimento estejam protegidos contra vulnerabilidades e ameaças cibernéticas.
Falar sobre isso é mais que necessário, porque cada dia mais as empresas se encontram vulneráveis aos ataques de hackers maliciosos, com mais ousadia e sofisticação. Ao mesmo tempo em que atacantes se especializam em tecnologias, devs criam códigos ininterruptamente e sem incluir a porção “segurança” no fluxo dinâmico de entrega contínua.
O desafio é fazer um DevSecOps sem impactar na experiência de pessoas desenvolvedoras (DevEx), ou seja, altamente relevante, com alto valor agregado, mas que não exija um desvio do seu dia a dia grande o suficiente para abortar o processo ou perder algum elemento fundamental, como a aprendizagem contínua.
Continue mergulhando nesse universo de DevSecOps! Temos um vídeo completo sobre o tema no nosso canal do YouTube. Assista:
DevSecOps Assessment
A jornada de segurança do AppSec foi criar um DevSecOps Assessment que é uma avaliação sistemática do processo, para desenvolver, testar e implantar sistemas.
O objetivo dessa avaliação é identificar e corrigir quaisquer vulnerabilidades de segurança que possam existir no desenvolvimento de sistemas, inclusive ajustar procedimentos para atender legislação e regulamentações dispostas dentro das organizações.
Utilizamos de todos os recursos disponíveis para que a adoção da prática seja uma realidade em todos os times, desde pessoas com capacitação para doutrinar sobre segurança, os chamados Security Champions – que, além disso, ditam a escalabilidade da segurança dentro dos times de engenharia, sendo o ponto focal do AppSec, até criação de conteúdos, vídeos curtos com boas práticas, dicas de capacitação adicional, etc.
Mais uma vez citando Glenn Wilson, o autor referencia as 3 camadas do DevSecOps em seu livro. Essas camadas são os alicerces sobre as quais os processos devem ser construídos:
A avaliação de segurança do DevSecOps Assessment é composta por várias etapas, cada uma tem um objetivo específico. A seguir, descrevo as principais etapas do processo shift-left que usamos aqui:
1- Planejamento
Inicialmente, a equipe de AppSec conhece o escopo da solução por meio do entendimento com o time de arquitetura e engenharia do projeto. O objetivo é obter o que será construído em alto nível e conhecer o roadmap para criar as agendas de colaboração.
2- Coleta de informações
Nesta fase, inicia-se o mapeamento dos ambientes e aplicações que estarão envolvidos na elaboração do produto, com profundidade, utilizando uma checklist padronizada para as aplicações e ambientes. Basicamente, serão apurados os dados sobre a construção da arquitetura, técnicas de desenvolvimento, linguagens e adoção de padrões de segurança.
A modelagem de ameaças (Threat Modeling) é um processo importante que ajuda a garantir a segurança de um sistema de computador. Ela envolve uma análise cuidadosa dos possíveis riscos e ameaças que podem afetar a aplicação em questão.
Para fazer isso, é necessário considerar vários fatores, como a importância do sistema, a forma como ele foi projetado, a sensibilidade dos dados armazenados, as tecnologias utilizadas e a probabilidade de um ataque cibernético.
O objetivo é que a Modelagem de Ameaças seja acatada pelo time de projeto do sistema e as recomendações sejam aceitas e incorporadas ao desenvolvimento.
3- Automação do Pipeline
Com os dados sobre a aplicação coletados na etapa anterior, o time de AppSec inicia a implantação do workflow automatizado na esteira de desenvolvimento de sistemas.
O workflow contém as ferramentas de segurança que serão implantadas no repositório das aplicações para que o serviço seja ativado e os scans das ferramentas de segurança comecem a rodar nos códigos das aplicações, conforme for elaborando os códigos e liberando nos ambientes anteriormente mapeados pelo AppSec, devidamente configurados na automação.
4- Identificação de vulnerabilidades
O AppSec recebe os registros das vulnerabilidades escaneadas pelo workflow e inicia a etapa de análise dos resultados, eliminando os “Falso-Positivos” que, eventualmente poderão surgir como suscetibilidade.
Após esse processo, a pessoa desenvolvedora deverá iniciar a análise das vulnerabilidades do código para abrir as “issues” na ferramenta de gestão de vulnerabilidade. Esse é o momento onde se tem conhecimento sobre o risco e o prazo de solução (SLA) da vulnerabilidade.
Aqui é importante ressaltar que tanto o risco quanto o SLA devem estar aderentes às políticas estabelecidas na organização. Todas as ferramentas de aferição de segurança passam por processo de auditoria recorrentes, de acordo com a natureza do produto em construção e as regras vigentes.
Um exemplo disso é o sistema de transação financeira, empréstimo, cartões e investimentos, que lidam com grande volume de dados sigilosos e sensíveis, que são alvos de órgãos como PCI/DSS, BACEN e Sarbanes-Oxley.
Além de ter um critério específico para esse tipo de construção de código, existem também certas prioridades do negócio para atendimento das correções das vulnerabilidades. Dessa forma, se pendentes, poderão impactar na recertificação de algum destes órgãos.
5- Recomendações e correções
Nesta fase, o AppSec e/ou o Security Champion fornece recomendações sobre como corrigir as vulnerabilidades identificadas e melhorar a segurança do processo de desenvolvimento de sistemas. Isso pode incluir mudanças no processo ou a introdução de novas técnicas de desenvolvimento e/ou a adoção de novos padrões de segurança (boas práticas).
6- Indicadores
Todo processo de SSDLC é medido ao longo do workflow, quantitativamente e qualitativamente. Os números são coletados dos resultados das ações dos scans de código e se baseiam, resumidamente, em:
- Quantidade de vulnerabilidade identificada;
- Quantidade de vulnerabilidade corrigida;
- Quantidade de Falso Positivo.
Na visão qualitativa, temos implementado: quantidade de vulnerabilidades por aplicação, por categoria e por criticidade. Também é possível obter números de lead time das equipes de desenvolvimento na análise e correção, bem como o SLA dos ajustes, com dados que podem ou não impactar a análise de risco para tomada de decisão do negócio.
7- Relatório
O time AppSec prepara um relatório com o resultado completo (end-to-end), incluindo as vulnerabilidades identificadas e as recomendações para corrigi-las, bem como as que já foram sanadas de forma cíclica.
Esse relatório é compartilhado com a equipe de desenvolvimento de sistema e outras partes interessadas para garantir que as vulnerabilidades sejam priorizadas para correção. Além disso, que as recomendações sejam absorvidas para evitar reincidência.
Resumo do Workflow DevSecOps Assessment
Para exemplificar, criamos um elo entre o diagrama. Ele é utilizado para demonstrar a integração de DevSecOps (figura abaixo) e o workflow que nos referimos neste artigo utilizado na Zup. As etapas estão dispostas do seguinte modo:
- 1 e 2 executadas na fase de PLAN;
- 3, 4 e 5 executados nas fases de CODE e BUILD;
- 6 e 7 executados na fase de TEST.
Ferramentas de automação do SSDLC
Para executar os scans de segurança no código, utilizamos um conjunto de ferramentas automatizadas e integradas a um repositório para gerir as vulnerabilidades.
No entanto, este artigo não tem como objetivo entrar no detalhe de cada ferramenta. Porém, vou fazer uma breve descrição dos serviços que utilizamos, ou melhor, quais tipos de testes que são executados no pipeline por meio do workflow:
- SAST – Teste de segurança de análise estática;
- Análise de Dependência – Análise dos componentes desatualizados do código;
- Análise de Segredos – Análise do uso de chaves e segredos expostos;
- IAC – Análise de Infra as a Code.
Conclusão
Neste artigo, relembramos conceitos importantes dentro da segurança da informação, como: DevOps e DevSecOps. Além disso, você conheceu as etapas de avaliação do DevSecOps Assessment, a pipeline de segurança do AppSec utilizando o conceito de DevOps
Por fim, esperamos que tenha gostado do conteúdo e que possa facilitar o seu dia a dia e do seu time. Comente abaixo o que achou e quais boas práticas você utiliza para jornadas de segurança ainda melhores.
