1

A Simple Enterprise Security Architecture (SESA): Towards a Pedagogic Architecture for

Teaching Cyber Security

Harjinder Singh Lallie

E-Security Group, WMG, University of Warwick, Coventry, CV4 7AL, UK, h.s.lallie@warwick.ac.uk

Abstract

Enterprise Security is a highly complex issue which is complicated further by conflicting views of the different elements of cyber security which are often represented as a while in terms of an architecture or model. In this paper we consider a number of approaches to defining architectures in the computer science domain and determine a number of architectural guiding principles from these. We consider a number of approaches to defining cyber security architectures and propose a Simple Enterprise Security Architecture (SESA) which encompasses security from the strategic through to the protocol level in three simple layers. Keywords: Enterprise security; Security architecture; Security models

1 Introduction Architectural approaches have been used within the computer science domain to allow for a more thorough understanding of the individual components and processes within a digital system and in particular the manner of interaction between the components and processes. Defining a complex system through an architectural viewpoint serves a very useful pedagogic value in the classroom as it can help to relay often complex technical concepts more easily to students. This approach also helps to demonstrate elements of the security system from the viewpoint of the various stakeholders. That said however, architectural approaches to defining security systems are in their infancy and there is room for clearer and simpler proposals which can serve particular value in the classroom. Security architectures have previously been reviewed by Oda et al who approach the issue of security architectures by considering how security is built into the core enterprise architectures [4]. Shariati et al reviewed a number of architectures and frameworks including the Gartner, SABSA, RISE and SOAE Security Governance frameworks [5]. In this paper we review a number of approaches in order to demonstrate their shortcomings as a pedagogic model that can be used in the classroom.

2

This paper highlights the importance of adopting an architectural approach towards defining a security system and considers what the guiding principles of a security architecture should be. We do this by exploring and analysing similar approaches in other computer science domains such as network engineering, computer systems, software engineering and digital forensics. Based on those guiding principles we propose a Simple Enterprise Security Architecture (SESA) which considers the security system as a simple three layered hierarchy. The rest of this paper is structured as follows. We begin in Section 2 by clarifying some of the terminology used in the domain, we proceed in section 3 to highlight the importance of adopting an architectural approach to designing a security system. In the same section we explore approaches to architectural definition in other areas of computing. This gives us the benefit of considering the views and approaches of experts in other fields some of which are more mature in terms of the development of the disciplines and philosophies. Ultimately, the purpose of this is to establish some of the guiding principles used in those domains to influence architectural models. In section 4, we proceed to exploring and critiquing two holistic approaches to defining security architecture. Finally, in section 0 we propose a simpler model for a security architecture and in doing so consider the views presented by other writers in the context of each layer of the proposed architecture.

2 Defining terms A number of terms such as architecture, design, framework, model, process and implementation have tended to be used interchangeably – often to mean the same thing. Such usage needs to be clarified. Eden and Kazman argue that whilst a similar array of terms are used within the software engineering industry, the terms are not well-defined enough and can cause miscommunication [6]. This is an issue that also applies within the cyber security domain wherein there is scope for miscommunication most particularly in understanding the distinctions between security architecture, design and implementation. A good designer may not necessarily be a good implementer and maintainer of the system. In the same way as a network administrator may be gifted in troubleshooting security related issues but may not necessarily be a good architect of a new system. An example of the confusion cause by the misuse of terms is typified by Talukder and Chaitanya who whilst appearing to speak about secure software systems architecture and the need to understand architectural principles in designing secured systems, the authors focus instead on design principles and give little or no consideration to architectural principles [7]. Eden and Kazman’s view can also be illustrated by the approach taken by Whitman [8] who in defining security architecture models proposes a number of examples of these as being:

• The Trusted Computer System Evaluation Criteria (TCSEC). A DoD standard that defines the criteria for assessing access controls in a system.

• The Information Technology Security Evaluation Criteria (ITSEC). A set of international criteria for evaluating computer systems.

3

