processo de gestão de risco para segurança da informação e … · processo de gestão de risco...

Processo de Gestão de Risco para Segurança daInformaçã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 FerreiraVogal: Prof. José Luís Brinquete Borbinha

Vogal: Prof. Miguel Leitão Bignolas Mira da Silva

27 de Outubro de 2016

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.

WILLIAM ERNEST HENLEY

iii

Agradecimentos

Ao Professor Jose Borbinha por toda a dedicacao e paciencia que teve para comigo durante todo o

trabalho indicando sempre qual o rumo a seguir, sem a sua orientacao nao teria conseguido concluir o

trabalho.

A todo o DNS.PT por toda a ajuda disponibilizada, em especial a Dr.a Ines Esteves, que sempre

acompanhou de perto sendo um exemplo de disponibilidade e trabalho, e ao Eng.o Rui Barquina que

atraves 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 colaboracao nao teria conseguido produzir o trabalho

que serve de sustentacao para esta dissertacao.

Sem nunca esquecer toda a minha famılia e amigos que sempre me apoiaram e deram forcas para

continuar, em especial os meus pais, irmao 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 motivacao e foco mesmo quando tudo

parecia impossıvel.

Por fim mas nao por ultimo, agradecer a Deus na certeza de que Ele me acompanhou em todo o

percurso e me deu atraves de todas as pessoas que se cruzaram no meu caminho as ferramentas para

conseguir alcancar este objetivo.

v

Resumo

Esta dissertacao surge da proposta que o DNS.PT realizou para o desenvolvimento de um plano de

continuidade de negocio de acordo com a norma ISO 22301. Analisei a norma ISO 22301 e colocou-se

a questao de como criar entao o processo para gerir os riscos da continuidade de negocio.

O problema a resolver surge da necessidade de integracao de um processo de risco para a continui-

