Com o aumento de dispositivos conectados à internet e a preocupação das organizações com a transformação digital em ter seus sistemas cada vez mais interconectados, crescem os riscos de segurança da informação. Devido aos avanços tecnológicos frequentes, o setor de TI de uma organização pode ser considerado essencial para garantir a operação de seus processos de negócio, bem como um parceiro estratégico para a disrupção de processos aplicando novas soluções. Diante do que foi exposto, torna-se impossível manter um ambiente computacional totalmente seguro e livre de ameaças. Pois, pode-se não possuir recursos financeiros ou humanos suficientes para abordar todos os riscos. Consequentemente, riscos de segurança da informação estão presentes nas organizações. Este trabalho consiste em fazer a gestão de riscos em prática utilizando o ServiceNow. Os resultados obtidos mostraram os riscos de um cenário real, e os impactos nos principais processos de negócio da organização se o tratamento dos riscos não forem priorizados e as recomendações não forem aplicadas.

1. CENTRO UNIVERSITÁRIO SOCIESC – UNISOCIESC
CAMPUS MARQUÊS DE OLINDA
LUCAS DE OLIVEIRA NASS
AVALIAÇÃO DE RISCOS EM UMA EMPRESA DE GRANDE PORTE DO
NORTE CATARINENSE UTILIZANDO A FERRAMENTA SERVICENOW
Joinville
2018/2

2. LUCAS DE OLIVEIRA NASS
Este trabalho será apresentado ao Centro
Universitário Sociesc - Unisociesc, como re-
quisito parcial para obtenção do título de
Bacharel em Sistemas de Informação.
Orientador: Prof. Dr. Mehran Misaghi
Joinville
2018/2

3. LUCAS DE OLIVEIRA NASS
AVALIAÇÃO DE RISCOS EM UMA EMPRESA DE GRANDE PORTE DO
NORTE CATARINENSE UTILIZANDO A FERRAMENTA SERVICENOW
Este trabalho foi julgado e aprovado em
sua forma final, sendo examinado pelos
professores da Banca Examinadora.
Joinville, 26 de Novembro de 2018.
Prof. Dr. Mehran Misaghi (Orientador)
Prof. MSc. Leila Regina Techio (membro interno)
Prof. MSc. Francini Reitz (membro interno)

4. AGRADECIMENTOS
Agradeço primeiramente a Deus, por me guiar e iluminar na realização deste
sonho.
A minha namorada, Aline Hilleshein, por todo amor, incentivo e compreensão
neste último ano de faculdade.
Aos programas PROUNI e FIES pela oportunidade de cursar uma faculdade.
Aos professores pelo conhecimento repassado e pela contribuição na minha
formação pessoal e profissional.
Ao professor orientador, Dr. Mehran Misaghi e MSc. Mara Jeanny Ferreira da
Silva, pela paciência e orientação durante a elaboração desse trabalho.
À banca examinadora pelas correções e sugestões.
Aos amigos que estiveram comigo nesta jornada.
A todos que contribuíram direta e indiretamente na minha formação, fica o meu
sentimento de gratidão. Muito obrigado!

5. RESUMO
Com o aumento de dispositivos conectados à internet e a preocupação
das organizações com a transformação digital em ter seus sistemas cada vez
mais interconectados, crescem os riscos de segurança da informação. Devido
aos avanços tecnológicos frequentes, o setor de Tecnologia de Informação (TI)
de uma organização pode ser considerado essencial para garantir a operação de
seus processos de negócio, bem como um parceiro estratégico para a disrupção
de processos aplicando novas soluções. Diante do que foi exposto, torna-se
impossível manter um ambiente computacional totalmente seguro e livre de
ameaças. Pois, pode-se não possuir recursos financeiros ou humanos suficien-
tes para abordar todos os riscos. Consequentemente, riscos de segurança da
informação estão presentes nas organizações. Este trabalho consiste em fazer
a gestão de riscos em prática utilizando o ServiceNow. Os resultados obtidos
mostraram os riscos de um cenário real, e os impactos nos principais processos
de negócio da organização se o tratamento dos riscos não forem priorizados e
as recomendações não forem aplicadas.
Palavras-chave: Segurança da informação, Gestão de Riscos, ServiceNow.

6. ABSTRACT
With the increase of devices connected to the Internet and the concern
of organizations with digital transformation in having their systems more and
more interconnected, the risks of information security grow. Due to frequent
technological advances, an organization Information Technology (IT) sector can
be considered essential to ensure the operation of its business processes, as
well as a strategic partner for the disruption of processes applying new solutions.
In light of the above, it is impossible to maintain a fully secure and threat-free
computing environment. You may not have enough financial or human resources
to cover all the risks. Consequently, information security risks are present in orga-
nizations. This work consists of risk management in practice using ServiceNow.
The results obtained showed the risks of a real scenario and the impacts on the
organization’s main business processes if the risk treatment is not prioritized and
the recommendations are not applied.
Keywords: Information Security, Risk Management, ServiceNow.

7. LISTA DE ILUSTRAÇÕES
Figura 1 – Exemplo de uma matriz de risco semi-quantitativa . . . . . . 19
Figura 2 – Processo de auditoria de segurança da informação . . . . . . 22
Figura 3 – Processo de gestão de riscos de segurança da informação . . 28
Figura 4 – Processo de gestão de riscos de segurança da informação . . 29
Figura 5 – Processo de gestão de riscos . . . . . . . . . . . . . . . . . 33
Figura 6 – Etapas do processo de gestão de riscos . . . . . . . . . . . 38
Figura 7 – Processo de avaliação de risco . . . . . . . . . . . . . . . . 39
Figura 8 – Visão geral do cenário de risco . . . . . . . . . . . . . . . . 40
Figura 9 – Fluxo de trabalho para desenvolver cenários de risco – abor-
dagem sugerida . . . . . . . . . . . . . . . . . . . . . . . . 42
Figura 10 – Macro processo de gerenciamento de riscos do ServiceNow . 46
Figura 11 – Subprocesso para estabelecimento do escopo de perfil para
os riscos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Figura 12 – Escopo de perfis no Gerenciamento de Riscos . . . . . . . . 48
Figura 13 – Gerenciar riscos, declarações de risco e estruturas de risco . 49
Figura 14 – Escopo de perfis no gerenciamento de riscos . . . . . . . . . 50
Figura 15 – Exemplo de escopo de perfis no gerenciamento de riscos . . 51
Figura 16 – Processo de avaliação de riscos . . . . . . . . . . . . . . . . 52
Figura 17 – Processo para transferência de risco . . . . . . . . . . . . . 53
Figura 18 – Processo para aceitação de risco . . . . . . . . . . . . . . . 54
Figura 19 – Processo de monitoramento de risco . . . . . . . . . . . . . 55
Figura 20 – Relação entre o ServiceNow e a NBR ISO/IEC 27005:2011 . 56
Figura 21 – Diagrama representando o cenário onde o estudo de caso foi
aplicado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Figura 22 – Modelo de dependência das classes de perfis . . . . . . . . 58
Figura 23 – Relacionamento entre tipos de perfis e o modelo de depen-
dência das classes de perfis . . . . . . . . . . . . . . . . . . 59
Figura 24 – Dashboard de gerenciamento de riscos . . . . . . . . . . . . 63
Figura 25 – Tipos de integrações utilizadas no ServiceNow . . . . . . . . 64
Figura 26 – Tipos de integrações utilizadas nos processos de negócio . . 65

8. LISTA DE TABELAS
Tabela 1 – Configuração dos critérios de riscos . . . . . . . . . . . . . . 62

9. LISTA DE QUADROS
Quadro 1 – Tipos de planos relacionados à continuidade de negócios . . 36
Quadro 2 – Relacionamento entre tipos de perfis e o modelo de depen-
dência das classes de perfis . . . . . . . . . . . . . . . . . 60
Quadro 3 – Relacionamento controle, perfil e eficácia do controle . . . . 60

10. LISTA DE SIGLAS
ACL Access Control
BCM Business Continuity Management
BCMS Business Continuity Management System
BCP Business Continuity Plan
BCRP Business Continuity and Recovery Planning
CM Crisis Management
COBIT Control Objectives for Information and Related Technology
COSO Committee of Sponsoring Organizations
CSC Centro de Serviços Compartilhados
DRP Disaster Recovery Plan
ERM Enterprise Risk Management
ERP Enterprise Resource Planning
ETL Extract Transform Load
GC Gerenciamento de Crise
GCN Gestão de Continuidade de Negócios
GRC Governance Risk and Compliance
hpaPaaS high-productivity application Platform as a Service
IP Internet Protocol
iPaaS integration Platform as a Service
IRM Integrated Risk Management
ISMS Information Security Management System

11. ISO International Organization for Standardization
IT Information Technology
ITOM IT Operation Management
ITSM IT Service Management
OA Objetos de Auditoria
OTC Order to Cash
OTIF On Time In Full
PaaS Plataform as a Service
PC Pontos de Controle
PCC Plano de Comunicação de Crises
PCN Plano de Continuidade de Negócios
PCO Plano de Continuidade Operacional
PEO Plano de Emergência
PDCA Plan-Do-Check-Act
PMBOK Project Management Body of Knowledge
PRD Plano de Recuperação de Desastres
PRN Plano de Restabelecimento dos Negócios
SaaS Service as a Service
SGCN Sistema de Gestão de Continuidade de Negócios
SGSI Sistema de Gestão de Segurança da Informação
SI Segurança da Informação
SOAP Simple Object Access Protocol

12. TAAC Técnicas de Auditoria Assistida por Computador
TI Tecnologia de Informação
TIC Tecnologia de Informação e Comunicação
VPN Virtual Private Network

13. Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1 CONCEITOS E TERMINOLOGIAS . . . . . . . . . . . . . . . . . . 18
2.1.1 Controles internos . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.2 Gestão de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.1.3 Auditoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.4 Auditoria interna e externa . . . . . . . . . . . . . . . . . . . . 20
2.1.5 Auditoria de segurança da informação . . . . . . . . . . . . . . 21
2.2 NORMAS RELACIONADAS A GESTÃO DE RISCOS . . . . . . . . . 24
2.2.1 NBR ISO/IEC 19011:2012 - diretrizes para auditorias de sistema
de gestão da qualidade e/ou ambiental . . . . . . . . . . . . . . 24
2.2.2 ISO/IEC 22301:2012 - segurança da sociedade — sistema de ges-
tão de continuidade de negócios — requisitos . . . . . . . . . 24
2.2.3 ISO/IEC 27001:2013 - tecnologia da informação - técnicas de se-
gurança - sistemas de gestão de segurança da informação - re-
quisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.4 ISO/IEC 27002:2013 - tecnologia da informação — técnicas de
segurança — código de prática para controles de segurança da
informação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.5 ISO/IEC 27005:2011 - tecnologia da informação — técnicas de
segurança — gestão de riscos de segurança da informação . . 27
2.2.6 ISO/IEC 27031:2011 - tecnologia da informação - técnicas de se-
gurança - diretrizes para a prontidão para a continuidade dos
negócios da tecnologia da informação e comunicação . . . . . 30
2.2.7 ISO/IEC 27032:2012 - tecnologia da Informação - técnicas de se-
gurança - diretrizes para segurança cibernética . . . . . . . . . 30
2.2.8 ISO/IEC 27033-1:2015 - tecnologia da informação - técnicas de
segurança - segurança de rede - parte 1: visão geral e conceitos 31
2.2.9 NBR ISO/IEC 31000:2009 - gestão de riscos – princípios e diretri-
zes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 GESTÃO DE RISCOS X PLANO DE CONTINUIDADE DE NEGÓCIO 34
2.4 METODOLOGIAS DE GESTÃO DE RISCOS . . . . . . . . . . . . . 37

