ESA Error Handling

• 1: Common ESA Logs
• 2: Common ESA Errors
• 3: Understanding the Insight indexes
• 4: Understanding the index field values
• 5: Index entries
• 6: Log return codes
• 7: Protectors security log codes
• 8: Policy audit codes
• 9: Additional log information

1 - Common ESA Logs

2 - Common ESA Errors

Patch Signing

From v10.0.0, all the packages, including the Protegrity developed packages, are signed by Protegrity. This ensures the integrity of the software being installed.

The following errors may occur while uploading the patch using Web UI or CLI Manager.

#The patch is signed by Protegrity signing key and the verification key is expired

Issue: This issue occurs if the verification key is expired, the following error message appears:
Error: Patch signature(s) expired. Would you like to continue installation?

Workaround:

• Click Yes to install the patch. The patch gets installed successfully.
• Click No. The patch installation gets terminated.

For more information about the Protegrity signed patch, contact Protegrity Support.

#The patch is not signed by Protegrity signing key

Issue: This issue occurs if the patch is not signed by Protegrity signing key.
Error: Signatures not found. Aborting

Workaround: Click Exit to terminate the installation process.
It is recommended to use a Protegrity signed patch.

For more information about the Protegrity signed patch, contact Protegrity Support.

Disk Space

#Insufficient disk space in the /var/log directory

Issue: This issue occurs if the disk space in the /var/log directory is insufficient.
Error: Unable to install the patch. The required disk space is insufficient for the following partition: /var/log/

Workaround: Ensure that at least 20% disk space in the /var/log directory is available to install the patch successfully.

#Insufficient disk space in the /opt/ directory

Issue: This issue occurs if the disk space in the /opt directory is insufficient.
Error: Unable to install the patch. The required disk space is insufficient for the following partition: /opt/

Workaround: Ensure that the available disk space in the /opt/tmp directory is at least twice the patch size.

#Insufficient disk space in the /OS directory

Issue: This issue occurs if the disk space in the /OS directory is insufficient.

Workaround: Ensure that at least 40% disk space in the /OS directory is available to install the patch successfully.

The space used in the OS(/) partition should not be more than 60%. If the space used is more than 60%, then you must clean up the OS(/) partition before proceeding with the patch installation process. For more information about cleaning up the OS(/) partition, refer to the documentation available at the following link.
https://my.protegrity.com/knowledge/ka04W000000nSxJQAU/

Miscellaneous

Unable to export the information while executing the cluster task using the IP address of the node.

Issue: This might occur if the task is executed using the IP address of the cluster task instead of the Hostname.

Workaround: To resolve this issue, ensure that the IP address of the cluster node is replaced with the Hostname in the task.

For more information about executing the cluster task, refer Scheduling Configuration Export to Cluster Tasks.

Basic Authentication

If you try to perform operations, such as, joining a cluster, exporting data/ configuration to a remote appliance, and so on , the operation fails with the following error:
Errorcode: 403

Issue: This issue occurs if the Basic Authentication is disabled, and you try to perform any of the following operations.

• Joining an existing cluster
• Establishing set ESA Communication
• Exporting data/configuration to a remote appliance
• Work with RADIUS authentication

Workaround: Ensure that the Can Create JWT Token permission is assigned to the role. If the Can Create JWT Token permission is not assigned to the role of the required user, then the operation fails.

To verify the Can Create JWT Token permission, from the ESA Web UI navigate to Settings > Users > Roles.

3 - Understanding the Insight indexes

All the Appliances and Protectors send logs to Insight. The logs from the Audit Store are displayed on the Discover screen of the Audit Store Dashboards. Here, you can view the different fields logged. In addition to viewing the data, these logs serve as input for Insight to analyze the health of the system and to monitor the system for providing security. These logs are stored in the Audit index with the name, such as, pty_insight_analytics_audit_9.2-*. To refer to old and new audit indexes, the alias pty_insight_*audit_* is used.

The /var/log/asdashboards.log file is empty. The init.d logs for the Audit Store Dashboards are available in /var/log/syslog. The container-related logs are available in /var/log/docker/auditstore_dashboards.log.

You can view the Discover screen by logging into the ESA and navigating to Audit Store > Dashboard > Open in new tab, select Discover from the menu, and select a time period such as Last 30 days. The Discover screen appears.

The following table lists the various indexes and information about the data contained in the index. You can view the index list by logging into the ESA, and navigating to Audit Store > Cluster Management > Overview > Indices. Indexes can be created or deleted. However, deleting an index will lead to a permanent loss of data in the index. If the index was not backed up earlier, then the logs from the index deleted cannot be recreated or retrieved.

4 - Understanding the index field values

Common Logging Information

These logging fields are common with the different log types generated by Protegrity products.

Note: These common fields are used across all log types.

Additional_Info

These descriptions are used for all types of logs.

Process

This section describes the properties of the process that created the log. For example, the protector or the rputils.

Origin

This section describes the origin of the log, that is, from where the log came from and when it was generated.

Protector

This section describes the Protector that generated the log. For example, the vendor and the version of the Protector.

Note: For more information about the Protector vendor, family, and version, refer here.

Protection

This section describes the protection that was done, what was done, the result of the operation, where it was done, and so on.

Client

This section describes from where the log came from.

