Security Design Best Practices

Follow these best practices to design a security model that effectively serves all combinations of your products and personas.

A well-designed security model is scalable, adaptable, and requires minimal maintenance. To avoid major security overhauls as your solution grows, design a flexible security model that supports various user roles and product tiers.

Future proof your security model design ahead of any configuration

Carefully consider your user personas before configuring the security model. Go over as many use cases as possible, including personas that are relevant to your initial solution and those you may target in the future. We recommend that you divide users into functional user groups based on your planned Visier deployments, such as general users, managers, executives, and recruiters. This minimizes future redesigns and the changes to your initial setup in the future. By defining personas, you can figure out what data and content they need to access how many permutations of each may be required.

Security should always be inherited from the parent administering tenant

Remember to define security at the overall administrating tenant level and push it down to all external customers. Doing so allows scalable security across all customers. Defining security for each customer individually creates maintenance, troubleshooting, and editing challenges. To simplify maintenance, we recommend that you design your security model and permissions so they can be reused across all customers.

While inheriting permissions from the parent tenant is best practice, you might need to create separate permissions to secure attributes that are unique to the child tenant, like custom attributes. If security access is required on these attributes, you can design child-level permissions for those attributes on the child tenant exclusively.

Dynamically look up a matching employee record against the user’s profile

Make use of dynamic look-up to automatically assign users to user groups and population access. Dynamic look-up matches an attribute on the user's profile to an employee record. For more information, see Set up Dynamic Look-Up. This option appends the Employee ID to the user profile, making it possible to dynamically assign users into User Groups on the basis of the user’s employee attributes. Furthermore, this creates the possibility of dynamically assigning population access based on the Employee ID. For example, giving supervisors access to their own reports.

Segment your users into distinct user groups

Again, when creating user groups it is important to understand all of the possible user personas. Data held by the employee, such as the employee ID or the employee’s email address can be used to determine a user’s membership in that group. This eliminates the need for manually provisioning users into a user group. Multiple permissions can be added to groups which further reduces the need to manually assign permissions to users.

Onboard attributes that can be used to segment users into groups

Consider loading data that will help you dynamically assign users to user groups. This data may not be apart of the standard set of employee attributes and is likely to reside within the security model that your human resources information system (HRIS) uses. Append these attributes to employee profiles so you can use them in user group security filters.

Set up permissions for use in multiple user groups

Define generic permissions for maximum reusability. Limit the number of permissions that require access to the same set of subjects, events and related objects. Avoid creating permissions filtered to specific organizations or locations. If filtering is required for specific data access, it should be defined dynamically, where possible.

Always define data access sets and security filters outside of permissions

Data access sets should always be referenced and not exclusive to a specific permission. Update data access sets globally so changes are automatically applied to any permission the data access set is used in. This means you only have to make the change once. For example, create a data access set that will be reused across products. If premium tier access to data attributes is shared across products, maintaining one data access set ensures alignment across all permissions referencing the data access set. You can also apply this best practice when defining security filters.

Create a baseline data access permission for use by all active users

Create a baseline data access permission for an All Users group. This allows you to enable users quickly with minimal access to the solution. When defining a standard baseline data access permission, it is important to safeguard sensitive attributes. A common example of this is to create a baseline simplified HR permission, which only grants access to basic attributes, such as Organization and Location. The best practice is to only grant access at the aggregate level to this permission. The addition of detailed view, sensitive attributes should be gated by a detailed permission which would need to be additionally assigned to the user.

Create separate permissions for data access, content packages, and capabilities

Creating separate data access permissions, as well as capability permissions enables the reusability of the permissions across multiple user groups. How you define each permutation will need to be closely aligned to your user personas, content, and tiering strategy for your products. You may need multiple data access permissions and capability permissions if you have multiple permutations of products and tiers. The key is to minimize the need for replicating permissions that combine all these pieces together ensuring the singular permissions can be reused for different groups of users.

Onboard hierarchy head data into organizational hierarchies

Onboard hierarchy head information for all your organizational hierarchies whenever feasible. The Organization Head attribute is an Employee ID that would head up an Organization ID within an Organization Hierarchy. This attribute can be leveraged by the security model, dynamically, to assign population sets to users that head up specific organizations or cost centers.

Leverage dynamic security for assigning users into groups

