Compliance Design Notes
Last modified 26 Apr 2024 12:22 +02:00
Table of Contents

This page contains design notes on compliance, thoughts, missing feature description, etc.

Configuration Changes

Changes we can make in 4.8 using configuration:

  • Archetypes

    • Project archetype and root org. Appropriate assignmentRelation for projects: members, managers, owners (stakeholders).

    • Location archetype and root org.

    • Organizational unit (or department/section/division? or have them as auxiliary/subtypes?) Can we also create root org (functional orgstruct)?

    • Organization …​ use this as a root org for `Organizational unit`s?

    • Asset? (variation of "App component" …​ or is it something different?)

    • "Top org container" for top-level orgs for projects and locations? Or we need special-purpose archetypes for this?

  • Compliance dashboard

  • Compliance reports

  • Pre-defined applicable policies:

    • Approval by manager (ISO 27001 5.15, 5.18)

    • Approval by role owner (ISO 27001 5.2, 5.15, 5.18)

    • Approval by application owner (ISO 27001 5.2, 5.15, 5.18)

    • Approval by security office? (Maybe create this only as an example) (ISO 27001 5.2, 5.15, 5.18)

  • Idea: pre-defined policySituation for "staff shortage" or "vacancies", such as no manager for project, less than two members of critical team, etc. Can be used in pre-configured dashboard.

  • Review database permissions. Can we make audit trail insert-only? (ISO27001 5.28)

  • Object mark "suspicious", can be used to mark objects for later investigation. (ISO27001 5.27, 5.28, 5.29)

Missing Features

