Audit policies

Auditing user actions in a control system helps answer "who changed this process variable, when, and why?"
In an industry that must comply with governmental regulations, such as U.S. Government 21 CFR Part 11, the plant must be able to answer this question. The answer is also important if the plant manufactures products with critical tolerances, or if unmanaged changes could negatively affect product quality or risk consumer safety.
An audit trail records:
  • The specific, authenticated user who is authorized to access the manufacturing system
  • The action taken—typically an operation that affects the manufacturing control system or that creates, modifies, or deletes some element of the manufacturing process
  • The resource—an object such as a
    PLC-5®
    , application, tag, or command, on which the user performs an action
  • The computer from which the user performed the action
  • The date and time when the user performed the action
Like other
FactoryTalk
 policy settings, audit policies are managed separately in the network directory and the local directory.
Auditing changes to the system configuration, and to the control system
The
FactoryTalk
 system generates and sends audit messages to
FactoryTalk Diagnostics
. A system-wide policy setting controls whether audit records are generated and logged. If the system policy is enabled, then
FactoryTalk Diagnostics
 routes the audit messages to various logging destinations, including the
FactoryTalk® Audit
 Log. If the system policy is disabled, then
FactoryTalk Diagnostics
 ignores audit messages generated by
FactoryTalk
 components and
FactoryTalk
 products and does not route them for logging.
Each
FactoryTalk
 product defines its own rules for auditing changes. This means that the messages that appear in the
FactoryTalk Diagnostics
 Viewer vary, depending on what products are installed. If the setting
Audit changes to configuration and control system
 is enabled, audit messages are generated when any configuration and control system changes occur across the
FactoryTalk
 system.
Auditing security access failures and successes
Whenever a user attempts to access a secured resource,
FactoryTalk Security
 can generate audit messages if the user was denied or granted access.
For example, suppose an area named Ingredients is secured so that only members of the OperatorsLine5 group can write to the area. If the
Audit object access success
 policy is enabled, every time an operator is granted write access to this area, a message is logged to
FactoryTalk Diagnostics
. If
Audit object access failure policy
is enabled, every time an operator is refused
Write
 access to this area, a message is logged to
FactoryTalk Diagnostics
.
Object access failures do not necessarily represent deliberate attempts to compromise the security of the system. For example, an object access failure message is logged if a user is denied
Configure Security
 permission and right-clicks the
Users and Groups
 folder.
Auditing security access success can consume large amounts of system resources. Enable this policy only when necessary, for example, while testing the system, or if required in industries that must comply with governmental regulations.
Examples of messages for auditing security access failures and successes:
  • User NETWORK\JSMITH attempted to perform action COMMON\WRITE from NETWORK\DOMAIN\COMPUTER5 on [
    OPC
     data server][RNA://$Global/Norms Bakery/Ingredients/RecipeDataServer] and was granted access
  • User NETWORK\JSMITH attempted to perform action COMMON\CONFIGURE SECURITY from NETWORK\DOMAIN\COMPUTER5 on [directory][$System] and was denied access
Provide Feedback
Have questions or feedback about this documentation? Please submit your feedback here.
Normal