Security WatchPrincípios da segurança quantum

Jesper M. Johansson

Pode ser bastante divertido lançar algo inesperado, mas importante, em meio a uma conversa. Há algum tempo, tenho usado o Princípio da incerteza de Heisenberg para explicar conceitos de segurança. (Aqueles que conhecem a minha história do unicórnio sabem que gosto de usar teorias elementares de outras disciplinas para fazer uma observação.) Estranho

quanto isso possa parecer, de fato existem corolários de segurança da informação quanto a alguns conceitos fundamentais em outros ramos da ciência.

O Princípio da incerteza de Heisenberg, que vem da física quantum, se baseia na equação mostrada na Figura 1. O princípio propriamente dito indica que a posição de uma partícula (p) e o momento favorável de uma partícula (x) estão de tal forma relacionados que, caso aumente a precisão da medição da posição, você aumenta a precisão da medição do momento favorável. O limite relacionado à precisão dos dois fatores é um pequeno múltiplo fixo da constante de Planck. Traduzindo, esse princípio diz que não é possível observar com total precisão determinados fatos sobre uma única partícula simultaneamente.

Figure 1** Heisenberg Uncertainty Principle **

Isso está diretamente relacionado à previsão de faixas indeterminadas, que basicamente permitem prever o nível de incerteza quanto ao estado de alguns fatos sobre uma partícula. Embora não seja possível (ainda) prever as faixas, é importante o fato de não ser possível prever com certeza como duas variáveis em uma única rede de computadores afetarão a segurança dessa rede.

Você também deve assumir contrapartidas. Embora você talvez não esteja associado à constante de Planck na segurança das informações, existe uma associação mesmo assim. A contrapartida mais evidente que você tem de assumir se dá entre a segurança e a usabilidade ou a utilidade. Caso você ignore a disponibilidade por um momento – e, francamente, acho que a equipe de segurança não deve ser responsável por outra disponibilidade que não seja a relacionada a ataques de negação de serviço –, a forma mais fácil de proteger algo é o desativando. Dessa forma, o hacking deixa de ser possível. Já a utilidade requer um mergulho de cabeça.

Da mesma forma, embora o custo seja significativamente maior, é possível evitar o vazamento de dados muito mais confidenciais implementando um produto caro de prevenção contra a perda de dados do que enviando um email para todos os funcionários uma vez por ano lembrando-os de que os aplicativos de sistema de mensagens instantâneas não se destinam ao uso corporativo. Mas a organização está disposta a pagar pela ferramenta de prevenção contra a perda de dados? Em termos de segurança, agora é possível ver onde a física quantum adquire mais relevância do que você poderia imaginar.

Gato de Schrödinger

Um conceito de física quantum relacionado, embora diferente, é explicado na parábola do gato de Schrödinger. A história dá conta de que Erwin Schrödinger, um proeminente físico do século 20, travava uma longa batalha no campo dos argumentos com Albert Einstein (outro proeminente físico do século 20 do qual você já deve ter ouvido falar) sobre o conceito da superposição. Schrödinger descobriu as áreas da mecânica quantum que apresentava elementos existentes em uma superposição de dois estados próximos do absurdo.

Para fazer sua observação, Schrödinger desenvolveu um experimento conceitual no qual um gato era colocado em uma caixa fechada hermeticamente. O outro item na caixa era um frasco de veneno cuja liberação era controlada por meio de uma partícula radioativa subatômica (imaginária). Se a partícula radioativa diminuísse, o veneno seria liberado, e o gato morreria.

A partícula subatômica, estando sujeita às leis da mecânica quantum, existe em uma superposição de estados. O gato decididamente atômico, dado seu estado sendo totalmente dependente do estado da partícula subatômica, também existe nessa superposição de estados. Somente observando, de fato, o estado do gato é que podemos finalmente colocá-lo em um estado específico de vida ou de morte.

Schrödinger, obviamente, pretendia com isso ilustrar como são absurdas algumas leis da mecânica quantum quando aplicadas a sistemas atômicos. Contudo, seu exemplo costuma ser creditado com ênfase naquilo que os homens do Direito chamam de "efeito observador". O efeito observador, embora não se aplique a sistemas subatômicos importantes na mecânica quantum, é interessante para nós, profissionais da segurança. Simplificando, ele diz que ao observar algo, você o altera.

