User Tip: Do your Users have a Need-to-Know?

Posted on by

privacy-policyAre you ensuring that the access to your financial asset data is secure? While eOriginal’s eCore® electronic vault provides state-of-the-art security for your data and transactions, security concerns could lie right within your organization.

Before providing a user access to our system, ask yourself, does this user have a need-to-know?

Need-to-know is one of the most fundamental security principles, and the practice limits the damage that can be done by a trusted insider. As a best practice, knowledge, possession of or access to financial asset information should not be provided to any individual solely by virtue of the individual’s office, position or history with the company.

Verifying a user’s genuine need-to-know may require some judgment, but will guarantee that your information is protected with the correct access permissions.

Setting Permissions within the eCore® Electronic Vault

Within eOriginal’s eCore electronic vault, actions define privileges, which generally control the ability to create, retrieve, modify, and delete information. Actions are broken down into two types: user-based and role-based actions:

  • Assigned user-based actions grant privilege directly to a specific user or user group.
  • Role-based actions are assigned to users based on the role they are playing in a business process. In addition, role-based actions are tied to eCore Vault containers.

Each action has an associated security scope. Security scopes available for system actions are (highest to the lowest level): vault repository, industry, organization, and vault container.

Holding a privilege in one organization does not grant the same privilege in another organization. Industry-scoped actions function the same way, but at the industry level. As an example, the permission to “create a transaction” is, by default, scoped to an organization. This means that the system restricts (or scopes) the user’s create transaction privilege to a single organization.

While user permissions can be assigned through groups, based on job title or other defining characteristics, this method, while more scalable, comes with more risk because any member who is added to a group immediately inherits that group’s privileges without any explicit assignment.