Tier Model & Delegation Model

Any security improvement is welcome, but no single security measurement will help us to protect all our environment. For example, a firewall facing internet indeed will help protecting our network, but will not help us too much on Trojans or worms. This is an antivirus work.

The Tier Model does help us on implementing a set of tiers or buffer zones. And with a set of rules and guides, we can restrict and isolate some of our assets. But here we are missing reducing the overall permissions and rights a user might have. Even if this user is within a given restricted tier. Here is where the twin brother comes to play: the Delegation Model can help reduce the those mentioned permissions and rights.

Even more, by implementing both models is not sufficient. We have to be prepared to monitor security, and to properly react on any given event. This demonstrates the need to have several tools (monitoring, analysis, alerting, etc.) working embedded into the models.

So, the answer is: Yes, we need both models working together. The Tier Model will help us to isolate and protect our assets, while the Delegation Model will help us to reduce the permissions and rights of our users and administrators.

Enforcing tier boundaries in Active Directory requires a combination of native controls and best practices to prevent credential exposure and lateral movement. Key technical enforcement mechanisms include:

1. Authentication Policy Silos (Windows Server 2012 R2+)

• Create separate authentication policy silos for each tier (Tier 0, Tier 1, Tier 2)
• Restrict privileged accounts to authenticate only to devices within their tier
• Use the New-ADAuthenticationPolicySilo PowerShell cmdlet to create silos
• Assign policies using Set-ADAccountAuthenticationPolicySilo
• Example: Domain Admins can only authenticate to Domain Controllers (Tier 0 devices)

2. Windows Defender Application Control (WDAC)

• Deploy code integrity policies to Privileged Access Workstations (PAWs)
• Whitelist only approved applications and binaries
• Prevent execution of unauthorized tools, malware, or credential-stealing utilities
• Use audit mode first, then enforce mode after validation

3. Credential Guard and Remote Credential Guard

• Enable Credential Guard on all Tier 0 and Tier 1 devices (requires TPM 2.0)
• Uses virtualization-based security (VBS) to isolate credentials
• Prevents pass-the-hash and pass-the-ticket attacks
• Configure via Group Policy: Computer Configuration → Administrative Templates → System → Device Guard

4. Group Policy Restricted Groups and User Rights Assignment

• Use GPOs to control local administrator group membership on each tier
• Deny "Log on locally" rights to lower-tier accounts on higher-tier systems
• Example: Deny Tier 2 accounts from logging into Tier 0 and Tier 1 devices
• Apply "Deny log on as a batch job" and "Deny log on as a service" where appropriate

5. Network Segmentation with Firewall Rules

• Implement network isolation between tier management zones
• Use Windows Firewall with Advanced Security or network firewalls
• Restrict RDP, WinRM, and SMB traffic based on source tier
• Create jump servers or PAWs as the only entry points between tiers

6. Just-In-Time (JIT) Administration

• Use Microsoft Identity Manager (MIM) PAM or third-party solutions
• Grant privileged access only when needed, for a limited time window
• Automatically revoke permissions after the time-limited session expires
• Maintains audit trail of all elevation requests and approvals

7. Privileged Access Management (PAM) with Shadow Security Principals

• Deploy MIM PAM to create time-bound memberships in privileged groups
• Uses a dedicated bastion forest for administrative account isolation
• Prevents permanent membership in high-privilege groups like Domain Admins

For detailed implementation guidance, see the AD Tier Model Overview and Tier 0 Configuration pages. The combination of these mechanisms creates defense-in-depth, ensuring that even if one control fails, others prevent tier boundary violations.

Third-party administrative tools—such as backup software, monitoring agents, and remote management utilities—can introduce risk if not properly categorized and managed within the tier model. Here’s how to handle them securely:

1. Categorizing Vendor Tools by Tier

• Determine the highest tier resource the tool can access. If it touches Domain Controllers or Tier 0 assets, it must be treated as Tier 0.
• Assign each tool and its service accounts to the appropriate tier (e.g., backup agent for DCs = Tier 0, monitoring agent for servers = Tier 1).
• Document all third-party tools and their tier assignments.

2. Agent Deployment Strategies

• Deploy agents only to systems within their assigned tier. Never install a Tier 0 agent on Tier 1 or Tier 2 systems.
• Use separate management consoles and update servers for each tier if possible.
• Apply strict firewall rules to limit agent communication to only what is necessary.

3. Credential Management for Tools

• Use unique service accounts per tier for each tool. Never reuse service accounts across tiers.
• Store credentials in a secure vault (e.g., CyberArk, Azure Key Vault) and rotate them regularly.
• Audit tool permissions and access logs frequently to detect misuse or privilege escalation.
• Work with vendors to understand their security model and request support for tiered deployments if needed.

Properly managing third-party admin tools is critical to maintaining tier boundaries and preventing a single compromised tool from becoming a path for lateral movement or privilege escalation. For more, see the Tier Model and Tier 0 Configuration guides.

Service accounts are one of the most challenging aspects of tier model implementation because they often span multiple systems and can create tier boundary violations if not managed correctly. Here's the proper approach:

Core Principle: Service Accounts Inherit the Tier of the Highest-Value Asset They Access

If a service account needs to access a Tier 0 resource (like a Domain Controller), it becomes a Tier 0 account regardless of where the service runs. This is critical for preventing privilege escalation attacks.

Best Practices for Service Account Management:

1. Use Group Managed Service Accounts (gMSA)

• Automatically rotate passwords every 30 days (configurable)
• Eliminate the risk of password theft or weak passwords
• Create using New-ADServiceAccount -Name svc-Tier0-Backup -DNSHostName svc-Tier0-Backup.domain.com -PrincipalsAllowedToRetrieveManagedPassword "Tier0-Servers"
• No human knows or can retrieve the password
• Preferred over traditional service accounts in all scenarios

2. Tier-Specific Service Account Placement

• Tier 0: Place in dedicated OU like OU=Service Accounts,OU=Tier 0,OU=Admin,DC=EguibarIT,DC=local
• Tier 1: Separate OU for server/application service accounts
• Tier 2: Workstation and low-privilege service accounts
• Apply tier-appropriate GPOs and authentication policies to each OU

3. Avoid Cross-Tier Service Accounts

• Never use the same service account across multiple tiers
• If a service needs to access resources in different tiers, redesign the architecture
• Consider using separate service accounts per tier with delegated permissions
• Use service-to-service authentication (certificate-based) when possible

