Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

Hi Tony, yes, talking about Encryption at Rest!

Can you elaborate on what it is that is causing you trouble? There are no special or different requirements for the service account wrt Encryption at Rest, nor do security modes, or SSL certificates (or other items stored in the keystore), have anything to do with it.

I trust you are familiar with the documentation provide here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=security-tm1-server-data-encryption. Noticed however that the documentation hasn't been updated to incorporate the use of the REST API for managing Encryption at Rest (actions like EncryptDataModel, RotateDataModelKey, RotateDataEncryptionKey and DecryptDataModel).

Understand this Encryption at Rest stuff might look techy but overall, provided you have keys that can be used for this purpose, it shouldn't rocket science to get this going either ;-)

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

Hi Hubert, 

I don't want to hijack the original thread so maybe I'll create another one.

We do have a service ticket open with IBM about this and our challenges though. It's possible the issues we're facing are as a result of our IT standards and approaches and the limited number of IBM examples in the documentation. 

We did find this document (IBM source) which was more complete and had more examples than the documentation itself and which others may find useful if they haven't seen it. 

Hi Tony, yes, talking about Encryption at Rest!

Can you elaborate on what it is that is causing you trouble? There are no special or different requirements for the service account wrt Encryption at Rest, nor do security modes, or SSL certificates (or other items stored in the keystore), have anything to do with it.

I trust you are familiar with the documentation provide here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=security-tm1-server-data-encryption. Noticed however that the documentation hasn't been updated to incorporate the use of the REST API for managing Encryption at Rest (actions like EncryptDataModel, RotateDataModelKey, RotateDataEncryptionKey and DecryptDataModel).

Understand this Encryption at Rest stuff might look techy but overall, provided you have keys that can be used for this purpose, it shouldn't rocket science to get this going either ;-)

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

Hi Tony,

Good find, I know Andreas is thorough, let me know if you still need additional help (or send me the ticket number privately if you want me to take a peek)!

In the meanwhile, I've mentioned we are working on extending our Encryption at Rest support to allow for customers to bring their own keys (BYOK), once that's done we'll update documentation as well, and include REST API based samples (as those referenced in the docs you found earlier are no longer available in TM1 v12). 

Hi Hubert, 

I don't want to hijack the original thread so maybe I'll create another one.

We do have a service ticket open with IBM about this and our challenges though. It's possible the issues we're facing are as a result of our IT standards and approaches and the limited number of IBM examples in the documentation. 

We did find this document (IBM source) which was more complete and had more examples than the documentation itself and which others may find useful if they haven't seen it. 

Hi Tony, yes, talking about Encryption at Rest!

Can you elaborate on what it is that is causing you trouble? There are no special or different requirements for the service account wrt Encryption at Rest, nor do security modes, or SSL certificates (or other items stored in the keystore), have anything to do with it.

I trust you are familiar with the documentation provide here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=security-tm1-server-data-encryption. Noticed however that the documentation hasn't been updated to incorporate the use of the REST API for managing Encryption at Rest (actions like EncryptDataModel, RotateDataModelKey, RotateDataEncryptionKey and DecryptDataModel).

Understand this Encryption at Rest stuff might look techy but overall, provided you have keys that can be used for this purpose, it shouldn't rocket science to get this going either ;-)

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

Hi 

Sorry for the question, but is unclear to me - encryption at rest is available for planning analytics on cloud, but  -- it is not available -- for planning analytics as a service / PAaaS, right?

Thanks, regards,

Márcio

Hi Tony,

Good find, I know Andreas is thorough, let me know if you still need additional help (or send me the ticket number privately if you want me to take a peek)!

In the meanwhile, I've mentioned we are working on extending our Encryption at Rest support to allow for customers to bring their own keys (BYOK), once that's done we'll update documentation as well, and include REST API based samples (as those referenced in the docs you found earlier are no longer available in TM1 v12). 

Hi Hubert, 

I don't want to hijack the original thread so maybe I'll create another one.

We do have a service ticket open with IBM about this and our challenges though. It's possible the issues we're facing are as a result of our IT standards and approaches and the limited number of IBM examples in the documentation. 

We did find this document (IBM source) which was more complete and had more examples than the documentation itself and which others may find useful if they haven't seen it. 

Hi Tony, yes, talking about Encryption at Rest!

Can you elaborate on what it is that is causing you trouble? There are no special or different requirements for the service account wrt Encryption at Rest, nor do security modes, or SSL certificates (or other items stored in the keystore), have anything to do with it.

I trust you are familiar with the documentation provide here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=security-tm1-server-data-encryption. Noticed however that the documentation hasn't been updated to incorporate the use of the REST API for managing Encryption at Rest (actions like EncryptDataModel, RotateDataModelKey, RotateDataEncryptionKey and DecryptDataModel).

Understand this Encryption at Rest stuff might look techy but overall, provided you have keys that can be used for this purpose, it shouldn't rocket science to get this going either ;-)

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks

That is correct Márcio, but as mentioned earlier, we are extending encryption at rest (EAR) in TM1 v11 with BYOK (which will change the REST API endpoints related to EAR - the existing once were already deprecated in TM1 v12) and we'll subsequently, already started working on that too, bring back EAR, with BYOK support, in TM1 v12.  

Hi 

Sorry for the question, but is unclear to me - encryption at rest is available for planning analytics on cloud, but  -- it is not available -- for planning analytics as a service / PAaaS, right?

Thanks, regards,

Márcio

Hi Tony,

Good find, I know Andreas is thorough, let me know if you still need additional help (or send me the ticket number privately if you want me to take a peek)!

In the meanwhile, I've mentioned we are working on extending our Encryption at Rest support to allow for customers to bring their own keys (BYOK), once that's done we'll update documentation as well, and include REST API based samples (as those referenced in the docs you found earlier are no longer available in TM1 v12). 

Hi Hubert, 

I don't want to hijack the original thread so maybe I'll create another one.

We do have a service ticket open with IBM about this and our challenges though. It's possible the issues we're facing are as a result of our IT standards and approaches and the limited number of IBM examples in the documentation. 

We did find this document (IBM source) which was more complete and had more examples than the documentation itself and which others may find useful if they haven't seen it. 

Hi Tony, yes, talking about Encryption at Rest!

Can you elaborate on what it is that is causing you trouble? There are no special or different requirements for the service account wrt Encryption at Rest, nor do security modes, or SSL certificates (or other items stored in the keystore), have anything to do with it.

I trust you are familiar with the documentation provide here: https://www.ibm.com/docs/en/planning-analytics/2.1.0?topic=security-tm1-server-data-encryption. Noticed however that the documentation hasn't been updated to incorporate the use of the REST API for managing Encryption at Rest (actions like EncryptDataModel, RotateDataModelKey, RotateDataEncryptionKey and DecryptDataModel).

Understand this Encryption at Rest stuff might look techy but overall, provided you have keys that can be used for this purpose, it shouldn't rocket science to get this going either ;-)

We're also looking at this for our on-prem system - I presume you're talking about Encryption At Rest here?

Implementation is taking far longer than it feels (to me) like it should. The documentation is missing questions we have - things like around the service account rights to various folders. We've had different responses around what authentication mode it works with too. Also, watch out for expiring / replacing your SSL certificates which are stored in the same keystores - this is not at all clear to us how it should be handled.

And to keep our IT folks happy we've been trying to get documentation around the encryption standards in use - that one we're still waiting on which seems like it should be readily available.

If you can't already tell I'm coming from the business side of things, not the deep techy side.  As a long time user / owner it gives me the heebie-jeebies :) 

Hi all,

customer is considering using TM1 data encryption, driven by their security team.

I am looking for experience with real customer environments - how does it affect processes, performance etc. If we have compelling reasons not to implement it, they would be able to present those to their security team.

Second - it is not quite clear from the docs if they could use their own key - either for DEK or the PK. 

In summary - at this point we are looking for a way to avoid implementing it, but if there are any well working proven methods, we would appreciate sharing them.

Thanks