Provide control over who can use the SNODEID parameter
With SPOE, the SNODEID presents a security vulnerability. The SNODEID is hard-coded in the process in clear text. Anyone authorized to use CDZ and able to read the file where the SNODEID is coded, typically in the process library, can create and submit their own process and have access on the remote node granted to the SNODEID under SPOE. Knowing the SNODEID a malicious actor could:
- Retrieve the same production data that was sent by the local node to the remote node.
- Retrieve the same production data that was or will be sent by the remote node to the local node.
- Send bogus data from the local node to a production file on the remote node.
To mitigate this risk, we would like to have the capability to limit the use of the SNODEID by the user ID (ACID) submitting the process. A given ACID would need to be permissioned to use a particular SNODEID for a particular remote node. If the ACID were not correctly permissioned, then the process submit should fail. Ideally, the management of ACID permissions to use SNODEID's would be handled through the ESM (enterprise security manager) allowing proper separation of responsibilities between CD administrators and engineers and security administrators.
-
Guest
- Jun 1 2018
- Delivered
| What is your industry? | Financial Markets |
|
How will this idea be used?
If this idea is implemented we will restrict the use of most SNODEIDs to the ACIDs used by the production job scheduler. This will prevent unauthorized use of SNODEIDs as explained in the idea description. |
|
Related ideas
Thank you for your patience as we changed direction on this enhancement and worked on it. I'm pleased to share that more granular control over who can use the SNODEID parameter has been delivered in v6.2. I'd encourage you to pull down the latest code to take advantage of this and other enhancements that were made.
Sincerely,
Chris Sanders
Connect:Direct Product Manager
Attachments Open full size
Hi Chris,
status has changed to Not under consideration
Has there been some other enhancement that that would mitigate this security hole in CD/z?
Or is there some published guidance or best practices being provided to customers to avoid this security vulnerability?
Your previous comment to this RFE is as follows;
Thank you for opening this enhancement request with IBM. I have reviewed it with my developers and we are all in agreement that this would be a worthwhile enhancement to C:D for z/OS. We have accepted this as an Uncommitted Candidate and will look to add it to the offering roadmap moving forward.
SIncerly,
Chris Sanders
Connect:Direct Offering Manager
Charles Friedman, Vice President
Morgan Stanley | ENTERPRISE TECH & SERVICES
Phone: +1 212 276-2055
Charles.Friedman@morganstanley.com
Attachments Open full size
Thank you for opening this enhancement request with IBM. I have reviewed it with my developers and we are all in agreement that this would be a worthwhile enhancement to C:D for z/OS. We have accepted this as an Uncommitted Candidate and will look to add it to the offering roadmap moving forward.
SIncerly,
Chris Sanders
Connect:Direct Offering Manager
Attachments Open full size
I vote yes
Attachments Open full size