Protective mechanisms
What are protective mechanisms?
The primary goal of Netwrix Password Secure is to ensure data security at all times. The authorization concept is naturally the most important component when it comes to granting users the intended level of permissions for accessing data. Specifically, this makes it possible to make certain information only available to selected employees. Nevertheless, it is still necessary to have protective mechanisms above and beyond the authorization concept in order to handle complex requirements.
- Visibility is not separately configured but is instead directly controlled via the authorization concept (read permission). Nevertheless, it represents an important component within the existing protective mechanisms and is why a separate section has been dedicated to this subject.
- By configuring Temporary permissions, it is possible to grant users or roles temporary access to data.
- Password masking enables access to the system without having to reveal the passwords of users. The value of the password remains constantly hidden.
- To link the release of highly sensitive access data to a double-check principle, it is possible to use Seals. The configuration of users or roles with the permissions to issue a release is possible down to a granular level and is always adaptable to individual requirements.
The following diagram shows a summary of how the existing protective mechanisms are integrated into the authorization concept.
In the interplay of the Authorization and protection mechanisms, almost all conceivable scenarios can be depicted. It is worth mentioning again that the authorization concept is already a very effective tool, with limited visibility of passwords and data records. This concept is present everywhere in Netwrix Password Secure, and will be explained in more detail below.
Visibility as a basic requirement
It should always be noted that visibility is always a basic requirement for applying further protective mechanisms. A record that is completely hidden from a user (= no read permission) can naturally not be given any further protective mechanisms.
NOTE: The visibility of a record is always the basic requirement for applying further protective mechanisms
Combining multiple protective mechanisms
In principle, there are a diverse range of possibilities for combining the above-mentioned protective mechanisms. Temporary access to a “masked” record is possible just as having a “masked” record which is additionally secured by a double-check principle is also possible. Nevertheless, it should be noted that temporary permissions in combination with seals always pose a risk. If releasing a seal requires approval from a person who only possesses or possessed temporary permissions or will only possess them in future, this could naturally conflict with the configured release criteria.
CAUTION: The combination of seals and temporary permissions is not recommended if the user with permissions to issue a release has only been given temporary permissions.
Release mechanism
What is the release mechanism?
A sealed password will not be released until the number of approvals required in the seal has been granted. Releases can be granted by anyone who has been defined as having the required permissions to issue the release in the seal. The mechanism describes the complete process from the first release request to the final grant of the release and the breaking of the seal.
Users and roles in the release mechanism
As noted in the previous sections, seals always restrict the right of a user to view a specific password. Even if the configuration is usually done at the level of the role, each user is naturally responsible for his own request when carrying out the release. Even if a seal is defined for a role, technically separate seals are created for each individual member of the role.
NOTE: Requests or releases are only valid for the respective user!
CAUTION: If a user is a member of several roles of a seal, the "stronger" right is always applied. Release rights have a priority over read rights
1. Requesting a release
In order to release a seal for sealed passwords, this must be requested from the user with the required permissions to issue the release. Within the Netwrix Password Secure client, this can be done via the buttons Reveal and Seal in the ribbon, as well as via the Icon in the password field of the data record in the reading pane.
A modal window opens, which can be used to request the seal. The reason for the entry will be displayed to the users with the required permissions to issue the release.
All user with the required permissions to issue the release will be notified that the user has requested the seal. This can be viewed via the module Notifications, as well as in the Seal overview.
2. Granting a release
The Seal overview can be opened via the seal symbol in the ribbon directly from the mentioned notification. It is indicated by the corresponding icon that there is a need for action. All relevant data for a release are illustrated within the seal overview. The reason given in the release is also evident.
If the release is granted, the Inquirer Im Module Notifications will be informed. You can also open the seal directly from the ribbon and see the now released state.
3. Breaking the seal
As soon as the requesting user has received the number of the required releases, he will be informed via the notifications as usual. The seal can now be broken. From this point on, the user will be able to see the password.
Seal overview
What is the seal overview?
Users with the required permissions to issue the releases receive access to the current state of the existing seals at any time via the seal overview. The overview is accessible via the ribbon as well as the icon in the password field of the reading pane.
The four states of a seal
The seal overview provides an overview of all users who have access to the sealed data set. This is also the case when they receive the seal on the membership of a role. Functions for editing and removing existing seals are also available. In addition, the current state of the seal is displayed in the form of a release matrix. There are a total of four states, in which a seal can be:
1. Sealed
If a data record for a user is sealed, the user is prevented from seeing the password by the seal. This corresponds to the condition when a seal has been newly installed. By resetting a request via the icon at the right edge of the screen, current requests from individual users are also returned to the "sealed" state.
2. Release process
If a user has requested a release, it is in the release process. This status is highlighted by an icon next to the user name, since a possible release can be actively granted by the authorized user. These so-called important entries can also be filtered in the headline of the seal overview in via the column. The maximum duration of an release request can be configured in the advanced seal settings. If the deadline has elapsed without sufficient releases being made, the request is deleted and the state “sealed” is restored.
3. Released
If a release is granted, a seal is approved as released. The maximum duration of a granted release can be limited in the advanced seal settings. The user then has, for example, 24 hours to accept the release and break the seal.
4. Broken
The actual seal breach is obtained by acquiring knowledge of the release and by actively breaking the seal after a security query. Viewing the password is irrelevant. Once broken seals can be manually reset by the icon to the right of the broken seal column. The state “Sealed” is restored.
CAUTION: It makes no sense to re-seal already visible passwords. The user was able to view the password. Therefore, it is not monitorable whether the password has been saved, for example, by screenshot. In such cases, a new password is the only way to guarantee 100% password security!
Seals
What are seals?
Passwords are selectively made available to the different user groups by means of the Authorization and protection mechanisms. Nevertheless, there are many scenarios in which the ability to view and use a record should be linked to a release issued in advance. In this context, the seal is an effective protective mechanism. This multi-eye principle protects passwords by securing them with granular release mechanisms. If you want to see a password, this must be requested and released. The release can also be temporary.
Relevant rights
The following option is required to add a seal.
User right
- Can add seal
Required permissions
Firstly, the user must have the authorize permission for the record in order to create seals. The read permission to all users and roles that are contained in the seal is also required. The exact configuration of password masking and permissions for records is described in detail in the Authorization concept section.
What exactly is sealed?
Technically speaking, the password itself is not sealed. It is the permission to see a password field that is protected by a seal. This allows for the most sensitive configurations, in which one group can use the password without restrictions, but the same password is sealed for other users. The wizard assists users in applying seals, as well as in future maintenance.
CAUTION: The complete data set is never sealed! Only the permission to view a password is protected by a seal.
CAUTION: Be Aware" Only records that are protected with a password can be sealed!
Seal wizard
All seal configurations are performed in the wizard. Both the application of new seals as well as the processing and removing are possible. The current state of a seal can also be viewed in an overview, which is accessible via the button in the ribbon. When the seal wizard is opened via the ribbon, the wizard appears in the case of unsealed data sets, which runs in four steps through the configuration of the seal.
1. Apply seal
All objects that are sealed are displayed at the beginning. Depending on the data record, this can be one object, or several. It is also possible to use existing Seal templates. Optionally, you can enter a reason for each seal.
2. Multi-eye principle
The seal logic is the most basic element of this protective mechanism. Here, you define for which users or roles the record should be sealed or released in the future. All those for whom the record is to be sealed are displayed in red, while all users with the required permissions to issue a release are displayed in blue.
NOTE: All users and roles for which the data set is not sealed and which are not authorized for release are displayed in green. These can use the data record independently of the seal.
To avoid having to perform any configuration manually, roles and users are copied directly from the authorizations of the data record. Compare with the "permissions" for the record (can be viewed via the ribbon).
Supervisors should issue the releases for their employees. Therefore, the checkbox also follows the existing authorizations. The following scheme is used:
NOTE: All users and roles that have the authorize permission to the record are "authorized to issue a release" for the seal by default. All users and roles that do not have the authorize permissions to the record are copied directly into the "Sealed for" column.
Here is a closer look at the permissions of the role Administrators on the record:
Adjusting the seal logic
Although standard authorizations are used as a basis for the sealing concept, these can be adapted. The number of releases generally required is as configurable as the required number of releases from a role. In the following example, the seal has been extended so that a total of three release authorizations are required in order to release the seal (Multi-eye principle). The role of the administrators has been marked in the mandatory column. This means that it must grant at least one release. In summary: A total of three releases must be made, whereby the group of administrators must grant at least one release.
In order to be not only dependent on existing authorizations on the data set, other users can also be added to the seal. The role accounting under "sealed for" has been added below.
NOTE: When a role or a user is added to a seal, these users also receive permissions on the record according to the authorization granted in the seal. A role that is added under "Sealed for" receives the Read permission on the record. When you add authorization permissions, these will include the Read, Write, Delete, and Authorize permission.
CAUTION: All the roles that were once added to the seal can no longer be removed via the seal logic. This is only possible directly via the authorizations of the data record!
NOTE: It is possible to seal records for a user who is also authorized to issue a release. In this constellation, it is important to ensure that at least one other user is authorized to issue a release. In principle, you should never be able to issue a release for yourself.
3. Advanced settings
Advanced seal settings allow you to adjust the multi-eye principle. Both the time validity of a release request as well as a granted release can be configured. Multiple break defines whether after the breaking of a seal by a user, other users may still break it.
4. Saving the seal
Before closing the wizard, it is possible to save the configuration for later use in the form of a template. Seal templates can be optionally provided with a description for the purpose of overview.
Summary
The permissions already present on the data set form the basis for any complex seal configurations. It is freely definable which users have to go through a release mechanism before accessing the password. The roles, which may be granted, are freely definable. An always accessible Seal overview allows all authorized persons to view the current state of the seals. The section on theRelease mechanism describes in detail the individual steps, from the initial release request to the final release.