1 2 Previous Next 10 Replies Latest reply on Aug 21, 2014 10:55 AM by docdriza

    Managing the great irony of SIEM - domain creds - and how the product might improve on this


      We all ostensibly implement a SIEM to increase our security posture. But the great irony is that we've now got one place that's holding a boatload of administrative credentials... none too securely.   In fact, the first time I ever had to ask our Windows group for an unrestricted domain credential... was in implementing SIEM.   Even for credentialed vulnerability scanning, I was able to use one that was restricted just to use from only certain IP addresses, but for whatever reason, to pull logs from Windows hosts with ESM Receiver,  an unrestricted domain admin appears to be required (this appears to be an issue on the MIcrosoft side of the fence).


      So -- open question -- what are your favorite strategies of how do you go about mitigating that risk? What would you like to see in ESM to help you mitigate that risk?    With root access to the backend of a receiver,  stored creds are stored in a reversible format as you might expect, and absent any documentation provided by McAfee on deploying certain common connector types and what the minimum privilege profile is for them...  in the interest of getting things working, it seems that SIEM consultants are too used to "always have just used a domain admin account for this."


      One approach I've attempted is to use domain admin creds that are restricted to use from only certain IP addresses.   Microsoft words this strangely in the properties of the account, but you can restrict domain creds to be used only from certain ip's or hosts, and they needn't just be windows hosts.   This works for certain types of data source connectors like CIFS shares, but domain accounts restricted to certain IP's do not work for Windows event log connections, or for the API into VMWare VSphere in my experience.


      A mitigating control for having to use an unrestricted domain admin account is to set alerts on logins from source IP's for that account that aren't from the nitro receiver, indicating a use of the domain account nitro uses from ip's that aren't nitro receiver.


      Another control is to change domain cred passwords routinely--some business have audit drivers that mandate quarterly change of domain creds.     But... it is a TOTAL PAIN IN THE BUTT to update these in all the data sources in ESM.    It take a long time to update and test creds and push them out in this  user interface, and there's no profile feature for just changing a cred in one place.  The profiles that are available are a bit too specific to be useful to change a domain cred everywhere it is used.   I do have a PER open on this, and if anyone else agrees that this needs to be a feature in the next release, please please please add a PER of your own asking for domain cred profiles.   I talked with the PM, and didn't get a feel that this was a well known widely voiced concern.     Credential-only profiles would be a huge help, or doing something to make changing properties on a data source a lot faster than it is today.


      Sharing any other comments or strategies for getting the benefits of SIEM in a least privilege way would be great!  

        1 2 Previous Next