Medir e melhorar controles de segurança, é só começar!

Chegou a hora de falarmos sobre métricas na gestão da segurança da informação. Este assunto sempre foi meio escanteado, já que parecia suficiente identificar riscos e implementar controles. Sabemos hoje (ou melhor, sempre soubemos) que não existe gestão de fato se não houver métricas e indicadores de performance.
Vamos falar um pouquinho sobre métricas. O conceito de métrica é amplamente utilizado na disciplina de administração (principalmente em mapas estratégicos e balanced scorecard) e em segurança da informação tem por fim identificar se estamos ou não sendo eficientes dentro do contexto de proteção de nosso negócio.

Duas categorias de métricas...

Existem dois grupos de métricas. Em primeiro lugar aparecem as métricas do sistema de gestão da segurança da informação, famoso SGSI. Estas métricas visam evidenciar se estamos girando o nosso PDCA adequadamente, no contexto da ISO 27001. São métricas relacionadas a gestão de riscos, de políticas, incidentes, ações corretivas e preventivas.

Controlar e mensurar!

Bom, o trabalho não para por aí. Alias, ele ainda está começando. Existe ainda um segundo grande grupo de métricas, que são as métricas de eficiência dos controles. A pergunta é simples “quão eficiente é o meu firewall, ou a minha política de senhas, na mitigação dos riscos identificados?”.

Para compor uma métrica você deve identificar indicadores de performance. Eu recomendo sempre a utilização de 5 indicadores de performance. Já é o suficiente.
Vamos ver como isso se comporta na prática. Primeiro escolhemos um controle qualquer, vou escolher o controle x.x.x da norma ISO 27002, que é a “Acordo de confidencialidade”. Propositalmente escolhi um controle que não é tecnológico, para poder ilustrar a dinâmica dessa medição fora do ambiente de TI.

Em primeiro lugar preciso identificar quem é o responsávelo pelo controle. Idealmente este controle é praticado pela área de recursos humanos, uma vez que esta área faz a ponte de contratação dos funcionários e muitas vezes de terceiros. Vamos considerar então que para este exemplo, nosso gestor de controle é a Gerente de RH.
Segundo passo, na medida do possível precisaremos de informações sobre a quantas anda este controle. Se é um controle novo, sem problema, não temos histórico e teremos que criar alguma referência com base em nossa experiência de mercado. Caso este controle já esteja sendo utilizado, existe algum dado, resultado ou não de auditoria, que possa nos dizer o quão eficiente ele é?

Imagine para uma empresa que tem um fluxo mensal de contratação de 100 profissionais, caso a área de recursos humanos fosse auditada, quantos acordos de confidencialidade eu poderia aceitar em estado de não conformidade? A resposta ecoa com um ZERO gritado a multidão, mas zero pode ser muito pouco, se este for um novo controle. Risco zero só existe quando o orçamento é infinito.

Sendo mais realista, proponho a seguinte escala de indicadores de performance para este controle:
1- Mais de 20 funcionários novos sem Acordo de Confidencialidade assinado
2- De 15 a 20 funcionários novos sem Acordo de Confidencialidade assinado
3- De 10 a 15 funcionários novos sem Acordo de Confidencialidade assinado
4- De 5 a 10 funcionários novos sem Acordo de Confidencialidade assinado
5- Até 5 funcionários novos sem Acordo de Confidencialidade assinado

Esta é uma escala, e não temos como negar. Agora precisamos escolher o indicador de eficiência esperada. Como o controle é novo, vou escolher o indicador 3. Com o passar do tempo posso apertar a eficiência esperada, porque nosso desejo é que com o passar do tempo, o PDCA cuide de reduzir o risco.

Crie uma agenda para o seu controle!

Qual o próximo passo? Já temos indicadores de performance para a nossa métrica de eficiência do contorle. Precisamos agora escolher uma periodicidade para que este controle seja revisado. A revisão não significa auditoria. O próprio gestor poderá informar o indicador de performance do seu controle.

