Password Vault support for outgoing Connect Direct for Windows transfers

Hello James,

While I agree that the proposed solution could limit the amount of time the password would be stored locally on the servers (cddef.bin), we believe it is more of a stop gap measure, rather than a long term solution:

1. Since multiple file transmissions could be active at the same time, each outbound file transmission would need to have its own temporary copy of the cddef.bin, built from the password vault. Otherwise, concurrent file transmission processes rebuilding and reading a common cddef.bin could be problematic (e.g. process 1 is reading the cddef.bin file while process 2 is rebuilding it). As such, part of the proposed solution would need to come up with a unique way of naming, creating, reading and deleting cddef.bin files. Certainly not difficult, but something that would need implemented by clients.

2. My understanding is that connect:direct processing is asynchronous. If that assumption is correct, the time between a file transmission request and its processing could be seconds, minutes or even hours. As such, the solution should fetch the password from the password vault just before it is needed (as I believe the password exit does), rather than fetching the password at the time of the request and hoping the password does not change before processing of the file transmission begins. Our policy is to recycle passwords daily, so this is a key point. With the proposed solution, potentially, a file transmission request script could fetch the password from the vault, build a temporary cddef.bin, but by the time the file transmission begins processing, the password may have changed, causing an authentication error and a failed file transmission. While this could be solved by ensuring password changes occur at a time when no transmissions are active, there would always be some chance of timing issues due to password changes.

3. With the proposed solution, clients would also need to design their own solution to securely store credentials to the password vault, whereas the password exit does this today with no additional work

4. We continue to believe one solution centered on the password exit is the way to go, no matter if a file transmission is inbound, outbound and method of initiation (CLI, CD File Agent, CD Requester). This minimizes configuration work for clients and provides a consistent approach and simplifies ongoing support.

Hello Henry,

Can you please have a look at my above comments and revert.

Thanks,

James

Thank you Henry for your feedback. We didnt emphasise that a password is only temporarily stored on disk. We envision the steps in a customer’s script being:

1. Pull a password from a password vault into an LCU file

2. Execute the Windows CLI

3. Delete the LCU file

The password is only on disk during the execution of the Windows CLI.

Regards,

James

If I am understanding the proposed solution correctly, it unfortunately does not satisfy all requirements from a PNC perspective. With the proposed solution, the credentials would still be stored and/or accessed locally on the server running connect:direct. Yes, the credentials in cddef.bin are encrypted, but that is current functionality. So, we see just two minor benefits with the proposed solution:

1. The user running LCU would no longer need to access a centralized password vault such as CyberArk to fetch the password in order to enter it into the LCU utility.

2. The password would not need to be exposed to the person running the LCU utility.

Our recommendation is to fetch the password using the password exit in real time, when outbound transmissions are initiated either by the Connect:Direct CLI or Connect:Direct File Agent. Essentially, we'd like to use the existing Proxy/Local Authority/Password exit process for these type of outbound transmissions. This would have the following benefits:

1. Static credentials would not longer be stored locally on the server (cddef.bin), reducing risk that with the proper tools, someone with knowledge of the encryption method could decrypt the credentials

2. Passwords could be changed / cycled by a centralized password vault such as CyberArk as often as required by company policy, it could be daily.

3. Same dynamic password solution for all transmissions, no matter how initiated and direction.

Hello team,

Attached the detailed solution draft for the RFE. We would be happy to provide a walk through if you need. Please let me know your thoughts.

Thanks,

James

Dear IBM,
Please kindly progress this enhancement  to delivery - please include the Password Exit feature in the CD Windows CLI  in a future product release of Connect Direct.

The rapidly changing security landscape in the banking and finance sector requires all passwords to be stored securely in a Password Vault. Inside the Vault, passwords can be reset without impacting file transfer batches, because the password gets fetched in real time. This approach improves the security posture of the file transfer process.  By adding the Password Exit functionality to the CD Windows CLI, it enables outbound file transfers to operate at the same level as inbound / proxy users.

The expectation is that adding password exit to CD Windows CLI will be slightly easier this time around because it has been built once before for proxy users. 
I am working in a major ('big four') Australian bank that has audit and compliance requirements for password security.

Hello John,

There are no programmatic APIs for client connection utility. The purpose of the client connection utility is to enable current Windows users to configure connection defaults in their registry. Providing password exit support for the utility is not aligned with the broader market needs and product trajectory. We genuinely see the need to add the password exit support in CD Windows CLI. We have got a similar RFE request from other banking customer , if the idea resonates with your use case, please feel free to upvote/ comment against the RFE. This will help us to prioritize the RFE as the reach is higher.

Thanks,

James

The Password Exit feature covers proxy users can the functionality be made available for client connection users?

Thank you for taking the time to provide your ideas to IBM. We appreciate your willingness to share details about your experience and your recommendations.

After our initial review, We would like to further discuss this enhancement with you. I have included some key members from our development team for our bi-weekly call coming Monday so that we can discuss this quickly.

Look forward to connect with you. Thanks and Appreciate your patience.

Thanks,

Product Management