4. Common Service Account Scenarios:

• Backup Software: If it backs up Domain Controllers → Tier 0 account required
• Monitoring Tools: Create separate monitoring accounts per tier, each with read-only access to their respective tier
• SQL Server: Application database → Tier 1 or Tier 2 depending on data classification
• Web Application Pools: Typically Tier 2 unless hosting administrative interfaces
• SCOM/SCCM Agents: If managing DCs → Tier 0; if managing servers → Tier 1; if managing workstations → Tier 2

5. Implement Least Privilege for Service Accounts

• Never add service accounts to Domain Admins, Enterprise Admins, or other high-privilege groups
• Use delegation to grant only the specific permissions needed
• Regularly audit service account permissions using tools like BloodHound or PingCastle
• Document the purpose and required permissions for each service account

6. Authentication Policy Restrictions

• Add Tier 0 service accounts to Tier 0 Authentication Policy Silo
• Restrict authentication to only the servers/DCs where the service runs
• Use New-ADAuthenticationPolicy with UserAllowedToAuthenticateFrom parameter
• Prevents lateral movement if the service account is compromised

7. Monitoring and Auditing

• Enable advanced auditing for service account activity
• Alert on authentication attempts outside expected systems
• Monitor for SPNs (Service Principal Names) added to service accounts
• Detect Kerberoasting attempts against service accounts with SPNs

For detailed guidance on implementing gMSAs with scheduled tasks and services, see the Scheduled Task using gMSA article. Proper service account management is essential for maintaining tier integrity while enabling necessary automation and services.

Break-glass accounts (also called emergency access accounts or fire-call accounts) are critical safety mechanisms that provide access to privileged systems during emergencies when normal authentication methods fail. These accounts are essential for disaster recovery scenarios.

What Qualifies as an Emergency Requiring Break-Glass Access?

• Complete failure of multi-factor authentication (MFA) systems
• Identity provider outage (Azure AD/Entra ID unavailable)
• Privileged Identity Management (PIM) service failure
• Complete compromise of administrative accounts requiring immediate lockdown
• Critical production outage requiring immediate Domain Controller access
• Ransomware attack requiring isolated recovery operations

Essential Characteristics of Break-Glass Accounts:

1. Account Configuration

• Create at least two break-glass accounts for redundancy (e.g., BG-Admin01, BG-Admin02)
• Make them members of Domain Admins (on-premises) or Global Administrator (Azure/Entra)
• Use extremely strong, randomly-generated passwords (minimum 30+ characters)
• Store passwords in physical safe or secure password vault with restricted access
• Never use these accounts for routine administration

2. MFA and Conditional Access Exemptions

• Cloud: Exclude break-glass accounts from ALL Conditional Access policies requiring MFA
• On-Premises: Do not enable smart card requirements or MFA for these accounts
• Reason: If MFA system fails, break-glass accounts must still function
• This is the ONE exception to "all admin accounts require MFA" rule

3. Password Policy Exemptions

• Set password to never expire (use Set-ADUser -PasswordNeverExpires $true)
• Exempt from fine-grained password policies that enforce rotation
• Rationale: Password rotation could cause lockout during emergency if updated password is not accessible
• Compensating control: Extensive monitoring and auditing

4. Monitoring and Alerting (Critical!)

• Configure real-time alerts for any authentication attempt (successful or failed)
• Alert should trigger immediate notification to security team (SMS, phone call, email)
• Monitor authentication source IP, device, time, and activity performed
• Use Azure Sentinel, Splunk, or SIEM to detect anomalous activity
• Enable advanced auditing: Account Logon, Logon/Logoff, Privilege Use, Directory Service Changes

5. Physical Security Controls

• Print passwords and seal in tamper-evident envelopes
• Store in physical safe requiring dual-authorization (two-person integrity)
• Maintain sign-out log with timestamp, person, and justification
• Alternative: Store in enterprise password vault (e.g., CyberArk, Thycotic) with break-glass access workflow
• Ensure passwords are accessible even if all IT systems are down

6. Cloud-Specific Considerations (Azure/Entra ID)

• Use cloud-only accounts (not synchronized from on-premises AD)
• Reason: If on-premises infrastructure is compromised or offline, cloud break-glass still works
• Exclude from Azure AD PIM (Privileged Identity Management) just-in-time activation
• Configure as permanent Global Administrators (not eligible assignments)
• Example naming: bg-admin01@contoso.onmicrosoft.com

7. On-Premises AD Specific Considerations

• Place accounts in dedicated OU: OU=Break Glass,OU=Tier 0,OU=Admin
• Block inheritance to prevent accidental GPO application
• Add to Tier 0 Authentication Policy Silo but allow authentication from PAWs and DCs
• Ensure accounts can log on locally to Domain Controllers
• Exempt from "Account is sensitive and cannot be delegated" to allow backup/recovery scenarios

8. Testing and Validation

• Test break-glass account access quarterly or bi-annually
• Validate password retrieval process works
• Confirm authentication succeeds and monitoring alerts trigger
• Document test results and any issues discovered
• Rotate passwords after each test or suspected compromise

9. Post-Use Procedures

• After any use of break-glass account, perform immediate investigation
• Review all actions performed during the session
• Change the password immediately after use
• Update password in physical safe/vault
• Document the incident: reason for use, actions taken, duration, outcome
• Conduct post-incident review to determine if normal access could be restored differently

Example PowerShell to Create Break-Glass Account:

# Generate complex password
  $Password = -join ((48..57) + (65..90) + (97..122) | Get-Random -Count 32 | ForEach-Object {[char]$_})
  $SecurePassword = ConvertTo-SecureString $Password -AsPlainText -Force

  # Create break-glass account
  New-ADUser -Name "BG-Admin01" -SamAccountName "BG-Admin01" `
    -UserPrincipalName "BG-Admin01@EguibarIT.local" `
    -AccountPassword $SecurePassword `
    -Enabled $true `
    -PasswordNeverExpires $true `
    -CannotChangePassword $false `
    -Path "OU=Break Glass,OU=Tier 0,OU=Admin,DC=EguibarIT,DC=local"

  # Add to Domain Admins
  Add-ADGroupMember -Identity "Domain Admins" -Members "BG-Admin01"

  # Display password for secure storage (do this only once)
  Write-Host "Break-Glass Password: $Password" -ForegroundColor Yellow
  Write-Host "Store this password securely and delete from screen immediately!" -ForegroundColor Red

