1 / 24

SWIM Implementation Team

SWIM Implementation Team. Segment 2 Prototyping Candidates. SIP TIM. Edward Ost, Flatirons Solutions, System Architect. 3 September 2009. Purpose. Provide an overview of SWIM Segment 2 prototyping candidates. Agenda. Service Gateway LAACS – SWIM PKI Unified Subscriber

dante-hicks
Télécharger la présentation

SWIM Implementation Team

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SWIM Implementation Team Segment 2 Prototyping Candidates SIP TIM Edward Ost, Flatirons Solutions, System Architect 3 September 2009

  2. Purpose • Provide an overview of SWIM Segment 2 prototyping candidates

  3. Agenda • Service Gateway • LAACS – SWIM PKI • Unified Subscriber • Complex Event Processing

  4. Security Prototypes • SSRI and LAACS-SWIM PKI Prototype provide • Uniform point of control • Security in a Box for SIPs • Consistency in Segment 1 Implementation • Minimal risk and effort for Segment 2 transition • SDLC Engagement Model based on Security Analysis Framework • Service Gateway provides • Uniform point of control • Consistent external interface implementation • Minimal risk and effort for Segment 2 transition

  5. SWIM Service Gateway Prototype Purpose • Establish an Untrusted ESB in the ED8 DMZ to act as a Service Gateway to accelerate secure exposure of services to external consumers.

  6. Service Gateway SWIM Risks • No common architecture exposing SIP services through the ED8 gateway • Redundant or incompatible deployment architectures • Incompatible SWIM Segment 1 security posture • Heterogeneous SWIM Segment 1 security postures • Increased level of effort SWIM Segment 2 transition • Deployment alternatives for ED8 DMZ are not well understood at this time • Uncertainty with respect to ED8 staffing support

  7. Service Gateway SWIM Benefits • Establish a common architecture • Common security model • Common deployment model • Decrease level of effort SWIM Segment 2 transition • Resolve ED8 technical and programmatic risks early • Multiple instances can be consolidated into a single NAS Service Gateway in Segment 2 (or earlier) • Rapid exposure of services to external consumers • Opportunistic exposure of NAS internal services

  8. SWIM Service Gateway Prototype Goal • Build an un-trusted ESB in the ED8 DMZ to facilitate service transport and mediation between external consumers and internally provided services. • Provide a reference implementation for SIPs in Segment 1. • Evaluate service gateway strategies and performance impacts. • Reduce technical and program risks related to ED8 support. • Provide an architecture that can be pooled as a common resource in Segment 2.

  9. LAACS-SWIM PKI Prototype Purpose • Provide a working model of how SWIM Security Reference Implementation (SSRI) based on Fuse ESB integrates with PKI infrastructure.

  10. SWIM Segment 1 Security Risks SIP • Multi-layer Security: Network, Transport, Endpoint, Business Logic • Lack of common security infrastructure • Lack of IT infrastructure • SCAP Preparation • Comply with SWIM Security Policy • SWIM Segment 2 transition SWIM • Determine Security Policy • Heterogeneous internal security strategies • Heterogeneous external boundary control strategies • Manageability • Provide SDLC controls • SWIM Segment 2 transition

  11. Integrated Security • There could be as many as four organizations responsible for different elements of security • Organizations must be loosely coupled while maintaining an Integrated Security posture

  12. SWIM Themes • SIP Segment 1 PKIAs a SIP Architect, how do I efficiently build and deliver local PKI infrastructure sufficient for my needs in Segment 1 while still being consistent with Segment 2 centralized PKI infrastructure? • SWIM Segment 1 SSRIAs a SWIM Architect, how does the Service Container consume PKI services from a heterogeneous collection of SIP providers in Segment 1? • SWIM Segment 2 Security DemarcationAs a SWIM Segment 2 Architect, what is the runtime demarcation between SWIM and NAS Security Infrastructure in SWIM Segment 2?

  13. LAACS-SWIM PKI Prototype Benefits • Provide a transition path for SIPs by providing a PKI-in-the-box to encapsulate components subject to change. • Minimize variation and level of effort for Segment 2 security transition. • Consistent, modular security posture that can be coordinated across SIPs, SWIM, and other security organizations

  14. LAACS-SWIM PKI Goals • PKI-in-a-box for SIPs • SSRI-PKI integration test-bed • Allow acceleration of PKI delivery schedule • Inputs to NAS Security Policy • Clarify program responsibility - SWIM, LAACS, FTI, other • Clarify enforcement boundaries – PKI, enforcement endpoint • Identify security technologies – PKI, XML-GW, WSS

  15. LAACS-SWIM PKI Prototype Objectives • SWIM Scope • Application level focused on Service Container as consumer of PKI services • NOT SSP servers • SWIM Deliverables • An application test fixture for validating PKI infrastructure use in services based on the SWIM Security Reference Implementation. • LAACS Deliverables • PKI Infrastructure as VM servers • Objectives • Move PKI server infrastructure schedule to the left • Application level security interoperability for SWIM Fuse products • SIP transition plan from local PKI to NAS PKI • Interoperability with USCP, DoD, and Eurocontrol • Provide local PKI procedures for SIPs • Provide VM for rapid integration testing with SIPs • Improve costing and requirement precision • Help develop SWIM S1 and S2 application level policy security

  16. Security Roadmap • SWIM Segment 1: • Centralized network security • ED-8 p2p Service Security • P2P Transport Security • Standardized local PKI • Standardized endpoint and business logic technology • SWIM Segment 2: • Centralized network Security • Service Gateway: ED-8 untrusted ESB • Centralized PKI • Centralized Transport Security • Managed Endpoint Security • Federated Business Logic Security Solution Components • Network: IPsec • DNSSEC • PKI • OCSP • CRL • CA • LDAP • Secure Token Service • SSO • XML-GW • Active Endpoints • SC Endpoints • Business Logic • SDLC Controls

  17. SWIM Unified Subscriber Prototype Purpose • Establishing a reference implementation for providing pub-sub semantics to external consumers over non-JMS transports through a unified subscriber interface that aggregates both publications and subscriptions.

  18. Unified Subscriber SWIM Risks • External consumers lack wire-level JMS interoperability • Distributed publishers such as TDDS require consumers to set up multiple subscriptions • As number of external consumers grow WAN traffic grows

  19. Unified Subscriber SWIM Benefits • Establish a common architecture • Provide a reusable asset for publication aggregation • Provide a reusable asset for subscription aggregation • Common deployment model • Resolve ED8 technical and programmatic risks early • Rapid exposure of JMS topics to external consumers • Opportunistic exposure of NAS internal topics

  20. SWIM Unified Subscriber Goal • WS-Notification provides a model for pub-sub semantics • Evaluate maturity of WS-Notification in Fuse ESB • Information subscription interface and endpoints should not reflect the providers deployment architecture • Subscribers should not have to manage multiple connections • Represents coupling between IT and operational domains • Mitigate with publisher proxy • Publishers should not have to worry about the location of subscribers • Represents coupling between consumer and provider topologies • Mitigate with subscription proxy

  21. Unified Subscriber Prototype Objectives • Aggregate distributed internal subscriptions • Aggregate multiple subscription requests • Evaluate WS-Notification maturity • Mediate subscriber transport • Support SOAP/HTTP subscriber endpoints • Supports WS-RM for guaranteed delivery • Support POX/HTTP consumers • Support ATOM consumers • Accelerate adoption by actual AOC • Apply unified subscriber pattern for internal NAS users

  22. CEP Prototype Purpose • Explore Complex Event Processing (CEP) leveraging System Wide Information Management (SWIM) SOA Infrastructure for Security Integrated Tool Suite (SITS)

  23. CEP Prototype Objective • Develop a Complex Event Processing Reference Implementation • Leverage SWIM SOA for data source integration • SITS System Interfaces • Skywatch – log identified incidents • TFR Builder – define monitoring rules based on TFR • AAP – define approved waivers and exceptions • MADE and SAMS – define monitoring rules based on SUA • ADAPT – tracking and coordination of identified flights • DEN

  24. CEP Prototype Objective • SWIM Architecture Case Study • Demonstrate an information grid pattern • Integrate multiple input data sources (MADE, SAMS, TFR, AAP) • Demonstrate canonical data exchange model • Application of DXSI for pub-sub • Demonstrate ESB transport and invocation mediation for providing pub/sub data feeds • Demonstrate ESB EDA integration with CEP • Evaluate Test Driven SOA concepts • Evaluate and test development infrastructure • Evaluate virtualization operational concepts • Deferred Options • Notification of external agencies through ESB and ED8 • Extension of collaboration services with RSS/ATOM type feeds • Extension of collaboration services with instant messaging

More Related