Medo e aversão ao DevSecOps

Tínhamos 2 analisadores de código, 4 ferramentas de teste dinâmico, artesanato próprio e 250 scripts. Não é que tudo isso seja necessário no processo atual, mas uma vez que você começa a implementar o DevSecOps, você tem que ir até o fim.

Fonte. Criadores de personagens: Justin Roiland e Dan Harmon.

O que é SecDevOps? E quanto ao DevSecOps? Quais são as diferenças? Segurança de aplicativos – do que se trata? Por que a abordagem clássica não funciona mais? Sabe a resposta para todas essas perguntas Yuri Shabalin de Segurança do Espadarte. Yuri responderá tudo detalhadamente e analisará os problemas de transição do modelo clássico de segurança de aplicativos para o processo DevSecOps: como abordar adequadamente a integração do processo de desenvolvimento seguro no processo DevOps e não quebrar nada, como passar pelos principais estágios de testes de segurança, quais ferramentas podem ser usadas, em que elas diferem e como configurá-las corretamente para evitar armadilhas.

Sobre o palestrante: Yuri Shabalin - Arquiteto Chefe de Segurança na empresa Segurança do Espadarte. Responsável pela implementação de SSDL, pela integração geral de ferramentas de análise de aplicações em um ecossistema unificado de desenvolvimento e testes. 7 anos de experiência em segurança da informação. Trabalhou no Alfa-Bank, Sberbank e Positive Technologies, que desenvolve software e presta serviços. Palestrante em conferências internacionais ZerONights, PHDays, RISSPA, OWASP.

Segurança de aplicações: do que se trata?

Application Security - Esta é a seção de segurança responsável pela segurança do aplicativo. Isso não se aplica à infraestrutura ou segurança de rede, mas sim ao que escrevemos e no que os desenvolvedores trabalham - essas são as deficiências e vulnerabilidades do próprio aplicativo.

direção SDL ou SDLC - Ciclo de vida de desenvolvimento de segurança - desenvolvido pela Microsoft. O diagrama mostra o modelo canônico SDLC, cuja principal tarefa é a participação da segurança em todas as etapas do desenvolvimento, desde os requisitos até o lançamento e produção. A Microsoft percebeu que havia muitos bugs na indústria, havia mais deles e algo precisava ser feito a respeito, e propôs essa abordagem, que se tornou canônica.

A segurança de aplicativos e o SSDL não têm como objetivo detectar vulnerabilidades, como comumente se acredita, mas sim prevenir sua ocorrência. Com o tempo, a abordagem canônica da Microsoft foi aprimorada, desenvolvida e introduzida em um mergulho mais profundo e detalhado.

O SDLC canônico é altamente detalhado em diversas metodologias - OpenSAMM, BSIMM, OWASP. As metodologias são diferentes, mas geralmente semelhantes.

Construindo segurança no modelo de maturidade

eu gosto mais BSIMM - Construindo segurança no modelo de maturidade. A base da metodologia é a divisão do processo de Segurança de Aplicações em 4 domínios: Governança, Inteligência, Touchpoints SSDL e Implantação. Cada domínio possui 12 práticas, que são representadas como 112 atividades.

Cada uma das 112 atividades tem 3 níveis de maturidade: iniciante, intermediário e avançado. Você pode estudar todas as 12 práticas seção por seção, selecionar coisas que são importantes para você, descobrir como implementá-las e adicionar elementos gradualmente, por exemplo, análise de código estática e dinâmica ou revisão de código. Você escreve um plano e trabalha com calma de acordo com ele como parte da implementação das atividades selecionadas.

Por que DevSecOps

DevOps é um processo geral e amplo no qual a segurança deve ser levada em consideração.

Inicialmente DevOps envolveu verificações de segurança. Na prática, o número de equipes de segurança era bem menor do que agora, e elas atuavam não como participantes do processo, mas como órgão de controle e fiscalização que lhe impõe requisitos e verifica a qualidade do produto ao final do lançamento. Esta é uma abordagem clássica em que as equipes de segurança estavam atrás do muro desde o desenvolvimento e não participavam do processo.

