Main Content
How to Keep Data Secure During a CMS Migration header

How to Keep Data Secure During CMS Migration

Takeaway: Securing data is a continuous process, not just a one-time action. When we talk about CMS migration, especially for sites with sensitive information, the focus should be as much on keeping data safe during the move as on ensuring its ongoing security afterward.

As someone deeply involved in CMS migrations, my experience has shown that the real challenge lies not just in moving data, but in maintaining its integrity every step of the way.

This blog aims to clarify the challenges of ensuring security during a CMS migration, focusing on the tools, strategies, and best practices essential to protect your data. Whether you’re dealing with a government website or a private sector project, understanding these nuances is key.

We’ll explore how to identify and tackle potential security vulnerabilities, the significance of using the right tools and encryption, and how we applied these to Riverside County.

SHARE THE SUMMARY TO YOUR STAKEHOLDERS

 

Riverside County website homepage

 

Understanding security vulnerabilities in CMS migrations

In my experience with CMS migrations, particularly with platforms like Drupal, the security risks are often more subtle and complex than one might anticipate. We find key vulnerabilities not just in the potential for external threats, such as hacking or data breaches, but also in the migration process itself—like data handling and user access management.

 

Identifying vulnerabilities before migration

The first step in ensuring a secure migration is a thorough evaluation of your current system. This means looking beyond the surface and diving into the details of your CMS’s structure and data handling.

For example, how are user profiles managed? Are there any outdated modules or themes that might pose a risk? These aspects need to be carefully reviewed, especially for sites with a lot of user data or government information. The focus should be on identifying any weak points that could be exploited during the migration process.

It’s not just me who suggests this either. Look at what David Rubie-Todd, Co-Founder and Marketing Director of Glide has to say about this:

"For me, the best way is to perform a thorough audit of the data before initiating the migration process. This may not be an obvious step, but it's crucial to identify any potential vulnerabilities or outdated data that could compromise security during the transfer.

This approach came about after a migration project I was leading where we discovered halfway through that some of the data had not been updated in over five years and was not compliant with the current security protocols. It taught me the vital lesson of being proactive rather than reactive when it comes to data security during CMS migration."

Zephyr Chan, Founder and Growth Marketer of Better Marketer also puts it nicely:

"Migrating outdated, unnecessary, or sensitive data not only clutters your new CMS but also increases security risks.

I learned this the hard way during an early migration. We transferred everything, including old accounts and outdated files. It was a mess and a security headache. Post-migration, we found ourselves sifting through a digital junkyard.

Before any migration, you should audit your data thoroughly. You can remove what's not needed. This approach streamlines the migration and tightens security. It's like moving house—why pack and move stuff you don't need?"

 

cluttered desktop
Image from ZME Science

 

Having a separate database layer

When migrating to a new system, it's crucial to ensure that not only your Drupal codebase is secure but also your database and server. Ideally, the database should be on a different server than your codebase to enhance security against potential hacking attempts.

There should be a separate database layer to prevent easy access to your database. It's essential to store the database safely in a different location. The code and database servers should interact using encryption keys for security.

 

Database layer

 

Best practices suggest that for migrations, whether you’re migrating from an older version of Drupal (Drupal 7 or earlier) or from another CMS to Drupal, attention should be paid to the locations of the database, file system, code, and repositories, like GitHub.

Previously, these components were often stored on the same server, but now, with improved security practices, it's important to ensure proper configuration even before updating or upgrading your Drupal systems.

 

Why a proactive approach in security is best

A proactive approach to security is non-negotiable. This involves not just patching up known vulnerabilities but anticipating potential issues that could show up during migration. It's about being one step ahead.

Montserrat Cano, International SEO and Digital Marketing Consultant at Montserrat Cano believes in involving the IT team right from the start:

"Involve the right people! During the migration process, especially during a re-platforming, there is a particular moment when the website is especially vulnerable to cyber-attacks. Working closely with your IT team will help protect your brand.

A second tip is to ensure that you audit well to understand what data there is and what you need to keep. This is especially important with customer data. Back up data in case of any issues."

In practice, this means ensuring that all software is up-to-date, using robust encryption methods for data transfer, and being vigilant about access controls and permissions. The goal is to mitigate risks before they become actual problems.

Alex Stasiak, CEO and Founder of Startup House recommends the same thing— to practice the principle of least privilege:

"Only give access rights to those who absolutely need them for the tasks at hand. We stumbled upon the value of this approach after a migration where excessive access led to unintended data exposure. By narrowing access, the chance of leaks tightens up significantly. Couple this with real-time monitoring to catch any unauthorized access attempts, and you turn your data migration into a fortress, with data moving securely and only accessible to a select few knights sworn to protect it."

 

