Microsoft Defender y PowerShell

style="letter-spacing: 0px; text-transform: unset; background-color: transparent;">¿Está migrando su organización a Exchange Online? ¿Utilizará Exchange Online Protection (EOP) únicamente o la combinará con productos de terceros? Analizaremos diferentes soluciones para mantenernos seguros.

Al migrar una organización de una solución de correo local a Exchange Online, un escenario típico es cómo manejar el flujo de correo al final del proyecto cuando la solución de correo electrónico local ya no está presente. Algunas organizaciones nunca han utilizado Exchange Online Protection (EOP) y utilizan una solución de terceros como ProofPoint, MessageLabs o Barracuda, por ejemplo. En esta fase del proyecto, se debe tomar una decisión: cambiar solo a EOP o mantener el actual producto de higiene del correo electrónico de terceros e incorporar EOP a esa combinación.

Si bien cambiar a EOP puede parecer sencillo, no necesariamente se debe a las reglas existentes ni a los ajustes de configuración vigentes. Además, es posible que el nivel de comodidad con este producto no se preste para cambiar a EOP para el enfoque único. Afortunadamente, existen algunas configuraciones que podemos implementar para que EOP (y Defender) manejen este escenario.

Antes

Después

La solución

Para que esto funcione correctamente, debemos realizar algunos cambios para que EOP pueda tratar el tráfico como comunicaciones SMTP confiables. Podemos realizar esta tarea con tres métodos o soluciones diferentes que veremos a continuación:

Solución 1

Antes de algunos cambios que Microsoft realizó en su configuración de Exchange Online Protection (EOP), la configuración típica para procesar el correo electrónico de un proveedor de higiene externo era crear entradas de filtro de conexión para las IP del servidor. Por ejemplo, Message Labs tiene documentación que se puede encontrar aquí. Eso explica cómo hacer esto en un inquilino. Las mismas acciones también se pueden realizar en PowerShell. Primero, comprobaremos qué filtros de conexión existen actualmente:

Get-HostedConnectionFilterPolicy

En un entorno totalmente nuevo, deberíamos ver esto:

En el caso de los mensajes entrantes de Mimecast, necesitamos agregar direcciones IP a 'IPAllowList' para que esto funcione. Si tuviéramos (por ejemplo) las direcciones IP 207.12.34.4 y 5, podríamos agregarlas con esta frase:

Set-HostedConnectionFilterPolicy Default -IPAllowList 207.12.34.4,207.12.34.5

Solución 2

Otro método utilizado es crear una regla de transporte que acepte conexiones del proveedor externo y omita el motor de filtrado de spam de EOP. Simplemente necesitamos las direcciones IP del proveedor y un parámetro llamado ExceptIfSCLOver, que está configurado en -1 según la documentación de Microsoft para reglas de transporte y tenemos esta frase :

New-TransportRule 'Inbound from Mimecast' -SenderIpRanges 207.12.34.4,207.12.34.5 -ExceptIfSCLOver -1

Con esto, cualquier correo electrónico procedente de esas direcciones IP evitará el filtrado de spam.

Solución 3

En esta solución, usaremos algo a lo que Microsoft agregó una nueva capacidad llamada Filtrado mejorado (omitir listado). Omitir lista permite que EOP analice mejor un correo electrónico cuando proviene de un servicio de higiene de terceros que se encuentra frente a EOP. Hay dos partes en esta configuración para que funcione: conector entrante y filtrado mejorado.

Nuevo conector entrante

New-InboundConnector -Name 'Mimecast Inbound' -ConnectorType Partner -SenderDomains '*' -SenderIPAddresses 207.12.34.4,207.12.34.5

Agregar configuración para omitir listado

Una vez que tengamos un conector, también podemos agregar la configuración de Omitir listado al conector. Hay dos parámetros posibles para configurar esto en el conector entrante y son EFSkipLastIP y EFSkipIPs. El uso del valor EFSkipLastIP le indicará a EOP cuándo se realiza una revisión del encabezado para omitir la última IP antes de ser recibida por EOP, asumiendo que esta es la IP del proveedor de servicios. La otra propiedad EFSkipIPs permite la configuración manual de direcciones IP específicas. A continuación se muestra un ejemplo de ambos parámetros utilizados:

Set-InboundConnector -Identity 'Mimecast Inbound' -EFSkipLastIP $TrueSet-InboundConnector -Identity 'Mimecast Inbound' -EFSkipIPs 207.12.34.4,207.12.34.5

