Tínhamos 2 analisadores de código, 4 ferramentas para testes dinâmicos, nossas criações e 250 scripts. Não que tudo isso fosse necessário no processo atual, mas, uma vez que começamos a implementar o DevSecOps, é preciso ir até o fim.
. Criadores dos personagens: Justin Roiland e Dan Harmon.
O que é SecDevOps? E DevSecOps? Quais são as diferenças? O que é Segurança de Aplicação? Por que a abordagem clássica não funciona mais? Todas essas perguntas têm resposta Yuri Shabalin do Swordfish Security. Yuri responderá tudo em detalhes e analisará os problemas da transição do modelo clássico de Segurança de Aplicação para o processo DevSecOps: como abordar corretamente a incorporação do processo de desenvolvimento seguro no processo DevOps sem quebrar nada, como passar pelas principais etapas de teste de segurança, quais ferramentas podem ser aplicadas, como se diferenciam e como configurá-las corretamente para evitar armadilhas.
Sobre o palestrante: Yuri Shabalin é Arquiteto Chefe de Segurança na Swordfish Security. Responsável pela implementação do SSDL, pela integração geral das ferramentas de análise de aplicações em um único ecossistema de desenvolvimento e teste. 7 anos de experiência em segurança da informação. Trabalhou no Alfa-Bank, Sberbank e na Positive Technologies, que desenvolve software e fornece serviços. Palestrante em conferências internacionais como ZerONights, PHDays, RISSPA, OWASP.
Segurança de Aplicação: o que é?
Segurança de Aplicação é uma disciplina de segurança que se ocupa da segurança das aplicações. Isso não se refere à infraestrutura ou à segurança de rede, mas sim ao que escrevemos e no que os desenvolvedores trabalham — são as falhas e vulnerabilidades da própria aplicação.
Direção — Ciclo de vida de desenvolvimento de segurança foi desenvolvido pela Microsoft. Na imagem — modelo canônico de SDLC, cuja principal tarefa é a participação da segurança em cada etapa do desenvolvimento, desde os requisitos até o lançamento e a produção. A Microsoft percebeu que havia muitos bugs no produto, que estavam se tornando mais frequentes, e que era necessário fazer algo a respeito, então propôs essa abordagem que se tornou canônica.
A Segurança de Aplicação e o SSDL não têm como foco a detecção de vulnerabilidades, como se costuma pensar, mas sim a prevenção de seu surgimento. Com o tempo, a abordagem canônica da Microsoft foi aprimorada e expandida, permitindo um mergulho mais profundo e detalhado.
O SDLC canônico é altamente detalhado em várias metodologias - OpenSAMM, BSIMM, OWASP. As metodologias diferem, mas, no geral, são semelhantes.
Modelo de Maturidade para Construir Segurança
Eu prefiro BSIMM — . A base da metodologia é a divisão do processo de Segurança da Aplicação em 4 domínios: Governança, Inteligência, Pontos de Contato SSDL e Implantação. Em cada domínio, existem 12 práticas, apresentadas na forma de 112 atividades.
Cada uma das 112 atividades tem 3 níveis de maturidade: inicial, intermediário e avançado. As 12 práticas podem ser estudadas por seções, selecionar os tópicos importantes para você, entender como implementá-los e gradualmente adicionar elementos, como análise estática e dinâmica de código ou revisão de código. Você elabora um plano e, com ele, trabalha tranquilamente dentro do escopo das atividades escolhidas.
Por que DevSecOps
DevOps é um processo amplo em que é necessário se preocupar com a segurança.
Inicialmente se previa a realização de verificações de segurança. Na prática, o número de equipes de segurança era muito menor do que hoje, e elas atuavam não como participantes do processo, mas como uma entidade de controle e supervisão que impõe requisitos e verifica a qualidade do produto no final do lançamento. Esse é o abordado clássico, no qual as equipes de segurança estavam isoladas da equipe de desenvolvimento e não participavam do processo.
O principal problema reside no fato de que a segurança da informação está separada do desenvolvimento. Normalmente, há um certo contorno de segurança da informação e nele estão 2-3 grandes e caras ferramentas. A cada seis meses, chega o código-fonte ou o aplicativo que precisa ser verificado, e uma vez por ano são realizados . Tudo isso leva ao atraso dos prazos de lançamento no mercado, enquanto o desenvolvedor se depara com uma quantidade enorme de vulnerabilidades geradas por ferramentas automatizadas. Tudo isso é impossível de ser analisado e corrigido, porque ainda não se analisaram os resultados dos últimos seis meses e aqui chega uma nova leva.
Durante o processo de trabalho da nossa empresa, vemos que a segurança em todos os setores e indústrias reconhece que é hora de se alinhar e girar junto com o desenvolvimento na mesma engrenagem - no . A paradigma DevSecOps se encaixa perfeitamente na metodologia de desenvolvimento ágil, na implementação, suporte e participação em cada lançamento e iteração.
A transição para DevSecOps
A palavra mais importante no Ciclo de Vida do Desenvolvimento de Segurança é "processo"Você precisa entender isso antes de pensar em comprar ferramentas.
Apenas incluir ferramentas no processo DevOps não é suficiente — a interação e compreensão entre os participantes do processo são importantes.
As pessoas são mais importantes do que as ferramentas.
Frequentemente, o planejamento do processo de desenvolvimento seguro começa com a escolha e compra de uma ferramenta e termina com tentativas de integrar a ferramenta ao processo atual, que permanecem apenas tentativas. Isso leva a consequências infelizes, pois cada ferramenta tem suas características e limitações.
Um caso comum é quando o departamento de segurança escolhe uma boa ferramenta cara, com amplas capacidades, e chega aos desenvolvedores — para integrá-la no processo. Mas não funciona — o processo está estruturado de tal forma que as limitações da ferramenta já comprada não se encaixam na atual paradigma.
Primeiro, descreva qual resultado você deseja e como o processo deve ser. Isso ajudará a entender os papéis da ferramenta e da segurança no processo.
Comece com o que já está em uso.
Antes de comprar ferramentas caras, veja o que você já tem. Cada empresa tem requisitos de segurança que são exigidos para o desenvolvimento, há auditorias, testes de penetração — por que não transformar tudo isso em uma forma compreensível e conveniente para todos?
Geralmente, os requisitos são um documento extenso que fica em uma prateleira. Houve um caso em que chegamos a uma empresa para revisar os processos e pedimos para ver os requisitos de segurança do software. O especialista responsável passou um bom tempo procurando:
— Agora, em algum lugar nas anotações estava o caminho onde esse documento está.
No final, recebemos o documento após uma semana.
Para requisitos, auditorias e outros, crie uma página, por exemplo, no Confluence — isso é conveniente para todos.
É mais fácil reformular o que já existe e usar isso como ponto de partida.
Use os Security Champions.
Normalmente, em uma empresa média com 100-200 desenvolvedores, há um especialista em segurança que desempenha várias funções e não consegue verificar tudo fisicamente. Mesmo que ele se esforce ao máximo — sozinho não conseguirá revisar todo o código que a equipe de desenvolvimento gera. Para tais casos, foi desenvolvido o conceito — .
Security Champions são pessoas dentro da equipe de desenvolvimento que estão interessadas na segurança do seu produto.
Security Champion é o ponto de entrada na equipe de desenvolvimento e o evangelista de segurança em uma única pessoa.
Normalmente, quando um especialista em segurança chega à equipe de desenvolvimento e aponta um erro no código, ele recebe uma resposta surpreendida:
— E você quem é? Eu nunca te vi antes. Está tudo bem para mim — meu colega mais experiente deu ‘aplicar’ na revisão do código, vamos seguir em frente!
Essa é uma situação típica, porque há muito mais confiança em colegas seniores ou simplesmente em colegas de equipe com os quais o desenvolvedor interage constantemente nas revisões de código. Se, ao invés de um especialista em segurança, for um Security Champion a apontar o erro e suas consequências, sua palavra terá mais peso.
Além disso, os desenvolvedores conhecem melhor seu código do que qualquer especialista em segurança. Para uma pessoa que analisa pelo menos 5 projetos em uma ferramenta de análise estática, é normalmente difícil lembrar de todos os detalhes. Security Champions conhecem seu produto: o que interage com o quê e a que devem prestar atenção primeiro — eles são mais eficazes.
Então, considere implementar Security Champions e ampliar a influência da equipe de segurança. Para o próprio campeão, isso também é vantajoso: desenvolvimento profissional em uma nova área, ampliação da visão técnica, aprimoramento de habilidades técnicas, gerenciais e de liderança, aumento do valor no mercado. É um certo elemento de engenharia social, seus ‘olhos’ na equipe de desenvolvimento.
Fases de teste
diz que 20% dos esforços dão 80% dos resultados. Esses 20% são práticas de análise de aplicações que podem e devem ser automatizadas. Exemplos de tais atividades são análise estática — SAST, análise dinâmica — DAST, e controle de Open Source. Vou falar mais sobre as atividades, assim como sobre as ferramentas, quais peculiaridades normalmente encontramos ao implementá-las no processo e como fazê-lo corretamente.
Principais problemas das ferramentas
Destacarei problemas relevantes para todas as ferramentas que exigem atenção. Vou analisá-los mais detalhadamente, para não me repetir depois.
Longo tempo de análise. Se de um commit até o lançamento em produção leva 30 minutos para todos os testes e a montagem, as verificações de segurança da informação levarão um dia. Ninguém vai atrasar o processo assim. Considere essa particularidade e tire suas conclusões.
Alto nível de Falso Negativo ou Falso Positivo. Todos os produtos são diferentes, todos usam diferentes frameworks e têm seu próprio estilo de codificação. Em diferentes bases de código e tecnologias, as ferramentas podem mostrar diferentes níveis de Falso Negativo e Falso Positivo. Portanto, veja o que exatamente em sua empresa e seus aplicativos mostrarão bons e confiáveis resultados.
Sem integrações com ferramentas existentes. Veja as ferramentas do ponto de vista das integrações, com o que você já está utilizando. Por exemplo, se você tem Jenkins ou TeamCity, verifique a integração das ferramentas exatamente com esse software, e não com GitLab CI, que você não utiliza.
Falta ou complexidade excessiva de personalização. Se a ferramenta não tem API, por que ela é necessária? Tudo que pode ser feito na interface deve estar disponível através da API. Idealmente, a ferramenta deve permitir a personalização das verificações.
Sem Roadmap de desenvolvimento do produto. O desenvolvimento não para, estamos sempre usando novos frameworks e funções, reescrevendo o código antigo em novas linguagens. Queremos ter certeza de que a ferramenta que comprarmos suportará novos frameworks e tecnologias. Portanto, é importante saber que o produto tem um real e adequado desenvolvimento.
Particularidades do processo
Além das particularidades das ferramentas, considere também as particularidades do processo de desenvolvimento. Por exemplo, interromper o desenvolvimento é um erro típico. Vamos ver quais outras particularidades devem ser consideradas e em que a equipe de segurança deve prestar atenção.
Para não atrasar os prazos de desenvolvimento e lançamento, crie regras diferentes e diferentes show stoppers — critérios para interromper o processo de montagem na presença de vulnerabilidades — para diferentes ambientes. Por exemplo, entendemos que o branch atual vai para o ambiente de desenvolvimento ou UAT, então não vamos parar e dizer:
— Você tem vulnerabilidades aqui, vocês não podem seguir adiante!
Neste estágio, é importante informar aos desenvolvedores que existem problemas de segurança que devem ser observados.
A presença de vulnerabilidades não é um impedimento para testes adicionais: manuais, integrações ou manuais. Por outro lado, precisamos de alguma forma aumentar a segurança do produto, e para que os desenvolvedores não ignorem o que a segurança encontra. Portanto, às vezes fazemos o seguinte: na bancada, quando é lançado no ambiente de desenvolvedor, apenas notificamos a equipe de desenvolvimento:
— Pessoal, vocês têm problemas, por favor, prestem atenção neles.
Na fase de UAT, novamente mostramos os avisos sobre vulnerabilidades, e na fase de lançamento ao público, dizemos:
— Pessoal, avisamos várias vezes, vocês não fizeram nada — não vamos liberar vocês com isso.
Se falarmos sobre código e dinâmica, é necessário mostrar e avisar sobre as vulnerabilidades apenas das funcionalidades e do código que foram escritos recentemente nesta feature. Se um desenvolvedor moveu um botão em 3 pixels e dizemos a ele que há uma injeção SQL lá e que precisa ser corrigido urgentemente — isso está incorreto. Olhem apenas para o que foi escrito agora e para a mudança que está sendo introduzida no aplicativo.
Suponha que temos um defeito funcional — como o aplicativo não deve funcionar: dinheiro não é transferido, ao clicar no botão não ocorre transição para a próxima página ou o produto não carrega. Defeitos de segurança — são defeitos similares, mas não em termos de funcionamento do aplicativo, mas sim de segurança.
Nem todos os problemas de qualidade de software são problemas de segurança. Mas todos os problemas de segurança estão relacionados à qualidade do software. Sherif Mansour, Expedia.
Como todas as vulnerabilidades são defeitos, elas devem estar no mesmo lugar que todos os defeitos de desenvolvimento. Portanto, esqueçam os relatórios e os PDFs assustadores que ninguém lê.
Quando eu trabalhava em uma empresa de desenvolvimento, recebi um relatório de ferramentas de análise estática. Eu o abri, fiquei horrorizado, preparei um café, folheei 350 páginas, fechei e fui trabalhar novamente. Relatórios grandes são relatórios mortos. Normalmente, eles não vão a lugar nenhum, os e-mails são deletados, esquecidos, perdidos ou a empresa diz que aceita os riscos.
O que fazer? Os defeitos confirmados que encontramos são simplesmente transformados em uma forma amigável para desenvolvimento, por exemplo, armazenando no backlog no Jira. Priorizamos os defeitos e os corrigimos na ordem de prioridade, juntamente com os defeitos funcionais e de teste.
Análise Estática - SAST
É uma análise de código em busca de vulnerabilidades, mas não é a mesma coisa que o SonarQube. Verificamos não apenas por padrões ou estilo. Na análise, é aplicado um conjunto de abordagens: por meio da árvore de vulnerabilidades, por , através da análise de arquivos de configuração. Isso é tudo que diz respeito diretamente ao código.
Vantagens da abordagem: detecção de vulnerabilidades no código em uma fase inicial do desenvolvimento, quando ainda não há ambientes e ferramentas prontas, e possibilidade de escaneamento incremental: escanear a parte do código que foi alterada e apenas a funcionalidade que estamos desenvolvendo agora, o que reduz o tempo de escaneamento.
Desvantagens — é a falta de suporte para as linguagens necessárias.
Integrações necessárias, que devem estar nas ferramentas, na minha opinião subjetiva:
- Ferramenta de integração: Jenkins, TeamCity e Gitlab CI.
- Ambiente de desenvolvimento: Intellij IDEA, Visual Studio. Para o desenvolvedor, é mais conveniente não ter que navegar em uma interface desconhecida que ainda precisa ser memorizada, mas ver todas as integrações necessárias e as vulnerabilidades que encontrou diretamente em seu próprio ambiente de desenvolvimento.
- Revisão de código: SonarQube e revisão manual.
- Rastreadores de defeitos: Jira e Bugzilla.
Na imagem, alguns dos melhores representantes da análise estática.
O importante não são as ferramentas, mas o processo, por isso existem soluções Open Source que também são boas para testar o processo.
SAST Open Source não encontrarão uma quantidade enorme de vulnerabilidades ou DataFlow complexos, mas ao construir o processo, eles podem e devem ser usados. Eles ajudam a entender como o processo será montado, quem será responsável pelos bugs, quem fará relatórios, quem prestará contas. Se você deseja realizar a fase inicial de construção da segurança do seu código, use soluções Open Source.
Como isso pode ser integrado, se você está no início do caminho, não tem nada: nem CI, nem Jenkins, nem TeamCity? Vamos considerar as integrações no processo.
Integração a nível CVS
Se você possui Bitbucket ou GitLab, pode fazer a integração a nível .
Por evento — pull request, commit. Você escaneia o código e, no status do build, mostra se a verificação de segurança foi bem-sucedida ou não.
Feedback. Sem dúvida, o feedback é sempre necessário. Se você apenas executou na área de segurança, colocou tudo em uma caixa e não contou a ninguém sobre isso, e depois no final do mês despejou uma série de bugs — isso não está certo e não é bom.
Integração com o sistema de code review
Certa vez, configuramos um usuário técnico de AppSec como revisor padrão em uma série de projetos importantes. Dependendo se erros foram encontrados no novo código ou não, o revisor do pull request define o status como "accept" ou "need work" — ou tudo OK, ou é necessário fazer ajustes com links sobre o que exatamente deve ser ajustado. Para a integração com a versão que está em produção, tivemos uma proibição de merge se o teste de segurança não fosse aprovado. Incorporamos isso à revisão manual de código, e os demais participantes do processo viam os status de segurança exatamente para esse processo específico.
Integração com SonarQube
Muitos têm para qualidade de código. Aqui é a mesma coisa — é possível fazer os mesmos gates apenas para ferramentas SAST. Terá a mesma interface, o mesmo quality gate, só que será chamado de security gate. E assim, se você tiver um processo utilizando SonarQube, poderá integrar tudo lá tranquilamente.
Integração em nível CI
Aqui também é tudo bastante simples:
- Em um nível com autotestes, testes unitários.
- Divisão por etapas de desenvolvimento: dev, test, prod. Podem ser incluídos diferentes conjuntos de regras, ou diferentes condições de falha: parar a compilação ou não parar a compilação.
- Execução síncrona/assíncrona. Esperamos a conclusão da verificação de segurança ou não. Ou seja, nós apenas a iniciamos e continuamos, e depois recebemos o status de que tudo está bom ou ruim.
Isso tudo em um mundo rosa ideal. Na vida real, isso não existe, mas nós nos esforçamos. O resultado das verificações de segurança deve ser análogo aos resultados dos testes unitários.
Por exemplo, pegamos um grande projeto e decidimos que agora vamos escaneá-lo com SAST — tudo bem. Colocamos esse projeto no SAST, que nos apresentou 20.000 vulnerabilidades, e, por decisão firme, aceitamos que estava tudo bem. 20.000 vulnerabilidades são nossa dívida técnica. Vamos guardar essa dívida em uma caixinha, e iremos resolvendo aos poucos e registrando bugs nos trackers. Contratamos uma empresa, fazemos tudo sozinhos ou contamos com a ajuda dos Security Champions — e a dívida técnica vai diminuindo.
E todas as novas vulnerabilidades no código novo devem ser corrigidas assim como erros em unit tests ou testes automatizados. Em termos gerais, uma nova compilação foi iniciada, rodaram os testes, dois falharam, e dois testes de segurança falharam. Tudo bem — verificamos o que aconteceu, corrigimos um, corrigimos o outro, e na próxima vez que rodamos — tudo certo, novas vulnerabilidades não surgiram, os testes não falharam. Se a tarefa for mais complexa e precisarmos investigá-la mais a fundo, ou se a correção das vulnerabilidades afetar grandes partes do que está 'debaixo do capô': registramos um bug no tracker, ele é priorizado e corrigido. Infelizmente, o mundo não é perfeito e os testes às vezes falham.
Um exemplo de security gate — análogo ao quality gate, relacionado à presença e quantidade de vulnerabilidades no código.
Integramos com o SonarQube — o plugin é instalado, tudo muito conveniente e legal.
Integração com o ambiente de desenvolvimento
Possibilidades de integração:
- Iniciar o escaneamento a partir do ambiente de desenvolvimento antes do commit.
- Visualização dos resultados.
- Análise dos resultados.
- Sincronização com o servidor.
Assim é como a obtenção de resultados do servidor parece.
No nosso ambiente de desenvolvimento aparece simplesmente um item adicional, informando que durante o escaneamento vulnerabilidades foram descobertas. Você pode corrigir o código imediatamente, verificar as recomendações e . Tudo isso está posicionado no local de trabalho do desenvolvedor, o que é muito conveniente — não é necessário navegar por outros links e procurar mais informações.
Open Source
Esse é meu tema favorito. Todos usam bibliotecas Open Source — por que escrever um monte de gambiarras e bicicletas, quando você pode pegar uma biblioteca pronta, onde tudo já está implementado?
Claro, é verdade, mas as bibliotecas também são escritas por pessoas, incluem riscos específicos e também têm vulnerabilidades que são reportadas periodicamente ou constantemente. Por isso, há um próximo passo em Segurança de Aplicações — a análise de componentes Open Source.
Análise Open Source — OSA
A ferramenta inclui três etapas principais.
Busca por vulnerabilidades em bibliotecas. Por exemplo, a ferramenta sabe que estamos usando uma biblioteca específica, e que existem ou que há algumas vulnerabilidades nos rastreadores de bug que se referem a essa versão da biblioteca. Ao tentar utilizá-la, a ferramenta emitirá um aviso de que a biblioteca é vulnerável e sugerirá usar uma versão onde as vulnerabilidades foram corrigidas.
Análise da conformidade de licenças. Isso ainda não é muito popular aqui, mas se você trabalha com o exterior, ocasionalmente pode receber uma advertência por usar um componente de código aberto que não pode ser utilizado ou modificado. Segundo a política da biblioteca de licenças, não podemos fazer isso. Ou, se a modificamos e a usamos, devemos disponibilizar nosso código. É claro que ninguém quer expor o código de seus produtos, mas há como se proteger disso.
Análise de componentes que são usados em ambientes industriais. Vamos imaginar uma situação hipotética, em que finalmente concluímos o desenvolvimento e lançamos a versão final de nosso microserviço. Ele está lá, funcionando maravilhosamente — uma semana, um mês, um ano. Não fazemos verificações de segurança, parece que está tudo bem. Mas, de repente, duas semanas após o lançamento, uma vulnerabilidade crítica é descoberta em um componente Open Source que estamos usando nesta versão, em um ambiente de produção. Se não registramos o que e onde estamos usando, essa vulnerabilidade simplesmente passará despercebida. Algumas ferramentas oferecem a capacidade de monitorar vulnerabilidades em bibliotecas que estão sendo usadas em produção. Isso é muito útil.
Características:
- Políticas diferentes para diferentes etapas de desenvolvimento.
- Monitoramento de componentes em ambientes industriais.
- Controle de bibliotecas no perímetro da organização.
- Suporte a diferentes sistemas de construção e linguagens.
- Análise de imagens Docker.
Alguns exemplos de líderes na área que estão envolvidos na análise de Open Source.
O único gratuito entre eles é do OWASP. É possível ativá-lo nas primeiras etapas, verificar como ele funciona e o que suporta. Basicamente, são todos produtos em nuvem ou on-premise, mas, em relação à sua base, eles de qualquer forma se conectam à internet. Eles não enviam suas bibliotecas, mas sim hashes ou seus próprios valores calculados, e fingerprints para seus servidores, a fim de receber notificações sobre a presença de vulnerabilidades.
Integração no processo
Controle de bibliotecas no perímetro, que são baixadas de fontes externas. Temos repositórios externos e internos. Por exemplo, dentro do Event Central há o Nexus, e queremos que não haja vulnerabilidades com status 'crítico' ou 'alto' dentro do nosso repositório. É possível configurar o proxy com a ferramenta Nexus Firewall Lifecycle para que tais vulnerabilidades sejam bloqueadas e não entrem no repositório interno.
Integração no CI. Em um nível com autotestes, testes unitários e divisão por etapas de desenvolvimento: dev, test, prod. Em cada etapa, é possível baixar quaisquer bibliotecas, usar o que for preciso, mas, se houver algo rígido com status 'crítico', talvez valha a pena chamar a atenção dos desenvolvedores na fase de lançamento em produção.
Integração com repositórios de artefatos: Nexus e JFrog.
Integração no ambiente de desenvolvimento. As ferramentas que você escolhe devem ter integração com os ambientes de desenvolvimento. O desenvolvedor deve ter acesso aos resultados da digitalização a partir de sua estação de trabalho, ou a capacidade de escanear e verificar o código por conta própria quanto a vulnerabilidades antes do commit no CVS.
Integração no CD. Esse é um recurso bacana que eu realmente gosto e sobre o qual já falei - monitoramento do surgimento de novas vulnerabilidades em ambientes de produção. Funciona mais ou menos assim.
Temos Repositórios Públicos de Componentes — algumas ferramentas externas e nosso repositório interno. Queremos que ele contenha apenas componentes confiáveis. Ao proxyar a solicitação, verificamos se a biblioteca baixada não possui vulnerabilidades. Se ela se enquadrar em determinadas políticas que estabelecemos e confirmamos com a equipe de desenvolvimento, ela não será baixada e uma notificação será enviada para usar outra versão. Portanto, se a biblioteca tiver algo realmente crítico e ruim, o desenvolvedor nem receberá a biblioteca na etapa de instalação — que use uma versão mais alta ou mais baixa.
- Durante a construção, verificamos se ninguém inseriu nada ruim, se todos os componentes são seguros e se ninguém trouxe nada perigoso em um pendrive.
- Em nosso repositório, temos apenas componentes confiáveis.
- Durante o deployment, verificamos mais uma vez o pacote em si: war, jar, DL ou imagem Docker para garantir que está em conformidade com a política.
- Ao sair para a produção, monitoramos o que acontece no ambiente de produção: se surgem ou não vulnerabilidades críticas.
Análise dinâmica — DAST.
Ferramentas de análise dinâmica diferem radicalmente do que foi dito até agora. É uma simulação do uso do aplicativo pelo usuário. Se for um aplicativo web, enviamos solicitações, simulando o trabalho do cliente, clicamos em botões na interface, enviamos dados artificiais do formulário: aspas, parênteses, símbolos em diferentes codificações, para observar como o aplicativo funciona e processa dados externos.
Esse mesmo sistema permite verificar vulnerabilidades padrão em Open Source. Como o DAST não sabe qual Open Source estamos usando, ele simplesmente dispara padrões 'maliciosos' e analisa as respostas do servidor:
— Ah, aqui há um problema de desserialização, e aqui não há.
Isso envolve grandes riscos, porque se você realizar esse teste de segurança no mesmo ambiente que os testadores estão utilizando, coisas desagradáveis podem acontecer.
- Alta carga na rede do servidor de aplicativos.
- Sem integrações.
- Capacidade de alterar configurações do aplicativo analisado.
- Sem suporte para as tecnologias necessárias.
- Complexidade de configuração.
Tivemos uma situação em que finalmente lançamos o AppScan: demoramos para obter acesso ao aplicativo, conseguimos 3 contas e ficamos felizes — finalmente vamos verificar tudo! Iniciamos a varredura, e a primeira coisa que o AppScan fez foi entrar no painel de administração, clicar em todos os botões, alterar metade dos dados e depois, afinal, derrubou o servidor com suas solicitações. O desenvolvimento com testes disse:
— Gente, vocês estão brincando?! Nós lhe demos contas, e vocês colocaram o ambiente fora do ar!
Considere os riscos possíveis. Idealmente, prepare um ambiente separado para testes de segurança da informação, que será isolado do restante do ambiente de alguma forma, e é recomendável verificar o painel de administração manualmente. Este é um pentest — os percentuais restantes de esforço que não estamos considerando agora.
É importante notar que isso pode ser usado como um análogo de teste de carga. Na primeira etapa, é possível ativar um scanner dinâmico em 10-15 threads e ver o que acontece, mas geralmente, como mostra a experiência, não resulta em nada bom.
Alguns recursos que normalmente usamos.
É importante destacar — é o ‘canivete suíço’ para qualquer especialista em segurança. Todos usam, e é muito prático. Recentemente, foi lançada uma nova versão demo da edição enterprise. Se antes era apenas uma ferramenta stand alone com plugins, agora os desenvolvedores estão finalmente criando um grande servidor, a partir do qual será possível gerenciar vários agentes. É incrível, recomendo experimentar.
Integração no processo
A integração ocorre de forma bastante boa e simples: iniciar a varredura após a instalação bem-sucedida do aplicativo no ambiente e varredura após a bem-sucedida realização de testes de integração.
Se as integrações não funcionam ou têm placeholders e funções simuladas, isso é sem sentido e inútil — qualquer que seja o padrão que enviarmos, o servidor ainda assim responderá da mesma forma.
- Idealmente, deve haver um ambiente separado para testes.
- Antes de iniciar o teste, registre a sequência de login.
- Testes do sistema de administração — apenas manuais.
Processo
Um pouco de forma geral sobre o processo e sobre o funcionamento de cada ferramenta, em particular. Todos os aplicativos são diferentes — um se destaca na análise dinâmica, outro na estática, um terceiro na análise de Código Aberto, testes de penetração ou, na verdade, algo completamente diferente, por exemplo, eventos com .
Cada processo precisa de controle.
Para entender como o processo funciona e onde ele pode ser melhorado, é necessário coletar métricas de tudo o que for acessível, incluindo métricas de produção, métricas de ferramentas e de rastreadores de defeitos.
Quaisquer dados são úteis. É importante observar de diferentes perspectivas onde cada ferramenta é melhor aplicada e onde o processo está falhando. Pode ser que valha a pena olhar para o tempo de resposta do desenvolvimento para entender onde melhorar o processo com base no tempo. Quanto mais dados, mais perspectivas podem ser construídas, desde níveis elevados até os detalhes de cada processo.
Como todos os analisadores estáticos e dinâmicos têm suas próprias APIs, métodos de execução e princípios — alguns possuem agendadores e outros não — estamos escrevendo uma ferramenta Orquestrador de AppSec, que permite estabelecer um único ponto de entrada para todo o processo desde o produto e gerenciá-lo a partir de um único ponto.
Gerentes, desenvolvedores e engenheiros de segurança têm um único ponto de entrada, a partir do qual é possível verificar o que está em execução, configurar e iniciar a varredura, obter os resultados da varredura e fazer exigências. Esforçamo-nos para abandonar papéis, traduzindo tudo para um formato compreensível que seja utilizado pelos desenvolvedores — páginas no Confluence com status e métricas, defeitos no Jira ou em diferentes rastreadores de defeitos, ou mesmo a integração em um processo síncrono/assíncrono no CI/CD.
Principais Conclusões
As ferramentas não são o mais importante. Primeiro, pense no processo — depois, implemente as ferramentas. As ferramentas são boas, mas caras, por isso pode-se começar com o processo e ajustar a interação e o entendimento entre o desenvolvimento e a segurança. Do ponto de vista da segurança, não é necessário "afundar" tudo de uma vez; do ponto de vista do desenvolvimento, se há algo de alta criticidade, isso precisa ser resolvido, e não ignorar o problema.
Qualidade do produto é o objetivo comum tanto da segurança quanto do desenvolvimento. Estamos fazendo a mesma coisa, esforçando-nos para que tudo funcione corretamente e para evitar riscos à reputação e perdas financeiras. É por isso que promovemos a abordagem DevSecOps e SecDevOps, para facilitar a comunicação e tornar o produto de maior qualidade.
Comece com o que já existe: requisitos, arquitetura, verificações parciais, treinamentos, diretrizes. Não é necessário aplicar todas as práticas em todos os projetos de imediato — avance de forma iterativa. Não há um padrão único — experimente e teste diferentes abordagens e soluções.
Entre os defeitos de segurança da informação e os defeitos funcionais há um sinal de igualdade.
Automatize tudo, o que se movimenta. Tudo que não se move — mova e automatize. Se algo for feito manualmente, essa parte do processo não é boa. Talvez valha a pena reconsiderá-la e também automatizá-la.
Se o tamanho da equipe de segurança da informação for pequeno — use Campeões de Segurança.
É possível que o que eu contei não sirva para você e que você crie algo próprio — e isso é bom. Mas escolha ferramentas com base nas exigências do seu processo específico. Não se baseie no que a comunidade diz, que esta ferramenta é ruim e aquela é boa. É possível que, no seu produto, tudo ocorra ao contrário.
Exigências para as ferramentas.
- Baixo nível de Falsos Positivos.
- Tempo de análise adequado.
- Facilidade de uso.
- Disponibilidade de integrações.
- Compreensão do Roadmap de desenvolvimento do produto.
- Possibilidade de customização das ferramentas.
A palestra do Yuri foi escolhida como uma das melhores na DevOpsConf 2018. Para conhecer mais ideias interessantes e casos práticos, venha nos dias 27 e 28 de maio em Skolkovo na dentro do . E ainda melhor, se você estiver disposto a compartilhar sua experiência, então para a palestra até 21 de abril.
Fonte: habr.com
