1. Ligar o “multi-factor authentication” (MFA) para todos os utilizadores e Global Admins (com excepção das contas de emergência) se já não precisa de continuar a usar aplicações Legacy que ainda usam o “SMTP Authentication Protocol”.

3. Não permita que os utilizadores criem “app passwords”. Estas passwords são usadas por aplicações que não suportam a “modern authentication” e que são, consequentemente, menos seguras. A opção, na falta destas aplicações, não deve estar ligada

4. Desabilitar, no MFA, os métodos de verificação por chamada e SMS. Estes métodos são menos seguros e o uso da aplicação móvel é preferível.

5. Colocar a opção para pedir a revalidação da identidade em 90 dias. Esta redução vai reduzir as possibilidades de os utilizadores aprovarem acessos indesejáveis por MFA e impedir o conhecido método de “MFA bombing”.

6. Ligar o MFA para todos os utilizadores baseado nas políticas de conditional access. Ter em conta que isto requer um “Azure Premium Plan 1”.

7. Criar duas contas de Domain Admin de emergência. Estas contas devem estar excluídas da autenticação MFA e de outras políticas de acesso condicional. Estas contas irão impedir que fiquemos excluídos do acesso à Azure Active Directory por exemplo se houver um problema grave e duradouro na rede telefónica ou nos telefones assim como uma saída ou desaparecimento súbito de um Domain Admin.

8. Usar o “Role-based access control” para admins com base no “principle of least privilege” (POLP). As contas de utilizadores devem ter sempre as permissões mínimas necessárias para realizarem as suas funções.

9. As contas de serviço que apenas precisam de ler a Azure Active Directory devem usar apenas o role de “Directory Role”.

10. Embora o “mailbox audit log” esteja sempre ligado deve também ser ligado o “Unified Audit Log”. Isto permitirá recolher todos os logs no Microsoft 365 Compliance Center o que facilitará a consulta de eventos de segurança permitindo criar aqui alertas.

11. Criar alertas quanto uma Team de MS Teams é apagada uma vez que o apagamento de uma Team irá também levar ao apagamento do site Sharepoint e de todos os dados aqui associados.

12. Ligar o “Enable Continuous Access Evaluation”. No Office 365 a autenticação baseia-se em OAuth 2.0 access tokens, são estas tokens que permitem o acesso a serviços e estão – por defeito – válidos durante uma hora refrescando depois de forma automática. Contudo, se algo mudar no perfil de acesso do utilizador durante essa hora esta mudança não é validade. Isto implica por exemplo que uma mudança de geografia não é validade e será permitida designadamente se um hacker obtiver a password de acesso poderá estar ativo na conta durante quase 60 minutos. Se a “Continuous Access Evaluation” (CAE) for ligada essa validação será quase imediata a até um tempo máximo de 15 minutos. De notar que esta configuração também exige um plano Azure Premium P1, pelo menos.

13. Ligar o “Azure Portal Inactivity Timeout” para todos os utilizadores.

14. Ligar as “Preset Security Policies in Exchange Online” tendo em conta que a Microsoft disponibilizou dois templates, um padrão e outro mais restritivo.

15. Verifique as configurações do “Configuration Analyzer” e ligue algumas que, por defeito, não estão ligadas, tais como “High-confidence spam detection action”, “Phishing email detection action”, “Bulk email threshold”, “Quarantine retention period”, “Enable end-user spam notifications” e o “Common Attachment Types Filter”.

16. Ligue o “External Email Tagging” para destacar num texto todos os mails com origem externa por forma a aumentar percepção de risco por parte dos utilizadores. Isto vai reduzir a possibilidade de um mail externo que se faz passar por interno conseguir levar a bom porto os seus fins maléficos.

17. Bloquear todos os “Basic Authentication Protocols” que permitem ligações ao Exchange Online sem “Modern Authentication”. Se estes estiverem activos basta a um hacker conhecer o username password (e há milhões de pares de credenciais na darkweb) para entrar numa conta de exchange.

