Having problems with your account or logging in?
A lot of changes are happening in the community right now. Some may affect you. READ MORE HERE

Improving and Monitoring a Data Security Practice

Micro Focus Expert
Micro Focus Expert
1 0 846

In our post on implementing data security throughout the enterprise, we discussed the fifth of six processes for “standing up” a data security practice.  After that, we spent noted how to reduce the cost and increase the performance of data protection technology. Now it’s time to introduce the sixth and final process of the series: improving and monitoring a data security practice.

Improving and Monitoring a Data Security Practice.jpg What is our motivation for a post-implementation process in our data security practice? After exerting so much effort, planning, and time into this project, we want to make sure it continues to function well into the future. Just as a car needs regularly scheduled maintenance to avoid become a repair nightmare, a data security practice needs regular improving and monitoring. Also protecting our data does not stop hackers: when describing what is a data security practice, we noted nine percent of attacks abscond with data while remaining undetected for weeks.

This post-implementation process starts with a single input: the data protection spreadsheet we developed during implementation. This spreadsheet contains a mapping of the technology used for protecting each critical digital asset in the enterprise. We may begin this process in parallel with implementation by performing our activities after installing each technology.

The first activity is to collect operational data. We need to integrate log output from our newly installed data protection solutions into our security operations center (SOC). If our solution has a centralized management console for event, key, and policy management, this step won’t take much time. However we must start ingesting into the SOC all the new logs that these new solutions generate.

The second activity is to observe usage patterns. What constitutes normal will vary depending on our particular implementation. Yet we should be able to detect patterns of typical behavior and sort these from suspected behavior.

Let’s imagine, for example, a global retailer with distributed customer service. We may notice protection activity (encryption and tokenization) 24x7 in the order database as on-line shopping is continuous. However we may simultaneously notice that each regional call center has only twelve hours of re-identification activity (decryption and de-tokenization) while that center is handling customer calls. For this activity, we want to discover what constitutes the “new normal.”

Our third activity is to implement operational restraints on out-of-bounds activity. Continuing our distributed customer service example, we may wish to restrict key delivery to call centers based on time of day. That way agents can access keys when the call center is open for business yet not outside those hours.

Our fourth activity, one often overlooked, is to engage with the user community. Just as a new machine must be carefully operated during a break-in period, we must expect users will face work­flow interruptions after we implement a new data security technology. We must provide users secure work-arounds to these interruptions. Otherwise we run the risk that users will introduce their own mitigations which more than likely won’t be secure.

Our fifth activity is also user-focused. We must integrate data security problems and solutions into our internal IT help desk. We can use the information gathered during community engagements and feed this forward into the trouble ticket system. That way we can continuously improve our data security implementation via automation around or education about multiple trouble points.

Does this process ever end? Are we ever really ready to exit? Not really, as this is a continuous maintenance process. We need to improve and monitor our data security practice throughout its life cycle.

Yet this is, however, the last of the six processes used in establishing a data security practice. In our next post, we’ll look at key takeaways from the exercise.

Meanwhile, what are your thoughts on improving data security? What is your experience with rolling out data protection? We’d love to hear your thoughts in the comments below.

About the Author
Solution architect for the Voltage SecureData product family.
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.