METI Dissertacao JoaoFialho 68153

Processo de Gestão de Risco para Segurança da
Informação e Continuidade de Negócio
João Carlos Gonçalves Fialho
Dissertação para obtenção do Grau de Mestre em
Engenharia de Telecomunicações e Informática
Orientador: Prof. José Luís Brinquete Borbinha
Júri
Presidente: Prof. Paulo Jorge Pires Ferreira
Vogal: Prof. José Luís Brinquete Borbinha
Vogal: Prof. Miguel Leitão Bignolas Mira da Silva
27 de Outubro de 2016
ii
Invictus
Out of the night that covers me,

Black as the pit from pole to pole,
I thank whatever gods may be
For my unconquerable soul.
In the fell clutch of circumstance

I have not winced nor cried aloud.
Under the bludgeoning of chance
My head is bloody, but unbowed.
Beyond this place of wrath and tears

Looms but the Horror of the shade,
And yet the menace of the years
Finds, and shall find me, unafraid.
It matters not how strait the gate,

How charged with punishments the scroll,
I am the master of my fate:
I am the captain of my soul.
W ILLIAM E RNEST H ENLEY
iii
iv
Agradecimentos
Ao Professor José Borbinha por toda a dedicação e paciência que teve para comigo durante todo o
trabalho indicando sempre qual o rumo a seguir, sem a sua orientação não teria conseguido concluir o
trabalho.
A todo o DNS.PT por toda a ajuda disponibilizada, em especial à Dr.a Inês Esteves, que sempre
acompanhou de perto sendo um exemplo de disponibilidade e trabalho, e ao Eng.o Rui Barquina que
através do seu conhecimento de muitos anos sobre o assunto me ajudou sempre a perceber e a execu-
tar da melhor forma possı́vel, sem a sua preciosa colaboração não teria conseguido produzir o trabalho
que serve de sustentação para esta dissertação.
Sem nunca esquecer toda a minha famı́lia e amigos que sempre me apoiaram e deram forças para
continuar, em especial os meus pais, irmão e a minha namorada, todos eles cada um no seu tempo e
à sua maneira fez este caminho comigo e ajudou-me a manter a motivação e foco mesmo quando tudo
parecia impossı́vel.
Por fim mas não por último, agradecer a Deus na certeza de que Ele me acompanhou em todo o
percurso e me deu através de todas as pessoas que se cruzaram no meu caminho as ferramentas para
conseguir alcançar este objetivo.
v
vi
Resumo
Esta dissertação surge da proposta que o DNS.PT realizou para o desenvolvimento de um plano de
continuidade de negócio de acordo com a norma ISO 22301. Analisei a norma ISO 22301 e colocou-se
a questão de como criar então o processo para gerir os riscos da continuidade de negócio.
O problema a resolver surge da necessidade de integração de um processo de risco para a continui-
dade de negócio num processo de gestão de risco para a segurança da informação (ISO 27001) que já
existia.
Este problema torna-se relevante por se estar a demonstrar a complementaridade das duas normas
e assim demonstrar que se pode gerir o risco de uma forma global.
Como ambas as normas referem a norma ISO 31000 como a referência a seguir para a gestão do
risco, decidi escolher a mesma como base do trabalho a desenvolver.
Analisando esta norma percebi que ela indica possı́veis métodos de aferir risco através da norma
ISO 31010. O método escolhido foi o BIA por ser mandatório na continuidade de negócio e aplicável na
segurança da informação.
Para criar o processo usei a sugestão da norma ISO 31000 como arquitetura de alto nı́vel e desen-
volvi um processo para cada atividade.
No final, consegui demonstrar que as normas se complementam e que é possı́vel gerir risco global-
mente beneficiando assim a própria organização que consegue ter todas as vertentes do negócio na
gestão do risco.
Palavras-chave: Continuidade do Negócio, Segurança da Informação, Processo Gestão de

Risco, Plano de Continuidade de Negócio, Normas ISO.
vii
viii
Abstract
It was from the DNS.PT internship proposal that the theme for this dissertation comes up, the pro-
posal was the creation of a business continuity plan accordingly with ISO 22301 standard. After the
standard analysis, the challenge of a risk management process creation has been made.
The problem to solve comes up by the necessity of integrate a risk management process for business
continuity on another for information security (ISO 27001).
The problem’s relevance is the demonstration of both standards complementarity and the possibility
to manage risk from a global perspective.
Both standards refer the ISO 31000 standard as reference for risk management, so I decided to use
this standard as base for my work.
By analyzing this standard, I realized that, it states several risk assessment techniques through
ISO 31010 standard. The chosen method was BIA, due to be mandatory for business continuity and
applicable at information security.
In order to create the process, I used the ISO 31000 suggestion as a high level process architecture
and develop a process per activity.
In the end, I was able to demonstrate the complementarity of standards, the global risk management,
which is a benefit for an organization that can have all the business points of view in risk management.
Keywords: Business Continuity, Information Security, Risk Management Process, ISO stan-
dards, Business Continuity Plan.
ix
x
Conteúdo
Invictus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix
Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii
Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv
Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Glossário . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2 Estado da Arte 4
2.1 Continuidade de Negócio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1 A norma referência ISO 22301 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2 Gestão de Risco em Continuidade de Negócio - ISO 31000 . . . . . . . . . . . . . 7
2.2 Segurança da Informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2.1 A norma referência ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Gestão de Risco na Segurança da Informação - ISO 27005 . . . . . . . . . . . . . 11
2.3 Aferição de Risco em Continuidade de Negócio e Segurança da Informação . . . . . . . 13
2.3.1 BIA - ISO 31010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.2 BIA - Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3.3 BIA - Passo 1: Definir Âmbito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.4 BIA - Passo 2: Recolher dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.5 BIA - Passo 3: Moderação e Relatório . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3 Análise do Problema 25
3.1 O Service Provider - Associação DNS.PT . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Contexto do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
xi
3.3 Definição do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4 Proposta de Solução 29
4.1 Estabelecer Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Aferir o Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Tratamento de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.4 Monitorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4.1 Monitorização de Estabelecer o Contexto . . . . . . . . . . . . . . . . . . . . . . . 38
4.4.2 Monitorização da Aferição de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4.3 Monitorização do Plano de Tratamento de Riscos . . . . . . . . . . . . . . . . . . . 40
4.5 Comunicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Processo de Gestão de Risco no COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5 Conclusões e Trabalho Futuro 44