O principal problema é que a segurança da informação está separada do desenvolvimento. Normalmente, este é algum tipo de circuito de segurança da informação e contém 2 a 3 ferramentas grandes e caras. Uma vez a cada seis meses chega o código-fonte ou aplicativo que precisa ser verificado e uma vez por ano eles são produzidos testes de invasão. Tudo isso faz com que a data de lançamento para a indústria seja atrasada e o desenvolvedor fique exposto a um grande número de vulnerabilidades de ferramentas automatizadas. É impossível desmontar e consertar tudo isso, porque os resultados dos seis meses anteriores não foram acertados, mas aqui está um novo lote.

No decorrer do trabalho da nossa empresa, vemos que a segurança em todas as áreas e indústrias entende que é hora de acompanhar o desenvolvimento e girar na mesma roda - em Ágil. O paradigma DevSecOps se adapta perfeitamente à metodologia ágil de desenvolvimento, implementação, suporte e participação em cada lançamento e iteração.

Transição para DevSecOps

A palavra mais importante no Ciclo de Vida de Desenvolvimento de Segurança é "processo". Você deve entender isso antes de pensar em comprar ferramentas.

Simplesmente incorporar ferramentas ao processo DevOps não é suficiente – a comunicação e o entendimento entre os participantes do processo são importantes.

As pessoas são mais importantes, não as ferramentas.

Muitas vezes, o planejamento de um processo de desenvolvimento seguro começa com a escolha e compra de uma ferramenta e termina com tentativas de integração da ferramenta no processo atual, que continuam sendo tentativas. Isto leva a consequências infelizes, porque todas as ferramentas têm características e limitações próprias.

Um caso comum é quando o departamento de segurança escolhe uma ferramenta boa, cara e com amplos recursos e procura os desenvolvedores para integrá-la ao processo. Mas não dá certo - o processo está estruturado de tal forma que as limitações da ferramenta já adquirida não se enquadram no paradigma atual.

Primeiro, descreva o resultado que você deseja e como será o processo. Isso ajudará a compreender as funções 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á possui. Toda empresa possui requisitos de segurança para desenvolvimento, existem verificações, pentests - por que não transformar tudo isso em uma forma compreensível e conveniente para todos?

Geralmente os requisitos são um Talmud de papel que fica em uma prateleira. Houve um caso em que chegamos a uma empresa para analisar os processos e pedimos para ver os requisitos de segurança do software. O especialista que tratou disso passou muito tempo procurando:

- Agora, em algum lugar das notas havia um caminho onde está esse documento.

Como resultado, recebemos o documento uma semana depois.

Para requisitos, verificações e outras coisas, crie uma página, por exemplo. Confluence - é conveniente para todos.

É mais fácil reformatar o que você já possui e usá-lo para começar.

Use campeões de segurança

Normalmente, em uma empresa média com 100-200 desenvolvedores, há um especialista em segurança que executa diversas funções e não tem tempo físico para verificar tudo. Mesmo que ele dê o seu melhor, ele sozinho não verificará todo o código que o desenvolvimento gera. Para tais casos, um conceito foi desenvolvido - Campeões de segurança.

Os Campeões de Segurança são pessoas da equipe de desenvolvimento interessadas na segurança do seu produto.

O Security Champion é um ponto de entrada para a equipe de desenvolvimento e um evangelista de segurança reunidos em um só.

Normalmente, quando um especialista em segurança chega até uma equipe de desenvolvimento e aponta um erro no código, ele recebe uma resposta surpresa:

- E quem é você? Estou vendo você pela primeira vez. Está tudo bem para mim - meu amigo mais velho me deu uma “aplicação” na revisão do código, seguimos em frente!

Esta é uma situação típica, pois há muito mais confiança nos seniores ou simplesmente nos colegas de equipe com quem o desenvolvedor interage constantemente no trabalho e na revisão de código. Se, em vez do oficial de segurança, o Campeão de Segurança apontar o erro e as consequências, então a sua palavra terá mais peso.

Além disso, os desenvolvedores conhecem seu código melhor do que qualquer especialista em segurança. Para uma pessoa que possui pelo menos 5 projetos em uma ferramenta de análise estática, geralmente é difícil lembrar de todas as nuances. Os campeões de segurança conhecem seu produto: o que interage com o quê e o que observar primeiro – eles são mais eficazes.

