LJK/Security Reference Manual
Previous Contents Index

GENPWD

Determine whether requirement for generated password conforms to policy.

Violation reports

Constraint Nature of the violation
PROHIBITED Generated password requirement is enabled in violation of policy
REQUIRED Generated password requirement is disabled in violation of policy

Description

Requiring users to choose only generated passwords reduces the chances that passwords can be guessed, but may increase the chance they will be written down.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

Requirement for generated passwords is prohibited

Customizing

Change the limits if your rule is to require generated passwords

Selector

Limits

Constraint Value Default
PROHIBITED FALSE or TRUE TRUE
REQUIRED FALSE or TRUE FALSE

Exemptions

Constraint Value Parameters
PROHIBITED FALSE or TRUE <node>, <username>
REQUIRED FALSE or TRUE <node>, <username>

Practical considerations

Even if generated passwords are not required, individual users are still free to ask for automatic password generation as part of their periodic password changes.

GRPNAM

Determine whether a user with GRPNAM privilege shares a UIC group with a more privileged user.

Violation reports

Constraint Nature of the violation
PRIVPROHIB GRPNAM user shares a UIC group with more privileged users in violation of policy
ABSOLUTHI GRPNAM user shares a UIC group with more privileged users in violation of policy

Description

The GRPNAM privilege allows a user to make group logical name table entries which could affect other users in that group. In the case where a more privileged user is in the same group, the actions of that user could be subverted.

Default policy

Users with GRPNAM privilege are forbidden to be in the same group with more privileged users

Customizing

Set limit PROHIBITED to be FALSE to remove the prohibition against users with GRPNAM privilege sharing UIC groups with more privileged users. selector Limits and exemptions for test PRIVPROHIB can take a selector consisting of a privilege name.

Thus, it can be set once for each possible privilege. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges.

Limits

Constraint Value Default
PRIVPROHIB FALSE or TRUE FALSE
ABSOLUTHI Category-None---Category-All Category-None

Exemptions

Constraint Value Parameters
PRIVPROHIB FALSE or TRUE <node>,<username>
ABSOLUTHI Category-None---Category-All <node>,<username>

Practical considerations

Many historic reasons for needing the GRPNAM privilege are no longer true.

The test ABSOLUTHI is sufficient to express simpler limitations based on privilege level.

If a more complicated selection of privileges is required, it may be necessary to use the test PRIVPROHIB.

GRPPRV

Determine whether a user with GRPPRV privilege shares a UIC group with a more privileged user.

Violation reports

Constraint Nature of the violation
PRIVPROHIB GRPPRV user shares a UIC group with more privileged users in violation of policy
ABSOLUTHI GRPPRV user shares a UIC group with more privileged users in violation of policy

Description

The GRPPRV privilege allows a user to access files of other users in the same UIC group. In the case where a more privileged user is in the same group, the actions of that user could be subverted.

Default policy

Users with GRPPRV privilege are forbidden to be in the same group with more privileged users

Customizing

Set limit PROHIBITED to be FALSE to remove the prohibition against users with GRPPRV privilege sharing UIC groups with more privileged users. selector Limits and exemptions for test PRIVPROHIB can take a selector consisting of a privilege name.

Thus, it can be set once for each possible privilege. When using the Command Interface if you do not specify a selector when changing the limit or exemptions your change applies to all privileges.

Limits

Constraint Value Default
PRIVPROHIB FALSE or TRUE FALSE
ABSOLUTHI Category-None---Category-All Category-None

Exemptions

Constraint Value Parameters
PRIVPROHIB FALSE or TRUE <node>,<username>
ABSOLUTHI Category-None---Category-All <node>,<username>

Practical considerations

The easiest approach to solving this problem is probably to reduce the privileges of the more-privileged user.

The test ABSOLUTHI is sufficient to express simpler limitations based on privilege level.

If a more complicated selection of privileges is required, it may be necessary to use the test PRIVPROHIB.

HOURSPRI

Determine how much access is allowed on primary days.

Violation reports

Constraint Nature of the violation
ABSOLUTLO Access fewer than minimum hours in policy
ABSOLUTHI Access more than maximum hours in policy