Break-glass accounts are your insurance policy against identity system failures. While they introduce risk by bypassing MFA and other security controls, the combination of strong passwords, extensive monitoring, physical security, and restricted use makes them a necessary component of enterprise resilience. For more on Tier 0 account management, see Building Tier 0.

Auditing and reviewing delegations is essential to maintain least privilege and prevent privilege creep in Active Directory. Over time, delegated rights can accumulate, leading to excessive or outdated permissions. Here’s how to approach ongoing delegation review:

1. PowerShell Scripts for Delegation Auditing

• Use Get-ACL and Get-ADObject to enumerate permissions on OUs and objects.
• Example: List all users/groups with delegated rights on an OU:

  Get-Acl 'AD:\OU=Users,DC=EguibarIT,DC=local' | Select-Object -ExpandProperty Access | \
    Where-Object { $_.IsInherited -eq $false } | \
    Select-Object IdentityReference, ActiveDirectoryRights, ObjectType

• Use dsacls.exe for a command-line summary of permissions.
• Export results regularly for comparison and change tracking.

2. Access Certification Processes

• Schedule periodic (quarterly/annual) reviews of delegated rights with business owners.
• Use access review tools (e.g., Microsoft Entra ID Access Reviews, third-party IAM solutions) to certify or revoke access.
• Document review outcomes and remediation actions.

3. Identifying Excessive Permissions

• Look for users/groups with Full Control or Write permissions outside their expected scope.
• Use tools like BloodHound or PingCastle to visualize and analyze privilege relationships.
• Remove or reduce permissions that are no longer justified.
• Implement a change management process for all new delegations.

Regular delegation audits help prevent privilege escalation, support compliance, and ensure your AD environment remains secure and manageable over time.

No. Once a user becomes member of a high privileged group, there is no technical restriction. Because of this, she or him can create/change/delete any other administrator. This is the problem with big AD implementations, which did not consider a proper Delegation model (or a 3^rd party tool which might provide this functionality).

Restricting Privileged Users is not possible. This is by Active Directory design.

Yes. Active Directory is extremely granular when referred to delegations.

We can delegate the task to manage:

• full partition
• certain kind of objects within a given partition
• attribute sets for an object
• specific attributes

So, if we need to delegate the right to reset passwords for users, we can do it. If we need to delegate the right to create and delete users, we can do it. If we need to delegate the right to manage groups, we can do it. If we need to delegate the right to manage only certain attributes of a user, we can do it. And so on.

We can delegate “exclusive” administrator tasks, as long as we can identify the task, and the responsible person or team.

Yes. A split-delegation is when 2 different teams have similar rights within the same object. This is very common and recommended to split loads within teams.

A very common scenario is:

• the user provisioning team is in charge to create and delete users
• Service Desk team in charge to reset passwords and unblock user accounts
• Human Resources team who will maintain certain attributes for the user. This could be be the Employee number and type or the organizational description.

In this example, we can see the importance of the “To who do I need to delegate?” and “What it has to be delegated?” questions

YES. 99% of AD implementations do need to delegate authority, even if a small team is administering the environment. The exception to the rule might be when ONLY 1 administrator is in place and he is solely using the physical AD console (Keyboard and Screen physically attached to the server within the server room) and not using the Admin privileges outside this box.

The same way we have doctors specialized in different areas, we do have administrators and operators who maintain the environment. So yes, most of the time we need to delegate authority.

Well, this is a very generic and difficult question to answer, or at least it is without having several more following it. We need to identify any person who is making a change within Active Directory, excluding of course typical standard changes as “Changing my own password”. In smaller scenarios a simple division within operations (reboot a computer, backup and restore data, reset and unblock user, etc,) and administration (create users, groups, access rights, etc.) might be sufficient.

But for larger organizations there might be several teams for each area:

• one group is in charge of granting and revoking access
• a different team manages the user provisioning
• several teams take care of desktops and laptops
• several teams are responsible for the servers
• individual teams are responsible for the infrastructure

Here is the Business who will dictate who is responsible of any assigned task, if the task is feasible. In other words, we should be able to identify the persons, or group of persons, who assign to run a task against the directory.

What it should be delegated? Same as the previous question, quite hard to individually response. The simplest, easiest, most common and worst thing we can do is to assign Administrator rights. We must completely ignore this approach, as is not even an option. What we must identify, is what specific action happening on the directory, and if it matches with the “To who do I need to delegate?” question, then we already identify a role, which a delegation will follow. Taking the user provisioning idea, this team creates and deletes users within the directory. So a delegation will be done for the identified team granting the right to ONLY create users.

No, the Enterprise Access Model does not replace the AD Tier Model for on-premises and hybrid environments—it expands upon it. This is a critical distinction that organizations must understand.

The Enterprise Access Model supersedes the legacy tier model by incorporating modern requirements such as cloud services (Azure, AWS, GCP), external user access (B2B/B2C), API access pathways, and DevOps workflows. EAM transforms the original three tiers into a five-plane architecture: Control Plane (Tier 0), Management Plane, Data/Workload Plane, User Access, and App Access.

Critical requirement: If your environment includes on-premises Active Directory infrastructure—whether standalone or in a hybrid configuration with cloud services—you MUST implement and maintain the AD Tier Model. Within your on-premises AD domain, strict tier-based segmentation remains non-negotiable. Domain controllers, privileged accounts, and administrative workstations must adhere to Tier 0 controls.

For hybrid environments, you implement both: AD Tier Model for on-premises infrastructure protection and EAM's expanded planes to extend protection into cloud resources, implementing PAWs, Just-In-Time (JIT) access, conditional access policies, and continuous monitoring across the entire estate.

Only organizations transitioning to cloud-native architectures without on-premises AD dependencies can focus solely on implementing the EAM framework. However, for the majority of enterprises maintaining hybrid infrastructures, the AD Tier Model is the essential foundation upon which modern privileged access security is built.

Privileged Access Workstations (PAWs) are hardened, dedicated systems that serve as secure administrative platforms, forming a critical security boundary between privileged credentials and potentially compromised endpoints. PAWs prevent credential harvesting attacks that exploit memory-resident credentials on multi-purpose systems.

