1 Law Enforcement National Data Exchange SEARCH Annual Membership Group Meeting July 20, 2007

2 Development Schedule Increment 1: 1 st Quarter, 2008 Increment 2: 1 st Quarter, 2009 Increment 3: 1 st Quarter, 2010 Anticipated Dates

3 Development and Implementation Performance-Based Acquisition Development contract awarded to Raytheon Company, February 12, 2007 Contractor start date – February 26, 2007 Incremental Deployment Increment I – February 2008 Sharing of incident/case report information Search Correlation (basic) Visualization (basic) Limited fail-over capability Initial support – 50,000 users

4 Development and Implementation, cont. Increment II – February 2009 Add data sets – incarceration data and arrest/booking data Correlation (advanced) Visualization (advanced) Subscription/Notification (advanced) Analytical/Reporting (basic) Increasing system fail-over capabilities 100,000 Users

5 Development and Implementation, cont. Increment III – February 2010 Add data sets – probation/parole data Enhancements and modifications to previously deployed functionality Analytical reporting (advanced) Implement fully redundant system and environments 200,000 Users Operations and Maintenance Delivery – September 2010

6 Major Activities, Milestones, and Reviews for Increment 1 System Test Readiness Review (STRR) (CONTROL GATE 5) Prototyping Requirements & Architecture Detailed Design Design Concept Review (DCR) Critical Design Review (CDR) Component Development, Test & Integration Production Test Readiness Review (PTRR) Deployment Readiness Review (DRR) (CONTROL GATE 4) Functional & Interface Testing Deploy to CJIS System Test Acceptance Test Acceptance Test Readiness Review (ATRR) Operational Readiness Review (ORR) Final Design Review (CONTROL GATE 3) Development and Test Implementation and Integration Operations and Maintenance Jul 26 Aug 29 Oct 4 Oct 26 Nov 13 Mar 15 May 8 May 30 Feb 2008 Operational Acceptance Review (OAR) (CONTROL GATE 6) Training, C&A, Deployment Integrated Baseline Review (IBR) May 2 Program Management Week 21 Week 26 Week 31 Week 34 Week 8 Week 4 Week 10 Week 13

7 N-DEx Data Sensitivity Levels The entering agency categorizes data submitted to the System into levels of sensitivity upon which the dissemination of the information/data is controlled. APB Approved Sensitivity Levels: - This capability will allow agencies to submit information for sharing but control the dissemination of sensitive information to protect investigative equities. - Sensitivity applied to specific data elements if needed LEVEL 1 - SHARED N-DEx shall provide the capability for data contributors to allow sharing data it submits to N-DEx LEVEL 2 – CONDITIONALLY SHARED N-DEx shall provide the capability for data contributors to specify “pointer based” sharing of data. (i.e. provide POC information only) LEVEL 3 – NOT SHARED N-DEx shall provide the capability for data contributors to restrict data its submits to N-DEx. This level is reserved for the most restricted investigations and investigative information.

8 88 Key Data Sharing Requirements: Increment 1 Allow agency to control how and with whom their data is shared Agencies can enforce sharing restrictions for their data through agency- administered policy on N-DEx or by tagging data prior to submission to N-DEx. Accommodate changes to sharing policy N-DEx provides tools and mechanisms to allow each agency policy to change/select policies, without modifications to N-DEx system Allow data contributors to designate their data as: Unrestricted sharing (Green) * Pointer-based sharing (Yellow) * Restricted sharing (Red) * Allows data contributor to specify “exceptions” for red or yellow data (i.e. who can view the red or yellow data)

9 99 Key Data Sharing Requirements: Increment 1 (cont.) Allow data contributors to grant access to pointer-based (yellow) and restricted (red) data to selected users, groups, or agencies N-DEx provides tools for fine-grained access control, e.g., to certain individuals or groups/task forces Allow data contributors to configure sharing rules at the record, element/attribute or groups of elements/attributes level N-DEx provides tools for fine-grained access control, e.g., to certain elements such as victim identifying information Allow agencies to tag data prior to submission to N-DEx Agencies can restrict sharing at the record level only using this method Agencies can select generally who can view their red or yellow data using N-DEx User Interface – applies to all red or yellow records Agencies can’t take full advantage of the flexible sharing policies if they opt to tag their data prior to submission (but can configure N-DEx to ignore their tags and use N-DEx tagging policies at a later time)