18. Bloquear tipos específicos de ficheiros no SharePoint e nos clientes OneDrive dos utilizadores. Embora extensões como .ini e .tmp já estejam excluídas outras, por razões de segurança, podem e devem ser excluídas. Por exemplo, a adição de extensões usadas por ransomware pode servir para bloquear a disseminação de um ataque de encriptação de ficheiros. É o caso, por exemplo, de “.micro” (TeslaCrypt 3.0), .ezz (Alpha Crypt), .zzzzz (Locky), .MERRY (Merry X-Mas) entre muitas outras. Pode também ser úitil bloquear o upload de ficheiros .PST como forma de impedir a exfiltração de dados ou o rápido preenchimento do espaço disponível no tenant de Office 365.

19. Permitir que apenas computadores de Domain possam usar o OneDrive ou pastas SharePoint. Isto vai impedir que utilizadores trabalhando a partir de casa em computadores sem antivirus ou com baixa segurança possam ser um risco de segurança.

20. Bloquear o acesso às credenciais de shared mailboxes. Estes utilizadores não têm licenças mas podem ser usados para logins precisando para tal apenas do conhecimento da password. Se este acesso não é necessário (e raramente o deverá ser) deve ser desligado.

21. Bloquear o “Auto-forwarding” para domínios externos irá impedir um dos comportamentos mais frequentes quando alguém obtém controlo de uma mailbox Office 365 que é o de enviar todo o correio para uma conta externa. Esta opção dificilmente terá justificações de serviço e deve ser desligada.

22. Bloquear o “User Consent” a aplicações já que este método tem sido usado de forma crescente por hackers os quais, em vez de captarem passwords, tentam agora enganar os utilizadores a darem-lhes permissões às aplicações maliciosas criadas por eles.

23. Bloquear o acesso dos utilizadores ao “Azure Portal”: por defeito todos os utilizadores têm esta capacidade ainda que apenas na qualidade de leitura mas a esmagadora maioria dos utilizadores não carece desta permissões e esta deve ser-lhes retirada.

24. No teams devem ser desligadas as opções em que
a. os utilizadores podem convidar utilizadores de Guest podem convidar outros Guests a colaborarem num documento partilhado.
b. Os utilizadores anónimos podem juntar-se a uma reunião que está ligada por default.
c. Bloquear “Third-party Apps” já que, por defeito, os utilizadores as podem adicionar e uma vez que cedem dados ao exterior isso pode ser um risco de segurança. Será mais seguro aprovar previamente essas aplicações.

25. Limitar o “External Sharing” em SharePoint que pode ser muito prático mas que permite enviar para fora da organização ficheiros que nunca devem sair da mesma.

26. Há organizações que estão a remover ou a reduzir as “password policies” e, de facto, há estudos que indicam que mudanças frequentes de passwords e passwords complexas fazem menos pela cibersegurança do que o que se pensava sobretudo se for usado o MFA e políticas de acesso condicional.

27. Ligar a notificação por cada mudança de password para o utilizador e para as contas de Domain Admin do tenant Office 365.

28. Usar o “Corporate branding” na página de login o que irá permitir que os utilizadores detectem rapidamente quando a página de login é uma página falsa criada para uma campanha de phishing.

29. O mail domain tem SPF, DKIM e DMARC?
Essas condições podem ser testadas no https://mxtoolbox.com, no https://easydmarc.com/tools/dkim-lookup e no https://dmarcian.com/dmarc-inspector/ sendo que no caso do tenant Office 365 da lisboa2023.org tudo parece estar em ordem. Contudo, muitas organizações que usam Office 365 não utilizam todas estas protecções contra ataques ao mail domain especialmente no que concerne ao DKIM.

É importante seguir estas indicações (e outras) para proteger um tenant Office 365. Sabemos que esta plataforma é um alvo muito apelativo para os criminosos e no caso do site da JMJ e no contexto da guerra na Ucrânia e dos ataques recentes a sua protecção é ainda mais importante. No caso da JMJ é essencial proteger os dados contra ameaças como phishing, malware, ransomware e vários tipos de ataques por engenharia social. Entre os dados ameaçados estão dados pessoais e/ou confidenciais, financeiros ou de outro tipo. Por forma a prevenir a perda de dados em ataques é preciso criar e manter políticas de backup e recuperação de dados que, por defeito, não existem nas subscrições de Office 365 e garantir a continuidade da operação, minimizando o risco de tempo de inatividade não planeado.