An
Information Technology
      Architecture
          for
    Emory University


       Security
  Domain Architecture


...
An IT Architecture for Emory University                                           Adopted by CIRT
Security Domain Architec...
An IT Architecture for Emory University                                                                           Adopted ...
An IT Architecture for Emory University                                            Adopted by CIRT
Security Domain Archite...
An IT Architecture for Emory University                                         Adopted by CIRT
Security Domain Architectu...
An IT Architecture for Emory University                                          Adopted by CIRT
Security Domain Architect...
An IT Architecture for Emory University                                                      Adopted by CIRT
Security Doma...
An IT Architecture for Emory University                                                                             Adopte...
An IT Architecture for Emory University                                                       Adopted by CIRT
Security Dom...
An IT Architecture for Emory University                                           Adopted by CIRT
Security Domain Architec...
An IT Architecture for Emory University                                                         Adopted by CIRT
Security D...
An IT Architecture for Emory University                                           Adopted by CIRT
Security Domain Architec...
An IT Architecture for Emory University                                         Adopted by CIRT
Security Domain Architectu...
An IT Architecture for Emory University                                          Adopted by CIRT
Security Domain Architect...
An IT Architecture for Emory University                                           Adopted by CIRT
Security Domain Architec...
An IT Architecture for Emory University                                           Adopted by CIRT
Security Domain Architec...
An IT Architecture for Emory University                                        Adopted by CIRT
Security Domain Architectur...
An IT Architecture for Emory University                                          Adopted by CIRT
Security Domain Architect...
An IT Architecture for Emory University                                         Adopted by CIRT
Security Domain Architectu...
An IT Architecture for Emory University                                                                                   ...
An IT Architecture for Emory University                                        Adopted by CIRT
Security Domain Architectur...
An IT Architecture for Emory University                                             Adopted by CIRT
Security Domain Archit...
An IT Architecture for Emory University                                                  Adopted by CIRT
Security Domain A...
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
9-4
Upcoming SlideShare
Loading in...5
×

9-4

