20071015 Architecting Enterprise Security

2,168 views

Published on

Published in: Technology, Education
1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
2,168
On SlideShare
0
From Embeds
0
Number of Embeds
20
Actions
Shares
0
Downloads
199
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

20071015 Architecting Enterprise Security

  1. 1. IT Architect Regional Conference 2007 Architecting Enterprise Security David Chou Architect, Microsoft david.chou@microsoft.com http://blogs.msdn.com/dachou
  2. 2. Environments Today Look Like… Source: The Walt Disney Company
  3. 3. Enterprise Security Concerns Governance • Policies • Standards SOA? • Procedures • Auditing • Personnel etc. Infrastructure Applications • Physical • Access Control • Perimeter • Data Protection • Network • Data Encryption • Hardware • Platform • Identity Mgmt • Integration etc. etc.
  4. 4. 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
  5. 5. SOA Brings Questions Impersonation / Trust Delegation System Identities End User Identities Message-Layer Transport-Layer Identity Federation Replicated Databases Centralized Shared Distributed Decision Infrastructure Enforcement Points Endpoint (Overlay) Intelligent Network End-to-End Context Peer-to-Peer Context
  6. 6. Information-Centric Security • Availability • Confidentiality • Integrity • Accountability • Identity and Access Management • Audit • Governance Trustworthy • Business Continuity Computing • Security by Design
  7. 7. Availability • System Reliability • Web Services Security • Threat Protection Gateway (XML Appliance) – Message alteration • Enterprise Service Bus – Data theft • Custom Component – Falsified messages – “Man in the middle” – Principal spoofing • Schema Poisoning – Forged claims • XML Parameter Tampering • Inadvertent XML DoS – Malformed XML content • WSDL Scanning • Oversized Payload – Denial of Service (DoS) • Recursive Payload • XML Routing Detours • Vulnerability Mitigation • SQL Injection • External Entity Attack • Malicious Code Injection •Identity Centric Attack
  8. 8. 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, AES- 256) • WS-Security (Oasis spec v1.1 Feb 2006; v1.0 Apr 2004)
  9. 9. Integrity • Data Assurance • XML Message Digest (W3C XML Enc and DSig specs) • WS-Security
  10. 10. Accountability • Non-Repudiation • XML Digital Signature (W3C XML Enc and DSig specs) • WS-Security
  11. 11. Identity and Access Management • User Authentication • Transport-Layer Security • Authorization & Access • Message-Layer Security Control • XACML (eXtensible Access • Trust & Federation Control Markup Language) 2.0 • WSI Basic Security Profile (WSI spec v1.0 March 2006) • Web Services Security Appliances • Enterprise Service Bus
  12. 12. Audit • Tracking • XML Digital Signature • Monitoring (W3C XML DSig spec) • Reporting • Digital Certificates (X.509, PKI, etc.) • Timestamps (network time synchronization) • Service Intermediaries (Web Services Security Appliances, Enterprise Service Bus, etc.)
  13. 13. 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
  14. 14. 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
  15. 15. 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)
  16. 16. 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)
  17. 17. 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
  18. 18. 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)
  19. 19. 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
  20. 20. 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
  21. 21. 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
  22. 22. 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
  23. 23. 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)
  24. 24. Information Security Technology Model Source: Burton Group
  25. 25. 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
  26. 26. Implementation Strategy Technology Organization • Identity Management (IdM) • Evolving Policies • Access Management • Collaborative Policy • Security Policy Management Management • Certificate & Key • Incentivize Compliance Management (CA & PKI) • Policy Lifecycle Process • Vulnerability Management • Full Process Transparency • Security Audit Management (Roadmaps, Migration • Lifecycle Management Paths) • Quality Management • Incremental Delivery • Registries and Repositories
  27. 27. 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
  28. 28. 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
  29. 29. 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)!
  30. 30. © 2007 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

×