Several topics must be addressed when securing Office 365  including the need to be able to track actions to detect illicit behaviour or trace the cause of an incident.

In France, however, many companies have difficulty consolidating logs and defining supervision use cases. Mastering logging must be at the heart of this approach.

Supervision of administrative actions is a necessity

For this logging decryption, let’s take the case of the platform administrators.

As with other SaaS solutions (Google Cloud Platform, Salesforce, etc.), the breach of data integrity or confidentiality following an error or malicious action by a company administrator is one of the major risks identified by our customers.

By definition, Office 365 administrators have high privileges:

• Configuration of the various services – or workloads – and APIs;
• Managing permissions on OneDrive and user mailboxes;
• Management of the life cycle of collaboration spaces.

It is easy to imagine the disastrous consequences that could result from the malicious or uncontrolled use of these privileges. Indeed, settings such as SharePoint Online external sharing, API permissions or email configuration could become significant data leakage vectors.

On-premise IT best-practices (lifecycle, least privilege principle, rights segmentation, strong authentication, just-in-time access, etc.) must also be applied in the Cloud. The Cloud must be mastered and controlled.

However, the implementation of good practices, although necessary, is not enough. Indeed, they do not guarantee that  administrators won’t carry out actions that compromise the level of security. One can therefore naturally wonder how it would be possible to audit the actions carried out and raise alerts if necessary.

What are the means provided by Microsoft? How can we prevent a malicious person from covering his tracks (which would make an attack more difficult to detect and reconstruct)?

To illustrate the different possibilities, we will follow the four examples below:

Figure 1 – Examples of configuration changes that may affect safety

What logs are available?

For historical and technical reasons, Office 365 inherently has several log sources: Unified Audit Logs, Exchange Logs and Azure Logs. These sources are complementary and must be analysed together in order to have an exhaustive view of the administrative actions performed.

Unified Audit Logs: unified logging of the different services

The most commonly cited and used source of logs is the “Unified Audit Logs”. These logs centralise the traces of users and administrators for all the platform’s services: SharePoint Online, Azure AD, Exchange Online, Teams, Power Platforms. Microsoft is progressively integrating the different sources and continues to add new logs.

To come back to our concrete examples, the interesting logs are:

• SharePoint Online External Sharing Policy Change: SharingPolicyChanged
• Assigning rights to a One Drive: SiteCollectionAdminAdded
• Assigning rights to a mailbox: AddMailboxPermission
• Changing an Administration Role: AddMembertoRole

These logs are accessible and exportable via the Compliance and Security Centers, the Office 365 Management and PowerShell APIs (via the Search-UnifiedAuditLog cmdlet). Note that logging must be enabled via the Compliance Center or PowerShell to be able to log and search.

It is possible to directly configure alerts related to the occurrence of certain logs in the Security and Compliance Centers.

Exchange Logs: logging of the messaging infrastructure

The second interesting source of logs is the “Exchange Logs“. These logs provide information about usage and administrative actions performed on the Exchange Online service as well as on personal or shared mailboxes. Two types of logs can be distinguished:

• Administrator Audit Logs: Service or mailbox administration logs (e.g. changing a user’s permissions, changing the retention time of a mailbox log etc.).
• Mailbox Audit Logs: Logs of use of a mailbox by the main user, a delegated user or a service administrator (e.g.: accessing the mailbox, sending an email in place of the main user, moving an item into a folder, permanent deletion, etc.).

To come back to our concrete examples, the logs that will interest us here are:

• Assigning rights to a mailbox: AddMailboxPermission
• Access to a folder or a mailbox: FolderBind (not enabled by default):
• Access to a mail: MailItemAccessed (only for users with an E5 license)

To go further with Administrator Audit Logs

Administrator Audit Logs are generated for any Exchange administration action that can be linked to a PowerShell cmdlet other than Get, Search or Test. These logs are linked to the Unified Logs and can be used in the Exchange Administration Center, Security and Compliance Centers, Office 365 Management and PowerShell APIs.