Portanto, considere implementar Security Champions e expandir a influência da sua equipe de segurança. Isso também é útil para o próprio campeão: desenvolvimento profissional em uma nova área, ampliação de seus horizontes técnicos, atualização de competências técnicas, gerenciais e de liderança, aumento de valor de mercado. Este é algum elemento da engenharia social, seus “olhos” na equipe de desenvolvimento.

Estágios de teste

Paradigma 20 a 80 diz que 20% de esforço produz 80% de 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 a análise estática - SAST, análise dinâmica - DAST и Controle de código aberto. Contarei com mais detalhes sobre as atividades, bem como sobre as ferramentas, quais recursos normalmente encontramos ao introduzi-las no processo e como fazê-lo corretamente.

Principais problemas de ferramentas

Destacarei problemas que são relevantes para todos os instrumentos e que requerem atenção. Vou analisá-los com mais detalhes para não repeti-los ainda mais.

Longo tempo de análise. Se do commit até o lançamento levar 30 minutos para todos os testes e montagem, as verificações de segurança da informação levarão um dia. Portanto, ninguém irá retardar o processo. Leve esse recurso em consideração e tire conclusões.

Alto nível de falso negativo ou falso positivo. Todos os produtos são diferentes, todos usam estruturas diferentes e 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. Então veja o que exatamente está em seu empresas e para seu as aplicações mostrarão resultados bons e confiáveis.

Sem integrações com ferramentas existentes. Veja as ferramentas em termos de integrações com o que você já usa. Por exemplo, se você possui Jenkins ou TeamCity, verifique a integração das ferramentas com este software, e não com o GitLab CI, que você não utiliza.

Falta ou complexidade excessiva de personalização. Se uma ferramenta não possui API, por que ela é necessária? Tudo o que pode ser feito na interface deve estar disponível através da API. Idealmente, a ferramenta deve ter a capacidade de personalizar verificações.

Nenhum roteiro de desenvolvimento de produto. O desenvolvimento não fica parado, estamos sempre utilizando novos frameworks e funções, reescrevendo códigos antigos em novas linguagens. Queremos ter certeza de que a ferramenta que compramos suportará novas estruturas e tecnologias. Portanto, é importante saber que o produto possui características reais e corretas Roadmap desenvolvimento.

Recursos do processo

Além das funcionalidades das ferramentas, leve em consideração as características do processo de desenvolvimento. Por exemplo, impedir o desenvolvimento é um erro comum. Vejamos quais outros recursos devem ser levados em consideração e no que a equipe de segurança deve prestar atenção.

Para não perder os prazos de desenvolvimento e lançamento, crie regras diferentes e diferente rolhas de exibição — critérios para interromper o processo de construção na presença de vulnerabilidades — para diferentes ambientes. Por exemplo, entendemos que a filial atual vai para o estande de desenvolvimento ou UAT, o que significa que não paramos e dizemos:

“Você tem vulnerabilidades aqui, não irá a lugar nenhum!”

Neste ponto, é importante informar aos desenvolvedores que existem questões de segurança que precisam de atenção.

A presença de vulnerabilidades não é um obstáculo para testes adicionais: manual, integração ou manual. Por outro lado, precisamos aumentar de alguma forma a segurança do produto, e para que os desenvolvedores não negligenciem o que consideram seguro. Portanto, às vezes fazemos isso: no estande, quando é lançado no ambiente de desenvolvimento, simplesmente avisamos o desenvolvimento:

- Pessoal, vocês estão com problemas, prestem atenção neles.

Na fase UAT mostramos novamente avisos sobre vulnerabilidades e na fase de lançamento dizemos:

- Pessoal, já avisamos várias vezes, vocês não fizeram nada - não vamos deixar vocês escaparem disso.

Se falamos de código e dinâmica, então é necessário mostrar e alertar sobre vulnerabilidades apenas dos recursos e do código que acabou de ser escrito neste recurso. Se um desenvolvedor mover um botão em 3 pixels e dissermos a ele que ele tem uma injeção de SQL ali e, portanto, precisa ser consertado com urgência, isso está errado. Vejam apenas o que está escrito agora e a mudança que vem na aplicação.

Digamos que temos um certo defeito funcional - a forma como o aplicativo não deveria funcionar: o dinheiro não é transferido, ao clicar em um botão não há transição para a próxima página ou o produto não carrega. Defeitos de segurança - são os mesmos defeitos, mas não em termos de funcionamento do aplicativo, mas em 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. Xerife Mansour, Expedia.

Como todas as vulnerabilidades são os mesmos defeitos, elas devem estar localizadas no mesmo local que todos os defeitos de desenvolvimento. Então esqueça os relatórios e 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. Abri, fiquei horrorizado, fiz café, folheei 350 páginas, fechei e continuei trabalhando. Grandes relatórios são relatórios mortos. Geralmente elas não levam a lugar nenhum, as cartas são apagadas, esquecidas, perdidas ou a empresa diz que aceita os riscos.

O que fazer? Simplesmente convertemos os defeitos confirmados que encontramos em um formato conveniente para o desenvolvimento, por exemplo, os colocamos em um backlog no Jira. Priorizamos defeitos e os eliminamos em ordem de prioridade, juntamente com defeitos funcionais e defeitos de teste.

Análise Estática - SAST

Esta é uma análise de código em busca de vulnerabilidades., mas não é o mesmo que SonarQube. Não verificamos apenas padrões ou estilo. Várias abordagens são utilizadas na análise: de acordo com a árvore de vulnerabilidade, de acordo com Fluxo de dados, analisando arquivos de configuração. Isso é tudo o que diz respeito ao código em si.

Prós da abordagem: identificar vulnerabilidades no código em um estágio inicial de desenvolvimentoquando ainda não há estandes ou ferramentas prontas, e capacidade de digitalização incremental: verificando uma seção de código que foi alterada e apenas o recurso que estamos fazendo atualmente, o que reduz o tempo de verificação.

Contras - esta é a falta de suporte para os idiomas necessários.

Integrações necessárias, que deveria estar nas ferramentas, na minha opinião subjetiva:

• Ferramenta de integração: Jenkins, TeamCity e Gitlab CI.
• Ambiente de desenvolvimento: Intellij IDEA, Visual Studio. É mais conveniente para um desenvolvedor não navegar em uma interface incompreensível que ainda precisa ser memorizada, mas ver todas as integrações e vulnerabilidades necessárias que encontrou no local de trabalho em seu próprio ambiente de desenvolvimento.
• Revisão de código: SonarQube e revisão manual.
• Rastreadores de defeitos: Jira e Bugzilla.

A imagem mostra alguns dos melhores representantes da análise estática.

Não são as ferramentas que são importantes, mas sim o processo, por isso existem soluções Open Source que também são boas para testar o processo.

O SAST Open Source não encontrará um grande número de vulnerabilidades ou DataFlows complexos, mas eles podem e devem ser usados ​​na construção de um processo. Eles ajudam a entender como o processo será construído, quem responderá aos bugs, quem reportará e quem reportará. Se você deseja realizar a etapa inicial de construção da segurança do seu código, utilize soluções Open Source.

Como isso pode ser integrado se você está no início de sua jornada e não tem nada: nem CI, nem Jenkins, nem TeamCity? Vamos considerar a integração no processo.

Integração de nível CVS

Se você possui Bitbucket ou GitLab, pode integrar no nível Sistema de Versões Simultâneas.

Por evento - solicitação pull, confirmação. Você verifica o código e o status da compilação mostra se a verificação de segurança foi aprovada ou reprovada.

Feedback. Claro, o feedback é sempre necessário. Se você apenas fez segurança paralelamente, colocou em uma caixa e não contou nada a ninguém sobre isso, e então no final do mês despejou um monte de bugs - isso não é correto e não é bom.

Integração com o sistema de revisão de código

