Example of Policy and Procedure for Configuration Management

Uncategorized 6 Minutes

by Pretesh Biswas,

Policy of Configuration Management

XXX uses a wide variety of components in creating and running its ICT infrastructure and end-user devices. These consist of hardware, software, cloud services and networks and all are potentially vulnerable to attack from threats from different sources. In order to lessen the risk of these components becoming compromised, it is important that we identify the most appropriate ways of configuring them and then ensure that these methods are used throughout our ICT landscape.
This policy describes the main principles on which such standard configurations must be based and sets out the rules for their use.
This control applies to all systems, people and processes that constitute the organization’s information systems, including board members, directors, employees, suppliers and other third parties who have access toXXX’s systems.
The following policies and procedures are relevant to this document:

  • Information Security Policy
    Mobile Device Policy
    Network Security Policy
    Cloud Services Policy
    Configuration Management Process
  • Change Management Process

New components that make up ISMS hardware, software, services and networks must have their required security settings defined and correctly configured prior to their implementation within our ICT environment.
Configurations of existing components must be reviewed periodically to ensure they meet the requirements of this policy.
Such components will include, but are not limited to:

  • Endpoint devices, such as desktops, laptops, mobile phones and tablets
  • Physical network devices, such as routers, switches and firewalls
  • Physical servers, including system software such as operating systems, databases and web servers
  • Cloud infrastructure, such as virtual servers, networks and storage
  • Where possible, standard templates will be used to document the required configuration of ICT components. These templates will be subject to change and version control.
  • The configurations defined will take appropriate account of available sources of information about securing the relevant components, such as vendor templates, guidance from cyber security authorities and best practice organizations, system hardening guides and our own information security policies.
  • Details of configuration standards will be protected as sensitive information which would be of use to an attacker.
  • Configuration standards must be reviewed on a regular basis and kept up to date with changes in the components themselves (such as new hardware or software versions) and the threats and vulnerabilities they face.
  • The correct configuration of components will be monitored and instances where existing settings deviate from the established standard will be investigated and, if necessary, corrected.
  • Where feasible, automated software methods such as Infrastructure as Code (laC) will be used to create components with the correct configuration. Automated audit tools may also be used to check configurations regularly and report on and correct those found to be non compliant.

SCOPE

Configuration Management covers the identification, recording, and reporting of IT components, including their versions, constituent components and relationships. Items that should be under the control of Configuration Management include hardware, software and associated documentation. This procedure is applicable to XXX.

PROCEDURE

The basic activities of Configuration Management are as follows:

  • Planning. Planning and defining the purpose, scope, objectives, policies and procedures, and the organisational and technical context, for Configuration Management.
  • Identification. Selecting and identifying the configuration structures for all the infrastructure’s Configuration Item(CI), including their ‘owner’, their interrelationships and configuration documentation. It includes allocating identifiers and version numbers for CIs, labelling each item, and entering it on the Configuration management database (CMDB).
  • Control. Ensuring that only authorised and identifiable CIs are accepted and recorded, from receipt to disposal. It ensures that no CI is added, modified, replaced or removed without appropriate controlling documentation, e.g. an approved Change request, and an updated specification.
  • Status accounting. The reporting of all current and historical data concerned with each CI throughout its life cycle. This enables Changes to CIs and their records to be traceable, e.g. tracking the status of a CI as it changes from one state to another for instance ‘under development’, ‘being tested’, ‘live’, or ‘withdrawn’.
  • Verification and audit. A series of reviews and audits that verify the physical existence of CIs and check that they are correctly recorded in the Configuration management system.

Configuration management planning

. A Configuration Management plan should define:

  • the purpose, scope and objectives of Configuration Management
  • related policies, standards and processes that are specific to the support group
  • Configuration Management roles and responsibilities
  • CI naming conventions
  • the schedule and procedures for performing Configuration Management activities: configuration identification, control, status accounting, configuration audit and verification
  • interface control with third parties, e.g. Change Management, suppliers Configuration Management systems design, including scope and key interfaces, covering: CMDB
  • locations of Configuration Management data and libraries controlled environments within which CIs are manipulated
  • support tools (e.g. build and installation tools)
  • housekeeping, including licence management, archiving and the retention period for CIs
  • planned configuration baselines, major Releases, milestones, workload and resource plan for each subsequent period.
  • Checks should be made to ensure that the staff, IT resources, and support tools – including the size of the CMDB to be made available to Configuration Management – are likely to be adequate.Where deficiencies are identified, steps should be taken to obtain further resources or procure enhanced support tools.

Configuration identification

The IT infrastructure configuration should be broken down and uniquely identified to enable effective control, recording and reporting of CIs to the level that the business requires. The scope should include the hardware, and software used to build, release, verify, install, distribute, maintain, recover and decommission CIs. This includes any environments and software tools used to build a CI. Examples of the components that should be identified are:

  • hardware (including network components where relevant)
  • system software, including operating systems
  • business systems – custom-built applications
  • packages – commercial off-the-shelf packages, standard products, and database products,
  • physical databases
  • environments
  • feeds between databases, applications and EDI links
  • configuration baselines
  • software releases
  • configuration documentation, e.g. system and interface specifications, licences, maintenance agreements, SLAs, decommissioning statement
  • Change documentation, deviations and waivers
  • other resources e.g. Users, suppliers, contracts
  • other documentation e.g. IT business processes, workflow, procedures
  • network components

