- The best foldable phones of 2024: Expert tested and reviewed
- Redefining customer experience: How AI is revolutionizing Mastercard
- The Apple Pencil Pro has dropped down to $92 on Amazon ahead of Black Friday
- This tiny USB-C accessory has a game-changing magnetic feature (and it's 30% off)
- Schneider Electric ousts CEO over strategic differences
Tips, Tricks and Updates for Tripwire’s State Analyzer
At the recent Tripwire Energy and NERC Compliance Working Group, we held a session to demonstrate some tips and tricks to make the latest Tripwire State Analyzer (TSA) work better for your organization. The newest State Analyzer version is 1.5.2, which offers features that align it with most of the latest systems and practices. It also includes improvements with its integration with Tripwire Enterprise (TE).
Active Directory Integration and Assessment Results
Tripwire State Analyzer manages Allowlists and then takes the managed allowlist data and compares those lists to the actual data gathered by TE via the element version data. These are assessments of your systems against the expected (what’s allowed according to the allowlists). This helps you automate the approval of compliant configuration items. TSA sends the results back to Tripwire Enterprise, and that is where most reporting will originate, but it is possible to run reports in TSA as well.
For example, if you are seeking to justify a list of ports on an Allowlist, the Axon agent or Tripwire agent can pull that data to compare it to the Allowlists, producing a record of approved and unapproved ports. This makes reporting of NERC CIP 010-R1 a lot easier. TSA manages allowlists of ports, services, software, users, groups, routes, and shares that auditors look for based on the CIP standards. TSA allows you to produce a report of the findings, providing a NERC CIP baseline of the current allowed information on those systems. If an organization needs this information for their NERC CIP documentation of the Tripwire State Analyzer Appliance itself, Tripwire provides allowlist entries for each of its products as a starting point for the allowlists. That is available in the assessment documentation as well.
Running Assessments of the systems can happen in two ways; based on a schedule, or whenever TSA gets updated information from TE. How TSA behaves when new data is received is based on an option that can be set in the Preferences page. Just check the box labeled “create assessment results automatically on TE after each query rule run” in the Allowlist basic settings. When this setting is checked, as new data comes into TSA during TSA Rule checks in TE, the new data is assessed immediately, and the results are written back to TE Reports as the assessment completes. This happens practically in real-time.
The interesting part about this is that the automatically running assessment won’t change the counts in the Allowlist assessments page of TSA. The is because these assessments happen in the background. If you want to see the current results in the TSA console as well, then either schedule the Assessments to run on a schedule or run them manually when you login to the Assessment screen.
Agentless Port Monitoring Tip
Sometimes, when scanning for non-agent based devices using NMAP, the data never reaches TSA for assessment. The reason that this occurs is because the NMAP Document Type Definition (DTD) check is failing. This will show up in the TE supervisor logs. This may be due to an old version of NMAP causing the DTD check to not find what its expecting. You could check the DTD and update to a newer version of NMAP that works with the DTD, substitute an NMAP DTD that is correct for your version of NMAP, or just move the DTD check file out of the external directory under the TSA supervisor. This will result in a correct reading of the NMAP files and the expected assessment of the network devices.
Managing Allowlists
Ephemeral ports can create problems on Allowlists. When a port is flagged as a violation, the assessment can be changed to “make allowed,” but the port would change upon a subsequent restart of a Windows system. Over time, this could result in hundreds of entries for the same port on a system if you just keep allowing them one at a time via the “make allowed” feature on the Assessment page. If you add that to the fact that many customers don’t use Groups for the Scope of the Allowlist entry, you end up with a lot of essentially unnecessary allowlist entries bogging down performance. If you have 100 Windows systems and one service that uses up to 1000 different ephemeral ports over time, you could have 100,000 allowlist entries to cover 1 service that runs on your Windows systems.
One way to get around that is to apply the Allowlist to a group rather than a single system, and to a port range instead of just a single port. For example, if the EventLog service is running on all the Windows systems, it can be specified for port 49000-50000 on all Windows systems, note the justification, and save it. A full range can be defined for the service. Attempting to manage ephemeral ports individually on each system causes the Tripwire assessment to take a lot longer because it creates more entries to join in the database to determine whether or not that port is allowed on that system. Groupings is a time-saver, as well as an efficiency enhancer for TSA. By reducing these entries, it is possible to turn 100,000 potential allowlist entries into 1 entry. This will result in TSA running faster, and more accurately, while covering the system as the port changes over time.
Another way to manage the Allowlists is to export the list to a CSV file and then sort it to find all the versions of a particular software in the environment. You can then turn that software entry into 1 package that covers the installation of that package. For instance, on Linux systems the Audit package is made of up “audit-libs-x86-64-Red Hat, Inc.”, “audit-libs-python-x86_64-Red Hat, Inc.”, and “audit-x86_64-Red Hat, Inc.” and all at version 2.8.5-4.el7. Since they’re all part of the same package and all of the save version, check the RegEx box in the Allowlist Entry under the Software Name, and make the entry “audit-.*” and list the version. You’ve gone from 3 entries to 1 across all RHEL systems – and apply this to all RHEL systems (this same entry can also apply to CentOS as well). That list can then be used to reduce all of the individual entries across an enterprise. Using a range for ephemeral ports, groups to combine assets with like configurations, and creating Allowlist entries that include as many things as possible allows the assessment to run a lot faster.
Other Notable Updates
Java 11 Support
Tripwire State Analyzer 1.5.2 now has Java 11 support for the TE supervisor. The supervisor is the piece that is installed in the Tripwire console, and communicates between the Tripwire Enterprise server, and the Tripwire State Analyzer appliance. The Supervisor communicates bi-directionally, sending updated element data to TSA, and writing assessment information back into TE. The Supervisor runs with Java and now is Java 11 supported. If you have upgraded to Tripwire Enterprise 9.0 and you’re using Java 11, the supervisor now also uses Java 11, enabling the removal of Java version 8 completely from your Tripwire Enterprise console.
Timeout Value Configuration and other new features
Configuration assessment timeout values are now manageable in the Allowlist preferences. This streamlines the assessment process by preventing the process from running endlessly, but also if your assessment takes longer than the default timeout, you can change the setting and give your assessments more time.
Transmission Control Protocol (TCP) dump is also available via the Tripwire State Analyzer command line, allowing communication issues to be researched much more efficiently. TCP dump can show the information that is being set to the State Analyzer.
Registry Discovery Updates
The TSA “Windows software” rule was updated to find more software packages. The configuration settings have been updated to include all the registry keys where the software is installed. This goes beyond the Global Variable that controls uninstall registry key listings. We worked with Microsoft’s engineers to gather a more accurate listing of all the software installation locations. This will help the assessment process to reveal the presence of software that the old rules didn’t find. The rules have been updated to look everywhere. The option to use the old rules is still available. As long as the data that gets pulled in by that rule is produced in the right format that TSA is expecting, it can work with the data. This enables options if you don’t want to capture all the software.
The latest version of Tripwire State Analyzer is another way that we are seeking to improve our products by listening to our customers. The Energy Working Group allowed us to interact with those in the energy sector. This helped us to gather even more information about how to make future improvements. To find out more, please visit us here.