A Methodology of Health Information Security Evaluation

• Abstract
• Introduction
• Objectives and Aims
• Case Study Description
• Overview
• Step 1: Scenario Construction and Modelling
• Step 2: Health Information Security Analysis
• Step 3: Comparison of the Current and Ideal Security
• Step 4: Post-Implementation Analysis
• Evaluating the Case Study
• Conclusion
• References

Abstract
With the conversion of paper health records to electronic health records, the health care sector is increasingly relying on technology to maintain the integrity of and update patients’ data. This reliance on technology requires an acute level of protection from technological disasters and/or threats of human error or sabotage. Research has shown there are inadequacies in the installation and use of security controls for health information records and that current methods of security analysis lack the techniques to analyse the technical and social aspects of security. This paper reports on progress towards development of a health information security evaluation methodology based on Unified Modelling Language techniques, and discusses an imminent case study that will be used for validation of the methodology.

Introduction
The 2006 Australian Computer Crime and Security Survey, performed by AusCERT,^[1] asked 389 respondents a series of questions on computer network attack, crime and computer misuse trends in Australia over the last 12 months. The medical health sector represented 6% of respondents, ie, approximately 23 organisations. The survey found a reduction in the reported use of security technologies, security policies and procedures, information technology (IT) security standards and IT qualifications and training compared to 2004 and 2005. Further, only 10% of all survey respondents thought they were managing all aspects of computer security reasonably well, which is a small improvement compared to 2005 (7%) and 2004 (5%). About one in five respondents experienced electronic attacks that harmed the confidentiality, integrity or availability of network data or systems in the last 12 months. These results are evidence that information security, or lack thereof, is an important issue when considering the protection of an organisation’s confidential data, including customer records, and system integrity.

Von Solms^[2] discovered that the need for information security in health care is much more acute in comparison to other sectors like financial, military and government. For example, a Health and Human Services Agency in California^[3] reported that an external hacker attack breached about 1.4 million computer records for the In-Home Supportive Services program in a University of California-Berkley database. The exposed records listed names, addresses, telephone numbers, birthdates and social security numbers of IHSS participants; which would be enough sensitive personal information for a criminal to commit identity fraud.

The results from other surveys (examples like ^{[4, 5, 6]}), provide enough evidence to suggest that the general management and implementation of information security controls is significantly deficient in numerous public and private sectors, including health care. Therefore, security controls need not only be implemented but the organisation should evaluate the controls once in place in order to verify that their system is secure. Numerous information systems security design methods have been developed to analyse and design security controls to map a solution onto the information problem of the system being assessed.^[7] These methods generally focus on the technology of information systems and, thus, propose technical solutions. While this is a necessary consideration, it is not the only element requiring recognition; organisational concerns, human factors, and social considerations also directly and indirectly affect the security management function.^{[8, 9]} Security in health care is seen as a people problem and users remain its greatest threat.^[10] This threat, therefore, emphasises the need for an information systems’ security design method that effectively models and evaluates both the technical and social aspects of information security in a health care environment.

In a paper presented by the authors in 2004,^[11] the conceptual development of a health information security evaluation method was discussed. This evaluation method was intended to: improve the analysis of security countermeasures for the protection of health information data; assist in establishing the appropriate level of security within organisations; and assist organisations in fulfilling the criteria for certification according to a recognised health information security management standard. Since 2004, the evaluation method theory has been refined and the author can now undertake a case study in a real life environment. This paper discusses the steps the case study will require and the techniques that will be used to assess the evaluation method.

Objectives and Aims
Conducting a health information security evaluation allows a health organisation to obtain a realistic measure of how secure its information resources are. The evaluation method under discussion provides a baseline and comparative set of criteria against which appropriate countermeasures to security risks or weaknesses, and the success of their implementation, can be gauged. It will assist with:

• Identifying security weaknesses, possible threats and attacks
• Increasing organisational awareness of security issues
• Improving the security of information systems
• Reducing the costs of and the level of complexity required to perform an information security evaluation
• Providing evaluation results that non-IT professionals can understand
• Assisting health care organisations towards fulfilling the criteria for certification according to a recognised health information security management standard.

From a research point of view, the stimulus for now carrying out the proposed case study includes, but is not limited to, evaluating:

• The usability of the evaluation method by all participants, ie, management, IT professionals, and non-IT professionals involved. 
• The efficiency of the method.
• The intelligibility of the processes involved and the outputs produced.
• The effectiveness of the results.
• The integrity of the method’s design.

A case study validating the evaluation research method will be undertaken, testing the method within a large health care establishment in the state of Victoria, Australia.

Case Study Description
The case study will enable an in-depth, longitudinal examination of the evaluation method in a health organisational framework within a well-defined environment. It will provide a systematic way of collecting data, analysing information, and reporting the results. The case study approach will also allow a real-life validation of the research solution.

Overview
The evaluation method being tested comprises four basic processes:

1. Scenario construction and modelling
2. Health information security analysis
3. Comparison of the current security measures and the ideal security system
4. Post-implementation analysis.
   
   
   Figure 1: Workflow processes for the evaluation method

For the case study, the "Researcher" will be the primary author and the "Participant" will be a member of the organisation with moderate IT knowledge. This person will be selected by the IT Director of the organisation and the primary author.

Step 1: Scenario Construction and Modelling
To achieve an understanding of the current health data security system, the primary author (Warren Brooks) will collect information through interviews, document analysis and observation. Documents analysed will include material on the physical layout of the studied organisation’s building, computing system and any environmental and security features, such as fire detection and suppression devices. The results of these analyses will be used to construct diagrams to represent the physical and logical designs of the system. The majority of diagrams will be primarily prepared using Unified Modelling Language (UML) techniques because this provides an abstract method for modelling security and assessing risks/threats on an organisation’s computing system.

However, the physical design diagram(s), which will depict how various entities interact with the system, will not require UML techniques to express them. Each entity, such as the building layout and complexity of the system, will be represented by a graphic and a text description (see figure 2).

Figure 2: Example physical model artefact

The logical diagram(s) will represent the structure of the run-time system through the use of UML Deployment diagrams. The physical relationships among system software and hardware components will be portrayed via the use of UML Components and Nodes, respectively. UML Components are used to model a static view of software making up a system: files; executable programs; documents; program libraries; system security elements; and tables of data.^{[12, 13]} Nodes are the run-time physical objects that represent processing resources in a system, such as workstations and server machines, but can also represent human or mechanical-processing resources^{[14, 15]} (see figure 3).

Figure 3: Example logical model artefact

Human interaction (both physical and logical) with the system is illustrated with UML Use Case diagrams. Each user may have a different type of interaction with the system, which might be a basic course of events and/or, possibly, a number of alternative and/or exceptional courses of events.^[16] The basic course of events that take place to enable a user to login to the system and the system to authenticate that user are illustrated in figure 4. An alternative or exceptional course of events is required if the goal cannot be achieved by following the basic course of events. For example, if a user has forgotten their password and cannot login to the system, an alternative course of events could be to contact the systems administrator to obtain a new password.

Figure 4: Example use case diagram artefact

The diagrams will present non-IT professionals with an intelligible illustration of the organisation’s IT system, the surrounding environment, and supporting security features. The diagrams can be used to help identify security weaknesses and possible threats and attacks. In addition, results from the analysis performed by the participant (in step 2) will be included to provide a clearer and more complete description of each diagram. The researcher will obtain feedback from members of the organisation to ensure each diagram is accurate.

Step 2: Health Information Security Analysis
The participant will analyse the security countermeasures the organisation already has in place by means of a checklist. The checklist that will be used contains a set of information security categories based primarily on the Australian Standard "Information Security Management – Implementation Guide for the Health Sector".^[17] The checklist is divided into the nine key areas of information security controls:

1. Information Security Policy
2. Security Organisation
3. Asset Classification and Control
4. Personnel Security
5. Physical and Environmental Security
6. Communications and Operations Management
7. Access Control
8. Business Continuity Management
9. Compliance.

To complete the security assessment, the participant will compare the security controls already in place against the information security criteria, ie, defined in the checklist. If a countermeasure has been installed then a value of 1 will be given on the checklist and a value of 0 if it has not been installed (see table 1). The participant may need to examine the diagrams created in step 1 or consult the researcher if he/she has any doubts or questions concerning the security analysis.

Table 1: Key control 4 checklist

