Knowledge Article

Identity Security Cloud Implementation Requirements Gathering Questionnaire

Author

  • neil_mcglennon

    SailPoint

Requirements Approach / Overview

Leading into implementation, some people may share specific requirements they have, and others often may not, or may not know how to easily articulate their requirements with regard to Identity Security Cloud feature sets. This document is a requirements gathering questionnaire, which is designed for any implementation personnel to ask questions necessary and gather information about particular requirements for implementation of Identity Security Cloud. The idea is that questions in this document can be asked to a particular implementation, and their responses recorded to better understand expectations around the implementation.

The resulting answers from this questionnaire should be recorded by any implementation personnel and written down to trace the project needs, and guarantee those specific requirements make it into an implementation design, which follows this document. If there are requirements / items discovered that are beyond the scope of the project, beyond the scope of what can be implemented, or what the product can allow, those should be handled as project issues tracked by the project management staff.

Once final requirements are gathered and signed-off, a technical implementation design can be drawn up for implementation, and corresponding testing plans can be mapped to that functionality. Further discussion around testing may be necessitated beyond what this document covers.

Project Details

Business / Timelines

This section details requirements and discussion points around how the project is run and its purpose.

  • What are the hard project timelines?
  • What are high-level requirements you are trying to achieve with the implementation?
  • What are current project drivers?
  • What are the priorities for the project? Are there must-haves?
  • What is your change control process?
  • What are different groups within the business that might interact with the system? If so, for what? And whom? e.g. Managers, Security, Auditors, Help Desk, etc.

Testing

This section details requirements and discussion points around testing.

  • What tests are needed to guarantee acceptance?
    • User Acceptance Testing (UAT) is commonly what we see; typically done by the customer or subsidiaries.
  • How do we test the implemented functionality?
  • Do you have a test environments? How do those map to the sources or applications in scope?
  • Who does the testing? Do you have a dedicated testing team?
  • Types of testing needed:
    • Unit Testing
    • Functional Testing
    • Integration Testing
    • Quality Assurance (QA)
    • User Acceptance Testing (UAT)
    • Load / Performance Testing
      • This necessitates another specialized tenant often.
    • Penetration Testing

Architecture / Infrastructure

We share our cloud communication architectural diagrams. The customer can also share their environmental details and any supporting materials. The customer should be prepared to go over the technical details of their environment, and this discussion will lead into source configurations in the next section.

  • How many VAs do you anticipate deploying? We recommend 2+ in Production and Sandbox.
  • Do you have any security requirements which may drive the VA deployment?
    • Normal Deployment
    • Proxy
    • Secure Tunnel
  • Do you have any High Availability (HA) or Disaster Recovery (DR) requirements?
  • VA placement:
  • Network topologies - where will the sources and in relation?
  • Ownership:
    • Who would carry out the VA deployments?
    • What is the process?
    • When is the earliest we can deploy these?
    • Do we need to do any special coordination?
  • Are there any security, audit, or compliance questions or concerns?

Sources / Integrations

In this section, we detail the sources or integrations that we will be communicating with. This can be a fairly lengthy and details section on its own, depending on the level of detail you go into.

  • What are your Authoritative Source(s)? Or said another way, what are the data sources that contain your identity information?
    • Typically this is some sort Human Resources (HR) system, but could be others.
  • What are your Non-Authoritative Source(s)?
    • These would be sources of user accounts and access.

For each source identify:

  • What is the business purpose of the specific system / source we are connecting to?
  • In general, about how many accounts are on this system? How many accesses / entitlements?
  • Who are the source owner(s)?
    • Business Owners
    • Technical Owners
    • Security / Compliance Owners
    • Other?
    • Who will be our main point of contact for questions?
  • What is the overall priority of this system in regards to project scope?
    • Is this a must have / high priority, or a nice-to-have / low priority?
  • Priority aside, what is the readiness of this system?
    • Is it relatively easy to onboard? Is this a 'quick win'?
  • What is your provisioning process to this system look like today?
    • Is it manual?
    • Is it automated? - If so, how?
  • What is the intent for this source?
    • Read / Aggregations?
    • Creating accounts?
    • Updating accounts (and access)?
    • Deleting accounts
    • Enable / Disable accounts?
    • Password management?
  • Does this source have test environments?
    • If not, how are we going to mitigate risk with the in-scope features?
  • How often do you need to bring in data (aggregations)?
    • Are there any Service Level Agreements (SLAs) you have with the business? How rigid are these?
  • What are the means (technical or otherwise) to connect to this system?
  • What information does the accounts and entitlements house?
    • What information is necessary to bring in?
    • What information makes an account unique?
  • What information may tie an account back to its owning identity? (i.e. correlation data)
  • How do you structure your account data? What does an ideal account look like? What are the data mappings?
  • Are there differences in data across populations?
  • Is there anything else to mention about a source that hasn't been conveyed yet? Other details?

