We have a requirement like this.
Need mail notification when a set of users log in and log out but not supposed to have access to the list of users. So is there any way we can achieve this by using some service account and fetching the details from some repository. Or any other thoughts?
Please suggest if it is possible in ESM 5.0
Amit Kumar Gupta
That is indeed why you need to duplicate the value of 'sourceUserName' into a different field (deviceCustrumStringX | flexStringX)
If I'm correct that is to be done by a parser override ( https://protect724.arcsight.com/message/5899#5899 ) since a map.x.properties file cannot be used. ( https://protect724.arcsight.com/message/16490#16490 & https://protect724.arcsight.com/message/19844#19844 ).
Please someone correct me if I'm wrong.
This duplicate needs to be set at the connector so when this events enters ESM it can perform the correlation.
el mejor ajo
I have a question, If you map the username to other custom fields then what's the pupose of obfuscating?
Can anyone help me understand this.
I will be happy to help you (if I can)....:-)
If we map the username to other custom fields then we will be able to use the logs for all the existing rules and reports just by changing the sourceUserNAme to some custom field.
Now coming to your query that what is the use of obfuscating?
We as SOC users are not supposed to have the access or visibility to the set of users for whom the logon/logoff monitoring is required. So team responsible to create and send this list of users can provide us the MD5 hash value instead of user names in the plain text. And we can compare this list against the obfuscated field "sourceUserName". In this way, we can monitor the access and also will not have idea about what are the actual users being monitored.
Hope I made some sense.
- Amit Gupta
Vivek was correct, the analyst or Admin console user can simply double click the correlated event that does the md5 matching and then look at the base event's attackerUserName if you have it copied and hashed in a seperate field such as deviceCustomString1
The external mapper is one way to achieve this...
Also for consideration, if this data is very high severity, be cautioned that md5 and even sha1 are trivial to crack just by googling online md5 cracker. Most level 2 analysts should know about md5 cracking techniques.
Another option would be to setup the user access controls to give full admin access with the exception of one group of active lists, rules and reports. This will not keep the correlated events from them but will help lock down viewing the active list and reports of who matched the MD5 hashes.
Again you will probably need to leverage an external mapper or script to retain the clear text userNames in the base event AND process your matching use case. Your use case is very do-able but you have some interesting restrictions.
Haha, off course it is correct. You can't hide everything from these events/notifications.
The only real way of doing this is reporting ALL users and have the team, which needs to keep secrets, have some solution to send out the notification... (or send notification for every login/logout and have the end user define their whitelist.) A kind of the other way around. The penalty you pay for such restrictions.
el mejor ajo
Well, so you will have a table containing MD5 of monitored usernames.
At the same time, you will have the login events with the username and corresponding MD5 hashes.
Than it is easy to store the real usernames of monitored users with corresponding MD5 to an ActiveList -> recreating the list, you are not allowed to know.
I agree it sounds like you could feasibly create a rainbow table using this MD5 approach.
OK, how about this:
Rather than working with MD5s and lookup lists, why not simply keep the unique, obfuscated ID in the external mapper database.
ie. you have a table in the database which is something like:
Your mapper looks up the username, and if it finds it, the mapper:
- Overwrites/wipes/reset the Source Username field (eg. Sets it to blank, or resets it to "Monitored User", or writes in the Unique ID
- Puts the Unique ID in the event; perhaps in the Source Username, or maybe a Device Custom String
- If necessary, sets a flag field to '1' to show this was a monitored user login
- What if the username is not in the database at all (does it just not set the fields?)
- Can it overwrite the source username (I think it can)?
- Will you need to have a specific flag set to trigger your rule from, or can you use something else (eg. "If username is 4 digits, then it must have been a protected user's logon")
So you'll need to play, and see what works.
- Generate the alert/report to the SOC team, which shows the fact that user "8112" logged in
- The authorised analyst/admin can then reverse lookup the original username against that ID (ie. "asmith"). It could even be a console right-click tool for them.
- The SOC admins have no access to the database, OR the connector install where the credentials might be somehow accessible/reusable. Hence they have no way of looking up the original user ID.
[ps. mention my name in your reply for my outlook rules, if you want me to see it]
You wouldn't even need to do full admin rights to restrict access to the list, just a tiered permission level approach should work. If you needed to hide the data in the events themselves that will become the difficult part.
Honestly the better approach will be to have a while list of approved users and have the notifications or reports for all users not in the white list. Either way you try to do this, you're going to have a very difficult time detecting unauthorized activity that you aren't authorized to detect.
Even if you do manage to hash, obfuscate, or encrypt the user ID's so not a single ArcSight user can see them, how valuable does this event become when you can no longer determine what was authorized or who was violating policy?
I look at this in the client or customer point of view and the only valuable information this event could now provide is that there was an un-authorized login at a specific time. If these user names are that sensitive of information then the same could also apply to an IP address, since you could find out what machine it was, who owned it, or where this person is located.
Still this is a very interesting use case.
Thank you everybody for your views on this. It really became an interesting use-case with the kind of responses received. However considering the complexcity involved to implement this, we dropped it.
Thanks for your detailed description.