Does anyone use HCL Connections on Premise ?
If so, please let me know ?
As we love the solution, but are struggling to continue with getting support for the on premise version.
kind regards
Ian
Of course. Otherwise this forum wouldn't even exist :-)
I have multiple customers with Connections on premise that I support.
What problem are you facing?
We use it. And many of our customers use it.
Support was never an issue. With small exceptions ("papercuts").
Development is also going along promising.
Connections 8 will refresh the look, which will make a lot of people happy.
Great news, as we currently have a support ticket open, due to multiple security vulnerabilities, don't know if you have the same issues, or not ? As currently the HCL Ticket relates to Javascript injection (DOM based) which relates to CWE's 94, 95, 116 which is HIGH Vulnerability, in addition a second security vulnerability which is due to a Cross site scripting (DOM based) which relates to CWE's 79, 80, 116, 159 which is also HIGH.
We have been struggling to get any L3 response so far in resolving the issue, as this is to do with the Websphere IHS Proxy element i guess which resides on our DMZ, but either way, we are confused if this is such a High level of security issue, why this has yet to be resolved.
In addition which also have outstanding is the Linux OrientMe server has also security - Critical security issues to do with the NFS shares.
I am struggling to understand how other on Premise users are able to cope with these issues, as these security issues have meant we have to shut down our OientMe server since last year, due to the seriousness of the security issue, we are still awaiting a fix.
Are you aware of the above and if so what have you done to resolve ?
Ian
There are certain rules you can set in IHS to prevent css attacks, but I suppose you have specific examples for specific applications that you refer to and I can't comment on that as I obviously can't see your support ticket.
With OrientMe and NFS, I assume you refer to no_root_squash which the NFS share needs and which is frowned upon from a security viewpoint. The reason this is frowned upon, is because no_root_squash could potentially allow to change any file on the NFS share. However, that is only a problem if users would be able to influence what is written by the Component Pack components, which is not the case. Users aren't able to directly write to this NFS share. It's only used by the pods. If then still you feel no_root_squash can not be allowed on a shared NFS server, then you can choose to create a designated NFS server for the component pack (I actually did this at one customer).
I don't want to be blunt, but it sounds a bit like you have a security department that doesn't understand the application and simply based on the used software and some configuration parameters has decided that something is a risk as they're not able to understand if it's an actual risk in the specific use case. What potential real-life scenario risks have they identified?
The security vulnerabilities, are being generated via a solution called Tenable.IO, in addition the security issues here have not been patched either by IBM who own websphere or by HCL who are working in conjunction with IBM to resolve we assume ? The issue here is more to do with weakness within the software in relation to not as I understand a configuration issue, but a software security weakness, in addition we have had an additional 3rd party also perform PEN testing which has identified the same security threats that obviously we would need to resolve.
In take on board your response in relation to the NFS, but in modern networks, you would never allow this NFS to be configured like this, which you do also appreciate like myself, but the fact is, that when being audited and performing security testing that the NFS issue is clearly not about a false positive, but also about security compliance. I appreciate you being blunt, but are finding it frustrating that HCL are taking weeks to come back with no answer in relation to the major HIGH issues in relation to the IHS / Proxy / Websphere, we are paying for support which would expect a response, or are you saying that your environment does not have these security issues, i.e. are you not exposing connections externally ?
We love the product we love HCL, but we need these issues to be addressed properly and fixed, just very interested in how everyone else is dealing with security issues, which we would normally have fixes, we have already applied some fixes we have been released, but still awaiting for further research.
My concern was originally, was assuming there are not that many customers using on premise, but obviously there are, thus we are confused we these issues have not been addressed and resolved before now.
I am sure you share the same passion about the HCL solutions, as we do, if there is anything we can pass onto to HCL to assist them in relation to the Cross Scripting and Javascript injection all to do with DOM, these please let me know.
Just to be clear, I understand your frustration in the slow response on tickets. I have seen tickets which need Development effort stay open for a very long time. I also recognise that while WebSphere and IHS development are still at IBM, it has become even more difficult to solve these issues.
With penetration testing, using an application like you use, has to be step 1. Step 2 is to identify whether the found vulnerability is actually a problem in the application or only a hypothetical problem. You need to have good knowledge of the application for that, so this can only be done by people who actually know the product and how exactly it's used in the organisation. For example, I'm sure Facebook has lots of security vulnerabilities, but is this relevant in the context of Facebook? So in this step it's necessary to identify real-world risks and present this to management. In step 3 it's up to management to sign off on the risks or not.
I've maintained Connections environments for large corporate customers (banks, insurance companies). We always had to go through this type of process. And yes, we always had to raise tickets for found vulnerabilities. But after we went through the process, risks were signed off and that was it. In most organisations, Connections was only used internally. In some externally, where external users had to use a VPN first to gain access to a specific network segment, but I also have customers with full external access. In most companies, there are clear rules about the type of content you're allowed to place on Connections, which, for example, in banks is a normal thing. Customer details are only to be placed on systems with the highest security rating, so not on Connections.
Hi.
Yes, of course, for us, for our own internal use, and deployed in a few customers as well.
Sincerely,
Elvis.
Yes, 7.0
Connections has bin on-prem since v4.5.. Now running v7 on Docker. It runs well.