--2020 Update: for information on securing your Sitecore 9 XP PaaS go here. --
Sitecore Experience Platform (Sitecore XP) is designed to be the leading digital experience platform. You likely chose it to give your clients a personalized experience they can’t find anywhere else.
Whether you’ve made the investment in Sitecore to be the center of your business or you’re just starting out with Sitecore, you want your customers to feel safe using your website. Sitecore features a commerce component as well as content management, so you need the trust of your site’s visitors so they feel safe purchasing from you.
Not every entrepreneur can dig through the security documentation to find all of the key security features required to be safe. Don’t worry. We’ve done that for you.
Here’s 5 steps you need to take to secure your Sitecore installation, distilled into practical steps.
Step 1: Secure the Sitecore Environment
Web application security is more than just securing software, and securing Sitecore XP is no different. The machines the software runs on must be protected from attack. Securing the environment means hardening the machines on which Sitecore’s key pieces operate to ensure attackers can’t find a small crack and use it to attack your site.
First, you should shut down all unnecessary services running on the server. Services are small programs that are always running on servers just in case anyone needs them. Identify any services you really aren’t using and turn them off or remove them entirely. Attackers have used vulnerable services to take over servers and gain access to other programs, such as an unsuspecting CMS installation.
The servers that are used for administrative functions and content creation should not be accessible to just anyone who wants to connect. In general, limit the IP addresses that can connect to your content authoring environments. It’s also a good idea to use multi-factor authentication on these servers to make sure only authorized users can make impactful changes to your site.
Finally, make sure the operating system on your servers is patched regularly. Patch management can be challenging, especially for larger organizations. However, patches are essential. A secure Sitecore installation could be compromised if your operating system is vulnerable to attack.
Step 2: Secure the Sitecore Application
Once the environment’s secure, it’s time to lock down Sitecore CMS itself. Complicated configuration can seem like a mountain to climb. Here’s some absolutely essential configuration you should have in place for a secure site.
The first order of business is passwords. Disable the default administrator account and create new admin accounts with new strong passwords for all of the accounts. Defaults are easy targets for attackers. User passwords are also important. Anyone who needs access to Sitecore’s content creation and publishing features should have strong passwords.
In the web . config file, in the <membership> section, you can set the following properties. We recommend the following values:
-
minRequiredPasswordLength = 8
-
minRequiredNonAlphanumericCharacters = 1
-
maxInvalidPasswordAttempts = 3
-
passwordAttemptWindow = 20
-
passwordStrengthRegularExpression = "^(?=.[a-z])(?=.[A-Z])(?=.\d)(?=.[@$!%?&])[A-Za-z\d@$!%?&]{8,}$"
If your company has password requirements for other systems, apply them to your Sitecore installation with the properties above.
The password itself is one aspect of a secure site. Another is the password hashing algorithm used to store passwords. The default algorithm is SHA1, which is simply not good enough. You can change the algorithm through the web . config file in the <membership> node. Set the hashAlgorithmType property to SHA512.
Make sure the core folders for Sitecore are not exposed unnecessarily. In the Internet Information Services (IIS) manager, you should prevent anonymous users from accessing the following folders:
• /App_Config
• /sitecore/admin
• /sitecore/debug
• /sitecore/login
• /sitecore/shell/WebService
When securing your environment, you had to disable unused services on the servers your Sitecore instance is running on. A similar rule of thumb is good for the administrative tools exposed in the Sitecore interface. Any content delivery servers exposed to the Internet should have administrative tools, such as SqlShell, Pipelines, FillDB, and logs. Never enable administrative tools on roles such as Content Delivery, xDB Reporting, or xDB Processing.
Remove the ability for users to upload files that may be shady into the Sitecore Media Library. Files such as .exe or .dll files really are not necessary in a content management system anyway.
You also want to remove unnecessary header information. Headers are a way to tell browsers information about the server they’re connecting to. Exposing too much information to end users could give attackers clues about how best to attack your site. It’s best to remove the following headers:
-
X-Aspnet-Version HTTP
-
X-Powered-By HTTP
-
X-AspNetMvc-Version HTTP
-
Server
The Sitecore docs don’t mention the “Server” header but this is also information you really don’t need to put out there where attackers can get it.
Step 3: Secure Your Connections
Data is the lifeblood of business and your CMS. This data has to be protected while it’s moving between computers. If it isn’t, data could be changed or stolen in transit.
HTTPS is the best way to protect data in transit. HTTPS is what causes the little lock to appear at the top of your browser when connecting to a website. It encrypts the data sent to other computers and protects it from tampering.
Sitecore enables HTTPS by default for the following services:
-
XP service roles
-
xConnect Search
-
xDB Processing service
-
xDB Reporting service
-
Content Publishing role
Make sure that all connections for your content management and content delivery environments are HTTPS. If you use Solr or the Azure Search provider for content search, make sure your connection to these services also uses HTTPS. Finally, use your IIS server to redirect any HTTP requests to your site to HTTPS to ensure only HTTPS requests will be served by your Sitecore instance.
Do a network check and look for any connections which aren’t using HTTPS. Some services have it enabled by default, but make sure nothing slips through the cracks.
Step 4: Separate Content Creation and Content Delivery
Now we step into the basic architecture of your Sitecore installation. Sitecore has many roles which each perform different tasks. Some roles serve the content you’ve created to the user. Others create the content and perform important tasks that transform data. Still others expose key administrative functionality which shouldn’t be exposed to the outside world.
The architecture defines how the different servers and roles interact with each other. The best architecture for a secure Sitecore CMS is one where the content creation and content delivery is separated from each other. Let’s look at a diagram to illustrate the point.
Content creation should be done by your employees only. Therefore, no content creation server should be exposed to the Internet. Only content delivery servers should be accessible from the Internet. Why is this important? If an attacker were to bring down your content delivery server or compromise it, the scope of the attack can be contained. You can create a new content delivery server and restore the data because your content database is safely tucked away out of the attacker’s reach.
Use a firewall and DMZ to protect your content creation server from the outside world. The DMZ is the small section between the two orange firewalls in the diagram above. Now your content creation server is safely tucked away without your users losing access to your content.
Step 5: Create Policies and Documentation
Now comes the part many don’t want to hear. You need policies. It may put a bad taste in some mouths, but policies can be helpful when done for the right reasons.
When security is a key piece of your site, standard build policies and clear documentation are essential to establish a secure environment and keep it secure. Clear policies help to create a blueprint for future growth by outlining exactly what configuration is necessary for new Sitecore servers. If your traffic grows to the point where you need more servers, the people building the new servers may not be the same people who built the original servers. These new builders will know exactly what to do to secure your new servers when they have clear documentation.
When operating in a cloud environment where automation can be used to create new servers, a written policy allows for scripts to be written that ensure a secure build with just the push of a button. Clear, and written, policies make the creation of servers much easier over time.
Sitecore Security Hardening Is Possible
CMS software can be complex, no matter how tech savvy you are. Sitecore is not different, but it can be secured with help from the experts. The tips above will help you secure your Sitecore CMS, but it’s okay if you need some personalized help. Get in touch with Engine Room if you’d like us to take a look at your installation and make sure it’s as secure as it can be. We can’t wait to work with you.
