Swim implementation team
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