Pau pra toda obra AppLocker: ’S é primeira segurança panacéia?

Greg Shields

Conteúdo

Aplicativos Whitelisting
AppLocker: Mais de SRP versão 2
Uma implantação Simple de AppLocker

Existe um ditado persistente em nosso setor que nada é uma panacéia. Definido como uma “ solução para todos os diseases, evils ou dificuldades ”, panacéia oft oferecida mas neverrealized representaria a solução IT para finalizar todas as soluções.

É a sabedoria convencional que nenhum produto único nunca totalmente pode oferecer essa correção one-stop para todos os seus problemas, não importa como disco rígido vendedores do produto podem tentar convencer você caso contrário. Ainda em Explorando a nova funcionalidade AppLocker no Windows 7 e Windows Server 2008 R2, preciso saber se Microsoft ficou fechar.

Para compreender completamente o poder do AppLocker, pense sobre noções básicas de manutenção de segurança do sistema. Malware é uma ameaça constante. Se ele infecta os sistemas por meio de um navegador da Internet ou enviado por meio de um ataque de worm estilo, ele às vezes, sobrecarregar até mesmo a melhores firewalls e mecanismos de anti-malware. Além disso, mesmo com uma abordagem em camadas para a segurança em seu ambiente, a combinação dessas ferramentas pode nunca ser preparada para esse ataque de zero-day temido.

Ainda há um segmento comum entre praticamente todas as peças de malware: Seu código deve ser processada para que ele danificar seus sistemas.

Esse único ponto aumenta a pergunta para administradores: "Se praticamente todo o malware requer processamento para ser perigosas, pode proteger-me impedindo que o processamento ocorra em primeiro lugar?"

A resposta: Absolutamente. E a solução para esse problema é AppLocker.

Aplicativos Whitelisting

AppLocker tem suas raízes na tecnologia de diretiva de grupo chamada diretivas de restrição de software (SRP), que apresentou com o Windows XP e Windows Server 2003. SRP introduziu o conceito de blacklists e whitelists em relação a permitido e permitido executáveis em um domínio do Windows. O conceito é simples:

• Com uma lista de bloqueio, você, o administrador, identifica os executáveis específicos que não são permitidos da execução em computadores em seu domínio. No momento da inicialização, processos são verificados em relação a lista de bloqueio antes que está sendo executado. Se um processo está na lista de bloqueio, execução é impedida e, em vez disso, é apresentada ao usuário com uma mensagem de erro.
• Com uma lista branca, o oposto se torne verdadeiro. Usando uma lista branca, você em vez disso, especificar os processos que têm permissão para executar em seus computadores. Lançado processos serão verificados em lista branca antes da execução. Apenas aqueles na lista branca têm permissão para executar;os não na lista branca são impedidos de sendo executado.

Com SRP, um desses dois paradigmas era possível, com o padrão enfocando blacklisting de aplicativos. Com o passar do tempo, no entanto, ficou óbvio que o conceito de whitelisting poderia ser muito mais poderoso. Enquanto whitelisting envolvidos mais trabalho, porque cada aplicativo aprovado para executar tinha que ser inseridos a diretiva, ele era um método potente para impedir tudo.

Na verdade, aproveitando o paradigma de whitelisting do SRP, um ambiente pode especificar quais aplicativos tinham testados, verificados e aprovados por seus administradores e a diretiva de segurança. Tudo — incluindo a maioria dos formulários da execução de malware e outros aplicativos quasi-legitimate não aprovados por IT — poderia ser negado explicitamente a execução. Nenhum processamento, nenhum malware, nenhuma infecção.

Mas ao simples no conceito, tecnologia do SRP era dolorosa na implementação. Apesar de sua capacidade, SRP foi implementada por apenas um ambientes muito poucos. Determinar o conjunto exato de aplicativos aceitáveis era um processo complexo e trabalhoso com pouco suporte de automação. Fazer até mesmo um pequeno erro em uma diretiva de grupo SRP pode significar a prevenção de execução de software todos os no domínio. Muito arriscado e muito administrativamente complexo em sua configuração, raramente SRP tornaram para a maioria dos ambientesradars.

AppLocker: Mais de SRP versão 2

