Skip to main content
Last Updated: June 4, 2014
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").
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.
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.
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.
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.
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).
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)" .
Masato Terada (HIRT), Naoko Ohnishi (HIRT) and Hiroko Okashita