Understanding Security Architecture

Understanding Security Architecture Suhair Hafez Amer and John A. Hamilton, Jr. Department of Computer Science and Software Engineering, 107 Dunstan Hall, Auburn University Auburn, Alabama 36849-5347, USA E-mail: amersuh@auburn.edu, hamilton@auburn.edu Keywords: security architecture, policy, security threats, security attacks. Abstract This paper is a survey of current work to understand what security architecture means and represents. A starting point was to include all elements of security architecture such as: network, host-based, applications, information, software, hardware, databases and physical elements. Any security architecture should also include the principles and processes that are reviewed in this paper. Models to capture security architecture and an example are presented. Finally techniques used to capture and assess security architectures are mentioned. 1. INTRODUCTION In February 2003, the White House released the National Strategy to Secure Cyber Space responding to an urgent need for users, operators, and both public and private sectors vendors of networked data and communication systems to work together to improve the security of the nation s information infrastructure [www.dhs.gov/xlibrary/assets/national_cyberspac e_strategy.pdf]. The National Strategy to Secure Cyberspace proposed the following objectives: 1) Preventing cyber attacks against America s critical information infrastructures. 2) Reducing national vulnerability to cyber attacks. 3) Minimizing damage and recovery time from cyber attacks that may actually occur. To insure security, it is important to build-in security in both planning and design phases and adapt a security architecture which makes sure that regular and security related tasks, are deployed correctly. In general, there is no single solution for a security architecture that will work across all organizations and that the infrastructure is constantly evolving. Therefore, the security architecture must be capable of adapting new changes, technologies, strategies and policies [Peterson 2006]. [Peterson 2006] defines security architecture as a unifying framework and reusable services that implement policy, standards, and risk management decisions. It is a strategy that allows the development and operations staff to align efforts, and drive platform improvements that are not possible to make at a project level. In general, risk management, security policy and standards, and security architecture govern the security processes and defense in depth architecture through design guidance, runtime support, and assurance services. Then the security metrics are used for decision support for risk management, security policy and standards, and security architecture [Moriconi et al. 1997] approach secure architectures in three steps. First, common architectural abstractions are formalized. Then the system architecture is refined into specialized architectures where each one is suitable for implementation under different security assumptions. Finally, a rigorous proof is conducted to see if every implementation satisfies the intended security policy. [Whitman and Mattord 2003] recommends an organization to employ six layers of security to protect its operations that are: 1. Physical security layer which addresses the protection of physical items, objects or areas from unauthorized access and misuse. 2. Personal security layer which addresses the protection of the individual or a group of individuals 2008 SpringSim 335 1-56555-319-5

who are authorized to access the organization and its operation. 3. Operations security layer which focuses on the protection of detail of a particular operation or series of activities. 4. Communications security layer that encompasses the protection of the organization s communication media, content and technology. 5. Network security layer which protects the network components, connections and contents. 6. Information security layer that is concerned with protecting the information, the systems and hardware that use, store and transmit that information. In this paper security architecture is studied as follows. The common elements that should exist in any security architecture are mentioned in section 2. Section 3 states the principles of any security architecture. Section 4 displays the process of a security architecture development. Sections 5 and 6 are models to capture security architectures. Finally section 7 mentions some of the techniques used to compare and assess security architectures. 2. SECURITY ARCHITECTURE COMMON ELEMENTS Any organization consists of different elements that represent its information structure. To achieve security, different elements should be dealt with individually as well as in unity. Following are examples of such elements. 2.1. Network security architecture The network security architecture defines the planning and design of the network to reduce security risks in accordance with an organization s risk analysis, security policies and employing security mechanisms such as firewalls [Peterson 2006]. As described by [Suess 2003], network security may be achieved by: 1. Eliminating network components that use shared Ethernet. Implement the concept of defense and use multiple firewalls within network. 2. Implement intrusion detection systems at key points within networks to monitor threats and attacks. 3. Measure and report network traffic statistics for the computers on the network. Attempts to develop network security architecture can be found in [Cheng et al. 1998] who presented the design, rationale, and implementation of security architecture for protecting the secrecy and integrity of Internet traffic at the Internet Protocol (IP) layer. The design includes (1) a security policy (2) a modular key management protocol, and (3) the IP Security Protocol. The Cisco IOS[tm] Security Architecture [CISCO IOS] provides modular, scalable security. Firewalls, access management, host security, and encryption provide the foundation for security. Each system can be tuned with its own policy options to meet an organization's requirements. The cornerstone of the Cisco IOS Security Architecture bases security requirements on multiple, overlapping solutions to maintain an organization's security integrity. The base architecture for IPsec compliant systems can be found at [Kent and Atkinson 1998]. The goal of the architecture is to provide various security services for traffic at the IP layer, in both the IPv4 and IPv6 environments. 2.2. Host based security architecture Host based security architecture is concerned with achieving security and reducing security risks at individual machines within an organization. This can be achieved through good system administration practices [Suess 2003]such as: 1. Maintain up to date virus protection, make sure that system software are configured properly, and latest patches are installed. 2. Establish virus protection with automated update service on all critical systems. 3. Perform risk assessment to identify the most important computers to protect. 4. Disable network services that are not needed and run host-based firewall on computers to block unwanted network traffic. 5. Monitor security alerts and develop mechanism for quickly patching systems. 1-56555-319-5 336 2008 SpringSim

