Request for Information on the best means to integrate key mobility solutions inclduing solutions that prevent, identify, monitor, analyze and mitigate issues/vulnerabilities against the device and the Department of Defense Information Network (DoDIN)

REQUEST FOR INFORMATION Defense Information Systems Agency (DISA), Infrastructure Development Directorate (ID72), Defense Information Technology Contracting Organization (DITCO)-SCOTT-PL83, Information Technology Division (DITCO) is seeking information from industry to assist with the development and planning of a potential new requirement. THIS IS A REQUEST FOR INFORMATION (RFI) NOTICE ONLY. THIS IS NOT A REQUEST FOR PROPOSALS (RFP). NO SOLICITATION IS AVAILABLE AT THIS TIME. 1. Purpose and Description: The Defense Information Systems Agency (DISA) Mobility Portfolio Division seeks information from industry on the best means to integrate key Mobility solutions. DISA requests information regarding current and planned mobile security solutions that prevent, identify, monitor, analyze, and mitigate issues/vulnerabilities against the device and the Department of Defense Information Network (DoDIN). 2. Scope of Effort: Mobile technology throughout DoD, including DoD Mobility Unclassified Capability (DMUC) and DoD Mobility Classified Capabilities (DMCC) require a secure means to manage and vet applications. DoD recognizes the critical importance of mobile software applications in the continuing evolution of the DoD mobile workforce. DoD mobile software applications, interoperable entities, and secure network management tools are necessary across the gamut of the DOD Enterprise. DoD must implement preventive, detective, and corrective mitigations for a comprehensive mobile threat detection environment. Meanwhile, the DMUC must provide regulated access to Commercial Off-the-Shelf (COTS) applications which transfer FOUO data applications via a secure cloud. 3. Technical Characteristics: The objective is to encompass legacy and/or evolving systems across MSM, Application Vetting Tools, and Cloud. These include, but are not limited to the existing mobility capabilities of Mobile Threat detection (MTD), also known as Mobile Security Management (MSM), Mobile Application Vetting, and Cloud for COTS applications. Mobile Threat Detection: - An automatic approach to monitoring and defining application security levels which, once implemented, provides end to end identification, enforcement and remediation for Malicious/High Risk Applications. Application Vetting Tools: What approach is offered for the following capabilities? - Static code checkers: Usage is typically included in the development process for developing and delivering apps to the government. The capability will be used to assess code during code development to find defects as early as possible in the software lifecycle. This capability should be highly interactive with the application developer and the application vetting user community. - Byte-code or binary code checking: This capability should be able to conduct checks and analysis on the applications (app) tested in the on-site lab environment. This capability should provide a sandboxed environment that enables the government to conduct security conformance checking for NIAP Application Software and functional testing on the app to determine if any deviant behavior is occurring outside of the prescribed architecture and functional description of the application. Deviant behavior indicators are defined by what the upfront expectation of how the application will function. As comparison, this capability should provide similar functionalities as Google's - bouncer' tool. - Network analysis: Proactively anticipate security flaws in the DoD Network. Cloud for COTS FOUO: - Provides an approach for accessing applications that are parsed by level of security in the cloud by containerize and provide secure access to COTS/FOUO applications at DoD Cloud Provisional Authorization Impact level 4 or 5. Based off the following description: 4. Requested Information: This RFI will assist the DoD in defining technical characteristics for a proposed solution. Requested Information: DISA intends additional dialogue with the mobile threat detection industry to identify tools and capabilities that can be integrated with current and future systems. These industry interactions may include discussions, demos, or prior verifiable results with companies that submit responses so to better understand their offerings. It is highly encouraged that cost estimation be correlated to stated vendor functionality in the responses. 5. Information from industry should include responses to the following questions: 5.1 What factors should DoD prioritize in developing an approach to preventive security testing for the following types of application source code and application binaries: native Windows, Android, and iOS? 5.2 What factors should DoD prioritize in developing an approach to integrating proactive security testing with on premise functionality as opposed to first party native Operating Systems and application development platform code assurance libraries? How can preventive security technologies be integrated with on premise and cloud-based application development platforms and application development platform code assurance libraries? Why would this approach be most effective? 5.3 How can proactive, detection, and corrective security technologies are used in the timely deployment of mission-critical mobile software applications that supports operational requirements at enterprise scale? What are the limitations of preventive, detection, and correction security technologies for timely software application deployments that support operational requirements and how can these be overcome? 5.4 How can DoD employ proactive, detection, and corrective technologies, preferably automated but also manual by exception as required, to meet the requirements of the National Information Assurance Partnership Protection Profile for Application Software to include activity assurances and the Requirements for Vetting Mobile Apps from the Protection Profile for Application Software? 5.5 How can analysis of software application URL requests be employed as preventive risk mitigation? What are the roles and limitations of proactive, detection, and corrective security technologies in mitigating malware threats and vulnerable behaviors? What is the role of preventive, detection, and corrective technologies in mitigating the impact of insecure coding practices? 5.6 How can preventive security technologies employ intelligence regarding publishers' reputations? What are the roles and limitations of preventive security technologies in countering advanced threat groups, zero day attacks and mitigating advanced persistent threats? 5.7 What is the role of preventive, detection, and corrective technologies in DoD mobile defense-in-depth? (outlined above) 5.8 How can mobile threat detection threat intelligence technologies be employed to automate the prevention and detection of zero-day attacks? 5.9 What are the roles and limitations of mobile threat detection technologies in incident response? How can mobile threat forensic artifacts be employed to mitigate risk to the DoDIN? 5.10 What is the role of mobile threat detection technologies in the evaluation of the security posture of the DoD mobile enterprise, the efficacy and return on investment of DoD mobile security assets, and the optimal dedication of DoD mobile security assets and resources? 5.11 How can mobile threat detection vendor intelligence programs regarding threat agent profiles, threat vector trends, and threat Internet protocol addresses and domains be employed to improve the security of the DoD mobile enterprise? 5.12 What are the roles and limitations of device sensors in the development and operation of a comprehensive mobile threat detection capability? 5.13 What are the roles and limitations of mobile threat detection in active and adaptive defense tactics? 5.14 What are the roles and limitations of mobile threat detection in current industry device? 5.15 What is the role of preventive, detection, and corrective technologies in the maintenance of commercial and government software applications deployed to devices as the applications are periodically updated? 5.16 How can mobile threat detection be integrated with mobile device management suites to maintain and improve the evolving security posture of the DoD mobile enterprise? 5.17 What capabilities and benefits are offered through the integration of these technologies that are not available separately? What if anything should be separate? 5.18 What are the roles and limitations of mobile threat detection in mobile device compliance monitoring and enforcement, including the application of a range of tailored compliance and remediation actions? How can the integration of mobile threat detection and educate device users about application software and device risk levels and applicable policy violations? RESPONSE GUIDELINES: Interested parties are requested to respond to this RFI with a white paper. Submissions cannot exceed 10, single spaced, 12-point type with at least one-inch margins on 8 1/2" X 11" page size. The response should not exceed a 5 MB e-mail limit for all items associated with the RFI response. Responses must specifically describe the contractor's capability to meet the requirements outlined in this RFI. Oral communications are not permissible. FedBizOpps will be the sole repository for all information related to this RFI. Companies who wish to respond to this RFI should send responses via email no later than October 21, 2016 to cynthia.d.black8.civ@mail.mil and cheryl.a.moody5.civ@mail.mil. INDUSTRY DISCUSSIONS: DISA representatives may choose to meet with potential offerors and hold one-on-one discussions. Such discussions would only be intended to obtain further clarification of potential capability to meet the requirements, including any development and certification risks. QUESTIONS: Questions regarding this announcement shall be submitted in writing by e-mail to cynthia.d.black8.civ@mail.mil and cheryl.a.moody5.civ@mail.mil. Verbal questions will NOT be accepted. Answers to questions will be posted to FBO. The Government does not guarantee that questions received after October 7, 2016 will be answered. The Government will not reimburse companies for any costs associated with the submissions of their responses DISCLAIMER: This RFI is not a Request for Proposal (RFP) and is not to be construed as a commitment by the Government to issue a solicitation or ultimately award a contract. Responses will not be considered as proposals nor will any award be made as a result of this synopsis. All information contained in the RFI is preliminary as well as subject to modification and is in no way binding on the Government. FAR clause 52.215-3, "Request for Information or Solicitation for Planning Purposes", is incorporated by reference in this RFI. The Government does not intend to pay for information received in response to this RFI. Responders to this invitation are solely responsible for all expenses associated with responding to this RFI. This RFI will be the basis for collecting information on capabilities available. This RFI is issued solely for information and planning purposes. Proprietary information and trade secrets, if any, must be clearly marked on all materials. All information received in this RFI that is marked "Proprietary" will be handled accordingly. Please be advised that all submissions become Government property and will not be returned nor will receipt be confirmed. 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.