Found this on wikipedia

[Ultramundane]

This post has been removed by the EDITOR at the request of IBM. Please DO not attempt to repost this as it will cause your immediate removal from the site!

Thank you for your understanding in Advance.

Editor,

Dennis James

[ray.wurlod]

No-one ever claimed that they used strong encryption. I'm sure that if you search DSXchange you will find others who have posted how easy it is to break. I think it was only a mechanism by Ascential marketing to be able to check the "we have encrypted parameters" check box.

[vmcburney]

So you are from Michigan, what a coincidence, the IP address of the anonymous person who keeps adding that entry onto Wikipedia is 204.74.160.15 and according to an IP Locator that's from Grand Rapids Michigan. I hope you are the person who keeps adding to Wikipedia because this is a far more appropriate place to raise it as an issue. It doesn't belong on Wikipedia as it's FUD but it's a good topic for a discussion here.

The only type of encryption you can rely on is 104 bit or better encryption with a changing key and you are unlikely to find this in the parameter manager of an ETL tool. DataStage parameter encryption isn't crack proof but then again it doesn't need to be. Anyone who has a DataStage Server login and password has access to most of the data that DataStage processes thanks to access to files, dataset, peeks, view data etc. You secure the server not the job parameters.

Parameter encryption is there to make it difficult to see certain values by accident or by curiousity. If you want to make it impossible to see values you need a third party encryption product.

You will find you can also crack the encryption or password protection on tools like MS Access, zip files and office documents if you try hard enough.

[Ultramundane]

So you are from Michigan, what a coincidence, the IP address of the anonymous person who keeps adding that entry onto Wikipedia is 204.74.160.15 and according to an IP Locator that's from Grand Rapids Michigan. I hope you are the person who keeps adding to Wikipedia because this is a far more appropriate place to raise it as an issue. It doesn't belong on Wikipedia as it's FUD but it's a good topic for a discussion here.

The only type of encryption you can rely on is 104 bit or better encryption with a changing key and you are unlikely to find this in the parameter manager of an ETL tool. DataStage parameter encryption isn't crack proof but then again it doesn't need to be. Anyone who has a DataStage Server login and password has access to most of the data that DataStage processes thanks to access to files, dataset, peeks, view data etc. You secure the server not the job parameters.

Parameter encryption is there to make it difficult to see certain values by accident or by curiousity. If you want to make it impossible to see values you need a third party encryption product.

You will find you can also crack the encryption or password protection on tools like MS Access, zip files and office documents if you try hard enough.

Don't know about the Michigan coincidence, but it is poor security in the product and I believe that it needs to be fixed. This poor security is in direct violation of all security standards that I aware of at my company. I believe that this product or at least the use of this product by more then one person violates PCI, SOX, and HIPPA.

[vmcburney]

It also violates NATO, KAOS and BATMAN. Look, access to DataStage and DataStage login is very secure - in fact you can just use the LDAP or operating system security and that makes the server secure.

SOX - you are barking up the wrong tree. SOX is for financial reporting and the accuracy and completeness of information. Since IBM incorporated QualityStage into DataStage they have a better tool for SOX compliance than most vendors.

HIPAA - has a requirement for PHI (protected health information), I would love to hear from Kim Duke on how they protect health records when they process them with DataStage. There are a lot of health organisations using DataStage.

PCI compliance - the protection of credit card information - in most cases the card numbers will be encrypted in the database and having DataStage logins and passwords to that database will not help you read card PANs (personal access numbers).

If they are storing PANs in a readable format, which is ill advised but allowed under PCI, then extra protection of that database is required and you can bet your bottom dollar they wont be letting people access that database through ODBC and client layers with ETL tools. In all likelyhood they will encrypt the PANs on the way out of the database and deliver them to the ETL tool in files.

PCI Compliance requires the encryption of PANs with a key of at least 104 bits that changes at least once every twelve months. You will not find this in any data integration or BI tool. You will find it in POS and banking software where the PAN gets captured or in third party software that DataStage can integrate with. Even if DataStage had a better encryption algorithm it is unlikely to be PCI compliant due to the key management requirement. It is overkill for an ETL tool. You leave that up to third party products.

For a PCI compliant DataStage environment you can have mocked up data in your development and test environments, possibly with the help of the Softech software, and a locked down production environment that is only accessible to administration and support. You encrypt all PANs before they land in files or datasets.

You do raise a good point that if DataStage is being used to connect to a database with unencrypted PANs they should consider a third party product for encrypting and unencrypting the database passwords and/or data that supports encryption key management.

[Ultramundane]

It also violates NATO, KAOS and BATMAN. Look, access to DataStage and DataStage login is very secure - in fact you can just use the LDAP or operating system security and that makes the server secure. ...

Datastage itself might be secure, but it gives out easy access to the systems it accesses. Unless the one developer is also the admin for the product, it violates every security guideline which I am aware. That is, if it accesses any sources or targets which require that credentials be specified and said such data is stored on one of those systems.

[ray.wurlod]

Ok, so stop using it and "do it yourself".

[Ultramundane]

Ok, so stop using it and "do it yourself".

Ray,

I am afraid the world doesn't work that way or at least my view of the world. I believe that we all rely on others whether we like it or not. Anyways, who is to say some other solution won't have pitfalls. I see no merit in your response. Also, I don't want to stop using it, I just want it be more secure and complaint with security regulations. Is that too much to ask? This has been known about for over 3 years. I am at a loss as to why it still hasn't been addressed.

[ray.wurlod]

Maybe because no-one else cares enough to harrass the vendor about it, mainly for the reasons in Vincent's post. As a sometime contractor, I know that I sign some fairly heavy duty non-disclosure agreements, and am happy to do so, thus even that I can access my clients' data is not a problem. What's in the database stays in the database.

[Ultramundane]

Maybe because no-one else cares enough to harrass the vendor about it, mainly for the reasons in Vincent's post. As a sometime contractor, I know that I sign some fairly heavy duty non-disclosure agr ...

I don't see anything in Vincent's post that is being related to this issue. I do agree that it seems that there are few who care enough to harrass the vendor as much as I to get things fixed.

[Daddy Doma]

Ultramundane,

What has been the response from IBM when you raise this issue with them?

[Ultramundane]

Ultramundane,

What has been the response from IBM when you raise this issue with them?

They got really really mad at me for pointing this flaw out. I was able to get them to fix several other security flaws. They said to make sure that you only give access to your very trusted developers. They also tried to say that I was trying to make sure that the product failed at my company. When in fact, I was trying to make sure that the product worked flawlessly. There is a big difference between the two that IBM could not understand. Next, they said I was being vulgar so they refused to work with me anymore. Well, it really hurt me that they said I wanted their product to fail. But, I refused to cave in, but instead to keep giving it my all in whatever limited box they try to enclose me. Anyways, we appointed another individual to handle the cases. He had to work with me and Ascential on the cases as a mediator.

After working with Ascential support for about a year to address many of the bugs we found and trying to get this issue fixed, he had a breakdown and refused to work the Ascential support folks anymore. He couldn't take them anymore. So, we had to find someone else to fit into this role.

To our dismay, the new individual was not able to get any better results working the Ascential developers despite his trying to sugar coat everything. They basically refused to fix issues we find unless we get our director and CIO to discuss the issues with IBM. Our CIO has done this as well and we still have not been able to get a resolution for this item. We asked that passwords NOT be output in any logs at any time with any option. That the passwords, should always be stars in the logs. We also asked that the export facility not export passwords unless done so in a extra encrypted binary mode. Ascential/IBM agreed that this would be fixed. This was about two years ago. So, I think that has been their response with us for some reason. Just keep ignoring them and the issue will go away.

