Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ? 
DevSecOps – Uma nova chance para segurança
Saiba mais sobre o DevSecOps e por que ele tem o potencial de transformar a maneira como protegemos nossos aplicativos.
Eu estava navegando recentemente pelas 20 mais recentes arquiteturas de referência DevSecOps para este ano e fiquei impressionado com várias coisas: cada uma tem vários elementos compartilhados, e as habilidades de PowerPoint dos diferentes autores variaram muito.
Ainda mais do que habilidades em PowerPoint, fiquei impressionado com o fato de que, assim como o DevOps mudou fundamentalmente nossos métodos de produção de aplicativos, o DevSecOps tem o mesmo potencial para transformar a maneira como protegemos os aplicativos. Resumindo, DevSecOps é realmente uma nova chance para segurança.
Isso me encorajou a tentar estabelecer minha própria filosofia DevSecOps e arquitetura de referência.
Minha filosofia DevSecOps é baseada inteiramente no pipeline CI / CD.
Existem três componentes fundamentais que devemos proteger:
O código e o aplicativo conforme ele se move pelo pipeline,
As ferramentas que compõem o pipeline e
O ambiente no qual o pipeline reside.
O problema
Há um pequeno problema aqui. A maioria dos profissionais de segurança não codifica. Da mesma forma, a maioria dos desenvolvedores de software sabe muito pouco sobre segurança. Como podemos efetivamente alinhar esses dois campos?
Ponte
Parte da solução é avançar para testes automatizados. O teste automatizado se concentra em ferramentas e a arquitetura de ferramentas é relativamente fácil.
A segunda abordagem, mais difícil, dolorosa e recompensadora, é mudar a maneira como pensamos sobre segurança – para parar a maneira como atualmente testamos e para reavaliar e reestruturar completamente nossa metodologia de testes de segurança.
É difícil e doloroso porque nós – particularmente em segurança – seguimos os mesmos padrões por várias décadas, e a mudança é difícil. Vários colegas admitiram para mim que “simplesmente não entendem”.
No entanto, essas mesmas pessoas compreendem o fato de que nossas práticas de segurança atuais falharam repetida e comprovadamente na proteção de ativos digitais críticos.
Conforme evidenciado pela monotonia diária de violações de dados bem-sucedidas e ataques cibernéticos.
A mentalidade “Shift-Left / Test Everywhere” é potencialmente gratificante porque representa uma mudança profunda em nossa abordagem para garantir ativos digitais. E é claro que precisamos mudar, dada a falta de sucesso das abordagens tradicionais.
Vamos começar com um pipeline de desenvolvimento genérico. O código entra à esquerda e um aplicativo sai à direita. Aqui está um exemplo de um pipeline de desenvolvimento.
Os testes de segurança de aplicativos quase sempre favoreceram o lado direito, ou implantar, do pipeline de desenvolvimento.
Qualquer pessoa que use software sabe que essa abordagem leva a um software com bugs.
Os defeitos de segurança são caros, mas a eliminação desses defeitos também é cara, especialmente quando os defeitos são descobertos no final ou no lado direito do ciclo de implantação.
O conceito de “deslocar a segurança para a esquerda” no pipeline de desenvolvimento deriva da noção “Test Early, Test Frequently”.
E qual é o resultado de todos esses testes? Código perfeito? Aplicativos que estão livres de vulnerabilidades? Dificilmente.
O teste de software / segurança não garante que o software esteja livre de bugs; em vez disso, os resultados dos testes são um meio de fornecer uma estimativa da qualidade do software às partes interessadas em vários níveis.
Uma solução proposta
Em quase todos os esforços de DevOps dos quais participei, a empolgação inicial de “Tornar-se Ágil” levou a uma expansão quase instantânea.
Repositórios do GitHub, instâncias do EC2, GCE e WVM, contêineres, novas ferramentas e orquestradores aparecem como narcisos.
Geralmente, há algum método para tudo isso, mas de acordo com as tendências históricas, as preocupações de segurança geralmente são deixadas na poeira.
Pode até haver um mandato para utilizar muitos serviços de monitoramento e segurança nativos do AWS / Azure / Google, mas para agir rapidamente aceitamos que não há problema em deixar nossa chave privada em um bastionhost para que desenvolvedores e administradores preguiçosos não precisa aprender como encadear solicitações SSH.
O maior impedimento para testes onipresentes não são ferramentas ou processos necessariamente.
Está mudando a forma como as pessoas pensam sobre seu trabalho. De acordo com o relatório do Forrester State of Agile (2017), a mudança comportamental é o maior obstáculo para acertar isso.
Agile e Lean exigem novos papéis, novos tipos de trabalhos, novas formas de trabalho e maior colaboração e comunicação.
Os gerentes devem se livrar de anos de gerenciamento direto de grandes equipes em favor de se tornarem líderes-servos. Sim, servir. Orientar, discutir, lembrem-se de como era na época de especialistas ou analistas.
A mudança de comportamento é o principal impedimento para a mudança organizacional, citada por mais da metade dos entrevistados.
Como promovemos mudanças comportamentais?
É difícil – particularmente em grandes organizações, e é complexo o suficiente para deixar de lado por enquanto e focar em algo que podemos mudar na maioria das organizações – testando estratégias e ferramentas.
Onde no pipeline nós testamos? Em todo o pipeline
Teste em todos os lugares
Se formos inteligentes, podemos tirar proveito de ferramentas – particularmente quando testes de segurança estática – que não foram especificamente projetados para serem ferramentas de análise de segurança.
Por exemplo, até mesmo algo tão simples quanto um teste de unidade pode ser usado potencialmente para impedir práticas inseguras de codificação que eventualmente resultariam em uma vulnerabilidade sendo introduzida no aplicativo.
Por onde começamos?
Análise de Segurança e Plano de Teste
Ele começa com uma análise inicial de segurança e um plano de teste subsequente que descreve como, quando e onde os testes serão realizados.
Onde os resultados dos testes serão arquivados e quem será o responsável pela aplicação dos resultados de volta ao pipeline.
Tanto a análise quanto o plano em si devem residir em um repositório como o GitHub e devem estar sujeitos às mesmas políticas de SCM que qualquer outro código.
Isso garantirá que todos os envolvidos possam contribuir e entender o plano de teste de segurança e suas responsabilidades individuais nesse plano.
Área de trabalho do desenvolvedor
Tanto o Docker quanto o Ansible são ótimas soluções para fornecer aos desenvolvedores um espaço de trabalho seguro e reutilizável.
Vamos encarar. Todos os desenvolvedores, testadores e profissionais de TI hackearam seu espaço de trabalho perfeito.
Eles têm seus programas favoritos, comandos de console, macros, atalhos, cores, fontes, etc.
Entre em contato com seus desenvolvedores e use suas informações para criar um ambiente unificado que pode ser desenvolvido em qualquer lugar.
Proteja esse ambiente e, dependendo das linguagens de programação internas, adicione as ferramentas de teste apropriadas.
Para Eclipse ou IntelliJ IDEA, você pode instalar o SonarLint, PMD, FindBugs e JUnit.
Se você usar o Visual Studio ou o Visual Studio Code, instale o ReSharper, o SonarLint, o CodeRush, o FxCop e o NUnit.
Para Atom, SonarLint, RSpec, brakeman e Mocha.
Não há combinação perfeita de ferramentas de segurança.
Os exemplos acima são apenas isso – exemplos. As ferramentas que cada organização usará dependerão de fatores como linguagem (s) de programação, tamanho e complexidade organizacional e atitudes no local de trabalho.
Independentemente das ferramentas IDE usadas, verifique se todos os resultados do teste são registrados, agregados e exibidos em tempo real para todos monitorarem.
Linters / Git Controls / Secrets
Enquanto você está projetando o ambiente de desenvolvimento final, considere adicionar linters, controles git e algum mecanismo para proteger segredos, como senhas, chaves de API, etc.
Genericamente, lint ou linter é qualquer ferramenta que sinaliza uso suspeito em software escrito em qualquer linguagem de computador.
O linting é um processo automatizado que faz uma análise de código estático (sem executar o código) para encontrar possíveis erros e impor padrões de codificação.
Linting geralmente é bastante rápido e permite impor não apenas padrões de codificação, mas também padrões de segurança, documentação e tratamento de erros.
Ferramentas de lint existem para a maioria dos idiomas.
Alguns populares incluem o cfn-Nag (AWS CloudFormation), o Puppet Lint (Puppet), o FoodCritic (Chef), o Rubocop (Ruby), o ESLint (JavaScript), o GoMetaLinter (Golang), o CSSLint (CSS), o SonarLint (Java, C #), e AnsibleLint (Ansible). Uma outra ferramenta on-line bacana que eu uso o tempo todo é JSONLint.
Evite que strings confidenciais, como senhas e chaves de API, sejam comprometidas com o Github.
Isso acontece com ferramentas como git-secrets e, enquanto você pensa em proteção de repositório, por que não adicionar o Blackduck Hub (BDH) para não incorporar vulnerabilidades conhecidas ao importar Código fonte aberto em seu projeto.
Como o BDH, o FoSSology é um kit de ferramentas de conformidade com licenças Open Source alternativas.
Proteger segredos dentro do seu ambiente de CI / CD pode facilmente ser um tópico por si só, mas como estou tentando resumir uma grande variedade de ferramentas em um curto espaço de tempo, mencionarei a que eu estou mais familiarizado – HashiCorp Vult.
No entanto, existem outras soluções, e a AWS acaba de lançar uma solução de segredos dedicada que vai além do que você poderia realizar com os armazenamentos de parâmetros.
Teste de segurança de aplicativo estático (SAST)
As ferramentas SAST são um conjunto de tecnologias projetadas para analisar código-fonte, bytecode e binários não compilados, para codificação e condições de design indicativas de vulnerabilidades de segurança.
O objetivo do SAST é identificar vulnerabilidades em seu código-fonte antes de implantar na produção.
As soluções SAST geralmente são programadas em linguagem específica e analisam um aplicativo de dentro para fora em estado de não execução.
As técnicas SAST podem detectar estouro de buffer, vulnerabilidades de segurança, erros de ponteiro, vazamentos de memória, e outros erros comuns de programação.
Existem muitas ferramentas específicas de idioma. As ferramentas SAST independentes do idioma comum incluem o Sonarqube, o Sentry, o HP Fortify SCA, o Coverity, o Checkmarx e o Veracode.
Seu objetivo não é testar com todas as ferramentas disponíveis, mas sim desenvolver um conjunto de ferramentas que se alinhem com suas atitudes, requisitos e orçamento organizacionais.
O Gartner classifica as principais ferramentas SAST e DAST da seguinte forma:
Além das ferramentas SAST mencionadas acima, não queremos deixar de fora as ferramentas de cobertura de código.
Cobertura de código é uma medida de quantas linhas, instruções ou blocos de seu código são testados usando seu conjunto de testes automatizados.
É uma métrica essencial para entender a qualidade dos seus esforços de teste.
A cobertura de código mostra quanto da sua aplicação não é coberta por testes automatizados e, portanto, é vulnerável a defeitos.
Tente garantir que todo o seu código seja testado, embora, na prática, a cobertura de 70% a 80% seja considerada suficiente.
Teste de segurança de aplicativos dinâmicos (DAST)
As tecnologias DAST são projetadas para detectar condições indicativas de uma vulnerabilidade de segurança em um aplicativo em seu estado de execução.
A maioria das soluções DAST testa apenas as interfaces HTTP, HTML, REST e SOAP expostas dos aplicativos habilitados para a Web.
No entanto, algumas soluções são projetadas especificamente para malformações de protocolo e dados não-Web, como chamadas de procedimento remoto e retornos de chamada.
As técnicas DAST podem simular e detectar problemas associados à autenticação, autorização, ataques do lado do cliente, execução inadequada de comandos, injeção de SQL, divulgação errônea de informações, interfaces e pontos de extremidade da API.
As ferramentas DAST populares incluem o nmap, o Metasploit / Rapid7, o Burp Suite, o Nikto2, o Arachni, o OWASP ZAProxy, o SQLMap, o Lynis e o Accunetix.
Orquestração
Os conjuntos de ferramentas SAST e DAST exigem orquestração para automatizar o teste.
A ferramenta de orquestração de CI / CD mais comum hoje é Jenkins.
O Jenkins é relativamente simples de instalar, configurar e usar; e é poderoso por si só.
Jenkins brilha quando adicionamos os mil ou mais plug-ins comerciais e comunitários desenvolvidos.
Existem plugins para muitas das ferramentas mencionadas neste artigo.
Provavelmente, a decisão mais difícil que você tomará ao usar o Jenkins é quais plugins fornecem o maior valor.
O Jenkins geralmente é configurado para executar uma compilação imediatamente após cada confirmação. Isso garante que o conjunto de testes completo seja executado sempre que o código do aplicativo for atualizado.
Teste de penetração e verificação de vulnerabilidades
A maioria das ferramentas DAST mencionadas acima também pode ser usada para testes de penetração e varredura de vulnerabilidades.
Com o entendimento de que há alguma sobreposição, essa última categoria de ferramentas adota uma abordagem mais geral ou holística para a varredura de segurança.
Por exemplo, Burp, Nikto2 e Arachni são muito especificamente scanners web ou HTTP.
Eles não verificam vulnerabilidades de injeção de SQL. O SQLMap, por outro lado, não verifica as vulnerabilidades da Web, mas se destaca na exploração da injeção de SQL.
Nenhuma das ferramentas DAST mencionadas (com exceção do Metasploit / Rapid7 e possivelmente, nmap) procura vulnerabilidades de RPC, mas uma rápida pesquisa no banco de dados Common Vulnerabilities and Exposures (CVE) lista 338 vulnerabilidades de RPC.
As principais ferramentas de teste de penetração e de varredura de vulnerabilidades que serão executadas antes do lançamento incluem: Tenable Nessus, Qualys, Retina CS do BeyondTrust e Rapid7 nexpose.
Todas essas ferramentas fornecem a capacidade de verificar vulnerabilidades e a opção de testar se quaisquer vulnerabilidades encontradas são exploráveis.
Essas ferramentas fornecem visibilidade abrangente e insight sobre a segurança de aplicativos com varredura de aplicativos freqüente, rápida e automatizada.
Eles também podem ser configurados para se concentrar em classes específicas de vulnerabilidades para que os desenvolvedores possam priorizar os esforços de correção.
Por último, a função de relatórios fornece documentação útil para conformidade e auditoria.
Segurança do Pipeline
Neste artigo, nos concentramos em testar a segurança de um ou mais aplicativos enquanto eles transitam pelo pipeline.
Isto é, segurança no pipeline.
Embora seja importante testar um aplicativo com pipeline, é ainda mais importante testar o pipeline e seu ambiente continuamente também.
Como mencionei acima, desenvolvedores e administradores preguiçosos frequentemente sacrificam a segurança por conveniência.
Dada a velocidade do esforço e o número de pessoas envolvidas na criação e manutenção de uma infra-estrutura de DevOps – especialmente em organizações que estão apenas iniciando suas viagens, os códigos maliciosos podem ser injetados no ambiente de CI / CD.
Essas mesmas ferramentas que você usa para testar o aplicativo e verificar vulnerabilidades devem ser usadas para verificar as próprias ferramentas de pipeline (como um cluster Jenkins) e o ambiente no qual o pipeline reside (AWS, por exemplo).
Além disso, o uso e integração de ferramentas de monitoramento como o Nagios, sistemas de detecção de intrusos como o Snort, bem como ferramentas de gerenciamento de configuração como Chef e Puppet, e ferramentas de registro como Graphite, ELK stack ou até mesmo um gerenciamento de informações e eventos de segurança (SIEM) solução como o Splunk, devem ser altamente priorizadas.
A telemetria de segurança deve ser avaliada continuamente e disponibilizada para todos da equipe. Os incidentes de segurança devem ser remediados imediatamente e o sistema reconfigurado para que qualquer incidente de segurança específico ocorra apenas uma vez.
Na minha opinião, o desenvolvimento ágil tem tudo a ver com mindset, pipeline e ferramentas.
Neste artigo, concentrei-me em ferramentas porque, francamente, é mais fácil do que tentar entender como efetuar mudanças institucionais.
Eu sei que, em algum momento, algumas organizações começam a acreditar que o desenvolvimento rápido funciona quando os membros da equipe são incentivados a ir rápido e quebrar as coisas, e que, para vencer seus concorrentes, a organização precisa imaginá-los.
Nem toda organização pode ter sucesso nisso. Infelizmente, a solução para isso não é estereotipada.
O mantra do DevSecOps é o teste em todos os lugares – em todas as etapas do pipeline.
Teste o código não compilado estático e os aplicativos dinâmicos. Teste e monitore as ferramentas de pipeline e o ambiente também.
O teste de segurança não está separado do desenvolvimento; está entrelaçado no desenvolvimento.
Além disso, no DevSecOps, é imperativo que os arquitetos de segurança da informação integrem a segurança aos fluxos de trabalho do DevOps em vários pontos do pipeline e de forma colaborativa e transparente para os desenvolvedores, preservando o trabalho em equipe e a velocidade de um ambiente de desenvolvimento ágil.
Sobre o autor: Guilherme Teles é um cara qualquer que não dorme direito e acaba escrevendo. Sou Certificado CISSP, CHFI, CEH, LPIC-3, AWS CDA, AWS SAA, AWS SOA Quer assinar a newsletter do site e receber esse e outros artigos? Clique aqui! Aproveite e navegue pelo smeu blog. Quem sabe você não está exatamente precisando de uma ajuda ? 