Vamos definir então que este controle será medido bimestralmente. Você como Security Officer deve receber bimestralmente a revisão do controle que será avaliado pela própria gestora de RH. A auditoria, dentro de sua agenda, ficará responsável por validar estes resultados. Esta é uma maneira inteligente de envolver os gestores e de deixar todos antenados quanto a uma possível validação de resultados.
Passado um ano, podemos apertar mais a eficiência esperada, pulando para a de número 4, onde aceitaremos de 5 a 10 funcinoários novos sem NDA.

O ISMS Risk Management Software, nossa ferramenta para gestão de riscos e controles, faz isso de forma automática, atendendo aos critérios da norma ISO 27001 que demandam a medição periódica da eficiência dos controles. O melhor de tudo é que fornecemos medições on time. Este tipo de relatório permite que você meça a evolução ou involução dos controles x riscos.



Sem medo de me repetir, parafraseio a turma da qualidade, que reza “só podemos gerir aquilo que podemos medir, só podemos medir aquilo que controlamos”. Controles e métricas são a base da gestão da segurança da informação!

Gestão de Risco e Compliance: O que vem antes?

A grande dúvida que paira no ar, e que certamente ocupa o pensamento dos CIOs e CSOs em todo mundo é: o que vem antes, gestão de risco ou compliance? A resposta não é simples, mas é lógica. Convido vocês leitores a investir alguns minutos e desbravar comigo ponto-a-ponto, quais são os parametros que condicionam e direcionam esta decisão.

Compliance e Gestão de Risco são dos hits do momento. Nunca se falou tanto em manter a conformidade com padrões internacionais, ao mesmo tempo que estruturar processos para antecipar problemas (gerenciar o risco) parece ser a nova ordem. Como em tudo que é novo e onde falta informação, acabamos cometendo alguns enganos que podem comprometer o cumprimento de nossas metas.

Gestão de Risco

É mais simples do que parece. Gerenciar riscos é um processo que deve ser executado continuamente, deve ter pai e mãe (alguém tem que ficar formalmente responsável por conduzí-lo), e deve ser institucionalizado. A gerência do risco se divide em quatro partes: (i) identificar e avaliar os riscos (risk assessment), (ii) tratar os riscos (risk treatment), (iii) aceitar os riscos abaixo da linha de corte (risk acceptance) e (iv) comunicar os riscos (risk communication). Muita gente é boa em identificar e avaliar os riscos, mas peca na hora de definir controles para tratar os riscos e também na hora de comunicar aos interlocutores certos.

O que eu fiz de errado?

Como já escrevi em outros artigos, e sintetizo aqui, os erros mais comuns no gerenciamento do risco são:

Criar super planilhas com cálculos complexos para medição do índice do risco: em análise de risco, menos é mais. Simplifique ao máximo sua matriz, pois só assim você conseguirá transformar este processo em parte do dia-a-dia das pessoas. Não esqueça, risco é evento associado a sua probabilidade e seu impacto. Nada a mais, nada a menos.

Tomar as decisões sobre impacto e probabilidade, e sobre o tratamento do risco sem envolver os gestores e a alta direção: a decisão por tratar ou não um risco é da Alta Direção e das pessoas que responderão legalmente caso o risco torne-se um incidente. Esqueca análise de risco de gabinete, onde você identifica e você decide. Envolva as pessoas se você quer que elas participem do processo!

Confundir análise de risco com análise de vulnerabilidades: trate as vulnerabilidades como vulnerabilidades. Para corrigir bugs e aplicar patches, utilize o controle “gestão de vulnerabilidades” da ISO 27002 (antiga ISO 17799). Se você colocar vulnerabilidades tecnológicas e riscos em um mesmo nível, provavelmente enlouquecerá. Deixe as vulnerabilidades para as ferramentas de análise de vulnerabilidades, construa sua análise de risco em alto nível. Pense no negócio!

Compliance

Mais simples do que parece, estar “compliant” com algo é estar em conformidade. Conformidade com o que? Depende. As empresas precisam estar de acordo com a lei, sejam elas gerais ou específicas, como atos regulatórios ou acordos comerciais.

Uma norma ou lei é formada por um conjunto de asserções que indicam “boas práticas”, sejam elas recomendações ou obrigações. O procedimento através do qual sabemos se estamos ou não em conformidade com determinada lei é bem simples. Faz-se uma engenharia reversa e transformamos os itens da norma em questionamentos. Algo do tipo, digamos que a lei específica traga a seguinte resolução:

Resolução 1.1.1: A empresa deve possuir acordo de confidencialidae assinado com todos os funcionários e terceiros.

Transformamos em algo como:

A empresa possui um processo que garanta que são assinados acordos de confidencialidade com funcionários e terceiros? (Sim / Não ).

Este seria o primeiro nível da validação. Você pode ir além colocando uma escala de maturidade. Sempre tem quem quer ver para crer, ou seja, verificar se o controle está ou não aplicado para atender a norma. Cuidado para não transformar sua Gap Analysis em auditoria. A escolha é sua!

Onde encontrar checklists gratuitas?

Não entendo muito porque investir dinheiro em verificar a conformidade, acho que o dinheiro deve ser investido nos planos de ação para garantir a conformidade. Checklists de SoX, PCI-DSS, ISO 27002 entre outras, são facilmente encontradas na Internet. Dias atrás fui abordado por um conhecido em um evento de Segurança da Informação. Perguntou se eu podia ajudá-lo em um projeto de PCI-DSS e se poderíamos fazer uma Gap Analysis. Fizemos um teste e digitamos “pci-dss checklist” no Google. Logo nos primeiros links já tivemos acesso a pelo menos duas boas checklists que certamente atendiam ao seu objetivo.

Onde eu quero chegar?

Quero dizer a vocês que faz-se muito alarde em torno de processos simples. Complicamos desnecessariamente. Investimos tempo e dinheiro em tarefas que poderiam ser realizadas com três vezes menos tempo, e se fossem implementadas de forma simples, trariam um resultado muitas vezes mais visivel a Alta Direção. Não podemos querer implementar gestão de risco exigindo que nossos gestores de negócio, já preocupados com inúmeras tarefas, sejam especialistas em calcular o risco.

Finalmente, o que vem antes?

Nem um, nem outro. Conformidade e gestão de risco são complementares, e só alcançam seu resultado completo quando integrados. Como saber qual o nível de risco se eu não souber quais são os controles que eu já tenho implementado em meu ambiente? Como justificar a implementação deste ou daquele controle senão através de riscos?

Para quem não precisa atender a leis ou regulamentações específicas, tire o “compliance” de sua frente. Foque na gestão de risco. Porque querer saber se eu atendo aos controles da SoX se eu não preciso atender a SoX? Neste caso o contexto da "análise de gap" de melhores práticas pode ser direcionado aos padrões normativos internacionais, como é o caso da ISO 27002. O que não significa que eu tenho que aplicar todos os controles da norma. A análise de gap vai me dizer o quão aderente estou ao padrão, mas será a análise de risco que vai direcionar os controles que devo ou não implementar.

Sobre Declaração de Aplicabilidade

A Declaração de Aplicabilidade é uma listagem dos controles aplicados, e dos controles não aplicados. Ou seja, é uma listagem de TODOS os controles do Anexo A da ISO 27001, mais os controles adicionais.

Devem ser colocadas justificativas pela APLICAÇÃO e pela NÃO APLICAÇÃO dos controles.

Nosso colega Ediemerson corretamente informou que devem ser feitas referencias para os riscos que estão sendo tratados, devemos indicar aonde encontra-se documentada a aplicação do controle selecionado.

Atenção: não confundir o termo APLICADO com APLICAVEL. Somente podem ser justificado o controle como NÃO APLICAVEL, se realmente não for possível aplicá-lo, como por exemplo "comércio eletrônico" para uma empresa que não realiza comércio eletrônico. A justificativa deste controle é, NÃO APLICAVEL.

NÃO APLICADOS são aqueles controles pelos quais não se optou devido a inexistência de risco que o justificassem, por serem NÃO APLICAVEIS, ou pela sobreposição de controle. Isso é muito comum!

Gestão do risco ou gestão da vulnerabilidade?

Tenho investido um bom tempo em palestras, cursos, seminários e toda a sorte de evento relativo à segurança da informação (mais especificamente com o tema “gestão de risco”). Ao ter me envolvido tão intimamente com este tema, tive a oportunidade de conversar com muitos especialistas, conhecer diversas visões sobre o assunto, e resolver alguns entendimentos equivocados que muita gente traz em relação ao assunto.

Neste artigo vamos tratar sobre a diferença entre gestão de riscos e gestão de vulnerabilidades. Espero que definitivamente possamos chegar em um acordo consciente sobre o que é uma coisa e o que é outra.

Vamos direto ao ponto. Risco é um termo abrangente, que é utilizado por dezenas de disciplinas relativas a segurança. No contexto de Segurança da Informação risco é tudo aquilo que pode acontecer em um momento futuro, associado ao seu impacto potencial.

O risco pode ser interpretado como um evento. Evento é algo que pode acontecer, e que se efetivamente vier a acontecer, dará luz ao que conhecemos como “incidente”.
Bom, até aqui, nenhuma grande novidade. Um risco será composto de um evento associado a uma probabilidade e um impacto. Vejamos abaixo como representar isso em uma tabela:

Evento: Acesso não autorizado da equipe de desenvolvimento ao banco de dados de produção.
Probabilidade: Baixa
Conseqüência: Alta
Risco: Médio

A partir daqui compartilho com vocês algumas conclusões não tão óbvias.

Isso é risco ou vulnerabilidade?

O risco é uma combinação de fatores. Essa combinação de fatores geralmente é, em parte a identificação de uma ameaça, em outra parte a identificação de uma vulnerabilidade. Essa combinação, chamamos de evento. O evento só se evidencia quando nós temos um agente (ameaça) e uma vulnerabilidade (fraqueza). Na tabela do exemplo acima a ameaça seria um funcionário da equipe de desenvolvimento (talvez um mau funcionário), e a vulnerabilidade a falta de controle de acesso ao banco de dados de produção.

Esse é o contexto do risco para a norma ISO 27001. Uma visão abrangente, mas não profunda. Faço uma pergunta, faz sentido se tivéssemos avaliado apenas a vulnerabilidade ou apenas a ameaça?

Gosto de citar o exemplo de um cliente onde após uma análise de vulnerabilidades, identificou-se a necessidade de aplicar uma correção em determinado servidor, responsável por gerar certificados digitais. Ao conversar com o analista perguntei se existia algum tipo de conexão de rede àquele servidor; a resposta foi não. Perguntei então se existia mais alguém, além do administrador do equipamento, com acesso físico aquela máquina; a resposta foi outro não. Neste caso aplicar um patch corretivo seria mais arriscado do que deixar o servidor desatualizado, uma vez que o software gerador de certificados poderia entrar em conflito com o sistema operacional, até então estável.

Acredito em uma visão abrangente dos fatores de risco, inclusive para equipamentos de TI. Sinceramente não acho que um equipamento possua mais que 30 risco (não confundam com vulnerabilidades).

Vamos imaginar o caso hipotético onde um perpetrador utiliza uma vulnerabilidade no sistema operacional para invadir o servidor de web. Como este risco deveria ser escrito?

Evento: Acesso interno ou externo ao equipamento através de falhas no sistema operacional devido a não atualização ou aplicação de pacotes de atualização fornecidos pelo fabricante.
Probabilidade: Alta
Conseqüência: Alta
Risco: Alto

Neste caso, ao invés de identificarmos que o servidor possui uma falha na aplicação web, devemos tratar de forma conjunta todo o manancial de problemas técnicos relativos a este servidor. Digo mais, todas estas falhas deverão ser tratadas através da aplicação de um único controle

Este controle é indicado na norma ISO 27002 (antiga ISO 17799) como “12.6. Gestão de Vulnerabilidades”, cujo o objetivo é “prevenir os danos resultantes de vulnerabilidades conhecidas”. E aqui faço uma ressalva importante: é extremamente crítico que você possua uma forma de identificar se os seus sistemas operacionais, aplicações, ativos de conectividade e etc, estão com os devidos patchs aplicados. Só por favor, não confunda gestão de vulnerabilidades com gestão do risco.

Gestão de Risco: TI ou não TI? Eis a questão!

