Creation of instances of the Generic Security Template

3.3 The Generic Security Template

3.3.3 Creation of instances of the Generic Security Template

recommendations derived from security incidents and the guidelines/policies/standards that are intended to prevent any recurrence of a data breach. We use the US Veterans

3.3. THE GENERIC SECURITY TEMPLATE 42

AC: User access control is addressed.

Healthcare System (HS) is acceptably Secure. SM: Security management is controlled. SM 1: Security management program is established. Position Description: Re-evaluate and correct position sensitivity levels. Risk Analysis: Develop and issue Government-wide risk analysis criteria.

SM1.2: A security management structure has been established. Management Structure: Establish an accurate functional description and performance plan to clarify the line authority and reporting relationship.

SM 3: Security control policies and procedures are documented and implemented. SM3.1: Security control policies and procedures are documented, approved by management and implemented.

AC3: Effective authorisation controls are implemented. AC3.1: User accounts are appropriately controlled. Access Control: Avoid the abuse of programmer level access control.

AC4: Sensitive system resources are adequately protected. AC4.1: Access to sensitive system resources is restricted and monitored. Sensitive Information: se encryption, or other effective tool, to protect personally identifiable information stored on removable storage.

Argument over FISCAM

Healthcare System of VA Federal Information Security Controls Audit Manual AC5: An effective audit and monitoring capabilities is implemented . AC 5.3. Incidents are properly analysed and appropriate actions taken. AC 5.3.3. Appropriate disciplinary actions are taken.

SM 3.1.1. Security control policies and procedures at all levels are are documented, address purpose, scope, roles, responsibilities, and compliance. Administrative Action: Take appropriate administrative action against the people involved in this incident for their inappropriate actions.

Security Policy: (1) Ensure that data security plans for research projects comply with information security policies; (2) Ensure human subjects in research, compliance with information security requirements; (3) Discontinue storing email on unauthorised system.

Argument over All Missing Security Recommendations. (Standard non-existent):

Figure 3.5: An example instance of the GST - VA 2007 Data Leakage Incident

3.3. THE GENERIC SECURITY TEMPLATE 43

Affairs (VA) Data Leakage Incident 2007 to illustrate the creation steps. Figure 3.5 presents the diagram created for this real world case study. As is mentioned, it is based on a report into the disclosure of personal information about veterans and over medical providers by the US Veterans Affairs Administration (VA) [15]. Below are the four steps to create a GST instance.

3.3.3.1 Step 1: Prepare the goal structure

The top level goal is to ensure that a healthcare system is acceptably secure. We used the word ”acceptably” as absolute security is unachievable. Within the GST, the se- curity argument is there to convince someone that the system is secure enough when compared against a specific security standard applied by the organisation. This high- level goal is then decomposed into sub-goals that each reflects more detailed security requirements within a security management system. The goal structure decomposi- tion continues in this way until it reaches the level that can be directly supported by appealing to the recommendations identified in an incident report.

In our approach, we have simplified the process of identifying sub-goals by us- ing security requirements within the applicable standards and guidelines in particular healthcare organisations. This helps to increase the genericity of our approach. The goal structured is pre-created to help the users get started. For example, in the case study of the VA 2007 Data Leakage Incident, we have used security requirements of the general controls (i.e. security management, access controls, configuration manage- ment, segregation of duties and contingency planning) in Federal Information Security Control Audit Manual (FISCAM). As is introduced in Chapter 2, FISCAM includes general controls categories such as security management, access controls, configura- tion management, segregation of duties and contingency planning. For each of those general control areas, it identifies several critical elements that are essential security requirements for establishing adequate security controls.

In this step, we borrowed the experience of conformance argument in safety area, where the goal structure has been used to represent safety standards. Instead of arguing how evidence supports a system requirement in system safety, a conformance argument justifies belief in conformance. The decomposition of sub-goals is over the safety standard’s requirements.

3.3. THE GENERIC SECURITY TEMPLATE 44

3.3.3.2 Step 2: Identify the lessons learned from the security incident

