segurança da informação na...

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Escola Superior de Tecnologias da Saúde de Coimbra

Segurança da Informação na Saúde

Rafael Rosa Simões

Mestrado em Sistemas e Sistemas da Informação para a Saúde Coimbra, Setembro, 2012

Instituto Politécnico de Coimbra

Instituto Superior de Engenharia de Coimbra

Escola Superior de Tecnologias da Saúde de Coimbra

Mestrado em Sistemas e Sistemas da Informação para a Saúde

Estágio/Projeto Relatório Final


Rafael Rosa Simões

Orientador: João Cunha

Grau Académico: Doutor

Instituição: ISEC

Co- Orientador: Luís Santos

Grau Académico: Mestre

Instituição: ISEC

Coimbra, Setembro, 2012


I

Agradecimentos

Dedico em especial este trabalho à minha namorada Denny, aos meus pais Joaquim e

Rosa bem como à minha madrinha Irene, que sempre me apoiaram e incentivaram na

realização do meu Mestrado. Mesmo nas alturas mais difíceis não me deixaram

desistir de lutar.

Desejo também agradecer aos meus orientadores Doutor João Cunha e Mestre Luís

Santos pelas críticas e sugestões dadas, em especial ao Mestre Luís Santos por

“simplesmente” me ter permitido seguir para a frente com este projeto. Sem dúvida

contribuíram imenso para a conclusão do meu Mestrado.

Desejo ainda agradecer à ISA pela oportunidade da realização do estágio, em especial

à Mestre Ariadne Pacheco pelas dicas e por me ter permitido a flexibilidade de horário

necessária à conclusão do estágio.

Por fim, desejo agradecer aos meus colegas de trabalho durante a realização deste

trabalho, aos colegas do MSTIS e em especial aos meus parceiros de investigação

António Simões e Rui Martins.

A todos os que mencionei, e aos que não mencionei, mas que sabem que lhes estou

agradecido,

Um grande bem-haja!


II

Resumo

A segurança da informação é uma temática que cada vez mais se justifica abordar

proactivamente. Em média (e apenas relativamente à esfera informática), oito adultos

por segundo são vítimas de crime de usurpação de informação. Quando se lida com

informação sensível como aquela que se encontra ligada à saúde as preocupações

redobram-se, devendo os cuidados de segurança ser igualmente multiplicados.

Como forma de pensar, estruturar e agir perante o desafio de abordar de modo

sistemático o tema da segurança numa empresa focada no desenvolvimento de

sistemas de informação para a saúde, foram estudadas algumas das normas

internacionais mais relevantes na área, bem como legislação e regulamentação

relacionada, em vigor no espaço jurídico em causa (Portugal, Comunidade Europeia).

No seguimento de tal esforço foram desenvolvidas diversas ferramentas genéricas de

suporte à adoção da norma ISO 27001 no contexto da empresa de acolhimento do

estágio. Foi igualmente revisto, no âmbito dos procedimentos impostos pela Comissão

Nacional de Proteção de Dados (CNPD), o conjunto de requisitos arquiteturais de uma

plataforma de serviços de informação para a saúde, em desenvolvimento.

Palavras-Chave

Segurança da informação

Segurança da informação na saúde

ISO 27001

CNPD (Comissão Nacional de Proteção de Dados)


III

Abstract

Information security is an issue that, more than ever, should be addressed proactively.

On average (and only in the information technologies sphere), in every second, eight

adults are victims of information theft. When dealing with highly sensitive information,

such as the one related to health care, these concerns are multiplied, and the same

should happen with safety precautions.

As a way of thinking, structuring and acting the challenge of systematically addressing

the issues related to security in a company focused on the development of information

systems for health care, during this internship some of the most relevant international

standards in the area, as well as laws and regulations in Portugal and the European

Community, were studied.

Following this effort, some generic tools were developed for supporting the adoption of

ISO 27001 in the context of the internship host company. Furthermore, a set of

architectural requirements for a platform of information services for health development

It was also amended revised under the procedures requirements laid down by the

National Commission for Data Protection (CNPD), the set of architectural requirements

of a platform of information services for health development.

KeyWords

Information Security

Information security in healthcare

ISO 27001

CNPD (National Commission for Data Protection)


IV

Termos e definições

Alternext Mercado internacional de ações destinado às PME

Ameaça Ameaça[41] surge como a possibilidade de um agente (ou fonte de

ameaça) explorar acidentalmente ou propositalmente uma

vulnerabilidade específica

Anti-malware Aplicativo de remoção de software malicioso

Backup Salvaguarda de informação, cópia de segurança

Benchmarking Medição de desempenho

Checklist Lista de controlo

CNPD Comissão Nacional de Proteção de Dados

Dados pessoais Qualquer informação relativa a uma pessoa singular identificada

ou identificável (“pessoa em causa”)

Disaster

Recovery

Recuperação de Desastres

EA Enterprise Architect

ECommerce Comércio eletrónico

ESTeSC Escola Superior de Tecnologias da Saúde de Coimbra

Ficheiro de

dados pessoais

Qualquer conjunto estruturado de dados pessoais, acessível

segundo critérios determinados

Firewall Dispositivo informático de bloqueio de acesso, entre outros

Fonte de

Ameaça

Fonte de Ameaça[41] é a intenção ou método com o objetivo da

exploração de uma vulnerabilidade ou uma situação e método que

pode acidentalmente despoletar uma vulnerabilidade

Framework Biblioteca de documentos

Gap Analysis Análise de lacunas

Healthcare Cuidados de saúde / área da saúde

IEC International Electrotechnical Commission

IM Instant messaging – serviço de mensagens instantâneas

Informática de

Saúde

Disciplina cientifica dirigida ao estudo do processamento de

informação e da comunicação da mesma na área da Saúde

Interconexão (inter + conexão) Relação ou ligação entre duas ou vários

elementos

Interconexão de

dados

Forma de tratamento que consiste na possibilidade de

relacionamento de dados de um ficheiro com dados de um ficheiro

ou ficheiros mantidos por outro ou outros responsáveis


V

ISA Empresa “Intelligent Sensing Anywhere, S.A”

ISEC Instituto Superior de Engenharia de Coimbra

ISMS (ou SGSI) Information security management system (ou Sistema de Gestão

de Segurança da Informação)

ISO International Organization for Standardization

ISO 27001 ISO / IEC Norma 27001

ISP Internet Service Provider– provedor de serviços WEB

IT Systems

Administrator

Administrador de Sistemas informáticos

Kerberos V5 Protocolo de autenticação de rede

Know-How Conhecimento ou “Saber Fazer”

Middleware Camada virtual entre a camada de hardware e de software

Modelo OSI Permite comunicação entre máquinas diferentes e define diretivas

genéricas para a construção de redes de computadores

independente da tecnologia utilizada. Esta arquitetura é um

modelo que divide as redes de computadores em 7 camadas, de

forma a se obter camadas de abstração

Não repúdio Fornece a garantia elevada de que algo é genuíno, e que não

pode ser subsequentemente refutado

NIST National Institute of Standards and Technology

NTLM Protocolo de autenticação

NVD National Vulnerability Database

OCTAVE Modelo de segurança da informação - Operationally Critical

Threat, Asset, and Vulnerability Evaluation

OneCare Produto ISA destinado à área da saúde e bem-estar

OpenProject Software grátis de gestão de projeto

Patches “Remendo” ou correção

PME Pequenas e Médias Empresas

Risco Risco surge como a probabilidade de uma fonte de ameaça

explorar uma vulnerabilidade, resultando num impacto para a

organização

Road Map Caminho a seguir

Sockets de

segurança

Camada de sockets protegida - método de segurança das

transações efetuadas via Internet (Ex. SSL)

SVN Apache Subversion, controlo de versões

TLS Mecanismo de segurança da camada de transporte de dados em


VI

rede

Tratamento de

dados pessoais

Qualquer operação ou conjunto de operações efetuadas sobre

dados pessoais

Vulnerabilidade Vulnerabilidade[41] é uma falha ou fraqueza de procedimento,

design, implementação, ou controlos internos de um ativo que

possa ser acidentalmente ou propositalmente explorada,

resultando numa brecha de segurança ou violação da política de

segurança do sistema

Workshops Ações de formação


VII

Índice

1. INTRODUÇÃO....................................................................................................... 1

1.1 APRESENTAÇÃO DO PROJETO/ESTÁGIO .............................................................. 1

1.2 FERRAMENTAS UTILIZADAS ............................................................................... 2

1.3 APRESENTAÇÃO DA ORGANIZAÇÃO .................................................................... 3

1.4 METODOLOGIA DE TRABALHO ............................................................................ 3

1.5 CONTRIBUTOS DESTE TRABALHO ....................................................................... 3

2. SEGURANÇA DA INFORMAÇÃO ......................................................................... 5

2.1. SÉRIE DE NORMAS ISO / IEC 27000 .................................................................. 7

3. GUIA DE IMPLEMENTAÇÃO .............................................................................. 25

3.1. FERRAMENTA DE GESTÃO DA IMPLEMENTAÇÃO ................................................. 25

3.2. DIAGRAMA DE IMPLEMENTAÇÃO ISO27001 ...................................................... 30

3.3. EXPLICAÇÃO DO PLANO DE IMPLEMENTAÇÃO .................................................... 33

3.4. RECOMENDAÇÕES DE ADAPTAÇÃO .................................................................. 34

4. CASO PRÁTICO DE IMPLEMENTAÇÃO ISO 27001 .......................................... 36

4.1. LEVANTAMENTO DE ATIVOS ............................................................................. 36

4.2. CLASSIFICAÇÃO / MANUSEAMENTO DA INFORMAÇÃO ........................................ 39

4.3. VULNERABILIDADES ........................................................................................ 40

4.4. TRATAMENTO DE RISCO .................................................................................. 46

4.5. ANÁLISE DE LACUNAS ..................................................................................... 55

4.6. CONCLUSÕES RETIRADAS DO CASO PRÁTICO ................................................... 59

5. CONFORMIDADE LEGAL DO PRODUTO ONECARE V2 .................................. 61

5.1. GUARDA DE DADOS DE SAÚDE ......................................................................... 62

5.2. REQUISITOS LEGAIS ........................................................................................ 63

5.3. ISO 27799 – ESPECIFICAÇÕES E CONTROLOS APLICÁVEIS AO ONECARE ........... 68

5.4. ARQUITETURA ONECARE V2 ........................................................................... 72

5.5. FUNCIONAMENTO DA ARQUITETURA ONECARE V2 – RESPOSTA À CNPD ........... 75

6. CONCLUSÕES.................................................................................................... 79

REFERÊNCIAS .......................................................................................................... 81

ANEXOS ..................................................................................................................... 83


VIII

Índice de Anexos

Anexo 1 - ISO 27799 – Especificações e controlos aplicáveis ao OneCare

Documento onde são resumidas as implicações da norma ISO 27799 ao produto

OneCare.

Anexo 2 - Reuniões de acompanhamento

Documento que tem listadas as reuniões de acompanhamento efetuadas entre o

autor deste trabalho e os seus orientadores.

Anexo 3 – Classificação / Manuseamento da Informação

Documento exemplo de matriz de classificação da informação numa empresa.

Anexo 4 – Listagem de riscos/ameaças

Documento de registo e catalogação de riscos numa empresa.

Anexo 5 – Listagem de vulnerabilidades + CVSS

Documento de registo, cálculo e avaliação de vulnerabilidades através do

modelo CVSS.

Anexo 6 – Priorização do tratamento de risco

Documento / calculadora de risco, servindo para através do risco total priorizar o

tratamento dos riscos potencialmente mais nefastos.

Anexo 7 - RTP Risk Treatment plan

Documento de tratamento de risco.

Anexo 8 - Gap-Analysis- Controls

Documento de análise de lacunas na implementação de determinados controlos

na empresa.

Anexo 9 - Relatório de análise de falhas

Documento que resume o documento de análise de lacunas.

Anexo 10 - Explicação do Plano de implementação ISO 27001

Documento explicativo de todas as fases de implementação da norma ISO

27001.

Anexo 11 - Listagem e classificação de Ativos

Documento exemplo de registo e classificação de ativos de informação numa

empresa

Anexo 12 - MSTIS Proposta de Projeto

Proposta inicial projeto de mestrado entregue à comissão pedagógica do MSTIS.

Anexo 13 - Plano de implementação da norma ISO 27001 numa PME.

Anexo 14 - Dimensão da vulnerabilidade (CVSS)


IX

Índice de Figuras

Figura 1- Adoção ISO 27001 por sector ........................................................................ 7

Figura 2- Ciclo PDCA .................................................................................................. 10

Figura 3- Controlos ISO 27002 ................................................................................... 21

Figura 4- Documento de Gestão da implementação (vista parcial) ............................. 26

Figura 5 - Relatório exemplo ....................................................................................... 27

Figura 6 - tempos de implementação .......................................................................... 29

Figura 7 - Ciclo PDCA com esquema de cores ........................................................... 31

Figura 8- Diagrama de implementação ....................................................................... 32

Figura 9 - Ex. Explicação do plano de implementação ................................................ 33

Figura 10 - Listagem e Classificação de Ativos ........................................................... 38

Figura 11 - classificação da informação ...................................................................... 40

Figura 12 - Métricas CVSS ......................................................................................... 41

Figura 13 - Calculo CVSS ........................................................................................... 45

Figura 14 - Listagem de Vulnerabilidades ................................................................... 46

Figura 15 - Listagem de Risco .................................................................................... 48

Figura 16 - Priorização do tratamento de risco............................................................ 49

Figura 17 - Risk treatment plan ................................................................................... 55

Figura 18 - Gap Analysis ............................................................................................ 56

Figura 19 - Relatório de análise de falhas ................................................................... 57

Figura 20 - Exemplo de nível de maturidade CMM ..................................................... 58

Figura 21 - Ambiente de trabalho Enterprise Architect – desenho OneCare v2........... 73

Figura 22 - esquema de comunicação OneCare v2 .................................................... 74

Figura 23- Ex. Restrições Legais ................................................................................ 74

Figura 24- Ex. Restrições Técnicas ............................................................................ 74

Figura 25- Ex. Atributos de qualidade ......................................................................... 75

Figura 26 - Disponibilidade da autenticação ............................................................... 76

Figura 27- Replicação de backups por SFTP .............................................................. 78


X

Índice de tabelas

Tabela 1 – Domínios específicos ISO 27000 ................................................................ 8

Tabela 2 - Normas Nucleares ISO 27000 ..................................................................... 9

Tabela 3- legenda diagrama de implementação ......................................................... 31

Tabela 4 - Dimensão do Risco .................................................................................... 50

Tabela 5 - impacto do risco ......................................................................................... 50

Tabela 6 - aceitação de risco ...................................................................................... 51

Tabela 7 - Matriz CIA .................................................................................................. 54

Tabela 8 - Avaliação Simplificada de Risco ................................................................ 54

Tabela 9 - Tempo de guarda de dados ....................................................................... 63

Cap.1 - Introdução Segurança da Informação na Saúde

1

1. Introdução

Este estágio enquadra-se no plano curricular do Mestrado em Sistemas e Tecnologias

da Informação para a Saúde, lecionado em parceria pelo ISEC – Instituto Superior de

Engenharia de Coimbra e pela ESTeSC – Escola Superior de Tecnologias da Saúde

de Coimbra.

O estágio realizou-se na ISA (empresa apresentada em detalhe no ponto

“Apresentação da Organização”, mais à frente no relatório) onde para além de

estagiário na área da segurança de informação, cumpro funções de administrador de

sistemas e redes informáticas (IT Systems Administrator), cargo que não relacionado

com este estágio em segurança da informação.

1.1 Apresentação do projeto/estágio

Este projeto/estágio tem como âmbito a segurança da informação e a segurança da

informação na área da saúde, abordando algumas das normas existentes na área e

ainda o tratamento de dados sensíveis, no caso, dados de saúde e todas as restrições

legais e de segurança que este acarreta.

Podemos dividir o projeto / estágio em 4 partes principais, a segurança da informação,

o guia de implementação ISO 27001, caso prático de implementação ISO 27001 e o

produto OneCare na vertente da autorização de tratamento de dados:

1.2.1. Segurança da informação

O objetivo desta fase/parte do estágio era estudar uma forma de tornar todos os

processos de interação com a informação, troca, manuseamento, tratamento de

informação (informação empresarial e informação de saúde), etc… mais seguros

(mantendo a disponibilidade, confidencialidade e integridade da informação), com o

objetivo de mitigar todos os riscos de segurança a que a informação da empresa está

sujeita.

1.2.2. Guia de implementação ISO 27001

Com esta parte pretendeu-se criar uma ferramenta de ajuda importante à

implementação da norma ISO/IEC 27001 na empresa, são explicadas todas as fases,

são descritos os recursos envolvidos e foram criados documentos e ferramentas de

exemplo para a maioria das fases e tarefas envolvidas na implementação da norma.


2

Nesta fase foram desenvolvidas três ferramentas. Um plano de implementação

explicado, um gráfico temporal Gantt de implementação e recursos envolvidos e um

diagrama de implementação, que se interligam entre si para facilitar o processo de

implementação da norma ISO 27001.

1.2.3. Caso prático

Esta parte teve como objetivo efetivar na prática algumas fases do guia de

implementação da fase anterior e assim avaliar a sua validade prática e aperfeiçoar o

guia com a experiencia da implementação prática de algumas fases. Desde o

levantamento de ativos de informação até à priorização de tratamento de risco, foram

efetuadas na prática algumas tarefas de implementação da norma ISO 27001.

1.2.4. Conformidade legal do produto OneCare v2

O OneCare é um produto da ISA destinado aos mercados da saúde e bem-estar, que

pela natureza dos mercados em questão, trata dados sensíveis, sendo esses dados

alvo de atenção especial por parte das organizações.

O objetivo desta parte do estágio foi efetuar o levantamento dos requisitos necessários

para obter aprovação por parte da comissão nacional de proteção de dados (CNPD)

para que o produto OneCare pudesse tratar dados sensíveis, mais propriamente

dados de saúde.

Participei também no desenho da arquitetura de comunicação e no levantamento de

toda a legislação que era necessária cumprir para a autorização por parte da CNPD.

1.2 Ferramentas utilizadas

Durante a elaboração deste projeto / estágio foram usadas as seguintes ferramentas

para auxílio ao cumprimento das diversas tarefas efetuadas:

Assembla – Repositório com suporte a controlo de versões

Dropbox – Repositório usado para documentos de pesquisa

Google – Pesquisa e recolha de informação

Microsoft Office (Word, Excel e Power Point) - Construção de documentação,

formulários, apresentações e folhas de cálculo

Moodle – Repositório de documentos e partilha com orientadores

Open Project – Criação do plano de implementação

Tortoise SVN – Cliente controlador de versões em ficheiros

Wuala – Backup (cópia de segurança) e proteção da documentação na internet

Youtube – Pesquisa sobre as normas e ferramentas de implementação

Zotero – Gestão de bibliografia e referências

Linked In – Grupo de discussão “ISO 27001 Lead Auditors Group”


3

1.3 Apresentação da Organização

A ISA - Intelligent Sensing Anywhere, S.A é uma empresa de base tecnológica que

desenvolve produtos e implementa soluções completas, para o mercado global, nas

áreas da Telemetria e Gestão Remota, Instrumentação, Automação e Controlo e

tecnologias para a saúde assentes em tecnologia e know-how específicos nos campos

da eletrónica, software, sensores, telemetria e controlo.

As soluções de telemetria e controlo da ISA são aplicáveis a um largo espectro de

mercados, os primeiros em que a ISA adquiriu know-how e para os quais desenvolveu

um conjunto de soluções completas, reconhecidas e implementadas

internacionalmente, foram o mercado da telemetria do ambiente (monitorização da

qualidade do ar e das águas) e o mercado da telemetria do gás e dos combustíveis

líquidos (monitorização de reservatórios e de contadores).

Atualmente a oferta da ISA alargou-se aos mercados da Energia, da Segurança e da

Saúde (no qual este estágio se integra).

A ISA está atualmente presente em bolsa, sendo a primeira empresa portuguesa no

Alternext, mercado internacional de ações destinado às PME.

A ISA atua num leque diversificado de áreas. No entanto o estágio considerou a ISA

como PME focada exclusivamente na saúde, considerando-a reduzida à sua unidade

de negócio ISA Intellicare (responsável pelo desenvolvimento da família de produtos

OneCare).

1.4 Metodologia de trabalho

Foram efetuadas reuniões de seguimento com os orientadores num período variável

de uma semana ou duas semanas entre si (ver anexo 2), dependendo da dimensão e

complexidade do trabalho e correções exigidas entre cada reunião.

Existiam reuniões de trabalho com os responsáveis de pelo desenvolvimento e pelo

produto OneCare v2, no intuito de acompanhar o trabalho efetuado no âmbito da

segurança e autorização do produto.

Foi criada uma sinergia com um grupo de projeto de licenciatura (António Simões e

Rui Martins) na área da segurança, para troca de ideias e discussão de temas, onde

tínhamos reuniões pelo menos de cariz semanal. Esta sinergia permitiu-nos uma

abordagem mais prática, visto termos feito uma parceria virtual de empresa de

auditora com empresa a implementar.

1.5 Contributos deste trabalho

O contributo do trabalho desenvolvido vai para além do que foi possível apresentar em

relatório, em especial para o conhecimento do autor, aumentando em muito o seu


4

conhecimento acerca da legislação nacional de tratamento / proteção de dados

pessoais, e possibilitou-lhe aumentar também o know-how em normas e modelos de

segurança, especialmente das normas da série ISO / IEC 27000.

Para a organização ISA, pensa-se que no mínimo este trabalho contribui com uma boa

ferramenta de ajuda à implementação da norma ISO 27001 visto ter sintetizadas todas

as normas da série 27000 num documento de explicação que indica por cada fase o

que é necessário ser produzido e o que é necessário ser documentado e discutido,

uma estimativa temporal do esforço de implementação e ainda uma aproximação aos

recursos envolvidos em cada fase de implementação. Na área do tratamento de dados

de saúde, foram levantados, discutidos e documentados todos os requisitos legais

para o tratamento de dados sensíveis.

Cap.2 - Segurança da informação Segurança da Informação na Saúde

5

2. Segurança da informação

A Segurança da Informação refere-se à proteção existente sobre a totalidade da

informação de uma determinada organização ou pessoa. Entende-se por informação

todo e qualquer conteúdo ou dado que tenha valor para qualquer organização ou

individuo. Esta pode estar armazenada para uso restrito ou exposta ao público para

consulta ou aquisição.

Durante a execução deste trabalho, inicialmente procurou-se estudar os melhores

métodos, normas e modelos que permitissem aumentar a segurança da informação de

uma organização, e logo aí surgiram uma imensidão de escolhas. A segurança de

determinada informação pode ser afetada por fatores comportamentais e de uso de

quem a utiliza, pelo ambiente ou infraestrutura que a suporta, ou ainda por indivíduos

mal-intencionados, que têm o objetivo de subtrair, destruir ou modificar essa

informação[36][37]. A segurança da informação de saúde surge como uma área

específica da segurança da informação, esta área devido ao seu caracter sensível

possui nuances especiais, sempre que se justifique serão apresentados os cuidados

específicos a ter com a segurança da informação em saúde.

Uma das primeiras tarefas realizadas foi o levantamento desses mesmos modelos e

normas (COBIT, modelo OCTAVE, Serie ISO27000), selecionando os mais atuais,

com mais aceitação a nível do mercado e também porque se adequam à área da

Saúde, sendo amplamente usados nesta área.

Um pormenor notado durante este período de estudo, foi que de que os próprios

autores e colaboradores das normas e modelos de segurança, tendem a banalizar o

termo “informação” e em muitos pontos das normas, abordam a “informação” como se

apenas existisse informação em formato digital, seja, a segurança informática. Esta

abordagem minimalista de segurança da informação não é de todo correta, visto que o

objeto seguro pode e deve ser considerado nas diversas fases da sua utilização

(armazenamento, transporte e processamento) e no contexto dos múltiplos

intervenientes envolvidos (pessoas, dispositivos, sistemas de transmissão, etc.).

Valerá a pena assegurarmos que a informação contida nos computadores da nossa

empresa está segura e, depois esquecermo-nos de por exemplo uma folha de papel

em cima da mesa com as senhas de acesso a esses mesmos dados?

Não nos devemos esquecer que fragmentos críticos de informação (na forma de

conhecimento de parâmetros ou procedimentos) de uma organização se encontram

muitas vezes armazenados apenas na memória de certos colaboradores.


6

Uma proteção adequada da mesma (em termos de disponibilidade, por exemplo)

passará pela criação de mecanismos de redundância que envolvam, por exemplo,

uma rotatividade laboral adequada que force a partilha do conhecimento por outros

colaboradores. Nunca devemos esquecer que a informação não se resume à contida

em ficheiros de computador e, que esta transita por diversos meios, não apenas em

redes informáticas. Informação existe num conjunto vasto de formatos, formato digital,

formato físico (em papel, por exemplo), etc.. e é transmitida também em diversos

meios, transmitida por meio digital (email, SMS, etc…), por meio físico (Ex. em carta

de papel) e está ainda contida em outros formatos, por exemplo no cérebro humano.

De entre todos métodos de segurança, foi decidido por parte do autor, dos

orientadores e da entidade acolhedora do estágio, que se iria estudar mais

detalhadamente a série de normas ISO / IEC 27000 e a sua implementação.

A série de normas ISO / IEC 27000[14] tem tido um grande crescimento a nível

mundial, e espera-se que cresça ainda mais nos próximos anos. Torna-se já como a

referência mundial[20] em segurança da informação, pois é abrangente e amplamente

aceite estimando-se que 87%[20] das organizações que implementaram a norma ISO

27001, obtiveram resultados positivos ou mesmo resultados muito positivos como

outcome da implementação. Existe também uma vantagem competitiva desta norma

com as restantes, esta é compatível com a família de normas ISO, permitindo muitas

empresas a implementar em conjunto com a ISO 27001 outras normas ISO, ex. ISO

9001.

Figura 1- Adoção ISO 27001 por sector in [20]


7

A ISO 27001 é bastante mais usada nos setores das empresas de IT e software (25%

do mercado) (ver Figura 1- Adoção ISO 27001 por sector )[14], de destacar também

as empresas da área da saúde que já ocupam mais de 10% do mercado das

empresas que seguem a norma ISO 27001.

2.1. Série de normas ISO / IEC 27000

Esta série de normas surge de um esforço conjunto da ISO (International Organization

for Standardization) e IEC (International Electrotechnical Commission) com o intuito de

criar um sistema de gestão da segurança da informação semelhante em design ao

sistema de gestão da qualidade já existente (a sério ISO 9000). Esta série teria de

conter um conjunto de boas práticas, recomendações em segurança da informação e

deveria abordar o risco que a informação corre e os respetivos controlos para esses

riscos. A série é muito ampla, abrangendo desde a privacidade passando pela

confidencialidade, acabando pelos minuciosos pormenores das falhas técnicas de

equipamentos. Foi assim criado um modelo dinâmico e aplicável a todos os tipos de

empresas, pequenas, médias, grandes, etc… que promove uma melhoria continua

através de um ciclo de feedback para melhorias contínuas, denominado ciclo PDCA

(plan-do-check-act em português planear-efetuar-verificar-agir).

A série ISO 27000 é então um conjunto de normas onde existem diretrizes e boas

práticas de planeamento, implementação e gestão de segurança em segurança de

informação. Esta série de normas é a evolução natural de normas anteriores. A norma

ISO 27001 representa uma evolução da antiga BS 7799-2, a ISO 27002 a evolução da

antiga ISO 17799 e a ISO 27005 a evolução da antiga BS 7799-3. As normas BS, de

British Standards, têm origem nesta instituição Britânica com a função de criar normas

e padrões a serem seguidos no Reino Unido, é um dos principais organismos

colaboradores ISO, estando mesmo na origem de normas como a ISO 9001[9]. Em

Novembro de 2005[10] a ISO deu início à criação desta série com o objetivo de

reorganizar um inúmero conjunto de normas de segurança da informação existentes

na altura, sem ligação entre elas.

Desde já interessa salientar que deste conjunto / série de normas, a única passível a

certificação é a norma 27001 (ISO/IEC 27001), sendo as outras complementos de

auxílio à certificação em áreas específicas de atividade. Podendo afirmar que se o

sistema de gestão de segurança da informação (SGSI) cumprir e implementar o

especificado nas restantes normas, o processo de certificação da ISO 27001 será

potencialmente melhor sucedido.


8

As normas 27000 e 27001 são introdutórias e referem-se a procedimentos de

implementação, ao invés das restantes que são focadas em determinadas áreas

específicas. A título de exemplo apresentam-se na Tabela 1 alguns dos domínios

específicos entretanto cobertos:

Tabela 1 – Domínios específicos ISO 27000

Norma Áreas de Domínio

27017 Segurança em serviços “Cloud” (Cloudcomputing)

27799 Segurança da informação na área da saúde

27006 Requisitos para organismos de auditoria e certificação de

sistemas de informação de gestão de segurança.

27015 Diretrizes para os sectores de finanças e seguros (Ainda

em Preparação)

27018 Privacidade na “Cloud” (Cloudcomputing)

27031 Guidelines para as tecnologias da informação e

comunicação – objetivo a continuidade do negócio.

27036 Diretrizes para a segurança de subcontratados (Ainda em

Preparação)

27037 Diretrizes para aquisição, identificação e preservação de

provas digitais (Ainda em Preparação)

27799 Gestão da segurança da informação na Saúde

27034 Guia para a segurança de aplicações informáticas (Ainda

em Preparação)

27013 Orientação sobre a aplicação integrada da ISO 20000-1 e

ISO 27001 (Ainda em Preparação)

27014 Framework para governação em Segurança da

Informação (Ainda em Preparação)

27032 Guia para segurança cibernética (Ainda em Preparação)

27033 Network Security – Segurança em redes informáticas

(Ainda em Preparação)

O número de áreas específicas cobertas pela série ISO 27000 não tem parado de

aumentar, tendência que certamente se manterá nos próximos anos. Desta tendência

resultará uma acreditação geral de âmbito mais alargado que reforçará o peso da

norma base na comunidade como referência incontornável na temática da segurança

de informação.

Para além das normas anteriores (Tabela 1), especificas de um determinado domínio,

a série ISO 27000 atualmente também ainda conta com as seguintes normas

nucleares, aplicáveis a todos os domínios e áreas de negócio:


9

Tabela 2 - Normas Nucleares ISO 27000

A norma ISO 27001 representa o ponto de partida das restantes normas da série, pelo

que considera-la de modo isolado para pouco sirva. A norma ISO 27001 especifica

orientações e requisitos genéricos, necessários à implementação de um sistema de

gestão de segurança de informação (SGSI).

Após algum estudo sobre a abordagem ISO 27000 torna-se evidente que a elaboração

de um SGSI completo e funcional requer sempre o envolvimento de várias normas da

série, visto que por si só, a norma ISO 27001 é limitada. De seguida são apresentadas

as normas que se revelaram mais relevantes para este estágio, a 27000, a 27001,

27002, 27005 e 27799. A ISO 27000 e ISO 27001 foram imprescindíveis por serem as

normas que especificam as orientações e requisitos genéricos de implementação, a

norma ISO 27005 por ser a norma que fornece as diretrizes para o processo de gestão

de riscos de segurança da informação. A norma ISO 27002 surge como complemento

à norma ISO 27001 e dando suporte implementação de um SGSI, fornecendo um

conjunto de controlos mais específicos. Já a ISO 27799 aparece como um foco da ISO

27002 para a segurança da informação da saúde, fornecendo controlos específicos

para a área.

2.1.1. 27000 – Contextualização e Vocabulário usado

A ISO 2700 é uma norma de introdução à série de normas 27000, é nela que são

enumerados e detalhados termos e os conceitos de um SGSI, bem como a definição

do que deve ser um sistema de gestão de segurança de informação - SGSI.

Norma Áreas de Domínio

27000 Contextualização e Vocabulário usado

27001 Requisitos (Certificável)

27002 Código de conduta em gestão de segurança da

informação

27003 Guia de Implementação

27004 Medir e avaliar

27005 Gestão do Risco

27007 Orientações de suporte a auditorias ao SGSI (Ainda

em Preparação)

27008 Orientação para os auditores de controlos do SGSI

(Ainda em Preparação)

27035 Gestão de Incidentes


10

2.1.2. ISO 27001

A norma ISO 27001 foi definida com vista a fornecer um modelo base que permite

manter um sistema de gestão de segurança da informação (SGSI).

Nesta norma estão definidos os objetivos, os requisitos do SGSI, e a metodologia

cíclica a que um SGSI deverá subordinar-se. A metodologia cíclica, denominada

PDCA (Plan, Do, Act, Check) (ver Figura 2- Ciclo PDCA[1]), define uma abordagem

sistemática e dinâmica, desde a criação até à avaliação do desempenho para que

assim seja sempre possível a afinação e melhoria contínua de um SGSI:

Figura 2- Ciclo PDCA

De seguida são detalhadas as diversas etapas do ciclo PDCA quanto ao seu objetivo e

fases envolvidas. De notar que a numeração vem das ferramentas criadas no ponto3 -

Guia de implementação) começando em 3 (três), visto existirem 2 fases anteriores ao

ciclo, denominadas “Clarificar prioridades a desenvolver no ISMS” e “Definição

preliminar do âmbito / alcance do ISMS”. Esta numeração está alinhada com os

documentos produzidos para apoio à implementação, mais à frente referidos.

Plan - Nesta etapa pretende-se estabelecer a política, objetivos, processos e

procedimentos do sistema de gestão de segurança da informação (SGSI) relevantes

para a gestão de riscos e melhoria da segurança da informação.

Esta etapa é composta pelas seguintes fases:

3. Estabelecer o ISMS

3.1 Definição do âmbito / alcance do SGSI

3.2 Definição dos requisitos de segurança da informação -

processos do SGSI

3.3 Criação do Management Information Security Forum (MISF)

3.4 Definição da política de segurança

RRS 2011

in [1]


11

3.5 Definição de uma política para o SGSI

4. Classificação de ativos

4.1 Identificar Ativos - dentro do âmbito do SGSI

4.2 Criar procedimentos e métricas para avaliação do Risco

5. Risk Assessment (avaliação de riscos)

5.1 Avaliação de riscos de segurança da informação

5.2 Abordar controlos e objetivos dos controlos

5.3 Preparar SOA – Statement of Applicability

Do - Nesta etapa são postas em prática as políticas, processos, procedimentos e

métodos de controlo do SGSI considerados na fase PLAN.


6. Implementar e operar SGSI

6.1 Tratamento de Risco

6.2 Implementação de controlos

6.3 Segurança de informação organizacional

6.4 Verificar manual da política de segurança da informação

6.5 Desenvolver as normas e procedimentos de segurança da

informação

6.6 Abordar Formação e sensibilização

6.7 Gerir operações e recursos do SGSI

Check - Nesta etapa é realizada a avaliação de desempenho dos processos tendo em

conta a política de segurança definida. Os resultados apurados são apresentados à

direção para análise crítica.


7. Monitorizar e Rever o ISMS

7.1 Monitorizar e rever os procedimentos

7.2 Auditorias Internas

7.3 Auditoria Externa

7.4 Medir eficácia dos controlos

7.5 Rever Avaliação do Risco

Act - Nesta etapa pretende-se elaborar ações corretivas e preventivas ao SGSI com

base nos resultados da auditoria interna efetuada pelos auditores internos e da análise

critica efetuada por parte da direção da empresa, com vista a uma melhoria contínua

do SGSI


8. Manter e melhorar o SGSI


12

8.1 Melhorar SGSI

9. Revisão de conformidade

9.1 Completar uma revisão de conformidade com a Checklist

da ISO 27003

9.2 Corrigir as não conformidades

10. Auditoria Externa ao SGSI

2.1.2.1. Segurança da informação aos olhos da 27001

Para aferir o grau de segurança de um SGSI é vital a aplicação de modelos de

avaliação quantitativa e qualitativa de segurança da informação e da organização.

A informação é um ativo que, à semelhança dos restantes ativos representa um

determinado valor no âmbito global da organização e assim sendo necessita ser

adequadamente protegida. A segurança da informação visa proteger a informação de

diversos tipos de ameaças, tentando garantir a continuidade dos negócios, mitigar os

riscos e maximizar o retorno dos investimentos.

A informação existe em variadas formas, pode ser impressa ou escrita em papel,

armazenada digitalmente, transportada por correio terrestre ou através de meios

eletrónicos. Seja qual for a forma apresentada ou o meio através do qual a informação

é distribuída ou armazenada, é recomendado que seja sempre devidamente protegida.

A Segurança da informação é obtida através da implementação de controlos, podendo

estes ser políticas, práticas de uso, procedimentos, estruturas organizacionais,

funções de software, e outros.

A segurança da informação é aqui caracterizada pela preservação de:

a) Confidencialidade: garantia de que a informação se encontra acessível somente a

indivíduos a quem foi concedida a respetiva autorização;

b) Integridade: garantia de que a informação não é, de forma intencional ou não

intencional, alterada indevidamente;

c) Disponibilidade: garantia de que os utilizadores autorizados podem aceder à

informação pelos processos e nas condições definidas sempre que necessário.

2.1.2.2. Estabelecer requisitos de segurança

É essencial que uma organização identifique os requisitos de segurança, existindo três

fontes principais para a classificação das prioridades dos controlos a implementar a

quando o tratamento de risco.

A primeira fonte é derivada da avaliação do risco dos ativos existentes na

organização. Através da avaliação do risco são identificadas as ameaças, as

vulnerabilidades e a probabilidade de ocorrência, bem como o impacto

potencial estimado.


13

A segunda fonte é a legislação, os estatutos, a regulamentação e as cláusulas

contratuais que a organização, parceiros, contratados e prestadores de serviço

têm que seguir.

A terceira fonte é o conjunto particular de princípios, objetivos e requisitos para

o processamento da informação que a organização tem que desenvolver para

apoiar suas operações.

2.1.2.3. Módulos importantes da ISO 27001

Estes módulos da Norma ISO 27001 são ao mesmo tempo controlos da norma ISO

27002, mais à frente serão explicados (ISO 27002):

Gestão de Risco

Política de Segurança da Informação

Organizando a Segurança da Informação

Gestão de ativos

Segurança em Recursos Humanos

Segurança Física e do Ambiente

Gestão das Operações e Comunicações

Controlo de Acessos

Aquisição, Desenvolvimento e Manutenção de Sistemas de Informação

Gestão de Incidentes de Segurança da Informação

Gestão da Continuidade do Negócio

Conformidade

2.1.3. ISO 27002

Esta norma poderia ser chamada "Código de conduta para controlos de segurança da

informação", focando-se em controlos de segurança da informação, enquanto é um

complemento à norma ISO 27001 dando suporte à implementação de um SGSI e,

fornecendo um conjunto de controlos específicos, organizados nos seguintes doze

domínios de segurança:

Estes 12 domínios que iremos ver de seguida (começando em “4 – Risk assessment”

até “15 – Compliance”) são secções da norma ISO 27002, sendo a numeração e os

nomes apresentados entre parêntesis “()” os nomes e números originas.

De seguida vamos ver a descrição das secções da norma bem como algumas

diretrizes de segurança da informação que a norma fornece por cada domínio

abordado.

1. Gestão de Risco (4. Risk assessment and Treatment) a. Análise de riscos


14

b. Mitigação de riscos

c. Avaliação de riscos

A ISO 27002 apenas faz uma pequena abordagem à gestão de risco (cerca de

uma página), fazendo apenas referência para a ISO 27005 – gestão de risco.

2. Política de Segurança da informação (5. Security policy) a. Linhas de orientação e procedimentos

b. Políticas

A gestão deve definir uma política para clarificar os seus objetivos, apoio, e

segurança da informação, ou seja, um documento resumido, de declaração de

política de segurança da informação, que estabelece as diretrizes chave, bem

como as obrigações de segurança da informação para toda a organização. Isto

é normalmente suportado por um conjunto abrangente de políticas corporativas

mais detalhadas de segurança informações, normalmente na forma de um

manual de política de segurança da informação.

3. Organização da segurança da informação (6. Organization of information security)

a. Organização interna

A organização deve ter um framework de gestão de segurança da

informação. A administração de topo deve fornecer orientações e

mostrar o seu apoio, por exemplo, ao aprovar políticas de segurança da

informação. Os papéis e responsabilidades devem ser definidos para as

funções de segurança da informação.

b. Elementos externos

A segurança da informação não deve ser comprometida pela introdução

de produtos ou serviços de terceiros. Os riscos devem ser avaliados e

mitigados. Ao lidar com os clientes e em acordos de terceiros.

4. Gestão de ativos (7. Asset management) a. Identificação do Dono (owner)

Todos ativos de informação devem ser contabilizados e terem nomeado

um proprietário. Deve ser mantido um inventário de ativos de

informação (hardware IT, software, dados, documentação de sistemas,

meios de armazenamento, ativos de suporte, tais como, ar

condicionados, UPSs e serviços de IT). O inventário deve registar a

propriedade e localização dos ativos, e os proprietários devem

identificar os usos aceitáveis dos mesmos.

b. Classificação de Ativos


15

A informação deve ser classificada e rotulada de acordo com sua

necessidade de proteção de segurança.

Um exemplo de classificação de ativos pode ser encontrado no Anexo 3

- Classificação da Informação.

5. Segurança em Recursos Humanos (8. Human resources security) a. Antes da Contratação

As responsabilidades de segurança devem ser levadas em conta no

recrutamento de funcionários permanentes, contratados e trabalhadores

temporários (por exemplo, através de propostas de emprego adequadas

e triagem pré laboral) e incluídos nos contractos (por exemplo, termos e

condições e, funções e responsabilidades de segurança).

b. Durante a Contratação

Devem ser definidas responsabilidades de gestão sobre a segurança da

informação. Funcionários e (se relevante) utilizadores terceiros de TI

devem estar cientes, formados e treinados para os procedimentos de

segurança. Para lidar com falhas de segurança é necessário criar um

processo formal para levantar processos disciplinares aos funcionários

que entrem em incumprimento.

c. Depois do fim do Contrato

Devem ser pensados aspetos de segurança aquando a saída de uma

pessoa da organização (por exemplo, o retorno dos ativos corporativos

e remoção de direitos de acesso) ou mudança de responsabilidades

devem ser geridos.

6. Segurança Física e do Ambiente (9. Physical and environmental security) Equipamentos de TI valiosos devem ser fisicamente protegidos contra danos

maliciosos ou acidentais, perda, sobreaquecimento, falhas de energia elétrica,

etc…

a. Áreas seguras

Esta seção descreve a necessidade de camadas de controlos físicos

para proteger as instalações de TI que contenham informação, contra

acessos não autorizados.

b. Segurança dos equipamentos

Equipamento crítico, informático ou de outro tipo (suportes de

informação), cablagem e etc… devem ser protegidos contra danos

físicos, incêndio, inundação, roubo, etc… tanto on-site como off-site.

Devem ser asseguradas fontes redundantes de alimentação elétrica e


16

os equipamentos informáticos devem ser mantidos adequadamente e

quando necessário eliminados de forma segura.

7. Gestão das Operações e Comunicações (10. Communications and

operations management)

Esta longa e detalhada secção da norma descreve os controlos de segurança

de sistemas e gestão de redes de informação:

a. Procedimentos operacionais e responsabilidades

Devem ser definidos e documentados as responsabilidades e

procedimentos operacionais para os sistemas de informação. Mudanças

a instalações de TI e sistemas devem ser controladas e os direitos de

acesso devem ser diferentes para diferentes colaboradores.

b. Terceiros - gestão da prestação de serviços

Devem ser criadas cláusulas contratuais para a prestação de serviços

por parte dos nossos fornecedores, por exemplo, deve ser criado um

SLA (Service Level Agreement) com penalizações financeiras com o

nosso ISP.

c. Planeamento do sistema e aceitação

Abrange o planeamento da capacidade de processamento e os

processos de aceitação.

d. Proteção contra códigos maliciosos e móveis Descreve a necessidade de controlos anti-malware, incluindo a

conscientização do utilizador. Controlos de segurança para código

móvel associada a uma série de serviços de middleware também são

descritos.

e. Backup

Cobre as rotinas de backup e os planos de restauro dos dados.

f. Gestão da Segurança da Rede de informação

Esboços de gestão segura de rede, monitorização da segurança da

rede e outros controlos. Também abrange a segurança dos serviços de

rede comerciais, tais como redes privadas e firewall.

g. Manuseamento de medias (suportes de informação)

Devem ser definidos procedimentos operacionais para proteger

documentos e suportes informáticos que contenham dados,

informações de sistema, etc… A alienação de medias de backup,

documentos, gravações de voz e outros, dados de teste, etc… devem

ser registados e controlados. Os procedimentos devem ser definidos


17

para lidar com segurança, transporte e armazenamento de media de

backup e documentação do sistema.

h. Troca de informação

A troca de informação entre organizações deve ser controlada. O

intercâmbio de informação também deve cumprir a legislação aplicável.

Os procedimentos de segurança / normas devem estar aplicadas para

proteger a informação e media física em trânsito, incluindo mensagens

eletrónicas (email e IM) e sistemas de informação empresariais.

i. Serviços de comércio eletrónico

As implicações de segurança do ECommerce (sistemas de transações

on-line) devem ser avaliadas e, implementados controlos adequados. A

integridade e disponibilidade da informação publicadas on-line (por

exemplo, em sites) também devem ser protegidas.

j. Monitorização

Cobre o registo de eventos de segurança de auditoria e monitorização

de alertas para detetar o uso não autorizado de informação. Abrange

também a necessidade de garantir logs de acesso e sincronização dos

relógios do sistema.

8. Controlo de Acessos (11. Access control) a. Exigências do negócio para controlo de acessos

Exigências da organização para controlar o acesso a recursos de

informação devem ser claramente documentadas numa política de

controlo de acessos incluindo, por exemplo, perfis de acesso

relacionados ao trabalho desempenhado.

b. Gestão de acessos do utilizador

A atribuição de direitos de acesso aos utilizadores deve ser formalmente

controlado através do registo dos utilizadores e procedimentos

administrativos (de registro inicial do utilizador até a retirar de direitos de

acesso quando não for mais necessário), incluindo restrições especiais

sobre a alocação de privilégios e revisão regular de direitos de acesso.

c. Responsabilidades do utilizador

Os utilizadores devem estar cientes das suas responsabilidades para

manter o controlo de acessos eficaz, por exemplo, escolher senhas

fortes e mantê-las confidenciais. Os sistemas e informações devem ser

protegidos quando deixados sozinhos (por exemplo, criação de políticas

de mesa limpa e ecrã limpo).


18

d. Controlo de acesso à rede

O acesso a serviços de rede deve ser controlado, tanto dentro da

organização como entre organizações. A política deve ser definida e os

utilizadores remotos (e possivelmente equipamentos) devem estar

devidamente autenticados na rede. Os serviços de informação,

servidores, utilizadores e sistemas devem ser separados em diferentes

domínios de rede lógica.

e. Controlo de acessos aos sistemas operativos

Acesso ao sistema por parte de utilizadores “poderosos” ( root user,

administrator, etc…) deve ser controlado e devem ser definidos timeouts

por inatividade nas sessões dos utilizadores.

f. Controlo de acessos à informação e às aplicações

O acesso a sistemas aplicacionais deve ser controlado de acordo com

uma política definida de controlo de acesso. Aplicações particularmente

sensíveis podem exigir plataformas dedicadas (isolada), controlos

adicionais devem ser aplicados para plataformas compartilhadas.

g. Computação móvel e trabalho remoto

Devem existir políticas formais que efetuem a gestão da utilização

segura de PCs portáteis, PDAs, telefones móveis e, de teletrabalho

seguro ("trabalho em casa", "caixeiros viajantes" e outras formas de

trabalho móvel ou remoto).

9. Aquisição, Desenvolvimento e Manutenção de Sistemas de Informação

(12. Information systems acquisition, development and maintenance)

A segurança da informação deve ser levada em conta nos processos do ciclo

de vida de desenvolvimento de sistemas, para a especificação, a construção /

aquisição, análise, implementação e manutenção de sistemas TI.

a. Requisitos de segurança dos sistemas de informação

Devem ser analisados e totalmente identificados os requisitos de

controlo de segurança durante a fase de requisitos ou processo de

aquisição do desenvolvimento de sistemas, e incorporado nos casos de

negócio. O Software adquirido deve ser formalmente testado em termos

de segurança.

b. Processamento correto nos sistemas aplicacionais

Devem existir controlos para a entrada de dados, processamento e

validação de saída/apresentação, para mitigar os riscos de integridade

associados.


19

c. Controlos criptográficos

Deve ser definida uma política de criptografia, abrangendo papéis e

responsabilidades, assinaturas digitais, não-repúdio, gestão de chaves

e certificados digitais.

d. Segurança do sistema de arquivos

O acesso aos arquivos do sistema (ambos os executáveis e código

fonte) e dados de teste devem ser controlados.

e. Segurança nos processos de desenvolvimento e suporte

Os administradores do sistema de aplicações devem ser responsáveis

por controlar o acesso ao projeto (de desenvolvimento) e ambientes de

apoio. Processos formais de controlo de mudanças devem ser

aplicados, incluindo as revisões técnicas.

f. Gestão de vulnerabilidades técnicas

As vulnerabilidades técnicas em sistemas e aplicações devem ser

controladas pela monitorização de anúncios de vulnerabilidades de

segurança relevantes (usando os fabricantes ou outras fontes de

informação), devem prontamente ser aplicados patches de segurança

relevantes.

10. Gestão de Incidentes de Segurança da Informação (13. Information security

incident management)

a. Reportar eventos e falhas de segurança da informação

É necessário um procedimento de notificação / alarme para os

incidentes ocorridos. Deve existir um ponto central de contacto, e todos

os funcionários devem ser informados das suas responsabilidades de

relato nos incidentes.

b. Gestão de incidentes de segurança da informação

É necessário definir responsabilidades e procedimentos consistentes e

eficazes para gerir incidentes, para implementar uma melhoria contínua,

e para recolher provas forenses quando necessárias.


20

11. Gestão da Continuidade do Negócio (14. Business continuity management)

Esta seção descreve a relação entre a gestão de disarter recovery em IT. A

continuidade de negócios e o planeamento de contingências, que vão desde a

análise e documentação através de exercício regulares / teste dos planos

criados. Estes serão os controlos que são projetados para minimizar o impacto

dos incidentes de segurança que ocorrem apesar dos controlos preventivos

existentes e vistos em outras partes da norma.

12. Conformidade (15. Compliance)

a. Cumprimento dos requisitos legais

A organização deve cumprir com toda a legislação aplicável, tais como

direitos de autor, proteção de dados, proteção de dados financeiros e

outros registos vitais, etc…

b. Conformidade com as políticas e normas de segurança e conformidade

técnica

Os administradores e proprietários do sistema devem garantir o

cumprimento com as políticas e normas de segurança, por exemplo,

através de revisões regulares de segurança das plataformas e testes de

penetração ao sistemas realizados por especialistas competentes.

c. Considerações de auditoria a Sistemas de Informação

As auditorias devem ser cuidadosamente planeadas para minimizar a

interrupção de serviços e sistemas operativos. As ferramentas de

auditoria também devem ser protegidas contra o uso não autorizado.

Na Figura 3- Controlos ISO 27002[22], podemos observar um mapa que sumariza

graficamente as 12 secções da norma que vimos anteriormente.


21

Figura 3- Controlos ISO 27002

2.1.4. ISO 27005

A norma ISO 27005 tem como objetivo principal fornecer diretrizes para o processo de

gestão de riscos de segurança da informação de uma organização, atendendo

particularmente aos requisitos de um SGSI. No entanto, é de notar que esta norma

não inclui uma metodologia específica para a gestão de riscos de segurança da

informação, cabendo à organização definir uma abordagem ao processo de gestão de

riscos.

Um risco é a combinação das consequências advindas da ocorrência de um evento

indesejado e da probabilidade da ocorrência do mesmo[21].

Nesta norma, é mostrada uma visão geral do processo de gestão de riscos de

segurança da informação, bem como as diversas atividades do mesmo, que estão

divididas em várias secções.

A análise/avaliação de riscos é o capítulo da norma ISO 27005 onde são definidos os

critérios para a avaliação de risco que são desenvolvidos para avaliar os riscos de

segurança da informação na organização, considerando os seguintes itens:

O valor estratégico do processo que trata as informações de negócio;

A criticidade dos ativos de informação envolvidos;

in [22]


22

Requisitos legais e regulamentares, bem como as obrigações contratuais;

Importância do ponto de vista operacional e dos negócios, da disponibilidade,

da confidencialidade e da integridade;

Expectativas e perceções das partes interessadas e consequências negativas

para o valor de mercado (imagem e reputação).

Dentro deste capítulo podemos encontrar a abordagem a diversos aspetos, que vão

desde a identificação de riscos, passando pela identificação de vulnerabilidades,

relacionar vulnerabilidades e riscos, probabilidade de acontecimento do risco,

avaliação de risco e acabando na priorização do tratamento do risco.

Após passarmos pelo processo de identificação de riscos e vulnerabilidades, assim

como a avaliação do mesmo, o próximo passo passa por definir como lidar com

determinado risco.

As formas disponíveis que existem para lidar com o risco são: tratar o risco, evitar o

risco, reduzir seu impacto, ou ainda, transferir o risco para outro local.

Esta identificação irá servir para o plano de tratamento de risco:

Aceitar um Risco – por outras palavras a administração aceita o risco,

comparando o impacto que este pode trazer com o investimento necessário

para providenciar controlos necessários à sua mitigação.

Reduzir – aplicar um controlo ou um conjunto de controlos que visam mitigar o

risco para um nível aceitável.

Evitar o risco – não executar os processos de negócio que estão associados a

determinado risco.

Transferir – transferir o risco para outra organização, por exemplo, criar um

contrato de seguro sobre o risco, ou criar contractos de entendimento com

outros parceiros de negócio.

Mais detalhes e explicação de uso desta norma poderão ser encontrados nos

capítulos 4 e 5 do Anexo 10 - Explicação do Plano de implementação ISO 27001.

2.1.5. ISO 27799

A ISO 27799 surge como implementação específica da ISO 27000 em sistemas da

informação da Saúde. Sendo a adaptação do guia de implementação prática da ISO

27002, para segurança de dados em saúde. O Anexo A desta norma descreve as

principais ameaças aos dados relacionados com a saúde. O Anexo B descreve

resumidamente as tarefas e os documentos relativos ao SGSI. Por fim o Anexo C da

norma apresenta as vantagens das ferramentas de suporte à implementação da

norma.


23

Esta norma internacional aplica-se à informação na saúde em todos os aspetos,

qualquer que seja a informação (números e letras, gravações de som, esquemas,

vídeos e imagens médicas), em qualquer meio que seja armazenada (impressa,

escrita em papel ou armazenada eletronicamente) e qualquer que seja o meio em que

esta é transmitida (em mão, por fax, por rede de computadores ou correio), a

informação tem sempre de ser devidamente protegida.

Esta norma em conjunto com a ISO/IEC 27002 define o que é requerido em termos de

segurança da informação na saúde. Estas não definem como os requisitos de

segurança devem ser cumpridos.

Existem algumas áreas da segurança da informação que a norma ISO 27799 não

engloba, entre elas:

Metodologias e testes que efetivem o controlo da anonimidade dos dados

pessoais de saúde.

Métodos de teste à qualidade dos serviços e infraestrutura de rede usada na

informática de saúde.

Qualidade dos dados (diferente de integridade dos dados).

2.1.5.1. Segurança da informação na Saúde

Para além da segurança básica da informação, integridade, disponibilidade e

confidencialidade (a definição de integridade, disponibilidade e confidencialidade pode

ser encontrada no ponto 2.1.2 na secção Segurança da informação aos olhos da

27001), na saúde, a privacidade dos indivíduos tem sempre de ser mantida. Para

manter a confidencialidade, terão de ser tomadas medidas para assegurar a

integridade dos dados de controlo de acesso, ou outro tipo de dados que a sua

adulteração possa por em causa a confidencialidade dos sem que esta seja notada.

Além disto, a segurança de um paciente depende da integridade dos dados referentes

ao seu estado de saúde, a falha disto pode trazer casos de doença, lesão ou até morte

do paciente.

Tem de ser mantido um nível máximo constante de disponibilidade do serviço, onde a

falha do serviço pode perturbar tratamentos ou diagnósticos de doenças.

Deve ser assegurado que o acesso á informação de saúde é auditado e contabilizado,

através de logs e historial, quem acede a quê e quando acedeu.

Estes controlos foram criados para prevenir erros na prática médica, que possam ser

causados pela falha da integridade dos dados de saúde. Em simultâneo, asseguram

que a continuidade dos serviços médicos é mantida.

Existem ainda considerações adicionais que vão de encontro aos objetivos da

segurança da informação na saúde:


24

a) Honrar e seguir as legislações de proteção de dados;

b) Seguir as melhores práticas da segurança e privacidade dos dados no que se

refere aos dados de saúde;

c) Responsabilizar individualmente e corporativamente as organizações e

profissionais de saúde pelas ações que efetuam sobre os dados;

d) Cumprir os requisitos comuns de segurança entre organizações de saúde;

e) Reduzir custos operativos, facilitando o aumento do uso das tecnologias de

informação, sem que isto cause entraves ao bom funcionamento das habituais

atividades de saúde;

f) Manter a confiança do público nas organizações de saúde e nos sistemas de

informação que estas usam;

g) Manter a ética profissional relacionada com os profissionais e organizações de

saúde;

h) Manusear dados de saúde em formato eletrónico no ambiente apropriado e

que ofereça segurança contra ameaças;

i) Pensar objetivamente na interoperabilidade entre sistemas, os dados de saúde

são trocados entre varias organizações de saúde, concelhos, distritos,

ministérios e até países. A informação deve conseguir ser facilmente portada

entre os diversos sistemas para assegurar uma contínua confidencialidade,

integridade e disponibilidade da informação.

Cap.3 – Guia de implementação Segurança da Informação na Saúde

25

3. Guia de implementação

Uma das tarefas efetuadas ao longo deste estágio consistiu na elaboração de um guia

de implementação da norma ISO 27001 adaptado à realidade de uma PME atuante no

segmento de desenvolvimento de sistemas de informação centrados na Saúde1. O

objetivo que assistiu a este esforço foi o de esta contribuição poder ser futuramente

explorada e eventualmente adaptada como ponto de partida para uma potencial

adoção da norma na empresa em causa.

O presente capítulo constitui o guia de implementação mencionado. O guia

desenvolvido é composto pelas seguintes ferramentas:

Ferramenta de gestão da implementação – Ferramenta de gestão de tempo de

implementação, de gestão de recursos envolvidos e de custo de

implementação;

Diagrama de Implementação ISO27001 – Ferramenta na forma de diagrama

sequencial que resume todas as fases de implementação propostas e os

documentos de produção necessária em cada fase;

Explicação do plano de implementação – Esta ferramenta foi construída o mais

detalhadamente possível e tem como objetivo explicar as necessidades de

cada fase de implementação (recursos envolvidos, documentos necessários,

fontes bibliográficas para consulta mais detalhada).

As seguintes secções detalham cada uma das componentes mencionadas. O capítulo

é encerrado com a apresentação de recomendações a ter em consideração durante a

adaptação das ferramentas desenvolvidas.

3.1. Ferramenta de gestão da implementação

Uma das ferramentas criadas foi um documento em OpenProject com o objetivo

principal de dar uma noção clara do esforço temporal, dos recursos envolvidos e da

totalidade das fases de implementação da norma ISO 27001 numa empresa[24].

1 A empresa no âmbito da qual foi desenvolvido o estágio atua num leque diversificado de áreas. No

entanto o estágio considerou a ISA como PME focada exclusivamente na saúde, considerando-a reduzida à sua unidade de negócio ISA Intellicare (responsável pelo desenvolvimento da família de produtos OneCare).


26

De seguida (Figura 4- Documento de Gestão da implementação), podemos observar o aspeto final do documento de gestão da implementação.

Esta ferramenta permite-nos efetuar a gestão de recursos humanos pertencentes à implementação da norma na empresa e, por exemplo imputar

custos de implementação quer monetários quer temporais.

Figura 4- Documento de Gestão da implementação (vista parcial)


27

A Figura 5 - Relatório exemplo, mostra um relatório tipo, produzido a partir da mesma,

do custo, da duração e da percentagem de execução da implementação da norma ISO

27001 numa PME.

Figura 5 - Relatório exemplo

Como pudemos ver na Figura 4, o documento tem estimado o tempo esperado de

execução de cada fase / tarefa (as tarefas presentes neste documento são listadas no

Anexo 13, não estando presente o gráfico de Gantt devido às dificuldades de

enquadramento do mesmo na impressão de uma folha A4 ou A3). O dimensionamento

considerado teve por base diversos documentos do “ISO27k implementers’ forum”

(grupo de discussão online conceituado na área) e a experiencia pessoal do autor

adquirida durante a execução de algumas das tarefas mencionadas.

Para cada tarefa foi estimada uma data de início e uma data de fim, bem como as

dependências[24] entre as demais tarefas. Foram igualmente atribuídos os recursos

humanos envolvidos em cada tarefa.


28

Dos recursos humanos atribuídos[23][24] no plano de implementação, foram

considerados para implementação dois em full-time (Responsáveis pela

implementação e Responsáveis pela segurança da informação), 7 recursos em part-

time (efetuando para alem das tarefas relacionadas com o ISMS, as tarefas

quotidianas na organização) e um grupo de segurança (MISF). De seguida, a

descrição dos recursos envolvidos na implementação[23]:

MISF – Management Information Security Forum, é um grupo multidisciplinar

de discussão, semelhante a um fórum de segurança.

Responsável Sistemas de Informação – Membro chefe do departamento de

sistemas de informação, em pequenas empresas é usual esta pessoa

chefiar[14] a segurança da informação na empresa.

Responsáveis pela implementação da ISO 27001 – pessoa responsável por

implementar a norma na empresa, cabe a esta pessoa inicialmente “convencer”

a administração da empresa que a implementação da empresa é o mais

correto.

Responsáveis pela segurança da informação – pessoa responsável máximo

pela segurança da informação na empresa e por tudo o que diz respeito a

segurança da informação. Numa empresa pequena é normalmente um

administrador[14] da empresa ou o responsável dos sistemas de informação[14]

que ocupam este cargo.

Responsável dos RH – Membro do departamento de recursos humanos (RH)

da empresa, cabe a esta pessoa fazer a ligação entre a segurança da

informação e as “pessoas” cabendo-lhe a gestão da formação para a

segurança, cuidados de segurança a ter com os funcionários antes, durante e

depois da contratação.

Administração da empresa – Administração de topo da empresa, cabe a estes

tomar as decisões críticas em relação à segurança da informação.

Chefe de Departamento – pessoa responsável pela segurança da informação

em um departamento, cabe-lhe a ele incutir a responsabilidade pela segurança

da informação aos seus colegas de departamento.

Donos dos Ativos – pessoa diretamente responsável por ativo e por todas as

falhas de segurança que ocorrerem relacionadas com aquele ativo.

Proprietários do processo das áreas estratégicas – responsável por

determinado processo considerado crítico para a empresa, por exemplo, um

gestor do projeto mais importante da empresa.


29

Auditores Internos – pessoa habilitada e formada a efetuar auditorias à luz da

norma ISO 27001.

No final da elaboração do documento, com a alocação[23][24] de recursos efetuada,

chegou-se a um tempo estimado de implementação de cerca de 6 meses (5 meses e

20 dias). Num estudo efetuado pela Certification Europe chegou-se à conclusão que o

tempo normal de implementação de uma empresa é de entre 6 e 12 meses[14], ver

Figura 6 - tempos de implementação , pelo que se pode afirmar que o tempo calculado

para a implementação estará dentro do normal para a tarefa em causa.

Figura 6 - tempos de implementação

Pensando em custos aproximados de implementação, e tendo chegado a 2789 horas

estimativas como custo de horas de trabalho necessárias para a implementação,

chegamos a um custo de implementação de:

Custo médio Trabalhador hora [15] = 867,5 (salario medio mensal de um

trabalhador por contra de outrem) / 22 dias / 8 horas ≈ 5€ por hora.

o 2789 Horas x 5€ = 13.945€

Estes valores sendo apenas uma aproximação (por defeito) ao custo de

implementação, demonstra que a implementação (recorrendo a recursos internos)

numa empresa nunca terá um custo inferior a dez mil euros (10.000€). Mudando o

paradigma de implementação recorrendo a recursos externos, o custo de

implementação[14] nunca será inferior a vinte e cinco mil euros (25.000€), podendo em

alguns casos chegar a valores superiores a oitenta mil euros (80.000€). Podem existir

organizações que pela sua natureza de atuação específica, o seu custo de

implementação possa disparar para as várias centenas de euros, devido à sua

complexidade de implementação ou a controlos dispendiosos (por exemplo, grande

investimento em hardware, software ou ferramentas semelhantes).

in [14]


30

Em relação ao tempo de implementação interna, é possível reduzir o tempo de

implementação alocando mais recursos em fases mais demoradas e complexas, ex.

levantamento de ativos, tratamento de risco, etc…

Abordando a relação custo / benefício de implementação, podemos facilmente concluir

que o custo implementação é relativamente baixo (cerca de 14.000€) tendo em conta

as potenciais falhas de segurança que irão ser mitigadas após a implementação da

norma numa organização, considerando que, atualmente para uma empresa é

bastante fácil obter um prejuízo de 14.000€ em por exemplo, fugas de informação ou

perca da mesma.

De notar que documento inclui para cada tarefa uma numeração adjacente que

permite relacionar as tarefas deste, com as mesmas tarefas dos documentos

“Diagrama de Implementação ISO27001” e “Explicação do plano de implementação”

abordados nas próximas secções.

3.2. Diagrama de Implementação ISO27001

O diagrama de implementação (Figura 8- Diagrama de implementação) foi criado com

o objetivo principal de mostrar visualmente as fases envolvidas na implementação da

norma ISO 27001, bem como as suas interligações, outcomes e, por fim, uma

perspetiva detalhada sobre o ciclo PDCA uma filosofia cíclica, como vimos

anteriormente (2.1.2 ISO 27001).

Para facilitar a leitura deste diagrama foi adotado um esquema cromático que permite

facilmente localizar cada uma das fases considerada num dos quatro estágios do ciclo

PDCA: o tom branco (creme) identifica o estágio Plan, o castanho o estágio Do, o azul

o estágio Check, e o vermelho o estágio Act. O cinzento identifica as fases do estágio

Viabilidade, um estágio considerado na fase de pré implementação. A cor verde

identifica os documentos que obrigatoriamente devem resultar de cada fase.

Um SGSI implica uma abordagem sistemática e dinâmica, desde a criação até à

avaliação do desempenho para que assim seja sempre possível a afinação e melhoria

do sistema[1]. Na Figura 8- Diagrama de implementação, podemos encontrar

detalhadamente e englobado num esquema de cores por fase relacionadas com as

cores encontradas no diagrama da Figura 7 que pretende ser um diagrama de alto

nível do referido diagrama de implementação.


31

Em seguida podemos encontrar na Tabela 3 uma legenda dos objetos usados no

diagrama de implementação. Este diagrama segue o modelo UML para facilitar a sua

leitura e compreensão.

Tabela 3- legenda diagrama de implementação

Fluxo de controlo

Fluxo de Informação

Transferência de dados / Informação / documentação

Atividade

Por cada fase é necessária a produção de determinados documentos, estes

encontram-se representados pelos retângulos verdes (Transferência de dados /

Informação / documentação). Para cumprir o ciclo de fases PDCA, na leitura do

diagrama é de notar que após a finalização da última fase (fase 10) o bom

funcionamento do ISMS exige que o estado das ações volte ao ponto 3

(estabelecimento do ISMS) e que continue sequencialmente novamente até ao ponto

10, repetindo-se assim um novo ciclo.

Figura 7 - Ciclo PDCA com esquema de cores


32

Mapa

Plan

Do

Check

Act

1 Clarificar prioridades a desenvolver no ISMS

2 Definição preliminar do

âmbito / alcance do ISMS

Viabilidade

3Estabelecer o ISMS

Implementação ISO/IEC 27001RRS 2012

4Classificação de activos

5Risk Assessment

6Implementar e Operar

ISMS

7Monitorizar e Rever o

ISMS

8Manter e melhorar o SGSI

10Auditoria Externa

9Revisão de conformidade

1.1 Os objectivos de implementação

2.1Responsabilidades e cargos

Nomear responsável pela

segurança da informação

2.2 ISMS – Framework de

gestão documental

Objectivos específicos /

prioritários da empresaÂmbito preliminar do ISMS

3.1Definição do âmbito /

alcance do ISMS

Papeis / cargos e

responsabilidades

Várias Saídas

Âmbito, barreiras e alcance

do ISMS

Requisitos de segurança da informação – a que activos

se aplicam

3.2Definir os requisitos de

segurança da informação - processos do ISMS

3.3Management Information

Security Forum (MISF)

Análise de LacunasRelatório de Falhas /

Lacunas

Processos, funções, localizações, sistemas de

informação e redes de

comunicação

Responsabilidades,Membros, Cargos e

frequência das acções

3.4Definição da política de

segurança

Política de Segurança

3.5Definir uma política para o

ISMS

Política do ISMS

4.1Identificar Activos - dentro

do âmbito do ISMS

4.2Procedimentos e métricas

para avaliação do Risco

Listagem de Ativos

Listagem de vulnerabilidades

e Métricas

Fonte de Vulnerabilidadese

Tipos de risco e níveis aceitáveis

Priorização do tratamento de risco

RTP – Risk treatment Plan SOA – Statement of

Applicability

5.1Avaliação de riscos de


5.2Controlos e objectivos dos

controlos

5.3Preparar SOA – Statement

of Applicability

6.1Implementação de

controlos

6.2Segurança de informação

organizacional

6.3Manual da política de


6.4Desenvolver as normas e

procedimentos de segurança da informação

6.5Formação e sensibilização

6.6Gerir operações e recursos

do ISMS

Métricas usadas Estrutura organizacional

Papeis, responsabilidades e “report lines”

Resumo de todas as políticas, métodos e procedimentos de

segurança

Procedimentos e rotinas

a seguir

Programa de formação para a

segurança

Desenho do ICT

7.1Monitorizar e rever os

procedimentos

7.2Auditoria Interna

7.3Auditoria Externa

7.4Medir eficácia dos

controlos

7.5Rever Avaliação do Risco

Relatório de erros ou falhas encontradas

Relatórios de Auditoria / Abertura

de NCs

Agendamento de Reuniões de

Auditoria

Eficácia e eficiência dos controlos

Eficácia e eficiência dos controlos8.1

Melhorar ISMS

9.1revisão de conformidade

ISO 27003

9.2Corrigir as não conformidades

- Registo de NC- Melhorias

Implementadas

Desvios da Norma Acções CorrectivasDocumento Obrigatório

Voltar à fase PLANPonto 3

Início

Figura 8- Diagrama de implementação


33

Existe ainda no canto inferior direito do diagrama de implementação (Figura 8) um

mapa cromático para auxílio da separação visual entre as diversas fases do ciclo.

À semelhança do documento anterior, as fases encontram-se numeradas para que

seja possível relacionar as tarefas deste, com as mesmas tarefas dos documentos

“Ferramenta de gestão da implementação” e “Explicação do plano de implementação”.

3.3. Explicação do plano de implementação

A terceira ferramenta desenvolvida, de auxílio à implementação de um Sistema de

Gestão da Segurança da informação (SGSI), consiste num documento (Figura 9 - Ex.

Explicação do plano de implementação / Anexo 10 - Explicação do Plano de

implementação ISO 27001)[33][34][35], no qual se detalham as necessidades de cada

fase (fases estas coincidentes com o documento em OpenProject referido acima). Este

documento tem como objetivo prestar apoio à implementação da norma ISO 27001

numa PME2, constando deste um Road Map com todas as fases do processo de

implementação e uma abordagem exemplificativa de cada fase.

Figura 9 - Ex. Explicação do plano de implementação

Por cada fase, o documento faz referência às pessoas ou cargos da organização que

devem fazer parte direta ou indireta do processo, bem como os documentos que

deverão ser produzidos no final da mesma.

2 Apesar de este documento introduzir uma compilação das normas relevantes (27001, 27002, 27003 e 27799) o mesmo não substitui a consulta das próprias normas para esclarecimentos mais detalhados.


34

O campo “entrada” de cada fase faz referência a documentos ou ideias que

terão de estar pré-definidas ou produzidas antes do início da fase em questão.

O Campo “saída” faz referência aos documentos e ferramentas que terão de

ser produzidos obrigatoriamente no final de cada fase.

No campo “Fontes Adicionais” podem-se encontrar referências ou fontes mais

detalhadas de informação acerca de cada fase de implementação.

O documento encontra-se dividido em 5 partes, a fase anterior à implementação “Fase

Preparatória”, e as 4 fases de implementação, Plan, Do, Check e Act.

3.4. Recomendações de adaptação

As ferramentas que vimos até a este momento (Diagrama de Implementação

ISO27001, Ferramenta de gestão da implementação e Explicação do plano de

implementação) são compatíveis com todos os tipos de PMEs, no entanto ainda assim

podem ser personalizadas e adaptadas facilmente para cumprir exatamente os

objetivos de uma organização.

3.4.1. Ferramenta de gestão da implementação

Esta ferramenta pode facilmente ser adaptada, quer em número de recursos

envolvidos na implementação, quer na criação de tarefas de implementação para além

das que já existem.

Para um maior detalhe quanto ao custo de implementação e após os recursos terem

sido escolhidos, deverá ser adicionado um custo por hora “real” de cada recurso

envolvido.

Para uma empresa de dimensão superior (a uma PME) poderão ser aumentados os

tempos de implementação de casa fase, bem como adicionados outros de recursos

nas diversas fases.

Deverá ser levado em atenção no momento de alteração da ferramenta que existem

dependências entre algumas das fases existentes. Por exemplo a fase 6.1 -

Tratamento de Risco nunca poderá ser efetuada antes da fase 5.1 - Avaliação de

riscos de segurança da informação.

3.4.2. Explicação do plano de implementação

Á semelhança da ferramenta de gestão de implementação e como estão diretamente

ligadas, a “explicação do plano de implementação” pode ser personalizado em termos

de recursos envolvidos e da adição de novas fases de implementação. De notar que

os documentos necessários abordados nas ferramentas não são opcionais, sendo

mesmo requisitos[16] da norma.


35

Na tabela de recursos envolvidos por fase, poderão ser acrescentados os nomes dos

elementos que vão desempenhar as tarefas das mesmas.

3.4.3. Diagrama de Implementação ISO27001

Mais uma vez tendo em conta a interligação destes três documentos, podemos dizer

que à semelhança dos dois anteriores, este pode ser adaptado tendo em conta a

adição de novas fases e a adição de novos documentos necessários em cada fase.

Cap. 4.Caso prático de implementação Segurança da Informação na Saúde

36

4. Caso prático de implementação ISO 27001

Depois de efetuado o guia de implementação, algo estava em falta. Quer por motivos

de teste do guia, quer para criar uma envolvência mais prática da aplicação da norma

ISO 27001.

Foram criadas ferramentas e abordadas as respetivas fases de implementação, entre

estas, foi abordado o levantamento de ativos, classificação da informação,

levantamento / priorização do tratamento de risco, a análise de vulnerabilidades

(dimensão e listagem de vulnerabilidades) e ainda a análise de lacunas de

implementação.

Os documentos e exemplos apresentados de seguida foram construídos para

aplicação na empresa ISA, no entanto as fases apresentadas de seguida

(Levantamento de Ativos, Classificação / Manuseamento da Informação, Listagem de

riscos, Vulnerabilidades, Dimensão da vulnerabilidade, Listagem de vulnerabilidades,

Priorização do tratamento de risco, Priorização do tratamento de risco (método

alternativo), Plano de tratamento de risco, Análise de lacunas, Relatório de análise de

falhas), não foram efetuadas de forma exaustiva, por exemplo, na fase de

levantamento de ativos apenas foram catalogados e avaliados uma percentagem do

total de ativos. Com esta aproximação não exaustiva, tentou-se efetuar um número

maior de fases em forma de exemplificação, ao invés de, por exemplo, completar

apenas uma fase com um detalhe e nível de implementação de 100%.

4.1. Levantamento de Ativos

Foi efetuado o levantamento (não exaustivo) de ativos na ISA, com destaque para os

ativos informáticos, totalizando setenta e cinco (75) ativos. Futuramente carece o

levantamento dos restantes ativos de informação. Foi ainda produzido um documento

que lista os ativos e o seu valor em termos de informação que estes contêm ou

transportam.

O documento de levantamento de ativos (Figura 10 - Listagem e Classificação de

Ativos), referido aqui como “listagem e classificação de ativos” tem como objetivo não

só criar uma base de dados de ativos mas também efetuar a sua avaliação.

A avaliação prática dos ativos é feita com a avaliação em separado dos 3 vértices da

segurança da informação: confidencialidade, disponibilidade e integridade, sendo que

esta avaliação foi levada a cabo pelo autor em conjunto com o responsável (IT

Manager) de implementação da ISO 27001 na ISA. Quanto mais alto é este valor (de 1

a 3), maior será o prejuízo para a organização no caso de algo nefasto acontecer com


37

o ativo. A avaliação final do ativo (valor do ativo) será dada pela soma simples da

avaliação dos 3 vértices se segurança.

A seguinte figura (Figura 10 - Listagem e Classificação de Ativos) surge organizada

por ID de ativo, em que cada ativo pode ter um tipo e uma categoria (de tipos). Surge

ainda a informação acerca da camada do modelo OSI em que este se enquadra para

facilitar a sua distinção futura. Possui ainda a informação acerca do seu responsável

bem como a sua classificação para a organização. Finalmente surge a informação

acerca do valor CID (Confidencialidade, Integridade e Disponibilidade) e de acordo

com este, o valor do ativo (C + I + D).

Para consulta do documento completo, ver Anexo 11.


38

Figura 10 - Listagem e Classificação de Ativos


39

4.2. Classificação / Manuseamento da Informação

Um dos passos mais importantes da segurança da informação, é a classificação[23][38]

da mesma, ou seja, dizer implicitamente a que pode ser divulgada, a que é privada e

por exemplo que é estritamente secreta. Esta classificação deverá ser efetuada

durante o planeamento do ISMS, ou mesmo antes desta fase, na fase de viabilidade /

âmbito preliminar do ISMS.

Existem várias formas e maneiras de classificar a informação (Figura 11 - classificação

da informação, detalhe no Anexo 3 - Classificação da Informação), tendo sempre em

conta as suas várias fases e formatos. Como se pode ver na Figura 11 é sugerido a

divisão da informação em 3 tipos:

Pública

Interna

Confidencial

Não é obrigatório que sejam 3 os tipos de informação, podendo por exemplo uma

empresa pretender classificar alguma informação como “ultra secreta” que neste

exemplo está agrupada na informação “confidencial”.

Para cada tipo de informação vamos ter que estabelecer vários requisitos de controlo

quanto a vários parâmetros e estados da informação, no caso considerámos 4

controlos:

Controlo físico – quem é responsável e o que é necessário fazer para controlar

as cópias físicas da informação? Ex. “Esta pessoa tem de assegurar que esta

informação é encriptada”.

Reprodução – Existe alguma limitação quanto às cópias da informação? Quem,

como e quando pode? Ex. “Cópias limitadas poderão ser efetuadas por

colaboradores ou subcontratados que tenham assinado um contrato de sigilo

de informação.”

Distribuição – Existem restrições quanto à distribuição deste tipo de

informação? Quem pode, para onde, como? Ex. “Interna: deve circular num

envelope. Externa: Usar um envelope selado. Eletrónica: usar email interno,

requer encriptação para circular externamente.”

Destruição – Como e por quem deve ser eliminada a informação deste tipo?

Ex. “Papel: usar um destruidor certificado que use corte em cruz. Dados

eletrónicos: Dispositivos magnéticos, CD’s. DVD’s e discos rígidos são

enviados para o IT para destruição apropriada.”


40

Figura 11 - classificação da informação

4.3. Vulnerabilidades

4.3.1. Dimensão da vulnerabilidade

Uma vulnerabilidade pode ser entendida como a condição de risco em que um ativo se

encontra. Um conjunto de situações mais, ou menos problemáticas, que colocam o

ativo numa condição de indefensibilidade, atacabilidade ou destrutibilidade.

Esta fase surgiu com a necessidade de existir uma catalogação de vulnerabilidades

que os ativos de informação possuem, e de entre as existentes, saber com exatidão

quais as mais potencialmente nocivas para o sistema.

Este método aqui explicado será usado de seguida no capítulo 4.3.2.Listagem de

vulnerabilidades, para efetuar o cálculo das vulnerabilidades que necessitam de uma

maior atenção / controlo.

Uma vulnerabilidade pode ser avaliada de uma forma mais simples, no entanto, a

opção mais eficaz acaba por ser a avaliação de vulnerabilidades com base numa base

de dados modelo, neste caso, a mais fiável será a NIST (National Institute of

Standards and Technology) [17], fazendo uso dos seus critérios de avaliação - CVSS[17]

(Common Vulnerabilities Score System). Assim, temos acesso às listagens de

vulnerabilidades fornecidas pelas NIST de forma direta e automática, tendo como fonte

uma das melhores bases de dados, o que tornará a nossa avaliação mais eficaz e

abrangente.


41

As métricas de análise estão divididas em domínios, como pode ser visto na Figura 12

- Métricas CVSS:

De seguida vamos abordadas os três domínios de métricas do CVSS, divididos em

Base, Temporal e de Ambiente.

4.3.1.1. Domínio Base:

Aqui será analisado como uma vulnerabilidade consegue afetar o ativo, que condições

precisa e quais os atributos CIA afetados. De notar que os valores entre parêntesis

(Ex. “(L)”) são os mesmos usados nas formulas de calculo do método.

Os elementos base CVSS a analisar são:

1 Rede (AV - Access Vector) - Esta medida esclarece como uma vulnerabilidade

é explorada. Quanto mais distante estiver o intruso maior será a pontuação

atribuída:

a. Local (L)

b. Rede adjacente (A)

c. Rede remota (R)

2 Complexidade de acesso (Access Complexity) – Esta medida define e

caracteriza os requisitos de complexidade e conhecimento que uma

vulnerabilidade necessita para ser explorada. Quanto mais conhecimento for

necessário e mais complexa for uma vulnerabilidade, menor será a pontuação

deste campo.

a. Baixa (A)

b. Media (M)

c. Alta (B)

3 Autenticação (Au) – Esta medida esclarece o número de autenticações que um

atacante necessita ultrapassar para explorar uma vulnerabilidade. Quanto

maior numero de autenticações, menor a pontuação.

a. Múltipla (M)

b. Uma (U)

c. Nenhum (N)

in [6] Figura 12 - Métricas CVSS in [6]


42

4 Impacto na confidencialidade (CI) – Esta medida esclarece sobre o impacto

que uma vulnerabilidade pode ter na confidencialidade de um ativo. Quanto

mais exposto ficar o ativo, maior será o valor do impacto.

a. Completa (C)

b. Parcial (P)

c. Nenhum (N)

5 Impacto na integridade (II) – Esta característica esclarece sobre a capacidade

de uma vulnerabilidade conseguir alterar um ativo sem consentimento. Quanto

mais alterado for o ativo, maior vai ser a pontuação atribuída.

a. Completa (C)

b. Parcial (P)

c. Nenhum (N)

6 Impacto na disponibilidade (ID) – Esta característica esclarece o quanto uma

vulnerabilidade consegue deixar indisponível um ativo. Quanto maior for a

indisponibilidade, maior será o valor.

a. Completa (C

b. Parcial (P)

c. Nenhum (N)

4.3.1.2. Métricas Temporais:

A ameaça representada por uma vulnerabilidade pode variar temporalmente. De notar

que os valores entre parêntesis (Ex. “(PP)”) são os mesmos usados nas formulas do

método. O CVSS aborda três fatores:

1 Confirmação dos detalhes técnicos de uma vulnerabilidade,

2 O estado de correção (patch de correção) da vulnerabilidade,

3 Disponibilidade de conhecimento acerca da exploração de vulnerabilidades ou

técnicas de ataque a esse ativo.

As métricas temporais são opcionais, estas incluem um valor que pode ou não ter

efeito na pontuação. Se a métrica não se aplica, esta é desprezada.

1 Possibilidade de Exploração de uma ameaça (Exploitability) - Esta métrica

mede o estado atual do conhecimento acerca da exploração de

vulnerabilidades ou técnicas de ataque a um ativo de informação. O

conhecimento público de falhas e técnicas de ataque torna pessoas normais,

sem grandes conhecimentos, potenciais atacantes.

Quanto mais facilmente uma vulnerabilidade poder ser explorada, maior será a

pontuação da vulnerabilidade:

Por Provar (PP) – não existe conhecimento acerca de como explorar a ameaça


43

a. Prova de Conceito (PC)

b. Funcional (F)

c. Alta (A)

d. Não Definida (ND)

2 O estado de correção - O nível de correção das vulnerabilidades é um fator

importante para a priorização de tratamento. A vulnerabilidade típica quando

inicialmente publicada, não tem uma correção associada. Com o tempo vão

aparecendo patches de correção.

Quanto menos oficial e permanente é uma correção, maior é a pontuação da

vulnerabilidade:

a. Correção Oficial (OF)

b. Correção temporária (TF)

c. Correção tipo “remendo” (W

d. Indisponível (U)

e. Não definida (ND)

3 Informação sobre a vulnerabilidade (Report Confidence) - Esta métrica mede o

grau de confiança da vulnerabilidade existente e da credibilidade dos detalhes

técnicos conhecidos acerca dela.

Por vezes, apenas a existência da vulnerabilidade é divulgada, mas sem

detalhes específicos. A vulnerabilidade pode ser corroborada mais tarde e, em

seguida, confirmada por parte do autor ou do fornecedor da tecnologia afetada.

Quanto mais uma vulnerabilidade é confirmada/validada pelo vendedor ou por

outras fontes fidedignas, maior é a pontuação:

a. Não Confirmada (UC)

b. Não Corroborada (UR)

c. Confirmada (C)

d. Não Definida (ND)

4.3.1.3. Domínio Ambiental (Opcional):

Aqui será analisado como uma vulnerabilidade pode ser relacionada com o

comportamento de utilizadores de tecnologias de informação.

1 Potencial Para danos colaterais (PDC) - Esta medida esclarece como uma

vulnerabilidade pode gerar danos à empresa, sendo eles financeiros, de

reputação ou de atividade. Quanto maior for o impacto, maior será o valor a

atribuir.

a. Indefinido (I)

b. Nenhum (N)


44

c. Baixo (B)

d. Médio Baixo (MB)

e. Médio Alto (MA)

f. Alto (A)

g. Distribuição dos Alvos (DA)

h. Indefinido (I)

i. Nenhuns (N)

j. Baixo (B)

k. Médio (M)

l. Alto (A)

NOTA: Esta métrica está relacionada com a seguinte para poder ser

considerada.

Na próxima métrica temos a valorização do ativo para atribuição de importância

e por consequência, de valorização.

2 Requisito de segurança (Requisitos Confidencialidade - RC, Requisitos

Integridade - RI, Requisitos Disponibilidade - RD) – Esta medida esclarece

como uma vulnerabilidade afeta em termos de

Confidencialidade/Integridade/Disponibilidade (CID) um determinado ativo.

Esta métrica está relacionada com as métricas do domínio base para efeitos de

cálculo final das métricas ambientais.

a. Indefinido (I)

b. Baixo (B)

c. Médio (M)

d. Alto (A)

NOTA: Todos os valores atribuídos a cada um dos parâmetros anteriores, bem como

todos os cálculos associados, são definidos pela NIST (National Institute of Standards

and Technology). Tal pode ser consultado através do seguinte endereço Web:

http://www.first.org/cvss/cvss-guide.html

Após avaliar as vulnerabilidades mediante os pontos definidos em cada um dos

domínios anteriores, obtemos 3 resultados finais:

Resultado final métricas Base (RFB)

Resultado final métricas Temporais (RFT)

Resultado final métricas Ambientais (RFA)

A aplicação das fórmulas métricas (Figura 13 - Calculo CVSS) é um processo que

recorre a fórmulas definidas no CVSS, de seguida iremos ver um exemplo da fórmula

de cálculo da métrica base de um ativo exemplo:



45

Figura 13 - Calculo CVSS

O detalhe das formulas poderá ser encontrado no guia CVSS versão 2.0[6].

Ambos os valores resultantes de cada dos três domínios deverão ser compreendidos

entre 0 e 10. Posteriormente é feita uma média dos três valores obtidos:

.

Estando a média efetuada, é necessário enquadrar este resultado na nossa dimensão

final do risco, para tal segue-se a atribuição de pontos à dimensão da vulnerabilidade:

Média compreendida entre 0 e 3,333 inclusive - 1 ponto

Média maior que 3,333 e menor ou igual que 6,666 - 2 pontos

Média maior que 6,666 (até 9) – 3 pontos

A explicação detalhada de cada ponto de cada métrica poderá ser encontrada no

Anexo 14 - Dimensão da vulnerabilidade (CVSS).

4.3.2. Listagem de vulnerabilidades

No seguimento do ponto anterior e com o intuito de avaliar as vulnerabilidades que os

ativos da ISA possuem, foi criada uma ferramenta / calculadora de vulnerabilidades

(Figura 14 - Listagem de Vulnerabilidades). Usando as métricas CVSS onde são

listadas todas as vulnerabilidades a que os ativos da empresa estão sujeitos, essa

vulnerabilidade tem um ID (Numeração automática Crescente), um Tipo (fornecido

pelo NIST) e um Nome (fornecido pelo NIST). Como exemplo na calculadora, são

apresentadas algumas das vulnerabilidades que o ativo 0001 (Anexo 11 - Listagem de

Ativos) possui.

in [6]


46

Está dividida em métricas Base, Temporais e Ambientais e por cada uma destas

métricas calcula um valor (de 0 a 9).

Esta ferramenta / listagem de vulnerabilidades tem o intuito calcular, segundo as

regras do guia CVSS 2.0, o valor de uma vulnerabilidade nos seus três domínios

(Base, Ambiental e Temporal). É efetuada uma média simples entre os valores dos

três domínios e apresentada a dimensão final da vulnerabilidade. Esta avaliação será

usada posteriormente como um dos parâmetros de priorização de tratamento de risco.

Esta ferramenta poderá ser encontrada em detalhe no Anexo 5, todas as fórmulas

usadas estão disponíveis na calculadora fornecida em MS Excel.

4.4. Tratamento de risco

4.4.1. Listagem de riscos

Nesta fase foram levantados 43 riscos[29], como sendo os riscos que afetam

diretamente os ativos da ISA, esta fase foi efetuada tendo em conta as diretrizes da

norma ISO 27005 e os riscos catalogados na mesma.

É necessário ter conhecimento e registo de todos os riscos a que os nossos ativos

estão sujeitos, para isto contamos com diversas fontes, entre elas a norma ISO

27005[29] que dá indicações sobre o risco a que os ativos estão sujeitos. Os anexos da

norma fornecem também dicas sobre origens e motivação do risco.

Para a elaboração de uma listagem deste género não podemos esquecer os riscos

detetados ou específicos ao âmbito da empresa.

O parâmetro “Dimensão do risco” não é abordado pela norma ISO 27005 foi

adicionado para aumentar a fiabilidade a forma de priorizar um risco.

A descrição de um risco comtempla as seguintes propriedades:

I. O Tipo, a propriedade que indica o tipo de risco enfrentamos e o

enquadramento dentro standard de riscos.

Figura 14 - Listagem de Vulnerabilidades


47

II. O Risco, como propriedade do nome do risco.

III. A dimensão como propriedade que define a dimensão de determinado risco,

podendo ser, Baixo (1 Ponto), Médio (2 Pontos), ou Alto (3 Pontos).

IV. A Consequência, sendo a propriedade que define os prejuízos que um risco

poderá trazer ao ativo.


48

Do levantamento do risco surge o documento de listagem de risco, Figura 15 -

Listagem de Risco.

O documento completo pode ser visto no Anexo 4.

Figura 15 - Listagem de Risco


49

4.4.2. Priorização do tratamento de risco

Este documento (em detalhe no Anexo 6) foi construído em colaboração com os

alunos de projeto de licenciatura do ISEC, António Simões e Rui Martins. Tem como

base a norma ISO 27005 e diversas outras fontes (ISO 27001 Lead Auditors Group) e

o nosso escrutínio pessoal. A Figura 16 - Priorização do tratamento de risco

representa o aspeto final da ferramenta de priorização do tratamento de risco.

A ferramenta é composta por várias secções, englobando:

Ativos e a sua avaliação;

Vulnerabilidades e a sua avaliação;

Dimensão final do risco;

Probabilidade de acontecimento;

Impacto total do risco;

Perceção do risco;

Nível de aceitação do risco;

Probabilidade de não deteção do risco

Cálculo final da prioridade de tratamento do risco.

Um ativo está exposto aos mais variados riscos, e para que se saiba a que riscos este

está exposto, dever-se-á fazer uma análise sobre os riscos e sobre as vulnerabilidades

que surgem com estes. O enquadramento dos elementos acima referidos tem que ser

quantificado para efeitos de gestão de segurança. A avaliação dos riscos e

vulnerabilidades poderá ser realizada através de uma escala de classificação.

Para cálculo da dimensão final do risco deverá ser utilizada a seguinte formula:

Figura 16 - Priorização do tratamento de risco


50

Dimensão final do risco (DFR) = Valor do ativo * Dimensão do risco * Dimensão da

vulnerabilidade

Exemplo:

Tabela 4 - Dimensão do Risco

Valor do ativo

Dimensão do risco

Dimensão da vulnerabilidade

Dimensão final do risco

6 3 3 6 * 3 * 3 = 54

7 1 2 7 * 1 * 2 = 14

7 2 1 7 * 2 * 1 = 14

A métrica utilizada de avaliação à dimensão final do risco sobre um ativo é definida

pelos seguintes elementos:

Risco pouco perigoso – valor entre 1 e 27 pontos

Risco perigoso – valor entre 28 e 54 pontos

Risco muito perigoso – valor entre 55 e 81 pontos

4.4.2.1. Probabilidade de acontecimento

A atribuição de probabilidade de acontecimento é um parâmetro onde o avaliador do

risco tem que através da sua experiência e com recolha de outras experiências sobre

a determinada vulnerabilidade, definir com que probabilidade (de 1 a 5) um risco

poderá acontecer. Não há um método exato nem matemático de determinar a

probabilidade de determinado risco ocorrer.

4.4.2.2. Impacto do risco

Um risco pode ocorrer e por isso causar impacto[29] num ativo de informação. É

importante qualificar e quantificar este fator, de modo a obter o cálculo do impacto do

risco.

Nunca acontece (Nunca aconteceu nos últimos 3 anos) - 1 Ponto

Raro (Uma vez por ano) - 2 Pontos

Periódico (Uma vez por trimestre) - 3 Pontos

Regular (Uma vez por mês) - 4 Pontos

Frequente (Uma vez por semana) – 5 Pontos

Impacto total do risco (ITR) = Dimensão final do risco * Probabilidade

Exemplo:

Dimensão final do risco Probabilidade Impacto do risco

54 3 162

14 2 28

14 5 70 Tabela 5 - impacto do risco


51

A métrica utilizada para avaliação do valor do impacto de um risco sobre um ativo é

definida pelos seguintes elementos:

Perdas insignificantes – valor entre 1 e 99 pontos

Perdas suportáveis – valor entre 100 e 199 pontos

Perdas não suportáveis – valor entre 200 e 299 pontos

Perdas críticas – valor entre 300 e 405

4.4.2.3. Perceção e nível de aceitação do risco

Diferentes riscos, têm diferentes níveis de impacto sobre o negócio, mediante os

custos e complexidade de tratamento do risco, este terá vários níveis de aceitação.

Neste parâmetro o avaliador do risco terá que através da sua experiência e neste caso

principalmente através da sua perceção [29] sobre o valor do sistema afetado, definir

qual será o valor do risco que o ativo alvo corre e qual o possível impacto gerado

sobre o mesmo.

A classificação do valor da aceitação do risco é feita através da escala:

Não considerável - 1 Ponto

Insignificante - 2 Pontos

Muito Baixo - 3 Pontos

Baixo - 4 Pontos

Médio Baixo - 5 Pontos

Médio Alto - 6 Pontos

Alto - 7 Pontos

Muito Alto - 8 Pontos

Destrutivo - 9 Pontos

A melhor forma de classificar a aceitação é através da criação de níveis, assim o

processo fica mais simples e percetível. Para obter os intervalos de aceitação, utilizou-

se a seguinte formula:

Nível de aceitação (NA) = Valor do ativo*Probabilidade * Aceitação

Exemplo:

Valor do ativo Probabilidade Aceitação Nível de aceitação

9 5 3 Não aceitável

9 3 3 Tratável

9 2 2 Aceitável Tabela 6 - aceitação de risco

A métrica utilizada para aceitação de um risco sobre um ativo é definida pelos

seguintes elementos:


52

Não aceitável - Maior que 108 pontos

Aceitável - Menor que 54 pontos

Tratável - Entre 54 e 108 pontos

4.4.2.4. Probabilidade de não deteção de risco

Qualquer vulnerabilidade trazida por um risco pode ter uma probabilidade[29] grande de

ser detetada, ou pelo contrário, pode passar sem ser detetado.

Neste parâmetro o avaliador do risco terá que dar a sua avaliação pessoal tendo em

conta a sua perceção do risco. Tem de estimar a probabilidade de ocorrência destas

falhas derivadas deste risco, e qual é a probabilidade de estas não serem detetadas.

Para medir essa probabilidade utilizamos a seguinte escala:

Bastante Provável – 1 Ponto

Provável – 2 Pontos

Normal – 3 Pontos

Pouco Provável – 4 Pontos

Improvável – 5 Pontos

4.4.2.5. Prioridade de tratamento do risco

Um fator importante a analisar num risco é a sua prioridade de tratamento[29][3]. Com

este fator percebemos quais os riscos e vulnerabilidades merecem maior atenção e

brevidade no tratamento.

Esta priorização de tratamento de risco está relacionada com o impacto de risco e a

probabilidade de não deteção. Para obter os valores que definem a prioridade de

tratamento de risco são obtidos pela seguinte fórmula:

Prioridade de tratamento de risco[23][29] (PTR) = Valor do ativo*Probabilidade * Nível de

aceitação

Depois de esta prioridade estar calculada, já temos uma listagem de risco a tratar

antes dos outros, pois devido à sua gravidade merecem uma maior atenção. Estes

riscos mais prioritários serão tratados na próxima iteração de tratamento de risco,

sendo estes englobados no PTR – plano de tratamento de risco (RTP – sigla original

da norma).

4.4.3. Priorização do tratamento de risco (método alternativo)

A escolha do método de avaliação de riscos é um dos passos mais importantes da

construção do ISMS. De seguida vamos ver uma alternativa de avaliação de risco, que

não sendo o melhor, é uma alternativa válida.


53

Para além do método anterior de priorização / avaliação do risco para futuro

tratamento, existe um modelo mais simplista abordado na norma ISO 27001 / 27005,

que é um modelo[29] que olha apenas para os três vértices da segurança e o impacto

que determinado risco tem sobre cada um desses vértices.

Este modelo poderá ser válido para pequenas empresas que pretendem ter um SGSI

o mais minimalista e simples de operar possível, mas fica aquém das espectativas

numa organização que pretenda uma avaliação de risco mais eficaz e exata.

Avaliação de Risco Simplificado – o objetivo principal deste processo é identificar

riscos analisando “ameaças a…”, “com impacto em”, e vulnerabilidades da informação

e dos sistemas que processam informação assim como a origem das ocorrências.

Para cumprir as exigências da ISO/IEC 27001, temos de criar um documento de

classificação / avaliação de risco e de seguida usa-lo para classificar o risco a que os

ativos estão sujeitos, tomar decisão acerca dos riscos que são intoleráveis e que terão

de ser mitigados, e efetuar uma gestão do risco residual através de uma política

cuidadosa e detalhada.

Avaliação do risco baseada nos níveis de confidencialidade, integridade e

disponibilidade (Tabela 7 - Matriz CIA):

Impacto do Risco Baixo Médio Elevado

Confidencialidade – Assegurar que a informação é apenas acedida por pessoas autorizadas a terem acesso.

A divulgação não autorizada de informação terá efeitos limitados para o funcionamento da organização, para os ativos ou pessoas da organização.

A divulgação não autorizada de informação trará sérios problemas para o funcionamento da organização, ativos ou pessoas da organização.

A divulgação não autorizada de informação trará problemas graves ou mesmo catastróficos para o funcionamento da empresa, ativos ou mesmo pessoas da organização.

Integridade – Salvaguardar a exatidão e integridade da informação e métodos de processamento

A alteração ou destruição não autorizada de informação trará efeitos pouco significativos para o funcionamento da organização, para os ativos ou pessoas da organização.

A alteração ou destruição não autorizada de informação trará sérios problemas ao normal funcionamento da organização, aos ativos ou mesmos às pessoas da organização.

A alteração ou destruição não autorizada de informação trará efeitos catastróficos para o funcionamento da organização, aos ativos ou mesmo às pessoas da organização.


54

Disponibilidade – Assegurar que os utilizadores autorizadores têm acesso á informação sempre que esta seja necessária.

A interrupção ao normal acesso / uso à informação ou a um sistema de informação não trará grande prejuízo á organização ou aos seus ativos e pessoas.

A interrupção ao normal acesso / uso à informação ou a um sistema de informação pode trazer efeitos bastante adversos à organização ou aos seus ativos e pessoas.

A interrupção ao normal acesso / uso à informação ou a um sistema de informação trará efeitos catastróficos ao funcionamento da organização ou aos seus ativos e pessoas.

Tabela 7 - Matriz CIA

Este processo é bastante simples no que toca a calcular o risco referente a

determinado ativo, bastando referir que cada vértice de segurança de determinado

ativo tem de ser avaliado em termos de impacto de ocorrência:

Risco Ativo em

Questão

Impacto do risco

na

confidencialidade

do ativo.

Impacto do risco

na

Disponibilidade

do ativo.

Impacto do

risco na

Integridade

do ativo.

Valor final

do Risco

Incêndio Servidor 1 1 3 3 7

Pequena

inundação Servidor 1 1 3 1 5

Tabela 8 - Avaliação Simplificada de Risco

Tínhamos então com a Tabela 8 - Avaliação Simplificada de Risco que, era mais grave

um incendio no servidor 1, que uma pequena inundação no servidor 1, visto o valor

final do risco (soma simples do impacto causado nos três vértices da segurança) é

mais elevado no caso do Incêndio. Este risco (incêndio) tinha então de ser mitigado

com maior prioridade que o outro (inundação).

4.4.4. Plano de tratamento de risco

Após termos avaliado o risco e de termos criado uma lista de prioridades a tratar,

vamos construir um dos documentos mais importantes e detalhados do SGSI, O Plano

de tratamento de Risco[30].

Este documento (Figura 17 - Risk treatment plan) pretende listar e registar para cada

ameaça a cada ativo, um plano de ação de tratamento. Esses planos de ação têm um

responsável pela sua implementação e uma data de início e fim de implementação.

Tem também a informação detalhada da ação que será efetuada ao ativo para mitigar

determinado risco que este corre.

Para cada ação proposta está associado um nível de mitigação em percentagem, ou

seja um risco de valor 1000 que sofre uma ação de mitigação a 50% ficará com um

risco residual pós tratamento de 500.

in [29]


55

Existe ainda uma rubrica de aceitação de tratamento do risco, para análise de custos

de mitigação. Neste decide-se tratar o risco com um determinado custo, ou pelo

contrário, rejeitar o tratamento se esse custo for incomportável.

Figura 17 - Risk treatment plan

Como exemplo, surge plano de tratamento do risco sobre o ativo “Autenticação AD

WS2008” e as suas várias vulnerabilidades (Figura 17 - Risk treatment plan), entre

elas, uma vulnerabilidade chamada Buffer “overflow in Active Directory ” com um valor

calculado de risco de 5670. Neste caso foi decidido aplicar as correções apresentadas

pelo fabricante do ativo para solucionar o problema (vulnerabilidade). Pensa-se que

com esta correção, o nível de mitigação irá ser de 100% baixando assim o nível do

risco para 0 (zero). Foi decidido neste caso exemplo aceitar o tratamento visto o risco

ter como impacto potencial “Perdas Criticas” e o custo de tratamento ser nulo (0€).

Existe ainda um responsável pelo tratamento deste risco e uma data para o seu

tratamento.

Deve ser levado em atenção que os controlos irão possuir informação sensível. Esta

informação deverá ser tratada como informação confidencial.

O documento completo está presente no Anexo 7 - RTP Risk Treatment plan(DO).

4.5. Análise de lacunas

A análise de lacunas (Gap Analysis)[4][8] é uma ferramenta usada em várias áreas e

original da área da gestão de empresas. Os princípios básicos do Gap Analysis são

aplicados à gestão de projetos servindo essencialmente para registar o que é

necessário ser feito, onde é necessário ser feito, o seu estado atual e o que falta para

que este esteja concluído (a lacuna (Gap) que falta ser cumprida).


56

No seguimento deste princípio da análise de lacunas, a ISO decidiu adaptar para uso

na norma a filosofia já usada em outras áreas de negócio. Assim a ferramenta foi

adaptada de modo a que fosse capaz de abranger o processo de implementação da

norma ISO 27001 numa organização. O princípio desta ferramenta para a ISO 27001 é

a de verificação da implementação dos controlos (apenas os controlos a aplicar) por

departamento da organização e efetuar um relatório do estado de implementação dos

mesmos.

Esta ferramenta permite-nos então verificar em qualquer altura o estado de

implementação dos controlos por cada departamento e permite-nos observar a lacuna

na implementação de determinado controlo, seja, o que falta implementar.

Como podemos ver na Figura 18 - Gap Analysis, existem perguntas de controlo,

relacionadas diretamente com os controlos da norma e a resposta (implementado,

parcialmente implementado ou não implementado) a essas perguntas, permite-nos

verificar o estado de implementação de cada controlo. Mais detalhes sobre o

documento poderão ser encontrados no Anexo 8 - Gap-Analysis.

4.5.1. Relatório de análise de falhas

O relatório de análise de lacunas, é efetuado com base na análise de lacunas (Cap.

4.5) e consiste em reuniões com membros-chave do pessoal dentro de cada uma das

áreas e departamentos definidos no âmbito do ISMS. As perguntas para as reuniões

são obtidas a partir das normas ISO 27001 e ISO 27002. Todas as falhas identificadas

durante as reuniões provêm de uma matriz previamente construída, que identifica as

possíveis falhas.

Com esta análise pretende-se verificar o estado da segurança da empresa no

momento em que esta foi efetuada. Devem ser recomendadas detalhadamente as

Figura 18 - Gap Analysis


57

ações futuras com vista a correção das falhas detetadas. Deve no final ser produzido

um relatório, que coloque ao corrente a administração e todos os elementos

relacionados com a segurança da informação sobre as falhas detetadas e ações de

correção a implementar.

Na Figura 19 - Relatório de análise de falhas, podemos ver um exemplo da disposição

do relatório de falhas (versão completa encontra-se no Anexo 9)[4], especificamente o

nível de maturidade de implementação dos controlos da norma. Este relata o que está

errado com o controlo em questão e fornece recomendações práticas para resolver as

falhas detetadas. Para o averiguar nível de maturidade é usada como métrica o

modelo CMM (Capability Maturity Model) adaptado à implementação da norma ISO

27001.

Figura 19 - Relatório de análise de falhas

Esta métrica de medição tem por base a Capability Maturity Model (CMM) (marca

registrada da Carnegie Mellon University, CMU) que é um modelo de desenvolvimento

criado após um estudo de dados recolhidos de organizações que fizeram parceria com

o Departamento de Defesa dos EUA, que financiou a pesquisa.

O termo "maturidade" refere-se ao grau de formalidade e otimização de processos, de

práticas ad hoc, passos definidos formalmente, para as métricas de processos

formalmente bem definidos, para no final obter uma otimização ativa dos processos.

À métrica padrão, foram adicionados dois níveis, o CMM 0 e o CMM 6, para

possibilitar a execução do Gap Analysis. Esta abordagem foi criada e adaptada pelo

ISO 27001 Fórum –


58

https://groups.google.com/forum/?fromgroups#!topic/iso27001security.

Cada um dos resultados identificados no Apêndice 1 terá uma classificação de nível

de maturidade CMM atribuído. A tabela a seguir vai ser utilizada para identificar a

classificação para cada controlo a medir. Para esclarecimento, as avaliações dos

níveis de maturidade são descritos abaixo novamente.

0 1 2 3 4 5 6

Figura 20 - Exemplo de nível de maturidade CMM

Avaliação de Nível de Maturidade[4] - A classificação de níveis foi realizada utilizando

uma metodologia de cinco níveis baseado no Capability Maturity Model (CMM). Usou-

se a CMM por fornecer uma referência para comparação e compreensão dos

comportamentos, práticas e processos de uma organização.

Os cinco níveis são:

CMM 1 (inicial) - Há evidências de que um problema de segurança

existe e precisa ser tratado, porém não há controlos para resolver a

questão.

CMM 2 (Parcial) - Os controlos de segurança ainda estão em

desenvolvimento e / ou não há documentação para apoiar a exigência.

CMM 3 (Definido) - Os controlos de segurança foram documentados e

comunicados através da formação, mas há áreas onde o detalhe

necessário é inexistente e / ou áreas onde não estão aplicadas ou

ativamente apoiadas pela alta administração.

CMM 4 (Monitorizado) - É possível medir a eficácia dos controlos de

segurança, mas não há evidência de estarem a atingir o nível

necessário de cumprimento.

CMM 5 (Optimized) - Os controlos de segurança foram refinados ao

nível exigido pela norma ISO 27001 com base numa liderança eficaz,

gestão da mudança, melhoria contínua e comunicação interna.

Para os fins da análise de falhas existem dois níveis adicionais nos níveis das

classificações de maturidade:

https://groups.google.com/forum/?fromgroups#!topic/iso27001security


59

CMM 0 (inexistente) - A completa falta de controlo;

CMM 6 (não aplicável) - Controlo está fora do âmbito.

4.6. Conclusões retiradas do caso prático

As cinco secções anteriores enquadram-se no plano de implementação criado no

ponto 3 - Guia de implementação. Sendo que o ponto 4.2 (Classificação /

Manuseamento da Informação) enquadra-se na fase preliminar à implementação (fase

de viabilidade) e as restantes secções pertencem à fase PLAN do ciclo PDCA da

norma ISO 27001. Existem ainda algumas destas secções que pertencem à mais que

uma fase do ciclo PDCA, como é o caso da fase 4.4.4 Plano de tratamento de risco

que também se inclui na fase DO, no ciclo PDCA.

Deste caso prático, retira-se uma perceção mais clara da complexidade de

implementação da norma e do esforço horário que esta obriga. Apesar das fases

terem sido elaboradas com o objetivo de exemplo para uma futura implementação

oficial, a carga horaria necessária à elaboração das mesmas por parte do autor,

mesmo que em modo de catalogação e levantamento não exaustivo foi bastante

pesada. Conclui-se com isto que a implementação prática da norma ISO 27001 numa

organização nunca deverá ser efetuada por uma única pessoa apenas, quer pela

carga laboral necessária, quer pela falta de julgamento necessário na realização de

algumas tarefas, em que nestes casos “várias cabeças pensarão melhor que uma”, ex.

Levantamento de risco, levantamento de ativos, levantamento de vulnerabilidades,

etc… Nestes casos, se a tarefa for realizada por uma única pessoa, é bastante

provável que fiquem alguns pormenores por descobrir.

Efetuar a gestão do risco sem conhecer a totalidade das ameaças é pouco eficiente.

Por outras palavras, não basta usar sistemas contendo fórmulas para medir o "Risco"

e assim decidir o investimento em ações de proteção do programa de segurança.

Fred Cohen, define esta questão de uma forma interessante:

"Risk management: a guess multiplied by an approximation, taken to the power of an

expert opinion."

Um bom início de implementação para uma organização passará sempre por uma

análise de risco bem efetuada, sempre que possível com um especialista da área na

equipa. Para uma abordagem mais realista e eficiente dos desafios de segurança da

informação para os negócios da empresa exige-se uma abordagem ampla com o foco


60

nas ameaças, o SGSI funciona[42] melhor quando é institucionalizado um fórum

interdepartamental para deteção de ameaças.

No entanto, nunca vamos evitar que as "ameaças explorem as vulnerabilidades e

resultem em impactos" muitas vezes não imaginados anteriormente. Por mais que se

invista em prevenção e deteção, incidentes e falhas vão sempre continuar a ocorrer.

Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde

61

5. Conformidade legal do produto OneCare v2

O OneCare é um produto ISA destinado aos mercados da saúde e bem-estar, que lida

com registos médicos dos clientes/utilizadores.

Por envolver o transporte, processamento e armazenamento de informação pessoal e

sensível, a exploração do OneCare v2 (também tratado como OneCare) em território

nacional fica obrigada por lei, a um procedimento formal de aprovação pela Comissão

Nacional de Proteção de Dados (CNPD).

A primeira versão do OneCare (protótipo) obteve autorização para tratamento de

dados (peso, pressão arterial e frequência cardíaca) em 2011, apenas como projeto-

piloto e com a duração de seis meses no espaço confinado à unidade de saúde

familiar de Celas – Coimbra.

O futuro OneCare v2, pertencerá a uma ampla família (OneCare-Mais Saúde,

OneCare-Mais Perto, OneCare Clinic, OneCare Home, etc…) de soluções (produtos /

serviços) de monitorização à distância de parâmetros biomédicos (tensão arterial,

glicemia, peso, saturação de oxigénio, temperatura, entre outros), de monitorização de

bem-estar (rotina diária, pedidos de auxílio, deteção de quedas, entre outros) e de

localização de pessoas e bens através de GPS, possuindo ainda a capacidade de

envio e receção de alertas via SMS e/ou mensagem de voz para familiares ou

profissionais de saúde.

Sendo assim, tendo a segunda versão do produto (v2) a capacidade de leitura de mais

dados sensíveis de pacientes, e tendo em vista a comercialização do produto (não

sendo este apenas um protótipo, ao invés do OneCare v1) surge a necessidade de

uma nova autorização por parte da CNPD para que o produto seja viável.

Durante a realização do presente estágio o autor foi integrado na equipa de

desenvolvimento do OneCare v2 como elemento responsável por preparar a

documentação do processo de aprovação do produto junto da CNPD e por rever a

especificação/arquitetura do produto de modo a torná-lo conforme com a legislação

em vigor.

A CNPD é a organização portuguesa que está autorizada e incumbida pela República

Portuguesa de autorizar o tratamento de dados sensíveis que, por lei, são de

tratamento proibido.

A CNPD é uma entidade focada na defesa da privacidade dos cidadãos portugueses,

focando-se nos dados de varias áreas, entre elas:

Saúde


62

Trabalho

Acesso a dados de terceiros

Informação de crédito

Fluxos internacionais

Videovigilância

Marketing político e eleitores

Novas tecnologias

Dados Manuais

Telecomunicações

Temos assim que focar o desenvolvimento dos produtos de saúde no objetivo de

cumprir a legislação portuguesa e comunitária (Lei 67/ 98 – Lei da Proteção de Dados

Pessoais, diretiva 95/46/CE, portaria 247/2000, lei 41 de 2004). Como se trata de uma

aplicação que irá armazenar dados clínicos de pacientes, o OneCare v2 deve cumprir

igualmente com a portaria 247/2000 de 8 de maio (Guarda de dados de saúde) e a lei

41 de 2004 (tratamento de dados pessoais no contexto das redes de informação)

aborda o tratamento de dados pessoais no contexto das redes de informação e

serviços de comunicações eletrónicas.

Foi ainda decidido com os responsáveis pelo desenvolvimento do produto que este

deveria seguir a filosofia de norma ISO 27799 e assim ser criado de raiz um produto

que cumpre os requisitos de segurança incluídos na norma.

Nas próximas secções iremos abordar as seguintes questões:

1 - Tempos obrigatórios para a guarda de dados de saúde;

2 - Requisitos legais que o produto OneCare v2 (ou semelhante) tem de cumprir;

3 - Especificações de segurança aplicáveis ao OneCare v2 ditados pela norma

ISO 27799;

4 - Trabalho efetuado no âmbito da segurança da arquitetura do produto

OneCare v2;

5 - Considerações finais acerca da legislação.

5.1. Guarda de dados de saúde

A guarda de dados de âmbito geral deve só por si ser bem pensada, por quanto tempo

deveremos guardar os dados é uma questão pertinente para todos os tipos de dados

existentes. No que toca a dados sensíveis, como os dados de saúde é ainda mais

pertinente que esse tempo seja bem pensado e calculado. Para cumprir os requisitos

legais81[5] em termos de tempos mínimos de armazenamento de dados em saúde,

existe uma portaria da Republica portuguesa que teremos de cumprir. A Portaria


63

247/2000 de 8 de maio define os tempos de armazenamento mínimo obrigatórios dos

tipos de dados relacionados com saúde, desde dados relativos a transfusões de

sangue, compras de consumíveis hospitalares, até ao transplante de órgão.

A Tabela 9 - Tempo de guarda de dados, enumera os tipos de informação que se

tornam relevantes na perspetiva específica do produto OneCarev2 bem como o

respetivo tempo de guarda previsto por lei:

Tabela 9 - Tempo de guarda de dados

Tipo de informação Tempo de Guarda

Fichas de cadastro. 25 Anos

Processos clínicos. 5 Anos

Ficheiros ou livros de registo de doentes. 5 Anos

Receituários do SNS. 4 Anos

Processos ou outra documentação do

gabinete do utente. 5 Anos

Nesta tabela temos apenas um pequeno sumário dos tempos de armazenamento que

os sistemas da área da saúde semelhantes ao OneCare têm de cumprir nos termos

legais, desde softwares de gestão de clinicas até sistemas de Healthcare, todos os

sistemas estão abrangidos de uma forma ou de outra por esta portaria (247/2000 de 8

de Maio).

5.2. Requisitos legais

Para além dos requisitos legais relativos à guarda de dados, que vimos no ponto

anterior (5.1 Guarda de dados de saúde), existem outras condicionantes legais[32] que

terão de ser cumpridas. Nesta secção são abordadas as outras questões legais e

normativas que têm de ser cumpridas para que o tratamento (i.e., processamento) de

dados operado pelo OneCarev2 seja conforme com a legislação em vigor.

Podemos dizer que todos os sistemas que tratem dados de saúde terão

obrigatoriamente de cumprir os pontos descritos de seguida das seguintes leis /

diretivas:

Diretiva 95/46/CE

Lei nº 67 / 98 de 26 de Outubro

Lei nº 12/2005 de 26 de Janeiro

Lei 41/2004

De seguida iremos ver em aspetos as implicações destas normas e diretivas sobre

produtos que tratem dados sensíveis, no caso, dados de saúde.


64

5.2.1. Diretiva 95/46/CE

A diretiva 95/46/CE[19] foi a primeira diretiva/regra ou lei a reger segurança da

informação, era na altura quando foi lançada muito minimalista, parlamento europeu

1995. Esta diretiva foi endereçada pelo parlamento europeu aos estados membros da

União Europeia e considera que, o tratamento de dados pessoais deve ser

considerado lícito quando se destinar a proteger um interesse essencial à vida da

pessoa em causa (Lei 31).

Indica também através da lei 42 que quando necessário e no interesse da pessoa em

causa ou com o objetivo de proteger os direitos e liberdades de outrem, os Estados-

membros podem limitar os direitos de acesso e de informação, que por exemplo,

podem indicar que o acesso aos dados médicos só poderá ser obtido por intermédio

de um profissional da saúde.

Para salvaguarda da informação esta diretiva obriga que os estados-membros

estabeleçam que o responsável pelo tratamento deve pôr em prática medidas técnicas

mínimas adequadas para proteger os dados pessoais contra a destruição acidental ou

ilícita, a perda acidental, a alteração, a difusão ou acesso não autorizados.

5.2.2. Lei da Proteção de Dados Pessoais

Como vimos anteriormente (5.2.1) o Parlamento Europeu lançou uma diretiva com o

intuito dos estamos membros criarem obrigações legais que zelassem pela proteção

dos dados pessoais dos cidadãos europeus. No seguimento da diretiva a presente lei

(Lei Nº 67/98) transpõe para a ordem jurídica interna a diretiva comunitária 95/46/CE,

do Parlamento Europeu.

Desta lei (Lei Nº 67/98) poderemos sublinhar que todos os artigos lá constados são

importantes, no entanto vamos abordar os que mais respeito dizem ao OneCare v2 e

produtos semelhantes.

5.2.2.1. Tratamento de dados

A lei 67/98 aplica-se ao tratamento de dados pessoais por todos os meios, sejam

automatizados ou meios não automatizados. No entanto interessa dizer que esta lei

não se aplica ao tratamento de dados pessoais efetuados por uma pessoa singular no

em atividades exclusivamente pessoais.

Esta lei aplica-se ao tratamento de dados pessoais efetuados em território português,

ou a tratamentos de dados efetuados fora do território português mas que usem

equipamentos (informático, ou semelhante) localizados em Portugal, devendo neste

caso o responsável pelo tratamento nomear um responsável que se encontre em

território português.


65

A lei obriga a que seja sempre mantida a qualidade dos dados, recorrendo a que estes

sejam sempre tratados de forma lícita, exatos, atualizados e que sejam conservados

de forma a permitir a identificação dos titulares apenas durante o período necessário

para o cumprimento das finalidades da recolha e do tratamento.

No entanto poderão existir situações em que seja necessária a conservação de dados

para fins históricos, estatísticos ou científicos por períodos superiores ao estritamente

necessário ao seu tratamento, neste caso deverá haver uma autorização explícita por

parte da CNPD – Comissão nacional de Proteção de Dados.

Poderão ainda assim existir nuances no que toca à legitimidade do tratamento de

dados e neste caso, podemos dizer que tratamento de dados pessoais só pode ser

efetuado se o seu titular tiver dado de forma inequívoca o seu consentimento ou ainda,

se o tratamento for ao encontro de uma missão de interesse público no exercício de

autoridade pública.

Para além de todas as regras que vimos até ao momento, existem ainda regras sobre

os dados considerados sensíveis. Os dados sensíveis são de tratamento proibido,

sendo estes, dados pessoais referentes a convicções filosóficas ou políticas, filiação

partidária ou sindical, fé religiosa, vida privada e origem racial ou étnica, bem como o

tratamento de dados relativos à saúde e à vida sexual, incluindo os dados genéticos.

No entanto o tratamento de dados sensíveis pode ser permitido em casos interesse

público ou por autorização direta da CNPD.

No caso do OneCare v2, interessa ressalvar que o tratamento dos dados referentes a

saúde é permitido quando necessário para efeitos de medicina preventiva, de

diagnóstico médico, ou de prestação de outros cuidados médicos ou ainda de gestão

de serviços de saúde. Neste caso e com notificação / autorização da CNPD o

tratamento desses dados pode ainda apenas ser efetuado por um profissional de

saúde obrigado a sigilo ou por outra pessoa sujeita igualmente a segredo profissional.

5.2.2.2. Obrigações da organização

Qualquer organização que trate dados, sensíveis ou não, está sujeita a obrigações

legais, por exemplo o “direito à informação” do titular dos dados e o “direito ao acesso”

do mesmo.

A quando a recolha de dados pessoais diretamente do seu titular, o responsável pelo

tratamento deve prestar informações ao mesmo, que vão desde a identidade do

responsável pelo tratamento, a sua finalidade, até aos destinatários ou categorias de

destinatários dos dados. Deve ainda ser transmitido ao titular dos dados, a existência

e as condições do direito de acesso e de retificação dos dados, desde que sejam

necessários.


66

Existe ainda por parte da organização que trata os dados, a obrigação de informar o

titular dos dados recolhidos sem restrições, demoras ou custos excessivos, de entre

outras, a comunicação sob forma inteligível, dos seus dados sujeitos a tratamento e de

quaisquer informações disponíveis sobre a origem desses dados, bem como da lógica

subjacente ao tratamento automatizado dos dados que lhe digam respeito. No caso do

direito de acesso à informação relativa a dados da saúde, este direito é exercido por

intermédio de um médico escolhido pelo titular dos dados.

Devem ainda ser criados especiais controlos de segurança quando aos dados

envolvidos no tratamento, especialmente quando a dados sensíveis diz respeito e no

caso o responsável pelo tratamento deve pôr em prática as medidas técnicas

adequadas para proteger os dados pessoais contra a destruição, a perda acidental, a

alteração, a difusão ou o acesso não autorizados.

Caso o tratamento seja feito por um parceiro subcontratado deverão ser criadas

medidas de segurança ainda mais rígidas para manter a segurança dos dados.

Devendo também estar cientes as pessoas que no exercício das suas funções,

tenham conhecimento dos dados pessoais tratados, que estas ficam obrigadas por lei

a sigilo profissional, mesmo após o termo das suas funções.

Após pedido de autorização à CNPD, esta autorização está ainda sujeita a publicação

em Diário da República devendo a publicação especificar as finalidades do tratamento,

os dados ou categorias de dados a tratar, a categoria ou categorias de titulares dos

dados, os destinatários ou categorias de destinatários a quem podem ser

comunicados os dados e o período de conservação dos dados.

Após o processo de autorização finalizar e ser dado início ao tratamento dos dados

por parte da organização, existe ainda o dever de colaboração, que designadamente

quando a CNPD tiver necessidade, e para o cabal exercício das suas funções, esta

organização (CNPD) tem toda legitimidade para examinar o sistema informático e os

ficheiros de dados pessoais, bem como toda a documentação relativa ao tratamento e

transmissão de dados pessoais que a empresa possua.

Deve ser garantido o acesso aos sistemas informáticos aos técnicos da CNPD quando

estes o requisitarem.

5.2.2.3. Consequências do não cumprimento da legislação

Esta lei faz também referência às consequências do não cumprimento da legislação.

Por exemplo para uma organização que não cumpra intencionalmente os requisitos de

segurança obrigatórios para o tratamento incorre na punição com prisão até um ano

ou multa até 120 dias.


67

Existe ainda referência à destruição propositada de informação ou à violação da

obrigação do sigilo por parte de um individuo ou organização e, nestes casos as

consequências podem ir a prisão até dois anos ou multa até 240 dias.

5.2.3. Lei nº 12/2005 de 26 de Janeiro

A lei 12 de 2005 define o conceito de informação de saúde e de informação genética,

a circulação de informação e a intervenção sobre o genoma humano no sistema de

saúde. Esta lei em sintonia com a anteriormente falada (5.2.2 Lei da Proteção de

Dados Pessoais) surge para criar regras de tratamento de dados sensíveis, no caso

desta exclusivamente dados de saúde.

De entre todos os artigos, aplicam-se ao OneCare entre outros a definição de

informação de saúde, que diz que a informação de saúde abrange todo o tipo de

informação direta ou indiretamente ligada à saúde, de uma pessoa, quer se encontre

viva ou tenha falecido e a sua história clínica e familiar.

Esta lei define também a propriedade da informação em saúde, onde segundo a

mesma, informação de saúde é propriedade do utente a que esta diz respeito, sendo

as unidades do sistema de saúde (ou equiparados por autorização da CNPD) os

depositários da informação, a qual não pode ser utilizada para outros fins que não os

da prestação de cuidados e a investigação em saúde.

À semelhança da Lei da Proteção de Dados Pessoais, esta lei reforça a ideia da

necessidade da tomada de providências adequadas à proteção da confidencialidade

da informação, garantindo a segurança das instalações e equipamentos, bem como o

controlo no acesso à informação e o reforço do dever de sigilo de todos os

profissionais.

Aborda ainda a utilização da informação de saúde referindo que esta informação pode,

desde que anonimizada, ser facultada para fins de investigação e que apenas pode

ser usada pelo sistema de saúde com autorização escrita do seu titular.

5.2.4. Lei 41/2004

A lei 41 de 2004 aborda o tratamento de dados pessoais no contexto das redes de

informação e serviços de comunicações eletrónicas, especificando e complementando

as disposições da Lei n.º 67/98, de 26 de Outubro no que toca à segurança e

confidencialidade dos dados, referindo que as empresas que oferecem redes e ou

serviços de comunicações eletrónicas devem colaborar entre si no sentido da adoção

de medidas técnicas eficazes para garantir a segurança dos seus serviços e a

segurança da própria rede. Estas empresas estão assim obrigadas e em caso de risco

especial de violação da segurança da rede, informar gratuitamente os utilizadores


68

desse serviço da existência daquele risco, bem como as soluções possíveis para o

mitigar.

5.2.5. Considerações finais

Pelo que vimos até ao momento nas cinco secções anteriores (Guarda de dados de

saúde, Diretiva 95/46/CE, Lei da Proteção de Dados Pessoais, Lei nº 12/2005 de 26

de Janeiro, Lei 41/2004) podemos com isto concluir que os dados sensíveis estão

controlados por uma grande quantidade de leis e que o tratamento de dados de saúde

é um assunto bastante complexo. Leva a um esforço de vários meses por parte de

uma organização apenas para obter autorização da CNPD para tratamento dos dados

recolhidos.

5.3. ISO 27799 – Especificações e controlos aplicáveis ao OneCare

A ISO 27799 tem controlos e especificações que podem ser aplicadas a produtos do

género OneCare, este texto tem por objetivo resumir os controlos e especificações

aplicáveis (o resumo das implicações encontradas na norma em relação ao OneCare

podem ser encontradas no Anexo 1).

5.3.1. Definição de responsabilidades

Devemos estar cientes que uma organização que trate dados de informação de saúde

deve rever totalmente a sua política de segurança de informação pelo menos uma vez

por ano, bem como que os gestores de uma mesma organização, são responsáveis

por assegurar a segurança da informação por ela tratada. Estes deverão definir e

atribuir responsabilidades na gestão da segurança da informação. No mínimo, uma

pessoa terá de ser responsável pela segurança da informação de saúde dentro da

organização. Deverá ser definido um documento de objetividade, que defina

responsabilidades, em termos de pessoas, processos, plataformas, aplicações e

localizações.

Deverão existir acordos de confidencialidade entre as organizações que processam

dados de saúde e todas as pessoas que acedem à informação, na forma de um termo

de confidencialidade que estas devem assinar antes de terem acesso aos dados.

Deve ainda ser definida uma política de penalidades para as pessoas que quebrarem

a política de segurança de informação.

Deverão existir acordos formais, sempre que uma organização que trata dados de

saúde utilize os serviços de terceiros para processar ou disponibilizar informação,

deve efetuar um contrato formal que especifique, entre outros:

A confidencialidade e valor dos dados pessoais de saúde.


69

As medidas de segurança que têm de ser implementadas para proteção da

informação.

Os limites de acesso que poderá haver a essa informação por parte da terceira

parte.

Os níveis de serviço que terão de ser mantidos durante o contrato, ex.: SLA

Penalidades a ser aplicadas em caso de falha de uma das cláusulas.

Para além das responsabilidades referidas anteriormente, deverão ser ainda definidas

responsabilidades ao nível dos ativos de informação de saúde. É necessário manter

um inventário de responsáveis pelos ativos e definir um responsável destacado por

zelar pela segurança desses ativos.

5.3.2. Classificação de informação de saúde

Toda a informação relacionada com saúde deve ser classificada inequivocamente

como “Confidencial”[39]. A confidencialidade da informação pessoal de saúde é

amplamente subjetiva. Cada individuo tem a sua própria avaliação do que é

confidencial para si, ex. uma pessoa acabada de sair de um relacionamento abusivo

pode considerar que os dados referentes à “morada” são absolutamente confidenciais,

já para uma pessoa com uma perna partida essa informação não é relevante.

A confidencialidade da informação pessoal de saúde depende diretamente do seu

contexto. O “nome” para um individuo na lista de admissão para uma cirurgia não tem

a mesma “confidencialidade” que para outro individuo que esteja numa lista de estudo

sobre impotência sexual.

A confidencialidade da informação pessoal de saúde pode variar ao longo do ciclo de

vida de um registo clinico de um individuo.

Apesar de toda a informação ter de ser considerada confidencial, poderão haver

determinados registos sujeitos a especial atenção pois estarão em risco de acesso por

sujeitos que não deviam ou não necessitavam do mesmo. Esses registos podem

mesmo ser de funcionários da organização, chefes de estado, celebridades, membros

de grupos de elevado risco (portadores de doenças sexualmente transmissíveis,

pessoas com forte predisposição genética a doenças graves, etc…). A informação

relativa a estes sujeitos ter uma marcação especial para que os acessos À mesma

seja fortemente controlado.

Deve ser efetuada uma classificação em termos de disponibilidade, integridade, e

importância a processos, equipamentos informáticos, software, espaços físicos e

pessoas.


70

Os sistemas que processam informação pessoal de saúde devem avisar os

utilizadores da natureza e confidencialidade da informação a ser acedida, por exemplo

no login, ou página inicial. Deve também garantir que quando é emitida uma cópia em

papel de informação pessoal, esta saia rotulada como “CONFIDENCIAL”, por

exemplo, em marca de água.

5.3.3. Acesso à informação de saúde

Quem, quando e onde acede? Todo o tipo de acessos a informação de saúde, seja

porque meio for, devem ser controlados, triados e registados[39].

Deve ser mantido um registo de informação detalhada das pessoas que acedem aos

dados de informação pessoal de saúde, que no mínimo indique a identificação

“verificada” do utilizador, endereço e empregador anterior.

O controlo de acessos aos registos de informação deve ser efetuado de modo a que

um utilizador apenas tenha acesso a um determinado registo, quando:

Exista um relacionamento direto, profissional de saúde – paciente;

O utilizador estiver a executar uma tarefa relacionada com o sujeito a que o

registo diga respeito;

Haja uma necessidade explícita daquela informação para auxílio de uma

atividade médica.

Em caso de cessação de ligação ou contrato de uma pessoa (ou utilizador) com uma

organização, deve ser bloqueado o mais rápido possível os acessos à informação.

Não devem ser esquecidos os voluntários, estagiários, colaboradores ou organizações

terceiras. Após lhe ser retirado o acesso, o sujeito em questão deve receber uma

notícia do sistema que deixou de ter acesso à informação.

Atualmente grande parte da informação é acedida através de meios digitais, no

entanto não deve ser descurada a segurança física devendo existir um controlo físico

de acesso à informação e aos sistemas que processam informação. Este controlo

deverá assegurar que só pessoas autorizadas poderão aceder.

Podemos mesmo dizer que um registo eficaz e respetiva auditoria serve de controlo ao

mau uso da informação, portanto de todos os requisitos de segurança de proteção de

dados pessoais de saúde, os mais importantes são os relacionados com a auditoria e

registo de ações e acessos à informação (logs). Estes métodos asseguram e

fomentam responsabilidade por parte dos utilizadores do sistema, aparecendo também

como um grande incentivo aos utilizadores para usarem os sistemas de acordo com as

regras de segurança.

A falha humana é bastante comum, contando que o Homem erra. Para futuros

apuramentos de verdade clínica, erros médicos, etc.. os sistemas de informação que


71

processam dados de saúde, devem implementar um método de auditoria, registo de

acessos por utilizador, criação, alteração, eliminação de informação e todo o tipo de

ações que o utilizador efetua no sistema. Deve ser guardado por exemplo um

identificador da máquina onde este utilizador está a aceder e mantido um registo da

transmissão de troca mensagens contendo registos de informação pessoal contendo

data, origem e destino mas nunca detalhes acerca do conteúdo.

Uma das fases mais importantes do controlo de acessos é a também a primeira de

todas, o registo de utilizadores. Este registo deve ser efetuado formalmente

englobando a verificação de níveis de permissões e áreas de acesso, sempre de

acordo com as reais autorizações do utilizador. Periodicamente terão de ser

verificadas e atualizadas as permissões de um utilizador de forma a assegurar que os

detalhes estão completos e se o utilizador ainda necessita do acesso.

Estes registos diferem de utilizador para utilizador, no que diz respeito aos direitos de

acesso. Devem ser definidas diversas estratégias de controlo de acesso que irão

ajudar significativamente a assegurar a confidencialidade e integridade da informação:

Role-Based – Devem ser definidos Roles em que um utilizador se encaixa,

podendo fazer parte de um ou vários Roles de acesso, ex. enfermeiro, médico,

auxiliar, etc…

Grupos de Acesso – definição de grupos de acesso a que os utilizadores

podem pertencer, ex. equipas médicas.

Acesso descritivo – Um utilizador com acesso legítimo aos dados (por

exemplo, médico de família) pode fornecer acesso temporário a outro utilizador

(por exemplo um especialista terapêutico).

O acesso à informação mais comum atualmente é o acesso por meio digital, por sua

vez na quase totalidade este acesso é controlado por intermedio de pelo menos uma

password. Devemos estar cientes no caso da saúde e outros sistemas críticos, que a

complexidade de uma password de acesso aos sistemas deve ser bem pensada, caso

seja um sistema de urgência essa complexidade poderá causar complicações, neste

caso devem ser pensados outros métodos de autenticação.

5.3.4. Salvaguarda e manutenção da informação

Os dados mesmo quando estão sujeitos a apertados controlos de segurança, não

estão livres de percas, eliminação involuntárias ou perca súbita da integridade. Por

este motivo devem ser mantidos backups atualizados de todos os dados pessoais de

saúde num local fisicamente seguro para que quando necessário estes possam ser

acedidos.


72

A informação está sempre sujeita a ameaças, sejam internas, sejam externas. Uma

das grandes ameaças à informação é o “código malicioso”[39], devendo por isso ser

implementado um sistema eficaz de prevenção, deteção e irradicação de malware e

outros tipos de código malicioso, em todos os postos de trabalho dos utilizadores que

acedam aos dados pessoais de saúde, os dos próprios ou os de terceiros.

No caso do OneCare deve ser assegurado que os médicos e outros profissionais de

saúde tenham no seu posto de trabalho um antivírus-firewall de bom desempenho e

deve ser aconselhado aos pacientes que só acedam aos seus dados no portal web

caso tenham um bom antivírus.

Com o tempo (não esquecendo as obrigações legais - Guarda de dados de saúde) é

possível que a informação deixe de ser útil e necessite de ser descartada, neste caso

e logo após esta informação deixar de ser considerada útil ou necessária, as

organizações devem apagar eficientemente ou mesmo destruir suportes que

contenham informação de saúde (sejam softwares aplicacionais, ou dados pessoais

de saúde). Um despojo ineficiente dos suportes poderá levar a brechas severas na

confidencialidade dos pacientes. De notar que equipamentos, dados ou software que

deem suporte a um sistema que contenha dados pessoais de saúde, não poderão ser

removidos ou deslocalizados da localização atual sem autorização direta da chefia da

organização.

5.4. Arquitetura OneCare v2

Durante a participação do autor na equipa de desenvolvimento para tarefas de revisão

de arquitetura, entre outras tarefas, o software utilizado para desenho dos requisitos

foi o EA – Enterprise Architect, da Sparx Systems, ver Figura 21 - Ambiente de

trabalho Enterprise Architect. Este software é usado globalmente por equipas de

desenvolvimento[40], revelando-se o conhecimento obtido na utilização desta

plataforma uma mais-valia para o autor no que toca ao desenho de sistemas de

informação e arquiteturas de comunicação.


73

Figura 21 - Ambiente de trabalho Enterprise Architect – desenho OneCare v2

O OneCare é uma gama de soluções / conjunto de serviços dedicado à promoção de

saúde e bem-estar dos clientes. Os dados recolhidos estão disponíveis num portal

Web onde podem ser consultados pelo paciente, familiares do paciente e prestadores

de cuidados de saúde. Sempre que ocorre um desvio nas medições são gerados

alertas automáticos e distribuídos pelas pessoas em questão (prestadores de cuidados

de saúde, familiares, etc…).

Os equipamentos de medição ligam-se a uma BOX (consola de monitorização) e esta

liga-se à WEB através de uma ligação ADSL, Fibra, Etc…

A comunicação dos dispositivos de medição com a BOX é feita através de Bluetooth e

a BOX é responsável por transmitir os dados recolhidos para os servidores ISA (Figura

22 - esquema de comunicação OneCare v2[18]).


74

Figura 22 - esquema de comunicação OneCare v2

Tendo em conta esta diversidade de equipamento, tecnologias, transmissão de dados

entre equipamentos foi necessário criar requisitos de segurança e atributos de

qualidade destinados a aumentar a fiabilidade e segurança do produto e dos seus

utilizadores.

Entre os requisitos estão:

Restrições técnicas – protocolos ou mecanismos seguros que o produto tem de

usar, quer a nível de hardware como de software, para garantir que a

informação por ele tratada, transmitida ou disponibilizada, é o feito sempre de

maneira segura, por exemplo ver Figura 24- Ex. Restrições Técnicas.

Restrições legais – como visto no ponto Requisitos legais são requisitos que o

produto tem que seguir obrigatoriamente para que este esteja conforme com a

legislação em vigor, por exemplo ver Figura 23- Ex. Restrições Legais.

Figura 24- Ex. Restrições Técnicas Figura 23- Ex. Restrições Legais

in [43]


75

Atributos de qualidade – Não sendo requisitos que o produto tem que seguir

obrigatoriamente para que este esteja conforme, são atributos que o produto deve

seguir para que esteja de acordo com os níveis de segurança desejados e, para

que esteja de acordo com os padrões da indústria. Podemos ver alguns exemplos

dos atributos de qualidade criados para o produto na Figura 25- Ex. Atributos de

qualidade.

5.5. Funcionamento da arquitetura OneCare v2 – Resposta à CNPD

Outra questão levantada pela CNPD para o processo de autorização prende-se com o

facto de como os sistemas que tratam informação salvaguardam a informação que

estes tratam e disponibilizam assim como é controlado o acesso à mesma. Pretendem

ver respondidas questões como “como o sistema garante a disponibilidade da

autenticação?” ou “que política de backup possui o sistema?”.

Nos parágrafos seguintes (Autenticação, acesso físico ao meio, funcionamento da

aplicação WEB e backups de informação) iremos ver as respostas que foram

construídas para dar resposta as questões levantadas pela CNPD.

5.5.1. Autenticação

Os controladores de autenticação estão colocados em locais com acesso limitado a

pessoas autorizadas, para que os controladores de Autenticação não sejam

comprometidos por uma invasão física.

Mecanismos de Autenticação - Os controladores de Autenticação assentam na

tecnologia Microsoft AD, usando como mecanismos de autenticação Kerberos V5, SSL

e TLS, da forma:

A autenticação de rede confirma a identificação do utilizador para qualquer serviço que

o utilizador tente aceder. Para fornecer esse tipo de autenticação, o sistema de

segurança oferece suporte a mecanismos de autenticação diferentes, Kerberos V5, a

camada de sockets de segurança (SSL) e a segurança da camada de transporte (TLS)

e, para manter compatibilidade com sistemas antigos, o NTLM.

Figura 25- Ex. Atributos de qualidade


76

Disponibilidade da autenticação - Existem 3 servidores (Figura 26 - Disponibilidade da

autenticação) distintos e isolados de autenticação, para que mesmo que um fique

indisponível os outros continuem a efetuar a autenticação dos utilizadores. Além de

aumentar a disponibilidade esta divisão possibilita um balanceamento de carga pelos 3

servidores aumentando uma vez mais a disponibilidade em caso de possível

sobrecarga de acessos.

Figura 26 - Disponibilidade da autenticação

Estes servidores de autenticação encontram-se em 2 datacenters diferentes, com

ligações de rede redundantes para o caso de uma falhar a outra possa assumir a

continuidade das operações.

Base de Dados de Utilizadores AD - Estes servidores não possuem acesso ao

exterior, os acessos à base de dados é feito apenas por servidores aplicacionais

dentro da infraestrutura. Para que não seja possível proceder ao apagamento,

alteração dos dados, estas bases de dados são apenas de leitura para operações

feitas fora dos servidores de autenticação.

5.5.2. Autorização de acessos

A Autorização de acessos é garantida internamente através da plataforma OneCare

que possui grupos de acesso, a esses grupos de acesso farão parte alguns

utilizadores na base de dados de utilizadores AD, e é a esses grupos que é concedida,

ou não autorização a aceder dados em determinada parte da aplicação.

As bases de dados que contem informação de saúde, de grupos de acesso e de

utilizadores não possuem acesso direto ao exterior, sendo os acessos autorizados

apenas à aplicação OneCare.


77

5.5.3. Acesso Físico ao Meio

Controlos de acesso às infraestruturas - Todas as salas possuem controlo de acessos

por RFID, mantendo o registo de entradas e saídas assim como a data e hora dos

acessos. Cada pessoa tem acesso restrito às salas a que tem autorização para entrar.

Controlo de acessos aos Data Centers - O acesso aos Data Centers é restrito e

apenas possível a 2 pessoas na empresa (IT Manager e IT Systems Administrator),

esta restrição / controlo é implementada através de um controlador de acessos por

leitor de dados biométricos, no caso, leitor de impressões digitais.

5.5.4. Funcionamento da aplicação WEB

Mecanismos de segurança - A aplicação terá mecanismos de segurança, para

possibilitar o acesso à informação sem por em causa a informação:

Toda a informação transmitida na rede é transmitida de forma impercetível a

uma pessoa que se introduza no meio entre o emissor (servidor ISA) e o

recetor (utilizador da aplicação), sendo toda a informação trocada através de

uma camada encriptada “HTTPS”.

Se em algum caso um utilizador deixar uma página aberta, esta após um

tempo curto de inatividade (1 – 2 minutos) irá automaticamente efetuar um

redireccionamento para uma página sem conteúdo sensível e, obrigará o

utilizador a efetuar nova autenticação de seguida.

A aplicação irá usar um método de autenticação de 3 vetores, usando login +

palavra-chave + cartão do cidadão para assim garantir a autenticidade de um

acesso à aplicação.

A aplicação deverá fazer referência no momento em que uma página é aberta

acerca da legislação em vigor e nas consequências do acesso a esta por

pessoas não autorizadas.

Todas as operações, alterações aos dados, visualização de informação, serão

registadas em historial, do género “quem e quando efetuou o quê”.

5.5.5. Backups de Informação

Frequência de Backup - Estão definidas 4 frequências diferentes para o backup:

Backup Diário – Realizado diariamente às 23h:00m

Backup Semanal – Realizado aos domingos às 23h:00m

Backup Mensal – Realizado todos os meses, no primeiro dia de cada mês

pelas 23h:00m

Backup Anual – Realizado todos os anos no primeiro dia, 1 de Janeiro às

23h:00m


78

Localização de Backups - A informação quando exportada para backup é exportada

num formato encriptado para que se for inadvertidamente acedida, esta não seja

percetível.

Os backups são mantidos num datacenter separado fisicamente dos servidores de

dados, num dispositivo de rede dedicado ao armazenamento de backups.

Replicação de Backups - Para aumentar substancialmente a segurança da informação

temos a informação replicada de 2 formas diferentes:

As cópias mensais são armazenadas (encriptadas) e TAPE num cofre seguro,

contra intrusão e incêndio, em que a sua localização só é conhecida por

elementos controlados dentro da organização.

Os backups são replicados minuto a minuto num datacenters externo (Figura

27- Replicação de backups por SFTP) contratado para o efeito, através de

protocolos de transferência de informação seguros (SFTP).

Estão então vistos todos os requisitos que o produto OneCare v2 tem de cumprir para

estar de acordo com as imposições legais, bem como as características técnicas que

este deve ter implementadas para que assim, cumpra com os requisitos de segurança

de informação que são exigidos nos dias de hoje.

Figura 27- Replicação de backups por SFTP

Cap. 6 Conclusões Segurança da Informação na Saúde

79

6. Conclusões

Em conclusão pensa-se que os objetivos propostos inicialmente neste trabalho foram

alcançados. O levantamento de requisitos de segurança e tratamento de dados para o

OneCare v2 foi concluído com sucesso, no entanto o autor salienta as dificuldades que

encontrou para conseguir junto da parte da CNPD quais eram realmente os seus

requisitos e necessidades.

Este trabalho teve um grande entrave, o tempo, que em junção com a complexidade

das normas da série ISO 27000 tornaram-se um grande obstáculo à realização deste

trabalho.

Existem ainda pelas pesquisas bibliográficas realizadas, centenas de abordagens

existentes à implementação da norma ISO 27001. Esta realidade trás assim um

acréscimo ao nível de dificuldade na construção de um SGSI e trouxe também ao

autor uma acrescida carga na compreensão da filosofia da norma e na construção do

plano de implementação, tendo este que de entre todas abordagens, criar uma própria

abordagem, que se tentou, que incluísse o melhor de todas as outras abordagens

existentes.

Com este trabalho, o autor pensa ter fornecido à ISA meios e ferramentas que

permitem identificar problemas na segurança da informação e ainda documentos que

serão uma boa ajuda inicial para a implementação final da norma ISO 27001 na

empresa.

Pode-se afirmar que a implementação da norma ISO 27001 surge na opinião do autor

como um bom investimento para todos os tipos de organizações, visto os benefícios

trazidos pelo SGSI a nível do controlo da segurança da informação são bastante

positivos, quer a níveis financeiros, quer a níveis competitivos e de imagem externa da

organização.

Conclui-se ainda que são necessários alguns anos de experiência na execução de

projetos de implementação de um SGSI a ponto de se conseguir montar um sistema

sem falhas e com um bom funcionamento a nível de processos internos.

“Não se gere o que não se mede, não se mede o que não se define, não se define o

que não se entende, não há sucesso no que não se gere” (William Edwards Deming).

Ao longo do mestrado o autor foi criando alguma sensibilidade para as nuances

específicas da área da saúde e para a segurança da informação nesta área, o que

sem dúvida foi uma relevante ajuda na realização deste trabalho.

Cap. 6 Conclusões Segurança da Informação na Saúde

80

Foi para o autor bastante gratificante e enriquecedor a realização deste trabalho, quer

a nível de conhecimento ganho, quer a nível de desenvolvimento do intelecto pessoal.

De futuro, o autor pretende continuar o estudo sobre segurança da informação, em

especial, a implementação da norma ISO 27001, e se possível tornar-se ISO 27001

Lead Implementer.


81

Referências

[1] ABNT, “Norma NBR ISO/IEC 27001”, 2006

[2] Assembleia da República. “Lei Nº 67/98. D.R. Nº 247, Série I-A De 1998-10-

26”, 2008

[3] Department of Education - State Government of Victoria. “Risk Treatment

Priority - State Government of Victoria”, n.d

[4] ISO27k Forum. “ISO 27001 ISMS Gap Analysis Executive Summary”, n.d

[5] Gomes, Maria Alice, CNPD - Comissão Nacional de Proteção de Dados.

“Guarda De Dados De Saúde”, n.d

[6] Peter Mell. “A Complete Guide to the Common Vulnerability Scoring System

Version 2.0”, n.d

[7] Roque, Ana. “Interconexão De Dados”, n.d

[8] Rouse, Margaret. “Gap Analysis.” SearchCIO-MidMarket.com, n.d

[9] Wikipedia contributors. “British Standards Institution.” Wikipedia, the Free Encyclopedia, July 22, 2012

[10] Wikipedia contributors, “ISO/IEC 27001.” Wikipedia, the Free Encyclopedia, July 17, 2012

[11] Alberts, Christopher. “The OCTAVE Method”, Software Engineering

Institute, Carnegie Mellon University

[12] Coleman, Jonathan. “Assessing Information Security Risk in

Healthcare Organizations” 2004

[13] West, Scott. ATI. “OCTAVE-Best Practices Comparative Analysis”. U.S.

Army Medical Research and Materiel Command - Fort Detrick. 2003

[14] Brophy, Michael. “ISO 27001 Global Survey”. Certification Europe. 2008

[15] GEP/MTSS , PORDATA. “Salário médio mensal dos trabalhadores por

conta de outrem”. N.d

[16] Salah, Osama. “Mandatory Information Security Management System

Documents Required for ISO/IEC 27001 Certification”. 2009

[17] Mell, Peter. “A Complete Guide to the Common Vulnerability Scoring

System Version 2.0.”. n.d

[18] Intelligent Sensing in Healthcare. “Soluções OneCare”.2012

[19] Directive 95/46/EC of the European Parliament and of the Council.

“Protection of individuals with regard to the processing of personal data and on

the free movement of such data”. 24 Outubro 1995.

[20] Best practice certification. “ISO 27001—Information Security

Management Systems”. Abril 2012


82

[21] ABNT. “Tecnologia da informação, Técnicas de segurança, Gestão de

riscos de segurança da informação”. 2008

[22] ISO27k Security. “ISO 27002”, n.d

[23] Calder, Alan & Watkins, Steve. “IT Governance - A Managers Guide to

Data Security and ISO 27001 - ISO 27002”. 2008

[24] Arnason, Sigurjon. “How to Achieve 27001 Certification - An example of

applied compliance management”. 2007

[25] ISO 27000. “Information technology - Security techniques - Information

security management systems - Overview and vocabulary”. 1ª ed 2009

[26] ISO 27001. “Information Security management systems -

Requirements”. 1ª ed. 2005

[27] ISO 27002. “Code of practice for information security management”. 1ª

ed. 2005

[28] ISO 27004. “Information technology – Security techniques – Information

security management – Measurement”. 1ª ed. 2009

[29] ABNT ISO 27005 - Gestão de riscos de segurança da informação, 1ª

ed. 2008

[30] Menon, Jay. “Guidelines for developing a Risk Treatment Plan”. 2009

[31] Swindon, Borough Council’s Risk Management Group. “Information

Security Forum Terms of Reference”. 2009

[32] Everett, Christopher. “Bridging the Gap Between Computer Security And

Legal Requirements”. N.d

[33] Harden, Steve. “Dois Passos Simples Para Corrigir Uma Não-

conformidade Intencional”. N.d

[34] Rildo (@rildosan) Santos. “Gestão De Risco e Controle Interno Com

COSO”, Agosto 2010.

[35] The SANS Institute. “. Measuring Controls”, n.d.

[36] RFC 2196. “The Site Security Handbook”

[37] Wikipedia contributors. “Information security.” Wikipedia, the Free

Encyclopedia, July 22, 2012

[38] Alberta Government Services. “Information Security Classification”. 2005

[39] ISO 27799. “Health informatics -- Information security management in

health using ISO/IEC 27002”. 2009

[40] Sparx Systems. “The UML Modeling Tool of Choice, Globally”. 2010

[41] NIST SP 800-30. “Guide for Conducting Risk Assessments”. 2011

[42] Süffert Sandro. “Risco, Vulnerabilidade, Ameaça e Impacto”. 2011

[43] ISA Intellicare. “Produto OneCare”. 2012

[44] Symantec. “2012 Norton Study: Consumer Cybercrime”. 2012


83

Anexos

Anexo 1 - ISO 27799 – Especificações e controlos

aplicáveis ao OneCare

Este texto tem por objetivo resumir os controlos e especificações da ISO 27799

pertinentes para o caso do produto OneCare, resume as implicações da norma ISO

27002 na ISO 27799.

7.2 – Information security policy – Este ponto define os requisitos base para a política

de segurança de informação de uma organização.

7.2.1 – Information Security Policy Document

a) Devem ser seguidas todas as leis, normas e contratos legais, mesmo até os que aferem responsabilidades éticas e profissionais.

b) Deve ser definido um protocolo / procedimento para ser aplicado quando a informação é partilhada, quer para investigação quer para ensaios clínicos.

7.2.2 – Review of the information security policy document

Uma organização que trate dados de informação de saúde deve rever totalmente a sua

política de segurança de informação pelo menos uma vez por ano.

7.3 – Organizing information security - Este ponto define os requisitos base ao nível de

acordos e contractos e definição de responsabilidades para a política de segurança de

informação de uma organização.

7.3.1 - Os gestores de uma empresa que trate dados de saúde são responsáveis por

assegurar a segurança da informação por ela tratada.

7.3.2.1 – Definir e atribuir responsabilidades na gestão da segurança da informação.

No mínimo, uma pessoa terá de ser responsável pela segurança da informação de

saúde dentro da organização.

Deverá ser definido um documento de objetividade, que defina responsabilidades, em

termos de pessoas, processos, plataformas, aplicações e localizações.

7.3.2.3 – Acordos de confidencialidade

As organizações que processam dados de saúde devem fornecer a todas as pessoas

que acedem à informação, um termo de confidencialidade que estas devem assinar

antes de terem acesso aos dados.

Deve ser definida uma política de penalidades para as pessoas que quebrarem a

política de segurança de informação.

7.3.3.1 – Identificação de riscos em elementos externos à organização

As organizações que processam dados de saúde devem efetuar um levantamento

exaustivo dos riscos que ameaçam os ativos de informação e de seguida implementar

os devidos controlos aos riscos identificados.

7.3.3.3 – Acordos formais com terceiras partes

Quando uma organização que trata dados de saúde utiliza os serviços de terceiros

para processar ou disponibilizar informação, deve efetuar um contrato formal que


84

especifique, entre outras coisas:

a) A confidencialidade e valor dos dados pessoais de saúde. b) As medidas de segurança que têm de ser implementadas para proteção da

informação. c) Os limites de acesso que poderá haver a essa informação por parte da terceira

parte. d) Os níveis de serviço que terão de ser mantidos durante o contrato, ex.: SLA e) Penalidades a ser aplicadas em caso de falha de uma das cláusulas. f) Etc…

7.4 – Gestão de Ativos - Este ponto tem por objetivo definir responsabilidades e

classificar ativos

7.4.1 – Responsabilidade pelos ativos de informação de saúde

a) Manter um inventário de responsáveis pelos ativos. b) Ter um responsável destacado que zele pela segurança desses ativos. c) Devem existir regras de utilização desses ativos, documentadas e

implementadas.

7.4.2.1 – Classificação de informação – Toda a informação relacionada com saúde

deve ser classificada inequivocamente como “Confidencial”

a) A confidencialidade da informação pessoal de saúde é amplamente subjetiva. Cada individuo tem a sua própria avaliação do que é confidencial para si, ex.: uma pessoa acabada de sair de um relacionamento abusivo pode considerar que os dados referentes à “morada” são absolutamente confidenciais, já para uma pessoa com uma perna partida essa informação não é relevante.

b) A confidencialidade da informação pessoal de saúde depende diretamente do seu contexto. O “nome” para um individuo na lista de admissão para uma cirurgia não tem a mesma “confidencialidade” que para outro individuo que esteja numa lista de estudo sobre impotência sexual.

c) A confidencialidade da informação pessoal de saúde pode variar ao longo do ciclo de vida de um registo clinico de um individuo.

Apesar de toda a informação ter de ser considerada confidencial, poderá haver

determinados registos sujeitos a especial atenção pois estarão em alto risco de acesso

por sujeitos que não deviam ou não necessitavam. Esses registos podem mesmo ser

de funcionários da organização, chefes de estado, celebridades, membros de grupos

de elevado risco (portadores de doenças sexualmente transmissíveis, pessoas com

forte predisposição genética a doenças graves, etc…). A informação relativa a estes

sujeitos ter uma marcação especial para que os acessos À mesma seja fortemente

controlado.

Deve ser efetuada uma classificação em termos de disponibilidade, integridade, e

importância a processos, equipamentos informáticos, software, espaços físicos e

pessoas.


85

7.4.2.2 – Manuseamento e identificação da informação

Os sistemas que processam informação pessoal de saúde, deve avisar os utilizadores

da natureza e confidencialidade da informação a ser acedida, por exemplo no login, ou

página inicial, e deve garantir que quando é emitida uma cópia em papel de informação

pessoal, esta saia rotulada como “CONFIDENCIAL”, por exemplo em marca de água.

7.5 – Recursos Humanos – Responsabilidades dos recursos humanos antes e depois

da contratação de um novo colaborador

7.5.1.1 – Papéis e Responsabilidades – antes da contratação.

Deve ser criado um documento descritivo que documente a descrição do “lugar” a ser

ocupado, papel e responsabilidades no que toca à política de segurança da informação

da organização.

Deve ser mantida uma atenção especial sobre os trabalhadores temporários,

estagiários e funcionários de curta duração.

7.5.1.2 – Triagem de acessos

Deve ser mantido um registo de informação pessoal das pessoas que acedem aos

dados de informação pessoal de saúde, que no mínimo indique a identificação

“verificada” do utilizador, endereço e empregador anterior.

7.5.1.3 – Terms and conditions of employment

Deve existir um documento que indique as responsabilidades de cada individuo pela

segurança da informação.

a) Penalidades que devem ocorrer, quando for identificada uma falha à politica de segurança da organização.

b) Assegurar que mesmo depois do término do contrato as questões de sigilo e confidencialidade da informação são mantidas pelo ex. funcionário.

7.5.2.1 – Responsabilidades da gestão

Deve ser dada especial atenção a sujeitos que não querem que os seus dados

pessoais não sejam acedidos por funcionários de saúde que lhes sejam vizinhos,

colegas, ou familiares.

Também a membros do staff que não pretendam ver a informação de amigos, vizinhos

ou familiares, deve-lhes ser dada essa hipótese / escolha.

Um sistema eficaz deve assegurar que é capaz de adereçar estas exclusões de

acesso.

7.5.3.2 – Cessação de acessos

As organizações devem cessar o mais rápido possível os acessos à informação de

sujeitos que tenham acabado a ligação com a organização, voluntários, estagiários,

colaboradores ou organizações terceiras.


86

O sujeito deve receber uma notícia do sistema que deixou de ter acesso à informação.

7.6 – Segurança física e do meio – controlo de acessos aos equipamentos e dados em

formato físico.

7.6.1.1 – Perímetro de segurança física

Deve existir um controlo físico de acesso à informação e aos sistemas que processão

informação. Esse controlo deverá assegurar que só pessoas autorizadas poderão

aceder.

7.6.2.4 – Secure disposal or re-use of equipment

As organizações devem apagar eficientemente ou mesmo destruir suportes que

contenham informação de saúde (sejam softwares aplicacionais, ou dados pessoais de

saúde) logo após esta informação deixar de ser considerada útil ou necessária.

7.6.2.5 – Removal of property

Equipamentos, dados ou software que deem suporte a um sistema que contenha

dados pessoais de saúde, não pode ser removida ou deslocalizados da localização

atual sem autorização direta da organização.

7.7 – Gestão de operações e comunicações – o que deve ser feito para proteção

contra vírus e malware e como devem ser controladas as comunicações de

informação.

7.7.4.1 – Controlo contra código malicioso

Deve ser implementado um sistema eficaz de prevenção, deteção e irradicação de

malware e código malicioso, em todos os postos de trabalho dos utilizadores que

acedam aos dados pessoais de saúde, os dos próprios ou os de terceiros.

No caso do OneCare deve ser assegurado que os médicos e outros profissionais de

saúde tenham no seu posto de trabalho um antivírus-firewall de bom desempenho e

deve ser aconselhado aos pacientes que só acedam aos seus dados no portal web

caso tenham um bom antivírus.

7.7.5 – Backup informação de saúde

Devem ser mantidos backups atualizados de todos os dados pessoais de saúde num

local fisicamente seguro para que futuramente possa ser acedido.

7.7.7 – Manuseamento de Media

Toda a informação que circule em formatos amovíveis, diskettes, CD’s, DVDs, Flash

Disks, etc… Deve ser sempre encriptada e devidamente protegida contra roubo.


87

7.7.7.2 – Alienação de Media

As organizações devem apagar de forma eficiente ou mesmo destruir suportes que

contenham informação de saúde, logo após esta informação deixar de ser considerada

útil ou necessária. Um despojo ineficiente dos suportes poderá levar a brechas severas

na confidencialidade dos pacientes.

7.7.7.3 – Procedimentos de manuseamento de informação

Todos os suportes de informação devem ser fisicamente protegidos e quando não o

poderem estar, os seus dados devem ser devidamente encriptados. O Estado e

localização de dispositivos não encriptados contendo dados pessoais devem ser

fortemente monitorizados.

7.7.8.3 – Troca de mensagens eletrónicas

Organizações que transmitam dados pessoais por via de correio eletrónico devem criar

alguns métodos para assegurar a confidencialidade e integridade da informação. EX:

mail com chaves publicas-Privadas

A informação trocada por email deverá sempre ser encriptada.

7.7.10.1 – Monitorizar a informação

De todos os requisitos de segurança de proteção de dados pessoais de saúde, dos

mais importantes são os relacionados com a auditoria e registo de ações e acessos à

informação (logs).

Estes métodos asseguram e fomentam responsabilidade por parte dos utilizadores do

sistema, Aparecendo também como um grande incentivo aos utilizadores para usarem

os sistemas de acordo com as regras de segurança.

Um registo eficaz e respetiva auditoria serve de controlo ao mau uso da informação e

mesmo uso abusivo da mesma.

7.7.10.2 – Auditoria de Acessos

Os sistemas de informação que processam dados de saúde deve possuir um sistema

de registo sobre o tipo de ações que o utilizador efetua no sistema. O sistema de

registos ( logs ) deve possuir uma maneira de identificar unicamente um utilizador, o

paciente a que os dados se referem, data e hora de cada operação efetuada.

Deve ser guardado por exemplo um identificador da máquina onde este utilizador está

a aceder (Ex: endereço IP)

Deve ser mantido um registo da transmissão de troca mensagens contendo registos de

informação pessoal contendo data, origem e destino mas nunca detalhes acerca do

conteúdo.

A organização deve cuidadosamente averiguar o período que os dados devem ser

armazenados, dados e informação clinica, tendo em conta normas clinicas e


88

legislação, para futuros apuramentos de verdade clínica, erros médicos, etc..

7.8 – Controlo de acessos – Quem, quando e onde acede. Gestão de acessos à

informação pessoal de saúde.

7.8.1.1 – Requisitos para controlo de acessos em saúde

O controlo de acessos aos registos deve ser feito de modo a que um utilizador tenha

acesso a um determinado registo, quando:

a) Exista um relacionamento direto, profissional de saúde – paciente. b) Quando o utilizador estiver a executar uma tarefa relacionada com o sujeito a

que o registo diga respeito. c) Quando haja uma necessidade explícita daquela informação para auxílio de

uma atividade médica.

7.8.2.1 – Registo de utilizadores

Deve ser efetuado um registo de utilizador formal, seja, verificação de níveis de

permissões, áreas de acesso sempre de acordo com as reais autorizações do

utilizador.

Periodicamente terão de ser verificadas e atualizadas as permissões de um utilizador

de forma a assegurar que os detalhes estão completos e se o utilizador ainda

necessita de acesso.

7.8.2.2 – Gestão de privilégios

Devem ser definidas diversas estratégias de controlo de acesso que iram ajudar

significativamente a assegurar a confidencialidade e integridade da informação:

a) Role-Based – Devem ser definidos Roles em que um utilizador se encaixa, podendo fazer parte de um ou vários Roles de acesso, ex.: enfermeiro, médico, auxiliar, etc…

b) Grupos de Acesso – definição de grupos de acesso a que os utilizadores podem pertencer, ex.: equipas médicas.

c) Acesso descritivo – Um utilizador com acesso legítimo aos dados (por exemplo, médico de família) pode fornecer acesso temporário a outro utilizador (por exemplo um especialista terapêutico).

7.8.2.3 – Gestão de passwords

A complexidade de uma password de acesso aos sistemas deve ser bem pensada,

caso seja um sistema de urgência essa complexidade poderá causar complicações,

neste caso devem ser pensados outros métodos de autenticação.

7.8.5.1 – Restrições de acesso a informação

Devemos assegurar que o paciente ao aceder à informação o faz de forma segura,

devidamente autenticado e em segurança.


89

7.8.6.1 – Computação Móvel

As organizações que processem dados de saúde devem:

a) Especificar os riscos que envolvem o acesso / processamento de dados de saúde em dispositivos móveis.

b) Preparar uma política de segurança a ser seguida quando é usado um dispositivo móvel para aceder à informação.

c) Obrigar os utilizadores de dispositivos móveis a seguir as políticas de segurança.

Sendo as redes moveis sem fios semelhantes às redes cabladas, tem diferenças

importantes e são conhecidos os seus pontos fracos e varias falhas de segurança, que

as torna menos ineficazes.

Em relação aos dispositivos moveis, muitas vezes não tem os dados salvaguardados

por backups, são mais suscetíveis a roubo ou extravio, e ainda são mais suscetíveis a

ataques de malware e derivados.

7.9.2.1 – Identificação única de pacientes

Os sistemas de informação de saúde devem:

Assegurar que um paciente é inequivocamente identificado no sistema.

Ser capaz de efetuar um merge (junção) de dois ou mais registos que tenham sido

criados não intencionalmente para a mesma situação com dados semelhantes ou

repetidos.


90

Anexo 2 - Reuniões de acompanhamento

Nesta secção estão listadas as reuniões (mais importantes) de acompanhamento

efetuadas com os orientadores da entidade de ensino (Luís Santos e João Cunha) e

reuniões na entidade ISA (António Damasceno e Ariadne Pacheco), está disponível

em anexo a descrição detalhada das reuniões efetuadas.

Data Participantes Local Temas debatidos

16-11-2011 Rafael Simões

Luis Santos

ISEC L0.1 Tema de Estágio / Tese


Luis Santos

ISEC

Gabinete

LS

Proposta Estágio / Tese

Análise de Livros e Normas de

Segurança de Saúde


Luis Santos

ISEC

Gabinete

LS

Gestão de documento no Moodle

Modelos de Segurança a estudar

Leis de proteção de Dados

Modelo OCTAVE

ISO 27001

Alunos de Licenciatura António

Simões e o Rui Martins

03-2012 Rafael Simões

Luis Santos

Ideias / tópicos da 27001 para Alunos

da Licenciatura


Luis Santos

António Simões

Rui Martins

ISEC A2.2 Sessão de Discussão ISO 27001

15-03-2012 Rui Martins

António Simões

Biblioteca

ISEC

Ativos de Informação para fase de

levantamento de ativos ISO 27001


Luis Santos

ISEC

Gabinete

LS

Preparação da reunião de

apresentação à ISA

18-04-2012 António

Damasceno

Ariadne Pacheco

Rafael Simões

Luis Santos

João Cunha

Gabinete

Reuniões

DEIS-ISEC

Apresentação e discussão das tarefas

de estágio

CNPD, ISO 27999 e ISO 27001

OneCare


Luis Santos

ISEC

Gabinete

LS

Requisitos Legislação e CNPD


Luis Santos

Reunião – Equipa Arquitetura

OneCare – ISA

Respostas da CNPD

22-05-2012 Rafael Simões Ursa Minor Definição dos requisitos de segurança


91

António

Damasceno

- ISA da arquitetura OneCare


Luis Santos

João Cunha

Gabinete

Reuniões

DEIS-ISEC

Legislação nacional e Requisitos

CNPD

Gantt (Open Project) de

Implementação ISO 27001


Luis Santos

João Cunha

Gabinete

Reuniões

DEIS-ISEC

Reuniões com o grupo de projeto (Rui

e António)



Âmbito de trabalho de estágio


António

Damasceno

Ursa Minor

- ISA

Reformulação das exigências da

CNPD


Luis Santos

João Cunha

Gabinete

Reuniões

DEIS-ISEC

Requisitos legais do OneCare

Road Map de implementação ISO

27001

Gestão Documental


Luis Santos

João Cunha

Gabinete

Reuniões

DEIS-ISEC

Relatório para entregar à CNPD –

Segurança OneCare


Luis Santos

ISEC

Gabinete

LS

A arquitetura do OneCare

Plano de implementação ISO 27001


António

Damasceno

Ursa Minor

- ISA

Documento de requisitos de

segurança


Luis Santos

João Cunha

ISEC

Gabinete

LS

Gap Analysis

SoA (Statement of Applicability)


27001




Luis Santos

João Cunha

Conf. Call.

Via Skype

Apreciação de Deliverables

Relatório Final


27001


Luis Santos

Conf. Call.

Via Skype

Apreciação de Deliverables

Relatório Final


Luis Santos

João Cunha

ISEC

Gabinete

LS

Relatório Final


Anexo 3 – Classificação / Manuseamento da

Informação

92 de 201

Rafael RS - 03-09-2012

Classificação / Manuseamento da Informação

Classificação Descrição Documentos / Registos Controlo Físico Reprodução Distribuição Destruição Pública Informação que pode ser

distribuída livremente e sem fronteiras, sem que cause qualquer dano para a empresa, funcionários ou interessados. O Departamento de segurança de informação ou equiparado devem aprovar o uso desta classificação em um documento. Estes documentos podem ser distribuídos a pessoas fora da organização.

Documentos de marketing para distribuição pública. Anúncios, resultado de contas anuais, páginas WEB públicas, vagas de emprego.

Nenhum Não Controlada. Sem Restrições Lixo comum ou reciclagem.

Interna Informação que a sua divulgação para fora da organização é inconveniente ou inapropriada. A divulgação externa á organização tem de ser aprovada pela direcção.

Memorandos departamentais, regras internas, procedimentos operacionais, investimentos, contractos, revistas internas, guidelines, listas de e-mail e telefone, relatórios de produtividade, relatórios disciplinares, SLA’s, Intranet WEB.

O autor é responsável pelo armazenamento e controlo documental.

Cópias limitadas poderão ser efectuadas por colaboradores ou subcontratados que tenham assinado um contrato de sigilo de informação.

Interna: deve circular num envelope. Externa: Usar um envelope selado. Electrónica: usar email interno, requer encriptação para circular externamente.

Papel: destruidor de papel. Dados electrónicos: Desmagnetização de dispositivos magnéticos. CD’s. DVD’s discos rígidos são enviados para o IT para destruição apropriada.

Confidencial Informação altamente sensível ou de grande valor para a organização. Apenas poderá ser divulgada fora da organização sobre ordem directa de um administrador de topo ou director geral.

Passwords, códigos PIN, chaves privadas, chaves de ligação VPN, números de cartões de crédito / débito, informação pessoal (registos RH, números de segurança social, etc…), outros dados extremamente sensíveis para a organização.

Origem: esta pessoa é responsável por assegurar que esta informação é distribuída apenas na medida do estritamente necessário. Recepção: esta pessoa tem de assegurar que esta informação é encriptada / guardada em sítio seguro quando não em uso.

Cópias limitadas poderão ser efectuadas com autorização directa do autor ou por uma pessoa por ele designada. Esta autorização deverá ser efectuada por escrito e assinada

Interna: Tem de circular num envelope fechado e deve ser entregue em mão. Externa: Usar um envelope “descaracterizado” e deve ser entregue em mão. Electrónica: usar apenas mail Interno, informação tem de ser encriptada antes de enviada.

Papel: usar um destruidor certificado que use corte em cruz. Dados electrónicos: Dispositivos magnéticos, CD’s. DVD’s e discos rígidos são enviados para o IT para destruição apropriada.

93 de 201


94

Anexo 4 – Listagem de riscos/ameaça

94 de 201

ID Tipo Risco0001 Dano físico Fogo

0002 Dano físico Água

0003 Dano físico Poluição

0004 Dano físico Acidente grave

0005 Dano físico Destruição de equipamento ou mídia

0006 Dano físico Poeira, corrosão, congelamento

0007 Eventos naturais Fenómeno climático

0008 Eventos naturais Fenómeno sismico

0009 Eventos naturais Fenómeno vulcânico

0010 Eventos naturais Fenómeno meteorológico

0011 Eventos naturais Inundação

0012 Paralização de serviços essenciais Falha do ar-condicionado ou do sistema de suprimento de água

0013 Paralização de serviços essenciais Interrupção do suprimento de energia

0014 Paralização de serviços essenciais Falha do equipamento de telecomunicações

0015 Distúrbio causado por radiações Radiação electromagnética

0016 Distúrbio causado por radiações Radiação térmica

0017 Distúrbio causado por radiações Pulsos electromagnéticos

0018 Comprometimento da informação Interceptação de sinais de interferência comprometedores

0019 Comprometimento da informação Espionagem à distância

0020 Comprometimento da informação Escuta não autorizada

0021 Comprometimento da informação Furto de mídia ou documentos

0022 Comprometimento da informação Furto de equipamentos

0023 Comprometimento da informação Recuperação de mídia reciclada ou descartada

0024 Comprometimento da informação Divulgação indevida

0025 Comprometimento da informação Dados de fontes não confiáveis

0026 Comprometimento da informação Alteração do hardware

0027 Comprometimento da informação Alteração do software

0028 Comprometimento da informação Determinação da localização

0029 Falhas técnicas Falha de equipamento

Médio Perda da integridadade/Indisponibilidade de outos ativos

Baixo Perda da confidencialidade

Médio Indisponibilidade/Invasão ao sistema/Perda de informação

Médio Perda de confidencialidade/Perda de vantagem competitiva

Médio Possivel perda de integridade

Médio Perda da integridade/Indisponibilidade de outros ativos

Médio Perda de vantagens competitivas/Informação em mão indesejadas/Possivel perda de confidencialidade

Médio Indisponibilidade

Baixo Possivel perda de confidencialidade/Acesso a informação critica/Perda de vantagem competitiva

Perda de informação/Possivel destruição

Alto Roubo de informação/Perda de vantagens competitivas/Possivel perda de confidencialidade/Invasão

Alto

Alto

Médio

Médio

Médio

Médio

Alto

Possivel dstruição/Indisponibilidade

Perda de informação/Possivel destruição

Roubo de informação/Perda de informação/Possivel perda de confidencialidade e integridade/Invasão

Roubo de informação/Perda de vantagens competitivas/Possivel perda de confidencialidade

Destruição/Indisponibilidade/Perda de Informação


Indisponibilidade/Danificação de equipamento/Possivel destruição/Perda de Informação

Indisponibilidade

Quebra nas comunicações externas e/ou internas/Indisponibilidade

Dimensão ConsequênciaDestruição/Indisponibilidade/Perda de Informação



Listagem de riscos/ameaças

Nome da Empresa: Local:

Versão: Estado:

Data: Responsável:

Alto

Alto

Médio

Alto

Alto

Baixo

Alto

Médio

Médio

Alto



Indisponibilidade/Danificação de equipamento/Destruição/Perda de Informação

Indisponibilidade/Danificação de equipamento/Possivel destruição/Perda de InformaçãoMédio

Alto Indisponibilidade/Danificação de equipamento/Destruição/Perda de Informação


95 de 201

0030 Falhas técnicas Defeito do equipamento

0031 Falhas técnicas Saturação do sistema de informação

0032 Falhas técnicas Defeito de software

0033 Falhas técnicas Violação das condições de uso do sistema de informação possibilitam a sua manutenção

0034 Ações não autorizadas Uso não autorizado do equipamento

0035 Ações não autorizadas Cópia ilegal de software

0036 Ações não autorizadas Uso de cópias de software falsificadas ou ilegais

0037 Ações não autorizadas Comprometimento dos dados

0038 Ações não autorizadas Processamento ilegal de dados

0039 Comprometimento de funções Erro durante o uso

0040 Comprometimento de funções Abuso de direitos

0041 Comprometimento de funções Forjamento de direitos

0042 Comprometimento de funções Repúdio de ações

0043 Comprometimento de funções Indisponibilidade de recursos humanos

Baixo Fraude/Sabotagem/Invasão

Médio Invasão/Indisponibilidade de serviços/Perdas financeiras

Baixo Possivel perda de informação, disponibilidade, integridade e confidencialidade

Baixo Invasão/Perda de confidencialidade

Baixo Fraude/Sabotagem/Invasão

Baixo Perdas financeiras por incuprimento da legislação/Fraude

Médio Fraude/Perda de integridade e confidencialidade

Baixo Perda de integridade/Fraude

Médio Perda de integridade/Possivel indisponibilidade futura

Médio Invasão/Sabotagem/Perda de confidencialidade/Fraude

Médio Perdas financeiras por incuprimento da legislação/Sabotagem/Fraude

Baixo Indisponibilidade/Invasão ao sistema

Médio Indisponibilidade/Sabotagem

Baixo Indisponibilidade/Possivel perda de confidencialidade e integridade/Perda de Informação

96 de 201


Anexo 5 – Listagem de vulnerabilidades + CVSS

97 de 201

Local:

Versão: Estado:

Responsável:

Inte

grid

ade

Disp

onib

ilida

de

Conf

iden

cial

idad

e

1 Buffer Errors Buffer overflow in Active Directory L Local B Baixa N Nenhuma C Completa C Completa C Completa 7,2 ND Não definida ND Não definida ND Não definida 7,2 A Alto A Alto A Alto A Alto A Alto 8,6 ALTO2 Authentication Issues LDAPS Authentication Bypass Vulnerability. L Local M Media U Uma P Parcial P Parcial N Nenhum 3 F Funcional CO Correção oficial NB Não corroborada 2,4 A Alto A Alto M Médio B Baixo M Médio 5,9 MEDIO3 Authentication Issues Active Directory Certificate Services Vulnerability L Local A Alta U Uma P Parcial P Parcial N Nenhum 2,4 ND Não definida CO Correção oficial NB Não corroborada 2 A Alto A Alto M Médio B Baixo M Médio 5,7 MEDIO4 Credentials Management The single sign-on implementation in Active Directory Federation Services (ADFS) does not properly remove credentials at the end of a network sessionL Local A Alta U Uma P Parcial P Parcial N Nenhum 2,4 ND Não definida CO Correção oficial NB Não corroborada 2 A Alto A Alto M Médio B Baixo M Médio 5,7 MEDIO

Dim

ensã

o fin

al d

a Vu

lner

abili

dade

Listagem de vulnerabilidades + CVSS

Temporais

Impa

cto

na d

ispo

nibi

lidad

e

Impa

cto

na in

tegr

idad

e

Poss

ibili

dade

de

Expl

oraç

ão

Rede

Com

plex

idad

e de

Ace

ssos

Aute

ntic

ação

Impa

cto

na c

onfid

enci

alid

ade

Esta

do d

e co

rreç

ão

Info

rmaç

ão so

bre

a vu

lner

abili

dade

Resu

ltado

Fin

al T

empo

rais

Dist

ribui

ção

dos a

lvos

Dano

s col

ater

ais

Ambiental

Resu

ltado

Fin

al A

mbi

enta

is

Requisitos

Nome da Empresa:

Data:

Vuln

erab

ilida

de

Tipo

ID

Identificação Grupo de Métricas

Resu

ltado

Fin

al B

ase

Base

98 de 201


96

Anexo 6 – Priorização do tratamento de risco

99 de 201


Versão: Estado:

Data: Responsável:

0001 Autenticação AD WS2008 0032 Defeito de software 0001 9 Baixo 1 Alto 3 27 Risco pouco perigoso Raro 2 54 Perdas insignificantes Médio Alto 7 126 Não aceitável Bastante Provável 5670

0001 Autenticação AD WS2008 0032 Defeito de software 0002 9 Baixo 1 Alto 3 27 Risco pouco perigoso Frequente 5 135 Perdas suportáveis Destrutivo 9 405 Não aceitável Improvável 3645

0001 Autenticação AD WS2008 0032 Defeito de software 0003 9 Baixo 1 Médio 2 18 Risco pouco perigoso Frequente 5 90 Perdas insignificantes Destrutivo 9 405 Não aceitável Normal 10935

0001 Autenticação AD WS2008 0032 Defeito de software 0004 9 Baixo 1 Alto 3 27 Risco pouco perigoso Regular 4 108 Perdas suportáveis Médio Alto 7 252 Não aceitável Pouco Provável 4536

0001 Autenticação AD WS2008 0031 Saturação do sistema de informação 0005 9 Médio 2 Alto 3 54 Risco perigoso Frequente 5 270 Perdas não suportáveis Médio Alto 7 315 Não aceitável Pouco Provável 5670

0008 ESET 0027 Alteração do software 0006 4 Médio 2 Alto 3 24 Risco pouco perigoso Regular 4 96 Perdas insignificantes Médio 6 96 Tratável Bastante Provável 1920

0008 ESET 0027 Alteração do software 0007 4 Médio 2 Médio 2 16 Risco pouco perigoso Regular 4 64 Perdas insignificantes Médio Alto 7 112 Não aceitável Bastante Provável 2240

0008 ESET 0032 Defeito de software 0008 4 Baixo 1 Alto 3 12 Risco pouco perigoso Raro 2 24 Perdas insignificantes Baixo 4 32 Aceitável Bastante Provável 640

0008 ESET 0027 Alteração do software 0009 4 Médio 2 Alto 3 24 Risco pouco perigoso Raro 2 48 Perdas insignificantes Médio 6 48 Aceitável Bastante Provável 960

0018 SW Core + Router 0029 Falha de equipamento 0010 8 Médio 2 Médio 2 32 Risco perigoso Raro 2 64 Perdas insignificantes Médio Baixo 5 80 Tratável Normal 1920

0018 SW Core + Router 0029 Falha de equipamento 0011 8 Médio 2 Alto 3 48 Risco perigoso Nunca acontece 1 48 Perdas insignificantes Não considerável 1 8 Aceitável Improvável 64

0018 SW Core + Router 0029 Falha de equipamento 0012 8 Médio 2 Alto 3 48 Risco perigoso Raro 2 96 Perdas insignificantes Alto 8 128 Não aceitável Improvável 1024

0018 SW Core + Router 0029 Falha de equipamento 0013 8 Médio 2 Alto 3 48 Risco perigoso Periódico 3 144 Perdas suportáveis Destrutivo 9 216 Não aceitável Improvável 1728

0018 SW Core + Router 0029 Falha de equipamento 0014 8 Médio 2 Médio 2 32 Risco perigoso Raro 2 64 Perdas insignificantes Destrutivo 9 144 Não aceitável Improvável 1152

0032 AP1 0029 Falha de equipamento 0015 7 Médio 2 Médio 2 28 Risco perigoso Raro 2 56 Perdas insignificantes Insignificante 2 28 Aceitável Improvável 196

0018 SW Core + Router 0029 Falha de equipamento 0016 7 Médio 2 Médio 2 28 Risco perigoso Raro 2 56 Perdas insignificantes Insignificante 2 28 Aceitável Improvável 196

0052 AP1 0029 Falha de equipamento 0017 7 Médio 2 Alto 3 42 Risco perigoso Raro 2 84 Perdas insignificantes Insignificante 2 28 Aceitável Improvável 196

0018 Datacenter Comunicaçõs 0026 Alteração do Hardware 0018 9 Médio 2 Médio 2 36 Risco perigoso Periódico 3 108 Perdas suportáveis Alto 8 216 Não aceitável Pouco Provável 3888

0018 Datacenter Comunicaçõs 0022 Furto de Equipamento 0019 9 Médio 2 Médio 2 36 Risco perigoso Frequente 5 180 Perdas suportáveis Destrutivo 9 405 Não aceitável Pouco Provável 7290

0018 Datacenter Comunicaçõs 0002 Agua 0020 9 Alto 3 Alto 3 81 Risco muito perigoso Raro 2 162 Perdas suportáveis Destrutivo 9 162 Não aceitável Pouco Provável 2916

0018 Datacenter Comunicaçõs 0001 Fogo 0021 9 Alto 3 Alto 3 81 Risco muito perigoso Raro 2 162 Perdas suportáveis Destrutivo 9 162 Não aceitável Pouco Provável 2916

Priorização do tratamento de risco

Incêndio reduzido, localizado num bastidor com dano parcial nos equipamentos contidos no mesmo

dot11t/t_if_dot11_hal_ath.c in Cisco IOS 12.3, 12.4, 15.0, and 15.1 allows remote attackers to cause a denial of service (assertion failure and reboot) via 802.11 wireless traffic, as demonstrated by a video call from Apple iOS 5.0 on an iPhone 4S, aka Bug ID CSCtt94391.

Access Point Web-browser Interface Vulnerability

Sabotagem de equipamento, com leve falha de disponibilidade no sistema. O objetivo será a recolha de informação importante sobre a rede e sistemas em operação.

Vandalização ou roubo do sistema de ar-condicionado. Não existe nenhum objetivo senão o de destruir, mas os prejuizos podem ser elevados

Filtro de sistema de ar condicionado relacionado com a refrigeração por àgua partido. Inundação de elevado grau e sistemas eletricos inativados automáticamente por prevenção

Prio

ridad

e de

trat

amen

to d

e ris

co

Prob

abili

dade

de

não

dete

cção

do

risc

o

Perc

epçã

o do

risc

o

Niv

el d

e ac

eita

ção

do ri

sco

Impa

cto

tota

l do

risco

Prob

abili

dade

de

acon

teci

men

to d

o ris

co

Dim

ensã

o do

risc

o

Dim

ensã

o da

vu

lner

abili

dade

Aval

iaçã

de

um a

tivo

Dim

ensã

o fin

al d

o ris

co

ID Ativo Ativo ID Risco RiscoID

Vulnerabilidade

Vulnerabilidade

The Personal Firewall driver (aka epfw.sys) 3.0.672.0 and earlier in ESET Smart Security 3.0.672 and earlier allows local users to gain privileges via a crafted IRP in a certain METHOD_NEITHER IOCTL request to \Device\Epfw that overwrites portions of memory.

The NAT implementation in Cisco IOS 12.1 through 12.4 and 15.0 through 15.1, and IOS XE 3.1.xSG, allows remote attackers to cause a denial of service (device reload or hang) via malformed NetMeeting Directory (aka Internet Locator Service or ILS) LDAP traffic, aka Bug ID CSCtd10712.

Cisco IOS 12.2, 12.3, 12.4, 15.0, and 15.1, when the data-link switching (DLSw) feature is configured, allows remote attackers to cause a denial of service (device crash) by sending a sequence of malformed packets and leveraging a "narrow timing window,"

The Neighbor Discovery (ND) protocol implementation in Cisco IOS on unspecified switches allows remote attackers to bypass the Router Advertisement Guarding functionality via a fragmented IPv6 packet in which the Router Advertisement (RA) message is contained in the second fragment, as demonstrated by (1) a packet in which the first fragment contains a long Destination Options extension header or (2) a packet in which the first fragment contains an ICMPv6 Echo Request message.

Cisco IOS 12.0, 15.0, and 15.1, when a Policy Feature Card 3C (PFC3C) is used, does not create a fragment entry during processing of an ICMPv6 ACL, which has unspecified impact and remote attack vectors, aka Bug ID CSCtj90091.

The ethernet-lldp component in Cisco IOS 12.2 before 12.2(33)SXJ1 does not properly support a large number of LLDP Management Address (MA) TLVs, which allows remote attackers to cause a denial of service (device crash) via crafted LLDPDUs, aka Bug ID CSCtj22354.

The SysInspector AntiStealth driver (esiasdrv.sys) 3.0.65535.0 in ESET System Analyzer Tool 1.1.1.0 allows local users to execute arbitrary code via a certain METHOD_NEITHER IOCTL request to \Device\esiasdrv that overwrites a pointer.

Cisco IOS 12.2 through 12.4 and 15.0 does not recognize the vrf-also keyword during enforcement of access-class commands, which allows remote attackers to establish TELNET connections from arbitrary source IP addresses via a standard TELNET client, aka Bug ID CSCsi77774.

Buffer overflow in Active Directory

LDAPS Authentication Bypass Vulnerability.

Active Directory Certificate Services Vulnerability

The single sign-on implementation in Active Directory Federation Services (ADFS) does not properly remove credentials at the end of a network session

Stack consumption vulnerability in the LDAP service allows remote attackers to cause a denial of service (system hang)

NOD32 Antivirus Long Path Name Stack Overflow Vulnerabilities

Multiple interpretation error in unspecified versions of NOD32 Antivirus allows remote attackers to bypass virus detection via a malicious executable in a specially crafted RAR file with malformed central and local headers, which can still be opened by products such as Winrar and PowerZip, even though they are rejected as corrupted by Winzip and BitZipper.

100 de 201


Anexo 7 - RTP Risk Treatment plan(DO)

101 de 201

Início Final

1Autenticação AD WS2008

Responsável por todas as autenticações efectuadas do dominio da ASI

Buffer overflow in Active Directory 5670

Transferir (Fabricante)

Acções Propostas: Activar e executar os updates de sistema via Windows Update ou WSUS, já existe uma correção para a falha.Requisitos:Microsoft Windows UpDate

100% 0

http://technet.microsoft.com/en-us/security/bulletin/ms11-019

Não é possivel à ASI laborar normal e eficazmente sem este serviço / activo em funcionamento.

Perdas críticasAceitar, não tem qualquer custo tangivel, apenas benefícios

José Endividuo 12-7-12 30-7-12

LDAPS Authentication Bypass Vulnerability 3645



100% 0 http://technet.microsoft.com/pt-pt/security/bulletin/ms11-086



José Simões 12-7-12 30-7-12

Active Directory Certificate Services Vulnerability 10935



100% 0 http://technet.microsoft.com/en-us/security/bulletin/ms11-051



José Martins 12-7-12 30-7-12

(ADFS) does not properly remove credentials at the end of a network session

4536Transferir

(Fabricante)


100% 0 http://technet.microsoft.com/en-us/security/bulletin/MS09-070



José Endividuo 12-7-12 30-7-12

1. Aceitar um Risco – por outras palavras a administração aceita o risco, comparando o impacto que este pode trazer com o investimento necessário para providenciar controlos necessários à sua mitigação.2. Reduzir – aplicar um controlo ou um conjunto de controlos que visam mitigar o risco para um nível aceitável.3. Evitar o risco – não executar os processos de negócio que estão associados a determinado risco.4. Transferir – transferir o risco para outra organização, por exemplo, criar um contrato de seguro sobre o risco, ou criar contractos de entendimento com outros parceiros de negócio.

Impacto do RiscoPerdas Insignificantes

Perdas SuportveisPerdas Não Suportaveis

Perdas Insuportaveis

Opções para o tratamento do Risco

Custo/Benefício - Aceitar ou Rejeitar o tratamento?

Impacto do RiscoDead Line

Risk Treatment PlanJustificação para a Acção

Nivel de Mitigação

Informação DetalhadaNo Nome do Activo Descrição do Activo ResponsávelPlano de AcçãoAcçãoRisk ValueAmeaça Risco Residual

102 de 201


98

Anexo 8 - Gap-Analysis- Controls

103 de 201

Listagem de Todos os Controlos da Norma ISO 27001Nem Todos Serão de implementação obrigatória, caso o controlo não se aplique a um departamento, ou a todos, o respectivo quadrado deve ser preenchido a branco

ID Nome do Controlo Pergunta D1 D2 D3 D4 Data limite Estado

5

5.1

5.1.1 Política de segurança da informação

A.5.1.1 É um documento aprovado pela Administração, publicado e comunicado a todos os funcionários e partes externas relevantes? NI NI NI NI Não

Implementado

5.1.2 Revisão da política de segurança da informação

A.5.1.2 A política publicada é revista em intervalos planeados ou quando ocorreram mudanças significativas para garantir a sua eficácia e adequação contínua? NI NI NI NI Não

Implementado

6

6.1

6.1.1 Compromisso de administração para a segurança da informação

A.6.1.1 Existe um comprometimento escrito que a Administração deve apoiar activamente a segurança dentro da organização através de uma direção clara e do reconhecimento das suas responsabilidades de segurança da informação? NI NI NI NI Não

Implementado

6.1.2 Coordenação de segurança da informação

A.6.1.2 São as atividades de segurança da informação coordenadas por representantes de diferentes partes da organização com papéis relevantes e funções de chefia? NI NI NI NI Não

Implementado

6.1.3 Atribuição de responsabilidades de segurança da informação A.6.1.3 Todas as responsabilidades de segurança da informação estão claramente definidos? NI NI NI NI Não

Implementado

6.1.4Processo de autorização para instalações de processamento de informação

A.6.1.4 Existe um processo de autorização definido para instalações de processamento de informação? PI PI PI PI Parcialmente implementado

6.1.5 Acordos de confidencialidade A.6.1.5 Estão identificados e analisados periodicamente os requisitos de confidencialidade ou não-divulgação de acordos, que reflictam as necessidades da organização para a protecção das informações ? PI PI PI PI Parcialmente

implementado

6.1.6 Contatos com autoridades A.6.1.6 Está a sua organização a manter os contactos adequados com as autoridades competentes? I I I I Implementado

6.1.7 O contato com grupos de interesses especiais A.6.1.6 Está a sua organização a manter os contactos adequados com as autoridades competentes? I I I I Implementado

6.1.8 Análise crítica independente de segurança da informação

A.6.1.8 A organização aborda a gestão da segurança da informação e as suas implicações (objetivos de controlo, controlos, políticas, processos e procedimentos de segurança da informação) , revendo-as de forma independente em intervalos planeados ou quando mudanças significativas ocorrem?

NI NI NI NI Não Implementado

A política de segurança

Política de segurança da informação

Organização da segurança da informação

Organização Interna

104 de 201

6.2

6.2.1 Identificação dos riscos relacionados com partes externas

A.6.2.1 Os riscos para a informação da organização e instalações de processamento de informações dos processos de negócios críticos que envolvam partes externas, foram identificados e implementados controlos apropriados antes de conceder acesso?

PI PI PI PI Parcialmente implementado

6.2.2 Gerindo a segurança ao lidar com clientes

A.6.2.2 Todos os requisitos de segurança identificados como necessários foram abordados antes de dar aos clientes acesso aos bens e informações da organização? PI PI PI PI Parcialmente

implementado

6.2.3 Segurança da informação em contratos de terceiros

A.6.2.3 Os acordos com terceiros envolvendo acesso, processamento, comunicação ou gestão de informação da organização,instalações de processamento de informação,a adição de produtos ou serviços para instalações de processamento de informação cobrem todos os requisitos de segurança relevantes?


7

7.1

7.1.1 Inventário de Ativos A.7.1.1 Estão todos os ativos claramente identificados e um inventário de todos os ativos importantes elaborado e armazenado? PI PI PI PI Parcialmente implementado

7.1.2 Propriedade de ativos A.7.1.2 Estão todas as informações e ativos associados a instalações de processamento de informação, sendo estas propriedade de uma determinada parte da organização? PI PI PI PI Parcialmente

implementado

7.1.3 Uso aceitável de recursos A.7.1.3 A organização possui regras para o uso aceitável de ativos associados às instalações de processamento de informação? PI PI PI PI Parcialmente

implementado

7.2

7.2.1 Diretrizes de classificação A.7.2.1 Tem informação classificada em termos de valor, requisitos legais, sensibilidade e criticidade para a organização? PI PI PI PI Parcialmente implementado

7.2.2 Manuseio e rotulagem de informações

A.7.2.2 Tem um conjunto apropriado de procedimentos de etiquetagem desenvolvido e implementado de acordo com o esquema de classificação adotado pela organização? PI PI PI PI Parcialmente

implementado

8

8.1

8.1.1 Papeis e responsabilidades A.8.1.1 Foram definidas e documentadas as responsabilidades e funções de segurança dos funcionários, contratados e terceiros de acordo com a política de segurança da informação da organização? NI NI NI NI Não

Implementado

8.1.2 TriagemA.8.1.2 Foram verificações realizadas sobre todos os candidatos para o emprego, os contratantes e utilizadores de terceiros, em conformidade com leis, regulamentos, ética e proporcional aos requisitos de negócios,classificação da informação a ser acedida e os riscos percebidos?


Gestão de Ativos

Partes externas

A responsabilidade por Ativos

Classificação da informação

Recursos Humanos Segurança

Antes de empregar

105 de 201

8.1.3 Termos e condições de empregoA.8.1.3 Como parte da obrigação contratual, ter todos os funcionários, contratados e terceiros concordaram e assinaram os termos e condições do seu contrato de trabalho, que afirmam a sua e as responsabilidades da organização para a segurança da informação?


8.2

8.2.1 Responsabilidades de gestão A.8.2.1 Existe um processo de gestão que assegura que funcionários, contratados e terceiros executam as suas funções em conformidade com as políticas estabelecidas e procedimentos da organização? PI PI PI PI Parcialmente

implementado

8.2.2 Conscientização de segurança da informação, educação e formação

A.8.2.2 Será que todos os funcionários da organização e eventualmente, fornecedores e terceiros receberam formação de conscientização apropriada e atualizações regulares nas políticas e procedimentos organizacionais, como procedimento relevante para a sua função?


8.2.3 Processo disciplinar A.8.2.3 Existe um processo disciplinar formal para empregados que tenham cometido uma violação de segurança? NI NI NI NI Não Implementado

8.3

8.3.1 Responsabilidades de termino de contrato

A.8.3.1 As responsabilidades para a realização de cessação do emprego ou mudança de emprego estão claramente definidas e documentadas? NI NI NI NI Não

Implementado

8.3.2 Retorno dos ativos A.8.3.2 Existe um processo para assegurar que todos os funcionários, fornecedores e terceiros têm de retornar todos os ativos da organização em seu poder ao término de seu contrato de trabalho, ou acordo? PI PI PI PI Parcialmente

implementado

8.3.3 Remoção dos direitos de acessoA.8.3.3 Existe um processo que assegura os direitos de acesso de todos os funcionários, fornecedores e de terceiros às informações e instalações de processamento de informação foram removidos ao término de seu contrato de trabalho, ou acordo ? Ou ajustado em caso de mudança?


9

9.1

9.1.1 Perímetro de segurança física A.9.1.1 Existem perímetros de segurança (barreiras tais como paredes, portões de entrada controlados por cartão ou recepções) para proteger as áreas que contenham informações e instalações de processamento de informação? I I I I Implementado

9.1.2 Controlos de entradas físicas A.9.1.2 Estão as áreas críticas protegidas por controlos de entrada apropriados para assegurar que somente pessoal autorizado têm acesso? I I Implementado

9.1.3 Proteger escritórios, salas e instalações A.9.1.3 Medidas de segurança física para escritórios, salas e instalações foram concebidas e aplicadas? I NI NI NI Parcialmente

implementado

9.1.4 Proteção contra ataques externos e ambientais

A.9.1.4 Proteção física contra danos causados por incêndio, inundação, terremoto, explosão, distúrbios civis, e outras formas de desastres naturais ou provocados pelo homem foi concebido e aplicado? PI PI PI PI Parcialmente

implementado

9.1.5 Trabalhar em áreas seguras A.9.1.5 Proteção física e diretrizes para trabalhar em áreas seguras foram concebidos e aplicados? I I Implementado

Segurança Física e Ambiental

Áreas seguras

Durante o emprego

Encerramento ou mudança de emprego

106 de 201

9.1.6 Áreas de acesso público de entrega e carregamento

A.9.1.6 Foram criados pontos de acesso, tais como áreas de carga e outros pontos onde as pessoas não autorizadas podem entrar no local controlado para evitar acesso não autorizado? NI NI Não

Implementado

9.2

9.2.1 Implantação de equipamentos para proteção

A.9.2.1 Estão instalados equipamentos para reduzir os riscos de ameaças e perigos ambientais e as oportunidades de acesso não autorizado? PI PI PI PI Parcialmente

implementado

9.2.2 Utilitários de apoio A.9.2.2 O equipamento está protegido contra falhas de energia e outras interrupções causadas por falhas no apoio aos serviços públicos? I Implementado

9.2.3 Segurança na cablagem A.9.2.3 Estão energia e cabos de telcomunicações, que transportam dados ou serviços de apoio de informação, protegidos contra interceptação ou danos? NI NI NI NI Não

Implementado

9.2.4 Manutenção de equipamentos A.9.2.4 O equipamento é corretamente mantido para garantir a sua contínua disponibilidade e integridade? PI PI Parcialmente implementado

9.2.5 Segurança de equipamentos fora das instalações

A.9.2.5 A segurança fora dos locais com equipamentos e os riscos de trabalhar fora das instalações da organização foram tidos em conta? PI PI PI PI Parcialmente

implementado

9.2.6 Segurança para descarte ou reutilização de equipamentos

A.9.2.6 Existe um procedimento para garantir que todos os itens de equipamento contendo mídia de armazenamento foram verificados para que quaisquer dados sensíveis e software licenciado foi removido ou substituído de forma segura antes da sua eliminação?


9.2.7 Remoção de propriedade A.9.2.7 Existe um processo para garantir que as informações, equipamentos ou software não devem ser retirados do local sem autorização prévia? NI NI NI NI Não

Implementado

10

10.1

10.1.1 Procedimentos operacionais documentados

A.10.1.1 Existem procedimentos operacionais documentados, mantidos e disponibilizados a todos os utilizadores que precisam deles? I I I I Implementado

10.1.2 Gestão da mudança A.10.1.2 São controladas mudanças nas instalações de processamento de informação e sistemas? PI PI PI PI Parcialmente implementado

10.1.3 Segregação de funções A.10.1.3 São os deveres e áreas de responsabilidade segregadas na organização, para reduzir as oportunidades de modificação não autorizada, não intencional ou uso indevido dos bens da organização? PI PI PI PI Parcialmente

implementado

10.1.4Separação de instalações de teste, desenvolvimento e operações

A.10.1.4 São o desenvolvimento, teste e instalações operacionais separados para reduzir os riscos de acesso não autorizado ou alterações nos sistemas operacional e de desenvolvimento? I I Implementado

10.2

Comunicação e Gestão de Operações

Procedimentos operacionais e responsabilidades

Gestão de terceiros em prestação de serviços

Segurança de equipamentos

107 de 201

10.2.1 Prestação de serviços A.10.2.1 Existe um processo que garanta que os controlos de segurança, definições de serviço e os níveis de entrega incluídos nos acordo de fornecimento de serviços de terceiros sejam implementados, operados e mantidos por terceiros? I I I Implementado

10.2.2 Monitorização e avaliação de serviços de terceiros

A.10.2.2 Os serviços, relatórios e registos fornecidos por terceiros, são regularmente monitorizados e revistos em auditorias realizadas regularmente? PI PI PI Parcialmente

implementado

10.2.3 Gestão de mudanças para serviços de terceiros

A.10.2.3 As mudanças realizadas na prestação de serviços, incluindo a manutenção e melhoria das políticas de segurança da informação, procedimentos e controlos existentes, têm em conta a criticidade dos sistemas e processos de negócio e na re-avaliação de riscos?

NI NI Não Implementado

10.3

10.3.1 A gestão de capacidade para novos sistemas

A.10.3.1 Existe um processo que garanta que o uso de recursos são monitorizados, atento, e as projeções feitas de requisitos de capacidade futura para garantir o desempenho do sistema requerido? I NI Parcialmente

implementado

10.3.2 Aceitação do sistema A.10.3.2 Possui critérios de aceitação para novos sistemas de informação, atualizações e novas versões e testes adequados do sistema (s) realizado(s) durante o desenvolvimento e antes da aceitação? I I Implementado

10.4

10.4.1 Controlos contra códigos maliciosos

A.10.4.1 Existem controlos de detecção, prevenção e recuperação para proteger contra códigos maliciosos e procedimentos apropriados de conscientização de utilizadores? NI NI NI NI Não

Implementado

10.4.2 Controlos contra códigos móveis A.10.4.2 Quando o uso de código móvel está autorizado,é garantido que o código móvel autorizado opera de acordo com uma política de segurança claramente definida e que código móvel não autorizado é impedido de executar? NI NI NI NI Não

Implementado

10.5

10.5.1 Informações back-up A.10.5.1 Existe um processo para assegurar que cópias de segurança de informação e software são executadas e testadas regularmente de acordo com a política de backup? I I Implementado

10.6

10.6.1 Controlos de rede A.10.6.1 As redes são adequadamente geridas e controladas, a fim de serem protegidas contra ameaças e para manter a segurança para os sistemas e aplicativos que utilizam a rede, incluindo informações em trânsito? PI PI PI PI Parcialmente

implementado

10.6.2 Segurança da rede de serviços A.10.6.2 Recursos de segurança, níveis de serviço e requisitos de gestão de todos os serviços de rede foram identificados e incluídos em acordos de serviços de rede, desvalorizando se estes são realizados in-house ou terceirizado? NI NI NI NI Não

Implementado

10.7

10.7.1 Manuseamento de midias removíveis A.10.7.1 Existem procedimentos para o manuseamento de midias removíveis? NI NI NI NI Não

Implementado

Gestão da segurança de rede

Back-up

Planeamento e aceitação dos sistemas

Proteção contra códigos maliciosos e móveis

Manuseamento de mídia

108 de 201

10.7.2 Descarte de midias A.10.7.2 A mídia é eliminada de forma segura e protegida quando não for mais necessária, utilizando procedimentos formais? NI NI PI NI Parcialmente implementado

10.7.3 Manipulação de processos de informação

A.10.7.3 Existem procedimentos estabelecidos para o manuseio e armazenamento de informações para proteger estas informações contra divulgação não autorizada ou mau uso? PI PI NI NI Parcialmente

implementado

10.7.4 Segurança da documentação dos sistemas A.10.7.4 Está documentação do sistema protegida contra o acesso não autorizado? I I I I Implementado

10.8

10.8.1 Políticas de câmbio e procedimentos sobre informações

A.10.8.1 Existem políticas de câmbio formais, procedimentos e controlos existentes para proteger o intercâmbio de informações através da utilização de todos os tipos de meios de comunicação? NI NI NI NI Não

Implementado

10.8.2 Acordos de intercâmbio A.10.8.2 Foram estabelecidos acordos para o intercâmbio de informações ou software entre a organização e as partes externas? NI PI Não

Implementado

10.8.3 Mídias em trânsito A.10.8.3 A mídia contendo informações está protegida contra o acesso não autorizado, uso indevido ou corrupção durante o transporte para além dos limites físicos da organização? NI NI Não

Implementado

10.8.4 Mensagens eletrónicas A.10.8.4 A informação envolvida em mensagens eletrónicas está devidamente protegidos? NI NI NI NI Não Implementado

10.8.5 Sistemas de informação empresariais

A.10.8.5 As políticas e procedimentos foram desenvolvidos e implementados para proteger a informação, associada com a interligação de sistemas de informação e os negócio da organização? NI NI NI NI Não

Implementado

10.9

10.9.1 O comércio eletrónico A.10.9.1 A informação envolvida no comércio electrónico através de redes públicas está protegida de atividades fraudulentas, disputa contratual e divulgação não autorizada ou modificação? PI PI PI PI Parcialmente

implementado

10.9.2 Transações on-lineA.10.9.2 A informação envolvida em transações on-line está protegida para evitar a transmissão incompleta, mau encaminhamento, alteração não autorizada da mensagem , a divulgação não autorizada, ou duplicação não autorizada da mensagem?

Não Implementado

10.9.3 Informações publicas disponíveis A.10.9.3 É a integridade da informação a ser disponibilizada em um sistema público, protegida para impedir a modificação não autorizada? PI PI PI PI Parcialmente

implementado

10.10

10.10.1 O log de auditoriaA.10.10.1 A organização produz registos de auditoria das atividades de utilizador, exceções e eventos de segurança da informação e mantem-os por um período acordado de tempo, para auxiliar em futuras investigações e monitorização de controlo de acesso?

I I I I Implementado

10.10.2 Monitorizar o uso do sistema A.10.10.2 Foram estabelecidos procedimentos para a fiscalização da utilização das instalações de processamento de informação e são revistos os resultados das actividades de monitorização regularmente? PI PI PI PI Parcialmente

implementado

Monitorização

Troca de informações

E-commerce

109 de 201

10.10.3 Proteção de informações de log A.10.10.3 As informações e sistemas de log protegidos estão protegidos contra falsificação e acesso não autorizado? I I I I Implementado

10.10.4 Registos de administrador e operador

A.10.10.4 Existe um processo para garantir que o administrador do sistema e as atividades de operação do sistema são registadas? I I I I Implementado

10.10.5 Registo de falhas A.10.10.5 Existe um processo que garanta que as falhas são registadas, analisadas e tomadas as medidas adequadas? PI PI PI PI Parcialmente implementado

10.10.6 Sincronização do relógio A.10.10.6 Estão os relógios de todos os sistemas de informação relevantes de processamento de informação, dentro da organização ou domínio de segurança, sincronizados com uma fonte de tempo precisa? I I I I Implementado

11

11.1

11.1.1 Acesse política de controlo A.11.1.1 Existe uma política de controlo de acesso estabelecida, documentada e revista com base nos negócios e requisitos de segurança para o acesso? NI NI NI NI Não

Implementado

11.2

11.2.1 Registo do utilizador A.11.2.1 Existe um registo formal de utilizador em vigor para a concessão e revogação de acesso a todos os sistemas de informação e serviços? PI PI PI PI Parcialmente

implementado

11.2.2 Gestão de privilégios A.11.2.2 São controlados, a alocação e o uso de privilégios? NI NI NI NI Não Implementado

11.2.3 Gestão de senhas do utilizador A.11.2.3 É controlada a atribuição de senhas através de um processo formal? NI NI NI NI Não Implementado

11.2.4 Revisão dos direitos de acesso do utilizador

A.11.2.4 Existe um processo formal que permite a gestão e revisão dos direitos de acesso dos utilizadors para intervalos regulares e limitados? NI NI NI NI Não

Implementado

11.3

11.3.1 O uso de senha A.11.3.1 Existe um processo que garante que os utilizadors seguem boas práticas de segurança na seleção e uso de senhas? I I I I Implementado

11.3.2 Equipamento do utilizador autónoma

A.11.3.2 Existe um processo que garante que os utilizadors estão cientes de que o equipamento autónomo tem a proteção adequada?

11.3.3 Politica de ecrã e mesa limpa A.11.3.3 Foi adotada uma política de mesa limpa de papéis e mídias de armazenamento removíveis e uma política clara para a tela de instalações de processamento de informações? NI NI NI NI Não

Implementado

Gestão de acesso do utilizador

Controlo de acesso

Requisitos de negócio para controlo de acesso

Responsabilidades dos utilizadors

110 de 201

11.4

11.4.1 Política sobre uso de serviços de rede

A.11.4.1 Existe um processo para garantir que os utilizadors só podem ser fornecidos com acesso aos serviços que eles foram especificamente autorizados a usar? NI NI NI NI Não

Implementado

11.4.2 A autenticação do utilizador para conexões externas

A.11.4.2 Existe um processo para garantir que métodos de autenticação adequados serão utilizados para controlar o acesso por utilizadors remotos? NI NI NI NI Não

Implementado

11.4.3 Identificação do equipamento em redes

A.11.4.3 Existe um processo para apoiar a identificação automática do equipamento que é considerado um meio para autenticar conexões de locais e equipamentos específicos? PI PI PI PI Parcialmente

implementado

11.4.4 Proteção da porta de diagnóstico remoto ea configuração A.11.4.4 O acesso físico e lógico a portas de diagnóstico e configuração são controlados? NI NI NI NI Não

Implementado

11.4.5 Segregação de redes A.11.4.5 Os grupos de serviços de informação, utilizadores e sistemas de informação são segregadas nas redes? PI PI PI PI Parcialmente implementado

11.4.6 Controlo de conexão de redeA.11.4.6 A capacidade de os utilizadores se conectem à rede restringida de redes compartilhadas, especialmente aquelas estendendo além das fronteiras da organização, em consonância com a política de controlo de acesso e requisitos das aplicações de negócio?


11.4.7 Controlo do encaminhamento de rede

A.11.4.7 Etão implementados controlos sobre o encaminhamento nas redes, para garantir que as conexões de computador e fluxos de informação não violem a política de controlo de acesso? PI PI PI PI Parcialmente

implementado

11.5

11.5.1 Procedimentos de Log-On Seguros A.11.5.1 O acesso aos sistemas operativos são controlados por um procedimento seguro de log-on? I I I I Implementado

11.5.2 Identificação e autenticação de utilizadores

A.11.5.2 Todos os utilizadores têm um identificador único (ID de utilizador para seu uso pessoal, e tem uma técnica de autenticação adequada escolhida para provar a identidade alegada do utilizador? I I I I Implementado

11.5.3 Sistema de gestão de senhas A.11.5.3 Sistemas para gestão de senhas interativos que permitem garantir senhas de qualidade? NI NI NI NI Não Implementado

11.5.4 Uso de utilitários do sistema A.11.5.4 Os programas capazes de alterar os controlos são restritos e devidamente controlados? I I I I Implementado

11.5.5 Tempo limite da sessão A.11.5.5 as sessões são inactivadas após um período definido de tempo? I I I I Implementado

11.5.6 Limitação de tempo de conexão A.11.5.6 Existem restrições quanto ao tempo de conexão utilizadas para fornecer segurança adicional a aplicações de alto risco? I I I I Implementado

11.6 Controlo de acesso a informação e aplicações

Controlo de acesso de rede

Controlo de acesso a sistemas operativos

111 de 201

11.6.1 Restrição de acesso à informação A.11.6.1 O acesso à informação e determinadas funções de aplicativos são restritos a determinados utilizadores e pessoas, em conformidade com a política definida de Controlo de acesso? I I I I Implementado

11.6.2 Isolamento dos sistemas sensíveis A.11.6.2 sistemas sensíveis têm um ambiente computacional dedicado (isolado)? I I I I Implementado

11.7

11.7.1 Computação móvel e comunicações

A.11.7.1 Existe uma política formal e estão adotadas medidas de segurança apropriadas para proteger contra os riscos da computação móvel e meios comunicação? PI PI PI PI Parcialmente

implementado

11.7.2 O teletrabalho A.11.7.2 Existem políticas, planos e procedimentos operacionais desenvolvidos e implementados para atividades de teletrabalho? NI NI NI NI Não

Implementado

12

12.1

12.1.1 Análise de segurança, requisitos e especificações NI NI NI NI Não

Implementado

12.2

12.2.1 Validação de dados de entrada A.12.2.1 Os dados de entrada para as aplicações são devidamente validados para garantir que estão corretos e apropriados? PI PI PI PI Parcialmente implementado

12.2.2 Controlo do processamento interno

A.12.2.2 Existem verificações de validação nas aplicações para detectar qualquer adulteração de informação através de erros de processamento ou atos deliberados? PI PI PI PI Parcialmente

implementado

12.2.3 Integridade da mensagem A.12.2.3 Os requisitos para garantir a autenticidade e proteger a integridade das mensagens foram identificados, e os controlos apropriados identificados e implementados? NI NI NI NI Não

Implementado

12.2.4 Validação de dados de saída A.12.2.4 Os dados de saída das aplicações são validados para garantir que o processamento da informação armazenada está correto e apropriado às circunstâncias? NI NI NI NI Não

Implementado

12.3

12.3.1 Política para o uso de controlos criptográficos A.12.3.1 foi desenvolvida e implementada uma política sobre o uso de Controlos criptográficos para proteção da informação? NI NI NI NI Não

Implementado

12.3.2 Gestão de chaves A.12.3.2 Existe um processo de gestão de chaves na organização para apoiar o uso de técnicas de criptografia? NI NI NI NI Não Implementado

Computação móvel e trabalho remoto

Processamento correto nas aplicações

Controlos criptográficos

Aquisição, desenvolvimento e manutenção de sistemas de informação

Requisitos de segurança dos sistemas de informação

112 de 201

12.4

12.4.1 Controlo de software em produção A.12.4.1 Existem procedimentos para controlar a instalação de software em sistemas operativos? I I I I Implementado

12.4.2 Protecção de dados de teste do sistema A.12.4.2 Os dados de teste são cuidadosamente selecionados, protegidos e controlados? I I I I Implementado

12.4.3 O controlo de acesso ao código fonte do programa A.12.4.3 O acesso ao código fonte dos programas é restrito? I I Implementado

12.5

12.5.1 Alterar os procedimentos de controlo A.12.5.1 a implementação de mudanças é controladas pelo uso de procedimentos formais de Controlo de mudança? I I NI I Parcialmente

implementado

12.5.2Revisão técnica das aplicações após mudanças no sistema operativo

A.12.5.2 Quando os sistemas operativos são alterados, as aplicações críticas de negócios revistos e testados para garantir que não haja impacto negativo nas operações organizacionais ou de segurança? PI PI PI PI Parcialmente

implementado

12.5.3 Restrições sobre mudanças em pacotes de software

A.12.5.3 as modificações em pacotes de software é desencorajada, limitado às mudanças necessárias, e todas as alterações devem ser estritamente controladas? PI PI PI PI Parcialmente

implementado

12.5.4 Fuga de informação A.12.5.4 As oportunidades de fuga de informação são prevenidas? NI NI NI NI Não Implementado

12.5.5 Desenvolvimento externo de software A.12.5.5 O desenvolvimento de software efectuado por terceiros é supervisionado e controlado pela organização? PI PI PI PI Parcialmente

implementado

12.6

12.6.1 Controlo de vulnerabilidades técnicas

A.12.6.1 É obtida informação oportuna sobre vulnerabilidades técnicas dos sistemas de informação , a exposição da organização a tais vulnerabilidades é avaliada e são tomadas medidas apropriadas para enfrentar o risco associado? PI PI PI PI Parcialmente

implementado

13

13.1

13.1.1 Relatar eventos de segurança da informação

A.13.1.1 Os eventos de segurança da informação são notificados através de canais de gestão adequados o mais rápido possível? PI PI PI PI Parcialmente

implementado

13.1.2 Reporte de falhas A.13.1.2 Existe um processo que garante a todos os funcionários, contratados e terceiros de sistemas de informação e serviços de observar e relatar quaisquer falhas de segurança observadas ou suspeitas de sistemas ou serviços? NI NI NI NI Não

Implementado

Segurança nos processos de desenvolvimento e apoio

Gestão de vulnerabilidades técnicas

Informações de gestão de incidentes de segurança

Relatar eventos de segurança da informação e fraquesas detectadas

Segurança dos ficheiros do sistema

113 de 201

13.2

13.2.1 Responsabilidades e procedimentos

A.13.2.1 As responsabilidades de gestão e procedimentos foram estabelecidas para garantir uma resposta rápida, efetiva e ordenada aos incidentes de segurança da informação? NI NI NI NI Não

Implementado

13.2.2 Aprendendo com os incidentes de segurança da informação

A.13.2.2 Existem mecanismos para permitir que tipos, volumes e custos dos incidentes de segurança da informação serem quantificados e monitorizados? NI NI NI NI Não

Implementado

13.2.3 Recolha de provasA.13.2.3 Quando uma ação de acompanhamento contra uma pessoa ou organização, após um incidente de segurança da informação envolve uma ação legal (civil ou criminal), há um processo que garante que as provas são coletadas, mantidas, e apresentadas em conformidade com as regras de prova previsto na jurisdição pertinente?


14

14.1

14.1.1

Incluindo segurança da informação no processo de gestão de continuidade de negócios

A.14.1.1 Foram desenvolvidos e mantidos procesos para continuidade dos negócios em toda a organização, que tratem dos requisitos de segurança da informação necessários para a continuidade de negócios da organização? I I I I Implementado

14.1.2 A continuidade dos negócios e avaliação de riscos

A.14.1.2 Existe um processo que garante que os eventos que podem causar interrupções aos processos de negócio, podem ser identificados juntamente com a probabilidade,o impacto e consequências de tais interrupções? NI NI NI NI Não

Implementado

14.1.3Desenvolver e implementar planos de continuidade, incluindo segurança da informação

A.14.1.3 Foram desenvolvidos e implementados planos para manter ou restaurar as operações e garantir a disponibilidade das informações no nível necessário e nas escalas de tempo necessário após a interrupção, ou falha de processos críticos de negócio?


14.1.4 Negócios estrutura de planeamento de continuidade

A.14.1.4 Existe um quadro único de planos de continuidade de negócio para garantir todos os planos são consistentes, de forma a atender aos requisitos de segurança da informação e identificar prioridades para testes e manutenção? PI PI PI PI Parcialmente

implementado

14.1.5Teste de manutenção e reavaliação dos planos de continuidade de negócios

A.14.1.5 Os planos de continuidade de negócio são testados e atualizados regularmente para assegurar que eles estejam atualizados e eficazes? PI PI PI PI Parcialmente

implementado

15

15.1

15.1.1 Identificação da legislação aplicável

A.15.1.1 Todas as disposições legais vigentes, requisitos regulamentares e contratuais e abordagem da organização para atender a esses requisitos são explicitamente definidos, documentados, mantidos e atualizados para cada sistema de informação da organização?


15.1.2 Direitos de Propriedade Intelectual (DPI)

A.15.1.2 Foram implementados os procedimentos adequados para garantir a conformidade com requisitos legislativos, regulamentares e contratuais sobre o uso do material em relação aos quais pode haver direitos de propriedade intelectual e sobre o uso de produtos de software proprietário?


Informações e aspectos de segurança na gestão de continuidade de negócios

Gestão de incidentes de segurança da informação e melhorias

Gestão da Continuidade de Negócios

Conformidade

Cumprimento dos requisitos legais

114 de 201

15.1.3 Proteção de registros organizacionais

A.15.1.3 Estão os registos importantes protegidos contra perda, destruição e falsificação, de acordo com as disposições legais, exigências regulatórias, contratuais e de negócios? PI PI PI PI Parcialmente

implementado

15.1.4 Protecção de dados e privacidade da informação pessoal

A.15.1.4 Está a protecção de dados e privacidade garantida, conforme exigido na legislação pertinente,regulamentos, se for o caso, as cláusulas contratuais? PI PI PI PI Parcialmente

implementado

15.1.5Prevenção do mau uso de recursos de processamento da informação

A.15.1.5 Os utilizadors estão impedidos de utilizar as instalações de processamento de informações para fins não autorizados? PI PI PI PI Parcialmente implementado

15.1.6 Regulamentação de controlos criptográficos A.15.1.6 Os controlos criptográficos utilizados em conformidade com todos os acordos relevantes, leis e regulamentos? NI NI NI NI Não

Implementado

15.2

15.2.1 Conformidade com as políticas e normas de segurança

A.15.2.1 Os gestores garantem que todos os procedimentos de segurança dentro da sua área de responsabilidade são executados corretamente para atingir a conformidade com políticas e normas de segurança? NI NI NI NI Não

Implementado

15.2.2 Verificação de conformidade técnica

A.15.2.2 Os sistemas de informação são examinados regularmente para o cumprimento das normas de implementação de segurança? PI PI PI PI Parcialmente

implementado

15,3

15.3.1 Auditoria de controlo a sistemas de informação

A.15.3.1 Os requisitos de auditoria e atividades envolvendo verificações em sistemas operacionais são cuidadosamente planeados e acordados para minimizar o risco de rupturas nos processos de negócios? I I I I Implementado

15.3.2Proteção das ferramentas de auditoria a sistemas de informação

A.15.3.2 O acesso a ferramentas de informação e sistemas de auditoria são protegidos para evitar qualquer possível abuso? PI PI PI PI Parcialmente implementado

Considerações em auditoria a sistemas de informação

Conformidade com as políticas de segurança, normas e conformidade técnica

115 de 201


Anexo 9 - Relatório de análise de falhas

116 de 201

ISO 27001 ISMS - Análise de falhas (Exemplo)

Página 1 de 21 08/09/12

Histório de versões

Versão Alterações Alterados Data

0.1 Documento inicial 2012-06-25

Aprovação

Data Aprovado Função Assinatura

Referência & Dependências

Ref Documento Versão Data

A ISO/IEC 27001:2005 – Requisitos de um ISMS 1ª edição Out 2005

C ISO/IEC 27002:2005 – Código de boas práticas 2ª edição Jun 2005

Indice de Ilustrações

Imagem 1 ....................................................................................................................................................... 4 Imagem 2 ....................................................................................................................................................... 6

117 de 201


Page 2 of 21 Ultima Modificação 08/09/12

Conteúdo

Histório de versões .......................................................................................................................................... 1

Aprovação ....................................................................................................................................................... 1

Referência & Dependências .............................................................................................................................. 1

1. Objetivos ............................................................................................................................................. 3

2. Abordagem à análise de falhas .............................................................................................................. 3

3. Métricas de medição utilizadas ............................................................................................................. 4

4. Sumário da análise de falhas ................................................................................................................. 5

5. Gráficos de implementação .................................................................................................................. 6

Apêndice – Falhas e ações de correção ................................................................................................... 7

Controlos ISO 27001 ..................................................................................................................................... 7 Controlos ISO 27001 ..................................................................................................................................... 9 Controlos ISO 27001 ...................................................................................................................................11 Controlos ISO 27001 ...................................................................................................................................13 Controlos ISO 27001 ...................................................................................................................................15 Controlos ISO 27001 ...................................................................................................................................17 Controlos ISO 27001 ...................................................................................................................................19

Referencias ................................................................................................................................................ 21

118 de 201



Introdução

Este documento detalha os resultados da análise de falhas do SGSI(Gap Analisis) que decorreu do dia xx-xx-xxxx a dia xx-xx-xxxx, que avaliou nível atual de conformidade com a norma ISO 27001.

Na generalidade percebe-se a necessidade de implementar uma abordagem sustentada por métodos seguros nos processos críticos do âmbito deste SGSI.

Após pequena reunião com elementos do grupo de segurança da informação, percebe-se a motivação e compromisso para a implementação das correções necessária para elevar o nível de maturidade para um nível aceitável numa primeira fase e a um nível máximo nas seguintes.

1. Objetivos

Os principais objetivos desta análise foram:

• Verificar o estado da segurança da empresa aquando esta primeira análise. Isto através de comparar os controlos implementados e aqueles que são recdomendados nas normas IEC/ISO 27001 e 27002

• Detalhar as acções recomendadas com vista a correção dos problemas detetados

• Realizar um relatório, que coloca ao corrente a administração e todos os elementos relacionados com a segurança da informação sobre as falhas detetadas e acções de correção a implementar.

2. Abordagem à análise de falhas

A análise de lacunas consistiu em reuniões com membros-chave do pessoal dentro de cada uma das áreas e departamentos definidos no âmbito. As perguntas para as reuniões foram obtidas a partir das normas ISO 27001 e ISO 27002. Todas as falhas identificadas durante as reuniões provêm de uma matriz previamente construída, que identifica as possíveis falhas e indica os departamentos onde se irá fazer o teste.

A matriz tem por base todos os 133 requisitos da norma ISO / IEC 27001 (Ref. [B]) e esses requisitos da norma são projetados para atingir objetivos de melhoramento dentro das 11 áreas-chave listadas abaixo:

• Política de Segurança

• Organização de Segurança da Informação

• Gestão de Ativos

• Recursos Humanos Segurança

• Segurança Física e Ambiental

• Comunicação e Gestão de Operações

• Controlo de Acesso

119 de 201



• Aquisição de Sistemas de Informação, Desenvolvimento e Manutenção

• Informação de Gestão de Incidentes de Segurança

• Gestão de Continuidade de Negócios e

• Conformidade

3. Métricas de medição utilizadas

Esta métrica de medição tem por base a Capability Maturity Model (CMM) (marca registrada da Carnegie Mellon University, CMU) é um modelo de desenvolvimento criado após um estudo de dados recolhidos de organizações que fizeram parceria com o Departamento de Defesa dos EUA, que financiou a pesquisa.

O termo "maturidade" refere-se ao grau de formalidade e optimização de processos, de práticas ad hoc, passos definidos formalmente, para as métricas de processos formalmente bem definidos, para no finaç obter uma optimização activa dos processos.

À métrica padrão, foram adicionados dois níveis, o CMM 0 e o CMM 6, para possibilitar a execução do Gap Analisis. Esta aobordagem foi criada e adaptada pelo ISO 27001 Forum - https://groups.google.com/forum/?fromgroups#!topic/iso27001security.

Cada um dos resultados identificados no Apêndice 1 terá uma classificação de nível de maturidade CMM atribuído. A tabela a seguir vai ser utilizada para identificar a classificação para cada controlo a medir. Para esclarecimento, as avaliações dos níveis de maturidade são descritos abaixo novamente.

Níveis de maturidade

0 1 2 3 4 5 6

�

Imagem 1

Exemplo de nivel de maturidade CMM

Avaliação de Nível de Maturidade - A classificação de níveis foi realizada utilizando uma metodologia de cinco níveis baseado no Capability Maturity Model (CMM). Usamos a CMM por fornecer uma referência para comparação e compreensão dos comportamentos, práticas e processos de uma organização.

Os cinco níveis são :

• CMM 1 (inicial) - Há evidências de que um problema de segurança existe e precisa ser tratado, porém não há controlos para resolver a questão.

• CMM 2 (Parcial) - Os controlos de segurança ainda estão em desenvolvimento e / ou não há documentação para apoiar a exigência.

• CMM 3 (Definido) - Os controlos de segurança foram documentados e comunicados através da formação, mas há áreas onde o detalhe necessário é inexistente e / ou áreas onde não estão aplicadas ou ativamente apoiadas pela alta administração.

120 de 201



• CMM 4 (Monitorizado) - É possível medir a eficácia dos controlos de segurança, mas não há evidência de estarem a atingir o nível necessário de cumprimento.

• CMM 5 (Optimized) - Os controlos de segurança foram refinados ao nível exigido pela norma ISO 27001 com base numa liderança eficaz, gestão da mudança, melhoria contínua e comunicação interna.

Para os fins da análise de falhas existem dois níveis adicionais nos níveis das classificações de maturidade:

• CMM 0 (inexistente) - A completa falta de controlo;

• CMM 6 (não aplicável) - Controlo está fora do âmbito.

4. Sumário da análise de falhas

Na primeira abordagem ao sistema de segurança implementado na nossa empresa, os níveis de proteção são razoáveis. Contudo, existem inúmeros pontos críticos que carecem de uma proteção sistematizada e com um nível operacional mais rigoroso.

Em anexo, estão as taxas de implementação dos controlos da norma ISO 27002 para existir um nível aceitável de segurança da informação. Um aspeto importante é a maturidade da implementação de cada controlo, estes mostram que controlos estão com um nível de implementação mais ou menos otimizado. Globalmente, podemos dizer que os controlos implementados têm um nível aceitável de maturidade, os gráficos sobre este fato serão apresentados na versão final deste documento.

Conclui-se que a empresa está desde o inicio virada para a proteção dos seus ativos, mesmo de uma forma um pouco rodimentar em relação ao possível de implementar, tem conseguido ver os seus riscos em níveis pouco destrutivos.

121 de 201


Página 6 de 21 08/09/12

5. Gráficos de implementação

Controlos ISO 27002 Implementados

Imagem 2

122 de 201



Apêndice – Falhas e ações de correção

Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM

5.1.1 Política de Segurança de

Informação

A.5.1.1 É um documento aprovado pela Administração, publicado e comunicado a todos os funcionários e partes externas relevantes?

Não existe nenhuma polítca de segurança bem definida e a que existe não foi aprovada pela administração

Recomendações:

Deverá ser feito uma breve explicação sobre as políticas de segurança, princípios, normas e requisitos de conformidade de particular importância para a organização, incluindo:

• conformidade com requisitos legislativos, regulamentares e contratuais;

• educação, segurança, treinamento e requisitos de sensibilização;

• gestão de continuidade de negócios;

• conseqüências das violações da política de segurança da informação;

Responsável: Rafael Simões

Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

123 de 201



6.1.1 Compromisso da administração

para a segurança da informação

A.6.1.1 Existe um comprometimento escrito que a Administração deve apoiar activamente a segurança dentro da organização através de uma direção clara e do reconhecimento das suas responsabilidades de segurança da informação?

Não existe qualquer compromisso da administração que demonstre qualquer compromisso com a segurança da informação.

Recomendações:

Administração deve:

a) assegurar que as metas de segurança da informação são identificadas, cumprem as necessidades da organização e integram os processos críticos;

b) formular, rever e aprovar a política de segurança da informação;

c) rever a eficácia da implementação da política de segurança da informação;

Responsável: António Simões

Due date: 10-07-2012

==

0 1 2 3 4 5 6

�

==

124 de 201




6.2.1 Identificação dos riscos

relacionados com partes externas

A.6.2.1 Os riscos para a informação da organização e instalações de processamento de informações dos processos de negócios críticos que envolvam partes externas, foram identificados e implementados controlos apropriados antes de conceder acesso?

Sim, pese embora que os controlos implementados estejam ainda com um nível de maturidade baixo e necessitam de sofrer melhoramentos.

Recomendações:

Onde existe uma necessidade de permitir um acesso a parte externa das instalações de processamento de informação ou informações de uma organização, uma avaliação de risco deve ser realizada para identificar os requisitos para controlos específicos. A identificação dos riscos relacionados com o acesso de parte externa deve levar em conta as seguintes questões:

a) É necessário que as partes externas acedam às infraestruturas de processamento de informação?

b O valor e a sensibilidade da informação envolvida e sua criticidade para o negócio é elevada?

operações;


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

125 de 201



7.1.1 Inventário de Ativos

A.7.1.1 Estão todos os ativos claramente identificados e um inventário de todos os ativos importantes elaborado e armazenado?

Sim estão, mas os donos dos activos não estão devidamente documentados e alguns pormenores de informação importante não estão recolhidos. Exemplo: Números de série e versões do ativo.

Recomendações:

A propriedade e informação detalhada de classificação devem ser acordadas e documentadas para cada um dos activos.


Due date: 10-07-2012

==

0 1 2 3 4 5 6

�

==

126 de 201




7.2.1 Diretrizes de classificação

A.7.2.1 Tem informação classificada em termos de valor, requisitos legais, sensibilidade e criticidade para a organização?

Sim, a informação está classificada quanto à criticidade e sensibilidade, mas a sensibilidade varia com o tempo. Quanto À valorização, não existem quaisquer exercícios realizados no sentido de calcular valor de informações.

Recomendações:

A Informação deixa frequentemente de ser sensível ou crítica após um certo período de tempo, por exemplo, quando a informação tenha sido tornada pública.

Estes aspectos devem ser levados em conta, pois a sobre-classificação pode levar à execução de controlos desnecessários, resultando em custos.


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

127 de 201



8.1.1 Papeis e responsabilidades

A.8.1.1 Foram definidas e documentadas as responsabilidades e funções de segurança dos funcionários, contratados e terceiros de acordo com a política de segurança da informação da organização?

As classificações existentes apenas estão relacionadas com as categorias de trabalhos do organigrama da organização. No que toca a segurança não existe nada construído.

Recomendações:

Os papeis de segurança e responsabilidades devem incluir algumas exigências:

• implementar e agir em conformidade com a segurança da informação da organização

• proteger os ativos contra o acesso não autorizado, divulgação, modificação, destruição ou interferência;

• assegurar que a responsabilidade é atribuída ao indivíduo por todas as ações tomadas.


Due date: 10-07-2012

==

0 1 2 3 4 5 6

�

==

128 de 201




8.2.3 Procesos disciplinar

A.8.2.3 Existe um processo disciplinar formal para empregados que tenham cometido uma violação de segurança?

Não existe nenhum procedimento disciplinar em vigor para caso que não comtemplem sanções judiciais e de menor gravidade.

Recomendações:

O processo disciplinar formal deve assegurar um tratamento correcto e justo para os empregados que sejam suspeitos de cometer violações de segurança.

O processo disciplinar formal deve fornecer uma resposta graduada que leva em consideração fatores tais como a natureza e a gravidade da violação e seu impacto nos negócios, se esta é ou não uma primeira infracção ou uma repetição, se o infrator foi devidamente treinada, legislação pertinente, contratos comerciais e outros fatores, conforme necessário..


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

129 de 201



8.3.1 Responsabilidades de termino de

contrato

A.8.3.1 As responsabilidades para a realização de cessação do emprego ou mudança de emprego estão claramente definidas e documentadas?

Não existe nenhum tipo de clausula no contrato dos trabalhadores ou terceiros que restrinja ou impessa a livre desvinculação da organização ou obrigue confidencialidade após cessação.

Recomendações:

Responsabilidades e deveres, que ainda sejam válidos após a cessação de contrato deve estar contido em contratos de funcionários, contratados ou utilizadores subcontratados


Due date: 10-07-2012

==

0 1 2 3 4 5 6

�

==

130 de 201




9.1.4 Proteção contra ataques externos e

ambientais

A.9.1.4 Proteção física contra danos causados por incêndio, inundação, terremoto, explosão, distúrbios civis, e outras formas de desastres naturais ou provocados pelo homem foi concebido e aplicado?

Existem algumas proteções contra alguns fenómenos,mas existe a possibilidade de continuar a promover melhoramentos nestes aspectos.

Recomendações:

As seguintes diretrizes devem ser consideradas para evitar danos causados por incêndios, explosões, terremotos, inundação, distúrbios civis, e outras formas de desastres naturais ou provocados pelo homem:

• materiais perigosos ou combustíveis devem ser armazenados a uma distância segura de uma área segura. Fornecimento a granel, tais como artigos de papelaria não deve ser armazenada dentro de uma área segura;

• equipamentos de reserva e de back-up de mídia devem ser instalados a uma distância segura para evitar danos de um desastre que afeta o site principal;

• equipamentos adequados de combate a incêndios devem existir e estár devidamente instalados.


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

131 de 201



9.2.1 Implantação de equipamentos para

proteção

A.9.2.1 Estão instalados equipamentos para reduzir os riscos de ameaças e perigos ambientais e as oportunidades de acesso não autorizado?

Sim, existem elementos que protegem contra o acesso não autorizado e ameaças ambientais. No que toca a acesso não autorizado existem controlos recomendados.

Recomendações:

Activos que requerem proteção especial devem ser isolados para reduzir o nível geral de protecção exigida;


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

132 de 201




10.1.4 Separação de instalações de teste,

desenvolvimento e operações

A.10.1.4 São o desenvolvimento, teste e instalações operacionais separados para reduzir os riscos de acesso não autorizado ou alterações nos sistemas operacional e de desenvolvimento?

Neste campo foi atribuído um louvor pelo trabalho executado até ao momento. Parabéns.

Recomendações:


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

133 de 201



10.2.3 Gestão de mudanças para serviços

de terceiros

A.10.2.3 As mudanças realizadas na prestação de serviços, incluindo a manutenção e melhoria das políticas de segurança da informação, procedimentos e controlos existentes, têm em conta a criticidade dos sistemas e processos de negócio e na re-avaliação de riscos?

Como neste momento ainda não existe uma politica de segurança da informação, logo este ponto ainda está muito imaturo.

Recomendações:

O processo de gestão de mudanças para serviços de terceiros deve ter em conta:

• as alterações feitas pela organização para implementar:

• melhorias para os serviços atuais oferecidos;

• desenvolvimento de quaisquer novos aplicativos e sistemas;


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

134 de 201




10.3.1 A gestão de capacidade para novos

sistemas

A.10.3.1 Existe um processo que garanta que o uso de recursos são monitorizados, atento, e as projeções feitas de requisitos de capacidade futura para garantir o desempenho do sistema requerido?

Sim, existem vários elementos que controlam o uso dos recursos nos vários departamentos e a vários níveis.

Recomendações:

Para cada novo planeamento de serviço em curso, os requisitos de capacidade devem ser identificados. O sistema de monitorazão deve ser ajustado para garantir e melhorar a disponibilidade e a eficiência dos sistemas.

A reavaliação dos sistemas em vigor deve ser contemplado e sempre que possível deve existir a procura de implementação de sistemas que melhorem o objetivo deste ponto.


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

135 de 201



10.4.1 Controlos contra códigos maliciosos

A.10.4.1 Existem controlos de detecção, prevenção e recuperação para proteger contra códigos maliciosos e procedimentos apropriados de conscientização de utilizadores?

Não, neste momento não existem sistemas que recuperem informação após ataques de códigos maliciosos. Este ponto é de extremo interesse e terá atenção especial.

Recomendações:

Deve ser estabelecido uma política formal de proibição de uso de software não autorizado; Deve ser estabelecida uma política formal para proteger contra riscos associados com a obtenção de arquivos e software a partir de redes externas, ou em qualquer outro meio, indicando quais as medidas de protecção devem ser tomadas.


Due date: 10-07-2012

0 1 2 3 4 5 6

�

==

136 de 201


Página 21 de 21 08/09/12

Referencias

CMM Adaptação ISO 27001 pelo ISO 27001 Forum

137 de 201


100

Anexo 10 - Explicação do Plano de implementação

ISO 27001

138 de 201

Classificação: INTERNA

Plano de Implementação ISO 27001 v006

Classificação: INTERNA RRS

2012 Página 1

Histórico

DATA VERSÃO RESPONSÁVEL DESCRIÇÃO

2012-06-11 000 RRS Criação do documento

2012-06-12 001 RRS Remoção de Pontos em excesso

2012-06-26 002 RRS Alterar Estrutura do Documento Sub-Pontos Sync Com Project Plan

2012-06-30 003 RRS Alterar o pedido na reunião de seguimento “Historial-2012-06-29”

2012-07-08 004 RRS 6.1 - Tratamento de Risco – eliminado, passou para 5.1 Avaliação de riscos de segurança da informação

2012-07-11 005 RRS Objectivos do Documento

2012-07-14 RRS Eliminação 3.6 – Juntei ao 4.2

2012-07-14 RRS Alteração de toda a fase de Risk Assesment

2012-07-16 RRS Alteração Gap Analysis

2012-07-19 RRS ISMS – Framework de gestão documental - no início da implementação

2012-07-21 RRS Retirei 7.6 – planos de segurança – não tinha sentido

2012-08-06 RRS Adicionar 6.1

2012-08-20 RRS Finalização da revisão ortográfica

139 de 201




2012 Página 2

Índice Histórico ............................................................................................................................... 1

Objectivos do Documento ......................................................................................................... 4

I. (Fase Preparatória) ............................................................................................................ 5

1. Clarificar prioridades a desenvolver no ISMS ................................................................. 5

1.1 Os objectivos de implementação ........................................................................... 5

2. Definição preliminar do âmbito / alcance do ISMS ......................................................... 6

2.1 Responsabilidades e cargos.................................................................................... 7

2.2 ISMS – Framework de gestão documental.............................................................. 8

II. (FASE PLAN) .................................................................................................................... 10

3. Estabelecer o ISMS ...................................................................................................... 10

3.1 Definição do âmbito / alcance do ISMS ................................................................ 10

3.2 Definir os requisitos de segurança da informação - processos do ISMS ................ 11

3.3 ISMS - Management Information Security Forum (MISF) ...................................... 13

3.4 Definição da política de segurança ....................................................................... 14

3.5 Definir uma política para o ISMS .......................................................................... 16

4. Classificação de activos................................................................................................ 17

4.1 Identificar Activos - dentro do âmbito do ISMS .................................................... 17

4.2 Procedimentos e métricas para avaliação do Risco............................................... 19

5. Risk Assessment .......................................................................................................... 21

5.1 Avaliação de riscos de segurança da informação .................................................. 21

5.2 Controlos e objectivos dos controlos.................................................................... 23

5.3 Preparar SOA – Statement of Applicability ........................................................... 24

III. (DO) ............................................................................................................................ 25

6. Implementar e Operar ISMS ........................................................................................ 25

6.1 Tratamento de Risco ............................................................................................ 25

6.2 Implementação de controlos ............................................................................... 25

6.3 Segurança de informação organizacional ............................................................. 27

6.4 Manual da política de segurança da informação .................................................. 27

6.5 Desenvolver as normas e procedimentos de segurança da informação ................ 29

6.6 Formação e sensibilização .................................................................................... 30

6.7 Gerir operações e recursos do ISMS ..................................................................... 31

IV. (CHECK) ....................................................................................................................... 32

7. Monitorizar e Rever o ISMS ......................................................................................... 32

140 de 201




2012 Página 3

7.1 Monitorizar e rever os procedimentos ................................................................. 32

7.2 Auditorias Internas .............................................................................................. 33

7.3 Auditoria Externa ................................................................................................. 34

7.4 Medir eficácia dos controlos ................................................................................ 34

7.5 Rever Avaliação do Risco...................................................................................... 36

V. (ACT) ............................................................................................................................... 37

8. Manter e melhorar o ISMS .......................................................................................... 37

8.1 Melhorar ISMS ..................................................................................................... 37

Exemplo de processo: ......................................................................................................... 37

9. Revisão de conformidade ............................................................................................ 38

9.1 Completar uma revisão de conformidade com a Checklist da ISO 27003 .............. 38

9.2 Corrigir as não conformidades ............................................................................. 39

10. Auditoria Externa ao ISMS ....................................................................................... 40

VI. Definições e Acrónimos ............................................................................................... 41

VII. Referências ................................................................................................................. 42

141 de 201




2012 Página 4

Objectivos do Documento

Este documento tem como objectivo prestar apoio à implementação da norma ISO 27001 numa PME, constando neste um Road Map contendo todas as fases do processo de implementação e uma abordagem exemplificativa de cada fase.

Apesar de este documento ter compilado as normas 27001, 27002, 27003 e 27799, este não substitui a consulta a estas mesmas normas para um esclarecimento mais detalhado.

Por cada fase, o documento faz referência às pessoas ou cargos da organização que devem fazer parte directa ou indirecta do processo, bem como os documentos que deverão ser produzidos no final do processo / fase.

O campo “entrada” de cada fase faz referência a documentos ou ideias que terão de estar pré-definidas ou produzidas antes do início da fase em questão.

No campo “Fontes Adicionais” podem-se encontrar referências ou fontes mais detalhadas de informação acerca de cada fase de implementação.

O documento encontra-se dividido em 5 partes, a fase anterior à implementação “Fase Preparatória”, e as 4 fases de implementação, Plan, Do, Check e Act.

142 de 201




2012 Página 5

I. (Fase Preparatória)

1. Clarificar prioridades a desenvolver no ISMS 1.1 Os objectivos de implementação

Os objectivos de implementação do ISMS devem ser pensados tendo em conta os requisitos e prioridades da segurança da informação da empresa.

Entrada o Objectivos estratégicos da empresa o Resumo dos sistemas de gestão existentes o Listagem de requisitos legais, entidades reguladoras e contractos de

obrigação que se apliquem à segurança da informação na empresa. Saída o Documento resumindo os objectivos específicos e prioritários da

empresa na implementação da norma. Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa / interessado ou destacado para o estudo da implementação da norma Normalmente este processo é encabeçado por responsáveis das TI

caso não exista um responsável directo pela segurança da informação.

Fontes Adicionais o Norma ISO/IEC 27003:2010 Capitulo 5.3

Abordagem Recomendada

Os objectivos para a implementação do ISMS podem ser determinados pelas respostas às seguintes questões:

Gestão do Risco – Como é que o ISMS pode trazer uma melhoria da gestão do risco da segurança da informação?

Eficiência – Como pode o ISMS melhorar a gestão da segurança da informação?

Vantagens de Negócio – como pode o ISMS trazer vantagens competitivas para a empresa?

De maneira a responder às questões acima, as prioridades de segurança são endereçadas por exemplo da seguinte maneira:

a) Negócios críticos e áreas de organização; I. Quais as áreas organizacionais que servem o negócio e qual o seu propósito?

II. Que ligações existem com empresas externas e quais os acordos? III. Que tipos de serviços existem subcontratados? IV. Quais são os negócios e as áreas críticas para a empresa?

b) Informação sensível ou importante I. Que informação é crítica para a empresa?

II. Quais seriam as consequências prováveis se certa informação fosse divulgada por partes não autorizadas? (Ex: perca de vantagem competitiva, perca de reputação, acções legais, etc.)

143 de 201




2012 Página 6

c) Leis que obrigam à existência de medidas de segurança da informação I. Que leis relacionadas com tratamento de risco ou segurança da informação se

aplicam à empresa? d) Acordos contratuais ou organizacionais relacionados com segurança da informação?

I. Requisitos de armazenamento dos dados (períodos de retenção, etc.)? II. Existem requisitos contratuais relacionados com a privacidade ou com a

qualidade (Ex: Service Level Agreement – SLA)? e) Requisitos a nível da indústria que especifiquem controlos específicos no que toca à

segurança da informação? I. Que requisitos específicos se aplicam ao sector da empresa?

f) Ambiente das ameaças I. Que tipo de protecção é necessária e contra que tipo de ameaças?

II. Quais são as diferentes categorias de informação que requerem protecção? III. Quais são as diferentes actividades de manuseio de informação que carecem

de protecção? g) Aspectos competitivos:

I. Quais são os requisitos do mercado onde a empresa se insere ao nível da segurança da informação?

II. Existem controlos adicionais à segurança da informação que tragam vantagens competitivas à empresa?

h) Continuidade de Negócio – Requisitos I. Quais os processos críticos do negócio? (processos em que a interrupção será

nefasta para a empresa) II. Até que nível a empresa pode tolerar a interrupção de cada um destes

processos críticos?

2. Definição preliminar do âmbito / alcance do ISMS

Entrada o O desenho do âmbito do ISMS terá de ter em atenção a fase anterior - prioridades da empresa.

Saída o Desta fase deve resultar um documento onde seja definido o âmbito preliminar do ISMS

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa /

interessado ou destacado para o estudo da implementação da norma Fontes Adicionais o NA

144 de 201




2012 Página 7


Os objectivos da implementação do ISMS devem incluir um âmbito de aplicação.

Tendo em mente a execução do projecto de implementação do ISMS, deve ser definida a estrutura da organização para o ISMS. Este âmbito inicial/preliminar deve ser definido para um guia de ajuda às decisões de implementação que irão surgir durante o processo.

Desta fase deve resultar um documento definindo o âmbito preliminar do ISMS, incluindo nele:

a) Um resumo das obrigações de segurança da informação exigidas pela empresa e as obrigações impostas por entidades externas (clientes, fornecedores, entidades públicas)

b) Descrição da relação entre as áreas englobadas pelo ISMS e os outros sistemas de gestão existentes na empresa (ex. SGSI – ISO9001)

c) Listagem dos objectivos da empresa a nível de gestão de segurança da informação (derivação do ponto anterior “Os objectivos para a implementação”)

d) Listagem resumida dos processos críticos para a empresa e suas características, sistemas críticos, activos de informação e suas características/tecnologias

e) Listagem das estruturas e localizações geográficas da empresa que sejam para englobar no ISMS

f) Devem ser identificados os elementos comuns e as diferenças de operação entre os vários sistemas de gestão existentes.

2.1 Responsabilidades e cargos

As responsabilidades e cargos devem ser definidos para o âmbito do ISMS.

Entrada o Âmbito preliminar desenvolvido no ponto anterior o Lista de partes interessadas\beneficiadores dos resultados do

projecto de implementação. Saída o Documento ou tabela que descreva os papéis / cargos e as

responsabilidades (com nomes) que são necessárias na empresa para a implementação do ISMS

o Nomeação de uma pessoa responsável por chefiar a segurança da informação na empresa.

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o Responsável dos recursos humanos para definição do número

colaboradores disponíveis para integrar o ISMS Fontes Adicionais o ISO/IEC 27003:2010 Cap. 5.3.2

o ISO/IEC 27003:2010 Anexo B

145 de 201




2012 Página 8


A estrutura organizativa e os recursos para assegurar a segurança da informação variam de empresa para empresa dependendo entre outros aspectos, da sua dimensão. Por exemplo numa pequena empresa, vários cargos são ocupados por uma mesma pessoa.

Não obstante, deve ser implicitamente nomeada uma pessoa responsável pela chefia da segurança da informação (normalmente o Chief Information Security Officer ou o Information Security Manager) e as restantes devem ser nomeadas tendo em conta as competências demonstradas para a ocupação do cargo / função.

As principais considerações aquando à definição de cargos de gestão de segurança da informação são:

a) A responsabilidade final sobre a segurança da informação continua a estar ao nível hierárquico da administração;

b) Cada funcionário é igualmente responsável pela tarefa original (função / cargo) e por manter a segurança da informação no local de trabalho e na organização;

c) Uma pessoa é apontada como promotor e coordenador dos processos de segurança da informação, normalmente o Chief Information Security Officer.

Deve ser criado um fórum de segurança da informação que permita melhorar a ligação entre os papéis / cargos de gestão de segurança de informação.

Os chefes de departamentos integrantes no âmbito do ISMS, são potenciais membros integrantes dos membros da equipa de implementação.

No anexo B da ISO 27003 existem detalhes que auxiliam na definição das responsabilidades e cargos.

2.2 ISMS – Framework de gestão documental

Os registos e documentos pertencentes ao ISMS devem ser controlados e documentados identificando os requisitos e o framework que irá permitir o controlo desses documentos no ISMS.

Entrada o Âmbito e a abrangência do ISMS o Estrutura organizacional para a segurança da informação

Saída o Uma estrutura que descreva os princípios para a documentação do ISMS, a estrutura de procedimentos para documentar o ISMS, papéis envolvidos, formatos de dados e os caminhos que os relatórios devem seguir até à gestão.

o Projectar os requisitos de documentação o Projectar os requisitos de registo (repositório de informação) o Um documento que sumarize os requisitos para registos e controlo

documental do ISMS

146 de 201




2012 Página 9

o Os repositórios e templates exigidos para os registos do ISMS. Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa Fontes Adicionais o ISO/IEC 27002

o ISO/IEC 27001 – 4.3.1


A documentação do SGSI deve incluir o registo de decisões de gestão; assegurar que as acções são rastreáveis de decisões administrativas e de políticas (que decisão despoletou a acção?), e que os resultados obtidos são reprodutíveis.

Os documentos do SGSI devem fornecer a prova de que os controlos são seleccionados com base nos resultados da avaliação e tratamento do risco, e que tais processos são implementados juntamente com a política do SGSI.

A documentação dos procedimentos deve ter uma referência à pessoa responsável pelo Documento e ao seu proprietário.

É necessário que os documentos do SGSI sejam geridos e disponíveis aos interessados, quando necessário. Isto inclui o seguinte:

a) Estabelecer o procedimento administrativo de gestão de documentos ISMS b) A aprovação formal de documentos para adequação antes da sua emissão c) Assegurar que alterações e actual revisão dos documentos sejam identificadas d) Protecção e controlo dos documentos como um activo de informação da organização

É importante que as versões pertinentes de documentos aplicáveis estejam disponíveis, garantindo que os documentos permaneçam legíveis, identificáveis, armazenados e, finalmente, eliminados de acordo com os procedimentos aplicáveis à sua classificação (deverá ser definido no manual de gestão documental).

Além disso, garantir que os documentos de origem externa sejam identificados, que a distribuição de documentos seja controlada, impedindo o uso não intencional de documentos obsoletos, e aplicar acompanhamento adequado para os mesmos, se forem retidos para qualquer finalidade.

Os registos devem ser criados, mantidos e controlados como prova de que o ISMS da organização está em conformidade com a ISO / IEC 27001, e para mostrar a eficácia das operações.

É também necessário manter registos do estado de implementação para toda a fase PDCA, assim como registos dos incidentes e eventos de segurança da informação, registros de formação, competências, experiência e qualificações, auditorias internas do SGSI, acções correctivas e preventivas, e registos organizacionais.

147 de 201




2012 Página 10

As seguintes tarefas devem ser realizadas para controlar registos:

a) Documentar os controlos necessários para identificar, armazenar, proteger, pesquisar e descartar dados, e documentar o seu tempo de armazenamento

b) Definir o que deve ser guardado nos processos de gestão operacional, e em que medida

c) Quando qualquer período de retenção é especificado pela legislação aplicável, o período de retenção deve ser definido em conformidade com esse requisito jurídico (ex. dados de saúde, dados financeiros, etc…).

II. (FASE PLAN)

3. Estabelecer o ISMS 3.1 Definição do âmbito / alcance do ISMS

A definição detalhada do âmbito e fronteiras (alcance) do ISMS, a definição da política do ISMS e a aceitação e apoio por parte da direcção, são os principais factores que levam a uma implementação com sucesso do ISMS.

Entrada o Âmbito e alcance preliminar o Especificações a nível de negócio, activos e tecnologias

Saída o Documento que indique o âmbito, barreiras e alcance do ISMS. Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o A administração da empresa, para indicar quais são as áreas e BU’s

(Business Units) que pretendem no sistema de gestão. Fontes Adicionais o ISO/IEC 27001:2005 Cap. 4.2.1 a) / b)


Para alcançar o objectivo de definir detalhadamente o âmbito e o alcance do ISMS, é necessário cumprir os seguintes pontos:

a) Definir o âmbito e o alcance organizacional; i. ISO 27003 - 6.2

b) Âmbito e alcance do ICT – Information Communication Technology; i. ISO 27003 - 6.3

c) Âmbito e alcance físico; i. ISO 27003 - 6.4

d) Especificações a nível de negócio, localização da empresa, activos e tecnologias, podem ser encontradas na ISO 27001 – 4.2.1 a) e b)

e) Integrar o âmbito e alcance preliminar para obter o “âmbito e alcance do ISMS”. i. ISO 27003 - 6.5

148 de 201




2012 Página 11

Será que o negócio percebe que a segurança da informação deve fazer parte da tecnologia? Será que o negócio sabe a diferença entre segurança da informação, privacidade e segurança física? Como estão os recursos alinhados em termos de segurança da informação, divididos por business units ou são comuns à organização? Nesta fase devemos ver respondidas as questões anteriores.

3.2 Definir os requisitos de segurança da informação - processos do ISMS

Nesta fase é importante considerar os requisitos de segurança, assim como que activos de informação que serão considerados no ISMS e verificar o ponto de situação de controlos aplicados.

Entrada o Prioridades do ISMS. o Objectivos, prioridades e requisitos da empresa. o Listagem de legislação aplicável, contractos e obrigações legais. o Política do ISMS, aprovação da administração

Saída o Documento que identifique os requisitos de segurança da informação e a que activos se aplicam, e que identifique em detalhe a infra-estrutura da empresa

o Um documento acerca das consequências dos incidentes da segurança da informação para a actividade normal da empresa.

o Documentar os processos, funções, localizações, sistemas de informação e redes de comunicação, caso ainda não tenham sido incluídos no ISMS.

o Efectuar a análise de Lacunas (Gap-Analysis) \Deliverables\2 – Plan\ 2012-04-07 Gap-Analysis- Controls.xlsx

o Relatório de Falhas / Lacunas \Deliverables\2 – Plan\2012-06-25 Relatório de análise de

falhas.docx Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Chefes de Departamento para auxiliarem a identificar os activos de

informação e respectivos requisitos de segurança. Fontes Adicionais o ISO/IEC 27001:2005 4.2.1.c), d), e)


Para definir requisitos relevantes a serem suportados pelo ISMS, identificar os activos de informação e obter o estado actual da segurança da informação, devemos consultar: ISO/IEC 27001 4.2.1.c), d), e).

A informação recolhida nesta fase de análise de requisitos de segurança, deve:

149 de 201




2012 Página 12

a) Criar um ponto de partida para a gestão b) Identificar e documentar condições para a implementação c) Fornecer um conhecimento consolidado e bem definido acerca das infra-estruturas da

organização d) Identificar os níveis desejados de segurança da informação para a empresa e) Determinar o conjunto das informações necessárias para a totalidade ou parte da

empresa no âmbito da proposta de implementação.

Como ajuda a esta fase devemos usar os documentos produzidos em 3 etapas anteriores:

a) Prioridades do ISMS a. Objectivos, prioridades e requisitos da empresa. b. Listagem de legislação aplicável, contractos e obrigações legais.

b) Política do ISMS, aprovação da administração

Por cada processo e tarefa especial da organização, terá de ser avaliado / decidido o quão crítica é a informação usada, por exemplo ao nível da protecção exigida. Diversas condicionantes internas poderão afectar a segurança da informação, e estas condicionantes terão de ser todas determinadas.

Nesta fase ainda não é necessário descrever em detalhe as tecnologias de informação em detalhe, deverá ser feito apenas um curto resumo da informação usada por um processo e que ICT (Information Communication Technology) – sistemas e aplicações estão associados.

A análise dos processos da organização deve fornecer um documento acerca dos efeitos dos incidentes da segurança da informação para a actividade normal da empresa.

Os processos, funções, localizações sistemas de informação e redes de comunicação têm de ser identificados e documentados caso ainda não tenham sido incluídos no ISMS.

Devem nesta fase ser identificados os activos de informação da empresa, os processos críticos / classificação de activos, requisitos de segurança a nível legal / contratual, a necessidade de formação dos funcionários da empresa a nível de segurança da informação.

Análise de Lacunas (Gap-Analysis)

Deve ser executada a Análise de lacunas, com uma ferramenta parecida com a (2012-04-07 Gap-Analysis- Controls.xlsx), esta ferramenta possui todos os controlos da norma, e nele vamos identificar os departamentos (âmbito de aplicação) a que esses controlos se aplicam, poderão haver alguns que não se apliquem ao âmbito da empresa.

Depois de termos o documento efectuado e actualizado a cada iteração, vamos efectuar o relatório de análise de falhas, e nele especificar o nível de maturidade de implementação de cada controlo e especificar algumas recomendações de implementação para o controlo (2012-06-25 Relatório de análise de falhas.docx).

150 de 201




2012 Página 13

3.3 ISMS - Management Information Security Forum (MISF)

Nesta fase importa ser pensado um grupo de discussão de segurança da informação para a empresa.

Entrada o ND Saída o Documento que indique as responsabilidades do Grupo

o Documento que indique os Membros do Grupo e seus cargos o Documento que defina a frequência das acções / reuniões do grupo.

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa

Fontes Adicionais o ND


Deve ser criado um grupo multidisciplinar de discussão, semelhante a um fórum de segurança.

Este grupo tem como funções:

a) Criar um programa de alertas ao staff da empresa com updates regulares b) Rever as políticas de segurança da informação e assegurar a relevância e a fácil

percepção das mesmas c) Desenvolver um processo de gestão de incidentes de segurança da informação.

Este grupo deve ser um grupo que não integre directamente o ISMS pois deverá ter uma visão crítica ao ISMS da empresa.

Membros: Inicialmente os membros deste grupo serão especialistas nas áreas englobadas no ISMS alinhadas à segurança da informação:

Gestor de Risco

Chefe dos Auditores internos

Auditor informático

Responsável pela protecção dos dados

Director de recursos humanos

Etc…

Frequência de Acções

As reuniões devem ser mensais, caso um acontecimento grave na segurança da informação o exija esta reunião deverá acontecer de imediato.

Assuntos abordados

a) Resultados das auditorias internas e respectiva análise b) Receber e analisar feedback das partes interessadas pela segurança da informação

151 de 201




2012 Página 14

c) Novas técnicas, produtos e procedimentos que possam ser usados para melhorar a performance do ISMS

d) Estado das acções correctivas e preventivas e) Vulnerabilidades e ameaças que não estão devidamente endereçadas desde o último

levantamento de risco f) Rever todos os incidentes de segurança e determinar se são necessárias acções que

alterem o ISMS ou a política de segurança da informação g) Recomendações e conselhos de melhoria a serem passados ao responsável pelo ISMS

(Operations Board)

3.4 Definição da política de segurança

Nesta fase deve sair um documento geral de segurança de informação para divulgar pelos funcionários da empresa e transmitir-lhes a sua responsabilidade sobre a informação.

Entrada o Âmbito de actuação o Requisitos legais e de negócio

Saída o Documento – política de segurança da informação Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Administração da empresa – aprovação do documento e

consciencialização dos funcionários Fontes Adicionais o Caso a política seja distribuída fora da organização - ISO/IEC 13335.

152 de 201




2012 Página 15


Este documento serve de guia e suporte à segurança da informação em acordo com os requisitos de negócio e requisitos legais aplicáveis.

Deve ser aprovado pela administração da empresa e devidamente divulgado por todos os elementos da organização e até mesmo por entidades externas relevantes.

Este documento deve mencionar o empenho da administração na implementação da gestão da segurança na informação e deve conter os seguintes pontos:

a) Uma definição de segurança da informação, os principais objectivos, o âmbito e a importância da segurança da informação enquanto permite a partilha da informação;

b) Uma declaração de intenção por parte da administração que dêem suporte aos objectivos e princípios básicos da segurança da informação em linha com a estratégia de negócio da empresa;

c) Um quadro para definir os objectivos de controlo e controlos, incluindo a estrutura de avaliação e gestão de riscos

d) Uma breve explicação das políticas de segurança, princípios, normas e requisitos legais que têm especial importância para a empresa:

i. Requisitos legais e regulamentos industriais ii. Educação para a segurança, formação e necessidades de sensibilização iii. Gestão da continuidade do negócio iv. Consequências da violação da política de segurança da informação

e) Responsabilidades gerais e responsabilidades específicas para a gestão da segurança da informação, incluindo o reporte / comunicação de incidentes de segurança da informação

f) Referencia para um documento mais detalhado que dê suporte à política, por exemplo com mais detalhe a nível dos procedimentos de segurança para sistemas de informação ou regras de segurança que os funcionários devem cumprir.

Esta política de segurança da informação deve ser comunicada a toda a organização, por um meio credível, acessível e perceptível para o leitor destinado.

Caso a política seja distribuída fora da organização, informação mais sensível tem de ser censurada. Mais informação pode ser encontrada na ISO/IEC 13335.

153 de 201




2012 Página 16

3.5 Definir uma política para o ISMS

Nesta fase deve ser levado em conta os resultados da fase de definição do âmbito e limites, das prioridades da empresa e do caso de negócio da empresa – requisitos e prioridades de segurança da informação, bem como o plano inicial para a implementação do ISMS.

Entrada o Âmbito de actuação o Requisitos legais e de negócio o Plano inicial de implementação do ISMS

Saída o Documento que descreva a política do ISMS Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Administração da empresa – aprovação do documento

Fontes Adicionais o Critério de avaliação do Risco - ISO/IEC 27005:2008


Devemos considerar:

i. Estabelecer os objectivos do ISMS baseando-se nos requisitos e prioridades de segurança da informação.

ii. Contextualizar a Gestão de Risco em relação à empresa iii. Estabelecer um critério de avaliação do Risco e uma estrutura de avaliação de Risco iv. Clarificar as responsabilidades de alto nível de gestão em relação ao ISMS

O Âmbito, e a política em si, devem levar em conta as características do negócio, a organização, local, activos e tecnologia. A política deve incluir um framework para definir os objectivos e estabelecer o sentido geral da direcção. Deve levar-se em conta todos os requisitos de negócio, requisitos de segurança legais, regulamentares e contratuais. A política deve estabelecer o contexto estratégico (para a organização e gestão de riscos) dentro do qual o SGSI será estabelecido. É preciso estabelecer critérios para a avaliação do risco e da estrutura da avaliação de risco. Mais uma vez, a gestão deve aprová-lo.

Desta fase deve sair um documento que descreva a política do ISMS. Este documento deve ser revisto numa fase posterior após a avaliação do risco, sendo este influenciado pela avaliação do risco.

154 de 201




2012 Página 17

4. Classificação de activos 4.1 Identificar Activos - dentro do âmbito do ISMS

Vamos nesta fase identificar e avaliar os activos de informação que existem na empresa e vão ser suportados no ISMS (estão dentro do âmbito).

Entrada o ND Saída o Documento que identifique todos os activos da empresa, processos

associados, dono do activo, classificação da informação, etc… o \Deliverables\2 – Plan\ 2012-04-01-001 Listagem de Ativos.xlsx

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o Chefes de Departamento para auxiliarem a identificar os activos de

informação e respectivos requisitos de segurança. o Responsável das TI



Para identificar os activos temos de listar e descrever:

a) Nome Único para o processo b) Descrição do processo e actividades associadas (criação, armazenamento, transmissão,

eliminação) c) Criticidade do processo para a empresa (critico, importante, auxiliar (de suporte à

empresa)) d) Titular (dono) do processo (organization unit) e) Processos que obtêm ou fornecem informação a este processo f) Aplicações informáticas que suportam este processo

Classificação da informação (confidencialidade, integridade, disponibilidade, controlo de acessos, não repúdio e outras propriedades úteis à empresa, por exemplo, quanto tempo deve a informação ser armazenada).

Na avaliação de um activo serão tidos em conta 3 atributos:

Confidencialidade:

Propriedade que limita o acesso a um activo. Unicamente utilizadores autorizados deverão poder aceder a este.

Na avaliação do activo, ser-lhe-á atribuído um dos 3 níveis de confidencialidade:

Baixo – 1 Ponto Médio – 2 Pontos Alto – 3 Pontos

155 de 201




2012 Página 18

Integridade:

Propriedade que define a integridade de um activo. Isto é, fazendo uso deste atributo, pretende-se que a informação não sofra qualquer tipo de mutação indesejada.

Na avaliação do activo, ser-lhe-á atribuído um dos 3 níveis de integridade:


Disponibilidade:

Propriedade que assegura a disponibilidade de um activo. Deste modo, assegurando este atributo estamos a assumir que determinado activo estará sempre (ou quase sempre) disponível.

Na avaliação do activo, ser-lhe-á atribuído um dos 3 níveis de disponibilidade:


Desta forma, um activo será avaliado da seguinte forma:

Valor de um activo (VA) = Confidencialidade + Integridade + Disponibilidade

Exemplo:

Confidencialidade Integridade Disponibilidade Valor do activo

Baixa Alta Média 1+3+2=6 Média Média Alta 2+2+3=7 Alta Baixa Alta 3+1+3=7

A métrica utilizada no que toca ao valor de um activo é definida pelos seguintes elementos:

Normal – valor entre 1 e 3 pontos

Importante – valor entre 4 e 6 pontos

Muito importante – valor entre 7 e 9

156 de 201




2012 Página 19

4.2 Procedimentos e métricas para avaliação do Risco

Esta fase serve para definir os procedimentos de avaliação do risco, utilizados aquando da avaliação do risco (próxima fase).

Definição de um método a adoptar para a avaliação do risco na empresa. Deve ser usado um método comum de avaliação que seja aplicável ao ISMS da empresa, nos requisitos de segurança da empresa e ainda nos requisitos legais.

Entrada o ND Saída o Como determinar as ameaças

o Fonte de Vulnerabilidades o Documento que indique que tipos de risco e com que níveis serão

aceitáveis para a empresa. o \Deliverables\2 – Plan\ 2012-07-01 Listagem de vulnerabilidades +

Métricas CVSS.xlsx Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Responsável das TI o Administração da empresa – aceitação do risco

Fontes Adicionais o NIST - National Institute of Standards and Technology o NVD - National Vulnerability Database o Diferentes metodologias de avaliação podem ser encontradas em:

ISO/IEC TR 13335-3 o CVSS


A metodologia de avaliação de risco passará pela utilização de procedimentos e ferramentas, que relacionados se traduzem na percepção do risco existente nos activos de informação da organização.

Os passos que constituem a avaliação de risco estão descritos nos pontos abaixo. Estes passos devem ser realizados pela ordem apresentada.

Os principais passos na avaliação do risco são:

1 Identificação e avaliação de riscos 2 Identificação e avaliação de vulnerabilidades 3 Aceitação e priorização (do tratamento) do risco 4 Atribuição de probabilidade de acontecimento 5 Definição da percepção do risco 6 Definição da probabilidade de não-detecção

Devemos definir:

Como são determinadas as ameaças (fontes, pessoas responsáveis) Como são identificadas as vulnerabilidades

157 de 201




2012 Página 20

Uma das fontes mais usadas, conhecidas e confiáveis é a NIST, National Institute of Standards and Technology que fornece gratuitamente acesso a NVD - National Vulnerability Database, uma base de dados actualizada de vulnerabilidades acerca de todo o tipo de activos de informação, com especial atenção ao de TI.

A base de dados de vulnerabilidades poderá ser baseada maioritariamente na NVD da NIST que é informação recente e estruturada sobre grande parte das vulnerabilidades. Ainda assim existe uma grande complexidade para avaliar e construir uma listagem de vulnerabilidades. O número de elementos a avaliar numa vulnerabilidade, para além de serem muitos estão relacionados com um Standard de avaliação de vulnerabilidades chamado CVSS. Este tem elementos específicos e estandardizados e fórmulas de cálculo específicas. No que toca a pontuar e quantificar as vulnerabilidades, tudo é feito de forma automática pela NIST. Foi construída uma calculadora de vulnerabilidades (\Deliverables\2 – Plan\ 2012-07-01 Listagem de vulnerabilidades + Métricas CVSS.xlsx), que efectua automaticamente o cálculo da ameaça de cada vulnerabilidade fornecendo assim uma boa métrica de comparação. Identificação e avaliação de riscos Os riscos estão descritos em bastantes catálogos existentes na internet, mas para exemplo, podemos usar como base de catálogo o documento: Deliverables\2 – Plan\ 2012-07-14 - Listagem de riscos.xlsx

Com a avaliação de riscos pretende-se criar uma relação da existência de um determinado activo, dos riscos que o mesmo corre e as vulnerabilidades que o mesmo tem. Para um bom suporte à evolução do SGSI será necessário manter informação sobre os riscos e as suas fontes que possivelmente podem afectar, ou até mesmo já afectaram a empresa. Para isso existe uma listagem de riscos e dos seus atributos que são armazenados numa lista actualizada ao longo do tempo: Deliverables\2 – Plan\ 2012-07-14 - Listagem de riscos.xlsx

158 de 201




2012 Página 21

5. Risk Assessment

5.1 Avaliação de riscos de segurança da informação

Consiste na identificação e análise de risco (interno e externo) que são significativos ao alcance dos objectivos da empresa.

Entrada o 4.2 Procedimentos e métricas para avaliação do Risco o Dimensão da Vulnerabilidade Deliverables\2 – Plan\ 2012-07-01 Dimensão da

vulnerabilidade.docx Deliverables\2 – Plan\ 2012-07-14 - Listagem de riscos

Saída o Identificar e avaliar as formas disponíveis que existem para tratar o risco, assim como priorizar o tratamento de determinados riscos Deliverables\2 – Plan\2012-07-14 - Priorização do tratamento de

risco.xlsx Recursos Envolvidos o Responsáveis dos Sistemas de informação,

o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF o Administração



Esta avaliação deve levar em consideração a severidade do risco, a frequência com que estes ocorrem e o seu impacto. Definição de como a empresa administrará tais riscos. 1

Proceder à avaliação dos riscos existentes, deve ser feito através de um workshop do grupo de segurança do ISMS que através de um “Brain Storming” vão avaliar a severidade dos riscos a que a informação está sujeita.

Necessário também identificar e avaliar as formas disponíveis que existem para tratar o risco, evitar o risco, reduzir seu impacto, ou ainda, transferir o risco para outro local. Esta identificação irá servir para o plano de tratamento de risco:

a) Aceitar um Risco – por outras palavras a administração aceita o risco, comparando o impacto que este pode trazer com o investimento necessário para providenciar controlos necessários à sua mitigação.

b) Reduzir – aplicar um controlo ou um conjunto de controlos que visam mitigar o risco para um nível aceitável.

c) Evitar o risco – não executar os processos de negócio que estão associados a determinado risco.

1 Rildo (@rildosan) Santos, “Gestão De Risco e Controle Interno Com COSO.”

159 de 201




2012 Página 22

d) Transferir – transferir o risco para outra organização, por exemplo, criar um contrato de seguro sobre o risco, ou criar contractos de entendimento com outros parceiros de negócio.

Aceitação de risco e priorização do risco A relação dos activos com os riscos e vulnerabilidades permitirá que se verifique o nível de aceitação de uma dessas relações. Existe um conjunto de elementos que serão avaliados e relacionados. Atribuição de probabilidade de acontecimento Neste parâmetro o avaliador do risco tem que através da sua experiência e com recolha de outras experiências sobre a determinada vulnerabilidade, definir com que probabilidade um risco poderá acontecer. Definição da percepção do risco Neste parâmetro o avaliador do risco terá que através da sua experiência e neste caso principalmente através da sua percepção sobre o valor do sistema afectado, definir qual será o valor do risco que o activo alvo corre e qual o possível impacto gerado sobre o mesmo. Definição da probabilidade de não detecção Neste parâmetro o avaliador do risco terá que dar a sua avaliação pessoal tendo em conta a sua percepção do risco. Tem de estimar a probabilidade de ocorrência destas falhas derivadas deste risco, e qual é a probabilidade de estas não serem detectadas.

Dimensão do risco Um activo está exposto aos mais variados riscos, e para que se saiba a que riscos este está exposto, dever-se-á fazer uma análise sobre os riscos e sobre as vulnerabilidades que surgem com estes. O enquadramento dos elementos acima referidos tem que ser quantificado para efeitos de gestão de segurança. A avaliação dos riscos e vulnerabilidades poderá ser realizada através de uma escala de classificação. Níveis de classificação:

Baixa - 1 Ponto Média - 2 Pontos Alta - 3 Pontos

Dimensão final do risco (DFR) = Valor do activo * Dimensão do risco * Dimensão da vulnerabilidade

Exemplo:

Valor do ativo

Dimensão do risco

Dimensão da vulnerabilidade

Dimensão final do risco

6 3 3 6 * 3 * 3 = 54

7 1 2 7 * 1 * 2 = 14

7 2 1 7 * 2 * 1 = 14

160 de 201




2012 Página 23

A métrica utilizada no que toca à dimensão final do risco sobre um activo é de caracter qualitativo e é definida pelos seguintes elementos:

Risco pouco perigoso – valor entre 1 e 27 pontos

Risco perigoso – valor entre 28 e 54 pontos

Risco muito perigoso – valor entre 55 e 81 pontos

5.2 Controlos e objectivos dos controlos

As opções para o tratamento do risco devem ser identificadas, assim como devem ser seleccionados os controlos apropriados para esse risco de acordo com as opções de tratamento.

Entrada o ND Saída o Uma lista dos controlos a usar e os seus objectivos

o O RTP – Risk treatment Plan – Plano de tratamento de risco: \Deliverables\2 – Plan\2012-07-10 RTP Risk Treatment

plan(PLAN).xlsx I. Descrição da relação estre os riscos e a opção para o seu

tratamento Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o MISF

Fontes Adicionais o ISO/IEC 27001 4.2.1 f) o ISO/IEC 27001 ANEXO A


Nesta fase é importante que se estabeleça uma relação entre os riscos e as opções tomadas para o seu tratamento que logo por si irá ser como tratamento de riscos sumário.

As opções possíveis para o tratamento de risco encontram-se enumeradas na ISO/IEC 27001 4.2.1 f).

O Anexo A da ISO 27001 “Control objectives and controls” é uma boa ferramenta para seleccionar os controlos e objectivos do controlo para tratamento do risco. Caso os controlos sugeridos pela norma não sejam os apropriados, devem ser especificados novos controlos e objectivos do controlo para determinado risco. É muito importante demonstrar como os controlos escolhidos vão mitigar os riscos - ISO/IEC 27001 ANEXO A.

Deve ser criada uma lista de controlos e objectivos aplicados a cada risco, quer para facilitar o processo futuro de auditoria, quer para melhorar o ISMS em causa.

Deve ser levado em atenção que os controlos irão possuir informação sensível. Deverá ser tratada como informação confidencial.

161 de 201




2012 Página 24

O plano de tratamento de riscos é um documento vivo. Quando novos riscos são identificados, ou os antigos são alterados, o plano de tratamento de risco precisa ser actualizado.

5.3 Preparar SOA – Statement of Applicability

Nesta fase, vamos criar um documento que identifique os controlos escolhidos para o SGSI, e explicar como e porque são apropriados.

Entrada o RTP – Risk treatment Plan – Plano de tratamento de risco Saída o SOA – Statement of Applicability - documento que identifique os

controlos escolhidos para o SGSI Descrição entre os riscos e os controlos/objectivos de controlo

seleccionados Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Responsável das TI



O SOA é derivado a partir da saída do plano de tratamento de risco e deve relacionar directamente os controlos seleccionados com os riscos destinados a mitigar. Tem de justificar a escolha do controlo seja por motivos legais, contratuais ou da organização interna. Deve fazer referência às políticas, procedimentos, outros documentos ou sistemas através dos quais o controlo seleccionado se irá realmente manifestar.

Também é boa prática documentar uma justificação para a exclusão dos controlos não seleccionados.

Em caso de futura certificação, os auditores externos irão pegar neste documento e averiguar a empresa, e a forma como os controlos estão aplicados. É por norma o documento central para uma auditoria “on-site”.

Note-se que um bom documento de SOA irá reduzir o número de outros documentos e mesmo poupar tempo. Por exemplo, a documentação de determinado controlo cuja descrição seja breve, se for executada no SOA irá eliminar a necessidade da criação de mais um documento que descreva esse mesmo controlo.

162 de 201




2012 Página 25

III. (DO)

6. Implementar e Operar ISMS

6.1 Tratamento de Risco

Entrada o RTP Saída o RTP – Implementado Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Chefes de departamento o Donos dos Activos o Responsável das TI



6.2 Implementação de controlos Implementação dos controlos seleccionados para cumprirem os seus objectivos

Definir uma forma de medir a eficácia dos controlos

Entrada o Controlos e objectivos dos Controlos o RTP

Saída o Documento que relate as métricas usadas para medir a eficácia dos controlos

o Fase de Implementação dos controlos o RTP – Implementado

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o Chefes de departamento o Donos dos Activos

Fontes Adicionais o ISO 27004 define um método de medição o Lista completa dos controlos implementados em conformidade com

o anexo A da ISO 27001


Para medir a eficácia dos controlos necessitamos de criar métricas de boa qualidade para cada um deles. Essas métricas terão de ter as seguintes características: (International Function Point Users Group, 2002)

163 de 201




2012 Página 26

1. Têm de ser universais, podendo ser aplicadas a tudo, não importando arquitectura,

interface ou condições. Uma métrica é universal se possuir um conjunto de variáveis que possam ser aplicadas a qualquer tipo de ISMS.

2. Deve produzir resultados significativos no que diz respeito à questão que procura medir, daí a importância de definir um conjunto de métricas que são úteis para o grupo de avaliação para obter o que se realmente quer saber, sem elaboração e sem a necessidade de mais informações.

3. Devem ser exactas e representar o que os gestores de segurança da informação

realmente querem e precisam saber. A métrica não deve desviar a atenção para outro aspecto que não seja o propósito para o qual foi concebido. Além disso, deve retractar os resultados, evitando desvios, tanto pelo grupo responsável pela medição, tanto pelos “tomadores de decisão”. A obtenção de resultados deve ser exequível, isto é, deve ser possível a obtenção dos dados e variáveis envolvidas na medição, de modo a optimizar os recursos e evitar o desperdício de tempo, esforço e dinheiro em medições impossíveis de executar.

4. Deve ser reprodutível, para que pessoas diferentes em momentos diferentes possam fazer a mesma medição. É vital a métrica ser consistentemente repetível, independentemente de quem fez a medição ou o momento no tempo em que a medição teve lugar. As condições de medição têm de ser preservadas.

5. Deve ser objectiva, isto é, não deve estar vinculada a factores variáveis, tais como o conhecimento de pessoas, a capacidade de memorizar, a percepção do produto, entre outros, evitando os factores subjectivos que poderiam distorcer os resultados.

6. Deve ser imparcial. A métrica deve ser justa e equitativa, deve ter um conjunto claramente definido de valores com que se pode determinar se o resultado é aceitável ou não, e para saber o nível e / ou a tendência de atributos do sistema.

A ISO 27004 define um método de medição com os seguintes passos: i. Lista completa dos controlos implementados em conformidade com o anexo A da ISO

27001 ii. Método de medição de atributos associados a controlos iii. Base de Dados de medida para os atributos de controlo iv. Produção do indicador

164 de 201




2012 Página 27

6.3 Segurança de informação organizacional Nesta fase devemos realinhar os papéis e responsabilidades com o tratamento de risco. O design organizacional deve procurar ser desenvolvido e integrado com o SGSI.

Entrada o ND Saída o Desenho final da estrutura organizacional para segurança da

informação o Papeis e responsabilidades, “report lines”(a quem relatar

acontecimentos) Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa o Chefes de departamento



A estrutura organizacional concebida para o ISMS deve reflectir as actividades de implementação e operação do ISMS, bem como, abordar, por exemplo, os métodos de monitorização e registo como uma parte das operações do ISMS. Por conseguinte, a estrutura para as operações do ISMS deve ser concebida com base na implementação prevista do ISMS, considerando o seguinte:

a) Serão todos os papéis da implementação do ISMS necessários para as operações do SGSI?

b) Os papéis definidos são diferentes daqueles definidos para a implementação do ISMS? c) Que papéis devem ser adicionados para a implementação do ISMS?

Por exemplo, as seguintes funções podem ser adicionadas para as operações do ISMS: a) Alguém responsável pelas operações de segurança da informação em cada

departamento b) Alguém responsável por medir o ISMS em cada departamento

6.4 Manual da política de segurança da informação A política de segurança da informação documenta a posição estratégica da organização em relação aos objectivos de segurança da informação em toda a organização.

Entrada o ND Saída o Política proposta (com a versão e data)

o Resumo de todas as políticas, métodos e procedimentos de segurança da organização num único documento.

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF


165 de 201




2012 Página 28


Fornece um método para as organizações estabelecerem os procedimentos e políticas necessárias para a protecção da informação e activos da organização. Resume também todas as políticas, métodos e procedimentos de segurança da organização num único documento.

Pode haver diferentes interpretações e exigências em relação à grandeza real do manual. Deve ser suficientemente resumido, para que o staff da empresa seja capaz de entender a intenção do mesmo.

A política proposta (com a versão e data) deve ser verificada e estabelecida dentro da organização pelo gestor operacional. Após o estabelecimento dentro do grupo de gestão, o gestor operacional aprova a política de segurança da informação. Em seguida, é comunicada a todos os membros da organização de tal forma que seja relevante / importante, acessível e compreensível para os seus leitores.

166 de 201




2012 Página 29

6.5 Desenvolver as normas e procedimentos de segurança da informação Para fornecer uma boa base de segurança à organização devem ser seguidas as normas de segurança e as questões legais aplicáveis à empresa.

Entrada o Normas e procedimentos de segurança Saída o Documento que indique, por departamento os procedimentos e

rotinas a seguir pelos funcionários para que não ponham em risco a segurança da informação.

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF o Representantes dos diferentes departamentos da organização o Responsáveis dos Sistemas de informação o Os proprietários do processo das áreas estratégicas e operacionais.


Abordagem Recomendada Os representantes de diferentes departamentos da organização devem participar no processo de desenvolvimento das regras e processos para a organização. Por exemplo, as seguintes funções podem ser incluídas:

a) Os gestores de segurança da informação, b) Os representantes da segurança física, c) Responsáveis dos Sistemas de informação, d) Os proprietários do processo das áreas estratégicas e operacionais.

Sugere-se manter o grupo editorial (das políticas de segurança) tão pequeno quanto possível, com a opção de nomear especialistas para a equipa, numa base temporária, consoante e quando necessário. Cada representante deve colaborar activamente com a sua própria área da organização para prestar apoio operacional “sem barreiras”. Futuramente irá facilitar um aperfeiçoamento na forma dos procedimentos e rotinas a nível operacional. As normas de segurança e os procedimentos devem ser usados como base para a concepção de procedimentos técnicos e operacionais mais detalhados. Documentação relevante e actualizada deve ser fornecida para cada membro da equipa dentro do âmbito. Os padrões de segurança da informação e os procedimentos devem ser aplicados a toda a organização e tornados claros, a que funções, sistemas e áreas são cobertas. A primeira versão deve ser produzida em tempo útil.

167 de 201




2012 Página 30

6.6 Formação e sensibilização Desenvolver um programa de formação, sensibilização e educação em segurança da informação.

Entrada o ND Saída o Programa de formação para a segurança Recursos Envolvidos o Recursos Humanos

o Responsáveis dos Sistemas de informação, o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa

Fontes Adicionais o ISO/IEC 27003 – 9.4.2

Abordagem Recomendada A gestão do SGSI em conjunto com os recursos humanos são responsáveis pela realização de formações e acções de sensibilização para garantir que todos os funcionários que estão alocados tenham um papel claramente definido e competências para executar as tarefas necessárias. Idealmente, o conteúdo da formação realizada deve ajudar todo o pessoal a estar atento e compreender o significado e a importância das actividades de segurança da informação em que estão envolvidos, e perceber como podem contribuir para alcançar os objectivos do SGSI. Um Programa de formação para a segurança deve garantir que os registos de formações e sensibilizações são gerados. Esses registos devem ser regularmente revistos para assegurar que todos os funcionários receberam a formação que necessitam. Deve existir um papel no SGSI responsável por este processo. O material de formação em segurança da informação deve ser projectado para combinar com os outros materiais de formação utilizados pela organização, especialmente de formações prestadas aos utilizadores de sistemas de TI. Formações em aspectos relevantes da segurança da informação devem idealmente ser integradas em todos os cursos dos utilizadores de TI. Podem ser pensados diferentes níveis de formação para diferentes tipos de utilizadores, utilizadores que tenham mais contacto com informação importante, deverão ter um nível de formação superior. O material de formação em segurança da informação deve conter no mínimo os seguintes pontos, conforme apropriado para o público-alvo:

a) Riscos e ameaças à segurança da informação b) Regras Básicas da segurança da informação c) Definição clara de incidente de segurança: orientação sobre como pode ser identificado e

como deve ser tratado e relatado d) Política de segurança da informação, normas e procedimentos da organização e) Responsabilidades e os canais de informação relativas à segurança da informação na

organização f) Orientação sobre como ajudar a melhorar a segurança da informação g) Orientação sobre incidentes de segurança da informação e como os relatar h) Onde obter mais informações.

168 de 201




2012 Página 31

6.7 Gerir operações e recursos do ISMS Esta fase consiste em “ligar os motores” do ISMS, chegamos à fase de operação e implementação:

I. Gerir as operações do ISMS II. Gerir os recursos do ISMS

III. Implementar os controlos capazes de detectar prontamente os eventos de segurança e que respondam convenientemente aos incidentes.

Entrada o Lista de Controlos

o Documentação geral do ISMS Saída o Desenho do ICT (information communication technology) Recursos Envolvidos o Responsáveis dos Sistemas de informação,

o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o Toda a Organização

Fontes Adicionais o ISO/IEC 27001 – 5.2 o ISO/IEC 27003 – 9.3


Nesta fase interessa também desenhar o ICT (information communication technology) e o ambiente de segurança física da empresa. Deve ser documentado para cada controlo integrante do ISMS:

a) Nome da pessoa responsável pela implementação de um controlo b) A prioridade do controlo a ser implementado c) Tarefas e actividades necessárias à implementação dos controlos d) Declaração que indique uma margem temporal para a implementação dos controlos e) Pessoa a que deve ser reportado a finalização da implementação de cada controlo f) Recursos de implementação (mão de obra, requisitos de espaço, custos, etc…)

169 de 201




2012 Página 32

IV. (CHECK)

7. Monitorizar e Rever o ISMS

7.1 Monitorizar e rever os procedimentos Executar uma revisão e monitorização aos procedimentos do SGSI

Entrada o Documentos de todo o SGSI Saída o Relatório de erros ou falhas encontradas Recursos Envolvidos o Responsáveis dos Sistemas de informação,

o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa



Efectuar Revisão Para:

a) Prontamente detectar erros nos resultados de processamento b) Identificar de imediato tentativas/sucessos de violações de segurança e incidentes c) Permitir à gestão determinar se as actividades de segurança efectuada por pessoas ou

implementadas pelas tecnologias de informação estão a resultar como o esperado. d) Ajudar a detectar eventos de segurança e, assim, prevenir incidentes de segurança

através da utilização de indicadores e) Determinar se as acções tomadas para resolver uma falha de segurança foram eficazes

170 de 201




2012 Página 33

7.2 Auditorias Internas As Auditorias Internas são um instrumento útil às análises críticas de gestão, para além de fornecerem os pressupostos para auto declarações de conformidade com a norma, em todas as áreas funcionais, simplificando a tarefa.

Entrada o SoA o PTR

Saída o Relatórios de Auditoria o Abertura de Não Conformidades, caso se aplique o Acções Correctivas e Preventivas

Recursos Envolvidos o Responsáveis dos Sistemas de informação, o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF

Fontes Adicionais o ISO/IEC 27001 – 6


Tendo em conta os resultados das auditorias vamos realizar análises periódicas da eficácia do ISMS (incluindo a política de reuniões do ISMS, os objectivos, e revisão de controlos de segurança).

A organização deve conduzir auditorias internas ao SGSI em intervalos planeados para determinar se os objectivos de controlo, controlos, processos e procedimentos do SGSI:

a) Estão em conformidade com os requisitos da norma ou leis aplicáveis b) Estão em conformidade com os requisitos de segurança da informação identificados c) Estão eficazmente implementados e mantidos, e se estão com o desempenho esperado.

171 de 201




2012 Página 34

7.3 Auditoria Externa Nesta fase vamos contactar uma empresa de auditorias externa, para submeter o nosso ISMS aos olhos críticos de um especialista e avaliar seriamente o desempenho do nosso ISMS

Entrada o ND Saída o Agendamento de Reuniões de Auditoria Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa Fontes Adicionais o ND


Contactar um auditor externo, por exemplo, em Portugal:

DQA - http://www.dqa.pt/default.aspx

SGS - http://www.pt.sgs.com/pt/home_pt_v2?

Integrity - http://www.integrity.pt

BUREAU VERITAS - http://www.bureauveritas.pt/

7.4 Medir eficácia dos controlos

Os indicadores devem expressar o nível actual de segurança em relação ao nível desejado de segurança. O objectivo do indicador é reflectir o nível de exposição ao risco pelo estado de implementação actual de um controlo.2

Entrada o Controlos Aplicados o Método de avaliação de risco – Definido numa fase anterior

Saída o Documento que indique a eficácia e eficiência dos controlos Recursos Envolvidos o Responsáveis dos Sistemas de informação,

o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF

Fontes Adicionais o The SANS Institute, “Measuring Controls”


Vamos então aplicar os indicadores que desenhamos numa fase anterior “Definir um método de avaliação de risco” e verificar se os requisitos de segurança estão a ser cumpridos.

2 The SANS Institute, “. Measuring Controls,” chap. 5.

172 de 201




2012 Página 35

Mediante uma diversidade de métricas, devemos escolher as mais adequadas a cada caso. Algumas podem ser utilizadas (mas não se limitam a estas) para medir a eficácia, eficiência, tempo, produtividade, qualidade, performance e confiabilidade do SGSI.

Como exemplo de acompanhamento das métricas, podemos usar:

I. Benchmarking de pesquisas sobre segurança da informação; II. Resultados de pesquisas internas de avaliação do SGSI;

III. Gestão de incidentes de segurança.

Independentemente da diversidade dos tipos de métricas existentes, a organização deve seleccionar aquelas que lhe forneçam informações relevantes do seu SGSI, conforme citado anteriormente. A seguir, temos uma tabela com as informações mínimas necessárias, para se criar um plano de métricas.

Passo a passo para o estabelecimento de métricas:

Métrica Este campo deve conter o nome da métrica e a descrição da escala que será usada.

Âmbito da métrica Este campo descreve o que deve ser medido. Por exemplo: o processo ou controlos do ISMS e que partes do processo ou controlos.

Propósito e objectivo Este campo deve definir o propósito da métrica, quais as metas e objectivos que devem ser atingidos

Método de medição Este campo deve descrever como a medição será realizada, por exemplo, usando cálculos, fórmula ou percentagens

Frequência da medição

Este campo deve descrever a periodicidade da medição. Por exemplo: mensal, semanal, diário etc.

Origem dos dados e procedimento de colecta

Este campo deve definir onde os dados serão recolhidos e que métodos são usados para a colecta.

Indicadores Este campo deve conter os indicadores usados para optimizar a métrica e definir o seu propósito e como eles são entendidos e podem ser aplicados.

Data da medição e responsável

Este campo deve descrever a data da medição e a pessoa responsável por esta acção.

Nível da efectividade alcançada

Este campo deve conter o resultado e a data da medição.

Causas do não-cumprimento

Este campo deve conter as causas do não-cumprimento dos objectivos, indicadores etc.

Fonte: “Measuring the effectiveness of your ISMS”.

173 de 201




2012 Página 36

7.5 Rever Avaliação do Risco

Nesta fase é necessário rever as avaliações de risco.

Entrada o Controlos Aplicados o Método de avaliação de risco – Definido numa fase anterior

Saída o Documento que indique a eficácia e eficiência dos controlos Recursos Envolvidos o Responsáveis dos Sistemas de informação,

o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa o MISF o Administração



Esta revisão deve ser repetida em intervalos planeados de tempo, revendo também os riscos residuais e os níveis aceitáveis de riscos identificados, tendo em conta as alterações na:

a) Organização b) Tecnologia c) Objectivos e processos de negócios d) Ameaças identificadas e) Eficácia dos controlos implementados f) Eventos externos, como mudanças no ambiente legal ou regulamentar e obrigações

contratuais.

174 de 201




2012 Página 37

V. (ACT)

8. Manter e melhorar o ISMS

8.1 Melhorar ISMS

Entrada o ND Saída o Documento para registo de não conformidades

o Criar um processo de acções correctivas e preventivas o Documentar as melhorias implementadas em casa fase

Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa o Responsáveis pela segurança da informação na empresa

Fontes Adicionais o “Exemplo de Processo”


a. Implementar as melhorias identificadas - devemos assegurar a melhoria contínua de todos os elementos do sistema de gestão da segurança da informação.

b. Desenvolver o procedimento de medidas correctivas - estabelecer um procedimento de acções correctivas para evitar a repetição de não-conformidades.

c. Desenvolver o procedimento de medidas preventivas - Acção de eliminação das causas de uma potencial não-conformidade.

d. Implementar melhorias às falhas encontradas na fase de verificação e. Comunicar às partes interessadas as acções preventivas e correctivas f. Correcções Finais

Exemplo de processo:

1. Registar a não-conformidade no formato adequado, escrevendo a data em que a ocorrência se verificou.

2. Indicar o ponto da norma que não está a ser cumprida, e descrever a não-conformidade.

3. Entregar a solicitação aos responsáveis do ISMS para a análise de causas do que causou o incumprimento junto do responsável pela área em causa, tendo este dois dias úteis para a apresentação de uma causa.

175 de 201




2012 Página 38

4. Determinar as acções necessárias para eliminar a não-conformidade apresentada, as quais são anotadas na solicitação inicial, declarando a data de início e de encerramento das actividades. Na entrega do pedido será atribuído um número de controlo de acção correctiva.

5. O número sequencial é gerado e gravado no formato adequado e de seguida é entregue uma cópia do pedido para o responsável de área.

6. É objectivamente verificada a eficácia das acções e como é levada a cabo a acção, se for efectiva fecha-se a solicitação registando a data.

7. Se as acções não forem eficazes, voltar ao passo inicial.

Gerar um relatório mensal da situação das acções correctivas e / ou preventivas e entregar uma cópia à administração.

9. Revisão de conformidade

9.1 Completar uma revisão de conformidade com a Checklist da ISO 27003 Nesta fase vamos verificar se não está nada em falta ou desviado das fases de implementação referidas na checklist fornecida na norma ISO 27003.

Entrada o Todo o SGSI e todas as fases anteriores Saída o Documento que indique a existência de algum desvio da norma, no

processo de implementação. Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa Fontes Adicionais o ISO 27003


Deve ser efectuado um seguimento fase a fase da implementação da norma na empresa, verificando se está tudo de acordo com o sugerido pela ISO / IEC através da checklist fornecida na ISO 27003.

I. Listagem de todas as actividades requeridas para criar e implementar um ISMS II. Dar suporte para monitorizar o progresso de implementação do ISMS

III. Mapear as actividades de implementação do ISMS com os respectivos requisitos da ISO 27001.

176 de 201




2012 Página 39

9.2 Corrigir as não conformidades

Entrada o Não conformidades abertas ou por resolver até ao momento. Saída o Acções Correctivas Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa Fontes Adicionais o ND


Devem ser analisadas as causas que estão nas origens das não conformidades, para que seja possível arranjar uma forma destas não se voltem a repetir.

Devem ser abertas acções correctivas para resolver ou mitigar os problemas descobertos na não conformidade.

Existem dois passos simples para corrigir uma não conformidade:3

I. Fornecer informações aos funcionários sobre o porquê de uma tarefa, processo ou protocolo ser importante. O PORQUÊ tem quatro fases, e todas as quatro devem ser explicitamente explicadas à equipa durante o processo de formação:

a. Fornecer uma descrição clara do benefício para a organização de “fazer bem feito”;

b. Fornecer uma descrição clara dos danos para a organização de “fazer mal feito”; c. Fornecer uma descrição detalhada do benefício ao funcionário de fazer

correctamente; d. Fornecer uma descrição das consequências para o funcionário de o fazer de

forma errada.

II. Quando queremos que as pessoas mudem, com o propósito de resolver problemas melhorando a qualidade ou a segurança, devemos adicionar ao seu processo de formação:

a. Explicação do problema em pormenor; b. Explicação do objectivo em detalhe; c. Discussão detalhada dos passos específicos para a solução; d. Explicar os benefícios do sucesso (benefício para eles, e para a organização).

Ambos os passos são muito simples, mas muitas vezes não são cumpridos. Muitas vezes, a solução mais eficaz é a solução mais simples.

3 Harden, “Dois Passos Simples Para Corrigir Uma Não-conformidade Intencional.”

177 de 201




2012 Página 40

10. Auditoria Externa ao ISMS

Entrada o Toda a documentação chave Saída o Acções Correctivas Recursos Envolvidos o Responsáveis pela implementação da ISO 27001 na empresa

o Responsáveis pela segurança da informação na empresa Fontes Adicionais o ND


A ISO/IEC 27001 geralmente envolve um processo de três fases de auditoria externa:

Fase 1

É uma análise preliminar informal do ISMS, por exemplo, a verificação da existência e plenitude da documentação chave, bem como a organização política da segurança da informação, Declaração de Aplicabilidade (SoA) e Plano de Tratamento de Risco (RTP). Esta fase serve para familiarizar os auditores com a organização e vice-versa.

Fase 2

É uma auditoria de conformidade mais detalhada e formal, testar o ISMS em relação aos requisitos especificados na norma ISO / IEC 27001. Os auditores vão procurar provas para confirmar que o sistema de gestão foi devidamente projectado e implementado, e está de fato em operação (por exemplo, confirmando que um grupo de segurança ou órgão de gestão semelhante se reúne regularmente para supervisionar o ISMS). As auditorias de certificação são geralmente conduzidas pelos “27001 ISO / IEC Lead Auditors”.

Passando esta fase, se os resultados do ISMS estiverem em conformidade, a empresa estará certificada com a ISO / IEC 27001.

Fase 3

Esta fase envolve o acompanhamento de revisões ou auditorias para confirmar que a organização se mantem em conformidade com a norma. A manutenção da certificação requer auditorias de reavaliação periódica para confirmar que o ISMS continua a operar como especificado. Estas auditorias de manutenção devem acontecer pelo menos uma vez por ano, mas (por acordo com a administração) são sempre realizadas com mais frequência, especialmente enquanto o ISMS ainda está em fase de amadurecimento.

178 de 201




2012 Página 41

VI. Definições e Acrónimos

ISMS (ou SGSI) – information security management system (ou Sistema de Gestão de Segurança da Informação)

Checklist – Lista de controlo

ISO - International Organization for Standardization

IEC - International Electrotechnical Commission

ISO 27001 – ISO / IEC Norma 27001

NIST - National Institute of Standards and Technology

NVD - National Vulnerability Database

Benchmarking – Medição de desempenho

179 de 201




2012 Página 42

VII. Referências Harden, Steve. “Dois Passos Simples Para Corrigir Uma Não-conformidade Intencional”.

http://pacientesseguros.blogspot.pt/2011/05/dois-passos-simples-para-corrigir-uma.html, n.d.

Rildo (@rildosan) Santos. “Gestão De Risco e Controle Interno Com COSO”, August 4, 2010. http://www.slideshare.net/Ridlo/gesto-de-risco-e-controle-interno-com-coso.

The SANS Institute. “. Measuring Controls”, n.d.

180 de 201


Anexo 11 - Listagem e classificação de Ativos

181 de 201

ISA

V002

03-04-2012

ID Categoria Tipo OSI Proprietário C I D Valor do Activo0001 Serviços Autenticação de Utilizadores L7 Rafael RS 3 3 3 90002 Serviços Serviços de Rede L7 Ariadne P 1 3 3 70003 Serviços Serviços de Rede L7 Rafael RS 1 1 1 30004 Serviços Serviços de Rede L7 Ariadne P 1 2 2 50005 Serviços Serviços WEB L7 Ariadne P 2 2 1 50006 Serviços Serviços de Rede L7 Ariadne P 1 2 3 60007 Serviços Serviços de segurança L7 Rafael RS 3 3 2 80008 Serviços Anty-Spam/Spyware L7 Ariadne P 1 1 2 40009 Serviços Firewall L7 Rafael RS 1 2 3 60010 Rede Firewall L5 Rafael RS 1 2 3 60011 Rede Firewall L5 Ariadne P 1 2 3 60012 Rede Load Balancer's L7 Rafael RS 1 2 3 60013 Serviços Tele-trabalho L5 Rafael RS 2 1 2 50014 Rede Linhas dedicadas L1 Ariadne P 2 1 3 60015 Rede Linhas dedicadas L1 Ariadne P 2 1 3 60016 Rede Linhas dedicadas L1 Ariadne P 2 1 1 40017 Rede Linhas dedicadas L1 Ariadne P 2 1 1 40018 Rede Routers/Switchs/Ap's L3 palmeida 2 3 3 80019 Rede Routers/Switchs/Ap's L2 palmeida 2 3 3 80020 Rede Routers/Switchs/Ap's L2 palmeida 2 3 3 80021 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30022 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30023 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 2 40024 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 2 40025 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 2 40026 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 2 4

Interna

Interna

SW6 - TechInterna

Interna SW7 - Produção

Interna SW8 - Admin

Pública

Pública

Pública

Interna

Interna

Interna SW5 - Tech

Responsável:


Data:

ID: Estado: Em edição

Firewall 3 - ISP Fibra + Router

DescriçãoAutenticação AD WS2008

DNS Externo

DNS Interno

DHCP

Webmail

NTP Server

RFID Access Control Server

Interna

SW Core + Router

SW1 - Datacenter Clientes

SW2 - Datacenter Clientes

SW3 - Utilizadores

SW4 - Utilizadores

Firewall 4 + LoadBalancer - ISP + Router

VPN

ISP Fibra 1

XDSL ISP

ISP Coax

ISP Fibra 2

Listagem e classificação de Ativos

Firewall 1 - ISP Coax + RouterPública

Pública

Pública

Pública

Pública

Pública

Interna

Interna

Interna ESET

Firewall 2 - ISP Fibra + Router

ClassificaçãoInterna

Pública

Interna

Interna

Pública

Coimbra

RRS

182 de 201

0027 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30028 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30029 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30030 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30031 Rede Routers/Switchs/Ap's L2 Rafael RS 1 1 1 30032 Rede Routers/Switchs/Ap's L2 Rafael RS 3 3 1 70033 Rede Routers/Switchs/Ap's L2 Rafael RS 3 3 1 70034 Rede Routers/Switchs/Ap's L2 Rafael RS 3 3 1 70035 Rede Linhas dedicadas L1 Ariadne P 3 2 3 80036 Rede Linhas dedicadas L1 Ariadne P 3 2 2 70037 Rede PABx/Voip L7 Ariadne P 2 2 2 60038 Rede PABx/Voip L7 Rafael RS 1 1 2 40039 Hardware Desktop L7 bsantos 2 2 2 60040 Hardware Laptop L7 dsousa 3 2 2 70041 Hardware Impressoras/Faxes L7 dsousa 2 1 1 40042 Hardware Impressoras/Faxes L7 Rafael RS 1 1 2 40043 Hardware Modem's L7 Rafael RS 3 2 3 80044 Hardware Modem's L7 Rafael RS 3 2 3 80045 Hardware Modem's L7 Rafael RS 3 2 3 80046 Hardware Modem's L7 Rafael RS 3 2 3 80047 Hardware Modem's L7 Rafael RS 3 2 3 80048 Hardware Modem's L7 Rafael RS 3 2 3 80049 Serviços Serviços de Cloud L7 Ariadne P 3 2 3 80050 Serviços Serviços de Cloud L7 Ariadne P 3 2 3 80051 Serviços Serviços de Cloud L7 Ariadne P 3 2 3 80052 Infraestrutura DataCenter's L1 Ariadne P 3 1 3 70053 Infraestrutura DataCenter's L1 Ariadne P 3 1 3 70054 Suporte Energia L1 Ariadne P 3 3 3 90055 Suporte Energia L1 Ariadne P 1 3 3 70056 Suporte Energia L1 Ariadne P 1 3 3 70057 Suporte Energia L1 Ariadne P 1 3 3 70058 Suporte Energia L1 Ariadne P 1 3 3 70059 Suporte HVAC L1 Ariadne P 1 3 3 70060 Suporte HVAC L1 Ariadne P 1 3 3 70061 Suporte HVAC L1 Ariadne P 1 3 3 70062 Suporte HVAC L1 Ariadne P 1 3 3 70063 Software Sistemas Operativos L7 Ariadne P 1 2 3 6Interna Windows Server 2000

Interna AR Condicionado 2 - Datacenter Clientes - Backup

Interna AR Condicionado 3 - Datacenter Clientes - Principal

Interna AR Condicionado 4 - Datacenter Clientes - Backup

Interna UPS 3 - Datacenter Clientes 10KVA

Interna UPS 4 - Datacenter Comunicações 10KVA

Interna AR Condicionado 1 - Datacenter Clientes - Principal

Interna Linha dedicada EDP



Interna SMSCenter ISP3

Interna Datacenter Comunicações

Interna Datacenter Clientes

Interna Modem Dados Cliente6

Interna SMSCenter ISP

Interna SMSCenter ISP 2




Interna Fax



Interna 70 Desktops

Interna 100 Laptops

Interna Impressoras x10

Interna Fibra Core ISA - Utilizadores

Interna Voip Server

Interna Telefones Voip x 40

Interna AP2

Interna AP3

Interna Fibra Core ISA - Clientes

Interna SW12 - Utilizadores


Interna AP1

Interna SW9- Intellicare



183 de 201

0064 Software Sistemas Operativos L7 Ariadne P 1 2 3 60065 Software Sistemas Operativos L7 Ariadne P 1 2 3 60066 Software Sistemas Operativos L7 Ariadne P 1 2 3 60067 Software Bases de Dados L7 Ariadne P 3 3 3 90068 Software Bases de Dados L7 Ariadne P 3 3 3 90069 Software Bases de Dados L7 Ariadne P 3 3 3 90070 Software Aplicações L7 Ariadne P 2 3 3 80071 Software Aplicações L7 Ariadne P 1 3 3 70072 Serviços Serviços de Rede L7 Ariadne P 1 2 2 50073 Serviços Serviços de Rede L7 Ariadne P 3 3 3 90074 Serviços Serviços WEB L7 Ariadne P 2 2 2 60075 Serviços Serviços WEB L7 Ariadne P 2 2 2 6Pública Apache WebServer

Pública FTP SERVER

Pública SFTP SERVER

Pública IIS WebServer

Interna SQL SERVER 2008 R2

Interna Exchange Server

Interna Hyper V Server

Interna Windows Server 2008 R2

Interna SQL SERVER 2005

Interna SQL SERVER 2008

Interna Windows Server 2003

Interna Windows Server 2008

184 de 201


102

Anexo 12 - MSTIS Proposta de Projeto

185 de 201

Mestrado em Sistemas e Tecnologias da Informação para a Saúde Instituto Politécnico de Coimbra

Escola Superior de Tecnologia da Saúde de Coimbra – Instituto Superior de Engenharia de Coimbra

Página 1 de 3 Proposta de Projecto – Modelo V1

Aprovado em reunião da Comissão Coordenadora do Mestrado ___/___/____

Projecto de dissertação/projecto

Mestrado: Sistemas e Tecnologias da Informação para a Saúde

Edição: 2010 / 2012

TÍTULO: Estágio – Auditoria de Segurança: Segurança de dados ALUNO: Rafael Rosa Simões ORIENTADOR: João Cunha GRAU ACADÉMICO: Doutor INSTITUIÇÃO: ISEC CO-ORIENTADOR: Luís Eduardo Faria dos Santos GRAU ACADÉMICO: Mestre INSTITUIÇÃO: ISEC CO-ORIENTADOR: Ariadne Grillo Pacheco GRAU ACADÉMICO: Mestre INSTITUIÇÃO: ISA CARACTERIZAÇÃO SUMÁRIA DO PROJECTO: Com este estágio pretende-se efectuar uma análise exaustiva ao nível de segurança dos dados de um sector de negócio, a nível das soluções de Healthcare da empresa (ISA – Intelligent Sensing Anywhere) avaliando as 3 vertentes da segurança da informação (Confidencialidade, Disponibilidade, Integridade). Estas soluções são na área de telecare, por exemplo: acompanhamento à distância do bem-estar e doenças crónicas, através da monitorização de parâmetros como a tensão arterial, a glicose capilar, o peso, a temperatura e a oximetria, e ainda sistemas de gestão de mobilidade e localização de pessoas. Estes dados tem de cumprir normas de armazenamento, transporte e disponibilização. OBJECTIVOS: Identificar e categorizar os riscos a que os dados dos clientes/pacientes (pacientes, normalmente idosos) estão sujeitos durante a captura, transporte e armazenamento. Avaliar a redundância dos dados para permitir evitar ao máximo a indisponibilidade da informação. Avaliar como a integridade dos dados é actualmente garantida e como esta poderá ser melhorada. Avaliar os protocolos de comunicação desde a captura dos dados até ao armazenamento dos mesmos e verificar se estes se adequam e se cumprem as normas legais.

186 de 201




Estudar a aplicação de um modelo de gestão de risco, o mais adequado possível à organização, para a identificação do risco e construção de políticas de gestão de risco a que os dados sensíveis estão sujeitos. Estudo da segurança da infra-estrutura de rede (firewall, acessos ao meio, etc), e o que pode afectar os 3 pilares fundamentais da segurança dos dados PLANO E CALENDARIZAÇÃO DO PROJECTO:

Mês Objectivos

Nov.

Dez.

Jan. a Maio

Jun.

Estudo e definição das ameaças e problemáticas a identificar. X Entrega da proposta de estágio/tese para submissão ao Conselho Técnico-científico X

Identificar falhas na política de acessos físicos às infra-estruturas da empresa X

Identificar e categorizar os riscos a que os dados estão sujeitos. X Estudar e apresentar propostas para mitigar as ameaças à segurança dos dados. X

Estudo da segurança da infra-estrutura de rede. X Estudar a aplicação de um modelo de gestão de risco X Elaboração dos capítulos da tese X Entrega da tese de Mestrado X

INFRA-ESTRUTURAS A UTILIZAR: Computador Pessoal, repositórios documentais sobre as especificações dos produtos abordados, rede informática da empresa. BIBLIOGRAFIA: A saúde e a protecção de dados - http://www.insa.pt/sites/INSA/Portugues/ComInf/Noticias/Paginas/SaudeProteccaoDados.aspx ISA Intellicare - http://www.isasensing.com/index.php?section=home&lg=pt

187 de 201




__________________________________________________________________________________

Declaração do aluno, orientador e co-orientador

Declaro que aceito realizar este projecto de dissertação segundo o plano acima indicado

................................................................................................................................. (Assinatura do aluno)

Declaro que aceito orientar a realização deste projecto de dissertação segundo o plano acima indicado

................................................................................................................................. (Assinatura do orientador)

Declaro que aceito co-orientar a realização deste projecto de dissertação segundo o plano acima indicado

................................................................................................................................. (Assinatura do co-orientador)

Coimbra ___/___/_____

188 de 201


Anexo 13 - Plano de implementação

189 de 201

1O

bte

r A

po

io d

a D

ire

cçã

o1

dia?

01

-01

-20

13

8:0

02

2-0

1-2

01

3 1

7:0

0

2Aqu

isiç

ão d

a N

orm

as S

erie

s IS

O 2

7000

1 di

a?01

-01-

2013

8:0

001

-01-

2013

17:

00

31

- C

lari

fica

r p

rio

rid

ad

es a

de

se

nvo

lve

r n

o I

SM

S7

dia

s?

01

-01

-20

13

8:0

00

9-0

1-2

01

3 1

7:0

0

41.

1 -

Reu

nião

inic

ial d

e en

quad

ram

ento

1 di

a?01

-01-

2013

8:0

001

-01-

2013

17:

00R

espo

nsáv

el S

iste

mas

de

Info

rmaç

ão;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

51.

1 -

Det

erm

inar

os

obje

ctiv

os d

a im

plem

enta

ção

do I

SMS

2 di

as?

03-0

1-20

13 8

:00

04-0

1-20

13 1

7:00

4R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

61.

1 D

ocum

enta

r os

obj

ectiv

os3

dias

?07

-01-

2013

8:0

009

-01-

2013

17:

005

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01

72

- D

efi

niç

ão

pre

lim

ina

r d

o â

mb

ito

/ a

lca

nce

do

I..

.7

,12

5 d

...

10

-01

-20

13

8:0

02

1-0

1-2

01

3 9

:00

3

82.

1 -

Def

inir e

doc

umen

tar

Res

pons

abili

dade

s e

carg

os2

dias

?10

-01-

2013

8:0

011

-01-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

92.

1 -

Doc

umen

tar o

âmbi

to d

o IS

MS

1 di

a?14

-01-

2013

8:0

014

-01-

2013

17:

008

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

102

.2 -

IS

MS

– F

ram

ew

ork

de

ge

stã

o d

ocu

me

nta

l 4

dia

s?

15

-01

-20

13

9:0

02

1-0

1-2

01

3 9

:00

11Id

entif

icar

req

uisi

tos

para

os

regi

stos

do

ISM

S e

gest

...

1 di

a?15

-01-

2013

9:0

016

-01-

2013

9:0

0

12D

efin

ir o

s re

quis

itos

docu

men

tais

1

dia?

16-0

1-20

13 9

:00

17-0

1-20

13 9

:00

11

13D

efin

ir o

s re

quis

itos

a ní

vel d

os r

egis

tos

1 di

a?17

-01-

2013

9:0

018

-01-

2013

9:0

012

14Pu

blic

ar p

roce

dim

ento

s de

ges

tão

docu

men

tal e

de

g...

1 di

a?18

-01-

2013

9:0

021

-01-

2013

9:0

013

15R

evis

ão

in

tern

a /

Re

vis

ão

po

r p

art

e d

a a

dm

inis

tr..

.1

,87

5 d

...

21

-01

-20

13

9:0

02

2-0

1-2

01

3 1

7:0

07

16R

ever

res

pons

abili

dade

s e

carg

os1

dia

21-0

1-20

13 9

:00

22-0

1-20

13 9

:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

17R

ever

âm

bito

ISM

S1

dia

22-0

1-20

13 8

:00

22-0

1-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

183

- E

sta

be

lece

r o

IS

MS

(Fa

se

Pla

n)

27

dia

s?

23

-01

-20

13

8:0

02

8-0

2-2

01

3 1

7:0

01

193

.1 -

De

fin

içã

o d

o â

mb

ito

/ a

lca

nce

do

IS

MS

6 d

ias?

23

-01

-20

13

8:0

03

0-0

1-2

01

3 1

7:0

0

20D

efin

ir e

Doc

umen

tar

o âm

bito

e a

s ba

rrei

ras

orga

niza

c...

5 di

as?

23-0

1-20

13 8

:00

29-0

1-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Adm

inis

traç

ão d

a em

pres

a

21D

efin

ir e

doc

umen

tar

o âm

bito

físi

co4,

875

di..

.23

-01-

2013

8:0

029

-01-

2013

16:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;A

dmin

istr

ação

da

empr

esa

22Pu

blic

ar Â

mbi

to I

SMS

1 di

a?30

-01-

2013

8:0

030

-01-

2013

17:

0021

;20

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

233

.2 -

De

fin

ir o

s r

eq

uis

ito

s d

e s

eg

ura

nça

da

in

form

...

3 d

ias?

31

-01

-20

13

8:0

00

4-0

2-2

01

3 1

7:0

01

9

24Ef

ectu

ar u

ma

anál

ise

de la

cuna

s pr

elim

inar

1 di

a?31

-01-

2013

8:0

031

-01-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to

25Pr

oduz

ir u

m re

lató

rio

2 di

as?

01-0

2-20

13 8

:00

04-0

2-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Che

fes

de D

epar

tam

ento

263

.3 -

IS

MS

- M

an

ag

em

en

t In

form

ati

on

Se

cu

rity

F..

.1

dia

?0

5-0

2-2

01

3 8

:00

05

-02

-20

13

17

:00

25

27Criar

Gru

po -

Mul

tidis

cipl

inar

1

dia?

05-0

2-20

13 8

:00

05-0

2-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

283

.4 -

De

fin

içã

o d

e u

ma

po

líti

ca

de

se

gu

ran

ça

12

dia

s?

06

-02

-20

13

8:0

02

1-0

2-2

01

3 1

7:0

0

29D

efin

ir p

roce

dim

ento

s de

seg

uran

ça d

a in

form

ação

7 di

as?

06-0

2-20

13 8

:00

14-0

2-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Adm

inis

traç

ão d

a em

pres

a

30D

efin

ir c

ontr

olos

4 di

as?

15-0

2-20

13 8

:00

20-0

2-20

13 1

7:00

29R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;A

dmin

istr

ação

da

empr

esa

313

.5 -

De

fin

ir u

ma

po

líti

ca

pa

ra o

IS

MS

4 d

ias?

18

-02

-20

13

8:0

02

1-0

2-2

01

3 1

7:0

0

32Id

entif

icar

as

obriga

ções

lega

is n

a se

gura

nça

de in

fo..

.1

dia?

18-0

2-20

13 8

:00

18-0

2-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

33Criar

um

crité

rio

de a

valia

ção

de r

isco

1 di

a?19

-02-

2013

8:0

019

-02-

2013

17:

0032

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

34R

ever

e p

ublic

ar a

pol

ítica

ISM

S1

dia?

20-0

2-20

13 8

:00

20-0

2-20

13 1

7:00

33R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

35Apr

ovaç

ão d

a po

lític

a pe

la a

dmin

istr

ação

1 di

a?21

-02-

2013

8:0

021

-02-

2013

17:

0034

Adm

inis

traç

ão d

a em

pres

a

364

- C

lassif

ica

çã

o d

e a

cti

vo

s5

dia

s?

22

-02

-20

13

8:0

02

8-0

2-2

01

3 1

7:0

0

374

.1 -

Id

en

tifi

ca

r a

cti

vo

s d

en

tro

do

âm

bit

o d

o I

S..

.1

dia

?2

2-0

2-2

01

3 8

:00

22

-02

-20

13

17

:00

38D

esen

volv

er u

m c

rité

rio

para

a c

lass

ifica

ção

dos

activ

os1

dia?

22-0

2-20

13 8

:00

22-0

2-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

aç..

.

394

.2 -

Pro

ce

dim

en

tos e

mé

tric

as p

ara

ava

lia

çã

o .

..4

dia

s?

25

-02

-20

13

8:0

02

8-0

2-2

01

3 1

7:0

03

7

40Criaç

ão e

pub

licaç

ão d

o pl

ano

3 di

as?

25-0

2-20

13 8

:00

27-0

2-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

aç..

.

41Id

entif

icar

a m

etod

olog

ia d

e id

entif

icaç

ão d

o risc

o1

dia?

26-0

2-20

13 8

:00

26-0

2-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

aç..

.

42D

esen

volv

er u

m c

rité

rio

para

ace

itaçã

o de

ris

co1

dia?

27-0

2-20

13 8

:00

27-0

2-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

aç..

.

43Id

entif

icar

o n

ível

de

acei

tabi

lidad

e do

ris

co1

dia?

28-0

2-20

13 8

:00

28-0

2-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Adm

inis

traç

ão d

a em

pres

a

Nom

eD

uraç

ãoIn

ício

Térm

ino

Pred

ec..

.N

ome

do R

ecur

so

Roa

dMap

ISA27

001

-

pági

na1

190 de 201

445

- R

isk

Asse

ssm

en

t1

9 d

ias?

01

-03

-20

13

8:0

02

7-0

3-2

01

3 1

7:0

03

6;1

8

455

.1 -

Ava

lia

çã

o d

e r

isco

s d

e s

eg

ura

nça

da

in

form

...

14

dia

s?

01

-03

-20

13

8:0

02

0-0

3-2

01

3 1

7:0

0

46Id

entif

icaç

ão d

e risc

os –

Wor

ksho

p /

Bra

inSt

orm

3 di

as01

-03-

2013

8:0

005

-03-

2013

17:

00M

ISF;

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Adm

inis

traç

ão d

a em

pres

a;R

e...

47Ana

lisar

e a

valia

r os

ris

cos

2 di

as06

-03-

2013

8:0

007

-03-

2013

17:

0046

MIS

F;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;A

dmin

istr

ação

da

empr

esa;

Re.

..

48Id

entif

icar

e a

valia

r as

opç

ões

disp

onív

eis

para

tra

tar

o...

3 di

as08

-03-

2013

8:0

012

-03-

2013

17:

0047

MIS

F;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;A

dmin

istr

ação

da

empr

esa;

Re.

..

49Pu

blic

ar o

rel

atór

io d

a av

alia

ção

2 di

as13

-03-

2013

8:0

014

-03-

2013

17:

0048

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

505

.2 -

Co

ntr

olo

s e

ob

jecti

vo

s d

os c

on

tro

los

6 d

ias?

13

-03

-20

13

8:0

02

0-0

3-2

01

3 1

7:0

04

8

51Se

lecc

iona

r os

con

trol

os e

os

obje

ctiv

os p

ara

o tr

ata.

..2

dias

?13

-03-

2013

8:0

014

-03-

2013

17:

00M

ISF;

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

52Es

boça

r um

Pla

no d

e Tr

atam

ento

de

risc

o pa

ra o

ISM

S2

dias

?15

-03-

2013

8:0

018

-03-

2013

17:

0051

MIS

F;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

53In

form

ar a

direc

ção

acer

ca d

o risc

o re

sidu

al p

ropo

sto

1 di

a?19

-03-

2013

8:0

019

-03-

2013

17:

0052

MIS

F;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

54D

ocum

enta

r a

apro

vaçã

o1

dia?

19-0

3-20

13 8

:00

19-0

3-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

55O

bter

apr

ovaç

ão d

a di

recç

ão p

ara

impl

emen

tar

e op

...

1 di

a?20

-03-

2013

8:0

020

-03-

2013

17:

0053

Adm

inis

traç

ão d

a em

pres

a

565

.3 -

Pre

pa

rar

So

A –

Sta

tem

en

t o

f A

pp

lica

bil

ity

4 d

ias?

21

-03

-20

13

8:0

02

6-0

3-2

01

3 1

7:0

0

57Ef

ectu

ar e

Pub

licar

4 di

as?

21-0

3-20

13 8

:00

26-0

3-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

585

.4 -

Ve

rifi

ca

r C

he

ck

list

ISO

27

00

31

dia

?2

7-0

3-2

01

3 8

:00

27

-03

-20

13

17

:00

56

59Val

idar

as

tare

fas

pela

che

cklis

t –

Ane

xo A

ISO

270

031

dia?

27-0

3-20

13 8

:00

27-0

3-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

606

- I

mp

lem

en

tar

e O

pe

rar

ISM

S (

DO

)2

5 d

ias?

28

-03

-20

13

8:0

00

1-0

5-2

01

3 1

7:0

05

8;5

6..

.

616

.1 -

Tra

tam

en

to d

e R

isco

2 d

ias

28

-03

-20

13

8:0

02

9-0

3-2

01

3 1

7:0

0

62Fo

rmul

ar o

PTR

– P

lano

de

trat

amen

to d

e R

isco

2 di

as28

-03-

2013

8:0

029

-03-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to;D

onos

do.

..

63Im

plem

enta

r PT

R8

dias

01-0

4-20

13 8

:00

10-0

4-20

13 1

7:00

62R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to;D

onos

do.

..

646

.2 -

Im

ple

me

nta

çã

o d

e c

on

tro

los

3 d

ias?

08

-04

-20

13

8:0

01

0-0

4-2

01

3 1

7:0

0

65Im

plem

enta

ção

dos

cont

rolo

s se

lecc

iona

dos

para

cum

p...

1 di

a?08

-04-

2013

8:0

010

-04-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to;D

onos

do.

..

66D

efin

ir u

ma

form

a de

med

ir a

efic

ácia

dos

con

trol

os

1 di

a?10

-04-

2013

8:0

010

-04-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to;D

onos

do.

..

676

.3 -

Se

gu

ran

ça

de

in

form

açã

o o

rga

niz

acio

na

l 4

dia

s?

11

-04

-20

13

8:0

01

6-0

4-2

01

3 1

7:0

06

6

68D

esen

ho f

inal

da

estr

utur

a or

gani

zaci

onal

par

a se

gura

...

1 di

a?11

-04-

2013

8:0

011

-04-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão;C

hefe

s de

Dep

arta

men

to

69Pa

peis

e r

espo

nsab

ilida

des,

“re

port

line

s”(a

que

m r

elat

...

2 di

as?

12-0

4-20

13 8

:00

15-0

4-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Che

fes

de D

epar

tam

ento

70Pu

blic

ar a

est

rutu

ra o

rgan

izac

iona

l fin

al p

ara

o IS

MS

1 di

a?16

-04-

2013

8:0

016

-04-

2013

17:

0069

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

716

.4 -

Ma

nu

al

da

po

líti

ca

de

se

gu

ran

ça

da

in

form

a..

.2

dia

s?

17

-04

-20

13

8:0

01

8-0

4-2

01

3 1

7:0

0

72Col

ecci

onar

/ a

dici

onar

a in

form

ação

nec

essá

ria

1 di

a?17

-04-

2013

8:0

017

-04-

2013

17:

00M

ISF;

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

73Pu

blic

ar o

s M

anua

l ISM

S da

pol

ítica

de

segu

ranç

a da

inf...

1 di

a?18

-04-

2013

8:0

018

-04-

2013

17:

0072

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

746

.5 -

De

se

nvo

lve

r a

s n

orm

as e

pro

ce

dim

en

tos d

e..

.3

dia

s?

24

-04

-20

13

8:0

02

6-0

4-2

01

3 1

7:0

0

75W

orks

hop

com

res

pons

ávei

s de

áre

a pa

ra d

esen

volv

er..

.1,

667

di..

.24

-04-

2013

8:0

025

-04-

2013

14:

20M

ISF;

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

;Che

fes

de D

epar

tam

ento

;Pro

...

76Pu

blic

ar o

pla

no d

e im

plem

enta

ção

de s

egur

ança

org

an..

.1

dia?

26-0

4-20

13 8

:00

26-0

4-20

13 1

7:00

75R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

776

.6 -

Fo

rma

çã

o e

se

nsib

iliz

açã

o2

dia

s?

25

-04

-20

13

8:0

02

6-0

4-2

01

3 1

7:0

0

78D

esen

volv

er u

m p

rogr

ama

de f

orm

ação

, se

nsib

iliza

ção

...

1 di

a?25

-04-

2013

8:0

025

-04-

2013

17:

00R

espo

nsáv

el S

iste

mas

de

Info

rmaç

ão;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

...

79Im

plem

enta

r o

prog

ram

a1

dia?

26-0

4-20

13 8

:00

26-0

4-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

aç..

.

806

.7 -

Ge

rir

op

era

çõ

es e

re

cu

rso

s d

o I

SM

S2

dia

s?

29

-04

-20

13

8:0

03

0-0

4-2

01

3 1

7:0

0

81D

esen

har

o IC

T (inf

orm

atio

n co

mm

unic

atio

n te

chno

log.

..2

dias

?29

-04-

2013

8:0

030

-04-

2013

17:

00R

espo

nsáv

el S

iste

mas

de

Info

rmaç

ão;R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

Nom

eD

uraç

ãoIn

ício

Térm

ino

Pred

ec..

.N

ome

do R

ecur

so

Roa

dMap

ISA27

001

-

pági

na2

191 de 201

826

.8 -

Ve

rifi

ca

r C

he

ck

list

ISO

27

00

31

dia

?0

1-0

5-2

01

3 8

:00

01

-05

-20

13

17

:00

80

;77

...

83Val

idar

as

tare

fas

pela

Che

cklis

t –

Ane

xo A

ISO

270

031

dia?

01-0

5-20

13 8

:00

01-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

847

- M

on

ito

riza

r e

Re

ve

r o

IS

MS

(C

HE

CK

)1

1 d

ias?

02

-05

-20

13

8:0

01

6-0

5-2

01

3 1

7:0

0

857

.1 -

Mo

nit

ori

za

r e

re

ve

r o

s p

roce

dim

en

tos

1 d

ia?

02

-05

-20

13

8:0

00

2-0

5-2

01

3 1

7:0

0

86Ex

ecut

ar u

ma

revi

são

e m

onito

riza

ção

aos

proc

edim

ento

s1

dia?

02-0

5-20

13 8

:00

02-0

5-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

877

.2 A

ud

ito

ria

s I

nte

rna

s5

dia

s?

03

-05

-20

13

8:0

00

9-0

5-2

01

3 1

7:0

0

88Pl

anea

r as

aud

itorias

1 di

a?03

-05-

2013

8:0

003

-05-

2013

17:

00M

ISF;

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

fo...

89Se

lecc

iona

r e

trei

nar

os a

udito

res

1 di

a?06

-05-

2013

8:0

006

-05-

2013

17:

00M

ISF;

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

fo...

90Ex

ecut

ar a

aud

itoria

1 di

a?07

-05-

2013

8:0

007

-05-

2013

17:

00Aud

itore

s In

tern

os

91D

ocum

enta

r a

Aud

itoria

1 di

a?08

-05-

2013

8:0

008

-05-

2013

17:

00Aud

itore

s In

tern

os

92D

ocum

enta

r ac

ções

cor

rect

ivas

e p

reve

ntiv

as1

dia?

09-0

5-20

13 8

:00

09-0

5-20

13 1

7:00

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

937

.3 -

Au

dit

ori

a E

xte

rna

5 d

ias?

10

-05

-20

13

8:0

01

6-0

5-2

01

3 1

7:0

08

7

94Con

tact

ar u

m a

udito

r ex

tern

o1

dia?

10-0

5-20

13 8

:00

10-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

95O

rgan

izar

aud

itoria

exte

rna

1 di

a?13

-05-

2013

8:0

013

-05-

2013

17:

00R

espo

nsáv

eis

pela

im

plem

enta

ção

da I

SO 2

7001

967

.4 -

Me

dir

efi

cá

cia

do

s c

on

tro

los

1 d

ia?

14

-05

-20

13

8:0

01

4-0

5-2

01

3 1

7:0

0

97Ver

ifica

r se

os

requ

isito

s de

seg

uran

ça e

stão

a s

er c

u...

1 di

a?14

-05-

2013

8:0

014

-05-

2013

17:

00M

ISF;

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

fo..

.

987.

5 -

Rev

er A

valia

ção

do R

isco

1 di

a?15

-05-

2013

8:0

015

-05-

2013

17:

00M

ISF;

Res

pons

ável

Sis

tem

as d

e In

form

ação

;Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

fo...

997

.7 -

Ve

rifi

ca

r C

he

ck

list

ISO

27

00

31

dia

?1

6-0

5-2

01

3 8

:00

16

-05

-20

13

17

:00

100

Val

idar

as

tare

fas

pela

Che

cklis

t –

Ane

xo A

ISO

270

031

dia?

16-0

5-20

13 8

:00

16-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

101

8 -

Ma

nte

r e

me

lho

rar

o S

GS

I (A

CT

)2

dia

s?

17

-05

-20

13

8:0

02

0-0

5-2

01

3 1

7:0

0

102

8.1

- M

elho

rar

ISM

S2

dias

17-0

5-20

13 8

:00

20-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

103

9 -

Re

vis

ão

de

co

nfo

rmid

ad

e1

dia

?1

7-0

5-2

01

3 8

:00

17

-05

-20

13

17

:00

104

9.1

- Com

plet

ar a

rev

isão

de

conf

orm

idad

e co

m a

Che

c...

1 di

a?17

-05-

2013

8:0

017

-05-

2013

17:

00R

espo

nsáv

eis

pela

impl

emen

taçã

o da

ISO

270

01 ;

Res

pons

ávei

s pe

la s

egur

ança

da

info

rmaç

ão

105

9.2

- Cor

rigi

r as

não

con

form

idad

es1

dia?

17-0

5-20

13 8

:00

17-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

106

10

- A

ud

ito

ria

Ex

tern

a a

o I

SM

S1

dia

?1

7-0

5-2

01

3 8

:00

17

-05

-20

13

17

:00

107

1

dia?

17-0

5-20

13 8

:00

17-0

5-20

13 1

7:00

Res

pons

ávei

s pe

la im

plem

enta

ção

da I

SO 2

7001

;R

espo

nsáv

eis

pela

seg

uran

ça d

a in

form

ação

Nom

eD

uraç

ãoIn

ício

Térm

ino

Pred

ec..

.N

ome

do R

ecur

so

Roa

dMap

ISA27

001

-

pági

na3

192 de 201


104

Anexo 14 - Dimensão da vulnerabilidade (CVSS)

Uma vulnerabilidade pode ser entendida como a condição de risco em que um ativo se

encontra. Um conjunto de situações mais, ou menos problemáticas, que colocam o

ativo numa condição de indefensibilidade, atacabilidade ou destrutibilidade.

Uma vulnerabilidade pode ser avaliada de uma forma mais simples, no entanto, a

opção mais eficaz acaba por ser a avaliação de vulnerabilidades com base numa base

de dados modelo, neste caso, a mais fiável será a NIST (National Institute of

Standards and Technology) [17], fazendo uso dos seus critérios de avaliação - CVSS[17]

(Common Vulnerabilities Score System). Assim, temos acesso às listagens de

vulnerabilidades fornecidas pelas NIST de forma direta e automática, tendo como fonte

uma das melhores bases de dados, o que tornará a nossa avaliação mais eficaz e

abrangente.

As métricas de análise estão divididas em domínios, como pode ser visto na Figura 28

- Métricas CVSS:

De seguida vamos abordadas os três domínios de métricas do CVSS, divididos em

Base, Temporal e de Ambiente.

Figura 28 - Métricas CVSS

193 de 201


1.1 Domínio Base:

Aqui será analisado como uma vulnerabilidade consegue afetar o ativo, que condições

precisa e quais os atributos CIA afetados. De notar que os valores entre parêntesis

(Ex. “(L)”) são os mesmos usados nas formulas de calculo do método.

Os elementos base CVSS a analisar são:

7 Rede (AV - Access Vector) - Esta medida esclarece como uma vulnerabilidade

é explorada. Quanto mais distante estiver o intruso maior será a pontuação

atribuída

a. Local (L) – O acesso à rede para executar o ataque é feito pelo acesso

direto ao ativo.

Exemplo: Abrir uma porta e tirar um portátil da empresa. Ou aceder a

um portátil, e por USB para roubar informação.

b. Rede adjacente (A) – É necessário acesso ao domínio de uma rede,

para realizar o ataque.

Exemplo: Entrar numa rede sem fios ou Bluetooth e emitir um ataque

DOS contra um servidor a correr um serviço

c. Rede remota (R) – Não existe qualquer necessidade do intruso estar na

rede onde o ativo está alocado.

Exemplo: Um ataque RPC para causar um “buffer overflow.”.

8 Complexidade de acesso (Access Complexity) – Esta medida define e

caracteriza os requisitos de complexidade e conhecimento que uma

vulnerabilidade necessita para ser explorada. Quanto mais conhecimento for

necessário e mais complexa for uma vulnerabilidade, menor será a pontuação

deste campo.

a. Baixa (A) – Existe poucos sistemas a ultrapassar e existe muito

conhecimento de como explorar a vulnerabilidade.

b. Media (M) – Existem alguns sistemas com proteção a ultrapassar e o

conhecimento embora restrito é acessível a bastantes pessoas.

c. Alta (B) – Os sistemas a ultrapassar para alcançar o ativo são bastantes

e complexos

9 Autenticação (Au) – Esta medida esclarece o número de autenticações que um

atacante necessita ultrapassar para explorar uma vulnerabilidade. Quanto

maior numero de autenticações, menor a pontuação.

a. Múltipla (M) – O intruso terá de se autenticar pelo menos duas vezes

para explorar a vulnerabilidade.

194 de 201


Exemplo: O intruso invade um sistema operativo com umas credenciais,

mas ao aceder a outro programa, tem que colocar novamente

credenciais. Mesmo estas sendo iguais.

b. Uma (U) – O intruso tem que se autenticar pelo menos uma vez.

Exemplo: O intruso para roubar um computador apenas terá de passar

pela identificação da entrada.

c. Nenhum (N) – O intruso não tem que fazer nenhuma autenticação para

chegar ao sistema.

10 Impacto na confidencialidade (CI) – Esta medida esclarece sobre o impacto

que uma vulnerabilidade pode ter na confidencialidade de um ativo. Quanto

mais exposto ficar o ativo, maior será o valor do impacto.

a. Completa (C) – A vulnerabilidade expõe completamente o ativo ou

informação relacionada com este.

Exemplo: Uma porta foi arrombada e permite o acesso a todas as salas

do edifício.

b. Parcial (P) – A vulnerabilidade expõe apenas parcialmente, o ativo ou

informação deste.

Exemplo: Uma porta foi arrombada e permite o acesso a parte do

edifício, permitindo obter informação confidencial contida apenas em

algumas salas.

c. Nenhum (N) – A vulnerabilidade não tem qualquer impacto no ativo.

11 Impacto na integridade (II) – Esta característica esclarece sobre a capacidade

de uma vulnerabilidade conseguir alterar um ativo sem consentimento. Quanto

mais alterado for o ativo, maior vai ser a pontuação atribuída.

a. Completa (C) – A vulnerabilidade altera completamente o ativo ou

informação relacionada com este.

Exemplo: Uma porta foi arrombada e foi substituído um equipamento de

rede por outro com configurações maléficas.

b. Parcial (P) – A vulnerabilidade altera apenas parcialmente, o ativo ou

informação deste.

Exemplo: Uma porta foi arrombada e apenas foi trocada uma carta do

equipamento ativo atacado.


12 Impacto na disponibilidade (ID) – Esta característica esclarece o quanto uma

vulnerabilidade consegue deixar indisponível um ativo. Quanto maior for a

indisponibilidade, maior será o valor.

195 de 201


a. Completa (C) – A vulnerabilidade torna completamente indisponível o

ativo ou a informação relacionada com este.

Exemplo: O sistema de AC é atacado e o sistema deixa de funcionar.

As temperaturas ficam tão elevadas que todos os equipamentos têm

que ser desligados.

b. Parcial (P) – A vulnerabilidade provoca apenas indisponibilidade parcial

ao ativo ou a informação relacionada com este.

Exemplo: O sistema de AC é atacado e o sistema deixa de funcionar

parcialmente. As temperaturas ficam elevadas, mas apenas alguns dos

equipamentos têm que ser desligados.


1.2 Métricas Temporais:

A ameaça representada por uma vulnerabilidade pode variar temporalmente. De notar

que os valores entre parêntesis (Ex. “(PP)”) são os mesmos usados nas formulas do

método. O CVSS aborda três fatores:

4 Confirmação dos detalhes técnicos de uma vulnerabilidade,

5 O estado de correção (patch de correção) da vulnerabilidade,

6 Disponibilidade de conhecimento acerca da exploração de vulnerabilidades ou

técnicas de ataque a esse ativo.

As métricas temporais são opcionais, estas incluem um valor que pode ou não ter

efeito na pontuação. Se a métrica não se aplica, esta é desprezada.

4 Possibilidade de Exploração de uma ameaça (Exploitability) - Esta métrica

mede o estado atual do conhecimento acerca da exploração de

vulnerabilidades ou técnicas de ataque a um ativo de informação. O

conhecimento público de falhas e técnicas de ataque torna pessoas normais,

sem grandes conhecimentos, potenciais atacantes.

Quanto mais facilmente uma vulnerabilidade poder ser explorada, maior será a

pontuação da vulnerabilidade:

Por Provar (PP) – não existe conhecimento acerca de como explorar a ameaça

a. Prova de Conceito (PC) – A ameaça é explorável apenas por atacantes

muito específicos e apenas em alguns sistemas com determinadas

condicionantes

196 de 201


b. Funcional (F) - Está disponível uma forma de exploração funcional da

ameaça, que funciona na maioria das situações onde a vulnerabilidade

exista.

c. Alta (A) - Está disponível uma forma de exploração da ameaça, é eficaz

em todas as situações onde a vulnerabilidade exista.

d. Não Definida (ND) - A atribuição deste valor para a métrica não tem

qualquer importância para a pontuação final. É um sinal para a equação

para saltar esta métrica.

5 O estado de correção - O nível de correção das vulnerabilidades é um fator

importante para a priorização de tratamento. A vulnerabilidade típica quando

inicialmente publicada, não tem uma correção associada. Com o tempo vão

aparecendo patches de correção.

Quanto menos oficial e permanente é uma correção, maior é a pontuação da

vulnerabilidade:

a. Correção Oficial (OF)– Está disponível uma solução completa que

elimine a vulnerabilidade.

b. Correção temporária (TF) – Está disponível uma solução oficial mas

temporária para a vulnerabilidade.

c. Correção tipo “remendo” (W)– Existe uma solução não oficial. Em

alguns casos, os utilizadores da tecnologia criam um patch por conta

própria e divulgam as etapas para eliminar a vulnerabilidade, ou pelo

menos mitigar.

d. Indisponível (U) – Não existe uma solução para o problema, ou esta é

impossível de aplicar.

e. Não definida ND - A atribuição deste valor para a métrica não tem

qualquer importância para a pontuação final. É um sinal para a equação

saltar esta métrica.

6 Informação sobre a vulnerabilidade (Report Confidence) - Esta métrica mede o

grau de confiança da vulnerabilidade existente e da credibilidade dos detalhes

técnicos conhecidos acerca dela.

Por vezes, apenas a existência da vulnerabilidade é divulgada, mas sem

detalhes específicos. A vulnerabilidade pode ser corroborada mais tarde e, em

seguida, confirmada por parte do autor ou do fornecedor da tecnologia afetada.

Quanto mais uma vulnerabilidade é confirmada/validada pelo vendedor ou por

outras fontes fidedignas, maior é a pontuação:

197 de 201


a. Não Confirmada (UC) – Há uma única fonte não confirmada ou

possivelmente vários relatórios contraditórios. Há pouca confiança na

validade dos relatórios. Um exemplo é um rumor que emerge do

submundo hacker.

b. Não Corroborada (UR) – Existem várias fontes não oficiais,

possivelmente incluindo empresas de segurança ou organizações

independentes de pesquisa.

c. Confirmada (C) – A vulnerabilidade foi reconhecida pelo vendedor ou

autor da tecnologia afetada, ou foi provada publicamente através de

demonstração.

d. Não Definida (ND) – A atribuição deste valor para a métrica não tem

qualquer importância para a pontuação final. É um sinal para que a

equação salte esta métrica.

1.3 Domínio Ambiental (Opcional):

Aqui será analisado como uma vulnerabilidade pode ser relacionada com o

comportamento de utilizadores de tecnologias de informação.

3 Potencial Para danos colaterais (PDC) - Esta medida esclarece como uma

vulnerabilidade pode gerar danos à empresa, sendo eles financeiros, de

reputação ou de atividade. Quanto maior for o impacto, maior será o valor a

atribuir.

a. Indefinido (I) – Este campo faz com que esta métrica não seja

considerada para a pontuação geral.

b. Nenhum (N) – O impacto não traz perdas à produtividade.

c. Baixo (B) – O impacto traz perdas reduzidas de produtividade, pois

afeta poucos serviços e pouco importantes.

Exemplo: A senhora da receção deixou a correspondência em cima da

mesa e foram roubadas notas de transferência de material entre

sucursais da empresa. Como a empresa tem um processo de

confirmação de chegada da informação, esta falha apenas atrasou o

processo de envio de material umas horas.

d. Médio Baixo (MB) – O impacto traz perdas financeiras e de

produtividade controláveis, pois afeta serviços de logística internas.


mesa e foram roubadas notas de transferência de material para um

cliente. Como a empresa não tem um processo de confirmação de

198 de 201


chegada de pedidos, esta falha atrasou o processo de envio de material

umas horas e gerou uma reclamação.

e. Médio Alto (MA) – O impacto traz perdas financeiras e de produtividade

elevadas, leva a que clientes reduzam a confiança na empresa e os

prejuízos internos sejam elevados.



cliente. O intruso alterou a documentação e o pedido chegou

completamente alterado. Uma encomenda de materiais desnecessários

e gigantesca foi enviada. Mas o cliente recusa a encomenda, mas como

os prazos permitem, emite encomenda por via prioritária. Os prejuízos

financeiros são apenas internos, as existe um impacto considerável na

reputação.

f. Alto (A) – O impacto traz perdas financeiras e de produtividade

irremediáveis, leva a que clientes cancelem contractos e façam

interposições judiciais contra a empresa.



cliente. O intruso alterou a documentação e o pedido chegou

completamente alterado. Uma encomenda de materiais desnecessários

e gigantesca foi enviada. O cliente prejudicado por esta falha, por justa

causa, cancelou o contrato e judicialmente pediu indeminização pelo

impacto causado no seu negócio.

4 Distribuição dos Alvos (DA) - Esta medida esclarece como uma vulnerabilidade

atinge em percentagem um conjunto de sistemas ou ativos. Quanto maior for o

numero de sistemas atingido, maior será o valor a atribuir.



b. Nenhuns (N) – Não existem sistemas afetados.

c. Baixo (B) – Existe uma percentagem entre 1 e 33 % de sistemas

afetados.

d. Médio (M) – Existe uma percentagem entre 34 e 66 % de sistemas

afetados.

e. Alto (A) – Existe uma percentagem entre 67 e 100 % de sistemas

afetados.

199 de 201


NOTA: Esta métrica está relacionada com a seguinte para poder ser

considerada. Na próxima métrica temos a valorização do ativo para atribuição

de importância e por consequência de valorização.

5 Requisito de segurança (Requisitos Confidencialidade - RC, Requisitos

Integridade - RI, Requisitos Disponibilidade - RD) – Esta medida esclarece

como uma vulnerabilidade afeta em termos de

Confidencialidade/Integridade/Disponibilidade (CID) um determinado ativo.

Esta métrica está relacionada com as métricas do domínio base para efeitos de

cálculo final das métricas ambientais.



b. Baixo (B) – A perda de [Confidencialidade |Integridade | Disponibilidade]

tem pouco efeito sobre a organização e os seus valores.

c. Médio (M) – A perda de [Confidencialidade |Integridade |

Disponibilidade] tem algum efeito sobre a organização e os seus

valores.

d. Alto (A) – A perda de [Confidencialidade |Integridade | Disponibilidade]

tem um efeito enorme sobre a organização e os seus valores.

NOTA: Todos os valores atribuídos a cada um dos parâmetros anteriores, bem como

todos os cálculos associados, são definidos pela NIST (National Institute of Standards

and Technology). Tal pode ser consultado através do seguinte endereço Web:


Após avaliar as vulnerabilidades mediante os pontos definidos em cada um dos

domínios anteriores, obtemos 3 resultados finais:

Resultado final métricas Base (RFB)

Resultado final métricas Temporais (RFT)

Resultado final métricas Ambientais (RFA)

A aplicação das fórmulas métricas é um processo que recorre a fórmulas definidas no

CVSS, de seguida iremos ver um exemplo da fórmula de cálculo da métrica base de

um ativo exemplo:

200 de 201



Figura 29 - Calculo CVSS

O detalhe das formulas poderá ser encontrado no guia CVSS 2.0[6].

Ambos os valores resultantes de cada dos 3 domínios deverão ser compreendidos

entre 0 e 10. Posteriormente é feita uma média dos 3 valores obtidos:

.

Estando a média efetuada, é necessário enquadrar este resultado na nossa dimensão

final do risco, para tal segue-se a atribuição de pontos à dimensão da vulnerabilidade:

Média compreendida entre 0 e 3,333 inclusive - 1 ponto

Média maior que 3,333 e menor ou igual que 6,666 - 2 pontos

Média maior que 6,666 – 3 pontos

in [6]

201 de 201