A norma mais importante

Há algum tempo venho escrevendo aqui sobre política de segurança da informação com o objetivo de ajudar os profissionais da área a lidar com a dura tarefa de criar estes documentos e colocá-los em prática. Já falei de algumas questões conceituais e estruturais envolvendo a política e sobre o que o documento principal deve contemplar.

Nesse post pretendo fazer algo parecido, mas com foco no que é para mim a norma mais importante de uma política: a Norma de Classificação da Informação.

Por que esse documento é importante?

Todas as áreas possuem recursos limitados. Simplesmente é impossível dedicar esforços e dinheiro em aplicar os mesmos controles de segurança para todos os tipos de informação. O raciocínio mais sensato é o de que os controles mais rígidos (e mais caros) devem ser aplicados nas informações mais importantes. Estabelecendo um mínimo aceitável para as informações de menor criticidade para organização.

Esta é a razão fundamental pela qual a Norma de Classificação da Informação é a mais importante da política. Pois por meio da classificação correta, a dedicação de recursos para a proteção da informação se torna  racional.

Empresas que não possuem uma política de segurança geralmente erram nesse critério pois, em muitas situações acabam investindo dinheiro na compra de canhões para matar formiga ou zarabatanas para matar elefantes. O que quero dizer com isso é que a Norma de Classificação não deve ser encarada somente como um conjunto de regras para as pessoas etiquetarem informações, mas sim como mais um instrumento para que o orçamento de segurança seja orientado de forma sensata.

Mas nisso mora um perigo

Pude notar um vício em todas as vezes fiz Análises de Impacto nos Negócios (BIAs): Os gestores tendem a supervalorizar a importância da atividade que conduzem. Na verdade essa percepção não é somente minha, todo mundo que trabalha com continuidade de negócios já sofreu com algo semelhante.

O que acontece é mais ou menos isso: No levantamento de informações para a BIA o gestor diz que a atividade dele não pode parar nem um minuto sequer  (RTO 0), aí você mostra para o gestor que, para que a atividade  dele não sofra interrupções ele terá de contratar, por exemplo um site backup para o qual boa parte de seus funcionários terão de ser deslocados em uma situação de contingência. Nesse momento o gestor faz as contas do quanto ele terá de gastar e reconsidera o RTO.

Com a classificação da informação pode ocorrer um fenômeno semelhante. O correto é que o colaborador que produziu a informação faça a sua classificação e geralmente eles supervalorizam a importância do que produzem. Isso cria dois cenários possíveis: (1) a empresa terá de dedicar recursos preciosos em proteger informação que não é tão importante ou (2) a norma perde seu lastro na realidade, torna-se um documento de gaveta.

Então considere que a Norma de Classificação da Informação é a que norteará toda implementação de segurança da companhia, por isso as instruções de como classificar devem ser marteladas sem cessar na cabeça dos colaboradores e a classificação revisada sempre que possível pela equipe de segurança da informação.

Quantas classificações?

Muita gente defende que sejam usadas três classificações (confidencial, de uso interno e pública). Sinceramente penso que se as equipes da empresa compreendem adequadamente as consequências de uma classificação no ambiente, vão querer definir quatro. Para ilustrar isso, dou um exemplo.

Imagine dois tipos de informação: chaves de criptografia e dados da folha de pagamento. Ambas informações são muito importantes e se tivéssemos trabalhando com três classificações, definiríamos as duas como confidenciais.

Agora considere que a pessoa que está redigindo a Norma de Criptografia, ao invés de dizer quais informações devem ser criptografadas (porque ela ou ele teria de alterar a norma a cada informação importante nova ou descontinuada) insira algo assim no documento:

“Toda informação classificada como confidencial deve ser criptografada”

Pronto, agora o pessoal de TI ganhou a missão de encontrar uma solução de criptografia para a folha de pagamento.

É por isso que sou adepto ao método de quatro classificações (confidencial, sensível, de uso interno e pública). Uso esses nomes, mas cada companhia pode usar o seu modelo. Se alguém quiser chamar de Donald, Huguinho, Zezinho e Luizinho e isso fizer sentido para os colaboradores, sem problema. O mais importante aqui é que as pessoas usem a classificação correta e que isso seja revertido em uma destinação de recursos sensata.

Agora sim… As classificações

Confidencial -Imagine gente sendo demitida, ações da empresa perdendo valor de mercado, dados de cartão de seus clientes sendo usados por quadrilhas, um concorrente lançando um produto parecido com o que sua empresa está há anos desenvolvendo… Imagine o caos. Este cenário de terror pode lhe ajudar a entender o que é informação confidencial.

Costumo definir informações confidenciais como aquelas que podem trazer sérios impactos para o negócio, parceiros e acionistas, representando perda financeira e até a inviabilidade de manter a operação caso sejam divulgadas de maneira não autorizada. Alguns exemplos seriam senhas, chaves criptográficas e dados de cartão de pagamento.

Sensível – Estas seriam as informações que, se vazadas poderiam expor especificidades do negócio, tendo impactos sérios, mas que a organização poderia suportar (não haveria riscos de falência). Como exemplo, posso citar a folha de pagamento, relatórios de auditoria, dados de clientes, etc.

De uso interno – As informações de uso interno são aquelas que requerem controle e cuidado. Mas que se vazadas não representam perda financeira. Exemplos seriam as políticas, normas e procedimentos.

Pública – Como o nome diz, estas são as informações que a empresa decidiu publicar por força da lei ou deliberadamente. Exemplos seriam as campanhas de publicidade e balanços financeiros (para as empresas de capital aberto).

Veja que com quatro classificações é possível estabelecer controles de segurança mais rígidos para as informações confidenciais, robustos para as sensíveis, relevantes para as informações de uso interno e básicos para as públicas.

No caso das públicas, vale dizer mais uma coisa: não é porque a informação é publica que ela não deve ter nenhum controle de segurança. Vale a pena relembrar o mantra de que segurança se traduz em disponibilidade, confidencialidade e integridade e assim considerar o uso de mecanismos que garantam que a informação pública é, no mínimo íntegra.

Outros itens da norma

Além dos campos de Modificações, Objetivo, Audiência e Exceções, comuns a todos os documentos como disse em meu último post, é importante que a Norma de Classificação da Informação também contemple:

  • A determinação de que toda mídia (arquivo, papel, computador e mídia removível) deve ser classificada.
  • Toda mídia deve ser classificada de acordo com a informação de maior classificação presente nela. Ex.: se uma mídia possui 1GB de informações públicas e 1MB de confidencial, ela deverá ser classificada como confidencial.
  • Todas as mídias classificadas como confidencial (no mínimo) devem ser monitoradas por mecanismos de segurança física definidos em norma específica para esse tema.
  • Todas as mídias classificadas como confidencial e sensível devem ter o acesso lógico monitorado (logs) por mecanismos definidos em norma específica para esse tema.
  • Mídias não classificadas adquirem automaticamente a classificação “sensível”. Obs.: aqui pode ocorrer o problema de um colaborador deixar de classificar uma mídia confidencial e ela adquirir controles de segurança inferiores ao necessário. Portanto… Reforço na Conscientização.
  • Todas as informações classificadas como de uso interno, sensível e confidencial devem ser protegidas por mecanismos de controle de acesso definidos em norma específica para esse tema.
  • Todas as informações classificadas como confidenciais devem ser criptografadas com algoritmos e ferramentas definidos em norma específica para esse tema.

De maneira geral estes são os itens que considero como essenciais para uma Norma de Classificação da Informação. Como venho dizendo, a operação de cada empresa pode demandar a customização de alguns detalhes, mas o básico está aí.

Este é o ultimo post que farei aqui neste ano. Desejo ótimas festas a todos os leitores e retomamos esse assunto no ano que vem.

O que a Política de SI precisa ter

Comecei essa sequência de posts falando dos problemas que geralmente surgem ao se fazer a política e as normas de segurança da informação. Na sequência abordei algumas atitudes interessantes para o projeto de criação desses documentos se tornar realidade e depois sugeri uma forma de estruturar os documentos.

Nesse post irei falar sobre os temas que, em minha opinião são essenciais ao redigir o principal documento de todo pacote de regras; aquele que pode ser chamado de política ou de diretrizes de segurança da informação. Mas antes de tudo é importante falar um pouco sobre formatação e a linguagem a ser usada na política.

Formatação

Sugiro sempre numerar todos os itens da política, conforme abaixo:

Captura de Tela 2015-12-05 às 11.16.49

Isso é importante para fazer referência as regras. Pois é mais fácil dizer “o que você está fazendo é violar o item 11.3.2 da política” do que “o que você está fazendo é violar aquele item da política sobre distribuição de mídia pirata”.

Só uma questão prática.

Firmeza na linguagem

Os documentos que determinam as regras de uma companhia não devem ser confundidos com um manual de aconselhamento. Eles não podem recomendar. Pelo contrário, esses documentos precisam ir direto ao ponto, sem rodeios dizendo o que se pode ou não fazer e indicando onde buscar regras adicionais ou outros documentos que indiquem como a atividade deve ser feita.

Dessa forma, caso se queira que uma política seja respeitada e seguida, nunca se deve usar em seus documentos as expressões “convém que” ou “recomenda-se que”. Fazendo isso, se submete ao colaborador a decisão de respeitar a regra quando lhe for “conveniente” ou simplesmente ignorar a “recomendação”, pois não há ali a obrigatoriedade de cumprimento.

Portanto, sem medo e sem dó, abuse das expressões “deve fazer” e “é proibido” e se achar por bem oferecer informações sobre como ler e entender a política, vale a pena criar um guia separado, somente com o objetivo educativo.

Estabelecido isso, agora vamos aos itens do documento.

Modificações

É importante ter uma tabela com todo o histórico de modificações em todos os documentos (política, norma e procedimentos) contendo a data da mudança, o que mudou, quem fez a mudança, quem revisou e quem aprovou. Ter isso documentado facilita a vida em auditorias.

Objetivo

Campo em que se dá uma breve descrição do motivo pelo qual a política existe. Não se deve usar esse campo para dizer porque segurança é importante ou se aprofundar em o que é informação ou segurança da informação. Deixe isso para as atividades de conscientização em segurança ou para um guia.

O campo de objetivo precisa estar em todos os documentos (política, normas e procedimentos).

Audiência

Esse é outro campo que precisa estar em todos os documentos e que também precisa ser preenchido de maneira simples e breve, basicamente com quem deve cumprir a política.

Lembre-se que em meu post anterior eu disse que certos documentos possuem audiência limitada a poucas áreas. Então em uma Norma de Desenvolvimento Seguro de Software, a audiência seria os desenvolvedores e arquitetos de software, por exemplo.

É importante mencionar aqui as áreas e não pessoas, pois caso uma pessoa citada saia da companhia, é necessário atualizar o documento e submetê-lo novamente ao processo de aprovação, o que pode durar meses.

Estrutura

Nessa sessão se obriga os gestores da política a estruturar os documentos no modelo hierárquico dizendo o seguinte:

  • que todos os temas específicos precisam estar em normas;
  • que as especificações sobre como cumprir as regras da política e das normas precisam ser documentadas em procedimentos;
  • que é proibido criar normas e procedimentos que entrem em contradição com o documento principal da política;
  • que a companhia é obrigada a divulgar os documentos a todos os funcionários e terceiros os quais a empresa entenda relevante;
  • que todos os documentos devem passar por revisão periódica (sugiro anual), mesmo que não haja necessidade de mudança e que essa revisão siga os passos de um procedimento específico.

Responsabilidades

Nessa seção da política é importante dizer quem tem a responsabilidade por:

  • Elaborar, aprovar, divulgar, motivar o cumprimento e cumprir a política, as normas e os procedimentos;
  • Cobrar o cumprimento dos prestadores de serviço;
  • Acionar as áreas responsáveis em caso de suspeita de incidente;
  • Elaborar planos de resposta a incidentes;
  • Elaborar análises de riscos;
  • Estabelecer e dar manutenção a um processo de gestão de continuidade de negócios.
  • Manter inventário de ativos;
  • Estabelecer e documentar as regras de segurança as serem aplicadas nos ativos;
  • Configurar os ativos de acordo com as regras de segurança;
  • Monitorar a segurança dos ativos.

Classificação

Deve haver uma norma específica para a classificação da informação. Entretanto é importante que o documento principal da política possua um item dizendo que toda informação da companhia deve ser classificada de acordo com a norma.

Serviços de mensagem e internet

É importante apresentar as regras gerais para serviços de mensagem e internet no documento principal. Elas precisam ter foco nos seguintes temas:

  • Spam;
  • Spoofing;
  • Envio de informações classificadas como confidenciais;
  • Remoção ou alteração de mensagem em situações de investigação (alteração de prova);
  • Propagação de código malicioso;
  • Conteúdo que não esteja de acordo com os valores da companhia (pornografia, calúnia, difamação, etc.);
  • Pirataria;
  • Jogos
  • Redes sociais;
  • Posição da empresa sobre o monitoramento dos acessos (se ela monitorará ou não).

Gestão de Identidade e de Acessos Físicos e Lógicos

Estes são temas que também devem ter normas específicas.

Quando falamos de acesso físico, no documento principal da política é necessário abordar como deve ser o tratamento de funcionários, prestadores de serviços e visitantes nas dependências da empresa, como ele será registrado, abordar de maneira geral as regras para o uso de crachás, revisão periódica de acessos e referenciar o procedimento que trata do ciclo de vida dos acessos físicos.

Já sobre acessos lógicos, toda essa questão de gestão de ciclo de vida de acessos e revisão periódica se repete, entretanto é necessário inserir as regras de senhas (tamanho, complexidade, bloqueio, etc.) e duplo fator de autenticação.

Uso de Tecnologia

A seção relacionada ao uso de tecnologia precisa tratar dos temas de propriedade de equipamentos (mencionar se eles são da empresa, se for o caso), a proibição de alteração de configurações por parte de usuários, designando a área correta para isso, a obrigatoriedade do uso de certas ferramentas de segurança em todos os computadores (por exemplo, antivírus, firewall de host, FIM, etc.), todas as questões relacionadas à instalação de software não autorizado ou pirata e a obrigatoriedade da parametrização de todos os equipamentos de acordo com um procedimento de configuração para cada tipo de ativo (também chamado de hardening ou baseline).

Sanções

Penso que toda política e normas deve ter, ao final uma área que determine o que pode acontecer com o funcionário ou prestador em caso de violação de suas regras.

A explicitação disso pode estar em um documento à parte o qual é citado na política, mas eu sinceramente acredito que pessoas não cumprem regras somente por boa vontade, mas sim porque também temem algum tipo de repreensão. Então essa possível repreensão precisa existir na política.

Exceções

Para esta seção, compartilho o texto que coloco em minhas políticas:

“Qualquer exceção a esta política deve ser documentada, aprovada pelo CEO, mais dois executivos estatutários e considerada em todas as análises de risco da empresa.”

O que quero dizer com isso:

  • primeiro, nenhum executivo aprova exceção à política sozinho e somente podem aprovar, aquelas pessoas que têm o poder de assinar pela empresa;
  • segundo, exceção à política é algo sério e precisa ser documentado. Quando se documenta algo, se pondera mais a respeito e se coloca um responsável na linha de tiro caso algo dê errado e
  • terceiro: Isso tem que entrar nas análises de risco. Quando se faz uma análise de risco, se pondera a probabilidade de exploração das vulnerabilidades as quais uma companhia está sujeita em relação ao seu impacto. Meu objetivo aqui é o de avaliar as exceções toda vez que se fizer uma análise de riscos, assim se cria um mecanismo para frequentemente questionar se a exceção é necessária, pois caso contrário a exceção vira regra.

Isso era o que eu tinha para compartilhar sobre o principal documento da política. Meu posicionamento não é definitivo e outros temas podem ser necessários, de acordo com cada ambiente. Sendo um crítico da “Big Mac-zação” desses documentos, não faria sentido eu dizer que esse é o único caminho, mas sim que ele pode ajudar muita gente que não tem nada.

Aproveito para agradecer a todas as pessoas que me enviam mensagens e comentários a respeito do trabalho que estou desenvolvendo aqui. Saibam que isso me dá uma motivação adicional para continuar e peço que compartilhem os textos, caso entendam que eles podem ajudar mais gente.

No próximo post vou falar sobre o documento que está em segundo lugar em importância quando falamos de políticas e normas de segurança da informação e que dele derivam uma série de atividades que podem encarecer ou até inviabilizar a aplicação da política, falo da Norma de Classificação da Informação.

Até.

 

 

 

 

Políticas de SI – Estrutura

Ao iniciar o processo de criação de uma política é comum fazer o seguinte questionamento: “devo colocar todas as regras em um documento só ou dividir a política em vários documentos?”

A política de segurança deve ser comparada a uma legislação que trata de diversos temas, alguns afetam todas as pessoas de uma companhia, por exemplo o uso de e-mail e outros estão associados a uma audiência muito pequena: como uma norma de gestão de chaves criptográficas.

Dessa maneira, imagine que após mapear todos os temas de segurança aplicáveis à sua empresa e documentar todas as regras, a sua primeira versão da política tenha algo em torno de 60 páginas.

Toda essa quantidade de páginas teria que ser encaminhada para alguns executivos para aprovação e depois de publicada, todos os colaboradores teriam que dar o aceite na política inteira. Ao final do processo é bem provável que nem os executivos, muito menos os funcionários tenham lido todo o documento.

Se ao invés de somente entregar o documento, queremos mesmo que as pessoas cumpram o que está escrito nele, podemos dizer que colocar tudo em uma política imensa não ajuda. Pelo contrário, complica.  Por que contadores teriam que ler e dar aceite em documentos que especificam segurança no desenvolvimento de software?

Assim o melhor caminho é o de dividir o documento por audiência, tonando o volume de leitura menor, mais claro e focado em cada público. Mas nesse momento surge outro questionamento importante: Estes documentos devem ser dispostos de maneira paralela, ou é possível estabelecer alguma hierarquia entre eles?

Estrutura paralela

Neste cenário o conjunto de políticas seria disposto em paralelo como na figura abaixo.

paralela

Já tive a oportunidade de ver um conjunto de políticas estruturado dessa maneira funcionar bem. No entanto acredito que essa não é a melhor forma de estruturar uma política, porque é fácil criar confusão sobre qual documento possui quais regras para uma situação específica e também há o risco de se estabelecer regras conflitantes entre os documentos.

Para tornar mais clara a minha opinião, demonstrarei abaixo a estrutura que penso fazer mais sentido.

Estrutura Hierárquica

A forma hierárquica de organização da política de segurança da informação não é nada nova. Pelo contrário, ela segue a estrutura de organização de leis em uso pelas mais influentes repúblicas democráticas do mundo.

hierarquica

Geralmente os países consolidam tudo aquilo que consideram certo e errado de maneira ampla e geral em uma constituição e estabelecem leis para aqueles temas que requerem uma atenção especial ou que lidam com um público ou condição específica, sempre mantendo o cuidado para que uma lei não se torne inconstitucional, situação em que suas regras entram em conflito com a constituição.

Esse arranjo de documentos também torna a constituição perene, sobrevivendo muito tempo sem alterações. A constituição brasileira de 1988 é bem grande e cheia de emendas. Com certeza não é o melhor exemplo para fundamentar meu argumento. Entretanto a constituição dos Estados Unidos é um conjunto bem pequeno de regras e desde 1751 teve somente 27 emendas. É essencialmente esse modelo que defendo quando vou construir uma política de segurança da informação.

A política de segurança da informação

Este documento pode ter outro nome, já vi como “Estatuto de Segurança da Informação”, “Diretrizes de Segurança da Informação”, “Políticas e Normas de Segurança da Informação” e outros. É importante escolher um nome que o todos os colaboradores reconheçam como a fonte de todas as regras gerais da companhia e por isso acho importante diferenciar a política de norma.

A política precisa ter um conteúdo geral evitando qualquer especificidade técnica. Por exemplo, procuro evitar o uso desse tipo de texto:

É proibido o envio de códigos de cartão de crédito por e-mail, ICQ ou WhatsApp

