ISO 27001 & BS 25999

Já aconteceu de sua gestão dar-lhe a responsabilidade de implementar a continuidade de negócios só porque você está no departamento de TI? Por que a continuidade de negócios normalmente está relacionada à tecnologia da informação?

Isto provavelmente acontece porque a continuidade de negócios tem suas raízes na recuperação de desastres, e a recuperação de desastres está totalmente ligada à tecnologia da informação. Vinte ou trinta anos atrás, a continuidade de negócios (CN) ainda não existia como um conceito, mas a recuperação de desastres (RD), sim – a principal preocupação era como salvar os dados caso ocorresse um desastre. Naquela época era muito comum adquirir equipamentos caros e colocá-los em um local remoto, de modo que todos os dados importantes de uma organização fossem preservados se, por exemplo, acontecesse um terremoto. O objetivo não era apenas preservar os dados, mas também processá-los mais ou menos com a mesma capacidade do local principal.

Mas depois de algum tempo, percebeu-se que esses dados seriam inúteis se não houve operações comerciais para utilizá-los. Foi assim que a ideia da continuidade de negócios nasceu – sua finalidade é permitir que a empresa continue funcionando, mesmo no caso de uma grande interrupção.

Definições

Vamos dar uma olhada nas definições: a continuidade de negócios é a “capacidade estratégica e tática da organização de se planejar e responder a incidentes e interrupções de negócios para conseguir continuar suas operações em um nível aceitável previamente definido” (BS 25999-2:2007), enquanto que a recuperação de desastres é “o processo, as políticas e os procedimentos relacionados à preparação para recuperação ou manutenção da infraestrutura tecnológica essencial para uma organização após um desastre natural ou induzido pelo homem” (Wikipedia.org).

Como você pode perceber a partir das definições, a ênfase na RD é a tecnologia, enquanto que na CN são as operações comerciais. Portanto, a recuperação de desastres é parte da continuidade de negócios. Você pode considerá-la como uma das principais possibilitadoras das operações comerciais, ou a parte tecnológica da continuidade de negócios.

No entanto, você deve ter notado outra coisa também: a definição de CN é uma citação da BS 25999-2, a principal norma em gestão da continuidade de negócios, enquanto que a definição da RD é citada da Wikipédia – na verdade, a “continuidade de negócios” é um termo oficial reconhecido nas normas, enquanto que a “recuperação de desastres” não é.

Implicações para a implementação

Então por que é uma má ideia o departamento de TI implementar a continuidade de negócios para toda a organização? Porque a continuidade de negócios é essencialmente uma questão comercial, não uma questão de TI. Se o departamento de TI fosse implementar a continuidade de negócios em toda a organização, ele não seria capaz de definir o grau de emergência das atividades comerciais, nem a importância das informações. Além disso, é uma questão de saber se iria conseguir obter o compromisso das partes comerciais da organização.

A melhor maneira de organizar a implementação da CN é a parte comercial liderar esse projeto. Assim você poderia conseguir uma maior consciência e aceitação de todas as partes da organização. O departamento de TI deve desempenhar seu papel nesse projeto – um papel fundamental – preparar os planos de recuperação de desastres.

Você também pode conferir o webinar BS 25999-2 Foundations Part 1: Business Impact Analysis (treinamento vendido comercialmente).

O Anexo A da ISO 27001 provavelmente é o anexo mais mencionado de qualquer norma de gestão. Por que se fala tanto sobre isso? Por que, às vezes, ele é polêmico?

Se você leu o Anexo A, sabe que há 133 controles de segurança listados. Se esse é o caso, para que serve a parte principal da norma?

O objetivo

O Anexo A contém as seguintes cláusulas (às vezes chamadas de domínios do Anexo A da ISO 27001):

• A.5 Política de segurança
• A.6 Organizando a segurança da informação
• A.7 Gestão de ativos
• A.8 Segurança em recursos humanos
• A.9 Segurança física e do ambiente
• A.10 Gerenciamento das operações e comunicações
• A.11 Controle de acessos
• A.12 Aquisição, desenvolvimento e manutenção de sistemas de informação
• A.13 Gestão de incidentes de segurança da informação
• A.14 Gestão da continuidade do negócio
• A.15 Conformidade

Como já foi mencionado, o Anexo A contém 133 controles que, como pode ser visto a partir dos nomes das cláusulas, não estão focados apenas em TI. Eles também abrangem a segurança física, a proteção jurídica, a gestão de recursos humanos, as questões organizacionais etc.

Portanto, você pode considerar o Anexo A como uma forma de catálogo de medidas de segurança para ser utilizado durante o processo de tratamento. Depois de identificar os riscos inaceitáveis na avaliação de riscos, o Anexo A irá ajudá-lo a escolher os controles corretos para diminuir esses riscos. E garantir que você não esqueça de nenhum controle importante.

