Implementing Data Security Throughout the Enterprise

Finally, the moment many have been waiting for. Especially the tech types: network and software engineers. After developing a prioritized security strategy, the fourth of six processes for implementing a data security practice, we can start the fifth and next to last process, namely implementing data security throughout the enterprise.

Implementing Data Security Throughout the Enterprise.pngWhy has this taken so long? Well, our activity up to this point has rolled forward into creating that prioritized security strategy. Which is a key by-product of complying with regulations such as the General Data Protection Regulation. Without this strategy and the complex work leading up to it, we run a risk of implementing data security in a manner that would be inefficient and ineffective.

Finally, we are now ready to roll data protection out throughout the enterprise. Let’s take a process-driven approach and identify our inputs, activities, outputs, entry, and exit criteria.

For inputs, let’s start with the output of the previous process, namely the prioritized security strategy. As a quality control input, let’s also use the output of our critical digital asset identification process to verify we are performing a true enterprise-wide delivery. And for reference, let’s get a copy of the data protection stack so we can identify which asset will be protected by what technology. We can start our process upon collection of these inputs.

Now onto the process activities. First, let’s verify we have accounted for all of our critical digital assets. We can do this by comparing the critical list with the prioritized strategy. Make sure every asset on the critical list shows up in the strategy, even if the proposed remediation is do absolutely nothing.

Second, let’s get organized. Let’s classify our critical digital assets along two dimensions: first by storage type and second by storage location.

This is easy to do with a spreadsheet. Create a tab for each storage type: cloud bucket, database, file share, hard drive, storage area network, and so on. Now for each tab, identify where each asset exists.

For example, the database tab might identify the credit card database is in Oracle, the customer list is in SQL Server, the inventory control is in PostgreSQL, and so on. Perform this classification for all storage types until we account for every critical digital asset.

Third, let’s choose a data security technology. We can continue building with this same spreadsheet. Using the data protection stack, add a column specifying the type of data security (application, network, database, file system, block storage) that should be used to protect the asset.

This begs a question, how would we choose which technology should apply to what asset? We can make this decision with a number of guiding factors: persistence, pervasiveness, preciousness, and priority. OK, I just made this up to match the “four Ps” of marketing (product, price, promotion, place), yet you’ll see this works out in the end.

By way of review, the data protection stack shows us where protection (in the form of encryption or tokenization) takes place. Recall that every time data transitions from a protected to unprotected state, we must account for the resulting security gap. Data protected higher in the stack is less likely to be exposed in such a gap.

Now let’s perform a technology assignment using our four factors starting with persistence: what is the lifetime of the asset? Is the asset short-lived, perhaps something that is used temporarily and then disposed of? Or is it an asset that lasts the lifetime of the enterprise? The longer the persistence, the higher we should be in the data protection stack.

Second, how pervasive is the data? What is the “foot print” of that data in the enterprise? In-cell encryption might be sufficient for data confined to a single database, for example. Yet data that updated across multiple databases, however, should be protected at the application level. Otherwise we would require remediation for the security gap created as data leaves one database and enters others.

Third, how precious is the data to the enterprise’s operations? File system protection may suffice for bulk reports that are used only occasionally. Customer lists, however, demand application level protection before (and especially if) we upload them to “software as a service” applications.

Fourth and finally, priority. We have prioritized our security requirements via pairwise comparisons and cost-value mappings. Assets that are higher in prioritization should use technology higher in the data protection stack to reduce risk generated by security gaps.

Our technology assignment is now complete. We now have a matrix ranking each critical asset by storage type, storage location, and technology assignment. We know what type of data protection we will use for each of our critical digital assets.

Assessment and planning are finished. Once this output is complete, we can exit the process and feed the results to our corporate IT security implementation team.

The last of six processes for implementing a data security practice is that of improving and monitoring the to make sure we maintain compliance and “future proof” our efforts. Before discussing that, however, in our next post we’ll take a technical detour into understanding the major drivers to reduce the cost and increase the performance of application level data security: decryption avoidance and key management.

What are your thoughts on this process for rolling out enterprise-wide data security? Have you ever been on a planning team that made these kinds of decisions? Have you been exposed to this kind of process before? We’d love to hear from so please post a comment below.


Data security and encryption