Blog do Chesley

Erros de segurança comuns do Microsoft 365

O Exchange Online Protection (EOP) é parte integrante de todos os níveis de licenciamento do Exchange Online, enquanto o Microsoft Defender for Office 365 (MDO) oferece recursos adicionais de segurança para licenças como Business Premium, Microsoft 365 E3 e Microsoft 365 E5.

No contexto deste blog, pretendo destacar cinco dos erros de segurança mais comuns observados em implantações do EOP e MDO. Embora existam numerosos equívocos a serem abordados, minha abordagem se concentrará em questões que podem ser prontamente corrigidas para obter resultados rápidos ou talvez até mesmo ignoradas por você, administrador do ambiente, até o momento.

Embora o cenário tecnológico esteja sempre evoluindo, o e-mail permanece como um campo crítico para defensores de segurança. Para ilustrar, a Abnormal relata  um aumento alarmante de 108% no comprometimento de e-mails comerciais (BEC) ano após ano. Portanto, é crucial minimizar os erros em seu ambiente, a fim de reduzir ao máximo a superfície de ataque, ao mesmo tempo em que simplifica a experiência dos usuários.

1. Erros de segurança comuns do Microsoft 365
2. As exclusões não são refinadas
3. Os domínios não utilizados não são protegidos pela autenticação DNS
4. Permitindo que os usuários finais controlem os desvios antispam
5. A entrega dinâmica de Anexos seguros pode causar problemas ao usuário final
6. Tratando a segurança de e-mail como se todos fossem iguais
7. Conclusões

As exclusões não são refinadas

Existem diversas abordagens para criar exclusões destinadas à filtragem de e-mails de entrada, que incluem regras de fluxo de e-mail, políticas antisspam, TABL (Tenant Allow/Block List), políticas de filtro de conexão, entre outras. Geralmente, as exclusões permitem que determinados endereços de e-mail ou domínios sejam isentos do processo de filtragem de spam.

No Exchange Online Protection (EOP), os e-mails de entrada recebem um Nível de Confiança de Spam (SCL), o qual é atribuído como um cabeçalho ao e-mail. Os valores do SCL variam de 5 a 9 e indicam diferentes níveis de confiança em relação ao spam, com base em fatores como falhas de autenticação DNS e padrões de spam conhecidos. Como administrador, ao configurar uma política de ignorar spam, é possível definir o SCL como -1 (negativo um), o que resultará na exclusão de quaisquer regras de spam.

É importante reconhecer que exclusões são uma parte essencial dos softwares de segurança. Embora falsos positivos ocorram (frequentemente devido a configurações incorretas do remetente, como SPF/DKIM mal configurados), é crucial evitar exclusões excessivamente amplas e simplistas.

Por exemplo, na política antisspam padrão (Política de entrada antisspam (Padrão)), é comum encontrar listados domínios genéricos, como o domínio da própria empresa, domínios de parceiros comerciais e domínios de serviços de e-mail populares, como outlook.com e gmail.com.

Dessa forma, é essencial equilibrar a eficácia da filtragem de spam com a minimização de falsos positivos, garantindo que as exclusões sejam criteriosamente definidas para otimizar a segurança do ambiente de e-mail.

Se a política padrão for sua única política ou se você estiver aplicando o mesmo tipo de exclusão a outra política de amplo alcance, correrá o risco de um adversário ignorar completamente os controles que, de outra forma, os protegeriam. O invasor pode provisionar a infraestrutura de envio de email, usar o domínio listado de permissões e enviar emails de phishing ou outras ameaças. (Observação importante: você não pode ignorar determinações de malware, mesmo definindo SCL -1).

O mesmo acontece com a política de filtro de conexão, que é uma das primeiras verificações de entrada que o e-mail tem com base em listas de permissão/bloqueio de IP. Só porque você confia no IP agora não significa que você sempre pode confiar nele. Este é particularmente o caso das partes externas. Só não faça isso: encontre a causa raiz e enfrente isso.

Vamos supor que um domínio esteja sempre falhando nas verificações antisspam. Aqui estão algumas reflexões sobre a melhor maneira de criar exclusões de uma forma que possa reduzir o risco.

• Use endereços de e-mail específicos e completos em vez de domínios inteiros, se possível.
• Use regras de fluxo de mensagens que também confirmem marcadores conhecidos. Por exemplo, defina o SCL como -1 para um domínio específico quando SPF/DMARC/DKIM passar e/ou se de um IP conhecido.