Tools and strategies for a secure migration

A successful and secure CMS migration hinges on a combination of the right tools and their strategic application. It's about weaving a tight security fabric that leaves no loose ends.

 

Choosing the right tools for the job

The effectiveness of the migration largely depends on the tools we choose. For instance, in Drupal migrations, I often rely on PHP Data Objects (PDO) for database abstraction. This isn’t just a preference; it’s about ensuring the highest level of security in data handling.

We encrypt sensitive information such as API keys, tokens, passwords, and personal data. This encryption, along with PDO statements, ensures secure data insertion into the new database.

Another indispensable tool in our arsenal is the Security Review module in Drupal. It’s like having a vigilant guard that continuously monitors the site’s security status, pinpointing vulnerabilities and guiding us on how to fortify our defenses.

New Relic Digital Experience Monitoring is another tool we use, which comes standard with Acquia. It's instrumental in identifying security threats.

For example, if we’re getting slow web transactions, slow queries and repeated attempts, New Relic helps us detect that. We can then block the offending IP address. This tool is invaluable for maintaining site performance and security, allowing us to quickly identify and address issues like bot attacks.

But it’s not just about having the right tools—it's about how you use them. Take PDO, for example. We don’t just use it for database interactions; we make sure each data field is processed through secure functions.

This meticulous approach is critical in preventing vulnerabilities like SQL injection. Similarly, data sanitization, particularly in web forms, is a practice we emphasize repeatedly. It’s about making sure that what goes into your database is exactly what’s supposed to go in—nothing more, nothing less.

I’ll go into these in detail when I discuss the Riverside County project.

 

The crucial role of encryption

A key aspect we can’t overlook during migration is encryption. It’s our fail-safe. Drupal actually provides options for encrypting keys. For instance, if your file system and database are on different servers, Drupal has modules that encrypt and store these keys securely. This ensures that whether the data is on a development, test, or cloud server, it remains out of reach from unauthorized access.

I like how Burak Özdemir, Founder of ozdemirburak.com puts this:

"In spy movies, there's always that tiny device that destroys all the evidence. We don't go that far, but we do something sort of similar with encryption keys. 

They are kept separate from the data. If someone grabs our database, they'd just get gibberish without the key. 

The "aha" moment came when we heard about a company that lost everything because their keys were taped to the data—figuratively speaking. Not us. We keep our keys in our pocket, away from prying eyes."

Another example I can give you is when I worked on the Knowledge Network project. They had a lot of sensitive user data on their website. They were concerned about how this data would be handled, especially on test servers.

 

British Columbia's Knowledge Network logo

 

At Promet, we specifically wrote scripts in Drupal to encrypt data flagged by the client. The migration scripts were carefully crafted to ensure data security.

Drupal offers default modules like Migrate, Migrate Upgrade, and Migrate Tools for migrations, which are user-friendly. Additionally, you can incorporate custom code to encrypt sensitive user data. Drupal provides numerous examples on how to write these scripts, allowing you to customize and execute them for secure data migration to the new system.

Speaking of which, Drupal is impressive in this regard. They offer a lot of test scripts within their migration-related modules. When you install these modules, they provide a set of test scripts that you can modify and use for your migration. It's quite handy and effective.

This is one of the many reasons why we advocate for open source for government websites—you don’t really get these with proprietary systems.

 

Navigating government standards in the Riverside County project

For Riverside County, our approach was multifaceted, involving the meticulous migration of content from over 50 non-Drupal websites into Drupal. This wasn’t just a matter of transferring data; it was about redefining how we protect it during the migration.

 

How our team ensured security for the Riverside County migration

Here’s a quick summary:

 

Secure CMS migration checklist

 

The key aspect is staying up-to-date with security releases. We subscribe to all Drupal release notifications and ensure that all modules and themes are consistently updated.

The first point to note is that we always use the Security Review module for every project. This is a standard practice, whether it's a newly migrated website or one we're building from scratch. This applies to all migrations, whether Drupal-to-Drupal or from another CMS to Drupal. Anything coming into Drupal undergoes this security review.

Next, writing secure code is crucial. Drupal has robust standards for coding, including specific functions to use when interacting with data. This includes stripping off extra or special characters. At Promet, we adhere to these secure coding standards in all our custom code and patches.

