While SNMP is a great tool for what it does, it only solves part of the problem. SNMP is an agent-based polling solution, and its abilities are thus limited to performance monitoring and visibility within a “poll cycle.”
With polling solutions like SNMP, many organizations may experience false positives if an outage occurs and is resolved between polling cycles – which, depending on the configuration, can be 15 minutes or longer – which contributes to a false sense of security, availability, and compliance. Furthermore, when a machine is being configured, from a hardware, operating system, or network perspective, SNMP is not the tool to provide visibility into configuration activities.
The major difference between ConsoleWorks and SNMP is that ConsoleWorks monitors people – privileged users – whereas other tools log the results of human activity through events that are not always clear enough or contain enough detail.
The level of messaging that is different with ConsoleWorks versus SNMP and other polling solutions is the people log, the people messages, the people alerts and alarms – both on the running OS and when the machine is in single user, configuration, service, or maintenance mode.
Read more about The ConsoleWorks® Difference versus SNMP
Event detection is the logical beginning of the event lifecycle, and where I’ll start my in-depth discussion of complete Event Lifecycle Management.
ConsoleWorks events are primarily text patterns defined by vendors that have been processed by TDi Technologies into an Intelligent Event Module (IEM). IEMs encode the event patterns of the predefined manufacturer’s events along with each event’s severity rating and human-readable description. The log files are then scanned for changes in real-time to detect any events that have occurred.
In addition to the predefined vendor event definitions, these patterns can also be customized text strings defined by the user for their own applications or systems.
Other event detection capabilities of ConsoleWorks include securely scanning for application log files in the event streams, including Syslog, SNMP traps and other monitored assets. ConsoleWorks also uses a sophisticated and intelligent search and comparison engine to look for defined event patterns and create alerts for correlated events that occur during a specified timeframe.
The ConsoleWorks solution automatically evaluates, analyzes, and sets the proper event priority for each event. Events include the vendor’s recommended priority or severity, the human-readable event definition, and the vendor-recommended actions (when available).
For an overview of Event Lifecycle Management, check out my previous blog article: Event Lifecycle Management and its Value in the Compliance Process
For additional information on event detection and the ConsoleWorks® Complete Event Lifecycle Management Solution, download the Solution Brief: A Complete Solution for Event Lifecycle Management
CIP-005-4 is focused on Electronic Security Perimeter(s). Section R5 is titled “Documentation Review and Maintenance” and is further defined as:
R5. Documentation Review and Maintenance — The Responsible Entity shall review, update, and maintain all documentation to support compliance with the requirements of Standard CIP-005-4a. R5.1. The Responsible Entity shall ensure that all documentation required by Standard CIP-005-4a reflect current configurations and processes and shall review the documents and procedures referenced in Standard CIP-005-4a at least annually. R5.2. The responsible Entity shall update the documentation to reflect the modification of the network or controls within ninety calendar days of the change. R5.3. The Responsible Entity shall retain electronic access logs for at least ninety calendar days. Logs related to reportable incidents shall be kept in accordance with the requirements of Standard CIP-008-4.
There are really two categories of information this section refers to: 1) Access records and 2) Reportable incidents. ConsoleWorks automatically captures and generates compliance records for privileged user access over all interfaces managed by ConsoleWorks. The information ConsoleWorks captures includes each access (what was accessed, who accessed it, when the access occurred) along with the actual down-to-the-keystroke records of what was actually done in each of these access sessions. This data is digitally signed to meet audit requirements as a true forensic activity log. Of course, ConsoleWorks does not do this for interfaces that are not managed by ConsoleWorks.
In addition, if desired ConsoleWorks can also capture and record any/all data output by the devices it manages – data that resides in log files or that is output as an SNMP Trap or SYSLOG message. Because there is no real work involved other than minor configuration, the best practices recommendation is to look at both the output stream (information output by the hardware/software of an IT asset) and the input stream (actions taken by privileged users). The capture and reporting by ConsoleWorks is automatic once the system is setup and configured.
Reportable incidents are a different story altogether. These are the events as defined by NERC-CIP that must be detected and then the appropriate action taken based on the nature and severity of the incident. For this issue ConsoleWorks uses its NERC-CIP IEM (Intelligent Event Module) to detect NERC-CIP incidents in the input/output information streams to identify NERC-CIP incidents properly related to the NERC-CIP requirements. Once the NERC-CIP IEM is setup, ConsoleWorks performs detection, alerting, recording, and report generation automatically.
The primary concern in meeting documentation requirements is that they meet internal and external stakeholder requirements with the least amount of effort and manual work possible. ConsoleWorks is directly aligned to this goal, dramatically simplifying the effort behind producing the appropriate NERC-CIP documentation. The information is retained by ConsoleWorks until such time as an administrator archives or deletes it.