Architecting Enterprise Security

David ChouArchitect, Microsoft

david.chou@microsoft.com

http://blogs.msdn.com/dachou

IT Architect Regional Conference 2007

Environments Today Look Like…

Source: The Walt Disney Company

Enterprise Security Concerns

Infrastructure• Physical• Perimeter• Network• Hardware• Identity Mgmtetc.

Applications• Access Control• Data Protection• Data Encryption• Platform• Integrationetc.

Governance• Policies• Standards• Procedures• Auditing• Personneletc.

SOA?

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

Trust

System Identities

Message-Layer

Identity Federation

Centralized Shared Infrastructure

Endpoint (Overlay)

End-to-End Context

Impersonation / Delegation

End User Identities

Transport-Layer

Replicated Databases

Distributed Decision Enforcement Points

Intelligent Network

Peer-to-Peer Context

Information-Centric Security• Availability

• Confidentiality

• Integrity

• Accountability

• Identity and Access Management

• Audit

• Governance

• Business Continuity

• Security by Design

TrustworthyComputing

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)

• 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

• Web Services Security Gateway (XML Appliance)

• Enterprise Service Bus

• Custom Component

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)

Integrity• Data Assurance • XML Message Digest (W3C

XML Enc and DSig specs)

• WS-Security

Accountability• Non-Repudiation • XML Digital Signature

(W3C XML Enc and DSigspecs)

• 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 StrategyTechnology

• 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.