IBM Security Z Security

Hi Lennie

As with all zSecure Alert functions, messages are generated using CARLa functions (sortlist or summary) and CARLa fields.  The TSO command generation is no different, the code you quote generates a

sortlist 'ALU' USER(0) 'REVOKE'

or maybe, if this is a threshold action with the value set to 200:

summary 'ALU' USER(0) 'REVOKE' count(>=200)

Since this alert is SMF based, USER(0) refers to the user ID that caused the SMF record to be generated.  Say, user BADGUY has caused 200 ACCESS violations, the generated command would be 

ALU BADGUY REVOKE

Hi Lennie,

All the CARLa field values are taken from the selected record (either report type level record or summary level).

Looking at C2PS1115, the selection is in this section:
)SEL &C2PESECP = RACF                      
 s type=(80,83) (event=access(failure))    
)ENDSEL                                    

and in the action command section we use a threshold via SUMMARY:

)CM Action command                                                      
)IM C2PSACTX                                                            
)SEL &C2PERCTP = MAIL                                                   
)SEL &C2PESECP = RACF                                                   
 sortlist date(nd) time(5) intent access class,           /*EZ0604008*/ 
  resource(0,wrap)                                        /*EZ0604008*/ 
)ENDSEL                                                                 
)SEL &C2PESECP = ACF2                                                   
 sortlist date(nd) time(5) acf2_access class,                           
  resource(0,wrap)                                                      
)ENDSEL                                                                 
)ENDSEL                                                                 
 summary  _cnt_historyVio1115(nd,<&C2PENVIO),                           
          _cnt_totalVio1115(nd,>=&C2PENVIO),                            
 date(nd) system(nd),                                                   

So when we summarize to "too many" violations for a particular USER, we issue an ALU for that user.
And the basic USER values are taken from the SMF violation records.

Regards,

Jeroen

Rob and Jeroen,

Thank you for your replies.

If I have understood these correctly, the parameters that are available for use in the command that I might wish to execute from any given alert will include all those fields that are available in the SMF record(s) that generated the alert. So I should be able to use all or each of those fields in a command I issue. 

Is that correct?
Lennie

Yes, you may use the fields that are available in the record (SMF, SYSLOG) that is used in the alert.

Some caveats:

The input field in SE.A.A is not very long, and in skeleton C2PSACTS, all fields and literals for the command have to fit in one line.
You can write a command section in your own installation skeleton, based on the code that ships in C2PSACTS.

Commands will execute run the user ID of the C2POLICE address space.  The default user ID, C2PSUSER, is not provisioned with system special.

FIB commands such as SUBMIT will not run from zSecure.

Rob,
Thanks for that extra detail.
I have been trying to get this process to execute an EXEC command. If I can simply pass the required parameters to a REXX routine I can do lost of other things that I can easily control. However,

1. I cannot get this to work. I seem to get nothing done at all and no message anywhere. I can get the command written to C2RCMD, but cannot get it executed. You say the FIB commands are not supported (SUBMIT, STATUS, OUTPUT, CANCEL) but not why. Are there others that are unsupported? Why would EXEC not work?
2. I find that the EXEC command with the parameters I pass, end up in CKXLOG. This was a surprise. Maybe Alert is using a command execution function which invokes the CKXLOG function. Can you elaborate?

Lennie

When you look at the CARLa commands generated from a standard alert that has a TSO action specified, you will see a NEWLIST with the CMD option specified.  This is the internal TSO command execution function, documented here.

You are not supposed to write to C2RCMD or any other dd name.

I do not know of docs about the link to CKXLOG, nor is there doc about EXEC or running a Rexx.  See the link above.

You may be able to experiment with your command generation code, using a simple batch job:

// EXEC PGM=CKRCARLX
//STEPLIB  DD DISP=SHR,DSN=SYS1.SCKRLOAD
//SYSPRINT DD SYSOUT=*
//SYSIN    DD *
newlist type=system outlim=1 cmd
  sortlist 'LU'

Program name CKRCARLX is the APF version of CKRCARLA as used within C2POLICE.  It requires a permit on an XFACILIT resource.  Swapping out the program name to CKRCARLA presents other limitations on the TSO commands supported.  When you get this job doing what you need, you could swap the newlist type to SMF, add an ALLOC TYPE=SMF ACTIVE and try to add SMF field names to the SORTLIST command.

Rob, that last reply was very helpful in understanding what is going on. It shows me the it is the CMD option on a NEWLIST statement that causes CKRCARLA or CKRCARLX to issue commands and what command are available in each environment. I know IKJTSOEV can be used to execute non-APF TSO commands and I wondered if this was being used. The environment created by IKJTSOEV does not support those FIB commands.

However, it appears that C2POLICE invokes CKRCARLX, the APF-authorised version and as document in the link you pointed out, this only supports a subset of commands including some HSM and IDCAMS commands, the APF-authorised commands and "some others" in a list internal to zSecure (undocumented).

Furthermore using your suggested JCL and executing CKRCARLX as used by C2POLICE, I was able to attempt to execute an EXEC command and found that I received a CKR962N message stating that EXEC is NOT supported in that environment. So my hope for using doing something more than single commands have been dashed. Experimentation with SUB and SUBMIT show that they too are not allowed. 

Back to the drawing board.
Lennie

Some background to what we are doing.
We have been trying to classify the Alerts raised by zSecure and have come up with three classifications.

1. Those that require immediate action. For these we will use an automation product to raise a formal alert which causes call-out if required.
2. Those that require eventual action. For these we would like to raise some kind of work ticket, for the situation to be investigated in due course.
3. Those that are being logged for records. These might be to understand what is going on in the system. Typically such alerts would activated for a fixed period of time.

The ones causing us difficulty are the second category. We would like to kick off some kind of process to raise this work ticket. We don't want to involve the automation product, as it is likely this category would be subject to much change and the change process could become unwieldy.

So here is the 64-dollar question.
Is there any way that I can kick off some kind of process from an alert generated by zSecure Alert?
We have attempted to use the "Action Command" of the alert, but as we cannot execute an EXEC we are snookered. What can we do?

Or is it reasonable to raise this as an "IBM idea"?

Lennie

Hi Lennie,

My thought is that you could send out a WTO and that that could be picked up by an automation package or something along those lines?

Regards,
Jeroen

Most ticketing systems I've worked with have some kind of email ingestion capability.  Sending an email to ticketing system is a straight-forward method, esp. since you're writing your own skeletons and have thereby control over the subject and content of your mail.

Perhaps the SYSL interface that writes Unix Syslog messages with (most of the) fields could be used to feed a ticket generator.  I wrote a Rexx that runs in z/OS Unix and uses the Socket interface to accept SYSL messages.  That could be your interface to receive alerts and process them as you like.  I still have the code somewhere, it ran for years in the time that zSecure could only transmit UDP streams.

In one installation I could not use email though SMTP, so all emails were left in JES2 spool.  I wrote a Rexx program that used the SDSF Rexx API to obtain a list of the email output files, read each file, pick relevant info from the mail body and take the necessary actions.  The program ran in a batch job that was scheduled to be submitted every 15 minutes.  It took only 83 lines of Rexx.  This might get you out from the woods?