Found this on wikipedia
Moderators: chulett, rschirm, roy
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
Found this on wikipedia
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
Thank you for your understanding in Advance.
Editor,
Dennis James
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
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.
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.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
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 wrote: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.
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
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.
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.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
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.vmcburney wrote: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. ...
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
Ray,ray.wurlod wrote:Ok, so stop using it and "do it yourself".
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.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
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.ray.wurlod wrote: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 ...
-
- Premium Member
- Posts: 62
- Joined: Tue Jun 14, 2005 7:17 pm
- Location: Australia
- Contact:
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
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.Daddy Doma wrote:Ultramundane,
What has been the response from IBM when you raise this issue with them?
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.
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
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.Daddy Doma wrote:Ultramundane,
What has been the response from IBM when you raise this issue with them?
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.
-
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
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 wrote: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.
Certus Solutions
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
Blog: Tooling Around in the InfoSphere
Twitter: @vmcburney
LinkedIn:Vincent McBurney LinkedIn
-
- Participant
- Posts: 407
- Joined: Mon Jun 27, 2005 8:54 am
- Location: Walker, Michigan
- Contact:
Unfortunately, I cannot see your entire post.vmcburney wrote:Ultramundane wrote: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 ...
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.