The technical necessity for PAWs stems from how Windows authentication works. When you authenticate to any system, your credentials temporarily reside in memory (LSASS process). If that system is compromised with malware, attackers can extract these credentials using tools like Mimikatz or similar credential dumpers. If you use the same workstation for email, web browsing, and privileged administration, a single phishing email or malicious website can compromise your entire administrative access.

Technical controls implemented on PAWs include:

• Application allowlisting (Windows Defender Application Control/WDAC) that permits only approved administrative tools
• Restricted internet access preventing phishing and drive-by downloads
• Enforced multi-factor authentication (MFA) at every logon
• Device attestation through TPM-backed certificates proving hardware integrity
• Credential Guard and Remote Credential Guard using virtualization-based security to isolate credentials
• Disabled credential caching preventing offline attacks
• No productivity applications—PAWs for Tier 0 operations must never be used for email, web browsing, or any task that could introduce malware vectors

In hybrid environments, PAWs must enforce context-aware access controls that verify device compliance state, network location, and authentication strength before permitting connections to both on-premises domain controllers and cloud management portals (Azure Portal, Microsoft 365 admin centers).

Without PAWs, even the best-designed tier architecture fails because compromised administrative credentials can bypass all logical boundaries. PAWs provide the physical and technical enforcement layer that makes tier separation effective.

Certain administrative roles possess capabilities that, when compromised by an attacker or malicious insider, can inflict catastrophic and potentially irrecoverable damage. The Enterprise Access Model addresses these through tier segmentation, credential isolation, and time-bound access controls.

Domain Administrators and Enterprise Administrators: These represent the highest risk. Compromise enables Golden Ticket attacks (forging Kerberos TGTs for persistent backdoors), GPO modification to deploy ransomware enterprise-wide, exfiltration of entire AD databases containing password hashes, disabling security controls and logging, or establishing skeleton keys that bypass authentication. Material impact includes complete operational shutdown, regulatory compliance violations with multi-million dollar fines, intellectual property theft, and permanent reputational damage affecting customer trust and stock valuations.

Backup Administrators and Storage Administrators: These control recovery capabilities. Malicious actors can delete or encrypt backup repositories, rendering ransomware attacks unrecoverable and forcing organizations to pay extortion demands. Modern ransomware operators specifically target backup infrastructure—including cloud-based backup services—before deploying encryption payloads. Without tier-segregated backup admin accounts enforced through PAWs, organizations lose their last defense against data loss.

PKI Administrators and Certificate Authority operators: Can issue fraudulent certificates for code signing (enabling malware deployment that bypasses security controls), SSL/TLS interception (man-in-the-middle attacks), or authentication certificates (impersonating any user or service). Compromised PKI requires complete infrastructure rebuild and certificate re-issuance—a process taking months that disrupts every digital service.

Cloud Global Administrators (Azure/Microsoft 365): Can modify conditional access policies creating backdoor access, export all organizational data including emails and OneDrive contents, delete production cloud resources including databases and virtual machines, or modify federation settings to persist access even after password resets. In hybrid environments without proper tier separation, compromising a cloud Global Administrator provides pathways to on-premises infrastructure through Azure AD Connect or Entra Cloud Sync servers.

How EAM addresses these threats: The no-credential-crossing principle technically enforced through Authentication Policy Silos, Protected Users security group membership preventing credential caching, Just-In-Time (JIT) access limiting exposure windows from permanent to hours, separate administrative accounts for on-premises versus cloud preventing cascade compromise, and multiple independent security boundaries requiring sequential breaches that dramatically increase detection likelihood.

Implementing the Enterprise Access Model in an existing hybrid environment requires a phased approach that maintains operational continuity while progressively strengthening security posture. This is not a weekend project—expect 6-18 months depending on organizational size and complexity.

Phase 1: Assessment and Planning (4-8 weeks)

• Conduct a complete inventory of privileged accounts across on-premises AD, Azure/Entra ID, and any other cloud platforms
• Identify all high-value assets requiring Tier 0/Control Plane protection: domain controllers, certificate authorities, backup infrastructure, Azure subscriptions with production resources
• Map existing administrative workflows and identify role-based access requirements
• Document current authentication pathways and trust relationships between on-premises and cloud
• Assess current PAW deployment state (or lack thereof)

Phase 2: On-Premises Tier Model Implementation (3-6 months)

• Implement Tier 0 protection first—this is your foundation. Create dedicated Tier 0 admin accounts separate from daily-use accounts
• Deploy PAWs for Tier 0 administrators using hardened Windows workstations with WDAC, Credential Guard, and network isolation
• Configure Authentication Policy Silos restricting where Tier 0 accounts can authenticate
• Enable Protected Users group membership for privileged accounts
• Implement logon restrictions using Group Policy preventing credential crossing between tiers
• Progressively move to Tier 1 (server management) and Tier 2 (workstation/user) segmentation

Phase 3: Cloud Control Plane Integration (2-4 months)

• Create separate cloud-only administrative accounts for Azure/Entra ID management—never use synchronized on-premises accounts for cloud Global Administrator roles
• Implement Entra ID Privileged Identity Management (PIM) for Just-In-Time access to cloud administrative roles
• Configure Conditional Access policies requiring MFA, compliant devices (PAWs), and approved network locations for all administrative access
• Enable Continuous Access Evaluation (CAE) for real-time session revocation
• Deploy Azure AD Connect or Entra Cloud Sync on dedicated Tier 0 servers with restricted access

Phase 4: Extended Planes and Monitoring (Ongoing)

• Implement Management Plane controls for enterprise-wide IT management functions
• Establish Data/Workload Plane segmentation for per-workload management
• Configure User Access and App Access pathways with appropriate B2B/B2C controls
• Deploy comprehensive logging to Azure Monitor/Sentinel or SIEM solution
• Enable anomaly detection for privileged account usage patterns
• Conduct regular access reviews and recertification campaigns

Critical success factors: Executive sponsorship and budget allocation, dedicated project team with security and AD expertise, phased rollout preventing operational disruption, extensive administrator training on new workflows, documented emergency access procedures (break-glass accounts), and continuous monitoring with defined incident response procedures.

Remember: the goal is not perfection on day one—it's continuous improvement. Start with Tier 0 protection on-premises, extend to cloud Control Plane, then progressively expand coverage. Each phase delivers measurable security improvements while building organizational capability for the next phase.

