Broadcom CA ACF2
Broadcom CA ACF2 is formerly known as CA Technologies ACF2. The name remains CA ACF2 in JSA.
The Broadcom CA Access Control Facility (ACF2) DSM collects events from a Broadcom CA Technologies ACF2 image on an IBM z/OS mainframe by using IBM Security zSecure.
When you use a zSecure process, events from the System Management Facilities (SMF) can be transformed into Log Event Extended Format (LEEF) events. These events can be sent near real-time by using UNIX Syslog protocol or JSA can retrieve the LEEF event log files by using the Log File protocol and then process the events. When you use the Log File protocol, you can schedule JSA to retrieve events on a polling interval, which enables JSA to retrieve the events on the schedule that you define.
To collect CA ACF2 events, complete the following steps:
Verify that your installation meets any prerequisite installation requirements.
Configure your IBM z/OS image to write events in LEEF format.
Create a log source in JSA for CA ACF2.
If you want to create a custom event property for CA ACF2 in JSA, for more information, see the Custom Event Properties for IBM Z/OS Technical note.
Before You Begin
Before you can configure the data collection process, you must complete the basic zSecure installation process and complete the post-installation activities to create and modify the configuration.
The following prerequisites are required:
You must ensure parmlib member IFAPRDxx is enabled for IBM Security zSecure Audit on your z/OS image.
The SCKRLOAD library must be APF-authorized.
If you are using the direct SMF INMEM real-time interface, you must have the necessary software installed (APAR OA49263) and set up the SMFPRMxx member to include the INMEM keyword and parameters. If you decide to use the CDP interface, you must also have CDP installed and running.
You must configure a process to periodically refresh your CKFREEZE and UNLOAD data sets.
If you are using the Log File protocol method, you must configure a SFTP, FTP, or SCP server on your z/OS image for JSA to download your LEEF event files.
If you are using the Log File protocol method, you must allow SFTP, FTP, or SCP traffic on firewalls that are located between JSA and your z/OS image.
Create a Log Source for Near Real-time Event Feed
The Syslog protocol enables JSA to receive System Management Facilities (SMF) events in near real-time from a remote host.
The following DSMs are supported:
IBM z/OS
IBM CICS
IBM RACF
IBM DB2
CA Top Secret
CA ACF2
If JSA does not automatically detect the log source, add a log source for your DSM on the JSA console.
The following table describes the parameters that require specific values for event collection for your DSM:
Parameter |
Value |
|---|---|
Log Source type |
Select your DSM name from the list. |
Protocol Configuration |
Syslog |
Log Source Identifier |
Type a unique identifier for the log source. |
Log File Log Source Parameter
If JSA does not automatically detect the log source, add a IBM z/OS, IBM CICS, IBM RACF, IBM DB2, Broadcom CA Top Secret, or Broadcom CA ACF2 log source on the JSA Console by using the Log File Protocol.
When using the Log File protocol, there are specific parameters that you must use.
The following table describes the parameters that require specific values to collect Log File events from IBM z/OS, IBM CICS, IBM RACF, IBM DB2, CA Top Secret, or CA ACF2:
Parameter |
Value |
|---|---|
Log Source name |
Type a name for your log source. |
Log Source description |
Type a description for the log source. |
Log Source type |
Select your DSM name. |
Protocol Configuration |
Log File |
Log Source Identifier |
Type an IP address, host name, or name to identify the event source. IP addresses or host names are suggested as they allow JSA to identify a log file to a unique event source. For example, if your network contains multiple devices, such as multiple z/OS images or a file repository that contains all of your event logs, you must specify a name, IP address, or host name for the image or location that uniquely identifies events for the DSM log source. This specification enables events to be identified at the image or location level in your network that your users can identify. |
Service Type |
From the Service Type list, select the protocol that you want to use when retrieving log files from a remote server. The default is SFTP.
The underlying protocol that is used to retrieve log files for the SCP and SFTP service type requires that the server that is specified in the Remote IP or Hostname field has the SFTP subsystem enabled. |
Remote IP or Hostname |
Type the IP address or host name of the device that stores your event log files. |
Remote Port |
Type the TCP port on the remote host that is running the selected Service Type. The valid range is 1 - 65535. The options include ports:
If the host for your event files is using a non-standard port number for FTP, SFTP, or SCP, you must adjust the port value. |
Remote User |
Type the user name or user ID necessary to log in to the system that contains your event files.
|
Remote Password |
Type the password necessary to log in to the host. |
Confirm Password |
Confirm the password necessary to log in to the host. |
SSH Key File |
If you select SCP or SFTP as the Service Type, this parameter gives you the option to define an SSH private key file. When you provide an SSH Key File, the Remote Password field is ignored. |
Remote Directory |
Type the directory location on the remote host from which the files are retrieved, relative to the user account you are using to log in. |
Recursive |
If you want the file pattern to search sub folders in the remote directory, select this check box. By default, the check box is clear. If you configure SCP as the Service Type, the Recursive option is ignored. |
FTP File Pattern |
If you select SFTP or FTP as the Service Type, you can configure the regular expression (regex) needed to filter the list of files that are specified in the Remote Directory. All matching files are included in the processing. The IBM z/OS mainframe that uses IBM Security zSecure Audit
writes event files by using the pattern: The FTP file pattern that you specify must match the name that you assigned to your event files. For example, to collect files that start with zOS and end with .gz, type the following code: Use of this parameter requires knowledge of regular expressions (regex). For more information about regex, see Lesson: Regular Expressions. (http://download.oracle.com/javase/tutorial/essential/regex/) |
FTP Transfer Mode |
This option displays only if you select FTP as the Service Type. From the list, select Binary. The binary transfer mode is needed for event files that are stored in a binary or compressed format, such as zip, gzip, tar, or tar+gzip archive files. |
SCP Remote File |
If you select SCP as the Service Type you must type the file name of the remote file. |
Start Time |
Type the time of day you want the processing to begin. For example, type 00:00 to schedule the Log File protocol to collect event files at midnight. This parameter functions with the Recurrence value to establish when and how often the Remote Directory is scanned for files. Type the start time, based on a 24-hour clock, in the following format: HH: MM. |
Recurrence |
Type the frequency, beginning at the Start Time, that you want the remote directory to be scanned. Type this value in hours (H), minutes (M), or days (D). For example, type 2H if you want the remote directory to be scanned every 2 hours from the start time. The default is 1H. |
Run On Save |
If you want the Log File protocol to run immediately after you click Save, select this check box. After the Run On Save completes, the Log File protocol follows your configured start time and recurrence schedule. Selecting Run On Save clears the list of previously processed files for the Ignore Previously Processed File parameter. |
EPS Throttle |
Type the number of Events Per Second (EPS) that you do not want this protocol to exceed. The valid range is 100 - 5000. |
Processor |
From the list, select gzip. Processors enable event file archives to be expanded and contents are processed for events. Files are processed after they are downloaded to JSA. JSA can process files in zip, gzip, tar, or tar+gzip archive format. |
Ignore Previously Processed File(s) |
Select this check box to track and ignore files that are already processed by the Log File protocol. JSA examines the log files in the remote directory to determine whether a file is previously processed by the Log File protocol. If a previously processed file is detected, the Log File protocol does not download the file for processing. All files that are not previously processed are downloaded. This option applies only to FTP and SFTP service types. |
Change Local Directory? |
Select this check box to define a local directory on your JSA for storing downloaded files during processing. It is suggested that you leave this check box clear. When this check box is selected, the Local Directory field is displayed, which gives you the option to configure the local directory to use for storing files. |
Event Generator |
From the Event Generator list, select LineByLine. The Event Generator applies more processing to the retrieved event files. Each line is a single event. For example, if a file has 10 lines of text, 10 separate events are created. |
Integrate Broadcom CA ACF2 with JSA by Using Audit Scripts
The Broadcom CA Access Control Facility (ACF2) DSM collects events and audit transactions on the IBM mainframe with the log file protocol.
QexACF2.load.trs is a TERSED file that contains a PDS loadlib with the QEXACF2 program. A TERSED file is similar to a zip file and requires you to use the TRSMAIN program to decompress the contents.
To upload a TRS file from a workstation, you must preallocate a file with the following DCB attributes: DSORG=PS, RECFM=FB, LRECL= 1024, BLKSIZE=6144. The file transfer type must be BINARY APPEND. If the transfer type is TEXT or TEXT APPEND, then the file cannot decompress properly.
After you upload the file to the mainframe into the allocated dataset, the TERSED file can be UNPACKED with the TRSMAIN utility by using the sample JCL also included in the tar package. A return code of 0008 from the TRSMAIN utility indicates that the dataset is not recognized as a valid TERSED file. This code (0008) error might be the result of the file not being uploaded to the mainframe with the correct DCB attributes, or because the transfer was not performed with the BINARY APPEND transfer mechanism.
After you have successfully UNPACKED the loadlib file, you can run the QEXACF2 program with the sample JCL file. The sample JCL file is contained in the tar collection. To run the QEXACF2 program, you must modify the JCL to your local naming conventions and JOB card requirements. You might also need to use the STEPLIB DD if the program is not placed in a LINKLISTED library.
To integrate CA ACF2 events into JSA:
The IBM mainframe records all security events as Service Management Framework (SMF) records in a live repository.
The CA ACF2 data is extracted from the live repository with the SMF dump utility. The SMF file contains all of the events and fields from the previous day in raw SMF format.
The QexACF2.load.trs program pulls data from the SMF formatted file. The QexACF2.load.trs program pulls only the relevant events and fields for JSA and writes that information in a compressed format for compatibility. The information is saved in a location accessible by JSA.
JSA uses the log file protocol source to retrieve the output file information on a scheduled basis. JSA then imports and processes this file.
Configuring Broadcom CA ACF2 that uses Audit Scripts to integrate with JSA
JSA uses scripts to audit events from Broadcom CA ACF2 installations, which are retrieved by using the log file protocol.
From the https://support.juniper.net/support/, download the following compressed file:
qexacf2_bundled.tar.gz
On a Linux operating system, extract the file:
tar -zxvf qexacf2_bundled.tar.gz
The following files are contained in the archive:
QexACF2.JCL.txt - Job Control Language file
QexACF2.load.trs - Compressed program library (requires IBM TRSMAIN)
trsmain sample JCL.txt - Job Control Language for TRSMAIN to decompress the .trs file
Load the files onto the IBM mainframe by using the following methods:
Upload the sample QexACF2_trsmain_JCL.txt and QexACF2.JCL.txt files by using the TEXT protocol.
Upload the QexACF2.load.trs file by using a BINARY mode transfer and append to a preallocated data set. The QexACF2.load.trs file is a tersed file that contains the executable file (the mainframe program QexACF2). When you upload the .trs file from a workstation, preallocate a file on the mainframe with the following DCB attributes: DSORG=PS, RECFM=FB, LRECL=1024, BLKSIZE=6144. The file transfer type must be binary mode and not text.
Note:QexACF2 is a small C mainframe program that reads the output of the TSSUTIL (EARLOUT data) line by line. QexACF2 adds a header to each record that contains event information, for example, record descriptor, the date, and time. The program places each field into the output record, suppresses trailing blank characters, and delimits each field with the pipe character. This output file is formatted for JSA and the blank suppression reduces network traffic to JSA. This program does not consume CPU or I/O disk resources.
Customize the trsmain sample_JCL.txt file according to your installation-specific parameters.
Example: Jobcard, data set naming conventions, output destinations, retention periods, and space requirements.
The trsmain sample_JCL.txt file uses the IBM utility TRSMAIN to extract the program that is stored in the QexACF2.load.trs file.
An example of the QexACF2_trsmain_JCL.txt file includes the following information:
//TRSMAIN JOB (yourvalidjobcard),Q1labs, // MSGCLASS=V //DEL EXEC PGM=IEFBR14 //D1 DD DISP=(MOD,DELETE),DSN=<yourhlq>.QEXACF2.LOAD.TRS // UNIT=SYSDA, // SPACE=(CYL,(10,10)) //TRSMAIN EXEC PGM=TRSMAIN,PARM='UNPACK' //SYSPRINT DD SYSOUT=*,DCB=(LRECL=133,BLKSIZE=12901,RECFM=FBA) //INFILE DD DISP=SHR,DSN=<yourhlq>.QEXACF2.LOAD.TRS //OUTFILE DD DISP=(NEW,CATLG,DELETE), // DSN=<yourhlq>.LOAD, // SPACE=(CYL,(10,10,5),RLSE),UNIT=SYSDA //
The .trs input file is an IBM TERSE formatted library and is extracted by running the JCL, which calls the TRSMAIN. This tersed file, when extracted, creates a PDS linklib with the QexACF2 program as a member.
You can STEPLIB to this library or choose to move the program to one of the LINKLIBs that are in LINKLST. The program does not require authorization.
After you upload, copy the program to an existing link listed library or add a STEPLIB DD statement with the correct
datasetname of the library that will contain the program.The QexACF2_jcl.txt file is a text file that contains a sample JCL. You must configure the job card to meet your configuration.
The QexACF2_jcl.txt sample file includes:
//QEXACF2 JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK, // MSGCLASS=P, // REGION=0M //* //*QEXACF2 JCL VERSION 1.0 OCTOBER, 2010 //* //************************************************************ //* Change below dataset names to sites specific datasets names*
//QEXACF2 JOB (T,JXPO,JKSD0093),DEV,NOTIFY=Q1JACK, // MSGCLASS=P, // REGION=0M //* //*QEXACF2 JCL VERSION 1.0 OCTOBER, 2010 //* //************************************************************ //* Change below dataset names to sites specific datasets names* //************************************************************ //SET1 SET SMFIN='MVS1.SMF.RECORDS(0)', // QEXOUT='Q1JACK.QEXACF2.OUTPUT', // SMFOUT='Q1JACK.ACF2.DATA' //************************************************************ //* Delete old datasets * //************************************************************ //DEL EXEC PGM=IEFBR14 //DD1 DD DISP=(MOD,DELETE),DSN=&SMFOUT, // UNIT=SYSDA, // SPACE=(CYL,(10,10)), // DCB=(RECFM=FB,LRECL=80) //DD2 DD DISP=(MOD,DELETE),DSN=&QEXOUT, // UNIT=SYSDA, // SPACE=(CYL,(10,10)), // DCB=(RECFM=FB,LRECL=80) //************************************************************* //* Allocate new dataset * //************************************************************* //ALLOC EXEC PGM=IEFBR14 //DD1 DD DISP=(NEW,CATLG),DSN=&QEXOUT, // SPACE=(CYL,(100,100)), // DCB=(RECFM=VB,LRECL=1028,BLKSIZE=6144) //************************************************************* //* Execute ACFRPTPP (Report Preprocessor GRO) to extract ACF2* //* SMF records * //************************************************************* //PRESCAN EXEC PGM=ACFRPTPP //SYSPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //RECMAN1 DD DISP=SHR,DSN=&SMFIN //SMFFLT DD DSN=&SMFOUT,SPACE=(CYL,(100,100)),DISP=(,CATLG), // DCB=(RECFM=FB,LRECL=8192,BLKSIZE=40960), // UNIT=SYSALLDA //************************************************************ //* execute QEXACF2 * //************************************************************ //EXTRACT EXEC PGM=QEXACF2,DYNAMNBR=10, // TIME=1440 //STEPLIB DD DISP=SHR,DSN=Q1JACK.C.LOAD //SYSTSIN DD DUMMY
//SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //CFG DD DUMMY //ACFIN DD DISP=SHR,DSN=&SMFOUT //ACFOUT DD DISP=SHR,DSN=&QEXOUT //************************************************************ //FTP EXEC PGM=FTP,REGION=3800K //INPUT DD * <IPADDR> <USER> <PASSWORD> PUT '<ACFOUT>' EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT> QUIT //OUTPUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //*
After the output file is created, schedule a job to a transfer the output file to an interim FTP server. The output file is forwarded to an interim FTP server.
You must configure the following parameters in the sample JCL to successfully forward the output to an interim FTP server:
//FTP EXEC PGM=FTP,REGION=3800K //INPUT DD * <IPADDR> <USER> <PASSWORD> PUT '<ACFOUT>' EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT> QUIT //OUTPUT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //*
Where:
<IPADDR> is the IP address or host name of the interim FTP server to receive the output file.
<USER> is the user name that is needed to access the interim FTP server.
<PASSWORD> is the password that is needed to access the interim FTP server.
<THEIPOFTHEMAINFRAMEDEVICE> is the destination of the mainframe or interim FTP server that receives the output.
<QEXOUTDSN> is the name of the output file that is saved to the interim FTP server.
You are now ready to configure the Log File protocol.
Schedule JSA to retrieve the output file from CA ACF2.
If the zOS platform is configured to serve files through FTP, SFTP, or allow SCP, then no interim FTP server is needed and JSA can pull the output file directly from the mainframe. The following text must be commented out using
//*or deleted from the QexACF2_jcl.txt file://FTP EXEC PGM=FTP,REGION=3800K //INPUT DD * <IPADDR> <USER> <PASSWORD> PUT '<ACFOUT>' EARL_<THEIPOFTHEMAINFRAMEDEVICE>/<ACFOUT> QUIT //OUTPUT DD SYSOUT=* //SYSPRINT DD SYSOUT=*
You are now ready to configure the log source in JSA.