Description

As delivered, VMS provides a DEFAULT authorization record allowing access 24 hours a day every day of the week. This may be required for those who work at odd hours or must be prepared to dial in from home, but it is not generally appropriate for those who use VMS in a production-oriented environment.

The purpose of this test is to ensure that usernames have restricted access hours, in accordance with local policy. The tests deal only with numbers of hours, rather than particular hours, so that someone working an evening shift can be tested by the same criteria as someone on day shift.

This test is for hours on "primary" days of the week. See test HOURSSEC for other days.

Default policy

Each username is tested against a minimum of 7 and a maximum of 9 hours access per day

Customizing

These limits can be set as appropriate for your environment

Selector

Limits

Constraint Value Default
ABSOLUTLO 0---24 7
ABSOLUTHI 0---24 9

Exemptions

Constraint Value Parameters
ABSOLUTLO 0---24 <node>, <username>
ABSOLUTHI 0---24 <node>, <username>

Practical considerations

Given a low setting of limit (UAF, HOURSPRI, ABSOLUTHI) as is recommended and the default, exemptions should be added for system management personnel who need access at all hours.

Like other aspects of LJK/Security, there is no form of control asserted, but the result would be violation reports for all system management personnel whose usernames are set to allow unrestricted access. As with other instances of a "management by exception" approach, avoiding a noise level through appropriate use of exemptions allows security personnel reviewing assessment reports to concentrate on the real problems.

HOURSSEC

Determine how much access is allowed on secondary days.

Violation reports

Constraint Nature of the violation
ABSOLUTLO Access fewer than minimum hours in policy
ABSOLUTHI Access more than maximum hours in policy

Description

As delivered, VMS provides a DEFAULT authorization record allowing access 24 hours a day every day of the week. This may be required for those who work at odd hours or must be prepared to dial in from home, but it is not generally appropriate for those who use VMS in a production-oriented environment.

The purpose of this test is to ensure that usernames have restricted access hours, in accordance with local policy. The tests deal only with numbers of hours, rather than particular hours, so that someone working an evening shift can be tested by the same criteria as someone on day shift.

This test is for hours on "secondary" days of the week. See test HOURSPRI for other days.

Default policy

Each username is tested against a minimum and a maximum of 0 hours access per day

Customizing

These limits can be set as appropriate for your environment

Selector

Limits

Constraint Value Default
ABSOLUTLO 0---24 0
ABSOLUTHI 0---24 0

Exemptions

Constraint Value Parameters
ABSOLUTLO 0---24 <node>, <username>
ABSOLUTHI 0---24 <node>, <username>

Practical considerations

Given a low setting of limit (UAF, HOURSSEC, ABSOLUTHI) as is recommended and the default, exemptions should be added for system management personnel who need access at all hours.

Like other aspects of LJK/Security, there is no form of control asserted, but the result would be violation reports for all system management personnel whose usernames are set to allow unrestricted access. As with other instances of a "management by exception" approach, avoiding a noise level through appropriate use of exemptions allows security personnel reviewing assessment reports to concentrate on the real problems.

IMPARTIAL

Determine whether assessments are conducted by recently created Usernames, as distinguished from long-term employees.

Violation reports

Constraint Nature of the violation
CERTIFY Username running assessment was created too long ago in violation of policy
CONTINUING Username running assessment was created too long ago in violation of policy
PERIODIC Username running assessment was created too long ago in violation of policy

Description

When a username involved the assessment is owned by long term user, the independence of the assessor from the operational management chain is subject to question.

This applies to both the individual running the overall assessment and the individuals using the command MCR LJK$SECURITY ANSWER on the tributary nodes.

Note
For the case of the individual running the overall assessment, these test are performed on the master node rather than on the tributary nodes, regardless of whether or not the master node is part of the assessment.

If the master node is not part of the assessment, violations will be reported as coming from the first tributary node in the assessment, based on the limits in the policy used for that tributary node.

Note
For the case of the individuals using the command MCR LJK$SECURITY ANSWER on the tributary nodes, this information will be gathered even when neither the quick method nor the automatic method is specified for that tributary node, since that is the only time it can be collected.