10 Implementation Process Contributor Creates and assigns sharing groups Contributor Creates and assigns sharing groups During operations, Contributor may Modify sharing groups During operations, Contributor may Modify sharing groups Contributor Selects subset of rules appropriate for its data Creates and assigns sharing groups Contributor Selects subset of rules appropriate for its data Creates and assigns sharing groups During operations, Contributor may Modify sharing groups Affect (activate/deactivate) sharing rules Affect specific records, all records, or new submissions During operations, Contributor may Modify sharing groups Affect (activate/deactivate) sharing rules Affect specific records, all records, or new submissions Contributor may migrate from unrestricted data (ALL GREEN) only, or agency-supplied, to N- DEx-assigned tags after coordinating with N-DEx operations staff N-DEx assigned tags agency-supplied tags unrestricted data only During integration planning, Contributor indicates sharing policy intent: Unrestricted data only (ALL GREEN) Agency-supplied tags N-DEx assigned tags During integration planning, Contributor indicates sharing policy intent: Unrestricted data only (ALL GREEN) Agency-supplied tags N-DEx assigned tags

11 Granularity of Sharing Policy Sharing policy can apply to entire records specific elements/attributes within the record, or groups of elements/attributes If data received pre-tagged, sharing policy must apply to entire record (#’s 1-3 in example)

12 Sharing Rules, Increment 1 1 If incident type is SEX CRIME and person is type VICTIM, personal identifying data is restricted, except for > 2 If person is of type WITNESS and person attribute AGE IS LESS THAN 18 AT TIME OF EVENT, personal identifying data is restricted, except for > 3 If person is of type SUBJECT and person attribute AGE IS LESS THAN 18 AT TIME OF EVENT, personal identifying data is restricted, except for > 4 If person is of type VICTIM and person attribute AGE IS LESS THAN 18 AT TIME OF EVENT, personal identifying data is restricted, except for > 5 All Incidents are pointer-based accessed, except for > Note: “personal identifying data” is Name, SSN, Age, and Address In Increment 1, contributors can select rules from a pre-defined list Candidate rules include:

13 Sharing Rules for “Pre-Tagged” Data If a contributor chooses to submit data pre-tagged sharing policy specifies who has access to any restricted (RED) or pointer-based (YELLOW) incident reports

14 Interfaces – Business Rules Insert/Replace Based on unique data item id When publish instruction is “Insert” Record does not exist in N-DEx: record is Inserted Record exists in N-DEx: record is Replaced Delete Based on unique data item id When publish instruction is “Delete” Record exists in N-DEx: record is deleted. Send expungements as a “Delete” Message

15 Interfaces – Business Rules Supplements Supplements: two records logically related. The LEA System has two options: Option 1: Represent in N-DEx as two records Option 2: In mapping create one Report with all of the entities of both records. When a supplement is created the LEA System must send the original record and all supplements. Example: For N-DEx purposes a supplement is a record that is related to another record but managed separately by the RMS system. These are commonly seen as records numbered like: (primary record), (supplement 1 to 12345), (supplement 2 to 12345).

16 Continued Role of N-DEx SMEs Raytheon usability prototype and wireframes On-line review and comments Participation over several months as Increment 1 evolves Participation will continue for Increment 2 & 3 Training/Audit Review CBT and Training Guides Review Audit Plan and Guide Participate in Testing Functional and Interface Testing Acceptance Testing Cost Modeling Participate in validation of Cost Modeling Study

17 Role of CJIS Systems Officer (CSO) The Advisory Policy Board tasked the N-DEx Program Office with conducting an analysis of each state’s role for N-DEx connectivity. Brief questionnaire sent to all CSOs by N-DEx Program Office during week of June 25, 2007, requesting response by July 16, The questionnaire focused on the CJIS system responsibilities for each CSO within their respective state in reference to the N-DEx system (i.e. monitoring system usage, system discipline, CJIS operating procedures, and other related duties outlined in the User Agreement). The N-DEx Program Office will report the findings of the CSO analysis at the Fall CJIS Working Group Meetings scheduled August 15-16, 2007, in Denver Colorado.

18 Questions N-DEx Program Office Criminal Justice Information Services Division 1000 Custer Hollow Road Clarksburg, WV (304)