Gerencia De Projeto

Anhanguera Educacional

Faculdade de Negócios e Tecnologias da Informação

Bacharelado em Sistemas de Informação

Atividades Práticas Supervisionadas

Relatório das Etapas 1 e 2

.

Disciplina: Desenvolvimento de Software Seguro

Professor: Hirlei

Semestre: 5º “B”

RA Nome

3799533489 Ernane Prado Zampier

4442883710 José Carlos de Almeida Junior

3715672271 Luiz Guilherme dos Reis Costa

4242843724 Suelayne Pereira de Oliveira Soares

4200057845 William da Silva Ganzela

Brasília – DF

25/03/2014

ETAPA 1 (tempo para realização: 4 horas)

 Aula-tema: Segurança Atualmente. Técnicas Seguras de Codificação: Estouro de Buffer, Controle de Acesso Apropriado.

PASSOS

Passo 1 (Aluno)

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

Passo 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:

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.

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 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 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