The Enterprise Access Model is absolutely implementable and highly recommended for small and medium-sized organizations. In fact, SMBs often have an advantage: less technical debt, fewer legacy systems, and more agility to implement security controls quickly.

Scaling EAM for SMBs: You don't need to implement every aspect simultaneously. Start with the highest-risk controls that provide maximum protection:

• Separate administrative accounts: Even in a 5-person IT team, every administrator should have a separate account for privileged tasks versus daily work. This is free and immediately effective.
• Basic PAWs: You don't need expensive hardware. A dedicated Windows 11 Pro workstation ($800-1200) configured with Windows Defender Application Control and removed from internet browsing/email provides 80% of PAW benefits. For very small teams, even a separate user profile on the same physical machine with restricted applications is better than nothing.
• Cloud-native advantages: SMBs using Microsoft 365/Azure without on-premises AD can implement EAM faster. Enable Privileged Identity Management (included in Microsoft 365 E5 or Azure AD Premium P2), configure Conditional Access policies (included in Microsoft 365 Business Premium), and enforce MFA (free in Entra ID)—these are mostly configuration, not cost.
• Hybrid SMBs: If you have on-premises AD, focus first on Tier 0 protection. Identify your 2-3 domain controllers, create separate Tier 0 admin accounts, implement basic logon restrictions via Group Policy, and use a dedicated admin workstation. This costs minimal budget but prevents 90% of privilege escalation attacks.

Cost considerations: Many EAM controls are configuration-based, not purchase-based. Group Policy restrictions, separate accounts, Authentication Policy Silos, and Protected Users group are free AD features. Cloud controls like Conditional Access and PIM require licensing (Microsoft 365 E5 or equivalent), but many SMBs already have these through CSP licensing programs.

Simplified implementation timeline for SMBs: A 20-50 person organization can achieve substantial EAM implementation in 2-3 months: Week 1-2 (assessment and account creation), Week 3-6 (PAW deployment and basic tier restrictions), Week 7-10 (cloud controls and Conditional Access), Week 11-12 (monitoring and refinement).

The risk argument: Ransomware doesn't discriminate by company size. In fact, SMBs are increasingly targeted because attackers assume weaker security. A compromised Domain Admin account is equally devastating whether you have 50 employees or 50,000. The median ransomware demand for SMBs is now $200,000-500,000—far exceeding the cost of implementing basic EAM principles.

Start simple, improve continuously: Implement what you can now, document what you can't yet achieve, and progressively enhance. A partial EAM implementation is infinitely better than no privileged access security strategy. Begin with account separation and basic tier boundaries—these cost almost nothing and provide substantial protection.

Remember: Microsoft's security recommendations aren't just for Fortune 500 companies. The same attack techniques compromise SMBs daily. The Enterprise Access Model provides a scalable framework that works at any organizational size—you adjust the complexity and tooling to match your resources, but the core principles remain equally valid and necessary.

Not really. The model focuses on many “very old, but STILL valid” concepts, which help us to protect our directory. For example, having unpatched systems will render into vulnerable systems, and the only solution is to patch them, reducing the risk thus increasing security.

Another example is the least privileged access. If we have a user with more rights than needed, then we are exposing more than needed. The solution is to reduce the rights, thus increasing security.

Another example is the logon restrictions. If we have a user who can logon from anywhere, then we are exposing more than needed. The solution is to restrict the logon, thus increasing security.

But when a more advanced thread is ahead, the solutions get more complex. The main concept here is: if you cannot access it, then you cannot tramper with it. The model is restricting highly targeted identities (nice cookie for hackers), minimizing their exposure. The model can be somehow modified and adapted, but there is no other “efficient” alternative to the concept.

So, the answer is: No, there is no alternative to these models. We can adapt them, but not replace them.

Because Active Directory is exposed, and don’t misunderstand this. It is exposed to persons, applications, services and networks, so there is a real risk to get it compromised. There are hundreds of details to take into account to objectively check the risk, but the risk is there, and the best thing to do is to manage the risk.

In the old times, just by having an antivirus was enough (Huuh!) to be protected. No internet available. Networks where pretty small, or even inexistent. As the devices where expensive, granting access to anyone was not so easy, so physical security was kind of present.

Today, we have an extreme connectivity, with at least 1 antivirus, anti-Trojans, worms, rootkits, spam… we have access control list for disks, groups, shares, mailboxes… we have many web applications and services, which use any kind of authentication and authorization… databases… social networks… BYOD… AND we have to manage it, assuring the integrity and security of all these. We cannot afford the risk of exposing all this information, or even worst compromising it.

We care about firewalls… networks… IDS… personal FW… antivirus… Authentication… Authorization… so: Why we are not protecting one of the most valuable and critical assets?

This model will not be the “ultimate” security for AD, but will help mitigate credential theft techniques.

Active Directory is a prime target for attackers because compromising it grants control over the entire enterprise. Understanding common attack vectors and how tier/delegation models mitigate them is essential for effective defense:

1. Pass-the-Hash (PtH) Attack

• How it works: Attacker extracts NTLM password hash from memory and uses it to authenticate without knowing the plaintext password.
• Defense via Tier Model: Prevents high-privilege credentials from being exposed on lower-tier systems. If a Tier 2 workstation is compromised, no Tier 0/1 credentials are present to steal.
• Defense via Delegation Model: Reduces the number of accounts with Domain Admin privileges, limiting the value of stolen credentials.
• Additional Controls: Protected Users group, Credential Guard, restricting NTLM authentication.

2. Golden Ticket Attack

• How it works: Attacker compromises the KRBTGT account hash and forges Kerberos Ticket Granting Tickets (TGTs) with unlimited validity and arbitrary group memberships.
• Defense via Tier Model: Limits lateral movement and reduces attack surface to reach Domain Controllers where KRBTGT resides.
• Defense via Delegation Model: Restricts who can access Domain Controllers and perform DCSync operations.
• Additional Controls: Regular KRBTGT password rotation (twice), monitoring for anomalous ticket lifetimes, Protected Users group enforcement.

3. Kerberoasting Attack

• How it works: Attacker requests service tickets for accounts with Service Principal Names (SPNs), then cracks the tickets offline to obtain plaintext passwords.
• Defense via Delegation Model: Ensures service accounts use Group Managed Service Accounts (gMSAs) with 120+ character passwords that are immune to offline cracking.
• Defense via Tier Model: Segregates service accounts by tier, limiting exposure if one is compromised.
• Additional Controls: Long complex passwords for service accounts, monitoring for TGS-REQ activity, removing unnecessary SPNs.

