Segurança

O grande debate: segurança pelo disfarce

Jesper M. Johansson and Roger Grimes

À primeira vista:

• Definindo a segurança pelo disfarce
• Avaliando a segurança por medidas de disfarce
• Estimando o valor de renomear a conta Administrador
• Tomando decisões fundamentadas quanto ao gerenciamento de risco

O termo "segurança pelo disfarce" costuma ser recebido com indiferença pelo pessoal da segurança, especialmente por aqueles que desejam se considerar especialistas. Praticamente um palavrão em alguns círculos, a segurança

pelo disfarce, como observado na Wikipedia (en.wikipedia.org/wiki/Security_through_obscurity), representa um dos aspectos mais verdadeiramente controversos da segurança. Muitas vezes, você verá referências jocosas a pessoas cujos esforços são tidos como sendo "apenas de segurança pelo disfarce".

A segurança pelo disfarce é, em poucas palavras, uma violação do Princípio de Kerckhoff, que sustenta que um sistema deve ser seguro por conta de seu design, e não porque este é desconhecido por um adversário. A premissa básica do Princípio de Kerckhoff é de que segredos não permanecem assim por muito tempo.

Como bom exemplo disso, considere o protocolo de autenticação NTLM (Windows NT® LAN Manager), que era inicialmente considerado um segredo de design. Para implementar o produto de interoperabilidade Samba destinado a sistemas operacionais baseados em UNIX, a equipe do Samba precisou fazer engenharia reversa no protocolo. O resultado foi a documentação mais abrangente sobre o protocolo NTLM disponível (monyo.com/technical/samba/translation/ntlm.en.html), bem como a descoberta de vários bugs. Como grande parte da segurança surgiu da criptografia e muitos designs secretos foram revelados, muitos praticantes da segurança acham que toda a segurança das informações deve seguir o Princípio de Kerckhoff.

Mas a segurança pelo disfarce é sempre ruim? Neste artigo, explicaremos o que é a segurança pelo disfarce, tentaremos esclarecer por que muitos consideram-na perda de tempo (e outros, não) e mostraremos por que a resposta, como sempre, é muito mais complicada do que parece à primeira vista.

Introdução à segurança pelo disfarce

Padrões da não-alteração por Steve Riley

Fico do lado dos que "não alteram" no problema da renomeação. Na verdade, nem se trata de uma questão de segurança; é um problema de gerenciamento de sistema. E como passei mais tempo pensando no espaço de gerenciamento dos sistemas (porque gerenciamento e segurança estão se tornando uma coisa só), me tornei cada vez mais adepto de não fazer nada que possa aumentar a fragilidade do sistema. Uma forma segura de aumentar a fragilidade é alterar os padrões das coisas. Há duas (tudo bem, três) razões pelas quais as pessoas alteram as configurações padrão:

• Existe um requisito conhecido quanto à funcionalidade que a alteração fornece.
• Há uma pressuposição de que a alteração melhorará a segurança.
• (Alerta: bobagem à frente.) Alguém leu sobre isso em um artigo de revista.

Caso você precise alterar um nome padrão por conta do motivo número um, vá em frente. Esses tipos de alteração raramente resultam na instabilidade de um sistema, normalmente porque já foram testados.

Caso esteja alterando um padrão diante do motivo número dois, antes pare e reconsidere. Esses tipos de alteração quase nunca são testados pelo fabricante do software e, por isso, este não pode prever como o sistema se comportará depois que você fizer a alteração. Além disso, normalmente existem alternativas muito melhores que fornecerão efetiva segurança.

E se um mau elemento fica sabendo o nome de uma conta? E aí? É a senha e sua força que mantêm a pessoa mal-intencionada longe do sistema. A necessidade de alterar nomes de conta padrão como Administrador e Convidado para algo não tão difícil de adivinhar costuma ser, na realidade, um indicativo do desejo de evitar senhas fortes ou senhas. Corrija o problema efetivo (segredos perdidos), e será possível evitar a fragilidade (alterando os nomes padrão).

