I have a client that would like to be notified if a user attempts to access files or folders to which they shouldn't have access. Now, this should not be an issue at all if file and folder ACLs are correct but that's another story. So, assuming a user doesn't have read access but can view files and folders can SDI provide alerts for this attempted access? Can the Widows File Server agent even track unsuccessful access attempts? The client is after real time alerting, if possible.
I've had a look at reports but there doesn't seem to be anything useful so I thought policies may be the way to go. Has anyone got whitelist or blacklist policies to work? The documentation goes on about custom AD attributes and such but gives no information about how one would actually use them. I've asked Symantec for examples but I received nothing useful.
Mark there is no alerting in the product on failure of audit events since there would be no activity on a failed READ as example. The application tracks successful access events against monitored shares for users identified in a directory service such as Active Directory, local user's list or LDAP.
As example, a share is left as an 'Open Share' with everyone full control but the Access Control List (ACL) has the files locked down to particular groups that do not include everyone. Then user Fonzie could see the files but when they attempt to read or open them it would fail and generate an Audit failure in the event logs of windows, if enabled. Data Insight (DI) would not capture that attempt as there was no successful access event, there was actually no access event generated.
In reporting you could determine the open shares with the permissions type report. You can set your open share policy for display in the DI Workspace under Settings >> (Global Settings) Advanced Analytics >> Open Share Policy (tab). In version 5.x of DI you will see a column under the shares showing if the share is open (1) or not (0).
Assuming you wished to monitor an object for access (Data Activity) it would alert on all access events and not just 'unauthorized' users. If you wished to Alerts on individuals (User Activity) you would have to add those individuals to an alert and based on their access the alert would be generated.
Real-time Alerting not really real time as there are jobs used to run the Policies, trigger alerts and email the notification list:
Note: default settings -
C:\Program Files\Symantec\DataInsight\bin>configcli list_jobs webserver |findstr Policy
| PolicyJob|10/20/15 12:00 AM|10/21/15 12:00 AM| 12am every day|
| PolicyJob_alerts| 10/20/15 2:51 PM| 10/20/15 2:51 PM| Every 10 seconds|
C:\Program Files\Symantec\DataInsight\bin>configcli list_jobs |findstr EmailAlert
| EmailAlertsJob| 10/20/15 2:38 PM| 10/20/15 2:53 PM| Every 15 minutes|
Whitelist alerts still would not accomplish what you hope to in order to catch users who attempt to read files listed in an open share even though they know not to. The Whitelist and conversely Blacklist alerting works against a specified list of users or groups or alternatively their custom attributes and alerts when someone outside of the defined list (inside for blacklisted objects) completes a specified event in a condition you have defined.
The list is built during the PolicyJob run daily and is active for all of the alerts generated until the next job runs, which by default is midnight daily. (An admin can change the frequency of that configuration using the command line in the manner - C:\Program Files\Symantec\DataInsight\bin\configdb –O –J job.PolicyJob.cron –j “0 0 0/5 * * ? *” Which is listed in Crontab format such as this example for every 5 hours). The best practice suggestion is to run it once daily.
It will consider past 24 hrs of activity from the time it started to generate alerts in the case of a whitelist policy. Since the job is run every 15 minutes, it will continue to generate alerts every 15 minutes till the last access goes beyond 24 hrs.
You did not mention the DI version you are using. There are improvements in the newer version of the product and additions are considered for future revisions via our Product Action Request (PAR) process of accepting enhancement requests through the Product Management group accessible through your account representative. Alternatively you can use the idea forum on this website.
I hope that gives you more information on the alerts aspect of the DI application?
If you would like a similar discussion on the addition of Custom Attributes. I can look to creation of an article demonstrating the ability or answer another thread under that subject.