Information Security is a Management Issue

With what seems like a never-ending stream of cybersecurity attacks, corporate boards and executives are searching for that “silver bullet” to protect them from the universe of threats. Unfortunately, corporations are spending hundreds of millions on products that claim to be the cure-all. Still, in reality, these products are not stopping every attack because technology isn’t the only solution.

Many of these products can reduce security risks, but only if they are fully implemented and integrated into an overall security strategy. The problems may not be with the products, but rather a lack of management focus on designing, implementing, and monitoring solutions properly. This requires an integration of people, processes, and technology.

 Implementing a security management program starts with understanding what assets need to be protected and establishing boundaries (or scope) of what will be included in a security management program. Assets should consist of data and intellectual property and the information technology and other resources the organization uses to produce value. Organizations that rely on third parties to perform work on their behalf should consider including their assets managed by third parties in the scope of their security management program as well.

Once all assets have been identified and the scope of the security management program established, management will need to establish security objectives to protect the data. Consider the National Institute of Standards and Technology (NIST) Cyber Security Framework (CSF) for organizations new to this journey. It is a good reference for the strategic-level security objectives, including Identify, Protect, Detect, Respond, and Recover. Each of these objectives will have multiple supporting observable and measurable controls.

 The next step is to identify risks to the assets and select appropriate controls from one of many security frameworks available to mitigate those risks. Unless there are legal, regulatory, or contractual requirements to align to a specific control framework, organizations may want to align with the NIST CSF or the International Standards Organization 27002:2013 Standard.

 Controls are selected as a byproduct of a risk assessment, where gaps in controls are evaluated, and the likelihood and adverse impacts are documented. The risk management process should be documented and repeatable, so the outcome of a risk assessment is a prioritized set of actionable projects that can achieve the organization’s security objectives. It is unrealistic to expect all risks to be mitigated, but executive management should review all open deferred risks at least annually. The risk assessment process should be updated on a set schedule following changes in the security management program’s scope or environment.

Every untreated risk needs to be assigned to a risk owner. This individual should acknowledge their responsibility, preferably in writing. Executive leadership should hold these risks owners accountable for reducing the risk to a level within the published risk appetite.

As stated earlier, controls supporting the key objectives need to be observable and measurable, and selecting appropriate measurement points is critical to success. For example, the NIST CSF function of Protecting systems requires implementing a vulnerability management plan. This plan has many components, including selecting, deploying, and validating software patches.

The primary objective of a patch management process (i.e., control) is to reduce or eliminate network vulnerabilities. Measuring the effectiveness of a network vulnerability control can be accomplished by reviewing patch deployment reports; however, this alone does not provide assurance that vulnerabilities are being reduced. Several reasons can contribute to this control’s failure, including the requirement to reboot a system following patch deployment, a misconfiguration that doesn’t permit a patch to work on all systems, or the presence of other incompatible software.

Automated patch management products can generate reports on the number of patches deployed. While these reports are important, measuring this control alone may present a false sense of security and ultimately divert management’s attention from the stated objective of remediating vulnerabilities.

The best solution to measure the control effectiveness for a patch management product is to select a control measurement at the end of the process, such as evaluating the number of vulnerabilities remediated. This can be accomplished by performing vulnerability scans and document systems still requiring remediation.

The CIO and the IT management team should then focus on reviewing run-time charts that document the number of new and recurring vulnerabilities found monthly. These charts can also document the average age of unmitigated vulnerabilities, which can be an early indicator of a resource shortage. In an optimized security management program, the overall number of recurring vulnerabilities should show a steady decline down to zero, while the number of days to remediate should also decline. As shown in the example, any increase in recurring vulnerabilities or average days to close would indicate a control failure.

By now, it should be clear that focusing on security technology alone will not address some of the root causes behind many successful breaches. Comparing the reports from a patch management product and vulnerability scans illustrates how management can leverage touchpoints in seemingly unrelated controls to measure the objective’s effectiveness. Many others address user training, incident response, and access controls. Only through sound security management principles, including implementing observable and measurable objectives, will organizations reduce the overall risk. Ultimately, managing security through observable and measurable metrics can help protect organizations’ assets.