| Previous | Contents | Index |
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., VAX VMS V6.0) 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 servicedue to inappropriate cachingg (as of VMS V7.3) within VMS Executive module SYSRDBRES preventing proper access to NAME_HIDDEN identifiers.
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:
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 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 POLICY_NIST_SP_800_53.COM
This command procedure establishes policy settings that correspond the United States National Institute of Standards and Technology Special Publication 800-53 (published February 28, 2005) entitled Recommended Security Controls for Federal Information Systems. Although that publication is only directly applicable to government systems, it is worth studying by anyone involved in computer security in the US private sector or in other countries.
But this command procedure is 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 this command procedure may not be the ones that are best for your organization. Furthermore, in the case of the (AUDIT,FIN*,REQUIRED) tests, this command procedure sets 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.
This command procedure provides limits in accordance with 800-53 control SI-07, but exemptions for the VMS TCB are required to complement those limits. Those exemptions are provided in the four families of command procedures below, 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 POLICY_NIST_SP_800_53.COM against a policy and then the proper command procedure from the families below to match your local situation.
Command procedures from the families listed below are also appropriate for those who are not using POLICY_NIST_SP_800_53.COM but want exemptions specific to a VMS version for images delivered as part of VMS and particularly those included in the VMS TCB. |
Whenever VMS patch kits are installed on the system, that will change the proper checksum values for any images replaced. You must make the appropriate changes in your policy to avoid getting violations reported. |
Command procedures from the families listed below are also appropriate for those who are not using POLICY_NIST_SP_800_53.COM but want exemptions specific to a VMS version for images delivered as part of VMS and particularly those included in the VMS TCB. |
Members of this family of command procedures establish policy settings as follows:
Members of this family of command procedures establish policy settings as follows:
Members of this family of command procedures establish policy settings as follows:
Members of this family of command procedures establish policy settings as follows:
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 |
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.
| Index | Contents |