To go further with Mailbox Audit Logs

Mailbox Audit Logs are the only category of logs to be configurable (perimeter and granularity). These logs allow tracing of the actions performed by an owner, a delegate (user with permissions) and an admin (access via eDiscovery tools).

Since January 2019, the logging of Mailbox Audit Logs is enabled by default for all Office 365 tenants. To date, if logging is enabled by default, all mailboxes are audited (even if the “-AuditDisabled” parameter is set to “True”). The only way not to log the actions of a mailbox is to implement a by-pass rule with “Set-MailboxAuditBypassAssociation”.

However, it should be noted that some actions are not audited by default, such as the access of a delegate or an admin to a user’s mailbox. It is therefore essential to analyse the logs to be activated, during the initial configuration of the service.

Depending on the license level and configuration, these logs can be linked to the Unified Logs and be used in the Exchange Administration Center, the Office 365 Management and PowerShell APIs or the Security and Compliance Centers.

Azure Logs and Reports: Azure Active Directory Logging

The last, but not least important source of logs are the “Azure AD logs”. These logs provide complete traces of the Office 365 identity brick and the associated administration actions. Several categories of logs and reports are available:

• Azure Audit Logs: Logs for the administration of the identification brick or modification of items (e.g. assigning the “SharePoint Administrator” role, creating a security user or group, authorising an API, configuring guest users, etc.).
• Azure Sign-in Logs: Logs for connecting to an Office 365 service (or to applications / APIs based on Azure AD) with information regarding the connection chain (e.g. protocol, IP address, terminal, etc.).
• Risky Sign-in: Connection reports with indicators related to suspicious connections.

These logs and reports are accessible and exportable via the Azure portal, the Graph or Azure Management and PowerShell APIs. Some of the logs directly related to Office 365 are also found in the Unified Audit Logs.

To come back to our concrete examples, the interesting logs are:

• Modification of an administration role: AddMembertoRole

Figure 2 – Summary of Office 365 Logs Features

In summary, the Unified Audit Logs provide a consolidated view of the different services of Office 365, but some information may be missing. It will be necessary to ensure that the required logs are present, and then to investigate further into the logs and reports of Exchange or Azure.

What is the retention period for the various Office 365 logs?

Once the proper logs have been identified, the challenge of retention arises. How can you be sure that the logs are well preserved without being altered, for as long as is required by the company’s security policy and various regulations, such as the anti-terrorist law or the GDPR?

By construction, and contrary to Exchange and SharePoint on-premise solutions, all the logs mentioned above are unalterable – that is to say, they cannot be modified or deleted by the company administrators. Furthermore, the default retention periods defined by default cannot be modified (i.e. 90 days for Office 365 and 7 logs or 30 days for Azure logs with standard licenses). With one exception, an Exchange administrator has the ability to delete the logs from mailboxes by changing the associated retention time.

If we go back to our examples, we could imagine a malicious administrator giving himself rights to access a mailbox, then look at the mails and erase the access logs by setting a zero-retention time. In this case, only the privilege elevation made in the Administrator Audit Logs would be retained.

In order to comply with security or regulatory requirements, it may also be necessary to ensure that the logs of the various departments are kept for more than 7, 30 or 90 days.

3 steps to implement relevant logging within Office 365

1. Definition and activation of the necessary logs: Unified Audit Logs may not be sufficient (monitoring of the Office 365 and Azure AD APIs, logging of administrator access to mailboxes, etc.);
2. Configuration of an automatic export of the identified logs to an external storage or an independent SIEM (via PowerShell or the API Management);
3. Monitoring the status of the tenant: implementing a dashboard of the tenant’s settings configuring alerts related to a change in log configuration (via the Security or Compliance Center, the Office 365 Management or PowerShell APIs), such as disabling Unified logs or a change in the retention of mailbox logs.

Figure 3 – Good Practices for Office 365 Logging

After carrying out these three actions, the company will have the necessary information to audit the tenant’s use and administration actions. However, this does not yet address the larger need for supervision of administrators. It may be useful to set up alerts (via the Security or Compliance Center or specialised third-party tools).

