IBM Security Z Security

I received a request to include the source IP in the information sent to QRadar for all of our active alerts. I opened a ticket with level 2 who suggested I pose the question here. Given the information provided in the link below, along with the fact that we have users that either log directly into an lpar or use VTAM/Switch to then select from a list of lpars and CICS regions, is it possible to provide 100% accuracy on the source IP of the user? If so, are we looking at application, SMF collection and z/Secure customizations?

https://www.ibm.com/support/pages/smf-can-remote-ip-address-be-associated-user-id


Thanks,
Mike

z/OS is one of the (very) few mainline operating systems where the majority of privileged user activity cannot be attributed to a source IP address.  This is due to said privileged activity being conducted through 3270 emulation, usage of a network host to transfer TCPIP (TN3270) sessions into VTAM, and session switching applications in z/OS.  This results in an SMF record containing an IP address + LU name in the network host, losing the LU name in the session switcher (sometimes without even an SMF record), and the actual privileged work running (on the production system) with an LU name that originates from another LPAR (sometimes even another domain).

When you serve each TN3270 connection on the application/production LPAR and remove the session switching application from the board, you might be able to correlate the LU name in TN3270 session initiation (119 subtype 20) with the TERMINAL name in SMF 30 and 80.  But this scheme can be easily thwarted by hopping from one TSO session to another using the TELNET command on z/OS.  That said, removing session switchers and serving concurrent TN3270 sessions (with SSL) from the workstation brings accountability of source IP address one step closer.

Could zSecure be helpful in this game?  Right now, it offers a SRCIP field in many SMF records, using the TERMINAL field as the source of IPv4 address when possible.  You can easily run a CARLa query to see how far this gets you:

newlist type=smf
  select exists(srcip) exists(userid) userid<>(ftp*,tn3270,net,tcpip)
  summary type * subtype * jobname * userid * srcip 

------------------------------
Rob van Hoboken
------------------------------

Rob,

Thanks for the response.  I ran the CARLa code suggested and it returned only the internal IP addresses and not the source IP I was looking for which is what I expected based on your explanation.  Unfortunately, the zSecure canned alerts show srcip as a field that is to be included in the payload sent to QRadar, but that is not populating at all.  Specifically looking at alert 1102:

select event=racinit(0,12) descriptor=(success,warning),      
       likelist=recent,                                       
       user=(,                                                
        IBMUSER,                                              
       )                                                      
option header=rfc5424                                         
sortlist,                                                     
 recno(nd) '<117>' | _hdr_datetime _hdr_hostname 'C2P1102'    
 'ÝC2P1102',                                                  
 userid('whoUSERID'),                                         
 user:name('whoNAME'),                                        
 'whatACTION="Logon_Emergency"'(norepl),                      
 desc('whatDESC',0,explode,hor),                              
 jobname('whatJOBNAME'),                                      
 jobid('whatJOBID'),                                          
 system('whereSYSTEM'),                                       
 terminal('fromWhereTERMINAL'),                               
 terminal('fromWhereSRCIP',hextoip),                          
 utoken_source_userid('fromWhereUSER'),                       
 utoken_source_system('fromWhereSYSTEM'),                     
 | '¨',                                                       
 'Alert: Emergency user' user(0,noprefix,noquote) 'logged on',
 '- Successful logon or job submit with a userid meant for',  

Without intelligent processing of SMF 118/119, which zSecure 2.4 didn't provide, there is no way to find the IP address for SMF record types that describe user activity (such as SMF 30 and 80).  The code you show attempts to display an IPv4 address by:

• checking if the TERMINAL field is a true hexadecimal value, i.e. contains only 0-9 and A-F, and
• formatting it as 4 octets when it is, preceded by fromWhereSRCIP=

This is the case for linemode telnet sessions that bypass VTAM, and FTP sessions.  An IP address of 10.11.12.254 would result in a TERMINAL value of 0A0B0CFE.  3270 telnet sessions go through VTAM, so an LU name is assigned from the pool instead of the IP address.  I suppose your alerts show an LU name, right?

If I were to write the alert skeleton again, based on zSecure 2.5, the 2 lines with TERMINAL would look like

terminal('fromWhereTERMINAL'),
srcip('fromWhereSRCIP'),

But that still would not show a SRCIP value for TN3270 sessions through VTAM, unless zSecure internally uses SMF 119 subtype 20 to keep track of IP address vs. LU name connections.  Oh well.  Note, TERMINAL does not provide support for IPv6.

------------------------------
Rob van Hoboken
------------------------------