Support Site

Updates

New Release! | ConsoleWorks

by

It’s official! We are excited to announce our new features in ConsoleWorks.

New, enhanced usability provides an easy and intuitive view to take action fast.

 

Compliance & Situational Awareness Dashboard

ConsoleWorks Continuous Monitoring and Situational Awareness Dashboards provide a real-time overview of the current state of the environment, enabling security and compliance personnel to quickly analyze data and then take action.  The comprehensive view summarizes the overall state of risk regarding compliance and security.

Security and compliance teams can quickly address gaps, eliminate threats, deny unnecessary connections, and keep security and compliance policies up-to-date and enforced.

The NERC CIP Compliance Dashboard provides a quick view and status of various compliance requirements, such as:

  • Review of asset classifications required every 15 months
  • Review of Privileges required every 15 months
  • Notification if an asset is not in an ESP
  • Notice of Patches identified that have not been addressed within 35 days
  • Notification of Failure to Log
  • Status of Password reset policy violations
  • Notice of Unsuccessful / Failed Login Attempts
  • BCM differences that have not been resolved within 30 days

The Dashboard Widget Designer allows any information defined in ConsoleWorks to be extracted and displayed as a chart. Warning thresholds can be easily set to provide early notifications, allowing time to address issues before compromising compliance thresholds.

Enhanced Operator Interface

ConsoleWorks Common IT / OT Operational Interface provides a single, simplified view that can be customized for individual workflows. The intelligent and dynamic filtering capabilities enable faster issue remediation and problem-solving for both IT and OT environments.

  • Built with a secure foundation with compliance and operations in mind
  • Built on the ConsoleWorks granular, role-based permissions model
  • Inter-widget communications enable intelligent filtering across ConsoleWorks components – Assets, Events, Logs, Tickets.
  • Intelligent Filtering enables faster issue remediation/problem solving
  • Tightly integrated with leading ticketing solutions for faster time to resolution

Download Datasheet

Compliance & Situational Awareness Dashboard Sample

Enhanced Operator Interface

ConsoleWorks Reduces Mean Time To Repair (MTTR) | REMEDIATE – Part 4 of 4

by

The final MTTR process step impact is Remediation. Once we know the problem, we must connect to the asset and perform the Remediation. While that may seem trivial, it often is not. With ConsoleWorks we are either already connected to the asset or simply click on the device’s name and are automatically connected to the asset, ready to perform our remediation. That leads us to an MTTR of Detect = 0, Isolate = 0, Analyze = 0 to (norm – x), and Remediate = (norm – y)?

Additionally, ConsoleWorks can capture remediation activity and assign it to an event as a best practice. Now when a problem occurs there is a distinct possibility that the remediation activity is already there, associated with the event. Because the best practice can include keystroke-by-keystroke instructions for remediation, the actual remediation step is reduced to a simple paste-execute.

For cases where best practices are in place, the MTTR process moves to an effective result of Detect = 0, Isolate = 0, Analyze = 0 to (norm –x) and Remediate = paste-execute to (norm –y).

Basically, for events that an IEM can pick up (and yes – you can change, add, delete, and build your own embedded content in an IEM) the process is intensely streamlined and simplified.

ConsoleWorks Detects the event, notifies you of it, tells you its severity, describes what the event means, has the data you need at your fingertips to troubleshoot the problem and pops you into the asset you need to remediate with one click, and may even give you the perfect set of instructions to remediate the issue almost instantly.

In short, ConsoleWorks will slash MTTR down to a fraction of what we usually experience.

Read the first three parts – ConsoleWorks Reduces Mean Time To Repair (MTTR): Part 1 – DETECT, Part 2 – ISOLATE, Part 3 – ANALYZE

ConsoleWorks Reduces Mean Time To Repair (MTTR) | ANALYZE – Part 3 of 4

by

Looking back at the first and second blog in this series, we see that by using ConsoleWorks IEMs the DETECT and ISOLATE steps are completed automatically in milliseconds (effective value = 0) taking a significant amount of time off of our MTTR. That leaves us with Detect = 0, Isolate = 0, Analyze = ?, Remediate = ?.

The Analyze step requires that we determine the nature of the real problem. In many cases, the events we start with including the issues described by things like Trouble Tickets are only a symptom of the underlying problems. Regardless of what many of us have been led to believe, Trouble Ticket systems and Event Management Systems often identify symptoms rather than root causes – ask any Admin responsible for dealing with those tickets or incidents.

In some cases, the human-readable descriptions from the vendor included in the IEMs will give us enough information to immediately identify the root cause of the problem. In these cases Analyze = 0, netting us an MTTR process of Detect = 0, Isolate = 0, Analyze = 0, and Remediate = ?.

In other cases, we need more information which typically pushes us back to our log files to troll through them for the important tidbits (other events) that can help us identify the root cause of the problem. With ConsoleWorks, that log file information has already been captured, stripped of spurious characters (noise), time-stamped, and ordered line-by-line in the same pane of glass so we can quickly zero in on the root cause of the problem. In cases where information from multiple assets is required to analyze the problem, ConsoleWorks lets us bring up processed log information for up to 4 assets side-by-side in our single pane of glass by just clicking on them. Using ConsoleWorks is far faster than trolling through log files or even log file repositories.

