How T1207 rogue domain controller detection protects Active Directory
Active Directory is the trust anchor for authentication, authorization and policy in most Windows environments, so an unexpected domain controller is a direct threat to everything that depends on it. Detecting T1207 Rogue Domain Controller means finding a system that registers itself as a domain controller or changes directory data in a way that makes it look authoritative, before defenders start trusting its answers. The technique matters because a system that behaves as a domain controller can serve directory information that defenders assume is accurate, which undermines the logs, group memberships and account states that incident responders rely on. In ATT&CK version 20.0, T1207 sits under the Defense Impairment tactic (TA0112), the tactic that describes adversaries breaking the mechanisms defenders use to see and trust what is happening.
Within an intrusion, this technique typically appears after an attacker has already gained enough privilege to write to directory objects or to introduce a new host into the domain. The adversary's goal is not only persistence but credibility: if defenders cannot confirm which controllers are legitimate, their investigation steps, password resets and access reviews can be fed false data. For a SOC lead, the first decision is which signals are authoritative. Confirm with your Windows and directory teams which domain controllers should exist, where their server objects and service records are expected, and which change windows allow new controllers. Any object or service record that falls outside that list becomes a high-priority alert rather than routine noise.
The detection approach in this topic relies on three telemetry sources: network traffic content, Active Directory object creation and Active Directory object modification. Your task is to confirm that domain controller logging and directory auditing are enabled across all controllers, that the relevant event sources reach your log platform such as Wazuh or Security Onion, and that retention covers the period needed for investigations. Confirm these settings in your own environment, because coverage depends on how your domain controllers were built and which audit policies were applied. The sections that follow cover the specific data components, detection logic and cyber range exercises needed to test this.
Which Windows telemetry reveals a rogue domain controller
This table maps each telemetry source to the T1207 signal it can reveal, the collection tool that carries it, and what the reader must confirm in their own environment. Read it as a checklist: a row is only useful once the named log source is confirmed as enabled and forwarded. The main takeaway is that directory object changes and replication-related network traffic are the strongest signals, and both depend on audit policy and sensor placement that must be verified locally.
| Telemetry source | Signal to look for | Collection tool | Confirm in your environment |
|---|---|---|---|
| Active Directory Object Creation (DC0066) | New domain controller or server objects appearing in the directory outside a planned promotion | Wazuh agent Windows event logs from domain controllers, forwarded to Security Onion | Directory service object auditing is enabled on domain controllers and changes are logged with the creating account |
| Active Directory Object Modification (DC0066) | Changes to computer account attributes, service principal names or replication-related permissions on non-DC hosts | Wazuh agent Windows event logs, aggregated in Security Onion | Which change types your audit policy captures and whether attribute-level changes are logged, not only object-level changes |
| Network Traffic Content (DC0085) | Directory replication or DC locator traffic originating from hosts that are not on the approved domain controller list | Zeek or Suricata sensors on server and user segments, aggregated in Security Onion | Sensor placement covers the segments where workstations and servers talk to domain controllers, and the approved DC list is current |
| Unexpected directory service traffic from non-DC hosts | Connections to global catalog or replication ports from workstations or application servers | Zeek connection logs, with Suricata alerts where rules are tuned | Baseline of normal directory traffic per segment, and which hosts are authorized to act as directory servers |
| DC promotion and DNS registration events | Newly registered SRV records for domain controller services or new DC-style hostnames in DNS | Wazuh agent DNS and system logs, correlated with Security Onion | DNS server logging and dynamic update auditing are enabled, and who may register records is documented |
| Asset inventory reconciliation | Domain controller objects with no matching change ticket, build record or hypervisor entry | Wazuh inventory data, correlated with the CMDB export in Security Onion | The CMDB or asset register is complete and reviewed on a schedule you define |
Detection logic for an unexpected domain controller in Active Directory
A rogue domain controller is only dangerous if it can be told apart from legitimate DC activity. The detection ideas below work together: each one checks a different signal, and the allow lists, change calendars and host role inventory used to tune them are shared across all of them. Expect false positives from planned DC work, so every alert should be checked against the change record before escalation.
New or changed DC account objects
Watch Active Directory Object Creation and Active Directory Object Modification events for computer objects that carry domain controller attributes, or for changes to the Domain Controllers organizational unit and its group membership. Alert when such a change falls outside an approved change window. Tune with a list of known DC computer objects and a change calendar. Main false positives: planned DC promotions, retirements and read-only DC deployments, all of which should be linked to a change ticket.
Replication from unlisted hosts
Directory replication requests come from DCs. Network Traffic Content from Zeek or Suricata can show replication-style RPC traffic originating from a host that is not on the DC allow list. Check the source against the host role inventory before escalating. Main false positives: new DCs not yet added to the allow list, and backup or monitoring tools that query directory services. Keep the allow list current as part of every promotion and decommission.
DC service traffic from workstations
Domain controller services such as Kerberos, LDAP and the global catalog should be reached from endpoints that are expected to use them, but not be offered by workstations or member servers. Flag host-to-host traffic where a non-DC system begins answering on DC service ports. Tune by mapping subnets and servers in the host role inventory. Main false positives: appliances or test systems that run directory-aware services, and lab ranges that mirror production naming.
Correlate with privileged group changes
A new DC is usually followed by changes to privileged groups or delegated rights, because the newcomer needs replication and administrative access. Correlate DC object events with changes to Domain Admins, Enterprise Admins and the Domain Controllers group within a short time window, using the outputs from the Audit mitigation. A DC change paired with a privilege change is the highest priority case. Main false positives: planned administrator onboarding and scheduled rotations, which the change calendar should explain.
Validate detections in a cyber range
Rehearse these detections in a private cyber range against a copy of the directory. Confirm that each log source is collected, that the allow lists match the lab's DC inventory, and that planned promotions and decommissions produce expected alerts without escalation. Record the ATT&CK version the rules target, because technique mappings can change between releases. Ask your partner to confirm the exact event coverage in your environment before relying on it.
How to validate a T1207 rogue domain controller detection
This sequence confirms that Windows domain controller telemetry reaches the SIEM, that the detections for T1207 Rogue Domain Controller fire with the expected fields in an isolated lab, and that the results are recorded against the ATT&CK version under test. The output is a validation record your team can review, repeat and hand to auditors or leadership.
Confirm the approval and isolation boundary
Before any emulation, the security lead and the domain owner sign a written scope that names the isolated lab domain, the test accounts, the emulation goal and the people who may stop the exercise. The lab must have no routing to production directories, DNS zones or trust relationships. Confirm this with a network check run from the lab side. The step is done when the signed scope and the isolation evidence are filed together in the validation record.
Verify domain controller telemetry reaches the SIEM
The platform engineering team checks that the lab domain controllers forward the logs that back the target data components, including Network Traffic Content (DC0085) and Active Directory Object Modification (DC0066), and that Active Directory Object Creation events are present. Each source is confirmed by searching for recent events in the SIEM and comparing timestamps with the host clock. The step closes when every expected source shows events from each controller, with no gaps in the time window.
Plan the approved emulation of an unauthorized directory role change
The red team or the detection engineer writes the emulation goal in plain language: an unauthorized change to directory objects that would make a system behave as if it were a domain controller, performed inside the isolated domain only. The plan states the expected artifacts, the expected log sources and the stop conditions. It does not include operational steps. The step closes when the plan is reviewed and approved by the security lead, and the expected artifacts are listed for the next step.
Confirm each detection fires with expected fields
Once the emulation runs, the detection engineer checks the SIEM for each detection tied to the target data components. Each alert should carry the fields the analytic depends on, such as the acting account, the host, the object class, the time and the change type. Missing or empty fields are logged as defects against the detection, not hidden. The step closes when each expected detection has either fired with complete fields or has a recorded gap with an owner and a fix.
Measure alert quality against the emulation log
The team compares the emulation log, which records what was done and when, with the alerts produced. They count true positives, missed actions and extra alerts that do not match any emulated action. They also check whether alerts reach the queue the analysts use. The step closes with a short table of detected, missed and noisy results per analytic, reviewed by the detection engineer and the SOC lead. Ask your vendor or detection content owner how they define these metrics so your figures stay comparable over time.
Tune and re-test the detections that failed
For each missed or noisy result, the detection engineer adjusts the logic, the field mapping or the data source, then repeats the emulation within the same approved scope. Changes are version-controlled so the reviewer can see what changed and why. The step is complete when the re-test shows the corrected behavior, or when the team records a documented accepted risk with an owner and a review date.
Record results against ATT&CK v20 and clean up the lab
The validation record names the ATT&CK version targeted, which is Enterprise ATT&CK v20 in this sequence, and maps each detection to its technique and data components. ATT&CK v20 was released on 2026-10-13, and releases can rename, deprecate or revoke techniques, so confirm the mapping against the current version before you reuse it. The lab domain is then reset or torn down, and the cleanup is logged. The step closes when the record, the signed scope and the cleanup evidence are stored together for review.
Why ATT&CK version and data component mapping matter for this detection
Every detection for T1207 Rogue domain controller should name the ATT&CK version it targets, because the technique record has changed between releases. ATT&CK v18, released October 28, 2025, replaced the detections on technique pages with detection strategies, identified by DET IDs, and analytics, and it made major updates to data components. A rule written against an older page may therefore cite a detection that no longer appears in the current record. ATT&CK v19, released April 28, 2026, split the Enterprise Defense Evasion tactic and introduced Defense Impairment as TA0112, so the tactic labels on T1207 must be checked against the version in use. Record the release next to every rule so an auditor can reproduce the mapping later.
The data component mapping is what ties a rule to the ATT&CK record. For this technique, the most useful telemetry is Network Traffic Content (DC0085), which shows traffic from a host presenting itself as a domain controller, along with the Active Directory Object Modification (DC0066) and Active Directory Object Creation components, which show directory objects being changed or introduced. Each rule's data source field should carry the component ID so coverage can be traced from the log source to the technique. Confirm in the enterprise-attack bundle for your chosen version that T1207 references these components, because the set of IDs can change between releases and the Active Directory Object Creation component should be checked the same way.
Turn this into a short register that your detection team maintains. For each T1207 rule, record the technique ID, the ATT&CK version, the STIX bundle filename and its checksum, the data component IDs, any DET IDs the rule implements, and the log sources that feed it. Ask your SIEM or content vendor to show that mapping for the version you run, and do not accept a mapping that names only the technique. Use the same version for the cyber range rehearsal so the test results describe the rules you will deploy. When ATT&CK publishes a new release, rerun the mapping check against the new bundle before changing production rules. The attack-stix-data repository is the place to start for bundle files.
Preventive controls that limit rogue domain controller risk
A rogue domain controller needs an account or path that can add a directory server or change directory objects. The four controls below narrow who can make those changes, keep the account lifecycle under review, and record each change so defenders can see it.
Restrict Tier 0 privileged accounts
Privileged Account Management (M1026) limits which accounts can add domain controllers, replicate directory data or edit the groups that hold those rights. In Active Directory this means keeping membership of Domain Admins, Enterprise Admins and Schema Admins small, placing those members in dedicated administrative accounts, and blocking those accounts from logging on to ordinary workstations. Compare the membership of these groups with an approved list on a fixed schedule. Every membership change to a Tier 0 group should trigger a review.
Govern account lifecycle
User Account Management (M1018) covers how accounts are created, reviewed, changed and removed. For T1207, the concern is any account that can promote a server or replicate directory data, including service accounts and older administrator accounts that nobody actively watches. Assign an owner to each privileged and service account, review dormant accounts on a set cycle, and remove rights the owner can no longer justify. Stale privileged accounts are the easiest unnoticed path to a directory change. Confirm with your identity team how each review is recorded.
Audit directory object changes
Audit (M1047) makes the directory record who changed what and when. Enable auditing of directory service access and object changes on every domain controller, then forward those events to a central platform such as Wazuh or Security Onion so the record survives a compromised host. Confirm that the audit policy covers the object classes involved in adding a new domain controller, including computer objects and the server settings that identify a replica. Without that coverage, a rogue domain controller can appear with no record of its creation.
Reconcile the domain controller inventory
Keep a written inventory of every authorized domain controller and reconcile it against what the directory reports. Compare the domain controller objects in the directory, the replication partners the domain reports, and the hosts listed in your build and configuration records. Investigate any server that appears in one source but not the others, and any server that holds directory roles without an approved change record. This check turns the audit trail into a standing control. Any domain controller missing from the inventory should be treated as an incident until proven otherwise.
Triage and response when a rogue domain controller alert fires
The first decision when a rogue domain controller alert fires is whether the host that announced itself as a domain controller is one your directory team actually owns. Check the host name, IP address, and computer account against your authoritative domain controller inventory and the most recent change records for DNS, the domain controller build, and any decommissioning work. Confirm the registration of the _msdcs service locator records and the domain controller's computer object in Active Directory, since an unexpected object or a service record pointing at an unfamiliar address is the strongest early indicator. If no approved change explains the host, treat the alert as a possible intrusion and open an incident before anyone reboots or reimages anything. Because the signal often comes from directory replication or network content, the replication topology and the source and destination of the traffic are part of the same evidence set.
Preserve evidence before you isolate. Capture the domain controller's Security and Directory Service event logs, the AD DS replication metadata from the legitimate domain controllers, DNS query logs, and the network sensor records for the suspicious host, and hash the collected files. Isolation needs care: cutting a real domain controller off from its replication partners can break directory consistency and lock out users across sites. Contain at the network edge or on the switch port for the suspicious host, block its replication and LDAP paths to the rest of the forest, and keep the legitimate controllers serving clients. Review every privileged account and group membership change in the window since the host first appeared, including Domain Admins, Enterprise Admins, and any account that authenticated to the suspicious host. Then scope which systems accepted that host as authoritative: clients using it through DNS or Group Policy, member servers that joined or re-validated trust, and applications that bind to the directory by name. Coordinate early with the identity team, which owns the directory and will decide on credential resets, the network team, which owns segmentation and sensor data, and legal and privacy counsel, who should advise on evidence handling and any notification duties. The final decision is whether to rebuild the affected domain controllers from known-good media or to re-verify domain trust and directory integrity against independent records. Rebuilding is the safer default when the investigation cannot establish what the rogue host changed, while re-verification fits a confirmed false positive with a complete change record. Document that decision, its owner, and the evidence behind it, so the post-incident review can test it.
Rehearsing T1207 detection in a private cyber range
DeployOpen builds the cyber range inside the client's own network, so telemetry, credentials and test domain data stay under the client's control. The lab is an isolated Windows Active Directory forest with sample workstations and member servers, plus a monitoring stack built from open-source components. The goal is to produce the same log sources the production environment would produce, so the detections rehearsed here transfer to live operations.
- Isolated directory: A separate Active Directory forest with no routed path to production, seeded with sample users, groups and a small set of workstations.
- Monitoring stack: Wazuh agents on domain controllers and workstations, with Security Onion or standalone Zeek or Suricata sensors on the lab segment to capture network traffic content and metadata.
- Audit configuration: Directory service change auditing and Windows security auditing enabled on domain controllers, matching the settings the client's production estate uses.
- Time and naming: Synchronized clocks and consistent host naming so alerts can be correlated across Wazuh and the network sensors.
- Access boundaries: Named lab operators, recorded access, and a documented process to reset the range between exercises.
Confirm with the client which audit policies and log forwarding paths are used in production before the range is built, because a range that differs from production will test the wrong detections.
Injects are planned, approved events that the exercise control team introduces to test whether defenders detect and respond to a rogue domain controller. Each inject is written in advance with its objective, expected telemetry, and stop conditions, and it is approved by the client's security and infrastructure owners. Scenarios should be realistic in the sense of matching the client's environment, but every step is agreed in writing before the exercise begins.
- Unplanned controller appearance: A new domain controller object and directory replication activity appear on the lab segment outside any recorded change window.
- Unexpected service records: A host registers directory service locator records that the operations team did not create, to test whether the team notices changes to directory objects.
- Replication from an unknown source: Replication traffic from an unapproved host reaches a lab domain controller, to test network sensor coverage.
- Change window comparison: The team is asked to match the event against the change calendar, to test process as well as tooling.
- Stop and rollback: A defined point where the control team halts the inject and the range is restored.
Before approval, confirm the scenario list, the authority for each step, and who may stop the exercise.
A good detection produces an alert that an analyst can understand within minutes, with enough context to decide whether the event is a change, a test or an intrusion. The rehearsal should record what alerts fire, how long they take to reach the analyst queue, and whether the analyst notes show the reasoning behind the triage decision. Measuring these points matters more than the rule count, because a rule that fires late or without context does not help the response.
- Directory object alerts: Wazuh or the chosen SIEM raises an alert when a new domain controller object or related directory object is created or modified, referencing the host, the account and the time.
- Network sensor alerts: Zeek or Suricata records show replication or directory traffic from a host that is not in the asset inventory.
- Timeline quality: The alert timeline places the directory change, the network activity and any authentication events in order, with consistent time sources.
- Analyst notes: Notes state the observed facts, the change calendar check, the decision and the next step, without assuming the outcome.
- Gaps: Each missed signal is logged with the reason, such as a missing audit policy or a sensor blind spot.
Detection logic should be validated against the ATT&CK version the team targets, and the team should confirm which data components their sensors actually provide.
Response in the range should follow the client's incident response plan, with roles assigned before the exercise starts. Good coordination means the detecting analyst escalates quickly, the directory owner verifies the domain controller inventory, and the incident lead decides on containment. Containment should be tested in the range, including isolating the suspect host and confirming that legitimate replication is not disrupted. Lessons learned are the record that turns the exercise into improved controls.
- Escalation path: The analyst contacts the incident lead and directory administrators using the contact list from the plan, and the time of each handoff is recorded.
- Verification: The directory team confirms against the approved controller list and change records whether the object is legitimate.
- Containment: Network isolation or host disablement is performed through a documented, reversible step, with a check that production-like replication is not broken.
- Evidence capture: Directory change logs, sensor captures and host state are preserved according to the client's evidence handling procedure.
- Lessons learned record: The after-action report lists timeline, decisions, gaps, owners and due dates for each corrective action.
Confirm with the client who holds authority to isolate domain controllers in production, since that decision drives the containment step.
Questions SOC leads ask about detecting rogue domain controllers
How do I build a domain controller allow list for detection?
Start from a signed inventory of every domain controller your directory actually uses, then compare it against what appears in directory and network telemetry. Pull the list from the directory itself, including the computer objects in the Domain Controllers organizational unit and the members of the Domain Controllers group, and cross-check it with the replication topology and DNS service records. Record the owner, the site, the build source and the change ticket for each entry. Review the list on a fixed schedule and after every approved promotion or demotion, because the allow list is only useful if it stays current. Treat any domain controller that replicates but is absent from the list as a finding to investigate, not as a noise item to suppress.
How do I tell a legitimate domain controller promotion from a rogue one?
The distinguishing factor is whether the promotion matches an approved change. A legitimate promotion usually traces to a change record, a known administrator account acting inside a maintenance window, a build from your standard image, and a server that appears on the allow list shortly afterward. A rogue promotion often lacks one or more of these, arrives outside a window, or comes from a host nobody owns. Correlate the directory object creation and attribute changes for the new server with authentication events on the promoting account, with the host's first appearance in replication traffic, and with the change management system. Build the rule so that a promotion without a matching change record raises a high-priority alert, and let approved promotions close automatically through an exception list that expires.
Do I still need network telemetry if I already collect directory logs?
Yes, in most environments. Directory logs record what the directory was told to do, but an attacker who can already modify directory objects may avoid creating the expected records or may act through a path your logging does not cover. Network telemetry, such as the content visible in replication and directory protocol traffic captured by Zeek or Suricata, shows what actually crossed the wire between hosts. Comparing the two is the stronger check: a server that replicates over the network but has no matching directory creation event is a strong signal. Confirm with your own sensor placement that replication traffic between your domain controllers is visible at the points you monitor, because a sensor that never sees the traffic cannot support the comparison.
How should I tune detections for read-only domain controllers?
Read-only domain controllers are a legitimate pattern, often deployed at branch sites or in perimeter networks, so they should be modeled as a distinct, approved class rather than excluded from scrutiny. Add them to the allow list with their role recorded, and build separate expectations for them: they should receive replication from a defined set of writable partners, they should not be granted broad administrative rights, and their creation should follow the same change control as writable servers. Alerts can then key on deviations from that expected role, such as a read-only server requesting changes it should never hold or appearing in a site where your design does not place one. Validate the tuned rules in your cyber range with both a read-only and a writable test server so you can confirm the rule separates them correctly.
How often should I retest rogue domain controller rules after ATT&CK updates?
Retest whenever the ATT&CK version your mappings target changes, and review the mappings at each release. MITRE publishes ATT&CK updates on its updates pages, and releases can rename, deprecate or revoke techniques, so a detection that names a specific version needs an explicit review step when that version is superseded. Recent releases were v18 on October 28, 2025, v19 on April 28, 2026 and v20 on October 13, 2026. Record the version in every rule's metadata, compare the technique and detection strategy references against the new STIX bundle, and rerun your range tests against the rule set. Also retest after any change to your sensor placement, log sources or directory design, since those changes can silently break a rule that still matches its ATT&CK mapping.
How do I confirm a rogue domain controller detection with a range exercise?
Run the exercise in an isolated private cyber range that mirrors your directory topology, with its own test domain, and agree the scope and rules of engagement in writing before any activity begins. Define the expected outcome for each scenario, such as an unapproved promotion that must generate a high-priority alert, an approved promotion that must not, and a read-only server that must be classified correctly. Then check that the expected records appear in your SIEM, that the Sigma or Wazuh rules fire within your agreed response window, and that the alert carries enough context for an analyst to triage it. Document each result, the rule version tested and any gap, and feed the findings back into the allow list and tuning. DeployOpen can plan and run this kind of exercise as a fixed-scope engagement, with the written scope defining what is tested.
Official ATT&CK sources for T1207 detection work
Start every T1207 detection project with the Defense Impairment tactic page, MITRE's TA0112 entry, because it defines the tactic that T1207 Rogue Domain Controller sits under and sets the context for why a rogue directory controller undermines what defenders can see and trust. Use it to confirm that the tactic and technique names in your detection catalog match MITRE's current wording before you write any rule. The tactic page describes intent, so pair it with the technique page for T1207 itself, which carries the detection strategies, analytics and data components your Windows telemetry needs to map to. Record the ATT&CK version you read, because the tactic was introduced in v19 and earlier mapping spreadsheets may still show these behaviors under Defense Evasion.
Next, read the ATT&CK updates pages for every release you target. The release notes for v18 and v19 describe the structural changes that affect this work: v18 replaced technique-level detections with detection strategies and analytics and reshaped data components, while v19 split Defense Evasion and created Defense Impairment. Releases can also rename, deprecate or revoke techniques, so a detection that maps cleanly today may need a new reference later. Assign a named owner to review each release, and have that owner confirm whether T1207 or its data component references changed before the next quarterly rule review. Ask your SIEM or detection vendor which ATT&CK version their content pack targets, since mismatched versions are a common source of silent coverage gaps.
The enterprise-attack 20.0 STIX bundle is the machine-readable source for the mapping itself. Load it into your detection engineering pipeline or review it with a script to confirm which data components, such as Network Traffic Content (DC0085) and Active Directory Object Modification (DC0066), are linked to T1207 and its relationships, rather than relying on a manually maintained table. Compare the bundle against your rule metadata so each Sigma rule, Wazuh rule or Security Onion detection references the same technique and version. Note that the bundle is published per version, so a rule written against 20.0 should be re-checked when you move to a later release. Confirm with your own engineers whether they will parse the bundle directly or consume a derived dataset, and document that choice in your detection standard.
How DeployOpen builds and rehearses T1207 detections
DeployOpen approaches T1207 Rogue domain controller as a fixed-scope engagement inside the client's own Active Directory environment. The work covers telemetry review, detection content for Windows, validation in a private cyber range and a documented handover that the client's own team can operate.
How we scope
- Agree in writing which Windows domain controllers, sites and log sources are in scope for T1207 detection
- Confirm which telemetry exists for Network Traffic Content, Active Directory Object Creation and Active Directory Object Modification
- Name the ATT&CK version the detections will target so mappings stay accurate across future releases
How we build
- Build detection logic for T1207 in Wazuh or Security Onion rules, described in words and mapped to ATT&CK data components
- Tune alerts against the client's normal directory replication and domain controller onboarding activity before go-live
- Document each detection's data sources, false positive sources and the Windows audit settings it depends on
How we hand over
- Deliver a written runbook covering triage steps, escalation paths and the evidence to preserve for domain controller investigations
- Provide cyber range exercise results showing which T1207 scenarios the detections caught and which gaps remain open
- Walk the client's security and identity teams through the detection content and the open items in a recorded session
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts
- Ongoing support, upgrades and continuous testing of the T1207 detections are available as a retainer
- Ask any quote to separate one-time build effort from recurring tuning, rule updates and rehearsal time
