How Can We Help?

Section 12 – Asset and Change Management

You are here:
< All Topics

CompTIA IT Security Course

 

Section 12

Asset and Change Management

 

🔹 What role does the Change Advisory Board (CAB) play?
Answer:
The Change Advisory Board (CAB) is responsible for evaluating and approving (or rejecting) proposed changes in an IT environment. It ensures that:

Risks are properly assessed

Business impacts are considered

Necessary resources and rollback plans are in place

Changes are aligned with security and operational policies

Summary: The CAB acts as a gatekeeper for stability, ensuring that changes are controlled, reviewed, and justified before implementation.

🔐 In smaller organisations, this may be informal or handled by a senior technical lead, but the principle remains the same: structured accountability before change.

 

🔹 Why is a baseline configuration important in forensic investigations?
Answer:
A baseline configuration provides a documented, secure, and approved state of a system. In forensic investigations, it is essential because:

It enables comparison between the current (possibly compromised) system state and the original known-good state

It helps investigators identify unauthorised modifications, malware injections, or configuration drift

It supports the timeline and scope analysis of an incident

Summary: The baseline is the reference point—without it, there’s no clear way to detect tampering, misconfigurations, or signs of breach.

 

Why is asset classification important in cybersecurity?

“To determine the appropriate level of protection, handling, and access control based on an asset’s confidentiality, integrity, and availability value—so the most critical assets receive the strongest safeguards.”

3. List three key risks of implementing changes without formal change management.

“Changes couldn’t be traced – who made them and why, changes might not be easy to revert if there are problems, risks might not be correctly anticipated or planned for in advance.”

Lack of traceability = audit failure

No rollback plan = increased downtime

Poor risk planning = security or service exposure

 

🎯 Mini Quiz Results
Q1:
Question: A new web server is deployed in production without notifying the security team. Which process has most likely failed?
Your Answer: B. Change control
✅ Correct.

Deploying without review or coordination = classic failure of change control. This bypasses risk evaluation, stakeholder awareness, and rollback planning.

Q2:
Question: Which of the following would best support the enforcement of a secure baseline?
Your Answer: B. Configuration drift detection tools
✅ Correct.

These tools identify when current configurations deviate from the baseline, making them essential for maintaining compliance and detecting tampering.

Q3:
Question: An organization maintains a detailed map of software, firmware, and hardware versions across all machines. This is most likely a:
Your Answer: B. Configuration Management Database (CMDB)
✅ Correct.

A CMDB provides a structured, queryable inventory of all system configurations and relationships—central to asset and change control in enterprise IT.

 

💬 4. Application Prompt
Scenario: You’re working as a Linux SysAdmin contractor. A developer pushes a kernel patch directly to a staging server without documentation or testing.

What should your response protocol include?

How would you address this to prevent recurrence while preserving team dynamics?

This scenario tests both your technical and soft-skill judgement—feel free to write out a short answer or talk through your approach.

 

4. Application Prompt: answer:
Inform the developer that kernel patches should not be pushed to staging servers without first testing and documenting NOR without first requesting a Change using the Change Management process, to have the proposed change approved by the CAB. The Change must first be approved by the CAB before it can be pushed out to the servers.

 

🧩 Application Prompt Review
Scenario Recap:
A developer pushes a kernel patch to a staging server without documentation, testing, or change process.

Your Response (paraphrased):

“Inform the developer that kernel patches should not be pushed to staging without prior testing, documentation, or CAB-approved change request.”

✅ Strong Points:

You correctly invoked the Change Management process as a non-negotiable control point.

You referenced both CAB approval and the need for documentation and testing, which demonstrates understanding of both policy and technical governance.

You framed it as an instructional response, which is ideal in operational settings where clarity is paramount.

🔧 Opportunity to Strengthen:
To make it even more exam and enterprise-ready, you could:

Mention risk implications (e.g. instability, security exposure).

Offer a corrective action: e.g. rollback the patch or validate its impact.

Preserve collaborative tone – especially in cross-functional teams.

📝 Suggested Final Response (Polished)
“Inform the developer that kernel patches must never be deployed to staging or production environments without prior testing, documentation, and formal approval via the Change Management process. A Request for Change (RFC) must be submitted and reviewed by the Change Advisory Board (CAB). This ensures technical risk is assessed and mitigated. Going forward, I’d recommend rolling back the unapproved patch if feasible and resubmitting the change request through the proper channel.”

Outcome:
✔️ You’ve clearly internalised both the technical and process implications of unregulated change. This is a Security+ and real-world success response.

 

 

 

 

 

 

 

 

 

 

Tags:
Table of Contents