Na Invillia, toda quarta-feira, ao meio-dia, paramos uma hora para nos nutrir com as dicas, how-tos, boas práticas e tendências selecionadas por nossos especialistas em Product, Agile, Back e Front, Mobile, Quality, Security e Data. Uma troca de experiência vital para quem adora o novo e essencial para que a inovação nunca pare. Se a tecnologia está no sangue, a gente faz questão de deixá-la circulando cada vez mais_
NA VEIA_ Vulnerabilidade x Requisitos Shift Security Left
10 minutos de leitura
No artigo de hoje, compartilhamos os principais aprendizados da incrível edição sobre Vulnerabilidade x Requisitos Shift Security Left, apresentada por Fernando Costa, nosso especialista no assunto.
Planejamento: Shift left
O Shift left é um conceito que busca trazer as preocupações de segurança mais para o início do processo, ou como o próprio nome diz, “mudar para a esquerda” dentro do ciclo de desenvolvimento. Nesta ideia, deixa-se de pensar somente em identificar e tratar vulnerabilidades – como é o mais comum de se encontrar hoje no mercado –, realizando um Pentest (teste de invasão) antes do produto ser entregue ao cliente, e passando a olhar para os requisitos de segurança, planejando as aplicações de forma segura, inserindo aspectos de segurança desde o projeto, e durante todo o processo de codificação até a entrega.
O Shift left, além de trazer mais robustez e confiabilidade para as aplicações, atua na redução de tempo e custos na produção, uma vez que os processos de segurança que naturalmente são inseridos durante todo o processo de produção, reduzem drasticamente o número de vulnerabilidades geradas, deixando de atrasar a entrega em virtude de correções que não são mais necessárias.
A nova cultura DevSecOps
DevSecOps é uma mudança cultural que vem do DevOps, ou seja, uma modificação da cultura DevOps que inclui a segurança no ciclo de desenvolvimento. Esta cultura inclui diversas técnicas, processos, ferramentas e modelos que se inserem nas fases do DevOps para que se crie um ciclo de desenvolvimento seguro. Então não se fala mais só do ciclo de desenvolvimento do produto, mas do ciclo de desenvolvimento “seguro”.
Há muitas opções na fase de planejamento e desenvolvimento, como, por exemplo: modelagem de ameaças, security code review e uma série de atividades inseridas em cada fase e que vão trazer, no final da história, um software seguro através do ciclo de desenvolvimento seguro.
No final, quando for realizado um teste de produto que passou por este ciclo, o número de vulnerabilidades diminui drasticamente. O mais comum é que, em aplicações oriundas de um ciclo de desenvolvimento seguro, encontram-se pouquíssimas ou nenhuma vulnerabilidade, dificultando a exploração e melhorando o produto como um todo. Por isso, quando se insere a segurança dentro do ciclo e não só no fim, há a garantia de entregar um software seguro.
Apesar de não existir um software “inabalável” e 100% seguro em nenhum cenário, por definição de “software seguro” entende-se um software que passou por um ciclo de desenvolvimento que contempla aspectos de segurança em todas as fases. Neste caso, entre as principais fases do DevSecOps, o mais importante é destacar a fase de planejamento e desenvolvimento por meio das principais ações, ou seja, verificar na ponta da linha na esquerda do processo (shift-left), os principais controles de segurança que devem ser atendidos durante a produção do software.
Modelagem de ameaças (Threat Modelling)
A modelagem de ameaças (Threat Modelling) foca em olhar para o projeto da aplicação – na fase de planejamento – e considerar como se estivesse num cenário real, criando todas as simulações de ataque possíveis dentro da aplicação, e considerando aspectos tais como: o impacto, tipo de ameaça, infraestrutura etc.
Assim, no final da história da modelagem de ameaças é necessário olhar para as ameaças que a aplicação será envolvida enquanto estiver em produção, o que possibilita a obtenção de requisitos funcionais e não funcionais de segurança que serão consumidos pelo time.
Neste caso, o X da questão não é só a vulnerabilidade, mas os requisitos. Não se fala do final do produto, mas de seu início e planejamento. Com isso, o software é construído de maneira sedimentada, com pilares de segurança criteriosos.
Neste momento, o profissional de segurança pode sugerir uma autenticação multifatorial e, se tiver um canal de comunicação sensível, sugerir o uso de criptografia, trazendo coisas mais pontuais como, por exemplo: no campo de senha é desejável utilizar, no mínimo, 12 caracteres com combinação de maiúsculas e minúsculas. Sua função é trazer os requisitos para que a aplicação seja construída de forma planejada. Por isso, a modelagem de ameaças é uma atividade exclusiva de um profissional de segurança.
IDE Security Plugins para o desenvolvimento
Para o desenvolvedor, os plug-ins são essenciais para prover a segurança durante o processo de desenvolvimento, sendo inseridos nas IDEs para a construção do código.
O “Sonarlint” – conhecido pela maioria dos desenvolvedores – é uma ferramenta essencial que aponta, por exemplo, quando um desenvolvedor cria um par de chaves com 1024 bits que já é considerada vulnerável. Neste caso, o próprio “sonarlint” sugere a criação de uma chave forte com 2048 bits.
Isso significa que, durante a codificação, já se tem duas vantagens: evitar o risco de gerar a vulnerabilidade e permitir o aprendizado constante. Além disso, existem tantas outras opções e ferramentas, inclusive para mobile, como o plugin de IDE para Android e Swift.
Configuração de repositório personalizada: Pré-Commit Hooks
Assim como o lint não é exclusivo de segurança – já que também pode ser utilizado para a qualidade – os Pré-Commit Hooks funcionam, basicamente, como uma configuração de repositório, através de scripts personalizados, com o objetivo de realizar alguma atividade ao submeter o código para a ferramenta. E, neste ponto, ele é essencial para a segurança, porque o time pode pré-configurar opções automatizadas, a fim de evitar falhas que podem passar despercebidas pelo programador durante a validação.
Um uso bastante comum de sua configuração é justamente para evitar o vazamento de credenciais. A falha recorrente é deixar as credenciais ou chaves de acesso em banco de dados, nuvem e token, diretamente no código, o que torna arriscado e crítico o seu uso.
A sugestão universal é sempre utilizar os secrets manager – popularmente conhecidos como “cofres de senha” – para que as credenciais não estejam expostas em repositórios públicos ou privados (que por alguma falha humana podem ser expostas).
Por isso, para evitar esse tipo de vazamento de dados, os Pre-commit Hooks são muito úteis para interromper e não permitir que o commit prossiga, alertando que foi “commitada” uma credencial diretamente em código. Por isso, sempre sugere-se a revisão de código para que além da exposição de credenciais outras vulnerabilidades possam ser evitadas.
Security Coding Standards – os mais utilizados
As normas e padrões de segurança são muito importantes e cada cenário tem sua especificidade, dentre os quais os mais utilizados são:
- OWASP TOP 10
Atualmente, este é um pré-requisito básico para qualquer desenvolvedor completo. Afinal, não adianta desenvolver um produto que atende aos requisitos funcionais em termos de usabilidade e qualidade, mas entregar um produto vulnerável que traz problema para a empresa, ou seja, sem segurança. (Para quem quer começar e não sabe nenhum padrão, basta começar pelo OWASP TOP 10 e depois que estiver dominando, buscar outros padrões e normativas.)
- OWASP ASVS ou MASVS
Padrão desenvolvido pela OWASP que contempla uma lista de requisitos e controles de segurança de aplicações a fim de garantir que os controles tenham sido implementados durante o ciclo de desenvolvimento.
- Melhores práticas de codificação segura da OWASP
Basicamente um checklist ou guia rápido utilizado para verificar se o time cometeu alguma falha, erro ou deixou passar alguma coisa durante o processo de codificação.
- PCI Security Standars Council (PCI, DSS, PA DSS, entre outros)
Bastante conhecida para aqueles que trabalham com cartão de crédito e dados financeiros de diversos tipos que funcionam como normas para uso e armazenamento de dados nas aplicações, ou seja, para dados sensíveis e de uso pessoal. Isso é importante quando as empresas têm que buscar parceria com as bandeiras de cartão de crédito e são obrigadas a ter compliance – medidas de segurança para armazenamento desse tipo de dado – seguindo as normativas da PCI.
- SEI CERT Coding Standars
Indicada para organizações que trazem padrões para cada tipo de cenário e área (tais como área da saúde etc.).
Peer Security Review: mapeamento colaborativo
Costumeiramente conhecido como Peer Review, esta ferramenta está presente em quase todos os times e envolve a revisão de boas práticas de segurança, com padrões específicos do produto. Para isso, é necessário fazer uso de wiki (confluence) contendo atividades relacionadas ao projeto e dicas de segurança em um local que todos tenham acesso para posterior revisão do código de acordo com as premissas elencadas.
A maior parte das empresas com alto nível de segurança tem uma wiki/confluence bem adotada para a condução do desenvolvedor. Além disso, utiliza-se as ferramentas de automatização que auxiliam, não somente como um lint – que verifica seu código em tempo de codificação –, mas também com um “scanner” no código para verificar os arquivos da máquina e suas vulnerabilidades. As ferramentas que auxiliam este processo – tais como Sonarqube, Findbugs, Android Lint etc. – são capazes de fazer essas varreduras por vulnerabilidades automaticamente.
Paralelamente a isso, os requisitos trazidos pela modelagem de ameaças para o Peer Security Review auxiliam na validação dos requisitos de segurança, pois quando há um requisito levantado e implementado naquela história, nada mais útil do que se atentar aos critérios de aceite para confirmar os requisitos de segurança que estão sendo contemplados.
Para isso, é necessário fazer um checklist de requisitos sobre a aplicação ou aquela história que está sendo atendida.
Mas se eu não tenho modelagem de ameaças e, consequentemente, nenhum requisito de segurança, como faço com meu time?
A OWASP “salva” o time, pois possui modelos padrão – o ASVS para web e MASVS para mobile – que são requisitos de segurança. A última versão para a web foi feita em outubro de 2021 junto com a última versão do Top 10 e está bem atualizada. (https://owasp.org/www-project-application-security-verification-standard/).
A OWASP Top 10 olha para os riscos e não para as ameaças, ou seja, trata as vulnerabilidades mais comuns de se encontrar na aplicação. O ASVS ao contrário, olha para os requisitos, sugerindo implementação de controles com base nas áreas do sistema. Isso facilita muito o trabalho do desenvolvedor porque não é trivial tentar identificar no código uma possível vulnerabilidade como apontada no OWASP TOP 10, mas é muito mais simples implementar requisitos que evitam as vulnerabilidades pois fala diretamente na linguagem do programador.
O ASVS trabalha nas áreas do sistema, tais como: autenticação, gerenciamento de sessão, validação e sanitização dos formulários, encoding/deconding, criptografia, logs, tratamentos de erro, proteção de dados, comunicação com API etc.
Vale ressaltar que, para levantamento de requisitos de segurança do sistema, a ferramenta é muito útil, mas não substitui a modelagem de ameaças, que é muito mais completa.
Sugestão de uso aos times
Para aplicar segurança no dia a dia, o time pode se reunir e verificar quais requisitos deseja-se atender e contemplar na aplicação. Ao verificar o que faz sentido, o time deve se debruçar sobre a ferramenta e estabelecer os controles a implementar. Funciona, basicamente, como fazer um trabalho de modelagem de ameaças quando não se tem um profissional de segurança.
Além do ASVS, vale lembrar, também, da ferramenta MASVS, que tem o mesmo objetivo, porém atende os desenvolvedores do mundo Mobile, tanto para Android, IOS, quanto para os modelos híbridos como Flutter e React Native.
Peer Security Review e sugestão de uso na prática diária
Hoje a própria OWASP recomenda que a OWASP Top 10 é a ferramenta inicial, mas o ASVS/MASVS é mais recomendado como prática diária, sendo que a única vantagem do OWASP Top 10 em relação ao ASVS é a conscientização dos times.
No entanto, para treinar o time, o ASVS é o melhor e mais recomendado, além de ser mais completo por cobrir efetivamente as atividades do ciclo de vida do software – teste, revisão de código, padrão de código etc.
Na Invillia temos o know-how e a experiência nas tecnologias, abordagens e metodologias mais inovadoras do mercado, sugerindo e aplicando </ a melhor > em cada caso. Estamos sempre estudando, enriquecendo conhecimentos, antecipando o que está por vir, testando, indo mais além. Criamos e continuamente aprimoramos ao lado de quem está revolucionando seus mercados com produtos e serviços digitais inovadores, resilientes, robustos, escaláveis e com a melhor experiência de utilização. E tudo isso a partir de um ponto: nosso Global Growth Framework _