Policy

This section describes the information about the policy.

Metering

This section describes the metering log information.

Note: These fields are applicable for Protectors up to v7.2.1. If you upgraded your ESA from v7.2.1 to v9.1.0.0 and migrated the metering audits, then these fields contain data.

Metering is not supported for Protectors v8.0.0.0 and above and these are fields will be blank.

Signature

This section handles the signing of the log. The key that was used to sign the log and the actual checksum that was generated.

Verification

This section describes the log information generated for a failed signature verification job.

5 - Index entries

Audit index

The log types of protection, metering, audit, and security are stored in the audit index. These log are generated during security operations. The logs generated by protectors are stored in the audit index with the name as shown in the following table for the respective version.

The following parameters are configured for the index rollover in v10.0.0:

• Index age: 30 days
• Document count: 200,000,000
• Index size: 5 GB

Protection logs

These logs are generated by protectors during protecting, unprotecting, and reprotecting data operations. These logs are generated by protectors, such as, DSG.

Use the following query in Discover to view these logs.

logtype:protection

A sample log is shown here:

 {
    "process": {
      "thread_id": "1227749696",
      "module": "coreprovider",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "4190",
      "user": "user4",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "level": "SUCCESS",
    "signature": {
      "key_id": "11a8b7d9-1621-4711-ace7-7d71e8adaf7c",
      "checksum": "43B6A4684810383C9EC1C01FF2C5CED570863A7DE609AE5A78C729A2EF7AB93A"
    },
    "origin": {
      "time_utc": "2024-09-02T13:55:17.000Z",
      "hostname": "hostname1234",
      "ip": "10.39.3.156"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "pcc_version": "3.6.0.1",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1"
    },
    "protection": {
      "dataelement": "TE_A_S13_L1R2_Y",
      "datastore": "DataStore",
      "audit_code": 6,
      "operation": "Protect",
      "policy_user": "user1"
    },
    "index_node": "protegrity-esa399/10.39.1.23",
    "tiebreaker": 210,
    "logtype": "Protection",
    "additional_info": {
      "description": "Data protect operation was successful"
    },
    "index_time_utc": "2024-09-02T13:55:24.766355224Z",
    "ingest_time_utc": "2024-09-02T13:55:17.678Z",
    "client": {},
    "correlationid": "cm0f1jlq700gbzb19cq65miqt"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-02T13:55:17.000Z"
    ],
    "index_time_utc": [
      "2024-09-02T13:55:24.766Z"
    ],
    "ingest_time_utc": [
      "2024-09-02T13:55:17.678Z"
    ]
  },
  "sort": [
    1725285317000
  ]

The above example contains the following information:

• additional_info
• origin
• protector
• protection
• process
• client
• protector
• signature

For more information about the various fields, refer here.

Metering logs

These logs are generated by protectors of prior to 8.0.0.0. These logs are not generated by latest protectors.

Use the following query in Discover to view these logs.

logtype:metering

For more information about the various fields, refer here.

Audit logs

These logs are generated when the rule set of the DSG protector gets updated.

Use the following query in Discover to view these logs.

logtype:audit

A sample log is shown here:

 {
   "additional_info.description": "User admin modified default_80 tunnel successfully ",
   "additional_info.title": "Gateway : Tunnels : Tunnel 'default_80' Modified",
   "client.ip": "192.168.2.20",
   "cnt": 1,
   "index_node": "protegrity-esa746/192.168.1.10",
   "index_time_utc": "2024-01-24T13:30:17.171646Z",
   "ingest_time_utc": "2024-01-24T13:29:35.000000000Z",
   "level": "Normal",
   "logtype": "Audit",
   "origin.hostname": "protegrity-cg406",
   "origin.ip": "192.168.2.20",
   "origin.time_utc": "2024-01-24T13:29:35.000Z",
   "process.name": "CGP",
   "process.user": "admin",
   "tiebreaker": 2260067,
   "_id": "ZTdhNzFmMTUtMWZlOC00MmY4LWJmYTItMjcwZjMwMmY4OGZh",
   "_index": "pty_insight_audit_v9.1-2024.01.23-000006"
 }

This example includes data from each of the following groups defined in the index:

• additional_info
• client
• origin
• process

For more information about the various fields, refer here.

Security logs

These logs are generated by security events of the system.

Use the following query in Discover to view these logs.

logtype:security

For more information about the various fields, refer here.

Troubleshooting index

The log types of application, kernel, system, and verification logs are stored in the troubleshooting index. These logs helps you understand the working of the system. The logs stored in this index are essential when the system is down or has issues. This is the pty_insight_analytics_troubleshooting index. The index pattern for viewing these logs in Discover is pty_insight_*troubleshooting_*.

The following parameters are configured for the index rollover:

• Index age: 30 days
• Document count: 200,000,000
• Index size: 5 GB

Application Logs

These logs are generated by Protegrity servers and Protegrity applications.

Use the following query in Discover to view these logs.

logtype:application

A sample log is shown here:

