Segurança no desenvolvimento: Integrando Security by Design no SDLC

Fundamentos dos requisitos de segurança - Requisitos de segurança

Apresentando o curso e a instrutora

Olá! Bem-vindos a mais um curso da Alura. Neste curso, vamos abordar a gestão de requisitos de segurança, compreendendo o que são esses requisitos, a diferença entre requisitos funcionais e técnicos, como eles operam e como podemos extrair requisitos de regulatórios. Além disso, discutiremos como gerenciar esses requisitos, garantindo que permaneçam válidos ao longo do tempo. Será um tema bastante interessante.

Meu nome é Giovana, sou gerente de APSEC atualmente, com 15 anos de experiência em TI, sendo 9 anos focados em segurança e 6 especificamente em APSEC. Já atuei em diversas áreas, como desenvolvimento, infraestrutura e redes, e hoje trabalho com segurança, tendo passado por Blue Team, Red Team e resposta a incidentes. Minha paixão é APSEC. Fui professora de pós-graduação e instrutora da ICCALSO, em uma certificação de APSEC.

Audiodescrição: Giovana é uma pessoa branca, loira, com olhos castanhos claros e cabelo comprido. Ela usa óculos arredondados com hastes pretas e está gravando no estúdio da Alura.

Explorando os fundamentos dos requisitos de segurança

Na primeira aula, vamos explorar os fundamentos dos requisitos de segurança. Entenderemos o que são requisitos de segurança, a diferença entre requisitos funcionais e não funcionais, e o impacto da ausência de requisitos no ciclo de desenvolvimento de software. Abordaremos temas importantes, como Security by Design (Segurança por Design), e finalizaremos com um estudo de caso para aplicar o conhecimento na prática.

Nesta primeira parte, compreenderemos que o requisito é a base de tudo quando trabalhamos com Security by Design, buscando incorporar segurança desde o início do desenvolvimento. No contexto de APSEC, é crucial entender a diferença entre requisitos funcionais e não funcionais e o impacto da ausência deles.

Definindo e diferenciando requisitos funcionais e não funcionais

Mas o que são requisitos? Todo sistema nasce de requisitos. Temos requisitos de negócio, infraestrutura, desenvolvimento e também de segurança. Eles direcionam o desenvolvimento e garantem que as necessidades do negócio sejam atendidas. Em segurança, são ferramentas ideais para evitar vulnerabilidades desde a concepção de um software.

Temos dois tipos de requisitos: funcionais e não funcionais. Os requisitos funcionais descrevem o que o sistema deve fazer, como ações, comportamentos e funcionalidades. Por exemplo, o usuário deve se autenticar com credenciais únicas para acessar a aplicação. Já os requisitos não funcionais descrevem como o sistema deve operar, abordando aspectos como qualidade, restrições, desempenho e segurança. Por exemplo, as credenciais devem ser armazenadas usando um algoritmo de hash resistente à colisão, como bcrypt ou argon2. Isso define como a senha deve ser armazenada e qual tipo de algoritmo deve ser utilizado.

Exemplificando a aplicação de requisitos de segurança

Definir requisitos pode parecer simples, mas tem impacto direto na proteção contra diversos tipos de ataques. Requisitos bem definidos evitam ambiguidades e facilitam a implementação. Para esclarecer, os requisitos funcionais descrevem a ação do sistema frente a um ataque, como bloquear, notificar ou verificar uma lista. Já os requisitos não funcionais descrevem como essas ações devem ocorrer, como tempo máximo de resposta, log obrigatório e algoritmo de checagem.

Vamos a alguns exemplos. No caso de um ataque de brute force, um requisito funcional seria o suporte obrigatório à autenticação multifator (MFA). Um requisito não funcional seria suportar MFA com pelo menos dois fatores diferentes, como sem OTP ou por geolocalização. Para credential stuffing, um requisito funcional seria validar a senha do usuário com outra base de senhas comprometidas para garantir segurança. Um requisito não funcional seria integrar a checagem de senhas em listas de credenciais comprometidas, como a base do Have I Been Found, ou uma base interna conhecida por vazamentos, impedindo seu uso.

