Populating Users From Groups

[JoeGumke]

I have a use case where I need to make daily reports of user activity derived from users that are maintained within an active directory group. Does anyone know if its possible to automatically update lists in the reporting engine from a powershell script ? I would like to update a reporting engine list from users within an AD group, and generates reports from the updated list.

[JohnKisner]

Joe,

If you create your list you will find it in a zip file under /home/rsasoc/rsa/soc/reporting-engine/liststore. However these compressed lists do not have any name that is representative of the actual name placed on the list within the Reporting Engine. The only way you can tell if you have the correct list is by looking at the content of the zipped list file. This being the case I believe you could add and remove items from the list by manipulating the zip. The key would be not to change the actual zip file name as this is the internal name that the reporting engine uses.

I hope this helps.

[DavidGassman3]

Sounds like a good RFE if not already on the docket.  Many other uses cases can be implemented by exposing the RE List from an automated standpoint (similar to how Recurring Feeds work today). 

[JohnKisner]

I agree. A proper REST like interface for the UI server that exposes the functionality of the UI componenets, not unlike the one used by the primary componets (broker, concentrator, decoder, etc), I think would be very helpful in automating pieces for power users, Professional Services and Support. I believe this has been brought up before with our Engineering team but unsure of what their thoughts are about it.

[DavidGassman3]

Sample use case:

Analyst obtains a fresh set of malicious C2 domains and needs to "put them into NetWitness". They should have the ability to paste in the domains in a list somewhere and have options to:

   1) add to a new/existing Recurring Feed (so that detection can happen going forward)

   2) add to a RE List that is preconfigured to query the existing db to look back & see if there are pre-existing sessions matching these domains.

Anyone agree?

[JohnKisner]

The first scenario you could do without a REST API as long as you had the recurring feeds CSV file somewhere that an analyst could manipulate the csv file. Or, this would need to be created by the customer, a web interface that generates and manipulates a recurring feed repository. Though it would be nice if we had our own area that could do this since the NetWitness UI server has its own webserver already Granted you could use a none recurring feed and just download the csv file from the Netwitness UI, make the changes you need and then reupload the file. The UI server keeps it unencrypted within itself somewhere. 

The second scenario I you could do as well even without the API. If you had a report that contained rules that referenced lists within the Reporting Engine. You could open the lists in RE and then just copy and past in what you wanted to the list. just by going to the list and click the Insert Values button. Once that was run you could run an adhoc report over the old data to see if it shows up.

However either scenario could be enhanced with a REST API for the UI

[DavidGassman3]

I'd find it useful to see both options exist in a single pane.  It's clumsy to have to go to Live Feeds for one part and then go dig and find the RE List to put the same data into, and scripting this option is not customer friendly.   I think the theme here is as you stated 'it would be nice if we had our own area that could do this' ---- meaning an RFE with priority assignment ... not just some idea that gets thrown into the mix and never gets implemented. Agreed with the idea of a REST API for the UI (leveraging the existing web server)--- lots of use cases could be implemented without all of the hacking around the platform.  

[JoeGumke]

Thanks john. So What does the lookup from the raw zip reporting list file ( /home/rsasoc/rsa/soc/reporting-engine/liststore), to the GUI reporting list name? For me to efficiently script this out, i'll need the ability to realtime find out what each zip file is mapped to, in terms of a reporting list name (user friendly name). There has to be something that gives us the user friendly reporting list name in the GUI.

[JohnKisner]

Joseph,

Sorry for taking so long to reply. I don't know of a way to find out what the mapping of the zip file names to the real list names. I suspect it is buried within one of the internal reporting engine databases or it may be in the H2 database itself. It would probably require talking to one of the reporting engine developers to find out where that was stored and if it were even readily accessible.

To get around this you could put something in the first entry of the list that is meaningless to the list itself but that you could use to help identify the list. It would need to be in the same format as the rest of the list but it would be an entry that never hits. Then you could use your script to look into all the zip files and find the one you want to update. Once you know the name of the zip file it shouldn't change unless you recreate it.