Principles
Alignment with Security Policies - security policies should drive the implementation of technical security controls.
Rationale: Technical security controls are put in place to enforce compliance with existing security policies. Technical security controls should not be put in place for the sake of technical controls.
Level of Security - information systems (including applications, computing platforms, data and networks) will maintain a level of security that is commensurate with the risk and magnitude of the harm that could result from the loss, misuse, disclosure or modification of information.
Rationale: As a practical matter, perfect security cannot be achieved in any information system. Therefore, security controls will be applied to reduce risk to an acceptable level.
Security Control Selection - the selection of controls will be based on a risk analysis and risk management decision.
Rationale: The process for selecting new controls will consider both the degree of risk mitigation provided by the control and the total cost to acquire, implement and maintain the control.
Security Control Management - technical security controls will not be implemented without the implementation of associated management and operational controls.
Rationale: Unmanaged security controls can present a greater risk than the absence of security controls.
Security Planning - information systems security will be built into systems from their inception rather than “bolted on” after system implementation.
Rationale: The cost and complexity of adding security controls to a system after it is already in production is significantly greater.
Measurement - all functional security requirements that define the “what” a system or product does will have associated assurance requirements to define “how well it does it.”
Rationale: Security controls will be able to be reviewed or audited through some qualitative or quantitative means in order to ensure that risk is being maintained at acceptable levels.
Security Control Modularity - safeguards will be modular so that they may be removed or changed as the system and enterprise risk profile changes.
Rationale: It is prudent to minimize the interdependence of controls so that controls can be easily interchanged or modified.
Security Control Standardization - selection of controls will consider the ability of the control to be applied uniformly across the NIH enterprise and to minimize exceptions.
Rationale: Achieving a standards-based environment will reduce operational costs, improve interoperability and improve supportability.
Compartmentalization and Defense-in-Depth - the architecture will embrace the concepts of compartmentalization and defense-in-depth.
Rationale: Compartmentalization localizes vulnerabilities and defense-in-depth establishes a series of imperfect countermeasures.
Manual Operations - controls will minimize the need for manual operation.
Rationale: Manual operation can create vulnerabilities and cause disruption of service due to misinterpretation and misconfiguration.
Levels of Protection and Response - controls will not impose unreasonable constraints or operate in a manner that causes unreasonable response.
Rationale: Controls should provide only the required level of protection, alerting and response.
Security Control Availability - controls will have the capability to be shut down gracefully and restored automatically to the conditions prior to shut down. Controls should fail-closed to the most restrictive condition.
Rationale: Controls will be highly available to minimize periods of vulnerability.
Security Control Default - controls will default to the most secure condition.
Rationale: This approach reduces the number of points of vulnerability.
Separation of Duties - the designer and the operator of a security control will be independent.
Rationale: Separation of duties ensures that there is not a conflict of interest in the design of security control.
