SOURCES SOUGHT
58 -- Internet Data Collection and Processing system
- Notice Date
- 1/10/2012
- Notice Type
- Sources Sought
- NAICS
- 334210
— Telephone Apparatus Manufacturing
- Contracting Office
- Department of Justice, Drug Enforcement Administration, Office of Acquisition Management, None, Washington, District of Columbia, 20537
- ZIP Code
- 20537
- Solicitation Number
- DEA-12-STII-0001
- Archive Date
- 2/1/2012
- Point of Contact
- Ghazala Shabnam, Phone: 703-495-6674
- E-Mail Address
-
ghazala.x.shabnam@usdoj.gov
(ghazala.x.shabnam@usdoj.gov)
- Small Business Set-Aside
- N/A
- Description
- THIS IS A REQUEST FOR INFORMATION (RFI) FOR THE PURPOSE OF CONDUCTING MARKET RESEARCH. THIS IS NOT A REQUEST FOR A SOLICITATION. NO CONTRACT WILL BE AWARDED AS A RESULT OF THIS RFI. This is a Request for Information (RFI). The purpose of this RFI is to gather information about commercially available solutions that meet the requirements outlined below and can provide the functionality of a Internet Data Collection and Processing system for use by the United States Drug Enforcement Administration (DEA) to conduct investigations which involve the legal intercept of electronic communications with content (Title III of the Omnibus Crime Control and Safe Streets Act of 1968), and information about electronic communications (Pen Register Trap and Trace - also known as PEN). This is not a RFI for Research and Development (R&D) or systems that may be developed at DEA expense, but rather a request for inputs about systems that are commercially available and meet most if not all of the requirements specified in this document. Term Notes: In the context of this RFI the term: - "provider" refers to a company or business offering electronic communication services such as telephone, cellular, internet, email, VOIP, etc. - "target" is used to reference a single lawfully monitored entity which may be associated with communications identifier such as an IP address, phone number, account number, web site, email address, etc. - "case" is used to represent a container for multiple "targets" by which the "targets" may be associated with each other in such a way as to share/deny access to collected data as well as provide a contextual frame of reference for the collected data. - "processing" refers to the reassembly of packet data into the original files or xml formatted representations of the original files; or the parsing and/or transformation of structured text (xml or delimited) and unstructured text files into individual file representations of the intended data types (email, html, documents, etc.). - "automatic" or "automatically" refers to a file or data processing operation which occurs without human intervention beyond initial configuration. - "monitor" or "monitoring" refers to the loading, collection, and/or processing application waiting for the arrival of new input to a folder (directory) in a file system or operating system port and acting upon the newly arrived data automatically. - "Processing Solution" refers to the subject of this RFI, which is a system that can provide the functionality of a lawful Internet Data Collection and Processing system. - "original data" or "source data" refers to the data as it was provided to the "Processing Solution" from the provider or other source external to the "Processing Solution" - "administrative user" refers to a user that is granted the authority to have full access to all administrative functions (configuration (monitors, logs, outputs, etc.), log viewing, adding other users, etc. ) of the "Processing Solution" - "CALEA" and "CALEA standard"- refers to the Communications Assistance for Law Enforcement Act (passed in 1994) and its associated standards for data capture and delivery to law enforcement. Please visit http://www.askcalea.net/standards.html for more information. - "3rd Party" - refers to any commercial or government organization that is not the owner/creator/ vendor of the "Processing Solution" REQUIREMENTS Data Collection and Processing 1. The "Processing Solution" shall accept and process cellular (mobile) provider data inputs a. Accept as input a single TCP data stream (to a monitored port) from a provider that contains cellular packet data for multiple numbers ("targets") and process the data into the original files or products that correspond to the original files (such as XML with content and schema). i. Segregate the input stream by individual phone number ("target") for configuration management and output ii. Provide each individual number's processed data as a structured data file output such as XML or delimited text that is, or fully represents, the original data. This is a requirement to allow other 3rd party viewing or analytical systems to ingest the data post processing. iii. File output must occur near real time from reassembly (processing) completion iv. Each file output from processing must have a corresponding hash value generated by a SHA-2 algorithm at the time it is created. The generated hash value must be persisted in such a way that it can be easily related back to its parent file. i. Input and output configuration and management must provide for the means to model the case/target container structure and be fully configurable by an administrative user. b. Perform item 1(a) for multiple providers (one stream for each) in multiple CALEA or other telecommunications standards including but not limited to the following i. TCP/FTP stream - ATIS/3GPP ii. TCP Stream - T1.IAS iii. TCP Stream - ETSI iv. TCP Stream - J STD 025B 2. The "Processing Solution" shall monitor for and process known (see 2a-2e) data files from any number of folders in a file system, or from ports, into the original files or products that correspond to the original files (such as XML with content and schema) and be written into equivalent data folders ("targets") on a file system. For example, the "Processing Solution" shall accept and process data from a folder on the file system called "\inputSample\JoeSample" and output to a specified folder called "\outputSample\JoeSample". Known data files and types include: a. PCAP, CAP, and PKT file output from IP collection tools such as "Wildpackets" or "Wire Shark" or other software. b. Email - RFC 5322, RFC 5321, RFC 2822, RFC 822 c. XML document files with agreed upon schemas which represent a file or product type acceptable by the "Processing Solution". Such XML files may represent, but are not limited to IP logs, email messages, text messages, chat messages, or other forms of communication or information about communications d. XML document files with agreed upon schemas and their associated support files pointed to by the xml document, which represent a file or product type ingestible by the "Processing Solution". For instance an XML file which represents a text message may have associated attachments such as photos or documents that are pointed to by the xml file. e. Delimited text files or other structured text files that contain single or multiple items which represent single or multiple files or product types which are acceptable by the "Processing Solution". Such text files may represent, but are not limited to IP address logs, email messages, text messages, chat messages, or other forms of communication or information about communications f. File monitoring shall be automatic and continuous or at a very short interval (under a minute) g. File output must be automatic and occur near real time from processing completion. h. Each file output from processing must have a corresponding hash value generated by a SHA-2 algorithm at the time it is created. The generated hash value must be persisted in such a way that it can be easily related back to its corresponding file. i. Input and output configuration and management must provide for the means to model the case/target container structure for this output in a file system and be fully configurable by an administrative user. 3. The "Processing Solution" shall be able to accept and process files as described in item #2 on demand by an administrative user. 4. The "Processing Solution" shall be capable of automatically extracting all relevant metadata from the original source data and outputting it as structured text like xml for loading to other 3rd party systems for viewing, reporting, analysis, etc. This relevant metadata (when available) shall include: a. Associated IP addresses (source/destination/origination) b. Associated URL(s) or host name information (source/destination) c. Associated user names, handles, or email addresses included as senders or recipients of the source communication d. Product Dates (sent, received, timestamps) e. Source file information (source or original file name if any, creation date, etc) f. File type or category that allows for easy identification of the output (examples: EMAIL, IMAGE, HTML, TEXT MESSAGE, CHAT, IP LOG) g. Other file source information 5. The "Processing Solution" shall provide configurable logging for monitoring, processing and loading as well as error recording and also provide administrative access to the logs. Data Organization and Reconstruction 6. The "Processing Solution" shall be able to represent a "case"/"target" model for setup, monitoring, loading, persistence, output, organization, and user/administrative security. See the "Term Notes" under the "Synopsis" for the definition of "case/target" in this context. 7. The "Processing Solution" shall reconstruct and output collected data as files in such a way that it is precisely, or very closely, representative of the data as it existed at its source or origin. For Example: a. Reassembled web page data shall be or precisely represent the original web page with associated products (images, audio, documents, links, etc) and viewable in a 3rd party browser or browser like viewing experience. NOTE: Uncollected data that was not contained in the original inputs (streams, pcap files, etc) such as images, supporting pages, videos, audio, etc, shall never be downloaded from the Internet to fill in uncollected information. b. Reassembled image data shall be whole (as collected) and output as an image file in the same format as it was originally collected or in a precisely representative format and viewable in a 3rd party viewer that supports the format type. c. Audio data shall be reassembled whole (as collected) and output in a file format and audible in a 3rd party media player that supports the format type. d. Video data shall be reassembled whole (as collected) and output in a file format that is viewable, and audible in a 3rd party media player that supports the format type. e. Chat data shall be reconstructed and output in such a way as to represent a "conversation" (to the extent possible during the collection and reassembly period) in a structured text format like xml that can provide for association of chat participants, attachments, and messages that are part of the source data. f. Text Message (as distinct from chat) data shall be reassembled and output as a "conversation" (to the extent possible during the collection period) in a structured text format like xml that can provide for association of participants, attachments, and messages that are part of the source data. g. Email data shall be reassembled or parsed and output in such a way as to be viewable in a third party viewer with all the source data and meta data to include recipients, sender, date, subject, and content (when present) with attachments (if present). Email shall be rendered in a structured text format like xml or as the current standard in item #2b (.eml file). h. Other types of content data not described in items 6a-6g shall be reassembled in a similar fashion to precisely represent their origin. 8. Log, Session, and other human to machine, machine to human, or machine to machine communication meta data shall be reconstructed as structured text (xml, csv) and viewable in 3rd party application that supports the format. 9. Source or original pre-processed data and metadata (when persisted) shall be made available as file output on demand by an administrative user. This applies in particular to any potential "Processing Solution" that persists the original and pre-processed data (and metadata) in a database or similar relational storage mechanism. This is separate functionality from the "real-time" post processing output. 10. The "Processing Solution" shall keep and not destroy or dispose of data that was not recognized, decoded, decrypted or reassembled properly by the processing mechanisms. Furthermore it shall organize and persist the data in such a way as to be recognizable as unclaimed or unknown data and viewable as source data (in a hex viewer or other suitable binary viewer) to an Administrative user. 11. The "Processing Solution" shall provide all file output as either the source data file as intercepted (examples:.eml,.htm(l),.jpeg,.mpeg,.txt, etc) or in a non-proprietary (not encoded, encrypted, or serialized) structured text format (xml, csv) that represents the complete source file. Application Scalability and Portability 12. The "Processing Solution" shall provide cellular data stream auto processing (see item #1) in the following ratios and times: a. Process one to n-number of "targets" from a single stream to a monitored port from a single provider b. Provide for item 9(a) for m-number of providers c. Process data in near real time (from when it is received at the processing point) 13. The "Processing Solution" shall provide PCAP, CAP, PKT, Email and other "known" structured file type input and auto processing (see item #2 ) in the following ratios and times: a. Process n-number of files from a monitored "target" folder or port in near real time or in the case of files at a configurable interval which can approach near real time. b. Provide for item 10(a) for m-number of "targets" contained within l-number of "cases" c. Process data in near real time (from file receipt) 14. The "Processing Solution" shall provide manual file processing (see item #3) in the following ratios: a. Processes n-number of files selected by an administrative user from a single folder for a single "target" on demand b. Provide for file processing for all files in a folder selected by an administrative user 15. The "Processing Solution" shall run on Microsoft Windows 2008 Server (64bit) and any generations which follow and preferably be capable of running in a virtualized environment. Data Transportation and Storage Integrity 16. Provide for file hashing at the point of first receipt or where first created by the "Processing Solution" and persist the generated file hash in such a way as it easily identifiable with its mated file. 17. Ensure that the first file created at point of receipt (in the case of port inputs) is kept unaltered and separate from processed data and provide a means for verifying that it is unaltered (See item 14.) 18. Provide for file hashing at processing output point and persist the generated file hash in such a way that it is identifiable with the mated output file. Additional Administrative Functionality 19. The "Processing Solution" shall provide a graphical user interface which runs on Microsoft Windows, or in a Browser supported by MS Windows, through which an administrative user can perform administrative maintenance, setup, and configuration of the "Processing Solution". For example: configure cases and targets; setup monitored folders and ports with appropriate input data type associations and output folders; add and delete users; view log files; load and process data; etc. 20. The "Processing Solution" shall provide a mechanism for another software application to supply administrative information for setting up and maintaining configurations for monitoring, processing, and output. This should be accomplished through an Application Programming Interface (API) or exposed methods made available through a service like a web service. A fully capable API is preferred. 21. The "Processing Solution" shall provide a means of backing up and restoring all of the configuration data which is necessary for it to be recovered and fully operational without manually re-entering all of the configuration data. RESPONSES This is a Request for Information (RFI). This is not a solicitation, award or request for proposals and does not obligate the government to award a contract. All responsible businesses, including small businesses, are encouraged to respond to this RFI. The Drug Enforcement Administration (DEA) Office of Investigative Technology (ST) is conducting market research and requests input from industry to assist in requirements planning. The DEA will not be responsible for any cost incurred by interested parties in responding to this RFI. Any and all associated costs shall be expended solely at the expense of the responder. Unsolicited proposals or offers of any kind will not be considered in response to this RFI. All information received in response to this RFI that is marked proprietary will be handled accordingly. Responses to the RFI will not be returned. At this time, questions concerning the composition and requirements for a future RFP, as well as those regarding the nature of the services to be performed under any future initiative will not be accepted. Email responses to this RFI to Ghazala.X.Shabnam@usdoj.gov by January 31, 2012. Responses must include the following information: 1. Company name; mailing address; physical address; point of contact; telephone number; fax number; email address; DUNS number; NAICS code; company business size (if small indicate type); and GSA schedule number (if applicable) 2. A corporate or company capability statement between one and 10 pages that includes relevant experience within the past three years. Relevant experience is defined as possessing the experience described in the "Requirements" section above. The capability statement should include a technical description of the software and/or hardware, the licensing capabilities and requirements (for enterprise and standalone), and maintenance and other contractor support services required for the government installation and support of all items related to the software and/or hardware system. 3. A representative sample of contracts your firm was awarded to provide the requirements as described in this notice within the past three years. For each contract listed include the type of contract; total estimated value; contract period of performance (e.g., base and number of option periods); customer (i.e. federal agency) and respective point of contact (e.g., point of contact's name, phone number, and email address). 4. Published documentation about the system to include manuals, white papers and other technical documentation (if available). 5. A rough order of magnitude of pricing for software and/or hardware under the described licensing models.   The Government encourages creativity and innovation in responses to this RFI. The North American Industry Classification System (NAICS) code applicable to this requirement is 334210 - Telephone Apparatus Manufacturing, with a size standard in number of employees of 1,000. Interested parties are requested to submit the above requested information directly via e-mail to: Ghazala.x.Shabnam@usdoj.gov no later than January 31, 2012. Any responses received after the closing date will not be considered. No literature will be returned to responding sources and each source is solely responsible for all expenses associated with submitting their literature. All information will be kept confidential and will not be disseminated to the public.
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/spg/DOJ/DEA/OAM/DEA-12-STII-0001/listing.html)
- Record
- SN02651650-W 20120112/120110234248-91141ac755265c5ac1fb11cca6bb6efa (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 |