Eu não desisto de dizer, divulgar, promover e explicar que existe uma distância abismal entre gerenciar riscos no contexto da ISO 27001 e gerenciar vulnerabilidades tecnológicas. Para alguns de nós, segurança está associado a criptografia, VPN, firewall, IPS etc. Se você quiser gerir segurança a partir das melhores práticas, terá que deixar que TI cuide da aplicação dos controles tecnológicos necessários para mitigar os riscos, e focar sua inteligencia e tempo na gestão dos processos que permitirao a identificação sistemática de novos problemas, a indicação de alternativas para o tratamento do risco, e o monitoramento de oportunidades de melhoria e incidentes.

Menos é mais!

Em se tratando da gestão do risco, menos é mais. Quanto menos você entrar no detalhe, quanto menos você granularizar seus ativos (sempre recomendamos agrupá-los), quanto menos você investir tempo e esforço no baixo nível, maior será a abrangência da sua análise e maior será o seu resultado. Defendemos que o gerenciamento de risco possa ser realizado de forma simples, que seus resultados possam ser lidos e interpretados por executivos, que a matriz de risco possa ser atualizada sem muito esforço, e que os interlocutores no processo de gestão de risco consigam visualizar na matriz de risco da sua área, processo ou ativo, efetivamente, aquilo que de fato representa risco ao negócio da sua organização.

Identificação e Classificação de Ativos

Segue abaixo POST enviado para uma conhecida lista de discussão, onde tratei o assunto "Identificação e Classificação de Ativos".

O assunto "identificação e classificação de ativos" é de vital importância para qualquer empresa que deseja certificar na ISO 27001 ou mesmo estar de acordo com as melhores práticas internacionais em gestão da segurança da informação.

Para o pessoal que está entrando agora na área da Segurança da Informação, é importante definirmos o conceito de Ativo.

Ativo é tudo o que tem valor ou gera valor para minha empresa. Este é um termo que emprestamos do mundo financeiro/contabil, cujo antônimo é passivo.

Se "Ativo", neste contexto, é algo importante ou que gera valor para a minha organização, o que devemos considerar como ativo em Segurança da Informação?

Simples: tudo aquilo que por si só é importante (Informação) ou cujo seu papel pode afetar a segurança da informação (preservação da confidencialidade, integridade e disponibilidade).

Cerca de três anos atrás fiz um exaustivo estudo de identificação dos possíveis tipos de Ativos. Estudei o texto das principais normas de gestão de risco e segurança da informação com o objetivo de identificar classes de ativos (categorias) com o fim de estruturar melhor a organização dos ativos no contexto da gestão do risco. Esta para mim seria o primeiro passo rumo a configuração de uma ciência.

Seguem abaixo algumas das minhas conclusões:

1-) Sobre categorias de Ativos

As normas, em sua maioria, fazem referência a seis grandes grupos de ativos, que são:

a) Ativos de Informação: informação digital e em papel;
b) Ativos de Software: sistemas, aplicações, ferramentas e etc;
c) Ativos Físicos: dispositivos de processamento, armazenamento, ambientes e etc;
d) Serviços: serviços de computação, serviço de transporte de dados (aluguel de link), serviço de fornecimento de energia elétrica e etc;
e) Pessoas: funcionários, terceiros, estagiarios e etc;
f) Ativos Intangiveis: imagem da empresa, reputação, credibilidade, vantagem estratégica e etc.

Ufa! Chegar até aqui, acreditem, não foi fácil. Hoje estou satisfeito porque consigo classificar qualquer ativo em uma destas seis categorias. Esse pequeno primeiro passo foi importante para a estruturação do meu entendimento; entendimento de algo que até então parecia muito vago e sem método.

Subdividi estas seis categorias em outras 28 categorias, que subdividi por sua vez em 50 categorias. Com isso ganhei granularidade. A vantagem em classificar os ativos em subcategorias é o tempo que economizamos para atualizar nossa matriz de risco. Explico o porquê.

Imagine que você tenha um novo risco associado a "funcionários terceirizados", ao invés de correr sua matriz de risco em busca de ativos que façam referência a "funcionários terceirizados", basta categorizar o ativo nesta classe, e automaticamente inserir o novo risco para todo o ativo assim definido. Isso economiza algum tempo, e garantirá que o risco será replicado para toda a sua base de ativos onde houver "funcionário terceirizado".

