“Google Search Reveals Community College Student’s Social Security Number.” While this may seem like a headline you would find on sites like The Onion, this is something that actually happened. This situation occurred when staff members at a community college started to test a new type of online application that utilized files full of sensitive and unaltered data on a server that was not secure. Even though this is an example that’s somewhat severe, if unmasked production data is used for test or development environments, serious issues can arise. To effectively prevent the possibility of exposing personal addresses, payroll information, Social Security numbers and other sensitive and private data to the wrong (potentially nefarious) individuals, developers should utilize datasunrise dynamic data masking. Have you heard of data masking? It’s a phrase that refers to data alterations from its original state to make sure it stays protected.
Lookup Substitution Process
The Problem: Think about any type of case where you have a database full of the Social Security information for your employees. This is information that should not be found in any type of testing environment. The Solution: A lookup table can be added in the production environment that can provide an alias for the specific value, limiting anyone’s access to the sensitive information. The Result: When this method is used, the testing environment isn’t populated with the sensitive information, however, it is still filled with realistic information/data.
The Problem: This is when the same issue mentioned above is present. However, here, rather than a lookup table, it’s eliminated because it could be compromised. The Solution: To fix this, the data can be encrypted. Only the people who actually need to see this information will be given the password that makes it readable. Encryption is a popular method used by changing the provided information into an unreadable format. This is one with the use of complex algorithms, which makes the data completely undecipherable until it is decrypted. The Result: Anyone who needs to have access to the data is given the password and those who don’t have this password can’t gain access to it. Keep in mind, if encryption is being used without any type of other data masking method, then the sensitive information can be instantly viewed once it is decrypted.
The Problem: With this situation, it would be if you had a list of customer credit card numbers. Because of the sensitivity of the information, it isn’t needed in a development or testing environment. The Solution and Possible Results: In this case, sensitive data can be substituted with a generic value. In most cases, this is typically only something that should be an option if the value isn’t needed for any type of development or QA purposes.
The Problem: In some situations, you may have some sensitive data that has to be protected, but unique values are also needed. For example, does the QA team need to verify pertinent information, such as the annual summary amount matching what’s set aside for salaries? The Solution: With shuffling, the annual salaries are scrambled from the initial employee. The Result: Employees can see the created salaries table with the values but can’t tell which one belongs to which employee.
As you can see, there are several methods that can be used to mask data and ensure it isn’t expected to nefarious individuals who may use it for dishonest purposes.