Data centric security: The only way forward


This content is over 24 months old. While the research and opinions expressed by Neuralytix was valid when published, readers should not rely on the applicability of the content in the context of today’s market.


Security is not a standalone function. Neuralytix believes that data security cannot be application based. The only way forward must be data centric security.

What is data centric security?

Data centric security refers to the combination of data security risk intelligence and data security controls.

Data security risk intelligence is itself a combination of manual processes, homegrown tools, and niche vendor solutions. The challenge with data security risk intelligence is these technologies are not meeting the challenge of expanding and highly distributed nature of data today.

On the other hand, data security controls are how credentials, encryption, masking, and tokenization of data take place. While all these controls have some form of password and/or identity asset management in place, encryption, masking, and tokenization controls that follow the data through its progression through various processes have limited penetration today.

At the end of the day, data centric security allows broader, more granular security controls of data. This must be “table stakes” in the burgeoning and proliferating nature of data today.

Who cares?

In today’s “information generation,” data centric security is not only a desired state, but a necessary one. Enterprises can no longer depend on permissions and information security based on users and user groups. Matrixed organizations are the norm in modern enterprises; and as such information security must be able to align with this.

Additionally, data and information is no longer just confined to the four walls of an enterprise. Social media, web based applications, and data interchange with partners up and down the supply chain means that the concept of “users” has a whole new meaning.

Concepts such as single sign on means that any given “user” may have different access levels based on its role at a given point in time. A simple example is where a “power” or “super” user of one application, may have minimal privileges on the human resources application – yet, it is the same “user” or person.

Also, in the modern matrixed organization, every employee may require different access based on the role that he or she is playing at a given point in time.

This means that broad based security paradigms are no longer effective.

Augmenting this lack of effectiveness is the idea that network security is no longer just about keeping “bad” people out, but also keeping “good” data and information within the organization. A presumption of poor network security is needed in today’s information era.

So how do we deal with this?

While application based security is certainly one way of combatting this complex problem, users would have to have individual logins and passwords for each application, making management impractical.

This is where data centric security comes into play. For any given data object (let’s take a database for argument’s sake), security is attached to that database. Data centric security is typically enforced through encryption or tokenization, but the growing needs for stricter data controls, de-identification and anonymization of data call for the broader use of data masking.

Data security controls provide protection in all forms, from a role within the organization (based on an organization chart), and can get as granular as the names of a specific sets of users, date specific parameters, economic factors or even how far along a particular process is within a supply chain.

Furthermore, attributes can be combined to enforce additional security.

Data centric security is therefore focused (as its moniker suggests) on data, and not on application or user directory structures. The importance of this concept can best be appreciated when following the life of a data object. For example, let us define a transaction as the data object for this argument. The data that was generated at point of sale may be available to store managers to review daily sales. Upon aggregation back at the district or regional office, the store managers may lose access to that specific data object, but may now gain access to aggregated data objects that are derived from multiple transactions.

In other words, once the transaction leaves the store, the local managers can no longer manipulate that data object, but they can see aggregated data based on analyses by the central office. As the data object traverses along its lifecycle, business analysts may be permitted to extract details such as demographics from the data object, and combining that data with warehouse data.

Ultimately, enterprise wide financial information can be generated and redistributed back to personnel to observe progress and success factors, all based on the initial data object (in this case the transaction), and based on role, time, superiority, and how far along the business process is; access to and editing of the data may be permitted or refused given multiple criteria.

Where to?

As more and more data gets integrated for Big Data historical and predictive analyses purposes, with data originating from multiple sources, external and internal organizations, security must be attributed to the data objects themselves. Traditional users and groups or application based security is good for keeping “bad” users out, but does not account for keeping “good” data in.

Data centric security does both – unauthorized users cannot access or edit the data object; while authorization is given based on specific factors and attributes that are appropriate as specific definitions meet the needs of business and regulatory governance.




This Insight is sponsored by Informatica. All opinions expressed are those of Neuralytix and its analysts.