In my previous post I expressed my opinion that the Nuclear Cyber Security Plans at US licensees have some deficiencies. In this post I want to talk about a couple of examples of the unnecessary controls within RG 5.71 and NEI 08-09. These controls, and perhaps others, should be removed from the next revision of NEI 08-09, as it should be obvious they are not necessary to protect SSEP functionality at any nuclear plant.
D 2.10 Non-Repudiation: This technical cyber security control ensures the protection of CDAs and audit records against an individual falsely denying they performed a particular action.
This control has nothing to do with CDA audit records in the sense implied by a normal reading of the text, anything within a normal system audit record can be repudiated by any user. Privileged users of most systems have the ability to write to log files, therefore, they can create any audit record they want. Consider a log file entry:
rdahl console login 07/06/2016 19:21:35
This doesn’t provide non-repudiatable (is that a word?) evidence that I logged into a machine from the console at that time. The root user could just have easily typed the following command:
echo “rdahl console login 07/06/2016 19:21:35” >/var/log
If you look at the guidance in SP 800-53, you can see the actual meaning and use of Non-Repudiation:
AU-10 Control: The information system protects against an individual (or process acting on behalf of an individual) falsely denying having performed [Assignment: organization-defined actions to be covered by non-repudiation].
Supplemental Guidance: Types of individual actions covered by non-repudiation include, for example, creating information, sending and receiving messages, approving information (e.g., indicating concurrence or signing a contract). Non-repudiation protects individuals against later claims by: (i) authors of not having authored particular documents; (ii) senders of not having transmitted messages; (iii) receivers of not having received messages; or (iv) signatories of not having signed documents. Non-repudiation services can be used to determine if information originated from a particular individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a procurement request) or received specific information. Organizations obtain non-repudiation services by employing various techniques or mechanisms (e.g., digital signatures, digital message receipts). Related controls: SC-12, SC-8, SC-13, SC-16, SC-17, SC-23.
Nothing at all to do with CDA audit records, incidentally, AU-10 requires detailed information to be provided about the actions required to be covered by non-repudiation.
The only usefulness of non-repudiation within the operations of a nuclear power plant would be if the NRC ever desired to see licensees move to paperless records. Work orders, Preventive Maintenances, Surveillances, ECs, could be digitally signed, preventing the destruction of so many trees, and Non-Repudiation could facilitate that through the use of digitally signed record digests.
D 1.13 Automated Marking
D 1.14 Automated Labeling
D 3.11 Transmission of Security Parameters
These are discussed as a group as they are all dependent on Mandatory Access Control, NIST SP 800-53 Rev 4 uses Security Attributes (NIST language for Security Parameters) as an example of the interdependence of some controls:
Implementation Tip
In diverging from the security control baselines during the tailoring process, organizations consider some very important linkages between various controls and control enhancements. These linkages are captured in the selection of controls and enhancements in the baselines and are especially significant when developing overlays (described in Section 3.3 and Appendix I). In some instances, the linkages are such that it is not meaningful to include a security control or control enhancement without some other control or enhancement. The totality of the controls and enhancements provide a required security capability. Some linkages are obvious such as the linkage between Mandatory Access Control enhancement (AC-3 (3)) and Security Attributes (AC-16). But other linkages may be more subtle. This is especially true in the case where the linkage is between security functionality-related controls and security assurance-related controls as described in Appendix E. For example, it is not particularly meaningful to implement AC-3 (3) without also implementing a Reference Monitor (AC-25). Organizations are encouraged to pay careful attention to the related controls section of the Supplemental Guidance for the security controls to help in identifying such linkages.
Essentially, you can’t have or transmit Security Attributes without implementing Mandatory Access Control, and unless a nuclear licensee is running a “Trusted” (in the NSA/DOD/Rainbow Series context) OS, e.g. Trusted64, Trusted Solaris, etc… None of these three controls can be implemented. It is impossible with a system that only provides Discrentionary Access Control. The “automated”-ness of D 1.13 and D 1.14 require the system to understand the security attributes of the internal data structures within the OS, from the supplemental guidance of AC-16 Security Attributes:
The term security labeling refers to the association of security attributes with subjects and objects represented by internal data structures within organizational information systems, to enable information system-based enforcement of information security policies
These four controls are examples of controls that provide no value to the protection of the SSEP functions at a nuclear power plant. In my next post, I will address another issue with NEI 08-09, but until then, take a look yourself at the following controls and see if you can find any purpose served in this context (Protecting the SSEP functionality of CDAs):
D 3.12 Public Key Infrastructure Certificates
D 3.19 Confidentiality of Information at Rest
E 5.7 Shared Resources (the first bullet, consistent with the NIST Control)
E 3.10 Information Output Handling and Retention
D 1.23 This security control ensures that information that could cause an adverse impact on SSEP functions or could assist an adversary in carrying out an attack is not released to the public.
