El blog de Santiago Nuñez Martinez https://docs.microsoft.com/archive/blogs/snunez/feed.xml Notas y experiencias personales sobre seguridad. Tue, 16 Apr 2019 06:17:31 GMT es_ES hourly 1 Diferenciar usuarios sincronizados con Azure AD Connect https://docs.microsoft.com/archive/blogs/snunez/diferenciar-usuarios-sincronizados-con-azure-ad-connect Mon, 10 Sep 2018 14:22:25 GMT https://blogs.technet.microsoft.com/snunez/?p=155
  • DirSyncEnabled
  • ImmutableId
  • OnPremisesSecurityIdentifier
  • LastDirSyncTime
    • De estos atributos, el más lógico es DirSyncEnabled. Pero una característica interesante a la hora de usar este atributo es que o tiene el valor true o tiene null; no tiene el valor false. Mis primeros scripts y grupos asumían que el valor sería true o false, y no funcionaban correctamente. Teniendo en cuenta esta característica, no resulta complicado tener una consulta powershell que nos devuelva los usuarios creados en Azure AD: 
    Get-AzureADUser -All $true | where {$_.DirSyncEnabled -ne $true}
    O crear un grupo dinámico. [caption id="attachment_165" align="alignnone" width="300"]Grupo Dinámico de Azure AD Grupo Dinámico de Azure AD[/caption]]]>         Auditar Office 365 https://docs.microsoft.com/archive/blogs/snunez/auditar-office-365 Fri, 29 Dec 2017 13:07:56 GMT https://blogs.technet.microsoft.com/snunez/?p=115
  • Habilitar los eventos de auditoría en Office 365
  • Consultar estos eventos de auditoría
  • Integrar estos eventos en un SIEM (por ejemplo OMS)

    • Eventos de auditoría en Office 365.

    El primer paso es habilitar la auditoría de los elementos que os interesan. Office 365 es un conjunto de servicios: Exchange Online, SharePoint Online, Teams, Yammer, Power BI, Sway, ... (seguro que me dejo alguno). Hay que registrar los eventos de Office 365 que nos interesen. Una forma sencilla de comenzar es habilitar el log unificado de Office 365 (https://support.office.com/en-us/article/Turn-Office-365-audit-log-search-on-or-off-e893b19a-660c-41f2-9074-d3631c95a014). Si disponéis de un entorno de pruebas, os recomiendo usarlo para facilitar la decisión de qué eventos queremos registrar, una aproximación que suelo recomendar es empezar por Exchange Online, habilitar la auditoría en los buzones de correo y revisar los eventos de auditoría para adaptarlos a nuestras necesidades. 
    $Creds = Get-Credential 
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell -Credential $Creds -Authentication basic -AllowRedirection
Import-PSSession $Session

Set-AdminAuditLogConfig -UnifiedAuditLogIngestionEnabled $true

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditEnabled $true
Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | Set-Mailbox -AuditLogAgeLimit 180

Get-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox"} | FL Name,Audit*

    Consultar los eventos de auditoría.

    Ya tenemos habilitada la auditoría con los eventos que nos interesa (o estamos en ello) y lo que necesitamos es hacer consultas sobre estos eventos. Lo más habitual es que los usuarios que necesitan hacer consultas, dispongan de cuentas de usuario con los permisos adecuados delegados para hacer las consultas. Para conseguir estos permisos, se pueden usar los roles existentes (incluyendo los roles de Exchange) o se pueden crear delegaciones personalizadas según las necesidades. La herramienta que suelo recomendar para ello es https://protection.office.com (el centro de seguridad y cumplimiento de Office 365. Para más información sobre como hacer las consultas, ver el artículo: https://support.office.com/en-us/article/Search-the-audit-log-in-the-Office-365-Security-Compliance-Center-0d4d0f35-390b-4518-800e-0c7ec95e946c 

    Integración con SIEM.

    Las principales dudas vienen a la hora de integrar estos eventos con el SIEM corporativo. La mayoría de las organizaciones ya disponen de un SIEM para los eventos de seguridad y quieren integrar los eventos de Office 365. Es importante tener habilitado el registro de los eventos que necesitemos (lo que no se habilite no aparecerá). En Azure AD, se creará una aplicación para conceder acceso a los log al SIEM. Este proceso se hace una única vez de manera que el SIEM se conecte con las credenciales de esa aplicación para descargarse los eventos. Normalmente, el fabricante del SIEM tiene documentado el procedimiento para crear esa aplicación, y en algunos casos (como OMS) la creación de la aplicación se realiza de manera automática. A partir de este momento, los eventos llegarán al SIEM y se podrá trabajar con ellos. Al igual que en el caso anterior, suelo recomendar tener un entorno de prueba y en esos casos, añadir OMS es realmente sencillo: https://docs.microsoft.com/en-us/azure/operations-management-suite/oms-solution-office-365]]>         Métodos para "controlar" Active Directory https://docs.microsoft.com/archive/blogs/snunez/metodos-para-controlar-active-directory Wed, 28 Jun 2017 16:51:59 GMT https://blogs.technet.microsoft.com/snunez/?p=105
  • Auditoria de Active Directory
  • Revisión de configuración de Active Directory
  • Análisis de comportamiento de Active Directory
    • Primero el contexto. Se trata de una organización en la que las tareas de administración de Active Directory están separadas de las tareas de seguridad. En este caso, se trata de dar una visión al departamento de seguridad sobre lo que sucede en Active Directory. La primera palabra clave que salió en la conversación es auditoría, pero en este contecto había que tener en cuenta que además de tener los eventos de auditoría de lo que sucede (un usuario ha iniciado sesión, se ha asignado un nuevo miembro a un grupo, ...) era omteresate saber cómo estaba configurado el entorno (que grupos privilegiados existen, que miembros tienen, ...) y además ser capaz de entender cuando un evento es una posible alerta (detectar comportamientos anómalos, ...).

    Auditoría de Active Directory

    Las funciones de auditoría en Active Directory son muy conocidas y de forma resumida se trata de counfirar los eventos de auditoría que queremos que registren en los controladores de dominio (Security Event Log). Hay muchas guías de configuración, de forma resumida los pasos son los siguientes:
    • Habilitar la auditoría en los controladores de dominio para los objetos de Active Directory (https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations)
    • Habilitar la auditoría en los propios objetos a monitorizar (SACL) (En el mismo documento, hay una serie de recomendaciones de objetos a auditar  https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/audit-policy-recommendations#active-directory-objects-and-attributes-to-monitor)
    Una vez realizadas las configuraciones lo más habitual es enviar los log de auditoría a un SIEM o a un sistema para su análisis. Hay varios artículos muy interesantes al respecto de la auditoría en Active Directory: https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/plan/security-best-practices/monitoring-active-directory-for-signs-of-compromise https://technet.microsoft.com/en-us/library/cc731607(v=ws.10).aspx

    Revisión de configuración de Active Directory

    El problema de quedarse sólo con la auditoría, es que las mejoras de configuración sólo se realizarán cuando se detecte un comportamiento no deseado, pero existen una serie de recomendaciones que podemos aplicar de manera proactiva. Mis compañeros de soporte tienen un servicio que se llama Active Directory Security Assessment que recopila la información de seguridad de un entorno de Active Directory y presentan un informe con los principales riesgos de seguridad y como resolverlos. Una opción DIY de realizar una revisión de Active Directory (menos completa que la anterior) es usar OMS (Operations Management Suite) para ello existe un módulo "AD Assessment" que es un buen punto de partida. https://blogs.technet.microsoft.com/msoms/2016/01/12/use-operations-management-suite-for-active-directory-assessment/

    Análisis de comportamiento de Active Directory

    En la parte de comportamiento ya estamos hablando de otro tipo de recopilación de información. Aquí es donde encaja ATA (Advanced Threat Analytics) que permite analizar el comportamiento de usuarios y entidades (equipos) y levanta alertas ante comportamientos anómalos. Es un producto que entra dentro de la categoría UEBA (User and Entity Behavior Analytics). El despliegue es muy sencillo y en muchos casos sin impacto en Active Directory, ya que no hace falta ningún tipo de permisos en Active Directory. Lo que se hace es “duplicar” el puerto de recibe y envía tráfico de los controladores de dominio, mediante port mirroring y todo el tráfico que entra y sale de los DC se envía también a un ATA Gateway que se encarga de analizarlo. También se puede recolectar este tráfico con un agente ATA Lightweight Gateway. De esta manera, ATA detecta diferentes comportamientos anómalos:
    • Basados en patrones. Estos comportamientos anómalos se detectan sin necesidad de un aprendizaje y se basan en comportamientos que por la secuencia de actividades entran claramente en un patrón de ataque, como son:
      • Actividades de reconocimiento (enumeraciones DNS, enumeraciones de cuentas, …)
      • Actividades sospechosas de fuerza bruta (NTLM, Kerberos, LDAP,…)
      • Implementaciones maliciosas de protocolos (DPAPI)
      • Cuentas “honey pot” con actividad
      • Pass-the-Hash, Pass-the-Ticket, Silver Ticket, Golden ticket, …
      • Y seguro que me dejo alguna
    • Basados en comportamiento. Aquí se detectan comportamientos anómalos basados en el modelo de comportamiento que ha creado ATA.
      • Acceso a recursos anómalos
      • Horas de actividad anómalas
      • Ejecuciones remotas
    Hay mucha más información sobre ATA en https://www.microsoft.com/en-us/cloud-platform/advanced-threat-analytics

    Mis recomendaciones

    Si es posible, usar los tres métodos:
    • Auditar los eventos de seguridad de Active Directory que se recomiendan.
    • Realizar un assessment de seguridad continuo (si puede ser con los servicios de soporte Premier, mejor).
    • Utilizar una herramienta de detección de comportamientos anómalos.
    ]]>         Azure Key Vault en entornos de producción https://docs.microsoft.com/archive/blogs/snunez/azure-key-vault-en-entornos-de-produccion Thu, 11 May 2017 21:30:52 GMT https://blogs.technet.microsoft.com/snunez/?p=47 ¿Qué es Azure Key Vault? Lo primero, por si no os suena, Azure Key Vault es un servicio de gestión de claves criptográficas y secretos. Se trata de un servicio de Azure en el que se pueden mantener secretos (contraseñas) o claves criptográficas que se usarán desde diferentes aplicaciones. Lo más interesante de este servicio es que separa la gestión del ciclo de vida de las claves (que normalmente será responsabilidad de los responsables de seguridad) del ciclo de vida de las aplicaciones que usan las claves (que serán responsabildad de los desarrolladores). Si queréis leer en más detalle sobre Azure Key Vault: https://docs.microsoft.com/azure/key-vault/

    azure-key-vault¿Por qué no veo las claves en el Key Vault de producción?

    Esta fue la duda que me planteó mi compañero. Y venía justificada porque en el entorno de desarrollo, podía conectarse con su cuenta al Key Vault de desarrollo y ver las claves que existían, sus propiedades, etc. Pero en el entorno de producción ya no era así. Su cuenta de desarrollador no tenía ningún permiso en el Key Vault de producción y por lo tanto no veía ninguna clave ni secreto. La aplicación funcionaba correctamente (porque se habían asignado los permisos a la identidad de la aplicación), pero los desarrolladores no podían ver si las claves existían, sus propiedades, etc. La conclusión era que todo funcionaba correctamente y que el modelo de permisos de acceso para el Key Vault estaba funcionando correctamente. En la mayoría de ejemplos que existen se muestran las claves, propiedades, etc. porque se hace con permismos de administrador, pero no hay que asumir que siempre se tendrán esos permisos.    ]]>         ¡Hola mundo! https://docs.microsoft.com/archive/blogs/snunez/hola-mundo Tue, 25 Apr 2017 17:10:08 GMT https://blogs.technet.microsoft.com/snunez/?p=35
  • El contenido se basará en mis opiniones y mi experiencia personal. Eso significa que puedo estar y estaré equivocado en lo que escriba en muchas ocasiones, pero si hay suerte en algún caso acertaré. Mi recomendación para los lectores es que no hay que creer todo lo que se lee en Internet.
  • Mi objetivo personal es recopilar información útil y experiencias que comparto con compañeros y clientes y que me será más fácil compartir desde aquí­.
  • La tématica de las entradas será variada y dependerá de lo que tenga que compartir en cada caso. Lo normal sería: seguridad, criptografíaa, certificados, ... veremos.
  • La frecuencia dependerá de qué tenga algo interesante que compartir. Intentaré publicar algo al menos una vez al mes.
  • Si dejas un comentario, lo revisaré y contestaré siempre que me sea posible. Pero eso no incluye revelar información que no esté autorizado o resolver problemas de entornos en producción.
    • ]]>