Information Assurance Best Practices for In-Flight and At-Rest Data

  |  January 4, 2017

It should not surprise anyone that the days of lax IT security practices are over. Information assurance has evolved out of the governance realm and into the world of implementation.  Almost every development work stream in a modern transformation project includes planning, building, and validating solutions to ensure the protection of critical and sensitive data, and data migration efforts are no exception. Whether it’s enterprise data in flight — that is, the data as it’s being transferred from your legacy system to your new system — or data at rest after it’s been migrated (in storage), you should adhere to two fundamental best practices to keep your information secure.

Understand where your sensitive data is — both in flight and at rest — where it’s at risk, and how to protect it

The first fundamental best practice in information assurance is to be fully aware of exactly what personally identifiable information (PII) and sensitive data exists in your legacy system, and specifically where it resides. By their nature, legacy systems often contain data that was created before more rigorous data protection protocols were developed. It’s sometimes surprising to learn how frequently older systems were “grandfathered in” when new and more stringent information assurance policies were put into place.

It’s also essential to understand that it’s not always easy or intuitive to know all the instances where PII exists. For example, in some databases, many older systems still use Social Security Numbers as internal keys to uniquely identify user information. In fact, this was actually standard operating procedure before SSNs became the veritable Holy Grail for identity thieves. Depending on the database and the approach used, it’s possible that SSNs may not even appear on any specific screen or report — yet they still exist, often unencrypted or otherwise protected, within the database.

Free Guide Download: Optimizing Data Migration Projects

For this reason, it’s critical to use data profiling software to identify and locate any instances of PII or other sensitive information in the enterprise data residing in your legacy system. Now for the not-so-fun part. This includes looking for sensitive data in places where you do not expect to find it. This means that finding every field in every data set or table that includes the terms “ssn,” “social_security,” etc. is only the first step. You should also use regular expression matching to find every occurrence of the familiar XXX-XX-XXXX sequence of numbers and hyphens in any character-based field in excess of 9 characters — even in places where the field or column name is not intuitive. (One easy way to do so is to use the regular expression “\s*\d{3}-?\d{2}-?\d{4}\s*“. You might be surprised at what you find.)

Taking the time to search thoroughly for such hidden PII is a must. Armed with the knowledge of exactly where PII resides in your legacy system, you can take steps to adequately encrypt the data — both during its migration as well as when it is at rest in the new target system.

Use standard enterprise data protection standards throughout the process

Naturally, throughout the data migration process you should continue implementing all the standard data protection processes and protocols your organization uses on a day-to-day basis. These are rather ubiquitous but effective techniques, ranging from AES encryption standards, using SSL on the wire, public key cryptography, digital certificates, and SHA hashing. Hashing data is not as secure as encrypting it, but it is still better than leaving it completely exposed. Check your target platforms to see which out-of-the-box choices are there before you start writing custom code. For example, if I were migrating to an Oracle RDBMS database running on Unix/Linux, I’d have a slew of choices on how to encrypt the data at rest without additional code, including:

  • Oracle Field Level Encryption
  • Oracle Tablespace Encryption
  • Filesystem or Logical Volume Encryption (choices vary based on Unix/Linux flavor)
  • SAN or Array Controller Based Encryption (depending on you storage infrastructure)

When it comes to security, don’t assume anything

The bottom line is that the process of moving legacy data could potentially expose sensitive data acquired or created long ago that your current stakeholders may not be fully aware of. Never make assumptions about security and information assurance. The network you are on is only secure until the first hacker inserts a packet sniffer onto the network, and physical storage locked in the server room might seem secure until the first tape backup gets misplaced. Plan to implement necessary security measures both while the data is in flight and once it’s at rest in the new system.




18 − four =