Ciclo de Vida de Desenvolvimento Seguro – Artigo PenTest Magazine

Recentemente foi publicado um artigo que escrevi na revista PenTest Magazine sobre Ciclo de Vida de Desenvolvimento Seguro, como não tenho permissão de compartilhar a revista em PDF por ser paga, compartilho com vocês a publicação em português.

O conteúdo original está disponível na revista PenTest Magazine, inclusive tem muito conteúdo bacana, vale a pena conferir

Ciclo de Vida de Desenvolvimento Seguro

 Introdução

O ciclo de vida de desenvolvimento seguro é importante para que sua organização proteja as informações críticas para o negócio e também seus clientes e parceiros de negócio.

Quando bem implementado garante maior confiabilidade e redução de custos, pois muitos problemas são identificados até mesmo antes da realização dos testes pela equipe responsável.

Segurança da Informação

 Antes de falar sobre ciclo de vida de desenvolvimento seguro precisamos entender um pouco sobre segurança da informação, muito bem representado pela tríade CIA (Confidentiality, Integrity, Availability) de acordo com a ISO/IEC 27001:2013 Information technology — Security techniques — Information security management systems – Requirements. Com o aumento do uso da tecnologia e exposição de informação outros conceitos complementares foram adicionados, porém a tríade é a base da segurança da informação.

• Confidentiality: Garantia de que as informações são acessadas somente por pessoas/sistemas autorizados;

• Integrity: Garantia de que as informações não sofram alterações de modo não autorizado;

• Availability: Garantia de que as informações estejam disponíveis no momento em que o usuário necessita.

Para a nossa matéria é importante entender outros conceitos que também diz respeito a segurança da informação:

• Privacidade: É necessário garantir a proteção das informações, bem como o uso devido da informação obtida e autorização do cliente. Quanto mais informação é obtida e armazenada, mais investimento é necessário para prover segurança, desse modo, é importante verificar o custo x benefício, nem sempre coletar uma quantidade muito grande de informações significa vantagem competitiva. Alguns países têm legislação muito clara no quesito privacidade e proteção de dados pessoais, outros estão caminhando para tal;
• Identificação: Há a necessidade de identificar o usuário dentro do sistema, portanto deve ser um usuário para uma pessoa. Com esta boa prática é possível identificar e responsabilizar o responsável por uma ação realizada dentro da aplicação através da trilha de auditoria.
• Autenticação: Este processo prova que o usuário é ele mesmo, já que ele possui a identidade de acesso na aplicação. O processo pode ser melhorado usando a autenticação multi-fator, esta ação aumenta a proteção se a credencial for comprometida;
• Autorização: Objetivo é garantir que o usuário tenha autorização concedida pelo proprietário da aplicação a acesso informações contidas nela. Deve ficar claro que a autorização visa prover acesso somente às informações necessárias para desempenhar a atividade;
• Responsabilização: Este processo visa garantir que a ação executada pode ser atribuída a uma determinada pessoa / sistema;
• Assurance: Tem por objetivo garantir que os controles de segurança foram implementados e também foram devidamente avaliados e testados.

Por que desenvolver aplicação segura?

É importante desenvolver aplicações segura porque os ataques evoluíram muito nos últimos tempos e podemos observar através da ilustração abaixo:

De acordo com a regra de Myers, o custo de manutenção de uma aplicação tende a ser 10 vezes maior a cada ciclo de vida de desenvolvimento.

Precisamos pontuar que este estudo é antigo e talvez não se aplique totalmente nos dias de hoje, porém há sim um custo elevado quando o bug é descoberto ao avançar as fases da aplicação.

Estar em conformidade com as melhores práticas de mercado de Tecnologia da Informação e Segurança da Informação, atender requisitos de parceiros e clientes.

E se a organização deseja obter o certificado da ISSO/IEC 27001:2013 e o escopo conter aquisição, desenvolvimento e manutenção de sistemas é necessário implementar os controles da seção 14 da ISO/IEC 27002:2013 que contém:

• 14.1 – Requisitos de Segurança de Sistemas de Informação – Tem por objetivo garantir que a segurança da informação é parte integrante dos sistemas de informação ao longo de todo ciclo de vida:
  • 14.1.1 – Análise e Especificação dos Requisitos de Segurança da Informação – os requisitos relacionados com segurança da informação devem ser incluídos nas especificações e requisitos;
  • 14.1.2 – Aplicando Segurança nos Serviços que Transitam Sobre Redes Públicas – Devem ser protegidas contra ações fraudulentas, disputas contratuais e divulgação e modificações não autorizadas;
  • 14.1.3 – Protegendo as Aplicações nas Transações de Serviços – Informações envolvidas em transações devem ser protegidas para prevenir erros, alterações, divulgações não autorizadas.