14. 2.4.1 Diretrizes do guia NIST 800-30 . . . . . . . . . . . . . . . . . . 37
2.4.2 Cenários de risco - usando o COBIT 5 para riscos . . . . . . . 40
2.5 CONCLUSÃO DO CAPÍTULO . . . . . . . . . . . . . . . . . . . . . 43
3 ESTUDO DE CASO . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Preparação da ferramenta . . . . . . . . . . . . . . . . . . . . . 46
3.2 RELAÇÃO ENTRE O SERVICENOW E A NBR ISO/IEC 27005:2011 55
3.3 CONFIGURAÇÃO DO AMBIENTE DO SERVICENOW . . . . . . . . 57
3.3.1 Classes de perfis . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.2 Tipos de perfis . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.3 Identificação dos perfis . . . . . . . . . . . . . . . . . . . . . . 60
3.3.4 Controles existentes . . . . . . . . . . . . . . . . . . . . . . . . 60
3.3.5 Estruturas, declarações de riscos e tipos de perfis . . . . . . . 61
3.3.6 Riscos identificados . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.7 Relacionamento entre controles e riscos . . . . . . . . . . . . 61
3.3.8 Análise de riscos . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.9 Análise dos resultados obtidos . . . . . . . . . . . . . . . . . . 63
4 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . . . . 67
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5 APÊNDICES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

15. 1 INTRODUÇÃO
O número de dispositivos conectados à internet é cada vez maior. Uma
notícia divulgada pelo Gartner (2017), diz que 8,4 bilhões de “coisas” estarão
em uso somente em 2017 e a estimativa até 2021 de acordo com Ericsson
(2015) é de 28 bilhões de dispositivos conectados. Com isso, surgem novas
vulnerabilidades que podem ser exploradas pelos atacantes se não houver novos
mecanismos de segurança da informação acompanhando o crescimento de IoT.
Com esse crescimento de dispositivos interconectados, é inviável para
uma organização resolver todas as vulnerabilidades. Pois, um risco nunca pode
ser considerado nulo, ou seja, não existe um ativo de informação totalmente
seguro (SÊMOLA, 2014). Além disso, pode-se não possuir recursos financeiros
ou humanos suficientes para abordar todos os riscos.
Os avanços em tecnologias e conscientização das pessoas sobre se-
gurança da informação, vem mostrando resultados expressivos. O CERT.br
apresenta estatísticas de diminuição de 1 milhão de incidentes (ataques, tentati-
vas de fraudes, entre outros) reportados em 2014, para aproximadamente 650
mil em 2016. Comprovando os avanços da segurança da informação.
Conforme Sêmola (2014), tecnologias e conscientização sobre segurança
da informação são exemplos que evitam ou diminuem as vulnerabilidades, sendo
assim, diminui-se os riscos. Porém, um risco nunca pode ser considerado nulo,
ou seja, não existe um ativo de informação totalmente seguro.
A medida que novas tecnologias e dispositivos interconectados são lança-
dos no mercado, surgem inúmeras novas vulnerabilidades. Essas vulnerabilida-
des, representam um risco para as organizações. Pois, podem causar grande
impacto operacional, financeiro, reputacional, etc.
Todos os riscos de uma organização não podem ser mitigados. De fato,
pode-se não possuir recursos financeiros ou humanos suficientes para abordar
todos os riscos. Diante deste contexto, questiona-se: como controlar e monito-
rar os riscos de segurança da informação com o crescimento exponencial de
dispositivos interconectados em um cenário industrial?
Acredita-se que, deve existir um processo de gerenciamento de riscos de
segurança da informação para identificar, classificar e priorizar qual risco deve
ser tratado. Quando o risco tem grande impacto sobre a operação de um serviço

16. 16
e grande probabilidade de acontecer, o serviço afetado deve possuir um Plano
de Continuidade de Negócios (PCN).
O PCN define ações para uma organização conseguir manter um nível de
funcionamento aceitável, perante à ocorrência de um evento não previsto ou um
desastre, até a situação atípica ser normalizada (ABRAPP, 2012).
Nessa pesquisa, o objetivo geral é a gestão de riscos em prática usando
a plataforma da ServiceNow. Um estudo de caso. Para atingir o objetivo geral,
formularam-se os seguintes objetivos específicos:
a) conceituar definições e terminologias utilizadas em gestão de riscos;
b) escolher indicadores de gestão de riscos;
c) realizar estudo das normas relacionadas a gestão de riscos;
d) apresentar recursos da ferramenta de gestão de riscos.
Tendo como base os objetivos deste trabalho, o mesmo se caracteriza
por ser uma pesquisa exploratória, seguida de um estudo de caso. Conforme
Gil (2010), uma pesquisa exploratória tem como finalidade proporcionar maior
familiaridade com o problema, tornando-o mais explícito.
Para o aprofundamento desse trabalho, será realizado um estudo de caso
sobre uma ferramenta de gestão de riscos, que tem como finalidade realizar um
estudo amplo e minucioso de um único caso (MARTINS, 2000).
Este trabalho está organizado de forma a apresentar, no capítulo 2 a
fundamentação teórica referente a segurança da informação, assim como os
conceitos, normas e diretrizes de gestão de riscos de segurança da informação.
No capítulo 3 é apresentado o estudo de caso realizado e no capítulo 4, a
conclusão do trabalho.

17. 2 REFERENCIAL TEÓRICO
A informação é utilizada em diversos segmentos, como supermercados,
bancos, indústrias, etc. Todas as organizações decidem suas ações e seus
planos baseando-se em informações. Além de segredos de negócio, análise de
mercado e concorrência, que também são informações essenciais e revelam-se
como diferencial competitivo relacionado ao crescimento e à continuidade do
negócio. Por esses motivos, a informação é considerada como um dos principais
ativos de uma organização (SÊMOLA, 2014).
A informação, os meios de transportes, processamento e os equipamentos
onde a informação é armazenada, são considerados ativos de informação (CAM-
POS, 2014). Pois, o valor de uma informação para a organização, em muito dos
casos, pode ser incalculável. Portanto, as ameaças devem ser mitigadas.
As ameaças são agentes ou circunstâncias que causam incidentes, ex-
plorando vulnerabilidades dos ativos de informação. Além disso, as ameaças
podem ser classificadas de três formas: naturais, involuntárias e voluntárias
(SÊMOLA, 2014).
Os ativos de informação podem possuir vulnerabilidades, que são fraque-
zas que podem ser exploradas de forma intencional ou não. As vulnerabilidades
também podem ser provenientes dos controles de segurança da informação, que
podem não existir ou não ser efetivos (NIST, 2012).
Uma ameaça que explora a vulnerabilidade de um ativo de informação,
resulta em um incidente de segurança da informação. O incidente causa impactos
negativos em uma organização, e para sua mitigação, deve-se implementar
controles de segurança da informação (SÊMOLA, 2014).
Um controle de segurança da informação é considerado qualquer meca-
nismo utilizado para mitigar a vulnerabilidade de um ativo (CAMPOS, 2014).
Além de controles, é necessário que a organização possua um Sistema de
Gestão de Segurança da Informação (SGSI). Que tem como foco estabelecer,
implementar, operar, monitorar, analisar, manter e melhorar a segurança da
informação (ISO/IEC 27001:2013).

18. 18
2.1 CONCEITOS E TERMINOLOGIAS
Para possibilitar o entendimento da atividade de auditoria de segurança
da informação, será abordado nessa seção, os conceitos gerais de controles
internos, gestão de riscos, auditoria interna e externa.
2.1.1 Controles internos
Na atividade de controles internos as entidades podem alcançar propósitos
relevantes, suportar e melhorar o seu desempenho. Conforme COSO (2013),
o objetivo de controles internos é possibilitar um nível de confiança razoável
para eficácia e eficiência dos recursos, fiabilidade da informação financeira e a
conformidade com a legislação e normas.
De acordo com o framework COSO (2007), que é referência mundial em
prevenir e evitar fraudes nos procedimentos e processos internos da organização,
possui quatro categorias de objetivos, permitindo que as entidades tenham foco
em diferentes aspectos do controle interno:
a) estratégico: relacionado com as metas da alta administração. Alinha e
fornece apoio à missão da organização;
b) operacional: refere-se a eficiência e eficácia no uso de recursos da
organização;
c) comunicação: referente a confiabilidade dos relatórios. Incluindo rela-
tórios financeiros e não financeiros, internos e externos;
d) conformidade: associado ao cumprimento da legislação e normas.
Essa classificação, proporciona que aspectos específicos do gerencia-
mento de riscos corporativos, sejam enfatizados. Embora essas categorias
sejam específicas, elas se relacionam. Pois, o mesmo objetivo pode existir em
mais de uma categoria, porém, tratando de necessidades empresariais dife-
rentes. A estrutura apresenta também, o entendimento do que se espera do
gerenciamento de riscos.

19. 19
2.1.2 Gestão de riscos
Segundo Brasil (2016), o conceito de gestão de riscos está relacionado
com o processo de identificar, avaliar e administrar eventos diante de inseguran-
ças. Um dos objetivos dessa atividade é a análise qualitativa dos riscos, que
pode ser realizada por meio de uma matriz, como a Figura 1:
Figura 1 – Exemplo de uma matriz de risco semi-quantitativa
Fonte: Adaptado de ISO/IEC 31010 (2009)
A matriz de risco pode ser utilizada para definir qual risco deve ser mitigado
primeiro. Se a probabilidade de um evento acontecer é alta e o impacto tem
representatividade na organização, o mesmo deve ser mitigado o quanto antes.
Dessa forma, a organização poderá priorizar a atuação nos riscos que
tem um maior impacto e probabilidade de acontecer. Conforme IBGC (2007), os
riscos deverão ser avaliados e monitorados considerando:
a) risco inerente: risco natural (ausente de qualquer controle);
b) risco residual: risco após o efeito do controle aplicado.
Após analisar o risco residual e compará-lo com o risco inerente, é possível
verificar a efetividade do controle aplicado. Depois de ter a pontuação do risco
residual, é necessário validar se a organização aceita esse risco. Caso ainda
não aceite o impacto e probabilidade do evento acontecer, será necessário
implementar mais controles.

20. 20
2.1.3 Auditoria
A atividade de auditoria atual originou-se no final do século XVIII na Ingla-
terra, resultante da revolução industrial. Já em 1929, com a quebra da bolsa de
valores de Nova York, o desenvolvimento das atividades de auditoria foi inten-
sificado. Pois investidores começaram a exigir mais segurança e credibilidade
das demonstrações contábeis para retornar os investimentos em ações. Essas
ações, contribuíram para a prática de auditoria atual (JUNIOR et al., 2011).
Para a realização de uma auditoria, as atividades de gestão de riscos e
controles internos são fundamentais. Sendo que em grandes empresas, essas
atividades podem ser executadas separadamente por áreas distintas.
A auditoria, de acordo com Mello (2005), busca analisar as operações,
sistemas, processos e responsabilidades gerenciais de uma determinada enti-
dade, com o objetivo de verificar a conformidade com legislação vigente, normas,
políticas e padrões. Podendo ser executada por uma equipe interna ou externa.
2.1.4 Auditoria interna e externa
Auditoria interna tem como foco a emissão de opinião conclusiva e reco-
mendações a respeito das operações examinadas, avaliar os fluxos dos sistemas,
plano de controle interno, etc. Em grandes entidades existe uma área voltada
para auditoria interna que realiza auditorias mais frequentes e com maior grau de
profundidade, sendo independente das demais áreas e respondendo diretamente
para o conselho de administração (AUDIBRA, 1991).
A realização da auditoria externa é feita por uma empresa contratada e
independente da contratante e seu objetivo é a emissão de um parecer sobre as
atividades avaliadas (ALMEIDA, 1998). Para que uma empresa seja certificada
em uma International Organization for Standardization (ISO), como a ISO/IEC
27001:2013, é necessário que a auditoria externa, utilize técnicas de auditoria
de segurança da informação para verificar todos os controles de segurança da
informação necessários para a certificação da entidade.