Managing sensitive keys effectively is another crucial aspect as I mentioned earlier. Drupal's Key module is excellent for handling various keys, like API keys, encryption keys, and database keys. It ensures all sensitive keys are securely stored and managed.

Additionally, we use Twig templates for front-end display. These templates ensure that data coming from the database is properly sanitized and presented in a user-friendly format.

For instance, they can filter out extraneous characters, like Chinese or Persian characters, displaying data in plain English. This also applies to form inputs, ensuring we only capture and store clean data in our database.

So, the security measures apply in both directions. We use a database abstraction layer for querying the database. We utilize PDO, which means we don't use straightforward queries. Instead, each field goes through a secure function, ensuring SQL injection is completely mitigated.

Regarding bot attacks and failed login attempts, we have measures in place to address these. If we detect multiple failed login attempts from the same IP address—say, four, five, or ten times—we block that account for a period like 24 or 48 hours. This is a configurable Drupal default security feature, tailored to each client's needs.

Drupal's flood table records failed login attempts, including the username and IP address involved. We can configure it to block access after a certain number of failed attempts, regardless of whether they come from the same or different IP addresses.

Effective user roles and permissions management is also crucial. We ensure that anonymous users don’t have access to modules they shouldn’t. Even for authenticated users, roles are clearly defined. For example, a content manager would only have access to manage content, not to the administrative functions of the website.

We also advocate for strong user authentication methods, like two-factor authentication. While it's up to the client to implement it, we always recommend having secure passwords, especially for admin accounts.

Lastly, we advocate for the use of HTTPS on all websites to ensure secure communication. Having a secure certificate is something we consider a best practice for all our projects.

We ensure HTTPS is used for both back-end and front-end, as we did for the Riverside County project. This is crucial for secure communication.

 

Implementing enhanced encryption measures

In addition to Drupal’s standard encryption, we applied an extra layer of security. This robust encryption practice was crucial in safeguarding data across various servers, including development, test, and cloud environments.

It was a step beyond the norm, tailored to address the specific security needs of a government project like Riverside County.

 

Strategic file migration and file permissions for enhanced security

Another aspect of our strategy was the migration of files as media entities within Drupal. This approach not only offered enhanced security for sensitive documents, such as resumes and cover letters, but also improved their usability within the new system.

Secure file permissions are also a key aspect. File permissions should be configured to grant access only as necessary. This applies not just to user-uploaded files like PDFs or Excel documents, but also to core code files, like PHP files and autoloaders.

These files execute when a homepage or index page is accessed, so it’s important to set up a secure file hierarchy. The permissions should allow only the necessary user groups, like 'www-data' for Apache, to have execute permissions.

And if it’s a public folder, we adjust permissions accordingly. For example, administrators or content managers might have write permissions, and users might be allowed to upload resumes. But execute permissions are always given with utmost caution to maintain security.

By the way, this approach to securing file permissions isn’t client-specific; it’s a standard practice at Promet to ensure a secure website.

 

Maintaining discretion for sensitive information

A unique requirement of this government project was the careful handling of highly sensitive information. For instance, ensuring that phone numbers of higher authorities were not immediately visible on the website, but accessible through multiple layers of screening.

This level of discretion was crucial in upholding the privacy and security standards expected of a government site.

 

On data privacy

Regarding GDPR compliance, we support various compliance tools like OneTrust or Cookiebot, depending on the client's requirements. Some clients are keen on GDPR compliance, so we ensure their sites adhere to these regulations, including the use of cookie banners. However, if a client doesn't require it, we may not implement such features.

 

Have a secure CMS migration journey with Promet Source

When it comes to CMS migration, you need a balanced approach that prioritizes both technical precision and security.

As we’ve explored, the key to a successful migration lies not just in the tools and strategies employed but also in a deep understanding of the potential vulnerabilities and a commitment to proactive security measures.

Whether it's managing intricate government data or ensuring the integrity of a private enterprise’s digital assets, the principles of diligence, thoroughness, and continual vigilance remain paramount.

Remember, a secure migration is a journey that extends beyond the technical transfer of data. It’s about building a foundation of trust and reliability, ensuring that your data remains protected, and your digital presence robust and resilient in the face of evolving cyber threats.

Are you preparing for a CMS migration and concerned about the security of your data? Our team of experts is here to guide you through every step of this critical process. With our deep expertise in CMS migration and a focus on robust security practices, we ensure your transition is not only smooth but also fortified against potential risks.

Connect with us for a personalized consultation, and let’s ensure your CMS migration is a secure, seamless, and successful journey. Your digital assets are invaluable—let’s protect them together.