A política de segurança da informação é um documento que precisa ser aprovado pelo maior executivo da empresa (presidente, CEO, etc.), então não é recomendável atualizar um documento tão importante como esse assim que uma tecnologia morre ou é trocada por outra na empresa.

Então prefiro dizer:

“É proibido o envio de qualquer informação classificada como sensível por meio de tecnologias de mensageria”

É melhor usar um termo genérico, mas que dê conta da diretriz que se quer impor e tornar isso claro (com exemplos) no glossário da política, documento que não requer aprovação de vários executivos a cada mudança.

Normas

Estes são os documentos específicos para cada tema e podem ter como audiência a empresa toda ou um grupo específico.

Diferente da política que demanda a aprovação do principal executivo da empresa, as normas podem ser aprovadas por executivos de menor nível hierárquico na organização, por conta da especificidade. Por exemplo, uma “norma de controle de acesso lógico” pode ser aprovada somente pelos executivos de tecnologia envolvidos nessa atividade.

Procedimentos

Se a política e as normas focam no quê pode ou não ser feito, nos procedimentos estão documentados como as atividades devem ser conduzidas.

Por exemplo, se a política de segurança da informação determina que toda informação classificada como sensível deve trafegar criptografada, a norma de criptografia deve estabelecer os algoritimos e tamanhos de chave para esse tráfego. Já os procedimentos documentam como instalar e configurar o mecanismo de criptografia adotado pela empresa, como em uma receita de bolo.

Penso que essa é a melhor estratégia para estruturar uma política. Fica claro para todo mundo qual é o documento principal, onde estão as regras específicas e o que se deve fazer para cumpri-las. Tudo de maneira organizada, pois não há segurança sem organização.

Como anexo desse post, coloco abaixo a lista de documentos que geralmente compõem uma Política de Segurança em conformidade com o PCI DSS.

No próximo post irei falar sobre quais regras devem estar no documento principal: a Política de Segurança da Informação.

Até

 

Política de Segurança da Informação
Norma de Gestão de Firewalls
Norma de Gestão de Dispositivos de Redes
Norma de Configuração de Servidores
Norma de Configuração de Estações de Trabalho
Norma de Gestão de Ativos de Clientes
Norma de Classificação da Informação
Norma de Retenção e Descarte de Informações
Norma de Criptografia
Norma de Uso de Internet
Norma de Uso de E-mail
Norma de Antivírus
Norma de Gestão de Vulnerabilidades e Atualizações de Software
Norma de Segurança no Desenvolvimento de Software
Norma de Gerência de Mudanças
Norma de Controle de Acesso Lógico
Norma de Gestão de Credenciais de Acesso Lógico
Norma de Gestão de Acesso Físico
Norma de Gestão de Trilhas de Auditoria
Norma de Monitoramento da Segurança da Informação
Norma de Proteção de Informações em Prestadores de Serviço
Termo de Aceite da Política de Segurança da Informação
Glossário da Política
Procedimento de Revisão dos Documentos da Política
Procedimento de Aprovação do Uso de Tecnologias Críticas
Procedimento para a Elaboração de Diagramas.
Procedimento de Revisão de Regras e Configuração dos Firewall e Dispositivos de Rede
Procedimento de Revisão de Pontos de Acesso Sem Fio
Procedimento de Gestão, Guarda e Descarte de Chaves Criptográficas
Procedimento de Revisão do Uso de Antivírus
Procedimento de Elaboração de Rankings de Riscos
Procedimento de Revisão de Código
Procedimento de Revisão de Acessos
Procedimento de Gestão de Credenciais de Acesso
Procedimento de Gestão de Acesso Físico
Procedimento de Gestão de Mídias
Procedimento de Gestão de Dispositivos de Captura de Dados de Cartão
Procedimento de Revisão de Trilhas de Auditoria
Procedimento de Análise de Riscos
Procedimento de Monitoramento da Segurança em Prestadores de Serviços
Plano de Resposta a Incidentes
Procedimento de Teste do Plano de Resposta a Incidentes

 

 

 

 

Política de SI – Atitudes para fazer acontecer

É comum as pessoas acreditarem que em um ambiente sem leis somente predomina a desordem e que uma das primeiras coisas a serem estabelecidas em qualquer ajuntamento de gente, são regras de conduta.

Entretanto, são poucas as empresas que determinam de maneira formal o que pode ou não ser feito em seu ambiente. Em alguns casos até existem regras formais, mas essas acabam sendo engavetadas por não fazerem muito sentido à realidade da companhia.

Nesse, que é mais um texto dessa minha caminhada no sentido de fornecer recursos para que cada leitor possa desenvolver suas políticas, irei recomendar algumas atitudes que podem fazer seu projeto de política sair do papel, se me permitem o trocadilho.

Hierarquia

Entendo que um dos problemas que mais contribuem para a falta de efetividade de uma política de segurança é o quanto a empresa dá valor para a hierarquia.

Já tive a oportunidade de trabalhar em uma companhia em que nada acontecia sem a vontade do dono. Por isso, havia um séquito de bajuladores que agia como uma corte orbitando em torno de um rei e cumprindo suas vontades. Para tentar convencer o dono de qualquer coisa, era necessário alcançar algum nível de consenso com o séquito, o que tornava o processo de estabelecer políticas muito difícil.

