1. Testes funcionais de segurança
1.1. Cobertura dos testes
1.1.1. Consiste em estabelecer a completude dos testes realizados, ou seja, se os testes realizados são ou não suficientes para demonstrar que a aplicação funciona da maneira como foi especificada.
1.2. Profundidade dos testes
1.2.1. Testes profundos são capazes de comprovar que a aplicação funciona corretamente com relação às suas funções que foram fornecidas externamente e também que os mecanismos internos de segurança estão operando como projetado.
1.3. Testes funcionais de segurança
1.3.1. Os testes funcionais são executados pelos desenvolvedores da aplicação. Eles têm a finalidade de garantir com que as funcionalidades de segurança realmente exibam as propriedades necessárias para satisfazer os requisitos funcionais da aplicação. Com a aplicação desses testes, garante-se no mínimo a satisfação dos requisitos funcionais de segurança, uma vez que os comportamentos não esperados (que é um conjunto infinito de situações) podem apenas ser reduzidos.
1.4. Testes independentes
1.4.1. Entretanto, o principal objetivo aqui é conter o risco de avaliações incorretas feitas por parte da equipe de desenvolvimento. Naturalmente, em função do conhecimento estrutural a respeito do funcionamento da aplicação, é comum que os desenvolvedores de software estejam mais propensos a deixar passar falhas e vulnerabilidades na aplicação que estão desenvolvendo.
2. Aceitação de Software
3. Avaliação de Vulnerabilidades
3.1. Análise de ameaças
3.1.1. Nesse caso, o papel do avaliador envolve identificar, estimar a capacidade, monitorar e analisar os cenários de exploração dos recursos e canais.
3.2. Uso inapropriado
3.2.1. Minimizar a probabilidade de que a aplicação seja configurada ou instalada de forma insegura, sem que o administrador ou usuário sejam capazes de detectar o problema. Minimizar o risco de que erros operacionais (humanos ou não) sejam capazes de desativar, desabilitar ou provocar falhas em funcionalidades de segurança, capazes de levar o sistema a um estado de insegurança não detectável.
3.3. Análise de documentação de ajuda
4. Conceitos de Segurança no Desenvolvimento de Software
4.1. ISO/IEC 15.408
4.1.1. Common criteria for information Technology
4.1.2. TCSEC - 1980 - "Orange Book" - Avalição de Segurança
4.2. Oragen book
4.2.1. Divisão D - proteção mínina
4.2.2. Divisão C - Proteção arbitrária
4.2.3. Divisão B - Proteção obrigatória
4.2.4. Divisão A - Proteção verificada
4.2.5. Cons
4.2.5.1. Fixava atributos de segurança em níveis estátivos
4.2.6. Pros
4.2.6.1. Bastante utilizado e difundido
4.3. Common Criteria
4.3.1. É um framework
4.3.2. Security Target
4.3.2.1. indica aspectos de segurança que foram considerados importantes e porque eles têm importância determinada sistema, é o documento que define os objetivos de segurança para o TOE. Cada objetivo deve ser avaliado com base nas implementações do sistema.
4.3.3. Protect Profile
4.3.3.1. Especifica uma classe de sistemas, descreve um conjunto de requisitos de segurança para uma classe ampla de dispositivos de segurança
4.3.4. Target of Evaluation
4.3.4.1. Esse sistema deve ter funções de segurança que são o conjunto de rotinas responsáveis por garantir a política de segurança do TOE
4.3.5. Evaluation Assurance Level
4.3.5.1. EAL-1
4.3.5.2. EAL-2
4.3.5.3. EAL-3
4.3.5.4. EAL-4
4.3.5.5. Extramente Rígidos
4.3.5.5.1. EAL-5
4.3.5.5.2. EAL-6
4.3.5.5.3. EAL-7
5. Desenvolvimento Seguro
5.1. Segurança do ambiente de desenvolvimento
5.1.1. Restrições de entrada e saída
5.1.2. Máquina de build específica
5.1.3. Processo definido de liberação de versões
5.1.4. Controle de acesso físico
5.1.5. proteção lógica de servidores
5.1.6. Equipe de testes capacitada
5.2. Segurança da aplicação desenvolvida
5.2.1. Aplicar as boas práticas de programação
5.2.2. Verificação de erros
5.2.3. Utilizar funções intrinsecamente seguras. Tratar variáveis de entrada.
5.2.4. Verificar o tamanho de buffers e arrays
5.3. Segurança para o cliente
5.3.1. Garantir a segurança para o cliente significa oferecer não só uma aplicação segura, mas também possibilitar que o cliente também se assegure de que o sistema é seguro.
5.4. Garantia de segurança
5.4.1. Escopo
5.4.2. Profundidade
5.4.3. Rigor
5.5. Os níveis de Garantia
5.6. Requisitos de Segurança
5.6.1. EAL-1
5.6.1.1. Nesse nível, as ameaças à segurança ainda não são vistas como sérias, e a avaliação é feita com base na aplicação entregue ao consumidor. A avaliação toma como base testes independentes, feitos de acordo com a especificação, e o exame da documentação de ajuda fornecida.
5.6.2. EAL-2
5.6.2.1. O nível de garantia EAL-2 é aplicado quando se requer a cooperação do desenvolvedor para fornecer informações de projeto e resultados de testes, de acordo com as práticas comerciais padrão (best practices). O nível EAL-2 ainda não requer um aumento substancial com relação aos investimentos financeiro e de tempo.
5.6.3. EAL-3
5.6.3.1. O EAL-3 possibilita que uma equipe de desenvolvimento obtenha o máximo de garantia de segurança, ainda no estágio de projeto do sistema, sem no entanto alterar suas práticas habituais de desenvolvimento. Esse nível de segurança requer uma investigação completa a respeito da aplicação e de seu desenvolvimento, sem a necessidade de uma reengenharia.
5.6.4. EAL-4
5.6.4.1. nível de garantia de segurança EAL-4 permite que a equipe de desenvolvimento obtenha o máximo de segurança através da engenharia de segurança, baseada em boas práticas de desenvolvimento. Mas, apesar do rigor, não requerem conhecimento especialista substancial, habilidades e outros recursos. De qualquer forma, esse é o mais alto nível de garantia a ser aplicado de forma economicamente viável.