E se dissermos que boa parte dos problemas de segurança poderiam ser evitados? Neste artigo, vamos abordar a importância da segurança da informação e como incluí-la em todo o processo do desenvolvimento: o chamado DevSecOps.
Nos últimos tempos, testemunhamos diversas falhas de segurança da informação ao redor do mundo: vulnerabilidades, ransomware, Man-in-the-middle, dentre outros problemas. Engana-se quem pensa que isso é uma dor de cabeça só para o time de engenharia, já que os impactos de falhas de segurança podem ser sentidos na empresa toda e até em clientes do seu produto.
Artigo escrito por Otávio Santana e Mariana Moreira.
3 mitos em torno de segurança da informação
Existem três tabus na área de desenvolvimento de software que precisamos falar para a abordar segurança da informação de forma mais constante:
1 – Brechas de segurança serem, muitas vezes, vistas como um problema apenas para empresas grandes
O primeiro deles é o mais simples para falar: a maioria das falhas de segurança e de seus respectivos impactos e prejuízos são comumente relacionadas a grandes empresas, como Facebook, Linkedin, dentre outras.
No entanto, esse não é um problema exclusivo de empresas de grande porte, tanto que existe um estudo da codegrip que relata que três em cada quatro aplicações em uso, atualmente, apresentam algum tipo de vulnerabilidade.
2 – Vulnerabilidade não geram prejuízo para as empresas
Segundo o último relatório de pesquisa de vulnerabilidades da IBM, essa ideia está longe de ser verdade. Para você ter ideia, cerca de 38% dos negócios foram perdidos pelas empresas que tiveram alguma falha de segurança. Além disso, existem algumas estimativas médias de prejuízo:
- Média de 180 USD por cada registro de informação pessoal.
- 4.62 milhões de dólares foi a média de brecha de ransomware.
- 3.61 milhões de dólares por cada violação de ambientes de nuvem híbrida.
Na prática, a vulnerabilidade também impacta na confiança e na credibilidade da marca. Um exemplo recente foi da Target, que precisou desembolsar cerca de 200 milhões de dólares para remediar a sua credibilidade.
3 – Problemas de segurança são oriundos de grandes erros
De todos os mitos, esta é a maior falácia de todas! No geral, os “menores problemas” são os que, justamente, resultam nos maiores desastres de segurança e podemos afirmar que as falhas costumam apresentar duas brechas:
- Através de uma vulnerabilidade de código de maneira intencional ou não-intencional: dentro do TOP 10 demonstrado pelo OWASP, encontramos falhas como problemas de configuração, de injeção e de design de código inseguro.
- Através da vulnerabilidade de operações: dentre os problemas mais comuns, podemos citar escolha por “senhas fracas”, padrão ou mesmo a falta de senha. Uma segunda falha comum é a de má gestão de permissionamento de pessoas a um documento ou sistema. Esses tipos de problemas, infelizmente, são bem corriqueiros, não por acaso 75% dos servidores redis têm problemas desse tipo.
Em uma analogia, podemos dizer que falhas de segurança são como o caso do Titanic. Considerado um dos maiores naufrágios, o que a maioria das pessoas desconhece é que o navio teve um “pequeno problema”: a falta de uma simples chave que poderia ter aberto o compartimento com binóculos e demais aparelhos que ajudariam a tripulação visualizar o iceberg a tempo e impedir a colisão.
Conhecendo a tríade da segurança
Entendemos a importância da segurança da informação e o grande impacto da sua ausência. Com isso, fica a dúvida: como definir se uma aplicação é segura?
De forma resumida, existe um acrônimo de uma aplicação segura baseado na ISO 27002, que é CIA, focado três propriedades:
- Confiabilidade: a garantia de que uma mensagem será entregue à pessoa que, de fato, precisa receber aquela informação.
- Integridade: a garantia de que a informação foi entregue sem nenhuma alteração ao longo do caminho.
- Disponibilidade: a garantia de que a informação precisa estar sempre disponível para o usuário legítimo.
Para exemplificar, uma analogia. Se o Titanic fosse uma “aplicação falha”, o que aconteceu foi um problema na propriedade A (Disponibilidade), uma vez que a chave que garantia o acesso aos binóculos não estava à disposição para o time à frente da embarcação.
Entendendo a segurança da informação como metodologia: o DevSecOps
Uma vez que entendemos os princípios de segurança, temos de entender o “como” incorporá-las na rotina das nossas aplicações. Afinal, de que forma vamos garantir que cada entrega/deploy não possua problemas de vulnerabilidades?
Uma das soluções é aumentar a integração entre os times, evitando o atraso de feedback e, principalmente, fazendo com que a segurança da informação aconteça de forma proativa e não reativa, como costuma acontecer.
A resposta para isso é o DevSecOps, cujo foco é adicionar a camada de segurança à operação de desenvolvimento. Pensar nesta metodologia é mais um passo na história da integração entre times.
- Agile: oriundo do manifesto ágil de 2001, esta metodologia foca na integração entre o time de desenvolvimento com a equipe de produtos.
- DevOps: em um próximo passo de integração, é adicionado o time de operações dentro do já integrado time de desenvolvimento e de usuário.
- DevSecOps: por fim, é adicionado o time de segurança aos times já existentes no DevOps.
Definições de DevSecOps
Como mais uma nomenclatura de metodologia, é natural que existam diversas definições para o mesmo termo. Algumas delas:
- DevSecOps: A leader’s guide to producing secure software: DevSecOps é o DevOps feito de forma segura.
- Hands-On Security in DevOps: o DevOps oferece benefícios de velocidade e qualidade com métodos contínuos de desenvolvimento e implantação, mas não garante a segurança de uma organização inteira.
- DevSecOps pela RedHat: quer você o chame de “DevOps” ou “DevSecOps”, sempre foi ideal incluir a segurança como parte integrante de todo o ciclo de vida do aplicativo.
Mas indiferente da definição que se tenha preferência, o grande ponto é que com o DevSecOps precisamos incorporar a segurança da informação como parte do processo.
Em outras palavras: a segurança em camadas, pensando desde o usuário final, passa pela o time de engenharia, até as configurações de banco de dados e sistemas operacionais.
Automatização da segurança e suas ferramentas
Além da segurança em camadas, outro cerne da metodologia é a automatização da segurança, já que quando estamos no meio de uma esteira de desenvolvimento, a tendência é que nós esqueçamos aquilo que fatalmente tínhamos de lembrar.
As ferramentas de segurança da informação podem ser integradas de CI/CD, ou seja, caso exista alguma falha, ela pode quebrar a build. Dentro das categorias das ferramentas de segurança, podemos listar alguns:
- SAST (Static application security testing): é o tipo de ferramenta que varre o código, de forma estática, e faz a análise do código antes da compilação.
- DAST (Dynamic Application Security Testing): ferramenta que realiza validações no código em momento de execução.
- IAST (Interactive Application Security Testing): executa testes de aplicação a partir de uma aplicação executada. A maior diferença do IAST, em relação ao DAST, é que os testes são realizados dentro da aplicação.
Quer saber mais sobre DevSecOps? Então acompanhe a talk “DevSecOps: integrando segurança no pipeline de desenvolvimento”, com Magno Logan que aconteceu na Trilha da Zup no TDC Innovation 2021. Tá imperdível.
Como o Horusec pode te ajudar a adotar a metodologia DevSecOps no seu projeto
De modo geral, estas ferramentas auxiliam na detecção de vulnerabilidades, monitoram bugs e, principalmente, evitam problemas de segurança.
Entre as ferramentas no mercado, temos o Horusec, um dos projetos Open Source mantidos pela Zup e que tem por foco deixar sua aplicação mais segura e prevenir vulnerabilidades de código.
Um dos seus diferenciais é a sua característica de orquestração. Isto é, ele permite a integração de mais ferramentas, afinal, quanto mais segurança melhor!
O Horusec possui ainda um dashboard, que auxilia os times a entenderem os problemas de segurança dentro da aplicação.
É possível integrar com o Horusec de diversas formas, por exemplo, com uma CI como Github Action, e o seu resultado ser exportado para o dashboard. A prevenção é o segredo, o que significa que caso um Pull Request possua uma vulnerabilidade, o build “quebra”, evitando uma futura dor de cabeça ou um próximo desastre de vulnerabilidade seja mergeado em ambiente de produção.
Atualmente, o Horusec possui três componentes:
- CLI, ou o clássico terminal, que permite a execução da análise e da visualização de vulnerabilidades direto pelo terminal.
- Dashboard, ou Horus-Manager, é um recurso opcional que permite a visualização dessas vulnerabilidades de maneira mais intuitiva que o terminal.
- Extensão para IDE: também opcional, mas que pode facilitar a análise de vulnerabilidades ao fazê-la da própria IDE. Hoje, temos a extensão para utilizar o Horusec no Visual Studio Code.
Uma boa primeira experiência é a instalação tanto do CLI quanto do dashboard, mas não se preocupe que você encontra todas as informações na documentação oficial. Em seguida, você pode analisar este repositório que contém diversas vulnerabilidades e em várias linguagens de programação.
Contar com ferramentas como o Horusec permite que nós, como profissionais de desenvolvimento, tenhamos uma maior confiança na criação de um código mais seguro e sem vulnerabilidades.
DevSecOps e segurança da informação: cada vez mais importantes
E aí, gostou de conhecer mais do universo de segurança da informação?
A nossa ideia foi dividir um pouco sobre conceitos, a metodologia DevSecOps e, em especial, como evitar pequenos erros que podem gerar gigantescas dores de cabeça na segurança da sua aplicação.
Você também pode conhecer mais dos projetos Open Source da Zup participando no nosso fórum!
