Never give up hope: Automat(able) acquisition of SMP/E SECINT information arrives

One thing I love about working in z/OS Development is that we get to deliver functions that we know folks will need and will want to use repeatedly!  

For longer than I want to mention (through the span of at least three IBM customer requirement control systems), we've been struggling with a certain customer requirement.  This requirement had become a "bane of our existence", at least for sysprogs who have to maintain the z/OS stack.  It was very difficult for IBM to deliver on, being constantly surfaced as a customer problem, and critically needed to help customers easier keep the security/integrity of their z/OS systems.  It has continually been one of the top requirements in all of z/OS for decades: how could we deliver the SMP/E SECINT (++ASSIGNs and HOLDDATA) in an automated way, when the information itself is IBM Confidential?

Well, hope springs eternal, and now we have that solution!  

In a nutshell, here's the solution:  when an SMP/E RECEIVE ORDER request is sent to the IBM server, *and* that user is permitted to the IBM Z and LinuxOne Security Portal (Security Portal), *then* the contents of that order will contain the SMP/E ++ASSIGN statements for the SECINT SOURCEID, and the HOLDDATA.  If the user is *not* permitted to the Security Portal, then everything is the same as it is today (meaning:  no SMP/E security/integrity information).  Best of all:  there is not z/OS support necessary to use this capability.  It all "just works" with what you have today!  

How do we know if you are permitted to the Security Portal?  By the Shopz certificate that you provide to the IBM server which you use for SMP/E RECEIVE ORDER processing, of course!

It is important to note on your SMP/E RECEIVE ORDER CONTENT request, what you should expect to see:

  • CONTENT(HOLDATA): provides you only the Enhanced HOLDDATA, just as before. This HOLDDATA will always contain the HIPER, PE, and FIXCAT information.  However, what is new in this solution: if the certificate you use is permitted to the Security Portal, then you will *also* receive the HOLDDATA for security/integrity information.  Here's a made-up example of what that additional information might look like:   

++ HOLD    (HFMID01) FMID(HFMID01) REASON(AAPAR01)  
 ERROR DATE(25289) COMMENT(SMRTDATA(FIX(UIPTF01)                  
 SYMP(B1.1,T1.1) CHGDT(251016))) CLASS(SECINT).
  • CONTENT for PTFs or any other selection:  provides you the PTFs, ++ASSIGN, and HOLDDATA, just as before.  However, what is new in this solution:  if the certificate you use is permitted to the Security Portal, then you will *also* receive the ++ASSIGNs for SOURCEID SECINT.  Here's a made-up example of what that additional information might look like:         
    
    ++ ASSIGN  SOURCEID(SECINT) TO(UIPTF01).

 So what else is important to know?  Although the Security Portal does contain the two SMP/E files for ++ASSIGN and HOLDDATA, the Security Portal also contains other critical information associated with security and integrity on the z/OS stack which is not SMP/E-consumable. This means the Security Portal still must be used to review the other related materials.  The ++ASSIGN and HOLDATA SMP/E-consumable information, however, does *not* need to be reviewed if you have acquired it from your SMP/E RECEIVE ORDER processing, since it is identical. 

One last critical reminder: anyone permitted to the Security Portal is responsible in their enterprise for proper control of IBM Confidential information. The acquisition of this SMP/E security/integrity information has been made much easier, and just as if you had acquired it directly from the Security Portal, the control of that information remains the same within your enterprise.  

Please do read this Support Document, which describes this long awaited solution and some Frequently Asked Questions:   https://www.ibm.com/support/pages/node/7248201

As a recap, here the solution which is now available:




Comments