DOCSLIB.ORG

Volume 3 Configuration and Change Management Version 1.1

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Volume 3 Configuration and Change Management Version 1.1 CRR Supplemental Resource Guide Volume 3 Configuration and Change Management Version 1.1 Copyright 2016 Carnegie Mellon University This material is based upon work funded and supported by Department of Homeland Security under Contract No. FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center sponsored by the United States Department of Defense. Any opinions, findings and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of Department of Homeland Security or the United States Department of Defense. NO WARRANTY. THIS CARNEGIE MELLON UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT INFRINGEMENT. [Distribution Statement A] This material has been approved for public release and unlimited distribution. Please see Copyright notice for non-US Government use and distribution. CERT® and OCTAVE® are registered marks of Carnegie Mellon University. DM-0003277 Distribution Statement A: Approved for Public Release; Distribution is Unlimited Table of Contents I. Introduction ............................................................................................................................................................... 1 Series Welcome ......................................................................................................................................................... 1 Audience .................................................................................................................................................................... 3 II. Configuration and Change Management ............................................................................................................... 4 Overview .................................................................................................................................................................... 4 Configuration and Change Management Terms ........................................................................................................ 5 Configuration and Change Management Process ..................................................................................................... 5 III. Create a Configuration and Change Management Plan ....................................................................................... 8 Before You Begin ....................................................................................................................................................... 8 Step 1. Obtain support for configuration and change management planning. ........................................................... 9 Step 2. Budget for configuration and change management. ...................................................................................... 9 Step 3. Define roles and responsibilities. ................................................................................................................... 9 Step 4. Gather existing policies, procedures, and documentation related to configuration and change management. ........................................................................................................................................................... 10 Step 5. Identify and prioritize critical organizational services that will require change and configuration management. ........................................................................................................................................................... 10 Step 6. Validate critical services with stakeholders and establish a configuration change review board. ................ 11 Step 7. Develop a change request process. ............................................................................................................ 11 Step 8. Determine how changes will be communicated to the organization. ........................................................... 12 Step 9. Develop a configuration and change management training plan. ................................................................ 12 Step 10. Identify tools for use in implementing and monitoring configurations. ........................................................ 12 Step 11. Plan for capacity management. ................................................................................................................. 13 Output of Section III ................................................................................................................................................. 14 IV. Identify Configuration Items ................................................................................................................................ 15 Before You Begin ..................................................................................................................................................... 15 Step 1. Map critical organizational services to stakeholders and related services. .................................................. 15 Step 2. Identify assets related to the critical services. ............................................................................................. 16 Step 3. Identify the configuration items of the assets that will undergo change and require change and configuration management. ..................................................................................................................................... 16 Step 4. Determine a configuration baseline for each configuration item. ................................................................. 17 Output of Section IV ................................................................................................................................................. 17 V. Implement and Control Configuration Changes ................................................................................................. 18 Before You Begin ..................................................................................................................................................... 18 Step 1. Evaluate change requests and approvals. ................................................................................................... 19 Step 2. Model configuration changes in a test environment. .................................................................................... 20 Step 3. Deploy changes in the production environment. .......................................................................................... 21 Step 4. Determine the success or failure of changes. .............................................................................................. 22 Step 5. Roll back unsuccessful changes. ................................................................................................................. 23 Step 6. Close out completed changes. .................................................................................................................... 23 Distribution Statement A: Approved for Public Release; Distribution is Unlimited Step 7. Change configuration baselines. ................................................................................................................. 25 Output of Section V .................................................................................................................................................. 26 VI. Monitor Configuration Changes .......................................................................................................................... 27 Before You Begin ..................................................................................................................................................... 27 Step 1. Identify systems or components not specified in documentation. ................................................................ 27 Step 2. Identify disparities between authorized, approved baselines and actual, implemented baselines. .............. 28 Step 3. Monitor system logs for unauthorized changes. .......................................................................................... 28 Step 4. Collect existing audits and configuration control records. ............................................................................ 28 Step 5. Define remediation action. ........................................................................................................................... 29 Step 6. Execute monitoring plan. ............................................................................................................................. 29 Output of Section VI ................................................................................................................................................. 30 VII. Conclusion ........................................................................................................................................................... 31 Appendix A. Example Change Request Template ................................................................................................... 32 Appendix B. Example Change Impact
Load more