O Anexo A é onde a ISO 27001 e a ISO 27002 se unem. Os controles da ISO 27002 são nomeados da mesma forma que no Anexo A da ISO 27001, mas a diferença está no nível de detalhamento. A ISO 27001 fornece apenas uma curta definição de um controle, enquanto a ISO 27002 fornece diretrizes detalhadas sobre como implementar o controle.

Desvantagens

Se até agora você está pensando que o Anexo A é uma ferramenta de implementação perfeita para seu projeto de segurança da informação, não seja tão otimista, ele também tem algumas coisas que não fazem muito sentido. Por exemplo, alguns controles definem quase os mesmos problemas, o que às vezes causa confusão, como o A.9.2.6 (Reutilização e alienação segura de equipamentos) e o A.10.7.2 (Descarte de mídias). Por outro lado, algumas questões, como as relações com terceiros, estão espalhadas por várias cláusulas do Anexo A – você pode encontrar esse assunto nas cláusulas A.6.2 (Partes externas), A.8 (Segurança em recursos humanos) e A.10.2 (Gerenciamento de serviços terceirizados), e no controle A.12.5.5 (Desenvolvimento terceirizado de software). Isso, às vezes, torna o Anexo A uma ferramenta de implementação difícil de usar.

Mas nem sempre são apenas ambiguidades – em alguns controles, o Anexo A menciona políticas e procedimentos, no entanto, não exige que sejam documentados. Pode parecer estranho, mas apenas quando a palavra “documentado” aparece é que a norma exige políticas/procedimentos escritos. Quando você analisa todo o Anexo A, ele menciona a palavra “documentado” em apenas 6 controles (A.5.1.1, A.7.1.3, A.8.1.1, A.10.1.1, A.11.1.1, A.15.1.1). Isso significa que você pode implementar todos os outros controles sem documentá-los.

No entanto, você não deve abusar dessa flexibilidade do Anexo A – quanto maior a organização, mais documentos devem ser produzidos, a fim de garantir que todos estejam cientes dos (e cumpram com os) procedimentos de segurança. Por outro lado, você deve ter cuidado para não exagerar na documentação, se esta for excessiva, ninguém irá estudá-la.

Relação com a parte principal da ISO 27001

A parte principal da norma ou, mais precisamente, as cláusulas obrigatórias de 4 a 8 contêm a parte de gestão da norma. Essas cláusulas descrevem o ciclo PDCA (Plan-Do-Check-Act ou Planejar-Fazer-Verificar-Agir), incluindo a avaliação e o tratamento de riscos, o controle da documentação, o controle de registros, o fornecimento de recursos, a auditoria interna, a análise crítica da gestão, as ações corretivas e preventivas etc.

Como dito anteriormente, o processo de avaliação e tratamento de riscos é a principal ligação entre as cláusulas 4 a 8 e os controles do Anexo A – ele irá ajudá-lo a decidir se os controles individuais do Anexo A são necessários para diminuir os riscos ou não.

Isso significa que as cláusulas 4 a 8 e o Anexo A não podem existir um sem o outro. A avaliação de riscos não faz sentido se não houver controles para diminuir os riscos, e a única maneira de determinar a aplicabilidade dos controles é por meio da avaliação de riscos.

Na minha opinião, esse foco nos riscos e a flexibilidade de aplicar controles de segurança de acordo com o que você considera conveniente são as melhores coisas da ISO 27001 – você só precisa ter o cuidado de tirar o máximo proveito disso.

Você também pode conferir o webinar ISO 27001 Foundations Part 3: Annex A overview (treinamento vendido comercialmente).

Você já ouviu algo como “Não pode ser feito”, “Isso não tem utilidade”, ou “É inútil se um grande desastre acontecer”? Se você implementou a gestão de continuidade de negócios, provavelmente já ouviu. Naturalmente, essa atitude não ajuda em seu projeto, por isso aqui estão algumas sugestões de como lidar com essas pessoas.

“Se um grande desastre acontecer, não seremos capazes de fazer nada”

Esta provavelmente é a mais comum. Bem, eles podem estar certos, a menos que você realmente tenha preparado a sua estratégia de continuidade de negócios e os planos de continuidade de negócios tendo em conta todos os cenários possíveis. Se você fez isso, então pode explicar para eles que preparou um local alternativo distante o suficiente para suportar qualquer tipo de desastre, que você fez uma cópia de segurança dos dados, que há um substituto para qualquer funcionário da empresa, que tem fornecedores alternativos para qualquer serviço crítico etc.

“Se uma guerra nuclear irromper, isso não vai funcionar”

Bem, a menos que você seja um fornecedor das forças armadas, isso não importa, não é verdade? Basicamente, nesse tipo de cenário catastrófico, sua empresa provavelmente não teria mais uma finalidade.

“Isso não tem utilidade”

Espero sinceramente que você nunca precise usar a continuidade de negócios. Mesmo sem mencionar exemplos bem-conhecidos como o 11 de setembro ou o furacão Katrina, basta perguntar: você já passou por uma pane elétrica? Ou o seu servidor já teve uma pane? Ou talvez um computador com dados importantes? Você já ouviu falar de algum edifício que queimou completamente? Basta ler as manchetes dos jornais para entender que essas coisas podem acontecer a qualquer um.

