infrastructural map for information security · 2015-01-08 · infrastructural map for information...

Infrastructural Map for Information Security

Sabah Al-Fedaghi Computer Engineering Department

Kuwait University Kuwait

Hanaa Alnashwan Computer Engineering Department

Kuwait University Kuwait

Abstract—The threat modeling process starts with the phases of identifying critical assets, creating an architecture overview, and decomposing to identify possible points of attack. Data flow diagrams and sequence diagrams are used in this process. This paper proposes an alternative flow-based methodology for building an architectural map for the system. It provides a high-level methodology for creating a blueprint of the organization to guide security planning in the network.

Keywords-conceptual model, information security, software lifecycle, threat modeling, network architecture, data flow diagrams, UML

I. INTRODUCTION

Threat modeling is an iterative process that encompasses various stages of software development and

continues throughout its life cycle. According to Olzak [11], the description of the threat modeling process involves a hybrid model that comprises six phases: (1) Identify critical assets, (2) Decompose the system to be assessed, (3) Identify possible points of attack, (4) Identify threats, (5) Categorize and prioritize the threats, and (6) Mitigate. Identifying critical assets entails listing “all critical assets and the systems on which they reside” [11]. Decomposing the system denotes selecting a system for which a threat model is being created.

Meier et al. [10] describe a three-stage process: (1) Identify assets; (2) Create an architecture overview that includes subsystems, trust boundaries, and data flow; and (3) Decompose the application. Creating an architecture overview requires developing an application architecture diagram that conveys the composition and structure of the “application and its subsystems together with its deployment characteristics… [with] details about the trust boundaries, authentication, and authorization” [10]. Identifying data flow involves the following:

[Start] at the highest level and then iteratively decompose the application by analyzing the data flow between individual subsystems… Data flow diagrams (DFDs) and sequence diagrams can help with the formal decomposition of a system. A DFD is a graphical representation of data flows, data stores, and relationships between data sources and destinations. A sequence diagram shows how a group of objects collaborate in terms of chronological events. [10]

Security-enhanced DFD is used to identify data entry points, the system pipelines with information/data sources and destinations, data processing phases, and trust boundaries in the system [13].

This paper maintains this level of detail in the process of threat modeling. It proposes a methodology for drawing an architectural overview based on the notion of flow instead of DFD and sequence diagrams. The resultant map can be used as an initial approach to reason about security, to enhance and reuse security expertise, and to identify security design flaws during development [1] [8].

Sabah Al-Fedaghi et al. / International Journal on Computer Science and Engineering (IJCSE)

ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 789

A. Problem

B. IT Company Example

As a starting point, we consider an actual medium-sized company in Kuwait with a network that can be described as shown in Fig. 1, which shows an external border router (R) linked to an Internet service provider (ISP). This router connects to an external switch (SW1) and firewall (FW1). These elements form the first layer of defense for public services, e.g., mail services, DNS, Web sites, and all the servers located behind the firewall in a separate DMZ.

The mail server is also controlled by an anti-spam device; furthermore, another DMZ for the external servers is accessed from outside. The internal interface for the external firewall is connected to the internal firewall as a second layer of defense to provide control of internal servers, databases (for external server), and LAN users. IPS sensors are also located in different places in the network to sniff all packets and detect known attacks. The IPS is located in the DMZs for the internal and external firewall. There is an active directory as a domain to control all users’ workstations and laptops.

Fig. 1 represents essentially the hardware connections in the network. Security points are dedicated by

hardware-oriented considerations without attention to conceptual flows and relationships. As one example of the consequences of basing security considerations on such a hardware-oriented view, consider the following:

Fig. 2 shows a partial view of Fig. 1 with DB Applications and Database server marked with dotted ovals. Both are accessed from outside by customers, as indicated by the thick links in the figure. The designers of the network located the application in DMZ, behind perimeter firewall 1, while the database server is located inside the network behind core switch SW3.

The network diagram does not indicate the logical link between the Database server and the DB applications. This allows a security hole in the system where an attacker can attack the DB Applications and use this to attack the Database server. This security hole was actually discovered after the system was seriously compromised.

Of course such lapse in design could have been recognized by more careful designers, as shown in the next example; however, dependence on a hardware-oriented architecture map contributed to such difficulties.

Users PC

SW

ACC application

ACS LMS

SERENAERP ACC DB

SW

WWW DNS MAIL

SW1

SW

FW1

FW

IPS

IPSSW

SW Anti Spam

Users PC

Users PC

Figure 1. Diagram of company network.

Core SW

SW

SW

R

Users PC

SW4

DB applications SERENAERP Database server

SW6

SW1 SW2