The rationale behind choosing a member of the organisation to perform the security analysis is to prohibit the fabrication, and publication, of any biased results for the case study and validation of research. That is, with two people performing the evaluation method, it will be impossible for either member to bias the evaluation because the results from Step 1 and Step 2 have to match.

Step 3: Comparison of the Current and Ideal Security
The researcher will then convert the results from the checklist assessment (which will give the existing security level) into a percentage figure and plot them onto a two-dimensional evaluation histogram, where the vertical axis defines the information security control key areas and the horizontal axis defines the percentage of ideal security (100 percent) achieved in each category. This will simplify management’s task in assessing their information security status by showing which countermeasures must be adopted to bring the information systems up to an acceptable security level. An example evaluation histogram is illustrated below.

Figure 5: Example showing results for each key control

These results, along with the diagrams, will be combined into an evaluation report which will discuss the overall security level of the organisation and highlight any weaknesses in the system discovered by the health information security analysis. The diagrams will provide the organisation with a pictographic showing all the physical and logical security measures that have been analysed, thereby, providing non-IT professionals with a clear picture of the results.

Step 4: Post-Implementation Analysis
The final step will be to improve the overall security level of the system by introducing new security features and analysing their probable effectiveness before implementation.

Misuse Case diagrams will be used to document negative scenarios that specify system preventions against misuser threats.^[18] In other words, each Use Case diagram (developed during step 1, the scenario construction and modelling phase) will be analysed to identify the weaknesses of, possible threats to or vulnerabilities to attack of the system and a misuse case will be written to describe each threat or possibility of attack. Taking the figure 4 use case diagram, for example, a hacker whose main goal was intruding into the information system would be introduced to the scenario. This main (hostile) goal would then be broken down into any number of sub-goals that the hacker might adopt in their attempt to gain unauthorised access to the system. The relationship between Use/Misuse Case goals and sub-goals is known as the threat–mitigation cycle and hostile goals are labelled as black misuse cases.^[19]

Figure 6: Example use/misuse case diagram

As can be seen in figure 6, the hacker could try to remotely attack unblocked ports to gain unauthorised access to the system. To prevent such an attack, the classic defence would be installing a firewall, which as we can see from the Use Case diagram (figure 4), is not currently installed or enabled. Using this process, security holes can be quickly identified and new security measures can be suggested to mitigate the threats to the system via these points of vulnerability.

The next phase is to have the security evaluation report reviewed by the organisation’s management and IT staff to identify weaknesses in the system’s current security system. New security features that would improve the current security level, can be achieved within budget, are compatible with the system and can be operated by IT personnel will then be identified. The researcher will repeat steps 1 to 3 to re-run the evaluation based on the suggested security features. The results from the new evaluation will be plotted against the original results to produce a comparative analysis (see figure 7). Note that in figure 7 the baseline security level for security responsibilities is not displayed because the current security level is already 100 percent and any changes to the system could not generate improvements in this area.

Figure 7: Baseline security values plotted against current security values

It is quite simple to suggest security features to mitigate the level of risk and threat in an information system security assessment scenario but they may not always be physically or logically possible to implement. By reconstructing the physical and logical models, management and IT personnel will have a visual analysis of the projected security level for the system, which will take into account physical and logical constraints. Once an attainable and acceptable level of security is identified through this evaluation process the new security features can be implemented.

Evaluating the Case Study
A variety of data capture techniques will be used to assess the case study and the results obtained from it. Both the researcher and participant will be given diary templates and they will be encouraged to use these to capture their thoughts, queries, and/or the issues that may arise during the case study. The participant will be interviewed by the researcher after step 2, to discuss the ease of use and effectiveness of the evaluation method as well as any noticeable strengths or weaknesses in it. The participant and other management and IT staff involved will be interviewed after they have read the findings report and asked for their views on the accuracy, effectiveness, intelligibility and simplicity of the report. They will also be asked to suggest any improvements to the report and whether specialised skill or knowledge was required to understand any part of the report or diagrams.

An independent, critical review of the checklist, diagrams, histograms and the findings report will be undertaken by an IT specialist who will assess their effectiveness and intelligibility. The independent reviewer will also be asked to suggest any possible improvements and highlight problems.

