Deep Dive into Writing Back to Axonius (Part 1 – Tags vs. Custom Data)

Introduction

Did you know that you can write back to Axonius with a few different tools? The purpose of this article series is to address the following use cases surrounding writing back into Axonius:

• Part #1:
  • Breaking down the difference between tags and custom data
  • How to utilize custom data fields (single / mass rule enrichment on a single field in custom or aggregated data)
• Part #2:
  • How to utilize data enrichment (mass rule enrichment on multiple fields in the aggregated fields)
• Part # 3:
  • How to utilize custom enrichment (mass enrichment on multiple fields in an adapter)

Tags vs Custom Data

Often, people think of tags and custom data as interchangeable elements. In some cases that can be true, but there are distinct differences.

You do have the ability to create tags and NOT export the data but that limits you as well. What if there was a better option? (There is.)

Tags were originally popularized for tools such as AWS, Azure, and GCP, i.e. multifunctional cloud services. However, they are not singularly designed to be databases. As a result they could house data, they could be a load balancer, they could be a measurer of all things compliance… lots of different functions that all need a common denominator. That single common denominator for the tool is “TAGS.”

Axonius has an advantage over that architecture: words. The words that exist in Axonius are extremely powerful, and as a result you don’t necessarily need the tags for the SAME functions as you would in AWS. I say SAME in all caps because there still is a function for the tags column, it is just a different function than what you may think.

In Axonius, we prefer that you use tags to give the world the “Here is your sign” type of things. Maybe there is something you don’t want ANYONE to miss. Maybe there is something that is so important that it transcends putting in its own bucket. Something like:

• A label that says: “DO NOT TOUCH!!!!”
• A time bucket that gives you a specific date range for an item (ie: 30-60 days)
• An exclusion identifier (ie: VA Blacklist item)
• An action item for a team member (ie: “John follow up”)
• An action item for a missing process (ie: AWS needs agent”)
• A non-standard membership that needs to be noted (AD Device)

No matter who the audience is, these tags can and should be seen by all.

We tend to run into problems, however, when there are so many commands that it is hard to keep track of things. The tags button is only so large, and when a customer has 15 tags it can be easy to miss something. As a result, we want to limit the number of tags and introduce custom data fields.

How to utilize custom data fields

Custom data fields are pretty fantastic if you are looking at adding something specific to a dataset. Using enforcement center, you can either manually or automatically add specific labels to any aggregated field and you can create any custom field you want.

In the following use case, you have a device that has quite a bit of aggregated data associated with it. (All data is from a test lab. For the sake of anonymity, I have obfuscated identifying elements).An important thing to note about Axonius is that if a field does not have any data in it (null value,) it will not report in either the aggregated field or the adapter specific field. When we do an aggregated pull down, here is a potential list of fields you can look up.

While this is a partial list, the big issue that we run into that some of the items have data in them and others don’t.

Say that you wanted to add custom fields that are specific to nomenclature that fits your organization. Let’s take an OS Name:

• Your Org would like to see all Red Hat Linux in one group. If you do a type and distribution search, you may find that you get the following items:

What’s tough about this is that this information comes from the tool and not from Axonius. We know this is an issue, and we want to make sure we get the most authentic data out the gate.

You can fix this two different ways. First, you can create a query that looks for “RHEL” OR “Red Hat” in the query.

Manual Process of adding custom fields

-----------------------------------------------------------------------------------------------------------------------

Manual Step #1 – Click the box in the top left header corner (make sure to click on the “Select all if you have more results than you have results per page).

Manual Step #2 – go to the actions tab and click on the “Add Custom Fields”. The screen below will show up.

From here, you can either click on a field within the field drop down OR you can Create your own.

• If you click on an item that looks like this:the Axonius icon will indicate that this field is in the aggregated fields.

• If you click on an item that looks like this:the person icon will indicate the data resides in the custom data fields adapter.

If there is not a category that you are looking for, you can create it

When creating fields, you are presented with some different options.

• Boolean – Booleans are used to represent truth values with two constant objects True and False.
• Float – Float represents real numbers, a data type that is used to define floating decimal points.
• Integer – Just as in mathematics (where it is referred to as a signed integer) an integer is a whole number that could hold a zero, positive or negative value.
• String - String represents a sequence of characters (text) inside double or single quotes.

Anything that has “List” prior to it references that there can be more than 1 entry. Keep in mind that to this point, we do not support date values in this process yet so they will need to come in as a string.

In this case with Red Hat, we will be putting custom data to the field as it is aggregated and is an easy one to connect to and get data from. Keep in mind that this field is generally not auto-propagated so this is a great aggregated field to use for this use case.

Once these custom fields have been created, you will see them added to the field. See below for the outcome.

Automating the process

-----------------------------------------------------------------------------------------------------------------------

This type of process isn’t really something you want to do daily. Luckily, Axonius has the means to automate this process!

Now we are going to go back to the query we had. Save it as “Red Hat Linux” and head over to enforcement center.

Once you get there, click on add enforcement

 Once you get into the main action, you will want to add a title and click on the “Axonius Utilities” > “Add Custom Data” button

After clicking on the “Add Custom Data”, you can copy the Enforcement Set Name to the Action Name or rename the action center name to what you want.

Fill out the field name (this is very important that this is EXACTLY what you see in the query field if you are adding to a current field). Then under the field value, type in “Red Hat”.

Once you hit save, it will take you to the trigger page. Under the module drop down, click on “device” and then look up your query name “Red Hat Linux”.

Toggle the “Enable Automation” button and hit save. At this point, if you want to run this automation more or less than every discovery cycle, you are welcome to.

Once you hit save, you can click the “run” button to get it to run immediately. Otherwise, it will run at the nightly discovery.

Keep in mind that currently this can be a bunch if you are in a spot where you want EVERY OS that you may have. There are generally 20-30 of these rules that you may want to do if dealing with OS’. Instead of redoing the action 20-30 times, you can click here:

An option to duplicate the enforcement will pop up. You can duplicate it and change the query, output and names and it will cut down on a bunch of extra work!