6. Create centralized system logging service. 7. Develop central authentication service to replace host-based password files. In general, host security may be achieved by specifying access control on the servers and workstations by using, for example, Intrusion Detection Systems, monitoring checks and/or using baseline configuration scanners [Peterson 2006]. 2.3. Application Security Architecture Application security not only deals with protecting the code and services running on the system but also protecting who is connecting to them and what is output-ed from such services. It is also concerned with delivering reusable application security services such as authentication, authorization. Auditing services can also be provided to enable developers to build security into their system [Peterson 2006]. It is important to identify the application features because the features influence the specification of the security policy. For example, indicating that an application or a system consists of multiple trusted domains means that the security policy must integrate a heterogeneous collection of users and resources that are administrated locally [Foster et al. 1998]. Operating systems must be flexible in their support for security policies, providing sufficient mechanisms for supporting the wide variety of real-world security policies. Such flexibility requires controlling the propagation of access rights, enforcing fine-grained access rights and supporting the revocation of previously granted access rights. The architecture described in [Spencer et al. 1999] and its prototype implementation in the Flask microkernel-based operating system addresses such issues and their policy flexibility of the prototype is evaluated showing that the architecture's impact on both performance and code complexity is modest. Moreover, their architecture is applicable to many other types of operating systems and environments. 2.4. Data and information Security Architecture Data security deals with securing access to data and its use. Due to the importance of information security [Whitman and Mattord 2003] introduced a hybrid framework for a blueprint of an information system which is represented shown in Figure 1. In Figure 1 [Whitman and Mattord 2003], users can access information in different ways. User and system have direct access to the information, however, networks and the Internet have an indirect access since a person accessing the Internet must go through the local network and then access the system that contains the information. There must be a layer of protection between each layer to prevent access to the inner layer from the outer one. Such an implementation reinforces the concept of defense in depth. It is important to note that although individual safeguards are located closer to the center of the sphere, people require a unique approach to security. People can directly access each ring as well as the information at the center of the model. This is why people as a result should become a layer of security in the form of a human firewall that protects information from unauthorized access and use. Monitoring systems Host IDS Firewalls Network IDS Encryption Redundancy Patches and upgrades Proxy Servers Backups Access controls Technology Systems Networks Internet Figure 1: Sphere of use and Protection of information [Whitman and Mattord 2003]. 2.5. Software Security Architecture Software can be defined as the operation system, controllers, utility programs, or application programs that can be used on computing equipments. Software can be replaced, changed, maliciously destroyed, modified, deleted, or misplaced. Sometimes a software attack can be identified when the software no longer runs but in many cases an attack may leave the software running as usual but make it do more than intended [Pfleeger and Pfleeger 2003]. Some examples of software vulnerabilities are: software deletion, software modifications by using logic bombs, Trojan horses, viruses, worms, trapdoor, Information leaks, and inserting malicious code [Wallach et al. 1997] note that software protection has two advantages. The first one is portability which ensures that a user-level Info People People Security planning Policy & law Education and training 2008 SpringSim 337 1-56555-319-5

