Chapter 105 · Flashcards

Security Policies — Flashcards

Eleven cards covering policy vs. technical controls, AUP and legal liability, BCP and testing requirement, DRP recovery sites, RTO and RPO, five IR roles, NIST SP 800-61 phases, Agile vs. Waterfall SDLC, change management elements, the CIA triad as policy foundation, and BIA. Click any card to flip it.

What is the difference between a security policy and a technical control?

Policy: a document that states what must be done and why. It establishes the requirement, defines scope, assigns responsibility, and sets consequences for non-compliance. Policies are approved by management and form the legal and organizational basis for security requirements. Technical control: a technology or configuration that implements how the policy requirement is met. Firewall rules implement network access policy. Password complexity settings implement password policy. Key relationship: Policies must exist before technical controls can be justified or audited. Technical controls without policy authority are difficult to enforce. Policy without technical controls are unenforceable requirements.

What does an Acceptable Use Policy contain, and why does it limit organizational legal liability?

AUP content: (1) Permitted uses of organizational systems. (2) Prohibited uses (illegal activities, unauthorized data sharing, excessive personal use). (3) Monitoring disclosure (users have no expectation of privacy on organizational systems). (4) Consequences for violations (discipline, termination, legal action). Legal liability limitation: By requiring employees to acknowledge (sign) the AUP, the organization creates documented notice that the employee understood prohibited activities. If an employee misuses systems, the AUP acknowledgment demonstrates the organization had clear policy, reducing organizational liability for enabling the conduct. Without an acknowledged AUP, the organization cannot demonstrate the employee was informed the activity was prohibited.

What is business continuity planning, and what is the testing requirement?

BCP: a comprehensive plan for maintaining critical business functions when normal operations are disrupted. Broader than IT: covers manual procedures for business processes when technology fails. Key elements: manual alternative procedures (how to process orders, pay employees without systems), dependencies (what processes depend on which systems), and recovery priorities. Testing requirement: A BCP that has never been tested is not a viable plan. Testing reveals: outdated procedures, missing supplies, staff who do not know their roles, and wrong assumptions. Must be tested through tabletop exercises (discussion), simulations (executing manual procedures), and full-scale tests. An unverified BCP is false confidence — it may fail exactly when needed most.

What are the three disaster recovery site types, and what are their cost vs. recovery time trade-offs?

Cold site: physical space with power and network connectivity but no equipment. Lowest cost. Highest RTO (weeks to set up). Organization must procure, install, and configure everything. Suitable only when extended downtime is acceptable. Warm site: pre-configured hardware and software, but data must be restored from backups. Moderate cost. Moderate RTO (days). Most common for mid-tier applications. Hot site: fully operational replica with real-time or near-real-time data mirroring. Highest cost. Lowest RTO (hours or minutes). Can resume operations almost immediately. Required for critical systems with very short RTO. Trade-off: higher cost directly reduces RTO and RPO.

What are RTO and RPO, and how do they drive DR planning decisions?

RTO (Recovery Time Objective): the maximum time the organization can tolerate being without a system before unacceptable business harm results. If the financial system RTO is 4 hours, DR procedures must restore it within 4 hours. RPO (Recovery Point Objective): the maximum acceptable data loss measured in time. If the customer database RPO is 1 hour, backups must occur at least every hour. How they drive decisions: A 4-hour RTO requires a warm or hot site, not a cold site (which takes weeks). A 15-minute RPO requires near-real-time replication, not daily backups. Shorter RTO/RPO = higher DR cost. The BIA identifies RTO/RPO requirements; the DRP must meet them.

What are the five incident response roles and their primary responsibilities?

(1) IR Team: technical responders who detect, contain, analyze, eradicate, and collect evidence. (2) IT Security Management: coordinates response, escalates to senior management, approves decisions affecting business operations. (3) Compliance Officers: ensures regulatory requirements are met, manages mandatory breach notifications (GDPR 72-hour notice, HIPAA), documents compliance decisions. (4) Technical Staff (non-IR): provides system access, SME knowledge, and operational support for specific systems under investigation. (5) User Community: reports suspicious activity, follows security instructions, cooperates with responder requests. Often first to notice an incident. All five roles must be defined in policy before an incident occurs.

What is the difference between NIST SP 800-61 and the NIST CSF?

NIST SP 800-61 (Computer Security Incident Handling Guide): specific framework for incident response. Four phases: (1) Preparation, (2) Detection and Analysis, (3) Containment, Eradication, and Recovery, (4) Post-Incident Activity. This is the incident response lifecycle tested on Security+. NIST CSF (Cybersecurity Framework): a broader framework for overall cybersecurity program management. Five functions: Identify, Protect, Detect, Respond, Recover. Provides a risk management framework for the entire security program, not just incident response. Exam trap: Questions asking about "incident response phases" want the SP 800-61 four-phase model. Questions about "NIST framework functions" or "cybersecurity program framework" want the CSF five functions. Do not confuse them.

What are the key differences between Agile and Waterfall SDLC methodologies from a security perspective?

Agile: iterative short sprints (2 weeks); working software delivered frequently; requirements evolve; cross-functional teams. Security challenge: frequent releases require continuous security testing (SAST/DAST automated in CI/CD pipeline). Security is integrated into each sprint via DevSecOps. Risk: fast pace may pressure teams to skip security reviews. Waterfall: linear sequential phases (Requirements → Design → Implementation → Testing → Deployment). Security must be captured in Requirements phase; retrofitting security into later phases is expensive. Formal security gate review before each phase transition. Risk: long development cycles mean security issues discovered late are expensive to fix. Both require: security requirements in project requirements, security testing before production deployment, security sign-off before release.

What five elements must a change management policy include?

(1) Frequency: how often changes are permitted (e.g., weekly change windows); restricting frequency ensures adequate review time. (2) Duration: time windows for implementing changes; changes outside windows require emergency process. (3) Fallback procedures: documented rollback plan for every change; if the change fails, how is the previous state restored? Required for every change, not just risky ones. (4) Risk analysis: security and operational impact must be assessed before approval. (5) Approval authority: who approves based on risk level (routine = IT manager; high-risk = CCB or CISO). Plus: documentation requirement for all approved changes and outcomes. Undocumented changes are a common root cause of security incidents.

How does the CIA triad serve as the foundation for all security policies?

Every security policy can be traced to protecting one or more CIA triad properties: Confidentiality: information is accessible only to authorized parties. Policies: AUP (restricts sharing), access control policy, encryption policy, data classification. Integrity: information is accurate and has not been unauthorized modified. Policies: change management (prevents unauthorized changes), SDLC (prevents insecure code), audit logging policy. Availability: systems and information are accessible when needed. Policies: BCP (maintains operations during disruption), DRP (restores systems), capacity planning policy. CIA triad provides the justification for any policy requirement: if you cannot trace a control to protecting C, I, or A, question whether it is needed. Policies without CIA justification are difficult to defend in audits.

What is a Business Impact Analysis (BIA), and what three things must it identify?

BIA (Business Impact Analysis): the analysis that forms the foundation for both BCP and DRP by identifying what must be protected, in what priority order, and with what recovery requirements. Three required outputs: (1) Critical business functions: which functions are most important to the organization and what the consequences of interruption are (financial loss, regulatory penalty, customer impact, reputational damage). (2) Tolerable downtime: how long each function can be suspended before unacceptable harm — this becomes the RTO for that function. Also: maximum acceptable data loss (RPO). (3) Dependencies: what systems, applications, and personnel each critical function depends on. BIA drives recovery site selection, backup strategy, and recovery prioritization in the DRP.