• 14.2 – Segurança em Processos de Desenvolvimento e de Suporte – tem por objetivo garantir que a segurança está projetada e implementada no desenvolvimento do ciclo de vida dos sistemas:
  • 14.2.1 – Política de Desenvolvimento Seguro – As regras para o desenvolvimento de software devem ser estabelecidas e seguidas para todas as aplicações que serão desenvolvidas;
  • 14.2.2 – Procedimentos para Controle de Mudanças de Sistemas – Mudanças em sistemas devem ser controlados utilizando procedimentos devidamente formalizados;
  • 14.2.3 – Análise Crítica Técnica das Aplicações Após Mudanças nas Plataformas Operacionais – Aplicações críticas para o negócio devem passar por análise crítica e testes quando plataformas operacionais sofrem alterações;
  • 14.2.4 – Restrições sobre Mudanças em Pacotes de Software – deve-se mudar pacotes somente quando realmente for necessário e devem ser devidamente controlados;
  • 14.2.5 – Princípios da Engenharia de Sistemas Seguros – Princípios para sistemas seguro de engenharia devem ser estabelecidos, documentados, mantidos e aplicados corretamente, deve-se considerar, desastres naturais e comportamento humano;
  • 14.2.6 – Ambiente de Desenvolvimento Seguro – É necessário estabelecer ambientes adequados para ambientes de desenvolvimento seguros, contemplando todo o ciclo de vida;
  • 14.2.7 – Desenvolvimento Terceirizado – A organização deve supervisionar e monitorar as atividades de desenvolvimento terceirizado;
  • 14.2.8 – Teste de Segurança do Sistema – Testes que envolvem funcionalidade de segurança devem ser executados durante o desenvolvimento do sistema, este deve ser periódico;
  • 14.2.9 – Teste de Aceitação de Sistemas – Programas e testes de aceitação devem ser estabelecidos para novos sistemas, atualizações e novas versões de aplicações;
• 14.3 – Dados para Teste – Garantir a proteção de dados usados para testes
  • 14.3.1 Proteção dos dados para teste – Os dados de testes devem ser selecionados com cautela, protegidos e devidamente controlados.

A ISO / IEC 27002: 2013 ajuda a identificar os controles aplicáveis no escopo, mas a implementação varia de empresa para empresa, e não passo a passo.

Através do SDL a organização mantém suas aplicações mais seguras, fornece confiança aos clientes e às partes interessadas, redução de retrabalho e custos.

Processo de Segurança em Desenvolvimento

Há pesquisas que mostram que a maioria dos incidentes de segurança de informações ocorrem devido a vulnerabilidades em aplicativos, no entanto, quem desenvolve o aplicativo? São as pessoas! Portanto, para fazer qualquer melhoria é necessário treinar e conscientizar os desenvolvedores e todas as equipes que atuam na entrega de determinada aplicação, desta forma terá a equipe alinhada com a finalidade de desenvolvimento seguro.

O desenvolvimento seguro não é apenas a codificação, envolve a infraestrutura para suportar o ambiente da aplicação. Sendo assim é necessário investir em proteção do ambiente como um todo.

Abaixo há um processo de ciclo de vida de desenvolvimento seguro muito interessante, tem como base o SDL Microsoft:

Pre SDL – Training

Em meu entendimento esta é a fase fundamental para um processo de desenvolvimento seguro de sucesso, o processo é vivo e necessita de melhoria contínua.

1. É necessário aculturar os funcionários em matéria de segurança, isso envolve as equipes de negócios e técnicas. O conteúdo deve ser direcionado de acordo com o público-alvo, uma vez que não é necessário para treinar tecnicamente uma pessoa na área de negócios, o conteúdo deve ser mais gerencial;
2. Definir o escopo do treinamento;
3. Deve ser recorrente e ter o mínimo de colaboradores treinados.

Phase 1 – Requirements

Nesta etapa do processo você terá a oportunidade de discutir sobre os requisitos de segurança e aprofundar em itens como:

1. Identificação de segurança necessária, requisitos mínimos de qualquer aplicação;
2. Privacidade;
3. Legislação vigente, políticas internas e externas;
4. Segurança dos dados, mínimo aceitável;
5. Aprofundamento na avaliação dos riscos de segurança e da privacidade;
6. Verificar se realmente há a necessidade de armazenar uma informação crítica;
7. Definir os especialistas necessários para o desenvolvimento, inclusive profissionais de segurança da informação;
8. Utilizar ferramentas de bug track;
9. Definir quality gates, quando avança próxima etapa, isso deve contemplar falhas de segurança;

Phase 2 – Design

Este é o momento de arquitetar a aplicação com base nos requisitos, de modo a estabelecer as necessidades para atendimento de proteção das informações, início do ciclo de vida.

Pontos como privacidade deve ser avaliado com muito cuidado, há a necessidade de envolver a área de negócios, visto que o que para um desenvolvedor pode ser um simples cadastro, porém para área de negócio pode ser informações críticas e que devem ter controles de segurança.

Como boa prática é importante:

1. Classifique o tipo de dado, isso se torna um baseline para os próximos projetos.
2. Use criptografia para proteger informações sensíveis:
   1. Verifique o que realmente necessita de criptografia, visto que isso pode onerar a aplicação;
   2. Defina o algoritmo que será utilizado.
3. Necessário reduzir a superfície de ataque, utilizando proteção em camadas, Web Application Firewall, utilização de DMZ, banco de dados não exposto para internet, entre outros recursos que podem aumentar a sua segurança;
4. Necessário realizar modelagem de ameaças para reduzir os riscos, a Microsoft criou a ferramenta baseada na taxonomia STRIDE (spoofing, tempering, repudiation, information disclousure, Denial of service and Elevation Privilege) muito utilizada em SDL;
5. Atuar com o princípio de menor privilégio;
6. Check list para não esquecer de algum ponto.

Phase 3 – Implementation

Esta etapa é a mão na massa, ou seja, codificação. É muito importante possuir ferramentas aprovadas e que possua verificação de segurança e que contenha avisos de compilador. É imprescindível atuar com as versões mais recentes desta e demais ferramentas.

Além disso é importante possuir:

1. Banir o uso de APIs inseguras e funções frágeis e realizar a devida documentação para que todos tenham conhecimento;
2. Ferramenta de análise estática realizada pelo próprio desenvolver;
3. Realizar revisão de código com apoio de ferramentas;
4. Realizar teste não estruturado, possibilita identificar comportamento anômalo;
5. Realizar revisão de código manual para identificar se há falso positivo e se possível outro desenvolvedor realizar esta análise manual;
6. Escrever um código limpo para que a manutenção possa ser realizada por outro time.

Phase 4 – Verification

Esta etapa do processo se refere ao teste da aplicação, utilizando métodos para validar se a aplicação está funcionando conforme o esperado, desde sua funcionalidade até os requisitos de segurança e privacidade das informações. Esta fase do processo é realizada por outra equipe.

Neste momento como boas práticas você deve contemplar:

1. Análise dinâmica, verifica a aplicação, possibilita verificar alguns problemas de segurança, comportamento do ambiente que suporta a aplicação. Para isso você pode utilizar ferramentas opensource e também de mercado;
2. Nesta etapa é possível combinar com testes não estruturados em todos os pontos de interação da aplicação, validando os controles pela superfície de ataque;
3. Revisão dos controles implementados para os riscos identificados na análise de ameaça;
4. Realizar teste de penetração, com profissionais especializados, podendo ser internos ou terceiros;
5. Se as equipes que trabalharam no projeto realizaram a lição de casa, o teste de penetração deverá identificar poucas falhas no desenvolvimento.

Phase 5 – Release

Nesta fase é imprescindível ter um plano mínimo de resposta de incidentes na aplicação devidamente documentado, inclusive identificando quais são as equipes envolvidas caso ocorra um incidente.

Fazer a revisão final de segurança da informação, pode através de um check list identificando se todas as fases de segurança foram realizadas, tal como:

1. Requisitos de privacidade;
2. Requisitos de Segurança da informação.

A última atividade desta etapa é o arquivamento de todos os documentos, especificações, códigos que fizeram parte deste desenvolvimento.

Pos SDL – Response

Esta fase é onde é colocado em prática o plano de resposta à incidentes.

Se sua organização não tem um time e um processo para resposta à incidentes é importante pensar nisso!

Desse modo é possível direcionar os incidentes para as equipes responsáveis pela tratativa, de forma organizada, cada um sabe exatamente o que deve ser feito.

Documentação e atualização dela é imprescindível para o sucesso deste processo.

Espero que tenham gostado desta publicação e até a próxima.