software-product must coexist with a variety of operating systems. For example, it allows a browser to have platform-independent security mechanisms. The second advantage is performance since it offers significantly cheaper cross-domain calls whereas if they were implemented in hardware they would slow programs to an unacceptable level [Wallach et al. 1997]. Software protection in the operating system community focuses on memory protection by using software fault isolation where the load, store and branch instruction are rewritten to validate all memory access with an acceptable slowdown [Wallach et al. 1997]. Another way is to use the proof-carrying code which eliminates the slowdown associated with software fault isolation by statically verifying a proof that a program respects an agreed upon security policy when the program is loaded. After the proof is verified, the program can run at full speed. One might also use the simple dynamic checking which is simple to implement. [Wallach et al. 1997] address the challenge of not only getting memory protection but also providing secure system services solely with software protection. In general, buffer overflows occur because of the way languages such as C and C++ are designed. If an application is running as root, and an exploit takes advantage of a buffer overflow, then the exploit now has root privileges. That's one reason why patching such vulnerabilities is a priority for conscientious programmers, and why it's important to apply patches regularly [Byfield 2005]. An example of a software protection architecture applied in Java can be found in [JSA 1997]. 2.6. Hardware In general, hardware can be attacked in many ways. Since it is easy to identify and see the devices that are connected to the system, it is easy to attack by adding, changing, removing, intercepting traffic to and flooding with traffic the devices connected to the system. Furthermore, hardware may suffer accidental acts that are not intentional involuntary machine slaughter where it can be drenched with water, burned, frozen, gassed or electrocuted with power surges. Another type of attack is the voluntary machine slaughter which a person actually wants to harm the hardware of a system. Such an attack may involve theft or destruction and can be secured by simple measures such as using locks and guards [Pfleeger and Pfleeger 2003]. 2.7. Database In databases not only is the data considered to be sensitive but also their characteristics. The database management system is responsible for handling the integrity, confidentiality and availability of data on three dimensions. Security can be addressed by operating system integrity control and recovery procedures. Element integrity is achieved by using the proper access control to protect a specific data element from being changed or written by unauthorized users. In order to ensure element accuracy, checks on the values of elements can be used to prevent the insertion of improper values whereas constraint conditions can be used to detect incorrect values. Two-phase update is the technique used in databases in order to ensure that an update operation is performed on the complete record and that no part of the data was updated before the operation is aborted for what ever reason. Many databases maintain additional information in order to detect inconsistencies. One way for a database to recover data is by maintaining a log of users accesses and what they have changed. Therefore, in the case of a failure the database backup is reloaded and all changes are applied from the log file. The concurrency/consistency problem resulting from many users accessing or sharing the same database can be solved by using different kinds of locks. Finally, to check the integrity of the data being entered and that it is consistent with the rest of the database characteristics a monitor can be used [Pfleeger and Pfleeger 2003]. Multilevel databases require different types of security measures. Security must be implemented for each individual element. Two levels of security that are sensitive and non-sensitive are inadequate; therefore, each element should be associated with a related sensitivity level. Security on an aggregate value many be different from the security of individual elements. One way to limit access is the use of separation which can be implemented using partitioning, encryption, and the use of integrity and sensitivity locks. Some examples of multilevel secure databases are: integrity lock model, trusted front-end model, commutative filters model, distributed databases and window/view based model [Pfleeger and Pfleeger 2003]. 2.8. Physical Security 1-56555-319-5 338 2008 SpringSim

