3.3.4 Pre-requisites to apply the Generic Security Template
The target users of the Generic Security Template will be the people responsible for protecting customers’ personal private information within an organisation. For ex- ample, in healthcare organisations, both healthcare professionals and IT professionals have the responsibility to protect patients’ private information. However, the appli- cation of the Generic Security Template resides on the expertise of the organisation’s incident handling capacity. Organisations have to satisfy the following pre-requisites to apply the Generic Security Template,
• Expertise of information security. The organisation should have an incident han- dling team [35, 53] consists of security analysts with incident handling expertise.
They should be able to analyse an incident and justify actions taken to address an incident.
• Incident reporting with useful recommendations. The organisation should have incident reporting [35, 167] mechanism allowing for useful security lesson learned in different forms (e.g. technical notes, security incident reports, etc.) generated from the incident handling process.
• Security requirements elicitation. The organisation should have security require- ments elicited [100] based on existing security standards, guidelines or proce- dures.
3.4 The Generic Security Template Pattern
3.4.1 GSN Pattern
It is important to recognise that our development of Generic Security Templates is, in part, motivated by previous work into design patterns. Alexander [159] describes how patterns “describe a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice”. The field of design patterns has become well established since the publication of the book “De- sign Patterns - Elements of Reusable Object-Orientated Software” [168] by Gamma, Helm, Johnson and Vlissides (the “Gang of Four”). Kelly adapted the concept of pat- terns to GSN safety arguments “A means of documenting and reusing successful safety
3.4. THE GENERIC SECURITY TEMPLATE PATTERN 47
argument structures” [7]. An interview study with 29 interviews including develop- ers, consultants, managers, and assessors shows that patterns provide a good starting point for safety argument construction and has estimated that the long-term benefits of pattern-based safety case development more than outweigh the (initial) costs [169].
Table 3.1 lists the symbols used to support the pattern design, which is an extension of GSN. Those are the Multiplicity Extensions and Entity Abstractions [7]. Explanation of the symbols are provided in Table 3.1.
Type Notations Notation Description Multiplicity
Extensions
A solid ball is the symbol for many (meaning zero or more).
The label next to the ball indicates the cardinality of the relationship
A line without multiplicity symbols indicates a one to one relationship (as in conventional GSN)
Entity Abstractions
Uninstantiated Entity. This placeholder denotes that the attached entity remains to be instantiated i.e. at some later stage the ‘abstract’ entity needs to be replaced (instantiated) with a more concrete instance.
n
Table 3.1: Extension of GSN Pattern Design Notations [7]
3.4.2 The Generic Security Template Pattern
Based on the steps in section 3.3.3, the Generic Security Template Pattern is created as shown in Figure 3.6. Whereas Figure 3.5 presents an instance of a Generic Security Template, Figure 3.6 provides a more generic overview which abstracts away from the specifics of the VA case study to provide the general structure of our analysis. It is not intended that this diagram will be visible to the end users of an incident report but that it provides a template for the security professionals and risk managers who coordinate the creation of a specific security template after each incident.
Within the pattern, G1 is the top level goal claiming that “System X is secure”
within the context of C1 “ISMS for System X”. It is then divided into sub-level goals using the strategies that “argument over Security Standard X” and that “argument over Missing Requirements”. Within Strategy S1, the concept “Security Standard” is ex- plained in C2 “Security Standard for System X”. Under Strategy S1, we have used the structured security requirements in the Security Standard as the goal structure; G3 ...
GN represent different level (1∼n) of goals (security requirements) in the goal struc- ture (security standards/guidelines). LL1 are the lessons learned deemed to be related to a specific goal (security requirement). Under Strategy S2, the Missing Requirement
3.4. THE GENERIC SECURITY TEMPLATE PATTERN 48
G1: {System X} is acceptably secure
G3 {Index 1.X}
{Security Requirement 1.X}
is addressed S1: Argument over {Security Standard X}
C1: ISMS for {System X}
C2: Security Standard for {System X}
In the context of
S2: Argument over all Missing Security Recommendation
G2 (Standard non-existent):
{Missing Recommendation Y} is addressed
GN {Index N.X}
{Security Requirement N.X}
is addressed
LL1 {Security Issue N.X}
{Recommendation N.X}
LL2 {Missing Security Issue Y}
{Missing Recommendation Y}
(p = # security requirements of
level 1)
(r = # security requirements of
level n)
(q = # missing security recommendations )
r p
q In the
context of
Figure 3.6: The Generic Security Template Pattern