The following topics are available:

iManage Security Policy Manager

iManage Security Policy Manager (SPM) is an optional add-on application for iManage Work that manages security. This application allows for more detailed control, audit, and reporting of security. It is a security layer before iManage Work's access permissions, and provide additional control including new security features. It is designed to work with iManage Work but is a separate application. iManage Work cannot change or set SPM values. SPM can also be applied to other applications including iManage Records Manager and the Microsoft Windows file system. Contact iManage for additional information about the application.

SPM introduces two conditions that apply first when determining access permissions for items, which includes containers (such as workspaces, folders, matters, clients, and cases) and documents: Open access, and restricted access.

• Open access. This permission allows the selected users and groups access to those items. However, normal iManage Work access permissions still apply. For example, SPM may grant a user open access to a matter, but iManage Work does not allow access for that user on that matter. The combined result is that the user has no access.
• Restricted access. This permission denies the selected users or group access to the items. Restricted access permission is a convenient method to limit access without having to modify iManage Work access permissions, and includes avoiding refile events. For example, SPM assigns a user restricted access to a matter. Regardless of the iManage Work access permission, even if the user is granted explicit iManage Work access permission, the user will have no access to the matter.

In the sections that follow, the discussion assumes a user or group has open access to an item.

iManage Work Object Security

The iManage Work security model offers a versatile and flexible means of managing security across all workspaces, containers, and documents. Each item has a series of security settings. Precise refinements can be made on each security settings, providing an increasing amount of security and specifying exact access for any user or group.

For example, an editor's group may be added to an item that allows those group members to edit documents. All other users can be excluded entirely, perhaps for conflict of interest reasons, from viewing documents. Additional versatility is provided by even being able to exclude specific members of that editor's group from editing or viewing a specific document.

Every item has the following security characteristics:

• Security Policy Manager (SPM) access limitations
• default security
• access permission
• library and global role restrictions
• security model and groups membership conflict resolution

The bottom line result of the combinations from all the sources is called the effective security.

Default security

The default security value is the basic security level and is inherent at all times. A value is automatically assigned when a container is created, or a document is created or initially uploaded. This value may be changed later by someone with the proper permissions. See Changing Security.

The following are the four default security values: 

Access permission

Access permission is an optional security value a user can have for a container, document, and email. Access permission refers specifically to user's granted access to an object. These include the following values. A user or group is not required to have an access permission. The access permission may be more or less restrictive than the object's default security. If specified, it overrides the default security. If not specified, the item's default security value is used.

Library and global roles restrictions

A library role is a named set of library-level privileges. Library roles are assigned to individual users, and each user must have a role, even if only the default role automatically to each new user. Some library-level privileges affect access to containers and documents. For example, if a container's default security is full access, a user is explicitly granted full access, which includes being able to delete items. However, if the user's library-level role privilege Delete is not granted, the user will not be able to delete items.

The following library-level privileges may affect user access.

Documents

Folders and tabs

Workspaces

Changing Security

Only a user or group with Full Access to that item can change security levels. This includes having access permission of Full Access, or being an item's operator (also called an owner), who by default has Full Access for that item.

Security can be changed in the following ways:

iManage Security Policy Manager: iManage Security Policy Manager (SPM) can set Open or Restricted access for users and groups. This access does not change the iManage Work system's settings but instead is a security layer that is checked before attempting to access iManage Work.

Direct assignment: The user can change the default security directly to an item. In the property panel, or at the time the document is created or initially uploaded, a properties panel displays. If the user has the proper level of permissions, they can change the default security.

Refile: Refile is an iManage Work Windows service that automatically updates container's and document's security. This includes the collective default security and access permission, and metadata for each item. If a parent container has its security changed, this service automatically propagates those changes downward through all the children containers and their documents. For example, if a workspace changed its default security to View, that new default security is automatically changed for all children containers with a default security of Inherited.

Security Model

The iManage Work security model resolves access conflicts if a user belongs to two or more groups. The model is called hybrid security. The hybrid model grants:

• Access using the most permissive access levels from among the available groups.
• Except if a denial exists. The denial take precedence over any access grant.

For example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.

The hybrid model grants access from the most permissive access levels. Here, Group 2 offers Read/write, so the user is granted Read/write access to Container A.

For another example, a user is a member of both Group 1 and Group 2, and is trying to access Container A.

The hybrid model grants access from the most permissive access levels except if there is a denial among those. Here, Group 1 offers No access, so the user is not granted access to Container A.

Conflicts from different groups