“Faremos isso somente para satisfazer o auditor”

Prioridade errada. Se você fizer isso corretamente, estará se protegendo e, como consequência, o auditor ficará contente.

“Não podemos prever todos os incidentes”

Isso é verdade, pelo menos no início. Mas se você executar sua avaliação de riscos corretamente, usar livros especializados e vários recursos e analisar a avaliação regularmente, é muito provável que com o tempo você seja capaz de considerar todos os riscos possíveis. Depois de conhecê-los, você pode preparar sua resposta.

“Em caso de emergência, as pessoas irão querer cuidar de suas famílias, não da empresa”

Isso também é verdade. Quem não ligaria primeiro para sua família para ver se está tudo bem no caso de um terremoto? Mas se você planejar cuidadosamente quem pode ir direto para casa depois de um incidente e quem deve ficar e resolver a situação, e se você cuidar da família dos funcionários que devem permanecer na empresa (por exemplo, atribuindo essa tarefa a algum outro funcionário), então, provavelmente, você já resolveu esse problema.

“As pessoas reagem irracionalmente em situações de crise”

Definitivamente, isso é verdade. Mas se você treinar seus funcionários (e fornecedores/parceiros) regularmente e exercitar seus planos de continuidade de negócios, eles irão se acostumar com situações estressantes e provavelmente irão responder da maneira certa, se tais situações ocorrerem.

Se você já implementou projetos parecidos, sabe como a conscientização é importante. Se seus colegas não reconhecerem os propósitos desses projetos, você terá grandes dificuldades com a implementação. Sem mencionar que seu projeto pode fracassar por completo. É por isso que você precisa considerar o trabalho de conscientização com antecedência.

Você também pode conferir o webinar BS 25999-2 Foundations Part 2: Business Continuity Strategy (treinamento vendido comercialmente).

Se você está começando a implementar a ISO 27001, provavelmente está procurando uma maneira fácil de fazer isso. Deixe-me desapontá-lo: não há maneira fácil de fazer isso. No entanto, vou tentar facilitar seu trabalho. Aqui está uma lista com os dezesseis passos que você tem de executar se quiser obter a certificação ISO 27001:

1. Obter o apoio da gerência

Isso pode parecer bastante óbvio e, normalmente, não é levado muito a sério. Mas, na minha experiência, este é o principal motivo do fracasso dos projetos de ISO 27001: a gerência não fornece um número suficiente de pessoas para trabalhar no projeto ou fornece pouco dinheiro. (Leia Quatro benefícios fundamentais da implementação da ISO 27001 para obter ideias de como apresentar o caso à gerência.)

2. Tratar como um projeto

Como já foi dito, a implementação da ISO 27001 é complexa, envolve várias atividades, muitas pessoas e dura vários meses (ou mais de um ano). Se você não definir claramente o que deve ser feito, quem vai fazê-lo e em que período de tempo (ou seja, aplicar gestão de projetos), você pode nunca terminar o trabalho.

3. Definir o escopo

Se você tem uma organização grande, provavelmente faz sentido implementar a ISO 27001 em apenas uma parte da organização, reduzindo significativamente o risco do projeto. (Problemas com a definição do escopo da norma ISO 27001)

4. Escrever uma política do SGSI

A Política do SGSI é o documento de mais alto nível em seu SGSI. Ela não deve ser muito detalhada, mas deve definir algumas questões básicas da segurança da informação em sua organização. Mas qual é o seu objetivo se não é detalhada? O objetivo é que a gerência defina o que deseja alcançar e como controlar isso. (Política de segurança da informação: o quão detalhada deve ser?)

5. Definir a metodologia da avaliação de riscos

A avaliação de riscos é a tarefa mais complexa do projeto da ISO 27001. O objetivo é definir as regras para a identificação de ativos, vulnerabilidades, ameaças, impactos e probabilidade, e definir o nível de risco aceitável. Se essas regras não forem claramente definidas, você pode se encontrar em uma situação em que obterá resultados inutilizáveis. (Leia Dicas de avaliação de risco para pequenas empresas.)

6. Realizar avaliação de riscos e tratamento de riscos

Aqui você tem de implementar o que definiu no passo anterior. Isso pode demorar vários meses para organizações grandes, então você deve coordenar esse esforço com muito cuidado. O objetivo é obter uma visão abrangente sobre os perigos para a informação da sua organização.

O propósito do processo de tratamento de riscos é diminuir os riscos que não são aceitáveis. Isso geralmente é feito pelo uso dos controles do Anexo A.

Nesta etapa, deve-se escrever um Relatório de avaliação de riscos, que documente todos os passos dados durante os processos de avaliação de riscos e tratamento de riscos. Além disso, deve-se obter a aprovação dos riscos residuais, seja como um documento separado ou como parte da Declaração de aplicabilidade.

