Scope
IEC 10164-7-95 (also published as ISO/IEC 10164-7:1995) defines the Security Alarm Reporting Function (SARF) for use in Open Systems Interconnection (OSI) systems management. The standard specifies a model for the reporting of security-related events as alarms, enabling interoperable communication of security incidents across heterogeneous management systems. It is part of the family of OSI systems management standards and is technically aligned with ITU-T Recommendation X.736 (Security Alarm Reporting Function).
Amendment 1:1996 (consolidated in the 2004 edition) introduces several enhancements to the original specification, including new alarm types, refined severity classification, and improved correlation mechanisms. The 2004 release integrates Amendment 1 and includes editorial corrections without altering the technical scope.
Implementation Tip: IEC 10164-7-95 assumes the existence of an underlying OSI management infrastructure as defined in ISO/IEC 7498-4. Ensure your implementation aligns with the overall systems management framework before deploying SARF components.
Technical Requirements
Security Alarm Model
The standard defines managed objects that represent security alarms. Each alarm is characterized by a set of attributes including alarm type, perceived severity, probable cause, specific problem, and additional information such as time of occurrence and source identifier. The managed object classes are specified using Guidelines for the Definition of Managed Objects (GDMO) templates.
Alarm Types and Parameters
| Alarm Type | Description | Default Severity |
| Authentication Alarm | Reports failure in authentication processes (user, system, or service) | Major |
| Confidentiality Violation | Detection of unauthorized read access to protected information | Critical |
| Integrity Failure | Detection of unauthorized modification or deletion of data | Major |
| Denial of Service | Resource exhaustion, service disruption, or prevention of service delivery | Critical |
| Non-Repudiation Failure | Failure in proof of origin, delivery, or submission | Warning |
| Security Audit Alarm (introduced by Amd1) | Anomaly detected in the security audit trail | Minor |
The extended alarm type list above includes additions from Amendment 1:1996, which added the Security Audit Alarm and refined the definition of existing types to align with practical security requirements.
Severity Levels
Each alarm carries a perceived severity attribute that can take one of five values: Indeterminate, Critical, Major, Minor, or Warning. The standard defines guidelines for mapping underlying security conditions to these levels. Amendment 1 introduced recommendations for severity assignment when multiple alarm conditions coexist, supporting more consistent incident prioritization.
Amendment 1:1996 Enhancements
- Addition of the Security Audit Alarm type for audit trail monitoring.
- Refinement of the correlation mechanism to allow alarm grouping and root-cause identification.
- Introduction of a severity override attribute, enabling management applications to dynamically adjust alarm severity based on context.
- Better alignment with the Event Report Management function (ISO/IEC 10164-5) and the Alarm Notification function (ISO/IEC 10164-4).
Caution: Amendment 1:1996 introduces new managed object classes and attributes that may not be present in implementations based solely on the 1995 edition. When migrating from older systems, verify backward compatibility of alarm attributes and severity mapping.
Implementation Highlights
Implementing IEC 10164-7-95 requires the following typical steps:
- Define Security Alarm Managed Objects: Using GDMO templates, create object classes that represent the security alarm types relevant to your system environment.
- Configure Event Forwarding Discriminator: Set up filters and discrimination logic to ensure security events are transformed into the standard alarm format and forwarded to designated management applications.
- Integrate with Systems Management Application Processes (SMAPs): Ensure that alarms can be reported across management domains using the CMIP (Common Management Information Protocol) or other appropriate protocols as defined by the OSI management framework.
- Test Correlation Rules: If leveraging the amendment’s correlation enhancements, implement logic to reduce alarm flood and identify underlying causes.
Best Practice: Use the standardized alarm types and severity levels without customization wherever possible. This maximizes interoperability when exchanging alarm information with external management systems. The amendment’s severity override mechanism can be used for local adaptation without breaking global consistency.
The standard also recommends that alarm notifications include sufficient context (e.g., time stamp, source of the event, suspected cause) to allow automated correlation and response. Implementers should pay special attention to the information elements defined in the associated ASN.1 modules.
Compliance Notes
Conformance to IEC 10164-7-95 is claimed by an implementation that supports the Security Alarm Reporting Function as defined in the standard and any applicable amendments. The key requirements for conformance are:
- Implementation of the mandatory managed object classes and attributes for at least one security alarm type.
- Support for the alarm reporting service as specified by the associated protocol (CMIP or equivalent).
- Correct representation of alarms using the defined information objects (alarm type, severity, probable cause, etc.).
- If Amendment 1:1996 is claimed, the implementer must also support the additional alarm types and attributes introduced by the amendment.
Conformance testing typically involves verification of the communication protocol (e.g., using PICS proforma) and validation of managed object behavior. The 2004 consolidated edition provides the definitive reference for combined requirements.
Non-Compliance Risk: Failure to correctly interpret severity values or alarm types can lead to misconfiguration when interworking with other OSI management systems. Always reference the latest consolidated edition (2004) to ensure consistency with Amendment 1 requirements.
Frequently Asked Questions
Q: What is the relationship between IEC 10164-7-95 and ITU-T X.736?
A: They are technically identical. ITU-T X.736 (Security Alarm Reporting Function) is aligned word-for-word with ISO/IEC 10164-7. The 1995 edition corresponds to X.736 (1994), and Amendment 1:1996 is also adopted in the ITU-T Recommendation. The 2004 consolidation includes all updates.
Q: What are the main changes introduced by Amendment 1:1996?
A: The amendment adds a new Security Audit Alarm type, provides a severity override attribute, improves alarm correlation logic, and clarifies the interaction with event report management and alarm notification functions. It also makes minor corrections to the GDMO definitions.
Q: Is the 2004 edition a full revision of the standard?
A: No. The 2004 edition is a consolidation of the 1995 edition and Amendment 1:1996, plus editorial corrections. It does not introduce new technical changes. Implementers should use the 2004 edition as the single reference to avoid confusion.
Q: How does IEC 10164-7-95 relate to other parts of ISO/IEC 10164?
A: It depends on the Event Report Management function (Part 5) for notification services and uses the Alarm Notification function (Part 4) for alarm state management. The relationship is described in Annex A of the standard.
© 2026 — Technical article based on International Standard IEC 10164-7-95 / Amd1-1996 (2004). This content is for informational purposes and should not replace the official document for conformance purposes.