![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
The information included in the alarm message depends on the type of event. In all cases, the alarm message contains the operator communication manager (OPCOM) heading, which includes the date and time the alarm was sent. It contains the type of alarm event, the date and time the alarm event occurred, and the user who caused the event, as identified by the user name and process identification (PID). Other information contained in alarm messages is specific to the type of event that the alarm signaled.
Alarms Announcing an Object Access
You can audit successful or unsuccessful access to a protected object by specifying the ACCESS keyword with the /ENABLE qualifier of the SET AUDIT command. You designate the object type with the /CLASS qualifier. See Section 4.7 for a description of object auditing. For example:
%%%%%%%%%%% OPCOM 17-SEP-1994 10:13:20.46 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 17-SEP-1994 10:13:20.09 PID: 30200117 Process name: Hobbit Username: GREG Process owner: [MTI,GREG] Terminal name: RTA1: Image name: DSA1:[GREG.TEST.ACCESS]ACCESS.EXE;50 Object class name: COMMON_EVENT_CLUSTER Object name: FOO Access requested: READ Deaccess key: 808E3380 Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: none
You can also audit access through the use of GRPPRV, READALL, SYSPRV, or BYPASS privilege.
You can audit successful or unsuccessful access to individual protected objects by adding an Alarm ACE or an Audit ACE to an object's ACL and enabling ACL events by specifying the ACL keyword with the /ENABLE qualifier of the SET AUDIT command. For example:
%%%%%%%%%%% OPCOM 12-NOV-1994 10:53:16.34 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id: 19681 Auditable event: Object deletion Event information: file deletion request (IO$_DELETE) Event time: 12-NOV-1994 10:53:16.30 PID: 20200158 Process name: FNORD$RTA2 Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTA2: Image name: $1$DIA1:[SYS0.SYSCOMMON.][SYSEXE]DELETE.EXE Object class name: FILE Object owner: [SYSTEM] Object protection: SYSTEM:RWE, OWNER:RWE, GROUP:, WORLD: File name: _$1$DIA3:[USERS.HUBERT.TMP]FOO.BAR;2 File ID: (4134,20,0) Access requested: DELETE Sequence key: 0005E05F Status: %SYSTEM-F-NOPRIV, insufficient privilege or object protection violation
Alarms Due to Modification of the Authorization
Databases
The Authorization class of security events is enabled by default. All changes to the rights database, the system user authorization file, and the network proxy authorization file immediately produce an audit event message.
Changes to the rights database result from such actions as the creation of a new database or the addition, modification, or removal of an identifier. The audit server also reports when there is a change in a user's identifiers. Note that the alarm message cites the image used to modify the rights database and the change itself. For example:
%%%%%%%%%%% OPCOM 15-DEC-1994 12:27:17.44 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19661 Auditable event: Identifier modified Event time: 15-DEC-1994 12:27:17.43 PID: 00000113 Username: SYSTEM Image name: LASSIE$DMA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE Identifier name: ROBINSON Identifier value: %X80010014 New attributes: RESOURCE
In reporting changes to the system or network user authorization files, the audit server also notes any kind of modification as well as the record modified and the change made. For example:
%%%%%%%%%%% OPCOM 18-DEC-1994 19:53:25.99 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) and security audit (SECURITY) on LASSIE, system id: 19611 Auditable event: System UAF record addition Event time: 18-DEC-1994 19:53:25.98 PID: 20200B25 Username: SYSTEM Image name: $1$DUS0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE Object name: SYS$COMMON:[SYSEXE]SYSUAF.DAT;2 Object type: file User record added: COOPER Fields modified: FLAGS,PWDLIFETIME
The following alarm message is an example of an alarm resulting from a password change:
%%%%%%%%%%% OPCOM 26-SEP-1994 15:12:35.95 %%%%%%%%%%%
Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id:
20300
Auditable event: System UAF record modification
Event time: 26-SEP-1994 15:12:35.92
PID: 52C00119
Process name: Hobbit
Username: GREG
Process owner: [RTB,GREG]
Terminal name: RTA2:
Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]AUTHORIZE.EXE
Object name: CLU$COMMON:<SYSEXE>SYSUAF.DAT;1
Object type: file
User record: GREG
Password: New: 7C5E4DA2 F19176AF
Original: 7C5E4DA2 F19176AF
Password date: New: 0 00:00:00.00
Original: 26-SEP-1994 15:12
Alarms Announcing Break-In Attempts
Break-in attempts are audited by default in the operating system; it audits dialup, local, remote, network and detached break-ins. Passwords used in break-in attempts are not displayed on security operator terminals, but they are logged to the security audit log file and can be displayed with the Audit Analysis utility.
This type of alarm notes the type of break-in attempt, the device user, the origin of attempt (if the break-in type was remote or network), and the parent user name (if the break-in type was detached). For example:
%%%%%%%%%%% OPCOM 7-DEC-1994 14:33:20.69 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Dialup interactive breakin detection Event time: 7-DEC-1994 14:33:20.68 PID: 00000052 Username: SNIDELY Terminal name: _LTA13: (AV47C1/LC-2-10)
Alarms Announcing Creation of an Object
You can audit the creation of objects by specifying the CREATE keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object as well as its object name. For example:
%%%%%%%%%%% OPCOM 17-SEP-1994 10:13:20.29 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object creation Event time: 17-SEP-1994 10:13:20.01 PID: 30200117 Process name: Hobbit Username: HUBERT Process owner: [SST,HUBERT] Terminal name: RTA1: Image name: DSA1:[HUBERT.TEST.ACCESS]ACCESS.EXE;50 Object class name: COMMON_EVENT_CLUSTER Object name: FOO Status: %SYSTEM-S-NORMAL, normal successful completion
Alarms Announcing Deaccess from an Object
You can audit the deaccess of a process from an object by specifying the DEACCESS keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object. For example:
%%%%%%%%%%% OPCOM 17-SEP-1994 10:13:38.34 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object deaccess Event time: 17-SEP-1994 10:13:38.31 PID: 30200117 Object class name: COMMON_EVENT_CLUSTER Deaccess key: 808E3380
Alarms Announcing Deletion of an Object
You can audit the deletion of objects by specifying the DELETE keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm notes the class of the object as well as its object name. For example:
%%%%%%%%%%% OPCOM 17-SEP-1994 10:13:36.17 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Object access Event time: 17-SEP-1994 10:13:36.08 PID: 30200117 Process name: Hobbit Username: HUBERT Process owner: [MTI,HUBERT] Terminal name: RTA1: Image name: DSA1:[HUBERT.TEST.ACCESS]ACCESS.EXE;50 Object class name: COMMON_EVENT_CLUSTER Object name: FOO Access requested: DELETE Status: %SYSTEM-S-NORMAL, normal successful completion Privileges used: none
Alarms Announcing Use of the Install Utility
You can audit the use of the Install utility (to install an image or to remove an installed image) by specifying the INSTALL keyword with the /ENABLE qualifier of the SET AUDIT command. Install alarms identify the type of operation, the name of the image affected by the operation, the flags set by the Install operation, and the privileges used. For example:
%%%%%%%%%%% OPCOM 7-DEC-1994 12:37:49.69 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19661 Auditable event: Installed file addition Event time: 7-DEC-1994 12:37:49.68 PID: 00000113 Username: SYSTEM Object name: LASSIE$DMA0:[SYS0.SYSCOMMON.][SYSEXE]NCP.EXE;1 Object type: file INSTALL flags: /OPEN/HEADER_RESIDENT/SHARED
Alarms Announcing Logins
You can audit successful logins by specifying the LOGIN keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit batch, dialup, local, remote, network, subprocess and detached login classes. This type of alarm notes the class of login, the device used, the origin of the login (if it was remote or network), the parent PID (if the login was subprocess), and the parent user name (if the login was detached). For example:
%%%%%%%%%%% OPCOM 18-DEC-1994 18:49:40.09 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Batch process login Event time: 18-DEC-1994 18:49:40.08 PID: 20002001 Username: LEWIS
Alarms Announcing Login Failures
You can audit login failures by specifying the LOGFAILURE keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit the batch, dialup, local, remote, network, subprocess and detached login failure classes. This type of alarm contains the class of login, the device used, a status message detailing the reason for the failure, the origin of the login (if it was remote or network), the parent PID (if the login was subprocess), and the parent user name (if the login was detached). For example:
%%%%%%%%%%% OPCOM 7-DEC-1994 12:48:43.50 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Network login failure Event time: 7-DEC-1994 12:48:43.49 PID: 0000011D Username: DECNET Remote nodename: TIGER Remote node id: 3218 Remote username: PROBER Status: %LOGIN-F-INVPWD, invalid password
You can audit logouts by specifying the LOGOUT keyword with the /ENABLE qualifier of the SET AUDIT command. You can audit batch, dialup, local, remote, network, subprocess and detached logout classes. This type of alarm contains the class of logout, the device used, the origin of the login (if it was remote or network), and the parent PID (if the login was subprocess). For example:
%%%%%%%%%%% OPCOM 18-DEC-1994 19:14:22.03 %%%%%%%%%%% Message from user AUDIT$SERVER on LASSIE Security alarm (SECURITY) on LASSIE, system id: 19611 Auditable event: Dialup interactive logout Event time: 18-DEC-1994 19:14:22.02 PID: 20200001 Username: DANCER Terminal name: _TTA1:
Alarms Announcing Volume Mounts and Dismounts
You can audit mount or dismount requests by specifying the MOUNT keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm contains the name of the image used to mount or dismount the volume, the device used, the log file recording the operation, the volume name, its UIC and protection code, and the flags set during the operation. For example:
%%%%%%%%%%% OPCOM 18-DEC-1994 17:43:26.94 %%%%%%%%%%% Message from user AUDIT$SERVER on CANINE Security alarm (SECURITY) on CANINE, system id: 19681 Auditable event: Volume mount Event time: 18-DEC-1994 17:43:26.04 PID: 00000038 Username: HOBBIT Image name: CANINE$DUA0:[SYS0.SYSCOMMON.][SYSEXE]VMOUNT.EXE;1 Object name: _CANINE$MUA0: Object type: device Object owner: [DEVO,HOBBIT] Object protection: SYSTEM:RWEDC, OWNER:RWEDC, GROUP:RWEDC, WORLD:RWEDC Logical name: TAPE$DBACK1 Volume name: DBACK1 Mount flags: /OVERRIDE=IDENT/MESSAGE
Alarms Reporting Network Connections
On VAX systems, you can audit the creation and termination of logical links with other nodes in the network when the connections made through DECnet Phase IV. To do so, specify the CONNECTION keyword with the /ENABLE qualifier of the SET AUDIT command. For example:
Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19681 Auditable event: DECnet logical link deleted Event time: 12-NOV-1994 10:54:25.01 PID: 202002EB Process name: FAL_16729 Username: HUBERT_N Process owner: [ACCOUNTS,HUBERT] Image name: $1$DIA1:[SYS0.SYSCOMMON.][SYSEXE]FAL.EXE Remote nodename: JPT Remote node id: 19.130 Remote username: HUBERT DECnet logical link ID: 16729 DECnet object name: FAL DECnet object number: 17 Remote logical link ID: 35429 Status: %SYSTEM-S-NORMAL, normal successful completion
Alarms Reporting Use of Process Control System Services
You can audit use of the process control system services, such as $CREPRC or $GETJPI, by specifying the PROCESS keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports the system service used to control a process, the device used, the name of the process and its user name. For example:
%%%%%%%%%%% OPCOM 25-JUL-1994 16:07:09.20 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 20300 Auditable event: Process suspended ($SUSPND) Event time: 25-JUL-1994 16:07:08.77 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTA1: Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE Status: %SYSTEM-S-NORMAL, normal successful completion Target PID: 30C00126 Target process name: SMISERVER Target username: SYSTEM Target process owner: [SYSTEM]
Alarms Reporting Use of Privilege
You can audit the use of privilege by specifying the PRIVILEGE keyword with the /ENABLE qualifier of the SET AUDIT command. The alarm reports the privilege used and what it was used to do. For example:
%%%%%%%%%%% OPCOM 17-SEP-1994 10:13:20.16 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 19728 Auditable event: Privilege used Event information: PRMCEB used to create permanent common event flag cluster ($ASCEFC) Event time: 17-SEP-1994 10:13:20.01 PID: 30200117 Process name: Hobbit Username: HUBERT Process owner: [MTI,HUBERT] Terminal name: RTA1: Image name: DSA1:[HUBERT.TEST.ACCESS]ACCESS.EXE;50 Event flag cluster name: FOO Privileges used: PRMCEB
Alarms Reporting Modification of a System Parameter
You can audit the modification of a system parameter by specifying the SYSGEN keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports on both the active parameters and the parameters stored on disk. For example:
%%%%%%%%%%% OPCOM 25-JUL-1994 16:09:04.67 %%%%%%%%%%%
Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) on FNORD, system id: 20300
Auditable event: SYSGEN parameter set
Event time: 25-JUL-1994 16:09:04.65
PID: 30C00119
Process name: Hobbit
Username: HUBERT
Process owner: [LEGAL,HUBERT]
Terminal name: RTA1:
Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SYSGEN.EXE
Parameters write: SYS$SYSROOT:[SYSEXE]VAXVMSSYS.PAR;68
Parameters inuse: SYS$SYSROOT:[SYSEXE]VAXVMSSYS.PAR;68
NSA_PAGES: New: 15
Original: 10
Alarms Reporting a Change in System Time
You can audit changes to system time by specifying the TIME keyword with the /ENABLE qualifier of the SET AUDIT command. This type of alarm reports the old and the new system time, the name of the user making the modification, and the device used. For example:
%%%%%%%%%%% OPCOM 25-JUL-1994 16:08:25.23 %%%%%%%%%%% Message from user AUDIT$SERVER on FNORD Security alarm (SECURITY) on FNORD, system id: 20300 Auditable event: System time recalibrated Event time: 25-JUL-1994 16:08:25.21 PID: 30C00119 Process name: Hobbit Username: HUBERT Process owner: [LEGAL,HUBERT] Terminal name: RTA1: Image name: $99$DUA0:[SYS0.SYSCOMMON.][SYSEXE]SET.EXE New system time: 25-JUL-1994 16:08:25.19 Old system time: 25-JUL-1994 16:08:25.18
Alarms Resulting from Execution of the SET AUDIT
Command
All uses of the SET AUDIT command are automatically audited, and you cannot disable it. The following alarm messages are examples of SET AUDIT alarms:
%%%%%%%%%%% OPCOM 12-NOV-1994 10:54:11.91 %%%%%%%%%%%
Message from user AUDIT$SERVER on FNORD
Security alarm (SECURITY) and security audit (SECURITY) on FNORD, system id: 19681
Auditable event: Security alarm state set
Event time: 12-NOV-1994 10:54:11.58
PID: 20200158
Alarm flags: ACL,AUTHORIZATION,CONNECTION
BREAKIN: (DIALUP,LOCAL,REMOTE,NETWORK,DETACHED)
LOGFAIL: (BATCH,DIALUP,LOCAL,REMOTE,NETWORK,
SUBPROCESS,DETACHED)
This glossary provides definitions of security-related terms used in
this guide.
access control: Restrictions on the ability of a
subject (user or process) to use the system or an object in the
computing system. Authentication of the user name and password controls
access to the system, while protection codes, access control lists, and
privileges regulate access to protected objects in that system.
access control entry (ACE): An entry in an access
control list (ACL). Access control entries may specify identifiers and
the access rights to be granted or denied the holders of the
identifiers, default protection for directories, or security details.
ACLs for each object can hold many entries, limited only by overall
space and performance considerations. See also access control list,
identifier.
access control list (ACL): A list that defines the
kinds of access to be granted or denied to users of an object. Access
control lists can be created for all protected objects such as files,
devices, and logical name tables. Each ACL consists of one or more
entries known as access control entries (ACEs). See also access
control entry.
access control string: A character string used in
remote logins. It consists of the user name for the remote account and
the user's password enclosed within quotation marks.
access matrix: A table that lists subjects on one axis
and objects on the other. Each crosspoint in the matrix thus represents
the access that one subject has to one object.
access type: The capability required to perform an
operation on a protected object. OpenVMS security policy can require
multiple capabilities to complete an operation. The most commonly
accessed object, a file, can require read, write, execute, delete, or
control access.
ACE: See access control entry.
ACL: See access control list.
ACL editor: An OpenVMS utility that helps users create
and maintain access control lists. See also access control
list.
alarm: See security alarm.
ALF file: See automatic login.
alphanumeric UIC: A format of a user identification
code (UIC). The group and member names can each contain up to 31
alphanumeric characters, at least one of which is alphabetic. The other
format of a UIC is numeric: it contains a group number and a member
number. See also user identification code, numeric UIC.
attribute: In the security context, a characteristic
of an identifier or the holder of an identifier. Attributes can enhance
or limit the rights granted with an identifier; for example, a user
holding an identifier with the Resource attribute can charge disk space
to the identifier.
audit: See security audit.
auditing: Recording the occurrence of
security-relevant events as they occur on the system and, later,
examining system activity for possible security violations or improper
use of the system. Security-relevant events include activities such as
logins, break-ins, changes to the authorization database, and access to
protected objects. Event messages can be sent as alarms to an operator
terminal or written as audit records to a log file. See also
security audit, security alarm.
audit trail: A pattern of security-relevant activity
sometimes found in the audit log file. The audit log file maintains a
record of security-relevant events, such as access attempts, successful
or not, as required by the authorization database. See also
security audit.
authentication: The act of establishing the identity
of users when they start to use the system. OpenVMS systems (and most
other commercial operating systems) use passwords as the primary
authentication mechanism. See also password.
authorization database: A database that contains the
security attributes of subjects and objects. From these attributes, the
reference monitor determines what kind of access (if any) is authorized.
authorization file: See system user authorization
file.
automatic login: A feature that permits users to log
in without specifying a user name. The operating system associates the
user name with the terminal (or terminal server port) and maintains
these assignments in the file SYS$SYSTEM:SYSALF.DAT, referred to as the
automatic login file or the ALF file.
breach: A break in the system security that results in
access to system resources or objects in violation of the system's
security policy.
break-in attempt: An effort made by an unauthorized
source to gain access to the system. Because the first system access is
achieved through logging in, intrusion attempts primarily refer to
attempts to log in illegally. These attempts focus on supplying
passwords for users known to have accounts on the system through
informed guesses or other trial-and-error methods. See also evasive
action.
C2 system: A U.S. government rating of the security of
an operating system; it identifies an operating system as one that
meets the criteria of a Division C, class 2 system.
capability: A resource to which the system controls access; currently, the only defined capability is the vector processor.
OpenVMS security policy protects vector processors from improper
access. An operation can require use or control access.
captive account: A type of account that confines the
user to the captive login command procedure. The use of Ctrl/Y is
disabled. If errors in the captive command procedure cause the
procedure to terminate and attempt to return the user to the DCL
command level, the process is deleted. (This type of account is
synonymous with a turnkey or tied account.)
common event flag cluster: A set of 32 event flags that enable cooperating processes to post event notifications to each other.
OpenVMS security policy protects common event flag clusters from
improper access. An operation can require associate, delete, or control
access.
control access: The right to modify an object's
security profile. Control access is granted explicitly in an ACL and
implicitly in a protection code. (All users qualifying for system or
owner categories have control access.)
decryption: The process that restores encoded
information to its original unencoded form. The information was encoded
by using encryption.
Default attribute: An option added to an ACE that
indicates the ACE is to be included in the ACL of any files created
within a directory. When the entry is propagated, the Default attribute
is removed from the ACE of the created file. An Identifier ACE with the
Default attribute has no effect on access. See also access control
entry, Identifier ACE.
device: A class of peripherals connected to a processor that are capable of receiving, storing, or transmitting data.
OpenVMS security policy protects devices from improper access. An
operation can require read, write, physical, logical, or control access.
discretionary controls: Security controls that are
applied at the user's option; that is, they are not required. Access
control lists (ACLs) are typical of such optional security features.
Discretionary controls are the opposite of mandatory controls.
disk scavenging: Any method of obtaining information
from a disk that the owner intended to discard. The information,
although no longer accessible to the original owner by normal means,
retains a sufficient amount of its original magnetic encoding that it
can be retrieved and used by one of the scavenging methods. See also
erase-on-allocate, erase-on-delete, erasure
pattern.
6346P028.HTM OSSG Documentation 22-NOV-1996 13:05:35.83
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.