Tripwire’s Energy and NERC Compliance Working Group virtual event offered some enlightening information, not only from industry experts but also some candid thoughts from current Tripwire customers. Even the most cogent summary of the keynote, as well as two of the sessions, simply cannot do proper justice to the knowledge that was shared during the event.
I had the pleasure of demonstrating some of the new features of Tripwire’s State Analyzer (TSA), as well as sharing some tips and tricks that are made capable in the latest release.
Tripwire State Analyzer is an appliance. It integrates to, and works with Tripwire Enterprise. In case you are unfamiliar with the State Analyzer, a quick way to describe it is that it collects element-version data from Tripwire Enterprise (TE) for ports, services, users, shares, and routes. TSA then compares the information collected from TE to lists of allowed items. It provides lists showing the status of every one of the constituent parts of the environment, including referencing the element-version data to determine if those items have changed and if they’re on the allowed list. It then sends that assessment data to Tripwire Enterprise. You can filter it within the State Analyzer, or Tripwire Enterprise for the reporting of the allowed list information.
Tripwire has partnered with FoxGuard to integrate with TSA. Leveraging FoxGuard’s data into TSA makes the patching process much more efficient by helping validate and advise which patches are critical and necessary.
When information is gathered by TE and stored, that data is then sent from TE to TSA. An assessment is run of this endpoint data against the lists of allowed and expected objects. (Open ports, for instance; Are all of the ports that were found allowed and documented?)
You can run reports out of Tripwire State Analyzer (TSA) to show the NERC CIP baseline for ports, services, users, software, etc. You can filter the information in the report exports from TSAand the port screen lets you see whether your NERC CIP baseline ports are in compliance. If you are running an application, such as Splunk, you may see a failure for port 8089 if that port has not been added to the allow list.
TSA also sends all of the assessment data down to Tripwire Enterprise whenever an assessment is run. The reports from the assessment can be reviewed in a TE dashboard for compliance with the allow lists. Changes to the assessment of each endpoint is tracked in Tripwire Enterprise, and every assessment generates a version of the assessment in TE. This gives you a history of the state of each system over time.
Changes made to the Allow Lists are tracked in TSA, which is important for NERC CIP reporting and auditing in general.
If you want to create an asset tag, or group some assets in State Analyzer (TSA) in a way that doesn’t exist in Tripwire Enterprise (TE), you can create a new tag set. Once the new tag set is created, you can add tags to it and then associate assets to the new tag. As an example, if you have an application on three systems and you want the allow list to only include those three, you can use that tag from State Analyzer. No, it does not push these new tags back down to your Tripwire Enterprise console. The TSA tags are only kept in the State Analyzer. This allows you to apply Allow List settings to assets that span more than one TE console in an easy fashion. Just use your new Asset Tag that spans the assets on the consoles.
The State Analyzer offers built-in, as well as customizable user control settings (Role Based Access Control, or RBAC). An Adminstrator in TSA can assign other analysts to various roles. The console displays the effective roles, and you can customize an analyst’s access to show only particular environments, such as specific operating systems. For example, this allows you to set up a person to be able to only access the Windows tags or just the Linux tags. Since Cisco devices are in another tag group, these analysts would not be able to see those Cisco devices.
In the TSA GUI there is a way to archive TSA system logs, but you also have the ability to record events as they happen for both recording as well as audit purposes by configuring the TSA Syslog forwarding. This can be done either through an SSH connection to the State Analyzer appliance and then using the command line application. The Syslog messages are then sent over to your Log Monitoring application. Using Syslog forwarding is highly recommended for audit purposes.
For NERC CIP audits, a really important feature is the custom field settings. This allows you to add a field for entering the justification the ports, services, users, etc. that will be monitored on each system.
For instance, if you have a port that is required to be open for a particular application, the ability to document the justification for why that port is necessary is expected as part of an audit. For non-NERC CIP applications, being able to generate a custom field to document why the object is allowed or even adding documentation for what the software or port is used for is very helpful for any admin that comes along later.
Along with that, you can make the custom fields a requirement when an allow list item is created or modified. So, if the justification is not specified and it’s a required field for your audits, the allow list editors will be forced to fill in the custom field if the required flag is checked.
Now, having a required field does have ramifications for importing allow list items from a CSV file. When you do the import, if you forget to fill in a field that is required you get a message saying that it failed to import. So, make sure required fields are always entered in CSV import content.
Another example custom field is Ticket Number. If your organization uses ticket numbers to keep track of change requests, but you do not want those numbers displayed in the State Analyzer reports, it can be hidden from those reports by selecting the option for that field to not show in TE Reports. Then the field will show up in TSA, but not in the TE reporting for those items.
We really make sure that ease of auditing is in place. Using custom fields for Justification, Documentation, or Ticket Numbers are just some of the example fields you can setup.
An area that can take a bit of work is addressing unauthorized items, especially when first setting up a new class of asset in TSA. For example, if you add a new Windows 2022 server and you haven’t had Windows 2022 in the environment before, an assessment will generate a lot of unauthorized software installed and it will need a lot of updates to the allow lists to justify and document the required packages.
An easy way to handle this is to export the unauthorized items into a spreadsheet. Then, you can view it side-by-side against the State Analyzer and see what allow list items you have for Windows that require Windows 2022 as well then update the allow list items to include the new platform. You can add a quick filter with the service name and add Windows 2022 to the operating system and save it. Then, the history will show where you added Windows 2022, and another handy feature for audit compliance is the change reason which will pop-up after the edit and document the change reason. This works for services, software shares, open ports, or whatever you have a lot of. Exporting the list, and viewing it side-by-side makes the task so much easier.
Tripwire State Analyzer give you visibility into critical aspects of your system to ensure only ports, software, users and such that are allowed to be on your critical systems are the only things that are installed and running there. Using the tips and tricks above help make working with Tripwire’s State Analyzer simple, reportable, and auditable.
If you’re looking to learn more about the industrial cyber threat landscape, the relevant frameworks you can use for ICS security, and how to gain organizational buy-in for your industrial security program, you should download our Navigating Industrial Cybersecurity: A Field Guide to learn more.