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 may allow access by unauthorized individuals.
Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

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.
Tests from this element are not conducted on Usernames allowed only Batch access, since passwords are not meaningful.

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.

The node name in an exemption for the USAGE facility can include standard VMS wildcard characters (% and *).

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
CNSS and NIST 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
CNSS and NIST 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.

Note
The CLUSTER tests are performed even when the USAGE facility is disabled because:

Use of the BRIEF method or disabling assessment of the USAGE facility manually is commonly used to save time.
The CLUSTER tests are much more efficient than other tests within the USAGE facility.
Measuring the most recent history of running assessments is critical for understanding whether product is being used effectively.

Default policy

See table below

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.

Contents

Index