PROJECT: Secure Messaging Platform
The Secure Messaging platform enables protected information exchange to both internal and external users with minimal disruption to existing email architecture and user workflow
Using the Secure Messaging platform doesn’t mean replacing any technology or applications that are currently in place including email addresses and /or email programs.
The Secure Messaging platform acts as a secure message gateway by adding a more reliable protocol that sits on top of existing email infrastructure while remaining completely backward compatible with existing systems It is offered both as a Cloud client-side deployment with a plug-in the mail client
In a Cloud deployment, no perimeter gateway is required. On ‘SEND’, the application client, intercepts the command and re-routes the message via HTTPS securely instead of sending the encrypted message via SMTP. At this stage, the transmission is encrypted.Once transferred securely to Secure Messaging platform, the message content & file attachments are encrypted ‘at rest’.
In contrast, the Secure Messaging Platform utilizes a closed-loop of secure and redundant servers for all secure communication and manages all secure messaging functions including message transport, encrypted database storage, archiving and tracking.
When a user sends a secure message, a direct and secure connection is established between the sender’s email program (e.g. Mozilla Thenderbird) and the Secure Messaging platform server. When a notification message is received, the users use their existing email programs (such as web & mobile enabled Secure Message Center (Webmail) to directly and securely connect to the Secure Messaging platform to decrypt and read the secure message, file attachments and associated metadata contained in the patented 'Delivery Slip'.
Information exchanged securely can only be accessed by authenticated users (email address and password, or more is required upon registration). Confidential information in secure messages can only be viewed by the users that they are intended for Secure messages are stored encrypted using industry standard encryption methods through the use of the Interchangeable Cryptographic Engine and can be adapted to the organization’s needs.
The default configuration uses AES 256-bit encryption for data-at-rest storage - instead of over the internet on unprotected, public SMTP servers, such as with basic email (even if emails are encrypted). AES 256-bit is the only publicly available cipher certified for official government documents classified as 'Top Secret’. It
eliminates cross-contamination of data with our multi-tenanted Cloud offering and ensures that the organization's data is not tampered with or edited over time, and is automatically archived indefinitely.
The platform has three major components:
1) Secure Messaging platform server
2) User Access programs (Applications)
3) Secure Messaging Directory
This modularized set of phyton or C, assemblies implements the core of the functionality provided by the Secure Messaging platform and includes functionality in the following areas:
Authentication services such as validating credentials, retrieving forgotten passwords, registering new users
Messaging services such as sending and receiving secure messages, creating draft messages, recalling secure messages, uploading and downloading file attachments
Tracking services such as obtaining tracking information for groups of secure messages; obtaining detailed tracking information for specific secure messages
Administrative services such as provisioning members, configuring feature settings, generating usage reports.
All these modules manipulate data via queries to the Data server (via the Data Layer) and / or the Cache server when available. All functionality provided by these modules is restricted to the privileges assigned to the session making use of other subsystems like Caching, Crypto Engine, SMTP Server, and other common libraries.
The Secure Messaging platform supports a rich set of extensibility options at the message and user’s profile levels allowing the integration of the secure delivery functionality provided by the platform with specific line of business applications. For example, secure messages can be extended to store extra information for a secure form submission where each secure message’s extra fields in the submitted form can be stored with the message as a transaction. The user profile may be extended to store customer-specific
information about users, such as their customer ID, employee number, etc. Extensible information can optionally be stored encrypted in the system, providing the same level of security than what is offered for secure messages.
The SQL database schema is comprised of a collection of tables, user functions, and store procedures created under a dedicated SQL user. This allows full isolation of the content of the customer platforms hosted in this database instance, and allows database administrators tighter control for accessing this information.
All the sensible information in the database is stored encrypted on a per customer basis. This includes message content, file attachments, file attachments references, user information, and more.
Secure messages contain both confidential information (the content and file attachments), and metadata that describes the message attributes available through the patented Delivery Slip. The metadata is stored unencrypted in the database to improve performance.
For example, the list of recipients and subject line of a secure message is stored clear in the database so that search operations can be implemented in an efficient way taking advantage of the relational model provided by SQL Server. However, this opens the possibility for potential issues with accidental or premeditated unauthorized changes directly in the database. For this reason, and to facilitate auditability operations when a secure message is stored in the database, the entire metadata information associated to the message at the time is also encrypted along with the content of the message (as a snapshot).
The Data layer encapsulates the logic of the database, allowing greater transparency and independence of the specific SQL engine used. The in-memory objects and collection of objects are passed back and forth via this layer allowing a higher degree of independence of specific RDBMS engines.
This Data layer takes care of using the appropriate database credentials used to communicate the modules with the SQL engine. The Data layer also takes care of creating and managing a database connection pool available to the modules running in the same instance.
The File server handles the storage and retrieval of encrypted files from the file system. It is used primarily to store/retrieve file attachments, which are stored not only encrypted, but also in chunks in a common files repository.
The location of these files in the file system is stored encrypted in the database. The File server can be optionally deployed to other servers to distribute the server load of encrypting/decrypting files and to make use of cheaper SAN-based storage units. This decreases the demand over the Application and Data servers and enhances scalability. Optional antivirus checking is executed at this stage in a background process.
As part of the messaging features provided by the Secure Messaging platform, the system sends message notifications to users using regular email via the SMTP protocol. These notifications, or stubs, do not contain any sensitive information and are a simple vehicle users are notified of new secure messages or other system activity.
The SMTP server delegates the sending of email notifications to a background process. Other modules using this component call its commands to create a new notification request, which is then placed in a queue (ProcessQ) where a background process reads from the queue and delivers the notification messages as they arrive.
This architecture allows great flexibility to configure this service in an isolated, dedicated server if needed for scalability and availability purposes.
The pre-configured how SaaS SMTP service is available on demand. This minimizes the chances of being flagged by spam filters when customers do not have a reliable email infrastructure to take the responsibility of delivering thousands of email message notifications.
Alternatively, customers can configure their own STMP outbound through the Web Admin Console so that all notifications are delivered from their own organization.
We work closely with market leaders in email deliverability space to maximize the chances of these email notifications reaching the intended recipients. These external SMTP providers continually monitor the reputation of the email notifications and proactively approach the major ISPs all over the world to protect the reputation of the default SaaS SMTP feature. Should a deliverability issue arise, our SMTP providers engage the problematic ISP directly to resolve the issue.