O efeito observador

Para explicar isso um pouco melhor, considere o exemplo de uma xícara de chá. Para saber se o chá está quente, você coloca um termômetro na xícara. Digamos que o chá esteja a 80 graus Celsius quando você coloca o termômetro, e este esteja a 22 graus (temperatura ambiente). Assim que você coloca o termômetro no chá, ele começa a absorver calor do chá, que cede parte do calor para aquecê-lo. Ao final do processo, o termômetro e o chá acabarão apresentando a mesma temperatura. No entanto, essa temperatura não será nem de 80 graus, nem de 22 graus; ela estará em algum ponto intermediário. Portanto, medindo a temperatura do chá, você a altera.

O efeito observador também é relevante para a segurança das informações. Sempre que faz algo para reduzir um problema de segurança, você pode acabar modificando sua postura em relação a ela por modificar o sistema. Chamarei isso de SPFE (efeito de fluidez quanto à postura de segurança) por falta de um termo melhor.

Um dos exemplos mais simples é o caso das dependências da conta de serviço. No capítulo 8 do Protect Your Windows Network (protectyourwindowsnetwork.com), abordo a instalação de um IDS (serviço de detecção de intrusões) nos sistemas para detectar ataques. No entanto, o IDS faz logon em um sistema central e exige acesso privilegiado aos sistemas monitorados. Na maior parte do tempo, isso significa que o serviço é executado em uma conta de serviço com alto privilégio.

Caso algum desses sistemas seja comprometido, o invasor pode obter acesso às credenciais da conta de serviço e acessar todos os demais sistemas, além de desabilitar o próprio IDS. Trata-se de um exemplo perfeito do SPFE. Instalando algo para garantir segurança no ambiente, é possível criar um novo problema de segurança em potencial.

Há muitos outros exemplos de SPFE. A descrição feita por Steve Riley do porquê o 802.1x apresenta determinados problemas em redes com fio (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx) é outro grande exemplo. Obviamente, usar firewalls baseados em host é algo extremamente desejável em muitos ambientes. No entanto, caso seja usada com 802.1x, a combinação possibilita um determinado ataque onde ele não era possível antes. Mais uma vez, uma tecnologia modifica a postura em relação à segurança do ambiente e possibilita um ataque que antes não era possível.

Nada disso significa que essas medidas sejam naturalmente inúteis e que devam ser evitadas. O que isso significa é que você precisa considerar as implicações daquilo que faz em termos de segurança no geral. Ao realizar o gerenciamento de risco, você deve considerar o significado real das ações e das prevenções para o risco. Ao atenuar um problema, você não pode simplesmente parar depois de implementar as contramedidas. Em um sentido bem próximo do real, segurança é um processo. Você precisa usar a estratégia de defesa aprofundada, mas considerando como as defesas alterarão a sua postura em relação à segurança e como você abordará as novas ameaças decorrentes da estratégia.

Uma estratégia de proteção experiente

Trabalho nas diretrizes de proteção há mais de 10 anos. Revendo os primeiros guias nos quais trabalhei, percebo que eles não eram nada mais do que listas de configurações que meus colegas e eu pensávamos que você deveria ativar. Naquele momento, a estratégia geral por trás da segurança era ingênua – basicamente, caso algo devesse fornecer segurança, a lógica era de que ele precisava estar ativado. Não se dava muita atenção ao fato de que talvez houvesse motivos legítimos para que ele fosse desativado inicialmente.

Acabei aprendendo que, para que haja uma proteção efetiva, você precisa dar muita atenção à proteção e considerar as ameaças às quais o sistema está sujeito. Essa revelação acarretou a lista de cenários que você vê no Windows 2000 Security Hardening Guide (go.microsoft.com/fwlink/?LinkID=22380). A evolução natural disso era dividir as diretrizes em níveis de ameaça diferentes, que é o que você vê no Windows Server 2003 Security Guide (go.microsoft.com/fwlink/?linkid=14846).

Durante todo esse tempo, me inconformava com o fato de que ainda era possível dividir um sistema mesmo com todas as diretrizes ativadas e in-loco. Isso porque havia patches não-encontrados – alguma prática operacional me inteirou disso –, ou porque algum software inseguro de terceiros foi instalado.

