Security Development Lifecycle Framework e suas 12 práticas de segurança

DevOps

Microsoft SDL

Security Framework Lifecycle

Conheça as melhores práticas do ciclo de vida de desenvolvido seguro 

O Ciclo de Vida do Desenvolvimento de Segurança (Microsoft SDL) consiste em um conjunto de práticas que suportam os requisitos de garantia e conformidade de segurança. O SDL ajuda os desenvolvedores a criarem softwares mais seguros, reduzindo o número e a gravidade das vulnerabilidades, ao mesmo tempo em que reduzem os custos de desenvolvimento.

Dentre as práticas abordadas temos as seguintes:

#1 - Fornecer Treinamento

Segurança é o trabalho de todos. Desenvolvedores, engenheiros de serviços e gerentes de programas e produtos devem entender o básico de segurança e saber como criar segurança em software e serviços para tornar os produtos mais seguros, ao mesmo tempo em que atendem às necessidades dos negócios e fornecem valor ao usuário.

O treinamento efetivo complementará e reforçará as políticas de segurança, as práticas de SDL, os padrões e os requisitos de segurança de software e será guiado por insights derivados de dados ou recursos técnicos recém-disponíveis.

Embora a segurança seja o trabalho de todos, é importante lembrar que nem todos precisam ser especialistas em segurança. No entanto, garantir que todos entendam a perspectiva do atacante, seus objetivos e a arte do possível ajudará a capturar a atenção de todos e elevar a barra do conhecimento coletivo.

#2 - Definir requisitos de segurança

A necessidade de considerar a segurança e a privacidade é um aspecto fundamental do desenvolvimento de aplicativos e sistemas altamente seguros e, independentemente da metodologia de desenvolvimento usada, os requisitos de segurança devem ser atualizados continuamente para refletir as alterações na funcionalidade necessária e no cenário de ameaças. Obviamente, o momento ideal para definir os requisitos de segurança é durante os estágios iniciais de design e planejamento, pois isso permite que as equipes de desenvolvimento integrem a segurança de maneira a minimizar as interrupções.

#3 - Definir relatórios de métricas e conformidade

É essencial definir os níveis mínimos aceitáveis ​​de qualidade de segurança e responsabilizar as equipes de engenharia por atenderem a esses critérios. A definição antecipada ajuda a equipe a entender os riscos associados a problemas de segurança, a identificar e corrigir defeitos de segurança durante o desenvolvimento e a aplicar os padrões em todo o projeto. Definir uma barra de erros significativa envolve definir claramente os limites de gravidade das vulnerabilidades de segurança (por exemplo, todas as vulnerabilidades conhecidas descobertas com uma classificação de gravidade "crítica" ou "importante" devem ser corrigidas com um período de tempo especificado) e nunca relaxá-la depois de configurada.

#4 - Realizar modelagem de ameaças

A modelagem de ameaças deve ser usada em ambientes onde haja risco significativo de segurança. A modelagem de ameaças pode ser aplicada no componente, aplicativo ou nível do sistema. É uma prática que permite que as equipes de desenvolvimento considerem, documentem e (importante) discutam as implicações de segurança dos projetos no contexto de seu ambiente operacional planejado e de forma estruturada, para em seguida, fazer seleções de recursos de segurança e estabelecer mitigações apropriadas.

#5 - Estabelecer requisitos de projeto

Implementar "recursos seguros", na medida em que funcionalidades são implementadas. Para isso, os engenheiros normalmente contarão com recursos de segurança, como criptografia, autenticação, registro e outros. Portanto, é muito importante que estes sejam aplicados de forma consistente e com uma compreensão consciente da proteção que eles fornecem.

#6 - Definir e usar padrões de criptografia

Com o aumento da computação móvel e na nuvem, é extremamente importante garantir que todos os dados, incluindo informações sensíveis à segurança e dados de gerenciamento e controle, estejam protegidos contra divulgação ou alteração não intencional quando estiverem sendo transmitidos ou armazenados. A criptografia é normalmente usada para conseguir isso.

#7 - Gerenciar o risco de segurança do uso de componentes de terceiros

Hoje, a grande maioria dos projetos de software é criada usando componentes de terceiros (comerciais e de código aberto). Ao selecionar componentes de terceiros para uso, é importante entender o impacto que uma vulnerabilidade de segurança neles poderia ter na segurança do sistema maior no qual eles estão integrados. Ter um inventário preciso de componentes de terceiros e um plano para responder quando novas vulnerabilidades forem descobertas ajudará bastante a mitigar esse risco, mas uma validação adicional deve ser considerada, dependendo do apetite de risco da sua organização, do tipo de componente usado e impacto potencial de uma vulnerabilidade de segurança.

#8 - Usar ferramentas aprovadas

Defina e publique uma lista de ferramentas aprovadas e suas verificações de segurança associadas. Os colaboradores devem se esforçar para usar a versão mais recente das ferramentas aprovadas, como por exemplo as versões mais atuais dos compiladores para aproveitar as novas funcionalidades e proteções de análise de segurança.

#9 - Executar teste de segurança de análise estática (SAST)

A análise do código-fonte antes da compilação fornece um método altamente escalável de revisão do código de segurança e ajuda a garantir que as políticas de codificação seguras estejam sendo seguidas. O SAST é normalmente integrado ao pipeline de confirmação para identificar vulnerabilidades sempre que o software é compilado ou empacotado.

