The latest news concerning wikileaks have some very important implications on CRM systems or xRM systems in general for that matter. How do you set the system up to avoid large information losses? There are some general things to be taken into consideration and some specifics for Microsoft Dynamics CRM.
For many companies, the list of customers, cases, interesting leads and business opportunities are among the most critical information the company has. If it gets into the wrong hands, the effects can be anything from embarssing to fatal. The latest weeks news concerning wikileaks has put this risk into some new light and it is a good time for companies to really put the right focus on this and handle the problem before it is too late. A competent CRM system like Microsoft Dynamics CRM, can, if security issues have not be properly addressed, be a great tool to very quickly export a lot of very business critical information.
There are some general tips that you really should address:
- How critical is the data? Which data is the most critical? Try to focus on the most important data instead of trying to set up fine masked security to cover all data. This will give you a bigger bang for the buck and also get the changes up and running quickly. Remember the fact that the chains often breaks at the weakest link, so focus on this link first.
- What legal aspects of the data do you have? Do all employees sign non-disclosure agreements and do they understand the severity of actually taking along some data to a competitor. In reality it is very hard to drive legal actions based on this but making sure all employees have understood the severity, will act proactivly to reduce the risk.
- Who can access the data? Usually not only the employees, IT-consultants, CRM- and ERP-consultants, and other contracted people might also have access.Trying to reduce the number of contractors, and signing company global NDA:s with contractors is usually a good idea.
- Where is the data stored? In these cloud computing times, this is not always a simple question. Data might be stored in a country with very rigid anti-terrorist or anti-piracy laws allowing government or other agencies to demand access to the data. If these government agencies judge that it be in their contrys best interest to send this information forward, this might also be done. Might sound a bit paranoid, but security policy is more about being paranoid than being naive. I would recommed hosting the system yourself or at a local partner. Preferably a partner of similar size to your own company since this will give you the same amount of flexibility and beaurocracy. This local partner will also be under the same national laws as your own company and have a more intimate relationship with your business than a huge corporation with a global hosting service.
- What is the weak link in the handling of data? It does not really matter if the CRM system in the cloud has astronomical encryption in the database and data transfers, if the people using the system have the same password in the CRM system as they have in all other online services like Facebook or Hotmail. Numerous examples have shown that people do share passwords between sites, and that cracking one site usually unlocks a lot more. An example can be a person using the same password for their local childcare portal as they do for their CRM at the global company they work for. The simple childcare portal, might be easily hacked with normal methods like SQL-injection and the passwords generated from this can then be used to access the global company CRM.
There are still more general principles to follow, I will not list them all here, if you have any you find particulary important, please leave a comment!
So, how do we handle this in Microsoft Dynamics CRM? There are several techniques that can be used but it is a constant battle between giving your users the power to really work with the data and making sure that the data is safe. Bellow are some of the more common ways of handling this:
- Security Roles and business units. The basic security architeture of Microsoft Dynamics CRM is really versatile and has very good support for separating users and data into different business units and then setting user roles to restrict access based on these business units. For instance, a team of telesales personell with a very high turnover of employees, can be set to only have read and write access to their own customers and opportunities and their team manager has the task of delegating the ownership of leads or opportunities to them. By using different roles, the senior sales team can on the other hand have access to all customers and business opportunities in the system. If a good separation of data can be done based on business units and security roles, this is a very good method since it is easy to set up and change, and still has very deep functionality in Dynamics CRM, going all the way down to the Filtered Views in the Dynamics CRM SQL-database.
- Disabling Excel export. Probably the most risky function in Dynamics CRM in regards to data theft from employees, is the Excel button. It can export any data the user has access to. There is a flag in the security roles, where this function can be switched off. It should be for all but powerusers, analysts and management.
- Limiting Excel export size. There is a way of manipulating the Dynamics CRM database to only allow a certain amount of rows in an excel export. As I have understood it, it is really a way of easing the load on the server and not really meant as a means of protecting data. It can only be set on a system wide way, which will limit the use of Excel for all users. You can read more about it in this blog entry, have a look in the comments, since it tells you how to set this for CRM 4. http://ronaldlemmen.blogspot.com/2006/11/maximum-amount-of-records-in-excel.html
- Custom Plugin code. Writing code that uses more complex functionality and filters the data can also be used. It need to trigger on the Retrieve, RetrieveMultiple and Execute methods. This is of course the moste versatile method. Even though it can be used to filter data that is accessed from the Dynamics CRM GUI it does not affect the Filtered Views in the database, so it is not a 100% solution but will work in most cases.
- Unsupported customizations. There is of course the dark side of customizations as well, by rewriting the database with new stored procedures, views, by modifying the existing CRM functionality, very deep changes can be made. This is not something I recommend since it will usually require deep reverse engineering and will seriously affect the upgradablity of the Dynamics CRM system.
This is a complex area and I would be happy to discuss it with you. Please leave a comment with your views on the subject. All comments are moderated to avoid spam.
CEO, Chief Architect and co-Founder at CRM-konsulterna AB