Auditability is a major principle of access control and a requirement of PCI-DSS. Monitoring complements accountability, authentication, and authorization by showing how security controls are actually protecting a system. Without monitoring, individual accountability, authentication, and authorization cannot be shown to have worked.
Monitoring must discover all occurrences of unusual authorized activities such as changing the security configuration or adding a user, and all occurrences of unauthorized activity such as a bad logon or denied file access.
On an HPE NonStop server, without additional third-party controls, authentication and authorization are controlled by the Safeguard subsystem. The Safeguard audit service provides for monitoring of authentication and authorization actions. It allows you to record and retrieve information about a wide range of events. Audited events are recorded in the Safeguard audit files, collectively referred to as the audit trail. With a tool such as XYGATE Merged Audit (XMA), you can easily collect Safeguard audit data and retrieve data in the form of queries and reports, using the easy to use XYGATE Report Manager (XRM) tool and also be notified in real-time of audit events that are too critical to wait for a report.
Determining what to audit seems simple enough. Why not just switch-on all available auditing and be done with it? Why not, indeed?
Auditing too much may not only be a waste of resources, it may be a drag on them as well. So much so, that if Safeguard auditing is configured incorrectly, Safeguard can far outrun any tool trying to collect from the Safeguard audit trail. We recently helped a customer who had reported excess overhead with their security audit processing and were experiencing delays in getting their critical audit information to their security incident and event monitoring system. It turned out that the root cause of the problem was a single Safeguard ACL on the USERID files with AUDIT-ACCESS-PASS set to ALL. This resulted in Safeguard generating an immense amount of audit, about 2100 records per second, causing the Safeguard audit trail to fill, roll over and subsequently delay the processing of the events due to congestion and limited resources. The utilities trying to read and act upon this overload of audit information fell behind and were no longer as effective as they should have been..
Not auditing enough means you probably do not have the data necessary to investigate a security anomaly. We have seen many instances of customers configured for only the minimum level of Safeguard auditing. These customers had absolutely no way of monitoring who was being authenticated and what objects were being accessed.
It is critical to understand what Safeguard is capable of auditing, how much is audited, and what is necessary to audit. The Safeguard subsystem generates audit records for the events it controls. Some events are recorded regardless of Safeguard settings. To audit most types of events, however, specific Safeguard audit attributes must be configured. You can configure the following events globally and in some cases, individually.
- Authenticating users
- Accessing objects
- Creating, changing, or deleting Safeguard protection records
- Creating, changing, or deleting Safeguard GROUP records
- Automatic logoffs that occur if you logon at a logged terminal
The volume of Safeguard auditing depends on the type of event being audited and the level of auditing. Most events generate multiple audit file entries. Furthermore, both successful and unsuccessful authentication and access attempts can be audited.
Auditing user authentication attempts is controlled using the AUDIT-AUTHENTICATE-FAIL and AUDIT-AUTHENTICATE-PASS attributes. XYPRO recommends setting both to ALL.
Accessing objects is controlled using the AUDIT-OBJECT-ACCESS-FAIL, AUDIT-OBJECT-ACCESS-PASS, AUDIT-DEVICE-ACCESS-FAIL, AUDIT-DEVICE-ACCESS-PASS, AUDIT-PROCESS-ACCESS-FAIL, AUDIT-PROCESS-ACCESS-PASS, AUDIT-DISKFILE-ACCESS-FAIL, and AUDIT-DISKFILE-ACCESS-PASS attributes. XYPRO recommends setting the FAIL-type attributes to ALL. The PASS-type attributes should be set to NONE.
Managing objects is controlled using the AUDIT-OBJECT-MANAGE-FAIL, AUDIT-OBJECT-MANAGE-PASS, AUDIT-DEVICE-MANAGE-FAIL, AUDIT-DEVICE-MANAGE-PASS, AUDIT-PROCESS-MANAGE-FAIL, AUDIT-PROCESS-MANAGE-PASS, AUDIT-DISKFILE-MANAGE-FAIL, and AUDIT-DISKFILE-MANAGE-PASS attributes. XYPRO recommends setting all of MANAGE-type attributes to ALL.
XYPRO recommends setting AUDIT-CLIENT-OSS and AUDIT-CLIENT-GUARDIAN to OFF.
XYPRO’s best practice settings agree with the Level 1 auditing recommendations of the HPE NonStop Security Hardening Guide. The three levels are:
Level 1– All changes to Safeguard’s configuration, failed object access attempts, all logon operations
Level 2 – All Guardian access (via Safeguard global AUDIT-CLIENT-GUARDIAN), successful object access attempts
Level 3 – Most or all OSS access (via Safeguard global AUDIT-CLIENT-OSS and AUDITENABLED set for sensitive OSS filesets)
XYGATE Merged Audit (XMA) collects audit entries from a variety of data sources, including Safeguard audit files, and merges them into a single NonStop SQL/MP database. XMA movers (Pathway serverclasses) read audit data sources, normalize the data, and optionally insert the data into the XMA database.
XMA movers use filters to sift through all of the audit data so that only the data that needs to be stored gets stored. Filters can also control what data is alerted to a Security Information & Event Monitoring (SIEM) appliance, such as HPE ArcSight.
With one exception, the default behavior of all movers is to write every record read from their respective product audit trails into the XMA database. XMA is installed, however, with several “ignore” filters. These filters ignore certain uninformative and unwanted events. The IGNORE action causes a mover to discard the data instead of inserting them into the XMA database.
EMS movers behave differently. Because of the huge volume of EMS messages, EMS log file entries will only be written to the XMA database when you create an EMS filter.
PCI DSS requirement 10 is all about tracking and monitoring all access to network resources and cardholder data. Requirement 10 states that “Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough tracking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, without system activity logs.”
Consider using third-party products such as:
- XYGATE Compliance Pro (XSW) for automated system policy, best practice, system integrity, and regulatory compliance (e.g., PCI, SOX, and HIPAA) monitoring.
- XYGATE Object Security (XOS) to further fine-tune object protection and auditing. XOS works with Safeguard as a Security Event Exit Process (SEEP). XOS is a lot more flexible than Safeguard and allows you to do things like audit successful updates to objects, but not successful reads.
Be certain of your auditing configuration. While you don’t necessarily need to audit everything, you do need to audit the right things. XYPRO published two books that consider the overall security of HPE NonStop servers. Even the most seasoned NonStop professional will find these books a must read.
And remember. If you need help, call XYPRO!
Steve Tcherchian, CISSP, PCI-ISA, PCIP is the Chief Product Officer and Chief Information Security Officer for XYPRO Technology. Steve is on Forbes Technology Council, the NonStop Under 40 executive board, and part of the ANSI X9 Security Standards Committee.
With over 20 years in the cybersecurity field, Steve is responsible for the strategy and innovation of XYPRO’s security product line as well as overseeing XYPRO’s risk, compliance, and security to ensure the best experience for customers in the Mission-Critical computing marketplace.
Steve is an engaging and dynamic speaker who regularly presents on cybersecurity topics at conferences around the world.
