swim implementation team
Skip this Video
Download Presentation
SWIM Implementation Team

Loading in 2 Seconds...

play fullscreen
1 / 24

SWIM Implementation Team - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' SWIM Implementation Team' - dante-hicks

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
swim implementation team

SWIM Implementation Team

Segment 2 Prototyping Candidates


Edward Ost, Flatirons Solutions, System Architect

3 September 2009

  • Provide an overview of SWIM Segment 2 prototyping candidates
  • Service Gateway
  • Unified Subscriber
  • Complex Event Processing
security prototypes
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
swim service gateway prototype purpose
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.
service gateway swim risks
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
service gateway swim benefits
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
swim service gateway prototype goal
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.
laacs swim pki prototype purpose
LAACS-SWIM PKI Prototype Purpose
  • Provide a working model of how SWIM Security Reference Implementation (SSRI) based on Fuse ESB integrates with PKI infrastructure.
swim segment 1 security risks
SWIM Segment 1 Security Risks


  • 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


  • Determine Security Policy
  • Heterogeneous internal security strategies
  • Heterogeneous external boundary control strategies
  • Manageability
  • Provide SDLC controls
  • SWIM Segment 2 transition
integrated security
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
swim themes
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?
laacs swim pki prototype benefits
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
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
laacs swim pki prototype objectives
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
security roadmap
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
  • PKI
    • OCSP
    • CRL
    • CA
    • LDAP
  • Secure Token Service
  • SSO
  • XML-GW
  • Active Endpoints
  • SC Endpoints
  • Business Logic
  • SDLC Controls
swim unified subscriber prototype purpose
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.
unified subscriber swim risks
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
unified subscriber swim benefits
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
swim unified subscriber goal
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
unified subscriber prototype objectives
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
cep prototype purpose
CEP Prototype Purpose
  • Explore Complex Event Processing (CEP) leveraging System Wide Information Management (SWIM) SOA Infrastructure for Security Integrated Tool Suite (SITS)
cep prototype objective
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
cep prototype objective1
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