Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 99

These two terms are quite often confused with each other or used as if they are interchangeable; in point of fact, it depends upon the culture and environment you're in as to which name is best to use. In business and leadership development contexts, change management (and change leadership) involves motivating, guiding, and leading people to change the ways they perceive their work and their systems and then further leading and guiding them toward making changes in those systems and in themselves. In these same contexts, configuration management is about taking a defined set of hardware, software, information, and even people skills and tasks, each of which has its particular collection or configuration of settings, options, parameters, and feature selections, and changing it into the same set of elements with different configuration settings. When you talk about IT change management and what you really mean is changing an IT systems' technical configuration into another configuration, it may be less confusing to talk about this as IT configuration management rather than IT change management. (Fortunately, nobody seems to talk about leading people to behave differently as “reconfiguring” them or managing that growth and development as “configuration managing” the HR assets!)

In an effort to reduce confusion, throughout this book I will refer to decisions about changing the configuration settings of an IT system as configuration management. (Change management, in the sense of organizational mission, vision, purpose, and culture, is beyond the scope of this book.)

As with many other topic areas, configuration and change planning and management present opportunities for you to work with the people around you, and with the procedures they already have in place, to understand what meanings they are implying by their use of certain terms. Guide them if you can to clarify, remove ambiguity, and become more aligned with industry-standard terms and meanings.

Configuration management and its partner process configuration control together keep a system and all of its elements managed in a cohesive, controlled way as changes, updates, or repair actions take place. Configuration management is a responsibility of both due care and due diligence and is vital to asset management. It is also a high-payoff set of process investments to make for improved information systems security. Configuration management ensures that the right stakeholders have made informed decisions to make changes, apply patches, or delete elements of your systems; configuration control ensures that those directed changes get made and that no other changes are allowed to take place.

Configuration management has perhaps the largest and most direct impact on an IT system's security posture. Without an active and effective configuration management and configuration control (CM/CC) system in place, your systems are essentially unmanaged and vulnerable. Consider as your starting point that straight from the shipping cartons, the default settings on all of your IT hardware, software, firmware, and data are often unsafe. One simple misconfiguration such as leaving a guest account open can bypass all other security controls. If by chance the new equipment or software you install is set up correctly and has no exploitable vulnerabilities still exposed, without configuration control, subsequent changes to that system and other systems it interacts or coexists with can re-expose those factory default weaknesses. Don't get the wrong impression here—without those factory or vendor default settings in place, you'd never be able to install and get the system up and running the first time. Once you do, of course, change them and lock them down tight.

The record-keeping that is the backbone of a good CM/CC system has another great payoff waiting for you, in the event that disaster strikes and you have to reload a bare-iron backup processing facility (or virgin VMs in the cloud) before you can get back into normal business operations. Those CM/CC records give you a known configuration baseline to use to verify that the backup images you loaded are configured, in all details, the way your management processes said they should be—the way your live production systems had been configured just before disaster struck.

Your organization should start by developing a configuration management plan if it does not have one in operation already. A configuration management (CM) plan defines how an organization will manage the configuration of its hardware and software assets. It defines details such as the roles, responsibilities, policies, and procedures that are applicable. A configuration control board (CCB), which ITIL guidance refers to as a change advisory board (CAB), will manage the CM plan. As the CCB is comprised of qualified stakeholders from the organization, they will often be the authors, editors, reviewers, and approvers of the organization's configuration policies and procedures. They will also be tasked with applying and enforcing the CM plan and helping technical administrators adhere to and understand the CM plan. Most importantly, the CCB controls and approves changes throughout the lifecycle of the IT systems, which is why they may also be known as the change control board.

Configuration management and change control focus on the life history of individual configuration items and on sets of configuration items. A configuration item (CI) is one discrete part of an IT system, like a piece of hardware or software, that has configurable settings or parameters and should be under formal configuration control. A baseline configuration is a defined, desired set of configurations for a specific CI (or combine multiple CIs into an IT system), which has been formally reviewed and approved. A baseline configuration is valid for a given point in time and may need to be adjusted over time as software or hardware versions change, new vulnerabilities are discovered, or different usage and needs dictate the need for change. When the baseline configuration needs to change, it should be done only through predefined change control procedures. Deciding what a CI should be is a matter of perspective. Consider as an example that a modern platform system such as Microsoft Office Professional might contain between 5,000 to 10,000 individual files, or about 2 GB of code, configuration data, settings, forms, and templates. To the Microsoft Office developer team, each of those files is a CI. To your company's systems administrators who download licensed distribution kits, configure them, and install them onto dozens or hundreds (or more!) of endpoint systems throughout your company, they may see each new patch version of Office as one CI or see it as thousands of CIs (all those files and all of the patches to them). Fortunately, Microsoft (and many other platform product vendors) provide some pretty extensive maintenance management tools to help you manage their products as deployed systems, rather than as deployed swarms of a huge and unwieldy number of files.