Automating Google Workspace (GWS) & more with Apps Script
20071015 Architecting Enterprise Security
1. IT Architect Regional Conference 2007
Architecting Enterprise Security
David Chou
Architect, Microsoft
david.chou@microsoft.com
http://blogs.msdn.com/dachou
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. 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. 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. Information-Centric Security
• Availability
• Confidentiality
• Integrity
• Accountability
• Identity and Access
Management
• Audit
• Governance Trustworthy
• Business Continuity Computing
• Security by Design
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. 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)
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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
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
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. 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. 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)!