Omitir lista también se puede filtrar a uno o varios usuarios si así se desea, tal vez para realizar pruebas:

Usuario único

Set-InboundConnector -Identity 'Mimecast Inbound' -EFUsers damian@practicalpowershell.com

Múltiples usuarios (grupo)

Set-InboundConnector -Identity 'Mimecast Inbound' -EFUsers it@practicalpowershell.com

PRECAUCIÓN!
Se justifica una advertencia porque a las direcciones IP especificadas se les permitirá más indulgencia que a otras direcciones IP. Puede que valga la pena verificar estas direcciones IP en un período de un trimestre o seis meses en caso de que esto cambie.
< br>

Simulaciones de phishing

Uno de los vectores de ataque más comunes para el correo electrónico es el phishing y muchos proveedores han creado soluciones para eliminar la mayor cantidad posible de este ataque de la vista del usuario. Sin embargo, quedan correos electrónicos que no son bloqueados por estas soluciones y terminan en el buzón del usuario. Para ayudar a identificar estos correos electrónicos, las empresas han creado servicios que ayudan a probar y capacitar a los usuarios para reconocer estos tipos de correo electrónico. Los proveedores van desde Microsoft hasta KnowBe4 y muchos otros. Un problema inherente es que si el mensaje de prueba llega de una fuente externa, EOP tiende a bloquearlo y nunca llega al buzón de correo del usuario. Para evitar esto, muchos proveedores instruyeron a la organización a crear reglas de transporte que evitarían los filtros de detección en EOP. Microsoft ha agregado una nueva característica para facilitar este proceso. Se llama "Entrega avanzada", con una subfunción llamada "Simulación de phishing". PowerShell se puede utilizar para administrar esta característica, desde el módulo PowerShell del Centro de seguridad y cumplimiento.

Al crear estas excepciones, asegúrese de recordar que al agregar estos servidores de envío, se omitirán muchos de los servicios de filtrado de EOP:

• Filtros en EOP y Microsoft Defender para Microsoft 365
• Purga de hora cero (ZAP)
• Alertas predeterminadas del sistema
• AIR y agrupación en clústeres en Defender para Microsoft 365
• Las alertas y AIR no se activarán
• Vínculos seguros en Defender para Microsoft 365
• Archivos adjuntos seguros en Defender para Microsoft 365
  
  

Cmdlets de PowerShell

Get-PhishSimOverridePolicyGet-PhishSimOverrideRuleNew-PhishSimOverridePolicyNew-PhishSimOverrideRuleRemove-PhishSimOverridePolicyRemove-PhishSimOverrideRuleSet-PhishSimOverridePolicySet-PhishSimOverrideRule

Configuración por defecto

Si buscamos Políticas o Reglas con PowerShell, vemos que en un inquilino, la configuración predeterminada está en blanco:

Como muchos otros elementos de configuración en Microsoft 365, estos dos cmdlets forman un par y necesitamos crear una Política y una Regla para continuar con esta característica. En la siguiente sección, analizaremos este proceso de creación.

Agregar una configuración personalizada

Primero, necesitamos crear una política y debe llamarse 'PhishSimOverridePolicy' debido a las restricciones de Microsoft de una política por inquilino:

New-PhishSimOverridePolicy -Name ' PhishSimOverridePolicy'

Con esta nueva Política, ahora podemos crear la Regla que controla qué servidores pueden comunicarse con el inquilino. En la siguiente línea, hacemos referencia a la Política que creamos, las IP de los remitentes externos de simulación de phishing, así como dos dominios para los que permitiremos la entrada de mensajes.

New-PhishSimOverrideRule -Name 'PhishSimOverrideRule' -Policy 'PhishSimOverridePolicy'  -SenderDomainIs PracticalPowerShell.com,PowerShellGeek.com -SenderIpRanges 147.160.167.0/26, 23.21.109.197,23.21.109.212

Tenga en cuenta que el nombre que proporcione se ignorará y se creará una nueva regla con un nombre similar a este:

Con la Política y Regla configuradas, cualquier simulación de Phish de nuestro proveedor, siempre que provenga de las IP predefinidas y esté destinada a los dominios predefinidos, se entregará al buzón de correo de un usuario final.