7. Escrever a Declaração de aplicabilidade

Depois de terminado o processo de tratamento de riscos, você saberá exatamente quais controles do Anexo A precisará (há um total de 133 controles, mas você provavelmente não precisará de todos eles). O objetivo deste documento (frequentemente referido como SoA) é listar todos os controles e para definir quais são aplicáveis e quais não são, e as razões para essa decisão, os objetivos a serem alcançados com os controles e uma descrição de como eles serão implementados.

A Declaração de aplicabilidade também é o documento mais adequado para obter autorização da gerência para implementar o SGSI.

8. Elaborar o Plano de tratamento de riscos

Quando você pensou que já havia resolvido todos os documentos relacionados aos riscos, aparece mais um. O objetivo do Plano de tratamento de riscos é definir exatamente como os controles do SoA devem ser implementados – quem irá fazer o trabalho, quando, com que orçamento etc. Esse documento é, na verdade, um plano de implementação focado em seus controles, sem o qual você não seria capaz de coordenar os próximos passos do projeto.

9. Definir como medir a eficiência dos controles

Outra tarefa que frequentemente é subestimada. A questão aqui é: se você não pode medir o que você fez, como pode ter certeza de ter cumprido o objetivo? Portanto, não se esqueça de definir a forma como você irá medir o cumprimento dos objetivos que definiu, tanto para o SGSI inteiro quanto para cada controle aplicável na Declaração de aplicabilidade.

10. Implementar os controles e procedimentos obrigatórios

É mais fácil falar do que fazer. É aqui que você deve aplicar os quatro procedimentos obrigatórios e os controles aplicáveis do Anexo A.

Esta geralmente é a tarefa mais arriscada do seu projeto. Ela normalmente envolve a aplicação de novas tecnologias, mas acima de tudo, a implementação de novos comportamentos na organização. Muitas vezes, novas políticas e procedimentos são necessários (o que significa que uma mudança é necessária), e as pessoas geralmente resistem à mudança – é por isso que a próxima tarefa (treinamento e conscientização) é crucial para evitar esse risco.

11. Implementar programas de treinamento e conscientização

Se você deseja que sua equipe implemente todas as novas políticas e procedimentos, primeiro você tem de explicar a eles porque isso é necessário e treiná-los para serem capazes de trabalhar como previsto. A ausência dessas atividades é a segunda razão mais comum para o fracasso do projeto da ISO 27001.

12. Operar o SGSI

Esta é a parte em que a ISO 27001 torna-se uma rotina diária da sua organização. A palavra crucial aqui é: “registros”. Auditores amam registros – sem registros será muito difícil provar que qualquer atividade foi realmente executada. Mas, em primeiro lugar, os registros devem ajudá-lo – com eles você pode monitorar o que está acontecendo – você saberá com certeza se seus funcionários (e fornecedores) estão realizando suas tarefas como exigido.

13. Monitorar o SGSI

O que está acontecendo em seu SGSI? Quantos incidentes você tem, de que tipo? Todos os procedimentos são executados corretamente?

É aqui que os objetivos para seus controles e metodologia de medição se unem: você tem de verificar se os resultados obtidos estão alcançando o que você definiu em seus objetivos. Se não estão, você sabe que algo está errado e que precisa executar ações corretivas e/ou preventivas.

14. Realizar auditoria interna

Muitas vezes as pessoas não estão cientes de que estão fazendo algo errado (por outro lado, algumas vezes elas sabem, mas não querem que ninguém descubra isso). Mas desconhecer problemas existentes ou possíveis pode prejudicar sua organização. Você precisa realizar auditorias internas para descobrir essas coisas. O objetivo aqui não é iniciar ações disciplinares, mas tomar ações corretivas e/ou preventivas. (Leia Dilemas com os auditores internos das normas ISO 27001 e BS 25999-2.)

15. Executar análise crítica da gestão

A gerência não tem de configurar o firewall, mas deve saber o que está acontecendo no SGSI, ou seja, se todos realizaram suas funções, se o SGSI está obtendo os resultados desejados etc. Com base nisso, a gerência deve tomar algumas decisões cruciais.

16. Ações corretivas e preventivas

O objetivo do sistema de gestão é assegurar que tudo o que está errado (as chamadas “inconformidades”) seja corrigido ou, de preferência, prevenido. Portanto, a ISO 27001 exige que as ações corretivas e preventivas sejam realizadas de forma sistemática, o que significa que a causa básica de uma inconformidade deve ser identificada e, então, resolvida e verificada.

Espero que este artigo tenha esclarecido o que precisa ser feito, pois apesar de a ISO 27001 não ser uma tarefa fácil, ela não é necessariamente complicada. Você só precisa planejar cada passo com cuidado e, não se preocupe, você irá obter seu certificado.

Aqui você pode baixar o diagrama do Processo de implementação da ISO 27001, que mostra todas essas etapas, juntamente com a documentação exigida.