(Roughly ordered by priority)

  • Password management

    • dictionary check: enabled by default? Not showing in GUI. (ISO 27001 5.17)

    • dictionary check for combination of dictionary words. (ISO 27001 5.17)

    • Forcing password change on next login: how can we make it easier to set up? (ISO 27001 5.17)

    • Closer integration with AM/SSO? Force password change, last login, etc. (ISO 27001 5.17)

    • enforcing different passwords on resources (ISO 27001 5.17 (D))

    • "users acknowledge receipt of authentication information" (ISO 27001 5.17)

    • (!!!) Force change of pre-configured administrator password on first login (ISO 27001 5.17)

    • "prevent the use of commonly-used passwords and compromised usernames, password combinations from hacked systems" (ISO 27001 5.17)

    • Guidance for end-users how to use password on pages that deal with passwords (ISO 27001 5.17)

    • Clean up documentation for password reset (it is in really bad shape)

    • Check that we use "approved cryptographic techniques for passwords" (encryption, hashing) (ISO 27001 5.17)

  • (!!!) Error messages and overall presentation of policy rule violations. Current error message looks like:

    No assignment exists for role 09360ff0-d506-4751-b13f-4e01422693ac (after operation)

    Overall, the presentation of policy rule violations should be re-thought and significantly improved. (ISO 27001 5.2, 5.3, 5.8, 5.9, 5.12, 5.13, 5.14)

  • Classification Improvements (ISO 27001 5.13, 5.8)

  • Policy rules

    • requirement constraint (ISO 27001 5.13, 5.8)

    • Nicer messages when violated

    • min/max assignees: considering all users or active users (ISO27001 5.36)

  • midScribe documentation (ISO27001 5.31)

  • Negative assignment ("exception from rule") (ISO27001 6.4)

  • Approval improvements

    • Rule of 4 eyes: requestor cannot be approver, even if he is specified as approved in the policy (ISO 27001 5.15, 5.18)

    • Handling of situation when there are no valid approvers, e.g. in case the "rule of 4 eyes" disqualified the only approver. (ISO 27001 5.15)

  • Idea: Initial configuration wizard, executed at first login of administrator after installation.

    • Change administrator password (if it was not generated)

    • Ask for name of organization, set up root object for organizational structure

    • Ask for basic archetypes to use? E.g. employee, student, etc.

  • Privileged access (ISO 27001 5.15, 5.18, 8.2)

    • Make Privileged Access label (classification) much more visible in GUI. Display it at prominent location in details page, maybe find a way how to mark it in lists. Mark privileged access in certifications. (ISO 27001 5.18)

    • Mark for "Privileged access", applied to all objects that deal (directly or indirectly) with privileged access. Can be used in searching or GUI.

    • ConnId pre-defined attribute PRIVILEGED_ACCESS, can be used for groups such as Domain Administrators or accounts such as root.

    • Ability to set Privileged Access classification on application roles that originated from groups marked as privileged by the connector.

  • Acceptable use (ISO 27001 5.10)

    • termsOfUseStatement as a property of all abstract roles and resources (polystring). Can be used especially in applications, delivering the statement to user when gaining access.

    • New notification event, triggers when gaining access to something (e.g. first assignment of application). Can be used to deliver the acceptable use statement using notifications. Pre-configuring notifications for this. (higher priority) (ISO 27001 5.10)

    • Provide ability to inform user in GUI when gaining a privilege, asking user to confirm acceptance of terms before assigning the privilege. Can be also used for acceptance of "terms of service" by end user before access to the service can be activated. Can be done ex-ante in shopping cart before submitting request, or ex-post as part of "activation" of the privilege. Note: Similar flow to GDPR consent. (lower priority) (ISO 27001 5.10, 5.19)

  • Certifications

    • GUI: Easy certification of clearances and classifications: easy to select scope (all clearances, specific clearance/classification, etc.) (ISO27001 5.12, 5.13, 6.1, 6.3)

    • Certification of other parts of (abstract) role, most notably policy rules. For ISO 27001 5.12, re-certification of policy rules included in classification definitions. (ISO27001 5.12)

    • Action button: replace assignment. Used to replace classification (e.g. change Cat.II system to Cat.III). The goal is not to remove the assignment, the goal is to keep the assignment. However, target of assignment may be different (better). The policy should make sure that there is at least one assignment of specific type (e.g. classification) after the campaign is done. (ISO27001 5.12, 5.13)

    • Make sure that the campaign can be started automatically, e.g. every year. Used to make sure a review policy is automatically enforced, e.g. make sure clearances are reviewed every year. (ISO27001 6.1, 6.3)

    • Make sure certification history is kept in some permanent place. E.g. we need to prove to an auditor that we have re-certified clearances every year. (ISO27001 6.1, 6.3)

  • Making sure that certain requirements are fulfilled before assignment is assigned or activated. (ISO 27001 5.12, 5.13, 5.14, 5.20)

    • Making sure user has enrolled multi-factor authentication before accessing classified system.

  • Make sure we can read number of failed login attempts from the resources (CZ NIS 2)

  • Shared accounts (ISO 27001 5.16 (b))

  • Introduce "asset" as a first-class citizen in midPoint (later, in synergy with risk assessment).

  • Risk model

  • Risk control related to external identities (social login) (ISO 27001 5.16, 5.19, 5.17)

  • Support for passkeys and other non-password credentials? (ISO 27001 5.17) (ISO 24760)

    • Default risk of application role may be given by application information label, e.g. all category III applications imply high risk for their application roles.

  • Improve instructions on initial password delivery and self-service password reset

Feature Ideas

Nice to have features:

  • Mark reference to compliance frameworks (e.g. ISO or NIS2) in midPoint objects (e.g. reports). Could be used by GUI to display "This is part of NIS2 compliance". Also mark references to legislation/regulations in custom objects (e.g. classification levels). Use for searching, demonstrating which mechanisms are used for compliance. (ISO27001 5.31)

  • Mark reference to business processes or capabilities ("business reference"?). This could be used to list all configurations that relate to a particular process, e.g. when that process is reviewed or audited. Can the "business process" be modeled as service, using assignments as references? How does it relate to midScribe? (ISO27001 5.31)

  • Compliance checklist: dashboard-like page, that checks for presence of configuration for individual compliance frameworks. (ISO27001 5.31) E.g. it can check for:

    • Do we have password policy applied? Is it strong?

    • Certification campaigns, are they configured and active?

    • If access request is enabled, do we have approval policies?

    • Do we have owners for entitlements (application roles)? How many (percent)?

    • SoD policies, do we have them? How many are enforced (percent)?

    • Do we have business roles? How much access is covered by business roles (percent)?

    • Do we have classification scheme configured? How much access has classificiation labels?

    • Do we have clearances set up? How many?

    • Do we have risk management (risk scores) set up? How many?

    • Warning if administrator account is enabled and password was not changed since installation (use password change timestamp).

    • Warning if administrator account is enabled and has weak or well-known password.

    • Warning if administrator account is still used (if it was logged-in recently).

    • Warning if HTTPS is not used.

  • Self-certification. User has to certify its own assignments. User has to confirm that he still needs the privilege. Maybe as a "zero" stage of regular certification?

    Important: do not update certification timestamp in this case (or use separate timestamp). This is not a formal certification, it is just a way to informally clean-up access. The access was not reviewed by another person in this case.

  • Emergency mode (see Incident response in notes below). (ISO27001 5.24, 5.29)