1. (To go further) Implementation of basic supervision: definition of general security detection scenarios, identification of the logs concerned, activation of the associated alert in the Security or Compliance Centers;
2. (To go even further) Setting up advanced supervision: identification of scenarios related to a business context, implementation, definition of the associated governance, continuous improvement.

What tools should be used to analyze the logs? Which detection scenarios should be prioritised? What governance should be put in place to define, implement and monitor alerts? These are all questions that need to be addressed in the implementation of the collaboration platform supervision.

It will also be necessary to take into account the regular changes made by Microsoft on these services, as well as on the structure of logs and APIs, especially since the preview and general availability functionalities coexist.

Cet article Logging of Office 365: a Case Study with Administrators est apparu en premier sur RiskInsight.

However, they are also facing increasingly stringent measures under new regulations such as the General Data Protection Regulation (GDPR), which covers all personal data, or the various new regulations on the protection of critical national infrastructures. France is in the vanguard of this activity with its Military Programming Act which applies to the organizations classed as “most critical” in terms of the country’s functioning.

But how can you put in place increasingly sophisticated detection systems, while, at the same time, complying with an ever-stricter regulatory framework?

SOCs ARE BEING STANDARDIZED AT THE EUROPEAN LEVEL—AND GLOBALLY

In the mid-2000s, the implementation of the first SOCs consisted, for the most part, of deploying log collectors based on geographical hubs and the setting up of a central alert management system. However, recent regulatory changes may require modifications to architecture. In France, in particular, within the context of the Military Programming Act, the requirement to set up a “system of log correlation and analysis” (i.e. a SOC equipped by a SIEM system) has been accompanied by a strict regulatory framework, which is set out in its PDIS (Security Incident Detection Service Providers) Requirements Reference Document.

In terms of standardization, this addresses three points in particular:

• First, the framework for surveillance: there is now an obligation to detect certain types of common attacks and implement controls, following recommendations made through audits carried out by qualified bodies, in accordance with the PASSI (Cybersecurity Audit Service Providers) Reference Document. Companies must also put in place a permanent surveillance unit to notify ANSSI (the French national agency for information system security) in the event of an IS being critically compromised.
• The second area addresses the securing of the SOC’s assets: new security measures described in the PDIS Requirements Reference Document demand, in particular, more robust measures for SOC operators and administrators (two-factor authentication, limitations on internet access, etc.). These security measures will be verified by ANSSI through audits, or retrospectively, following the compromise of an IS being notified to it.

Finally—the architecture—where there’s a requirement for greater complexity: partitioning into trust zones and an enlargement to the perimeter of the monitored network are introduced (going beyond the traditional scope of equipment under security surveillance: business servers and handheld devices must also now be monitored). Information related to security incidents (events, analysis reports, and their associated notifications) must also now be retained for as long as the service is provided.

STRONG SECURITY AND CAREFUL HANDLING OF PERSONAL DATA: INCOMPATIBLE GOALS?

To carry out retrospective analyses and, in particular, to determine the origin of cyber-attacks, a good deal of personal and critical data must be collected, stored, and exploited. However, this data is covered by the GDPR, which tends to limit its collection and use.

Google’s recent fine by the AGPD (Spain’s personal data protection authority) highlights the types of issue that a SOC may encounter regarding the processing of personal data:

• Google’s obligations in the processing of personal data and the user’s right to be forgotten were the prime causes of Google’s penalty. In fact, the GDPR intends to offer European citizens the option to access, modify, or delete their data wherever it is stored (including in the cloud). This means that, in practice, companies must know exactly what data is being collected by their SOC, so that they can inform their customers, employees, etc. accordingly—and offer them the option of having it removed at any time. Having said that, the GDPR seems to indicate that preservation of some data is acceptable, where this is necessary for the protection of companies. The details of exactly how this provision will operate are expected to be worked out over the next few years.
• An obligation of transparency with respect to the exploitation of data is the second issue that the AGPD’s action raises. Yet, for PDISs, the obligation to monitor a wide range of equipment gives rise to the collection of a large and varied amount of data. The content of logs will therefore have to be addressed to ensure that only the data needed for security-monitoring activity is collected.
• Finally, the GDPR imposes a requirement to justify the preservation of the data. Yet, PDIS requirements are for data to be kept for at least six months, in order to have the ability to carry out long-term or retrospective analysis; this creates regulatory uncertainty: how far can a company go in ensuring the protection of its IS?