470

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
470
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "9-4"

  1. 1. An Information Technology Architecture for Emory University Security Domain Architecture Adopted by CIRT February 20, 2002 Committee on Information Technology Architecture March 6, 2002 Version 1.9.8
  2. 2. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Security Domain Task Force Dwayne Bush (ITD and Chair) Rick Aaron (Emory Healthcare) Parrish Brown (ITD) Tim Brown (Business School) Phil Chandler (School of Medicine) Peter Day (ITD and Editor) Mark Elliott (ITD) John Goodson (Human Resources) Martin Halbert (University Libraries) Chang-Kwei Lin (Yerkes) Belinda Maaskant (School of Public Health) John Mason (Network Communications) Rob Poh (ITD). with assistance by Jay Flannagan (ITD) DOCUMENT REVISION HISTORY Release Description Date 1.0 Insert summary, overview and principles November 9, 2000 1.1 Updates based on Nov 10, 2000 meeting November 13, 2000 1.2 Fix formatting problems, add to glossary December 7, 2000 1.3 Add trends, standards & other from latest meetings December 7, 2000 1.4 Reorg., additional info, changes to technologies & configurations December 11, 2000 1.5 Changes from Dec. 15 task force meeting & polishing December 17, 2000 1.6 Std. Headers & footers, copy edit, expand Exec. summary January 16, 2001 1.7 Updated all but principles, tutorial overview, section pagination February 20, 2001 1.8 More emphasis on classification, fix formatting in products February 23, 2001 1.8.1 Add classification to Fig 2; Update Domains in Fig 1; Next Steps February 23, 2001 1.9 S-10 to std., smooth rough edges, respond to IT-ARCH feedback February 26, 2001 1.9.1 Copy editing, resource default status, definition of scalable March 27, 2001 1.9.2 Codes to §7 & 8. Pending classification policy. Delete old §8.4. April 9, 2001 1.9.3 Copy edits, clarification, role definitions in §6, §11, §12 April 12, 2001 1.9.4 Respond to DWB & SSA (§3, C-7), misc. edits. May 4, 2001 1.9.5 Respond to RP & DB, §5.5 format, §6-8 tables, §10 considerations May 17, 2001 1.9.6 Update section 2 outline May 21, 2001 1.9.7 Change status to “Ready for Adoption” Sept. 19, 2001 1.9.8 Changed status to Adopted; added copyright & more bookmarks March 6, 2002 ITA Version 1.9.8 © 2000 Emory University Page ii
  3. 3. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 TABLE OF CONTENTS 1. Executive Summary..............................................................................................................1 2. Introduction...........................................................................................................................1 3. Overview................................................................................................................................1 4. IT Trends...............................................................................................................................1 5. Security Principles...............................................................................................................1 6. Technologies.........................................................................................................................1 7. Standards Compliance.........................................................................................................1 8. Standard Products................................................................................................................1 9. Configurations......................................................................................................................1 10. Considerations & Next Steps.............................................................................................1 11. Glossary..............................................................................................................................1 12. Appendix: Justification and Implications of the principles.............................................1 LIST OF FIGURES Figure 2-1. Process to derive domain architectures...............................................................1 Figure 3-2. Assets information.................................................................................................2 Figure 3-2. Assets information.................................................................................................2 Figure 3-3. Risks and countermeasures..................................................................................3 Figure 3-3. Risks and countermeasures..................................................................................3 Figure 3-4. Zones of trust..........................................................................................................4 Figure 3-5. Network zone technologies...................................................................................5 Figure 3-5. Network zone technologies...................................................................................5 Figure 3-6. Network Policy Pockets.........................................................................................6 Figure 3-6. Network Policy Pockets.........................................................................................6 Figure 3-7. Firewall access control..........................................................................................6 Figure 3-7. Firewall access control..........................................................................................6 Figure 3-8. Proxy access control..............................................................................................6 Figure 3-8. Proxy access control..............................................................................................6 Figure 9-9. Placement in zones................................................................................................4 Figure 9-9. Placement in zones................................................................................................4 ITA Version 1.9.8 © 2000 Emory University Page iii
  4. 4. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 1. Executive Summary Security involves a balance between protection and access. Emory needs to provide members of its community with access to the resources that they need to perform their roles and responsibilities. Emory also needs to allow access to certain resources by outside participants in Emory projects and programs and by consumers of Emory-supplied systems, services, or data. At the same time, Emory needs to protect its assets and restrict access to them according to its policies, license agreements, and the requirements of granting and regulatory agencies. The security architecture is intended to establish an environment that addresses Emory’s security needs for the good of all of Emory. Based on Emory’s IT requirements and principles that have been already established in previous architectural documents, the security architecture seeks to be flexible enough to adapt to future requirements as needed, yet be able to keep down support costs by taking advantage of standardization and economies of scale. The principles, technologies, standards and configurations that it provides to do this seek to foster harmony with other IT architecture decision areas (called “domains”). Having an Emory-wide security architecture will provide a number of benefits to Emory as a whole. It can promote information sharing, foster enhanced decision making and collaboration, support the building of both internal and external relationships, and contribute to system and service reliability, by: • Giving those responsible for data confidence that the data will only be accessible as intended; • Allowing selected Emory, departmental, and school information resources to safely be made available to the Emory community and the world; • Ensuring that changes are only made by those people and processes authorized to do so; • Supporting an environment where work flow and process automation can be implemented in a manner that is reasonably free from abuse; • Allowing systems to be shared by the University and Healthcare. In spite of these features, no environment can be risk free or perfectly secure, because people can thwart security no matter how much money has been spent or how much technology has been put in place. Thus organizations that are leading edge in security focus first on making decisions needed to establish security policy before focusing on security technology. One of the first policy decisions is to identify the resources that need protection (called “assets”) and classify them to indicate how much protection they need. Once assets are identified and classified, it is easier to develop policies and procedures and apply technology to protect them. Then implementing security involves assessing risks and threats, addressing vulnerabilities of assets as soon as they are discovered, and responding quickly to security violations. The architecture envisions security services for the whole of Emory, such as common access control and notification of the latest threats, vulnerabilities, and countermeasures. Since IT resources are generally attached to a network, and attacks often come through the network, the architecture also includes campus services to assess vulnerability of systems to network attack and to detect and react to the onset of such attacks. Since attacks can come from both outside and inside Emory, the architecture includes a layered scheme that can provide more restrictive network access and stronger protection to portions of the campus network as needed. ITA Version 1.9.8 © 2000 Emory University Page 1
  5. 5. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 2. Introduction In Document 1 we agreed on a statement of what Emory wants to achieve, and how it will use an IT architecture to help reach its goals. At the end of that document, we arrived at a statement of the requirements our technical architecture should meet, e.g. “facilitate change in academic and administrative processes” and “provide a campus network that allows communication and exchange of information.” In Document 2 we identified the design principles (called the Conceptual Architecture Principles or CAPs) we will use as we evolve our new IT environment, as well as the categories (called “architecture domains”) where we need to decide on policies, standards, etc. The following diagram illustrates the process of deriving the domain architectures. Drivers of Domains Change  Data and Information Emory's Vision Management  Platform  Mission  Network  Goals  Distributed  Priorities Architecture Conceptual Environment  Strategies Requirements Architecture Management  Security Environment  Integration  Application  Trends  Intranet &  Forces e-Commerce  Challenges  Online Learning  Constraints  Collaboration  Opportunities  Directory Document 1 Document 2 Figure 2-1. Process to derive domain architectures This document is one of a set of documents—one for each domain—that take the next step and provides those policies, standards, etc. for each of the domains. In outline, this document: • Provides an Overview describing this domain architecture; • Points the reader to other Related Domain Architectures; • Identifies the IT Trends relevant to this domain; • Describes the Design Principles associated with this domain; • Shows how the principles of this domain provide Support for the Conceptual Architecture Principles; • Lists relevant Configuration Principles; • Describes Standards, Products and Configurations for the domain; • Points out considerations to address for this and other domains and suggests next steps; • Provides a Glossary of terms; • Shows in an Appendix the detailed Justification and implications of the principles so that those interested can understand in more detail the subtleties of meaning and the thinking behind each principle. ITA Version 1.9.8 © 2000 Emory University Page 1
  6. 6. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 3. Overview 3.1 Security in general “Security is a topic that is about as exciting as watching paint dry.” -- Gene Spafford “The only truly secure system is one that is powered off, cast in a block of concrete, and sealed in a lead-lined vault with armed guards -- and even then I have my doubts.” -- Gene Spafford “100% system security = 100% non production.” -- Rollo Rogers. “If you don’t know the threat, how do you know what to protect? If you don’t know what to protect, how do you know you are protecting it? If you are not protecting it. . . .the adversary (dragon) wins!” -- The Laws of OPSEC Balancing protection and access. Security involves a balance between protection and access. Too great a restriction on access to data, information and other resources impedes the use for which these resources were intended. It also reduces the value of information, since information increases in value the more it is used. Instead, Emory needs to provide members of its community with access to the resources that they need. Emory also needs to allow access to certain resources by outside participants in Emory projects and programs and by consumers of Emory-supplied systems, services, or data. At the same time, Emory needs to protect its assets and restrict access to them according to its policies, license agreements, and the requirements of granting and regulatory agencies. The need for security policy decisions. No environment can be risk free or perfectly secure, because some aspects of security can only be managed by personal choices. Indeed, in the absence of policy to the contrary, people can leave sensitive information unprotected, share passwords, and let others into secured areas. Thus people can thwart security no matter how much money has been spent or how much technology has been put in place. Organizations that are leading edge in security focus first on making decisions needed to establish security policy before focusing on security technology. What to protect. One of the first policy decisions is to identify the resources that need protection (called “assets”) and classify them to indicate how much protection they need. This document will be mostly concerned with IT resources, a category of potential assets that includes such things as data and information, network facilities (voice, video, and data), computers, printers, software, administrative and research data, and the connection(s) to the Internet. Also included as potential assets are resources that the university does not own, but which are in its custodial care. Resource owners and classification. From the moment of their creation, all Emory resources and information requiring protection need to be classified to indicate the level of protection. To identify assets and determine the amount of protection they need, the architecture asserts that every resource has an “owner,” that is, someone or some organizational unit that has final rights regarding disposition of the resource. To enable owners to classify resources in a standard way, the architecture envisions a classification scheme that allows owners to indicate the level of protection needed in terms that the owner understands. ITA Version 1.9.8 © 2000 Emory University Page 1
  7. 7. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Classification is key. Classification is a key driver for implementing security. Once resources are classified, it is easier to develop policies and procedures and apply technology to protect them. Knowing the classification of a resource helps people make personal choices that are more likely to protect the resource. Classification of data does not change no matter how it is stored or displayed. Thus classification provides a way to determine the change in protective measures needed when data changes form, such as when data stored on a computer system is printed on paper. Classification scheme. At the conceptual level, the security architecture seeks to make possible giving assets the protection implied by their classification regardless of the classification scheme. At the product level, the security architecture assumes use of security classification guidelines for Emory whose approval is pending. Once the guidelines are approved, classification of resources is part of the implementation of the architecture. In the meantime, this document focuses on access control, since controlling access is one of the main countermeasures for protecting a resource, and uses the ratings “Restricted,” “Confidential,” and “Public.” The rating indicates the level of access protection needed according to the impact on Emory of unauthorized access. Figure 9-1 on page 4 of this document shows a recommended classification of certain enterprise IT resources using these ratings. Stewards, Custodians and Administrators. For most Emory IT resources, such as a major Emory IT system, Emory is the owner, and it has entrusted responsibility for the resource (including its classification) to someone else called the “Steward” of that resource. The Steward may employ someone called a “Custodian” to take care of the resource, and may delegate classification to the Custodian or base the classification on information from the Custodian. The Custodian in turn may depend upon an “Administrator” of the resource to supply advice and take direct action. In the case of an IT resource, such action could involve making configuration changes to an IT system to secure it. Assets Information Database. The architecture envisions that the identity of assets, their classification, and other information about them would be maintained in a database. An issue is how to motivate people to put the information in the database and keep it up-to-date. The architecture envisions that Drives Requirements Drives the Senior Emory leaders would drive classification identification and classification of assets Senior Owners Custodians VP for by requiring it of owners and stewards. Leaders Stewards Administrators IT The Vice Provost for IT would also take leadership in this by encouraging Access by Keep asset custodians and administrators. The Help Desk, data up-to-date Local Support information in this database would also be & Others of potential use for purposes other than security, and would be made available to Access the Help Desk, local support, and others. Enterprise Control Asset Some of it might be of wide enough Directory Information Feed interest to appear in the Enterprise Service Database Directory. Figure 3-2. Assets information Threats, Vulnerabilities, Risks, and Countermeasures. Threats continually appear and vulnerabilities are continually found. Protecting systems requires knowing of vulnerabilities as soon as they are discovered, quickly detecting intrusions, taking protective measures ITA Version 1.9.8 © 2000 Emory University Page 2
  8. 8. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 immediately, and applying all fixes as soon as they become available. The architecture envisions having a security analyst who has trusted sources of information about threats, vulnerabilities and countermeasures, plus other sources that the analyst checks for validity. The analyst makes sure that people who need to know are informed, monitors reports of campus problems, sends out warnings, and tracks incidents and intrusions and the cost to address them. A Security Administrator enters the data into a database and maintains it. Using this data, the analyst can better quantify the risks of certain threats for Emory. External trusted Pull sources of Clearinghouse information of risks and countermeasures  ISS Vulnerabilities DB  InfoGuard  Incidents  Etc.  Intrusions  What, why  Cost to fix Targeted Alert  Countermeasures Entry LISTSERV a Update t campus List da  Etc. ed at  Notice lid Al Va  Warning er t  Etc. Other Assets Who to notify sources of Database information  E-mail Analysis  Bugtraq  Etc. Figure 3-3. Risks and countermeasures Proactive and Reactive Security. Security policy and procedures along with protective measures help prevent security breaches and reduce to an acceptable level the probability of harm or loss. However, changes in the IT environment continually introduce new vulnerabilities, so security incidents still happen. When they occur, quick detection and rapid response are needed to minimize loss or harm. To address detection, the architecture envisions the use of “intrusion detection” technologies that monitor the environment and send alarms when a security policy violation, break-in or attack is detected. Alarms might be evaluated by the security analyst or might produce an automated protective response according to established policy and procedures. Zones of Trust. IT resources vary in the extent to which they can be trusted to not be compromised. The security architecture envisions a layered approach that uses zones of trust to provide increasing levels of security according to the increasing security needs indicated by the classification scheme. Each zone is inside the next, leading from the least trusted to the most trusted. This approach is similar to protecting a castle using multiple walls that form concentric rings with the castle at the center and cities in the rings. There is exactly one door into the outer ring, and only one door between rings. Each door has a guard who says “Who goes there?” and may ask for identification and a password. It is hard for people in outer rings to attack people in ITA Version 1.9.8 © 2000 Emory University Page 3
  9. 9. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Emory Trusted Emory Untrusted Emory Proprietary & Confidential Public information Secure Available to Emory faculty, staff and & resources Restricted students only Available to Available to anyone Policy Pockets only those granted access Outside Emory Figure 3-4. Zones of trust. inner rings, but less hard if they are in the same ring. Thus those in the same ring need to have the same minimum level of trustworthiness. Number of zones. The diagram shows three zones, but the number of zones does not have to be as many as three or as few as three. The use of multiple zones allows access between a less and a more trusted zone to be controlled to protect a resource from attack by a less trusted one. Any zone could be subdivided into “policy pockets” of common security policy if need be to allow supporting additional classification categories without the expense of infrastructure to establish another zone. The picture illustrates this for a classification scheme with four categories by putting two categories (proprietary and confidential) in the same zone. Emory is likely to need multiple zones as indicated in Section 9.3.1 page 3 below. Establishing trust. Trust in a resource depends upon measures taken to detect and prevent compromise of the resource and violations of security policy. To establish a minimum level of trust, each zone except perhaps an “untrusted” zone requires that the devices in it be certified to have a certain level of security determined by the security policies, procedures, and protections that are in place to check for attacks, intrusions and security policy violations. Measures to establish trust include fixing known problems, detecting intrusions, and periodically checking for unauthorized changes, violations of policy, and vulnerabilities to attack. 3.2 Network Security “Ethernet over barbed wire? Well, that’s one approach to network security.” -- Mark Vinsel Focus on data networks. Network security is an application of the above general security approach to networks for electronic communication. Of the three types of networks – voice, video, and data – the focus of this document is security for data networks, because that is the type of network to which most IT resources attach and through which they can be attacked. Data networks need to be secured not only to protect their attached IT resources, but also to protect the network itself, that is, to protect the ability to access the IT resources on the network, and the ability for those IT resources to interact using the network. 3.2.1 Basic network Security Basic countermeasures. While controlling physical access to the network hardware is a necessary requirement to secure the network, the greatest threat to the network and the systems attached to it is an attack that occurs through the network itself. Unlike a physical ITA Version 1.9.8 © 2000 Emory University Page 4
  10. 10. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 attack, an attack through the network can occur from anywhere in the world without the attacker having to be physically near the local network equipment or local IT resources. Preventive countermeasures then seek to detect and remove vulnerabilities that can be exploited over the network, while reactive countermeasures seek to respond to attacks and intrusion. Thus the basic network security countermeasure technologies probe systems for vulnerabilities and inspect the traffic flowing through the network in real time. Firewalls separate the zones. The network security architecture envisions implementing zones of trust using a repeating pattern of technologies. The zones are logically sets of one or more networks that connect with other networks only through devices called “firewalls” that inspect the network traffic flowing through them in real time. The firewalls act on the traffic according to security policies and procedures when they detect predefined patterns. Examples of actions a firewall might take are changing the contents of the traffic, sending an alarm, redirecting the traffic, blocking the traffic, or sending a response. Zone technologies. The accompanying diagram shows the technologies used to separate the rings and enforce security policy. Routers and switches (RT/SW) connect networks and route traffic between them like hallways connecting rooms. Firewall(s) (FW) “guard the door” to a room, examining and selectively acting on traffic going through them in real time. Intrusion RT/SW ID FW FW RT/SW = Router/Switch CK ID = Intrusion Detection FW = Firewall CK = Optional additional checks Figure 3-5. Network zone technologies Detectors (ID) monitor traffic in real time for attacks, suspicious activity, unauthorized access or other signs of a breach of security. The firewall(s) only do basic checks, rerouting certain traffic to other devices for further checks (CK). For example, e-mail could be sent to a virus checker. If a virus or intrusion is detected, an alert could be sent to the firewall(s) to block it. Multiple firewalls may be needed to provide the required availability, reliability and responsiveness, or allow sharing of firewalls for economies of scale. This set of standard technologies is repeated at the border of each zone, and all the firewalls communicate with each other. Other technologies in the zone. In addition to the minimum technologies, other technologies can be used to verify that the resources in a zone are meeting the minimum security requirements. An example is a network “scanner” that periodically probes IT resources in its zone to check for network vulnerabilities, intrusions and security violations. A scanner can also check to see if inner zones conform to security policy for access between zones. An additional intrusion detector inside a zone can be used to verify that the outside intrusion detector and the firewalls are handling intrusion attempts according to policy. It can also detect intrusion attempts by one device against another device in the same zone, as might occur if the attacking device were already compromised. ITA Version 1.9.8 © 2000 Emory University Page 5
  11. 11. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Policy pockets. When the needed level of protection can be the same but policies differ, the cost and complexity of the infrastructure to create separate zones can be avoided by placing the resources with distinct security policies into “policy pockets” that use the border firewall(s) of their common zone to separate them and enforce their differing policies. Zone with Policy Pockets Inner Outer Zone Policy Pocket 1 CK Optional other Zone (e.g. project 1 servers) checks Router/ Policy Pocket 2 Router/ Firewall(s) Switch (e.g. project 2 servers) Switch Policy Pocket 3 Intrusion remainder of zone Detection Figure 3-6. Network Policy Pockets. Access control. The access control infrastructure provides a means for authentication and access control decisions to take place external to applications and systems. These decisions use an externally managed store of enterprise information called “access policy data” that includes identifiers, data to verify identities, and attributes indicating group memberships. The authentication service enables people and systems to prove their identity prior to accessing a target service. Externalizing authentication and access policy data gives target services a way to avoid the burden of maintaining their own files of such data or supporting new authentication technologies (such as finger print readers). Firewall. Access control uses a layered approach. At zone boundaries, firewalls control access by authenticating the identity of the requester when needed and allowing access to a system, service or other resource only by those authorized to do so. Prove Identity Verify identity Fire Fire Access Access wall wall Policy Verify Data Resource Access Target Figure 3-7. Firewall access control Proxy. A separate system called a “proxy” that talks to a target resource on behalf of the Prove Identity Verify identity Proxy Fire Fire Access Access wall wall Policy Request Verify Data Access Target Figure 3-8. Proxy access control ITA Version 1.9.8 © 2000 Emory University Page 6
  12. 12. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 requestor would provide an additional layer of access control. It could be located in a zone of Security Domain Architecture less trust than the target resource to provide access to the resource by other systems without the need for those systems to access the zone where the resource is located. In addition, by taking access requests on behalf of a resource, a proxy could provide externalized authentication for access to a resource even when the level of security of the target resource is unknown. Authentication service. While the application implementing a service ultimately decides whether to allow access to some data or function, the application would be able to take advantage of the external authentication service to verify identity. People and systems would prove their identity to the authentication service prior to accessing the target service. The result of authentication would be either proxy access to the target service or a credential that vouches for their identity. Access to the authentication service would be made available by means of widely supported, industry-proven standards to the extent feasible. Access policy data. Access to policy data would also be made available as appropriate using widely supported industry-proven standards to the extent feasible. Because overall security depends on the security of the access policy data, the systems where it is stored would be protected by the strongest methods Emory is able to use. In particular, the data would be located in the most secure zone. Access to policy data would depend on security considerations such as the location of the requester (including zone of trust), the security of the connection, and the requester’s authenticated identity (or lack of identity in the case of anonymous access). 3.3 Subdomains In summary, security involves • identifying assets and their owners, classifying assets, and creating policies and procedures; DRAFT FOR DISCUSSION • assessing threats, vulnerability to threats, and the resulting risk to assets; • developing proactive and reactive countermeasures to reduce risk and respond to violations of security. Accordingly, this document organizes security into the following three subdomains. Subdomain Name Subdomain Description Assets Resources that need protection. Risks Possibilities of harm or loss. Countermeasures Ways to reduce the probability of harm or loss to an acceptable level. ITA Version 1.9.8 © 2000 Emory University Page 7
  13. 13. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 3.4 Related Domain Architectures The security domain is related to all other architecture domains. However, it strongly interacts with the following domains because of its dependence on them. In particular, principles of these domains are applicable to the security domain. See these other domain architectures for additional information. Domain Name Domain Description Relationship to Security Arch. Directory The directory service architecture defines the Can provide infrastructure to create a single, unified naming security policy scheme that uniquely identifies entities, and information such provides the capability for a network-attached as for service, system, or device to use an entity’s name authentication and to obtain information about the entity. authorization. Network The Network Architecture provides the voice, video A resource to be and data communication infrastructure for the protected. A distributed IT environment. It covers structure and channel by which topology, bandwidth management, cable plant, a resource can be electronics (hubs, PBX, routers, switches), attacked. Defines protocols (access, routing, naming, DNS), carrier standards for services (frame relay, leased channels, ATM, network attached WAN, SONET ring), wireless, Internet connections. security devices. Data and The Data and information Management Defines principles Information Architecture defines the components and and standards for management standards for accessing, exchanging, modeling, organizing, storing storing, converting, organizing, and distributing and retrieving data and information. Product and technology security-related categories governed by this domain include data. databases, data warehouses, data marts, data repositories, data modeling tools, data replication tools, data administration tools, data extract tools, data movement tools, and data cleansing tools. Platform The Platform Architecture defines the technical Defines principles computing components of the infrastructure: the and standards for client and server hardware platforms, the operating platforms on systems executing on those platforms, and the which security database environments and interfaces supported. processes and applications run. ITA Version 1.9.8 © 2000 Emory University Page 8
  14. 14. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 4. IT Trends 4.1 Trends from Document 1 The following are the trends identified in Document 1 and their implications for Security. 1. Hardware will get faster, cheaper, denser and more diverse.  As systems get cheaper, they become more widely used, resulting in more widespread exposure to threats.  Faster and cheaper systems enable attackers to afford systems that can try possible keys faster and crack encryption faster, so there will be a need for increasingly larger keys.  Denser technology enables creation of small systems using wireless technology that can be stationary or mobile. How can the location and identity of such systems be determined so that access control can take device location and identity into account?  The infrastructure will be challenged to support security across an increasingly diverse set of systems and devices. 2. Demand for capacity will continue to increase.  Increased numbers of users and increased usage will require scaling up management of accounts and administration of access control. Standards and infrastructure will be needed to enable that scalability. As a result Emory will need to get out of the password synchronization business.  General growth in demand will require investing money in general computing infrastructure, which competes with money needed for security infrastructure. 3. Demand for access to “anything” from “anywhere” will continue to grow.  “Password challenge” will become insufficient as a means of access control. Identity will need to rely on additional factors such as something you have (e.g. token) or something you are (e.g. fingerprint).  Access control will have to be based on who is requesting access, where they are located, date and time of access attempt, and target of access to determine what they will be allowed to do.  Support will be needed for use of different methods of identification depending on location. 4. Security will be a primary concern with increased dependence on network applications.  Emory will need to support technologies related to intellectual property as they become important.  Costs will continue to rise due to growth in attacks.  Emory will need to use a knowledge management approach to manage the knowledge necessary to protect its IT infrastructure.  A support center model to handle response to attacks may be required. ITA Version 1.9.8 © 2000 Emory University Page 1
  15. 15. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 5. IT expertise will continue to be scarce and its cost will continue to rise.  An approach is needed that does not require a rapid increase in security experts as the number of systems and the security issues increase.  Security practices and technology are becoming more difficult and specialized.  Certification in security technologies and practices is becoming available.  Security experts will become harder to find, and their salary requirements will increase.  Ways other than salary will be needed to attract and retain security experts. (See the Implications of Principle S-8 on page 9.) 4.2 Domain-specific Trends The following are trends specific to this domain. 6. Organizations that are leading edge in security focus first on making decisions needed to establish security policy before focusing on security technology. 7. Miniaturization will bring down the cost of biometric devices, leading to their wider use, such as in smart cards and small devices like wearable computers. 8. PKI will to be important for implementing digital signatures, and for setting up encrypted conversations among devices. 9. The expertise needed to initiate an attack is going down as those with the expertise create kits to allow anyone to do it. This results in an increase in attacks. 10. The vulnerability of individual systems is increasing due to the increasing use of peer to peer applications (e.g. Napster) and fast, always on connections (e.g. DSL and cable modems). The people using these applications increasingly have limited knowledge about the associated requirements for security. They accept the out-of-the-box configuration, rather than engaging in expert planning of the configuration as was done for systems in the past. This will lead to a need for more remote management, but will they accept it? 11. Operating systems keep changing and their complexity keeps increasing, leading to the continual introduction of new vulnerabilities. Maintaining security will thus require staying on top of the latest threats. 12. People at Emory are creating applications, particularly using web technologies, and want to do access control. Emory needs to provide a central way that is so attractive that they prefer it over doing it themselves, and help them do it securely when they want to do it themselves. 13. People see the benefits of using the web (e-business) outweighing the risks of not taking the time to do it more securely; or they use the web in spite of the lack of adequate security. 14. The web and e-business are a new frontier for crime. There will be changes in system security requirements as law enforcement and the legal system come together to respond. We will have to be prepared to respond in the time frame needed. 15. Security will increasingly be based on roles. ITA Version 1.9.8 © 2000 Emory University Page 2
  16. 16. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 5. Security Principles The following principles—derived from the Conceptual Architecture Principles of Document 2— apply to the entire security domain. They, along with the principles in the Assets, Risks and Countermeasures subdomains, are to be used to guide the implementation of the enterprise infrastructure that helps to secure other IT assets. In particular, they are to be used in the evaluation, selection, design, construction, implementation and deployment of products and systems. Following these principles will not only help the implementation succeed, but will also promote logical consistency with other domains and the architecture requirements and Conceptual Architecture Principles (CAPs). The table in Section 5.5 (page 5) shows how these principles support the CAPs. While giving just the titles and statements of the principles is sufficient to summarize them, such a list is insufficient for a full understanding of them. To see the reasoning behind a principle and the implications of following it, the reader is advised to consult the details in Appendix 1 (page 1). 5.1 Overall Security Principles S-1.Security infrastructure must be scalable. The enterprise infrastructure that helps to secure other IT assets must be able to scale the load it can support, assets it can secure, amount of data it can store and process, and the reliability, availability, and maintainability it can achieve as quickly as needed. (Page 2) i. Monitoring and logging should be able to scale to handle the maximum activity that can occur. ii. Auditing (including scanning) and logging should be flexible in the amount of detail that is captured, and capable of quickly increasing its capacity to collect detail as needed to the point that it can capture all available detail on all activity. iii. Access control must allow a scalable increase in the assets whose access is to be controlled, the actions that can be performed on those assets, the things that could be given access, the number and complexity of the access rules, and the capacity to enforce the rules. iv. The security architecture must enable load balancing (pickup workload in real time) and moving the security infrastructure and equipment around as quickly as needed to handle longer-term changes in workload. S-2.Make it easy to integrate new security technologies. The security infrastructure must be able to support as quickly as needed new security hardware, methods, types of clients, and locations from which access occurs. (Page 3) S-3.Security infrastructure should employ standard, extensible, and widely supported interfaces. To the extent possible, the security infrastructure should employ widely supported, standard interfaces through which the security infrastructure can interact with existing and new systems and technologies. It should support adding and extending interfaces to add new capabilities without disturbing existing portions of the infrastructure. (Page 4) S-4.Build security infrastructure with a bias toward using modular, loosely coupled, widely supported components. IT security solutions and infrastructure should be engineered with a bias toward using highly discrete, modular, loosely coupled, and widely supported components. (Page 5) ITA Version 1.9.8 © 2000 Emory University Page 1
  17. 17. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 S-5.Standardize judiciously. Standardize the shared security infrastructure to the extent feasible using interfaces, technologies, and policies that can be widely supported by systems and devices in common use at Emory. (Page 6) S-6.Security systems should be process-event driven. Security events and transactions should occur in real time except where explicit exception is made. In any case, transactions associated with security systems should be sent when ready unless being explicitly held by design (in which case they are not ready). (Page 7) S-7.Document the flow of security-infrastructure-related information. The flow of information into, out of, and between components of the security-infrastructure should be documented and made available for access via the Emory Intranet. (Page 8) S-8.Develop core competencies in security implementation. Emory should develop core IT competence in the application, integration and configuration of security technologies and systems to implement security policy at Emory. (Page 9) S-9.Consider outsourcing in the context of risk to Emory’s security. Outsourcing an IT service must not create an unacceptable security risk for Emory. (Page 10) S-10.Establish and adhere to security best practices. There should be a set of Emory standard security best practices. Do not deviate from these best practices or from the security architecture simply for convenience or expediency. Instead, find a way to handle requirements securely within the architecture. (Page 11) 5.2 Assets Principles A-1.Externalize security policy data. To the extent possible, data representing security policy, such as attributes and their values, should be managed outside the systems that enforce the policy. (Page 12) A-2.Support delegation of administrative responsibilities. The security architecture should allow fine-grained delegation of administrative responsibilities with strong checks and balances. (Page 14) A-3.Support operations on groups of security attributes. The security infrastructure should be able to support grouping of attributes and values and assigning them all at once. (Page 15) A-4.Every resource has an owner. a. Every resource has an owner. What owners can do and the responsibilities required of them vary among resources. b. The Security Architecture should include means for determining who owns each resource. c. The Security Architecture should specify and communicate the rights of owners, and the duties and responsibilities of resource owners, stewards, custodians, and users for each resource. (Page 16) A-5.Say how custodial duties are distributed. The Security Architecture should specify how decisions regarding distribution of custodial duties and responsibilities are made. (Page 17) A-6.Provide an asset security classification scheme. The Security Architecture should include a classification scheme that allows owners of resources to indicate the level of protection needed for a resource in terms that are understandable to the owner and that can be linked to specific protective measures. The classification scheme should use no more categories than are needed to capture real differences in protection. (Page 18) ITA Version 1.9.8 © 2000 Emory University Page 2
  18. 18. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 5.3 Risks Principles R-1.Provide a clearinghouse of threats. The Security Architecture should include a clearinghouse of current and archived knowledge about security threats that has been validated and researched. (Page 19) R-2.Provide risk evaluation standards. The Security Architecture should provide a standard means of evaluating risks with regard to the probability that a loss will occur and severity of the loss (i.e., how damaging it would be). (Page 20) R-3.Provide for communication of security warnings. The Security Architecture should provide a means for communicating validated warnings and general information about security risks to the Emory University community. Page 21) 5.4 Countermeasures Principles C-1.Support use of layered security models. The security architecture should be able to support the use of layered security models and accommodate changes to those models as needed, such as the addition of layers and changes in security at the boundary of a layer. (Page 22) C-2.Support initiating auditing and monitoring as needed. The enterprise security architecture must use components with a built-in capability to audit, monitor and log their activity as selectively and quickly as needed. Other infrastructure components should be chosen to have these capabilities to the extent possible. (Page 23) C-3.Implement security policy as quickly as needed. The enterprise security architecture should provide policy frameworks for specifying attributes of security policy in a way that the security infrastructure could implement the policy as quickly as needed. (Page 24) C-4.The enterprise-securing infrastructure should be highly secure. The enterprise infrastructure whose purpose is to help secure other IT assets should be protected by the strongest security methods that Emory is able to use. (Page 25) C-5.Enforce security policy at as early a layer as possible. The security architecture should allow systems that enforce security policies to do so as near to the outermost security layer as policy and feasibility allow. Corollary: a. Keep authentication and its enforcement external to applications, services and resources. (Page 26) C-6.Reduce overall security complexity. The enterprise IT security architecture should be as simple and easy to use as possible while providing the needed protection, access and adaptability. (Page 27) C-7.Provide common security infrastructure and services. Provide common security tools, policy frameworks, and interoperable security infrastructure and services that can be generally used wherever and whenever needed within Emory to provide security. (Page 28) C-8.Provide appropriate access controls. The security architecture should be able to provide appropriate access control for all classes of resources, simultaneously supporting access privileges assigned at the discretion of the owner, as well as predetermined access privileges based on classification, policy and role that are available only when explicitly granted. Corollary: a. The security architecture should support giving authorized individuals and systems access to policy stores for purposes such as auditing and data analysis. (Page 29) ITA Version 1.9.8 © 2000 Emory University Page 3
  19. 19. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 C-9.Costing and pricing should promote desirable security practices. IT costing and pricing should promote recommended security practices and the use of the security infrastructure. Corollaries: a. The cost of providing the security infrastructure should use total cost and benefit over the full life cycle, including cost of training, support, maintenance, entry and exit, payback or return on investment, and adjustments for risk. b. Security systems should define and track over time their performance, health, available capacity, who is using them and how much. (Page 30) C-10.Use industry security solutions when feasible. Base the Emory security infrastructure on industry proven and supported components, methods, standards and tools. (Page 31) C-11.Deploy countermeasures appropriately. Decisions of deployment of countermeasures should be made with reference to the following considerations: (1) security classification and the resulting requirements, (2) availability of countermeasures, (3) best practices, and (4) management decision to fund the deployment. (Page 32) C-12.Coordinate countermeasures. University countermeasures and Healthcare countermeasures should be coordinated to ensure that they are not in conflict with each other. (Page 33) C-13.Provide a clearinghouse of countermeasures. The Security Architecture should include a clearinghouse of current and archived countermeasures that have been validated and researched. Page 34) ITA Version 1.9.8 © 2000 Emory University Page 4
  20. 20. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 5.5 Support for the Conceptual Principles Conceptual Architecture Principles B.8 Appropriate access controls A.1: Manage as a unity B.3 Standardize judiciously B.6 Facilitate access C.2 Staff competencies C.4 Industry std. solutions B.1.3 Modular loosely-coupled B.5 Common security layer A.3 Managed evolution B.1.4 Enable reuse A.2 Infrastructure as asset B.2 Reduce complexity B.4 Event driven systems B.1.1 Scalable infrastructure B.1 Prepared for change B.1.2 Easy integration C.1 Costing. and pricing B.7 Document Information flows C.3 Outsourcing Legend  Strong applicability  Moderate applicability Domain Principles S-1 Scalable infrastructure     S-2 Add new technologies       S-3 Standard interfaces              S-4 Modular components            S-5 Use standards              S-6 Event driven system        S-7 Document info. flow       S-8 Security competency       S-9 No risky outsourcing    S-10 Use best practices       A-1 Externalize policy data          A-2 Support delegation         A-3 Support groups         A-4 Assets have owners      A-5 Duty distribution     A-6 Security classification         R-1 Clearinghouse            R-2 Risk evaluation stds.        R-3 Comm. warnings          C-1 Layered models                  C-2 Auditing & monitoring        C-3 Impl’t. policy quickly       C-4 Highly secure infra.      C-5 Enforce at early layer          C-6 Reduce complexity       C-7 Common infra.              C-8 Appropriate controls       C-9 Costing & pricing         C-10 Industry solutions       C-11 Appropriate C-meas.       C-12 Coordinate C-meas.           C-13 Clearinghouse             ITA Version 1.9.8 © 2000 Emory University Page 5
  21. 21. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 5.6 Configuration principles 5.6.1 For network zones of trust 1. There may be only one path between adjacent zones. That path must be through a pool of one or more firewalls that are identically configured and connected. Reason: This reduces cost and complexity, since each path requires one or more firewalls. The use of firewalls makes ingress and egress more secure, and a single path is easier to secure. 2. Every resource (other than a firewall) must be in one and only one zone. Note that a network is a resource. Reason: Letting a resource (other than a firewall) be in multiple zones compromises the security architecture, because it could be used to create a path between zones that is not adequately secured. 3. Do not allow a resource (other than a firewall) to have network interfaces that connect to networks in multiple zones at the same time. Note that a network is a resource. Reason: Doing so places the resources in multiple zones at the same time, which compromises the security architecture. 4. Use the smallest number of zones needed to capture distinct levels of protection. Reason: Additional zones require additional equipment. Fewer zones keep down complexity and cost. 5. It must be possible to put a resource in any zone regardless of the physical location of the resource. This implies that (a) resources in the same physical location can be in different zones. (b) Resources in the same zone can be in different physical locations. (c) The zone in which a resource is placed can be a function of the role of the resource in addition to its location. Reason: Access control is not based solely on the physical location of a person or resource. It can also be based on role. ITA Version 1.9.8 © 2000 Emory University Page 6
  22. 22. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 6. Technologies The following are the technologies needed to implement the security infrastructure. Those governed by the security domain are given first, followed by assumed technologies from other architecture domains. These assumptions are necessary until architectures are established in those domains. 6.1 Governed Technologies–Assets Technology Resource Definition & Notes Security classification Allows owners of resources to indicate a level of protection for the scheme resource in terms that are understandable to the owner and that can be linked to specific protective measures. See principle A-6 Page 2. Asset policies Includes duties of owners, stewards, custodians, and administrators related to assets. Examples are policies about identifying assets and classifying them. Asset procedures Includes procedures to be followed by owners, stewards, custodians, and administrators related to assets. Examples are procedures to identify assets and classify them. 6.2 Governed Technologies—Risks Technology Resource Definition & Notes Security administrator Performs activities related to securing information and other computer resources. Assists users with application security needs. Maintains security databases, tables, libraries, and security software. Scans computer systems to detect security violations. Security analyst Directs research and validation of risks and security information. Directs tracking of incidents and intrusions. Decides when warnings, notifications and alerts are warranted. Directs the quantification of risks of threats and the cost to address them. Recommends security plans, policies, standards, procedures, and technology requirements. Risk policies Includes policies on risk assessment and escalation, sending of notices regarding threats and vulnerabilities, etc. Risk procedures Includes procedures for doing risk assessment and escalation, sending of notices regarding threats and vulnerabilities, etc. 6.3 Governed Technologies—Countermeasures 6.3.1 General Security Technology Resource Definition & Notes Methods used to control Methods can include Passwords, digital certificates, Biometrics, Smart access cards, and mechanical controls (keys, dongles). Encryption Examples include use to secure data stored in a database, network traffic in transit, and e-mail. PKI Public Key Infrastructure. Includes technologies such as digital certificates, digital signatures, and certificate authorities. Countermeasures policies Includes policies relative to security requirements of owners, including policy on: certification of resources, placement of resources in zones, ITA Version 1.9.8 © 2000 Emory University Page 1
  23. 23. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Technology Resource Definition & Notes response to a security incident, fire drills (whether to have them, how often, etc.), passwords (rules for good ones, aging, testing, etc.). Countermeasures Includes procedures to implement policy relative to security requirements procedures of owners, including procedures to: get resources certified and placed in a zone, respond to and recover from a security incident, practice responding (fire drills), test passwords, etc. 6.3.2 Network Security Technology Resource Definition & Notes Firewall Involves platform, software, policy, and administration. Network Intrusion Detection Scans network traffic in real time to detect activity that violates security policy. For example, it could detect the beginning of an attack on a system or detect that unauthorized network access is occurring. Network vulnerability Probes devices that are connected to a network to detect vulnerabilities scanner to network attacks. Checks security from the outside. Network Virus scanner Scans network traffic for viruses in real time. Typically runs on firewall or dedicated platform. Trap Provided as target of attack to obtain information about an attacker and the methods of attack. Proxy server Redirects authentication requests between different zones of trust. May be used as a firewall to make the network addresses of devices on one side invisible to the other. Network security policies Countermeasures policies and procedures specific to Network security. and procedures 6.3.3 Platform Security Technology Resource Definition & Notes System Intrusion Detection Checks data about processes that are running, data in logs and files and other data accessible on a system to detect security violations. For example, it could detect that data has changed when it should not have. System vulnerability Checks security settings on a system to detect vulnerabilities. For scanners example, it could detect that security settings on a file are too low or that someone has unauthorized privileges. Checks security from the inside. File Virus Scanner Runs on a system to scan for viruses in files accessible by that system. Tools used to control Examples are shim, Pluggable Authentication Module (PAM), RACF, and access web authorization. Platform security policies Countermeasures policies and procedures specific to Platform security. and procedures ITA Version 1.9.8 © 2000 Emory University Page 2

×