Abstract We grow increasingly dependent on the appropriate operation of computer-based systems. One...
57
Writing Effective Security Abuse Cases Thitima Srivatanakul, John A. Clark and Fiona Polack University of York Technical Report YCS-2004-375 University of York Department of Computer Science 14 May 2004
Transcript of Abstract We grow increasingly dependent on the appropriate operation of computer-based systems. One...
Writing Effective Security Abuse Cases
Thitima Srivatanakul, John A. Clark and Fiona Polack
University of York Technical Report YCS-2004-375
University of York
Department of Computer Science
14 May 2004
Abstract We grow increasingly dependent on the appropriate operation of computer-based systems. One aspect of such systems is security. As systems become more complex current means of analysis will probably prove ineffective. In the safety domain a variety of analysis techniques has emerged over many years. These have proved surprisingly effective. Since the safety and security domains share many similarities, various authors have suggested that safety techniques might usefully find application in security. This report takes one such technique, HAZOPs, and applies it to one widely used informal design component – UML’s use cases.
i
Table of Contents 1. Introduction............................................................................................................1
1.1 Motivation......................................................................................................1 1.2 Solutions from safety .....................................................................................2
2. HAZOP: A rigorous approach to security analysis................................................4 2.1 HAZOP ..........................................................................................................4
3. Use cases................................................................................................................7 4. Method procedures and guidelines ........................................................................9
4.1 The analysis process ......................................................................................9 4.2 Use case elements and their security deviations ............................................9 4.3 HAZOP security guidewords.......................................................................11
5. Deriving use case deviants...................................................................................14 6. Example application.............................................................................................16
6.1 System description .......................................................................................16 6.2 Analysis........................................................................................................18 6.3 The results....................................................................................................44
7. Discussion and conclusions .................................................................................46 7.1 Summary of major findings .........................................................................46 7.2 Conclusions..................................................................................................48
8. References............................................................................................................49
ii
List of Figures Figure 1: Fundamental use case elements.....................................................................7 Figure 2: Simple e-commerce system use case diagram. ............................................16
iii
List of Tables Table 1: HAZOP guide words [68]. ..............................................................................5 Table 2: Example guide word interpretations for timing [68]. .....................................5 Table 3. The interpretations of guide words for an actor............................................12 Table 4. The interpretations of guide words for an association. .................................12 Table 5. The interpretations of the guidewords for a use case....................................13 Table 6: Stakeholders-Interest list. ..............................................................................17 Table 7: Actor-Goal list. ..............................................................................................17 Table 8: Analysis of ‘Browse Catalogue’ use case......................................................25 Table 9: Analysis of ‘Register Customer’ use case. ....................................................32 Table 10: Analysis of ‘Order Goods’ use case. ...........................................................40 Table 11: Analysis of ‘Change Password’ use case. ...................................................43
iv
1. Introduction Computer security is increasingly problematic; threats to systems and the data stored on them grow as computer networking and computer literacy increase. Computers are now an obvious target for the disgruntled employee, the rejected partner, the disenfranchised constituent, and the fraudster. With increased opportunity, attacks become more novel, complex and unpredictable. To make matters worse, the criticality of computer systems is increasing. Many organisations rely on stored data, business or management programs, internet connections and the web/email facilities that the internet supports. Security breaches have the potential to cause dramatic losses of money, confidence, reputation, or even of life. To combat the increased number and severity of security risks, systems development needs to analyse security with particular care and rigour. Security analysis should be an essential part of all computer-related engineering practices. Although security was one of the first domains to embrace formal development techniques and processes, much security analysis remains informal. At the requirements level most analysis is informal; with the increased complexity of emerging systems there is a pressing need to add rigour to the process of engineering security requirements. Some requirements may be expressed as ‘use cases’. This paper investigates the systematic use of a technique from the safety domain (HAZOPs) and shows how it can be applied to use cases to elicit and explore their security aspects. 1.1 Motivation Research in security has emphasized particular aspects of security or technologies required to implement security mechanisms. Confidentiality properties, for example, have been analysed mathematically by many authors and there has been a vast amount of research into cryptography. However, these are only partial solutions to the security problem. Much security research has been sponsored by Governmental organisations and the research tends to reflect Governmental security concerns. Modern systems, over a range of application domains, have security issues. Reaching for pre-defined templates of what were relevant security problems and their solutions will often not suffice. Much more subtlety will be needed to determine in what security for a system should consist and how assurance can be gained that the developed system provides it. It is universally asserted that security must be built-in, but proper integration of security development and analysis processes with the development of the rest of the system is not common. Bolt-on ‘security’ is a frequent approach. One can understand this lack of proper integration. System development is hard enough under benign conditions, let alone in the presence of malice. Attacks may come from all directions, from exploiting radio frequency leakage, through power consumption of a smart card leaking key information, to more social/personnel aspects such as what has recently been described as cognitive hacking [23]. Expertise across the relevant domains is
1
generally not possessed by any one person. Furthermore, for modern complex systems we might question whether ‘expertise’ is really enough. Expertise depends on previous experience. Many modern systems give rise to new security concerns and experts have a hard time coping with novel systems. Commonly used analysis techniques (e.g. checklists/profiles) are too rigid to uncover new threats. Integrating security with the design process is further complicated because developments are usually iterative and so security issues must be addressed iteratively (with all that entails). Furthermore, evolution of systems is a natural part of the lifecycle and presents significant challenges for secure systems. Maintaining rigour under change is hard and expensive; much more so if certification requires externally provided evidence, such as that provided by independent evaluation. The above problems are not unique to security. Safety critical and safety related systems present similar problems, but safety analysis and development would appear more tightly integrated. Part of the reason for this, perhaps, is that the safety domain has developed many simple but effective analysis tools whose results are seen to affect the design process in a significant way. These tools are typically understood by non-safety experts (though their effective use requires skill), allowing various stakeholders to bring their knowledge to bear in the service of safety, or allowing experts to exercise their craft with increased rigour. Might such safety techniques usefully be applied to security? 1.2 Solutions from safety The scale and scope of security risk in modern computer systems requires systematic, rigorous techniques that are part of standard development processes. Techniques applied in the development of safety-critical systems tend to be well-defined and systematic. They have proven effective over many years. Safety and security have many similarities. Both are concerned with the management of risk. Safety typically concerns itself with reducing the risk of loss of life or environmental damage to tolerable levels. Security concerns itself with engineering acceptable levels of risk to various assets (and is most typically concerned with threats to the confidentiality, integrity, and availability of information, and threats to the supporting infrastructure). Development concepts and practices from one domain have found interpretation or direct application in the other. For example, notions of graded assurance were first seen in the security domain; the US DoD’s Trusted Computer Security Evaluation Criteria [65] (a.k.a. the ‘Orange Book’, due to the colour of its cover) required increased functionality and increased rigour in design to cope with various levels of system risk. The concept of graded assurance migrated to the safety domain, where functionality and assurance were separated (and so very simple functionality could be required to have high assurance). This separation of functionality and assurance has been adopted in recent security standards, such as the ‘Common Criteria’ [18]. Formal methods found application in the 1970s and 1980s primarily in security and subsequently became a mainstay of much safety-oriented research. Perhaps the most important similarity is that rigorous arguments are generally required to justify the deployment of safe and secure systems. Systems must be demonstrably safe or secure. In recent years, the notion of a safety case has emerged -
2
a rigorous, well-structured and understandable marshalling of evidence that a system is suitable to be deployed, i.e. is acceptably safe. Safety analysts already have numerous techniques at their disposal for generating and recording evidence and these can be adapted for security assurance evidence. Fault Tree Analysis (FTA) [58] has inspired security Threat Trees [2] and Attack Trees [62]. These approaches systematically decompose goals, representing the findings in a tree structure. MOAT [42] is a security argumentation technique that uses FTA notations to express its assurance arguments. More sophisticated argumentation [57] is available via derivatives of the Goal Structured Notation [39]. Techniques for the investigation of deviations (unintended or unexpected behaviour [59]), developed for safety critical systems, also appear in security work. The abuse case model [53][54] expresses deviation from normal system use by specific actors. This work takes as its starting point use cases, a requirements technique from the Unified Modeling Language (UML) and related development methods. This clearly satisfies the need to integrate security analysis with conventional systems development; UML is increasingly the notation of choice in systems development. However, the technique again focuses on expressing the effect of known security threats; it is not capable of systematically seeking other possible threats. Systematic deviational techniques such as HAZOP [60][68], successfully used in safety critical systems, are little used in security. One doctoral study [31] applies HAZOP to protocol requirements analysis, to systematically investigate unknown threats and attacks on protocols. We propose an extension of abuse cases, providing a more rigorous approach to analysing security. We apply the principles of HAZOP, tailored to a security perspective, to an existing functional requirements representation (i.e. use cases). The approach systematically mutates the model and its elements, thus prompting identification of a wide range of threats and other non-functional requirements. The next section of the report discusses the concept and uses of HAZOP in more detail. Section 3 introduces and elaborates use case. Section 4 outlines the proposed method and the necessary interpretations of HAZOP guidewords. Section 5 provides guidance on the derivation of the use case deviants. Section 6 presents a simple case study of an e-commerce system. The report concludes with a summary of our findings.
3
2. HAZOP: A rigorous approach to security analysis Security analysis must determine cost-effective controls to make a system’s assets secure against credible threats. These threats may include loss of confidentiality, integrity, availability etc. Damage may also include secondary damage, e.g. to reputation. The analysis must explore the vulnerability of the system to these threats, the probability that such vulnerabilities may be exploited to form attacks, and determine the potential impact of attacks. Cost-effective counter-measures are then sought. Clearly, efficient identification of threats is key to the development of secure systems. HAZOP is a technique widely used in safety; it presents a possible approach to systematic security threat identification. 2.1 HAZOP HAZOP is the technique of Hazard and Operability Analysis (HAZOP). It is a qualitative technique, developed by chemical producers to systematically identify potential hazards and operability problems in designs for new chemical plants. Traditional approaches based on checklists and intuition were capable of checking, for example, the effects of a valve not opening or not closing; HAZOP guidewords encouraged other (more subtle) scenarios to be identified, such as the valve being part-open, or sluggish in its opening. A systematic description of the technique applied to safety in computer and other systems is given in [68][60]. The basic principle of HAZOP is that hazards arise due to deviations from normal or intended behaviours. Like identification of systems requirements, HAZOP is best conducted as a team analysis activity, ideally using people with various backgrounds. The team, led by a HAZOP leader, systematically investigates each of the system elements to identify deviations from the design intent. Each of the identified deviants is then further investigated to ascertain possible causes and effects. The identification of deviations is prompted by a set of guidewords/guidephrases, where each related guideword/guidephrase is applied to each attribute. A pipe in a chemical plant might have fluid flow as an attribute. The guideword “NO/NONE” prompts us to consider what would happen if no fluid flowed (for whatever reason). Similarly, for a petrol tank, with attribute content “petrol”, the guide phrase “OTHER THAN” prompts us to consider what would happen if the wrong kind of petrol were present (for example, use of leaded petrol in an engine designed for unleaded fuel might wreck that engine), or fluid other than petrol were used. The technique is flexible. For example, it is possible to apply it to manual or automated procedures. A replacement procedure for an aircraft windscreen might have a step requiring the engineer to fasten the screen with identified bolts. What would happen if the wrong kind (“OTHER THAN”) of bolt were used, or even if the whole step were omitted (“NONE”) for a particular bolt? An aircraft engine maintenance procedure might require the level of oil to be checked in an engine with oil caps being securely replaced after the checks. What would happen if such caps were not replaced (use of ‘NOT’)? 1 1 Accidents have actually arisen with such causes. An aeroplane landed with the pilot unconscious having been half sucked out of the cockpit at 17000 feet having lost the windscreen after replacement.
4
The generic set of guidewords of HAZOP, as incorporated in UK Defence Standard OO-58 [68], is provided in Table 1.
Guidewords Meaning NO or NOT or NONE
None of the design intent is achieved
MORE Quantitative increase in a parameter LESS Quantitative decrease in a parameter AS WELL AS or MORE THAN
An additional activity occurs
PART OF Only some of the design intent is achieved REVERSE Logical opposite of the design intention occurs OTHER THAN Complete substitution. Another activity takes place.
Table 1: HAZOP guide words [68]. A key part of HAZOP analysis is to interpret the guidewords for the context of interest. For example, Table 2 shows variations or interpretations of the guidewords for application to the timing of events or actions.
Guidewords Meaning Interpretation NO
Event/action never takes place.
EARLY Event/action takes place before it is expected.
LATE Event/action takes place after it is expected.
BEFORE Happens before another event or action that is expected to precede it.
Timing of Event or Action
AFTER Happens after another event or action that is expected to come after it.
Table 2: Example guide word interpretations for timing [68]. HAZOP has gained wide acceptance: 00-58 [68] recommends HAZOP for hazard analysis in any safe system development; it has been successfully applied to the safety analysis and operation of chemical plants, aircraft, and many other products. HAZOP has also been applied to the security domain. For example, Foster [31] has applied it to the generation and analysis of security protocols requirements. She stated that protocol development is relatively unstructured and as a consequence can produce protocols vulnerable to attack. The technique prompts the analyst to consider unknown threats and attacks on protocols.
84 out of 90 bolts were of smaller than required diameter. (BAC One Eleven over Oxfordshire 1990) [43]. In another incident, a pilot managed an emergency landing after oil drained out of all engines; one engineer had maintained all four aircraft engines and omitted to replace the oil caps.
5
Winther et. al. [69] has adapted HAZOP guidewords to generate new guidelines specific to security attributes. However, the derived guidewords are too restricted, and are not flexible enough to bring out most of the analysts’ creativity. We have indicated a general approach to applying HAZOPs for security. Specialising the technique for a particular domain allows increased rigour and indeed efficiency.
6
3. Use cases The use case technique, now popularised as part of the UML [61], was proposed by Jacobson [38] to describe behaviours of a system from a user’s perspective. Typically, a use case characterises interactions between an actor (usually a user, but possibly another system) and a system. There is a visual representation, the use case diagram, and a tabular format. Figure 1 depicts the fundamental elements of the use case in diagrammatic form. The actor (a stick-man) interacts (an association line) with a use case (an ellipse).
Controller
Display Flight Path
Actors
AssociationUse Case
Figure 1: Fundamental use case elements. Actors represent external users or other systems that have an interaction or association with the system. An actor characterises the role that users or other external systems may have in relation to the system.
• Actors are everything that needs to exchange information with the system [38]. Human and non-human interaction with the system can be expressed, and actors can represent individual or collective roles.
• Association lines connect an actor with the use case. This represents an interaction (communication) or association between the actor and that use case. The interaction may represent the exchange of information between the actor and the system or the invocation of the system’s operation by the actor and vice versa.
• Use cases represent the system’s behaviour from the external perspective, the task that the system must achieve on behalf of the actor(s) with which it interacts. Different authors document use cases in different ways. In general, the description comprises pre-condition, post-condition and sequences of actions (scenarios) including variants. The pre-condition defines the states that the system must be in for the use case to execute. The post-condition defines the state properties required after executing the use case.
The tabular form of a use case is a text description of how an interaction is accomplished. The different outcomes of a use case can be expressed using scenarios (action steps). There is little agreement as to what should be included in the tables. In UML (and the related methods), use cases are almost always used to capture and express functional and late requirements. They represent the system and its
7
interactions, in a simple form that is easily understood by the different parties involved. In the Unified Process [45], the expression of use cases is the foundation for subsequent development activities, as the captured requirements are fed into the specification and design process. Recent work has applied use case modelling to requirements analyses other than the purely functional. Abuse and misuse cases are proposed as (intuitive) means to capture and analyse security requirements [53][54][63]. Sindre [63] notes that both security and safety requirements can be elicited from use case diagram and scenarios. Douglass [26] shows that use case modelling can be used to document some non-functional requirements, for example, by annotating each action in use case scenarios with its timing constraints. Work by Allenby et. al. [1] on the elicitation and analysis of safety requirements also uses HAZOP on use case scenarios. The analysis results in a tabular form describing the likely catastrophic failures, their causes and effects. Use cases, like abuse or mis-use cases, are potentially useful in the analysis of security requirements. The system interfaces presented to an attacker may be characterised by use cases. The attacker may ‘stay within the rules’ (but do so in a particularly clever way), or may choose to deviate from what is intended as acceptable behaviour. Attacks may often be regarded as ‘exceptional flows’ in a use case. Existing abuse case approaches do not give any systematic way of generating such unusual deviations. In this report we show how HAZOPs can be used to generate alternative or exceptional behaviours in a systematic way. We regard our approach as a useful tool. Since not all system requirements will be recorded as use cases, other analyses have to be carried out too. Though HAZOPs may prove useful in those contexts too, in this report we restrict ourselves only to the analysis of use cases.
8
4. Method procedures and guidelines Our approach starts from system use cases. These might be taken from the initial phase of the system development. In normal usage, the use cases would model only high-level functional requirements. The aim of our approach is to systematically analyse the system to identify potential threats and security requirements. Our technique applies the HAZOP guidewords, with suitable interpretations, to elements of the use case. The elements incorporated are those that could be subject to deviations leading to meaningful results. 4.1 The analysis process The essential steps of the analysis process are as follows.
1. From a use case, identify and record: a. intent and capability of actors; b. associations between actors and use cases; c. components from use case description: pre-condition, main flow of
events, alternative flows of events (i.e. normal but perhaps less likely and exceptional /error flow of events) and post-condition.
2. Apply HAZOP guidewords with the appropriate interpretation to each element
identified in step 1, to suggest deviations.
3. Evaluate whether the identified deviations violate, or could violate, any stated security properties. Investigate possible causes of the deviations.
4. Identify consequences that may arise from the deviations (extract affected
assets from the identified consequences.)
5. Categorise the deviations identified, and generalise each group.
6. Provide recommendations or requirements on the identified problems/threats. 4.2 Use case elements and their security deviations A use case describes a sequence of events, typically expressed by scenarios. Actions are expressed under various conditions, responding to a request from one of the actors that has an association with it. We identify elements that are subject to deviations for each of the main elements of a use case. Actors Each actor possesses different characteristics. Actor roles can be distinguished by their intent and capability. The characteristics determine the deviations that are possible for each actor; the ways in which actors deviate from their normal role may have different impacts on the system. Deviations from the actor’s intent or actions
9
(deviations from goals), whether intentional or accidental, can reveal new threats to the system. Sometimes, new malicious actors are also identified by considering intentional deviation from expected actor behaviour. The deviation of actors needs to take notice of the different potential resources and skills of individuals (or systems) playing the roles represented as actors. For example, a cyber-terrorist network usually has more ability to cause attacks than an individual teenage hacker, in terms of access to resources and skills. In gambling or gaming environments, actors may have differing local computational capabilities. Similarly, most actors will not have supercomputing facilities, but in some cases this may make a difference. Actors may differ in their ability to screen incoming information (e.g. for email viruses). Actors may also differ in the protocols they are able to support etc. A network administrator is able to access many more files or programs than a normal user. For human actors, one person may play different roles in the system and the roles a person may possess can be limited or restricted. For example, the same person is not allowed to both process and approve a payment. The intent of an actor is an interesting concept. An actor may obey all security policy rules and participate in a seemingly innocuous interaction. However, it may be that the real intent is to signal information via a covert channel. Associations An association of the actor with a use case models the external interactions with the system through the functionality modelled in the use case. The significance of restricting access to an operation to a particular group of users (an actor), and of assignment of access controls to a particular user or actor could be highlighted by this part of the analysis. In secure systems, access to functionality depends on actor roles. We need to have a clear idea of which actors should be able to access which use cases for which purposes. Such control may be enforced in several ways. For example, access controls may form an explicit part of the use case (i.e. suitable authorisation checks are made by the system), or else physical access to particular terminals may be restricted to authorised personnel. (Such alternative refinements of system goals are addressed in [56]). Availability is now a security goal for many systems. HAZOP application to associations such as NO association might reveal potential causes such as simple equipment malfunctioning (e.g. a keyboard refusing to acknowledge particular key presses, or else network failure). Inappropriate configuration may also result in associations not being effected. Unintended associations are a particular problem. Use cases record only intended associations. An association represents an actor’s ability to exchange matter or information across some interface. Intentional interactions use identified associations. It is intended that the channels used by the actors are the only relevant ones. However, physics often implements unintended associations. A communications cable may provide a point-to-point channel, but may also emit electromagnetic radiation that can be picked up by a suitably equipped eavesdropper. In a similar vein, an electromagnetic ‘pulse gun’ may seriously harm or even destroy equipment from short range. Electromagnetic interference may also be a problem without any deliberate action. Covert channels can be considered as unintended associations. More
10
generally, consideration of unintended associations points to a need for issues of zonal analysis to be considered [64]. However, at this point we indicate a general opportunity to consider such matters at the use case level (even if only briefly, or to highlight the need for particular analyses later in the development). Several associations may be current for an actor; the actor may indeed engage in parallel instance of the same use case. In on-line gambling, this may allow for instances of collusion. It is possible also that uses cases executed in quick succession may cause problems (e.g. in a distributed cash system it may be possible to carry out a second withdrawal before a central database has processed a successful confirmation of the first, leading to withdrawal limits being exceeded). Use Cases The use case pre- and post-condition both represent states of the system at certain sets of times. Deviations from these normally-reached states causes deviant interactions and could result in exceptions to the flow of events. We can address the variations from the normal behaviour, by considering the deviations of each step in the use case and investigating the causes. 4.3 HAZOP security guidewords Tables 3 to 5 show the interpretations of HAZOP guidewords that we propose for application to the use case elements and their features. In interpreting the guide words some measure of scoping will be needed, for example “OTHER THAN” applied to an action or result could cover a huge number of possibilities. We leave such pragmatic decisions scooping to the analyst.
11
An actor has an action, representing an intent, and a capability, representing the skills and resources at their disposal. Element: Actors Features Guide words Interpretations
NO The action/intent does not take place. MORE More action is achieved. This may be one of the following:
Sequential Repeat – the same actions take place repeatedly. Parallel Repeat - – the same actions take place concurrently. Extreme Intent – some scalar attribute of the action is affected (e.g. extreme parameter values are used in service invocations).
LESS Less action is achieved than intended. The intended actions are incomplete or insufficient.
AS WELL AS As well as the intended or normal action, some unexpected supplementary or contradictory actions occur or are intended.
Action (Intent)
OTHER THAN
The action achieves an incorrect result. Alternatively, the actor may use facilities for purposes other than those intended, i.e. abuse of privilege (some OTHER THAN actions may lead to exceptional scenarios).
NO Lack of the capability to perform the action. MORE More general capability, allowing more to be achieved than intended. LESS Less general capability, allowing less to be achieved than is required. PART OF The actor has only part of, or is missing a specific part of the capability.
Capability
AS WELL AS As well as the specific capabilities required, the actor has other specific capabilities.
Table 3. The interpretations of guide words for an actor.
An association is not considered to have additional features. However, more guide words are appropriate: Element: Association Features Guide words Interpretations
NO Association does not/can not take place. MORE Superfluous – Interface permits greater functionality to a particular actor
than is required. More functionality is available. Association is not constrained as required. Further divisions are: In-parallel with – More functionality is provided/occurs simultaneously with the permitted ones. In- sequence with – More functionality provided/occurs before or after the permitted ones.
LESS Interface permits less functionality to a particular actor than is required. Association is over-constrained.
AS WELL AS Associations to a particular use case take place with other actors as well. REVERSE Interaction takes place in the reverse direction.
Associations
OTHER THAN
Wrong association is defined. Swapping roles – Swapping of associations between actors or individuals.
Table 4. The interpretations of guide words for an association.
Finally, for the use case itself, the temporal guide words are included:
12
Element: Use Case Elements Features Guide words Interpretations
NO The state or condition does not take place or is not detected. AS WELL AS Additional conditions apply. This may mean that more stringent checks
are made, or else a more restrictive state results than is strictly required. Errors of commission might be considered here.
PART OF Only a subset of the required conditions applies. This might for example, result from incomplete checks (e.g. access control checks or integrity checks), by incomplete implementation (a program doesn’t do all it should), or because the consequences of system behaviour are not fully understood.
State (defined in a pre-condition or a post- condition)
OTHER THAN
An incorrect condition applies. Perhaps the wrong data is used.
NO No action takes place. MORE More action is achieved. A stronger post-condition is achieved. More
actions could be carried out: Repeat – the same actions take place repeatedly. Superfluous – the system does different additional actions to those intended or required. A Trojan horse usually implements more functionality than is apparent, for example. Additionally, an action may take place for longer than required.
LESS Less is achieved than intended. A weaker post-condition could result. For example, an action is incomplete, or an action takes place for a shorter time than required, or an action stopped earlier than expected.
Action
OTHER THAN
An incorrect action takes place. An action not intended or required takes place instead. For example, wrong detail is provided or a wrong button is pressed.
LESS Less is achieved than intended. For example, Drop – Miss one or more parts of action. Additionally, a sequence of action takes place for a shorter time than required.
AS WELL AS The sequence does the intended actions plus others. REVERSE The sequence of actions takes place in reverse order (and other out-of-
order concepts). EARLY The action sequence or its components takes place before it is expected
(timing). LATE The action sequence or its components takes place after it is expected
(timing). BEFORE The action sequence or its components happens before another action
that is expected to precede it. AFTER The action sequence or its components happens after another action that
is expected to come after it.
Sequence of Actions (scenarios)
OTHER THAN
An incorrect action sequence takes place.
Table 5. The interpretations of the guidewords for a use case.
13
5. Deriving use case deviants The guidewords alone do not give a clear idea of how to derive deviants from use cases. This section provides additional guidance for performing the use-case-based security analysis, based on experience of applying the technique. Note that, in applying the guidewords, much repetition is expected. Analysts must ensure that any apparent repetition is indeed repetition and not a subtle variation of a previously-identified threat. The derivation of deviants must consider at least the three fundamental security properties (i.e. confidentiality, integrity and availability). The emphasis will vary between applications. The guidance also includes high-level patterns of analysis. Viewpoint considerations/Stakeholders’ interests Stakeholders are individuals or organisations that have an interest in the system, even though they are not a direct part of the system, and may not directly interact with the system. One (partial) definition of a stakeholder is an authority (not a hacker!) that has an authorised ability to cause the system to cease to exist or cease to operate. Each stakeholder in a system has a viewpoint, representing his or her interest in the system. Stakeholders’ interests might be in conflict. Security analysis must take account of different viewpoints, and of the seniority or importance of the stakeholders. For example, some stakeholders are concerned about the integrity of classified information; others may find confidentiality of personal data more important. Deviations from all stakeholder interests should be considered. Role/actor mapping Deviation analysis must consider the possibility of unexpected interactions through shared and multiple roles. A computer system is built to support the roles of humans or of machines. An actor characterises the role that the users or other external systems play in relation to the computer system. Individuals within roles are not distinguished, and an individual may play different roles at different times. A multi-user role always has potential deviations in which the actual user within a role initiating some interaction is not the same as the actual user receiving a response. The use case definition of actors and roles may be confused, allowing individuals to operate outside their intended or authorised roles.
14
Business Rules A business rule defines a business aspects or constraint on a system. It consists of policy, some constraints and a validation audit. The business rule influences the way that the interactions with the system are specified. Business rules should include statements of the required security policy (e.g. auditing, integrity or confidentiality of data). However, in practice, security policies are at best implicit. The use case analysis helps to make explicit the security policy, and the system requirements must then be modified so that the functional requirements respect these policies. When deriving the deviations, it is essential to consider what sort of business rules the system does or should enforce. Well-known sources of security violations Although the systematic HAZOP approach is a significant improvement on earlier intuitive analyses, it is important not to ignore or neglect the “checklists” of accumulated wisdom in security. Three common sources of security violation are timing, HCI, and presentation.
• Timing information is not always explicit in use case diagrams and descriptions. However, whenever timing may be associated with events or actions, timing deviations must be taken into account. Typically, timing issues include response time (time between input to output) and repetition time (time between successive updates or outputs). Deviations from timing are events that occur later, earlier, sooner or longer than expected. In terms of security, this may leak information or encourage odd or unfortunate user actions. • Poor HCI design, for example implicit system response or lack of acknowledgement message, may be misleading to users of a system. Security problems may also arise if the HCI functions overload the system, or if the users cannot understand how to use the system as intended. Use case analysis occurs too early in development to include a detailed study of the HCI and its security implications. However, the consideration of known HCI pitfalls may help to identify security “anti-requirement”: things that the system must not do if it is to be acceptably secure.
• Presentation issues include the way in which data is presented to users by a system. For example, intent and actions may be influenced by the order or format of data listed on the screen. Essentially, presentation is part of the conversion of data into information; varying the presentation changes the information that a user can extract. The most obvious security pitfall is perhaps inference. However, there are many more subtle presentational effects to be considered when deriving deviations.
15
6. Example application This section presents a simple case study. The use cases describing an apparently-innocuous web-ordering system are analysed to systematically reveal threats. 6.1 System description A website hosts a company’s product catalogue that anyone using the internet can access and browse. A customer who are registered with the company can order goods via the website. To order goods, the registered customer must provide sufficient payment and delivery detail. If customers who are not registered but wish to purchase, the ordering facility provides an initial registration procedure. Orders are processed by an operator, who logs on to the host system. The operator may change his/her login password when required. The use case diagram is shown in Figure 2.
Customer
E-Commerce System
Operator
Browse catalog
Register customer
Order goods
Change password
Figure 2: Simple e-commerce system use case diagram. Table 6 lists the stakeholders in the web ordering system.
16
Stakeholders-Interests list Stakeholders Interest Company owner Profits and reputation of the company System manager System’s performance and operation of
staff. Developer Correct operation of the program.
Table 6: Stakeholders-Interest list. Table 7 summarises the intents of the use case actors. Actor-Goal list Actor Goal Customer Browse catalogue Register Order goods Operator Process order goods
Table 7: Actor-Goal list.
Use Case Descriptions The following descriptions elaborate each use case in Figure 2. Use case name: Browse Catalogue Goal: To explore the lists of goods available from the system. Actor(s): Customer Preconditions: The customer has access to the internet. Main flow of events:
1. The customer enters the e-commerce website. 2. The customer selects the Browse Catalogue section. 3. The system displays lists of products to the customer. 4. The customer browses the catalogue for a particular product. 5. The customer finds the product.
Alternate flows: User cannot find product he/she wanted. Use case ends. Post conditions: The product is found. Use case name: Register customer Goal: To register a customer identity with the system. Actor(s): Customer Preconditions: The customer has access to the website.
The customer has not registered before. Main flow of events:
1. The customer enters the Register Customer section. 2. The system displays the new customer registration form. 3. The customer provides registration details. 4. The customer submits the registration form. 5. The system updates its registration data information.
Alternate flows: The customer has already registered. Use case ends. Post conditions: The customer is registered and the details are saved to a database.
17
Use case name: Order goods Goal: To order goods from the system. Actor(s): Customer
Operator Preconditions: The customer is registered to order goods.
The customer has entered registration details e.g. user name and password (the customer is logged on to the ordering section).
Main flow of events:
1. The customer enters Order Goods section. 2. The system displays the customer’s account detail. 3. For each product that the customer wishes to order, the customer
enters its identity. 4. The customer provides delivery details. 5. The system calculates and displays the price of the goods
ordered. 6. The customer submits payment details. 7. The system confirms the result of transaction. 8. The operator collects the detail of the order. 9. The operator processes the order.
Alternate flows: Post conditions: The order and its detail are entered on the system and the order is
processed. Use case name: Change Password Goal: Change the password for the login Actor(s): Operator Preconditions: The operator is logged in. Main flow of events:
1. The operator enters his/her current password 2. The system validates the password. 3. The operator enters a new password, twice, as prompted by the
system. 4. The operator confirms the change. 5. The system saves the new password.
Alternate flows: A1. If the operator’s old password is incorrect, an error message should be displayed and the password should not be changed. A2. If the two entries of the new passwords do not match, the operator is prompted to re-enter them.
Post conditions: The password of the operator is changed and updated in the database.
6.2 Analysis The use case descriptions document functional requirements for the e-commerce system, capturing the interactions between the actors and the system. From the use cases and their descriptions, we can identify the actors’ intents (these can be taken from the actor-goal list), actors’ capabilities, associations of customer and operator with the use cases, the preconditions and post conditions of the use case, and a sequence of events of order goods. Each of the elements and features is subject to deviation. Table 8 to Table 11 show the analysis results for the system.
18
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
U
se C
ase:
Bro
wse
Cat
alog
ue
Act
or
Cus
tom
er’s
A
ctio
n –
Brow
se C
atal
ogue
N
ot R
elev
ant
NO
– C
usto
mer
doe
s no
t ha
ve
the
abili
ty
to
brow
se th
e ca
talo
gue.
• Ph
ysic
al
– la
ck
of
com
pute
r sy
stem
, la
ck
of
acce
ss to
inte
rnet
•
Kno
wle
dge
- do
es n
ot
know
th
e w
ebsi
te,
no
know
ledg
e of
us
ing
an
inte
rnet
syst
em.
The
syst
em m
isse
s op
portu
nity
fo
r one
pot
entia
l cus
tom
er.
• St
eal c
ompu
ter s
et
• B
lock
in
tern
et
acco
unt
• Pr
ovid
e w
rong
in
fo
abou
t the
web
site
. •
Mod
ify w
ebsi
te U
RL
MO
RE
– C
usto
mer
has
m
ore
abili
ty
than
re
quire
d.
• A
cces
s hid
den
links
. A
cces
s of
un
wan
ted/
conf
iden
tial i
nfor
mat
ion.
Any
co
nfid
entia
lda
ta
mus
t no
t be
m
ade
avai
labl
e fo
r pu
blic
acc
ess.
Cus
tom
er’s
Cap
abili
ty –
Br
owse
Cat
alog
ue
LE
SS –
Cus
tom
er d
oes
not h
ave
muc
h ab
ility
. •
Phys
ical
–
lack
of
ap
prop
riate
co
mpu
ter
syst
em,
lack
of
acce
ss t
o in
tern
et
Th
e sy
stem
mis
ses
oppo
rtuni
ty
for o
ne p
oten
tial c
usto
mer
.
• K
now
ledg
e -
does
not
kn
ow
the
web
site
, no
kn
owle
dge
of
usin
g an
in
tern
et sy
stem
.
• St
eal c
ompu
ter s
et
• B
lock
inte
rnet
acc
ess
Tim
eout
s m
ay
com
e in
to fo
rce.
Ass
ocia
tions
A
ssoc
iatio
n -
Cus
tom
er
and
Brow
se C
atal
ogue
N
O –
Cus
tom
er d
oes
not
have
as
soci
atio
n w
ith
Bro
wse
C
atal
ogue
us
e ca
se.
Sam
e as
NO
in
Cus
tom
er’s
C
apab
ility
19
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R T
HA
N –
Oth
er
peop
le
can
brow
se
the
cata
logu
e.
Not
of
se
curit
y re
leva
nce,
an
y pe
rson
is
le
gitim
ate
to
brow
se th
e ca
talo
gue.
Use
Cas
e E
lem
ents
Pr
e-co
nditi
on
- Th
e cu
stom
er h
as a
cces
s to
th
e in
tern
et
NO
-
The
cust
omer
ca
nnot
ac
cess
to
th
e in
tern
et.
• Lo
ss
of
netw
ork
and
othe
r phy
sica
l equ
ipm
ent.
• In
tern
et
acco
unt
expi
res.
•
The
syst
em
mis
ses
oppo
rtuni
ty
for
one
pote
ntia
l cu
stom
er.
• IS
P no
t ava
ilabl
e •
Wro
ng c
onfig
urat
ion
of
netw
ork.
• C
usto
mer
’s fr
ustra
tion
Den
ial-o
f-se
rvic
e
Stric
tly,
this
is
a
prob
lem
fo
r th
e cu
stom
er.
Can
m
ake
serv
er s
ide
as
flexi
ble
as p
ossi
ble.
NO
–
The
cust
omer
ca
nnot
ent
er t
he s
yste
m
web
site
.
• Th
e e-
com
mer
ce s
erve
r is
dow
n (o
r m
alfu
nctio
ning
in
som
e w
ay).
• Lo
ss o
f net
wor
k.
• Th
e sy
stem
is
bloc
ked/
over
load
ed
• C
usto
mer
m
ay
get
bore
d an
d m
ay n
ot w
ant t
o ac
cess
the
site
aga
in.
• Lo
cal e
rror
• C
usto
mer
dis
appo
intm
ent.
• B
lock
syst
em.
• In
terc
eptio
n of
al
l in
fo p
asse
d •
Den
ial-o
f-se
rvic
e at
tack
St
ep
1-
The
cust
omer
en
ters
th
e e-
com
mer
ce
web
site
.
MO
RE
– ap
plie
d to
cu
stom
er.
Mor
ecu
stom
ers
ente
r th
e w
eb
site
.
•
Poss
ibly
le
gitim
ate
acce
ss b
y m
any
inte
rest
ed
user
s.
• Se
rvic
e m
ay
be
seve
rely
im
pede
d.
Use
r br
owsi
ng
sess
ions
may
be
very
slo
w o
r el
se n
ot a
ccep
ted.
•
Mas
sive
si
mul
ated
requ
ests
to e
nter
the
site
by
mal
icio
us p
roce
sses
.
• In
adve
rtent
or
delib
erat
e ov
erlo
adin
g of
sy
stem
(de
nial
of
serv
ice
atta
ck)
Th
is is
tric
ky. W
e co
uld
mak
e br
owsi
ng su
bjec
t to
log
on (u
nusu
al).
We
coul
d m
onito
r re
ques
ts fo
r sig
ns
of a
ctua
l use
r be
havi
our (
rath
er
than
pro
gram
bas
ed
requ
ests
of a
m
alic
ious
age
nt)
20
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R
TH
AN
–
the
cust
omer
at
tem
pts
to
ente
r th
e in
dica
ted
web
si
te
but
is
dire
cted
to
an
othe
r (p
ossi
bly
spoo
f of
the
orig
inal
)
• M
alic
ious
ha
ndlin
g at
lo
cal h
ost.
• D
omai
n sq
uatti
ng
on
addr
esse
s alo
ng th
e pa
th.
• U
se o
f si
mila
r na
mes
fo
r co
mpa
ny,
lead
ing
to
cust
omer
s be
ing
mis
led
(e.g
. vi
a se
arch
en
gine
re
turn
s).
• G
oes
to
wro
ng
site
ge
nera
lly.
Cus
tom
er i
s si
mpl
y en
gagi
ng in
a s
poof
ed o
r pla
inly
w
rong
int
erac
tion
with
obv
ious
co
nseq
uenc
es.
• Sp
oofe
d si
tes
have
obv
ious
pr
oble
ms.
Rep
utat
ion
of
com
pany
m
ay
(wro
ngly
) be
ta
rnis
hed.
Man
ipul
atio
n of
hos
t or
ro
utin
g
Be
on l
ooko
ut f
or
atte
mpt
ed
infr
inge
men
ts
of
nam
e.
Sear
ch
for
links
w
ith s
imila
r na
mes
to
th
at
of
the
com
pany
.
NO
–
The
cust
omer
nn
ot
ente
r to
th
e io
n.
ca sect
• Li
nk is
not
ava
ilabl
e •
Fire
wal
l •
Link
is
av
aila
ble
but
ther
e ha
s be
en
deni
al
of
serv
ice
• C
usto
mer
’s d
isap
poin
tmen
t •
Cus
tom
er
may
ge
t bo
red
and
may
not
wan
t to
acce
ss th
e si
te a
gain
.
Fabr
icat
ion
of w
ebsi
te
St
ep
2-
The
cust
omer
en
ters
to
Br
owse
C
atal
ogue
sect
ion.
OT
HE
R T
HA
N –
The
cu
stom
er e
nter
s a
sect
ion
othe
r tha
n B
row
se.
• In
tern
al e
rror
on
web
si
te.
• C
omm
unic
atio
ns
are
alte
red
in t
rans
it to
ref
lect
di
ffer
ent
requ
est
(but
to
sa
me
web
site
).
Var
ious
–
rang
ing
from
an
noya
nce
and
bew
ilder
men
t th
roug
h to
acc
essi
ng s
ensi
tive
info
rmat
ion
the
cust
omer
sh
ould
n’t.
• La
rgel
y in
tern
al
syst
em in
cons
iste
ncy.
•
Man
ipul
atio
n of
co
mm
unic
atio
ns.
Step
3-
Th
e sy
stem
di
spla
ys l
ists
of
prod
ucts
to
the
cust
omer
.
NO
– T
he s
yste
m w
as
unab
le
to
disp
lay
the
prod
ucts
.
• Th
e se
rver
is
dow
n (o
r pa
rt of
sys
tem
is
dow
n if
dist
ribut
ed se
rver
). •
The
syst
em is
blo
cked
. •
Bro
wse
r mis
mat
ches
. •
Erro
r in
data
base
.
Cus
tom
er’s
ann
oyan
ce
Plus
, the
com
pany
is n
ot a
ble
to
adve
rtise
any
pro
duct
s.
• B
lock
syst
em
• V
irus/
hack
ing
Ther
e m
ay b
e go
od
lega
l rea
sons
why
th
is is
shou
ld b
e th
e ca
se!
Is th
ere
mat
eria
l whi
ch
shou
ld h
ave
age
limit
impo
sed?
21
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
MO
RE
–
The
syst
em
show
s m
ore
than
the
lists
of
pr
oduc
ts
than
it
is
supp
osed
to.
• St
aff m
ista
ke.
• D
ata
(sta
tus
e.g.
sa
le/n
ot y
et o
n sa
le)
of t
he
asso
ciat
ed
prod
uct
is
inco
rrec
t. •
Add
ed
prod
uct
from
th
e ou
tsid
er (
e.g.
adv
ertis
e on
this
web
site
) •
Sear
ch
filte
rs
not
wor
king
app
ropr
iate
ly.
• D
ata
rele
ase
may
ha
ve
unfo
rtuna
te e
ffec
ts:
prod
uct
not
on s
ale
is b
eing
dis
play
ed,
and
will
bec
ome
unav
aila
ble
whe
n th
e cu
stom
er o
rder
s it,
lea
ding
to
cu
stom
er
diss
atis
fact
ion.
Pr
oduc
t dis
play
ed w
ith o
ld p
rice
and
old
deta
il,
whi
ch
the
com
pany
nee
ds t
o se
ll at
the
pr
ice
it ad
verti
ses.
The
orga
nisa
tion’
s re
puta
tion
is
effe
cted
if th
e pr
oduc
t on
sale
is
not
suita
ble
or
illeg
al.
Ove
rload
ing
with
irr
elev
ant
info
rmat
ion.
• M
odifi
catio
n of
mes
sage
(c
omm
unic
atio
n ch
anne
l).
This
real
ly
illus
trate
s the
im
porta
nce
of
havi
ng a
ccur
ate
info
rmat
ion
on a
w
eb-s
ite. T
here
are
al
l man
ner o
f co
mm
erci
al /l
egal
re
ason
s to
do so
.
• M
odifi
catio
n of
web
site
(file
). •
Mod
ifica
tion
of
the
stor
age
files
of p
rodu
ct.
Wha
t exa
ctly
is
mea
nt b
y “i
s su
ppos
ed to
”? A
re
ther
e le
gal
cons
train
ts o
n w
hat
shou
ld b
e di
spla
yed?
Ill
ustra
tes n
eed
to
enfo
rce
sale
s po
licy
with
in th
e la
w. T
his h
as
impl
icat
ions
for t
he
deta
ils w
e st
ore
with
act
ual
cust
omer
s.
22
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
L
ESS
–
The
syst
em
show
s lis
ts o
f pr
oduc
ts
less
tha
n it
is s
uppo
sed
to.
• St
aff m
ista
ke.
• D
ata
(sta
tus
e.g.
sa
le/n
ot y
et o
n sa
le)
of t
he
asso
ciat
ed
prod
uct
is
inco
rrec
t. •
Out
side
r’s f
abric
atio
n •
Cor
rupt
ion
of m
essa
ge
pass
ing.
• Su
pplie
r’s f
rust
ratio
n •
Lose
the
oppo
rtuni
ty to
sel
l a
parti
cula
r pro
duct
.
• M
odifi
catio
n of
mes
sage
(c
omm
unic
atio
n ch
anne
l).
Beg
s the
que
stio
n as
to h
ow li
sts a
re
requ
este
d. A
t thi
s st
age
it is
not
stat
ed
whe
ther
this
is
sim
ply
by
hype
rlink
s or e
lse
by se
arch
crit
eria
.
• M
odifi
catio
n of
web
site
(file
). •
Mod
ifica
tion
of
the
stor
age
files
of p
rodu
ct.
RE
VE
RSE
–
The
syst
em
show
s lis
ts
of
prod
uct
in a
rev
erse
or
unus
ual o
rder
.
• Po
ssib
le
man
ipul
atio
n of
co
mm
unic
atio
ns
but
prin
cipa
l ca
use
is
sim
ply
delib
erat
e ac
tion
serv
er
side
.
• A
di
ffer
ent
(incl
udin
g re
vers
e or
der)
m
ay
influ
ence
se
lect
ion
to b
uy.
• M
alic
ious
se
rver
man
agem
ent/d
evel
opm
ent
.
Ps
ycho
logi
cal
issu
es m
ust b
e ta
ken
into
co
nsid
erat
ion.
Who
ar
e th
e cu
stom
ers
who
hav
e pr
oduc
ts
here
– a
re so
me
bein
g fa
vour
ed?
Can
we
mak
e m
oney
ope
nly
from
th
is?
Not
e –
som
e pr
oduc
ers m
ay
actu
ally
pay
to
appe
ar o
n a
web
si
te.
OT
HE
R T
HA
N –
The
sy
stem
sho
ws
som
ethi
ng
else
or
in
corr
ect
data
as
soci
ated
with
pro
duct
s.
• O
utsi
der’
s fab
ricat
ion
• R
epla
cem
ent o
r red
irect
to
ot
her
fake
w
ebsi
te
to
obta
in
cust
omer
’sin
form
atio
n.
• C
usto
mer
may
be
mis
led
by
erro
neou
s da
ta.
The
serv
er
man
agem
ent
may
be
le
gally
ob
liged
to s
ell a
t wha
teve
r pric
e w
as a
dver
tised
for e
xam
ple.
•
Page
no
t av
aila
ble
(inte
rnal
mis
conf
igur
atio
n).
• In
tern
al
serv
erda
ta/c
onfig
urat
ion
erro
rs.
• C
usto
mer
’s d
isap
poin
tmen
t to
see
wha
t is n
ot e
xpec
ted.
• Fa
bric
atio
n of
w
ebsi
te
• M
an-in
-the-
mid
dle
atta
ck
• In
com
pete
nce
inte
rfac
e de
sign
(thr
eat).
•
Inte
rnal
con
figur
atio
n m
anag
emen
t err
or
(acc
iden
tal o
r del
iber
ate)
.
Nee
d co
ntro
lled
acce
ss to
co
mm
erci
ally
se
nsiti
ve
info
rmat
ion
on
serv
er d
atab
ase.
W
hole
new
set o
f us
e ca
ses
(req
uire
men
ts)
need
ed.
23
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
AS
WE
LL
AS
– de
tails
ar
e su
pplie
d to
cus
tom
er
but a
lso
to a
third
par
ty.
• C
omm
s mon
itorin
g •
Prof
iling
act
iviti
es
serv
er si
de.
• Po
ssib
le b
reac
h of
priv
acy.
Pa
ssiv
e m
onito
ring
on th
e ne
t. A
ctiv
e m
onito
ring
by
serv
er (w
ithou
t kn
owle
dge
of c
usto
mer
)
Wha
t is t
he p
olic
y on
priv
acy?
Mos
t lik
ely
issu
e he
re is
th
e st
orin
g of
pr
ofile
dat
a. W
hat
are
lega
l iss
ues?
St
ep
4–
The
cust
omer
br
owse
s th
e ca
talo
gue
for a
par
ticul
ar p
rodu
ct.
NO
– N
/A
NO
–
The
cust
omer
ca
nnot
fin
d th
e pr
oduc
t he
or s
he is
look
ing
for.
• Th
e pr
oduc
t is
no
t av
aila
ble
with
in t
he s
yste
m
(nor
mal
cas
e).
• In
form
atio
n of
th
e pr
oduc
t was
tam
pere
d w
ith.
• Pa
cket
w
as
corr
upte
d/or
man
ipul
ated
. •
Info
rmat
ion
sent
is
not
com
plet
e •
Mis
mat
ch
sear
ch
crite
ria
• Lo
se th
e op
portu
nity
to s
ell
a pa
rticu
lar p
rodu
ct.
• C
usto
mer
dis
satis
fact
ion.
• M
odifi
catio
n (c
orru
ptio
n)
of
mes
sage
(c
omm
unic
atio
n ch
anne
l).
• M
odifi
catio
n of
w
ebsi
te (f
ile).
• M
odifi
catio
n of
th
e st
orag
e fil
es o
f pro
duct
.
Prov
ide
sear
ch
resu
lts
on
sim
ilar
sear
ched
wor
ds.
Step
5 –
The
cus
tom
er
finds
the
prod
uct.
OT
HE
R T
HA
N –
The
cu
stom
er m
ista
kes
som
e ot
her
prod
ucts
fo
r th
e pr
oduc
t loo
king
for.
• U
ncle
ar d
escr
iptio
n of
th
e pr
oduc
t •
Tric
k th
e cu
stom
er i
n ch
oosi
ng
som
ethi
ngdi
ffer
ent.
•
The
com
pany
mus
t do
mor
e w
ork
if th
e pr
oduc
t if
retu
rned
an
d re
fund
requ
este
d.
•
• C
usto
mer
’s
frus
tratio
nw
hen
rece
ive
prod
uct
that
was
no
t int
entio
nally
ord
ered
for.
D
istra
ctio
n/m
anip
ulat
ing
the
cust
omer
So
met
hing
of
an
H
CI
issu
e. N
eed
to
cons
ider
inte
rfac
e.
24
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
Po
st-c
ondi
tion
– Th
e pr
oduc
t/s is
foun
d.
NO
– T
he p
rodu
ct is
not
fo
und.
•
The
prod
uct
is
not
avai
labl
e w
ithin
the
sys
tem
(n
orm
al c
ase)
. •
Info
rmat
ion
of
the
prod
uct w
as ta
mpe
red
with
. •
Pack
et
was
co
rrup
ted/
or m
anip
ulat
ed.
• In
form
atio
n se
nt i
s no
t co
mpl
ete
• M
ism
atch
se
arch
cr
iteria
• Lo
se th
e op
portu
nity
to s
ell
a pa
rticu
lar p
rodu
ct.
• C
usto
mer
dis
satis
fact
ion.
• M
odifi
catio
n (c
orru
ptio
n)
of
mes
sage
(c
omm
unic
atio
n ch
anne
l).
• M
odifi
catio
n of
w
ebsi
te (f
ile).
• M
odifi
catio
n of
th
e st
orag
e fil
es o
f pro
duct
.
Tabl
e 8:
Ana
lysi
s of ‘
Brow
se C
atal
ogue
’ use
cas
e.
25
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
U
se C
ase:
Reg
iste
r cu
stom
er
Act
or
NO
– R
egis
ter a
ctio
n di
d no
t ta
ke
plac
e.
Fail
to
regi
ster
.
• In
terc
eptio
n by
an
in
trude
r •
Loss
of
netw
ork/
serv
er
is d
own
• C
usto
mer
do
es
not
com
plet
e th
e re
gist
ratio
n by
ac
cide
nt.
• D
eclin
e re
gist
ratio
n
• C
usto
mer
loss
es tr
ust i
n th
e co
mpa
ny,
if he
ha
s al
read
y su
bmitt
ed th
e de
tail
but w
as n
ot
upda
ted.
•
Nee
d to
regi
ster
aga
in.
Inte
rcep
tion
of
mes
sage
pa
ssed
thro
ugh
netw
ork.
Th
is c
an m
ake
the
cust
omer
los
e tru
st
in
the
com
pany
’s
over
all
serv
ice
and
mig
ht n
ot w
ant
to
do m
ore
impo
rtant
se
rvic
e (e
.g.
purc
hasi
ng
the
prod
ucts
) w
ith t
he
com
pany
. M
OR
E
– R
egis
ter
cust
omer
m
ore
than
re
quire
d.
• R
epea
ted
regi
stra
tions
(in
tent
iona
lly).
• D
uplic
ated
or
repl
ayed
of
the
mes
sage
. •
The
syst
em m
ight
not
al
low
to
chan
ge d
etai
l, so
re
gist
er a
gain
with
diff
eren
t de
tail.
• In
crea
se w
ork
load
to
the
syst
em,
and
may
res
ult
in t
he
unav
aila
bilit
y of
the
serv
ice.
•
Blo
ck
othe
rco
mm
unic
atio
ns
with
th
e sy
stem
.
• R
epea
ted
regi
stra
tion
(Flo
od sy
stem
).
• Ta
ke a
dvan
tage
of “
one
per
cust
omer
” of
fers
.
• R
epla
y of
mes
sage
. Sh
ould
al
low
cu
stom
er to
cha
nge
deta
il af
ter
regi
stra
tion.
LE
SS –
N/A
Cus
tom
er’s
ac
tion
– Re
gist
er c
usto
mer
OT
HE
R
TH
AN
–
Reg
iste
r so
meo
ne
othe
r th
an o
nese
lf.
• Ph
anto
m
user
regi
stra
tion.
Wro
ng
user
in
form
atio
n re
ceiv
ed, r
esul
ting
in in
accu
rate
da
ta g
athe
red
(e.g
. nu
mbe
r of
cu
stom
er
inte
rest
ed
in
the
prod
uct)
• C
usto
mer
pr
ovid
esw
rong
info
rmat
ion
deta
il •
Cus
tom
er
regi
ster
s on
be
half
of o
ther
per
son.
•
Cus
tom
er
uses
ot
her
pers
on’s
det
ail (
stea
l inf
o).
Obt
ain
othe
r pe
rson
’s
deta
il.
This
ra
ises
th
e is
sues
w
heth
er
phan
tom
use
rs a
re
of c
once
rn o
r no
t. W
ill i
t af
fect
any
of
fers
or b
enef
its?
26
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
N
O –
Cus
tom
er d
oes
not
have
ab
ility
to
re
gist
er
cust
omer
.
• Ph
ysic
al
–los
sco
nnec
tion.
Not
be
able
to p
roce
ss a
ny o
rder
fr
om th
e w
eb-s
ite.
• D
oes
not
have
re
gist
ratio
n in
form
atio
n.
• C
onfu
sion
in
w
hat
info
rmat
ion
to fi
ll in
.
Th
is is
the
prob
lem
of
the
cus
tom
er t
o pr
ovid
e su
ffic
ient
in
form
atio
n.
The
syst
em
coul
d pr
ompt
re
quire
d fie
lds
to b
e fil
led
in,
leav
ing
othe
rs
as o
ptio
nal.
MO
RE
– C
usto
mer
has
m
ore
abili
ty t
o re
gist
er.
(Reg
iste
r us
ing
diff
eren
t id
entit
ies o
r add
ress
es)
• D
evia
te
som
e de
tails
su
ch a
s nam
es o
r add
ress
es.
• Sw
ap
plac
es
of
surn
ame
and
give
n na
me.
•
Diff
eren
t ph
onet
icsp
ellin
gs
of
non-
Engl
ish
nam
es.
•
Prof
it lo
ss fo
r the
com
pany
• Th
e cu
stom
er
can
take
ad
vant
age
of ‘o
ne-p
er-c
usto
mer
’ of
fers
or
‘o
ne-p
er-h
ouse
hold
’ of
fers
.
Frau
dule
nt
mul
tiple
regi
stra
tions
.
Ther
e is
a p
ossi
ble
need
to
dete
ct a
nd
deal
w
ith
frau
dule
nt m
ultip
le
regi
stra
tion.
Cus
tom
er’s
cap
abili
ty –
Re
gist
er c
usto
mer
LE
SS
– C
usto
mer
ha
s le
ss a
bilit
y to
regi
ster
. D
uplic
ate
of n
ames
in
the
data
base
. •
Cus
tom
er d
isap
poin
tmen
t •
The
com
pany
lo
ses
one
pote
ntia
l cus
tom
er.
Th
is i
s an
iss
ue t
o be
fu
rther
di
scus
sed
on
how
to
di
stin
guis
h pe
ople
hav
ing
the
sam
e na
mes
(p
ossi
bly
usin
g em
ails
). A
ssoc
iatio
n N
O –
Ass
ocia
tion
with
th
e pa
rticu
lar
cust
omer
do
es n
ot ta
ke p
lace
.
• C
onne
ctio
n is
blo
cked
. •
• C
usto
mer
dis
appo
intm
ent
• Th
e co
mpa
ny
lose
s on
e po
tent
ial c
usto
mer
.
Blo
ck c
onne
ctio
n Fl
ood
syst
em
NO
– A
ssoc
iatio
ns w
ith
the
cust
omer
s do
not
take
pl
ace.
• Lo
ss
of
netw
ork
and
othe
r phy
sica
l equ
ipm
ent.
• Se
rver
is d
own
• C
usto
mer
dis
appo
intm
ent
• Th
e co
mpa
ny
lose
s po
tent
ial c
usto
mer
s.
Blo
ck c
onne
ctio
n Fl
ood
syst
em
Viru
s/ha
ckin
g
MO
RE
– N
/A
N/A
Ass
ocia
tion
- C
usto
mer
an
d Re
gist
er C
usto
mer
LE
SS –
N/A
N
/A
27
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R
TH
AN
–
Ass
ocia
tion
with
ot
hers
(e
.g.
cust
omer
/or
to
an
oper
ator
/or
to
an
intru
der)
Nor
mal
ope
ratio
n (a
ny b
ody
can
regi
ster
)
Th
is
rais
es
issu
es
on
regi
stra
tion
polic
y.
Can
a
com
pany
w
orke
r be
a
pote
ntia
l cu
stom
er?
Use
Cas
e E
lem
ent
NO
–
The
cust
omer
ca
nnot
en
ter
to
the
Reg
iste
r C
usto
mer
sect
ion.
• Th
e w
eb
page
is
co
rrup
ted/
rem
oved
.
• Li
nk is
not
ava
ilabl
e •
Cus
tom
er d
isap
poin
tmen
t. •
Cus
tom
er
may
ge
t bo
red
and
may
not
wan
t to
acce
ss th
e si
te a
gain
.
Fabr
icat
ion
of w
ebsi
te
MO
RE
– T
he c
usto
mer
en
ters
to th
e se
ctio
n m
ore
than
onc
e.
Kee
p re
fres
hing
or
load
ing
the
sam
e pa
ge.
Not
a p
robl
em.
LE
SS –
N/A
Step
1 –
The
cus
tom
er
ente
rs
to
the
Regi
ster
C
usto
mer
sect
ion.
OT
HE
R T
HA
N –
The
cu
stom
er e
nter
s to
som
e ot
her
sect
ion
rath
er t
han
the
Reg
iste
r C
usto
mer
se
ctio
n.
• Th
e pa
ge w
as r
epla
ced
by a
n in
trude
r. •
Inco
rrec
t co
nfig
urat
ion/
upda
te
(acc
iden
tally
or
mal
icio
usly
)
• C
usto
mer
’s c
onfu
sion
•
Com
pany
’s re
puta
tion
• C
onfid
entia
l de
tails
can
be
reve
aled
ou
t, if
the
cust
omer
fil
ls i
n th
e fo
rm w
hich
tho
ught
to
be
auth
entic
.
• M
odifi
catio
n of
w
ebsi
te (f
ile).
• M
odifi
catio
n of
th
e st
orag
e fil
es o
f pro
duct
.
NO
–Th
e ne
w c
usto
mer
is
tratio
n fo
rm i
s no
t sp
laye
d.
reg
di
• Se
rver
is d
own
• In
terc
eptio
n by
intru
der
• W
rong
co
nfig
urat
ion/
na
min
g.
• C
ompa
ny lo
ses
oppo
rtuni
ty
for n
ew p
oten
tial c
usto
mer
. •
Cus
tom
er
cann
ot
regi
ster
le
adin
g to
cu
stom
er
diss
atis
fact
ion.
Inte
rcep
tion
Step
2
– Th
e sy
stem
di
spla
ys
the
new
cu
stom
er
regi
stra
tion
form
.
MO
RE
–
Mor
ein
form
atio
n is
dis
play
ed
than
inte
nt o
n th
e fo
rm.
•
Wro
ng fo
rm is
di
spla
yed
• C
onfid
entia
l dat
a is
di
spla
yed
• C
usto
mer
’s c
onfu
sion
•
Con
fiden
tial
data
ca
n be
se
en b
y ot
her p
eopl
e pa
ssin
g by
th
e m
onito
r dis
play
.
Fabr
icat
ion
of w
eb-s
ite.
Onl
y su
ffic
ient
in
form
atio
n sh
ould
be
dis
play
ed.
28
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
L
ESS
– In
com
plet
e fo
rm
is d
ispl
ayed
. •
Inte
rcep
tion
• W
rong
fo
rm
isdi
spla
yed
•
Insu
ffic
ient
in
form
atio
n re
ceiv
ed, m
ay b
e us
eles
s or d
rop
out
from
th
e re
gist
ratio
n re
sulti
ng
in
cust
omer
’sdi
ssat
isfa
ctio
n.
• U
naut
horis
ed
mod
ifica
tion
of
rela
ted
files
• W
rong
inf
orm
atio
n is
kep
t in
the
syst
em.
• In
terc
eptio
n En
ough
in
form
atio
n sh
ould
be
dis
play
ed.
OT
HE
R T
HA
N –
Oth
er
form
is d
ispl
ayed
•
The
page
was
rep
lace
d by
an
intru
der.
• R
edire
ct t
o a
phan
tom
w
eb p
age.
•
Mis
take
mad
e by
staf
f
• C
usto
mer
’s c
onfu
sion
•
Com
pany
’s re
puta
tion
• C
onfid
entia
l de
tails
can
be
reve
aled
ou
t, if
the
cust
omer
fil
ls i
n th
e fo
rm w
hich
tho
ught
to
be
auth
entic
.
Una
utho
rised
m
odifi
catio
n of
fil
es
/nam
es
OT
HE
R
TH
AN
–
a fo
rm
is
disp
laye
d by
ag
ent
othe
r th
an
the
syst
em.
• M
an
in
the
mid
dle
atta
ck.
Or
agen
tm
asqu
erad
ing
as
the
syst
em.
•
Min
or p
robl
em i
f ne
w i
nfo
is o
ffen
sive
but
rea
l pr
oble
m
com
es n
ext.
Man
in th
e m
iddl
e at
tack
.
NO
–
The
regi
stra
tion
tail
is n
ot p
rovi
ded.
de
Cus
tom
er in
actio
n.
• D
elay
ed re
gist
ratio
n •
Faile
d re
gist
ratio
n
Wha
t ha
ppen
s if
this
is
too
late
– a
tim
eout
? M
OR
E
– M
ore
regi
stra
tion
deta
il is
pr
ovid
ed th
an re
quire
d.
N
ot a
pro
blem
.
Step
3 –
The
cus
tom
er
prov
ides
re
gist
ratio
n de
tails
.
LE
SS –
Les
s re
gist
ratio
n de
tail
is
prov
ided
th
an
requ
ired.
Cus
tom
er
is
relu
ctan
t to
pr
ovid
e re
al/e
noug
hin
form
atio
n.
In
suff
icie
nt
info
rmat
ion
is
regi
ster
ed.
Pr
even
t by
us
ing
man
dato
ry
field
s (u
se
syst
em
to
chec
k).
29
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R T
HA
N –
The
cu
stom
er p
rovi
des
som
e ot
her d
etai
l.
Sam
e as
OTH
ER T
HA
N in
C
usto
mer
’s a
ctio
n W
rong
us
er
info
rmat
ion
rece
ived
, res
ultin
g in
inac
cura
te
data
gat
here
d (e
.g.
num
ber
of
cust
omer
in
tere
sted
in
th
e pr
oduc
t)
Usi
ng
inap
prop
riate
iden
tify
i.e. r
ight
iden
tity,
w
rong
de
tail
or
wro
ng
iden
tity
but
right
/wro
ng
deta
il.
Po
tent
ially
m
ajor
pr
oble
m.
Wha
t ar
e th
e de
tails
? W
hat
onus
is
ther
e to
che
ck a
ccur
acy
by
othe
r m
eans
? A
ge, a
ddre
ss e
tc.
Issu
es
of
fake
d id
entit
y?
Lega
l is
sues
(da
ta
prot
ectio
n A
ct e
tc.)
NO
– T
he c
usto
mer
doe
s
subm
it re
gist
ratio
n ta
ils.
not
de
• C
usto
mer
in
actio
n/re
fuse
s/ch
ange
s his
min
d.
N
o ne
w
regi
stra
tion
deta
il is
st
ored
. •
Com
pute
r han
gs
Dis
tract
or t
rick
cust
omer
M
inor
MO
RE
– T
he c
usto
mer
su
bmits
mor
e th
an o
nce.
•
Cus
tom
er
mis
take
nly
pres
ses
twic
e (o
ver-
eage
r cu
stom
er)
• D
uplic
ate
on n
etw
ork
• R
epla
y of
mes
sage
.
• Th
e sa
me
cust
omer
det
ail i
s up
date
d tw
ice.
•
The
syst
em
igno
res
the
dupl
icat
e in
form
atio
n.
Rep
lay
of m
essa
ge
Issu
e he
re is
real
ly
one
of c
hang
e.
Wha
t is t
he p
olic
y on
cha
ngin
g de
tails
on
ce p
rovi
ded?
Th
is n
eeds
to b
e au
then
ticat
ed in
so
me
way
ot
herw
ise
A c
an
have
his
/her
det
ails
re
mov
ed b
y B
. Th
is is
con
nect
ed
with
abo
ve. T
here
is
the
poss
ibili
ty o
f us
er su
bmitt
ing
mul
tiple
but
di
ffer
ent d
etai
ls.
Step
4 –
The
cus
tom
er
subm
its
Regi
stra
tion
deta
ils.
LE
SS –
N/A
30
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
O
TH
ER
TH
AN
– T
he
cust
omer
cl
icks
on
an
othe
r but
ton.
• M
ista
ke
othe
r bu
ttons
fo
r the
‘Reg
iste
r But
ton’
• Lo
ss
of
info
rmat
ion
ente
red.
•
Expo
sure
of
info
rmat
ion
to
othe
rs.
Dis
tract
or t
rick
cust
omer
. M
inor
.
OT
HE
R T
HA
N –
The
cu
stom
er s
ubm
its d
etai
l to
som
eone
els
e.
• In
terc
eptio
n by
intru
der
• D
iscl
osur
e of
info
rmat
ion
Eave
sdro
ppin
g In
terc
eptio
n
AS
WE
LL
A
S –
The
deta
il is
se
nt
whi
le
som
ethi
ng e
lse
occu
rs
• In
tern
et
gets
di
scon
nect
ed.
• In
terr
uptio
n by
an
in
trude
r •
Cus
tom
er
stop
s an
d w
ants
to c
ance
l •
Extra
eve
nt i
s in
itiat
ed
by c
usto
mer
or a
n in
trude
r •
Info
rmat
ion
may
be
st
ored
in lo
cal b
uffe
r or e
lse
be
retri
evab
le
by
som
e m
eans
. •
Info
rmat
ion
is
sim
ply
sent
to a
n in
trude
r
• C
usto
mer
is
no
t su
re
whe
ther
th
e de
tail
is
sent
th
roug
h or
not
. •
Cus
tom
er
send
s th
e in
form
atio
n ag
ain
if he
/she
stil
l w
ants
to
carr
y ou
t re
sulti
ng i
n du
plic
atio
n of
reco
rds.
• In
trude
r may
get
det
ails
• D
istra
ct
or
trick
cu
stom
er.
A p
age
disp
layi
ng
conf
irmat
ion
that
th
e in
form
atio
n is
re
ceiv
ed
wou
ld
less
en w
orrie
s fro
m
the
cust
omer
s.
NO
– T
he in
form
atio
n is
no
t upd
ated
. •
Con
nect
ion
loss
bef
ore
send
ing
info
rmat
ion
• In
terc
eptio
n •
Erro
r in
se
rver
si
de
(pro
gram
min
g er
ror,
phys
ical
lo
ss,
or
from
m
alic
ious
act
ions
)
• C
usto
mer
is
no
t su
re
whe
ther
th
e de
tail
is
sent
th
roug
h or
not
.
• C
usto
mer
se
nds
the
info
rmat
ion
agai
n.
Inte
rcep
tion
St
ep
5 -
The
syst
em
upda
tes t
he in
form
atio
n.
MO
RE
–
Thin
form
atio
n is
up
date
d m
ore
than
onc
e.
e •
Erro
r in
serv
er si
de
• D
uplic
ated
or
repl
ayed
of
the
info
rmat
ion
The
sam
e cu
stom
er
deta
il is
up
date
d tw
ice.
• R
epla
y of
in
form
atio
n •
Una
utho
rised
m
odifi
catio
n of
pro
gram
on
serv
er si
de.
31
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
L
ESS
– N
/A
O
TH
ER
TH
AN
– T
he
syst
em
upda
tes
wro
ng
info
rmat
ion.
• M
essa
ge
is
corr
upte
d by
an
intru
der.
• Er
ror
in
the
upda
te
prog
ram
.
The
syst
em
obta
ins
wro
ng
info
rmat
ion
• C
orru
pt o
f mes
sage
•
Una
utho
rised
m
odifi
catio
n of
pro
gram
on
serv
er si
de.
NO
– C
usto
mer
is
not
regi
ster
ed to
dat
abas
e.
• Ph
ysic
al p
robl
ems
• So
ftwar
e pr
oble
ms (
e.g.
da
taba
se)
• D
uplic
ate
acco
unt
regi
ster
ed
• In
com
plet
e in
form
atio
n pr
ovid
ed.
• M
essa
ge c
orru
ptio
n
• C
usto
mer
’s fr
ustra
tion.
•
The
com
pany
lo
seop
portu
nity
to se
ll.
M
alic
ious
ly
atta
ck
phys
ical
or
so
ftwar
e co
mpo
nent
s.
MO
RE
–
Cus
tom
er
is
regi
ster
ed
to
data
base
m
ore
than
onc
e.
• U
pdat
e w
rong
by
the
prog
ram
•
Dup
licat
e m
essa
ge
rece
ived
The
sam
e cu
stom
er
deta
il is
up
date
d tw
ice.
•
Una
utho
rised
m
odifi
catio
n of
pro
gram
on
serv
er si
de.
• R
epla
y of
mes
sage
Is t
here
any
pol
icy
agai
nst
dupl
icat
e cu
stom
ers?
Post
-con
ditio
ns
– Th
e cu
stom
er
is
regi
ster
ed
and
the
deta
ils s
aved
to a
da
taba
se.
OT
HE
R
TH
AN
-
Inco
mpl
ete
info
rmat
ion
is re
gist
ered
to d
atab
ase.
• U
pdat
e w
rong
by
the
prog
ram
•
Wro
ng/in
com
plet
e in
form
atio
n is
rece
ived
.
The
syst
em
rece
ives
w
rong
in
form
atio
n
• U
naut
horis
ed
mod
ifica
tion
of p
rogr
am
on se
rver
side
. •
Mod
ifica
tion
of
mes
sage
via
net
wor
k.
Tabl
e 9:
Ana
lysi
s of ‘
Regi
ster
Cus
tom
er’ u
se c
ase.
32
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
U
se C
ase:
Ord
er g
oods
A
ctor
N
O –
The
cus
tom
er d
oes
not o
rder
goo
ds.
• U
nsat
isfie
d w
ith
the
prod
uct s
elec
tions
/pric
e •
Com
plic
ated
inte
rfac
e •
Dis
tract
ion
by
the
com
pany
’s
oppo
nent
ad
verti
sem
ent
• Lo
se a
n op
portu
nity
to se
ll •
Cus
tom
er’s
dis
appo
intm
ent
Hac
king
Pr
ovis
ion
of a
use
r-fr
iend
ly
inte
rfac
e de
sign
. Pr
ovis
ion
of
secu
rity
mec
hani
sm
in
prev
entin
g un
auth
oris
ed
pop-
up w
indo
ws.
MO
RE
– T
he c
usto
mer
ex
cess
ivel
y or
der g
oods
•
Not
the
ow
ner
of t
he
acco
unt/o
r car
d he
’s u
sing
•
Pran
k or
der
with
fak
e ac
coun
t.
• Th
e co
mpa
ny
sent
or
der
with
out g
ettin
g pa
id la
ter o
n.
• Th
e ow
ner
of t
he p
aym
ent
beco
mes
fur
ious
whe
n fin
ds o
ut
that
the
ord
er w
as n
ot i
nitia
ted
by h
im.
• Ti
me
was
ted
whe
n ve
rify
paym
ent
deta
il w
ith
card
co
mpa
ny
and
turn
ou
t to
be
fa
ke.
• In
crea
se
wor
kloa
d to
th
e co
mpa
ny st
aff
• O
btai
n pa
ssw
ord
and
card
det
ail (
stea
l, br
iber
y,
soci
al e
ngin
eerin
g).
• G
et
acce
ss
to
othe
r co
mpu
ter,
whi
le
logg
ing
on to
the
syst
em.
This
ra
ises
th
e is
sues
of
w
heth
er
the
paym
ent s
houl
d be
rec
eive
d be
fore
de
liver
y or
not
.
Cus
tom
er’s
ac
tion
–O
rder
goo
ds
AS
WE
LL
A
S –
The
cust
omer
pr
ovid
esin
suff
icie
nt/in
corr
ect
deta
il w
hen
subm
ittin
g or
der.
•
Det
ail n
ot a
vaila
ble
• C
ompl
icat
ed in
terf
ace
• Ty
ping
mis
take
•
Dis
tract
ion
• Pr
oces
sing
of
pa
ymen
t w
ould
be
unsu
cces
sful
. •
Cus
tom
er’s
dis
appo
intm
ent
• In
crea
se
wor
kloa
d to
th
e co
mpa
ny st
aff.
• St
eal/v
irus
• D
istra
ctio
n C
heck
s on
m
anda
tory
fie
ld
prio
r to
ac
cept
ing
the
requ
est.
33
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R T
HA
N –
The
cu
stom
er
inte
nds
to
achi
eve
som
ethi
ng
else
ra
ther
th
an
to
orde
r go
ods.
Mal
icio
us in
tent
s W
rong
st
atis
tics
data
on
th
e nu
mbe
r of c
usto
mer
acc
ess
Dis
rupt
ion
on th
e se
rvic
e In
crea
se w
orkl
oad
Floo
d/bl
ock
the
syst
em
Impe
rson
atin
g as
cust
omer
This
ra
ises
th
e is
sues
of
w
heth
er
to
allo
w
user
s to
si
mul
tane
ousl
y lo
g on
usi
ng t
he s
ame
acco
unts
.
Cus
tom
er’s
cap
abili
ty –
O
rder
goo
ds
NO
– T
he c
usto
mer
has
no
abi
lity
to o
rder
goo
ds.
• Ph
ysic
al
– lo
ssco
nnec
tion.
Com
pany
m
isse
s th
e op
portu
nity
fo
r on
e po
tent
ial
cust
omer
. •
Doe
s no
t hav
e ac
coun
t/ pa
ymen
t inf
orm
atio
n •
The
cust
omer
has
not
be
en r
egis
tere
d (r
egis
tratio
n de
tail
not a
vaila
ble)
• D
isru
ptio
n of
conn
ectio
ns
Th
is
rais
es
the
issu
es
of
wha
t m
etho
d of
pay
men
t sh
ould
th
ere
be
avai
labl
e fo
r th
e cu
stom
ers.
• St
eal
card
/pay
men
t in
fo.
NO
– T
he o
pera
tor
does
no
t pro
cess
the
orde
r. •
Lack
of
re
spon
sibi
lity
in w
ork
• O
rder
do
es
not
com
e th
roug
h to
the
oper
ator
. •
Ord
er
is
lost
/or
has
been
mod
ified
.
• C
usto
mer
w
aits
de
finite
ly
for t
he g
oods
ord
er.
• C
usto
mer
’s d
isap
poin
tmen
t •
Fina
ncia
l lo
ss
to
the
com
pany
• U
naut
horis
ed
mod
ifica
tion
of
the
mes
sage
via
net
wor
k •
Una
utho
rised
de
letio
n of
ord
er re
ceiv
ed.
Shou
ld i
nfor
m t
he
cust
omer
on
th
e ap
prox
imat
e de
liver
y da
te.
MO
RE
– T
he o
pera
tor
proc
esse
s th
e or
der
mor
e th
an re
quire
.
• O
pera
tor
erro
r (a
ccid
enta
lly e
.g. o
pera
tor’
s m
isin
terp
reta
tion)
•
Softw
are
erro
r •
Cor
rupt
of
the
mes
sage
(b
y an
intru
der o
r net
wor
k)
• G
reed
y op
erat
or,
pret
ends
th
at
he/s
he
has
rece
ived
th
e or
der
mor
e th
an it
was
sent
.
• Fi
nanc
ial
loss
e.
g.
the
syst
em s
ent
out
two
orde
rs b
ut
only
get
pai
d fo
r one
•
Cus
tom
er
need
s to
pa
y tw
ice
if th
e bo
th
paym
ent
trans
actio
ns a
re p
roce
ssed
.
• C
orru
pt th
e m
essa
ge.
• In
tent
iona
lly
mak
e m
ista
ke b
y th
e op
erat
or.
Ope
rato
r’s
actio
n –
Proc
ess t
he o
rder
LE
SS –
N/A
34
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
O
TH
ER
TH
AN
– T
he
oper
ator
pro
cess
es o
rder
w
ith w
rong
info
rmat
ion.
• O
pera
tor e
rror
•
Mod
ifica
tion
ofin
form
atio
n in
the
data
base
•
The
syst
em
send
s ou
t w
rong
or
der,
lead
ing
to
cust
omer
’s d
isap
poin
tmen
t. •
Gre
edy
oper
ator
,pr
eten
ds
that
he
/she
ha
s re
ceiv
es w
rong
info
rmat
ion
•
The
cust
omer
nee
ds t
o pa
y m
ore
than
act
ually
nee
ds to
.
• C
orru
pt o
f th
e m
essa
ge
via
netw
ork
or a
n in
trude
r.
• C
orru
pt th
e m
essa
ge.
• In
tent
iona
lly
mak
e m
ista
ke b
y th
e op
erat
or.
OT
HE
R T
HA
N –
The
op
erat
or
proc
ess
orde
r w
hen
not r
ecei
ved.
• Fa
bric
atio
n of
ord
er
An
inco
rrec
t ord
er is
sent
out
.
Fabr
icat
ion
of o
rder
.
NO
– T
he o
pera
tor
has
no a
bilit
y to
pro
cess
the
or
der.
• N
o pr
ivile
ge to
do
so.
• Th
e su
pplie
r co
nnec
tion
is n
ot a
vaila
ble.
• Sl
ow d
own
the
proc
ess.
• O
pera
tor’
s fru
stra
tion
Mod
ifica
tion
of th
e us
er’s
pr
ivile
ge.
Mon
itorin
g sy
stem
sh
ould
be
us
eful
fo
r thi
s pur
pose
. M
OR
E –
The
ope
rato
r ha
s ab
ility
to
do m
ore
than
pro
cess
ing
the
orde
r (e
.g. m
odify
ord
er).
• In
accu
rate
/or
nopr
ivile
ged
is se
t.
Ope
rato
r is
abl
e to
mod
ify t
he
orde
r le
adin
g to
fin
anci
al l
oss
and
cust
omer
’s fr
ustra
tion.
•
Dat
abas
e is
no
t pr
otec
ted.
•
Erro
r in
the
prog
ram
Una
utho
rised
m
odifi
catio
n in
dat
abas
e an
d so
ftwar
e co
de.
Ass
ign
appr
opria
te
priv
ilege
LE
SS –
N/A
O
TH
ER
TH
AN
– N
/A
Ope
rato
r’s
capa
bilit
y –
Proc
ess t
he o
rder
AS
WE
LL
A
S –
The
oper
ator
ha
s ab
ility
to
so
me
othe
r pr
oces
s in
volv
ing
orde
ring
of
good
s.
• R
espo
nsib
ility
/role
is
as
sign
ed in
corr
ectly
•
Priv
ilege
ass
ignm
ent
is
inco
rrec
t.
Ope
rato
r is
abl
e to
mod
ify t
he
orde
r le
adin
g to
fin
anci
al l
oss
and
cust
omer
’s fr
ustra
tion.
Una
utho
rised
m
odifi
catio
n in
dat
abas
e an
d so
ftwar
e co
de.
Ass
ign
appr
opria
te
priv
ilege
Ass
ocia
tion
Ass
ocia
tion
– O
rder
go
ods a
nd O
pera
tor
NO
–
Ord
er
hasn
’t pa
ssed
to
oper
ator
whe
n ex
pect
ed.
• Lo
ss o
f net
wor
k •
Inte
rcep
tion
• C
usto
mer
wai
ts in
defin
itely
fo
r the
goo
ds o
rder
ed.
• O
ther
com
petit
or m
ay h
ave
bette
r of
fer
and
offe
r to
th
e cu
stom
er,
if th
e in
form
atio
n is
re
veal
ed.
Inte
rcep
tion
35
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
M
OR
E –
Mor
e th
an o
ne
oper
ator
pr
oces
s th
e sa
me
orde
r.
• O
pera
tor e
rror
•
Softw
are
erro
r •
Gre
edy
com
pany
,pr
eten
ds
to
have
re
ceiv
e m
ore
orde
r
• C
usto
mer
re
ceiv
es
mor
e th
an o
ne o
rder
but
pay
s fo
r onl
y on
e, r
esul
ting
to f
inan
cial
los
s of
the
com
pany
. •
Cus
tom
er n
eeds
to
pay
for
mor
e th
an
one
orde
r, if
the
paym
ent
trans
actio
ns
are
proc
esse
d.
Una
utho
rised
m
odifi
catio
n N
eed
to
prot
ect
cust
omer
.
LE
SS –
N/A
O
TH
ER
TH
AN
– O
rder
go
ods
is
asso
ciat
ed
to
som
eone
oth
er t
han
the
oper
ator
.
• H
acki
ng to
the
syst
em
• In
trude
r ha
s ac
cess
to
the
syst
em
(com
pute
r sy
stem
or d
ocum
enta
tion)
•
Fake
op
erat
or,
impe
rson
atin
g re
al o
pera
tor
• O
rder
goo
ds i
s se
nt t
o w
rong
pl
ace
(acr
oss
netw
ork)
Dis
clos
ure
of i
nfor
mat
ion
(e.g
. ac
coun
t in
form
atio
n,
good
s or
dere
d in
fo,
paym
ent
deta
il,
cred
it ca
rd n
umbe
r and
etc
.)
• H
acki
ng
• Im
pers
onat
ing
AS
WE
LL
AS
- O
rder
go
ods
is
asso
ciat
ed
to
som
eone
as w
ell
• In
terc
eptio
n •
Man
in
th
e m
iddl
e at
tack
. •
Ope
rato
r re
veal
s th
e de
tail
(acc
iden
tally
an
d m
alic
ious
ly)
Sam
e as
abo
ve. B
ut th
e op
erat
or
does
not
hav
e kn
owle
dge
that
so
met
hing
has
hap
pene
d. S
eem
s to
still
be
norm
al.
• In
terc
eptio
n •
Man
in
th
e m
iddl
e at
tack
. •
Mal
icio
us in
side
r
Ass
ocia
tion
– O
rder
go
ods a
nd C
usto
mer
s N
O –
Ass
ocia
tion
with
th
e cu
stom
er
does
no
t ta
ke p
lace
.
Con
nect
ion
is b
lock
ed
Cus
tom
er’s
dis
appo
intm
ent
Blo
ck c
onne
ctio
n to
the
sy
stem
.
Use
Cas
e E
lem
ents
St
ep 1
- T
he c
usto
mer
en
ters
O
rder
G
oods
se
ctio
n.
NO
–
The
cust
omer
ca
nnot
en
ter
Ord
er
Goo
ds se
ctio
n.
• Li
nk is
not
ava
ilabl
e •
The
web
pag
e fo
r ord
er
good
sect
ion
is re
mov
ed.
• C
usto
mer
dis
appo
intm
ent.
Cus
tom
er m
ay g
et b
ored
and
m
ay n
ot w
ant t
o ac
cess
the
site
ag
ain.
Fabr
icat
ion
of w
ebsi
te.
36
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
M
OR
E -
The
cus
tom
er
ente
rs to
the
sect
ion
mor
e th
an o
nce.
Kee
p re
fres
hing
and
load
ing
the
sam
e pa
ge.
Not
a p
robl
em.
LE
SS –
N/A
OT
HE
R T
HA
N -
The
cu
stom
er e
nter
s to
som
e ot
her
sect
ion
rath
er t
han
the
Ord
er G
oods
sect
ion.
• Th
e pa
ge w
as r
epla
ced
by a
n in
trude
r •
Inco
rrec
t co
nfig
urat
ion/
upda
te
(acc
iden
tally
/mal
icio
usly
)
• C
usto
mer
’s c
onfu
sion
•
Com
pany
’s re
puta
tion
• M
odifi
catio
n of
w
ebsi
te (f
ile).
• M
odifi
catio
n of
th
e st
orag
e fil
es o
f pro
duct
.
NO
–
The
cust
omer
’s
unt
deta
il is
no
t la
yed.
ac
codi
sp
• A
ccou
nt
does
no
t m
atch
•
Wro
ng d
ata
is s
ent
to
retri
eve
info
•
Inte
rcep
tion
• M
essa
ge c
orru
pt
• C
usto
mer
will
not
be
able
to
or
der
good
s le
adin
g to
cu
stom
er f
rust
ratio
n or
atte
mpt
to
try
to re
-reg
iste
r aga
in.
• D
iscl
osur
e of
cu
stom
er’s
ac
coun
t det
ail.
• In
terc
eptio
n •
Tap
com
mun
icat
ion.
•
Cor
rupt
the
mes
sage
.
MO
RE
–
The
syst
em
disp
lays
cu
stom
er’s
ac
coun
t de
tail
mor
e th
an
nece
ssar
y (e
.g.
card
de
tail/
secu
rity
info
).
• So
ftwar
e er
ror
• Pr
ogra
mm
ing
mis
take
D
iscl
osur
e of
cu
stom
er’s
ac
coun
t det
ail.
Una
utho
rised
m
odifi
catio
n of
softw
are
Onl
y su
ffic
ient
in
form
atio
n is
ne
eded
to d
ispl
ay.
LE
SS –
Ess
entia
l de
tail
is n
ot sh
own.
•
Softw
are
erro
r •
Prog
ram
min
g m
ista
ke
• In
terc
eptio
n
• D
iscl
osur
e of
cu
stom
er’s
ac
coun
t det
ail.
• C
usto
mer
’s c
onfu
sion
Una
utho
rised
m
odifi
catio
n of
softw
are
Enou
gh
info
rmat
ion
is
need
ed to
dis
play
. O
TH
ER
TH
AN
– T
he
acco
unt
deta
il di
spla
yed
is in
accu
rate
.
• M
odifi
catio
n of
acco
unt d
etai
l
Cus
tom
er c
onfu
sion
to
whe
ther
th
e de
tail
is c
orre
ct o
r not
. •
Inte
rpre
tatio
n of
th
e ac
coun
t in
form
atio
n is
w
rong
. (So
ftwar
e fa
ult)
Sam
e as
abo
ve
Step
2
- Th
e sy
stem
di
spla
ys
cust
omer
’s
acco
unt d
etai
l.
OT
HE
R T
HA
N –
The
sy
stem
di
spla
ys
othe
r cu
stom
er’s
ac
coun
t de
tails
.
• R
etrie
val
of t
he w
rong
de
tail
(sof
twar
e er
ror)
•
Wro
ng d
ata
is s
ent
to
retri
eve
info
.
Dis
clos
ure
of o
ther
cus
tom
er’s
ac
coun
t det
ail.
Sam
e as
abo
ve
37
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
N
O –
The
cust
omer
doe
s no
t en
ter
the
good
s de
tail.
• C
usto
mer
inac
tion
N/A
MO
RE
–
The
good
s en
tere
d ar
e m
ore
than
in
tend
ed.
• In
corr
ect
upda
te o
f th
e go
ods
to t
he l
ist
of g
oods
se
lect
ed.
• C
usto
mer
clic
ks o
n th
e ‘s
ubm
it’
or
‘add
’ bu
tton
mor
e th
an o
nce.
Cus
tom
er’s
frus
tratio
n w
hen
get
paid
for g
oods
not
wan
ted.
U
naut
horis
ed
mod
ifica
tion.
Th
e sy
stem
sho
uld
prov
ide
the
list
of
the
sele
cted
goo
ds
for
the
cust
omer
to
view
at a
ny ti
me.
LE
SS
– Th
e go
ods
ente
red
are
few
er
than
in
tend
ed.
• In
corr
ect
upda
te o
f th
e go
ods
to t
he l
ist
of g
oods
se
lect
ed.
• C
usto
mer
do
es
not
clic
k on
th
e ‘s
ubm
it’
or
‘add
’ but
ton.
Cus
tom
er’s
fr
ustra
tion
whe
n re
ceiv
e fe
wer
ord
er
• U
naut
horis
ed
mod
ifica
tion.
•
Inte
rcep
tion
Sam
e as
abo
ve
Step
3 -
For
eac
h ite
m
that
the
cus
tom
er w
ishe
s to
or
der,
the
cust
omer
en
ters
its d
etai
l.
OT
HE
R T
HA
N –
The
cu
stom
er
ente
r w
rong
go
ods d
etai
l.
Unc
lear
pro
duct
des
crip
tion
C
usto
mer
’s
frus
tratio
n w
hen
rece
ive
wro
ng o
rder
U
naut
horis
ed
mod
ifica
tion.
Sa
me
as a
bove
.
NO
– T
he d
eliv
ery
deta
il is
not
pro
vide
d.
N/A
MO
RE
– N
/A
LE
SS
– In
suff
icie
nt
deliv
ery
deta
il is
prov
ided
.
• C
usto
mer
pr
ovid
esin
suff
icie
nt d
etai
l
• Th
e or
der
cann
ot
be
deliv
ered
. •
Inte
rcep
tion
• M
essa
ge is
cor
rupt
ed.
• G
oods
are
sen
t to
wro
ng
addr
ess.
• In
terc
eptio
n •
Cor
rupt
the
mes
sage
M
anda
tory
fie
ld
chec
k.
Step
4 -
The
cus
tom
er
prov
ides
del
iver
y de
tails
.
OT
HE
R T
HA
N –
The
cu
stom
er
prov
ides
inco
rrec
t del
iver
y de
tail.
Tr
ick
cust
omer
to
m
ake
mis
take
. Sa
me
as a
bove
Sa
me
as a
bove
D
eliv
ery
conf
irmat
ion
page
.
38
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
OT
HE
R
TH
AN
–
Del
iver
y de
tail
is
prov
ided
by
othe
r per
son.
• In
trude
r en
ters
his
/her
ow
n de
liver
y de
tail
inst
ead
of th
e cu
stom
er
• M
odifi
catio
n of
th
e m
essa
ge b
y th
e in
trude
r
Goo
ds
are
sent
to
an
othe
r ad
dres
s, w
hile
the
pay
men
t is
be
ing
dedu
cted
fr
om
the
owne
r’s
acco
unt,
resu
lting
to
cu
stom
er d
issa
tisfa
ctio
n
Una
utho
rised
m
odifi
catio
n of
th
e m
essa
ge
Step
5
- Th
e sy
stem
ca
lcul
ates
an
d di
spla
ys
the
pric
e of
th
e go
ods
orde
red.
NO
– T
he s
yste
m d
oes
not
or
fails
to
ca
lcul
ate/
disp
lay
the
amou
nt d
ue.
Erro
r in
the
prog
ram
In
terc
eptio
n C
usto
mer
doe
s no
t kn
ow h
ow
muc
h is
du
e an
d m
ay
be
relu
ctan
t to
subm
it an
y pa
ymen
t de
tails
.
• U
naut
horis
ed
mod
ifica
tion
of
the
prog
ram
•
Inte
rcep
tion
NO
–
The
cust
omer
su
bmits
pa
ymen
t de
tail
to
the
syst
emun
succ
essf
ully
.
• Lo
ss
of
inte
rnet
co
nnec
tion
• Se
rver
is d
own
• C
usto
mer
inac
tion
• C
usto
mer
is
w
orrie
d w
heth
er o
r no
t the
pay
men
t has
re
ache
d th
e sy
stem
. •
Oth
er
mal
icio
us
pers
on
mig
ht a
ttem
pt to
mak
e pa
ymen
t or
cap
ture
pay
men
t det
ail i
f th
e cu
stom
er is
not
aro
und
the
PC.
Blo
ck sy
stem
. C
onfir
mat
ion
page
.
MO
RE
– T
he p
aym
ent
deta
il is
sen
t ou
t m
ore
than
onc
e.
• C
usto
mer
ac
cide
ntal
ly
subm
its m
ore
than
onc
e.
• R
epla
yed
of
mes
sage
by
an
intru
der.
Paym
ent
trans
actio
n is
m
ade
twic
e.
Rep
lay
of m
essa
ge
OT
HE
R
TH
AN
–
Inco
rrec
t pa
ymen
t de
tail
is s
ent
out
(e.g
. val
ue o
f pa
ymen
t, ca
rd n
umbe
r)
• M
odifi
catio
n of
mes
sage
by
an in
trude
r
• C
usto
mer
ha
s pa
y m
ore
than
requ
ire
• C
usto
mer
en
ters
inco
rrec
t det
ail
•
The
paym
ent’s
va
lidat
ion
fails
re
sulti
ng
in
cust
omer
’s
diss
atis
fact
ion.
Cor
rupt
the
mes
sage
Pa
ymen
t sh
ould
be
chec
ked
befo
re a
ny
orde
rs
can
be
proc
esse
d.
Step
6 -
The
cus
tom
er
subm
its p
aym
ent d
etai
l.
OT
HE
R T
HA
N –
The
cu
stom
er
subm
itspa
ymen
t de
tail
to o
ther
sy
stem
s/us
ers
(mes
sage
is
reve
aled
).
•
No
encr
yptio
n of
m
essa
ges
• Pa
ymen
t de
tail
is s
ent
to w
rong
pla
ce.
• D
iscl
osur
e of
pa
ymen
t de
tail
to a
third
par
ty.
• O
rder
is n
ot p
roce
ssed
if th
e sy
stem
ha
s no
t re
ceiv
ed
the
paym
ent d
etai
l.
• Ta
p co
mm
unic
atio
n.
• In
terc
eptio
n
39
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
O
TH
ER
T
HA
N
– Pa
ymen
t de
tail
is
subm
itted
but
not
by
the
cust
omer
.
• In
trude
r fa
kes
a pa
ymen
t mes
sage
.
The
paym
ent
trans
actio
n is
re
ject
ed b
y ca
rd c
ompa
ny.
Mod
ifica
tion
of m
essa
ge.
AS
WE
LL
AS
– O
ther
pr
oces
s oc
curs
w
hen
paym
ent i
s sub
mitt
ed.
• Lo
ss
of
inte
rnet
co
nnec
tion
• In
trude
r in
itiat
es o
ther
pr
oces
s •
Cus
tom
er in
itiat
es o
ther
pr
oces
s.
Cus
tom
er
has
no
idea
if
the
paym
ent
has
alre
ady
take
n pl
ace.
Blo
ck sy
stem
C
onfir
mat
ion
page
.
NO
– T
he s
yste
m d
oes
not
conf
irm t
he r
esul
t of
th
e tra
nsac
tion
• Th
e sy
stem
is
inte
ntio
nally
blo
cked
fro
m
send
ing
back
the
mes
sage
so
tha
t th
e pa
ymen
t ca
n be
ca
rrie
d ou
t w
ithou
t th
e cu
stom
er k
now
ing.
C
usto
mer
’s w
orry
• Lo
ss
of
netw
ork
and
othe
r com
mun
icat
ions
Blo
ck sy
stem
C
onfir
mat
ion
page
or
se
nd
a co
nfirm
atio
n e-
mai
l to
th
e cu
stom
er.
Step
7
- Th
e sy
stem
co
nfir
ms
the
resu
lt of
tr
ansa
ctio
n.
MO
RE
–
The
syst
em
conf
irms
resu
lt m
ore
than
onc
e.
Dup
licat
e of
mes
sage
C
usto
mer
is
w
orrie
d on
ho
w
man
y tra
nsac
tions
are
mad
e fo
r th
e pa
ymen
t.
Rep
lay
of m
essa
ge.
Step
8
- Th
e op
erat
or
proc
esse
s the
ord
er.
NO
– S
ame
as a
bove
in
oper
ator
’s a
ctio
n.
NO
– T
he d
ata
is n
ot
rece
ived
. •
Loss
of n
etw
ork
• In
terc
eptio
n •
Syst
em is
blo
cked
No
orde
ring
and
purc
hasi
ng
take
n pl
ace.
•
Blo
ck sy
stem
•
Inte
rcep
tion
Po
st-c
ondi
tion
- Th
e or
der
and
its d
etai
l ar
e re
ceiv
ed a
nd p
roce
ssed
.
M
OR
E
– Su
perf
luou
s in
form
atio
n is
rece
ived
. M
odifi
catio
n of
the
mes
sage
W
rong
del
iver
y/pa
ymen
t de
tail
caus
ing
custo
mer
’s
anno
yanc
e to
war
ds th
e co
mpa
ny.
Mod
ifica
tion
of m
essa
ge.
Tabl
e 10
: Ana
lysi
s of ‘
Ord
er G
oods
’ use
cas
e.
40
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
U
se C
ase:
Cha
nge
pass
wor
d A
ctor
O
pera
tor’
s ac
tion
– C
hang
e pa
ssw
ord
MO
RE
–
Ope
rato
r re
peat
edly
ch
ange
pass
wor
d
Ope
rato
r w
ants
to
use
the
sam
e pa
ssw
ord
still
but
was
fo
rced
to
chan
ge,
so n
eeds
to
cha
nge
until
he
can
use
his o
rigin
al p
assw
ord.
Vul
nera
bilit
y to
atta
cks
if sa
me
pass
wor
d is
use
d.
Soci
al
engi
neer
ing,
to
co
nvin
ce t
he o
pera
tor
to
use
the
sam
e pa
ssw
ord.
Stric
tly e
nfor
ce th
e pa
ssw
ord
polic
y.
Ope
rato
r’s
capa
bilit
y –
Cha
nge
pass
wor
d N
O –
The
ope
rato
r ha
s no
abi
lity
to c
hang
e th
e pa
ssw
ord.
• O
pera
tor
cann
otre
mem
ber o
ld p
assw
ord
V
ulne
rabi
lity
to a
ttack
s if
sam
e pa
ssw
ord
is u
sed.
•
The
old
pass
wor
d is
in
corr
ect.
Ass
ocia
tion
OT
HE
R
TH
AN
–
Cha
nge
of p
assw
ord
by
som
eone
els
e.
• O
btai
n of
old
pas
swor
d •
Cha
nge
in
pass
wor
d fil
es o
r dat
abas
e.
Una
utho
rised
per
son
may
fre
ely
use
the
syst
em f
or h
is/h
er o
wn
bene
fits.
Stea
l, so
cial
eng
inee
ring,
br
ibe.
Pa
ssw
ords
in
da
taba
se/fi
les
shou
ld
also
be
pr
otec
ted
or
encr
ypte
d.
Ass
ocia
tion
– O
pera
tor
and
Cha
nge
pass
wor
d
NO
–
No
asso
ciat
ion
betw
een
‘Cha
nge
pass
wor
d’
and
the
oper
ator
.
•
Ope
rato
r do
es
not
chan
ge p
assw
ord.
Vul
nera
bilit
y to
atta
cks
if sa
me
pass
wor
d is
use
d.
Soci
al
engi
neer
ing,
to
co
nvin
ce t
he o
pera
tor
to
use
the
sam
e pa
ssw
ord.
Enfo
rce
the
pass
wor
ds
to
be
chan
ged
regu
larly
Use
Cas
e E
lem
ent
Pre-
cond
ition
s –
The
oper
ator
is lo
gged
on.
N
O
– Th
e op
erat
or
cann
ot lo
g in
. •
Loss
of
ne
twor
k/
softw
are
prob
lem
s •
Acc
ount
an
d/or
pa
ssw
ord
are
inco
rrec
t •
The
oper
ator
w
as
bloc
ked
• A
ccou
nt is
dis
able
d
No
activ
ities
can
be
done
. •
Blo
ck sy
stem
•
Mod
ifica
tion
of
the
stor
ed
acco
unt
info
rmat
ion.
41
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
M
OR
E –
Mor
e th
an o
ne
user
/ope
rato
r lo
g on
with
th
e sa
me
acco
unt.
Obt
ain
acco
unt
info
rmat
ion
and
pass
wor
d.
Una
utho
rised
per
son
may
fre
ely
use
the
syst
em f
or h
is/h
er o
wn
bene
fits.
Stea
l, so
cial
eng
inee
ring,
br
ibe.
En
forc
e on
ly
one
user
to
be l
ogge
d on
at a
tim
e.
LE
SS –
N/A
OT
HE
R T
HA
N –
The
ac
coun
t is
log
ged
on b
y so
meo
ne e
lse.
Obt
ain
acco
unt
info
rmat
ion
and
pass
wor
d.
Una
utho
rised
per
son
may
fre
ely
use
the
syst
em f
or h
is/h
er o
wn
bene
fits.
Stea
l, so
cial
eng
inee
ring,
br
ibe.
NO
– N
/A
MO
RE
– T
he p
assw
ord
is
ente
red
with
m
any
atte
mpt
s.
• In
trude
r re
peat
edly
gues
ses t
he p
assw
ord.
Una
utho
rised
per
son
may
fre
ely
use
the
syst
em f
or h
is/h
er o
wn
bene
fits.
Ti
me-
out a
nd b
lock
th
e sy
stem
if
a nu
mbe
r of a
ttem
pts
have
exc
eede
d.
LE
SS –
N/A
Step
1.
- Th
e op
erat
or
ente
rs h
is o
ld p
assw
ord
OT
HE
R T
HA
N –
The
op
erat
or
ente
rs
an
inco
rrec
t pas
swor
d.
Inco
rrec
t pa
ssw
ord
is
ente
red.
Th
e pa
ssw
ord
valid
atio
n fa
ils
Step
2
- Th
e sy
stem
va
lidat
es p
assw
ord.
N
O –
The
sys
tem
was
un
able
to
va
lidat
e pa
ssw
ord.
• Th
e pa
ssw
ord
does
not
m
atch
the
exis
ting
pass
wor
d in
the
syst
em.
• Pa
ssw
ord
stor
ed
was
ch
ange
d by
an
intru
der
The
pass
wor
d va
lidat
ion
fails
. Th
e op
erat
or
is
not
able
to
ac
cess
the
syst
em.
Mod
ifica
tion
of th
e st
ored
ac
coun
t inf
orm
atio
n.
NO
– N
/A
OT
HE
R T
HA
N –
The
op
erat
or
ente
rs
wro
ng
pass
wor
d in
the
sec
ond
time
Typi
ng m
ista
ke
Pass
wor
d w
ill n
ot b
e ch
ange
d.
Step
3
- Th
e op
erat
or
ente
rs h
is n
ew p
assw
ord
twic
e
OT
HE
R T
HA
N –
The
op
erat
or
ente
rs
apa
ssw
ord
twic
e w
hich
is
not e
xpec
ted.
•
Wro
ng p
ositi
on o
f han
d on
key
boar
d •
Cha
ract
er is
sen
t wro
ng
from
key
boar
d •
The
pass
wor
d is
sto
red
inco
rrec
tly.
Ope
rato
r w
ill
be
unab
le
to
logo
n.
Mod
ifica
tion
of th
e st
ored
ac
coun
t inf
orm
atio
n.
42
Ele
men
ts
Gui
dew
ord-
Dev
iatio
n C
ause
E
ffec
ts
Thr
eats
invo
lved
. C
omm
ents
N
O –
The
cha
nge
deta
il w
as n
ot se
nt o
ut.
Loss
of
ne
twor
k an
d co
nnec
tion
Ope
rato
r w
ill
be
unab
le
to
logo
n.
Blo
ck sy
stem
MO
RE
– T
he c
hang
e is
se
nt o
ut m
ore
than
onc
e.
The
oper
ator
cl
icks
th
e bu
tton
twic
e.
Not
a p
robl
em.
Th
e sy
stem
sho
uld
prev
ent
‘dou
ble
clic
king
’ act
ion.
Step
4
- Th
e op
erat
or
conf
irm
s the
cha
nge
OT
HE
R T
HA
N –
The
op
erat
or
conf
irms
the
chan
ge
for
deta
il no
t ex
pect
ed (
the
deta
il se
nt
out i
s wro
ng).
Mod
ifica
tion
of th
e m
essa
ge
afte
r tra
nsm
ittin
g.
Ope
rato
r w
ill
be
unab
le
to
logo
n.
Mod
ifica
tion
of
the
mes
sage
NO
– T
he p
assw
ord
is
not c
hang
ed.
• Pr
ogra
m e
rror
•
Pass
wor
d in
put
cont
ains
inva
lid c
hara
cter
Ope
rato
r w
ill
be
unab
le
to
logo
n.
Step
5 -
The
syst
em s
aves
pa
ssw
ord
to th
e sy
stem
.
OT
HE
R T
HA
N –
The
sy
stem
sa
ves
wro
ng
valu
e of
pas
swor
d.
• Pr
ogra
m e
rror
•
Intru
der
Ope
rato
r w
ill
be
unab
le
to
logo
n.
• Sp
oofin
g •
Mod
ifica
tion
of
the
stor
ed
acco
unt
info
rmat
ion.
Post
-con
ditio
n –
Pass
wor
d is
cha
nged
.
Sam
e as
abo
ve
Tabl
e 11
: Ana
lysi
s of ‘
Cha
nge
Pass
wor
d’ u
se c
ase.
43
6.3 The results The analysis identifies unexpected behaviours of the system and the actor, as the results from the application of the HAZOP guide words to the use case elements. Causes and consequences of each behaviour are identified. Further comments and recommendations can be investigated. This section summarises results obtained from the case study analysis. The results highlight potential threats to the system. For example, impersonation, message corruption or unauthorised accesses to the system (by social engineering, bribery, stealing, hacking etc.) are identified as possible threats. The likelihood of these threats should be subject to further analysis, so that correct measures can be provided. An issue raised from the discussion during the analysis is the order of the product lists displayed to the customer. The use case for browsing a catalogue stipulated that a list of relevant products be returned to the customer. One of the attributes of a list is the order in which the items appear (as anyone familiar with search engines will know). Applying OTHER THAN on this attribute led to discussions of the possible effects of different ordering and possible means of resolution. Another example of security-related issue raised is the realisation that the user identity representation is non-trivial. As part of the registration process a user was required to submit his or her ‘details’. Although our use case checked that the exact details had not already been registered, minor variants could easily be accepted as those of distinct customers. For example, Jeffrey Herebeacker and Jeffrey Hearbehacker would be considered distinct. There may be good pragmatic reasons why customers should not have multiple identities, but there are security issues too. What if we wanted to have of ‘one-per-customer’ offers? Similarly, the intent of ‘one-per-household’ offers could be circumvented easily by adopting minor variants of street name (the postal service in the UK is known for its ability to deliver very badly addressed post). This suggested that a more sophisticated and fuzzy notion of equality of details might be needed. Thus, although it might be ‘obvious’ when two sets of details are the same and when they are not, simply considering the application of OTHER THAN to details prompts us to consider in more detail what we really want, and reveals potential deficiencies in the mechanism we have chosen to implement. Though the technique does not solve the issue, it successfully highlights it for consideration. Several other potential attacks identified in the analysis are due to the vulnerabilities of the payment process and the handling of confidential details. These suggest to the developer that the security policy for how the payment and the confidential details are to be handled should be made explicit and analysed further. Additional functional requirements arise from the analysis. Some of these requirements are derived to help prevent or mitigate the likelihood of the vulnerabilities. The following are some of the derived requirements extracted from Table 8 to Table 11.
1. The system needs to check mandatory fields (e.g. all required payment details are filled in).
44
2. There is a need to provide functions to allow customers to update/modify their detail (in order to avoid unnecessary repeated registration).
3. Acknowledgement messages should be provided to users to confirm actions taken (messages sent). Thus the technique highlights issues relevant for good HCI design.
4. There is a need to provide/display confirmation details before processing the payment of the transaction.
5. There is a need to provide session time out (to protect against users wandering away from terminals etc).
6. Modification of web-site data should only be done by an authorised person in an appropriate manner. (This may be obvious but was certainly not explicit.)
7. There is a need for communications protection. Again, this may seem obvious, but the work exposed various assumptions being made about confidentiality and integrity of such communications.
8. There is a need to specify and enforce a policy on password maintenance. 9. There is a need to consider how abnormal or incomplete transactions should
be handled. Additionally, there are obvious needs for the maintenance of a secure audit trail for appropriate accountability.
45
7. Discussion and conclusions 7.1 Summary of major findings HAZOP provides a systematic approach to reasoning about the high-level security of a system modelled in use cases. It can be seen as a useful tool in the security analysis armoury. The worked study we have presented here is small but has allowed us to draw conclusions on the utility of the general technique. Below we summarise our observations on the experience of applying HAZOPs to the e-commerce example. • HAZOPS helps the derivation of security requirements and policy. The
analysis process is an effective means of teasing out security requirements. At their simplest these will be additional functional requirements. However, we found that the analysis process often provoked discussion about higher-level policy issues. In some environments the security policy may be implicit and in many cases will be incomplete. HAZOPS prompts the analysis team to think in ways they would not otherwise have done.
• HAZOPS highlights issues. HAZOPS provides problems and issues, not
solutions! It forces the analyst to consider unusual scenarios. Sometimes the issues thrown up have no clear solution (e.g. one could deal with the provision of multiple identities by ignoring them and not offering ‘one per customer’ offers). Also, in trying to interpret what is meant by particular natural language descriptions one occasionally finds lower level design possibilities being discussed. Though strictly inapplicable at the use case level, lower level implementation issues can be unearthed and recorded for consideration. Inevitably, much design is iterative and in many developments there is some degree of working ahead (and so aspects of implementation will proceed before higher levels have strictly been finished). Working ahead with forethought should save misguided effort being spent.
• HAZOPs can be applied to all use case elements. Associations are often
glossed over in normal developments but have significant security relevance, raising fundamental questions about who should have accesses to which services. An assumption is typically made in use cases that the actor remains constant throughout a transaction. However, this assumption can be subjected to perturbation, leading to issues of masquerading and impersonation etc. The very existence of association as a concept leads to this sort of thinking. Once an element is identified it can be challenged by perturbation and the consequences considered. Insight is typically needed to generate the scenarios. Although not all security problems will be identified via consideration of perturbations of the core use cases, the method does seem to yield useful information and prompts a much more systematic analysis.
• Abstraction from communications hides threats. In our web-based system the
principals in transactions are distributed. The language in the use cases often obscures the underlying communications needed. Thus, ‘the system presents to the customer’, really involves sending the appropriate data across the web,
46
though this is nowhere mentioned. This abstraction hides attacks based on message interception/spoofing. We found in practice that we did address some communications security issues. Also, in uses cases, simple acknowledgement messages are often omitted. This too can hide or even create threats. If no acknowledgement is actually implemented, a user may induce a transaction again (e.g. buying air tickets for a second time over the web, thinking the first transaction initiated has been aborted).
• Viewpoint prompts are useful! We have found it very useful to wear various
‘hats’ in carrying out the analysis. These are what are usually referred to as viewpoints. Even simple considerations such confidentiality, availability, integrity, accountability and timing prompt the analysts to highlight issues in these areas. Analysts are free to generate these as appropriate. One could easily imagine environmental viewpoints (e.g. temperature, which may have a distinct effect on smart card operations), a passive eavesdropper viewpoint, a maintenance viewpoint, or a cleaner’s viewpoint!
• There are more actors than you think. Determining what you have forgotten
is hard! The analysts must attempt to consciously search for such additional considerations. Thus, for example, cleaners did not appear in any of the previous analysis, and yet they may have physical access to terminals and servers.
• Elicitation of attack patterns. The HAZOP based approach helps in elicitation
of patterns of attack, as well as analysing and creating a process of developing a pattern library. For example, analysis reveals implicit protocols between the user and the system – and deviations from these protocols; this could form a pattern that can be applied generally.
• Uses cases are programs too! Although we have deliberately applied the
technique to high-level scenarios, this is not essential. A normal program is a sequence of actions, with preconditions and preconditions. The HAZOPs approach can be applied to lower levels of design/implementation (mutatis mutandis).
The use of the technique itself is also observed. The following are some observations made on the results and procedure in carrying out the techniques: • There is a lot of repetition: we need a way of summarising the useful findings.
The results produced are very repetitive. This is probably because the same guidewords are applied to each element and action step of the use case, some of which are very similar. Generalization of the identified threats would be one possible approach in summarising the findings.
• Team-based analysis. Any team-based analysis approach is more powerful than a
single-user equivalent; creativity is encouraged, and alternative views are aired and discussed. Because the systematic analysis of the use cases was carried out by a team (here the three authors), the coverage is wider and deeper than an initial exploration by one of the authors. It is also observed that roles in the team are important. Different roles have different interests on the system (i.e. privacy,
47
availability and confidentiality). This would help the discussion and raises issues that we might not normally consider.
• Issues of scoping: individually apply guidewords to each term. For more
detailed analysis of a particular function or behaviour, each individual term or sub-statement could be thoroughly analysed by applying the HAZOP guidewords to. This creates more possible deviations to a particular function. However, we need to see if the findings are worth the effort.
• Use case-based analysis. Of course, the technique makes use of use case
modelling as the underpinning of the analysis. The thoroughness of the analysis highly depends on how detail and accurate the use case is constructed and the level of abstraction you would like to achieve.
• Flexibility. Guidewords are adjustable. Interpretations can be modified according
to certain types of the system. • Time-consuming and tedious. Most systematic approach consumes more time,
however producing a more thorough result. It is preferably to spend more time and effort to identify what is significant to the system at the early stage of the development. This sort of observation seems intrinsic to the technique. It applies also to some other thorough forms of test, e.g. mutation testing. Automated support for carrying out and recording the analysis. Indeed, since ideas often come quickly, a dedicated recorder who does not participate in the technical discussions may well be appropriate. In our efforts, we typically recorded ideas on a whiteboard and recorded them formally afterwards.
7.2 Conclusions The role of security analysis is becoming increasingly important. Systems are becoming more complex and are now operating in environment with higher risks. Consequences of such systems failure are of high concern. The method, presented in the paper, provides a more rigorous approach in carrying out security analysis. It is intended to supplement other forms of analysis and should be integrated with it. The simple case study has demonstrated that it is possible and beneficial to adapt HAZOP (technique widely used in safety community) to Use Case (which is primarily used for capturing functional requirements) to provide a more systematic approach for security analysis. The future work in this area could include: (1) generation of attack patterns from the analysis results, (2) further application to other descriptive types (e.g. procedures, informal descriptions, protocols described using message sequence charts), (3) generalisation of threats results and (4) implementation of tool support.
48
8. References
[1] Allenby, K. and Kelly, T.P., 2001. Deriving Safety Requirements using Scenarios. In: the 5th IEEE International Symposium on Requirements Engineering (RE'01), IEEE Computer Society Press.
[2] Amoroso, E., 1994. Fundamentals of Computer Security Technology. Prentice-Hall. ISBN 0-13-305541-8.
[3] Anderson, R. and Stallings, W., 1996. Why Cryptosystems Fail. Practical Cryptography for Data Internetworks, IEEE Computer Society Press.
[4] Anderson, R., 1999. The Formal Verification of a Payment System. In: M. Hinchey and J. Bowen, ed. Industrial-Strength Formal Methods in Practice. Springer-Verlag, London.
[5] Anderson, R., 2001. Security Engineering: A Guide to Building Dependable Distributed Systems. John Wiley & Sons, Inc. ISBN 0-471-38922-6.
[6] Ball, C. and Kim, R., 1991. An Object Oriented Analysis Of Air Traffic Control. MITRE Corporation, McLean, Virginia. Available from: www.mitrecaasd.org/library/tech_docs/pre1999/wp90w542/
[7] Barcalow, J. and Yoder, J., 1997. Architectural Patterns for Enabling Application Security. Fourth Conference on Patterns Languages of Programs (PLoP '97) Monticello, Illinois, September 1997.
[8] Baskerville, R., 1993. Information Systems Security Design Methods: Implications for Information Systems Developments. ACM Computing Surveys, 25(4), 375-414.
[9] Bell, D. E., Lapadula L. J., 1974. Secure computer systems: Mathematical foundations and model. MITRE Corp., Tech. Rep. M74-244.
[10] Biba, K. J., 1977. Integrity considerations for Secure computer Systems. MITRE Corp., ESD-TR 76-372.
[11] Blair, B.G., 2002. Accidental or Unauthorized Launch. Available from: http://www.clw.org/pub/clw/coalition/chap2b.htm.
[12] Boeing. Multi-engine maintenance. Aero Magazine. Available from: http://www.boeing.com/commercial/aeromagazine/aero_05/textonly/m02txt.html
[13] Brewer, D. and Nash M., 1989. The Chinese Wall Security Policy. In: Proceedings of IEEE Symposium Security & Privacy, IEEE Comp Soc Press, 206-214.
[14] Brewer, D.F.C., 1993. Applying Security Techniques to Achieve Safety. In: Directions in Safety-Critical Systems, Proceedings of the Safety-Critical Systems Symposium, Bristol, Springer-Verlag London Ltd.
[15] Burns, A., McDermid, J. et al., 1992. On the Meaning of Safety and Security. The Computer Journal, 35(1).
[16] C & A Security Risk Analysis Group, 2002. Introduction to Security Risk Analysis and Security Risk Assessment. Available from: http://www.security-risk-analysis.com/
[17] Carroll, J.M., 1996. Computer Security, 3rd Edition. Butterworth-Heinemann. ISBN 0-750-69600-1
[18] Common Criteria Information Board, 1997. Common Criteria for Information Technology Security Evaluation, version 2.0, October 1997
49
[19] Commission of European Communities, 1991. Information Technology Security Evaluation Criteria (ITSEC), version 1.2, Commission of European Communities, June 1991.
[20] Clark, D.D. and Wilson, D.R., 1987. A Comparison of Commercial and Military Computer Security Policies. In: Proceedings of IEEE Symposium on Security and Privacy, IEEE Comp Soc Press, 184-194.
[21] Craigen, D., Gerhart, S. et al., 1993. An international survey of industrial applications of formal methods; vol. 1: Purpose, approach, analysis and conclusions. National Institute Standards and Technology, Technical Report NIST GCR 93/626.
[22] Cullyer, J., 1993. The Technology of Safety and Security. In: The Computer Bulletin, vol. 5.
[23] Cybenko, G., Giani, A. and Thompson, P., 2003. Cognitive Hacking: A Battle for the Mind. Computer, pp.5056.
[24] Damianou N., Dulay N., Lupu E., Sloman M., 2001. The Ponder Policy Specification Language. In: Proc. Policy 2001: Workshop on Policies for Distributed Systems and Networks, Bristol, UK, January 2001. Springer-Verlag LNCS, 29-31.
[25] Denning, D.E., 1999. Information Warfare and Security. Addison Wesley. [26] Douglas, B.P. 2000. Real-Time UML (2nd ed.): Developing efficient objects for
embedded systems. Addison Wesley Longman. [27] US Department of Defence, 1985. Trusted Computer System Evaluation Criteria
(TCSEC), DOD 5200.28-STD, December 1985. [28] Ellison, R., Linger, R., et al., 1999. Survivable Network System Analysis: A Case Study.
IEEE Software, 70-71. [29] The Federal Aviation Administration. Available from: http://www.faa.gov [30] Fisch, E.A. and White, G.B., 2000. Secure Computers and Networks: Analysis, Design
and implementation. CRC Press LLC. ISBN 0-8493-1868-8. [31] Foster N., Jacob J., 2001. Requirements Gathering and Analysis for Security Protocols.
Department of Computer Science, The University of York, UK. [32] Herrmann, P. and Krumm, H., 2001. Object-Oriented Security Analysis and Modeling.
In: Proceedings of the 9th International Conference on Telecommunication Systems - Modeling and Analysis, 21-32.
[33] Hoare, C.A.R., 1985. Communicating Sequential Processes. Prentice Hall. [34] Hoyt, D. B., 1973. Computer Security Handbook. Macmillan, New York. ISBN 0-024-
69910-1. [35] International Civil Aviation Organization. Available from: http://www.icao.org/ [36] Isaksen, U., Bowen, J.P. and Nissanke, N., 1996. System and Software Safety in Critical
Systems. Technical Report RUCS/97/TR/062/A, Department of Computer Science, The University of Reading, UK, 1997.
[37] ISO Standard 17799, 2000. Based on BS7799 British Standards Institute Standard for Information Security Management, last published in 1999.
[38] Jacobson, I., Christerson, M., Jonsson, P., and Overgaard, G., 1992. Object-Oriented Software Engineering: A Use Case Driven Approach. Addison-Wesley.
[39] Kelly, T.P. and McDermid, J.A. 1998 Safety Case Patterns – Reusing Successful Arguments, In: Proceedings of IEE Colloquium on Understanding Patterns and Their Application to System Engineering, London, UK.
50
[40] Kelly, T.P., 1999. Arguing Safety – A Systematic Approach to Managing Safety Cases. Thesis (DPhil). Department of Computer Science, University of York, UK.
[41] Kelly, T.P., 2002. Kelly’s Publication Web Page. Available from: http://www-users.cs.york.ac.uk/~tpk/pubs.html
[42] Kienzle, D.M. and Wulf, W.A., 1997. A Practical Approach to Security Assessment. In: Proceedings of the 1997 New Security Paradigms Workshop, England, September 1997.
[43] King, D.F. Learning Lessons the (not quite so) hard way. Incidents, the road to human factors in engineering. Available from: http://www.hf.faa.gov/docs/508/docs/king15.pdf
[44] Kletz, T., 1992. Hazop and Hazan: Identifying and Assessing Process Industry Hazards, 3rd edition. Institution of Chemical Engineers. ISBN 0-85295-285-6.
[45] Kruchten, P. 2000. The Rational Unified Process: An Introduction (2nd Edition) Addison-Wesley.
[46] Laprie, J.C., 1992. Dependability: Basic Concepts and Terminology. Dependable Computing and Fault Tolerance, vol.5.
[47] Leveson, N.G., Harvey, P.R., 1983. Software Fault Tree Analysis. The Journal of Systems and Software, 80-99.
[48] Leveson, N.G., 1986. Software safety: Why, what, and how. Computing Surveys, 18(2), 125-163.
[49] Leveson, N.G., 1995. Safeware, System Safety and Computers, Addison-Wesley Publishing Company Inc. ISBN 0-201-11972-2.
[50] Longley, D. and Shain, M., 1987. Data and Computer Security, Dictionary of Standards, Concepts and Terms. MacMillan Publishers Ltd.
[51] Lynch, J., 2001. Applying Safety Critical Systems Engineering Techniques to Secure Systems. Dissertation (MSc). Department of Computer Science, University of York, UK.
[52] McDermid, J.A., Nicholson, M, Pumfrey, D. and Fenelon, P., 1995. Experience with the application of HAZOP to Computer-Based Systems. In: Proceeding of the 10th annual conference on computer assurance (COMPASS 95). Gaithersburg, MD, 37-48.
[53] McDermott, J. and Fox, C. 1999. Using Abuse Case Models for Security Requirement Analysis. In: Proceedings of 15th Annual Computer Security Applications Conference, Phoenix, Arizona.
[54] McDermott, J., 2001. Abuse-Case-Based Assurance Arguments. In: 17th Annual Computer Security Applications Conference. December 10-14, 2001
[55] Mead, N.R., Ellison, R.J. et. al., 2000. Survivable Network Analysis Method, SEI, CMU.
[56] Moffett, J. and Nuseibeh, B. 2003 A Framework for Security Requirements engineering. Report YCS 368, Department of Computer Science, University of York. Available from: http://www-users.cs.york.ac.uk/~jdm/olpapers.htm
[57] Moore, A.P., 1997. The JMCIS information flow improvement (JIFI) assurance strategy. Technical Report 500-190, Centre for High Assurance Computer Systems Information Technology Division, Naval Research Laboratory, Washington, D.C. http://chacs.nrl.navy.mil/publications/CHACS/1997/jifi_web/node14.html
[58] NUREG 0492. Fault Tree Handbook. U.S. Nuclear Regulatory Commission.
[59] Pumfrey, D.J., 1999. The Principled Design of Computer System Safety Analyses. Thesis (DPhil). PhD thesis, Department of Computer Science, University of York, UK.
[60] Redmill, F., Chudleigh, M. and Catmur, J., 1999. System Safety: HAZOP and Software HAZOP. John Wiley and Sons Ltd; ISBN: 0471982806
51
52
[61] Rumbaugh, J., Jacobson, I. and Booch, G., 1999. The UML Reference Manual. Addison Wesley.
[62] Schneier, B., 1999. Attack Trees. Dr. Dobb's Journal December 1999. Available from: http://www.ddj.com/articles/1999/9912/
[63] Sindre, G. and Opdahl, A.L., 2000. Eliciting Security Requirements by Misuse Cases. In: Proceedings of TOOLS Pacific 2000, 20-23 Nov. 2000 (120-131).
[64] Srivatanakul, T., Clark, J., and Polack, F. 2004. Security Zonal Analysis. Technical Report, YCS-374, Department of Computer Science, University of York, 2004.
[65] Trusted Computer System Evaluation Criteria, a.k.a. “The Orange Book” DoD 5200.28-STD, December 1985 (supersedes 1983 CSC-STD-00l-83). http://www.radium.ncsc.mil/tpep/library/rainbow/5200.28-STD.html
[66] UK Ministry of Defence, 1996. Defence Standard 00-56 Issue 1: Safety Management Requirements for Defence Systems.
[67] UK Ministry of Defence, 1996. Defence Standard 00-56 Issue 2: Safety Management Requirements for Defence Systems.
[68] UK Ministry of Defence, 1996. Defence Standard 00-58: HAZOP Studies on Systems Containing Programmable Electronics.
[69] Winther, R., Johnsen, O-A., and Gran, B.A., 2001. Security Assessments for Safety Critical Systems using HAZOPs. In: Proceedings of SAFECOMP 2001, Budapest, Hungary.
![On describing tense and aspect systems. A review …linguistica.sns.it/QLL/QLL02/rass.Aaron,Eisele,Mreta.pdf1 [Fonts usati: Times, IPAKiel, Symbol] On describing tense and aspect systems.](https://static.fdocuments.us/doc/165x107/5e934abdbb4a0c1ac30411f5/on-describing-tense-and-aspect-systems-a-review-eiselemretapdf-1-fonts-usati.jpg)
