Um Framework para Integrar a Segurança de Aplicações na Engenharia de Software (FIASSE)

Nota: Este repositório é um trabalho em andamento. Contribuições são bem-vindas!

Visão Geral

TL;DR: por favor, leia a DOC. Explore o site do FIASSE. Visite as Discussões no GitHub para contribuir.

Este repositório contém recursos e materiais para o Framework da OWASP para Integrar a Segurança de Aplicações na Engenharia de Software (FIASSE). FIASSE (pronunciado /feiz/, como 'phase') é um framework independente de fornecedor que promove uma abordagem centrada no desenvolvedor e baseada em princípios para construir software securable (segurável). Ele reconhece que a segurança é um processo dinâmico e contínuo, assim como o desenvolvimento. Ele introduz o Modelo de Engenharia de Software Segurável (SSEM) como uma linguagem de design comum que utiliza termos consagrados da engenharia de software para integrar a segurança à arquitetura, ao design e à engenharia de software, incorporando a segurança nos princípios que moldam o próprio código. O framework permite que as equipes de desenvolvimento agreguem valor computacional de forma resiliente, reduzindo a probabilidade de impacto material decorrente de eventos cibernéticos ao longo do ciclo de vida do código.

FIASSE é um framework criacional. Ele aborda como a segurança é implementada no software, conectando decisões de engenharia diretamente a resultados seguráveis. Não é um framework de garantia (assurance), um modelo de maturidade, nem um substituto para catálogos de controles ou métricas de vulnerabilidade. Ele complementa essas abordagens e alivia a pressão a jusante sobre garantia e conformidade.

Propósito

Fornecer diretrizes práticas que capacitem os desenvolvedores a criar software segurável sem exigir profundo conhecimento em segurança, e orientar os profissionais de segurança a integrar efetivamente sua experiência em segurança à engenharia de software. O FIASSE alcança isso por meio de uma lente de Engenharia de Software, reduzindo a carga cognitiva e promovendo a colaboração entre as equipes de desenvolvimento e de segurança.

Como é Diferente?

Enquanto projetos focados em garantia, como o OWASP Top 10, destacam o que evitar (uma lista de bloqueio), o OWASP FIASSE fornece um conjunto de atributos e práticas positivas a serem seguidas (uma lista de permissões). Essa abordagem aproveita as habilidades existentes de engenharia de software para construir software segurável, em vez de exigir que os desenvolvedores aprendam técnicas de exploração ou adotem uma mentalidade focada em vulnerabilidades. A ênfase está em possibilitar a codificação segura e prática por meio de princípios de engenharia familiares.

Ao definir claramente o papel prático da segurança dentro do processo de desenvolvimento, este framework garante que o valor de negócio seja capturado de forma eficaz. Estabelecer expectativas explícitas de segurança antes que o código seja escrito reduz a probabilidade de que falhas de segurança sejam descobertas e precisem de remediação posteriormente. A adoção eficaz deve melhorar as métricas de garantia existentes, reduzir a rotatividade de achados, produzir correções mais duradouras e encurtar o tempo de remediação.

Valores Fundamentais

O FIASSE é orientado por quatro valores fundamentais. Cada um expressa uma preferência relativa: ambos os lados têm valor, mas quando escolhas precisam ser feitas, o FIASSE favorece o lado esquerdo.

• Atributos Seguráveis em vez de Controles de Segurança: preferir as qualidades de engenharia que permitem que um sistema seja construído e mantido defensável em vez de controles de segurança adicionados posteriormente para compensar fraquezas.
• Participação em vez de Avaliação: preferir o engajamento estruturado entre segurança e desenvolvimento ao longo de todo o ciclo de vida em vez da avaliação realizada após o trabalho estar concluído.
• Primeiros Princípios de Engenharia em vez de Jargão de Segurança: preferir o embasamento nos primeiros princípios consagrados da engenharia de software em vez de jargão específico de segurança ou heurísticas adversariais.
• Valor de Negócio em vez de Atividade de Segurança: preferir a segurança que sustenta a criação de valor da organização em vez da segurança buscada como um fim em si mesma.

Princípios-Chave

• O Paradigma Securável: Não existe um estado estático de "seguro". Um sistema declarado seguro hoje pode estar vulnerável amanhã. O FIASSE redireciona o objetivo de engenharia de "ele é seguro?" para "ele foi construído de modo que a segurança possa ser mantida?" por meio de resiliência adaptativa, segurança evolutiva e melhoria contínua.
• Agregar Valor Computacional de Forma Resiliente: A diretriz primária da engenharia de software em um contexto de negócios. O software deve atender aos requisitos funcionais enquanto sustenta as qualidades securáveis que lhe permitem resistir à mudança, ao estresse e ao ataque que se seguem a cada mudança.
• Missão de Segurança: Reduzir o Impacto Material: A missão da segurança é reduzir a probabilidade de impacto material de um evento cibernético. A eliminação completa de violações não é um objetivo de negócios prático, portanto as estratégias de segurança devem estar alinhadas com os objetivos de negócios e o apetite ao risco.
• A Relação Qualidade-Segurança: A segurança não pode exceder a qualidade do software. As qualidades que tornam o software fácil de entender, alterar, testar e observar são as mesmas qualidades que tornam possível protegê-lo. O investimento em qualidade de engenharia é um investimento em segurança.
• Segurança Centrada no Desenvolvedor: Capacitar os engenheiros de software a construir sistemas securáveis usando princípios familiares de engenharia de software, em vez de exigir que adotem a mentalidade de um testador de penetração.
• SSEM como Linguagem Comum de Design: Utilizar termos consagrados de engenharia de software (por exemplo, Analisabilidade, Modificabilidade, Testabilidade) para definir e discutir atributos de segurança. Isso torna a segurança acessível aos desenvolvedores e dá aos profissionais de segurança uma base compartilhada para avaliação.
• Alinhar a Segurança com os Objetivos de Desenvolvimento e de Negócios: Segurança e desenvolvimento são complementares, não adversariais. O AppSec participa precocemente do SDLC, particularmente durante o levantamento de requisitos e o planejamento de funcionalidades, para que as expectativas sejam explícitas antes de o código ser escrito.
• O Princípio da Transparência: Os sistemas são projetados para que partes autorizadas possam compreender o estado interno e o comportamento. Logging estruturado, instrumentação e trilhas de auditoria são incorporados ao código em vez de serem fornecidos apenas por ferramentas externas.
• O Princípio da Menor Surpresa: Os sistemas se comportam de maneiras intuitivas e previsíveis para usuários, desenvolvedores e administradores. A previsibilidade auxilia a análise, reduz a carga cognitiva e torna as fronteiras de confiança claras.
• Requisitos como Cidadão de Primeira Classe no AppSec: Recursos de Segurança, Cenários de Ameaça e Critérios de Aceitação de Segurança são entregues por meio do processo de requisitos. As vulnerabilidades comumente remontam a uma expectativa que nunca foi especificada, portanto essa lacuna pertence ao processo de requisitos.

Princípios de Engenharia

A Seção 4 do framework fornece aos desenvolvedores princípios que se aplicam diretamente no nível do código: