Medo e ódio DevSecOps

Tivemos 2 analisadores de código, 4 ferramentas para testes dinâmicos, nosso próprio artesanato e 250 scripts. Não que tudo isso fosse necessário no processo atual, mas desde que comecei a implementar o DevSecOps, precisamos ir até o fim.



Fonte Autores dos personagens: Justin Royland e Dan Harmon.

O que é o SecDevOps? E o DevSecOps? Quais são as diferenças? Segurança de aplicativos - sobre o que é? Por que a abordagem clássica não funciona mais? Yury Shabalin, da Swordfish Security, sabe a resposta para todas essas perguntas . Yuri responderá tudo em detalhes e analisará os problemas de alternar do modelo clássico de Application Security para o processo DevSecOps: como abordar a integração do processo de desenvolvimento seguro no processo DevOps e não quebrar nada, como passar pelos principais estágios dos testes de segurança, quais ferramentas podem ser usadas, o que eles diferem e como configurá-los corretamente para evitar armadilhas.


Sobre o palestrante: Yuri Shabalin - Arquiteto Chefe de Segurança da Swordfish Security . Ele é responsável pela implementação do SSDL, pela integração geral das ferramentas de análise de aplicativos em um único ecossistema de desenvolvimento e teste. 7 anos de experiência em segurança da informação. Ele trabalhou no Alfa Bank, Sberbank e Positive Technologies, que desenvolve software e fornece serviços. Palestrante de conferências internacionais ZerONights, PHDays, RISSPA, OWASP.

Segurança de aplicativos: sobre o que é?

Segurança do aplicativo é a seção de segurança responsável pela segurança do aplicativo. Isso não se aplica à infraestrutura ou à segurança da rede, a saber, o que escrevemos e o que os desenvolvedores estão trabalhando - essas são as falhas e vulnerabilidades do próprio aplicativo.

A direção do SDL ou SDLC - ciclo de vida de desenvolvimento de segurança - foi desenvolvida pela Microsoft. O diagrama mostra o modelo SDLC canônico, cuja principal tarefa é a participação da segurança em cada estágio do desenvolvimento, desde os requisitos, até o lançamento e liberação na produção. A Microsoft percebeu que havia muitos erros no baile, havia mais deles e algo precisava ser feito, e propuseram essa abordagem, que se tornou canônica.



O Application Security e o SSDL não têm como objetivo detectar vulnerabilidades, como geralmente se acredita, mas impedir sua ocorrência. Com o tempo, a abordagem canônica da Microsoft foi aprimorada, desenvolvida e uma imersão detalhada mais profunda apareceu nela.



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

Criando segurança no modelo de maturidade

Gosto mais do BSIMM - Construindo Segurança no Modelo de Maturidade . A base da metodologia é a separação do processo de Segurança de aplicativos em 4 domínios: Governança, Inteligência, Pontos de contato SSDL e Implantação. Cada domínio possui 12 práticas, representadas como 112 atividades.



Cada uma das 112 atividades possui 3 níveis de maturidade : elementar, intermediário e avançado. Todas as 12 práticas podem ser estudadas em seções, selecionar coisas importantes para você, entender como implementá-las e adicionar gradualmente elementos, por exemplo, análise de código estático e dinâmico ou revisão de código. Você pinta o plano e trabalha com calma nele, como parte da implementação das atividades selecionadas.

Por que DevSecOps

O DevOps é um grande processo comum em que você precisa cuidar da segurança.

Inicialmente, o DevOps incluía verificações de segurança. Na prática, o número de equipes de segurança era muito menor do que agora, e elas agiram não como participantes do processo, mas como um órgão de controle e supervisão que define os requisitos e verifica a qualidade do produto no final do lançamento. Essa é uma abordagem clássica na qual as equipes de segurança estavam atrás do muro desde o desenvolvimento e não estavam envolvidas no processo.



O principal problema é que a segurança da informação é separada do desenvolvimento. Normalmente, este é um tipo de circuito IB e contém 2-3 ferramentas grandes e caras. A cada seis meses, chega o código-fonte ou aplicativo, que precisa ser verificado e, uma vez por ano, são produzidos pentestes . Isso tudo leva ao fato de que os prazos para a entrada no baile são adiados e um grande número de vulnerabilidades das ferramentas automatizadas cai sobre o desenvolvedor. Tudo isso não pode ser desmontado e reparado, porque os resultados dos seis meses anteriores não foram resolvidos e aqui está um novo lote.