A segurança pelo disfarce não inclui medidas que não fazem absolutamente nada para reduzir um problema. Por exemplo, uma organização que bloqueie o protocolo NNTP nos roteadores de borda para impedir que os funcionários leiam grupos de notícias, mas que permita o protocolo SSH, não está usando a segurança pelo disfarce. Como o SSH pode encapsular todos os protocolos, o problema não é disfarçado; a redução inválida implementada deixa de fazer tudo senão impedir que usuários legítimos realizem tarefas legítimas sem violar as diretivas de segurança. Essas medidas não são de segurança pelo disfarce; elas são apenas inválidas e inúteis.

Como a própria palavra "segurança" na locução "segurança pelo disfarce" já diz, você tem alguma proteção com a medida. No entanto, o que também fica implícito – e esse é o problema – é que você, na verdade, não está fazendo nada a fim de parar um ataque em um ou mais vetores. (Um vetor de ataque é, essencialmente, um meio pelo qual um invasor pode acessar um sistema.)

Suponhamos que você tenha um servidor Web vulnerável, por exemplo, que possa ser atacado pela porta TCP 80 usando uma exploração pública. Para fechar esse vetor em especial, é possível corrigir o servidor Web ou desativá-lo; qualquer uma das ações pararia completamente esse vetor. Você poderia parar parcialmente o vetor de ataque usando um firewall ou IPsec para fechar a porta 80 em todos os computadores, exceto alguns selecionados. Isso não bloquearia completamente o vetor de ataque, mas reduziria o problema de maneira significativa.

Por outro lado, a segurança pelo disfarce envolve tomar algumas medidas que não param o vetor de ataque, mas meramente o ocultam. Por exemplo, você pode optar por mover o servidor Web para a porta 81, e não a 80, para que apenas aqueles que saibam onde encontrar o servidor Web consigam fazer isso. Ou é esse o argumento. Na verdade, mover o servidor Web para a porta 81 pára apenas alguns ataques, sendo, em grande parte, uma inconveniência para o usuário final. Um intruso competente simplesmente executaria um scanner de porta e um elemento de destaque de faixa da Web em um grande número de portas para descobrir servidores Web em portas que não fossem padrão. Assim que encontrar uma, ele poderá ativar a exploração no servidor porque você não eliminou, de fato, o vetor de ataque; você apenas (temporariamente) o ocultou.

Isso significa que você não deve ao menos tentar? A resposta... depende. Assim como acontece com quase tudo no campo da segurança das informações, tudo se resume ao gerenciamento de risco. Para compreender os principais fatores a serem considerados, observaremos rapidamente mais algumas medidas de segurança pelo disfarce e, em seguida, abordaremos uma – renomear a conta Administrador – mais detalhadamente.

Avaliando medidas de segurança

São inúmeros os exemplos de segurança pelo disfarce. Eles podem ser ações realizadas por gerenciadores de sistema e de rede ou iniciadas por desenvolvedores de software. No entanto, o que eles têm em comum é que pretendem reduzir uma vulnerabilidade a ocultando de invasores potenciais.

Alguns desses procedimentos não podem apresentar ao menos algum efeito benéfico? É mesmo justo dizer que a segurança pelo disfarce é de todo ruim? Você certamente encontrará propositores de pelo menos algumas dessas medidas. Por exemplo, no Windows®, é possível ocultar as letras da unidade no Windows Explorer. Muitos ambientes, notadamente laboratórios de computadores em escolas, usam essa técnica para evitar que os usuários salvem os dados no disco rígido. Obviamente, como a maioria dos aplicativos ainda pode salvar dados no disco rígido, isso agrega pouco valor como medida de segurança final. No entanto, as instituições que a implementaram normalmente dizem que ela reduz dados no disco rígido.

Outra prática do tipo de segurança pelo disfarce normalmente implementada no Windows é desativar os compartilhamentos de rede administrativos (como, por exemplo, C$, Admin$ etc.). Isso foi pensado para impedir que um invasor seja capaz de se conectar remotamente ao computador. De fato, isso não é apenas verdade, como um invasor com uma conta capaz de usar os compartilhamentos administrativos pode reabilitá-los remotamente. Ainda assim, muitas organizações juram que desabilitar esses compartilhamentos reduz a incidência de malware nas redes.

Um dos nossos exemplos favoritos de esforço mal empregado é a configuração "permitir desencaixe sem fazer logon" no Windows. Caso seja desabilitada, o botão "desencaixar" permanece oculto na tela de logon. A idéia por trás disso é que, dessa forma, um invasor não pode desencaixar o computador a tempo. Obviamente, qualquer intruso pode simplesmente colocar o computador e a base de encaixe em uma sacola e sair por aí com eles, independentemente da visibilidade desse botão. Essa possibilidade sequer é de segurança pelo disfarce.

Outro exemplo claro é a configuração "permitir que operadores do servidor agendem tarefas", que, exatamente como seu próprio nome diz, permite a usuários membros do grupo Operadores de Servidor agendar tarefas. Trata-se de um problema confidencial porque essas tarefas podem ser executadas como Sistema Local e apenas os administradores devem ser capazes de agendar tarefas executadas como Sistema Local. É claro que os operadores de servidor podem se fazer administradores por meio de um número qualquer de vetores diferentes, logo, impedi-los de agendar tarefas dessa maneira tem, na verdade, um valor mínimo.

Ainda assim, muitas organizações gostam dessa configuração porque ela permite que os engenheiros sejam operadores de servidor, e não administradores, o que significa ser menos provável que eles destruam acidentalmente o servidor. Isso, por si só, pode trazer algum benefício.

Então qual é o veredicto? Obviamente, alguns desses problemas podem ser bem complicados. Passamos momentos agradáveis debatendo esses tipos de medida. Roger segue firmemente no time dos que acham essas práticas importantes. Jesper, por outro lado, acha que elas são, na melhor das hipóteses, perda de tempo na maior parte dos casos. Exploremos um dos casos mais citados – e controversos – em termos de segurança pelo disfarce: renomear a conta Administrador. Roger argumentará em favor da medida; Jesper, contra. Nomes importantes da segurança como Aaron Margosis e Steve Riley também fazem suas ponderações nas barras laterais "Renomear a conta Administrador" e "Padrões da não-alteração", respectivamente.

Ocultando a conta Administrador

Renomear a conta Administrador, RID (identificador relativo) 500, para algo desconhecido pelo público geral costuma ser recomendado por profissionais de segurança e está entre os muitos guias de proteção da Microsoft. Até mesmo a Diretiva de Grupo inclui uma configuração para renomear a conta Administrador, como mostrado na Figura 1. A idéia é de que se a conta Administrador for renomeada, um invasor terá mais dificuldade ao fazer logon como sendo o verdadeiro administrador. É claro que o problema mais óbvio em relação ao uso da Diretiva de Grupo nessa operação é que a conta Administrador renomeada terá o mesmo nome em todos os computadores nos quais esse Objeto de Diretiva de Grupo foi aplicado. Isso diminui o valor de disfarce dessa medida de segurança em especial.

Figura 1** Renomeando a conta Administrador **(Clique na imagem para uma visão ampliada)

Neste contexto, também é importante observar que qualquer usuário com uma conta legítima pode recuperar o nome da conta Administrador, independentemente de ter sido renomeada ou não. O RID da conta Administrador é sempre 500. Solicitando o nome da conta cujo RID é 500, qualquer usuário com uma conta pode ver o que é realmente chamado, como mostra a Figura 2.

Figura 2** Localizando contas Administrador renomeadas **(Clique na imagem para uma visão ampliada)

A vez de Roger

O principal argumento que ouço contrário à renomeação da conta Administrador é que é muito fácil converter qualquer nome de conta principal no SID (identificador de segurança) relacionado e descobrir seu RID. E o RID da conta Administrador verdadeira é sempre 500. Assim, caso um invasor possa facilmente converter nomes de conta de usuário nas combinações SID/RID e achar o RID 500, por que se preocupar?

Mas não é tão simples. Para conseguir conversões do nome da conta de usuário em SID/RID, você deve ter acesso às portas NetBIOS ou LDAP. Como a maioria dos firewalls de perímetro não permite esse tipo de acesso pela Internet, até ignorar totalmente o firewall, o invasor não converterá nada. Além disso, conversões anônimas de SID não funcionam no Windows XP e em versões posteriores do Windows, exceto nos controladores de domínio. Nos computadores mais externos (aqueles sob o maior risco), o invasor precisaria de credenciais autenticadas para fazer conversões de nome em SID.

