Política de Segurança de Informação: um modelo de como não fazer

Augusto Campos em 20/01/2009

A política de segurança da sua organização é inexistente ou ineficaz, e ainda por cima dificulta que os usuários possam usar os recursos de informática para realizar trabalho legítimo? Você não está sozinho, esta é uma fonte contínua de frustração para bastante gente.

Na verdade, e para ser justo, mesmo quando ela funciona bem, é provável que muitos usuários ocasionalmente sintam que ela é um entrave ao seu desempenho. Mas quando ela não funciona, o efeito é muito mais frustrante.


Batendo na mesma tecla

As causas são bem conhecidas, e não é necessário formação em TI para entender por que as coisas acontecem assim. E a listagem abaixo é justamente isso: uma lista do que deve ser feito se quisermos que a política de segurança de TI não funcione, acompanhada de ocasionais comentários em itálico explicando ou ampliando os itens. Mas a receita oposta (a do sucesso) seja bem mais difícil de definir ;-)

Os comentários em itálico são todos meus, mas a lista original foi publicada há 2 semanas no Internet Storm Center. Eu me esforcei menos para fazer uma tradução fiel, e mais para torná-la suficientemente compreensível para poder ser entendida (com menos jargões, especialmente) por todo mundo que tem interesse no avanço da segurança das informações em suas organizações, e na redução das proibições e restrições desnecessárias ou injustificadas.

Já vai longe o tempo em que eu era administrador de redes e lia diariamente sites como o Internet Storm Center. Mas tanto naquela época como agora eu sempre acreditei que a organização só faz a política - quem faz a segurança são os usuários. E é suficientemente fácil encontrar exemplos de políticas de segurança de informação sendo mal-empregados e gerando mais prejuízos do que benefícios.

Portanto, se a lista abaixo provocar reflexões sobre a situação na sua organização, compartilhe conosco nos comentários!

Vamos à lista!

Política de Segurança da Informação: checklist do que NÃO fazer

Práticas de segurança

  • Espere que os usuários, em prol da segurança, abram mão da conveniência. Abrir mão da conveniência é algo que geralmente se faz só por obrigação imposta, por mais que se compreenda e apóie a política (e se deseje que "os outros" abram mão das suas conveniências), em especial quando as pessoas se percebem impedidas, pela própria organização, de realizar o trabalho que se espera delas.
  • Tranque tanto a infra-estrutura, que trabalhar se torne complicado demais. Complemento do comentário acima. E há um risco adicional: os usuários vão encontrar "jeitinhos", como o uso de cópias locais, versões antigas e mídias não-autorizadas.
  • Diga "não" sempre que lhe solicitarem alguma aprovação. Assumindo que você tenha força suficiente para sustentar um comportamento deste tipo, aí quem vai encontrar jeitinhos serão departamentos inteiros, filiais, e outros agregados.

  • Imponha requisitos de segurança sem as ferramentas e treinamento adequados. Vira letra morta, e ainda por cima custa caro. Segurança precisa ser praticada por todos, o que pressupõe ferramentas e educação.
  • Concentre-se em mecanismos preventivos, ignorando as tecnologias de detecção. Se você acreditar que suas barreiras são inexpugnáveis, corre o risco de perceber o inimigo já agindo livremente dentro delas, tarde demais
  • Não analise logs de sistemas, aplicações e segurança.
  • Não tenha tratamento especial e separação para seus servidores acessíveis via Internet. Se os seus servidores acessíveis via Internet ficarem na mesma rede que os demais computadores da organização, a tendência é que todos os demais computadores estejam bem mais expostos do que deveriam.
  • Assuma que seu gerenciamento de atualizações de sistemas funciona, sem verificá-lo. Basta haver um computador sem uma atualização crítica, para colocar por água abaixo todo o restante do esforço.
  • Apague logs porque eles ficaram grandes demais para ler. Configure-os de acordo, processe-os e leia! Ou arrume quem o faça, regularmente e com muita atenção.
  • Espere que o SSL resolva todas as questões de segurança de seus aplicativos web. SSL é só o mínimo necessário, e o "cadeadinho fechado" no rodapé do navegador não protege contra as falhas na programação ou na arquitetura.

  • Proíba o uso de pen drives, sem delimitar o acesso à Internet. Os mesmos arquivos que podem entrar ou sair via pen-drive podem fazê-lo via uma grande variedade de sites na Internet. Pen drives são uma ferramenta, mas o que deve ser restrito é trazer ou levar os arquivos não autorizados que se queira impedir. Só proibir os pen drives é incômodo e ineficaz.
  • Aja como se fosse superior a seus pares nas demais áreas de TI. Cooperação é muito mais eficaz.
  • Pare de aprender sobre tecnologias e ataques.
  • Adote novas tecnologias antes que elas tenham maturidade suficiente. Folders, livretos, exposições e as conversas dos vendedores devem ser tomados em conjunto com doses saudáveis de consideração.
  • Contrate alguém só porque ele tem um monte de certificações.
  • Não informe seus gestores sobre os problemas de segurança que os seus esforços evitaram. Os seus custos e as dificuldades que você gera, eles vêem. Permita que vejam claramente os resultados também.
  • Não faça treinamento cruzado nas equipes de segurança e TI. Os desenvolvedores, equipes de suporte, operação e manutenção são essenciais na segurança. E os profissionais da segurança precisam conhecer as tecnologias que estão protegendo ou restringindo.

Gestão de senhas

  • Exija que seus usuários troquem de senha com muita frequência. ...e eles adotarão esquemas fáceis de lembrar (e quebrar), ou escreverão as senhas em algum lugar de fácil acesso.
  • Espere que seus usuários lembrem de senhas sem escrevê-las. ...e eles nunca vão trocá-las, ou escolherão sempre senhas fáceis.
  • Imponha requisitos de seleção de senhas que exijam esforço demais. ...e eles as esquecerão com freqüência e pedirão ajuda a terceiros na hora de trocá-las, falando em voz alta a senha que tentaram e qual irão tentar agora.
  • Use a mesma senha em sistemas com níveis de risco diferentes.
  • Deixe de considerar a facilidade com que uma senha pode ser regerada ou zerada. Às vezes com um simples telefonema, sem verificação de identidade.

Política de segurança e adoção de padrões

  • Ignore requisitos legais. Não é razoável: proibir o que uma norma superior permite, permitir o que a lei proíbe, atribuir a si mesmo o poder de realizar verificações ou praticar ações que potencialmente violem direitos alheios. Mesmo assim muita gente tenta, todos os dias, e se dá mal na hora de colocar em prática.
  • Assuma que os usuários irão ler a política de segurança porque você pediu a eles. Eles só o farão se precisarem muito. Publicar pode ser o suficiente para que eles venham a conhecer as linhas gerais, eventualmente distorcidas pela Rádio Corredor. Para que os usuários conheçam uma política detalhadamente, é preciso recorrer a outros meios de educação. Na prática, você não pode assumir nem mesmo que toda a equipe de TI, ou que a maioria dos executivos, vá ler a norma.

  • Use modelos de documentos de segurança sem adaptá-los. E não vale adaptar só um pouquinho. A não ser que a implantação vá ser para fins didáticos.
  • Pule direto para a adoção completa das normas ISO antes de estar pronto. Maturidade, de modo geral, implica em um plano de adoção em várias etapas sucessivas.
  • Crie políticas de segurança que você não poderá fazer cumprir. Uma norma cujo cumprimento não é (ou não pode ser) exigido pode ser até mesmo pior do que a ausência de normatização, e acaba servindo apenas para punir culpados depois que a porta já estiver arrombada e as vacas tiverem fugido do estábulo.
  • Faça cumprir políticas cuja aprovação formal é incompleta ou insuficiente. Especialmente caso exista possibilidade de o caso ir parar no judiciário (mesmo que seja o trabalhista, em caso de penalidade disciplinar), ou houver interações complexas entre departamentos ou áreas da organização.
  • Siga cegamente requisitos das normas, sem criar uma arquitetura de segurança completa.
  • Crie sua política de segurança só para marcar um ponto em uma checklist. Se for só para dizer que tem, aí o melhor é mesmo cumprir apenas os requisitos mínimos e estar preparado para arcar com os resultados. Fazer pela metade sai mais caro, e pode ser tão ou mais ineficaz do que só fazer o mínimo que a norma exige.
  • Contrate alguém para escrever a sua política de segurança sem conhecer sua realidade.
  • Em um ambiente multi-idiomas, traduza a sua política sem manter significados consistentes em todas as traduções.
  • Esconda dos funcionários a sua política. Divulgue a todos, não restrinja a divulgação do que não for informação sensível, preocupe-se com a internalização e adoção na prática.
  • Assuma que se as políticas funcionaram para o ano passado, funcionarão para o próximo. Quantos prédios haviam sido atingidos intencionalmente por aviões de grande porte antes do 11 de setembro?
  • Assuma que atender as normas significa que você está seguro. Atender as normas é só o mínimo necessário.
  • Assuma que as políticas não se aplicam aos executivos. Se houver exceções, elas devem constar na norma, e não podem comprometer sua eficácia. Pouco adianta todo o restante do esforço se um gerente puder trazer um pen drive de casa para instalar um programa ou compartilhar um arquivo em uma máquina da rede local. Uma variante do mesmo erro: "Assuma que as políticas não se aplicam ao pessoal de TI".
  • Esconda-se dos auditores. Se a prioridade é a segurança, não apenas você deve dar as boas vindas a eles, como ainda se esforçar para oferecer a eles uma visão ampla, geral e irrestrita. Mas se a prioridade for apenas obter uma certificação ou atender a uma determinação da matriz, você nem precisaria estar lendo este material.

Ferramentas de segurança

  • Ative uma ferramenta de segurança como veio na caixa, sem configurá-la.
  • Configure o IDS (sistema de detecção de intrusão) para ser sensível demais, ou de menos. Se ele gerar muitos falsos-positivos, você vai acabar ignorando os verdadeiros. Se ele for muito permissivo, pode deixar de detectar alguma intrusão real.
  • Compre ferramentas de segurança sem considerar os custos de ativação e manutenção. Mesmo quando o contrato inclui a implantação e manutenção, há outros custos associados que precisam ser considerados.
  • Dependa de anti-vírus e firewalls, sem controles adicionais.

  • Adote verificações regulares de vulnerabilidades, mas não acompanhe com atenção os resultados.
  • Deixe seu anti-vírus, IDS e outras ferramentas rodando no piloto automático. O custo orçado destas ferramentas deve incluir o valor dos profissionais que precisarão acompanhá-las, gerenciá-las e resolver as situações que elas apontarem, se possível antes que se tornem em comprometimentos.
  • Empregue múltiplas tecnologias de segurança sem entender quanto cada uma delas contribui.
  • Se apresse para comprar produtos caros quando uma correção simples e barata corrigiria sozinha 80% do problema. Corrigir só 80% do problema não é suficiente, mas se é simples e rápido fazê-lo, o ideal é verificar se é possível colocar em prática e depois reavaliar a situação, para ver se a ferramenta cara é necessária para resolver os 20% restantes, ou se outros caminhos surgem.

Gestão de risco

  • Tente aplicar o mesmo rigor a todos os ativos de informação, independente do seu perfil de risco. Fica bem mais caro do que deveria, atrapalha processos sem necessidade, e prejudica bastante a adoção e internalização pelas pessoas envolvidas.
  • Dê a alguém o título de Gestor dos Riscos, mas não lhe dê o poder de tomada de decisões correspondente. Ele terá que optar entre se omitir, ou ser o chato que fica apontando riscos nas atividades alheias podendo ser ignorado, ou ainda saber que está lá só para levar a culpa.
  • Ignore o quadro geral, e se concentre nas análises quantitativas. É mentalmente desafiante e muito interessante aplicar os modelos matemáticos de quantificação de riscos, mas eles não podem substituir a visão do todo, e sim complementá-la.
  • Assuma que você não precisa se preocupar com segurança, porque sua organização é muito pequena ou insignificante.
  • Assuma que você está seguro porque não se tem notícia de que foi invadido recentemente. Será que você foi invadido e nem sabe? É mais comum do que muitos imaginam.
  • Seja paranóico sem considerar o valor do recurso ou o seu fator de exposição. Admitindo que o comportamento paranóico tem seu lugar, mesmo assim é necessário empregá-lo com critério.
  • Classifique todos os seus dados como "top secret". Nivelar por cima, nesse caso, tem praticamente o mesmo efeito que nivelar por baixo.

Leia também:

Comentar

Comentários arquivados

Comentário de Daniel em 20/01/2009 às 11:31:23

Não sei se sou só eu, mas odeio esse tipo de lista extensa do que "NÃO fazer". A maioria dos itens apenas fica com dupla negação, como "Não analise logs de sistemas". Se é para "não não analisar", por que não sugerir diretamente a análise de uma vez? Mas que fique claro que não estou criticando o conteúdo — que aprovei —, apenas a forma como ele foi apresentado. :)

Comentário de augusto em 20/01/2009 às 13:30:23

Eu acho que você cai nessa dupla negação por tentar analisar a lista como algo que ela não é. Tudo seria bastante fácil se, para evitar a armadilha de um comportamento errado, bastasse decidir fazer exatamente o seu oposto. Aí poderíamos partir do "Não analise os logs dos sistemas" e chegar (por meio da resolução da dupla negativa) ao "Analise os logs dos sistemas", e estaria tudo resolvido. Mas as compilações de comportamentos negativos ou más práticas, como é o caso dessa lista, não funcionam de modo tão simples - não basta simplesmente decidir fazer o oposto. Mantendo o mesmo exemplo que você escolheu, eu acredito que para evitar cair no comportamento do "Não analise os logs dos sistemas", seria necessário colocar em prática várias outras decisões, incluindo: - Certificar-se de que todos os sistemas disponibilizem logs em um formato e local conhecido e padronizado. - Certificar-se de que as informações relevantes para a priorização, identificação de exceções, correlação e outros processos estão também disponíveis. - Ter um processo definido de coleta, armazenamento, priorização, identificação de exceções, correlação e outras atividades relacionadas a estes logs. - Dispor dos recursos necessários para realizar os processos acima regularmente. (entre outros itens). Simplesmente passar a ler todos os logs hoje existentes pode não ser uma solução, ou ser uma solução incompleta e bastante ineficiente. Ou seja: as listas negativas apontam os sintomas, e não os remédios. Elas podem ajudar você a descobrir que algo está errado, ou mesmo apontar o que está errado. Elas podem ajudar você a convencer alguém de que algo precisa ser mudado. Mas elas não servem para lhe apontar o jeito certo de fazer as coisas. Para isso existem diversas formações, existem padrões, normas e melhores práticas. Existem vários outros recursos, profissionais e técnicas. Mas a dupla negação das listas deste tipo não é uma delas ;-)

Comentário de Carlos Eduardo em 20/01/2009 às 16:54:29

Acredito que nada substituiu o bom senso na hora de interpretar alguma informação, seja ela escrita ou falada. A lista é bem interessante e infelizmente uma realidade recorrente em muitas empresas até de grande porte. No meu ponto de vista, vejo que nós brasileiros não temos uma cultura de se preocupar com segurança. Pra não ir muito longe, quantos de nós compramos uma licença de anti-virus e a atualizamos com frequência? Ou até mesmo as atualizações críticas de segurança do SO. E para sair um pouco da questão tecnológica da coisa. A própria papelada que muitas vezes possui informações sigilosas não são manipualdas com segurança. Algumas das empresas que atendo imprimem os holerites de pagamento numa impressora que todo mundo tem acesso e pior, até visitantes podem acessar. Acredito que segurança de informação é questão de cultura e partido do que NÃO devemos fazer, fica um pouco mais fácil saber o que PODEMOS e DEVEMOS fazer.

Comentário de Gustavo Bittencourt em 21/01/2009 às 09:53:05

Concordo com o Daniel, é muito fácil dizer o que não fazer. Mas quando a questão é dizer o que fazer, tudo se complica. Pegando como exemplo as ações citadas pelo Augusto para gestão de log: "Certificar-se de que todos os sistemas disponibilizem logs em um formato e local conhecido e padronizado." A padronização de log de todos os sistemas de uma empresa é uma utopia. Qualquer empresa razoavelmente informatizada utiliza pelo menos um centena de sistemas. Nas maiores, esta ordem chega a dezenas de milhares. Que pagará o custo de adequação dos sistemas, sejam eles desenvolvidos interna ou eternamente, sob medida ou de prateleira, departamentais ou corporativos? Quem pagará o custo contínuo de inventariar TODOS os sistemas da organização incluído a informação de local de armazenamento de seus logs? "Certificar-se de que as informações relevantes para a priorização, identificação de exceções, correlação e outros processos estão também disponíveis." A "correlação de eventos" é conceito muito "bonitinho" no papel mas de difícil execução. É claro que existem sistemas de correlacionamento de eventos, mas estes sistemas não são baratos, e a sua manutenção, para que seja efetivos, exige mão-de-obra cara, dedicada e especializada. "Ter um processo definido de coleta, armazenamento, priorização, identificação de exceções, correlação e outras atividades relacionadas a estes logs." Aplicar este processo a todos os sistemas? Se sim, conheço empresas que geram logs na ordem de terabytes/dia, realizar coleta, armazenamento, priorização (seja lá o que isso queira dizer), identificação de exceções, correlação de eventos, etc. é muito muito caro e frequentemente inviável. Se não, quem define na organização quais sistemas deverão ter seus logs tratados desta forma e com que critério deve ser realizada esta definição? "Dispor dos recursos necessários para realizar os processos acima regularmente." Custo, custo, custo, quem paga tudo isso?

Comentário de augusto em 21/01/2009 às 10:08:33

Sim, não há dúvida de que não é nem simples, nem fácil, e nem barato.

Comentário de Vinícius em 21/01/2009 às 19:02:11

Quanto aos logs extensos o suficientes para inviabilizar seu tratamento tradicional, soube recentemente que existem algumas empresas brasileiras especializadas em automatizar a análise de grandes blocos de texto (por exemplo, logs) utilizando técnicas de Data Mining. Em primeira vista pode parecer caro, mas dependendo do que se procura nesses logs, o gasto com segurança passa a ser investimento.

Comentário de webster em 24/01/2009 às 01:48:29

Parabéns pelo artigo, Augusto. Você sempre diligente, hein! Este texto vem bem a calhar àqueles que não podem deixar morrer seus sistemas corporativos ou homólogos. Embora eu já conhecesse algumas dessas dicas professadas por você, de ouvido ou lendo, gostei.

Comentário de João Henrique em 24/01/2009 às 14:02:58

Pra facilitar a gestão de senhas pelos usuários, as empresas podem disponibilizar (ou seja, sugerir, divulgar, faciltar o acesso, dar suporte) o KeePass, disponível no Portable Apps. No meu último emprego mesmo tinha 5 senhas que precisavam ser trocadas de vez em quando, fora a da pelada

Comentário de Jeronimo Zucco em 24/01/2009 às 17:00:33

“Ter um processo definido de coleta, armazenamento, priorização, identificação de exceções, correlação e outras atividades relacionadas a estes logs.” Entre os ítens acima, me parece que somente a correlação entre os eventos o OSSEC não faz, e é software livre: http://www.ossec.net

Comentário de Ricardo Castro em 04/08/2009 às 17:10:57