Acontece que a proteção nesses dois guias não fez muito para ajudar na postura de segurança agregada. Tudo se resumiu a algumas coisas especiais. Na verdade, o sistema mais seguro que já criei (msdn2.microsoft.com/library/aa302370) empregava apenas quatro ou cinco dos ajustes contidos nesses guias de segurança e nenhum deles de fato parava qualquer um dos ataques aos quais estava sujeito. Infelizmente, as pessoas querem apenas um grande botão azul "Proteger-me agora" que protegerá automaticamente os sistemas, mas segurança é mais complicada do que isso.

Como abordar riscos

Para estar protegido (em contraposição ao estado finito da segurança), você deve usar uma abordagem razoável em relação aos riscos. Você deve compreender os riscos que está enfrentando, decidir qual deles deseja atenuar e, em seguida, compreender como atenuá-los, e isso raramente é feito com o simples lançamento de opções.

Em geral, essas opções de segurança são projetadas para cenários específicos e não necessariamente criam a melhor configuração para o seu. Na verdade, elas criam um bom ponto de partida na linha de base e são disponibilizadas principalmente porque o mercado exige esses ajustes de proteção rápidos. Por padrão, a maioria já está ativada em softwares modernos e os que não estão certamente apresentam efeitos colaterais significativos.

Além disso, lançar muitas opções pode produzir um sistema sem suporte e instável que talvez não execute as tarefas que você precisa realizar – todas para atenuar as ameaças que você ainda não enumerou. O SPFE e a física quantum nos dizem para refazer a análise depois de protegermos as coisas, mas muitas organizações deixam de fazer isso. Na verdade, elas sequer analisam as ameaças inicialmente. Se começar, de fato, analisando as ameaças, você descobrirá que as coisas que realmente fazem diferença não são restrições anônimas quanto à listagem dos nomes de conta e de todas as alterações feitas na lista de controle de acesso.

Na verdade, o que realmente faz a diferença é determinar se o sistema deve fornecer um determinado serviço, a quem em caso afirmativo e, em seguida, impor essa diretiva. O que faz a diferença é verificar se apenas os sistemas e os usuários que, de fato, precisam se comunicar com você têm permissão para isso. O que faz a diferença é verificar se todos os aplicativos são executados e os usuários contam com os menores privilégios possíveis. Em suma, o que faz a diferença é usar uma abordagem sensata em termos de segurança e realizar a análise das dificuldades de forma que você permita a cada sistema assumir a responsabilidade por sua própria segurança.

É por isso que a abordagem atual em relação à segurança agora emprega ferramentas como Server and Domain Isolation (microsoft.com/sdisolation), ACS (Assistente de Configuração de Segurança) nos produtos Windows Server® e as ferramentas no gerenciamento de funções do Windows Server 2008. Essas ferramentas orientam você durante o processo de compreensão dos cenários para os quais deve dar suporte e, em seguida, ajudam a bloquear os sistemas da maneira apropriada. Tudo bem, essas ferramentas não oferecem a solução completa que todos querem, embora proporcionem uma configuração com suporte que, de fato, realiza as tarefas pelas quais você comprou o software.

Aplicar segurança onde necessário

Tudo isso quer dizer ser possível confiar em outras entidades ou simples ajustes em termos de segurança. Cada ativo deve ser capaz de se defender sozinho porque conceitos como, por exemplo, "perímetro" e "rede interna" não querem dizer nada atualmente.

A grande maioria das redes organizacionais é, na melhor das hipóteses, semi-hostil. Você precisa compreender isso e executar as etapas apropriadas sem depender exclusivamente das diretrizes de proteção automáticas. Para começar, você deve compreender suas necessidades. Além disso, você deve procurar diretrizes de outras pessoas que também compreendam essas necessidades.

Recentemente, um convidado em um webcast recomendou que usuários de pequenas empresas visitassem o site do Departamento de Segurança Interna e baixassem um guia de proteção para o Internet Explorer®. Por que você deve esperar que uma agência governamental encarregada de proteger a ordem de segurança nacional e militar forneça diretrizes sobre como proteger um navegador da Web em pequenas empresas? Trata-se de um exemplo perfeito de uma lógica ineficiente que ainda prevalece no campo da segurança do computador. A pressuposição é de que como as diretrizes foram emitidas por uma agência governamental de três letras, logo, os resultados devem ser altamente seguros.