Assim, há um número considerável de obstáculos de defesa reais que devem ser ignorados para que se inicie um ataque de conversão. E mesmo que chegue tão longe, o invasor acaba no mesmo ponto em que estaria se o nome da conta não tivesse sido renomeado. Renomear a conta Administrador só pode aumentar a segurança. Mal certamente não fará.

Trata-se de um outro segredo Caso o invasor não saiba o nome da conta Administrador, este se torna mais um rótulo "secreto", semelhante a uma senha, que um invasor precisa conhecer. Tudo bem, é provável que os nomes de conta de usuário sejam significativamente menos complexos do que uma senha administrativa, mas continua sendo mais um obstáculo que complica exponencialmente o problema da adivinhação/descoberta da senha. Caso já tenha feito testes de penetração de senha, você sabe como é muito mais difícil adivinhar tanto o nome de usuário quanto a senha. Isso constitui uma tarefa já difícil e a dificulta ainda mais.

Barra malware automatizado e script kiddies Tenho atuado na defesa da segurança do Windows há 22 anos e executado 8 iscas do Windows, expostas à Internet, nos últimos 5. Durante todo esse período, jamais vi um malware automatizado (que constitui a grande maioria de todos os ataques) ou sequer usei qualquer rótulo de conta que não fosse Administrador (ou raiz, no caso dos sistemas *NIX). Se renomear a conta Administrador, você interromperá imediatamente todo o malware dependente do nome de administrador. E isso se traduz em um menor risco de segurança.

O mesmo acontece com script kiddies. Todos os manuais de hackers do Windows "kewl" que conheço mencionam técnicas de conversão nome em SID, mas, por alguma razão, jamais vi um caso desses em minhas iscas, mesmo que também tivesse uma conta Administrador "falsa" como saída. Bons hackers devem sempre verificar se a conta Administrador encontrada é a real (RID 500), mas eles não fazem isso. Não sei por quê. Acho que a culpa está na preguiça dos hackers e no comportamento humano desprezível.

Além disso, pára a maioria dos profissionais Isso surpreende a maior parte das pessoas. Quando executa iscas já há alguns anos, você reconhece rapidamente as diferenças entre ataques automatizados, script kiddies e profissionais. Nos últimos cinco anos, com milhões de ataques informados em relação às minhas iscas, jamais vi os profissionais fazerem conversões de SID com a presença da conta Administrador falsa.

Não tenho certeza se alguns criminosos profissionais realizam a conversão de SID, mas estou propenso a apostar que se trata de uma pequena minoria, e uma que jamais documentei. Por que os profissionais não fariam isso? Acho que eles não vêem nenhum motivo para tentar algo quando quase todo o mundo não está.

Simplifica o alerta Agora, a oposição pode argumentar que, se a renomeação da conta Administrador sobressaísse, ela perderia seu valor como técnica de disfarce. O argumento é de que malware, script kiddies e profissionais mudariam suas táticas padrão para procurar nomes diferentes de apenas Administrador. E essa é uma preocupação válida. Felizmente, isso não altera a condição essencial. Primeiro, caso a conta super privilegiada não seja nomeada Administrador, o hacker mal-intencionado deve se esmerar mais. E isso é fato. E caso tenha de trabalhar mais arduamente, é menos provável que o hacker mal-intencionado tente essa avenida de ataque, o que talvez possibilite que uma das demais técnicas aprofundadas de defesa por deslocamento detecte a atividade mal-intencionada mais rapidamente.

E isso me leva à minha última observação em favor da renomeação. Caso a conta Administrador jamais tenha se chamado Administrador e você crie uma outra com esse nome, como mostrado na Figura 3, há aí um bom mecanismo de alerta. Caso o monitoramento de evento detecte uma tentativa de logon usando o nome padrão, trata-se de um evento a ser explorado imediatamente.

