El problema de la generación de conjuntos de ítems frecuentes

The map of risk scenario forecasts (described in section 6.3 of this thesis) was compared with the case organisation’s incident registers of 2011 and 2012. The aim was to test the hypothesis that:

The frequency of occurrence of the incident scenarios in the case organisation falls within the same range of expected frequencies generated by the HI-risk method.

The positions of the scenarios on the risk map study were compared with the positions of the scenarios from the case organisation. The results are presented on the risk map in Figure 7-5. The scenarios from the case organisation are presented by a square and the original forecasts are shown in circles. The numbers in the circles/squares refer back to the numbers of the scenarios listed in section 6.3. It is visible that there occurs some overlap and some differences.

Not all scenarios from the map occurred in the case organisation. Only scenarios 1 to 6 and 16 (as listed in section 6.3.3) could be compared. The scenarios 5, 6, and 16 are positioned in the expected range. It is clear that scenarios 2, 3 and 4 happened more frequently than expected and scenario 1 occurred less frequently. Scenario 4 and 16 had a lower number of records affected, but this is explained by the fact that the case organisation did not register the damage and therefore all incidents fell in the ‘0-9 records affected’ category. The differences of the scenarios 1 to 4 are discussed in the next sections.

Figure 7-5 Case organisation’s incident scenarios positioned on risk map

7.3.2.1 Discussion of scenario 1 and 4

The scenario where unattended assets go missing (scenario 1) occurred less frequently than expected in the case organisation, while scenario 4 (theft of assets) occurred more frequently. The case organisation made a distinction in their incident register between burglary from the premises and missing assets and that made it clear to make the distinction between these scenarios. This is also shown in the organisation’s data breach policy, the policy in which it is explained to staff what to do in case of an incident, as it mentions the loss or theft of data as one type of incident that needs to be reported:

The loss or theft of personal identifiable data, whether held on paper or electronic form must immediately be reported to your Line Manager/Director

and notified to the Information Governance Department […] in the first instance (p.5 section 4).

However, in an earlier stage of the research, the expert panel pointed out that it is often difficult to identify a missing asset as stolen or being lost. They stated that in many organisations these incidents are being treated as one scenario. For that reason, it could be that the database of past incidents is somewhat ‘soiled’ because the data that was put in was not always completely certain if an asset was simply mislaid or stolen from the premises. That could be an explanation for the ‘gone missing’ category having somewhat higher frequencies than it should have as it includes unclear cases as well.

To rule out this distortion, a recalculation was done by treating scenario 1 and 4 as one scenario. After combining the two possible scenarios into one, the combined scenario (assets going missing or being stolen from premises) from the database would be placed in the ‘very frequently’ grid (18% of all incidents). A similar result would happen for the case organisation, as the combination of the scenarios places it in the ‘very frequently’ grid as well (15%). In Figure 7-5 this combined scenario is indicated with blue figures with the number 1 / 4.

7.3.2.2 Discussion of scenario 2

Scenario 2 (password, user ID or access token sharing) happened more frequently in the case organisation. The organisation is aware of that risk and it is being reported frequently to the IT service desk. From the interviews, it was learned that a possible explanation of this higher occurrence could be the recent history of merging 9 organisations together, leading to the current situation where the IT systems are not yet fully integrated and subject to migrations and changes:

We are a conglomerate of 9 organisations. Each organisation had its own IT people and policies and procedures. We are still trying to integrate different areas. Our organisation is so big and some controls are fundamentally missing.

We have no HR system; we don’t know who is who. That is why we have no single-sign on. Once our systems are better we will be able to know our organisation better, and then we will be able to understand our risks better. In healthcare we need access to many more different systems than in other types of organisations and users find it difficult to remember all the different passwords (IT Security Manager in interview).

The higher frequency of occurrence of scenario 2 in the case organisation is explainable due to temporary circumstances after organisational changes. It is expected that the scenario will occur less in the future, when all changes stabilise. For future estimations, it remains important for the expert panel to be knowledgeable of changes in the

healthcare system and of any foreseen mergers of health boards. Plans for large scale changes influence scenarios like these, and should affect the experts’ estimated frequency.

Within the SLT department, this scenario was also recognised. There had been some password sharing in the past:

There has been some password sharing at times in the past, but not to access patient information. It was to access our stats. But I am aware that there is a risk if you have a culture of password sharing (Interviewee 1).

The department is also aware that the risk remains high in the near future:

We are moving very soon to an electronic case note record. Some principles about security will still maintain but they will be interpreted differently within an electronic record than they would be with a paper record. That will be a big change for our security management. There will be a different emphasis; we will look at logging off and passwords instead of locking case notes at night (Interviewee 2).

This scenario is likely to be temporarily regarded as a higher risk in the case organisation than was forecasted by the HI-risk method, and it is expected to lower once the new organisation has settled down.

7.3.2.3 Discussion scenario 3

Scenario 3 (email to unauthorised recipient) occurred more frequently in the case organisation. Staff report system or user errors to the service desk by email. In the email they explain that there is a problem with a record of a patient and they include the name, number and sometimes diagnoses in the email. The organisation is aware of that scenario and the service desk staff register these as events as security incidents. The IT security manager always talks to the staff involved, with the aim of educating them and to prevent it from happening again. The high frequency in this case is very likely caused by concise registration and high awareness of this specific event.

One of the most frustrating things that keeps happening is that our Service Desk is an external company. When something is faulty with a record, staff is not allowed to share this information with the Service Desk, but they do. The Information Commissioner has said we can’t do it, the Caldicott Guardian has said we can’t do it and they still do it (IT Security Manager).

Scenario 3 includes all situations where confidential information is sent to persons who are not authorised to receive that information. The scenario in the case organisation, where the email was sent to a specific unauthorised group of people (the IT service desk) also occurred in the database of security incidents from the NHS organisations (as

discussed in section 6.2 of this thesis). This led to the conclusion that scenario 3 could be split into two scenarios:

1. Email containing confidential or personal identifying data sent to IT service desk (scenario 20).

2. Email containing confidential or personal identifying data sent to other unauthorised recipients (scenario 3).

After this correction, scenario 3 fell in a closer range to the expected frequency. The new scenario, numbered as 20, is a security risks scenario that could provide interesting feedback to other organisations. The fact that the case organisation registers these scenarios separately might trigger other organisations to evaluate the situation at their IT service desk, and to analyse if they experience identical breaches of the Data Protection Act but just have not realised that yet.