FLORIDA DEPARTMENT OF LAW ENFORCEMENT

Transcription

1 FLORIDA DEPARTMENT OF LAW ENFORCEMENT REQUEST FOR INFORMATION (RFI) 1524 FOR Incident Tracking System February 13, 2015 Page 1 of 23

2 I. INTRODUCTION The Florida Department of Law Enforcement (FDLE), FDLE Investigations & Forensic Sciences Program Office is requesting information regarding a comprehensive Incident Tracking System. II. PURPOSE OF AN RFI Pursuant to Rule 60A-1.042, Florida Administrative Code (F.A.C.), an agency may request information by issuing a written Request for Information. Agencies may use Requests for Information in circumstances including, but not limited to, determining whether or not to competitively procure a commodity or contractual services, determining what solicitation process to use for a particular need, or researching general, special, and/or technical specifications for a solicitation. A Vendor s response to an RFI is not an offer and the agency may not use the Vendor s submission to justify a contract with that Vendor without otherwise complying with Chapter 287, F.S., and Rule 60A-1.042, F.A.C. Vendors submitting a response to an agency s RFI are not prohibited from responding to any related subsequent solicitation. III. BACKGROUND In July 2013, the Florida Fusion Center (FFC) within the Florida Department of Law Enforcement (FDLE) became the primary state contact to the Multi-State Information Sharing and Analysis Center (MS-ISAC). The FFC facilitates computer network monitoring by the MS-ISAC at several data centers/agencies in Florida. This monitoring produces alerts which identify existing or potential network security issues. The alerts are provided to the affected agency to remove threats and support their network defense. Additionally, the MS-ISAC provides intelligence products (Advisories) to the FFC. These advisories are provided to be disseminated to different level audiences. As of July 1, 2014, pursuant to Chapter (4)(d), Florida Statutes, all executive branch State of Florida agencies need to start reporting network security incidents, including data breaches, to the FFC, referred to in the statute as the Cybercrime Office of the FDLE. To avoid confusion, this office within FDLE will be referred to in this document as the FDLE Cybercrime Office (FCO). The FCO assumes that each agency has, or will have, internal incident reporting procedures; however, the method and format of reporting and the specific incident classifications will vary from agency to agency. This information will eventually become standardized as the Agency for State Technology (AST) develops statewide policies and procedures to address information technology issues. Page 2 of 23

3 All agencies should be able to notify the FCO in an effort to share information about current information technology security issues, especially those that may have an impact on other State of Florida agencies. This will provide visibility into security issues that could facilitate additional available resources being leveraged when necessary. More serious security issues should have the ability to be reported with more immediacy and general or routine issues in a monthly synopsis. Should the FCO become aware through this reporting Incident Tracking System (System), or any other means, of a security incident that affects one or more State agencies, the FCO will pass that information to the appropriate agency Information Security Managers ISM(s). Once the System is implemented, the agency ISM s will be contacted by the FCO with procedures and establishing of authentication credentials. Further, according to new provisions of Chapter 282, Florida Statutes, all reports submitted to the FCO will be classified as confidential information and not available for public record disclosure; however, there will be public disclosure of non-confidential information. Reports will not be further disseminated without the consent of the appropriate agency ISMs. IV. STATEMENT OF NEED AND TECHNICAL INFORMATION A. General Description The information obtained from responses to this RFI will be used to support FDLE s request for funding to complete this effort. The primary purpose of this RFI is to obtain information from qualified Vendors regarding: Products available for incident tracking and data sharing in a statewide environment where Agencies maintain disparate systems and reporting tools. Specific technological improvements now available for incident tracking systems. Information about products that could meet the needs of both reporting (by agency ISMs) and administrative (FCO and AST) functionality. For example, details related to how the system supports standardized reporting forms, incident categories, escalation capabilities, dashboards, and analytics. This includes the production of visual tools, such as charts and graphs, for users to be able to easily understand and communicate the analytical output. Information about how incidents are managed, monitored, and maintained. Information about how your product can analyze data in the system and how that analysis can be viewed, either through dashboards, charts, graphs. Page 3 of 23

4 Information on how the recommended product produces, executes and maintains robust testing to ensure expected results from known test data. Information on technical knowledge transfers for architecture, hardware, database, storage, networking and software of the new Incident Tracking System. A list of any required third-party software, and/or any vendor supplied customized COTS product information that may be required to implement the Incident Tracking System. Provide system capabilities for supporting application program interfaces (APIs), data exchanges (non-api), and notifications (protocols and information filtering). Provide technical information related to automation capabilities. Map automation to system functions such as electronic data interfaces, alerting and notifications, workflows, and all related incident lifecycle automation capabilities. If the system supports in-line actions, please provide technical specifics and supported applications for this functionality. General costs regarding implementation and maintenance of the System. How the product may produce and maintain a modern, role-based access control system, with effective logging. Description of business continuity, backup, and disaster recovery capabilities. B. Current Systems 1. Overview of Current Systems The FCO currently receives data from various sources as described in this section and manually manipulates this data to create a more uniform data set to work with. These Functional Requirements are broken down primarily by function (e.g., data collection) and secondarily by the data source and type of data to be collected, processed, and output. A table of the Functional Requirements is available on Attachment #1. The System that will replace the current manual processes will create a uniform input method for some of the input sources, replace current data stores with a database System, and be able to output this data in reports, as well as with a dashboard for users to see what is important to them. In addition, the current data (mainly Excel spreadsheets and SharePoint documents) need to be migrated into the new System when it is brought online. 2. State Agency Information Security Managers (ISMs) Report Incidents To comply with Florida Statutes, ISMs for several state agencies are required to report incidents to the FCO. Before the AST can establish a uniform reporting Page 4 of 23