Você provavelmente já sabia que o primeiro passo para a implementação da ISO 27001 é a definição do escopo. O que você provavelmente não sabia é que esta etapa, apesar de parecer simples à primeira vista, às vezes pode causar uma porção de problemas. Ou seja, muitas empresas estão tentando diminuir os custos de sua implementação diminuindo escopo, mas muitas vezes se encontram em uma situação em que esse escopo é uma verdadeira dor de cabeça.

Então, onde está o problema?

O problema quando o escopo da ISO 27001 não é toda a organização é que o Sistema de gestão da segurança da informação (SGSI) deve ter interfaces com o mundo “exterior”; nesse contexto, o mundo exterior não são apenas os clientes, parceiros, fornecedores etc., mas também os departamentos da organização que não estão dentro do escopo. Pode parecer estranho, mas um departamento que não esteja dentro do escopo deve ser tratado da mesma forma que um fornecedor externo.

Por exemplo, se você escolher que somente o departamento de TI estará dentro do escopo, e esse departamento estiver utilizando os serviços do departamento de compras, o departamento de TI deve efetuar a avaliação de riscos do seu departamento de compras para identificar se existem riscos para as informações pelas quais o departamento de TI é responsável, além disso, os dois departamentos devem assinar termos e condições para os serviços prestados.

Por que tal sobrecarga é necessária? Você tem de se colocar no lugar do organismo de certificação, pois este deve certificar que dentro dos seu escopo, você é capaz de lidar com as informações de forma segura, embora não possa verificar nenhum dos departamentos fora do escopo. A única maneira de lidar com essa situação é tratar os departamentos como se fossem empresas externas. (Atenção: os auditores de certificação nunca gostam de escopos pequenos.)

Os problemas não param por aqui. Às vezes, escopos pequenos simplesmente não são possíveis, porque não há uma interface com o mundo exterior. Por exemplo, se os funcionários de dentro e de fora do escopo trabalham na mesma sala, esse escopo é pouco viável; se tanto os funcionários de dentro do escopo quanto os de fora utilizam a mesma rede local (sem discriminação) e têm acesso a vários serviços de rede, esse escopo definitivamente não é possível, pois não há como controlar o fluxo de informações somente dentro do escopo.

Ou seja, diminuir escopo do SGSI às vezes é impossível, e na maioria dos casos isso irá lhe trazer uma sobrecarga desnecessária. Portanto, o que inicialmente não parecia ser uma boa solução, pode ser a melhor opção no final. Tente estender seu escopo a toda a organização. A regra geral é: se sua organização não tem mais do que algumas centenas de funcionários e uma ou apenas algumas sedes, o melhor seria o SGSI abranger toda a organização.

Por outro lado, se você realmente não pode abranger toda a organização dentro do escopo do SGSI, tente defini-lo em uma unidade organizacional que seja suficientemente independente; tente resolver as relações com as outras unidades organizacionais de fora do escopo, determinando seu serviço por meio de documentos internos (políticas, procedimentos etc.), que serviriam de “acordos”; de tal forma que você poderia documentar as obrigações dessas unidades organizacionais de uma maneira que seja utilizável nas operações diárias.

Pronto! Você já resolveu o primeiro passo da implementação da ISO 27001.

Você também pode conferir o tutorial em vídeo Como definir e documentar o escopo do SGSI de acordo com a ISO 27001 (vídeo vendido comercialmente).

Se você se deparou com a ISO 27001 e a ISO 27002, provavelmente notou que a ISO 27002 é muito mais detalhada, muito mais precisa. Então, qual é o propósito da norma ISO 27001?

Em primeiro lugar, você não pode obter a certificação ISO 27002 porque ela não é uma norma de gestão. O significa ser uma norma de gestão? Significa que essa norma define como administrar um sistema. No caso da ISO 27001, ela define o sistema de gestão da segurança da informação (SGSI), portanto, a certificação para a ISO 27001 é possível.

Esse sistema de gestão significa que a segurança da informação deve ser planejada, implementada, monitorada, analisada e aperfeiçoada. Significa que a gestão tem suas responsabilidades definidas, que os objetivos devem ser estabelecidos, medidos e analisados, que deve haver auditorias internas e assim por diante. Todos esses elementos são definidos na norma ISO 27001, mas não na ISO 27002.

Os controles da ISO 27002 tem os mesmos nomes do Anexo A da ISO 27001. Por exemplo, na norma ISO 27002 6.1.6, o controle é chamado de Contato com autoridades, enquanto na norma ISO 27001 é A.6.1.6 Contato com autoridades. Porém, a diferença está no nível de detalhamento – em média, a ISO 27002 explica um controle em uma página inteira, enquanto a ISO 27001 dedica apenas uma frase para cada controle.

Por fim, a diferença é que a ISO 27002 não faz distinção entre os controles aplicáveis a uma determinada organização, e aqueles que não são. Por outro lado, a ISO 27001 determina uma avaliação de riscos a ser executada a fim de identificar, para cada controle, se ela é necessária para diminuir os riscos, e se for, em que medida deve ser aplicada.