21. 21
2.1.5 Auditoria de segurança da informação
A auditoria de segurança da informação tem o objetivo de avaliar efici-
ência, eficácia e conformidade com legislação vigente, processos, políticas,
procedimentos e outros controles de segurança da informação. Tal atividade
mitiga os riscos que podem causar danos a organização se forem efetivados
(RODRIGUES; FERNANDES, 2011). Além disso, as auditorias de segurança da
informação são classificadas como:
a) auditoria de gestão: examina as políticas de segurança, estrutura da
segurança e plano de segurança;
b) auditoria operacional: confere a eficiência da segurança, usuários,
controles físicos, ambientais e lógicos;
c) auditoria de conformidade: fiscaliza normas, integridade de informa-
ções, disponibilidade e confidencialidade.
Esses três tipos de auditoria possibilitam o planejamento de auditorias
com foco em determinado contexto. Cada tipo de auditoria é importante para a
organização da metodologia de trabalho para auditar a segurança da informação.
Para que a auditoria seja eficiente, deve-se auditar periodicamente.
Conforme Hayes (2003), auditoria de segurança da informação é um
processo continuo de definição e manutenção de políticas de segurança eficazes.
A ISO/IEC 27001:2013, responsável por estabelecer o Information Security
Management System (ISMS) ou em português, SGSI, baseia-se no processo
Plan-Do-Check-Act (PDCA), representado por quatro fases:
a) planejar: estabelecer políticas, objetivos, processos e procedimentos
do SGSI;
b) executar: implementar e operar a política, controles, processos e
procedimentos;
c) verificar: avaliar, e quando possível, mensurar o desempenho do
processo em relação à política, objetivos e experiência prática do
SGSI. Além disso, reporte os resultados para o gerenciamento de
revisão;

22. 22
d) agir: fazer ações corretivas e preventivas, baseando-se nos resulta-
dos da auditoria do SGSI e revisão de gerenciamento, para melhoria
contínua do SGSI.
Para verificar a conformidade de uma organização com a ISO/IEC 27001:2013,
é necessário que seja realizado um processo de auditoria. O processo de audi-
toria de segurança da informação possui vários modelos e metodologias, alguns
são criados por organizações públicas que atuam como órgãos de controle
interno e externo. Para entender o processo de auditoria de segurança da in-
formação, será apresentado na Figura 2, o modelo fornecido pelo Rodrigues e
Fernandes (2011).
Figura 2 – Processo de auditoria de segurança da informação
Fonte: Adaptado de Rodrigues e Fernandes (2011)
Na Figura 2 é proporcionado uma visão geral, sobre as atividades que
compõem o processo de auditoria de segurança da informação. Esse processo
é composto por nove atividades, que serão detalhadas a seguir.
O primeiro passo é a gestão do projeto ou do programa de auditoria, que
estabelece a gestão do projeto ou dos projetos que formam o programa de
auditoria. Como qualquer outro projeto, o projeto de auditoria de segurança
da informação está suscetível a desvios e riscos, que precisam ser monito-
rados e controlados. Recomenda-se para essa situação que seja utilizado o

23. 23
Project Management Body of Knowledge (PMBOK) e a ISO/IEC 19011:2012,
para orientação geral de planejamento e gestão de projetos.
A decisão do propósito da auditoria, é o segundo passo. Que pode ser
a verificação de situações suspeitas, eventos ou ocorrências que necessitam
de mais atenção e analisar riscos de segurança que a organização pode estar
exposta.
A terceira etapa do processo de auditoria é a identificação de objetos e
pontos de controle. Nessa etapa, deve-se analisar o sistema de controle interno
da entidade auditada para identificar onde os elementos do controle interno
podem ser associados aos Objetos de Auditoria (OA) e Pontos de Controle (PC).
O framework Control Objectives for Information and Related Technology (COBIT),
apresenta vários objetivos de controle e pontos de controle.
Na etapa seguinte, após a identificação de objetos e pontos de controle,
é a definição de técnicas para obter evidências e procedimentos de controle.
Nessa etapa são definidas as técnicas utilizadas para obtenção de evidências e
efetuados teste junto aos pontos de controle.
O quinto passo é a montagem da roteirização detalhada da auditoria de
segurança da informação. Na roteirização é detalhado o roteiro dos procedimen-
tos e testes que serão ou que poderão ser efetuados pelo auditor. Nessa etapa,
poderão ser utilizados frameworks, como o ISACA (2016).
A coleta e registro de evidências é o sexto passo do processo de auditoria
de segurança da informação. O objetivo nessa atividade é a coleta de informa-
ções e evidências na entidade auditada e fazer o registro em formulários físicos
ou em meios digitais, mantendo a organização dessas informações.
Após a sexta etapa, deve-se verificar, validar e avaliar as evidências obtidas
de forma rigorosa. Pois algumas evidências que em certo momento não faziam
sentido ou não se relacionavam com outras evidências, nessa etapa devem
começar a ter relevância.
A oitava etapa é a produção de pareceres e outras entregáveis. Esse passo
é destinado para o desenvolvimento do relatório com pareceres, recomendações
e conclusões do auditor. Em cada passo também pode haver entregas, como o
plano de auditoria, relatórios situacionais de auditoria e os pareceres. Esses são
denominados como produtos da auditoria.

24. 24
O último passo, com base em Rodrigues e Fernandes (2011), é o acompa-
nhamento pós-auditoria. Conforme a NBR ISO/IEC 19011:2012, o acompanha-
mento pós-auditoria acontece sempre na existência de um programa de auditoria.
Essa etapa é considerada como uma atividade de gestão, que tem como objetivo
preservar boas práticas e para garantir mudanças (NBR ISO/IEC 19011, 2012).
2.2 NORMAS RELACIONADAS A GESTÃO DE RISCOS
Normas ou padrões são documentos, que estabelecem regras e diretrizes,
geralmente desenvolvidos por um órgão oficial. Como um dos órgãos mais
importantes do mundo no desenvolvimento de padrões internacionais, pode-se
citar o ISO. Nessa seção, será apresentado as normas da ISO que são utilizadas
em auditorias de segurança da informação.
2.2.1 NBR ISO/IEC 19011:2012 - diretrizes para auditorias de sistema de
gestão da qualidade e/ou ambiental
A NBR ISO/IEC 19011:2012 orienta a gestão de programas de auditoria, a
realização de auditorias internas ou externas de sistemas de gestão de qualidade
e/ou ambiental, as organizações que necessitam realizar auditorias de sistema
de gestão da qualidade e/ou ambiental, a certificação de sistemas de gestão, o
credenciamento ou em padronização na área de avaliação da conformidade.
Além da aplicação dessa norma em sistemas de gestão da qualidade e/ou
ambiental, o usuário pode adaptá-la ou aplicá-la a outros tipos de auditorias,
como a auditoria de segurança da informação.
Esse padrão internacional orienta também os princípios de auditoria, ge-
renciamento de programas de auditoria, assim como as atividades de auditoria e
ainda a competência e avaliação de auditores.
2.2.2 ISO/IEC 22301:2012 - segurança da sociedade — sistema de gestão
de continuidade de negócios — requisitos
A ISO/IEC 22301:2012 apresenta os requisitos para configurar e gerenciar
um Sistema de Gestão de Continuidade de Negócios (SGCN) ou em inglês

25. 25
Business Continuity Management System (BCMS), efetivo (BS ISO/IEC 22301,
2012).
Um SGCN destaca a importância de compreender as necessidades da
organização e a necessidade de desenvolver políticas e objetivos de Gestão de
Continuidade de Negócios (GCN), mensurar, implementar e operar controles
para gerenciar a capacidade geral de uma organização em gerenciar inciden-
tes disruptivos, com base no PDCA que monitora e revisa o desempenho e
efetividade do SGCN e melhoria continua com base na medição objetiva.
Esse padrão internacional pode ser utilizado pela auditoria para avaliar
a capacidade de uma organização em atender suas próprias necessidades
de continuidade e obrigações, através da verificação de documentos como:
procedimento para identificação de requisitos legais e regulatórios aplicáveis, lista
de requisitos legais, regulatórios e outros, política de continuidade de negócio,
etc (27001 Academy, 2014).
2.2.3 ISO/IEC 27001:2013 - tecnologia da informação - técnicas de segu-
rança - sistemas de gestão de segurança da informação - requisitos
A ISO/IEC 27001:2013 fornece um modelo para estabelecer, implementar,
operar, monitorar, manter e melhorar um SGSI ou em inglês ISMS. O SGSI
de uma organização é motivado por suas necessidades e objetivos, requisi-
tos de segurança, processos empregados e ainda o tamanho e estrutura da
organização.
Este padrão adota uma abordagem de processo para estabelecer, imple-
mentar, operar, monitorar, revisar e manter o SGSI de uma entidade. Qualquer
atividade que use recursos e que sejam gerenciados para possibilitar a transfor-
mação de entradas em saídas, pode ser um processo. É possível considerar
como "abordagem de processo"a aplicação de um sistema de processos dentro
de uma organização, junto com a identificação e as interações desses processos
e ainda sua gestão.
Essa padrão internacional incentiva seus usuários, através da abordagem
de processo para gerenciamento de segurança da informação, a destacar a
importância de:

26. 26
a) entender os requisitos de Segurança da Informação (SI) de uma orga-
nização e a importância de estabelecer políticas e objetivos de SI;
b) implementar e operar controles para gerenciar os riscos de SI de uma
organização no âmbito dos riscos globais do negócio;
c) monitorar e rever o desempenho e a eficácia do SGSI;
d) utilizar melhoria contínua com base na medição objetiva.
A utilização de metodologias como o PDCA, nesse padrão internacional,
aplica-se para a estruturação de todos os processos de SGSI. Além disso, a
ISO/IEC 27001:2013 pode ser utilizada pela auditoria interna e externa para
avaliar a conformidade das políticas e objetivos de SI (ISO/IEC 27001, 2013).
2.2.4 ISO/IEC 27002:2013 - tecnologia da informação — técnicas de segu-
rança — código de prática para controles de segurança da informa-
ção
A ISO/IEC 27002:2013 estabelece diretrizes e princípios gerais para iniciar,
implementar, manter e melhorar o SGSI em uma organização. Esse padrão
internacional pode servir como orientação prática para a elaboração de padrões
de segurança organizacional, práticas efetivas de gerenciamento de segurança
e para auxiliar a criar confiança nas atividades entre organizações.
Nas auditorias de segurança de informação, o auditor pode verificar se
a entidade está em conformidade com este padrão internacional que aborda
a avaliação e tratamento dos riscos, políticas de segurança, organização da
informação interna e externa, gestão de ativos, segurança dos recursos humanos,
segurança física e ambiental, gerenciamento de comunicações e operações,
controle de acesso, gestão de incidentes de segurança da informação, gestão
de continuidade de negócios, conformidade e aquisição, desenvolvimento e
manutenção de sistemas de informação (ISO/IEC 27002, 2013).

