Since 2000, the nonprofit Center for Internet Security (CIS) has provided the public service of creating and distributing hardening guidelines for common operating systems and applications. Alongside documents describing what configuration to check, how they should be configured, and how to fix them, CIS also offers a software solution that can analyze a system for compliance with the CIS benchmarks. Despite those resources, and their criticality for information security, the fact remains that becoming and staying secure is a persistent problem. Why is system hardening so hard?
The problem isn't a lack of knowledge for assessing the security of information systems. CIS has provided more than enough information. While vulnerability detection is outside of the scope of CIS, it's worth mentioning there are also free tools to address that threat vector. Various vendors have been working on the technical problems of automating CIS assessment for years. The problem holding back organizations that want to improve is in the interface between the data collected and the people who will use it.
One solution that vendors have tried is to treat people as the weak link and automate them out of the hardening process. Each CIS benchmark includes information on how to remediate non-compliant systems. Automating that remediation is initially appealing. Updating systems is time consuming and prone to human error, and the demands of CIS benchmarks can be sweeping in scope, like checking the permissions on every file.
The problem, of course, is that automating what you don't understand is more dangerous than no automation at all. The promise of automated compliance has now come and gone as companies have realized that it is better to retain the risk of waiving of a control until they can understand its impacts than to give up control of their infrastructure to a set of scripts written by a vendor's outsourced content team. And so one theory for why hardening is difficult-- because people are slow and cannot be trusted-- must be discarded. Rather than a technical problem of execution speed, the real hurdle is the need for judgment. Hardening requires elevating people, not discarding them.
Given hundreds of checks per system, many of which will likely fail, how do businesses prioritize the work to be done? The ability to explore CIS policy results to find patterns– tests that are failing everywhere and for which the risk should be formally retained, tests that are passing almost everywhere and only need a little push to achieve full compliance- is the next step. To that end, we have built a CIS reporting dashboard with modern analytics, data visualization, and API interoperability to integrate with other systems. The machine problem of executing tests is a solved one; the design goal for our implementation of CIS benchmarks is to make the copious outputs useful for the person responsible for improvement.
Additionally, the results of CIS benchmarks need to have context. Without an understanding of the other requirements for those systems, you are flying blind and might as well use a script to change all the configuration settings. To achieve resilience, hardening guidelines need to be balanced with operational needs. To that end, UpGuard visualizes the results of CIS tests along with the complete state of your system and other requirements being executed as UpGuard policies. Conflicts between hardening requirements and your application needs can be identified and resolved before they cause problems.
But beyond the problem of making compliance easier lies the bigger question: so what? What is the risk associated with a failing benchmark? Omitting benchmarks because they are failing can clear out the noise, but is it creating critical business risks? That discussion is at the heart of digital resilience, and it is one where the human component is even more important than in prioritizing what to fix. Having adequate data to assess where controls are failing and the cost of fixing them is critical, but it must be put in service of the human determination of business strategy.
Policies are now coupled more tightly with node scans, giving you one interface to see exactly how a node is configured, how it's changing, and how compliant it is with your operational or security standards.
Read Article >
Sometimes creating security documentation can be just as difficult as enacting security measures themselves.
Read Article >