Testes de Elite - Testando Código e Componentes Seguros

Segurança é importantíssima para os nossos sistemas e aplicativos modernos. E segurança forte requer o uso de uma série de tecnologias, como a criptografia e os módulos de hardware seguro, por exemplo. No entanto, como essas são tecnologias complexas, elas normalmente são encapsuladas dentro de componentes e serviços seguros e cujos APIs são consumidas por partes menos críticas da aplicação.

Isso traz um grande desafio - como testar esses componentes de software que foram projetados para serem seguros? Muitas vezes, na prática, para garantir que esses componentes realmente são seguros, é preciso lançar mão de técnicas e arquiteturas de teste não-convencionais. Descobre quais e como!

Transcript

1. www.nascent.com.br Testes de Elite Segurança em primeiro lugar Testando Código e Componentes Seguros Sean Michael Wykes
2. TDC / 2018 Sean Michael Wykes • British born and educated, living in Brazil since 1997 • Masters Degree (’92) in Information Engineering from Southampton University • 20+ years experience in design and development of systems and secure applications, based on technologies such as smart-cards and secure elements. • Author of “Criptografia Essencial - a Jornada do Criptógrafo” – Elsevier 2016. https://CriptografiaEssencial.com.br
3. TDC / 2018 3 Como Desenvolvemos 3 Software Seguro ? Testamos
4. TDC / 2018 4 Tríade da Segurança da Informação C I A T CONFIDENCIALIDADE Confidentiality INTEGRIDADE Integrity DISPONIBILIDADE Availability RASTREABILIDADE Traceability + Tétrade
5. TDC / 2018 5 Desenvolvimento Seguro Processos de Desenvolvimento Seguro Requisitos de Segurança, Design Seguro, Desenvolvimento de Código Seguro, Validação e testes de Segurança, SecDevOps Atividades Seguras Incluir atividades novas relacionadas à segurança, como a Modelagem de Ameaças, Revisão e Análise de Código e os Testes de Penetração Mindset de Segurança Pensar sobre segurança ajuda a: 1) pensar melhor sobre a solução e 2) desenvolver produtos melhores e mais seguros +
6. TDC / 2018 6 Thinking para Security Desenvolvedores
7. TDC / 2018 7 7 “Security Thinking é a mentalidade, ou mind- set, de tornar segurança uma parte integral do processo de desenvolvimento de software e hardware, através de uma compreensão da importância, complexidade, sutileza e profundidade da Segurança Sistêmica” Security Thinking
8. TDC / 2018 8 As 5 Máximas do Security Thinking Equilíbrio Simplicidade Desconfiança Encapsulamento Abertura
9. TDC / 2018 Os 4 Caminhos de Testes Seguros 1. FELIZ Condições de Erro Condições Maliciosas Condições Normais 2. INFELIZ Condições Excepcionais 3.FALHA 4. HACKED
10. TDC / 2018 10 O que é um “Componente Seguro” ?
11. TDC / 2018 11 Sistemas e Componentes Um Sistema é composto de Componentes v Componente pode ser classe, modulo, serviço, aplicativo, ... v Modelo de composição: subsistemas, sub-objetos, ... v O componente de uma pessoa é o sistema de outra Modularização v Separação regida pela arquitetura e tecnologia v Facilita na organização v Divisão de funções e responsabilidades
12. TDC / 2018 12 Sistemas e Componentes Virtualização e Containerização v Sandboxing: Contenção de falhas v DevOps: Agilidade, Disponibilidade, Escalabilidade Containers Seguros v Proteção de Dados e Processos Críticos v Exemplos: Smart-cards, Secure Elements, TEE / Enclaves, HSM
13. TDC / 2018 13 Seguro? O que significa mesmo? NFR-1: SEGURANÇA É UM REQUISITO NÃO-FUNCIONAL .. em todas as condições Deve ser 100% seguro .. protegido contra todos os ataques .. atuais e futuros. Como: Usabilidade Performance Disponibilidade Testabilidade Imprecisos Subjetivos Emergentes EXEMPLO ;)
14. TDC / 2018 14 Segurança na Realidade NFR-1: SITUAÇÃO DESEJADA .. em todas as condições Deve ser 100% seguro .. protegendo contra todos os ataques .. atuais e futuros. SEGURANÇA NA REAL • É uma propriedade emergente e dinâmica Emergente • Varia conforme o contexto e os pontos de vista Variável • Atacantes são inteligentes e inovam rapidamente Inovadora • Não existe nenhum pó mágico Complexa
15. TDC / 2018 15 Componentes x Segurança 1 2 3 Componente que não é inseguro Componente não contém bugs, falhas ou funcionalidades que podem ser aproveitadas por uma parte maliciosa. + possui features de segurança Incorpora ou chama funcionalidades explicitas que são necessárias para tornar o componente ou sistema seguro. + é um feature de segurança Provê serviços de segurança para outros componentes do sistema NÍVEL 0 Componente inseguro Componente contém falhas ou funcionalidades que podem ser aproveitadas por uma parte maliciosa.
16. TDC / 2018 16 Chega de blah-blah-blah! Sistema Real ! Vamos ver um
17. TDC / 2018 17 TOKEN CRIPTOGRÁFICO PARA CERTIFICAÇÃO DIGITAL Projeto INTERNET ID
18. TDC / 2018 18 Escopo e Entregáveis Cartão Inteligente (smart-card) Principais Funções: Gerar e armazenar Chaves Criptográficas RSA Armazenar Certificados Digitais X.509 Calcular Assinaturas Digitais Abrir Dados Criptografados Autenticar Usuário por código PIN / PUK administrativo Cryptographic Service Providers Desenvolver Componentes de Software para Windows, Linux e MacOS, que permitem uso do Token por Softwares Aplicativos Homologação Homologar o Token Criptográfico com ITI / IN-METRO Certificar o CSP-Windows com Microsoft WHQL Token Criptográfico
19. TDC / 2018 19 Aplicação Aplicação MS Crypto API PC/SC Gerenciador de Cartões Arquitetura da Solução Internet ID Smart Card MiniDriver Base SmartCard CSP PKCS#11 Crypto Token Interface ... PKCS#11 Smartcard APDU MiniDriver MS CryptoAPI APIs Token Criptográfico Componentes Minidriver.dll Token Criptográfico PKCS#11.dll / .so C S P T O K E N
20. TDC / 2018 20 APDU: Comunicação com Cartão APDU Command CLA INS P1 P2 DATA LC LE APDU Response DATA SW APDU Command APDU Response ~LE LC
21. TDC / 2018 21 Requisitos de Segurança do Token 21 1. Operações criptográficas com chaves somente devem ser permitidas após validação correta do código PIN. 2. Não deve existir nenhuma forma de extrair as chaves criptográficas do Token 3. Os códigos PIN e PUK não podem ser recuperados do Token, e devem ser protegidos contra tentativas incorretas excessivas. 4. Geração e escrita de chaves devem ser possíveis somente após validação do PIN ou PUK. 5. Após validação correta do PUK, deve ser permitida a gravação de um novo PIN. 6. O PUK administrativo não permite uso das chaves
22. TDC / 2018 22 Como Desenvolver e Testar 22 ? INTERNET ID
23. TDC / 2018 23 Testes da Solução Internet ID 1.Testes Unitários - devTest - 2 níveis de teste: TOKEN e CSP - 4 APIs 2.Testes de Integração - TOKEN + CSP 3.Testes de Aceitação - Homologação e Certificação
24. TDC / 2018 24 o Token Criptográfico Etapa 1 24 Desenvolver e Testar
25. TDC / 2018 25 Estratégia de DevTest para o TOKEN PC/SC Gerenciador de Cartões Token Criptográfico Test Runner 1. Testes Manuais 2. Testes Assistidos 3. Contrapartes do Domínio 4. Casos e Dados de Testes 5. Testes Automatizados Contrapartes do Domínio Gerador de Chaves Gerador de Certificados Validador de Assinaturas Cifrador de Dados Fases % complete
26. TDC / 2018 26 Desafios Jiga de Testes Não existe, tem que construir Para Debug, criar ferramenta UI Protocolos de Baixo Nível Construir Helpers – Build / Parse / Validate Encapsular “SUT” por APIs Roteiro de Testes Tem que elaborar – criar – inovar Security Thinking – 4 Caminhos de Teste
27. TDC / 2018 27 Desafios Conhecimentos Específicos É preciso conhecer profundamente a área específica Multidisciplinariedade Uso de Criptografia Dados Opacos, Aleatoriedade, Não-determinismo Testes dinâmicos - dados mudam a cada execução Contrapartes do Domínio SuperMocks - componentes que não fazem parte do escopo, mas que são necessários para os testes.
28. TDC / 2018 28 Testando o Caminho Feliz Criar casos de teste para: Dados e parâmetros válidos Sequências de operação corretas ...
29. TDC / 2018 29 Testando o Caminho Infeliz Criar casos de teste para: Dados e parâmetros inválidos nos pacotes APDU Sequências de operação incorretas ... Obs: Fica difícil usar componentes secundários reais para testar os caminhos Infeliz, Falhos e Ataques
30. TDC / 2018 30 Testando o Caminho da Falha Criar casos de teste para: Remoção do cartão e/ou Leitor Interrupção durante operação de gravação ... Obs: Precisará de apoio específico do framework Como desligar o cartão durante uma operação?
31. TDC / 2018 31 Testando o Caminho do Ataque Levantamento - Requisitos e Ativos O que tem de valor e que deve ser protegido? Como esses ‘ativos’ estão protegidos? Questionamento Funcionam as proteções? Como alguém mal-intencionado poderia tentar burlar os mecanismos de proteção? Validação e Saneamento Criar e executar casos de teste para verificar a ausência dessas vulnerabilidades. Requer técnicas diferenciadas e conhecimento dos tipos de vulnerabilidade.
32. TDC / 2018 32 os Provedores de Serviços Criptográficos Etapa 2 32 Desenvolver e Testar
33. TDC / 2018 33 Estratégia de DevTest para o CSP Test Runner 1. Testes Manuais 2. Contrapartes do Domínio 3. Casos e Dados de Teste 4. Tokens de Teste Contrapartes do Domínio Gerador de Chaves Gerador de Certificados Validador de Assinaturas Cifrador de Dados Fases % complete MS Crypto API PC/SC Gerenciador de Cartões Smart Card MiniDriver Base SC CSP PKCS#11 Crypto Token Interface Token Criptográfico Token Criptográfico 5. Testes Automatizados Token Criptográfico Token Criptográfico Token Criptográfico Token Criptográfico Metadados
34. TDC / 2018 34 Desafios Intestabilidade Como mockar objetos reais (PC/SC, BaseCSP, Token)? C/C++ compilado -> objeto opaco Invisibilidade Como validar os Meta-dados do Token? Manual: Incrementar UI de testes Testes de Equivalência CSP e PKCS#11 fazem as mesmas coisas? Interoperabilidade?
35. TDC / 2018 35 Dicas e Lições Aprendidas com testes de 35 COMPONENTES SEGUROS
36. TDC / 2018 36 Contrapartes do Domínio Em muitos casos, para cada feature de um componente seguro, será necessário construir uma ou mais contrapartes de testes. Contrapartes do Domínio A* B* D* C* Componente Seguro A B D C Features de Segurança SuperMocks Esses SuperMocks fazem operações seguras como geração, processamento e validação de elementos de dados do domínio. Frequentemente devem ser capazes de gerar elementos quase-válidos, a título de simular condições de ataque. Montar – Desmontar Enviar – Receber Encriptar – Decriptar Assinar – Validar
37. TDC / 2018 37 Proxies de Teste API’s internos não oferecem visibilidade do lado de fora. Componente Seguro A B C Problemas de Visibilidade
38. TDC / 2018 38 Proxies de Teste API’s internos não oferecem visibilidade do lado de fora. Componente Seguro A B C 1. Implementa API interno P 1 P2 Os Objetos Proxy (P1,P2) implementam os APIs internos e funcionam como provedores ou consumidores destes API. Por default, simplesmente REPASSEM. Problemas de Visibilidade 2. Liga Proxy ao Remoto Cada Proxy se comunica com um shim específico ligado a um objeto simulado, mock e/ou contraparte. O Proxy pode funcionar em quatro modos: REPASSAR, ESPIAR, PROVEDOR e CONSUMIDOR. Shims & Contrapartes A* S2 S 1
39. TDC / 2018 39 Afinal Qual o Perfil do Testador de Elite 39 ?
40. TDC / 2018 40 Tropa de elite “Termo normalmente utilizado para designar unidades militares com treinamento excelente e armamento superior” 40
41. TDC / 2018 41 “O Testador de Elite é o artesão dos testes” 41 Jairo Silveira Tondin
42. TDC / 2018 42 E.T. – O Testador de Elite Conhecimento Conhecer profundamente as técnicas de sec-app-dev, as vulnerabilidades, os ataques e as defesas Cada projeto e diferente, é preciso aprender rápido e fazer associações de ideias Pensar e enxergar além do Testador Funcional. Paciência e Flexibilidade Ter flexibilidade para sair da caixinha Ser detalhista ao ponto de exaustão Saber alternar repetidamente e rapidamente entre as fases de Descoberta, Experimentação, Definição e Validação Exercer curiosidade para fazer Testes Exploratórios
43. TDC / 2018 43 E.T. – O Testador de Elite Filosofia de Security Thinking Enxergar para cima – ver o contexto maior - e para baixo – perceber os detalhes suteis e ocultos. Conhecer e/ou Intuir onde e como o bicho vai pegar. Pensar como Defensor para compreender as proteções implementadas, e como Atacante para descobrir e identificar fraquezas potenciais. Autossuficiência Criar ferramentas pois as prontas muitas vezes não são adequadas Possuir pensamento e visão Multinível Ser Polivalente – combinação diversa de aptidões Saber Inovar nos casos e critérios de teste
44. TDC / 2018 44 Obrigado! sean.public@nascent.com.br https://www.linkedin.com/in/seanwykes/ Uma marca Nascent https://CriptografiaEssencial.com.br