Compliance Design Notes
Last modified 26 Jul 2024 17:02 +02:00
Table of Contents

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

Configuration/Schema 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, 8.6)

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

  • Underassigned: Pre-defined mark for "understaffed", "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. (ISO 27001 5.2, 5.8, 8.6) ✓

  • Understaffed security: Pre-defined mark for staff shortage in security-related role or organization. Can be used in pre-configured dashboard. As opposed to regular Underassigned mark, this can be used in dashboards with higher severity, as security-related shortage is likely to pose high risk. (ISO 27001 5.2) ✓ (TODO: document)

  • Information security classification to mark all roles, apps and services that are related to information security. For roles and orgs there will be default minAssignee policy rule for Understaffed security mark. For orgs, we will need an "understaffing" rule for manager as well. Maybe we can add rule for additional approval of role assignment by the security office? At least document such scenario in docs. (ISO 27001 5.2)

  • Compliance dashboard ✓ (TODO: document)

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

  • minAssignee policy rule for owner in Business role archetype?

  • Default policy rule for roles checking whether role/app has an owner. TODO: which mark to use? Understaffed does not seem appropriate. Maybe Neglacted or Unowned?

  • Environment (devel/test/prod) demarcation for ServiceType (mostly applications). "displaying appropriate environment identification labels in menus to reduce the risk of error" [ISO27001 8.31]

    Probably create Environment archetype for orgs (and root org as well, with pre-defined devel/test/prod), which is assigned to services (applications). Also apply to resources (ResourceType) and midPoint itself (SystemConfiguration?). How can application "inherit" environment from resource? However, we need option for application not to "inherit" environment, e.g. we can have testing apps that still use production AD for authentication. Inducement from app to resource, could this work? (ISO27001 8.25, 8.27, 8.31, 8.33)

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

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

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

  • Extend application/asset schema. It should include: (ISO 27001 5.9,8.8)

    • software vendor

    • software name

    • version numbers

    • current state of deployment (designed/devel/test/production/…​)

    • Link to app entry point?

    • Maybe: installation target? Where is the app installed?

    • Later: reference to SBOM or other fine-grained BOM/versioning data.

  • Classification for Emergency access? Similar to privileged access.

  • Classify security-relevant roles "Information security responsibility" ✓

  • Marks

    • Unclassified - applications without classification + policy rule (in Application archetype?)

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)

    • maximum number of password changes per time (e.g. per day) (ENISA-baseline)

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

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

      • Privileged classification for (application) roles and entitlements. Document its use.

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

      • Allow to search users/roles that have this classification. Set up reports/dashboards.

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

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

    • Better GUI. E.g. enforce action is not even shown in current GUI.

    • Show evaluated policy rules or marks in GUI. E.g. I want to see that role has violated minAssignee constraint when I look at role details.

    • Policy rule exceptions and exception approvals - make sure they work. Use cases: SoD exceptions, classification violation exceptions, clearance exceptions. (ISO 27001 5.3, 8.7)

    • Policy rule exception validity, i.e. exception for a short time period. (ISO 27001 5.3, 8.7)

    • Policy rule exception review (certifications) (ISO 27001 5.3, 8.7)

    • Index/search all objects that have policy rule (specific constraint, markRef and enforcement)

    • minAssignments/maxAssignments constraints? E.g. applications without classification

  • Marks

    • Marks should have a "retention" setting, specifying whether the mark could be cleared automatically (e.g. by policy rule going "off"), or it should be retained until cleared manually by system administrator. This would be useful for marking objects with modification constraint, policy rule setting the mark, but it has to be manually cleared when modification is reviewed. It may be also useful for setting up policy rules that set suspicious mark for some combinations of states/attributes (also as "modification" constraint). We want to retain that mark until it is manually reviewed and cleared.

    • Marks could have "warning" setting. If active, GUI would warn user that object has a mark - or that an operation results in object getting a mark. The warning will be displayed after the operation is completed, or on preview page. E.g. assigning a conflicting role resulted in "exclusionViolation" mark. E.g. removing a classification assignment from an application did result in getting "unclassified" mark on object.

    • The "warning" setting could influence how prominently is the mark displayed in the GUI, e.g. whether it should be shown in object lists, object details, summary panels, etc.

  • GUI

    • Show marks in object details

    • Better support for custom assignment panels. E.g. show assignments with particular archetype (classifiation,clearance), also the "assign" button should only list targets of that archetype.

    • Dashboard widgets that can show/list objects of generic types, such as AssignmentHolderType or AbstractRoleType, or even ObjectType. Currently, these widgets do not have the "More info" link to list objects.

    • Default column for roles: "number of members" instead of "projections"

    • Default column for application roles: application

    • Default column for applications: "owner" instead of "projections"

    • Default column for applications: classification

    • Better GUI for policy rules. E.g. enforce action is not even shown in current GUI.

    • Clearly show that particular access is privileged, use special label, mark, icon whatever.

    • Nicer icon for Application archetype. Cloud icon means stock Service, we should distinguish application somehow.

    • Show classifications in access request and approvals. (ISO27001 5.13)

    • More information for widgets: some way how to get more detailed description of widget, explaining what the widget shows. Maybe tooltip? Maybe something longer? Maybe click on "more info" should show description (with some nice icon) on top of the search list?

    • "Back" button is missing when clicking on dashboard widget "more info" link.

    • Separators/rows in dashboards, or some other ways to organize widgets (nice to have)

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

  • 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 and use last login from the resources (e.g. report unused accounts/users)

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

  • Sync mechanism or mapping that is summarizing (adding up) values from projections, e.g. total number of failed login attempts across all accounts.

  • Application inventory / assets

    • Finish concept of "application inventory", how it is supposed to be used normally, what data we want to store about applications, do we want to sync data to midPoint, or is midPoint going to be authoritative …​ what is the common case? Also, relation to classification and other ISO controls and features. We have to finish this, otherwise we have strange things in GUI such as confusing "Inventory records" label for application projections.

    • Introduce "asset" as a first-class citizen in midPoint (later, in synergy with risk assessment). What is relation to asset to application? Is is (is it related to) the "Application component" concept that sometimes use?

  • Shared accounts (ISO 27001 5.16 (b))

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

  • "Comparative" mappings: mappings that can detect and report that a value was changed on resource. They do not necessarily change the value. This can be used for preparing midPoint deployment, assessing the changes that midPoint would do (note: this can be partially provided by similations). It may be used to detect and report policy violations (on ongoing basis). It may be used to detect local changes by system administrator. (ISO 27001 8.9)

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

  • Alerting: ability to send alerts (high-priority notifications) to users, and also to other systems (SIEM, threat detection): a.k.a. "risk signals" - use Shared Signals? Extend notification for user alerting? (ISO 27001 8.5)

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

  • Flexible auth: limit connection times, e.g. allow login only during work hours.

  • Resource wizard improvements to warn about incomplete and insecure resource configurations. E.g. weak password for admin account, not using TLS, etc. We probably need support for that in the connector? The connector may do more, such as check if directory is world-readable, whether admin account is used directly, check whether administrator passwords were changed (are not factory-default), etc. (ISO 27001 8.9)

