This appendix lists the use of privilege by LJK/Security.

The LJK/Security software is installed with privileges, but turns those privileges off except when needed. At those times, it enables appropriate privileges, but only if the user has the appropriate facility-specific identifiers for a particular function, as discussed in Section 5.4, Privileges Required to Invoke Commands.

I.1 Reading and Writing Policy, Assessment and Result Files

LJK/Security uses SYSPRV privilege to read and write Policy, Assessment and Result files stored in LJK$SECURITY_POLICY_AREA:, LJK$SECURITY_RESULT_AREA: and LJK$SECURITY_ACTION_AREA:.

I.2 Reading the User Authorization File

LJK/Security uses READALL privilege to read the User Authorization File (SYSUAF) retrieving information about usernames established on the system along with their privileges and other security-relevant information.

I.3 Getting a List of All Devices

LJK/Security uses CMKRNL privilege to determine the names of all devices on the system. As of VMS V4.2 (the earliest version under which LJK/Security can be run), DEC provided no supported interface to accomplish this.

I.4 Checking Disk File Protection and Backup Date

LJK/Security uses READALL to check protection and backup date of disk files.

I.5 Checking Disk Quota Values

LJK/Security uses READALL to check disk quota values.

I.6 Synchronizing between LJK/Security Processes

LJK/Security uses SYSLCK to synchronize between LJK/Security processes.

I.7 Setting up LJK/Security DECnet Object Database Entries

For DECnet Phase IV, LJK/Security uses OPER and BYPASS to set up LJK/Security DECnet object database entries.

For DECnet Phase V, LJK/Security uses OPER and SYSPRV to set up LJK/Security DECnet object database entries.

I.8 Reading DECnet Database Entries

For DECnet Phase IV, LJK/Security uses SYSPRV to read DECnet database entries.

For DECnet Phase V, LJK/Security uses SYSPRV and OPER to read DECnet database entries.

I.9 Creating Detached LJK/Security Processes

LJK/Security uses the IMPERSONATE (DETACH) privilege to create detached LJK/Security processes.

I.10 Reading Files for Kit Building

LJK/Security uses READALL for kit building, in case a site has modified protection of images which must be included in the kits.

I.11 Parsing the User Authorization File Specification

LJK/Security uses READALL privilege to parse the User Authorization File (SYSUAF) specification for test VMS_SYSUAF_LOCATION.

I.12 Reading Accounting State

LJK/Security uses CMEXEC privilege to read the current status of VMS Accounting for facility ACC.

I.13 Reading Audit State

LJK/Security uses CMEXEC, CMKRNL, WORLD and READALL privileges to read the current status of VMS Auditing for facility AUDIT.

I.14 Reading Device Access Control Lists

LJK/Security uses READALL and SHARE privileges to read Access Control Lists for devices.

I.15 Reading Terminal Access Control Lists

LJK/Security uses READALL and SHARE privileges to read Access Control Lists for terminals.

I.16 Reading the System Rights List

LJK/Security uses CMEXEC privilege to read the System Rights List.

I.17 Reading the list of Installed Images

LJK/Security uses CMEXEC privilege to read the VMS list of Installed Images.

I.18 Highwater Marking and Erase-on-Delete

LJK/Security uses CMKRNL privilege to read the status of disk volumes regarding Highwater Marking and volume-wide Erase-on-Delete status.

I.19 Checking Privilege

LJK/Security uses AUDIT privilege on versions of VMS which support the $CHECK_PRIVILEGE system service (e.g., VMS V6.0 and beyond) to call the $CHECK_PRIVILEGE system service and create the corresponding VMS system audit entries as specified in the local audit server configuration.

I.20 System Owned Locks

LJK/Security uses CMEXEC privilege to designate certain locks as system-owned because they hold data that persists beyond image rundown.

I.21 Creating detached processes running LOGINOUT

LJK/Security uses SETPRV privilege to create detached processes running LOGINOUT so they can set appropriate privileges for the process.

