1. An Information Technology Architecture for Emory UniversitySecurity Domain Architecture Adopted by CIRTFebruary 20, 2002 Committee on Information Technology Architecture March 6, 2002Version 1.9.8

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 HISTORYReleaseDescription Date1.0 Insert summary, overview and principles November 9, 20001.1 Updates based on Nov 10, 2000 meeting November 13, 20001.2 Fix formatting problems, add to glossaryDecember 7, 20001.3 Add trends, standards & other from latest meetingsDecember 7, 20001.4 Reorg., additional info, changes to technologies & configurations December 11, 20001.5 Changes from Dec. 15 task force meeting & polishing December 17, 20001.6 Std. Headers & footers, copy edit, expand Exec. summaryJanuary 16, 20011.7 Updated all but principles, tutorial overview, section pagination February 20, 20011.8 More emphasis on classification, fix formatting in products February 23, 20011.8.1 Add classification to Fig 2; Update Domains in Fig 1; Next StepsFebruary 23, 20011.9 S-10 to std., smooth rough edges, respond to IT-ARCH feedback February 26, 20011.9.1 Copy editing, resource default status, definition of scalable March 27, 20011.9.2 Codes to 7 & 8. Pending classification policy. Delete old 8.4. April 9, 20011.9.3 Copy edits, clarification, role definitions in 6, 11, 12April 12, 20011.9.4 Respond to DWB & SSA (3, C-7), misc. edits.May 4, 20011.9.5 Respond to RP & DB, 5.5 format, 6-8 tables, 10 considerations May 17, 20011.9.6 Update section 2 outline May 21, 20011.9.7 Change status to Ready for Adoption Sept. 19, 20011.9.8 Changed status to Adopted; added copyright & more bookmarks March 6, 2002 ITA Version 1.9.8 2000 Emory University Page ii 3. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002TABLE 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.............................................1LIST 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 UniversityPage iii 4. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20021. 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 Emorys security needs for the good of all of Emory. Based on Emorys 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 asintended; Allowing selected Emory, departmental, and school information resources to safely be madeavailable 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 ina 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 UniversityPage 1 5. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20022. 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 DomainsChange Data andInformationEmory's VisionManagement Platform Mission Network Goals Distributed PrioritiesArchitecture Conceptual Environment Strategies RequirementsArchitecture Management Security Environment Integration Application Trends Intranet & Forcese-Commerce Challenges Online Learning Constraints Collaboration Opportunities Directory Document 1Document 2 Figure 2-1. Process to derive domain architecturesThis document is one of a set of documentsone for each domainthat 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 UniversityPage 1 6. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20023. Overview3.1Security in generalSecurity is a topic that is about as exciting as watching paint dry. -- Gene SpaffordThe only truly secure system is one that is powered off, cast in a block of concrete, andsealed 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 dont know the threat, how do you know what to protect? If you dont know whatto protect, how do you know you are protecting it? If you are not protecting it. . . .theadversary (dragon) wins! -- The Laws of OPSECBalancing 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. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002Classification 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 thatDrives RequirementsDrives the Senior Emory leaders would driveclassification identification and classification of assetsSenior OwnersCustodians VP for by requiring it of owners and stewards. LeadersStewardsAdministratorsIT The Vice Provost for IT would also take leadership in this by encouraging Access byKeep asset custodians and administrators. TheHelp Desk, data up-to-dateLocal 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 enoughDirectory Information Feed interest to appear in the EnterpriseServiceDatabase Directory. Figure 3-2. Assets informationThreats, 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. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002immediately, 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. Externaltrusted Pullsources ofClearinghouse information of risks and countermeasures ISS VulnerabilitiesDB InfoGuard Incidents Etc. Intrusions What, why Cost to fixTargeted Alert CountermeasuresEntry LISTSERV a Updatet campus List da Etc.ed at Notice lidAl Va Warning ert Etc.OtherAssets Who to notifysources of Databaseinformation E-mailAnalysis 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 UniversityPage 3 9. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Emory Trusted Emory UntrustedEmory Proprietary & Confidential Public informationSecure Available to Emory faculty, staff and & resourcesRestricted students only Available toAvailable toanyone Policy Pocketsonly those grantedaccessOutsideEmory 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.2Network SecurityEthernet over barbed wire? Well, thats one approach to network security.-- Mark VinselFocus 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 UniversityPage 4 10. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002attack, 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. IntrusionRT/SW ID FWFWRT/SW = Router/SwitchCK ID = Intrusion Detection FW = Firewall CK = Optional additional checksFigure 3-5. Network zone technologiesDetectors (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. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002Policy 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 ZonePolicy Pocket 1 CKOptional otherZone (e.g. project 1 servers) checks Router/Policy Pocket 2Router/ Firewall(s)Switch (e.g. project 2 servers) Switch Policy Pocket 3 Intrusion remainder of zoneDetectionFigure 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 IdentityVerify identity FireFire AccessAccess wallwall PolicyVerify DataResourceAccess TargetFigure 3-7. Firewall access controlProxy. A separate system called a proxy that talks to a target resource on behalf of the Prove IdentityVerify identity ProxyFire FireAccessAccesswall wallPolicyRequestVerify Data AccessTarget Figure 3-8. Proxy access controlITA Version 1.9.8 2000 Emory University Page 6 12. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002requestor would provide an additional layer of access control. It could be located in a zone ofSecurity 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 requesters authenticated identity (or lack of identity in the case of anonymous access).3.3Subdomains 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 DescriptionAssets Resources that need protection.RisksPossibilities of harm or loss.CountermeasuresWays to reduce the probability of harm or loss to an acceptable level. ITA Version 1.9.8 2000 Emory University Page 7 13. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 3.4Related 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 NameDomain DescriptionRelationship to Security Arch.DirectoryThe directory service architecture defines theCan provide infrastructure to create a single, unified naming security policy scheme that uniquely identifies entities, and information such provides the capability for a network-attachedas for service, system, or device to use an entitys nameauthentication and to obtain information about the entity. authorization.NetworkThe Network Architecture provides the voice, videoA 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 principlesInformationArchitecture defines the components and and standards formanagement standards for accessing, exchanging, modeling,organizing, storing storing, converting, organizing, and distributing and retrieving data and information. Product and technologysecurity-related categories governed by this domain includedata. 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 UniversityPage 8 14. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20024. IT Trends4.1Trends 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 widespreadexposure to threats. Faster and cheaper systems enable attackers to afford systems that can try possiblekeys faster and crack encryption faster, so there will be a need for increasingly largerkeys. Denser technology enables creation of small systems using wireless technology that canbe stationary or mobile. How can the location and identity of such systems bedetermined so that access control can take device location and identity into account? The infrastructure will be challenged to support security across an increasingly diverseset of systems and devices.2. Demand for capacity will continue to increase. Increased numbers of users and increased usage will require scaling up management ofaccounts and administration of access control. Standards and infrastructure will beneeded to enable that scalability. As a result Emory will need to get out of the passwordsynchronization business. General growth in demand will require investing money in general computinginfrastructure, 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 willneed to rely on additional factors such as something you have (e.g. token) or somethingyou are (e.g. fingerprint). Access control will have to be based on who is requesting access, where they arelocated, date and time of access attempt, and target of access to determine what theywill be allowed to do. Support will be needed for use of different methods of identification depending onlocation.4. Security will be a primary concern with increased dependence on networkapplications. Emory will need to support technologies related to intellectual property as they becomeimportant. Costs will continue to rise due to growth in attacks. Emory will need to use a knowledge management approach to manage the knowledgenecessary 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. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20025. 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 thenumber 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 theImplications of Principle S-8 on page 9.)4.2Domain-specific Trends The following are trends specific to this domain.6. Organizations that are leading edge in security focus first on making decisions needed toestablish security policy before focusing on security technology.7. Miniaturization will bring down the cost of biometric devices, leading to their wider use, suchas in smart cards and small devices like wearable computers.8. PKI will to be important for implementing digital signatures, and for setting up encryptedconversations among devices.9. The expertise needed to initiate an attack is going down as those with the expertise createkits 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. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20025.Security Principles The following principlesderived 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 UniversityPage 1 17. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 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 Emorys 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.2Assets PrinciplesA-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 UniversityPage 2 18. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20025.3Risks PrinciplesR-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.4Countermeasures PrinciplesC-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. 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 UniversityPage 4 20. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002 5.5Support for the Conceptual Principles Conceptual Architecture Principles B.8 Appropriate access controls A.1: Manage as a unityB.3 Standardize judiciously B.6 Facilitate accessC.2 Staff competenciesC.4 Industry std. solutions B.1.3 Modular loosely-coupled B.5 Common security layerA.3 Managed evolution B.1.4 Enable reuseA.2 Infrastructure as assetB.2 Reduce complexity B.4 Event driven systemsB.1.1 Scalable infrastructureB.1 Prepared for change B.1.2 Easy integration C.1 Costing. and pricingB.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 Implt. 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. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20025.6Configuration 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 ofone 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 tosecure. 2. Every resource (other than a firewall) must be in one and only one zone. Note that anetwork is a resource.Reason: Letting a resource (other than a firewall) be in multiple zones compromises thesecurity architecture, because it could be used to create a path between zones that is notadequately secured. 3. Do not allow a resource (other than a firewall) to have network interfaces that connect tonetworks 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, whichcompromises 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 complexityand cost. 5. It must be possible to put a resource in any zone regardless of the physical location of theresource. This implies that (a) resources in the same physical location can be in differentzones. (b) Resources in the same zone can be in different physical locations. (c) The zonein which a resource is placed can be a function of the role of the resource in addition to itslocation.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. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20026.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 TechnologiesAssetsTechnology ResourceDefinition & NotesSecurity classificationAllows owners of resources to indicate a level of protection for thescheme 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 TechnologiesRisksTechnology ResourceDefinition & NotesSecurity 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 policiesIncludes policies on risk assessment and escalation, sending of notices regarding threats and vulnerabilities, etc.Risk proceduresIncludes procedures for doing risk assessment and escalation, sending of notices regarding threats and vulnerabilities, etc.6.3 Governed TechnologiesCountermeasures 6.3.1 General SecurityTechnology ResourceDefinition & NotesMethods used to controlMethods can include Passwords, digital certificates, Biometrics, Smartaccess cards, and mechanical controls (keys, dongles).Encryption Examples include use to secure data stored in a database, network traffic in transit, and e-mail.PKIPublic 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. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002 Technology Resource Definition & Notesresponse to a security incident, fire drills (whether to have them, howoften, etc.), passwords (rules for good ones, aging, testing, etc.).Countermeasures Includes procedures to implement policy relative to security requirementsproceduresof owners, including procedures to: get resources certified and placed ina zone, respond to and recover from a security incident, practiceresponding (fire drills), test passwords, etc. 6.3.2 Network SecurityTechnology Resource Definition & NotesFirewallInvolves platform, software, policy, and administration.Network Intrusion Detection Scans network traffic in real time to detect activity that violates securitypolicy. For example, it could detect the beginning of an attack on asystem or detect that unauthorized network access is occurring.Network vulnerability Probes devices that are connected to a network to detect vulnerabilitiesscanner to network attacks. Checks security from the outside.Network Virus scanner Scans network traffic for viruses in real time. Typically runs on firewall ordedicated platform.TrapProvided as target of attack to obtain information about an attacker andthe methods of attack.Proxy serverRedirects authentication requests between different zones of trust. Maybe used as a firewall to make the network addresses of devices on oneside invisible to the other.Network security policies Countermeasures policies and procedures specific to Network security.and procedures 6.3.3 Platform SecurityTechnology Resource Definition & NotesSystem Intrusion DetectionChecks data about processes that are running, data in logs and files andother data accessible on a system to detect security violations. Forexample, it could detect that data has changed when it should not have.System vulnerabilityChecks security settings on a system to detect vulnerabilities. Forscannersexample, it could detect that security settings on a file are too low or thatsomeone has unauthorized privileges. Checks security from the inside.File Virus ScannerRuns 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, andaccessweb authorization.Platform security policiesCountermeasures policies and procedures specific to Platform security.and procedures ITA Version 1.9.8 2000 Emory University Page 2 24. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002 6.4 Technologies needed from other architecture domains These technology resources governed by other architecture domains are also needed by the security architecture. Technology Usage & Notes Governed by SubdomainsResource AR CDatabase For the asset database, clearinghouse of risks, DataYY YManagement and access policy store.managementSystemWeb frontTo enter and access information. Web access isIntranet & e- YY Yendpreferred.CommerceDatabase To configure and maintain the database. DataYYadministratormanagementPlatform For databases, scanners, proxys, firewalls, etc.PlatformYY YData Analyst Determine database schemas, consult asDataYY Yconsulting needed. managementScriptingTo automate procedures and feeds. Application YY YtoolsDiscussion For notification (such as warnings).CollaborationYlistStatisticalFor analyzing incidents and doing probability ApplicationYanalysis tools projections.EducationIncludes documents and classes on policy and? YY Y best practices; checklists for hardening systems; instructors and classrooms. For end users and for local support.Web server Provide web access to the database. Intranet & e- YY Y CommerceDirectoryTo provide standards-based look up of accessDirectory YY Y policy data about things requesting access andService the target of that access.VPNVirtual Private Network. Provides authenticated,NetworkY encrypted extension of the Emory network to devices on networks outside Emory. A=Assets subdomain, R=Risks subdomain, C=Countermeasures subdomain ITA Version 1.9.8 2000 Emory University Page 3 25. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20027.Standards Compliance For the technologies governed by this domain, this section gives standards that are in current use at use at Emory or that are recommended for future use at Emory plus recommendations regarding compliance with them. See the Glossary for definitions. Standards governed by the architecture are given first, followed by assumed standards from other architecture domains. The assumed standards are necessary until standards are established in those domains.7.1 Benefit of standards There is considerable variation in IT security at Emory that creates needless complexity and uncertainty in both standards and products. The following comparisons give an indication of where this occurs and how the use of standards can lead to more simplicity and clarity.Current state with large variation: Identification of assets is haphazard. Some are inadequately secured as a result of beingoverlooked. Determination of measures to secure an asset is done anew each time. Discovery of vulnerabilities and countermeasures of IT resources is haphazard. There is no agreed upon basis for judging the adequacy of security of an IT resource. Security practices and procedures must be discovered anew by each administrator andvary widely in their effectiveness. System compromise and security violations are discovered by accident. Response to security incidents is reinvented for each event, reducing effectiveness andresponsiveness. There is no estimate of the risk to Emory of security incidents.Future state with standards: Assets are inventoried and classified as to the level of security needed. Policies and procedures are defined to secure an asset according to the needed level ofsecurity. Vulnerabilities and countermeasures are documented. Systems are tested for vulnerabilities. Best practices in security are provided. Standard technologies are available to detect intrusion. Standard procedures are defined to respond to security incidents. Security vulnerabilities, countermeasures, and incidents are tracked and analyzed toproduce estimates of the risk to Emory of security incidents.7.2 Descriptors for standards Acceptanceo International: Wide use by the international technology communityo National: Wide use within a countryo HiEd: Wide use within Higher Education communityo Name of a group: Wide use specific to this group (e.g. Internet2 members) Authorityo Name of the organization that defines and maintains the standardo De facto: Not defined as a standard, but receives wide acceptanceo Infol.: Informational RFC. Does not have the force of an Internet standard, but is one that receives wide acceptance within the Internet technical community. ITA Version 1.9.8 2000 Emory University Page 1 26. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 Extent of usage of standard at Emory o H = High use o M = Medium use o L = Low use o N or None = Not used Emory future compliance with standard Sometimes includes caveats (such as a length of time) o Y = Compliant: Full compliance with the standard o L = Limited compliance o N = Not compliant: No compliance Missing data: o ND = Not decided: No decision has been made o NK = Not known7.3Standards ComplianceAssets Technology Standards Authority/ Extent of Future Reason ResourceAccept- Usage atCompli-anceEmory ance Security classification HIPAA U.S. Govt./ LowY Federal law schemeNational Asset policiesEmory policiesEmory /LowY Emory Emory requirementSANS SANS / NKLowNDNeeds studyFERPAU.S. Govt./ High Y Federal law NationalHIPAAU.S. Govt./ Medium Y Federal law NationalCOPPAU.S. Govt./ LowY Federal law National Asset procedures NK NK / NKNK NDNeeds study7.4Standards ComplianceRisks Technology Standards Authority/ Extent of Future Reason ResourceAccept- Usage atCompli-anceEmory ance Security analyst Current Emory position Emory/ LowY Required.Security Analyst (LB07) Emory Security Current Emory position Emory/ LowY Required. administratorSecurity Administrator Emory(LB03) Risk policiesNK NK / NKNK NDNeeds study Risk proceduresNK NK / NKNK NDNeeds study ITA Version 1.9.8 2000 Emory University Page 2 27. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20027.5Standards ComplianceCountermeasures 7.5.1 General Security Technology StandardsAuthority/Extent ofFutureReason Resource Accept-Usage at Compli- ance Emoryance Methods used toPassword challengeDe facto /High 1 yr See trends control access IntlRBACNIST / NK None YManageability Encryption RC4 40 bitNK / NK High YShort termRC4 128 bit NK / NK LowY4.1 Trend #1Unix password (crypt) XOPEN / Medium ND Needs studyIntl.DES NIST / U.S. Medium ND Needs study PKIFederal PKI Technical NIST / NK None When Needs studyWorking Group stds.doneHEPKI EDUCAUSE NoneWhen To interoperate& Internet2/ done within higherHiEdeducation CountermeasuresNKNK / NK NK ND Needs study policies CountermeasuresInternet Best Practices Infol. / LowND Needs procedures such as rfc 2196, 2504, Internetevaluation2827, 3013Operations Security NSDD 298/ None ND Needs(OPSEC) Process U.S. Govt. evaluationdepts. andagenciesJoint CommissionJCAHO/High YRequired forStandards Healthcareaccreditationorgs. ITA Version 1.9.8 2000 Emory UniversityPage 3 28. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20027.5.2 Network Security TechnologyStandardsAuthority/ Extent ofFuture Reason ResourceAccept- Usage at Compli-anceEmoryance FirewallTCP/IP v4 protocols IETF/ Intl.HighY Required OPSEC Checkpoint/ Low Only if Only Firewall-1 Consortiumchoosesupports it, but it Firewall-1provides interoperability and choice of other products. TechnologyStandardsAuthority/ Extent ofFuture Reason ResourceAccept- Usage at Compli-anceEmoryance Network Intrusion OPSEC Checkpoint/ Low Only if Required by Detection ConsortiumchooseFirewall-1 Firewall-1 Intrusion Detection IETF/ WillNoneY Internet drafts Exchange Format be Intl. Whenare at finalized www.ietf.org/ html.charters/id wg-charter.html Network vulnerability OPSEC Checkpoint/ Low Only if Required by scanner ConsortiumchooseFirewall-1 Firewall-1 Network virus CVP Checkpoint/ NKOnly if Required by scanner ConsortiumchooseFirewall-1 Firewall-1 TrapTCP/IP v4 protocols NK / NK HighY Required Proxy serverSOCKS v5IETF/ Intl.NoneY Applicable if choose session layer approach Application protocols IETF/ Intl.HighY If choose application layer approach TCP/IP v4 IETF/ Intl.HighY Necessary UDP v4IETF/ Intl.. HighY When needed UDP v6IETF/ Intl.. NoneY When needed TCP/IP v6 IETF/ Intl.NoneY When needed Network securityNKNK / NK NKNDNeeds study policies and procedures ITA Version 1.9.8 2000 Emory UniversityPage 4 29. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20027.5.3 Platform Security TechnologyStandardsAuthority/Extent ofFuture Reason ResourceAccept-Usage at Compli-ance Emoryance System IntrusionIntrusion Detection IETF/ Will NoneWhenInternet drafts Detection Exchange Format be Intl.finalized are atwww.ietf.org/html.charters/idwg-charter.html MD5 (rfc 1321)IETF/ Intl. NKY Best practiceSystem vulnerabilityNKNK / NKNKNDNeeds study scanner TechnologyStandardsAuthority/Extent ofFuture Reason ResourceAccept-Usage at Compli-ance Emoryance File virus scannerNKNK / NKNKNDNeeds study NKNK / NKNKNDNeeds study Tools used to control NKNK / NKNKNDNo standards access NKNK / NKNKNDNeeds study Platform security NKNK / NKNKNDNeeds study policy and procedures7.6Assumed standards from other architecture domains. TechnologyStandardsAuthority/Extent ofFuture Reason ResourceAccept-Usage at Compli-ance Emoryance DatabaseODBCMicrosoft/ Low Y Required Management System Intl. SQL ANSI, ISO, Low Y Required IEC 9075- 1-5 1999/ Intl. Web front end HTML v3 W3C / Intl. HighY Required Pure JAVA 2 Sun/ Intl.MediumNDNeeds study JavascriptECMA-262,HighY (ECMAScript)ISO-16262/ Intl. HTTP 1.1, rfc 2616IETF/ Intl. HighY Required DatabaseEmory position Emory/Low Y Required administrator database Administrator Emory (LK37) ITA Version 1.9.8 2000 Emory University Page 5 30. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002Platform NTMicrosoft/HighYIntl.UNIX (AIX, Solaris) Vendor/ Low YIntl.Hardware (IBM, Sun or Vendor/ HighNDNeeds studyIntel)Intl.TCP/IP protocolsIETF/ Intl.HighY Required Data Analyst Emory position Data Emory/Low Y Required consulting Analyst (LB10)Emory Scripting toolsPerl v5 Larry Wall/ MediumYIntl. Discussion listListservLsoft/ Intl. HighY Technology StandardsAuthority/ Extent of Future Reason Resource Accept- Usage atCompli- anceEmory ance Statistical analysis SAS v8Vendor /MediumY Would be toolsIntl.chosen bySPSS v10Vendor /MediumY analystIntl. EducationNKNK / NK NKNDNeeds study Web server HTTP 1.1, rfc 2616IETF/ Intl.HighY RequiredTCP/IP v4 protocols IETF/ Intl.HighY Required DirectorySpecified by DirectoryNK / NK Low YArch VPNIPSec IETF/ Intl.Low Y RequiredISAKMP/Oakley IETF/ Intl.NoneY RequiredTCP/IP v4 protocols IETF/ Intl.HighY Required ITA Version 1.9.8 2000 Emory UniversityPage 6 31. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20028.Standard Products This section gives the relevant products currently in use at Emory and their current and recommended future status relative to their use to implement the security architecture. Categories that do not have products in use at Emory represent gaps that need to be filled to implement the security architecture. Standards specified by the security architecture are given first, followed by assumed standards from other architecture domains.Life-cycle status (current and future) for products and product categories: Test: Under test, not for production use Pilot: Step following test; limited production use; goes to recommended or STD if successful. Rec: use at Emory is recommended and encouraged. STD: Emory standard; use is required. Maint: In use, supported in maintenance mode only. Out: In process of being phased out Codes for missing data: ND = Not decided: No decision has been made NK = Not known NC = Not collected NA = Not applicable8.1 Standard ProductsAssetsTechnology Current Emory Products: Consistent with position Life Cycle StatusProductname / version / source on trends /Category Aligns with principles / CurrentFuture Complies with standardsSecurity Information & ResourceND / ND / ND RecOutclassification Access Classificationscheme Guidelines / July 1995 / NK Resource Security Y/Y/YTest STD Classification Guidelines / pending / IRM Healthcare confidential and ND / ND / ND HC STD ND not confidential / NK / Emory HealthcareAsset policies Information Access Policy / ND / ND / ND RecOut July 1995 / www.emory.edu/ITD/POLICY/ info.access.html Information and ResourceND / ND / ND Test STD Access Policy / pending / IRMAssetNK / NK / NKND / ND / ND ND NDprocedures ITA Version 1.9.8 2000 Emory University Page 1 32. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20028.2 Standard ProductsRisksTechnology Current Emory Products: Consistent with position Life Cycle StatusProductname / version / source on trends /Category Aligns with principles / CurrentFuture Complies with standardsSecurity ND / ND / IRM Y/Y/YSTDSTDanalystSecurity ND / ND / IRM Y/Y/YSTDSTDAdministratorRisk policiesNK / NK / NKND / ND / ND ND NDRisk NK / NK / NKND / ND / ND ND NDProcedures8.3 Standard ProductsCountermeasures 8.3.1 General SecurityTechnology Current Emory Products: Consistent with position Life Cycle StatusProductname / version / source on trends /Category Aligns with principles / CurrentFuture Complies with standardsMethods used Userids & passwords / NK /ND / ND / ND STDNDto control vendoraccessEncryption Oracle networking / 8 / OracleND / ND / YSTDSTD Corp. SSL in various web products / ND / ND / YSTDSTD NC / NC PGP / NC / NC ND / ND / ND Test TestPKIServer digital certificates (such ND / ND / YSTDSTD as password change server) / NC / NCCounter- NK / NK / NKND / ND / ND ND NDmeasurespoliciesCounter- NK / NK / NKND / ND / ND ND NDmeasuresprocedures ITA Version 1.9.8 2000 Emory UniversityPage 2 33. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 20028.3.2 Network SecurityTechnology Current Emory Products:Consistent with position Life Cycle StatusProductname / version / sourceon trends /CategoryAligns with principles / CurrentFutureComplies with standardsFirewall Firewall-1 / NC / CheckPoint Y / ND / Y ND ND (Healthcare only)NetworkReal Secure / NC / ISS Y / Y / Y inc OPSECSTDSTDIntrusionDetectionNetworkInternet Scanner / 6.1 / ISS Y / Y / Y inc OPSECSTDSTDvulnerabilityscannerNetwork virusNK / NK / NK ND / ND / ND ND Suggestscanner NortonTrap NK / NK / NK ND / ND / ND ND NDProxy server NK / NK / NK ND / ND / ND ND NDNetworkNK / NK / NK ND / ND / ND ND NDsecuritypolicies andprocedures 8.3.3 Platform SecurityTechnology Current Emory Products:Consistent with position Life Cycle StatusProductname / version / sourceon trends /CategoryAligns with principles / CurrentFutureComplies with standardsSystem Tripwire / 2.2 / NKND / ND / ND ND NDIntrusionDetectionSystem NK / NK / NK ND / ND / ND ND NDvulnerabilityscannerFile virus VirusScan / 4.5.0 / McAfee ND / ND / ND RecOutscannerVirusScan / 4.5.1 / McAfee ND / ND / ND PilotRec Virex / 6.1 / McAfee ND / ND / ND RecRecTools used toRACF (MVS) / NC / IBMND / ND / ND STDSTDcontrol access PAM (Solaris, Linux) / NC / NC ND / ND / ND STDSTDPlatform NK / NK / NK ND / ND / ND ND NDsecurity policyand procedures ITA Version 1.9.8 2000 Emory University Page 3 34. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002 8.4 Assumed products from other architecture domains.Technology Current Emory Products:Consistent with position Life Cycle StatusProductname / version/ source on trends /CategoryAligns with principles / CurrentFutureComplies with standardsDatabase Oracle DBMS / 8i / OracleY/Y/YSTDSTD 3ManagementyrsSystem DB2 for MVS / NK / IBM Y/Y/YSTDSTD Sybase DBMS / 11.9.2 / Y/Y/YMaintOut SybaseWeb front endNetscape / 4.5+ / AOLY/Y/YRecND Internet Explorer / 4+ / Y/Y/YRecSTD MicrosoftDatabase ND / ND / IRMY / Y / ND ND NDadministratorPlatform AIX / 4.3.3 / IBMY/Y/YSTDSTD Solaris / 5.6 / SunY/Y/YSTDSTD NT 4 / sp 6a / Microsoft Y/Y/YSTD1 yr Data Analyst ND / ND / IRMND / ND / ND ND NDconsultingScripting toolsPerl / v5.05 / NKY/Y/YRecRec Discussion listLISTSERV / 1.8d / LSoftY/Y/YSTDSTD StatisticalSAS / 8.1 / SAS InstituteY/Y/YRecRecanalysis tools SPSS / 10.0.5 / SPSS Inc.Y/Y/YRecRecEducationNK / NK / NK ND / ND / ND ND NDWeb server Netscape / 3.5+ / SunY/Y/YSTDSTD Apache / 1.3.x / NCY/Y/YSTDSTD,preferredforsecurityDirectoryIPlanet / v4.1+ / SunND / Y / Y STDOut iPlanet / v5 / Sun ND / Y / Y NK STDVPNContivity / 4500 / NortelND / ND / ND STDSTD ITA Version 1.9.8 2000 Emory University Page 4 35. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 20029. Configurations The intent of the configurations section is to provide enough detail to prescribe implementation at Emory in a way that follows the principles yet uses standards and products to reduce needless complexity and keep down support costs. The section should also contrast at the individual products level and at the standards level any needless complexity of the current state with the simplicity and clarity of the envisioned future state. At this stage of the development of this domain, the implementation details are still being worked out. Once these details are available, they would be included or linked from this section and made available according to their security classification.9.1Assets Configuration There is currently wide variation in the way in which people at Emory think about assets and their ownership, identify and classify the assets, identify stewards, custodians, and administrators and delegate responsibilities to them. This state of affairs creates an environment that is too complex to secure at reasonable cost. The architecture reduces the complexity and the number of people to manage it through the use of: standard roles (owner, steward, custodian, administrator); standard policies and procedures for identifying assets, the people in the standard rolesthat are associated with the asset, and the delegation of responsibilities; a standard location in which to store the asset information; standard access to asset information via the web; standard database software and server; a standard Enterprise directory.Figure 3-1 on page 2 indicates generally how the standard products would be used to accomplish this. The details are yet to be decided. In many cases it is assumed that choices would be made based on standards from other architecture domains that are yet to be created. Configuration details would include: Policy regarding what is expected of owners, stewards, custodians, and administrators. A process and a procedure for identifying assets and information about them, includingtheir owners and their classification. Choice and configuration of:o The asset information database and where it would be located.o The web server and how it will access the database.o Equipment on which to run the database and web server.o Data elements to feed to the directory and configuration of that feed.o An interface for access to the database. ITA Version 1.9.8 2000 Emory UniversityPage 1 36. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 9.2Risks Configuration Figure 3-2 on page 3 indicates generally how the standard products would be used implement the risks subdomain.There is currently much variation in knowledge of threats and vulnerabilities, risk assessment, and incident reporting as well as much duplicated effort as the result of people doing their own assessments based on individually selected sources and methods of research. An additional factor is the variation in time available to spend on this work as a result of extent to which risk assessment is a job responsibility or volunteered time.The architecture reduces cost by leveraging the economy of scale of centralizing risk assessment and dissemination of information for all of Emory. Centralizing this function reduces the number of people that have to be involved in tracking threats and vulnerabilities, assessing risks, and locating, documenting and disseminating countermeasures. These people have this work as part of their job responsibility and have the expertise and time to do it. In addition, they can act for the good of all of Emory by checking known assets for vulnerability to a current threat and getting protective filters put in place at the network border.The architecture reduces complexity by providing standard places to send reports of incidents and get information on risks and countermeasures.The details are yet to be decided. In many cases it is assumed that choices would be made based on standards from other domains that are yet to be created. Configuration details would include: Selection of trusted resources. Design, placement, and configuration of the risks and countermeasures database. Design and configuration of interfaces and feeds from trusted sources. Design and configuration of an interface for access to the database. Configuration of a listserv list. Selection and configuration of software tools and algorithms for analysis. ITA Version 1.9.8 2000 Emory University Page 2 37. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002 9.3Countermeasures Configuration 9.3.1 Placement of assets and countermeasures in zones Figure 9-1 (page 4 below) illustrates the need for multiple network zones of trust and what would be put in them. The outer Emory Public zone would be the default location for Emory resources that are not classified or that are classified as Public. The protective measures would be a first line of defense against attacks and would place minimal controls on the network traffic. Untrusted systems, that is, systems that are not administered to fix security vulnerabilities and lack checks for intrusion, would also be in this zone. Such systems typically include most desktop machines and servers on the Emory campus plus computers in public Emory facilities. They also include Emory computers located in non-Emory facilities such as at home or in a hotel room. Intrusion Detection would detect internal attacks that occur within this zone as well as watch for attacks against the Private zone. The CVP system acts as an additional filter for certain traffic, such as scanning for viruses in e-mail.The next zone, Private, uses an additional set of checks and moderately strong access rules and restrictions to provide added protection for resources classified as proprietary or confidential. This zone would typically contain servers from departments, schools and divisions, and might use Policy Pockets if necessary to handle differences in security policy. The zone also helps protect trusted hosts from internal attacks, since such attacks would most likely come from untrusted systems. The Intrusion Detection system watches for attacks and security violations. The ISS Scanner checks systems for network vulnerabilities. A trap system acts as a target to tempt intruders away from other systems. The trap would also log access attempts, including the attackers keystrokes, to get information about an attacker or to obtain advanced warning of a more concerted attack.Resources classified as highly restricted are in a Secure zone that differs in a fundamental way from the other zones. The devices in this zone use special network numbers that are not seen by devices outside the zone. Instead, all traffic goes through a proxy server that acts as an intermediary and translates between the special numbers and Emory network numbers. As a result, devices outside the zone cannot interact directly with devices inside this zone. Instead, the proxy server handles all such interactions on behalf of the communicating parties. Assets in this zone include the mainframe and infrastructure services such as the master DNS and security servers. In particular, the policy store of security information would be in this zone. ITA Version 1.9.8 2000 Emory UniversityPage 3 38. An IT Architecture for Emory UniversityAdopted by CIRT Security Domain ArchitectureFebruary 20, 2002Figure 9-9. Placement in zones ITA Version 1.9.8 2000 Emory University Page 4 39. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 200210. Considerations & Next Steps10.1 Considerations for this domain 1. RBAC roles. The number of roles needed for RBAC may be larger than expected, sinceaccess privileges might not map to job title. Indeed, the same job title is used for jobs thatare similar in nature, but are very different in their particulars and in the area of theuniversity where they occur. In addition, the number of roles will be expanded due to accessthat is given because of who you are. For example, some in a job title can decide what theywill do and what they will delegate, which causes access needs to depend on the way anindividual organizes the work. 2. Security of the access policy data. The information in external policy stores will need tobe classified and placed in appropriately secure zones of trust. This may require partitioningthe information if it cannot all be placed in or replicated to a sufficiently secure single zone.This is particularly an issue for the Directory service, given the varying types of informationthat it would likely contain. 3. Use of authentication services. Of immediate concern is how to architect generalauthentication services so that allowing insecure applications and systems to authenticateEmory network ids does not compromise the security of those ids. (More generally, seePrinciple C-7, page 3.) 4. Reaction to intrusion. What should the security architecture say about Emorys reaction todetection of an intrusion? The statement would need to cover preparation, detection,containment, eradication, recovery and follow-up. The reaction would need to take intoaccount that some intrusions have greater impact than others, some require quicker or morecoordinated response than others, and the skills required can vary depending on the natureof the incident.10.2 Considerations for other domains 10.2.1For the Directory Service domain 1. Directory support for Security. The Directory Service architecture has a principle tosupport the needs of security. However, the Directory Service might not be implemented intime to do that initially. This would delay use of the Directory Service by the Securityarchitecture. Given the principle to use industry standard solutions when feasible, availabilityof products and features may also affect the timing of that use. The Directory Service willneed to take the initiative to provide support for Security and make known when it is readyand able to do so.10.3 Next Steps Update Emorys Information Access Policy and adopt a classification scheme based onthe proposed Information and Resource Access Policy and the proposed Informationand Resource Access Classification Guidelines dated January 2001. Create an asset database. See if adding columns to the Help Desk database could dothis. Begin opportunistic classification: Whenever a resource receives enterprise attention,especially security-related attention, seek to get it classified and put in the assetITA Version 1.9.8 2000 Emory University Page 1 40. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 2002 database. In particular, make classification part of implementing the web server accesscontrol service. Install border firewall(s) to complete the creation of the Public zone for the Universityacademic network. Install a virus scanning service for e-mail entering and leaving the University academicnetwork. Implement other trusted network zones. Provide intrusion detection and proactive scanning. Define requirements to be certified as trusted within each zone. Relocate classified network resources into corresponding zones. ITA Version 1.9.8 2000 Emory University Page 2 41. An IT Architecture for Emory University Adopted by CIRT Security Domain Architecture February 20, 200211. Glossary TermDefinition accessThe ability to do something with a resource (such as use, change, view). access controlEnforcement of authorization. The means by which access is explicitly enabled or restricted in some way (usually through physical and system-based controls). API Application Programming Interface. A defined way for a software routine to call upon another software routine, give it the information it needs and obtain a result. assessIn the context of security, it is chiefly concerned with evaluating the security of a resource by judging its risks, determining how well security policy is being followed, and reviewing the effectiveness of countermeasures. asset A resource worth protecting. audit v.t. Review an activity after the fact to make recommendations for changes to ensure compliance with guidelines or policy. In this context it is chiefly concerned wit