Princípios de segurança

Princípios de Segurança

Visão geral do ciclo de vida do desenvolvimento da segurança

A experiência com a segurança de software do mundo real levou a um conjunto de princípios de alto nível para a compilação de um software mais seguro. As definições resumidas desses princípios são:

Seguro por Design: a arquitetura, o design e a implementação do software devem ser executados de forma a protegê-lo e proteger as informações que ele processa, além de resistir a ataques.

Seguro por Padrão (Default): na prática, o software não atingirá uma segurança perfeita; portanto, os designers devem considerar a possibilidade de haver falhas de segurança. Para minimizar os danos que ocorrem quando invasores miram nessas falhas restantes, o estado padrão do software deve aumentar a segurança.

Seguro na Implantação (Deployment): o software deve conter ferramentas e orientação que ajudem os usuários finais e/ou administradores a usá-lo com segurança.

Comunicações: os desenvolvedores de software devem estar preparados para a descoberta de vulnerabilidades do produto e devem comunicar-se de maneira aberta e responsável com os usuários finais e/ou com os administradores para ajudá-los a tomar medidas de proteção (como instalar patches ou implantar soluções alternativas).

Fase de requisitos

A necessidade de considerar a segurança "de baixo para cima" é um princípio fundamental do desenvolvimento de sistemas seguros. Embora vários projetos de desenvolvimento produzam "próximas versões" baseadas nas versões anteriores, a fase de requisitos e o planejamento inicial de uma nova versão oferecem a melhor oportunidade para criar software seguro.

Durante a fase de requisitos, a equipe de produto entra em contato com a equipe de segurança central para solicitar a designação de um supervisor de segurança (chamado de o "cara da segurança" na implementação do SDL na Microsoft) que serve como um ponto de contato, pesquisa e orientação durante o planejamento. O supervisor de segurança ajuda a equipe de produto revisando os planos, fazendo recomendações e garantindo que a equipe de segurança planeje recursos apropriados para dar suporte ao cronograma da equipe de produto. O supervisor de segurança aconselha a equipe de produto sobre os marcos de segurança e os critérios de saída que serão exigidos com base no tamanho, na complexidade e no risco do projeto. O supervisor de segurança continua sendo o ponto de contato da equipe de produto com a equipe de segurança, desde o início do projeto até a conclusão da Revisão final de segurança e o lançamento do software. O supervisor de segurança também serve como ponto de contato entre a equipe de segurança e a gerência da equipe de produto, e aconselha a gerência da equipe quanto ao controle do elemento de segurança de seus projetos, de forma a evitar surpresas relacionadas à segurança posteriormente durante o processo.

A fase de requisitos é a oportunidade para a equipe de produto considerar como a segurança será integrada no processo de desenvolvimento, identificar os objetivos chave de segurança e maximizar a segurança de software, minimizando a quebra de planos e cronogramas. Como parte desse processo, a equipe precisa considerar como os recursos de segurança e as medidas de controle de seu software serão integradas com outros softwares que provavelmente serão usados com ele. (A interface com outros softwares é uma consideração essencial para atender às necessidades dos usuários de integração de produtos individuais em sistemas seguros.) A perspectiva geral da equipe de produto sobre os objetivos, os desafios e os planos de segurança deve se refletir nos documentos de planejamento produzidos durante a fase de requisitos. Embora os planos estejam sujeitos a alterações conforme o andamento do projeto, a articulação precoce desses planos ajuda a garantir que nenhum requisito seja desconsiderado ou estabelecido na última hora.

Cada equipe de produto deve considerar os requisitos de recursos de segurança como parte dessa fase. Embora alguns requisitos de recursos de segurança sejam identificados em resposta à modelagem de ameaças, é provável que os requisitos do usuário determinem a inclusão de recursos de segurança em resposta às exigências do cliente. Os requisitos dos recursos de segurança também serão definidos de acordo com a necessidade de obedecer aos padrões da indústria e dos processos de certificação, como os Critérios comuns. A equipe de produto deve reconhecer e refletir esses requisitos como parte de seu processo de planejamento normal.

Fase de design

A fase de design identifica a estrutura e os requisitos gerais do software. Da perspectiva de segurança, os elementos-chave da fase de design são:

Definir as diretivas de design e arquitetura de segurança: definir a estrutura geral do software, tendo como ponto de vista a segurança, e identificar os componentes cujo funcionamento correto é essencial para a segurança (a "base de computação confiável"). Identificar técnicas de design, como a organização do software em componentes bem definidos e estruturados de forma a evitar dependências circulares entre componentes, o uso de linguagem com rigidez de tipos, a aplicação de privilégios mínimos e a minimização da superfície de ataque, que se aplicam ao software globalmente. Esses componentes são organizados em camadas, e uma camada mais alta pode depender dos serviços das camadas inferiores, mas o contrário é proibido. As particularidades dos elementos individuais da arquitetura serão detalhadas nas especificações individuais de design, mas a arquitetura de segurança identifica uma perspectiva geral no design da segurança.

Documentar os elementos da superfície de ataque do software. Como o software não atingirá uma segurança perfeita é importante que apenas os recursos que serão usados pela grande maioria dos usuários sejam expostos a todos eles por padrão, e que esses recursos sejam instalados com o nível de privilégio mais baixo possível. A medição dos elementos da superfície de ataque fornece à equipe de produto uma métrica constante da segurança padrão e permite que a equipe detecte as instâncias em que o software se torna mais suscetível a ataques. Algumas instâncias com uma maior superfície de ataque podem ser justificadas pela usabilidade ou função de produto avançada, mas é importante detectar e questionar cada uma dessas instâncias durante o design e a implementação, de forma a fornecer software com uma configuração padrão tão segura quanto possível.

Realizar