{
    "process": {
      "name": "hubcontroller"
    },
    "level": "INFO",
    "origin": {
      "time_utc": "2024-09-03T10:02:34.597000000Z",
      "hostname": "protegrity-esa503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-esa503/10.37.4.12",
    "tiebreaker": 16916,
    "logtype": "Application",
    "additional_info": {
      "description": "GET /dps/v1/deployment/datastores | 304 | 127.0.0.1 | Protegrity Client | 8ms | "
    },
    "index_time_utc": "2024-09-03T10:02:37.314521452Z",
    "ingest_time_utc": "2024-09-03T10:02:36.262628342Z",
    "correlationid": "cm0m9gjq500ig1h03zwdv6kok"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:02:34.597Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:02:37.314Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:02:36.262Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Application@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357754597
  ]

The above example contains the following information:

• additional_info
• origin
• process

For more information about the various fields, refer here.

Kernel logs

These logs are generated by the kernel and help you analyze the working of the internal system. Some of the modules that generate these logs are CRED_DISP, KERNEL, USER_CMD, and so on.

Use the following query in Discover to view these logs.

logtype:Kernel

For more information and description about the components that can generate kernel logs, refer here.

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "CRED_DISP"
    },
    "origin": {
      "time_utc": "2024-09-03T10:02:55.059999942Z",
      "hostname": "protegrity-esa503",
      "ip": "10.37.4.12"
    },
    "cnt": "1",
    "index_node": "protegrity-esa503/10.37.4.12",
    "tiebreaker": 16964,
    "logtype": "Kernel",
    "additional_info": {
      "module": "pid=38236",
      "description": "auid=4294967295 ses=4294967295 subj=unconfined msg='op=PAM:setcred grantors=pam_rootok acct=\"rabbitmq\" exe=\"/usr/sbin/runuser\" hostname=? addr=? terminal=? res=success'\u001dUID=\"root\" AUID=\"unset\"",
      "procedure": "uid=0"
    },
    "index_time_utc": "2024-09-03T10:02:59.315734771Z",
    "ingest_time_utc": "2024-09-03T10:02:55.062254541Z"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:02:55.059Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:02:59.315Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:02:55.062Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Kernel@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357775059
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• origin
• process

For more information about the various fields, refer here.

System logs

These logs are generated by the operating system and help you analyze and troubleshoot the system when errors are found.

Use the following query in Discover to view these logs.

logtype:System

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

 {
    "process": {
      "name": "ESAPAP",
      "version": "10.0.0+2412",
      "user": "admin"
    },
    "level": "Low",
    "origin": {
      "time_utc": "2024-09-03T10:00:34.000Z",
      "hostname": "protegrity-esa503",
      "ip": "10.37.4.12"
    },
    "cnt": "1",
    "index_node": "protegrity-esa503/10.37.4.12",
    "tiebreaker": 16860,
    "logtype": "System",
    "additional_info": {
      "description": "License is due to expire in 30 days. The validity of license has been acknowledged by the user. (web-user 'admin' , IP: '10.87.2.32')",
      "title": "Appliance Info : License is due to expire in 30 days. The validity of license has been acknowledged by the user. (web-user 'admin' , IP: '10.87.2.32')"
    },
    "index_time_utc": "2024-09-03T10:01:10.113708469Z",
    "client": {
      "ip": "10.37.4.12"
    },
    "ingest_time_utc": "2024-09-03T10:00:34.000000000Z"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:00:34.000Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:01:10.113Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:00:34.000Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@System@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725357634000
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• origin
• process

For more information about the various fields, refer here.

Verification logs

These log are generated by Insight on the ESA when a signature verification fails.

Use the following query in Discover to view these logs.

logtype:Verification

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "insight.pyc",
      "id": 45277
    },
    "level": "Info",
    "origin": {
      "time_utc": "2024-09-03T10:14:03.120342Z",
      "hostname": "protegrity-esa503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-esa503/10.37.4.12",
    "tiebreaker": 17774,
    "logtype": "Verification",
    "additional_info": {
      "module": ".signature.job_executor",
      "description": "",
      "procedure": "__log_failure"
    },
    "index_time_utc": "2024-09-03T10:14:03.128435514Z",
    "ingest_time_utc": "2024-09-03T10:14:03.120376Z",
    "verification": {
      "reason": "SV_VERIFY_RESPONSES.INVALID_CHECKSUM",
      "job_name": "System Job",
      "job_id": "9Vq1opEBYpV14mHXU9hW",
      "index_name": "pty_insight_analytics_audits_10.0-2024.08.30-000001",
      "doc_id": "JI5bt5EBMqY4Eog-YY7C"
    }
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:14:03.120Z"
    ],
    "index_time_utc": [
      "2024-09-03T10:14:03.128Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:14:03.120Z"
    ]
  },
  "highlight": {
    "logtype": [
      "@opensearch-dashboards-highlighted-field@Verification@/opensearch-dashboards-highlighted-field@"
    ]
  },
  "sort": [
    1725358443120
  ]

This example includes data from each of the following groups defined in the index:

• additional_info
• process
• origin
• verification

For more information about the various fields, refer here.

Policy log index

The log type of policy is stored in the policy log index. They include logs for the policy-related operations, such as, when the policy is updated. The index pattern for viewing these logs in Discover is pty_insight_*policy_log_*.

The following parameters are configured for the policy log index:

• Index age: 30 days
• Document count: 200,000,000
• Index size: 5 GB

Use the following query in Discover to view these logs.

logtype:policyLog

For a list of components and modules and the type of logs they generate, refer here.