A opção costuma ser apresentada como uma decisão binária: é possível ter "segurança alta" ou "segurança baixa". Uma forma melhor de apresentar essa opção é entre "segurança alta" ou "segurança apropriada". Segurança não tem tamanho único.

Na verdade, segurança alta não é para todos – e normalmente não é para a maioria! Não se trata de uma meta final que você deva buscar. Trata-se de uma configuração especializada para sistemas em que as pessoas morrerão se o sistema for comprometido. Caso isso seja adequado ao seu perfil de risco e modelo de ameaça, use alta segurança.

Caso isso não seja adequado ao seu perfil de risco e modelo de ameaça, você deve usar algo mais apropriado. É mais do que provável que um dos ajustes que é possível configurar já esteja, por padrão, apropriadamente definido como nível de um perfil de risco moderado. Esse estado padrão, usado na maioria dos produtos Microsoft atuais, garante uma contrapartida razoável entre segurança e usabilidade, utilidade e desempenho. Até onde se estende, a proteção é feita normalmente para você.

Agora você precisa considerar outras etapas da segurança. Um bom local para começar seria o TechNet Security Center (microsoft.com/technet/security) e, é claro, livros como o Windows Server 2008 Security Resource Kit.

É tudo uma questão de gerenciamento de risco

Agora você já deve ter notado aonde quero chegar com isso: gerenciamento de risco. A principal mensagem do Princípio da incerteza de Heisenberg é que você tem contrapartidas. Essa parte do princípio não é uma grande descoberta.

Porém, a mensagem da história do gato de Schrödinger é algo que grande parte das pessoas deixam de levar em conta. Não é importante apenas que você analise todos os lados da questão e tome uma decisão quanto às contrapartidas, mas também considere as alterações introduzidas pelas soluções. Uma boa estratégia de gerenciamento de risco considera como essas alterações afetam o sistema e se elas foram implementadas como parte de uma estratégia de atenuação de risco ou por alguma outra razão.

Expectativa de perda anual

A forma mais comum de quantificar o risco, além de ser o método que você aprende em vários cursos de certificação em segurança, é a equação ALE (expectativa de perda anual), mostrada na Figura 2. A ALE padrão é muito simples. Você determina a probabilidade de um incidente e o custo de cada ocorrência e, em seguida, multiplica os dois valores. Isso resulta na quantia que você deve pagar pelos incidentes de segurança anualmente. Caso o custo do risco seja alto o bastante, você implementa a atenuação.

Figure 2** ALE is the probability of a loss, multiplied by the cost of the loss per incident **(Clique na imagem para aumentar a exibição)

O problema disso é que a ALE padrão deixa de compensar o custo da atenuação. Não apenas a atenuação tem um custo próprio, mas também muitas atenuações têm efeitos colaterais, que também têm um custo associado.

Considere um dos ajustes de segurança mais usados: o bloqueio de conta. Muitas organizações implantam o bloqueio de conta ostensivamente para impedir que os invasores adivinhem senhas. É possível calcular matematicamente a probabilidade de um invasor adivinhar qualquer senha. Caso seja criativo, você também pode imaginar um custo médio da violação resultante do êxito de um invasor ao adivinhar uma senha. Com base nesses dois números, muitas organizações decidiram que a ALE é inaceitável e, por isso, implementaram o bloqueio de conta.

No entanto, essa atenuação em especial tem um custo que você talvez não esteja levando em conta. Existe o custo da implementação da atenuação propriamente dita, é claro, embora ele seja mínimo. Para ser preciso, o cálculo também deve incluir os custos dos efeitos colaterais resultantes da atenuação.

Inicialmente, há um custo associado ao desbloqueio das contas dos usuários por parte do suporte técnico. Caso uma conta seja bloqueada por um curto período, digamos, 15 minutos, ainda existe um custo da perda de produtividade nesse período. Esse fator é contabilizado como sendo o custo de cada incidente, multiplicado pela probabilidade de ocorrer o incidente nesse determinado período. Nesse caso, você multiplicaria o custo pelo número esperado de eventos de bloqueio – um número que os logs talvez já sejam capazes de fornecer.

