Over the years, we've seen organizations take multiple approaches to security assessments and the associated findings. Some organizations are apprehensive about acknowledging certain findings for fear they may have to actually spend resources to fix them. Other organizations welcome the identification of issues, but will only remediate exactly what is explicitly detailed in a report. While there is nothing wrong with fixing specific technical issues related to a particular process or technology, as a security professional, I'd like to encourage organizations to take one additional step that will greatly increase their ability to achieve an appropriate level of security.

Root Cause Analysis (RCA) and remediation should be a cornerstone for any security program, no matter the size or type of business. As information security professionals, we're trained to identify gaps in existing security practices. We should spend an equal amount of time and more energy identifying the root cause(s) for each gap and the remediation steps necessary to reduce the likelihood of a similar gap manifesting itself in the future through the elimination of root cause(s). It is just common sense that if we do not remediate the root cause(s) of an issue, that issue is certain to resurface and cause further problems in the future. Treat the disease, not the symptoms.

Say, for instance, a high risk security patch is found to be missing from a critical system. What do you do? Well, hopefully your organization has vulnerability lifecycle management and emergency change procedures in place that allow you to analyze the impact of the patch on the system. Your goal is to deploy the patch in a timely and low-risk fashion to resolve the tactical issue at hand. (If not, you can use the steps below to help resolve that issue.)

Once you have resolved the tactical issue through your vulnerability lifecycle management and/or emergency change procedures, you can step back and attempt to identify the strategic remediation necessary to reduce the likelihood of recurrence. One easy way to identify the root cause is by asking the question: Why? The patch management failure above might play out in this way:

Question: Why was a high risk security patch missing from a critical production system?

Answer: The system was recently deployed and was not part of the last round of patches.

Question: Why was the system not part of the last round of patches?

Answer: The timing of the deployment was such that the most recent patches were deployed to the production environment, but where not yet included in the system build process.

Question: Why were the patches not included in the system build process?

Answer: The system build process is updated every 120 days, but patches are applied every 45 days.

Root Cause Analysis: The patch management process and system build process are out of sync. Either updating the system build documentation every 45 days to include the latest patches OR implementing some other detective control to identify and apply all appropriate patches is required to reduce the likelihood of recurrence.

Applying this question and answer process to recognized issues should help you to accurately identify the root cause for identified gaps. Remediation of those gaps may take time, but will significantly reduce the security risk to your organization.