Never manually assign users to groups. Users should always be dynamically assigned to user groups through security attributes held by the employee via API or via HRIS attributes held by the employee. Manual assignment will lead to human error and can have serious consequences if not maintained.

Define inclusion security filters instead of exclusion

When defining security filters and population access, use inclusion when filtering. This also applies when defining user assignment in user groups. Inclusion ensures users get access to the intended population and assigned to the correct user group. Exclusion can lead to unintentional data access. For example, you could potentially grant users access to future departments that users shouldn't have access to.

Security Implementation

A robust security model minimizes risks, prevents insider threats, and supports operational efficiency. Key considerations for implementation include:

• User security
• Studio profiles
• Permissions
• Dynamic security
• Security inheritance
• Security maintenance

User Security

Securing user access is critical for protecting sensitive data and ensuring compliance with organizational policies. Individual users and user groups can pose significant risks to your security model when logging in. Simplify and secure the user login experience and add a layer of security to your tenant by setting up:

• Single Sign-On (SSO): Users log in with external credentials and set up SSO with your SAML 2.0-compliant identity provider. For more information, see, Set Up Single Sign-On.
• Network access: Users log in and export data only from trusted IP addresses specified in CIDR format. By default, users can log in from any network. For more information, see Set Up Network Access.

User Groups

If your security model involves creating and maintaining user groups, you can dynamically determine user security using data attributes. Define user groups at the administrative tenant level and distribute changes to all analytic tenants. For more information, see User Groups.

A successful security plan involves thinking big and building small. Design your plan for all potential future users, but only implement what's needed today. We recommend splitting users into functional user groups. It’s helpful to think about the various Visier deployments you’re planning. For example, those deployments could be to:

• General users
• Managers
• Leadership and executives
• Recruiters

As you create the user groups, you can set up the criteria and see a list of the users that fall into that group to validate that the criteria is working. For more information, see Manage the User Group Membership.

Studio profiles

Profiles can be assigned permanently or for a specified duration, ideal for temporary or project-based roles. Users need profiles to load data and customize analytic models. You can assign profiles so users can upload, transform, and publish data. For more information, see Studio Profiles. If users don’t need to work in Studio, they do not need profiles.

Permissions

You can simplify your model by reusing permissions across multiple users. As your security needs change, it’s easier to edit shared permissions than modify different individual permissions. Having fewer permissions also makes it easier to identify issues and troubleshoot. Permission can apply to:

• Data Security: Choose which data users can access.
• Capabilities: Choose what actions users can do in the solution.
• Content packages: Choose which guidebooks, metrics, or other content users can see.

When creating a new permission you should aim to simplify users’ experience by tailoring the content to their specific job needs. As a best practice, you should use permissions to limit a user’s access to only what they need to see for their job. This decreases the risk of security issues and insider threats.

Permissions can be granted to user groups that share similar access needs to decrease the number of total permissions. The addition of a new permission will not remove the content access to an existing permission. This prevents conflicts when multiple permissions are set for similar datasets. For more information, see Permission Management.

Dynamic security

When considering dynamic organization security, you can base your security on the following common hierarchies:

• Organization Hierarchy: This is typically the departmental structure. It’s the simplest scenario and is used to restrict access to only employees who are the organizational head of departments. In other words, these employees only have access to their own organization.
• Supervisory Hierarchy: This is also based on the departmental structure, however the restriction is based on an employee’s direct manager. This means access is given to all employees who report to a particular manager.

You can also create your own custom hierarchies outside of departmental structure. For more information, see Set Up Dynamic Security Using Security Files .

Security inheritance

Defining permissions and groups at the administrating level ensures all changes made will be distributed to analytic tenants. Handle assignments of these defined permissions and groups at the analytic level to ensure accuracy in each specific tenant.

When building the security model, create reusable permissions for all external clients. To test, publish the security model to production, then create a test user in the external client assigned to the inherited permission, and preview.

Security maintenance

Security model changes require project publication to take effect. For more information, see Publish Project Changes. New analytic objects necessitate permission updates as Visier does not grant access by default.

Always consider maintainability when creating or updating data security and content packages. Review and update permissions in the following situations:

• After each Visier release that includes new analytic objects.
• When you onboard new data that introduces or populates analytic objects.
• When you create new analyses for custom content.

Administrators must review each permission and determine whether it should include access to the newly added content.