Hello BigFixers,
When creating a new fixlet or task there are properties for Category, Download Size, Source, Source ID, Source Release Date, Source Severity, CVE ID, and SANS ID.
Is there a way to add new custom properties to allow additional classifications and ties to external data sources? We are interested in creating fields for “Change Request Number” and “Incident Number” so that specific actions can be tied back to specific tickets in our ITMS.
Or, has anyone already accomplished this via a different mechanism?
Thank you,
Tom
Those properties are for the fixlet or task themselves, it does not provide any data to the endpoints they are executed on.
We usually add some of that data to the name if we need it. But what we really needed is to know which systems we executed it on.
So we setup a custom property (client setting) that can be added when we take custom actions related to tickets or changes. First we setup a custom property (Tools, Manage Properties).
Then we add the action below to any fixlets we create and want to add ticket numbers. It will prompt you when you go to deploy it.
action parameter query "SetTicket" with description "Please enter the Ticket Number, multiple should be delimeted with a :" With default ""
setting "MYC - Tickets"="{parameter "SetTicket" of action}" on "{parameter "action issue date" of action}" for client
Now you can create a custom report and filter on ticket numbers to determine which systems you executed the fixlet on.
We do separate reports, we do not use Web Reports. Our report team pulls this data every 4 hours and stores it in a sql table so we can take more actions tomorrow and still have the previous ticket numbers available to us in our report.
1 Like
Thanks D.Dean! That is an interesting idea.
Commonly we would add MIME Fields for this kind of tracking, valid on either Fixlets or Actions.
They aren’t visible in the Console, but can be queried via REST API, custom Web Reports/Dashboards, etc.
Thank you, Jason! We will investigate that option too.
@webbytr, there isn’t but apart from the alternatives that were given to you below by others, nothing stops you from using the default ones. For example, we use “SANS ID” for exactly that purpose (put identifiers for ticket #s who requested the specific fixlet; we write names of owners/requestors in “Source ID”, we write creator in “Source”, and obviously all those are retrievable data via both WR or custom session relevance. It’s not idea but as long as you enforce it as a standard and all your operators complies with whatever structure you decide on it should work just fine.
There is an idea for actual custom fields (https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-128) but it doesn’t seem there are a lot of votes in it, so doubtful it will be committed to soon.
1 Like
Hi Ageorgiev,
Thank you for idea. We did consider using the existing fields but would prefer to avoid mixing types of data stored in a property(KB#s versus CR#s, etc.
I did not find that existing Idea post when I searched for this topic, so I did go and vote for it. TY!
Tom
1 Like
