ABSTRACT1. INTRODUCTION2. A REFINED NETWORK SECURITY DEVELOPMENT MODEL3. THE REFINED MODEL IN ACTION4. SUMMARY AND FUTURE WORK5. ACKNOWLEDGEMENT6. REFERENCESNETWORK SECURITY DEVELOPMENT PROCESS - A Framework for Teaching Network Security Courses T. Andrew Yang, Tuan Anh Nguyen Univ. of Houston – Clear Lake, Houston, Texas Contact: (281) 283-3835, [email protected] ABSTRACT Teaching Network Security course is a challenging task. One of the challenges is that networks have become more complicated and prone to attacks. In response to the challenge, the set of networking and security protocols and mechanisms continue to evolve, increasing the number of security technologies a network engineer needs to master in order to secure a network. This paper describes our experience of applying a network security development model to developing a network security lab. Developing network security is an iterative process, encompassing the analysis of vulnerabilities and threats, construction of policies, design of network architecture, integration plan of control measures, implementation of the design, and the operation and maintenance of a secure network. While Network Security has become an increasingly complicated topic to teach, we have learned from experiences the significance of a well-defined network security development process for teaching the development of secure networks. 1. INTRODUCTION Efforts have been made to design network labs for testing computer and network security principles and practices. Padman, etc. [2], for example, present their design of the ISIS Lab as a model of highly reconfigurable laboratory for information security education. In order to develop a secure networking lab for teaching and research (henceforth, the Lab), we decided to adopt a formal network security development process [1]. As illustrated in Figure 1, the model consists of seven steps: (a) Asset Identification: To identify what should be protected. (b) Threat Assessment: To determine what you are trying to protect the network from. (c) Risk Assessment: To determine how likely the threats are. A risk rating between 1 (lowest) and 5 (highest) is assigned to each of the assets with respect to each of the security goals (confidentiality, data integrity, origin integrity, non-repudiability, and availability) [3]. (d) Policy Construction: To construct network security policies, based on the risks. (e) Network Security Design: To design the network security architecture and the control measures, in order to enforce the defined policies. (f) Network Security Implementation: To implement the design and integrate the mechanisms. (g) Audit and Improvement: To review the process continually and make improvement each time a weakness or a threat is found, or when an asset is added or changed. As shown in Figure 1, the development process is iterative, meaning it is often necessary to revisit an earlier stage in order to rectify the existing requirements, design, or deployment of the network. Our experience has shown that, although the development model is useful in guiding the development process, there still exists in the model roomfor improvements. In the rest of this paper, we first describe the refined model (Figure 2), and then our experience of using the model in developing the Lab. The paper concludes with a summary and possible future work. 2. Asset/Resource Identification3. Threat Assessment4. Service – AssetRelationships8. Implementation5. Risk Assessment for: a. Services b. Resources6. Policy Construction7. Network Security DesignAbortStart1. Service Identification9. Audit and Improvement Figure 1: The 7-step model of Network Security Development Process [1] Figure 2: The refined 9-step model of Network Security Development Process 2. A REFINED NETWORK SECURITY DEVELOPMENT MODEL While designing the Lab following the 7-step model [1], we came to realize that it was difficult to assess the risks of the identified assets (step C in Figure 1). For most of the assets, the assessments are mainly based on the assessor’s subjective evaluation and experiences, hence resulting in somewhat arbitrary assignment of risk ratings. To mitigate this difficulty, we refined the model by assessing the risks based on the servicesprovided by the underlying network (step 5 in Figure 2), rather than directly on the assets. There are two reasons why we evaluate services instead of assets: - First, each service is built upon one or more network assets. Services of a network are the “business” functions of the network. Ultimately, to protect a network is to maintain secure operation of the network services. - Secondly, evaluating the risks associated with services is more logical than evaluating the risks associated with assets. The “business” goals to be achieved by the services provide guidelines for evaluating the confidentiality, data integrity, origin integrity, non-repudiability, and availability of those services. On the other hand, it is comparatively difficult to evaluate the risks associated with an asset, because a particular network device or server is typically used to support multiple, higher-level services, each of which has its own security requirements and risks. The modifications we made to the original model are illustrated in Figure 2, and the new or modified steps are highlighted below: Step 1) Service Identification: To identify the services the underlying network should provide and protect. Step 4) Service-Asset Relationship: To clarify the relationship between network services and network assets. While a service may require the support of multiple assets, an asset, in contrast, may be used to support multiple services. Therefore, there exists a many-to-many relationship between services and assets. Table 1 shows the relationships between two sample services (S1 and S2) and some sample assets (A1, A2, A3). Table 1: Relationship between Services and Assets Service Asset S1 S2 A1 9 A2 9 9 A3 9 Note: The check sign (9) means that the service is supported by the asset. Step 5) Risk Assessment of Services and Assets: To determine how likely the threats are against the services and the assets. 5a. In step 5a, risks associated with the services are first assessed, based on the “business” goals. Table 2 shows risk ratings of the two sample services, S1 and S2, with respect to the security goals. Table 2: Rating of Sample Services Security goal Service Confiden-tiality