Published on

  • Be the first to comment

  • Be the first to like this


  1. 1. SECURITY ARCHITECTURES “We have no future because our present is too volatile. We have only risk management. The spinning of the given moment’s scenarios. Pattern recognition...” -William Gibson “Pattern Recognition” Context New software system paradigms demand that information security keep pace with the chang- ing software landscape. With Web Services and Service Oriented Architectures (SOA), software de- velopment is in the third phase of an evolution that began with object oriented programming and progressed to component based program- ming. In object oriented and component based programming, security designers could rely on common languages, security models, and tech- nologies in a distributed system to secure both the clients’ and servers’ transactions and end- points. For example, EJB clients and servers can Service Oriented assume and use a common J2EE security stan- dard for authentication and authorization for Security Architecture both its client and server. However, in Web Ser- vices and Service Oriented Architecture, systems are loosely coupled. Clients and servers may be written in different languages and running on Gunnar Peterson disparate operating systems. Service Oriented Architecture agree upon interface and data Arctec Group schema, but the implementations may vary from client to server, and services may be chained cre- ating a peer to peer model. As programming models and implementations change, the secu- rity assumptions and designs must be refreshed and updated to manage the emerging threats that result from new architectures. Problem Statement The primary security mechanisms deployed to- day rely on notions of perimeters and central- ized security models. However, the nature of business is moving rapidly towards decentral- ized “intertwingled-ness” (non-hierarchical con- nectivity) and perimeters are eroding. Central- ized security systems do not apply in SOA’s de- centralized peer to peer architecture. Security design assumptions based on outmoded technol- ogy create brittle and ineffective systems when deployed in a SOA paradigm. Malicious attack- ers exploit the seams left between the existing security mechanisms deployed based on out- moded assumptions and the reality of the threats to the connected systems on the ground. Solution In keeping with the design spirit of SOA, the way forward in software security architecture is viewing security as service that is decoupled and composeable. Service Oriented Security (SOS) ar- chitecture does not solely focus on perimeters, but rather provides a framework to analyze and manage risk to the system’s assets, such as data, services, and identities. SOS and its architectural Information Security Bulletin, November 2005 Volume 10, Page 325 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission
  2. 2. SECURITY ARCHITECTURES - Deployment View: deals with the defense in depth 5 layer model: physical, network, host, ap- Message plication, and data Identity - Transaction Use Case Life Cycle View: deals with the key behavioral flows and relationships in a Transaction system and its actors from an end-to-end per- Use Case spective Life Cycle Each of the individual views is composed of do- main specific elements, constraints, threats, risks, Deployment vulnerabilities, and countermeasures. Each view Service also includes a set of key architectural patterns and principles. By partitioning concerns security designers are able to first decouple concerns to Figure 1 - Service Oriented Security Views analyze security domains and analyze tradeoffs and dependencies among the domains. The re- views provide a framework for reasoning about sultant architecture takes the concerns from each software security in a service oriented system. domain into account and provides holistic solu- This framework can be used by security archi- tions based on the risk management of digital as- tects to harmonize designs across infrastructure, sets like identities and data. The following sec- applications, and data based on business risk. tions examine each SOS viewpoint in more de- Service Oriented Security Architecture provides tail and provide an example usage. a set of views that can be used in a larger enter- prise security architecture, such as SABSA [7]. In Architecting with the SOS Views a SABSA model, the five main Service Oriented Software security architecture is an iterative pro- Security architecture views detail the Conceptual cess that includes decomposing complex prob- and Logical Security Views. lem spaces, drilling down on granular details to gain traction in a domain; and then synthesizing across domains, building up design views, iden- Service Oriented Security tifying relationship vectors that illustrate the sys- Architecture Overview tem’s security design goals. Each SOS View con- In software architecture, the word “security” can tains the following constituents: often do more harm than good. Frequently, stakeholders have differing, conflicting, and - Elements: describe the key components in the overloaded definitions of the term. In order to system and their logical organization including build a coherent system, the architects must pro- the subjects and objects that the view interacts vide specific guidance to the development and with operational teams. Service Oriented Security - Constraints: show the business, political, legal, (SOS) Architecture provides a set of software ar- and technical constraints for the view chitecture viewpoints that allow security archi- tects to construct a holistic system design based - Risk Model: illustrates the threats, assets, vul- on a set of views. No single view is sufficient to nerabilities, and countermeasures in the view. analyze and understand the system’s security as Conduct architectural risk analysis to manage a whole. The combination of the SOS views and risks [8] their relationships demonstrate the security deci- sions and design. Since security is not a zero - Relationships: conveys the nature and direction sum game, the views provide a framework in of the views’ relationships with other views which to conduct security architecture tradeoff The chief utility of separation of concerns in SOS analysis and to convey design decisions to devel- is that each of the views’ elements, constraints, opment and operational staff. As Kruchten ob- risk models, and relationships are unique and served [1], views enable the software architect to decoupled inside their view. The design deci- separate concerns in a complex system. The sions made about securing the elements will im- views in Service Oriented Security consist of the pact other views, but separating the concerns al- following: lows for decoupling the concerns and handling the domain specific risks. - Identity View: deals with the generation, com- munication, recognition, negotiation, and Identity View transformation of identity Using Kim Cameron’s definition we will exam- ine identity as “a set of claims made by one digi- - Service View: deals with the service, its meth- tal subject about itself or another digital subject." ods and component parts [2. This definition rewards careful study because it reveals that identity is not a passive entity, but - Message View: deals with the service’s message rather the result of an active set of processes that payload can be judged against a dynamic set of criteria. Volume 10, Page 326 Information Security Bulletin, November 2005 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission
  3. 3. SECURITY ARCHITECTURES When identity is defined as a set of claims, each service can decide what claims it will accept and from what SecurityDomain SecurityDomain authorities. App Federation Key elements of the Identity View include: App/Resources - Authentication mecha- Betsy nisms, events, and princi- User Store Red Green pals including Kerberos Fed Fed tickets, X.509, Windows Server Server sessions, and web server sessions - Identity Federations in- cluding the portable, Figure 2 - Using Identity Federation strong identities like SAML, Liberty, and WS- anywhere a digital subject is mapped, con- Federation identities sumed, stored, and transformed. The Identity - Monitoring and audit systems: provide trace- View has relationships with the other SOS ability of identity-related events like authenti- Views. The Identity View provides information cation about subjects to the other SOS Views, other views both consume and query principal data - Identity domain-specific attributes provided by the processes generated by Identity View elements. Due to its criticality as a founda- Identity is a fundamental element in access con- tion element for other views, the elements in the trol decisions, hence the protocols that generate, Identity View should be hardened using the communicate and negotiate identity information strongest security controls that are reasonably require security analysis to ensure a robust possible for all the states of the system that the system. identity is in. Identity information is a very valuable asset to attackers and so systems designers must design Service View its implementation and usage to withstand a va- The Service provides the interface to the rest of riety of attacks. Phishing attacks that continue to the system and brokers the identity, messages, grow in distribution and sophistication are just and transactional data. The Service View is con- one example of attacks that exploit weak identity cerned with the risks around the service and the systems [3]. Privacy, regulatory, and legal do- service’s ability to broker information flows with mains all impose constraints on identity imple- requisite confidentiality, integrity, and availabil- mentations and what information may be shared ity. Services require access control protection and and used by parties. Identity information may may consume identity and domain attribute in- “leak” inadvertently to other systems and users formation from other domains, so the service can that are not allowed to access the information. typically make a minimum of assumptions about what it receives. From a detection and response Identity View Pattern: Federated Identity standpoint, services require logging mechanisms to vouch for the health of the system. Standard - Context: Security domains Red and Green want technology specific service hardening and secu- to integrate disparate systems with unique pol- rity guidelines apply in the services view, such icies and management. The systems have dis- as the OWASP guidelines for Web Applications. parate identity repositories, operating systems, and application languages, but want to ex- Key elements of the Service View include: change XML documents for order processing - Application Servers and Services: such as data- - Problem: User credentials must be securely bases, web servers, and web services ported across domains and security informa- tion must be recognizable to both parties - Logging Services - Solution: Use federated identity for access con- - Integrity Services trol. Red Client (Alice) logs onto local Red sys- tem, generates/sends encrypted SAML token Service risks include denial of service, forcing ex- with app request to the Green Service. Green ception conditions, attacks against validation sys- server validates assertions for access rights. tems, attacks against program and service logic. Since services are an endpoint for incoming re- Federation is one example of a service in the quests, they must broker access and data flows identity view. Many other will come into play in between the domains with disparate security a system, including access control mechanisms, models. Information Security Bulletin, November 2005 Volume 10, Page 327 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission
  4. 4. SECURITY ARCHITECTURES Message View Pattern: WS-Security Manufacturer Supplier Web Context: data is in- SOAP App Server Data- creasingly shared Web Service Service SPI base across technological and policy bound- Filters and Analyses Data aries. The technology Figure 3 - Security Pipeline Interface Provides Data Integrity and Logging stack is unpredict- able in SOA systems, Service View Pattern: Security Pipeline Interface hence command and control security systems do not apply. - Context: host must mediate activity between remote client system and back end resources Problem: message must be protected beyond the span of control of the service and systems, since - Problem: host system cannot trust incoming re- it can traverse multiple domains. How does the quests and data principle of complete mediation [5] apply in a “fire and forget” service oriented world? - Solution: Use Security Pipeline Interface (SPI) [4] to enforce the principle of Separation of Privi- Solution: Use WS-Security standard to sign and lege [Saltzer75] and reduce risk of data integ- encrypt persistent XML documents. WS-Security rity threats. Run SPI in separate physical, pro- uses XML Encryption and XML Signature, and cess and memory space from business logic can accept tokens such as SAML, Kerberos, and aware services. Execute logging of access con- X.509 to provide assurance through authentica- trol and related security event at the SPI. tion, authorization, and validation Message View Deployment Environment View Information security is concerned with protect- The Deployment Environment view is focused ing valuable digital assets, in many cases the on the classic information security Defense in most valuable assets from a risk management Depth layers: perspective is not network access, but rather the company’s data. As distributed systems continue - Physical: such as guards and locks to evolve and become more connected to each - Network: such as firewalls, IDS other in ways not foreseen by their original de- signers, such as decades old legacy systems be- - Host: such as HIDS, Host Integrity Monitoring ing connected to the web, data and messages and server hardening emerge in ways not intended when their protec- tion mechanisms were implemented. The net re- - Application: such as Input Validation, logging sult of this evolution is to move security mecha- systems nisms closer to the asset level, in this case the - Data: such as database hardening, and data data elements. Encryption and related technol- level access controls ogy standards are used to constrain access to persistent data while it is at rest and ensure The Deployment Environment view is where the integrity and auditability over its life cycle. lions share of IT security resources are deployed currently. The patterns in place in the Deploy- Key elements in the Message View include: ment Environment are more mature than those - Message Payload: typically a XML document in the emerging SOA-centric views like Identity, and related schema information Message, and Service views. The risks that are present in the defense in depth layers currently - Interface Information: for example WSDL in Web must be baselined against the SOA applications Services that are deployed on these foundations. - Security Tokens: such as digital signature infor- Deployment Environment View Anti-Patterns: mation and cryptographic keys Trusted Versus Untrusted Considered Harmful Risks in the Message view include attacks - Do not architect using dualistic concepts like against data at rest and in transit. Since data “trusted versus untrusted”. Deperimeterization flows in service oriented systems cannot be pre- renders these definitions meaningless. Instead dicted in an end to end sense with a high degree focus on layers of verification based on avail- of confidence, encryption is a primary consider- able protection, detection, and response mech- ation for protecting messages as it traverses a anisms. host of states, and security domains. As with us- Additional Deployment Environment View Pat- ing PGP for email security, encrypting the mes- terns: sage payload provides fine grained protection even without the designer’s knowing the precise - Use Honeypots for understanding the actual details of the system that the message will threat profile on the ground of each domain to traverse. vet trust zone assumptions. Develop metrics Volume 10, Page 328 Information Security Bulletin, November 2005 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission
  5. 5. SECURITY ARCHITECTURES and reporting to feed forward into future secu- ship outcome changes the base flow of the Use rity designs. Case. In the case of including an access control Use Case like Authenticate User, the outcome - Utilize security metrics across layers to develop of this (usually boolean pass/fail) directly a scoring system and track performance over changes the behaviors of the related use case. time for decision support The extends relationship does not alter behav- ior of the preceding use case, so if a use case Transaction Use Case Life cycle View extends to a monitor event use case and that Use Cases are used to show the end-to-end view monitor server is down, it may not make sense of the system. Use cases provide a synthetic to alter the flow of the preceding Use Case. model that correlates requirements from differ- ent domains’ concerns into a coherent model - Mapping Use Cases to Threat Models: Security and flow. Use Case models contain many prop- cannot only focus on functional requirements, erties that are critical to secure system design: but must also consider the attacker viewpoint. Threat modelling and abuse cases are tech- - Stakeholders: In Information Security, it pays to niques used in the development life cycle to find allies who have a vested interest in sys- map possible threats, vulnerabilities, and im- tem security. Stakeholders who may be con- pacts onto the system so that appropriate secu- cerned about security implications in the sys- rity countermeasures can be built into the sys- tem that is being built include not just the core tem. The Use Case model allows the Threat development staff, but also the legal staff, busi- Model to refer to functions in a context-sensi- ness owners, domain experts, operational staff, tive manner. customers, shareholders, and users. - Pre and Post Conditions: Pre and post conditions Brokering Relationships describe the set conditions that must be satis- To facilitate communication across views and se- fied for the Use Case to execute (Pre-condi- curity domains, a common mechanism is needed tions) and the set of states that the system can to generically create, validate, and exchange se- be in after it has completed (Post-conditions). curity information. WS-Trust provides a stan- Pre-conditions allow the Information Security dard framework for request/response communi- team to articulate the security conditions, such cation for a variety of security tokens including as authentication and authorization processes SAML, Kerberos, and X.509. Integration patterns that must be completed before accessing the of these relationships can be distilled from the Use Case functionality so that developers have Use Cases. The directionality of the relationship a consistent spec to build from. and the nature of the relationships (includes ver- sus extends) shows how the system must be - Exceptional and Alternate Flows: A fundamental built to satisfy security and privacy requirements principle in security design is to design for fail- across domains. ure. Development projects are mainly focused on base flows of the system since these imple- ment business valuable features. However Architecture Issues from a security standpoint, exceptional and al- The SOS views describe a way of seeing security ternate flows highlight paths that often be- architecture across a complex system to make come attack vectors. These flows are worth ex- and convey security design decisions. The soft- amination by Information Security to ensure ware security space contains issues that are still that the system is designed to deal with these being worked to achieve optimal effectiveness. exceptions and has deployed security mecha- nisms such as audit logs and IDS tools to catch security exceptions when they occur. XML Security Research has shown various flaws with XML Se- - Actors: Actors can include computer systems, curity [6] related to its reliance on XML for en- users, and other resources like schedulers. By cryption and signature as well as replicating a analyzing the actors involved in the Use Case number of problems in legacy technologies. model, the Information Security team can be- Since a large number of emerging security solu- gin to build a picture of the access control tions, particularly WS-* rely on XML security structures such as roles and groups that may mechanisms it is worth revisiting this depend- be required for design as the system is built. ency to see if XMPP or other technology can Where delegation or impersonation is used, ac- remedy these issues. tors can identify where this is accomplished and what actors are mapped onto other actors at runtime. Emerging Toolsets and Standards The software security space is evolving at a rapid - Relationships: Much of the power in the Use pace; investment paths are not clear in a long Case model comes from its simplicity. Use term sense. Deploying resources based on to- Case models feature two types of relation- day’s assumptions about standards, for example ships: includes and extends. These have direct SAML vs. WS-*, implementation, and threat security implications, in the includes relation- models inserts a higher degree of variability into Information Security Bulletin, November 2005 Volume 10, Page 329 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission
  6. 6. SECURITY ARCHITECTURES the system’s longevity based on the outcomes of [7] the technical and standards challenges. [8] Steven Lavenhar and Gunnar Peterson, Ar- Changing Threat Landscape: chitectural Risk Analysis, Cigital Copyright Attacker Co-Evolution 2005 As with any security design, the opponent is homo sapiens meaning that the opponent is ever adaptable and resourceful. As security designs article/bestpractices/ become more robust, then business deploy more architectural_risk_analysis/ resources and transactions to the online world, architectural_risk_assessment.xml thus attracting more attackers. References About the Author [1] Philippe Kruchten, Architectural Blueprints – Mr. Peterson is CTO of Arctec Group, a consult- The “4+1” View Model of Software Architecture, ing firm focused on building strategic technology IEEE Software, 1995 blueprints for its clients. [2] Kim Cameron, What is a digital identity?, 2005 He has served organizations as a Software Archi- 07.html#a152 tecture consultant for distributed systems includ- ing smart card, databases, middleware, messa- [3] Anti-Phishing Working Group, Phishing Ac- ging, application layer, embedded systems, and tivity Trends Report, June, 2005 commercial packages. Mr. Peterson has provided consulting services on software security design, _Activity_Report_Jun_05.pdf process, and training to some of the largest fi- nancial systems, financial exchanges, manufac- [4] Security Pipeline Interface”, Hoffman and turing, and healthcare organizations and sys- Davis, Proceedings of the Sixth Annual Com- tems. puter Security Applications Conference, 1990 [5] Saltzer and Schroeder, The Protection of Infor- Mr. Peterson has presented on software security mation in Computer Systems, Proceedings of topics for numerous conferences and organiza- the IEEE, 1975) tions, including ISSA, Black Hat, OWASP, and [6] Peter Gutmann, Why XML Security is Broken, SANS. He has published papers on the Dept 2005 Homeland Security portal: Build Security In on Identity Architecture and on Architectural Risk Assessment. Mr. Peterson is an associate editor pubs/xmlsec.txt of Information Security Bulletin. There is only one way to get all issues of Information Security Bulletin: SUBSCRIBING! Please use the form in the journal, or visit Volume 10, Page 330 Information Security Bulletin, November 2005 Copyright ©2005 CHI Publishing Ltd - All rights reserved - Do not copy without written permission