Tecnologia do AppLocker se destina a aumentar níveis de adoção incorporar funcionalidade de gerenciamento melhor. Integrado muito mais rigidamente os sistemas operacionais Windows Server 2008 R2 e Windows 7, AppLocker aproveita os conceitos do SRP para criar uma solução mais utilizável.

A primeira forma na qual AppLocker melhora sobre SRP é por meio da adição de um modo de aplicação auditoria somente (consulte do Figura 1). Nesse modo, computadores configurados e executável regras apenas relatório onde ocorrem violações de diretivas. Combinando auditoria somente imposição modo do AppLocker com uma lista vazia branca, é possível identificar rapidamente os tipos de aplicativos que estão sendo executados em computadores em todo o domínio. Com informações de auditoria que está sendo depositadas no log de eventos AppLocker cada computador, detalhes sobre esses aplicativos e de seus executáveis podem ser documentadas para a imposição posterior.

Figura 1 AppLocker no modo somente de auditoria. (Clique na imagem para uma visão ampliada)

Um segundo mecanismo melhora a criação de regra com um assistente automatizada. Encontrado na diretiva de grupo do AppLocker console é uma seleção para regras para gerar automaticamente (consulte do Figura 2). Essa opção inicia um assistente que irá verificar qualquer estrutura de arquivos em um computador de referência, procurando por arquivos executáveis. Qualquer executável encontrado em suas subpastas ou o caminho atribuído pode ter uma regra gerada automaticamente para ele. Apontando o assistente em direção a um computador de referência com software comuns do seu ambiente de instalado automaticamente gera uma lista de regras. Essa lista pode ser usada como o ponto de partida para posterior personalização.

Figura 2 do AppLocker automaticamente gerar executável do Assistente de regras (clique na imagem para ampliá-la)

AppLocker também simplifica a geração de regra reduzindo o número de classes de regra para três. Eles estão projetados para ser usado em combinação, e você descobrirá que cada classe de regra fornece uma abordagem diferente para limitar a execução de software:

• Regras de caminho criar uma restrição com base no nome ou local do arquivo do executável. Por exemplo, uma regra de caminho pode ser criada para um determinado nome de arquivo (sol.exe) ou uma combinação de nome de arquivo e o curinga (sol*.exe) para capturar limitadas modificações para um nome de arquivo. Os curingas também podem ser usados em combinação com caminhos de arquivo (%ProgramFiles%\Microsoft Games\ 1).
• Regras de hash do arquivo são criadas para superar algumas limitações óbvias com regras de caminho. Usando uma regra de caminho, um executável pode ser acessado, movendo-out de um caminho gerenciado ou alterando suficientemente seu nome de arquivo. Um hash criptográfico de um arquivo gerenciado usando uma regra de hash do arquivo, é criado. Basear regras fora do arquivo hashes significa que eles permanecem gerenciados não importa onde estão localizados no sistema. Enquanto isso aumenta a segurança da solução geral, se torna seu desvantagem óbvia como arquivos são alterados com o tempo devido a patches ou atualizações. Por esse motivo, uso de regras de hash do arquivo requer adicionais devido cuidado como software é atualizado.
• Regras do Publisher requerem que o executável gerenciado é assinado digitalmente. A assinatura digital permite que o arquivo ser restringido com base em seu editor, nome do produto, versão nome do arquivo e o arquivo. Escala de uma tabela variável e valor personalizado opção oferece a capacidade de ajustar as características que você se preocupa com você e que são opcionais. Por exemplo, é possível restringir um arquivo com base em seu editor, nome do produto e nome de arquivo ao definir um caractere curinga para a versão de arquivo (consulte a Figura 3). O resultado líquido: Quaisquer atualizações de versão posteriores a esse arquivo serão aprovadas automaticamente.

Figura 3 criando e personalizando uma regra do publisher. (Clique na imagem para uma visão ampliada)

Uma adição útil final é a capacidade para criar exceções especiais associadas a qualquer classe de regra. Essas exceções permitem uma definição mais deles executáveis são permitidos para execução, como opposed que são impedidos. Por exemplo, você pode permitir a execução de qualquer executável em %ProgramFiles%\Microsoft Office\ 1 pasta, mas impedir WINPROJ.EXE especificamente devido a restrições ou outras razões de licenciamento.

