Active Lists

When creating an active list, you should probably include the customer resource column. This makes your AL friendly for MSSPs, or for when you need to separate out data among your business units. Not every AL will need to segregate customer data, especially for a product package or an L1 solution package.

If you are going to do anything other than check an entry to see if it is in an AL, you will need to access the data through the GetActiveListValue function, which means you need to define key fields. Key fields are also required when you want multi-mapped entries, case insensitive columns, etc. Choose your key fields wisely.

Key field selection should satisfy the following conditions:
1. Use the minimum number of key fields possible, but don’t be afraid to have multiple key fields.
2. The key field(s) selected should uniquely identify an entry.
3. The event fields from which the data is taken should never be null. (Note: this is ideal, but not necessarily always possible.)
4. When using IP address fields as a key field, always add the zone field as a key field, as well.
5. Don’t forget to use the customer field as a key field.

example for tracking versions
• Customer (key)
• SystemZone (key)
• SystemAddress (key)
• SystemHostName (key)
• SystemVersion

If you’ve done your network modeling well, then you’ll want to use the asset information, instead (column set 4):
• Customer (key)
• AssetID (key)
• AssetZone
• AssetAddress
• AssetHostName
• AssetURI
• AssetVersion

Please note that most of the asset information listed is comprised of derived fields. You can get away with something more along these lines:
  • Customer (key)
  • Asset (key)
  • additional information (data you would track, or a dummy field, if necessary)
If you find the need to check a list to see whether an entry is in it, but need to use an additional AL feature, such as case insensitive columns, use a dummy string field to be the non-key data field, since you cannot have only key fields defined in a list. Your rule to add entries to the list can put whatever string is convenient, a good example would be device custom string1.

Column Ordering

We highly recommend using a consistent column ordering for active lists. This is because many use case implementations depend on monitoring active list audit events, and the entry information in these audit events is often contained within Device Custom String4. If you are tracking information regarding a host or a user, we recommend following these key field ordering examples:
Use Column1 Column2 Column3 Column4 Column5 Column6 Column7
Users Customer NT Domain User Name        
Hosts Customer Zone IP Address Host Name Asset    
Users by Hosts Customer Zone IP Address Host Name Asset NT Domain User Name
Services by Hosts Customer Zone IP Address Host Name Asset Service Name  
Tracking local Linux user accounts might be instantiated using these columns:
  • Customer (key)
  • Zone (key)
  • IP Address (key)
  • Host Name (key)
  • Asset (key)
  • Domain (key) [for Windows, this would be the NT Domain, may not be relevant for Linux hosts]
  • User Name (key)
  • User ID
Using consistent ordering will allow the use of global variables for dealing with list data in audit events for multiple lists easier to understand and maintain.

-- PrenticeHayes - 14 Apr 2017
Topic revision: r1 - 14 Apr 2017, PrenticeHayes


Activate Wiki

This site is powered by FoswikiCopyright &© by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback