Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

Martin:

The problem with just replacing all PII with 'xxxxx', if this is for the purpose of masking production data for test use, is that the queries will not behave as they would with the real data because every identifier will have the same value of 'xxxxx'! You have to use a masking or obfuscation that leaves the distribution of values similar to production.

Art

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

In my experience, data should be stored unmasked as some "client" should retrieve original data and others masked data.

There should be a definition of masked columns: tablename + columname 

By default, if a column is defined as masked depending of the column type:

CHAR,VARCHAR,LVARCHAR -> should retrieve a basic hash E.G. MD5 of the content

DATE OR DATETIME should change aleatory the day of the date and change hour minute or second if timestamp

NUMERIC COLUMN (FLOAT, DECIMAL, INTEGER) should retrieve a numeric hash of the column using some internal algorithm so same original number always masks to same destination number.

If a column is defined as hashed we need to know who is able to see the original data. All other connections should mask data in the resultset.

So, here is the tricky think: implementation

1. You can add a list of users able to see original data without masking
   Cons of this model is that a dba can add himself to this list, retrieve "protected" data and then remove himself from the authorization list. In this "sensible" info no unauthorized users should be able to get unmasked data
2. You can define a password for clients to see unmasked data
   This password can ge defined at the database level and then only sessions sending proper password are able to see unmasked data (E.G. SET ENVIRONMENT mask_passwd "ABC123";)
   Then the installer of the application can set the database mask pasword and nobody (even the DBAs) are able to get unmasked data. Only at the application level, the client session is able to send the password and nobody knows it.

Possible issues: in first implementation, I would allow only CHAR columns to be masked/hashed. The best ways is to allow lauch proper sqls without knowing the details, that is the reason I propose using a hashing algorith, so you can select how many names have your patients without knowing the real name.
Cons of hashing vs masking is that some column sizes should change for example MD5 hashing of a CHAR(15) column, returns a CHAR(32) string

This can be a mess, so maybe Informix should allow to mask/hash only columns larger than 32 or cut the hashing if column size is smaller.

E.G.

original CHAR(15) with content "ABCD" will return cb08ca4a7bb5f96

original CHAR(32) with content "ABCD" will return cb08ca4a7bb5f9683c19133a84872ca7

That's my two cents.

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika 

I'm not clear at which level such 'masking' is desired:  should data in storage be altered, physically/permanently (which would make it unusable for e.g. WHERE clauses, indices, etc.), or should it only be obfuscated when actually delivered to a client, i.e. at the point where it's being put onto the wire, or anything in between?  Should e.g. stored procedures also not be able to 'see' the real data? And probably more aspects ...

Dear All,

Is "data masking" feature  available in INFORMIX ? If it is not available pl. let us know the similar features in INFORMIX ? 

Thanks !

Best Regards,

Indika