The ISA/IEC 62443 standard specifies security capabilities for (industrial) control system components. Developed by the ISA99 committee and adopted by the International Electrotechnical Commission (IEC), provides a framework to address and mitigate security vulnerabilities in industrial automation and control systems (IACSs). it is based upon the input and knowledge of IACS security experts from across the globe to develop consensus standards that are applicable to all industry sectors and critical infrastructure. Central is the application of IACS security zones and conduits (isolation & segmentation), which were introduced in 62443-1-1,
ISA-62443-4-2, Security for Industrial Automation and Control Systems: Technical Security Requirements for IACS Components, provides the cybersecurity technical requirements for components that make up an IACS, specifically the embedded devices, network components, host components, and software applications.
Based on the IACS system security requirements of ISA/IEC 62443‑3-3, System Security Requirements and Security Levels, 4-2 specifies security capabilities that enable a component to mitigate threats for a given security level without the assistance of compensating countermeasures.
ISA/IEC 62443-4-1, Product Security Development Life-Cycle Requirements, specifies process requirements for the secure development of products used in an IACS and defines a secure development life cycle for developing and maintaining secure products. The life cycle includes security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management, and product end of life.
ISA/IEC 62443-3-2, Security Risk Assessment, System Partitioning and Security Levels, is based on the understanding that IACS security is a matter of risk management. 3-2 will define a set of engineering measures to guide organizations through the process of assessing the risk of a particular IACS and identifying and applying security countermeasures to reduce that risk to tolerable levels.
By aligning the identified target security level with the required security level capabilities 3‑3, System Security Requirements and Security Levels it takes the earlier 1-1 standard a step further. 2-3, Patch Management in the IACS Environment addresses the installation of patches, also called software updates, software upgrades, firmware upgrades, service packs, hot fixes, basic input/output system updates, and other digital electronic program updates that resolve bug fixes, operability, reliability, and cybersecurity vulnerabilities. It covers many of the problems and industry concerns associated with IACS patch management for asset owners and IACS product suppliers. It also describes the effects poor patch management can have on the reliability and operability of an IACS.
The CIS Controls™ are a prioritized set of actions that collectively form a defense-in-depth set of best practices that mitigate the most common attacks against systems and networks. The CIS Controls are developed by a community of IT experts who apply their first-hand experience as cyber defenders to create these globally accepted security best practices. The experts who develop the CIS Controls come from a wide range of sectors including, retail, manufacturing, healthcare, education, government, defense, and others. So, while the CIS Controls address the general practices that most organizations should take to secure their systems, some operational environments may present unique requirements not addressed by the CIS Controls.
The guidance on how to apply the security best practices found in CIS Controls. For each top-level CIS Control, there is a brief discussion of how to interpret and apply the CIS Control in such environments, along with any unique considerations or differences from common IT environments. The applicability or not of specific Sub-Controls is addressed and additional steps needed in ICS environments are explained.
The overall concept is the use of the Admnistrative Asset Shell (AAS). It is requesting access to an object. In the context of an AAS an object typically is a submodel or a property or any other submodel element connected to the asset. The implemented access control mechanism of the AAS evaluates the access permission rules (2a) that include constraints that need to be fulfilled w.r.t. the subject attributes (2b), the object attributes and the environment conditions (2d). The focus is on access control. An object in the context of ABAC corresponds typically to a submodel or to a submodel element. The object attributes again are modelled as submodel elements. Subject Attributes need to be accessed either via an external policy information point or they are defined as properties within a special submodel of the AAS. A typical subject attribute is its role. The role is the only subject attribute defined in case of role based access control. Optionally, environment conditions can be defined. In role based access control no environment conditions are defined. Environment conditions can be expressed via formula constraints. To be able to do so the values needed should be defined as property or reference to data within a submodel of the AAS.
NAMUR, the "User Association of Automation Technology in Process Industries", is an international association of user companies (established in 1949) and represents their interests concerning automation technology. NAMUR numbers over 150 member companies. The achievement of added value through automation engineering is at the forefront in all NAMUR member company activities. NAMUR conducts a frank and fair dialogue with manufacturers.
NAMUR’s Automation Security working group 4.18 addresses issues including the following topics in the context of its experience exchange, its concept developments, formulation of requirements to be met by automation solutions and its involvement in national and international standardisation.
Relevant recommendations and worksheets
NA 163 Security Risk Assessment of SIS (Safety Instrumented Systems)
NA 169 Automation Security Management in the Process Industry. NA 169 describes the steps to systematically build a Cyber Security Management System (CSMS) for automation systems in the process industry in order to ensure the correct operation of the functional safety devices, to protect critical data and to ensure the availability and reliability of the plants
The Industrial Internet Security Framework (IISF) is a cross-industry-focused security framework comprising expert vision, experience and security best practices. It reflects thousands of hours of knowledge and experiences from security experts, collected, researched and evaluated for the benefit of all IIoT system deployments.
It builds on the ‘Industrial Internet of Things Reference Architecture’ (IIRA), that lays out the most important architecture components, how they fit together and how they influence each other. Each of these components must be made secure, as must the key system characteristics that bind them together into a trustworthy system.
It reviews security assessment for organizations, architectures and technologies. It outlines how to evaluate attacks as part of a risk analysis and highlights the many factors that should be considered, ranging from the endpoints and communications to management systems and the supply chains of the elements comprising the system. Different roles are identified that should be considered in conjunction with the key characteristics, including, owner/operator, system integrator/builder and equipment vendor. Each role offers different risk management perspectives that affect the decisions regarding security and privacy.
An industry-accepted way to document what security controls exist in IaaS, PaaS, and SaaS services, providing security control transparency. It provides a set of Yes/No questions a cloud consumer and cloud auditor may wish to ask of a cloud provider to ascertain their compliance to the Cloud Controls Matrix (CCM).
It helps cloud service providers and their customers to gauge the security posture and determine if their cloud services are suitably secure. In addition to improving the clarity and accuracy, it also supports better auditability of the CCM controls.
Universal Business Language (UBL) is an open library of standard electronic XML business documents for procurement and transportation such as purchase orders, invoices, transport logistics and waybills. UBL was developed by an OASIS Technical Committee with participation from a variety of industry data standards organizations. Version 2.1 was approved as an OASIS Standard in November 2013 and an ISO Standard (ISO/IEC 19845:2015) in December 2015
SensorThings API is an Open Geospatial Consortium (OGC) standard providing an open and unified framework to interconnect IoT sensing devices, data, and applications over the Web. It is an open standard addressing the syntactic interoperability and semantic interoperability of the Internet of Things. It complements the existing IoT networking protocols such CoAP, MQTT, HTTP, 6LowPAN. While the above-mentioned IoT networking protocols are addressing the ability for different IoT systems to exchange information, OGC SensorThings API is addressing the ability for different IoT systems to use and understand the exchanged information. As an OGC standard, SensorThings API also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems.