Understanding Software Supply Chain Risks
image credit: © Artur Szczybylo | Dreamstime.com
- Apr 27, 2020 10:32 pm GMTApr 27, 2020 10:31 pm GMT
- 753 views
This item is part of the Cybersecurity - Special Issue - 04/2020, click here for more
The material presented in this article represents the accumulation of knowledge and experiences gathered over 18 months of development and testing, performed during the creation of Reliable Energy Analytics LLC (REA) Software Assurance Guardian Point Man™ (SAG-PM™) Supply Chain verification software. On April 6th the North American Electric Reliability Corporation (NERC) filed a request with the Federal Energy Regulatory Commission (FERC) to extend the deadline date for compliance with FERC Order 850 (Supply Chain Regulations) until October 1, 2020. REA fully supports NERC’s petition to delay implementation of the FERC Order 850 effective date until October 1, 2020, for the following reasons:
- Key components needed to effectively verify supply chain vendor integrity for proper business practices are still under development. The North American Transmission Forum (NATF) is leading an industry initiative to define key components, such as standard vendor questionnaires intended to provide responsible entities with the information needed to verify vendors, using standard terms and semantics. A draft version of the questionnaire is scheduled for release in May, 2020. However, many implementation details remain unanswered, for example: How will vendors make their standardized responses available to customers and prospective customers; Will a common database, similar to NAESB’s EIR be available to search for vendor responses?
- Some BES responsible entities are still working on their Supply Chain Risk Management plans and many lack a standardized method/best practice to perform software verification, in accordance with CIP-010-3 R1 part 1.6 and record a standardized proof of evidence. Many smaller companies lacking critical cybersecurity skillsets are especially vulnerable to harm from malicious software, i.e. ransomware, until such time that they adopt and implement appropriate controls to verify software integrity and authenticity.
- Currently, there are no proof of evidence standards leaving the decision of what information to record as proof of verification open to each Company’s own discretion. This lack of a standard proof of evidence will make it difficult for NERC and FERC auditing personnel to determine if adequate and effective controls are in place to secure the BES from harmful software and illegitimate, or compromised, vendors. Lack of a defined standard for proof of evidence leaves open the possibility for ambiguities that make compliance auditing difficult. A defined standard for proof of evidence would benefit both auditors and responsible entities in knowing what information is needed, for CIP-010-3 R1, Part 1.6 compliance and, more importantly, to know that adequate and effective protection controls are being followed.
- 18 months of software development and extensive testing of REA’s Software Assurance Guardian Point Man™ (SAG-PM™) software has identified numerous, and sometimes surprising, risks in the software supply chain, including, but not limited to:
- Suspect source locations where software objects are made available for customer download. Some locations lack digital certificates that are needed to verify the entity providing access to a software object. Some locations are using digital certificates from Certification Authorities that perform no identify vetting. Some digital certificates failed TLS/SSL verification, raising doubts over the integrity and authenticity of a site. Self-signed Digital Certificates provide a veil of trust that may not be warranted, affecting the trustworthiness of a download location and its provider.
- Numerous test cases have revealed the presence of BLACKLISTED IP addresses that exist in the route used to acquire and download a software object, raising concerns over man-in-the-middle attacks. Several test cases have identified IP addresses that exist outside the United States, providing hostile nations an opportunity to inflict harm.
- Varying levels of meta-information contained within a software object make it difficult to ascertain the original software developer, product names, versions, and inherent risks that exist in a software object, if it were to be installed in a critical system.
- Real SAG-PM test cases have identified software objects using digital signatures that are being reported as valid, but have been created using expired Digital Certificates, some as far back as 2014. Upon further introspection, these same software objects were also found to contain trojan vulnerabilities that could bring harm to the BES. Software containing valid digital signatures alone are an insufficient control at protecting against harm to the BES.
- Lack of a standard vendor questionnaire and response that is needed to ascertain a trustworthiness score for vendors within the supply chain. Additionally, there is no standard mechanism to make these vendor responses available to interested parties.
- Vulnerability search results from well-known vulnerability databases have shown a poor sign/noise ratio, making it difficult to determine if a known vulnerability is applicable to a given software object and version. More specific vulnerability search criteria and a structured response, i.e. JSON or XML, would help.
In summary, these are just a few of the issues that have been identified over an 18-month period during which SAG-PM software development and testing procedures were underway. Many Companies, especially smaller Companies, that lack access to the level of cybersecurity skill sets needed to manually perform effective, risk-based analysis security controls. These Companies could benefit from having access to best practices for software supply chain risk analysis, like those implemented in SAG-PM, in order to make a risk-based decision to install, or not install, a software object in a BES critical system.