Certa vez, atuamos como revisores padrão para um usuário técnico do AppSec em vários projetos importantes. Dependendo se os erros são identificados no novo código ou se não há erros, o revisor define o status da solicitação pull como “aceitar” ou “precisa de trabalho” - ou está tudo OK ou os links para o que exatamente precisa ser melhorado precisa ser melhorado. Para integração com a versão que está entrando em produção, habilitamos a proibição de mesclagem caso o teste de segurança da informação não seja aprovado. Incluímos isso na revisão manual do código e outros participantes do processo viram os status de segurança desse processo específico.

Integração com SonarQube

Muitos têm portão de qualidade em termos de qualidade de código. É a mesma coisa aqui - você pode criar as mesmas portas apenas para ferramentas SAST. Haverá a mesma interface, o mesmo portão de qualidade, só que será chamado portão de segurança. E também, se você tiver um processo usando SonarQube, poderá integrar tudo facilmente lá.

Integração no nível de CI

Tudo aqui também é bastante simples:

• No mesmo nível dos autotestes, testes de unidade.
• Divisão por estágios de desenvolvimento: desenvolvimento, teste, produção. Diferentes conjuntos de regras ou diferentes condições de falha podem ser incluídos: pare a montagem, não pare a montagem.
• Lançamento síncrono/assíncrono. Estamos aguardando o fim dos testes de segurança ou não. Ou seja, acabamos de lançá-los e seguir em frente, e então obtemos o status de que tudo está bom ou ruim.

Está tudo em um mundo rosa perfeito. Não existe tal coisa na vida real, mas nos esforçamos. O resultado da execução das verificações de segurança deve ser semelhante aos resultados dos testes unitários.

Por exemplo, pegamos um projeto grande e decidimos que agora iremos digitalizá-lo com SAST - OK. Colocamos este projeto no SAST, ele nos deu 20 vulnerabilidades e por uma decisão obstinada decidimos que estava tudo bem. 000 vulnerabilidades são nossa dívida técnica. Colocaremos a dívida em uma caixa, vamos esclarecê-la lentamente e adicionar bugs aos rastreadores de defeitos. Vamos contratar uma empresa, fazer tudo sozinhos ou pedir a ajuda dos Security Champions - e a dívida técnica diminuirá.

E todas as vulnerabilidades emergentes no novo código devem ser eliminadas da mesma forma que os erros em uma unidade ou em autotestes. Relativamente falando, a montagem começou, rodamos, dois testes e dois testes de segurança falharam. OK - fomos, olhamos o que aconteceu, consertamos uma coisa, consertamos outra, executamos na próxima vez - estava tudo bem, nenhuma nova vulnerabilidade apareceu, nenhum teste falhou. Se esta tarefa for mais profunda e você precisar entendê-la bem, ou a correção de vulnerabilidades afeta grandes camadas do que está por baixo do capô: um bug foi adicionado ao rastreador de defeitos, ele é priorizado e corrigido. Infelizmente, o mundo não é perfeito e os testes às vezes falham.

Um exemplo de portão de segurança é análogo a um portão de qualidade, em termos de presença e número de vulnerabilidades no código.

Integramos com SonarQube - o plugin está instalado, tudo é muito prático e bacana.

Integração com ambiente de desenvolvimento

Opções de integração:

• Executando uma varredura no ambiente de desenvolvimento antes de confirmar.
• Ver resultados.
• Análise dos resultados.
• Sincronização com o servidor.

É assim que parece receber resultados do servidor.

Em nosso ambiente de desenvolvimento Intelij IDEA simplesmente aparece um item adicional informando que tais vulnerabilidades foram detectadas durante a verificação. Você pode editar imediatamente o código, consultar recomendações e Gráfico de Fluxo. Tudo isso está localizado no local de trabalho do desenvolvedor, o que é muito conveniente - não há necessidade de seguir outros links e procurar algo adicional.

Open Source

Este é o meu tema favorito. Todo mundo usa bibliotecas de código aberto - por que escrever um monte de muletas e bicicletas quando você pode pegar uma biblioteca pronta na qual tudo já está implementado?

Claro que isto é verdade, mas as bibliotecas também são escritas por pessoas, também incluem certos riscos e também existem vulnerabilidades que são periodicamente, ou constantemente, reportadas. Portanto, há o próximo passo na Segurança de Aplicações - esta é a análise dos componentes de Código Aberto.