Recommendations

Recommendations for midPoint deployments:

  • Audit: appropriate settings for audit log retention. Safe storage of audit trail, ensure non-tampering. Also: safe archival of audit trail. (ISO27001 5.28)

  • Log collection: use log server to centrally collect the logs (ISO27001 5.28)

  • Conduct controlled (manually initiated) full synchronization of all systems after an incident. Purpose: make sure there are no extra accounts or privileges, either created by an attacker, or leftovers from incident response. (ISO27001 5.24, 5.27, 5.28, 5.29)

Examples and Configurations

Examples and configuration recommendations that we need to prepare:

Name Description Controls Status

Policies for information security

How can midPoint reports help with preparing of security policies? All policies, all special cases (exceptions), all policy violations, access included in/from roles, …​

ISO 27001 5.1

Requirements not clear

Application and role governance

Setting up role owners, application owners, security office team. Using pre-defined "applicable polies" to set up approval. Setting up basic orgstruct, setting up approval by manager. Set up certification campaigns, considering role/application owners and managers. Use minAssignees policy rule to mark roles that are not assigned to anyone, e.g. in case that we have no auditor, or we have less two members of security team (no peer redundancy).

Overlap with "Application/asset management", should we merge?

ISO 27001 5.2, 5.15, 5.18

Requirements quite clear

SoD policy enforcement

Setting up SoD policy rules, applying gradual enforcement: do not enforce, just report, clean up violations, finally go for full enforcement. Use dashboard to monitor progress.

ISO 27001 5.3

Requirements clear

Project management

Use pre-defined archetype and org root to create a project, assign manager, assign members, specify access rights for manager and members. Authorizations for project manager to modify project (maybe members). Set up AD project groups. Set general policy for all projects at the archetype level, e.g. setting policySituation for all projects that do not have a manager. Include information classification.

See also "Automatic management of access rights".

ISO 27001 5.8, 5.12, 5.13, 5.14

Requirements somehow clear, need more work

Application/asset management

Setting up application inventory, specifying owners and classifications for applications. Use dashboard to find applications/roles without owners/classifications.

Overlap with "Application and role governance", should we merge? Should we specialize this example for use of dashboards?

ISO 27001 5.9

Requirements not clear

Audit log retention and analysis

Set up appropriate retention of audit log data (limiting size, also for privacy). Use audit log viewer and object history to find access rights of a person in the past? Use audit log viewer to review emergency actions of administrators during incident response. Use metadata as easier and faster way to access historical data. Show that metadata remain even if detailed audit trail is deleted.

ISO 27001 5.10, 5.27, 5.33, 5.34

Requirements not clear

Information classification

Information Classification and Clearances

Improvements: external access (5.14), include the clearance in archetype+NDA, certification, set up distribution lists for all users of Cat.III systems (to spread awareness).

ISO 27001 5.12, 5.13, 5.14, 5.20, 6.1, 6.3

Done, needs improvement (Classification Improvements)

Delegated business role maintenance

Delegate creation and maintenance of business roles to business users, using role wizard. Use "applicable policies" to set up access-and-approval scheme. Use pre-congifured policies for app-owner and role-owner approval, setup of approval by manager.

Overlap with "Application and role governance", should we merge?

ISO 27001 5.15, 5.18

Requirements not clear yet

Incident response

Preparation: Use reporting to estimate effects, e.g. how many users will be affected when SSO system is breached? Use simulations to predict effects of incidents, e.g. what access would attacker gain if he gets role Foobar? Pre-configure emergency privileges for incident responders team, as non-active (conditional) inducements.