The following matrix determines the net result of conflicts caused by a user being in two or more groups.

• First, determine the group with the most restrictive access in the first column. This means the group either has No Access, or any other access.
• Second, determine the group with the least restrictive access in the second column.
• Third, using the single row that matches the first and second access levels, cross index with the user's access rights. The result is the user's access level from groups.

Unspecified access permission indicates that access permissions have not been defined for the item. The item may not have any default values, or all existing values have been removed.

Examples

If the user is part of a group that offers the most restrictive access of No Access, regardless of any other access permissions (except for the owner who always has full access) the user will have no access.

If the user is part of a group that offers the most restrictive access of View, another group offers the least restrictive of Read/Write, and the user has access permission of View, the effective security is Read/Write. The security model resolves the different access levels as the least restrictive, here as Read/Write.

How to calculate Default Effective Access Rights

How to calculate Effective Default Security Policy

Effective Security

Effective Security is the net result of a combination of an item's:

• Security Policy Manager access level
• default security

• access permission

• roles restrictions

• conflicts among groups the user belongs to
• the security model being used

If an item has only default security, all users will be limited to that security level. For example, if the default security is view, then all users have view access to it.

Users may have access permission different than the default security. Continuing the example, user Sandhya needs to be prohibited from viewing a container's contents, perhaps due to a conflict of interest. In this case, she would be assigned an access permission of no access. After that, Sandhya will not be able view contents inside the container. If the access permission of no access were applied to a document, she could not be able to read it, and is even being prohibited from seeing it in a container.

The effective security in these two cases is straightforward. The access permission always has priority. In the example above, no access has priority over the view default security.

However, access can also be provided through groups.

If the user is provided access from only one group (and with no explicit security otherwise), the group's access priority is over the default security. For example, the user Nicole is part of a group with read/write access to a container with view default security. Nicole has the effective security of read/write. This is granted from the group having priority over the default security.

If a user is a member of at least two groups, and some of the groups have different access levels, an access level conflict occurs. The resolution depends on the security model being used.

Owner

The owner is a role that's automatically assigned to the user who creates a new workspace or folder. That user has Full Access privileges to the workspace/folder. A workspace/folder can have only one owner, and the current owner can assign the role to another user.

Operator

The operator is a role that's automatically assigned to the user who creates a new document or initially uploads a document. That user has Full Access privileges to the document. A document can have only one operator, and the current operator can assign the role to another user.

Author

An author of a document is a role that's automatically assigned to the user who creates a new document or initially uploads a document. The author can be changed by a document's operator or another user who has full access to the document. The author role doesn't grant ownership to the document (see Operator) but does grant implicit full access to it.

ACLs

An ACL is an access control list used by iManage Work to mark access permissions for documents and containers. Any entity with the appropriate access (for example, system administrators, third party tools) can view/modify an ACL. A child container can be said to "inherit its parent's ACL," meaning the default security and all users and groups in that container access permission from the parent.

Refile

iManage Refile Service is a service that propagates security and property field changes throughout a library in a background operation. This is not part of an item's effective security but can affect an item's security values.

The propagation begins with well defined events, such as changing the security on a container, or changing a property field value. For example, changing the default security of a container may trigger a refile event. Once an event is initiated, the propagation is automatic and does not require confirmation from the user. During the propagation, items are updated according to explicit rules. The refile processes downward, through each subfolder and is recursive through all subfolders. For example, a change at the matter level may affect all items within that matter. If the event occurs in a child folder within that matter, only that child folder and items contained by it, including other folders, may be affected. The propagation never transverses to a higher container. The operation occurs in the background and is not noticeable by users. They can continue to use the application. However, it may take a few minutes for the refile service to propagate these changes through the entire container hierarchy.

Refer to Refile for additional information.

Encryption

Data encryption is a security measure that prevents visibility of documents in the case of unauthorized access or theft. This is not part of an item's effective security but can affect an item's security values.

Also called data at rest encryption, documents are encrypted when they aren't being used. In the event they're compromised, such as by theft, wrongful disclosure, or unauthorized access (including internal unauthorized access), the files are encrypted, and therefore, unreadable. When an authorized user accesses a document (such as through editing or viewing within a client application), the document is decrypted and will be able to be read or edited normally. When the user is done with it, it's returned to its encrypted state. This encryption is compliant with HIPAA and other American statutes protecting sensitive information.

A document or email will be encrypted if at least one of the following conditions is applicable, even if other conditions specify not to enable encryption. More than one condition has no additional effect.