Managing Your Assets with Tripwire Enterprise

Image

Asset management is a tricky subject. In many cases, organizations have no idea about how many assets they have, let alone where they are all located.  Fortunately, there are tools that can assist with reaching your asset management goals. While Tripwire Enterprise (TE) is great for detecting unauthorized changes on your system and also for ensuring your systems are hardened (as well as stay hardened), you must first get a handle on managing the assets that you’re monitoring.

Tripwire Enterprise makes that task easy if your Tripwire agent is part of your image build. When the instance of the Operating System (OS) is created, the agent activates and connects to the Tripwire console. The agent tells the console what OS is running on the system along with its hostname. The Tripwire console then puts the asset in a group for that OS type. Easy and automatic! 

However, there is some massaging that is needed to catalog the asset the way that works best for your security practice. I have seen various divergences in what people users do to get that asset regularly monitored. In an effort to make your Tripwire experience even better, I will cover some best practices and methods for making the management of assets easy in Tripwire. Easy is what you want; easy is what can be achieved.

If you’re monitoring more than a hundred nodes in Tripwire, then your environment most likely has some “churn” in the assets that are in use and that need to be monitored. Automating the onboarding and offboarding of assets, ensuring that they are tagged correctly and verifying that they have the correct rules applied is a daunting effort without automation. Fortunately, Tripwire gives you options to automate the asset management process in your Enterprise console.

What rules are you running?

The “Critical Change Audit” is the most commonly used rule set shared across the Tripwire customer universe. These rules cover the known critical directory and file locations on the OS. They are the minimum set of objects you should be monitoring on a system. 

One configuration example that is not optimal is to arrange “Tripwire Tasks” by product, location or function, with the same OS rules being run in various tasks. In some cases, a new system that was added to the console but not tagged properly (or linked if one is still using the legacy groups in Tripwire) will result in inaccurate or erroneous monitoring.

To avoid this problem, all systems that are compiled in the console should be automatically tagged. Along with that, OS rules should be run by tasks that use the System Tag Sets -> Operating System option. 

These tag sets vary by operating systems. For example:

• Windows 2016 rules should use the Windows 2016 “System Tag Set” in the Task.
• Red Hat 8 rules should use the Red Hat Enterprise Linux 8 System Tag set in its task. 
• Any new Windows 2016 system or RHEL 8 system will automatically be added to that group, thus ensuring it will always be checked by that Task. 

Once you handle the OS Rules this way, nothing needs to be done manually.

For application rules, there are a number of methods for automatically tagging an asset with the application running on the system. My previous blog on asset tagging covers those methods.

What reports are you running?

The way that your Tripwire Tasks are configured may be totally different from how changes are reported to various teams.

Reports are often sent to the party responsible for that system. So, tagging based on who gets the reports is the next consideration. Automatic tagging for responsibility can be a bit trickier, but often there are IP address ranges you can use or integrate into a Configuration Manager Database (CMDB) where tags can be picked up and applied to your TE Assets.

The same assets that have basic OS rules run against them often have reports that use a different set of tags for the reporting. When a new asset shows up in the console, someone should be responsible for seeing the changes to this asset, that is, the changes that are not auto-promoted.

Some customers have very little report review needed because they’ve automated so much of the process. The changes go through Dynamic Software Reconciliation (DSR) to promote normal patching by comparing changes to patch manifests. Then the next automated process using the TEIF integration to a ticketing system (Service Now, Jira, Cherwell, etc) is set up to auto-promote expected changes to applications. Any changes left that have not followed an expected change process are sent to an event monitoring system for review by security. This leaves little left to review in the TE Reports, and it is the ultimate automation of change handling.

Data retention

Once you’ve processed the change information, it’s time to think about data retention.

Data retention has multiple approaches. One method addresses assets that have been in the console for a long time and have a lot of change data. Another method examines data for assets that are no longer in the environment.  

Retired assets are also a point for serious consideration. Once a system is retired in your environment, the retention period will be determined not only by corporate policy but also by regulatory directives.  

At some point, you’ll need to delete the retired node, and once you delete the node, all of the change data about that node goes with it. These days, many customers are sending the change data into another system for longer term storage. When stored in this manner, auditable change data can be easily accessed, allowing you to remove the node from the live system sooner rather than later. There is no risk of breach in a system that’s retired and doesn’t exist anymore, so there’s little to be gained from that historical data in your Tripwire system. Think of your Tripwire console as a picture of your currently running environment and its system state from one day to the next. When that state changes, you need to know about it. 

It should be noted that assets that remain in the console, handled by the “Compact Element Versions,” is beyond the scope of this current discussion.

Axon Agents

If you’re using the Tripwire Axon agents in your environment, there’s an easy way to accomplish automated removal of retired assets: a task! There are two Tripwire tasks associated with the health/state of the Axon agents:

• A Check Node Connection task attempts to connect to Axon Agent-based nodes in a smart node group at a user-specified interval. If the task cannot connect to a node for a specified time period, the node is de-licensed and/or deleted by an Offboarding task (described next). If the Check Node Connection task re-connects before this time period expires, the timer is reset to zero.
• The Offboarding task works with a Check Node Connection task to manage ephemeral assets. If the Check Node Connection task is unable to connect with an Axon Agent-based node for a specified time period, the Offboarding task de-licenses and/or deletes the node.

If the Tripwire Console has not had a working connection to an Axon agent for a specified period of time, you can de-license the node, which will return the license to the available license pool and stop the tasks from checking on that node. The data for an de-licensed node will still show up in reports, with the data still in the TE database, taking up space. You can also set the Offboarding task to remove a node after a specified period of time, and that will clean up all of the data for that node from the back-end database.

For example, you can setup the Offboard task to de-license a node that hasn’t been connected for a day and then delete that node if it has not been connected for a week. Assuming that you don’t need to send your TE Data into another system for longer term storage and historical reporting, you could set the retention period to delete after 90 days.

These automated tasks ease the management of the nodes in your environment, reducing both the administrative burden and possible mistakes. In my experience, during TE Health Checks, I’ve found unchecked nodes that were there for weeks but were never added to a group that was part of a Task – that could be an audit problem later.

Setting up the Asset Management portion of your Tripwire Console to automate the management of your assets is not a difficult task. It can make your life easier, and it can avoid costly mistakes in monitoring. Ask your Tripwire sales engineer for advice and help if you’re not sure how to get started turning your TE Console’s asset management capability into a fully automated system.

To learn more about Tripwire’s asset management capabilities and the rest of the product portfolio, click here: https://www.tripwire.com/products.