SPECIAL NOTICE
D -- Request for Information - Mobile Device Management
- Notice Date
- 10/25/2011
- Notice Type
- Special Notice
- NAICS
- 541519
— Other Computer Related Services
- Contracting Office
- Contracting Center of Excellence (NCR-CC), 200 Stovall Street, 11TH Floor, Alexandria, VA 22331-1700
- ZIP Code
- 22331-1700
- Solicitation Number
- W91WAWPMNES2
- Archive Date
- 10/24/2012
- Point of Contact
- Hamilton D. Cunningham, 703.325.1987
- E-Mail Address
-
Contracting Center of Excellence (NCR-CC)
(hamilton.d.cunningham@us.army.mil)
- Small Business Set-Aside
- N/A
- Description
- Request for Information (RFI) for Program Management Network and Enterprise Services (PM NES) Establishment of Mobile Device Management Services Army Contracting Command National Capitol Region 200 Stovall Street Alexandria, Virginia 22331-1700 THIS REQUEST FOR INFORMATION (RFI) SUPPORTS THE ESTABLISHMENT OF A MOBILE DEVICE MANAGEMENT SYSTEM SERVICING THE DEPARTMENT OF DEFENSE TO FACILITATE ENTERPRISE MANAGEMENT OF MOBILE DEVICES. Table of Contents 1.0Background4 2.0Introduction4 3.0Vendor Instructions5 4.0Request for General Information6 5.0Objective7 6.0Request for Technical Information9 7.0Constraints14 8.0Transition and Transformation15 1.0Background The use of commercial mobile devices (CMDs), such as devices and tablets, offers an unprecedented amount of opportunity for advanced mobile computing and communications within the Department of Defense (DoD). However, the importance of adapting to these newly emerging technologies while also adhering to existing security policies and requirements poses major challenges moving forward. In the realm of CMDs, it is widely known that most mobile operating systems (OS) lack the basic functionality necessary to meet minimum DoD security requirements for protecting personal, military, and enterprise data. Therefore, the need to augment existing systems with additional administrative components as part of a greater architecture becomes paramount to ensuring security and functionality across a variety of mobile device platforms. Some of the hurdles include, but are not limited to, the securing, monitoring, and management of CMDs. In addition, the provisioning and updating of these devices at an enterprise-level poses great challenges as DoD moves towards wide proliferation of devices and tablets. Overall, the obstacles faced by the DoD community can be potentially mitigated by utilizing a mobile device management (MDM) system capable of providing a central administrative framework for tracking and monitoring CMDs as well as ensuring security policy compliance among end-point devices. 2.0Introduction This RFI is issued as a means of technical discovery and information gathering. Program Management Network and Enterprise Services (PM NES) seeks to (1) become familiar with the current state of the MDM market, specifically to validate available MDM features and capabilities in existence today, (2) identify those MDM companies which are exceeding the inherent supported baseline functionality of current device platforms and applying innovative approaches to providing a greater security and enterprise management model in their MDM platforms. PM NES seeks this information from industry, particularly from MDM vendors who specialize in the following types of mobile device management: Software Distribution - The ability to manage and support mobile application use including deploy, install, update, delete or block. Policy Management - Development, control and operations of DoD enterprise mobile access, connectivity, and security policy. Inventory Management - Software, firmware, hardware, and peripheral device inventory management, this includes provisioning and support. Security Management - The implementation and enforcement of DoD-level device security, authentication, validation and encryption functionality. 3.0Vendor Instructions DISCLAIMER 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 confirm receipt of the RFI response. Whatever information is provided in response to this RFI will be used to assess 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 541519 (size standard $25M). Small businesses are strongly encouraged to provide responses to this RFI, in order to assist PM NES 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 PM NES in establishing a basis for developing any subsequent potential subcontract plan small business goal percentages. Submission Instructions Responses should include the (1) business name and address; (2) name of company representative and their business title; (3) contract vehicles 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. The responses should be in a white paper format, no longer than fifty (50) pages in length. Responses to this RFI are due NLT Tuesday 8 November 2011 at 5:00 PM Eastern (EST). Contact POC's are Gregory Clark (Gregory.clark5@us.army.mil) and Hamilton Cunningham (hamilton.d.cunningham@us.army.mil). Proprietary Statement Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received that is marked Proprietary will be handled accordingly. Please be advised that all submissions become Government property and will not be returned. Responses will be reviewed by government personnel and PM NES PMSS support contractor personnel from SNVC, Inc. All government and contractor personnel reviewing RFI responses will have signed non-disclosure agreements and understand their responsibility for proper use and protection from unauthorized disclosure of proprietary information as described in 41 USC 423. The Government shall not be held liable for any damages incurred if proprietary information is not properly identified. Contracting Office Address: 200 Stovall Street Hoffman Building 1 10th Floor, Room 10S67 Alexandria, Virginia 22331-1700 United States Place of Performance: Non-U.S. United States Primary Point of Contact.: Gregory Clark, Contracting Officer Gregory.clark5@us.army.mil Phone: 703.325.6542 4.0 Request for General Information 1.Describe your organization. The term "mobile device management" can describe a wide range of products and services that enables organizations to deploy and support enterprise applications to mobile devices with various areas of functionality, such as security, provisioning, software and inventory management, and decommissioning. What types of MDM products and services do you provide? 2.Describe your organization's experience with and expertise in the MDM industry. 3.If possible, please describe client organizations/agencies within the DoD and federal government community who have either previously used or currently use your MDM product(s)/service(s). If not applicable, please describe any commercial companies who use your MDM product(s)/service(s). What was the size and scope of their mobile device deployments? 4.What is your current year-to-date (YTD) revenue in the MDM industry? 5.Please provide market penetration and level of financial funding to meet product improvement and marketing goals in the next 5 years. 6.Does your MDM solution have DoD Information Assurance Certification and Accreditation Process (DIACAP) accreditation, Certificate of Networthiness (CoN), Security Technical Implementation Guide (STIG), and/or equivalent qualifications which permit use of your product on the DoD network? Please list all relevant certifications. 7.Please describe a future roadmap for your organization as well as your MDM product. What features and/or capabilities to you plan to integrate in future versions of your product? Please provide a tentative timeline of capability milestones, if applicable. 8.What are your standard contract terms and conditions? 9.Please provide any additional information about your organization which you feel distinguishes you as a provider of, or authority on, MDM technology. 5.0Objective Ideally, the vendor should discuss how their solution addresses the following capabilities which are of interest to the U.S. Army and the Department of Defense: Support for iOS 5.x, Android 2.x and 3.x, Blackberry 6.x and 7.x, and Windows Phone 7 (WP7) mobile device platforms Support for Microsoft Exchange, Blackberry Enterprise Server, and Oracle Sun Java Unified Communication Suite messaging server platforms Security and Policy/Compliance Enforcement oComplex password enforcement (strong alphanumeric password) oRemote device wipe (both selective and total) oRemote device lock oDevice lock (after a given period of inactivity) oAdministrator/remote reset of device password oCAC/PIV device authentication oAdminister policies as groups oAdminister policies as individuals oSupport complex group policies (multi-layered, hierarchical, etc.) and/or individual policies oDisable infrared (IR) port oDisable Wi-Fi radio oDisable automatic connection to Wi-Fi networks oDisable cellular radio oDisable Bluetooth radio oBluetooth profile whitelist/blacklist by vendor oBluetooth profile whitelist/blacklist by peripheral type oDisable camera(s) oDisable microphone(s) oDisable removable media port oDisable USB/serial port (i.e. 30-pin dock connector, MicroUSB, MiniUSB, etc.) oSupport restrictive management of USB/serial access by vendor and/or peripheral type oDisable screen capture oDisable voice dialing oDisable access to public app repositories (i.e. App Store, Android Market, etc.) oSupport granular restrictive access to specific public app repositories and/or specific applications on specific public app repositories oDisable use of preinstalled browser oEnforce URL and web content filtering oEnable browser enforcement through DoD proxy oDisable Location-based services (GPS) oDisable SMS/MMS messaging oPolicy compliance reporting oQuery for compliance and security information oAlert system for users and IT administrators when device policies are violated, which includes the ability to "kill" devices when they become noncompliant oForce exclusive use of VPN for all IP traffic oEnforce DoD Logon Banner or custom text to device lock oFIPS 140-2 level 1data-at-rest encryption oFIPS 140-2 level 1 data-in-transit encryption oFIPS 140-2 level 1 encrypted certificate store on device oForced and/or optional FIPS 140-2 level 1 encryption of removable media oJailbreak/Root detection mechanism oDevice integrity monitoring oTrusted boot sequence oRemote device health monitoring oLocation-based policy enforcement oLog device activity and message archiving and retrieval (incoming/outgoing calls, messages, data, etc.) natively on device oLog device activity and message archiving and retrieval (incoming/outgoing calls, messages, data, etc.) from administrative server oRestrict access to enterprise servers Application Management oApplication blacklisting oApplication whitelisting oRestrict/manage application "sideloading" oApplication management/deployment by security or policy groups/types oDisable preinstalled applications oDeny removal of applications oRemotely push applications to device oRemotely uninstall applications on device oQuarantine protection for rogue applications oQuery for application information oServer-side backup of application information installed on device oDevice backup of application information on removable media oApplication validation at download, installation, run-time, and device boot-up Malware Control Management oAntivirus and malware detection oSpam protection oPhishing protection Email oS/MIME capability oIntegrated calendaring oDoD Global Address List (GAL) integration oCAC/PIV encryption and signing integration oPlain text only native email enforcement VPN Management oPKI-based authentication oDisable Split Tunneling oIPSec/SSL end-to-end encryption oFIPS 140-2 data-in-transit encryption Inventory/Asset Management oQuery support for device and network information oDevice activation and deactivation oDevice configuration and imaging oTrouble ticket and tracking management oEnforce mobile communication expense policies, such as disabling cellular data or access to servers when roaming internationally Software Distribution oAccess to private application repository oPush and/or pull over-the-air (OTA) software updates for applications and Operating Systems (OSes) oTrusted controls for over-the-air (OTA) or tethered provisioning and updating process oBackup/restore of configuration data oBackup/restore of software Administration and Reporting oBusiness intelligence, analytics, and reporting tools oAccess to management server via single or web-based console Role-based access oGroup-based action management oEnterprise platform integration (i.e. LDAP, Blackberry Enterprise Server, Good Mobile Messaging, certificate authority, trouble ticketing and help desk, such as Remedy) oFIPS 140-2 level 1 encryption of administrative (MDM) communications A Certificate of Networthiness (CoN) Integration of hard and/or soft token user authentication, i.e. Common Access Card (CAC), microSD, near-field communication (NFC), etc. Suite B certification of cryptographic modules for processing classified information up to Secret level Integration of virtualized operating systems and/or hypervisor architecture for mobile devices An MDM solution scalable to support all potential DoD users 6.0Request for Technical Information Please answer the following questions with as much detail as possible. Please note that some questions are to be interpreted simply as guidelines and can be used to include any additional information related to the topic which may differentiate or better explain your product's functionality. MDM Platform 1.What is your company's technical approach to mobile device management? Do you take a lightweight approach where a mobile agent is installed on the device to call native APIs on the mobile platform or a heavyweight approach where client-side management software on the device can enforce policies beyond the native APIs, such as local data encryption and selective wipe? 2.What is the delivery model for your MDM platform? (i.e. on-premises, cloud, managed services, hybrid, etc.) 3.Describe your MDM network architecture. Graphics or diagrams are acceptable. 4.For securing data, does your MDM solution allow separation of personal and corporate content on the device? If so, how do you achieve and protect data separation? Is your separation based on virtualization technology (i.e. VMware MVP)? How and where are encryption keys and authentication data stored? 5.Can you host a private app repository using your MDM solution? If so, does your app repository support bundling and/or app-level access rules for specific user groups/types? 6.Does your MDM solution include an email component? If so, does it support S/MIME, calendaring, and/or Global Address List (GAL) lookup? What messaging server platforms does your MDM solution support? (i.e. Microsoft Exchange, Sun Java, etc.) 7.Describe your MDM solution's failover capabilities. For example, if your MDM server fails, does it revert elegantly to a backup? 8.Does your MDM solution provide database and server redundancy? Please describe. 9.List any dependencies on externally provided infrastructure, e.g. Apple Push Notification Service (APNS). 10.Do you have any hard and/or soft token(s) integrated with your MDM solution? If so, to what extent? Can you require hard/soft token authentication upon unlocking of the device? 11.Can your MDM solution integrate with an e-Policy Operator (ePO) or Host Based Security System (HBSS) to provide host-based intrusion detection? 12.Does your MDM solution integrate with virtualized OSes and/or hypervisor architecture on mobile devices? 13.Describe how your MDM solution would be configured to support the following user population sizes: (a) 25k users (b) 100k users (c) 250k users (d) 500k users (e) 1million users 14.For each population size listed in Question 12, provide the number of yearly man-hours and labor skills required to staff and maintain the system as an enterprise solution. 15.For each population size listed in Question 12, what is the time table for standing up a MDM solution? Estimated times should include user data provisioning and testing. Provide any assumptions made. Device 16.What mobile OS platforms (specify by version number) do you support? Does your MDM solution provide equal functionalities across all supported mobile platforms? If not, what particular feature sets are not available on what particular mobile platforms? Please explain. 17.Are there limitations to what device manufacturers and/or carrier service providers your product supports as well? If so, please describe. 18.Can your MDM resident mobile application be removed or modified by the user? If this answer varies by OS or device, please specify for each major variant. 19.What are the possible detection and/or failure scenarios if your MDM application is corrupted by malware? 20.Can your MDM solution enforce major and minor releases of an approved software version (OS, MDM client, third-party application, etc.) installed on the device before granting the user access to it? Please explain. 21.What methods does your MDM solution implement to protect devices from malware and viruses? For example, does your MDM solution provide a device-level firewall, malware, and/or intrusion detection system (IDS) protections for the connection path between the infrastructure and/or MDM and the device? Please explain. 22.Can your MDM solution backup and restore configuration data and software on the device? Please explain. 23.Can your MDM solution monitor device status such as battery life, memory usage, and CPU? Please explain. Security 24.To what extent can you determine if a user is complying with security policy? Is it real-time or periodic? Is the compliance performed on the backend and/or on the device? Does your MDM solution allow for both active and passive compliance and security checking? What types of alerts are available for the user and the administrator when policies have been violated? What are the available courses of action, both at an administrative and at a device level, when an alert is triggered? 25.Is the communication and data handling of your MDM solution FIPS 140-2 compliant and/or validated by NIST? Please describe the cryptographic modules used in your product to support data-at-rest, data-in-motion, and data-in-transit encryption. 26.Is the communication and data handling of your MDM solution Suite B compliant and/or validated by NSA? Please describe the cryptographic modules used in your product to support data-at-rest, data-in-motion, and data-in-transit encryption. 27.Does your MDM solution include a jailbreak/root detection mechanism? If so, please describe how it is implemented. Can it detect both tethered and OTA jailbreak methods? Is your detection mechanism proprietary or open-source? Can you prevent and/or detect manual override of this feature by the user? 28.To what extent can you enforce complex password configuration on the device? (i.e. number of characters, at least 2 complex characters, etc.) Can you prevent and/or detect manual override of this feature by the user? 29.Please describe your method(s) of triggering a remote wipe on a device. Do you leverage any native remote wipe capability of the device or use a proprietary method? Are you able to perform any form of selective remote wipe? If so, what types of data can be selectively wiped and by what method? 30.To what extent can you administratively control Wi-Fi? For example, can you blacklist/whitelist certain Wi-Fi networks? Can you disable the automatic connection of the device to a Wi-Fi network? Can you prevent and/or detect manual override of this feature by the user? Please explain. 31.To what extent can you administratively control cellular communication? For example, can you force devices to use 3G service over LTE? Can you impose carrier-based or location-based restrictions on service and/or roaming access? Can you prevent and/or detect manual override of this feature by the user? Please explain. 32.To what extent does your MDM solution manage VPN communication? Can you disable split tunneling? What method are you using to encrypt network communication from end-to-end? Can you prevent and/or detect manual override of this feature by the user? 33.To what extent can you administratively control the Bluetooth communication? For example, can you blacklist/whitelist connecting devices by vendor or peripheral type? 34.To what extent can you disable location-based services? Can you disable the location of your device either by GPS and/or cellular triangulation? Can you prevent and/or detect manual override of this feature by the user? 35.To what extent can you administrative control the camera(s)? Can you disable both the front and rear cameras independently of each other? Can you prevent and/or detect manual override of this feature by the user? 36. To what extent can you administrative control the removable media port? For example, can you restrict the port so that the device allows only the removable media inserted upon provisioning to communicate with it? Can you prevent and/or detect manual override of this feature by the user? 37.To what extent can you administrative control the USB/serial port? Can you restrict the port so that it can only be used for charging the device? Can you restrict the use of the port by vendor and/or peripheral type? Can you prevent and/or detect manual override of this feature by the user? 38.Can you disable screen capture? Can you prevent and/or detect manual override of this feature by the user? 39.Can you disable the ability to access speech recognition functionality on the device? If so, explain. 40.To what extent can you manage browser access to the web? Can you restrict the browser management of passwords/form history/search history/cookies? Can you force all web traffic through a DoD proxy? Can you prevent and/or detect manual override of this feature by the user? 41.Can you display a custom banner upon unlocking the device that states "I've read and consent to the terms of the IS agreement"? 42.Does your MDM solution perform some type of device health and/or integrity monitoring? If so, please describe. 43.Can your MDM solution provide intelligent reporting and trend analysis on security-related events to recognize unusual, and potentially malicious, patterns with devices within the enterprise? Please explain. Application 44.What unique features does your MDM solution have to support application policy management? 45.Does your MDM solution have an application blacklisting/whitelisting capability? 46.To what extent can your MDM solution monitor the access, download, installation, and execution of applications? 47.Can your MDM solution disable some/all preinstalled applications that come with a commercial device? 48.Can your MDM solution prevent the user from removing installed applications? If so, to what extent? Can you prevent and/or detect manual override of this feature by the user? 49.Can your MDM solution restrict or manage the "sideloading" of applications to prevent unapproved installation of applications by removable media and/or USB connection? 50.Can your MDM solution place prohibited applications installed on the device in quarantine? 51.Can your MDM solution administratively push or uninstall applications on a device? 52.Can your MDM solution query a device for a list of installed and/or running applications? 53.In the event a user loses their device, does your MDM solution back up application information so that it can be restored on the user's next device? 54.Does your MDM solution validate the integrity of applications when they are downloaded, installed, executed, and displayed at device boot-up? Please explain. Policy 55.Can your MDM solution create administrative policies based on user group? What about creating policies for multi-layered hierarchical user groups that require different levels of security and compliance? For example, an infantry group could set its own policies in addition to any policy that it inherits from the Army, which also inherits policies from the DoD. Consequently, setting policies of any group in the multi-tiered hierarchical path would have no effect on any group outside that path, nor could it allow a lower tier group to delete any higher level group set policies. 56.Can your MDM solution restrict lower tiered managers from changing/deleting policies enacted by higher level managers? Conversely, would it allow lower tiered managers the ability to enforce stricter policies than those enacted by higher level managers? 57.Can your MDM solution manage policies based on particular hardware model? 58.Can your MDM solution leverage location-based services to enforce compliance policies? For example, if a user worked in a Sensitive Compartmented Information Facility (SCIF), could your solution trigger the user's device to turn off all radios upon proximity of the building? Please explain. 59.To what extent can you restrict access to network resources? Can you establish group/individual privileges to specific network resources? 60.To what extent can you restrict access to public app repositories? 61.How does your MDM solution handle software updates for applications and the OS? 62.Can you enforce mobile communication expense policies using your MDM solution? 63.Does your MDM solution have a component for managing device inventory? Please describe in detail how your MDM solution solves this issue. 64.Can your MDM solution provide designated alerts to another enterprise network management application using SNMPv3 or SNMPv2 with IPSec tunnel? 65.Can your MDM solution create acceptable use policies for using an enterprise device for personal use? 66.Can your MDM solution create different policies for employee-owned devices and company-owned devices? Service 67.Can your MDM solution allow for multi-tiered helpdesk support? For example, an Army civilian would get helpdesk support from the Army but it is the same application supporting all of the various helpdesks. Additionally, the Army helpdesk profile would allow them to only view Army devices and not the other Services, but the OSD level profile would have access to all helpdesk information. 68.Can your MDM solution provide centralized administration and a single management repository for all devices managed by the enterprise but provide multi-tier management/role capability (managing hierarchal groups) in accessing mobile device information and setting policies? 69.What type of reporting and business intelligence (BI) tools do you offer with your MDM product? Please provide a description of what kinds of device status reports can be produced using your tools? Are they comprised of both text and statistical graphics? Are they canned reports or can they be customized by the client? 70.Can your MDM solution provide helpdesk functionality troubleshooting tools, report generation, historical analysis, and problem triage? 71.Can your MDM solution provide reports and trend analysis on mobile service usage to view calls made/received, data download/upload usage, SMS usage, application downloads, toll calls, overages, inactive phones, and roaming charges? 72.Can your MDM solution provide device monitoring, alarms, error logs, inventory tracking, and customizable reports? 73.Can your MDM solution retrieve asset-tracking information such as serial number and asset tags? 74.Can your MDM solution provide users the ability to perform self-service configuration for capabilities such as device procurement, device registration, service activation, application download/configuration, locate device, lock/wipe device, and user-contact information changes? 75.Can your MDM solution support over-the-air (OTA) provisioning to which OS and version type devices? 76.Can your MDM solution create configuration profiles (sometimes referred to as templates) that simplify the process of provisioning based on vendor, operating system, or model type? 77.Can your MDM solution provide an audit trail capability? Many enterprises must comply with government regulations (e.g., Payment Card Industry Data Security Standard [PCI-DSS] and Health Insurance Portability and Accountability Act [HIPAA]) and must demonstrate their compliance with these regulations. Some MDM systems provide the ability to produce a provisioning audit trail and a resultant compliance report that can assist enterprises with their regulatory compliance-reporting obligations. Please describe in detail. 7.0Constraints The following constraints should be identified and mitigation processes defined in industry responses. Compliance with Army security policies, guidelines and architectures including Top Level Architecture (TLA), Information Assurance Vulnerability Alert (IAVA) reporting, monitoring, etc. DIACAP Authority to Operate (ATO) Certificate to Operation (CTO) Certificate of Networthiness (CON) Army Interoperability Certification (AIC) IPv6 Transition Preparation Clinger-Cohen Act (CCA) Compliance Information Assurance Strategy (AIS) - Required for CCA compliance and the others Global Information Grid Bandwidth Expansion (GIG BE) connectivity Continuity of Operations (COOP) and Disaster Recovery (DR) Army Environmental/Facilities requirements (if applicable), specifically: oInfrastructure oPhysical Security oSurvivability oTime lines oRequired footprint/floor space oApprovals and Ownership 8.0Transition and Transformation In any organization, change is always challenging. It is the Army's intent to transition and transform the user community to the MDM as transparently, seamlessly, and expeditiously as possible. As such, it is requested that industry address the following additional items in their response to this RFI. A successful mitigation plan for past transitions in the commercial or Federal marketplace. Any capabilities that exist for users to perform a "Self-Service" migration Any issues and mitigation techniques related to migrating devices into the new Enterprise solution. Levels of service currently being provided in the commercial or Federal marketplace and their key performance parameters Strategies for identifying and resolving recurring and systemic problems with the MDM system Current methodology for providing Tier 2/Tier 3 level support services An expected "start up" period of time in calendar days, from date of award through service provision, including installation, Information Assurance (IA) accreditations and certifications. How would the transition of data to a new service provider (commercial or government) at the end of the contract be performed?
- Web Link
-
FBO.gov Permalink
(https://www.fbo.gov/notices/190a6592066a74b3ba730cb7c8182bf3)
- Record
- SN02612360-W 20111027/111025234029-190a6592066a74b3ba730cb7c8182bf3 (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 |