2-) Não confunda Inventário de Ativo de Hardware e Software com Ativos de Negócio

Aqui vai uma outra questão muito importante. Muitas empresas com as quais tenho tido contato, confundem a necessidade de identificar e classificar Ativos relevantes para a organização, com o exercício de gerar imensas listas de ativos de hardware e software.

Como o colega Siera escreveu, a função do inventário de ativos é identificar aquilo que é importante para a empresa. É uma forma de colocar em foco o mais relevante, e investir tempo em análise e proteção daquilo que de fato faz diferença para o negócio. Não conheço ferramenta de inventário de software que catalogue pessoas, serviço de terceiros, imagem da empresa, ambientes físicos e etc. Ferramentas de inventário de hardware e software são muito boas para dar ao administrador uma visão do seu parque tecnológico, mas no meu ponto de vista, mais atrapalham do que ajudam no inventário de ativos do negócio.

3-) Agrupamento de Ativos

A regra de ouro da gestão da segurança é manter o processo o mais simples possível. Acreditem em mim, ja fiz análises quantitativas, qualitativas, mistas e tudo o mais que foi possivel, e o ensinameno que levo de tudo isso é que o processo de gestão da segurança só vai melhorar se acontecer repetidas vezes, e só vai acontecer repetidas vezes se for simples.

Algumas empresas (talvez ainda com essa visão de hardware e software) costumam listar exaustivamente os seus equipamentos de TI, para analisar seus riscos separadamente. Por exemplo: imagine uma empresa de desenvolvimentode software com 300 funcionários, todos utilizando estações de trabalho padrão. Faz sentido cadastrar 300 ativos e realizar uma análise de risco para cada ativo? Em minha opinião isso seria gastar tempo e intelecto em vão. Se isso já é estranho, imagina ainda empresas que analisam 600 roteadores :-)

Para esta caso o ideal é identificar e cadastrar apenas um ativo "Estações de Trabalho da Equipe de Desenvolvimento XPTO", e fazer UMA análise de risco, porque no final das contas, os controles aplicados a todas as estações serão os mesmos.

4-) Classificação de Relevância dos Ativos

Peça para o dono do Ativo indicar sua importancia em CID. Não esqueça do L, que é a Legalidade. Caso existam regulamentações que exijam a proteção do ativo, a aplicação do controle independe da análise de risco.

Gosto muito de classificar os ativos em 3 níveis de relevância: alto, médio ou baixo. Estou anexando um figura que mostra a valoração (valuaton) do ativo em cinco tipos.
Considerações finais:

Peço aos colegas e amigos que me perdoem se fui pouco didático ou se dei pouca atenção a esse ou aquele ponto. Espero sinceramente que este POST possa ajudar alguém que assim como eu, já passou ou está passando por um processo de certificação ISO 27001.

Ativo - Segunda Parte

Bom, poderia chamar este post de "Ativos - Além da Teoria, vamos a Prática". Porque pretendo, apesar de objetivo, passar por um dos pontos que mais costuma confundir o Security Officer interessado em atender a ISo 27001.

A questão é: quão granular devo ser para tratar os "ativos"? Devo considerar a caixa de e-mail do meu computador um ativo, ou o ativo é a minha workstation? Ou ainda, cada um dos computadores dos 750 funcionários do call-center são ativos diferentes? Se essas são as suas dúvidas não se desespere, 99 em 100 implantadores de ISO 27001 já passaram por estes dilemas "intelectuais".

A norma deixa claro que a organização deve identificar seus principais ativos. Quando escreve "principais ativos" não significa uma lista exaustiva dos ativos da organização. A única função de separarmos do joio os ativos importantes é garantir que a análise de risco será sobre aquilo que mais importa para a minha organização.

Quão profunda deve ser essa seleção? Neste, como em todos os outros critérios da norma, deve sempre imperar o bom senso. Se eu tenho 300 estações de trabalho da equipe do desenvolvimento, e julgo que os riscos aos 300 são os mesmos, basta que eu indique o ativo "Workstations da Equipe de Desenvolvimento". E lá vou eu em busca de 10, 20, 50 ou 100 riscos relacionados a este ativo.