No processo de nossa empresa, vemos que a segurança em todas as áreas e setores entende que é hora de se recompor e girar com o desenvolvimento em uma roda - no Agile . O paradigma DevSecOps se encaixa muito bem na metodologia de desenvolvimento ágil, na implementação, suporte e participação em cada release e iteração.

Transição para DevSecOps

A palavra mais importante no ciclo de vida do desenvolvimento de segurança é "processo" . Você deve entender isso antes de pensar em comprar ferramentas.

Apenas incorporar ferramentas no processo do DevOps não é suficiente - a interação e o entendimento entre os participantes do processo são importantes.

Mais importante que as pessoas, não ferramentas

Freqüentemente, o planejamento de um processo de desenvolvimento seguro começa com a seleção e compra de uma ferramenta e termina com tentativas de integrar a ferramenta ao processo atual, que continuam sendo tentativas. Isso leva a tristes conseqüências, porque todas as ferramentas têm características e limitações próprias.

Um caso comum em que o departamento de segurança escolheu uma ferramenta boa e cara, com ótimos recursos, e procurou os desenvolvedores - para incorporar no processo. Mas não dá certo - o processo é estruturado para que as limitações da ferramenta já adquirida não se encaixem no paradigma atual.

Primeiro, descreva qual resultado você deseja e como será o processo. Isso ajudará a entender os papéis da ferramenta e a segurança no processo.

Comece com o que já está em uso

Antes de comprar ferramentas caras, veja o que você já possui. Cada empresa possui requisitos de segurança para o desenvolvimento, há verificações, protestos - por que não transformar tudo isso em uma forma compreensível e conveniente para todos?

Normalmente, os requisitos são um Talmud de papel, que fica em uma prateleira. Houve um caso em que chegamos à empresa para ver os processos e pedir para mostrar os requisitos de segurança do software. O especialista que fez isso procurou por um longo tempo:

- Agora, em algum lugar nas notas havia uma maneira de encontrar este documento.

Como resultado, recebemos o documento uma semana depois.

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

É mais fácil reformatar o que já está lá e usá-lo para iniciar.

Use campeões de segurança

Geralmente, em uma empresa de médio porte para 100 a 200 desenvolvedores, um oficial de segurança trabalha, que executa várias funções e, fisicamente, não tem tempo para verificar tudo. Mesmo que ele tente o seu melhor, ele sozinho não verificará todo o código que o desenvolvimento gera. Para tais casos, um conceito foi desenvolvido - Security Champions .

O Security Champions é uma pessoa da equipe de desenvolvimento interessada na segurança do seu produto.

O Security Champion é o ponto de entrada para a equipe de desenvolvimento e o evangelista de segurança, tudo em um.

Geralmente, quando um cofre chega à equipe de desenvolvimento e indica um erro no código, ele recebe uma resposta surpresa:

"Quem é você?" Te vejo pela primeira vez. Estou indo bem - meu amigo mais velho no conjunto de revisão de código "aplicar", vamos mais longe!

Essa é uma situação típica, porque há muito mais confiança nos colegas de equipe sênior ou apenas, com quem o desenvolvedor interage constantemente no trabalho e na revisão de código. Se, em vez do guarda de segurança, o Campeão da Segurança indicar o erro e as consequências, sua palavra terá mais peso.

Além disso, os desenvolvedores conhecem seu código melhor do que qualquer provedor de 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 que e o que observar em primeiro lugar - eles são mais eficazes.

Portanto, pense em implementar os Security Champions e expandir a influência da equipe de segurança. Para o próprio campeão, isso também é útil: desenvolvimento profissional em um novo campo, ampliando os horizontes técnicos, aumentando as habilidades técnicas, gerenciais e de liderança, aumentando o valor de mercado. Este é um elemento da engenharia social, seus "olhos" na equipe de desenvolvimento.

Etapas de teste