This is the process of knowing what aspects of the computing environment will or have an impact on security. It is in general used to describe the security needed outside the computer system. Some examples of the natural disasters that may affect a system are flood and fire. Damage may also result from power loss that can be because of an uninterruptible power supply or surge suppressors. In both cases such a loss may lead to media damage. Furthermore, human vandals may physically attack systems which can be easily prevented by employing guards or using locks [Pfleeger and Pfleeger 2003]. 3. PRINCIPLES OF SECURITY ARCHITECTURE Nine principles of security architecture have been identified by [Byfield 2005]: 1. Set a security policy for the system and know what's on it. 2. Actions should be verifiable which is achieved by the ability to check if an action is carried out. 3. Always give the least privilege practical. In general, all processes, users, and programs should be given only the access to system resources that they need, and no more. 4. Practice defense in depth and not rely on one form of security precaution. 5. Auditing the system: keep (and review) system logs. 6. Build to contain intrusions and minimize the consequences when a system is cracked. 7. A system is only as strong as its weakest link and the more defenses a system has, the less likely that the weakest one will leave it vulnerable. 8. The only way to be reliably certain that the system is secure after being successfully attacked is to reinstall the BIOS, reformat the hard drive, and restore files from a backup taken before the system was compromised which is time-consuming and result in a system being off-line for some time. 9. Practice full disclosure. When a system is successfully attacked, or is known to be vulnerable, let users know as soon as possible. On the level of individual systems, it allows the users of vulnerable system to take their own precautions. 4. SECURITY ARCHITECTURE PROCESS The security architecture process [Peterson 2006] is an iterative process that unifies the evolving business, technical, and security domains. [Peterson 2006] describe the four main phases in the process, as shown in Figure 2, as: 1. Architecture Risk Assessment: assesses the business impact to critical business assets, the probability and impact of security threats and vulnerabilities. 2. Security Architecture and Design: architecture and design of security services that enable business risk exposure targets to be met. 3. Implementation: Assurance services are targeted at verifying that the Risk Management, Security Policy and Standards, Security Architecture decisions are reflected in the actual runtime implementation. 4. Operations and Monitoring processes should be instrumented with security metrics to better measure the runtime environment. Figure 2: Security Architecture Lifecycle [Peterson 2006] 5. MODELS CAPTURING SECURITY ARCHITECTURE A significant aspect of designing a security architecture is to capture the architecture in an appropriate way. The representation should be clear, concise and consistent to facilitate easy analysis and comparison of architectures. [Lawlor and Vu 2003] describe the following models for capturing architecture: 1) The UK s Domain 2008 SpringSim 339 1-56555-319-5

Approach is claimed to allow a concise representation of an organization s discrete information sets along with any appropriate physical elements such as buildings, server rooms, and printers. 2) Australian Defence Architecture Framework does not address security, and is likely too broad to be ideally suited to architecture capture. (It should be noted that there is active research going on in the area of security architecture in the closely related US DOD Architecture Framework.) 3) The International Common Criteria s Protection Profiles are formal documents that could certainly capture security architecture, but perhaps at an unnecessary level of detail [Lawlor and Vu 2003]. 6. ICIIP MODEL Figure 3: ICIIP Model [Kiely and Benzel 2006] The Institute for Critical Information Infrastructure Protection (ICIIP) [Kiely and Benzel 2006] developed at the Marshall School of Business, University of Southern California represents the typical organizational entity, key elements of its security system, and discussion of national security issues, the dynamic relationships or tensions among these elements. Figure 3 identifies the three traditional elements of people, process, and technology and adds a fourth node of organizational strategy and design creating a threedimensional working model. The connections between the nodes are shown as six dynamic interconnections tensions, These tensions are: governance, culture, architecture, enabling and support, emergence, and human factors. The four nodes and six tensions shown in Figure 3 are summarized in Kiely and Benzel s words [Kiely and Benzel 2006]. Elements and connections of the ICIIP model [Kiely and Benzel 2006] are: 1. Organization focuses on the need to design organizational structures and strategies that enable the enterprise to compete effectively, create competitive advantages, understand its tolerance to risk and adopt governance policies that elevate security to a first priority, a board level issue, pervasive throughout the enterprise. 2. Security process is the method an organization uses to implement and achieve its security objectives. The process is designed to identify, measure, manage and control the risks to system and data availability, integrity, and confidentiality, and ensure accountability for system actions. 3. Technology is specifically assigned to develop and implement technological approaches to the protection of information systems, approaches that must stay ahead of the competing, threatening technology that would exploit and corrupt those systems if it could. 4. The people node represents the human resources in an enterprise who need to practice not only fundamental security but also in more complex enterprise systems, receive added training for securing enterprise data and communications, etc. After defining the four nodes, [Kiely and Benzel 2006] go on to describe the six tensors that connect the nodes. 1. The human factors tensor connects the people and technology nodes. All job descriptions must include a level of security risk and some content containing the handling of information. Security technology must be developed and deployed with people in mind. It is recommended to include social resources in psychological contracts between employees and firm, encourage sharing about security risks, and 1-56555-319-5 340 2008 SpringSim