• ISO/IEC 15408 – the common criteria for Information Technology Security Evaluation.

• Bell-LaPadula Confidentiality Model. • Biba Integrity Model • Clark-Wilson Integrity Model • Graham-Denning Access Control Model • Harrison-Ruzzo-Ullman Model • Brewer-Nash Model

Each of the models referred to in Whitman’s paper are unique and particular elements of a security architecture but are not an overarching enterprise wide security architecture. Indeed, it may not have been Whitman’s intention to propose this, the context is nevertheless confusing. The models referred to by Whitman can be encompassed within particular layers of the holistic security architecture that we focus on in the present paper.

2.1 Architecture, design and implementation We base our definitions of these terms on the Oxford dictionary [9]. The term architecture means “the conceptual structure and logical organization of a computer or computer-based system”. A design is a “plan or drawing produced to show the look and function or workings of a building, garment, or other object before it is made”. We can see from this that an architecture and a design are not the same thing. A model is a “thing used as an example to follow or imitate” and a framework is “a basic structure underlying a system, concept or text”. A framework or model in our view is a structure which describes or imitates a design. Whilst this may not be a conclusive definition of what it is in the present context, we can certainly be clear of what it is not. It is not an architecture nor the implementation. An implementation is the enactment of that design and the design is quite often based on the architecture, hence a systems designer may most often have an architectural blueprint of some kind from which to guide the design.

3 Architectures, models and frameworks in other computer science disciplines.

In this section we explore approaches towards defining complex systems in other computer science domains namely: network engineering, computer architecture, software architecture and digital forensics. This discussion serves two purposes, firstly to identify the benefits that architectural approaches provide within those domains and therefore whether the same may apply to approaching cyber security from an architectural viewpoint and secondly to highlight some guiding principles which influence our proposal.

4

3.1 Network architecture Architectural approaches to system definition are not new to the domain of computer science, efforts have previously been deployed in the areas of network engineering, computer architecture, software architecture, and digital forensics. Some of the models proposed in these domains have become widely accepted amongst academia and business. For instance, the ISO/OSI seven layer model is considered an academic standard in the domain of network architecture wherein the TCP/IP model has become a widely implemented practical standard. The ISO/OSI seven layer model provides students of network engineering with the conceptual constructs of a networked system, the model clearly delineates the various functions of the network and provides a mechanism for more easily understanding the communication flows between the various systems that exist within the network.

3.2 Computer architecture Similarly, computer systems also have been presented as conceptual architectures which present otherwise complex systems as logical structures that are easier to comprehend and understand. Comer highlights the importance of this approach and argues that it: makes it possible to write more efficient code that is less prone to errors, helps programmers understand the effects of their choices and also how to debug hardware issues [10]. There are benefits therefore to the designer, the user and also the person charged with the subsequent maintenance. We can see from Comer’s viewpoint that understanding the architecture in this way helps achieve efficiency and to better understand the effects of choices, furthermore it helps to troubleshoot problems. Another important viewpoint is given by the ACM who propose that students should not be encouraged to view the computer as a black box but should understand the functional components of a computer system as well as develop a good understanding of the interaction and performance of those components, this is made easier through considering the system as a layered architecture [11].

3.3 Software architecture Most of the conceptual thinking in architectural approaches in computer science has probably been proposed within the software engineering domain. Garlan notes that an architectural approach to designing software can provide significant benefits, this has resulted in numerous ‘idiomatic patterns’ some of which have been documented as industrial or scientific standards [12]. Monroe et al add that by adopting an architectural approach towards software design, the designer can enjoy the benefits of design and code reuse, previously applied tested and understood solutions can be reapplied, the system design becomes “intellectually tractable” and also helps to establish whether a proposed new system will meet its most critical requirements [13]. Gutmann [14] proposes five key software architectural design principles, the design:

• Utilises independent objects

5

• Utilises intelligent objects • Is platform independent • Isolates the internal architecture from external code • Is layered

