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.log-previous then gets cleared so it will hold only the new day's information.
If you have a need to retain this information for more than 48 hours, setup your archiving application to take from SSProtect.log-previous. At any time other than midnight, this file is not being changed or accessed.
Each of these files can be found in the following folder:
IMPORTANT: Avoid direct access to this folder except to read SSProtect.log-previous.log and potentially Install.log.
Logfiles are specific to a Profile. These files are swapped in and out of the same location when you change Profiles, insuring only one specific Account (User) gets associated with a set.
This file holds data specific to install, upgrade, and uninstall though many useful aspects of this process end up in the SSProtect.log file. You will not likely need access to this file.
This file holds most of the log data associated with the software, though :Email specifics are held independently (see below). Because :Email calls into :Expand, which is managed by the :Foundation Client (SSProtect), some of this data ends up in SSProtect.log.
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. Most data associated with protecting and accessing content, from a security standpoint, gets stored in SSProtect.log because the :Foundation Client hosts :Expand. In fact, :Email carries out all security tasks by invoking :Expand commands from the Add-In. It won't take long to understand where you to look for different types of items.
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 SSProtect:Email Outlook ribbon control group. Toward the middle-left of the dialog you will see a control used to filter logged data next to a Show Log button. Clicking on 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 easily email to others. See below to view the UI controls.
For the :Foundation Client (SSProtect), click the notification icon then choose the Display Logfile... context menu item. As with :Email, the logfile is displayed in Notepad for you.
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, reads, then closes target files. This allows SSProtect to continue adding information while you review content. Notepad does not provide any mechanism for dynamically updating file views on change - there are many other applications you can use for this purpose, and it is the one time you may want to access logfiles directly.
CAUTION: Notepad is not a signed executable, and attackers sometimes replace it with their own version to intercept information. Future versions of the software will offer alternatives.
IMPORTANT: If you use a file monitoring program to see dynamic changes to the file real-time, make sure you do not modify and save content to the same folder. Because logfile data is not considered critical, it is not stored in backup form in any way. If you modify or remove information, the data it replaces will be lost forever.
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 bar'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 Reporting and Logs... 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 approach removing filtering altogether.
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 up to and including v2.9.1. This will be adjusted in subsequent versions.
* Trace logging is only enabled by SSProtect Support for exceptional circumstances, and for a limited period of time due to the amount of insight provided into sensitive content. This insures that the settings aren't available for localhost attackers to exploit. Speak to your Administrator for more information.
Utilizing Log Filtering
You want to 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 Debug 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 insure 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 Administration 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.
This article was updated w/ v5.1.1 of the :Foundation Client