Lessons learned are identified by searching incident reports for security issues and rec- ommendations. A review of the existing incident reports [14–16, 44] show that the security analysts are able to describe learning points using structured text. However, there has not been a unified definition on an appropriate level of details that a lesson learned should contain. The security analysts define their own level of details in the security incident report according to individual business needs. However, too much information will undermine the effectiveness of the graphical presentation, while too little information will make it difficult to understand. In this step, the analyst has to identify key learning points. These are then introduced into the Generic Security Tem- plate using a structured textual format. For the security issue, we recommend to use short<Noun-Phrase>, for example, “Sensitive Information”, as a short description of a specific security issue. For the recommendation, we recommend the statement to be in the form of<Verb-Phrase> <Noun-Phrase>. For example, “Use encryption or effec- tive tool to protect personally identifiable information”. This is different from Kelly’s work in using the<Noun-Phrase>as evidence/solution such as “test result” to support the truth of the goals. The security issue and its corresponding recommendation will become theLessons learnedpart of the Generic Security Template.

3.3.3.3 Step 3: Map the Lessons learned to the Goal Structure

The lessons identified in Step 2, typically contain different levels of details, can be mapped to different levels of the goal structure. This has achieved by using the bottom up approach and the analyst has to identify the relationships between security sub- goals, based on standards, guidelines and policies, and the lessons learned from a previous security incident. For example, as is shown in Figure 3.5, the lessons learned

“Access Control: Avoid the abuse of programmer level access control”, was found to be related and mapped to the goal “AC 3.1 User accounts are appropriately controlled”.

There are the cases when the lessons learned could not find a goal to map to. For example, as is shown in Figure 3.5, the lessons learned “Position Description: Re- evaluate and correct position sensitivity levels” and “Risk Analysis: Develop and is- sue Government-wide risk analysis criteria”, could not find goals to map to. These lessons learned are mapped to a newly created goal named “Standard non-existent”

and directly link to the top goal. This probably because the existing goals, based on standards, guidelines or policies have missing requirements that are not covered those

3.3. THE GENERIC SECURITY TEMPLATE 45

learning points. This may also due to the unsuitability to add those lessons into security standards, guidelines or policies. For example, some recommendations may refer to the process for managing a system, or the meta process of reporting incidents across or- ganisations. However, these newly identified lessons need further assessment in terms of whether they are suitable to be included in the existing security standards/guidelines.

A key benefit of our approach is that their subjective reasoning is documented in the nodes of the Generic Security Template. A range of stakeholders can then check the resulting diagrams to determine when key lessons have been omitted or if addi- tional work is required to support the exchange of security lessons. They could check the reasoning and experience can be borrowed from safety area on how to avoid and detecting fallacious reasoning in the arguments [166]. The use of a graphical nota- tion provides stakeholders with an overview of key issues before being forced to read the hundreds of pages of detailed prose that increasingly documents the findings of security investigations.

3.3.3.4 Step 4: Elaborate the Context and Strategy

Strategies are inserted between goals and sub-goals; they justify goal decomposition.

They typically refer to the goal decomposition methods, such as the use of security standards, organisational guidelines or technical documentation. As before, we have exploited a simplified sentence structure that is intended to improve the clarity of the diagram as used in the safety arguments [7]; “argument by <approach>”, “argument over <approach>”, “argument using <approach>”, “argument of <approach>”. For example, “Argument over FISCAM”.

Recall step 3, there are some lessons learned that are not covered by the existing goal structure, they are mapped to a newly create goal named “Standard non-existent”.

A new strategy named “Argument over all Missing Security Requirements” is created and inserted between the top goal and the goal “standard-do-not-exist” to present such argument.

The context notations need to be elaborated during this process by providing sup- plementary information for a specific incident such as in Figure 3.5, “Federal Informa- tion Security Controls Audit Manual”, this context information is used to explain the concept “FISCAM” in the strategy.

3.4. THE GENERIC SECURITY TEMPLATE PATTERN 46