ISMS Standards

New ISO series of 27000 standards

• ISO/IEC 27000 Fundamentals and vocabulary
• ISO/IEC 27001 ISMS - Requirements (revised BS 7799 Part 2:2005) - Published 15th Oct 2005
• ISO/IEC 27002 Code of practice for information security management as from April 2007 -currently ISO/IEC 17799:2005, published 15th June 2005
• ISO/IEC 27003 ISMS implementation guidance (under development)
• ISO/IEC 27004 Information security management measurement (under development)
• ISO/IEC 27005 Information security risk management (based on and incorporating
• ISO/IEC 13335 MICTS Part 2) (under development)
• ISO/IEC 27006 Requirements for bodies providing audit and certification of information security management systems - Published 15th February 2007
• ISO/IEC 27007 Guidelines for information security management systems auditing (under development)
  

ISMS Specifications

• ISO/IEC 27001:2005 ISMS - Requirements (revised version of BS 7799-2:2002 Information security management systems – specification with guidance for use.)
• ISO 9001:2000 Quality Management Systems – Requirements

Auditing Standards

• ISO 19011:2002, Guidelines on Quality and/or Environmental Management Systems Auditing

Accreditation Standards

• ISO/IEC 17021 Conformity Assessment – Requirements for bodies providing audit and certification of management systems
• ISO/IEC 27006 Requirements for bodies providing audit and certification of information security management systems

Control Standards

• ISO/IEC 27002:2005 Code of practice for information security management

From: TQMC

From now on, Axur Blog will be published only in English!

From now on, we decide to post only in english. English will be our official language. Why to do so?

1-) We believe ISO 27001 is a worlwide stuff. It's very important to share our experience in ISO 27001 implementation and management with all consultants around world.

2-) Starting march, Axur ISMS will be delivered in English, and we need to communicate with our clients.

3-) English is an universal language. Looks like a kind of "successfully Esperanto".

Axur Team!

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.