This week we’re moving to a simple yet critical fundamental of NonStop security—ensuring individual accountability. While aspects of this were touched upon in both the #10 and #9 NonStop Security Fundamentals, we feel individual accountability is an important enough concept to rate its own entry on the list.
#8: Ensure individual accountability (no shared IDs!)
The NonStop system is shipped with certain shared userids that can be used for privileged or non-privileged access (like SUPER.SUPER or NULL.NULL). However, security best practices and industry regulations, like PCI DSS, require users to have unique userids so that there is clear accountability. This also facilitates effective auditing, remediation and management of individual user rights and access.
These are some areas that must be addressed:
Eliminate shared userids. In the #9 blog we talked about PCI DSS Requirement 8.1 which required all users to have unique userids in order to ensure individual accountability—eliminating the use of shared userids is an extension of that concept. Shared userids, particularly for privileged userids, provide too much access and too little accountability.
Eliminate aliases to privileged userids. Aliases are only available in Safeguard environments and are used to provide alternate user names that can be used to log on to the system. Aliases should not be assigned to privileged userids (like SUPER.SUPER) because the alias gains all the underlying userid’s privileges and Safeguard provides limited auditing of the alias activity. Third-party products like XYGATE Access Control (XAC) can eliminate the need for aliases and provide more extensive auditing. Note, if a company wishes to continue using aliases, any XYGATE module can be configured to restrict the alias’s privileges separately from those of the underlying userid.
While we’re on the topic of userids, let’s cover two additional points about managing personal userids in order to have effective NonStop security with clear accountability:
No personal userids in the SUPER group. Anyone with a personal ID in the group number 255 is a SUPER group member. SUPER group members can set and reset the system time, manage all jobs in the SPOOLER or in PERUSE (regardless of who owns them), and perform all commands within SCF, FUP and several other powerful utilities.
No personal userids assigned to the 255 member of any group. The group member number 255 is the Group Manager ID and should never be assigned as a personal userid. Some of the risks associated with the Group Manager ID are:
- Group Managers can ADD, Alter, Delete userids in their own group if Safeguard is not present or is not configured to prevent it.
- Group Managers can “log down” to the userid of any member of the same group without a password unless prevented by Safeguard.
- Group Managers can PROGID any program owned by a group member.
- In Safeguard, the group manager of the Primary Owner of any object’s Protection Record can also modify any Safeguard Protection Records owned by members of the same group
Well, that’s #8: Ensuring individual accountability (no shared IDs!).It’s not just an important security best practice but also a PCI DSS requirement.
Stay tuned to the XYPRO blog site—next up on our list is NonStop Security Fundamental #7
For more information or help: More in-depth information and guidance on these security subjects are available in XYPRO’s NonStop security handbooks: HPE NonStop Server Security: A Practical Handbook and Securing HPE NonStop Servers in an Open Systems World: TCP/IP, OSS and SQL. PCI information can be found at:https://www.pcisecuritystandards.org/index.php
You may also contact XYPRO for assistance. For over 30 years, XYPRO has provided NonStop security solutions and services that help companies protect their NonStop systems and comply with industry regulations (such as PCI DSS, HIPAA, and SOX).
