DevSecOps Eficaz
A segurança não é apenas documento com regras e políticas, instruindo o que desenvolvedores e operadores devem seguir. Segurança não se trata de pessoas discutindo sobre quem faz parte da equipe de segurança cibernética, na qual ninguém sabe o que está acontecendo em relação aos projetos ou em que ninguém está ajudando para que o desenvolvimento e as operações estejam seguras.
Bem, às vezes, a equipe de segurança de nossa empresa aplica regras e políticas por meio de reuniões ou perguntando via e-mail ou chat como está a segurança. Em casos mais sérios, quando ocorre o vazamento de informações, a equipe se mobiliza para achar o culpado. Esta é uma maneira comum de se expor a hackers.
A segurança deve receber atenção constante, em todos os momentos, por todas as pessoas.
Primeiramente, concentrar a segurança da empresa inteira em uma única equipe é um grande erro. A segurança é responsabilidade de todas as pessoas. Cada pessoa que possua negócios diretos ou indiretos com a nossa empresa deve se preocupar.
Após observar muitos erros sobre o que é DevSecOps, elaborei este artigo, que mostra como ser eficiente no processo DevSecOps e como fugir de abordagens erradas.
Aplicação de Regras e Políticas
Muito bem. Precisaremos de documentações que nos instruam sobre o que devemos fazer, mas a aplicação não deve ser realizada de maneira reativa, durante uma discussão ou em um coffee break. Mais uma vez, reforçamos que deixar a segurança nas mãos de uma única equipe não surtirá efeitos. A aplicação deve ser realizada por meio de um software com essa finalidade e incorporada no Pipeline de DevOps.
Temos diversas ferramentas e abordagens para fazer valer nossas regras e políticas. Neste artigo, demonstrarei como ser eficiente ao iniciar uma iniciativa de DevSecOps e como obter resultados.
Para que os objetivos sejam cumpridos, devemos adotar os seguintes passos:
1. Definir o alvo
2. Criar um blueprint
3. Transmitir
4. Aplicar
5. Medir
Estou presumindo que a empresa já possua um alto nível de conhecimento em DevOps.
Definir o alvo
Para traçarmos uma direção, devemos estabelecer nossos objetivos e alvos. Sem eles, não teremos um norte.
Vamos expor alguns exemplos e utilizá-los como metas neste artigo.
· Sem exposição de informações confidenciais: Garanta que nenhuma senha, frase secreta, cadeia de certificado ou chave pessoal sejam vazadas.
· Sem certificados expirados: Não deixe que certificados TLS expirem.
· Sem biblioteca desatualizada: Verifique as dependências dos projetos, assim como as bibliotecas dos sistemas operacionais, serviços e utilitários.
· Sem vulnerabilidade de códigos: Verifique estaticamente o código-fonte em busca de vulnerabilidades e erros.
· Conformidade com o OWASP Top 10: Verifique dinamicamente o aplicativo em execução em busca de vulnerabilidades.
Uma vez que há muitos alvos, vamos ver mais exemplos: nenhum processo autorizado, nenhuma porta autorizada, nenhuma biblioteca com bug, nenhum repositório autorizado, gerenciamento do final de vida útil, nenhuma conta autorizada, conformidade com Vulnerabilidades e Exposições Comuns — CVE, gerenciamento de vulnerabilidades, TLS Everyuwhere etc.
Criar o blueprint
A etapa do blueprint é importantíssima, pois ele auxiliará a definir “como” serão os desenvolvimentos e as operações e como a segurança está relacionada a estes dois fatores. Neste blueprint, definiremos as regras e como elas serão aplicadas, preparando, assim, a empresa para os próximos passos.
Vamos observar o diagrama para entender o blueprint de nossos alvos definidos.
O diagrama acima expõe 4 blocos para auxiliar no mapeamento de nossos alvos: Gestão Secreta, Qualidade de Código SAST, Reforço, Executar o SAST de Qualidade. Porém, para realizar sua iniciativa DevSecOps, serão necessários outros diagramas para mapear seus alvos.
Observação: Mostro apenas alguns alvos e blocos de construção para que o artigo não fique cansativo.
Agora, crie um espaço em sua wiki e elabore tópicos concisos, explicando cada detalhe do blueprint e destacando os seguintes pontos:
· Conecte o blueprint aos alvos
· Detalhe os blocos de construção
· Como eles serão aplicados
· Quais são as ferramentas
· Segurança em primeiro lugar
· Foco na segurança
· Exceções
· Como manter a conformidade
· O roteiro
Como é possível observar acima, devemos mapear cada bloco de construção nas etapas de nosso pipeline. Isso nos ajudará a aplica-los, além de coletar a métrica e como emprega-la em nossos projetos.
Transmitir
As pessoas devem saber.
Agora, devemos fazer o marketing desta nova iniciativa. O blueprint não ajudará se as pessoas não souberem como utilizá-lo.
Primeiro, reúna os melhores patrocinadores. Eles comprarão o blueprint e auxiliarão no crescimento. Nunca faça uma mudança dessa magnitude no formato big bang, pois isso não funcionará.
As pessoas devem conhecer e entender os benefícios, e como é importante manter a conformidade com o blueprint do DevSecOps, uma vez que todos possuem papeis importantes. Para realizar uma transmissão satisfatória, sua empresa deve fazer o seguinte:
· Informe a todos sobre o roteiro. Espalhe-o por meio de banners, intranet, vídeos, sinais digitais etc.
· Crie presentes: camisetas, garrafas, adesivos, bonés
· Observe quais são as primeiras pessoas a adotá-lo
· Realize workshops
· Realize reuniões internas
· Mostre os benefícios
· Auxilie as equipes a manterem a Segurança
Boas soluções são baseadas em boa comunicação e em um marketing bem feito. Os resultados não aparecem se as pessoas não souberem como manter a segurança. Elas devem saber o que é certo e o que é errado ao criarem um software ou quando provisionarem e configurarem uma infraestrutura.
Reforçar
Agora, reforçaremos as regras e políticas. Todos sabem como manter a segurança e estão preparados para aplicar as regras e políticas.
Não é humanamente possível atender à demanda, por isso, devemos aplicar o reforço em nosso pipeline, seja para software ou para infraestrutura. Adotaremos ferramentas e sistemas automáticos para realizar essa tarefa para cada alvo definido. Analisaremos ferramentas para cada um.
Não mostrarei nenhuma ferramenta proprietária, mas é possível encontrar alternativas pagas em sites como o stackshare.io.
Não expor informações confidenciais
Tais informações são: senhas, frases secretas, chaves pessoais, contas de base de dados, tokens.
Para preservar as informações, não devemos salvá-las em arquivo comuns, dentro do repositório git e sem senhas perpétuas. Para resolver quase todos esses problemas, devemos empregar uma ferramenta de segurança para gerenciar cada uma das informações confidenciais.
Uma ferramenta de segurança deve, obrigatoriamente, gerenciar o ciclo de vida de informações confidenciais, mitigando os riscos em caso de vazamento. Uma ferramenta mais aperfeiçoada pode gerenciar muitos tipos diferentes de credenciais, como: banco de dados, sistema operacional, provedores de nuvem etc. Além disso, ela pode oferecer recursos e métodos para que consumidores obtenham acesso a tais informações por meio de API.
· HashiCorp Vault para gerenciar informações confidenciais
· Gitrob para verificar repositórios Git em busca de vulnerabilidades
Se você tiver de utilizar informações confidenciais em seu pipeline, SSH Key, utilize direto de seu servidor de automação (por exemplo, Jenkins).
Não deixe que certificados expirem
Nos dias de hoje, o TLS é obrigatório. Por isso, devemos gerenciar a expiração de certificados para evitar erros de SSL handshake.
Adote uma ferramenta para monitorar todos os certificados dentro (domínio privado) e fora (domínio público) da empresa.
· Sensu para verificar o certificado TTL
· HashiCorp Vault para gerenciar os certificados de nosso domínio privado
O Sensu não possui a funcionalidade de verificação nativa. Porém, existe um plugin que oferece essa funcionalidade, além do que, permite que ele monitore outros alvos. Clique e veja.
Não deixe a biblioteca desatualizada
Uma empresa possui diversos projetos em desenvolvimento e em andamento. É possível que bibliotecas desatualizadas sejam utilizadas quando uma equipe começa a desenvolver um novo microsserviço, por exemplo. Bem, nós não podemos permitir isso.
Observação: Escrevi “…quando uma equipe começa a desenvolver um novo…” porque devemos ser cuidadosos ao reforçar projetos que impactem a produção ou as missões.
Nunca imponha algo para um projeto somente para agradar alguém. Trabalhe com as equipes, compreenda o impacto dessas novas regras e evite confusões.
As ferramentas disponíveis para realizar este trabalho são específicas para a plataforma e linguagem do projeto. Porém, essas ferramentas devem nos auxiliar a identificar bibliotecas desatualizadas ou que apresentem bugs.
· OWASP Dependency Check: use para projetos java e para projetos .net.
· RetireJS: use para projetos js.
Devemos criar uma etapa em nosso pipeline para aplicar este alvo em cada construção. Isso garante que nenhuma dependência desatualizada, não autorizada ou com erro seja despercebida.
Para aplicar este alvo no servidor, podemos empregar ferramentas como Chef e Inspect para gerenciar as configurações e manter a estabilidade. Essas ferramentas atuam no nível do sistema operacional para manter a conformidade e geralmente exigem um agente instalado no host.
Não deixe os códigos vulneráveis
Também conhecido como SAST: Teste de Segurança de Aplicativo Estático.
Este alvo procura por erros, má utilização, possíveis falhas de memória, loopings infinitos, ou seja, tudo que pode causar vulnerabilidade. Uma ferramenta bem conhecida para sanar estes problemas é o SonarQube, que possui diversas maneiras de verificar os arquivos fonte em busca de erros e má utilização, além de poder ser usado em diversos idiomas.
· Infer by Facebook: outra opção fornecida pelo Facebook, em que podemos verificar Java, C/C++ e Object-C.
Manter a conformidade com o OWASP Top 10
O Open Web Application Security Project — OWASP — é uma organização de caridade sem fins lucrativos, focada em melhorar a segurança de software. (fonte).
O OWASP Top 10 reúne os 10 maiores riscos de segurança — sua última atualização foi em 2017 (verifique todos aqui). Esse top 10 funciona como uma orientação e fornece os melhores aplicativos de segurança da Web. Muitas ferramentas seguem estas orientações e aplicam suas próprias verificações. Indicarei duas boas ferramentas:
· OWASP ZAP: a implementação referência do OWASP
· IronWASP: uma boa opção de código aberto
Medir
Conheça os números e veja os resultados.
As medições são importantes para entender o quanto a iniciativa DevSecOps é eficaz. Sem elas, ficamos sem orientação.
Existem ótimas opções de código aberto para obter métricas e apresentá-las. Sou um grande fã do Grafana, que apresenta as métricas de forma prática. Para armazená-las, eu sugiro o InfluxDB, que pode ser integrado ao nosso pipeline e englobar cada medida. Além disso, o Grafana e o InfluxDB possuem ótima integração.
O que pode ser medido?
· Informações confidenciais encontradas em repositórios Git
· Certificados expirados
· Tempo restante para renovar um certificado expirado
· Dependências desatualizadas
· Sistemas operacionais de bibliotecas desatualizadas
· Vulnerabilidades encontradas no código-fonte
· As 10 maiores vulnerabilidades encontradas no APP
É só isso, pessoal! É assim que penso que o DevSecOps pode ser eficiente. Se você gostou, deixe o seu aplauso e a sua opinião!
O DevSecOps é muito utilizado. Porém, sempre tente mais fazer do que falar, porque falar é fácil, como foi dito por Linus.
by: Fábio José