Identity Model

In this section, we detail the various identity populations as a basis for identity management. This is designed to map the authoritative sources (already discussed) to how we might build the identities and where we might get data.

  • What type of identities are you bringing in?
    • Are they treated differently? the same?
  • Authentication - If these identities were to log into the system, how would they authenticate?
    • Pass-Through Authentication to a source (e.g. Active Directory)
    • Integrated Windows Authentication (IWA)?
    • SAML
  • For each identity, are there specific information / attributes you want to collect?
    • This is the interesting 'things' we can say about an identity.
    • Spreadsheet of these?
    • Are there are any calculated attributes?
    • Where do these attributes come from?
    • What is necessary by downstream systems?
    • Should we transform, map, or normalize attributes? Do you have inconsistent or bad data?
    • How should we handle special characters? e.g. dashes in names, accents, etc?
  • What should we use for first and last name? The legal name? Or preferred name? e.g. Robert Smith vs Bob Smith
  • Do you have a manager hierarchy defined? What source(s) determine this?
    • Does anyone not have a manager? If so, what are the implications of that?
  • Overall identifier - is there an overall username construct?
    • How will they login?
    • We use this as a 'uid' in Identity Security Cloud.
  • What is an identity's lifecycle today?
    • Joiner / Create
    • Leaver / Disable
  • Are there any attributes which describe an identity's status / state?
    • This will be the identity's Lifecycle State attribute.
    • e.g. start and end date, HR status code, or a combination?
  • How does your authoritative source(s) handle:
    • Rehires?
    • Transfers?
    • Conversions (i.e. from Contractor to Employee)
    • Leave of Absence (LoA)
  • Is there possibility for multiple HR records for a single identity?
    • i.e leave and come back? Or should we handle this as separate identities?

Identity Security Cloud Features

In this section, we should validate the features they have purchased, and which they want to implement. This will determine which specific feature requirements we discuss in next sections. Only go through specific sections as needed, or required.

  • Do you have any specific order or priority of features you would like to implement in a certain order?
    • Note: We can make recommendations in ordering and priorities.

Provisioning

This section will detail requirements around provisioning. This can sometimes be a longer conversation than the questions here, depending on their expectations, and needs. It is a good idea to document as much as you can.

  • By what means, automated or manual, are you doing provisioning today? How can this be improved / changed?
    • Is Identity Security Cloud a replacement or a supplement to these tools?
    • Are there other solutions that provision?
  • What is your overall provisioning process today? How do you setup accounts? What is the process - walk through it.
    • Give a 'day in the life' example - for instance, a joiner.
  • What are the sources for provisioning?
    • Refer to the sources list.
  • When is someone first given access? X days before start? On the day they start? As needed?
  • What access do we typically grant for your identities? (Note: This is a very loaded question)
    • Do you have mappings of access
    • Do you have existing role definitions in your systems today?
  • Identity Lifecycle Revisit - Automated Process - What happens when someone is hired? terminated? other?
    • Enable of accounts?
    • Disable of accounts?
    • Send emails?
    • Grant access?
    • Remove access?
  • Is there any manual override to automated processes? Describe how that works?
  • What are the sources we're provisioning to? (Refer to sources mentioned earlier and add if not there)
    • What operations do we need to support? Create, Update, Enable, Disable, (Delete)
    • What is a template or "gold standard" for creating this account? How do you do this today?
    • What is the username we generate, and how is this generated?
      • Common Patterns: first.last, filast, etc.
      • Is it unqiue? What do we about special chars? Incrementation schedule? i.e. what happens if something isn't unique.
    • Sequencing of account creation (e.g. AD first, AzureAD second, etc.)
  • Do you have anything defined today for roles?
    • Access granted, assignment criteria, ownership
  • Are there any simple packages or patterns of access that you can easily grant?
  • Are there specific attributes that you want to enforce across the sources?
    • Are there any write-back to authoritative sources?
  • Discuss the password generation and transmittal best practices.
  • Are there any other provisioning requirements that haven't been covered so far?

