<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Deviational analyses for validating regulations on real systems</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Fiona Polack</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Thitima Srivatanakul</string-name>
          <xref ref-type="aff" rid="aff0">0</xref>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Tim Kelly</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>John Clark</string-name>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>Department of Civil Aviation, Ministry of Transport</institution>
          ,
          <addr-line>Bangkok 10120</addr-line>
          ,
          <country country="TH">Thailand</country>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>Department of Computer Science, University of York</institution>
          ,
          <addr-line>YO10 5DD</addr-line>
          ,
          <country country="UK">UK</country>
        </aff>
      </contrib-group>
      <fpage>813</fpage>
      <lpage>817</lpage>
      <abstract>
        <p>Deviational analysis is a traditional way of exploring the safety of systems. The results of deviational analysis contribute to traditional safety cases and safety arguments. We extend deviational analysis to other aspects of dependability, notably security. We discuss how the evidence of deviational analysis can contribute to the validation of regulations, in the sense of their application of regulations to real systems. Keyword: deviational analysis, dependability, regulation validation</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>Background</title>
      <p>
        Regulations are intended to control the way that choice operates in critical
systems. Validation must include consideration of how well their intent is met by
real systems operating within the regulations. We describe the systematic
analysis of security, illustrating it with results from a case study of the security of
baggage handling in an international airport [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]. The case study was carried
out in situ, with the co-operation of the relevant airport staff.
      </p>
      <p>
        International airline regulations [
        <xref ref-type="bibr" rid="ref9">9</xref>
        ] have a goal to prevent the introduction of
explosives or other dangerous devices on to aircraft by way of checked baggage.
This is elaborated [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ] to,
1. all baggage is subject to security controls prior to boarding the aircraft;
2. all baggage is protected from interference or the introduction of unauthorised
items after acceptance at the check-in counter;
3. baggage for passengers who are not on board the aircraft must not be
transported on to the aircraft.
      </p>
      <p>The first two aspects are addressed here. The case study reveals a range of
situations where the regulations are in force but their intent was not met.
1.1</p>
      <sec id="sec-1-1">
        <title>Deviational analysis and argumentation</title>
        <p>The most mature area of dependability assurance is safety; national and
international procedures require operators of aircraft, manufacturing plants and other
critical systems to provide evidence of acceptably-safe operation.</p>
        <p>
          In safety, traditional checklist approaches capture experience of development
or operation. More powerful approaches use flaw hypothesis to explore the
potential for accidents. For example, HAZOP [
          <xref ref-type="bibr" rid="ref7">7</xref>
          ] is a systematic, deviational approach
applied to models, that encourages imaginative analysis of potential for failure
by applying guidewords to concepts and components.
        </p>
        <p>
          Deviational techniques provide evidence for arguments made to demonstrate
to external assessors that a system meets necessary dependability targets. Again,
argumentation is most advanced in safety work. In general, we can identify the
required dependability attributes for particular types of system, and build policy
and regulations based on argumentation of these attributes (see [
          <xref ref-type="bibr" rid="ref2">2</xref>
          ]).
        </p>
        <p>
          Safety cases are typically visualised using the Goal Structuring Notation
(GSN). This expresses the structure of an argument in terms of the goals,
argument strategies (eg. for decomposing goals), context, assumptions and solutions
(where evidence establishes the validity of the stated goal) [
          <xref ref-type="bibr" rid="ref5">5</xref>
          ]. The GSN
approach has been extended to dependability and policy derivation (see [
          <xref ref-type="bibr" rid="ref4">4</xref>
          ]).
1.2
        </p>
      </sec>
      <sec id="sec-1-2">
        <title>Argumentation and regulations</title>
        <p>Our work looks at how well a real system establishes the intention of the
regulations under which it operates (we do not directly analyse the regulations). We
apply two deviational approaches to models of the baggage handling system. The
deviations aim to elicit ways in which baggage security could be compromised,
despite the system’s established conformance to international regulations.</p>
        <p>
          Our deviational approaches, developed to analyse models for potential
security vulnerabilities, apply HAZOP to use cases [
          <xref ref-type="bibr" rid="ref13 ref14">13, 14</xref>
          ] and security zones [
          <xref ref-type="bibr" rid="ref12">12</xref>
          ].
In [
          <xref ref-type="bibr" rid="ref11">11</xref>
          ], these approaches provide evidence to a GSN argument that the system
