Gestão de riscos em TI

Prévia do material em texto

<p>GESTÃO DE RISCOS EM TI</p><p>W</p><p>B</p><p>A</p><p>04</p><p>53</p><p>_v</p><p>1.</p><p>0</p><p>2</p><p>Márcio dos Santos</p><p>Londrina</p><p>Editora e Distribuidora Educacional S.A.</p><p>2020</p><p>GESTÃO DE RISCOS EM TI</p><p>1ª edição</p><p>3</p><p>2020</p><p>Editora e Distribuidora Educacional S.A.</p><p>Avenida Paris, 675 – Parque Residencial João Piza</p><p>CEP: 86041-100 — Londrina — PR</p><p>e-mail: editora.educacional@kroton.com.br</p><p>Homepage: http://www.kroton.com.br/</p><p>Presidente</p><p>Rodrigo Galindo</p><p>Vice-Presidente de Pós-Graduação e Educação Continuada</p><p>Paulo de Tarso Pires de Moraes</p><p>Conselho Acadêmico</p><p>Carlos Roberto Pagani Junior</p><p>Camila Braga de Oliveira Higa</p><p>Carolina Yaly</p><p>Giani Vendramel de Oliveira</p><p>Henrique Salustiano Silva</p><p>Juliana Caramigo Gennarini</p><p>Mariana Gerardi Mello</p><p>Nirse Ruscheinsky Breternitz</p><p>Priscila Pereira Silva</p><p>Tayra Carolina Nascimento Aleixo</p><p>Coordenador</p><p>Henrique Salustiano Silva</p><p>Revisor</p><p>Cecilia Sosa Arias Peixoto</p><p>Editorial</p><p>Alessandra Cristina Fahl</p><p>Beatriz Meloni Montefusco</p><p>Gilvânia Honório dos Santos</p><p>Mariana de Campos Barroso</p><p>Paola Andressa Machado Leal</p><p>Dados Internacionais de Catalogação na Publicação (CIP)</p><p>______________________________________________________________________________________</p><p>Santos, Márcio dos.</p><p>S237g Gestão de Riscos em TI/ Márcio dos Santos. – Londrina:</p><p>Editora e Distribuidora Educacional S.A., 2020.</p><p>44 p.</p><p>ISBN 978-65-87806-20-4</p><p>1. Gestão 2. Riscos 3. TI. I. Título.</p><p>CDD 004</p><p>____________________________________________________________________________________________</p><p>Raquel Torres – CRB 6/2786</p><p>© 2020 por Editora e Distribuidora Educacional S.A.</p><p>Todos os direitos reservados. Nenhuma parte desta publicação poderá ser</p><p>reproduzida ou transmitida de qualquer modo ou por qualquer outro meio,</p><p>eletrônico ou mecânico, incluindo fotocópia, gravação ou qualquer outro tipo de</p><p>sistema de armazenamento e transmissão de informação, sem prévia autorização,</p><p>por escrito, da Editora e Distribuidora Educacional S.A.</p><p>4</p><p>SUMÁRIO</p><p>Introdução à Gestão de Riscos ______________________________________ 05</p><p>Contexto e Identificação de riscos __________________________________ 18</p><p>Análise e Avaliação de riscos _______________________________________ 32</p><p>Tratamento, aceitação e monitoramento dos riscos_________________ 47</p><p>GESTÃO DE RISCOS EM TI</p><p>5</p><p>Introdução à Gestão de Riscos</p><p>Autoria: Márcio dos Santos</p><p>Leitura crítica: Cecilia Sosa Arias Peixoto</p><p>Objetivos</p><p>• Compreender o papel da Tecnologia da Informação</p><p>(TI) em uma organização, bem como sua importância</p><p>em um cenário de tomada de decisões.</p><p>• Conhecer o papel da governança de TI nos processos</p><p>de gestão de riscos dentro de uma organização.</p><p>• Identificar o que são riscos em TI e seus impactos</p><p>organizacionais em caso de não tratamento.</p><p>• Identificar a importância da informação em</p><p>organizações.</p><p>• Compreender a diferença entre dados, informação e</p><p>conhecimento gerado para tomada de decisões.</p><p>6</p><p>1. O papel da TI dentro de uma organização</p><p>A Tecnologia da Informação (TI), atualmente, já não pode ser</p><p>considerada apenas um departamento auxiliar que presta serviços</p><p>pontuais em momentos de falha de sistema ou problemas de hardware.</p><p>Com o fluxo de dados, o crescimento massivo da informação e a busca</p><p>constante pelo conhecimento gerado a partir dessas informações, a TI</p><p>se apresenta como forte aliada das organizações que enxergam seu</p><p>potencial, a fim de alcançar maior competitividade no mercado.</p><p>Cabe, portanto, a TI, o papel fundamental de prover ferramentas,</p><p>recursos e disponibilidade de infraestrutura, escalabilidade e rápida</p><p>resolução de incidentes à organização na qual está vinculada, segundo</p><p>Fernandes (2014).</p><p>2. Governança de TI</p><p>Com o objetivo de trazer uma representação mais efetiva dentro de uma</p><p>organização, gerando processos mais eficientes, surge no contexto da</p><p>alta gestão (composta por diretores e executivos, além de integrantes da</p><p>área de computação), a governança de TI.</p><p>Na prática, a governança de TI resume-se a uma ramificação da</p><p>organização (e dentro da própria organização) que assume mais um</p><p>papel conceitual, simbólico, porém, extremamente atuante quanto</p><p>aos processos e procedimentos adotados para tomada de decisões</p><p>importantes concernentes aos procedimentos de TI. Isso significa que</p><p>você não encontrará dentro de uma empresa uma placa presa em</p><p>alguma porta, informando que ali é o setor da governança de TI.</p><p>7</p><p>A governança de TI funciona como um conselho deliberativo de</p><p>determinado órgão. É formado por pessoas com conhecimentos</p><p>diversos em várias áreas para que as deliberações adotadas sejam</p><p>embasadas em pontos de vistas diversos e não apenas na visão de um</p><p>diretor ou presidente. Ainda na linha do conselho deliberativo , é mais</p><p>conceitual e não existe, em uma associação, por exemplo, uma placa</p><p>informativa com os dizeres: “Aqui é a sala do Conselho”.</p><p>Esse status de conselho que pode ser atribuído à governança de TI,</p><p>colocou a Tecnologia da Informação em outro patamar, deixou seu</p><p>posto secundário e de baixa relevância e passou a ter um status de</p><p>maior valorização dentro do negócio, servindo como mecanismo de</p><p>suporte à organização, guiando esta, na realização de planos, metas e</p><p>estratégias (ABNT, 2009 apud FERNANDES, 2014).</p><p>É importante que você compreenda que a governança de TI não prega</p><p>de forma meramente orientativa os padrões a serem seguidos, assim</p><p>como um framework ou bibliotecas de boas práticas (Cobit, ITIL, CMMI e</p><p>outras). De acordo com Fernandes (2014), a governança de TI prega um</p><p>alinhamento direto entre o departamento de Tecnologia da Informação</p><p>e a visão da organização. Isso inclui tratamento de falhas, gestão da</p><p>continuidade do negócio e minimização dos impactos aos riscos.</p><p>Todavia, essas definições da governança de TI são apenas norteadoras,</p><p>ou seja, espera-se que a organização assuma e implante o conceito</p><p>definido como ciclo de governança de TI, composto basicamente de</p><p>quatro etapas sequenciais:</p><p>1. Alinhamento estratégico e compliance.</p><p>2. Decisão, compromisso, priorização e alocação de recursos.</p><p>3. Estrutura, processos, operações e gestão.</p><p>4. Gestão do valor e do desempenho.</p><p>8</p><p>Confira a estrutura sequencial na Figura 1 a seguir:</p><p>Figura 1 – Ciclo da governança de TI</p><p>Fonte: Fernandes (2014, p. 14).</p><p>2.1 Riscos</p><p>Nas palavras de Cabral e Caprino (2015, p. 38), risco é definido como a</p><p>“probabilidade e potencial magnitude de uma perda futura”, ou seja, é a</p><p>chance de um evento considerado negativo ocorrer no futuro.</p><p>Esse leque de eventos negativos, no âmbito da Tecnologia da</p><p>Informação, é muito amplo e pode ser originado a partir de diversas</p><p>fontes, como falhas de hardware, software, ativos internos, eventos</p><p>e catástrofes. Geralmente, a quebra de alguns princípios acarreta no</p><p>aumento da probabilidade de ocorrência do risco e este aumento pode</p><p>ocasionar um erro, falha ou quebra de confiabilidade.</p><p>Esses princípios nos reportam aos conceitos básicos de segurança da</p><p>informação, que, conforme nos aponta Barreto et al. (2018), podem ser</p><p>agrupados nas seguintes categorias: confidencialidade, autenticidade,</p><p>disponibilidade, e integridade.</p><p>2.1.1. Confidencialidade</p><p>Algo confidencial tem acesso restrito a um grupo específico de pessoas.</p><p>Logo, a confidencialidade está diretamente ligada à restrição de acesso,</p><p>seja por meio físico ou virtual. Determinadas seções de uma organização</p><p>9</p><p>só permitem entrada de membros de escalões específicos para zelar</p><p>pela confidencialidade dos dados e informações que trafegam naquele</p><p>ambiente.</p><p>Adicionalmente, determinadas áreas de um sistema informatizado</p><p>também podem possuir limitação de acesso mediante usuário e senha,</p><p>restringindo, assim, o acesso apenas àqueles que têm permissão para</p><p>tal.</p><p>Essa limitação de acesso não se restringe apenas a indivíduos, mas</p><p>também a dispositivos virtuais e máquinas, segundo Barreto et al. (2018),</p><p>por exemplo, uma Application Programming Interface (API), rotina de</p><p>programação utilizada para acessar recursos em aplicações externas,</p><p>que consome dados via webservice.</p><p>2.1.2. Autenticidade</p><p>A autenticidade, como</p><p>de um ano:</p><p>ALE = SLE x LF</p><p>Para que este cálculo seja de fato aplicável e eficiente, considera-</p><p>se que é possível mensurar os impactos financeiros causados pela</p><p>concretização de uma ameaça. Vamos utilizar um exemplo aplicado</p><p>por Cabral e Caprino (2015), para uma organização que tenha 10% de</p><p>chance de um de seus principais sistemas sofrer paralização por mais de</p><p>uma hora, trazendo prejuízo de $100.000,00. Nesse contexto, o cálculo</p><p>da expectativa anual de perda seria:</p><p>ALE = 100.000 x 0.1 = $10.000,00</p><p>Os controles podem se basear na norma ISO 27002 ou ainda serem</p><p>definidos de acordo com a própria organização (vale lembrar que</p><p>esta família de normas ISO apenas guiam o gestor de TI e time de</p><p>Governança de TI quando às práticas que podem ser adotadas, não</p><p>sendo mandatórias em suas implementações).</p><p>A aplicação dos controles pode ser em vários segmentos:</p><p>• Acesso físico: esse é o mais básico tipo de controle que pode</p><p>existir. Consiste em não permitir acesso físico de pessoas não</p><p>autorizadas a determinados locais da organização, como sala dos</p><p>servidores, departamento de TI, datacenter (caso seja aplicável) etc.</p><p>Os meios de se manter este controle com limitações podem ser</p><p>diversos, desde aqueles mais singulares, como manter uma porta</p><p>fechada com um aviso de acesso restrito (não muito funcional), até</p><p>métodos mais eficientes e sofisticados como leitura de digital ou</p><p>retina.</p><p>60</p><p>• Acesso virtual: a restrição de acesso virtual se refere,</p><p>basicamente, às redes de comunicação internas nas quais apenas</p><p>o pessoal autorizado pode ter livre tráfego. Não faria muito sentido</p><p>um usuário convencional ter acesso ao servidor de dados por meio</p><p>do ambiente de rede de seu terminal.</p><p>• Acesso de usuário: cada usuário também deve ter seu nível de</p><p>acesso pré-definido e com as restrições apontadas, de forma</p><p>que tenha visibilidade apenas dos recursos computacionais</p><p>e informáticos que forem inerentes à sua atuação dentro da</p><p>organização.</p><p>O tema gestão de riscos em TI é algo extremamente amplo e requer um</p><p>aprofundamento muito minucioso, principalmente, pelo fato de existir</p><p>um grande leque de bibliografia de sustentação atrelada, como o guia</p><p>PMBOK, Cobit, biblioteca ITIL, normas ISO das famílias 27000 e 31000,</p><p>além dos diversos autores que abordam de maneira bastante eficiente o</p><p>assunto.</p><p>Dessa forma, uma sugestão para você, que se interessou pelo tema e</p><p>quer conhecer um pouco mais a respeito dos processos que envolvem</p><p>a gestão de riscos em TI, é iniciar pelos estudos desses instrumentos</p><p>de base, agregando sempre bibliografias complementares que trarão</p><p>exemplos e aplicações práticas dos conteúdos abordados.</p><p>Referências Bibliográficas</p><p>CABRAL, Carlos; CAPRINO, Willian. Trilhas em Segurança da Informação:</p><p>caminhos e ideias para a proteção de dados. Rio de Janeiro, RJ: Brasport, 2015.</p><p>HINTZBERGEN, Jule et al. Fundamentos de segurança da informação: com base</p><p>na ISSO 27001 e na ISSO 27002. Rio de Janeiro, RJ: Brasport, 2018.</p><p>61</p><p>Bons estudos!</p><p>o próprio nome diz, tem por objetivo aferir se</p><p>determinada informação provém, de fato, do remetente que alega estar</p><p>emitindo, bem como se a informação permaneceu fidedigna durante o</p><p>trajeto.</p><p>Essa aferição de autenticidade pode ser vista amplamente nos meios</p><p>digitais da atualidade, que aferem o emissor de uma informação por</p><p>meio de certificados digitais. Outros mecanismos, como assinatura</p><p>digital, também se encaixam no perfil de regra de autenticidade.</p><p>2.1.3. Disponibilidade</p><p>Talvez este seja o item que mais ocasione os erros nos departamentos</p><p>de TI, pois está diretamente ligado aos dispositivos de hardware</p><p>(embora também existam falhas de disponibilidade ocasionadas por</p><p>software em decorrência de má configuração, mau desenvolvimento,</p><p>10</p><p>vulnerabilidades ou overflow – este último, sendo uma junção de falhas</p><p>entre hardware e software). Falhas de disponibilidade ocorrem quando</p><p>determinado recurso deixa de funcionar por algum motivo, por exemplo,</p><p>por uma queda de energia, pela falta de Internet, por falhas na rede de</p><p>computadores, e pelo overflow de usuários no sistema causando queda</p><p>do servidor.</p><p>Outros cenários já são mais triviais e estão relacionados diretamente</p><p>ao hardware dos dispositivos informáticos e infraestrutura, como um</p><p>mau funcionamento de placa de memória ou rompimento de cabos, por</p><p>exemplo. Pode-se dizer que, se um serviço estava funcionando e, por</p><p>algum motivo não intencional, deixou de funcionar, ocorreu, então, falha</p><p>de disponibilidade.</p><p>2.1.4. Integridade</p><p>A integridade acaba complementando o item autenticidade, pois seu</p><p>objetivo é aferir se um determinado dado ou informação chegou ao</p><p>destinatário exatamente da forma como foi emitido pelo remetente,</p><p>sem sofrer qualquer tipo de modificação no percurso.</p><p>Essa prática evita que uma técnica de invasão amplamente utilizada e</p><p>conhecida como Man in the middle (homem no meio)-, por exemplo, seja</p><p>aplicada. Nesse tipo de ataque, o invasor intercepta o tráfego de dados</p><p>entre o emissor e seu receptor, podendo sequestrar, redirecionar ou</p><p>modificar os dados trafegados, conforme demonstrado na Figura 2:</p><p>11</p><p>Figura 2 – Invasão do tipo Man in the middle</p><p>Fonte: elaborado pelo autor.</p><p>Alguns erros podem ser recorrentes dentro de uma estrutura</p><p>organizacional e essa recorrência auxiliará na descoberta de gargalos</p><p>para elaboração de planos de contingência e gestão de riscos de TI.</p><p>2.2. Gestão de riscos</p><p>Agora que você já compreendeu a importância da TI dentro de</p><p>uma organização, aprendeu sobre governança de TI e seu papel</p><p>gerencial e conheceu as categorias falhas/erros que podem afetar</p><p>sistemas de tecnologia da informação, vamos tratar sobre a gestão</p><p>de riscos propriamente e as recomendações de tratativas desta</p><p>gestão, considerando cenários diversos. Adicionalmente, você poderá</p><p>compreender a importância de manter a segurança da informação.</p><p>2.2.1. O valor da informação</p><p>Para entender o valor da informação, precisamos antes de tudo</p><p>compreender seu conceito. De acordo com Barreto (2018, p. 21),</p><p>“informações são o resultado dos dados já tratados e organizados de</p><p>uma forma lógica”. Dados, por sua vez, são tidos como fatos brutos que</p><p>ainda não receberam tratamento.</p><p>12</p><p>Pode-se afirmar, então, que dados são partículas de uma informação e a</p><p>informação é o conjunto de dados previamente tratados. A informação,</p><p>por sua vez, gera o conhecimento e o conhecimento é utilizado para</p><p>tomada de decisão.</p><p>Essa sequência lógica está presente em absolutamente tudo o que</p><p>existe, seja em um cenário tecnológico ou no preparo de uma xícara de</p><p>café. Sempre existirão dados, informação e conhecimento atrelados,</p><p>nesta ordem. A Figura 3 exemplifica este cenário:</p><p>Figura 3 – Exemplo de dados, informação e conhecimento</p><p>Fonte: elaborado pelo autor.</p><p>Observe que as informações são os elementos por meio dos quais o</p><p>conhecimento é gerado para, então, tomar-se uma decisão. Logo, a</p><p>informação protegida representa poder de competitividade.</p><p>Nas palavras de Barreto (2018), as empresas podem utilizar</p><p>determinadas informações para conquistar ou fidelizar clientes, além de</p><p>construir perfis de clientes por meio de análise de dados.</p><p>Vale ressaltar, todavia, que a tomada de decisão, salvo cenários de</p><p>Inteligência Artificial com redes neurais amplamente treinadas, são</p><p>realizadas com base no conhecimento pessoal de seus colaboradores,</p><p>13</p><p>utilizando também outras informações pré-existentes na organização,</p><p>segundo Barreto (2018).</p><p>2.2.2. Aplicação da gestão de riscos</p><p>Corroborando a definição de Cabral e Caprino (2015), Hintzbergen et al.</p><p>(2018, p. 24) define o conceito básico de risco como “efeito da incerteza</p><p>sobre os objetivos. É a combinação da probabilidade de um evento e sua</p><p>consequência. Um efeito é um desvio do que é esperado, o qual pode</p><p>ser positivo e/ou negativo”.</p><p>Expandindo o conceito e aplicando-o a um cenário genérico de sistema</p><p>de informação, Cabral e Caprino (2015), descrevem a gestão de risco</p><p>como sendo:</p><p>O objetivo máximo da segurança da informação (SI). Apesar de parecer</p><p>uma afirmação presunçosa, devemos analisar os motivos pelos quais</p><p>trabalhamos para preservar a segurança das informações. Veremos que</p><p>tudo se resume à gestão de risco. Aplicamos medidas de segurança para</p><p>evitar perdas, sejam elas relacionadas à confidencialidade, integridade</p><p>ou disponibilidade (a tríade clássica da segurança da informação). Como</p><p>são eventos futuros, é necessário entender a chance e a dimensão de tais</p><p>perdas. Em outras palavras, o risco. (CABRAL; CAPRINO, 2015, p. 38,)</p><p>Um dos primeiros requisitos na tratativa dos riscos é conhecê-los e</p><p>categorizá-los. É importante ressaltar que esta concepção prévia é uma</p><p>estimativa do que pode ocorrer, pois como já foi citado anteriormente,</p><p>risco é a probabilidade de ocorrência futura.</p><p>Conhecendo o cenário de riscos ,ao qual a organização está exposta, é</p><p>possível preparar, organizar e priorizar ações a serem realizadas para</p><p>minimizar os impactos gerados.</p><p>Esse processo de conhecimento de cenário é definido por Hintzbergen</p><p>et al. (2018, p. 21) como análise de riscos, que consiste em “compreender</p><p>14</p><p>a natureza do risco a fim de determinar o seu nível”. Por meio dessa</p><p>análise é possível gerar uma base para estimar a magnitude do risco,</p><p>bem como gerar decisões para seu tratamento, logo, o processo de a</p><p>análise de riscos deve incluir a estimativa do risco, segundo Hintzbergen</p><p>et al. (2018).</p><p>Entretanto, atente-se a este ponto: a gestão de riscos não evitará,</p><p>propriamente, que algo negativo ocorra, mas minimizará ao máximo os</p><p>impactos gerados na organização quando a previsão se tornar realidade.</p><p>Dessa forma, a gestão de riscos aplicará técnicas para manter o risco</p><p>ao qual a informação está sujeita em níveis aceitáveis e adequados,</p><p>segundo Cabral e Caprino (2015), ou seja, com impactos mínimos ou até</p><p>mesmo inexistentes.</p><p>Cabral e Caprino (2015) complementam que a eliminação do risco</p><p>não é algo desejável, pois se uma informação não está sujeita a riscos,</p><p>então não tem valor à organização. E se não tem valor, não faz sentido</p><p>de existir. Assim, entende-se que o risco é necessário para que uma</p><p>informação possa ter seu valor agregado.</p><p>2.3. Fases da gestão do processo de riscos</p><p>A gestão de riscos em TI, que é um processo cíclico e contínuo, segundo</p><p>Cabral e Caprino (2015), que percorre algumas fases padrão:</p><p>• Análise de riscos.</p><p>• Definição de riscos.</p><p>• Aplicação de controles.</p><p>15</p><p>Outras fases podem ser desenvolvidas e são até mesmo apontadas</p><p>por algumas bibliografias específicas. Todavia, as fases que embasam o</p><p>processo de gestão de riscos podem se resumir a essas três citadas.</p><p>O processo para mitigar o risco inicia-se sempre com uma análise</p><p>do cenário, bem como pela tolerância aceita pelas partes envolvidas:</p><p>alta gestão, departamento de TI, corpo executivo etc. Observe que,</p><p>novamente, envolvemos vários departamentos neste processo, o que</p><p>reforça a importância da governança de TI para uma correta e eficiente</p><p>aplicação da gestão de riscos.</p><p>Cada departamento</p><p>representado na governança de TI apontará</p><p>os níveis de tolerância que estão dispostos a aceitar, seguindo seus</p><p>próprios critérios. Essa análise inicial apontará o investimento necessário</p><p>para minimizar os impactos do risco. Compreenda que, nem sempre,</p><p>o termo investimento deve ser interpretado como injeção de recurso</p><p>financeiro. O investimento pode representar prazo, recursos humanos,</p><p>conhecimento etc.</p><p>Diminuir os impactos dos riscos deve sempre ser o objetivo primordial</p><p>de qualquer guia de gestão de riscos, e, por consequência, deve ser o</p><p>mantra da governança de TI. Hintzbergen et al. (2018) demonstra que</p><p>ações simples, previamente estruturadas e empregadas pela governança</p><p>de TI, podem minimizar os impactos dos riscos e, quando esses</p><p>ocorrerem, serão em menor escala e com menor potencial:</p><p>Uma contramedida é posta em prática para mitigar o risco em potencial.</p><p>Ela pode ser uma configuração de software, um dispositivo de hardware ou</p><p>um procedimento que elimine a vulnerabilidade ou reduza a probabilidade</p><p>de um agente ameaçador ser capaz de explorar a vulnerabilidade.</p><p>Exemplos de contramedidas incluem a gestão de senhas fortes, um</p><p>guarda de segurança, mecanismos de controle de acesso em sistemas</p><p>operacionais, a implementação de senhas do basic input/output system</p><p>(BIOS) e treinamento de conscientização sobre segurança. (HINTZBERGEN,</p><p>2018, p. 35)</p><p>16</p><p>Como elemento auxiliar, considerando que o risco prevê o cenário</p><p>negativo como inevitável, elaborar um mapa de riscos pode ser uma boa</p><p>alternativa para estimar os riscos e priorizá-los. Analise o exemplo de</p><p>mapa de risco disposto na Figura 4:</p><p>Figura 4 – Exemplo de mapa de riscos</p><p>Fonte: Fernandes (2014, p. 208).</p><p>Nota-se que, neste exemplo de mapa de riscos, uma linha de processos</p><p>sequenciais foi elencada, cada qual recebendo um tipo de falha/erro</p><p>possível de ocorrer, bem como as ações a serem tomadas mediante</p><p>tal ocorrência, com o objetivo de facilitar a tomada de decisão em um</p><p>cenário em que o risco se fizer vigente.</p><p>17</p><p>Vimos, nesta unidade, os princípios básicos que norteiam a gestão de</p><p>riscos de TI em uma organização, bem como as diretivas que podem ser</p><p>adotadas pela governança de TI quando implantada.</p><p>Todo esse processo está focado em tornar seguros os dados e as</p><p>informações da organização, considerando que vivemos na era da</p><p>informação e o conhecimento é mais valoroso que o próprio dinheiro</p><p>em si.</p><p>Referências Bibliográficas</p><p>BARRETO, Jeanine dos Santos et al. Fundamentos de segurança da informação.</p><p>Porto Alegre, RS: SAGAH, 2018.</p><p>CABRAL, Carlos; CAPRINO, Willian. Trilhas em Segurança da Informação:</p><p>Rio de Janeiro, RJ: Brasport, 2015.</p><p>FERNANDES, Aguinaldo Aragon. Implantando a governança de TI: da estratégia à</p><p>gestão dos processos e serviços. 4. ed. Rio de Janeiro, RJ: Brasport, 2014.</p><p>HINTZBERGEN, Jule et al. Fundamentos de segurança da informação: com base</p><p>na ISSO 27001 e na ISSO 27002. Rio de Janeiro, RJ: Brasport, 2018.</p><p>18</p><p>Contexto e Identificação de riscos</p><p>Autoria: Márcio dos Santos</p><p>Leitura crítica: Cecilia Sosa Arias Peixoto</p><p>Objetivos</p><p>• Identificar cenários de riscos em TI.</p><p>• Contextualizar e mapear os riscos.</p><p>• Identificar as causas, fontes e consequências</p><p>positivas/ negativas de um risco.</p><p>• Conhecer as normas ISO relacionadas à gestão de</p><p>riscos.</p><p>• Conhecer o guia PMBOK e sua abordagem de</p><p>tratativas de cenários de riscos.</p><p>19</p><p>1. Normas ISO</p><p>Os riscos estão presentes em qualquer organização e devem ser</p><p>tratados como benesses institucionais, uma vez que representam a base</p><p>para mensurar a qualidade, valor e importância de uma informação.</p><p>Embora cada organização tenha suas particularidades quanto ao</p><p>que é considerado risco, existe um norte que pode ser utilizado para</p><p>orientar os profissionais da área de TI quanto aos procedimentos mais</p><p>adequados para lidar com tais cenários. Esses procedimentos são</p><p>descritos por meio de normas. Utilizaremos as normas ISO.</p><p>1.1 Família ISO 27000</p><p>Embora o grande foco da gestão de riscos seja trabalhado pela família</p><p>ISO 31000, é necessário que façamos uma abordagem preliminar</p><p>da família de normas ISO 27000 e 27005, que tratam a respeito de</p><p>segurança, mais especificamente Sistema de Gestão de Segurança da</p><p>Informação (SGSI). Nas palavras de Barreto (2018):</p><p>Cada norma da família ISO 27000 tem uma função específica, mas todas</p><p>visam à criação, à manutenção, à melhoria, à revisão, ao funcionamento</p><p>e à análise de um SGSI. Essas normas podem ser adotadas pelas</p><p>organizações, seja qual for o seu tamanho ou tipo, pois suas diretrizes</p><p>visam a garantir que tanto os sistemas quanto as organizações estejam</p><p>seguros, por meio de estratégias e orientações que fazem com que</p><p>o SGSI se adapte à empresa que deseja fazer a sua implementação</p><p>(INTENATIONAL ORGANIZATION FOR STANDARDIZATION, 2018). As</p><p>diretrizes traçadas pelas ISO 27000 estabelecem o que deve ser feito</p><p>durante todo o processo de implementação de um SGSI e tratam também</p><p>de assuntos mais específicos, como requisitos e orientações que servirão</p><p>para as empresas que vão prestar serviços de certificação ou de auditoria</p><p>em empresas que desejem implementar um SGSI. (BARRETO, 2018, p. 167)</p><p>20</p><p>Essa família ISO é muito extensa e aborda temas básicos, desde</p><p>fundamentos de implementação de SGSI até processos para realização</p><p>de auditoria em Sistemas de Informação.</p><p>Este embasamento, fornecido pela família ISO 27000, ajuda a perceber</p><p>que uma organização está sujeita a diversas ameaças, que podem ser de</p><p>cunho informatizado ou físico.</p><p>Em nível computacional, essa norma trata as ameaças como riscos, que</p><p>abre a possibilidade de exploração de vulnerabilidades organizacionais,</p><p>trazendo impactos negativos. Assim, a norma estabelece a necessidade</p><p>de descrever os riscos de forma qualitativa e quantitativa, analisando-</p><p>os de acordo com a as prioridades inerentes à própria organização,</p><p>segundo Barreto (2018).</p><p>Adicionalmente, a ISO 27002 estabelece um código de prática para a</p><p>segurança da informação que contempla, nas palavras de Hintzbergen</p><p>(2018):</p><p>• Compreender os requisitos de segurança da informação, bem</p><p>como a necessidade de definir procedimentos de segurança da</p><p>informação.</p><p>• Implementar, operar e gerenciar controles de riscos de segurança</p><p>da informação.</p><p>• Monitorar e revisar periodicamente o desempenho do Sistema</p><p>de Gerenciamento de Segurança da Informação para aferir sua</p><p>eficácia.</p><p>• Prover um processo de melhoria contínua com base nas medições</p><p>cíclicas obtidas pelo monitoramento de desempenho.</p><p>21</p><p>1.2 Família ISO 31000</p><p>A ISO 31000 é uma família que tem, em sua estrutura, um leque de</p><p>normas iniciadas por este mesmo número (explicando o motivo de ser</p><p>chamada família 31000). Essa família (que será chamada deste ponto em</p><p>diante apenas de ISO 31000) pode ser utilizada em qualquer empresa,</p><p>independentemente do setor em que atue.</p><p>Barreto (2018) explica que a ISO 31000 é formada pelas seguintes</p><p>normas:</p><p>• ISO 31000, que traz informações, princípios, diretrizes e melhores</p><p>práticas para implantação e manutenção da gestão de riscos em</p><p>uma organização.</p><p>• ISO 31010: apresenta algumas técnicas para avaliação e gestão de</p><p>riscos.</p><p>• ISO Guia 73: funciona como um anexo, trazendo um vocabulário a</p><p>respeito das expressões utilizadas na gestão de riscos.</p><p>É importante que você internalize que essas normas servem de guia, ou</p><p>seja, é por meio delas que a organização na qual você atua deve balizar</p><p>os passos e traçar estratégias. Entretanto, isso não significa que as</p><p>sugestões propostas sejam mandatórias.</p><p>Essa liberdade se deve ao fato de que a família ISO 31000 tem como</p><p>principal objetivo conscientizar as organizações quanto à importância</p><p>da gestão de riscos, segundo Barreto (2018), não tendo o propósito de</p><p>realizar certificação dessas entidades.</p><p>Nas recomendações da família ISO 31000, um processo de gestão de</p><p>riscos deve seguir um organograma conforme disposto na Figura 1:</p><p>22</p><p>Figura 1 – Processo de gestão de riscos</p><p>Fonte: adaptado de Barreto (2018, p. 171).</p><p>O bloco definido como</p><p>comunicação e consulta, na Figura 1, aponta</p><p>a comunicação entre todas as partes interessadas (independente do</p><p>escalão organizacional) e, a cada etapa de evolução no processo de</p><p>mensuração do risco, essa comunicação deve ser estabelecida.</p><p>O estabelecimento de um contexto consiste em definir os critérios e</p><p>os setores envolvidos, bem como abordar papéis e responsabilidades</p><p>distribuídos pela estrutura organizacional da instituição, atentando-</p><p>se para não causar conflito com outras políticas pré-estabelecidas,</p><p>questões legais, financeiras, tecnológicas etc.</p><p>23</p><p>Já o bloco de identificação de riscos é a definição, propriamente dita,</p><p>dos riscos que podem afetar a organização, de maneira positiva ou</p><p>negativa. Essa é, talvez, uma das etapas mais importantes do processo</p><p>de gestão de riscos, pois se algum risco for deixado de fora nesta etapa,</p><p>consequentemente, não será tratado nos passos posteriores. Dessa</p><p>forma, a não identificação de um risco em potencial poderá gerar um</p><p>cenário inesperado, caso se concretize, pois não terá, dentro do mapa</p><p>de riscos, um tratamento pré-estabelecido.</p><p>Quanto ao bloco de análise de riscos, a organização deve:</p><p>• Compreender os riscos elencados no processo de identificação.</p><p>• Compreender as causas desses riscos.</p><p>• Estipular qual a probabilidade de ocorrência de cada risco.</p><p>• Compreender as causas desses riscos.</p><p>Tendo finalizado a etapa de análise, inicia-se o processo de avaliação de</p><p>riscos, no qual são definidos:</p><p>• Quais riscos precisam de tratamento.</p><p>• Quais os graus de prioridade no tratamento desses riscos.</p><p>Pode soar um pouco estranha a possibilidade de um risco não ser</p><p>tratado. Entretanto, em uma visão organizacional, nem todos os riscos</p><p>oferecem cenários danosos. Um vazamento de informações pode</p><p>ser danoso dependendo do nível hierárquico do qual se originar.</p><p>Informações vazadas de uma reunião da diretoria podem ser bem</p><p>mais sensíveis que as informações vazadas entre funcionários de nível</p><p>administrativo.</p><p>24</p><p>É necessário, assim, estabelecer quais riscos serão realmente tratados,</p><p>para que o mapa de riscos não fique repleto de informações que são</p><p>inexpressivas quanto aos seus impactos.</p><p>O bloco de tratamento de riscos aponta as ações que devem ser</p><p>tomadas para que um ou mais riscos possam ser sanados. Esse bloco</p><p>ainda contempla a forma como ocorrerá a implementação dessas ações</p><p>no contexto da organização. Essa também é considerada uma fase</p><p>crucial, pois é nela que se decide se um risco deve ser reduzido, evitado,</p><p>removido, aumentado, compartilhado ou retido.</p><p>Novamente, um som de estranheza pode surgir no ar quando se utiliza a</p><p>palavra aumentado. Nos objetivos desta aula, você deve ter visto que um</p><p>dos tópicos tratou a respeito dos impactos negativos ou positivos de um</p><p>risco. É fundamental que você compreenda que um risco não significa,</p><p>propriamente, algo ruim, embora a maior parte das definições aponte</p><p>nessa direção. Um risco é a probabilidade de algo ocorrer e esse algo</p><p>pode causar um impacto na organização.</p><p>A organização corre, diariamente, o risco de ser beneficiada com um</p><p>número astronômico de clientes da noite para o dia. Observe que essa</p><p>é uma situação benéfica, mas se não houver um preparo estrutural para</p><p>tratar tal situação, os resultados podem ser catastróficos.</p><p>Dessa forma, compreenda bem que riscos podem ser negativos ou</p><p>positivos.</p><p>Por fim, o bloco de monitoramento e análise crítica é um processo</p><p>contínuo, que visa realizar a aferição dos processos estabelecidos e seus</p><p>efetivos funcionamentos. Esse processo cíclico pode ser representado</p><p>pelo ciclo PDCA (Plan, Do, Check, Act – planeje, faça, cheque os resultados,</p><p>oficialize ou modifique a ação), apontado na Figura 2:</p><p>25</p><p>Figura 2 – Ciclo PDCA</p><p>Fonte: elaborado pelo autor.</p><p>O nome ciclo não é à toa, pois esses procedimentos descritos devem</p><p>ser feitos de maneira contínua, visando sempre a melhoria de um</p><p>determinado processo.</p><p>2. Explanando o contexto</p><p>De acordo com Hintzbergen (2018), a definição de contexto é esboçada</p><p>como o estabelecimento de questões internas e externas que sejam</p><p>relevantes para seu propósito e que afetem a habilidade de alcançar</p><p>resultados pretendidos. Já nas palavras de Barreto (2018), contexto está</p><p>relacionado aos setores envolvidos num processo de gestão de riscos.</p><p>Em ambas as colocações, é possível notar que existe uma necessidade</p><p>de participação direta dos setores da instituição no processo</p><p>26</p><p>de mapeamento e identificação dos riscos, ou seja, a estrutura</p><p>organizacional é o grande pilar nesta etapa.</p><p>Isso corrobora a ideia de que um processo de implantação de gestão de</p><p>riscos em TI deve ser empregado na modalidade Top to Bottom, ou seja,</p><p>de cima para baixo na hierarquia da instituição.</p><p>Ações de mudanças de paradigmas devem vir sempre apoiadas pelo alto</p><p>escalão para que sejam aderidas por toda a estrutura organizacional</p><p>abaixo.</p><p>Todos os setores envolvidos têm seu papel a ser desempenhado e</p><p>devem realizá-lo de forma orquestrada para que o plano de gestão de</p><p>riscos tenha êxito.</p><p>Essa etapa do processo, geralmente, alastra-se por toda a extensão</p><p>organizacional e envolve não apenas agentes humanos, mas também</p><p>tecnológicos. É comum o envolvimento de organizações externas</p><p>(contratadas para atuarem em determinadas etapas de um processo de</p><p>gestão de risco).</p><p>Um exemplo de insumos tecnológicos que podem ser requeridos para</p><p>tratamento de um risco é a ativação de um firewall para barrar tentativas</p><p>de invasão a partir de um endereço IP específico. Podemos, ainda,</p><p>utilizar como exemplo o uso de um sistema interno de e-mails, em</p><p>servidores próprios, para evitar que as mensagens dos colaboradores</p><p>circulem em servidores externos.</p><p>Já como exemplo de contratação de empresa externa, para auxiliar</p><p>em algumas etapas do processo de gestão de riscos, podemos citar</p><p>datacenters para realização de backups (cópias de segurança), que</p><p>podem ser ativados para salvamento de dados em local remoto ou para</p><p>recuperação desses dados em caso de perdas, falhas ou danos aos</p><p>dados locais.</p><p>27</p><p>Observe que todo esse cenário ocorre dentro de um contexto pré-</p><p>estabelecido no momento de elaboração do plano de gestão de riscos.</p><p>3. O processo de identificação dos riscos</p><p>A identificação dos riscos, neste contexto, consiste em agrupar os riscos</p><p>comuns de maneira categorizada, ou seja, correlacionar riscos de uma</p><p>mesma natureza, origem, gênero ou impacto “com o objetivo de gerar</p><p>uma lista de riscos que possam afetar a realização dos objetivos da</p><p>organização”, segundo Barreto (2018, p. 171).</p><p>Nesta etapa do processo, é importante que a governança de TI analise</p><p>todos os aspectos organizacionais que possam envolver incertezas. Para</p><p>facilitar a assimilação, seguem alguns exemplos.</p><p>Imagine que uma determinada empresa atue no segmento de</p><p>investimentos financeiros e realiza o grande montante de suas</p><p>atividades via Internet. Diariamente são trafegados milhões de reais em</p><p>investimento mediante o sistema de home broker dos clientes. Alguns</p><p>possíveis cenários de risco neste contexto poderiam ser:</p><p>• A organização ficar sem Internet, impossibilitando a recepção dos</p><p>investimentos feitos pelos clientes.</p><p>• O sistema de Home Broker cair, devido a um tráfego muito intenso</p><p>(overflow), de acordo com a oscilação da bolsa de valores.</p><p>• O sistema de Home Broker sofrer uma quebra de segurança e os</p><p>dados trafegados serem comprometidos.</p><p>• Ocorrer erro de hardware na estrutura dos servidores que</p><p>mantém a versão back-end do sistema em funcionamento.</p><p>28</p><p>• Ocorrer queda de energia e os equipamentos pararem durante</p><p>o dia, no período de funcionamento da bolsa e maior tráfego de</p><p>clientes, emitindo ordens de compra e venda de ações e títulos.</p><p>Observe que, no exemplo acima, foram listados riscos que estão,</p><p>de alguma forma, relacionados, pois todos têm ligação direta ao</p><p>funcionamento de uma estrutura computacional responsável por</p><p>manter a organização em operação.</p><p>É exatamente dessa maneira que devem ser elencados os riscos dentro</p><p>dessa fase</p><p>do processo de gestão. Lembre-se de que ainda não é o</p><p>momento de tratá-los. Para isso, existirá um momento específico que se</p><p>inicia na análise dos riscos e finaliza na etapa de tratamento dos riscos.</p><p>4. Uma visão do PMBOK a respeito</p><p>O Project Management Body Of Knowledge (PMBOK) é um guia</p><p>desenvolvido pelo Project Management Institute (PMI), focado no</p><p>estabelecimento de metodologias bem definidas para gerenciamento de</p><p>projetos.</p><p>Embora o grande objetivo do guia não seja voltado especificamente à</p><p>área de gestão de riscos, papel muito bem coberto pelo COBIT e outras</p><p>bibliotecas focadas na área de segurança da informação, o PMBOK</p><p>aborda alguns aspectos que convém analisarmos, principalmente,</p><p>quanto à mitigação de riscos por meio de padronização de</p><p>procedimentos.</p><p>Um adendo: ainda que o foco principal não seja a área de riscos, o guia</p><p>detém uma abordagem bastante estruturada a respeito do tema, afinal,</p><p>todo projeto tem também seu grau de risco que precisa ser considerado.</p><p>Nas palavras de Fernandes (2014):</p><p>29</p><p>O PMBOK, para ser utilizado de forma consistente em uma organização</p><p>de TI, necessita de adaptações em função dos tipos, portes e riscos</p><p>dos projetos. Além do mais, deve ser estabelecido um processo de</p><p>gerenciamento de projetos que interligue, de forma lógica e coerente,</p><p>as boas práticas entre si. Adicionalmente, formulários específicos</p><p>devem ser elaborados ou customizações de ferramentas específicas de</p><p>gerenciamento de projetos podem ser necessárias para o uso do processo.</p><p>(FERNANDES, 2014, p. 357)</p><p>A sexta edição do PMBOK (2017) trata a respeito da implementação de</p><p>respostas aos riscos, dividindo o processo em três etapas: entradas,</p><p>ferramentas e técnicas e saídas, conforme apontado na Figura 3.</p><p>Figura 3 – Implementar respostas aos riscos–PMBOK</p><p>Fonte: PMBOK (2017, p. 51).</p><p>4.1 Implementação de respostas aos riscos</p><p>Conforme apresentado na Figura 3, o PMBOK define três estágios</p><p>para implementação de respostas aos riscos. Abordaremos de forma</p><p>objetiva cada uma deles, pois como já foi citado, o PMBOK não é voltado</p><p>especificamente à gestão de riscos.</p><p>30</p><p>4.1.1. Entradas</p><p>As entradas são os inputs, que darão início ao processo de</p><p>implementação do Risco. Caso o guia PMBOK seja utilizado em</p><p>consonância com alguma biblioteca, norma ou framework, os</p><p>documentos, mapas e diagramas de riscos podem ser considerados</p><p>como os elementos de entrada que situam a organização quanto aos</p><p>riscos e suas especificações.</p><p>4.1.2. Ferramentas e técnicas</p><p>Compreendem os insumos técnicos e recursos pessoais que serão</p><p>empregados na resolução do risco, ou sua amenização, visando</p><p>minimizar os impactos.</p><p>O próprio guia coloca dois tópicos que são voltados a recursos</p><p>humanos, o que demonstra a importância de uma ação efetiva e pessoal</p><p>nas tratativas dos riscos, ainda que o uso de ferramentas técnicas/</p><p>informatizadas também sejam citadas.</p><p>4.1.3. Saídas</p><p>Engloba a solicitação de mudanças e, principalmente, o registro</p><p>(documentação oficial) do que foi aprendido com o risco e como este</p><p>aprendizado impactará as ações futuras da organização na tratativa</p><p>deste e de novos riscos inerentes ao mesmo tema ou temas similares.</p><p>Realizando uma ponte desse diagrama com o ciclo PDCA, já abordado</p><p>anteriormente e demonstrado na Figura 2, pode-se considerar:</p><p>31</p><p>Quadro 1 – Comparativo entre ciclo PDCA e diagrama de</p><p>implementação de respostas aos riscos, do guia PBOK, sexta edição</p><p>(2017)</p><p>Fonte: elaborado pelo autor.</p><p>Compreenda que, embora estejamos apresentando uma gama de</p><p>recursos, você deve adaptar o uso da biblioteca/framework que</p><p>melhor se adequar ao cenário no qual o processo de gestão de riscos</p><p>esteja sendo implantado/ gerenciado. Assim, conhecer um leque de</p><p>possibilidades poderá conferir uma amplitude mais consistente para</p><p>escolha.</p><p>Referências Bibliográficas</p><p>BARRETO, Jeanine dos Santos et al. Fundamentos de segurança da informação.</p><p>Porto Alegre, RS: SAGAH, 2018.</p><p>FERNANDES, Aguinaldo Aragon. Implantando a governança de TI: da estratégia à</p><p>gestão dos processos e serviços. 4. ed. Rio de Janeiro, RJ: Brasport, 2014.</p><p>HINTZBERGEN, Jule et al. Fundamentos de segurança da informação: com base</p><p>na ISSO 27001 e na ISSO 27002. Rio de Janeiro, RJ: Brasport, 2018.</p><p>32</p><p>Análise e Avaliação de riscos</p><p>Autoria: Márcio dos Santos</p><p>Leitura crítica: Cecilia Sosa Arias Peixoto</p><p>Objetivos</p><p>• Compreender os riscos inerentes a uma organização.</p><p>• Reconhecer as causas e as fontes dos riscos.</p><p>• Mensurar os níveis de riscos.</p><p>• Categorizar os níveis de riscos.</p><p>• Estipular os impactos organizacionais em caso de</p><p>incidência dos riscos.</p><p>• Compreender os métodos utilizados para a</p><p>realização de análise quantitativa ou qualitativa</p><p>quanto aos riscos identificados.</p><p>• Conhecer técnicas quantitativas aplicáveis para se</p><p>chegar a métricas de análise de risco.</p><p>33</p><p>1. Análise dos riscos</p><p>Um processo de gestão de riscos deverá sempre ser o ponto de partida</p><p>para a obtenção de sucesso nas operações de análise e tratativa de</p><p>riscos. De acordo com a Norma ISO 31000, nas palavras de Barreto</p><p>(2018), esse processo é composto por sete requisitos básicos:</p><p>• Comunicação e consulta.</p><p>• Estabelecimento do contexto.</p><p>• Identificação de riscos.</p><p>• Análise de riscos.</p><p>• Avaliação de riscos.</p><p>• Tratamento de riscos.</p><p>• Monitoramento e análise crítica.</p><p>Neste tema, trataremos especificamente da análise e avaliação dos</p><p>riscos.</p><p>É de suma importância que você compreenda que a tratativa de algo</p><p>só pode ocorrer após sua descoberta. Logo, o cumprimento dos sete</p><p>requisitos requer uma sequência lógica, sem antecipar ou pular etapas.</p><p>Cabral e Caprino (2015) nos alerta sobre a importância de se conhecer</p><p>todos os conceitos envolvidos na abordagem de análise de riscos e</p><p>ressalta que, no processo de análise, devemos seguir dois pontos. Dois</p><p>norteadores: a probabilidade de o risco ocorrer e a magnitude de perda,</p><p>em caso de ocorrência.</p><p>A probabilidade ou frequência de ocorrência deve definir um intervalo</p><p>de tempo a ser utilizado no cálculo, além de estabelecer valores por</p><p>34</p><p>meio numérico, por exemplo, valores entre zero e um. A fórmula deverá</p><p>seguir os princípios da probabilidade: número de ocorrências no período</p><p>selecionado dividido pelo próprio período.</p><p>Suponha que a organização ABC Empreendimentos está calculando a</p><p>probabilidade de ocorrerem falhas nos servidores para um determinado</p><p>período. A priori, deve-se seguir a seguinte ordem de passos:</p><p>1. n(Ω): definir um período tomado como base, por exemplo, o</p><p>ano anterior (compreenda que ano se refere ao período de doze</p><p>meses imediatamente anteriores ao período atual).</p><p>2. n(a): contabilizar a quantidade de ocorrências do mesmo gênero</p><p>(falha nos servidores) dentro do período selecionado.</p><p>3. p(a): obter a probabilidade de ocorrência do evento, por meio da</p><p>divisão entre n(a) por n(Ω).</p><p>Dessa forma, utilizando valores fictícios como exemplo, caso no</p><p>último ano (doze meses – n(Ω)) os servidores da organização ABC</p><p>empreendimentos tenham sofrido três falhas (n(a)), a probabilidade de</p><p>ocorrência no período corrente será de 25% ou, 0,25 caso seja utilizada</p><p>escala proporcional de zero a um.</p><p>Para cada risco identificado, existe um tratamento a ser empregado,</p><p>seja a aceitação, remoção ou expansão. Cada risco tem sua respectiva</p><p>prioridade de acordo com os impactos ou organização que hospeda</p><p>o risco. Como forma de exemplificar, podemos comprar os seguintes</p><p>cenários:</p><p>a. A empresa A está localizada em uma região do Brasil cujo índice</p><p>de chuvas é de 15% para o período de doze meses. Todos os</p><p>dados da empresa estão em nuvem, alocados em um servidor</p><p>externo. O escritório citado funciona apenas com processos</p><p>administrativos.</p><p>35</p><p>b. A empresa B, de contrapartida, está em uma região cujo índice</p><p>pluviométrico é de 88%. Os servidores da empresa estão alocados</p><p>no próprio escritório.</p><p>Ambas as empresas podem estabelecer a incidência de alagamento</p><p>como um risco, mas o grau apontado pela empresa A seria muito menor</p><p>que o grau apontado pela empresa B.</p><p>Adicionalmente,</p><p>a própria localização física de cada empresa</p><p>influenciaria na prioridade do risco. Para a empresa A, o risco de perda</p><p>de dados é quase nulo, já para a empresa B, o risco se potencializa.</p><p>Assim, pode-se afirmar que a definição de prioridade no tratamento de</p><p>riscos é muito relativa e para que exista uma métrica de prioridades de</p><p>tratamento, é necessário fazer uma análise de cenários e impactos para</p><p>que seja possível chegar aos níveis de prioridade adequados.</p><p>Voltemos à ABC Empreendimentos, como base desse novo exemplo.</p><p>Considere que uma nova análise probabilística foi realizada quanto à</p><p>incidência de vírus na rede interna e o resultado obtido pela fórmula foi</p><p>igual a 80% (0,8).</p><p>Na análise anterior, realizada quanto à possibilidade de queda</p><p>de servidores no mesmo período, a probabilidade ficou em 25%.</p><p>Em uma tabela comparativa com ambos os dados, observaremos</p><p>claramente que as chances de infecção por vírus de computador</p><p>ocorrer são relativamente maiores que as chances de parada dos</p><p>servidores. Considere ainda que outros detalhes devem ser levados em</p><p>consideração, como o tipo de vírus e sua ação nos computadores em</p><p>detrimento aos impactos pela queda dos servidores.</p><p>Cabe ressaltar que a escolha equivalente de períodos definirá a</p><p>assertividade do cálculo. De nada adianta realizar o comparativo acima,</p><p>considerando o período de um mês para a probabilidade de infecção</p><p>36</p><p>virtual por vírus e o período de 24 meses para a pane em servidores.</p><p>Cabral e Caprino (2015) aponta que:</p><p>Um ponto importante a se considerar ao analisarmos tais números é o</p><p>intervalo de tempo utilizado. Embora um evento com 10% de chance de</p><p>acontecer em um ano possa ser considerado ‘raro’ sob certa perspectiva,</p><p>também pode ser considerado comum quando o intervalo de tempo</p><p>considerado é maior – o mesmo evento, quando considerado para um</p><p>intervalo de tempo de vinte anos, deve acontecer por volta de duas vezes.</p><p>O correto entendimento de probabilidades é um dos fatores críticos da</p><p>análise e da gestão de risco. (CABRAL; CAPRINO, 2015, p. 40)</p><p>2. Processo de identificação</p><p>Considerando que o contexto já está totalmente estabelecido e a</p><p>probabilidade de ocorrência dos riscos a serem analisados já está</p><p>calculada, basta apenas compreender a forma como os riscos, se</p><p>comportam. De acordo com Barreto (2018), essa análise:</p><p>Envolve a compreensão sobre os riscos da organização, suas causas,</p><p>fontes, consequências positivas e negativas, e ainda a probabilidade de</p><p>ocorrerem. Essa análise pode ser feita em diversos graus de detalhamento,</p><p>a critério da empresa, e ainda pode ser quantitativa ou qualitativa.</p><p>(BARRETO, 2018, p. 172)</p><p>Os eventos causadores de perdas são conhecidos como ameaças.</p><p>Veremos, a seguir, os tipos de ameaça, agentes, impactos, ativos e</p><p>vulnerabilidades que devem ser identificadas na análise de riscos.</p><p>Por meio da análise de riscos, é possível esclarecer quais ameaças</p><p>são relevantes para os processos operacionais, além de identificar</p><p>os riscos associados, garantindo que as medidas de segurança sejam</p><p>corretamente implantadas, segundo Hintzbergen (2018).</p><p>37</p><p>Ainda neste contexto, Barreto (2018) informa que avaliar riscos significa</p><p>dar prioridade aos riscos, organizando-os por critérios pré-estabelecidos</p><p>pela organização, considerando todos os possíveis fatores envolvidos.</p><p>2.1 Ameaças</p><p>Ameaças podem receber diversas designações, de acordo com a</p><p>organização, atividade, estrutura física e computacional. Elencá-las de</p><p>maneira correta e detalhada facilitará os passos de tratativa. Barreto</p><p>(2018) define ameaças como agentes ou condições que, ao explorarem</p><p>as vulnerabilidades, podem provocar danos e perdas e categoriza as</p><p>ameaças em três categorias (veremos a seguir).</p><p>Figura 1 – Hacker utilizando vários computadores</p><p>Fonte: gorodenkoff/ iStock.com.</p><p>Parte dos esforços empregados na gestão de riscos deve ser voltado à</p><p>minimização dos impactos decorrentes da concretização de uma ameaça</p><p>e, para isso, deve-se entender como as ameaças ocorrem, segundo</p><p>Barreto (2018).Pode-se utilizar como base os dados demonstrados no</p><p>Quadro 1 para conhecer as ameaças mais profundamente. Embora não</p><p>38</p><p>exista um modelo pré-definido e padronizado para o procedimento, esse</p><p>quadro pode ser um bom ponto de partida, adequável de acordo com a</p><p>organização.</p><p>Quadro 1 – Proposta de elicitação de ameaças, com categorização</p><p>Ameaça Tipo Origem Impacto</p><p>Invasão.</p><p>Intencional.</p><p>Externa. Roubo de</p><p>informações; quebra</p><p>de integridade.</p><p>Malwares. Não</p><p>intencional.</p><p>Externa/</p><p>interna.</p><p>Danificação de dados;</p><p>comprometimento da</p><p>integridade.</p><p>Queda de energia. Não</p><p>intencional.</p><p>Externa. Suspensão</p><p>temporária das</p><p>operações; perda</p><p>de comunicação</p><p>síncrona com filiais;</p><p>perda de trabalhos</p><p>em execução (não</p><p>salvos).</p><p>Indisponibilidade</p><p>de Internet.</p><p>Não</p><p>intencional.</p><p>Externa. Perda de</p><p>comunicação</p><p>síncrona com filiais</p><p>de forma síncrona;</p><p>paralização dos</p><p>sistemas SAAS.</p><p>Perda de dados por</p><p>falha humana.</p><p>Não</p><p>intencional.</p><p>Interna. Inconsistência de</p><p>informações.</p><p>Exclusão de</p><p>dados de forma</p><p>intencional.</p><p>Intencional. Interna. Inconsistência de</p><p>informações.</p><p>Fonte: elaborado pelo autor.</p><p>39</p><p>Adicionalmente, sugere-se, para este quadro, a inclusão de colunas</p><p>como: modo de solução, plano de contingência, prazo de resolução, nível</p><p>de criticidade.</p><p>1.2.1. Agente de ameaça</p><p>As três principais categorias dos agentes de ameaça são:</p><p>• Ameaças naturais: aquelas que têm como origem os fenômenos</p><p>da natureza (terremotos, furacões, enchentes, maremotos etc.).</p><p>• Ameaças involuntárias (não intencionais): aquelas que resultam</p><p>de ações danosas, mas não intencionais e, geralmente, são</p><p>causadas por erros, falhas, e acidentes.</p><p>• Ameaças intencionais: são aquelas causadas com o propósito</p><p>de gerar dano, perda ou prejuízo, como invasões, disseminação</p><p>proposital de vírus em uma rede, vazamento de dados e</p><p>informações etc.</p><p>1.2.2. Impacto</p><p>Os impactos são resultado da ameaça concretizada. Cabral e Caprino</p><p>(2015), esclarecem que o impacto:</p><p>Está diretamente relacionado ao comprometimento de uma das</p><p>propriedades básicas da segurança da informação: confidencialidade,</p><p>integridade e disponibilidade. O impacto pode ser representado de</p><p>diversas formas, embora seja comum considerá-lo em termos financeiros,</p><p>ou seja, o custo ou prejuízo causado pela ocorrência da ameaça. (CABRAL;</p><p>CAPRINO, 2015, p. 41)</p><p>Nem sempre os impactos têm aspecto negativo, pois sua incidência</p><p>pode influenciar no atingimento de um objetivo, tornando-se então, uma</p><p>oportunidade, segundo Barreto (2018).</p><p>40</p><p>1.2.3. Ativo</p><p>O ativo é o componente que será diretamente afetado pela ocorrência</p><p>da ameaça e não precisa propriamente ser algo concreto. Alguns</p><p>exemplos de ativos concretos e abstratos são:</p><p>Concretos:</p><p>• Estrutura física da organização.</p><p>• Estrutura computacional (hardware).</p><p>• Recursos humanos.</p><p>• Documentos, fichas, relatórios, registros.</p><p>• Bens de forma geral.</p><p>Abstratos:</p><p>• Dados isolados ou processados.</p><p>• Informação processada.</p><p>• Conhecimento gerado pela informação processada.</p><p>Calcular o impacto das ameaças com base no valor financeiro de</p><p>determinados ativos não faz muito sentido, considerando que nem</p><p>sempre o valor de um determinado ativo corresponde ao valor do</p><p>subativo vinculado. Um bom exemplo seria calcular um Disco Rígido</p><p>(HD) com baixo valor (considerando seu preço de compra relativamente</p><p>baixo), pois os dados que pode armazenar acabam superando muito o</p><p>valor empregado na compra de um novo componente do mesmo tipo.</p><p>41</p><p>1.2.4. Vulnerabilidade</p><p>Uma ameaça só pode, de fato, se concretizar caso haja algum tipo de</p><p>vulnerabilidade que venha a ser explorada pelo agente. Os tipos de</p><p>vulnerabilidades podem ser diversos e, geralmente, não são de cunho</p><p>intencional.</p><p>Figura 2 – Brechas e vulnerabilidades</p><p>Fonte: NicoElNino. iStock.com.</p><p>Quando tratamos a respeito de computação, especificamente, existe</p><p>uma tendência a se enxergar apenas os componentes informatizados</p><p>em qualquer tipo de cenário abordado, mas é importante ressaltar</p><p>que, geralmente, esses componentes são um dentre todos os</p><p>demais elementos que compõem a gestão da informação. Assim, a</p><p>vulnerabilidade, por exemplo, não estará ligada apenas aos dispositivos</p><p>tecnológicos, mas a vários outros fatores agregados, como:</p><p>42</p><p>• Pessoas que lidam com a informação: grande parte da</p><p>vulnerabilidade provém de fatores humanos, ou seja, pessoas</p><p>que compõem o corpo de colaboradores da organização deixam</p><p>vazar informações que aparentemente podem não ter grande</p><p>importância, mas se utilizadas por alguém mal intencionado, pode</p><p>ocasionar em situação de risco.</p><p>• Pessoas com acesso a altos níveis gerenciais/ administrativos:</p><p>via de regra, é uma boa prática conceder acesso apenas aos níveis</p><p>necessários aos colaboradores, evitando que pessoas, ainda</p><p>que não intencionalmente, permitam abertura de brechas de</p><p>segurança.</p><p>• Desconcentrar informações: informações concentradas em</p><p>apenas uma pessoa acabam sendo danosas, pois o nível de</p><p>vulnerabilidade estará concentrado em apenas um ponto.</p><p>Barreto (2015) mostra que:</p><p>Os sistemas, em geral, precisam ser protegidos dessas vulnerabilidades,</p><p>porque, quando elas são exploradas, podem causar diversos problemas</p><p>para as empresas. Uma vulnerabilidade é, geralmente, explorada por</p><p>uma ameaça. Ameaças são agentes ou condições que, ao explorarem as</p><p>vulnerabilidades, podem provocar danos e perdas [...]. É importante que</p><p>as empresas conheçam as principais ameaças à segurança da informação,</p><p>bem como as vulnerabilidades a elas associadas, para que seja possível</p><p>evitar os transtornos causados pela concretização de uma ameaça. Nesse</p><p>processo de análise, adentra-se no estudo do risco, que envolve entender</p><p>como as ameaças ocorrem, verificar as vulnerabilidades a que a empresa</p><p>está sujeita e analisar a probabilidade de concretização de ataques. Dessa</p><p>forma, é possível efetuar um tratamento mais adequado aos riscos, de</p><p>acordo com as reais condições da organização. (BARRETO, 2015, p. 18)</p><p>É um consenso entre profissionais da computação que eliminar as</p><p>vulnerabilidades em cem por cento é algo impossível, principalmente,</p><p>quando se trata de sistemas e estruturas de grande porte, em que o</p><p>43</p><p>número de variáveis a serem tratadas e testadas é alto. Entretanto,</p><p>também existe o consenso de que é possível se reduzir drasticamente</p><p>as brechas de vulnerabilidades mais comuns, dificultando o nível dos</p><p>riscos.</p><p>Quando as vulnerabilidades são minimizadas, há de se preocupar ainda</p><p>com ataques de força bruta, ataques do tipo man in the middle, ataque</p><p>de colisão, ataque de pré-imagem, dentre outros.</p><p>3. Avaliação de riscos</p><p>A avaliação do risco pode ser considerada como “o processo geral de</p><p>identificação do risco, análise do risco e estimativa do risco”, segundo</p><p>Hintzbergen (2018, p. 21).</p><p>Já Cabral e Caprino (2015) afirmam que neste tema (análise de riscos),</p><p>a computação é recém-chegada, pois já era amplamente abordado</p><p>por muitas outras disciplinas, principalmente, aquelas do segmento</p><p>financeiro. Acrescenta ainda que:</p><p>Técnicas quantitativas foram desenvolvidas nas mais diversas disciplinas.</p><p>Algumas das técnicas mais promissoras de análise de risco são</p><p>provenientes de áreas como a engenharia e a física aplicada. Apesar de</p><p>diversas variações, é possível identificar componentes comuns a essas</p><p>técnicas, componentes que podem beneficiar qualquer tentativa de análise</p><p>quantitativa de risco (CABRAL e CAPRINO, 2015, p. 47).</p><p>Algumas dessas técnicas são amplamente aplicáveis à área da</p><p>computação, como:</p><p>• Decomposição: considerando que o mero estudo probabilístico</p><p>para realizar uma comparação entre sua incidência em</p><p>comparação ao seu impacto pode não ser suficiente para se</p><p>chegar a uma tomada de decisão. Desta forma, a técnica da</p><p>44</p><p>decomposição fragmenta o problema em partículas menores para</p><p>que essas partículas sejam analisadas e possam oferecer uma</p><p>visão mais clara do cenário como um todo. “A decomposição dos</p><p>fatores de risco é um dos conceitos mais importantes para uma</p><p>análise de risco eficiente”, segundo Cabral e Caprino (2015, p. 47).</p><p>• Estimativas em faixas de valores e probabilidades: ainda com</p><p>os valores fragmentados por meio da técnica de decomposição,</p><p>não é possível chegar a um valor único para todas as variáveis</p><p>envolvidas. Dessa forma, a obtenção de uma faixa de valores</p><p>torna-se algo mais viável que um valor fixo, pois em um cenário</p><p>com alto nível de mutabilidade, é mais adequado se encaixar</p><p>riscos/ ameaças, por meio de um intervalo de valores possíveis.</p><p>Por exemplo, seria muito mais prático avaliar-se a probabilidade</p><p>de ataque por malware de uma forma geral do que apontar um</p><p>tipo de malware específico como um Trojan.</p><p>• Calibragem: essa técnica fornece uma análise consistente, pois</p><p>envolve mais de uma pessoa no processo. Essa abordagem</p><p>visa alinhar o entendimento de várias pessoas para estimativa</p><p>dos valores (de prioridade de riscos) a serem atribuídos em</p><p>determinado processo.</p><p>Embora esta seja uma outra técnica, a calibragem utiliza recursos</p><p>da estimativa em faixa de valores e probabilidades para chegar a</p><p>uma faixa aceitável que comporta um intervalo de valores dentro</p><p>de si.</p><p>Uma das abordagens que também utiliza faixa de valores como base é</p><p>a taxonomia FAIR (Factor Analysis of Information Risk–Análise fatorial de</p><p>risco à informação). Essa taxonomia mensura os fatores que contribuem</p><p>para um determinado risco e a forma como influenciam direta ou</p><p>indiretamente uns nos outros.</p><p>45</p><p>Figura 3 – Taxonomia FAIR</p><p>Fonte: Cabral e Caprino (2015).</p><p>Utilizando esta taxonomia, o risco é calculado basicamente utilizando</p><p>como base quatro variáveis:</p><p>1. Frequência da ameaça.</p><p>2. Vulnerabilidade: qual a probabilidade de sucesso do ataque, perda</p><p>primária.</p><p>3. Perda primária.</p><p>4. Perda secundária.</p><p>Com esses dados, é possível obter-se a frequência com que uma</p><p>ameaça tenta se concretizar, bem como a estimativa de exposição à</p><p>vulnerabilidade por parte da organização. As perdas primárias estão</p><p>voltadas à reparação de um dano oriundo da concretização de uma</p><p>ameaça, enquanto as secundárias estão relacionadas a danos indiretos.</p><p>Outras variáveis podem surgir dentro do escopo de cada organização,</p><p>mas essas variáveis propostas pela taxonomia FAIR são um bom ponto</p><p>de partida para a maioria dos casos.</p><p>46</p><p>Referências Bibliográficas</p><p>BARRETO, Jeanine dos Santos et al. Fundamentos de segurança da informação.</p><p>Porto Alegre, RS: SAGAH, 2018.</p><p>CABRAL, Carlos; CAPRINO, Willian. Trilhas em Segurança da Informação:</p><p>caminhos e ideias para a proteção de dados. Rio de Janeiro, RJ: Brasport, 2015.</p><p>HINTZBERGEN, Jule et al. Fundamentos de segurança da informação: com base</p><p>na ISSO 27001 e na ISSO 27002. Rio de Janeiro, RJ: Brasport, 2018.</p><p>47</p><p>Tratamento, aceitação e</p><p>monitoramento dos riscos</p><p>Autoria: Márcio dos Santos</p><p>Leitura crítica: Cecilia Sosa Arias Peixoto</p><p>Objetivos</p><p>• Compreender os métodos para tratamento de</p><p>riscos.</p><p>• Ponderar estados de aceitação de riscos.</p><p>• Identificar situações para aceitação de riscos.</p><p>• Monitorar a aceitação de riscos.</p><p>• Avaliar status do risco a ser aceito.</p><p>48</p><p>1. Tratamento dos riscos</p><p>Assim como vários outros componentes em diversas áreas, os riscos</p><p>também têm um ciclo de vida que se inicia antes mesmo de sua</p><p>ocorrência, e culmina nas etapas de tratamento.</p><p>O processo de tratamento de riscos, ao contrário do que se pode</p><p>esperar, não visa propriamente eliminar o risco em si, pois já se sabe</p><p>que um risco não é eliminado em sua essência, mas minimizado ou</p><p>maximizá-lo quanto aos impactos que pode causar à organização,</p><p>quando ocorrer.</p><p>Dessa maneira, há de se pensar: o que faz então o processo de</p><p>tratamento de riscos? Nas palavras de Hintzbergen (2018), essa é a etapa</p><p>em que se implementam melhorias para modificar os riscos. Observe</p><p>que o autor nos aponta o verbo principal da operação como sendo</p><p>modificar o risco ao invés de eliminá-lo.</p><p>Dentre as métricas propostas, Hintzbergen (2018) cita que existem</p><p>formas diversas de modificar um risco, por exemplo:</p><p>• Encerrar atividades</p><p>que originam o risco.</p><p>• Tomar ou elevar o risco, a fim de perseguir uma oportunidade.</p><p>• Remover a fonte de riscos.</p><p>• Alterar a probabilidade de ocorrência do risco.</p><p>• Alterar as consequências do risco.</p><p>• Dividir o risco com um terceiro.</p><p>• Manter o risco por meio de uma escolha consciente.</p><p>49</p><p>1.1. Encerrar as atividades que originam o risco</p><p>Em uma análise ampla de cenários, você poderá observar que um risco</p><p>só ocorre ou se intensifica mediante um quadro prévio que o tenha</p><p>originado. Geralmente, este quadro é composto de micro etapas que</p><p>compõem as atividades da organização. Por exemplo, a opção de colocar</p><p>os dados da organização em um servidor em nuvem, como forma de</p><p>minimizar os riscos de perigos físicos ao equipamento, aumentando, por</p><p>consequência, o risco de invasão.</p><p>Um exemplo adicional seria a contratação de um software de firewall,</p><p>que pudesse construir uma barreira de verificação sobre todos os</p><p>pacotes trafegados em uma rede interna, de forma a prover maior</p><p>segurança aos dados. Esse mesmo firewall acabaria por causar</p><p>uma lentidão no tráfego de informações pela rede, podendo gerar</p><p>congestionamento em momentos de pico, resultando em não respostas</p><p>e quebrando o princípio da disponibilidade.</p><p>Com esses dois exemplos simples, é possível notar que ao eliminar o</p><p>agente causador do risco, o próprio risco também é eliminado. Isso</p><p>não significa que não haverá mais riscos, significa apenas que aquele</p><p>risco em especial deixará de existir. O próprio processo de mitigação</p><p>de riscos pode acabar por gerar outros riscos, segundo Hintzbergen</p><p>(2018) e caberá à governança de TI ponderar os níveis mais aceitáveis a</p><p>considerar.</p><p>Dessa forma, existem maneiras de se modificar um risco ao ceder às</p><p>duas opções possíveis: não iniciar ou não continuar uma determinada</p><p>atividade que dê origem ao cenário de riscos.</p><p>50</p><p>1.2. Tomar ou elevar o risco, a fim de perseguir uma</p><p>oportunidade</p><p>Essa situação é, de longe, uma das mais arriscadas por gestores de TI ou</p><p>times de governança de TI. Assim como praticamente tudo na vida, uma</p><p>oportunidade é rodeada de incertezas e essas incertezas geram cenários</p><p>potenciais de risco.</p><p>Há de se convir, entretanto, que alguns riscos de fato valem a pena, caso</p><p>o retorno obtido pela oportunidade seja benéfico e proporcionalmente</p><p>maior que o risco assumido.</p><p>Assim, a organização pode optar por encarar o cenário de risco ou até</p><p>mesmo elevar o risco já existente para aumentar uma oportunidade</p><p>iminente. Para uma melhor compreensão, vamos utilizar dois exemplos:</p><p>Pressuponha que uma organização tenha a oportunidade de diminuir</p><p>seus custos com infraestrutura de redes e tráfego de dados de</p><p>comunicação ao aderir a um novo protocolo beta, capaz de transformar</p><p>o padrão TCP/IP mais célere e menos custoso. A economia financeira</p><p>seria imediata, porém, haveria um risco em mudar toda a infraestrutura</p><p>atual para um protocolo em estado beta.</p><p>Nesse cenário hipotético, cabe ao time de governança de TI optar por</p><p>assumir ou não este risco, visando uma oportunidade. Em situações</p><p>desse tipo, em que um novo risco é avaliado, os resultados podem ser</p><p>mais incertos, pois, por ser algo novo, ainda não é possível mensurar</p><p>seus impactos objetivamente.</p><p>Já, nesse segundo exemplo, utilizaremos um cenário em que a</p><p>organização já tem o risco como parte de um processo e já tem</p><p>estabelecido seu tratamento. Pressuponha que para aumentar a</p><p>velocidade de tráfego em uma rede composta por Intranet, Extranet</p><p>e Internet, a organização precise diminuir as regras de firewall, já que,</p><p>51</p><p>nos últimos doze meses, os ataques à rede foram quase inexistentes</p><p>e, dentre os existentes, nenhum chegou a utilizar os critérios mais</p><p>robustos de segurança do firewall.</p><p>Observe que esse cenário de análise de riscos requer um leque</p><p>prévio de informações para que seja possível calcular a probabilidade</p><p>de ocorrência de riscos de acordo com eventos passados. Caberá,</p><p>novamente, ao time de governança de TI optar por assumir esse risco</p><p>mediante a análise realizada, visando capturar a oportunidade almejada.</p><p>1.3. Remover a fonte de risco</p><p>Esse tópico, diferentemente dos demais, já segue uma linha mais</p><p>extremista, em que se considera como solução para minimizar os riscos,</p><p>a eliminação de sua fonte.</p><p>Em uma visão geral, essa ação pode ser considerada sensata, como, por</p><p>exemplo, a eliminação da Internet em uma organização para prevenir</p><p>invasão externa aos servidores. Entretanto, é necessário atentar que</p><p>nem sempre ações extremistas geram os melhores resultados.</p><p>1.4. Alterar a probabilidade</p><p>Embora o título aparente aludir à manipulação de dados, não é bem</p><p>essa a ideia proposta. Quando falamos de alterar a probabilidade, nos</p><p>referimo a considerar dados diferentes para gerar um resultado diverso</p><p>de uma mesma probabilidade já estipulada. Vejamos um exemplo:</p><p>considere que a empresa ABC S/A teve um total de doze tentativas</p><p>de ataque cibernéticos nos últimos dois anos. Proporcionalmente,</p><p>é possível afirmar que existiu uma média de um ataque a cada dois</p><p>meses.</p><p>52</p><p>Esse número pode ser um número elevado, se for considerado de</p><p>forma isolada, mas, ao recalcular a probabilidade adicionando um novo</p><p>comparativo, esse cenário pode mudar um pouco.</p><p>Ainda na mesma empresa ABC S/A, a probabilidade gerada, aponta que</p><p>para os próximos vinte e quatro meses, ocorrerão doze novos ataques,</p><p>mas, estatisticamente, toda a estrutura estabelecida pela organização</p><p>para segurança (firewall, DMZ, IPS, IDS) é capaz de deter 98% dos</p><p>ataques.</p><p>Observe que com essas novas variáveis, a probabilidade de invasão</p><p>muda consideravelmente. Ainda que ocorram ataques, a estrutura de</p><p>proteção é forte o suficiente para barrá-los sem causar danos à rede</p><p>interna. Dessa forma, é necessário analisar mais variáveis dentro de um</p><p>estudo probabilístico, de forma a obter valores mais confiáveis de um</p><p>contexto específico.</p><p>Figura 1 – Infraestrutura de segurança de redes</p><p>Fonte: Borodatch/ iStock.com.</p><p>53</p><p>1.5. Alterar as consequências</p><p>Quando a probabilidade não pode ser alterada, busca-se alterar</p><p>as consequências advindas de um risco. As consequências são</p><p>provenientes do risco ocorrido, ou seja, as ações tomadas deverão</p><p>considerar que o risco já se concretizou. Uma das formas de se</p><p>modificar as consequências é diluir o ponto de impacto. Utilizemos o</p><p>mesmo exemplo anterior, da empresa ABC S/A e seu sistema de Firewall.</p><p>Caso a rede da organização venha a ser invadida, todos os dados</p><p>estarão sujeitos ao perigo. Entretanto, se esses dados estiverem</p><p>descentralizados ou alocados de maneira distribuídas em sub-redes</p><p>com níveis de segurança diferenciada, o ataque recebido poderá causar</p><p>menos impacto. Nota-se, entretanto, que, na tentativa de modificar a</p><p>consequência, uma nova estratégia foi traçada e vem, inevitavelmente</p><p>com seu próprio leque de riscos.</p><p>1.6. Dividir o risco com um terceiro</p><p>É possível também transferir os impactos dos riscos a seguradoras, que</p><p>assumirão a responsabilidade de cobertura por danos físicos, materiais</p><p>e virtuais, em caso de concretização dos riscos. Esse cenário é muito</p><p>comum, principalmente, na era da informação, em que os dados valem</p><p>mais que o próprio dinheiro.</p><p>Neste tema, Cabral e Caprino (2015), apontam-nos a oportunidade de</p><p>transferência de risco como algo bastante viável:</p><p>Através de medidas como seguros ou legislação é possível transferir o</p><p>risco para outra entidade, como uma seguradora. Uma entidade pode</p><p>optar em transferir seu risco por meio de pagamento de um prêmio a</p><p>uma seguradora. O seguro para riscos de SI ainda é pouco comum, uma</p><p>vez que não há fontes de dados confiáveis para as abordagens atuariais</p><p>das seguradoras. Legislação e outras regulamentações também podem</p><p>54</p><p>causar a transferência de riscos, geralmente, de um grupo de indivíduos</p><p>com pouca influência sobre os riscos para uma entidade capaz de mitigá-</p><p>los. Um exemplo dessa situação é o padrão de segurança para dados de</p><p>cartões de pagamento, o PCI DSS. As bandeiras de cartão de crédito, entre</p><p>elas,</p><p>Visa e Mastercard, exigem que aqueles que trabalham com seus</p><p>cartões apliquem os controles definidos no padrão PCI DSS, aplicando</p><p>regras que incluem possibilidades de multas e sanções. Com isso, é</p><p>possível transferir o risco daqueles que sofrem com fraudes causadas pelo</p><p>vazamento de dados de cartões (os emissores e os portadores de cartões)</p><p>para aqueles capazes de reduzir as ocorrências, como os estabelecimentos</p><p>que aceitam os pagamentos (identificados também como principal ponto</p><p>de comprometimento dos dados). CABRAL; CAPRINO (2015, p. 51)</p><p>Dessa forma, embora os riscos sejam inevitáveis, os impactos podem</p><p>ser menos agressivos caso a organização não precise lidar com eles.</p><p>Essa opção aplica-se, claro, apenas a danos físicos, como estruturas e</p><p>equipamentos, mas caso o impacto seja mais abstrato, como a imagem</p><p>da organização diante de seus clientes e acionistas, o cenário muda</p><p>consideravelmente e, devido à subjetividade da situação, o processo de</p><p>recuperação é impreciso.</p><p>1.7. Manter o risco através de uma escolha consciente</p><p>Por fim, temos a parte mais sensível dessa lista, que é a aceitação de</p><p>um risco. Essa escolha deve levar em consideração um amplo conjunto</p><p>de variáveis, que vão desde os impactos financeiros até os impactos de</p><p>imagem da organização diante do mercado.</p><p>Embora esse seja um dos últimos passos descritos, é também um dos</p><p>primeiros a ser considerado. Isso ocorre devido ao efeito cíclico de</p><p>melhoria contínua no processo de gestão de riscos em que o efeito</p><p>contínuo faz com que não se tenha propriamente um ponto de partida</p><p>ou ponto de chegada, mas uma linha temporal constante e evolutiva, em</p><p>forma de espiral.</p><p>55</p><p>Nesse contexto, “antes de considerar o tratamento de um risco, a</p><p>organização deve definir um critério para determinar se os riscos podem</p><p>ou não ser aceitos”, segundo Hintzbergen (2018, p. 43). Essa análise se</p><p>torna muito particular para cada organização, mas um exemplo a ser</p><p>tomado é quanto aos aspectos financeiros. Um risco pode ser aceito,</p><p>caso os impactos de sua ocorrência sejam baixos ou caso o custo de seu</p><p>tratamento seja algo exorbitante e inviável, segundo Hintzbergen (2018).</p><p>Nessa mesma linha de raciocínio, Cabral e Caprino (2015) apontam-</p><p>nos que o processo de mitigar o risco incorre em uma análise pela</p><p>organização:</p><p>Orisco identificado pode ser considerado muito alto pela organização,</p><p>que pode definir ações para reduzi-lo. Existem várias abordagens para</p><p>a redução de riscos, sendo a mais comum à aplicação de controles. Os</p><p>controles podem reduzir o risco através da diminuição da probabilidade</p><p>de concretização de uma ameaça, normalmente através da diminuição das</p><p>vulnerabilidades. É o que se faz, por exemplo, ao se aplicar uma correção</p><p>de software (patch) a um sistema. É importante ressaltar que controles</p><p>podem não eliminar completamente o risco e trazem custos, diretos e</p><p>indiretos, à organização. Ao risco existente após a aplicação do controle</p><p>damos o nome de ‘risco residual’ (o risco original também é conhecido</p><p>como ‘risco inerente’). (CABRAL; CAPRINO, 2015, p. 50)</p><p>O processo de tratamento de riscos se estrutura basicamente em:</p><p>• Aplicar os controles adequados para reduzir os riscos.</p><p>• Aceitar de forma consciente e objetiva os riscos, desde que</p><p>satisfaçam claramente a política e os critérios de aceitação de risco</p><p>da organização.</p><p>• Evitar riscos, não permitindo ações que possam causar sua</p><p>ocorrência.</p><p>56</p><p>• Transferir os riscos associados a outras partes, por exemplo,</p><p>seguradoras ou fornecedores.</p><p>2. Aceitação dos riscos</p><p>A aceitação dos riscos se baseia no simples ato de inércia, que não deve</p><p>ser considerada com a ignorância da existência do risco, muito pelo</p><p>contrário, essa é uma inércia planejada, estudada e meticulosamente</p><p>avaliada.</p><p>Conforme já vimos, existem riscos que têm menor impacto que outros</p><p>em uma organização. Alguns riscos podem até ser considerados como</p><p>banais e triviais e não necessitam propriamente de um conjunto de</p><p>controles de tratamento.</p><p>Um bom exemplo de riscos triviais, em um contexto de TI, seria a pane</p><p>de componentes de hardware, como placas de memória, por exemplo.</p><p>Como se trata de um risco sobre o qual não se tem domínio, o plano</p><p>máximo que pode existir para tratá-lo é aceitá-lo. Dessa forma, se</p><p>alguma máquina do parque tecnológico parar de funcionar devido à</p><p>pane na memória RAM, troca-se a placa e coloca-se a máquina de volta à</p><p>ativa.</p><p>Para cenários de riscos triviais, é importante existir os critérios de</p><p>contingência que seja capaz de prover a continuidade dos serviços/</p><p>negócios pelo período em que o risco esteja sendo tratado ou enquanto</p><p>o risco estiver impactando a organização (ainda que de forma ínfima).</p><p>O Plano de Continuidade do Negócio (Business Continuity Planning–</p><p>BCP) também chamado de continuidade dos serviços, dependendo</p><p>da bibliografia adotada, está contido dentro do tema disponibilidade,</p><p>ou seja, dar continuidade aos serviços significa manter o serviço em</p><p>funcionamento ainda que em um grau diminuto.</p><p>57</p><p>Espera-se que durante o período de execução do plano de continuidade</p><p>do negócio, a equipe técnica esteja trabalhando para solucionar o</p><p>problema, falha ou erro e que este risco ocorrido esteja previamente</p><p>descrito, documentado e com os controles de tratativas pré-</p><p>estabelecidos no plano de gestão de riscos.</p><p>Planejar a continuidade dos negócios é, além de um critério de impacto</p><p>financeiro, pois as operações da organização continuam fluindo, mesmo</p><p>em ritmo desacelerado, também uma questão de postura de mercado,</p><p>pois mostra o quão a empresa é sólida e preparada para situações</p><p>adversas.</p><p>Seguindo no viés financeiro, Hintzbergen (2018) nos relata que,</p><p>anualmente, muitas empresas simplesmente não sobrevivem aos</p><p>impactos que os desastres naturais causam em seus sistemas,</p><p>principalmente, por não terem se preparado previamente para isso ou</p><p>por não terem um plano de continuidade de negócios pré-estabelecido.</p><p>Isso não significa que não ter este plano estruturado ocasionará,</p><p>taxativamente, na falência da organização. Entretanto, é um fato que os</p><p>impactos serão bem mais acentuados.</p><p>Paralelamente ao BCP, existe o Disaster Recovery Planning (DRP), Plano</p><p>de Recuperação de Desastres. Esse plano é focado especificamente no</p><p>que e como fazer, e contém informações que servirão de guia para que</p><p>a organização consiga se reestruturar, ainda que paulatinamente, após a</p><p>ocorrência de um desastre.</p><p>Embora caminhem de mãos dadas, o BCP e o DRP têm suas respectivas</p><p>funções e designações. Enquanto o DRP tem como meta voltar à</p><p>produção, o BCP visa voltar com a operação no status anterior ao</p><p>desastre. Em suma, o DRP é posto em ação quando o desastre está</p><p>em curso, já o BCP tem uma visão mais ampla e estrutura formas</p><p>58</p><p>alternativas para que o negócio continue a funcionar até que o desastre</p><p>seja controlado, diminuído ou eliminado Hintzbergen (2018).</p><p>Figura 2 – Plano de continuidade dos negócios</p><p>Fonte: designer491/ iStock.com.</p><p>3. Controles</p><p>Nas palavras de Cabral e Caprino (2015), a terceira etapa da gestão de</p><p>riscos é a definição e aplicação de controles. Esses controles afetam</p><p>diretamente o cálculo dos riscos, por meio da redução da probabilidade</p><p>de incidência ou do impacto da ameaça.</p><p>Os controles nem sempre estão atrelados à eliminação das</p><p>vulnerabilidades, mas nem sempre é este o propósito do controle.</p><p>Aplicar uma configuração de cluster a um servidor, por exemplo, não</p><p>elimina a vulnerabilidade do equipamento a falhas. No entanto, a falha</p><p>de um componente não causará o impacto relacionado à interrupção do</p><p>serviço, uma vez que os outros componentes do cluster poderão assumir a</p><p>carga de trabalho do componente que falhou. (CABRAL; CAPRINO, 2015, p.</p><p>41)</p><p>59</p><p>Uma forma de se chegar a uma medida de riscos é por meio de um</p><p>cálculo do risco baseado em uma expectativa anual de perda (ALE–</p><p>Annual Loss Expectancy). A ALE é gerada por meio da multiplicação de</p><p>uma ameaça (SLE–Single Loss Expectancy) por sua frequência (LF – Loss</p><p>Frequency) no intervalo</p>