Siebel CRM has been in the enterprise world for more than a decade. You’d expect any things that need to be done from a data security perspective is already done somewhere and by someone. You’d expect most of those things to be already known to you if you spent any time experimenting with Siebel.

Or, so you think.

There are surprising ways that specific organisations use data in Siebel. A generic one size fits all approach For data security irks people quite a bit.

Before I go any further I would just like to outline what Siebel supports from a data security perspective.

Authentication #

As in any enterprise class application, Siebel supports authenticating the end-user to provide access to the application.

Siebel by itself does not have any authentication mechanism, but instead depends on third parties to carry out that authentication. That can be -

• Database authentication: use authentication provided for a user in the database. Each user must have a distinct login in the database.
  Not a popular mechanism for enterprise software due to user management issues - Siebel is not likely to be the only enterprise product used by the organisation.
  Siebel remote clients use authentication against the iSQL database The remote database acts as a mirror of the data that is required off-line.
• LDAP authentication: Integrate with a supported LDAP provider to perform user authentication.

For a full list of what third-party providers are supported, head over to the SRSP page .

Siebel clients for mobile piggyback on HTML 5 standards to store data off-line. They do not support off-line authentication at this time.

Access control #

One of the things that gets discussed in Siebel requirement sessions is “who will access what data?”.

Application access is provided after authentication. Data can be encrypted while being transported from the client to the server using HTTPS protocol.

Data access control in Siebel is primarily enabled in two ways:

1. Responsibility: Defines who gets access to the UI. For example, sales department users get access to “opportunities”, while service users look at “service requests”
2. Ownership: Defines what data the user sees on the UI. For example, sales rep has access to “my opportunities” while her manager has access to “my team’s opportunities”

Defining responsibility as well as ownership for a user is an application configuration activity in Siebel. They can be changed as and when the need arises without changing the underlying code.

But, the left-hand side of the equation is in the code. For example: Value in the position field of the account gets compared to the users active position. Position field (which I refer to as LHS) is within the code.

Changing code is often made a big deal since it involves multiple levels of migration, compilation and deployment - not to forget all the testing that is required in between.

Access to you by also gets defined by “personalisation rules”. These rules are defined in application and provide one more layer of control To enable a more dynamic access to UI. For example provide access to accounts applet in opportunity screen only if Position <> “CEO”.

Ownership gets defined at multiple levels -

• Person based: Tagged to an individual. Activities are assigned to a person and should be viewable by that person. The team may not have any role to play in a person’s activity.
• Position based: Tagged to a role. Accounts are assigned against a position. More than one person can get assigned to a single position, and/or more than one position can get assigned to an account.
• Organisation based: Tagged to a department. Accounts assigned against an organisation, which may or may not be shared across different organisations.

There are various permutations and combinations of the above attributes and the reporting relationships, but you get the general idea.

Bottom line: access to data gets determined by person’s responsibility as well as her role.

The “view” kind of requirements are quite straightforward and (comparatively) simple, but any of the other CRUD operations are not. Siebel provides specific user properties at the business layer to control who gets to update/delete specific data. But all these changes require changes in the code, and prove expensive if not designed properly.

Visibility rules for remote clients #

Data for remote clients for the same pattern as that defined in the access control mechanisms, with an add on enabler.

Routing rules #

Data routed to the remote clients for off-line usage are defined by a separate set of rules.

These get defined by:

• The routing model assigned to remote user
• Routing rules specified in the “Dock Object”

Together they decide which data has to be routed to the remote client.

Routing models can be changed at any time since the defined in the application, but change the dock objects need code changes. Help from Siebel expert services is often recommended to change dock objects.

Data filters #

Data filters are akin to routing rules - but applicable for Siebel off-line clients for mobile devices.

New in Siebel 8.1.1.14, data filters enable one more layer of filtering to make sure only required microdata gets passed across to the off-line clients.

Data filters are defined in the application, and are changeable at any time.

Data storage #

Siebel uses third-party databases to store data, and is dependent on the storage capability provided by those databases.

The business layer Siebel provides encryption and data masking features. Using business component user properties in the code, specific attributes (e.g SSN) can be encrypted independent of the database. Data can also be selectively masked, e.g., hide credit card numbers except for the last four digits.

More popular way of enabling data encryption at this time is by using the database capability. For example Oracle transparent data encryption (TDE) is often used in implementations that use sensitive data. In these cases the encryption is transparent to Siebel application, and there is no additional configuration needed on the Siebel side.

Consider performance implications while encrypting specific tables and attributes in the database.

For remote applications the entire “local” database can be encrypted.

Data Security considerations for a Siebel project #