A sample log is shown here:

{
    "process": {
      "name": "hubcontroller",
      "user": "service_admin",
      "version": "1.8.0+6.g5e62d8.1.8"
    },
    "level": "Low",
    "origin": {
      "time_utc": "2024-09-03T08:29:14.000000000Z",
      "hostname": "protegrity-esa503",
      "ip": "10.37.4.12"
    },
    "cnt": 1,
    "index_node": "protegrity-esa503/10.37.4.12",
    "tiebreaker": 10703,
    "logtype": "Policy",
    "additional_info": {
      "description": "Data element created. (Data Element 'TE_LASCII_L2R1_Y' created)"
    },
    "index_time_utc": "2024-09-03T08:30:31.358367506Z",
    "client": {
      "ip": "10.87.2.32",
      "username": "admin"
    },
    "ingest_time_utc": "2024-09-03T08:29:30.017906235Z",
    "correlationid": "cm0m64iap009r1h0399ey6rl8",
    "policy": {
      "severity": "Low",
      "audit_code": 150
    }
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T08:29:14.000Z"
    ],
    "index_time_utc": [
      "2024-09-03T08:30:31.358Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T08:29:30.017Z"
    ]
  },
  "highlight": {
    "additional_info.description": [
      "(Data Element '@opensearch-dashboards-highlighted-field@DE@/opensearch-dashboards-highlighted-field@' created)"
    ]
  },
  "sort": [
    1725352154000
  ]

The example contains the following information:

• additional_info
• origin
• policy
• process

For more information about the various fields, refer here.

Policy Status Dashboard index

The policy status dashboard index contains information for the Policy Status Dashboard. It holds the policy and trusted application deployment status information. The index pattern for viewing these logs in Discover is pty_insight_analytics*policy_status_dashboard_.

