If you have been reading my blogs previously you might have noticed that I several times (More on the insecurity of data, External posting on if your cloud system is safe from the law) have written about the fact that I think that many companies are viewing clouding a bit too lightly, especially from the legal perspective that many countries governments perceive themselves of having the rights to your data if the data either resides in that country, travels through that country or is owned by a company in that country.
From this perspective, I must conclude that the Snowden case is not very surprising. It mearly confirms what I expected to be true all the time and I would say that anybody being surprised is rather showing exceptional naivety towards our governments.
Hence I would just again remind you, that if you have sensitive data, beware of all the threats to the data. There are hackers, lawyers, FBI agents, and XYZ-agents and you have to assess the interest of all potential parties to you data. Then understand and handle the risk in a controlled manner.
MVP, CEO and owner at CRM-konsulterna AB
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
When creating workflows there are some things that have to be taken into account. One thing that you might not know the details about is the Scope in “Options for Automatic Workflows”. There are four options that are very similar to the options used for setting up security roles. They are:
– Business Unit
– Parent: Child Business Unit
Bellow the selection of the scope, there are some workflow triggering options, like starting the workflow when on create or when an attribute has changed.
The meaning of this is that dependent on the scope you have selected, the triggering will be set up, based on the user who owns the workflow.
So, for instance, if I select “User” in scope and then select triggering on attribute change, and I am the owner of the workflow, then it will only trigger when I make a change to the object.
If scope is set to Organization, it will trigger for all users in the tennant which is why this is most often used. Note however that user is set as default, so you’ll have to change this when creating the workflow if you want it to work for someone else than yourself.
This is a useful tool since it can allow powerusers to create their own workflows to help them with their work without actually enabling this for everyone else.
As I have mentioned earlier, the workflow functionality is very powerful, and even thought there are protections agains infinite recursions and such, there is still the risk that semi skilled powerusers creating workflows that put a heavy load on the asyncservice, so I would be a bit reluctant on letting them use this. Thorough training is a must before and try to teach them to keep the workflows simple. If you have several custom workflow activities, for instance, activities for integrating with other systems, I would be very careful since it is hard, if not impossible to restrict a custom workflow activity to just a selected amount of users.
Microsoft Dynamics CRM Architect