Experto en varios temas AppLocker: ¿TI ’s primer seguridad panacea?

Greg Shields

Contenido

Aplicaciones whitelisting
AppLocker: Más que la versión 2 de SRP
Una implementación simple de AppLocker

Hay un long-standing decir en nuestra industria que nada es una panacea. Definido como “ remedio para todos los enfermedades, evils o dificultades ”, la panacea ofrecía situado pero neverrealized representará la solución de TI para finalizar todas las soluciones.

Se trata de sabiduría convencional que ningún producto único puede nunca totalmente ofrecerle esa corrección de parada de uno para todos los problemas, independientemente de cómo duro vendedores de dicho producto podrían intentar convencer de lo contrario. Aún en Explorar la nueva funcionalidad de AppLocker en Windows 7 y Windows Server 2008 R2, se debe preguntarse si Microsoft ha perdido la cierre.

Para comprender la eficacia de AppLocker, piense en los conceptos básicos de mantener la seguridad del sistema. Malware es una amenaza constante. Si se infecta los sistemas mediante un explorador de Internet o se inserta a través de un ataque de gusano estilo, inunda a veces incluso el mejores los servidores de seguridad y los motores de antimalware. Además, incluso con un enfoque por capas a la seguridad en su entorno, la combinación de estas herramientas no puede nunca estar preparada para que ataque temido de día cero.

Todavía es un subproceso comunes entre prácticamente todos los fragmentos de software malintencionado: Su código debe procesarse para que pueda dañar los sistemas.

Este único punto provoca la pregunta para los administradores: ¿Si prácticamente todo software malintencionado requiere procesamiento para ser peligroso, podría "proteger" yo mismo evitando que se produzca en primer lugar el procesamiento?

Siempre respondo: Absolutamente. Y la solución para ese problema AppLocker.

Aplicaciones whitelisting

AppLocker tiene sus raíces en la tecnología de directiva de grupo denominada directivas de restricción de software (SRP), que se presentó con Windows XP y Windows Server 2003. SRP introdujo el concepto de blacklists y whitelists en relación con no permitido y permite ejecutables en un dominio de Windows. El concepto es sencillo:

• Con una lista negra, usted, el administrador, identifica los archivos ejecutables específicos que no están permitidos de ejecutarse en equipos de su dominio. En el momento del lanzamiento, los procesos se comprueban con la lista negra antes de que se está ejecutando. Si es un proceso en la lista negra, se impide la ejecución y un mensaje de error en su lugar se presentará al usuario.
• Con una lista blanca, lo contrario se convierte en true. En su lugar mediante una lista blanca, especifique los procesos que se pueden ejecutar en sus equipos. Iniciados procesos se comprueban con la lista blanca antes de la ejecución. Sólo los de la lista blanca se pueden ejecutar;los no en la lista blanca se impide que se está ejecutando.

Con SRP, cualquiera de estos dos paradigmas era posible, con el predeterminado centrándose en la lista negra a las aplicaciones. A lo largo del tiempo, sin embargo, resultó evidente que el concepto de whitelisting podría ser considerablemente más eficaces. Mientras whitelisting complejo más trabajo porque cada aplicación aprobado para ejecutar tenía que introducirse en la directiva, era un método importantes para evitar todo lo demás.

En efecto, aprovechando el paradigma de whitelisting del SRP, un entorno podría especificar qué aplicaciones tenían ha probado, comprobadas y aprobado por sus administradores y la directiva de seguridad. Todo lo demás, incluidos la mayoría de los formularios de ejecución de malware y otras aplicaciones quasi-legitimate no aprobadas por TI: explícitamente denegado ejecución. No procesar, no software malintencionado, ninguna infección.

Pero al simple en concepto, tecnología del SRP dolorosa en implementación. A pesar de su eficacia, SRP se implementó sólo por un entornos muy pocos. Determinar el conjunto exacto de las aplicaciones aceptables era un proceso difícil y complejo con poco soporte de automatización. Cometer incluso un pequeño error en una directiva de grupo de SRP podría significar la prevención de ejecución de software todo en el dominio. Demasiado arriesgado y administrativamente demasiado complejo en su configuración, SRP rara vez la realizado en la mayoría de los entornosradars.

AppLocker: Más de SRP versión 2

Tecnología de AppLocker pretende aumentar niveles de adopción incorporando mejor funcionalidad de administración. Integra más estrechamente en los sistemas operativos Windows 7 y Windows Server 2008 R2, AppLocker aprovecha conceptos del SRP para crear una solución más utilizable.

