When you face a Dynamics CRM or AX implementation or you are already running a Dynamics CRM or AX system, security is probably not the first thing on your priorities list. And I do understand that, because your business is asking for functionality, performance, availability, integration, flexibility and so on. But security is not a sexy topic to talk about…
Why is security not a hot topic? A few excuses which could be the reason:
- A product such as CRM or AX should be secure by design. I don’t have to think about security anymore.
- Our company has an in house security policy applicable to all products in the infrastructure. Dynamics adheres to that.
- I don’t have the budget, so we will do it later. First things first.
- Security introduces complexity and is therefore a risk for the implementation.
- Security is a performance bottleneck.
If you hear one of these excuses, then actually we hear assumptions and that is WRONG. Most likely business critical data will be stored in your Dynamics product. So what is your excuse when your database is corrupted, unavailable or even compromised?
1. A product such as CRM or AX should be secure by design. I don’t have to think about security anymore.
The assumption here is that the Dynamics products ONLY run in a secure infrastructure. However, it is possible to run your Dynamics product on a less secure infrastructure. During installation Dynamics products do not check for encrypted devices or protocols. They also do not check Firewall state, Anti-Virus scanners and strong passwords. During an installation service accounts and updates are checked, but it is possible to work around these checks.
2. Our company has an in house security policy applicable to all products in the infrastructure. Dynamics adheres to that.
The assumption here is that if it is not in the security policy already, it is not applicable for your implementation. However it is likely that Dynamics products will introduce new ways to work with data. Think about local data availability, mobile data consumption, customer portals connections, third party product integration, new code and scripts. The question is: Does our security policy cover these new ways of working with business critical data?
3. I don’t have the budget, so we will do it later. First things first.
On the short term you have to invest a little if the security level you need for your business critical data is not reached. Think about: extra test cycles, certificates and extra documentation. But changing your implementation over time is much more costly because things need to change. Making your Dynamics implementation secure by design is the most effective way to reduce risk and costs.
4. Security introduces complexity and is therefore a risk for the implementation.
Adding security doesn’t make your Dynamics implementation more complex, but it is true you have to add more steps to complete the product installation. When these steps are documented and scripted, the installation time will be reduced.
5. Security is a performance bottleneck.
Some security features do consume more resources from the server or the client. Think about Encryption/Decryption or Anti Virus Scanning. But this might never lead to a performance bottleneck. If this is the case, the configuration is wrong and need to be adjusted.
SECURITY TIPS AND TRICKS
- Use the latest updates for all components
- Install Anti-Virus and configure exclusions properly
- Use strong passwords and change them periodically
- Limit the amount of administrators and limit user security roles
- Use Database Encryption and encrypt your backups
- Use https instead of http with a valid certificate
- Disable Mixed (SQL) authentication and only use Windows Authentication
- Enable bitlocker for drive encryption
- Enable auditing and check regularly for odd behavior
- Use IPSEC in your network
- Review the developed code and scripts
- Enable all firewalls and check the settings