From z/OS TSS STIG
Part of ZUSS0080
Associated with IA controls: ECAR-3, ECAR-2, IAGA-1, ECAR-1
Associated with: CCI-000213 CCI-000770
Shared accounts by nature are a violation of proper audit trail and proper user authentication. If not properly controlled, could cause system corruption without an audit trail tracking session
z/OS Software owning Shared accounts” maybe created for the installation and upgrades on the z/OS Mainframe products that require the use of USS (UNIX System Services) as long as all IA requirements are met. “z/OS USS Software Owning Shared Accounts” shall be referenced within this VUL as the full name or abbreviated “Shared accounts” for all references within this VUL. Rules and requirements for z/OS USS Software Owning Shared Accounts. 1) Shall include a statement from the responsible SA requesting the “shared account”, stating specific justification for the z/OS USS Software Owning shared account. Responsible SA shall be responsible for maintaining all documentation concerning account, usage, control, annual review, etc and shall provide upon request by IA staff or auditors as requested. 2) A separate “z/OS USS Software Owning shared account” userid will be created for each application and/or product that requires USS for separation of duties for product support. This “shared account” shall be used for the sole purpose of file/directory ownership based upon the UID assigned to the “shared account”. 3) The “shared accounts” shall only be used within/for USS (UNIX System Services). The “shared account” userids shall have no special privileges, will not be granted access to interactive on-line facilities, batch facility, and will not be granted access to datasets and resources outside of the USS environment. 4) The “shared account” userids shall adhere to the same complex password syntax rules and shall be assigned a non-expiring complex password or be set up as protected under RACF. 5) Authorized user(s) shall only access “shared account” via the USS “SU” Command (switch user: su –s userid ) and not utilize any password. When the ACP IAO creates the account with a complex password, such password shall not be written down or shared with others. 6) The responsible documented z/OS system programmer shall be granted specific limited and temporary access based upon submitted security service requests identifying project, duration required and justification for accessing “shared account” via the “su” command on a specific z/OS domain, example: initial software installation or upgrade of specific vendor software. 7) Responsible individual z/OS System programmer shall be granted temporary access to the specific BPX.SRV.userid (“userid” shall be the single “shared account” requested) in the surogate user class with full logging of the permission to BPX.SRV.userid for the specific period of time required to perform functional requirements via the “su” command and appropriate usage of the “shared account”. 8) Standard procedure for all updates within USS Directories/files shall be performed based upon the direct authority granted to the z/OS system programmer individual userids. Shared accounts shall only be utilized for initial software installation or vendor software upgrades. If all the above requirements are not met for the z/OS USS Software Owning shared account, this is a finding.
To create a shared account follow the instructions below. Shared accounts” will be created for the installation and upgrades on the z/OS Mainframe products that require the use of USS (UNIX System Services) Rules and requirements for z/OS USS Software Owning Shared Accounts 1) Shall include a statement from the responsible SA requesting the “shared account”, stating specific justification for the z/OS USS Software Owning shared account. Responsible SA shall be responsible for maintaining all documentation concerning account, usage, control, annual review, etc and shall provide upon request by IA staff or auditors as requested. 2) A separate “z/OS USS Software Owning shared account” userid will be created for each application and/or product that requires USS for separation of duties for product support. This “shared account” shall be used for the sole purpose of file/directory software ownership based upon the UID assigned to the “shared account”. 3) The “shared accounts” shall only be used within/for USS (UNIX System Services). The “shared account” userids shall have no special privileges, shall not be granted access to interactive on-line facilities, batch facility, and shall not be granted access to datasets and resources outside of the USS environment. 4) The “shared account” userids shall adhere to the same complex password syntax rules and shall be assigned a non-expiring complex password or be set up as protected under RACF. 5) Authorized user(s) shall only access “shared account” via the USS “SU” Command (switch user: su –s userid ) and not utilize any password. When the ACP IAO creates the account with a complex password, such password shall not be written down or shared with others. 6) The responsible documented z/OS system programmer shall be granted specific, limited and temporary access based upon submitted security service requests identifying project, duration required and justification for accessing “shared account” via the “su” command on a specific z/OS domain, example: initial software installation or upgrade of specific vendor software. 7) Responsible Individual z/OS System programmer shall be granted temporary access to the specific BPX.SRV.userid (“userid” shall be the single “shared account” requested) in the surogate user class with full logging of the permission to BPX.SRV.userid for the specific period of time required to perform functional requirements via the “su” command and appropriate usage of the “shared account”. 8) Standard procedure for all updates within USS Directories/files shall be performed based upon the direct authority granted to the z/OS system programmer individual userids. Shared accounts shall only be utilized for initial software installation or vendor software upgrades. To share HFS or ZFS Files associated with this shared file : • Associate the directory or file with a ACP group that has been assigned a z/OS UNIX group identifier (GID), give the ACP group the appropriate group permissions, and connect the users to this ACP group • With z/OS Version 1 Release 3 or later, you can use access control lists (ACLs) to control access to files and directories by individual UIDs and GIDs. With ACLs, you can give more than one group permissions for directories or files on HFS, so you do not need to ensure that all your file owners connect to the same ACP group. NOTE: If using HFSSEC for TSS or ACF2 you will not be able to use ACLs to control access to your files. Both CA-ACF2 and CA-TSS provide for a feature and capability to control all HFS/ZFS files and directories directly within the ACP using HFSSEC resource class. HFSSEC provides full control, auditing and review capability within the native ACP software and requires less interaction in setting up appropriate and proper access controls over the vast USS environment. With appropriate HFSSEC controls in place, access controls are performed by the ACP and not via USS UID/GID Controls. Using HFSSEC, all controls are at the userid level and would not be able to utilize ACL’s to control access.
Lavender hyperlinks in small type off to the right (of CSS
class id, if you view the page source) point to
globally unique URIs for each document and item. Copy the
link location and paste anywhere you need to talk
unambiguously about these things.
You can obtain data about documents and items in other
formats. Simply provide an HTTP header Accept:
text/turtle or
Accept: application/rdf+xml.
Powered by sagemincer