Containment: Quickly enable emergency privileges for responders. Manually deactivate a user, e.g. after he was fired. We do it manually, because HR recon is slow. Containment phase: disable access to suspected users. Analysis: list all users of particular vulnerable application. Force password change for a large number of users. Incident information: send notification to all affected users.

ISO 27001 5.17, 5.18, 5.24, 5.25, 5.26, 5.27, 5.28, 5.29

Requirements not clear yet

Automatic management of access rights

Inducement from orgstruct and location, role autoassignment, org template autoassignment. Reuse parts of the book.

ISO 27001 5.8, 5.18

Requirements quite clear

Orgstruct automation

Inducement from orgstruct. Micro-certification on orgstruct membership change.

ISO 27001 5.18

Requirements incomplete, need to add more

Deployment documentation

Document which configuration is used to implement compliance with ISO or NIS2. Ideally, refer to specific controls and business processes. Use this information to find configurations that need review when requirements change.

ISO 27001 5.31

Requirements incomplete, design incomplete (business reference)

Identity lifecycle and privacy

Apply lifecycle states to identity (users), controlling information in each step. Use "proposed" state for users that are not yet ready to get privileges (e.g. have not passed basic screening yet). Keep archived users to avoid re-use of identifiers and e-mail addresses. Making sure user is properly and automatically deprovisioned. Especially use the "archived" state, setting up limited access to archived user data, possibly reducing the data for privacy (erasure). Use of assignment as "legal basis", demonstrating that the identity is deprovisioned if we do not have any legal basis. Document the legal basis in roles (use midScribe). Use of classification/location to limit transfer of information? Keep data of EU users in EU applications. Use "suspended" state to temporarily disable a user, e.g. for maternal leave, during incident investigation or as an extreme disciplinary action.

ISO 27001 5.16, 5.18, 5.33, 5.34, 6.1, 6.4 GDPR

Requirements partially clear

Re-certification of clearances, screenings and trainings

Use re-certification campaigns to re-evaluate clearances.

Use a long-running campaign to manage security re-training. The decisions in the campaign will indicate whether a person have passed training. The goal is not to remove the privileges, the goal is to make sure all trainings are renewed.

ISO27001 5.12, 6.1, 6.3

Requirements partially clear

Fit into some scenarios:

  • Deliver "welcome" message for new users, including information about policies and acceptable use. Deliver especially to external e-mail addresses (suppliers, contractors). (ISO 27001 5.10, 5.19)

  • Deliver "acceptable use" statement to user when account is created on a system (notifications). (ISO 27001 5.10)

More ideas:

  • Managing privileged access: using the "Privileged access" classification

  • Classifications based on TLP protocol

  • SANS classification scheme

  • Concrete and complete examples on password management, including initial password delivery and self-service password reset

Reports and Dashboards

  • All policies (ISO 27001 5.1)

  • All policy violations (ISO 27001 5.1)

  • All special cases (approved exceptions from policy rules) (ISO 27001 5.1?, 5.2)

  • SoD policies: all roles with SoD exclusions. All SoD policy rules. Nice to have: all roles that are subject to SoD policy rules (even indirectly). (ISO 27001 5.3)

  • SoD violations (ISO 27001 5.3)

  • SoD exceptions (approved violations) (ISO 27001 5.3)

  • Roles without owners. Application roles without owners. Business roles without owners. Etc. (ISO 27001 5.2)

  • Applications without owners. (ISO 27001 5.2, 5.9)

  • Applications without classification. (ISO 27001 5.9, 5.12, 5.13, 5.14)

  • Requestable roles without approvers. (ISO 27001 5.2, 5.15, 5.18)

  • Active projects without managers (ISO 27001 5.8)

  • Staff shortage (dashboard): projects and teams with vacancies at important positions.

  • Orphaned accounts (ISO 27001 5.16)

  • Identities with privileged access

  • Number of active users (dashboard only?) (ISO 27001 5.16)

  • Number of archived users (dashboard only?) (ISO 27001 5.16)

  • Dormant users / sleepers (users without any privileges) (ISO 27001 5.16)

  • Temporarily inactive users (exclude archived users) (ISO 27001 5.16)

  • "Standing privilege" - manual assignments, including access request (ISO 27001 5.15, 5.18)

  • Privilege assignments to review - manual assignments that were not certified recently (ISO 27001 5.18)

  • Suspicious objects (ISO27001 5.27, 5.28, 5.29)

  • Manual data overrides (fixed HR errors)

  • Users without organizational assignments (no org, no project, …​)

  • Number of all accounts (all resources) (ISO 27001 5.32)

  • Number of active accounts (all resources) (ISO 27001 5.32)

  • Number of active accounts per resource (e.g. for license management) (ISO 27001 5.32)

  • Unused accounts. Accounts not used for X months. (ISO 27001 5.32)

  • Organizational units without managers

  • Number of job titles

  • Top job titles

  • Number of locations

  • Largest locations by number of users

