How to secure your Kentico CMS platform

Following on from the article we wrote about the security threats we face on the web, it seems like a good time to brush up on what we can do to minimise these threats within specific CMS platforms. The following shows some best practice steps which can lower the risk of any foul play within a Kentico CMS.

Just for total clarification, the steps outlined in the article are specifying best practice and will lower the ‘percentage of risk’ considerably if the platform is compromised. 

A 10 point plan to secure your Kentico Platform

1. User Accounts

Make sure administration and housekeeping is done within the CMS. There should be no rogue test user accounts/roles active or enabled - so these need to be either deleted or disabled.

As a general housekeeping task i would uncheck ‘enabled’ user accounts, then if an account is disabled by error it's straightforward to re-enable the account again.    

2. Keeping the system up-to-date with hotfixes

Keep your platform up-to-date as hotfixs/patches can be security based. An example is the hotfix on Kentico V8.

Example: 8.2.48: Security - Cross-site scripting in the administration UI. Don't know your version? This can be found quickly, go into the CMS and click the question mark in the top right corner of the screen.

The number will be to the right of ‘request new feature’. Remember Kentico have a 7-day Bug Fixing Policy.

3. Specify certain File types that can be uploaded

You can specify which extensions are allowed for uploaded files in general and this does include forms.

4. Restrict Areas

Ensure UI personalisation for specified roles is set correctly to prevent users from accessing unnecessary user interface. You can configure UI personalisation in the UI personalisation application, example shown below. 

Figure - Configuring what modules get displayed to a user, however beware of the ‘Design Tab’ 

We configure the templates within the design tab so that these can be configured and customised within the ‘Page Tab’. 

The problem is, the ‘design tab’ allows the page templates to be altered, meaning all the pages using this template can be altered quickly. This is brilliant if a change to a template is required and cascades to all the pages using that template. On the other side of the coin, we often restrict access to the design tab as there is a risk some users will unknowingly make huge changes across the site on a template level. 

Please note: Templates do have a revision history so things can always be reverted quickly if this did ever happen.

Don't forget! You may still want users to have the editor WYSIWYG tool-bar to format text within widgets and/or pages, similar to the one shown below.

Below is how you can configure it so the WYSIWYG gets displayed to the user within a role.

Figure - Don't forget to configure the WYSIWYG toolbar within 'Editor'

5. Restrict Permissions

Ensure Permissions for specified actions in Kentico modules are set correctly for all roles. You can configure permissions in the permissions slide on a role level. 

For example: Within the Pages module you can configure the following permissions:

• Browse tree    
• Read    
• Modify    
• Check in any page    
• Create    
• Delete    
• Manage workflow    
• Destroy    
• Modify permissions    
• Submit for translation    

6. Strong Password

Make sure users are only allowed to use strong and complex passwords. Below are the settings where you can configure this.

7. Password change after elapsed time period

You can configure the need for passwords to be reset after a period of time. This will lower the risk of gaining entry to the CMS.

8. Password storage

Ensure passwords are stored in a strong and secure format. The recommended option is SHA2 with salt and can be set in the drop-down within settings.

9. Specify the number of password attempts 

Following a similar principle to your bank card, it is wise to limit the number of password attempts that are allowed. For example you can define the number so you can only have 5 attempts before your user account becomes ‘locked’,

10. Audit trial for page/templates 

Enable a workflow and apply to pages to be able to log version history. This doubles up as an audit trail and the ability to revert any changes quickly to a previous version. This is to provide you with a safety net to revert any changes if an error takes place.

Consultation and a Security Review

Doing these 10 points above should help secure your Kentico site and is a great starting point. Moving forward you may want to do more and do your due-diligence that your platform is as secure it could be.

In summary, we would recommend that you take the following steps to ease any security concerns you have:

• Quba can review your current site to illustrate your strengths and weaknesses.
• We can provide recommendations that will increase security and ensure best practice is adhered to.
• If required physically perform the upgrades and execute delivery. 

Kentico also offer their own consultation and security audit/review and further reading can be found in this Kentico CMS Security White Paper.

Call: 0114 279 7779 or Email: hello@quba.co.uk to speak to a Quban if you require any guidance on this topic.