5 requirement, agencies are reporting this data to the FCO in a variety of formats, which are manually put into an Excel spreadsheet within the FCO. In addition, any attachments are placed into a folder in a SharePoint system. Agencies report major incidents individually, in a timely manner after the incident occurs. Minor incidents are reported in aggregate form (e.g., description of the type of incident and the number of these incidents that happened) once a month. Some state agencies receive reports from security software vendors that are forwarded to the FCO. 3. The FCO receives s from the MS-ISAC and disseminates data from these to agency ISMs/appropriate parties The FCO receives both Advisory and Alert s from the MS-ISAC. The MS-ISAC advisory s are forwarded to the ISMs and other intelligence community partners for the purpose of situational awareness and computer network security hardening. The alerts pertaining to identified security issues within a Florida based network are provided to the appropriate party. These alerts use a traffic light protocol (TLP) for identifying who should receive the information. 4. The FCO manually consolidates and analyzes incoming data, then communicates important information to other stakeholders Data from individual and consolidated incident reports submitted by ISMs, as well as data from the MS-ISAC, are manually entered into Excel spreadsheets at the FCO. Analysts use these spreadsheets to identify trends and notify ISMs and the AST with any incidents or trends that would be of use to these other stakeholders. There is no current mechanism to consolidate and analyze data from security software vendor reports. C. Objectives: Acquire and implement a customized Incident Tracking System to meet FDLE s requirements for incident tracking Improve the methods of receiving, storing, displaying, updating and analyzing the information Provide a modern, role-based access control system, with effective logging Provide business processes through automated queries, workflows and drilldown capabilities Eliminate manual processes Improve processing and analysis of the consolidated results Meet FDLE s high availability requirements Page 5 of 23

6 Meet FDLE s information technology (IT) standards and policies Maintain compliance with the FBI CJIS Security Policy (CSP), state of Florida, and FDLE security rules (attachment #2) To obtain planning, configuration, implementation, production employment services To obtain user training for FDLE To obtain system administration training for FDLE s IT support staff To establish a maintenance and technical support program for the Incident Tracking System. D. System Performance The data sharing system is not considered mission critical but the Agency requires the System to be designed for high availability and redundancy: Vendor should suggest the uptime recommended System will be able to meet (e.g., 99.99%) The System is desired to be accessible 24 hours a day x 7 days a week; however peak access times will be during core business hours (Monday through Friday, 8-5) E. Services Describe the software and hardware implementation services that can be provided to migrate the current data from SharePoint, Excel spreadsheets, and MS-ISAC Advisory and Alert notifications to the new Incident Tracking System. Describe the overall approach including the System architecture and technologies that may be used for mapping and extract, transform, and load (ETL) of the data Describe what processes may be available to ensure data quality during import and updates Describe the user interface and what types of queries and features may be included in a standard core license and, (if applicable) optional licenses Describe available system(s) that allow the FCO to search using configurable search screens Describe any user account management, audit, and reporting capabilities available to administrative users Provide an approximate schedule which may take into consideration, planning, installation, interface, System testing, implementation or any major task(s) Describe the tools and methodologies contractors may use for testing. Describe any major risks which may be involved in implementing a statewide Incident Tracking System and actions that should be taken to mitigate these risks Page 6 of 23

7 Vendor should be able to validate recommended requirements, hardware and third-party software indicated to host and operate the Incident Tracking System software. Vendor should include training service options for users of the proposed System, application administrators, and IT support staff. Vendor should recommend maintenance and technical support services with consideration of: o Telephone and access to contractor engineers and technical support staff, o Solution diagnostics and troubleshooting, o Product alerts, bulletins, and o Product updates as patches, enhancements, and new releases. F. Hardware and COTS Software FDLE requires high uptime; therefore hardware and software designs must be robust and offer redundancy with no single points of failure. Since robust designs drive costs up, to assist FDLE in its information-gathering effort, multiple designs should be provided to illustrate the tradeoff in costs and service levels. Describe and list the hardware and commercial-off-the-shelf (COTS) software needed to complete the project Describe and list the hardware and software needed to provide ongoing operations for the System Provide a description of System management tools. List the tools by System function (for example, security, database maintenance, scheduling, System monitoring and reporting) G. Standards To comply with statutory requirements, grant guidelines, and to ensure future compatibility and scalability, FDLE requires vendors to meet the standards as detailed in section C, Objectives. According to new provisions of Chapter 282, Florida Statutes, all reports submitted to the FCO will be classified as confidential information and not available for public record disclosure. Reports will not be further disseminated without the consent of the appropriate agency ISMs. H. Staffing Requirements Describe potential contractor and FDLE staff positions that may be recommended to complete the project. Include a description of the specific qualifications recommended for both a contractor and FDLE staff. An onsite project manager will be required and should be factored into the completion of the project. All project work must occur at the FDLE headquarters located at 2331 Phillips Road in Tallahassee, Florida. No data will be allowed off-site. All data will remain within the FDLE headquarters in Tallahassee, Florida. Page 7 of 23

8 Background investigations will be completed on all contractors before work can begin. Equipment and third-party software required to host and operate the Incident Tracking System software is not in scope for this engagement. FDLE plans to acquire equipment and third-party software through other suppliers. However, the Vendor is required to provide the specifications for the hardware. I. Training Provide a detailed overview of the training services for the proposed system including: Training requirements & strategy System administrator training End user training J. Technical Support Provide details on how the system will be supported, specifically: Onsite support options/personnel requirements Helpdesk/call center support Support resources Proposed service levels & incident response times K. Version Control Provide details of what technologies and processes could be used for version control within the recommended/proposed System. Describe how new releases, patches, hotfixes, and other updates could be tested and promoted from test to production. Concurrent Versions System (CVS) is used by FDLE and would be the preferred solution. L. Corporate Capabilities Provide a brief description of corporate capabilities, including: How long the company has been doing work related to incident tracking Information about similar comprehensive Incident Tracking System Projects previously completed CMMI, ISO, or other certifications V. RESPONSE INSTRUCTIONS AND FORMAT Please submit one electronic copy to the Procurement Officer noted in Section XI below no later than the time and date noted in the Section VII., Timeline. Responses must reference the RFI No.: FDLE RFI 1524 in the subject line of the response submission. The Vendor should organize their response submittal contents as follows: Tab 1 Introduction Page 8 of 23

9 Tab 2 Requested Information and Responses Tab 3 Sample Pricing Information Tab 4 Additional Information o o TAB 1 Introduction Provide a cover letter, the Vendor s primary point of contact and contact information (name, title, address, telephone number(s), fax number and an address) TAB 2 Requested Information and Responses (Please reprint each request with your response) The Department s intent is to identify potential Vendors that can fulfill the functional requirements listed on Attachment #1. Vendors should address all of the hardware, software, services, and functional requirements identified in this RFI. o TAB 3 Sample Pricing Information PLEASE DO NOT PROVIDE A SPECIFIC PRICE QUOTE. To preserve your ability to bid on a future procurement related to this RFI it is important to provide general pricing information only (i.e., competitive ranges and variables impacting price; not a specific price quote.) o TAB 4 Additional Information Provide additional information Vendor believes FDLE should consider regarding this project. VI. PROCESS Responses to this RFI will be reviewed by the Department for informational purposes only. A Vendor s response to this Request for Information is not an offer and FDLE will not use the Vendor s submission to justify a contract with that Vendor without otherwise complying with Chapter 287, F.S., and Chapter 60A-1, F.A.C. FDLE Investigations & Forensic Sciences is requesting information, and will review the responses received from this RFI, for purposes including, but not limited to, determining whether or not to competitively procure a solution, determining what solicitation process to use for a particular need, or researching general, special, and/or technical specifications for a solicitation. Page 9 of 23

10 FDLE anticipates offering Vendors the opportunity to schedule a presentation of proposed software capabilities. Vendors may be notified and provided instruction for demonstration specifications in accordance with Section VII, Timeline. Trade secrets are confidential and exempt from disclosure under Chapter 119, F.S., pursuant to the statutory provisions in F.S , F.S and F.S If Vendor claims trade secret information is required to demonstrate their product, their meeting will be deemed confidential and closed to other vendors and the public. Vendors submitting a response to an agency s Request for Information are not prohibited from responding to any related subsequent solicitation. VII. TIMELINE Listed below are important dates/times on which actions must be taken or completed. If the Department finds it necessary to update any of the dates/times noted, it will be accomplished by an Addendum to the RFI. All times listed below are local time in Tallahassee, Florida. DATE TIME ACTION 02/13/15 RFI posted on Vendor Bid System (VBS) 03/06/15 5:00 PM ET Vendor Questions Due, by 5:00PM ET 03/13/15 FDLE Posts Reponses to Questions (Anticipated Date) 03/27/15 3:00 PM ET Vendor Responses Due 04/08/15 Schedule Vendor Demonstrations (if applicable) 04/14/15 Begin Vendor Demonstrations (if applicable) VIII. RFI QUESTIONS AND CONTACT WITH THE STATE Questions may be submitted via . Questions will not be answered via telephone. The Department will post answers to questions received on the Vendor Bid System in accordance with Section VII. Please direct any questions or issues regarding this RFI to the Procurement Officer identified herein. The Agency will post amendments to this RFI on the Florida Vendor Bid System at: Each Respondent is responsible for monitoring the VBS for new or changing information. Page 10 of 23

11 IX. VENDOR COSTS Vendors are responsible for all costs associated with the preparation, submission, and any potential meeting to discuss this Request for Information. The State of Florida, Department of Law Enforcement, or Investigations & Forensic Science Program will not be responsible for any vendor-related costs associated with responding to this request. X. CONFIDENTIAL, PROPRIETARY OR TRADE SECRET MATERIAL The Department takes its public records responsibilities as provided under Chapter 119, Florida Statutes and Article I, Section 24 of the Florida Constitution, very seriously. If Vendor considers any portion of the documents, data or records submitted in response to this RFI to be confidential, trade secret or otherwise not subject to disclosure pursuant to chapter 119, Florida Statutes, the Florida Constitution or other authority, Vendor must also simultaneously provide the Department with a separate redacted copy of its RFI, on CD, and briefly describe in writing the grounds for claiming exemption from the public records law, including the specific statutory citation for such exemption. This redacted copy shall contain the Department s RFI name, number, and the name of the Vendor on the cover, and shall be clearly titled Redacted Copy. The Redacted Copy shall be provided to the Department at the same time Vendor submits its response to the RFI and must only exclude or obliterate those exact portions which are claimed confidential, proprietary, or trade secret. The Vendor shall be responsible for defending its determination that the redacted portions of its RFI response are confidential, trade secret or otherwise not subject to disclosure. Further, Vendor shall protect, defend, and indemnify the Department for any and all claims arising from or relating to Vendor determination that the redacted portions of its RFI response are confidential, proprietary, trade secret or otherwise not subject to disclosure. If Vendor fails to submit a Redacted Copy with its response, the Department is authorized to produce the entire documents, data or records submitted by Vendor in answer to a public records request for these records. XI. PROCUREMENT OFFICER Diana K. Trahan, CPPB, FCCM, FCCN Office of General Services/Purchasing 2331 Phillips Road Tallahassee, Florida Telephone No.: (850) / Fax No.: (850) FDLEOGSCONTRACTS@fdle.state.fl.us This contact person is the only authorized individual to respond to RFI comments and questions. Page 11 of 23

12 ATTACHMENT 1 The following sections list the requirements for the new Incident Tracking System are categorized by functions the system will be required to perform. 1.1 Functional and Non-functional Requirements Data Collection Capabilities This section includes requirements which will enable the system to collect data from various state agencies in a uniform manner. The input capabilities will allow for both single incident input, as well as for consolidated input of multiple minor incidents (which will include the number and type of incidents for that entry) General Collection Capabilities Requirements that are consistent among data sources ITS - 1 The system shall provide a web-based form to collect incident information. ITS - 2 The system shall be able to treat certain fields as available for public reports, while making other fields unavailable for public reports Requirements for collecting data submitted by ISMs ITS - 3 ITS - 4 ITS - 5 ITS - 6 ITS - 7 ITS - 8 ITS - 9 The system shall allow single incidents to be added, modified and deleted. The system shall allow aggregate incidents to be added, modified and deleted. The system shall capture the following for aggregate incidents: the number of incidents, a free text subfield for the type of malware and the date range in which they were added. The following data fields will be collected: Agency Incident Number, Agency, Incident Date, Date Reported to ISM, Date Confirmed as Security Incident, CISRT Issued Date, Incident Description, Category, Type of Malware, Malware Name, Agency CSIRT Level, Incident Manager, Status, Date Closed, Reported to AST/FDLE, Resolution. The system will generate an ID sequence number. The system shall indicate the following fields are being required: Agency Incident Number, Agency, Date Reported to ISM and Category. The system shall allow entry of two optional fields for the Agency Incident Number, including a multi-value field for type of number and a free text field for the value. ITS - 10 The system shall allow more than one Incident to be entered with the same Agency Incident Number. ITS - 11 ITS - 12 ITS - 13 ITS - 14 ITS - 15 ITS - 16 The system shall allow a maximum of 25 characters for the Malware Name. The Date Reported to AST/FDLE should be a date picker on the incident form. The following fields will be a dropdown: Category, Type of Malware, Agency CSIRT Level, Corrective Action and Status. The CSIRT Issued Date should be an alphanumeric field. The following shall be free text fields: Incident Description, Type of Malware and Resolution. The system shall collect the following fields for reporting: Source IP, MAC Address, Server Name, Mainframe, Operating System, Database Name and Platform, Data Type and Page 12 of 23

13 Infrastructure Component. ITS - 17 ITS - 18 ITS - 19 ITS - 20 ITS - 21 ITS - 22 The system shall allow the user to add attachments to the incident once the incident is submitted. The system shall not allow deletion or revision after an incident is submitted but shall allow a new incident to be added. The system shall contain an indicator that there are attachments for a particular incident. The system shall provide hover over notes for all the data collection fields. The system shall allow a maximum of 256 characters for the Incident Description. The system shall be able to extract data from standardized reports provided by major security software providers MS-ISAC (Multi-State Information Sharing & Analysis Center) Collection ITS - 23 The system shall receive Alert and Advisory notifications from one or more MS-ISAC addresses for further processing Data Processing Capabilities This section describes the requirements for the system to process input from state agencies, from initial entry of an incident through closing the incident. This includes, but is not limited to, any requirements for the system to help data entry by automatically filling out certain data elements or providing multiple values for users to choose General Data Processing Capabilities Requirements for the entire system ITS - 24 ITS - 25 ITS - 26 ITS - 27 ITS - 28 ITS - 29 ITS - 30 ITS - 31 ITS - 32 ITS - 33 ITS - 34 The system shall provide a search for the Malware Name. The system shall auto-generate the Agency field with the agency s name upon login. The system shall allow the Category field to generate subcategories. The subcategory will be mandatory if there is a category selected. The system shall allow the user to enter an explanation for deleting an incident. The Incident Description shall display a disclaimer warning user not to include personal information. The system shall populate the Date Closed when the incident is closed. The following fields shall be generated as system dates: Date Closed and Reported to AST/FDLE. The system shall populate the Report to AST/FDLE date when the form is submitted. The system shall allow the Status to be modified. The system shall provide a method to search for deleted incidents MS-ISAC Processing Requirements ITS - 35 ITS - 36 ITS - 37 ITS - 38 For advisory s, the system shall be able to differentiate the following advisory category levels: Amber and White and Green. The Green notification should be combined with the White notification. The key to identifying the level is indicated in the . For alert s from MS-ISAC, the system shall be able to differentiate processing based on the source and/or the subject of the . The system shall send the notifications to a distribution list provided by the FCO. For advisories, the system shall be able to parse MS-ISAC s to extract the date, category Page 13 of 23

14 (Amber, White and Green), subject and ticket#. ITS - 39 ITS - 40 For advisories, the system will allow the administrator to have them automatically distributed, or to change this function to manual, so the administrator can add additional information to the before distribution. The system shall allow only the Administrator to enter the Action Taken Data Storage Capabilities This section describes what needs to be stored by the system, and any rules pertaining to the storage of that data General Data Storage Capabilities ITS - 41 ITS - 42 ITS - 43 ITS - 44 ITS - 45 ITS - 46 ITS - 47 ITS - 48 ITS - 49 ITS - 50 ITS - 51 ITS - 52 ITS - 53 The system shall store the original incident. The system shall flag deleted records as delete. The system shall retain the incident tracking reports for 4 years. The system shall store the corrective actions along with a free text field. Per Legal Counsel, the system shall store the original incident reports in an unmodified format. The intent is that reports can be reviewed but not edited. The system shall store single incidents. The system shall store multiple Incidents. The system shall store the following for multiple incidents: the number of incidents, a free text subfield for the type of malware and the date range in which they were added. The system shall store data fields, such as: Agency Incident Number, Agency, Incident Date, Date Reported to ISM, Date Confirmed as Security Incident, CISRT Issued Date, Incident Description, Category, Type of Malware, Malware Name, Agency CSIRT Level, Incident Manager, Status, Date Closed, Reported to AST/FDLE and Resolution, Source IP, MAC Address, Server Name, Mainframe, Operating System, Database Name and Platform, Data Type and Infrastructure Component. The system shall be able to identify individual fields as being available for inclusion in public releases, or non-public release fields. The system shall store the ID sequence number. The system shall be able to store a field to describe the type of an optional Agency Incident Number, such as: IG Case Number, Audit Number, (LE) Law Enforcement Number, Ticket Number, (IG) Chief Inspector General Number and Other as a free text field for the identifier value. The system shall store the duplicate Incident that has the same Agency Incident Number. ITS - 54 The system shall be able to accommodate fields stored as codes values, such as: Type of Malware, Agency CSIRT Level, Agency, Status, and Corrective Action MS-ISAC Data Storage Requirements ITS - 55 ITS - 56 ITS - 57 The system shall store data parsed from notifications. The system shall store attachments from MS-ISAC s. The system shall allow only the Administrator to enter the Action Taken. Page 14 of 23

15 Audit Log Capabilities This section describes what auditing data should be stored by the system. ITS - 58 ITS - 59 ITS - 60 The system shall capture and store the original incident entry, User ID of who entered the incident and all modifications to the incident including date, date/time, Incident ID, Agency Incident Number, Value Before the Change and the Value After the Change and the User ID of who change the incident. The system shall log the date of each change, the Incident ID, the Agency, the CSIRT Level, the Category and the Status. The system shall capture the explanation and details of incidents that are deleted Reporting Capabilities This section describes the reports that the system should provide General Reporting Capabilities ITS - 61 The system shall be capable of generating customized reports based on some of the data fields captured from ISM submissions (e.g., a report based on the Type of Malware, which will be one of the data fields).. ITS - 62 The system shall allow Agencies to report no reports this month for any incidents for the month to meet reporting requirements Notification Capabilities The sections describes the notifications that the system will provide under certain circumstances, including the type, medium of the notification, as well as who will receive it. ITS - 63 ITS - 64 ITS - 65 ITS - 66 ITS - 67 The system shall send an notification to AST/FCO when the incident status is changed. The system shall send an notification to AST/FCO when the incident is deleted. The system shall send an notification to the user to reset their password. The system shall not allow a user to access the application if the reset password failed. The system shall send an notification to AST/FCO when an incident is changed. Page 15 of 23

16 Dashboard Capabilities This section describes what information is to be displayed to the users. The type of data displayed in the dashboard will depend on the type of user (e.g., agency ISM). ITS - 68 ITS - 69 The system shall provide a dashboard on the landing page. The system shall be able to display a variety of data and information on the dashboard, (e.g., the: Total Number of Incidents Reported, a link to produce an Executive Summary (see section , below) for closed incidents, Incident Report with detailed information, and Aggregate Statistics from all reporting state agencies, Bulletins from AST/FFC and other news on other agencies without disclosing agency specific information, and links to the latest MS-ISAC advisories with the ability for the user to download these. ITS - 70 The system shall display a Public Record disclaimer on the landing page MS-ISAC Advisory Notifications This section describes the Advisory notifications that are receive from MS-ISAC and the process of how they should be received. ITS - 71 ITS - 72 ITS - 73 ITS - 74 ITS - 75 ITS - 76 ITS - 77 For advisories, the system shall store data from the notification. The system shall send the advisory notifications to a distribution list provided by the FCO. The system shall store the attachments. For advisories, the system shall display the subject line of the five most recent notifications on the dashboard and link to the advisory . For advisories, the system shall allow users to view the notifications from the dashboard. For advisories, the system shall have the capability to download the advisory notifications from the dashboard. The system shall not allow the alerts to be visible by all users. ITS - 78 For alerts, the system shall have the capability to search the notification by the subject field, ticket number, and IP address Executive Summary Capabilities For each closed incident, the system should be able to generate an on-demand summary that includes non-confidential information about the incident that may be disseminated to the public. ITS - 79 ITS - 80 ITS - 81 ITS - 82 The Executive Summary should include the following: The version of the Executive Summary (date/time stamp), Status confirmed, completed and published, and Corrective Action. The system shall allow the user to print the Executive Summary as a PDF. The system shall only generate an Executive Summary on demand. The system shall not allow the Executive Summary to be printed if the incident is not closed Data Migration General Data Migration Requirements ITS - 83 ITS - 84 The current incident data in the Excel spreadsheet and SharePoint should be migrated into the new Incident Tracking System. The system shall migrate the MS-ISAC notifications from an excel spreadsheet. ITS - 85 The system shall migrate the notifications from an excel spreadsheet. Page 16 of 23

17 1.1.6 Security Capabilities General Security Requirements ITS - 86 ITS - 87 ITS - 88 ITS - 89 ITS - 90 ITS - 91 ITS - 92 ITS - 93 ITS - 94 ITS - 95 ITS - 96 ITS - 97 ITS - 98 ISM shall have the capability to enter and modify any field, except auto-generated fields only for their agency. The system shall not allow an ISM to delete an incident. The system shall allow an ISM to add attachments to an incident. The system shall allow the ISM to list corrective actions taken. The system shall allow the Application Administrator the capability to add additional codes to the code table. The system shall allow the Application Administrator the capability to change, update and delete any field. The system shall not allow the Application Administrator to add new incidents. The system shall not allow the Application Administrator who is also an ISM to log into the system to perform both roles. The system shall allow multiple roles for users. The system shall have a reset password procedure that includes a challenge question to answer. The system will operate on the Internet using Secure Socket Layers (SSL). The system shall allow the Agency Inspector General to have the same access as ISM. The system shall allow the Inspector General read-only access. The system shall allow ISM the capability to change the Status. Page 17 of 23

18 ATTACHMENT 2 FEDERAL BUREAU OF INVESTIGATION CRIMINAL JUSTICE INFORMATION SERVICES SECURITY ADDENDUM Legal Authority for and Purpose and Genesis of the Security Addendum Traditionally, law enforcement and other criminal justice agencies have been responsible for the confidentiality of their information. Accordingly, until mid-1999, the Code of Federal Regulations Title 28, Part 20, subpart C, and the National Crime Information Center (NCIC) policy paper approved December 6, 1982, required that the management and exchange of criminal justice information be performed by a criminal justice agency or, in certain circumstances, by a noncriminal justice agency under the management control of a criminal justice agency. In light of the increasing desire of governmental agencies to contract with private entities to perform administration of criminal justice functions, the FBI sought and obtained approval from the United States Department of Justice (DOJ) to permit such privatization of traditional law enforcement functions under certain controlled circumstances. In the Federal Register of May 10, 1999, the FBI published a Notice of Proposed Rulemaking, announcing as follows: 1. Access to CHRI [Criminal History Record Information] and Related Information, Subject to Appropriate Controls, by a Private Contractor Pursuant to a Specific Agreement with an Authorized Governmental Agency To Perform an Administration of Criminal Justice Function (Privatization). Section 534 of title 28 of the United States Code authorizes the Attorney General to exchange identification, criminal identification, crime, and other records for the official use of authorized officials of the federal government, the states, cities, and penal and other institutions. This statute also provides, however, that such exchanges are subject to cancellation if dissemination is made outside the receiving departments or related agencies. Agencies authorized access to CHRI traditionally have been hesitant to disclose that information, even in furtherance of authorized criminal justice functions, to anyone other than actual agency employees lest such disclosure be viewed as unauthorized. In recent years, however, governmental agencies seeking greater efficiency and economy have become increasingly interested in obtaining support services for the administration of criminal justice from the private sector. With the concurrence of the FBI s Criminal Justice Information Services (CJIS) Advisory Policy Board, the DOJ has concluded that disclosures to private persons and entities providing support services for criminal justice agencies may, when subject to appropriate controls, properly be viewed as permissible disclosures for purposes of compliance with 28 U.S.C We are therefore proposing to revise 28 CFR 20.33(a)(7) to provide express authority for such arrangements. The proposed authority is similar to the authority that already exists in 28 CFR 20.21(b)(3) for state and local CHRI systems. Provision of CHRI under this authority would only be permitted pursuant to a specific agreement with an authorized governmental agency for the purpose of providing services for the administration of criminal Page 18 of 23

19 justice. The agreement would be required to incorporate a security addendum approved by the Director of the FBI (acting for the Attorney General). The security addendum would specifically authorize access to CHRI, limit the use of the information to the specific purposes for which it is being provided, ensure the security and confidentiality of the information consistent with applicable laws and regulations, provide for sanctions, and contain such other provisions as the Director of the FBI (acting for the Attorney General) may require. The security addendum, buttressed by ongoing audit programs of both the FBI and the sponsoring governmental agency, will provide an appropriate balance between the benefits of privatization, protection of individual privacy interests, and preservation of the security of the FBI s CHRI systems. The FBI will develop a security addendum to be made available to interested governmental agencies. We anticipate that the security addendum will include physical and personnel security constraints historically required by NCIC security practices and other programmatic requirements, together with personal integrity and electronic security provisions comparable to those in NCIC User Agreements between the FBI and criminal justice agencies, and in existing Management Control Agreements between criminal justice agencies and noncriminal justice governmental entities. The security addendum will make clear that access to CHRI will be limited to those officers and employees of the private contractor or its subcontractor who require the information to properly perform services for the sponsoring governmental agency, and that the service provider may not access, modify, use, or disseminate such information for inconsistent or unauthorized purposes. Consistent with such intent, Title 28 of the Code of Federal Regulations (C.F.R.) was amended to read: Dissemination of criminal history record information. a) Criminal history record information contained in the Interstate Identification Index (III) System and the Fingerprint Identification Records System (FIRS) may be made available: 1) To criminal justice agencies for criminal justice purposes, which purposes include the screening of employees or applicants for employment hired by criminal justice agencies. 2) To noncriminal justice governmental agencies performing criminal justice dispatching functions or data processing/information services for criminal justice agencies; and 3) To private contractors pursuant to a specific agreement with an agency identified in paragraphs (a)(1) or (a)(6) of this section and for the purpose of providing services for the administration of criminal justice pursuant to that agreement. The agreement must incorporate a security addendum approved by the Attorney General of the United Page 19 of 23

20 States, which shall specifically authorize access to criminal history record information, limit the use of the information to the purposes for which it is provided, ensure the security and confidentiality of the information consistent with these regulations, provide for sanctions, and contain such other provisions as the Attorney General may require. The power and authority of the Attorney General hereunder shall be exercised by the FBI Director (or the Director s designee). This Security Addendum, appended to and incorporated by reference in a government-private sector contract entered into for such purpose, is intended to insure that the benefits of privatization are not attained with any accompanying degradation in the security of the national system of criminal records accessed by the contracting private party. This Security Addendum addresses both concerns for personal integrity and electronic security which have been addressed in previously executed user agreements and management control agreements. A government agency may privatize functions traditionally performed by criminal justice agencies (or noncriminal justice agencies acting under a management control agreement), subject to the terms of this Security Addendum. If privatized, access by a private contractor's personnel to NCIC data and other CJIS information is restricted to only that necessary to perform the privatized tasks consistent with the government agency's function and the focus of the contract. If privatized the contractor may not access, modify, use or disseminate such data in any manner not expressly authorized by the government agency in consultation with the FBI. Page 20 of 23

21 FEDERAL BUREAU OF INVESTIGATION CRIMINAL JUSTICE INFORMATION SERVICES SECURITY ADDENDUM The goal of this document is to augment the CJIS Security Policy to ensure adequate security is provided for criminal justice systems while (1) under the control or management of a private entity or (2) connectivity to FBI CJIS Systems has been provided to a private entity (contractor). Adequate security is defined in Office of Management and Budget Circular A- 130 as security commensurate with the risk and magnitude of harm resulting from the loss, misuse, or unauthorized access to or modification of information. The intent of this Security Addendum is to require that the Contractor maintain a security program consistent with federal and state laws, regulations, and standards (including the CJIS Security Policy in effect when the contract is executed), as well as with policies and standards established by the Criminal Justice Information Services (CJIS) Advisory Policy Board (APB). This Security Addendum identifies the duties and responsibilities with respect to the installation and maintenance of adequate internal controls within the contractual relationship so that the security and integrity of the FBI's information resources are not compromised. The security program shall include consideration of personnel security, site security, system security, and data security, and technical security. The provisions of this Security Addendum apply to all personnel, systems, networks and support facilities supporting and/or acting on behalf of the government agency. 1.1 Definitions 1.2 Contracting Government Agency (CGA) - the government agency, whether a Criminal Justice Agency or a Noncriminal Justice Agency, which enters into an agreement with a private contractor subject to this Security Addendum. 1.3 Contractor - a private business, organization or individual which has entered into an agreement for the administration of criminal justice with a Criminal Justice Agency or a Noncriminal Justice Agency. 2.1 Responsibilities of the Contracting Government Agency. 2.2 The CGA will ensure that each Contractor employee receives a copy of the Security Addendum and the CJIS Security Policy and executes an acknowledgment of such receipt and the contents of the Security Addendum. The signed acknowledgments shall remain in the possession of the CGA and available for audit purposes. 3.1 Responsibilities of the Contractor. 3.2 The Contractor will maintain a security program consistent with federal and state laws, regulations, and standards (including the CJIS Security Policy in effect when the contract is executed), as well as with policies and standards established by the Criminal Justice Information Services (CJIS) Advisory Policy Board (APB). 4.1 Security Violations. 4.2 The CGA must report security violations to the CJIS Systems Officer (CSO) and the Director, FBI, along with indications of actions taken by the CGA and Contractor. 4.2 Security violations can justify termination of the appended agreement. 4.3 Upon notification, the FBI reserves the right to: Page 21 of 23

