The basis of CNSS reporting is on a per-system basis, and that definition of each system is something on which the CA-2 and CA-7 teams should be in agreement. A CNSS system can be much larger than a single running copy of VMS, and even larger than a single running VMScluster. It may even mix VMS and non-VMS machines. It is important to agree on a definition of where boundaries of each CNSS system start and end, and then stick to it.

Typically at least the VMS portion of any CNSS system will be assessed from a single LJK/Security master node, but a single master node might be used for assessing the VMS portion of more than one CNSS system. In the case of a single master node used to assess two CNSS systems named Castor and Pollux, the policy file name prefixes on an LJK/Security master node might be OIG_FY06_CASTOR_ and OIG_FY06_POLLUX_ for the CA-2 Security Assessment team vs. CASTOR_ and POLLUX_ for the CA-7 Continuous Monitoring team.

P.2.5 Using CA-7 Exemptions for CA-2 Assessments

In setting limits within a policy for the Automatic Testing method, those conducting a separate CA-2 Security Assessment will want to create a policy from scratch, perhaps carrying in policy settings prepared in advance or used for CA-2 Security Assessment on some other system operated by the organization. Another option would be to take the default CNSSI 1253 policy settings that ship with LJK/Security and just make particular changes for those controls where the policy of the organization mandates a different value in the policy from that shipped with LJK/Security. It would be a mistake to just make a wholesale copy of the policy used for CA-7 Continuous Monitoring, since that might not have been kept current with the organization's policy.

But the situation is different in the case of exemptions in the new policy. Exemptions are used in LJK/Security to indicate special cases where abnormal values are permitted based on management approval. For instance a typical limit says that no individuals should have privileges assigned to their VMS username. Then exemptions are entered for the VMS usernames of those assigned to system management duties, so that violation reports are not generated for those usernames authorized to have privilege. To recreate the exemptions appropriate to a system would be time consuming, so a better tactic is:

1. Extract the exemptions (but not the limits) from the appropriate CA-7 policy (or policies) with a command like

   $ LJK/Security SHOW POLICY ca7policyname - /EXEMPTIONS /NOLIMITS /COMMAND_PROCEDURE - /OUTPUT=REVIEW.TXT

   creating a command procedure for applying those exemptions to some other policy. Each line in the command procedure contains an entire command for establishing one exemption, so some of those lines will be quite long.

2. Use a text editor to inspect each exemption in the resulting command procedure and decide whether it was properly granted. On lines where the exemption is not appropriate, comment out the line with an initial exclamation point (!). This has the same effect as deleting the line, but leaves a better record of what actions are taken. For an even better record, one can follow that exclamation point with brief text (on a single line) indicating the reason for the decision.
3. Apply the resulting batch of exemptions to the CA-2 policy with a command like

   $ @REVIEW.TXT ca2policyname

   where ca2policyname is the name of the policy created earlier with the current limits for the organization.

4. Use the resulting policy for the Annual CA-2 Security Assessment.

Depending on the organization's policy some manual reporting of inappropriate exemptions found in step 2 above might be in order.

In the following sections, we discuss various considerations for proposed exemptions, depending on the LJK/Security facility in which the exemptions are located. The examples are based on limits specified in the POLICY_NIST_SP_800_53*.COM file provided in directory LJK$SECURITY_EXAMPLES. Your own organization's limits may be different.

P.2.5.1 Example of an Exemption Based on Node

For LJK/Security test (VMS,ANNOUNCE,CONTAINS)² the value specified in the limit is the system use notification to be displayed to authorized users on login. This means a violation will be reported for any Node where this notification is not provided. An exemption might be present allowing a particular Node to skip this message if it is exclusively for public use. Questions that might be asked about such an exemption include:

• Does the organization's policy allow exemptions for this test ?
• Is the value specified for this exemption within a range allowed for exemptions to this test by the organization's policy ?
• Does the comment field of this exemption provide tracking information required to determine that the procedure for issuing exemptions under the organization's policy was followed ?
• Does following that tracking information show that the organization's policy was followed for this exemption and that the exemption still conforms to the organization's policy with the passage of time ?

For LJK/Security test (DISK, FILEPROT, ABSOLUTHI)³ the value specified in the limit is (SYSTEM:RWED,OWNER:RWED,GROUP:RE,WORLD), meaning a violation will be reported for each file which has a more permissive protection mask.

For LJK/Security test (DISK, FILEPROT,PERCENTHI)⁴ and selector READ, the limit specified has a value of 10 meaning a violation will be reported for each file to which more than 10 percent of users have read access.

Often exemptions will be used for those two tests with respective values of (SYSTEM:RWED, OWNER:RWED,GROUP:RE,WORLD:RE) and 100 percent for a VMS system-wide login command procedure, since that must be executed on behalf of each user at login. Questions that might be asked about such exemptions include:

• Does the organization's policy allow exemptions for this test ?
• Is the file one for which the organization's policy allows such exemptions ?
• Is the value specified for this exemption within a range allowed for exemptions to this test by the organization's policy ?
• Does the comment field of this exemption provide tracking information required to determine that the procedure for issuing exemptions under the organization's policy was followed ?
• Does following that tracking information show that the organization's policy was followed for this exemption and that the exemption still conforms to the organization's policy with the passage of time ?
• If the file is one accessed via a logical name like SYS$SYLOGIN, is it canonically specified to use that logical name, such as "SYS$SYLOGIN,SYS$COMMON:[SYSMGR]SYLOGIN.COM" ?

For LJK/Security test (TERM, TYPEAHEAD, PROHIBITED)⁵ the value specified in the limit is True, meaning a violation will be reported for each terminal over which logins are allowed by VMS. A typical policy will include exemptions for each terminal over which logins are allowed by site rules. Questions that might be asked about such an exemption include:

• Does the organization's policy allow exemptions for this test ?
• Is the value specified for this exemption within a range allowed for exemptions to this test by the organization's policy ?
• Does the comment field of this exemption provide tracking information required to determine that the procedure for issuing exemptions under the organization's policy was followed ?
• Does following that tracking information show that the organization's policy was followed for this exemption and that the exemption still conforms to the organization's policy with the passage of time ?

For LJK/Security test (UAF, PRIVLEVEL, ABSOLUTHI)⁶ the value specified in the limit is Category-Normal, meaning a violation will be reported for each username that has privileges at a higher level. A typical policy will include an exemption allowing username SYSTEM to have privileges at the level Category-All. Separate exemptions would be present for individuals assigned to system management duties.

Questions that might be asked about such an exemption include:

• Does the organization's policy allow exemptions for this test ?
• Is the value specified for this exemption within a range allowed for exemptions to this test by the organization's policy ?
• Does the comment field of this exemption provide tracking information required to determine that the procedure for issuing exemptions under the organization's policy was followed ?
• Does following that tracking information show that the organization's policy was followed for this exemption and that the exemption still conforms to the organization's policy with the passage of time ?

This glossary gives an alphabetical-order explanation of various terms (denoted in boldface throughout this manual) that have specialized meanings within the context of LJK/Security.

assessment: An overall set of associations from tributary nodes to the policies and transport methods to be used in assessing security of those nodes.

effective privilege: Privileges a user could obtain even beyond explicit privileges and implicit privileges. Going beyond explicit privileges and implicit privileges generally involves exploiting a weakness in system administration, such as improperly protected files which are regularly executed by privileged users.

exemption: Statement within a policy that under particular circumstances a different limit is to be used for some test than the normal limit established in that policy.

explicit privilege: Privilege granted in the privilege section of the User Authorization File. This includes both default privileges and privileges which can be gained with the SET PRIVILEGE command, either individually authorized or authorized in general by the SETPRV privilege. Explicit privilege can be different from implicit privilege and effective privilege (q.v.).

implicit privilege: Privilege granted by assignment of a system UIC code to a user in the User Authorization File. Implicit privilege can be different from explicit privilege and effective privilege (q.v.).

limit: An individual value against which a particular test is made within a particular policy.

Mandatory Access Controls: Management control which cannot be subverted technically by actions of an individual user who has ownership of data.

master node: The VMS system on which LJK/Security software is initially installed. This system (possibly along with others in a cluster to which it belongs) is where data regarding policies, assessments is stored and where results are collected.

policy: A set of values for individual tests to be made by LJK/Security in assessing security. It is possible to have multiple policies and apply each to different sets of nodes or to the same nodes on different schedules.

result: An individual instance of a limit being exceeded. Results are transmitted back from tributary nodes to the master node. Only after the results have been collected are the exemptions taken into consideration for reporting purposes.

selector: An additional qualification used with certain tests to specify separate instances of limits or exemptions based on an additional factor, such as privilege or day of the week.

test: An individual comparison to be made between a security-relevant condition on a node and a limit in the relevant policy.

transport method: A mechanism used to send LJK/Security software kits and assessment requests from the master node to a tributary node and to send assessment results from a tributary node back to the master node. Available mechanisms include DECnet and removable magnetic media such as magnetic tape or diskette (depending on hardware configurations).

tributary node: A node which is to be measured by LJK/Security software. It contains only a subset of the LJK/Security software, which is installed from a kit generated on the master node rather than from the master kit delivered by LJK Software.

In most cases the master node will also be a tributary node, running evaluations of itself. It is never necessary to install on the master node the LJK/Security software kit generated for tributary nodes.

value: The numeric, boolean or other standard in a limit or an exemption, against which test results are compared.

violation: An instance where a VMS control is not in compliance with the limit and exemptions set in an LJK/Security policy.