No caso de Injection, um requisito funcional seria utilizar consultas parametrizadas em todas as interações com dados. Um requisito não funcional seria que esses inputs sejam validados automaticamente, rejeitando caracteres ou padrões maliciosos definidos na política de segurança. A ideia é deixar claro o que constitui um requisito funcional de segurança e um requisito não funcional de segurança, e como eles se complementam.

Fundamentos dos requisitos de segurança - A importância do Secure by Design

Introduzindo o conceito de Secured by Design

Nessa aula, vamos entender mais sobre como incorporar segurança desde o desenho e a concepção de novos projetos, abordando o conceito de Secured by Design (Seguro por Design). Mas o que é Secured by Design? Trata-se de integrar a segurança desde a concepção do software. A segurança precisa ser parte integrante do software desde o início, e não ser adicionada posteriormente. Quanto mais cedo trouxermos a segurança e essas preocupações, melhor, pois assim teremos menos custos de retrabalho. Isso ocorre porque, ao entregar o software já seguro, evitamos a necessidade de voltar e corrigir vulnerabilidades, reduzindo custos de correção. A ideia é que o software nasça seguro por padrão, evitando também custos com fraudes, já que vulnerabilidades em produção podem ser exploradas para fraudes, gerando prejuízos financeiros para a empresa.

O Secured by Design é um princípio, e não uma camada extra de segurança. É pensar em segurança desde a concepção de um projeto. Quanto antes mapeamos esses problemas e preocupações, mais cedo conseguimos atuar neles, reduzindo custos, exposição a riscos, ataques e retrabalho, pois ninguém aprecia retrabalho.

Comparando cenários de segurança

Para dar um contexto maior, vamos considerar dois cenários: o cenário do Secured by Design e o cenário do processo padrão. No primeiro caso, teremos o custo para corrigir o código dos desenvolvedores, pois não houve integração com a produção nem com o sistema, e, por isso, a vulnerabilidade não pode ser explorada por um atacante. No processo padrão, que é o segundo cenário, temos o custo para corrigir o código dos desenvolvedores, e, nesse caso, o custo refere-se ao tempo, e não necessariamente a dinheiro.

O custo para corrigir as integrações desse código com o sistema que já está em produção, e o custo da exploração dessa falha ou vulnerabilidade em si, em produção, são aspectos importantes a considerar. Quando chegou para revisão, esse código já havia sido implementado em produção. Isso nos ajuda a entender o quanto ganhamos com o Secured by Design.

Explicando os princípios-chave do Secured by Design

Alguns princípios-chave do Secured by Design incluem Secured by Defaults, Least Privilege e Defense in Depth. Vamos explicar cada um deles.

Secured by Defaults refere-se a ter configurações seguras por padrão para serem utilizadas na empresa. Por exemplo, utilizar TLS 1.2 ou superior em vez de SSL ou TLS 1.0, adotar senhas fortes com uma política de senha bem definida, e mascarar dados sensíveis. Esses são padrões de segurança que devem ser aplicados em todo o desenvolvimento de código, em diferentes aspectos. Os próprios desenvolvedores e times de engenharia podem usar isso como base, sem necessariamente depender de um time de segurança. A ideia é produzir conteúdo e fornecer uma base de conhecimento para eles.

O princípio do menor privilégio envolve conceder as permissões mínimas necessárias que uma pessoa precisa para realizar suas atividades conforme sua função determina. Isso não é novidade, já abordamos esse tema diversas vezes ao longo do curso.

Por fim, a defesa em profundidade é a ideia de criar múltiplas camadas de defesa, de modo que a camada seguinte consiga deter um possível ataque ou incidente de segurança, caso a camada anterior falhe. É como uma casca de cebola, com vários níveis e proteções diferentes para cada nível, para impedir que um ataque ou atacante consiga acessar e roubar informações, dados ou atingir a empresa.