• A lista de permissões/bloqueios do locatário força a infraestrutura de envio correspondente para remetentes falsificados, mas não exatamente no mesmo nível das regras de fluxo de mensagens. Eu uso o TABL reativamente e as regras de fluxo de e-mail proativamente como uma ferramenta de longo prazo.
• Verifique em toda a sua infraestrutura (todas as políticas antimalware/spam/phishing, TABL, regras de fluxo de e-mail, filtro de conexão) exclusões históricas que podem não ser mais necessárias.

Os domínios não utilizados não são protegidos pela autenticação DNS

Se você possui domínios em sua posse, mesmo que não haja envio ativo de e-mails por meio deles, é crucial implementar a autenticação DNS para comunicar aos destinatários que nenhum e-mail recebido desses domínios é legítimo e deve ser considerado como spam. É comum encontrar empresas que detêm domínios e até mesmo os registram no Microsoft 365, porém não estabelecem nenhum controle efetivo sobre eles.

No contexto do Sender Policy Framework (SPF), é recomendável criar um registro que explicitamente negue a confiança em qualquer servidor de envio, indicando que nenhum servidor está autorizado a enviar e-mails em nome desse domínio. Isso é alcançado por meio da configuração de uma política de “Fail” ou “SoftFail” no registro SPF do domínio, especificando que nenhum servidor é considerado autorizado para enviar e-mails em nome desse domínio.

Essa medida não apenas ajuda a proteger a reputação de seu domínio ao evitar que ele seja associado a atividades de spam, mas também auxilia os destinatários na identificação de e-mails legítimos, uma vez que qualquer mensagem recebida de tais domínios será automaticamente considerada suspeita e tratada adequadamente. Além disso, isso reforça a segurança do ecossistema de e-mails, impedindo potenciais ataques de spoofing ou phishing que possam explorar domínios sem proteção adequada.

Portanto, ao estacionar domínios ou mantê-los sem atividade de envio de e-mails, a configuração cuidadosa da autenticação DNS, especialmente do SPF, é essencial para garantir a integridade do seu domínio e proteger a reputação da sua marca online.

v=spf1 -all

Para o DMARC, defina o recorde para rejeitar todas (100%) das falhas. Este é o padrão, mas eu gosto que ele explicitamente definido para visibilidade:

v=DMARC1; p=reject; pct=100;

Permitindo que os usuários finais controlem os desvios antispam

O Exchange Online Protection (EOP) adota o conceito de uma coleção de listas seguras, que é prontamente habilitada. Essa funcionalidade permite que os usuários controlem suas próprias configurações de filtro de spam, em linha com as práticas de outros provedores de e-mail. A gestão da coleção de listas seguras é análoga à experiência que os usuários têm ao clicar com o botão direito em um e-mail no Outlook e ajustar as opções de lixo eletrônico.

No exemplo fornecido, é demonstrado que a coleção de listas seguras permite que um usuário defina uma exceção antispam para todo o domínio gmail.com. Embora isso possa facilitar as tarefas dos usuários, é importante observar que, por padrão, a coleção de listas seguras permite que os usuários ignorem as regras estabelecidas pelo administrador de segurança. Isso resulta na aplicação da regra SCL -1 para os endereços de e-mail definidos pelos usuários, em vez das definições determinadas pelo administrador.

Como administrador, você pode gerenciar a coleção de listas seguras por caixa de correio usando o cmdlet Set-MailboxJunkEmailConfiguration no PowerShell. Isso permite editar as configurações da coleção de listas seguras para uma caixa de correio específica ou desabilitá-la completamente (usando -Enabled $false). É importante notar que não é possível desabilitar a coleção de listas seguras para todo o locatário. Portanto, é recomendável implementar um script recorrente do PowerShell para verificar e ajustar as configurações da coleção de listas seguras em todas as caixas de correio, especialmente para novas caixas ou edições.

A entrega dinâmica de Anexos seguros pode causar problemas ao usuário final

O Defender para Office 365 Plano 1 desbloqueia o recurso Anexos Seguros. Isso usa um ambiente de área restrita para anexos de e-mail para “detoná-los” e revisar as consequências dessa detonação na área restrita. Se não houver nada suspeito, é entregue.

Isso adiciona uma pequena sobrecarga à entrega de e-mails de entrada, crescendo à medida que o tamanho do anexo aumenta.