Figura 3** Tentativas de logon usando uma conta de nome Administrador falsa podem servir como um aviso antecipado **(Clique na imagem para uma visão ampliada)

Os nossos logs de eventos estão repletos de logons "inválidos" que não significam nada. Normalmente, trata-se apenas de um usuário (ou o Windows) tentando fazer logon usando uma senha inválida ou algo do gênero. Porém, caso a conta se chame Administrador, como é possível separar facilmente as tentativas de logon válidas das mal-intencionadas? Se jamais teve uma conta de logon Administrador e detectar uma tentativa de logon usando esse nome de conta, você saberá que, provavelmente, existe má intenção. Um aviso antecipado silencioso é muito valorizado na defesa atual.

A vez de Jesper

Renomear a conta Administrador por Aaron Margosis

Jesper, em um mundo ideal, você estaria absolutamente correto. As senhas sempre seriam fortes o suficiente para inviabilizar a adivinhação por força bruta e as contas administrativas locais -500 só seriam usadas na recuperação de emergência. Porém, no mundo real, nada disso acontece.

Apesar da grande divulgação da segurança feita e, em especial, da série de senhas fantástica criada por você ("Grandes debates: Frases secretas X senhas", partes 1, 2 e 3, em go.microsoft.com/fwlink/?LinkId=113157; go.microsoft.com/fwlink/?LinkId=113159 e go.microsoft.com/fwlink/?LinkId=113160), muitos administradores de sistema não têm uma compreensão atualizada do que constitui uma senha forte.

Não faz muito tempo que uma senha composta por oito caracteres aleatórios tirados de vários conjuntos de caracteres era forte; a Lei de Moore tornou isso obsoleto. A educação do usuário (e do administrador do sistema) é um elo frágil e deverá continuar assim até que, pelo menos o tópico da senha forte se torne um item polêmico a ser debatido nos canais de notícias das redes de televisão.

Sendo assim, considerando que a adivinhação de senha no mundo real não demore 600 bilhões de anos e possa, pelo contrário, ser feita durante o almoço, adicionar um multiplicador x1000 pode ter um valor real. E contra os muitos ataques automatizados tendo em vista a conta Administrador, renomeá-la a torna invulnerável.

O tempo e o esforço normalmente envolvidos na renomeação da conta administrativa costumam ser baixos; geralmente, como você observou, trata-se de uma configuração de GPO simples. Na verdade, a U.S. Government's Federal Desktop Core Configuration (csrc.nist.gov/fdcc) exige a renomeação da conta -500. Renomear é apenas uma das muitas configurações obrigatórias, e não a que vi exigindo uma enorme quantidade de tempo ou atenção. Nem vi ninguém se acalmando com um falso sentido de segurança a respeito do valor – ainda tenho que ouvir alguém dizendo: "não precisamos de gerenciamento de patches porque renomeamos as nossas contas administrativas".

A renomeação tem algum valor quando a conta está renomeada da mesma forma em toda a organização? Embora não seja grande, existe um certo valor: primeiro, bloqueia ataques automatizados que esperam Administrador e, segundo, o conjunto de invasores potenciais não é necessariamente um subconjunto de "todos" aqueles que conhecem o novo nome. (O maior risco é quando contas administrativas locais – renomeadas ou não – compartilham uma senha em toda a organização. Gerenciá-las permanece sendo o maior e mais importante problema. Desabilitar a conta -500 é uma forma de resolver isso, embora bloqueie uma avenida de recuperação importante quando as contas de domínio não podem ser usadas.) Também indicarei que nossos guias de segurança recomendavam há muito a renomeação das contas padrão, logo, isso foi bem testado e é totalmente aceito.

Acho que, agora, todos nós sabemos que as medidas de disfarce – por si – não constituem uma defesa adequada. Porém, elas podem aprimorar outras medidas de segurança, e os dados de Roger mostram isso claramente. Desde que o custo da implementação seja baixo, as organizações não devem descartá-la.

Assim com acontece com os argumentos favoráveis, há argumentos válidos desfavoráveis em relação à renomeação da conta Administrador. Antes de entrar nisso, porém, devo admitir que a última observação feita por Roger é extremamente válida. No entanto, em um ambiente altamente gerenciado, qualquer logon com a conta Administrador deve ser investigado porque ela jamais deve ser usada senão em situações de recuperação de emergência.