Gutmann’s proposal highlights two fundamental architectural goals – that of the need to adopt a layered approach and to achieve platform independence. Furthermore we can see from some of the ideas presented above that the issues of software architecture and design can be separated out wherein the architecture is the highest level of abstraction.

3.4 Digital Forensics Similar research has been undertaken in the digital forensics domain wherein endeavours have been made to define the digital investigation process in a model. However the proposals in this domain are primarily models of frameworks that propose particular investigative procedures or processes and are not architectural definitions. Reith et al proposed an ‘abstract digital forensics model’ which describes the digital investigation procedure as a sequence of small processes [15]. Carrier and Spafford took this approach further, they combined the approach and preparation phases of Reith et als model and proposed a framework for investigation which subdivided key aspects of an investigation into a number of phases [16]. This research was developed further by Baryamureeba and Tushbe in their ‘Enhanced Digital Investigation Process (EIDIP) Model which divided the investigative process into five phases [17]. Similar work has been conducted by Pollitt [18], Perumal [19] and Alharbi et al [20]. There may be scope to consider the need to present the digital forensics domain as an architectural system. We can see that most of the research in the digital forensics domain has focussed on proposing an investigative model which encompasses processes of investigation rather than an architectural approach to studying and understanding the domain.

3.5 Summary Having considered some of the approaches to architecture in other domains we can establish that the consideration of a security system from an architectural viewpoint would correspondingly provide the security system designer with the ability to produce a better and more efficient design, the system administrator to better troubleshoot the problems, the practitioner to better deploy and manage the various components of the system and the decision makers to understand the trade-offs in spend and most importantly the implications thereof. From this discussion we can also establish some guiding principles in terms of what an architectural model should conform to, it must be:

• Layered so as to separate the various levels of complexity into logical, abstract and intellectually tractable components

• Platform, protocol and technology independent

6

• An abstracted architecture which does not focus on procedure but on the independent constructs of the various systems and sub-systems which contribute to the whole of the architecture

4 Previous approaches to defining security architecture

Having considered some of the approaches in other computer science disciplines, we proceed to exploring and critiquing previous attempts at defining security architectures, frameworks and models. Goldman explores the issues surrounding the development of resilient security architectures and discusses ‘architectural strategies’ and in particular outlines how resiliency can be built into such an architecture [21]. However, she does not proceed to define what she means by a ‘security architecture’ or even the characteristics of such an architecture. Notably however, Goldman makes important recommendations for critical systems which she says must be easily adaptable, scalable, replaceable, reconfigurable and recoverable in the event of an unexpected disruption, degradation or compromise of critical system components, services and/or data. Goldman also refers to the security architecture as having ‘layers’ of separation which allow for the monitoring and analysis of events, traffic and anomalous behaviour - a principle referred to by Goor as as orthogonality [22]. The ISO 7498 standard: Information Processing System-Open System Interconnections-Basic Reference Model, Part 2: Security Architecture [23] defines the concept of layering in the context of a security architecture. The standards used a number of principles to determine the allocation of security services to layers and the placement of security mechanisms in the layers as follows:

a. that the number of alternative ways of achieving a service should be minimized;

b. that it is acceptable to build secure systems by providing security services in more than one layer;

c. that additional functionality required for security should not unnecessarily duplicate the existing OSI functions;

d. that violation of layer independence should be avoided; e. that the amount of trusted functionality should be minimized; f. that, wherever an entity is dependent on a security mechanism provided by

an entity in a lower layer, any intermediate layers should be constructed in such a way that security violation is impracticable;

g. that, wherever possible, the additional security functions of a layer should be defined in such a way that implementation as a self-contained module(s) is not precluded; and

h. that this part of ISO 7498 is assumed to apply to open systems consisting of end systems containing all seven layers and to relay systems.

Here again, we are presented with a number of core architectural principles: a layered approach and the independence of those layers.

7

Figure 1. Peterson's Security Architecture Lifecycle

[2]

4.1 DSNET and MILNET One of the earlier attempts to define a security architecture was presented by Shirey [24]. This study focuses specifically on the architecture of the Department of Defense Data Network and analyses the physical network from a security viewpoint. That particular network is divided into two segments, Defense Secure NETwork (DSNET) and MILitary NETwork (MILNET). Shirey goes into significant detail and essentially describes the technical architecture of the network. It is unlikely that a network of such sensitivity (politically) could again be described to such detail.

4.2 Kiely and Petersons approaches Shirey’s study is interesting because it is one of the earliest published security architectures, it presents primarily a technical architecture devoid of the ‘human’ and enterprise elements. The domain of cyber security differs from those presented up to this point because of the way in which it encompasses every aspect of the business from the technical systems through to the people, procedures and policies of the enterprise. This has been recognised by Kiely who proposes a holistic approach towards security architecture which links up organisational strategy with technology [25]. However this approach appears to ignore the people in the organisation and also the policies in place (or lack thereof) in an organisation. Peterson defines a security architecture lifecycle (Figure 1) which focuses on: identifying the risks to an organisation, building security around this, implementing the designed system and then monitoring this [2]. Peterson’s model is a high level strategic view of security and places more emphasis on the software architecture whilst providing some consideration to risk and other aspects of business strategy. There is a clear emphasis on OWASP (Open Web Application Security Project) with little or no consideration of the technical underpinnings of such a security system.

4.3 Cohen’s model Cohen [1] proposes the Enterprise Information Protection Architecture which considers four core elements: the control architecture, technical security

8

architecture, risk/governance architecture and the business itself. An analysis of Cohen’s model (Figure 2) will show that it is over-detailed particularly in specifying discreet protection mechanisms such as firewalls and diodes. On occasion it presents conflicting messages, for instance, one might expect certain controls such as the principle of least privilege and duty separation to be implemented as part of the control architecture along with the audit and access controls, however these principles are presented as a function of the technical security architecture alongside practical implementations such as firewalls and barriers. Furthermore certain components such as the ‘auditors’, the board etc are listed in two separate sub-categories (‘oversight’ and Organizational Governance Architecture). In the case of auditors, their role and responsibility should be considered and integrated into the implementation of the audit procedure within the organizational governance architecture.

4.4 SABSA Sherwood et al proposes a model known as SABSA (Sherwood Applied Business Security Architecture) [3]. SABSA is a whole enterprise-wide socio-technical approach towards security management. SABSA is based on ISO 7498-2 – part 2 “security architecture” and is a proprietary and practical model which is used for developing enterprise security architecture and strategy. In their approach, Sherwood et al recognised that a system can be viewed through the experiences of the users, their model:

Figure 2. Cohen's Enterprise Information Protection Architecture [1]

9

“provides an overarching framework that binds them [existing methods, models and standards] all together into a single holistic view of how to design and manage enterprise security” [3].

Sherwood et al propose a layered model comprising of sub-architectural views as presented in Table 1. Each of the layers in this model can be expanded as follows: • The business view (contextual security architecture) is the strategic view

of the core business requirements from the CEO/shareholders perspective and has to govern and directly influence the development of the business security system. In the context of a business information system therefore, this is a definition of what it is, how it is used, who will use it etc.

• The architects view (conceptual security architecture). This layer guides the application security, network security, cryptographic infrastructure and access control strategies and is often referred to as the ‘consultants view’.

• The designers view (logical security architecture). The designer interprets the strategies defined above and specifies the essential components of the system

• The builders view (physical security architecture) refers to the view taken by those charged with implementing and configuring the system.

• The tradesmans view (component security architecture). This is where the model presents some problems. It is difficult to ascertain the difference between the physical and component architectures. From the SABSA models it seems that the component architecture is the system design point. i.e. the people that design the protocols, software, physical hardware etc.

• The facilities managers view (operational security architecture). This is another interesting feature of the model. The facility manager according to SABSA is the person(s) responsible for implementing and running the product.

