LJK/Security Reference Manual
DISMAIL
Determine whether disabling announcement of mail conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Mail announcement is enabled in violation of policy
|
|
REQUIRED
|
Mail announcement is disabled in violation of policy
|
Description
The DISMAIL authorization flag prevents messages when a user logs in
or when mail is delivered.
Tests from this element are not
conducted on Usernames allowed only Batch access, since such messages
are not issued.
Default policy
Disabling of mail announcement is prohibited
Customizing
Customization may be appropriate for users in a very
captive environment,
but it is more likely that the NOMAIL indication should be used to
prevent
those users from being sent mail in the first place
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
Announcement of mail when delivered or on
login can be viewed as a continuity-of-service consideration, although
even when enabled for a
particular username, individual announcements can still be suppressed
by end user action.
DISPWDDIC
Determine whether disabling of password dictionary screening conforms
to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Password dictionary screening is disabled in violation of policy
|
|
REQUIRED
|
Password dictionary screening is enabled in violation of policy
|
Description
Password dictionary screening is an important technique for preventing
selection of weak passwords by users. This test can be used to ensure
whether or not such screening is in force.
Tests from this element are not
conducted on Usernames allowed only Batch access, since passwords are
not meaningful.
Default policy
Disabling the password dictionary screening is
prohibited
Customizing
If there is a strong reason for allowing use of
versions of VMS earlier than VMS V5.4 at your site, you may wish to
establish exemptions for the test
PROHIBITED on certain nodes to have the value of TRY
rather than TRUE.
There is virtually no security-acceptable reason for allowing password
screening to be disabled on versions of VMS which are capable of it,
but the customization capability is provided
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations
Password dictionary screening only works for
password choices made with the SET PASSWORD command. It does not
prevent privileged users from selecting a weak password for themselves
or another user with the AUTHORIZE utility.
DISPWDFCHG
Determine whether forcing of password change on expiration conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Forced password change is disabled in violation of policy
|
|
REQUIRED
|
Forced password change is enabled in violation of policy
|
Description
The DISFORCE_EXP_PWD_CHANGE authorization flag disables forcing of
users to change their password on login if it has expired.
Tests from this element are not
conducted on Usernames allowed only Batch access, since passwords are
not meaningful.
Default policy
Forced password change is required for versions of VMS
which support it
Customizing
Set limit PROHIBITED to
be FALSE to remove the requirement for forced password change.
Set limit PROHIBITED to be TRUE to impose the
requirement for forced password change ON ALL versions of VMS (meaning
a violation on versions of VMS earlier than V5.0).
selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
TRY
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
<node>,<username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>,<username>
|
Practical considerations
There is very little reason to use the
DISFORCE_EXP_PWD_CHANGE flag. If it is set, then users can log in and
forget to change their password, meaning they will be locked out on the
next login attempt.
DISPWDHIS
Determine whether disabling of password history screening conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Password history screening is disabled in violation of policy
|
|
REQUIRED
|
Password history screening is enabled in violation of policy
|
Description
Password history screening is an important technique for preventing
reuse passwords by users. This test can be used to ensure whether or
not such screening is in force.
Tests from this element are not
conducted on Usernames allowed only Batch access, since passwords are
not meaningful.
Default policy
Disabling the password history screening is prohibited
Customizing
If there is a strong reason for allowing use of versions of
VMS earlier than VMS V5.4 at your site, you may wish to establish
exemptions for the test PROHIBITED on
certain nodes to have the value of TRY rather than
TRUE.
There is virtually no security-acceptable reason for allowing password
screening to be disabled on versions of VMS which are capable of it,
but the customization capability is provided
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE, TRUE or TRY
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations
Password history screening only works for
password choices made with the SET PASSWORD command. It does not
prevent privileged users from selecting a previously used password for
themselves or another user with the AUTHORIZE utility.
DISRECON
Determine whether disabling of reconnection conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Reconnection is disabled in violation of policy
|
|
REQUIRED
|
Reconnection is not disabled in violation of policy
|
Description
Individual usernames can be prohibited from reconnecting to detached
processes. The ability to reconnect (provided by the VMS virtual
terminal
mechanism) is generally viewed as a continuity of service feature. In
cases where a single username might have multiple
interactive jobs at the same time, prohibiting reconnection might be
appropriate in order to avoid confusion.
Terminal reconnection was originally developed as a
continuity-of-service feature.
Since then as concern about security has grown, the manual
DISCONNECT command has become more important as a method for
achieving what various security disciplines call "Session
Lock".
Tests from this element are not
conducted on Usernames not allowed Interactive access.
Default policy
Disabling of reconnection is neither prohibited nor
required
Customizing
Setting limits in combination
with exemptions can be used to PROHIBIT or REQUIRE
reconnection capability for particular usernames
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations
If allowing reconnection would cause confusion
due to sharing of usernames
between individuals, it is that sharing which should be addressed. If
multiple individuals have identical access requirements, they can be
assigned separate usernames with identical characteristics (including
UIC) while preserving separate passwords and process accountability.
DISREPORT
Determine whether disabling reporting of last login conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Reporting last login is disabled in violation of policy
|
|
REQUIRED
|
Reporting last login is enabled in violation of policy
|
Description
Reporting of last login time is an important technique for detecting
unauthorized use of usernames (since only the authorized individual is
in a position to know the proper last login).
Tests from this element are not
conducted on Usernames allowed only Batch access, since such messages
are not issued.
Default policy
Disabling the reporting of last login is prohibited
Customizing
There is virtually no security-acceptable reason for
disabling this notification, but like all tests, the customization
capability is provided
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
This notification is of no use unless end
users are trained to report suspicious incidents. Setting a false
"last login" value through
system programming can be used to test whether end users are in fact
going to report such incidents.
DISPWDSYNC
Determine whether password synchronization into VMS conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Password synchronization into VMS is enabled in violation of policy
|
|
REQUIRED
|
Password synchronization into VMS is disabled in violation of policy
|
Description
The DISPWDSYNC authorization flag indicates that the passwords used to
authenticate to non-VMS ACME agents should be stored by the VMS ACME
into SYSUAF for future use in VMS-only authentication.
Tests from this element are not
conducted on Usernames allowed only Batch access, since passwords are
not meaningful.
Default policy
Password synchronization is neither required nor
prohibited
Customizing
Use these tests to match how
you use external authentication
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations
If you do not use external authentication,
ignore this element.
DISUSER
Determine whether disabling of username conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Username is disabled in violation of policy
|
|
REQUIRED
|
Username is not disabled in violation of policy
|
Description
The DISUSER flag applied to a username entry in the authorization file
prevents logins under the username.
Default policy
Disabling of a username is neither prohibited nor
required
Customizing
Customization here can be used to track usernames
as outlined in
Section 11.2, Tracking Usernames
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
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 removing usernames from the
authorization file, many
system administrators prefer to set the DISUSER flag, so that any
attempts
against those usernames will include the username in the accounting
file.
If a username is not on the system at all, it is not included in the
accounting file record of a login failure.
DISWELCOME
Determine whether disabling welcome message conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Display of welcome message is disabled in violation of policy
|
|
REQUIRED
|
Display of welcome message is enabled in violation of policy
|
Description
Disabling the welcome message from being displayed to particular
usernames can be a security hazard if that message is typically used to
alert users to security-relevant information.
Tests from this element are not
conducted on Usernames allowed only Batch access, since such messages
are not issued.
Default policy
Disabling the welcome message is prohibited
Customizing
Disabling the Welcome message may be acceptable if is it not used for
security-relevant information
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
The Welcome message (received after successful
login) should not be confused with the Announce message (received just
before the username prompt).
Since the username is not known at the time the Announce message is
issued, there is no way to tailor the Announce message on a
per-username basis.
EXPIRATION
Determine whether expiration of username conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
RELATIVHI
|
Username expiration is too far away in violation of policy
|
|
RELTEMPHI
|
Username expiration is too far away in violation of policy
|
|
RELATIVLO
|
Username expiration is too soon in violation of policy
|
Description
Usernames which have expiration dates very far in the future will
possibly escape periodic review by appropriate authorities to determine
if the usernames
are still needed.
Usernames which expire very soon are presumably overdue for management
review.
If such usernames are allowed to expire when they are still needed, the
result will be increased user hostility toward security concerns in
general.
The constraints RELATIVHI and RELTEMPHI are equivalent
in function but intended for different use. The intent is that
constraint RELTEMPHI be the intended maximum lifetime
of usernames an organization defines as "temporary". The
normal long-term (nothing is "permanent") usernames would
each receive an exemption from the RELTEMPHI test.
Default policy
Usernames must have a remaining lifetime between 30 and
1000 days. The constraint RELTEMPHI has a value of
1000, providing no difference from constraint
RELATIVHI for organizations that do not create temporary usernames
Customizing
The default RELATIVLO limit should be
changed if you have a different need for warning about expiring
usernames. Exemptions are probably in order for the
SYSTEM username.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable
Selector
Limits
| Constraint |
Value |
Default |
|
RELATIVHI
|
0---n (days)
|
1000
|
|
RELTEMPHI
|
0---n (days)
|
1000
|
|
RELATIVLO
|
0---n (days)
|
30
|
Exemptions
| Constraint |
Value |
Parameters |
|
RELATIVHI
|
0---n (days)
|
<node>, <username>
|
|
RELTEMPHI
|
0---n (days)
|
<node>, <username>
|
|
RELATIVLO
|
0---n (days)
|
<node>, <username>
|
Practical considerations
Limited username lifetime will only be
acceptable if you provide timely
notification in advance of expiration to those who might care if a
username becomes unavailable.
EXTAUTH
Determine whether external authentication conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
External authentication is enabled in violation of policy
|
|
REQUIRED
|
External authentication is disabled in violation of policy
|
Description
The EXTAUTH authorization flag indicates that non-VMS ACME agents are
allowed to authenticate this user.
Tests from this element are not
conducted on Usernames allowed only Batch access, since passwords are
not meaningful.
Default policy
External authentication is neither required nor
prohibited
Customizing
Use these tests to match how
you use external authentication
Selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations
If you do not use external authentication,
ignore this element.