integrate security technologies and policies into the work process. 2. The essence of culture is composed of patterns, patterns of behavior, belief, assumptions, attitudes, and ways of doing things. More specifically, culture has to do with the covert, underlying patterns of an organization. An organization s culture can, to some extent, be created through the predictability and rigor of its structure, but it often comes about due to unintended consequences of the structure or perhaps lack of structure. 3. Organizational governance is concerned with embedding security into the organization s structure. It must be adopted as strategy, made part of a high level policy and accountability, monitored at the highest levels of the organization. 4. Security Architecture is a comprehensive formal encapsulation of all of the people, processes, policies and technology that comprises an organization s security practices. Often, Security Architecture is viewed as simply the relations between different technology components in an IT system. An example of a security architecture framework that is defined relative to a specific domain s needs is the Department of Defense DoD Architecture Framework (DoDAF). The architecture is described for both war fighting operations and business operations and processes. It is based on an IEEE Standard (IEEE STD 610.12, 19903). It is largely oriented towards providing tools and techniques for understanding, comparing and integrating systems and systems of systems and places a high degree of emphasis on interoperability that are key points in critical enterprise operations. 5. Enabling and supporting defines the holistically aligned relationship and connection between process and technology. Processes can be redesigned by changing their architecture and flows, by changing the information technologies that enable them, the organizational structure that houses them, and the people skills, incentives, and performance measures of the people who execute them. 6. Emergence means surfacing, developing, growing, or evolving. They propose that emergence should not be reactive - how long it takes an organization to bounce back after a crisis- but instead proactive. Being better at anticipating, building a culture that has enough faith in itself to allow emergent rather than prescribed processes and more importantly, outcomes. 7. SECURITY ARCHITECTURE COMPARISON AND ASSESSMENT There are several techniques that can be used to compare among and assess different security architectures such as Bayesian networks, simulation, risk analysis, Information Assurance Technical Framework (IATF) approaches, game theory, survivability analysis and economic models of information security. In general, Bayesian networks allow considering the effect of countermeasures on potential attacks. [Lawlor and Vu 2003] point out that: justifying the data used in Bayesian networks is a serious issue that needs to be considered. Simulation has a dynamic nature, giving decision-makers knowledge of the architecture. However, it relies on the existence of an accurate model, which is hard to obtain in the information security domain. The IATF robustness strategy provides minimum requirements on architectures, but the incompleteness of the strategy and its US specific requirements are issues to be considered. Game theory could theoretically provide optimal designs for security architectures. Unfortunately, it is not well developed enough for the information security domain to be relied upon. Survivability analysis techniques are useful for architecture assessment, but are restricted to architectures containing networks. Economic models have practical, nontechnical uses, incorporating a human factors and system view into the security architecture analysis. However, they do not provide the most important answers 2008 SpringSim 341 1-56555-319-5

