You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »


2. Reporting and Auditing


  1. What current and historical data is maintained for reporting?

  2. Is the reason (automatic and manually approved) for all provisioning decisions and actions stored? Can it be sent to an external system (Splunk, logstash, etc) data warehouse?

  3. How is the data stored? Can it be read by external systems?

  4. Can we export the data in its entirety?

  5. Can we control how long the data is maintained?

  6. Does this product provide what our auditors and compliance officers need?

  7. Does this product provide what our application (target system) owners need?

  8. Reporting (should we just combine audit and report?)

    1. What pre-built reports are available? Can they be customized?

    2. Can we build our own reports? Using a GUI? Non-GUI?

    3. Does the product support reports on

      1. Access for an application (target system)

      2. All access for a user, all users in a unit, all users for a supervisor

      3. Elevated or high-risk access

      4. Separation of Duties

    4. What output formats are available for reports (eg, PDF, CSV, HTML)

    5. Is the data used for reports available for use by third-party reporting tools?

    6. Can reports be run on a schedule and sent by email or to a (possibly external) report repository, and/or made available via GUI? If available via GUI, what are the access controls?

  9. Auditing

    1. Can we compare intended provisioning to the actual state of an application on demand?

    2. Does the product audit changes made within it (eg, who made a change to group membership logic when, and what the change was)

    3. Does the product support Separation of Duties audits?

    4. (If you do access reviews / attestations) does the product provide adequate support?

      1. review by person, unit, application

      2. review of only manually-decided access, exceptions only, etc

      3. Can audit results include “comments” (eg, “access being removed because …”) that become part of the record

      4. Can the auditing work with an external ticketing system (eg, ServiceNow, Remedy)

      5. How does the product define and schedule reviews, notify and remind reviewers, etc? Can the product send emails and/or use an external ticketing system? Are reviews done within the product, or in a document sent to the reviewer?

      6. How does the reviewer to report results? Is the effort required proportional to the number of changes?

      7. Does the product support workflows, logic, etc. needed to implement access changes determined by a review?


5.    Credential provisioning

    a.       Password rules and policies

        i. Describe the password policies you support with regard to complexity, length, and any dictionary checks. Include character classes supported in complexity checks. (Call nist

        ii. Does your product support flexible password policy based on password length? For example support pass phrases but requiring additional character sets for shorter passwords.

        iii. Describe your support for passwords in multiple languages.

        iv. Describe your products support for password expiration, including any support for flexible expiration based on grouping, assurance, or other factors such as password quality.

        v. Describe how your product conveys password quality to end users.

        vi. Describe how you product meets accessibility guidelines

    b.       Initial password setting (credential activation?, initial login?)

        i. Describe how your product assures initial password setting is being done by the appropriate authority, such as invitations, one time and/or short lived tokens etc.

        ii. Describe your products support for terms of use and informed consent when getting a credential.

        iii. What platforms are supported for end user devices setting initial and subsequent passwords, including any required technologies.

        iv. Describe any features your product has to deter attacks on unclaimed credentials.

        v. Describe how your product handles multiple credential stores.

    c.       Assignment of additional authentication factors

        i. Describe your support for certificate based authentication.

        ii. Describe your support for multifactor enrollment, specifying supported technologies and products, explicitly address U2F support.

        iii. Describe any support you have for challenge response questions.

        iv. Describe any unlisted additional authentication factors, and any features that help user recognition such as image validation.

        v. How do you handle loss of a (perhaps only) two factor device, such as one time tokens

    d.       Deprovisioning of credentials

        i. Describe the states supported by your product for credentials, such as open, expired, disabled, locked/unlocked, security deny, etc.

        ii. Describe any workflow available for deprovisioning, time based, approval based, and any attribute or membership checks that can be used for deprovisioning workflow.

        iii. Describe any controls for sanity checks in your product to prevent accidental mass deprovisioning.

        iv. Describe the administrative capabilities your product has for deprovisioning and deprovisioning intervention, include any delegation features.

        v. Describe how your product handles deprovisioning of credentials w/r/t propagation to multiple credential stores.

In addition to the above, include documentation of your APIs related to all of the above functional areas.

  • No labels