Updated Jan. 23, 2024

Overview

The PreVeil solution provides secure messaging and file sharing to customers by making true end-to-end encryption (E2EE) and zero trust easy to use and manage. National Security Agency (NSA), International Traffic in Arms Regulations (ITAR) and other compliance schemes including DoD Cybersecurity Maturity Model Certification (CMMC), can include the use of E2EE and zero trust principles as secure means to protect and secure controlled or sensitive data.

Companies can adopt PreVeil and use it for internal communications and collaboration, and also interact with their partners or supply chain companies to protect information within the Defense Industrial Base (DIB) or any supply chain that requires secure, compliant collaboration between companies.

PreVeil complies with many applicable Department of Defense (DoD) Defense Federal Acquisition Regulation Supplement (DFARS) and National Institute of Standards and Technology (NIST) supply chain requirements including most of the Cybersecurity Maturity Model Certification (CMMC 2.0) Level 2 controls needed to protect Controlled Unclassified Information (CUI). PreVeil provides an effective way for a DIB company to meet many CMMC requirements in an efficient way using E2EE and PreVeil’s robust information assurance features as part of their compliance program.

What Problem Does Email Gateway Solve?

The PreVeil system is based on E2EE, meaning that only the endpoint devices have the means to encrypt or decrypt content, not the server. E2EE uses the PreVeil software installed on the endpoints to access encrypted data or the web-based PreVeil Express. Stored encrypted data cannot be seen by anyone; not even PreVeil admins or AWS GovCloud admins.

The problem that the PreVeil Email Gateway solves is for those cases where not every user that your company interacts with has a PreVeil endpoint. They may be DoD supply chain partners unable to install the PreVeil software on their computers or mobile devices; or they be unwilling to do so. In this case, E2EE cannot be used, but the compliance boundary and data protections must be maintained between these companies. That’s where PreVeil Email Gateway comes in.

Gateway Example – CUI Ingress and Egress

CUI may be “received from” or “sent to” a third party that is not using PreVeil. Without E2EE in place, the compliance boundary is maintained in such a way that CMMC Level 2 guidance can be met. The third party may be DOD agency, or prime contractor or supply chain partner on a contract including CUI; that for whatever reason cannot run PreVeil on their devices.

Open

What is the PreVeil Email Gateway

The Email Gateway is a PreVeil-furnished software solution the runs in the customer environment, either in the cloud or on-premises. The Email Gateway software includes 3 main components: Message transfer agent, service business logic, and PreVeil client as shown below.

Open

User Experience - Subdomain

In order for the Gateway to route messages correctly, a special subdomain must be claimed and assigned to the Gateway email traffic. The users will experience a seamless Email communication via the Gateway. In this example, auburn.edu has added the subdomain secure.auburn.edu to designate CUI traffic that gets routed through the Gateway. All email that lacks the subdomain would route through the regular commercial (non- compliant) Email system as normal. All Email with the subdomain will route through the Gateway and remain separate from the other commercial Email systems.

 For example, joe@xyz.mil can send a message to alice@secure.auburn.edu that will be routed through the Gateway to/from Alice’s PreVeil encrypted mailbox seamlessly. And Alice can originate or reply to Joe’s Email just as easily from her PreVeil encrypted mailbox. No additional Email accounts are needed, the subdomain is only used for routing. Alice must notify Joe that he will use the secure.auburn.edu address when sending CUI to Alice.

Non-PreVeil Email sent to alice@auburn.edu (no subdomain) will be routed through the commercial Email system (in this case O365 Exchange Online). Conversely, Email routed via the Email Gateway will never travel over the commercial company Email system.

User Experience – External Sender

The external non-PreVeil sender joe@xyz.mil uses the alice@secure.auburn.edu address to send CUI to Alice. The Gateway handles address translation and the PreVeil client inside the Gateway forwards the message to Alice’s encrypted PreVeil mailbox as normal (alice@auburn.edu). Alice can read and reply to these messages in the same way she does with any other PreVeil E2EE users. There are no changes to Alice’s PreVeil account, and no additional accounts are needed. In this case, PreVeil E2EE stops at the gateway, and outside the Gateway the Email transaction will take place according to how the MTA component in the Gateway is configured as seen above (see certificates topic below).

User Experience – Internal Sender or Reply

It works the same in reverse; simply Reply or compose a new message from alice@auburn.edu to joe@xyz.mil. Inside the Gateway, the addresses are transformed so that Alice’s email is decrypted and will now be sent from the Gateway as alice@secure.auburn.edu to Joe. Joe can easily reply as normal to alice@secure.auburn.edu.

Remember, the special Gateway subdomain is only used for CUI-Email routing and does not need to be added to the actual PreVeil user accounts.

Certificates

The use of digital certificates may be required to complete a trusted communication between company and third party not using PreVeil. This will be seen in 2 most common options.

1. Server Certificates are installed on the PreVeil Email gateway MTA to support server to server trust for TLS connections. In the case of server certificates, the certificate is installed and maintained by IT admin on the PreVeil gateway’s MTA component. DoD networks may require a certificate signed by the DoD root, known as ECA certificates.

Admin Experience – External Users

The External users, joe@xyz.mil in our above example, or entire Domains need to be identified in order for the Gateway to handle name translation and reply to messages properly in both directions; inbound and outbound.

The PreVeil admin manages the external Gateway Email users via the admin console. The admin can add/remove users and Domains to the Gateway external user list and only those users can interact with company accounts via the Gateway. This is to ensure rogue or blocked accounts cannot interact with the PreVeil users inside your company via the Gateway, and PreVeil admin always knows who is allowed Email access via the Gateway.

Conclusion

The PreVeil Email Gateway is intended for communicating with external parties that do not or cannot run PreVeil software on their devices. Email Gateway is ideal for cases when this communication is required, yet a separate, cyber security compliance boundary must be maintained by the company using PreVeil. CMMC is required for companies handling CUI, and PreVeil E2EE and admin features can be an essential part of a company’s CMMC compliance program. When combined with the Email Gateway, PreVeil provides a complete solution without compromising company security compliance. The most common way to deploy Gateway is to work with PreVeil’s hosting partner to host and manage the Gateway software for your company.

Of course, the easiest and most secure may to communicate is by using PreVeil’s E2EE capabilities. Interacting securely and privately with other PreVeil users, either individual or enterprise/Org account, inside or outside the company, does not require the Email Gateway. But when non-PreVeil third parties are part of the mix, the Email Gateway is a solution that can help.