for government and Defense information systems. 8. CONCLUSION This paper serves as an overview of what security architecture represents to the IT community. Universal security architecture is difficult to define or develop as each organization needs to adjust according to its needs and available resources. Several important items related and representing security architecture have been mentioned. The authors included a list of elements that should be addressed in a security architecture such as: network component, host-based component, applications, information, software, hardware, databases and physical components. The difference, for example, between software and application components lies in their use. Applications are already developed pieces of software, mainly developed by a third-party company, and they are responsible for patching and securing it. Software development is affected highly by the language used for development. For example, security in C and C++ is not as mature as in Java. Information is different from databases because it includes information that is not only stored on physical medias but also the knowledge employees know. The paper also includes a list of principles and processes of security architecture. It mentions models that are used to capture architecture and then representing it in an understood way. The ICIIP Model is also mentioned. Finally, techniques used to compare and assess any security architecture are surveyed. 9. REFERENCES [Byfield 2005] Byfield, Bruce. Nine principles of security architecture. November 22, 2005. http://www.linux.com/articles/49803. [Cheng et al. 1998] Cheng, P.-C., Garay, J. A. and Herzberg, A. A security architecture for the Internet Protocol. Internet Computing. Volume 37, Number 1, 1998. [Cisco IOS] Cisco IOS Security Architecture. White paper. www.cisco.com/warp/public/614/9.html [Foster et al. 1998] Foster, I., Kesselman, C., Tsudik G. and Tuecke S. "A Security Architecture for Computational Grid", Proceedings of the 5th ACM Conference on Computer and Communications Security Conference, San Francisco, California, November, 1998. [JSA 1997] Java Security Architecture. Sun Microsystems, Inc. 1997-2002. http://java.sun.com/j2se/1.4.2/docs/guide/securit y/spec/security-spectoc.fm.html [Kent and Atkinson 1998] Kent, S. and Atkinson, R. Security Architecture for the Internet Protocol. Network Working Group. RFC 2401. November 1998. http://www.faqs.org/rfcs/rfc2401.html. [Kiely and Benzel 2006] Kiely, Laree and Benzel, Terry. Systemic Security Management, Technical report. USC. Marshall School of Business. Commissioned by the Institute for Critical Information Infrastructure Protection (ICIIP). http://www.marshall.usc.edu/ctm/iciip/events/s SM%20Final%20WP%20April%2023%202006. pdf. [Lawlor and Vu 2003] Lawlor, B. and Vu, L. A Survey of Techniques for Security Architecture Analysis, Technical Report. DSTO-TR-1438. 2003. http://dspace.dsto.defence.gov.au/dspace/handle/ 1947/4007 [Moriconi et al. 1997] Moriconi, M., Xiaolei, Q., Riemenschneider, R.A., and Li, G., "Secure software architectures", Proc. IEEE Symposium on Security and Privacy, 1997, pp. 84-93. [Peterson 2006] Peterson, Gunnar. Security Architecture Blueprint. 2006. http://arctecgroup.net/pdf/arctecsecurityarchite ctureblueprint.pdf. [Pfleeger and Pfleeger 2003] Pfleeger, C. P., Pfleeger, S. L., Security In Computing. Professional Technical Reference. Prentice Hall, Upper Saddle River, NJ, 2003. [Spencer et al. 1999] Spencer, R., Smalley, S. Loscocco, P., Hibler, M., Andersen, D. and Lepreau, J. The Flask Security Architecture: System Support for Diverse Security Policies. in the Proceedings of The Eighth USENIX Security Symposium, August 1999, pages 123-139. [Suess 2003] Suess, Jack. Security architecture: computer and network security in higher education. Published by Jossey-Bass, a Wiley company. 2003. http://www.educause.edu/ir/library/pdf/pub7008j.pdf. [Wallach et al. 1997] Wallach, D. S., Balfanz, D, Dean, D. and Felten, E. W. Extensible security architectures for Java. In Proceedings of the Sixteenth ACM Symposium on Operating System Principles, pages 116--128, Saint Malo, France, October 1997. [Whitman and Mattord 2003] Whitman, M. E., and Mattord, H. J. Principles of Information Security. Thomson. Course Technology. Canada 2003. 1-56555-319-5 342 2008 SpringSim