Security event monitoring (SEM) seems to become more prevalent. In a relatively short period two customers with basically the same requirements. SEM in its bare essence means that “security events” are fed to a specialized department using a rule-base (e.g. Oracle Policy Automation) to identify whether follow-up actions are required. What are such events? Think of the login of a high-privileged account. Or adding a user to a Siebel responsibility. But most events will simply be neglected since they are trusted events. For example user Barry Halley who is a functional administrator adds user Linda Vaughn to a Service Rep responsibility. Not a true security event to be actionable. Now the same user Barry Halley removed himself from the “High-privileged accounts” responsibility. This latter responsibility is just an empty place-holder responsibility carrying no Siebel Views. SInce Barry removed himself he just made himself a regular user. Though still with administrative privileges – since he hold a number of administrative responsibilities. Oops – that could be a security event.
How could SEM be practically implemented in Siebel?
One way to think of – is to use Audit Trail as the fundamental capability to enable this. As long as everything is stored in the Audit Trail table – it could be extracted.
To start – customer needed to have a security event for a High-privileged account login. Siebel out-of-the-box writes the logout (not login…) timestamp in LAST_LOGIN_TS on S_USER. No so useful. So customer added X_HP_LOGIN_TS and X_HP_LOGOUT_TS as new S_USER columns. These are populated in TheApplication().Start(). Simply by reading a calculated field from the Employee BC IIf(InList(“HP Account Responsibility”, GetProfileAttrAsList(“User Responsibilities”)), ‘Y’, ‘N’)”. If the calculated field returns True, the X_HP_LOGIN_TS is populated. On the TheApplication().Close() event similar logic.
Next – enable Audit Trail on the User BC for both BC fields mapped against X_HP_LAST_LOGIN_TS and X_HP_LAST_LOGOUT_TS.
Know – to have security events for associations and disassociations of users from responsibilities – just add the necessary Audit Trail configuration.
The gotcha with Audit Trailing associations and disassociations is that only the child objects ROW_ID will be stored. Not so useful – that needs to be taken care of while extracting the data from S_AUDIT_ITEM for sure!
Now – extracting the data from S_AUDIT_ITEM. The official way is to use the Audit Trail VBC business component. But that’s a rather slow approach. A better approach would be to extract this data through PL/SQL on the database itself. It will be much more performing option. But… not supported by Oracle. In the event Oracle Engineering decides to alter the encoding of the S_AUDIT_ITEM.AUDIT_LOG contents – your PL/SQL will no longer work. That said – that risk is probable an acceptable one. I will spent more time on decoding the Audit Trail data in another post.
Finally – an absorbing SEM application will need to be fed regularly. Probable with the smallest possible delay. But extracting data from Audit Trail will need to be scheduled. If iterations follow each other quickly – the data to extract will be limited. Iterations of 5 minutes will likely be acceptable in reality.
Oh yeah – do not forget to take the Audit Trail modifications itself into considerations. Having an admin changing the Audit Trailed Business components / fields can definitely be a relevant security event! The good thing: Siebel OOTB has Audit Trail enabled on the Audit Trail business components. “Audit Trail Audit data” can be sent also to the consuming SEM application.