dade de negocio num processo de gestao de risco para a seguranca da informacao (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 referencia a seguir para a gestao do

risco, decidi escolher a mesma como base do trabalho a desenvolver.

Analisando esta norma percebi que ela indica possıveis metodos de aferir risco atraves da norma

ISO 31010. O metodo escolhido foi o BIA por ser mandatorio na continuidade de negocio e aplicavel na

seguranca da informacao.

Para criar o processo usei a sugestao 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 propria organizacao que consegue ter todas as vertentes do negocio na

gestao do risco.

Palavras-chave: Continuidade do Negocio, Seguranca da Informacao, Processo Gestao de

Risco, Plano de Continuidade de Negocio, Normas ISO.

vii

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

Conteudo

Invictus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Agradecimentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Resumo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Lista de Tabelas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiii

Lista de Figuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Abreviaturas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii

Glossario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix

1 Introducao 1

1.1 Motivacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Objectivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Estado da Arte 4

2.1 Continuidade de Negocio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 A norma referencia ISO 22301 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Gestao de Risco em Continuidade de Negocio - ISO 31000 . . . . . . . . . . . . . 7

2.2 Seguranca da Informacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1 A norma referencia ISO 27001 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2.2 Gestao de Risco na Seguranca da Informacao - ISO 27005 . . . . . . . . . . . . . 11

2.3 Afericao de Risco em Continuidade de Negocio e Seguranca da Informacao . . . . . . . 13

2.3.1 BIA - ISO 31010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.3.2 BIA - Fundamentos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.3.3 BIA - Passo 1: Definir Ambito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.4 BIA - Passo 2: Recolher dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.3.5 BIA - Passo 3: Moderacao e Relatorio . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4 COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3 Analise do Problema 25

3.1 O Service Provider - Associacao DNS.PT . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2 Contexto do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

xi

3.3 Definicao do Problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Proposta de Solucao 29

4.1 Estabelecer Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Aferir o Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

4.3 Tratamento de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

4.4 Monitorizacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4.4.1 Monitorizacao de Estabelecer o Contexto . . . . . . . . . . . . . . . . . . . . . . . 38

4.4.2 Monitorizacao da Afericao de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.4.3 Monitorizacao do Plano de Tratamento de Riscos . . . . . . . . . . . . . . . . . . . 40

4.5 Comunicacao . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.6 Processo de Gestao de Risco no COBIT 5 . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5 Conclusoes e Trabalho Futuro 44

5.1 Objetivos e Desafios Iniciais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

5.2 Processo de Gestao de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3 DNS.PT como Infraestrutura Crıtica em Portugal . . . . . . . . . . . . . . . . . . . . . . . 48

5.4 Conclusoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

5.5 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Anexos 52

A Proposta BIA ISACA 53

B Proposta BIA DNS.PT 58

C Definicao Infraestrutura Crıtica 61

D Classificacao enquanto Infraestrutura Crıtica 64

Referencias 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 Repositorios de Informacao utilizados nos 5 processos. . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Atividades executadas no processo de Estabelecer o Contexto. . . . . . . . . . . . . . . . . . . 32

4.3 Atividades executadas no processo de Afericao de Risco. . . . . . . . . . . . . . . . . . . . . . 34

4.4 Atividades executadas no processo de Tratamento de Risco. . . . . . . . . . . . . . . . . . . . . 36

4.5 Atividades executadas no processo de Monitorizacao do Estabelecer Contexto. . . . . . . . . . . 38

4.6 Atividades executadas no processo de Monitorizacao da Afericao de Risco. . . . . . . . . . . . . 39

4.7 Atividades executadas no processo de Monitorizacao do Plano de Tratamento de Riscos. . . . . . 40

4.8 Atividades executadas no processo de Comunicacao e Consulta. . . . . . . . . . . . . . . . . . 41

xiii

Lista de Figuras

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

2.2 Processo de gestao de risco. [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Processo de gestao de risco norma ISO 27005. [7] . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.4 Principios do COBIT 5. [8] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.5 Areas chave do COBIT 5 para governance e gestao. [8] . . . . . . . . . . . . . . . . . . . . . . 24

2.6 Processos do COBIT 5 para governance e gestao. [8] . . . . . . . . . . . . . . . . . . . . . . . 24

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

4.2 Processo de Afericao de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

4.3 Processo de Tratamento de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.4 Processo de Monitorizacao do Contexto do Negocio . . . . . . . . . . . . . . . . . . . . . . . . 38

4.5 Processo de Monitorizacao da Afericao de Risco . . . . . . . . . . . . . . . . . . . . . . . . . . 39

4.6 Processo de Monitorizacao do Tratamento de Riscos . . . . . . . . . . . . . . . . . . . . . . . . 40

4.7 Processo de Comunicacao e Consulta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.8 Ligacao do COBIT 5 a outras normas e frameworks. [10] . . . . . . . . . . . . . . . . . . . . . . 43

4.9 Processos COBIT 5 para gerir o risco. [10] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

xv

Abreviaturas

BIA Business Impact Analysis.

ccTLD country code Top Level Domain.

CN Continuidade de Negocio.

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 Gestao de Continuıdade de Negocio.

SLA Service Level Agreement .

xvii

Glossario

anycast forma de encaminhamento onde os dados sao distribuıdos ao destino mais proximo, ou ao

melhor destino definido pelo routing da rede.

atividade processo ou conjunto de processos realizados por uma organizacao que produzem ou su-

portam um ou mais produtos e servicos.

BIA Analise do impacto que cada evento de carater disruptivo pode ter no negocio.

ccTLD e um domınio de topo na Internet geralmente usado e reservado para paıses ou territorios.

consequencia Resultado de um evento que afeta os objetivos.

continuidade de negocio Capacidade da Organizacao continuar a fornecer produtos ou servicos a

nıveis aceitaveis, definidos previamente, a seguir de um incidente disruptivo.

controlo Acao que modifica o risco.

criterio de risco Termo de referencia ou limite sobre o qual a significancia do risco e avaliada.

DNS o protocolo usado para gestao e conversao de nomes em IP na Internet.

DNSSEC visa melhorar a seguranca criada para o protocolo DNS, reduzindo o risco de manipulacao de

dados e domınios forjados, este mecanismo assenta em criptografia de assinaturas com recurso

a chaves assimetricas.

evento Ocorrencia ou mudanca de um conjunto particular de circunstancias.

gestao de risco atividades coordenadas que visam direcionar e controlar uma organizacao em relacao

ao seu risco.

ICANN entidade sem fins lucrativos, responsavel pela alocacao do espaco de enderecos IP (IPv4 e

IPv6), pela administracao do DNS, assim como gerir o sistema de servidores-raiz do DNS.

key drivers Procedimentos documentados que guiam a organizacao para responder, recuperar, reini-

ciar e restaurar a operacao para um nıvel pre-estabelecido a seguir a uma disrupcao.

MTD ver MTPD.

MTPD Tempo maximo de disrupcao aceite pela organizacao ate sofrer impactos no seu negocio.

xix

plano de continuidade de negocio Procedimentos documentados que guiam a organizacao para res-

ponder, recuperar, reiniciar e restaurar a operacao para um nıvel pre-estabelecido a seguir a uma

disrupcao.

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

input em um output .

processo de gestao de risco Aplicacao sistematica de polıticas de gestao, procedimentos e praticas

nas atividades de comunicacao, consulta, estabelecimento do contexto, e identificacao, analise,

avaliacao, tratamento, monitorizacao e revisao do risco.

registo de riscos Repositorio de toda a informacao relativa aos riscos, eventos, impactos, consequencias,

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 execucao, sem olhar a prioridades, tratando assim todos os processos de igual modo e

garantindo que todos tem direito ao seu tempo de execucao e o podem usufruir.

RPO Tempo maximo aceite de perda de informacao antes da ocorrencia de um evento disruptivo.

RTO Tempo mınimo aceite que o sistema pode levar a recuperar o seu funcionamento.

seguranca da informacao Preservacao da confidencialidade, autenticidade e disponiblidade da informacao.

sistema de gestao de continuidade de negocio Parte do sistema de gestao global que estabelece,

implementa, opera, monitoriza, reve, mantem e melhora a continuıdade de negocio.

stakeholders Partes interessadas ou intervinientes que podem ser afetadas por uma decisao ou ativi-

dade da organizacao.

tratamento do risco Processo para modificar o risco.

trends Procedimentos documentados que guiam a organizacao para responder, recuperar, reiniciar e

restaurar a operacao para um nıvel pre-estabelecido a seguir a uma disrupcao.

xx

Capıtulo 1

Introducao

1.1 Motivacao

O Domain Name System (DNS), e uma das ferramentas fundamentais para o funcionamento da

Internet, este protocolo efetua a resolucao de nomes de domınios em enderecos Internet Protocol(IP),

e vice-versa. Este protocolo consiste numa base de dados hierarquica e distribuıda, com mecanismos

de redundancia e distribuicao de carga, nomeadamente atraves do algoritmo Round Robin, multiplas

instancias de servidores de nomes, tal como define a especificacao do protocolo DNS. Mais recente-

mente, nas ultimas duas decadas, surgiram novos mecanismos para reforcar a seguranca e resiliencia

do servico DNS, nomeadamente DNSSEC e anycast.

A Internet e a sua utilizacao, nomeadamente a gestao e utilizacao de domınios, tem cada vez mais

impacto na vida das pessoas e das empresas, atendendo a criticidade, do servico de gestao 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 organizacao mecanismos e/ou processos que assegurem a continuidade do seu negocio

atraves de uma correta gestao do impacto que o risco associado a cada processo pode provocar ao

negocio.

Esta necessidade transversal a praticamente todas as organizacoes que se querem de sucesso,

provocou que por outro lado venham cada vez mais a compreender a necessidade de garantir que exis-

tem uma series de mecanismos dentro da sua organizacao que permitam uma protecao dos dados dos

seus sistemas de informacao e uma recuperacao dos processos core do negocio em tempo util para o

negocio da organizacao, pois os desastres acontecem e uma organizacao que transmita confianca, tao

fundamental para o mercado, e uma organizacao de sucesso (alguem confiaria num banco se soubesse

que nao havia mecanismos de backup e que caso haja um problema implicasse a nao salvaguarda das

transacoes?).

Deste modo tornou-se bastante claro para mim a importancia dos temas de gerir o risco, garantir

a continuidade de negocio e seguranca da informacao. Por serem temas bastante atuais, a motivacao

deste trabalho passou por responder a necessidade destes dois domınios em gerir o risco com o mesmo

processo de gestao de risco, de modo a poder comprovar a complementariedade dos temas.

1

1.2 Overview

Esta dissertacao baseia-se na resolucao de um problema, a criacao de um processo de gestao de

risco entre dois domınios, seguranca da informacao e continuidade de negocio. Para tal, em primeiro lu-

gar, foi realizada uma pesquisa sobre o estado da arte onde se procurou identificar as normas referencia

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.

Apos a realizacao desta pesquisa a conclusao 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 solucao.

De modo a implementar esta arquitetura foi necessario procurar uma tecnica de afericao de risco que

pudesse servir as necessidades da seguranca da informacao e da continuidade de negocio, na norma

ISO 31000 vem referido que existe uma lista de tecnica sugeridas para afericao do risco na mesma

norma. Apos analisar a norma ISO 31010 e comparar com os requisitos das normas ISO 22301 e

ISO 27001 a conclusao que tirei foi de que a tecnica de Business Impact Analysis (BIA) responde as

necessidades do meu problema.

Deste modo identificada a arquitetura a seguir e escolhida a tecnica 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 consideracao os requisitos das normas

referencia da ISO para os dois domınios e as atividades realizadas procuram responder a isso mesmo.

A principal logica passou entao por criar atividades que evitassem ao maximo a duplicacao de tra-

balho, por exemplo em vez de definir uma politica de seguranca da informacao e outra de continuidade

de negocio, define-se uma so polıtica de seguranca da informacao e continuidade de negocio onde se

responde aos requisitos das duas normas. Este exemplo ilustra aquilo que foi a logica condutora da

implementacao 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 seguranca da informacao e um sistema de continuidade de negocio ambos

baseados no mesmo processo de gestao de risco numa organizacao do mercado tecnologico.

Para conseguir cumprir com esse objetivo principal tenho de em primeiro lugar conseguir atingir

alguns objetivos secundarios:

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

• Demonstrar que ambos domınios tem os mesmo requisitos de gestao risco;

• Demonstrar que os requisitos de gestao de risco sao respondidos pela arquitetura de processos

proposta pela norma ISO 31000 e pela norma ISO 27005;

• Demonstrar que e possıvel aplicar um processo de gestao de risco comum entre domınios a

frameworks empresariais de processos, neste caso o COBIT5;

2

• Demonstrar que nao faz sentido pensar na seguranca da informacao sem considerar a necessi-

dade de salvaguardar a continuidade de negocio, do mesmo mdo que nao faz sentido salvaguar-

dar a continuidade de negocio sem assegurar a seguranca da informacao.

Cumprindos estes objetivos secundarios a que me proponho consigo, atingir o meu objetivo principal

que, conforme referi, passa por provar que e possıvel numa organizacao do mercado das tecnologias a

gestao de risco ser comum a seguranca da informacao e a continuidade de negocio.

3

Capıtulo 2

Estado da Arte

2.1 Continuidade de Negocio

O conceito continuidade de negocio surge da necessidade das empresas desenvolverem mecanis-

mos formais que permitam num caso de catastrofe ou interrupcao da sua atividade normal por qualquer

motivo, que o seu negocio continue a funcionar dentro da normalidade ou, pelo menos, que o core do

negocio continue a funcionar, permitindo a recuperacao 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 referencia hoje em dia e a norma ISO 22301 que e baseada na norma inglesa BS

25999. [3] Uma vez que a norma referencia para o caso e da ISO, e de todo relevante analisar as

possıveis relacoes entre os requisitos desta norma com as restantes normas de sistemas de gestao da

ISO.

Requisitos ISO 9001:2008 ISO 14001:2004 ISO 20000:2011 ISO 22301:2012 ISO 27001:2005

Objetivos do Sistema de Gestao 5.4.1 4.3.3 4.5.2 6.2 4.2.1

Polıtica do Sistema de Gestao 5.3 4.2 4.1.2 5.3 4.2.1

Comprometimento da Gestao 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 correspondencia entre as normas ISO para

sistemas de gestao, esta correspondencia e sem duvida um dos pontos fortes da norma ISO 22301, o

fator de se poder aproveitar e relacionar trabalho que ja esteja desenvolvido noutras areas.

Constata-se pois que esta facilidade em integrar sistemas de gestao ISO e um forte incentivo para

a implementacao das suas normas de referencia, neste caso a de Continuidade de Negocio.

2.1.1 A norma referencia ISO 22301

Uma vez que a norma ISO 22301 e a norma referencia hoje em dia para a Continuidade de Negocio

e de todo o interesse explorar o que ela determina. A norma ISO 22301 vem acrescentar alguns

conceitos que nao eram introduzidos ou explicitados de forma clara na norma anterior: [3]

• Contexto da organizacao;

• Partes interessadas;

• Lideranca;

• Tempo maximo aceitavel de inoperabilidade;

• Objetivo mınimo de continuidade de negocio;

• Avaliacao do desempenho;

• Priorizacao das janelas temporais;

• Alertas e comunicacao.

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 gestao de continuidade de negocio,

fazendo uso do metodo 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. Comecando no planeamento, aqui estabelece-se a polıtica, objetivos, controlos, processos,

tudo o que seja relevante no contexto da empresa para a continuidade do negocio. Na fase seguinte

proceder-se-a a implementacao do plano e processos desenvolvidos, para que avancando para o ter-

ceiro passo se faca uma avaliacao crıtica do que se tem de mudar ou melhorar do plano original. Se

a avaliacao for positiva, avanca-se para o estagio final do processo, onde se fara uma manutencao

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]:

• Clausula 4: Contexto da Organizacao;

• Clausula 5: Lideranca;

• Clausula 6: Planeamento;

• Clausula 7: Suporte;

• Clausula 8: Operacao;

• Clausula 9: Avaliacao do desempenho;

• Clausula 10: Melhoramento.

Na clausula 4, tendo explicitado a importancia do contexto de uma organizacao, uma vez que cabe

a empresa definir quais os departamentos, processos, sistemas, ativos, etc..., que sao relevantes para

a continuidade de negocio, ate porque a propria organizacao opera num contexto tambem ele relevante

para o negocio e isso tem de ser tido em conta aquando do desenho da solucao de continuidade. [1]

A clausula 5 refere-se a lideranca. O papel da lideranca e fundamental, cabe a quem lidera a

organizacao onde o vai implementar, mostrar compromisso com a norma e motivar os colaboradores a

aderirem, envolvendo-os no processo. Analisando a clausula 6, e logico 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, mensuravel, e monitorizavel. So com objetivos que correspondam a

estas caracterısticas se consegue ir ao encontro do que estipula a norma. [2]

Na clausula 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 clausula 8 esta dependente da anterior, uma vez que so se con-

segue fazer uma correta operacao se existir um suporte adequado, este e o ponto central desta norma,

comecando pela Business Impact Analysis (BIA) e preciso analisar o impacto que cada disrupcao pode

ter no negocio, em seguida avalia-se o risco associado a esse impacto, combinando-o com probabi-

lidade. Neste ponto a norma recomenda, para a afericao 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 clausula que se refere que uma organizacao

tem de implementar toda a polıtica delineada anteriormente para que conforme e dito na clausula 9 se

faca uma avaliacao. A avaliacao de desempenho pode ser feita de diversas formas: [2]

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

Checklist Distribuir planos para revisao Assegura que o plano alcanca todas as atividades Nao e eficaz

Tutorial estruturado Olha para cada passo do PCNAssegura que as atividades planeadas

sao corretamente descritas no PCNCapacidade de resposta de baixo valor

SimulacaoCenario para ativar

processos de recuperacaoSessao pratica

Quando os conjuntos sao

muito diferentes

ParaleloTeste total, no entanto o

processo primario nao para

Assegura um alto nıvel de fiabilidade

sem interromper o quotidiano do negocio

Muito caro, envolve todos

os colaboradores

Interrupcao TotalO desastre e replicado

ao ponto de parar o negocioTeste mais fiavel do PCN Arriscado

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 Gestao de Continuıdade de Negocio (SGCN) definir qual e a que melhor se adequa a

realidade da organizacao e do negocio. Por fim, a norma recomenda a organizacao entrar no ciclo da

clausula 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 elaboracao de um plano de continuidade de negocio e a existencia

de um processo de gestao de risco coeso e robusto de modo a que o alicerce do plano tambem o seja

(clausula 8 da norma ISO 22301).

2.1.2 Gestao de Risco em Continuidade de Negocio - ISO 31000

Uma vez que a norma referencia seguida para continuidade de negocio faz da norma ISO 31000 o

modelo a seguir para o processo de gestao de risco e de todo relevante analisar esta mesma norma.

A norma ISO 31000 descreve como se deve proceder para a gestao do risco, nesta norma encontra-se

definido de um modo generico como se deve criar um processo formal de gestao de risco.

Antes de proceder a descricao do modelo que a norma ISO 31000 propoe e importante referir alguns

conceitos chave [4]:

• Gestao de risco cria e protege valor, contribuindo para a concretizacao dos objetivos e melhoria

de desempenho;

• Gestao de risco e uma ferramenta que auxilia os decisores nas suas escolhas, ajudando nomea-

damente a priorizar alternativas;

• O bom desempenho da gestao de risco esta dependente da qualidade da informacao, uma vez

que quanto melhor for a informacao fornecida ao decisor, melhor ele podera aferir o risco;

• O processo de gestao de risco devera ser dependente do contexto, nao estatico de modo a poder

ser constantemente melhorado e bem estruturado;

7

• O processo de gestao de risco deve ser incorporado em todos os processos relevantes ao con-

texto.

Figura 2.2: Processo de gestao 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 comunicacao com todas as partes interessadas, ja que sera preciso estar em cons-

tante contacto, ao definir antecipadamente os canais de comunicacao, esta a ganhar-se eficiencia. [4]

Apos definir como se ira proceder toda a comunicacao, 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

ambito, dentro da organizacao, e que se vai aplicar o processo de gestao de risco. E completamente

diferente avaliar o risco apenas na visao da seguranca da informacao, onde a principal preocupacao

e a confidencialidade, integridade, e acessibilidade (CIA) da mesma, do que olhar para o risco na

perspetiva da continuidade de negocio, onde o fundamental e manter os processos fulcrais ao negocio

o mınimo tempo possıvel sem funcionar. O contexto externo determina em que condicoes se aplica a

gestao de risco, quer em termos de ambiente, quer em termos de partes interessadas, por exemplo

uma situacao de crise economica 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 criterio 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 afericao de risco temos 3 passos [4] :

• Identificacao do risco:

Esta tarefa e a primeira da afericao do risco, onde e necessario identificar todas as fontes de risco

e suas areas de impacto, eventos, causas e consequecias. O principal objetivo e gerar uma lista

de riscos com base nos eventos que podem gerar esses mesmos riscos. Ao contrario do que

se poderia pensar deve ter-se em conta fontes de potencial risco que nao sejam do controlo da

organizacao, isto e, deve considerar-se o risco sistemico.

8

• Analise do risco:

Aqui o objetivo e criar informacao para a tarefa seguinte. Ao analisar o risco pretende-se perceber,

causas, efeitos, probabilidade de as consequencias acontecerem, assim como os fatores que

afetam tanto a consequencia como a ocorrencia. Nesta analise, pode haver um evento a afetar

diversos objetivos, da mesma forma que diversos eventos podem afetar o mesmo objetivo.

• Afericao do risco:

Pretende-se com esta afericao auxiliar a tomada de decisoes, tendo como base a analise ja feita.

Afericao e feita comparando o nıvel de risco obtido na analise com os criterios de risco definidos,

caso assim se justifique o risco tera de ser tratado. Podera acontecer que a afericao recomende

uma analise mais profunda ou ate mesmo nao proceder a qualquer acao corretiva.

Concluıda a afericao 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 toleravel;

• Caso nao o seja, gerar novos controlos no risco;

• Aferir a eficacia 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 ocorrencia, mudar

as consequencias ou partilhar o risco com terceiros. [4]

Para decidir qual o melhor controlo e necessario ter em conta o esforco que sera preciso para o

controlo funcionar, e quanto e que vai custar. Estes fatores, por vezes, podem levar a organizacao

aceitar o risco. Por norma as organizacoes beneficiam quando os controlos sao combinados, isto e,

quando os controlos nao sao aplicados individualmente. Ao delinear controlos o gestor do risco nao

deve esquecer que o proprio tratamento introduz risco em caso de incumprimento ou mau planeamento.

[4]

Apos estas iteracoes e, como estamos perante um processo cıclico, devem ser feitos testes e

manutencao de forma regular ao processo de gestao de risco, mantendo-o assim sempre o mais atua-

lizado possıvel, de modo a responder as necessidades atuais da organizacao.

2.2 Seguranca da Informacao

O principal objetivo da seguranca da informacao e preservar a disponibilidade, confidencialidade

e a integridade da informacao. Pode tambem envolver a protecao e preservacao da autenticidade da

informacao assegurando assim que a informacao e de confianca. Uma organizacao que implemente

um sistema de gestao da seguranca da informacao transmite igualmente uma imagem de confianca

para o exterior, o que e de extrema importancia nos dias de hoje. [7]

No domınio da seguranca da informacao ha conceitos chave que e preciso ter em conta [7]:

9

• Ameaca: Causa potencial de um incidente indesejavel, pode prejudicar um sistema ou a organiza-

cao;

• Vulnerabilidade: Fraqueza de um ativo ou controlo que pode ser explorada por uma ou mais

ameacas;

• Evento: Ocorrencia ou mudanca de um conjuto particular de circunstancias;

• Consequencia: Resultado de um evento que afeta os objetos;

• Controlo: Medida que modifica o risco;

• Impacto: Mudanca negativa no nıvel dos objetivos de negocio alcancados;

• Ativo: Qualquer coisa que tenha valor para a organizacao.

Os ativos (neste caso, ativos de informacao) tem de ser protegidos atraves da definicao, alcance,

manutencao e melhoria eficaz da seguranca da informacao, mantendo e melhorando o seu cumpri-

mento legal e imagem. Estas atividades coordenadas apontam para a implementacao de controlos

adequados que tratam riscos inaceitaveis para a seguranca da informacao. [7]

As decisoes estrategicas relativas a seguranca da informacao devem estar em concordancia com os

stakeholders, e todos os parceiros relevantes. E muito importante que a seguranca da informacao esteja

integrada nos processos e estrutura da organizacao de forma a alcancar os objetivos propostos. [7]

2.2.1 A norma referencia ISO 27001

A norma ISO 27001 especifica os requisitos para estabelecer, implementar e manter de forma

contınua um sistema de gestao da seguranca da informacao numa qualquer organizacao. [5]

Do mesmo modo que as restantes normas ISO sobre sistemas de gestao ja abordadas neste re-

latorio, esta norma tem como clausula inicial para a definicao do sistema de gestao, (clausula 4) a

definicao do contexto da organizacao, perceber partes interessadas, parceiros, definir criterios e requi-

sitos a cumprir, onde aplicar a norma. [5]

Na clausula 5, esta norma frisa a importancia do comprometimento da gestao de topo na organizacao,

passando para a definicao de uma polıtica de seguranca da informacao. A polıtica deve estar alinhada

com os interesses da organizacao, definir os objetivos da seguranca da informacao e comprometer-se

com a aplicacao dos requisitos para a seguranca da informacao e a melhoria contınua do sistema de

gestao. O ultimo ponto desta clausula refere-se a atribuicao de responsabilidades e papeis relativos a

seguranca da informacao. [5]

A clausula 6 desta norma pode ser interpretada a luz da norma ISO 31000, uma vez que e aqui que

se faz a afericao do risco da seguranca da informacao. Espera-se que neste ponto a organizacao ja

tenha definido qual o criterio para aceitar ou nao risco e o criterio para realizar a afericao do mesmo

risco, assim como os objetivos que pretende atingir para a seguranca da informacao. Todo o processo

descrito vai de encontro a figura 2.2. A afericao e composta por identificar, analisar e aferir o risco da

10

seguranca da informacao sendo, por fim, executado o tratamento adequado ao risco (pode ir desde a

implementacao de controlos a aceitacao do risco). [5]

De seguida, na clasula 7, e referida a questao da importancia da gestao dar suporte ao sistema,

quer seja em termos orcamentais, quer em fornecer o conhecimento tecnico a colaboradores caso

isso seja relevante. E igualmente referido a semelhanca das ISO 22301 e ISO 31000 a importancia

de estabelecer canais de comunicacao e informar devidamente todas a partes interessadas sejam

estas internas ou externas. Existe, tambem, referencia a questao do controlo documental, este ponto

relaciona-se com a norma ISO 9001. [5]

Em termos operacionais e de avaliacao de desempenho (clausulas 8 e 9, respetivamente) a organi-

zacao deve proceder a afericao do risco, ao controlo operacional dos processos criados para responder

aos objetivos de forma regular, a avaliacao regular do desempenho do sistema e que seja avaliado

com base em auditorias internas com a consequente revisao do resultado por parte da gestao de topo.

Assim, pretende-se identificar de forma sistematica possıveis falhas e proceder a melhoria contınua do

sistema (clausula 10). [5]

2.2.2 Gestao de Risco na Seguranca da Informacao - ISO 27005

Esta norma ISO especifica os requisistos para um processo de gestao de risco da seguranca da

informacao de acordo com a norma ISO 27001, que pode ser aplicada de um modo abrangente a toda

a organizacao ou apenas a uma parte da mesma (sistema, departamento, por exemplo), ou aspetos

de controlo como um plano de continuidade de negocio 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-

cessario, se deve aprofundar a abordagem na afericao em cada iteracao. Nesta norma esta definido

um processo de gestao do risco na seguranca da informacao com o metodo PDCA, consistindo nos

seguintes passos: [7]

• Plan:

Estabelecer contexto (ver normas ISO 27001 clausulas 4/5 e ISO 31000 clausula 5.3);

Aferir o risco (ver ISO 31000 clausula 5.4);

Desenvolver um plano de tratamento do risco. O objetivo passa por identificar os controlos que

sao precisos para reduzir, reter, evitar ou transferir o risco.

• Do:

Implementar o plano de tratamento do risco (ver ISO 31000 clausula 5.5).

• Check :

Monitorizar e rever (ver ISO 31000 clausula 5.6), ter em especial atencao alteracoes que novos

ativos, vulnerabilidades ou ameacas possam trazer para a organizacao.

• Act :

Manter e melhorar o processo de gestao de risco recorrendo a monotorizacao e revisao cıclica do

mesmo.

11

Figura 2.3: Processo de gestao de risco norma ISO 27005. [7]

Como se pode ver pela figura 2.3 nem sempre, e possıvel tratar o risco na primeira iteracao, sendo

precisas novas iteracoes para o levar a um nıvel que seja aceitavel, nesta fase e deveras relevante

assegurar que os riscos sao aceites pela gestao de topo, principalmente quando questoes orcamentais

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 aceitavel;

• Gerar novo plano de tratamento se o nıvel nao se aceitar;

• Avaliar a eficacia do novo tratamento.

O objetivo deste processo e contribuir para identificar riscos e aferir as suas consequencias, fazendo

o seu relatorio pelos canais de comunicacao criados, envolvendo assim todas as partes interessadas no

processo. Conseguir estabelecer uma priorizacao do tratamento dos riscos de modo a poder aplicar em

primeiro lugar controlos aos riscos mais crıticos e urgentes (nocao de continuidade de negocio, primeiro

vem o fulcral do negocio, depois vem o resto). Criar um processo eficaz no tratamento e monitorizacao

do risco atraves de iteracoes cıclicas que proporcionem uma revisao periodica do processo. [7]

12

2.3 Afericao de Risco em Continuidade de Negocio e Seguranca

da Informacao

Apos analisar as duas tematicas, continuidade de negocio e seguranca da informacao, e importante

perceber se existe forma de ter um processo de gestao de risco que seja adequado as duas normas

referencia. Ao analisar as duas normas percebeu-se que ambas tem a norma ISO 31000 como norma

referencia para a gestao de risco, sendo que no caso da seguranca da informacao existe uma aplicacao

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 tecnica de afericao de risco que mais se adequa ao caso.

2.3.1 BIA - ISO 31010

A norma ISO 31010 explicita um conjunto de tecnicas de afericao de risco que se podem aplicar em

qualquer processo de gestao de risco que tenha a norma ISO 31000 por base.

Na norma ISO 31010 vem a tecnica de Business Impact Analysis, que e uma tecnica de afericao

de risco muito usada em continuidade de negocio, sendo, assim, escolhida para usar no processo de

gestao de risco. [1] Esta tecnica, embora amplamente usada neste meio, nao tem uma concretizacao,

existindo sim guidelines, nomeadamente na norma ISO 31010, que fornecem a ideia geral de como

se deve proceder. Esta limitacao abre a oportunidade de cada um poder adaptar esta tecnica as suas

necessidades o que e de extrema importancia visto que temos de conciliar a seguranca da informacao

com a continuidade de negocio.

Segundo esta norma ISO o BIA analisa como e que disrupcoes causadas por riscos chave afetam o

negocio de uma organizacao, identificando e quantificando que recursos sao precisos para gerir estes

impactos. [6]

A norma ISO identifica tres pontos-chave desta tecnica [6]:

• Identificacao e criticidade dos processos chave para a organizacao, atividades e ativos associa-

dos, assim como as interdependencias chave que existam para a organizacao;

• Como os eventos que geram disrupcao ao negocio vao afetar os objetivos de continuidade de

negocio;

• Recursos necessarios para gerir o impacto de uma disrupcao e recuperar a organizacao para

nıveis aceitaveis de operacao.

Esta tecnica e usada para definir a criticidade e tempos de recuperacao dos processos e ativos

associados de modo a assegurar que se continua a alcancar os objetivos da organizacao. Os recursos

precisos para aplicar esta tecnica sao [6]:

• Uma equipa para fazer a analise e desenvolver o plano;

• Informacao sobre os objetivos fundamentais, ambiente, operacoes e interdependencias da organizacao;

13

• Detalhes dos processos da organizacao, relacoes com outras organizacoes, outsourcing e sta-

keholders;

• Consequencias financeiras e operacionais da perda de processos crıticos;

• Lista de intervenientes de areas relevantes para a organizacao e/ou stakeholders que serao con-

tactados.

O processo para o BIA segundo a norma ISO 31010 pode ser feito atraves de questionarios, entre-

vistas, workshops ou combinando duas ou mais destas tecnicas que devem ser utilizadas com o objetivo

de obter uma melhor percecao da criticidade dos processos, dos efeitos de perda desses processos no

negocio, os tempos de recuperacao e recursos necessarios. [6]

Os pontos-chave que e preciso ter em consideracao num qualquer BIA, segundo a norma ISO

31010, sao [6]:

• Confirmacao dos processos chave da organizacao com base no seu output e determinar a critici-

dade dos mesmos. As vulnerabilidades e o risco poderao ser indicadores uteis para este ponto;

• Determinar as consequencias da disrupcao nos processos crıticos em termos financeiros e ou

operacionais, em perıodos definidos;

• Identificar as interdependencias entre stakeholders internos e externos;

• Determinar a quantidade de recursos que estao disponıveis e qual e o nıvel de recursos que sao

precisos para continuar a operar num nıvel aceitavel apos uma disrupcao;

• 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 interdependencias, documentar os impactos que os processos tem no negocio nas diversas

vertentes, fornecer os recursos adequados as necessidades de cada processo. E tambem esperado

que estejam definidos os tempos em que cada processo crıtico pode estar sem funcionar corretamente

e em recuperacao. [6]

A norma ISO 31010 identifica um conjunto de pros e contras nesta tecnica, nos pros temos o apro-

fundar do conhecimento dos processos da organizacao, que dota a organizacao da capacidade de

continuar a atingir os seus objetivos. Um outro ponto positivo e conseguir obter a lista de recursos

que sao precisos para alcancar os objetivos e a oportunidade que e dada de reformular e melhorar os

processos da organizacao para que ela se torne mais resiliente. [6]

Por outro lado, os contras do BIA, para esta norma ISO, sao a falta de conhecimento de todos os

participantes em realizar questionarios e entrevistas, o facto de as dinamicas de grupo poderem afetar

uma analise completa aos processos crıticos. O facto de as expectativas nos requisitos de recuperacao

serem demasiado otimistas e outro fator apontado, assim como o facto de nao se obter o conhecimento

adequado das atividades da organizacao. [6]

14

2.3.2 BIA - Fundamentos

O Business Impact Analysis e, sem duvida, o produto mais importante e fundamental do ciclo de

vida da continuidade de negocio. E atraves da realizacao do BIA que os requisitos da organizacao no

que diz respeito a responder a desastres sao respondidos de forma apropriada. [9]

Business Impact Analysis e definido1 como a analıse ao nıvel da gestao atraves do qual uma

organizacao realiza a afericao quantitativa dos impactos financeiros e a afericao qualitativa dos im-

pactos nao financeiros, que podem resultar de uma situacao onde a organizacao seja sujeita a uma

emergencia de continuidade de negocio, seja por um incidente de seguranca ou por uma crise. Os re-

sultados obtidos no BIA sao usados para tomar decisoes relacionadas com a estrategia e as solucoes

para a continuidade de negocio. [9]

Por outras palavras, o BIA ajuda a identificar qual e o custo de interromper o negocio, qual o impacto

que essa paragem tem nos lucros na organizacao, nas receitas, quao danificada fica a relacao com

clientes e a imagem exterior da organizacao. Para alem de ajudar a fazer esta identificacao, esta tecnica

permite ainda que o gestor do negocio entenda melhor qual o tempo de paragem que cada processo

pode tolerar antes de o impacto acontecer e quais saos recursos(pessoas, IT, outros processos, etc) do

qual este processo depende. [9]

O resultado ideal do BIA ao contrario do que se possa pensar e alcancado quando se consegue

fazer a identificacao exata dos recursos que sao precisos para proteger, recuperar e quao rapido se

consegue recuperar um processo de modo a conseguir manter um nıvel de servico aceitavel. [9]

Ter esta definicao em mente e muito util porque ajuda a focar o BIA nos impactos de um evento

e nao na causa do mesmo. Muitas organizacoes ficam profundamente focadas no exterior do BIA ao

estarem constantemente a definir possıveis cenarios, o que acaba por prejudicar a propria organizacao

pois acaba por se atrasar mais o processo e confundir os participantes. No fim de contas no BIA o que

nao importa e se a interrupcao do negocio foi causada por uma falha de energia, um incendio ou outra

situacao qualquer, o que importa ao realizar esta tecnica e que uma vez que o negocio parou saber as

consequencias e quao rapido se consegue recuperar. [9]

Por outro lado e sempre uma boa pratica 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

cenarios esta a ajudar-se quem realiza o BIA pela primeira vez e como tem de orientar a sua linha de

pensamento. Estes cenarios devem ser o mais explıcitos e de alto nıvel possıvel. Alguns cenarios que

costumam ser utilizados sao [9]:

• Edifıcio da sede e/ou datacenter deixa de estar disponıvel;

• O IT da organizacao deixa de funcionar parcial ou totalmente;

• Um ou mais processos da organizacao deixam de poder ser executados;

• Uma combinacao dos anteriores.

1Business 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 negocio. Esta abordagem assume que a organizacao

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 gestao e que

sejam alocados todos os recursos necessarios. Num estagio inicial de contato com a continuidade

de negocio pode ser a melhor estrategia atrasar a realizacao do BIA ate a continuidade de negocio

estar mais esclarecida dentro da cultura e polıtica da organizacao, tal a necessidade de nao produzir

resultados enganadores, a nao ser que a gestao da organizacao ja esteja a antecipar a necessidade

de atuar nos resultados obtidos. [9]

Deste modo, pode afirmar-se que para iniciar o BIA e necessario: [9]

• Um comprometimento claramente assumido por parte da gestao em alcancar os objetivos da

continuidade de negocio;

• A indicacao de que existe uma vontade da organizacao de investir em solucoes para a area da

continuidade de negocio que irao surgir com a ajuda dos resultados do BIA;

• Uma declaracao na polıtica da organizacao com o ambito que tenciona atribuir ao plano de conti-

nuidade de negocio.

2.3.3 BIA - Passo 1: Definir Ambito

O primeiro passo para a aplicar o BIA e definir o ambito no qual se vai aplicar esta tecnica. Este

passo pode-se subdividir em dois pontos:

Primeiro - a gestao de topo deve decidir se o BIA e para aplicar a toda a organizacao ou apenas

a uma parte da mesma (departamento, processo, etc...). Os fatores a ter em conta para tomar esta

decisao devem incluir o tamanho e a complexidade do negocio, a diversidade de processos que se vai

encontrar e principalmente os recursos disponıveis (pessoas) para fazer o BIA. [9]

Esta definido como boa pratica que em organizacoes de grande dimensao o processo do BIA deve-

se comecar por aplicar em apenas uma parte da organizacao, de preferencia 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 sao de qualidade e

consistentes de modo a poderem ser mais tarde. [9]

Segundo - Antes de se perguntar ao negocio o que e crıtico em situacao de desastre, e preciso

garantir que esta claramente definido o ambito de aplicacao do BIA, e aconselhavel a gestao elaborar

uma polıtica para o BIA e definir qual e o perıodo de interrupcao que se vai estar a lidar na analise. Pode-

se descrever este passo como o ’planeamento do horizonte’ que sera determinado por um conjunto de

fatores [9]:

• BIA a ser desenvolvido por subsidiarias dentro de um grupo empresarial, ou departamento dentro

de uma organizacao, devem considerar o impacto que possam ter no resto quer do grupo/departamentos,

quer o impacto que a organizacao tem em outros players no negocio;

16

• Para algumas organizacoes esta determinado como objetivo recuperar o negocio e resumir todos

os processos dentro de uma linha temporal pre-definida, no entanto tal objetivo pode nao ser

realizavel se estivermos a falar de uma multinacional, e necessario ter em conta quer o negocio

quer a dimensao da organizacao, a melhor solucao pode passar mesmo por uma recuperacao

gradual em muitos casos;

• Para facilitar uma tecnica util e comecar por realizar questoes de alto nıvel para determinar qual

e o ’planeamento do horizonte’ que melhor se adequa a realiade do negocio, ha requisitos que se

tem de ter em conta, um negocio na area dos servicos tem tempos e requisitos que uma fabrica

nao 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 negocio o que realmente se

pretende. Excepto em casos anormais, o normal e que tudo, ou quase tudo, numa organizacao 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 questoes que sao essenciais de responder. [9]

1. O que deve ser incluido no ambito do BIA?

2. O que deve ser colocado de parte? Quer por nao fazer parte do ambito do BIA, quer por nao

representar um impacto significativo dentro do horizonte planeado.

3. Como combater a tendencia humana de considerar tudo o que fazemos como importante e dife-

renciar isso do que e realmente crıtico?

Para conseguir responder as duas primeiras perguntas e preciso ter um conhecimento do negocio,

pelo menos de um ponto de vista topo-baixo em termos do impacto que uma interrupcao no negocio

iria causar. Geralmente uma discussao com os stakeholders de maior peso ira produzir uma solucao

que seja de acordo com o a organizacao. [9]

Uma parte importante da analise e identificar onde e que uma atividade/processo que fica dentro do

ambito do BIA e dependente de uma atividade/processo que ficou posto de parte por nao se equadrar

no ambito previamente delineado. Este tipo de dependencias sendo quase inevitaveis constituı um bom

barometro para o BIA pois um BIA que nao revele surpresas destas quando feito pela primeira vez,

pode em grande parte dos casos significar que a analise nao teve rigor. Ao considerar o que deve

ou nao fazer parte do ambito nao se deve descurar o fato de um contınuo acumular de carga num

dado processo pode resultar se nao considerado numa surpresa bastante desagradavel na fase de

recuperacao. [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 pontuacoes que pontua e mede

17

as interrupcoes num dado processo em termos de perdas de receita, danos na reputacao, danos no

consumidor ou relacoes com parceiros, entre outros que possam ser relevantes no ambito do negocio

da organizacao. O desafio aparece em quase todas as tentativas de pontuar processo recorrendo a

esta alternativa e o fato de algumas ’medicoes’ serem muito difıceis de fazer, nestes caso a decisao

final cabera a gestao da organizacao que devera desenhar uma linha entra o importante e o crıtico. [9]

Existem diversos metodos para obter dados para o BIA, os mais utilizados sao [9]:

• Questionarios - Distribuir aos colaboradores responsaveis nas areas de negocio dentro do ambito

do BIA para que eles preencham;

• Questionarios - Para serem preenchidos de forma bi-lateral no ambito de reunioes ou entrevistas;

• Workshops ou mesas de discussao. (Esta abordagem pode ser util para obter uma visao mais

equilibrada da criticidade dos processos, no entanto ha o periodo de um colaborador senior por

exemplo force a sua opiniao no grupo.)

A forma ideal de fazer este passo pode passar por combinar os metodos acima referidos, comecar

numa accao de sensibilizacao para explicar e determinar de forma clara os conceitos do BIA, objetivos

e ambito, seguindo-se de um questionario inicial de simples preenchimento, neste questionario o ideal

e manter as coisas simples e nao perguntar mais do que “caso haja uma disrupcao no negocio e o seu

processo parar isso leva a um impacto negativo na organizacao?”. [9]

Esta abordagem so vai funcionar conforme esperado se obviamente a accao de sensibilizacao correr

conforme previsto e todos os participantes compreendam corretamente a mensagem. Neste ponto

do processo o BIA e extremamente dependente da interpretacao que e feita pelas pessoas. Uma

forma de ajudar na realizacao deste questionario e a priori realizar um programa de mapeamento dos

processos para identificar ativos e interdependencias. Desta forma consegue-se uma melhor imagem

da realidade do negocio o que ajuda a decidir a existencia ou nao de impactos, tambem se consegue

reduzir significativamente o risco de nao olhar para uma dependencia que possa ser crıtica. [9]

Algumas vantagens de utilizar um questionario inicial simples sao [9]:

• Identificar possıveis inconsistencias na afericao de criticidade;

• Identificar possıveis inconsistencias entre a discussao do ambito e o definido no passo 1;

• Eliminar processos/atividades nao crıticas do ambito do BIA;

Apos esta tarefa e necessario recolher ainda mais informacao e definir mais alguns conceitos, uma

vez que e preciso informacao com maior detalhe por parte do negocio, aqui aconselha-se a um ques-

tionario ou entrevista um pouco mais sofisticado para obter a informacao pretendida. A informacao que

se pretende agora obter e [9]:

1. Os requisitos temporais, MTPD e RTO;

2. Calendario dos processos;

18

3. Objetivo de recuperacao (RPO);

4. Dependencias dos processos;

5. Recursos necessarios para a recuperacao;

O RTO e o tempo de recuperacao, ou seja quanto tempo e que deve demorar a recuperar o pro-

cesso/negocio desde que houve o incidente. O RTO e um objetivo que a organizacao se deve propor

a alcancar, o que significa que muitas vezes nao se consegue cumprir e por isso existe outra medida

temporal o MTPD que define a janela temporal maxima que se pode estar com o processo/negocio

sem funcionar de todo. Ao definir estes tempos ha quem ter em consideracao o tempo para pensar, o

tempo para mobilizar recursos e o tempo para criar o ambiente proprio para recuperar do incidente. No

entanto ha que pensar corretamente nestes tempo, nomeadamente a nıvel da gestao porque quanto

mais depressa se tem de recuperar algo mais dinheiro se tem de gastar e cabe a gestao de topo fazer

esse trade-off. [9]

O ponto do calendario e muito especıfico, pode nao se aplicar em todas as organizacoes, 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 necessario no momento da recuperacao.

[9]

O RPO e outra variavel temporal, aqui define-se a quantidade de informacao que e preciso reter para

recuperar o processo/negocio. Pode haver negocios que suportem recuperar atraves de um backup de

ha 1 semana ou mais tempo, enquanto que ha negocio como por exemplo a banca onde os dados tem

de estar atualizados ao segundo. E e preciso ter esta consideracao quando se define o RPO do mesmo

modo que a semelhanca do RTO e MTPD quanto menos tempo mais dinheiro e preciso para cumprir

os objetivos. [9]

O ponto das dependencias caso ja se tenha feito o processo de mapeamento fica finalizado, no

entanto caso nao se tenha feito e neste momento obrigatorio proceder a esse levantamento de modo a

identificar tudo do qual cada processo depende, nunca esquecendo as dependencias entre processos

e sub-processos. [9]

Apos todas as definicoes anteriores e importante definir quais sao os recursos necessarios, quando

se fala de recursos fala-se de tudo o que e necessario, IT, locais, orcamento, colaboradores, todo o

tipo de ativos que a organizacao possa ter. Este ponto toma especial importancia para evitar duplas

contagens de recursos, por exemplo se 10 colaboradores sao precisos para recuperar o processo B

mas 4 ja foram destacados para o processo A entao apenas ha um incremento de 6 colaboradores. E

tambem importante identificar se e necessario algum tipo de fornecedor. [9]

19

2.3.5 BIA - Passo 3: Moderacao e Relatorio

Este passo 3 serve para fazer a moderacao dos resultados obtidos, das surpresas que possam ter

surgido e assegurar que tudo o que foi feito e razoavel. A experiencia tem mostrado que este passo e

muito importante uma vez que ajuda a garantir que a qualidade do BIA. [9]

A Moderacao e um processo de duas fases, em primeiro lugar ha que aferir a validade dos dados que

resultaram da recolha previamente realizada para a definicao dos requisitos operacionais. Em seguida

e necessario responder as implicacoes da informacao obtida, ou seja, responder de forma adequada

as diferencas entre os resultados obtidos e as capacidades de recuperacao reais da organizacao, a

resposta tera de ser razoavel uma vez que nem tudo podera ser alterado. Alguns metodo para fazer

esta moderacao sao [9]:

• Comparar o output BIAS anteriores, existe alguma razao valida para haver diferencas nos resul-

tados? Resulta de mudancas no negocio? Explicita apenas uma diferenca de opiniao por ser feito

por pessoas diferentes?

• Comparar o output obtido com o que se obteve em departamentos ou unidades de negocio si-

milares que ja tenham feito um processo similiar, desta forma tenta-se saber se os resultados

sao coerentes ou nao com processos semelhantes. Aqui ha que ter em conta especificidaes do

processo pois isso pode provocar uma discrepancia nos resultados o que nao significa que os

mesmos estejam errados.

• Recorrer a um consultor ou colaborador(es) senior, recorrendo a alguem ja com experiencia

consegue-se uma visao diferente que pode identificar erros na abordagem ou justificar discrepancias.

O relatorio final do BIA deve apresentar os requisitos operacionais, e importante reforcar que o

relatorio deve ser limitado ao objetivo do BIA, ou seja, nao se deve exigir que apresente uma estrategia

do que se deve fazer e como se deve fazer. Essa parte e responsabilidade de uma afericao de risco

posterior e do risk appetite da organizacao. O relatorio devera ser redigido de modo a fazer uma “prova

cabal”que satisfaca uma auditoria posterior, os principais temas a abordar neste relatorio sao [9]:

• Objetivo e ambito do BIA;

• Polıtica, definicoes que suportam o BIA;

• Descricao dos metodos usados para fazer o BIA;

• Explicacao do porque da validacao dos dados no passo da moderacao;

• Explicitacao clara dos resultados inconclusivos;

• Indicacao das consequencias da aceitacao ou nao dos resultados do BIA;

• Inclusao de resultados especıficos da analise.

20

Dependendo do tamanho da organizacao a revisao e melhoria do BIA podera ser feita com intervalos

de tempo diferentes, por norma em organizacoes pequenas e menos complexas o BIA devera ser revisto

anualmente ou quando ha mudancas significativas no negocio. No entanto e importante garantir que

no limite pelo menos a organizacao faz um BIA total a cada trienio. [9]

2.4 COBIT 5

O COBIT 5 fornece uma framework que auxilia as organizacoes a alcancar os seus objetivos em

termos de governance e gestao do IT empresarial. De certo modo pode-se afirmar que o COBIT 5 ajuda

a criar um valor otimizado para o IT, atraves da manutencao de um trade-off entre a concretizacao de

benefıcios e a optimizacao 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 organizacao, trazendo a si a totalidade do negocio e

todas as areas funcionais de IT com responsabilidades, aqui considera todos os interesses relacionados

com IT de stakeholders internos e externos. O COBIT 5 e generico e util a todo o tipo de organizacoes

quer em termos de tamanho, quer seja comercial, OSFL ou setor publico. [8]

Figura 2.4: Principios do COBIT 5. [8]

Conforme a figura 2.4 o COBIT 5 tem 5 princıpios chave para o governance e gestao de IT empre-

sarial [8]

• Princıpio 1: Ir de encontro as necessidades dos stakeholders - As organizacoes existem com o

objetivo de gerar valor para os seus stakeholders atraves da manutencao de um trade-off entre

a otimizacao de riscos, uso de recursos e a obtencao de benefıcios. O COBIT 5 fornece todo o

tipo de processos necessarios para suportar a criacao de valor no negocio atraves do uso das TI.

Devido ao fato de cada organizacao ter o seu proprio contexto e cultura o COBIT 5 e adaptavel a

cada realidade podendo ser configurado consoante as necessidades proprias de cada caso.

21

• Princıpio 2: Abrange a organizacao na sua totalidade - O COBIT 5 integra o governance de IT no

governance da organizacao:

– Cobre todos processos e atividades dentro da organizacao, nao se foca apenas no IT, re-

laciona sim a informacao e tecnologias como ativos que devem ser tratados como qualquer

outro ativo.

– Considera que o ambito de todo o governance e gestao relacionada com o IT e a toda a

organizacao, ponta a ponta, incluido tudo de todos, seja interno ou externo, desde que seja

relevante para a gestao da informacao e relacionado com o IT.

• Princıpio 3: Aplicar uma framework unica e integrada - Existem muitas normas e boas praticas

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 gestao de IT.

• Princıpio 4: Permitir uma aborgadem holıstica - Uma governance e gestao de IT eficiente e eficaz

requer uma abordagem holıstica, tendo em consideracao todas as componentes em interacao.

O COBIT 5 define um conjuto de facilitadores para suportar a implementacao de um sistema de

gestao e governance de IT compreensivo. Estes facilitadores podem ser definidos como qualquer

coisa que ajude a organizacao a alcancar os seus objetivos. O COBIT 5 define sete categorias de

facilitadores:

– Pincıpios, polıticas e frameworks;

– Processos;

– Estruturas organizacionais;

– Cultura, etica e comportamento;

– Informacao;

– Servicos, infraestrutura e aplicacoes;

– Pessoas, qualidades e competencia.

• Princıpio 5: Seprar governance da gestao - O COBIT 5 faz uma clara distincao entre a governance

e gestao. Estes dois termos englobam tipo de atividades diferentes, tendo requisitos diferentes

no que a estruturas organizacioanais necessarias diz respeito e de igual modo terem propositos

diferentes. A distincao feita pelo COBIT 5 e:

– Governance - Assegura que as necessidades dos stakeholders, condicoes e opcoes sao

avaliadas para determinar o melhor trade-off possıvel sob o qual os objetivos da organizacao

devem ser atingidos. Determina direcao a seguir atraves da tomada de decisao e priorizacao.

E tambem responsavel por monitorizar o desempenho e o cumprimento dos objetivos defini-

dos.

22

– Gestao - Planeia, constroi, executa e monitoriza atividades de acordo com a direcao definida

pela governance de modo a alcancar os objetivos da organizacao.

Como podemos ver pela figura 2.5 o COBIT 5 nao e prescritivo, aconselha sim a organizacao a

implementar os processos de governance e gestao de modo a que pelo menos as areas chave sejam

cobertas. Uma vez que cada organizacao tem uma realidade propria 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

areas chave fazem parte do ambito de aplicacao do COBIT 5. [8]

Na figura 2.6 podemos observar o modelo referencia de processos conjunto de governance e de

gestao que o COBIT 5 define e descreve em detalhe. Este conjunto representa o que em regra geral se

encontra numa organizacao relacionada com IT, deste modo fornece uma base comum e um modelo

de referencia compreensıvel que auxilia os gestores de negocio e operacionais de IT. Este modelo

proposto apesar de completo e compreensivo nao e o unico modelo possıvel, uma vez que se deve ter

em conta as especıficidades de cada organizacao. [8]

Incorporar um modelo operacional de linguagem comum a todas as partes da organizacao relacio-

nadas com o IT e um dos maiores desafios para uma governance de referencia. Como se observa na

figura 2.6 o modelo divide os processos da organizacao em duas grandes areas:

• Governance - Cinco processos, dentro de cada processo sao definidas praticas de avaliacao,

direcao e monitorizacao (EDM).

• Gestao - Tem 4 domınios em linha com areas de responsabilidade de planeamento, construcao,

execucao e monitorizacao (PBRM), e fornece uma cobertura ponta-a-ponta para o IT. Os nomes

dos domınios sao escolhidos em linha com a designacao destas areas principais:

– Alinhar, Planear e Organizar (APO);

– Construir, Adquirir e Implementar (BAI);

– Fornecer, Servico e Suporte (DSS);

– Monitorizar, Avaliar e Aferir (MEA).

Cada domınio tem um numero de processos, no entanto a maioria dos processos precisa de ati-

vidades de planeamento, implementacao, execucao e monitorizacao 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: Areas chave do COBIT 5 para governance e gestao. [8]

Figura 2.6: Processos do COBIT 5 para governance e gestao. [8]

24

Capıtulo 3

Analise do Problema

3.1 O Service Provider - Associacao DNS.PT

O service provider onde se realiza este trabalho e a associacao DNS.PT, que esta encarregue

da gestao e manutencao 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 independencia

do modelo, garantir a participacao de todos os atores (modelo multi-stakeholder), o papel ativo no

estado portugues e a autossustentacao.

O fato de ser uma associacao sem fins lucrativos vem dentro do que se pratica por parte da maioria

dos gestores de ccTLD, “dos 38 ccTLD´s analisados, 27 [...] sao entidades com natureza associativa e

sem fins lucrativos” 1. Todos os ccTLDs, independentemente do seu modelo organizacional, dimensao

ou estrutura, tem como base da sua atividade o RFC1591.2 Este documento tem como requisitos

fundamentais:

• Dever de servir a comunidade da Internet;

• Existencia de uma estrutura, com capacidades organizacionais e tecnicas para a reutilizacao

das responsabilidades necessarias na prossecucao de um trabalho equitativo, justo, honesto e

competente;

• Ser legıtima a sua funcao, por ter sido devidamente delegada e amplamente reconhecida pela

comunidade da Internet local.

Operando com base nestes princıpios, garante-se a existencia de uma estrutura associativa base-

ada no seu fim nao lucrativo, oferecendo os seus servicos em conformidade com as melhores praticas

internacionais.

Hoje em dia todo o mercado tecnologico e um mercado em crescendo onde a aposta em servicos

e virtualizacao tem vindo a ganhar cada vez mais peso. Estamos perante um mercado onde cada vez

1https://www.dns.pt/fotos/editor2/links/plano_de_atividades_2013-2016.pdf2https://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, servicos como o DNS estao e irao ganhar cada vez mais preponderancia

nas TI. No caso concreto do mercado onde opera a DNS.PT temos tres 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 numero possıvel de domınios, de preferencia a registrar’s, uma vez que desse modo esta

a estimular um mercado entre os mesmos para que estes oferecam o melhor servico possıvel,

sendo que sera o proprio mercado a fazer a filtragem e a eliminar quem nao 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 numero consideravel de domınios, para os

incorporar nos seus servicos fornecidos. Devido ao conhecimento tecnico que muitos registrar

retiram ao registry o onus de dar suporte tecnico 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 solucao

acaba por a prazo eliminar as mas praticas dos registrar. 4

Por ser permitido em Portugal que qualquer cidadao 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 as empresas que os revendem ao consumidor

final.

Nao obstante, toda esta componente de negocio que tem de ser gerida com o intuito de dar lucro. A

DNS.PT tem um cariz nao lucrativo assumindo um outro papel, com a seguinte missao: “A Associacao

DNS.PT [...], procurara orientar as suas linhas de accao em benefıcio de toda a comunidade Inter-

net portuguesa, dinamizando e incentivando a utilizacao generalizada. ”, e ainda objetivo da DNS.PT

promover o uso da Internet para a educacao, divulgando igualmente a cultura portuguesa. 1

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 negocio da DNS.PT, da capacidade

para gerir o domınio de topo, o ccTLD .pt. O relatorio desse processo esta disponıvel online.5 Existindo

esta evidencia, esta assegurado que a zona de domınios “.pt”consegue manter-se, isto e continua a

3https://www.icann.org/resources/pages/registries/registries-en4https://www.icann.org/resources/pages/registrars-0d-2012-02-25-en5http://www.iana.org/reports/2013/pt-report-20130808.html

26

ser possıvel aceder a domınios “.pt”caso haja disrupcao no servico. No entanto, apesar de existirem ja

estes mecanismos de resiliencia inerentes ao protocolo DNS e necessario que se crie uma formalizacao

de processos e mecanismos de modo a responder ao que ja existe no protocolo, cabe a DNS.PT,

exclusivamente, a gestao da zona de domınios “.pt”, assegurar a sua acessibilidade e atualizacao,

assim de como de todos os sistemas inerentes ao core do seu negocio. online

O impacto resultante desta zona, por algum motivo, deixar de estar acessıvel (muito pouco provavel)

ou atualizada, seria deveras negativo para o paıs, devido a crescente preponderancia da Internet, na

operacao das empresas.

3.2 Contexto do Problema

Este projeto surge no processo de certificacao da Associacao DNS.PT na norma ISO 27001, neste

processo foi exigido que existisse um Plano de Continuidade de Negocio de modo a assegurar a

seguranca da informacao mesmo em continuidade de negocio.

Foi por decisao do DNS.PT que se optou por seguir a norma referencia ISO 22301, nao havendo

qualquer obrigatoriedade por seguir esta norma, a decisao 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 realizacao do Plano de Continuidade de Negocio.

A norma ISO 22301 conforme ja analisado tem como ponto obrigatorio a existencia de um processo

de gestao de risco. Este processo de gestao de risco tem sempre de ter em conta a realidade do

negocio em si, por isso ha que ter em conta o papel fundamental que desempenha a seguranca da

informacao num negocio cujo business core assenta nas TI.

Desta situacao de conjugar estas duas realidades e criar um processo de gestao de risco que

consiga fazer esta mesma ligacao cada vez mais importante, surgiu a proposta para este projeto cujo

foco sera entao neste processo de gestao de risco que va de encontro aos requisitos da continuidade

de negocio e da seguranca da informacao.

3.3 Definicao do Problema

Para a realizacao deste projeto e entao proposto que se desenvolva um processo de gestao de risco

que de suporte a um plano de continuidade de negocio, objetivo final da DNS.PT. Deste modo, o pro-

blema a resolver e o de como desenvolver e implementar um processo de gestao de risco que suporte

um plano de continuidade de negocio, de acordo com a norma ISO 22301, dentro da DNS.PT. Tendo em

conta que a DNS.PT conta ja com uma certificacao ISO 9001 e ISO 27001, a ja implementacao destas

normas e um facilitador na resolucao do problema proposto uma vez que ja existem mecanismos de

afericao de risco para ativos e processos, feitos no ambito da certificacao na seguranca da informacao.

Nao sendo, por isso, necessario fazer tudo de raiz, podendo aproveitar-se o trabalho ja desenvolvido

pela DNS.PT na implementacao dessas duas normas.

Como se comprovou as normas ISO 27001, ISO 31000 e ISO 27005 estao relacionadas entre si.

27

A norma ISO 31000 define um processo de gestao do risco de modo generico, a ISO 27001 define

um sistema de gestao para seguranca da informacao e a ISO 27005 define um processo de gestao de

risco de acordo com a ISO 27001 seguindo a estrutura do processo de gestao de risco generico da ISO

31000.

Na perspetiva do que e proposto fazer, verificou-se que em primeiro lugar era intencao da DNS.PT

ter um plano de continuidade de negocio e que esse plano precisava de um processo de gestao de risco,

foi entao proposto como problema a resolver a criacao desse processo para o plano de continuidade

de negocio. A motivacao deste plano veio da certificacao ISO 27001 que a DNS.PT realizou e como

existe a norma ISO 27005 que define um processo de gestao de risco para a seguranca da informacao

pode-se concluir que o processo de gestao de risco a implementar como suporte a continuidade de

negocio podera ser implementar a norma ISO 27005 conseguindo deste modo uma total integracao

com a certificacao obtida.

Um ponto fundamental de um processo de gestao de risco e a tecnica de afericao de risco escolhida,

esta tecnica tem de ter em conta quer a realidade da organizacao, neste caso o DNS.PT, quer o ambito

do processo de gestao de risco. Deste modo a tecnica a escolher tem de se poder enquadrar na norma

ISO 27005 e na norma ISO 22301, como ambas as normas tem como referencia para a gestao de risco

a norma ISO 31000 e de especial relevancia usar uma tecnica que seja aplicavel segundo esta norma.

Deste modo o problema que se procura dar resposta e o de criar um processo de gestao de risco

que enquadre a continuidade de negocio e a seguranca da informacao usando uma tecnica de afericao

de risco adequada a esta realidade de ter que responder aos requisitos de 2 normas diferentes.

28

Capıtulo 4

Proposta de Solucao

A proposta de solucao desenvolvida e a criacao de um processo de gestao de risco que possa supor-

tar as necessidades das normas ISO 27001 de seguranca de informacao e ISO 22301 de continuidade

de negocio 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 sao:

• Estabelecer o Contexto;

• Afericao de Risco;

• Tratamento de Risco;

• Monitorizacao;

• Comunicacao.

Nas subseccoes seguintes irei fazer a descricao da minha proposta para cada um dos 5 processos

para este domınio especıfico. Comecarei por enunciar os objetivos de cada processo, seguido de

uma descricao do mesmo, no final de cada descricao encontra-se a minha proposta de diagrama. Os

diagramas propostos estao definidos na linguagem BPMN, em cada subseccao teremos o desenho

BPMN seguido de uma explicacao dos objetivos do processo e de uma tabela descritiva das atividades

do processo correspondente.

Por razoes de pragmatismos nos desenhos e para facilitar a interpretacao dos mesmos, foram re-

movidas prepositadamente as setas de comunicacao de mensagens trocadas entre atores do mesmo

processo. Nos 5 processos existem diversas interacoes com repositorios de informacao cujo conteudo

esta descrito na tabela 4.1.

29

Nome Repositorio Conteudo

BIA

- Stakeholders;

- Requisitos legais;

- Arquitetura tecnologica do negocio;

- Processos do negocio e suas dependencias;

- Metodos de afericao de risco e de impacto e criterio de risco;

- Impacto dos processos no negocio;

- Criticidade dos processos e tempos crıticos de recuperacao;

Registo de Riscos

- Riscos dos processos;

- Probabilidade de ocorrencia de cada risco;

- Impacto dos riscos no negocio;

- Nıvel de cada risco;

- Controlos associados a cada risco;

- Planos de tratamento de risco efetuados;

Monitorizacao - Relatorios de monitorizacao dos diversos processos;

Tabela 4.1: Repositorios de Informacao utilizados nos 5 processos.

4.1 Estabelecer Contexto

O processo de estabelecer contexto tem como objetivos:

• Definir os objetivos a atingir na Seguranca da Informacao e Continuidade e Negocio;

• Definir polıtica de Seguranca da Informacao e de Continuidade de Negocio;

• Estabelecer o contexto interno e externo da organizacao;

• Definir metodos de afericao de risco e de impacto dos processos do negocio.

E neste processo onde se faz a definicao do que se pretende atingir com a gestao de risco, e

deveras importante que se estabeleca um contexto correto e se definam metodos e criterios tao pre-

cisos quanto possıvel, tendo claro sempre presente as necessidades reais do negocio. Para facilitar a

correta execucao do processo se possıvel e recomendavel executar acoes de sensibilizacao do tema

aos diversos intervenientes, quer para que fiquem conscientes da importancia da sua participacao quer

para se comecaram a ambientar as terminologias usasdas neste domınio.

Neste processo e onde se define o negocio, identifica processos da organizacao, as suas de-

pendencias e relacoes, nas dependencias dos processos e necessario obter a arquitetura tecnologica

existente uma vez que esta e sempre parte vital nas organizacoes de hoje. E ainda preciso perceber

como e que os processos interagem com o negocio e vice-versa, isto e, se eu ficar sem o processo x

sera que o negocio consegue prosseguir normalmente? Se nao consegue qual o impacto e porque?

O processo y e altamente crıtico porque suporta a execucao dos n processos core do negocio, 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 informacoes uma vez que as implicacoes podem

colocar o negocio em perigo de nao continuar, bastanto classificar um processo que e altamente crıtico

com criticidade moderada devido a falta de informacao precisa e atual.

30

Este processo deve ser executado sempre que a gestao realizar mudancas na organizacao ou sem-

pre que o contexto interno ou externo mude, para alem das situacoes que possam ser detetadas no

processo de monitorizacao. O quadro resumo das atividades deste processo, que de seguida se des-

crevem, pode ser consultado na tabela 4.2 onde e tambem indicado o input e output de cada atividade.

No contexto externo e necessario perceber quais sao os fatores que podem afetar a organizacao de

modo a posteriormente poder fazer uma correcta afericao do risco. Estes fatores podem ser ambientais,

polıticos, regulatorios, financeiros/economicos, relacoes com stakeholders, key drivers e trends que

possam influenciar os objetivos da organizacao. No que respeita ao contexto interno sera necessario

avaliar qual a posicao da gestao do risco nos objetivos gerais da organizacao, normas e guidelines

adotados pela organizacao, cultura interna, sistemas de informacao existentes, stakeholders, entre

outros. Estes requisitos descritos e outros que se podem considerar na definicao do contexto interno e

externo podem ser consultados no ponto 5.3 da norma ISO 31000. [4]

Sera ainda necessario definir uma polıtica de seguranca da informacao e de continuidade de negocio

de acordo com os objetivos a atinguir nestas duas areas, nestas polıticas devera estar expresso o

risk appetite da organizacao para ambos os casos. Na definicao das dependencias cabe a cada res-

ponsavel de processo identificar os ativos que interveem no mesmo, assim como as relacoes que o seu

processo tem com outros processos, a arquitetura tecnologica e tambem definida neste ponto sendo

uma responsabilidade do responsavel sobre a area tecnica da organizacao. [4]

Uma vez obtido o conhecimento do funcionamento e das dependencias da organizacao cabe ao

responsavel pela SI e CN a definicao dos tempos crıticos (RTO, RPO, MTD) de cada processo e avaliar

segundo o metodo BIA ja definido qual e o impacto que cada processo tem no negocio e com isso

definir a criticidade de cada processo para a organizacao, todo este trabalho tera de ser aprovado pelo

responsavel do negocio. A modelacao deste processo pode ser vista na figura 4.1.

Figura 4.1: Processo de Estabelecer o Contexto.

31

Atividade Objetivo Input Output

Definir contexto

interno/externo

- Definicao de todos os fatores

internos/externos que podem influenciar

a organizacao;

- Definicao de objetivos para a gestao

de risco;

N/A

- Stakeholders;

- Requisitos Legais/Regulatorios;

- Fatores polıticos/ ambientais/

financeiros/ economicos;

- Key drivers e trends;

- Polıticas e normas internas

relevantes para o domınio;

- Polıtica e objetivos de seguranca da

informacao e continuidade de negocio;

Analisar

documentos

- Analisar para aprovar ou rejeitar

os documentos que definem o contexto

interno/externo da organizacao

- Stakeholders;

- Requisitos Legais/Regulatorios;

- Fatores polıticos/ ambientais/

financeiros/ economicos;

- Key drivers e trends;

- Polıticas e normas internas

relevantes para o domınio;

- Polıtica e objetivos de seguranca da

informacao e continuidade de negocio;

-Aprovacao ou rejeicao dos documentos;

Identificar processos

do negocio

- Criar uma lista com todos os processos

da organizacao que sao relevantes para o

negocio

N/A - Processos do negocio

Identificar dependencias

do negocio

- Identificacao de todos os ativos;

- Identificar relacao entre ativos e

processos;

- Identificar relacao entre processos;

- Identificar arquitectura tecnologica

do negocio;

- Processos do negocio

- Arquitetura de processos da

organizacao;

- Dependencias dos processos da

organizacao;

- Arquitetura tecnologica da

organizacao;

- Relacoes entre processos;

Agrupar dependencias- Consolidar informacao recebida

de cada responsavel no repositorio BIA;

- Arquitetura de processos da

organizacao;

- Dependencias dos processos

da organizacao;

- Arquitetura tecnologica da

organizacao;


N/A

Definir metodo BIA e

criterio de risco

- Definicao de um metodo BIA para

calculo do nıvel de risco e do impacto

dos processos no negocio;

- Definicao dos tempos crıticos de

recuperacao para cada processo;

- Definicao de um criterio de risco para

a organizacao;

- Arquitetura de processos

da organizacao;

- Dependencias dos processos

da organizacao;

- Arquitetura tecnologica

da organizacao;


- Criterio de risco;

- Metodo BIA;

- Tempos crıticos de recuperacao

dos processos;

Analisar BIA e criterio

de risco

- Analisar a proposta de BIA e de

criterio de risco para aprovar ou rejeitar;

- Criterio de risco;

- Metodo BIA;

- Tempos crıticos de recuperacao

dos processos;

- Aprovacao ou rejeicao

Tabela 4.2: Atividades executadas no processo de Estabelecer o Contexto.

32

4.2 Aferir o Risco

O processo de Afericao de Risco tem como objetivos:

• Identificar os riscos existentes para cada processo de negocio 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 negocio;

O quadro resumo das atividades deste processo, que de seguida se descrevem, pode ser consultado

na tabela 4.3 onde e tambem indicado o input e output de cada atividade.

No processo de afericao de risco e se vai aplicar tudo o que se definiu no contexto, aqui comeca-

se por identificar todos os riscos que estejam dentro do domınio e do ambito pretendidos, e muito

importante nao 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 existencia de um repositorio onde esteja armazenada

toda a informacao relacionada com os riscos que identificamos no nosso negocio, e desta necessidade

que se cria ou reve caso ja exista um registo de risco, sendo que na revisao se deve remover todos os

riscos obsoletos. O registo de risco e um elemento crıtico para o processo de gestao de risco pois e

nele que vamos armezar toda a informacao encontrada e todo o trabalho produzido relativo aos riscos

que estao dentro do domınio do problema.

E tambem 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 analise 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

consequencia qual o impacto que isso vai trazer ao negocio. Para alem do impacto e importante tambem

perceber qual e a frequencia e/ou a probabilidade de ocorrencia que esse risco tem durante um perıodo

de tempo (aqui fica ao criterio da organizacao qual o espaco temporal mais plausıvel a considerar se

um ano, mes, semana, dia).

Apos avaliar cada risco e preciso entao atribuir um nıvel de risco, para tal existem diversas tecnicas

que podem ser consultadas na norma ISO 31010 sendo que a sua aplicacao deve ter em conta a rea-

lidade da organizacao e os objetivos a atingir, tendo em consideracao que o objetivo deste processo e

juntar a seguranca da informacao com a continuidade de negocio, a tecnica proposta e a realizacao de

um metodo BIA, este metodo pode basear o nıvel de risco em diversos indicadores consoante as neces-

sidades de cada situacao, ver anexo A com exemplo ilustrativo de um BIA, neste caso concreto, como

temos de lidar com a continuidade de negocio e seguranca da informacao os indicadores aconselhados

sao de impacto do risco no processo, probabilidade de ocorrencia do risco e impacto do processo no

negocio. Estes indicadores podem caso se pretenda ser poderados e/ou normalizados, nao existindo

nenhuma regra definida fica ao criterio de cada responsavel por esta area ver qual e a situacao que me-

lhor se adequa quer ao negocio quer aos objetivos da gestao para a gestao de risco. Este e o metodo

33

escolhido por ser algo mandatorio na continuidade de negocio e que se adequa as necessidades de

seguranca da informacao. [1] [6]

A modelacao deste processo pode ser vista na figura 4.2.

Figura 4.2: Processo de Afericao de Risco


Criar/Rever registo

de riscos

- Identificar riscos de cada processo;

- Identificar controlos existentes;

- Associar controlos a riscos

identificados;

- Remover riscos obsoletos;

N/A - Registo de riscos

Agrupar alteracoes no

registo de riscos

- Receber dos responsaveis dos

processos alteracoes ao registo de riscos

- Riscos dos processos;

- Controlos dos processos;

- Riscos obsoletos;

- Registo de Riscos

Analisar registo de

riscos

- Analisar se registo de riscos responde

as necessidades da organizacao- Registo de riscos

- Aprovacao/Rejeicao do

registo de riscos proposto

Analisar riscos

- Identificacao da probalidade/frequencia

de ocorrencia de cada risco;

- Impactos do risco no processo/negocio;

- Registo de riscos

- Probabilidade/Frequencia de

ocorrencia de cada risco;

- Impacto do risco no negocio;

Aferir nıveis de risco- Calcular o nıvel de risco com base nos

indicadores escolhidos;

- Probabilidade/Frequencia de

ocorrencia de cada risco;

- Impacto do risco no negocio;

- Nıveis de risco;

Analisar nıveis de risco

- Analisar os nıveis de risco para

perceber se correspondem a realidade

do negocio;

- Nıveis de risco- Aprovacao/Rejeicao dos

nıveis de risco

Tabela 4.3: Atividades executadas no processo de Afericao de Risco.

34

4.3 Tratamento de Risco

O processo de Tratamento de Risco tem como objetivos:

• Definicao de controlos para os riscos identificados;

• Atualizacao dos controlos existentes;

• Mitigacao do nıvel de risco nos processos mais crıticos para um nıvel aceitavel;

O quadro resumo das atividades deste processo, que de seguida se descrevem, pode ser consultado

na tabela 4.4 onde e tambem 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 afericao de risco e preparar um plano de tratamento de risco. Este plano consiste num

conjunto de controlos, novos ou atualizacoes a controlos existentes, que sao delineados para reduzir o

nıvel de risco do processo ao qual sao relacionados. Nao 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 mitigacao.

Uma vez elaborado o plano de tratamento de risco este deve ser revisto em conjunto com os res-

ponsaveis de cada processo de modo a se poder acrescentar novos controlos a proposta ou a remo-

ver controlos que a partida ja representem uma reducao do nıvel de risco, todas estas propostas de

remocao e acrescento devem ser documentadas no registo de riscos (indicar que o controlo e obsoleto

ou acrescentar outros). Apos a obtencao de uma versao final para submeter a aprovacao do res-

ponsavel do negocio e preciso calcular quanto vai custar implementar cada controlo, esta atividade e

especialmente importante porque vai acabar por ter um impacto direto na decisao final do responsavel

de negocio 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 responsavel do

negocio poder decidir o maximo de conforto possıvel. Uma vez estimados os custos o responsavel

pela seguranca da informacao e continuidade de negocio deve priorizar os controlos de modo a que a

gestao consiga perceber quais sao os mais urgentes a implementar.

Assim que recebe o plano de tratamento de riscos para aprovar o responsavel do negocio deve

decidir consoante os objetivos a atingir pela organizacao quais os controlos que sao obrigatorios de

implementar, os que a organizacao suporta implementar e quais os que podem nao ser implementados

pelo custo ser superior ao ganho efetivo (se o nıvel de risco estiver ja abaixo do aceitavel ou muito

proximo do limite, podera nao se justificar o custo para a realidade da organizacao). Ao decidir ira

escolher os controlos a aplicar e notificar o responsavel pela SI e CN dos controlos selecionados para

aplicacao explicando as exclusoes. A responsabilidade de aplicacao dos controlos e depois dos donos

dos processos. Os controlos a aplicar devem ter como objetivo uma reducao do nıvel de risco, quer

seja pela reducao de probabilidade de ocorrencia, remocao da fonte de risco, reducao 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 alteracao em relacao ao definido na norma ISO 31000, ver figura 2.2, onde apos se definir os con-

35

trolos se deve analisar se estes surtiram o efeito desejado ou nao de modo a de imediato poder redefinir

os mesmos ou acrescentar outros, esta alteracao embora nao expressa diretamente no desenho deste

sub-processo e tambem considerada na arquitetura de processos utilizada para o processso de gestao

de risco neste caso. Por ser uma aplicacao desta arquitetura pode-se utilizar essa alteracao para este

caso e permitir que assim o responsavel do negocio possa rejeitar o plano de tratamento de risco e que

o plano de tratamento de risco seja imediatamente revisto para nova submissao.E iniciar o processo de

monitorizacao para perceber se os controlos surtiram ou nao o efeito desejado. [4] [7]

A modelacao deste processo pode ser vista na figura 4.3.

Figura 4.3: Processo de Tratamento de Risco


Elaborar plano de tratamento

de riscos

- Definir controlos para os riscos

identificados;- Registo de riscos - Plano de tratamento de riscos

Receber e analisar modificacoes

ao plano

- Receber e analisar as alteracoes

propostas ao plano de tratamento de riscos- Plano de tratamento de riscos - Plano de tratamento de riscos

Calcular custos dos controlos- Calcular custo de implementacao dos

controlos propostos- Plano de tratamento de riscos - Custo dos controlos propostos

Priorizar controlos - Priorizar os controlos propostos - Plano de tratamento de riscos- Controlos ordenados por

criticidade

Analisar plano de tratamento

de risco

- Analisar o plano de tratamento de

riscos para aprovacao- Plano de tratamento de riscos

- Aprovacao/Rejeicao do plano

de tratamento de riscos

Decidir tipo de implementacao- Perceber qual o tipo de implementacao

possıvel- Plano de tratamento de riscos

- Decisao sobre o tipo de

implementacao

Implementar plano- Implementar todo o plano de

tratamento de riscos- Plano de tratamento de riscos - Implementacao de todo o plano

Escolha dos controlos a aplicar - Selecionar alguns controlos para aplicar - Plano de tratamento de riscos - Aplicacao dos controlos escolhidos

Implementar plano de tratamento

de riscos

- Comunicar para implementar

todos os controlos propostos- Plano de tratamento de riscos

- Ordem de implementacao

dos controlos

Implementar controlos selecionados- Comunicar para implementar

os controlos selecionados- Lista de controlos selecionados

- Ordem de implementacao dos

controlos selecionados

Tabela 4.4: Atividades executadas no processo de Tratamento de Risco.

36

4.4 Monitorizacao

Tendo por base o ponto 9.3 da norma ISO 22301 e ISO 27001 percebe-se que e necessario mo-

nitorizar e rever de forma periodica quer o sistema de seguranca da informacao, quer o sistema de

continuidade de negocio, o que implica monitorizar e rever a base de ambos os sistemas que e o pro-

cesso de gestao 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 aconselhavel existir uma monitorizacao e

revisao periodicas ou ad hoc do processo de gestao de risco, o tempo que dista entre duas revisoes ou

atividades de monitorizacao esta dependente da gestao que deve sempre ter em consideracao tanto

o contexto interno, como externo do negocio da organizacao. A Arquitetura de processos por ser a

proposta da norma ISO 31000 respeita esta necessidade ao permitir a execucao a qualquer altura

da monitorizacao e revisao, conseguindo assim a melhoria contınua do sistema, pois e possıvel estar

sempre a monitorizar de modo a depois introduzir alteracoes para melhorar o processo.

Conforme referido o processo de monitorizacao 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 afericao do risco e no tratamento do risco.

Verificar se houve alteracoes no contexto da organizacao, ou novos riscos surgiram e se os controlos

foram ou nao eficazes. [4]

Para alcancar estes objetivos dividi o processo de monitorizacao e revisao em 3 sub-processos,

monitorizacao do processo de estabelecer o contexto, monitorizacao do processo da afericao de risco

e monitorizacao 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 gestao de risco:

Estabelecer Contexto, Afericao 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 apos a primeira definicao de contexto e possıvel caso a organizacao assim o

entenda monitorizar o mesmo, sendo a mesma logica aplicada aos restantes processos. Uma vez que

cada negocio tem caracterısticas especıficas que influenciam todo o processo de gestao de risco, fica

ao criterio da organizacao a frequencia e o momento de efetuar a monitorizacao e revisao, ao estar a

pre-estabelecer uma frequencia ou um momento do ano estaria certamente a ignorar as especificida-

des de muitos negocios que poderiam adoptar este processo. Alem disto se olharmos para a norma

ISO 31000 tambem nao encontramos nenhuma definicao concreta de quando e com que frequencia

realizar a monitorizacao, 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 ambito da gestao de risco fazer

uma revisao/monitorizacao, sendo ela periodica ou ad hoc nao e problema de maior uma vez que e

dependente do negocio. [4]

37

4.4.1 Monitorizacao de Estabelecer o Contexto

Na monitorizacao do contexto o principal objetivo passa por perceber se o contexto da organizacao

foi sujeito a alteracoes, ou seja, e preciso perceber se houve uma mudanca de objetivos e se as polıticas

definidas ainda fazem sentido na organizacao, se os metodos de afericao de risco e impacto ainda

servem os objetivos da organizacao, se houve mudancas no contexto externo que possam influenciar o

nıvel de risco e o impacto dos processos como mudancas socio-economicas no mercado, mudancas no

regulador (se aplicavel), entrada/saıda de stakeholders, a nıvel do contexto interno poderao ser fatores

como uma mudanca tecnologica nos sistemas da organizacao ou uma alteracao da arquitetura ou ate

uma mudanca nos processos de negocio de como eles interagem entre si.

Neste processo e muito importante saber fazer uma avaliacao cuidada dos documentos produzidos

e da realidade atual para perceber se houve alteracoes e se estas alteracoes podem significar novos

riscos ou modificacao do nıvel de risco ou o desaparecimento de riscos existentes, uma vez que estas

implicacoes representam um impacto significativo no negocio.

A modelacao deste processo pode ser vista na figura 4.4 e o quadro resumo das atividades deste

processo, descritas nesta secao, pode ser consultado na tabela 4.5 onde e tambem indicado o input e

output de cada atividade.

Figura 4.4: Processo de Monitorizacao do Contexto do Negocio


Rever contexto interno/externo

- Rever aplicabilidade dos documentos

produzidos na atividade ”Definir contexto

interno/externo”do processo de

estabelecer contexto

- Repositorio BIA - N/A

Rever Arquitetura tecnologica- Rever toda a arquitetura tecnologica

para encontrar alteracoes- N/A - N/A

Rever dependencias dos processos- Rever todas as dependencias/

relacoes dos processos de negocio- N/A - N/A

Produzir relatorio

- Escrever um relatorio com a indicacao

do trabalho realizado e se e preciso

proceder a alguma alteracao

- Alteracoes contexto interno/externo;

- Alteracoes Arq. Tecnologica;

- Alteracoes nas dependencias dos

processos;

- Relatorio de monitorizacao do

contexto

Tabela 4.5: Atividades executadas no processo de Monitorizacao do Estabelecer Contexto.

38

4.4.2 Monitorizacao da Afericao de Risco

Para monitorizar a afericao de risco tem de se ter em conta o contexto, uma vez que esta depende

dele, e normal a alteracao de uma ou mais condicoes no contexto provocar uma mudanca na analise

dos riscos, no entanto pode perfeitamente acontecer que seja atribuıdo a um risco uma frequencia,

probabilidade ou impacto que nao correspondem a realidade, quer seja em defeito ou por excesso, o

facto de estas situacoes poderem ocorrer torna fundamental a existencia de um processo que monito-

riza e reve as avalicoes dos riscos e os nıveis de risco atribuıdos. Caso seja detetada uma qualquer

modificacao quer seja uma mudanca ao contexto, quer apenas no nıvel de risco tera de se forcosamente

rever o registo de riscos para perceber se ha alguns novos a considerar, ou outros que ja nao fazem

parte do contexto ou se os nıveis de risco ainda fazem sentido no novo contexto ou nova avaliacao.

E norma nas empresas que implementam sistemas como o da norma ISO 27001 fazer-se uma

revisao periodica dos riscos e da sua avaliacao, para esse efeito deixaria de ser necessario re-executar

o processo de afericao 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 modelacao

deste processo pode ser vista na figura 4.5 e o quadro resumo das atividades do mesmo, descritas

nesta secao, pode ser consultado na tabela 4.6 onde e tambem indicado o input e output de cada

atividade.

Figura 4.5: Processo de Monitorizacao da Afericao de Risco


Rever registo de riscos- Rever existencia dos riscos e controlos

existentes- Registo de riscos - N/A

Analisar riscos

- Rever riscos identificados e analisar

a manutencao da probabilidade/frequencia

de ocorrencia e do impacto

- N/A - N/A

Conferir nıveis de risco- Rever nıveis de risco para identificar

a necessidade de possıveis alteracoes- N/A - N/A

Produzir relatorio

- Escrever um relatorio com a indicacao



- Alteracoes na existencia de riscos e

controlos;

- Alteracoes da frequencia/prob. de

um dado risco;

- Alteracoes no impacto de um dado

risco;

- Alteracoes no nıvel de um dado risco

- Relatorio de monitorizacao

da afericao de risco

Tabela 4.6: Atividades executadas no processo de Monitorizacao da Afericao de Risco.

39

4.4.3 Monitorizacao 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 negocio 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 reducao possıvel dos nıveis de risco, isto

porque sempre que se detetam controlos ineficazes deve-se anotar isso no relatorio de monitorizacao,

para que a deficiencia seja corrigida na elaboracao do proximo 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 recomendavel e rever o contexto e a afericao de risco

para perceber se e uma questao de adicionar mais controlos ao plano de tratamento de riscos ou se

e necessario um recomeco a partir da definicao do contexto ou da afericao de risco, este processo

conforme ja abordado pode ser realizado logo apos a implementacao dos controlos e, por isso, respeita

a execucao da arquitetura de processos da norma ISO 27005.




Figura 4.6: Processo de Monitorizacao do Tratamento de Riscos


Conferir aplicacao dos controlos- Conferir se todos os controlos selecionados

foram corretamente aplicados- Registo de riscos - N/A

Avaliar a eficacia dos controlos- Avaliar se os controlos aplicados surtiram

o efeito desejado- N/A - N/A

Produzir relatorio

Escrever um relatorio com a indicacao



- N/A- Relatorio da monitorizacao

do plano de tratamento dos riscos

Tabela 4.7: Atividades executadas no processo de Monitorizacao do Plano de Tratamento de Riscos.

40

4.5 Comunicacao

O processo de comunicacao e consulta tem como objetivo definir como realizar a comunicacao com

os diversos stakeholders relevantes para o processo de gestao de risco, para se poder comunicar o tra-

balho realizado e receber um possıvel input dado pelos stakeholders que a gestao e/ou o responsavel

da seguranca da informacao considere pertinente para melhorar o processo de gestao de risco. Para

alem da importante componente de ir ao encontro dos objetivos dos stakeholders e necessario, por

vezes, obter da parte dos mesmos um qualquer input sobre o trabalho desenvolvido nao numa otica

do dar conhecimento mas sim na otica de uma consultoria sobre esse tema, nesta situacao o sta-

keholder funciona como consultor e ajuda a organizacao a realizar o trabalho de modo a responder as

suas preocupacoes. Nem sempre as recomendacoes dos stakeholders sao possıveis de implementar,

pois o seu racio custo-benefıcio pode ser baixo. Para perceber se uma recomendacao e possıvel de

aplicar deve haver a concordancia entre o responsavel do negocio e o responsavel pela seguranca da

informacao e continuidade de negocio, 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 Comunicacao e Consulta


Comunicar aos stakeholders

o trabalho desenvolvido

- Comunicar o trabalho feito no ambito 4

processos restantes que compoem a

arquitetura

- Repositorio BIA;

- Registo de riscos;

- Monitorizacao;

- N/A

Recolher feedback

- Receber o feedback dos stakeholders;

- Perceber se ha ou nao recomendacoes

para proceder a alguma alteracao no

trabalho apresentado;

- Feedback/Nao feedback - N/A

Ponderar que recomendacoes

aplicar

- Ponderar quais sao as alteracoes que se

justificam realizar e quais sao as que sao

possıveis de executar

- Recomendacoes dos

stakeholders- Recomendacoes a aplicar

Aplicar recomendacoes

escolhidas- Aplicar as recomendacoes selecionadas - Recomendacoes a aplicar - N/A

Tabela 4.8: Atividades executadas no processo de Comunicacao e Consulta.

41

4.6 Processo de Gestao de Risco no COBIT 5

Com estes desenhos e as propriedades referidas a proposta de solucao corresponde a totalidade

dos processos de gestao 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

seguranca da informacao com a continuidade de negocio. No entanto sera igualmente interessante per-

ceber como se pode aplicar este processo de gestao de risco numa framework muito usual no mundo

empresarial de IT nos dias de hoje, o COBIT 5 dando assim sentido a solucao proposta.

Conforme analisado, o COBIT 5 permite que a informacao e tecnologia associada sejam geridas de

forma holıstica para a organizacao como um todo, ao ter principios facilitadores e genericos que podem

ser aplicados a toda e qualquer organizacao. 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 as organizacoes 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 sao precisos para suportar a gestao 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 ligacao entre a gestao de risco e o COBIT 5, de tal modo que todos

os processos servem de suporte a gestao do risco. No entanto, e importante perceber entao como e

que se pode usar o COBIT 5 para responder as normas ISO 22301 e 27001. Analisando a figura 4.8

ve-se que o COBIT 5 responde as 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 gestao de risco proposto a uma organizacao 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 negocio, 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 ocorrencia

de incidentes e problemas que possam provocar a disrupcao do negocio assegurando sempre a con-

tinuidade do mesmo. Conseguindo fazer esta ligacao ao nıvel dos objetivos, pode-se tambem olhar a

gestao de risco, essencial a continuidade de negocio, 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 negocio como se pode ver pela figura 4.8. A semelhanca da seguranca da

informacao tambem a continuidade de negocio tem necessidade de monitorizacao e revisao periodicas,

42

no entanto esta necessidade e tambem contemplada no COBIT5 pelos processos do domınio MEA, o

mesmo sucedendo as 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 gestao de risco a uma

organizacao que use a framework de referencia COBIT conseguindo assim interligar a seguranca da

informacao com a continuidade de negocio.

Figura 4.8: Ligacao do COBIT 5 a outras normas e frameworks. [10]

Figura 4.9: Processos COBIT 5 para gerir o risco. [10]

43

Capıtulo 5

Conclusoes e Trabalho Futuro

5.1 Objetivos e Desafios Iniciais

No ambito da realizacao do trabalho realizado para o DNS.PT tive a oportunidade de ler e analisar a

norma referencia ISO 22301, apos analise da norma foi-me bastante clara a necessidade da existencia

de um processo de gestao de risco, uma vez que e sobre o mesmo que se desenvolve todo o trabalho

de continuidade de negocio. No entanto, antes de poder partir para a concretizacao de uma proposta

de um plano de continuidade de negocio foi necessario 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 Negocio;

• Produzir um Processo de Gestao de Risco;

• Integrar o trabalho desenvolvido na cultura e processos do DNS.PT;

• Obter a aprovacao por parte da gestao 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 negocio;

• Perceber a cultura do DNS.PT;

• Adaptar o Plano de Continuidade de Negocio e a sua Gestao do Risco a cultura do DNS.PT;

• Integrar a continuidade de negocio de um modo formal na cultura do DNS.PT;

• Como utilizar o trabalho desenvolvido nas normas ISO em que o DNS.PT ja obteve certificacao;

44

Para conseguir perceber melhor o contexto do negocio tive de pesquisar relativamente ao tema

de continuidade de negocio e seguranca da informacao, ao mesmo tempo aproveitava o tempo em

escritorio para realizar pequenas entrevistas aos colaboradores do DNS.PT de modo a poder obter a

informacao de quem esta por dentro do negocio e assim perceber melhor a cultura da organizacao.

Os inputs acabaram por me aproximar mais da realidade efetiva do que e o negocio e permitiram-me

conceber a minha ideia de como e o negocio e como abordar o mesmo na perspetiva da continuidade

de negocio e seguranca da informacao.

Uma vez que, aquando da minha chegada ao DNS.PT ja existia implementado um processo de

gestao de risco para a seguranca da informacao de acordo com os requisitos da norma ISO 27001,

era claro que teria de aproveitar todo o trabalho realizado pelo DNS.PT nesse mesmo ambito para

a concretizacao 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 negocio

estaria a evitar a duplicacao de documentos e a manter-me dentro daquilo que e a cultura do DNS.PT

no que respeita aos seus processos.

Foi relativamente facil a introducao do tema da continuidade de negocio na cultura da organizacao,

principalmente a nıvel da gestao de risco, uma vez que todos os colaboradores tinham sido previamente

sensibilizados, sendo-lhes explicada a importancia deste tema para o DNS.PT, mesmo ja existindo

processos inerentes a tecnologia utilizada que garantissem a continuidade de negocio nao existia a

data uma formalizacao de um plano de como assegurar essa continuidade.

5.2 Processo de Gestao de Risco

Conforme referido o DNS.PT ja estava dotado de um processo de gestao risco, no entanto esse

mesmo processo encontrava-se exclusivamente focado nas necessidades da seguranca da informacao

e seria necessario introduzir neste processo as necessidades da continuidade de negocio.

O primeiro passo foi rever o contexto, era necessario identificar se seria preciso proceder a alteracoes

do mesmo, uma vez que se ia introduzir uma variavel nova. Foi necessario criar uma polıtica de con-

tinuidade de negocio, identificar stakeholders, que requisitos legais teriam de ser respondidos, obter a

arquitetura do sistema e criar um metodo BIA para ser aplicado aos processos de negocio.

Uma vez que estava a ocorrer ao mesmo tempo uma revisao dos processos de negocio devido a

renovacao da certificacao da norma ISO 9001, esse trabalho nao foi realizado neste ambito, assim

como a identificacao dos requisitos legais ficou atribuıda a equipa da area juridica.

Para a criacao da polıtica de continuidade de negocio o que se fez foi aproveitar a polıtica de

seguranca de informacao vigente e introduzir na mesma as preocupacoes relativas a continuidade

de negocio criando assim um unico 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 negocio e a seguranca da informacao, implementando

medidas que assegurem a resiliencia do DNS.PT a adversidade. Permitindo, assim, a recuperacao

das atividades crıticas da organizacao num intervalo de tempo aceitavel, minimizando desta forma as

45

consequencias de incidentes para os seus stakeholders. O DNS.PT compromete-se assim a manter o

Plano de Continuidade de Negocio documentado, atualizado e testado com regularidade.”.1

Criada a polıtica era preciso proceder a definicao do BIA. Para definir o BIA recorri a norma ISO

31010 [6], aos modelos exemplo como o do anexo A e as recomendacoes 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 sao os objetivos que

pretendemos alcancar 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 negocio e a criticidade da sua recuperacao.

• Identificacao dos processos de negocio e qual o impacto que uma disrupcao do processo pode

ter no negocio. O tempo de indisponibilidade deve refletir o maximo que o DNS.PT pode tolerar

de modo a poder continuar a fornecer os seus servicos;

• Identificar prioridades de recuperacao 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 necessario ter presente uma linha condutora foi na definicao 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 recuperacao RTO, RPO e MTD, especıficos de cada processo, definem a criticidade de um

dado processo.

Esta definicao da criticidade e do impacto que os processos tem no negocio, para alem da im-

portancia que tem para a elaboracao de um plano de continuidade de negocio, onde e fulcral saber

priorizar as tarefas de recuperacao, tem extrema importancia para o processo de gestao de risco pois

vai influenciar o nıvel de risco dos ativos que sao 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 negocio e objetivos da organizacao.

Apos a concepcao dos modelos, a definicao das polıticas e do BIA seguiu-se a obtencao da arqui-

tetura do negocio. Nesta tarefa e importante perceber do que depende cada processo e que relacoes

existem entre processos. Deste modo aproveitando o levantamento de ativos feito para a certificacao

da norma ISO 27001 foi feita uma revisao para identificar novos ativos e eliminar ativos que ja nao

existiam e em colaboracao com o departamento tecnico procedeu-se a elaboracao da arquitetura do

negocio, identificando as dependencias entre processos, sistemas de informacao e ativos. Nao sera

aqui mostrado em anexo o que resultou do levantamento devido a questoes de confidencialidade.

Por fim, recorreu-se ao metodo BIA, previamente definido, e procedeu-se a identificacao dos pro-

cessos crıticos e dos impactos que estes tem no negocio, para tal atribuiu-se um nıvel de impacto de

1-5 em cada area a considerar para cada processo, atribuiu-se um tempo crıtico de recuperacao, tendo

1https://www.dns.pt/pt/

46

sempre presente as relacoes de dependencia com outros processos e, combinando todas estas verten-

tes calculou-se um nıvel de criticidade para cada processo do negocio. A semelhanca do levantamento

da infraestrutura tambem o resultado do BIA nao pode ser divulgado uma vez que trata informacao

confidencial que, a partida, nem sequer e divulgada a toda a associacao.

Para conseguir fazer estes calculos e estas atribuicoes foram realizadas reunioes com os res-

ponsaveis dos processos e com o responsavel pelo negocio para que estes atribuıssem os tempos

crıticos e os impactos respetivos a cada processo, era no entanto necessario evitar que todos os pro-

cessos fossem considerados de extrema importancia, para que tal nao acontecesse foi necessario

proceder a uma previa explicacao sobre os objetivos a atingir e, posteriormente, colocar questoes que

obrigassem a focar o essencial, como por exemplo:

• E possıvel realizar o processo sem este servico/sistema?

• Quanto tempo o DNS.PT aguenta no limite sem este processo numa situacao de crise?

• Admitindo que ficava sem o sistema x, conseguia executar o seu processo?

Ao colocar questoes como as expostas conseguiu-se um maior entendimento por parte dos res-

ponsaveis dos processos do objetivo que se pretendia atingir. Apos ter fechado a questao da definicao

das criticidades dos processos entrou-se na fase da afericao de risco.

Como o DNS.PT tinha ja estruturado um processo de gestao de risco para a seguranca da informacao

assim como a certificacao ISO 27001, estava calendarizada a partida uma revisao dos riscos e uma

reafericao dos mesmos no ambito desta certificacao, deste modo e aproveitando que se estava a rever

o registo de riscos foram introduzidos riscos relativos a continuidade de negocio e alargou-se o espectro

de analise dos riscos existente para considerar tambem os impactos da continuidade de negocio para

alem da seguranca da informacao que ja era analisada.

Como o DNS.PT baseia o core do seu negocio na tecnologia do protoloco DNS.PT e opera na

area de jurisdicao da IANA que recomenda os gestores de domınios de topo a implementarem alguns

mecanismos de seguranca segundo as boas praticas internacionais, ja existiam a priori mecanismos

que garantiam a continuidade do negocio e, desse modo, apesar de se ter alargado o ambito a analise

de risco, nao houve alteracoes para alem do limite considerado pelo DNS.PT como aceitavel no nıvel de

risco. Isto provocou que nao 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 revisao dos controlos existentes e

tentar otimizar os que ja existem. Toda a informacao relativa a riscos, controlos e analises dos mesmos

e tambem considerada como confidencial e, como tal, nao 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 negocio foi necessario iden-

tificar os requisitos legais para evacuacoes e situacoes de catastofre com a protecao civil, durante a

pesquisa da legislacao percebeu-se que existia em Portugal uma lista de infraestruturas crıticas para

o paıs. Apos o conhecimento deste enquadramento foi do interesse do DNS.PT que se elaborasse

uma exposicao para enviar a proteccao civil 2 3 para que o DNS.PT pudesse passar a ser considerado

como infraestrutura crıtica, a base da exposicao enviada pode ser consultada no anexo C. Neste anexo

podemos ver que o argumento maior utilizado e:

“Manutencao de funcoes vitais para a sociedade o bem-estar economico ou social, e cuja perturbacao

ou destruicao teria um impacto significativo, dada a impossibilidade de continuar a assegurar essas

funcoes”. Este dois criterios sao evocados porque tendo em conta que, hoje em dia a Internet desem-

penha um papel central na vida da sociedade, principalmente em termos de negocio e economia, um

provedor de servicos 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 paralisacao poderia levar

a um impacto muito severo na economia e sociedade portuguesa, (transcricao do anexo C).

Apos conseguir a definicao como uma das infraestruturas crıticas do paıs foi considerado que os

processos crıticos do DNS.PT seriam aqueles que envolvessem a disponibilizacao dos domınios e

classificou-se a associacao como um operador de telecomunicacoes, esta classificacao nao foi do

agrado da gestao por nao corresponder ao que realmente e o core do negocio do DNS.PT, uma vez que

a protecao civil tinha deixado a classificacao aberta a uma sugestao por parte da associacao, tratou-se

de procurar qual seria a classificacao mais adequada ao DNS.PT tendo em conta o seu negocio.

Uma das coisas que esteve sempre presente e que independentemente da area encontrada o modo

de funcionamento do DNS.PT era, e e, o de um service provider. Aqui podemos ler a transcricao da

proposta final de definicao: ”O DNS.PT usa por base o protocolo DNS no core do negocio e conforme

analisado o ambito deste protocolo pode-se considerar o ciberespaco. O enquadramento que esta

analise sugere ser possıvel para o DNS.PT e o de um provedor de servicos no ciberespaco.”. Todo o

documento com a elaboracao da proposta pode ser consultado no anexo D.

Esta proposta e inovadora e vem abrir um vazio que existe na classificacao da protecao civil onde

nao estao contemplados os modelos de funcionamento das organizacoes que operam grande parte do

seu negocio na Internet e no ciberespaco. Caso seja aceite esta classificacao pode vir a ajudar outras

organizacoes semelhantes a DNS.PT quer em Portugal, quer noutros paıses, nomeadamente a nıvel

europeu, uma vez que ainda nao existe uma definicao clara sobre este genero de organizacoes e quer

Portugal, quer o DNS.PT podem ser vistos como um modelo a seguir.

De referir que no momento do termino do meu trabalho na associacao DNS.PT ainda nao existia

uma resposta por parte da protecao civil a proposta que foi enviada.

2http://www.prociv.pt/pt-pt/Paginas/default.aspx3http://www.prociv.pt/pt-pt/RISCOSPREV/INFRAESTRUTURASCRITICAS/Paginas/default.aspx

48

5.4 Conclusoes

Ao longo deste trabalho procurei responder as necessidades de dois domınios, a continuidade de

negocio e a seguranca da informacao, estes dois domınios no caso de organizacoes muito ou total-

mente tecnologicas sao profundamente complementares, pois como se viu, pela analise efetuada as

normas referencia, existem muitos requisitos transversais.

Esta transversalidade quando estamos perante um negocio puramente assente na tecnologia foi

o que permitiu a elaboracao com sucesso de um processo de gestao de risco que permita alimentar

os dois sistemas de gestao. No entanto apesar de uma grande limitacao 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 importancia das tecnologias, nomeadamente da informacao digital, em todas as areas de

negocio rapidamente nos aproximamos de uma situacao em que, qualquer que seja o negocio, quando

falamos em continuidade de negocio e em seguranca da informacao estamos perante um cenario em

que todo o core do negocio e abrangido.

No entanto, ao longo do trabalho desenvolvido rapidamente me apercebi da importancia de existirem

processos definidos e frameworks de aplicacao como o COBIT, pois ao basear todo o trabalho de

gestao de riscos quer de continuidade de negocio, quer de seguranca de informacao em meros wishfull

thinkings onde nao se define concretamente quem faz o que, nao estamos a solucionar um problema

mas sim a aumenta-lo.

Uma das ilacoes que retirei do trabalho realizado foi que a escolha da tecnica de afericao 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 negocio, enquanto tecnica de afericao de risco

nao so permitiu poupar trabalho na definicao de metodos de afericao, assim como que todos os riscos

estivessem alinhados nos parametros e escalas utilizados o que permitiu a realizacao da avaliacao da

criticidade dos riscos e controlos com maior facilidade.

O fator de a continuidade de negocio obrigar a um pensamento total do negocio obriga a que a pes-

soa que esta a implementar o processo de gestao de risco nao se foque exclusivamente na seguranca

da informacao e pense tambem na implicacao que um risco pode ter para o negocio.

Os maiores desafios por mim encontrados foram:

• Um desconhecimento inicial do tema e da cultura da organizacao que me levou a perder mais

tempo que o esperado na fase de pesquisa e ambientacao;

• O ter de enquadrar as duas normas, ISO 27001 e ISO 22301 e encontrar uma unica 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 identificacao do que apenas e crıtico para o negocio porque existe a

tendencia do ser humano considerar que o que e critico para si tambem e para o negocio o que

nao e necessariamente verdade;

49

• O facto de o contexto do trabalho ser muito especıfico o que dificultou a extrapolacao para outros

domınios.

Ao logo de todo o trabalho retirei licoes relativamente aos desafios ultrapassados, ao definri um

contexto pude perceber a importancia de adaptar o trabalho desenvolvido ao negocio e que embora as

normas de SI e CN sejam semelhantes ha que notar as pequenas diferencas entre ambas. Na atividade

da afericao do risco ficou percetıvel a importancia que as acoes de sensibilizacao previas aos projetos

tem por promoverem uma maior aceitacao e compreensao do tema. Assim como o impacto que o

contexto tem na afericao do risco. Relativamente ao tratamento do risco, foi possıvel verificar que o

negocio, as tecnologias usadas e guidelines seguidas tem muita influencia na parte de definir controlos,

uma vez que interferem no contexto e nıveis de risco. Adicionalmente consegui ter a experiencia da

importancia de um bom trabalho de equipa e de haver varias equipas alocadas a projetos diferentes a

colaborar entre si, sem duvida que esta experiencia me sera muito util na vida laboral onde e cada vez

mais utilizado o trabalho de equipa.

Uma grande limitacao por mim notada nos processos de gestao de risco e que a analise dos riscos

esta quase totalmente baseada na definicao do contexto e nas suas implicacoes, isto implica que o

mais pequeno erro de analise no contexto, quer por substimar ou por sobrestimar um qualquer fator,

pode ter grandes repercussoes no nıvel de um risco o que pode implicar controlos desnecessarios que

se traduzem em gastos que nao seriam precisos ou em falta de controlos o que pode por em causa a

continuidade do proprio negocio.

Em suma considero que estes domınios sao complementares e que nao faz sentido pensar na

seguranca da informacao descurando a continuidade do negocio do mesmo modo que nao faz sentido

considerar a continuidade do negocio descurando a seguranca da informacao. Para alem desta reci-

procidade entre os dois domınios considero tambem que se pode concluir que e possıvel englobar a

gestao do risco num so domınio facilitando assim a implementacao de sistemas de gestaos 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 negocio ja permitem realizar este tipo de solucoes, sendo por isso algo

aplicavel atualmente.

5.5 Trabalho Futuro

A realizacao deste trabalho pode servir de referencia para organizacoes, 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 gestao de risco para domınios diferentes o que

traria um incremento de kown-how e case studies para auxiliar as organizacoes.

Pode tambem 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 referencia para o

trabalho.

Seria bastante util o desenvolvimento de um processo de gestao de risco que conseguisse englobar

as diferentes perspetivas e pontos de vista que uma organizacao pode ter, neste caso a preocupacao

50

foi apenas em 2 domınios ”base”de uma organizacao como o DNS.PT, no entanto o poder haver

um processo global de aplicacao transversal traria grandes benefıcios, uma vez que poria toda uma

organizacao muito mais resiliente ao risco.

51

Anexos

52

Anexo A

Proposta BIA ISACA

Este anexo e conforme o encontrado no site da ISACA. 1.

1http://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

Regulatory and Legal Fines, penalties, compliance issues, contractual obligations, financial liabilities

Customer Service Termination or reduction of service level (internal of external), live operators vs. automated response

Goodwill Public image, shareholder relations, market share

Business Impact Analysis Questionnaire

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:

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 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 ambito do trabalho e que foi adoptado pelo

DNS.PT.

58


Lisboa, 14 de março de 2016 DNS.84.01

2 Objetivo

O objetivo 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 BIA é 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 deve estimar o tempo de indisponibilidade. O

tempo de indisponibilidade deve 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ável perder

antes da disrupção.

RTO (Recovery Time Objective): Limite máximo de tempo aceitável perder no processo

de recuperação após disrupção.

MTD (Maximum Time of Disruption): Soma do RPO e RTO, tempo limite aceitável 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áveis 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 BIA serão realizadas as seguintes atividades:

Aferição dos Processos e respetivos donos;

Identificaçã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

valor 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

1 – Muito Alta <4h

2 - Alta >4h e <1d

3 - Moderada >1d e <3d

4 - Baixa >3d e <14d

5 – Muito Baixa >14d e <30d

Criticidade RPO

1 – Muito Alta >0h e <1h

2 - Alta >1h e <1d

3 - Moderada >1d e <3d

4 - Baixa >3d e <7d


Criticidade MTD

1 – Muito Alta <4h

2 - Alta >4h e <1,5d

3 - Moderada >1,5d e <4d

4 - Baixa >4d e <15d


Tabela 2 - RTO Tabela 3 - RPO Tabela 4 - MTD

Gravidade Reputação e Imagem

1 – Muito Baixa Erros internos sem interação com comunicações externas, que não tem qualquer impacto na continuidade de negócio.

2 - Baixa Falhas ou erros com impacto residual na continuidade de negócio dada a sua rápida resolução ou p ouca re levância para o negócio.

3 - Moderada Falhas ou erros dentro da comunidade DNS.PT, que originem alertas ou re clamaçõ es m as q ue n ão resultam e m publicidade negativa, não tendo impacto direto na continuidade de negócio.

4 - Alta Falhas ou erros com impacto na continuidade de negócio dentro da comunidade DNS.PT, redes socia is e ca nais d e comunicação nacionais , com a poss ibi l idade de provocar publ icidade di famatória , que afetam o negócio comprometendo-o de forma irreversível a curto-prazo.

5 – Muito Alta Falhas ou erros com impacto na continuidade de negócio dentro da comunidade DNS.PT, redes socia is e ca nais d e comunicação nacionais e internacionais, que provocam publicidade difamatória ou quebra de integridad e d e dad os publicados pelo DNS.PT, que afetam 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

X

Tabela 6 – Aferição do Impacto e Criticidade do Processo

Anexo C

Definicao 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

1

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 iado 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 Nacional 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 qualquer 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 infraestruturas 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

2

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

Anexo D

Classificacao enquanto Infraestrutura

Crıtica

Este anexo e um parecer sobre como deve ser classificado o DNS.PT enquanto uma IC em Portu-

gal.

64

1

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ádio, ótico 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 setor 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 redes 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

2

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 defesa

nacional como ambiente virtual onde se agrupam e relacionam utilizadores, 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 le

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ável 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, quer a revendedores de domínios.

O DNS.PT usa por base o protocolo DNS no core do negócio e conforme analisado 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.

3

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_Security_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

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] Goncalo Mateus: A Risk Register for Information Security - Relatorio de Projeto de Dissertacao do

Mestrado em Engenharia de Telecomunicacoes e Informatica, 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