
¿Cómo configurar la seguridad de Windows 10 y Windows 11 en 2023?
¿Cómo configurar la seguridad de Windows 10 y Windows 11 en 2023?
En el artículo anterior, aprendió sobre los riesgos y el impacto de los dispositivos de propiedad personal en la seguridad de la información y los pasos prácticos que puede tomar para garantizar que se aplique la protección adecuada. En este artículo, analizaremos las nuevas opciones de seguridad disponibles con Windows 10 y cómo se pueden combinar con la seguridad existente para mejorar la protección. Exploraremos sus beneficios y sus requisitos de hardware y software y le señalaremos las advertencias al implementar algunas de ellas.
Cubriremos los siguientes temas en este artículo:
- Windows Hello y Windows Hello para negocios
- Seguridad basada en virtual
- Guardia credencial
- Guardia de dispositivo
- Guardia de aplicaciones de defensor de Windows (WDAG) para Microsoft Edge
- Guardia de explotación del defensor de Windows
- Certificado de salud del dispositivo
- Nuevas opciones de bitlocker
- Solución de contraseña de administrador local
Desafíos de seguridad de hoy
Bienvenido a los virus informáticos, el caballo de los troyanos, los rootkits, las puertas traseras, los gusanos, el ransomware, el sharware, el software de seguridad deshonesto, la estafa, el crapware, el malware, el adware, el spyware, el riesgo, el gris, software no deseado y muchas, muchas otras amenazas.
Y se están volviendo cada vez más sofisticados. ¿Asustado? El panorama de seguridad cibernética ha cambiado mucho en los últimos años. ¿Te has adaptado también? Puedes hablar de una revolución de las amenazas cibernéticas.
El delito cibernético se ha mudado a ciberdisigio, ciber-guerra y cibercrector. Cuando los ex atacantes se centraron en las compañías Fortune 500, se ve que los atacantes ahora van tras cualquier objetivo, todas las verticales, todas las cadenas de suministro, subcontratistas, pequeñas empresas e individuos a nivel de línea. El malware y las vulnerabilidades han pasado al robo de credenciales a gran escala y amenazas persistentes avanzadas. Necesita combatir esta revolución, y es una tarea muy desafiante.
La siguiente figura muestra la evolución de los ataques:
En el pasado, los ataques con frecuencia fueron dirigidos por lo que llamamos Script Kiddies, que en su mayoría eran personas no calificadas que usaban guiones y programas desarrollados por otros. Sus ataques fueron poco sofisticados y principalmente motivados por travesuras o fama. El mayor impacto fue hecho por Blaster y Slammer en este tiempo.
Desde 2005, el crimen organizado llegó cada vez más al juego. Sus ataques fueron más sofisticados y diferenciados. Las nuevas amenazas como el ransomware, el fraude de clics y el robo de identidad se volvieron comunes. Están motivados por monetizar el delito cibernético. Desde 2010, hemos visto una próxima tendencia de CryptoLockers. La escena del crimen organizado incluso proporciona líneas directas las 24 horas, los 7 días de la semana si se convierte en víctima de tales criptolockeros y tiene problemas para ingresar a la clave de desbloqueo pagado.
Desde 2012, hablamos de ahora en términos de amenazas cibernéticas. Sabemos que los estados nacionales, los grupos terroristas y los activistas también son una amenaza. Utilizan ataques muy sofisticados y bien generados. Tienen diferentes motivos, como robo de IP, daño, interrupción y venganza. En el pasado, tardó varios días hasta semanas en planificar hasta explotar. Hoy, solo lleva horas o días, y hablamos de hazañas de día cero.
Necesitamos un nuevo enfoque para abordar las amenazas. El modelo económico de los ataques debe ser arruinado. No más escala y grandes estilos de ataque. Necesitamos romper los libros de jugadas de ataque. Cada ataque debe ser único y consumir mucho tiempo nuevamente. Y necesitamos eliminar todos los vectores reales de ataque. En este sentido, se han nombrado cuatro pilares principales para la protección de amenazas:
- Protección del dispositivo
- Resistencia a la amenaza
- Protección de identidad
- Protección contra la información
Al observar los plazos de ataque típicos, el tiempo promedio entre el compromiso del primer host y el compromiso de administrador del dominio es de solo 24-48 horas. Pero tarda entre 11 y 14 meses en detectar el ataque. Por lo tanto, necesitamos redefinir la pila de defensa en entornos previos y posteriores a la violación y asumir una violación en algún momento. Por lo tanto, hay un quinto pilar llamado detección de incumplimiento, investigación y respuesta.
La protección del dispositivo tiene como objetivo mejorar la protección de su hardware. Los piratas informáticos podrían soltar fácilmente malware como un RootKit en su dispositivo y comprometer su dispositivo antes de que se inicie el sistema operativo. Puede comparar tal RootKit con un hipervisor, y si está bien escrito, el sistema operativo no podrá detectarlo en absoluto. Cosas bien conocidas como el módulo de plataforma de confianza (TPM), la interfaz de firmware extensible unificada (UEFI), el arranque seguro y la funcionalidad de antimalware de lanzamiento temprano (ELAM) pueden ayudar a proteger su integridad de dispositivos y proteger su sistema operativo antes de que comience. Se ha agregado una nueva seguridad a Windows 10 con contenedores de seguridad basados en virtualización y nuevos sensores biométricos para la autenticación de dos factores.
La resistencia a las amenazas tiene como objetivo endurecer su sistema operativo contra virus, troyanos y otro malware. Cosas bien conocidas, como el filtro de reputación SmartScreen, el firewall de cliente y el anti-malware del defensor de Windows, difícilmente pueden mantenerse al día con alrededor de 390,000 nuevos programas de malware que se crean cada día.
Se introdujo una nueva seguridad en Windows 10 con la protección de dispositivos, un complejer avanzado a prueba de manipulaciones, WDAG y contenedores de SO seguros para aplicaciones como Edge y Edge se han endurecido aún más al limitar su acceso a ciertas API de bibliotecas de enlace dinámico (DLL) y eliminar Tecnología anticuada y crítica de seguridad.
Identity Protection tiene como objetivo deshacerse de las contraseñas y proteger las credenciales secundarias con la nueva seguridad de Windows Hello y Credential Guard. Esto defiende contra los ataques de pases-the-Hash (PTH) con la ayuda de un contenedor SO seguro usando VBScript. Junto con Windows Hello y los servicios de credenciales de próxima generación, la superficie de ataque es aún más limitada y la información confidencial está protegida.
La protección de la información tiene como objetivo proteger la información, siempre que reside en el dispositivo para proteger contra la pérdida o robo y para proteger los datos al transferir entre dispositivos. Las soluciones bien conocidas como BitLocker y BitLocker To Go se combinan con la nueva seguridad de Windows 10 con el nuevo algoritmo de bitLocker XTS y la protección de la información de Windows A.K.A. ) con una definición de límite fácil y soporte B2B en un contenedor transparente para todos los datos confidenciales.
En el mundo moderno de las amenazas cibernéticas, debemos asumir el potencial de una violación. Por lo tanto, la detección, la investigación y la respuesta de la violación tienen como objetivo detectar estas violaciones más rápido y comenzar las contramedidas lo antes posible. Con seguridad mejorada de Windows 10 con más acceso condicional granular, certificación de salud de nuevos dispositivos (DHA) y Protección de amenazas avanzadas de Windows Defender (ATP) en el lado del cliente, esta protección posterior a la violación debe mejorarse. En el lado del servidor, la incorporación de Microsoft Advanced Amenic Analytics (ATA) nos ayudará a detectar un comportamiento sospechoso. ATP y ATA estarán cubiertos en otro capítulo.
Echemos un vistazo a las nuevas funciones de seguridad de Windows 10.
Windows Hola/Windows Hello para negocios
Según el informe de seguridad más nuevo de Microsoft, la recomendación de la longitud de la contraseña se ha elevado a un mínimo de 12 caracteres. Pero las contraseñas seguras pueden ser difíciles de recordar, y obligar a los usuarios a cambiar con frecuencia sus contraseñas a menudo conducirán a problemas amarillos de notas adhesivas. Además, los usuarios a menudo reutilizan las contraseñas. Las contraseñas a veces se comparten entre las personas. Las infracciones del servidor pueden exponer contraseñas, especialmente si se almacenan en texto sencillo o hash sin sal. Además, los usuarios pueden exponer involuntariamente sus contraseñas debido a los ataques de phishing.
Por lo tanto, las contraseñas ya no son suficientes porque con frecuencia son débiles, la misma contraseña se usa en demasiadas ubicaciones, y debido al aumento del poder de cálculo de la nube, pueden ser fácilmente agrietados por un ataque de fuerza bruta o tablas de arco iris si son demasiado cortas. Se pueden robar, violar o imponer fácilmente.
Además, los ataques PTH ahora son una amenaza muy real. PTH se descubrió en 1997 cuando el cliente de Bloque de mensajes del servidor (SMB) aceptó los hash de contraseña NTLM. Fue armado en 2008 por Hernan Ochoa de Amplia Security.
El hash cambia solo cuando se cambia la contraseña. Además, existe una relación entre la contraseña y el hash. Si la contraseña es demasiado corta, puede ser fácilmente forzada o calculada. Peor aún es el uso de la función inteligente solo para tarjeta porque el hash solo cambiará cuando alterne esta función o cuando cambie su tarjeta inteligente. Además, se puede usar una contraseña robada en varias computadoras, y en la mayoría de los casos, ni siquiera notará que alguien más está usando sus credenciales.
Necesitamos pasar a una experiencia más segura y sin contraseña. Y Windows Hello es capaz de proporcionar uno. Microsoft es miembro de la junta de Fast Identity Online (para obtener más información, visite https://www.fidonet.com/index.php) y utiliza hardware y software estandarizados descritos en Fido 2.0.
Al usar Windows Hello, sus credenciales (modo de consumo) o su clave privada asimétrica (modo comercial) se almacenan dentro de su TPM. Su pin o factor biométrico se usa para desbloquear su TPM.
Para poder usar sensores biométricos, primero debe definir un PIN. No se deje desconcertarse por la palabra pin. No es una contraseña solo numérica; También puede ser alfanumérico con caracteres especiales. La complejidad del PIN se puede administrar por Group Policy Object (GPO) o la gestión de dispositivos móviles (MDM). Y donde con una contraseña normal solo es capaz de establecer la complejidad, aquí puede definir cada uno de los minúsculas, mayúsculas, dígitos y caracteres especiales con no permitidos, permitidos y requeridos, lo que le brinda un control más granular sobre los pasadores.
El PIN se define por dispositivo y no deambula. Por lo tanto, incluso un PIN de seis caracteres de largo podría ser más seguro que una contraseña tradicional de 12 caracteres, ya que el PIN solo se puede usar en el dispositivo que lo posee, mientras que una contraseña, una vez comprometida, se puede usar en la mayoría de los casos en cada dispositivo en el dominio.
Windows Hello actualmente admite tres tipos de sensores biométricos: huella digital, cara e iris. Actualmente se evalúan más tipos de inicio de sesión, como anillos biométricos y exploración de vasos sanguíneos, y se agregarán con futuras versiones de Windows 10.
No te preocupes; El escaneo de su huella digital genera una plantilla, que no se puede transformar nuevamente en una huella digital. Estas plantillas solo se almacenan localmente. Entonces, incluso si un atacante compromete su sistema, él o ella no podrá obtener su escaneo de huellas digitales. ¡Windows 10 no es el coleccionista de huellas digitales más grande del mundo!
Los datos biométricos utilizados para admitir Windows Hello se almacenan solo en el dispositivo local. No deambula y nunca se envía a dispositivos o servidores externos. Se recomienda encarecidamente el uso de TPM. Si bien el uso de TPM es más seguro y robusto, Windows también contiene un mecanismo alternativo basado en software que se utilizará cuando no hay TPM disponible. GPO puede evitar el uso de Windows Hello en máquinas sin TPM (establecer use un dispositivo de seguridad de hardware para habilitarse).
Los dispositivos con capaces de huellas dactilares deben cumplir con los requisitos biométricos (requisitos biométricos: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-biométrico-ruquirements) para falsos y verdaderos tasa de aceptación, implementar técnicas anti-especificación y proporcionar un controlador de Marco Biométrico de Windows (WBF) para que se le permita como Windows Hello Hello Fingerprint Devices. Pero incluso si existen requisitos detallados, la calidad de la detección de anti-especificación y vida puede variar entre diferentes modelos. Debe observar los dispositivos de huellas digitales con detección de vida capacitiva, térmica o de ultrasonido si desea garantizar más seguridad. Pero estos sensores son más caros. Además, los modelos de sensores de área grande suelen ser más seguros que los modelos de deslizamiento. No existe la posibilidad de GPO para limitarse a ciertos modelos de huellas digitales, por lo que debe deshabilitar los modelos no deseados directamente dentro del firmware BIOS/UEFI de sus dispositivos.
Para los escaneos de cara e iris, todos los dispositivos también deben cumplir con las estrictas especificaciones del sensor de Microsoft (sensores infrarrojos, iluminadores IR, resolución, etc.). Pero, ¿por qué Windows Hello usa infrarrojos en lugar de imágenes en color normales? Debido a que IR puede manejar situaciones de poca luz y luz lateral de manera más robusta, generalmente es más inmune al maquillaje y el vello facial. Además, ayuda con la suplantación porque no permite fotos o pantallas LCD.
Si su dispositivo biométrico no cumple con los requisitos biométricos y, por lo tanto, no tiene un controlador certificado por WBF, no se ofrecerá como un sensor biométrico en el control del sistema Hello Windows. Pero aún podrá usar un pin con Windows Hello. Si hace cumplir el uso de biometría por GPO, solo se aplicará a los sensores certificados.
Si su dispositivo ya no reconoce más sus datos biométricos (como debido a una lesión en el dedo, con los dedos húmedos con modelos de sensores capacitivos o por usar gafas nuevas), aún podrá usar su pin como copia de seguridad. Si usa anteojos, debe registrarse varias veces con el sistema de reconocimiento facial con y sin gafas para obtener la mejor experiencia de usuario.
Diferencias entre Windows Hello y Windows Hello para negocios
Windows Hello está dirigido a individuos/dispositivos de consumo. La verificación PIN o biométrica se usa en su dispositivo personal para reducir el riesgo de keyloggers o phishing de contraseña, pero el proceso de inicio de sesión todavía usa su hash de contraseña. Como normalmente no se une a un dominio y su hash no puede dañar otros dispositivos, este es un riesgo reducido.
Windows Hello for Business se puede configurar mediante GPO o MDM y utiliza un PIN respaldado por autenticación asimétrica (clave pública/privada) o basada en certificados. Al eliminar el uso de hashes, la seguridad aumenta considerablemente. Para usar este modo de tecla asimétrica, debe usar Azure AD o implementar un controlador de dominio de Windows Server 2016. Con el uso de Windows Server 2016, puede habilitar el modo de credencial de próxima generación y eliminar la relación entre la contraseña y el hash. Con este modo, el hash puede ser más aleatorio y cambiar con más frecuencia.
Además del GPO de complejidad PIN ya mostrado, también puede hacer cumplir la inscripción en Windows Hello for Business, el uso de TPM Security Device, el uso de la autenticación de certificados locales, la inscripción a Biometrics y (si está conectado a Azure Ad Premium) Iniciar sesión como segundo factor.
Para proteger sus credenciales dentro de la memoria de su sistema, necesitaremos seguridad (VBS) y guardia de credenciales, que se describirá a continuación.
Seguridad basada en la virtualización
VBS, también conocido como el modo de usuario aislado (IUM) proporciona un nuevo límite de confianza para el software del sistema. VBS se incluye con la empresa (incluida la LTSB), la educación y las ediciones de IoT Enterprise de Windows 10. Aprovecha la virtualización de la plataforma para mejorar la seguridad de la plataforma al limitar el acceso a activos de seguridad de alto valor, incluso del código de modo supervisor (CPL). VBS proporciona un entorno de ejecución seguro y protege varios servicios de Windows 10, como el aislamiento de credenciales de LSA y la integridad del código de modo del kernel (KMCI). En el sistema operativo del servidor, también proporciona un TPM virtual (VTPM).
VBS utiliza el hipervisor para proteger un mini núcleo y otras piezas/servicios importantes del sistema operativo al hacer cumplir, escribir y ejecutar permisos en la memoria del sistema.
Al separar estos servicios, mejora la protección del sistema operativo contra los ataques del núcleo y otros ataques. Incluso si el malware gana acceso al núcleo, los efectos son limitados porque el hipervisor evita que el malware ejecute código.
Las nuevas características de seguridad (guardia de credencial, protector de dispositivos y protección de aplicaciones) usan este modo VBS. Por lo tanto, para usar cualquiera de estas tres características de seguridad, primero debe activar VBS. Aquí hay un esquema de alto nivel de Windows 10 con VBS activado:
Incluso si el malware obtiene acceso al núcleo de Windows, los servicios aislados críticos dentro del sistema operativo seguro de VBS se mantienen seguros. La superficie de ataque con VBS está aún más limitada por tener solo un conjunto mínimo de funcionalidad, sin soporte del controlador y muchas características de seguridad, como la integridad de código y la protección de flujo de control (CFG).
Para poder usar VBS, debe usar la arquitectura X64 (para soporte Hyper-V) y su hardware debe tener algunas características disponibles y activadas.
Los requisitos más actualizados para VBS siempre se pueden encontrar en https://docs.microsoft.com/en-us/windows-hardware/design/minimum/device-guard-and-credential-guard. Como puede ver, se agregan nuevos requisitos de hardware con cada iteración de Windows 10 para asegurar todas las posibilidades. Los siguientes son necesarios como mínimo para habilitar VBS:
- CPU de 64 bits
- OS de 64 bits
- UEFI 2.3.1c o firmware superior
- Sin modo Legacy/BIOS activado
- Arranque seguro activado
- Hyper-V Función Hypervisor activada
- Soporte de virtualización:
- Extensiones de virtualización (Intel VT-X o AMD-V)
- Traducción de direcciones de segundo nivel (SLAT) (Intel EPT o AMD RVI)
- Unidad de gestión de memoria de salida de entrada (IOMMU) (Intel VT-D o AMD VI)
- TPM 1.2 o (recomendado) 2.0
Como puede ver, la activación segura del arranque es obligatoria. El arranque seguro en sí necesita el modo UEFI. Todo el hardware con un logotipo de hardware moderno de Windows 8 o Windows debe admitir UEFI 2.3.1 y Secure Boot. Por lo tanto, debe buscar este logotipo o pedirle compatibilidad a su proveedor de hardware. Todos los sistemas que cumplen con estos requisitos deben instalarse en modo UEFI o convertirse con la herramienta MBR2GPT desde Legacy hasta el modo UEFI para aumentar sustancialmente la seguridad. Si se cumplen todos los requisitos, puede activar la función VBS.
En Windows 10 versión 1511, VBS debe activarse instalando Hyper-V Hypervisor y el modo de usuario aislado se presenta a pedido. Dado que Windows 10 versión 1607, la función de modo de usuario aislado ya no está presente, y VBS se activa automáticamente tan pronto como se instala la función Hyper-V Hypervisor y se cumplen los requisitos previos de hardware. Siempre que solo instale Hyper-V Hypervisor y no de Servicios de Hyper-V, el usuario no puede hacer daño a su entorno creando máquinas virtuales o conmutadores virtuales adicionales. La función puede ser instalada por GUI, PowerShell, Dism o un archivo Unattend.xml al implementar la imagen. Se necesita un reinicio después de agregar la función.
VBS contiene varios mecanismos de seguridad para protegerse contra cualquier ataque conocido. Estos mecanismos de seguridad, como la ausencia de soporte del controlador del dispositivo dentro de VBS e integridad de código forzado, se describirán con más detalle en las secciones de protección de credencial y protección del dispositivo.
Guardia credencial
Como ya se describió en la sección Hello Windows, la vulnerabilidad de PTH se ha convertido en una amenaza muy común. Las herramientas de piratas informáticos como Mimikatz pueden volcar la memoria del sistema y depurar su lsass.exe, que contiene todas las credenciales actualmente activas, incluidas las hashes. Cuando la PTH se armó, Windows 7 ya estaba convencional y el diseño de Windows 8.0 también se completó. No pudieron reaccionar/rediseñar su núcleo para evitar este volcado de memoria. Cada servicio pudo descargar su subsistema de autoridad de seguridad local (LSASS). Con Windows 8.1, se introdujo un nuevo nivel de proceso protegido (PPL). Cuando se activó RunAspPL, el proceso LSASS se ejecutaría con un nivel de protección más alto (nivel del sistema) y, por lo tanto, ya no sería accesible por servicios ilegales/corruptos. Pero Mimikatz evolucionó y encontró un punto débil con los controladores de dispositivos. Incluso cuando se ejecuta en la PPL, los controladores de dispositivos corruptos pueden acceder a LSASS. Se necesitaba un elemento de seguridad más disruptivo. Desde Windows 8.0, el sistema operativo cliente también es capaz de la función Hyperv. Hyper-V protege el contenido de la memoria de sus invitados. Nació la idea de un segundo sistema operativo virtual, la seguridad basada en la virtualización.
Para proteger mejor a VBS contra los vectores de ataque conocidos, como el uso de controladores de dispositivos corruptos, el sistema operativo VBS no admite los controladores de dispositivos. Los binarios dentro del VBS están protegidos por la integridad del código (binarios firmados) y CFG (una tabla de todos los estados posibles de un ejecutable). Entonces, incluso en el improbable caso de que el malware sea capaz de ingresar VBS, los binarios de malware/infectados se identifican por integridad del código y no se ejecutarán. E incluso si deben ser capaces de engañar la integridad del código, el protector de flujo de control y el ejecutable detectará el comportamiento de salto diferente de los ejecutables y el ejecutable.
Credential Guard usa VBS para aislar la autenticación de Windows del sistema operativo Windows. En el sistema protegido de VBS, el sistema operativo de alto nivel y el sistema operativo VBS se comunican con llamadas de procedimientos remotos (RPC). Al activar Credence Guard, verá además del conocido LSASS un nuevo proceso llamado Lsaiso. Este LSAISO no es el LSAISO que se ejecuta dentro de VBS, sino un LSAISO adicional que se ejecuta dentro del sistema operativo de alto nivel para ayudar a la comunicación de LSASS entre los dos entornos.
El LSASS de alto nivel-OS solo contiene un GUID de referencia para la credencial. Solo el VBS LSASS contiene el hash.
El malware podría tratar de obtener el GUID, pero los procesos LSASS/LSAISO solo se comunicarán con sus homólogos, por lo que el GUID podría ser conocido por el malware sin que haga ningún daño.
Desafortunadamente, Credential Guard se hace referencia dentro del GPO y dentro de MSINFO32 también como Guardia de dispositivos. Para activar la protección de credenciales en su sistema, su sistema debe ser capaz de ejecutar el sistema operativo VBS, y la función VBS debe estar activa/en ejecución.
Para verificar su hardware en busca de compatibilidad, puede usar la herramienta de preparación de hardware de protección de dispositivos y protección de credenciales (para obtener más información, visite https://www.microsoft.com/en-us/download/details.aspx?id=53337). El protector de credenciales puede ser controlado por GPO o MDM. Encontrará el GPO relacionado en la sección GPO de la máquina en el sistema | Guardia del dispositivo.
Seleccione la entrada de seguridad basada en Virtualization Builting y configuéla para habilitarse. Para el nivel de seguridad de la plataforma, seleccione Boot seguro como mínimo, o mejor, seleccione Protección Secure Boot y DMA.
A continuación, debe configurar la configuración de la guardia de credencial para habilitarse sin bloqueo o habilitado con el bloqueo UEFI. Se requiere un reinicio después de que se aplica la política para activar la guardia de credenciales:
Para verificar si VBS y Credential Guard están en funcionamiento, puede verificar su administrador de tareas. Si ve un proceso llamado lsaiso.exe, indica que el guardia de credencial está ejecutando:
Alternativamente, puede usar msinfo32.exe y mirar las entradas de resumen del sistema para la protección de dispositivos: la seguridad basada en la virtualización debería estar ejecutándose, y los servicios de seguridad basados en la virtualización que se ejecutan en la protección de credenciales:
Si la protección de credencial no puede activarse en su dispositivo, verifique la compatibilidad con la protección del dispositivo y la herramienta de preparación de hardware de la protección de credenciales o el visor de eventos para una identificación de evento de error.
Además de la configuración de la protección de credenciales, existe la protección basada en la virtualización de la integridad del código, también conocida como la protección del dispositivo, que se cubrirá a continuación.
Guardia de dispositivo
Puede ejecutar su sistema de dos maneras. Uno confía en todo hasta que hay evidencia de que es malicioso. La evidencia debe ser proporcionada por, por ejemplo, su solución antivirus. Este es un método del pasado que difícilmente podría mantenerse al día con los más de 390,000 malware diario recién generado. El otro es que confía solo en el software/ejecutables/scripts conocidos.
Pero, ¿alguna vez ha intentado la lista blanca todos los ejecutables de su imagen con políticas de restricción de software o aplicador? Primero, debe inventar la inventario de todos los ejecutables y luego crear una política basada en un certificado digital, hash o ruta. Hay una gran cantidad de ejecutables. Y no todos están firmados digitalmente. Por lo tanto, debe recurrir a los nombres de archivo y los hashes. Pero, ¿qué pasa si usa una aplicación que crea ejecutables con nombre al azar sin firmar en su carpeta temporal durante el tiempo de ejecución? Debe hacer un gran agujero de seguridad en las reglas de su Applocker permitiendo una ruta genérica para la ejecución.
Además de los ejecutables, debe la lista blanca de todos los DLL. No solo hay tantos archivos DLL que hacen que el inventario y la creación de reglas sean más complejos, sino que también notará una posible degradación del rendimiento de su sistema al verificar todos sus DLL con Applocker.
¿Y qué hay de los guiones? La mayoría de sus scripts no están firmados, y es común crear y ejecutar scripts durante el tiempo de ejecución de ejecutables. Nuevamente, debe hacer grandes agujeros en la seguridad de su Applocker permitiendo rutas o nombres genéricos sin firmas.
Además, un administrador o malware puede manipular a Applocker para que no se reinicie después del reinicio. Se necesita una solución más restrictiva, a prueba de manipulaciones, pero fácil de administrar. Bienvenido a Code Integrity, también conocido como Guard de dispositivos.
La integridad del código ya se introdujo con Windows Vista. En la versión de escritorio de Windows 8.0, se llamaba KMCI. Hizo cumplir las firmas digitales, la integridad de los binarios del kernel de Windows, los controladores de primera parte de Windows y las firmas de controladores X64. En las versiones Mobile y Windows RT, la integridad del código se extendió adicionalmente a la integridad del código de modo de usuario (UMCI) y la firma digital e integridad de todos los ejecutables. Esta fue una razón por la cual Mobile y RT solo pudieron ejecutar aplicaciones firmadas correctamente desde la tienda Windows. Por lo tanto, ya tenemos conocimiento práctico de implementar dicho CI.
Pero, ¿por qué no fue suficiente? La versión utilizada en Windows 8.x tenía un inconveniente importante: se estaba ejecutando dentro del mismo espacio del núcleo del sistema operativo de alto nivel y podía ser manipulado por malware. Y el UMCI requirió una posibilidad amigable para la empresa para firmar las aplicaciones LOB y Win32.
En Windows 10, los componentes KMCI y UMCI se movieron dentro del contenedor VBS seguro. Además, la integridad del código ahora es configurable, por lo que en el modo KMCI también, los controladores de terceros pueden permitirse/integrarse en la política KMCI. Y en UMCI, todos los ejecutables, tanto las aplicaciones clásicas de Win32 como las aplicaciones modernas de interfaz de usuario (APPX), pueden integrarse en una política de integridad de código o en un archivo de catálogo confiable y firmado. La política de integridad del código se quema en hardware, es decir, se almacena en TPM a prueba de manipulaciones. Entonces, incluso si arranca desde un DVD de entorno de preinstalación de Windows (WIN PE) o reinstala su sistema operativo, la política permanece intacta y protege su sistema operativo.
Integridad del código de protección de dispositivos utiliza firmas digitales si es posible. Si no hay firma digital, puede retrasar los hashes. Cuantos más hash de archivo tenga, más probabilidades de romper su política de integridad del sistema/código con la próxima actualización de la aplicación. Por lo tanto, debe tratar de mantener el uso de hashes al mínimo para evitar problemas innecesarios después del parche.
El protector de dispositivos se utiliza para que se presente todos sus ejecutables, DLL y scripts. En la parte superior del protector de dispositivos, puede usar Applocker para una lista negra adicional.
Durante el arranque de Windows y la carga del núcleo, no todos los componentes de la protección de dispositivos están disponibles, por lo que el uso de archivos de catálogo firmados solo es posible para UMCI. Para crear tal plan de su imagen, es decir, la política de integridad de código, debe realizar los siguientes pasos:
1. Prepare su sistema dorado, que se utilizará para la recolección de la política de aplicación.
2. Habilite VBS y Guardia del dispositivo en el sistema. Establezca la protección del dispositivo en modo de auditoría.
3. Recopile toda la información del archivo con PowerShell Cmdlets para crear una política.
4. Repita los pasos 1-3 para todos los diferentes modelos de hardware/configuraciones de imagen base. Fusionar múltiples políticas o implementar políticas diferenciadas. Tenga en cuenta que solo puede haber una política de protección de dispositivos activo al mismo tiempo en el mismo sistema.
5. Convierta la política en formato binario y firme.
6. Implemente su política en modo de auditoría en el sistema de destino y la prueba.
7. Use Windows PowerShell Cmdlets para crear una política desde el registro de auditoría y fusionar.
8. Habilite la aplicación de la política y la prueba.
Para habilitar la protección del dispositivo en un sistema, VBS debe activarse primero. Después de eso, puede habilitar la protección del dispositivo con el siguiente GPO:
Después de la creación exitosa de dicha política de integridad de código, se puede aplicar a través de GPO o MDM. Una política de integridad de código una vez aplicada a un sistema solo puede reemplazarse por otra política de integridad de código con el mismo certificado de firma. Tenga cuidado con el uso de certs muy cortos, ya que la política debe reemplazarse antes de que el certificado esté desactualizado. La política de integridad de código debe estar en una ruta UNC o en una ruta localmente válida. Se prefiere UNC, ya que una ruta local necesita un trabajo de copia adicional:
Para crear, firmar y probar, los siguientes cmdlets PowerShell de protección del dispositivo están disponibles en Windows 10:
Como alternativa, puede crear un archivo de catálogo para aplicaciones. Esto solo se puede utilizar para aplicaciones/componentes UMCI, como durante el arranque del sistema, cuando los controladores y los componentes del sistema están marcados, las partes del programa adecuadas de la protección del dispositivo aún no están listas para escanear archivos de catálogo, por lo que solo funcionan las políticas de protección de dispositivos Estos componentes KMCI. Para crear un archivo de catálogo firmado de una aplicación, debe realizar los siguientes pasos:
1. Prepare su sistema de catálogo, que se utilizará para la recopilación de todos los archivos nuevos, información agregada del archivo de catálogo.
2. Habilite VBS y Guardia del dispositivo en el sistema. Establezca la protección del dispositivo en modo de auditoría.
3. Ejecute PackageInspector.exe Inicio C: para un escaneo inicial del sistema.
4. Instale las aplicaciones.
5. Detener la recopilación de información con paquetes de paquetes.
6. Firme el archivo de catálogo con SignTool.exe.
7. Copie el archivo de catálogo firmado al sistema de destino en C: \ Windows \ System32 \ Catroot \ {F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
8. Después de una prueba exitosa, implementa el archivo de catálogo en todos sus sistemas en esta carpeta.
No hay un límite oficial de los archivos de catálogo documentados, pero debe intentar mantenerlo bajo/limpieza de archivos de catálogo innecesarios.
La tercera opción es agregar automáticamente las aplicaciones instaladas por su instalador administrado a la integridad del código de protección del dispositivo. Esta opción se agregó con Windows 10 1703. Un instalador administrado utiliza una regla para confiar en uno o más ejecutables como fuente autorizada para la implementación de aplicaciones. Al especificar un ejecutable como un instalador administrado, todos los archivos escritos desde el proceso de ese ejecutable serán etiquetados por Windows como originados de una autoridad de instalación confiable. Al momento de escribir este libro, no hay un diálogo GUI para definir un instalador administrado, y tiene varias limitaciones conocidas. Todos los pasos necesarios, incluida la modificación manual de los archivos XML, se documentan en https://docs.microsoft.com/en-us/windows/device-security/device-guard/deploy-managed-installer-device-guard .
En una versión futura de Windows 10, se agregará un cuarto método para agregar aplicaciones con scripts al estándar de oro. Esté atento a las compilaciones previas de Windows Insider para obtener información de primera mano tan pronto como esté disponible.
Además de la aplicación de la integridad del código, también hay otras ejecuciones introducidas por el protector de dispositivos. En la memoria del núcleo y el lado del controlador, se realizan las siguientes ejecuciones:
- Las reglas de integridad del código todavía se aplican incluso si una vulnerabilidad permite el acceso al modo de kernel no autorizado, ya que se ejecuta en un espacio seguro VBS
- Las páginas de memoria solo son marcadas ejecutables si son validadas correctamente por Code Integrity
- Guard de dispositivos La memoria del núcleo activada por la protección de KMCI-protección no puede marcarse tanto en escritura como ejecutable para reducir el riesgo de código malicioso automodificante que es difícil de detectar
- Desafortunadamente, no todos los controladores serán actualmente compatibles y ya no pueden escribir y ejecutar la memoria del núcleo, por lo que se necesitan controladores compatibles con la protección del dispositivo actualizado
Para probar todos sus controladores existentes antes de imponer la protección del dispositivo en estos sistemas, puede usar la herramienta de preparación de hardware de protección y protección de credenciales. La herramienta se puede encontrar en https://www.microsoft.com/en-us/download/details.aspx?id=53337.
Además, hay cumplimientos en el manejo de script con la protección del dispositivo activado:
- El host de script de Windows requerirá scripts firmados: todos los archivos VBScript (.vbs y .vbe), JScript (.js), el archivo de script de Windows (.wsf) y los componentes de script de Windows (.WSC) deben firmarse o no se ejecutarán .
- Todas las MSI deben firmarse o no se ejecutarán.
- Los scripts de PowerShell unsigned estarán en modo de lenguaje restringido, que bloqueará varios comandos/cmdlets peligrosos. Para usar todo el potencial de PowerShell, el script debe firmarse para ejecutarse en modo de idioma completo.
- Otros scripts como .bat y .cmd actualmente no están restringidos.
Además de estas limitaciones y ejecuciones, ¿dónde se aplica la protección del dispositivo? Necesitamos distinguir cuatro casos de uso diferentes, desde bien administrado hasta traer su propio dispositivo (BYOD).
Carga de trabajo fija:
- Configuración de software y hardware muy bien definida
- Bien administrado
- Baja tasa de rotación
- Idealmente, no hay usuarios de usuario o estándar solo
En el escenario de carga fija (como PC en modo kiosco y PC de línea de producción), puede activar todas las partes necesarias de la cadena de seguridad con arranque seguro, VBS y protección de dispositivos, y puede ejecutar KMCI protegido por VBS y UMCI en modo Funcionado.
Totalmente administrado:
- Configuración de hardware bien definida
- Software administrado solamente
- Bien administrado
- Idealmente, solo usuarios estándar
En un escenario totalmente administrado (debería ser la PC en el lugar de trabajo de Office típica sin un usuario administrativo), puede activar nuevamente todas las partes requeridas de la cadena de seguridad con Boot, VBS y Guardia de dispositivos seguros, y puede ejecutar KMCI protegido por VBS y UMCI en modo forzado. Si un usuario tiene derechos de administración, no puede instalar su propio software, ya que será bloqueado por el protector de dispositivos.
Ligeramente administrado:
- Configuraciones de hardware múltiples y variadas
- El usuario puede instalar software no administrado
- Usuarios estándar o administrativos
En el escenario ligeramente administrado (que todavía se encuentra con demasiada frecuencia), solo puede activar algunas partes de la cadena de seguridad. El arranque seguro y los VBS deben estar disponibles sin problemas. Pero KMCI con protección VBS debe ser revisada. UMCI solo se puede activar en modo de auditoría, y los registros deben inspeccionarse regularmente. Debido a los altos éxitos falsos positivos para el software no administrado, los registros son difíciles de leer/interpretar.
BYOD:
- Dispositivos de propiedad personal
- Hardware y software altamente variables
En el escenario BYOD, no se pueden activar partes de la cadena de seguridad, como el arranque seguro, VBS o la protección de dispositivos, incluso en modo de auditoría.
Con la implementación actual de la protección de dispositivos, puede ejecutarla solo en carga de trabajo fija y escenarios totalmente administrados. Incluso entonces, no es capaz de activarlo en todos los clientes, y debe activarlo en tantos escenarios como sea posible para elevar la barra de seguridad y mejorar su conocimiento de la protección de dispositivos.
Con futuras implementaciones de Guard de dispositivos, el escenario ligeramente administrado podrá protegerse sin demasiada sobrecarga. Además, los tiempos de escaneo de la creación de políticas de integridad de código y la creación de archivos de catálogo se mejorarán y pronto se agregarán nuevas características de seguridad.
Una violación de KMCI dará como resultado una pantalla azul. Si ve la siguiente pantalla azul repetidamente, verifique la política de integridad de su código y busque malware:
Guardia de aplicaciones de defensa de Windows para Microsoft Edge
Con Redstone 3/Windows 10 1709, se introdujo una nueva característica de seguridad con el engorroso nombre WDAG para Microsoft Edge. Aunque tiene un nombre difícil de manejar, su funcionalidad se puede explicar fácilmente. El concepto de VBS se extiende a contenedores de software. Por lo tanto, ejecutará software expuesto como su navegador en un sistema operativo virtual adicional y se conectará solo por el protocolo de escritorio remoto (RDP). El primer programa capaz de esto fue Microsoft Edge, pero otros productos seguirán con las próximas versiones de Windows 10. Si se piratean una instancia de Microsoft Edge que se ejecuta en un contenedor tan seguro, no tiene acceso al sistema operativo host. Cuando Microsoft Edge muestra una intranet o sitio confiable, se ejecutará en el sistema operativo host. Al navegar en otros sitios, RDP ejecutará y conectará una nueva instancia en el sistema operativo Windows.
Para activar esta función de seguridad, necesita en ejecución Hyper-V y VBS, por lo que necesitará las extensiones de virtualización de OS y CPU de 64 bits. Para los invitados a Hyper-V, debe activar la función de anidación Hyper-V. Como agregará un tercer sistema operativo a su memoria, la RAM mínima absoluta debe ser de 4 GB. Se recomienda 8 GB o más. Esta función de seguridad también necesita una SKU empresarial. Cuando VBS está en funcionamiento, puede agregar la función de protección de la aplicación de la aplicación Windows Defender, que se puede encontrar en la vista previa de Insider desde 16251 y en el comercio minorista de Windows 10 Versión 1709. También es posible controlar esta función con el GPO activado/apagado Guardia de aplicaciones de defensa de Windows (WDAG). La función necesita un reinicio para activar.
En el modo independiente (cuando no se aplica GPO de aislamiento de red) el usuario puede abrir una instancia de borde protegido con el menú contextual.
Las organizaciones pueden controlar varios aspectos de WDAG. Para definir sitios de confianza para WDAG, necesitan los dominios de recursos empresariales alojados en la nube GPO. Este GPO se puede encontrar en la configuración de la computadora | Plantillas administrativas | Red | Aislamiento de red. Para agregar, por ejemplo, todos los sitios Packtpub y Microsoft a su lista de sitios de confianza, debe habilitar este GPO y agregar la siguiente línea a los recursos en la nube de Enterprise: .packtpub.com | .microsoft.com.
Todas las entradas deben comenzar. y múltiples entradas deben separarse con el carácter de la tubería (|). Personajes de marcador de posición como * o? no están permitidos. Si un recurso necesita una dirección proxy para acceder, debe emparejarse el dominio utilizando una coma trasera seguida de la dirección proxy.
Los GPO específicos de WDAG se pueden encontrar en la configuración de la computadora | Plantillas administrativas | Componentes de Windows | Guardia de aplicaciones de defensa de Windows después de importar las plantillas GPO de 1709 (de hecho, ya han existido parcialmente desde 1703 pero no fueron funcionales en la versión de lanzamiento).
Configurar configuración de portapapeles de la aplicación de la aplicación de Windows GPO controla las operaciones del portapapeles. Por defecto, las operaciones de portapapeles de y en WDAG Edge están bloqueadas por completo. Puede habilitar la copia de WDAG al host y/o viceversa. El contenido de portapapeles se puede limitar solo a texto, solo imágenes o texto e imágenes. Habilitar el portapapeles reduce la seguridad.
Configurar configuraciones de impresión de la aplicación de la aplicación de Windows Configuración GPO Capacidades de impresión. Por defecto, toda la funcionalidad de impresión se desactiva en la protección de aplicaciones. Puede habilitar la impresión y limitarla a XPS, PDF, solo local, solamente en red y muchas combinaciones de estas cuatro opciones o habilitar toda la impresión. Habilitar las funcionalidades de impresión reduce la seguridad.
Permitir la persistencia de datos para Windows Defender Application GPO GPO controla si los datos del usuario, como las cookies y los favoritos, así como los archivos descargados, persistirán dentro del silo de la protección de aplicaciones. De manera predeterminada, WDAG elimina todos los datos del usuario dentro del contenedor de protección de aplicaciones después de detener la instancia. Cuando el GPO está habilitado, aún puede eliminar el contenido utilizando el comando RESET-APLICATIONGUDGUARD PowerShell.
Si solo necesita los archivos de registro de borde de un contenedor de protección de aplicaciones, existe los eventos de auditoría permitidos en Windows Defender Application GPO. Por defecto, los registros de eventos de auditoría no se recopilan para WDAG. Cuando habilita esta configuración, los eventos de auditoría se registrarán en eventos de host.
En el primer inicio de WDAG después del inicio/reinicio, verá una breve salpicadura que le dice cuándo comienza WDAG. Al momento de escribir este libro, dependiendo de RAM, HDD y CPU, esto puede tomar de 10-20 segundos hasta 1-2 minutos en sistemas muy antiguos o limitados.
Además, el usuario obtiene un cuadro de información (desenganchado) que le informa sobre el modo WDAG con un enlace a más información.
El icono de borde muestra un símbolo de escudo cuando se ejecuta en modo WDAG.
Con el cuadro de información desconectado, el usuario solo verá un aviso de guardia de aplicación naranja en la esquina superior izquierda. Aquí hay una comparación entre el modo de sitio de confianza normal y el modo de protección de aplicaciones:
El administrador de tareas no mostrará instancias de borde protegido, sino el cliente WDAG RDP en su lugar:
Con la implementación actual de WDAG, no hay una manera fácil de verificar el consumo de memoria de las aplicaciones que se ejecutan dentro del contenedor de protección de aplicaciones. Actualmente, Microsoft Edge es el primer producto que admite el nuevo modo WDAG. Seguirán más productos de Microsoft. La solución de seguridad de terceros basada en la virtualización Bromium puede ejecutarse al lado de WDAG.
Guardia de explotación del defensor de Windows
Desde hace mucho tiempo, podría habilitar la seguridad adicional en su sistema operativo utilizando el Kit de herramientas de experiencia de mitigación mejorada gratuita (EMET). El desarrollo de EMET se detuvo el año pasado, y el soporte para TI finalizará en julio de 2018. Además, la última versión de EMET 5.5.2 ya no es compatible con Windows 10 1709 y se desinstalará con una actualización en el lugar e instalación de EMET será bloqueado activamente.
Pero no se preocupe; Toda la funcionalidad de EMET y aún más características ahora están integradas en Windows 10 1709. Esta nueva característica de seguridad se denomina Guard de Exploits de Windows Defender y se encuentra dentro del Centro de Seguridad de Defensor de Windows bajo la aplicación y el control del navegador | Protección de exploit:
Al acceder a la configuración de protección de exploit, puede controlar la configuración de todo el sistema y las anulaciones específicas del programa. Estar cuidadosamente con la configuración de todo el sistema. Las configuraciones por programa se realizan mediante un esquema que aplica la función en el nombre de la aplicación. Como los esquemas de APP-V y los esquemas de protección EMET/Exploit no pueden anidadarse, la configuración de la guardia de explotación no se aplicará en las aplicaciones de App-V.
La configuración de todo el sistema contiene la configuración (ya conocida de EMET) de prevención de ejecución de datos (DEP), que evita la ejecución del código de las páginas de memoria de solo datos; Dirección de la aleatorización del diseño del espacio (ASLR), ahora llamado (ASLR obligatorio), que obliga a la reubicación de imágenes (DLLS); y Protección de sobrescritura de manejo de excepciones estructuradas (SEHOP), que garantiza la integridad del controlador de excepción antes de ejecutarlo, validando la integridad del montón para la rociado de almacenamiento y la corrupción de almacenamiento de montón.
Además, ahora puede hacer cumplir CFG, lo que garantiza la integridad de todas las llamadas indirectas, y ASLR de abajo hacia arriba, que aleatorizará todas las ubicaciones para las asignaciones de memoria virtual.
La configuración del programa se puede definir mediante el nombre del programa o la ruta exacta del archivo. Por programa, puede anular cada configuración de todo el sistema y definir más configuraciones. Y como una gran mejora sobre EMET, puede activar una auditoría en cada configuración. Donde EMET era más como una forma de configuración de prueba y error (active todas las configuraciones y luego desactive la configuración uno por uno hasta que la aplicación funcione), la nueva auditoría ayuda a encontrar la configuración incompatible muy rápidamente.
Según la configuración del programa de Guard de Exploit, incluye Guard de código arbitrario (ACG), que evita la modificación de la página del código; Bloquear imágenes de baja integridad, que evita la carga de imágenes marcadas con baja integridad; Bloquear imágenes remotas, que evita la carga de imágenes de dispositivos remotos; Bloquear fuentes no confiables, que evita la carga de cualquier fuente a base de GDI que no esté instalada en el directorio de fuentes del sistema; Code Integrity Guard, que solo permite la carga de imágenes firmadas por Microsoft; Desactivar puntos de extensión para deshabilitar varios mecanismos extensibles que permiten la inyección de DLL en todos los procesos, como los ganchos de ventana; Deshabilite la llamada del sistema WIN32K para evitar que los programas usen cualquier llamada del sistema WIN32K; No permita que los procesos infantiles eviten que los programas creen procesos infantiles; Filtrado de dirección de exportación (EAF) para detectar funciones exportadas peligrosas que se resuelven con código malicioso; Filtrado de dirección de importación (IAF), que hace lo mismo que EAF pero para funciones importadas; Simular la ejecución (SIMEXEC) para garantizar que las llamadas a las funciones sensibles vuelvan a las personas que llaman legítimas; Validar la invocación API (CallerCheck), que garantiza que las API sensibles sean invocadas por personas que llaman legítimas; Validar el uso del manejo, que plantea una excepción en cualquier referencia de manejo no válido; Validar la integridad de la dependencia de la imagen, que impone la firma de código para la carga de dependencia de la imagen de Windows; y validar la integridad de la pila (StackPivot), que garantiza que la pila no haya sido redirigida para funciones sensibles.
Cada una de estas funciones agrega seguridad a sus aplicaciones a costa de gastos generales de la CPU. Como esta sobrecarga depende del código de la aplicación, no hay números generales en el éxito de rendimiento para la mayoría de las características de seguridad. Debe verificar el rendimiento de cada una de sus aplicaciones individualmente.
La configuración solo se puede cambiar/eliminar como usuario administrador. Todas las configuraciones se pueden editar en la GUI y exportar como XML para configurar por GPO.
Certificado de salud del dispositivo
Windows 8.0 ya introdujo una nueva posibilidad de evaluar la salud del proceso de arranque llamado arranque medido, una variante grabada del arranque seguro. Pero la parte del contador empresarial adecuado para verificar los datos de salud y hacer cumplir el control de acceso no estaba disponible en ese momento.
Con Windows 10 1511, la técnica se nombró como Windows Probable PC Health (PPCH) y luego con Windows 1607 y Newer renombrado a DHA. En Windows Server 2016, la contraparte se llama Servicio de Certificado de Salud (HA).
Pero, ¿qué es exactamente DHA? Combinará arranque seguro, VBS, Elam y protección de sus controladores de botas tempranas y los medirá con la ayuda de su TPM 2.0. Estos resultados de datos de arranque medidos son recopilados por el proveedor de servicios de configuración de certificación de salud (CSP) y enviado a un control remoto para la verificación/comparación con las políticas actuales:
El proceso de certificado de salud verificará los componentes de arranque de hardware (por ejemplo, valores de PCR), componentes de arranque del sistema operativo (por ejemplo, contador de arranque) y si la protección del dispositivo está habilitada, la política de protección de dispositivos actual. Se verificará más en el núcleo de Windows (por ejemplo, firmación), su anti-malware compatible con Elam se lanzará como el primer controlador de modo de kernel y medido y por último, pero no menos importante, se medirán todos los controladores de arranque tempranos necesarios.
Cuando su cliente solicita acceso a un recurso corporativo protegido, su cliente necesita una certificación de salud válida. El CSP de CSP de salud enviará los datos recopilados al URI pre-proporcionado. Actualmente, el servicio DHA está diseñado para esperar un servicio en la nube de Microsoft al igual que la contraparte (HASSPSERV.Microsoft.com). Actualmente se investiga una variante de las premisas en las premisas y posiblemente está disponible en una versión futura de Windows 10. Los datos recopilados están firmados y contiene su registro TPM, los datos de la clave de identidad de certificación (AIK) (valores de PCR, contador de arranque, etc.) La información del certificado AIK.
El servicio de certificación de salud del dispositivo remoto verifica el certificado y compara los datos con sus valores configurados. Si todo está dentro del rango, un token de salud del dispositivo que contiene la información de salud junto con un tiempo de emisión válido se generará, encriptará, firmará y se enviará al cliente. El cliente almacena el BLOB cifrado de salud en su tienda local.
Estos pasos se realizan después de la activación de la certificación de la salud y en cada arranque y rehacido tan pronto como expiró la fecha de validez del token de salud. Al acceder a un activo de alto valor en su entorno corporativo, el cliente enviará su token de salud válido al proveedor de identidad y una decisión de acceso condicional otorgará o negará el acceso. Cuando no se cumplen los criterios de salud o se anticipa no se otorga acceso.
En el lado del cliente, necesitará Windows 10 instalado en modo UEFI con Boot Secure ACTIVADO y TPM 2.0. Con la implementación actual de DHA, necesitará en el lado del backend, el servicio de la nube tiene Microsoft, una solución MDM que admite DHA (por ejemplo, Intune) y Azure AD Standalone o Azure AD con conector AD en modo híbrido.
Se recomienda el uso de VBS, guardia de credencial y protección de dispositivos para mejorar aún más la seguridad.
La activación del certificado de salud en el lado del cliente se realizará como parte de la inscripción con el proveedor de MDM. Sin configuración, la certificación de salud se deshabilitará de forma predeterminada.
DHA es una mejora consecuente sobre la protección de acceso a la red descontinuada (NAP). Proporcionará una manera fácil de aumentar la seguridad y la integridad del dispositivo sin el jefe alrededor de sus usuarios.
Centro de seguridad del defensor de Windows
El Centro de seguridad de Windows Defender introducido con 1703 y extendido con 1709 se describirá junto con Windows Defender ATP en el siguiente.
Nuevas opciones de bitlocker
El cifrado de disco duro de cifrado avanzado (AES) (BitLocker) utilizado ya que Windows Vista fue el encadenamiento de bloques de cifrado AES (AES-CBC). Vista y Windows 7 proporcionaron también AES-CBC con difusor de elefante. Para admitir el cifrado de hardware de BitLocker con las llamadas unidades encriptadas (EDRIVE), el soporte para el difusor de elefantes se eliminó con Windows 8.0. Todavía se puede acceder a AES con difusor, pero el nuevo cifrado solo se puede hacer en AES-CBC 128 o 256 bits.
Con la introducción de Windows 10 1511, se implementó un nuevo estándar AES llamado AES-XEX basado en el modo de código de código ajustado con el robo de texto cifrado (XTS-AES). XTS-AES proporciona protección adicional de una clase de ataques contra el cifrado que se basan en manipular con texto cifrado para causar cambios predecibles en el texto plano al agregar permutaciones adicionales. XTS-AES no estará de portada en OSE más antiguos.
De forma predeterminada, Windows 10 1511 y Newer utilizarán XTS-AES para la unidad del sistema operativo y las unidades de datos fijos. Por razones de compatibilidad, las unidades extraíbles utilizarán el antiguo método AES-CBC. Tan pronto como todos los OSE que acceden a la unidad extraíble son Windows 10 1511 o más nuevos, también puede cambiar de forma segura a XTS-AES para unidades extraíbles.
Para distinguir entre AES con difusor (Vista/Server 2008 Till Windows 7/Server 2008 R2), AES-CBC solo (Windows 8/Server 2012 hasta Windows 10 1507/Server 2012 R2) y nuevo AES-CBC + XTS-AES ( Windows 10 1511 y posterior/servidor 2016), ahora hay 3 GPO diferentes:
Solución de contraseña de administrador local
¿Dónde almacena la contraseña de la cuenta de administración local en cada PC de su dominio? Las opciones incluyen:
- La cuenta está deshabilitada, solo use una cuenta/grupo de dominio para los derechos de administración locales (¿qué pasa cuando el dominio no está disponible?)
- Use la misma contraseña en cada máquina, establecida en el momento en que está construido (¡una excelente manera de permitir que el malware se extienda por toda la red en segundos!)
- Use una hoja de cálculo u otras notas centralizadas para grabarlas para otros administradores para acceder, pero está bien porque está en una red segura compartida y contraseña protegida (porque nadie podría hacer una copia o descifrar la seguridad débil de Excel, ¿verdad?)
¿Y qué hace cuando desea cambiar la contraseña después de que su sistema se haya visto comprometido, o uno de sus administradores se va, o un usuario ha descubierto la contraseña y ahora la está utilizando para instalar software y hacer cambios no autorizados? Estas son sus opciones:
- Cambiarlos uno por uno: visitar cada terminal manual o remotamente
- Use PowerShell u otra herramienta de secuencias de comandos (¿sigue usando la misma contraseña para cada PC?)
- Preferencias de política de grupo (esta opción no es segura y la función ahora ha sido deshabilitada)
Para resolver este problema, Microsoft proporciona la solución de contraseña de administrador local (LAPS). Puede descargar el paquete desde el sitio web de Microsoft: https://www.microsoft.com/en-us/download/confirmation.aspx?id=46899.
Una vez descargado, verá los siguientes archivos nuevos:
Preparación de anuncios
Para implementar esta solución, hay algunos pasos básicos que deben seguirse; Consulte la Guía de operaciones para obtener más información sobre lo siguiente:
- Actualización del esquema de anuncios: antes de que se pueda usar esta solución, el esquema de anuncios debe extenderse por dos nuevos atributos.
- Permisos del administrador: hay varios permisos que deben establecerse para permitir que las computadoras actualicen AD con los detalles de su cuenta de administrador local y eviten el acceso no autorizado a las contraseñas una vez que se almacenan en Active Directory:
- Agregue los derechos de la máquina para habilitar cada computadora administrada para actualizar los nuevos atributos de esquema
- Eliminar los derechos extendidos de todos los usuarios para evitar el acceso a las contraseñas
- Agregue los derechos de usuario para permitir que el usuario o grupo apropiado pueda recuperar las contraseñas
Ahora a la instalación
Cuando instale las vueltas por primera vez manualmente, verá las siguientes indicaciones:
Haga clic en Siguiente.
Deberá instalar las herramientas de administración en la PC donde recuperará las contraseñas, así como la extensión ADMPWD GPO si desea que se administre la misma máquina:
Haga clic en Siguiente.
Haga clic en Instalar.
Una vez que se complete la instalación, lo siguiente estará disponible.
Vueltas ui
La interfaz de usuario principal permite al administrador consultar AD, según el nombre de la computadora, y recuperar los detalles de la contraseña.
En el menú Inicio, verá el siguiente icono de acceso directo:
Cuando lo inicie, se le presentará la siguiente pantalla, que se puede usar para recuperar contraseñas para computadoras específicas en su dominio, y establecer la nueva fecha/hora de vencimiento:
Política grupal Extensión del lado del cliente
Esto debe implementarse en cada computadora administrada. Esto se puede gestionar utilizando una variedad de métodos, incluida la función de instalación de software de la política de grupo, SCCM, Script de inicio de sesión, instalación manual, etc.
Si desea escribir esto, puede usar esta línea de comandos para realizar una instalación silenciosa:
msiexec /i
\ laps.x64.msi /silencio
msiexec /i\ laps.x86.msi /Quiet
Simplemente cambie
Ejemplo: msiexec /i \\ servidor \ share \ laps.x64.msi /silencio
Opciones de configuración de políticas de grupo
Ahora configuramos la política de grupo para aplicar los cambios de contraseña a esta PC:
Configuración de contraseña: las siguientes opciones están disponibles para configurar la configuración local para las contraseñas administradas por esta solución:
Nombre de la cuenta de administrador para administrar: Esto es para cuando ha cambiado el nombre del administrador predeterminado o ha creado una nueva cuenta:
Política de vencimiento de contraseña: esta configuración garantiza que la política no entra en conflicto con la política de seguridad definida a nivel de dominio:
Habilitar o deshabilitar la política: esta configuración le permite crear la política en un estado discapacitado y luego habilitar la política cuando está listo para implementar:
Una vez que haya configurado la política y la haya dirigido a un OU, puede ejecutar GPUPDate en la máquina de destino o esperar el tiempo de actualización predeterminado.
Pruebe que las contraseñas se han cambiado y que puede recuperar con éxito la contraseña utilizando la interfaz de usuario de Laps.
Resumen
En este artículo, aprendió sobre las nuevas y mejoradas capacidades de seguridad de Windows 10 y cómo pueden protegerlo en el escenario actual de amenaza de seguridad cibernética. Aumentar el nivel de seguridad es un esfuerzo continuo, y las versiones futuras de Windows 10 pronto traerán características de seguridad adicionales. Pero incluso con todas estas características de seguridad, puede ocurrir una violación. Por lo tanto, es importante detectar tal violación lo antes posible, encontrar su punto de origen y tomar contramedidas adecuadas.