Last Update: January 05, 2022
HIRT adopts the 4-IRT model of organizational scheme to promote vulnerability countermeasure implementation and incident response.
The 4-IRT model reflects the functional role of the corporation and consist of a coordination center of the IRTs (HIRT/CC, aka HIRT or HIRT Center), an IRT for the role as the developer of IT (Information Technology) / ICS (Industrial Control Systems) products (Product IRT), an IRT for the role as the system integrator (SI) and service provider using those products (SI Vendor IRT), and an IRT for the role as the Internet user to operate and maintain its IT/ICS systems.
HIRT-PUB10008 focuses on Hitachi's role as the developer of IT/ICS products (Product IRT) and introduces the vulnerability disclosure process of the Hitachi group (hereinafter referred to as "Hitachi").
* IRT(Incident Response/Readiness Team)
A general term for an organization that detects the occurrence of cyber security incidents and coordinates with relevant players to prevent the damage from escalating and investigates and collects the cause to prevent the reoccurrence. It is also called CSIRT (Cyber/Computer Security Incident Response/Readiness Team).
Figure 1 shows the product vulnerability disclosure process promoted by the Hitachi. The process is broadly divided into 3 steps.
Step 1: Acquisition of Vulnerability Information ... (1) ISO/IEC 29147:2014 Vulnerability disclosure
Step 2: Investigations and Fixing Vulnerability ... (2) ISO/IEC 30111:2013 Vulnerability handling processes
Step 3: Information Disclosure ... (3)(4) ISO/IEC 29147:2014 Vulnerability disclosure
The following sections outline each of 3 steps.
Figure 1: Product Vulnerability Disclosure Process.
There are several channels to obtain the information on the vulnerabilities, the method to examine them and the attacking techniques (hereinafter referred to as "the vulnerability related information"). Major channels are listed below in order of the amount through which vulnerabilities have been reported.
HIRT and those involved in the product development in Hitachi are proactively working on discovering and eliminating the vulnerabilities as one of the efforts to improve the product security. In this process, vulnerability may be found during the product development process, such as at the design review phase, testing phase and inspection phase. If a found vulnerability affects the products of other vendors outside the Hitachi, it is reported to the contact point for the Information Security Early Warning Partnership and the collaborative vulnerability countermeasure actions are initiated. "JVN#79314822: Tomcat vulnerable in request processing" is an example of the case where a vulnerability affected the products of other vendors and was reported to the Information Security Early Warning Partnership.
Some mailing lists, such as Bugtraq, and the website of the security vendors and product vendors provide the vulnerability related information and make them available to the public. HIRT collects that information in collaboration with the product development departments, including the investigation on whether a similar vulnerability has been reported.
The Hitachi has been a member of the Information Security Early Warning Partnership as a product development vendor since July 2004, and promoting the vulnerability countermeasure implementation. HIRT acts as the contact point for the Hitachi and disseminates the vulnerability information obtained through the Partnership to the product development departments.
HIRT has set up a special contact point for CERT/CC to directly receive the vulnerability related information since 2005. The vulnerability related information reported to HIRT is forwarded to the relevant product development departments.
An initial report from the security researchers may not be directly made to HIRT. HIRT collaborates with the department that received the initial report, follows up the reported vulnerability, as well as disseminates the information to the relevant departments. "JVNVU#472363: IPv6 implementations insecurely update Forwarding Information Base" is an example of the case where the vulnerability was reported by a security researcher. Please refer the Acknowledgments of vulnerability handling and incident response for detail.
Once the product development departments received the vulnerability related information, they investigate the vulnerability and prepare the security patch.
The basic principles of the investigation and fixing the vulnerability are that the countermeasure should be available at the same time as the vulnerability is disclosed and that the release date should be coordinated among the relative parties.The former means that the vulnerability and its security patch should go hand-in-hand when disclosed.The latter means that release date of the vulnerability that could affect the various products of the various vendors should be coordinated and agreed among those vendors.As needed, the timeline to the release date is coordinated among the relative players, such as the Information Security Early Warning Partnership and the security researcher.
Some vulnerabilities stem from the implementation and the others stem from the specifications, such as the protocols.In case of the latter, it is necessary to consider the impact that the countermeasure may have on the target's behaviors, such as interoperability.In such a case, with the help of CERT/CC and JPCERT/CC that are the designated coordination authority for the vulnerability countermeasure issue, the department may set up a meeting to discuss the countermeasures and possible impact of them to consider the options.JVNVU#472363 on IPv6 vulnerability reported in 2008 is an example that employed the said approach.For more information on how VU#472363 was handled, check out "Internet Week 2008: Most Challenged Vulnerabilities in 2008: IPv6 Vulnerability VU#472363 (in Japanese)".
Upon completing fixing the vulnerability, the product development department prepares the information on the vulnerability and countermeasure to be released.
When disclosing the vulnerability information, it is important to consider the said principles that the countermeasure should be available at the same time as the vulnerability is disclosed and that the release date should be coordinated among the relative parties.If information on a vulnerability is disclosed to the public or leaked to the malicious parties while still investigating and fixing the vulnerability, malicious codes (exploit codes) may be developed, circulated and used to attack the computer systems leaving the product users without the way to defend them.Such a situation is way too dangerous and must be avoided.When the vulnerability affect the product that is used in the systems of more than one organization, especially when the vulnerability affects the products of multiple vendors, acting solely and disclosing the vulnerability information ahead of the date agreed by the relative parties, will endanger the computer systems that use other affected products.For this reason, if the vulnerability notified from the Information Security Early Warning Partnership or JPCERT/CC is found to affect the products of multiple vendors, the principle that the release date should be coordinated among the relative parties and the disclosure is being held back till the agreed date (Figure 2).
In the past, there was an incident where a third party posted a CERT/CC vulnerability information that was not supposed to be disclosed to the public to a public mailing list ( [Full-Disclosure] Overflow in SunPRC-derived XDR libraries ). This gave the lesson that the vulnerability and security information must be controlled properly.
Figure 2: The principle of coordinating the release date among the relative parties.
(= A framework to defend the information systems from threat of cyber attack)
On the release date, the product development department notifies its product users about the vulnerability countermeasure information through its customer support service via email and the website.
In September 2005, HIRT opened a one-stop portal that aggregate the security information released at the website of the Hitachi and the Hitachi group companies to provide the security information on the Hitachi products and services to the users in an integrated way.
Security Portal
Japanese: http://www.hitachi.com/hirt/
English: http://www.hitachi.com/hirt/
As for the vulnerabilities notified through the Information Security Early Warning Partnership and CERT/CC, Hitachi will publish the information on how Hitachi is responding to the reported vulnerability on JVN (Japan Vulnerability Notes), a domestic vulnerability countermeasure information portal, CERT/CC Vulnerability Notes Database, and promote the implementation of the countermeasure.
Since July 2009, Hitachi has been proactively working to improve the infrastructure to efficiently use the vulnerability countermeasure information in Japan.
Since 2013, Hitachi has carried out the efforts using the approach of extending into the ICS domain, the empirical experience from the HIRT activities implemented to date. It's the establishment of framework with HIRT as basic point of contact for external organizations for vulnerability handling for IT/ICS products (Figure 3).
Figure 3. Framework for vulnerability handling for IT/ICS domain by HIRT.
Please refer each Hitachi product page for the version life cycle or EOL (End of Life).
The guide is a standard that outlines how to proceed when vulnerability is discovered. It was established on July 7, 2007. It aims to prevent the damage that can be inflicted on the general public users due to the attacks, such as computer viruses and unauthorized access, and ensure the safety of the advanced information and communications network by promoting the circulation of the vulnerability countermeasure information and encouraging the implementation of the countermeasure.
The Partnership is a framework to receive a report regarding vulnerability, require the product developers or website administrators to fix the vulnerability, notify the public and encourage to implement the countermeasure (Figure 4). It was established as a public-private partnership under the Software Vulnerability Related Information Handling Measures and started its operation on July 8, 2004. It aims to prevent the vulnerability information from being released to the public before the countermeasure becomes available and misused by computer viruses and in unauthorized access as well as to prevent the damage that can be caused by incidents, such as information leak or system crash. When vulnerability is discovered, IPA receives the report, and JPCERT/CC determines which products are affected by the vulnerability, notifies the product vendor(s) and coordinates the response. JVN publishes the information on the detail on the vulnerability and the vendor's response to the vulnerability to encourage the users to implement the countermeasure.
For more information on reporting the vulnerability through the Information Security Early Warning Partnership, refer to http://www.ipa.go.jp/security/vuln/report/index.html (in Japanese).
Examples of the incidents where the vulnerability information was disclosed to the public before the countermeasure was made available and used in attacks are "Vulnerability in Help and Support Center Could Allow Remote Code Execution (MS10-042)" and "Java Development Toolkit insufficient argument validation (VU#886582)". For more information on the disclosure of vulnerability with no available countermeasure (excluding workarounds and mitigation measures) and attacks that targets those vulnerabilities, refer to "HIRT-PUB10004: Zero-Day Attacks and Vendor Responses (2010) (in Japanese)" and "HIRT-PUB11001: Zero-Day Attacks and Vendor Responses (2011) (in Japanese)".
Figure 4. Framework overview of the Information Security Early Warning Partnership.
A domestic vulnerability countermeasure information portal site that publishes the vulnerabilities reported through the Information Security Early Warning Partnership with the detail and the product developer's response status to let the users know about the vulnerabilities. HIRT has been supporting the JVN since June 2002.
ISO/IEC 29147 provides a guideline for vendors to include in their normal business processes on receiving information about potential vulnerabilities from people or organizations externally and distributing vulnerability resolution information to affected users (Figure 5).
ISO/IEC 30111 gives guidelines for how to process and resolve potential vulnerability information reported by individuals or organizations that find a potential vulnerability in a product or online service (Figure 5).
Figure 5. Relationship of 29147: Vulnerability disclosure and 30111: Vulnerability handling processes.
Masato Terada (HIRT), Naoko Ohnishi (HIRT) and Hiroko Okashita
