Risk categorization on ad trust

 what would be defined as high risk in terms of trust


A trust should be treated as **high risk** when it meaningfully increases the chance of lateral movement, privilege escalation, or cross-boundary compromise, especially if it extends access between forests or to sensitive production environments.[1][2]

In practical audit terms, high risk usually means the trust weakens the security boundary, is difficult to monitor tightly, or depends on legacy settings and exceptions that expand exposure.[3][4]


## High-risk indicators

A trust is typically high risk if any of the following apply:[1][5][6]


- It is a **forest trust** or crosses a strong security boundary, because that expands the reachable attack surface.[1][2]

- It allows broad authentication rather than **selective authentication**, meaning users from the trusted side can authenticate to many systems by default.[5][6]

- **SID filtering** is disabled, weakened, or temporarily turned off for migration purposes.[4][7]

- The trusted environment has weaker security posture, unknown admin hygiene, or legacy systems that cannot be hardened.[3]

- The trust reaches **tier 0** assets, domain controllers, admin workstations, privileged groups, or production-critical applications.[3][6]

- The trust is used for business continuity or migration but has no defined end date or retirement plan.[6][8]

- There is limited logging, alerting, or periodic review of trust-related access and configuration changes.[6][9]


## Audit-friendly definition

You can define it like this in the document:


**High-risk trust relationships are those that cross significant security boundaries, provide broad or unrestricted cross-domain authentication, involve legacy or weakly governed environments, or create elevated exposure to privileged or production assets. Trusts configured without strong compensating controls, such as selective authentication, SID filtering, restricted administrative access, and enhanced monitoring, shall also be considered high risk.**[5][4][6]


## Practical classification

You can further classify a trust as high risk if it has one or more of these characteristics:[6][3]


- External or forest trust to a less trusted environment.

- Trust used by many users or applications rather than a narrow business function.

- Trust required for migration, coexistence, or legacy integration.

- Trust with privileged access paths across environments.

- Trust with repeated exceptions or overdue remediation.


## Suggested governance rule

A simple rule for your framework would be:  

**Any trust that crosses forests, touches privileged infrastructure, depends on legacy exceptions, or lacks selective authentication/SID filtering and strong monitoring shall be reviewed and classified as high risk until compensating controls are validated.**[5][4][6

**Trust Risk Classification**


| Risk Level | Definition | Typical Indicators |

|---|---|---|

| Low | The trust is narrowly scoped, well governed, and supported by strong technical and monitoring controls. | Limited business use, known trusted partner or internal boundary, selective authentication enabled where applicable, SID filtering in place, strong logging and periodic review. |

| Moderate | The trust introduces some additional exposure but remains manageable with documented controls and periodic oversight. | Broader user or application scope, partial legacy dependency, compensating controls in place, monitoring exists but may require tuning, review occurs at least annually. |

| High | The trust materially increases the likelihood or impact of unauthorized access, lateral movement, or privilege escalation. | Cross-forest or external trust, weak or missing selective authentication, SID filtering concerns, legacy or untrusted environment, access to privileged or production assets, limited monitoring, or repeated exceptions. |


You can also add this sentence beneath the table:


**Trusts classified as High risk shall be subject to enhanced governance, including formal approval, documented compensating controls, periodic recertification, and management review until the risk is reduced or the trust is retired.*


Comments

Post a Comment

Popular posts from this blog

AD trust register

An AD trust register should be a controlled inventory of every trust relationship in your environment, with enough detail to answer **what exists, why it exists, who owns it, and when it was last validated**. At minimum, it should capture the trust’s type, direction, transitivity, source and target domains/forests, and security settings such as selective authentication or SID filtering where applicable [1][2]. ## Recommended columns A practical trust register usually includes these fields: | Field | Purpose | |---|---| | Trust ID | Unique identifier for tracking and audit references. | | Trust name / target | The other domain or forest in the trust. | | Source domain / forest | Your side of the relationship. | | Trust type | Domain, forest, external, realm, etc. [3][1] | | Direction | One-way incoming, one-way outgoing, or two-way [3][2] | | Transitivity | Transitive or non-transitive [3][1] | | Authentication model | Selective authentication or forest-wide authentication [1] | | SID f...
Read more

Ad control catalog

  # Active Directory Security Framework Detailed Control Catalog ## Purpose This document is an expanded draft of the Active Directory security framework with individual controls listed under each control domain so the framework can be used as the basis for an auditable control register, control testing workbook, or management review package.[1][2][3] The control statements are designed to be tailored to the organization’s actual implementation status and evidence sources while retaining mapping to recognized standards and vendor guidance.[1][2][4] ## How to use this catalog Each control should be assigned a unique internal control ID, owner, implementation status, review frequency, and evidence source during the next draft iteration.[3][2] The standards mapping shown here is intended as a practical starting point rather than a legal or certification opinion, and it should be validated against the organization’s chosen compliance framework.[3][5] ## Standards basis This draft uses ...
Read more