Access Request

This section will detail requirements around access requests. Most of the time this is a supplement to provisioning (above). This can sometimes be a longer conversation than the questions here, depending on their expectations, and needs. It is a good idea to document as much as you can.

  • By what means, automated or manual, are you doing access request today? How can this be improved / changed?
    • Is Identity Security Cloud a replacement or a supplement to these tools?
    • Are there other solutions that are requesting access?
  • What are the sources for access requests?
    • Refer to the sources list.
  • Request process
    • Do you allow self-service requests (i.e. request for self)?
    • Do you allow for requests on behalf of (e.g. manager requesting for an employee)?
      • If so, who can request on behalf of someone else?
  • Requestable items
    • What items to you allow to be requestable?
    • Do you have a good understanding of these accesses? Has this been defined?
    • How do you present these to the end-user? Do you have nice language / descriptions defined?
  • Approval Processes
    • What are the common approval processes that you follow?
    • Do all accesses have the same approval process?
    • Are there access that have no approvals?
  • Are there any other access request requirements that haven't been covered so far?

Certifications

This section will detail requirements around access review / certifications. This can sometimes be a longer conversation than the questions here, depending on their expectations, and needs. It is a good idea to document as much as you can.

  • By what means, automated or manual, are you doing certification today? How can this be improved / changed?
    • Is Identity Security Cloud a replacement or a supplement to these tools?
    • Are there other solutions that are certifying / reviewing access?
  • Do you have any audit findings? Or deadlines you need to meet?
  • How frequently do you certify?
  • What are the sources for access review / certification?
    • Refer to the sources list (above).
  • What type of certifications?
    • Manager
    • Source Owner
    • Entitlement Owner
    • Ad-hoc via Search
    • Other?
  • What are the contents and people in certification (Campaign Filters)?
    • Who are the certifiers? Who owns them?
    • Is there anyone you don't want to certify (Campaign Filters)?
    • Is there any delegation to others (Campaign Reassignment)?
    • A good example of this is executive certifications may be reassigned to their executive assistant.
  • Do you have any need to group entitlements together (Access Profiles)?
  • Manager Certs: Do you have manager hierarchy defined?
    • Make sure manager is a proper reference
  • Source Certs: Do you have source owners?
  • Entitlement Descriptions? Do you have these? Can you get them? Are they already part of group description?
  • Reporting
    • What is required by audit?
    • What is required by operations?
  • Are there any other certification requirements that haven't been covered so far?

Password Management

This section will detail requirements around password management. This can sometimes be a longer conversation than the questions here, depending on their expectations, and needs. It is a good idea to document as much as you can.

  • By what means, automated or manual, are you doing password management today? How can this be improved / changed?
    • Is Identity Security Cloud a replacement or a supplement to these tools?
    • Are there other solutions that are changing passwords?
  • What are the sources for password management?
    • Refer to the sources list.
  • What password flows / use cases are you using?
    • Authenticated (Change my password)
    • Unauthenticated (Forgot my password)
  • Are any passwords synchronized together?
    • If so, do all passwords conform to a single password policy?
  • Are the password policies consistent or different across systems?
  • Are there other integrations needed?
    • Desktop Password Reset (DPR) - Explain use cases here, if needed.
      • Do users need to be authenticated on the network?
    • Password Interceptor (PWI) - Explain use cases here, if needed.
      • Do DCs have ability to call IDN directly? Or via proxy?
  • Strong Authentication - What are methods used?
    • KBA - What the questions that you need? How many? Do these need to be multi-lingual?
    • SMS / Text - Mobile or Phone
    • Voice - Mobile or Phone
    • Integrations
      • Duo
      • RSA
      • Symantec
      • SafeNet
  • Do you need password reminders enabled?
    • This is only available for certain sources (like Active Directory), which have a password reset date.
  • How are notifications sent out? What do these look like?
  • Are there any other password management requirements that haven't been covered so far?

Platform / System Settings

This section will detail requirements around miscellaneous system settings.

Branding

  • Do you have specific colors or logos we can use with the product?
  • Do these need to be targeted towards a certain sub-set of identities?

Email

  • Do you have any specific email template formats needed?