DHS Terrorist Watch ListIntegration Program

Watch List Update Data Distribution Service

15 March 2006

UNCLASSIFIED/FOUO

DHS OCIO Information Sharing Program

Unclassified//FOUO 2

Agenda

• Background and objectives of OCIO Watch List Integration (WLI) program

• Drill-down on the Watch List Update technology pilot

• Contribution of Watch List Update pilot to Screening Initiative led by Screening CIOs

• Action requested - - Questions/critique/discussion/use of Watch List Update pilot

− Alignment to objectives and requirements− Alternatives for meeting near term and long term data

needs

• Next Steps

Unclassified//FOUO 3

Watch List Integration Program Background• Program established in DHS CIO Office in FY2004 in

response to one failure blamed for 9/11: multiple inconsistent “watch lists”

• Program Objectives - - − Create a “solutions architecture” for enhanced and

coordinated use of terrorist watch list data in person screening within DHS

− Limited to solution planning, coordination and “glue” technology

− Additional tasks added with issuance of HSPD-6 (9/2003) establishing Terrorist Screening Center

− Additional task added to support DHS HSPD-11 and related analysis

− Also supported BTS/OCIO screening “transformation” initiatives

• Starting in January, 2005, focus on “glue” technology: Watch list Update Pilot

Unclassified//FOUO 4

FY06 Program Goals

1. Establish real-time update of Watch List in one or more DHS screening databases under Component sponsorship

2. Publish additional screening data services via Watch List Pilot, creating SOA-based screening content distribution for info sharing in partnership with HSOC/IA

3. Extend screening data services to SBI field operators in support of DHS Policy/Planning

Unclassified//FOUO 5

Project Overview: Watch List Update PilotObjective: create a pilot “Watch List Update” technology component that will serve future screening business process while also providing operational experience with the SOA architecture pattern

• Update component needed – DHS has large, dynamic set of people screening programs. Manage adds/changes here, not at TSC: make single DHS connection to TSC

• Incorporate known future technology requirements– Including “Addendum A” data in XML format, interfaces compatible with anticipated Info Sharing Environment patterns; robust real-time updates; logging

• Validate SOA technology pattern – Designed as service, not application; multiple interfaces; “self-service”; identify technical and other issues using SOA/ESB

• Create “starter” implementation of SOA/ESB architecture for Department

Unclassified//FOUO 6

Implementation Plan

• Information Sharing Environment (ISE) Pilot:− Establish platform necessary for information sharing environment− Provide interface for one-way integration between TSC and IBIS/No-

Fly via ISE− Develop dataset and core services for receiving updates from TSC− Leverage existing TWPDES data exchange standard for initial TSC

integration− Provide HTML DB interface to the Information Sharing Environment

(ISE) watch list

• ISE Enhancements:− Integrate with IDENT and USCIS− Employ federated web services locator− Refine services developed during pilot

• ISE Adoption:− Integrate with other DHS component systems− Integrate with other communities

Unclassified//FOUO 7

Incoming: IC-developed XML data schema for terrorist identities--Terrorist Watch List Person Data Exchange Standard (TWPDES)

Technical Approach - Data

• Core Dataset – Identify and document person-centric core-dataset needed to create, maintain and share across the department, and extend as mission functionality extended datasets are identified.

• Extended Dataset – Identify and document person-centric extended dataset needed to create, maintain and share across department and other external partnering organizations.

• Domain Data - Identify and document person-centric domain dataset needed to share across department and other external partnering organizations.

• NIEM (GJXDM & TWPDES) – Adopt and contribute to NIEM standards.

Unclassified//FOUO 8

The Watch List Update Pilot uses an Enterprise Services Bus to implement the business functionality following a Service Oriented Architecture (SOA) pattern.

Technical Approach - SOA

• Business Services – This layer is used to expose the functionality using various technical protocols. JMS, SOAP or MQ protocols may be used together or individually to extend functionality specified by a core services layer.

• Core Services – This layer contains the main processes which implement workflow integration. These are defined as stand alone. Core services utilize both common services and reusable services.