CONFIGURATION CHANGE MANAGEMENT

Dept. Head along with IT must implement a controlled change process and provide tailored methods and standard operating procedures for effectively planning, recording, controlling, and validating product requirements and data that contain the requirements. Tailoring will depend on the organization and the level of control or complexity needed.
Configuration management control is accomplished by utilizing the CMDB, a centralized configuration management database, or a series of databases that provide central, logical access to configuration data, containing relevant information such as the configuration items and their attributes, baselines, documentation, changes, and relationships. Requests for Changes must be stored in the CMDB.

Configuration status Accounting
The CMDB tool must be used to track submitted Requests for Changes. The objectives of the system are to provide enhanced coordination, visibility, and accountability. Records describing configuration items must be established and maintained in the CMDB. The tool must assign a unique identifier to each Request for Change and maintain a repository of all change requests. Dept. Heads must record actions in sufficient detail that the content and status of each
Configuration Item is known and previous versions can be recovered. Organizations must maintain product description records, configuration verification records, change status records, and history of change approvals.
The CMDB must contain relevant information about configuration items, their attributes, baselines, documentation, changes, and relationships. The recording of changes must include:

  • The reason for the changes
  • If a proposed change to the configuration item is accepted, a schedule for incorporating the change into the configuration item and other affected areas
  • Indication that changed configuration items have been released only after review and approval of configuration changes. Changes are not official until they are approved

CONFIGURATION VERIFICATION AND AUDITS

Configuration auditing must be performed by ISMS coordinator to verify the integrity of the processes, systems, items, and baselines under Configuration Management control.

  • The ISMS coordinator conducts these audits to ensure baseline compliance of the configured assets’ hardware, software, and controlled documentation with established requirements, specifications, and functional parameters.
  • Change control processes are also subject to Configuration Management Audits.
  • Configuration Management Audits must be used to ensure the accuracy of the CMDB;
  • determine the accuracy and completeness of Configuration Management processes;
  • verify data and documentation;
  • ensure project compliance with requirements, standards, and conventions.

All audit records and respective deficiencies must be placed into the CMDB, which shall be used to track corresponding action items, suspense dates, and close-out activities. The ISMS coordinator can decide whether these attributes need to be tracked within the CMDB since he/she is responsible for conducting periodic audits. The CMDB must be used to maintain a historical file of all audit information throughout the applicable life cycle.
The ISMS coordinator must conduct its audits on a periodic basis following a defined audit sequence.
The ISMS coordinator must have the responsibility to initiate the audit sequence and oversee its implementation.

Back to Home Page

If you need assistance or have any doubt and need to ask any questions contact me at preteshbiswas@gmail.com. You can also contribute to this discussion and I shall be happy to publish them. Your comment and suggestion are also welcome.

Published by Pretesh Biswas

Pretesh Biswas has wealth of qualifications and experience in providing results-oriented solutions for your system development, training or auditing needs. He has helped dozens of organizations in implementing effective management systems to a number of standards. He provide a unique blend of specialized knowledge, experience, tools and interactive skills to help you develop systems that not only get certified, but also contribute to the bottom line. He has taught literally hundreds of students over the past 5 years. He has experience in training at hundreds of organizations in several industry sectors. His training is unique in that which can be customized as to your management system and activities and deliver them at your facility. This greatly accelerates the learning curve and application of the knowledge acquired. He is now ex-Certification body lead auditor now working as consultancy auditor. He has performed hundreds of audits in several industry sectors. As consultancy auditor, he not just report findings, but provide value-added service in recommending appropriate solutions. Experience Consultancy: He has helped over 100 clients in a wide variety of industries achieve ISO 9001,14001,27001,20000, OHSAS 18001 and TS 16949 certification. Industries include automotive, metal stamping and screw machine, fabrication, machining, assembly, Forging electrostatic and chrome plating, heat-treating, coatings, glass, plastic and rubber products, electrical and electronic equipment, assemblies & components, batteries, computer hardware and software, printing, placement and Security help, warehousing and distribution, repair facilities, consumer credit counseling agencies, banks, call centers, etc. Training: He has delivered public and on-site quality management training to over 1000 students. Courses include ISO/TS -RAB approved Lead Auditor, Internal Auditing, Implementation, Documentation, as well as customized ISO/TS courses, PPAP, FMEA, APQP and Control Plans. Auditing: He has conducted over 100 third party registration and surveillance audits and dozens of gap, internal and pre-assessment audits to ISO/QS/TS Standards, in the manufacturing and service sectors. Other services: He has provided business planning, restructuring, asset management, systems and process streamlining services to a variety of manufacturing and service clients such as printing, plastics, automotive, transportation and custom brokerage, warehousing and distribution, electrical and electronics, trading, equipment leasing, etc. Education & professional certification: Pretesh Biswas has held IRCA certified Lead Auditor for ISO 9001,14001 and 27001. He holds a Bachelor of Engineering degree in Mechanical Engineering and is a MBA in Systems and Marketing. Prior to becoming a business consultant 6 years ago, he has worked in several portfolios such as Marketing, operations, production, Quality and customer care. He is also certified in Six Sigma Black belt .

Published

Leave a Reply