| Previous | Contents | Index |
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 PCI DSS
This command procedure establish policy settings that follow the Payment Card Industry Data Security Standard V1.2.
These command procedures provides limits in accordance with 800-53 control SI-7, but exemptions for the VMS TCB are required to complement those limits. Use the command procedures described in Section K.1.6, 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 PCI DSS command procedure from this section against a policy and then the proper command procedure from Section K.1.6 to match your local situation.
Command procedures listed in Section K.1.6 are also appropriate for those who are not using command procedures to set up PCI DSS policies but want exemptions specific to a VMS version for images delivered as part of VMS and particularly those included in the VMS TCB. |
For detailed discussion regarding use of LJK/Security for PCI DSS compliance, see Appendix N, Quick Start Guide to PCI DSS Security Assessments.
Command procedures in this appendix establish policies to test a system according to the PCI Data Security Standard.
PCI DSS Requirement 2.2 specifies that configurations should also
conform to security rules established by NIST, so POLICY_PCI.COM
includes some tests based on the NIST 800-53 standard. But for a full
assessment against NIST 800-53A (which takes a lot more work)
use the command procedures described in Section K.1.2, NIST.
K.1.3.1 POLICY_PCI_MERCHANT.COM
This command procedure sets a policy to measure against PCI DSS
requirements for merchants who accept payment cards.
K.1.3.2 POLICY_PCI_SERVICE_PROVIDER.COM
This command procedure sets a policy to measure against PCI DSS
requirements for service providers.
K.1.3.3 POLICY_PCI_SHARED_HOSTING.COM
This command procedure sets a policy to measure against PCI DSS
requirements for hosting providers.
K.1.4 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.4.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.6.1, POLICY_VMS_SHA1_AXP_%%_*.COM or Section K.1.6.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.
Command procedures listed in Section K.1.6.1 and Section K.1.6.2 are also appropriate for those who are not using one of the command procedures listed in Section K.1.4.3 but want exemptions specific to a VMS version for images delivered as part of VMS and particularly those included in the VMS TCB. |
For detailed discussion regarding use of LJK/Security for DoD Instruction 8500.2 compliance, see Appendix O, Quick Start Guide to DoD Instruction 8500.2 Vulnerability Assessments.
K.1.4.1 Mission Assurance Categories
DoD Instruction 8500.2 defined three Mission Assurance Categories:
DoD Instruction 8500.2 defined three Confidentiality Levels:
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:
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 Committee on National Security Systems Instruction 1253 (initially published October, 2009) entitled Security Categorization and Control Selection for National Security Systems.
These command procedures provides limits in accordance with CNSSI 1253 control SI-7, but exemptions for the VMS TCB are required to complement those limits. Use the command procedures described in Section K.1.6, 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 CNSSI 1253 command procedure from this section against a policy and then the proper command procedure from Section K.1.6 to match your local situation.
Command procedures listed in Section K.1.6 are also appropriate for those who are not using command procedures to set up CNSSI 1253 policies but want exemptions specific to a VMS version for images delivered as part of VMS and particularly those included in the VMS TCB. |
For detailed discussion regarding use of LJK/Security for CNSS compliance, see Appendix P, Quick Start Guide to CNSS Security Assessments.
While CNSSI 1253 is based on NIST SP 800-53, the number of standard variations is considerably greater:
Members of these families of command procedures establish policy settings as follows:
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.6.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.6.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.6.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.
1 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. |
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.3.3,LJK$SECURITY_SITE_CHECKSUM callout.
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 |
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.
This appendix tells how to send LJK/Security requests and results directly over TCP/IP in environments which do not have DECnet installed.
By default, LJK/Security transmits
There are three major methods for achieving DECnet connections between VMS systems:
For those situations, using LJK/Security requires additional work on
the part of the system managers to transmit the data.
L.1 Basic Approach to Transmission over TCP/IP
To run transmissions between the product master node and tributary nodes you must define in advance some systemwide logical names which are no longer than 15 characters long:
Then you write some DCL command procedures and run them on a regular
basis to transmit files.
L.2 LJK/Security Command Examples
To use systemwide logical names for routing "request" and "result" files to reserved disk directories, you can use commands like:
$ LJK/Security MODIFY ASSESSMENT MY_8500_2_ASSESSMENT/POLICY=MY_8500_2_POLICY - /NODE=BOSTON/REQUEST=IA_BOSTON/RESULT=IA_RESULT $ LJK/Security MODIFY ASSESSMENT MY_8500_2_ASSESSMENT/POLICY=MY_8500_2_POLICY - /NODE=DENVER/REQUEST=IA_DENVER/RESULT=IA_RESULT |
The IA_BOSTON and IA_DENVER systemwide logical names in the example above are defined on the master node, while the IA_RESULT systemwide logical name is defined on each tributary node. All those logical names indicate where the executing LJK/Security program is to leave the data files. The location from which the executing LJK/Security program is to read the data files on the other node after transfer is specified at the "REMOTE" command in the command procedures shown below.
Like all LJK/Security commands, you issue the ones shown above on the master node, even though the "IA_RESULT" systemwide logical names are defined on each tributary node.
L.3 Example TCP/IP Command Procedure for Each Tributary Node
The following command procedure presumes:
$ !
$ ! LJK$SECURITY_EXAMPLES:LJK$SECURITY_TCPIP_TRIBUTARY.COM
$ !
$ ! To use this command procedure, copy it to another directory
$ ! before changing the sections surrounded by rows of asterisks.
$ ! That way local modifications will not be wiped out when you
$ ! upgrade to the next version of LJK/Security.
$ !
$ ! This command procedure will copy any LJK/Security result files
$ ! it finds on a tributary node back to the master node.
$ !
$ ! Then it will invoke LJK/Security to process any request files
$ ! it finds on a tributary node to create a result file.
$ !
$ ! The process under which this command procedure executes must
$ ! have whatever rights are required to transfer files between
$ ! nodes and must have one of the identifiers:
$ !
$ ! LJK$SECURITY_REMOTE
$ ! LJK$SECURITY_ROLE_STARTUP
$ ! LJK$SECURITY_ALL
$ !
$ ON WARNING THEN GOTO RESUBMIT
$ !
$ ! When run interactively, this command procedure just submits itself.
$ ! The sole parameter is the optional name of a batch queue to use.
$ !
$ IF F$MODE() .NES. "BATCH" THEN GOTO RESUBMIT
$ !
$ ! ---------------------------------------------------------
$ !
$ ! Ship back any result file created on this tributary node
$ !
$ NEXT_RESULT = F$SEARCH("",321)
$ RESULT_LOOP:
$ NEXT_RESULT = F$SEARCH("IA_RESULT:LJK_SECURITY.DAT;-0",321)
$ IF NEXT_RESULT .EQS. "" THEN GOTO RESULT_DONE
$ !
$ ! Ensure it is complete by getting exclusive access. If the
$ ! oldest version is still being written, wait for the next run.
$ !
$ OPEN EXCLUSIVE_CHAN/APPEND/ERROR=RESULT_DONE 'NEXT_RESULT'
$ CLOSE EXCLUSIVE_CHAN
$ !
$ ! We have found a complete result file -- copy it to the Master Node
$ !
$ ! *********************************************************
$ ! *********************************************************
$ ! *** This command uses a DECnet copy utilizing DECnet ***
$ ! *** proxy logins. Replace it with a COPY/TCP or ***
$ ! *** other command suitable to your environment. ***
$ ! *********************************************************
$ ! *********************************************************
$ ! *********************************************************
$ !
$ COPY/LOG 'NEXT_RESULT' MASTER::IA_RESULT:;
$ DELETE 'NEXT_RESULT'
$ !
$ ! *********************************************************
$ ! *********************************************************
$ !
$ GOTO RESULT_LOOP
$ RESULT_DONE:
$ !
$ ! ---------------------------------------------------------
$ !
$ ! Process any request file copied onto this tributary node
$ !
$ NEXT_REQUEST = F$SEARCH("",321)
$ REQUEST_LOOP:
$ NEXT_REQUEST = F$SEARCH("IA_REQUEST:LJK_SECURITY.DAT;-0",321)
$ IF NEXT_REQUEST .EQS. "" THEN GOTO REQUEST_DONE
$ !
$ ! Ensure it is complete by getting exclusive access. If the
$ ! oldest version is still being written, wait for the next run.
$ !
$ OPEN EXCLUSIVE_CHAN/APPEND/ERROR=REQUEST_DONE 'NEXT_REQUEST'
$ CLOSE EXCLUSIVE_CHAN
$ !
$ ! *********************************************************
$ ! *********************************************************
$ !
$ ! We have found a complete request file -- process the request
$ !
$ DEFINE/USER NEXT_REQUEST 'NEXT_REQUEST' ! 15 or fewer characters
$ MCR LJK$SECURITY REMOTE NEXT_REQUEST
$ DELETE 'NEXT_REQUEST'
$ !
$ ! *********************************************************
$ ! *********************************************************
$ !
$ GOTO REQUEST_LOOP
$ REQUEST_DONE:
$ !
$ ! ---------------------------------------------------------
$ !
$ RESUBMIT:
$ !
$ ! When run interactively, this command procedure just submits itself.
$ ! The sole parameter is the optional name of a batch queue to use.
$ !
$ PROC = F$ENVIRONMENT("PROCEDURE") ! Our command procedure
$ PROC = PROC - F$PARSE(PROC,,,"VERSION") ! but the latest version
$ !
$ ! Use any queue specified in P1
$ !
$ QUEUE = F$GETQUI("DISPLAY_JOB","QUEUE_NAME",,"THIS_JOB")
$ IF P1 .NES. "" THEN QUEUE = P1
$ IF QUEUE .NES. "" THEN QUEUE = "/QUEUE=" + QUEUE
$ show symbol queue
$ !
$ submit 'PROC' -
/AFTER="+00:05:00.00" - ! Every 5 minutes
/NONOTIFY - ! do not bother the humans
/PARAMETERS="''P1'" - ! Preserve any queue name specified
/NOPRINTER - ! Do not print log file
'QUEUE' - ! Specified or existing queue
/RESTART - ! Restart-enabled
/RETAIN=ERROR ! Track failures
$ !
$ EXIT $STATUS ! From LJK$SECURITY_TCPIP_TRIBUTARY.COM
$ !
|
| Previous | Next | Contents | Index |