Prezado Augusto, Parabéns pelo artigo que na minha visão é o reflexo de uma realidade de todas as instituições. Como Gerente de TI vivencio diariamente não questões tecnológicas mas sim humanas. Gerenciamento de egos e ruídos atualemnte dependendo de onde venha pode derrubar uma Política de Segurança que foi elaborada a N mãos durante tanto tempo. Estamos sempre negociando. Recentemente passamos pelo problema de troca de senha (periodicidade e complexidade). Tivemos que rever a política e no final acabou tudo bem. att Ricardo

Comentário de Fabio em 12/11/2009 às 11:30:23

Dizer oque não deve ser feito é muito fácil, todos nós sabemos disso. Esquecemos de um detalhe importante:" lidamos com seres humanos", onde por sua vez tem um sentimento complexo e livre arbitrio. O ser humano mudaria um pouco o conceito sobre de segurança(nada é realmente seguro), se o negócio fosse dele, ai sim daria atenção maior para o negócio. No meu ponto de vista, tudo está na vontade e na ética. Temos muitos analistas de segurança que são negligentes com os negócios, partindo por esse ponto. A discussão não é fácil Abraços

Comentário de douglas de freitas em 17/02/2010 às 14:21:16

não entendi o que ele falou...

Comentário de Patrícia Lins em 10/05/2010 às 18:34:44

Embora seja Engenheira Eletricista, sou apaixonada por segurança da informação. Achei o artigo muito legal, particularmente nunca trabalhei na área de administração de redes ou segurança da informação propriamente dita, então, meu conhecimento nesta área é essencialmente teórico, e cheguei aqui justamente procurando um artigo, tutorial, post falando de políticas de segurança na prática e encontrei. Parabéns, muito bem escrito, deu para aprender mais um pouco de segurança da informação.

Comentário de cleberson em 04/06/2010 às 17:54:57

não entendi nada se alguem poder me esplicar por favor me ajude.

Comentário de Thomaz em 14/09/2011 às 03:37:33

Há endereços físicos que estão na Internet, mas somente acessam o sistema interno onde a comunicação com o cliente é só via mailing. Há ambiente tão fechado que não tem nem comunicação por e-mail informal com o cliente. Só a página da intranet. Há endereços físicos, que tem Internet que as páginas são entregues pela rede da matriz o que em alguns casos a conexão não é otimizada o plano de Internet com a operadora na matriz e torna o sistema lento, onde a filial a conexão não pode usar todo o seu potencial. Ainda os problemas são muito básicos. "Depende muito de quem vende a solução e de que compra". Na realidade toda a estrutura no final é uma coisa só. Hoje já há bons parques de hardware. Na rede o que falta é além de a matriz aumentar a sua velocidade, é a questão dos Rack para montagem de servidor/switch ter melhor guarnição. E quanto a acessos centralizar a autenticação e tornar o ambiente produtivo. Painel de controle próprio com a lista de instalações homologadas é o ideal quanto à setup. Quanto a membro de admins e users, preferencialmente após uma boa imagem todos devemos ser users. E com uma série de modificações para as ferramentas homologas terem funcionalidade e automação de verdade com criptografia descente. Quantos admins se logam como admins? Além é claro de um sistema de callcenter de comunicação unificada com helpdesk onde exista analista de hardware e software antecedido de training onde não seria necessário técnico de campo. Empresas exclusivas trabalham com reconhecimento facial e excelente sistema de compreensão de backup o que é exclusividade repito. Hardware com webcam vai mudar este cenário. Rede social interna ajuda a testar usuários de redes de computadores. O que já é um pré-requisito para a assistência e programas de treinamento. Quanto a terminais burros, o nome já diz, tem função limitada, ainda a um grande caminho a evoluir com a compatibilidade de softwares de segurança e suporte a outras soluções. Compensa hardware completo individual. Quanto à impressão o que é muito importante para comunicação, cada usuário deveria ter sua própria impressora, mas não por comodidade, mas produtividade e segurança. Quanto a smartphones imposição de controles é uma questão também de treinamento da exposição de informações, do que é promoção e o que é risco, que neste caso poucas empresas dão suporte a celular da empresa que recebe ligação da URA. Muitos admins perdem totais acessos a um sistema remoto por vários motivos que poderiam ser evitados.