Looking beyond the example of Spain, it’s instructive to compare the different legislative approaches to the notification of incidents. Those dedicated to the protection of personal data target rapid notification in order to limit the impacts on people’s lives; while legislation concerning the protection of critical infrastructure requires limited and highly confidential notifications in order to allow sufficient time for incidents to be correctly managed, without revealing to an attacker the fact that they have been discovered. In the end, the GDPR took into account this type of scenario, but that’s not to say that other texts won’t result in contradictory obligations.

A STRICT—BUT BENEFICIAL—REGULATORY FRAMEWORK

The tightening of the regulatory framework for SOCs, whether direct (via PDIS requirements) or indirect (through the GDPR), will result in a transformation of the IS ecosystem. New types of profiles could thus be integrated into teams, such as the Data Privacy Officer (DPO), which the SOC could consider as a key player in maintaining its long-term compliance.

In addition, these regulations will raise maturity levels among the players who have to comply with them, as well as among those who draw inspiration from them. Already, there are numerous moves toward compliance involving SOC architecture, as well as its processes and governance.

In complying with the regulations, tools also count—and that means looking at innovations such as data-based surveillance (with Data Leakage Prevention [DLP] tools), which can help ensure compliance with respect to the protection of sensitive data.

TOWARD MORE REALISTIC REGULATIONS…

The value of the requirements for many organizations, both as standards and objectives to be met, cannot be disputed.

While the bar may seem high, and regulatory inconsistencies remain, one thing is for sure: the next round of regulatory updates will provide a solid framework for the design and improvement of SOC.

Cet article The SOC – a department undergoing a full regulatory overhaul est apparu en premier sur RiskInsight.

Beaucoup ont donc entamé au cours des 18 derniers mois un projet visant à exploiter les logs (ou journaux d’évènements) afin d’anticiper, détecter et diagnostiquer des actes malveillants.

L’objectif est ambitieux : on parle d’abord de log management, puis de corrélation des logs à l’aide d’un SIEM (security information and event management) . Quelle réalité derrière ces principes ? Comment les mettre en place ?

Étape 1 : centraliser les journaux

Une grande majorité de machines (équipements réseau, serveurs, postes de travail), bases de données ou applications d’un SI peuvent aujourd’hui générer des logs. Ces fichiers contiennent, pour chaque machine, la liste de tous évènements qui se sont déroulés : réussite ou échec d’une connexion utilisateur, redémarrage, saturation de la mémoire…

Pour les exploiter, il est possible de se connecter unitairement à chacun des équipements afin d’y observer l’historique. Cette tâche fastidieuse, encore souvent observée sur le terrain, est irréaliste sur des systèmes d’information complexes. Elle est par ailleurs inefficace pour prévenir un incident ou détecter les impacts en temps réel.

La construction d’un « puits de log » est une première brique de réponse : il s’agit de collecter, à l’aide d’un outil automatisé du marché, l’ensemble des journaux d’équipements dans un espace de stockage unique. L’un des critères de sélection de cet outil est justement sa capacité à reconnaître différents formats de logs (syslog, traps SNMP, formats propriétaires…).

Le volume d’information centralisée peut vite exploser : il est important d’éviter la collecte de données inutiles. Par ailleurs, le système peut également être gourmand en puissance de calcul en fonction des périmètres de recherches effectuées.

On parle de log management à partir du moment où les données contenues dans ce puits sont traitées et exploitées, par exemple pour retrouver un élément dangereux (virus, problème de sécurité…), ou un comportement malveillant (fuite d’information, suppression de données…). Il est nécessaire de cadrer en amont les finalités du projet,  qui peuvent être multiples :