I.22 Calling SYS$IDTOASC

LJK/Security uses CMKRNL privilege to call the SYS$IDTOASC system service due to inappropriate caching (as of VMS V7.3) within VMS Executive module SYSRDBRES preventing proper access to NAME_HIDDEN identifiers.

I.23 Suppression of Detailed Auditing

On VMS Version 6.0 and later, LJK/Security uses IMPERSONATE privilege to suppress detailed auditing (for instance on each use of privilege) while conducting an assessment on tributary nodes.

This appendix describes steps taken to ensure the security of LJK/Security itself.

The following design decisions were made to enhance the security of LJK/Security:

• Disables, limits and exemptions for individual tests are stored within policies on the master node, to defend against tampering on tributary nodes.
• Result files (created when an assessment is run or scheduled to be run) contain the necessary policy and assessment data as of the time the result file was created. It is this rendition of the policies and assessment which is used in further processing, to thwart attempts at revisionist history.

It should be noted that provision of site specific code in images named LJK$SECURITY_SITE_SHARE_AXP.EXE or LJK$SECURITY_SITE_SHARE_VAX.EXE declares a high degree of trust in that site specific code, equal to that placed in LJK/Security.

This appendix explains the example policies provided by LJK/Security for published requirement lists such as NIST Special Publication 800-53.

LJK/Security creates new policies with reasonable general-purpose limits and allows full tailoring by customers. But some of that tailoring can be laborious even before one gets to locality-specific considerations.

K.1 Example Command Procedures

To ease some of that burden, the following DCL command procedures are provided on the master node in directory LJK$SECURITY_EXAMPLES: after installation. Each such command procedure takes a single parameter which is the name of the policy to which it will be applied.

K.1.1 POLICY_NULL.COM

This command procedure neutralizes any existing policy settings (such as those LJK/Security creates by default) to allow subsequent commands to work on a "clean slate". Use this command procedure before other command procedures if you want to avoid the LJK/Security default best practices recommendations.

K.1.2 FISMA

These command procedures establish policy settings that follow the US Federal Information Security Management Act of 2002 as elaborated by US Federal Information Processing Standard 200 (FIPS 200) and the United States National Institute of Standards and Technology Special Publication 800-53 (initially published February 28, 2005) entitled Recommended Security Controls for Federal Information Systems. Although that publication is only directly required for US government systems, it is worth studying by anyone involved in computer security in the US private sector or in other countries.

But these command procedures are just a starter toward security assessments that comply with 800-53. That document specifies some areas in which local assignments of values must be made, and the choices made by LJK Software in these command procedures may not be the ones that are best for your organization. Furthermore, in the case of the (AUDIT,FIN*,REQUIRED) tests, these command procedures set four conflicting goals as all required. That should make it quite clear that you must make a site-specific choice of strategy in that case. Crashing VMS in the event of an audit problem could be a very bad choice, for instance in a hospital system.

These command procedures provides limits in accordance with 800-53 control SI-07, but exemptions for the VMS TCB are required to complement those limits. Use the command procedures described in Section K.1.4, according to platform (VAX or Alpha), choice of checksum algorithm (simple or SHA-1) and the particular version of VMS that is being run. Execute the NIST 800-53 command procedure from this section against a policy and then the proper command procedure from Section K.1.4 to match your local situation.

For detailed discussion regarding use of LJK/Security for FISMA compliance, see Appendix L, FISMA Security Assessments with LJK/Security.

K.1.2.1 POLICY_NIST_SP_800_53A_LOW.COM

Command procedure POLICY_NIST_SP_800_53A_LOW.COM establishes a policy to test only those controls that 800-53 (as elaborated by NIST SP 800-53A) requires for systems categorized as FIPS 199 Impact Level Low and ignore other risks for which LJK/Security can test.

For a policy similar to this but taking into account the variances introduced in NIST SP 800-53 Revision 2 for SCADA/ICS systems, use POLICY_NIST_SP_800_53A_LOW_ICS.COM.

K.1.2.2 POLICY_NIST_SP_800_53A_MODERATE.COM

Command procedure POLICY_NIST_SP_800_53A_MODERATE.COM establishes a policy to test only those controls that 800-53 (as elaborated by NIST SP 800-53A) requires for systems categorized as FIPS 199 Impact Level Moderate and ignore other risks for which LJK/Security can test.

For a policy similar to this but taking into account the variances introduced in NIST SP 800-53 Revision 2 for SCADA/ICS systems, use POLICY_NIST_SP_800_53A_MODERATE_ICS.COM.

K.1.2.3 POLICY_NIST_SP_800_53A_HIGH.COM

Command procedure POLICY_NIST_SP_800_53A_HIGH.COM establishes a policy to test only those controls that 800-53 (as elaborated by NIST SP 800-53A) requires for systems categorized as FIPS 199 Impact Level High and ignore other risks for which LJK/Security can test.

For a policy similar to this but taking into account the variances introduced in NIST SP 800-53 Revision 2 for SCADA/ICS systems, use POLICY_NIST_SP_800_53A_HIGH_ICS.COM.

K.1.2.4 POLICY_NIST_SP_800_53.COM

Command procedure POLICY_NIST_SP_800_53.COM establishes a policy to test all controls from 800-53 that can be tested by LJK/Security, including those which 800-53 specifies but never requires. Use one of the other command procedures if you only want to assess to a particular FIPS 199 Impact Level, Low, Moderate or High and ignore other risks for which LJK/Security can test.

For a policy similar to this but taking into account the variances introduced in NIST SP 800-53 Revision 2 for SCADA/ICS systems, use POLICY_NIST_SP_800_53_ICS.COM.

K.1.2.5 POLICY_NIST_SP_800_53A_FULL.COM

Command procedure POLICY_NIST_SP_800_53A_FULL.COM establishes a policy to test all controls from 800-53 that can be tested by LJK/Security, including those which 800-53 specifies but never requires. Use one of the other command procedures if you only want to assess to a particular FIPS 199 Impact Level, Low, Moderate or High and ignore other risks for which LJK/Security can test.

The difference between this and Section K.1.2.4 is that this command procedure expresses violations with the full NIST 800-53A Assessment Objective terminology.

A major purpose of this command procedure is as a base for those who want to build a policy including NIST 800-53 controls that are not required for particular FIPS 199 impact levels.

For a policy similar to this but taking into account the variances introduced in NIST SP 800-53 Revision 2 for SCADA/ICS systems, use POLICY_NIST_SP_800_53A_FULL_ICS.COM.

K.1.3 DoD Instruction 8500.2

These command procedures establish policy settings that correspond to the United States Department of Defense Instruction 8500.2 (published February 6, 2003) entitled Information Assurance (IA) Implementation.

The command procedures listed in Section K.1.3.3 provide limits in accordance with 8500.2 IA Controls DCCT-1, DCSL-1 and ECSD-2, but exemptions for the VMS TCB are required to complement those limits. Those exemptions are provided in the Section K.1.4.1, POLICY_VMS_SHA1_AXP_%%_*.COM or Section K.1.4.2, POLICY_VMS_SHA1_VAX_%%_*.COM command procedures below, according to platform (VAX or Alpha) and the particular version of VMS that is being run.

For detailed discussion regarding use of LJK/Security for DoD Instruction 8500.2 compliance, see Appendix M, DoD Instruction 8500.2 Vulnerability Assessments.

K.1.3.1 Mission Assurance Categories

• MAC I
  For systems where the consequences of loss of integrity or availability are unacceptable.
• MAC II
  For systems where the consequences of loss of integrity are unacceptable.
• MAC III
  For systems where the consequences of loss of integrity or availability can be tolerated or overcome.

DoD Instruction 8500.2 defined three Confidentiality Levels:

• Classified
  For systems containing classified information.
• Sensitive
  For systems containing sensitive but unclassified information.
• Public
  For systems containing no classified or sensitive information.

To support all possible combinations of one of the three Mission Assurance Categories and one of the three Confidentiality Levels, LJK/Security supplies nine command procedures:

• POLICY_DODI_8500_2_MACI_CLASSIFIED.COM
• POLICY_DODI_8500_2_MACII_CLASSIFIED.COM
• POLICY_DODI_8500_2_MACIII_CLASSIFIED.COM
• POLICY_DODI_8500_2_MACI_SENSITIVE.COM
• POLICY_DODI_8500_2_MACII_SENSITIVE.COM
• POLICY_DODI_8500_2_MACIII_SENSITIVE.COM
• POLICY_DODI_8500_2_MACI_PUBLIC.COM
• POLICY_DODI_8500_2_MACII_PUBLIC.COM
• POLICY_DODI_8500_2_MACIII_PUBLIC.COM

Members of these families of command procedures establish policy settings as follows:

• Exemptions from test (DISK,INSTALLED,PROHIBITED) for those images that ship with VMS as part of the Trusted Computing Base.
• Exemptions from test (DISK,INSTPRIV,PROHIBITED) for those images that ship with VMS as part of the Trusted Computing Base.
• Exemptions from test (DISK,INSTPROT,PROHIBITED) for those images that ship with VMS as part of the Trusted Computing Base.
• Exemption values (causing a check to be made) for all VMS images and certain static VMS command procedures with test (DISK,CHECKSUM,SHA1) or (DISK,CHECKSUM,SIMPLE)¹ .

• Choose System Integrated Products as part of installing VMS.
• Add layered products (from HP or third parties) that add images to the Trusted Computing Base.
• Add custom applications specific to your site that add images to the Trusted Computing Base.

Each command procedure can be applied to existing policies that are going to be used against systems running the appropriate version of Alpha VMS as specified in the command procedure name.

K.1.4.2 POLICY_VMS_SHA1_VAX_%%_*.COM

Each command procedure can be applied to existing policies that are going to be used against systems running the appropriate version of VAX VMS as specified in the command procedure name.

K.1.4.3 POLICY_VMS_SIMPLE_AXP_%%_*.COM

Each command procedure can be applied to existing policies that are going to be used against systems running the appropriate version of Alpha VMS as specified in the command procedure name.

K.1.4.4 POLICY_VMS_SIMPLE_VAX_%%_*.COM

Each command procedure can be applied to existing policies that are going to be used against systems running the appropriate version of VAX VMS as specified in the command procedure name.

K.2 Choice of Checksum Algorithms

The SHA1 command procedures above use a cryptographic checksum that is resiliant not only against inadvertent system image modification but also against deliberate modification by a skilled attacker. It does, however, take up to 2 hours for all VMS images on a fast VAX, compared to 2 minutes for the rough checksums used by the SIMPLE command procedures above.

Starting in February 2005 there were cryptographic research reports showing an ability to create hash collisions using the SHA-1 algorithm. However those reports did not indicated the ability to create collisions with a specified hash value, which is what would be required to compromise the use of checksums by LJK/Security. As cryptographic research progresses, LJK/Security may be modified to include further choices of checksum algorithms. However those who feel a need to be on the cutting edge in this regard should consider the mechanism for using site-specific hash algorithms within LJK/Security, as described in Section 9.2.3,LJK$SECURITY_SITE_CHECKSUM callback.

K.3 Creating Your Own Command Procedures

The command procedures above are created in the style of those created by the command

$ LJK/SECURITY SHOW POLICY/COMMAND_PROCEDURE

relying on the special symbol processing described in Section H.8, DCL Symbol Processing for more efficient operation.

You may wish to use similar techniques for composing similar command procedures of your own. That would be useful for making a duplicate policy with certain changes imposed via a text editor or a custom program.