RFI Questions and Answers.docx

36 KB Posted

Attached to
Department of Defense Secure Access File Exchange
Solicitation number
622469205
Issued by

About this file

Written by GovTribe AI ·

This document contains Questions and Responses related to a Request for Information (RFI) for a Department of Defense Secure Access File Exchange (SAFE) system. The RFI seeks information on new file sharing technologies and capabilities that can be employed to modernize the DoD SAFE file sharing capability, supporting both Impact Level 5 (IL5) and Impact Level 6 (IL6) standards for deployment to both the NIPRNet and SIPRNet.

Key details from the Q&A include:

  • The system requires multi-factor authentication, including for guest users who do not use DoD-issued PKI authenticators like CACs and SIPR tokens.
  • The system should have the ability to set file-sharing controls to allow, limit or prohibit re-sharing of files by authorized recipients.
  • The system must be capable of appropriately safeguarding PII/PHI information.
  • The system should provide NetOps toolsets and analytics to monitor and detect malicious user activity.
  • The Government is seeking Rough Order of Magnitude pricing and information on innovative strategies for a resilient, scalable architecture to support current and future demands.

View the file

Other files

File Type Posted
RFI - Update 1.docx DOCX document
RFI - Final.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file
Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Solicitation # 622469205 Department of Defense Secure Access File Exchange

QUESTION & RESPONSE TEMPLATE

Questions & Response Template

Question #
RFI Reference
Questions / Comments
Government Response
RFI Response
1
Provides a zero-trust architecture with Multi-Factor Authentication that will allow access to all DoD military, civilian and authorized contractor personnel, while only allowing guest access to other users.

For the Multi-Factor Authentication requirement, we would assume that most users would use DOD issued PKI authenticators such as SIPR Tokens and CACs. Does the MFA requirement also apply to guests (i.e. users who would not use these methods to authenticate)? If so, what is required for these users – MFA access experience, approved authenticators, enroll?

CAC and SIPR tokens can be used for MFA for “authenticated” users. Guest users are also required to use some method of MFA to ensure that the user downloading the file is in fact the intended recipient. How this could be accomplished is the information we are seeking, and the requirement does not specifically call out how.

2
Cross Domain.
Are there current Cross Domain (NIPR to SIPR) solutions that can be leveraged that can be integrated with the SAFE solution or must the SAFE solution be authorized to function as a CD?
iSAFE (not to be confused with DoD SAFE) is an existing cross-domain file transfer capability that allows a user to transfer a file from the NIPR to SIPR environment, but not share files with other users. This could possibly be leveraged; however, we have not engaged with that PMO to determine feasibility. It’s likely that to achieve this capability, we may need to develop a native solution and we understand that may be difficult. The point of this RFI is to obtain information of how this may be achieved.
3
Cross Domain.

Must this requirement be met within the 12-month period of performance (accounting for cross domain funding and review/approval scheduling)?

Cross Domain does not need to be addressed in the first 12 months, but a path to achieving cross-domain should be laid out.

4
Provides the ability to set file-sharing controls to allow, limit or prohibit re-sharing of the files received by a user.
Request for the Government to expand on their definition of re-sharing, perhaps with an example scenario. Does this require a rights-management solution that marks the file in such a way that only approved recipients are allowed to view it?

The main purpose of this requirement is to allow a recipient to easily “re-share” a document that they receive, without requiring them to download and re-upload the same document to send to additional users. Current SAFE users often do this by simply sharing the pick-up information email they receive with additional users. This presents a vulnerability in that anyone who obtains that pick-up information can then also download and reshare the information. A new SAFE requirement will prohibit this from happening by requiring MFA to ensure that only the intended recipients of a document are permitted to access those documents. In order to share, users will be forced to download and re-upload files in order to share. This requirement is meant to be a convenience to users who have a legitimate need to reshare the documents they receive over SAFE.

5
Provides the ability to set file-sharing controls to allow, limit or prohibit re-sharing of the files received by a user.
Would this functionality add controls onto a document/file once it has been downloaded by the authorized recipient(s)? If so, would it apply to all file types? For example, a compressed archive that contains multiple fills.

This requirement only applies to files, while they are being handled by the system. For example, the system may allow a recipient to share a file that they received to other users. The original sender of the document may allow, permit, or restrict sharing through the system. This requirement would no longer apply to documents that have been downloaded by a recipient.

6
Provides the required security to allow users to share files, marked as Personal Identifiable Information/Protected Health Information (PII/PHI).
Would the Government please provide further details on the types of restrictions it would like to see in place to prevent the unauthorized sharing of PII/PHI?
No additional restrictions are required. The system just needs to be capable of appropriately safeguarding information at the PII/PHI level. The current system achieves this simply by offering an optional built-in AES-256 encryption mechanism and stores documents encrypted at rest.
7
Provide a NetOps toolset and analytics capability to provide visualization of system utilization metrics and to help monitor and detect malicious user activity.
Does the Government have metrics or thresholds it uses today to denote malicious or suspicious activity that could be imported into a new system?
The current system does monitor for malicious uploads, using mostly Commercial Off The Shelf Software in addition to the scanning and monitoring capability that comes native with our hosting environment.
8
RFI General
We would like to understand your current process / next steps and timelines associated with your desire to replace the current DOD Safe application.

The Government is only seeking input from industry regarding the subject RFI and has no further information to share currently.

9
RFI General
What security platforms are you using:

· Authentication (AD/LDAP, SSO, MFA)

· Authentication for external? (SSO?)

· Security Information and Event Management (SIEM)

· Data Loss Prevention (DLP)

· Advanced Threat Protection (ATP)

· Cross Domain Solutions

· Classification (What are you using to tag documents?)

Currently:

· SAFE uses CAC for authenticating DoD users. Guest users have no method of authentication and have limited access to the system.

· The current system does not have a native SIEM, DLP or ATP capability. All of those functions are performed as a service through our hosting environment. We currently do not tag documents for classification as we currently only operate an unclassified capability. However, standing up an instance of SAFE on SIPR may require that mechanism.

File details come from the government source that posted it. Updated .