Pular para o conteúdo principal

SSDF

Secure Software Development Framework

O Secure Software Development Framework (SSDF) do NIST serve para orientar organizações na integração de práticas de segurança em todo o ciclo de vida do desenvolvimento de software. Ele visa reduzir vulnerabilidades, aumentar a resistência a ataques e melhorar a confiabilidade do software.

O uso da SSDF ajuda as organizações a atenderem às seguintes recomendações de desenvolvimento seguro de software:

• As organizações devem garantir que seu pessoal, seus processos e sua tecnologia estejam preparados para realizar o desenvolvimento seguro de software.
• As organizações devem proteger todos os componentes de seu software contra adulteração e acesso não autorizado.
• As organizações devem produzir software bem protegido com o mínimo de vulnerabilidades de segurança em suas versões.
• As organizações devem identificar as vulnerabilidades residuais em suas versões de software e reagir adequadamente para resolver essas vulnerabilidades e evitar que outras semelhantes ocorram no futuro.

A SSDF não prescreve como implementar cada prática.
Pode ser usada por qualquer organização.
Pode ser usada para qualquer tipo de desenvolvimento de software.

A SSDF define um subconjunto de alto nível das ações necessárias, e as organizações devem adotar uma abordagem baseada em riscos para escolher práticas relevantes e eficazes, conforme seu contexto e nível de alto risco.

As vulnerabilidades incluem não apenas bugs causados por falhas de codificação, mas também pontos fracos causados por definições de configuração de segurança, suposições de confiança incorretas e análises de risco desatualizadas.

SDLC​

SDLC (Software Development Life Cycle) é o ciclo de vida do desenvolvimento de software, ou seja, o conjunto de fases que um software percorre desde a concepção até a sua descontinuação.

Todas as fases do ciclo de vida do desenvolvimento de software são impactadas quando adotamos o SSDLC (Secure Software Development Life Cycle).

Shifting left​

Shifting left é o princípio de incorporar práticas de segurança o mais cedo possível no ciclo de desenvolvimento de software (SDLC). Isso reduz custos, evita retrabalho, minimiza dívidas técnicas e resulta em software mais seguro e resiliente.

Estrutura​

As práticas estão organizadas em quatro grupos:

  1. Preparar a organização (PO): As organizações devem garantir que seu pessoal, seus processos e sua tecnologia estejam preparados para realizar o desenvolvimento seguro de software em nível organizacional. Muitas organizações descobrirão que algumas práticas de PO também são aplicáveis a subconjuntos de seu desenvolvimento de software, como grupos ou projetos de desenvolvimento individuais.

  2. Proteger o software (PS): As organizações devem proteger todos os componentes de seu software contra adulteração e acesso não autorizado.

  3. Produzir software bem protegido (PW): As organizações devem produzir software bem protegido com o mínimo de vulnerabilidades de segurança em suas versões.

  4. Responder a vulnerabilidades (RV): As organizações devem identificar as vulnerabilidades residuais em suas versões de software e reagir adequadamente para resolver essas vulnerabilidades e evitar que outras semelhantes ocorram no futuro.

Práticas​

PO – Preparar a organização​

  • PO.1 – Definir requisitos de segurança para o desenvolvimento de software
    Estabelece diretrizes organizacionais formais para práticas seguras de desenvolvimento.
    Garante consistência e responsabilidade em todos os projetos de software.

  • PO.2 – Implementar funções e responsabilidades
    Define quem faz o quê em relação à segurança no ciclo de vida do software.
    Ajuda a evitar lacunas e sobreposições nas atividades de segurança.

  • PO.3 – Implementar cadeias de ferramentas de suporte
    Usar a automação para reduzir o esforço humano e melhorar a precisão, a reprodutibilidade, a usabilidade e a abrangência das práticas de segurança em todo o SDLC, além de fornecer uma maneira de documentar e demonstrar o uso dessas práticas.

  • PO.4 – Definir e usar critérios para verificações de segurança de software
    Ajudar a garantir que o software resultante do SDLC atenda às expectativas da organização, definindo e usando critérios para verificar a segurança do software durante o desenvolvimento

  • PO.5 - Implementar e manter ambientes seguros para o desenvolvimento de software
    Garantir que todos os componentes dos ambientes de desenvolvimento de software sejam fortemente protegidos contra ameaças internas e externas para evitar o comprometimento dos ambientes ou do software que está sendo desenvolvido ou mantido neles. Exemplos de ambientes para desenvolvimento de software incluem ambientes de desenvolvimento, compilação, teste e distribuição.