• Common Services - Processes which implement common functionality.

• Reusable Services - Sub-Processes.• XSD definition is used to provide a standard

data format regardless of protocol used.• XSLT schema is used to decouple the data

transformation function from the core business processes.

Unclassified//FOUO 9

Key Architecture Considerations

• Easily add or replace new interfaces

• Support industry standard protocols

• W3C XML Schema support

• SOA pattern: building a component, not a complete application

• NIEM (GJXDM & TWPDES) compliant

• Anticipate requirements for federated query and role-based access capabilities

Unclassified//FOUO 10

Key Functional Requirements

• Provide a standards-based DHS enterprise-level platform to disseminate real-time updates of terrorist watch list to multiple DHS screening systems

− Eliminate multiple point-to-point communication exchanges• Support additional (Addendum A) data elements and TWPDES schema• Provide potential for sharing terrorist-related data with DHS’ external

partners [TSC and the National Counterterrorism Center (NCTC)]• Provide an easily scalable solution that utilizes standard interfaces for

integrating with a wide variety of DHS systems− Independent import and export transport methods− Minimize changes to existing systems− Easy “Customization” of data elements provided to each screening system− Support multiple interface protocols

• Provide sufficient data to re-trace data receipt, translation, and delivery in order to troubleshoot data distribution issues

• Provide a means for re-transmission of prior data sent to DHS end systems

• Provide a means to ensure data quality through error checking and resolution procedures

Unclassified//FOUO 11

High-Level Functionality

Unclassified//FOUO 12

Logical System Architecture

Unclassified//FOUO 13

Watch List Update Component Overview

Unclassified//FOUO 14

Message Structure Overview• Message structure is independent of transport method

• Messages will contain one or more nominations

• Each nomination has one associated action (A, M, D)

• Each nomination is tagged for one or more destinations example: (IBIS, TSANOF, etc.)

• The nomination can contain one or more person instances in TWPDES 1.x format

• UUID will come from the TSC

• The message ID (OriginatorID) is passed to the downstream organization components (OC) for full traceability

• Messages are received in TWPDES 1.0+ format and transformed via the ESB BUS to TWPDES 2.0 with plans to migrate to TWPDES 1.1 and NIEM later

Unclassified//FOUO 15

Incoming TSC Message Structure

Drivers• Message structure

independent of transport method

• Messages will contain one or more nominations

• Each nomination will have one associated action (A, M, D)

• Each nomination will be tagged for one or more destinations (IBIS, NoFly)

• The nomination will be in TWPDES 1.0+ format. Based on the current XSD used by TSC

• Each nomination may contain one or more person instances

• UUID will come from the TSC

Data• TWPDES 1.0+• Action• Destination

XSD Message Structure

Unclassified//FOUO 16

Outgoing ISE Message Structure

Drivers• Message structure

independent of transport method

• Messages will contain only one nomination

• The message will have one associated action (A, M, D)

• Each message will be routed to one client destination (IBIS, NoFly)

• The message body will be in TWPDES 2.0 format

• Each message may contain one or more person instances

• ISE generated UUID

Data• TWPDES 2.0• Action

XSD Message Structure

Unclassified//FOUO 17

Message XSLT Transformation Mapping

Unclassified//FOUO 18

Message XSLT Transformation Preview

TWPDES 1.0+

TWPDES 2.0

Unclassified//FOUO 19

Watch List Update Log Database

Drivers• Support

administrative functions

• Message store• Traceability• Debugging and error

resolution• Chain of custody• Transaction history

(45 Days)

Data• Watch List data• System configuration• Transaction logs

Thes e entities are part of the Organization Regis tration and Configuration Proces s

Thes e entities s upport the information s haring operation

has /benefits

are logged in /contains

logs entries in /holds entries from

provided to /receives from

Are Processed on /Reflects

OrganizationOrganizationID