22 5.1 Audit a. Investigate or decline to investigate any report of unauthorized use; b. Suspend or terminate access and services, including telecommunications links. The FBI will provide the CSO with timely written notice of the suspension. Access and services will be reinstated only after satisfactory assurances have been provided to the FBI by the CJA and Contractor. Upon termination, the Contractor's records containing CHRI must be deleted or returned to the CGA. 5.2 The FBI is authorized to perform a final audit of the Contractor's systems after termination of the Security Addendum. 6.1 Scope and Authority 6.2 This Security Addendum does not confer, grant, or authorize any rights, privileges, or obligations on any persons other than the Contractor, CGA, CJA (where applicable), CSA, and FBI. 6.3 The following documents are incorporated by reference and made part of this agreement: (1) the Security Addendum; (2) the NCIC 2000 Operating Manual; (3) the CJIS Security Policy; and (4) Title 28, Code of Federal Regulations, Part 20. The parties are also subject to applicable federal and state laws and regulations. 6.4 The terms set forth in this document do not constitute the sole understanding by and between the parties hereto; rather they augment the provisions of the CJIS Security Policy to provide a minimum basis for the security of the system and contained information and it is understood that there may be terms and conditions of the appended Agreement which impose more stringent requirements upon the Contractor. 6.5 This Security Addendum may only be modified by the FBI, and may not be modified by the parties to the appended Agreement without the consent of the FBI. 6.6 All notices and correspondence shall be forwarded by First Class mail to: Assistant Director Criminal Justice Information Services Division, FBI 1000 Custer Hollow Road Clarksburg, West Virginia Page 22 of 23