La primera forma en que se mejora la AppLocker a través de SRP es mediante la adición de un modo de cumplimiento de auditoría sólo (vea de figura 1). En este modo, los equipos configurados y ejecutable las reglas sólo informe donde realizará las infracciones de directivas. Combinando el modo sólo de cumplimiento del AppLocker auditoría con una lista blanca vacía, es posible identificar rápidamente los tipos de aplicaciones que se ejecutan en equipos a través del dominio. Con información de auditoría se deposita en el registro de sucesos de cada equipo AppLocker, detalles de esas aplicaciones y sus archivos ejecutables se pueden documentar para cumplimiento posterior.

Figura 1 AppLocker en modo de auditoría sólo. (Haga clic en la imagen para aumentarla)

Un segundo mecanismo mejora la creación de reglas mediante un asistente automatizado. Se encuentra en directiva de grupo del AppLocker consola es una selección para generar reglas automáticamente (consulte de figura 2). Esta opción inicia a un asistente que buscará cualquier estructura de archivos en un equipo de referencia, buscando archivos ejecutables. Cualquier archivo ejecutable que se encuentra en la ruta de acceso asignado o sus subcarpetas en puede tener una regla que genera automáticamente para ella. Que señala a este asistente hacia un equipo de referencia con software común del entorno instalado automáticamente genera una lista de reglas. Esa lista puede utilizarse como punto de partida para la posterior personalización.

Figura 2 de asistente AppLocker automáticamente generar ejecutable para reglas (haga clic en la imagen para ampliarla)

AppLocker también simplifica la regla de generación reduciendo el número de clases de regla a tres. Está diseñados para utilizarse en combinación y verá que cada clase de regla ofrece un enfoque diferente para limitar la ejecución de software:

• Reglas de ruta de acceso crear una restricción basándose en el nombre o la ubicación del archivo del archivo ejecutable. Por ejemplo, se puede crear una regla de ruta para un determinado nombre de archivo (sol.exe) o una combinación de nombre de archivo y caracteres comodín (sol*.exe) para capturar las modificaciones limitadas a un nombre de archivo. También se puede utilizar caracteres comodín en combinación con las rutas de archivo (%ProgramFiles%\Microsoft Games\ *).
• Se crean reglas de hash de archivo para superar algunas limitaciones obvias con reglas de ruta. Mediante una regla de ruta, un archivo ejecutable puede tener acceso a moviendo fuera de una ruta administrada o modificando suficientemente su nombre de archivo. Utilizar una regla de hash de archivo, se crea un hash criptográfico de un archivo administrado. Basar las reglas de archivo hash significa que permanecen administrados independientemente de donde está ubicados en el sistema. Mientras Esto aumenta la seguridad de la solución global, su inconveniente queda patente como cambian los archivos de tiempo debido a las revisiones o actualizaciones. Por ese motivo, el uso de las reglas de hash de archivo requiere adicional debido diligencia como software se actualiza.
• Reglas de Publisher requieren que el ejecutable administrado está firmado digitalmente. Esa firma digital permite el archivo restringirse basado en su editor, nombre de producto, versión nombre de archivo y archivo. Una escala deslizante y valor personalizado opción proporciona la capacidad de ajustar qué características que le interesan y que son opcionales. Por ejemplo, es posible restringir un archivo basándose en su editor, product name y filename al establecer un comodín para la versión del archivo (consulte la figura 3). El resultado final: Las actualizaciones de versión posterior de ese archivo se aprueban automáticamente.

Figura 3 crear y personalizar una regla de publisher. (Haga clic en la imagen para aumentarla)

Una adición útil final es la capacidad para crear excepciones especiales asociadas con cualquier clase de regla. Estas excepciones habilitar una definición más de los cuales se permiten ejecutables para ejecución, como opposed que no pueden. Por ejemplo, puede permitir la ejecución de cualquier archivo ejecutable en la carpeta %programfiles%\Microsoft Office\ * pero evitar específicamente WINPROJ.EXE debido a restricciones o otros motivos de licencias.

Porque AppLocker configuración normalmente se crean a través de la directiva de grupo, la asignación de reglas de prevención de ejecución puede se centra en los equipos de su entorno o los usuarios individuales. Dentro de grupo Directiva de administración Editor (GPME), la configuración de AppLocker que se definen para los equipos está en la ubicación de configuración del equipo | directivas | configuración de Windows | Configuración de seguridad | directivas de control de aplicación. Los definidos para los usuarios se encuentran en la misma ubicación bajo Configuración de usuario. Como tal, cualquier combinación de usuario y configuraciones centradas en el equipo puede realizarse basándose en la aplicación de directiva de grupo. Combinación de directiva es aditiva, significado que no reemplazan la directiva de grupo o reglas de reemplazo ya está presentes en un objeto de directiva de grupo (GPO) vinculado. Asignado a través de directivas de grupo de reglas se aplicarán utilizando el mismo orden de aplicación como GPO tradicionales.

Ahora, limitación principal del AppLocker está relacionada con las versiones de sistema operativo que aplicará sus reglas. En el lado cliente, sólo 7 para Windows Ultimate y Windows 7 Enterprise pueden participar en AppLocker regla cumplimiento. Para los servidores, cualquier edición de Windows Server 2008 R2 excepto para Windows Web Server y Windows Server Foundation forzará reglas AppLocker. Aunque Microsoft puede back puerto esta funcionalidad en versiones anteriores de sistemas operativos, esta característica actualmente se agrega a la lista de atractivas razones para una actualización de Windows 7. (Al escribir este documento, no hay información ha publicado sobre un puerto de servicios posible para versiones anteriores de sistemas operativos.)

Una parte de compatibilidad buenas noticias: Base de directiva de grupo del AppLocker no requiere actualización de controladores de dominio (DC) para admitir la distribución de sus directivas. Pueden existente de Windows Server 2003 y Windows Server 2008 DC host AppLocker directivas.

Una implementación simple de AppLocker

Si AppLocker agregado sonidos de seguridad útiles al entorno pequeño, los pasos siguientes implican implementar la solución. Obviamente, implementación no ocurre hasta que se ha actualizado un porcentaje cuyo tamaño se puede modificar de sus equipos portátiles y a Windows 7. Sistemas operativos anteriores a Windows 7 y Windows Server 2008 R2 no aplicar reglas de AppLocker, pero respetará las aplica a través de SRP. Mientras las reglas SRP y AppLocker no estén directamente convertibles, se puede convertir manualmente la información recopilada a través de modo de auditoría sólo del AppLocker para su uso en el SRP.

La implementación de AppLocker implica varios pasos, empezando por determinar cómo implementar la tecnología y crear un equipo de referencia para aislar el conjunto inicial de las aplicaciones. Recuerde que, a diferencia de SRP, aplicación ­ almacén toma la suposición de que se va a crear una lista blanca de aplicaciones. Aunque es posible crear una arquitectura de listas negras, hacerlo no se recomienda simplemente porque ese enfoque no proporciona la capacidad de prevención de ejecución mismo ofrecida por whitelists.

En su documento titulado "diseño e implementar Windows AppLocker directivas"Microsoft describe un proceso paso nueve para implementar aplicaciones ­ almacén en un entorno. Mientras este documento está en versión beta en escribir este artículo, la versión actualmente disponible incluye detalles importantes acerca de cómo crear correctamente una completa infraestructura de AppLocker. Para la simplicidad, sin embargo, son aquí los pasos de unos que necesita para empezar.

Primero, cree una lista de aplicaciones que considera aceptable para la ejecución de la organización de TI. Puede crear esta lista manualmente entrevistando propietarios de la aplicación en su organización. O puede empezar creando y interrogar un equipo de referencia que contiene las aplicaciones normalmente disponibles en su negocio. Iniciar dicho proceso creando la instancia de sistema operativo, o imágenes con la imagen favorita-solución de implementación y garantizar que las aplicaciones derecha están instaladas. En este equipo, también debe instalar el Toolkit de administración de Systems remoto (RSAT) para Windows 7, que puede encontrarse en el sitio Web de Microsoft. Las RSAT incluye GPME componentes necesarios para crear reglas de AppLocker.

Cuando esté listo para su análisis, cree un nuevo GPO y iniciar dentro de la GPME. Desplácese a configuración del equipo | directivas | configuración de Windows | Configuración de seguridad | directivas de control de aplicación | AppLocker y haga clic en el vínculo en el panel derecho para configurar la aplicación de reglas. En la ventana resultante, active la casilla configurada en ejecutable reglas de marcado y establecer la regla sólo de auditoría. Esta opción mantiene los comportamientos existentes en sistemas administrados al informar AppLocker infracciones en el registro de eventos local.

