XYGATE Object Security and the OSS Security Event Exit Process (SEEP)
With the upcoming February RVU of the NonStop OS (H06.26/J06.15), HP will introduce support for a Security Event Exit Process (SEEP) within the OSS subsystem. This is a capability that has been anticipated for quite some time, as it allows third-party solutions to participate in the authorization decision when file access requests are made. It works similarly to the Safeguard Authorization SEEP that XYPRO and others take advantage of to enhance and add to Guardian file security.
It is worth noting that the OSS SEEP does not use Safeguard. It is invoked via the OSS Name Server, and configured via SCF.
This article is intended to highlight some of the benefits of the new XYGATE XOS OSS Add-on module. Beginning March 2013, (the XYGATE Object Security (XOS) product can now be licensed to provide previously unavailable, flexible exceptionally granular security for NonStop OSS users. This article was also triggered, in part, by recent discussions on LinkedIn about perceived security limitations on the HP NonStop server, so where appropriate, reference will be made to that discussion.
NonStop users have been taking advantage of the capabilities that XOS provides in Guardian for many years. In general XOS, through its advanced wildcarding and regular expression support, allows for a hugely increased amount of granularity and flexibility, when compared with standard Safeguard ACLs. One XOS user (a leading credit card company) was able to reduce their list of Safeguard ACLs from over one million to approximately 300 with XOS, based on this additional flexibility. Yes, one million to three hundred.
XOS is also simple to use, with a GUI interface assisting with the creation and maintenance of the simple user and object policy rules which govern your security implementation.
With the new OSS SEEP from HP, XOS now has a new OSS module to provide the same levels of usability, granularity and flexibility that has been available to secure the Guardian filesystem for some time. Although NonStop provides two Authorization SEEPs (one for Guardian and one for OSS), the same XOS configuration will rule on Guardian and OSS access requests, and is configured in the same way that users have come to rely on.
XOS with the OSS SEEP includes the following features:
- Every type of OSS operation against every OSS object can be restricted, allowed, and/or audited.
- OSS SEEP rulings are applied at the fileset level. Specific filesets can be included or excluded.
- Guardian and OSS object security can be maintained together in a single file.
- OSS rules can be applied by user function. When users and aliases are grouped by function, manipulation becomes a single operation. This can allow for a significant reduction in the number of ACLs.
- OSS rules can be written for specific users or custom user groups, including Safeguard ALIAS and network users.
- OSS objects do not have to exist for a rule to be set up, allowing for dynamic security rules that apply automatically when object are created.
- OSS objects can be controlled by object name, requesting object, the user or group of users requesting the operation, and/or by OSS operation type. For example, you can restrict who can create or view certain OSS directories, even if they don't already exist.
- OSS operation restrictions or allowances can be set to warning mode for specific users, groups of users, or rules, allowing access to be granted while auditing what the ruling would have been.
- OSS operation restrictions or allowances can be tested in a "what if" mode to verify the outcome before putting a rule into production.
- OSS ruling processes (Security Event Exit Processes) can be distributed across available NonStop CPUs.
- Auditing is very granular. Access to objects can be audited for some users, but not for others.
These capabilities should go a long way to addressing the general concerns raised on LinkedIn recently that “OSS security isn’t as robust or as easy to maintain as Guardian” (to paraphrase).
Other issues raised include shortcomings of existing HP NonStop server audits – lack of IP addresses, difficulties in correlating events etc. These issues are addressed with a combination of XYGATE User Authentication (XUA), which logs IP addresses at logon, XYGATE Access Control (XAC), which captures keystroke audits showing what a user did at any given time, and XYGATE Merged Audit (XMA) which filters all audit data and optionally sends it to a Security Incident Event Manager (SIEM) product like HP ArcSight, for correlation.
XUA can also be used to in an enterprise SSO solution, or with any LDAP server. This applies to 100% of HP NonStop logons or authentication requests.
XYPRO also provides an extensive range of security configuration services offerings for your entire HP NonStop server environment, to ensure optimum security and compliance.
If you would like any further information about how the XYGATE product suite can help simplify and strengthen your HP NonStop server Guardian and/or OSS security, please contact your local XYPRO representative https://www.xypro.com/xypro/contact or email me directly at andrew_p@xypro.com.
Andrew Price
Director, Product Management
Andrew_P@xypro.com
XYPRO Technology Corporation
Posts