• Vérifier que les règles du SI sont appliquées
• Détecter les attaques ou les utilisations frauduleuses du SI
• Permettre les analyses post-incidents (forensics)
• Répondre aux contraintes légales ou de conformité avec la capacité de fournir des éléments de preuve

Pour démarrer, une bonne pratique consiste à s’orienter principalement vers des logs de sécurité et réseau. Certaines applications métiers sensibles pourront ensuite être ajoutées.

Une fois l’espace de stockage cadré, l’archivage amène son lot de contraintes :

• D’un point de vue légal et réglementaire, il faut s’assurer de la licéité des traitements en fonction des informations archivées et de leurs durées de rétention. Une déclaration à la CNIL est à prévoir dans de nombreux cas.  En fonction de leur origine (e-mail, proxy, applications), les périodes de rétention ne sont pas soumises aux mêmes règles. À titre d’exemple, on considère aujourd’hui qu’une durée raisonnable pour l’historique des accès des utilisateurs à internet est de 12 mois.
• En fonction des traitements et du cadre juridique existant dans l’entreprise (par exemple charte incluant la surveillance…), les collaborateurs doivent potentiellement être informés des mesures mises en place. Dans ce cadre la mobilisation des ressources humaines et des instances représentatives du personnel sont à prévoir.
• La gestion des identités et des accès au puits de logs  est, enfin, un sujet crucial. Le volume et la sensibilité des informations qui y sont stockées nécessite d’identifier précisément les personnes habilitées à en faire usage, et de limiter strictement leurs droits au périmètre qui leur incombe. Toute modification des traces doit être interdite (même aux administrateurs),  afin que celles-ci puissent avoir une valeur probante le cas échéant.

Étape 2 : faciliter l’analyse, du SIEM au Big Data

Si des recherches manuelles sont toujours possibles dans un puits de logs, elles ne répondent qu’à un besoin précis et ponctuel.

Pour obtenir une analyse en temps réel avec des remontées d’alertes automatiques, il est nécessaire de passer à l’étape supérieure : le SIEM. Il s’agit à la fois d’une extension et d’une industrialisation de la première étape, souvent offerte par le même outil du marché.

Il s’agit ici de rechercher, à travers les traces, des liens entre des évènements unitaires ayant lieu sur différents éléments du SI, afin d’anticiper, bloquer (en temps réel) ou comprendre une action malveillante.  On parle alors de corrélation de logs.

Pour cela, il est important de définir les types de comportement anormaux à identifier. C’est la principale difficulté : un niveau de sensibilité trop élevé génèrera beaucoup d’alertes sans intérêt, tandis qu’un niveau trop faible ne permettra pas de lever les alertes pertinentes. Cette étape comporte donc une phase d’ajustement et apprentissage qui peut durer plusieurs mois.

Aujourd’hui le marché des SIEM se renouvelle : les solutions sont de plus en plus performantes, utilisent de nouvelles techniques de détection d’attaque, et exploitent de plus en plus la puissance de calcul du Cloud pour la corrélation d’évènements.

Le marché voit également arriver des outils utilisant les principes du Big Data. Plutôt que de rechercher des scénarios connus, l’idée est alors de détecter des anomalies statistiques dans la masse d’information. Cette approche séduisante doit encore être mise à l’épreuve du terrain.

 Ne pas négliger les aspects organisationnels

Enfin, il est nécessaire de s’assurer que les alertes seront traitées par les équipes compétentes. Les procédures et l’organisation associées doivent donc embarquer les équipes sécurité (SOC/CERT), réseau et système et le RSSI. Des réflexions autour de l’externalisation ou de l’internalisation de ces fonctions de surveillance et des liens avec les entités en charge de la gestion des incidents de sécurité sont également essentielles.

Cet article Surveillance sécurité : passer du puits de logs au SIEM (security information and event management) est apparu en premier sur RiskInsight.