To conclude my thoughts on the training. I thought I would include some screenshots so you can see Sentinel in action for yourself!

To sum up, the way Sentinel works is:

1. Logs are pulled into Sentinel and each line is seperated into events with severity levels ranging from 1 to 5
2. You define filters to look for events of interest. For example a filter might look like:
   filter(((e.DeviceCategory = “IDS”) and (e.Severity >= 4)))
3. Multiple Events can be groups together and marked as incidents. Each incident can be assigned a category and can be assigned to a person for further investigation
4. Utilizing Filters a correlated event can kick of an action (or trigger) such as sending an e-mail, appending a list, appending an ldap attribute or kicking off a javascript file (for further flexibility)
5. ProcessWork Flows can be designed to dictate the logic behind how an event is handled. The chain of command can be worked into the work flow. I.e. when a correlated event takes place ad Analyst can be prompted to check out the incident. Once the analyst attempts to rectify the problem and closes it out. It then can go to an Administrator who can further investigate or close out the incident.

This is the process in a nutshell, if you follow the screens after reading the explanation it might make more sense.

I mentioned the learning curve before. Where does that come in? Definitely when it comes to writing filters. attempting to fully leverage this product will take a concerted effort of Administrators who must keep evaluating the data coming in, to come up with new filters and rules to look for. This will take out of the box thinking. If Sentinel could become smarter over time and share its own suggestions for filters that would be great. When I shared this idea with someone they said that would be Sentinel for Sentinel. Til that point comes where Artificial Intelligence is worked into apps like this Admins will have to play close attention and help make their companies investment worthwhile.

Sentinel is beast and can do a whole lot. The challenge is getting people trained and involving those with the security background that can help them identify what attacks to look for. The filtering language can be very powerful if an Admin can logically think about what sequence of events might take place during an attack. There is a “window” feature where a current attack can be compared to an attack that took place earlier where a set range of time can be specified. For example a usecase can be if someone attempts to login as administrator 5 times within 24 hours you might want to have a filter and event setup to disable that account temporarily and kick off a workflow to reenable that account once its been approved.

For those firms this product may be overkill and they may want to look into Novell’s new identity Audit application which was formerly known as Novell Scout. PS that is a totally different application. Sentinel was aquired in the purchase of a company called esecurity. Scout was an application that Novell developed and is not a light version of Sentinel.

This training was pretty well laid out. The labs were pretty good. The environment was great. There were about 25 integrators (Novell partners) representing companies from all over the US. They had a few give aways (i.e. blu ray player and external drive). They even took us out to dinner  one night, paid for our hotel rooms, and provided lunch every day. So Thanks to Novell for treating us right and getting us aquainted with Sentinel.