O que frequentemente acontece quando a política vinga em um ambiente desses é que as regras passam a valer para a maioria dos empregados e são criadas exceções para os executivos. Mantendo a empresa vulnerável, afinal são os executivos que detêm as informações mais críticas.

Neste caso, penso que é essencial tentar convencer os grupos focando em conscientização sobre os riscos, obviamente sem se render ao jogo da bajulação (afinal, somos profissionais). Mas também é importante estabelecer uma segunda linha de atuação, fazendo alianças com os auditores. Estes profissionais geralmente seguem a cartilha americana que determina a implementação de políticas e podem “recomendar fortemente” a formalização e o cumprimento das regras nos documentos. Não resolve todos os problemas, mas dá subsídio político para desbloquear o caminho.

Minha sugestão pode parecer maluca para muita gente; “como vou dar pistas para o auditor de que algo não vai bem? Ele vai me dar um ponto de auditoria!” Bom… Minha intenção aqui é falar com quem quer trabalhar de verdade e não esconder as coisas pra debaixo do tapete. Ter uma boa relação com os auditores pode render várias coisas boas como a formalização e priorização de atividades – tendo um caminho a cumprir sem ter que viver apagando incêndios –  e a liberação de verba para projetos.

Bom senso

Deixar de estabelecer formalmente as regras de segurança é o mesmo que submeter a proteção das informações ao bom senso das pessoas.

Todos temos uma noção própria do que é certo e errado. Mas, mesmo que bem intencionadas, as pessoas podem agir de maneira completamente diferente quando falamos em expor informações a riscos. É preciso dizer a elas exatamente o que fazer e criar barreiras eficientes que evitem que elas façam o contrário por erro, omissão ou má intenção.

Expor esta condição aos executivos pode ser um passo à frente no sentido de lhes oferecer uma visão clara sobre os riscos de depender do bom senso das pessoas.

Foco na realidade tecnológica

Embora as políticas de segurança devam dedicar muito do seu foco em guiar a atitude das pessoas,  penso que isso é parte do que se deve esperar desses documentos. Mais importante, em minha opinião, é criar documentos que disciplinem como a tecnologia deve operar com base na realidade.

Quando elaboro uma política dedico muito mais tempo em entender os detalhes técnicos do ambiente e definir regras que se encaixem às tecnologias em uso do que escrevendo “faça isso, não faça aquilo”. De que adianta dizer que a senha padrão para uma empresa é de 15 caracteres se seu principal sistema opera no máximo com 8?

A política de segurança da informação não deve ser confundida com uma carta de intenções. A definição de regras de segurança sempre força algum tipo de mudança para aquelas empresas que nunca tiveram um documento como esse. Mas não se pode perder o foco da realidade, caso contrário o documento se torna somente uma promessa e o executivo que bancou, simbólica ou financeiramente o documento pode pensar que dedicou esforço para nada.  Criar uma política é algo que precisa equilibrar mudança de conduta e realidade.

Continuar lendo

O problema da Política de Segurança

Essa história sempre se repete.

Chega um dia que o responsável por segurança da informação de uma empresa decide por si, ou empurrado por outros, que é necessário elaborar uma política de segurança da informação. Rapidamente ele vê dois caminhos para solucionar o problema: jogar o abacaxi no colo de uma pessoa de sua equipe ou contratar uma consultoria para dar conta do trabalho.

É possível ter um trabalho maravilhoso nos dois cenários, mas o que frequentemente acontece é o seguinte.

“Escrever é um pé no saco”

O elemento mais sedutor da área de segurança da informação é a possibilidade hackear coisas ou desenvolver estratégias de proteção de informações em estruturas tecnológicas complexas. Não tem discussão, isso é o que mais atrai gente para trabalhar na área.

Aí o gestor pega um profissional desses e diz que ele vai ter que escrever diversos documentos estabelecendo o que as pessoas podem ou não fazer… Primeiro, é muito comum ouvir dos técnicos que esses documentos não servem pra nada. Segundo, geralmente o pessoal técnico acha que escrever é algo torturante.

Não vivemos mais nos anos 80/90, em que os profissionais tinham que manter o emprego a qualquer custo, suportando tudo aquilo que não gosta. Lógico que tá cheio de “paus mandados” no mercado, mas ao submeter um bom profissional a uma atividade que ele não gosta, ou não acredita, abre-se o caminho do LinkedIn.

A roda já tá pronta né?

O caminho mais fácil para essa pessoa se livrar logo da bucha é buscar um documento pronto na Internet, pois não vamos reinventar a roda.

Aqui começa o destino de um documento de gaveta.

Os religiosos passam milênios tentando fazer com que regras prontas sejam cumpridas pelos outros em prol de um benefício espiritual, tudo isso sem sucesso, pois caso contrário teríamos uma religião só. Por que ainda se acredita que copiar e colar regras dos outros iria funcionar nas empresas que estão o tempo todo se movimentando, se reciclando e se reorganizando em função do lucro?

