LJK/Security Reference Manual
PWDNULL
Determine whether use of null passwords conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
CAPTIVE
|
Null password username is not set as Captive
|
|
MUSTAUTO
|
Null password username is not set as autologin-only
|
|
MUSTLOCK
|
Null password username does not have password locked
|
|
PRIMAXPRIV
|
Maximum privilege category allowed to have a null primary password
|
|
PRIPROHIB
|
Has null primary password in violation of policy
|
|
PRIREQUIRE
|
Lacks null primary password in violation of policy
|
|
SECMAXPRIV
|
Maximum privilege category allowed to have a null secondary password
|
|
SECPROHIB
|
Has null secondary password in violation of policy
|
|
SECREQUIRE
|
Lacks null secondary password in violation of policy
|
Description
Null passwords allow access by unauthorized individuals.
Default policy Use of null primary passwords is prohibited. Use of null
secondary passwords is required (in other words, secondary passwords
are prohibited).
Customizing Add exemptions for specific usernames
which are to be allowed to have null passwords. selector Limits
| Constraint |
Value |
Default |
|
CAPTIVE
|
Category-None---Category-All
|
Category-Normal
|
|
MUSTAUTO
|
Category-None---Category-All
|
Category-Normal
|
|
MUSTLOCK
|
Category-None---Category-All
|
Category-Normal
|
|
PRIMAXPRIV
|
Category-None---Category-All
|
Category-Normal
|
|
PRIPROHIB
|
FALSE or TRUE
|
TRUE
|
|
PRIREQUIRE
|
FALSE or TRUE
|
FALSE
|
|
SECMAXPRIV
|
Category-None---Category-All
|
Category-All
|
|
SECPROHIB
|
FALSE or TRUE
|
FALSE
|
|
SECREQUIRE
|
FALSE or TRUE
|
TRUE
|
Exemptions
| Constraint |
Value |
Parameters |
|
CAPTIVE
|
Category-None---Category-All
|
<node>, <username>
|
|
MUSTAUTO
|
Category-None---Category-All
|
<node>, <username>
|
|
MUSTLOCK
|
Category-None---Category-All
|
<node>, <username>
|
|
PRIMAXPRIV
|
Category-None---Category-All
|
<node>, <username>
|
|
PRIPROHIB
|
FALSE or TRUE
|
<node>,<username>
|
|
PRIREQUIRE
|
FALSE or TRUE
|
<node>,<username>
|
|
SECMAXPRIV
|
Category-None---Category-All
|
<node>, <username>
|
|
SECPROHIB
|
FALSE or TRUE
|
<node>,<username>
|
|
SECREQUIRE
|
FALSE or TRUE
|
<node>,<username>
|
Practical considerations Changing the limit to allow
unrestricted use of null primary passwords effectively turns oversight
of null passwords over to individual system administrators.
The %%%MAXPRIV constraints were added to allow support
of a privilege-dependent policy for null secondary passwords. As it
turns out, the %%%MAXPRIV constraints can accomplish
everything done by the %%%PROHIB constraints
except for prohibiting null passwords for usernames that have
no privileges.
Changing the limit or exemptions to
allow use of secondary passwords may lead to a false sense of security
by those who do not realize that in the hands of a single individual, a
single more obscure password is just as good.
QUEPRIO
Determine whether a username's maximum queue priority conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTLO
|
Username's maximum queue priority is lower than permitted by policy
|
|
ABSOLUTHI
|
Username's maximum queue priority is higher than permitted by policy
|
Description
Intended to store a username's maximum queue priority, this field is
not actually used by current values of VMS.
Default policy Defaults are a minimum of 0 and a maximum of 4, to
correspond to the values which happen to be left in the field by the
VMS utility AUTHORIZE. Customizing No customization should be
necessary. selector Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
0---255
|
0
|
|
ABSOLUTHI
|
0---255
|
4
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTLO
|
0---255
|
<node>, <username>
|
|
ABSOLUTHI
|
0---255
|
<node>, <username>
|
Practical considerations
This test exists in case later versions of VMS make use of the
authorization field.
RESTRICTED
Determine whether designation as restricted account conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Restricted flag is enabled in violation of policy
|
|
REQUIRED
|
Restricted flag is disabled in violation of policy
|
Description
The RESTRICTED authorization flag prevents a user from avoiding a login
command procedure by disabling some techniques commonly used to escape
such procedures.
Default policy Restricted flag is neither prohibited nor required.
Customizing Set limit REQUIRED to be TRUE to force
restriction in general. Add exemptions to allow
particular usernames to avoid restriction.
Set limit REQUIRED to be TRY to force restriction only
on those versions of VMS where the RESTRICTED flag is supported (VMS
version 5.2 and greater).
selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE, TRUE or TRY
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>,<username>
|
|
REQUIRED
|
FALSE, TRUE or TRY
|
<node>,<username>
|
Practical considerations
The RESTRICTED flag is implemented effective with VMS Version 5.2. For
the future its purpose is to maintain the user in a confined
environment until all login command procedures have executed, while the
purpose of the CAPTIVE flag is to maintain the user in a confined
environment throughout a session.
UICPRIV
Ensure usernames with different privileges do not share UICs.
Violation reports
| Constraint |
Nature of the violation |
|
PRIVPROHIB
|
Username sharing UIC with one more privileged
|
|
ABSOLUTHI
|
Username sharing UIC with one more privileged
|
Description
If a username shares a UIC with another username which has more
privilege, it can readily subvert the privileges of the more privileged
username by tactics such as changing the login command file.
Default policy Any difference in privilege between two usernames
sharing a UIC is prohibited. Customizing RELAXATION of the default
limits or establishment of exemptions
for these tests should only be done after an
extremely thorough security review.
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. selector
Limits and exemptions for
test PRIVPROHIB can take a selector
consisting of a privilege name.
Thus, each 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>,<filespec>
|
|
ABSOLUTHI
|
Category-None---Category-All
|
<node>, <username>
|
Practical considerations Users who wish to simulate a less privileged
environment can do so with the VMS command SET PRIVILEGE followed by
the VMS command SPAWN.
If a more complicated selection of privileges is required, it may be
necessary to use the test PRIVPROHIB.
UICSHARE
Ensure the number of usernames sharing a UIC does not exceed policy
maximum.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTHI
|
Username sharing UIC with more than permitted
|
Description
Sharing UICs without reason is a security exposure, while UICs must be
shared in some cases (e.g., identical functions on multiple shifts).
This test compares the number of usernames sharing a
UIC with an organization-specific maximum.
Default policy A maximum of 5 usernames can share a UIC. Customizing
Any exemption must be set up for all
usernames sharing a UIC. The tightest restriction that can be set is a
value of 1, since each username at least share it's UIC with itself.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
ABSOLUTHI
|
0-n
|
5
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTHI
|
0-n
|
<node>, <username>
|
Practical considerations Sharing UICs can actually be of security
benefit, in cases where it is applied to users of a common application
who would otherwise share a username and password. For existing
applications with built-in limitations, UIC sharing can sometimes be
the only recourse until the application is replaced.
USRDATOFF
Determine whether presence of site-specific UAF data area conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Site-specific UAF data is present in violation of policy
|
|
REQUIRED
|
Site-specific UAF data is absent in violation of policy
|
Description
Some sites use this optional area of the authorization file records to
store authorized data (including security-relevant data in some cases).
Attackers have been known to use this area to store data associated with
their breakin efforts.
As a result, each site should ensure that the presence or absence of
this field matches their intent.
Default policy Existence of a site-specific UAF data area is
prohibited. Customizing Modify both limits if you use
the data area on all your nodes. Exemptions should be
only on a node-by-node basis with a wildcard "*" for username
since information only maintained for certain usernames can be kept in
another file. 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 If a site uses the site-specific data field,
regular program runs should be made to ensure the field is being used
only for its authorized purpose.
VMSAUTH
Determine whether ability of user to avoid external authentication
conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
User is allowed to avoid external authentication in violation of policy
|
|
REQUIRED
|
User is not allowed to avoid external authentication in violation of
policy
|
Description
The VMSAUTH authorization flag indicates that the user can choose to
authenticate directly to the VMS ACME Agent.
Default policy The ability of the user to avoid external authentication
is neither required nor prohibited. Customizing This capability should
be available to system managers for troubleshooting. 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 Unskilled users can get themselves confused
with this capability by losing password synchronization between
multiple ACME Agents.
6.9 USAGE tests
Tests in the USAGE facility deal with the record of
past events on the system, largely based on the VMS Audit logs.
Exemptions are based on node name and
one of
- Absolute Time (dd-mmm-yyyy:hh:mm:ss.hh)
e.g. 4-Mar-2009 21:56:13.12, to exempt an event at the specified time.
- Earliest Time ("<="dd-mmm-yyyy:hh:mm:ss.hh)
e.g. <=4-Mar-2009 21:56:13.12, to exempt an event at or prior to the
specified time.
Unlike exemptions for other facilities,
value associated with the exemption
does not matter. Any event for the specified test that
matches the node and date criteria is
exempted.
For the Earliest Time form of exemption, the latest
such time specified also covers all prior dates, so LJK/Security will
only maintain a single exemption of the Earliest Time form at a time.
product compares date-based exemptions on a
"close-enough" basis, ignoring possible minute differences
that are not visible in the full ASCII representation of a time. (Those
representations only go down to one-hundredth of a second, while VMS
binary time representations can have differences down to the
100-nanosecond level.)
ASSESSMENT
Ensure frequency of past security assessments conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
CERTIFY
|
Two consecutive assessments for the selected facility or
pseudo-facility were separated by more than the maximum interval
|
|
CLUSTER
|
Most recent assessment of another cluster member for the selected
facility or pseudo-facility is longer ago than the maximum interval
|
|
CONTINUING
|
Two consecutive assessments for the selected facility or
pseudo-facility were separated by more than the maximum interval
|
|
PERIODIC
|
Two consecutive assessments for the selected facility or
pseudo-facility were separated by more than the maximum interval
|
Description
The tests for this element determine
whether the intervals between past assessments conform to policy. The
tests for each of the constraints
have different purposes:
- CERTIFY - The assessment for the periodic certification and
accreditation
- CLUSTER - Most recent assessment of another cluster member
The
nature of a VMS cluster is such that all members are necessarily part
of the same security domain and thus must be subject to the same
standards.
- CONTINUING - Ongoing assessments
FISMA documentation calls this
"continuous monitoring" under CA-7
while DoD Instruction 8500.2 calls it "vulnerability
assessment"
under control VIVM-1.
- PERIODIC - An assessment less frequent that CONTINUING but
potentially more through
FISMA documentation calls this
"security assessment" under CA-2
while DoD Instruction 8500.2 calls it "conformance testing"
under control ECMT-1 or ECMT-2.
The CLUSTER constraint is the only one whose
test is different. It covers just the most recent
assessment while the others go back in history. The
others could be used for different purposes than described in this
documentation, at the risk of confusing the successor of those who make
such a change.
Default policy The most frequent interval is one day for quick
facilities and seven days for slow facilities. Customizing A more
aggressive approach than the default would be to have a time interval
of 1 hour for quick facilities and one day for slow facilities (DISK
and USAGE). selector
Limits and exemptions for
test PRIVPROHIB can take a selector
consisting of a facility or pseudo-facility name.
Thus, each can be set once for each possible facility or
pseudo-facility. When using the Command Interface if you do not specify
a selector when changing the limit or
exemptions your change applies to all facility and
pseudo-facilities.
Limits
| Constraint |
Value |
Default |
|
CERTIFY
|
time-interval
|
9999 days
|
|
CLUSTER
|
time-interval
|
one day for quick facilities, seven days for slow facilities
|
|
CONTINUING
|
time-interval
|
one day for quick facilities, seven days for slow facilities
|
|
PERIODIC
|
time-interval
|
one year
|
Exemptions
| Constraint |
Value |
Parameters |
|
CERTIFY
|
time-interval
|
<node>,<absolute-time> or <earliest-time>
|
|
CLUSTER
|
time-interval
|
<node>,<absolute-time> or <earliest-time>
|
|
CONTINUING
|
time-interval
|
<node>,<absolute-time> or <earliest-time>
|
|
PERIODIC
|
time-interval
|
<node>,<absolute-time> or <earliest-time>
|
Practical considerations Adding exemptions based on
earliest-time may be appropriate for situations where use of
product is introduced late in the game. The
earliest-time specified cannot be later than the time at which the
exemption is added.