Skip to content

Latest commit

 

History

History
756 lines (494 loc) · 32.5 KB

compliance.adoc

File metadata and controls

756 lines (494 loc) · 32.5 KB
Raw

Compliance Design Notes

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. (ISO27001 7.1, 7.2)

    • 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)

  • Create Teams top-level org and archetype? Pre-configure Cybersecurity team, as a target for some default rule. E.g. "Approval by security team" applicable policy, policy rule in Privileged classification (at least in example)?

  • Relations for read, write, admin. For fine-grain access control.

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))

    • enforcing different password for administrator personas (ISO 27001 8.2)

    • "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)

  • [/midpoint/features/planned/classification/] (ISO 27001 5.13, 5.8, 8.2)

    • Privileged classification for (application) roles and entitlements. Show that in GUI in prominent place. Document its use. Ability for connectors to mark entitlements as privileged. (ISO27001 8.2)

  • 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.

  • Notifications

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

  • Acceptable use (ISO 27001 5.10, 8.2)

    • 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.

      It is important to have this in classifications as well, especially the Privileged classfication - and apply that accordingly.

    • 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, 8.2)

  • 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, 6.6)

    • 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)

    • Pre-define certification (campaigns and micro) for privileged access rights.

  • Lifecycle state model

    • Make sure information erasure works (for privacy) (ISO27001 5.34, GDPR)

    • Select which assignments are considered active in archived state. E.g. we want to de-activate all organizational and role assignments, but we may want to keep clearances active, to indicate remaining responsibilities. E.g. people that were given access to intellectual property may have obligations to keep secrets even after their employment is terminated. There may be SoD for clearances, e.g. an employee that worked for client A cannot work for client B, not even in the future. It may be important to retain the clearance active even for archived users, as the user may be re-hired and re-activated. (ISO27001 6.5)

    • Select which assignments to keep in archived state ("termination of employment"). E.g. we want to keep org assignments in inactive state, we want to keep clearances (NDA) to indicate that the user has responsibility to keep secrets even after the employment was terminated. (ISO27001 6.5)

    • Selective "reaping" of archived objects. E.g. we want to keep ordinary archived users for 2 years, then delete them. However, if s user has valid NDA (clearance), we want to keep the record for as long as the NDA is valid.

  • 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

    • 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.

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

  • Step-up authentication and/or re-authentication in midPoint GUI. E.g. allow user to access end-user GUI with just a password. Require second factor (or re-entry of password) when entering administration zone. Clear indication in the GUI that we have administration privileges now. (ISO27001 8.2)

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

  • 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)

  • Temporary retention of privileges: temporarily keep user privileges (assignments) after organizational change. E.g. temporarily keep assignment to old organizational unit, to make sure all inducements are applied. Motivation: a person may still need to help with his old responsibilities after re-org. (ISO27001 6.5)

  • Per-role notification: we want to send notification to selected group of users when this role is assigned/unassigned. E.g. we want to notify all partners that we have new salesperson. Even more importantly, we want to notify partners when a salesperson leaves. (ISO27001 6.5)

  • Device management

    • Better device management? For management of mobile devices and BYOD. Device archetype, views, etc.? Pre-configured link to users. Management of technical accounts of access tokens for the devices, automatic revocation. (ISO27001 7.9, 7.14, 8.1)

    • Record classification level of the devices. Can we use some policy rules to use the classification? Can this be used to evaluate risk? E.g. user with lot of low-classification devices poses much more risk? (ISO27001 7.9, 7.14, 8.1)

  • Break-glass privileges: allow selected users to gain privileges by "breaking glass", an action in GUI initiated by the user. After "breaking glass", emergency privileges are assigned to the user for a limited duration. The "break glass" operation is recorded in the audit trail, metadata, and alarm is raised → priority notifications are issued to relevant "overseers" (e.g. security team). We usually do not want any complicated authentication for the "break glass" operation, we want to it be simple, easy to operate under stress or in panic (availability takes priority over confidentiality/consistency).

    Examples: Emergency access to system administrators/operators during security incident. Emergency access for medical staff to access medical records of a patient in order to save life. Access for emergency responders (e.g. voluntary firefighter team) to access some parts of infrastructure (e.g. to cut power to location) or enable physical access to rooms. (ISO27001 5.24, 5.26, 5.29, 5.30, 8.2)

  • On-demand privileges: allow selected users to gain privileges by "activating" them in midPoint GUI. Activation of the privileges may require additional authentication of the user, e.g. use of additional authentication factor. Activation of the privileges assigns the privileges to user for a limited period of time.

    The goal is to limit standing privileges, especially very strong privileges (such as superuser access to operating systems) that are not used often. As this mechanism is not used often and involves strong privileges, its activation may be quite demanding - it can take some time and may be reasonably inconvenient (confidentiality/consistency takes priority over availability). This mechanism is similar to "break glass", except that no alarm is raised (no priority notification). Use of on-demand privileges is normal operation, it is not an emergency.

    Examples: System administrator access to very powerful privileges, such as superuser accounts (root). Access of operators or power users to privileged actions that are rarely used, e.g. ability to explicitly start backup procedure or reboot a system. (ISO27001 5.15, 5.18, 8.2)

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)

  • Mark privileged access (ISO27001 8.2)

  • Avoid use of shared accounts (root) at all costs (ISO27001 5.16, 5.17, 8.2)

  • Use of entitlements for granting privileged access (e.g. ability to sudo) instead of giving access to privileged accounts (root). (ISO27001 8.2)

  • Certify all requested and manually assigned access. Combine micro-cert and campaigns. Set up micro-cert for privileged access on org change (can this be a default config?). (ISO27001 8.2)

  • Use personas for administrators, set a stronger password policy for admin personas. Use special intent and naming convention for admin accounts. (ISO27001 8.2)

  • Use password sync, make the password same on all resources - contrary to (ISO 27001 5.17 (D)). Explain why this makes sense intra-organization. Use admin personas to have different password for administration tasks.

  • Approve addition of privileged access (inducement) to active role. Approval by "Security team?"

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, 6.5

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, 8.3

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. Show assignments/unassignments of a particular privileged access (role).

