The non~linear blog gets a makeover

Two years ago, we launched this blog as a bit of an experiment.  Several hundred posts later, the blog has come to play a central role within our company - with our peers, our partners and our clients.

The work and referrals that have arisen out of this blog have kept us busy… so busy that the blog itself was, perhaps, a little neglected (at least from a design perspective.)

Today, we’re pleased to showcase a brand new design

Over the course of the redesign, I have had a chance to get intimately re-acquainted with the articles produced by my fellow colleagues.  And I have say, they have written some extremely interesting stuff.  To celebrate the re-launch, I thought I might highlight a few perennial favorites.

This is the first post in a series discussing security considerations and approaches for websites driven by the Sitecore CMS. The topic of discussion today is set-up and infrastructure.

Top ten Sitecore security dos and don’ts

1. Content authors should not be using the same installation as the actual website. The CMS should sit behind the firewall and publish content to the web server nodes.
2. The database and the CMS should reside on different servers. This physical separation reduces impact if there is a breach.
3. On the SQL Database, create a specific access account for Sitecore, and provide users with only the required privileges (db_datareader, db_datawriter, execute permissions on stored procedures, etc).
4. The Sitecore Data Folder should reside in an area that is not directly accessible via the web. This prevents unwanted access to files and forces all visitors to retrieve the files through the security rules enforced by the CMS.
5. If you’re using Sitecore 6 on IIS 6, note that there is bug in IIS and a default configuration value that may allow access to your web.config file. To prevent this, be sure your web.config contains the following code in the FilterUrlExtensions section:
   </p> <span desc=”Blocked extensions that do not stream files (comma separated)” class=”mceItemParam”></span>*</param>

A major concern for any website is its vulnerability to external attacks. While these security concerns are not unique to CMS-driven sites, they are especially important to consider in organizations that are using a content management system. The presence of a CMS introduces special considerations for security – for example, having many users inside the organization who are able to update the site. This series of blog posts is meant to guide the reader through a variety of security considerations related to CMS-driven websites, some of which will be specific to Sitecore. The good news is that all of these concerns can be addressed and overcome through careful planning.

Sitecore Security - Key Considerations:

• Sitecore Setup and Infrastructure
  Was Sitecore installed correctly, with the recommended configuration? Did you take the necessary precautions to protect IIS and the Windows server?
• Danger from within: Consideration of content authors, validation and governance
  Now that many people can update site content, what processes do you need to put in place to ensure that content authors do not accidently create a security vulnerability?
• Findability of private information
  When a CMS runs multiple sites or a public and private version of a site, does the implementation correctly protect access to content, particularly from the very thorough and efficient search engine crawlers?
• External Hackers
  Injection, Cross Site Script and Other Forms of Attack. While not specific to Sitecore or any CMS, there are certain techniques and approaches provided by the Sitecore backend that allow CMS developers to create even more secure and robust sites.
• Sleeping (peacefully) at night
  You have done your best during implementation, now what? Some final thoughts on tools to help you prevent problems so you can stop worrying about being hacked.

Starting in the next post, I will delve into each of these topics. If you would like to see other areas covered in this discussion you can always reach me at glen {at} nonlinear.ca.