5.1 Objetivos e Desafios Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Processo de Gestão de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 DNS.PT como Infraestrutura Crı́tica em Portugal . . . . . . . . . . . . . . . . . . . . . . . 48
5.4 Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.5 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Anexos 52
A Proposta BIA ISACA 53
B Proposta BIA DNS.PT 58
C Definição Infraestrutura Crı́tica 61
D Classificação enquanto Infraestrutura Crı́tica 64
Referências 68
xii
Lista de Tabelas
2.1 Mapeamento entre pontos nas normas ISO. [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Formas de avaliar o desempenho da polı́tica implementada. [2] . . . . . . . . . . . . . . . . . . 7
4.1 Repositórios de Informação utilizados nos 5 processos. . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Atividades executadas no processo de Estabelecer o Contexto. . . . . . . . . . . . . . . . . . . 32
4.3 Atividades executadas no processo de Aferição de Risco. . . . . . . . . . . . . . . . . . . . . . 34
4.4 Atividades executadas no processo de Tratamento de Risco. . . . . . . . . . . . . . . . . . . . . 36
4.5 Atividades executadas no processo de Monitorização do Estabelecer Contexto. . . . . . . . . . . 38
4.6 Atividades executadas no processo de Monitorização da Aferição de Risco. . . . . . . . . . . . . 39
4.7 Atividades executadas no processo de Monitorização do Plano de Tratamento de Riscos. . . . . . 40
4.8 Atividades executadas no processo de Comunicação e Consulta. . . . . . . . . . . . . . . . . . 41
xiii
xiv
Lista de Figuras
2.1 Plan-Do-Check-Act(PDCA) [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Processo de gestão de risco. [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Processo de gestão de risco norma ISO 27005. [7] . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Principios do COBIT 5. [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.5 Áreas chave do COBIT 5 para governance e gestão. [8] . . . . . . . . . . . . . . . . . . . . . . 24
2.6 Processos do COBIT 5 para governance e gestão. [8] . . . . . . . . . . . . . . . . . . . . . . . 24
4.1 Processo de Estabelecer o Contexto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Processo de Aferição de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.3 Processo de Tratamento de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.4 Processo de Monitorização do Contexto do Negócio . . . . . . . . . . . . . . . . . . . . . . . . 38
4.5 Processo de Monitorização da Aferição de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.6 Processo de Monitorização do Tratamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 40
4.7 Processo de Comunicação e Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.8 Ligação do COBIT 5 a outras normas e frameworks. [10] . . . . . . . . . . . . . . . . . . . . . . 43
4.9 Processos COBIT 5 para gerir o risco. [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
xv
xvi
Abreviaturas
BIA Business Impact Analysis.
ccTLD country code Top Level Domain.
CN Continuidade de Negócio.
DNS Domain Name System.
DNSSEC Domain Name System Security Extensions.
ICANN Internet Corporation for Assigned Names and Numbers.
IP Internet Protocol.
ISP Internet Service Provider .
MTD Maximum Time of Disruption.
MTPD Maximum Tolerable Period of Disruption.
PDCA Plan-Do-Check-Act.
RPO Recovery Point Objective.
RTO Recovery Time Objective.
SGCN Sistema de Gestão de Continuı́dade de Negócio.
SLA Service Level Agreement.
xvii
xviii
Glossário
anycast forma de encaminhamento onde os dados são distribuı́dos ao destino mais próximo, ou ao
melhor destino definido pelo routing da rede.
atividade processo ou conjunto de processos realizados por uma organização que produzem ou su-
portam um ou mais produtos e serviços.
BIA Análise do impacto que cada evento de caráter disruptivo pode ter no negócio.
ccTLD é um domı́nio de topo na Internet geralmente usado e reservado para paı́ses ou territórios.
consequência Resultado de um evento que afeta os objetivos.
continuidade de negócio Capacidade da Organização continuar a fornecer produtos ou serviços a

nı́veis aceitáveis, definidos previamente, a seguir de um incidente disruptivo.
controlo Ação que modifica o risco.
critério de risco Termo de referência ou limite sobre o qual a significância do risco é avaliada.
DNS o protocolo usado para gestão e conversão de nomes em IP na Internet.
DNSSEC visa melhorar a segurança criada para o protocolo DNS, reduzindo o risco de manipulação de
dados e domı́nios forjados, este mecanismo assenta em criptografia de assinaturas com recurso
a chaves assimétricas.
evento Ocorrência ou mudança de um conjunto particular de circunstâncias.
gestão de risco atividades coordenadas que visam direcionar e controlar uma organização em relação
ao seu risco.
ICANN entidade sem fins lucrativos, responsável pela alocação do espaço de endereços IP (IPv4 e
IPv6), pela administração do DNS, assim como gerir o sistema de servidores-raiz do DNS.
key drivers Procedimentos documentados que guiam a organização para responder, recuperar, reini-
ciar e restaurar a operação para um nı́vel pré-estabelecido a seguir a uma disrupção.
MTD ver MTPD.
MTPD Tempo máximo de disrupção aceite pela organização até sofrer impactos no seu negócio.
xix
plano de continuidade de negócio Procedimentos documentados que guiam a organização para res-
ponder, recuperar, reiniciar e restaurar a operação para um nı́vel pré-estabelecido a seguir a uma
disrupção.
processo Conjunto de atividades inter-relacioanadas ou que interagem entre si que transformam um

input em um output.
processo de gestão de risco Aplicação sistemática de polı́ticas de gestão, procedimentos e práticas

nas atividades de comunicação, consulta, estabelecimento do contexto, e identificação, análise,
avaliação, tratamento, monitorização e revisão do risco.
registo de riscos Repositório de toda a informação relativa aos riscos, eventos, impactos, consequências,
ativos, controlos.
risco Efeito de incerteza nos objetivos.
Round Robin Este algoritmo consiste em atribuir a cada processo um quantum fixo de tempo para
a sua execução, sem olhar a prioridades, tratando assim todos os processos de igual modo e
garantindo que todos têm direito ao seu tempo de execução e o podem usufruir.
RPO Tempo máximo aceite de perda de informação antes da ocorrência de um evento disruptivo.
RTO Tempo mı́nimo aceite que o sistema pode levar a recuperar o seu funcionamento.
segurança da informação Preservação da confidencialidade, autenticidade e disponiblidade da informação.
sistema de gestão de continuidade de negócio Parte do sistema de gestão global que estabelece,
implementa, opera, monitoriza, revê, mantem e melhora a continuı́dade de negócio.
stakeholders Partes interessadas ou intervinientes que podem ser afetadas por uma decisão ou ativi-
dade da organização.
tratamento do risco Processo para modificar o risco.
trends Procedimentos documentados que guiam a organização para responder, recuperar, reiniciar e
restaurar a operação para um nı́vel pré-estabelecido a seguir a uma disrupção.
xx
Capı́tulo 1
Introdução
1.1 Motivação
O Domain Name System (DNS), é uma das ferramentas fundamentais para o funcionamento da
Internet, este protocolo efetua a resolução de nomes de domı́nios em endereços Internet Protocol(IP),
e vice-versa. Este protocolo consiste numa base de dados hierárquica e distribuı́da, com mecanismos
de redundância e distribuição de carga, nomeadamente através do algoritmo Round Robin, múltiplas
instâncias de servidores de nomes, tal como define a especificação do protocolo DNS. Mais recente-
mente, nas últimas duas décadas, surgiram novos mecanismos para reforçar a segurança e resiliência
do serviço DNS, nomeadamente DNSSEC e anycast.
A Internet e a sua utilização, nomeadamente a gestão e utilização de domı́nios, tem cada vez mais
impacto na vida das pessoas e das empresas, atendendo à criticidade, do serviço de gestão do domı́nio
de um country code Top-Level Domain (ccTLD), torna-se imperativo a um gestor como o DNS.pt, imple-
mentar na sua organização mecanismos e/ou processos que assegurem a continuidade do seu negócio
através de uma correta gestão do impacto que o risco associado a cada processo pode provocar ao
negócio.
Esta necessidade transversal a praticamente todas as organizações que se querem de sucesso,
provocou que por outro lado venham cada vez mais a compreender a necessidade de garantir que exis-
tem uma séries de mecanismos dentro da sua organização que permitam uma proteção dos dados dos
seus sistemas de informação e uma recuperação dos processos core do negócio em tempo útil para o
negócio da organização, pois os desastres acontecem e uma organização que transmita confiança, tão
fundamental para o mercado, é uma organização de sucesso (alguém confiaria num banco se soubesse
que não havia mecanismos de backup e que caso haja um problema implicasse a não salvaguarda das
transações?).
Deste modo tornou-se bastante claro para mim a importância dos temas de gerir o risco, garantir
a continuidade de negócio e segurança da informação. Por serem temas bastante atuais, a motivação
deste trabalho passou por responder à necessidade destes dois domı́nios em gerir o risco com o mesmo
processo de gestão de risco, de modo a poder comprovar a complementariedade dos temas.
1
1.2 Overview
Esta dissertação baseia-se na resolução de um problema, a criação de um processo de gestão de
risco entre dois domı́nios, segurança da informação e continuidade de negócio. Para tal, em primeiro lu-
gar, foi realizada uma pesquisa sobre o estado da arte onde se procurou identificar as normas referência
e como podem ser aplicadas. Num segundo momento a pesquisa incidiu sobre como identificar pontos
em comum entre os dois domı́nios, nomeadamente gerir os riscos com um só processo.
Após a realização desta pesquisa a conclusão que obtive foi de que a arquitetura definida nas nor-
mas ISO 31000 e ISO 27005 conseguir responder aos requisitos que procurava para a minha solução.
De modo a implementar esta arquitetura foi necessário procurar uma técnica de aferição de risco que
pudesse servir as necessidades da segurança da informação e da continuidade de negócio, na norma
ISO 31000 vem referido que existe uma lista de técnica sugeridas para aferição do risco na mesma
norma. Após analisar a norma ISO 31010 e comparar com os requisitos das normas ISO 22301 e
ISO 27001 a conclusão que tirei foi de que a técnica de Business Impact Analysis (BIA) responde às
necessidades do meu problema.
Deste modo identificada a arquitetura a seguir e escolhida a técnica para aferir o risco a etapa se-
guinte foi criar processos que pudessem aplicar a arquitetura proposta. Para desenhar estes processos
escolhi a linguagem BPMN. Em cada um deles tive de ter em consideração os requisitos das normas
referência da ISO para os dois domı́nios e as atividades realizadas procuram responder a isso mesmo.
A principal lógica passou então por criar atividades que evitassem ao máximo a duplicação de tra-
balho, por exemplo em vez de definir uma politica de segurança da informação e outra de continuidade
de negócio, define-se uma só polı́tica de segurança da informação e continuidade de negócio onde se
responde aos requisitos das duas normas. Este exemplo ilustra aquilo que foi a lógica condutora da
implementação da arquitetura de processos da ISO 31000.
1.3 Objectivos
O objetivo principal que proponho atingir com esta tese passa por demonstrar que é possı́vel de-
senvolver um sistema de segurança da informação e um sistema de continuidade de negócio ambos
baseados no mesmo processo de gestão de risco numa organização do mercado tecnológico.
Para conseguir cumprir com esse objetivo principal tenho de em primeiro lugar conseguir atingir
alguns objetivos secundários:
• Demonstrar complementariedade entre as normas ISO 22301 e ISO 27001;
• Demonstrar que ambos domı́nios têm os mesmo requisitos de gestão risco;
• Demonstrar que os requisitos de gestão de risco são respondidos pela arquitetura de processos
proposta pela norma ISO 31000 e pela norma ISO 27005;
• Demonstrar que é possı́vel aplicar um processo de gestão de risco comum entre domı́nios a
frameworks empresariais de processos, neste caso o COBIT5;
2
• Demonstrar que não faz sentido pensar na segurança da informação sem considerar a necessi-
dade de salvaguardar a continuidade de negócio, do mesmo mdo que não faz sentido salvaguar-
dar a continuidade de negócio sem assegurar a segurança da informação.
Cumprindos estes objetivos secundários a que me proponho consigo, atingir o meu objetivo principal
que, conforme referi, passa por provar que é possı́vel numa organização do mercado das tecnologias a
gestão de risco ser comum à segurança da informação e à continuidade de negócio.
3
Capı́tulo 2
Estado da Arte
2.1 Continuidade de Negócio
O conceito continuidade de negócio surge da necessidade das empresas desenvolverem mecanis-

mos formais que permitam num caso de catástrofe ou interrupção da sua atividade normal por qualquer
motivo, que o seu negócio continue a funcionar dentro da normalidade ou, pelo menos, que o core do
negócio continue a funcionar, permitindo a recuperação da empresa até que volte ao seu estado nor-
mal “capability of the organization to continue delivery of products or services at acceptable predefined
levels fllowing disruptive incident” [1].
A norma de referência hoje em dia é a norma ISO 22301 que é baseada na norma inglesa BS
25999. [3] Uma vez que a norma referência para o caso é da ISO, é de todo relevante analisar as
possı́veis relações entre os requisitos desta norma com as restantes normas de sistemas de gestão da
ISO.
Requisitos ISO 9001:2008 ISO 14001:2004 ISO 20000:2011 ISO 22301:2012 ISO 27001:2005
Objetivos do Sistema de Gestão 5.4.1 4.3.3 4.5.2 6.2 4.2.1
Polı́tica do Sistema de Gestão 5.3 4.2 4.1.2 5.3 4.2.1
Comprometimento da Gestão 5.1 4.4.1 4.1 5.2 5
Requisitos Documentais 4.2 4.4 4.3 7.5 4.3
Auditoria Interna 8.2.2 4.5.5 4.5.4.2 9.2 5
Melhoria Contı́nua 8.5.1 4.5.3 4.5.5 10 8
Melhoria 5.6 4.6 4.5.4.3 9.3 7
Tabela 2.1: Mapeamento entre pontos nas normas ISO. [2]
4
Conforme se constata pela tabela 2.1, existe uma forte correspondência entre as normas ISO para
sistemas de gestão, esta correspondência é sem dúvida um dos pontos fortes da norma ISO 22301, o
fator de se poder aproveitar e relacionar trabalho que já esteja desenvolvido noutras áreas.
Constata-se pois que esta facilidade em integrar sistemas de gestão ISO é um forte incentivo para
a implementação das suas normas de referência, neste caso a de Continuidade de Negócio.
2.1.1 A norma referência ISO 22301
Uma vez que a norma ISO 22301 é a norma referência hoje em dia para a Continuidade de Negócio
é de todo o interesse explorar o que ela determina. A norma ISO 22301 vem acrescentar alguns
conceitos que não eram introduzidos ou explicitados de forma clara na norma anterior: [3]
• Contexto da organização;
• Partes interessadas;
• Liderança;
• Tempo máximo aceitável de inoperabilidade;
• Objetivo mı́nimo de continuidade de negócio;
• Avaliação do desempenho;
• Priorização das janelas temporais;
• Alertas e comunicação.
Mantendo grande enfoque na norma BS 25999 e acrescentando os conceitos já referidos, a norma
ISO 22301 especifica um conjunto de requisitos para planear, estabelecer, implementar, operar, mo-
nitorizar, rever, manter e melhorar continuamente um sistema de gestão de continuidade de negócio,
fazendo uso do método da figura seguinte. [2]
Figura 2.1: PDCA [1]
5
Observa-se na figura 2.1, que o grande enfoque de todo o processo é a melhoria contı́nua do
sistema. Começando no planeamento, aqui estabelece-se a polı́tica, objetivos, controlos, processos,
tudo o que seja relevante no contexto da empresa para a continuidade do negócio. Na fase seguinte
proceder-se-á a implementação do plano e processos desenvolvidos, para que avançando para o ter-
ceiro passo se faça uma avaliação crı́tica do que se tem de mudar ou melhorar do plano original. Se
a avaliação for positiva, avança-se para o estágio final do processo, onde se fará uma manutenção
constante ao sistema, tendo sempre em linha de vista a sua melhoria. [1]
Conforme se tem vindo a explicitar, esta norma tem um grande enfoque em estabelecer objetivos,
monitorizar e melhorar com vista a um desenvolvimento contı́nuo que vá acompanhando a empresa ao
longo do seu tempo de vida. Esta norma tem como pontos chave [2]:
• Cláusula 4: Contexto da Organização;
• Cláusula 5: Liderança;
• Cláusula 6: Planeamento;
• Cláusula 7: Suporte;
• Cláusula 8: Operação;
• Cláusula 9: Avaliação do desempenho;
• Cláusula 10: Melhoramento.
Na cláusula 4, tendo explicitado a importância do contexto de uma organização, uma vez que cabe
à empresa definir quais os departamentos, processos, sistemas, ativos, etc..., que são relevantes para
a continuidade de negócio, até porque a própria organização opera num contexto também ele relevante
para o negócio e isso tem de ser tido em conta aquando do desenho da solução de continuidade. [1]
A cláusula 5 refere-se à liderança. O papel da liderança é fundamental, cabe a quem lidera a
organização onde o vai implementar, mostrar compromisso com a norma e motivar os colaboradores a
aderirem, envolvendo-os no processo. Analisando a cláusula 6, é lógico inferir que sem delinear objeti-
vos difı́cilmente se consegue algo. É crucial que haja um planeamento detalhado, consistente, flexı́vel
para que se possa ir adaptando, mensurável, e monitorizável. Só com objetivos que correspondam a
estas caracterı́sticas se consegue ir ao encontro do que estipula a norma. [2]
Na cláusula 7 explicita-se que “The day-to-day management of an effective business continuity ma-
nagement system relies on using the appropriate resources for each task” [2], ou seja, cabe a quem
lidera fornecer os meios adequados, em termos de know-how, de sistemas e ferramentas, para o cum-
primento dos requisitos da norma. A cláusula 8 está dependente da anterior, uma vez que só se con-
segue fazer uma correta operação se existir um suporte adequado, este é o ponto central desta norma,
começando pela Business Impact Analysis (BIA) é preciso analisar o impacto que cada disrupção pode
ter no negócio, em seguida avalia-se o risco associado a esse impacto, combinando-o com probabi-
lidade. Neste ponto a norma recomenda, para a aferição de risco, seguir a norma ISO 31000, este
processo para aferir o risco e geri-lo é o suporte de todo o plano, uma vez que tudo vai girar em torno
6
dos resultados que aqui se obtiverem. É igualmente nesta cláusula que se refere que uma organização
tem de implementar toda a polı́tica delineada anteriormente para que conforme é dito na cláusula 9 se
faça uma avaliação. A avaliação de desempenho pode ser feita de diversas formas: [2]
Tipo de Exercı́cio O que é? Benefı́cios Desvantagens

Checklist Distribuir planos para revisão Assegura que o plano alcança todas as atividades Não é eficaz
Assegura que as atividades planeadas
Tutorial estruturado Olha para cada passo do PCN Capacidade de resposta de baixo valor
são corretamente descritas no PCN
Cenário para ativar Quando os conjuntos são
Simulação Sessão prática
processos de recuperação muito diferentes
Teste total, no entanto o Assegura um alto nı́vel de fiabilidade Muito caro, envolve todos
Paralelo
processo primário não para sem interromper o quotidiano do negócio os colaboradores
O desastre é replicado
Interrupção Total Teste mais fiável do PCN Arriscado
ao ponto de parar o negócio
Tabela 2.2: Formas de avaliar o desempenho da polı́tica implementada. [2]
Como se observa na tabela 2.2, existem diversas formas de avaliar o desempenho, cabe ao gestor
do Sistema de Gestão de Continuı́dade de Negócio (SGCN) definir qual é a que melhor se adequa à
realidade da organização e do negócio. Por fim, a norma recomenda à organização entrar no ciclo da
cláusula 10, para periodicamente rever a sua polı́tica de forma a tentar torná-la cada vez mais eficiente
e eficaz de modo a responder aos desafios que forem surgindo. [2]
Um dos pontos cruciais para a elaboração de um plano de continuidade de negócio é a existência
de um processo de gestão de risco coeso e robusto de modo a que o alicerce do plano também o seja
(cláusula 8 da norma ISO 22301).
2.1.2 Gestão de Risco em Continuidade de Negócio - ISO 31000
Uma vez que a norma referência seguida para continuidade de negócio faz da norma ISO 31000 o
modelo a seguir para o processo de gestão de risco é de todo relevante analisar esta mesma norma.
A norma ISO 31000 descreve como se deve proceder para a gestão do risco, nesta norma encontra-se
definido de um modo genérico como se deve criar um processo formal de gestão de risco.
Antes de proceder à descrição do modelo que a norma ISO 31000 propõe é importante referir alguns
conceitos chave [4]:
• Gestão de risco cria e protege valor, contribuindo para a concretização dos objetivos e melhoria
de desempenho;
• Gestão de risco é uma ferramenta que auxilia os decisores nas suas escolhas, ajudando nomea-
damente a priorizar alternativas;
• O bom desempenho da gestão de risco está dependente da qualidade da informação, uma vez
que quanto melhor for a informação fornecida ao decisor, melhor ele poderá aferir o risco;
• O processo de gestão de risco deverá ser dependente do contexto, não estático de modo a poder
ser constantemente melhorado e bem estruturado;
7
• O processo de gestão de risco deve ser incorporado em todos os processos relevantes ao con-
texto.
Figura 2.2: Processo de gestão de risco. [4]
O ponto 5.2 da figura 2.2 recomenda fortemente que antes de se iniciar todo o processo, se desen-
volvam canais de comunicação com todas as partes interessadas, já que será preciso estar em cons-
tante contacto, ao definir antecipadamente os canais de comunicação, está a ganhar-se eficiência. [4]
Após definir como se irá proceder toda a comunicação, segundo a norma em causa, é preciso
definir o contexto (ponto 5.3), tanto interno como externo. O contexto interno determina onde e em que
âmbito, dentro da organização, é que se vai aplicar o processo de gestão de risco. É completamente
diferente avaliar o risco apenas na visão da segurança da informação, onde a principal preocupação
é a confidencialidade, integridade, e acessibilidade (CIA) da mesma, do que olhar para o risco na
perspetiva da continuidade de negócio, onde o fundamental é manter os processos fulcrais ao negócio
o mı́nimo tempo possı́vel sem funcionar. O contexto externo determina em que condições se aplica a
gestão de risco, quer em termos de ambiente, quer em termos de partes interessadas, por exemplo
uma situação de crise económica afeta o risco com partes interessadas externas ou condiciona ainda
mais os investimentos. É ainda neste ponto que se deve definir os objetivos e os critério de risco a
utilizar. [4]
Uma vez definido o contexto, passa-se para a tarefa central de todo o processo, aferir o risco (ponto
5.4). Na aferição de risco temos 3 passos [4] :
• Identificação do risco:
Esta tarefa é a primeira da aferição do risco, onde é necessário identificar todas as fontes de risco
e suas áreas de impacto, eventos, causas e consequêcias. O principal objetivo é gerar uma lista
de riscos com base nos eventos que podem gerar esses mesmos riscos. Ao contrário do que
se poderia pensar deve ter-se em conta fontes de potencial risco que não sejam do controlo da
organização, isto é, deve considerar-se o risco sistémico.
8
• Análise do risco:
Aqui o objetivo é criar informação para a tarefa seguinte. Ao analisar o risco pretende-se perceber,
causas, efeitos, probabilidade de as consequências acontecerem, assim como os fatores que
afetam tanto a consequência como a ocorrência. Nesta análise, pode haver um evento a afetar
diversos objetivos, da mesma forma que diversos eventos podem afetar o mesmo objetivo.
• Aferição do risco:
Pretende-se com esta aferição auxiliar a tomada de decisões, tendo como base a análise já feita.
Aferição é feita comparando o nı́vel de risco obtido na análise com os critérios de risco definidos,
caso assim se justifique o risco terá de ser tratado. Poderá acontecer que a aferição recomende
uma análise mais profunda ou até mesmo não proceder a qualquer ação corretiva.
Concluı́da a aferição do risco e consoante o resultado aı́ obtido, é feito o tratamento do risco, este
tratamento passa por decidir se:
• O nı́vel de risco é tolerável;
• Caso não o seja, gerar novos controlos no risco;
• Aferir a eficácia dos controlos gerados.
Os controlos a efetuar podem ser para parar uma atividade, aumentar o risco (caso se pretenda
aproveitar uma oportunidade), remover a fonte de risco, mudar a probabilidade de ocorrência, mudar
as consequências ou partilhar o risco com terceiros. [4]
Para decidir qual o melhor controlo é necessário ter em conta o esforço que será preciso para o
controlo funcionar, e quanto é que vai custar. Estes fatores, por vezes, podem levar à organização
aceitar o risco. Por norma as organizações beneficiam quando os controlos são combinados, isto é,
quando os controlos não são aplicados individualmente. Ao delinear controlos o gestor do risco não
deve esquecer que o próprio tratamento introduz risco em caso de incumprimento ou mau planeamento.
[4]
Após estas iterações e, como estamos perante um processo cı́clico, devem ser feitos testes e
manutenção de forma regular ao processo de gestão de risco, mantendo-o assim sempre o mais atua-
lizado possı́vel, de modo a responder às necessidades atuais da organização.
2.2 Segurança da Informação
O principal objetivo da segurança da informação é preservar a disponibilidade, confidencialidade

e a integridade da informação. Pode também envolver a proteção e preservação da autenticidade da
informação assegurando assim que a informação é de confiança. Uma organização que implemente
um sistema de gestão da segurança da informação transmite igualmente uma imagem de confiança
para o exterior, o que é de extrema importância nos dias de hoje. [7]
No domı́nio da segurança da informação há conceitos chave que é preciso ter em conta [7]:
9
• Ameaça: Causa potencial de um incidente indesejável, pode prejudicar um sistema ou a organiza-
ção;
• Vulnerabilidade: Fraqueza de um ativo ou controlo que pode ser explorada por uma ou mais
ameaças;
• Evento: Ocorrência ou mudança de um conjuto particular de circunstâncias;
• Consequência: Resultado de um evento que afeta os objetos;
• Controlo: Medida que modifica o risco;
• Impacto: Mudança negativa no nı́vel dos objetivos de negócio alcançados;
• Ativo: Qualquer coisa que tenha valor para a organização.
Os ativos (neste caso, ativos de informação) têm de ser protegidos através da definição, alcance,
manutenção e melhoria eficaz da segurança da informação, mantendo e melhorando o seu cumpri-
mento legal e imagem. Estas atividades coordenadas apontam para a implementação de controlos
adequados que tratam riscos inaceitáveis para a segurança da informação. [7]
As decisões estratégicas relativas à segurança da informação devem estar em concordância com os
stakeholders, e todos os parceiros relevantes. É muito importante que a segurança da informação esteja
integrada nos processos e estrutura da organização de forma a alcançar os objetivos propostos. [7]
2.2.1 A norma referência ISO 27001
A norma ISO 27001 especifica os requisitos para estabelecer, implementar e manter de forma
contı́nua um sistema de gestão da segurança da informação numa qualquer organização. [5]
Do mesmo modo que as restantes normas ISO sobre sistemas de gestão já abordadas neste re-
latório, esta norma tem como cláusula inicial para a definição do sistema de gestão, (cláusula 4) a
definição do contexto da organização, perceber partes interessadas, parceiros, definir critérios e requi-
sitos a cumprir, onde aplicar a norma. [5]
Na cláusula 5, esta norma frisa a importância do comprometimento da gestão de topo na organização,
passando para a definição de uma polı́tica de segurança da informação. A polı́tica deve estar alinhada
com os interesses da organização, definir os objetivos da segurança da informação e comprometer-se
com a aplicação dos requisitos para a segurança da informação e a melhoria contı́nua do sistema de
gestão. O último ponto desta cláusula refere-se à atribuição de responsabilidades e papéis relativos à
segurança da informação. [5]
A cláusula 6 desta norma pode ser interpretada à luz da norma ISO 31000, uma vez que é aqui que
se faz a aferição do risco da segurança da informação. Espera-se que neste ponto a organização já
tenha definido qual o critério para aceitar ou não risco e o critério para realizar a aferição do mesmo
risco, assim como os objetivos que pretende atingir para a segurança da informação. Todo o processo
descrito vai de encontro à figura 2.2. A aferição é composta por identificar, analisar e aferir o risco da
10
segurança da informação sendo, por fim, executado o tratamento adequado ao risco (pode ir desde a
implementação de controlos à aceitação do risco). [5]
De seguida, na clásula 7, é referida a questão da importância da gestão dar suporte ao sistema,
quer seja em termos orçamentais, quer em fornecer o conhecimento técnico a colaboradores caso
isso seja relevante. É igualmente referido à semelhança das ISO 22301 e ISO 31000 a importância
de estabelecer canais de comunicação e informar devidamente todas a partes interessadas sejam
estas internas ou externas. Existe, também, referência à questão do controlo documental, este ponto
relaciona-se com a norma ISO 9001. [5]
Em termos operacionais e de avaliação de desempenho (cláusulas 8 e 9, respetivamente) a organi-
zação deve proceder à aferição do risco, ao controlo operacional dos processos criados para responder
aos objetivos de forma regular, à avaliação regular do desempenho do sistema e que seja avaliado
com base em auditorias internas com a consequente revisão do resultado por parte da gestão de topo.
Assim, pretende-se identificar de forma sistemática possı́veis falhas e proceder à melhoria contı́nua do
sistema (cláusula 10). [5]
2.2.2 Gestão de Risco na Segurança da Informação - ISO 27005
Esta norma ISO especifica os requisistos para um processo de gestão de risco da segurança da
informação de acordo com a norma ISO 27001, que pode ser aplicada de um modo abrangente a toda
a organização ou apenas a uma parte da mesma (sistema, departamento, por exemplo), ou aspetos
de controlo como um plano de continuidade de negócio o que é deveras relevante para o projeto a
desenvolver. [7]
O processo a desenvolver nesta norma deve ter por base uma abordagem iterativa onde, se ne-
cessário, se deve aprofundar a abordagem na aferição em cada iteração. Nesta norma está definido
um processo de gestão do risco na segurança da informação com o método PDCA, consistindo nos
seguintes passos: [7]
• Plan:
Estabelecer contexto (ver normas ISO 27001 cláusulas 4/5 e ISO 31000 cláusula 5.3);
Aferir o risco (ver ISO 31000 cláusula 5.4);
Desenvolver um plano de tratamento do risco. O objetivo passa por identificar os controlos que
são precisos para reduzir, reter, evitar ou transferir o risco.
• Do:
Implementar o plano de tratamento do risco (ver ISO 31000 cláusula 5.5).
• Check:
Monitorizar e rever (ver ISO 31000 cláusula 5.6), ter em especial atenção alterações que novos
ativos, vulnerabilidades ou ameaças possam trazer para a organização.
• Act:
Manter e melhorar o processo de gestão de risco recorrendo à monotorização e revisão cı́clica do
mesmo.
11
Figura 2.3: Processo de gestão de risco norma ISO 27005. [7]
Como se pode ver pela figura 2.3 nem sempre, é possı́vel tratar o risco na primeira iteração, sendo
precisas novas iterações para o levar a um nı́vel que seja aceitável, nesta fase é deveras relevante
assegurar que os riscos são aceites pela gestão de topo, principalmente quando questões orçamentais
fazem adiar controlos. Nesta abordagem temos a etapa de tratamento do risco dividida em: [7]
• Ordenar o tratamento dos riscos por prioridade;
• Decidir se o nı́vel do risco já é aceitável;
• Gerar novo plano de tratamento se o nı́vel não se aceitar;
• Avaliar a eficácia do novo tratamento.
O objetivo deste processo é contribuir para identificar riscos e aferir as suas consequências, fazendo
o seu relatório pelos canais de comunicação criados, envolvendo assim todas as partes interessadas no
processo. Conseguir estabelecer uma priorização do tratamento dos riscos de modo a poder aplicar em
primeiro lugar controlos aos riscos mais crı́ticos e urgentes (noção de continuidade de negócio, primeiro
vem o fulcral do negócio, depois vem o resto). Criar um processo eficaz no tratamento e monitorização
do risco através de iterações cı́clicas que proporcionem uma revisão periódica do processo. [7]
12
2.3 Aferição de Risco em Continuidade de Negócio e Segurança
da Informação
Após analisar as duas temáticas, continuidade de negócio e segurança da informação, é importante
perceber se existe forma de ter um processo de gestão de risco que seja adequado às duas normas
referência. Ao analisar as duas normas percebeu-se que ambas têm a norma ISO 31000 como norma
referência para a gestão de risco, sendo que no caso da segurança da informação existe uma aplicação
mais concreta da ISO 31000 como já se analisou. Deste modo a norma ISO 27005 é bom ponto de
partida, no entanto há que escolher a técnica de aferição de risco que mais se adequa ao caso.
2.3.1 BIA - ISO 31010
A norma ISO 31010 explicita um conjunto de técnicas de aferição de risco que se podem aplicar em
qualquer processo de gestão de risco que tenha a norma ISO 31000 por base.
Na norma ISO 31010 vem a técnica de Business Impact Analysis, que é uma técnica de aferição
de risco muito usada em continuidade de negócio, sendo, assim, escolhida para usar no processo de
gestão de risco. [1] Esta técnica, embora amplamente usada neste meio, não tem uma concretização,
existindo sim guidelines, nomeadamente na norma ISO 31010, que fornecem a ideia geral de como
se deve proceder. Esta limitação abre a oportunidade de cada um poder adaptar esta técnica às suas
necessidades o que é de extrema importância visto que temos de conciliar a segurança da informação
com a continuidade de negócio.
Segundo esta norma ISO o BIA analisa como é que disrupções causadas por riscos chave afetam o
negócio de uma organização, identificando e quantificando que recursos são precisos para gerir estes
impactos. [6]
A norma ISO identifica três pontos-chave desta técnica [6]:
• Identificação e criticidade dos processos chave para a organização, atividades e ativos associa-
dos, assim como as interdependências chave que existam para a organização;
• Como os eventos que geram disrupção ao negócio vão afetar os objetivos de continuidade de
negócio;
• Recursos necessários para gerir o impacto de uma disrupção e recuperar a organização para
nı́veis aceitáveis de operação.
Esta técnica é usada para definir a criticidade e tempos de recuperação dos processos e ativos
associados de modo a assegurar que se continua a alcançar os objetivos da organização. Os recursos
precisos para aplicar esta técnica são [6]:
• Uma equipa para fazer a análise e desenvolver o plano;
• Informação sobre os objetivos fundamentais, ambiente, operações e interdependências da organização;
13
• Detalhes dos processos da organização, relações com outras organizações, outsourcing e sta-
keholders;
• Consequências financeiras e operacionais da perda de processos crı́ticos;
• Lista de intervenientes de áreas relevantes para a organização e/ou stakeholders que serão con-
tactados.
O processo para o BIA segundo a norma ISO 31010 pode ser feito através de questionários, entre-
vistas, workshops ou combinando duas ou mais destas técnicas que devem ser utilizadas com o objetivo
de obter uma melhor perceção da criticidade dos processos, dos efeitos de perda desses processos no
negócio, os tempos de recuperação e recursos necessários. [6]
Os pontos-chave que é preciso ter em consideração num qualquer BIA, segundo a norma ISO
31010, são [6]:
• Confirmação dos processos chave da organização com base no seu output e determinar a critici-
dade dos mesmos. As vulnerabilidades e o risco poderão ser indicadores úteis para este ponto;
• Determinar as consequências da disrupção nos processos crı́ticos em termos financeiros e ou

operacionais, em perı́odos definidos;
• Identificar as interdependências entre stakeholders internos e externos;
• Determinar a quantidade de recursos que estão disponı́veis e qual é o nı́vel de recursos que são
precisos para continuar a operar num nı́vel aceitável após uma disrupção;
• Identificar alternativas para quando um processo está indisponı́vel;
• Determinar tempos crı́ticos: RTO, RPO, MTPD.
No fim deste processo de acordo com a norma, deve-se produzir uma lista de processos crı́ticos
e suas interdependências, documentar os impactos que os processos têm no negócio nas diversas
vertentes, fornecer os recursos adequados às necessidades de cada processo. É também esperado
que estejam definidos os tempos em que cada processo crı́tico pode estar sem funcionar corretamente
e em recuperação. [6]
A norma ISO 31010 identifica um conjunto de prós e contras nesta técnica, nos prós temos o apro-
fundar do conhecimento dos processos da organização, que dota a organização da capacidade de
continuar a atingir os seus objetivos. Um outro ponto positivo é conseguir obter a lista de recursos
que são precisos para alcançar os objetivos e a oportunidade que é dada de reformular e melhorar os
processos da organização para que ela se torne mais resiliente. [6]
Por outro lado, os contras do BIA, para esta norma ISO, são a falta de conhecimento de todos os
participantes em realizar questionários e entrevistas, o facto de as dinâmicas de grupo poderem afetar
uma análise completa aos processos crı́ticos. O facto de as expectativas nos requisitos de recuperação
serem demasiado otimistas é outro fator apontado, assim como o facto de não se obter o conhecimento
adequado das atividades da organização. [6]
14
2.3.2 BIA - Fundamentos
O Business Impact Analysis é, sem dúvida, o produto mais importante e fundamental do ciclo de
vida da continuidade de negócio. É através da realização do BIA que os requisitos da organização no
que diz respeito a responder a desastres são respondidos de forma apropriada. [9]
Business Impact Analysis é definido1 como a analı́se ao nı́vel da gestão através do qual uma
organização realiza a aferição quantitativa dos impactos financeiros e a aferição qualitativa dos im-
pactos não financeiros, que podem resultar de uma situação onde a organização seja sujeita a uma
emergência de continuidade de negócio, seja por um incidente de segurança ou por uma crise. Os re-
sultados obtidos no BIA são usados para tomar decisões relacionadas com a estratégia e as soluções
para a continuidade de negócio. [9]
Por outras palavras, o BIA ajuda a identificar qual é o custo de interromper o negócio, qual o impacto
que essa paragem tem nos lucros na organização, nas receitas, quão danificada fica a relação com
clientes e a imagem exterior da organização. Para além de ajudar a fazer esta identificação, esta técnica
permite ainda que o gestor do negócio entenda melhor qual o tempo de paragem que cada processo
pode tolerar antes de o impacto acontecer e quais sãos recursos(pessoas, IT, outros processos, etc) do
qual este processo depende. [9]
O resultado ideal do BIA ao contrário do que se possa pensar é alcançado quando se consegue
fazer a identificação exata dos recursos que são precisos para proteger, recuperar e quão rápido se
consegue recuperar um processo de modo a conseguir manter um nı́vel de serviço aceitável. [9]
Ter esta definição em mente é muito útil porque ajuda a focar o BIA nos impactos de um evento
e não na causa do mesmo. Muitas organizações ficam profundamente focadas no exterior do BIA ao
estarem constantemente a definir possı́veis cenários, o que acaba por prejudicar a própria organização
pois acaba por se atrasar mais o processo e confundir os participantes. No fim de contas no BIA o que
não importa é se a interrupção do negócio foi causada por uma falha de energia, um incêndio ou outra
situação qualquer, o que importa ao realizar esta técnica é que uma vez que o negócio parou saber as
consequências e quão rápido se consegue recuperar. [9]
Por outro lado é sempre uma boa prática ter um conjunto de contextos de alto nı́vel pré estabelecidos
para se conseguir orientar de uma forma mais rigorosa o BIA. Ao pré estabelecer um conjunto de
cenários está a ajudar-se quem realiza o BIA pela primeira vez e como têm de orientar a sua linha de
pensamento. Estes cenários devem ser o mais explı́citos e de alto nı́vel possı́vel. Alguns cenários que
costumam ser utilizados são [9]:
• Edifı́cio da sede e/ou datacenter deixa de estar disponı́vel;
• O IT da organização deixa de funcionar parcial ou totalmente;
• Um ou mais processos da organização deixam de poder ser executados;
• Uma combinação dos anteriores.

1 Business Continuity Institute - Glossary
15
Um dos erros comuns ao realizar o BIA pela primeira vez é querer logo a partir dos primeiros
resultados criar o plano de continuidade de negócio. Esta abordagem assume que a organização
vai estar pronta para agir consoante as surpresas que possam emergir do BIA. Para se conseguir
suceder neste tipo de abordagem é essencial que haja um alto comprometimento da gestão e que
sejam alocados todos os recursos necessários. Num estágio inicial de contato com a continuidade
de negócio pode ser a melhor estratégia atrasar a realização do BIA até a continuidade de negócio
estar mais esclarecida dentro da cultura e polı́tica da organização, tal a necessidade de não produzir
resultados enganadores, a não ser que a gestão da organização já esteja a antecipar a necessidade
de atuar nos resultados obtidos. [9]
Deste modo, pode afirmar-se que para iniciar o BIA é necessário: [9]
• Um comprometimento claramente assumido por parte da gestão em alcançar os objetivos da

continuidade de negócio;
• A indicação de que existe uma vontade da organização de investir em soluções para a área da
continuidade de negócio que irão surgir com a ajuda dos resultados do BIA;
• Uma declaração na polı́tica da organização com o âmbito que tenciona atribuir ao plano de conti-
nuidade de negócio.
2.3.3 BIA - Passo 1: Definir Âmbito
O primeiro passo para a aplicar o BIA é definir o âmbito no qual se vai aplicar esta técnica. Este
passo pode-se subdividir em dois pontos:
Primeiro - a gestão de topo deve decidir se o BIA é para aplicar a toda a organização ou apenas
a uma parte da mesma (departamento, processo, etc...). Os fatores a ter em conta para tomar esta
decisão devem incluir o tamanho e a complexidade do negócio, a diversidade de processos que se vai
encontrar e principalmente os recursos disponı́veis (pessoas) para fazer o BIA. [9]
Está definido como boa prática que em organizações de grande dimensão o processo do BIA deve-
se começar por aplicar em apenas uma parte da organização, de preferência na que está motivada para
o aplicar. Esta abordagem de fazer um projeto piloto em primeiro lugar garante que o processo é bem
compreendido pelos colaboradores e que os resultados que resultam do processo são de qualidade e
consistentes de modo a poderem ser mais tarde. [9]
Segundo - Antes de se perguntar ao negócio o que é crı́tico em situação de desastre, é preciso
garantir que está claramente definido o âmbito de aplicação do BIA, é aconselhável à gestão elaborar
uma polı́tica para o BIA e definir qual é o perı́odo de interrupção que se vai estar a lidar na análise. Pode-
se descrever este passo como o ’planeamento do horizonte’ que será determinado por um conjunto de
fatores [9]:
• BIA a ser desenvolvido por subsidiárias dentro de um grupo empresarial, ou departamento dentro
de uma organização, devem considerar o impacto que possam ter no resto quer do grupo/departamentos,
quer o impacto que a organização tem em outros players no negócio;
16
• Para algumas organizações está determinado como objetivo recuperar o negócio e resumir todos
os processos dentro de uma linha temporal pré-definida, no entanto tal objetivo pode não ser
realizável se estivermos a falar de uma multinacional, é necessário ter em conta quer o negócio
quer a dimensão da organização, a melhor solução pode passar mesmo por uma recuperação
gradual em muitos casos;
• Para facilitar uma técnica útil é começar por realizar questões de alto nı́vel para determinar qual
é o ’planeamento do horizonte’ que melhor se adequa à realiade do negócio, há requisitos que se
tem de ter em conta, um negócio na área dos serviços tem tempos e requisitos que uma fábrica
não tem e vice-versa;
2.3.4 BIA - Passo 2: Recolher dados
Uma das partes mais difı́cieis do BIA é definir e comunicar com o negócio o que realmente se
pretende. Excepto em casos anormais, o normal é que tudo, ou quase tudo, numa organização possa
em teoria ter a capacidade de vir a ser considerado crı́tico com o decurso do BIA. No entanto, mantendo
o planeamento definido o interesse é em encontrar o que pode ser crı́tico apenas dentro desse plano
delineado. É claro que isto é um argumento mais a favor de criar esta polı́tica do BIA que define de
forma clara qual o limite de dados a ser recolhidos e o que deve ser reportado em todo o processo.
Neste passo do processo há 3 questões que são essenciais de responder. [9]
1. O que deve ser incluido no âmbito do BIA?
2. O que deve ser colocado de parte? Quer por não fazer parte do âmbito do BIA, quer por não
representar um impacto significativo dentro do horizonte planeado.
3. Como combater a tendência humana de considerar tudo o que fazemos como importante e dife-
renciar isso do que é realmente crı́tico?
Para conseguir responder às duas primeiras perguntas é preciso ter um conhecimento do negócio,
pelo menos de um ponto de vista topo-baixo em termos do impacto que uma interrupção no negócio
iria causar. Geralmente uma discussão com os stakeholders de maior peso irá produzir uma solução
que seja de acordo com o a organização. [9]
Uma parte importante da análise é identificar onde é que uma atividade/processo que fica dentro do
âmbito do BIA é dependente de uma atividade/processo que ficou posto de parte por não se equadrar
no âmbito previamente delineado. Este tipo de dependências sendo quase inevitáveis constituı́ um bom
barómetro para o BIA pois um BIA que não revele surpresas destas quando feito pela primeira vez,
pode em grande parte dos casos significar que a análise não teve rigor. Ao considerar o que deve
ou não fazer parte do âmbito não se deve descurar o fato de um contı́nuo acumular de carga num
dado processo pode resultar se não considerado numa surpresa bastante desagradável na fase de
recuperação. [9]
Diferenciar importancia de criticidade é outro desafio do BIA nesta etapa de recolher dados, tipica-
mente uma forma de responder a este problema é criar uma matriz de pontuações que pontua e mede
17
as interrupções num dado processo em termos de perdas de receita, danos na reputação, danos no
consumidor ou relações com parceiros, entre outros que possam ser relevantes no âmbito do negócio
da organização. O desafio aparece em quase todas as tentativas de pontuar processo recorrendo a
esta alternativa é o fato de algumas ’medições’ serem muito difı́ceis de fazer, nestes caso a decisão
final caberá à gestão da organização que deverá desenhar uma linha entra o importante e o crı́tico. [9]
Existem diversos métodos para obter dados para o BIA, os mais utilizados são [9]:
• Questionários - Distribuir aos colaboradores responsáveis nas áreas de negócio dentro do âmbito
do BIA para que eles preencham;
• Questionários - Para serem preenchidos de forma bi-lateral no âmbito de reuniões ou entrevistas;
• Workshops ou mesas de discussão. (Esta abordagem pode ser útil para obter uma visão mais
equilibrada da criticidade dos processos, no entanto há o periodo de um colaborador senior por
exemplo force a sua opinião no grupo.)
A forma ideal de fazer este passo pode passar por combinar os métodos acima referidos, começar
numa acção de sensibilização para explicar e determinar de forma clara os conceitos do BIA, objetivos
e âmbito, seguindo-se de um questionário inicial de simples preenchimento, neste questionário o ideal
é manter as coisas simples e não perguntar mais do que “caso haja uma disrupção no negócio e o seu
processo parar isso leva a um impacto negativo na organização?”. [9]
Esta abordagem só vai funcionar conforme esperado se obviamente a acção de sensibilização correr
conforme previsto e todos os participantes compreendam corretamente a mensagem. Neste ponto
do processo o BIA é extremamente dependente da interpretação que é feita pelas pessoas. Uma
forma de ajudar na realização deste questionário é a priori realizar um programa de mapeamento dos
processos para identificar ativos e interdependências. Desta forma consegue-se uma melhor imagem
da realidade do negócio o que ajuda a decidir a existência ou não de impactos, também se consegue
reduzir significativamente o risco de não olhar para uma dependência que possa ser crı́tica. [9]
Algumas vantagens de utilizar um questionário inicial simples são [9]:
• Identificar possı́veis inconsistências na aferição de criticidade;
• Identificar possı́veis inconsistências entre a discussão do âmbito e o definido no passo 1;
• Eliminar processos/atividades não crı́ticas do âmbito do BIA;
Após esta tarefa é necessário recolher ainda mais informação e definir mais alguns conceitos, uma
vez que é preciso informação com maior detalhe por parte do negócio, aqui aconselha-se a um ques-
tionário ou entrevista um pouco mais sofisticado para obter a informação pretendida. A informação que
se pretende agora obter é [9]:
1. Os requisitos temporais, MTPD e RTO;
2. Calendário dos processos;
18
3. Objetivo de recuperação (RPO);
4. Dependências dos processos;
5. Recursos necessários para a recuperação;
O RTO é o tempo de recuperação, ou seja quanto tempo é que deve demorar a recuperar o pro-
cesso/negócio desde que houve o incidente. O RTO é um objetivo que a organização se deve propor
a alcançar, o que significa que muitas vezes não se consegue cumprir e por isso existe outra medida
temporal o MTPD que define a janela temporal máxima que se pode estar com o processo/negócio
sem funcionar de todo. Ao definir estes tempos há quem ter em consideração o tempo para pensar, o
tempo para mobilizar recursos e o tempo para criar o ambiente próprio para recuperar do incidente. No
entanto há que pensar corretamente nestes tempo, nomeadamente a nı́vel da gestão porque quanto
mais depressa se tem de recuperar algo mais dinheiro se tem de gastar e cabe à gestão de topo fazer
esse trade-off. [9]
O ponto do calendário é muito especı́fico, pode não se aplicar em todas as organizações, aqui
o importante é perceber se o processo é sempre contı́nuo no tempo ou se respeita algum ciclo de
atividade operacional, isto é importante para escalar o trabalho necessário no momento da recuperação.
[9]
O RPO é outra variável temporal, aqui define-se a quantidade de informação que é preciso reter para
recuperar o processo/negócio. Pode haver negócios que suportem recuperar através de um backup de
há 1 semana ou mais tempo, enquanto que há negócio como por exemplo a banca onde os dados têm
de estar atualizados ao segundo. E é preciso ter esta consideração quando se define o RPO do mesmo
modo que à semelhança do RTO e MTPD quanto menos tempo mais dinheiro é preciso para cumprir
os objetivos. [9]
O ponto das dependências caso já se tenha feito o processo de mapeamento fica finalizado, no
entanto caso não se tenha feito é neste momento obrigatório proceder a esse levantamento de modo a
identificar tudo do qual cada processo depende, nunca esquecendo as dependências entre processos
e sub-processos. [9]
Após todas as definições anteriores é importante definir quais são os recursos necessários, quando
se fala de recursos fala-se de tudo o que é necessário, IT, locais, orçamento, colaboradores, todo o
tipo de ativos que a organização possa ter. Este ponto toma especial importância para evitar duplas
contagens de recursos, por exemplo se 10 colaboradores são precisos para recuperar o processo B
mas 4 já foram destacados para o processo A então apenas há um incremento de 6 colaboradores. É
também importante identificar se é necessário algum tipo de fornecedor. [9]
19
2.3.5 BIA - Passo 3: Moderação e Relatório
Este passo 3 serve para fazer a moderação dos resultados obtidos, das surpresas que possam ter
surgido e assegurar que tudo o que foi feito é razoável. A experiência tem mostrado que este passo é
muito importante uma vez que ajuda a garantir que a qualidade do BIA. [9]
A Moderação é um processo de duas fases, em primeiro lugar há que aferir a validade dos dados que
resultaram da recolha previamente realizada para a definição dos requisitos operacionais. Em seguida
é necessário responder às implicações da informação obtida, ou seja, responder de forma adequada
às diferenças entre os resultados obtidos e as capacidades de recuperação reais da organização, a
resposta terá de ser razoável uma vez que nem tudo poderá ser alterado. Alguns método para fazer
esta moderação são [9]:
• Comparar o output BIAS anteriores, existe alguma razão válida para haver diferenças nos resul-
tados? Resulta de mudanças no negócio? Explicita apenas uma diferença de opinião por ser feito
por pessoas diferentes?
• Comparar o output obtido com o que se obteve em departamentos ou unidades de negócio si-
milares que já tenham feito um processo similiar, desta forma tenta-se saber se os resultados
são coerentes ou não com processos semelhantes. Aqui há que ter em conta especificidaes do
processo pois isso pode provocar uma discrepância nos resultados o que não significa que os
mesmos estejam errados.
• Recorrer a um consultor ou colaborador(es) sénior, recorrendo a alguém já com experiência

consegue-se uma visão diferente que pode identificar erros na abordagem ou justificar discrepãncias.
O relatório final do BIA deve apresentar os requisitos operacionais, é importante reforçar que o
relatório deve ser limitado ao objetivo do BIA, ou seja, não se deve exigir que apresente uma estratégia
do que se deve fazer e como se deve fazer. Essa parte é responsabilidade de uma aferição de risco
posterior e do risk appetite da organização. O relatório deverá ser redigido de modo a fazer uma “prova
cabal”que satisfaça uma auditoria posterior, os principais temas a abordar neste relatório são [9]:
• Objetivo e âmbito do BIA;
• Polı́tica, definições que suportam o BIA;
• Descrição dos métodos usados para fazer o BIA;
• Explicação do porquê da validação dos dados no passo da moderação;
• Explicitação clara dos resultados inconclusivos;
• Indicação das consequências da aceitação ou não dos resultados do BIA;
• Inclusão de resultados especı́ficos da análise.
20
Dependendo do tamanho da organização a revisão e melhoria do BIA poderá ser feita com intervalos
de tempo diferentes, por norma em organizações pequenas e menos complexas o BIA deverá ser revisto
anualmente ou quando há mudanças significativas no negócio. No entanto é importante garantir que
no limite pelo menos a organização faz um BIA total a cada triénio. [9]
2.4 COBIT 5
O COBIT 5 fornece uma framework que auxilia as organizações a alcançar os seus objetivos em
termos de governance e gestão do IT empresarial. De certo modo pode-se afirmar que o COBIT 5 ajuda
a criar um valor otimizado para o IT, através da manutenção de um trade-off entre a concretização de
benefı́cios e a optimização dos nı́veis de risco e uso de recursos. O COBIT 5 permite que o IT seja
gerido de uma forma holı́stica dentro de toda a organização, trazendo a si a totalidade do negócio e
todas as áreas funcionais de IT com responsabilidades, aqui considera todos os interesses relacionados
com IT de stakeholders internos e externos. O COBIT 5 é genérico e útil a todo o tipo de organizações
quer em termos de tamanho, quer seja comercial, OSFL ou setor público. [8]
Figura 2.4: Principios do COBIT 5. [8]
Conforme a figura 2.4 o COBIT 5 têm 5 princı́pios chave para o governance e gestão de IT empre-
sarial [8]
• Princı́pio 1: Ir de encontro às necessidades dos stakeholders - As organizações existem com o

objetivo de gerar valor para os seus stakeholders através da manutenção de um trade-off entre
a otimização de riscos, uso de recursos e a obtenção de benefı́cios. O COBIT 5 fornece todo o
tipo de processos necessários para suportar a criação de valor no negócio através do uso das TI.
Devido ao fato de cada organização ter o seu próprio contexto e cultura o COBIT 5 é adaptável a
cada realidade podendo ser configurado consoante as necessidades próprias de cada caso.
21
• Princı́pio 2: Abrange a organização na sua totalidade - O COBIT 5 integra o governance de IT no
governance da organização:
– Cobre todos processos e atividades dentro da organização, não se foca apenas no IT, re-
laciona sim a informação e tecnologias como ativos que devem ser tratados como qualquer
outro ativo.
– Considera que o âmbito de todo o governance e gestão relacionada com o IT é a toda a

organização, ponta a ponta, incluido tudo de todos, seja interno ou externo, desde que seja
relevante para a gestão da informação e relacionado com o IT.
• Princı́pio 3: Aplicar uma framework única e integrada - Existem muitas normas e boas práticas
relacionadas com o IT, cada uma orientando um determinado conjunto de atividades. O COBIT 5
faz o alinhamento de alto nı́vel entre normas e frameworks relevantes, conseguindo assim unificar
tudo numa só framework para governance e gestão de IT.
• Princı́pio 4: Permitir uma aborgadem holı́stica - Uma governance e gestão de IT eficiente e eficaz
requer uma abordagem holı́stica, tendo em consideração todas as componentes em interação.
O COBIT 5 define um conjuto de facilitadores para suportar a implementação de um sistema de
gestão e governance de IT compreensivo. Estes facilitadores podem ser definidos como qualquer
coisa que ajude a organização a alcançar os seus objetivos. O COBIT 5 define sete categorias de
facilitadores:
– Pincı́pios, polı́ticas e frameworks;
– Processos;
– Estruturas organizacionais;
– Cultura, ética e comportamento;
– Informação;
– Serviços, infraestrutura e aplicações;
– Pessoas, qualidades e competência.
• Princı́pio 5: Seprar governance da gestão - O COBIT 5 faz uma clara distinção entre a governance
e gestão. Estes dois termos englobam tipo de atividades diferentes, tendo requisitos diferentes
no que a estruturas organizacioanais necessárias diz respeito e de igual modo terem propósitos
diferentes. A distinção feita pelo COBIT 5 é:
– Governance - Assegura que as necessidades dos stakeholders, condições e opções são

avaliadas para determinar o melhor trade-off possı́vel sob o qual os objetivos da organização
devem ser atingidos. Determina direção a seguir através da tomada de decisão e priorização.
É também responsável por monitorizar o desempenho e o cumprimento dos objetivos defini-
dos.
22
– Gestão - Planeia, constrói, executa e monitoriza atividades de acordo com a direção definida
pela governance de modo a alcançar os objetivos da organização.
Como podemos ver pela figura 2.5 o COBIT 5 não é prescritivo, aconselha sim a organização a
implementar os processos de governance e gestão de modo a que pelo menos as áreas chave sejam
cobertas. Uma vez que cada organização tem uma realidade própria ela deve organizar os seus pro-
cessos de acordo com o que acha que melhor se adequa à sua realidade, desde que garanta que as
áreas chave fazem parte do âmbito de aplicação do COBIT 5. [8]
Na figura 2.6 podemos observar o modelo referência de processos conjunto de governance e de
gestão que o COBIT 5 define e descreve em detalhe. Este conjunto representa o que em regra geral se
encontra numa organização relacionada com IT, deste modo fornece uma base comum e um modelo
de referência compreensı́vel que auxilia os gestores de negócio e operacionais de IT. Este modelo
proposto apesar de completo e compreensivo não é o único modelo possı́vel, uma vez que se deve ter
em conta as especı́ficidades de cada organização. [8]
Incorporar um modelo operacional de linguagem comum a todas as partes da organização relacio-
nadas com o IT é um dos maiores desafios para uma governance de referência. Como se observa na
figura 2.6 o modelo divide os processos da organização em duas grandes áreas:
• Governance - Cinco processos, dentro de cada processo são definidas práticas de avaliação,
direção e monitorização (EDM).
• Gestão - Têm 4 domı́nios em linha com áreas de responsabilidade de planeamento, construção,

execução e monitorização (PBRM), e fornece uma cobertura ponta-a-ponta para o IT. Os nomes
dos domı́nios são escolhidos em linha com a designação destas áreas principais:
– Alinhar, Planear e Organizar (APO);
– Construir, Adquirir e Implementar (BAI);
– Fornecer, Serviço e Suporte (DSS);
– Monitorizar, Avaliar e Aferir (MEA).
Cada domı́nio tem um número de processos, no entanto a maioria dos processos precisa de ati-
vidades de planeamento, implementação, execução e monitorização dentro do processo ou dentro do
contexto especı́fico. Os domı́nios foram igualmente definidos em linha com o que geralmente é mais
relevante para o IT a nı́vel empresarial. [8]
23
Figura 2.5: Áreas chave do COBIT 5 para governance e gestão. [8]
Figura 2.6: Processos do COBIT 5 para governance e gestão. [8]
24
Capı́tulo 3
Análise do Problema
3.1 O Service Provider - Associação DNS.PT

O service provider onde se realiza este trabalho é a associação DNS.PT, que está encarregue
da gestão e manutenção do ccTLD “.pt”. Tem como modelo de funcionamento um “modelo associativo
sem fins lucrativos e multi-stakeholder, ou como é usual[...] modelo de “responsabilidade colaborativa” 1 .
Neste modelo salientam-se quarto pontos chave presentes no plano de actividades 1 , a independência
do modelo, garantir a participação de todos os atores (modelo multi-stakeholder), o papel ativo no
estado português e a autossustentação.
O fato de ser uma associação sem fins lucrativos vem dentro do que se pratica por parte da maioria
dos gestores de ccTLD, “dos 38 ccTLD´s analisados, 27 [...] são entidades com natureza associativa e
sem fins lucrativos” 1 . Todos os ccTLDs, independentemente do seu modelo organizacional, dimensão
ou estrutura, têm como base da sua atividade o RFC1591.2 Este documento tem como requisitos
fundamentais:
• Dever de servir a comunidade da Internet;
• Existência de uma estrutura, com capacidades organizacionais e técnicas para a reutilização

das responsabilidades necessárias na prossecução de um trabalho equitativo, justo, honesto e
competente;
• Ser legı́tima a sua função, por ter sido devidamente delegada e amplamente reconhecida pela
comunidade da Internet local.
Operando com base nestes princı́pios, garante-se a existência de uma estrutura associativa base-
ada no seu fim não lucrativo, oferecendo os seus serviços em conformidade com as melhores práticas
internacionais.
Hoje em dia todo o mercado tecnológico é um mercado em crescendo onde a aposta em serviços
e virtualização tem vindo a ganhar cada vez mais peso. Estamos perante um mercado onde cada vez
1 https://www.dns.pt/fotos/editor2/links/plano_de_atividades_2013-2016.pdf
2 https://www.ietf.org/rfc/rfc1591.txt
25
se movimenta mais dinheiro, o que significa que cada vez mais há mais pessoas e empresas a usar e
tirar partido deste mercado, serviços como o DNS estão e irão ganhar cada vez mais preponderância
nas TI. No caso concreto do mercado onde opera a DNS.PT temos três papeis fundamentais:
• Registry :
O registry tem como responsabilidade gerir os domı́nios de topo de um paı́s garantindo que a sua
zona DNS, com os respetivos servidores de nomes, está sempre acessı́vel permitindo o acesso
a todos os domı́nios corretamente configurados da mesma zona. É do seu interesse vender o
maior número possı́vel de domı́nios, de preferência a registrar’s, uma vez que desse modo está
a estimular um mercado entre os mesmos para que estes ofereçam o melhor serviço possı́vel,
sendo que será o próprio mercado a fazer a filtragem e a eliminar quem não é competitivo em
termos da qualidade da oferta.3
• Registrar :
O registrar, por norma um Internet Service Provider (ISP), compra domı́nios ao registry, ou seja
em vez de comprar domı́nio a domı́nio, compra um número considerável de domı́nios, para os
incorporar nos seus serviços fornecidos. Devido ao conhecimento técnico que muitos registrar
retiram ao registry o ónus de dar suporte técnico ao consumidor final, libertando-o assim de ser
registry e registrar ao mesmo tempo.4
• Registrant:
O registrant é o consumidor comum, que tanto pode ser uma pessoal individual ou uma empresa,
que procura obter/reservar um domı́nio para fins profissionais ou pessoais. É a procura dos
registrant que acaba por fazer o mercado funcionar, pois ao procurar sempre a melhor solução
4
acaba por a prazo eliminar as más práticas dos registrar.
Por ser permitido em Portugal que qualquer cidadão compre o seu domı́nio ao ccTLD, a DNS.PT
tem dois papeis atuando como registrar,primeiramente ao vender diretamente ao consumidor final o seu
domı́nio, e como registry uma vez que fornece domı́nios às empresas que os revendem ao consumidor
final.
Não obstante, toda esta componente de negócio que tem de ser gerida com o intuito de dar lucro. A
DNS.PT têm um cariz não lucrativo assumindo um outro papel, com a seguinte missão: “A Associação
DNS.PT [...], procurará orientar as suas linhas de acção em benefı́cio de toda a comunidade Inter-
net portuguesa, dinamizando e incentivando a utilização generalizada. ”, é ainda objetivo da DNS.PT
1
promover o uso da Internet para a educação, divulgando igualmente a cultura portuguesa.
Em 2013, o DNS.PT fez prova ao Internet Corporation for Assigned Names and Numbers (ICANN),
a entidade internacional que gere a parte da Internet relativa ao negócio da DNS.PT, da capacidade
para gerir o domı́nio de topo, o ccTLD .pt. O relatório desse processo está disponı́vel online.5 Existindo
esta evidência, está assegurado que a zona de domı́nios “.pt”consegue manter-se, isto é continua a
3 https://www.icann.org/resources/pages/registries/registries-en
4 https://www.icann.org/resources/pages/registrars-0d-2012-02-25-en
5 http://www.iana.org/reports/2013/pt-report-20130808.html
26
ser possı́vel aceder a domı́nios “.pt”caso haja disrupção no serviço. No entanto, apesar de existirem já
estes mecanismos de resiliência inerentes ao protocolo DNS é necessário que se crie uma formalização
de processos e mecanismos de modo a responder ao que já existe no protocolo, cabe à DNS.PT,
exclusivamente, a gestão da zona de domı́nios “.pt”, assegurar a sua acessibilidade e atualização,
assim de como de todos os sistemas inerentes ao core do seu negócio. online
O impacto resultante desta zona, por algum motivo, deixar de estar acessı́vel (muito pouco provável)
ou atualizada, seria deveras negativo para o paı́s, devido à crescente preponderância da Internet, na
operação das empresas.
3.2 Contexto do Problema
Este projeto surge no processo de certificação da Associação DNS.PT na norma ISO 27001, neste
processo foi exigido que existisse um Plano de Continuidade de Negócio de modo a assegurar a
segurança da informação mesmo em continuidade de negócio.
Foi por decisão do DNS.PT que se optou por seguir a norma referência ISO 22301, não havendo
qualquer obrigatoriedade por seguir esta norma, a decisão recaı́u nomeadamente no facto de já existir
trabalho desenvolvido nas normas ISO 9000 e ISO 27001 o que permitia aproveitar esse trabalho para
a realização do Plano de Continuidade de Negócio.
A norma ISO 22301 conforme já analisado tem como ponto obrigatório a existência de um processo
de gestão de risco. Este processo de gestão de risco têm sempre de ter em conta a realidade do
negócio em si, por isso há que ter em conta o papel fundamental que desempenha a segurança da
informação num negócio cujo business core assenta nas TI.
Desta situação de conjugar estas duas realidades e criar um processo de gestão de risco que
consiga fazer esta mesma ligação cada vez mais importante, surgiu a proposta para este projeto cujo
foco será então neste processo de gestão de risco que vá de encontro aos requisitos da continuidade
de negócio e da segurança da informação.
3.3 Definição do Problema
Para a realização deste projeto é então proposto que se desenvolva um processo de gestão de risco
que dê suporte a um plano de continuidade de negócio, objetivo final da DNS.PT. Deste modo, o pro-
blema a resolver é o de como desenvolver e implementar um processo de gestão de risco que suporte
um plano de continuidade de negócio, de acordo com a norma ISO 22301, dentro da DNS.PT. Tendo em
conta que a DNS.PT conta já com uma certificação ISO 9001 e ISO 27001, a já implementação destas
normas é um facilitador na resolução do problema proposto uma vez que já existem mecanismos de
aferição de risco para ativos e processos, feitos no âmbito da certificação na segurança da informação.
Não sendo, por isso, necessário fazer tudo de raiz, podendo aproveitar-se o trabalho já desenvolvido
pela DNS.PT na implementação dessas duas normas.
Como se comprovou as normas ISO 27001, ISO 31000 e ISO 27005 estão relacionadas entre si.
27
A norma ISO 31000 define um processo de gestão do risco de modo genérico, a ISO 27001 define
um sistema de gestão para segurança da informação e a ISO 27005 define um processo de gestão de
risco de acordo com a ISO 27001 seguindo a estrutura do processo de gestão de risco genérico da ISO
31000.
Na perspetiva do que é proposto fazer, verificou-se que em primeiro lugar era intenção da DNS.PT
ter um plano de continuidade de negócio e que esse plano precisava de um processo de gestão de risco,
foi então proposto como problema a resolver a criação desse processo para o plano de continuidade
de negócio. A motivação deste plano veio da certificação ISO 27001 que a DNS.PT realizou e como
existe a norma ISO 27005 que define um processo de gestão de risco para a segurança da informação
pode-se concluir que o processo de gestão de risco a implementar como suporte à continuidade de
negócio poderá ser implementar a norma ISO 27005 conseguindo deste modo uma total integração
com a certificação obtida.
Um ponto fundamental de um processo de gestão de risco é a técnica de aferição de risco escolhida,
esta técnica têm de ter em conta quer a realidade da organização, neste caso o DNS.PT, quer o âmbito
do processo de gestão de risco. Deste modo a técnica a escolher tem de se poder enquadrar na norma
ISO 27005 e na norma ISO 22301, como ambas as normas têm como referência para a gestão de risco
a norma ISO 31000 é de especial relevância usar uma técnica que seja aplicável segundo esta norma.
Deste modo o problema que se procura dar resposta é o de criar um processo de gestão de risco
que enquadre a continuidade de negócio e a segurança da informação usando uma técnica de aferição
de risco adequada a esta realidade de ter que responder aos requisitos de 2 normas diferentes.
28
Capı́tulo 4
Proposta de Solução
A proposta de solução desenvolvida é a criação de um processo de gestão de risco que possa supor-
tar as necessidades das normas ISO 27001 de segurança de informação e ISO 22301 de continuidade
de negócio integrando os requisitos no mesmo processo, demostrando assim a complementariedade
das duas normas.
Para construir este processo baseei o meu trabalho na arquitetura de processos definida na norma
ISO 31000. Esta Arquitetura é composta pelos seguintes processos que se podem observar na figura
2.2.
Para aplicar esta arquitetura de processos no domı́nio do problema, criei 5 processos que interagem
entre si da forma descrita na figura 2.2, os 5 processos são:
• Estabelecer o Contexto;
• Aferição de Risco;
• Tratamento de Risco;
• Monitorização;
• Comunicação.
Nas subsecções seguintes irei fazer a descrição da minha proposta para cada um dos 5 processos
para este domı́nio especı́fico. Começarei por enunciar os objetivos de cada processo, seguido de
uma descrição do mesmo, no final de cada descrição encontra-se a minha proposta de diagrama. Os
diagramas propostos estão definidos na linguagem BPMN, em cada subsecção teremos o desenho
BPMN seguido de uma explicação dos objetivos do processo e de uma tabela descritiva das atividades
do processo correspondente.
Por razões de pragmatismos nos desenhos e para facilitar a interpretação dos mesmos, foram re-
movidas prepositadamente as setas de comunicação de mensagens trocadas entre atores do mesmo
processo. Nos 5 processos existem diversas interações com repositórios de informação cujo conteúdo
está descrito na tabela 4.1.
29
Nome Repositório Conteúdo
- Stakeholders;
- Requisitos legais;
- Arquitetura tecnológica do negócio;
BIA - Processos do negócio e suas dependências;
- Métodos de aferição de risco e de impacto e critério de risco;
- Impacto dos processos no negócio;
- Criticidade dos processos e tempos crı́ticos de recuperação;
- Riscos dos processos;
- Probabilidade de ocorrência de cada risco;
- Impacto dos riscos no negócio;
Registo de Riscos
- Nı́vel de cada risco;
- Controlos associados a cada risco;
- Planos de tratamento de risco efetuados;
Monitorização - Relatórios de monitorização dos diversos processos;
Tabela 4.1: Repositórios de Informação utilizados nos 5 processos.
4.1 Estabelecer Contexto
O processo de estabelecer contexto tem como objetivos:
• Definir os objetivos a atingir na Segurança da Informação e Continuidade e Negócio;
• Definir polı́tica de Segurança da Informação e de Continuidade de Negócio;
• Estabelecer o contexto interno e externo da organização;
• Definir métodos de aferição de risco e de impacto dos processos do negócio.
É neste processo onde se faz a definição do que se pretende atingir com a gestão de risco, é
devéras importante que se estabeleça um contexto correto e se definam métodos e critérios tão pre-
cisos quanto possı́vel, tendo claro sempre presente as necessidades reais do negócio. Para facilitar a
correta execução do processo se possı́vel é recomendável executar ações de sensibilização do tema
aos diversos intervenientes, quer para que fiquem conscientes da importância da sua participação quer
para se começaram a ambientar às terminologias usasdas neste domı́nio.
Neste processo é onde se define o negócio, identifica processos da organização, as suas de-
pendências e relações, nas dependências dos processos é necessário obter a arquitetura tecnologica
existente uma vez que esta é sempre parte vital nas organizações de hoje. É ainda preciso perceber
como é que os processos interagem com o negócio e vice-versa, isto é, se eu ficar sem o processo x
será que o negócio consegue prosseguir normalmente? Se não consegue qual o impacto e porquê?
O processo y é altamente crı́tico porque suporta a execução dos n processos core do negócio, há al-
ternativas? Este é o tipo de perguntas que se pretende responder com o contexto bem estabelecido e
como se comprova é mesmo importante ser exato nas informações uma vez que as implicações podem
colocar o negócio em perigo de não continuar, bastanto classificar um processo que é altamente crı́tico
com criticidade moderada devido à falta de informação precisa e atual.
30
Este processo deve ser executado sempre que a gestão realizar mudanças na organização ou sem-
pre que o contexto interno ou externo mude, para além das situações que possam ser detetadas no
processo de monitorização. O quadro resumo das atividades deste processo, que de seguida se des-
crevem, pode ser consultado na tabela 4.2 onde é também indicado o input e output de cada atividade.
No contexto externo é necessário perceber quais são os fatores que podem afetar a organização de
modo a posteriormente poder fazer uma correcta aferição do risco. Estes fatores podem ser ambientais,
polı́ticos, regulatórios, financeiros/económicos, relações com stakeholders, key drivers e trends que
possam influenciar os objetivos da organização. No que respeita ao contexto interno será necessário
avaliar qual a posição da gestão do risco nos objetivos gerais da organização, normas e guidelines
adotados pela organização, cultura interna, sistemas de informação existentes, stakeholders, entre
outros. Estes requisitos descritos e outros que se podem considerar na definição do contexto interno e
externo podem ser consultados no ponto 5.3 da norma ISO 31000. [4]
Será ainda necessário definir uma polı́tica de segurança da informação e de continuidade de negócio
de acordo com os objetivos a atinguir nestas duas áreas, nestas polı́ticas deverá estar expresso o
risk appetite da organização para ambos os casos. Na definição das dependências cabe a cada res-
ponsável de processo identificar os ativos que interveêm no mesmo, assim como as relações que o seu
processo tem com outros processos, a arquitetura tecnológica é também definida neste ponto sendo
uma responsabilidade do responsável sobre a área técnica da organização. [4]
Uma vez obtido o conhecimento do funcionamento e das dependências da organização cabe ao
responsável pela SI e CN a definição dos tempos crı́ticos (RTO, RPO, MTD) de cada processo e avaliar
segundo o método BIA já definido qual é o impacto que cada processo tem no negócio e com isso
definir a criticidade de cada processo para a organização, todo este trabalho terá de ser aprovado pelo
responsável do negócio. A modelação deste processo pode ser vista na figura 4.1.
Figura 4.1: Processo de Estabelecer o Contexto.
31
Atividade Objetivo Input Output
- Stakeholders;
- Requisitos Legais/Regulatórios;
- Definição de todos os fatores - Fatores polı́ticos/ ambientais/
internos/externos que podem influenciar financeiros/ económicos;
Definir contexto
a organização; N/A - Key drivers e trends;
interno/externo
- Definição de objetivos para a gestão - Polı́ticas e normas internas
de risco; relevantes para o domı́nio;
- Polı́tica e objetivos de segurança da
informação e continuidade de negócio;
- Stakeholders;
- Requisitos Legais/Regulatórios;
- Fatores polı́ticos/ ambientais/
- Analisar para aprovar ou rejeitar financeiros/ económicos;
Analisar
os documentos que definem o contexto - Key drivers e trends; -Aprovação ou rejeição dos documentos;
documentos
interno/externo da organização - Polı́ticas e normas internas
relevantes para o domı́nio;
- Polı́tica e objetivos de segurança da
informação e continuidade de negócio;
- Criar uma lista com todos os processos
Identificar processos
da organização que são relevantes para o N/A - Processos do negócio
do negócio
negócio
- Arquitetura de processos da
- Identificação de todos os ativos;
organização;
- Identificar relação entre ativos e
- Dependências dos processos da
Identificar dependências processos;
- Processos do negócio organização;
do negócio - Identificar relação entre processos;
- Arquitetura tecnológica da
- Identificar arquitectura tecnológica
organização;
do negócio;
- Relações entre processos;
- Arquitetura de processos da
organização;
- Dependências dos processos
- Consolidar informação recebida
Agrupar dependências da organização; N/A
de cada responsável no repositório BIA;
- Arquitetura tecnológica da
organização;
- Relações entre processos;
- Definição de um método BIA para - Arquitetura de processos
cálculo do nı́vel de risco e do impacto da organização;
- Critério de risco;
dos processos no negócio; - Dependências dos processos
Definir método BIA e - Método BIA;
- Definição dos tempos crı́ticos de da organização;
critério de risco - Tempos crı́ticos de recuperação
recuperação para cada processo; - Arquitetura tecnológica
dos processos;
- Definição de um critério de risco para da organização;
a organização; - Relações entre processos;
- Critério de risco;
Analisar BIA e critério - Analisar a proposta de BIA e de - Método BIA;
- Aprovação ou rejeição
de risco criterio de risco para aprovar ou rejeitar; - Tempos crı́ticos de recuperação
dos processos;
Tabela 4.2: Atividades executadas no processo de Estabelecer o Contexto.
32
4.2 Aferir o Risco
O processo de Aferição de Risco tem como objetivos:
• Identificar os riscos existentes para cada processo de negócio para ambos os domı́nios;
• Identificar os controlos associados a cada risco;
• Associar os riscos identificados aos processos correspondentes;
• Atribuir um nı́vel de risco coerente a cada risco dos processos de negócio;
O quadro resumo das atividades deste processo, que de seguida se descrevem, pode ser consultado
na tabela 4.3 onde é também indicado o input e output de cada atividade.
No processo de aferição de risco é se vai aplicar tudo o que se definiu no contexto, aqui começa-
se por identificar todos os riscos que estejam dentro do domı́nio e do âmbito pretendidos, é muito
importante não menosprezar qualquer tipo de risco uma vez que só é possı́vel mitigar o que se identifica.
Ao identificar os riscos surge a necessidade da existência de um repositório onde esteja armazenada
toda a informação relacionada com os riscos que identificamos no nosso negócio, é desta necessidade
que se cria ou revê caso já exista um registo de risco, sendo que na revisão se deve remover todos os
riscos obsoletos. O registo de risco é um elemento crı́tico para o processo de gestão de risco pois é
nele que vamos armezar toda a informação encontrada e todo o trabalho produzido relativo aos riscos
que estão dentro do domı́nio do problema.
É também no registo de risco que se vai colocar os controlos que já existem, relacionando-os com
os riscos sob os quais operam.
Durante a atividade de análise dos riscos deve-se perceber qual ou quais eventos podem estar
na origem do risco, qual é o impacto que esse risco tem no processo ao qual está relacionado e por
consequência qual o impacto que isso vai trazer ao negócio. Para além do impacto é importante também
perceber qual é a frequência e/ou a probabilidade de ocorrência que esse risco tem durante um perı́odo
de tempo (aqui fica ao critério da organização qual o espaço temporal mais plausı́vel a considerar se
um ano, mês, semana, dia).
Após avaliar cada risco é preciso então atribuir um nı́vel de risco, para tal existem diversas técnicas
que podem ser consultadas na norma ISO 31010 sendo que a sua aplicação deve ter em conta a rea-
lidade da organização e os objetivos a atingir, tendo em consideração que o objetivo deste processo é
juntar a segurança da informação com a continuidade de negócio, a técnica proposta é a realização de
um método BIA, este método pode basear o nı́vel de risco em diversos indicadores consoante as neces-
sidades de cada situação, ver anexo A com exemplo ilustrativo de um BIA, neste caso concreto, como
temos de lidar com a continuidade de negócio e segurança da informação os indicadores aconselhados
são de impacto do risco no processo, probabilidade de ocorrência do risco e impacto do processo no
negócio. Estes indicadores podem caso se pretenda ser poderados e/ou normalizados, não existindo
nenhuma regra definida fica ao critério de cada responsável por esta área ver qual é a situação que me-
lhor se adequa quer ao negócio quer aos objetivos da gestão para a gestão de risco. Este é o método
33
escolhido por ser algo mandatório na continuidade de negócio e que se adequa às necessidades de
segurança da informação. [1] [6]
A modelação deste processo pode ser vista na figura 4.2.
Figura 4.2: Processo de Aferição de Risco

- Identificar riscos de cada processo;
- Identificar controlos existentes;
Criar/Rever registo
- Associar controlos a riscos N/A - Registo de riscos
de riscos
identificados;
- Remover riscos obsoletos;
- Riscos dos processos;
Agrupar alterações no - Receber dos responsáveis dos
- Controlos dos processos; - Registo de Riscos
registo de riscos processos alterações ao registo de riscos
- Riscos obsoletos;
Analisar registo de - Analisar se registo de riscos responde - Aprovação/Rejeição do
- Registo de riscos
riscos às necessidades da organização registo de riscos proposto
- Identificação da probalidade/frequência - Probabilidade/Frequência de
Analisar riscos de ocorrência de cada risco; - Registo de riscos ocorrência de cada risco;
- Impactos do risco no processo/negócio; - Impacto do risco no negócio;
- Probabilidade/Frequência de
- Calcular o nı́vel de risco com base nos
Aferir nı́veis de risco ocorrência de cada risco; - Nı́veis de risco;
indicadores escolhidos;
- Impacto do risco no negócio;
- Analisar os nı́veis de risco para
- Aprovação/Rejeição dos
Analisar nı́veis de risco perceber se correspondem à realidade - Nı́veis de risco
nı́veis de risco
do negócio;
Tabela 4.3: Atividades executadas no processo de Aferição de Risco.
34
4.3 Tratamento de Risco
O processo de Tratamento de Risco tem como objetivos:
• Definição de controlos para os riscos identificados;
• Atualização dos controlos existentes;
• Mitigação do nı́vel de risco nos processos mais crı́ticos para um nı́vel aceitável;
O quadro resumo das atividades deste processo, que de seguida se descrevem, pode ser consultado
na tabela 4.4 onde é também indicado o input e output de cada atividade.
No processo de Tratamento de risco a primeira atividade consiste em ir ler os resultados obtidos no
processo de aferição de risco e preparar um plano de tratamento de risco. Este plano consiste num
conjunto de controlos, novos ou atualizações a controlos existentes, que são delineados para reduzir o
nı́vel de risco do processo ao qual são relacionados. Não existe nenhuma regra ou norma que indique
quantos controlos deve ter cada risco ou cada processo, é perfeitamente possı́vel reduzir o nı́vel de um
risco com um só controlo como ter de recorrer a n controlos para conseguir essa mitigação.
Uma vez elaborado o plano de tratamento de risco este deve ser revisto em conjunto com os res-
ponsáveis de cada processo de modo a se poder acrescentar novos controlos à proposta ou a remo-
ver controlos que à partida já representem uma redução do nı́vel de risco, todas estas propostas de
remoção e acrescento devem ser documentadas no registo de riscos (indicar que o controlo é obsoleto
ou acrescentar outros). Após a obtenção de uma versão final para submeter à aprovação do res-
ponsável do negócio é preciso calcular quanto vai custar implementar cada controlo, esta atividade é
especialmente importante porque vai acabar por ter um impacto direto na decisão final do responsável
de negócio sobre quais controlos implementar, sendo muito importante obter uma estimativa o mais
aproximada possı́vel do custo de modo a sobrevalorizar nem subvalorizar e assim o responsável do
negócio poder decidir o máximo de conforto possı́vel. Uma vez estimados os custos o responsável
pela segurança da informação e continuidade de negócio deve priorizar os controlos de modo a que a
gestão consiga perceber quais são os mais urgentes a implementar.
Assim que recebe o plano de tratamento de riscos para aprovar o responsável do negócio deve
decidir consoante os objetivos a atingir pela organização quais os controlos que são obrigatórios de
implementar, os que a organização suporta implementar e quais os que podem não ser implementados
pelo custo ser superior ao ganho efetivo (se o nı́vel de risco estiver já abaixo do aceitável ou muito
próximo do limite, poderá não se justificar o custo para a realidade da organização). Ao decidir irá
escolher os controlos a aplicar e notificar o responsável pela SI e CN dos controlos selecionados para
aplicação explicando as exclusões. A responsabilidade de aplicação dos controlos é depois dos donos
dos processos. Os controlos a aplicar devem ter como objetivo uma redução do nı́vel de risco, quer
seja pela redução de probabilidade de ocorrência, remoção da fonte de risco, redução dos impactos ou
partilha de risco com terceiros. [4]
Analisando a norma ISO 27005, ver figura 2.3, notamos que nesta fase do processo é introduzida
uma alteração em relação ao definido na norma ISO 31000, ver figura 2.2, onde após se definir os con-
35
trolos se deve analisar se estes surtiram o efeito desejado ou não de modo a de imediato poder redefinir
os mesmos ou acrescentar outros, esta alteração embora não expressa diretamente no desenho deste
sub-processo é também considerada na arquitetura de processos utilizada para o processso de gestão
de risco neste caso. Por ser uma aplicação desta arquitetura pode-se utilizar essa alteração para este
caso e permitir que assim o responsável do negócio possa rejeitar o plano de tratamento de risco e que
o plano de tratamento de risco seja imediatamente revisto para nova submissão.E iniciar o processo de
monitorização para perceber se os controlos surtiram ou não o efeito desejado. [4] [7]
A modelação deste processo pode ser vista na figura 4.3.
Figura 4.3: Processo de Tratamento de Risco

Elaborar plano de tratamento - Definir controlos para os riscos
- Registo de riscos - Plano de tratamento de riscos
de riscos identificados;
Receber e analisar modificações - Receber e analisar as alterações
- Plano de tratamento de riscos - Plano de tratamento de riscos
ao plano propostas ao plano de tratamento de riscos
- Calcular custo de implementação dos
Calcular custos dos controlos - Plano de tratamento de riscos - Custo dos controlos propostos
controlos propostos
- Controlos ordenados por
Priorizar controlos - Priorizar os controlos propostos - Plano de tratamento de riscos
criticidade
Analisar plano de tratamento - Analisar o plano de tratamento de - Aprovação/Rejeição do plano
- Plano de tratamento de riscos
de risco riscos para aprovação de tratamento de riscos
- Perceber qual o tipo de implementação - Decisão sobre o tipo de
Decidir tipo de implementação - Plano de tratamento de riscos
possı́vel implementação
- Implementar todo o plano de
Implementar plano - Plano de tratamento de riscos - Implementação de todo o plano
tratamento de riscos
Escolha dos controlos a aplicar - Selecionar alguns controlos para aplicar - Plano de tratamento de riscos - Aplicação dos controlos escolhidos
Implementar plano de tratamento - Comunicar para implementar - Ordem de implementação
- Plano de tratamento de riscos
de riscos todos os controlos propostos dos controlos
- Comunicar para implementar - Ordem de implementação dos
Implementar controlos selecionados - Lista de controlos selecionados
os controlos selecionados controlos selecionados
Tabela 4.4: Atividades executadas no processo de Tratamento de Risco.
36
4.4 Monitorização
Tendo por base o ponto 9.3 da norma ISO 22301 e ISO 27001 percebe-se que é necessário mo-
nitorizar e rever de forma periódica quer o sistema de segurança da informação, quer o sistema de
continuidade de negócio, o que implica monitorizar e rever a base de ambos os sistemas que é o pro-
cesso de gestão de risco comum, desse modo e olhando para o ponto 5.6 da norma ISO 31000 e
para o ponto 12.2 da norma ISO 27005 percebe-se que é aconselhável existir uma monitorização e
revisão periódicas ou ad hoc do processo de gestão de risco, o tempo que dista entre duas revisões ou
atividades de monitorização está dependente da gestão que deve sempre ter em consideração tanto
o contexto interno, como externo do negócio da organização. A Arquitetura de processos por ser a
proposta da norma ISO 31000 respeita esta necessidade ao permitir a execução a qualquer altura
da monitorização e revisão, conseguindo assim a melhoria contı́nua do sistema, pois é possı́vel estar
sempre a monitorizar de modo a depois introduzir alterações para melhorar o processo.
Conforme referido o processo de monitorização vai de encontro com o ponto 5.6 da norma ISO
31000 Monitoring and review, neste ponto pretende-se dar resposta à necessidade de rever todo o
trabalho desenvolvido no estabelecimento do contexto, na aferição do risco e no tratamento do risco.
Verificar se houve alterações no contexto da organização, ou novos riscos surgiram e se os controlos
foram ou não eficazes. [4]
Para alcançar estes objetivos dividi o processo de monitorização e revisão em 3 sub-processos,
monitorização do processo de estabelecer o contexto, monitorização do processo da aferição de risco
e monitorização do processo de tratamento de risco, cada um destes sub-processos visa monitorizar
e rever o trabalho desenvolvido em cada uma das 3 etapas centrais do processo de gestão de risco:
Estabelecer Contexto, Aferição de Risco e Tratamento de Risco, ver figura 2.2.
Seguindo o estabelecido na arquitetura, os processos podem ser executados a qualquer momento
o que significa que logo após a primeira definição de contexto é possı́vel caso a organização assim o
entenda monitorizar o mesmo, sendo a mesma lógica aplicada aos restantes processos. Uma vez que
cada negócio tem caracterı́sticas especı́ficas que influenciam todo o processo de gestão de risco, fica
ao critério da organização a frequência e o momento de efetuar a monitorização e revisão, ao estar a
pré-estabelecer uma frequência ou um momento do ano estaria certamente a ignorar as especificida-
des de muitos negócios que poderiam adoptar este processo. Além disto se olharmos para a norma
ISO 31000 também não encontramos nenhuma definição concreta de quando e com que frequência
realizar a monitorização, de fato o que vem escrito na norma é que “Both monitoring and review should
be a planned part of the risk management process and involve regular checking or surveillance. It
can be periodic or ad hoc”, ou seja, desde que esteja planeado no âmbito da gestão de risco fazer
uma revisão/monitorização, sendo ela periódica ou ad hoc não é problema de maior uma vez que é
dependente do negócio. [4]
37
4.4.1 Monitorização de Estabelecer o Contexto
Na monitorização do contexto o principal objetivo passa por perceber se o contexto da organização

foi sujeito a alterações, ou seja, é preciso perceber se houve uma mudança de objetivos e se as polı́ticas
definidas ainda fazem sentido na organização, se os métodos de aferição de risco e impacto ainda
servem os objetivos da organização, se houve mudanças no contexto externo que possam influenciar o
nı́vel de risco e o impacto dos processos como mudanças sócio-económicas no mercado, mudanças no
regulador (se aplicável), entrada/saı́da de stakeholders, a nı́vel do contexto interno poderão ser fatores
como uma mudança tecnológica nos sistemas da organização ou uma alteração da arquitetura ou até
uma mudança nos processos de negócio de como eles interagem entre si.
Neste processo é muito importante saber fazer uma avaliação cuidada dos documentos produzidos
e da realidade atual para perceber se houve alterações e se estas alterações podem significar novos
riscos ou modificação do nı́vel de risco ou o desaparecimento de riscos existentes, uma vez que estas
implicações representam um impacto significativo no negócio.
A modelação deste processo pode ser vista na figura 4.4 e o quadro resumo das atividades deste
processo, descritas nesta seção, pode ser consultado na tabela 4.5 onde é também indicado o input e
output de cada atividade.
Figura 4.4: Processo de Monitorização do Contexto do Negócio

- Rever aplicabilidade dos documentos
produzidos na atividade ”Definir contexto
Rever contexto interno/externo - Repositório BIA - N/A
interno/externo”do processo de
estabelecer contexto
- Rever toda a arquitetura tecnológica
Rever Arquitetura tecnológica - N/A - N/A
para encontrar alterações
- Rever todas as dependências/
Rever dependências dos processos - N/A - N/A
relações dos processos de negócio
- Alterações contexto interno/externo;
- Escrever um relatório com a indicação
- Alterações Arq. Tecnológica; - Relatório de monitorização do
Produzir relatório do trabalho realizado e se é preciso
- Alterações nas dependências dos contexto
proceder a alguma alteração
processos;
Tabela 4.5: Atividades executadas no processo de Monitorização do Estabelecer Contexto.
38
4.4.2 Monitorização da Aferição de Risco
Para monitorizar a aferição de risco tem de se ter em conta o contexto, uma vez que esta depende
dele, é normal a alteração de uma ou mais condições no contexto provocar uma mudança na análise
dos riscos, no entanto pode perfeitamente acontecer que seja atribuı́do a um risco uma frequência,
probabilidade ou impacto que não correspondem à realidade, quer seja em defeito ou por excesso, o
facto de estas situações poderem ocorrer torna fundamental a existência de um processo que monito-
riza e revê as avalições dos riscos e os nı́veis de risco atribuı́dos. Caso seja detetada uma qualquer
modificação quer seja uma mudança ao contexto, quer apenas no nı́vel de risco terá de se forçosamente
rever o registo de riscos para perceber se há alguns novos a considerar, ou outros que já não fazem
parte do contexto ou se os nı́veis de risco ainda fazem sentido no novo contexto ou nova avaliação.
É norma nas empresas que implementam sistemas como o da norma ISO 27001 fazer-se uma
revisão periódica dos riscos e da sua avaliação, para esse efeito deixaria de ser necessário re-executar
o processo de aferição de risco e executar-se-ia este processo, exceto se houver a necessidade de
voltar a estabeler o contexto aı́ teria de se voltar a aferir o risco conforme já foi abordado. A modelação
deste processo pode ser vista na figura 4.5 e o quadro resumo das atividades do mesmo, descritas
nesta seção, pode ser consultado na tabela 4.6 onde é também indicado o input e output de cada
atividade.
Figura 4.5: Processo de Monitorização da Aferição de Risco

- Rever existência dos riscos e controlos
Rever registo de riscos - Registo de riscos - N/A
existentes
- Rever riscos identificados e analisar
Analisar riscos a manutenção da probabilidade/frequência - N/A - N/A
de ocorrência e do impacto
- Rever nı́veis de risco para identificar
Conferir nı́veis de risco - N/A - N/A
a necessidade de possı́veis alterações
- Alterações na existência de riscos e
controlos;
- Escrever um relatório com a indicação - Alterações da frequência/prob. de
- Relatório de monitorização
Produzir relatório do trabalho realizado e se é preciso um dado risco;
da aferição de risco
proceder a alguma alteração - Alterações no impacto de um dado
risco;
- Alterações no nı́vel de um dado risco
Tabela 4.6: Atividades executadas no processo de Monitorização da Aferição de Risco.
39
4.4.3 Monitorização do Plano de Tratamento de Riscos
O grande objetivo ao monitorizar um plano de tratamento de riscos é perceber se em primeiro lugar

os controlos foram efetivamente implementados e de acordo com o especı́ficado no plano de tratamento
de riscos elaborados previamente.
Ao avaliar os controlos implementados nos diversos processos do negócio e perceber se estes
conseguiram reduzir o nı́vel de risco para o nı́vel pretendido ou se foram ineficazes, está a garantir-se
que o sistema está sempre em melhoria contı́nua rumo à maior redução possı́vel dos nı́veis de risco, isto
porque sempre que se detetam controlos ineficazes deve-se anotar isso no relatório de monitorização,
para que a deficiência seja corrigida na elaboração do próximo plano, ou caso seja algo muito crı́tico,
que se volte a elaborar um plano de tratamento de riscos substituto.
Pode acontecer que apesar de bem implementados os controlos sejam ineficazes e os nı́veis de
risco ainda demasiado altos, nesses casos o recomendável é rever o contexto e a aferição de risco
para perceber se é uma questão de adicionar mais controlos ao plano de tratamento de riscos ou se
é necessário um recomeço a partir da definição do contexto ou da aferição de risco, este processo
conforme já abordado pode ser realizado logo após a implementação dos controlos e, por isso, respeita
a execução da arquitetura de processos da norma ISO 27005.
Figura 4.6: Processo de Monitorização do Tratamento de Riscos

- Conferir se todos os controlos selecionados
Conferir aplicação dos controlos - Registo de riscos - N/A
foram corretamente aplicados
- Avaliar se os controlos aplicados surtiram
Avaliar a eficácia dos controlos - N/A - N/A
o efeito desejado
Escrever um relatório com a indicação
- Relatório da monitorização
Produzir relatório do trabalho realizado e se é preciso - N/A
do plano de tratamento dos riscos
proceder a alguma alteração
Tabela 4.7: Atividades executadas no processo de Monitorização do Plano de Tratamento de Riscos.
40
4.5 Comunicação
O processo de comunicação e consulta tem como objetivo definir como realizar a comunicação com
os diversos stakeholders relevantes para o processo de gestão de risco, para se poder comunicar o tra-
balho realizado e receber um possı́vel input dado pelos stakeholders que a gestão e/ou o responsável
da segurança da informação considere pertinente para melhorar o processo de gestão de risco. Para
além da importante componente de ir ao encontro dos objetivos dos stakeholders é necessário, por
vezes, obter da parte dos mesmos um qualquer input sobre o trabalho desenvolvido não numa ótica
do dar conhecimento mas sim na ótica de uma consultoria sobre esse tema, nesta situação o sta-
keholder funciona como consultor e ajuda a organização a realizar o trabalho de modo a responder às
suas preocupações. Nem sempre as recomendações dos stakeholders são possı́veis de implementar,
pois o seu rácio custo-benefı́cio pode ser baixo. Para perceber se uma recomendação é possı́vel de
aplicar deve haver a concordância entre o responsável do negócio e o responsável pela segurança da
informação e continuidade de negócio, sendo que o primeiro é o decisor final e o segundo funciona no
papel de um consultor que dá o seu parecer. [1] [4] [7] [5]
Figura 4.7: Processo de Comunicação e Consulta

- Comunicar o trabalho feito no âmbito 4 - Repositório BIA;
Comunicar aos stakeholders
processos restantes que compõem a - Registo de riscos; - N/A
o trabalho desenvolvido
arquitetura - Monitorização;
- Receber o feedback dos stakeholders;
- Perceber se há ou não recomendações
Recolher feedback - Feedback/Não feedback - N/A
para proceder a alguma alteração no
trabalho apresentado;
- Ponderar quais são as alterações que se
Ponderar que recomendações - Recomendações dos
justificam realizar e quais são as que são - Recomendações a aplicar
aplicar stakeholders
possı́veis de executar
Aplicar recomendações
- Aplicar as recomendações selecionadas - Recomendações a aplicar - N/A
escolhidas
Tabela 4.8: Atividades executadas no processo de Comunicação e Consulta.
41
4.6 Processo de Gestão de Risco no COBIT 5
Com estes desenhos e as propriedades referidas a proposta de solução corresponde à totalidade

dos processos de gestão de risco referidos pelas normas ISO 31000 e ISO 27005 que podem ser con-
sultados nas figuras 2.2 e 2.3, respetivamente, mantendo as suas necessidades e conseguindo juntar a
segurança da informação com a continuidade de negócio. No entanto será igualmente interessante per-
ceber como se pode aplicar este processo de gestão de risco numa framework muito usual no mundo
empresarial de IT nos dias de hoje, o COBIT 5 dando assim sentido à solução proposta.
Conforme analisado, o COBIT 5 permite que a informação e tecnologia associada sejam geridas de
forma holı́stica para a organização como um todo, ao ter principios facilitadores e genéricos que podem
ser aplicados a toda e qualquer organização. De um modo simples, o COBIT 5 ajuda a otimizar o valor
criado a partir do IT ao manter uma harmonia entre os beneficios e os nı́veis de risco dos recursos. [10]
O COBIT 5 é especialmente interessante de abordar por o facto de a cobertura já referida anteri-
ormente às organizações e por se poder facilmente relacionar com as normas ISO abordadas neste
trabalho conforme se pode ver pela imagem 4.8.
Na figura 4.9 vemos quais os processos do COBIT 5 que são precisos para suportar a gestão de
risco:
• A rosa escuro temos os processos de suporte chave;
• A rosa claro temos os restantes processos de suporte;
• A azul claro temos os core risk process,
Como se percebe há uma forte ligação entre a gestão de risco e o COBIT 5, de tal modo que todos
os processos servem de suporte à gestão do risco. No entanto, é importante perceber então como é
que se pode usar o COBIT 5 para responder às normas ISO 22301 e 27001. Analisando a figura 4.8
vê-se que o COBIT 5 responde às necessidades das normas ISO 27001 e 27005. No entanto falta
esclarecer se é possı́vel ligar os requisitos da norma ISO 22301 aos processos do COBIT 5, para que
se possa aplicar este processo de gestão de risco proposto a uma organização que use a framework
COBIT.
Nos domı́nios DSS do COBIT 5 temos um conjuto de processos que é possı́vel relacionar com as
necessidades da continuidade de negócio, nomeadamente os processos DSS02, DSS03 e DSS04, Ma-
nage Service Requests and Incidents, Manage Problems e Manage Continuity respetivamente que, no
fundo, respondem aos objetivos indicados na norma ISO 22301, preparar para agir e gerir a ocorrência
de incidentes e problemas que possam provocar a disrupção do negócio assegurando sempre a con-
tinuidade do mesmo. Conseguindo fazer esta ligação ao nı́vel dos objetivos, pode-se também olhar à
gestão de risco, essencial à continuidade de negócio, como já se analisou a norma ISO 22301 é res-
pondida nesse aspecto pela norma ISO 31000 o que significa que o COBIT 5 pode ser usado para gerir
o risco da continuidade de negócio como se pode ver pela figura 4.8. À semelhança da segurança da
informação também a continuidade de negócio tem necessidade de monitorização e revisão periódicas,
42
no entanto esta necessidade é também contemplada no COBIT5 pelos processos do domı́nio MEA, o
mesmo sucedendo às normas ISO 27001, ISO 27005 e ISO 31000. [8] [1] [4]
Como se acabou de demonstrar é de todo possı́vel aplicar este processo de gestão de risco a uma
organização que use a framework de referência COBIT conseguindo assim interligar a segurança da
informação com a continuidade de negócio.
Figura 4.8: Ligação do COBIT 5 a outras normas e frameworks. [10]
Figura 4.9: Processos COBIT 5 para gerir o risco. [10]
43
Capı́tulo 5
Conclusões e Trabalho Futuro
5.1 Objetivos e Desafios Iniciais

No âmbito da realização do trabalho realizado para o DNS.PT tive a oportunidade de ler e analisar a
norma referência ISO 22301, após análise da norma foi-me bastante clara a necessidade da existência
de um processo de gestão de risco, uma vez que é sobre o mesmo que se desenvolve todo o trabalho
de continuidade de negócio. No entanto, antes de poder partir para a concretização de uma proposta
de um plano de continuidade de negócio foi necessário estruturar uma abordagem de modo a conseguir
produzir um trabalho de qualidade.
O primeiro passo foi identificar quais eram os meus objetivos e que desafios é que se colocavam já
a partida para ultrapassar. Os objetivos eram:
• Produzir um Plano de Continuidade de Negócio;
• Produzir um Processo de Gestão de Risco;
• Integrar o trabalho desenvolvido na cultura e processos do DNS.PT;
• Obter a aprovação por parte da gestão relativamente ao trabalho desenvolvido.
De modo a conseguir atingir estes objetivos enunciados foi preciso perceber quais eram os desafios
que se colocavam, os desafios iniciais eram:
• Perceber o negócio;
• Perceber a cultura do DNS.PT;
• Adaptar o Plano de Continuidade de Negócio e a sua Gestão do Risco à cultura do DNS.PT;
• Integrar a continuidade de negócio de um modo formal na cultura do DNS.PT;
• Como utilizar o trabalho desenvolvido nas normas ISO em que o DNS.PT já obteve certificação;
44
Para conseguir perceber melhor o contexto do negócio tive de pesquisar relativamente ao tema
de continuidade de negócio e segurança da informação, ao mesmo tempo aproveitava o tempo em
escritório para realizar pequenas entrevistas aos colaboradores do DNS.PT de modo a poder obter a
informação de quem está por dentro do negócio e assim perceber melhor a cultura da organização.
Os inputs acabaram por me aproximar mais da realidade efetiva do que é o negócio e permitiram-me
conceber a minha ideia de como é o negócio e como abordar o mesmo na perspetiva da continuidade
de negócio e segurança da informação.
Uma vez que, aquando da minha chegada ao DNS.PT já existia implementado um processo de
gestão de risco para a segurança da informação de acordo com os requisitos da norma ISO 27001,
era claro que teria de aproveitar todo o trabalho realizado pelo DNS.PT nesse mesmo âmbito para
a concretização do meu trabalho. Ao aproveitar o trabalho realizado e adaptando os documentos já
produzidos para que estes passem a conter as necessidades inerentes à continuidade de negócio
estaria a evitar a duplicação de documentos e a manter-me dentro daquilo que é a cultura do DNS.PT
no que respeita aos seus processos.
Foi relativamente fácil a introdução do tema da continuidade de negócio na cultura da organização,
principalmente a nı́vel da gestão de risco, uma vez que todos os colaboradores tinham sido previamente
sensibilizados, sendo-lhes explicada a importância deste tema para o DNS.PT, mesmo já existindo
processos inerentes à tecnologia utilizada que garantissem a continuidade de negócio não existia à
data uma formalização de um plano de como assegurar essa continuidade.
5.2 Processo de Gestão de Risco
Conforme referido o DNS.PT já estava dotado de um processo de gestão risco, no entanto esse
mesmo processo encontrava-se exclusivamente focado nas necessidades da segurança da informação
e seria necessário introduzir neste processo as necessidades da continuidade de negócio.
O primeiro passo foi rever o contexto, era necessário identificar se seria preciso proceder a alterações
do mesmo, uma vez que se ia introduzir uma variável nova. Foi necessário criar uma polı́tica de con-
tinuidade de negócio, identificar stakeholders, que requisitos legais teriam de ser respondidos, obter a
arquitetura do sistema e criar um método BIA para ser aplicado aos processos de negócio.
Uma vez que estava a ocorrer ao mesmo tempo uma revisão dos processos de negócio devido à
renovação da certificação da norma ISO 9001, esse trabalho não foi realizado neste âmbito, assim
como a identificação dos requisitos legais ficou atribuı́da à equipa da área júridica.
Para a criação da polı́tica de continuidade de negócio o que se fez foi aproveitar a polı́tica de
segurança de informação vigente e introduzir na mesma as preocupações relativas à continuidade
de negócio criando assim um único documento que servia as duas normas ISO. A polı́tica definida
pode ser consultada no site do DNS.PT, sendo que uma das partes mais relevantes para este trabalho
fica aqui transcrita: ”Garantir a continuidade de negócio e a segurança da informação, implementando
medidas que assegurem a resiliência do DNS.PT à adversidade. Permitindo, assim, a recuperação
das atividades crı́ticas da organização num intervalo de tempo aceitável, minimizando desta forma as
45
consequências de incidentes para os seus stakeholders. O DNS.PT compromete-se assim a manter o
Plano de Continuidade de Negócio documentado, atualizado e testado com regularidade.”.1
Criada a polı́tica era preciso proceder à definição do BIA. Para definir o BIA recorri à norma ISO
31010 [6], aos modelos exemplo como o do anexo A e às recomendações do The Definitive Handbook
of Business Continuity Management [9], tendo sempre presente a realidade existente no DNS.PT.
Antes de poder definir como se calculavam os impactos é preciso saber quais são os objetivos que
pretendemos alcançar com o BIA, isto porque deve-se elaborar sempre o BIA consoante os objetivos
que pretendemos cumprir. Para as necessidades do DNS.PT os objetivos do BIA eram:
• Determinar os processos de negócio e a criticidade da sua recuperação.
• Identificação dos processos de negócio e qual o impacto que uma disrupção do processo pode
ter no negócio. O tempo de indisponibilidade deve refletir o máximo que o DNS.PT pode tolerar
de modo a poder continuar a fornecer os seus serviços;
• Identificar prioridades de recuperação para os recursos do sistema, tendo por base os resultados
previamente obtidos devem-se identificar os processos crı́ticos.
Um dos pontos do BIA onde foi necessário ter presente uma linha condutora foi na definição de
escalas de impacto, uma vez que os colaboradores estavam já habituados a trabalhar com escalas de
impactos de 1-5 seria contra producente estar a criar uma nova escala só para efeitos de BIA. Estas
escalas depois de aplicadas a cada processo no caso do mesmo falhar e combinadas com os tempos
crı́ticos de recuperação RTO, RPO e MTD, especı́ficos de cada processo, definem a criticidade de um
dado processo.
Esta definição da criticidade e do impacto que os processos têm no negócio, para além da im-
portância que têm para a elaboração de um plano de continuidade de negócio, onde é fulcral saber
priorizar as tarefas de recuperação, tem extrema importância para o processo de gestão de risco pois
vai influenciar o nı́vel de risco dos ativos que são utilizados nesse mesmo processo. No anexo B pode-
mos consultar o BIA criado de acordo com aquilo que foi definido como importante de contemplar para
o negócio e objetivos da organização.
Após a concepção dos modelos, a definição das polı́ticas e do BIA seguiu-se a obtenção da arqui-
tetura do negócio. Nesta tarefa é importante perceber do que depende cada processo e que relações
existem entre processos. Deste modo aproveitando o levantamento de ativos feito para a certificação
da norma ISO 27001 foi feita uma revisão para identificar novos ativos e eliminar ativos que já não
existiam e em colaboração com o departamento técnico procedeu-se à elaboração da arquitetura do
negócio, identificando as dependências entre processos, sistemas de informação e ativos. Não será
aqui mostrado em anexo o que resultou do levantamento devido a questões de confidencialidade.
Por fim, recorreu-se ao método BIA, previamente definido, e procedeu-se à identificação dos pro-
cessos crı́ticos e dos impactos que estes têm no negócio, para tal atribuiu-se um nı́vel de impacto de
1-5 em cada área a considerar para cada processo, atribuiu-se um tempo crı́tico de recuperação, tendo
1 https://www.dns.pt/pt/
46
sempre presente as relações de dependência com outros processos e, combinando todas estas verten-
tes calculou-se um nı́vel de criticidade para cada processo do negócio. Á semelhança do levantamento
da infraestrutura também o resultado do BIA não pode ser divulgado uma vez que trata informação
confidencial que, à partida, nem sequer é divulgada a toda a associação.
Para conseguir fazer estes cálculos e estas atribuições foram realizadas reuniões com os res-
ponsáveis dos processos e com o responsável pelo negócio para que estes atribuı́ssem os tempos
crı́ticos e os impactos respetivos a cada processo, era no entanto necessário evitar que todos os pro-
cessos fossem considerados de extrema importância, para que tal não acontecesse foi necessário
proceder a uma prévia explicação sobre os objetivos a atingir e, posteriormente, colocar questões que
obrigassem a focar o essencial, como por exemplo:
• É possı́vel realizar o processo sem este serviço/sistema?
• Quanto tempo o DNS.PT aguenta no limite sem este processo numa situação de crise?
• Admitindo que ficava sem o sistema x, conseguia executar o seu processo?
Ao colocar questões como as expostas conseguiu-se um maior entendimento por parte dos res-
ponsáveis dos processos do objetivo que se pretendia atingir. Após ter fechado a questão da definição
das criticidades dos processos entrou-se na fase da aferição de risco.
Como o DNS.PT tinha já estruturado um processo de gestão de risco para a segurança da informação
assim como a certificação ISO 27001, estava calendarizada à partida uma revisão dos riscos e uma
reaferição dos mesmos no âmbito desta certificação, deste modo e aproveitando que se estava a rever
o registo de riscos foram introduzidos riscos relativos à continuidade de negócio e alargou-se o espectro
de análise dos riscos existente para considerar também os impactos da continuidade de negócio para
além da segurança da informação que já era analisada.
Como o DNS.PT baseia o core do seu negócio na tecnologia do protoloco DNS.PT e opera na
área de jurisdição da IANA que recomenda os gestores de domı́nios de topo a implementarem alguns
mecanismos de segurança segundo as boas práticas internacionais, já existiam a priori mecanismos
que garantiam a continuidade do negócio e, desse modo, apesar de se ter alargado o âmbito a análise
de risco, não houve alterações para além do limite considerado pelo DNS.PT como aceitável no nı́vel de
risco. Isto provocou que não houvesse a necessidade de estar a executar todo um processo de criar um
novo plano de tratamento de risco, optando-se antes por fazer uma revisão dos controlos existentes e
tentar otimizar os que já existem. Toda a informação relativa a riscos, controlos e análises dos mesmos
é também considerada como confidencial e, como tal, não pode ser anexada neste trabalho.
47
5.3 DNS.PT como Infraestrutura Crı́tica em Portugal
Durante o estabelecimento do contexto externo para a continuidade de negócio foi necessário iden-
tificar os requisitos legais para evacuações e situações de catástofre com a proteção civil, durante a
pesquisa da legislação percebeu-se que existia em Portugal uma lista de infraestruturas crı́ticas para
o paı́s. Após o conhecimento deste enquadramento foi do interesse do DNS.PT que se elaborasse
uma exposição para enviar à protecção civil 2 3
para que o DNS.PT pudesse passar a ser considerado
como infraestrutura crı́tica, a base da exposição enviada pode ser consultada no anexo C. Neste anexo
podemos ver que o argumento maior utilizado é:
“Manutenção de funções vitais para a sociedade o bem-estar económico ou social, e cuja perturbação
ou destruição teria um impacto significativo, dada a impossibilidade de continuar a assegurar essas
funções”. Este dois critérios são evocados porque tendo em conta que, hoje em dia a Internet desem-
penha um papel central na vida da sociedade, principalmente em termos de negócio e economia, um
provedor de serviços como o DNS.PT que garante a acessibilidade da “zona .pt” é absolutamente es-
sencial para muitas empresas portuguesas, como a banca por exemplo, cuja paralisação poderia levar
a um impacto muito severo na economia e sociedade portuguesa, (transcrição do anexo C).
Após conseguir a definição como uma das infraestruturas crı́ticas do paı́s foi considerado que os
processos crı́ticos do DNS.PT seriam aqueles que envolvessem a disponibilização dos domı́nios e
classificou-se a associação como um operador de telecomunicações, esta classificação não foi do
agrado da gestão por não corresponder ao que realmente é o core do negócio do DNS.PT, uma vez que
a proteção civil tinha deixado a classificação aberta a uma sugestão por parte da associação, tratou-se
de procurar qual seria a classificação mais adequada ao DNS.PT tendo em conta o seu negócio.
Uma das coisas que esteve sempre presente é que independentemente da área encontrada o modo
de funcionamento do DNS.PT era, e é, o de um service provider. Aqui podemos ler a transcrição da
proposta final de definição: ”O DNS.PT usa por base o protocolo DNS no core do negócio e conforme
analisado o âmbito deste protocolo pode-se considerar o ciberespaço. O enquadramento que esta
análise sugere ser possı́vel para o DNS.PT é o de um provedor de serviços no ciberespaço.”. Todo o
documento com a elaboração da proposta pode ser consultado no anexo D.
Esta proposta é inovadora e vem abrir um vazio que existe na classificação da proteção civil onde
não estão contemplados os modelos de funcionamento das organizações que operam grande parte do
seu negócio na Internet e no ciberespaço. Caso seja aceite esta classificação pode vir a ajudar outras
organizações semelhantes à DNS.PT quer em Portugal, quer noutros paı́ses, nomeadamente a nı́vel
europeu, uma vez que ainda não existe uma definição clara sobre este género de organizações e quer
Portugal, quer o DNS.PT podem ser vistos como um modelo a seguir.
De referir que no momento do término do meu trabalho na associaçao DNS.PT ainda não existia
uma resposta por parte da proteção civil à proposta que foi enviada.
2 http://www.prociv.pt/pt-pt/Paginas/default.aspx
3 http://www.prociv.pt/pt-pt/RISCOSPREV/INFRAESTRUTURASCRITICAS/Paginas/default.aspx
48
5.4 Conclusões
Ao longo deste trabalho procurei responder às necessidades de dois domı́nios, a continuidade de
negócio e a segurança da informação, estes dois domı́nios no caso de organizações muito ou total-
mente tecnológicas são profundamente complementares, pois como se viu, pela análise efetuada às
normas referência, existem muitos requisitos transversais.
Esta transversalidade quando estamos perante um negócio puramente assente na tecnologia foi
o que permitiu a elaboração com sucesso de um processo de gestão de risco que permita alimentar
os dois sistemas de gestão. No entanto apesar de uma grande limitação deste trabalho ser o fato de
ter sido aplicado e desenvolvido dentro de um contexto muito especı́fico e concreto com o crescente
aumento da importância das tecnologias, nomeadamente da informação digital, em todas as áreas de
negócio rapidamente nos aproximamos de uma situação em que, qualquer que seja o negócio, quando
falamos em continuidade de negócio e em segurança da informação estamos perante um cenário em
que todo o core do negócio é abrangido.
No entanto, ao longo do trabalho desenvolvido rapidamente me apercebi da importância de existirem
processos definidos e frameworks de aplicação como o COBIT, pois ao basear todo o trabalho de
gestão de riscos quer de continuidade de negócio, quer de segurança de informação em meros wishfull
thinkings onde não se define concretamente quem faz o quê, não estamos a solucionar um problema
mas sim a aumentá-lo.
Uma das ilações que retirei do trabalho realizado foi que a escolha da técnica de aferição de risco
foi fundamental para conseguir aplicar a arquitetura escolhida neste problema, o fato de ter optado
pelo BIA, que é um dos requisitos da continuidade de negócio, enquanto técnica de aferição de risco
não só permitiu poupar trabalho na definição de métodos de aferição, assim como que todos os riscos
estivessem alinhados nos parâmetros e escalas utilizados o que permitiu a realização da avaliação da
criticidade dos riscos e controlos com maior facilidade.
O fator de a continuidade de negócio obrigar a um pensamento total do negócio obriga a que a pes-
soa que está a implementar o processo de gestão de risco não se foque exclusivamente na segurança
da informação e pense também na implicação que um risco pode ter para o negócio.
Os maiores desafios por mim encontrados foram:
• Um desconhecimento inicial do tema e da cultura da organização que me levou a perder mais

tempo que o esperado na fase de pesquisa e ambientação;
• O ter de enquadrar as duas normas, ISO 27001 e ISO 22301 e encontrar uma única resposta para
gerir o risco de 2 normas distintas.
• Aquela que para mim foi maior dificuldade, a necessidade de conseguir fazer perceber nas entre-
vistas de recolha de dados a identificação do que apenas é crı́tico para o negócio porque existe a
tendência do ser humano considerar que o que é critico para si também é para o negocio o que
não é necessariamente verdade;
49
• O facto de o contexto do trabalho ser muito especı́fico o que dificultou a extrapolação para outros
domı́nios.
Ao logo de todo o trabalho retirei lições relativamente aos desafios ultrapassados, ao definri um
contexto pude perceber a importância de adaptar o trabalho desenvolvido ao negócio e que embora as
normas de SI e CN sejam semelhantes há que notar as pequenas diferenças entre ambas. Na atividade
da aferição do risco ficou percetı́vel a importância que as ações de sensibilização prévias aos projetos
têm por promoverem uma maior aceitação e compreensão do tema. Assim como o impacto que o
contexto tem na aferição do risco. Relativamente ao tratamento do risco, foi possı́vel verificar que o
negócio, as tecnologias usadas e guidelines seguidas têm muita influência na parte de definir controlos,
uma vez que interferem no contexto e nı́veis de risco. Adicionalmente consegui ter a experiência da
importância de um bom trabalho de equipa e de haver várias equipas alocadas a projetos diferentes a
colaborar entre si, sem dúvida que esta experiência me será muito útil na vida laboral onde e cada vez
mais utilizado o trabalho de equipa.
Uma grande limitação por mim notada nos processos de gestão de risco é que a análise dos riscos
está quase totalmente baseada na definição do contexto e nas suas implicações, isto implica que o
mais pequeno erro de análise no contexto, quer por substimar ou por sobrestimar um qualquer fator,
pode ter grandes repercussões no nı́vel de um risco o que pode implicar controlos desnecessários que
se traduzem em gastos que não seriam precisos ou em falta de controlos o que pode por em causa a
continuidade do próprio negócio.
Em suma considero que estes domı́nios são complementares e que não faz sentido pensar na
segurança da informação descurando a continuidade do negócio do mesmo modo que não faz sentido
considerar a continuidade do negócio descurando a segurança da informação. Para além desta reci-
procidade entre os dois domı́nios considero também que se pode concluir que é possı́vel englobar a
gestão do risco num só domı́nio facilitando assim a implementação de sistemas de gestãos de ambos
os domı́nios. Um outro fator importante é o fato de conforme se viu com o COBIT hoje em dia as fra-
meworks para o governance do negócio já permitem realizar este tipo de soluções, sendo por isso algo
aplicável atualmente.
5.5 Trabalho Futuro

A realização deste trabalho pode servir de referência para organizações, por exemplo, outros cc-
TLD’s que queiram seguir o caminho que o DNS.PT decidiu iniciar, e isso levar a que se tenham de
buscar complementariedades e desenhar processos de gestão de risco para domı́nios diferentes o que
traria um incremento de kown-how e case studies para auxiliar as organizações.
Pode também servir de incentivo a uma maior procura de frameworks como o COBIT, uma vez
que se viu ser possı́vel mapear os processos COBIT com os requisitos das normas referência para o
trabalho.
Seria bastante útil o desenvolvimento de um processo de gestão de risco que conseguisse englobar
as diferentes perspetivas e pontos de vista que uma organização pode ter, neste caso a preocupação
50
foi apenas em 2 domı́nios ”base”de uma organização como o DNS.PT, no entanto o poder haver
um processo global de aplicação transversal traria grandes benefı́cios, uma vez que poria toda uma
organização muito mais resiliente ao risco.
51
Anexos
52
Anexo A
Proposta BIA ISACA
Este anexo é conforme o encontrado no site da ISACA. 1 .
1 http://www.isaca.org/Groups/Professional-English/business-continuity-disaster-recovery-planning/
GroupDocuments/Business_Impact_Analysis_blank.doc
53
Business Impact Analysis

Objectives
The purpose of the business impact analysis (BIA) is to identify which business units/departments and
processes are essential to the survival of _____________. The BIA will identify how quickly essential business
units and/or processes have to return to full operation following a disaster situation. The BIA will also identify
the resources required to resume business operations.
Business impacts are identified based on worst-case Scenario that assumes that the physical infrastructure
supporting each respective business unit has been destroyed and all records, equipment, etc. are not accessible
for 30 days. Please note that the BIA will not address recovery solutions.
The objectives of the BIA are as follows:

• Estimate the financial impacts for each business unit, assuming a worst case scenario.
• Estimate the intangible (operational) impacts for each business unit, assuming a worst-case scenario.
• Identify the organization’s business unit processes and the estimated recovery time frame for each
business unit.
Policy
Each Facility Business Continuity Planner shall perform a BIA on all business processes to determine the
criticality of these processes to ______________ and to determine what the impacts are to the organization if
those processes were interrupted. It shall identify the business process availability Recovery Time Objectives
(RTOs), business process Recovery Point Objectives (RPOs), key business processes and the associated risks if
these processes were not available.
Scope
Each Facility within __________________. should have a Business Impact Analysis which includes each
department and process located within the facility.
Business Impact Analysis Scores
The following number scores have been established to provide firm tangible and intangible exposure categories
for cross-company comparison.
Cumulative Dollar Loss Ranges (Tangible)
Score Loss Range

0 none
1 < $1,000
2 ≥ $1,000 < $5,000
3 ≥ $5,000 < $10,000
4 ≥ $10,000 < $25,000
5 ≥ $25,000 < $50,000
6 ≥ $50,000 < $100,000
7 ≥ $100, 000 < $150,000
8 ≥ $150,000 < $250,000
9 ≥ $250,000 < $500,000
10 ≥ $500,000
Customer Service and Goodwill Loss Ranges (Intangible)
Score Effect
0 None
2 Minimal
4 Moderate
6 Moderately Heavy
8 Heavy
10 Severe
Definitions
Impact Category Definition

Loss of Revenue Loss of income received from selling goods or services
Additional Expenses Temporary staffing, overtime, equipment, services
Fines, penalties, compliance issues, contractual obligations, financial
Regulatory and Legal
liabilities
Termination or reduction of service level (internal of external), live
Customer Service
operators vs. automated response
Goodwill Public image, shareholder relations, market share
Business Impact Analysis Questionnaire
A Business Impact Analysis is a process used to determine the effect of an interruption of services on each
business unit and the organization as a whole. The analysis can provide information on the short and long
term effects of a disaster on such factors as profit, market share and goodwill.
This information in required to develop a business continuity strategy for the entire organization. Please fill
out this questionnaire in as much detail as possible. Your input will be valuable in developing an effective
Business Continuity program.
Business Unit/Department Name:
Description of Business Unit/Department’s Purpose in the Organization:
Name of Unit/Department’s Manager/Director:
In the followings table, list the business processes performed by the Business Unit/Department
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
For each business process listed above, fill out a questionnaire sheet.
Completed by: Date:

Business Impact Analysis Questionnaire
Business Unit/Department Name:
Business Process Name:
Business Function Description:
1. Does this Function have to be performed at a specific time of the day/week/month/year?

No Yes- If yes, state the requirement:
2. Using the Impact categories to classify the type of loss incurred and the Loss ranges (0 through 10) specify your
estimated amount of exposure during each time period below:
Cumulative Impact after Days:
Impact Category 1 3 5 10 20 30
Loss of revenue
Additional expenses
Regulatory and legal
Customer service
Goodwill
3. Is this function dependent on any technology (hardware or software):
No Yes- If yes, list:
4. Does this function depend on any outside services or products for its successful completion?
No Yes- If yes, list:
5. What is the maximum amount of time this business process could be unavailable?
Completed by: Date:
Anexo B
Proposta BIA DNS.PT
Este anexo é o modelo BIA desenhado e utilizado no âmbito do trabalho e que foi adoptado pelo
DNS.PT.
58
2 Objetivo
O objetiv o do BIA é identificar e priorizar os processos de negócio correlacionando-os com o
impacto existente no negócio quando um ou mais processos estão indisponíveis.
O BI A é composto por dois passos:
 Determinar os processos de negócio e a criticidade da sua recuperação. Identificação

dos processos de negócio e qual o impacto que uma disrupção do processo pode ter
no negócio do mesmo modo que se dev e estimar o tempo de indisponibilidade. O
tempo de indisponibilidade dev e refletir o máximo que o DNS.PT pode tolerar de modo
a poder continuar a fornecer os seus serviços.
 Identificar prioridades de recuperação para os recursos do sistema. Tendo como base
os resultados previamente obtidos devem-se identificar os processos críticos.
3 Glossário
 RPO (Recovery Point Objective): Limite de tempo de dados que é aceitáv el perder
antes da disrupção.
 RTO (Recovery Time Objective): Limite máximo de tempo aceitáv el perder no processo
de recuperação após disrupção.
 MTD (Maximum Time of Disruption): Soma do RPO e RTO, tempo limite aceitáv el para o
processo estar indisponível.
4 Determinar Criticidade dos Processos
4.1 Identificar Impactos e Estimar Tempo de Indisponibilidade

Nesta secção identifica-se os tempos aceitáv eis de indisponibilidade e de recuperação de
cada processo e o inerente impacto financeiro, de imagem e reputação inerente ao não
cumprimento dos mesmos.
Para se fazer o processo do BI A serão realizadas as seguintes atividades:
 Aferição dos Processos e respetivos donos;
 I dentificação das dependências entre Processos e sistemas;
 Reunião com o dono de cada Processo;
o Dono de cada Processo responde ao questionário de modo a poder preencher
a tabela 5 para o seu Processo.
4.2 Criticidade
A Criticidade resulta da aferição do impacto na Reputação e do impacto financeiro
decorrente do não cumprimento do RTO e RPO, ou seja, a criticidade de um processo será o
v alor máximo entre o impacto financeiro, de imagem e reputação.
Lisboa, 14 de março de 2016 DNS.84.01

4.2.1 Tabelas de Impacto
Gravidade Impacto Financeiro Dia Semana Mês
1 – Muito Baixa =< 50,00 € 50,00 € 350,00 € 1.500,00 €
2 - Baixa =< 500,00 € 500,00 € 3.500,00 € 15.000,00 €
3 - Moderada =< 10.000,00 € 10.000,00 € 70.000,00 € 300.000,00 €
4 - Alta =< 20.000,00 € 20.000,00 € 140.000,00 € 600.000,00 €
5 – Muito Alta > 20.000,00 € > 20.000,00 € > 140.000,00 € > 600.000,00 €
Tabela 1 - Impacto Financeiro
Criticidade RTO Criticidade RPO Criticidade MTD
1 – Muito Alta <4h 1 – Muito Alta >0h e <1h 1 – Muito Alta <4h
2 - Alta >4h e <1d 2 - Alta >1h e <1d 2 - Alta >4h e <1,5d
3 - Moderada >1d e <3d 3 - Moderada >1d e <3d 3 - Moderada >1,5d e <4d
4 - Baixa >3d e <14d 4 - Baixa >3d e <7d 4 - Baixa >4d e <15d
5 – Muito Baixa >14d e <30d 5 – Muito Baixa >7d e <14d 5 – Muito Baixa >15d e <37d
Tabela 2 - RTO Tabela 3 - RPO Tabela 4 - MTD
Gravidade Reputação e Imagem
1 – Muito Baixa Erros i nternos sem interação com comunicações externas, que não tem qualquer i mpacto na continuidade de negócio.
Fa l has ou erros com impacto residual na continuidade de negócio dada a sua rápida resolução ou p ouca re l evâ nci a
2 - Baixa pa ra o negócio.
Fa l has ou erros dentro da comunidade DNS.PT, que originem alertas ou re cl a ma çõ es m a s q ue n ã o res ul ta m e m

3 - Moderada publicidade negativa, não tendo impacto direto na continuidade de negócio.
Fa l has ou erros com impacto na continuidade de negócio dentro da comunidade DNS.PT, redes s oci a i s e ca na is d e
4 - Alta comuni ca çã o na ci ona i s , com a pos s i bi l i da de de provoca r publ i ci da de di fa ma tóri a , que a feta m o negóci o
comprometendo-o de forma irreversível a curto-prazo.
Fa l has ou erros com impacto na continuidade de negócio dentro da comunidade DNS.PT, redes s oci a i s e ca na is d e
5 – Muito Alta comunicação nacionais e i nternacionais, que p rovocam publicidade difamatória ou quebra de integri da d e d e da d os
publicados pelo DNS.PT, que a fetam o negócio comprometendo-o de forma i rreversível a médio-prazo.
Tabela 5 – Impacto de Reputação e Imagem
Processo RPO RTO MTD Reputação Impacto (€) Criticidade
Tabela 6 – Aferição do Impacto e Criticidade do Processo
Lisboa, 14 de março de 2016 DNS.84.01

Anexo C
Definição Infraestrutura Crı́tica
Este anexo é um memorando sobre como se definem infraestruturas crı́ticas em Portugal e como o
DNS se pode considerar uma delas.
61
Memorando
Para: Dr.ª Inês Esteves
De: João Fialho
CC: .
Data: 1-12-2015
Assunto: Avaliação de Estruturas Críticas em Portugal
Pretende-se com este memorando fazer uma exposição sobre como se avaliam estruturas
críticas em Portugal e sobre quem recai essa responsabilidade.
O conceito de Infraestrutura Crítica (IC) foi definido pelo Decreto-Lei n.º 62/2011:
Artigo 2.º
Infra-estruturas críticas
Para efeitos do presente decreto -lei, entende-se por:
a) «Infra-estrutura crítica» a componente, sistema ou parte deste situado em
território nacional que é essencial para a manutenção de funções vitais para a
sociedade, a saúde, a segurança e o bem-estar económico ou social, e cuja
perturbação ou destruição teria um impacto significativo, dada a impossibilidade de
continuar a assegurar essas funções;
b) «Infra-estrutura crítica europeia» ou «ICE» a infra-estrutura crítica situada em
território nacional cuja perturbação ou destruição teria um impacto significativo em,
pelo menos, mais um Estado membro da União Europeia, sendo o impacto aval i ado
em função de critérios transversais, incluindo os efeitos resultantes de dependências
intersectoriais em relação a outros tipos de infra–estruturas.
Após a pesquisa conclui-se que “Em Portugal, a proteção de infraestruturas críticas teve
início em 2004”[1], e que este mesmo plano foi responsabilidade do Conselho Naci onal do
Planeamento Civil de Emergência (CNPCE). Na altura da elaboração deste plano foi feita uma
avaliação das estruturas críticas a nível nacional, não tendo sido encontrada à data qualque r
referência a outro plano ou levantamento.
Em Março de 2012 o Decreto-Lei nº 73/2012, transfere as responsabilidades do CNPCE para
a Autoridade Nacional de Proteção Civil (ANPC), “reforço das atribuições da Autoridade
Nacional de Proteção Civil em matéria de política de proteção civil, em especial pela
absorção das atribuições anteriormente cometidas ao Conselho Nacional de Planeamento
Civil de Emergência”
Desde dessa data é da responsabilidade da ANPC a avaliação e proteção de infrae struturas
críticas.
No site da ANPC encontra-se o seguinte parágrafo: “A Autoridade Nacional de Proteção Civil,
enquanto entidade atualmente detentora das atribuições do CNPCE, tem vindo a
desenvolver esforços no sentido da rápida implementação do quadro legal vigente, tarefa na
qual se encontra a trabalhar em estreita parceria com o Gabinete do Secretário Geral do
1
Sistema de Segurança Interna, com as forças e serviços de segurança e com entidades
representantes dos sectores da energia e dos transportes. Para além da atividade
permanente de atualização do inventário de infraestruturas críticas nacionais, está em curso
a identificação dos planos de segurança dos operadores já exi stentes e a definição de um
modelo/guião orientador para a elaboração e implementação de tais Planos por parte dos
operadores que ainda não os possuam.”[1]
Segundo este excerto é dado a entender que atualmente ainda estão a proceder a esta
atualização do levantamento feito anteriormente, porém não se encontra nenhuma menção
direta relativa às Tecnologias da Informação, não havendo data limite de término.
Enquadramento DNS.PT
Atendendo à legislação que vigora atualmente onde se encontra a definição de
infraestrutura crítica, os motivos para considerar a Associação DNS.PT como tal são:
 “Manutenção de funções vitais para a sociedade […]o bem-estar económico ou
social, e cuja perturbação ou destruição teria um impacto significativo, dada a
impossibilidade de continuar a assegurar essas funções”
Este dois critério são evocados porque tendo em conta que, hoje em dia a Internet
desempenha um papel central na vida da sociedade, principalmente em termos de negócio e
economia, um provedor de serviços como a associação que garante a acessibilidade da
“zona .pt” é absolutamente essencial para muitas empresas portuguesas, como a banca por
exemplo, cuja paralisação poderia levar a um impacto muito severo na economia e
sociedade portuguesa.
Referências
1. http://www.prociv.pt/RISCOSVULNERABILIDADES/Pages/InfraestruturasCriticas.aspx
2. http://segurancaecienciasforenses.com/2012/03/04/proteccao-de-infra-estruturas-
criticas-2/
3. http://www.segurancaonline.com/gca/?id=966
2
Anexo D
Classificação enquanto Infraestrutura

Crı́tica
Este anexo é um parecer sobre como deve ser classificado o DNS.PT enquanto uma IC em Portu-
gal.
64
DNS.PT enquanto Infraestrutura Crítica Nacional
A Associação Nacional de Proteção Civil (ANPC) considerou na sua classificação de
infraestruturas críticas para Portugal os processos de delegação de domínios e de registo e
alteração de domínios. Estes processos segundo a ANPC foram englobados na classificação
de Comunicação de Dados e Internet.
Analisando os indicadores a que se têm de dar resposta enquanto infraestrutura

crítica de Comunicação de Dados e Internet, constata-se que estes não fazem parte da
realidade de negócio do DNS.PT e que por isso é impossível ao DNS.PT responder a estes
requisitos. Após esta análise, por iniciativa do DNS realizou-se um trabalho de pesquisa com
vista a obter uma categorização adequada enquanto infraestrutura crítica. Durante a
realização deste mesmo trabalho feito um levantamento de informação de modo a
conseguir perceber onde enquadrar o DNS.PT.
Da pesquisa ressalvam-se os seguintes pontos:
o Segundo a International Electrotechnical Commission (IEC) uma

telecomunicação é uma comunicação por cabo, sinal rádio, ótico ou
qualquer outro sistema eletromagnético. [1]
o Esta entidade considera igualmente que também se pode classificar por

telecomunicação qualquer transmissão, emissão ou receção de sinais,
imagens, texto, sons ou dados sob qualquer tipo de cabo, sinal rádi o, óti co
ou qualquer outro sistema eletromagnético. [1]
o Segundo a mesma entidade um service provider é uma organização que

presta um serviço a utilizadores ou a outros providers. Os serviços podem
ser de acesso à Internet, conteúdos, informação, sistema de mensagens
privadas ou de armazenamento de conteúdos por exemplo. [1]
o Segundo o governo dos USA o setor da IT é operado por uma combinação de

entidades que mantêm a rede, incluindo a Internet. As funções deste se tor
são virtuais e distribuídas e têm como objetivo fornecer hardware, software,
tecnologias e serviços da informação. Este setor em conjunto com o setor
das comunicações é responsável pela Internet. [2]
o O Departamento de Defesa dos USA define o ciberespaço como um domínio

global dentro do ambiente de informação, composto pela rede
interdependente de infraestruturas de TI onde se inclui a Internet, as re de s
de telecomunicações, os sistemas de computadores. [6]
o Para o governo britânico o ciberespaço é um domínio interativo feito a partir

de um conjunto de redes digitais e é usado para armazenar, modificar e
comunicar informação, ele inclui a Internet e outros sistemas de informação
que suportam os negócios do dia-a-dia, infraestruturas e serviços. [3]
o O governo alemão define o ciberespaço como o espaço virtual que liga

todos os sistemas das tecnologias da informação ao nível dos dados e de um
modo global. A base do ciberespaço é a Internet como uma rede de acesso e
transporte global de dados. Esta rede pode ser expandida adicionando uma
1
qualquer rede de dados adicional. Sistemas de IT isolados num espaço
virtual não pertencem ao ciberespaço. [4]
o No panorama português o ciberespaço vem definido no instituto de de fesa

nacional como ambiente virtual onde se agrupam e relacionam utilizadore s,
linhas de comunicação, sites, fóruns, serviços de internet e outras redes”. [5]
o Atualmente, a Porto Editora define o ciberespaço como o “espaço virtual

constituído por informação que circula nas redes de computadores e
telecomunicações “e a Priberam define-o como “o espaço ou conjunto das
comunidades de redes de comunicação entre computadores,
nomeadamente a Internet”. [6]
Considerações
Após esta pesquisa é considerado pelo DNS.PT que a possibilidade de criar uma
subcategoria, sob Comunicações, que melhor se adeque quer aos processos considerados
quer ao negócio da própria associação é porventura a melhor alternativa para o
enquadramento do DNS.PT enquanto infraestrutura crítica.
Observando as definições dadas ao ciberespaço conclui-se que as IT operam sob e l e

e que a Internet tem um papel fundamental uma vez que é o liga os diversos sistemas IT e o
que permite que estes comuniquem, criando um ciberespaço global. Para além desta
definição o ciberespaço tem ainda a característica de poder armazenar e modificar
informação.
O protocolo DNS funciona como uma base de dados hierárquica onde é possível
fazer a tradução entre endereços IP e nomes de domínios. Este protocolo não é responsáve l
por fazer qualquer tipo de comunicação, o que o DNS faz é encaminhar a comunicação para
o destino ao indicar o endereço IP pretendido.
Este protocolo é uma tecnologia basilar da Internet, por consequência també m o é

do ciberespaço, porque se sem DNS hoje a Internet não funcionaria, então o ciberespaço,
que como se viu é um conjunto de redes sendo a Internet a rede por excelência do
ciberespaço, perderia a sua maior rede.
Existe sim uma relação de complementaridade entre telecomunicações e o

ciberespaço com os seus serviços, não obstante o facto de serem áreas distintas elas
colaboram entre si, uma vez que as telecomunicações fornecem o meio físico para que estes
serviços possam existir e estes serviços de certo modo permitem extrair todo o potencial das
telecomunicações.
O modelo de atuação do DNS.PT é o de um service provider. Uma vez que faz a

gestão de domínios (um domínio é considerado como informação e o seu armazenamento
considera-se armazenamento de conteúdos), vendendo-os quer a utilizadores finais, que r a
revendedores de domínios.
O DNS.PT usa por base o protocolo DNS no core do negócio e conforme anali sado o
âmbito deste protocolo pode-se considerar o ciberespaço. O enquadramento que esta
análise sugere ser possível para o DNS.PT é o de um provedor de serviços no ciberespaço.
2
Bibliografia
[1].http://www.electropedia.org/iev/iev.nsf/display?openform&ievref=701 -01-05
[2].https://www.dhs.gov/information-technology-sector
[3].https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/60961/uk -
cyber-security-strategy-final.pdf
[4].https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/Cyber Security/Cyber_Secu
rity_Strategy_for_Germany.pdf?__blob=publicationFile
[5].http://www.idn.gov.pt/publicacoes/cadernos/idncaderno_12.pdf
[6].http://www.revistamilitar.pt/artigo.php?art_id=854
3
Bibliografia
[1] International Organization for Standardization (ISO): Societal security - Business continuity mana-
gement systems - Requirements. ISO 22301:2012, 2012
[2] Professional Evaluation and Certification Board (PECB): Whitepaper ISO 22301: Societal security -
Business continuity management systems.
[3] BSI: Moving from BS 25999-2 to ISO 22301: The new international standard for business continuity
management systems.
[4] International Organization for Standardization (ISO): Risk Management - Principles and guidelines.
ISO 31000:2009, 2009
[5] International Organization for Standardization (ISO): Security techniques - Information security ma-
nagement systems - Requirements. ISO 27001:2013, Second Edition 1-10-2013
[6] International Organization for Standardization (ISO): Risk management — Risk assessment techni-
ques. ISO 31010:2009, 2009.
[7] Gonçalo Mateus: A Risk Register for Information Security - Relatório de Projeto de Dissertação do
Mestrado em Engenharia de Telecomunicações e Informática, IST, Janeiro 2016
[8] ISACA: COBIT

R 5, 2012.
[9] Andrew Hiles FBCI, Director, Kingswell International Limited The Definitive Handbook of Business
Continuity Management. Wiley, third edition, first edition in 2011.
[10] Nelson Gibbs: COBIT 5 for Risk, The Institute of Internal Auditors International Conference, Van-
couver, 5-8 Julho 2015.
68

METI Dissertacao JoaoFialho 68153

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

METI Dissertacao JoaoFialho 68153

Enviado por

Direitos autorais:

Formatos disponíveis

Processo de Gestão de Risco para Segurança da

Informação e Continuidade de Negócio

João Carlos Gonçalves Fialho

Dissertação para obtenção do Grau de Mestre em

Engenharia de Telecomunicações e Informática

Orientador: Prof. José Luís Brinquete Borbinha

Out of the night that covers me,

In the fell clutch of circumstance

Beyond this place of wrath and tears

It matters not how strait the gate,

W ILLIAM E RNEST H ENLEY

Palavras-chave: Continuidade do Negócio, Segurança da Informação, Processo Gestão de

5 Conclusões e Trabalho Futuro 44

A Proposta BIA ISACA 53

B Proposta BIA DNS.PT 58

C Definição Infraestrutura Crı́tica 61

D Classificação enquanto Infraestrutura Crı́tica 64

2.1 Mapeamento entre pontos nas normas ISO. [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

4.1 Repositórios de Informação utilizados nos 5 processos. . . . . . . . . . . . . . . . . . . . . . . 30

2.1 Plan-Do-Check-Act(PDCA) [1] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4.1 Processo de Estabelecer o Contexto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

BIA Business Impact Analysis.

ccTLD country code Top Level Domain.

DNS Domain Name System.

DNSSEC Domain Name System Security Extensions.

ICANN Internet Corporation for Assigned Names and Numbers.

ISP Internet Service Provider .

MTD Maximum Time of Disruption.

MTPD Maximum Tolerable Period of Disruption.

RPO Recovery Point Objective.

RTO Recovery Time Objective.

SGCN Sistema de Gestão de Continuı́dade de Negócio.

SLA Service Level Agreement.

consequência Resultado de um evento que afeta os objetivos.

continuidade de negócio Capacidade da Organização continuar a fornecer produtos ou serviços a

controlo Ação que modifica o risco.

DNS o protocolo usado para gestão e conversão de nomes em IP na Internet.

evento Ocorrência ou mudança de um conjunto particular de circunstâncias.

MTD ver MTPD.

processo Conjunto de atividades inter-relacioanadas ou que interagem entre si que transformam um

processo de gestão de risco Aplicação sistemática de polı́ticas de gestão, procedimentos e práticas

risco Efeito de incerteza nos objetivos.

segurança da informação Preservação da confidencialidade, autenticidade e disponiblidade da informação.

tratamento do risco Processo para modificar o risco.

• Demonstrar complementariedade entre as normas ISO 22301 e ISO 27001;

• Demonstrar que ambos domı́nios têm os mesmo requisitos de gestão risco;

2.1 Continuidade de Negócio

O conceito continuidade de negócio surge da necessidade das empresas desenvolverem mecanis-

Tabela 2.1: Mapeamento entre pontos nas normas ISO. [2]

2.1.1 A norma referência ISO 22301

• Tempo máximo aceitável de inoperabilidade;

• Objetivo mı́nimo de continuidade de negócio;

• Priorização das janelas temporais;

Figura 2.1: PDCA [1]

• Cláusula 4: Contexto da Organização;

• Cláusula 9: Avaliação do desempenho;

• Cláusula 10: Melhoramento.

Tipo de Exercı́cio O que é? Benefı́cios Desvantagens

Tabela 2.2: Formas de avaliar o desempenho da polı́tica implementada. [2]

2.1.2 Gestão de Risco em Continuidade de Negócio - ISO 31000

Figura 2.2: Processo de gestão de risco. [4]

• O nı́vel de risco é tolerável;

• Caso não o seja, gerar novos controlos no risco;