Interestingly, the model does not seem to incorporate the users (or what they see – human interface) and we can only assume that this is accounted for within the designer/builder view. In our view, this model – like Cohen’s is overly complex and can be simplified further. One of the problems we have with this model is that the architect and designer views could be incorporated into a single layer which is effectively the consideration of the strategic requirements and their design thereof. Furthermore, the builder and the tradesman view can also be combined into a single view. That said, like the ISO/OSI seven layer model, the SABSA model is a good example of a system which can be seen from various stakeholder viewpoints. The application layer for instance is the view taken by the end user of a network component – particularly where the networking component is a user-interface. Williams explores these various viewpoints and notes that hardware engineers and programmers view the same system in different ways as do the application user, systems administrators the high level language programmers and systems programmers [26].

10

The business view Contextual security architecture The architects view conceptual security architecture The designers view logical security architecture The builders view physical security architecture The tradesmans view component security architecture The facilities managers view operational security architecture

Table 1. Sherwood Et al’s SABSA security Architecture [3]

5 A Simple Enterprise Security Architecture (SESA) We propose a Simple Enterprise Security Architecture (SESA) which encompasses the domain into 3 simple layers – Business, People and System. Each of these layers are independent of each other and devoid of any specific technical implementation details. Most of these layers are subdivided into further sub layers each of which can be used to demonstrate particular user views of the security system. The proposed architecture has been used to teach Cyber Security and has been very well received in a University Post graduate masters level course. Our proposal places the users within the basic construct of the model and presents these as layers as shown in Figure 3. Each of the layers within the proposed model are discussed herein.

5.1 Business Layer This layer encompasses the core business goals and objectives and comprises of three sub-layers: Business Requirements and Strategy, Regulation and compliance and Security Strategy. To a CEO and/or board of directors (referred to herein simply as ‘the board’), the security architecture defines a system which must

Figure 3. A Simple Enterprise Security Architecture

11

encompass and support the generic business needs of the organisation. We refer to this as the Business Requirements and Strategy sub-layer and it comprises simply of the organisational goals, strategy and its market. This is an area of cyber security that students often struggle to comprehend particularly in the context of their chosen academic discipline. In the real world however one would expect a consultant or systems designer to have a good knowledge and understanding of the business context for which they are designing a particular system. More often today their view is driven by regulatory and compliance related requirements such as ISO 27001, PCI-DSS and the Data Protection Act to name a few. The responsibility for complying generally lies at board level and correspondingly is driven through all layers of the organisation from the board downwards. We refer to this sub-layer as the Regulation and Compliance sub-layer and within it sit the raft of standards, compliance and legislation described herein. This layer interacts with the business requirements and strategy layer because organisational goals are often influenced directly by this and also with the security strategy layer because this often influences policy and security strategy, Organisational strategy is often reflected through policy which in this context relates to system use, employment and other matters. We refer to this as the security strategy sub-layer. It is useful at this point to consider the view that the board has of the security architecture. Their immediate view (in addition to the three sub-layers described above) is of the people using the system, they rarely maintain a day-to-day view of the system layer, for instance, they do not maintain a view of the hardware/component level and rarely involve themselves strategically in the selection of hardware, components or the implementation of particular protocols. This is an important point which we discuss further in this paper.

5.2 People Layer The second layer in our architecture is referred to as the people layer which comprises of a single sub layer - the human interface layer. Software/web engineers/developers develop applications which are used by the end-users within an organisation (through the HCI). The user view of a security system however has often been criticised for being neglected and being the weakest link in most security systems [27-29]. To this end, a lot of research has more recently focussed on the user view of security and focuses for instance in the areas of presenting understanding security warnings to users [30-32], the use of PINs [33] and even the colour schemes used [34]. In our architecture, the user interface is the view that end users directly see, in other words their immediate view of the security of an organisation is typically the daily usage of a system through the HCI. At the same time however, the user has two further views: the security strategy sub-layer, i.e. the policies that they must comply with, and occasionally the user security interfaces such as physical access systems and biometric systems.

12