É claro que se eu identificar um risco alto relacionado por exemplo ao vazamento de código fonte através de um serviço de webmail gratuito, vou aplicar o controle bloqueio de web para todas as estações do setor (não sejam assim tão maus!).

A regra é: faça uma boa análise de risco. Se para isso você tiver que entrar na peculiaridade do hardware, então faça. Nos meus muitos anos de praça nunca precisei, e acho que se tivesse feito, teria decuplicado o meu trabalho, além de tornar inviavel a perpetuação deste processo nas empresas dos meus clientes :-)

Ativo - Primeira Parte

A norma ISO 27001 deixa claro em seu texto, que a implementação do SGSI está focada em proteger os ativos importantes da organização. Mas afinal de contas, o que é um "ativo"?

Pra quem vem do mercado financeiro, ou pra quem opera no mercado de capitais, este termo é bem familiar. Ativo é tudo aquilo que tem valor ou gera valor para uma empresa.

Muitas vezes a turma de TI confunde ativo especificamente com componentes de tecnologia. É importante compreender que ativo é um termo muito mais abrangente.

Fiz uma análise das principais normas de segurança da informação: ISO 27001, ISO 13.335-1 e 2, ISO 17799 (ISO 27002) entre outras. O que percebi é que existe uma definição em comum entre estas normas, de que os ativos podem ser classificados em seis tipos. São eles:

1. Informação
2. Software e Sistemas
3. Pessoas
4. Serviços
5. Áreas ou Instalações Físicas
6. Intangíveis (imagem, credibilidade e etc)

Bom, então aqui vai a minha dica: quando forem analisar os riscos para determinado escopo, considerem agrupar tipos de risco para cada uma das categorias acima.

Classificação da Informação

Bom pessoal, este é um dos mais controversos controles do anexo A da ISO 27001. Literalmente você pode montar uma iniciativa complexa para classificar sua informação ou algo simples. Neste controle mais do que em qualquer outro é importante estar bem focado no negócio, para não criar um monstro capaz de devorar o próprio Security Officer.

Em primeiro lugar, creio que o termo correto, ao invés de CLASSIFICAÇÃO DA INFORMAÇÃO, deveria ser TRATAMENTO DA INFORMAÇÃO. Explico o porquê. Bom, em primeiro lugar entendo que a classificação da informação é apenas uma das facetas do tratamento da informação, que também deve considerar o "rótulo".

Vamos deixar isso mais simples. O que entendemos por Classificação da Informação é um processo que se divide em "Criação de Categorias de Informação" e "Definição de como rotular as informações". Isso tudo para tratar a informação considerada confidencial de maneira diferente da informação pública.

Exemplo: minha empresa pode ter três categorias de classificação, sendo (a) informação confidencial; (b) informação de uso interno; (c) informação pública. O bacana a partir da classificação é poder determinar como será tratada a informação confidencial quando for enviada por e-mail (na maioria dos casos só pode ser enviada se criptografada), ou até mesmo métodos de descarte de informações confidenciais em papel (que só será feito através de fragmentadora de papeis).

Mas para que serve a tal da classificação? Sabemos que proteção da informação é um recurso caro, classificar é uma forma racional de proteger melhor aquilo que é mais importante :-)

ISMS - Keep it simple!

Implementar um SGSI certificável pela ISO 27001 não é tarefa das mais fáceis. É um honroso emprego da inteligência na aplicação de melhores práticas que visam transformar a cultura de uma empresa e voltar a atenção do Board para a proteção da informação.

Proteção sistemática que deve se perpetuar.

Alguns "Indiana Jones" da segurança da infomração tem-se aventurado a inciar o processo de certificação nas empresas onde trabalham. O caminho é árduo quando se começa certo. O caminho é árduo e tortuoso quando logo de início calçamos o sapato apertado ou somos obrigados a andar rápido demais.

O mau planejamento de orçamento e a má definição do Escopo da certificação, tem sido os principais fatores de insucesso em projetos de ISO 27001. Explico.

