1.3.2 Technical Implications

Technical implications = effects a technical change has on security, availability, and performance. Even small changes can break compatibility or open new vulnerabilities.

Allow vs Deny lists

• Allow List (Whitelist) → only listed items run → "default deny"
• ✅ More secure — only pre-approved software/IPs/users
• Deny List (Blacklist) → only listed items blocked
• ❌ Less secure — unknown malware can still run
• *Exam rule:* Allow List > Deny List for security

Restricted activities

Limits to reduce attack surface: - No software installs - No USB drives - No PowerShell scripts - Block certain websites / unauthorized apps

Downtime & restarts

• Downtime → system/service unavailable (planned or unexpected)
• Minimize via redundancy, clustering, maintenance windows
• Service Restart → restart a specific service only (web, DB)
• Application Restart → restart only the patched app (CRM, ERP)

Legacy applications

• Old apps still in use, unsupported or unpatched
• Risks → outdated protocols, weak crypto, EoL OS
• Mitigate with segmentation, VM isolation, compensating controls

Dependencies

• Apps rely on DBs, APIs, auth services, libraries
• Updating one component can break another → run impact analysis first

Documentation that must be updated

• Diagrams → network, architecture, topology → must reflect reality
• Policies & Procedures → reflect new controls (MFA, password rules, backups)

Version Control

• Keeps full history of configs / code / docs
• Tracks who, when, what changed → audit trail
• Enables rollback when a change breaks things

Exam takeaway

Every change → evaluate impact, document, update diagrams + policies, manage via version control.