A pergunta é: por que essas duas normas existem separadamente, porque não foram fundidas, reunindo os lados positivos de ambas as normas? A resposta é a usabilidade: se fosse uma única norma, ela seria muito complexa e muito grande para uso prático.

Cada norma da série ISO 27000 é projetada com um determinado foco. Se você quiser construir os alicerces da segurança da informação em sua organização e definir sua estrutura, deve usar a ISO 27001; se você quiser implementar controles, deve usar a ISO 27002; se você quiser realizar avaliação de riscos e tratamento de riscos, deve usar a ISO 27005 etc.

Para concluir, poderíamos dizer que, sem os detalhes fornecidos na norma ISO 27002, os controles definidos no Anexo A da ISO 27001 não poderiam ser implementados. Porém, sem estrutura de gestão da ISO 27001, a ISO 27002 permaneceria apenas como um esforço isolado de alguns entusiastas da segurança da informação, sem aceitação da alta administração e, portanto, sem impacto real sobre a organização.

Você também pode conferir o webinar ISO 27001 Foundations Part 3: Annex A overview (treinamento vendido comercialmente).

Alguma vez você já tentou convencer sua gerência a financiar a implementação da segurança da informação? Se você já tentou, provavelmente sabe como funciona: eles vão lhe perguntar quanto custa, e se parecer muito caro eles irão dizer que não.

Na verdade, você não deve culpá-los, afinal, a responsabilidade principal deles é a rentabilidade da empresa. Isso significa que todas as decisões deles se baseiam no equilíbrio entre investimento e benefício, ou, na linguagem da administração, ROI (retorno sobre o investimento).

Isso significa que você deve fazer sua lição de casa antes de tentar propor um investimento dessa natureza – pense cuidadosamente sobre como apresentar os benefícios, utilizando uma linguagem que a gerência irá entender e aprovar.

Tentarei ajudá-lo. Os benefícios da segurança da informação, principalmente a implementação da ISO 27001, são inúmeros. Mas, segundo a minha experiência, os quatro a seguir são os mais importantes:

1. Conformidade

Pode parecer estranho listar a conformidade como o primeiro benefício, mas ela muitas vezes mostra o mais rápido “retorno sobre o investimento”: se uma organização precisa cumprir com diversos regulamentos sobre proteção de dados, privacidade e governança de TI (especialmente se for uma organização financeira, de saúde ou governamental), a ISO 27001 pode trazer a metodologia que permitirá fazer isso da maneira mais eficiente.

2. Vantagem de mercado

Em um mercado que é cada vez mais competitivo, às vezes é muito difícil encontrar algo que irá diferenciá-lo aos olhos dos clientes. A ISO 27001 pode ser, de fato, um ponto de venda inigualável, especialmente se você lida com informações confidenciais dos clientes.

3. Redução de despesas

A segurança da informação geralmente é considerada como um custo sem ganho financeiro aparente. No entanto, há ganho financeiro se você diminuir os gastos causados por incidentes. Você provavelmente tem interrupções no serviço, ou vazamentos ocasionais de dados, ou funcionários descontentes. Ou ex-funcionários descontentes.

A verdade é que ainda não existe uma metodologia e/ou tecnologia para calcular quanto dinheiro você poderia economizar se prevenisse esses incidentes. Mas é sempre bom chamar a atenção da gerência para esses casos.

4. Organização da empresa

Este é provavelmente o ponto mais subestimado – se sua empresa vem crescendo acentuadamente durante os últimos anos, você pode ter problemas como: quem tem de decidir o quê, quem é responsável por determinados ativos de informações, quem tem de autorizar o acesso a sistemas de informações etc.

A ISO 27001 é especialmente útil na solução desses problemas, pois ela irá forçá-lo a definir muito precisamente tanto as responsabilidades quanto os deveres e, portanto, reforçar sua organização interna.

Para concluir, a ISO 27001 pode trazer muitos benefícios e não ser apenas mais um certificado em sua parede. Na maioria dos casos, se você apresentar esses benefícios de forma clara, a gerência irá começar a prestar atenção.

Você também pode conferir o webinar ISO 27001 / BS 25999-2 management responsibilities: What does management need to know? (treinamento vendido comercialmente).

Você provavelmente já se perguntou por que tem de realizar uma análise de impacto nos negócios (AIN) se já fez a avaliação de riscos. Você identificou todos os riscos, certo? E passou muito tempo analisando sua empresa, por que então mais uma análise?

Bem, o objetivo da AIN é diferente. Na continuidade de negócios tudo está relacionado ao tempo – não importa se você pode recuperar a sua atividade comercial, se não for feito em tempo razoável. “Razoável” é o que a AIN tem de determinar. Seu principal objetivo é descobrir qual é o objetivo de tempo de recuperação para cada atividade crítica dentro da organização.