Análise de código aberto - OSA

A ferramenta inclui três grandes etapas.

Procurando vulnerabilidades em bibliotecas. Por exemplo, a ferramenta sabe que estamos usando alguma biblioteca, e que em CVE ou existem algumas vulnerabilidades nos rastreadores de bugs relacionados a esta versão da biblioteca. Ao tentar utilizá-la, a ferramenta emitirá um aviso de que a biblioteca está vulnerável e aconselhará a utilização de outra versão que não possua vulnerabilidades.

Análise da pureza da licença. Isso ainda não é muito popular aqui, mas se você trabalha no exterior, de vez em quando poderá receber um imposto por usar um componente de código aberto que não pode ser usado ou modificado. De acordo com a política da biblioteca licenciada, não podemos fazer isto. Ou, se o modificarmos e usarmos, devemos postar nosso código. Claro, ninguém quer publicar o código de seus produtos, mas você também pode se proteger disso.

Análise de componentes que são utilizados em ambiente industrial. Vamos imaginar uma situação hipotética em que finalmente concluímos o desenvolvimento e lançamos a versão mais recente do nosso microsserviço. Ele mora lá maravilhosamente - uma semana, um mês, um ano. Não coletamos, não realizamos verificações de segurança, tudo parece estar bem. Mas de repente, duas semanas após o lançamento, uma vulnerabilidade crítica aparece no componente Open Source, que usamos nesta compilação específica, no ambiente industrial. Se não registrarmos o que e onde usamos, simplesmente não veremos essa vulnerabilidade. Algumas ferramentas têm a capacidade de monitorar vulnerabilidades em bibliotecas atualmente utilizadas na indústria. É muito útil.

Características:

• Diferentes políticas para diferentes estágios de desenvolvimento.
• Monitoramento de componentes em ambiente industrial.
• Controle de bibliotecas dentro da organização.
• Suporte para vários sistemas de construção e linguagens.
• Análise de imagens Docker.

Alguns exemplos de líderes do setor que estão envolvidos na análise de código aberto.

O único grátis é esse Verificação de dependência da OWASP. Você pode ligá-lo nos primeiros estágios, ver como funciona e o que suporta. Basicamente, são todos produtos em nuvem ou locais, mas por trás de sua base ainda são enviados para a Internet. Eles não enviam suas bibliotecas, mas hashes ou seus próprios valores, que calculam, e impressões digitais para seus servidores para receber informações sobre a presença de vulnerabilidades.

Integração de processos

Controle de perímetro de bibliotecas, que são baixados de fontes externas. Temos repositórios externos e internos. Por exemplo, o Event Central executa o Nexus e queremos garantir que não haja vulnerabilidades em nosso repositório com status “crítico” ou “alto”. Você pode configurar o proxy usando a ferramenta Nexus Firewall Lifecycle para que tais vulnerabilidades sejam eliminadas e não acabem no repositório interno.

Integração em CI. No mesmo nível dos autotestes, testes unitários e divisão em estágios de desenvolvimento: dev, test, prod. Em cada etapa você pode baixar qualquer biblioteca, usar qualquer coisa, mas se houver algo difícil com o status “crítico”, talvez valha a pena chamar a atenção dos desenvolvedores para isso na fase de lançamento em produção.

Integração com artefatos: Nexus e JFrog.

Integração no ambiente de desenvolvimento. As ferramentas escolhidas devem ter integração com ambientes de desenvolvimento. O desenvolvedor deve ter acesso aos resultados da verificação em seu local de trabalho ou a capacidade de escanear e verificar ele mesmo o código em busca de vulnerabilidades antes de se comprometer com o CVS.

Integração de CD. Esse é um recurso bacana que gosto muito e sobre o qual já falei - monitorar o surgimento de novas vulnerabilidades em ambiente industrial. Funciona mais ou menos assim.

