How to Manage a Multi-faceted IT Environment

By Sean Atkinson, Chief Information Security Officer

It has become a common practice to combine management of different technologies into a single process and expect that actions taken will occur in the same manner and time frame as when those processes were separate. Specifically, this blog post examines the complex IT environments that exist and the expectation put on those systems to patch, update and maintain secure configurations all when each specific technology is managed in vastly different ways.

Compliance – with conditions!

At CIS we align best practices to processes and actions as a requirement. For IT teams, it is crucial to understand your hardware and software environments in order to maintain asset inventory and know what systems you have. Patching, updates, and remediating issues with configurations are all items that are specifically prescribed by CIS as basic elements of establishing and, more importantly, maintaining security control.

Issues may arise when the expectation is that management of Windows and *nix environments (such as Unix and Linux) are the same: “Just update and make sure we are compliant.” If only it were so simple! In most cases, these processes (updating, vulnerability scanning, configuration management, etc.) should be specifically managed with respect to the underlying technologies. The devil is truly in the details, such as specific controls and compliance requirements set against each type of infrastructure. Therefore, automation and management of checks across the infrastructure are recommended. This will allow for a strategized solution to different pathways of patch management as well as define those systems where we have levels of criticality for securing infrastructure.

Critical patch management

In some cases, such as industrial control systems, the technologies involved are so critical that patch management cycles are built around a specific downtime. This leads to a conglomeration of patches all to be installed at a single point in time. Our warning when dealing with such critical systems is twofold:

• Test those patches in another environment for operational effectiveness
• Have a “back out” strategy should things go awry

It is not often that you will find a test environment that is an exact mirror of production, which means that testing can only go so far. For this reason, we suggest that technical teams always have a strategy to implement stability and re-apply a particular patch or update once the correct implementation strategy has been identified.

Questions for the reader

For different OS flavors – how do you manage the patching requirement: as a single operation, divided between OS, or based on the criticality of the system?

Given the above scenarios, do you manage each environment as a separate control requirement?

Join the discussion on Twitter with #AskCISecurity.