SOURCES SOUGHT
70 -- Tracking Managing Extracts from Secure Sytems. Sensitive Agency Information. Personally Identifiable Information (PII)
- Notice Date
- 7/17/2007
- Notice Type
- Sources Sought
- NAICS
- 334111
— Electronic Computer Manufacturing
- Contracting Office
- General Services Administration, Federal Technology Service (FTS), Office of Information Security (TI), 7th & D Streets, S.W., Room 5060, Washington, DC, 20407, UNITED STATES
- ZIP Code
- 20407
- Solicitation Number
- Reference-Number-GSA-TFI-2007-018
- Response Due
- 8/13/2007
- Point of Contact
- Jon Faye, Contracting Officer, Phone (202) 708-6099, Fax (202) 708-7800, - Howard Parker, Jr., Contracting Officer, Phone (202) 401-7139, Fax (202) 708-7027,
- E-Mail Address
-
jon.faye@gsa.gov, howard.parker@gsa.gov
- Description
- RFI Title: Tracking and Managing Extracts from Secure Systems. Sensitive Agency Information. Personally Identifiable Information (PII). Action: It is requested that information relating to current solutions and future implementations of applications, tools, appliances, and associated procedures to address managing tracking, reporting, and erasure of Sensitive Agency Information, extracted from databases and other controlled systems and environments as directed by OMB M-06-16 be provided to GSA as result of issuance of this RFI. Disclaimer: This RFI is issued solely for information and planning purposes and does not constitute a solicitation. In accordance with FAR 15.201(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Respondents are solely responsible for all expenses associated with responding to this RFI. Respondents needing confidential treatment for any proprietary information they furnish must comply with the SEC confidential treatment regulations at 17 C.F.R. 200.83. Responses to this RFI will not be returned. Respondents will not be notified of the result of the review. GSA is providing this RFI on behalf of another Federal Agency. Summary: The tracking, managing, protecting, and erasure of Sensitive Agency Information, particularly Personally Identifiable Information (PII), extracted from a controlled IT environment such as data stores and databases are of significant interest to the Federal Government. Security breaches from several Federal Agencies over the past two years resulting in unauthorized release of PII have heightened the need for a focused solution. Office of Management and Budget (OMB) memorandum M-06-16, Protection of Sensitive Agency Information (SAI), identifies four Action Items addressing defensive IT controls to assist in maintaining elevated security environments for Sensitive Agency Information. Action Item #4 recommends all Federal Agencies Log all computer-readable data extracts from databases holding sensitive information and verify each extract including sensitive data has been erased within 90 days or its use is still required. Addressing this Action Item within the variety of Federal Agency IT environments and unique organizational needs will require an integrated and intelligent solution from industry. An effective, cost efficient, operational solution is the goal of this RFI. Federal Agency data stores and information repositories include legacy and new technologies span the enterprise, and include mainframes, Storage Area Networks/Network Attached Storage (SAN /NAS), databases, file servers, email servers, etc. and potentially, web and application servers. As technology evolves, so Federal IT diversity expands. With government growth, so grows the need to share data in a controlled, secure manner. Thus, authorized systems, applications, and scripts extract and share information from a multitude of Agency repositories with a plethora of stakeholders. Agencies and their organizations must manage these information transfers, and endow both parties with the confidence that information is safe and maintained within understood bounds and paradigms. However, problems arise as information moves farther from an Agency core and beyond its central control. Once out of managed, secure data repositories and traversing beyond the reach of established alerting and access controls, disparate protection methods no longer provide adequate insight or management. How secure is Personally Identifiable Information once it has entered this unstructured environment? Where it moves, who accesses it, or what manipulations are done to it can no longer be established nor controlled. New tools are needed that extend Enterprise information oversight and protection into less structured environments. Technology is needed that can determine how this information is stored and dispersed, to manage data deletion compliance after it is no longer required; and thus secure information to the degree within, or on-par with, the original repository. Address: GSA FAS Assisted Acquisition Services (TFI) Acquisitions and Contracts Management 301 7th Street SW Room 5060 Washington, DC 20407-0001 Further Contact Information: Attn: Jon D. Faye Contracting Officer Based on OMB June 23, 2006 release of memorandum M-06-16, the GSA is requesting responses from industry corporations, scientists, researchers, and organizations that represent the Information Technology (IT) industry data leakage, tracking and management community, on how best to implement a solution to identify, track, manage, log, report, and erase Sensitive Agency Information (SAI), particularly Personally Identifiable Information (PII), extracted from databases and other controlled environments, within Agency, and its sub-organization, IT architectures, as it traverses and settles across the Enterprise. The GSA requests descriptions of industry approaches, practices, and capabilities to provide the services requested in this RFI. Responses shall address listed objectives, and not be used to provide marketing material. Vendors shall explain how their solution and/or products will meet the goal of achieving OMB M-06-16, Action Item #4. Vendors shall explain if their products meet this requirement out-of-the-box, if customization and integration is required, as well as in-whole or in-part. Vendors are also encouraged to propose alternative approaches that may be different than the generic solution outlined in this RFI. However, the various solution components and/or target points of data extraction and subsequent storage must be addressed. For purposes of this RFI, the term Personally Identifiable Information (PII), defined by OMB M-06-19, means any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual identity, such as their name, social security number, date and place of birth, mothers maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. Based on the various IT environments implemented across Federal Agencies, and in coordination with Federal Enterprise Architecture requirements and recommendations, a solution that can integrate with existing Agency architectures is envisioned. Thus, the solution must be versatile, allowing placement of components or software in conjunction with a variety of IT environments. These environments include, but are not limited to mainframes, SAN/NAS, databases; file, email, web and application servers; etc., and the tape archival systems that support them. Additionally, environments will include workstations, portable devices such as laptops, Personal Digital Assistant (PDA), Universal Serial Bus (USB) devices, and media such as DVDs and CDs. Functions within the vendor solution shall monitor PII extractions and archive tracking data (date and time SAI was removed, entities performing the extract, and extracted data or its representation). Any SAI or PII stored within solution components or sent between components shall be protected, possibly through encryption or some other mechanism, according to federal security standards. There shall be proactive solution processes implementing compliance of Federal recommendations for erasure/removal of SAI within 90 days from the date the information is no longer needed. The solution shall have a central management component/console which tracks, records, consolidates and correlates, and may initiate pre-determined actions on SAI. The management component therefore, shall provide reporting of all solution functions. A. PII Monitoring and Managing Solution Objectives The high level objectives of this RFI are summarized as follows. 1. Data security controls shall be an integral process/function to the proposed solution addressing Federal confidentiality, integrity and availability requirements. 2. Ability to identify or tag, and log SAI data removed/extracted from secure IT data repositories. 3. Ability to manage (log, track, monitor, and report) PII as it traverses across, and outside of, the Enterprise Architecture in various electronic forms. 4. Ability to manage various electronic data formats, including database extracts, images, *.pdf files, text and spreadsheet documents. 5. Ability to manage (log, track, monitor, and report) PII for any pending distributions such as email, instant messaging, web posting, CD creation, etc. of PII, and potentially prevent distribution. 6. Ability to accommodate previously encrypted data traversing the Enterprise. 7. Ability to manage identified PII to determine any reconfiguration either by conversion (saving data in whole or in part into another file format) or by dissection and infusion (cut and paste) from one format or document type to another. 8. Ability to track and manage PII database extracts over time in accordance with Federal and Agency retention policies (erasure within 90 days (or some configurable period), or designated as still being required). Solutions should address user nodes ??? e.g. workstation, laptop, PDA, and other secondary repositories. 9. Ability to automate alerting of PII existence after 90 days (or some configurable period) if PII is no longer needed. 10. Ability to automate the proactive erasure/relocation of PII in accordance with retention requirements and policy. 11. Ability to consolidate monitoring and tracking results at a management component/console that maintains an intelligent, on-going record of data extracts, their location, users/nodes having these extracts, and storage duration. 12. Ability to scan in coordination with, and report to, a central management component. 13. Ability to perform proactive scanning of network segments or specific nodes for PII creation, storage, and compliance with time-based erasure/relocation/archival requirements and policy. 14. Ability to perform reactive scanning of network segments or specific nodes for known data extractions, data replications, and compliance with time-based erasure/relocation/archival requirements and policy. 15. Ability to control access to PII data stored or transmitted by solution components providing confidentiality, integrity and proper availability. 16. Ability to protect, possibly through encryption, SAI stored on solution components. 17. Ability to protect, possibly through encryption, communications between solution components. 18. Ability to integrate with existing Identity Management Access Control methodologies (PKI Certificates, Tokens, etc.). 19. Ability to track and report PII when written to portable storage and media. B. Supplemental Objectives 1. Ability, once data has been identified or tagged, to protect it from unauthorized release or distribution. 2. Ability to report and provide metrics on occurrences and quantities of SAI or PII data elements (Social Security Number (SS#), address, DOB, financial data, etc.). 3. Ability to report and provide metrics of the most significant user, program, or other criteria; e.g. creator of PII material, or program with most extracted material, etc. 4. Ability to encrypt data written to portable storage. 5. Ability to accommodate disconnected end-user devices within the solution, e.g. either by reporting disconnected devices containing SAI at last connection, or once reconnected rescanning devices for previous or new SAI content. 6. Ability to manage (log, track, monitor, report and erase) remote extractions of SAI and PII from the Enterprise, or the sharing of SAI and PII between Agencies. In addition to the typical descriptive reply, vendors shall respond by listing the objective above with their response to immediately follow, thus assisting assessors who evaluate the degree of objective achievement. Pricing: Vendors shall provide pricing information (GSA pricing, if available) to allow the government to understand and forecast costs involved in implementing the vendor solution by individual hardware and software components. Example of vendor pricing model may include: 1) license cost per server/node, 2) cost per number of server/nodes, or database monitored, 3) cost per appliance. Vendor shall also provide volume discounts presenting expected pricing and implementation costs for various sized organizations. Organizations for this effort, addressing a corresponding amount of infrastructure, shall be very small (~50 users), small (~500 users), medium (~ 5000 users), and large organizations (~50,000 users). Vendors shall provide all assumptions. Request for Information All responses must be submitted by e-mail to Jon.Faye@GSA.GOV, in accordance with the following instructions: 1. Responses should be in Microsoft Word format and should include each vendor name, address, and contact information. 2. Responses should, at minimum, address the objectives by providing policies, procedures, processes, and/or technologies to be deployed. 3. Responses should include any necessary policy and management controls references that fulfill objectives not met by, or work in conjunction with, proposed products and services. 4. Responses should describe the company experience and qualifications with regard to the products and services described in their proposed solution. 5. Responses should identify other Government agencies and private companies, including points of contact and their contact information, using the vendor products or solution. 6. Responses should include any past performance, certifications, etc. that the company may have with regard to their proposed solution. The RFI response may reference a website, magazine article, or other published literature and may include graphics, charts, white papers, or other supporting material. However, the response should specifically address the RFI objectives and how the vendor solution accomplishes these objectives. Broadly applicable marketing material, while helpful as background, would not be sufficient, and may not be reviewed. 7. Vendors are encouraged to discuss how their solution correlates to the presented solution concept. Responses need not be limited by the architecture or technology described. Partial solutions are acceptable. 8. Responses should include a vendor point of contact for product evaluation. 9. The company should also identify in their response any GSA Schedule contracts or other Government-Wide Agency Contracts (GWAC) that it may have under which these products or services can be acquired. 10. Responses submitted for this RFI may be forwarded to a contractor for evaluation. Responses are subject to FOIA request; as such any proprietary information not meant for public dissemination should be excluded. 11. All responses must be received at e-mail address: Jon.Faye@GSA.Gov no later than August 13, 2007, reference RFI number GSA-TFI-2007-018. Supplemental Information: PII Monitoring and Managing Solution Concept Federal Agencies have an extremely wide variety of operational environments across their various enterprises, and therefore require flexible, versatile solutions. The description below and Diagram 1, PII Monitoring and Management Solution Concept, provides visual perspective and insight into a possible solution to the described scenario. Insert Diagram 1, PII Monitoring and Management Solution Concept here??? Example Scenario Agency mission information is located in various enterprise repositories, the largest being their mainframe. Data maintained and protected within various logical partitions contains PII data collected while achieving the agency, and its sub-organization, missions. A nightly script accesses several databases and extracts data, containing PII, for consolidation and future application processing. Days later, analysts within the Agency access this consolidated information from an application server through a thick client, transferring data with PII to their workstations. As the agency has vague rules prohibiting PII removal, an analyst exports several data sets, and copies them to a CD for transport to another office. In this scenario PII exists in four locations (the mainframe database, application server, workstation, and CD); and on potentially three devices that do not control access in accordance with permissions established on the original databases (workstation, CD, and depending on the permissions assigned, application server). The distribution (writing PII to CD) accommodates PII removal from the Agency physical as well as logical protections without accommodating for its management. In order to comply with M-06-16 in the above scenario, a solution would need to address the following: 1. Identify PII upon extraction from the mainframe and application server databases; 2. Track and manage PII located on the analysts workstations; 3. Track, manage, and protect PII distributed to portable media (CD); 4. Manage PII establishing the ninety-day erasure period, and on the ninetieth-day announcing the need to erase (or performing erasure/relocation); 5. Monitor/scan the workstation to determine if identified PII remains, was distributed, reconfigured or deleted/relocated; 6. Securely report changes in PII to the scanning application or management component; 7. Scan workstations periodically to determine if new PII exists, or was distributed; and, 8. Collect and intelligently present status of PII located throughout the enterprise. PII Monitoring and Managing Solution Concept Components Vendor responses need not be limited by the architecture described herein. Solutions that involve some of the components described, or seek to address the above objectives in a totally different manner, are welcome. Partial solutions are acceptable. Solutions allowing for options addressing this situation, such as component/service cafeteria-style selection, to meet various objectives and needs is acceptable. Descriptions of how the complete implementation of policy, products and services will be deployed in an Enterprise environment are encouraged. The following are functional descriptions of solution concept components. 1. The PII Monitoring Appliance. A PII Monitoring Appliance shall have the ability to be placed in front of, or in conjunction with, various data repositories throughout the Enterprise (mainframes, SAN/NAS, databases; file, email, web and application servers). As PII data is extracted from a repository it shall be identified; along with a date/time stamp, the credentialed individual who or authorized process that performed the extraction; and reported to the management component/console for subsequent management (log, track, monitor, report, and erasure). This component would allow integration across significantly varied architectures. Communications between components shall be secure. 2. The PII Monitoring Application. A PII Monitoring Application shall perform similar functions as the Monitoring Appliance but do so on an end-node (workstation, laptop, server, PDA, etc.). It shall also confirm the existence of previously identified PII, and scrutinize the system for any PII reconfiguration activities such as copy/paste to other data formats (database extracts into Word documents, spreadsheets; images files, etc.), as well as PII creation and generation. The Monitoring Application shall detect data replication to any portable storage (CD/DVD, USB, etc.), or supplemental enterprise storage such as a network drive. Additionally, the Monitoring Application would monitor for any pending distributions such as email, instant messaging, web posting, etc. of PII, and potentially prevent this distribution. PII distributions and attempts shall be reported to a management component/console. Communications between components shall be secure. This Component should allow the end user to group related PII and manage collectively to reduce administrative efforts. 3. The PII Management Component/Console. A PII Management Component/Console shall provide the ability to set criteria for identification of PII. This component shall consolidate, store and present in an intelligent and efficient manner the location and status of PII identified or tagged from extraction points, to secondary storage, to end user nodes. This component shall have the ability to consolidate tracking of PII movement throughout the Enterprise, log PII data manipulation; and provide consolidated management views/reports of PII status per node, per user, per project, etc. The PII management component/console must also be able to direct the scanning appliance to perform scans, and maintain these results. Scan results shall be coordinated with previous scan results to provide further information and insights. Information shall have the ability to be sorted, filtered, and analyzed thus providing an Enterprise perspective. The PII Management Console shall provide reporting, trending, and graphing capabilities. Communications between components shall be secure. 4. The PII Scanning Appliance. A PII Scanning Appliance shall perform scans on specific network segments, devices, and nodes, as directed by the management component/console. All results would be presented to the management component/console for long-term storage, management, analysis, and reporting. Communications between components shall be secure. Disclaimer This RFI is issued solely for information and planning purposes and does not constitute a solicitation. In accordance with FAR 15.201(e), responses to this notice are not offers and cannot be accepted by the Government to form a binding contract. Respondents are solely responsible for all expenses associated with responding to this RFI. Respondents needing confidential treatment for any proprietary information they furnish must comply with the SEC confidential treatment regulations at 17 C.F.R. 200.83. Responses to this RFI will not be returned. Respondents will not be notified of the result of the review. NOTE: THIS NOTICE MAY HAVE POSTED ON FEDBIZOPPS ON THE DATE INDICATED IN THE NOTICE ITSELF (17-JUL-2007). IT ACTUALLY APPEARED OR REAPPEARED ON THE FEDBIZOPPS SYSTEM ON 30-AUG-2007, BUT REAPPEARED IN THE FTP FEED FOR THIS POSTING DATE. PLEASE CONTACT fbo.support@gsa.gov REGARDING THIS ISSUE.
- Web Link
-
Link to FedBizOpps document.
(http://www.fbo.gov/spg/GSA/FTS/TI/Reference-Number-GSA-TFI-2007-018/listing.html)
- Place of Performance
- Address: To be determined.
- Zip Code: 20407
- Country: UNITED STATES
- Zip Code: 20407
- Record
- SN01391650-F 20070901/070830230919 (fbodaily.com)
- Source
-
FedBizOpps Link to This Notice
(may not be valid after Archive Date)
| FSG Index | This Issue's Index | Today's FBO Daily Index Page |