SSProtect :Email capabilities execute from the inclusion of an Outlook Add-In managed by the SSProtect :Foundation Client. This is described in the article, Getting Started with :Email. Configuration Settings and thus Policy are further described in the article, :Email Policy Settings. You should be familiar with both articles' content and also general SSProtect file protection before proceeding.
SSProtect :Email was designed with the same philosophy used for all other SSProtect components - provide a protected end-user experience that's easy to use but non-intrusive while maintaining a protective posture (by default). This doesn't generally preclude the ability to remove content from the protective scope of SSProtect (though Release capability can be curtailed), however aims to reduce human error from accidentally exposing sensitive content to ongoing threats.
Expanded Threat With Email Content Exposure
Because Email is often used to share information pervasively, the threat resulting from inadvertently transmitting plaintext content can be elevated, for example when sharing information beyond team, organizational, governmental, and/ or regulatory boundaries. Consider the case of sharing content with a trusted, offshore team. Though members often maintain strong loyalties and adherence to data protection standards, some may be located in countries with a history of government corruption, a low probability of electronic crime prosecution, and/ or a lower cost of living. Though some of these dynamics drive offshore economic advantages, they at the same time may not provide adequate barriers to organized crime, known to traffic stolen information.
:Email relies on protections delivered by SSProtect and KODiAC, both as a method for achieving stability in Outlook data protection, and also as an avenue to reducing risks associated with aggressive, targeted IP theft and malice.
:Email, as an Outlook Add-In, uses SSProtect :Expand to protect content and access managed data. The SSProtect Profile associated with an Outlook Email Account governs behavior, defining the Operating Mode for Attachments while leveraging additional Components for additional data management and Incident Response capabilities.
There are, however, specifics to the manner in which message content and Attachments are protected that have an impact on end-results. In general, :Email benefits from built-in :Access 2FA, :Assess auditing tracking and reporting, and of course :Confidential data encryption - automatically and by default. Additional optional facilities such as :Recover, :xRecovery, and :Respond also apply, though more specifically to protected Attachments than email message body content, as explained below.
Message Content Protection
Email message content - the authored body of an email message - is today protected with Optimized Offloading. As a result, message body content is not immediately available for :Recover/ :xRecovery and :Respond services.
If this distinction is critical to your deployment considerations, contact our Support staff to discuss readily available, custom variations which, in general, lack only the UI necessary to enumerate and select email message thread context for Restoration. This means content would be available for ongoing :Respond usage and future :Recover/ :xRecovery enumeration and restoration, once UI details are resolved and deployed in production facilities.
NOTE: Plans for delivering these changes undergo continuous review, and will be made available based on demand.
Attachment Operating Mode
Email Attachments are protected using the Operating Mode defined by the associated SSProtect Profile. When using Double or Hybrid Conversion, version-based backup content is available for :Recover Restoration. In fact, Attachments in this respect operate like every other SSProtect-managed file, and bring all SSProtect service capabilities to bear.
Attachment Protection Procedure
When you send an Outlook Email message with Attachments, their protection status is governed by the Attachment Policy settings described below. When plaintext Attachments require protection before delivery, they are placed in the Path defined in the Settings' Protected Attachment Location. If a previous instance of the same Attachment filename exists, you will be prompted before content is overwritten.
Existing Attachments, already protected, are not changed and not copied to the Attachment folder - only plaintext items that by Policy must be protected before delivery.
Note that, when using :Recover, this creates a natural, intended, and purposed progression for attached content. If your SSProtect Policy uses Optimized Offloading, you can, if desired, save Attachments then access them independently.
In fact, you can do this with any protected Attachment at any time, though bear in mind that the governing SSProtect Policy's Version Chain Policy applies to any renaming or relocation activities when carried out by the original owner (does not apply to Recipients except when sending data to yourself).
Rules and Policies that govern Attachment protection requirements are carried out when you Send a message, but before it is delivered (whether a New message, a Reply or a Forwarded Message).
What happens when you attach plaintext materials to a protected message (by checking Protect on Send)? Whether a New message, a Reply or Forwarded item, Attachment Protection Policy is governed by the Settings option, Attaching Plaintext Files to Protected Messages, as detailed below.
Deny: Require with protected messages
With Deny, when you choose Protect on Send and attach plaintext content to the message, then try to Send the message, :Email will preclude message delivery and present an error. This can be fixed by removing all plaintext attachments and/ or replacing them with SSProtect'd content.
Confirm: Permit Send with plaintext attachments after prompt
With Confirm, when you choose Protect on Send and attach plaintext content to the message, then try to Send the message, :Email will prompt you with a notice that you've attached plaintext content to a protected message. This allows you to confirm your intent and deliver the message as-is, or instead return to the message and make the necessary adjustments.
This is a viable option, as sometimes very large attachments do not need to be protected, for example binary files, non-sensitive images, etc.
Auto: Convert plaintext attachments on Send; Stop on Fail
With Auto, when you choose Protect on Send and attach plaintext content to the message, then try to Send the message, :Email will automatically convert plaintext attachments to protected content before sending the message. Further details on how protected content gets managed are included after this section.
Permit: Send without confirmation (Not Recommended)
With Permit, when you choose Protect on Send and attach plaintext content to the message, then try to Send the message, :Email will ignore the contrasting protected message and plaintext attachments, delivering the message without interruption. This is, as noted, not recommended since it's easy to overlook intent and attach sensitive plaintext content to an externally-bound recipient, for example (who with protected content would need to be an Organization sharing peer or Third Party Trust for access).