IT Security
Security concepts, architecture diagrams and role models describe intended controls; they do not directly prove the productive state. A technical examination therefore reconstructs identities, authentication methods, roles, group memberships, inherited permissions and configuration paths from the systems that actually enforce access.
Short answer
The central distinction is between the intended security model and the effective configuration. A role can look restrictive on paper while group inheritance, application defaults, database grants or service-account permissions produce a broader effective access path.
Authentication answers who or what can establish an identity. Authorization answers what that identity can do after authentication. These layers, together with configuration and change history, should be examined separately.
1. Separate the target concept from the actual configuration
Documentation is a reference, not the productive state
Policies, architecture diagrams, access-control matrices and operating procedures are useful reference material. The actual state is reconstructed from configuration files, IAM systems, directory services, cloud policies, database privileges, application roles and, where appropriate, reproducible access tests.
The applicable time is also important. A current role model cannot automatically be projected onto a historical incident or project milestone. Configuration exports, audit trails and infrastructure-as-code revisions can help determine which state applied at the relevant date.
Differences are classified as technical deviations first. Whether a deviation constitutes a policy, contractual or regulatory breach is a separate assessment.
2. Identities and authentication
Human and machine identities should be distinguished
Users, administrators, service accounts, API clients, workload identities and emergency accounts can follow different authentication paths. The examination records which identities exist, how they are provisioned and whether they are active, shared, federated or locally managed.
Authentication factors, token lifetimes, key material, credential rotation and privileged login paths can affect the risk of an identity. A documented requirement for multi-factor authentication is not equivalent to evidence that MFA was enforced on every relevant path.
Technical tests should avoid turning credential verification into unnecessary privilege use. The objective is to establish the configured authentication path and relevant exceptions within the authorised scope.
3. Authorization and effective permissions
Effective access can arise through several layers
Permissions can be granted directly, inherited through groups, derived from roles, created by resource policies or expanded by application-specific rules. The examination therefore calculates effective rights rather than relying only on one administrative screen.
Cross-system paths matter. A user with permission to modify a CI/CD pipeline may indirectly be able to influence a deployment even without direct production-shell access. Likewise, a service account with broad database rights may create a different risk than its application role suggests.
Where feasible, a permission matrix can map identity → role/group → technical control → resource → allowed action. The matrix makes hidden inheritance and inconsistent restrictions visible.
4. Configuration changes and traceability
The change path is part of the security state
Access changes can arise through directory administration, infrastructure-as-code, cloud consoles, database commands or application administration. Audit records, commits and configuration histories can show when a permission changed and through which control plane.
Logging of user, role and privilege changes can support reconstruction, but only if the relevant events were configured and retained. Missing logs are treated as a limitation rather than proof that no change occurred.
Unapproved or undocumented changes can be technical findings. The reason, responsibility and legal consequence of such a change are separate questions.
5. Technical assessment and limitations
Broad permission is not automatically equivalent to misuse
A technical assessment can state that an account has a defined effective permission, that a control is absent, or that a documented restriction is not implemented as described. It cannot infer actual misuse merely from the existence of the permission.
Least privilege can be used as a technical reference concept, but the required permission set still depends on system function and operating model. The examination therefore avoids labelling every broad role as defective without analysing why the access exists and what it enables.
Sampling and incomplete visibility must be disclosed. SaaS platforms, external identity providers and managed services can contain control layers that are not fully visible from one tenant export.
6. Effective permission matrix and path analysis
Access paths should be represented end to end
For complex systems, the most useful result can be a path-oriented model rather than a list of roles. A path may start with an identity, continue through group membership or federation, reach an administrative interface and then enable an action on a protected resource.
Conflicting grants and denials, role precedence and conditional policies should be resolved according to the actual platform semantics. A theoretical permission that is blocked by an enforced condition is different from a permission that is immediately usable.
The final matrix should identify verified paths, unresolved paths and assumptions. This makes the boundary of the examination visible to later reviewers.
Is the access-control finding based on the effective system state?
- Is the intended access-control model distinguished from the observed productive configuration?
- Are human, service and machine identities included where relevant?
- Are authentication methods and privileged login paths identified?
- Are direct, inherited and conditional permissions resolved to effective rights?
- Are cross-system administrative paths such as CI/CD or cloud control planes considered?
- Are configuration and privilege changes traceable for the relevant period?
- Are missing logs or inaccessible control planes treated as limitations?
- Does the conclusion avoid inferring misuse merely from the existence of permission?
Constructed example
A role matrix states that developers cannot modify production. The examination confirms that developers have no direct production login but finds that one developer group can edit a deployment pipeline whose service account has production privileges. The result documents this indirect access path rather than describing only the interactive login controls.
Audit data show that the pipeline permission was removed later. Because the earlier policy export is incomplete, the exact start date of the broader permission remains uncertain and is reported as such.
The example is entirely constructed and does not describe a real engagement.
Sources and technical basis
- Official technical guidance NIST SP 800-53 Rev. 5, including Access Control, Identification and Authentication, Configuration Management, and Audit and Accountability control families. Open source.
- Author methodology Sources and Methodology of the German knowledge base, used for the separation of evidence, interpretation and limitations. Open source.
- Official technical guidance BSI minimum standard on logging and detection, including logging of user, rights and privilege changes. Open source.
Further reading
- Network Boundaries and Exposed Services
- Technical Analysis of Log Data
- Reconstructing a Security Incident
- Examining Vulnerabilities in IT Systems
Critical review and methodological limitation
An access-control review is state-dependent. Documentation, IAM exports and application configuration can each describe different layers, and the effective path can only be understood when those layers are connected.
The existence of a permission establishes capability, not actual use. Conversely, failure to observe one access path does not prove that no alternative administrative path exists.
- Target vs actual: policies describe intent; system configuration determines effective technical access.
- Identity vs action: authentication of an identity does not by itself prove which person performed an action.
- Permission vs misuse: technical capability and actual use must remain separate findings.
Translation and methodological scope
This English article is based on the reviewed German V1 source article. The translation preserves the technical meaning, methodological distinctions, source status and stated limitations. It does not strengthen technical findings into legal conclusions and does not treat technical references as proof of compliance or suitability for a specific system.
Author's technical literature and publications
The following works provide additional technical and methodological context. They do not replace required primary sources, standards, manufacturer documentation or other independent specialist sources. Unpublished manuscripts, drafts and teaching materials are deliberately not presented here as public sources.
IT Security Assessments
Technical examination of vulnerabilities, configurations, log data, incidents and documented security measures.
Explore this assessment service