REFERENCIA:
Estas mismas configuraciones también aparecen en Microsoft Defender Center:
Correo electrónico y colaboración > Políticas > Políticas de amenazas > Entrega avanzada

Configuración posterior

Una vez que la Política/Regla esté lista, podemos ejecutar cmdlets de PowerShell para verificar la configuración, tal vez con fines de validación o documentación. Estos dos cmdlets servirían para ese propósito y no necesitan ningún parámetro para ejecutarse:

Get-PhishSimOverridePolicy

Get-PhishSimOverrideRule

Buzón de operaciones de seguridad

Primero, ¿qué es un buzón de SecOps? SecOps es una abreviatura de Operaciones de seguridad, pero también se abrevia como equipo de seguridad de una organización. El buzón es un buzón dedicado que puede recibir correo electrónico sin filtrar (malicioso o no) para que un equipo de seguridad lo revise. Para utilizar esta función se debe identificar o crear un buzón dedicado para este fin. Una vez que el buzón esté listo, podemos usar PowerShell para crear nuestra combinación de política y regla para la función de buzón SecOps.
De forma predeterminada, el inquilino de una organización no debe tener ninguna en la lista:

Veamos qué cmdlets de PowerShell tenemos disponibles para configurar esta característica:

Cmdlets de PowerShell

Get-SecOpsOverridePolicy
Get-SecOpsOverrideRule
New-SecOpsOverridePolicy
New-SecOpsOverrideRule
Remove-SecOpsOverridePolicy
Remove-SecOpsOverrideRule
Set-SecOpsOverridePolicy
Set-SecOpsOverrideRule

Crear nueva política/regla

Al crear una Política y Regla, solo necesitamos la dirección de correo electrónico del buzón que se utilizará para esta función. El nombre tanto de la Política como de la Regla no se puede personalizar y debe utilizar los nombres predeterminados proporcionados por Microsoft. Los nombres de ambos se pueden encontrar en la documentación de los cmdlets: New-SecOpsOverridePolicy y New-SecOpsOverrideRule. Una vez que tengamos esa información, podemos crear la combinación Política/Regla:

New-SecOpsOverridePolicy -Name SecOpsOverridePolicy -SentTo SecurityTeam@powershellgeek.com
New-SecOpsOverrideRule -Name SecOpsOverrideRule -Policy SecOpsOverridePolicy

Tenga en cuenta que solo se permite una política y una regla para las anulaciones de SecOps:

Modificar una política/regla existente

Por supuesto, una vez colocado este par, también podremos modificar la configuración si surge la necesidad. Sin embargo, por más normal que sea en PowerShell, no hay mucho que cambiar ni en la Política ni en la Regla. En la Política, Obtener ayuda para el cmdlet muestra muchas opciones, pero en realidad, solo podemos modificar las propiedades Comment y SentTo con cualquiera de los cmdlet. A continuación se muestran algunos ejemplos de estos parámetros en acción:

Políticas:

Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment 'Sec Ops Policy - Security Team Mailbox'
Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment -AddSendTo ITManagers@powerShellgeek.com
Set-SecOpsOverridePolicy -Identity SecOpsOverridePolicy -Comment -RemoveSentTo securityTeam@powerShellgeek.com

Reglas:

Get-SecOpsOverrideRule | Set-SecOpsOverRideRule -Comment 'Sec Ops Rule for PowerShellGeek.com'

Eliminación de una política/regla de buzón de SecOps

Si ya no es necesaria esta función, también se la puede eliminar al inquilino con dos frases ingeniosas:

Get-SecOpsOverridePolicy | Remove-SecOpsOverridePolicy

Get-SecOpsOverridePolicy | Remove-SecOpsOverridePolicy

Pensamientos finales - Conclusión

Defender para Microsoft 365 tiene muchas partes móviles de las cuales solo exploramos algunas en este artículo. Como todas estas son características nuevas para Defender para Microsoft 365, espere ver más características agregadas con el tiempo. No todas las organizaciones utilizarán estas funciones, ya que algunas organizaciones utilizan el Simulador de ataques de Microsoft y no tienen un proveedor de higiene externo frente a EOP y, por lo tanto, solo pueden usar la función SecOps Mailbox. Mientras que otras organizaciones utilizarán los tres porque tienen un proveedor externo para simulaciones de phishing e higiene del correo electrónico. Como tal, cada una de estas características debe ser evaluada por una organización para determinar sus necesidades y escenarios.