1. DHS Terrorist Watch List Integration Program Watch List Update Data Distribution Service 15 March 2006 UNCLASSIFIED/FOUO DHS OCIO Information Sharing Program

2. 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

3. 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

4. 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

5. Unclassified//FOUO 5 Project Overview: Watch List Update Pilot Objective: 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

6. 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

7. 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.

8. 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.

9. 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

10. 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

11. Unclassified//FOUO 11 High-Level Functionality

12. Unclassified//FOUO 12 Logical System Architecture

13. Unclassified//FOUO 13 Watch List Update Component Overview

14. 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

15. 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

16. 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

17. Unclassified//FOUO 17 Message XSLT Transformation Mapping

18. Unclassified//FOUO 18 Message XSLT Transformation Preview TWPDES 1.0+ TWPDES 2.0

19. 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

20. 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

21. 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

22. 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

23. 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?