Porque AppLocker configurações geralmente são criadas por meio da diretiva de grupo, a atribuição de regras de prevenção de execução pode ser voltada para computadores no seu ambiente ou usuários individuais. Dentro o grupo Diretiva de gerenciamento Editor (GPME), as configurações de AppLocker definidas para computadores estão no local configuração do computador | diretivas | configurações do Windows | configurações de segurança | diretivas de controle do aplicativo. As definidas para os usuários estão no mesmo local em configuração do usuário. Assim, qualquer combinação de configurações focalizado no computador e usuário pode ser feita com base no aplicativo da diretiva de grupo. Mesclar a diretiva é aditivo, significado que não substituam a diretiva de grupo ou Substituir regras já está presentes em um GPO (vinculado grupo Diretiva de objeto). Atribuído por meio de diretivas de grupo de regras serão aplicadas usando a mesma ordem de aplicativo como GPOs tradicionais.

Agora, principal limitação do AppLocker está relacionada com as versões de sistema operacional aplicará suas regras. No lado do cliente, apenas 7 do Windows Ultimate e no Windows 7 Enterprise podem participar em AppLocker regra imposição. Para servidores, qualquer edição do Windows Server 2008 R2, exceto para o Windows Web Server e Windows Server Foundation irá impor regras AppLocker. Enquanto a Microsoft pode back porta essa funcionalidade em versões anteriores do sistema operacional, esse recurso atualmente adiciona à lista de atraentes razões para uma atualização do Windows 7. (Quando este texto, nenhuma informação foi liberada sobre uma porta back possível para versões anteriores do sistema operacional.)

Um elemento de compatibilidade boas notícias: Base de diretiva de grupo do AppLocker não requer nenhuma atualização de controladores de domínio (DCs) para oferecer suporte a distribuição de suas diretivas. Windows Server 2003 existente e controladores de domínio do Windows Server 2008 podem hospedar AppLocker diretivas.

Uma implantação Simple de AppLocker

Se AppLocker adicionado sons de segurança útil ao seu ambiente pequeno, as próximas etapas envolvem a implementação da solução. Obviamente, implementação não ocorrer até que tenha atualizado uma porcentagem dimensionável de seus desktops e laptops para o Windows 7. Sistemas operacionais anteriores ao Windows 7 e Windows Server 2008 R2 não aplicar AppLocker regras, mas eles respeitarão as aplicadas por meio SRP. Enquanto as regras SRP e AppLocker não conversíveis diretamente, as informações reunidas através auditoria somente modo do AppLocker podem ser convertidas manualmente para uso no SRP.

Implantar AppLocker envolve várias etapas, começando com determinar como implementar a tecnologia e criação de um computador de referência para isolar o seu conjunto inicial de aplicativos. Lembre-se de que, ao contrário do SRP, aplicativo ­ Bloqueador padrão a suposição de que você criará uma lista branca de aplicativos. Embora seja possível criando uma arquitetura de lista de bloqueio, isso não é recomendável simplesmente porque essa abordagem não fornece o mesmo poder de prevenção de execução oferecido pelo whitelists.

No seu documento intitulado "planejamento e implantação Windows AppLocker diretivas"Microsoft descreve um processo de nove etapas para implementar o aplicativo ­ Bloqueador em um ambiente. Enquanto este documento está em beta quando este texto, a versão disponível no momento inclui significativo detalhes sobre como criar uma infra-estrutura AppLocker completa corretamente. Para fins de simplicidade, aqui no entanto, são algumas etapas que você precisa começar.

Primeiro, crie uma lista de aplicativos que sua organização de TI considera aceitável para execução. Você pode criar esta lista manualmente por Entrevistar proprietários dos aplicativos na organização. Ou você pode começar criando e interrogar um computador de referência que contém os aplicativos normalmente disponíveis em sua empresa. Iniciar esse processo criando a instância de SO — ou -o usando sua solução de implantação de imagem favorita de imagem — e garantir que os aplicativos direito são instalados. No computador, você também deve instalar as RSAT (Toolkit de administração de sistemas remoto) para Windows 7, que pode ser encontrado no site da Microsoft. A RSAT inclui os componentes GPME necessários para criar regras de AppLocker.