Nós temos Repositórios de componentes públicos — algumas ferramentas externas e nosso repositório interno. Queremos que contenha apenas componentes confiáveis. Ao fazer proxy de uma solicitação, verificamos se a biblioteca baixada não possui vulnerabilidades. Se ele se enquadrar em determinadas políticas que definimos e necessariamente coordenamos com o desenvolvimento, não o carregamos e somos solicitados a usar outra versão. Conseqüentemente, se houver algo realmente crítico e ruim na biblioteca, o desenvolvedor não receberá a biblioteca na fase de instalação - deixe-o usar uma versão superior ou inferior.

• Na hora de construir, verificamos se ninguém escorregou nada de ruim, se todos os componentes estão seguros e se ninguém trouxe nada de perigoso no pen drive.
• Temos apenas componentes confiáveis ​​no repositório.
• Ao implantar, verificamos mais uma vez o próprio pacote: war, jar, DL ou imagem Docker para garantir que ele esteja em conformidade com a política.
• Ao entrar na indústria, monitoramos o que está acontecendo no ambiente industrial: vulnerabilidades críticas aparecem ou não.

Análise Dinâmica - DAST

As ferramentas de análise dinâmica são fundamentalmente diferentes de tudo o que foi dito antes. É uma espécie de imitação do trabalho do usuário com o aplicativo. Se for uma aplicação web, enviamos solicitações, simulando o trabalho do cliente, clicamos nos botões frontais, enviamos dados artificiais do formulário: aspas, colchetes, caracteres em diferentes codificações, para ver como funciona e processa a aplicação dados externos.

O mesmo sistema permite verificar vulnerabilidades de modelos em código aberto. Como o DAST não sabe qual código aberto estamos usando, ele simplesmente lança padrões “maliciosos” e analisa as respostas do servidor:

- Sim, há um problema de desserialização aqui, mas não aqui.

Há grandes riscos nisso, porque se você realizar esse teste de segurança na mesma bancada em que os testadores trabalham, coisas desagradáveis ​​podem acontecer.

• Alta carga na rede do servidor de aplicativos.
• Sem integrações.
• Capacidade de alterar as configurações do aplicativo analisado.
• Não há suporte para as tecnologias necessárias.
• Dificuldade de configuração.

Tivemos uma situação quando finalmente lançamos o AppScan: passamos muito tempo tentando acessar o aplicativo, conseguimos 3 contas e ficamos felizes - finalmente vamos verificar tudo! Iniciamos uma varredura, e a primeira coisa que o AppScan fez foi entrar no painel de administração, perfurar todos os botões, alterar metade dos dados e, em seguida, encerrar completamente o servidor com seu formulário de correio-solicitações de. Desenvolvimento com testes disse:

- Gente, vocês estão brincando comigo?! Nós lhe demos contas e você montou um estande!

Considere possíveis riscos. O ideal é preparar um estande separado para testar a segurança da informação, que ficará pelo menos de alguma forma isolado do resto do ambiente, e verificar condicionalmente o painel de administração, de preferência no modo manual. Este é um teste de invasão - aquelas porcentagens restantes de esforço que não estamos considerando agora.

Vale a pena considerar que você pode usar isso como um análogo do teste de carga. No primeiro estágio, você pode ativar um scanner dinâmico com 10 a 15 threads e ver o que acontece, mas geralmente, como mostra a prática, nada de bom.

Alguns recursos que costumamos usar.

Vale a pena destacar Suíte Burp é um “canivete suíço” para qualquer profissional de segurança. Todo mundo usa e é muito conveniente. Uma nova versão demo da edição empresarial foi lançada. Se antes era apenas um utilitário autônomo com plugins, agora os desenvolvedores estão finalmente criando um grande servidor a partir do qual será possível gerenciar diversos agentes. Isso é legal, recomendo que você experimente.

Integração de processos

A integração acontece muito bem e de forma simples: comece a digitalizar após a instalação bem-sucedida aplicações para o estande e digitalização após teste de integração bem-sucedido.

Se as integrações não funcionarem ou houver stubs e funções simuladas, é inútil e inútil - não importa o padrão que enviamos, o servidor ainda responderá da mesma maneira.

• Idealmente, uma bancada de testes separada.
• Antes de testar, anote a sequência de login.
• O teste do sistema de administração é apenas manual.

processo

