DHS Terrorist Watch List Integration Program

1. DHS Terrorist Watch ListIntegration Program Watch List Update Data Distribution Service DHS OCIO Information Sharing Program 15 March 2006 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 • Establish real-time update of Watch List in one or more DHS screening databases under Component sponsorship • Publish additional screening data services via Watch List Pilot, creating SOA-based screening content distribution for info sharing in partnership with HSOC/IA • Extend screening data services to SBI field operators in support of DHS Policy/Planning 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 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. Technical Approach - Data Incoming: IC-developed XML data schema for terrorist identities--Terrorist Watch List Person Data Exchange Standard (TWPDES) • 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. Technical Approach - SOA The Watch List Update Pilot uses an Enterprise Services Bus to implement the business functionality following a Service Oriented Architecture (SOA) pattern. • 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 XSD 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 Unclassified//FOUO

16. Outgoing ISE Message Structure XSD 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 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 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? Unclassified//FOUO