Isso é supérfluo O principal risco que a renomeação da conta Administrador deve reduzir é o de alguém adivinhar a senha remotamente. Mas somente um usuário que não tivesse outra conta autorizada no computador seria barrado com a renomeação da conta Administrador. Esse invasor normalmente tentaria uma série de senhas aleatórias para fazer o logon na conta Administrador. No entanto, ele receberia a mesma mensagem de erro, independentemente de ter adivinhado ou não o nome da conta e a senha.

Isso sugere que um dos principais argumentos a favor da renomeação da conta Administrador – o de que os script kiddies vão embora – é fraco. Eles não vão embora antes com o nome original da conta Administrador alterado porque não sabem disso! Eles adivinharão o mesmo conjunto de senhas aleatórias, independentemente do que seja e, em seguida, passarão à próxima vítima potencial.

Isso significa que, enquanto a senha da conta Administrador for forte o suficiente para repelir ataques, renomear a conta não agregará valor algum. Digamos que haja uma senha com 15 caracteres em nossa conta Administrador, composta de letras maiúsculas e minúsculas, números e símbolos escolhidos de todo o teclado. Adivinhar essa senha pela rede levará aproximadamente 591.310.404.907 anos. Em termos comparativos, isso é cerca de 43 vezes mais do que a existência do universo.

Agora, digamos que a conta Administrador tenha sido renomeada, e criamos um dos 1.000 valores possíveis. Estenderíamos o tempo de adivinhação da senha para 591.310.404.906.787 anos, ou 43.161 vezes a existência do universo. Estamos mais seguros? Obviamente, estamos três mil vezes mais seguros. Conseguimos tornar mais improvável a adivinhação da nossa senha por parte do invasor? Bem, isso é infinitamente pequeno em ambos os casos. Em outras palavras, em termos reais, não estamos, de forma alguma, melhores do que com o nome original da conta Administrador. Não é só porque renomear a conta interrompe o malware que tenta usá-la que isso significa que haveria êxito do malware se você não tivesse renomeado a conta. Na verdade, se usasse uma senha forte, como deve, você poderia praticamente impedir que ele obtivesse êxito, independentemente do nome da conta.

Fica claro que grande parte das diretrizes de segurança exige a renomeação da conta Administrador, mas isso não faz dessa uma medida de segurança importante, ou mesmo válida. Ela simplesmente retira a possibilidade de tomar uma decisão apropriada quanto ao gerenciamento de risco. Os guias de segurança apresentam configurações que costumam ser muito exigidas, mas que não fazem diferença e que, em muitos casos, sequer existem. Para acabar progredindo no campo da segurança, precisamos dar um passo adiante em termos de requisitos e analisar efetivamente os problemas, além de avaliar se as reduções têm sentido ou não. É importante se lembrar de um ponto crítico aqui: o fato de um invasor estar se direcionando para um recurso não é, por si, motivo suficiente para modificar esse recurso. Você só deve modificar um recurso se tiver uma expectativa justificável de que um invasor terá êxito, a menos que você modifique o recurso.

Se nós pressupusermos uma senha forte, a probabilidade de êxito será efetivamente zero, independentemente da renomeação da conta. Por isso, desde que conte com uma senha forte, você não tem nenhuma razão especial de segurança para renomeá-la. Além disso, se você, assim como eu, operar de acordo com o princípio de que um computador será provavelmente mais estável quanto menos ajustes e alterações fizer nele (um fato bem estabelecido, a propósito), aí é que não haverá mesmo razão para renomear a conta Administrador.

Muda o foco para reduções de valor inferior Um problema com as reduções pela segurança de valor inferior pelo disfarce é que elas tiram o foco das reduções de valor superior na organização. Por exemplo, o tempo e o esforço colocados na renomeação da conta Administrador não podem ser usados em mais nada. Caso esse nada forneça valor superior à renomeação das contas Administrador, a organização perdeu uma oportunidade. Esse talvez não pareça ser um custo real, mas imagine renomear 50.000 contas Administrador, e você vai entender do que estamos falando.