ISO 27001 5.10, 5.27, 5.33, 5.34

Requirements not clear

Information classification

[/midpoint/reference/roles-policies/classification/]

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, 8.2

Done, needs improvement ([/midpoint/features/planned/classification/])

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. Role certification campaign, distribute to role owners (prioritize privileged access in roles).

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

ISO 27001 5.15, 5.18, 8.2, 8.3

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 (break-glass).

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. Automatically assign physical access token based on location. Reuse parts of the book.

ISO 27001 5.8, 5.18, 6.5, 7.2, 8.2, 8.3

Requirements quite clear

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, 8.2, 8.3

Requirements partially clear

Access certification

Set up annual certification campaigns for privileged access rights. Set up a micro-certification after org change. Use of outlier detection to provide guidance for certification decisions.

ISO27001 5.2, 5.15, 5.16, 5.18, 5.36, 6.5, 8.2

Requirements partially clear, but not complete

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

Delegated administration for suppliers/partners

Provide delegated administration config for suppliers/partners. We need org struct representing external orgs, and users that will be acting as admins for their orgs (authorizations). Admins can add/delete users in their orgs, and manage some basic access (e.g. make other users admins).

ISO27001 5.19, 5.20, 6.5

Requirements partially clear

Enforcing MFA

Make sure all people with remote access have MFA credentials enrolled, and have MFA enforced. Make sure people with privileged access have MFA too. Report people that violate this rule. Revoke remote access to people that violate this rule. Automatically provision MFA credentials/config to the roles that need MFA. We need SSO/AM server for this, use keycloak?

ISO27001 6.7

Requirements partially clear

Device management

Device inventory, manage access rights for devices (technical accounts). Assignments/linked objects to track ownership. Audit trail to log device transfers. Get list of PCs from AD, assign ownership. Record classification level of the device. Can we use some policy rules to use the classification? Can this be used to evaluate risk? E.g. user with lot of low-classification devices poses much more risk?

ISO27001 7.9, 7.14, 8.1

Not clear yet

Managing privileged access

Use of Privileged classification to mark privileged access. Make sure that only users that have passed advanced security training (clearance) can have privileged access. Making sure that all privileged access has additional approval step when assigned (inducement in Privileged classification). Notification "you have privileged access now" Reporting/dashboarding all users with privileged access.

ISO27001 5.15, 5.18, 8.2, 8.3

Somehow clear

Fine-grained access control

Use services to represent objects (file shares, spaces, documents). Use parametric roles with relations (read, write, admin) to control access to particular objects.

ISO27001 5.15, 5.18, 8.3

Somehow 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)

  • Use of personas for administrators. Use special intent and naming convention for admin accounts. (Add to "Managing privileged access" example?) (ISO27001 8.2)

More ideas:

  • Classifications based on TLP protocol (ISO27001 5.12, 5.13)

  • SANS classification scheme (ISO27001 5.12, 5.13)

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

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.

Note
 "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.

Docs Improvements

  • [/midpoint/features/planned/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?

  • Can we query for active assignments? We want direct assignments, therefore roleMembershipRef will not work. Can assignment effectiveStatus help?