Protecting Resources › LCF Security

LCF Security

Resources protected by LCF are known as unownable resources. LCF resources are added to individual ACIDs to provide access. They are not permitted. LCF security allows the security administrator to limit:

• Commands available to a TSO user.
• Monitor commands available to CA‑Roscoe, ACEP, WYLBUR, and other online multi‑user applications.
• CICS, IMS, and CA‑IDMS transactions.
• Programs a batch job can execute.
• ISPF/SPF panel options available to a user.

When securing transactions with LCF:

• LCF transaction security is easy to implement and is the most common method of implementing security.
• Implementation can be performed for one user without impacting others.
• LCF lets you protect transactions without interfering with other facilities. (You can set up LCF security on your test system without affecting your production system.) Use of facility entries USER77 through USER221 for LCF is not recommended. Even after renaming, LCF processing considers these facilities to be identical.
• LCF level security should not be combined with OTRAN (resource) security. If a transaction is secured by both LCF and OTRAN, OTRAN overrides LCF.
• Password reverification can be used for transactions that are protected through LCF.
• The XDEF and NOXDEF FACILITY suboptions are used for LCF to provide default protection.
• The LCFTRAN and LCFCMD FACILITY suboptions are used to tailor the text for CA Top Secret LCF messages.
• The TSS WHOHAS command is not valid with LCF security. (It is available for OTRAN.)

It is recommended that within a single facility inclusive or exclusive LCF be used to secure sensitive transactions (not a combination of both).

Set Up LCF Security

Transactions protected through LCF must be defined by facility. Divide transactions by function or subset and as a group within profiles. This way transactions are defined only once per group, instead of once per user. You can then limit access to the transaction with an inclusive list that specifies which transactions the user is allowed to use, or an exclusive list that specifies which transactions the user is not allowed to use.

Limiting Access With Inclusive Lists

The inclusive approach restricts an ACID to using only specifically authorized transactions for a particular facility. An inclusive list is indicated by the CMD or TRANS keyword. (These keywords are interchangeable.)

Use of user definable facility entries USER77 through USER221 are not recommended for LCF. LCF processing considers the use of these facilities identical, even after the facility entries have been renamed.

When specifying an inclusive list, use the syntax:

TSS ADDTO(acid) TRANSACTIONS(facility,(trans,trans...))

Example: limit access

This example restricts the users connected to the PROF01 profile to using only the DDYA, DDYU, and DDYY transactions under the CICSPROD facility:

TSS ADDTO(PROF01) TRANSACTIONS(CICSPROD,(DDYA,DDYU,DDYY))

Limiting Access With Exclusive Lists

The exclusive approach allows an ACID to use all transactions except a specific list of restricted transactions for a particular facility. An exclusive list is indicated by the XCOMMAND or XTRANSACTIONS keyword. (These keywords are interchangeable.) For purposes of LCF protection, facility entities USER77 through USER221 are not considered unique.

When specifying an exclusive list, use the syntax:.

TSS ADDTO(acid) XCOMMAND(facility,(trans,trans...))

Example: limiting access

This example allows USER01 to use all of the TSO transactions except the SPF EDIT (SPF2) panel:

TSS ADDTO(USER01) XCOMMAND(TSO,(SPF2))

The LCF Decision Process

When CA Top Secret is validating an ACID's request to access a command, the following decision‑making process is used:

• CA Top Secret searches the user's Security Records in the following order:
  • The ACID's Security Record
  • Any PROFILE(s) associated with the ACID (in the order shown by a TSS LIST command function)
  • The ALL Record
• The search continues through all records (user, profile, ALL) and ends when an exact match or prefix is found, or when all records are searched. If CA Top Secret does not find an exact or closest match to a transaction and only an inclusive list is encountered during the search of the user's applicable records, the transaction must be outside the user's authorized list and the transaction is rejected.
• If CA Top Secret does not find an exact or closest match and only an exclusive list is encountered during the search of the user's applicable records, the transaction must be outside the user's unauthorized (exempt) list and the transaction is accepted.

If Both Inclusive and Exclusive LCF Are Used

Using both inclusive and exclusive LCF lists within a single facility is not recommended. A mixture of LCF‑types is difficult to maintain.

If you use both inclusive and exclusive lists, make sure your definitions do not contradict each other. For example:

TSS ADDTO(CCC) TRANSACTIONS(CICSA,(ABCT))

TSS ADDTO(CCC) XTRANSACTIONS(CICSA,(ABCT))

CA Top Secret uses the following decision‑making process if the list types are mixed:

• The order in which an ACID's security records are checked is the same as the order listed previously.
• Inclusive LCFs are checked first; if a match is found, the request is allowed.
• If the transaction is not found on an inclusive LCF, the exclusive LCF is checked. If the transaction is found on the exclusive LCF, the request is failed.

Within each level of the ACID's Security Records, inclusive then exclusive checking is performed before the next record level, (for example Profile) is reached.

After all levels of checking have been completed, and if both exclusive and inclusive LCF were executed during the security record search, then inclusive LCF logic takes precedence and the record is rejected.

Providing Default Protection

You can provide default protection for transactions by using the XDEF and NOXDEF sub-options of the FACILITY control option.

• The NOXDEF sub-option is set by default to allow all users to execute any transaction until access controls have been established by an inclusive or exclusive list for the user
• The XDEF sub-option indicates that users must have some kind of transaction list-inclusive (TRANS or CMD) or exclusive (XTRANS or XCMD)-before the user can execute any LCF transaction

In FAIL mode, a transaction cannot be executed by a user unless that user is defined to CA Top Secret.

Example: default protection

This example specifies the XDEF option for the CICSPROD facility:

TSS MODIFY(FACILITY(CICSPROD=XDEF))

Bypassing LCF Security

To specify that a particular user or profile is to bypass all LCF security, attach the NOLCFCHK bypass attribute to its ACID. NOLCFCHK use should be carefully restricted.

This attribute is sometimes used with CICS or IMS region ACIDs to avoid the administrative overhead of granting region permission for every transaction taking place.

Example: bypass LCF security

This example allows the ACID SUPRACID to bypass all LCF security checking:

TSS ADDTO(SUPRACID) NOLCFCHK

Using Generic Prefixing

You can use generic prefixes when specifying transactions within an inclusive or an exclusive list. A generic LCF rule is invalid for password reverification.

When using generic prefixing, append a G to the prefix to indicate that a generic prefix is being supplied.

Example: generic prefixing

This example restricts the ACID PDGRLP from using all batch programs that begin with the characters IEH:

TSS ADDTO(PDGRLP) XTRANSACTIONS(BAT,(IEH(G))

Using Reverification

To reduce the chance of someone taking advantage of an unattended terminal, use reverification to force the terminal's user to supply his password to execute a particular transaction. Append a V to the transaction.

Note the following:

• Reverification is only supported for CICS and IMS
• An LCF rule which specifies password reverification may not be specified as a generic prefix

Example: reverification

This example forces reverification:

TSS ADDTO(USR01) TRANSACTIONS(CICSPROD,(PAY9(V)))

Accessing All Transactions

You can use an exclusive LCF list to permit access to all transactions in a facility that, by default, protects all transactions. To allow access to all transactions within a facility, specify an exclusive LCF list for a transaction that does not exist.

Example: access all transactions

This example specifies an exclusive LCF list for the CICS facility, listing NULL as the restricted transaction:

TSS ADDTO(USER01) XTRANSACTIONS(CICSPROD,(NULL))

Because NULL does not exist, USER01 is allowed access to all CICS transactions.