Which central log platform does Essential Eight Maturity Level 2 require?
Maturity Level 2 does not name a product. It requires that specific event types are sent to a central location, that the logs are protected, and that they are analyzed in a timely way. Any platform that passes those tests can be used, whether it is commercial, open source or built in-house. The starting point is therefore the control requirements, not a tool list. The controls that carry the logging weight are ISM-1660, which covers central logging of application control events, ISM-1815, which requires event logs to be protected from unauthorized modification and deletion, and ISM-1906, which covers timely analysis of event logs from internet-facing servers. Confirm the full set of event types for your target level in the ISM Essential Eight profile before you select anything.
The organization owns the logging decision and the evidence. Your leadership chooses the platform, sets retention and access rules, and accepts the residual risk. An implementation partner can install and configure the platform in your environment, write the runbooks, and document how each control is met, including where the protection and alerting settings live. The partner prepares that evidence but does not decide whether it is sufficient. Only an independent assessor judges maturity. The Essential Eight is a set of mitigations rather than a certification scheme, so there is no ASD certificate to obtain. Ask any provider to show, in writing, which evidence they will hand over and which parts remain your responsibility.
Test the candidate platform against the controls before you buy or build. For each candidate, ask whether it can receive the required event sources, whether administrators can alter or delete stored events without leaving a trace, whether alerting on internet-facing server logs can be configured, and how long events are kept. Confirm licensing and edition limits for each feature with the vendor, since some protection or audit features may sit in paid tiers or may be disabled by default. Run a short trial that sends real events through the pipeline and check that the assessor-facing evidence, such as configuration exports and sample alerts, can be produced on demand.
Which events must reach the central platform at ML2?
Maturity Level 2 moves several event sources from local storage into a central platform, so an assessor can see them in one place. The cards below cover each source ML2 adds, what it shows, and where it originates. Confirm the exact event scope for your target level against the ISM OSCAL ML2 profile before you configure forwarding.
Application control events
ML2 requires central logging of allowed and blocked application control events, which is the evidence that your approved-execution rules are working. An assessor will look for blocked attempts and the rule or policy that stopped them. On Windows, these events come from the WDAC or AppLocker operational logs, and the central platform must receive them with the host name and user. Check that both allowed and blocked events are forwarded, since the control is weak if you only see blocks.
PowerShell execution events
PowerShell logging shows scripts that ran, including script block content, on workstations and servers. An assessor uses these events to check whether script-based attacks would be visible and reviewable. On Windows, Script Block Logging and module logging write to the PowerShell operational log, so the forwarder must collect that channel and not only the classic Windows logs. Confirm which PowerShell logging settings the ML2 profile requires for your fleet.
Command line process events
Command line auditing records the full arguments of processes as they start, which lets an assessor reconstruct what an administrator or attacker actually ran. On Windows this depends on process creation auditing (Event ID 4688) with command line capture enabled. On Linux, the equivalent comes from auditd execve records or a similar process audit source. Check that the platform retains the full command line field, because truncated arguments can hide the evidence the control is meant to produce.
Privileged access events
Events for privileged access show when administrator rights were granted, used and changed, and they are central to the restrict administrative privileges strategy. Assessors look for logons to privileged groups, changes to group membership, and use of elevated tokens. On Windows, these come from the Security log, and on Linux from sudo and authentication logs. Confirm that privileged accounts, including those on servers and network devices, send their events to the central platform and are not only logged locally.
Multi-factor authentication events
MFA events show whether a second factor was required and whether it succeeded, failed or was bypassed. An assessor compares these against the systems that the MFA strategy says must be protected. Sources include your identity provider, VPN and remote access gateways, and privileged access tools. Check that failed attempts and enrolment changes are forwarded, because a log that only records successful sign-ins gives the assessor no evidence of enforcement.
Incident reporting inputs
ML2 expects detected cyber security events to reach people who can report them to the CISO and to ASD. The central platform is the usual place where alerts from the sources above are triaged, so it must produce records that an incident response plan can act on. Document which alerts escalate, who receives them, and how the timeline is preserved. Confirm the reporting obligations and timings with your CISO and the ISM text, since they go beyond the logging itself.
How do you protect event logs from modification and deletion?
ISM-1815 expects that event logs cannot be modified or deleted by ordinary administrators, so the platform must make tampering difficult even for the people who run it. The practical design separates three things: the log sources (endpoints, servers, applications and identity systems), the collector or forwarder that ships events off each source, and the storage tier where events are kept. A compromised workstation or a privileged user on a server should not be able to reach the storage tier and rewrite its own history. In a self-hosted design, that usually means the collector writes to storage over a one-way path, the storage tier accepts writes from collectors and grants read access to analysts, and deletion rights sit with a small, separately controlled role. Confirm in writing which accounts can delete indices or alter retention, and who approves that change.
Write-once or restricted-delete storage is the control that makes the separation hold. In OpenSearch, index state management policies can make an index read-only and delete it after a set number of days, so retention is enforced by policy rather than by hand. Set the delete step to a retention period your obligations justify, and keep the policy under change control. The same logic applies to Graylog, where retention deletes the oldest indices. Snapshots to a repository that the log administrators cannot overwrite add a second copy. Verify this by attempting a delete with an ordinary administrator account and recording the refusal. Do not assume an index is protected because a policy exists.
Integrity evidence is what an assessor will ask to see. Start by confirming that OpenSearch Security plugin audit logging is enabled, because it records authentication successes and failures, permission grants and denials and index changes, and it is disabled by default. It must be configured in opensearch.yml and audit.yml, so check both files in the deployed cluster rather than the documentation. Then keep the audit trail itself in a location the audited administrators cannot change. Evidence for an assessment typically includes the configuration files, a sample of audit events showing a blocked or attempted change, the retention policy, and the role assignments that show who can delete. Your platform vendor or implementation partner can prepare that evidence, but only the independent assessor decides whether it is sufficient.
How do Wazuh, OpenSearch and Graylog compare on licensing and retention?
Wazuh is licensed under GPL-2.0-only, and its agent is the piece most organizations deploy first. The agent collects system and application logs from monitored endpoints and forwards them to the Wazuh server, which can also receive logs over syslog or through third-party API integrations. The server then analyzes each event in pre-decoding, decoding and rule matching stages.
- Agent collection: The agent gathers logs from endpoints and forwards them to the server, covering the event sources ML2 names such as application control, PowerShell, command line and privileged access events.
- Decoding and rules: Each event is decoded and compared against a ruleset of over 3,000 built-in rules and decoders, plus any custom rules you write.
- MITRE ATT&CK mapping: Matching alerts are mapped to MITRE ATT&CK, which helps analysts group detections by adversary technique.
- Alert output: Alerts are written to alerts.log and alerts.json, and forwarded to the Wazuh indexer for review in the dashboard.
- Retention: Retention of the indexed data depends on how the indexer is configured, so confirm the storage and retention settings for your deployment.
Confirm with Wazuh which features are included in the current release and whether any support terms apply to your deployment. Check that the events ML2 requires are covered by a decoder and rule in your environment.
OpenSearch is licensed under Apache-2.0 and is commonly used as the storage and search layer behind a logging pipeline. Its Index State Management plugin applies policies that act on an index based on its age, size or document count. This is the feature that most directly controls how long logs are kept and how they are protected from later change.
- Rollover: A policy can roll an active index over into a new one once it reaches an age, size or document count you set.
- Read-only: A policy can make an index read-only after rollover, which supports the ML2 requirement that event logs are protected from unauthorised modification.
- Snapshot: A policy can take a snapshot of an index so a copy exists outside the live index.
- Deletion after a set number of days: A policy can delete an index after a number of days you define, which sets the retention period.
- Audit logging: Security plugin audit logging records authentication, permission and index change events, but it is disabled by default and must be configured in opensearch.yml and audit.yml.
Confirm the retention period your policy must meet, and confirm with the OpenSearch project or your distributor which security features you need for your version.
Graylog Open is licensed under the Server Side Public License version 1 (SSPL-1.0). It is not an OSI-approved open source license. Starting with Graylog 4.0 (2020), Graylog Open moved from GPL v3 to SSPL, and earlier releases remain under GPL v3. SSPL section 13 requires anyone who offers Graylog as a public service to release their service stack under the SSPL, which matters if you plan to provide logging to third parties.
- Inputs and routing: Graylog ingests logs over inputs such as syslog, GELF and Beats, then routes and filters them in real time through streams and processing pipelines.
- Rotation and retention: Index rotation can be set by message count, size or time, and retention deletes the oldest indices.
- Search and dashboards: Search supports time range filtering, and dashboards help analysts review events.
- Paid editions: Graylog Enterprise and Graylog Security are paid editions, so features you need beyond Open may carry a license cost.
- Legal review: Have counsel review SSPL obligations before offering Graylog as a service to others.
Confirm the current Graylog Open feature set, edition limits and support terms with Graylog before you select it for ML2 evidence.
What does timely analysis of internet-facing server logs look like?
The sequence turns raw events from internet-facing servers into alerts that someone reviews within a response time the organization has set and written down, so that suspicious activity is noticed while it can still be contained.
Identify the internet-facing servers in scope
The organization, usually with its security and platform teams, lists every server that accepts traffic from the internet, including reverse proxies, VPN concentrators, web and API hosts, and their supporting services. This list defines which log sources the ISM-1906 expectation applies to. Done means the list is approved, versioned and tied to the asset inventory, so an assessor can see that no internet-facing server is missing from the analysis scope.
Ingest server logs into the central platform
Agents, syslog forwarders or API integrations send system, web server, authentication and security events from each in-scope server to the central platform. In a self-hosted deployment, the team configuration and log shipping are often handled by the implementation partner, while the organization owns the decision about which event sources count. Done means every in-scope server appears as a reporting source and events arrive with reliable timestamps.
Decode events into structured fields
The platform parses each raw message into named fields such as source address, user, process, request path and outcome. Wazuh, for example, runs pre-decoding and decoding stages before rules are applied, and Graylog uses extractors and pipeline rules for the same purpose. Done means a sample of events from each source shows the expected fields populated, because unparsed events cannot be matched by rules.
Match events against detection rules
Each decoded event is compared with detection rules that cover the activity the organization cares about, such as repeated authentication failures, unexpected administrative actions and web requests that match known exploitation patterns. Built-in rulesets are a starting point and need tuning to the environment. Done means the team can show which rules are enabled for each server class, who approved them, and when they were last reviewed.
Generate and route alerts to responders
Matching events create alerts that are stored, tagged with the affected asset, and sent to the people who triage them through a dashboard, ticketing queue or notification channel. Routing rules should reflect who must respond and who must be informed about incidents under the CISO and ASD reporting expectations. Done means a test event produces an alert that reaches the named queue without manual intervention.
Triage alerts within the organization's response time
An analyst reviews each alert, classifies it as benign, suspicious or a cyber security incident, and records the decision with the time it was made. The response time is set by the organization, not by ASD, and must be written into the logging or incident procedure. Done means each alert has an outcome, the elapsed time from alert to outcome is recorded, and any missed target is escalated and explained.
Document the timeliness target and review it
The organization records its timeliness target, the scope of servers covered, the alert severities that trigger escalation, and the roles responsible for each step. The document is reviewed on a schedule the organization sets and after significant changes to the estate. Done means an assessor can trace a sample of alerts back to the documented target and see that the target was reviewed and approved.
Consider a commercial alternative for Windows
For Windows estates, Microsoft's guidance for timely analysis of Windows logs uses Defender for Endpoint P2 with Microsoft Sentinel and Microsoft Defender XDR. This is one commercial route alongside self-hosted tools such as Wazuh, OpenSearch or Graylog. Licensing, data residency and the team skills required should be compared against the written scope before choosing. Confirm current licensing terms with Microsoft and the platform vendors, since they change and an assessor will test the working configuration rather than the product name.
What must be in place before an assessor reviews logging?
An assessor will not accept a log platform on its product features alone. The six items below are the conditions the platform must meet before a logging review can produce usable evidence, and each one can be checked and documented in advance.
Complete inventory of log sources
Start with a written list of every system that must send events to the central platform: domain controllers, servers, workstations, internet-facing applications, and the security tools themselves. For each source, record the owner, the event types it produces and whether it is confirmed as forwarding. Compare this list against the ML2 event types, including application control, PowerShell, command line, privileged access and MFA events. The gap between the inventory and the live forwarding list is usually the first finding an assessor raises. Keep the inventory as a dated, versioned document.
Synchronized time across sources
Events from different hosts only support an incident timeline if their clocks agree. Confirm that every source and the central platform synchronize to the same time service, and record the configured source and any drift checks. Check a sample event from each source type and compare its timestamp with the platform's receipt time. Keep the time service configuration export and a dated sample of the comparison, because assessors ask how event sequences were established.
Audit policies enabled on sources
Forwarding a log source does not help if the source never generates the events. Confirm that the audit policies for logon, privileged use, process creation, and command line capture are enabled on each host class, and that application control and PowerShell logging are switched on where ML2 requires them. Export the effective policy from a representative host of each class, not just the template. For self-hosted platforms such as OpenSearch, the Security plugin audit logging is disabled by default and must be configured in opensearch.yml and audit.yml, so export those files too.
Documented retention and lifecycle rules
Write down how long each log class is kept online, how long it is kept in archive, and what triggers deletion. In OpenSearch, Index State Management policies can roll over, make indices read-only, snapshot them and delete them after a set number of days. Graylog uses index rotation by message count, size or time, and retention that deletes the oldest indices. Confirm that the configured policy matches the written rule, and keep an export of each policy alongside the document that approves it.
Restricted access to the log store
Logs that can be edited or deleted by the people they record cannot support an assessor's conclusions. Define which roles can read, which can administer the platform, and which can delete indices or change retention. Remove standing administrator rights from routine analysts and use separate accounts for platform administration. Export the role mappings and the list of accounts with delete or write rights, then reconcile that list against current staff. Confirm that changes to these roles are themselves logged to the central platform.
Tested alerts and incident reporting
ML2 expects timely analysis of internet-facing server logs, and reporting of incidents to the CISO and to ASD. Test the alert workflow with a controlled event, such as a deliberate failed logon burst on a test host, and confirm that the alert is raised, triaged, escalated and recorded. Keep the sample alert record, the ticket or case that followed, and the escalation contact list. For Wazuh, alerts written to alerts.json and the dashboard view are both useful evidence. Record the date of the test and repeat it when rules or contacts change.
Frequently asked questions about ML2 central logging
Is a self-hosted log platform acceptable for Essential Eight Maturity Level 2?
Yes. The Essential Eight is a set of mitigations rather than a certification scheme, so ML2 does not require a specific product or a hosting model. What matters is that the platform receives the required events, protects them from unauthorised modification and deletion, and supports timely analysis that your assessor can test. Self-hosted tools such as Wazuh, OpenSearch and Graylog Open can meet those needs when they are configured and evidenced properly. Your organization still owns the control, so confirm the approach with your assessor before you build it. You can check the requirements yourself in the Essential Eight maturity model.
Does the Graylog Open license create a problem for ML2 logging?
It can, depending on how you deploy and offer it. Graylog Open is licensed under the Server Side Public License version 1 from Graylog 4.0 onward, and earlier releases remain under GPL v3. The SSPL is not an OSI-approved open source license, and its section 13 applies when you offer Graylog as a public service. An internal logging deployment for your own staff is a different case from a hosted service sold to customers, so have legal counsel review your use. Graylog Enterprise and Graylog Security are paid editions, and their features differ from the open edition. Ask your vendor to confirm which features your ML2 design needs.
What drives the effort to set up central logging for ML2?
The main drivers are the number of log sources, how many event types you must capture, and how much of the environment already produces usable logs. Application control, PowerShell, command line, privileged access and MFA events all need to reach the central platform, and each source type has its own collection method. Protecting logs and setting retention also takes design work, as does defining alert rules for internet-facing servers. Expect more effort where endpoints, servers and cloud services are managed by different teams. Ask any provider to break its quote into source onboarding, parsing and alerting, access controls for log integrity, and documentation.
Can an implementation partner build the ML2 logging platform for us?
A partner can plan, deploy, configure, harden and document a self-hosted logging platform inside your own infrastructure, and it can prepare the evidence your assessor will request. DeployOpen works this way: it prepares systems, controls and evidence, and most engagements are fixed-scope with the scope and deliverables agreed in writing before work starts. Your organization still owns the controls, decides on policy, and runs the platform after handover unless you buy a retainer for ongoing support. A partner does not decide whether your logging meets ML2 on its own authority.
How long does it usually take to configure central logging for ML2?
No reliable duration is supplied for this work, so treat any figure you hear with caution. The timeline depends on the number of log sources, the state of existing logging, the target architecture and how quickly your change control and access approvals move. Ask your provider for a timeline tied to a written scope, with milestones for source onboarding, alert validation and evidence capture. Your internal teams will also need time to review and approve configuration changes, which often takes longer than the technical build itself.
What must our organization provide before a logging project starts?
You need to supply access and decisions, not just budget. Typical inputs include an inventory of systems that generate in-scope events, administrator access to the source systems and cloud accounts, network paths for collection, storage and retention requirements, and named owners who can approve alert rules and incident handling. You also need a written decision on where the platform will run and who may administer it. Without these inputs, scope tends to grow during delivery. Confirm each dependency in your statement of work before work starts.
Can a partner issue the assessment or confirm that we meet ML2?
No. A partner can prepare systems, configuration and evidence, but it cannot issue assessment reports or certificates. Essential Eight maturity is evidenced through assessment of each strategy's implementation and effectiveness, and the assessment must be carried out by a suitably qualified independent assessor that you engage. Your assessor decides whether the evidence meets the maturity model. Ask the assessor early which evidence formats they accept, such as exported logs, configuration records, alert tests and incident records.
How DeployOpen deploys and documents ML2 logging
DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For central logging at Maturity Level 2, we prepare the log platform and the evidence an independent assessor will review, while the organization keeps ownership of its controls and the assessment outcome.
How we scope
- Agree in writing which log sources, event types and retention settings the engagement covers before work starts.
- Map each in-scope log source to the ML2 logging requirements it supports, so gaps are visible at the outset.
- Confirm with your assessor which artifacts they expect, since the written scope should name those deliverables explicitly.
How we build
- Deploy the chosen self-hosted log platform in your cloud account, data center or air-gapped network, as the scope defines.
- Configure collection for application control, PowerShell, command line, privileged access and MFA events where your environment produces them.
- Set protection for stored event logs against modification and deletion, and test that analysis and alerting work for internet-facing server logs.
How we hand over
- Document the architecture, collection configuration, retention settings and access controls so your team can reproduce and audit them.
- Provide test records showing that defined events reach the platform, are protected and are reviewed within the timelines your own procedures set.
- Hand over the evidence package in a format your internal audit or independent assessor can review, without DeployOpen issuing any report or certificate.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped separately from the initial fixed-scope engagement.
- Retainers can cover platform upgrades, log source additions and periodic checks that central logging still meets the agreed scope.
- Ask any provider to state in writing which tasks stay with your staff, including incident reporting to the CISO and ASD.