O paradigma de 20 a 80 diz que 20% do esforço produz 80% do resultado. Esses 20% são práticas de análise de aplicativos 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 código aberto . Vou falar mais sobre atividades, bem como sobre ferramentas, quais recursos geralmente encontramos quando são introduzidos no processo e como fazê-lo corretamente.

Os principais problemas das ferramentas

Vou destacar os problemas que são relevantes para todas as ferramentas que requerem atenção. Vou analisá-los com mais detalhes para não repetir mais.

Análise de longo tempo. Se levar 30 minutos para concluir todos os testes e montagem, desde o commit até o prod, as verificações de segurança das informações levarão um dia. Portanto, ninguém irá desacelerar o processo. Considere esse recurso e tire conclusões.

Alto Falso Negativo ou Falso Positivo. Todos os produtos são diferentes, todos usam estruturas diferentes e seu próprio estilo de escrever código. Em diferentes bases e tecnologias de código, as ferramentas podem mostrar níveis diferentes de falso negativo e falso positivo. Portanto, veja o que exatamente na sua empresa e para seus aplicativos mostrará um resultado bom e confiável.

Não há integração com ferramentas existentes . Observe as ferramentas em termos de integrações para que você já esteja usando. Por exemplo, se você possui Jenkins ou TeamCity, verifique a integração de ferramentas com este software, e não com o GitLab CI, que você não usa.

A ausência ou complexidade excessiva de customização. Se a ferramenta não possui uma API, por que é necessária? Tudo o que pode ser feito na interface deve estar acessível por meio da API. Idealmente, a ferramenta deve ter a capacidade de personalizar verificações.

Nenhum desenvolvimento de produto de roteiro. O desenvolvimento não pára, sempre usamos novas estruturas e funções, reescrevemos o código antigo em novas linguagens. Queremos ter certeza de que a ferramenta que compramos oferecerá suporte a novas estruturas e tecnologias. Portanto, é importante saber que o produto possui um Roteiro de desenvolvimento real e adequado.

Recursos do processo

Além dos recursos das ferramentas, considere os recursos do processo de desenvolvimento. Por exemplo, interferir no desenvolvimento é um erro típico. Vamos ver quais outros recursos devem ser considerados e o que a equipe de segurança deve prestar atenção.

Para não interromper as datas de desenvolvimento e lançamento, crie regras diferentes e diferentes interruptores de exibição - critérios para interromper o processo de criação na presença de vulnerabilidades - para diferentes ambientes . Por exemplo, entendemos que o ramo atual vai para o estande de desenvolvimento ou UAT, portanto, não paramos e não dizemos:

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

Neste ponto, é importante informar aos desenvolvedores que há problemas de segurança que merecem atenção.

A presença de vulnerabilidades não é um obstáculo para mais testes : 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 esqueçam o que acham segurança. Portanto, às vezes fazemos isso: no estande, quando é lançado no ambiente de desenvolvimento, simplesmente notificamos o desenvolvimento:

- Gente, você tem problemas, por favor, preste atenção a eles.

No estágio do UAT, mostramos novamente avisos sobre vulnerabilidades e, no estágio de saída do baile, dizemos:

- Pessoal, já avisamos várias vezes, você não fez nada - não vamos deixar você sair com isso.

Se falamos sobre código e dinâmica, é necessário mostrar e alertar sobre vulnerabilidades apenas dos recursos e códigos que foram escritos neste recurso. Se o desenvolvedor moveu o botão 3 pixels e dizemos a ele que ele possui injeção SQL e, portanto, precisa ser corrigido com urgência, isso está errado. Veja apenas o que está escrito agora e a alteração que chega ao aplicativo.

Suponha que tenhamos um certo defeito funcional - a maneira como o aplicativo não deve funcionar: o dinheiro não é transferido; quando você clica no botão, não há transição para a página seguinte ou a mercadoria não carrega. Defeitos de segurança são os mesmos, mas não no contexto do aplicativo, mas 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 têm os mesmos defeitos, elas devem estar localizadas no mesmo local que todos os defeitos de desenvolvimento. Portanto, esqueça os relatórios e PDFs assustadores que ninguém lê.



Quando trabalhei para uma empresa de desenvolvimento, recebi um relatório das ferramentas de análise estática. Abri, fiquei horrorizada, fiz café, folheei 350 páginas, fechei e continuei a trabalhar. Grandes relatórios são relatórios mortos . Geralmente eles não vão a lugar algum, as cartas são excluídas, esquecidas, perdidas ou a empresa diz que corre riscos.

O que fazer Acabamos de transformar os defeitos confirmados que encontramos em um formato conveniente para o desenvolvimento, por exemplo, adicioná-los ao backlog em Jira. Priorizamos e eliminamos defeitos em ordem de prioridade, juntamente com defeitos funcionais e defeitos de teste.

Análise estática - SAST

Essa é uma análise de código para vulnerabilidades , mas não é a mesma coisa que o SonarQube. Verificamos não apenas padrões ou estilo. Na análise, várias abordagens são usadas: na árvore de vulnerabilidades, no DataFlow , na análise de arquivos de configuração. Tudo isso está diretamente relacionado ao código.

Vantagens da abordagem : identificar vulnerabilidades no código em um estágio inicial de desenvolvimento , quando não houver stands e uma ferramenta concluída, e a possibilidade de varredura incremental : varrer uma seção do código que foi alterada e apenas o recurso que estamos fazendo agora, o que reduz o tempo de varredura.

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

As integrações necessárias que deveriam 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 o desenvolvedor não entrar em uma interface incompreensível que ainda precisa ser lembrada, mas diretamente no local de trabalho em seu próprio ambiente de desenvolvimento para ver todas as integrações e vulnerabilidades necessárias que ele encontrou.
  
• 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 o processo; portanto, existem soluções de código aberto que também são boas para executar o processo.



O SAST Open Source não encontrará um grande número de vulnerabilidades ou DataFlow complexo, mas você pode e deve usá-las ao criar um processo. Eles ajudam a entender como o processo será construído, quem responderá aos bugs, quem denunciar, quem denunciar. Se você deseja executar o estágio inicial de criação da segurança do seu código, use soluções de código aberto.

Como isso pode ser integrado se você está no começo da estrada e não tem nada: nem CI, nem Jenkins, nem TeamCity? Considere a integração no processo.

Integração CVS

Se você possui Bitbucket ou GitLab, pode fazer a integração no nível do sistema de versões simultâneas .

Por evento - solicitação de recebimento, confirmação. Você digitaliza o código e mostra no status da compilação que a verificação de segurança foi aprovada ou falhou.

Feedback. Obviamente, o feedback é sempre necessário. Se você simplesmente se apresentou no lado da segurança, coloque-o em uma caixa e não conte a ninguém sobre isso e depois solte um monte de bugs no final do mês - isso não é certo nem bom.

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

Uma vez, em vários projetos importantes, definimos o revisor padrão do usuário técnico do AppSec. Dependendo se os erros foram detectados no novo código ou se não há erros, o revisor coloca o status em "aceitar" ou "precisa de trabalho" na solicitação de recebimento - tudo está OK ou você precisa refinar e vincular exatamente o que finalizar. Para a integração com a versão que vai para o prod, tivemos a proibição de mesclagem ativada se o teste IB não for aprovado. Incluímos isso em uma revisão manual de código, e outros participantes do processo viram status de segurança para esse processo específico.

Integração SonarQube

Muitos têm um portal de qualidade para a qualidade do código. A mesma coisa aqui - você pode fazer os mesmos portões apenas para as ferramentas SAST. Haverá a mesma interface, a mesma porta de qualidade, apenas será chamada de porta de segurança . E também, se você tiver um processo usando o SonarQube, poderá integrar facilmente tudo lá.

Integração de IC

Aqui também tudo é bem simples:

• No mesmo nível dos autotestes , testes de unidade.
  
• Separação por estágios de desenvolvimento : dev, test, prod. Diferentes conjuntos de regras podem ser incluídos ou diferentes condições de falha: pare a montagem, não pare a montagem.
  
• Início síncrono / assíncrono . Estamos aguardando o final do teste de segurança ou não. Ou seja, nós apenas os lançamos e seguimos em frente, e então recebemos o status de que tudo é bom ou ruim.
  