27. 27
2.2.5 ISO/IEC 27005:2011 - tecnologia da informação — técnicas de segu-
rança — gestão de riscos de segurança da informação
A ISO/IEC 27005:2011 fornece diretrizes para o gerenciamento de riscos
de segurança da informação em uma organização, apoiando os requisitos de um
SGSI de acordo com a ISO/IEC 27001:2013.
Contudo, este padrão internacional não fornece nenhuma metodologia
para gerenciamento de riscos de segurança da informação. A gestão de riscos
de segurança da informação deve contribuir para:
a) identificação de riscos;
b) processo de avaliação de riscos em função das consequências ao
negócio e da probabilidade de sua ocorrência;
c) comunicação e entendimento da probabilidade e das consequências
dos riscos;
d) priorização de tratamento de risco;
e) priorização de ações para mitigar os riscos;
f) comprometimento das partes interessadas quando as decisões de
gestão de riscos são tomadas e mantidas informadas sobre a situação
da gestão de riscos;
g) eficácia do monitoramento do tratamento do risco;
h) monitoramento e análise crítica periódica dos riscos e do processo de
gestão de riscos;
i) coleta de informações de forma a melhorar a abordagem da gestão de
riscos;
j) treinamento de gestores e pessoal a respeito dos riscos e das ações
para mitiga-los.
Sendo assim, a organização fica responsável por definir sua abordagem
para o gerenciamento de riscos, dependendo, por exemplo, do escopo do SGSI,
contexto de gerenciamento de risco, etc.
Esse padrão internacional também complementa os conceitos gerais espe-
cificados na ISO/IEC 27001:2013 que é projetada para auxiliar a implementação

28. 28
satisfatória de segurança da informação com base em uma abordagem de ge-
renciamento de risco (ISO/IEC 27005, 2011). Além disso, a ISO/IEC 27001:2013
fornece um processo para gestão de riscos de segurança da informação, que é
apresentado na Figura 3.
Figura 3 – Processo de gestão de riscos de segurança da informação
Fonte: NBR ISO/IEC 27005:2011
O processo de gestão de riscos de segurança da informação ilustrado
pela Figura 3, é formado por 8 atividades. Definição do contexto e seguindo

29. 29
para o processo de avaliação de riscos, que é composto pelas atividades de
identificação, análise e avaliação de riscos. Se a avaliação for satisfatória,
seguirá para o tratamento do risco. Posteriormente, se o tratamento também foi
satisfatório, o processo continuará para aceitação do risco.
Em todas as etapas desse processo, pode-se fazer a comunicação e
consulta do risco. Apenas a atividade de monitoramento e análise crítica de
riscos será feita na execução do tratamento do risco e aceitação do risco.
A ISO/IEC 27005:2011 estabelece que esse processo de gestão de riscos
deve ser contínuo. Com a metodologia PDCA, é possível ter uma visão cíclica da
gestão de risco de segurança da informação. Na Figura 4 apresenta o processo
na metodologia PDCA.
Figura 4 – Processo de gestão de riscos de segurança da informação
Fonte: Adaptado de ISO/IEC 27005:2011
A metodologia PDCA ilustrada na Figura 4 e aplicada para o processo
de gestão de risco de segurança da informação, divide o processo em quatro
etapas principais. Na primeira etapa, o “planejamento” possui as atividades de
estabelecer o contexto, avaliar, desenvolver o plano de tratamento e aceitar os

30. 30
riscos. Relacionado ao “fazer”, está a atividade de implementação do plano
de tratamento de riscos, seguido pela terceira etapa de monitorar e revisar
continuamente os riscos. Na quarta e última etapa, está a atividade de manter e
melhorar o processo de gerenciamento de riscos de segurança.
2.2.6 ISO/IEC 27031:2011 - tecnologia da informação - técnicas de segu-
rança - diretrizes para a prontidão para a continuidade dos negó-
cios da tecnologia da informação e comunicação
A ISO/IEC 27031:2011 apresenta conceitos e princípios da prontidão
esperada da Tecnologia de Informação e Comunicação (TIC) para a continuidade
de negócios.
Esse padrão internacional também fornece um framework de métodos e
processos para identificar e especificar todas os aspectos (como critérios de
desempenho, desenho e implementação) para melhorar a disponibilidade de TIC
da organização e garantir a continuidade dos negócios.
Além disso, essa norma aborda todos os eventos e incidentes, incluindo
os incidentes e eventos de segurança da informação, que possam ter algum
impacto na infraestrutura e sistemas de TIC.
2.2.7 ISO/IEC 27032:2012 - tecnologia da Informação - técnicas de segu-
rança - diretrizes para segurança cibernética
A ISO/IEC 27032:2012 aborda questões de segurança cibernética que se
concentram em resolver problemas entre os diferentes domínios de segurança
no ciberespaço, fornecendo orientação técnica para abordar os riscos comuns de
cibersegurança, como ataques de engenharia social, propagação de programa
malicioso, spyware e outros programas indesejados (ISO/IEC 27032, 2012).
A orientação técnica desse padrão internacional, também oferece controles
para enfrentar esses riscos, incluindo controles para se preparar aos ataques,
como malware, criminosos individuais ou organizações criminosas na internet,
detectar e monitorar ataques e ainda responder a ataques.
Outro foco desse padrão internacional é o compartilhamento eficiente
e eficaz de informações, coordenação e tratamento de incidentes entre as
partes interessadas no ciberespaço. Entende-se como partes interessadas os

31. 31
consumidores, que podem ser vários tipos de organizações ou indivíduos e ainda
provedores, que incluem provedores de serviços.
Nesse padrão, é apresentado um framework para compartilhamento de
informações, coordenação e manipulação de incidentes. O framework inclui
elementos-chaves de considerações para estabelecer confiança, processos
necessários para colaboração e interoperabilidade entre diferentes partes inte-
ressadas e requisitos técnicos para integração de sistemas e interoperabilidade
entre as partes interessadas.
2.2.8 ISO/IEC 27033-1:2015 - tecnologia da informação - técnicas de se-
gurança - segurança de rede - parte 1: visão geral e conceitos
A ISO/IEC 27033-1:2015 é composta por 6 partes, tendo como título geral
Tecnologia da Informação – Técnicas de Segurança – Segurança de rede para
todo o conjunto abaixo:
a) visão geral e conceitos;
b) diretrizes para a concepção e implementação de segurança de rede;
c) referência de cenários de rede – ameaças, técnicas de design e pro-
blemas de controle;
d) proteção de comunicações entre redes usando gateways de segu-
rança;
e) proteção de comunicações em redes usando redes privadas virtuais
Virtual Private Network (VPN);
f) proteção do acesso à rede Internet Protocol (IP) sem fio.
A primeira parte desse padrão internacional apresenta uma visão geral
sobre segurança da rede e definições relacionadas. Essa parte define e descreve
os conceitos e apresenta orientações de gerenciamento de segurança da rede
para dispositivos, aplicativos, serviços e usuários finais, além disso, também é
fornecido orientação para informações que estão trafegando através dos links de
comunicação.
Essa primeira parte da ISO/IEC 27033-1:2015 é relevante para adminis-
tradores seniores, gerentes, usuários não técnicos, profissionais responsáveis

32. 32
pela segurança da informação/rede, operação de rede, responsável pelo pro-
grama geral de segurança e desenvolvimento de políticas de segurança de uma
organização. Esse padrão internacional também inclui para seus usuários:
a) orientação de como identificar e examinar os riscos de segurança
de rede bem como a definição de requisitos da segurança de rede,
baseando-se nesta análise;
b) uma visão macro dos controles que sustentam arquiteturas de se-
gurança técnica de rede e outros controles associados, assim como
controles não-técnicos e controles técnicos que são aplicáveis não
apenas às redes;
c) como obter arquiteturas de segurança técnica de rede de boa quali-
dade, e os aspectos de risco, design e controle relacionados aos tipos
cenários de rede e áreas de tecnologia de rede, que são detalhadas
nas próximas partes desse padrão internacional.
A ISO/IEC 27033-1:2015 apresenta uma breve abordagem sobre os pro-
blemas relacionados à implementação e operação dos controles de segurança
da rede e ao acompanhamento e revisão contínuos da sua implementação. O
padrão internacional fornece uma visão geral e um roteiro, para as demais partes
(ISO/IEC 27033-1, 2015).
2.2.9 NBR ISO/IEC 31000:2009 - gestão de riscos – princípios e diretrizes
A NBR ISO/IEC 31000:2009 estabelece princípios que precisam ser se-
guidos para tornar a gestão de risco eficaz. Essa norma recomenda que as
organizações desenvolvam, implementem e melhorem continuamente um fra-
mework (nesse caso, é possível utilizar o ciclo PDCA), tendo como função
principal: integrar o processo para gerenciar riscos na governança, estratégia
e planejamento, gestão, processos de reportar dados e resultados, políticas,
valores e cultura em toda a organização (NBR ISO/IEC 31000, 2009).
Com a utilização de uma abordagem genérica, esse padrão internacional
proporciona princípios e diretrizes para gerenciar qualquer forma de risco de
uma maneira sistemática, transparente e confiável, dentro de qualquer escopo e
contexto.

33. 33
Na Figura 5 é apresentado o processo de gestão de riscos, constituído por
sete atividades denominadas: comunicação e consulta, estabelecimento do con-
texto, identificação de riscos, análise de riscos, avaliação de riscos, tratamento
de riscos e monitoramento e análise crítica.
Figura 5 – Processo de gestão de riscos
Fonte: Adaptado de NBR ISO/IEC 31000:2009
A ISO/IEC 31000:2009 possui o processo de gestão de riscos, apresentado
na Figura 5, muito semelhante a Figura 3. Analisando os dois processos, apenas
três atividades estão ausentes no processo da ISO/IEC 31000:2009. Que são:
aceitação do risco, ponto de decisão 1 e 2.
Esse padrão internacional também fornece direcionamentos para cada
uma das sete atividades apresentadas na Figura 5. Iniciando pela comunicação
e consulta, estabelecimento do contexto, identificação, análise, avaliação e
tratamento de riscos, monitoramento e análise crítica. Essas atividades tem
como objetivo:
a) comunicação e consulta: comunicar e consultar durante todas as fases
do processo de gestão de riscos, as partes interessadas internas e
externas;

34. 34
b) estabelecimento do contexto: estabelecer os objetivos, definir o escopo
e os critérios de riscos para o processo;
c) identificação dos riscos: identificar as fontes de riscos, áreas de impac-
tos, eventos e suas causas e consequências;
d) análise de riscos: fornecer uma entrada para a tomada de decisões e
as opções abrangem diversos tipos e níveis de risco;
e) avaliação de risco: auxiliar na tomada de decisões baseando-se nos
resultados da análise de riscos;
f) tratamento de riscos: selecionar uma ou mais opções para alterar os
riscos e a implementação dessas opções;
g) monitoramento e análise crítica: o monitoramento e a análise crítica
devem ser planejados como parte do processo de gestão de riscos e
com observação regular.
Na execução de auditorias, essa norma proporciona aos auditores a
certificar-se que os riscos são eficazmente gerenciados na organização como
um todo ou em uma área, atividade ou projetos específicos e ainda para avaliar a
eficácia de uma organização em gerenciar riscos (NBR ISO/IEC 31000, 2009).
2.3 GESTÃO DE RISCOS X PLANO DE CONTINUIDADE DE NEGÓCIO
O PCN define ações para uma organização conseguir manter um nível de
funcionamento aceitável, perante à ocorrência de um evento não previsto ou um
desastre, até a situação atípica ser normalizada (ABRAPP, 2012).
Conforme Cerullo, V e Cerullo, J (2004), todas as organizações precisam
elaborar um PCN abrangente baseado em suas particularidades. O PCN também
deve ser dinâmico, sendo aprimorado paralelamente com as mudanças nos
ambientes de negócios e suas dependências de tecnologias da informação.
O projeto para o desenvolvimento do PCN, envolve a identificação de
possíveis ameaças e seus impactos às organizações, indicando um framework
para criação de procedimentos que aumentam a resiliência, preservando os
interesses da organização, como a sua reputação, marca e atividades de criação
de valor (LUDESCHER, 2012 apud SMITH, 2008). O PCN deve incluir também,

