Week 19: Configuration Management (CM)

In this week's column, Bard offers some tips on configuration management.

When
Every month for organizations with ongoing changes planned, every other month for organizations with medium activity or quarterly for organizations with less activity.

Why
There are different types of CM like software, network, etc. They all boil down to knowing the security state of your entire system at any given time -- no matter what changes are applied. CM, sometimes called change management, is the management of security features through control of changes made to hardware, software, firmware, documentation, test, test fixtures and test documentation of an information system (IS) throughout its development and operational life.

For the government, CM is an integral part of the system accreditation process. If you have systems that must pass certification and accreditation (C&A), you must use a CM process when ISes, new or otherwise, are under development, being procured or delivered for operation. Therefore, it's imperative that accreditation authorities be advised of CM decisions. This will ensure systems are fielded or modified within acceptable risk parameters and the latest security technology is being incorporated into system designs. This participation is most important at preliminary design and critical design reviews.

Strategy
If you don't have one, you need to create a Configuration Control Board (CCB), sometimes also called a Configuration Management Board. The board should be made up of people who are knowledgeable members of the program team and who represent key functional areas and have the authority to commit to decisions made at the CCB. You'll need a chairperson for it, like the CIO. Other members include, at a minimum, the chief system or software engineer/architect, quality assurance/control expert, functional area leads, program managers, cognizant engineers, business managers and perhaps even finance/accounting members as applicable. Voting can be optional, but I support the voting option with authority to veto based on impacts to security.

The following policy items should be included for the CM of all systems:

--Modifying, relocating or reconfiguring of hardware or software for any system should be evaluated and approved by the CCB for your site. Hardware should not be connected to any system/network without the express written consent of the CCB, and of course documented appropriately. Modifying, installing or downloading any software may affect system accreditation, if applicable. Your policy should delineate authorized and unauthorized software and hardware.

--Participate in the development of site CM Plan (CMP).

--Establish your site's architectural baseline and maintain it.

--Preview proposed security changes that could impact your site's security posture and make approval/disapproval recommendations.

--Certify site accreditation baseline, if applicable, in coordination with the site certification authority (as required), now annually.

--Ensure all site security documentation is prepared and maintained.

Your site CMP describes how to implement and maintain configuration of your site; defines how CM is implemented as it relates to identification, control, status accounting and auditing; defines the roles of designers, developers, management, the CCB and any others in the lifecycle of present/future baseline systems and how new systems will be incorporated into the baseline; and defines CCB membership by office symbol and title.

More information
Sites like http://www.sei.cmu.edu and http://www.icmhq.com contain information sources from industry and government. There are also automated tracking programs, some resident in the operating systems, some as modules to buy and some as third-party options.

About the author
Shelley Bard, CISSP, is a senior security network engineer with Verizon Federal Network Systems (FNS). An infosecurity professional for 17 years, Bard has briefed and written infosecurity assessments and technical reports for the White House and Department of Defense, special interest groups, industry and academia. Please e-mail any comments to mailto:securityplanner@infosecuritymag.com.

Opinions expressed in this column are those of Shelley Bard and don't necessarily reflect those of Verizon FNS.

Last week: Week 18: Budgets
Next week: The dreaded risk assessment

This was first published in April 2004

Dig deeper on Network Device Management

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close