Chapter 7 Security Action Specification & Comparison System
7.4 SASaCS Development
7.4.1
Requirements Specification
As shown in Figure 7.1, the Requirements Elicitation and Analysis tasks are key activities within Specification/Requirements Engineering. To facilitate the gathering of requirements for SASaCS, the two techniques used were analysis of scenarios (that is, real-life examples or narrations of how the system would work) and small-scale prototypes. These enabled varying levels and perspectives of requirements to be viewed. The main scenario used is documented below.
Typical Scenario: Company A and Company B first select a set of pertinent risks from an independently owned and moderated central risks catalogue/listing. These risks will factor into their RM methodologies. This is done to ensure that both companies start from the same point concern-
ing the security risks which face the envisioned business scenario. The
central risks listing is to be extensive and updated regularly. Public sub- missions/suggestions of risks are to be allowed, but moderated by third party security professionals.
Having selected the security risks, companies individually apply their methodologies. If new risks are identified, these are shared with the business partners to ensure all entities consider the same risks. After each company’s general RM process, the findings and documentation produced are entered into SASaCS. The system enables users to select the risks agreed previously and add respective information on (i) their security actions, that is, how the company has decided to handle the risks, and (ii) the various aspects (such as laws, risks’ severity levels and so on) that have influenced how the company treats the risk. Once complete, the system encodes all the information entered into a standardized document format.
Personnel from Company A and Company B would then meet up, bring- ing together their documents with the encoded information. These docu-
7. Security Action Specification & Comparison System (SASaCS) Prototype 165
ments are fed into the comparison feature of the SASaCS tool. The system is expected to match the risks and compare the treatment of risks across companies. This therefore enables an easier negotiation, discussion and reconciliation of conflicting security actions. Various settings should also be available in the system to allow detailed security action and risk data comparison. Output of the system should be (i) a user-friendly interface where security actions and the related security risks are matched to some degree and displayed, and (ii) a list of flagged inconsistencies that represent exceptional situations and thus should be discussed by companies’ analysts and security professionals.
This scenario of how the developed system would be used offers a general view of the major tasks that a fully implemented SASaCS should accommodate. With this documented, the next objective was a scenario analysis to determine and formally state the requirements of the system. The output of this analysis is included in a UML diagram in Figure 7.2. The UML use case diagram was preferred as it is a largely accepted graphical modelling technique to express system behaviours and functional requirements [193].
To briefly explain the use case diagram, the large box on the right repre- sents the actual system, which in this case is SASaCS. The two entities on the left are external actors (or persons) that interact with the system. Within the system box, there are a number of use case ovals which provide a top-level description
of the behaviour that the system is to exhibit. Figure 7.2 employs a uses
notation to show where system behaviour is part of a larger task. For exam- ple, the ‘Maintain accessible central risk listing’ behaviour is comprised of the ‘Update global risk listing’ and ‘Accept new risk submissions’ tasks. Conversely, the extends notation is employed to show where sub-tasks are optional, for example, ‘Synchronize to global risk listing’ may or may not occur during the execution of the ‘Maintain local risk listing’ task. Finally, actor-to-use case lines are used to connect actors and the specific use cases within the system with which
1. Maintain accessible central risk listing
Update central risk listing Accept new risk
submissions Submit risks to central
risk listing
2. Maintain local risk
listing
Synchronize local to central risk listing Update local risk
listing
3. Encode Risk Metho-
dology (RiM) findings & security actions
Allow user input of RiM findings
Allow referencing of local risk listing Produce document
with encoded RiM findings Process documents with security actions
4. Compare & assess
security actions Identify similarities & disparities in documents Present output to system users SASaCS Independent Security Professionals «uses» «uses» «uses» «uses» «extends» «uses» «uses» «uses» «uses» «uses» «uses» Company «uses»
Allow input of security actions & supporting
factors
Figure 7.2: Use case model of the complete SASaCS version they interact.
Progressing from the diagram’s notation itself, there are four main use cases: ‘Maintain accessible central risk listing’, ‘Maintain local risk listing’, ‘En- code Risk Methodology (RiM) findings & security actions’ and ‘Compare and assess security actions’. The tasks involved in these use cases largely mirror the activities discussed in the typical case scenario above. Furthermore, in some sit- uations they add detail on how the activities may be executed (for example, the ‘Synchronize local to central risk listing’ case expands on how a local risk listing is maintained). As a result of these two factors, this section does not provide further descriptions of these use cases.
To accompany a use case diagram, Lunn [113] advocates the application of use case descriptions and documentation templates. These templates tend to be very useful as they enable more detail to be provided for the cases outlined in the diagram. Sommerville [193] adds to the discussion and notes that use cases can be further supplemented with UML sequence diagrams. The benefit of these is their ability to expand on a use case and provide a graphical, low-level model of
7. Security Action Specification & Comparison System (SASaCS) Prototype 167
the sequence of interactions which constitute it. Both these techniques (templates and sequence diagrams) were employed to aid in the Requirements Engineering activity during SASaCS development.
Having provided an outline of the functionality expected by SASaCS, the next section takes a brief look at the design architecture. This provides an insight into the general design ideas supporting the complete system and also sets the context for the prototype implementation section which it precedes.
7.4.2
Architectural Design
The main goal with the architectural design stage is to lay the groundwork for a system which will satisfy the previously specified requirements. Sommerville [193] expands on this notion and describes the architectural design as being concerned with “establishing a basic structural framework that identifies the major compo- nents of a system and the communications between these components” (p.242). Because of these aims, the design task is a critical undertaking where various fundamental but important system decisions are made.
For SASaCS, the architecture design task was guided by [193] and there- fore one of the main emphases was on identifying system components and their interactions (readers can refer again to Figure 7.1 for the overview). The ar- chitecture produced which is shown in Figure 7.3 is also heavily based on the ‘Solution Model in action’ construct. That model supplies a justification for the architecture conceived. From Figure 7.3, one can also see the implementation of the use case behaviours outlined in Figure 7.2. To supplement the diagram, an example of a typical process flow is given. This example provides practical insight and further detail into the workings of the model that were excluded from the diagram to avoid clutter. Here are the steps.
1. Businesses reference the central Web site and agree on a risks catalogue version to use for their interactions. Each entity then synchronizes their local risk catalogue to the agreed Central Risk Catalogue.
risk cat- alogue (local)
selection of basic risk data from.. methodology
references.. 5.findings methodology input into..
Data entry & Encoding interface
of SASaCS tool
7. SADML doc entered into..
1. companies agree on Central catalogue version for use & any specific shared risks, then sync local datastores
Company 1 6. encoding produces SADML doc ... ... ... Comp any 2 Comp any n
Website with: Central
Risk Catalogue datastore, & SADML
schema
Comparsion & assessment
features of the SASaCS tool
8. validate SADML docs against schema
...
7. SADML docs entered into.. 1. ...9. output: (i) User-friendly interface where security actions and the related security risks, are matched to some degree and displayed (ii) Inconsistencies flagged that represent exceptional situations
and thus should be discussed by personnel
3. exchange risks data Risk methodology conducted
2. Risk identification stage
4. Continue methodology
Figure 7.3: SASaCS architecture overview
2. Companies then carry out their individual risk identification processes for the scenario, in which they also consider risks from their now-synchronized local risks catalogue.
3. If risks are found which are not included in a business’ synchronized risks catalogue, these are then communicated to the other parties so that all of them can assess these risks in their subsequent risk assessment stages. In more specific terms, companies will add these newly suggested risks to their local risk catalogues and refer to them later during risk assessment and ultimately data entry and encoding.
4. Businesses then branch off to continue conducting their RM methodologies. Key aspects of interest include risk severity/priority levels and other fac- tors that aided in how entities decided to treat the identified risks. Full documentation should be made and kept.
5. Each entity would then input data from their RM methodology documen- tation into the Data Entry interface of SASaCS. The aim is to get pertinent information on risks and factors influencing risk treatment choices (that is, security actions) into the system. A typical process for a single risk would
7. Security Action Specification & Comparison System (SASaCS) Prototype 169
be:
(a) Within the Data Entry interface, select a risk (the system would query from the local risk catalogue to allow risks to be chosen)
(b) Find the selected risk in the risk methodology documentation
(c) Enter pertinent information related to the risk into the Data Entry interface. This encompasses data on the risk’s severity level, factors (such as policies, budgetary constraints and so on) that influenced the decision to choose a security action to address that risk and, finally, the security action itself.
6. After companies are finished, the Encoding interface of SASaCS allows them to encode all the information entered and have it output in a SADML document.
7. At the comparison and assessment stage, businesses then bring their docu- ments together and allow them to be assessed by the Comparison features of SASaCS.
8. The system validates the documents to ensure they are well-formed (a com- mon XML check) and conform to purpose-built SADML schema rules. 9. The system conducts the comparison of security actions. The predefined,
shared risks are a critical component during comparison as they form the common base on which security actions can be matched and compared. Finally, the system outputs (i) a user-friendly report where security actions and the related security risks for all companies are matched and displayed on screen, and (ii) inconsistencies that represent exceptional situations which need to be followed up and further discussed by companies’ personnel.
Having reported on the design of the full SASaCS version, the next section narrows the scope to focus on the prototype system that was implemented.