Boutle, C

Hayat, MZ

Reeve, JS

English

Southampton (e-Prints Soton)

UNCLASSIFIEDDomain Based Security: Improving PracticesZia Hayat∗University of Southamptonzia.hayat@baesystems.comJeﬀ ReeveUniversity of Southamptonjsr@ecs.soton.ac.ukChris BoutleBAE SYSTEMS Integrated System Technologieschris.boutle@baesystems.comAbstract DBSy (Domain Based Security) is being used more and morefor the identiﬁcation, analysis and documentation of security issues in en-terprise CIS (Communication & Information Systems) projects particularlyin the military domain. The methodology incorporates numerous securityrelated activities in the early stages of the systems lifecycle to aid in thespeciﬁcation of high-level, technology independent security functionality so-lutions.This report focuses on research carried out into improving practices withinthe DBSy user community with particular emphasis on:• Applicability and indeed advantages of using DBSy to model: mobile,autonomous and ad-hoc CIS from a business processes perspective• Ranking risks1 according to an appropriate value system• Modeling business connections in an extensible mannerThe IFPA (Indirect Fire Precision Attack) and CVF (Future Carrier) projectswere used as case studies, in order to identify the extent to which DBSy sup-ports the modelling of the aforementioned concepts. Section 1 introducesthe signiﬁcance of DBSy and the reasons for its use in military enterpriseprojects such as IFPA & CVF, section 2 then highlights limitations identi-ﬁed in the current speciﬁcations of DBSy and how it maybe advantageousto build upon the current speciﬁcations. Section 3 discusses solutions pro-posed in order to overcome the limitations identiﬁed in section 2. Section 4illustrates the usefulness of the proposed solutions in terms of IFPA & CVFwith section 5 containing the ﬁndings from this research.Key Words: Autonomous Systems, Business Connections & Rank-ing Risks∗Sponsored by BAE SYSTEMS Integrated System Technologies, Security ResearchGroup, Frimley, Camberley, Surrey GU16 7EX, UK1The terms risk and compromise path will be used interchangeably throughout thisreport1UNCLASSIFIED1 IntroductionFrom our experiences of applying DBSy to various infosec projects it hasbeen found to be a highly intuitive and ﬂexible methodology, providing de-signers and accreditors with the required information to assess security froma cost-beneﬁt point of view. Such cost-beneﬁts assessment may not be di-rectly ﬁnancial instead relating to user experience and the agility of theprocesses in place to enable the business and allow it to react eﬀectively tochanging circumstances.Most modern military CIS are procured under increasingly demandingtime and cost restrictions. These restrictions combined with requirementsto integrate new and existing systems providing NEC (Network Enabled Ca-pability) have exacerbated the need to provision for security from an earlystage ideally from the initial feasibility phase. Early consideration of securityprovides a better understanding of the security issues ultimately providinga more eﬀective solution meeting the requirements with lower associatedcosts.Due to its integrated and systematic approach for identifying, analysingand documenting security issues at an early stage DBSy has been used tospecify security functionality from a technology independent point-of-viewin both IFPA & CVF.Mobile and autonomous CIS allow ﬂexible and sophisticated modes ofoperation, which are increasingly necessary for businesses to eﬃciently, ful-ﬁl their requirements. Such systems also introduce ad-hoc communications,which need to be securely managed. Together mobile & autonomous CISand the ad-hoc communications they utilise present signiﬁcant security chal-lenges. It is therefore important for DBSy to be able to model such issuesif it is to eﬀectively analyse enterprise CIS architectures for military andnon-military business.In order to successfully minimise potential risks it is important to gain anunderstanding of their severity relevant to one another, DBSy must thereforefacilitate such a requirement. Many businesses also require specialised con-nection types for communications between business processes DBSy musttherefore provide an extensible mechanism to model such connections.2 Perceived Limitations in DBSy SpeciﬁcationsDue to the relative novelty of DBSy it has not been fully tested throughapplication to real life projects. In our modelling of IFPA we encounteredthe problem of describing an autonomous system, which is also mobile andrequires ad-hoc communications with other physically distributed systems.Current speciﬁcations of DBSy do not identify how to model such behaviour.Although it has been found that DBSy does not explicitly support themodelling of mobile, ad-hoc and autonomous systems, the advantages ofproviding such techniques have also been investigated. DBSy unlike mostother modelling tools illustrates the maximum allowed connectivity between2UNCLASSIFIEDvarious business processes. Although the explicit representation of mobileprocesses and ad-hoc communications would provide a more complete repre-sentation of an architecture this cannot be seen to enhance the understand-ing of security issues. As all processes (static or mobile) and communications(permanent or ad-hoc) must be explicitly deﬁned in a uniform manner, en-suring that the superset of all such processes and their connections are fullyspeciﬁed.Due to the limited usefulness of explicitly modelling mobile CIS andad-hoc communications it was decided to concentrate on developing mecha-nisms for the description of autonomous CIS. However as previously statedno technique within DBSy currently exists to model autonomous systems.Features from the speciﬁcations [4] most closely aligned to modelling au-tonomous systems are sensors2, eﬀectors3 and business domains4. A tradi-tional business domain is restricted to representing a logical group of peoplewho may collaborate and share information relatively freely and sensors &eﬀectors do not permit explicit valuation. These limitations mean the cur-rent speciﬁcations do not satisfy our requirements for modelling autonomousbusiness processes in IFPA, where we have a unique business process of adeﬁned value (protective marking & criticality level) which does not explic-itly represent any logical grouping of people, instead autonomously aimingto achieve the dynamic goals of people in business domain(s).There is currently no speciﬁcation for the systematic ranking of riskswithin DBSy. Such an approach would aid in reporting risks in a moremeaningful and concise manner thus allowing for resources to be concen-trated into those risks perceived to be of greatest threat according to theranking mechanism. This is particularly signiﬁcant in larger projects suchas CVF, where the security analyst can be swamped by the vast number ofpotential risks with no sense of their relative signiﬁcance.The speciﬁc nature of certain projects means the business connectionsbetween various processes are not adequately modelled using the standardconnection types, which are part of the current DBSy speciﬁcation. A moregeneric method for expressing connection types is therefore required this washighlighted in our modelling of IFPA, where we require a messaging connec-tion between an autonomous business process and person(s) with whom itmay communicate. This is contrary to the current standard messaging con-nection type which is deﬁned for communications between people in businessdomains only.2A sensor is deﬁned as: Connects an environment to a domain, enabling informationto be collected from the environment.3Eﬀectors have various deﬁnitions depending on its instance for example a printer isdescribed as: Connects a domain to an environment, enabling information to be printed.4A business domain represents the logical places where people work and exchange databy means of software acting on their behalf.3UNCLASSIFIED3 Proposed Improvements to DBSy SpeciﬁcationsThe discussions in sections 1 and 2 suggest the concept of autonomy mustbe addressed, enabling accurate modelling of the envisaged CIS architecturefor IFPA, thus providing a valuable insight into the security implicationsinvolved. Abstractly an autonomous system can be described as some com-bination of integrated sensing and eﬀecting capability. Such systems mayreact to sensed data in a semi-automatic manner, using pre-deﬁned or real-time5 decision rules upon which to base eﬀecting actions.The ABD (Autonomous Business Domain) construct has been devised tomodel autonomous processes in DBSy, its graphical representation is givenin ﬁgure 1. Its speciﬁcation can be summarised as: A logical computing andcommunication base, which may accumulate, transmit and process data. AnABD must:• Be hosted upon an island of infrastructure• Connect to: environment(s) via sensors and/or eﬀectors and businessdomain(s) via business connection(s)• Have a unique identiﬁer within an infosec business model• Have an appropriate valuation such as protective marking as well ascodes and caveats as necessaryFigure 1: Graphical representation of the ABD business process construct.Due to the generic nature of its speciﬁcation the ABD is applicable in awide range of instances particularly military, due to the increasing numberof CIS projects requiring autonomous capability such as guided munitions,unmanned underwater vehicles, smart mines etc. The potentially sensitivenature of the business carried out by ABDs suggests they must be hostedupon island(s) of infrastructure, highlighting the need for well deﬁned andsecure points of communication with other processes.From the speciﬁcation of an ABD it is proposed to label ABDs withprotective marking and codes & caveats. Therefore ABDs can be analysedas a point of attack (in the compromise step analysis stage) just as anyother important business process in DBSy such as conventional business do-mains. This aids in the identiﬁcation of risks associated with such processes.5Real-time decisions maybe from a human user operating in business domain(s), e.g.MITL (Man-In-The-Loop)4UNCLASSIFIEDFor example mobile code can give attackers the opportunity to re-conﬁgureautonomous processes to react to authorised or un-authorised instructions(e.g. command & control) in malicious or un-intended ways. Potential at-tacks may vary from the leakage of conﬁdential data to integrity and evendenial-of-service.The compromise path analysis technique currently speciﬁed in DBSy toidentify potential risks maybe used in conjunction with an appropriate valuesystem to rank risks. An overview of the process proposed to identify andrank risks is given below and summarised in ﬁgure 2.1. Deﬁne an infosec architecture model2. Carry out compromise step analysis on the infosec architecture model3. Identify compromise paths4. 6 Carry out HMG IS3 (Her Majesty’s Government Infosec Standard3) connection level calculations for each compromise path identiﬁed instep 35. List individual compromise paths in order of severity according toHMG IS3 connection levels calculated in step 4In order to calculate the HMG IS3 connection level for individual com-promise paths7 it is suggested to take into account the diﬀerence in protec-tive marking, codes and caveats of both the attacker and victim domains.Figure 2: Overview of proposed threat analysis technique.It is suggested non-standard business connection instances are referencedby a unique identiﬁer, this is illustrated in further detail in section 4. Suchan approach would aid in the modelling of non-standard business connec-tions, as well as providing potentially useful security information, due to thesensitivities of speciﬁc connection types and the data they transmit.6This step (4) maybe replaced by any valuation scheme of relevance to the project beingundertaken, the example given is for UK (United Kingdom) MoD (Ministry of Defence)projects.7Such a path maybe a direct or indirect connection in terms of the infosec businessmodel (developed as part of the infosec architecture model), however this is not relevantin the current context.5UNCLASSIFIED4 Application of ImprovementsThe example infosec architecture model illustrated in ﬁgure 3 highlights theuse of an ABD with table 1 showing the use of a referencing table to describenon-standard business connections. It can be seen how an ABD may usesensors and eﬀectors as well as other business connections to enable it incarrying out its required business. From table 2 it can be seen how risks canbe ranked according to an appropriate value system8.The ranking of compromise paths9 according to their severity is sug-gested as a suitable risk ranking mechanism. Deriving risks according toa mechanism such as that illustrated in ﬁgure 2 would also prove inexpen-sive, as most of the steps shown are likely to already be carried out in themajority of projects which utilise DBSy.Figure 3: Illustrates the use of the ABD component and referencing of non-standard business connections.Connection Id Connection Description1 Logistics Messaging2 Imaging & Temperature Information3 Mission Speciﬁc MessagingTable 1: Deﬁnes each non-standard connection for the example infosec ar-chitecture in ﬁgure 3.8HMG IS3 using only protective markings was used in the example given in table 2.9If a series of compromise steps from a potential attacker to a victim process consistsolely of soft security functions this is deﬁned as a compromise path. There are twodistinct risk types, which are classiﬁed according to the direction of the data ﬂow, theseare:- Conﬁdentiality risks whereby data ﬂows from the victim to the attacker process- Integrity & Availability risks whereby data ﬂows from the attacker to the victimprocess6UNCLASSIFIEDFrom a detailed threat analysis carried out using in house software devel-oped previously, three compromise paths have been identiﬁed. These pathscan also be identiﬁed from ﬁgure 4. The risks are as follows:• Attacker:A - Victim:B (Risk T)• Attacker:Z - Victim:A (Risk U)• Attacker:B - Victim:A (Risk V)Figure 4: Illustrates the compromise paths of the infosec architecture inﬁgure 3.It must be noted that an indirect compromise path also exists wherebyprocess Z is the attacker and process B is the victim via process A, howeverit has not been explicitly identiﬁed as the individual risks U and V can beseen to encompass this risk.Risk HMG IS3 Level RankingT 1 2U 2 1V 1 =2Table 2: Ranking of risks for the example infosec architecture in ﬁgure 3.Although the ranking mechanism outlined does not explicitly expressthe type of risk (i.e. Conﬁdentiality, Integrity or Availability) this can beidentiﬁed from the compromise step analysis stage.7UNCLASSIFIED5 ConclusionsExperience in applying DBSy to the IFPA and CVF projects has shown itto be a ﬂexible and indeed eﬀective methodology for the identiﬁcation, anal-ysis and documentation of security issues in infosec architectures. Howeverdue to its relative novelty as well as its broad appeal it has been shownthat individual user communities such as the military will have to adapt themethodology for their needs, building on the fundamental building blockstowards more comprehensive techniques.The issues of mobile systems and ad-hoc communications have beenfound to not require speciﬁc adaptation as this would add little to the use-fulness of the methodology in security terms. However autonomous systemssuch as those proposed in IFPA have been found to require innovation bythe user community in order to leverage the advantages of DBSy.The ranking of potential risks has been identiﬁed as a valuable procedureproviding useful information to analysts and developers of systems, for thepurposes of concentrating scarce resources according to the potential sever-ity of risks. Such a ranking mechanism would aid in large projects such asCVF particularly where the number of risks are numerous proving diﬃcultto identify the relative severity of risks.The modelling of specialised business connection types allows for a moreintuitive description of the communications between business processes aswell as, giving a more comprehensive insight into potential security impli-cations due to the nature of the data in transit. This was highlighted fromour work on IFPA where it was necessary to specify business connectionscurrently unavailable in the standard template.Acknowledgements: Thanks to Richard Elder & Chris Coles for theirinvaluable contribution, to this piece of work. Martin Field provided usefulfeedback on the presentation of this paper.8UNCLASSIFIEDReferences[1] M.Z. Hayat, Domain Based Security Threat-Analysis, AMS IntegratedSystems & University of Southampton, UK, January 2005.[2] K.J. Hughes, Domain Based Security: enabling security at the level ofapplications and business proceses, QinetiQ, Malvern, UK, 2002.[3] MoD, HMG Infosec Standard 3: Connecting Business Domains, UK,October 2001.[4] A.P. Page, G.D. Dickin, C.L. Robinson, Domain Based Security: Ab-breviations and Glossary of Terms, QinetiQ, Malvern, UK, 2003.[5] C.L. Robinson and K.J. Hughes, Managing Infosec Risk in ComplexProjects, QinetiQ, Malvern, UK, 2001.[6] C.L. Robinson, K.J. Hughes, I. Staniforth and S. Wiseman, Classes ofSecurity Functions for use with an Infosec Architecture Model, QinetiQ,Malvern, UK, 2003.[7] S. Wiseman and K.J. Hughes, Categories of IS3 Functionality to supportcompromise path analysis, QinetiQ, Malvern, UK, 2003.9

Categories of IS3 Functionality to support compromise path analysis,

Classes of Security Functions for use with an Infosec Architecture Model,

Domain Based Security Threat-Analysis, AMS Integrated Systems

Domain Based Security: Abbreviations and Glossary of Terms,

Domain Based Security: enabling security at the level of applications and business proceses,

Infosec Standard 3: Connecting Business Domains,

Managing Infosec Risk

Domain Based Security: Improving Practices

Domain Based Security: Improving Practices

Abstract

Similar works

Full text

Available Versions

Southampton (e-Prints Soton)