Support TIBER-EU Compliance

The entity conducts a risk assessment and puts in place risk management controls to facilitate a controlled, safe test on live production systems.

Mandatory

Provides live session visibility and account-level access controls that inform the risk assessment; administrators can define and enforce restrictions ahead of the test window.

IT can apply access controls, multi-factor authentication (MFA), and session policies to AD users, groups, and organizational units (OUs).

File permission reports help the team spot overly permissive access to CIF-supporting data stores before the test begins, reducing the attack surface ahead of testing.

The scope of the test includes the people, processes, and technology supporting Critical or Important Functions (CIFs). The test is conducted on live production systems.

Mandatory

UserLock's agent-based deployment is fully functional in live Windows production environments (or test environments) and maintains policies in offline or airgapped scenarios.

FileAudit monitors live production Windows files, file servers, and cloud storage that contains CJI/CIF-supporting data in real time (the same systems the Red Team will target during the test).

Only the Control Team is informed about the test. All other staff — the Blue Team — remain unaware and conduct their duties normally throughout testing.

Mandatory

Logon monitoring and anomaly alerts operate continuously without requiring Blue Team awareness. The Blue Team's normal detection capabilities are preserved unmodified.

File access monitoring and event alerts continues normally without requiring Blue Team configuration changes, ensuring authentic, uncoached detection behaviour during testing.

Testing phase: What the red team will encounter

The RTT executes attack scenarios targeting the people, processes, and technology supporting CIFs, testing the entity's protection, detection, and response capabilities.

Mandatory

UserLock's MFA, concurrent session limits, and contextual access controls are among the active defences the Red Team must contend with, directly testing the organization's security posture.

Real-time file access monitoring means any Red Team access to CIF-supporting data stores is captured and can trigger Blue Team alerts, directly testing detection capability.

During active testing, the RTT take a stage-by-stage approach. All actions are logged for the replay exercise, as evidence for the RTTR, and for future reference.

Mandatory

Every logon event, session, failed attempt, and privilege use is logged with timestamp, identity, workstation, and outcome, providing the entity-side audit trail needed to demonstrate RTT actions.

All file access events are logged with full context: user, path, operation, and timestamp. This creates the evidence that the Blue Team needs to reconstruct the Red Team's movements through data stores.

The minimum duration of active testing is 12 weeks. The RTT aim to reach all flags set for systems supporting CIFs across all attack phases (in, through, out).

Mandatory

Session-based access controls and monitoring help actively resist Red Team lateral movement throughout the 12-week window. The Blue team can continuously block and force logoff accounts with suspicious activity, detect concurrent sessions, and limit access based on factors like time, IP address, and device.

Continuous file activity monitoring across the full testing period helps ensure that Red Team access to data flags is captured at any point during the 12-week window, not just during attended monitoring sessions.

Physical red teaming (e.g., planting a device on premises) is permitted within scope, provided all necessary precautions are in place and no legal boundaries are crossed.

Optional

If a physical attacker gains local access, UserLock's device lock enforcement (after n minutes of inactivity), concurrent session detection, and workstation-based access restrictions remain active as controls.

File access from a locally planted device is captured in the audit log. This provides evidence of the physical intrusion vector's data access attempts for the Blue Team and replay exercise.

Closure phase: Reporting, replay, and remediation

The Blue Team is informed of the test and delivers a Blue Team Test Report (BTTR), mapping its actions alongside the RTT's actions using a timeline of detections.

Mandatory

The UserLock audit log provides a complete, tamper-evident timeline of all logon events during the test period. This is the primary source the Blue Team uses to map detected activity against the RTT's actions.

FileAudit's event log of all file accesses during the testing period gives the Blue Team concrete, timestamped evidence of which data the Red Team accessed, when, from where, and from which user account.

During the Purple Teaming exercise, the Blue Team and Red Team work together to identify alternative attack steps and how the Blue Team could have responded to them.

Mandatory

Session and logon audit data supports discussion of how alternative attack paths (e.g. credential stuffing, lateral movement) would have appeared in logs, and whether existing alert thresholds would have caught them.

File access history supports exploration of alternative data exfiltration paths and whether the Blue Team's file monitoring rules would have triggered alerts under different RTT approaches.

After the replay and Purple Teaming exercises, the entity produces a remediation plan to address vulnerabilities and root causes identified during testing.

Mandatory

Where gaps in access controls or session management are identified during testing, UserLock provides the specific remediation controls to close them: MFA rollout, session time limits, workstation restrictions.

Where file access controls are found to be insufficient, FileAudit's permission analysis and access rights reporting supports targeted remediation, tightening access to CIF-supporting data stores.

Audit records from the test must be protected, retained, and handled with appropriate confidentiality controls given the sensitivity of test findings.

Mandatory

Audit records are stored in a centralized, tamper-evident repository separate from the Windows Security Event Log. Only UserLock admins with the right permissions have access to the log, retained with configurable policies aligned to the test lifecycle.

File audit data is stored independently of audited systems with permissions limiting who can view test-period records, protecting the confidentiality of findings throughout the closure phase.

Cross-phase: Ongoing entity-side controls

The entity must be able to assess its protection, detection, and response capabilities — the three dimensions that a TIBER-EU test specifically evaluates.

Mandatory

UserLock directly supports the three pillars that TIBER tests evaluate: protection (MFA, access controls), detection (session monitoring, real-time alerts, audit logs), and response (one-click account block, force logoff).

FileAudit addresses detection (real-time alerts on abnormal file access, identifying which user account did what), and the audit logs provide forensic evidence to support response and post-incident review.

Access to test documentation and findings must be limited on a need-to-know basis throughout the test. Code names should be used in all communications and documents.

Mandatory

UserLock administrators can restrict access to UserLock, and decide who can view certain reports. This helps ensure that only Control Team members can view test-period logon data without exposing it to Blue Team personnel.

FileAudit report access can be restricted to named FileAudit administrators, ensuring that test-period file access records are not visible to Blue Team staff who should remain unaware of the test.

TIBER-EU tests are conducted on live production systems. Entities must ensure backup and restoration capabilities are in place and that testing minimises risk to CIF continuity.

Mandatory

Account block and logoff controls are configured with production-safe thresholds — preventing Red Team activity from inadvertently triggering mass lockouts that disrupt CIF operations

File monitoring is read-only and non-intrusive. It does not modify, block, or interrupt file operations on CIF-supporting systems, preserving continuity throughout the testing period.