4) Best Practices & Disaster Prevention Flashcards
Network Topology Diagrams
Describes the network layout
May be a logical diagram
Can include physical rack locations
Knowledge Base/Articles
Helps to find a solution quickly
External sources
Manufacturer knowledge base
Internet communities
Internal documentation
Institutional knowledge
Usually part of help desk software
Incident Documentation
Security Policy
Documentation must be available (no questions)
Documentation always changes (wiki model is best)
Regulatory & Compliance Policy
Meeting the standards of laws, policies, & regulations
A healthy catalog of rules
Many are industry-specific or situational
Penalties: Fines, loss of employment, incarceration
Scope: Domestic or international requirements
Ex: HIPAA (Health Insurance Portability & Accountability Act)
Healthcare standards of storage, use, transmission of info
GLBA (Gram-Leach-Bliley Act of 1999)
Disclosure of privacy information from financial institutions
Acceptable Use Policy (AUP)
What is acceptable use of company assets?
Detailed docs, may be in the Rules of Behavior
Covers many topics: Internet use, telephones, computers, mobile devices, etc
Used by an organization to limit legal liability.
Password Policy
Passwords should be complex
Expire every 30/60/90 days
Critical systems may be more frequent.
Recovery process should not be trivial.
Lockout after failed attempts
Disable accounts, don’t delete until files claimed
Inventory Management (Asset Tags/Barcodes)
Keeping a record of every asset
(Routers, switches, cables, fiber modules, CSU/DSUs)
Financial records, audits, depreciation
Make/model, config, purchase data, location, etc
Tag the asset (barcode, RFID, tracking number)
Scope the Change
Determine the effect of the change
(An entire site, or single device)
A single change can be far reaching
(Multiple applications, internet, remote site access, etc)
How long will this take?
(No impact? Hours of downtime?)
Risk Analysis
Determine a risk value
(Low, medium, high)
Risk can be far reaching
(Fix could break something else, OS failures, data corruption, etc)
Risk in NOT making change?
(Vulnerability, app unavailability, unexpected downtime)
Plan for Change
Document every detail and step for the change.
(Technical, for technical people)
Others can help identify unforeseen risk.
Scheduling (time of day/week, completion time frame)
End-User Acceptance
Nothing happens without a sign-off
The end users of the application/network
Users must be aware of the change and potential impact. (For sake of performing job properly)
Ideally a formality (constant communication)
Change Board & Approvals
Examines all of the changes proposed (to give Yes/No)
Identify importance of changes (prioritize)
Conflicts between changes? (Stretch changes out?)
Backout Plan
There are always scenarios where things do not go as planned.
Must have a way to revert changes
(Prepare for worst, hope for best)
Some changes can be very difficult to revert.
Always have backups (perhaps first step for plan)
Document Changes
Everyone needs to know what has changed (even in the future)
Help desk documentation (version numbers, network diagram, new server names)
Track changes over time, track before & after stats
Backup & Recovery: Image Level
Bare metal backup using images
OS volume or hypervisor snapshots
Recover the entire system at once
Make an exact copy somewhere else
