DORA and Netwrix Auditor: logging, detecting and producing evidence

Article 12 requires financial entities to define which events must be logged, how long logs are retained and the measures needed to protect them. The level of detail must match the purpose of the control. DORA requires in particular the logging of events related to logical and physical access control, identity management, change management, ICT system operations and network traffic activities.

Netwrix Auditor can contribute to this requirement on its supported sources. Its change and activity reports cover Active Directory, Microsoft Entra ID, file servers, SharePoint, SQL Server, Windows Server, VMware and various Microsoft environments. A dedicated category also makes it possible to review logon activity.

Take Claire, a legitimate user of a financial application. An IAM policy can explain why she holds an entitlement, but a later control or investigation may require knowing whether she actually logged on, which account made a change, which permission changed or on which resource the action took place. Netwrix Auditor structures its search data precisely around fields such as who performed the action, the object concerned, the resource, the date and, for some environments, the workstation from which the change originated.

The point is therefore not to accumulate logs to demonstrate that they exist, but to hold information that makes it possible to reconstruct an activity when internal control, security or investigation needs it.

Article 23 requires financial entities to put in place a mechanism able to collect, monitor and analyse information, including the logs provided for in Article 12, in order to identify anomalous activities or behaviours. For assets supporting critical or important functions, the text requires in particular tools producing alerts on detected anomalies.

Netwrix Auditor makes it possible to define alerts on specific events. Its alerts can be associated with a risk level and feed the Behavior Anomalies mechanism, which relates certain anomalies to a user and then allows the corresponding activities to be examined.

For Claire, an isolated change may be perfectly normal, whereas a succession of modifications, deletions or other unusual events may justify an investigation. Auditor makes it possible to surface this kind of signal from the events it collects and the rules that are configured.

One limit must nevertheless remain clear: Netwrix Auditor alone does not constitute the complete detection mechanism required by DORA. Article 23 also covers internal and external threats, information from business functions, threat intelligence, notifications from providers and other sources. A SIEM, a SOC, endpoint, network or cloud solutions may therefore remain necessary to achieve the expected coverage.

Netwrix Auditor does not decide who should obtain an entitlement and does not, as a principle, block each action before it is executed. Its main function in this architecture is to provide visibility, investigation, alerts and evidence about the changes and activities of the systems it monitors.

Its contribution to DORA therefore focuses mainly on Article 12, by making some of the audit trails required by the regulation easier to use, and on part of Article 23, by allowing certain anomalous behaviours or events to be detected and investigated.

The exact scope depends on the connected sources and the enabled functions. A complete DORA architecture must therefore start by identifying the events required by the regulation, then check which sources are actually covered by Auditor and which must be collected or analysed by other components, for example on Active Directory attack paths.