Writing Access Rules › Writing the First Access Rules

Writing the First Access Rules

The most general rule set that you can write includes only one rule entry for each possible $KEY value. This type of rule allows read, write, and execute access by anyone under any conditions. To write such a rule set for a minidisk and the CMS file IDs it contains requires just two lines. You can write these lines to a CMS file and use them as input to the CA ACF2 for z/VM rule compiler or enter them directly into the compiler using the ACF COMPILE command. The following example shows how this rule set appears:

$KEY(TLCAMS)
‑ R(A) W(A) E(A)

Instead of entering a dsn entry, a dash (‑) represents all the possible minidisk identifiers; CMS file IDs, and MVS and VSE data set names. The dash (‑) is a valid CA ACF2 for z/VM masking character and means the rule entry matches any value in this $KEY. $KEY control statements must begin in the first column. All rule input entries should begin in position two.

Because no other conditions are specified in this rule entry, the permissions apply to all users accessing any of TLCAMS’s information. The permissions indicated by R(A) W(A) E(A) specify that reading, writing (updating), and executing (running execs and modules from TLCAMS minidisks) are all allowed.

Early rule sets like this one greatly reduce the number of loggings and the volume of reports. However, from a security point of view, this rule is too general to be a good permanent rule. You should only use this technique selectively and only as a transition aid to reduce report volume. When you are ready to write a more specific TLCAMS rule (while still in LOG mode), remove this temporary rule. This logs all accesses to TLCAMS files again (no rule applies, so they look like potential violations). Or, you could change access permissions in the rule from A (allow) to L (allow but log). Now, CA ACF2 for z/VM reports of TLCAMS file accesses can help write specific TLCAMS rules.

Writing Temporary Rules

Another CA ACF2 for z/VM rule feature that you could use is to specify that a rule entry is only temporary. This is done by putting an end date on it. For example, you could have created the previous TLCAMS rule like this:

$KEY(TLCAMS)
* TEMPORARY RULE TO REMOVE TLCAMS FROM REPORTS
‑ UNTIL(12/31/97) R(A) W(A) E(A)

When this rule is compiled and stored by CA ACF2 for z/VM, it automatically expires on December 31, 1997. With no rule left allowing anyone access after that date, accesses to TLCAMS files would again appear on the logging reports. This way, the security administrator would not forget to refine the initial rule. This example also contains an optional comment statement (any line with an asterisk in column one).

Based on the CA ACF2 for z/VM reports, you can write additional rules and redefine existing rules until you feel most rules are complete. You can use WARN mode as an additional period to refine rules before you implement full ABORT mode. See the “Converting to Full Security,” chapter for more information on these modes.

For additional information on rule set syntax and hints on rule writing, see the Administrator Guide.