| Previous | Contents | Index |
This chapter discusses the uses of policy modification.
7.1 Disables
The primary use of disables is to save execution time by avoiding testing of an entire facility. If one of your nodes has an extremely large User Authorization File, for instance, you might choose to test it only once per day, while testing other facilities at the start of each 8 hour shift.
No capability is provided to disable particular tests within a facility, because the time-consuming portion of the testing process is getting the raw information, such as user authorization or file data, which is done once per data item for all the tests in a facility. For instance, once information about a particular file has been retrieved from VMS, the number of tests applied to it in memory does not have a significant effect on performance. Of course, the number of tests failed, and thus the number of violation records written, can affect performance.
Newly created policies have all facilities enabled by default.
7.1.1 Using the /METHOD=QUICK qualifier
The most common candidate facilities for disabling are those that involve extensive disk reading, such as the DISK facility that reads protection information for all files and the USAGE facility that reads all available audit logs.
But those who want to disable those facilities often want to do it only some of the time, perhaps as part of a more frequent assessment that shares a policy with a less frequent more thorough assessment. Rather than constantly modifying the policy disable to first prevent and then allow those facilities to run, you will probably want to use the /METHOD=QUICK qualifier on one of two commands:
Limits are the cornerstone of policies, setting the basic criteria by which nodes will be assessed. As supplied, LJK/Security provides a default set of limits for each policy you create, but after you have used the software for a while it is likely you will want to make some changes to suit your own organization's needs.
Newly created policies have a default value for each limit, either taken from the policy named DEFAULT or from the factory defaults. When you customize a policy by changing particular limits, all other limits retain their value unless you change them.
In general comments applied to limits (but not comments applied to disables or to exemptions) are included in violation reports created by LJK/Security. As such they can be used to indicate the authority rquiring a particular limit setting, such as a particular internal memo or some external requirement such as a particular control listed in NIST Special Publication 800-53.
In contrast, most comments applied to disables or to exemptions just provide a record for those inspecting why particular settings were made.
The major exception to the above general description is tests in the (DISK, CHECKPROT) element. For that element, comments associated with limits just provide a record for those inspecting settings, while comments associated with exemptions are included in violation reports.
Disabling tests entirely is only done on a facility-wide basis through
the
use of disables (see Section 7.1), but the same
effect can be achieved by setting tests to be totally permissive, as is
done by the command procedure described in Section K.1.1, POLICY_NULL.COM.
7.3 Exemptions
Exemptions provide a finer control over reporting of assessment results, allowing for policy deviations in specific cases. 1
Certain exemptions are normal, since the conditions they permit are required for normal operation of VMS. These exemptions are not automatically generated by LJK/Security software, since LJK Software believes that sites should always be aware of all exemptions added to their policies. Exemptions LJK Software has identified that most sites will want to add are:
1 Except for Disk tests, exemption processing is done when receiving results on the master node. Thus no processing time is consumed on the tributary nodes due to a long list of exemptions. |
The audit history mechanism can be used to show when changes were made
to
your policies. Preservation of this audit history is the reason why
LJK/Security provides no command to delete a policy
or an assessment.
7.5 Tri-valued logic
Some tests take limit and exemption values using tri-valued logic:
Many elements have tests for exactly two boolean constraints, PROHIBITED and REQUIRED. With these two boolean tests, there are four possible limit settings:
| Value of REQUIRED limit | Value of PROHIBITED limit | |
|---|---|---|
| FALSE | TRUE | |
| FALSE | never report a violation | report violation if TRUE |
| TRUE | report violation if FALSE | always report violation |
Many elements have tests for exactly two numeric
constraints, ABSOLUTLO and ABSOLUTHI. If the
limits for these
two numeric tests are set such that the ABSOLUTHI
limit is lower than the ABSOLUTLO
limit, the result is to report
violations in all cases, similar
to setting both limits TRUE as described in
Section 7.6.
7.8 Policy Performance Considerations
There are three major areas where the performance of LJK/Security is drastically affected by policy choices:
Finally, violation processing in general is slow. It is better to run a
less ambitious policy until the most outrageous security errors are
brought under control.
7.9 SHOW POLICY/COMMAND_PROCEDURE
The /COMMAND_PROCEDURE output of the SHOW POLICY command (or corresponding capabilities of the Window and Menu interfaces) produce a command procedure that can be modified to give exactly the same settings to some other policy. The strength of this capability is not in exact duplication, but rather in tailoring the output to produce a slightly different result.
$ SEARCH MY_FILE.COM "/TEST=(UAF ,PWDMINLEN ,"/OUTPUT=MY_OTHER_FILE.COM |
$ SORT MY_FILE.COM MY_FILE.COM /KEY=(POSITION=1,SIZE=60)/STABLE |
This chapter discusses the uses of assessment modification.
Modification of assessments gives you the ability to apply differing policies and transmission media to various nodes in your organization. It is rare that an organization which has totally uniform uses for all VMS systems, and thus it is rare than an organization has totally uniform security needs for all those systems.
Because the assessment is the basis for reporting violations, formal assessments to meet NIST 800-53 requirements should be for an entire "system" as defined for FISMA compliance purposes. See further discussion of this issue in Section L.2.4. |
Specifying the name of a node when modifying a assessment serves to add the node to that assessment.
To remove a node from an assessment modify the assessment to give the node a policy name which is blank. Technically a record of the node will remain in the file (for audit-trail purposes, if nothing else) but the node will not be included when the assessment is run.
On master nodes without DECnet, the master node should be specified as "0" when adding it to an assessment. |
Modifying an assessment to change the
policy associated with a node will cause subsequent
RUN commands for that
assessment to use the new policy. Any previous RUN
commands (even those specifying an AFTER or INTERVAL time)
will use the policy in effect at the time the RUN
command was issued.
8.3 Changing Request Media
Modifying an assessment to change the request medium
associated with a node will cause subsequent RUN commands for that
assessment to use the new request medium. Any previous RUN commands
(even those specifying an AFTER or INTERVAL time)
will use the request medium in effect at the time the RUN command was
issued.
8.4 Changing Result Media
Modifying an assessment to change the result medium
associated with a node will cause subsequent RUN commands for that
assessment to use the new result medium. Any previous RUN commands
(even those specifying an AFTER or INTERVAL time)
will use the result medium in effect at the time the RUN command was
issued.
8.5 Changing Media Protection
Modifying an assessment to change the request or
result medium
protection associated with a node will cause subsequent RUN commands
for that assessment to use the new request or result medium protection.
Any previous RUN commands (even those specifying an AFTER or INTERVAL
time)
will use the request or result medium protection in effect at the time
the RUN command was issued.
8.6 Audit history
The audit history mechanism can be used to show when changes were made to your assessments.
| Previous | Next | Contents | Index |