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

Download Infrastructural Map for Information ?· 2015-01-08 · Infrastructural Map for Information Security…

Post on 24-Jun-2018




0 download

Embed Size (px)


  • Infrastructural Map for Information Security

    Sabah Al-Fedaghi Computer Engineering Department

    Kuwait University Kuwait

    Hanaa Alnashwan Computer Engineering Department

    Kuwait University Kuwait

    AbstractThe 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


    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.













    SW AntiSpam



    Figure 1. Diagram of company network.






    DBapplicationsSERENAERP Databaseserver





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



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

    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


    Financial system network

    Customer workstations Customer

    workstations Customer workstations

    Floor switch



    Web server Application


    Data centre


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


    To Internet

    Database server

    Logical data flow

    Enterprise core



    data flow

    Customer workstations Customer

    workstationsCustomer workstations

    Floor switch

    Enterprise core switchFirewall


    Web server

    Application server

    Data centre Fiber

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



    Database server

    Multiple floors

    Corporation office