35. 35
controles para identificar e mitigar os riscos e limitar os impactos dos incidentes,
desastres, etc.
Desastre pode ser definido genericamente como um evento que causa
sofrimento e grandes prejuízos, sejam físicos, morais, materiais ou emocionais
(HOUAISS, 2017). Desse modo, a palavra “desastre” não está relacionada
diretamente a um evento catastrófico como um furacão, apesar de que possa ter
essa origem. Pode ser considerado como um desastre, a falha de um disco rígido
do servidor de Enterprise Resource Planning (ERP) que ocasiona a perda de
dados fundamentais para o funcionamento de uma organização, principalmente
se não existir backup dessas informações. (CERULLO; CERULLO, 2004)
Na continuidade do negócio é necessário mitigar os riscos, entretanto é
impossível prever todas as vulnerabilidades de um sistema, especialmente se
o mesmo for de grande porte. Além disto, existe situações que não podem ser
previstas, justificando a criação do Plano de Recuperação de Desastres (PRD),
ou em inglês Disaster Recovery Plan (DRP). Este representa um conjunto de
ações fundamentais para executar a recuperação de uma entidade que vivenciou
um evento de desastre.
Em ambientes computacionais, desastre pode ser definido como a inter-
rupção não planejada de processos de negócio de uma empresa, resultando na
paralisação da operação de um sistema crítico, como o ERP, devido à falha de
elementos da infraestrutura de TI (LUDESCHER, 2012 apud TOIGO, 2003).
De acordo com Pereira et al. (2011), o PRD precisa determinar o que será
mantido pelo plano, a análise que cobrirá os efeitos das perdas de dados e a
interrupção da comunicação com os colaboradores, fornecedores e clientes.
É fundamental também identificar os eventos que apresentam possíveis
desastres, quais pessoas na organização possuem permissão para anunciar um
desastre e colocar o PRD em execução no menor tempo possível. Desse modo,
as ações descritas no PRD deverão ser precisas e claras, objetivando facilitar
sua execução.
Segundo Swanson et al. (2010), um PCN pode ser constituído por uma
coleção de documentos que remetem a uma certa área ou necessidade da
organização. No Quadro 1 é apresentado os tipos de planos relacionadas à
continuidade negócios.

36. 36
Quadro 1 – Tipos de planos relacionados à continuidade de negócios
Fonte: Swanson et al. (2010)
Deve ser destacado que, como os PCNs podem ser constituídos por vários
tipos de planos, como mostrado na Quadro 1, podendo conter um conjunto
de procedimentos de recuperação ou PRDs, cada um relacionado a um dos
sistemas computacionais da entidade, onde cada sistema pode ter um processo
de recuperação diferenciado e exclusivo.
A GCN ou em inglês Business Continuity Management (BCM), prepara
as organizações para futuros eventos que podem interferir na realização dos
objetivos do negócio. O Gerenciamento de Crise (GC) ou Crisis Management
(CM) é um elemento chave do GCN e trata de comunicar informações sobre a
crise para os stakeholders da organização (PWC, 2017).
Uma pesquisa realizada pela CMI (2009), mostrou que 91% dos entrevis-
tados em organizações que executaram o GCN nos últimos 12 meses, concorda-
ram ou concordam fortemente que o plano foi efetivo na redução da interrupção
gerada por um evento. Essa pesquisa reforça a importância do GCN, mostrando

37. 37
que é necessário ter meios para garantir e validar sua eficácia. Pois se apenas
existir um papel com procedimentos obsoletos, o plano não terá eficiência em
meio ao desastre.
De acordo com (IIA, 2014), a auditoria interna pode contribuir de forma
significativa para o desenvolvimento, implementação e avaliação do GCN e GC
da organização. A auditoria interna está em uma posição independente das
outras áreas na estrutura organizacional da empresa e possui conhecimento
detalhado das operações. Ainda assim, pode-se contribuir com diversos papéis
fundamentais e de suporte, dependendo da existência e/ou maturidade das
iniciativas de GCN e GC.
Os papéis da auditoria interna podem ainda abranger garantia e asses-
soria de serviços antes, durante e depois de uma crise. Garantia e assessoria
requerem entendimento profundo de elementos chaves do GCN, contendo a
governança do programa, análise de impacto empresarial e Business Continuity
and Recovery Planning (BCRP).
Os compromissos que a auditoria interna tem com garantia e validação de
atividades, podem ser utilizados ainda para verificar se o GCN e GC são eficazes.
Já os serviços de assessoria, podem ser realizados para ajudar a gerenciar o
foco do planejamento das atividades e a coordenar o GCN e GC com riscos e
controles (IIA, 2014).
2.4 METODOLOGIAS DE GESTÃO DE RISCOS
Para realizar análise e gerenciamento de riscos, o responsável por essas
atividades pode utilizar algumas metodologias. Nessa seção será apresentado
as diretrizes do guia NIST 800-30 e Cenários de risco – usando o COBIT 5 para
riscos.
2.4.1 Diretrizes do guia NIST 800-30
O objetivo do NIST 800-30 revisão 1, é prover orientação para realizar
avaliações de risco em sistemas de informações e organizações. Em resumo, o
NIST 800-30 apresenta as diretrizes para a realização de cada uma das etapas
do processo de avaliação de risco (preparar a avaliação, conduzir a avaliação,

38. 38
comunicar os resultados da avaliação e manutenção da avaliação), representado
na Figura 6.
Figura 6 – Etapas do processo de gestão de riscos
Fonte: Adaptado de NIST (2012)
O processo de gestão de risco possui quatro etapas, conforme Figura 6.
Nesse diagrama, as etapas são divididas em moldar, avaliar, responder e moni-
torar. A primeira etapa do processo de gerenciamento de riscos, representado
pelo “montar”, aborda como as organizações estruturam riscos ou estabelecem
o contexto de risco. O objetivo dessa etapa é produzir uma estratégia de gestão
de risco que aborde como as organizações pretendem avaliar, responder, e
monitorar o risco.
A segunda etapa descrita como “avaliar”, tem como objetivo identificar
ameaças a organização, vulnerabilidades internas e externas, dano que as
ameaças podem causar ao explorarem vulnerabilidades e a probabilidade da
ocorrência dos danos.
Na terceira etapa, o objetivo é fornecer uma resposta coerente, para toda
organização, ao risco. Nessa fase, o NIST 800-30 fornece quatro diretrizes:

39. 39
a) desenvolver cursos alternativos de ação para responder ao risco;
b) avaliar os cursos alternativos de ação;
c) determinar cursos de ação apropriados e consistente;
d) implementar respostas de risco baseando-se em cursos selecionados.
A quarta e última etapa, aborda o monitoramento do risco. Nessa etapa,
deve-se determinar a eficácia contínua de respostas a riscos, identificar mudan-
ças que impactam o risco ao sistemas e aos ambientes em que os sistemas
operam, além de verificar se a respostas ao risco planejadas estão implemen-
tadas e os requisitos de segurança da informação foram atendidos e está em
conformidade com a missão da organização, legislação federal, regulamentações,
políticas, padrões e guias.
Além do processo de gestão de risco, o NIST 800-30 fornece orientações
para realização de avaliações de riscos nas organizações. Na Figura 7 apresenta
as quatro etapas que compõe o processo de avaliação de risco.
Figura 7 – Processo de avaliação de risco
Fonte: Adaptado de NIST (2012)

40. 40
O processo de gestão de risco, ilustrado na Figura 7, é constituído pelas
etapas de preparar a avaliação, conduzir a avaliação, comunicar os resultados e
manter a avaliação. Já a etapa de conduzir a avaliação, é composta pelas sub-
etapas de identificar origens de ameaças e eventos, identificar vulnerabilidades e
condições predisponentes, determinar a probabilidade de ocorrência, determinar
a intensidade do impacto e determinar o risco.
2.4.2 Cenários de risco - usando o COBIT 5 para riscos
Um dos componentes mais importantes para o Enterprise Risk Mana-
gement (ERM), é a análise de cenários de risco. Na Figura 8 apresenta uma
técnica para ajudar a descrever riscos em termos mais fáceis para os líderes de
negócios compreenderem (ISACA, 2014).
Figura 8 – Visão geral do cenário de risco
Fonte: Adaptado de ISACA (2014)

41. 41
O item destacado em vermelho (cenários de riscos) na Figura 8, possui um
processo sugerido pelo ISACA (2014) e será abordado nessa seção. Um cenário
de risco é uma descrição de um possível evento, que poderá acontecer. Esse
possível evento, tem um impacto incerto sobre a realização dos objetivos da
organização. Além disso, a Figura 8 apresenta que os cenários de risco podem
ser decorrentes de dois mecanismos diferentes:
a) abordagem de cima para baixo: parte dos objetivos gerais da empresa
e realiza uma análise dos cenários de risco de TI mais relevantes e
prováveis que afetam os objetivos da organização;
b) abordagem de baixo para cima: lista de cenários genéricos é utilizada
para definir um conjunto de cenários relevantes e personalizados,
aplicados à situação da organização.
O processo de gerenciamento de riscos, como NBR ISO/IEC 27005:2011
ou NBR ISO/IEC 31000:2009, determinam que os riscos passem pelas atividades
de identificação, análise e execução.
Quando os cenários de risco são bem elaborados, auxiliam essas ativida-
des e as tornam relevantes para a empresa. Os cenários de risco que são bem
elaborados, devem possuir cinco características:
a) relevância para decisão: os cenários de risco devem expor informações
relevantes para apoiar as decisões;
b) consistência: cada cenário deve ser interessante por si só;
c) plausibilidade: os cenários devem ser plausíveis e realistas;
d) probabilidade: devem ser prováveis de ocorrer;
e) oportuno: cada cenário deve ser elaborado utilizando dados atualiza-
dos para refletir o ambiente corporativo.
Além dos cenários de riscos terem como características: relevância, con-
sistência, plausibilidade, probabilidade e oportunos para serem considerados
bem elaborados, os cenários devem seguir um processo.
Na Figura 9 é apresentado uma abordagem sugerida pelo ISACA (2014),
de fluxo trabalho para desenvolvimento de cenários de risco. Esse processo é
constituído de 8 atividades principais.

42. 42
Figura 9 – Fluxo de trabalho para desenvolver cenários de risco – abordagem sugerida
Fonte: Adaptado de ISACA (2014)
A visão geral ilustrada na Figura 9, possibilita o entendimento das principais
atividades encontradas no processo de desenvolvimento de cenários de risco.
Iniciando pela utilização de exemplos para facilitar a construção dos cenários,
até a atividade de gerenciamento de cenários.
Após a definição do conjunto de cenários de risco, o conjunto pode ser
utilizado para análise de risco, onde a frequência e o impacto dos cenários serão
avaliados. Componentes relevantes dessa avaliação, são os fatores de risco.
As condições que influenciam a frequência e/ou o impacto nos negócios
dos cenários de risco, são denominadas de fatores de risco. Esses fatores
podem ser classificados em duas categorias principais, fatores contextuais e

43. 43
capacidades. Essas duas categorias ainda podem ser subdivididas em outras
quatros:
a) fatores contextuais internos: na maioria, estão sob o controle da orga-
nização. Porém, nem sempre é fácil mudá-los;
b) fatores contextuais externos: grande parte, estão fora do controle da
empresa;
c) capacidades de gerenciamento de riscos de TI: indica a maturidade
da organização para execução dos processos de gerenciamento de
riscos;
d) capacidades relacionadas à TI: indica a capacidade dos facilitadores
do COBIT 5 relacionados à TI. Esses facilitadores, possuem relevância
para influenciar a frequência e o impacto dos cenários de TI e devem
ser levados em consideração durante todas as análises de risco.
Os fatores de risco podem ser expostos como fatores causais do cenário
que está se realizando ou como vulnerabilidades ou fraquezas. A análise de
cenários não deve basear-se apenas em experiências passadas e eventos atuais
conhecidos, mas deve preocupar-se com possíveis eventos futuros.
As tecnologias emergentes, as novas regulamentações, as mudanças
demográficas e as novas iniciativas de negócios podem ser um risco no futuro.
Os fatores de riscos se alteram ao decorrer do tempo, consequentemente, os
cenários de risco também são alterados.
Como os cenários de risco são impactados pelas mudanças dos riscos,
exige-se que a organização realize avaliações e monitoramento de riscos conti-
nuamente. A avaliação de riscos baseada nos cenários deve ser realizada pelo
menos uma vez por ano e quando ocorrer uma alteração significativa nos fatores
de risco internos ou externos.
2.5 CONCLUSÃO DO CAPÍTULO
As organizações estão sofrendo com as vulnerabilidades que acompa-
nham o crescimento exponencial da utilização de dispositivos interconectados.
Por esse motivo, as normas e guias referente a segurança da informação e

44. 44
gestão de riscos auxiliam as organizações na identificação e na avaliação dos
riscos.
No capítulo a seguir, será apresentado um estudo de caso utilizando uma
ferramenta para gerenciar e avaliar os riscos de uma organização de grande
porte do norte catarinense. Também será apresentado o relacionamento da
ferramenta com a NBR ISO/IEC 27005:2011.

45. 3 ESTUDO DE CASO
Com o conhecimento obtido a partir do referencial teórico, foi feito um
estudo de caso utilizando uma ferramenta de Integrated Risk Management (IRM)
em uma empresa multinacional. Normas e guias internacionais foram utilizados
para auxiliar no entendimento do processo de gerenciamento de riscos, utilizado
pela ferramenta de IRM e entender sua conformidade com a NBR ISO/IEC
27005:2011.
3.1 METODOLOGIA
O ServiceNow é uma Plataform as a Service (PaaS) que possui várias
aplicações, como: IT Service Management (ITSM), IT Operation Management
(ITOM), segurança das operações, Governance Risk and Compliance (GRC),
etc. A solução de IRM, inclusa na aplicação de GRC, tem como alvo equipes de
segurança de TI, diretores de gerenciamento de riscos e equipes de auditoria
interna (GARTNER, 2018c).
O relatório do Gartner (2018c) classificou o ServiceNow, como líder do
quadrante mágico para a solução de IRM. E foi classificado também pelo
Gartner (2018a), como líder em high-productivity application Platform as a Ser-
vice (hpaPaaS).
Conforme o relatório Gartner (2018c), existem outras ferramentas além do
ServiceNow para gerenciamento de riscos. Mas, para esse trabalho foi escolhido
o ServiceNow. Pois, essa ferramenta já está sendo utilizada pela organização, na
qual o estudo de caso foi aplicado, para outras finalidades, como: gerenciamento
de serviços de TI e de negócios.
O estudo de caso foi aplicado em uma organização, que tem sua sede
localizada no norte catarinense. Essa empresa, com mais de 70 anos de história,
está presente em vários países da américa latina, Estados Unidos e China.
Esse estudo foi feito com base em um cenário disponibilizado pela equipe
de arquitetura de sistemas da empresa citada anteriormente. O cenário aborda al-
guns ativos de TI e serviços de negócios utilizados integralmente ou parcialmente
pela equipe do Centro de Serviços Compartilhados (CSC) e seus solicitantes.
Os detalhes do cenário serão apresentados na seção 3.3.

46. 46
A coleta de informações necessárias para executar a avaliação de risco,
foi realizada entre os dias 22 e 26 de outubro de 2018 na sede da empresa, com
a equipe de arquitetura de sistemas. Sendo que essa equipe, foi entrevistada
tendo como base questionários padrões fornecidos pelo ServiceNow, além de
perguntas acrescentadas pelo autor desse trabalho.
3.1.1 Preparação da ferramenta
Nesse trabalho, o processo de gerenciamento de riscos utilizando o Ser-
viceNow, foi dividido em dois subprocessos. O primeiro subprocesso é o de
estabelecer escopo de perfil para os riscos e o segundo subprocesso, é o de
gerenciamento de riscos, declarações e estruturas de riscos. Na Figura 10
é apresentado o macroprocesso de gerenciamento de riscos. Para facilitar a
identificação dos processos e suas respectivas atividades, foram criados identifi-
cadores, como P1 e P2.
Figura 10 – Macro processo de gerenciamento de riscos do ServiceNow
Fonte: o autor (2018)
O processo de gerenciamento de riscos é contínuo, por esse motivo a
Figura 10 não possui um evento de término. Na Figura 11 é apresentado com
mais detalhes as atividades que envolvem o primeiro subprocesso.

47. 47
Figura 11 – Subprocesso para estabelecimento do escopo de perfil para os riscos
Fonte: o autor (2018)
O primeiro subprocesso, apresentado acima, é composto por quatro ativi-
dades principais: definir classes de perfil, estabelecer os tipos de perfil, identificar
os perfis e relacionais os perfis. Essas atividades apresentadas na Figura 11,
são detalhadas a seguir.
Em programação orientada a objetos, uma classe é um gabarito para
definição de objetos (RICARTE, 2000). Na aplicação de GRC do ServiceNow,
esse conceito é utilizado também. Classes de perfis, funcionam como um
gabarito para a definição de perfis, ou seja, define o que realmente é um perfil.
As classes de perfis, também permitem que os gerentes de GRC sepa-
rem os perfis para melhor distinção, podendo filtrar os relatórios para definir
relacionamentos entre as diferentes classes de perfil.
Os tipos de perfis são categorias que contêm um ou mais perfis. A lógica de
negócios do ServiceNow, automatiza o processo de criação e categorização dos
perfis que atendam às condições do tipo de perfil. Por exemplo, uma organização
pode utilizar a tabela “cmdb_ci_computer” do ServiceNow para gerenciar seus
computadores. Para automatizar a criação dos perfis, pode ser criado um “filtro
de perfil” na lista relacionada de tipo de perfil.
Os perfis são os registros que agregam informações de GRC relacionadas
a um item específico. Cada perfil, é associado a um único registro de qualquer

48. 48
tabela da instância do ServiceNow. O relacionamento entre os tipos de perfis e
os perfis, são apresentados na Figura 12.
Figura 12 – Escopo de perfis no Gerenciamento de Riscos
Fonte: Adaptado de ServiceNow (2018)
Na Figura 12, é apresentado um exemplo de classe de perfil, três exemplos
de tipos de perfis e três exemplos de perfis. A classe de perfil escritórios, contêm
os tipos de perfis escritórios globais, escritórios norte - americanos e escritórios
da união europeia.
O tipo de perfil escritórios globais, contêm todos os perfis ilustrados na Fi-
gura 12. O tipo de perfil escritórios norte-americanos, possui os perfis escritórios
de Los Angeles e escritórios de Nova York. E o tipo de perfil escritórios da união
europeia, possui apenas o perfil escritórios de Berlim. Após criar os perfis, os
mesmos devem ser relacionados para gerar o mapa de dependência.

49. 49
O segundo subprocesso é o de gerenciar riscos, declarações e estruturas
de riscos. Este, por sua vez, é composto por nove atividades e um subprocesso.
Na Figura 13 é apresentado uma visão geral desse subprocesso.
Figura 13 – Gerenciar riscos, declarações de risco e estruturas de risco
Fonte: o autor (2018)
O subprocesso apresentado na Figura 13, possui atividades que são feitas
por meio de entrevistas, como as atividades P2.1 e P2.2. Mas também possui
atividades que devem ser executadas na ferramenta, como P2.3 à P2.9. Como
nesse estudo de caso será feito apenas uma avaliação de risco, a atividade P2.4
não será abordada. Pois essa atividade deve ser utilizada por organizações que
tenham um ciclo recorrente de avaliação de riscos.
A aplicação de GRC do ServiceNow também fornece uma biblioteca de
riscos. Essa biblioteca está dividida em dois módulos: estruturas de risco e
declarações de risco.

50. 50
A estrutura de risco tem como funcionalidade, agrupar as declarações de
risco. Declarações de risco por sua vez, tem como objetivo principal agrupar os
riscos. Na Figura 14 é apresentado como os documentos de riscos se relacionam
com os perfis.
Figura 14 – Escopo de perfis no gerenciamento de riscos
Fonte: Adaptado de ServiceNow (2018)
As declarações de risco são nomeadas com ameaças, como por exemplo
perda de integridade. Na declaração de risco também é definido a categoria, a
avaliação de risco, os modelos de indicador e a pontuação padrão dos riscos.
Ao associar a estrutura de riscos a um tipo de perfil, para cada perfil um
risco é criado automaticamente por declaração de risco. Essa prática facilita a
administração e criação de novos riscos.

51. 51
Na Figura 15 é apresentado um exemplo de escopo de perfil no gerenci-
amento de riscos, composto por uma estrutura de risco, duas declarações de
riscos, um tipo de perfil, um perfil e dois riscos.
Figura 15 – Exemplo de escopo de perfis no gerenciamento de riscos
Fonte: Adaptado de ServiceNow (2018)
O escopo de perfil apresentado na Figura 15, mostra que a estrutura de
risco ”ameaças físicas e ambientais” possui as declarações de risco ”fogo” e
”terremoto”. O perfil ”escritórios de Nova York” está associado ao tipo de perfil
”escritórios globais”. Para cada perfil, gera-se um risco por declaração de risco.
No exemplo da Figura 15, como são duas declarações de risco associadas
ao tipo de perfil "escritórios globais", foram gerados os riscos de terremoto e fogo
para o perfil escritórios de Nova York.
O subprocesso contido no fluxo P2, é apresentado na Figura 16. São
cinco atividades principais que compõe a avaliação de riscos, sendo elas P2.10.1

52. 52
- rascunho, P2.10.2 - avaliar, P2.10.3 - responder, P2.10.8 - ”revisão ok?” e
P2.10.9 - monitorar.
Figura 16 – Processo de avaliação de riscos
Fonte: o autor (2018)
Os riscos quando são criados manualmente ou gerados automaticamente
como na atividade P2.8, iniciam na atividade P2.10.1. Nessa atividade o analista
de risco pode fazer a análise do risco, informar quem é o grupo responsável, o
proprietário do risco, as pessoas que serão entrevistadas na avaliação, ajustar a
pontuação do risco inerente/residual, adicionar indicadores, tarefas, controles,
etc. Concluindo essas configurações prévias, é iniciado a avaliação do risco.
No ServiceNow o risco qualitativo é calculado da seguinte maneira: pon-
tuação = impacto x probabilidade. Para que o cálculo esteja adequado com a
realidade da organização, deve ser configurado o valor monetário do impacto e
pontuação e a probabilidade no módulo “critérios de risco”.
Na atividade P2.10.2, os entrevistados recebem uma notificação infor-
mando que há uma nova avaliação de risco para ser respondida. Após submeter

53. 53
as respostas da avaliação, o fluxo avança para a atividade P2.10.3. Com base
nas respostas da avaliação, o analista de risco pode ajustar os mesmos campos
da atividade P2.10.1, como a pontuação do risco.
O tratamento do risco também deve ser feito na atividade P2.10.3. Os
subprocessos de evitar, mitigar ou transferir o risco são os mesmos. Por esse
motivo, será apresentado apenas o processo de transferir o risco na Figura 17.
Figura 17 – Processo para transferência de risco
Fonte: o autor (2018)
O processo apresentado na Figura 17, inicia com a definição da pessoa
que será responsável por descrever o plano. Após o responsável pelo plano
finalizar a atividade P2.10.7.2, ele revisa todas as informações e finaliza sua
tarefa.

