Complete PCI DSS Log Review Procedures, Part 11

Once upon a time, I was retained to create a comprehensive PCI DSS-focused log review policies, procedures and practices for a large company.  It is focused on PCI DSS, but based on generally useful log review practices that can be utilized by everybody and with any regulation or without any compliance flavor at all.

This is the 11th post in the long, long series (part 1, part 2, part 3 – all parts). A few tips on how you can use it in your organization can be found in Part 1. You can also retain me to customize or adapt it to your needs.

And so we continue with our Complete PCI DSS Log Review Procedures (please read in order- at this point we are pretty deep in the details and this piece might look out of context):

External Information Sources Investigation

Here is the procedure to follow in this case:

This procedure can be expanded to cover other sources of information available at the organization.

The main idea of this procedure it to identify and then query information sources (such as IdM, change management, integrity checking, network flow analysis, etc), based on the type of the exception log entry and then to identify its impact and the required actions (if any)

The procedure works to roughly identify the type of a log entry and then to query the relevant information sources. In some cases, then the log entry is deemed to be an indication of a serious issue, incident response process is triggered.

However, it sometimes happens that neither the preliminary analysis nor the query of external systems yields the results and the “exception” log entry is exceptional. In this case, the collaborative workflow is triggered. See the next section for details

Escalation to Others Procedure – Collaborative Workflow

The investigation and escalation process is shown below:

This process allows tapping into the knowledge of other people at the organization who might know what this “anomaly” is about.

The main idea of this procedure it to identify and then interview the correct people who might have knowledge about the events taking place on the application then to identify its impact and the required actions (if any).

The very last resource is to query the application vendor; such info request is typically time consuming or even expensive (depends on the support contract available) so it should be used sparingly.

To be continued.

Follow PCI_Log_Review to see all posts.

Possibly related posts:

• Incident Log Review Checklist
• All posts tagged PCI_Log_Review