Fundamentos dos requisitos de segurança - Estudo de caso

Analisando estudos de caso de segurança

Nesta aula, vamos analisar alguns estudos de caso para entender melhor como requisitos bem definidos e o uso de Security by Default (Segurança por Padrão) poderiam ter evitado os problemas que vamos discutir.

Discutindo o caso Equifax

No primeiro caso, da Equifax, os atacantes exploraram uma vulnerabilidade no Apache Struts, para a qual já havia um patch disponível há dois ou três meses, mas que não foi aplicado. O CEO afirmou a um comitê do congresso dos Estados Unidos que a vulnerabilidade foi identificada em março, mas a correção só foi aplicada vários meses depois, devido à ausência de um processo de gestão de patches para garantir que as atualizações, não apenas de segurança, mas também de manutenção, fossem implementadas.

Neste caso, não havia um requisito claro e bem definido sobre a atualização contínua e monitoramentos que poderiam ter evitado esse incidente. Requisitos de segurança vão além do código; eles também incluem processos de manutenção. A falta de um processo estabelecido para a gestão de patches, para garantir que eles sejam aplicados, especialmente no caso de patches de segurança, e a manutenção contínua são cruciais. Isso nos permite acompanhar o que está acontecendo, identificar novas vulnerabilidades em produtos, como um zero-day, por exemplo, além de realizar o monitoramento constante das aplicações.

Como resultado desse caso, 147 milhões de pessoas foram afetadas.

Examinando o caso Uber

Passando para o segundo caso, da Uber, vamos explicar um pouco o contexto.

Em outubro de 2016, hackers acessaram o repositório privado do GitHub, utilizado por engenheiros da Uber, e abusaram das credenciais encontradas para invadir bancos de dados da empresa. Isso resultou no vazamento de dados pessoais de 57 milhões de usuários, além de 600 mil motoristas. Esses dados incluíam nome, e-mail, telefone, número de carteira de motorista e outras informações pessoais e sensíveis. Em resposta, a Uber pagou 100 mil dólares aos invasores para tentar manter esse incidente em sigilo, conseguindo fazê-lo por mais de um ano.

Destacando a importância dos requisitos não funcionais

Requisitos não funcionais, como a forma de armazenar credenciais de maneira segura e a rotatividade delas, são tão importantes quanto os requisitos funcionais de um sistema. A ausência de pequenos requisitos pode causar grandes incidentes de segurança. É importante não permitir que nossas empresas utilizem práticas como ter credenciais embutidas no código (hardcoded). Mesmo que essas credenciais sejam posteriormente removidas do código e colocadas em um vault (cofre), como deveria ser feito, elas permanecem no histórico do código. Se alguém acessar e verificar o histórico de pull requests ou de commits, poderá acessar essas chaves antigas.

No caso de uma empresa ter chaves embutidas no código, é necessário removê-las e, no mínimo, rotacionar essas chaves para novas senhas, armazenando-as em um vault para uso. Se possível, embora nem sempre seja viável, também é recomendável limpar esse histórico dentro da base de código.

Concluindo com lições aprendidas

As lições aprendidas são claras: segurança não pode ser improvisada. Requisitos precisam estar documentados para que possamos evitar a repetição de falhas. Muitas falhas históricas poderiam ter sido evitadas com requisitos claros desde o início.

Sobre o curso Segurança no desenvolvimento: Integrando Security by Design no SDLC

O curso Segurança no desenvolvimento: Integrando Security by Design no SDLC possui 94 minutos de vídeos, em um total de 49 atividades. Gostou? Conheça nossos outros cursos de Segurança em DevOps, ou leia nossos artigos de DevOps.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Fundamentos dos requisitos de segurança
• Integração dos requisitos ao SDLC
• Requisitos regulatórios e de conformidade
• Definição de requisitos técnicos de segurança
• Secure Defaults
• Documentação, comunicação e manutenção