cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Former Member
Not applicable
Report Inappropriate Content
Message 1 of 11

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!  

10 Replies
Former Member
Not applicable
Report Inappropriate Content
Message 2 of 11

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

One thing I am doing is using the SIEM Collector Agent.  It runs on the host system without credentials.

Former Member
Not applicable
Report Inappropriate Content
Message 3 of 11

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

Thanks ddd671-- Have you run into any stability gripes about it?    As you might imagine, we're hesitant to prod another group to put any piece McAfee software on an otherwise well running server without an excellent reason.    Curious if folks are generally happy with the collector agent.  It does indeed eliminate the credential need, which is a compelling reason.  

Former Member
Not applicable
Report Inappropriate Content
Message 4 of 11

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

I've had issues with the Linux version, and decided it just wasn't worth the time.  Plain old Syslog still works well for those.  On the Windows side of things I haven't had many issues at all.  With version 10 of the SIEM collector agent it can be managed from ePO.  I deploy both the SIEM collector agent and its policy (ePO speak for configuration) from ePO with very little trouble.  I've been running the agent for over a year now, and I am currently working to get it deployed widely in my environment.  If all goes well, the agent will be part of the baseline configuration in our environment.  I plan on having a policy that says "do not send anything" for most systems, with other policies by server type (domain controller, IIS server, terminal server, etc.).

One gotcha to look out for is this:  the hostname field is case sensitive so you have to be very careful to get it exactly right.

Former Member
Not applicable
Report Inappropriate Content
Message 5 of 11

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

Hi ddd671,

I have the collector installed through ePO on some of the test machines and trying to integrate it with ESM.

I tried to Auto Learn from the receiver properties for MEF events but it could not find anything.

How did you integrate collectors to your ESM?

I am running ESM v9.4 combo.

Former Member
Not applicable
Report Inappropriate Content
Message 6 of 11

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

I'm not sure what your problem is, but had to adjust the DHCP field in the receiver settings to include my devices with SIEM collector agents running.  Else the receiver wasn't listening for auto-learned sources.   Also, make sure that you have hostname field exactly the same on ePO policy and in the autolearn settings.  You may have firewall issues as well in your network.

Good Luck

Former Member
Not applicable
Report Inappropriate Content
Message 7 of 11

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

That is spot on DDD671.

DHCP field in receiver settings was the culprit. All fixed now and added sources to ESM. Thank you.

Quick question though: since these sources are on DHCP, what if the client IP changes? How will the ESM data source know of the new IP?

Former Member
Not applicable
Report Inappropriate Content
Message 8 of 11

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

If you are matching by IP and the IP address changes your data source will fail.  If you match by hostname only, then so long as the new IP address is in the defined DHCP field range for the receiver then it should continue to function.  At least this is my understanding, your mileage may vary.

Glad you got it working.

esher72
Level 9
Report Inappropriate Content
Message 9 of 11

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

It doesn't have to be a full domain admin account to pull logs. That is just the easy way to do it. That is why everyone is a local admin and every firewall is any<-->any right?

Seriously, it might be a pain, but I am pretty sure your AD sysadmins can provision a group with the appropriate rights and add whatever service account you use with the SIEM to that group. It is a pretty convoluted process but it is out there in the google ether. There is a certain competing product that has a write-up for something similar that might be a good place to start. I warn you that your Windows sysadmin will probably hate you for asking them to do it though.

Google this:

create user to read domain controller logs wmi

That will give you some of the results that I saw. I have used a few of those write-ups to create accounts for other systems to pull logs prior to this SIEM. To be clear, I have not done it with this one yet though. I almost pulled the trigger when I ran the heartbleed exploit against the ESM and was looking at clear text credentials that had DA rights. That was shutdown really quick and patched ASAP, so I understand the issue you raise. It surely has put getting a different account provisioned back on my plate.

Former Member
Not applicable
Report Inappropriate Content
Message 10 of 11

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

Just in time for and https://kc.mcafee.com/agent/index?page=content&id=KB74126 (How to use a non-Admin account for WMI)

You Deserve an Award
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.

Community Help Hub

    New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.

  • Find Forum FAQs
  • Learn How to Earn Badges
  • Ask for Help
Go to Community Help

Join the Community

    Thousands of customers use the McAfee Community for peer-to-peer and expert product support. Enjoy these benefits with a free membership:

  • Get helpful solutions from McAfee experts.
  • Stay connected to product conversations that matter to you.
  • Participate in product groups led by McAfee employees.
Join the Community
Join the Community