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!
Monday, August 6, 2007
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)