You Need Documentation?

A gap assessment is reviewing how a system or process is against your checklist/benchmark, in order to identify any gaps.

Whenever doing a gap assessment, in my experience there is always going to be one general area a company is almost certainly lacking.  It’s that dreaded word (and not just dreaded by programmers only)… Yes, it’s documentation!

NOTE: My apologies to programmers. I used to be (and I still am though scrappy now) a programmer. I know how you feel. I felt the same way. I hated documentation. But I’ve seen the light being on the other side of the fence and it’s for the greater good. Trust me.

Companies are generally missing documentation and whenever doing PCI-related assessments documentation is key. We have a problem.

Never fear, this is easier to fix that expected as in many cases the companies are doing things in a PCI DSS (or other PCI-type assessment) compliant manner, but it’s just not documented. Often, I find they do not understand the difference between a policy, process and procedure and don’t know where to begin.

PCI policies, processes and procedures?

PCI DSS v3.0 is great as it clearly spells out in the reporting requirements whether a documented policy, or documented process/procedure is required. My suggestion is you do them all in a certain order as follows:

•  Write your policy: Business rules and guidelines – the high level objectives you want to meet. Don’t include the how (process/procedure).
• Write your process: These are the activities to produce a specific output.
• Write your procedure: These are the underlying tasks that result in your process being fulfilled.

I still do not understand, can you give me an example?

As an example:

Policy: All system components must be hardened according to their respective hardening guides.

So let us assume you have firewalls. You need your own firewall hardening guide.

• Process: Prevent internal addresses coming from the outside.
  • Type command XXXXXXXXXX (task/procedure)
  •  Type command XXXXXXXXXX (task/procedure)
• Process: Remove the default password.
  • Type command XXXXXXXXXX (task/procedure)
  • Type command XXXXXXXXXX (task/procedure)

There are many ways to write your documentation, and I’d encourage you to split them into appropriate documents.

NOTE: In the past I’ve seen some companies just have few large documents just to satisfy PCI DSS – please split the documents up that is workable for your business.

Scope?

Your document is not intended to be read by everyone. The document has an intended audience, so make it clear by writing an introduction. For example:

“The scope of this document applies to firewall administrators.”

Roles and Responsibilities?

Of course, PCI DSS wants to know the roles and responsibilities. For example:

“Firewall administrators are responsible for applying this hardening document to all firewalls prior to installation into the production environment. All firewall administrators will need written approval before installing any firewall into the production system. Firewall administrators are required to test all firewalls after making changes to firewalls.

The owner of this document is the <insert title> who will ensure this document is kept up to date.”

Versioning?

You need to demonstrate that you update documents at specific times as addressed by the PCI DSS. There are some ways to meet this. I strongly encourage you to use a versioning table. Consider including:

• Version
• Last modified date
• Changes made
• Reviewed/approved

You will then be able to demonstrate how frequently it was reviewed:

Hint: Stick in a policy somewhere to confirm the frequency:

“This document will be reviewed every x months”

(where x is the frequency required)

So, what is the benefit of this framework?

• Confirms roles/responsibilities: Personnel know who is responsible for what device/process/system.
• Mitigates ambiguity in configuration: Follow the step by step procedures as detailed in the documents and in principle your system components should be hardened to the same level.
• Faster implementation: Often, you can copy/paste the commands into your system components and execute the command. This reduces human error/typos.
• Reviews: You can demonstrate required review periods and updates made according to your business or changes to the standards.

Summary

In summary, documentation is a key element to passing an assessment. Documentation determines correct business objectives, correct and consistent configuration, clear roles and responsibilities and also Business As Usual (maintain compliance by following compliant practices in a timely manner).

This is not an easy task to do, but once you got it, you won’t need to rewrite it again! But remember, documents will need to be demonstrated to be reviewed at various times throughout the year in order to maintain compliance.

Action:

• Document your policy
• Document your procedure
• Document your tasks to meet your procedure(s)
• Include a scope section
• Include a roles/responsibilities section
• Include a version table
• Document the frequency to review and update the document.

Once you have written your documents (and had them checked), go and relax. You deserve it!

If you still need policies, simply subscribe to my newsletter. Then get in contact.

#cyberattack, #cybersecurity, #dataprotection, #datasecurity, #datasecuritybreach, 

#gdpr, #gdprcompliance, #informationsecurity, #infosec, #pcidss, #personaldata, 

#security