Para mitigar as preocupações que os administradores possam ter sobre a lentidão da entrega de emails, a Microsoft fornece a ação Entrega Dinâmica. Para caixas de correio do Exchange Online, isso permite que a mensagem de email seja entregue normalmente, mas o anexo só tem uma versão de visualização, com a versão completa posteriormente ‘injetada’ no email.

Não recomendo o uso do Dynamic Delivery. Em vez disso, fique com o modo Bloquear. Uma das razões pelas quais não recomendo é a experiência do usuário final. Vamos pegar o exemplo de um arquivo de entrada do Excel que obtém a versão de visualização anexada. O destinatário encaminha muito rapidamente o e-mail para outra pessoa. O destinatário do e-mail encaminhado não receberá o arquivo completo, apenas o espaço reservado temporário. Entenderam?

Tratando a segurança de e-mail como se todos fossem iguais

O último erro comum a ser discutido é a uniformidade excessiva encontrada em muitos grandes inquilinos que são examinados. Embora a simplificação da arquitetura de segurança seja uma prática recomendada, é importante reconhecer que a simplicidade tem limites. O Exchange Online Protection (EOP) e o Microsoft Defender for Office 365 (MDO) oferecem uma flexibilidade significativa, permitindo que diferentes níveis de proteção, exclusões e desvios sejam direcionados para diferentes usuários, com base no risco e nas necessidades de negócios. Essa capacidade é fundamental em ambientes de grande escala.

Vamos ilustrar essa questão com alguns exemplos:

– Se uma organização possui um domínio de uma empresa parceira que necessita ser sempre ignorado pelas políticas antispam, essa exceção precisa ser aplicada a todo o locatário? Uma prática recomendada é utilizar as condições de fluxo de mensagens para restringir essas políticas apenas aos destinatários que se comunicam com esse domínio específico. Isso evita a aplicação desnecessária da exceção a toda a organização.

– Se a organização deseja restringir a capacidade dos usuários de gerenciar sua própria coleção de listas seguras, é necessário aplicar essa restrição a toda a organização? Dependendo da escala e de outros fatores, essa abordagem pode sobrecarregar desnecessariamente a equipe de TI central. Uma alternativa a ser considerada é permitir que os usuários que demonstram competência em treinamentos de simulação de ataques tenham permissão para gerenciar suas próprias listas seguras, mas não as de outros usuários.

– Embora uma organização possa optar por utilizar a política de proteção padrão predefinida como uma linha de base para todo o locatário, isso não significa que todos os usuários precisam ser tratados de maneira uniforme. Existem usuários de maior risco, como executivos e usuários privilegiados, que possuem acesso a informações confidenciais. Nesses casos, é aconselhável direcionar políticas de proteção mais rigorosas para esses usuários, enquanto os usuários de menor risco podem receber um nível menor de proteção.

Essas práticas refletem a importância de uma abordagem flexível e adaptável à segurança de e-mails em uma organização Microsoft 365. Ao personalizar as políticas de segurança com base nas necessidades e nos perfis de risco dos usuários, é possível otimizar a eficácia da proteção enquanto minimiza a sobrecarga operacional e oferece uma resposta mais ágil às ameaças emergentes.

Fontes confiáveis: Documentação oficial da Microsoft sobre Exchange Online Protection e Microsoft Defender for Office 365, boas práticas de segurança cibernética recomendadas por organizações como o National Institute of Standards and Technology (NIST) e o Center for Internet Security (CIS).

Conclusões

Em conclusão, é fundamental direcionar e refinar as políticas de segurança de forma a minimizar qualquer fator que aumente a superfície de ataque, ao mesmo tempo em que se maximiza qualquer medida que reduza essa superfície. Não se deve simplesmente aceitar os padrões existentes, como as coleções de listas seguras mencionadas anteriormente. É essencial direcionar as políticas de proteção padrão ou rigorosas de acordo com o perfil de risco de cada usuário.

Para mais informações sobre boas práticas de segurança cibernética e como otimizar a proteção de e-mails em ambientes Microsoft 365, recomendo a consulta à documentação oficial da Microsoft sobre Exchange Online Protection (EOP) e Microsoft Defender for Office 365. Além disso, organizações como o National Institute of Standards and Technology (NIST) e o Center for Internet Security (CIS) oferecem valiosos recursos e diretrizes para fortalecer a segurança cibernética em organizações.