5.3 System Layer The system layer comprises of four sub-layers, namely: User Security Interface (described above), protocols, code and component. The protocols sub-layer comprises of a very large suite of security protocols such as SSL, Kerberos, IPSEC and even the cryptographic algorithms. Such protocols exist at this level as conceptual designs and are then programmed/hard coded into the system as code (the code sub-layer) and then implemented sometimes as hardwired code within the component sub-layer. The code sub-layer encompasses the programs, applications and software based utilities that incorporate protocols as well as the system requirements. The component sub-layer involves the design of the underlying electrical components that make up the physical security systems. This layer is quite general in that we incorporate within this the various levels of hardware design which includes the hardwired coding of protocols and also the various electrical devices and components themselves. The devices that we incorporate within this level are the routers, gateways, IDS/IPS systems, firewalls etc., however we do not incorporate within this sub layer the protocols that operate within these devices – they sit in the protocol sub layer, are implemented in code in the code sub layer and then built as hardware at this sub layer.

6 Conclusions and Future work In this study we have considered a number of approaches towards defining architectures within the computer science domain. From that analysis we have established some fundamental guiding principles that should be incorporated within any architectural model. We have proceeded to analyse existing approaches towards defining security architectures and highlighted a number of benefits within these models as well as some shortcomings which often make them unsuitable for teaching Cyber Security in the classroom. We have proceeded to propose a Simple Enterprise Security Architecture which links up organisational strategy through to the underlying protocols of security architecture. Every aspect of enterprise security can be incorporated within these three layers. Whilst we have used the proposed architecture to teach Cyber Security at higher education level, we aim to develop this study further and test the architecture against given case studies so as to demonstrate its value in the classroom. Within that study we aim to further clarify the stake holder’s various views and interactions with these layers as well as the communication flows therein.

13

References

[1] F. Cohen, Enterprise Information Protection. New York, USA: Fred Cohen and Associates, 2008.

[2] G. Peterson. (2007, 8th August). Security Architecture Blueprint Available: http://arctecgroup.net/pdf/ArctecSecurityArchitectureBlueprint.pdf [3] J. Sherwood, A. Clark, and D. Lynas, Enterprise Security Architecture, A

Business-Driven Approach. CA, USA: CMP Books, 2005. [4] S. M. Oda, H. Fu, and Y. Zhu, "Enterprise information security architecture a

review of frameworks, methodology, and case studies," in 2nd IEEE International Conference onComputer Science and Information Technology, Beijing, China 2009, pp. 333-337.

[5] M. Shariati, F. Bahmani, and F. Shams, "Enterprise information security, a review of architectures and frameworks from interoperability perspective," Procedia Computer Science, vol. 3, pp. 537-543, 2011.

[6] A. H. Eden and R. Kazman, "Architecture, design, implementation," in 25th International Conference on Software Engineering, Portland, Oregon, USA, 2003, pp. 149-159.

[7] A. K. Talukder and M. Chaitanya, Architecting secure software systems. New York, USA: CRC Press, 2008.

[8] M. E. Whitman and H. J. Mattord, Management of Information Security. KY, USA: Course Technology Ptr, 2010.

[9] Oxford University Press. (2010, 11th January). Oxford Dictionaries. Available: http://oxforddictionaries.com

[10] D. Comer, Essentials of Computer Architecture. New York, USA: Pearson/Prentice Hall, 2005.

