IBM Security Architecture


Published on

Published in: Technology, Business
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • With current enterprise practices: High cost to operating the Control Layer Poor security from ineffective control layer High systems development costs
  • The Security Enforcement Service (SES) is the “services” view of the commonly used “Policy Enforcement Point”/”Access Enforcement Functionality” (PEP, AEF) defined by ISO. This service is responsible for enforcing the decisions made by the SDS and thus allowing/disallowing access to resources based on these decisions. The Security Decision Service (SDS) is the “services” view of the commonly used “Policy Decision Point”/”Access Decision Functionality” (PDP, ADF) defined by ISO. This service is responsible for making the access control decisions based on information provided by the SES. Typically these decisions are of the form “can user X access resource Y in manner Z”, which translates to examples such as “Can Joe Read File A?”. These decisions may be richer than described, including information such sa time of day, requestor’s IP address, or even the contents of the request (“Transfer $10,000 from an account with a balance of $200 INTO an account with a balance of $50).
  • Reality: IDC estimates that the average enterprise has 150+ directories Every application uses a directory, all are disparate, but have dependancies A SINGLE Enterprise LDAP directory is not a reality: Each application has its own varying degrees of proprietary/openess – externalization of attribues, sharing, etc. Dependancies among directories: employee/partner/customer information, passwords Authoritative sources – user profile is made up from various sources – HR, email, business apps Multiple organizations manage Varying levels of security requirements Desired Environment: A balanced federated directory model, managed under a common set of processes, tools and organizational governance Consolidate where possible, understand what directories and uses of directories, manage at appropriate level
  • Need an example that describes the “multiple Identity Issues” Imagine a world where every country issues Passports for every person visiting that country. That would be chaotic. Countries would end up administering passports for non-authoritative users.
  • Within a federation, organizations play one or both of two roles: identity provider and/or service provider . Identity Provider: The identity provider (IdP) is the authoritative site responsible for authenticating an end user and asserting an identity for that user in a trusted fashion to trusted partners. The identity provider is responsible for account creation, provisioning, password management, and general account management and also acts as a collection point or client to trusted identity providers. . Service Provider: Those partners who offer services but do not act as identity providers are known as service providers. The service provider (SP) relies on the IdP to assert information about a user, leaving the SP to manage only those user attributes that are relevant to the SP. Looking back at our earlier example of IBM and Hewitt: IBM would be the identity provider, they are asserting the identity of an IBM employee to Hewitt Hewitt would be the service provider. There service is the savings plan/401k management
  • Managing the SOA Security includes: Identity Services Authentication Services Consistent authorization across the infrastructure components (policy managed based on a single decision point implementing authorization across layers) Auditing & Compliance to security policy Trust/Map identities between various security sub-systems Confidentiality, Integrity and Availability Administration and Policy Management
  • The lock on the SOAP Message is meant to imply that the SOAP message is inherently secure in and of itself. The SOAP message can be transported in any way and its security is not affected. The SOAP message could be sent as an e-mail attachment, carried on a floppy-disk, etc, and the properties of privacy, integrity, proof of origin are not affected. In contrast, the security of a message that relies on transport security is exposed when that transport security has “gaps” – as would occur when multiple SSL hops are required to move the message from the origin to the ultimate receiver. The gaps in the transport security may or may not be an issue – depending on the trust assigned to the nodes that provide the transport compared to the trust required for the message.
  • The full title of the SOAP message security specification is “Web Services Security: SOAP Message Security 1.0”, and it can be found at This standard defines a set of SOAP extensions that provide the ability to: send security tokens as part of a message, include an XML Digital Signature as part of a message, encrypt all or part of the message using XML Encryption These elements can be used to achieve “message-based security” for a SOAP message. That is, the message in and of itself is tamper-proof and confidental. The origin of the message is provided by the Token Element. Any change to the message will cause the signature validation to fail so content integrity is provided. An observer of the message cannot read it if it is encrypted, providing message privacy. The Oasis page for Web Service Security in general is
  • NOTES: TRANSPORT LAYER/EDGE SECURITY This is an “optional” component. There will be pressure to use XML FW/GW as the transport layer edge termination (among other things, they do have slick acceleration capabilities). However, many customers will already have an edge termination component and won’t willingly give it up XML FW/GW (aka DataPower) While this can do message layer functionality, it typically won’t be able to handle any element level decryption (not allowed to, as opposed to not capable of). The component will typically “authenticate” based on the certificate that is included with the request and used as part of signature validation. This may well not represent the actual requestor (think sales clerk placing order versus outbound SOAP gateway at sales clerk’s company) ESB Additional tokens for identification and authentication can be handled within ESB (need as part of routing a message, user is gold/silver, for example, in addition to security type decisions, silver not authorized to request upgrades online) APPLICATION Receives requestor’s identity from ESB (eg asserted over TAI in a WAS environment) and uses this for local, application based authorization decisions Note that XML FW/GW, ESB will communicate with security services using WS-Trust, in the guise of token functionality (token validation mainly, but also the ability to extract an identity and map it appropriately for use by component) Application may use WS-Trust but this is a lot less likely (cause it means that App is getting a web services request and knows how to deal with it) but will often, through things like JACC providers, access third-party/external security services. Security services can provide all sorts of functionality. This is a “grab bag” box, to indicate that we typically want a consolidated provider/container for security policy, token functionality, key management, authorization, etc.
  • MASS – Method for Architecting Secure Solutions Based on Common Criteria requirements, terminology, a methodology for enumeration of security services applied to a given system architecture
  • IBM Security Architecture

    1. 1. Integrated Security Architecture James Andoniadis IBM Canada
    2. 2. CEO View: Increased Collaboration Brings Rewards
    3. 3. Layers of security <ul><li>Perimeter Defense </li></ul><ul><li>Keep out unwanted with </li></ul><ul><ul><li>Firewalls </li></ul></ul><ul><ul><li>Anti-Virus </li></ul></ul><ul><ul><li>Intrusion Detection, etc. </li></ul></ul><ul><li>Control Layer </li></ul><ul><ul><li>Which users can come in? </li></ul></ul><ul><ul><li>What can users see and do? </li></ul></ul><ul><ul><li>Are user preferences supported? </li></ul></ul><ul><ul><li>Can user privacy be protected? </li></ul></ul><ul><li>Assurance Layer </li></ul><ul><ul><li>Can I comply with regulations? </li></ul></ul><ul><ul><li>Can I deliver audit reports? </li></ul></ul><ul><ul><li>Am I at risk? </li></ul></ul><ul><ul><li>Can I respond to security events? </li></ul></ul>Perimeter Defense Control Layer Assurance Layer
    4. 4. Pre SOA Security: Enforcement & Decision Points Access Enforcement Functionality (AEF) Access Decision Functionality (ADF)
    5. 5. Directory Management View Web Single Sign On Messaging CRM/ ERP (PeopleSoft) Meta-Directory LDAP Directory Proxy External ePortal Web Access Control Network Access Control Customer Employee Transactional Web Presentation Informational Web Presentation Certificate Status Responder External Directory Transactional Web Integration External SMTP Gateway Internal SMTP Gateway Network Dispatcher Delegated User Management Internal ePortal, LDAP- enabled apps Single Sign On Application Access Control Network Authentication & Authorization Internal Directory LOB Applications Databases Application Directory Network Operating Systems Identity Management Certifcate Authority
    6. 6. Identity and Access Management Portfolio Identity Stores HR CRM, Partners <ul><li>Enterprise Directory </li></ul><ul><li>Personal Info </li></ul><ul><li>Credentials </li></ul><ul><li>Entitlements </li></ul>Apps/Email UNIX/Linux NOS Databases & Applications MF/Midrange Security Mgmt Objects ITIM: Provisioning <ul><li>Policies </li></ul><ul><li>Workflow </li></ul><ul><li>Password Self-service </li></ul><ul><li>Audit trails </li></ul>Web Applications ITFIM: Federated Identity Web Services Security Portal Presentation Personalization ITAM: Web Access Management SSO, Authentication, Authorization ITDI Directory Integration ITDS Directory Server TAM for ESSO
    7. 8. Governments as Identity Providers “ TRUST provides ACCESS” The United States is an “Identity Provider” because it issues a Passport as proof of identification USA Vouches for its Citizens Germany:Identity Provider USA:Identity Provider China:Identity Provider Users Users Users
    8. 9. Roles: Identity Provider and Service Provider 1. Issues Network / Login credentials 2. Handles User Administration/ ID Mgmt 3. Authenticates User 4. “Vouches” for the user’s identity Service Provider controls access to services Third-party user has access to services for the duration of the federation Only manages user attributes relevant to SP Identity Provider “ Vouching” party in transaction “ Validation” party in transaction Service Provider Mutual TRUST
    9. 10. Federated Identity Standards
    10. 11. Agenda <ul><li>Enterprise Security Architecture – MASS Intro </li></ul><ul><li>Identity, Access, and Federated Identity Management </li></ul><ul><li>SOA Security </li></ul>
    11. 12. SOA Security Encompass all Aspects of Security Custom Application Packaged Application Packaged Application Custom Application consumers business processes process choreography services atomic and composite Service Consumer Service Provider 1 1 2 2 3 3 4 4 5 5 OO Application Custom Application Outlook SAP Custom Application business processes process choreography Services (Definitions) atomic and composite Service components Service Consumer Service Provider 1 1 2 2 3 3 4 4 5 5 OO Application ISV Custom Apps Platform Operational systems Supporting Middleware MQ DB2 Unix OS/390 <ul><li>SOA Security </li></ul><ul><li>Identity </li></ul><ul><li>Authentication </li></ul><ul><li>Authorization </li></ul><ul><li>Confidentiality, Integrity </li></ul><ul><li>Availability </li></ul><ul><li>Auditing & Compliance </li></ul><ul><li>Administration and Policy Management </li></ul>SCA Portlet WSRP B2B Other
    12. 13. Message-based Security : End-to-End Security <ul><li>Message-based security does not rely on secure transport </li></ul><ul><ul><li>message itself is encrypted  message privacy </li></ul></ul><ul><ul><li>message itself is signed  message integrity </li></ul></ul><ul><ul><li>message contains user identity  proof of origin </li></ul></ul>HTTPS HTTPS SOAP Message Connection Integrity/Privacy Connection Integrity/Privacy ?
    13. 14. Web Service Security Specifications Roadmap WSS – SOAP Security Security Policy Secure Conversation Trust Federation Privacy Authorization SOAP Messaging
    14. 15. SOAP Message Security: Extensions to Header <ul><li>SOAP Header allows for extensions </li></ul><ul><li>OASIS standard “WS-Security: SOAP Message Security” </li></ul><ul><ul><li>defines XML for Tokens, Signatures and Encryption </li></ul></ul><ul><ul><li>defines how these elements are included in SOAP Header </li></ul></ul>Envelope Body Header <application data> Security Element Security Token Signature Encrypted Data Security Element
    15. 16. Security Drill Down <ul><li>Transport Layer Security </li></ul><ul><li>SSL/TLS Termination </li></ul><ul><li>1 st Layer Message Security </li></ul><ul><li>Signature Validation/ Origin Authentication </li></ul><ul><li>Message Level Decryption </li></ul><ul><li>2 nd Layer Message Security </li></ul><ul><li>Requestor Identification & Authentication & Mapping </li></ul><ul><li>Element Level Decryption </li></ul>Application Security (Authorization with ESB asserted identifier) Security Policy Security Token Service Key Store, Management Authorization <ul><li>N th Layer Message Security </li></ul><ul><li>Requestor Identification & Authentication & Mapping </li></ul><ul><li>Message Level Encryption </li></ul>
    16. 17. Moving to SOA – Accommodate Web Services SOAP HTTP
    17. 18. Moving to SOA – Accommodate Web Services SOAP Transport Layer Confidentiality Integrity Transport Layer Confidentiality Integrity HTTP User Interaction Based I&A Enforcement Identification & Authentication Decisions Token Based Authentication Enforcement Identity Mapping Message Layer Confidentiality Integrity
    18. 19. Moving to SOA, Adding the ESB… (Mandatory Scary Picture) Common Auditing & Reporting Service Tivoli Federated Identity Manager Tivoli Access Manager H/W: DataPower XS40 S/W: WebSphere Web Svs. G/W S/W: Tivoli Access Manager Reverse Proxy/Web PI Tivoli Directory Server WebSphere Enterprise Service Bus DP XI50 TFIM, TAM TFIM TFIM TFIM TAM TAM
    19. 20. Further Reading <ul><li>On Demand Operating Environment: Security Considerations in an Extended Enterprise </li></ul><ul><ul><li> </li></ul></ul><ul><li>Web Services Security Standards, Tutorials, Papers </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>Websphere Security Fundamentals / WAS 6.0 Security Handbook </li></ul><ul><ul><li> </li></ul></ul><ul><ul><li> </li></ul></ul><ul><li>IBM Tivoli Product Home Page </li></ul><ul><ul><li> </li></ul></ul>
    20. 21. Summary <ul><li>End-to-end Security Integration is complex </li></ul><ul><li>Web Services and SOA security are emerging areas </li></ul><ul><ul><li>Moving from session level security to message level security </li></ul></ul><ul><li>Identity Management incorporates several security services, but other security services need to be integrated as well </li></ul><ul><ul><li>Audit and Event Management, Compliance and Assurance </li></ul></ul><ul><ul><li>Etc. </li></ul></ul><ul><li>Security technology is part – process, policy, people are the others and often harder to change </li></ul><ul><li>Only Constant is Change, but evolve around the fundamentals </li></ul><ul><ul><li>Establish separation of application and security management </li></ul></ul><ul><ul><li>Use of open standards will help with integration of past and future technologies </li></ul></ul>
    21. 22. Questions?
    22. 23. Security 101 Definitions <ul><li>Authentication - Identify who you are </li></ul><ul><ul><li>Userid/password, PKI certificates, Kerberos, Tokens, Biometrics </li></ul></ul><ul><li>Authorization – What you can access </li></ul><ul><ul><li>Access Enforcement Function / Access Decision Function </li></ul></ul><ul><ul><li>Roles, Groups, Entitlements </li></ul></ul><ul><li>Administration – Applying security policy to resource protection </li></ul><ul><ul><li>Directories, administration interfaces, delegation, self-service </li></ul></ul><ul><li>Audit – Logging security success / failures </li></ul><ul><ul><li>Basis of monitoring, accountability/non-repudiation, investigation, forensics </li></ul></ul><ul><li>Assurance – Security integrity and compliance to policy </li></ul><ul><ul><li>Monitoring (Intrusion Detection, AntiVirus, Compliance), Vulnerability Testing </li></ul></ul><ul><li>Asset Protection </li></ul><ul><ul><li>Data Confidentiality, Integrity, Data Privacy </li></ul></ul><ul><li>Availability </li></ul><ul><ul><li>Backup/recovery, disaster recovery, high availability/redundance </li></ul></ul>
    23. 24. Agenda <ul><li>Enterprise Security Architecture – MASS Intro </li></ul><ul><li>Identity, Access, and Federated Identity Management </li></ul><ul><li>SOA Security </li></ul>
    24. 25. MASS – Processes for a Security Management Architecture
    25. 26. Access Control Subsystem <ul><li>Purpose: </li></ul><ul><li>Enforce security policies by gating access to, and execution of, processes and services within a computing solution via identification, authentication, and authorization processes, along with security mechanisms that use credentials and attributes. </li></ul><ul><li>Functions: </li></ul><ul><li>Access control monitoring and enforcement: Policy Enforcement Point/Policy Decision Point/ Policy Administration Point </li></ul><ul><li>Identification and authentication mechanisms, including verification of secrets, cryptography (encryption and signing), and single-use versus multiple-use authentication mechanisms </li></ul><ul><li>Authorization mechanisms, to include attributes, privileges, and permissions </li></ul><ul><li>Enforcement mechanisms, including failure handling, bypass prevention, banners, timing and timeout, event capture, and decision and logging components </li></ul><ul><li>Sample Technologies: </li></ul><ul><li>RACF, platform/application security, web access control </li></ul>
    26. 27. Identity and Credential Subsystem <ul><li>Purpose: </li></ul><ul><li>Generate, distribute, and manage the data objects that convey identity and permissions across networks and among the platforms, the processes, and the security subsystems within a computing solution. </li></ul><ul><li>Functions: </li></ul><ul><li>Single-use versus multiple-use mechanisms, either cryptographic or non-cryptographic </li></ul><ul><li>Generation and verification of secrets </li></ul><ul><li>Identities and credentials to be used in access control: identification, authentication, and access control for the purpose of user-subject binding </li></ul><ul><li>Credentials to be used for purposes of identity in legally binding transactions </li></ul><ul><li>Timing and duration of identification and authentication </li></ul><ul><li>Lifecycle of credentials </li></ul><ul><li>Anonymity and pseudonymity mechanisms </li></ul><ul><li>Sample Technologies: </li></ul><ul><li>Tokens (PKI, Kerberos, SAML), User registries (LDAP,AD,RACF,…), Administration consoles, Session management </li></ul>
    27. 28. Information Flow Control Subsystem <ul><li>Purpose: </li></ul><ul><li>Enforce security policies by gating the flow of information within a computing solution, affecting the visibility of information within a computing solution, and ensuring the integrity of information flowing within a computing solution. </li></ul><ul><li>Functions: </li></ul><ul><li>Flow permission or prevention </li></ul><ul><li>Flow monitoring and enforcement </li></ul><ul><li>Transfer services and environments: open or trusted channel, open or trusted path, media conversions, manual transfer, and import to or export between domain </li></ul><ul><li>Encryption </li></ul><ul><li>Storage mechanisms: cryptography and hardware security modules </li></ul><ul><li>Sample Technologies: </li></ul><ul><li>Firewalls, VPNs, SSL </li></ul>
    28. 29. Security Audit Subsystem <ul><li>Purpose: </li></ul><ul><li>Provide proof of compliance to the security policy. </li></ul><ul><li>Functions: </li></ul><ul><li>Collection of security audit data, including capture of the appropriate data, trusted transfer of audit data, and synchronization of chronologies </li></ul><ul><li>Protection of security audit data, including use of time stamps, signing events, and storage integrity to prevent loss of data </li></ul><ul><li>Analysis of security audit data, including review, anomaly detection, violation analysis, and attack analysis using simple heuristics or complex heuristics </li></ul><ul><li>Alarms for loss thresholds, warning conditions, and critical events </li></ul><ul><li>Sample Technologies: </li></ul><ul><li>syslog, application/platform access logs </li></ul>
    29. 30. Solution Integrity Subsystem <ul><li>Purpose: </li></ul><ul><li>address the requirement for reliable and correct operation of a computing solution in support of meeting the legal and technical standard for its processes </li></ul><ul><li>Functions: </li></ul><ul><li>Physical protection for data objects, such as cryptographic keys, and physical components, such as cabling, hardware, and so on </li></ul><ul><li>Continued operations including fault tolerance, failure recovery, and self-testing </li></ul><ul><li>Storage mechanisms: cryptography and hardware security modules </li></ul><ul><li>Accurate time source for time measurement and time stamps </li></ul><ul><li>Alarms and actions when physical or passive attack is detected </li></ul><ul><li>Sample Technologies: </li></ul><ul><li>Systems Management solutions - performance, availability, disaster recovery, storage management </li></ul><ul><li>Operational Security tools: , Host and Network Intrusion Detection Sensors (Snort), Event Correlation tools, Host security monitoring/enforcement tools (Tripwire, TAMOS), Host/Network Vulnerability Monitors/Scanners (Neesus), Anti-Virus software </li></ul>