ATPS Desenvolvimento De Software Seguro

Passo 1 (Aluno)

Ler atentamente os capítulos do livro-texto ou complementar sobre a importância do Desenvolvimento de Software Seguro.

É importante que o software seja desenvolvido com segurança, a fim de diminuir o número de vulnerabilidades, que a cada ano vem crescendo. Para tanto, os requisitos de segurança da informação precisam ser incorporados em cada etapa do desenvolvimento, desde, o início do desenvolvimento de software até a etapa de implantação, pois quanto mais cedo forem identificadas as vulnerabilidades, menores serão os gastos no projeto, sendo de suma importância que os níveis de segurança de um produto sejam mensurados de acordo com o risco que apresenta.

No desenvolvimento do software é importante conhecer as vulnerabilidades de cada etapa do desenvolvimento para que as ameaças iminentes possam ser removidas da forma mais célere possível, eliminando assim os riscos da má gestão de custos e da descoberta de vulnerabilidades já na finalização do software. Quando a empresa sofre essas ameaças (ataques ou tentativas de ataques) é importante coletar as situações anteriores, a fim de que, os dados possam ser analisados sempre que um novo sistema for desenvolvido.

Como já dito, os níveis de segurança alteram de acordo com o âmbito de negócio que a empresa possui, logo é importante é importante reunir os *stakeholders para propor quais serão os critérios de avaliação para a implantação da segurança e quais serão os níveis de segurança.

Para que os problemas no desenvolvimento de softwares sejam atenuados, é preciso adotar padrões de códigos, normas e manuais de segurança a fim de que se possam evitar erros no código fonte, além da etapa de testes que será muito importante a cada nova implementação de levantamento de requisitos.

Passo 1.2 (Equipe)

Criar uma lista descrevendo pelo menos cinco Princípios de Segurança. Essa lista deve descrever cada princípio e destacar em qual fase de desenvolvimento pode ser empregada, pode-se basear o conjunto de fases do Modelo em Cascata (figura 1):

REQUISITOS

PROJETO/ANÁLISE

IMPLEMENTAÇÃO

TESTE

MANUTENÇÃO

1.2.1 Fases 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 integrados 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.

1.2.2 Fases 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 em camadas, 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. (Organização em camadas se refere à organização do software em componentes bem definidos e estruturados de forma a evitar dependências circulares entre componentes. Esses