{
    "logtype": "Status",
    "process": {
      "thread_id": "2458884416",
      "module": "rpstatus",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "2852",
      "user": "root",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "origin": {
      "time_utc": "2024-09-03T10:24:19.000Z",
      "hostname": "ip-10-49-2-49.ec2.internal",
      "ip": "10.49.2.49"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "datastore": "DataStore",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0"
    },
    "ingest_time_utc": "2024-09-03T10:24:19.510Z",
    "status": {
      "core_correlationid": "cm0f1jlq700gbzb19cq65miqt",
      "package_correlationid": "cm0m1tv5k0019te89e48tgdug"
    },
    "policystatus": {
      "type": "TRUSTED_APP",
      "application_name": "APJava_sample",
      "deployment_or_auth_time": "2024-09-03T10:24:19.000Z",
      "status": "WARNING"
    }
  },
  "fields": {
    "policystatus.deployment_or_auth_time": [
      "2024-09-03T10:24:19.000Z"
    ],
    "origin.time_utc": [
      "2024-09-03T10:24:19.000Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:24:19.510Z"
    ]
  },
  "sort": [
    1725359059000
  ]

The example contains the following information:

• additional_info
• origin
• protector
• policystatus
• policy
• process

Protectors status index

The protector status logs generated by protectors of v10.0.0 are stored in this index. The index pattern for viewing these logs in Discover is pty_insight_analytics_protectors_status_*.

The following parameters are configured for the index rollover:

• Index age: 30 days
• Document count: 200,000,000
• Index size: 5 GB

Use the following query in Discover to view these logs.

logtype:status

A sample log is shown here:

{
   "logtype":"Status",
   "process":{
      "thread_id":"2559813952",
      "module":"rpstatus",
      "name":"java",
      "pcc_version":"3.6.0.1",
      "id":"1991",
      "user":"root",
      "version":"10.0.0.2.91.5ec4b8b",
      "core_version":"2.1.0-alpha+24.g7fc71.2.1",
      "platform":"Linux_x64"
   },
   "origin":{
      "time_utc":"2024-07-30T07:22:41.000Z",
      "hostname":"ip-10-39-3-218.ec2.internal",
      "ip":"10.39.3.218"
   },
   "cnt":1,
   "protector":{
      "vendor":"Java",
      "datastore":"ESA-10.39.2.7",
      "family":"sdk",
      "version":"10.0.0.2.91.5ec4b8b"
   },
   "ingest_time_utc":"2024-07-30T07:22:41.745Z",
   "status":{
      "core_correlationid":"clz79lc2o004jmb29neneto8k",
      "package_correlationid":"clz82ijw00037k790oxlnjalu"
   }
}

The example contains the following information:

• additional_info
• origin
• policy
• protector

Protector Status Dashboard index

The protector status dashboard index contains information for the Protector Status Dashboard. It holds the protector status information. The index pattern for viewing these logs in Discover is pty_insight_analytics*protector_status_dashboard_.

A sample log is shown here:

{
    "logtype": "Status",
    "process": {
      "thread_id": "2458884416",
      "module": "rpstatus",
      "name": "java",
      "pcc_version": "3.6.0.1",
      "id": "2852",
      "user": "root",
      "version": "10.0.0-alpha+13.gef09.10.0",
      "core_version": "2.1.0+17.gca723.2.1",
      "platform": "Linux_x64"
    },
    "origin": {
      "time_utc": "2024-09-03T10:24:19.000Z",
      "hostname": "ip-10-49-2-49.ec2.internal",
      "ip": "10.49.2.49"
    },
    "cnt": 1,
    "protector": {
      "vendor": "Java",
      "datastore": "DataStore",
      "family": "sdk",
      "version": "10.0.0-alpha+13.gef09.10.0"
    },
    "ingest_time_utc": "2024-09-03T10:24:19.510Z",
    "status": {
      "core_correlationid": "cm0f1jlq700gbzb19cq65miqt",
      "package_correlationid": "cm0m1tv5k0019te89e48tgdug"
    },
    "protector_status": "Warning"
  },
  "fields": {
    "origin.time_utc": [
      "2024-09-03T10:24:19.000Z"
    ],
    "ingest_time_utc": [
      "2024-09-03T10:24:19.510Z"
    ]
  },
  "sort": [
    1725359059000
  ]

The example contains the following information:

• additional_info
• origin
• protector
• process

DSG transaction metrics

The table in this section lists the details for the various parameters generated by DSG transactions. The DSG transaction logs are stored in the pty_insight_analytics_dsg_transaction_metrics_9.2 index file. The index pattern for viewing these logs in Discover is pty_insight_analytics_dsg_transaction_metrics_*. The following parameters are configured for the index rollover:

• Index age: 1 day
• Document count: 10,000,000
• Index size: 1 GB

This index stores the following fields.

* -The origin_time_utc and logtype parameters will only be displayed on the Audit Store Dashboards.

For more information about the transaction metric logs, refer to the section Transaction Metrics Logging in the Protegrity Data Security Gateway User Guide 3.2.0.0.

Scheduled tasks are available for deleting this index. You can configure and enable the scheduled task to free up the space used by old index files that you do not require.

For more information about scheduled tasks, refer here.

DSG usage metrics

This section describes the codes associated with the following DSG usage metrics:

• Tunnels usage data (Version 0)
• Service usage data (Version 0)
• Profile usage data (Version 0)
• Rules usage data (Version 0)

The table in this sub sections lists the details for the various parameters generated while using the DSG. The DSG usage metrics logs are stored in the pty_insight_analytics_dsg_usage_metrics_9.2 index file. The index pattern for viewing these logs in Discover is pty_insight_analytics_dsg_usage_metrics_*. The following parameters are configured for the index rollover:

• Index age: 1 day
• Document count: 3,500,000
• Index size: 1 GB

For more information about the usage metrics, refer to the Protegrity Data Security Gateway User Guide 3.2.0.0.

Scheduled tasks are available for deleting this index. You can configure and enable the scheduled task to free up the space used by old index files that you do not require.

For more information about scheduled tasks, refer here.

Tunnels usage data

The table in this section describes the usage metric for Tunnels.

A sample is provided here:

{"metrics_type":"Tunnel","version":0,"tunnel_type":"HTTP","cnt":1,"logtype":"Application","origin":{"time_utc":"2023-04-13T12:28:18Z"},"previous_timestamp":"2023-04-13T12:28:08Z","tunnel_id":"140361619513360","checksum":"4139677074","uptime":620.8048927783966,"bytes_processed":401,"frontend_bytes_processed":401,"backend_bytes_processed":0,"previous_bytes_processed":401,"previous_frontend_bytes_processed":401,"previous_backend_bytes_processed":0,"total_bytes_processed":1203,"total_frontend_bytes_processed":1203,"total_backend_bytes_processed":0,"message_count":1,"previouse_message_count":1,"total_message_count":3}

Services usage data

The table in this section describes the usage metric for Services.

A sample is provided here:

{"metrics_type":"Service","version":0,"service_type":"REST-API","cnt":1,"logtype":"Application","origin":{"time_utc":"2023-04-13T12:28:18Z"}, "previous_timestamp":"2023-04-13T12:28:08Z", "service_id":"140361548704016","checksum":"3100121694","tunnel_checksum":"4139677074","calls":401,"frontend_calls":401,"backend_calls":0,"previous_calls":401,"previous_frontend_calls":401,"previous_backend_calls":0,"total_calls":1203,"total_frontend_calls":1203,"total_backend_calls":0,"bytes_processed":2,"frontend_bytes_processed":1,"backend_bytes_processed":1,"previous_bytes_processed":2,"previous_frontend_bytes_processed":1,"previous_backend_bytes_processed":1,"total_bytes_processed":6,"total_frontend_bytes_processed":3,"total_backend_bytes_processed":3}

Profile usage data

The table in this section describes the usage metric for Profile.

A sample is provided here:

{"metrics_type":"Profile","version":0,"cnt":1,"logtype":"Application","origin":{"time_utc":"2023-04-13T12:28:18Z"},"previous_timestamp":"2023-04-13T12:28:08Z","profile_id":"140361548999248","checksum":"3504922421","parent_checksum":"3100121694","calls":2,"previous_calls":2,"total_calls":6,"profile_reference_count":0,"previous_profile_reference_count":0,"total_profile_reference_count":0,"bytes_processed":802,"previous_bytes_processed":802,"total_bytes_processed":2406,"elapsed_time_sample_count":2,"elapsed_time_average":221078.5,"total_elapsed_time_sample_count":6,"total_elapsed_time_sample_average":245797.0}

Rules usage data

The table in this section describes the usage metric for Rules.

A sample is provided here:

{"metric_type":"Rule","version":0,"rule_type":"Extract","codec":"Set User Identity","cnt":1,"logtype":"Application","origin":{"time_utc":"2023-04-13T12:28:18Z"},"previous_timestamp":"2023-04-13T12:28:08Z","broken":false,"domain_name_rewrite":false,"rule_id":"140361553016464","rule_checksum":"932129179","parent_checksum":"3504922421","calls":1,"previous_calls":1,"total_calls":3,"profile_reference_count":0,"previous_profile_reference_count":0,"total_profile_reference_count":0,"bytes_processed":1,"previous_bytes_processed":1,"total_bytes_processed":3,"elapsed_time_sample_count":1,"elapsed_time_sample_average":406842.0,"total_elapsed_time_sample_count":3,"total_elapsed_time_sample_average":451163.6666666667}

DSG error metrics

The table in this section lists the details for the various parameters generated for the DSG Error Metrics. The DSG Error Metrics logs are stored in the pty_insight_analytics_dsg_error_metrics_9.2 index file. The index pattern for viewing these logs in Discover is pty_insight_analytics_dsg_error_metrics_*. The following parameters are configured for the index rollover:

• Index age: 1 day
• Document count: 3,500,000
• Index size: 1 GB

This index stores the following fields.

* -The origin_time_utc and logtype parameters will only be displayed on the Audit Store Dashboards.

For more information about the error metric logs, refer to the Protegrity Data Security Gateway User Guide 3.2.0.0.

Scheduled tasks are available for deleting this index. You can configure and enable the scheduled task to free up the space used by old index files that you do not require.

For more information about scheduled tasks, refer here.

Miscellaneous index

The logs that are not added to the other indexes are captured and stored in the miscellaneous index. The index pattern for viewing these logs in Discover is pty_insight_analytics_miscellaneous_*.

This index should not contain any logs. If any logs are visible in this index, then kindly contact Protegrity support.

The following parameters are configured for the index rollover:

• Index age: 7 days
• Document count: 3,500,000
• Index size: 200 mb

Use the following query in Discover to view these logs.

logtype:miscellaneous;

Scheduled tasks are available for deleting this index. You can configure and enable the scheduled task to free up the space used by old index files that you do not require.

For more information about scheduled tasks, refer here.

6 - Log return codes

7 - Protectors security log codes

The security logging level can be configured when a data security policy is created in the Policy management in ESA. If logging level is set to audit successful and audit failed, then both successful and failed Unprotect/Protect/Reprotect/Delete operations will be logged.

You can define the server where these security audit logs will be sent to. You can do that by modifying the Log Server configuration section in pepserver.cfg file.

If you configure to send protector security logs to ESA, you will be able view them in Discover, by logging into the ESA and navigating to Audit Store > Dashboard > Open in new tab, select Discover from the menu, and select a time period such as Last 30 days. The following table displays the logs sent by protectors.

8 - Policy audit codes

9 - Additional log information

These are values for understanding the values that are displayed in the log records.

Log levels

Most events on the system generate logs. The level of the log helps you understand whether the log is just an information message or denotes some issue with the system. The log message and the log level allows you to understand more about the working of the system and also helps you identify and troubleshoot any system issues.

Protection logs: These logs are generated for Unprotect, Reprotect, and Protect (URP) operations.

• SUCCESS: This log is generated for a successful URP operation.
• WARNING: This log is generated if a user does not have access and the operation is unprotect.
• EXCEPTION: This log is generated if a user does not have access, the operation is unprotect, and the return exception property is set.
• ERROR: This log is generated for all other issues.

Application logs: These logs are generated by the application. The log level denotes the severity level of the log, however, levels 1 and 6 are used for the log configuration.

• 1: OFF. This level is used to turn logging off.
• 2: SEVERE. This level indicates a serious failure that prevents normal program execution.
• 3: WARNING. This level indicates a potential problem or an issue with the system.
• 4: INFO. This level is used to display information messages about the application.
• 5: CONFIG. This level is used to display static configuration information that is useful during debugging.
• 6: ALL. This level is used to log all messages.

Policy logs: These logs are used for the policy logs.

• LOWEST
• LOW
• NORMAL
• HIGH
• CRITICAL
• N/A

Protector information

The information displayed in the Protector-related fields of the audit log are listed in the table.

Protectors having CORE version 1.2.2+42.g01eb3.1.2 and higher are compatible with ESA v10.0.0. For more version-related information, refer to the Product Compatibility on My.Protegrity. The protector family might display the process.name for some protectors. This will be fixed in a later release.

Modules and components and the log type

Some of the components and modules and the logtype that they generate are provided in the following table.

For more information and description about the components that can generate kernel logs, refer here.

Kernel logs

This section lists the various kernel logs that are generated.

Note: This list is compiled using information from https://pmhahn.github.io/audit/.

User and group account management:

• ADD_USER: A user-space user account is added.
• USER_MGMT: The user-space management data.
• USER_CHAUTHTOK: A user account attribute is modified.
• DEL_USER: A user-space user is deleted.
• ADD_GROUP: A user-space group is added.
• GRP_MGMT: The user-space group management data.
• GRP_CHAUTHTOK: A group account attribute is modified.
• DEL_GROUP: A user-space group is deleted.

User login live cycle events:

• CRYPTO_KEY_USER: The cryptographic key identifier used for cryptographic purposes.
• CRYPTO_SESSION: The parameters set during a TLS session establishment.
• USER_AUTH: A user-space authentication attempt is detected.
• LOGIN: The user log in to access the system.
• USER_CMD: A user-space shell command is executed.
• GRP_AUTH: The group password is used to authenticate against a user-space group.
• CHUSER_ID: A user-space user ID is changed.
• CHGRP_ID: A user-space group ID is changed.
• Pluggable Authentication Modules (PAM) Authentication:
  • USER_LOGIN: A user logs in.
  • USER_LOGOUT: A user logs out.
• PAM account:
  • USER_ERR: A user account state error is detected.
  • USER_ACCT: A user-space user account is modified.
  • ACCT_LOCK: A user-space user account is locked by the administrator.
  • ACCT_UNLOCK: A user-space user account is unlocked by the administrator.
• PAM session:
  • USER_START: A user-space session is started.
  • USER_END: A user-space session is terminated.
• Credentials:
  • CRED_ACQ: A user acquires user-space credentials.
  • CRED_REFR: A user refreshes their user-space credentials.
  • CRED_DISP: A user disposes of user-space credentials.

Linux Security Model events:

• DAC_CHECK: The record discretionary access control (DAC) check results.
• MAC_CHECK: The user space Mandatory Access Control (MAC) decision is made.
• USER_AVC: A user-space AVC message is generated.
• USER_MAC_CONFIG_CHANGE:
• SELinux Mandatory Access Control:
  • AVC_PATH: dentry and vfsmount pair when an SELinux permission check.
  • AVC: SELinux permission check.
  • FS_RELABEL: file system relabel operation is detected.
  • LABEL_LEVEL_CHANGE: object’s level label is modified.
  • LABEL_OVERRIDE: administrator overrides an object’s level label.
  • MAC_CONFIG_CHANGE: SELinux Boolean value is changed.
  • MAC_STATUS: SELinux mode (enforcing, permissive, off) is changed.
  • MAC_POLICY_LOAD: SELinux policy file is loaded.
  • ROLE_ASSIGN: administrator assigns a user to an SELinux role.
  • ROLE_MODIFY: administrator modifies an SELinux role.
  • ROLE_REMOVE: administrator removes a user from an SELinux role.
  • SELINUX_ERR: internal SELinux error is detected.
  • USER_LABELED_EXPORT: object is exported with an SELinux label.
  • USER_MAC_POLICY_LOAD: user-space daemon loads an SELinux policy.
  • USER_ROLE_CHANGE: user’s SELinux role is changed.
  • USER_SELINUX_ERR: user-space SELinux error is detected.
  • USER_UNLABELED_EXPORT: object is exported without SELinux label.
  • AppArmor Mandatory Access Control:
    • APPARMOR_ALLOWED
    • APPARMOR_AUDIT
    • APPARMOR_DENIED
    • APPARMOR_ERROR
    • APPARMOR_HINT
    • APPARMOR_STATUS APPARMOR

Audit framework events:

• KERNEL: Record the initialization of the Audit system.
• CONFIG_CHANGE: The Audit system configuration is modified.
• DAEMON_ABORT: An Audit daemon is stopped due to an error.
• DAEMON_ACCEPT: The auditd daemon accepts a remote connection.
• DAEMON_CLOSE: The auditd daemon closes a remote connection.
• DAEMON_CONFIG: An Audit daemon configuration change is detected.
• DAEMON_END: The Audit daemon is successfully stopped.
• DAEMON_ERR: An auditd daemon internal error is detected.
• DAEMON_RESUME: The auditd daemon resumes logging.
• DAEMON_ROTATE: The auditd daemon rotates the Audit log files.
• DAEMON_START: The auditd daemon is started.
• FEATURE_CHANGE: An Audit feature changed value.

Networking related:

• IPSec:
  • MAC_IPSEC_ADDSA
  • MAC_IPSEC_ADDSPD
  • MAC_IPSEC_DELSA
  • MAC_IPSEC_DELSPD
  • MAC_IPSEC_EVENT: The IPSec event, when one is detected, or when the IPSec configuration changes.
• NetLabel:
  • MAC_CALIPSO_ADD: The NetLabel CALIPSO DoI entry is added.
  • MAC_CALIPSO_DEL: The NetLabel CALIPSO DoI entry is deleted.
  • MAC_MAP_ADD: A new Linux Security Module (LSM) domain mapping is added.
  • MAC_MAP_DEL: An existing LSM domain mapping is added.
  • MAC_UNLBL_ALLOW: An unlabeled traffic is allowed.
  • MAC_UNLBL_STCADD: A static label is added.
  • MAC_UNLBL_STCDEL: A static label is deleted.
• Message Queue:
  • MQ_GETSETATTR: The mq_getattr and mq_setattr message queue attributes.
  • MQ_NOTIFY: The arguments of the mq_notify system call.
  • MQ_OPEN: The arguments of the mq_open system call.
  • MQ_SENDRECV: The arguments of the mq_send and mq_receive system calls.
• Netfilter firewall:
  • NETFILTER_CFG: The Netfilter chain modifications are detected.
  • NETFILTER_PKT: The packets traversing Netfilter chains.
• Commercial Internet Protocol Security Option:
  • MAC_CIPSOV4_ADD: A user adds a new Domain of Interpretation (DoI).
  • MAC_CIPSOV4_DEL: A user deletes an existing DoI.

Linux Cryptography:

• CRYPTO_FAILURE_USER: A decrypt, encrypt, or randomize cryptographic operation fails.
• CRYPTO_IKE_SA: The Internet Key Exchange Security Association is established.
• CRYPTO_IPSEC_SA: The Internet Protocol Security Association is established.
• CRYPTO_LOGIN: A cryptographic officer login attempt is detected.
• CRYPTO_LOGOUT: A cryptographic officer logout attempt is detected.
• CRYPTO_PARAM_CHANGE_USER: A change in a cryptographic parameter is detected.
• CRYPTO_REPLAY_USER: A replay attack is detected.
• CRYPTO_TEST_USER: The cryptographic test results as required by the FIPS-140 standard.

Process:

• BPRM_FCAPS: A user executes a program with a file system capability.
• CAPSET: Any changes in process-based capabilities.
• CWD: The current working directory.
• EXECVE; The arguments of the execve system call.
• OBJ_PID: The information about a process to which a signal is sent.
• PATH: The file name path information.
• PROCTITLE: The full command-line of the command that was used to invoke the analyzed process.
• SECCOMP: A Secure Computing event is detected.
• SYSCALL: A system call to the kernel.

Special system calls:

• FD_PAIR: The use of the pipe and socketpair system calls.
• IPC_SET_PERM: The information about new values set by an IPC_SET control operation on an Inter-Process Communication (IPC) object.
• IPC: The information about a IPC object referenced by a system call.
• MMAP: The file descriptor and flags of the mmap system call.
• SOCKADDR: Record a socket address.
• SOCKETCALL: Record arguments of the sys_socketcall system call (used to multiplex many socket-related system calls).

Systemd:

• SERVICE_START: A service is started.
• SERVICE_STOP: A service is stopped.
• SYSTEM_BOOT: The system is booted up.
• SYSTEM_RUNLEVEL: The system’s run level is changed.
• SYSTEM_SHUTDOWN: The system is shut down.

Virtual Machines and Container:

• VIRT_CONTROL: The virtual machine is started, paused, or stopped.
• VIRT_MACHINE_ID: The binding of a label to a virtual machine.
• VIRT_RESOURCE: The resource assignment of a virtual machine.

Device management:

• DEV_ALLOC: A device is allocated.
• DEV_DEALLOC: A device is deallocated.

Trusted Computing Integrity Measurement Architecture:

• INTEGRITY_DATA: The data integrity verification event run by the kernel.
• INTEGRITY_EVM_XATTR: The EVM-covered extended attribute is modified.
• INTEGRITY_HASH: The hash type integrity verification event run by the kernel.
• INTEGRITY_METADATA: The metadata integrity verification event run by the kernel.
• INTEGRITY_PCR: The Platform Configuration Register (PCR) invalidation messages.
• INTEGRITY_RULE: A policy rule.
• INTEGRITY_STATUS: The status of integrity verification.

Intrusion Prevention System:

• Anomaly detected:
  • ANOM_ABEND
  • ANOM_ACCESS_FS
  • ANOM_ADD_ACCT
  • ANOM_AMTU_FAIL
  • ANOM_CRYPTO_FAIL
  • ANOM_DEL_ACCT
  • ANOM_EXEC
  • ANOM_LINK
  • ANOM_LOGIN_ACCT
  • ANOM_LOGIN_FAILURES
  • ANOM_LOGIN_LOCATION
  • ANOM_LOGIN_SESSIONS
  • ANOM_LOGIN_TIME
  • ANOM_MAX_DAC
  • ANOM_MAX_MAC
  • ANOM_MK_EXEC
  • ANOM_MOD_ACCT
  • ANOM_PROMISCUOUS
  • ANOM_RBAC_FAIL
  • ANOM_RBAC_INTEGRITY_FAIL
  • ANOM_ROOT_TRANS
• Responses:
  • RESP_ACCT_LOCK_TIMED
  • RESP_ACCT_LOCK
  • RESP_ACCT_REMOTE
  • RESP_ACCT_UNLOCK_TIMED
  • RESP_ALERT
  • RESP_ANOMALY
  • RESP_EXEC
  • RESP_HALT
  • RESP_KILL_PROC
  • RESP_SEBOOL
  • RESP_SINGLE
  • RESP_TERM_ACCESS
  • RESP_TERM_LOCK

Miscellaneous:

• ALL: Matches all types.
• KERNEL_OTHER: The record information from third-party kernel modules.
• EOE: An end of a multi-record event.
• TEST: The success value of a test message.
• TRUSTED_APP: The record of this type can be used by third-party application that require auditing.
• TTY: The TTY input that was sent to an administrative process.
• USER_TTY: An explanatory message about TTY input to an administrative process that is sent from the user-space.
• USER: The user details.
• USYS_CONFIG: A user-space system configuration change is detected.
• TIME_ADJNTPVAL: The system clock is modified.
• TIME_INJOFFSET: A Timekeeping offset is injected to the system clock.