Um pouco generalizado sobre o processo em geral e sobre o funcionamento de cada ferramenta em particular. Todos os aplicativos são diferentes - um funciona melhor com análise dinâmica, outro com análise estática, um terceiro com análise OpenSource, pentests ou algo completamente diferente, por exemplo, eventos com Waf.

Todo processo precisa de controle.

Para entender como um processo funciona e onde ele pode ser melhorado, você precisa coletar métricas de tudo que puder encontrar, incluindo métricas de produção, métricas de ferramentas e de rastreadores de defeitos.

Qualquer informação é útil. É preciso olhar de diferentes ângulos onde esta ou aquela ferramenta é melhor utilizada, onde o processo especificamente cede. Pode valer a pena examinar os tempos de resposta do desenvolvimento para ver onde melhorar o processo com base no tempo. Quanto mais dados, mais seções podem ser construídas desde o nível superior até os detalhes de cada processo.

Como todos os analisadores estáticos e dinâmicos possuem suas próprias APIs, seus próprios métodos e princípios de inicialização, alguns possuem agendadores, outros não - estamos escrevendo uma ferramenta Orquestrador AppSec, que permite criar um único ponto de entrada em todo o processo do produto e gerenciá-lo a partir de um ponto.

Gerentes, desenvolvedores e engenheiros de segurança têm um ponto de entrada a partir do qual podem ver o que está em execução, configurar e executar uma verificação, receber resultados da verificação e enviar requisitos. Estamos tentando nos afastar da papelada, para traduzir tudo em algo humano, que é usado pelo desenvolvimento - páginas no Confluence com status e métricas, defeitos no Jira ou em vários rastreadores de defeitos, ou integração em um processo síncrono/assíncrono em CI /CD.

Principais lições

As ferramentas não são o principal. Primeiro pense no processo e depois implemente as ferramentas. As ferramentas são boas, mas caras, então você pode iniciar o processo e construir comunicação e entendimento entre desenvolvimento e segurança. Do ponto de vista da segurança, não há necessidade de “parar” tudo, do ponto de vista do desenvolvimento, se há algo alto, mega supercrítico, então precisa ser eliminado, e não fechar os olhos para o problema.

Qualidade do produto - objetivo comum segurança e desenvolvimento. Fazemos uma coisa, tentamos garantir que tudo funcione corretamente e que não haja riscos reputacionais ou perdas financeiras. É por isso que promovemos uma abordagem DevSecOps, SecDevOps para melhorar a comunicação e melhorar a qualidade do produto.

Comece com o que você já tem: requisitos, arquitetura, verificações parciais, treinamentos, diretrizes. Não há necessidade de aplicar imediatamente todas as práticas a todos os projetos - mover iterativamente. Não existe um padrão único - experimentar e tente diferentes abordagens e soluções.

Existe um sinal de igualdade entre defeitos de segurança da informação e defeitos funcionais.

Automatize tudoisso se move. Tudo o que não se move, mova-o e automatize-o. Se algo for feito manualmente, não é uma boa parte do processo. Talvez valha a pena revisá-lo e automatizá-lo também.

Se o tamanho da equipe de SI for pequeno - use campeões de segurança.

Talvez o que eu falei não combine com você e você venha com algo de sua preferência - e isso é bom. Mas escolha ferramentas com base nos requisitos do seu processo. Não olhe para o que a comunidade diz, que esta ferramenta é ruim e esta é boa. Talvez o oposto seja verdadeiro para o seu produto.

Requisitos para ferramentas.

• Falso positivo de baixo nível.
• Tempo de análise adequado.
• A comodidade de uso.
• Disponibilidade de integrações.
• Compreender o roteiro de desenvolvimento de produto.
• Possibilidade de personalizar ferramentas.

O relatório de Yuri foi escolhido como um dos melhores na DevOpsConf 2018. Para conhecer ideias e casos práticos ainda mais interessantes, venha a Skolkovo nos dias 27 e 28 de maio DevOpsConf dentro de festival RIT++. Melhor ainda, se você estiver pronto para compartilhar sua experiência, então enviar um pedido para o relatório até 21 de abril.

Fonte: habr.com