1) Como estes projetos tendem a iniciar por TI, muitos gestores acreditam que a certificação é uma iniciativa que o ajudará a justificar a compra de 'n' softwares e appliances para proteção de dados. Em alguns casos sim, em outros casos não. Esquece o nosso gestor neófito que historicamente gastamos muito mais em educação e treinamento. Consulte a área de Qualidade de sua empresa para entender a abrangência do assunto.

2) Quando a definição de escopo, recomendo uma boa lida na norma ISO 27001, no item 4.2.1 item (a), que transcrevo abaixo:

a) Define the scope and boundaries of the ISMS in terms of the characteristics of the business, the organization, its location, assets and technology, and including details of and justification for any exclusions from the scope (see 1.2).

Recomendo veementemente que a consolidação do escopo seja feita com apoio de um especialista. Muitas empresas cometem erros venais quando definem como escopo uma área ligada a sistema ou infra-estrutura de TI. Para estes casos fica muito complicado identificar as interfaces com outras áreas de negócio, e se criarmos infinitas interfaces para isolar o escopo, corremos o risco de implementarmos o SGSI em um escopo de pouco valor para o negócio da organização. Não esqueça que a informação é dinâmica, e não estática.

Pense por vertical de negócio e não por horizontal ou backoffice.

TI e a Corrida para o Futuro - A Gestão de Riscos como Alternativa

Por Victor Hugo Menegotto, CISSP

Geralmente a corrida inicia em direção ao caminho mais fácil, que parece ser sempre o mais adequado, o menos custoso, e mais eficiente, quase tão bom quanto os maiores players do mercado. Afinal, se a Microsoft, a Cisco e a IBM seguem estes padrões, faremos o mesmo, é perfeito. Parece perfeito.

Perdi a conta do número de projetos encerrados e sem continuidade, perdi a conta do número de executivos que não se preocupou em gerir, medir e controlar, mas apenas em atender demandas externas ou exigências internas. E de fato, seus objetivos foram atingidos, mas para um período curto de tempo, a curto prazo, pois é assim que funciona nossa cultura. Não é a toa que os indianos possuem uma grande potência em TI, eles planejam a longo prazo, e quando começam a colher os frutos, a garantia de que terão frutos para um século é quase certa. O mais grave disso tudo, não é a garantia dos frutos que talvez não tenhamos, mas a concorrência - com planejamento e organização – que sem piedade, nos atropelará.

Então basta de atender demandas e exigências, esta na hora de planejar o futuro, participar da implantação de seja qual for a normativa, e principalmente, dar continuidade aos processos implementados. Essa é uma tarefa difícil, mas longe de impossível. Com participação, organização e as ferramentas certas, o processo se torna menos complexo. E às vezes até simples.

Mas afinal, que normativa devemos seguir?

Considerando ITIL (ISO 20000) e Cobit, como muito promissores, pelo menos 1 destes 2 é um “must have” para quase qualquer organização de médio à grande porte. Mas o principal ponto de investimento, não é especificamente nenhuma norma. E sim, a gestão de riscos, sejam eles financeiros, de mercado ou de segurança. Independente do risco, sua gestão é fundamental.

Ok, esta entendido, ITIL, Cobit e Gestão de Riscos, mas por onde começo?

Quando você compra um carro, qual a primeira coisa que você se preocupa?

a) Em como vai fazer para consertar alguns detalhes da pintura;
b) Em como vai fazer para trocar o som, as rodas e etc;
c) Com o seguro.

Não sei em relação a você, mas para mim a resposta parece muito simples, no seguro é claro. E é neste ponto que assino embaixo da Gestão de Riscos, que irá nos proporcionar a alternativa para o seguro - o controle. A gestão de riscos vai nos dizer, quais são os problemas, vai elencá-los, vai tratá-los, e vai medí-los. Provendo a gerencia completa sobre nossos processos. Sem dúvida, a gestão de riscos deve ser o ponto de partida para qualquer executivo de TI.

E por favor, não esqueça: não basta analisar os riscos, você deve gerí-los, acompanhá-los, controlá-los e aí sim, terá gerência sobre Tecnologia da Informação e seus processos de negócio.