Esse tipo de análise, muitas vezes, não é levada a sério. Em primeiro lugar, a empresa geralmente não sabe que resultados incorretos podem incorrer em despesas desnecessárias ou criar uma estratégia de continuidade de negócios inadequada, mas também o esforço necessário para realizar a AIN é subestimado.

Portanto, aqui estão algumas dicas que irão tornar a sua análise de impacto nos negócios mais eficaz:

Trate-a como um (mini) projeto. Defina o responsável pela sua implementação e sua autoridade; defina o escopo, os objetivos e prazos.

Faça sua lição de casa, prepare um bom questionário. Um questionário bem estruturado irá lhe poupar muito tempo e tornar os resultados mais precisos. As normas BS 25999-1 e BS 25999-2 lhe darão uma boa ideia sobre o que ele deve conter. Entre outras coisas, você tem de identificar os impactos resultantes de interrupções e determinar como variam ao longo do tempo, identificar os recursos necessários para recuperação etc. É uma boa prática utilizar perguntas qualitativas e quantitativas para identificar os impactos.

Defina critérios claros. Se o entrevistado tem de responder perguntas pela atribuição de valores, por exemplo, de 1 a 5, certifique-se de explicar exatamente o que cada uma dessas cinco notas significam. Não é raro que o mesmo evento seja avaliado como catastrófico pelos funcionários de nível mais baixo, enquanto que a alta administração avalia seu impacto como moderado.

Colete os dados por meio de interação humana. Os melhores resultados são obtidos quando alguém qualificado em continuidade de negócios realiza uma entrevista com a pessoa responsável por uma atividade crítica. Dessa forma, uma série de questões sem solução são esclarecidas, e respostas equilibradas são obtidas. Se as entrevistas não forem viáveis, faça pelo menos um workshop com todos os participantes para que possam tirar dúvidas sobre tudo o que os está incomodando. Em outras palavras, não basta enviar os questionários e repreender as pessoas por não enviá-los de volta no tempo estabelecido.

Determine os objetivos de tempo de recuperação somente depois de ter identificado todas as interdependências. Por exemplo, com o questionário você pode concluir que para a atividade crítica “A” o tempo máximo aceitável de interrupção é de dois dias; porém, o tempo máximo aceitável de interrupção para a atividade crítica “B” é de um dia e esta não pode ser recuperada sem a ajuda da atividade crítica A. Isso significa que o objetivo de tempo de recuperação para “A” será um dia em vez de dois.

De acordo com minha experiência, os resultados da AIN muitas vezes são inesperados. Geralmente, o objetivo de tempo de recuperação é mais longo do que se pensava inicialmente, e a AIN revela dependências de alguns recursos que são na verdade apenas um ponto único de falha. Mas o melhor de tudo é que a análise de impacto nos negócios é a maneira mais eficaz de fazer as pessoas pensarem sobre o inesperado. Ao criar essa consciência, você aumenta as chances de sobrevivência da sua empresa.

Você também pode conferir o webinar BS 25999-2 Foundations Part 1: Business Impact Analysis (treinamento vendido comercialmente).

Muitas vezes, vejo as políticas de segurança da informação com muitos detalhes, tentando cobrir tudo, desde os objetivos estratégicos até quantos dígitos numéricos uma senha deve conter. O único problema com essas políticas é que elas contêm 50 páginas ou mais, e ninguém as leva realmente a sério. Elas geralmente acabam servindo como documentos artificiais, cuja única finalidade é agradar o auditor.

Mas por que essas políticas são tão difíceis de implementar? Porque são muito ambiciosas, tentam abranger muitas questões e são destinadas a um amplo grupo de pessoas.

É por isso que a ISO 27001, a principal norma de segurança da informação, define diferentes níveis de políticas de segurança da informação:

• Políticas de alto nível, como a Política de Sistema de Gestão da Segurança da Informação – essas políticas geralmente definem a intenção estratégica, os objetivos etc.
• Políticas detalhadas – esse tipo de política geralmente descreve uma área selecionada da segurança da informação com mais detalhes, com responsabilidades específicas etc.

A ISO 27001 exige que a Política de Sistema de Gestão da Segurança da Informação (SGSI), como o documento de mais alto nível, contenha o seguinte: uma estrutura para definir os objetivos, levando em consideração diversos requisitos e obrigações, que se alinhe com o contexto de gestão estratégica de riscos da organização e estabeleça os critérios da avaliação de riscos. Essa política deve ser bem curta (uma ou duas páginas talvez), pois sua finalidade principal é permitir que direção seja capaz de controlar seu SGSI.

Por outro lado, as políticas detalhadas devem ser destinadas para uso operacional e devem focar em um campo menor de atividades de segurança. Exemplos dessas políticas são: Política de classificação, Política de uso aceitável de recursos de informação, Política de backup, Política de controle de acesso, Política de senha, Política de mesa limpa e tela limpa, Política de utilização dos serviços de rede, Política de computação móvel, Política para o uso de controles criptográficos etc. Nota: a ISO 27001 não exige que todas essas políticas sejam implementadas e/ou documentadas, pois a decisão de aplicabilidade e extensão desses controles depende dos resultados da avaliação de riscos.

