Architecting Enterprise Security

IT Architect Regional Conference 2007 Architecting Enterprise Security David Chou Architect, Microsoft david.chou@microsoft.com http://blogs.msdn.com/dachou Environments Today Look Like… Source: The Walt Disney Company Enterprise Security Concerns Governance • Policies • Standards • Procedures • Auditing • Personnel etc. SOA? Infrastructure • Physical • Perimeter • Network • Hardware • Identity Mgmt etc. Applications • Access Control • Data Protection • Data Encryption • Platform • Integration etc. SOA Brings Changes • • • • • • • • Imperative to Connect Networks Without Borders Mass Volume Real-Time Communications Integration Layer Concerns Inter-Dependencies Amplified Existing Issues Magnified New Issues Created Changing Nature of the Threat Environment SOA Brings Questions Impersonation / Delegation End User Identities Transport-Layer Replicated Databases Distributed Decision Enforcement Points Intelligent Network Peer-to-Peer Context Trust System Identities Message-Layer Identity Federation Centralized Shared Infrastructure Endpoint (Overlay) End-to-End Context Information-Centric Security • • • • • • • • • Availability Confidentiality Integrity Accountability Identity and Access Management Audit Governance Business Continuity Security by Design Trustworthy Computing Availability • System Reliability • Threat Protection – – – – – – – – Message alteration Data theft Falsified messages “Man in the middle” Principal spoofing Forged claims Malformed XML content Denial of Service (DoS) • Web Services Security Gateway (XML Appliance) • Enterprise Service Bus • Custom Component • Vulnerability Mitigation • Schema Poisoning • XML Parameter Tampering • Inadvertent XML DoS • WSDL Scanning • Oversized Payload • Recursive Payload • XML Routing Detours • SQL Injection • External Entity Attack • Malicious Code Injection •Identity Centric Attack Confidentiality • Data Privacy • Transport-Layer Security (SSL, TLS, IPSec) • XML Content Encryption (W3C XML Enc spec) • XML Encryption (W3C XML Enc spec): • • • Block encryption (3DES, AES-128, AES-256) Key transport (RSA-v1.5, RSA-OAEP) Key wrapping (3DES, AES128, AES256) • WS-Security (Oasis spec v1.1 Feb 2006; v1.0 Apr 2004) Integrity • Data Assurance • XML Message Digest (W3C XML Enc and DSig specs) • WS-Security Accountability • Non-Repudiation • XML Digital Signature (W3C XML Enc and DSig specs) • WS-Security Identity and Access Management • User Authentication • Authorization & Access Control • Trust & Federation • Transport-Layer Security • Message-Layer Security • XACML (eXtensible Access Control Markup Language) 2.0 • WSI Basic Security Profile (WSI spec v1.0 March 2006) • Web Services Security Appliances • Enterprise Service Bus Audit • Tracking • Monitoring • Reporting • XML Digital Signature (W3C XML DSig spec) • Digital Certificates (X.509, PKI, etc.) • Timestamps (network time synchronization) • Service Intermediaries (Web Services Security Appliances, Enterprise Service Bus, etc.) Security Architecture Policies (for example) • • • • • • • • • • Implement Threat Protection Implement Transport-Layer Security Implement Service Virtualization Externalize & Centralize Security Management Authenticate All Messages Authorize All Messages Audit All Messages Sign All Messages Encrypt Confidential Content Implement Standards-Based Security Implement Threat Protection • • Motivations – Supports Availability and Risk Aggregation Level 1 – Implement centralized protection against Denial of Service (DoS) attacks (floods, buffer overflows, message replays, message reflections) – Implement centralized protection (schema validation, WSDL cloaking) against XML-based DoS (XDoS) attacks (schema poisoning, oversized payload, recursive payload, WSDL scanning, parameter tampering) – Implement centralized protection (signature detection, context-sensitive content filtering, external reference control) against XML content-level attacks (SQL injection, virus/malicious code injection, identity spoofing, external entity attacks) – Filter all internal communication destined for ESB via internal Web Services Security Gateway – Filter all external communication mediated by B2B Gateway via Web Services Firewall • Level 2 – Implement decentralized/distributed vulnerability containment points at end systems – Maintain local vulnerability database or access centralized vulnerability management implementation • Future Developments – Anomaly detection (conversational/behavioral analytics) – XML-vectored intrusion detection and prevention Implement Transport-Layer Security • Motivations – Supports Confidentiality between peers (but not between end systems when managed by intermediaries) – Supports transport-level Data Integrity with protocol-based message digests (RFC 2104) and handshake completion hashes • Level 1 – All communication should be transported over SSLv3 – X.509 (RFC 3280) certificates should be used to establish authentication – Use only widely adopted (128-bit or longer) cryptographic algorithms: • • • For public-key cryptography: RSA, Diffie-Hellman, DSA, Fortezza For symmetric ciphers: RC2, RC4, IDEA, DES, 3DES, AES For one-way hash functions: SHA-1, SHA-2 – Authenticate only the server to maintain server identity for client-server communication – Mutual authentication should be implemented for server-server communication • Level 2 – All communication should be transported over TLS (currently v1.1; RFC 4346) – Use advanced ciphersuites (Camellia, Kerberos, SEED, Elliptic Curve Cryptography, Pre-Shared Key) • Future Developments – IPSec (RFCs 4301-4309) – OpenPGP-based certificates – Network Access Control (NAC) Implement Service Virtualization • Motivations – Supports Availability (by encapsulation service implementation details such as location, interface definition, security policies, etc.) – Supports Identity and Access Management – Supports Risk Aggregation • Level 1 – Server-to-server (point-to-point) direct connections – Unmanaged or managed by Web Services Management (WSM) solution • Level 2 – Mediate all internal communication via centralized ESB – Mediate all external communication via centralized B2B Gateway implementation • Future Developments – Domain-specific ESB integration and federation – Data and semantics virtualization (transformation into canonical formats) Externalize & Centralize Security Mgmt • Motivations – Supports Governance – Supports Identity and Access Management – Supports Risk Aggregation • Level 1 – Maintain local and autonomous security policy decisions (based on identity and access) – Maintain local identity store or access shared (centralized) identity store • Level 2 – Maintain local policy enforcement implementation – Delegate (externalize) security policy decision to centralized implementation • Future Developments – Externalize key and certificate management to centralized implementation – Externalize audit management to centralized implementation – Externalize vulnerability identification and mitigation to centralized implementation Authenticate All Messages • Motivations – Supports Identity and Access Management • Level 1 – System-based (peer-to-peer) trust relationships – Implement transport-layer security – Unique certificates or keys should be used to establish each relationship to maintain sender (requester or consumer) identity • Level 2 – Identity-based trust relationships (all connections are inherently untrusted) – Implement message-level security (attach credential tokens and cipher specifications and/or SAML identity assertions to establish and verify identity) • Future Developments – Enterprise single sign-on (based on centrally managed identity assertions) Authorize All Messages • Motivations – Supports Identity and Access Management • Level 1 – Maintain distributed, fine-grained, and customized local request authorization implementations (security policy decision and enforcement) – Implement centralized coarse-grained service authorization based on identity for proxy services deployed on ESB and B2B Gateway • Level 2 – Implement centralized fine-grained service authorization based on request content (payload) for proxy services deployed on ESB and B2B Gateway • Future Developments – Centralized security policy decision management and distributed enforcement implementation – Dynamic security policy interpretation and negotiation – Resource-layer policy enforcement implementation Audit All Messages • • Motivations – Supports Accountability – Supports Audit Level 1 – Intermediaries should log all message exchanges (requestor identity, destination, timestamp, message digest or content/payload, etc.) – The requester/sender (or consumer) system should log all sent messages (destination, timestamp, content/payload) and correlate them with received response messages – The server/receiver (or producer) system should log all received messages (requester identity, timestamp, content/payload) and correlate them with generated response messages – Intermediaries should audit encrypted content (by proactive decryption) in all received messages, if the peer-to-peer security context is established with requester systems • Level 2 – Intermediaries should log both received and sent messages if message content/format was altered due to proxy service implementation (i.e., data transformation, credential/identity mapping, data encryption/decryption, etc.) – Intermediaries do not have to audit encrypted content in received messages if the end-to-end security context is established between requester and receiver end systems • Future Developments – Externalize audit management to centralized implementation – Centralized audit log correlation and analytics Sign All Messages • Motivations – Supports Accountability – Supports Integrity • Level 1 – Internal messages do not have to be digitally signed – External message exchanges should be digitally signed (implemented by the B2B Gateway) • Level 2 – Sender (or consumer) systems should attach digital signatures (including message digests) to all messages – establishes non-repudiation for the sender systems – Intermediaries should perform signature verification in all received messages, if the peer-to-peer security context is established with requester systems • Level 3 – Receiver (or producer) systems should perform signature verification on received messages, as end-to-end security contexts can be established with requester systems • Future Developments – XML element-level digital signatures – Externalized signature verification using centralized management implementation Encrypt Confidential Information • Motivations – Supports Confidentiality • Level 1 – Implement transport-layer security to establish peer-to-peer confidentiality – Intermediaries are inherently trusted • Level 2 – Implement standards-based content/payload-level encryption (including fields and elements) • • • Block encryption (3DES, AES-128, AES-256) Key transport (RSA-v1.5, RSA-OAEP) Key wrapping (3DES, AES-128, AES-256) – Intermediaries do not decrypt/encrypt content if end-to-end security contexts are established between sender and receiver systems • Future Developments – Externalized key management and verification using centralized key and certificate management implementation Implement Standards-Based Security • Motivations – Supports Security By Design • Level 1 – Implement standards-based transport-layer security • Level 2 – WS-Security 1.0 (April 2004) – WS-Policy 1.1 (May 2003) – SAML 1.1 (September 2003) • Level 3 – WS-Security 1.1 (February 2006) – WS-Policy 1.2 (March 2006) – WSI-Basic Security Profile 1.0 (March 2006) • Future Developments – – – – – – W3C XML Encryption (XMLEnc), XML Digital Signature (XMLDsig) W3C XKMS (XML Key Management) WS-Federation WS-SecureConversation WS-Trust XACML (eXtensible Access Control Markup Language; OASIS 2.0 February 2005) Information Security Technology Model Source: Burton Group Policy-based & Layered Security Model • Perimeter Layer – Practices “security by exclusion” by enforcing boundaries between internet and intranet – Examples of technical components include: • Firewalls, VPNs, Intrusion Detection Systems (IDS), etc. • Identity and Access Layer – Practices “security by inclusion” by providing and enforcing identity-related and other resource-specific controls – Examples of technical components include: • • Authentication servers (i.e., Microsoft domain controllers, RSA/ACE server, etc.) Web access management (i.e., CA eTrust SiteMinder, IBM Tivoli Access Manager, etc.) • Resource Layer – Consists of applications, systems, content, and repositories – Security typically provided natively by resources • Control Layer – Exercises configuration, command, control, auditing, and detection obligations – Manages policy administration, decision, and enforcement operations through propagation, delegation, inheritance, and federation control mechanisms for cross-domain coordination Implementation Strategy Technology • • • • • • • • • Identity Management (IdM) Access Management Security Policy Management Certificate & Key Management (CA & PKI) Vulnerability Management Security Audit Management Lifecycle Management Quality Management Registries and Repositories Organization • Evolving Policies • Collaborative Policy Management • Incentivize Compliance • Policy Lifecycle Process • Full Process Transparency (Roadmaps, Migration Paths) • Incremental Delivery What’s Next? • • • • • • • • • De-Perimeriterization Continues Outsider / Insider Lines Blurring LOB Applications Becoming Service Consumers Emergence of Logical Security Zone Partitions Convergence of Virtualization and Physical Security Increasing Endpoint Security Intelligence Increasing Data / Content Centralization Federation Advancement Continues Encryption Going Mainstream In Summary • Just like enterprise SOA, it’s “how” you do security • Planning enterprise security requires a comprehensive, holistic approach • Focus on organizational and cultural issues • Security can create tight coupling in enterprise SOA • Essential part of an SOA infrastructure • Evolving technology landscape • Incremental technology delivery; maturity-based approach (expect mixed and hybrid environments) • Consumerization and evolving Web to bring more changes THANK YOU! • 10/15/07 3:15pm – Harry Pierson, “Moving Beyond Industrial Software” • 10/16/07 9:45am – Lynn Langit, “SharePoint Architecture – Lessons from the Trenches” • Come by our booth • Drop a business card • Win an Xbox 360 (or a Zune)! © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.