Industrial Internet Security Framework v 1.0 | Page 129

Security Framework Annex A: Industrial Security Standards A.4.2 FEDERAL INFORMATION PROCESSING STANDARD (FIPS) The FIPS publication 140 Publication Series establishes requirements for cryptographic modules that include both hardware and software components. Topics covered by FIPS 140-2 1 include implementation and use of asymmetric and symmetric keys, message authentication, secure hashing, and random number generation. FIPS 140-2 specifies four qualitative security assurance levels, with each level representing increasingly more stringent controls to prevent physical access to information stored or managed by the modules. A.5 SAFETY STANDARDS AND THEIR RELATIONSHIP WITH SECURITY Most commonly accepted safety standards and guidance documents build on, adapt or derive from ‘IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safetyrelated Systems.’ 2 Examples include ISO 26262 (automotive), IEC 62279 (rail), IEC 61511 (industrial process control), and IEC 61513 (nuclear reactor instrumentation and control).3 The IEC 61508 family of standards generally requires safety to be handled as a first-class system property throughout the complete lifecycle of the system from requirements elicitation through end-of-life. These standards require that all hazards must be identified and the risks associated with those hazards must be reduced to As-Low-As-Reasonably-Possible (ALARP). Since security vulnerabilities enable adversaries to precipitate hazards, existing safety standards can be viewed as directly implying that system security too must be seriously considered at each stage of the system lifecycle (i.e., security must be built-in from the beginning and not added post hoc). In addition to the IEC 61508 family of derived standards, there are a number of other guidance standards focused mainly on the development of software for safety critical systems. Examples include MISRA C (guidance on use of the C programming language in critical systems), DO-178B/C (software in aviation systems), and ARINC 653 (a standard separation kernel interface for avionics software systems). 4 Generally, these standards require a rigorous and well-documented development process for safety critical software. Often, extensive unit testing with high coverage or even formal methods must be used for verification. While these standards have been developed with safety in mind, the prescribed development processes can help reduce the introduction of exploitable defects. A.6 PRIVACY STANDARDS, FRAMEWORKS AND REGULATION A.6.1 ISO/IEC AND NIST PRIVACY STANDARDS The International Organization for Standardization (ISO) has been working on a set of standards relating to privacy and protection of personally identifiable information (PII). See [FIPS-140-2] See [IEC-61508] 3 See [ISO-26262-1], [IEC-62279], [IEC-61511] and [IEC-61513] 4 See [MISRA-C], [RTCA-DO-178B], [RTCA-DO-178C] and [ARINC-653] 1 2 IIC:PUB:G4:V1.0:PB:20160926 - 129 -