É comum os profissionais de segurança repetirem o mantra de que “segurança se faz para o negócio”. Esse discurso bonito quer dizer que o negócio geralmente atropela as barreiras que não tenham a ver com ele. É como se fosse o fluxo de um rio, você pode tentar conduzir a corrente, mas fique no caminho dela pra ver o que acontece com você.

Não proponho a reinvenção da roda, mas os documentos de outros devem servir somente como inspiração para a criação de uma política. A não ser que se esteja em busca de uma certificação, como a PCI DSS. Nesse caso a margem de manobra é mais estreita, mas ela existe.

A via da consultoria

Caso o gestor tenha algum orçamento, ele pode optar por comprar o documento de uma consultoria.

As consultorias adoram quando o cliente não tem nenhuma política e nenhum conhecimento sobre como fazer os documentos. Assim eles podem vender várias horas de um consultor (geralmente umas quarenta) para que este profissional pegue um documento já pronto e dedique pouco tempo somente trocando o nome da empresa e de suas áreas em campos do template.

Sejamos francos: consultoria lucra com template, quanto mais ela ter que personalizar um trabalho, mais  precisa que seus consultores fiquem dedicados a uma atividade que não será replicável para outro cliente. Fazer políticas de segurança para quem não tem nada é um prato cheio, pois o profissional trabalha no máximo oito horas adaptando o documento e 32 horas é lucro. E claro que o consultor não vai ficar as 32 horas sem fazer nada, ele vai ser alocado em outro projeto. Ou seja naquele tempo restante haverá no mínimo dois clientes pagando pelo seu tempo.

No discurso, as consultorias defendem a teoria de que aquilo é o resultado de uma metodologia baseada em melhores práticas… Conversa fiada. O objetivo é o mesmo de qualquer empresa, obter o maior lucro com o mínimo esforço. Isso não é uma crítica, é a realidade.

Obviamente que uma empresa que nunca teve uma política na vida terá que incorporar uma série de novas atividades à sua rotina, caso contrário ela não estaria implementando segurança. Óbvio também que temos que aproveitar o que há de bom e que tenha funcionado em outros lugares. Mas como eu disse acima, se o documento não seguir o fluxo da companhia, ele não fará sentido.

Vamos parar de reproduzir essa lógica?

Veja que a situação se resume ao seguinte. O gestor tem um problema para tirar da frente, o colaborador dele dá preferência a atuar tecnicamente e a consultoria prefere fabricar documentos aos moldes do “tamanho único”. A reprodução desse comportamento não gera segurança. Pois somente multiplica documentos de gaveta que não servirão como diretrizes para a proteção dos dados nas organizações.

É necessário romper com este ciclo e para isso os gestores e colaboradores precisam acreditar que a política de segurança da informação é um documento útil, não somente para se safar em auditorias, mas como um instrumento de gestão da segurança da informação. E penso que para um documento ser útil, este deve ter alto nível de personalização.

Quero contribuir para que o mercado tenha documentos mais alinhados a cada realidade e pretendo escrever mais sobre esse tema em meio aos meus próximos posts, mostrando como eu faço as minhas políticas.

 

 

 

 

 

 

 

O governo fazendo “governiçe”

a8c9e0110cca49db5762f0870255231d

O governo brasileiro, através do Serpro está exigindo que todos os seus fornecedores de software, ou de hardware com software embarcado, entreguem o código-fonte de seus produtos para serem auditados[1]. Conforme informou o portal CryptoID.

Vogons

Governos são Vogons. São inchados, lentos e de mentalidade essencialmente burocratizante.

Não acredito que um governo ou um Estado deve se movimentar na velocidade autoritária do capital, pois governos precisam ser democráticos e a democracia toma tempo. Os momentos mais bonitos que tenho em minha memória dos atos de conduzidos por ativistas aos quais tenho respeito, eram as assembleias de definição de trajeto. A democracia pressupõe o tempo da maioria e é assim que deve ser.

Entretanto, há um outro lado presente na lentidão dos governos que são as vontades políticas, contaminadas por interesses de pessoas e grupos que estão ali enraizados em suas instituições. Como algumas bromelias, que possuem em si a dependência parasitária do outro, mas nesse caso sem nada da beleza da flor.

Fico imaginando, este tipo de medida defendida pelo Serpro em vigor. Primeiro, todos os atuais fornecedores teriam que entregar o seu código-fonte, formando uma pilha imensa de dados para analisar. Enquanto as versões não são analisadas, nada poderá ser atualizado pois os pacotes somente poderiam ser instalados após a análise. Ou então estes seriam instalados, mesmo se houvesse ali algum backdoor e seus códigos entrariam na fila sem fim de dados para auditoria.

Processos novos de compra de software também teriam que passar por análise, de maneira que o processo licitatório seria imenso e melhorias na infraestrutura tecnológica e de segurança demorariam anos para serem implementadas, ou correriam por um processo “alternativo”. Sabemos o que a acontece em essas gambiarras procedimentais. Em minha opinião isso tornaria o Estado brasileiro ainda mais lento ou mais suscetível à corrupção.

O Serpro tem dificuldades até para gerir o certificado digital de sua página (eles que são uma autoridade certificadora), imagine auditar todo o software que o governo usa (há uma atualização sobre este tema mais abaixo).