4. DCSync Attack

• How it works: Attacker uses replication permissions (DS-Replication-Get-Changes-All) to impersonate a Domain Controller and request password hashes for any account, including KRBTGT and Domain Admins.
• Defense via Delegation Model: Strictly controls who has replication rights. Only actual DCs and specific backup accounts should have these permissions.
• Defense via Tier Model: Isolates systems that can authenticate as accounts with replication rights to Tier 0 only.
• Additional Controls: Audit DS-Replication-Get-Changes events (Event ID 4662), use advanced threat detection tools to identify abnormal replication requests.

5. Silver Ticket Attack

• How it works: Attacker compromises a service account's password hash and forges service tickets for that specific service, bypassing the KDC entirely.
• Defense via Delegation Model: Implements gMSAs with automatic password rotation and strong passwords, making hash extraction less valuable.
• Defense via Tier Model: Limits which systems can access specific services based on tier boundaries.
• Additional Controls: Service account password rotation, monitoring for service tickets without corresponding TGT requests.

6. Privilege Escalation via Misconfigured Delegation

• How it works: Attacker exploits accounts configured for unconstrained or constrained delegation to impersonate high-privilege users.
• Defense via Delegation Model: Regularly audits and removes unnecessary delegation configurations. Uses resource-based constrained delegation where appropriate.
• Defense via Tier Model: Restricts which accounts can delegate credentials and where they can be used.
• Additional Controls: Protected Users group members cannot be delegated, monitor for accounts with TRUSTED_FOR_DELEGATION flag.

7. Lateral Movement via Admin Shares (C$, ADMIN$)

• How it works: Attacker uses stolen credentials to access administrative shares on other systems and deploy malware or extract data.
• Defense via Tier Model: Prevents administrative credentials from being valid across tier boundaries via Authentication Policy Silos.
• Defense via Delegation Model: Reduces the number of accounts with local admin rights on systems.
• Additional Controls: Local Admin Password Solution (LAPS), network segmentation, firewall rules restricting SMB access.

Real-World Impact: Major breaches like Target (2013), NotPetya (2017), and SolarWinds (2020) all involved AD compromise and lateral movement. The Tier/Delegation models specifically address the attack paths used in these incidents by enforcing credential isolation and least privilege.

For comprehensive implementation guidance, see AD Tier Model, Delegation Model, and RBAC Implementation.

Detecting Active Directory compromise is critical because attackers often establish persistent access and remain undetected for months. Here are the key indicators, tools, and techniques to identify if your AD has been breached:

Signs of Active Directory Compromise:

1. Suspicious Administrative Accounts

• Unknown accounts in Domain Admins, Enterprise Admins, or Schema Admins groups
• Service accounts added to privileged groups
• Accounts with "Password Never Expires" or "User Cannot Change Password" set unexpectedly
• Newly created accounts with high privileges shortly after creation
• Check with: Get-ADGroupMember -Identity "Domain Admins" -Recursive

2. Abnormal Authentication Patterns

• Privileged accounts authenticating from unusual locations or workstations
• Authentication attempts at unusual times (2 AM on weekends)
• Multiple failed login attempts followed by successful authentication (password spray attacks)
• Service accounts authenticating interactively instead of as a service
• Monitor Event IDs: 4624 (successful logon), 4625 (failed logon), 4768 (Kerberos TGT request), 4769 (Kerberos service ticket request)

3. Unauthorized Changes to Active Directory

• Unexpected Group Policy Objects (GPOs) or modifications to existing GPOs
• Changes to AdminSDHolder object (affects how permissions are protected)
• Modifications to Schema (rare and highly suspicious)
• New or modified AD trusts
• Changes to delegation permissions on sensitive OUs
• Monitor Event IDs: 5136 (directory service object modified), 5137 (object created), 5141 (object deleted)

4. Abnormal Replication Activity

• DCSync attacks appear as replication requests from non-DC systems
• Replication from unknown or unauthorized sources
• Unusual volume of replication traffic
• Monitor Event ID 4662 with DS-Replication-Get-Changes-All operation

5. Kerberos Anomalies

• Service tickets (TGS) requested without corresponding TGT (Silver Ticket indicator)
• Tickets with abnormally long lifetimes (10 years = Golden Ticket)
• Kerberos tickets requested for the KRBTGT account
• Downgrade to RC4 encryption when AES is configured
• Check KRBTGT last password change: Get-ADUser krbtgt -Properties PasswordLastSet

Tools for Compromise Detection:

1. BloodHound

• Maps AD relationships and attack paths to Domain Admins
• Identifies shortest path to compromise for any user
• Reveals hidden delegation relationships and group nesting
• Free and open-source: https://github.com/BloodHoundAD/BloodHound

2. PingCastle

• Comprehensive AD security assessment and scoring
• Identifies misconfigurations, stale accounts, weak passwords
• Generates risk reports with prioritized remediation steps
• Free edition available: https://www.pingcastle.com

3. Purple Knight (Semperis)

• Scans for AD security indicators of exposure (IoE) and indicators of compromise (IoC)
• Checks for Golden Ticket attacks, ACL backdoors, and privileged account exposure
• Free community edition: https://www.purple-knight.com

4. Microsoft Defender for Identity (formerly Azure ATP)

• Real-time detection of suspicious activities and attacks
• Uses behavioral analytics and machine learning
• Detects Golden Ticket, Pass-the-Hash, DCSync, and reconnaissance attacks
• Cloud-based sensor deployment on Domain Controllers

5. Semperis Directory Services Protector (DSP)

• Continuous monitoring and automated threat detection
• Real-time alerting on dangerous AD changes
• Automated rollback of malicious modifications
• Commercial product with deep AD expertise

Critical Event IDs to Monitor:

• 4662: An operation was performed on an object (watch for replication operations)
• 4624: Account successfully logged on (Type 3 = network, Type 10 = RDP)
• 4672: Special privileges assigned to new logon (admin rights)
• 4768: Kerberos TGT requested (watch for encryption downgrades)
• 4769: Kerberos service ticket requested (Kerberoasting indicator)
• 5136: Directory service object modified (unauthorized changes)
• 4720: User account created (especially with immediate admin privileges)
• 4728/4732: Member added to security-enabled group (privileged group additions)

