SOURCES SOUGHT
D -- Lawful Data Intercept Collection, Analysis & Minimization System (ICAMS)
- Notice Date
- 5/24/2011
- Notice Type
- Sources Sought
- NAICS
- 511210
— Software Publishers
- Contracting Office
- Department of Justice, Drug Enforcement Administration, Office of Acquisition Management, None, Washington, District of Columbia, 20537
- ZIP Code
- 20537
- Solicitation Number
- DEA-11-ST-RFI-0002
- Archive Date
- 6/17/2011
- 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. The Drug Enforcement Administration (DEA) is currently performing a market survey to determine potential vendors (small or large) to gather information about commercially available solutions that meet the "requirements" outlined below and can provide the functionality of a lawful data intercept collection, analysis, and minimization system for use by the United States Drug Enforcement Administration (DEA) to conduct investigations which involve the legal intercept of electronic communications, and information about electronic communications. Term Note: In the context of this RFI the word "provider" refers to a company offering electronic communication services such as telephone, cellular, internet, email, VOIP, etc. The word "target" is used to reference a single monitored facility or communications identifier such as an IP address, phone number, account number, web site, email address, etc. The word "case" is used to represent a container for multiple "targets" by which the "targets" may be associated with each other, share/deny access, and provide a context for common functionality such as reporting, analysis, and viewing. The term "minimization" refers to the process of determining which intercepted (collected) communications products are relevant to a court ordered ongoing investigation. The term "pertinence" shall be used to refer to the designation of a collected product as pertaining to/or not pertaining to an ongoing investigation or to classify a product as being protected under legal privilege (such as client/attorney). REQUIREMENTS Data Collection and Loading 1. Handle streaming cellular (mobile) data feeds a. Handle a single TCP data stream from a provider that contains cellular packet data for multiple numbers ("targets") - Segregate the stream by individual number ("target") - Provide each individual number as a file output (this should allow other vendors to process the files downstream into other viewing or analytical systems) - Ingest and reassemble each file as data input available under its corresponding "target" number b. Perform item 1(a) for multiple providers (one stream for each) in multiple standards including the following - TCP/FTP stream - 3GPP - TCP Stream - T1 IAS - TCP Stream - ETSI - TCP Stream - J STD 025B 2. Auto load "known" data files and types from any number of monitored folders into equivalent data containers ("targets") in the application (for example a monitored folder called "JoeSample" will "load" data into a visible container called "JoeSample". Known data files and types include: a. PCAP, CAP, PKT file output from IP collection tools such as "Wildpackets" or "Wire Shark" b. Email (RFC- 822 w/MIME, MAPI, HTML) c. XML data files with agreed upon DTD d. XML metafiles with agreed upon DTD and their associated files e. Delimited text files f. Files generated in item #1 of this document (ETSI, J-STD-25B, etc) All accompanying metadata shall be extracted and persisted with the product for viewing, reporting, analysis, and exporting. This meta data (when available) shall include: g. Mulitiple associated IP addresses (one product to zero, one or many ips) h. Multiple urls (one product to zero, one or many urls) i. Product Date (one to zero or one) j. Product File Name (one to one) k. Product File Size (one to one) l. Associated Files (one product to zero, one or many associated files) m. Product "type" (one product to one product type - examples: EMAIL, IMAGE, WEB PAGE, etc) n. Product Source (Provider or processing method if provider is not known) **Note: Auto load monitoring shall be continuous or at a very short interval (under a minute) 3. Provide for auto-loading and viewing of any files that are associated with a predefined published xml based complex data type (c. and d. in item #2 of this document). As an example the xml data type may include the following fields (attributes and properties) for each file product: a. Mulitiple associated IPS (one product to zero, one or many ips) b. Multiple urls (one product to zero, one or many urls) c. Product Date (one to zero or one) d. Product File Name (one to one) e. Product File Size (one to one) f. Associated Files (one product to zero, one or many associated files) g. Product "type" (one product to one product type - example EMAIL, IMAGE, WEB PAGE, etc) h. Product Source (Provider or processing method) This would allow users to process custom data and produce this data type for loading and viewing as needed without the vendor needing to develop a processer/loader. Reports, analysis, minimization and normal features shall be able to be generated from this data. **Note: This information (a-h) shall be acquired and persisted for all products where it is available 4. Allow for "a-la-cart" loading of all files within a folder (or zip file) for viewing, translating, etc. 5. Start/Halt auto-loading and/or collection of data based on predefined dates for the monitored "target" 6. Make it apparent to the user that a data load has totally or partially failed 7. Log data processing and Loading Data Organization and Reconstruction 8. The application shall be able to represent a "case"/"target" model for data loading, persistence, viewing, organization, and user security a. User permissions such as viewing and creating metadata shall be assignable and enforceable within the "case"/"target" model b. Other general application features described in this document shall fall under this scheme 9. Allow for categorization and selection of data by product "types" or attributes including: a. IP (IP address and URL trees or lists with aggregates)) b. Email (email addresses tree or list with aggregates) c. Text (user name, conversation with aggregates) d. Chat (user name, conversation with aggregates) e. File Types (file extensions with aggregates) f. Unknown or Unclaimed (shall be viewable and include compressed, encoded or encrypted data) 10. Notify the user through the Graphical User Interface (when present) that new data has been auto loaded to a "case"/"target" if that user has permission to the "case"/"target" with new data (see item #8) 11. Allow for the marking and persisting of data as "read", "unread", "pertinent", "non-pertinent" and "privileged" or some equally representative nomenclature for the concept of pertinence (see the "Term Note" at the beginning of this document) a. Access to various pertinent and privileged data shall be controllable by user or role permissions (see item #7) b. The "pertinence" marking shall be changeable c. The changes of "pertinence" shall be logged by user and auditable d. Automatically export "pertinent" marked data products to a folder on the file system by "case"/"target" 12. Reconstruct collected data in such a way that it can be viewed (or heard for audio products), printed, exported (and imported) in an organized format similar to the way it was at its origin a. Http data shall be viewable as a web page or text file (including extended character sets) in a browser or browser like viewing experience. NOTE: Uncollected data (images, videos, audio, etc) shall not be downloaded from the internet to fill in web pages when viewed b. Image data shall be whole and viewable as a standalone image file (see item 14) c. Audio data shall be whole and audible in a media player d. Video data shall be whole, viewable, and audible in a media player (built in, native, or third party) e. Chat data shall be available as a "conversation" (to the extent possible during the collection period) f. Text data shall be available as a "conversation" (to the extent possible during the collection period) g. Email shall be viewable in a browser or email view with to, from, date, subject, and content with attachments if present; raw view shall be available that shows the full file content in a text view (shall be able to handle extended character sets) h. Log, Session, and other machine initiated or machine to machine communications shall be reconstructed as text, xml, or html as appropriate 13. Resolve IP addresses acquired from products and persist the information for reporting and viewing (see item #2 and 2(g)) Data Export and Archive 14. Provide for Export/Archive Functionality a. Auto export of pertinent products as the collected product type (ex. Jpeg, bmp, wav, html, pdf, txt, or equivalent representation) with translation reports/notes (see item #10) b. Manual full "native" export/archive of "case"/"target", search results, or selected data to be used for the explicit purpose of importing back into the application as needed - Shall export all meta data about the product into a meta file along with the product in its native file format - Shall have the option of removing data from the system that is exported (archive) - Shall be importable back into the application by loading the produced meta-file and accompanying files - Imported data shall retain its state from the exported system (ex. Pertinence, translations) c. "Light" export of products for "case"/"target", search results, or selected data - Exports a subset of meta data about each product (pertinence, date, filename, size, product type, etc) into a "list" that is viewable in a common internet browser and provide a link to each product in the "list" - Each product shall exported into its native file format (or viewable/audible equivalent) and viewable/audible using a third party application appropriate for the file type such as an image viewer, media player, word processor, browser, etc. 15. Raw or "original" non processed data shall be unaltered and available for burning to ROM (DVD, BlueRay, etc); Shall be able to be deleted after burning or permanent ROM storage is accomplished Application Scalability and Portability 16. Cellular data stream auto processing (see item #1) a. Process one to n-number of "targets" from a single stream from a single provider b. Provide for item 21(a) for m-number of providers c. Process data in near real time (from when it is received at the processing point) 17. PCAP, CAP, PKT, Email and other "known" file type auto processing (see item #2 and #3) a. Process n-number of files from a monitored "target" folder at a user specified interval b. Provide for item 22(a) for m-number of "targets" contained within l-number of "cases" c. Process data in near real time (from file receipt) 18. Manual file processing (see item #4) a. Processes n-number of user selected files a single target b. Provide for single folder or recursive sub folder file processing for n-number of files in m-number of folders 19. Provide for enterprise level networked functionality a. Centrally process and load data for m-number of cases with n-number of targets b. Provide for network connected clients (in the same network security model - Microsoft Active Directory or subsequent MS security model) to view, generate meta information, create reports, export, import, and perform analysis on the same centrally loaded/stored data (constrained by the client's current user security scope - i.e. the "case"/"target" permission model and user name within the governing user security model) 20. Provide for single instance (stand alone) functionality a. Provide for the loading of processed data files onto a single machine for m-number of cases and n-number of targets contained "within" each case b. Provide for viewing, generating meta information, report creation, exporting, importing and performing analysis on data loaded on the single machine with the user's security scope ("case"/"target") c. Operate in a local (workstation) security environment 21. Run on the following Operating Systems and generations that follow a. Microsoft Windows XP (Professional) b. Microsoft Windows 2003 (Server) c. Microsoft Windows 7 (Professional) d. Microsoft Windows 2008 (Server) Data Transportation and Storage Integrity 22. Provide for file hashing at the point of first receipt or where first created by the application and persist the generated file hash 23. Provide for file hashing at each processing point of output and persist the generated file hash 24. Provide for file hash comparison, or other dependable means for ensuring file copies transacted during the processing or transport of files are consistent and unchanged from source to destination 25. Ensure that originally received data is kept unaltered and separate from processed data and provide a means for verifying that it is unaltered (ex. Digital signature) 26. Data provided for viewing, reporting, exporting, and analysis (processed data) shall be traceable back to its collected or original source file Additional General User Initiated Functionality 27. Allow for the creation of translation reports to be associated with a data product (these shall be exportable with their associated products - see item #11) 28. Allow for the creation of notes or comments about a product (these shall be exportable with their associated products) 29. Extract "tags" (Meta data such as location information, date-time, camera model, etc) out of images (when available in the image) at user request and display them for the user 30. Easy point and click viewing of new (unread/newly loaded) data for minimization or real time monitoring purposes while also supporting more advanced data analysis for analysts (see item #31) 31. Allow for the creation of charts and reports about product meta-data with appropriate filters (including "case"/"target", pertinence, date ranges, product types (see item #8) etc) a. Frequency occurrence information for IP addresses, phone numbers, email addresses, URLs, user names, file extensions, location, etc b. Link information such as frequency of communication between phone numbers, ip addresses, email address, users names, data sources, etc c. Aggregation of same-type products by probability (or certainty) of relationship (example: continuing text or chat conversations) d. Canned reports for relevant periods of time (ex. 10 day report by "pertinence") e. Ad hoc or custom reporting capabilities f. Reports shall be exportable as PDF, XML, and CSV Files Users shall be able to access products directly from reports, charts, and or frequency and relationship displays. 32. Provide for keyword searching of products and return the search results for viewing a. Search full file content (for plain text, xml, html or other text based files) b. Search translations/notes (see item #26 and #27) c. Search product meta data d. Filter by date/time, product type/category, etc e. Search results shall be constrained by the user's "case"/"target" permissions (see item #8) 33. Allow the user to create (and delete) a "container" for persisting search results or selected products a. Users shall be able to add and remove products b. Users shall be able to search the user folders (see item #31) c. Search results shall be added automatically to the user folder RESPONSES This is a Request For Information (RFI). This is not a solicitation. All responsible businesses, including small and large 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. 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 511210 - Software Publishers, with a size standard of $25.0 Million. Interested parties are requested to submit the above requested information directly via e-mail to: Ghazala.x.Shabnam@usdoj.gov no later than June 15, 2011. 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-11-ST-RFI-0002/listing.html)
- Place of Performance
- Address: Drug Enforcement Administration, Lorton, Virginia, 22192, United States
- Zip Code: 22192
- Zip Code: 22192
- Record
- SN02455949-W 20110526/110524235033-3f89ac5177af1440112901a28e2d9a79 (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 |