Acesso feito em 16/04/15 às 13:23
Acesso feito em 16/04/15 às 13:23

Atualizações e Segurança

No vídeo divulgado pelo portal CryptoID (reproduzo abaixo), um representante da Cisco questiona como o governo vai lidar com as atualizações de software, sobretudo as de segurança e qual seria a proteção da guarda dos fontes. O representante do Serpro diz claramente que não sabe como isso vai ser feito e somente se apoia nos mecanismos de proteção de informações em vigor na Previdência Social e Receita Federal.

Sobre as atualizações, como disse acima, isto tem tudo para se tornar um grande buraco negro. Pois uma análise de código não pode ser confundida com uma linha de produção. É um trabalho que demora muito para ser feito e depende de gente especializada. Devido ao alto volume, à medida que este trabalho for se desenvolvendo, os profissionais tendem a criar estratégias para automatizá-lo ou para torná-lo cada vez mais parcial, somente buscando ameaças em pontos já conhecidos do código. É aí que mora o perigo. Código-fonte não é um monólito. É algo em que é possível esconder muitas funções.

Além disso, quem parte do pressuposto de que os sistemas e a infraestrutura do governo são seguros, precisa dar um passeio no bairro da Santa Ifigênia aqui em São Paulo. Não desconfio que os fontes vazariam facilmente destes ambientes.

Essa medida mais fragiliza o governo do que o protege. A NSA continuará nos monitorando mesmo com isso.

Software livre

Teve gente entendeu essa ideia do Serpro como positiva, pois a queda de braço entre governo e empresas de software com código fechado, obrigaria o Estado a se render aos encantos do software livre.

Sou um apoiador das campanhas pelo uso de código aberto e penso que softwares desse tipo tornam tudo mais transparente e favorecem a cultura do compartilhamento de conhecimento.

Entretanto, não há qualquer indício nesse decreto que diga que o governo vá nessa direção. Na realidade este só quer ter os fontes para checar se não há ali algum backdoor ou outros mecanismos de intrusão e espionagem. Aliás, não há nada no decreto que determine a entrega dos fontes. Isso é pura viagem “all inclusive” na maionese defendida pelo Serpro.

Há mais chance do governo adotar a lógica do fornecedor único. Isso facilitaria a auditoria Vogon, mas criaria um cenário muito parecido com o do processo eleitoral. Vejam os trabalhos do Professor Diego Aranha da UNICAMP a respeito das urnas eletrônicas e entenderão que isso não representa nada em termos de segurança.

Minha recomendação

Lógico que eu não iria ficar aqui atirando pedra na iniciativa do Serpro sem recomendar nada.

Órgão para a definição de padrões

Não sou adepto do complexo de vira-lata, mas penso que é inteligente adaptar boas ideias desenvolvidas em outros países ao nosso cotidiano. Sempre falo que o Brasil precisa ter uma entidade que desenvolva padrões para a configuração de ativos, dispositivos e procedimentos de segurança a serem implementados pelas instituições do Estado. Os estadunidenses possuem o NIST e os europeus o ENISA que determinam desde como uma estação de trabalho deve ser configurada até a maneira como uma instituição deve responder a um incidente de segurança da informação.

O trabalho que estas entidades fazem é tão formidável que até empresas adotam os seus padrões por conta própria, de maneira a proteger os seus ambientes.

Defendo ainda a teoria de que este órgão seja desvinculado do Serpro de maneira a não ser contaminado por flutuações de humor dos governos ou de corporações. Uma boa alternativa nesse sentido é de criar esta entidade sob a estrutura do NIC.br. Organização que em minha opinião possui mais neutralidade, é cheia de profissionais de alto gabarito técnico e que funciona sem a influência direta de grandes corporações ou políticos.

Uso do software livre sim

Esse é o melhor caminho mesmo.

Mas ele não pode vir através de uma medida que determina a auditoria de código-fonte, pois acho que essa iniciativa somente conduz ao caminho do fornecedor único, alinhado ao comportamento Vogon.

O uso do software livre dever ser adotado em uma política de governo que aproveite a transparência das plataformas para adequá-las aos seus padrões, sem deixar também de aproveitar as novas ideias que vão surgindo no percurso.

Monitoramento de perímetro

Com a aplicação de padrões e procedimentos será possível ao governo implementar técnicas de monitoramento do comportamento dos seus ativos, sejam eles baseados em software livre ou não, e atuar objetivamente em casos que fujam à regra.

Auditoria inteligente

Um ambiente organizado e que respeita padrões é muito mais fácil de auditar do que a cacofonia presente nos códigos-fonte da maioria dos produtos. À medida que os padrões vão sendo desenvolvidos, aplicados e atualizados, o trabalho do auditor se torna mais objetivo e simplificado.

—-

Atualização / Correção

A minha menção ao certificado do Serpro acima estava errada porque os certificados ICP Brasil não estavam configurados corretamente nos meus browsers (testei em todos que uso). Decidi manter o trecho para ser sincero com o leitor e não agir como muitos que escrevem bobagens e depois apagam. Ou seja, “mea culpa”. Entretanto isso não invalida meus outros argumentos.