Como começar com DevSecOps.
Seja bem-vindo ao nosso blog! Como começar com DevSecOps? Nos últimos posts, abordamos tópicos fundamentais como “Introdução ao DevSecOps” e “Arquitetura DevSecOps e Ferramentas“. Discutimos em detalhes o que é DevSecOps e como essa abordagem pode auxiliar no desenvolvimento de software com alta qualidade e segurança durante todo o ciclo de vida. Além disso, oferecemos uma visão geral sobre as possíveis arquiteturas e ferramentas para implementação eficaz do DevSecOps.
Vamos lá, o Pablo Marçal pediu para eu começar com o “COMO“, aqui estou eu tentando trazer insigths de onde e COMO começar sua jornada em DevSecOps, nada do que estou escrevendo aqui é “LEI”, é apenas um caminho para que possa se obter um bom conhecimento.
O que é SDL? SDL (Security Development Lifecycle).
O SDL, ou Ciclo de Vida de Desenvolvimento de Segurança, é uma metodologia que integra práticas de segurança em cada fase do desenvolvimento de software. Seu principal objetivo é garantir que a segurança seja considerada desde o início do projeto até a sua conclusão. As principais características do SDL incluem:
- Treinamento em Segurança: Nós capacitamos os desenvolvedores e equipes com conhecimento sobre práticas seguras de codificação.
- Definição de Requisitos de Segurança: Estabelecemos critérios de segurança que o software deve atender.
- Design Seguro: Incorporamos padrões de design que mitigam riscos de segurança.
- Implementação Segura: Utilizamos práticas seguras de codificação para reduzir vulnerabilidades.
- Testes de Segurança: Realizamos testes específicos para identificar e corrigir falhas de segurança.
- Resposta a Incidentes: Preparamos planos de ação para lidar com potenciais incidentes de segurança após a implementação do software.
Com o SDL, garantimos que a segurança seja uma prioridade durante todo o ciclo de vida do desenvolvimento de software. Dessa forma, entregamos produtos mais robustos e protegidos contra ameaças.
A Microsoft criou o Security Development Lifecycle (SDL). Em 2002, após enfrentar várias falhas de segurança em seus produtos, a empresa decidiu reavaliar e aprimorar suas práticas de desenvolvimento de software. Assim, começou o desenvolvimento do SDL. Em 2004, a Microsoft formalmente introduziu o SDL como um processo de engenharia de segurança integrado ao desenvolvimento de software. Com o SDL, a empresa buscava reduzir vulnerabilidades de segurança, melhorar a segurança do software e garantir que a segurança fosse considerada em todas as fases do desenvolvimento.
Por que é importante conhecer OWASP Top 10?
O OWASP Top 10 é uma lista das dez principais vulnerabilidades de segurança em aplicativos web, criada pela Open Web Application Security Project (OWASP). Essa lista é amplamente reconhecida e utilizada como um padrão de referência para desenvolvedores e equipes de segurança na identificação e mitigação de riscos em aplicações web. Vamos explorar as vulnerabilidades mais recentes incluídas no OWASP Top 10:
-
Injeção: Ataques de injeção, como SQL, NoSQL, OS e LDAP, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta.
-
Falhas de Autenticação: Essas vulnerabilidades permitem que atacantes assumam a identidade de outros usuários, temporariamente ou permanentemente.
-
Exposição de Dados Sensíveis: Essas falhas resultam na exposição de dados sensíveis a usuários não autorizados.
-
Entidades Externas XML (XXE): Ataques contra processadores XML que avaliam referências a entidades externas dentro de documentos XML.
-
Quebra de Controle de Acesso: Essas falhas permitem que usuários não autorizados acessem dados ou funcionalidades além de seus privilégios permitidos.
-
Configurações Incorretas de Segurança: Problemas que resultam de configurações incorretas ou não seguras em servidores, bancos de dados ou aplicações.
-
Cross-Site Scripting (XSS): Essas vulnerabilidades permitem que atacantes injetem scripts maliciosos em páginas vistas por outros usuários.
-
Desserialização Insegura: Problemas que ocorrem quando dados não confiáveis são usados para desserializar objetos.
-
Uso de Componentes com Vulnerabilidades Conhecidas: Utilização de bibliotecas, frameworks e outros componentes com falhas conhecidas.
-
Registro e Monitoramento Insuficientes: Falta de registro adequado e monitoramento de atividades, dificultando a detecção de ataques e respostas rápidas a incidentes.
Essas vulnerabilidades representam os riscos mais críticos e comuns encontrados em aplicativos web. Compreender e mitigar esses riscos é essencial para o desenvolvimento de aplicativos seguros e robustos. Ao seguir as diretrizes do OWASP Top 10, você pode melhorar significativamente a segurança de suas aplicações e proteger melhor os dados dos usuários.
Se APIs são tendência para 2024, preciso conhecer OWASP API Security Top 10.
A lista OWASP API Security Top 10 identifica as principais vulnerabilidades de segurança encontradas em APIs (Interfaces de Programação de Aplicações). Criada pela Open Web Application Security Project (OWASP), essa lista é um guia essencial para desenvolvedores e equipes de segurança. Vamos explorar as vulnerabilidades mais recentes incluídas no OWASP API Security Top 10:
-
Autorização Quebrada em Nível de Objeto: Essa vulnerabilidade ocorre quando as APIs não verificam corretamente se um usuário está autorizado a acessar um objeto específico. Como resultado, usuários mal-intencionados podem acessar dados de outros usuários.
-
Autenticação Quebrada: Falhas na implementação de autenticação permitem que atacantes comprometam tokens de autenticação ou explorem outros erros de implementação para assumir a identidade de outros usuários, temporariamente ou permanentemente.
-
Exposição Excessiva de Dados: APIs que retornam mais dados do que o necessário expõem informações sensíveis. Portanto, os desenvolvedores devem filtrar os dados e expor apenas o que é necessário.
-
Falta de Recursos e Limitação de Taxa: A ausência de limites no número de chamadas que um cliente pode fazer à API pode levar ao esgotamento dos recursos do servidor, facilitando ataques de negação de serviço (DoS).
-
Autorização Quebrada em Nível de Função: Falhas que permitem que usuários sem privilégios adequados acessem funcionalidades administrativas ou de outros níveis de acesso.
-
Atribuição em Massa: Quando desenvolvedores expõem todos os parâmetros de objeto sem filtrar campos que não devem ser modificados pelo cliente, podem ocorrer ataques de atribuição em massa.
-
Configuração de Segurança Incorreta: Configurações incorretas ou inseguras em servidores, serviços ou configurações padrão podem ser exploradas para obter acesso não autorizado ou expor dados.
-
Injeção: Ataques de injeção, como SQL, NoSQL e LDAP, ocorrem quando dados não confiáveis são enviados para um interpretador como parte de um comando ou consulta. Isso permite que atacantes executem comandos arbitrários.
-
Gerenciamento Impróprio de Ativos: A falta de gerenciamento adequado de inventário de APIs, incluindo versões antigas e não documentadas, pode expor a aplicação a riscos.
-
Registro e Monitoramento Insuficientes: A falta de registro adequado e monitoramento das atividades das APIs dificulta a detecção e resposta a ataques, permitindo que invasões permaneçam sem ser detectadas por longos períodos.
Compreender e mitigar essas vulnerabilidades é crucial para garantir a segurança das APIs. Ao seguir as diretrizes do OWASP API Security Top 10, você fortalece significativamente a segurança de suas interfaces de programação de aplicações e protege os dados dos usuários de maneira mais eficaz.
Trabalho com Dados, Inteligência Artificial ou Segurança da informação?
É importante que você conheça OWASP Top 10 para Modelos de Linguagem de Grande Escala (LLM).
Os Modelos de Linguagem de Grande Escala (LLMs) apresentam novas e únicas vulnerabilidades de segurança. A OWASP, reconhecida por suas diretrizes de segurança para aplicações web, também propôs uma lista focada na segurança dos LLMs. Vamos explorar as vulnerabilidades mais recentes incluídas no OWASP Top 10 para LLMs:
-
Injeção de Prompt: A injeção de prompt ocorre quando um atacante manipula a entrada para alterar o comportamento do LLM, resultando em saídas indesejadas ou potencialmente prejudiciais.
-
Exposição de Dados Sensíveis: LLMs treinados com dados confidenciais podem inadvertidamente expor essas informações quando solicitados. É crucial filtrar e gerenciar adequadamente os dados usados no treinamento.
-
Alucinações: LLMs podem gerar informações falsas ou enganosas que parecem plausíveis. Garantir a precisão das respostas é um desafio contínuo.
-
Resposta Tendenciosa: Modelos podem refletir preconceitos presentes nos dados de treinamento, resultando em respostas discriminatórias ou injustas. A mitigação desses vieses é essencial.
-
Falha na Autenticação e Autorização: Quando LLMs são integrados a sistemas críticos, falhas na autenticação e autorização podem permitir acesso não autorizado a dados sensíveis ou funcionalidades importantes.
-
Falta de Limitação de Taxa e Abuso de Recursos: Sem limitação adequada, LLMs podem ser explorados por atacantes para esgotar recursos do sistema, causando degradação de serviços ou interrupções.
-
Configuração de Segurança Incorreta: Configurações inadequadas ou inseguras no ambiente onde o LLM opera podem ser exploradas por atacantes para comprometer o sistema.
-
Manipulação de Entrada e Saída: Ataques que exploram a falta de validação e sanitização de entradas e saídas podem causar comportamentos indesejados ou comprometer a integridade do sistema.
-
Desempenho e Confiabilidade: Vulnerabilidades que afetam o desempenho e a confiabilidade do LLM podem levar a respostas lentas, falhas ou comportamentos inconsistentes.
-
Registro e Monitoramento Insuficientes: A falta de registro e monitoramento adequados dificulta a detecção de atividades maliciosas e a resposta a incidentes, permitindo que ataques passem despercebidos por longos períodos.
Compreender e mitigar essas vulnerabilidades é crucial para garantir a segurança e a integridade dos LLMs. Ao seguir as diretrizes do OWASP Top 10 para LLMs, você pode fortalecer a segurança de seus modelos de linguagem e proteger melhor os dados e usuários.
OWASP SAMM (Software Assurance Maturity Model)
Nosso objetivo é fornecer uma maneira eficaz e mensurável para que você possa analisar e melhorar seu ciclo de vida de desenvolvimento seguro. O SAMM (Software Assurance Maturity Model) apoia todo o ciclo de vida do software e é independente de tecnologia e processos. Desenvolvemos o SAMM para ser evolutivo e orientado por riscos, pois não existe uma única receita que funcione para todas as organizações.
Como o SAMM Funciona?
1. Avaliação da Maturidade:
- Você pode usar o SAMM para avaliar o nível atual de maturidade das suas práticas de segurança de software.
- O modelo oferece uma estrutura clara para identificar áreas de melhoria.
2. Planejamento de Melhoria:
- Com base na avaliação, você pode planejar melhorias específicas para aumentar a maturidade da segurança em diferentes áreas.
- O SAMM fornece orientações práticas sobre como evoluir de um nível de maturidade para outro.
3. Implementação de Práticas Seguras:
- O SAMM cobre todas as fases do ciclo de vida do software, desde o planejamento e design até a implementação e verificação.
- Você pode integrar práticas de segurança em cada fase para garantir um desenvolvimento seguro.
Evolução Contínua:
- O SAMM é projetado para ser adaptável, permitindo que você ajuste suas práticas de segurança conforme novas ameaças surgem e sua organização evolui.
- A abordagem orientada por riscos ajuda a focar nos aspectos mais críticos para a segurança do seu software.
Benefícios do SAMM.
- Independência de Tecnologia: Você pode aplicar o SAMM independentemente das tecnologias ou processos específicos que sua organização utiliza.
- Flexibilidade e Adaptabilidade: O SAMM é evolutivo, permitindo ajustes contínuos e melhorias baseadas em riscos específicos.
- Orientação Prática: O modelo fornece orientações práticas que você pode implementar diretamente em suas operações de desenvolvimento.
- Medição e Melhoria: Você pode medir a eficácia das suas práticas de segurança e planejar melhorias contínuas para aumentar a maturidade.
Por que Escolher o SAMM?
O SAMM é uma ferramenta poderosa para qualquer organização que busca melhorar suas práticas de desenvolvimento seguro. Seja você uma pequena startup ou uma grande corporação, o SAMM oferece uma abordagem estruturada e orientada por riscos para garantir a segurança do software. Ao adotar o SAMM, você assegura que a segurança seja uma prioridade contínua e evolutiva no seu ciclo de vida de desenvolvimento de software.
OWASP DSOMM (DevSecOps Maturity Model)
De startups a corporações multinacionais, a indústria de desenvolvimento de software atualmente é dominada por frameworks ágeis, equipes de produto e estratégias DevOps. No entanto, durante a implementação, os aspectos de segurança muitas vezes são negligenciados ou não recebem a devida atenção. Frequentemente, os requisitos de segurança padrão do ambiente de produção não são aplicados ao pipeline de build no ambiente de integração contínua, especialmente com o uso de containers como o Docker. Como resultado, o registro do Docker frequentemente não é seguro, o que pode levar ao roubo de todo o código-fonte da empresa.
O Papel do DevSecOps Maturity Model
O DevSecOps Maturity Model, apresentado na nossa palestra, demonstra as medidas de segurança aplicadas ao usar estratégias DevOps e como essas medidas podem ser priorizadas. Com a ajuda das estratégias DevOps, também é possível melhorar a segurança. Por exemplo, cada componente, como bibliotecas de aplicativos e bibliotecas do sistema operacional em imagens Docker, pode ser testado para vulnerabilidades conhecidas.
Melhorando a Segurança com DevSecOps
Os atacantes são inteligentes e criativos, equipados com novas tecnologias e objetivos específicos. Sob a orientação do DevSecOps Maturity Model, você pode implementar princípios e medidas apropriadas que contrariam esses ataques. Algumas práticas recomendadas incluem:
1. Testes de Vulnerabilidade:
- Aplicação e Bibliotecas: Teste todas as bibliotecas de aplicação e sistema operacional para vulnerabilidades conhecidas. Ferramentas como Snyk e Clair podem ser integradas ao pipeline de CI/CD para realizar essas verificações automaticamente.
2. Segurança do Registro Docker:
- Acesso Restrito: Configure políticas de acesso restritas para o registro Docker, garantindo que apenas usuários autorizados possam acessar e modificar imagens.
- Varredura de Imagens: Implemente a varredura automática de imagens para detectar e remediar vulnerabilidades antes da implantação.
3. Automatização da Segurança:
- Integração Contínua: Adicione verificações de segurança ao seu pipeline de integração contínua (CI). Ferramentas de análise estática (SAST) e análise dinâmica (DAST) ajudam a identificar vulnerabilidades no código durante o desenvolvimento.
- Entrega Contínua: Garantir que todas as etapas da entrega contínua (CD) incluam verificações de conformidade e segurança para manter a integridade do código e da infraestrutura.
4. Cultura de Segurança:
- Educação e Treinamento: Proporcione treinamento contínuo em segurança para desenvolvedores, engenheiros de DevOps e equipes de operações. Uma cultura de segurança começa com a conscientização e o conhecimento.
- Colaboração entre Equipes: Fomente a colaboração entre as equipes de desenvolvimento, segurança e operações para garantir que todos estejam alinhados nos objetivos de segurança.
OWASP DevSecOps Guideline
A OWASP DevSecOps Guideline explica como implementar um pipeline seguro, usar as melhores práticas e introduzir ferramentas que podem ajudar nesse processo. O projeto também promove a cultura de segurança shift-left em nosso processo de desenvolvimento. Esta iniciativa ajuda empresas de todos os tamanhos que possuem um pipeline de desenvolvimento, ou seja, um pipeline DevOps. Nosso objetivo é criar uma perspectiva de um pipeline DevOps seguro e, em seguida, melhorá-lo com base em nossos requisitos personalizados.
Objetivo Ideal: Detecção Rápida de Problemas de Segurança
Nosso objetivo principal é “detectar problemas de segurança (seja por design ou vulnerabilidade da aplicação) o mais rápido possível.”
Implementando um Pipeline Seguro com a OWASP DevSecOps Guideline
1. Integração de Ferramentas de Segurança
Para começar, integramos ferramentas de segurança em cada estágio do pipeline de CI/CD. Estas ferramentas ajudam a identificar vulnerabilidades antes que elas cheguem à produção. Algumas ferramentas recomendadas incluem:
- SAST (Static Application Security Testing): Ferramentas como SonarQube ou Checkmarx analisam o código-fonte para detectar vulnerabilidades durante a fase de desenvolvimento.
- DAST (Dynamic Application Security Testing): Ferramentas como OWASP ZAP ou Burp Suite testam a aplicação em execução para encontrar vulnerabilidades.
- SCA (Software Composition Analysis): Ferramentas como Dependabot ou Snyk verificam bibliotecas e dependências para vulnerabilidades conhecidas.
2. Automatização de Verificações de Segurança
Automatizar as verificações de segurança no pipeline de CI/CD é crucial. Isso garante que cada alteração de código seja analisada para problemas de segurança antes da integração. Aqui estão algumas práticas recomendadas:
- Integração Contínua (CI): Configure pipelines que executam verificações de segurança automaticamente a cada commit.
- Entrega Contínua (CD): Assegure-se de que as verificações de segurança sejam uma etapa obrigatória antes da implantação em produção.
3. Promovendo a Cultura Shift-Left
A cultura shift-left significa incorporar práticas de segurança desde o início do ciclo de desenvolvimento. Para promover essa cultura:
- Educação e Treinamento: Proporcione treinamentos regulares para desenvolvedores e equipes de operações sobre práticas de segurança.
- Revisões de Código: Realize revisões de código focadas em segurança regularmente, incentivando os desenvolvedores a identificar e corrigir vulnerabilidades.
4. Monitoramento Contínuo e Feedback
Implemente monitoramento contínuo para detectar e responder rapidamente a incidentes de segurança. Utilize ferramentas de logging e monitoramento para manter a visibilidade sobre a segurança da aplicação em produção.
- Monitoramento de Logs: Ferramentas como ELK Stack (Elasticsearch, Logstash, Kibana) ajudam a monitorar logs e identificar padrões suspeitos.
- Alertas e Notificações: Configure alertas automáticos para notificar a equipe de segurança sobre atividades suspeitas ou anomalias.
Se eu tivesse começando hoje com DevSecOps: Um Guia Prático.
Para começar a implementar DevSecOps de forma eficaz e evitar problemas com a equipe de desenvolvimento, é essencial seguir uma abordagem estruturada.
1. Implementar SCA (Software Composition Analysis)
Por que começar aqui? SCA é fácil de implementar e oferece benefícios imediatos ao identificar vulnerabilidades em bibliotecas e dependências de terceiros, comuns em muitos projetos.
Ações práticas:
- Integre Ferramentas SCA: Utilize ferramentas como Dependabot, Snyk ou OWASP Dependency-Check no pipeline de CI/CD.
- Proporcione Treinamento Básico: Ensine os desenvolvedores a resolver vulnerabilidades nas dependências.
2. Adotar SAST (Static Application Security Testing)
Por que isso é essencial? SAST identifica vulnerabilidades no código-fonte sem precisar de execução. Assim, você pode detectar problemas de segurança antes da implantação.
Ações práticas:
- Configure Ferramentas SAST: Use ferramentas como SonarQube, Checkmarx ou Fortify.
- Integre no CI/CD: Adicione a verificação SAST no pipeline de integração contínua para analisar cada commit.
- Treine os Desenvolvedores: Ensine-os a interpretar os resultados e corrigir problemas.
3. Implementar IaC Scanning (Scanning Terraform, HelmChart)
Por que isso é importante? Com a infraestrutura como código (IaC), garantir que os arquivos de configuração estejam seguros é crucial para a segurança da infraestrutura.
Ações práticas:
- Utilize Ferramentas IaC: Ferramentas como Checkov, TFLint ou Kics ajudam a escanear arquivos IaC.
- Automatize as Verificações: Adicione verificações de IaC no pipeline de CI/CD.
- Crie Guias de Melhores Práticas: Distribua guias para escrever código IaC seguro.
4. Introduzir DAST (Dynamic Application Security Testing)
Por que agora? DAST testa a aplicação em execução e identifica vulnerabilidades que SAST ou SCA não detectam.
Ações práticas:
- Implemente Ferramentas DAST: Use ferramentas como OWASP ZAP, Burp Suite ou AppScan.
- Configure Ambientes de Teste: Realize testes DAST em ambientes de teste para não afetar a produção.
- Automatize os Testes: Adicione verificações DAST no pipeline de CI/CD.
5. Realizar Infrastructure Scanning
Por que isso é crucial? Garantir que a infraestrutura subjacente esteja segura é tão importante quanto a segurança do código.
Ações práticas:
- Utilize Ferramentas de Varredura: Ferramentas como Nessus, OpenVAS ou Qualys escaneiam servidores e redes.
- Automatize Relatórios: Gere relatórios automaticamente e execute ações corretivas baseadas nas vulnerabilidades encontradas.
6. Fazer Compliance Check
Por que nesta fase? Após garantir a segurança da aplicação e da infraestrutura, verificar a conformidade com normas é o próximo passo lógico.
Ações práticas:
- Use Ferramentas de Compliance: Ferramentas como Chef InSpec, OpenSCAP ou AWS Config ajudam na verificação de conformidade.
- Integre Verificações de Compliance: Adicione estas verificações no pipeline de CI/CD.
7. Implementar IAST (Interactive Application Security Testing)
Por que por último? IAST oferece uma análise contínua e detalhada durante a execução da aplicação. No entanto, pode ser mais complexo e requer ajustes finos.
Ações práticas:
- Utilize Ferramentas IAST: Ferramentas como Contrast Security, Hdiv Security ou Veracode são úteis.
- Teste em Ambiente Controlado: Ajuste as configurações para minimizar interrupções.
- Proporcione Treinamento Avançado: Ensine desenvolvedores e engenheiros de segurança a usar e interpretar os resultados do IAST.
Seguindo esses passos, você garante uma implementação suave de práticas de DevSecOps, minimizando interrupções e maximizando a segurança desde o início.
Fonte:
https://www.microsoft.com/en-us/securityengineering/sdl
https://owasp.org/Top10/pt_BR/
https://owasp.org/API-Security/editions/2023/en/0x11-t10/
https://owasp.org/www-project-top-10-for-large-language-model-applications/
https://owasp.org/www-project-samm/
https://owasp.org/www-project-devsecops-maturity-model/
https://owasp.org/www-project-devsecops-guideline/
Sugestão de livros:
Sugestão de treinamento:
4Linux – DevSecOps segurança Ágil em pipelines CI/CD e DevOps
Pratical DevSecOps – Certified DevSecOps Professional
[];
Atualmente atua como Architecture Manager pela Atos Brasil, entusiasta Microsoft, FreeBSD e Debian, com mais de 20 anos de experiência em infraestrutura de T.I com ambientes heterogêneos, possuí o título de Microsoft Certified Trainer, AWS Community Builder, FinOps Member Foundation, Membro do comitê público do IDCIBER e especialista em segurança de perímetro, tendo atuado com soluções como Isa Server, iptables, IPFW, Cisco ASA, SonicWall, Fortigate, pfSense e soluções de Web Application Firewall.