Reporting of ICT Incidents to the Financial Supervisory Authority

Circular/Guidance

Sent to:

Commercial Banks Savings Banks Financing Companies Insurance Companies E-money Institutions Securities Firms Asset Management Companies for Securities Funds Regulated Markets, including Exchanges Clearing Houses Securities Registers BBS AS

The Regulation on the Use of Information and Communication Technology (ICT Regulation) § 9, third paragraph, has been amended. The new third paragraph reads as follows:

"Incidents that result in a significant reduction in functionality due to breaches of confidentiality (protection of data), integrity (protection against unauthorized changes), or availability of ICT systems and/or data shall be reported to the Financial Supervisory Authority. The reporting shall normally include incidents that the institution itself categorizes as severity very serious or critical, but may also include other incidents if these reveal special vulnerabilities in applications, architecture, infrastructure, or defenses. Institutions referred to in § 1, first paragraph, no. 5 (Private, municipal, and county pension funds and pension schemes), no. 11 (Debt collection agencies), and no. 12 (Real estate agencies) are not subject to the incident reporting requirement."

The current third paragraph of § 9 becomes the new fourth paragraph. The amendment enters into force on 1 December 2009.

This circular describes in more detail the procedures for incident reporting to be used. The circular replaces Circular 31/2007.

1. Background

It is important to ensure that deviations in the ICT operations of individual institutions are handled quickly and according to a defined procedure so that the normal situation is restored and measures are implemented to prevent the same type of incident from occurring again. It is also important to ensure that information about incidents and deviations that may have significance for the entire or part of the financial sector is registered and followed up. The Financial Supervisory Authority considers such reporting to be fundamental for ensuring information and overview in an area of significant importance for the stability of the financial market. Correct handling of ICT deviations should contribute to good risk management and ensure that payments and settlements are carried out correctly and efficiently. Critical situations must be handled with minimal adverse effects.

Incident reporting helps to ensure a correct and timely picture of the risk level in the financial sector and to uncover patterns and relationships that may be difficult for an individual institution to see. However, the most important aspect is the individual institution's handling of incidents to ensure restoration and follow-up with relevant preventive measures. Incident reporting provides the basis for risk analyses and the opportunity to implement preventive measures at an early stage. Furthermore, incident reporting to the Financial Supervisory Authority can function as a common information center if many financial institutions are affected by an incident simultaneously.

On this basis, it has been decided that incident reporting will continue through regulation in the ICT Regulation. The scope of incident reporting has been expanded to apply to all institutions covered by the ICT Regulation, with the exception of private, municipal, and county pension funds and pension schemes, debt collection agencies, and real estate agencies.

Many of the institutions covered by the ICT Regulation are also subject to the Basel II regulatory framework for operational risk. Through this framework, they are required to establish a system for handling incidents and storing incident history for five years back in time. This applies to institutions that have chosen the AMA (Advanced Measurement Approach) or TSA (The Standardized Approach, also known as "sjablongmetoden" in Norwegian) methods for assessing operational risk. The incident reporting system is adapted to the requirements in Basel II so that there are no overlapping requirements and the same data basis can be used.

Payment intermediation constitutes a significant part of banks' operations. In the Act on Payment Systems etc., § 3-3 General System Requirements, the Financial Supervisory Authority has been given a responsibility that makes it desirable to be informed about deviations in the operation of payment service systems as part of the Authority's work in this area.

2. Incidents to be Reported

Incidents that result in a significant reduction in functionality due to breaches of confidentiality (protection of data), integrity (protection against unauthorized changes), or availability of ICT systems and/or data shall be reported to the Financial Supervisory Authority.

The incidents may be caused by failures in central infrastructure such as power or telecommunications, errors in networks, errors in system software, errors in applications, or ICT-based malicious attacks.

The report shall normally include incidents that the institution itself categorizes as severity very serious or critical, but may also include other incidents if these reveal special vulnerabilities in applications, architecture, infrastructure, or defenses.

Below are listed some examples of incidents that should be reported. The list is not exhaustive. The examples are intended as a tool to make it easier to assess whether an incident qualifies for reporting or not.

Relevant examples for banks/BBS:

a) Customers report lack of availability to the online bank. The bank has made changes to the online bank application, and the changes may have caused an error that was not detected during testing.

b) Many customers cannot pay with debit cards in stores. Some point-of-sale terminals have functionality to serve customers offline, but this does not apply to all. The cause turns out to be lack of access to balance checks due to a problem with a central operational component.

c) Customers report to the bank that they have access to view other customers' accounts in the online bank. The bank has made changes to the online bank application, and it turns out that the changes have caused an error that was not detected during testing.

d) A common supplier of network infrastructure to banks makes changes to the software configuration that result in a weakness causing frequent recurring problems with operational stability.

e) The bank receives messages from customers who have discovered that unauthorized transactions have been made from their accounts at the bank. This reveals a new attack of malicious code against the bank's online bank customers.

f) The bank has switched operational suppliers, and in the first weeks the bank runs on the new operational platform, the bank experiences greater problems with fixed operational runs.

g) The bank is hit by a virus attack that spreads to large parts of the bank's workstations, both at the head office and branches. Bank employees lose access to their workstations and cannot perform normal work tasks.

h) Several customers report to the bank about changes to their account balances that they do not recognize. The bank finds unauthorized updates in the database but has not yet identified the source of these. There are signals suggesting that a former employee may have compromised the data.

i) The online bank is subjected to massive simultaneous logins so that the server cannot handle the requests. The server is taken down and restarted with special monitoring. The bank assumes it is a so-called Denial of Service (DoS) attack. The online bank is down for a total of 3 hours and 40 minutes.

j) Power outage at the operational supplier and failure of the UPS solution at the operational supplier result in lack of access to the bank's core systems for a period of 4 hours and 15 minutes.

Relevant examples for other institutions

k) VPS has technical problems that cause securities settlements to be significantly delayed.

l) Several members of the Oslo Stock Exchange report unstable access to the trading system with periodic complete lack of availability. The problem persists for more than two hours.

m) In a securities firm, the access control system lacked sufficient separation of access rights for user groups. An employee exploited the hole in the system to acquire information and make trades they are not authorized for.

n) In an insurance company, an application change caused an error in the rights calculation program. The error was only discovered after letters had been sent to customers.

o) Due to operational problems, the monthly run for pension payments in the insurance company failed, and the payments are delayed by one week.

p) A card company has technical problems in the control center. Authorization requests are rejected, and customers cannot use international payment cards for e-commerce, at hotels, or at other point-of-sale terminals.

3. Time of Reporting

The incident is reported to the Financial Supervisory Authority without unjustified delay.

4. Form of Reporting

The institution reports the incident to the Financial Supervisory Authority via email to: hendelse@finanstilsynet.no . Alternatively, one can report by letter or telephone to the case handler in the IT Supervision section of the Financial Supervisory Authority, see telephone list below.

Incidents that banks report to NICS' operator office and that also fall within the scope of this circular are sent with a copy to: hendelse@finanstilsynet.no .

If the same incident affects several banks that cooperate, the banks can report with one joint message to the Financial Supervisory Authority.

Protection of Confidential Information

If the institution considers incident information to be sensitive, the institution can choose one of these alternatives to ensure confidential handling of the data:

The Financial Supervisory Authority's system for exchanging encrypted email

ordinary email where the incident report is attached as an encrypted and password-protected Word document (password exchanged with the Financial Supervisory Authority by telephone)

telephone

ordinary post

If the incident report contains personal data, these must be masked in accordance with requirements in the Personal Data Act.

5. Content of the Report to the Financial Supervisory Authority

It is important that reporting takes place quickly, and it may therefore be appropriate to notify about an incident before there is full overview of the cause and consequences. It will then be appropriate to send a final report on cause and measures later. The Financial Supervisory Authority may, based on the reporting, request further information or establish direct contact with the institution.

Generally, the reporting should contain the following information about the incident:

time when the incident occurred time when the incident was discovered contact information description of the incident with which systems and/or data are affected preliminary consequences of the incident cause of the incident as far as this has been mapped out time for restoration of normal operations or estimate for this measures for restoration measures to prevent recurrence or when and how this is planned

The institution can use a copy of the institution's internal form for deviation registration if this covers the information specified above.

Anne Merethe Bellamy

Frank Robert Berg