7.5.1
Functionality
In deciding on the implementation scope of the SASaCS prototype, emphasis was placed on two aspects. First, identifying areas which would demonstrate some of the core research ideas embodied in the system, and second, using areas that provided a platform for a good evaluation which appreciated the limitations of this project. The functionalities chosen which met this criteria were the ‘Encoding of Risk Methodology (RiM) findings & security actions’ (Use case 3) and the ‘Comparison and assessing of security actions’ (Use case 4). These cases (viewable in Figure 7.2) adequately characterize core underlying research themes and also encompass the overarching goal of easing the progression between Requirements Elicitation and Negotiations phases in BOF4WSS.
Use cases 1 and 2 were accepted as important to this research but their implementation was not seen to add significant value to the prototype or any subsequent evaluation of it. They were therefore excluded.
To expand briefly on the functionality of Use case 3, two enabling com- ponents deserve mention. These are, the Risk Catalogue from which risks are selected (this relates to both the central and local catalogues), and the SADML format which is the formal language used to encode risk methodology findings and security actions data. The former of these aspects encompasses the creation of a simple database system and its population with risks data. As this task is relatively trivial, further detail on the construction process is not given; the database structure for the risks system can however be seen in the more general entity diagrams in Appendix A.
The next enabling component promotes the SADML format as a novel document format to define RM/RA data which may also have uses independently of the SASaCS tool. Example usages of SADML include using it as a document exchange format or for storage of RM data from various disparate techniques. With appreciation of the novelties of this new XML-based format, the next section
7. Security Action Specification & Comparison System (SASaCS) Prototype 171
gives an overview.
7.5.2
Security Action Definition Markup Language
(SADML)
The structure of SADML was conceived to mirror the knowledge captured in the ontology (from Chapter 6) and as such, a number of the ontology’s concepts have been represented as XML elements/tags. To comply with XML’s hierarchical na- ture it was necessary to define a sensible hierarchy of elements. Furthermore, this structure would need to accommodate one-to-many relationships across elements (for example, if a security policy relates to multiple security actions, this should be appreciated). An excerpt of such a structure is displayed in Figure 7.4.
Asset
Risk(s)
Threat(s)
Threat Agent
Vulnerabilities Risk Level Acceptance Action(s) Impact Factor Probability Factor Adequacy of Controls Factor Mitigation Action(s)
Laws and Reg- ulations Refs Security Policy Refs Coverage Level Same as Acce- ptance Action Laws and Regulations
...
...
Security Requirements Level 1 Level 2 Level 3 Level 4 Security Policies...
Figure 7.4: A hierarchical structure of the elements
As shown in Figure 7.4, the top-level elements are based around the secu- rity actions and treatment factors (such as laws and policies). This was because the security actions were found to be encompassing elements in which various other concepts (for example, risks and threats) could be logically composed. Simi- larly, the treatment factors were independent elements which were only referenced (using XML elements/tags ending in ‘Refs’) in security actions. In practice there- fore, there might be an acceptance action that addresses one or more risks, and one or more security policies may have been used/referenced to determine that action. Part of the SADML format is presented in Code Snippet 2. The + sign indicates that there is additional data which is not displayed here.
<needsBase xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:risksx-schema"> <mitigationActions>
<mitigationAction>
<name>Security action for auditing/logging purposes</name>
<details>Mitigation action for auditing/logging purposes</details> <risks>
<risk id="GR1">
+ <threats>
+ <vulnerabilities>
+ <riskLevel value="high">
<riskComment>Risk associated with general logging, auditing, and ...</riskComment> <riskActionCoverageOfRisk> <coverageLevel>full coverage</coverageLevel> <coverageDetail /> </riskActionCoverageOfRisk> </risk> + <risk id="GR2"> </risks> <lawAndRegulationRefs>
<lawAndRegulationRef idref="LR215"><relationToRiskAction /></lawAndRegulationRef> </lawAndRegulationRefs> + <contractualObligationRefs> <businessPolicyRefs /> + <securityPolicyRefs> <securityBudgetRefs /> <securityRequirementRefs>
<securityRequirementRef idref="SR230"> ... </securityRequirementRef> </securityRequirementRefs> </mitigationAction> + <mitigationAction> </mitigationActions> + <acceptanceActions> <transferenceActions /> <avoidanceActions /> <lawsAndRegulations>
<lawAndRegulation id="LR215">Sarbanes-Oxley Act of 2002 (SOX) requires that companies maintain a ready available, verifiable audit trail and ... </lawAndRegulation> </lawsAndRegulations> + <contractualObligations> <businessPolicies /> + <securityPolicies> <securityBudgets /> <securityRequirements>
<securityRequirement id="SR230">A part of reliable business process execution both within the company and externally, involves comprehensive logging ... </securityRequirement> ...
</securityRequirements> </needsBase>
7. Security Action Specification & Comparison System (SASaCS) Prototype 173
The snippet gives a snapshot of the implemented XML hierarchy men- tioned prior. The core of the SADML format is described in the XML schema
designed (indicated by urn:risksx-schema in the document).
The novelty of SADML is rooted in the unique perspective it gives on security actions and the emphasis it places on aspects which have been overlooked in other languages. From a review of the literature, only one related generic (that is, not system-specific) XML-based language was identified. This was the Enterprise Security Requirement Markup Language (ESRML) [176].
ESRML, as Roy et al. [176] note, is for specifying enterprise information security requirements which are in compliance with the ISO 17799 standard. The knowledge gap filled by this language is similar to the area targeted by SADML. This is particularly as ESRML looks at (i) the higher layers of security and not specifics such as access control (such as the eXtensible Access Control Markup Language (XACML)) or identity management (such as the Security Assertion Markup Language(SAML)), and (ii) sharing and exchanging the enterprise se- curity information across companies for business purposes. The shortcomings of ESRML in terms of this research stem from its lack of emphasis on factors which significantly influence security actions, and its concentration on risk mitigation as opposed to other ways to treat risks. These are areas addressed in SADML. With the prototype’s scope now presented, the next section discusses some important implementation decisions made.
7.5.3
Justification of Implementation Decisions
To implement the functionalities outlined for the prototype, three fundamental questions were identified. These pertained to what software development tools to employ, exactly what type of application—desktop versus Web-based—would be most appropriate to build and lastly, for security actions comparison, should the system be developed to accommodate any number of companies or would a more manageable subset be adequate.
crosoft Visual Studio 2008 [126] (VB.NET language) and SQL Server 2005 [125] to support SASaCS prototype development. These tools were preferred (to, for example, a Java-based tool-set) because of the researcher’s previous experience in working with them and the vast array of predefined controls available. Both of these factors therefore acted to speed-up and enhance the development process.
The second decision related to the type of application created and this was important because of the varying nuances linked to desktop and Web-based applications (see Liberty and Hurwitz [109] for detailed benefits and differences). After careful analysis, a desktop application was chosen as it allowed for the development of a much more flexible solution in terms of user interface, data entry and format of system output.
The final decision focused on the general question of whether the proto- type’s comparison features should accommodate any number of companies, simi- lar to the full SASaCS version, or if catering to a smaller subset of companies (for example, two or three) would suffice. Following deliberations on this topic, it was decided that allowing for these operations between two companies would suffice. Although increasing the number of companies might be better as it would more closely resemble the full system version, for the purposes of the prototype, the added value of doing this did not merit the increased implementation complexity. This was mainly because the general conceptual approach which would be applied to two companies is also the way in which multiple companies would be handled.