Como essas políticas devem conter mais detalhes, elas são geralmente mais longas, até dez páginas. Se elas forem muito mais longas do que isso, será muito difícil de implementá-las e mantê-las.

Em outras palavras, a segurança da informação é muito complexa para ser definida em uma única política – devido aos diferentes aspectos do SGSI e aos diferentes “grupos alvo” deve haver políticas diferentes. Organizações de médio porte geralmente produzem até quinze políticas seu SGSI.

Alguém poderia argumentar que esse número de políticas não é nada além de sobrecarga para uma empresa. Eu certamente concordaria se essas políticas forem escritas somente com a auditoria de certificação em mente, nesse caso elas não trariam nada além de mais burocracia. No entanto, se uma política for escrita com a intenção de diminuir os riscos, então ela muito provavelmente irá mostrar seu valor, se não imediatamente, em dois ou três anos, diminuindo o número de incidentes.

Você também pode conferir o tutorial em vídeo Como elaborar a Política de SGSI de acordo com a ISO 27001 (vídeo vendido comercialmente).

Se você ouviu falar que a ISO 27001 exige muitos procedimentos, isso não é verdade. A norma, na verdade, requer apenas quatro procedimentos documentados: um procedimento para o controle de documentos, um procedimento para auditorias internas do SGSI, um procedimento para ação corretiva e um procedimento para ação preventiva. O termo “documentado” significa que “o procedimento é estabelecido, documentado, implementado e mantido” (ISO/IEC 27001, 4.3.1 Nota 1).

Nota: neste post não vou escrever sobre outros documentos obrigatórios, como escopo do SGSI, política do SGSI, Metodologia de Avaliação de Riscos, Relatório de Avaliação de Riscos, Declaração de Aplicabilidade, Plano de Tratamento de Riscos etc. Aqui irei focar somente nos procedimentos.

O procedimento para o controle de documentos (processo de gestão de documentos) deve definir quem é o responsável pela aprovação dos documentos e por revisá-los, como identificar as alterações e o status da revisão, como distribuir os documentos etc. Em outras palavras, esse procedimento deve definir como a corrente sanguínea da organização (o fluxo de documentos) irá funcionar.

O procedimento de auditorias internas deve definir as responsabilidades pelo planejamento e realização das auditorias, como os resultados da auditoria serão relatados e como os registros serão mantidos. Isso significa que as principais regras para a realização da auditoria devem ser definidas.

O procedimento para a ação corretiva deve definir como a inconformidade e suas causas serão identificadas, como as ações necessárias serão definidas e implementadas, quais registros serão feitos e como a revisão dessas ações será executada. O objetivo deste procedimento é definir como cada ação corretiva deve eliminar a causa da inconformidade para que ela não volte a ocorrer.

O procedimento para a ação preventiva é quase o mesmo da ação corretiva, a diferença é que este visa eliminar a causa da inconformidade para que ela não chegue a ocorrer. Devido às suas similaridades, esses dois procedimentos geralmente são unidos em um único.

Mas porque a ISO 27001 requer procedimentos documentados que não estão relacionados à segurança da informação, enquanto os procedimentos de segurança não são obrigatórios?

A resposta está na avaliação de riscos. A ISO 27001 exige que você realize uma avaliação de riscos, e quando essa avaliação de riscos identifica alguns riscos inaceitáveis, a ISO 27001 exige que um controle do seu Anexo A seja implementado para diminuir os riscos. O controle pode ser técnico (por exemplo, antivírus para diminuir o risco de ataques de softwares maliciosos), mas também pode ser organizacional, como implementar uma política ou um procedimento (por exemplo, implementar um processo de back-up). Portanto, os procedimentos se tornam obrigatórios somente se a avaliação de riscos identificar riscos inaceitáveis.

Uma nota importante: ao contrário dos quatro procedimentos obrigatórios que devem ser documentados, os procedimentos decorrentes dos controles do Anexo A não precisam ser documentados. Cabe à organização avaliar se tal procedimento deve ser documentado ou não.

Você pode considerar os quatro procedimentos obrigatórios como os pilares do seu sistema de gestão (em conjunto com a política de segurança) – depois que eles estiverem firmemente assentos no chão, você pode começar a construir as paredes da sua casa. Isso se torna evidente quando se analisa outros sistemas de gestão – os mesmos quatro procedimentos são obrigatórios lá também – na ISO 9001 (sistemas de gestão da qualidade), ISO 14001 (sistemas de gestão ambiental) e BS 25999-2 (sistemas de gestão da continuidade de negócios). Como consequência, você pode usar esses procedimentos como o principal elo entre diferentes sistemas de gestão, se quiser desenvolver o chamado “sistema integrado de gestão”.

Você também pode conferir o tutorial em vídeo Como elaborar o Procedimento de controle de documentos da ISO 27001/ISO 22301 (vídeo vendido comercialmente).