Asset and Change Management
77 cards · 6 sections
Acquisition and Procurement (OBJ 4.1, 4.2)
Acquisition
The process of obtaining goods and services. Acquisition is the final act of receiving the product or service after all procurement steps are complete.
Procurement
The entire structured process of sourcing and obtaining goods and services, encompassing all steps before acquisition — needs assessment, vendor evaluation, internal approvals, and contracting.
Purchase Order (PO)
A formal document issued by a purchasing department that authorizes a specific purchase; constitutes a legally binding payment promise — not immediate payment — with terms such as net 15, net 30, or net 60 days.
Purchase Method Types
- Company credit card — low-cost, immediate purchases; organization sets transaction limits and approved categories
- Individual purchase (reimbursement) — employee buys with personal funds and seeks repayment; used when no company card is available or in emergencies
- Purchase order (PO) — formal authorization for larger or more expensive purchases; issued by the purchasing department before goods or services are received
Internal Approval Process for Hardware and Software
- Goal alignment — verify the purchase supports organizational objectives and operational needs
- Budget verification — confirm adequate funds are allocated before committing to a purchase
- Security and compatibility review — ensure the product meets security standards and integrates with existing infrastructure
Post-Procurement Integration Steps
- Compatibility assessment with current systems
- Security configuration and hardening of the new product
- End-user training on the new system or software
- Integration into existing organizational workflows
Acquisition vs. Procurement — Primary Distinction
Scenario: 'exam asks which term describes the entire sourcing and vetting process before a purchase' → Answer: Procurement. Acquisition is the final act of obtaining; procurement encompasses every preceding step.
Purchase Method — Formal Authorization Requirement
Scenario: 'organization requires a signed authorization document before a large hardware order is placed' → Answer: Purchase Order (PO). Company credit card and individual reimbursement are used for smaller, immediate purchases only.
Security Role of Procurement
Procurement is a security control: hardware and software must pass security and compatibility review before purchase is authorized. Scenario: 'employee installs unapproved software without a PO' → violates procurement policy and introduces unauthorized software risk.
Mobile Device Deployments (OBJ 4.1)
BYOD (Bring Your Own Device)
A deployment policy where employees use personally owned devices for work purposes. The employee owns and controls the device; the organization has limited authority to enforce security configurations unless the employee voluntarily enrolls the device in MDM.
COPE (Corporate-Owned, Personally Enabled)
A deployment model where the organization provides and owns the device but permits personal use by the employee. The organization retains full monitoring rights and MDM control over the device.
CYOD (Choose Your Own Device)
A deployment model where the employee selects a device from a set of company-approved options; the organization owns all devices and maintains standardized MDM management. Typically restricted to work use only.
MDM (Mobile Device Management)
Software solution enabling centralized management of mobile devices — enforces corporate policies, deploys patches and applications remotely, and supports remote lock or wipe of enrolled devices to protect corporate data.
Deployment Model Comparison — BYOD, COPE, CYOD
- BYOD — employee owns device; lowest upfront cost for employer; highest security risk; limited MDM enforcement capability
- COPE — company owns and provides device; permits personal use; highest upfront cost; full MDM control; employee privacy concerns
- CYOD — company owns device chosen from approved list; work-use typically only; strong MDM control; moderate cost; employee choice within approved options
Deployment Model Selection Criteria
- Cost — BYOD is lowest upfront but carries hidden security costs; COPE and CYOD have higher upfront hardware costs but lower ongoing support costs due to standardized models
- Security — COPE and CYOD allow full MDM integration and policy enforcement; BYOD cannot guarantee MDM enrollment or mandatory security configurations
- Employee satisfaction — BYOD and CYOD offer personal choice; COPE offers least personal control
Device Ownership — Primary Distinguisher
Scenario: 'exam identifies the deployment model where the employee owns the device' → Answer: BYOD only. Both COPE and CYOD are company-owned models. Ownership determines who has primary control and who bears responsibility.
Maximum Security Control Scenario
Scenario: 'organization requires full MDM control and standardized policy enforcement across all devices' → Answer: COPE or CYOD. BYOD cannot guarantee MDM enrollment or mandatory security configuration because the employee owns the device.
MDM Capabilities — Exam Recognition
Scenario: 'lost company device needs data protected remotely' → Answer: MDM remote wipe. MDM also supports remote lock, policy enforcement, patch deployment, and simultaneous app installation across all enrolled devices.
BYOD Core Security Limitation
Scenario: 'organization cannot mandate encryption on employee devices under BYOD' → reflects the fundamental BYOD limitation: because the employee owns the device, the organization cannot unilaterally enforce security configurations without the employee's cooperation or voluntary MDM enrollment.
Asset Management (OBJ 4.2)
Asset Management
The systematic approach to governance and value realization of assets over their entire lifecycle — covering assignment, classification, monitoring, tracking, and eventual disposal.
Asset Owner
The individual or group assigned accountability for a specific asset; responsible for its use, maintenance, upgrade decisions, and eventual retirement or disposal.
Asset Classification
Categorizing assets by function, value, sensitivity, or other criteria to inform maintenance schedules, replacement timing, and disposal methods. High-value assets require more stringent maintenance; low-value assets may be prioritized for disposal.
Asset Monitoring
Maintaining an inventory record of each asset — including specifications, location, and assigned user — to ensure all assets are accounted for and used optimally.
Asset Tracking
Extending asset monitoring by using specialized software and technologies such as GPS to monitor the real-time physical location, status, and condition of assets.
Enumeration (Asset Management)
Identifying and counting assets connected to a network using scanners and software tools; determines device type, operating system, software versions, and health status. Used to detect unauthorized devices and support patch management.
Two Main Functions of Asset Management
- Assignment and accounting — assign each asset an owner; classify by value and function; clarifies responsibility for maintenance, upgrades, and replacement
- Monitoring and tracking — maintain inventory records (monitoring) and track real-time location or status via specialized software (tracking)
Asset Monitoring vs. Asset Tracking — Distinction
Monitoring maintains a static inventory record (specifications, location, assigned user). Tracking provides real-time dynamic updates on physical location and condition using GPS or tracking software. Tracking extends monitoring.
Enumeration in Security Operations
Regular enumeration produces an accurate, current asset inventory — detects unauthorized devices on the network, identifies outdated operating systems and software, and informs vulnerability and patch management decisions.
Unauthorized Device Detection — Primary Method
Scenario: 'organization needs to identify unauthorized devices connected to the corporate network' → Answer: Enumeration (network scanning). Enumeration compares discovered devices against the authorized asset register to surface unknown or rogue devices.
Monitoring vs. Tracking — Scenario Mapping
Scenario: 'organization needs to know where a specific laptop is physically located right now' → Answer: Asset tracking (GPS or tracking software). Scenario: 'organization needs a record of who is assigned which laptop and its specifications' → Answer: Asset monitoring (inventory record).
MDM as Asset Management Tool
MDM is the primary platform for managing mobile assets — enables remote policy enforcement, patch and app deployment, remote lock/wipe, and maintains a live inventory of all enrolled devices. Applies to both OBJ 4.1 (security techniques) and OBJ 4.2 (asset management implications).
Asset Disposal and Decommissioning (OBJ 4.2)
NIST SP 800-88
NIST Special Publication 800-88 — Guidelines for Media Sanitization. The authoritative federal standard governing sanitization, destruction, and certification procedures during asset disposal and decommissioning.
Sanitization
The process of making data inaccessible and irretrievable from a storage medium using forensic-resistant techniques, without necessarily destroying the physical device.
Overwriting
Sanitization technique replacing existing data on a storage device with random data. Pass count by classification level: 1 pass (low sensitivity), 7 passes (moderate), 35 passes (high). More passes reduce the probability of forensic data recovery.
Degaussing
Sanitization technique using a degausser to generate a strong magnetic field that disrupts magnetic domains on HDDs or magnetic tape — permanently destroys stored data and renders the device incapable of storing data in the future.
Secure Erase
A legacy firmware-level sanitization command for SSDs and HDDs that activates the device's built-in erasure routine to purge all data blocks; largely superseded by Cryptographic Erase due to identified implementation flaws.
Cryptographic Erase (CE)
Sanitization method that destroys the encryption keys protecting data at rest rather than overwriting the data itself; since the data is permanently unreadable without the keys, the device can be reused or resold. Completes in 30–60 seconds.
Destruction (Media Disposal)
Physical elimination of storage media via shredding, pulverizing, melting, or incinerating per NIST SP 800-88 recommendations; used when sanitization alone is insufficient — typically for classified or top-secret data environments.
Certification (Disposal)
Documented proof — an audit log — that data or hardware has been securely sanitized or destroyed; required for regulatory compliance and demonstrates adherence to data security obligations.
Data Retention
Policy defining what data to preserve and for how long, based on regulatory requirements, legal obligations, and operational needs; balances compliance mandates against the expanding attack surface and cost of retaining large data volumes.
Sanitization vs. Destruction — When to Use Each
Sanitization makes data unrecoverable while preserving potential device reuse or resale. Destruction eliminates both data and the physical device. High-security environments handling classified or top-secret data require physical destruction, not sanitization alone.
Cryptographic Erase Advantages
- Speed — deletes only encryption keys, not all data blocks; completes in seconds regardless of drive capacity
- Device reuse — encrypted data remains on the device but is permanently unreadable; device can be safely repurposed or resold
- Modern standard — preferred for SSDs and self-encrypting drives where overwriting is unreliable due to wear-leveling
Data Lifecycle Stages
- Creation — data is generated or received by the organization
- Processing — data is actively used, transformed, or analyzed
- Archiving — data is retained per retention policy for compliance or historical purposes
- Destruction — data is sanitized or physically destroyed when the retention period expires or the asset is decommissioned
Data Retention Risk Principle
Retaining data creates regulatory value (compliance, historical analysis, dispute resolution) but simultaneously expands the attack surface and storage cost. The more data retained, the more extensive the required security controls.
Fastest Sanitization Method for Large Drives
Scenario: 'organization needs to sanitize a large-capacity drive quickly before redeployment' → Answer: Cryptographic Erase. Completes in 30–60 seconds by destroying encryption keys; overwriting the same drive would take hours.
Method That Renders a Device Permanently Unusable
Scenario: 'organization must dispose of HDDs in a way that prevents any future storage use' → Answer: Degaussing (destroys magnetic properties, device cannot store data afterwards) or physical destruction (shredding, pulverizing, melting, incinerating).
Classified Data Disposal — Primary Method
Scenario: 'agency is decommissioning systems containing classified or top-secret data' → Answer: Physical destruction (shredding, pulverizing, melting, or incinerating). Sanitization alone is insufficient for classified environments.
NIST SP 800-88 — Exam Recognition
Scenario: 'exam asks which document provides authoritative guidance on media sanitization' → Answer: NIST SP 800-88 (Guidelines for Media Sanitization). Governs sanitization, destruction, and certification procedures.
Proof of Disposal for Regulatory Compliance
Scenario: 'auditor requests evidence that decommissioned storage media was securely disposed of' → Answer: Certification (audit log documenting the sanitization or destruction process). Required for regulated industries and organizations handling sensitive data.
Overwriting Pass Counts — Classification Mapping
1 pass: low-sensitivity data. 7 passes: moderate-sensitivity. 35 passes: high-sensitivity. Higher classification levels require more overwriting passes to reduce forensic recovery probability. Know the 1/7/35 mapping for scenario questions.
Change Management (OBJ 1.3)
Change Management
The structured strategy for transitioning individuals, teams, or entire organizations from a current state to a desired future state in a controlled, planned manner — preventing unauthorized modifications, security gaps, and operational disruptions.
Change Advisory Board (CAB)
A body of representatives from multiple organizational units responsible for evaluating proposed changes — assesses viability, potential security impact, and alignment with organizational objectives before authorizing implementation.
Change Owner
The individual or team responsible for initiating and advocating for a change request; accountable for detailing the change's necessity, expected benefits, and implementation challenges.
Stakeholder (Change Management)
Any person or team with a vested interest in a proposed change — either directly impacted by it or playing a role in its assessment or implementation. Must be consulted and informed before the change is executed.
Impact Analysis
Assessment of the potential consequences of a proposed change, including immediate operational effects, long-term business impacts, security implications, and unforeseen risks; required before a change is submitted for CAB approval.
Change Approval Workflow
- Change owner submits a request detailing the need, benefits, and risks of the proposed change
- Impact analysis is conducted to assess operational, security, and business effects
- CAB evaluates the proposal for viability, impact, and organizational alignment
- CAB approves or rejects; approved changes are scheduled and implemented
Stakeholder Types in Change Management
- Technical stakeholders — developers, system administrators, and engineers directly executing or affected by the change
- Business stakeholders — support teams, management, and compliance officers affected by change outcomes
- End-user stakeholders — employees or customers whose daily workflows are impacted by the change
Change Management Security Rationale
Uncontrolled changes are a primary source of security gaps and misconfigurations in enterprise networks. Structured change management ensures every modification undergoes security review and impact analysis before implementation, preventing unauthorized changes from introducing vulnerabilities.
Change Approval Authority — Primary Answer
Scenario: 'exam asks who is responsible for approving proposed changes in an organization' → Answer: Change Advisory Board (CAB). The CAB evaluates viability, security impact, and alignment before granting authorization.
Change Owner Role — Scenario Mapping
Scenario: 'exam identifies the person who initiates and advocates for a change request' → Answer: Change owner. The change owner proposes and justifies; the CAB independently evaluates and approves. These are distinct roles.
Pre-Approval Requirement — Impact Analysis
Scenario: 'what must be completed before a change is submitted to the CAB for approval' → Answer: Impact analysis. Assesses what could go wrong, who is affected, and whether business operations will be disrupted.
OBJ 1.3 — Change Management and Security Importance
OBJ 1.3 focuses on why change management matters for security: unauthorized or uncontrolled changes are a leading cause of misconfigurations and exploitable vulnerabilities. Change management prevents this by requiring approval, documentation, and testing for every modification.
Change Management: Technical Implications and Documentation (OBJ 1.3)
Allow List
A security control specifying which entities — IP addresses, applications, or users — are explicitly permitted to access a given resource. Used by routers and firewalls; entities not on the list are denied by default.
Deny List (Block List)
A security control specifying which entities are explicitly prevented from accessing a given resource. The complement of an allow list; entities not on the deny list are permitted by default.
Maintenance Window
A pre-scheduled period during which changes are implemented to minimize disruption to end users and business operations; allows downtime-inducing changes to be executed during low-impact hours.
Version Control (Change Documentation)
A system that tracks and manages changes to documents, software, and configurations over time; enables rollback to a previous stable version if an implemented change causes failures or instability.
Restricted Activities
Operations designated as restricted due to their potential impact on system health or security — for example, accessing a protected database or taking a critical server offline. Must be explicitly verified before a change is approved.
Legacy Application
Older software still in use despite the availability of newer alternatives; particularly sensitive to changes because it is less flexible, has limited vendor support, and may break on updates that modern applications handle gracefully.
Dependency (Technical Change Context)
A relationship where one system, service, or application relies on another to function correctly; changes to one component can produce cascading failures across dependent systems and partner architectures.
Technical Implications to Evaluate Before Implementing a Change
- Allow and deny lists — review whether the change requires adding or removing entries; inadvertent changes can grant or revoke critical access
- Restricted activities — verify whether the change involves any operations flagged as restricted
- Downtime — estimate potential downtime; schedule within a maintenance window if significant
- Service and application restarts — identify services that must restart; assess impact on active users and data in transit
- Legacy applications — determine whether older systems in the environment are sensitive to the proposed change
- Dependencies — map all system dependencies before implementation to prevent cascading failures
Three Components of Change Documentation
- Version control — track changes to all affected documents, software, and configurations; enables rollback if the change fails
- Documentation updates — update network and system diagrams, policies, procedures, and change requests or trouble tickets after implementation
- Post-implementation review — assess what succeeded or failed; revise policies and procedures to prevent recurrence of issues
Allow and Deny List Review During Changes
Any change modifying IP addresses, ports, services, or firewall rules requires a concurrent review of existing allow and deny lists. Failing to review these lists during a firewall upgrade can inadvertently grant unauthorized access or block legitimate services.
Scheduling Changes to Minimize Impact
Scenario: 'organization needs to install a critical patch requiring a server reboot' → Answer: Schedule during a maintenance window to minimize disruption to end users and avoid peak business hours.
Cascading Failure After a Change — Root Cause
Scenario: 'a minor configuration change causes unexpected failures in multiple downstream systems' → Answer: Insufficient dependency mapping before implementation. Always map dependencies before executing changes.
Post-Change Documentation Requirements
Scenario: 'what must be updated after a change is successfully implemented' → Answer: Network and system diagrams (reflect new state), policies and procedures (address issues found), and change requests or trouble tickets (record completion and outcomes).
Change Rollback Mechanism
Scenario: 'an implemented change causes system instability and must be reversed' → Answer: Version control enables revert to the previous stable state. Version control is a mandatory component of the change documentation process.
Allow List vs. Deny List — Primary Distinction
Allow list: explicitly permits specified entities, denies all others by default. Deny list: explicitly blocks specified entities, permits all others by default. Both must be reviewed during any firewall or access control change to prevent inadvertent access policy violations.