The Cybersecurity and Infrastructure Security Agency’s (CISA) activities aim to promote coherence between government and industry. This capability helps CISA anticipate, prioritize, and manage industrial control systems (ICS) risks at the national level. CISA helps control system vendors and asset owners/operators identify security vulnerabilities and develop sound, proactive mitigation strategies that will strengthen their ICS cybersecurity.
For this reason, One of CISA’s activities was also the creation of a document describing the Common Industrial Control System Vulnerability Disclosure Framework. This document was created to provide vendors and system integrators with consensus guidance for developing vulnerability disclosure policies. However, this document is not intended to be prescriptive. The fact is that each vendor has specific challenges relating to how their products are used and the potential risks inherent in different disclosure paths.
Software Vulnerabilities
The largest part of the document is devoted to software vulnerabilities. As mentioned in the document, this superclass of vulnerabilities encompasses several different categories of software issues, each of which must be evaluated independently. In addition, it does not include issues related to software vulnerabilities identified in third-party products.
Here follows discussed 3 types of vulnerabilities:
Architectural Vulnerabilities
Architectural vulnerabilities in software can occur when the design of an application or component exposes a security flaw despite the use of appropriate coding standards. The next reason could be even because of maintaining legacy support. They most often occur in the first phase, during the design of the application. The discovery of such a vulnerability may occur when the ICS application is deployed.
The document gives the following examples of architectural vulnerabilities:
- Internal services exposed to external connections without appropriate security
- Communication channels existing between multiple hosts without adequate authentication or authorization elements
- Inadequate or absent input parsing on server or middleware applications allowing injection attacks
- A lack of cryptographic protection for business-sensitive communications
These vulnerabilities are among the most difficult to mitigate appropriately. Often it is necessary to sacrifice functionality or significantly reconfigure an existing solution.
Implementation Vulnerabilities
Code-based vulnerabilities arise, for example, when a function or feature of an application is implemented incorrectly by failing to follow secure coding policies and procedures. These vulnerabilities are the most visible because they are regularly identified and patched as part of the normal product lifecycle. Methods for recognizing them are, for example:
- Manual code reviews
- Static code analysis
- Compile-time functional analysis – scanning for deprecated or insecure functions
This type of vulnerability can be removed quite easily, just by small changes in the code. Specific application components are replaced with newer components that no longer contain the vulnerable code.
Third-Party Software Vulnerabilities
This type of vulnerability affects software components used in first-party/vendor products. Moreover, they may be design or implementation related. Software solutions often use third-party application code, which creates the potential for vulnerabilities affecting the product. However, they are not under the direct control of the software vendor. The third-party products used can range from individual libraries to embedded applications. In addition, they may include independent applications that are sold alongside the vendor’s applications.
The document also describes mechanisms for identifying vulnerabilities, namely:
- Internal Vulnerability Discovery – Design/Development Time
- Internal Vulnerability Discovery – After Release
- External Vulnerability Discovery – Customer Discovery
- External Vulnerability Discovery – Customer Audit Discovery
- External Vulnerability Discovery – Independent Researcher
- External Vulnerability Discovery – 0-Day
- Vulnerability Disclosure Policy Components
The last part of the document deals with components, which form the basis for a formal Vulnerability Disclosure policy. The key to securing any company is understanding the purpose of its vulnerability disclosure policy. It is not possible to cover all cases, but such a policy is invaluable for making situational decisions. At each stage of the remediation process, it is necessary to know the steps to be taken. These matters are dealt with by the authors of the document in the section Policy Commitments.
References
Vulnerability disclosure framework
