Segurança da Informação e Tratamento de Incidentes - III_Teorico

Prévia do material em texto

Inserir Título Aqui 
Inserir Título Aqui
Segurança da Informação e 
Tratamento de Incidentes
Categorização de Incidentes e Avaliação de Riscos
Responsável pelo Conteúdo:
Prof. Esp. Antonio Eduardo Marques da Silva
Revisão Textual:
Prof.ª Dr.ª Selma Aparecida Cesarin
Nesta unidade, trabalharemos os seguintes tópicos:
• Classificação de Incidentes;
• Gerenciamento de Riscos;
• Identificação de Riscos;
• Erros da Gestão de Riscos do Projeto. Fonte: Getty Im
ages
Objetivo
• Compreender e abordar o entendimento sobre a categorização de incidentes e avaliação 
de riscos, apresentando os conceitos de: notificação e identificação de anomalias no Sis-
tema Corporativo (triagem), contenção, análise, rastreamento (ação/reação), reparo e 
recuperação, prevenção (acompanhamento).
Caro Aluno(a)!
Normalmente, com a correria do dia a dia, não nos organizamos e deixamos para o úl-
timo momento o acesso ao estudo, o que implicará o não aprofundamento no material 
trabalhado ou, ainda, a perda dos prazos para o lançamento das atividades solicitadas.
Assim, organize seus estudos de maneira que entrem na sua rotina. Por exemplo, você 
poderá escolher um dia ao longo da semana ou um determinado horário todos ou alguns 
dias e determinar como o seu “momento do estudo”.
No material de cada Unidade, há videoaulas e leituras indicadas, assim como sugestões 
de materiais complementares, elementos didáticos que ampliarão sua interpretação e 
auxiliarão o pleno entendimento dos temas abordados.
Após o contato com o conteúdo proposto, participe dos debates mediados em fóruns de 
discussão, pois estes ajudarão a verificar o quanto você absorveu do conteúdo, além de 
propiciar o contato com seus colegas e tutores, o que se apresenta como rico espaço de 
troca de ideias e aprendizagem.
Bons Estudos!
Categorização de Incidentes e Avaliação de Riscos
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
Contextualização
Você sabe definir o que é Segurança da Informação e quais os conceitos essenciais 
que podem caracterizá-la? Saberia explicar o que é um incidente e como categorizá-lo?
Qual a importância de uma boa política de Segurança da Informação para uma Organização?
Como existem diferentes Tecnologias aplicadas em Segurança da Informação, você 
deve estar se perguntando como é possível entender melhor o seu funcionamento.
Embora possamos aprender várias ferramentas ou tecnologias em segurança, preci-
samos focar em alguma(s), principalmente, as mais utilizadas no Mercado, para termos 
maior facilidade de manuseio.
Nesta Unidade, vamos entender como classificar os incidentes e quais benefícios 
eles podem trazer para uma Empresa, bem como entender a definição de risco e como 
identificá-los para evitar problemas em relação à segurança da infraestrutura e dos ser-
viços de TIC.
Não se preocupe!
Nesta Disciplina, iremos abordar alguns conceitos fundamentais para que você possa 
entender como funciona alguns recursos, técnicas e ferramentas que fazem parte de um 
Sistema de Gestão da Segurança da Informação.
Vamos começar!
6
7
Classificação de Incidentes
A classificação de incidentes é um dos aspectos mais importantes e mais difíceis da im-
plementação da ITIL. Os benefícios superam em muito os desafios gerenciais envolvidos.
Por meio da Classificação de Incidentes e do Suporte Inicial, a equipe do Service 
Desk visa a determinar o motivo de um incidente e como direcioná-lo para uma resolução.
A Biblioteca de Infraestrutura de TI (ITIL – Information Technology Infrastructure 
Library) gasta um tempo considerável discutindo a classificação.
Há muitos formulários gratuitos e listas de verificação disponíveis, e a maioria dos 
sistemas automatizados oferece assistência integrada com classificação.
Tais incidentes tendem a saltar de grupo para grupo e sofrem muitos crescimentos 
e transferências. Esses incidentes “saltantes” consomem recursos organizacionais sig-
nificativos e infligem serviços ruins a usuários e a clientes. Felizmente, existem várias 
correções rápidas e fáceis para esse problema. 
A seguir, vamos descrever 9 passos simples para melhorar a classificação de inciden-
tes e oferecer um esquema de classificação mais simples (BAARS, 2018).
Sobre a classificação
Toda a classificação se resume a tentar entender e identificar quais Sistemas são 
afetados e em que grau. A classificação eficaz de incidentes ajuda no encaminhamento 
do incidente para a Equipe correta, na primeira tentativa, por que a classificação, ge-
ralmente, é feita incorretamente, mesmo com todos os recursos, ferramentas e tempo 
dedicados a determinado assunto.
A classificação de incidentes começa a dar errado quando os scripts de diagnóstico 
(scripts) se tornam muito complexos. Embora extremamente valiosos, os scripts exigem 
esforço de gerenciamento.
No entanto, tentar coletar enormes quantidades de dados por meio de dúzias de 
perguntas desacelera o processo de classificação, complica o fluxo de trabalho e resulta 
numa classificação incompleta. Uma observação simples é manter seus scripts de diag-
nóstico tão simples e objetivos quanto possível (MILAR, 2012).
Lista de verificação para melhorar a Classificação de Incidentes
Para simplificar o processo de classificação, melhorar sua eficiência e começar a rei-
nar naqueles “Incidentes desconhecidos”, considere o seguinte:
• Use scripts de diagnóstico: use scripts para padronizar e formalizar a Classificação 
de Incidentes. Sem procedimentos de script de som (manual ou automatizado), você 
não pode desenvolver as informações de gerenciamento necessárias para garantir 
7
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
sua eficácia. Sem um processo repetitivo (por exemplo, um script), você não pode 
classificá-los de maneira confiável;
• Não classificar somente por sintoma: certifique-se de não usar sintomas docu-
mentados como sua classificação. Os sintomas mudam e podem ser enganosos.
Documente o Item de Configuração (CI) julgado em questão. Registre os sintomas 
num campo de comentários, mas saiba que usuários diferentes reportarão sintomas 
diferentes para o mesmo incidente. Classificar em sintoma é uma das piores práticas;
• Classifique incidentes, não registrando apenas chamadas: certifique-se de 
que você está realmente realizando a Classificação de Incidentes, e não simples-
mente registrando chamadas. Se você estiver registrando chamadas, não se pre-
ocupe em tentar executar a Classificação de Incidentes. Registrar chamadas é 
uma atividade muito diferente da Classificação e do Suporte Inicial. O registro de 
chamadas simplesmente reúne dados de resolução e identificação que um espe-
cialista usará posteriormente;
• Mantenha-o simples: revise seus scripts de diagnóstico com frequência, certifique-
-se de que eles não sejam tão complicados que a equipe não possa concluí-los num 
período de tempo razoável. Inclua como um código de diagnóstico “outro” ou “des-
conhecido” e rastreie esses códigos. Esses códigos são um indicador de que seus 
scripts precisam de manutenção;
• Use seu catálogo de serviços: se você tiver um catálogo de serviços, use-o.
Se você não tiver um, considere implementar um. Fazer referência a um serviço 
num catálogo acelera a atividade de registro de incidentes. Também resulta em 
menos informações coletadas e, portanto, menos burocracia. Por fim, ele fornece 
aumento na precisão dos dados no registro de incidentes e pode ajudar no encami-
nhamento, na escalação e no suporte;
• Tire proveito de suas ferramentas: muitas das ferramentas automatizadas dis-
poníveis atualmente fornecem suporte sólido para classificação de incidentes.
Investigue as capacidades de qualquer sistema que você tenha. Se apropriado, use 
esses recursos. Apenas lembre-se de manter as regras o mais simples possível;
• Avalie sua maturidade: avalie honestamente a maturidade de sua Organização, 
processos e pessoas. Uma abordagem gradual ao longo do tempo é a melhor abor-
dagem na maioria dos casos. Isso é especialmente verdadeiropara Organizações 
novas ou imaturas. O motivo da avaliação é estabelecer uma expectativa razoável 
de capacidade e desempenho antes de implantar seu novo Sistema de Classificação 
de Incidentes! A mais alta eficiência só ocorre quando você tem, pelo menos, o 
gerenciamento básico de configuração, problemas e níveis de serviço;
• Valide seu escopo: é muito importante perceber que nem todos os eventos que 
ocorrem garantem um incidente. É fácil definir seu escopo muito amplo ou muito 
estreito. Muito amplo: todos os eventos normais do Sistema automatizado podem 
se tornar um incidente, sobrecarregando sua equipe e seus sistemas.
Os Dados: Segurança da Informação. Disponível em: https://youtu.be/qTOBYMOT8-I.
8
9
Esquema de Classificação Simples
Itens de Configuração (CI) formam a base de toda a Classificação. A questão é de 
profundidade. Muitas vezes, a classificação leva uma das duas formas:
• Classificação baseada no IC físico (por exemplo, estação de trabalho, aplicativo de 
software etc.);
• Classificação baseada no CI de serviços de TI (por exemplo, Entrada de Pedidos, 
Internet etc.).
No mínimo, sua classificação deve operar no IC físico. Conforme você amadurece 
(ou seja, tem um Gerenciamento de Nível de Serviço mais definido), você também pode 
expandir para o serviço de TI afetado. Um esquema de classificação eficaz e simples 
pode ter:
• Tipo;
• Categoria;
• Subcategoria.
O campo Tipo deve concentrar o suporte necessário pelo tipo de incidente (muitas 
vezes, também é onde a priorização começa).
Existem três tipos básicos de interações do Service Desk descritas no ITIL:
• Falha ou Erro;
• Solicitação de Serviço;
• Assistência/Consulta.
O campo Categoria tem a função de selecionar um domínio tecnológico de especializa-
ção. Tente manter o campo Categoria para o menor número possível de áreas principais.
Alguns exemplos:
• Hardware;
• Software;
• Rede;
• Pessoas;
• Processo;
• Acomodação.
Já a subcategoria conduz ao grupo específico dentro do domínio de conhecimento 
tecnológico identificado pela categoria. As entradas aqui são bem específicas para sua 
Organização. Novamente, é melhor manter a lista o menor possível e, ao mesmo tempo, 
transmitir de forma eficaz.
9
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
Alguns exemplos:
• Hardware: estação de trabalho, impressora, monitor, roteador, PBX, telefone etc.;
• Software: processamento de texto, planilha eletrônica, Banco de Dados, entrada 
de pedidos etc.;
• Alojamento: mover/adicionar/alterar etc.
Podemos dar como exemplo a saída de um Sistema, como segue:
• Tipo: Falha/Falha;
• Categoria: Software;
• Subcategoria: Banco de Dados.
Benefícios da Classificação efetiva
A categorização de sucesso ajuda de várias maneiras. Aqui, estão algumas delas:
• Encontre rapidamente soluções (soluções alternativas e/ou correções) para incidentes;
• Encaminhe corretamente os incidentes para o Grupo de Suporte correto;
• Reúna dados suficientes para acelerar diagnósticos por suporte de nível;
• Auxilia o Gerenciamento de Problemas na construção e manutenção de uma base 
de conhecimento;
• Melhora a eficiência de Grupos Técnicos/Funcionais;
• Melhora as satisfações do cliente;
• Aumenta a produtividade do usuário;
• Constrói a maturidade em direção a operações mais proativas.
Como classificar Incidentes
Como categorizar ou classificar incidentes talvez seja uma das perguntas mais co-
muns que surgem ao tentar estabelecer o Gerenciamento de Incidentes com base na IT 
Infrastructure Library (ITIL). 
De acordo com o ITIL, o objetivo da classificação de incidentes e do Suporte inicial é:
• Especifique o serviço com o qual o incidente está relacionado;
• Associe o incidente a um Acordo de Nível de Serviço (SLA);
• Identifique a prioridade com base no impacto nos negócios;
• Defina quais perguntas devem ser feitas ou quais informações devem ser verificadas;
• Determine uma matriz primária de relatórios para Informações de Gerenciamento;
• Identifique um relacionamento para combinar com erros conhecidos ou soluções;
• Selecione e/ou defina o melhor especialista ou grupo para lidar com o incidente.
10
11
Assim, a Classificação de Incidentes existe, principalmente, para classificar os Inci-
dentes, a fim de fornecer suporte inicial.
Suporte inicial significa análise adequada e avaliação. A classificação não é para de-
terminar a causa raiz nem as causas técnicas do incidente.
Essa observação única, de que a classificação de incidentes não é para identificar 
problemas, mas para orientar o fluxo de trabalho, causa uma tremenda quantidade de 
angústia. O problema se agrava quando os fornecedores promovem esquemas de clas-
sificação projetados para técnicos experientes e não para agentes de service desk ou 
suporte técnico de primeiro nível (MILAR, 2012).
Os fundamentos da classificação foram apresentados anteriormente (veja os links a 
seguir). Agora, quero explorar os problemas por trás da própria hierarquia de classifica-
ção, que é onde a maioria dos profissionais enfrenta problemas.
Com base na minha experiência em ajudar a projetar Sistemas de Classificação, o 
seguinte compara e contrasta dois esquemas de classificação diferentes e fornece um 
modelo que realmente reflete as práticas do ITIL.
Número 1 – Categoria/Tipo/Item
Muitas ferramentas de gerenciamento de serviços de TI que oferecem automação de ge-
renciamento de incidentes usam uma simples Categoria/Tipo/Item (CTI) para classificação.
O CTI é uma abordagem de três níveis para definir “Categoria”, um “Tipo” associado 
à “Categoria” e um “Item” associado ao “Tipo”. Uma abordagem popular sugere que 
Category e Type sejam “substantivos” e Item seja um “verbo”.
Depois de determinar que a consulta é um Incidente, não uma Solicitação de Altera-
ção (RFC) ou uma Solicitação de Serviço, e deduzindo que o Incidente está relacionado 
a um Banco de Dados Oracle, por exemplo, que exige uma atualização, a equipe do 
Service Desk codifica o Incidente como:
Banco de Dados | Oracle | Atualizar.
No entanto, a abordagem do CTI pode limitar sua eficácia, pois existem alguns pro-
blemas que não são tão sutis com sua lógica. 
O CTI funciona bem quando o trabalho necessário é conhecido, como nesse exem-
plo. Mas o CTI rapidamente se torna problemático quando o fluxo de trabalho não é 
bem conhecido. A investigação e o diagnóstico extra, necessários para solucionar o in-
cidente para concluir a classificação CTI, é precisamente o problema com a abordagem 
CTI, pois complica a coleta de dados e combina a classificação e o suporte inicial com 
investigação e diagnóstico, o que confunde a finalidade do suporte inicial.
O motivo é simples: o CTI assume um entendimento técnico das causas dos Inciden-
tes e a maioria dos funcionários do Service Desk (aqueles que realizam Classificação e 
11
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
Suporte Inicial) não saberão a causa de um incidente até que ele avance na atividade de 
Investigação e Diagnóstico e talvez até fechadas.
Esse tipo de classificação, geralmente, ocorre quando um grupo de especialistas em 
Tecnologia determina (por conta própria) como a transferência de tickets funcionaria se 
eles pudessem projetar um Sistema que eles usariam, para serem usados por pessoas 
que sabem o que sabem (NIELES, 2017).
Naturalmente, o problema aqui é que a Equipe Técnica não executa Classificação e 
Suporte Inicial; agentes de Service Desk relativamente não técnicos.
Em outras palavras, para solicitações de serviço em que o fluxo de trabalho é óbvio, 
o CTI está bem. No entanto, para Falhas ou quando o fluxo de trabalho não é conheci-
do, pode se tornar problemático quando usado por agentes não técnicos. Claramente, 
precisamos de outra abordagem que seja menos técnica e mais flexível.
Repensando o CTI
Vamos voltar ao que exatamente é um incidente. O ITIL define um incidente como: 
“Qualquer evento que não faça parte da operação padrão de um serviço e que cause ou 
possa causaruma interrupção ou uma redução na qualidade desse serviço.” 
Essa é uma definição bastante ampla, que abrange dois tipos amplos de trabalho:
• Falhas, panes;
• Pedidos de serviços novos ou adicionais.
Solicitações de serviço abrangem um nível adicional de detalhes. Exemplos de solici-
tações de serviço incluem:
• Perguntas sobre o uso de serviços (por exemplo, consultas de aplicativos, geralmen-
te tratadas no Service Desk);
• Ações de rotina (por exemplo, redefinições de senha ou solicitações.
Além disso, o Service Desk, no qual o Gerenciamento de Incidentes começa, também 
coleta as Solicitações de Mudança (RFCs) por meio do processo de Execução da Solicitação.
Embora uma RFC não seja um tipo de incidente, o Service Desk deve ser capaz de 
identificá-las e manipulá-las conforme necessário, geralmente, para transmitir para o 
Change Management ou gerenciamento de trocas. 
Isso complica um pouco a classificação, pois agora temos de determinar se a consulta 
é uma Solicitação e não um Incidente; e se for um Incidente, qual tipo de incidente ele 
representa, ou seja, Falha ou uma Consulta de Aplicação (como usar um aplicativo ou 
recurso ou função do Sistema). 
Cada uma das possibilidades tomará um caminho diferente por meio da Organização 
de TI. Essa verdade torna a primeira entrada na taxonomia de classificação de um tipo 
(por exemplo, caminho por meio da TI para um grupo de suporte) e não uma categoria 
(por exemplo, o que deve acontecer quando chegar ao grupo correto). 
12
13
O Service Desk tem de ser capaz de separar as consultas do usuário em uma dessas 
caixas e, em seguida, manipular cada uma apropriadamente.
Agora você começa a entender por que a Classificação é uma das perguntas mais 
frequentes do praticante e por que o CTI pode não estar certo para todos que se apro-
ximam da classificação do Incidente (NIELES, 2017).
Número 2 – Classificação ITIL
O suporte inicial tem a função de determinar que tipos de suporte ao cliente ou ao 
usuário são necessários. 
A classificação determina o suporte inicial que o cliente ou o usuário requer e isso 
significa que a primeira entrada na taxonomia de classificação deve indicar o tipo de tra-
balho que deve ser realizado e deve definir claramente como a Organização de TI deve 
responder (não quem na Organização deve responder). 
Por esses motivos, o ITIL fornece um exemplo dessa atividade e rotula o primeiro 
elemento de sua taxonomia de classificação como “Tipo”. A entrada Tipo descreve o 
amplo envolvimento funcional necessário para oferecer suporte ao cliente ou usuário. 
Existem apenas alguns tipos baseados nos possíveis questionamentos do usuário. O 
número exato de Tipos deve ser determinado, mas deve representar claramente o curso 
principal da Organização. 
Alguns exemplos incluem:
• Requisição de serviço;
• Falha;
• Incidente técnico;
• Ajuda e assistência.
O uso de um elemento Tipo estabelece a base para trabalhos conhecidos, como RFC, 
solicitação de serviço ou falha, e permite diferenciar listas para categorias de nível supe-
rior ou principal. Exemplos de categorias principais por tipo podem incluir:
• Requisição de Serviço:
 » Mover/Adicionar/Alterar para o sistema;
 » Resetar a senha.
• Falha:
 » Impressora não imprimindo;
 » Sistema caiu.
• Incidente Técnico:
 » Limite de uso de disco excedido;
 » Alerta automático.
13
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
• Ajuda/Assistência:
 » Pedido de informação;
 » Assistência usando aplicação.
Tratamento de Incidentes de Segurança na Internet do NIc.br.
Disponível em: https://youtu.be/flu6JPRHW04.
Alguns Tipos de Incidentes
Para facilitar ainda mais a classificação de Incidentes, decidimos incluir aqui alguns 
exemplos (tipos) mais próximos do nosso dia a dia:
• Incidentes de Eventos: um Incidente de Evento é criado por um produto de geren-
ciamento de eventos quando ocorre um evento significativo e requer investigação 
adicional pelos operadores da central de atendimento. Os incidentes de evento con-
têm apenas informações sobre o evento. Eles não contêm dados relacionados ao IC;
• Incidentes de Infraestrutura: um Incidente de Infraestrutura é criado por um pro-
duto de gerenciamento de eventos, que inclui uma referência a um IC. Este IC é 
a causa provável do evento. Incidentes de infraestrutura contêm informações de 
evento e de IC consolidadas num único incidente. Um incidente de infraestrutura 
não leva em consideração os relacionamentos com outros ICs afetados;
• Incidentes Causais: um Incidente Causal é criado por um produto de gerencia-
mento de eventos, que inclui uma referência a um IC. Este IC é a causa provável do 
evento. Incidentes causais contêm informações de evento e de IC consolidadas num 
único incidente. Um Incidente Causal leva em conta os relacionamentos com outros 
ICs impactados conforme o modelo de impacto. As informações sobre os ICs de 
interesse impactados estão listadas na Tabela Relacionamentos do Incidente Causal;
• Incidentes de impacto: um Incidente de Impacto destina-se a documentar qual-
quer IC de interesse que possa ter sido afetado por um evento registrado em relação 
a um IC relacionado de nível inferior. Esses incidentes são usados para fins de notifi-
cação, rastreamento e geração de relatórios. Por exemplo, se o serviço de negócios 
de e-mail for identificado como o IC de interesse, se algum IC de infraestrutura, 
como um servidor de e-mail que ofereça suporte ao serviço de e-mail, for afetado 
por um Incidente Causal para o servidor de e-mail, um Incidente de Impacto para 
o serviço de e-mail pode ser gerado. Os incidentes de impacto não são ativamente 
trabalhados pelos técnicos da central de atendimento para abordar a causa raiz.
Os técnicos do service desk, tradicionalmente, trabalham no Incidente Causal para 
resolver o problema. Quando o Incidente Causal é resolvido, os Incidentes de Im-
pacto relacionados são automaticamente resolvidos.
14
15
Gerenciamento de Riscos
Risco é uma medida da extensão em que uma Entidade é ameaçada por uma circuns-
tância ou evento em potencial, e tipicamente uma função de: (i) os impactos adversos 
que surgiriam se a circunstância ou evento ocorresse; e (ii) a probabilidade de ocorrência. 
Indivíduos gerenciam os riscos todos os dias, embora possam não estar cientes disso. 
As ações tão rotineiras quanto o cinto de segurança de um carro, carregar um guarda-
-chuva quando a chuva é prevista ou escrever uma lista de coisas para fazer, em vez de 
confiar na memória, ficam todas sob a alçada do gerenciamento de riscos.
Os indivíduos reconhecem várias ameaças aos seus melhores interesses e tomam 
precauções para protegê-los ou minimizar seus efeitos.
Tanto o governo, Empresas privadas e a Indústria administram rotineiramente uma 
miríade de riscos. Por exemplo, para maximizar seu retorno sobre os investimentos, as 
Empresas precisam escolher entre planos de investimento em crescimento que sejam 
agressivos e de alto risco ou lentos e seguros. Essas decisões requerem análise de risco em 
relação aos benefícios potenciais, consideração de alternativas e, finalmente, a implemen-
tação do que a gerência determina como o melhor curso de ação (BAARS, 2018).
Com relação à segurança da informação, o gerenciamento de riscos é o processo de 
minimizar riscos às operações organizacionais (por exemplo, missão, funções, imagem 
e reputação), ativos organizacionais, indivíduos, outras Organizações, conforme descrito 
na Nation Resulting from the Operation of a System ou NIST.
O NIST SP 800-39 identifica quatro etapas distintas para o Gerenciamento de Ris-
cos. O Gerenciamento de Riscos exige que as Organizações (i) enquadrem os riscos, (ii) 
avaliem o risco, (iii) respondam ao risco e (iv) monitorem o risco.
Vamos descrever esses itens de uma forma resumida:
• Enquadramento do Risco: descreve como as Organizações estabelecem um con-
texto de risco para o ambiente no qual as decisões baseadas no risco são tomadas. 
O objetivo do componente de enquadramentode risco é produzir uma estratégia 
de Gerenciamento de Risco que aborda como as Organizações pretendem avaliar, 
responder e monitorar riscos, enquanto torna explícitas e transparentes as per-
cepções de risco que as organizações usam rotineiramente na tomada de decisões 
operacionais e de investimento;
• Avaliação de Risco: descreve como as Organizações analisam o risco dentro do con-
texto do quadro de risco organizacional. O objetivo do componente de avaliação de 
risco é identificar: (i) ameaças às operações e ativos da Organização, indivíduos, e 
outras; (ii) vulnerabilidades internas e externas das Organizações; (iii) os danos (ou seja, 
consequências/impacto) às Organizações que possam ocorrer devido ao potencial de 
ameaças que exploram vulnerabilidades e (iv) a probabilidade de ocorrência de danos;
15
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
• Respondendo ao Risco: aborda como as Organizações respondem ao risco 
quando esse risco é determinado com base nos resultados das avaliações de risco.
A finalidade do componente de resposta ao risco é fornecer uma resposta con-
sistente e ampla da Organização ao risco, de acordo com o quadro de risco orga-
nizacional: (i) desenvolvendo cursos de ação alternativos para responder ao risco; 
(ii) avaliar os cursos alternativos de ação; (iii) determinar cursos apropriados de 
ação consistentes com a tolerância de risco organizacional e (iv) implementar 
respostas de risco com base em cursos de ação selecionados;
• Monitoramento do Risco: aborda como as Organizações monitoram os riscos ao 
longo do tempo. A finalidade do componente de monitoramento de risco é: (i) verificar 
se as medidas de risco planejadas são implementadas e se os requisitos de Segurança 
da Informação derivam/rastreiam para missões organizacionais/funções Empresa-
riais, Legislação federal, diretivas, regulamentos, políticas, padrões e diretrizes estão 
satisfeitos; (ii) determinar a eficácia contínua das medidas de resposta ao risco após a 
implementação; e (iii) identificar mudanças que impactam o risco nos Sistemas Orga-
nizacionais e nos ambientes em que os Sistemas operam.
Para ajudar as Organizações a gerenciar melhor o risco de Segurança da Informação 
no nível do Sistema, o NIST desenvolveu o Risk Management Framework (RMF). 
O RMF promove os conceitos de Gerenciamento de Risco quase em tempo real e 
atualização contínua do Sistema por meio da implementação de processos robustos de 
monitoramento contínuo. O RMF também fornece aos líderes seniores as informações 
necessárias para tomar decisões econômicas e baseadas em riscos com relação aos Sis-
temas Organizacionais que suportam suas principais missões e funções de negócios e 
integra segurança de informações na arquitetura corporativa e Ciclo de Vida de Desen-
volvimento de Sistemas ou, do inglês, System Development Life Cycle (SDLC). 
As seis etapas que compõem o RMF incluem:
1. Categorização do Sistema;
2. Seleção de Controle de Segurança;
3. Implementação de Controle de Segurança;
4. Avaliação de Controle de Segurança;
5. Autorização do Sistema;
6. Monitoramento de Controle de Segurança.
Vamos, então, conhecer um pouco mais sobre cada etapa do RMF em sequência:
• Categorizar: o primeiro passo do RMF concentra-se na categorização do Siste-
ma. Aqui, as Organizações categorizam o Sistema e as Informações processadas, 
armazenadas e transmitidas por esse Sistema com base numa análise de impacto.
As diretrizes de categorização de segurança para Sistemas de Segurança não nacio-
nais podem ser encontradas no FIPS 199 e no NIST SP 800-60.7;
• Selecionar: a segunda etapa do processo de RMF envolve a seleção de um conjunto 
inicial de controles de segurança de linha de base para o Sistema, com base na cate-
gorização de segurança, além de adaptar e complementar a linha de base de controle 
de segurança conforme necessário numa avaliação organizacional de risco e local;
16
17
• Implementar: na terceira etapa, a Organização é responsável por implementar 
controles de segurança e descrever como os controles são empregados no Sistema 
e em seu ambiente de operação. Muitas publicações do NIST fornecem informa-
ções sobre implementações de controle de segurança e estão disponíveis para refe-
rência no site do Centro de Recursos de Segurança de Computadores;
• Avaliar: a quarta etapa garante que a Organização avalie os controles de segurança 
usando procedimentos de avaliação apropriados e determine até que ponto os contro-
les são implementados corretamente, operando conforme o esperado e produzindo o 
resultado desejado com relação ao atendimento dos requisitos de segurança do Siste-
ma. O NIST fornece diretrizes para o desenvolvimento de métodos e procedimentos 
de avaliação para determinar a eficácia do controle de segurança em sistemas federais 
e para relatar descobertas de avaliação no Relatório de Avaliação de Segurança;
• Autorizar: na quinta etapa, um gerente sênior autoriza oficialmente um Sistema a 
operar ou continuar a operar com base nos resultados de uma avaliação completa 
do controle de segurança. Essa decisão é baseada na determinação do risco para 
operações e ativos organizacionais, indivíduos, outras Organizações e a Nação re-
sultante da operação do sistema e a decisão de que esse risco é aceitável;
• Monitorar: a sexta etapa do RMF é monitorar continuamente os controles de seguran-
ça no Sistema para garantir que eles sejam eficazes ao longo do tempo, conforme ocor-
rem mudanças no sistema e no ambiente em que o sistema opera. As Organizações 
monitoram os controles de segurança do Sistema continuamente, inclusive avaliando 
a eficácia do controle, documentando mudanças no sistema ou em seu ambiente de 
operação, realizando análises de impacto de segurança das mudanças associadas e 
relatando o estado de segurança do sistema a autoridades organizacionais designadas.
Categorize
System
Select
Controls
Implement
Controls
Assess
Controls
Authorize
System
Monitor
Controls
Organization-wide
Risk Management
SP 800-39
Starting Point
SP 800-37
SP 800-53A
Mu
lti
ple
 NI
ST
 Pu
bli
ca
tio
ns
*
*e
.g.
, S
P 8
00
-34
, S
P 8
00
-61
, S
P 8
00
-12
8
SP
 80
0-1
37
 /
SP
 80
0-3
7 /
 SP
 80
0-5
3 A
FIPS 200 / SP 800-53
FIPS 199 / SP 800-60
Figura 1 – Framework de Gerenciamento de Riscos
17
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
Identificação de Riscos
A importância do Gerenciamento de Riscos já foi absorvida pelo Mercado e al-
gumas das provas desse sucesso estão descritas nas metodologias que já se consoli-
daram, uma das mais conhecidas, certamente, é a PMBoK ou Project Management 
Body of Knowledge ou, em português, Guia do Conjunto de Conhecimentos em Ge-
renciamento de Projetos, que prevê Disciplinas como, por exemplo, gerenciamento de 
custos, de aquisições, de prazo, de qualidade, de recursos humanos, de comunicação, 
de escopo e de gerenciamento de riscos (NIELES, 2017).
As incertezas caracterizadas num projeto, geralmente, estão relacionadas a restri-
ções, requisitos, premissas ou condições adversas que podem criar efeitos negativos 
para o planejamento e para a implementação das ações num projeto.
Então, o fato de saber identificar e analisar os riscos está relacionada diretamente à 
expertise de se conseguir observar onde podem estar os possíveis focos de problemas. 
Esses problemas ou fontes de dificuldades podem ser internas (processos mal estrutura-
dos, monitoramento ineficiente e falta de patrocínio ou compromisso das partes envolvi-
das) ou externas (Mercado, Política Financeira e realidade econômica) e sua análise pode 
ser qualitativa e quantitativa, como segue:
• A Análise de Riscos Qualitativa prioriza os riscos, para que seja dado um 
tratamento mais especial, para um acompanhamento mais próximo aos riscos 
mais significativos;
• A Análise de Riscos Quantitativa demonstra o impacto dos riscos em termos de 
custos e de tempo para execução das atividades e pode fornecer números e pro-
jeções estatísticassobre dias, horas, valores e outros resultados diretos de riscos.
Para que possamos fazer uma boa identificação dos riscos de um projeto, seguem os 
itens que podem nos ajudar: 
• Conhecer o histórico: todo projeto gera ensinamentos, quando indicamos a meto-
dologia do PMBoK, por exemplo, ou realizando um projeto de forma desorientada, 
no final, é gerado todo um cronograma existente e ou uma documentação das 
lições aprendidas. A revisão dessa lista de problemas ocorridos e aprendidos em 
situações anteriores é enriquecedora porque sugere sempre possíveis fragilidades 
que podem ocorrer mais uma vez;
• Rever a Documentação de Abertura do Projeto: é padrão no Gerenciamento 
de Projetos, pois declara escopo e estrutura de cada novo projeto que está sendo 
aberto. Verificar essa formalização das tarefas que devem ser executadas para que 
os objetivos sejam alcançados pode trazer insights e chamar a atenção para algum 
ponto que possui alguma fragilidade;
• Analisar Causas e Efeitos: quando se olha para as causas dos eventuais proble-
mas e do possível impacto produzido, devemos ter um caminho para identificar os 
riscos e também as oportunidades para o mitigar. Identificando os eventos de risco 
18
19
para subsidiar as análises de agrupamentos e estabelecer possíveis ações para pre-
venir e corrigir as eventuais ocorrências indesejadas;
• Ouvir os Interessados: na interpretação de Gestão de Projetos, os stakeholders, 
que significa todas as pessoas envolvidas e interessadas no projeto, devem ser ouvi-
dos, de certa forma, pois participam do projeto de maneira intensa, fazendo parte 
dele e, certamente, terão contribuições sobre identificação de eventuais riscos e 
até mesmo de como possivelmente corrigi-los. Essa ampliação a discussão com as 
equipes é, geralmente, oportuna e produtiva;
• Gerenciar Colaborativamente: embora as metodologias de Gerenciamento de 
Projetos definam as responsabilidades segregadas entre as disciplinas que, junta-
mente, conduzem e materializam um eventual projeto, suas atividades são funda-
mentais. As equipes participantes, certamente, conhecem a realidade do negócio e 
do projeto e, por esse motivo, têm impressões sobre o modelo de gestão e sobre a 
estrutura do projeto, lidando diretamente com os recursos disponibilizados por ele;
• Realizar Gestão de Riscos: a gestão de riscos é um processo já conhecido e conso-
lidado no meio empresarial, industrial e público, legitimado pela ISO 31000:2009, 
e que contempla alguns subprocessos. É interessante o profissional conhecer essas 
regras e etapas para ter uma direção de como fazê-lo mais assertivamente;
• Estabelecimento de Contexto: nessa fase inicial, pode-se classificar os riscos 
quanto à sua origem (internos ou externos). No ambiente interno, tem-se: estru-
tura hierárquica, governança, responsabilidades, estratégias corporativas, proces-
sos, cultura organizacional, recursos, sistemas e dados do negócio e conhecimento 
instalado. Já o ambiente externo contempla os contextos social, político, cultural, 
legal, mercadológico, tecnológico e econômico;
• Identificação de Riscos: nesta etapa, produz-se uma lista de riscos e ameaças 
relacionadas aos possíveis eventos indesejáveis num eventual projeto, sendo que 
após essa identificação será possível visualizar os fatores que reduzem, aumentam, 
agilizam ou atrasam a realização dos objetivos a serem alcançados num projeto;
• Análise dos Riscos: essa etapa define o estudo das causas dos eventuais riscos 
e de suas consequências sobre um determinado projeto em questão. Além disso, 
podem avaliar as chances de reincidência e os efeitos produzidos em caso de novas 
ocorrências e problemas;
• Avaliação dos Riscos: nesta etapa, ocorre a segregação dos riscos conforme o 
nível do impacto produzido. Essa avaliação pode ser considerada alta, média ou bai-
xa. Também há outras formas de classificação que consideram os seguintes níveis: 
extremo, elevado ou moderado;
• Tratamento dos Riscos: como o nome indica, nesta etapa, os riscos podem ser 
tratados e o planejamento colocado em prática. Tratar os riscos nada mais é do 
que modificar a situação atual para que o cenário corporativo não fique vulnerável 
ao problema identificado. Esse caso é definido por um plano de ação com o intuito 
de mitigar riscos negativos (eliminá-los ou reduzi-los em relação as suas chances de 
19
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
ocorrência) e maximizar os riscos positivos (aumentando, então, a sua probabilida-
de de captura crescente de valor);
• Disseminação da Gestão de Riscos: na metodologia PMBoK, é contemplada a 
disciplina relacionada à comunicação e propaganda. Suas características também 
devem ser aplicadas no contexto da Gestão de Riscos, pois deverá haver transpa-
rência na propagação de informações e diálogo aberto entre as partes interessadas 
e participantes do projeto;
• Monitoramento Permanente: deve-se verificar, observar, supervisionar e identifi-
car as oportunidades de melhoria de uma forma cíclica e sem intervalos. Analisar 
criticamente o que está sendo realizado na Gestão de Riscos é premissa importante 
para o sucesso dessa atividade. Essa fase deve perdurar do início ao fim do ciclo de 
vida do projeto.
Perspectiva inovadora na Gestão de Riscos em TI.
Disponível em: https://youtu.be/W7Vph0LGrVY.
Erros da Gestão de Riscos do Projeto
A fim de facilitar o desenvolvimento da Gestão de Riscos num Projeto, indico aqui 
alguns erros mais comuns e que precisam ser evitados para um bom andamento nos 
trabalhos a respeito desse tema.
São eles (9 erros):
1. Ignorar lições aprendidas;
2. Prender-se às lições aprendidas;
3. Confundir Gestão de Riscos com Auditoria;
4. Escolher métodos inadequados;
5. Considerar tudo como risco;
6. Considerar Projetos de TI como diferentes dos Projetos Empresariais;
7. Atuar apenas na fase de planejamento;
8. Limitar a gestão de riscos a determinados atores;
9. Deixar a gestão de riscos alheia à dinâmica corporativa.
20
21
Material Complementar
Indicações para saber mais sobre os assuntos abordados nesta Unidade:
 Livros
Fundamentos do Gerenciamento de Serviços de TI
FREITAS, M. A. S. Fundamentos do Gerenciamento de Serviços de TI. 2.ed. São 
Paulo: Brasport, 2018;
Governança de Segurança da Informação
MANOEL, S. Governança de Segurança da Informação. São Paulo: Brasport, 2014;
Fundamentos de Segurança da Informação com Base na ISO 27001 e na ISO 27002
BAARS, H.; HINTZBERGEN, J., HINTZBERGEN, k., SMULDERS, A. Fundamentos 
de Segurança da Informação com Base na ISO 27001 e na ISO 27002, 3ed, São 
Paulo, Pearson, 2018.
CCNP Routing and Switching Official Cert Library
KEVIN, W.; LACOSTE, R.; HUCABY, D. CCNP Routing and Switching Official Cert 
Library. Indianapolis: Cisco Press, 2015.
21
UNIDADE 
Categorização de Incidentes e Avaliação de Riscos
Referências
FERNANDES, A. A.; ABREU, V. F., Implantando a Governança de TI. 4.ed. São 
Paulo: Brasport, 2018.
MILAR, T. et al. NIST – Computer Security Incident Handling Guide – Revision 2. 
EUA: NIST, 2012.
NIELES, M; DEMPSEY, K; PILLITERI, V. NIST – An Introduction to Information 
Security – Revision 1. EUA: NIST, 2017.
OLIVEIRA, B. S. Métodos Ágeis e Gestão de Serviços de TI. São Paulo: Brasport, 2018.
OLIVEIRA, F. B. Tecnologia da Informação e Comunicação. São Paulo: Pearson, 2012.
22