We are not a small company. In fact, we have over 50 developers and many many projects and several thousand jobs. We add about 100 jobs to the system per week. We also handle data which is sensitive for SOX, PCI, and HIPPA. Thus, security is very important to us. We had also passed that information along to Ascential/IBM and they very reluctantly agreed that it was a problem in the product and that it needed to be fixed, but we have been unable to get them to take any action to fix the issue.

This issue also presented to Keith Kole at IBM who is apparently a product lead of some sort. He said that they would make it a top priority to fix the issue. Again, this was over two years ago. So, no action by IBM, just attempts at some make us feel goods and that they are actively doing something for over three years now to fix the issue.

[Ultramundane]

Ultramundane,

What has been the response from IBM when you raise this issue with them?

They got really really mad at me for pointing this flaw out. I was able to get them to fix several other security flaws. They said to make sure that you only give access to your very trusted developers. They also tried to say that I was trying to make sure that the product failed at my company. When in fact, I was trying to make sure that the product worked flawlessly. There is a big difference between the two that IBM could not understand. Next, they said I was being vulgar so they refused to work with me anymore. Well, it really hurt me that they said I wanted their product to fail. But, I refused to cave in, but instead to keep giving it my all in whatever limited box they try to enclose me. Anyways, we appointed another individual to handle the cases. He had to work with me and Ascential on the cases as a mediator.

After working with Ascential support for about a year to address many of the bugs we found and trying to get this issue fixed, he had a breakdown and refused to work the Ascential support folks anymore. He couldn't take them anymore. So, we had to find someone else to fit into this role.

To our dismay, the new individual was not able to get any better results working the Ascential developers despite his trying to sugar coat everything. They basically refused to fix issues we find unless we get our director and CIO to discuss the issues with IBM. Our CIO has done this as well and we still have not been able to get a resolution for this item. We asked that passwords NOT be output in any logs at any time with any option. That the passwords, should always be stars in the logs. We also asked that the export facility not export passwords unless done so in a extra encrypted binary mode. Ascential/IBM agreed that this would be fixed. This was about two years ago. So, I think that has been their response with us for some reason. Just keep ignoring them and the issue will go away.

We are not a small company. In fact, we have over 50 developers and many many projects and several thousand jobs. We are currently adding about 100 jobs to the system per week. We also handle data which is sensitive for SOX, PCI, and HIPPA. Thus, security is very important to us. We had also passed that information along to Ascential/IBM and they very reluctantly agreed that it was a problem in the product and that it needed to be fixed, but we have been unable to get them to take any action to fix the issue.

This issue was also presented to Keith Kole at IBM who is apparently a product lead of some sort. He said that they would make it a top priority to fix the issue. Again, this was over two years ago. So, no action by IBM, just attempts at some make us feel goods and that they are actively doing something for over three years now to fix the issue.

[vmcburney]

We asked that passwords NOT be output in any logs at any time with any option. That the passwords, should always be stars in the logs. We also asked that the export facility not export passwords unless done so in a extra encrypted binary mode.

Those are all good suggestions. I haven't heard anything about it but it would be great if that made it into a future release. Did they ever implement encrypted values as stars in the log message? I seem to recall it changing for version 8.

[Ultramundane]

We asked that passwords NOT be output in any logs at any time with any option. That the passwords, should always be stars in the logs. We also asked that the export facility no ...

Unfortunately, I cannot see your entire post.

Some of the issues I noted:
If you go into director and click on job you can see the encrypted password.
If you export a job using XML, you can see the encrypted password.
Many of the environment variables you can set for a job will output the encrypted password to the log.
There are a few undocumented environment variables that when added to a project and job will output the unencrypted password to the log.
If you can access a job, you can open it, delete all contents, put down an external source stage and use the echo command to display the unencrypted password.
If you run a ps loop on the OS you can often time catch datastage passing passwords unencrypted to other components.
These are not all fixed by merely not including any actual passwords in the jobs, because you can get at the last encrypted value that was passed into the job via the log.
Nor, are these all issues fixed by limiting a single person to a single project. You still have the admins and operators.

Without the bugs and flaws we have found, I think this is a very good product with a very pretty interface.