Priority Wishlist

High Priority

  • Password management: to pass ISO27001 requirements

  • PolicyType ✓

  • Object marks for all object types ✓

  • Policy rules to use marks instead of policySituation ✓

  • Privileged classification for (application) roles and entitlements. Show that in GUI, at least in object details. Allow to search users/roles that have this classification.

  • Ability to mark object by arbitrary object mark in GUI. (#9842)

  • Show effective marks in object lists and object details (GUI). (#9843)

  • Show effective assignment marks in list of all assignments (GUI). (#9844) E.g. show that a certain assignment has SoD violation mark.

  • Policy rules

    • requirement constraint (ISO 27001 5.13, 5.8)

    • Better GUI: At least show that enforce action is there

    • Index/search all objects that have policy rule (specific constraint, markRef and enforcement)

  • Auxiliary archetypes in GUI, they are almost useless now.

  • Certifications: Make sure we can certify clearances

  • Make sure we can read and use last login from the resources (e.g. report unused accounts/users)

Medium Priority

  • 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.13, 5.18)

  • Classifications: prominent place in GUI, pass through inducements, searching, reporting. See Classification Improvements. (ISO27001 5.13)

  • Policy rules

    • requirement constraint (ISO 27001 5.13, 5.8)

    • Better GUI: overall improvement, probably custom widget?

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

    • Nicer messages when violated

    • Policy rule exceptions

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

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

  • Better GUI support for custom assignment panels. E.g. show assignments with particular archetype (classifiation,clearance), also the "assign" button should only list targets of that archetype. (ISO27001 5.13)

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

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

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

  • ** Finish concept of "application inventory" (design)

  • midScribe documentation (ISO27001 5.31)

Feature Ideas

Evolution:

  • requestable should not be a flag, it should be a classification. If we do that, we can set up a policy for it, e.g. each requestable role must have an approver. We might be able to do that with a global policy rule for now.

  • Addition to focusType in inducement: focusArchetype to limit application of inducement to certain archetypes, e.g. applications.

Nice to have features:

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

  • 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? (ISO27001 5.13)

    • 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 (just-in-time 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. Benefits: less risk of unintentional use of privileges (e.g. deleting entire disk); use of privilege may require stronger authentication, stronger that the OS can provide; privileged users are less obvious (not members of "Domain Admins" group), it is more difficult to find targets for attacker

    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)

  • Track login and logout times, to determine duration of access. Can be used to estimate effort spent in systems. E.g. to detect under-maintained operating systems and apps.

  • Analyze/record usage frequency for accounts? E.g. used every day, once per week, once per year …​

  • Detect account usage anomalies by watching last login time. E.g. log-on at night.

  • Analyze history/frequency of failed login attempts, to detect password-based attacks. Look at all failed login timestamps together, e.g. to detect password spraying attacks.

  • Analyze password change history/frequency - can we determine anything interesting from that?

  • Risk management

    • Higher risk score (or default risk score) for roles classified as privileged access.

    • Adjust risk score (or default risk score) using classifications.

    • Higher risk score for users with large number of failed logins.

    • Higher risk score for accounts with low usage frequency? Or not?

    • Higher risk score for accounts that were not used for a long time.

    • Higher risk score for users that have not changed password in a long time.

    • Higher risk for users/assgnments that are outliers.

    • Higher risk for users/roles that were not recertified for a long time.

    • Lower risk for users that have MFA setup/requirement.

  • Certification hint: show that the assignment is giving an account that was not used for a long time. Could show usage frequency as well.

  • How to "regularly review" service accounts? How to "verify configuration settings, evaluate password strengths and assess activities performed"? Can we use certifications? We should detect unused accounts. (ISO 27001 8.9)

  • Recording results of deletion, i.e. proof that information was deleted - in metadata? "recording the results of deletion as evidence". We cannot use audit, as audit has limited lifetime, and the deleted information is stored there. We want proof/record that something was deleted without revealing its value. (ISO 27001 5.34, 8.10)

  • Support for data masking: anonymisation/pseudonymization. E.g. export of data to test/devel environment where names and personal numbers are "masked", replaced with fake values. The idea is that developers/testers may test on data with real volume and structure (e.g. group memberships), without revealing user personal data. Maybe have "masking personas" that contain fake data, so the fake names can be consistent across testing systems? NOTE: This may be much harder than it seems. (ISO 27001 8.11, 8.31, 8.33)

  • Data leakage detection: detect that someone else than midPoint stored sensitive data in user profiles. E.g. look for identifiers (SSN, national ID) or data (date of birth, age, gender) in user profiles. (ISO 27001 8.12)

  • Mark data items (schema) that contain sensitive information. Maybe store sensitivity of information in the metadata as well. This could be used by policy rules, e.g. to prevent mapping from leaking sensitive data to low-classification application. This could be used by erasure process of lifecycle, to automatically erase all sensitive information when user gets to archived state. (ISO 27001 5.12, 5.13, 8.12)

  • Restore of target system data from midPoint cache: use cached information to restore data of a broken target system after a failure. (ISO 27001 8.13)

  • Explore use of Shared Signals for alerting and integration. (ISO 27001 8.16)

  • Which passwords of service accounts do we need to change when an admin leaves? Which passwords he created or had access to? (ISO27001 8.20, 8.21)

  • Conditional roles for SoD: some assignments/inducements can be deactivated (using condition) when a conflicting role is assigned. (ISO27001 5.3)

  • Application inventory and physical world: Physical server should have the highest classification among all the applications/assets that run on it. How can we model this in midPoint (ISO 27001 5.9)

  • Certification: show history (audit trail) since the last certification

Recommendations

Recommendations for midPoint deployments:

  • Reference IAM architecture, how midPoint fits in, how it should be used. (ISO 27001 8.27)

  • How applications should be integrated with midPoint (or other IGA platform), manual for application developers. APIs, use of connectors, etc. (ISO 27001 8.26, 8.27, 8.28, 8.29)

  • Application roles must have inducement to application. Do we have this documented? Is it documented well? Emphasized enough?

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

  • Dedicated directories (LDAP/AD) for privileged users, e.g. to use for UNIX/SSH auth, RDP, VPN, etc. Requiring stronger passwords and MFA. Limiting access to directory by non-privileged users (less information for attacker).

  • User inducements in business roles and (especially) orgs to build up policy. Do not use autoassignments.

Examples and Configurations

Examples and configuration recommendations that we need to prepare:

Name Description Controls Status

Information security roles, responsibilities and policies

Use of Information security classification to mark security-related roles. Show understaffing in dashboard. Special who-what-why report for these roles?

Organization for security team, and its manager: chief security officer (CISO). Additional approval for security roles by security team + escalation to manager (chief security officer).

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

ISO 27001 5.1, 5.2

Requirements somehow 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). Find responsibility gaps, e.g. applications without owners, roles without owners, "vacancies" by using policy rules (e.g. projects without managers).

Overlap with "Application/asset management", should we merge? Merge with "policies for information security"?

ISO 27001 5.2, 5.9, 5.15, 5.18, 6.5, 8.6, 8.8

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. SoD exceptions (approved, shown on dashboard)

ISO 27001 5.1, 5.3, 8.32

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. Use of archetype to create AD project groups for members/managers Set up wiki space or source code repository for the project. 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. Use access control to source code repositories as part of the example. Try to use read/write permissions, using relation (see "fine-grained access control").

See also "Automatic management of access rights".

ISO 27001 5.8, 5.12, 5.13, 5.14, 8.3, 8.4

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. Linking service accounts. Find responsibility gaps, e.g. applications without owners, roles without owners, "vacancies" by using policy rules (e.g. projects without managers).

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

ISO 27001 5.9, 8.8

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

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

Done, needs improvement: PolicyType (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. 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. Quickly disable service accounts, isolating applications to limit spreading of incident. 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, 8.7

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. Special certification of privileged access ("minimize number of privileged identities").

ISO27001 5.15, 5.18, 8.2, 8.3, 8.8, 8.9

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

Authentication

Use of midPoint with SSO/AM, integration (both ways). Last login time, number of failed logins, etc. MFA for admins (use privileged access classification). Which SSO/AM to use? Keycloak?

ISO27001 8.2 8.5

Somehow clear

Reductions (Need better name)

Reduce access rights and licenses by identifying unused accounts and privileges. Use last login timestamp to report "lazy" users. Use automated process to disable accounts not used for more than 12 months. Use certification in some way?

ISO27001 5.32, 8.9

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

  • Special approval of role by security officer (5.2)

  • Enforce owner for each asset (application) (5.2)

  • Report security roles and their assignments (5.2)

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

  • Management of service accounts for applications, link them to applications, use application inventory. Quickly disable the accounts on incident/malware to isolate the application. Supports "zero trust" concept. (ISO27001 8.7)

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)

  • Personas or separate accounts for testing (ISO27001 8.4)

  • Prohibit direct access of suppliers to sensitive systems. Suppliers do not have managed devices, we have to assume they are not secure. We do not want to grant them VPN access. We will only allow SSH/RDP access. Use classification/clearances for this (in reverse), e.g. do not allow VPN access for anyone who is allowed to use non-managed device (which is in fact SoD).

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)

  • Report security roles and their assignments (5.2)

  • Report all security roles that are not properly staffed (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)

  • Suspicious objects (mark) (ISO27001 5.27, 5.28, 5.29) ✓

  • 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, 8.8) ✓

  • 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. (ISO 27001 5.2, 5.8, 8.6)

  • Understaffed security positions: use Understaffed security mark.

  • Neglected roles and apps (roles/apps without owner).

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

  • Unused accounts per application. Number/percentage of unused accounts per application. Average usage frequency per application (e.g. users accessing the app once per week on overage) (ISO 27001 5.32, 8.9)

  • Accounts that were never used (never logged in).

  • Organizational units without managers

  • Number of job titles

  • Top job titles

  • Number of locations

  • Largest locations by number of users

  • Users with large number of failed logins

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

  • Service (application) accounts with passwords that were not changed in a looong time (e.g. 5 years)

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.

  • What is "assset", definition of "asset"

  • TLP protocol (ENISA-baseline)

  • Store classification in audit log in a searchable way (ISO27001 5.12, 5.13, 5.14)

