One of the sessions that I attended during the day on the Tuesday of TRISC 2009 was by Doug Landoll from Lantego on “Security Policy Architecture”.  The presentation was a very good overview of how to put good security policies in place that are easily auditable should that need arise and that are as comprehensive as necessary.  The actual presentation slides are available here and because he had some very good visual aids in his presentation, I’m going to just recommend that you check out the actual slides.  My notes, however, are below just in case the slides ever get deleted for some reason:

Importance of Security Policies

  • Govern expected behavior and process
    • Expected and prohibited behavior
    • Security process
  • Establishes roles and responsibilities
    • Management & oversight
    • Execution
  • Define protection measures
    • Access controls
    • Physical security measures
    • Monitoring, audit, and oversight
    • Response priorities

Hazards of Weak Security Policies

  • Unclear expected behavior
    • Personnel guess at what is allowable & expected
    • Minor “infractions” – undefined & unnoticed
    • Leads to eroding culture of trust
  • Unclear roles and responsibilities
    • No oversight – administrator actions go unchecked
    • No management – activities according to whim
  • Unclear protection measures
    • “Heroes” define network security
    • Extremely tech-centric security posture

Security Architecture Mistakes

  • Mixed audience policies
    • Ex: Encryption policy
      • Use of encryption – users
      • Selection of encryption algorithms – system owners
      • Implementation of encryption – custodians
      • Key escrow – system owners
      • Oversight – auditors/management
    • Ex: Security Updates
      • Do not block network updates – users
      • Patch every Tuesday – admins
  • Who is the audience?

Common Policy Architecture Mistakes

  • One topic = one policy
  • Magic Policies
    • Templates
    • Handbooks
  • Pros
    • Solves the “blank piece of paper” problem
  • Cons
    • Old
    • No consideration for your environment, culture, or organization
    • Discourages analysis
    • No SME (Subject Matter Expert) involvement
    • Thwarts adoption
  • Match policy to requirements
    • PCI Policy project
    • HIPAA Policy project
    • TAC 202 Policy project
    • Etc
  • Problem
    • Requirements by controls
    • Policies organized by audience & topic

Clean Slate Approach

  1. Assess what you have
    • Independent & complete review process
  2. Determine controls framework
    • COBIT, ISO 27001
  3. Map in requirements
    • PCI DSS, HIPAA, TAC 202
  4. Organize create policy statements
    • For each control (rows) and requirement (column)
  5. Create policy architecture
    • According to audience & topic

Policy Assessment Approach

  • Step 1 (Essential Elements Checklist)
  • Steps 2 (controls & framework) & 3 (map requirements)
  • Steps 4 (policy statements) & 5 (policy architecture)

Conclusion

  • Administrative Controls
    • Management, oversight, process
    • Address organizational and insider issues
  • Lack of policy architecture
    • Leads to weak administrative controls
    • Unplanned technology implementation
      • “implementation by appointment”
  • Ensure your controls are complete
  • Reaction is NOT a strategy (Don’t do it because a vendor called you or because an auditor said to do it)