is acceptably secure. The goal is to meet the security intent of the regulations.
Here, we reflect on security analysis and argument as a means to explore how well
the compliant baggage handling system establishes the intent of the regulations.
2
        </p>
      </sec>
    </sec>
    <sec id="sec-2">
      <title>Abuse cases: HAZOP on use cases</title>
      <p>
        Use cases are used to model high-level functional requirements. We propose [
        <xref ref-type="bibr" rid="ref11 ref13">11,
13</xref>
        ] abuse cases to systematically challenge the meaning of every model element:
the use case, its actors and associations. HAZOP is applied to the use case’s
process steps and their pre- and post-conditions. For actors, HAZOP is applied
to their intentions and capabilities, as derived from intended goals.
      </p>
      <p>
        The technique was devised for use in the early stages of development, to
identify and incorporate security-related requirements and development constraints.
It is similar to, but more systematic than, other abuse or misuse case techniques
used to highlight system vulnerabilities [
        <xref ref-type="bibr" rid="ref10 ref6">6, 10</xref>
        ], and to work using HAZOP to
extract non-functional requirements [
        <xref ref-type="bibr" rid="ref1 ref3">1, 3</xref>
        ]. In adapting HAZOP for model analysis,
each HAZOP guideword must be assigned a clear interpretation for each type
of model element. For example, Table 1 gives the HAZOP guideword
interpretations for actor.
Feature Guideword Meaning
Actor NO The intent (action) does not take place
Intent MORE More than the intent is achieved, eg. sequential or parallel
repetition or some scalar parameter is too large
LESS Actions were incomplete or insufficient
AS WELL some supplementary or contradictory action occurred as
AS well as that intended
OTHER The action achieves incorrect results or the actor uses the
THAN action for purposes outside the intended
Actor NO The actor does not have the ability to perform the action
Capability MORE, AS More general capability, allowing more than intended
acWELL AS tion to be performed
LESS, Less capability, or only part of the required abilities, so
PART OF less is achieved than intended
      </p>
      <p>
        Table 1. Generic HAZOP guidewords interpreted for use case actor [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ]
The baggage handling system has been in operation for many years, so its
functional “requirements” are well understood. As expected, abuse cases reveal
no new information about functional aspects. However, the analysis reveals
various security threats and several implicit security requirements. It also highlights
the importance of appropriate inputs and/or information within the system:
many of the vulnerabilities relate to incorrect use of baggage tags, or to the
possibility of baggage being swapped or tampered with during the check-in process.
The HAZOP analysis focuses on areas of vulnerability in the system that might
compromise its ability to achieve the intention of the baggage regulations.
      </p>
      <p>In comparison to other security analysis techniques, abuse cases prompt a
detailed discussion of how an attack might exploit a vulnerability, and possible
effects of exploitation are thoroughly investigated. Airport security managers
found the technique beneficial in its ability to identify vulnerabilities in
operational tasks and in features of the computer systems related to baggage handling.
Importantly, these issues are newly identified, despite the long period of use,
under well-managed regulatory procedures.
3</p>
    </sec>
    <sec id="sec-3">
      <title>Zonal analysis with HAZOP</title>
      <p>Regulations typically assume zoning. For example, transport networks have zones
where vehicles can legally travel (roads, rails, air corridors) and park (parts of
airports, some road verges). Regulations intend to manage action in and between
zones, whilst risk analysis also considers interaction of networks: where roads
cross railways, or road vehicles circulate in airports. The importance of zones
in security is the ability to identify any means of illicitly crossing the boundary
between zones.</p>
      <p>
        In [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ], HAZOP challenges the potential channels, and the use of channels,
between zones. For the baggage handling system [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], there are three zones: the
baggage sorting and make-up area (zone 1), the check-in desk (zone 2) and all
adjacent areas (zone 3). Airport staff identified known channels in relation to
these zones. Compliance with the baggage-security regulations implies that these
channels are only used in intended ways by authorised agents. Srivatanakul’s
systematic zonal HAZOP identified over 50 potential vulnerabilities, such as
unintended channels to zones 1 an 2, and unintended consequences of intended
channels. Thus, zones 1 and 2 were shown to be secure, but checked-in baggage
might be compromised by illicit use of a legal entry point in to zone 2.
      </p>
      <p>In most cases, the vulnerabilities are protected by existing controls. However,
a few had the potential to cause serious breaches of regulation, prompting
reconsideration of how the regulations are interpreted, or application of enhanced
access control. Again, the airport security management found the technique an
effective audit of security measures.</p>
      <p>
        The HAZOP analyses contribute evidence to a GSN security argument. In