Baseline Security Posture Assessment:

Run a comprehensive assessment immediately:

# Check for privileged group members
Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select Name, SamAccountName

# Find accounts with password never expires
Get-ADUser -Filter {PasswordNeverExpires -eq $true} -Properties PasswordNeverExpires | Select Name, Enabled

# Check KRBTGT password age
Get-ADUser krbtgt -Properties PasswordLastSet | Select Name, PasswordLastSet

# Find accounts with AdminCount=1 (protected by AdminSDHolder)
Get-ADUser -LDAPFilter "(adminCount=1)" | Select Name, Enabled

# Check for suspicious SPNs
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName

Immediate Actions if Compromise is Suspected:

• Isolate affected Domain Controllers from the network
• Reset KRBTGT password twice (with 10-hour gap between resets)
• Reset all privileged account passwords
• Review and remove unauthorized accounts from privileged groups
• Engage incident response team and consider professional forensics
• Document all findings for post-incident analysis

Regular security assessments using these tools and techniques should be performed quarterly at minimum. Continuous monitoring with Microsoft Defender for Identity or similar solutions is strongly recommended for early detection. For more on securing AD, see Tier 0 Security.

Failing to implement proper tier and delegation models exposes your organization to significant security risks, compliance violations, and potentially catastrophic business impact. Here's a comprehensive view of the consequences:

1. Technical Security Risks

Rapid Lateral Movement (Mean Time to Domain Admin: Hours)

• Without tier boundaries, a single compromised workstation can lead to Domain Admin access within hours
• Attackers use tools like BloodHound to map the fastest path to privileged accounts (average: 3-5 hops)
• Credentials cached on workstations provide stepping stones across the entire environment
• Real-world example: Target breach (2013) - HVAC vendor credentials led to full network compromise in days

Unlimited Blast Radius

• Single compromised account with excessive permissions can affect entire organization
• Ransomware can spread from workstations to servers to Domain Controllers without restriction
• Example: NotPetya (2017) caused $10 billion in damages by exploiting unrestricted lateral movement
• Recovery time: Weeks to months for complete domain rebuild

Persistent Backdoors

• Attackers establish hidden administrative accounts in privileged groups
• Create malicious GPOs for persistence and data exfiltration
• Modify ACLs to grant themselves permanent access rights
• Average dwell time before detection: 207 days (Mandiant M-Trends 2023)

2. Compliance and Regulatory Violations

PCI-DSS (Payment Card Industry Data Security Standard)

• Requirement 7: Restrict access to cardholder data by business need-to-know
• Requirement 8: Identify and authenticate access to system components
• Violation consequences: Fines up to $100,000 per month, loss of ability to process credit cards
• Delegation Model directly addresses least-privilege requirements

HIPAA (Health Insurance Portability and Accountability Act)

• Minimum necessary standard: Access limited to minimum necessary for job function
• Administrative safeguards: Implement policies to prevent unauthorized access
• Violations: Up to $1.5 million per violation category per year
• Recent enforcement: $16 million fine for failure to implement access controls

SOC 2 Type II

• Common Criteria 6.3: Requires segregation of duties and least privilege
• Failing audit can result in loss of customers and revenue
• Many SaaS vendors require SOC 2 compliance from partners

GDPR (General Data Protection Regulation)

• Article 32: Appropriate security measures including access control
• Fines: Up to €20 million or 4% of global annual revenue, whichever is higher
• Example: British Airways fined £20 million for insufficient access controls

3. Financial Impact

Direct Breach Costs

• Average cost of data breach: $4.45 million (IBM Cost of Data Breach Report 2023)
• Ransomware payments: Average $812,000 (Sophos State of Ransomware 2023)
• Downtime costs: $5,600 per minute for large enterprises
• Recovery costs: Domain rebuild can cost $500,000 - $2 million+

Indirect Business Impact

• Loss of customer trust and reputation damage
• Revenue loss during outage (average: 21 days for full recovery)
• Stock price impact: Average 7.5% decline post-breach announcement
• Legal fees and class-action lawsuits
• Increased cybersecurity insurance premiums (50-100% increase post-breach)

Insurance and Liability

• Cyber insurance may deny claims if "reasonable security controls" were not implemented
• Lack of documented tier model can be considered gross negligence
• Board members and executives face personal liability for inadequate cybersecurity governance

4. Case Studies: Real-World Consequences

Colonial Pipeline (2021)

• Compromised VPN password → full network access → ransomware
• Paid $4.4 million ransom, 6-day shutdown
• Impact: Fuel shortages across U.S. East Coast
• Root cause: No network segmentation or privileged access controls

Maersk / NotPetya (2017)

• Ransomware spread from single compromised system to 45,000 endpoints globally
• Cost: $300 million, 10-day complete shutdown
• Required reinstallation of 4,000 servers and 45,000 PCs
• Could have been prevented with tier boundaries and credential isolation

SolarWinds (2020)

• Compromised build environment → supply chain attack → 18,000 organizations affected
• Attackers had unrestricted access for 9+ months
• Estimated impact: $100 million+ for SolarWinds alone
• Congressional testimony emphasized lack of network segmentation

5. Mean Time to Recovery (MTTR) Comparison

• With Tier/Delegation Models: 24-72 hours to contain, 1-2 weeks to full recovery
• Without Models: 1-2 weeks to contain, 1-6 months for complete recovery (often requires full AD rebuild)
• Key Difference: Tier boundaries contain the breach to a specific zone, preventing complete domain compromise

6. Attack Success Rate Impact

• No Tier Model: 85% probability of full domain compromise if any privileged account is compromised
• With Tier Model: 15% probability - attacker must breach multiple layers and authenticate across tier boundaries
• Defense-in-depth created by tier boundaries increases attacker cost and detection likelihood by 10x

Bottom Line: The cost of implementing tier and delegation models ($100,000 - $500,000 for consulting, training, and initial deployment) is less than 10% of the average breach cost. The investment in these security models provides:

• 90% reduction in lateral movement capability
• 10x increase in attacker detection probability
• Compliance with regulatory requirements
• Reduced cyber insurance premiums
• Foundation for Zero Trust architecture

Not implementing these models is no longer a technical debate—it's a business risk decision with quantifiable financial and legal consequences. For implementation guidance, see AD Tier Model and Building the Delegation Model.