FW1 FW2

IPS SW3

Users PC

Figure 2. More detailed view of part of the company network shown in Fig. 1.

SW5

R


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 790

C. Better Approach but Still Hardware Oriented

Consider the following example, given in [11], representing a more methodological approach that supplements a hardware-oriented network by investigating logical data flows embedded in the system. Analysis of a given financial system decomposes it according to a network diagram that is a variation of the UML standards and includes two types of connections: the actual hardware connectivity and logical flow of data (see Fig. 3). The logical connection is represented in the figure by the large arrow between the Web server and the Application server. Apparently, the method used to develop this network diagram can be roughly described as follows. 1. Start with the hardware diagram as designed by network engineers. 2. Inspect the diagram for possible logical connects between hardware components.

Olzak [11] also produces a functionality (interaction) diagram (see Fig. 4). “This functionality diagram uses a DFD (Data Flow Diagram) approach to show the functional relationships between the various system components” [11].

Identifying possible points of attack includes the identification of attack points (trust boundaries) such as system interfaces with the rest of the world. “A trust boundary separates processes, system components, and other elements that have different trust levels… Trust boundaries also exist at all entry points into the system” [11]. A trust boundary is the point in the stream of flow where the two sides of the line have different trust levels. Fig. 5 shows the network diagram for the financial system shown in Fig. 3 with trust boundaries added.

This approach is based on the hardware network as a starting point and does not represent a systematic process since it involves heterogeneous diagrams that need multiple skills. The quality of the decomposition method depends on the quality of the hardware configuration and also on the level of knowledge of the security engineers of the logical data flows among components of the configurations.

This paper proposes a methodology that avoids these difficulties by establishing a conceptual non-hardware foundation for drawing an architectural overview based on the notion of flow.

Form Content

Browser Security database

System administrator

Web server

Application server

Figure 4. Functionality diagram (partial from [10]).

Form Request

Authentication Account configuration

Logs Log data

Procedure call

Requested data

Financial database

Request for data

Requested data

Database server

Multiple floor corporation

office

Financial system network

Customer workstations Customer

workstations Customer workstations

Floor switch

Firewall

Router

Web server Application

server

Data centre

Fiber

Figure 3. Sample network diagram of a financial system (partial from [11]).

DISK

To Internet

Database server

Logical data flow

Enterprise core

switch

Logical

data flow

Customer workstations Customer

workstationsCustomer workstations

Floor switch

Enterprise core switchFirewall

Router

Web server

Application server

Data centre Fiber

Figure 5. Network diagram with trust boundaries (partial from [11]).

DISK

ToInternet

Database server

Multiple floors

Corporation office


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 791

II. ARCHITECTURE AND SYSTEM

The relevant dictionary [14] definition of architecture is - “a framework or structure that portrays

relationships among all the elements of the subject force, system, or activity,” and in computer science, “the arrangement of the various devices in a complete computer system or network,” and - “the internal organization of a computer's components with particular reference to the way in which data is transmitted.”

Thus, architecture encompasses the organizational topology of the system, in addition to internal

organization of its components. This conception of architecture is suitable from the security point of view because it provides the security designer a complete picture of all “territories” with security significance. It includes all computers, with all related servers, routers, switches, operating systems, user workstations, etc.

Additionally, the network, software, and organizational units (e.g., human user, department) are all

included in the architecture. The totality, as well as each of these “things,” is the system. Consequently, we need to find a workable description for a system that can be used in all these ways.

We next propose such a characterization based on the notion of flow. The resultant model is used to draw a grand conceptual (application-independent) picture of the architecture of the system that would be used for security planning, as discussed previously in Meier et al.’s [10] step (2), which states, “Create an architecture overview that includes subsystems, trust boundaries, and data flow,” and in Olzak’s [11] three steps: (1) Identify critical assets, (2) Decompose the system to be assessed, and (3) Identify possible points of attack.

Additionally, our proposed flow-based system includes dynamic features that can serve in mapping data flows, data stores, relationships between sources and destinations, and collaboration of objects in terms of chronological events. That is, it can be used instead of such tools as DFD and sequence diagrams.

III. FLOWTHINGS MODEL (FM)

