Evolving Security Risk and Responsibility in the Industrial Internet of Things

Industrial Control Systems (ICS) are essential elements of the modern world.  They are core components of the Industrial Internet of Things.  As cyber threats have begin targeting ICS, Security is now an important element of Reliability and Safety. Organizations that operate and procure components from ICS Original Equipment Manufacturers (OEMs) understand that their systems are only as safe and reliable as their least secure components.  As a result, these organizations are beginning to contractually shift the responsibility for assuring components are secure to the OEMs.


NIST has identified Threat Sources, Vulnerabilities, and Incidents in ICS that show how ICS systems have been successfully attacked.  In 2013, the Department of Homeland Security’s ICS Computer Emergency Response Team (CERT) cataloged 177 exploitable vulnerabilities found in ICS products from 52 vendors. Many famous ICS attacks like Stuxnet and less famous attacks exploit vulnerabilities like those found in these ICS products. While most attacks operational systems will encounter will not be as complex, Stuxnet is both an example of possible modern attacks and contains many elements used by successful, less complex attacks.  Portions of the Stuxnet attack that should be of concern to ICS Original Equipment Manufacturers (OEMs):

  • Products attacked had little or no security.  Once a product was accessed, there was no security to prevent unauthorized configuration or programming changes to cause the unintended operations the attacker desired.  Does your product have correctly implemented security features?
  • The attack used several “zero-day” exploits.  Zero-day exploits are vulnerabilities identified by the attacker but not used until needed.  As a result, there was no warning to the OEM through its own resources or third parties that their product was vulnerable.  Do you know how the code in your company’s product was developed and if it has existing security vulnerabilities?
  • The OEM’s development system was compromised.  The attacker introduced malware into the OEM’s development systems that hid additional malware that was incorporated into software builds for the OEM’s products. While this method required advanced technology, insider attacks by developers provide a simpler and more accessible method to compromise code.  How does your company ensure it knows what is in the code it is shipping in its products?
  • The attackers stole authentication data from an OEM.  This theft allowed the attacker to “sign” code and enable it to pass security checks the OEM used to prevent unauthorized code to be loaded into its product.  How does your company authorize updates to its products in the field?
  • The attack was targeted to specific equipment and operation.  Malware can be embedded into products and remain dormant for use by the attacker at a time/condition of their choosing.  As a result, a general operational check of a device at or before delivery is not representative of future operation during attack.  How does your company test the security of its products?
  • The attackers obtained detailed design information on the products targeted.  Modern attacks are based on intelligence, not just technology.  If an OEM’s products are available to an attacker through legitimate or illegitimate means, the attacker will obtain them and test their attacks on them.  If design data is available though documentation and/or former employees, the attacker will obtain it and use it to design the attack.  How does your company protect its Intellectual Property?

Key Take-Away for OEMs: Although the Integrator and Operator of the system attacked by Stuxnet was concerned about security, the attacks succeeded in part by compromising products supplied by third-party OEMs.



The success of Stuxnet and other attacks on critical infrastructure has raised concern on the security of these systems.  This concern has driven the tailoring and adoption of IT security standards into these non-IT applications.  To ensure that the security is implemented, language is being added to contracts with OEMs for products and Primes/Integrators for systems.  An example of this language was defined in 2014 by the Department of Energy. While the Government provides the guidance, most Energy related contracts are commercial.  This language was adapted from security best practices and will likely be a prototype for other Industrial Internet of Things applications.

This language includes:

  • Security features, processes, and technologies adapted from IT standards.  These include: Access Control, Authentication, Auditing, Network Security, Malware Protection, and Intrusion Detection.  While selection/scope of the language will vary by application, OEMs should be prepared to respond to and negotiate final security compliance.
  • The requirement for the OEM to show that they have a Life Cycle Security Program in place.  Similar to Quality Systems, having a Life Cycle Security Program in place shows that the OEM’s product was developed following by a documented, auditable process incorporating best security practices.  Also like a Quality System, this Life Cycle process cannot be retroactively applied to a product.  Products developed without this process can be used but they will require an extra level of scrutiny and risk acceptance.

Key Take-Away for OEMs:  Contract language requiring security in non-IT products is in use.  Compliance with this language requires a proactive investment in security by OEMs to ensure they can meet the requirements.


Electronic component counterfeiting is an ongoing challenge to both the reliability and security of systems.  Counterfeit components may not function the same as the OEM’s original components leading systems to perform differently than designed.

In an attempt to reduce the risk of counterfeit components, organizations are adopting standards such as SAE AS5553A to protect their supply chain.  When added to contracts, language from these standards transfers the liability for counterfeit components to to supplier/OEM of the equipment.  This can include the larger component an electronic part is contained in, software/firmware loaded into the part, and/or "tainted" parts that have had malware added to them.

The effect of this regulation is that Prime Contractors and System Integrators are flowing down compliance to the regulation as a contractual requirement to Industrial Internet of Things OEMs.  Organizations are reducing their security exposure by contracting out the risk. In the Information Technology industry, security is now a common element of Service Level Agreements.

Key Take-Away for OEMs: An OEM’s ability to prove their products provide the required level of security is becoming a requirement to do business.


Secmation provides a wide range of products and services to aid Product Teams implement Security efficiently leading to on-time product launch.  Our Experts have led product development through the full lifecycle and understand how Security is integrated efficiently into the product.  We understand product requirements and regulations in the Industrial Internet of Things including SCRM.

The Secmation Rapid Start Process can quickly get a Product Team started developing secure products.  We can work with the organization to improve security over time and respond to security events.

We understand the particular needs of Control Engineers to design and develop systems that meet stringent performance, safety, reliability, and cost requirements.  We speak the same language and can add security to control systems with limited compromises.  We understand modern attacks that can target both the computing and control algorithms.