Setting up SIEM
I'm using ManageEngine EventLog Analyzer for SIEM. It seems appropriate enough for what I'm trying to accomplish. And, right now, it isn't the main focus of this question.
What I need to do is to collect pertinent information (logs/audits/etc. I suppose) from a number of workstations on a peer-to-peer network.
So, some setup is necessary on each workstation. While it may be easier or more efficient to do with a Server, that's not in the picture and isn't a present concern.
I'm told that I need to set up Audit Policies with gpedit:
Fine. What I have no feel for is what happens when I set these things to Success/Fail. I'm rather sure that some are of little interest. I'm also concerned that some will generate huge amounts of needless data. I also imagine that I'm familiar with some of them via Event Viewer, etc.
Any recommendations? Should I simply check Success/Fail on all of them? Should I avoid some of them altogether? What do you do?
I know this is rather open-ended. My objective is to have SIEM and not so much "computer management" if that helps.
So opinions are fine .....
Also, I'm wanting to log Windows logon failures as a security indicator. So far I've not been able to get that information.
What might be the formula? Or, is this Audit Policy setting going to help with that?
FYI: at this point I can get WMI to connect from the monitoring computer to all of the workstations. So that part is done. And, I'm getting *data*! But I'm not sure why I get what I get and I'm not sure how to get what I want. That's where things stand.
Probably theres a good guide on how to do this but I've not found it yet.
What I need to do is to collect pertinent information (logs/audits/etc. I suppose) from a number of workstations on a peer-to-peer network.
So, some setup is necessary on each workstation. While it may be easier or more efficient to do with a Server, that's not in the picture and isn't a present concern.
I'm told that I need to set up Audit Policies with gpedit:
Fine. What I have no feel for is what happens when I set these things to Success/Fail. I'm rather sure that some are of little interest. I'm also concerned that some will generate huge amounts of needless data. I also imagine that I'm familiar with some of them via Event Viewer, etc.Any recommendations? Should I simply check Success/Fail on all of them? Should I avoid some of them altogether? What do you do?
I know this is rather open-ended. My objective is to have SIEM and not so much "computer management" if that helps.
So opinions are fine .....
Also, I'm wanting to log Windows logon failures as a security indicator. So far I've not been able to get that information.
What might be the formula? Or, is this Audit Policy setting going to help with that?
FYI: at this point I can get WMI to connect from the monitoring computer to all of the workstations. So that part is done. And, I'm getting *data*! But I'm not sure why I get what I get and I'm not sure how to get what I want. That's where things stand.
Probably theres a good guide on how to do this but I've not found it yet.
Sorry I neglected to answer this part:
> Or, is this Audit Policy setting going to help with that?
Yes, this audit policy is exactly what you need to get that kind of information. Normally you'd be targeting domain controllers as a central authentication service. For a peer to peer network that's going to be a bit moot.
Do you have any centralised services at all? Or any centralised authentication?
Chris
> Or, is this Audit Policy setting going to help with that?
Yes, this audit policy is exactly what you need to get that kind of information. Normally you'd be targeting domain controllers as a central authentication service. For a peer to peer network that's going to be a bit moot.
Do you have any centralised services at all? Or any centralised authentication?
Chris
ASKER
This is on a peer-to-peer network with no centralized services other than the SIEM monitor which will use WMI access for Windows workstations.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks!
> avoid some of them altogether? What do you do?
It's a start, and some of them will indeed generate a fair number of logs.
However, for several of these that policy is only the first step. It enables auditing, but you've not given it anything to audit. What is audited is dictated by the System Access Control List (SACL) set on individual objects (files, directories, objects in Active Directory, registery keys, etc). The SACL does not grant access in any way, the Discretionary ACL (DACL) does that job.
This article takes you forward from the set-up of the policies and provides some examples of the kind of data you will be capturing based on each setting.
https://technet.microsoft.com/en-us/library/dd277403.aspx
For those governed by SACLs you will need to figure out what you want to see. Any change, delete only, use of rights which were permitted, attempts to do something which was denied, the list goes on but must start by identifying what is deemed to be of particular interest.
I would be surprised if this didn't take quite a lot of tuning to get the right volume of useful information, but I'm sure you expected that much.
Chris