[11] E. Roberts, G. Engel, C. Chang, J. Cross, R. Shackelford, R. Sloan, D. Carver, R. Eckhouse, W. King, and F. Lau. (2001, Computing Curricula 2001: Computer Science. Available: http://www.acm.org/education/curric_vols/cc2001.pdf

[12] D. Garlan and M. Shaw, "An introduction to software architecture," Advances in software engineering and knowledge engineering, vol. 1, pp. 1-40, 1993.

[13] R. T. Monroe, A. Kompanek, R. Melton, and D. Garlan, "Architectural styles, design patterns, and objects," Software, IEEE, vol. 14, pp. 43-52, 1997.

[14] P. Gutmann, Cryptographic security architecture: design and verification. New York, USA: Springer-Verlag New York Inc, 2004.

[15] M. Reith, C. Carr, and G. Gunsch, "An examination of digital forensic models," International Journal of Digital Evidence, vol. 1, pp. 1-12, 2002.

[16] B. Carrier and E. H. Spafford, "An event-based digital forensic investigation framework," in 4th Digital Forensic Research Workshop, Baltimore, Maryland, USA, 2004, pp. 11-13.

[17] V. Baryamureeba and F. Tushabe. (2004, 3rd November, 2011). The Enhanced Digital Investigation Process Model. Available: http://www.forensicfocus.com/enhanced-digital-investigation-model

[18] M. M. Pollitt, "An ad hoc review of digital forensic models," in Second International Workshop on Systematic Approaches to Digital Forensic Engineering, Seattle, Washington, USA, 2007, pp. 43-54.

[19] S. Perumal, "Digital forensic model based on Malaysian investigation process," International Journal of Computer Science and Network Security, vol. 9, p. 38, 2009.

[20] S. A. Soltan Alharbi, J. W. J. Jens Weber-Jahnke, and I. T. Issa Traore, "The Proactive and Reactive Digital Forensics Investigation Process: A Systematic

14

Literature Review," International Journal of Security and Its Applications, vol. 5, pp. 59-72, 2011.

[21] H. G. Goldman. (2010, 10th January, 2012). Building Secure, Resilient Architectures for Cyber Mission Assurance. Available: http://www.mitre.org/work/tech_papers/2010/10_3301/10_3301.pdf

[22] A. J. C.-d. Goor, Computer Architecture and Design. New York, USA: Addison Wesley, 1989.

[23] ISO, "7498," in Information Processing System-Open System Interconnections-Basic Reference Model, Part 2: Security Architecture, ed: ISO, 1984.

[24] R. W. Shirey, "Defense Data Network Security Architecture," ACM SIGCOMM Computer Communication Review, vol. 20, pp. 66-72, 1990.

[25] L. Kiely and T. V. Benzel, "Systemic security management," Security & Privacy, IEEE, vol. 4, pp. 74-77, 2006.

[26] R. Williams, Computer systems architecture: A networking approach. New York, USA: Prentice Hall, 2006.

[27] S. L. Pfleeger, "Making Security More Usable," The Innovator, vol. 4, 2011. [28] M. F. Theofanos and S. L. Pfleeger, "Guest Editors' Introduction: Shouldn't All

Security Be Usable?," Security & Privacy, IEEE, vol. 9, pp. 12-17, 2011. [29] D. Schutzer, "Bits and Bytes: Understanding Human Behaviour," The Innovator,

vol. 4, 2011. [30] J. Sobey, P. van Oorschot, and A. S. Patrick, "Browser Interfaces and EV-SSL

Certificates: Confusion, Inconsistencies and HUMAN INTERFACE Challenges," Technical Report TR-09-02 (January 15, 2009), School of Computer Science, Carleton University, Canada2009.

[31] R. Biddle, P. Van Oorschot, A. S. Patrick, J. Sobey, and T. Whalen, "Browser interfaces and extended validation SSL certificates: an empirical study," in The 2009 ACM workshop on Cloud computing security Chicago, IL, USA, 2009, pp. 19-30.

[32] M. E. Maurer, "Bringing effective Security Warnings to mobile Browsing," presented at the Second International Workshop in Security and Privacy in Spontaneous Interaction and mobile Phone Use (IWSSI/SPMU), Helsinki, Finland, 2010.

[33] S. Brostoff, P. Inglesant, and M. A. Sasse, "Evaluating the usability and security of a graphical one-time PIN system," in 24th BCS Interaction Specialist Group Conference University of Abertay, Dundee, UK, 2010.

[34] A. S. El Ahmad, J. Yan, and U. o. N. U. T. C. Science, "Colour, usability and security: a case study," Citeseer, School of Computing Science, University of Newcastle upon Tyne, UK2010.