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 -