We propose that the basic feature characterizing systems of interest in architecture for security planning is flow. In the famous Knowledge Pyramid, data, information, knowledge, and wisdom are all “things that flow.” “Things that flow” are things that have exactly six states at any given time: arrived, accepted, processed, created, released, and transferred, as shown in Fig. 6, called a flowsystem. The word state here denotes a condition, as in states of water: liquid, vapor, and solid. The material presented in this section is a summary of many publications (e.g., [2, 3, 4, 5, 6, 7] and included here to make the paper self-contained.

A. Basic Description

Consider the states of a flowthing such as data. At any moment within the system it is in one and only one of the six states, as follows:

The data has just been created. Creation here means that it did not previously exist in the system, but the system then generated it. For example, a thermometer generates data indicating the temperature is 40 (not necessarily exhibiting it), a human being generates a new poem, mining software generates the result that John is a risk. Certainly, such data:

- did not arrive and was not accepted from outside the system, so it is not in a received state, - has not been processed (however, it may be the result of processing – e.g., data mining), so it is not in a

processed state, - is not released, or transferred outside the system (e.g., the poet has not yet spoken or written the poem; it is

still in his/her mind, or the software program has not output the results of data mining but retains it in storage). So, the data is in the created state, but not in the other five states.

Figure 6. Flowsystem diagram

Transferred

Released

Created

Arrived

Processed Accepted


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 792

Suppose that data x has just arrived from another system; the data, currently, is thus not in a created state. It has not been accepted by the system and can still be rejected because of some error and “returned to sender.” It is certainly not in the processed state because it has not yet been used in any process (translation, comparison, inspection, etc.). It is not in a created state because the system did not create it; rather, it was received from outside. Also, such data is not in the released state, because the system (after accepting it) has not released it to the outside. It is also not in the transferred state because the transfer stage was finished when it arrived in the system.

We can do similar analyses for all six states. Note that “processing,” here, means “working on” the piece of data that may result in changing, say, its form (e.g., decimal to binary) without producing new data; thus these six states exclude each other. Furthermore, there are no more than these six states.

Consider the data being stored. A stored state is not a basic state because received data can be stored, processed data can be stored, created data can be stored, released data can be stored, and transferred data can be stored (e.g., the channel’s buffer).

Accordingly, a flowsystem can be constructed as in Fig. 6, and each of the six states can be called a stage of the flowsystem. Flow here denotes the pathway by which a flowthing is transformed from one state to another. The model embeds many notions such as copying (one flowthing becomes two), destruction (disappearance of a flowthing), delaying/ waiting (imprisoning in a state), etc. All these conditions can happen at any state of the model.

In the FM model, the environment of the flowsystems is called a sphere. For example, the sphere of a seller includes an orders flowsystem, an invoices flowsystem, and a payment flowsystem.

B. Examples

As an example, Fig. 7 shows the flowsystem of a “dumb terminal” system (a sphere with one flowsystem). It does not have processing or creation stages.

Dumb terminals are usually described as having no “intelligence” (processing) and depend entirely on the

computer to which they are connected for computations, storage, and retrieval. Also, such a system does not generate (create) any type of data. It simply receives (arrival + acceptance) and releases/transmits data. “Release” can be instantaneous; that is, as soon as the data is released, it is transmitted. Some terminals have some type of storage in the form of a buffer that preserves the data in case of transmission breakdown – as in the case of a printer that stores data when the paper runs out.

To simplify diagrams, the states of arrived and accepted can be merged into a received state under the assumption that every arriving flowthing is accepted. Similarly, the release and transfer states can be merged into a communicated state.

Fig. 8 shows a sample process represented by the well-known data flow diagram (DFD) [9]. For comparison purposes, the flow-based representation is shown in Fig. 9. There are two spheres:

Customer, and Seller. Each includes three flowsystems: Orders, Invoices, and Payments. Customer and Seller each create, receive, process, and communicate these flowthings. Each stream of flow forms a pattern of activities that can be utilized to identify various security-sensitive points. Furthermore, each flow triggers another flow, denoted by dashed arrows.

IV. APPLYING FM TO ARCHITECTURE DIAGRAMS

In this section, we apply the FM methodology to the two networks discussed in the second section.

Transfer Dumb terminal

ReleaseAccept

Figure 7. Flow-based dumb terminal conceptualization.

Arrive

Customer Process order

Credit approval

Item details

Orders

Invoices

Customer data

Figure 8. Example of data flow diagram (from [9]).

Inventory data


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 793

A. The IT Company Example

Fig. 10 shows the FM description of the diagram of the company network shown in Fig. 1. Routers, switches,

servers, users’ PCs, and other components are conceptualized as flowsystems. Other involved entities such as the super user, software applications, and special groups of users are represented uniformly in this formalism.

Fig. 10 appears more complex than diagrams such as the IT company’s network diagram (Figs. 1, 2) or Olzak’s [11] figures 3, 4, and 5 because it includes more details than are shown in these diagrams. In FM, if we are interested in lumping the details (i.e., internal structures of spheres), we can erase all stages and unify all types of flow in the model, but such a description would be like describing the connections (of all types of flow) between floors in drawings of buildings with one type of box and arrow. FM brings internal details up to the conceptual level for security analysis; however, FM details are also suitable descriptions for bridging the gap between IT expert and user, analogous to detailed construction drawings understood by owners as well as by engineers.

The FM-based architectural view offers a unified conceptual picture that can be used for fine-grained depiction of the security aspects of the system. It compels the designer to base security considerations not only on physical links, but also on all individual flows and their types. It also guarantees identification of all components, interfaces, and user access points, and any interdependencies with other systems.

FM is a high-level conceptual description that is drawn according to logical relationships that specify flows among spheres. Consider the flows of an outside user (through the Internet) of the database applications. Fig. 11 is the FM representation of such flows.

CommunicateOrder

Figure 9. Flow-based conceptualization of Fig. 8.

Create Receive

Invoice Process

Order Process

Receive

Create Invoice Receive

Payment Process Create

Payment

Customer sphere

Seller sphere

Communicate

CommunicateCommunicate

Communicate Communicate

FS

ISP Anti- Spaming

S

SERENA

TAA C

T

CRc

F

Users PCs

Users PCs Database server

IPS ROUTER

FW SWSWCore SW C

RCR

CR T

CR

IP T

CR

c

S Tr

C

R

c

CR

S SWT

CRc r

TrC

R

cc

T

CRAA

WWW T

CR

DNS T

C

ccR

Mail T

CR

cTr

C

RTrC

R

TrCrR

r

TrCR

c r

T

CRA A

T

CR

T

CR

Tr

CR

c

SW

S

ER CR

c r

Tr

CR

c

SW

ACS LMS

ISP

FW

T

CR

APPLICATION

SERENERP

SW T

CRA A

Figure 10. The network diagram of Fig. 1 as a flow-based diagram

TC

Rc

R

cc r


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 794

B. Financial System Example

Next, we examine the flow-based version of Olzak’s [11] network diagram given in the introduction. We have made no attempt to redesign the network; rather our aim is to reconceptualize the design based on the FM description. Using the hardware based architecture map of Fig. 5, it is possible to make a FM–based description of this financial system with trust boundaries. However, The FM approach introduces one integrated picture for network and functional (Figs. 3 and 4) features in preparation for the next step in the security analysis. In FM, there is no need for different hardware network, UML, and DFD diagrams. The FM description is based completely on a logical view of flows involved in the system. Clear analysis of these flows will result in explicit representation of the flows between the Web server and application server. This can be discovered even before establishing the hardware network, at the requirement analysis phase.

Consider the DFD functional diagram in Olzak’s Fig. 4. The trust boundaries can be located only between

system components. The diagram is almost identical to the network diagram (Fig. 3) after switches and firewalls are removed. System administrator and log are introduced artificially without affecting the issue of trust

Figure 11. A non-hardware based FM conceptual description that is drawn according to logical relationships and trust boundary.

Communicate

Outside user

Create

ProcessReceive

Request

Response

Receive

Process

Receive

Database application Database application

Process

Receive

Communicate Communicate Communicate

Communicate CommunicateCommunicateCommunicate

TRUST BOUNDARIES

Web server

Communicate

Com

municat

Arrive

Accept

Accept

Authentication

Request

Authentication

Communicat

Request

Record Id

Communicat

Record

Receive

Application Database

Process

Com

municate

Arrive

Accept

Arrive

Process

Communicat

Com

municate

Com

municate

Accept

Com

municate

Process

Com

municat

Arrive

Accept

Arrive

Releas

Communicat

Database

Arrive

Communicat

Record IdRecord Id

Request

RecordRecord

Com

municat

Arrive

Accept

Authentication

Form Content

Application server

(a) DFD description [11].

Form Request Authenti

cation

Procedure call Requested

data

Financial database

Request for data

Requesteddata

Database server

Web server

Figure. 12. DFD Functionality Diagram and FM Diagram

(b) FM description

1

2

3

4

5

6

7

8

9

10

11

12

10


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 795

boundaries, which can be deduced from the network diagram only. Some arrows represent flow; others, such as those between Web server and Browser, and LDAP security DB, are unlabeled. DFD can be considered a very rough representation of various flows in the system.

In contrast, we focus on the main flows among Web server, Application server, and Database server. Fig. 12(a) shows this portion of the DFD diagram, and Fig. 12(b) shows the corresponding FM description. Without loss of generality, suppose that the requests are about records in the database. Thus, there are three flowthings in each transaction: authentication information, type of request (access type), and record identifier. Additionally, there is the flow of records in case of approved access.

Thus, flow starts with sending authentication, access type, and record ID (flowsystems circles 1, 2, and 3,

respectively) from Web server to Application server. At the authentication flow system (circle 4), authentication information arrives but is not necessarily accepted (trust boundary denoted by dotted line); however, if it is accepted, it triggers (dashed line) acceptance of the corresponding (to authentication) request, otherwise the request is rejected even before it is accepted in the system (trust boundary). The access request at the acceptance stage is examined, and if the request is approved (i.e., the sender of the request is authorized to retrieve, delete, update records), this triggers acceptance of the record ID at flowsystem 7.

Then, we assume that the authentication and the request record ID are all sent to the Database server (circles 9, 10, and 11). It is possible that the authenticated request is acceptable as a user in the application server, but not at the database server. It is also possible that the types of operations permitted for a certain user are authorized in the application server, but not in the database server. At flowsystem 12, records are accessed, transferred to the application server, then to the Web server.

In this scenario, the FM representation presents a fine-grained notion of trust boundary. In any flowsystem, arrived flowthings are distrusted until they are examined to approve their flow within the system. In FM, trust boundaries are connected to access control methodology.

V. CONCLUSION

This paper has utilized a new information flow model for identifying critical assets, creating an architecture overview, and decomposing the system to identify possible points of attack. It presents a complete description of information flow.

FM comprises a limited number of information states with precise transition links. Furthermore, the model distinguishes explicitly between different types of flow through a triggering mechanism. We have demonstrated that it presents a more complete descriptive methodology than some proposed diagrams. Security policies and constraints can be declared to control the flow in the stream of information flow.

REFERENCES [1] M. Abo-Antoun, D. Wang, and P. Torr, “Checking threat modeling data flow diagrams for implementation conformance and security,”

Proceedings of the Twenty-second IEEE/ACM International Conference on Automated Software Engineering, 2007, pp. 393-396.

[2] S. Al-Fedaghi and K. Al-Enazi, “Extracting security requirements from reality,” 3rd International Conference on Computer Research and Development (ICCRD 2011), March 11–13, 2011, Shanghai, China.

[3] S. Al-Fedaghi, “Software requirements as narratives,” Third International Conference on Information, Process, and Knowledge Management, February 23-28, 2011, Gosier, Guadeloupe, France.

[4] S. Al-Fedaghi and Y. Al-Abduljader, “Alternative conceptualization of objects in the requirement analysis phase of the software development life cycle,” 2010 Second International Joint Conference on Computer and Communication Technology (IJJCCT 2010), 27-28 December 2010, Jeju Island, Korea.

[5] S. Al-Fedaghi, “System-based approach to software vulnerability,” The IEEE Symposium on Privacy and Security Applications (PSA-10), Minneapolis, USA, 2010.ftp://ftp.computer.org/press/outgoing/proceedings/SocialCom%202010/data/4211b072.pdf

[6] S. Al-Fedaghi and A. Alrashed, “Threat risk modeling,” 2010 International Conference on Communication Software and Networks (ICCSN 2010), Singapore, 26-28 February 2010.

[7] S. Al-Fedaghi, “Conceptualizing software life cycle,” 8th International Workshop on Conceptual Modelling Approaches for e-Business (eCOMO 2009), Sydney, Australia, 21-24 April 2009.

[8] M. Howard, and S. Lipner, The Security Development Lifecycle. Microsoft Press, 2006.

[9] P. Kejriwal, Elements of System Analysis and Design, Laynetworks, accessed 2010.http://www.laynetworks.com/use%20case%20vs.%20dataflow%20diagram.htm

[10] D. Meier, A. Mackman, M. Dunner, S. Vasireddy, R. Escamilla, and A. Murukan, “Improving Web application security: Threats and countermeasures,” Chapter 3 in Threat Modeling. Microsoft, 2003. http://msdn.microsoft.com/en-us/library/ff648644.aspx

[11] T. Olzak, “A practical approach to threat modeling,” March 2006. http://adventuresinsecurity.com/blog/wp-content/uploads/2006/03/A_Practical_Approach_to_Threat_Modeling.pdf \

[12] J. Rosnay, “The systemic revolution: A new culture,” Chapter 2 in The Macroscope. Harper & Row, 1979.http://pespmc1.vub.ac.be/macroscope/chap2.html

[13] E. Yourdon, Structured Analysis. Prentice Hall, 1988.

[14] The Free Dictionary. Farlex, 2010. http://www.thefreedictionary.com/architecture


ISSN : 0975-3397 Vol. 3 No. 2 Feb 2011 796

infrastructural map for information security · 2015-01-08 · infrastructural map for information...

Documents