Observará que esta ventana tiene una ficha Avanzadas, en el que puede optar por habilitar la colección de reglas DLL. AppLocker tiene la capacidad de crear reglas basadas en archivos DLL además a archivos ejecutables. Mientras se puede implementar esta configuración para mayor seguridad, el hacerlo agregará una carga administrativa adicional, ya que deberá aislar y configurar reglas para todas las DLL en su entorno además a archivos ejecutables. Puesto que un archivo ejecutable puede aprovechar varias DLL, dicha tarea puede ser un dolor de cabeza de administración. Habilitando regla DLL colección también afectará al sistema rendimiento porque el procesamiento de cada archivo DLL se requiere validación antes de ejecución.

El siguiente paso es configurar el conjunto predeterminado de reglas de archivo ejecutable. Haga clic con el botón secundario en el sub-node AppLocker del mismo nombre y elija crear reglas de predeterminado. Se crean tres reglas de forma predeterminada. Dos permitir la ejecución de todos los archivos de las carpetas Windows y archivos de programa, mientras que el tercero (que aparece en de figura 4) permite a los miembros del grupo Administradores local para ejecutar todas las aplicaciones. Esta tercera regla excluye eficazmente administradores locales de procesamiento de reglas.

Regla de la figura 4 predeterminado excluir administradores locales de prevención de ejecución. (Haga clic en la imagen para aumentarla)

Cuando eso completa, haga clic de nuevo con el botón secundario en el nodo reglas de archivo ejecutable y elija Generar reglas automáticamente. Este asistente interrogará la máquina local para la creación de reglas, motivo por el cual debe ejecutarse en el equipo de referencia de archivos ejecutables posibles. De forma predeterminada, el asistente buscará archivos ejecutables en la ruta c:\Archivos de programa, aunque rutas alternativas pueden comprobarse mediante la edición en las opciones del asistente.

Haciendo clic en siguiente en el Asistente para, le lleva a la pantalla Opciones de regla. Aquí, tiene la opción para crear reglas de Publisher para los archivos que están firmados digitalmente o para crear reglas de hash para todos los archivos. Reglas de ruta de acceso pueden crearse automáticamente en esta pantalla, pero sólo cuando no archivos ya ha firmado digitalmente por sus editores. Haciendo clic en siguiente nuevo finaliza el análisis del sistema y le lleva a una pantalla donde puede revisar la lista de reglas. Pueden eliminarse las reglas que no desea crear haciendo clic en el vínculo para revisar los archivos que se han analizado, desactiva la casilla de verificación junto a los archivos apropiados. Una vez que completa, haga clic en crear.

Completar esta tarea en un sistema de Windows 7 recién generado agrega cuatro nuevas reglas. Aunque bastantes más archivos ejecutables se encuentran en esta ubicación, el asistente le predeterminada grupo juntos las reglas para simplificar su aplicación. En este momento, si piensa como supervisión de otros tipos de archivo ejecutables, es posible configurar reglas para las secuencias de comandos y ejecutables basados en Windows Installer en esta misma ubicación GPME.

En este momento, el GPO comenzará configurar clientes de destino según la pertenencia a OU. Porque la directiva de cumplimiento de la regla está establecida en sólo de auditoría, realmente no se producirá ninguna restricción de ejecución. Durante este período, es una buena idea para examinar los registros de sucesos en diversos sistemas administrados para ver si están trabajando las reglas para su entorno o si su aplicación podría impedir que un archivo ejecutable necesario ejecución. Utilizar esa información para ajustar el conjunto de reglas existente para que funcione correctamente para su entorno.

Cuando esté listo para mover de informar sobre archivos ejecutables para evitar realmente les, simplemente Desplácese atrás hasta el nodo AppLocker en el GPME y cambie las propiedades de obligatoriedad de auditoría sólo a exigir reglas.

Obviamente, necesitará proyecto más planeamiento y pruebas prior to implementación. Pero estos sencillos pasos obtendrá comenzar. Mientras AppLocker no sea la panacea de seguridad completo, su capacidad para evitar que todos, pero los archivos ejecutables absolutamente aprobados desde la ejecución significa que procede realmente, realmente cerrar.

Greg Shields, MVP, es un socio en concentró Technology. Obtener más 'ShieldsGeek de todo cambia sugerencias y trucos en de ConcentratedTech.com.