View
217
Download
0
Category
Preview:
Citation preview
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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!
Segurança da Informação na Saúde
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)
Segurança da Informação na Saúde
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)
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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)
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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.
Cap.1 - Introdução Segurança da Informação na Saúde
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”
Cap.1 - Introdução Segurança da Informação na Saúde
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
Cap.1 - Introdução Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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]
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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:
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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]
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Esta etapa é composta pelas seguintes fases:
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.
Esta etapa é composta pelas seguintes fases:
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
Esta etapa é composta pelas seguintes fases:
8. Manter e melhorar o SGSI
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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).
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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]
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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.
Cap.2 - Segurança da informação Segurança da Informação na Saúde
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:
Cap.2 - Segurança da informação 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).
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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)
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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.
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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.
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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]
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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.
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
segurança da informação
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
segurança da informação
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
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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.
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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.
Cap.3 – Guia de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
38
Figura 10 - Listagem e Classificação de Ativos
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.”
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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]
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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)
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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:
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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]
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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:
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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.
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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]
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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).
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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 –
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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:
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 4.Caso prático de implementação Segurança da Informação na Saúde
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
Cap. 5.Conformidade legal OneCare Segurança da Informação na 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
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na 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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na 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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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]).
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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]
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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
Cap. 5.Conformidade legal OneCare Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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.
Segurança da Informação na Saúde
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
30-11-2011 Rafael Simões
Luis Santos
ISEC
Gabinete
LS
Proposta Estágio / Tese
Análise de Livros e Normas de
Segurança de Saúde
11-01-2012 Rafael Simões
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
09-03-2012 Rafael Simões
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
14-04-2012 Rafael Simões
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
04-05-2012 Rafael Simões
Luis Santos
ISEC
Gabinete
LS
Requisitos Legislação e CNPD
18-05-2012 Rafael Simões
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
Segurança da Informação na Saúde
91
António
Damasceno
- ISA da arquitetura OneCare
25-05-2012 Rafael Simões
Luis Santos
João Cunha
Gabinete
Reuniões
DEIS-ISEC
Legislação nacional e Requisitos
CNPD
Gantt (Open Project) de
Implementação ISO 27001
01-06-2012 Rafael Simões
Luis Santos
João Cunha
Gabinete
Reuniões
DEIS-ISEC
Reuniões com o grupo de projeto (Rui
e António)
Gantt (Open Project) de
Implementação ISO 27001
Âmbito de trabalho de estágio
05-06-2012 Rafael Simões
António
Damasceno
Ursa Minor
- ISA
Reformulação das exigências da
CNPD
08-06-2012 Rafael Simões
Luis Santos
João Cunha
Gabinete
Reuniões
DEIS-ISEC
Requisitos legais do OneCare
Road Map de implementação ISO
27001
Gestão Documental
22-06-2012 Rafael Simões
Luis Santos
João Cunha
Gabinete
Reuniões
DEIS-ISEC
Relatório para entregar à CNPD –
Segurança OneCare
29-06-2012 Rafael Simões
Luis Santos
ISEC
Gabinete
LS
A arquitetura do OneCare
Plano de implementação ISO 27001
06-07-2012 Rafael Simões
António
Damasceno
Ursa Minor
- ISA
Documento de requisitos de
segurança
16-07-2012 Rafael Simões
Luis Santos
João Cunha
ISEC
Gabinete
LS
Gap Analysis
SoA (Statement of Applicability)
Road Map de implementação ISO
27001
Gantt (Open Project) de
Implementação ISO 27001
09-08-2012 Rafael Simões
Luis Santos
João Cunha
Conf. Call.
Via Skype
Apreciação de Deliverables
Relatório Final
Road Map de implementação ISO
27001
23-08-2012 Rafael Simões
Luis Santos
Conf. Call.
Via Skype
Apreciação de Deliverables
Relatório Final
05-09-2012 Rafael Simões
Luis Santos
João Cunha
ISEC
Gabinete
LS
Relatório Final
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
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
Destruição/Indisponibilidade/Perda de Informação
Destruiçã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/Possivel destruição/Perda de Informação
Indisponibilidade/Danificação de equipamento/Possivel destruição/Perda de Informação
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
Indisponibilidade/Danificação de equipamento/Possivel 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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
96
Anexo 6 – Priorização do tratamento de risco
99 de 201
Nome da Empresa: Local:
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
Segurança da Informação na Saúde
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
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/pt-pt/security/bulletin/ms11-086
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é Simões 12-7-12 30-7-12
Active Directory Certificate Services Vulnerability 10935
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-051
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é Martins 12-7-12 30-7-12
(ADFS) does not properly remove credentials at the end of a network session
4536Transferir
(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/MS09-070
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
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
Segurança da Informação na Saúde
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?
PI PI PI PI Parcialmente implementado
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?
NI NI NI NI Não Implementado
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?
NI NI NI NI Não Implementado
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?
NI NI NI NI Não Implementado
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?
PI PI PI PI Parcialmente implementado
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?
NI NI NI NI Não Implementado
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?
NI NI NI NI Não Implementado
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?
NI NI NI NI Não Implementado
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?
PI PI PI PI Parcialmente implementado
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?
PI PI PI PI Parcialmente implementado
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?
PI PI PI PI Parcialmente implementado
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
Segurança da Informação na Saúde
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
ISO 27001 ISMS - Análise de falhas (Exemplo)
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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 3 of 21 Ultima Modificação 08/09/12
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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 4 of 21 Ultima Modificação 08/09/12
• 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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 5 of 21 Ultima Modificação 08/09/12
• 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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Página 6 de 21 08/09/12
5. Gráficos de implementação
Controlos ISO 27002 Implementados
Imagem 2
122 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 7 of 21 Ultima Modificação 08/09/12
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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 8 of 21 Ultima Modificação 08/09/12
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
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 9 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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;
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
125 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 10 of 21 Ultima Modificação 08/09/12
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.
Responsável: António Simões
Due date: 10-07-2012
==
0 1 2 3 4 5 6
�
==
126 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 11 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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.
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
127 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 12 of 21 Ultima Modificação 08/09/12
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.
Responsável: António Simões
Due date: 10-07-2012
==
0 1 2 3 4 5 6
�
==
128 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 13 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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..
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
129 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 14 of 21 Ultima Modificação 08/09/12
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
Responsável: António Simões
Due date: 10-07-2012
==
0 1 2 3 4 5 6
�
==
130 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 15 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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.
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
131 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 16 of 21 Ultima Modificação 08/09/12
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;
Responsável: António Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
132 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 17 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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:
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
133 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 18 of 21 Ultima Modificação 08/09/12
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;
Responsável: António Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
134 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 19 of 21 Ultima Modificação 08/09/12
Ref Controlos ISO 27001 Recomendações e Descobertas Nível de Maturidade CMM
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.
Responsável: Rafael Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
135 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Page 20 of 21 Ultima Modificação 08/09/12
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.
Responsável: António Simões
Due date: 10-07-2012
0 1 2 3 4 5 6
�
==
136 de 201
ISO 27001 ISMS - Análise de falhas (Exemplo)
Página 21 de 21 08/09/12
Referencias
CMM Adaptação ISO 27001 pelo ISO 27001 Forum
137 de 201
Segurança da Informação na Saúde
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
2012 Página 7
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
2012 Página 8
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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)
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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)
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
2012 Página 15
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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:
Baixo – 1 Ponto Médio – 2 Pontos Alto – 3 Pontos
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:
Baixo – 1 Ponto Médio – 2 Pontos Alto – 3 Pontos
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Fontes Adicionais o ND
165 de 201
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
2012 Página 28
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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.
Fontes Adicionais o ND
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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”
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Fontes Adicionais o ND
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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”
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Abordagem Recomendada
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Classificação: INTERNA
Plano de Implementação ISO 27001 v006
Classificação: INTERNA RRS
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
Segurança da Informação na Saúde
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:
Nome da Empresa: Local:
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 UPS 1 - Datacenter Clientes 10KVA
Interna UPS 2 - Datacenter Clientes 5KVA
Interna SMSCenter ISP3
Interna Datacenter Comunicações
Interna Datacenter Clientes
Interna Modem Dados Cliente6
Interna SMSCenter ISP
Interna SMSCenter ISP 2
Interna Modem Dados Cliente3
Interna Modem Dados Cliente4
Interna Modem Dados Cliente5
Interna Fax
Interna Modem Dados Cliente1
Interna Modem Dados Cliente2
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 SW13 - Utilizadores
Interna AP1
Interna SW9- Intellicare
Interna SW10 - Utilizadores
Interna SW11 - Utilizadores
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
Segurança da Informação na Saúde
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
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 2 de 3 Proposta de Projecto – Modelo V1
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
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 3 de 3 Proposta de Projecto – Modelo V1
__________________________________________________________________________________
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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.
c. Nenhum (N) – A vulnerabilidade não tem qualquer impacto no ativo.
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
Segurança da Informação na Saúde
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.
c. Nenhum (N) – A vulnerabilidade não tem qualquer impacto no ativo.
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
Segurança da Informação na Saúde
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
Segurança da Informação na Saúde
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.
Exemplo: A senhora da receção deixou a correspondência em cima da
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
Segurança da Informação na Saúde
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.
Exemplo: A senhora da receção deixou a correspondência em cima da
mesa e foram roubadas notas de transferência de material para um
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.
Exemplo: A senhora da receção deixou a correspondência em cima da
mesa e foram roubadas notas de transferência de material para um
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.
a. Indefinido (I) – Este campo faz com que esta métrica não seja
considerada para a pontuação geral.
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
Segurança da Informação na Saúde
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.
a. Indefinido (I) – Este campo faz com que esta métrica não seja
considerada para a pontuação geral.
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:
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 é 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
Segurança da Informação na Saúde
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
Recommended