Recommended publications
  • Robot Vision: Projective Geometry
    Robot Vision: Projective Geometry Ass.Prof. Friedrich Fraundorfer SS 2018 1 Learning goals . Understand homogeneous coordinates . Understand points, line, plane parameters and interpret them geometrically . Understand point, line, plane interactions geometrically . Analytical calculations with lines, points and planes . Understand the difference between Euclidean and projective space . Understand the properties of parallel lines and planes in projective space . Understand the concept of the line and plane at infinity 2 Outline . 1D projective geometry . 2D projective geometry ▫ Homogeneous coordinates ▫ Points, Lines ▫ Duality . 3D projective geometry ▫ Points, Lines, Planes ▫ Duality ▫ Plane at infinity 3 Literature . Multiple View Geometry in Computer Vision. Richard Hartley and Andrew Zisserman. Cambridge University Press, March 2004. Mundy, J.L. and Zisserman, A., Geometric Invariance in Computer Vision, Appendix: Projective Geometry for Machine Vision, MIT Press, Cambridge, MA, 1992 . Available online: www.cs.cmu.edu/~ph/869/papers/zisser-mundy.pdf 4 Motivation – Image formation [Source: Charles Gunn] 5 Motivation – Parallel lines [Source: Flickr] 6 Motivation – Epipolar constraint X world point epipolar plane x x’ x‘TEx=0 C T C’ R 7 Euclidean geometry vs. projective geometry Definitions: . Geometry is the teaching of points, lines, planes and their relationships and properties (angles) . Geometries are defined based on invariances (what is changing if you transform a configuration of points, lines etc.) . Geometric transformations
    [Show full text]
  • Managing the Configuration of Information Systems with a Focus on Security
    MANAGING THE CONFIGURATION OF INFORMATION SYSTEMS WITH A FOCUS ON SECURITY Shirley Radack, Editor Computer Security Division Information Technology Laboratory National Institute of Standards and Technology U.S. Department of Commerce Organizations have to make frequent changes to their information systems in order to implement new and updated hardware and software components, correct software flaws and other errors, address new security threats, and adapt to changing business objectives. These constant changes result in adjustments being made to the configuration of information systems; these activities could have an impact on the security of the systems and operations. In developing information systems, organizations employ many components that can be interconnected in different arrangements to meet the organization’s business, mission, and information security needs. To protect information systems and information, organizations need techniques for the secure configuration, operation, and management of system components, including mainframes, workstations, servers, networks, operating systems, middleware, and applications, and for the management and control of risks to systems and information. The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) has issued a new guide to help organizations develop a well-defined process for managing and controlling secure system configurations, and for managing risks in information systems. NIST Special Publication 800-128, Guide to Security- Focused
    [Show full text]
  • COMBINATORICS, Volume
    http://dx.doi.org/10.1090/pspum/019 PROCEEDINGS OF SYMPOSIA IN PURE MATHEMATICS Volume XIX COMBINATORICS AMERICAN MATHEMATICAL SOCIETY Providence, Rhode Island 1971 Proceedings of the Symposium in Pure Mathematics of the American Mathematical Society Held at the University of California Los Angeles, California March 21-22, 1968 Prepared by the American Mathematical Society under National Science Foundation Grant GP-8436 Edited by Theodore S. Motzkin AMS 1970 Subject Classifications Primary 05Axx, 05Bxx, 05Cxx, 10-XX, 15-XX, 50-XX Secondary 04A20, 05A05, 05A17, 05A20, 05B05, 05B15, 05B20, 05B25, 05B30, 05C15, 05C99, 06A05, 10A45, 10C05, 14-XX, 20Bxx, 20Fxx, 50A20, 55C05, 55J05, 94A20 International Standard Book Number 0-8218-1419-2 Library of Congress Catalog Number 74-153879 Copyright © 1971 by the American Mathematical Society Printed in the United States of America All rights reserved except those granted to the United States Government May not be produced in any form without permission of the publishers Leo Moser (1921-1970) was active and productive in various aspects of combin• atorics and of its applications to number theory. He was in close contact with those with whom he had common interests: we will remember his sparkling wit, the universality of his anecdotes, and his stimulating presence. This volume, much of whose content he had enjoyed and appreciated, and which contains the re• construction of a contribution by him, is dedicated to his memory. CONTENTS Preface vii Modular Forms on Noncongruence Subgroups BY A. O. L. ATKIN AND H. P. F. SWINNERTON-DYER 1 Selfconjugate Tetrahedra with Respect to the Hermitian Variety xl+xl + *l + ;cg = 0 in PG(3, 22) and a Representation of PG(3, 3) BY R.
    [Show full text]
  • Performance Evaluation of Genetic Algorithm and Simulated Annealing in Solving Kirkman Schoolgirl Problem
    FUOYE Journal of Engineering and Technology (FUOYEJET), Vol. 5, Issue 2, September 2020 ISSN: 2579-0625 (Online), 2579-0617 (Paper) Performance Evaluation of Genetic Algorithm and Simulated Annealing in solving Kirkman Schoolgirl Problem *1Christopher A. Oyeleye, 2Victoria O. Dayo-Ajayi, 3Emmanuel Abiodun and 4Alabi O. Bello 1Department of Information Systems, Ladoke Akintola University of Technology, Ogbomoso, Nigeria 2Department of Computer Science, Ladoke Akintola University of Technology, Ogbomoso, Nigeria 3Department of Computer Science, Kwara State Polytechnic, Ilorin, Nigeria 4Department of Mathematical and Physical Sciences, Afe Babalola University, Ado-Ekiti, Nigeria [email protected]|[email protected]|[email protected]|[email protected] Received: 15-FEB-2020; Reviewed: 12-MAR-2020; Accepted: 28-MAY-2020 http://dx.doi.org/10.46792/fuoyejet.v5i2.477 Abstract- This paper provides performance evaluation of Genetic Algorithm and Simulated Annealing in view of their software complexity and simulation runtime. Kirkman Schoolgirl is about arranging fifteen schoolgirls into five triplets in a week with a distinct constraint of no two schoolgirl must walk together in a week. The developed model was simulated using MATLAB version R2015a. The performance evaluation of both Genetic Algorithm (GA) and Simulated Annealing (SA) was carried out in terms of program size, program volume, program effort and the intelligent content of the program. The results obtained show that the runtime for GA and SA are 11.23sec and 6.20sec respectively. The program size for GA and SA are 2.01kb and 2.21kb, respectively. The lines of code for GA and SA are 324 and 404, respectively. The program volume for GA and SA are 1121.58 and 3127.92, respectively.
    [Show full text]
  • Business Rule Based Configuration Management and Software System Implementation Using Decision Tables
    Business Rule Based Configuration Management and Software System Implementation Using Decision Tables Olegas Vasilecas, Aidas Smaizys Vilnius Gediminas Technical University, Sauletekio av. 11, LT-10223 Vilnius, Lithuania [email protected], [email protected] Abstract. Deployment and customization of the software in different information systems of separate organizations challenge large requirement conformity, project and specification management, design and architecture complexity, code integration, compatibility and interoperability issues, frequently causing the need of reengineering through the entire all the system development lifecycle. The paper proposes new business rule based method of information system configuration management and automated way of configuration implementation into the final software system code. 1 Introduction Business systems are functioning according to business rules in specific business domain. Due to dynamic of its nature, business environment is changing frequently according to internal and external influences such as changes in law, new competition etc. [1]. However Business rules (BR) of particular problem domain are similar in several organizations but they are never applied the same way even they depend on the same legal regulations. Production and implementation of such a software system into the large amount of slightly different information systems of separate organizations challenge large requirement conformity, project and specification management, design and architecture complexity,
    [Show full text]
  • Blocking Set Free Configurations and Their Relations to Digraphs and Hypergraphs
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Elsevier - Publisher Connector DISCRETE MATHEMATICS ELSIZI’IER Discrete Mathematics 1651166 (1997) 359.-370 Blocking set free configurations and their relations to digraphs and hypergraphs Harald Gropp* Mihlingstrasse 19. D-69121 Heidelberg, German> Abstract The current state of knowledge concerning the existence of blocking set free configurations is given together with a short history of this problem which has also been dealt with in terms of digraphs without even dicycles or 3-chromatic hypergraphs. The question is extended to the case of nonsymmetric configurations (u,, b3). It is proved that for each value of I > 3 there are only finitely many values of u for which the existence of a blocking set free configuration is still unknown. 1. Introduction In the language of configurations the existence of blocking sets was investigated in [3, 93 for the first time. Further papers [4, 201 yielded the result that the existence problem for blocking set free configurations v3 has been nearly solved. There are only 8 values of v for which it is unsettled whether there is a blocking set free configuration ~7~:u = 15,16,17,18,20,23,24,26. The existence of blocking set free configurations is equivalent to the existence of certain hypergraphs and digraphs. In these two languages results have been obtained much earlier. In Section 2 the relations between configurations, hypergraphs, and digraphs are exhibited. Furthermore, a nearly forgotten result of Steinitz is described In his dissertation of 1894 Steinitz proved the existence of a l-factor in a regular bipartite graph 20 years earlier then Kiinig.
    [Show full text]
  • ITIL Asset and Configuration Management in the Cloud
    ITIL Asset and Configuration Management in the Cloud January 2017 © 2017, Amazon Web Services, Inc. or its affiliates. All rights reserved. Notices This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether express or implied. This document does not create any warranties, representations, contractual commitments, conditions or assurances from AWS, its affiliates, suppliers or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. Contents Introduction 1 What Is ITIL? 1 AWS Cloud Adoption Framework 2 Asset and Configuration Management in the Cloud 3 Asset and Configuration Management and AWS CAF 5 Impact on Financial Management 5 Creating a Configuration Management Database 6 Managing the Configuration Lifecycle in the Cloud 8 Conclusion 9 Contributors 10 Abstract Cloud initiatives require more than just the right technology. They also must be supported by organizational changes, such as people and process changes. This paper is intended for IT service management (ITSM) professionals who are supporting a hybrid cloud environment that leverages AWS. It outlines best practices for asset and configuration management, a key area in the IT Infrastructure Library (ITIL), on the AWS cloud platform.
    [Show full text]
  • Software Project Monitoring and Control
    Module 12 Software Project Monitoring and Control Version 2 CSE IIT, Kharagpur Lesson 31 Risk Management and Software Configuration Management Version 2 CSE IIT, Kharagpur Specific Instructional Objectives At the end of this lesson the student would be able to: • Identify the main categories of risks which can affect a software project. • Explain how to assess a project risk. • Identify the main strategies to plan for risk containment. • Explain what risk leverage is. • Explain how to handle the risk of schedule slippage. • Explain what is meant by configuration of a software product. • Differentiate among release, version and revision of a software product. • Explain the necessity of software configuration management. • Identify the principal activities of software configuration management. • Identify the activities carried out during configuration identification. • Identify the activities carried out during configuration control. • Identify the popular configuration management tools. Risk management A software project can be affected by a large variety of risks. In order to be able to systematically identify the important risks which might affect a software project, it is necessary to categorize risks into different classes. The project manager can then examine which risks from each class are relevant to the project. There are three main categories of risks which can affect a software project: Project risks. Project risks concern varies forms of budgetary, schedule, personnel, resource, and customer-related problems. An important project risk is schedule slippage. Since, software is intangible, it is very difficult to monitor and control a software project. It is very difficult to control something which cannot be seen. For any manufacturing project, such as manufacturing of cars, the project manager can see the product taking shape.
    [Show full text]
  • Quality Assurance and Configuration Management
    Quality Assurance and Configuration Management Energy, Climate, & Sandia National Laboratories implements quality assurance and configuration Infrastructure Security systems essential to the control and traceability of modeling used to demonstrate regulatory compliance. Introduction agencies, including, most significantly, the U.S. Nuclear Regulatory Commission Sandia National Laboratories has a long and the U.S. Environmental Protection history of involvement in significant Agency, as well as various federal, state, national programs directed at solving and other organizations. Among more the national problem of managing the notable successes of this work has been disposal of various forms of nuclear the adaptation of quality assurance wastes. These involvements include to activities sponsored largely by the significant responsibility on the Waste U.S. Department of Energy involved Isolation Pilot Plant (WIPP), the Yucca in the characterization, selection, and Mountain Site Characterization Project performance analyses associated with (YMP), the Hanford Tank Waste programs involving nuclear waste Remediation System (TWRS), and management. Quality assurance the Greater Confinement Disposal requirements originated from a need to (GCD) programs. In addition, control and assure the quality of nuclear Sandia has also played major roles power plant design, construction, and in nuclear waste transportation, operations; modifying these concepts and in several environmental for application to scientific investigation remediation and restoration and characterization activities was a programs, including those at Fernald, necessary and beneficial effort that Ohio, and Hanford, Washington. has proven successful for nuclear waste A key to the success of our activities management. on these programs, particularly for Decades of experience under the WIPP, YMP, TWRS, and GCD, was the scrutiny of independent audits, development and application of quality identifying quality deficiencies, and assurance for program activities.
    [Show full text]
  • Service Asset and Configuration Management (SACM/CMDB) Process
    Service Transition SERVICE ASSET AND CONFIGURATION MANAGEMENT PROCESS VERSION: 4.3 REVISION DATE: February 23, 2017 Service Transition USER GUIDE Service Asset and Configuration Management Process 4.3 | 02/23/2017 Contents Section 1. Introduction ......................................................................................... 1 1.1 Purpose .............................................................................................. 1 1.2 Goal .................................................................................................... 1 1.3 Overview ............................................................................................ 1 1.4 Key Relationships with other processes ........................................ 2 1.5 Definitions .......................................................................................... 2 Section 2. Roles and Responsibilities .................................................................. 4 2.1 Process Owner/Configuration Manager ......................................... 4 2.2 Configuration Item Class Owner ..................................................... 4 2.3 Configuration Item Class Administrator ......................................... 4 2.4 Configuration Item Company Administrator .................................. 5 2.5 IT Service Continuity Management (ITSCM) Role......................... 5 2.6 IT Staff ................................................................................................ 5 2.7 ITSM Product Manager ....................................................................
    [Show full text]
  • Self-Dual Configurations and Regular Graphs
    SELF-DUAL CONFIGURATIONS AND REGULAR GRAPHS H. S. M. COXETER 1. Introduction. A configuration (mci ni) is a set of m points and n lines in a plane, with d of the points on each line and c of the lines through each point; thus cm = dn. Those permutations which pre­ serve incidences form a group, "the group of the configuration." If m — n, and consequently c = d, the group may include not only sym­ metries which permute the points among themselves but also reci­ procities which interchange points and lines in accordance with the principle of duality. The configuration is then "self-dual," and its symbol («<*, n<j) is conveniently abbreviated to na. We shall use the same symbol for the analogous concept of a configuration in three dimensions, consisting of n points lying by d's in n planes, d through each point. With any configuration we can associate a diagram called the Menger graph [13, p. 28],x in which the points are represented by dots or "nodes," two of which are joined by an arc or "branch" when­ ever the corresponding two points are on a line of the configuration. Unfortunately, however, it often happens that two different con­ figurations have the same Menger graph. The present address is concerned with another kind of diagram, which represents the con­ figuration uniquely. In this Levi graph [32, p. 5], we represent the points and lines (or planes) of the configuration by dots of two colors, say "red nodes" and "blue nodes," with the rule that two nodes differently colored are joined whenever the corresponding elements of the configuration are incident.
    [Show full text]
  • 2. Configuration Management
    Computer Science and Software Engineering University of Wisconsin - Platteville 2. Configuration Management Yan Shi SE 3730 / CS 5730 Lecture Notes Outline . What is configuration management? — Identification — Change control — Status accounting — Audit and review . CM techniques and practices — lock-modify-unlock — copy-modify-merge — RCS — branching — deltas . CM tools Why is CM needed? . ``This worked yesterday and doesn't work now.” What happened? . ``The user manual says to do this, but when I do it, something different happens.'' Which is correct, the manual or the code? Why was one changed? . ``The code changes that I made last week are no longer in the code.” What happened to the fix? Who changed the code and Why? . ``The listing doesn't match what the program does!'' Which is correct? . ``Did the bug get fixed in this copy, too?'' Why is CM needed? . Control the changes — Versions of documents need to be combined to form a product, or configuration — With many people working on many files, inconsistencies can occur . Required for testing — We must know and control what source was used to produce a software system in order to know what is being tested — We need to be able to build and rebuild a software system reliably . Reduce the quality cost — https://www.youtube.com/watch?v=Ij1yDpfZI8Q CM CONCEPTS AND COMPONENTS What is Configuration Management? . Software CM is a discipline for managing the evolution of software systems throughout all stages of the software life cycle. SCM is a component of SQA system. — Infrastructure component — Organizational framework . SQA teams are often required to take the responsibility of managing the CM system.
    [Show full text]