OrganizationIDReferenceOrganizationNameOrganizationTypeTxtOrgAbbreviationTxtOrgGovernmentLevelCodeOrgBranchNamePrimaryContactPersonPrimaryContactPersonPhoneNoPrimaryContactPersonFaxNumberPrimaryPersonMobileNumberPrimaryContactEmailIDPrimaryContactInfoReferenceEmergencyContactPersonEmergencyContactPersonPhoneNoEmergencyContactPersonFaxNoEmergencyContactPersonMobileNoEmergencyContactEmailIDEmergencyContactReferenceOrganizationUserIDOrganizationPassword

OrganizationTopicsOrganizationID (FK)OrganizationInterestSeqID

TopicOfInterestTopicOfInterestReferenceActivityTypeTxtActivityTypeReferenceOrganizationUserIDOrganizationPasswordImportTransportTypeExportTransportTypeXSLTReferenceURLWSDLServiceNameWSDLPortNameWSDLPortBinding

ISEMessageLogISEMessageLogID

TopicOfInterestSenderMessageIDProviderTimeStampReceiveTimeStampMessageBlockMessageBlockURLMessageBlockIDMessageBlockSizeinBytesImportTransportTypeExportTransportTypeSendJMSDestinationSendJMSExpirationSendJMSPrioritySendJMSMessageIDSendJMSTimeStampSendJMSCorrelationIDSendJMSReplytoSendJMSTypeSendJMSRedeliveredSendWSDestinationSendWSMessageIDWebServiceReplyTypeErrorReasonMessageRequestStartDateMessageRequestEndDateISEMessageLogTimeStampTransactionType (FK)

ISEMessageSenderISEMessageSenderID

AgencySenderSenderMessageIDMessageBlockIDTopicOfInterestSenderInformationtextReceiverInformationTextXMLinfoTextRemarksXMLMessageReceiveXMLMessageSendISEMessageStateISEMessageQueueTimeStampImportTransportTypeExportTransportType

TransactionTypesTransactionType

Unclassified//FOUO 20

Where is Query Capability?• Building an update component, not an application

• Query of full Watch List is an obvious requirement, but out of scope for this effort

− Requires “persisting” the full Watch List dataset and developing one or more queries

• Alternatives for implementing query− Add to functionality of Watch List Update component

Pro - - “complete” application easier to demo! Con - - breaks SOA pattern; competes with screening process

owners; not aligned with TSC plans− Assign that service to DHS (organizational) component

Pro - - Leverages customer knowledge of components Con - - Not aligned with TSC plans

− Assign to TSC, as “authoritative source” of data Pro - - Purest implementation of ISE/SOA concepts; aligned with

TSC plans Con - - May have to wait for TSC; requires “distributed query”

capabilities on DHS end to combine with other data

Unclassified//FOUO 21

Implementation Status Summary• Platform: Oracle 10g on Sun hardware with Solaris, TIBCO, and

Watch List Update component logic installed and configured at Ashburn Data Center and ST&E and C&A complete

• Network connectivity from TSC to Ashburn in place

• ATO pending mitigation of ST&E findings. GATS planned end of March

• Interconnect agreements and PIA in progress

• On track for operational (pilot) implementation Q2FY2006

• CBP agreed to take ownership – pending final decision/concurrence

• Open issues:− Info Sharing Arrangement discussions with TSC− Target screening systems—NoFly, TECS, Secure Flight—not ready to consume

update service

Unclassified//FOUO 22

Contribution to the Screening Initiative

• “Quick win”− Fills certain need for real-time update from TSC Watch

List− Based on service-oriented pattern consistent with Team

5 and other recommendations− Incorporates established TWPDES identity schema,

which provides for Addendum A and biometric identifiers; closely coordinated with NIEM strategy

− Software, equipment, C&A, PIA done or in progress− Resources in place for IOC and interim O&M

• “Starter” for Departmental ESB facility− NOT trying to do it all - - just an update component− Ready for handoff to Screening PMO− Available for quick implementation of additional SOA

component pilots (I-94, SBI, CIS ID check, RCI)− Does NOT assume or require centralized ESB strategy

Unclassified//FOUO 23

Feedback. . .

• How does this pilot align to architecture vision?

• How can pilot contribute to objectives?

• What are best alternatives for meeting near term and long term data needs?

• Next steps?