LJK/Security Reference Manual
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.
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.
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 last login is considerable time ago, the username in question
may not actually be in use and possibly should be disabled.
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)
|
10000
|
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 locking of password 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.
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.
MAXACCTJOB
Determine whether specification of maximum jobs for account conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTLO
|
Maximum jobs for account is lower than allowed by policy
|
|
ABSOLUTHI
|
Maximum jobs for account is higher than allowed by policy
|
Description
User authorization field MAXACCTJOBS limits the number of simultaneous
batch, interactive and detached jobs which may be active on behalf of
users who share a single ACCOUNT value
in their authorization file records.
Default policy No limit is enforced. Customizing Customize if you feel
a need to enforce such a limit. selector Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
0---n
|
0
|
|
ABSOLUTHI
|
0---n
|
0
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTLO
|
0---n
|
<node>, <username>
|
|
ABSOLUTHI
|
0---n
|
<node>, <username>
|
Practical considerations Most sites do not use this limitation
capability except for particular chargeback reasons.
MAXDETACH
Determine whether specification of maximum detached jobs conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTLO
|
Maximum detached jobs is lower than allowed by policy
|
|
ABSOLUTHI
|
Maximum detached jobs is lower than allowed by policy
|
Description
User authorization field MAXDETACH limits the number of simultaneous
detached jobs which may be active on behalf of users who share a single
ACCOUNT value
in their authorization file records.
Default policy No limit is enforced. Customizing Customize if you feel
a need to enforce such a limit.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
0---n
|
0
|
|
ABSOLUTHI
|
0---n
|
0
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTLO
|
0---n
|
<node>, <username>
|
|
ABSOLUTHI
|
0---n
|
<node>, <username>
|
Practical considerations Most sites do not use this limitation
capability except for particular chargeback reasons.
MAXJOBS
Determine whether specification of maximum jobs for username conforms
to policy.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTLO
|
Maximum jobs for username is lower than allowed by policy
|
|
ABSOLUTHI
|
Maximum jobs for username is higher than allowed by policy
|
Description
User authorization field MAXJOBS limits the number of simultaneous
batch, interactive, network and detached jobs which may be active on
behalf of a single username.
The first 4 network jobs are not counted.
Default policy No limit is enforced. Customizing Customize if you feel
a need to enforce such a limit.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
0---n
|
0
|
|
ABSOLUTHI
|
0---n
|
0
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTLO
|
0---n
|
<node>, <username>
|
|
ABSOLUTHI
|
0---n
|
<node>, <username>
|
Practical considerations Most sites do not use this limitation
capability except for particular chargeback reasons.
MIGRATEPWD
Determine whether sharing password changes conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Sharing password changes is enabled in violation of policy
|
|
REQUIRED
|
Sharing password changes is disabled in violation of policy
|
Description
The MIGRATEPWD authorization flag indicates that the passwords changes
made to one ACME agent are shared with others.
Default policy Password sharing 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.