54. 54
Ao finalizar a atividade P2.10.5, P2.10.6 ou P2.10.7, a atividade P2.10.8 é
iniciada. Nessa etapa, o analista de risco verifica se está de acordo com todas
as informações inseridas no risco. Caso não esteja de acordo, pode retornar
para a atividade P2.10.3. Ou pode estar de acordo, e seguir com a atividade
P2.10.9.
Na atividade P2.10.4, além de informar o responsável pelo plano de acei-
tação de risco, será necessário informar a data de término de aceitação do
risco. Além disso, é necessário aprovação do analista de riscos. Na Figura 18 é
apresentado o fluxo de aceitação de risco.
Figura 18 – Processo para aceitação de risco
Fonte: o autor (2018)
Ao definir uma data de término de aceitação do risco no subprocesso
ilustrado na Figura 18, e o subprocesso chegar na atividade P2.10.9, ficará agen-
dado no ServiceNow que após a data definida o risco retornará para a atividade
P2.10.1. Ou seja, será necessário iniciar um novo processo de avaliação de
riscos.

55. 55
No subprocesso P2.10.9, podem ser definidos indicadores para monitorar
o risco e a frequência de coleta de dados. Na Figura 19 é apresentado o
subprocesso de gestão de indicador.
Figura 19 – Processo de monitoramento de risco
Fonte: o autor (2018)
Conforme ilustrado na Figura 19, caso o indicador não esteja ok, é criado
automaticamente um problema para uma equipe tratar. Após analisar, responder
e revisar, o problema é encerrado e o ciclo de coleta de informações continua.
3.2 RELAÇÃO ENTRE O SERVICENOW E A NBR ISO/IEC 27005:2011
Após apresentação dos processos de gerenciamento de riscos utilizados
pelo ServiceNow, foi relacionado a NBR ISO/IEC 27005:2011 com a ferramenta
de IRM utilizada nesse trabalho. Na Figura 20 é apresentado a relação entre
as atividades presentes no processo de gestão de riscos de segurança da
informação da NBR ISO/IEC 27005:2011, com as atividades do processo de
gerenciamento de riscos do ServiceNow.

56. 56
Figura 20 – Relação entre o ServiceNow e a NBR ISO/IEC 27005:2011
Fonte: Adaptado de NBR ISO/IEC 27005:2011
Nos retângulos laranjas estão descritos as atividades, apresentadas com
seus identificadores, ao lado das atividades do processo de gestão de riscos de
segurança da informação da NBR ISO/IEC 27005:2011. Fundamentado pelo
o que é apresentado na Figura 20, entende-se que a aplicação de GRC do
ServiceNow foi desenvolvida com base nesse padrão internacional.

57. 57
3.3 CONFIGURAÇÃO DO AMBIENTE DO SERVICENOW
Essa subseção apresenta detalhes de configuração do cenário escolhido,
no ServiceNow. O cenário apresentado na Figura 21, é composto por ativos de
TI, ServiceNow, RabbitMQ, MuleSoft, ERP e Sistemas legados.
Figura 21 – Diagrama representando o cenário onde o estudo de caso foi aplicado
Fonte: o autor (2018)
Por restrições de acesso, não será abordado nesse trabalho detalhes do
ERP e sistemas legados. Porém, é apresentado de forma genérica na Figura

58. 58
21 para ilustrar a fonte de dados para o ServiceNow. Além do ERP e sistemas
legados, os ativos de TI também estão sendo representados de forma genérica.
O MuleSoft é visionário no quadrante do Gartner (2018b) em integration
Platform as a Service (iPaaS). Essa plataforma de integração centraliza e
organiza todas as integrações da organização, facilitando a reutilização das
integrações.
O RabbitMQ é uma aplicação de mensageria de código aberto. Aplicações
de mensagerias coordenam o envio e a recepção de mensagens em uma fila,
permitindo o envio e recebimento de mensagens em velocidades diferentes.
Por exemplo, o sistema A envia 10 mensagens a cada milissegundo. Já o
sistema B, consegue consumir 5 mensagens a cada milissegundo. Sem uma fila,
provavelmente algumas mensagens iriam se perder. Caso o sistema de destino
esteja indisponível, as mensagens aguardam na fila até serem consumidas
(RABBITMQ, 2018).
3.3.1 Classes de perfis
Para esse trabalho, o modelo de dependência das classes de perfis, foi
estruturado da seguinte maneira: Business Service e IT Asset tem impacto de
baixo para cima em Department e, Department impacta a Company que é o
nível mais alto. A Figura 22 apresenta esse modelo de dependência de classes.
Figura 22 – Modelo de dependência das classes de perfis
Fonte: o autor (2018)

59. 59
O modelo de dependência apresentado na Figura 22, mostra que um
ativo de TI tem impacto no departamento, que consequentemente, tem impacto
na organização. Essa é uma visualização gráfica gerada pelo módulo GRC
Workbench.
3.3.2 Tipos de perfis
Para cada classe, gera-se um ou mais tipos de perfis. Na Figura 23 é
apresentado o relacionamento entre classes e tipos de perfis com base na
visualização gráfica gerada pelo módulo GRC Workbench.
Figura 23 – Relacionamento entre tipos de perfis e o modelo de dependência das classes
de perfis
Fonte: o autor (2018)
No escopo atual, a estrutura de tipos de perfis mostrado na Figura 23
atende, mas é possível ter tipos de perfis mais específicos para cada classe de
perfil.

60. 60
3.3.3 Identificação dos perfis
Os perfis abordados nesse trabalho, estão listados no Quadro 2 e relacio-
nados ao tipo de perfil e classe de perfil.
Quadro 2 – Relacionamento entre tipos de perfis e o modelo de dependência das classes
de perfis
Fonte: o autor (2018)
Para esse trabalho, aborda-se doze perfis, distribuídos entre os tipos de
perfis computadores, roteadores, switchs, firewall, departamentos, companhia e
serviços de negócios conforme Quadro 2.
3.3.4 Controles existentes
Para cada perfil, foi analisado se possuíam algum controle. Se possuíam
controle, foi analisado a eficácia do controle. No Quadro 3 é apresentado o
relacionamento entre controle, perfil e eficácia.
Quadro 3 – Relacionamento controle, perfil e eficácia do controle
Fonte: o autor (2018)

61. 61
No Quadro 3 são expostos os controles existentes obtidos a partir de
entrevistas com os responsáveis de cada perfil. De todos os perfis, em apenas
três foi identificado um controle por perfil. Dois terços dos três controles, foram
identificados como eficaz. Apenas um controle foi identificado como eficácia
parcial, conforme Quadro 3.
3.3.5 Estruturas, declarações de riscos e tipos de perfis
Após associar as declarações de riscos com as estruturas de riscos,
cada tipo de perfil foi associado em uma estrutura de risco para que os riscos
sejam gerados. No Apêndice E é apresentado o relacionamento entre estrutura,
declaração de risco e tipo de perfil.
Conforme o Apêndice E, criou-se duas estruturas de risco, sete decla-
rações de riscos e sete tipos de perfis. Os tipos de perfis “departamentos” e
“companhia” não possuem estrutura de risco e declaração de risco associados.
Pois, o foco desse trabalho é gerenciar os riscos de TI.
3.3.6 Riscos identificados
Para cada perfil listado, foi gerado um risco por declaração de risco, totali-
zando trinta e seis riscos. No Apêndice F é apresentado o relacionamento entre
perfil e seus respectivos riscos.
3.3.7 Relacionamento entre controles e riscos
Após identificar os controles, é feito o relacionamento entre declaração
de risco, perfil, vulnerabilidade, controle e consequências. Esse relacionamento
é apresentado no Apêndice G. As consequências relacionadas a perda de
integridade, disponibilidade e confidencialidade, são provenientes da aplicação
padrão de GRC do ServiceNow. As demais consequências foram identificadas
pelo autor.

62. 62
3.3.8 Análise de riscos
Nesse trabalho optou-se por utilizar as configurações padrões dos critérios
de riscos. Na Tabela 1 é apresentado a configuração dos critérios de riscos da
aplicação de GRC do ServiceNow.
Tabela 1 – Configuração dos critérios de riscos
Fonte: o autor (2018)
Os resultados das avaliações de riscos são apresentados a partir do
Apêndice A até o Apêndice D por ordem de prioridade. Para obter os resultados,
foi utilizado como base de cálculo a Tabela 1 e a equação apresentada na seção
3.1.1.
Após análise dos dados apresentados nos Apêndice A até D, constatou-
se que 14% dos riscos tem a pontuação residual muito alta ou alta. Nesse
percentual estão inclusos os riscos de perda de disponibilidade para o perfil
MuleSoft e Aplicações do ServiceNow. Além de perda de confidencialidade para
os perfis: instância do ServiceNow, Aplicações do ServiceNow e MuleSoft.
A pontuação dos riscos também pode ser visualizada no ServiceNow
através de um dashboard. Na Figura 24 é apresentado os mesmos dados dos
Apêndices A até D, porém de maneira visual.

63. 63
Figura 24 – Dashboard de gerenciamento de riscos
Fonte: o autor (2018)
A Figura 24 auxilia na identificação de qual risco deve ser mitigado pri-
meiro. Através da matriz que apresenta a quantidade de riscos na intersecção
entre impacto e probabilidade, ou pela visão acima da matriz, que apresenta a
quantidade de riscos por pontuação.
A aplicação de GRC do ServiceNow também fornece outros gráficos, mas
para esse trabalho, decidiu-se utilizar apenas o que está apresentado na Figura
24.
3.3.9 Análise dos resultados obtidos
A organização deve priorizar o tratamento dos riscos classificados como
alto ou muito alto e avaliar a viabilidade de implementar as recomendações
apresentadas a seguir.

64. 64
A pontuação de risco para a maioria dos perfis da classe Business Ser-
vice pode ser considerado como alarmante, pois graves consequências podem
se manifestar na organização. Dentre as várias consequências possíveis, as
principais e mais graves são:
a) indisponibilidade do MuleSoft, ocasionando parada total ou parcial do
ServiceNow e outros sistemas conectados;
b) indisponibilidade total ou parcial das aplicações do ServiceNow, impac-
tando os funcionários do CSC e os solicitantes de serviços;
c) perda de confidencialidade do MuleSoft, da instância do ServiceNow e
suas aplicações, resultando no vazamento de informações pessoais
de funcionários, fornecedores, etc.
A indisponibilidade do ServiceNow ou MuleSoft pode afetar a operação
de 316 serviços executados pelo CSC. Na Figura 25 é apresentado o tipo de
integração, a quantidade e o percentual de serviços que utilizam integração.
Figura 25 – Tipos de integrações utilizadas no ServiceNow
Fonte: o autor (2018)

65. 65
Conforme apresentado na Figura 25, apenas 31% dos serviços não são
dependentes de integrações e os outros 69%, são dependentes de integrações
via Simple Object Access Protocol (SOAP) e/ou Extract Transform Load (ETL).
Na Figura 26 é demonstrado a relação entre os processos de negócios e as
integrações.
Figura 26 – Tipos de integrações utilizadas nos processos de negócio
Fonte: o autor (2018)
O processo de negócio que possui mais integrações, como mostra a Figura
26, e é o mais importante para organização, é o Order to Cash (OTC). O mesmo
contém os processos de faturamento, contas a receber, serviços ao cliente, etc.
Após a análise da avaliação de riscos, recomenda-se que a organização
priorize o tratamento dos riscos para os perfis MuleSoft, instância e aplicações
do ServiceNow.
Para o MuleSoft, recomenda-se que seja implementado uma arquitetura
hibrida para mitigar o risco de perda de disponibilidade. Ou seja, ter a plataforma
na nuvem padrão oferecida pelo fornecedor e em outra nuvem publica ou privada
gerenciada pela organização.