[
        <xref ref-type="bibr" rid="ref11">11</xref>
        ], sample patterns of analysis are presented to assist the argument of that the
security intent of the regulations is met. For example, a security goal formulated
as Access to Zone 1 is restricted to authorised persons might be decomposed
under a strategy, argument over authorised and unauthorised people. However, a
HAZOP result is that authorised people can legally access a zone and and cause
harm. The primary goal must be re-written as, Access to Zone 1 is restricted
to authorised persons for identified purposes. The analysis proceeds to consider
potential violations of security by authorised persons with unidentified purposes.
At the lowest level, evidence that a security goal is met is by appeal to the
finegrained HAZOP analysis of the zones and channels.
4
      </p>
    </sec>
    <sec id="sec-4">
      <title>Conclusions</title>
      <p>
        In relation to validation of regulations, [
        <xref ref-type="bibr" rid="ref11">11</xref>
        ] notes that the vulnerabilities found
by the two techniques arise, despite existing security controls and operational
tasks that are compliant with the regulations in [
        <xref ref-type="bibr" rid="ref8">8</xref>
        ]. It is well-known that security
cannot only be considered in general; regulations must be (re)validated in the
specific context and domain. Security vulnerabilities arise because it is too easy
to comply with the regulations without achieving their intent.
      </p>
      <p>In terms of the validation of regulations, our HAZOP analyses do not look
at the regulations themselves, but at the ability of a system to uphold the intent
of the regulation. HAZOP analysis is a widely-accepted systematic approach,
applied to models of systems to detect and evaluate potential failures or
vulnerabilities. Here, HAZOP generates significant insight in to potential security
threats that would cause the system to violate the security intentions of the
international baggage regulations.</p>
      <p>Abuse cases identify vulnerabilities in the interactions of people and
processes, whilst zonal HAZOP seeks side channels by which secure zones can be
attacked. Both are used here to explore how the intent of the regulations is borne
out in the actual system.</p>
      <p>
        Although the zonal HAZOP case study concentrates on physical zones,
HAZOP can also be applied to logical zones [
        <xref ref-type="bibr" rid="ref12">12</xref>
        ]. An important sort of logical zone,
in relation to regulation, is areas of responsibility; the analogy of illicitly crossing
a boundary between zones is gaps or overlaps in the responsibilities of people or
systems that contribute to compliance with the regulations.
      </p>
      <p>The deviational analyses provide a valuable security audit of the existing
system, and prompt consideration of the need for specific guidance on how to
achieve the intent of the regulations in specific situations. If similar analyses were
to be applied to systems for which new regulations were being prepared, possible
omissions or errors could be detected and corrected in the draft regulations.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          1.
          <string-name>
            <given-names>K.</given-names>
            <surname>Allenby</surname>
          </string-name>
          and
          <string-name>
            <given-names>T. P.</given-names>
            <surname>Kelly</surname>
          </string-name>
          .
          <article-title>Deriving safety requirements using scenarios</article-title>
          .
          <source>In 5th IEEE International Symposium on Requirements Engineering (RE'01)</source>
          . IEEE Computer Society Press,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          2.
          <string-name>
            <given-names>G.</given-names>
            <surname>Despotou</surname>
          </string-name>
          and
          <string-name>
            <given-names>T.</given-names>
            <surname>Kelly</surname>
          </string-name>
          .
          <article-title>Extending the safety case concept to address dependability</article-title>
          .
          <source>In 22nd International System Safety Conference. System Safety Society</source>
          ,
          <year>August 2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          3.
          <string-name>
            <given-names>B. P.</given-names>
            <surname>Douglass</surname>
          </string-name>
          .
          <article-title>Real-time UML (2nd ed</article-title>
          .):
          <article-title>Developing efficient objects for embedded systems</article-title>
          . Addison-Wesley Longman Ltd.,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          4. M. Hall-May and
          <string-name>
            <given-names>T.</given-names>
            <surname>Kelly</surname>
          </string-name>
          .
          <article-title>Planes, trains and automobiles - an investigation into safety policy for systems of systems</article-title>
          .
          <source>In 23rd International System Safety Conference. System Safety Society</source>
          ,
          <year>August 2005</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          5.
          <string-name>
            <given-names>T. P.</given-names>
            <surname>Kelly</surname>
          </string-name>
          .
          <article-title>Arguing Safety - A Systematic Approach to Safety Case Management</article-title>
          .
          <source>PhD thesis</source>
          , Department of Computer Science, University of York,
          <year>1999</year>
          . http://www.cs.york.ac.uk/ftpdir/reports/YCST-99-05.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          6.
          <string-name>
            <given-names>J.</given-names>
            <surname>McDermott</surname>
          </string-name>
          .
          <article-title>Abuse-case-based assurance arguments</article-title>
          .
          <source>In 17th Annual Computer Security Applications Conference</source>
          ., pages
          <fpage>366</fpage>
          -
          <lpage>376</lpage>
          . IEEE Computer Society,
          <year>2001</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref7">
        <mixed-citation>
          7. MoD.
          <article-title>Defence standard 00-58: HAZOP studies on systems containing programmable electronics</article-title>
          .
          <source>Technical report, UK Ministry of Defence</source>
          ,
          <year>1996</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref8">
        <mixed-citation>
          8. International Civil Aviation Organisation.
          <article-title>Annex 17, safeguarding civil aviation against acts of unlawful interference</article-title>
          .
          <source>ICAO</source>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref9">
        <mixed-citation>
          9. International Civil Aviation Organisation.
          <article-title>Doc 8973, security manual for safeguarding civil aviation against acts of unlawful interference</article-title>
          .
          <source>ICAO</source>
          ,
          <year>2002</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref10">
        <mixed-citation>
          10.
          <string-name>
            <given-names>G.</given-names>
            <surname>Sindre</surname>
          </string-name>
          and
          <string-name>
            <given-names>A. L.</given-names>
            <surname>Opdahl</surname>
          </string-name>
          .
          <article-title>Eliciting security requirements by misuse cases</article-title>
          .
          <source>In Proc. of TOOLS Pacific</source>
          <year>2000</year>
          , pages
          <fpage>120</fpage>
          -
          <lpage>131</lpage>
          . IEEE Computer Society,
          <year>2000</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref11">
        <mixed-citation>
          11.
          <string-name>
            <given-names>T.</given-names>
            <surname>Srivatanakul</surname>
          </string-name>
          .
          <article-title>Security Analysis with Deviational Techniques</article-title>
          .
          <source>PhD thesis</source>
          , Department of Computer Science, University of York, UK,
          <year>2005</year>
          . http://www.cs.york.ac.uk/ftpdir/reports/YCST-2005-12.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref12">
        <mixed-citation>
          12.
          <string-name>
            <given-names>T.</given-names>
            <surname>Srivatanakul</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J.</given-names>
            <surname>Clark</surname>
          </string-name>
          , and
          <string-name>
            <given-names>F.</given-names>
            <surname>Polack</surname>
          </string-name>
          .
          <article-title>Security zonal analysis</article-title>
          .
          <source>Technical Report YCS-2004-374</source>
          , Department of Computer Science, University of York, UK,
          <year>2004</year>
          . http://www.cs.york.ac.uk/ftpdir/reports/YCS-2004-374.pdf.
        </mixed-citation>
      </ref>
      <ref id="ref13">
        <mixed-citation>
          13.
          <string-name>
            <given-names>T.</given-names>
            <surname>Srivatanakul</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. A.</given-names>
            <surname>Clark</surname>
          </string-name>
          , and
          <string-name>
            <given-names>F.</given-names>
            <surname>Polack</surname>
          </string-name>
          .
          <article-title>Effective security requirements analysis: HAZOP and use cases</article-title>
          .
          <source>In Information Security: 7th International Conference</source>
          , volume
          <volume>3225</volume>
          <source>of LNCS</source>
          , pages
          <fpage>416</fpage>
          -
          <lpage>427</lpage>
          . Springer,
          <year>September 2004</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref14">
        <mixed-citation>
          14.
          <string-name>
            <given-names>T.</given-names>
            <surname>Srivatanakul</surname>
          </string-name>
          ,
          <string-name>
            <given-names>J. A.</given-names>
            <surname>Clark</surname>
          </string-name>
          , and
          <string-name>
            <given-names>F.</given-names>
            <surname>Polack</surname>
          </string-name>
          .
          <article-title>Writing effective security abuse cases</article-title>
          .
          <source>Technical Report YCS-2004-375</source>
          , Department of Computer Science, University of York, UK,
          <year>2004</year>
          . http://www.cs.york.ac.uk/ftpdir/reports/YCS-2004-375.pdf.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>