#10 - Executar teste de segurança de análise dinâmica (DAST)

A execução da verificação em tempo de execução do software totalmente compilado ou empacotado verifica a funcionalidade que só é aparente quando todos os componentes estão integrados e em execução.

#11 - Realizar Pentest (testes de intrusão)

O teste de penetração é uma análise de segurança de um sistema de software realizado por profissionais de segurança qualificados simulando as ações de um hacker. O objetivo de um teste de penetração é descobrir possíveis vulnerabilidades resultantes de erros de codificação, falhas de configuração do sistema ou outras fraquezas de implantação operacional, e como tal, o teste normalmente encontra a maior variedade de vulnerabilidades. Os testes de penetração são frequentemente realizados em conjunto com revisões de código automatizadas e manuais para fornecer um nível de análise maior do que normalmente seria possível.

#12 - Estabelecer um processo padrão de resposta a incidentes

A preparação de um plano de resposta a incidentes é crucial para ajudar a lidar com novas ameaças que podem surgir com o tempo. Ele deve ser criado em coordenação com a Equipe de resposta a incidentes de segurança do produto da sua organização. O plano deve incluir quem entrar em contato em caso de emergência de segurança e estabelecer o protocolo a ser adotado.

Quais são os benefícios de uma abordagem de segurança em DevOps

Os protocolos de segurança incorporados ao processo de desenvolvimento e operação, permitem que a equipe de DevOps e os profissionais de segurança aproveitem o poder das metodologias ágeis – juntos, como um time - sem impactar o objetivo de criar código seguro e ágil.

Um dos principais benefícios identificado é a capacidade de fazer pleno uso dos serviços em nuvem aplicando as tecnologias de segurança que os mesmos fornecem. Por exemplo, as organizações que executam serviços na nuvem como o Azure colhem os benefícios de um maior controle de segurança preventiva e detectiva, no modelo de integração e implantação contínua.

À medida que mais organizações confiam nas aplicações em nuvem para manter as operações em funcionamento e para automatizar tarefas, os esforços de segurança independentes dos realizados pelos Cloud Services Provider são cruciais para evitar paralisações dispendiosas.

As medidas de segurança inerentes ao DevOps têm muitas outras vantagens. Essas incluem:

  • Maior velocidade, agilidade e segurança para as aplicações
  • Capacidade de responder rapidamente a mudanças e necessidades
  • Melhor colaboração e comunicação entre equipes
  • Mais oportunidades para construções automatizadas e testes de garantia de qualidade
  • Identificação precoce de vulnerabilidades no código
  • Defense in Depth (DiD):Proteção do seu ambiente em multi-camadas

Uma mudança cultural e técnica em direção a uma abordagem DevOps ajuda as empresas a lidar com ameaças à segurança de maneira mais eficaz, em tempo real. É importante ver as equipes de segurança como um ativo valioso que ajuda a evitar lentidão e não como um obstáculo à agilidade. Por exemplo, a detecção precoce de um aplicativo mal projetado que não pode ser dimensionado na nuvem economiza tempo, recursos e custos de computação valiosos.

A escalabilidade na nuvem requer a incorporação de controles de segurança em uma escala maior. A modelagem contínua de ameaças e o gerenciamento de compilações de sistemas são necessários à medida que os negócios baseados em tecnologia evoluem em um ritmo acelerado.

Secure DevOps: abordagem prática

Análise de código – análise o código fonte de maneira estática para que as vulnerabilidades possam ser identificadas rapidamente.

Gerenciamento de alterações - aumente a velocidade e a eficiência, evite que qualquer pessoa envie alterações e determine antes se a alteração é boa ou ruim.

Monitoramento de conformidade - esteja pronto para uma auditoria a qualquer momento (o que significa estar em constante estado de conformidade, incluindo a coleta de evidências de conformidade com LGPD, PCI, etc..

Modelagem de ameaças - identifique bugs, falhas, possíveis ameaças emergentes a cada atualização de código e seja capaz de responder rapidamente.

Avaliação de vulnerabilidades - identifique novas vulnerabilidades com a análise dinâmica e mantenha um score de risco para cada uma delas.

Treinamento de segurança - treine desenvolvedores, QAs, arquitetos e toda a equipe de engenheira de software.

Se você ainda não iniciou o processo, é hora de mesclar suas metas de segurança com o DevOps e implementar as práticas recomendadas e tornar "Segurança como parte do código".

Em resumo, é fácil entender o que o DevOps significa e porque as pessoas se preocupam com isso: é uma estratégia que estende a eficiência do DevOps à segurança de software.

Quando você se senta e realmente começa a implementar o DevOps, as coisas podem ficar mais complicadas. Não há opção que você possa ativar para obter o Secure DevOps. Nem existe uma ferramenta específica que você possa adquirir, ou mesmo um processo específico a seguir.

Em vez disso, a implementação do DevOps exige que você execute uma avaliação ampla dos recursos existentes de TI e dos processos de desenvolvimento e operação e, em seguida, crie uma estratégia holística que integre segurança.

Artigo traduzido e adaptado da Microsoft por Rafael Fontes – Head of security ESX.