Cncs Qnrcs 2019
Cncs Qnrcs 2019
Cncs Qnrcs 2019
PARA A CIBERSEGURANÇA
Centro Nacional de Cibersegurança
2
1 Prefácio
A segurança digital das entidades públicas e privadas do nosso país é uma prioridade. Sem
um elevado nível de maturidade em Cibersegurança nas nossas organizações, não estão
reunidas as condições para um efetivo e sustentável desenvolvimento económico. Neste
contexto, as medidas preventivas e, em particular, a conformidade com as melhores práti-
cas, são aquelas que melhor contribuem para este ambiente desejado.
Neste enquadramento, o Centro Nacional de Cibersegurança reuniu o conjunto das melho-
res práticas num Quadro Nacional de Referência para a Cibersegurança, o qual permite às
organizações reduzir o risco associado às ciberameaças, disponibilizando as bases para que
qualquer entidade possa, de uma forma voluntária, cumprir os requisitos mínimos de segu-
rança das redes e sistemas de informação, nas suas diversas componentes. Designadamen-
te, na identificação, proteção, deteção, resposta e recuperação a ciberincidentes, incluindo
a organização necessária para a sua gestão.
Com uma estrutura simples e clara, este documento pretende servir de guia para deci-
sores e técnicos das organizações. Desta forma, convidamos toda a comunidade a ado-
tar este Quadro Nacional de Referência para a Cibersegurança, contribuindo assim para
um desenvolvimento económico sustentável.
___________________________ ___________________________
António Gameiro Marques Lino Santos
Autoridade Nacional de Segurança Coordenador do Centro Nacional de Cibersegurança
3
ÍNDICE
1 Prefácio............................................................................................................................................................................ 3
3 Introdução.................................................................................................................................................................... 11
3.1 Enquadramento................................................................................................................................................. 12
3.2 Objetivos.............................................................................................................................................................. 14
3.5.1 Introdução..................................................................................................................................................... 22
3.5.2 Enquadramento............................................................................................................................................ 23
Critérios de impacto.................................................................................................................................................... 26
Identificar ameaças...................................................................................................................................................... 28
Identificar controlos..................................................................................................................................................... 29
Identificação de vulnerabilidades................................................................................................................................ 29
Identificação de impacto............................................................................................................................................. 30
Análise de probabilidade............................................................................................................................................. 33
4
3.5.10 Exemplo.......................................................................................................................................................... 37
3.8 Contextualização............................................................................................................................................... 43
4.2.1 Identificar............................................................................................................................................................. 47
4.2.2 Proteger................................................................................................................................................................ 48
4.2.3 Detetar.................................................................................................................................................................. 50
4.2.4 Responder............................................................................................................................................................ 51
4.2.5 Recuperar............................................................................................................................................................. 51
4.3 Identificar........................................................................................................................................................... 53
inventariados................................................................................................................................................................ 54
ID.GA-2 – As aplicações e plataformas de software que suportam os processos dos serviços críticos devem ser
inventariadas................................................................................................................................................................ 55
ID.GA-5 – Os ativos necessários para a prestação de bens e serviços devem ser classificados................................. 57
ID.AO-3 – A missão, visão, valores, estratégias e objetivos da organização devem ser definidas e comunicadas.... 59
ID.AO-5 – Os requisitos de resiliência necessários para suportar a prestação de serviços críticos devem ser
definidos....................................................................................................................................................................... 61
ID.AR-2 – A organização deve partilhar informações sobre ameaças de cibersegurança com grupos de interesse
da especialidade.......................................................................................................................................................... 64
5
ID.AR-3 – As ameaças internas e externas devem ser identificadas e documentadas na metodologia de gestão do
risco....................................................................................................................................................................................65
ID.AR-4 – A gestão do risco deve ser efetuada com base na análise de ameaças, vulnerabilidades, probabilidades
e impactos..........................................................................................................................................................................66
ID.AR-5 – A organização deve garantir que as respostas aos riscos são identificadas e priorizadas................................67
ID.GL-3 – Os contratos com fornecedores devem respeitar o plano de gestão do risco para a cadeia logística........... 72
ID.GL-5 – O plano de resposta e recuperação de desastre deve ser exercitado com o acompanhamento de
fornecedores..................................................................................................................................................................... 73
PR.GA-4 – A organização deve aplicar na gestão de acessos, os princípios do menor privilégio e da segregação
de funções..........................................................................................................................................................................79
PR.GA-6 – A organização deve verificar a identidade dos colaboradores e vinculá-las às respetivas credenciais......... 82
PR.GA-7 – Devem ser definidos mecanismos de autenticação de utilizadores, dispositivos, e outros ativos de
sistemas de informação.................................................................................................................................................... 83
PR.FC-2 – Os utilizadores com acesso privilegiado devem compreender quais são os seus papéis e
responsabilidades..............................................................................................................................................................85
PR.FC-3 – As partes interessadas externas devem compreender quais são os seus papéis e responsabilidades...........85
PR.SD-3 – A organização deve gerir formalmente os ativos durante os procedimentos de remoção, transferência e
PR.SD-4 – A organização deve providenciar a capacidade adequada para garantir a disponibilidade das redes e
6
PR.SD-6 – A organização deve utilizar mecanismos de verificação para confirmar a integridade de software,
firmware e dados...............................................................................................................................................................91
princípios de segurança.....................................................................................................................................................94
PR.PI-4 – Devem ser realizadas, mantidas e testadas cópias de segurança dos dados da organização..........................97
PR.PI-5 – As políticas e regulamentações associadas à operacionalização dos ambientes físicos dos ativos da
PR.PI-8 – A efetividade das tecnologias de proteção deve ser tida em conta na melhoria dos processos de
proteção...........................................................................................................................................................................100
PR.PI-11 – A cibersegurança deve ser contemplada nos processos de gestão de recursos humanos..........................102
PR.MA-2 – As operações de manutenção remota das redes devem ser revistas, aprovadas, executadas e
registadas.........................................................................................................................................................................105
com as políticas...............................................................................................................................................................106
PR.TP-2 – Os suportes de dados amovíveis devem ser protegidos e a sua utilização deve ser restrita, de acordo
PR.TP-5 – Devem ser implementados mecanismos para cumprir os requisitos de resiliência em situações
adversas...........................................................................................................................................................................110
4.5 Detetar.....................................................................................................................................................................112
DE.AE-2 – Os eventos detetados devem ser analisados por forma a se identificarem os alvos e os métodos de
7
ataque........................................................................................................................................................................114
DE.AE-3 – Os eventos devem ser coletados e correlacionados a partir de várias fontes e sensores.......................114
DE.MC-2 – O ambiente físico deve ser monitorizado para se detetar potenciais incidentes de segurança............118
DE.MC-3 – A atividade dos colaboradores deve ser monitorizada para se detetar potenciais incidentes..............119
DE.MC-4 – A organização deve identificar e implementar mecanismos para deteção de código malicioso...........120
DE.MC-5 – A utilização de aplicações não autorizadas em dispositivos móveis deve ser detetada........................121
DE.MC-6 – As atividades dos prestadores de serviços externos devem ser monitorizadas para deteção de
incidentes...................................................................................................................................................................122
DE.MC-7 – Deve ser efetuada a monitorização de acessos não autorizados de colaboradores, conexões,
dispositivos e software.....................…………………………………………………………………………………………………………………..123
DE.PD-2 – As atividades de deteção devem cumprir com todos os requisitos aplicáveis........................................ 125
de atividades..............................................................................................................................................................131
RS.CO-2 – Os incidentes devem ser reportados de acordo com critérios estabelecidos......................................... 131
RS.CO-3 – As informações devem ser partilhadas de acordo com o plano de resposta.......................................... 132
RS.CO-4 – A coordenação com as partes interessadas deve ocorrer conforme os planos de resposta.................. 133
RS.CO-5 – Deve ocorrer partilha voluntária de informação com partes interessadas externas.............................. 134
RS.AN-4 – Os incidentes devem ser categorizados de acordo com o plano de resposta......................................... 137
RS.AN-5 – A organização deve definir processos para receber, analisar e responder a vulnerabilidades provenien-
8
RS.MI-2 – Os incidentes devem ser mitigados.......................................................................................................... 139
RS.MI-3 – As novas vulnerabilidades identificadas devem ser mitigadas ou documentadas como riscos
aceites........................................................................................................................................................................140
4.7 Recuperar...........................................................................................................................................................143
RC.CO-2 – As atividades de recuperação devem ser comunicadas às partes interessadas, internas e externas, bem
5 RECOMENDAÇÕES ADICIONAIS...................................................................................................................148
5.1 Introdução.........................................................................................................................................................149
9
2 Sumário Executivo
A consciencialização das organizações para a temática da segurança das redes e dos sis-
temas de informação nunca foi tão relevante como é hoje em dia. A cada ano que passa,
existe um maior número de dispositivos conectados entre si através da internet, alguns
deles mal protegidos ou mal configurados, que acabam por se traduzir em ameaças aos
ativos das organizações.
A cibersegurança, em todas as suas vertentes, é uma preocupação central nas socieda-
des atuais. Um ambiente seguro é fundamental para estabelecer e desenvolver qualquer
atividade económica ou social. No entanto, a segurança não deve ser a protagonista. Pelo
contrário, deve existir para libertar os cidadãos e as empresas de preocupações, de modo
a que se possam focar nas suas atividades.
Em alinhamento com a Lei n.º 46/2018, que estabelece o regime jurídico da segurança
do ciberespaço, transpondo a Diretiva (UE) 2016/1148, do Parlamento Europeu e do Con-
selho, de 6 de julho de 2016, relativa a medidas destinadas a garantir um elevado nível
comum de segurança das redes e da informação em toda a União, este documento tem
como missão providenciar às organizações um guia de cibersegurança que sistematiza um
conjunto de medidas para as problemáticas mais relevantes da atualidade nesta matéria.
Pretende disponibilizar as bases para uma organização cumprir os requisitos mínimos de
segurança da informação recomendados.
Sabendo que as organizações se podem encontrar em diferentes níveis de maturidade e
possuir diferentes dimensões (desde micro e pequenas organizações a grandes empresas
ou instituições públicas), e que algumas recomendações podem ser desproporcionalmente
exigentes para a dimensão da organização ou não ser suficientemente exigentes, sugere-se
que o documento seja interiorizado com espírito crítico por cada organização e adequado
às suas necessidades.
Está estruturado num conjunto de medidas de segurança que traduzem cinco objetivos
específicos: Identificar, Proteger, Detetar, Responder e Recuperar.
São referenciados exemplos e orientações que permitem sistematizar processos e proce-
dimentos cuja aplicação conduza ao cumprimento desses mesmos objetivos, não na forma
de uma lista de controlo de ações a realizar, mas antes na representação dos objetivos cha-
ve reconhecidos pelos diversos intervenientes como uma referência de alto nível, assente
num conjunto de referenciais internacionais e em diferentes normas técnicas.
Os objetivos são divididos em categorias e subcategorias, sendo que para cada subcatego-
ria este documento referencia um exemplo de implementação tecnológica, de implemen-
tação processual e de evidência, consistindo numa descrição genérica de como poderá ser
aplicado, contribuindo, desse modo, para uma melhor compreensão do mesmo.
Este documento termina com um conjunto de recomendações adicionais, fundamentais
para que as organizações possam cumprir, por um lado, com a legislação em vigor, e por
outro possam de forma efetiva estar preparadas, através da definição de uma estratégia
que envolva toda a organização, para gerir o risco e mitigar o impacto dos incidentes que
poderão afetar as organizações.
10
3.1 Enquadramento
É realidade aceite que uma parcela significativa da nossa economia, assim como do bem-
-estar social, se encontram consubstanciadas em infraestruturas e serviços disponibiliza-
dos no ciberespaço. No presente documento, entendemos o ciberespaço como sendo um
ambiente complexo, de valores e interesses, materializado numa área de responsabilidade
coletiva, que resulta da interação entre pessoas e redes e sistemas de informação. Este am-
biente complexo e heterogéneo oferece novas possibilidades e oportunidades. No entanto,
em igual medida, lança a base para a criação de um novo espaço de ameaça e risco com a
ocorrência de incidentes que podem trazer impactos económicos e sociais que não podem
ser negligenciados.
Estes incidentes de segurança informática podem não impactar apenas o enquadramento
cibernético, estendendo o seu alcance a infraestruturas físicas que suportem serviços críti-
cos ou essenciais ao pleno funcionamento da sociedade.
Na era digital em que vivemos, as infraestruturas funcionam baseadas na premissa de que
os elementos tecnológicos são robustos e fiáveis e que tecnologias emergentes e comple-
xas (por exemplo: IoT, Cloud Computing, Big Data) têm o potencial para oferecer uma ele-
vada flexibilidade e eficiência na comunicação e coordenação de serviços e processos. Mas
este uso crescente de tecnologias de informação também significa que estas se tornam
mais vulneráveis a atividades ilícitas e maliciosas e a processos de manutenção operacio-
nais mal planeados.
São variadas as motivações subjacentes às atividades maliciosas que podem ser concre-
tizadas por terroristas, criminosos, ativistas ou nações estrangeiras. O impacto de um
incidente varia num espectro alargado, com graus de severidade diferentes, desde a indis-
ponibilidade de um sítio institucional, com eventual impacto reputacional, até à redução
da capacidade de defesa de um país, a perdas financeiras ou mesmo de vidas humanas.
Numa outra perspetiva, uma gestão adequada dos riscos relacionados com incidentes de
cibersegurança pode revelar-se também em oportunidades de melhoria na qualidade dos
serviços prestados, na adoção de novas práticas, no desenvolvimento de novos produtos
ou serviços e na melhoria da reputação das organizações.
Em 2016, foi aprovada a Diretiva (UE) 2016/1148 do Parlamento Europeu e do Conselho, de
6 de julho, relativa a medidas destinadas a garantir um elevado nível comum de segurança
das redes e dos sistemas de informação em toda a União (Diretiva SRI). A Diretiva SRI visa
assegurar que os operadores de serviços essenciais e os prestadores de serviços digitais to-
mam as medidas técnicas e organizativas adequadas e proporcionadas para gerir os riscos
que se colocam à segurança das redes e dos sistemas de informação que utilizam nas suas
operações e que notificam as autoridades competentes ou as CSIRT (Equipas de Resposta
a Incidentes de Segurança Informática), sem demora injustificada, dos incidentes com um
12
impacto relevante na continuidade dos serviços essenciais por si prestados.
Com a Diretiva SRI, pretendeu-se criar-se o enquadramento legal para a legislação dos Es-
tados-Membros no domínio da cibersegurança e fornecer bases para desenvolver uma cul-
tura de cibersegurança em setores vitais para a economia dos Estados-Membros e para o
correto funcionamento da sociedade, setores esses que dependem fortemente das redes
e sistemas de informação. Assim, o Anexo II da referida Diretiva prevê os seguintes setores
de operadores de serviços essenciais: energia, transportes, bancário, infraestruturas do
mercado financeiro, saúde, fornecimento e distribuição de água potável, e infraestruturas
digitais. O Anexo III foca os seguintes prestadores de serviços digitais: serviços de compu-
tação em nuvem, serviços de mercado em linha, serviços de motor de pesquisa em linha.
No entanto, ainda carecemos de abordagens adequadas que apoiem e facilitem a coope-
ração rápida e eficaz entre operadores de serviços essenciais e prestadores de serviços digi-
tais, quer em termos de troca de informações específicas sobre incidentes, quer na partilha
de informações sobre riscos e ameaças. Além disso, existe um défice na captura e correla-
cionamento de eventos e informações associadas a ataques cibernéticos a infraestruturas,
para além de que as ferramentas existentes não fornecem orientação técnica adequada aos
profissionais de resposta a incidentes sobre como detetar, investigar e reproduzir ataques.
Como tal e, apesar da importância socioeconómica das ferramentas e técnicas para lidar
com incidentes, ainda não existe uma maneira fácil, estruturada, padronizada e confiável
de gerir e prever incidentes inter-relacionados de cibersegurança, de uma maneira que
tenha em conta a heterogeneidade e complexidade do incidente e os tipos de ataques
cada vez mais sofisticados. Portanto, há uma necessidade urgente de criar novos sistemas
para o tratamento eficiente de incidentes e apoiar a compreensão completa e comum de
situações de ataques cibernéticos em tempo útil.
As próprias ameaças ao ciberespaço, como potenciais incidentes, não devem comprometer
todos os benefícios que as redes e sistemas de informação potenciam na nossa sociedade.
A resposta a uma ameaça ou incidente não deverá ser, por isso, encarada apenas numa
perspetiva de indisponibilização de um determinado serviço digital afetado, mas deve ser
sistemática e focada também na prevenção e na sensibilização de todos os intervenientes,
sejam eles cidadãos, organizações públicas e privadas, ou o país em geral.
O Quadro Nacional de Referência para a Cibersegurança, doravante denominado QNRCS,
pretende ser uma ferramenta à disposição da sociedade para apoio a essa resposta siste-
mática. Esta resposta está igualmente alinhada com a Lei n.º 46/2018, que estabelece o
regime jurídico da segurança do ciberespaço, transpondo a Diretiva SRI.
13
92/2019 de 23 de maio1. A Estratégia funda-se no compromisso de aprofundar a se-
gurança das redes e da informação, como forma de garantir a proteção e defesa do
ciberespaço de interesse nacional e potenciar uma utilização livre, segura e eficiente do
mesmo por parte de todos os cidadãos, das empresas e das demais entidades públicas e
privadas. A Estratégia alicerça-se em três princípios, os quais o QNRCS pretende endereçar
da seguinte forma:
a. Subsidiariedade: o QNRCS pretende ser uma ferramenta transversal a todas as or-
ganizações intervenientes no ciberespaço, desde os operadores privados até ao
Estado, enquanto responsável pelo garante da soberania e dos princípios constitu-
cionais;
b. Complementaridade: sendo o QNRCS transversal, propõe um conjunto de medidas
alargadas e integradoras que têm como objetivo potenciar a consciencialização
entre todos os atores intervenientes no ciberespaço e a posição que ocupam no
mesmo;
c. Proporcionalidade: no QNRCS, ao longo dos objetivos de segurança, propõe-se a
adequação das medidas à organização, quanto à sua aplicabilidade, dimensão, se-
tor de atividade e caraterização dos riscos identificados.
Ter uma visão holística, quer de pessoas, quer de infraestrutura de equipamentos dedica-
dos à temática da segurança e que consiga seguir as medidas propostas no QNRCS, requer
um investimento em três pilares. Primeiro, na criação da figura do CISO, como responsável
máximo da segurança da informação dentro da organização, em segundo, com a constitui-
ção de um SOC, para dotar a organização das instalações e equipas de suporte necessárias
e, em terceiro, da constituição de uma equipa especializada de resposta a incidentes que
pode operar nas instalações do SOC, ou seja, a criação da função CSIRT. No último capítulo
do documento apresentam-se recomendações adicionais, com o objetivo de clarificar estes
três pilares e a sua importância nas organizações.
3.2 Objetivos
¹ https://dre.pt/application/conteudo/122498962
14
O QNRCS não pretende constituir-se como uma norma de cibersegurança, mas sim como
uma referência que permita identificar as normas, padrões e boas práticas existentes em
vários domínios da segurança da informação. A sua aplicação nas organizações é volun-
tária e passível de ser adaptada, por forma a melhor endereçar necessidades específicas
inerentes ao seu setor, dimensão ou qualquer outro aspeto distintivo que caracterize a
organização.
A estrutura central do QNRCS foi definida numa perspetiva de ciclo de vida da gestão da
cibersegurança de uma organização, tendo em atenção os aspetos humanos, tecnológicos
e processuais, com especial enfoque nos processos e procedimentos da gestão do risco.
Uma característica intrínseca do risco é o facto de este não poder ser totalmente elimi-
nado, tornando-se fundamental a concretização de uma estratégia global da organização,
para garantir a implementação de um processo eficaz de gestão do risco.
Este é um processo contínuo de identificação, diagnóstico e resposta, sendo que, para
que seja possível gerir o risco, as organizações devem compreender a probabilidade de um
determinado evento ocorrer, bem como os seus potenciais impactos adversos e vulnera-
bilidades existentes. Conhecendo esta informação, qualquer organização pode determinar
o seu nível aceitável do risco e, de esta forma, promover a resiliência da sua atividade
enquanto prestador de bens ou serviços. A esta informação corresponde a perceção de
tolerância ao risco, condição sine qua non para a priorização das atividades realizadas no
âmbito da cibersegurança.
O documento encontra-se estruturado com uma parte inicial onde se efetua uma intro-
dução ao QNRCS, identificando-se os seus objetivos, o seu contexto, a sua aplicabilidade e
as definições das terminologias utilizadas. Explana-se igualmente a temática da gestão do
risco, cujo entendimento se considera enriquecedor para enquadramento e melhor perce-
ção do QNRCS.
15
No final do documento, apresenta-se o papel do CISO (Responsável de Segurança de In-
formação), que se considera uma posição importante na organização. É sobre o CISO que
deve recair a gestão do ciclo de vida das temáticas da segurança da informação e cibersegu-
rança. Reflete-se igualmente sobre a CSIRT (Equipa de Resposta a Incidentes de Segurança
Informática) e o SOC (Centro de Operações de Segurança), quais os seus objetivos, a sua
constituição e, ainda, sobre a importância da partilha de informação sobre incidentes de
cibersegurança com as partes interessadas da organização.
16
TERMO DEFINIÇÃO ORIGEM
Confidencialidade A propriedade de a informação não ser divulgada a pes- ISO/IEC 27000
soas ou entidades não autorizadas, ou segundo proces-
sos não autorizados.
Continuidade do Capacidade da organização para continuar a fornecer NP EN ISO 22301
negócio produtos ou serviços a níveis aceitáveis pré-definidos,
na sequência de um incidente disruptivo.
Disponibilidade Propriedade de estar acessível e de poder ser utilizada a ISO/IEC 27000
pedido de uma entidade autorizada.
Documento Informação e respetivo meio de suporte (exemplo não NP EN ISO 22301
constantes na NP EN ISO 22301: papel, magnético, ele-
trónico ou unidade de armazenamento de computador,
fotografia ou amostra de referência).
Entrega Contínua Abordagem ao processo de engenharia de software, no QNRCS
âmbito da qual se produz código em ciclos curtos, o que
permite um alinhamento estreito com metodologias
ágeis.
Equipa de respos- A equipa que atua por referência a uma comunidade de Lei 46/2018
ta a incidentes de utilizadores definida, em representação de uma organi-
segurança infor- zação, prestando um conjunto de serviços de segurança
mática que inclua, designadamente, o serviço de tratamento e
resposta a incidentes de segurança das redes e dos siste-
mas de informação.
Especificação téc- Um documento que define os requisitos técnicos que Lei 46/2018
nica um produto, processo, serviço ou sistema devem cum-
prir.
Exercício Processo para formar, avaliar, praticar e melhorar o de- NP EN ISO 22301
sempenho de uma organização.
Framework Modelo de referência. NP ISO/IEC 27001
Gestão do risco Atividades coordenadas para dirigir e controlar uma or- NP EN ISO 22301
ganização, no que respeita ao risco.
Honeypot Mecanismo de criação de um sistema que potencia um QNRCS
provável atacante a incorrer numa ação ilegítima, que
poderia resultar num incidente. É um recurso criado
propositadamente para ser sondado, atacado e compro-
metido. Um dos seus principais objetivos é o de permitir
a monitorização do comportamento dos atacantes.
Incidente Um evento com um efeito adverso real na segurança das Lei 46/2018
redes e dos sistemas de informação.
Infraestrutura A componente, sistema ou parte deste, situado em Lei 46/2018
crítica território nacional, que é essencial para a manutenção
de funções vitais para a sociedade, saúde, segurança e
o bem-estar económico ou social, cuja perturbação ou
destruição teria um impacto significativo, dada a impos-
sibilidade de continuar a assegurar essas funções.
17
TERMO DEFINIÇÃO ORIGEM
Integração Con- Prática de engenharia de software que promove a con- QNRCS
tínua solidação de código numa cadência curta, tipicamente
diária, tendo por objetivo simplificar o processo de inte-
gração das várias peças produzidas.
Integridade A propriedade de salvaguardar o caráter exato e comple- ISO/IEC 27000
to da informação e dos ativos.
Internet Sistema global de redes interconectadas e de domínio ISO/IEC 27032
público.
Acordo de nível Acordo documentado entre a organização e o cliente ISO/IEC 20000
de serviço que identifica serviços e o seu desempenho acordado.
Uma especificação técnica, aprovada por um organismo Lei 46/2018
de normalização reconhecido para aplicação repetida ou
Norma continuada, cuja observância não é obrigatória.
Melhoria contínua Atividade recorrente com vista a incrementar a capaci- NP EN ISO 9000
dade para satisfazer requisitos.
Operador de in- Uma entidade pública ou privada que opera uma infraes- Lei 46/2018
fraestrutura crítica trutura crítica.
Operador de ser- Uma entidade pública ou privada que presta um serviço Lei 46/2018
viços essenciais essencial.
Organização Pessoa ou conjunto de pessoas que tem as suas próprias NP EN ISO 22301
funções com responsabilidades, autoridades e relações
para atingir os seus objetivos.
Parte Interessada Pessoa ou organização que pode afetar, ser afetada por, NP EN ISO 22301
ou considerar-se como sendo afetada por uma decisão
ou atividade. Pode ser um indivíduo ou um grupo que
tem um interesse em qualquer decisão ou atividade de
uma organização.
Plano da continui- Procedimentos documentados que orientam as organi- NP EN ISO 22301
dade do negócio zações para responder, recuperar, retomar e restaurar
um nível pré-definido de operacionalização, após disrup-
ção.
Política Intenções e orientação de uma organização, conforme NP EN ISO 22301
formalmente expressas pela sua gestão de topo.
Ponto de troca de Uma estrutura de rede que permite a interligação de Lei 46/2018
tráfego mais de dois sistemas autónomos independentes, a fim
de facilitar a troca de tráfego na Internet.
Prestador de ser- Uma pessoa coletiva que presta um serviço digital. Lei 46/2018
viços digitais
Prestador de ser- Uma entidade que presta serviços do sistema de nomes
viços do sistema de domínio (DNS) na Internet.
de nomes de do- Lei 46/2018
mínio
Processo Conjunto de atividades interrelacionadas ou interatuan- NP EN ISO 22301
tes que transformam entradas em saídas.
Procedimento Modo especificado de realizar uma atividade ou um pro- NP EN ISO 22301
cesso.
Rede e sistema de Qualquer dispositivo ou conjunto de dispositivos inter- Lei 46/2018
informação ligados ou associados, em que um ou mais desenvolve,
em execução de um programa, o tratamento automati-
zado de dados informáticos, bem como a rede de comu-
nicações eletrónicas que suporta a comunicação entre
eles e o conjunto de dados informáticos armazenados,
tratados, recuperados ou transmitidos por aquele ou
aqueles dispositivos, tendo em vista o seu funcionamen-
to, utilização, proteção e manutenção.
18
TERMO DEFINIÇÃO ORIGEM
Registo de nomes Uma entidade que administra e opera o registo de no- Lei 46/2018
de domínio de mes de domínio da Internet de um domínio de topo es-
topo pecífico.
Registo Documento que expressa resultados obtidos ou fornece NP EN ISO 22301
evidência das atividades realizadas.
Representante Uma pessoa singular ou coletiva, estabelecida na União NIS 2016/1148
Europeia, expressamente designada para atuar por con-
ta de um prestador de serviços digitais não estabelecido
na União Europeia, que pode ser contactada por uma
autoridade competente nacional ou por uma CSIRT, em
representação do prestador de serviços digitais, quanto
às obrigações que incumbem a este último.
Risco Uma circunstância ou um evento razoavelmente identifi- Lei 46/2018
cável, com um efeito adverso potencial na segurança das
redes e dos sistemas de informação.
Segurança das re- A capacidade das redes e dos sistemas de informação Lei 46/2018
des e dos sistemas para resistir, com um dado nível de confiança, a ações
de informação que comprometam a confidencialidade, integridade, dis-
ponibilidade, autenticidade e o não repúdio dos dados
armazenados, transmitidos ou tratados, ou dos serviços
conexos oferecidos por essas redes ou por esses siste-
mas de informação, ou acessíveis através dos mesmos.
Serviço de compu- Um serviço digital que permite o acesso a um conjunto Lei 46/2018
tação em nuvem modulável e adaptável de recursos computacionais par-
tilháveis.
Serviço de merca- Um serviço digital que permite aos consumidores ou Lei 46/2018
do em linha aos comerciantes celebrarem contratos de venda ou de
prestação de serviços por via eletrónica com comercian-
tes, quer no sítio na Internet do mercado em linha, quer
no sítio na Internet de um comerciante que utilize os
serviços de computação disponibilizados pelo mercado
em linha.
Serviço de motor Um serviço digital que permite aos utilizadores consul- Lei 46/2018
de pesquisa em tarem todos os sítios na Internet, ou sítios na Internet
linha numa determinada língua, com base numa pesquisa so-
bre qualquer assunto e que fornece ligações onde po-
dem ser encontradas informações relacionadas com o
conteúdo solicitado.
Serviço crítico Serviço de suporte aos processos chave de uma organi- QNRCS
zação.
19
TERMO DEFINIÇÃO ORIGEM
Sistema Legado Sistema obsoleto que permanece em operação na orga- QNRCS
nização.
Tratamento de Todos os procedimentos de apoio à deteção, análise, Lei 46/2018
incidentes contenção e resposta a um incidente.
Tolerância ao risco Disposição da organização ou das partes interessadas ISO/IEC 22300
para assumirem o risco após o seu o tratamento, por for-
ma a poderem alcançar os seus objetivos.
Verificação cíclica Método de deteção de erros normalmente usada em re- QNRCS
de redundância des digitais e dispositivos de armazenamento, para dete-
tar uma mudança acidental em cadeias de dados.
Vulnerabilidade Fraqueza de um ativo ou de um controlo que pode ser ISO/IEC 27032
explorada por uma ameaça.
Zona desmilitari- Rede de perímetro (igualmente conhecida como sub- ISO/IEC 27033
zada -rede rastreável) que se insere como uma “zona neutra”
entre redes.
Tabela 1 – Definições
3.4.2 Abreviaturas
ABREVIATURA DEFINIÇÃO
AVAC Aquecimento, ventilação e ar condicionado.
CCTV Closed-circuit television – Circuito fechado de televisão.
CD Continuous Delivery – Entrega contínua.
CI Continuous Integration – Integração contínua.
CIS Center for Internet Security – Centro de segurança para a internet.
Chief Information Security Officer – Responsável de Segurança de Informa-
CISO
ção.
Control Objectives for Information and Related Technologies - Objetivos de
COBIT
controlo para informações e tecnologias relacionadas.
COO Chief Operations Officer – Responsável das Operações.
CRC Cyclic Redundancy Check – Verificação cíclica de redundância.
CSC Critical Security Controls – Controlos críticos de segurança.
Computer Security Incident Response Team – Equipa de Resposta a Inciden-
CSIRT
tes de Segurança Informática.
Lista de registos que contêm um número de identificação, uma descrição
CVE
e, pelo menos, uma referência pública para vulnerabilidades de segurança.
DLP Data Loss Prevention – Prevenção de perda de informação.
DMZ Demilitarized Zone – Zona desmilitarizada.
DNS Domain Name System – Sistema de resolução de nomes de domínio.
ENSC Estratégia Nacional de Segurança do Ciberespaço 2019-2023.
IDS Intrusion Detection System – Sistema de deteção de intrusões.
IoT Internet of Things – Internet das coisas.
IP Internet Protocol – Protocolo de comunicações.
IPS Intrusion Prevention System – Sistema de prevenção de intrusões.
Information Systems Audit and Control Association – Associação de auditoria
ISACA
e controlo de sistemas de informação.
20
ABREVIATURA DEFINIÇÃO
International Organization for Standardization - Organização internacional de
ISO
normalização
International Organization for Standardization/International Electrotechnical
ISO/IEC Commission – Organização internacional de normalização/Comissão eletro-
técnica internacional.
Base de dados de vulnerabilidades mantida por organização não governa-
MITRE mental Norte-americana, internacionalmente reconhecida como a líder nes-
ta matéria.
National Institute of Standards and Technology – Instituto Nacional de Pa-
NIST
drões e Tecnologia (Norte-americano).
QNRCS Quadro Nacional de Referência para a Cibersegurança.
Responsible – Responsável, Accountable – Aprovador, Consulted – Consulta-
RACI
do e Informed – Informado. Matriz de atribuição de Responsabilidades.
SOC Security Operations Center - Centro de Operações de Segurança.
SRI Segurança das Redes e da Informação.
Strengths – Forças, Weaknesses – Fraquezas, Opportunities – Oportuni-
SWOT
dades, Threats – Ameaças.
VPN Virtual Private Network – Rede privada virtual.
SGSI Sistema de Gestão de Segurança da Informação.
TI Tecnologias de Informação.
UPS Uninterruptible Power Source – Unidade de alimentação ininterrupta.
WAF Web Application Firewall – Firewall de aplicações web.
WWW World Wide Web – Rede mundial de computadores.
Tabela 2 - Abreviaturas
21
3.5 Gestão do Risco
3.5.1 Introdução
O QNRCS propõe uma implementação processual orientada à gestão do risco, que permi-
te às organizações a tomada de decisão de forma priorizada e informada, no contexto da
cibersegurança. Estas decisões devem, sempre, estar igualmente orientadas à garantia da
confidencialidade, disponibilidade e integridade na prestação do bem ou serviço para uma
determinada organização. Neste âmbito, entende-se risco como uma circunstância ou um
evento identificável, com um efeito adverso potencial na segurança das redes e dos siste-
mas de informação.
Neste contexto, são propostas várias abordagens ao processo de avaliação periódica dos
riscos e de aferição da forma como estes se relacionam no âmbito da prestação de um bem
ou serviço. O resultado destas avaliações deve permitir à organização caracterizar a situa-
ção atual, definir objetivos e elencar um conjunto de ações que fomentem uma evolução
positiva da sua situação no contexto da cibersegurança. Assim, o QNRCS permite, a quem
o aplica, que escolha e direcione ao longo do tempo as melhorias pretendidas na gestão
dos riscos.
A gestão do risco, quando efetuada de forma sistematizada e numa lógica de melhoria, é
uma prática que permite às organizações identificar, quantificar e estabelecer as priorida-
des face a critérios de aceitação do risco e objetivos relevantes para a organização.
A gestão do risco de uma organização pode ser entendida como a gestão da incerteza e de-
terminação das ações necessárias, para que esta possa ser minimizada para níveis conside-
rados aceitáveis por parte da organização. É um exercício sistematizado, no âmbito do qual
a organização identifica possíveis ameaças que possam construir sobre as vulnerabilidades
dos ativos, bem como quais os níveis do risco associado, avaliando-se a probabilidade de
ocorrência e possíveis impactos.
A ISO/IEC 310001 disponibiliza um conjunto de princípios e de orientações genéricas sobre
gestão do risco para as organizações. Por outro lado, a ISO/IEC 270052 especifica orienta-
ções e processos para gestão do risco de segurança dos sistemas de informação de uma
organização, suportando-se, em particular, nos requisitos de um Sistema de Gestão de Se-
gurança da Informação (SGSI), implementado de acordo com a norma ISO/IEC 270013.
A ISO/IEC 27005 não fornece uma metodologia específica para a gestão dos riscos de segu-
rança da informação. Cabe às organizações definirem qual a sua abordagem para a gestão
dos riscos. Em geral, a metodologia de gestão do risco ISO/IEC 27005, por ser direcionada a
sistemas de informação, pode ser aplicável a todos os tipos de organização.
A segurança da informação tem como preocupação primária a proteção dos ativos da or-
ganização contra ameaças internas e externas, sendo estas categorizadas de acordo com o
potencial dano que possam causar aos ativos a proteger.
22
No domínio da segurança é dada maior atenção às ameaças relacionadas com atividades
maliciosas ou de origem humana. A figura em baixo, retirada da norma ISO/IEC 270324,
ilustra esses conceitos e relações de alto nível.
Tal como será explicado mais à frente neste capítulo de gestão do risco, o plano de trata-
mento dos riscos é executado tendo por base a avaliação realizada pela organização sobre
riscos identificados, no âmbito do processo de análise. Existem quatro opções disponíveis
para tratamento do risco: Evitar, Aceitar, Mitigar e Transferir.
Para todos os riscos cuja opção de tratamento tenha sido a mitigação, a organização deve-
rá elaborar um plano de tratamento que identifique os constrangimentos e eventuais de-
pendências, prioridades atuais da organização, prazos de execução, recursos necessários
e o caminho crítico da implementação de medidas de mitigação.
3.5.2 Enquadramento
Tal como se pode observar na figura seguinte, a Gestão do Risco em Segurança da Infor-
mação baseada na norma ISO/IEC 27005, é composta pelas seguintes fases: Estabelecer
Contexto (1), o Levantamento do Risco (2), que inclui a identificação (2.1), análise (2.2) e
avaliação do risco (2.3), a fase de tratamento do risco (3), de aceitação do risco (4) dando-
-se depois sequência às fases de comunicação e consulta (5) e de monitorização e revisão
do risco (6).
No presente capítulo iremos densificar cada uma das fases indicadas seguindo as diretrizes
da norma ISO/IEC27005, culminando com um exemplo prático da aplicabilidade da gestão
de um risco.
• Definir uma metodologia de gestão do risco que seja adequada para a realidade da
organização;
24
o Gestor do risco – Elemento responsável pelo processo de gestão do risco;
o Membro da equipa de gestão do risco – Elemento participante no proces-
so de gestão do risco. Poderá ser um responsável de ativos, de departa-
mento ou representante de uma parte interessada relevante.
• Identificar uma ferramenta para suportar a gestão e o tratamento do risco;
• Definir e identificar quais os registos a criar e a manter (por exemplo: atas de reu-
niões, plano de acompanhamento da análise do risco, relatórios de progresso).
Todas estas decisões devem ser analisadas e aprovadas pela gestão de topo da organiza-
ção.
Podem ser identificados critérios de avaliação adicionais que poderão suportar a prioriza-
ção do tratamento dos riscos.
25
Critérios de impacto
A organização deverá definir quais os níveis de impacto que deverão suportar a sua gestão
do risco. O critério de impacto deve ser determinado em termos de grau de danos ou cus-
tos que um evento de segurança da informação tem para a organização.
Na identificação dos níveis de impacto a assignar aos riscos, a organização deverá ter em
atenção os seguintes indicadores:
A organização deve definir quais são os seus critérios de aceitação do risco. Deverá identifi-
car a partir de que nível do risco terá de ser necessária a aprovação da gestão de topo para
que o mesmo possa ser aceite.
A organização deve definir as suas próprias escalas de níveis de aceitação dos riscos. Na
definição dos critérios de aceitação do risco, a organização deve ter em consideração os
seguintes pontos:
• Os critérios de aceitação podem incluir diversos limites, existindo um nível do risco
aceitável, sendo que a aceitação dos riscos acima desse nível deve ser formalmen-
te aprovada pela gestão de topo;
• Os critérios de aceitação podem diferir de acordo com o seu tempo de vida. Por
exemplo, o risco pode estar associado a uma atividade temporária ou de curto
prazo, da organização.
Os critérios de aceitação devem ser estabelecidos considerando-se os seguintes fatores:
26
Definição de âmbito e fronteiras
• Edifício/Localização;
• Plataforma de infraestrutura;
• Plataforma aplicacional;
• Processos referentes à atividade da organização.
O que não estiver incluído no âmbito deverá ser formalmente justificado pela organização.
A fase de identificação é a primeira fase da etapa de levantamento dos riscos. Nesta fase,
dever-se-á identificar, reconhecer e descrever os riscos que possam criar constrangimentos
ou impedir a organização de atingir os seus objetivos.
O propósito da identificação é determinar as ocorrências que poderão causar uma poten-
cial perda à organização. Os passos descritos nas próximas etapas são essenciais para se
efetuar a coleta de dados para alimentar a análise do risco.
27
Identificação dos ativos
A organização deve identificar quais os ativos que suportam o âmbito definido na gestão do
risco de segurança da informação. Os ativos são tudo o que tem valor e que requer prote-
ção na ótica da organização.
Os ativos poderão ser (mas não só) das seguintes categorias:
A organização deve ter um inventário dos seus ativos com, pelo menos:
Identificar ameaças
Uma ameaça tem o potencial de poder criar impactos e consequências negativas nos ativos
da organização. Adicionalmente, esta pode ser de origem natural ou humana e pode ser
acidental ou deliberada.
A informação relativa à identificação de ameaças pode ser obtida das seguintes formas:
28
• Especialistas de segurança da informação;
• Especialistas de segurança física;
• Departamentos legais;
• Catálogo de ameaças.
Identificar controlos
No final desta atividade, a organização deverá ter uma lista de todos os controlos existentes
e planeados com o seu respetivo estado de implementação.
Identificação de vulnerabilidades
Com base na lista de ameaças e dos ativos (não esquecendo os controlos implementa-
dos), a organização deverá identificar uma lista de potenciais vulnerabilidades que poderão
ser associadas aos seus ativos. As vulnerabilidades podem ser identificadas nas seguintes
áreas:
29
• Organização;
• Processos e procedimentos;
• Rotinas de gestão;
• Colaboradores;
• Ambientes físicos;
• Configuração dos sistemas de informação;
• Hardware, software e equipamento de rede;
• Dependência com partes externas interessadas.
A existência de uma vulnerabilidade não causa danos por si só. Para que cause danos, é
necessário que exista uma ameaça que possa explorar essa mesma vulnerabilidade.
Uma vulnerabilidade pode não exigir a implementação de um controlo, mas deve ser co-
nhecida e monitorizada pela organização. Releva-se, que um controlo ou conjunto de con-
trolos que estejam incorretamente implementados podem traduzir-se em potenciais vul-
nerabilidades para a organização. A eficácia de um controlo depende do ambiente em que
o mesmo está a operar.
A organização pode identificar uma lista complementar de vulnerabilidades que não es-
tejam relacionadas com ameaças e/ou ativos concretos. Esta lista pode fazer parte da sua
base de dados de conhecimento de gestão do risco.
Identificação de impacto
A organização deve identificar as consequências dos riscos e aferir qual o impacto que a
possível exploração de uma vulnerabilidade por parte de uma ameaça, poderá ter em ter-
mos de confidencialidade, integridade e/ou disponibilidade dos ativos que se encontrem
no âmbito do processo de gestão do risco.
Um impacto deve ser avaliado em várias dimensões, nomeadamente (e não somente), na
geração de condições operacionais adversas, na perda de negócio por parte da organização
ou em danos de reputação e imagem.
Esta atividade identifica os danos ou impactos para a organização que podem ser causados
por um cenário de incidente. Um cenário de incidente pode ser originado pela exploração
de uma vulnerabilidade por parte de uma determinada ameaça ou por um conjunto de
ameaças a um sistema de informação.
O impacto dos cenários de incidentes deve ser determinado considerando-se os crité-
rios ponderadores que são definidos no estabelecimento do contexto. Uma determinada
ameaça pode ter impacto em um ou mais ativos, ou em partes de ativos.
Os ativos devem ter classificações atribuídas em função do seu valor para a organização,
mediante as consequências no seu negócio, no caso de estes serem danificados e/ou com-
prometidos. O impacto pode ser temporário ou permanente (como no caso da destruição
de um ativo).
O impacto do risco deverá ser identificado com base nas vulnerabilidades e ameaças as-
sociadas. Deve ser igualmente tido em atenção, na identificação do impacto, quais as con-
sequências para os ativos e, inerentemente, para os processos referentes à atividade da
organização que estes suportam.
30
Na aferição de impacto, a organização poderá identificar potenciais consequências opera-
cionais em termos de, mas não se limitando a:
31
Metodologia de análise
A metodologia de análise do risco pode ser consubstanciada por uma abordagem analítica
de caráter qualitativo, quantitativo ou por uma combinação de ambas. Na prática, a análise
qualitativa é mais utilizada, numa primeira abordagem, para a obtenção de indicadores
gerais do nível do risco e para identificar os riscos mais relevantes.
O método de análise deverá ser consistente com os critérios de avaliação do risco, defini-
dos na fase de definição de contexto do risco.
• Como uma atividade de triagem inicial para identificar os riscos que exigem uma
análise mais detalhada;
• Quando este tipo de análise é apropriado para a tomada de decisão;
• Quando os dados ou recursos numéricos são inadequados para uma análise quan-
titativa do risco.
Para execução desta fase, a organização deverá dispor de uma lista dos cenários de inciden-
tes relevantes, da identificação das ameaças e vulnerabilidades anteriormente analisadas,
dos ativos afetados e das respetivas consequências para esses ativos e para os processos
referentes à atividade da organização, inseridos no âmbito do processo de gestão do risco.
32
Deve ser avaliado o impacto nos serviços prestados pela organização que possam resultar
na ocorrência de incidentes de segurança. O levantamento do impacto deverá ser igual-
mente avaliado no contexto da perda de confidencialidade, integridade e/ou disponibilida-
de dos ativos em análise.
O impacto do risco deve ter como base as vulnerabilidades, as ameaças identificadas e as
respetivas consequências do risco nos ativos e processos referentes à atividade da organi-
zação.
O impacto pode ser avaliado em diversas perspetivas, nomeadamente, técnica, financeira,
humana, de imagem ou, por uma outra perspetiva não referida, mas que seja relevante
para a organização.
A avaliação dos ativos começa com a sua classificação, de acordo com a sua importância
para o cumprimento dos objetivos de negócio da organização. Pode ser determinada usan-
do duas medidas:
Análise de probabilidade
Com base nas ameaças, vulnerabilidades e listas de incidentes (incluindo lições aprendidas)
existentes, a organização deverá avaliar qual a probabilidade de ocorrência do risco.
Uma vez identificados os cenários de incidentes, incluindo identificação de ameaças, ati-
vos afetados, vulnerabilidades exploradas e o impacto para os ativos e para os processos
referentes à atividade da organização, deve ser tido em linha de conta a frequência da
ocorrência das ameaças e a facilidade com que as vulnerabilidades poderão ser exploradas,
considerando:
• Para fontes de ameaças acidentais: fatores geográficos, como por exemplo proxi-
midade com indústrias químicas ou petrolíferas, a possibilidade de condições cli-
máticas;
33
Determinação do nível do risco
Nesta fase, todos os riscos identificados deverão ter o seu nível determinado.
Assim que o plano de tratamento do risco seja definido, os riscos residuais necessitam de
ser determinados. Este processo envolve uma atualização ou uma nova iteração com a fase
de avaliação, tendo como base os efeitos esperados pelo tratamento do risco proposto.
Caso o risco residual ainda não cumpra com os critérios de aceitação do risco da organi-
34
zação, poderá ser necessária uma iteração adicional do tratamento do risco antes de se
proceder à aceitação do mesmo.
35
• Providenciar a garantia do resultado da gestão dos riscos da organização;
• Recolher informações do risco;
• Partilhar os resultados da avaliação dos riscos e apresentar o plano de tratamento
dos riscos;
• Evitar ou reduzir a ocorrência e o impacto das quebras de segurança da informação
devido à falta de entendimento mútuo entre quem toma as decisões e as partes
interessadas;
• Suportar as tomadas de decisão;
• Enriquecer os conhecimentos sobre as temáticas da segurança da informação na
organização;
• Coordenar com outras partes interessadas e planear respostas para reduzir o im-
pacto dos incidentes;
• Disponibilizar, a quem toma as decisões e às partes interessadas da organização,
uma demonstração de responsabilidade sobre os riscos;
• Melhorar a consciencialização sobre a importância do processo de gestão dos ris-
cos.
36
O resultado das atividades de monitorização pode ser inserido noutras atividades de re-
visão dos riscos. A organização deve efetuar a revisão de forma regular ou sempre que
ocorram alterações significativas.
3.5.10 Exemplo
João, responsável do Gabinete de Gestão de Projeto da Organização, identificou no seu pro-
cesso de análise do risco que existe uma elevada possibilidade de roubo das palavras-passe
dos utilizadores da plataforma de gestão de ficheiros, alojada num serviço de computação
em nuvem, que é utilizada pela organização para disponibilização de toda a documentação
gerada no âmbito da execução dos seus projetos.
O risco identificado por João, teve por base:
Durante o processo, identificou que a ameaça poderia ter efetivamente origem num ata-
que malicioso externo, levado a cabo tirando partido da vulnerabilidade anteriormente
identificada (política de palavras-passe deficiente) e, observou igualmente, que este vetor
de ataque poderia colocar em causa a confidencialidade e a integridade da informação que
se encontrava alojada neste ativo (plataforma de gestão de ficheiros).
João efetuou a avaliação de impacto com base na matriz sistematizada na metodologia
do risco da organização (1 – Pequeno, 2 – Moderado, 3 – Elevado, 4 – Catastrófico) tendo
atribuído um impacto “4 – Catastrófico” ao risco em causa.
De seguida, efetuou o exercício de avaliação da probabilidade de o risco ocorrer. Consultou
a metodologia e face às possibilidades apresentadas - 1 – Improvável, 2 – Provável, 3 – Mui-
to Provável, 4 – Quase certa - decidiu que a probabilidade seria “4 – Quase certa”.
Com base no cálculo do impacto e probabilidade, o nível do risco (resultado do produto en-
tre o impacto e a probabilidade) é 16. De esta forma, João concluiu que o risco identificado
é Muito Alto. Esta conclusão é sustentada nos critérios de identificação do nível do risco da
tabela de níveis, publicada no âmbito da metodologia de gestão do risco da organização:
a. [1; 2] – Nível baixo;
b. [3 a 6] – Nível Médio;
c. [8 a 12] – Alto;
d. [16] – Muito Alto.
Face ao nível identificado, a organização não o pode aceitar, uma vez que todos os riscos
de nível “Muito Alto” devem ser obrigatoriamente tratados, exceto se tiverem sido formal-
mente aceites pela Gestão de Topo. Nesse caso, a organização, na sua sessão de gestão do
risco, pode tomar a decisão estratégica de o mitigar e de executar as seguintes atividades:
37
1 Garantir que o fornecedor da plataforma de gestão de ficheiros altera a sua polí-
tica de gestão de palavras-passe em conformidade com as suas práticas internas,
no espaço de tempo a definir;
2 Avaliar outras plataformas que prestem o mesmo serviço, com as condições con-
sideradas como adequadas pela organização.
Foi igualmente identificada uma responsável (Inês – Diretora dos Sistemas de Informação)
pela execução das atividades, tendo sido igualmente acordada uma data estimada de reso-
lução. A data foi escolhida de acordo com as prioridades atribuídas aos riscos identificados,
tendo em conta o nível do risco e a criticidade dos ativos envolvidos.
Tabela de Resumo
CAMPOS VALORES
#ID 1
Descrição do Risco Possibilidade de acesso indevido a informação de projetos da organização
Ativo Plataforma de gestão de ficheiros
Responsável do Risco João – Responsável Gabinete de Gestão de Projeto
Ameaça Ataque malicioso de força bruta às palavras-passe
Vulnerabilidade Política de palavras-passe deficiente
Confidencialidade Sim
Integridade Sim
Disponibilidade Não
Impacto 4 – Catastrófico
Probabilidade 4 – Quase Certa
Nível do Risco 16 – Muito Alta
Estratégia Mitigar/Tratar
Ações - Garantir que o fornecedor da plataforma de gestão de ficheiros altere a sua polí-
tica de palavras-passe em conformidade com as suas práticas internas, no espaço
de tempo a definir;
- Avaliar plataformas que prestem o mesmo serviço, com as condições considera-
das como adequadas pela organização.
Responsável pelo tra- Inês – Responsável dos Sistemas de Informação
tamento de ações
Data do tratamento DD-MM-AAAA
38
3.6 Âmbito e aplicabilidade
O QNRCS tem aplicabilidade em todas as organizações públicas e privadas nacionais, no-
meadamente:
1 Administração Pública;
39
Passo 2 – Linhas orientadoras: Uma vez definido o âmbito do programa de ciberseguran-
ça, a organização identifica e define as redes e sistemas de informação e respetivos ati-
vos relacionados com a atividade, requisitos regulatórios e a estratégia de gestão do risco.
Adicionalmente, a organização identifica ameaças e vulnerabilidades aplicáveis aos ativos
previamente definidos.
Passo 3 – Criação do Perfil Atual: A organização cria aquele que é o seu “Perfil Atual”,
indicando para cada categoria e subcategoria quais os objetivos de segurança que cum-
pre atualmente. Caso cumpra parcialmente alguns dos objetivos, deve documentar esta
situação, por forma a consubstanciar o seu nível de maturidade e informação de base para
futura aferição.
Passo 4 – Aferição do risco: A Análise do risco pode ser guiada de acordo com o processo
de gestão do risco em vigor na organização, ou tendo por base ações anteriores. A organi-
zação analisa o seu ambiente operacional para aferir o grau de probabilidade de ocorrência
de um evento ou incidente de cibersegurança e o impacto que este possa ter na organiza-
ção. Este processo deve ter em linha de conta fontes de informação, internas e externas,
relativas a vulnerabilidades e ameaças emergentes, por forma a obter um melhor entendi-
mento quanto à probabilidade e impacto expetáveis.
Passo 5 – Criação do Perfil Alvo: A organização cria o seu “Perfil Alvo” com base nas cate-
gorias e subcategorias descritas no QNRCS, refletindo aqueles que são os resultados pre-
tendidos. A organização poderá definir as suas próprias categorias e subcategorias, por
forma a melhor endereçar as características e riscos particulares inerentes à sua atividade.
Por outro lado, a organização também poderá considerar contributos e requisitos de inter-
venientes externos, tais como outras entidades do setor e fornecedores.
40
Este universo de partes interessadas está compreendido no ecossistema de cibersegu-
rança, relevante para a prestação dos bens ou serviços da organização. Considerando as
categorias e subcategorias estabelecidas no QNRCS, bem como os perfis definidos, estão
identificados os mecanismos contextuais, processuais e semânticos conducentes a uma
comunicação acessível e facilmente aferida pelo ecossistema.
2 Medidas de segurança.
41
As medidas de segurança traduzem-se em categorias que se dividem em subcategorias.
A cada objetivo de segurança, pode corresponder uma ou mais categorias. A cada categoria
pode corresponder uma ou mais subcategorias.
A cada subcategoria está associado um ou mais controlos ou referências. O objetivo passa
por interligar cada uma das subcategorias a referenciais de boas práticas de segurança da
informação e de cibersegurança, por intermédio de um conjunto de práticas de referência
e de maior aceitação/popularidade em Portugal.
Para cada subcategoria, referencia-se um exemplo de implementação tecnológica e ou-
tro de implementação processual, consistindo numa descrição genérica de como pode ser
aplicado, contribuindo, desse modo, para uma melhor compreensão da aplicabilidade do
mesmo. São ainda referenciados exemplos genéricos de possíveis evidências que podem
ser utilizadas na demonstração da aplicação de determinada medida de segurança.
O Catálogo de controlos críticos de cibersegurança (CSC) é publicado pelo Center for Inter-
net Security (CIS1). Este catálogo disponibiliza uma lista de ações, priorizada, que é regular-
mente revista pela comunidade académica, de forma a ser utilizável pelas organizações.
¹ https://www.cisecurity.org
42
COBIT 5
ISO/IEC 27001:2013
A norma ISO/IEC 270012 especifica os requisitos para estabelecer, implementar, operar,
monitorizar, rever, manter e melhorar um sistema de gestão de segurança da informação,
bem como os requisitos para os controlos de segurança a serem implementados, de acor-
do com as necessidades e realidade da organização.
3.8 Contextualização
QNRCS pretende ser aplicável, essencialmente, a organizações que assentem a sua ativi-
dade em tecnologia, quer seja numa perspetiva de cibersegurança para Tecnologias de
Informação, de controlos de sistemas industriais, sistemas de interface homem-máquina,
dispositivos IoT ou, de uma forma mais generalista, todos os dispositivos conectados de
alguma forma a redes e sistemas de informação.
A estrutura apresentada é uma proposta de um conjunto de práticas de segurança da infor-
mação para a cibersegurança. Reforça-se o aspeto de que, no âmbito da aplicação voluntá-
ria, qualquer organização é livre para definir o que deseja implementar, quais as medidas
de segurança a implementar ou outros atributos adicionais que entenda como relevantes,
de acordo com o seu tipo de atividade, dimensão e perfil do risco associado.
A título de exemplo, apresentam-se algumas situações em que se pode justificar a adapta-
ção/aplicação do QNRCS numa organização:
1 Um regulador definir o contexto de aplicação no seu setor de atividade, selecio-
nando subcategorias e definindo as medidas de segurança que considere apro-
priados para cada subcategoria, de acordo com um perfil de risco genérico asso-
ciado, na sua área de atuação;
² https://www.isaca.org/
3 https://www.iso.org/isolec-27001-information-security.html
⁴ https://www.nist.gov/
43
3 Ferramenta de suporte para identificar um conjunto de práticas que podem ser
implementadas pelas partes interessadas da organização;
4 Uma organização pode identificar no QNRCS possíveis práticas que podem ser
transformadas em requisitos contratuais que visem a melhoria das relações de
troca de bens e serviços entre as organizações, enquadradas na temática da segu-
rança da informação e cibersegurança.
44
4.1 Objetivos de segurança
Também a utilização do QNRCS deve ser feita numa perspetiva de melhoria contínua. Não
deve ser efetuada uma utilização estática das práticas identificadas no QNRCS mas, sim,
evoluir de acordo com a maturidade da organização e o seu contexto.
No quadro seguinte concretizam-se os objetivos de segurança propostos:
OBJETIVO DESCRIÇÃO
Identificar Compreensão do contexto da organização, dos ativos que suportam os proces-
sos críticos da atividade da organização e dos riscos associados relevantes. Esta
compreensão permite que a organização consiga definir e priorizar os seus re-
cursos e investimentos de acordo com os seus objetivos gerais e com a sua es-
tratégia de gestão do risco.
Proteger Implementação de medidas destinadas a proteger os processos organizativos e
os ativos da organização, independentemente da sua natureza tecnológica. As-
sim, nesta categoria, são definidas medidas orientadas à proteção da organização
nas suas três dimensões: Pessoas, Processos e Tecnologia.
Detetar Definição e implementação de medidas destinadas a identificar, de forma atem-
pada, os incidentes. Ou seja, a deteção de eventos com um efeito adverso real
na segurança das redes e dos sistemas de informação.
46
OBJETIVO DESCRIÇÃO
Responder Definição e implementação de medidas de ação apropriadas, em caso de dete-
ção de um incidente. As medidas propostas no âmbito deste objetivo pretendem
mitigar o impacto do incidente, ou seja, reduzir os seus potenciais efeitos adver-
sos.
Recuperar Definição e implementação de atividades que visam a gestão de planos e me-
didas de recuperação dos processos e serviços afetados por um incidente de
cibersegurança. As medidas pertencentes a este objetivo pretendem assegurar a
resiliência da organização nas suas dimensões Pessoas, Processos e Tecnologia.
E que, no caso de existência de um incidente, a organização consiga utilizar as
medidas para suporte à recuperação em tempo útil da sua atividade.
4.2.1. Identificar
Pretende-se estabelecer um entendimento, transversal à organização, para a abordagem
à gestão do risco de cibersegurança no contexto da envolvência das suas redes e sistemas
de informação, pessoas, ativos, dados e respetivas capacidades. As práticas que se enqua-
dram no objetivo Identificar são basilares para a efetiva utilização do QNRCS. Conhecer,
num contexto organizacional, os recursos que suportam as suas funções importantes e
os respetivos riscos associados, permite à organização priorizar os seus esforços de forma
consistente.
Descreve-se, no quadro seguinte, as categorias existentes com a identificação das respeti-
vas subcategorias associadas.
47
CATEGORIA DESCRIÇÃO SUBCATEGORIAS
ID.GA A organização deve identificar os dados, colaboradores, equi- ID.GA-1
pamentos, sistemas e instalações que permitem cumprir os
Gestão de ID.GA-2
ativos
seus objetivos no decorrer da sua atividade. Devem ser iden-
tificados e geridos de forma consistente com aquela que é a ID.GA-3
sua relevância no cumprimento dos objetivos da organização e
com a estratégia de gestão do risco. ID.GA-4
ID.GA-5
4.2.2 Proteger
Pretende-se, como resultado do objetivo Proteger, proporcionar o desenvolvimento e a
implementação das salvaguardas necessárias à garantia de prestação de serviços ou bens,
suportando e reforçando a capacidade de a organização limitar ou conter o impacto de
eventual ocorrência de um incidente de cibersegurança.
Esta capacidade suporta-se, entre outras, na gestão da identidade eletrónica e respetivas
autorizações, na realização de ações de formação e de sensibilização e na definição e im-
48
plementação de procedimentos, processos e tecnologias de proteção da informação.
Descreve-se, no quadro seguinte, as categorias existentes com a identificação das respeti-
vas subcategorias associadas.
49
CATEGORIA DESCRIÇÃO SUBCATEGORIAS
PR.MA A manutenção e reparação das redes e sistemas de informação PR.MA-1
deve ser realizada em concordância com as políticas, processos
Manutenção PR.MA-2
e procedimentos instituídos.
PR.TP As soluções técnicas de segurança devem ser geridas por for- PR.TP-1
ma a garantir a confidencialidade, integridade e disponibilida-
Tecnologia de PR.TP-2
proteção
de das redes e sistemas de informação, em concordância com
as políticas relacionadas, processos, procedimentos e acordos PR.TP-3
relevantes.
PR.TP-4
PR.TP-5
4.2.3 Detetar
No contexto do objetivo Detetar, pretende-se desenvolver práticas adequadas e atempa-
das à deteção da ocorrência de eventos de cibersegurança, por via da monitorização con-
tínua das redes e sistemas de informação e da implementação de processos de deteção.
Descrevem-se, no quadro seguinte, as categorias existentes com a identificação das respe-
tivas subcategorias associadas.
50
4.2.4 Responder
4.2.5 Recuperar
51
ma a reduzir os impactos do incidente ocorrido. Entre outras, promove-se a execução de
planos de continuidade de negócio, de recuperação, da execução de exercícios de simula-
ção de situações de crise e de atualizações dos planos com vista à melhoria dos mesmos.
Descrevem-se, no quadro seguinte, as categorias com a identificação das respetivas subca-
tegorias associadas.
Identificar
52
4.3.1 ID.GA Gestão de Ativos
R.N. CIS CSC 1; ID.GA-1 - Os dispositivos físicos, redes e sistemas de informação existentes na
COBIT 5 BAI09.01,
BAI09.02;
organização devem ser inventariados
ISO/IEC
27001:2013
A.8.1.1, A.8.1.2;
Descrição
NIST SP 800-53
Rev. 4 CM-8,
PM-5.
A organização deve inventariar os seus dispositivos físicos, redes e sistemas de informação
existentes, por forma a garantir que existe um mapeamento estruturado dos mesmos. To-
dos os dispositivos e sistemas inventariados devem ser classificados de acordo com a sua
relevância para a organização.
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos.
Implementação Processual
A organização deve efetuar o inventário dos seus equipamentos de acordo com as seguin-
tes regras:
1 Os dispositivos físicos e sistemas devem ser inventariados com a seguinte infor-
mação:
a. Número de inventário;
b. Nome do equipamento;
c. Número de série;
d. Localização.
Evidências
1 Inventário atualizado dos ativos com:
a. Informação de inventário;
b. Identificação dos responsáveis pelos ativos;
c. Classificação dos ativos em função da sua criticidade.
54
R.N. CIS CSC 2; ID.GA-2 - As aplicações e plataformas de software que suportam os processos
COBIT 5 BAI09.01,
BAI09.02,
dos serviços críticos devem ser inventariadas
BAI09.05;
ISO/IEC
27001:2013 Descrição
A.8.1.1, A.8.1.2,
A.12.5.1; As aplicações e plataformas de software da organização, que suportam os processos dos
NIST SP 800-53 serviços críticos, devem ser inventariadas e classificadas de acordo com a sua relevância
Rev. 4 CM-8,
PM-5. para a organização
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos.
Implementação Processual
A organização deve elaborar o inventário de todas as suas aplicações, identificando:
1 Informação necessária ao inventário de uma aplicação;
Evidências
1 A organização deve possuir um inventário atualizado de todas as suas aplicações
e plataformas de software, com a identificação da sua criticidade e dos seus res-
ponsáveis.
a. Informação de inventário;
b. Identificação dos responsáveis;
c. Classificação das aplicações ou plataformas de software ou em função da
sua criticidade.
R.N. CIS CSC 2; ID.GA-3 - As redes e fluxos de dados devem ser mapeados
COBIT 5 DSS05.2;
ISO/IEC
27001:2013
A.13.2.1, A.13.2.2; Descrição
NIST SP 800-53
Rev. 4 AC-4, CA-3, A organização deve possuir um inventário com todas as suas redes de comunicações e o
CA-9, PL-8. mapeamento dos seus fluxos de comunicação internos e externos. Esta informação é es-
sencial para que a organização tenha conhecimento dos ativos que suportam a sua infraes-
trutura de comunicações e dos respetivos fluxos de comunicação existentes.
55
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos.
Implementação Processual
A organização deve executar as seguintes atividades:
1 Inventariar os seus ativos de rede de comunicações;
Evidências
1 A organização deve apresentar:
a. Registos do inventário dos ativos de rede de comunicações;
b. Lista dos fluxos de comunicação entre os seus sistemas internos e siste-
mas de partes interessadas externas;
c. Mapeamentos de informação;
d. Documentos que identifiquem os procedimentos de transferência segura
de informação.
R.N. COBIT 5 ID.GA-4 - As redes e sistemas de informação externos devem ser identificados
APO02.02,
APO10.04,
e catalogados
DSS01.02;
ISO/IEC
27001:2013 Descrição
A.11.2.6;
NIST SP 800-53 As redes e sistemas de informação da organização, que se encontram no exterior das suas
Rev. 4 AC-20,
instalações físicas, devem ser identificados e catalogados para que a organização tenha
SA-9.
conhecimento da localização dos seus ativos.
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos.
Implementação Processual
A organização deve possuir um mapeamento das suas redes e sistemas de informação
que se encontram no exterior, identificando pelo menos:
56
1 Número de inventário;
2 Tipo de equipamento;
3 Descrição;
4 Localização;
Evidências
1 A organização deve possuir um inventário atualizado dos seus ativos de rede e
sistemas de informação externos.
R.N. CIS CSC 13, ID.GA-5 - Os ativos necessários para a prestação de bens e serviços devem ser
14; classificados
COBIT 5
APO03.03,
APO03.04, Descrição
APO12.01,
BAI04.02,
BAI09.02;
A organização deve classificar os seus ativos (humanos, tecnológicos de hardware e sof-
ISO/IEC
tware, dispositivos, dados, tempo e aplicações), de acordo com a criticidade e valor que
27001:2013 estes ativos representem para si. No processo de inventariação, a organização deve:
A.8.2.1;
NIST SP 800-53 1 Identificar um método de classificação de ativos que seja aprovado internamente;
Rev. 4 CP-2, RA-2,
SA-14, SC-6.
2 Garantir que os responsáveis pelos ativos os classificam de acordo com a impor-
tância dos mesmos para a organização.
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos.
Implementação Processual
A organização deve garantir que:
1 A classificação dos ativos é efetuada de acordo com a sua importância para a ati-
vidade da organização;
Evidências
1 Registos da classificação dos ativos.
57
4.3.2 ID.AO Ambiente da Organização
R.N. COBIT 5 ID.AO-1 - O papel da organização na cadeia logística deve ser identificado e co-
APO08.01, municado
APO08.04,
APO08.05,
APO10.03,
APO10.04,
APO10.05;
Descrição
ISO/IEC A organização deve ter a capacidade de identificar e tipificar os seus fornecedores na ca-
27001:2013
A.15.1.1, A.15.1.2, deia logística e de acordo com as prestações contratualizadas com os mesmos.
A.15.1.3, A.15.2.1,
A.15.2.2;
NIST SP 800-53
Rev. 4 CP-2, SA-12.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve definir uma política de gestão de fornecedores que estabeleça crité-
rios orientadores quanto aos procedimentos, comportamentos e modos de agir, que de-
vem ser adotados nos processos de contratação e de gestão de fornecedores.
Após o processo de contratualização, deve ser registado:
1 A identificação do fornecedor;
3 Os serviços:
a. Essenciais e permanentes (por exemplo: segurança física das instalações,
limpeza, conservação patrimonial, entre outros);
b. Eventuais, para exercer atividade de curta duração (por exemplo: ma-
nutenção de impressoras, pequenos arranjos, manutenção hardware,
entre outros);
Evidências
1 Documentos de suporte à política de gestão de fornecedores;
58
R.N. COBIT 5 ID.AO-2 - O posicionamento da organização no seu setor de atividade deve
APO02.06, ser identificado e comunicado
APO03.01;
ISO/IEC
27001:2013 Cláu-
sula 4.1; Descrição
NIST SP 800-53
Rev. 4 PM-8. A organização deve ser capaz de:
1 Identificar o seu enquadramento no respetivo setor de atividade;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve identificar, na sua política de segurança da informação, a sua missão,
objetivos e partes interessadas.
A organização deve efetuar uma análise SWOT nos contextos externo e interno, que identi-
fique os seus pontos fortes, pontos fracos, oportunidades e ameaças.
Evidências
Documento da política de segurança da informação na organização, que deve incluir:
1 Identificação da visão, missão e objetivos de segurança da informação;
3 Análise SWOT.
R.N. COBIT 5 ID.AO-3 - A missão, visão, valores, estratégias e objetivos da organização devem
APO02.01, ser definidas e comunicadas
APO02.06,
APO03.01;
NIST SP 800-53
Rev. 4 PM-11,
Descrição
SA-14.
A missão, visão, valores, estratégias e objetivos são os princípios fundamentais de orienta-
ção de uma organização. Indicam a forma como esta se posiciona no seu setor de atividade
e como procura ser reconhecida pelos colaboradores, clientes, fornecedores e outras or-
ganizações terceiras.
59
Implementação Técnica
Não aplicável.
Implementação Processual
1 Documentar a missão, visão, valores e objetivos da organização;
Evidências
1 Documentos de suporte à política de segurança da informação, com a identifica-
ção da visão, missão, objetivos e partes interessadas, internas e externas, à orga-
nização.
Implementação Técnica
1 Ferramentas/aplicações de gestão de ativos;
Implementação Processual
A organização deve efetuar a identificação e o registo dos ativos que suportam os seus
serviços críticos, seguindo as diretrizes indicadas em ID.GA-1, bem como acautelar a sua
capacidade e respetiva redundância em caso de falha. Exemplo de redundâncias:
60
1 UPS de suporte;
3 Sistema AVAC;
Evidências
1 Documentos e registos de ativos de suporte primários e respetiva capacidade;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Identificar cenários de crise;
¹ Ver ISO/IEC 22301 - Society security -- Business continuity management systems -- Requirements
61
b. Identificar os planos de testes de recuperação adequados.
Evidências
1 Documentos de suporte à estratégia de proteção contra desastres naturais e ata-
ques maliciosos;
R.N. CIS CSC 19; ID.GV-1 - A política de segurança da informação deve ser definida e comunicada
COBIT 5
APO01.03,
APO13.01,
EDM01.01, Descrição
EDM01.02;
ISO/IEC A organização deve:
27001:2013
A.5.1.1; 1 Definir a sua política de segurança da informação;
NIST SP 800-53
Rev. 4 -1 todos
os controlos de
2 Garantir o compromisso da gestão de topo na aprovação da política de segurança
segurança. da informação;
Implementação Técnica
Efetuar a publicação da política de segurança da informação em repositório de fácil acesso
a todos os colaboradores da organização. Exemplos de locais para alojamento e publicação:
1 Intranet;
Implementação Processual
A organização deve garantir que a sua política de segurança da informação:
1 Identifica qual a base que conduziu à sua definição;
62
Evidências
1 Documento com a política de segurança da informação;
R.N. CIS CSC 19; ID.GV-2 - Os requisitos legais e regulamentares para a cibersegurança devem ser
COBIT 5 BAI02.01, cumpridos
MEA03.01,
MEA03.04;
ISO/IEC Descrição
27001:2013
A.18.1.1, A.18.1.2, A organização deve garantir que cumpre as leis e regulamentos de cibersegurança, de acor-
A.18.1.3, A.18.1.4, do com a legislação nacional e europeia em vigor. Para esse efeito, deve definir-se quais são
A.18.1.5;
os requisitos legais, regulamentares e contratuais nacionais e europeus que necessitam de
NIST SP 800-53
Rev. 4 -1 todos
ser observados e seguidos.
os controlos de
segurança.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Identificar, na sua política de segurança da informação, as conformidades legais
(nacionais e europeias) aplicáveis e as garantias de proteção de propriedade inte-
lectual;
Evidências
1 Documento com a lista de requisitos legais, regulamentares e contratuais;
63
4.3.4 ID.AR Avaliação do Risco
R.N. CIS CSC 4; ID.AR-1 - As vulnerabilidades dos ativos devem ser identificadas e documentadas
COBIT 5
APO12.01,
APO12.02,
APO12.03, Descrição
APO12.04,
DSS05.01, Uma das bases da avaliação do risco da organização deve ser o processo de gestão de vul-
DSS05.02;
nerabilidades. Nomeadamente, todas as vulnerabilidades conhecidas que não foram miti-
ISO/IEC
27001:2013
gadas e/ou solucionadas.
A.12.6.1, A.18.2.3;
Estas vulnerabilidades devem ser avaliadas em sede de análise do risco da organização e
NIST SP 800-53
Rev. 4 CA-2, CA-7, deve ser formalmente definida qual a estratégia a aplicar, respeitando a metodologia de
CA-8, RA-3, RA-5, gestão e risco da organização.
SA-5, SA-11, SI-2,
SI-4, SI-5.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve garantir que no seu processo de análise do risco:
1 Efetua a tipificação de vulnerabilidades dos seus ativos que possam ser explora-
das por possíveis ameaças;
Evidências
1 Documentos de suporte à gestão do risco;
R.N. CIS CSC 4; ID.AR-2 - A organização deve partilhar informações sobre ameaças de ciberse-
COBIT 5 BAI08.01; gurança com grupos de interesse da especialidade
ISO/IEC
27001:2013
A.6.1.4;
NIST SP 800-53
Descrição
Rev. 4 SI-5, PM-
15, PM-16. A organização deve estabelecer contacto com grupos de interesse sobre a temática da se-
gurança da informação, para que possa trocar experiências sobre boas práticas e ter acesso
a informações relevantes sobre segurança da informação.
As informações sobre ameaças de cibersegurança podem ser recolhidas junto de fóruns ou
em fontes de partilha de informações da especialidade.
64
Implementação Técnica
Caso as fontes de partilha de informação sejam de formato eletrónico e passíveis de ser
consumidas por interfaces aplicacionais, devem ser sistematizados processos automáticos
de recolha, tratamento e armazenamento das mesmas, para posterior correlação pelos
sistemas de gestão de eventos.
Implementação Processual
A organização deve:
1 Estabelecer contactos com grupos de interesse e especialistas técnicos;
2 Ter acesso a:
a. Bases de dados e a listas de distribuição sobre vulnerabilidades e corre
ções;
b. Fontes públicas e/ou privadas de conhecimento sobre ameaças.
Evidências
1 Registo estruturado de contactos estabelecidos com grupos de interesse, listas de
distribuição e especialistas técnicos;
R.N. CIS CSC 4; ID.AR-3 - As ameaças internas e externas devem ser identificadas e documenta-
COBIT 5 das na metodologia de gestão do risco
APO12.01,
APO12.02,
APO12.03,
APO12.04; Descrição
ISO/IEC
27001:2013 Cláu- No âmbito do processo de gestão do risco, a organização deve identificar e documentar
sula 6.1.2; as possíveis ameaças que possam explorar vulnerabilidades eventualmente existentes nos
NIST SP 800-53 seus ativos.
Rev. 4 RA-3, SI-5,
PM-12, PM-16.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve, em sede de análise do risco, identificar as ameaças que possam colo-
car em causa a integridade, confidencialidade ou disponibilidade dos seus ativos.
65
Evidências
1 Documentos que suportem a metodologia de gestão do risco;
R.N. CIS CSC 4; ID.AR-4 - A gestão do risco deve ser efetuada com base na análise de ameaças,
COBIT 5 vulnerabilidades, probabilidades e impactos
APO12.02;
ISO/IEC
27001:2013
A.12.6.1; Descrição
NIST SP 800-53
Rev. 4 RA-2, RA-3, A organização deve identificar, na sua metodologia de gestão do risco, quais os critérios
PM-16. associados à aferição de probabilidade e impacto dos riscos, por forma a calcular o nível
do risco associado. As vulnerabilidades e ameaças devem ser tidas em linha de conta no
processo de identificação dos riscos.
Implementação Técnica
Não aplicável.
Implementação Processual
Devem ser identificados, na metodologia de gestão do risco, os níveis de impacto e de
probabilidade a serem considerados. Estas identificações são essenciais para a aferição da
severidade associada aos riscos a analisar.
A identificação do valor do ativo poderá ser importante para a definição das prioridades de
tratamento dos riscos.
A introdução de uma função para o cálculo do nível do risco, torna menos subjetiva e mais
consistente a avaliação do mesmo.
Fatores críticos para a função:
1 Impacto;
2 Probabilidade;
66
Evidências
1 Documentos que suportem a metodologia de gestão do risco, garantindo a identi-
ficação de:
a. Níveis de impacto;
b. Níveis de probabilidade;
a. Importância do ativo para a organização (se aplicável);
b. Função para cálculo do nível do risco.
R.N. CIS CSC 4; ID.AR-5 - A organização deve garantir que as respostas aos riscos são identifica-
COBIT 5 das e priorizadas
APO12.05,
APO13.02;
ISO/IEC
27001:2013 Cláu- Descrição
sula 6.1.3;
NIST SP 800-53 A organização deve definir a resposta adequada ao nível do risco encontrado. A prioridade
Rev. 4 PM-4, de tratamento dos riscos deve ser definida de acordo com o nível do risco observado e a
PM-9.
criticidade do ativo para a organização.
Implementação Técnica
Não aplicável.
Implementação Processual
A metodologia de análise e tratamento do risco da organização deve contemplar:
1 A definição da estratégia de resposta aos riscos;
Evidências
1 Documento de suporte à metodologia de gestão do risco, com a definição da res-
posta e priorização dos riscos;
67
4.3.5 ID.GR Estratégia de Gestão do Risco
R.N. CIS CSC 4; ID.GR-1 - A organização deve definir um processo de gestão do risco
COBIT 5
APO12.04,
APO12.05,
APO13.02, Descrição
BAI02.03,
BAI04.02;ISO/IEC A organização deve garantir que o seu processo de gestão do risco se encontra devidamen-
27001:2013 Cláu- te definido e gerido, assim como, acordado entre as partes interessadas relevantes.
sula 6.1.3;
ISO/IEC A organização deve definir, no âmbito da gestão do risco:
27001:2013 Clau-
se 6.1.3, Clause
8.3, Clause 9.3;
1 Uma estratégia compreensiva de gestão dos riscos associados com a utilização e
NIST SP 800-53 operação das redes e sistemas de informação;
Rev. 4 PM-9.
2 Procurar que a estratégia definida seja seguida de forma consistente por toda a
organização;
Implementação Técnica
A organização deve suportar-se em sistemas de informação orientados para a gestão do
risco.
Implementação Processual
1 A organização deve definir uma estratégia de governação para riscos, que garanta
a gestão de todo o ciclo de vida dos mesmos;
4 Deve ser consistente por toda a organização e identificada de forma não ambígua:
a. A estratégia de tolerância ao risco, aceite e assumida pela organização;
b. As metodologias de definição, avaliação e tratamento dos riscos;
c. A metodologia de monitorização da evolução dos riscos ao longo do
tempo.
Evidências
1 Documento com a definição da estratégia de identificação, avaliação e tratamento
dos riscos.
68
R.N. COBIT 5 ID.GR-2 - A organização deve determinar e identificar a sua tolerância ao risco
APO12.06;
ISO/IEC
27001:2013 Cláu-
sula 6.1.3, Cláusu- Descrição
la 8.3;
NIST SP 800-53
A organização deve definir, na sua metodologia de gestão do risco, a sua estratégia de tra-
Rev. 4 PM-9. tamento do risco, tendo em consideração os níveis dos riscos existentes e a sua tolerância
ao risco.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve identificar, na sua metodologia de gestão do risco:
Evidências
1 Documento que suporta a metodologia de gestão do risco.
R.N. COBIT 5 ID.GR-3 - A organização deve definir a sua estratégia de tratamento do risco
APO12.02;
ISO/IEC
27001:2013 Cláu-
sula 6.1.3, Cláusu- Descrição
la 8.3;
NIST SP 800-53 A organização deve definir a resposta de tratamento do risco a aplicar aos seus ativos críti-
Rev. 4 SA-14, PM- cos, tendo em conta a sua tolerância ao risco, de acordo com o seu papel no seu setor de
8, PM-9, PM-11.
atividade.
Implementação Técnica
Não aplicável.
Implementação Processual
Na metodologia de gestão do risco, deve ser identificada a estratégia de respostas aos
riscos associados aos ativos críticos observados. As respostas para tratamento do risco da
organização devem ser:
69
1 Evitar o risco – Colocar a probabilidade ou impacto tendencialmente próximo de
zero, tornando mais difícil a sua ocorrência e/ou eliminar totalmente o seu impac-
to;
Evidências
1 Documento que suporta a metodologia de gestão do risco.
R.N. CIS CSC 4; ID.GL-1 - A organização deve definir, avaliar e gerir processos de gestão do risco
COBIT 5 da cadeia logística
APO10.01,
APO10.04,
APO12.04,
APO12.05,
APO13.02, Descrição
BAI01.03,
BAI02.03, A organização deve garantir que efetua uma análise às partes interessadas pertencentes
BAI04.02; à sua cadeia logística, utilizando a mesma metodologia de análise e de gestão interna do
ISO/IEC risco.
27001:2013
A.15.1.1, A.15.1.2,
A.15.1.3, A.15.2.1,
A.15.2.2;
NIST SP 800-53
Rev. 4 SA-9, SA-12, Implementação Técnica
PM-9.
Não aplicável.
Implementação Processual
Na política de gestão de fornecedores, a organização deve identificar:
1 Os responsáveis internos pela execução da análise do risco;
Evidências
1 Documento de suporte à política de gestão de fornecedores.
70
R.N.COBIT 5 ID.GL-2 - A organização deve avaliar o risco da cadeia logística de cibersegurança
APO10.01,
APO10.02,
APO10.04,
APO10.05,
APO12.01, Descrição
APO12.02,
APO12.03,
APO12.04,
Os fornecedores de redes e sistemas de informação, componentes e serviços de ciberse-
APO12.05, gurança, devem ser identificados, priorizados e avaliados, recorrendo a um processo de
APO12.06, avaliação do risco da cadeia logística de cibersegurança.
APO13.02,
BAI02.03; A organização deve categorizar os seus fornecedores, tendo em conta:
ISO/IEC
27001:2013 1 A exposição da sua informação aos fornecedores;
A.15.2.1, A.15.2.2;
NIST SP 800-53
Rev. 4 RA-2, RA-3,
2 O impacto na cadeia logística;
SA-12, SA-14, SA-
15, PM-9. 3 O tipo de bens e serviços fornecidos.
Implementação Técnica
Não aplicável.
Implementação Processual
A categorização geral dos fornecedores deve ser efetuada na política de gestão de forne-
cedores.
Os fornecedores devem ser categorizados por níveis, de acordo com a exposição da infor-
mação da organização perante os mesmos.
A organização deve efetuar a categorização dos seus fornecedores, identificando a seguinte
informação:
1 Nome do fornecedor;
4 Nível de exposição:
a. Confidencialidade;
b. Integridade;
c. Disponibilidade.
Evidências
1 Política de gestão de fornecedores, com a identificação das regras de categoriza-
ção dos fornecedores;
71
R.N. COBIT 5 ID.GL-3 - Os contratos com fornecedores devem respeitar o plano de gestão do
APO10.01, risco para a cadeia logística
APO10.02,
APO10.03,
APO10.04,
APO10.05;
Descrição
ISO/IEC
27001:2013 A organização deve garantir que os seus fornecedores cumprem as suas regras de trata-
A.15.1.1, A.15.1.2,
A.15.1.3; mento e segurança da informação.
NIST SP 800-53
Rev. 4 SA-9, SA-11,
Os contratos com fornecedores devem ser utilizados para implementar medidas adequa-
SA-12, PM-9. das, de modo a garantir o cumprimento dos objetivos da política de segurança da infor-
mação da organização e do plano de gestão do risco para a cadeia logística.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve garantir que a sua política de gestão de fornecedores contempla a
obrigatoriedade de:
1 Inclusão de cláusulas de confidencialidade nos contratos estabelecidos com for-
necedores;
3 Restantes fornecedores.
Evidências
1 Política de gestão de fornecedores, com a identificação das regras contratuais e
de colaboração da organização com os seus fornecedores.
72
ISO/IEC Os fornecedores devem ser periodicamente avaliados por meio de auditorias, resultados
27001:2013
A.15.2.1, A.15.2.2; de testes ou outras formas de avaliação, para que a organização verifique se estão a cum-
NIST SP 800-53 prir com as suas obrigações contratuais, as quais devem incluir medidas de ciberseguran-
Rev. 4 AU-2, AU-6, ça.
AU-12, AU-16, PS-
7, SA-9, SA-12.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve identificar na sua política de gestão de fornecedores:
1 O plano de auditoria;
Evidências
1 Documentos de suporte da política de gestão de fornecedores;
R.N. CIS CSC ID.GL-5 - O plano de resposta e recuperação de desastre deve ser exercitado
19;20; com o acompanhamento de fornecedores
COBIT 5 DSS04.04;
ISO/IEC
27001:2013
A.17.1.3; Descrição
NIST SP 800-53
Rev. 4 CP-2, CP-4,
A organização deve identificar quais dos seus fornecedores devem participar nos seus pla-
IR-3, IR-4, IR-6, nos de resposta e recuperação e garantir que os mesmos são envolvidos nos testes e nos
IR-8, IR-9. exercícios planeados.
Implementação Técnica
Não aplicável.
73
Implementação Processual
A organização deve garantir que:
1 Identifica na lista de fornecedores se o mesmo faz parte de um plano de resposta
e/ou de recuperação e, em caso afirmativo, qual o plano associado;
74
4.4.1 PR.GA Gestão de Identidades, Autenticação e Controlo de Acessos
R.N. CIS CSC 1, 5, PR.GA-1 - O ciclo de vida de gestão de identidades deve ser definido
15, 16;
COBIT 5 DSS05.04,
DSS06.03;
ISO/IEC Descrição
27001:2013
A.9.2.1, A.9.2.2, A organização deve garantir que as identidades e credenciais de acesso às suas redes e
A.9.2.3, A.9.2.4, sistemas de informação são emitidas, geridas, verificadas, revogadas e auditadas em con-
A.9.2.6, A.9.3.1,
A.9.4.2, A.9.4.3;
formidade com os processos instituídos.
NIST SP 800-53
Rev. 4 AC-1, AC-2,
IA-1, IA-2, IA-3, IA-
4, IA-5, IA-6, IA-7,
IA-8, IA-9, IA-10,
IA-11. Implementação Técnica
1 Sistema de informação para a gestão de identidades e acessos;
Implementação Processual
A organização deve criar, disseminar, rever e atualizar:
1 Processo de gestão de acessos a ativos da organização;
76
Evidências
1 Documentação de suporte ao processo de gestão do ciclo de vida dos utilizado-
res;
2 Catálogo de acessos aos ativos da organização;
R.N. COBIT PR.GA-2 - Devem existir controlos de acesso físico às redes e sistemas de infor-
5 DSS01.04, mação
DSS05.05;
COBIT 5 DSS04.04;
ISO/IEC
27001:2013 Descrição
A.11.1.1, A.11.1.2,
A.11.1.3, A.11.1.4, A organização deve proteger e gerir o acesso físico às suas infraestruturas de rede e de
A.11.1.5, A.11.1.6,
sistemas de informação.
A.11.2.1, A.11.2.3,
A.11.2.5, A.11.2.6,
A.11.2.7, A.11.2.8; A organização deve aplicar este controlo aos seus colaboradores e visitantes, a zonas da
NIST SSP 800-53 organização que sejam de acesso restrito e/ou a áreas sensíveis que alojem informação
Rev. 4 PE-2, PE-3, confidencial, redes e/ou sistemas de informação.
PE-4, PE-5, PE-6,
PE-8.
Implementação Técnica
A organização deve:
1 Efetuar o controlo de acessos baseado em cartões magnéticos (ou utilizando
outro método de autenticação equivalente) e criando barreiras de acesso com
torniquetes e/ou portas de segurança que restrinjam o acesso às zonas que se
pretende proteger;
Implementação Processual
A organização deve:
1 Criar e manter uma lista das pessoas com acessos autorizados a zonas reservadas,
onde as redes e os sistemas de informação estão alojados;
77
4 Controlar o acesso às zonas de segurança definidas:
a. Verificando a identidade de indivíduos antes de lhes permitir a entrada;
b. Controlando entradas e saídas, usando os mecanismos de restrição físi-
ca adequados;
c. Mantendo um registo de auditoria de passagem por pontos chave;
Garantindo acompanhamento de visitantes por pessoas autorizadas;
Evidências
1 Registo de entradas e saídas de zonas de acesso reservado;
R.N. CIS CSC 12; PR.GA-3 - A organização deve gerir os seus acessos remotos
COBIT 5
APO13.01,
DSS01.04,
DSS05.03;
Descrição
ISO/IEC
27001:2013 A organização deve documentar, gerir e controlar os acessos remotos às suas redes e sis-
A.6.2.1, A.6.2.2,
A.11.2.6, A.13.1.1, temas de informação.
A.13.2.1;
NIST SP 800-53
São considerados acessos remotos, todos os acessos feitos às redes e sistemas de infor-
Rev. 4 AC-1, AC- mação por colaboradores que comuniquem através de redes de comunicações externas
17, AC-19, AC-20, à organização. As VPN, quando criadas, devem ser consideradas redes de comunicações
SC-15.
internas, observando-se os controlos de segurança apropriados.
Cumulativamente, apenas são considerados acessos remotos a redes e sistemas de infor-
mação, aqueles que sejam realizados a sistemas cujo propósito original não seja disponibi-
lizar informação para consulta pública.
Implementação Técnica
1 Gestão de Identidades e Acessos;
78
Implementação Processual
A organização deve:
Evidências
1 Documentos de suporte às políticas de gestão do teletrabalho e acessos remotos;
R.N. CIS CSC 3, 5, PR.GA-4 - A organização deve aplicar na gestão de acessos, os princípios do me-
12, 14, 15, 16, 18; nor privilégio e da segregação de funções
COBIT 5 DSS05.04;
ISO/IEC
27001:2013 Descrição
A.6.1.2, A.9.1.2,
A.9.2.3, A.9.4.1,
A.9.4.4, A.9.4.5;
As permissões de acesso e as autorizações devem ser geridas de acordo com os princípios
NIST SP 800-53
de acesso adequados à função, de acordo com os princípios de necessidade de conhecer e
Rev. 4 AC-1, AC-2, de segregação de funções.
AC-3, AC-5, AC-6,
AC-14, AC-16, Entende-se, por menor privilégio, que a concessão de acessos às redes e sistemas de in-
AC-24.
formação da organização aos colaboradores, devem ser as estritamente necessárias para
o correto desempenho das suas funções. Por segregação de funções, entende-se a prática
da divisão do conhecimento e de privilégios entre múltiplos indivíduos, de forma a que um
processo em particular não possa ser executado ou controlado apenas por um deles.
O principal fundamento para a aplicação desta prática de segregação de funções, é a pre-
venção de incidentes de segurança com impacto significativo nas atividades operacionais
da organização. Existindo múltiplas pessoas envolvidas, minimiza-se a oportunidade de
transgressões e fomenta-se a probabilidade de estas serem detetadas e reportadas.
O princípio de segregação de funções pode ser aplicado nos seguintes tipos de processos:
1 Sequenciais: Quando as atividades podem ser executadas em tarefas sequenciais
e por pessoas diferentes (por exemplo: na atribuição de acessos, uma pessoa soli-
cita, outra aprova e uma terceira atribui os acessos);
79
2 Quórum: Quando as atividades requerem um quórum mínimo de aprovações
para poderem ser executadas (por exemplo: a recuperação de uma chave de ci-
fra, onde é requerida a presença de dois ou mais administradores de sistemas);
3 Geoespacial: Quando as atividades podem ser divididas em tarefas que são realiza-
das em locais diferentes (por exemplo: gestão de sistemas de informação, cujas tare-
fas são efetuadas por colaboradores sediados em diferentes zonas geográficas).
Implementação Técnica
1 Gestão do ciclo de vida de Identidades e Acessos.
Implementação Processual
A organização deve:
1 Criar um mapeamento de funções por perfis;
Evidências
1 Documentos de suporte ao processo de gestão de acessos;
R.N. CIS CSC 9, PR.GA-5 - A organização deve proteger a integridade das redes de comunicações
14, 15, 18;
COBIT 5 DSS01.05,
DSS05.02;
ISO/IEC Descrição
27001:2013
A.13.1.1, A.13.1.3, A integridade das redes de comunicações deve ser protegida por intermédio da sua segre-
A.13.2.1, A.14.1.2, gação e segmentação.
A.14.1.3;
NIST SP 800-53 A rede de comunicações deve ser desenhada de forma a não ser possível aceder-se a qual-
Rev. 4 AC-4, AC-
10, SC-7.
quer sistema, a partir de qualquer ponto da mesma.
Devem ser criadas zonas de segurança com propósitos identificados e com barreiras bem
definidas e forçadas por equipamentos de rede de comunicações com capacidade para o
efeito (routers, gateways, firewalls, entre outros).
80
As segregações da rede de comunicação devem ser documentadas em políticas que defi-
nam o seu modelo de governo, nomeadamente, que autorizações são necessárias para a
aprovação de novos fluxos e que fluxos entre zonas são pré-aprovados. Os fluxos de infor-
mação entre sistemas devem obrigar a autorizações específicas e estar de acordo com as
políticas definidas para o efeito.
Exemplos do que as restrições de fluxos devem incluir:
1 Impedimentos de transmissão de informação sensível em claro para a Internet;
3 Restrição de acessos diretos à Internet que não sejam feitos através de um proxy
corporativo;
Implementação Técnica
1 Firewall;
Implementação Processual
A organização deve:
1 Criar uma norma de segregação de redes de comunicações;
81
Evidências
1 Documento com a política de segregação de redes de comunicações e de zonas
de segurança;
R.N. CIS CSC, 16; PR.GA-6 - A organização deve verificar a identidade dos colaboradores e vincu-
COBIT 5 DSS05.04, lá-las às respetivas credenciais
DSS05.05,
DSS05.07,
DSS06.03;
Descrição
ISO/IEC
27001:2013, A identidade dos colaboradores deve ser vinculada, revista e as suas credenciais confirma-
A.7.1.1, A.9.2.1;
das interactivamente, quando necessário.
NIST SP 800-53
Rev. 4 AC-1, AC-2,
AC-3, AC-16, AC-
A verificação de antecedentes deve ser efetuada respeitando a legislação laboral aplicável.
19, AC-24, IA-1,
IA-2, IA-4, IA-5,
IA-8, PE-2, PS-3.
Implementação Técnica
1 Gestão de Identidades e Acessos.
Implementação Processual
A organização deve:
1 Efetuar a verificação de credenciais e referências dos novos colaboradores nos
termos permitidos por lei e de forma adequada às funções que o mesmo irá exer-
cer;
82
Evidências
1 Registos das verificações de antecedentes efetuadas;
R.N. CIS CSC 1, PR.GA-7 - Devem ser definidos mecanismos de autenticação de utilizadores, dis-
12, 15, 16; positivos e outros ativos de sistemas de informação
COBIT 5 DSS05.04,
DSS05.10,
DSS06.10;
ISO/IEC Descrição
27001:2013
A.9.2.1, A.9.2.4, Os mecanismos de autenticação devem ser definidos e mantidos de acordo com as ca-
A.9.3.1, A.9.4.2,
A.9.4.3, A.18.1.4;
racterísticas dos sistemas e dos perfis de acessos, por forma a permitir a manutenção da
NIST SP 800-53
integridade e a confidencialidade da informação.
Rev. 4 AC-7, AC-8,
AC-9, AC-11, AC-
12, AC-14, IA-1,
IA-2, IA-3, IA-4,
IA-5, IA-8, IA-9,
IA-10, IA-11. Implementação Técnica
1 Gestão de Identidades e Acessos;
Implementação Processual
A organização deve:
1 Criar e manter uma política de gestão de palavras-passe;
Evidências
1 Documentos de suporte à política de gestão de palavras-passe;
83
4.4.2 PR.FC Formação e Sensibilização
R.N. CIS CSC 17, PR.FC-1 - Os colaboradores devem ter formação em segurança da informação
18;
COBIT 5
APO07.03,
BAI05.07; Descrição
ISO/IEC
27001:2013 A organização deve estabelecer um plano de ações de formação em segurança da infor-
A.7.2.2, A.12.2.1; mação, bem como definir os processos e procedimentos necessários para garantir a sua
NIST SP 800-53 correta implementação.
Rev. 4 AT-2, PM-
13. A organização deve medir o sucesso das suas ações de formação.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve criar, disseminar e atualizar:
1 Um plano de ações de formação;
4 Medir o sucesso das ações de formação realizadas através de entrevistas aos for-
mandos das mesmas.
Evidências
1 Plano de ações de formação em segurança da informação;
84
R.N. CIS CSC 5, PR.FC-2 - Os utilizadores com acesso privilegiado devem compreender quais são
17, 18; os seus papéis e responsabilidades
COBIT 5APO07.02,
DSS05.04,
DSS06.03;
ISO/IEC Descrição
27001:2013
A.6.1.1, A.7.2.2; Os colaboradores, com acessos privilegiados às redes e sistemas de informação da organi-
NIST SP 800-53 zação, devem ser devidamente consciencializados sobre as suas funções e compreender os
Rev. 4 AT-3, PM- seus papéis e responsabilidades. A organização deve definir os conteúdos programáticos
13.
necessários para que as ações de formação sobre acessos privilegiados sejam eficazes.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve providenciar ações de formação sobre a utilização de acessos privile-
giados aos colaboradores:
1 Antes de estes darem início ao exercício de funções que requeiram este tipo de
acessos;
Evidências
1 Plano de ações de formação respeitante à temática de acessos privilegiados;
R.N. CIS CSC 17; PR.FC-3 - As partes interessadas externas devem compreender quais são os seus
COBIT 5 papéis e responsabilidades
APO07.03,
APO07.06,
APO10.04,
APO10.05; Descrição
ISO/IEC
27001:2013 Todas as partes interessadas, externas e relevantes para a organização, devem ter conhe-
A.6.1.1, A.7.2.1,
A.7.2.2;
cimento dos seus papéis e responsabilidades no âmbito do sistema de segurança da orga-
NIST SP 800-53
nização. Este entendimento é essencial para aumentar o nível de segurança da informação
Rev. 4 PS-7, SA-9, da organização.
SA-16.
A organização deve efetuar ações de sensibilização para garantir que o entendimento das
partes interessadas sobre este tema é o adequado e necessário.
85
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Estabelecer os requisitos mínimos de segurança, funções e responsabilidades que
os clientes e fornecedores devem seguir;
Evidências
1 Documento com requisitos mínimos de segurança a requerer aos clientes e forne-
cedores;
R.N. CIS CSC 17, PR.FC-4 - A gestão de topo deve compreender as suas funções e responsabilidades
19;
COBIT 5
EDM01.01,
APO01.02, Descrição
APO07.03;
ISO/IEC A gestão de topo deve demonstrar estar comprometida com a temática da segurança da
27001:2013
A.6.1.1, A.7.2.2;
informação e cibersegurança. A gestão de topo deve compreender qual é o seu papel e
responsabilidade nesta temática.
NIST SP 800-53
Rev. 4 AT-3, PM-
13.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve garantir que a gestão de topo:
1 Tem os seus papéis e responsabilidades definidos;
86
Evidências
1 Definição de papéis e responsabilidades;
R.N. CIS CSC 13, PR.SD-1 - A organização deve proteger os dados armazenados
14;
COBIT 5APO01.06,
BAI02.01,
BAI06.01, Descrição
DSS04.07,
DSS05.03, As redes e sistemas de informação devem proteger a confidencialidade e integridade da
DSS06.06;
informação armazenada na organização.
ISO/IEC
27001:2013
A.8.2.3;
NIST SP 800-53
Rev. 4 MP-8, SC-
12, SC-28. Implementação Técnica
1 Serviços de cifra de ficheiros, bases de dados e cópias de segurança;
Implementação Processual
A organização deve garantir que:
1 Os dados são armazenados de acordo com a classificação que lhes for atribuída
para o nível de confidencialidade pretendido;
Evidências
1 Documentos de suporte à classificação de informação;
87
R.N. CIS CSC 13, PR.SD-2 - A organização deve proteger os dados em circulação
14;
COBIT 5
APO01.06,
DSS05.02, Descrição
DSS06.06;
ISO/IEC A organização deve proteger a integridade e a confidencialidade da informação transmiti-
27001:2013 da. Este controlo deve ser aplicado quer a redes de comunicações internas como externas.
A.8.2.3, A.13.1.1,
A.13.2.1, A.13.2.3, Para sistemas distribuídos, este controlo deve aplicar-se em toda a linha, por forma a ga-
A.14.1.2, A.14.1.3;
rantir a integridade entre os componentes e serviços que geram a informação e os compo-
NIST SP 800-53
Rev. 4 SC-8, SC-11,
nentes e serviços que a recebem.
SC-12.
Quando for impraticável ou impossível garantir os controlos de segurança necessários e as
garantias de controlo efetivo através dos veículos contratuais apropriados, a organização
deve implementar os controlos compensatórios necessários ou explicitamente aceitar o
risco adicional e/ou transferir o risco para o fornecedor contratual.
Implementação Técnica
1 Serviços de cifra de comunicações.
Implementação Processual
A organização deve garantir que:
1 Efetua o transporte da informação de forma segura e de acordo com as suas re-
gras de classificação de informação definidas;
Evidências
1 Documentos de suporte à classificação de informação;
R.N. CIS CSC 1; PR.SD-3 - A organização deve gerir formalmente os ativos durante os procedi-
COBIT 5 BAI09.03; mentos de remoção, transferência e aprovisionamento dos mesmos
ISO/IEC
27001:2013
A.8.2.3, A.8.3.1, Descrição
A.8.3.2, A.8.3.3,
A.11.2.5, A.11.2.7; A organização deve garantir a existência de procedimentos de autorização, monitorização,
NIST SP 800-53 registo e de controlo dos dados de redes e sistemas de informação e dos componentes que
Rev. 4 CM-8, MP- entram e saem das suas instalações.
6, PE-16.
88
Quando a informação deixar de ser necessária para a organização, devem ser aplicados
mecanismos de higienização, que devem estar associados à classificação de segurança as-
sociada à informação.
Implementação Técnica
Implementação Processual
A organização deve:
1 Elaborar procedimentos de gestão do ciclo de vida de ativos;
Evidências
1 Documentos de suporte ao processo de gestão de ciclo de vida de ativos;
R.N. CIS CSC 1, PR.SD-4 - A organização deve providenciar a capacidade adequada para garantir
2, 13; a disponibilidade das redes e dos sistemas de informação
COBIT 5
APO13.01,
BAI04.04;
ISO/IEC
Descrição
27001:2013
A.12.1.3, A.17.2.1; A capacidade das redes e dos sistemas de informação deve ser monitorizada. Devem ser
NIST SP 800-53 efetuadas previsões sobre as necessidades de capacidade futura, para garantir que a per-
Rev. 4 AU-4, CP-2, formance dos sistemas está alinhada com os requisitos de prestação dos serviços críticos.
SC-5.
Implementação Técnica
1 Monitorização de métricas e histórico de capacidade dos recursos informáticos;
89
Implementação Processual
A organização deve:
1 Criar procedimentos para gerir os três tipos primários de capacidade:
a. Capacidade de armazenamento (base de dados, sistemas de ficheiros,
entre outros);
b. Capacidade de memória e de processamento (poder computacional);
c. Largura de banda e latência das redes de comunicações.
Evidências
1 Documentos de suporte ao processo de gestão de capacidade;
R.N. CIS CSC 13, PR.SD-5 - A organização deve implementar proteções que evitem exfiltração de
COBIT 5 informação
APO01.06,
DSS05.04,
DSS05.07,
DSS06.02; Descrição
ISO/IEC
27001:2013 A organização deve implementar controlos de segurança nas fronteiras das suas instalações
A.6.1.2, A.7.1.1,
A.7.1.2, A.7.3.1,
ou das suas redes e sistemas de informação, para detetar e impedir a exfiltração não auto-
A.8.2.2, A.8.2.3, rizada de informação.
A.9.1.1, A.9.1.2,
A.9.2.3, A.9.4.1, Deve ser definido o âmbito de atuação e frequência da aplicação, com o objetivo de se
A.9.4.4, A.9.4.5, adequar a mitigação do risco associado. Risco este, que deve ser calculado tendo por base
A.10.1.1,
A.11.1.4,A.11.1.5, a classificação de confidencialidade da informação.
A.11.2.1, A.13.1.1,
A.13.1.3, A.13.2.1,
A.13.2.3, A.13.2.4,
A.14.1.2, A.14.1.3;
NIST SP 800-53
Rev. 4 AC-4, AC-5, Implementação Técnica
AC-6, PE-19, PS-3,
PS-6, SC-7, SC-8, 1 Implementação de sistemas de prevenção de perda de informação (DLP);
SC-13, SC-31, SI-4.
2 Sistema de classificação de informação de mensagens de correio eletrónico e do-
cumentos.
90
Implementação Processual
A organização deve:
1 Implementar medidas de salvaguarda para prevenir a exfiltração não autorizada
de informação dos seus sistemas, como por exemplo:
a. Obrigatoriedade de usar formatos e protocolos predefinidos;
b. Monitorização para esteganografia;
c. Restringir uso de interfaces externas de rede ao estritamente necessá-
rio;
d. Monitorização dos cabeçalhos de pacotes de rede;
e. Efetuar análises aos padrões de tráfego de rede para detetar desvios,
quer de tipo, quer de volume;
2 Criar procedimentos que tornem eficaz e consistente a adoção das suas regras de
classificação da informação.
Evidências
1 Documentos de suporte à política de utilização aceitável de ativos;
R.N. CIS CSC 2, 3; PR.SD-6 - A organização deve utilizar mecanismos de verificação para confirmar
COBIT 5 a integridade de software, firmware e dados
APO01.06,
BAI06.01,
DSS06.02;
ISO/IEC Descrição
27001:2013
A.12.2.1, A.12.5.1, A organização deve utilizar mecanismos de verificação que garantam a integridade de sof-
A.14.1.2, A.14.1.3,
A.14.2.4;
tware, firmware e dados. Estes controlos têm como objetivo detetar manipulações não
NIST SP 800-53
autorizadas ou erros inesperados devido a má utilização.
Rev. 4 SC-16, SI-7.
Implementação Técnica
1 Testes estáticos de segurança a redes e sistemas de informação;
91
Implementação Processual
A organização deve:
1 Definir processos/procedimentos de controlo de qualidade que exijam verificação
de integridade de software e/ou firmware;
Evidências
1 Documentos de suporte a processos/procedimentos de verificação de integrida-
de;
R.N. CIS CSC 18, PR.SD-7 - A organização deve utilizar mecanismos de verificação para confirmar
20; a integridade de software, firmware e dados
COBIT 5 BAI03.08,
BAI07.04;
ISO/IEC
27001:2013 Descrição
A.12.1.4;
NIST SP 800-53 A organização deve efetuar a separação dos ambientes das suas redes e dos seus sistemas
Rev. 4 CM-2. de informação, de forma física ou lógica, de acordo com as suas funções.
Os ambientes de desenvolvimento e testes devem estar segregados dos ambientes de pro-
dução, quer em termos de acessos, como em termos de dados.
Implementação Técnica
1 Zonas de segurança de redes de comunicações;
Implementação Processual
A organização deve:
1 Criar, disseminar e atualizar uma política de desenvolvimento seguro de software;
92
3 Efetuar a gestão de configurações de ambientes, de forma independente e da
maneira adequada a cada tipo de ambiente (estabilidade em produção e flexibili-
dade em desenvolvimento);
Evidências
1 Documentos de suporte ao desenvolvimento seguro de software;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve garantir:
1 A manutenção do seu hardware pelo fabricante ou por um fornecedor certifica-
do.
Evidências
1 Plano de manutenção do hardware;
93
4.4.4 PR.PI Procedimentos e Processos de Proteção da Informação
R.N. CIS CSC 3, PR.PI-1 - Deve ser criada e mantida uma configuração base de redes e sistemas
9, 11; de informação que incorpore os princípios de segurança
COBIT 5 BAI10.01,
BAI10.02,
BAI10.03,
BAI10.05; Descrição
ISO/IEC
27001:2013 A organização deve estabelecer uma configuração base para redes e sistemas de informa-
A.12.1.2, A.12.5.1, ção, para os seus componentes e para as suas comunicações e conectividades.
A.12.6.2, A.14.2.2,
A.14.2.3, A.14.2.4;
Por configuração base, entende-se:
NIST SP 800-53
Rev. 4 CM-2, CM-
3, CM-4, CM-5,
1 Programas informáticos instalados em estações de trabalho;
CM-6, CM-7, CM-
9, SA-10. 2 Equipamentos pessoais, tais como computadores portáteis, impressoras e outros
dispositivos móveis;
Implementação Técnica
1 Sistema de integração/entrega contínua (CI/CD);
Implementação Processual
A organização deve:
1 Desenvolver, documentar e manter sob controlo de versões a configuração atual
das suas redes e sistemas de informação;
Evidências
1 Documentos de suporte à política de desenvolvimento seguro de software;
94
R.N. CIS CSC 18; PR.PI-2 - Deve ser implementado um ciclo de vida de desenvolvimento seguro
COBIT 5 de software
APO13.01,
BAI03.01,
BAI03.02,
BAI03.03; Descrição
ISO/IEC
27001:2013 A organização deve aplicar princípios de engenharia de segurança da informação na es-
A.6.1.5, A.14.1.1, pecificação, desenho, desenvolvimento, implementação e modificação das suas redes e
A.14.2.1, A.14.2.5;
sistemas de informação. Estes princípios devem ser aplicados, quer a novos sistemas, como
NIST SP 800-53
Rev. 4 PL-8, SA-3, a sistemas que estejam a passar por alterações significativas.
SA-4, SA-8, SA-10,
SA-11, SA-12, SA- Para sistemas legados, estes princípios devem ser aplicados, na medida do possível, tendo
15, SA-17, SI-12, em conta o estado atual do hardware, software e firmware desses sistemas.
SI-13, SI-14, SI-16,
SI-17.
Implementação Técnica
1 Ferramentas de integração contínua (CI);
Implementação Processual
A organização deve:
1 Definir os requisitos de segurança da informação nos seus projetos;
95
Evidências
1 Documentos com requisitos de segurança da informação de projeto;
R.N. CIS CSC 3, 11; PR.PI-3 - Deve ser implementado um processo de gestão de alterações
COBIT 5 BAI01.06,
BAI06.01;
ISO/IEC Descrição
27001:2013
A.12.1.2, A.12.5.1, A organização deve implementar um processo formal de gestão de alterações.
A.12.6.2, A.14.2.2,
A.14.2.3, A.14.2.4;
NIST SP 800-53
Rev. 4 CM-3, CM-
4, SA-10.
Implementação Técnica
1 Sistema de gestão de alterações;
Implementação Processual
A organização deve garantir que:
1 A configuração base das redes e sistemas de informação é formalmente revista,
tendo em conta os conceitos de funcionalidade mínima necessária e políticas de
robustecimento de segurança definidas;
Evidências
1 Documento com o processo de gestão de alterações;
Implementação Técnica
1 Ferramenta de cópias de segurança.
Implementação Processual
A organização deve:
1 Proteger a confidencialidade, integridade e disponibilidade das cópias de segu-
rança;
2 Equacionar a possibilidade de guardar as suas cópias de segurança em local segu-
ro, fora das suas instalações;
3 Executar cópias de segurança regulares da informação dos utilizadores, sistemas e
documentação das redes e sistemas de informação;
4 Testar periodicamente o restauro das cópias de segurança e iniciar medidas corre-
tivas em caso de falha.
Evidências
1 Documentos de suporte a política de cópias de segurança;
97
Implementação Técnica
1 Proteção contra picos de corrente elétrica;
Implementação Processual
A organização deve:
1 Instalar sensores de fumo, temperatura, humidade e inundação nos locais ade-
quados;
4 Executar, dentro dos prazos previstos, a devida manutenção dos sistemas acima
mencionados;
Evidências
1 Registos de controlo de acesso;
R.N. COBIT 5 PR.PI-6 - Os dados devem ser destruídos de acordo com a política definida
BAI09.03,
DSS05.06;
ISO/IEC
27001:2013 Descrição
A.8.2.3, A.8.3.1,
A.8.3.2, A.11.2.7; As informações digitais e físicas devem ser sujeitas aos métodos apropriados de destruição,
NIST SP 800-53 de acordo com a sua classificação de informação.
Rev. 4 MP-6.
Implementação Técnica
1 Higienização de ficheiros e sistemas de ficheiros, com destruidor de ficheiros;
2 Destruidor de papel.
98
Implementação Processual
1 No final do ciclo de vida da informação, a organização deve implementar contro-
los que garantam a sua destruição (em formato digital ou físico), de acordo com
a sua classificação e respeitando as regras que poderão ser aplicáveis face a leis
nacionais e sectoriais existentes;
Evidências
1 Documentos de suporte à classificação da informação;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Monitorizar, analisar, auditar e avaliar a performance dos seus controlos, proces-
sos e sistemas de gestão implementados;
99
Evidências
1 Relatórios das auditorias internas;
R.N. COBIT 5 PR.PI-8 - A efetividade das tecnologias de proteção deve ser tida em conta na
BAI08.04,
DSS03.04;
melhoria dos processos de proteção
ISO/IEC
27001:2013
A.16.1.6; Descrição
NIST SP 800-53
Rev. 4 AC-21, CA- A organização deve ter um compromisso contínuo com a melhoria, efetuando sessões de
7, SI-4.
lições aprendidas e analisando os incidentes ocorridos. Estas lições têm como objetivo a
redução dos riscos de ocorrência de incidentes futuros.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Praticar de forma regular o processo de lições aprendidas com base nos inciden-
tes ocorridos;
2 Promover a partilha do conhecimento aprendido na investigação e resolução de
incidentes;
Evidências
1 Registos, com a identificação das ações de melhoria contínua, originados por inci-
dentes ocorridos;
100
R.N. CIS CSC 19; PR.PI-9 - Os planos de resposta a incidentes, da continuidade de negócio, de
COBIT 5 recuperação de incidentes e de recuperação de desastres devem ser
APO12.06, atualizados
DSS04.03;
ISO/IEC
27001:2013
A.16.1.1, A.17.1.1, Descrição
A.17.1.2, A.17.1.3;
NIST SP 800-53 Os planos de resposta a incidentes, da continuidade de negócio, de recuperação a inciden-
Rev. 4 CP-2, CP-7, tes e de recuperação de desastres devem ser atualizados com frequência.
CP-12, CP-13, IR-7,
IR-8, IR-9, PE-17.
A organização deve garantir que as partes interessadas relevantes, internas e externas,
tenham o conhecimento apropriado de todas as atualizações efetuadas.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Criar um plano de resposta e de recuperação de incidentes que:
a. Contenha um plano de implementação para a capacidade de resposta a
incidentes;
b. Descreva a estrutura e organização da resposta inicial;
c. Defina o que são incidentes;
d. Defina os recursos necessários para suportar a resposta a incidentes;
e. Defina os procedimentos de resposta a perdas de informação;
Evidências
1 Plano da continuidade do negócio;
101
R.N. CIS CSC 19, PR.PI-10 - Os planos de resposta e recuperação devem ser testados e exercitados
20;
COBIT 5 DSS04.04;
ISO/IEC
27001:2013
Descrição
A.17.1.3;
A organização deve garantir que os planos de resposta e de recuperação de incidentes e
NIST SP 800-53
Rev. 4 CP-4, IR-3, da continuidade do negócio da organização são testados, para que se possa determinar a
PM-14. eficácia dos mesmos e identificar possíveis pontos de falha.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve conduzir os seguintes tipos de teste:
1 Exercícios dos planos da continuidade do negócio;
Evidências
1 Registos da execução dos exercícios e testes da continuidade do negócio e de res-
posta/recuperação de incidentes.
R.N. CIS CSC 5, 16; PR.PI-11 - A cibersegurança deve ser contemplada nos processos de gestão de
COBIT 5 recursos humanos
APO07.01,
APO07.02,
APO07.03,
APO07.04, Descrição
APO07.05;
ISO/IEC Os processos organizacionais que gerem os recursos humanos, como a triagem de candi-
27001:2013 datos, contratação, categorização das posições e de cessação de vínculo laboral, devem ser
A.7.1.1, A.7.1.2,
A.7.2.1, A.7.2.2,
avaliados e revistos com base nos requisitos de segurança estabelecidos.
A.7.2.3, A.7.3.1,
A.8.1.4;
NIST SP 800-53
Rev. 4 PS-1, PS-2,
PS-3, PS-4, PS-5,
PS-6, PS-7, PS-8, Implementação Técnica
SA-21.
Não aplicável.
102
Implementação Processual
A organização deve atualizar os processos de gestão de recursos humanos, aquando da
entrada, alteração e saída de colaboradores, devendo:
1 Efetuar a categorização da posição em termos de funções, âmbito, responsabili-
dades e risco;
3 Executar a triagem com base no risco percecionado para a posição, de forma re-
gular;
4 Em caso de transferência:
a. Efetuar a revisão de acessos físicos e lógicos às redes e sistemas de infor-
mação e instalações;
b. Efetuar a confirmação das necessidades operacionais para continuidade
dos acessos;
c. Efetuar a atualização de acessos com base nas novas funções;
Evidências
1 Documentos que suportam o processo de gestão de colaboradores;
2 Dossier de colaborador.
R.N. CIS CSC 4, PR.PI-12 - Deve ser definido e implementado um processo de gestão de vulne-
18, 20; rabilidades
COBIT 5 BAI03.10,
DSS05.01,
DSS05.02;
ISO/IEC Descrição
27001:2013
A.12.6.1, A.14.2.3, A organização deve definir e implementar um plano para gestão das vulnerabilidades nas
A.16.1.3, A.18.2.2,
A.18.2.3;
redes e sistemas de informação.
NIST SP 800-53
Rev. 4 RA-3, RA-5,
SI-2.
Implementação Técnica
1 Ferramenta de rastreamento de vulnerabilidades.
103
Implementação Processual
A organização deve definir e implementar um processo de gestão de vulnerabilidades que:
1 Efetue um planeamento do rastreamento de vulnerabilidades às suas redes e sis-
temas de informação, garantindo que identifica:
a. A sequência da execução do rastreamento;
b. As janelas temporais para a execução do rastreamento;
c. Um relatório das vulnerabilidades encontradas;
Evidências
1 Documento de suporte ao processo de gestão de vulnerabilidades;
104
Implementação Técnica
1 Ferramenta de gestão de pedidos.
Implementação Processual
A organização deve:
1 Desenvolver, disseminar, rever e atualizar um processo de manutenção de siste-
mas, definindo o âmbito, propósito, perfis e responsabilidades das partes interes-
sadas envolvidas;
Evidências
1 Implementação de controlo e registos de acessos em áreas seguras;
R.N. CIS CSC 3, 5; PR.MA-2 - As operações de manutenção remota das redes devem ser revistas,
COBIT 5 DSS05.04; aprovadas, executadas e registadas
ISO/IEC
27001:2013
A.11.2.4, A.15.1.1,
A.15.2.1; Descrição
NIST SP 800-53
Rev. 4 MA-4. A manutenção remota das redes e sistemas de informação da organização deve ser sujeita
a processos de aprovação, devendo ser registada e executada de forma a impedir a existên-
cia de acessos não autorizados.
105
Implementação Técnica
1 Registo dos pedidos de intervenção em sistema de gestão de pedidos.
Implementação Processual
A organização deve:
1 Aprovar e monitorizar as manutenções remotas e atividades de diagnóstico;
Evidências
1 Documentos de suporte à política de fornecedores;
R.N. CIS CSC 1, 3, PR.TP-1 - Os registos de auditoria e de histórico devem ser documentados, im-
5, 6, 14, 15, 16; plementados e revistos de acordo com as políticas
COBIT 5
APO11.04,
BAI03.05,
DSS05.04,
DSS05.07, Descrição
MEA02.01;
ISO/IEC Os registos de auditoria e de histórico da organização devem ser determinados, documen-
27001:2013 tados, implementados e revistos de acordo com as políticas correspondentes.
A.12.4.1, A.12.4.2,
A.12.4.3, A.12.4.4,
A.12.7.1;
NIST SP 800-53
Rev. 4 família AU.
Implementação Técnica
1 Gestão de eventos de segurança da informação;
106
Implementação Processual
A organização deve:
1 Criar, disseminar, rever e atualizar uma política de gestão de registos e eventos;
5 Determinar que tipos de eventos devem ser alvo de registos de auditoria dentro
das redes e sistemas de informação;
Evidências
1 Política de gestão de eventos, registos de auditoria e histórico;
R.N. CIS CSC 8, PR.TP-2 - Os suportes de dados amovíveis devem ser protegidos e a sua utiliza-
13; ção deve ser restrita, de acordo com a política definida
COBIT 5
APO13.01,
DSS05.02,
DSS05.06; Descrição
ISO/IEC
27001:2013 A organização deve implementar procedimentos que garantam o cumprimento das regras
A.8.2.1, A.8.2.2, de utilização de suportes de dados amovíveis, de acordo com a classificação de informação
A.8.2.3, A.8.3.1,
A.8.3.3, A.11.2.9; definida.
NIST SP 800-53
Rev. 4 MP-2, MP-
3, MP-4, MP-5,
MP-7, MP-8.
107
Implementação Técnica
1 Restringir o acesso físico a todos os suportes de dados amovíveis (por exemplo:
cofres nas estações de trabalho) ou lógicas, removendo a capacidade de inserir,
ler ou escrever discos amovíveis via software para esse efeito;
Implementação Processual
A organização deve:
1 Restringir o acesso a suporte de dados amovíveis, de acordo com a classificação
de informação;
Evidências
1 Documentos de suporte à classificação da informação;
R.N. CIS CSC 3, PR.TP-3 - O princípio da minimização de funcionalidades deve ser incorporado
11, 14; na configuração de sistemas de modo a fornecer apenas os recursos es-
COBIT 5 DSS05.02, senciais
DSS05.05,
DSS06.06;
ISO/IEC Descrição
27001:2013
A.9.1.2; A organização deve aplicar o princípio da funcionalidade mínima na configuração das redes
NIST SP 800-53 e sistemas de informação. A funcionalidade mínima deve garantir que apenas sejam autori-
Rev. 4 AC-3, CM-7. zados acessos aos utilizadores que necessitem dessas mesmas funcionalidades, por forma
a executarem as tarefas a si atribuídas de acordo com os seus perfis funcionais.
108
Implementação Técnica
1 Gestão de identidades e acessos.
Implementação Processual
A organização deve:
1 Aplicar os princípios da funcionalidade mínima para tarefas relacionados com a
gestão das redes e sistemas de informação:
a. Restrição de funcionalidades, portos, protocolos e serviços;
b. Restrição de processos para desempenhar as funções necessárias;
c. Restrição de níveis de privilégios mínimos para cumprir a missão da orga-
nização ou funções necessárias;
d. Restrição de acessos a funções de segurança;
e. Restrição de acessos de rede a comandos privilegiados;
f. Restrição de domínios de processamento;
g. Restrição de contas privilegiadas;
h. Restrição de privilégios para a execução de código.
Evidências
1 Documentos de suporte ao processo de gestão de acessos;
R.N. CIS CSC 8, PR.TP-4 - As redes de comunicações e de controlo devem ser protegidas
12, 15;
COBIT 5 DSS05.02,
APO13.01;
ISO/IEC Descrição
27001:2013
A.13.1.1, A.13.2.1, Os fluxos regulam a transferência de informação e os caminhos que podem ser abertos
A.14.1.3; dentro de cada sistema ou entre sistemas. Estes, devem ser controlados operacionalmente
NIST SP 800-53 e devem ser sempre requeridas as autorizações prévias para que possam ser alterados.
Rev. 4 AC-4, AC-
17, AC-18, CP-8,
SC-7, SC-19, SC-
20, SC-21, SC-22,
SC-23, SC-24, SC-
25, SC-29, SC-32, Implementação Técnica
SC-36, SC-37, SC-
38, SC-39, SC-40,
SC-41, SC-43.
1 Sistema de Deteção e Prevenção de Intrusões (IDS/IPS);
2 Firewall;
3 Proxy;
109
Implementação Processual
A organização deve garantir que:
1 As alterações efetuadas nas suas redes de comunicações são executadas dentro
… do processo de gestão de alterações.
Evidências
1 Existência de dispositivos de rede de comunicações com funções de segurança;
R.N. COBIT 5 PR.TP-5 - Devem ser implementados mecanismos para cumprir os requisitos de
BAI04.01,
BAI04.02,
resiliência em situações adversas
BAI04.03,
BAI04.04,
BAI04.05,
DSS01.05;
Descrição
ISO/IEC A organização deve implementar os mecanismos necessários, para que possa cumprir os
27001:2013
A.17.1.2, A.17.2.1; requisitos de resiliência básicos em situações incomuns e garantir a alocação de recursos e
NIST SP 800-53 equipamentos adicionais. Caso seja necessário responder a situações adversas, coloca-se
Rev. 4 CP-7, CP-8, em prática a estratégia da continuidade do negócio.
CP-11, CP-13, PL-
8, SA-14, SC-6.
Implementação Técnica
1 Sistemas de alta disponibilidade;
Implementação Processual
A organização deve:
1 Determinar o tempo máximo aceitável de falha para os ativos e serviços críticos,
aprovisionando componentes de substituição para a reposição do serviço em
caso de avaria dos componentes em operação;
110
4 Estabelecer um local alternativo, que garanta os contratos necessários para per-
mitir, de forma segura, a transferência das suas redes e sistemas de informação
para as funções e atividades críticas para a organização;
Evidências
1 Documentos de suporte ao plano da continuidade do negócio;
111
4.5.1 DE.AE Anomalias e Eventos
R.N. CIS CSC 1, 4, DE.AE-1 - A organização deve definir e gerir um modelo de referência de opera-
6, 12, 13, 15, 16; ções de rede e fluxos de dados esperados para utilizadores e sistemas
COBIT 5 DSS03.01;
ISO/IEC
27001:2013
A.12.1.1, A.12.1.2, Descrição
A.13.1.1, A.13.1.2;
NIST SP 800-53 A organização deve garantir que as operações efetuadas na sua infraestrutura de rede de
Rev. 4 AC-4, CA-3, comunicações são executadas de forma sistematizada, por pessoal qualificado, e que seja
CM-2, SI-4.
garantida a integridade, confidencialidade e disponibilidade da informação.
Para cada sistema de informação, a organização deve medir, criar e manter um modelo do
padrão de referência para os fluxos de comunicações esperados, quer estes sejam origina-
dos por utilizadores, quer por sistemas internos ou externos.
Implementação Técnica
1 Sistema de Deteção e Prevenção de Intrusões (IDS/IPS);
2 Firewall;
3 Proxy;
Implementação Processual
Na operação da infraestrutura de rede de comunicações, onde se incluem todos os equipa-
mentos de rede de comunicações e de segurança, a organização deve:
1 Garantir que existe um padrão de referência para os fluxos de dados de utilizado-
res e sistemas;
2 Garantir que o padrão de referência é atualizado com base nas alterações rele-
vantes feitas nas redes e sistemas de informação;
Evidências
1 Modelo para registo de fluxos de dados;
113
R.N. CIS CSC 3, 6, DE.AE-2 - Os eventos detetados devem ser analisados por forma a se identifica-
13, 15; rem os alvos e os métodos de ataque
COBIT 5 DSS05.07;
ISO/IEC
27001:2013
A.12.4.1, A.16.1.1, Descrição
A.16.1.4;
NIST SP 800-53 A organização deve implementar um processo de gestão e de correlação de eventos de
Rev. 4 AU-6, CA-7, segurança que:
IR-4, SI-4.
1 Suporte o seu processo de análise e tratamento de eventos;
Implementação Técnica
1 Gestão e correlação de eventos de segurança.
Implementação Processual
A organização deve:
1 Implementar um processo de monitorização das suas redes e sistemas de infor-
mação, que permita analisar os eventos ocorridos nos mesmos;
4 Garantir que sejam abertos incidentes nos casos em que se confirme o incidente.
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
R.N. CIS CSC 1, 3, DE.AE-3 - Os eventos devem ser coletados e correlacionados a partir de várias
4, 5, 6, 7, 8, 11, fontes e sensores
12, 13, 14, 15, 16;
COBIT 5 BAI08.02;
ISO/IEC
27001:2013 Descrição
A.12.4.1, A.16.1.7;
A organização deve implementar os mecanismos tecnológicos e processuais necessários,
114
NIST SP 800-53 que permitam a coleta e correlação dos eventos gerados nas suas redes e sistemas de in-
Rev. 4 AU-6, CA-7, formação e nos dispositivos de segurança.
IR-4, IR-5, IR-8,
SI-4.
Estes eventos devem ser correlacionados entre si e, se possível, enriquecidos com fontes
de conhecimento externas sobre ameaças.
Implementação Técnica
1 Gestão e correlação de eventos de segurança;
Implementação Processual
A organização deve:
1 Garantir a recolha e armazenamento de eventos de segurança dos sistemas de
informação, equipamentos de rede de comunicações e dispositivos de segurança;
Evidências
1 Documentos de suporte ao processo de gestão de eventos;
R.N. CIS CSC 4, 6; DE.AE-4 - O impacto dos eventos deve ser classificado
COBIT 5
APO12.06,
DSS03.01;
ISO/IEC
Descrição
27001:2013
A.16.1.4; A organização deve efetuar uma categorização e tipificação dos eventos, por forma a aferir
qual o impacto dos mesmos sobre as suas redes e sistemas de informação.
A categorização dos eventos irá suportar a organização no processo de decisão sobre que
115
NIST SP 800-53 ações desencadear para cada tipo de evento. Os eventos poderão dar origem a incidentes.
Rev. 4 AU-6, CA-7,
IR-4, IR-5, IR-8,
SI-4.
Implementação Técnica
1 Gestão de eventos de segurança da informação.
Implementação Processual
O processo de gestão de eventos deve ser complementado com:
1 Categorização e tipificação de eventos;
Evidências
1 Documento de suporte ao processo de gestão de eventos;
R.N. CIS CSC 6, DE.AE-5 - Devem ser definidos os limites de alerta para incidentes
19;
COBIT 5
APO12.06,
DSS03.01; Descrição
ISO/IEC
27001:2013 Tendo como base a tipificação e categorização dos eventos do seu sistema de gestão de
A.16.1.4; eventos, a organização deve definir quais são os critérios que devem justificar a necessida-
NIST SP 800-53 de de abertura de incidentes.
Rev. 4 IR-4, IR-5,
IR-8.
Implementação Técnica
1 Gestão de eventos de segurança da informação.
Implementação Processual
A organização deve:
1 Definir a taxonomia das prioridades de incidentes;
116
2 Definir quais os limites a considerar quando um evento, conjunto de eventos ou
correlação de múltiplos eventos, configura um incidente;
Evidências
1 Documentos de suporte ao processo de gestão de eventos;
R.N. CIS CSC 1, 7, DE.MC-1 - As redes e sistemas de informação devem ser monitorizados para de-
8, 12, 13, 15, 16; tetar potenciais incidentes
COBIT 5 DSS01.03,
DSS03.05,
DSS05.07;
NIST SP 800-53 Descrição
Rev. 4 AC-2, AU-
12, CA-7, CM-3, A organização deve efetuar a monitorização da sua rede e dos seus sistemas de informação.
SC-5, SC-7, SI-4.
A monitorização deve estar integrada com o processo de gestão de eventos.
Implementação Técnica
1 Gestão e correlação de eventos de segurança da informação;
Implementação Processual
A organização deve:
1 Desenvolver uma estratégia de monitorização contínua da segurança e privacida-
de;
117
4 Ajustar o nível de monitorização de atividade quando existe uma mudança no
risco sobre ativos ou indivíduos;
Evidências
1 Documentos de suporte à gestão e correlação de eventos;
R.N. COBIT 5 DE.MC-2 - O ambiente físico deve ser monitorizado para se detetar potenciais
DSS01.04, incidentes de segurança
DSS01.05;
ISO/IEC
27001:2013
A.11.1.1, A.11.1.2; Descrição
NIST SP 800-53
Rev. 4 CA-7, PE-3, A organização deve garantir que os seus perímetros de segurança física são monitorizados.
PE-6, PE-20. A monitorização dos controlos de proteção física deve ser inserida no processo de gestão
de eventos, associados a categorização e tipificação especifica.
Implementação Técnica
1 Soluções de CCTV/Controlo de Acessos;
Implementação Processual
A organização deve garantir que:
1 Os pontos de controlo de segurança física produzem registos de auditoria;
118
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
R.N. CIS CSC 5, 7, DE.MC-3 - A atividade dos colaboradores deve ser monitorizada para se detetar
14, 16; potenciais incidentes
COBIT 5 DSS05.07;
ISO/IEC
27001:2013
A.12.4.1, A.12.4.3; Descrição
NIST SP 800-53
Rev. 4 AC-2, AU- A monitorização das atividades dos colaboradores deve estar integrada no âmbito do pro-
12, AU-13, CA-7, cesso de gestão de eventos.
CM-10, CM-11.
Esta atividade tem como objetivo recolher informação que possibilite uma atuação célere
da organização, no caso de existência de algum incidente que possa ter origem na atividade
de um colaborador.
A organização deve garantir que a informação recolhida e o seu respetivo tratamento res-
peitam o enquadramento jurídico aplicável e a política de privacidade da organização.
Implementação Técnica
1 Sistema de gestão de eventos de segurança da informação;
Implementação Processual
A monitorização das atividades dos colaboradores deve:
1 Ser garantida nas suas atividades regulares, quando interagindo com os sistemas
e redes de comunicações da organização;
4 Poder gerar alertas que sejam elevados a incidentes nos casos apropriados;
119
Evidências
1 Documentos de suporte do processo de gestão e correlação de eventos;
R.N. CIS CSC 4, 7, DE.MC-4 - A organização deve identificar e implementar mecanismos para
8, 12; deteção de código malicioso
COBIT 5 DSS05.01;
ISO/IEC
27001:2013
A.12.2.1; Descrição
NIST SP SP 800-53
Rev. 4 SI-3, SI-8. A organização deve implementar mecanismos que permitam a deteção e a prevenção de
existência de código malicioso nas suas redes e sistemas de informação.
Implementação Técnica
A organização deve:
1 Implementar ferramentas de deteção e de proteção contra a existência de código
malicioso nos equipamentos dos utilizadores e nas suas redes e sistemas de infor-
mação que:
a. Efetuem uma verificação periódica e em tempo real das redes e sistemas
de informação;
b. Analisem ficheiros com origem externa ao sistema (tal como ficheiros
retirados da internet ou copiados de suportes amovíveis);
c. Bloqueiem e/ou coloquem em quarentena como resposta imediata à
deteção de código malicioso;
Implementação Processual
A organização deve:
1 Garantir que os mecanismos de deteção e prevenção de código malicioso produ-
zem registos de auditoria;
120
Evidências
R.N. CIS CSC 7, 8; DE.MC-5 - A utilização de aplicações não autorizadas em dispositivos móveis
COBIT 5 DSS05.01; deve ser detetada
ISO/IEC
27001:2013
A.12.5.1, A.12.6.2;
NIST SP 800-53 Descrição
Rev. 4 SC-18, SI-4,
SC-44. A organização deve ter a capacidade de detetar instalações indevidas de aplicações nas
suas redes e sistemas de informação. A deteção deste tipo de atividades deve estar inte-
grada com o processo de gestão de eventos da organização.
Implementação Técnica
Gestão de equipamentos de trabalho com ferramentas de controlo de atividade aplicacio-
nal.
Implementação Processual
A organização deve:
1 Definir, documentar e disseminar uma lista de aplicações e de tecnologias permi-
tidas e não permitidas;
121
Evidências
R.N. COBIT 5 DE.MC-6 - As atividades dos prestadores de serviços externos devem ser moni-
APO07.06,
APO10.05;
torizadas para deteção de incidentes
ISO/IEC
27001:2013
A.14.2.7, A.15.2.1; Descrição
NIST SP 800-53
Rev. 4 CA-7, PS-7, As atividades dos prestadores de serviços externos devem ser monitorizadas pela organi-
SA-4, SA-9, SI-4.
zação, para detetar se as redes e os sistemas de informação da organização são acedidos
sem autorização.
Implementação Técnica
1 Gestão e correlação de eventos de segurança da informação;
Implementação Processual
A organização deve:
1 Identificar na política de gestão de fornecedores:
a. As atividades de monitorização do serviço prestado à organização;
a. Quais os requisitos de segurança, perfis e responsabilidades para forne-
cedores;
122
Evidências
1 Documentos de suporte à política de gestão de fornecedores;
R.N. CIS CSC 1, DE.MC-7 - Deve ser efetuada a monitorização de acessos não autorizados de
2, 3, 5, 9, 12, 13, colaboradores, conexões, dispositivos e software
15, 16;
COBIT 5 DSS05.02,
DSS05.05;
ISO/IEC Descrição
27001:2013
A.12.4.1, A.14.2.7, A organização deve garantir a monitorização de acessos às redes e sistemas de informação
A.15.2.1; por colaboradores, dispositivos, equipamentos e processos que não tenham as devidas
NIST SP 800-53 autorizações.
Rev. 4 AU-12,
CA-7, CM-3, CM-8,
PE-3, PE-6, PE-20,
SI-4.
Implementação Técnica
1 Gestão e correlação de eventos de segurança da informação;
Implementação Processual
A organização deve:
1 Monitorizar os acessos às redes e sistemas de informação e correlacioná-los com
a lista definida de acessos autorizados;
Evidências
1 Registos de eventos de acesso a sistemas e aplicações;
123
R.N. CIS CSC 4, DE.MC-8 - Devem ser efetuados rastreamentos de vulnerabilidades
20;
COBIT 5 BAI03.10,
DSS05.01;
ISO/IEC
Descrição
27001:2013
A.12.6.1; A organização deve executar o processo de gestão de vulnerabilidades definido, efetuan-
NIST SP 800-53 do rastreamentos de vulnerabilidades regulares, de forma automática e manual.
Rev. 4 RA-5.
Implementação Técnica
1 Ferramentas de análise e rastreamento de vulnerabilidades.
Implementação Processual
A organização deve:
1 Efetuar um plano de execução das análises de vulnerabilidades;
Evidências
1 Documentos de suporte ao processo de gestão de vulnerabilidades;
R.N. CIS CSC 19; DE.PD-1 - Devem ser definidos os papéis e responsabilidades na deteção de
COBIT 5 eventos anómalos
APO01.02,
DSS05.01,
DSS06.03;
ISO/IEC
27001:2013 Descrição
A.6.1.1, A.7.2.2;
NIST SP 800-53 A organização deve efetuar sessões de esclarecimento, que visem o claro entendimento
Rev. 4 CA-2, CA-7, das partes interessadas nos processos, bem como os limites de responsabilidades e de
PM-14.
atividades respetivos.
¹ Caso exista processo legal, este deve ser aplicado
124
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve definir, no âmbito dos processos de gestão de eventos e de inci-
dentes:
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
R.N. COBIT 5 DE.PD-2 - As atividades de deteção devem cumprir com todos os requisitos aplicá-
DSS06.01,
MEA03.03,
veis
MEA03.04;
ISO/IEC
27001:2013 Descrição
A.18.1.4, A.18.2.2,
A.18.2.3; A organização deve implementar atividades de auditoria interna, que lhe permitam aferir o
NIST SP 800-53
Rev. 4 AC-25,
funcionamento dos seus serviços de deteção e identificar possibilidades de melhoria.
CA-2, CA-7, SA-18,
SI-4, PM-14.
Implementação Técnica
1 Gestão e correlação de eventos de segurança da informação.
Implementação Processual
A organização deve:
1 Elaborar um plano de auditoria anual;
125
2 Definir qual a sua metodologia de avaliação, por forma a poder medir a eficácia
das atividades de deteção;
Evidências
1 Plano de auditoria;
2 Relatórios de auditoria;
Implementação Técnica
Gestão e correlação de eventos de segurança da informação.
Implementação Processual
A organização deve:
1 Identificar os objetivos a atingir com os testes;
126
4 Formalizar a execução dos testes e elaborar relatório das atividades;
Evidências
1 Registos de planos de testes;
R.N. CIS CSC 19; DE.PD-4 - Informações sobre deteções de eventos devem ser comunicadas
COBIT 5
APO08.04,
APO12.06,
DSS02.05; Descrição
ISO/IEC
27001:2013 A organização deve definir uma estratégia de comunicação, que mantenha informadas as
A.16.1.2, A.16.1.3; partes interessadas relevantes, sobre a ocorrência de eventos e/ou incidentes. A estratégia
NIST SP 800-53 deve ser suportada num plano de comunicação que poderá ser consolidado com os outros
Rev. 4 AU-6, CA-2, planos de comunicação que a organização disponha.
CA-7, RA-5, SI-4.
Implementação Técnica
1 Plataforma de resposta a incidentes.
Implementação Processual
O processo de gestão de incidentes da organização deve ter um plano de comunicação
definido. No plano deve identificar:
1 O que comunicar: Que conteúdo (por exemplo: a descrição de um incidente e os
seus impactos);
2 Que mensagem: Forma e formato, que tipo de meio será usado, desde pequenos
textos a imagens, metáforas, vídeos, entre outros;
3 Quem deve comunicar: Deve ser nomeado um responsável que tenha a autorida-
de e autonomia para comunicar, particularmente com organizações externas;
5 Como comunicar: Que canais devem ser usados para obter maior eficácia na difu-
são da mensagem (por exemplo: mensagens de correio eletrónico e protetores de
ecrã);
127
6 Quando comunicar: A comunicação deve ser regularmente exercitada em condi-
ções comuns (por exemplo: divulgação da política de segurança da informação),
mas poderá ter frequências e modos de atuação muito diferentes em contexto de
incidente.
Evidências
1 Documentos de suporte ao processo de gestão de incidentes;
R.N. COBIT 5 DE.PD-5 - Os processos de deteção devem ser objeto de melhoria contínua
APO11.06,
APO12.06,
DSS04.05;
ISO/IEC Descrição
27001:2013
A.16.1.6; A organização deve garantir que aprende com os incidentes que ocorrem nas suas redes e
NIST SP 800-53 sistemas de informação, identificando medidas operacionais e/ou processuais que possam
Rev. 4, CA-2, CA-7,
PL-2, RA-5, SI-4,
melhorar a capacidade de deteção de novos incidentes.
PM-14.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve executar:
1 Procedimento de revisão e aprendizagem de processos de deteção de eventos;
Evidências
1 Plano de melhoria dos processos de deteção;
128
4.6.1 RS.PR Planeamento da Resposta
R.N. CIS CSC 19; RS.PR-1 - O plano de resposta deve ser executado durante ou após a ocorrência
COBIT 5 de um incidente
APO12.06,
BAI01.10;
ISO/IEC
27001:2013 Descrição
A.16.1.5;
NIST SP 800-53 A organização deve sistematizar o seu processo de resposta a incidentes, por forma a ga-
Rev. 4 CP-2, CP-10, rantir uma correta alocação de recursos (humanos, tecnológicos e processuais) na resolu-
IR-4, IR-8.
ção do mesmo.
A resolução dos incidentes deve seguir um processo sistematizado, no âmbito do qual tem
de ser identificado um responsável pelo seu tratamento.
No processo de análise de evidências de um incidente, é relevante garantir-se a integridade
das evidências analisadas e recolhidas.
Implementação Técnica
1 Plataforma de resposta a incidentes.
Implementação Processual
A organização deve:
1 Implementar um processo de resposta a incidentes, que inclua as fases de con-
tenção e erradicação;
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
130
4.6.2 RS.CO Comunicações
R.N. CIS CSC 19; RS.CO-1 - Na resposta a um incidente, os colaboradores devem conhecer os
COBIT 5 seus papéis e a ordem de execução de atividades
EDM03.02,
APO01.02,
APO12.03;
ISO/IEC Descrição
27001:2013
A.6.1.1, A.7.2.2, Na resposta a um incidente, a organização deve garantir que os colaboradores envolvidos
A.16.1.1; têm conhecimento de quem são as partes interessadas relevantes envolvidas, do seu papel
NIST SP 800-53 no processo de resposta a incidentes e dos passos de execução para resolução do mesmo.
Rev. 4 CP-2, CP-3,
IR-3, IR-8.
Implementação Técnica
1 Plataforma de resposta a incidentes.
Implementação Processual
A organização deve, no seu processo de resposta a incidentes, identificar:
1 Os passos de execução da resposta a incidentes;
2 As partes interessadas;
Evidências
1 Documento de suporte ao processo de resposta a incidentes;
R.N. CIS CSC 19; RS.CO-2 - Os incidentes devem ser reportados de acordo com critérios estabe-
COBIT 5 lecidos
DSS01.03;
ISO/IEC
27001:2013
A.6.1.3, A.16.1.2; Descrição
NIST SP 800-53
Rev. 4 AU-6, IR-6, A organização deve estabelecer e divulgar, às partes interessadas relevantes, os canais ade-
IR-8. quados para se reportarem incidentes e deve, também, estabelecer a tipificação de inci-
dentes de segurança da informação.
131
Implementação Técnica
1 Plataforma de resposta a incidentes.
Implementação Processual
Evidências
1 Documentos de suporte ao processo de resposta a incidentes;
R.N. CIS CSC 19; RS.CO-3 - As informações devem ser partilhadas de acordo com o plano de res-
COBIT 5 posta
DSS03.04;
ISO/IEC
27001:2013
A.16.1.2, Cláusula Descrição
7.4, Cláusula
16.1.2; A organização deve divulgar às partes interessadas relevantes, utilizando os canais adequa-
NIST SP 800-53 dos, as informações referentes aos incidentes. Esta ação tem como objetivo ajudar as par-
Rev. 4 CA-2, CA-7, tes interessadas a detetar, conter e solucionar problemas semelhantes nos seus sistemas
CP-2, IR-4, IR-8,
PE-6, RA-5, SI-4. de informação.
A estratégia de comunicação deve ser identificada num plano de comunicação produzido
para o efeito. O plano poderá ser consolidado com outros planos de comunicação existen-
tes na organização.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Identificar o plano de comunicação a adotar. O plano poderá ser consolidado com
outros planos de comunicação existentes;
132
2 Identificar as partes interessadas relevantes, pelas quais deve ser disseminada a
informação sobre incidentes;
Evidências
1 Registos da identificação das principais partes interessadas;
R.N. CIS CSC 19; RS.CO-4 - A coordenação com as partes interessadas deve ocorrer conforme os
COBIT 5 planos de resposta
DSS03.04;
ISO/IEC
27001:2013 Cláu-
sula 7.4; Descrição
NIST SP 800-53
Rev. 4 CP-2, IR-4, A organização deve implementar um plano de comunicação, de coordenação e de escalo-
IR-8. namento de incidentes, alinhado com a categorização e criticidade dos mesmos. O plano
poderá ser consolidado com outros planos de comunicação que a organização disponha.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve, no âmbito do seu plano de resposta a incidentes, identificar a seguinte
informação:
1 As partes interessadas relevantes;
133
e. Como comunicar: Que canais devem ser usados para obter maior eficá-
cia na difusão da mensagem (por exemplo: mensagens de correio ele
trónico e protetores de ecrã);
f. Quando comunicar: A comunicação deve ser regularmente exercitada em
condições comuns (por exemplo: divulgação da política de segurança da
informação), mas poderá ter frequências e modos de atuação muito dife-
rentes em contexto de incidente;
g. Ponto único de contacto de cada parte interessada;
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
R.N. CIS CSC 19; RS.CO-5 - Deve ocorrer partilha voluntária de informação com partes interessa-
COBIT 5 BAI08.04; das externas
ISO/IEC
27001:2013
A.6.1.4;
NIST SP 800-53
Descrição
Rev. 4 SI-5, PM-15.
No processo de resposta a um incidente, a organização deve identificar qual a informação
que tem de ser partilhada com as partes interessadas externas, para se alcançar uma cons-
ciência mais abrangente sobre cibersegurança.
Nestas situações, a organização deve partilhar informações sobre indicadores de compro-
misso a grupos de interesse, para que estes possam, também, beneficiar da partilha e me-
lhorar tempos de resposta a identificar, detetar, conter e erradicar essas ameaças na sua
circunscrição e no seu círculo de influência.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Manter uma lista atualizada das partes interessadas relevantes;
2 Ter canais seguros estabelecidos com os pontos de contacto das partes interessa-
das externas relevantes, para partilha de informação de forma segura.
134
Evidências
1 Registos com contactos de reguladores e grupos de interesse técnico e legislativo;
2 Plano de comunicação.
R.N. CIS CSC 4, 6, RS.AN-1 - As notificações dos sistemas de deteção devem ser investigadas
8, 19;
COBIT 5 DSS02.04,
DSS02.07;
ISO/IEC
Descrição
27001:2013
A.12.4.1, A.12.4.3, A organização deve garantir que os eventos originados nos sistemas de deteção são anali-
A.16.1.5; sados, categorizados e tratados de forma sistematizada. A organização deve identificar que
NIST SP 800-53 eventos devem evoluir para incidentes.
Rev. 4 AU-6, CA-7,
IR-4, IR-5, PE-6,
SI-4.
Implementação Técnica
1 Plataforma de gestão e correlação de eventos.
Implementação Processual
A organização deve:
1 Monitorizar os eventos gerados nos sistemas de deteção;
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
135
R.N. COBIT 5 RS.AN-2 - O impacto do incidente deve ser avaliado
DSS02.02;
ISO/IEC
27001:2013
A.16.1.4, A.16.1.6; Descrição
NIST SP 800-53
Rev. 4 CP-2, IR-4. No processo de categorização dos incidentes, a organização deve avaliar o impacto que
os incidentes causam aos seus ativos e, consequentemente, à sua operação, usando essa
avaliação para definir qual a severidade a atribuir ao incidente.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Definir níveis de impacto de incidentes, tendo em conta o impacto que os mes-
mos podem causar no contexto definido;
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
Implementação Técnica
1 Gestão e correlação de eventos;
136
Implementação Processual
Para o efeito, a organização deve garantir:
1 Procedimentos que permitam a identificação, coleta e aquisição de registos e in-
formação;
Evidências
1 Documentos de suporte ao processo de gestão e correlação de eventos;
R.N. CIS CSC 19; RS.AN-4 - Os incidentes devem ser categorizados de acordo com o plano de res-
COBIT 5 DSS02.02; posta
ISO/IEC
27001:2013
A.16.1.4;
NIST SP 800-53
Descrição
Rev. 4 CP-2, IR-4,
IR-5, IR-8. A organização deve garantir que a categorização dos incidentes é efetuada de acordo com
as regras definidas no seu plano de resposta a incidentes.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Definir a taxonomia de categorização de incidentes, tendo em conta o tipo de
incidente. Por exemplo, seguindo a classificação da Taxonomia Nacional para a
classificação de incidentes1 na sua atual redação:
a. Malware;
b. Disponibilidade;
c. Recolha de Informação;
d. Tentativa de Intrusão;
e. Intrusão;
f. Segurança da Informação;
g. Fraude;
h. Conteúdo Abusivo;
i. Outro.
Evidências
1 Documentos de suporte ao plano de resposta a incidentes: Taxonomia de catego-
rização de incidente;
R.N. CIS CSC 4, RS.AN-5 - A organização deve definir processos para receber, analisar e respon-
19; der a vulnerabilidades provenientes de fontes internas e externas
COBIT 5
EDM03.02,
DSS05.07;
NIST SP 800-53 Descrição
Rev. 4 SI-5, PM-
15. A organização deve ter definido um processo formal para receber a submissão de vulnera-
bilidades, provenientes de fontes internas ou externas (por exemplo: testes internos, rela-
tórios de segurança ou investigadores de segurança).
Cada submissão deve ser analisada, verificada e, no caso de ser real, deve seguir o processo
de resposta a vulnerabilidades definido pela organização.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Dispor de um processo para submissão de vulnerabilidades, disponível de forma
interna e externa;
Evidências
1 Documento de suporte ao processo de gestão de vulnerabilidades;
138
4.6.4 RS.MI Mitigação
Implementação Processual
A organização deve:
1 Ter capacidade para investigar e tomar a decisão sobre a direção a tomar:
a. Análise de malware;
b. Análise forense (recolha, investigação e custódia);
c. Análise e correlação de registos;
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
139
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve:
1 Conter o incidente (bloquear contas, serviços e websites, segregar redes ou con-
tas de utilizadores, suspender o acesso à internet, alterar palavras-passe, fechar
portos de comunicação e desligar sistemas da rede de comunicações);
3 Erradicar:
a. Remover o malware usado no ataque;
b. Aplicar atualizações de segurança;
c. Restaurar as cópias de segurança que forem necessárias;
d. Forçar alterações de palavras-passe e/ou requerer segundos fatores de
autenticação.
4 Documentar:
a. Que sistemas foram alvo de comprometimento;
b. Efetuar uma análise de causa raiz;
c. Que informação foi perdida ou exfiltrada.
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
R.N. CIS CSC 4; RS.MI-3 - As novas vulnerabilidades identificadas devem ser mitigadas ou docu-
COBIT 5 mentadas como riscos aceites
APO12.06;
ISO/IEC
27001:2013
A.12.6.1; Descrição
NIST SP 800-53
Rev. 4 CA-7, RA-3, As novas vulnerabilidades identificadas devem ser formalmente avaliadas pela organização,
RA-5. no âmbito das suas atividades de gestão de vulnerabilidades. Deve ser identificado pela
organização qual o tratamento a efetuar às vulnerabilidades encontradas.
Implementação Técnica
Não aplicável.
140
Implementação Processual
A organização deve avaliar novas vulnerabilidades:
1 E remediar a mesmas;
Evidências
1 Documentos que sustentam o processo de gestão de vulnerabilidades;
R.N. COBIT 5 RS.ME-1 - Os planos de resposta a incidentes devem incorporar as lições apren-
BAI01.13; didas
ISO/IEC
27001:2013
A.16.1.6, Cláusula
10; Descrição
NIST SP 800-53
Rev. 4 CP-2, IR-4, A organização deve efetuar uma observação dos incidentes ocorridos, após a finalização
IR-8. dos mesmos, para poder identificar possíveis lições aprendidas.
A organização deve promover sessões de trabalho com a equipa de resposta a incidentes,
onde deve ser discutido o que foi aprendido no incidente. Nestas sessões de trabalho, deve
ser analisado e documentado tudo o que é conhecido sobre o incidente, identificando-se o
que funcionou bem e o que precisa de ser melhorado no plano de resposta, para tornar a
organização e os seus sistemas mais resilientes no tratamento de incidentes futuros.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve implementar um plano de melhoria com base nas lições aprendidas,
como por exemplo:
1 Que alterações podem ser efetuadas para melhorar a segurança;
141
5 Que fragilidades foram exploradas;
6 Como se garante que não volta a acontecer.
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve atualizar:
1 A lista de redes e sistemas de informação de suporte aos serviços críticos;
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
142
4.7.1 RC.PR Plano de Recuperação
R.N. CIS CSC 10; RC.PR-1 - Os planos de resposta a incidentes devem incorporar as lições apren-
COBIT 5 didas
APO12.06,
DSS02.05,
DSS03.04;
ISO/IEC Descrição
27001:2013
A.16.1.5; A organização deve sistematizar o seu processo de recuperação de incidentes, por forma a
NIST SP 800-53 garantir uma correta alocação de recursos (humanos/tecnológicos e processuais) à resolu-
Rev. 4 CP-10, IR-4, ção dos mesmos.
IR-8.
No processo de recuperação de um incidente de segurança da informação, é relevante
garantir a integridade e disponibilidade dos sistemas.
Implementação Técnica
1 Plataforma de cópias de segurança e restauro.
Implementação Processual
A organização deve:
1 Implementar um processo de recuperação de incidentes;
Evidências
1 Documentos de suporte ao plano de resposta a incidentes;
144
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve implementar um plano de melhoria com base nas lições aprendidas.
A organização deve contemplar:
1 Avaliação da eficácia dos planos de recuperação existentes;
Evidências
1 Documentos de suporte ao processo de recuperação de incidentes;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve atualizar:
1 A lista de prioridades das redes e sistemas de informação que suportam os servi-
ços críticos;
145
3 As listas de contactos dos responsáveis técnicos;
Evidências
1 Documentos de suporte ao plano de recuperação de incidentes;
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve definir um plano de comunicação com as partes interessadas que iden-
tifique:
1 O que comunicar: Que conteúdo (por exemplo: a forma adequada como foi trata-
do um incidente de cibersegurança);
2 Que mensagem: Forma e formato, que tipo de meio será usado, desde pequenos
textos a imagens, metáforas, vídeos, entre outros;
3 Quem deve comunicar: Deve ser nomeado um responsável que tem a autoridade
e autonomia para comunicar, particularmente com organizações externas;
5 Como comunicar: Que canais devem ser usados para obter a melhor eficácia na
difusão da mensagem (por exemplo: mensagens de correio eletrónico e proteto-
res de ecrã);
146
6 Quando comunicar: A comunicação deve ser regularmente exercitada em condi-
ções comuns (por exemplo: divulgação da política de segurança da informação),
mas poderá ter frequências e modos de atuação muito diferentes em contexto de
incidente.
Evidências
1 Plano de comunicação associado à recuperação de incidentes.
R.N. COBIT 5 RC.CO-2 - As atividades de recuperação devem ser comunicadas às partes in-
APO12.06; teressadas, internas e externas, bem como às equipas executivas e de
ISO/IEC gestão
27001:2013 Cláu-
sula 7.4;
NIST SP 800-53 Descrição
Rev. 4 CP-2, IR-4.
A organização deve garantir que as partes interessadas, internas e externas, são informadas
no caso de existência de incidentes que assim o justifiquem.
A organização deve definir uma estratégia de comunicação baseada num plano de comuni-
cação produzido para o efeito. Este poderá ser consolidado com outros planos de comuni-
cação existentes na organização.
Implementação Técnica
Não aplicável.
Implementação Processual
A organização deve identificar:
1 Procedimento de escalonamento de incidentes;
Evidências
1 Plano de comunicação documentado e disseminado pelos responsáveis pela sua
execução.
147
5.1 Introdução
Atualmente, quase todas as organizações têm equipamentos de segurança nas suas re-
des de comunicações, como firewall, sistemas de deteção de intrusão, filtros de pedidos
de resolução de nomes, proteção contra mensagens de correio eletrónico contendo spam
ou phishing, ferramentas de deteção de ameaças persistentes, entre outras. Estes equi-
pamentos são uma primeira linha de defesa, constituindo medidas básicas para a segu-
rança dos colaboradores e das redes e sisteAtualmente, quase todas as organizações têm
equipamentos de segurança nas suas redes de comunicações, como firewall, sistemas de
deteção de intrusão, filtros de pedidos de resolução de nomes, proteção contra mensagens
de correio eletrónico contendo spam ou phishing, ferramentas de deteção de ameaças per-
sistentes, entre outras. Estes equipamentos são uma primeira linha de defesa, constituindo
medidas básicas para a segurança dos colaboradores e das redes e sistemas de informação
da organização, contra ciberataques e tráfego não regulado da internet.
Serão estas tecnologias, por si só, suficientes para se garantir a segurança da informação
da organização?
Não é possível dar-se uma resposta concreta a esta questão, tendo em conta que a mesma
depende de diversas variáveis de avaliação, que são alteradas de acordo com a tecnologia,
recursos, contexto e ambiente envolvente da organização. Na prática, estes equipamentos
providenciam uma proteção imediata contra as ameaças conhecidas (se devidamente pa-
rametrizados), mas poderão ser ineficientes com o que ainda é desconhecido.
Segundo o MITRE1, a lista de CVEs, ou seja, o número de vulnerabilidades publicadas por
ano, tem aumentado de forma significativa nos últimos anos, como se pode constatar no
gráfico abaixo.
Cada uma destas possíveis vulnerabilidades existentes nas redes e sistemas de informação
da organização pode ser explorada por uma nova ameaça.
Os perímetros de defesa são habitualmente estáticos e não são atualizados de forma contí-
¹ https://cve.mitre.org/
149
nua. Daqui deriva outro grande desafio para as organizações, tendo em conta que as amea-
ças existentes originadas no ciberespaço são bastante dinâmicas.
Como resposta a estes desafios, torna-se necessário ter uma equipa especializada e multi-
disciplinar que possa servir a organização, atualizando de forma continuada a proteção das
suas redes e sistemas de informação contra novas ameaças de cibersegurança ou mesmo
evoluções de ameaças antigas.
² https://www.cnpd.pt/bin/rgpd/rgpd.html, https://gdpr.eu/
150
• Suportar a organização na estratégia e desempenho e monitorização das tecnolo-
gias de informação;
O CISO tem um papel fulcral na análise do QNRCS e na identificação das medidas que
possam ser adequadas para implementação da sua organização. Deve acompanhar todo o
processo de implementação, definição de prioridades e atividades de melhoria contínua,
que garantam que a organização está preparada e adequadamente resiliente em termos de
segurança da informação e cibersegurança.
Existem diversos modelos de SOC que vão desde o virtual, com recursos alocados a tempo
parcial e sem exclusividade, até ao modelo multifunções onde as equipas realizam não só
as tarefas de segurança, mas também tarefas de operação e monitorização das redes e
sistemas de informação. De seguida, identificamos os tipos mais comuns de SOC e quais as
suas características mais relevantes:
³ https://www.gartner.com/en/newsroom/press-releases/2017-10-12-security-operations-center
s-and-their-role-in-cybersecurity
151
SOC Virtual
1 Sem instalações dedicadas;
SOC Dedicado
1 Instalações dedicadas;
3 Operação 24x7;
4 Reativo e pró-ativo.
SOC Distribuído
1 Instalações dedicadas;
4 Reativo e pró-ativo;
SOC de Comando
1 Instalações dedicadas;
3 Operação 9x5;
4 Reativo e pró-ativo;
SOC Multifunções
1 Instalações dedicadas;
152
3 Operação 24x7;
4 Reativo e pró-ativo;
SOC de Fusão
1 Instalações dedicadas;
3 Operação 24x7;
4 Reativo e pró-ativo;
SOC Externalizado
1 Sem instalações dedicadas;
3 Operação 24x7;
4 Reativo e pró-ativo;
2 Focar o alinhamento dos entregáveis do SOC com a missão, visão, valores, estra-
tégias e objetivos da organização;
153
5.4 Constituição de CSIRT
A abreviatura CSIRT significa Computer Security Incident Response Team (Equipa de Respos-
ta a Incidentes de Segurança Informática).
Trata-se de um termo predominantemente utilizado na Europa e que corresponde ao ter-
mo protegido CERT, registado nos EUA pelo CERT Coordination Center (CERT/CC) (Centro
de Coordenação CERT) da Carnegie Mellon University.
Uma equipa de CSIRT é uma equipa de peritos de segurança informática que tem como
principal atividade responder aos incidentes. Presta os serviços necessários para os gerir e
ajudar os seus utilizadores a recuperarem das violações da segurança que ocorram.
Ter ao serviço uma equipa de segurança informática dedicada ajuda as organizações a re-
duzir o impacto e a prevenir os incidentes graves.
Outros benefícios possíveis são os seguintes:
1 Ter uma coordenação centralizada para as questões de segurança informática na
organização, com um ponto único de contacto;
Como referência internacional, o RFC23502 da IETF (Internet Engineering Task Force) docu-
menta a estrutura de um CSIRT, que deve ser preenchida e publicada por forma a facilitar a
comunicação sobre políticas, procedimentos e serviços à comunidade abrangida, ou mes-
mo a outras organizações e/ou equipas de resposta a incidentes.
A nível europeu, e com uma definição mais recente, podemo-nos inspirar na ENISA3 e clas-
sificar os serviços típicos de uma equipa de CSIRT em três categorias:
⁴ https://www.enisa.europa.eu/publications/csirt-setting-up-guide-in-portugese/at_download/
fullReport
⁵ https://tools.ietf.org/html/rfc2350#appendix-E
⁶ https://www.enisa.europa.eu/topics/csirt-cert-services
154
Serviços reativos
1 Alertas e avisos;
2 Resposta a incidentes:
a. Análise de incidentes;
b. Resposta a incidentes no local;
c. Suporte a resposta a incidentes;
d. Coordenação de resposta a incidentes;
3 Gestão de vulnerabilidades:
a. Análise de vulnerabilidades;
b. Resposta a vulnerabilidades;
c. Coordenação da resposta a vulnerabilidades;
4 Gestão de artefactos:
a. Análise de artefactos;
b. Resposta a artefactos;
c. Coordenação da resposta a artefactos.
Serviços Proativos
1 Campanhas de sensibilização;
2 Acompanhamento de tecnologia;
3 Consultoria de segurança;
4 Sensibilização em segurança;
5 Treino e formação;
155
A criação de um CSIRT permite às organizações prepararem a sua capacidade de resposta a
incidentes de segurança da informação e cibersegurança. Permite, igualmente, à organiza-
ção incrementar a sua capacidade de resposta a incidentes de segurança de informação, de
forma conjunta com outras partes interessadas, tendo em conta que a estrutura do CSIRT
releva a importância da partilha de informação de incidentes de segurança de informação
durante o ciclo de vida dos processos de gestão inerentes.
Portugal dispõe de uma Rede Nacional de CSIRT1, composta por organizações do setor pú-
blico e privado, que tem como objetivo:
Em termos de maturidade das equipas CSIRT, existe já o modelo SIM3 (Security Incident
Management Maturity Model) que se baseia em quatro vetores: organizacional, humano,
ferramentas e processos. Este modelo de maturidade inclui a avaliação de 44 diferentes
parâmetros de uma equipa nos referidos quatro vetores, e permitirá a qualquer equipa,
depois de constituída e de operar durante algum tempo, realizar uma autoavaliação. Esta
circunstância potenciará a melhoria contínua da equipa.
⁷ https://www.redecsirt.pt/
156
O quadro seguinte serve de apoio para análise das informações de referência que supor-
tam as subcategorias do QNRCS.
158
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
CIS CSC 19
ID.GV-1 – A política de COBIT 5 APO01.03, APO13.01, EDM01.01, EDM01.02
segurança da informa- ISO/IEC 27001:2013 A.5.1.1
Governação (ID.GV)
ção deve ser definida e NIST SP 800-53 Rev. 4 -1 controls from all security con-
comunicada trol families
CIS CSC 19
ID.GV-2 – Os requisitos COBIT 5 BAI02.01, MEA03.01, MEA03.04
legais e regulamentares ISO/IEC 27001:2013 A.18.1.1, A.18.1.2, A.18.1.3,
para a cibersegurança A.18.1.4, A.18.1.5
devem ser cumpridos NIST SP 800-53 Rev. 4 -1 controls from all security con-
trol families
CIS CSC 4
ID.AR-1 – As vulnera- COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04,
bilidades dos ativos DSS05.01, DSS05.02
devem ser identificadas ISO/IEC 27001:2013 A.12.6.1, A.18.2.3
e documentadas NIST SP 800-53 Rev. 4 CA-2, CA-7, CA-8, RA-3, RA-5,
SA-5, SA-11, SI-2, SI-4, SI-5
ID.AR-2 – A organização
deve partilhar informa- CIS CSC 4
ções sobre ameaças COBIT 5 BAI08.01
de cibersegurança com ISO/IEC 27001:2013 A.6.1.4
grupos de interesse da NIST SP 800-53 Rev. 4 SI-5, PM-15, PM-16
Avaliação de risco (ID.AR)
especialidade
ID.AR-3 – As ameaças
internas e externas CIS CSC 4
devem ser identificadas COBIT 5 APO12.01, APO12.02, APO12.03, APO12.04
e documentadas na ISO/IEC 27001:2013 Clause 6.1.2
metodologia de gestão NIST SP 800-53 Rev. 4 RA-3, SI-5, PM-12, PM-16
do risco
ID.AR-4 – A gestão do
risco deve ser efetuada
CIS CSC 4
com base na análise de
COBIT 5 APO12.02
ameaças, vulnerabilida-
ISO/IEC 27001:2013 A.12.6.1
des, probabilidades e
NIST SP 800-53 Rev. 4 RA-2, RA-3, PM-16
impactos
ID.AR-5 – A organiza-
CIS CSC 4
ção deve garantir que
COBIT 5 APO12.05, APO13.02
as respostas aos riscos
ISO/IEC 27001:2013 Clause 6.1.3
são identificadas e
NIST SP 800-53 Rev. 4 PM-4, PM-9
priorizadas
CIS CSC 4
Estratégia de Gestão de Risco (ID.GR)
159
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
CIS CSC 4
ID.GL-1 – A organização
COBIT 5 APO10.01, APO10.04, APO12.04, APO12.05,
deve definir, avaliar e
APO13.02, BAI01.03, BAI02.03, BAI04.02
gerir processos de ges-
ISO/IEC 27001:2013 A.15.1.1, A.15.1.2, A.15.1.3,
tão do risco da cadeia
A.15.2.1, A.15.2.2
logística
NIST SP 800-53 Rev. 4 SA-9, SA-12, PM-9
COBIT 5 APO10.01, APO10.02, APO10.04, APO10.05,
ID.GL – Gestão do Risco da Cadeia Logística ID.GL-2 – A organização APO12.01, APO12.02, APO12.03, APO12.04, APO12.05,
deve avaliar o risco APO12.06, APO13.02, BAI02.03
da cadeia logística de ISO/IEC 27001:2013 A.15.2.1, A.15.2.2
cibersegurança NIST SP 800-53 Rev. 4 RA-2, RA-3, SA-12, SA-14, SA-15,
PM-9
ID.GL-3 – Os contratos
COBIT 5 APO10.01, APO10.02, APO10.03, APO10.04,
com fornecedores de-
APO10.05
vem respeitar o plano
ISO/IEC 27001:2013 A.15.1.1, A.15.1.2, A.15.1.3
de gestão do risco para
NIST SP 800-53 Rev. 4 SA-9, SA-11, SA-12, PM-9
a cadeia logística
COBIT 5 APO10.01, APO10.03, APO10.04, APO10.05,
MEA01.01, MEA01.02, MEA01.03, MEA01.04,
ID.GL-4 – Os fornece-
MEA01.05
dores devem ser perio-
ISO/IEC 27001:2013 A.15.2.1, A.15.2.2
dicamente avaliados
NIST SP 800-53 Rev. 4 AU-2, AU-6, AU-12, AU-16, PS-7,
SA-9, SA-12
ID.GL-5 – O plano de
CIS CSC 19, 20
resposta e recupera-
COBIT 5 DSS04.04
ção de desastre deve
ISO/IEC 27001:2013 A.17.1.3
ser exercitado com o
NIST SP 800-53 Rev. 4 CP-2, CP-4, IR-3, IR-4, IR-6, IR-8,
acompanhamento de
IR-9
fornecedores
160
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
PROTEGER (PR)
PR.GA-1 – O ciclo de COBIT 5 DSS05.04, DSS06.03
vida de gestão de ISO/IEC 27001:2013 A.9.2.1, A.9.2.2, A.9.2.3, A.9.2.4,
identidades deve ser A.9.2.6, A.9.3.1, A.9.4.2, A.9.4.3
definido NIST SP 800-53 Rev. 4 AC-1, AC-2, IA-1, IA-2, IA-3, IA-4,
IA-5, IA-6, IA-7, IA-8, IA-9, IA-10, IA-11
mas de informação
NIST SP 800-53 Rev. 4 PE-2, PE-3, PE-4, PE-5, PE-6, PE-8
CIS CSC 12
COBIT 5 APO13.01, DSS01.04, DSS05.03
PR.GA-3 – A organiza-
ISO/IEC 27001:2013 A.6.2.1, A.6.2.2, A.11.2.6,
ção deve gerir os seus
A.13.1.1, A.13.2.1
acessos remotos
NIST SP 800-53 Rev. 4 AC-1, AC-17, AC-19, AC-20, SC-
15
161
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
162
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
PR.SD-3 – A organiza-
ção deve gerir formal- CIS CSC 1
mente os ativos duran- COBIT 5 BAI09.03
te os procedimentos de ISO/IEC 27001:2013 A.8.2.3, A.8.3.1, A.8.3.2, A.8.3.3,
remoção, transferência A.11.2.5, A.11.2.7
e aprovisionamento NIST SP 800-53 Rev. 4 CM-8, MP-6, PE-16
dos mesmos
PR.SD-4 – A organiza-
ção deve providenciar
CIS CSC 1, 2, 13
a capacidade adequada
COBIT 5 APO13.01, BAI04.04
PR.SD – Segurança de Dados
163
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
PR.PI-1 – Deve ser
CIS CSC 3, 9, 11
criada e mantida uma
COBIT 5 BAI10.01, BAI10.02, BAI10.03, BAI10.05
configuração base de
ISO/IEC 27001:2013 A.12.1.2, A.12.5.1, A.12.6.2,
redes e sistemas de
A.14.2.2, A.14.2.3, A.14.2.4
informação que incor-
NIST SP 800-53 Rev. 4 CM-2, CM-3, CM-4, CM-5, CM-6,
pore os princípios de
CM-7, CM-9, SA-10
segurança
CIS CSC 18
PR.PI-2 – Deve ser
COBIT 5 APO13.01, BAI03.01, BAI03.02, BAI03.03
implementado um
ISO/IEC 27001:2013 A.6.1.5, A.14.1.1, A.14.2.1,
ciclo de vida de desen-
A.14.2.5
volvimento seguro de
NIST SP 800-53 Rev. 4 PL-8, SA-3, SA-4, SA-8, SA-10, SA-
software
11, SA-12, SA-15, SA-17, SI-12, SI-13, SI-14, SI-16, SI-17
CIS CSC 3, 11
PR.PI-3 – Deve ser
COBIT 5 BAI01.06, BAI06.01
implementado um
ISO/IEC 27001:2013 A.12.1.2, A.12.5.1, A.12.6.2,
processo de gestão de
A.14.2.2, A.14.2.3, A.14.2.4
alterações
NIST SP 800-53 Rev. 4 CM-3, CM-4, SA-10
PR.PI – Procedimentos e Processos de Proteção da Informação
164
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
CIS CSC 5, 16
PR.PI-11 – A cibersegu- COBIT 5 APO07.01, APO07.02, APO07.03, APO07.04,
rança deve ser contem- APO07.05
plada nos processos ISO/IEC 27001:2013 A.7.1.1, A.7.1.2, A.7.2.1, A.7.2.2,
de gestão de recursos A.7.2.3, A.7.3.1, A.8.1.4
humanos NIST SP 800-53 Rev. 4 PS-1, PS-2, PS-3, PS-4, PS-5, PS-6,
PS-7, PS-8, SA-21
CIS CSC 4, 18, 20
PR.PI-12 – Deve ser de-
COBIT 5 BAI03.10, DSS05.01, DSS05.02
finido e implementado
ISO/IEC 27001:2013 A.12.6.1, A.14.2.3, A.16.1.3,
um processo de gestão
A.18.2.2, A.18.2.3
de vulnerabilidades
NIST SP 800-53 Rev. 4 RA-3, RA-5, SI-2
165
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
PR.MA-1 – As ativida-
des de manutenção e
reparação dos ativos da COBIT 5 BAI03.10, BAI09.02, BAI09.03, DSS01.05
organização devem ser ISO/IEC 27001:2013 A.11.1.2, A.11.2.4, A.11.2.5,
PR.MA – Manutenção
realizadas e registadas A.11.2.6
em programas e planos NIST SP 800-53 Rev. 4 MA-2, MA-3, MA-5, MA-6
aprovados e contro-
lados
PR.MA-2 – As opera-
ções de manutenção CIS CSC 3, 5
remota das redes COBIT 5 DSS05.04
devem ser revistas, ISO/IEC 27001:2013 A.11.2.4, A.15.1.1, A.15.2.1
aprovadas, executadas NIST SP 800-53 Rev. 4 MA-4
e registadas
PR.TP-1 – Os registos CIS CSC 1, 3, 5, 6, 14, 15, 16
de auditoria e de COBIT 5 APO11.04, BAI03.05, DSS05.04, DSS05.07,
histórico devem ser MEA02.01
documentados, imple- ISO/IEC 27001:2013 A.12.4.1, A.12.4.2, A.12.4.3,
mentados e revistos de A.12.4.4, A.12.7.1
acordo com as políticas NIST SP 800-53 Rev. 4 AU Family
PR.TP-2 – Os suportes CIS CSC 8, 13
de dados amovíveis de- COBIT 5 APO13.01, DSS05.02, DSS05.06
vem ser protegidos e a ISO/IEC 27001:2013 A.8.2.1, A.8.2.2, A.8.2.3, A.8.3.1,
sua utilização deve ser A.8.3.3, A.11.2.9
restrita, de acordo com NIST SP 800-53 Rev. 4 MP-2, MP-3, MP-4, MP-5, MP-7,
PR.TP – Tecnologia de Proteção
166
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
DE.AE-1 – A organiza-
ção deve definir e gerir CIS CSC 1, 4, 6, 12, 13, 15, 16
DETETAR (DE) um modelo de referên- COBIT 5 DSS03.01
cia de operações de ISO/IEC 27001:2013 A.12.1.1, A.12.1.2, A.13.1.1,
rede e fluxos de dados A.13.1.2
esperados para utiliza- NIST SP 800-53 Rev. 4 AC-4, CA-3, CM-2, SI-4
dores e sistemas
DE.AE-2 – Os eventos
detetados devem ser CIS CSC 3, 6, 13, 15
DE.AE – Anomalias e Eventos
CIS CSC 6, 19
DE.AE-5 – Devem ser
COBIT 5 APO12.06, DSS03.01
definidos os limites de
ISO/IEC 27001:2013 A.16.1.4
alerta para incidentes
NIST SP 800-53 Rev. 4 IR-4, IR-5, IR-8
167
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
DE.MC-1 – As redes e
CIS CSC 1, 7, 8, 12, 13, 15, 16
sistemas de informação
COBIT 5 DSS01.03, DSS03.05, DSS05.07
devem ser monitoriza-
NIST SP 800-53 Rev. 4 AC-2, AU-12, CA-7, CM-3, SC-5,
dos para detetar po-
SC-7, SI-4
tenciais incidentes
DE.MC-2 – O ambiente
físico deve ser monito- COBIT 5 DSS01.04, DSS01.05
rizado para se detetar ISO/IEC 27001:2013 A.11.1.1, A.11.1.2
potenciais incidentes NIST SP 800-53 Rev. 4 CA-7, PE-3, PE-6, PE-20
de segurança
DE.MC-3 – A atividade CIS CSC 5, 7, 14, 16
dos colaboradores COBIT 5 DSS05.07
deve ser monitorizada ISO/IEC 27001:2013 A.12.4.1, A.12.4.3
para se detetar poten- NIST SP 800-53 Rev. 4 AC-2, AU-12, AU-13, CA-7, CM-
DE.MC – Monitorização Contínua de Segurança
168
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
DE.PD-1 – Devem ser
CIS CSC 19
definidos os papéis e
COBIT 5 APO01.02, DSS05.01, DSS06.03
responsabilidades na
ISO/IEC 27001:2013 A.6.1.1, A.7.2.2
deteção de eventos
NIST SP 800-53 Rev. 4 CA-2, CA-7, PM-14
anómalos
DE.PD-2 – As atividades COBIT 5 DSS06.01, MEA03.03, MEA03.04
DE.PD – Processos de Deteção
de deteção devem ISO/IEC 27001:2013 A.18.1.4, A.18.2.2, A.18.2.3
cumprir com todos os NIST SP 800-53 Rev. 4 AC-25, CA-2, CA-7, SA-18, SI-4,
requisitos aplicáveis PM-14
COBIT 5 APO13.02, DSS05.02
DE.PD-3 – Os processos
ISO/IEC 27001:2013 A.14.2.8
de deteção devem ser
NIST SP 800-53 Rev. 4 CA-2, CA-7, PE-3, SI-3, SI-4, PM-
testados
14
DE.PD-4 – Informações CIS CSC 19
sobre deteções de COBIT 5 APO08.04, APO12.06, DSS02.05
eventos devem ser ISO/IEC 27001:2013 A.16.1.2, A.16.1.3
comunicadas NIST SP 800-53 Rev. 4 AU-6, CA-2, CA-7, RA-5, SI-4
DE.PD-5 – Os processos COBIT 5 APO11.06, APO12.06, DSS04.05
de deteção devem ser ISO/IEC 27001:2013 A.16.1.6
objeto de melhoria NIST SP 800-53 Rev. 4, CA-2, CA-7, PL-2, RA-5, SI-4,
contínua PM-14
RS.PR – Planeamento
RESPONDER (RS)
RS.PR-1 – O plano
da Resposta
CIS CSC 19
de resposta deve ser
COBIT 5 APO12.06, BAI01.10
executado durante ou
ISO/IEC 27001:2013 A.16.1.5
após a ocorrência de
NIST SP 800-53 Rev. 4 CP-2, CP-10, IR-4, IR-8
um incidente
RS.CO-1 – Na resposta
a um incidente, os co- CIS CSC 19
laboradores devem co- COBIT 5 EDM03.02, APO01.02, APO12.03
nhecer os seus papéis ISO/IEC 27001:2013 A.6.1.1, A.7.2.2, A.16.1.1
e a ordem de execução NIST SP 800-53 Rev. 4 CP-2, CP-3, IR-3, IR-8
de atividades
RS.CO-2 – Os inciden- CIS CSC 19
tes devem ser repor- COBIT 5 DSS01.03
tados de acordo com ISO/IEC 27001:2013 A.6.1.3, A.16.1.2
RS.CO – Comunicações
169
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
CIS CSC 4, 19
RS.MI-2 – Os incidentes COBIT 5 APO12.06
devem ser mitigados ISO/IEC 27001:2013 A.12.2.1, A.16.1.5
NIST SP 800-53 Rev. 4 IR-4
RS.MI-3 – As novas
vulnerabilidades iden- CIS CSC 4
tificadas devem ser COBIT 5 APO12.06
mitigadas ou docu- ISO/IEC 27001:2013 A.12.6.1
mentadas como riscos NIST SP 800-53 Rev. 4 CA-7, RA-3, RA-5
aceites
RS.ME-1 – Os planos de
COBIT 5 BAI01.13
RS.ME – Melhorias
resposta a incidentes
ISO/IEC 27001:2013 A.16.1.6, Clause 10
devem incorporar as
NIST SP 800-53 Rev. 4 CP-2, IR-4, IR-8
lições aprendidas
RS.ME-2 – As estra-
COBIT 5 BAI01.13, DSS04.08
tégias de resposta a
ISO/IEC 27001:2013 A.16.1.6, Clause 10
incidentes devem ser
NIST SP 800-53 Rev. 4 CP-2, IR-4, IR-8
atualizadas
170
OBJETIVO CATEGORIA SUBCATEGORIA INFORMAÇÕES DE REFERÊNCIA
RC.PR – Plano de
RECUPERAR (RC)
RC.PR-1 – A organiza-
Recuperação
CIS CSC 10
ção deve seguir um
COBIT 5 APO12.06, DSS02.05, DSS03.04
plano de recuperação
ISO/IEC 27001:2013 A.16.1.5
durante ou após um
NIST SP 800-53 Rev. 4 CP-10, IR-4, IR-8
incidente
RC.ME-1 – Os planos
COBIT 5 APO12.06, BAI05.07, DSS04.08
de recuperação devem
RC.ME – Melhorias
ISO/IEC 27001:2013 A.16.1.6, Clause 10
incorporar as lições
NIST SP 800-53 Rev. 4 CP-2, IR-4, IR-8
aprendidas
RC.ME-2 – As estraté-
gias de recuperação COBIT 5 APO12.06, BAI07.08
devem ser continua- ISO/IEC 27001:2013 A.16.1.6, Clause 10
mente revistas e atua- NIST SP 800-53 Rev. 4 CP-2, IR-4, IR-8
lizadas
RC.CO-1 – A organiza-
ção deve implementar COBIT 5 EDM03.02
RC.CO – Comunicações
171
Rua da Junqueira 69,
www.cncs.gov.pt
1300-342 Lisboa
[email protected]
+351 210 497 400