Quando estiver pronto para análise, crie um novo GPO e iniciá-lo dentro o GPME. Navegue até Configuração do computador | diretivas | configurações do Windows | configurações de segurança | diretivas de controle do aplicativo | AppLocker e clique o link no painel à direita para configurar a imposição de regra. Na janela resultante, verifique a caixa marcada configurado em regras de executável e definir a regra a auditoria somente. Esta configuração mantém seus comportamentos existentes em sistemas gerenciados ao relatar AppLocker violações de regra no log de eventos local.

Você perceberá que essa janela possui uma guia Avançado, no qual você pode escolher ativar a coleção de regras DLL. AppLocker tem a capacidade de criar regras com base em DLLs em adição aos arquivos executáveis. Enquanto você pode implementar essa configuração para segurança adicional, isso adicionará uma carga extra administrativa pois você precisará isolar e configurar regras para todas as DLLs em seu ambiente em adição aos arquivos executáveis. Como um arquivo executável pode aproveitar várias DLLs, essa tarefa pode ser uma dor de cabeça de gerenciamento. Habilitando regra DLL coleção também terá impacto sobre desempenho do sistema porque o processamento de cada DLL será requerem validação antes de execução.

A próxima etapa é configurar o conjunto padrão de regras do executável. Clique o subnó AppLocker o mesmo nome com o botão direito do mouse e escolha para criar regras padrão. Três regras são criadas por padrão. Duas permitir a execução de todos os arquivos nas pastas do Windows e arquivos de programas, enquanto a terceira (mostrada na do Figura 4) permite que os membros do grupo Administradores local para executar todos os aplicativos. Essa terceira regra exclui efetivamente administradores locais do processamento de regras.

Figura 4 padrão regra excluindo administradores locais de prevenção de execução. (Clique na imagem para uma visão ampliada)

Uma vez que for concluída, clique novamente com o botão direito do mouse o nó regras executável e optar por gerar regras automaticamente. Este assistente irá interrogar o computador local para executáveis potencial para criação de regra, por isso, deve ser executado no computador de referência. Por padrão, o assistente procurará executáveis no caminho C:\Program Files, embora caminhos alternativos que podem ser verificados por editá-los nas opções do assistente.

Clicar em Avançar no assistente leva você à tela preferências de regra. Aqui, você tem a opção para criar regras de editor para arquivos que são assinados digitalmente ou para criar regras de hash para todos os arquivos. Regras de caminho podem ser criadas automaticamente nesta tela, mas somente quando arquivos já ainda não foi assinados digitalmente por seus editores. Clicando em Avançar novamente conclui a verificação do sistema e leva você para uma tela onde você pode analisar a lista de regras. Regras que você não deseja criar poderá ser eliminadas clicando no link para examinar os arquivos que foram analisados, em seguida, desmarcar a caixa de seleção ao lado para os arquivos apropriados. Depois que for concluída, clique em criar.

Concluir esta tarefa em um sistema Windows 7 recém-criado adiciona quatro novas regras. Embora poucos mais arquivos executáveis são encontrados neste local, o assistente irá por padrão grupo regras juntos para simplificar seus aplicativos. Neste ponto, se você sentir como monitoramento para outros tipos de executáveis, é possível configurar regras para scripts e executáveis baseados no Windows Installer nesse mesmo local GPME.

Neste ponto, o GPO será começar a configurar clientes de destino com base na participação em OU. Como a diretiva de aplicação de regra é definida para auditoria somente, nenhuma restrição de execução, na verdade, irá ocorrer. Durante esse período, é uma boa idéia para pesquisar os logs de eventos em vários sistemas gerenciados para ver se as regras são úteis para o seu ambiente ou se seu aplicativo poderia impedir um executável necessário a execução. Use essas informações para ajustar o conjunto de regras existentes para que funcionem corretamente para o seu ambiente.

Quando você estiver pronto para mover de relatórios sobre executáveis, na verdade, impedindo-los, apenas navegue volta para o nó AppLocker o GPME e altere as propriedades de aplicação de auditoria somente para impor regras.

Obviamente, você precisará de projeto mais planejamento e teste prior to implantação. Mas estas etapas simples serão exibida ao iniciar. Enquanto AppLocker pode não ser a panacéia de segurança completo, suas capacidades para impedir que todos os mas seu absolutamente aprovadas executáveis de execução significa que se trata realmente, realmente fechar.

Greg Shields, MVP, é um parceiro em Concentrated Technology. Obtenha mais 'ShieldsGeek de All Trades dicas e truques em do ConcentratedTech.com.