Critical System Protection

I need some assistance in fine tuning the detection policies as the SCSP events are piling up the database and the size is increasing drastically. I have identified that some of the policies like File Tampering, Windows success logon are set to default so i need to know if we can fine tune to reduce the events.

 

Thanks,

Jayakumar 

Hey J,

Don't be afraid to experiment with detection policies.  Unless you have spececfic actions tied to certain events, you probably won't hurt things too much ;)

Maybe we can setup an online session and tackle things together.

Send me an email and we'll set up something.  I'd love to help.

You should interrogate your logs to see what is the majority of things being created, and if they are worthwhile to you or not.  If they aren't, then get rid and change the policy appropriately.

You can also use a Detection Config to tell the agents what events to send to the mangement server.  If anything in the config matches, then it will be sent.  

The config only controls what is sent, not what is logged locally.  However, if you have your Common Config set to delete log files after processing, then the logs will be purged after they roll over.

Alternatively, you can edit the policy like the above comments mention.  Look for rule names, that will lead you to the correct part of the policy, and you can try and tune out the events there.

 

Thanks All for prompt responses.

 

I need to know if there are any recommended policy for detection of Critical File Tampering & Windows success Logon, as of now it is detecting all System critical files *.exe, *.dll etc and Authentication logs are huge in count so these events are filling up the DB size. So i need the recommended files for windows.

 

Thanks,

Jayakumar

Also the Windows logon for NT Authority\Anonymous, NT Authority\System logs are being logged and these logs are also heavily filling the DB size, is there a way to fine tune to only monitor the User logon/log off i.e., Interactive logon only?

If you are running the Baseline Detection Policy, you can find lot of good information in this document

Detection Policy Guide

 

Good luck!

You mentioned "policies" in your original question.  Like Will mentioned, the Baseline Detection Policy is what you should be using -- it is an amalgamation of the other detection policies.

Tuning is part of the SCSP process, and in the beginning you will need to tune out the stuff that you don't want to see.  

The most important thing is to make sure you know what you are required to log...then you can tune down the event volume appropriately.  For PCI, SCSP is typically deployed to cover the FIM monitoring requirements...so you can disable all the succesful/failed login sections of the baseline policy.  Occasionally, users will also leverage SCSP to meet the PCI requirements related to log integrity...then you have to selectively tune the succesful/failed login sections(and document!) to ensure you remain in compliance.

The 'select' and 'ignore' strings in the baseline policies are stellar tools for helping you fine tune the policies.  SCSP can generate a mountain of data...as you've found.  The key to a succesful deployment is tuning your policies in a manner where you meet business requirements AND minimize event volume.

 

Conventus has built some tools that make this effort significantly easier...please don't hesitate to reach out if you need assistance.

I have a policy "File Tampering" which detects the file modification and deletion of files under the system directory. Is there a way to exclude the detections made by a specific user?

 

Regards,

Jayakumar

Can you clear up a few things first.

1. I assume you created a new detection policy and added a custom rule based on the FIle Watch catagory.
2. I think you mean you want the policy to ignore the actions of certain users.

 

Thanks

 

Yes Will, your are right.

I need to know if i can exclude a user activity in File Tampering detection policy.

 

Thanks & Regards,

Jayakumar

 

Hi Jayakumar!

There no way (that I know of) to narrow the focus of a detection rule to a specific person or group.  Likewise, there's no mechanism to exclude the actions of certain users or groups.

 

Send me a private message and we can take this offline.  If you're willing to tell me exactly what you're trying to achieve, maybe we can find a solution.

 

Best Regards

Use the configs to tell the agent what to send to the manager.  Both the Detection and Prevention configs have a default "Do not send", so if a config is empty, nothing will be sent to the manager.  

The IPS side of the house will tell you "Who" while the IDS side cannot tell you "Who" without you enabling the Windows Object Auditing (which taxes system resources).

I think the best bet for you would be to use a custom Prevention policy that watches the directory in question, and is set to "Allow but Log".  This will generate IPS events every time someone touches the file.

From there you can go into the Prevention Config and set a log rule:  "User Name" "Not Equals" "<username(s)>" and set to "Transmit in Real time".  The rules are processed in order, so it may be necessary to move this rule to the top of the list.

Apply the Prevention Config to the assets you want this to apply to.

This will result in the agent still logging the event, but it will not send the event to the manager when the user or users you listed touch the file.

To ignore a particular user in FIM, you can insert the following into the 'Ignore Strings' section of the rule:

*User: SampleDomain\SampleUser1*

Keep in mind this will only work on agents that have realtime FIM functionality.

 

Know that this is a bit old, but wanted to throw in my 2 cents. You can replicate many of the FIM capabilities with a prevention policy. Just start off with the targeted prevention policy, create a file access rule for "no access" or "Read Only" (depending on whether you want to log accesses or modifications. With this strategy, you can limit the logged activity based on user id and/or group. The key thing to remember here is to make sure you have prevention disabled! One key thing to remember is that you will not be able to report on file differences (what changed within the file) or the file hashes (if this is important to your auditory requirements). Feel free to reach out to me via e-mail or on this forum if you want to discuss further. Chris Tyrrell Compliance Practice Lead Conventus ctyrrell@conventus-sei.com