Você também precisa levar em consideração o fator agravante do usuário. Uma evidência curiosa indica que os usuários usarão senhas menos complicadas se estiverem sujeitos ao bloqueio de conta porque a possibilidade de digitá-las incorretamente é menor. Por isso, a probabilidade do incidente que queremos evitar não chega integralmente a zero depois da implementação da atenuação.

Por fim, talvez haja vulnerabilidades introduzidas pela atenuação que não estavam presentes no sistema antes de sua introdução. No caso do bloqueio de conta, um invasor pode usar esse recurso para desabilitar todas as contas na rede simplesmente adivinhando repetidamente as senhas de maneira incorreta. Existe a probabilidade de que isso também ocorra, além do custo associado de cada incidente.

Levando em conta todos esses fatores, fica claro que você deve modificar a equação da expectativa de perda. Primeiramente, você deve modificar a probabilidade do incidente. Agora a possibilidade de ocorrência do incidente deve ser menor que antes, embora, como você viu anteriormente, ela talvez não chegue inteiramente a zero. O custo de cada incidente também pode ter sido alterado. Para o produto em questão, você precisa adicionar o custo da própria atenuação. Esse custo é composto pelo custo de implementação mais a soma do custo anual de todos os efeitos colaterais. Todos esses custos anuais são o produto da probabilidade de ocorrência do efeito colateral e do custo de cada incidente desse efeito colateral. Simplificando um pouco a apresentação da equação, agora você tem a equação da análise de risco mais precisa mostrada na Figura 3.

A equação aprimorada na Figura 3 oferece uma forma muito mais precisa de analisar o risco de um determinado problema. Muitas organizações já analisaram seus riscos dessa forma. Mas muitas ainda contam com uma visão simplificada do risco que não aponta adequadamente a necessidade de análise do impacto das atenuações. Usando a equação ALE modificada, você está colocando essa necessidade à frente e no centro de tudo.

Figure 3** Considering the additional costs of mitigation **(Clique na imagem para aumentar a exibição)

O que tudo isso significa

Se você só fizer algo depois de ler este artigo, será preciso questionar a sabedoria convencional por trás das estratégias de segurança. Muito do que fazemos no campo da segurança das informações se baseia em uma visão de mundo bastante estereotipada. E muitas das pressuposições agora estão ultrapassadas.

Os ataques mudaram. Os invasores agora são profissionais, estão nisso por dinheiro, pela supremacia nacional e por ideologia. Não é possível perder tempo e dinheiro em ajustes que não aumentem a segurança. Isso também quer dizer que você deve usar uma abordagem muito mais sofisticada em relação ao gerenciamento de risco.

Primeiro, é importante que você observe que tudo o que faz tem uma contrapartida. Não é possível saber tudo com a mais absoluta certeza.

Segundo, você deve compreender que a operação se dá em um sistema independente. Introduzindo alterações de segurança no sistema, você modifica o próprio sistema, o que significa que deve analisá-lo novamente.

Isso deve ser feito, preferencialmente, antes da implementação efetiva dessas alterações porque é muito comum que elas tenham tal impacto sobre o sistema que fazem mais mal do que bem. Usando ferramentas de análise melhores, as quais lembram a necessidade de análise dessas alterações, você terá menos chances de se esquecer delas.

Por fim, jamais se esqueça do fator humano. Tudo o que você faz na segurança de informações é permitir que a empresa e os usuários da organização trabalhem com a maior segurança possível.

Em uma apresentação recente, comentei que não havia um único usuário atual que comprasse seu computador de forma que pudesse executar um programa antivírus. A segurança é o seu objetivo principal, mas não o da empresa. As organizações que meramente toleram a segurança por isso estar em seus interesses fazem isso momentaneamente. Jamais se esqueça de que o grupo de segurança de informações está lá para atender à empresa, e não o contrário. Se você ignorar esse fato, os usuários farão qualquer coisa para concluir seus trabalhos, mesmo que isso signifique driblar controles de segurança que não compreendem ou com os quais concordam.

Jesper M. Johanssoné arquiteto de software e trabalha na segurança de software, além de ser editor colaborador da TechNet Magazine. Ele possui PhD em sistemas de informações sobre gerenciamento, tem mais de 20 anos de experiência em segurança e é MVP (Most Valuable Professional) Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..