dhs terrorist watch list integration program watch list update data distribution service 15 march...
TRANSCRIPT
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?