craftvia/seed/isms-vorlagenpaket-v2-en/richtlinien/R08_Identitaets-und-Zugriffsmanagement.md

Policy Identity and Access Management

Document information	Value
Document type	Policy
Scope	{{ISMS_SCOPE}}
Organisation	{{ORG_NAME}}
Responsible	{{ROLE_IT_LEAD}}
Approved by	{{ROLE_MANAGEMENT}}
Version	{{DOC_VERSION}}
Date	{{DOC_DATE}}
Status	{{DOC_STATUS}}

1. Purpose

This policy governs means of identification, secure log-on, account management as well as the granting and control of access rights. It elaborates the information security policy ({{LINK:L00}}) and serves to meet the requirements of VDA ISA 2027.

2. Scope

This policy applies within the defined ISMS scope ({{ISMS_SCOPE_DESCRIPTION}}).

3. Requirements and implementation

Structure per section: Requirement (1:1 from VDA ISA; [MUST]/[SHOULD] and — where the protection need applies — [HIGH]/[VERY HIGH]) and Implementation at {{ORG_NAME}} (consolidated, to be adjusted where necessary).

3.1 Handling of means of identification

Requirement reference: {{#if FLAG_FW_TISAX}}VDA ISA 4.1.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.16{{/if}}

Requirement

{{#if FLAG_FW_TISAX}} {{#if FLAG_FW_ISO27001}}Requirements per VDA ISA 2027:{{/if}}

• [MUST] The requirements for handling means of identification throughout the entire lifecycle are determined and met; the relevant aspects are taken into account. {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Means of identification can only be created under controlled conditions. {{/if}} {{#if FLAG_HIGH_PROTECTION}}

• [HIGH] A strategy for blocking or invalidating means of identification in the event of loss is prepared and, as far as possible, implemented. (C, I, A) {{/if}} {{/if}}

{{#if FLAG_FW_ISO27001}} {{#if FLAG_FW_TISAX}}Requirements per ISO/IEC 27001:{{/if}}

• [ISO A.5.16] The full life cycle of identities is managed. {{/if}}

Implementation at {{ORG_NAME}}

Means of identification (user IDs, tokens, certificates) are assigned throughout the lifecycle uniquely to a person and under controlled conditions via the central directory ({{TOOL_IAM}}); issuance, withdrawal and blocking are requested, approved and documented in {{TOOL_TICKET}} (BL-IAM-07, see {{LINK:VA-03}}).

{{#if FLAG_ELEVATED_PROTECTION}}

Where the protection need is high, an implemented strategy for blocking/invalidating means of identification in the event of loss is in place. {{/if}}

3.2 Secure log-on

Requirement reference: {{#if FLAG_FW_TISAX}}VDA ISA 4.1.2{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.8.5{{/if}}

Requirement

{{#if FLAG_FW_TISAX}} {{#if FLAG_FW_ISO27001}}Requirements per VDA ISA 2027:{{/if}}

• [MUST] The user authentication procedures are selected on the basis of a risk assessment; possible attack scenarios (e.g. direct reachability via the internet) have been taken into account.

• [MUST] State-of-the-art user authentication procedures are applied. {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] The authentication procedures are defined and implemented on the basis of business and security requirements. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Users are authenticated at least by strong passwords in line with established and recognised practices. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] For privileged user accounts, higher-grade procedures are used (e.g. privileged access management, two-factor authentication). {{/if}} {{#if FLAG_HIGH_PROTECTION}}

• [HIGH] Depending on the risk assessment, authentication and access control are strengthened by supplementary measures (e.g. continuous access monitoring, strong authentication, automatic log-off, lock upon inactivity, brute-force prevention). (C, I, A) {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}}

• [VERY HIGH] Before accessing data with a very high protection need, users are authenticated by means of strong authentication (e.g. two-factor) in line with the state of the art. (C, I) {{/if}} {{/if}}

{{#if FLAG_FW_ISO27001}} {{#if FLAG_FW_TISAX}}Requirements per ISO/IEC 27001:{{/if}}

• [ISO A.8.5] Secure authentication technologies and procedures are used on the basis of the access restrictions and the access control policy. {{/if}}

Implementation at {{ORG_NAME}}

The authentication procedures are selected on a risk basis and correspond to the state of the art; password requirements per BL-IAM-01 (at least {{PW_MIN_LENGTH}} characters, {{PW_COMPLEXITY}}, {{PW_ROTATION}}) are enforced via the central directory ({{TOOL_IAM}}). For remote access, administrative access and cloud services, MFA (BL-IAM-02) is enforced via {{TECH_MFA}}; privileged accounts use higher-grade procedures (PAM).

{{#if FLAG_ELEVATED_PROTECTION}}

Where the protection need is high, authentication/access control are strengthened by supplementary measures (access monitoring, auto-logout BL-IAM-03, lock BL-IAM-04, brute-force protection). {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, access is only granted after strong authentication (two-factor).{{/if}} {{/if}}

3.3 User accounts and log-on information

Requirement reference: {{#if FLAG_FW_TISAX}}VDA ISA 4.1.3{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.17{{/if}}

Requirement

{{#if FLAG_FW_TISAX}} {{#if FLAG_FW_ISO27001}}Requirements per VDA ISA 2027:{{/if}}

• [MUST] The creation, modification and deletion of user accounts is carried out.

• [MUST] Unique and personalised user accounts are used.

• [MUST] The use of shared accounts is regulated (e.g. limited to cases where traceability is dispensable).

• [MUST] User accounts are deactivated immediately after the user leaves (e.g. upon end of contract).

• [MUST] User accounts are reviewed regularly.

• [MUST] The log-on information is provided to the user in a secure manner.

• [MUST] A policy for handling log-on information is defined and implemented; the relevant aspects are taken into account. {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] A base account with minimal access rights and functionalities exists and is used. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Default accounts and passwords preconfigured by the manufacturer are deactivated (e.g. blocking or password change). {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] User accounts are created or authorised by the responsible body. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] The creation of user accounts is subject to an approval process (four-eyes principle). {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] User accounts of service providers are deactivated after completion of their task. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Deadlines for deactivating and deleting user accounts are defined. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] The use of default passwords is prevented technically. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] In the case of strong authentication, the use of the medium (e.g. possession factor) is secure. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] User accounts are reviewed regularly; this also includes accounts in customers' IT systems. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Interactive log-on for service accounts (technical accounts) is prevented technically. {{/if}} {{/if}}

{{#if FLAG_FW_ISO27001}} {{#if FLAG_FW_TISAX}}Requirements per ISO/IEC 27001:{{/if}}

• [ISO A.5.17] Allocation and management of authentication information is controlled by a suitable management process. {{/if}}

Implementation at {{ORG_NAME}}

User accounts are managed via a defined lifecycle (joiner/mover/leaver) (see {{LINK:VA-03}}) uniquely personalised in the central directory ({{TOOL_IAM}}); triggers are {{TOOL_TICKET}} requests from HR/manager notifications. Accounts of leavers are deactivated without delay, accounts are reviewed regularly (including in customer systems), shared accounts are regulated. Log-on information is provided securely; default accounts/passwords are deactivated, base accounts with minimal rights are used, creation follows the four-eyes principle, and interactive log-on for technical accounts is prevented.

3.4 Access rights

Requirement reference: {{#if FLAG_FW_TISAX}}VDA ISA 4.2.1{{/if}}{{#if FLAG_FW_ISO27001}}{{#if FLAG_FW_TISAX}} · {{/if}}ISO/IEC 27001 A.5.15, A.5.18, A.8.2, A.8.3, A.8.18{{/if}}

Requirement

{{#if FLAG_FW_TISAX}} {{#if FLAG_FW_ISO27001}}Requirements per VDA ISA 2027:{{/if}}

• [MUST] The requirements for managing access rights (authorisation) are determined and met; the relevant aspects are taken into account.

• [MUST] The access rights granted for normal and privileged user accounts as well as technical accounts are reviewed regularly, also in customers' IT systems. {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Strategies for authorising access to information are prepared. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Authorisation roles are used. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Rights are granted according to the need-to-use principle and in line with role and/or area of responsibility. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] Normal user accounts do not receive privileged access rights. {{/if}} {{#if FLAG_INCLUDE_SHOULD}}

• [SHOULD] The user's access rights are updated after a change in their responsibilities. {{/if}} {{#if FLAG_HIGH_PROTECTION}}

• [HIGH] The access rights are approved by the responsible internal information officer. (C, I, A) {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}}

• [VERY HIGH] Information is stored encrypted at content level (e.g. file level) to prevent unauthorised access (including by privileged users). Where encryption is not feasible, equivalent measures apply. (C) {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}}

• [VERY HIGH] Existing access rights are reviewed at shorter intervals (e.g. quarterly). (C) {{/if}} {{/if}}

{{#if FLAG_FW_ISO27001}} {{#if FLAG_FW_TISAX}}Requirements per ISO/IEC 27001:{{/if}}

• [ISO A.5.15] Rules to control physical and logical access to information and assets are established and implemented on the basis of business and information security requirements.

• [ISO A.5.18] Access rights are provisioned, reviewed, modified and removed in accordance with the access control policy.

• [ISO A.8.2] The allocation and use of privileged access rights is restricted and closely managed.

• [ISO A.8.3] Access to information and application functions is restricted in accordance with the access control policy.

• [ISO A.8.18] The use of utility programs capable of overriding system and application controls is restricted and tightly controlled. {{/if}}

Implementation at {{ORG_NAME}}

Access rights are granted according to the least-privilege principle (need-to-know/least privilege) on a role basis (RBAC) via the central directory ({{TOOL_IAM}}); request, technical review and approval take place in {{TOOL_TICKET}} (see {{LINK:VA-03}}). Rights are updated or revoked upon change/removal and recertified at least {{RECERT_FREQ}} (BL-IAM-05), also in customer systems; default accounts do not receive privileged rights.

{{#if FLAG_ELEVATED_PROTECTION}}

Where the protection need is high, access rights are approved by the responsible internal information officer. {{#if FLAG_VERY_HIGH_PROTECTION}}Where the protection need is very high, information is stored with content-level encryption (protection also against privileged users) and access rights are reviewed at shorter intervals (e.g. quarterly).{{/if}} {{/if}}

4. Binding nature

This policy is binding for all affected roles within the scope. Compliance is monitored by {{ROLE_IT_LEAD}}.

5. Roles and responsibilities

Role	Responsibility in this policy
{{ROLE_IT_LEAD}}	Technical implementation of IAM
Business units	Approval of authorisations
{{ROLE_ISB}}	Monitoring

6. Review and update

This policy is reviewed at least {{REVIEW_CYCLE}} and on an ad-hoc basis by {{ROLE_IT_LEAD}} and approved by {{ROLE_MANAGEMENT}}.

7. Evidence

The evidence is not maintained in this document but centrally in the evidence register ({{LINK:NACHWEISREGISTER}}) and in the associated entries of the ISMS tool ({{TOOL_NAME}}).

8. Related documents

• Associated procedures: {{LINK:VA-03}}
• Technical security baseline: {{LINK:BASELINE}}
• ISA mapping matrix: {{LINK:ISA_MAPPING}}
• Evidence register: {{LINK:NACHWEISREGISTER}}
• Further: {{LINK:R02}}, {{LINK:R05}}, {{LINK:R10}}