Está tudo em um mundo rosa perfeito. Na vida real, não é, mas nos esforçamos. O resultado das verificações de segurança deve ser semelhante aos resultados dos testes de unidade.

Por exemplo, pegamos um projeto grande e decidimos que agora o digitalizaremos com o SAST'om - OK. Introduzimos este projeto no SAST, ele nos deu 20.000 vulnerabilidades e, com uma decisão decidida, aceitamos que está tudo bem. 20.000 vulnerabilidades são nosso dever técnico. Colocaremos a dívida em uma caixa e, lentamente, coletaremos e iniciaremos bugs nos rastreadores de defeitos. Contratamos uma empresa, fazemos tudo sozinhos ou a Security Champions nos ajudará - e nossa dívida técnica diminuirá.

E todas as vulnerabilidades emergentes no novo código devem ser corrigidas, assim como os erros na unidade ou nos autotestes. Relativamente falando, a montagem começou, foi embora, dois testes e dois testes de segurança caíram. OK - eles foram, olharam o que aconteceu, corrigiram uma coisa, corrigiram a segunda, expulsaram na próxima vez - estava tudo bem, não havia novas vulnerabilidades, os testes falharam. Se essa tarefa for mais profunda e você precisar entendê-la bem, ou a correção de vulnerabilidades afeta grandes camadas do que está oculto: trouxeram um bug para o rastreador de defeitos, ela é priorizada e corrigida. Infelizmente, o mundo não é perfeito e, às vezes, os testes falham.

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

Integramos com o SonarQube - o plugin está instalado, tudo é muito conveniente e legal.

Integração do ambiente de desenvolvimento

Recursos de integração:

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

Parece algo como obter resultados do servidor.



Intellij IDEA , , . , Flow Graph . , — - .

Open Source

. Open Source — , , ?



, , , , , , . Application Security — Open Source .

Open Source — OSA

.

. , , - , CVE - - , . , , , .

. , , , . , . , , . , , .

, . , . — , , . , , . Open Source , , -. , , . , . .

:

• .
  
• .
  
• .
  
• .
  
• Docker-.
  

, Open Source.


— Dependency-Check OWASP. , , . , on-premise, . , , , , .

, . . , Event Central Nexus, , «» «». Nexus Firewall Lifecycle , .

CI . , - : dev, test, prod. , , , - «critical» -, .

: Nexus JFrog.

. , , . , CVS.

CD. , — . .



Public Component Repositories — , . , trusted components. , . , , . , - , — .

• build' , , .
  
• trusted components.
  
• : war, jar, DL Docker- , .
  
• , : .
  

— DAST

, . . -, , , , : , , , , .

Open Source. DAST , Open Source , «» :

— , , .

, , — .

• \ .
  
• .
  
• .
  
• .
  
• .
  

, AppScan: , 3 — - ! , , AppScan — -, , , mailform -. :

— , ?! , !

. , -, . — , .

, . 10-15 , , , , .

, .



Burp Suite — « » . , . - enterprise edition. stand alone , - , . , .

: .

mock-, — , .

• — .
  
• .
  
• — .
  

, . — , , OpenSource, - , , Waf .

.

, , , , -.

. , , . , , . , .



API, , , , — AppSec , .

, security- , , , , , . , , — Confluence , Jira -, / CI/CD.

Key Takeaways

. — . , , . — «» , — - high mega super critical, , .

— , . , , . DevSecOps, SecDevOps, .

, : , , , , . — . — .

.

, . , — . - , . , .

— Security Champions .

, , , - — . , . , community, , . , .

.

• False Positive.
  
• Tempo de análise adequado.
  
• Facilidade de uso.
  
• Disponibilidade de integrações.
  
• Noções básicas sobre desenvolvimento de produtos de roteiro.
  
• A capacidade de personalizar ferramentas.
  

O relatório de Yuri foi escolhido como um dos melhores do DevOpsConf 2018. Para se familiarizar com idéias e casos práticos ainda mais interessantes, visite Skolkovo nos dias 27 e 28 de maio no DevOpsConf como parte do festival RIT ++ . Melhor ainda, se você estiver pronto para compartilhar sua experiência, solicite um relatório até 21 de abril.