PS – Proteger o software​

  • PS.1 – Proteger todas as formas de código contra acesso não autorizado e adulteração
    Ajudar a evitar alterações não autorizadas no código, tanto inadvertidas quanto intencionais, que poderiam contornar ou negar as características de segurança pretendidas do software. Para códigos que não se destinam a ser acessíveis ao público, isso ajuda a evitar o roubo do software e pode tornar mais difícil ou demorado para os invasores encontrarem vulnerabilidades no software.

  • PS.2 – Fornecer um Mecanismo para Verificar a Integridade da Versão do Software
    Ajudar os adquirentes de software a garantir que o software adquirido seja legítimo e não tenha sido adulterado.

  • PS.3 – Arquivar e Proteger Cada Versão de Software
    Preservar as versões do software para ajudar a identificar, analisar e eliminar as vulnerabilidades descobertas no software após o lançamento.

PW – Produzir software bem protegido​

  • PW.1 – Projetar Software para Atender aos Requisitos de Segurança e Atenuar os Riscos de Segurança
    Identificar e avaliar os requisitos de segurança do software; determinar os riscos de segurança que o software provavelmente enfrentará durante a operação e como o projeto e a arquitetura do software devem atenuar esses riscos; e justificar os casos em que a análise baseada em riscos indica que os requisitos de segurança devem ser relaxados ou dispensados. A abordagem dos requisitos e riscos de segurança durante o projeto do software (seguro por projeto) é fundamental para melhorar a segurança do software e ajudar a aumentar a eficiência do desenvolvimento.

  • PW.2 – Revisar o Projeto do Software para Verificar a Conformidade com os Requisitos de Segurança e as Informações de Risco
    Ajudar a garantir que o software atenderá aos requisitos de segurança e abordará de forma satisfatória as informações de risco identificadas.

  • PW.3 – Movido para PW.4

  • PW.4 – Reutilizar Software Existente e Bem Protegido Quando for Viável, em vez de Duplicar a Funcionalidade
    Reduzir os custos de desenvolvimento de software, agilizar o desenvolvimento de software e diminuir a probabilidade de introduzir vulnerabilidades de segurança adicionais no software, reutilizando módulos e serviços de software que já tiveram sua postura de segurança verificada. Isso é particularmente importante para o software que implementa a funcionalidade de segurança, como módulos e protocolos criptográficos.

  • PW.5 – Criar Código-Fonte Seguindo as Práticas de Codificação Segura
    Diminuir o número de vulnerabilidades de segurança no software e reduzir os custos, minimizando as vulnerabilidades introduzidas durante a criação do código-fonte que atendem ou excedem os critérios de gravidade de vulnerabilidade definidos pela organização.

  • PW.6 – Configurar os Processos de Compilação, Interpretação e Construção para Melhorar a Segurança do Executável
    Diminuir o número de vulnerabilidades de segurança no software e reduzir os custos, eliminando as vulnerabilidades antes da realização dos testes.

  • PW.7 - Revisão e/ou Análise de Código Legível por Humanos para Identificar Vulnerabilidades e Verificar a Conformidade com os Requisitos de Segurança Ajudar a identificar vulnerabilidades para que possam ser corrigidas antes do lançamento do software para evitar a exploração. Usar métodos automatizados reduz o esforço e os recursos necessários para detectar vulnerabilidades. O código legível por humanos inclui código-fonte, scripts e qualquer outra forma de código que uma organização considere legível por humanos.

  • PW.8 - Testar o Código Executável para Identificar Vulnerabilidades e Verificar a Conformidade com os Requisitos de Segurança Ajudar a identificar vulnerabilidades para que possam ser corrigidas antes do lançamento do software, a fim de evitar a exploração. O uso de métodos automatizados reduz o esforço e os recursos necessários para detectar vulnerabilidades e melhora a rastreabilidade e a repetibilidade. O código executável inclui binários, bytecode e código-fonte executados diretamente e qualquer outra forma de código que uma organização considere executável.

  • PW.9- Configurar o Software para Ter Configurações Seguras Por Padrão Ajudar a melhorar a segurança do software no momento da instalação para reduzir a probabilidade de o software ser implantado com configurações de segurança fracas, colocando-o em maior risco de comprometimento.

RV – Responder a vulnerabilidades​

  • RV.1 – Identificar e confirmar vulnerabilidades em uma base contínua
    Ajudar a garantir que as vulnerabilidades sejam identificadas mais rapidamente para que possam ser corrigidas mais rapidamente de acordo com o risco, reduzindo a janela de oportunidade para os invasores.

  • RV.2 – Avaliar, Priorizar e Corrigir as Vulnerabilidades
    Ajudar a garantir que as vulnerabilidades sejam corrigidas de acordo com o risco para reduzir a janela de oportunidade para os invasores.

  • RV.3 – Analisar as Vulnerabilidades para Identificar Suas Causas Principais
    Ajudar a reduzir a frequência das vulnerabilidades no futuro.