This article shows you how to access host log files for both the :Foundation Client and :Email.
SSProtect records host-specific log information in several files:
These files are located inside your Windows user profile storage space but not in an area typically shared with Domain resources - this information (and all SSProtect host configuration data) remains local to your host computer.
SSProtect.log holds one single day's information. At midnight (local time according to your computer), SSProtect.log replaces SSProtect-previous.log then gets cleared so it will hold only the new day's information. This process also applies to the noted :Email log.
Logfiles are specific to a Profile. These files are swapped in and out of the same location to Profile-specific subfolders as required by the active SSProtect User.
Long Term Storage
If you have a need to retain this information for more than 48 hours, setup an archiving application to copy the previous day's log files at any time other than midnight, local time, preferably from the Profile's subfolder. Make sure, when possible, that your application reads data using shared access (not exclusive read or read/ write).
Each of these files can be found in the following location (browse Profile subfolders for details):
IMPORTANT: Avoid direct access to this folder except to read the noted previous days' logfiles.
This file holds all log data associated with the software except that specific to :Email, which is held independently as previously noted and further explained below.
Note, also, that this file also includes :Expand processing, which :Email relies on to carry out protective tasks.
As noted above, each SSProtect.log holds only one day of information. This file holds the previous day's content, and it gets replaced at midnight (local host time) each day.
This file holds information specific to the :Email Outlook COM Add-In. This includes specifics to the way :Email interacts with Outlook, static :Email configuration (Policy), and :Expand calls also reflected in SSProtect.log.
NOTE: :Email carries out all security tasks using :Expand.
Accessing Log Data
Rather than work with files directly, use the UI provided by each of the client applications.
For :Email, use the Settings button in the Outlook ribbon's SSProtect:Email control group. Toward the middle-left of the Options display (from Settings), you will see a control used to filter logged data next to a Show Log button. Clicking this button opens the logfile in Notepad, at which point you can utilize Save As... to store a copy in a temporary location that you can then work with or email to others.
For the :Foundation Client (SSProtect), click the notification icon then choose the Display Logfile... context menu item. The logfile is then also displayed in Notepad for you to Save and use independently.
Concurrent Notepad Access to Log Data
Notepad was chosen for two reasons - unless specifically removed it comes with each version of Windows, and also it opens and reads files without holding open file handles. This allows SSProtect to continue adding information while you review (unchanging) content. Notepad does not provide any mechanism for dynamically updating the views on change - there are many other applications you can use for this purpose (such as Notepad++, which now builds dynamic updates into the foundation rather than using an add-on).
CAUTION: Notepad is not a signed executable (at least not this week), and attackers sometimes replace it with their own version to intercept information. Future versions of the software will offer alternatives.
Dynamic Logfile Monitoring
If you use a file monitoring program to see dynamic changes to the native logfile real-time, make sure you do not modify and save content to the same folder unless you don't mind losing information. Because logfile data is not considered critical, it is not stored in backup form in any way. As such, if you modify and/ or lose information, content is gone - SSProtect doesn't provide a fallback.
Accessing Log Filtering
You can change the amount of detail included in the log files by modifying the data log filter provided by each application.
For :Email, choose Settings in the Outlook ribbon's SSProtect:Email control group, then use the dropdown listbox next to the Show Logfile button:
For SSProtect, navigate to the notification icon, click and choose the Usage Reports context menu, then choose the Manage submenu:
SSProtect divides Log filtering into four different groups. These groups manage the 27 major subsystems that make up the :Foundation Client and optional components. Each group's content will become familiar with ongoing use. Categories are detailed at the end of this article.
Modify the dropdown listbox levels debug levels for each category then choose Commit. If you dismiss the dialog without saving changes, you will be notified with a chance to Save.
Log filtering is setup to provide increasing amounts of information as you choose to include lower levels of severity. Filtering is inclusive such that any filtering level includes data at its' severity level and all data at higher severity levels. Thus as you approach filtering for the least severe events, you include more event data. Raise the filtering level to reduce the amount of information placed in the related logfile.
Filtering includes the following levels, listed in increasing levels of severity:
Trace* Includes very specific details related to program execution
Debug Includes state information for trained staff to interpret
Info Includes useful information concerning detailed execution
Warning Notices for issues that may not be errors; worth investigation
Error Provides error data not always reported to end-users
Severe Failure cases that are almost certainly unusual problems
Critical Failure cases that require immediate investigation
System (:Email-only) Problems with and/or related to host resource interaction
Note that Info and Error logging levels are slightly different (and may be reversed in verbosity) for :Email. This will be adjusted in subsequent versions.
* Trace logging is only made available with coordination by SSProtect Support given the amount of data pushed to the logfile and its' impact on performance.
Utilizing Log Filtering
You should execute the program using the least-intrusive level of logging available, which is either Critical or System depending on which application you're using. The software does not provide a way to disable logging because significant problems need to be listed so that issues can be quickly associated with major problems.
However, when you encounter an issue without a clear solution, you can change filtering to reflect the level of information required to troubleshoot then return to the software to reproduce the issue. Once you have achieved that objective, we recommend you first return to logging and adjust the filter to the standard level you've chosen to use in normal circumstances then review the more detailed information (with or without Support).
Granularity and Performance
The less severe logging levels typically include more information than levels that require higher severity before recording information (but not in all cases). Less severe logging also includes every more-severe logging level thus the amount of data being recorded grows quickly as you move from System-level logging to Trace-level logging.
If you have a large amount of information managed by SSProtect, Trace and Debug logging will result in a visible performance impact. For this reason, we recommend using an Error filtering level, or greater (Severe, Critical, or System) for normal operation.
SSProtect Component Categories
Each of the four major SSProtect Log Categories is listed below, with a short summary of the category's subsystem to help you determine which components to adjust.
This is the category comprised of the fewest number of subsystems, though it is not the least complex by any measure. Within this component you will be adjusting output from:
This subsystem manages secure network communications between the client and server, and is responsible for encrypting, hashing, and authenticating messages while verifying their integrity and readying data for dispatch.
Request/Response Data Marshaling
With over 400 different messages, Marshaling translates application-level information into formats that can be utilized by the Protocol layer to form network messages. This layer also acquires response data from the Protocol layer and manages dispatch to waiting senders ready to interpret results in their own specific formats.
This subsystem forms all data packets that utlimately go onto the wire. While Comms Crypto implements the actual encryption and hashing, the protocol layer is responsible for invoking the proper setup calls and collecting results into network byte format. This layer differs from Packet Marshaling in that it works directly with bytes on the wire, whereas Packet Marshaling manages input to and output from the protocol functions.
The Protection category manages subsystems that are specifically focused on access to and management of protected information in file/ email format. This category is often also referred to as the File category.
This subsystem handles configuration and management of protected files, more specifically all actions and resources associated with the Protected Files display - for locally protected files, the list of encrypted cloud-stored files, and individual protected file versions.
The layer works directly with the filesystem driver to monitor, manage, and intercept requests to managed files residing in mass storage. This is the layer responsible for encapsulating user workflows to ensure access request dispatch authentication, task authorization, and data integrity are retained while seamlessly acquiring, converting, and presenting data to native applications - or performing the reverse by converting stored information to remote-secure storage and/or managing cryptographic offloading and result integrity.
The File List layer provides an interface between the File Filter and configuration/ policy data required for conversion (encryption/ decryption) and access control. This list holds attributes associated with files and policies for managing various circumstances in a centralized fashion for other subysstems to access quickly, consistently, and accurately.
This layer provides extra insulation and encapsulates data distribution primitives designed to expose an individual's policy layers to Administrators and peers. This forms the foundation for real-time data sharing and distributed configuration persistence among peers when other wish to leverage existing configuration sets and/or distribute data seamlessly.
The Filter List manages individually protected items, taking care of their state and whether or not they are shared or, "owned" items. This layer interacts with both the file filtering mechanism and also Explorer Icon Overlay state processing.
The Restoration subsystem handles all aspects of seamless Backup/ Restore of protected content, completely insulating others from the very existence of cloud-based data persistence - both in terms of reflecting local protected access changes to remote cloud storage and also acquiring versioned history lists and instance data not readily available from local storage resources.
The Conversion category manages all aspects of encryption and decryption for managed data. This does not include cryptographic primitives for secure networking, though does utilize this layer to provide cryptographic offloading and two-factor authentication. This is the heart of SSProtect's :Foundation Client (the :Confidentiality and :Access subsystems).
The subsystem handles all aspects of two-factor authentication, managing software-based credential generation and/or dispatch of hardware handling This layer is also responsible for the progressive processing of Last Login information, server state, and dispatch of Enhanced 2nd-Factor Login proceedings.
Different from Comm Crypto, this handles all major cryptography functions associated with converting files - RSA and AES encryption/ decryption (vs. hashing and DH key exchange for CommCrypto).
This subsystem handles logic associated with encrypting and decrypting protected content, and involves both Modes of operation along with dynamic prompting for switchover to Optimized Offloading, when appropriate.
The calculation of software-based OATH OTPs based on the stored Moving Factor and Secret gets handled by this layer, which is also responsible for protecting these assets as if they were being used as the primary way of protecting managed content.
The Workflow is the logic behind managing an encrypt or decrypt operation, which manages eight major operations - encryption and decryption for locally shared content, external Third Party Trust sharing, and all combinations of these with both Modes of protective operation.
These are the icon overlay DLLs that plug into the Explorer Shell to both detect new content as users navigate through folders and also determine content state, i.e. encrypted, shared encrypted, or not encrypted.
All remaining subsystem logs are managed by the Admin category, which includes Startup, Administrative task coordination, User configuration, and administrative aspects of runtime file conversion. Administration also includes all UI display and most configuration storage, overlapping duties with the Protection layer for local/ remote persistence insulation.
You can search this site for more information on various topics, or use this link to submit a specific request. You can also send email directly to firstname.lastname@example.org, and our staff will respond to your needs as soon as possible.
In the meantime, don't forget to check out our primary website and Insights columns for information on current trends, security topics, and how our technologies relate.
This article was updated w/ v9.1.3 of the :Foundation Client