.png)
February 20, 2024
To: Cybersecurity and Infrastructure Security Agency
Sent via email
Re: Operational Technology Cybersecurity Coalition Comments on the Secure By Design Whitepaper Request for Information
The Operational Technology Cybersecurity Coalition (OTCC) appreciates the opportunity to submit comments to the Cybersecurity and Infrastructure Security Agency (CISA) regarding the request for information (RFI) on its whitepaper Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Secure by Design Software.
The OTCC is a diverse group of leading industrial control systems (ICS) and operational technology (OT) cybersecurity vendors covering the entire OT lifecycle. As such, we appreciate the work that has gone into this effort so far and are glad to see CISA is looking for specific commentary on how OT should be included in future iterations of the paper.
OT makes up the hardware and software systems that monitor and control physical processes and devices in critical infrastructure, ensuring the resiliency, accessibility, and security of those systems are critical to functionality. As OT and information technology (IT) systems continue to converge, OT systems are increasingly exposed to cyber threats that can compromise their functionality and integrity.
The OTCC supports policies that promote cybersecurity by design for safety, security, and reliability. Products and services should be thoughtfully designed and built to proactively prevent and protect from malicious attacks and breaches. OT systems can differ significantly from IT systems and therefore require unique considerations when it comes to implementing Secure by Design, Secure by Default principles, to include:
Legacy Systems: Other physical components of OT networks – things like electricity transformers, water pumps, sensors, actuators and programmable logic controllers (PLCs) – are designed to last decades and are typically not designed for iterative upgrades so common in IT systems. This means that many OT systems in critical infrastructure are composed of legacy technology that is not suited to modern cybersecurity updates common in IT. These legacy systems were often designed without modern security controls like encryption, authentication, and access controls. As such, integrating modern cybersecurity measures common in IT into these older systems can be difficult, costly, and in some cases – not possible.
Incompatibility with Patching: Frequent updates and patches, common in IT environments, are often not feasible in OT environments. Applying patches can disrupt critical operations, and testing patches for compatibility is complex due to the real-time nature of OT processes and an emphasis on system availability. As a result, known vulnerabilities may persist longer in OT systems.
Diverse Ecosystems: OT environments encompass a wide range of devices, protocols, and vendors. In some cases, equipment is custom-made for customers. This diversity makes it challenging to implement standardized cybersecurity measures across the board. Each system might require a unique approach, complicating centralized management.
Risk to Human Safety: In OT environments, cybersecurity breaches can lead to physical consequences, such as equipment malfunction, environmental damage, and even threats to human safety. Balancing cybersecurity with the need for continuous and reliable operations becomes critical for asset owners and operators.
Limited Monitoring and Visibility: Unlike IT networks that generate extensive logs and data, many OT systems have limited logging and monitoring capabilities. This makes it challenging to detect and respond to cybersecurity incidents effectively.
With these five OT unique characteristics in mind, the OTCC is pleased to serve as a resource to CISA on policy matters related to OT and ICS policy matters, particularly when it comes to designing more secure systems.
Before answering your specific questions, we would like to request that CISA work with us and other interested OT/ICS stakeholders to produce a version of the Secure by Design guidance that is more applicable to the OT/ICS community than the current document. Given the sector’s unique needs and strong commitment to improving design practices, it is appropriate that CISA and the private sector work together to develop a guide that helps drive security improvement in this space for decades to come.
We believe that guidance should be based strongly on the core tenants of the National Institute of Standards and Technology (NIST) Secure Software Development Framework and ISA/IEC 62443-4-1 – the leading technical standard for the secure development of products used in industrial automation and control systems1. In fact, Practice 3 of this standard is entitled Secure by Design, and covers Secure by Design Principles, Defense in Depth Design, Security Design Review, and Secure Design Best Practices. Practice 4 covers Secure Implementation, Practice 5 is dedicated to Security Verification and Validation Testing, Practice 6 focuses on Management of Security-Related Issues, Practice 7 covers Security Update Management, and Practice 8 focuses on Security Guidelines. All of these elements are the keys to successful implementation of Security by Design practices in the OT/ICS area, and much work has been done to create and produce these standards. CISA should embrace them as the core of Secure by Design for the OT/ICS community, and work with key stakeholders to make any necessary updates or modifications. In addition to ISA/IEC 62443, the North American Electric Reliability Corporation (NERC) has worked for years to develop performance-based standards for the North American bulk power system, some of which may be able to be modified for other critical infrastructure sectors that rely on to OT/ICS.
Now, to help answer the OT-specific questions laid out in the RFI, we offer the following:
Which OT products or companies have implemented some of the core tenants of Secure by Design engineering? In OT, secure by design does not necessarily equate to only “security requirements.” Instead, it’s the processes, practices, and techniques used for each specific item being designed and made. One needs to understand what they’re designing to – i.e. the environment in which the component will be operating and potential threats it will face – in order to estimate the mitigations that will need to be built in. In OT, it is incredibly difficult to build in scalable security for every environment in which something like a PLC will be used. The key is to not get overwhelmed with the details of implementing security requirements, but instead adhering to the core principles of the Secure Software Development Lifecycle like those found in ISA/IEC 62443-4-1 and delivering components with security capabilities as described in ISA/IEC 62443-4-2 and 3-3. While the fundamental characteristics between OT and IT systems differ, the premise of secure by design engineering does not change across OT and IT. While the technology and usage intent will vary, the processes and principles such as threat monitoring, pen testing, vulnerability testing, effective security development, and security testing will remain the same.
What priority levels do customers place on security features and product attributes? What incentives would likely lead customers to increase their demand for security features, even if it costs more? Asset owners and operators consistently prioritize uptime and safety and have long lead times and very deliberate update and maintenance schedules. It is not uncommon for systems to remain up and running for years at a time. That, in turn, means that patches and updates might go unapplied for long periods of time. All of this sets the context for how customers look at security features and product attributes. In terms of priority, customers should expect an implicit baseline level of security and efficiency for products, which includes having the right defensive controls in place. At the same time, however, only larger organizations are better able to appreciate and build a business case for cybersecurity improvements than smaller organizations, which may avoid taking on the risk to modernize due to the expertise required to implement baseline cyber hygiene practices in OT networks. In terms of incentives, customers most often react to regulatory compliance (e.g. NERC CIP). Compliance is the number one drive of cybersecurity improvements, while awareness of risk directly affecting an enterprise is a distant second. While organizations such as Information Sharing Analysis Centers do a good job disseminating risk awareness, they do not reach all verticals that ICS systems are deployed in. Providing timely, specific awareness could act as an incentive to urge forward those customers who are unaware of the risks they face. In order to accomplish this, we believe it is important to draw a distinction between product security and component security. As previously mentioned, OT systems in critical infrastructure are composed of legacy technology and therefore not designed for iterative upgrades. By building in security to the components that make up the product, this layering defense mitigates risk to the overall system and compensates for the lack of upgrading. To achieve this more complete approach to security, we propose referencing NIST’s publication on IoT Device Cybersecurity Capability Core Baseline,2 as it “provides organizations a starting point to identify the device cybersecurity capabilities for new IoT devices that are manufactured, integrated, or acquired.” To be more cost effective in a constantly evolving space, we propose leveraging existing technology and investing in new IT and OT security appliances that can defend a larger footprint, rather than investing security into one product or a product unable to support the necessary safety controls.
Where could targeted investments be made to raise and scale security levels across OT? In order to raise and scale security levels across OT we propose providing free training on the Secure Software Development Framework (SSDF) to provide a baseline level of understanding on Secure by Design engineering processes and principles for product development and maintenance. In addition, we propose providing high quality training courses that cover coding in all languages, IoT, OT, and firmware. In order to train staff on product security, companies are already spending millions of dollars a year for secure development training – training that still lacks in terms of OT. Further, leveraging existing trainings and open sourcing such training would require minimal additional effort and resources. In addition, investments into Secure by Design training should be complemented by investments into training in OT cyber hygiene and risk management practices for critical infrastructure owners and operators where OT is frequently deployed. A well cyber-educated OT industry with better understanding of their cyber needs, will lead to more informed customers when managing and upgrading their enterprises. Such trainings would help ensure secure products are met with secure environments. While regulatory compliance is the strongest cybersecurity driver, we understand that CISA is not a regulatory agency. Therefore, raising awareness of cybersecurity risk within the asset owner/operator community is the best next option. To increase awareness of cyber risk, we suggest that CISA expand its their field team operations to be more involved with organizations on a greater regional, state, and local level to help drive better security among smaller organizations. Further, we propose CISA establishes a grant program for underserved critical infrastructure verticals to participate in field exercises for the purposes of educating and informing senior leaders across sectors to incentive security in data collection for operational readiness. Finally, we encourage innovation in specific areas such as the reduction of complexity associated with OT security (reduce the friction in implementing OT security), OT protocol standardization (move along the industry stack on legacy protocols lacking in security controls), and improve the platforms (not just focusing on applications) used to run OT solutions (topics like better memory management, more resilient networks, and improved edge/IoT cyber awareness).
Ultimately, Secure by Design in OT is a shared responsibility. While developers can design systems that are secure at the start, continued security depends on owners and operators, as well as those who maintain the systems, to do their part. They must execute best practices and continue to operate OT systems in a way that best secures the hardware and software that make up OT devices and systems. For holistic cyber defense at the systems level, Secure by Design products must be paired with secure by operation environments.
Again, the OTCC appreciates the work that CISA has done on Secure by Design and the effort to ensure OT specific needs are taken into consideration. We look forward to your reactions to our recommendations and stand ready to assist you in our shared desire to continue improving the state of OT/ICS cybersecurity.
Sincerely,
Andrew Howell
Executive Director, OTCC
Comments