This takes us to an MTTR of Detect = 0, Isolate = 0, Analyze = 0 to (norm – x), and Remediate = ?

Read Part 4 – ConsoleWorks Reduces Mean Time To Repair (MTTR) | REMEDIATE – Part 4 of 4

ConsoleWorks Reduces Mean Time To Repair (MTTR) | ISOLATE – Part 2 of 4

by

In the first blog we identified that ConsoleWorks IEMs automatically capture log-file changes and scan them for vendor-defined error codes. This automation moved the MTTR detect process step from reactive failure with log trolling to real-time event detection. Now that real-time events are detected, the next step is the isolate those events that are real problems.

To do so, we need to understand the nature of the event codes that vendors have defined. These codes rarely tell us much about the problem, and they don’t tell us anything about their severity rating. That means we have to look up each code, see how important the vendor thinks it is (severity rating), and then see what they say about the actual problem the code represents.

Most event code patterns are alpha-numeric identifiers that have no real meaning to a human being, so the ConsoleWorks IEMs serve another purpose – encoding the severity rating along with the human-readable description of the event provided by the vendor.

In addition to real-time notification with no human intervention, the events are textually and visually called out by severity rating so at a glance we know what events signal real problems. Next to the severity rating is a description of the event so we also know how the vendor describes each event in human-readable form. The system automatically displays this information to the ConsoleWorks user – in milliseconds from the time the actual event occurred on the IT asset (hardware or software) eliminating all of the MTTR time typically used to ascertain what has happened. Now the time to isolate the real problem is gone, and whatever it used to be is a direct MTTR reduction. Besides Analyze and Remediate, we have effectively eliminated all of the other process steps that typically go into the process behind our MTTR number.

So now our MTTR impact is as follows: Detect = 0, Isolate = 0, Analyze = ? and Remediate = ?

Read Part 3 – ConsoleWorks Reduces Mean Time To Repair (MTTR) | ANALYZE – Part 3 of 4

ConsoleWorks Reduces Mean Time to Repair (MTTR) | DETECT – Part 1 of 4

by

If you could reduce Mean Time To Repair (MTTR) down to a fraction of what it is now would you do so? Of course, anyone would slash MTTR down if they could and there are a lot of companies who promise just that. Before we look at MTTR reduction, let’s first get a stake in the ground around the process steps that consume time behind the MTTR measure. These are generally considered to be: Detect, Isolate, Analyze and Remediate. We will discuss ‘DETECT’ In Part 1 of 4 related posts.

Traditionally, the process entails trolling through log-files after something has gone wrong in the hopes that we can isolate one or more codes and then research them to see what they mean. This all takes time and occurs after the fact when the MTTR clock is already ticking.

The ConsoleWorks Platform has a different take on MTTR that can greatly reduce MTTR across a wide variety of issues. This capability is called Intelligent Event Modules (IEMs). ConsoleWorks’ base technology under IEMs is the ability to define patterns that represent events of importance that can be generated by a hardware or software asset. These events are embedded in all hardware and software in an IT/OT infrastructure by the manufacturer. If we set up these codes in ConsoleWorks IEMs, we can identify these events.

The IEMs encode the event patterns of the predefined manufacturer’s events along with each event’s severity rating and a human-readable description. ConsoleWorks scans log-file changes in real-time (log-files are tailed to stream new information directly to ConsoleWorks) to detect any events that have occurred.

The automated process greatly reduces the MTTR by proactively detecting events (Detect) in milliseconds as compared to waiting for a failure to occur then trolling logs to find out what might have happened.

So at this point our MTTR impact is as follows: Detect = 0, Isolate = ?, Analyze = ? and Remediate = ?

Read Part 2 – ConsoleWorks Reduces Mean Time To Repair (MTTR) | ISOLATE – Part 2 of 4

CEO, Bill Johnson & TDI Sponsors OT Track at CS4CA | Houston, March 26-27th

by

 

While cybercrime steadily increases in the US, the perceived complexity of data security remains a barrier for organizations to strengthen their cybersecurity strategies. Cyber risks and cybersecurity operations are complex and unique to every circumstance, therefore difficult to quantify. But ultimately, all complexities can be broken down. This is the mission of CS4CA USA 2019, returning for a 7th year to Houston in March 26th-27th 2019. IT & OT security experts unite to elucidate the most advanced cybersecurity information and policies to current and future threats jeopardizing American Critical Infrastructure.

CS4CA USA brings together IT & OT cybersecurity professionals to discuss challenges, debate critical issues and explore new ideas and concepts. Join 250+ experts from across the Oil & Gas, Energy, Utility, Water, Power & Maritime industries in Houston, Texas. The 7th annual Cyber Security for Critical Assets conference boasts a dynamic double-stream agenda with both IT & OT sessions.

TDi Technologies OT Track Sponsor |  Bill Johnson, CEO & Founder of TDi Technologies, will be speaking on the topic, ‘Leveraging Cybersecurity to Improve Operations and Situational Awareness.’

WE INVITE YOU TO JOIN US!

This invitation is complimentary, it includes access to all sessions, a copy of the presentations and 12 points for your CPD qualification. To redeem your VIP Summit Pass use code: TDI at checkout.

 

Claim Your VIP Pass

 

We can help

Reach out today, and we'll talk through how we might be able to help!

Contact us