Even with strict tier boundaries and delegation models, legitimate scenarios arise where temporary exceptions or emergency access is required. Managing these exceptions securely while maintaining operational agility is critical. Here's a comprehensive framework:

1. When Are Security Exceptions Justified?

Legitimate Exception Scenarios:

• Critical Production Outage: Application failure requiring immediate cross-tier access to diagnose and remediate
• Security Incident Response: Active breach requiring forensic access across multiple tiers
• Disaster Recovery: Complete system failure requiring privileged access from non-standard locations
• Vendor Support: Third-party technical support requiring temporary elevated permissions
• Migration/Upgrade Windows: Major infrastructure changes requiring temporary broader access
• Audit and Compliance Activities: External auditors requiring read-only access to privileged systems

NOT Justified Exceptions (Always Deny):

• "It's faster this way" - Convenience is never a valid security exception
• "We've always done it this way" - Legacy practices must be modernized
• "The tool requires Domain Admin" - Find an alternative or redesign the architecture
• Permanent exceptions - All exceptions must have expiration dates

2. Exception Request and Approval Process

Formal Exception Request Requirements:

• Business Justification: Clear description of why the exception is necessary and business impact if denied
• Scope: Specific accounts, systems, and actions required
• Duration: Exact start and end time (maximum: 24-72 hours for most exceptions)
• Risk Assessment: Documented risks and compensating controls
• Alternative Analysis: Proof that standard processes were evaluated and are insufficient
• Approvers: Minimum two approvals from Security and Business stakeholders

Approval Workflow:

• Level 1 (Operational): Service Desk or Tier 1 Support - Can request, cannot approve
• Level 2 (Tactical): IT Manager or Security Engineer - Can approve routine exceptions (e.g., vendor support)
• Level 3 (Strategic): CISO or IT Director - Must approve high-risk exceptions (e.g., cross-tier access to Tier 0)
• Emergency Override: Two-person integrity required (e.g., on-call Security Manager + IT Director)

3. Time-Limited Access Implementation

Using Privileged Identity Management (PIM):

• Azure AD/Entra PIM for cloud resources: Request just-in-time role activation with approval workflow
• Microsoft Identity Manager (MIM) PAM for on-premises: Create time-bound membership in privileged groups
• Third-party PAM solutions: CyberArk, BeyondTrust, Delinea (formerly Thycotic)
• Automatic expiration: Access revoked automatically after approved time window (no manual cleanup required)

PowerShell Example for Time-Limited Group Membership:

# Grant temporary Domain Admin access for 2 hours
$User = "CONTOSO\john.doe"
$Group = "Domain Admins"
$ExpirationTime = (Get-Date).AddHours(2)

# Add user to group
Add-ADGroupMember -Identity $Group -Members $User

# Schedule automatic removal
$Action = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-Command Remove-ADGroupMember -Identity '$Group' -Members '$User' -Confirm:`$false"
$Trigger = New-ScheduledTaskTrigger -Once -At $ExpirationTime
Register-ScheduledTask -TaskName "Remove-$User-From-$Group" -Action $Action -Trigger $Trigger -User "SYSTEM"

# Send notification
Send-MailMessage -To "security@EguibarIT.local" -Subject "Temporary Privileged Access Granted" -Body "User: $User`nGroup: $Group`nExpires: $ExpirationTime"

4. Compensating Controls During Exception Period

Mandatory Monitoring and Logging:

• Enable verbose auditing on all accounts with exception access
• Real-time SIEM alerts for any actions performed during exception window
• Session recording for all privileged access (e.g., RDP session shadowing)
• Log all commands executed (PowerShell script block logging, command-line auditing)
• Notification to Security Operations Center (SOC) when exception access is activated

Additional Security Controls:

• Dual-Person Integrity: Require two people on bridge call during critical exception access
• Restricted Source IP: Limit authentication to specific management workstations or VPN gateways
• Read-Only First: If possible, grant read-only access first to diagnose, then elevate to write if necessary
• Change Freeze: During exception period, freeze all other changes to reduce variables
• Backup Before Action: Take snapshots/backups before any changes during exception window

5. Post-Exception Review and Audit

Immediate Post-Exception Actions (Within 24 Hours):

• Verify access has been revoked (automated checks, manual confirmation)
• Review all logs for actions performed during exception period
• Document actual actions taken vs. approved scope
• Identify any unauthorized or suspicious activity
• Reset passwords for accounts used during exception (if high-risk scenario)

Exception Analysis and Continuous Improvement:

• Monthly review of all exceptions: Identify patterns and frequent requesters
• Root cause analysis: Why was standard process insufficient?
• Process improvement: Update tier model or delegation to reduce future exceptions
• Training: Educate teams on proper escalation paths
• Metrics: Track exception frequency, duration, and approval times

6. Emergency Access Scenarios (Break-Glass)

When to Use Break-Glass Accounts:

• Complete MFA/authentication system failure
• All normal administrative accounts locked or compromised
• Critical infrastructure failure requiring immediate recovery
• Ransomware attack requiring isolated recovery operations

Break-Glass Account Procedures:

• Physical retrieval of password from secure safe (dual-authorization required)
• Immediate notification to CISO and Security team
• Real-time monitoring of all actions
• Post-use password reset and investigation
• Full incident report within 48 hours

For detailed break-glass implementation, see the FAQ: "What are break-glass accounts?"

7. Exception Management Best Practices

• Default Deny: Start with assumption that all exceptions are denied unless proven necessary
• Time-Boxing: Never grant indefinite exceptions - maximum 72 hours for most scenarios
• Least Privilege During Exception: Grant minimum permissions needed, not blanket Domain Admin
• Automation: Automate exception request, approval, provisioning, and revocation workflows
• Metrics and Reporting: Board-level reporting on exception frequency and trends
• Culture: Make exception requests painful enough to motivate fixing root causes

8. Tools for Exception Management

• ServiceNow: ITSM platform with approval workflows and time-based access
• Azure AD/Entra PIM: Just-in-time role activation with approval and MFA
• CyberArk: Privileged access management with session recording
• BeyondTrust: Privileged remote access with time-limited sessions
• Custom PowerShell/Scripts: For on-premises scenarios without PAM tools

Security exceptions are inevitable, but they must be rigorously controlled, logged, and reviewed. A mature exception management process demonstrates security maturity while enabling operational flexibility. The goal is to make exceptions rare, short-lived, and fully auditable. For more on emergency access, see Tier 0 Security.