Security Procedures — Flashcards

CCB: the formal governance body that reviews and approves/rejects proposed IT changes. Seven-step workflow: (1) Scope definition — what changes, which systems, why. (2) Risk analysis — security and operational impact assessment. (3) Implementation plan — step-by-step instructions with timing. (4) End-user impact assessment — notification requirements. (5) CCB review and approval — board decision (approve/reject/modify). (6) Backout plan — documented rollback procedure, required before approval. (7) Documentation — post-implementation record of change and outcome. A change without a backout plan should be rejected at step 5.

Backout plan: a documented, tested procedure for reverting a system change to its previous state if the change fails or produces unacceptable results. Must be completed BEFORE the change window begins. Why required before approval: (1) A failed change without a rollback plan leaves the system in an undefined, potentially insecure state. (2) Improvising recovery under pressure during a failed change extends downtime and increases error risk. (3) Some changes cannot be easily reversed without prior preparation (database schema changes, certificate replacements). The CCB's responsibility includes verifying that the backout plan exists, is complete, and has been tested. A backup alone is not a backout plan — it is a data recovery mechanism; the plan specifies the exact steps to reverse the change.

Emergency changes: changes that must be implemented immediately due to critical security risk (actively exploited vulnerability, system failure) and cannot wait for the next scheduled CCB meeting. Emergency process differences: Expedited approval from a designated authority (CISO, IT director on-call) rather than full CCB review. Speed is prioritized while maintaining accountability. What stays the same: risk assessment (even if brief), documentation (completed post-implementation), backout plan (even if simplified), and CCB review at the next scheduled meeting. What the emergency process does NOT do: eliminate approval entirely; allow completely undocumented changes. An unapproved, undocumented emergency change is still a change management violation regardless of the emergency justification.

(1) AUP acknowledgment: first required step before any system access; creates documented notice of permitted/prohibited activities. (2) Account creation with least privilege: minimum permissions for current job role; no speculative future access. (3) Role-based group assignment: RBAC groups based on job function, inheriting defined permissions. (4) Pre-configured hardware provisioning: devices with EDR, encryption, MDM enrollment pre-installed; not blank hardware for self-configuration. (5) Security awareness training: completed before unescorted access to facilities or systems; covers phishing, data handling, incident reporting. Each step has a security purpose: AUP = legal notice; least privilege = attack surface reduction; pre-configured hardware = consistent security baseline; awareness training = human layer defense.

Immediately deleting a departing employee's account may permanently destroy: EFS (Encrypting File System) keys — files encrypted by the account become unreadable without the account's certificate. Digital signature verification — documents signed by the account may become unverifiable. Certificate associations — services or configurations tied to the account's certificate may fail. Audit log continuity — historical log entries may lose their account context. Correct process: Disable the account immediately on the last day (preventing authentication — the security goal), retain it for a review period (30–90 days), resolve all cryptographic dependencies, then delete. The disable/delete distinction is one of the most commonly tested offboarding facts on Security+.

Offboarding must be pre-planned and assigned to specific roles with clear responsibilities. Complete checklist covers: Logical access: disable all accounts (AD, email, VPN, cloud, SaaS); revoke MFA tokens; remove from distribution lists. Physical access: deactivate badge; recover access cards, keys, and security tokens; remove from physical access lists. Hardware recovery: recover laptop, phone, tablet; document with receipt. Data management: transfer business-critical data to successor; handle personal data per policy. Remote access: terminate active VPN sessions; revoke certificate-based remote access. All steps must be completed simultaneously, not sequentially over days — particularly access removal, which is a same-day requirement.

Security playbook: a documented, step-by-step procedure for responding to a specific type of security event or performing a security operation. Operationalizes incident response plans into actionable instructions. Four structural elements: (1) Step-by-step actions: specific, actionable instructions (not vague guidance like "contain the system" but exact steps like "disable switch port listed in asset database"). (2) Conditional logic: decision points directing responders based on specific criteria (if X then escalate; if Y then proceed). (3) Roles and responsibilities: who performs each step. (4) Revision process: playbooks must be updated as threats evolve, technology changes, or post-incident reviews identify gaps. Common types: phishing response, ransomware containment, account compromise, DDoS mitigation.

SOAR (Security Orchestration, Automation, and Response): a platform that connects security tools and executes playbook steps automatically when trigger conditions are met. Three capabilities: (1) Orchestration: connects disparate security tools (SIEM, EDR, firewall, ticketing, threat intelligence) and coordinates actions across them based on playbook logic. Eliminates manual tool-switching. (2) Automation: executes playbook steps automatically when triggers fire, without human intervention for high-confidence scenarios. Reduces MTTR from minutes/hours to seconds. (3) Response: takes active response actions — blocking IPs, disabling accounts, quarantining email, isolating endpoints — actions that analysts would perform manually, now executed in seconds. Requires: playbooks must exist first; SOAR automates their execution but cannot invent the procedure itself.

Centralized: single security team (CISO + security dept) makes all decisions; enforced uniformly. Advantages: consistent standards, unified enterprise visibility, efficient resource use, clear accountability. Disadvantages: slow to adapt to business unit needs; single point of failure. Decentralized: each business unit has independent security authority. Advantages: fast local decisions; context-appropriate for business unit needs. Disadvantages: inconsistent standards; gaps between units; difficult enterprise-wide visibility. Federated (hybrid): central team sets enterprise minimums; BU teams handle local implementation within those standards. Most common in large organizations. Advantages: combines enterprise consistency with local flexibility. Disadvantages: requires clear boundary definition between central and local authority.

Security governance documents form a hierarchy: Policy (top): states what must be done and why. Approved by senior management. Sets intent and requirements. Mandatory. Example: "Passwords must be stored securely." Standard: specifies measurable technical requirements derived from policy. Mandatory. Example: "Passwords must be bcrypt-hashed with unique salt." Procedure: step-by-step instructions for implementing the standard. Mandatory. Example: "To configure bcrypt: Step 1: Import bcrypt library... Step 2: Generate 16-byte random salt..." Guideline (bottom): non-mandatory recommendations and best practices. Provides guidance but permits deviation with justification. Auditors check compliance with policy, standards, and procedures. Guidelines are voluntary. Procedures operationalize standards; standards operationalize policy.

Procedures and playbooks are documents that describe how to operate in a specific environment against specific threats. Both change over time. Triggers for playbook revision: (1) Post-incident review identifies a procedure that failed or was missing. (2) New threat types emerge requiring new response procedures. (3) Technology changes make existing steps incorrect (new tool, deprecated command, changed interface). (4) Regulatory changes require new process steps or documentation. (5) Organizational changes modify roles, systems, or contacts referenced in the playbook. Monitoring: regularly schedule playbook reviews (at least annually, or after every significant incident). Test playbooks through tabletop exercises and simulations to verify accuracy. An inaccurate playbook that is followed precisely during an incident can cause harm by directing responders to take wrong actions confidently.

Change management: the broad organizational discipline for managing all changes to IT systems, covering the entire lifecycle: how changes are requested, categorized, reviewed, approved, implemented, and documented. The overall process framework. Change control: the specific formal approval mechanism within change management that ensures changes receive appropriate review before implementation. The CCB is the change control body. Relationship: change management is the umbrella; change control (CCB approval) is one critical step within it. Change management also includes: change categorization (standard/normal/emergency), change scheduling (change windows), post-implementation review, and change database maintenance. Change control focuses specifically on the approval gate. An organization can have change management without a formal CCB (using manager approval instead), but cannot have meaningful change control without some structured review body.