6 Steps for Better Cyber Security Documentation

It’s been awhile since I posted a cyber security post. Since I encounter all of these questions on a daily basis, I thought it’d be a good recap. Yes, I know it’s a “6 things you can do” list and I can harp on those kinds of lists occasionally, but the subject matter’s different this morning. I might have another post about where my quiet time led this morning.

What does your cyber security posture look like right now? What would you like it to look like? Is cyber security just a goal to attain or is it something that you can start doing today?

Believe it or not, documentation is as important as making sure you are scanning your systems for vulnerabilities and applying patches to remediate your systems. Certainly, some vulnerabilities can’t be remediated for some reason or another, which is why mitigating the risk is as important. Let’s look at how organized documentation help ensure your systems are maintained in an optimal state of security and availability. Having just these records in a well-maintained, centrally located binder will save many headaches later.

1. Configuration management records: Network diagrams, hardware and software lists of what your baseline system looks like. This will include your licensing agreements and warranty/support documentation, including any third party service level agreement documentation. Any modifications to your systems should also be documented here (new applications, technical refresh, physical location changes of systems, etc.). NIST SP 800-128 is an excellent resource for details on keeping configuration management.

2. Vulnerability management records: Details on how your systems are scanned for vulnerabilities and remediated (or mitigated). This will include what type of vulnerability scanner(s) you are using (i.e. BeyondTrust Retina, Nessus, etc.) and documentation of what you are scanning for (not just missing patches, could be open ports, lack of file auditing, file permissions, etc). If you are using automated patch management, include documentation of how it is set up (WSUS, Shelvik, Secunia, etc.) . Sign up for patch notices and vulnerability notices from sources such as Microsoft, Bugtraq, CERT and US-CERT to stay on top of keeping systems and applications up-to-date. If the data is sensitive, copies of scan results should be kept in a secure area where only certain authorized personnel will have access to them. These scan results can be listed as individual (or one bulk) action item in the Plan of Action & Milestones (POA&M) listed below.

3. A brief statement of what statutory requirements you are meeting (i.e. HIPAA, PCI-DSS, FISMA) and why your systems fall under those requirements (store protected PII, banking information, healthcare provider/patient information, lawyer/client information, etc.). Having this in writing helps you and your business understand what exactly the requirement is and how you are meeting it. The POA&M should be attached or included with this statement. Include what level of Confidentiality, Integrity and Availability are required for your system to determine what measures should be implemented. Include what the consequences are of failing to maintain your systems.

4. Incident Handling & Response Plan: This should include an actual mission statement, strategies and goals to show an organized approach for incident response. At a minimum, the plan should list team members and leadership; a means to recognize what’s happening (or happened) and what needs to be fixed. It should include metrics to determine the impact of a system(s) being down (financial impact, civil impact, possible criminal impact), what information was compromised or stolen, and how to recover from the incident (with a projected timeline). Lastly, it should include how the incident response plan and methods handled incidents, as they aren’t static incidents, and debriefed as lessons learned to the organization. NIST 800-61 Rev 2 is a great resource for this.

5. A list of users with copies of their signed End User Agreements. If the user has privileged access, they should have that documented as well.

6. A list of training performed, not just for the system administrators and systems security personnel, but for end users as well. For example, HR and medical personnel should have some type of HIPAA or PII training for end users, stressing the importance of data protection. 

If implemented in an organized, documented fashion, you should find maintaining your systems in a more secure state a much easier task. All too often, many system administrators either neglect the updates entirely or have made so many complex changes that it becomes a herculean effort to document. Baseline where you are now as your starting point, and work from there.
It pays off in the long run.