Conclusions
The process described above aims to validate the conceptual model in a real life health care setting. The primary author will be running a case study to test the model in a regional Australian hospital in Victoria, Australia. This hospital is the largest public hospital outside the Melbourne metropolitan area (Melbourne is the state capital city) and has 400 beds. It provides acute services in Cardiology, Cardiothoracic Surgery, Emergency Medicine, Medical and Radiation Oncology, Medicine, Surgery, Obstetrics and Gynaecology, Orthopaedics, Paediatrics, Plastic Surgery, Psychiatry, Urology and Renal Dialysis as well as Coronary Care and Intensive Care Units. The hospital will provide a rich environment in which to test the model.

As stated before, security in the health sector is seen as a people problem. To test this perception, the primary author has, using UML techniques, developed an information security modelling concept that allows for technical and non-technical aspects of information security to be mapped to the system and evaluated accordingly.

References

1. AusCERT, Australian High Tech Crime Centre, the Australian Federal Police, New South Wales Police, Northern Territory Police, Queensland Police, South Australia Police, Tasmania Police, Victoria Police and Western Australia Police. 2006 Australian Computer Crime and Security Survey. http://www.auscert.org.au/images/ACCSS2006.pdf. Accessed: 15 July 2006.
2. Von Solms SH. Information Security in Medical Informatics, 2nd International Working Conference on Health Informatics Proceedings, 1996, South Africa.
3. California Healthline. About 1.4 Million Computer Records for In-Home Supportive Service Breached, California Healthcare Foundation, October 2004.
4. http://www.californiahealthline.org/index.cfm?Action=dspItem&itemID=106520. Accessed: 18 July 2006. PriceWaterhouseCoopers, Microsoft, ClearSwift, Entrust, Symantec. Information Security Breaches Survey 2006, Department of Trade and Industry, April 2006. http://www.pwc.com/uk/eng/ins-sol/publ/pwc_dti-fullsurveyresults06.pdf. Accessed: 14 June 2006.
5. Tucker T. 2002 Security Awareness Index Report: The State of Security Awareness among Organisations Worldwide, Pentasafe Security Technologies, 2002. http://security.ittoolbox.com/pub/AM101502a.pdf. Accessed: 10 Dec 2005.
6. Brooks W, Warren M, Hutchinson W. Information Security Management within Australian Healthcare Organisations, ISOneWorld Conference Proceedings, The Information Institute, 2003, Las Vegas USA.
7. Baskerville R. Information Systems Security Design Methods: Implications for Information Systems Development, School of Management, Binghamton University, New York. ACM Computing Surveys, 1993; 25(4).
8. Baskerville R. Designing Information Systems Security, John Wiley & Sons, 1988, Chichester, UK.
9. Yngstrom L. & Bjorck F. The Value of Assessment of Information Security Education and Training, in Yngstrom and Fischer-Hubner (Eds), WISE 1 – Proceedings of the IFIP TC11 WG11.8 First World Conference on Information Security Education, Stockholm University, Sweden, 1999: 271-292.
10. Armstrong H. L. A Soft Approach to Management of Information Security, PhD Thesis. School of Public Health, Curtin University of Technology, 1999, Australia.
11. Brooks W, Warren M. Health Information security evaluation: continued development of an object-oriented method, 2nd Australian Information Security Management Conference Proceedings, Edith Cowan University, 2004, Perth, Western Australia.
12. Bennett S, Skelton J, Lunn K. UML. Schaum’s Outline Series. UK: McGraw-Hill; 2001.
13. Fowler M, Scott K. UML Distilled: a brief guide to the standard object modelling language. 2d ed. US: Addison Wesley Longman; 2000.
14. Microsoft. Microsoft Office Visio Professional 2003. Program help file.
15. Sparks G. An introduction to UML: the component model. Sparx Systems, Australia. http://www.sparxsystems.com.au. Accessed: 8 April 2006.
16. McGraw-Hill. Practical object-oriented design with UML. Int ed. UK: McGraw-Hill Book Company International; 2000:41.
17. Standards Australia. Information security management – implementation guide for the health sector, HB 174-2003. Australia: Standards Australia International Ltd; 2003.
18. Alexander I. Misuse Cases, Use cases with Hostile Intent. OU Research Group, May 2002. IEEE Software Jan/Feb 2003; 20(1):58–66.
19. Sindre G, Opdahl AL. Eliciting security requirements by misuse cases. Proc TOOLS Pacific 20–23 November 2000: 120–31.