Work Done So Far

Docs Improvements

  • Compliance (old page, needs update)

  • Document project management idea

  • Document application inventory idea

    • Use of archetype to create AD project groups for members/managers

    • Project owener (gestor/sponsor) vs project manager

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

  • Secure coding practices (ISO 27001 8.28)

  • Security testing practices (ISO 27001 8.29)

Open Questions

  • How to make "SoD policy" report? TODO: We need more specific use-cases (look for roles with policies? look for users influenced by policies?)

    • Report all roles that have SoD policy rule definitions

    • Report all roles that are subject to SoD policy rules (rule may be in metarole)

    • Report all SoD exceptions

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

  • 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? TODO: Need more specific use cases.

  • Can we make sure we have active user as owner/manager? E.g. whan owner/manager is org unit, we want at lest one active user in the org unit.

  • Reports and archetypes: Are archetypes good method to sort reports? E.g. "privileged users" report is a compliance report, yet it is also a dashboard report and collection report. Later: 4.10 (Advanced analytics).

  • Better support for MFA - integration with SSO/AM. How are we going to approach it? Examples with selected SSO/AM systems? How we can do adaptive auth? How we can do authentication step-up? (ISO 27001 5.8: "the level of confidence or assurance required towards the claimed identity of entities in order toderive the authentication requirements") (ISO 27001 5.8, 8.5)

  • Check that we display previous login time and number of previous failed logins after login procedure is completed (ISO27001 8.5 "considering")

  • Find a good term for "lazy" users, users that were not using system for a long time. Maybe "dormant"?

  • Idea: Can we determine app/account usage frequency/intensity from watching changes in last login value?

  • Counts: number of accounts per user, number of application per user, number of assignment/roles per user. How to search them? (give me all users with more than 10 accounts) How to sort lists? Do we need to store them?

  • How to deal with existing policy violations?

  • Can midPoint detect that disabled orphaned account was re-enabled? Can we react? Can we report it?

  • Certification "manual mode": Do not make any automatic changes (e.g. revoke), do all changes manually. Only report where the situation need to be remedied. Remediation is manual. Can we do this in 4.9? (ISO 27001 5.9)

Answered Questions

  • New abstract role subtype "Policy"? midPoint 4.9

  • Should we mark Superuser role as privileged by default? It is privileged, technically. However, may it somehow deform the reports? YES!

Was this page helpful?
YES NO
Thanks for your feedback