RBAC

  • Number of roles by type (ISO 27001 5.1, 5.15, 5.18)

  • Access included in roles (%) (ISO 27001 5.1, 5.15, 5.18)

  • Identities with access from roles (%) (ISO 27001 5.1, 5.15, 5.18)

  • Unused roles (roles without active assignment) (ISO 27001 5.1, 5.15, 5.18)

  • Idea: some role hierarchy metric? How many roles are included in other roles?

Audit

  • All accounts created/deleted on resource (ISO 27001 5.10, 5.16, 5.18)

  • Roles assigned/unsassigned, automatically/manually (ISO 27001 5.10, 5.16, 5.18)

  • Password changes

  • Access requests

  • Authentications (to midPoint)

  • REST service access

  • Provisioning operations

Later:

  • High-risk roles

  • High-risk users

Usage:

  • Application that were not used recently.

  • Vastly over-provisioned applications. Applications that are used only by a small fraction of users that have access to them.

"Without owner" should really mean "without active owner". Only active users should be considered valid owners.

Misc and Notes

  • "License management" as formal feature? (ISO 27001 5.11, 5.32)

  • Should we pre-configure top-level org "Suppliers", to allow creating of supplier organization entries? (ISO 27001 5.19)

  • Running an action for all users of an application, e.g. notifying them about an incident, forcing them to change passwords.

  • We really should recommend to always use midPoint with SSO/AM, and MFA, which avoids lots of password problems.

  • Incident response

    • Use conditional roles to pre-configure emergency privileges for incident response. Q: what will trigger the condition? How to make sure such roles (their members) are automatically recomputed to immediately gain the privileges. Note: this may work both ways, granting more privileges to security staff and revoking some privileges to risky user populations (e.g. disabling external access on AM server). (ISO27001 5.24, 5.29)

    • Emergency mode: global mode, can be turned on by authorized users. It enables pre-defined elevated privileges for security and business continuity staff. All operations that happen during emergency mode have a special mark in the audit trail, can be used to investigate the incident. All assignments, accounts and associations that are created during emergency mode are marked. They can be discovered after the incident and cleaned up. This should also apply to role modification and possibly other operations. (ISO27001 5.24, 5.29)

      Probably needs several modes: security incident, disruption, natural disaster, …​

    • Guide: "Incident response with midPoint", recommending individual steps (containment, escalation, …​), referencing ISO controls.

  • ISO 27001 is often referencing "assets", which in our parlance refers to application. This makes the policies quite application-centric, rather than role-centric. E.g. approval by application owners, rather than role owner.

  • Methodology: Locations as orgs. Strongly recommend use of org-based locations (possibly hierarchical), can be used to directly assign policies using inducements.

Work Done So Far

Docs Improvements

  • Compliance (old page, needs update)

  • Link features to IGA capabilities

  • ISO27001 controls: show "Implementation plan" section (when we are ready)

  • Link ISO27001 controls to IGA capabilities?

  • Show ISO27001 control category, type (e.g. #preventive), concepts and other attributes? Is it legal? (copyright)

  • Highlight ISO27001 controls that are closely related to IGA (capability==#Identity_and_ac- cess_management?)

Open Questions

  • New abstract role subtype "Policy"?

  • How to determine classification of a role from classifications of sub-roles and applications? Similar mechanism should be used to determine risk levels.

  • How to make "SoD policy" report?

  • Licence management as a feature? (ISO 27001 5.11) What do we need to do? License archetype?

  • Certification for classifications: replacing assignment of classification, instead of removing it?

Was this page helpful?
YES NO
Thanks for your feedback