Designing Security Architecture Solutions phần 8 ppsx

■■ Allow the packet through. ■■ Drop the packet with no response to the sender. ■■ Drop the packet but send an ICMP host unreachable message back to the client. ■■ Allow the packet through after setting up special conditions for monitoring the conversation that it is part of, with the intent of changing behavior dynamically on any suspicious activity. Solutions that combine firewalls with IDS sensors can achieve additional levels of secu- rity. The firewall enforces policy while the IDS measures attacks aimed at the firewall (if the sensor is in front of the firewall) or measures our success in thwarting attacks according to policy (if placed behind the firewall). Firewall Configurations Firewalls are very versatile and can appear as any of the four channel patterns intro- duced in Chapter 4, “Architecture Patterns in Security.” ■■ Packet filters make decisions to allow or deny traffic based on the contents of the packet header; for example, the source or destination IP address, the port numbers used, or the protocol. Some packet filters maintain a notion of connection state or can assemble fragmented packets. ■■ Personal firewalls, or host-based software firewalls, protect a single host from any attacks on its network interface. PC firewalls such as Tiny Personal Firewall, Zone Alarm, Norton Personal Firewall, or tcpwrapper (which we argued, in Chapter 4, could also be considered a filter from a different perspective because of granularity of access protection) all wrap a single host. ■■ Secure gateways intercept all conversations between a client network adaptor and the gateway, building an encrypted tunnel to protect data traveling over the open Internet. Once the data reaches the internal network, it travels in the clear. ■■ Application proxies can perform elaborate logging and access control on the firewall because they can reassemble fragmented packets and pass them up the application stack to a proxy version of the service. The proxy version prevents external communications from directly accessing the internal service. We can perform high-level inspections of the contents of the communication because we have knowledge of the application on either endpoint. Application proxies can support complex security policy, but they are slower than packet filters. Firewall Limitations Firewalls have some limitations. A firewall cannot perform the following actions: ■■ Protect applications from traffic that does not go across it. If your network routes traffic around a firewall, perhaps through a dial-up modem or a dual homed host linked to an insecure network, all hosts on the network are vulnerable to attack. ■■ Protect you if the firewall is misconfigured. Security Components 307 ■■ Play the role of a general-purpose host and remain secure. A firewall cannot support arbitrary and possibly unsafe services and still enforce security policy. ■■ Protect against attackers already inside the network. ■■ Protect against traffic that is not visible; for example, encrypted data riding on a permitted protocol or a covert tunnel using a permitted protocol as a wrapper for a forbidden protocol. ■■ Inspect general data content for all dangerous payloads. There are too many attacks, and each attack can be modified to defeat the signature match used by the firewall. Firewalls can range from expensive specialized security components with complex configurations to free personal firewalls and cheap network appliances that perform Network Address Translation (NAT), DHCP, filtering, and connection management. We do not recommend putting business logic on security components such as firewalls. This procedure is a bad idea because firewalls are normally not under your control, and they might require out-of-band management procedures, might have implementation errors, and might have a very specific network infrastructure purpose that is at odds with your application. Firewalls represent single points of failure in the architecture, and because all of our applications share a dependency on one firewall, we must engi- neer the availability, scalability, and performance of the firewall to adequately address the application’s needs of today and of the future. Intrusion Detection Systems Network intrusion detection systems identify threats launched against an organization and respond to these threats by notifying an intrusion analyst, logging the attack to a database, or possibly reconfiguring the network automatically to prevent the attack from succeeding. The risk of a network intrusion cannot be evaluated in a vacuum; we must place the attack in the context of the host under attack, its operating system, net- work defenses, and vulnerabilities — along with the potential cost if the attack suc- ceeds. We refer the reader to Northcutt and Novak’s excellent introduction to intrusion detection and analysis, [NN00] for more information. Network detection tools analyze network traffic for patterns of behavior that appear suspicious. Because traffic volumes can overwhelm the pattern-matching abilities of our analytic tools, we might have to filter our traffic to extract packets that conform to some prerequisite form or property. We could choose to examine traffic by protocol, TCP flags, payload sizes, source or destination address, or port number. Attackers can modify traffic in many interesting ways. They could fragment packets excessively, spoof source IP address and port information, use ICMP messages to surreptitiously scan the network or redirect traffic, use several hosts simultaneously to launch a DDOS attack, or build a covert tunnel inside a permitted protocol or service. An intrusion detection system can examine traffic at many levels of granularity, from low-level mod- HIGH-LEVEL ARCHITECTURE 308 ifications of physical layer information to high-level application analysis of reassem- bled packets from fragments using knowledge of the syntax of the data (for example, recognizing a command to delete all files on a UNIX host). Systems can come with a predefined filter and signature set installed or can provide full programming support for custom signature definition. IDS configuration requires us to be very knowledgeable about networking protocols used to get a good idea of what normal traffic looks like. Intrusion analysts must be able to separate false positives (which are nonattacks reported by the IDS) from actual attacks. Tools such as tcpdump can filter and capture IP packets for analysis and help us create signatures for attacks. A packet might depart from the standard IP network- ing protocol definitions in some particular way. It could be: ■■ Deliberately malformed in order to fingerprint a target OS (perhaps by sending an unsolicited FIN packet to an open port or by setting and sending bogus TCP flag values in bad packets to look at the response from the host). ■■ Designed to perform network reconnaissance on available services. ■■ Designed to deny service; for example, through a land attack (an IP datagram with the same source and destination IP address; if a sensor encounters such a packet, it can issue an alarm because this action definitely signifies anomalous activity). ■■ Part of an attempt to hijack an established connection. Broadly speaking, intrusion detection solutions are composed of several components. Sensors. Sensors detect attacks by matching network traffic against a database of known intrusion signatures. Intrusion detection sensors attempt to operate at network bandwidth rates and send alarms to managers. Sensors sometimes store compiled rules and signature definitions for quicker pattern matching against traffic as it flies by. Some sensors listen in promiscuous mode, picking up all packets on the network; others work in tandem with a partner system or a router to target traffic aimed at that particular host or device. Managers. Managers merge event and alarm notifications from many sensors deployed across the network and manage sensor configuration and intrusion response. Databases. Managers often store event data in (possibly proprietary) databases for later analysis by using sophisticated tools. Consoles. Analysts can access event data from the console to generate statistical reports, order events by criticality, drill down into low-level detail of packet contents, or execute commands to respond to an intrusion. Reporting and analysis. Although network intrusion detection is often described as real time, this situation is rarely the case. In addition to crisis management functions, in the event of an intrusion we also need tools for offline reporting and analysis. These activities are critical for understanding the behavior of the network. Security Components 309 Network intrusion detection (NID) and analysis is still largely an art form. An applica- tion must consider many factors before deploying an NID system. Project expertise in intrusion detection. Most applications lack the expertise to deploy and monitor IDS on a day-to-day basis (installing one and forgetting its existence is another matter). In this situation, it is probably best not to depend on intrusion detection systems at all. Note that we are not saying that intrusion detection systems are bad, but if your primary role is that of a systems architect and you lack the relevant expertise, you should not depend on one to keep you secure. Intrusion detection systems belong in the network infrastructure category and can create too many false positives to be stable for integrating into your architecture. Find out what corporate firewalls and IDS policy recommend, and then hire an expert to install and configure a commercial network ID solution. Also, budget the resources to maintain the system and train an analyst in production for the day-to- day incident analysis and response. Sensor placement. Sensors cannot generate alarms on traffic they will not see. Sensors are often placed at network chokepoints or at the junction of two separate corporate networks with different patterns of usage (for example, research and development versus an integrated testing network). Sensors can be placed inside or outside the corporate firewall on the connection to the open Internet. As we mentioned, this firewall can actually be a combination of two firewalls—one on each side of the corporate router—or this firewall could have multiple interfaces to partner networks, a DMZ, or the secure corporate network. One rule of thumb for sensor placement in complicated scenarios is interface-sensor pairing, where each network places a sensor on the inside of its interface to the firewall and installs filters and signatures that validate the firewall’s policy for incoming traffic to their particular network. The managers and IDS databases normally will reside on the secure corporate network for safety. Sensor performance. Sensors might be unable to process all the packets received without dropping a large percentage. Standalone or host-based sensors. Sensors can be special hardware devices, supporting multiple network interfaces, strong security, and easy remote management of signatures and filters. Alternatively, sensors can be host-based software products that inspect traffic on all network interfaces on the host before passing these on to the relevant application. A standalone sensor might represent a single point of failure and could possibly be knocked off the network through a denial-of-service attack without our knowledge. In the latter case, in exchange for a performance penalty, we are ensured that we have seen all traffic to our host and can protect the sensor itself from being brought down by using automatic process restarts. We might have fewer interoperability and portability issues with bump-in- the-wire sensors because they are relatively isolated from our application. Networking protocols and host architectures. Heterogeneous host and network environments create overlapping areas of signature coverage. Some hosts are vulnerable to some form of attack, some network protocols have very different data formats, or sensors might not keep up with the evolution of the underlying communications layer. HIGH-LEVEL ARCHITECTURE 310 TEAMFLY Team-Fly ® Lookup attacks. Rather than directly attacking a host, a hacker might target naming services used by the host for matching an IP address to a host name, an object reference to an object name, or a hardware address to an IP address. Broken name mappings can cause denial of service. Tuning levels of false positives and negatives. The system administrator and intrusion analyst must improve the signal to noise ratio on the console. Otherwise, system administrators will abandon intrusion analysis after the initial glow of installing and examining potential network intrusion events as it becomes increasingly difficult to wade through this information. Generating excessive alarms on nonevents while missing actual attacks is a common problem in many intrusion detection deployments. Skill level of the attacker. Attackers can foil intrusion detection systems in a number of ways. The attacker can learn the limitations of the intrusion detection sensor if the sensor and its alarm response to an attack are also visible. An attacker can choose intrusions that will not be detected by the sensor or can knock the sensor off the network to prevent it from pushing alarms correctly to the user. Attackers can mix multiple attacks to create complexity, thereby confusing the analyst. A patient attacker, by using data volumes under alarm thresholds, can slowly conduct a reconnaissance of the network. Incident analysis and response strategy. Once we decide what our policy at the perimeter of the corporation is, and we install our IDS in the field, we must also follow up on incident analysis and response. This process requires considerable commitment from the architect of the application. Unless you are designing a security system, an IDS might be beyond the application’s capability to maintain and manage. Network intrusion detection is best left to experts. We suggest that the application focus its architectural energies on all the other security mechanisms in this chapter and in previous chapters. Applications should conform to corporate guidelines for operating an intrusion detection solution, set aside resources to purchase and run a commercial IDS, make room on the host’s performance budget for a host-based solution, hire and train analysts, and outsource filter creation and updates. LDAP and X.500 Directories Directories store information that is read often by a large group of users but modified infrequently by a much smaller group of administrators. The X.500 standard defines a comprehensive and powerful framework for enterprise directories. This framework includes the following components: An information model. The basic entity in the directory is an entry. Entries are organized into hierarchies based on the directory schema. Each entry has a required objectClass type field and a collection of attribute-value(s) pairs. Each objectClass definition in X.500 lists the mandatory and optional attributes for an entry of that class. X.500 also supports inheritance. An objectClass inherits the mandatory and Security Components 311 optional attributes of its parent class in addition to its own attribute definitions. Each entry has a relative distinguished name (RDN) that identifies it within the space of all entries. The collection of all data entries is called the Directory Information Base (DIB). An object-naming model. The RDN of an entry identifies its position in the Directory Information Tree (DIT). We can find the entry by following a path formed from the name-value assertions in the RDN, from the root of the DIT to the entry. A functional model. The functional model describes the operations that Directory User Agents (DUAs) can perform upon Directory Service Agents (DSAs), which collectively store the DIB. The functional model has powerful scoping and filtering rules that allow the user to launch complex queries against the server. If the server cannot find an entry, it can pass the query on to another DSA or return an error to the user. A security model. Directories can use strong authentication services such as Kerberos or SSL, along with entry level ACLs, to control access to a particular element of the DIB. An access model. The Directory Access Protocol specifies the messaging formats, order of messages, return values, and exception handling needed to query the DIB. The DAP protocol supports a number of read, write, or access operations on the directory. It also supports a search option that can be quite slow. A distributed architecture model. X.500 defines a distributed architecture for reliability, scalability, availability, and location independence. Although the standard creates a single global namespace across the enterprise, each instance of a directory service agent can manage all local updates and modifications quickly. Directories share information through replication, which also provides load balancing and high availability. The schema and attributed definitions are flexible, allowing application extensions to the data definition in a structured manner. X.500 directories support a range of operations including read, list, search, modify, add, delete, bind, unbind, and abandon session. DAP uses the ASN.1 BER notation for mes- sage encodings. Although DAP is very powerful, applications may encounter difficulties in creating, securing, and extending responses using DAP. The ASN.1 syntax uses exten- sive data typing and formatting rules that blow up message sizes. In addition, on a DUA query the DSA may sometimes respond with a redirection to another DSA, rather than providing the required response, which might add to the complexity of the client. Lightweight Directory Access Protocol LDAP, specified in [RFC2251] by University of Michigan researchers Wahl, Howes, and Kille, implements a subset of the functional and operational models of DAP. LDAP sim- plifies encodings, reduces message size, removes operations that can be simulated by using sequences of simpler operations (such as list and read), and assumes greater responsibility in tracking down referrals to resource requests by users, responding with an error if unsuccessful in resolving the query. HIGH-LEVEL ARCHITECTURE 312 LDAP runs directly over the TCP/IP stack, opening up directory access to a huge popu- lation of clients and servers. LDAP not only simplifies the encoding schemes but mes- sages use less space on average compared to ASN.1 messages, which can be quite complex and heavy. LDAP also drops some service controls to speed up application ser- vice. LDAP implements query scoping (which defines the part of the DIT that will be searched) and filtering (which limits the entities searched in the query scope) differ- ently from DAP. Many directory vendors, including Oracle Internet Directory, Microsoft Active Direc- tory, iPlanet Directory Server, and Novell eDirectory, support LDAP. Architectural Issues Directories define user and resource hierarchies, assist domain-based user manage- ment, and provide distributed services such as naming, location, and security. Directories play a critical role in addressing security challenges in any enterprise. Deploying an enterprise directory has become such a specialized skill that companies often outsource the task to directory service providers, or call on heavy doses of con- sulting to accomplish the task. The structure of data in the organization drives the architecture. ■■ What kind of data will we put in the directory? Is the directory for e-commerce, network and systems administration, or user management? How do we define schema and attributes to store user information, resource descriptions, customer data, supplier catalogs, or systems administration information? ■■ Must we support multiple network domains? How do we partition our data across domains? Does each domain extend the global schema in some way? ■■ Will single-tier directory services suffice or must we create a multi-tier solution with a meta-directory at the root? ■■ What goes into the global catalog of all the subordinate directories? Is their relationship peer-to-peer or hierarchical? ■■ Is data replicated from masters to slaves, or do we continually synchronize peer directories? ■■ Are we using our vendor product directory to provide virtual access to information in relational databases? Virtual access is very hard to accomplish because we are mixing two philosophies of data organization. Directory data is read often and written rarely, and fast access is supported through extensive preprocessed indexing. Relational databases support a balanced mix of reads and writes and optimize SQL queries in a completely different manner. Can we ensure that response time for complex queries is adequate? ■■ How do we handle referrals? Can we handle queries from partner directories (possibly not under our control), and if so, how can we authenticate and authorize referred queries? Security Components 313 ■■ Does our data have additional structure? How does the vendor support XML? How does the vendor support other middleware or database products? ■■ Is integration easy? Does the vendor depart from open standards, and if so, how does this affect application interoperability, integration, and evolution? ■■ Are any security services built into the directory and meta-directory products? As directory vendors run away from the commoditization of directory services, they build feature-rich but noncompliant products. Architects can face interoperability issues, lack of bug fixes, poor performance, or unwanted increases in licensing costs. Unlike many of the other security components we present in this chapter, however, directories do hold a central role in enterprise security architecture. For further elabo- ration on the importance of data management for security, we refer the reader to Chapter 15, “Enterprise Security Architecture.” Kerberos The Kerberos Authentication Protocol, invented in the late 1980s at MIT, enables clients and servers to mutually authenticate and establish network connections. Kerberos secures resources in a distributed environment by allowing an authenticated client with a service ticket on one computer to access the resources on a server on another host without the expense of a third-party lookup. The Kerberos protocol is an established open IETF standard. Over the years, it has been subjected to considerable peer review of the published open source, and all defects in the original protocol have been closed. Kerberos has risen from a well-respected authentication standard to a leading security infrastructure component in recent years, after Microsoft announced that Windows 2000 and Microsoft Active Directory would support the protocol for authentication purposes within Windows Primary Domain Controllers (PDC). Kerberos comes in two flavors: a simpler version 4 that runs exclusively over TCP/IP and a more complex version 5 that is more flexible and extensible. In addition to functional enhancements, Kerberos V5 uses ASN.1 with the Basic Encoding Rules (BER) allowing optional, variable length, or placeholder fields. Microsoft has adopted Kerberos V5 as the primary network authentication scheme for Windows 2000 domains (with support for NT LAN Manager for backward compatibility with NT3.x–4.0 subdomains). Kerberos uses symmetric key cryptography to protect communications and authenti- cate users. Kerberos encrypts packets for confidentiality, ensures message integrity, and prevents unauthorized access by network sniffing adversaries. Kerberos vendors support common cryptographic algorithms such as DES and 3DES, and are adding sup- port for the new NIST standard for encryption, the Advanced Encryption Standard (AES). Kerberos introduces a trusted third party, the Key Distribution Center (KDC), to the architecture that mediates authentication by using a protocol based on the extended HIGH-LEVEL ARCHITECTURE 314 Needham-Schroeder protocol, assuming a notion of universal time. The KDC authenti- cates connection requests between client and server and grants the client privileges to resources on the server. Each client or principal has a secret password (a master key) known to the KDC. The KDC stores all the passwords of participating principals in an encrypted database. The KDC knows every principal’s secret key. If the KDC is compromised, we have lost security entirely. Applications should require high performance and availability from the KDC to prevent response delays or creation of a single point of failure. Although the Kerberos standard speaks of two services, the KDC in all implementations of Kerberos is a single process that provides both. Authentication Service. The authentication service issues session keys and ticket- granting tickets (TGT) for services requests to the KDC. Ticket-Granting Service. The ticket-granting service issues tickets that allow access to other services in its own domain or that allow referrals to be made to ticket- granting services in other trusted domains. When client Alice logs onto her workstation, the workstation sends an authentication request to the KDC. The KDC responds with the following items: ■■ A session key valid for the current login session ■■ A TGT, which contains the session key, the user name, an expiration time, all encrypted with the KDC master key Alice must present the TGT to the KDC every time she requests to communicate with server Bob. The TGT allows the KDC some measure of statelessness because it con- tains all the information needed for the KDC to help Alice set up a Kerberos transaction. Each Kerberos transaction consists of four messages, two between Alice and the KDC (a ticket granting service request and a ticket granting service reply), and two between Alice and Bob (an application request and an application reply). We refer the interested reader to [KPS95] for an excellent presentation of Mediated Authentication and the Kerberos V4 and V5 protocols for more details. In addition to the open source Kerberos release from MIT (http://web.mit.edu/ Kerberos/), several vendors offer commercial Kerberos authentication products and services, including CyberSafe (TrustBroker at www.cybersafe.com) and Microsoft (W2K security at www.microsoft.com /WINDOWS2000/techinfo/). Kerberos Components in Windows 2000 Windows 2000 implements the KDC as a domain service, using Active Directory as its account database along with additional information about security principals from the Global Catalog. Security Components 315 Windows 2000 has a multimaster architecture, where many domain controllers with identical replicated databases share load balancing and fault tolerant network adminis- tration services. Each domain controller has its own KDC and Active Directory service, and the domain controller’s Local Security Authority (LSA) starts both services auto- matically. Any domain controller can accept authentication requests and ticket-granting requests addressed to the domain’s KDC. Microsoft’s adoption of Kerberos within Windows 2000 is not without controversy. Although supporters of Kerberos are complimentary of Microsoft’s decision to include a reputable authentication protocol based on an open standard into their products, they are critical of Microsoft’s decision to add licensing restrictions to their authorization extensions of the Kerberos V5 protocol. Windows 2000 uses an optional authorization data field to store a Privilege Access Certificate (PAC), a token that enables the server to make access decisions based on the user’s Windows user group. Although the exten- sion itself is permitted by the protocol, Microsoft’s licensing restrict prevents third par- ties from building complete domain controllers that implement this authorization field. Therefore, providing networks services in a Windows environment would require a Microsoft domain controller. One motivation for this restriction could be the lesson learned from Samba. Samba is an example of the open source movement’s ability to replace commercial vendor products with free alternatives, seamlessly. The Samba software suite is a collection of programs that implements the Server Message Block (commonly abbreviated as SMB) protocol for UNIX systems. The SMB protocol is sometimes also referred to as the Common Internet File System (CIFS), LanManager, or NetBIOS protocol. At the heart of Samba is the smbd daemon, which provides file and print services to SMB clients, such as Win- dows 95/98, Windows NT, Windows for Workgroups or LAN Manager. Rather than run- ning a Windows file or print server, network administrators can provide the same service from a cheap Linux box using Samba. Microsoft insists that they are motivated by a concern for interoperability. Because of the central role Kerberos plays in the Windows 2000 architecture, Microsoft is con- cerned that deployments of their flagship product for managing enterprise networks of millions of objects describing the company’s users, groups, servers, printers, sites, cus- tomers, and partners, will fail because of incompatible domain management. Along with the Active Directory, and the policy database, Kerberos lies at the heart of Win- dows 2000’s goals of providing domain definition, resource description, efficient authentication, trust management, and reliable network administration. Allowing full implementations of competing domain controller products (especially free open source examples) may create interoperability woes that fragment the network across domains. The difficulty lies not in Kerberos interoperability, but in providing users of Kerberos realms under a non-Windows KDC access to services on a Windows 2000 domain. Users could authenticate to the Windows domain but, as their tickets would not contain the required PAC value in the authorization field, they may have no privileges. Microsoft has suggested workarounds to this problem that create a trust relationship between the two realms allowing one to manufacture PACs for the other for inclusion in tickets. For an interesting discussion of this issue, please see Andrew Conry-Murray’s article [Con01] along with the resources on Microsoft’s TechNet links. HIGH-LEVEL ARCHITECTURE 316 [...]... direct conflict with security architecture proposals Performance Security solutions add layers of authentication and access control to every operation Applications that use security service providers, trusted third Security and Other Architectural Goals 327 parties, or directories in the architecture see additional network delays because of local and network accesses introduced for security purposes Interoperability... Application architects designing security solutions for these systems must use common off-the-shelf components to absorb and contain some of this complexity There are many popular security components that we do not have the space to present in detail, for example security tools such as the following (and many others): ■ ■ tcpwrapper (ftp.porcupine.org/pub /security/ ) ■ ■ tripwire (www.tripwiresecurity.com/)... different architectural goals and security We will then proceed to classify our non-functional goals into three categories to discuss the affects of security architecture on each ■ ■ Complementary goals, which support security ■ ■ Orthogonal goals, which through careful design can be made independent of security ■ ■ Conflicting goals, which are inherently opposed to security 323 324 H IGH-LEVE L ARC... practices create reusable designs and architectures and create a shared and common vocabulary for entities across many applications within a single business domain Security Issues For the most part, ease of use and security do not conflict with one another The two main points of contention are ease of security management and SSSO Security Management Administering security in a heterogeneous environment... chapter, we will discuss the conflicts faced by a security architect from the vantage point of the goal targeted, rather than the component used to achieve security This discussion sets the stage for our concluding chapters on the other challenges faced by the application architect, namely security management and security business cases 14 CHAPTER Security and Other Architectural Goals I n this chapter,... differences between security and our other application goals Force Diagrams around Security Force diagrams are a simple means of expressing a snapshot of the current state of an application Force diagrams pick one particular architectural goal (in our case, security) and map the tensions between this goal and other non-functional goals Our main goal, security, pulls the system architecture in one direction... supporting millions of objects [CBP99] Scalability makes security administration cleaner Interoperability Interoperability has been the central theme of several of our technical chapters: Chapter 8, “Secure Communication,” Chapter 9, “Middleware Security, ” and Chapter 11, “Application and OS Security. ” Please refer to our discussion of two areas of security related interoperability issues in these chapters... it pays some attention to conflicts with security but not in an optimal manner Note that the reference goal of security appears on the arrow to the left, denoting its special status Complementary Goals The goals of high availability, robustness, and auditing support our reference system goal of security High availability Robustness Reconstruction of events Security Orthogonal goals High availability—and... full range of DCE services, including authenticated RPC, single sign-on, naming, location, and security, or can use a minimal subset of services, for example, only implementing authentication using the DCE generic security services API All the DCE services make use of the security service DCE’s underlying security mechanism is the Kerberos network authentication service from Project Athena at the Massachusetts... use, adaptability, and evolution as goals that are largely independent of security within the application H IGH-LEVE L ARC H ITECTU RE High availability Robustness Reconstruction of events Orthogonal goals 3 28 Ease of use Adaptability Evolution Scalability Interoperability Maintainability Performance Portability System Architecture Security Opposed goals Figure 14.2 Good tensions in an application Conflicting . direct conflict with security architecture proposals. Performance. Security solutions add layers of authentication and access control to every operation. Applications that use security service providers,. powerful and flexible security component, easy added to any security architecture. Operational complexity and performance are the major architectural issues. The Distributed Sandbox Security is a disabling. interconnections. Application architects designing security solutions for these systems must use common off-the-shelf components to absorb and contain some of this complexity. There are many popular security components