23 FEDERAL BUREAU OF INVESTIGATION CRIMINAL JUSTICE INFORMATION SERVICES SECURITY ADDENDUM CERTIFICATION I hereby certify that I am familiar with the contents of (1) the Security Addendum, including its legal authority and purpose; (2) the NCIC 2000 Operating Manual; (3) the CJIS Security Policy; and (4) Title 28, Code of Federal Regulations, Part 20, and agree to be bound by their provisions. I recognize that criminal history record information and related data, by its very nature, is sensitive and has potential for great harm if misused. I acknowledge that access to criminal history record information and related data is therefore limited to the purpose(s) for which a government agency has entered into the contract incorporating this Security Addendum. I understand that misuse of the system by, among other things: accessing it without authorization; accessing it by exceeding authorization; accessing it for an improper purpose; using, disseminating or re-disseminating information received as a result of this contract for a purpose other than that envisioned by the contract, may subject me to administrative and criminal penalties. I understand that accessing the system for an appropriate purpose and then using, disseminating or re-disseminating the information received for another purpose other than execution of the contract also constitutes misuse. I further understand that the occurrence of misuse does not depend upon whether or not I receive additional compensation for such authorized activity. Such exposure for misuse includes, but is not limited to, suspension or loss of employment and prosecution for state and federal crimes. Printed Name/Signature of Contractor Employee Date Printed Name/Signature of Contractor Representative Date Organization and Title of Contractor Representative Page 23 of 23