The PCI Data Security Standard (PCI DSS) consists of 12 mandatory high-level requirements for all organizations that store, transmit, or process payment cards. These 12 requirements are further subdivided into sections, describing activities that organizations must engage in while managing their networks, administering their systems, and, in general protecting the payment card data with which they have been entrusted.
While PCI DSS details compliance requirements in most areas, its directives make only passing reference (if at all) to an overall security framework into which the required actions must fit. If organizations simply follow the PCI DSS blindly, they may not achieve the overall security goals.
ISO 27002, also known as ISO 17799, is a security standard of practice. In other words, it is a comprehensive list of security practices that can be applied -- in varying degrees -- to all organizations. The benefit of such a standard to organizations attempting to comply with the PCI-DSS is twofold. First, it provides a framework that allows organizations to achieve their PCI security goals along with those from other sources, like industry or governmental regulations. Second, it provides guidance on how to fit some of PCI's governance and policy requirements into an organization's compliance program.
For example, ISO 27002 discusses the necessity of involving business, management, human resources and technology representatives in the security program. It also provides references for high-level policies for important areas such as data classification, data handling and access control. While PCI DSS describes specific technical practices and organizational activities, it doesn't talk about the overall program in which these activities exist or the specific policies that require these activities.
When a company establishes a program based on a broad standard like ISO 27002, it can treat the PCI-DSS requirements as a subset of those required by the ISO. Further, a program structured according to ISO 27002 will require organizations to employ critical support systems required by many regulations (and PCI DSS in particular). For example, ISO 27002 requires change control in network administration, system configuration, policy management, procedure management and software development. PCI DSS calls out the need for accurate diagrams and documentation for its network and systems as well as change control processes to ensure discipline in administration of the PCI DSS-related components.
ISO 27002's broad requirements for change control associated with all aspects of administration encourage a consistent approach across an enterprise. This kind of approach, when applied to PCI DSS, would help improve both the consistency, effectiveness and efficiency of change control across a company and increase the likelihood that an auditor would find a company's practices acceptable.
Another benefit of combining the structure of ISO 27002 and the specific requirements of PCI DSS is that the PCI DSS helps organizations define three of the most challenging aspects of ISO compliance: scope of compliance, data classification and data handling. Armed with these constraining requirements, organizations can define policies and procedures that are consistent with best practice as specified by ISO and directly address PCI DSS compliance. For example, PCI DSS defines what aspects of credit card data are sensitive. It describes access control requirements for credit card information, encryption requirements for transmission and storage, and even the testing necessary to verify effectiveness of controls. These specific requirements allow organizations to state how systems must be configured, how employees must treat data and how an organization monitors the effectiveness of its controls.
A growing number of organizations are building security programs according to standard frameworks like ISO 27002. These frameworks are allowing organizations to factor compliance with multiple regulations and contracts into their security programs in a consistent and effective manner.
The beauty of using the ISO standard with specific regulations is that the regulations fill in the necessary details that the framework lacks while the framework provides structure to address multiple sets of requirements consistently. The two concepts work hand in hand and provide effectiveness, efficiency and auditability.
About the author:Richard E. "Dick" Mackey is regarded as one of the industry's foremost authorities on security and compliance. He is a frequent speaker and contributor to magazines and online publications. He has advised leading financial firms on compliance with PCI, GLBA and SOX. He has also provided guidance to a wide range of companies on enterprise security architectures, identity and access management and security policy and governance.
Tuesday, January 29, 2008
Thursday, January 24, 2008
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
Tuesday, January 15, 2008
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!
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!
Monday, December 17, 2007
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!
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!
Wednesday, October 17, 2007
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.
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.
Monday, August 6, 2007
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!
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.
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.
Subscribe to:
Posts (Atom)