66. 66
Para o risco de perda de disponibilidade das aplicações do ServiceNow,
recomenda-se que seja implementado o processo de gestão de mudanças,
testes automatizados e versionamento de código.
Recomenda-se que fornecedores não tenham acesso a usuários e senhas
de produção para mitigar o risco de perda de confidencialidade para MuleSoft,
instância do ServiceNow e suas aplicações. Para as aplicações do ServiceNow,
também deve ser feito umas revisão dos Access Control (ACL) e roles para
mitigar o risco de perda de confidencialidade.
Além de todas essas recomendações, também deve ser iniciado o desen-
volvimento de PCNs para os riscos classificados como alto e muito alto. Bem
como um plano de tratamento de riscos, conforme sugere a norma NBR ISO/IEC
27005:2011.

67. 4 CONSIDERAÇÕES FINAIS
Com o crescimento exponencial de dispositivos conectados à internet
e com a preocupação das organizações, em se transformarem digitalmente e
terem seus sistemas interconectados, os riscos de segurança da informação
tendem a crescer.
Os riscos de segurança da informação ainda aumentam, quando os arquite-
tos de soluções e desenvolvedores estão preocupados em atender cronogramas
impossíveis de serem realizados e já acordados com os executivos do negócio.
Afastando-se cada vez mais de soluções seguras.
Para gerenciar os riscos de uma organização, a aplicação de GRC do Ser-
viceNow é uma alternativa. Para demonstrar sua aderência a um dos processos
de gerenciamento de riscos utilizados mundialmente, foi feito um relacionamento
entre a NBR ISO/IEC 27005:2011 e o ServiceNow.
Conforme apresentado no capítulo 3, com um estudo de caso foi demons-
trado a gestão de riscos em prática, utilizando a plataforma do ServiceNow e as
maneiras de priorizar os riscos, com indicadores e gráficos.
Nesse trabalho também foram apresentadas as normas e guias relaci-
onados a gestão de riscos, como a NBR ISO/IEC 27005:2011, NBR ISO/IEC
31000:2009, NIST 800-30, etc.
O trabalho mostrou com os resultados obtidos no capítulo 3, quais riscos
tem maior probabilidade e impacto de afetar negativamente a organização. Com
essas análises e informações disponibilizadas, a organização pode avaliar as
recomendações e priorizar o tratamento dos riscos. Desta forma, a organização
poderá evitar futuros impactos operacionais e financeiros.
Como sugestões de trabalhos futuros, poderá ser realizado um estudo
comparativo entre os líderes do quadrante mágico do Gartner para IRM. Também
poderá ser executado um estudo de caso com a aplicação de gerenciamento de
auditoria, gestão de riscos de fornecedores ou gestão de políticas e compliance
do ServiceNow. Esses estudos de casos irão contribuir para o entendimento
completo da aplicação de GRC do ServiceNow.

68. REFERÊNCIAS
27001 Academy. Lista de verificação dos documentos obrigatórios da iso 22301.
Croácia, 2014.
ABRAPP, A. B. das Entidades Fechadas de P. C. Guia de Boas Práticas
para Planos de Continuidade de Negócios. São Paulo: Comissão Técnica
Regional Sudeste de Governança da ABRAPP, 2012.
ALMEIDA, M. C. Auditoria: Um Curso Moderno e Completo. 3a
. ed. [S.l.]:
Saraiva, 1998.
AUDIBRA, I. dos Auditores Internos do B. Normas brasileiras para o exercício
da auditoria interna. 3a
. ed. [S.l.: s.n.], 1991.
BRASIL, S. Gestão de riscos / Superior Tribinual de Justiça. Brasília: STJ,
2016.
BS ISO/IEC 22301. Societal security – Business continuity management
systems – Requirements. 2012.
CAMPOS, A. SISTEMA DE SEGURANÇA DA INFORMAÇAO: CONTRO-
LANDO OS RISCOS. Santa Catarina: VISUAL BOOKS, 2014.
CERULLO, V.; CERULLO, M. J. Business continuity planning: a comprehensive
approach. Missouri, 2004.
CMI, C. M. I. A Decade of Living Dangerously: The Business Continuity
Management Report 2009. Londres, 2009.
COSO, C. of Sponsoring Organizations of the T. C. Gerenciamento de Riscos
Corporativos - Estrutura Integrada. New Jersey: AICPA, 2007.
COSO, C. of Sponsoring Organizations of the T. C. Controle interno - estrutura
integrada. AICPA, 2013.
ERICSSON. Ericsson mobility report on the pulse
of the networked society. 2015. Disponível em:
<https://www.ericsson.com/assets/local/news/2016/03/ericsson-mobility-
report-nov-2015.pdf> Acesso em: 02 out. 2017.
GARTNER. Gartner Says 8.4 Billion Connected "Things"Will Be
in Use in 2017, Up 31 Percent From 2016. 2017. Disponível em:
<https://www.gartner.com/newsroom/id/3598917> Acesso em: 02 out. 2017.

69. 69
GARTNER. Magic Quadrant for Enterprise High-Productivity
Application Platform as a Service. 2018. Disponível em:
<https://www.gartner.com/doc/reprints?id=1-4UCCMEPct=180329st=sb>
Acesso em: 30 ago. 2018.
GARTNER. Magic Quadrant for Enterprise Integration Platform as a
Service. 2018. Disponível em: <https://www.gartner.com/doc/reprints?id=1-
4WJHF99ct=180418st=sg> Acesso em: 02 nov. 2018.
GARTNER. Magic Quadrant for Integrated Risk Management. 2018. Disponí-
vel em: <https://www.gartner.com/doc/reprints?id=1-4XF62IOct=180424st=sb>
Acesso em: 30 ago. 2018.
GIL, A. C. Como elaborar projetos de pesquisa. 5a
. ed. São Paulo: Atlas,
2010.
HAYES, B. Conducting a Security Audit: An Introductory Overview. 2003.
Disponível em: <https://www.symantec.com/connect/articles/conducting-security-
audit-introductory-overview> Acesso em: 17 nov. 2017.
HOUAISS. Dicionário da Língua Portuguesa Houaiss. 2017. Disponível em:
<https://www.cert.br/stats/incidentes/> Acesso em 02 nov. 2017.
IBGC. Guia de Orientação para o Gerenciamento de Riscos Corporativos.
São Paulo: IBGC, 2007.
IIA, T. I. of I. A. . Bussiness Continuity Management. Flórida, 2014.
ISACA. Risk Scenarios - Using COBIT 5 for Risk. Illinois: Information Systems
Audit and Control Association, 2014.
ISACA. Is audit/assurance program cybersecurity: Based on the nist
cybersecurity framework. ISACA, Illinois, 2016.
ISO/IEC 27001. Information technology – Security techniques – Information
security management systems – Requirements. 2013.
ISO/IEC 27002. Information technology – Security techniques – Code of
practice for information security management. 2013.
ISO/IEC 27005. Information technology – Security techniques – Information
security risk management. 2011.
ISO/IEC 27032. Information technology – Security techniques – Guidelines
for cybersecurity. 2012.

70. 70
ISO/IEC 27033-1. Information technology — Security techniques —
Network security — Part 1: Overview and concepts. 2015.
ISO/IEC 31010. Risk Management — Risk Assessment Techniques. 2009.
JUNIOR, J. H. P. et al. Auditoria das demonstrações contábeis. 2. ed. [S.l.]:
FGV editora, 2011.
LUDESCHER, W. Modelo para avaliação da qualidade de projetos de planos
de continuidade de negócios aplicados a sistemas computacionais. Tese
(Doutorado) — Universidade de São Paulo, 2012.
MELLO, A. de O. Organização básica da auditoria interna. [S.l.]: Biblioteca
Técnica de Auditoria Interna, 2005.
NBR ISO/IEC 19011. Diretrizes para auditorias de sistema de gestão da
qualidade e/ou ambiental. 2012.
NBR ISO/IEC 31000. Gestão de riscos – Princípios e diretrizes. 2009.
NIST, S. 800-30. Risk management guide for information technology
systems, p. 800–30, 2012.
PEREIRA, U. S. et al. Plano de contingência de ti: preparando sua empresa para
reagir a desastres e manter a continuidade do negócio. 2011.
PWC. Gestão de Continuidade de Negócios. [S.l.], 2017.
RABBITMQ. RabbitMQ is the most widely deployed open source message
broker. 2018. Disponível em: <https://www.rabbitmq.com/> Acesso em: 02 nov.
2018.
RICARTE, I. L. M. O que é uma classe. 2000. Disponível em:
<http://www.dca.fee.unicamp.br/cursos/PooJava/classes/conceito.html>
Acesso em: 29 set. 2018.
RODRIGUES, R. W. da S.; FERNANDES, J. H. C. Auditoria e Conformidade
de Segurança da Informação. 1a
. ed. [S.l.]: CEGSIC, 2011.
SÊMOLA, M. Gestão da segurança da informação: uma visão executiva.
Rio de Janeiro: Elsevier, 2014.
SERVICENOW. Establish profile scoping for risks. 2018. Disponí-
vel em: <https://docs.servicenow.com/bundle/london-governance-risk-
compliance/page/product/grc-risk/concept/profiles-risk.html> Acesso em: 29 set.
2018.

71. 71
SMITH, D. Business Continuity Management: Good Practices Guidelines.
Berkshire: Business Continuity Institute, 2008. Disponível em: <http:
//www.thebci.org/gpg.htm>. Acesso em 25 mar. 2009.
SWANSON, M. et al. NIST Special Publication 800-34 Contingency Planning
Guide for Federal Information Systems. NIST special publication, p. 149, 2010.
TOIGO, J. W. Disaster Recovery Planning: Preparing for the Unthinkable.
New Jersey: Pearson Education, 2003.

72. 5 APÊNDICES
APÊNDICE A - RISCOS COM PONTUAÇÃO RESIDUAL ALTA E MUITO
ALTA
APÊNDICE B - RISCOS COM PONTUAÇÃO RESIDUAL MODERADA
APÊNDICE C - RISCOS COM PONTUAÇÃO RESIDUAL BAIXA
APÊNDICE D - RISCOS COM PONTUAÇÃO RESIDUAL MUITO BAIXA
APÊNDICE E - RELACIONAMENTO ENTRE ESTRUTURAS, DE CLARA-
ÇÕES DERISCOS E TIPOS DE PERFIS
APÊNDICE F - RELACIONAMENTO ENTRE PERFIL, RISCO E CATEGO-
RIA
APÊNDICE G - RELACIONAMENTO ENTRE CONTROLES E RISCOS

73. APÊNDICE A - RISCOS COM PONTUAÇÃO RESIDUAL ALTA E MUITO
ALTA

74. APÊNDICE B - RISCOS COM PONTUAÇÃO RESIDUAL MODERADA

75. APÊNDICE C - RISCOS COM PONTUAÇÃO RESIDUAL BAIXA

76. APÊNDICE D - RISCOS COM PONTUAÇÃO RESIDUAL MUITO BAIXA

77. APÊNDICE E - RELACIONAMENTO ENTRE ESTRUTURAS, DE
CLARAÇÕES DERISCOS E TIPOS DE PERFIS

78. APÊNDICE F - RELACIONAMENTO ENTRE PERFIL, RISCO E CATEGORIA

79. APÊNDICE G - RELACIONAMENTO ENTRE CONTROLES E RISCOS