After this not so brief introduction to what Siebel can do in the data security space, it is time to move on and then check out what exactly needs to be considered to enable data security for any Siebel project.

Data security is a long-term design decision. This means that as additional users/regions/departments become Part of the same Siebel implementation, the security rules should ideally not be rewritten to suit everybody’s needs.

Although data security is as old as CRM systems themselves, it is often misunderstood and poorly designed. Here are a few considerations that you can keep in mind for a Siebel project.

Don’t over engineer. #

I did tell you that data security has to be scalable for newer users. But at the same time this is not a license to over engineer the data access solution.

Organisations change. The business rules that are a must have today can undergo drastic changes in a couple of years. Regulatory requirements and other external factors change to suit the times.

It is not quite a good idea to consider the situation five years from now and design something that is not workable today. Keep it as simple as possible, close to vanilla but do consider the scalability angle.

Embed data security in functional requirement discussions. #

Project team become so busy and engrossed within the functional requirements, that any problem that can be put off later is enthusiastically postponed. Since data visibility is a tricky topic, have offered seem teams postponing the discussion of this topic to a later date.

And when this date finally arrives, there are more than a few surprises in store.

• There are dozens of fields on the UI that should not be visible to anybody less than a manager
• Don’t allow editing specific fields to the partner
• Restrict access to data to users from other countries

The best practice is to discuss data security requirements as you go through the process flows and structure the UI.

Consider regulatory requirements. #

If you have a global implementation the data security problem can get tricky.

• Personal health information (PHI. e.g., illness history) and personally identifiable information (PII. e.g., ) are provided on a need basis, and to specific roles. Access to data may even be audited by regulatory agencies.
• Data may not be stored in a server hosted in a different country. For example, date of EU customers can be stored in US servers (thanks to Safe Harbour agreements), but not in an Asian country.
• Data visibility across countries/continents may become really complex. For example countries like Russia do not allow data of Russian individuals to be accessed from other countries. Data restrictions even within the various countries in Europe are different, but would need to be considered.
• PII need to be stored in an encrypted form.

It is best to designate a legal/compliance representative during the functional requirements phase, and collect all such design influencers. This representative has to be made responsible to talk to all countries involved and consolidate any specific legal requirements.

The child data conundrum. #

Siebel allows visibility to be defined at the parent or at the child level. For example you will have access to your own opportunities when you go to opportunity screen, and see the same opportunities when you go to Accounts - opportunities view.

The only problem  - this is not defined out of the box. And most of the Siebel implementations do not do this. As a result the teams identified the need to filter out child data only at a later stage. Changes at that point can prove to be expensive, confusing and lead to several dependent bugs.

Pick and pop up problems. #

Users may assume selection of data in a pick applet, or in a MVG will be different from the visibility enabled on the screen. This may or may not happen depending on the application configuration. For example: I want to see only my accounts while trying to select an account in the opportunity. The default behaviour is to show all accounts in the organisation.

Consider dependent data while designing the process areas.

Be aware of CRUD. #

Business teams often do not envision how this solution works end-to-end. Unless specifically asked for the do not consider the entire data life-cycle in the CRM system (from collection through reporting and archival).

This is the same reason I try to avoid exposing the application for the first time the vicinity of UAT. Users tend to recognise the only when they see and use the application. Conference room pilots and/or user pilots mitigate this problem to a significant extent.

Also, take note of the following:

• Visibility rules in most cases cannot be dynamically defined, and certainly cannot be defined by users
• Providing one-off access to data is not possible for all practical purposes
• Having too many rules on who exactly can update or delete data at certain states may exponentially increase design complexity

Discuss all operations possible on data, harmonise those requirements, and drive data security design based on those factors.

Be aware of data migration implication. #

It is almost too easy to escape the visibility requirements by just mapping UI fields in the legacy system to corresponding fields in Siebel.

But bear in mind that legacy visibility rules may need mapping as well. Understand why visibility rules were built in a specific way, map those two existing/new rules within Siebel and port visibility specific data as part of migration.

Clearly outline integration requirements #

Data residing in external systems will have visibility controlled through those external systems. Any operations including integration triggers has to be controlled by the system in use. When it comes to the interface between the external systems and Siebel, authentication by using the distinct integration user is the first layer of security.

At the same time do not be afraid to implement additional security layers for sensitive data operations. This may include -

• Create distinct visibility rules at integration object layer
• Use cloned business components that can have integration specific requirements

Ideally, security applicable for integration specific requirements also need to find their way to the business layer used with the UI. But again, we don’t always live in an ideal world.

The important thing is to discuss overarching integration requirements alongside the functional requirements for a particular process area.

In Summary #

It is easy to mess up data access control mechanisms in Siebel.

Do not tread the easy path!