Pior ainda é a possibilidade bem real de que a liderança da organização descanse assim que a redução de valor inferior esteja in-loco. A gerência talvez nem sempre compreenda o valor mínimo fornecido pelas reduções da segurança pelo disfarce e pode não executar etapas adicionais. Isso pode efetivamente oferecer um risco significativo para a organização, ainda que esse risco possa ser tranqüilamente evitado com o simples emprego de tempo e esforço na compreensão do valor das reduções que estão sendo implementadas.

Caro de gerenciar Por fim, dependendo da qualidade de implementação da redução, seu gerenciamento pode ficar bastante caro. Caso você defina apenas um GPO (Objeto de Diretiva de Grupo) para renomear a conta Administrador, o custo é bem baixo. Todos saberão o nome, e o custo da implantação é praticamente zero. No entanto, o valor que isso fornece também é praticamente mínimo porque, como disse, todos com uma conta saberão qual é o nome. Por isso, para obter um determinado valor dessa redução, você precisa usar nomes diferentes em hosts diferentes, e o gerenciamento do sistema acaba ficando caro.

Você estaria muito melhor usando uma ferramenta como passgen (protectyourwindowsnetwork.com/tools.htm) para definir uma senha totalmente aleatória de 100 caracteres em todas as contas Administrador em toda a rede e usar contas diferentes no gerenciamento diário. Considerando que a conta Administrador é essencialmente para fins de recuperação de desastre (exceto no Windows Small Business Server 2003), isso não deve causar muito impacto no sistema do gerenciamento de rede. Além disso, o invasor teria uma chance maior de encontrar uma agulha no fundo do Oceano Pacífico do que adivinhar a senha de qualquer uma das contas Administrador. Já se concentrando em senhas exclusivas e fortes, os script kiddies podem continuar adivinhando o que quiserem.

É tudo uma questão de gerenciamento de risco

Praticamente toda medida de segurança pelo disfarce pode ser analisada na forma que fizemos aqui. Há prós e contras em qualquer esquema, e a abordagem certa para uma organização não necessariamente se adapta a uma outra organização. No final das contas, esse acaba sendo um problema de gerenciamento de risco. Os riscos superam os custos da implementação da solução? Toda decisão tomada por você quanto à proteção dos ativos de informações deve ser uma decisão de gerenciamento de risco bem informada, e raramente as opções são preto e branco.

É verdade: algumas decisões já foram tomadas para você. Por exemplo, embora seja plenamente possível optar por não criptografar informações de cartão de crédito ou armazenar os códigos de verificação do cartão de crédito, qualquer uma das ações deverá resultar em uma perda da possibilidade de aceitar cartões de crédito como forma de pagamento. O provável impacto negativo dessa decisão para a empresa é que você não tem, de fato, uma opção. Em outras palavras, embora essa seja, em grande parte, uma decisão de gerenciamento de risco, se trata de uma fácil de tomar.

Da mesma forma, também é verdade que ninguém, em sã consciência, conectaria uma rede sem fio aberta ao back-end da rede em uma loja física. Porém, isso não significa que a decisão não seja de gerenciamento de risco. Ela é. Alguém pode optar por fazer isso e, se assim o fizer, deverá sofrer as conseqüências (que parecem jamais acontecer de fato, infelizmente).

A etapa chave a ser executada aqui é articular claramente o problema que precisa resolver, as soluções propostas para ele e os prós e os contras de cada uma. Tendo isso, você conta com as informações necessárias para tomar uma decisão de gerenciamento de risco. Sem essas informações, você está tomando decisões com base em uma desconfiança, e essas raramente são boas decisões.

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 Microsoft em segurança corporativa. Seu livro mais recente é Windows Server 2008 Security Resource Kit.

Roger Grimes (CPA, CISSP, MCSE: segurança), consultor em segurança sênior da equipe ACE da Microsoft, é autor ou colaborador de oito livros sobre segurança de computadores e autor de mais de 200 artigos em revistas. Ele é assíduo palestrante em conferências sobre segurança e colunista de segurança da InfoWorld.

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