If the master node is not part of the assessment, violations will be reported as coming from the first tributary node in the assessment, based on the limits in the policy used for that tributary node.

Default policy

There is no requirement regarding the age of the username running the assessment

Customizing

Modify the limits to comply with an organizational requirement independence of assessors.

A limit or exemption with a value of zero means there is no value which is considered unacceptable

Selector

Limits

Constraint Value Default
CERTIFY 0---n (days) 0
CONTINUING 0---n (days) 0
PERIODIC 0---n (days) 0

Exemptions

Constraint Value Parameters
CERTIFY 0---n (days) <node>, <username>
CONTINUING 0---n (days) <node>, <username>
PERIODIC 0---n (days) <node>, <username>

Practical considerations

This test is not a complete indication of compliance with impartiality requirements (or not).

LASTLOGIN

Determine whether last login time conforms to policy.

Violation reports

Constraint Nature of the violation
EITHER Last login of any type is too long ago in violation of policy
INTERACT Last interactive login is too long ago in violation of policy
OTHER Last non-interactive login is too long ago in violation of policy

Description

When the EITHER last login is considerable time ago, the username in question may not actually be in use and possibly should be disabled.

When the INTERACT or OTHER last login is considerable time ago, the username in question has been granted access it is not using.

Default policy

Last interactive login must have been in the past 30 days

Customizing

Modify the limits if your tolerance for username inactivity is different from the default.

A limit or exemption with a value of zero means there is no value which is considered unacceptable

Selector

Limits

Constraint Value Default
EITHER 0---n (days) 30
INTERACT 0---n (days) 30
OTHER 0---n (days) 30

Exemptions

Constraint Value Parameters
EITHER 0---n (days) <node>, <username>
INTERACT 0---n (days) <node>, <username>
OTHER 0---n (days) <node>, <username>

Practical considerations

The test ( UAF, LASTLOGIN, OTHER ) in most cases should be quite large, since many individuals use only interactive access.

LOCKPWD

Determine whether a prohibition against users changing their passwords conforms to policy.

Violation reports

Constraint Nature of the violation
PROHIBITED Locked password is enabled in violation of policy
REQUIRED Locked password is disabled in violation of policy

Description

Except in the case of usernames shared between individuals (generally undesirable from the security standpoint anyway), locking passwords is widely acknowledged as a bad security practice.

These tests do not report a violation if the username under consideration has the DISUSER flag set. This is done to avoid false violation notices when sites retain old usernames with the DISUSER flag set to facilitate analysis of past audit logs and to guard against re-use of usernames or UICs.

Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

Default policy

Locking of password is prohibited

Customizing

Exemptions to the PROHIBITED test should be sufficient to take care of exceptional cases

Selector

Limits

Constraint Value Default
PROHIBITED FALSE or TRUE TRUE
REQUIRED FALSE or TRUE FALSE

Exemptions

Constraint Value Parameters
PROHIBITED FALSE or TRUE <node>, <username>
REQUIRED FALSE or TRUE <node>, <username>

Practical considerations

Rather than shared passwords, usernames without a password are often used (avoiding the appearance that sharing passwords is ever permissible). In that case, passwords should be locked to prevent one user from adding a password.

LOGFAIL

Determine whether existence of login failures conforms to policy.

Violation reports

Constraint Nature of the violation
FAILURES Number of login failures exceeds policy

Description

Login failures are brought to the attention of a user when they log in. These tests can provide information about login failures against inactive usernames.

Default policy

Login failures since the last successful login cannot exceed 3

Customizing

Some cases of mistaken node identity may warrant exemptions, where users attempt a login to the wrong node with a valid username.

Unlike many other tests, a value of zero means there is a test and no failures are allowed

Selector

Limits

Constraint Value Default
FAILURES 0---n 3

Exemptions

Constraint Value Parameters
FAILURES 0---n <node>, <username>

Practical considerations

This counter is reset with each successful login to the username in question. For inactive usernames, a careful attacker who limits the number of attempts on any given occasion (to avoid VMS breakin detection) still leaves a trace which can be reported by this test. If the username is so inactive that the failure count gets high, the reason for an inactive username should be addressed.

Previous Next Contents Index