| 70 -- Technical Media Analysis Tool |
| Program Summary |
 |
| Title: |
70 -- Technical Media Analysis Tool |
| GovCB Opps ID : |
ADP12001468890002735 |
| Document Type: |
Sources Sought Notice |
| FSC Code: |
70 - General Purpose Information Technology Equipment (including software).
|
| NAICS Code: |
511210 - Software Publishers |
| Solicitation No.: |
Reference-Number-TMAT |
| Source: |
http://www1.fbo.gov/spg/DISA/D4AD/DITCO/Reference%2DNumber%2DTMAT/SynopsisR.html |
Posted Date:
|
Jan 12, 2008 |
| Last Update: |
Jan 12, 2008 |
| Due Date: |
Feb 11, 2008 |
|
| Description |
|
General Information
| Document Type: |
Sources Sought Notice |
| Solicitation Number: |
Reference-Number-TMAT |
| Posted Date: |
Jan 11, 2008 |
| Original Response Date: |
Feb 11, 2008 |
| Current Response Date: |
Feb 11, 2008 |
| Original Archive Date: |
Feb 26, 2008 |
| Current Archive Date: |
Feb 26, 2008 |
| Classification Code: |
70 -- General purpose information technology equipment |
| Naics Code: |
511210 -- Software Publishers |
Contracting Office Address
Defense Information Systems Agency, Procurement and Logistics, DITCO-Scott, 2300 East Dr. Building 3600, Scott AFB, IL, 62225-5406, UNITED STATES
Description
REQUEST FOR INFORMATION
(RFI)
Technical Media Analysis Tool
This Request for Information (RFI) is for a Technical Media Analysis Tool that will identify an attacker or the electronic address from where an attach is generated, support damage assessment, provide attack characterization that will support mitigation efforts and provide forensic data for use in the pursuit of legal action as warranted. Responses are due by Close of Business Feb 11, 2008 and should address the following:
1.0 SUBJECT
This document is a Request for Information (RFI) for a Technical Media Analysis Tool (TMAT) that can be deployed on selected host machines across the Department of Defense (DoD). Throughout the DoD, within the realm of military command, control, communications, computers and intelligence; the collection, exploitation and protection of sensitive information is critical. While methods have proven effective at countering identifiable threats originating from outside as well as inside network boundaries, a gap in capability that characterizes a cyber attack and attributes the source of a cyber attack has been identified, exposing the DODs vulnerability across the global infrastructure. This capability gap of Attribution and Response Action could adversely impact not only regional operations but potentially global operations and systems that support the warfighter. Historically, there has been less emphasis on the Attribution and Response Action to cyber attacks. Cyber-threats to the Global Information Grid (GIG) may vary significantly depending on an adversarys intent, technological capability and level of knowledge. Attacks launched from outside the enclave are increasing in frequency and currently the vast majority of protection and detection measures employed by both government and industry are focused at preventing external network attacks. However, there is an equal or potentially more damaging threat posed by those who have access to information systems and networks, and operate from within a network.
With regard to a TMAT capability, the targeted sector includes: 1) outside attackers, 2) outside attackers who have found a means to gain access to DOD computer assets and/or networks that are now acting from the inside, and 3) legitimate, authorized internal users. The primary applications of TMAT will be in the analysis of media to determine the identity of the attacker (the host machine, the individual user(s), the sponsoring state, or group), how the attack was conducted (attack vectors and methodologies), and the attackers intentions.
2.0 DESCRIPTION
The Defense Information Systems Agency (DISA), in support of the Computer Network Defense (CND) mission assigned to the United States Strategic Command (USSTRATCOM), is seeking information from industry, academia, and government that will assist in the acquisition of TMAT capabilities to enhance the CND posture of the DoD computer network systems. The required product is to analyze/examine non-volatile data such as a hard drive or system image (Dead Box), and also Live Box analysis/examination of running systems to acquire volatile data such as network connections and memory contents.
Live Box System:
Under TMAT, solution security products are selectively installed directly on network end points. In general, this means installing agent-based tools on targeted host machines (e.g., workstations, laptops, servers). In order to be effective across enterprise networks, host-based capabilities must be centrally managed to support installation, monitoring, updating, and configuration. The following is a description of potential system architecture for a live-box analysis:
Central Manager: The portion of the solution that provides the central management functionality is called the central manager. The central manager provides centralized installation, management, monitoring, and configuration of the host agent. This central manager primarily will reside within the local enclave but will also have Enterprise remote access. The central manager should use strong authentication for communication to the host agent over an encrypted session and use ports that are authorized through perimeter firewalls for remote connectivity.
Host Agent: The local host capability to communicate with the central manager is referred as the host-based agent or agent. The capabilities could be provided by either a single agent with multiple modules, the use of multiple agents/modules, or a combination of the two. The technical media analysis tool should gather user and system information on host machines to include volatile data.
Dead Box System:
In addition to the enhanced dynamic real-time analysis, there exists a need for off-line, dead-box comprehensive analysis. Dead-box analysis allows the analyst to conduct a more comprehensive examination to determine the malware utilized in the attack, the methodology of the attack, and possibly a damage assessment of the attack. Possible analysis would include:
- Discovery of web sites visited and determination of time spent viewing
- Recovery of deleted files, emails, and instant messages
- Analysis of malware methodology
- Analysis of intrusion methodologies
- String searches
- Password cracking
- Decrypt encrypted folders, files, and disks
- Analysis of targets computer and network usage
3.0 CAPABILITIES/REQUIREMENTS
This section describes the desired capabilities and requirements for the Technical Media Analysis Tool. Please address each capability/requirement and identify how closely you meet that capability/requirement. If you have a different solution with equivalent functionalities please address those functionalities. A solution with multiple products under a single manager is acceptable for the purpose of this RFI. Individual products with a subset of these capabilities are also of interest, and vendors and/or government organizations with these solutions are encouraged to respond to this RFI. While not all encompassing some of the envisioned TMAT capabilities and requirements may be:
General Requirements. The vendor should describe the desired information and operation characteristics of the environment.
1. The tool will operate in a controlled environment with access restrictions applied to the data gathered, the tools operation, and the tools software elements. Some of the features include the ability to ensure Confidentiality and Integrity of the software elements through self-protection mechanisms and access controls to limit the users to an identifiable select group. Additionally, the tool will protect the gathered information from unauthorized access and control its availability to select groups. All communications will be encrypted.
2. The solution shall not interfere with any applications or authorized system activities operationally required by system users or administrators. In addition the solution should not interfere with authorized patching and upgrades of operating systems and installed applications.
3. The solution will need to be capable of supporting and analyzing a large number of operating systems, and their associated file formats, employed by DoD. Among the systems are: Windows 2000, Windows XP, Windows 2003, Windows NT4 (SP6a), SOLARIS, HP-UX, Linux, and other UNIX variants.
4. The solution must be compatible with and not interfere with other approved CND tools (i.e. Anti-Virus, Anti-Spyware, and Host-Based Security System (HBSS), Secure Configuration Compliance Validation Initiative (SCCVI), and Secure Configuration Remediation Initiative (SCRI)).
5. The solution shall preserve the collected evidence in a proven forensically sound format that can be verified through a repeatable process. Information and data must be protected and preserved using industry standard and business best practices to ensure the security and traceability of the data.
6. The solution will create, maintain, and archive customizable audit logs, audit trails for all activities while limiting reviews of these logs to only authorized entities in a secure manner.
7. The solution should integrate with external hash databases for rapid identification and classification of applications, processes, drivers, system files, malware, etc.
Graphical User Interface (GUI)/Console Requirements. applies to the collector, correlator, and analysis engine or machine used to convert the collected user data into actionable information on specific user activities.
1. The Console is the central display and interaction point for the gathered data. The Console requires an operator-friendly display method that facilitates the decision process, provides real-time actionable information, alerts on behavior activities, and controls the interaction (refresh rate, bandwidth, etc) between all components.
2. During information gathering the Console is required to gather, display, and alert the operator based on parameters and templates that consist of both pre-defined, scripted, and operator-configured actions.
3. The console will make available operator configured, filtered, decision information for electronic interaction (i.e., data mining and keyword searches), electronic exchange (import/export) through industry standards (CSV, OBDC, XML, etc) as well as through customized and template reports and alerts.
Static Dead Box Requirements
1. The solution shall be able to manage, image, and produce forensically sound records and copies of all currently available electronic media (removeable/non-removeable) (i.e., hard drives, CD/DVD, USB storage media, floppy disk, PDAs, cameras, etc.), extract and enumerate serial numbers of hard drives and provide the capability to associate the acquired evidence with source media.
2. The solution shall have the ability to accurately acquire, identify, display, and manage data and information from targeted locations and record information concerning the target to include: user specified files by a hash; modification date/time based on system time, last accessed date/time file ownership and permission, file security attributes, both logical and physical location of a file files with modified extensions or mismatched headers
3. The system shall provide the capability to restart a failed acquisition from point of error without restarting the acquisition from scratch.
4. The system shall provide the capability to troubleshoot problematic media during the imaging process by being able to change error granularity.
5. The system shall selectively extract files from forensic image to export these files to local storage media both as a native file and/or an evidence container.
6. The system shall reconstruct and parse all modern and common client email files and attachments.
7. The system shall graphically identify, view, search, and recover data from media slack space.
8. The system shall identify and view data from medias unallocated space.
9. The system shall search and view specific user defined strings in media.
10. The system shall accurately identify all aspects of hard drive configuration, including the number of partitions/volumes cylinders, heads, and sectors on a drive.
11. The system shall accurately identify the number of files (based on file type) on the media.
12. The system shall produce user specific Internet browser history with timeline.
13. The system shall accurately display the contents of the Windows registry.
14. The system shall identify all services that automatically start during system boot.
15. The system shall accurately identify and list all potentially encrypted files on a device.
16. The system shall accurately identify all compressed files on a device both by file extension and file header.
17. The system shall mount and view all compressed files identified on a device.
18. The system shall compare file and image hashes, and report anomalies.
19. The system shall import and export file hashes in standard file formats.
20. The system shall identify specific file attributes, such as hidden files.
21. The system shall identify and recover data from files containing Alternate Data Streams (ADS)
22. The system shall work with large datasets and evidence files (terabyte).
23. The system shall view and recover deleted files, whole or partial, and automatically recover data from reformatted volumes
24. The system shall provide Unicode support for searching and reviewing foreign language files.
25. The system shall identify and parse link files from both allocated and unallocated space.
26. The system shall automatically enumerate registry for all relevant hardware information from source device.
27. The system shall display event logs.
28. The system shall display web server event logs.
29. The system shall provide capability to add external viewers for unsupported file types.
Live Box Analysis Requirements
1. The system shall acquire system information and forensic images locally or remotely in an encrypted and mutually authenticated manner from the central manager as directed when systems are present on the network such as removable media, laptops, or encrypted volumes.
2. The system shall capture and view volatile memory, process tables, network connection status and retrieve socket status (i.e., open, time wait) for all connections while the target system is running.
3. The system shall capture all local routing table information.
4. The system shall capture and view open files while the target system is running.
5. The system shall capture active libraries/modules while the target system is running.
6. The system shall capture and view open files associated with running processes.
7. The system shall identify libraries/modules that are injected into memory.
8. The system shall capture and view network interface card information while the target system is running.
9. The system shall capture and view user accounts information (i.e. SID, last logon time, currently logged on, etc) while the target system is running.
10. The system shall identify hidden processes while the target system is running.
11. The system shall identify start times for all running processes.
12. The system shall identify the full file path for all running processes.
13. The system shall identify the process command line switches for all running processes.
14. The system shall identify start times for all active libraries.
15. The system shall identify the full file path for all active libraries.
16. The system shall identify option flags or switches for all active libraries.
17. The system shall generate a hash of files corresponding to a running process.
18. The system shall generate a hash of active libraries/modules while the target system is running.
19. The system shall perform quick look review on selected systems capable of 50 systems simultaneously.
20. The system shall collect data without relying on the target operating system.
21. The system must be able to deploy and manage deployed agents through an encrypted connection independent of the DoD HBSS program
22. The system shall send instructions to deployed agents over a mutually authenticated and encrypted communication path for simultaneous execution of the identified commands
4.0 SAMPLE RESPONSE OUTLINE
This outline is intended to minimize the effort of the respondent and structure the responses for ease of analysis by the government. Respondents are free to develop their response accordingly, but should answer the fundamental questions provided.
Section 1. Product (limited to 15 pages, including diagrams and spreadsheets)
Describe a working product as a possible solution to meet the Technical Media Analysis Tool capabilities. Delineate how the product currently meets the stated capabilities and whether the solution is mature (i.e., publicly released) or in developmental stage. Please address the following:
1. Specify if the product solution comprises hardware (e.g., an appliance), software, or both. Include minimum and optimum hardware requirements, descriptions of any fail-over capabilities, and database requirements.
2. Describe the type of functions performed by the product solution. Per capability, indicate in a spreadsheet which ones the proposed solution: currently meets, is currently being developed, planned future development, or does not plan to meet.
3. List the Operating System(s) the product(s) supports to include patch and service pack levels.
4. Describe how the solution suites will be managed and provide logical data flow.
5. Describe the recommended deployment architecture and strategy to include installation and maintenance (life cycle support).
6. Describe the scalability of the product(s) for an Enterprise-wide deployment.
7. Describe the most effective product implementation for Enterprise-wide analysis collaboration
8. Describe any testing that has been or will be conducted for compliance, such as the Common Criteria for Information Technology (IT) Security Evaluation and/or the Cryptographic Module Validation Program (CMVP) described in the National Institute of Standards and Technology (NIST) Federal Information Processing Standard (FIPS) 140-2. Include a discussion of common criteria and FIPS certifications on the proposed solution.
9. Provide descriptions and certification of current software security assurance practices used
10. Provide information on existing and planned IPv6 compatibility.
Section 2. Feasibility Assessments (limited to 3 pages, including diagrams and spreadsheets)
1. Describe how the solution is managed (the appliance/software and the data flow) and the estimated amount of manpower required.
2. Describe the feasibility assessment of the proposed Technical Media Analysis Tool solution deployment scenario.
3. DoD is in the process of deploying a Host Based Security System (HBSS) that is based on the McAfee ePo product. The intent of HBSS is to deploy agents, and manage them from a single central console. Please describe the feasibility of meeting the McAfee interface requirements as described in the McAfee Security Innovation Alliance (SIA) http://www.mcafee.com/us/partners/security_innovation_alliance/overview.html.
4. Include data on the amount of network traffic generated between product solution sets and those to and from the management console.
Section 3. Cost and Schedule Estimates (limited to 4 pages, including diagrams and spreadsheets). This is not a solicitation and any cost estimates that are provided are not binding.
1. Describe a DOD Enterprise-wide solution cost estimate (software and/or appliance).
2. Provide a cost estimate when describing the licensing agreement, support, training, and maintenance for non-recurring and annual recurring costs for the host-agent required for Unlimited Enterprise Wide Licenses.
Section 4. Regulatory Requirements (limited to 4 pages, including diagrams and spreadsheets)
1. Briefly describe your products National Information Assurance Partnership (NIAP) Certification status or plan to obtain NIAP certification. The potential acquisition effort will require Proof of NIAP certification for this capability at a minimum of Evaluation Assurance Level (EAL) 2 or a letter of intent to commit to the NIAP certification process.
2. Briefly describe your products ability to comply with Security Technical Implementation Guidelines (STIGs). STIGs provide instruction on securing operations in a specific technical environment. STIGs and application checklist are available from http://iase.disa.mil. Adherence to the standards is mandatory and ensures the solution shall not introduce vulnerabilities while maintaining full functionality on a STIG compliant system.
3. Briefly describe your products plan for Certification and Accreditation. The potential acquisition effort will require the vendors solution(s) to be certified and accredited via the DITSCAP or DIACAP process as applicable. The product must receive an Authority to Operate (ATO) before it is placed on any DoD network.
4. Briefly describe your products compliance with Section 508 of the Rehabilitation Act.
Section 5. Additional Materials/Information
Information Exchange Meeting
Commercial off-the-shelf/Government off-the-shelf (COTS / GOTS) demonstration day(s) will be held after the due date of this RFI (Date is TBD). Due to time and facility limitations, participation in these days will be by invitation only. The COTS / GOTS day(s) will be held at a location and time to be announced. Be advised that no more than three representatives from each respondent should attend. The government reserves the right to cancel any stated or potential COTS/GOTS day demonstrations at its discretion.
Provide any other materials, suggestions, and discussions deemed appropriate.
THE GOVERNMENT DOES NOT INTEND TO AWARD A CONTRACT ON THE BASIS OF THIS RFI OR OTHERWISE PAY FOR INFORMATION RECEIVED IN RESPONSE TO THE RFI. This RFI is issued for information and planning purposes only and does not constitute a solicitation. All information received in response to the RFI that is marked Proprietary will be handled accordingly. The Government shall not be liable for or suffer any consequential damages for any proprietary information not properly identified. Proprietary information will be safeguarded in accordance with the applicable Government regulations. Responses to the RFI will not be returned nor will the Government confirmed receipt of the RFI response. Whatever information is provided in response to this RFI will be used to access tradeoffs and alternatives available for determining how to proceed in the acquisition process. In accordance with FAR 15.201(e), responses to this RFI are not offers and cannot be accepted by the Government to form a binding contract.
The anticipated North American Industry Classification System Code (NAICS) for this requirement is 511210, and the size standard is $23M.
Small businesses are strongly encouraged to provide responses to this RFI, in order to assist DISA in determining the potential levels of interest, competition and technical capability to provide the required services within the Small Business community. In addition, this information will also be used to assist DISA in establishing a basis for developing any subsequent potential subcontract plan small business goal percentages.
5.0 SUBMISSION INSTRUCTIONS
RFI responses should be submitted via email (time stamped and not to exceed 5 MB) to: samuel.tesfaye@disa.mil; shannon.keesler@disa.mil
Responses should include the (1) business name and address; (2) name of company representative and their business title; (3) contract vehicles available that would be available to the Government for the procurement of the product and service, to include General Service Administration (GSA) Federal Supply Schedules (FSS), or any other Government Agency contract vehicle.
6.0 CONTACT INFORMATION
All inquires and questions related to this RFI should be sent to the following Points of Contact: Mr. Samuel Tesfaye, Program Manager, (703) 882-1573, samuel.tesfaye@disa.mil or Shannon Keesler, Alternate Program Manager, (703) 882-1494, shannon.keesler@disa.mil. Responses are due no later than close of business Feb 11, 2008.
Point of Contact
Mary Hall, Contract Specialist, Phone 618-229-9580, Fax 618-229-9177, Email MaryAnn.Hall@disa.mil - Thomas Anson, Contracting Officer, Phone 618-229-9727, Fax 618-229-9177, Email Thomas.Anson@disa.mil
|
|
