1. Introduction
The aim of this document is to identify and analyze examples of practices of reporting information security incidents.
The document was prepared by surveying various sources related to the field of reporting information security incidents. These sources include, but are not limited to, literature, laws, codes of conduct, best practices, and websites of organizations managing such schemes. For the purpose of this document, data breach notification schemes and the mandatory schemes in the European Union concerning the notification of cyber security incidents in the telecommunications sector are excluded from this document.
After this introduction, a list of ten identified practices is provided (Section 2). Then, the findings of the analysis of identified practices are presented (Section 3). Finally, a conclusion is drawn (Section 4). In addition, a table providing an overview of each of the identified practices is attached to this document as an annex.
2. A list of ten identified practices
1. Reporting scheme set out in the Act to Strengthen the Security of Federal Information Technology of 2009 (Germany)
2. Reporting scheme set out in Best Practices for Web Hosting Providers published by StopBadware (StopBadware is an US based not for profit organization focused on protecting the public from badware websites)
3. Reporting scheme set out in the Disaster Information Reporting System (USA)
4. Reporting scheme set out in Federal Information Security Management Act of 2002 (USA)
5. Reporting scheme set out in IETF Recommended Internet Service Provider Security Services and Procedures 2000 (Internet Engineering Task Force)
6. Reporting scheme set out in the Information Technology Act 2000 as amended from Amendment Act of 2006 (India)
7. Reporting scheme set out in Internet Industry Code of Practice of 2010 (Australia)
8. Reporting scheme set out in Internet Service Provider (ISP) Network Protection Practices written by the Computer Security, Reliability and Interoperability Council (CSRIC) of the Federal Communications Commission (USA)
9. Reporting scheme set out in ISO/IEC 27002:2005 Information technology — Security techniques — Code of practice for information security management (International Organization for Standardization and the International Electrotechnical Commission).
10. Network Outage Reporting System (USA)
3. Findings of the analysis of identified practices
Due to the complexity of the schemes for reporting information security incidents, it is impossible to provide a detailed analysis on all characteristics of the schemes. Instead, only the major issues will be addressed. In particular, the following parts of the schemes for reporting information security incidents will be subject of this analysis: primary area of reporting (Subsection 3.1), purpose of the scheme (Subsection 3.2), reporting obligation (Subsection 3.3), incidents that trigger the reporting scheme (Subsection 3.4), authorities managing the scheme (Subsection 3.5), entities that are obliged or entitled to report on information security incidents (Subsection 3.6), incentives given to the entities to report information security incidents (Section 3.7), entities to which the report of information security incident should be sent (Subsection 3.8), requirements for the format of report (Subsection 3.9), timing requirements (Subsection 3.10), reporting channel (Subsection 3.11), confidentiality of the information submitted in the report (Subsection 3.12), follow-up procedures (Subsection 3.13), coordination and information distribution (Subsection 3.14), ex-post analysis of individual incidents (Subsection 3.15).
3.1 Primary area of reporting
All of the examined schemes have as their primary area of reporting either cybersecurity incidents or network faults.
3.2 Purpose of reporting
The examined reporting schemes tend to focus on one or more of four main objectives. These are: (1) incident response, (2) incident prevention, (3) rectification of incidents (4) informing users affected by the incidents.
Schemes focused on incident response
The schemes focused on incident response aim enabling sharing of information and coordination during emergency situations or time-sensitive incidents.
For example, the Federal Information Security Management Act of 2002 (FISMA) states that the federal agencies must develop procedure for reporting, including notifying and consulting with the Federal information security incident center. The Federal information security incident center provides timely technical assistance to operators of agency information systems regarding security incidents, including guidance on detecting and handling information security incidents.
Another example of scheme focused on incident response is the Code of Practice of the Australian Internet Industry Association which states that, when an ISP identifies suspicious or malicious activity against ISP network which may constitute a significant cyber security incident, CERT Australia should also be given visibility of the issue.
Schemes focused on incident prevention
The schemes for incident prevention are focused on reducing the number of incidents. Such schemes aim at collecting information on threats and using it for prevention of incident. Two examples of such schemes are provided in this paragraph.
The first examples is the reporting scheme for incident prevention is contained in the German Act to Strengthen the Security of Federal Information Technology, which states that, if the federal authorities become aware of information necessary to prevent threats to IT security which is significant for carrying out tasks or for the IT security of other authorities, these federal authorities must inform the Federal Office for Information Security.
The second example of a scheme for incident prevention is the Best Practices for Web Hosting Providers published by StopBadware. It states that the web hosting providers should periodically review previously tracked incident reports. The reason for this is because it will allow the web hosting providers to identify patterns of infection and operational lessons that may not be obvious in the midst of addressing individual issues. Thus, they will be able to prevent incidents.
Informing users affected by the incidents
The purpose of many of the examined schemes is to inform users affected by the incident. For instance, the reporting scheme set out in IETF Recommended Internet Service Provider Security Services and Procedures 2000 state that ISPs should be proactive in notifying customers of security vulnerabilities in the services they provide.
3.3 Reporting obligation
Mandatory reporting
Four of the examined schemes are mandatory. Two operate in USA, one operates in Germany, and one operates in India. Usually, the obligation for reporting amounts to a small legal clause in a regulatory act which is not devoted specifically on the scheme. In the case of Network Outage Reporting System (NORS), however, the reporting obligation is contained in a rule issued by the Federal Communications Commission (FCC) which is devoted specifically on the scheme.
When the obligation for reporting is contained in a regulatory act which is not devoted specifically on the scheme, the authorities managing the scheme may be entitled to develop policies to implement this clause. For instance, FISMA states that each agency shall develop, document, and implement an agency wide information security program.
It should be also noted that, when the obligation for reporting is implemented in a legal clause in a regulatory act which is not specifically devoted on the scheme, authorities, different than those managing the scheme, may be entitled to develop policies for the implementation of the clause. For example in Germany, according to the Act to Strengthen the Security of Federal Information Technology, with the approval of the Council of Chief Information Officers of the federal ministries, the Federal Ministry of the Interior shall issue general administrative regulations with regard to the obligation of federal authorities to inform the Federal Office for Information Security of information about threats to IT security.
In the case of NORS, where the reporting obligation is contained in a rule devoted specifically only on the scheme, the reporting scheme is described in details. Nevertheless, the Federal Trade Commission delegates authority to the Chief, Office of Engineering and Technology, to make the revisions to the filling system and template necessary to improve the efficiency of reporting and to reduce, where it is reasonably possible, the time for providers to prepare, and for the Commission staff to review, the communications disruption reports.
Voluntarily reporting
Five of the examined schemes for voluntarily reporting schemes are contained in either Code of practices or Best Practices. One of the examined practices, Disaster Information Reporting System (DIRS), is a web-based system.
In three cases, the authors of the examined schemes for voluntarily reporting are standards developing organizations. Three other schemes for voluntarily reporting are written, respectively, by an advisory committee of national telecommunications regulator, an NGO, and an industry association.
3.4 Incidents that trigger the reporting scheme
The incidents that trigger the examined reporting schemes can be classified in two groups, namely, cybersecurity incidents and network faults. Because telecommunications networks are dependent on IT components, there is some overlap between these two types of incidents. However, the procedures for reporting cybersecurity incidents and network faults tend to differ. Below, we will analyse the reporting schemes that can be triggered by cybersecurity incidents (Subsection 3.3.1) as well as the reporting schemes that can be triggered by network faults (Subsetion 3.3.2).
3.4.1 Cybersecurity incidents
Types of cybersecurity incident that can trigger the scheme
Most of the schemes that have cyber security incidents as their primary area of reporting can be triggered by every type of cybersecurity incident. This is because they do not specify the type of incident that can trigger the reporting mechanism. In such schemes, the definition of cybersecurity incident can be “information necessary to prevent threats to IT security, especially information concerning security vulnerabilities, malicious software, successful or attempted attacks on IT security and the means used to carry out such attacks”, “security incidents”, “security incidents that affect components of an ISP’s infrastructure”, “any event has occurred or any situation has arisen which may materially and adversely affect the integrity of the computer system”, “suspicious or malicious activity against ISP network which may constitute a significant cyber security incident”, “information security events, incidents and weaknesses (including near-misses)”.
Two of the schemes that have cybersecurity incidents as their primary area of reporting can be triggered only by a specific type of cybersecurity incidents, namely, malware. One of these schemes, Best Practices for Web Hosting Providers published by StopBadware, uses the word badware instead of malware and defines badware as “software that fundamentally disregards users’ choices about how their computers or Network connections are used”. The other scheme, Internet Service Provider (ISP) Network Protection Practices written by CSRIC, uses the phrase “infection with malware” as the trigger of the scheme, but it does not provide a definition of malware.
The reporting thresholds
Only three of the examined schemes for reporting cybersecurity incidents use reporting thresholds. These three schemes state that, in order to be reported, a cyber security incident needs to be, respectively, “significant”, “materially and adversely affects the integrity of the computer system”, or “fundamentally disregards users’ choices about how their computers or Network connections are used”.
It should be noted that the Code of Practice of the Australian Internet Industry Association gives an indication of what a “significant cyber security incident” means. It states that suspicious or malicious activity against ISP network which may constitute a significant cyber security incident, includes, but is not limited to, activity that is “(i) novel or not previously seen by the ISP; or (ii) impacts well beyond the capacity of private enterprise to manage; or (iii) involves serious malicious intent; and (iv) involves serious threats to Australian telecommunications network or other critical infrastructure.”
3.4.2 Network faults
Types of network faults that can trigger the scheme
Two of the examined schemes, namely, NORS and DIRS, can be triggered by network faults. The incident that can trigger NORS is “significant degradation in the ability of an end user to establish and maintain a channel of communications as a result of failure or degradation in the performance of a communications provider’s network”. DIRS does not specify the type of incident that can trigger the scheme. It only mentions that the system can be used for reporting communications infrastructure status and situational awareness information during times of crisis. DIRS’ webpage also mentions that, typically, DIRS is only activated for major disasters.
The reporting thresholds
NORS specifies which thresholds are significant by stating that the providers covered by the scheme are only required to report “outages” that last at least 30 minutes and (1) meet certain user-based thresholds, (2) meet certain capacity-based thresholds, (3) potentially affect specific aspects of 911 communications, (4) potentially affect special offices and facilities, or (5) result in a failure of certain critical elements of the network.
DIRS states that it is typically activated for major disasters without defining what a “major disaster” means.
3.5 Authorities managing the scheme
The authorities managing the scheme are authorities that (1) analyze incidents individually and follow up with the incident owners, (2) evaluate incidents statistically and draw lessons, (3) manage long-term evolution of the scheme.
Most often, the telecommunications regulatory authorities have responsibilities for managing mandatory reporting schemes. The Federal Information Security Management Act of 2002 (FISMA), however, obliges each federal agency to develop, document, and implement an agency wide information security program, approved by the Director, to provide information security for the information and information systems that support the operations and assets of the agency that includes procedures for reporting security incidents. Consequently, in the case of FISMA, the managing of the scheme is done by a federal agency, not by a telecommunication regulatory authority.
3.6 Entities that are obliged or entitled to report on information security incidents
On the basis of this research, the following groups of entities which are obliged or entitled to report on information security incidents can be identified: (1) telecommunications operators, (2) government agencies (3) ISPs, (4) Authorities issuing digital signature certificates, (5) others, including commercial enterprises of all sizes, not-for-profits, charities, government departments and quasi-autonomous bodies.
3.7 Incentives given to the entities to report information security incidents
In all mandatory reporting schemes, the non-compliance with the obligation for reporting will be an infringement of the law. Thus, avoiding an infringement of the law is the main incentive for the entities which are obliged to report security incidents. In the case of NORS, for instance, when a communications provider wilfully or repeatedly fails to comply with the FCC Outage Reporting Rule, the FCC may issue a Notice of Apparent Liability for Forfeiture. Subsequently, if the forfeiture is not paid, the case will be submitted to the Department of Justice which is entitled to enforce the forfeiture order by bringing a civil suit against the provider.
With regard to the voluntarily reporting schemes, the incentives may vary. They can be (1) improving the good order and health of the Web hosting providers’ infrastructure and strengthen the chain of trust that underpins the open Internet, (2) allowing communications providers to identify the appropriate contact for his/her station during emergencies which will, in turn, eliminates lost time when trying to identify and coordinate with the federal contacts who can provide immediate assistance, (3) providing an avenue for communications providers to restore their operations and receive additional help during emergencies, e.g., securing generators, fuel, (4) reducing the number of requests from various government agencies for status of each station, (5) ensuring that communications providers will be able to serve their communities, providing them with critical updates and risk communications information from reliable and credible sources during emergencies, (6) improving awareness of suspicious activity on their networks, leading to a more timely and effective response to threats, (7) reducing service calls from customers related to security issues, (8) offering customers a greater level of confidence in the security of their internet connections, (9) addressing the growing botnet problem in consumers end-user devices and ISP networks.
3.8 Entities to which the report of information security incident should be sent.
On the basis of this research, the following groups of entities to which the report of information security incident should be sent were established: (1) government agencies, including telecommunications regulatory authorities, (2) users affected by the incident, (3) ISPs, (4) CERTs and information security incident centers, (5) law enforcement agencies, (6) other agencies or offices, (7) a central point of contact in the organization.
3.9 Requirements for the format of report
The requirements for the format of report vary amongst the examined schemes. Below, a list of the requirements used in the examined schemes is provided. These requirements can be separated in three groups, namely, (1) contact information about the reporting entity, (2) information about the incident and (3) actions taken after the incident.
Contact information about the reporting entity
When contact information needs to be reported, it may include a contact name, phone number, e-mail address, and other information about the reporting entity,
Information about the incident
When information about the incident needs to be reported, it may include information about: (1) the nature of the incident, (2) URL(s) related to the incident, (3) a timestamp of when the report about the incident was received, (4) whether customer data may have been compromised.
Actions taken after the incident
In some of the examined schemes, actions taken after the incident need also to be reported. Information about actions taken after the incident may include: (1) actions already taken or intended to mitigate or resolve the issue, (2) actions taken to eliminate the vulnerability, (3) the expected schedule for response, assuming it can be predicted.
3.10 Timing requirements
While some schemes only say that the reporting entity needs to report “without delay” or “timely”, other schemes give more detailed timing requirements. For instance, Network Outage reporting system states that the basic notification should be sent within 120 Minutes, the Initial Communications Outage Report should be sent within 72 hours, and the Final Communications Outage Report should be sent within 30 days. The document containing the Best Practices for Web Hosting Providers published by StopBadware states that reports should be passed on to downstream providers or site owners, as appropriate, in a timely manner, but no later than two business days following receipt of a report.
3.11 Reporting channel
Some schemes use web-based filing systems created specially for them. Other schemes do not specify the type of reporting channel. A third group of schemes only give examples of notification methods. For example, the reporting scheme set out in Internet Service Provider (ISP) Network Protection Practices written by the Computer Security, Reliability and Interoperability Council (CSRIC) of the US Federal Communications Commission states that the notification can be made through email, telephone call, postal mail, instant messaging (IM), short messaging service (SMS), and web browser notification.
It should be noted that the reporting scheme set out in IETF Recommended Internet Service Provider Security Services and Procedures 2000 notes that, for the purpose of reporting security-related incidents it is reasonable for ISP to use their already established procedures for notifying customers of outages and service degradation.
3.12 Confidentiality of the information submitted in the report
Most of the examined procedures do not state that the information submitted in the report will be kept confidential. However, there are three exceptions, namely, NORS, DIRS, and the Best Practices for Web Hosting Providers published by StopBadware. NORS and DIRS state that the outage data submitted by the reporting entity is presumed confidential. The Best Practices for Web Hosting Providers published by StopBadware state that when reports are passed on by a provider, the provider should not reveal the identity of a reporter unless the reporter explicitly requests so.
3.13 Follow-up procedures
The follow-up procedures that need to be taken after the incident may include measures to prevent the reoccurrence of such incidents. For instance, the Best Practices for Web Hosting Providers published by StopBadware, state that a provider engaging in mitigation after evaluating a badware report should take steps to prevent the reported badware from affecting Internet users or other systems.
3.14 Coordination and information distribution
Only one of the examined schemes, DIRS, elaborates on the coordination and information distribution between the entities that receive reports. DIRS states that, to improve the utility of DIRS and facilitate Federal restoration efforts, the FCC will disseminate DIRS information to other Federal agencies that are authorized participants on the Emergency Support Function-2 (ESF-2) team. Also, when DIRS is activated, the FCC sends an email to service providers, DIRS coordinators, and inputters notifying them of the activation.
3.15 Ex-post analysis of individual incidents
Two of the examined schemes, namely, the Best Practices for Web Hosting Providers published by StopBadware and NORS, deal with the issue of ex-post analysis of individual incidents. The Best Practices for Web Hosting Providers published by StopBadware state that providers should periodically review previously tracked reports because this will provide an opportunity to identify patterns of infection and operational lessons that may not be obvious in the midst of addressing individual issues.The website of the Network Outage Reporting System states that the Communications Systems Analysis Division of the FCC’s Public Safety and Homeland Security Bureau administers NORS, monitors the outage reports submitted through NORS, and performs analyses and studies of the communications disruptions reported.
4. Conclusion
This document identified and analyzed ten examples of practices of reporting information security incidents. On the basis of the analysis, it can be concluded that, because of the differences in the examined schemes, a summary of these schemes providing an overview of the different parts of the reporting procedures can be very helpful when designing new reporting procedures.
***
I wrote this report during my traineeship at the European Commission. It was included in the Staff Working Paper that has been produced in preparation of the European Strategy for Internet Security.
Photo: R/DV/RS, http://www.flickr.com/photos/redvers/2453082354/sizes/m/in/photostream/