NIST 800-61r2 Incident Handling Principles

Synopsis deconstruction of the NIST 800-61 r2 document on Incident Handling.

The full report available here.

• Be ready to contact outside people, predetermine guidelines for appropriate information
• Focus on handling incidents that use common attack vectors
  • Attack vectors are
    • External/removable media – USB etc
    • Attrition – dos attacks
    • Web – attack from website or application
    • Email – attachments & links
    • Improper usage – breach of acceptable use policy
    • Loss of theft of kit – laptop, smartphone
    • Other – an attack that does fit in the above categories
• Automate for initial analysis to get interesting data
• Adequate logging in place
• Written guidelines to prioritize incidents, based on functionality impact, information impact as it relates the CIA (Confidentiality, Integrity and Availability) recover-ability from the incident
• Use Lessons Learned to improve going forward
• CSIRC – Computer Incident Response Capability
• Event – any observable occurrence in a system or network, web site connection, sending an email etc
• Adverse events – event with bad outcome – system crash, packet flood
• Computer security incident – violation or imminent threat of violation of computer security policies
• Contact Police through one consistent person
• Communications with outside parties
  • Customers, constituents and media
  • Other Incident Response teams
  • Software and Support Vendors
  • ISPs (Internet Service Providers)
  • Law Enforcement
  • Incident Reporters
• When PII (Personally Identifiable Information) is involved, incident response should be different, different breach notification
• Team could be Employees, partially or fully outsourced
  • Team model section factors
  • Need for 24/7 availability
  • Full time vs part time
  • Employee moral
  • Cost
  • Expertise
• If outsourcing consider
  • Current and future quality of work
  • Division of responsibility’s
  • Sensitive information revealed to contractor, use NDAs
  • Lack of organisation specific knowledge
  • Lack or Correlation – Admin access to host machines required
  • Handling incidents and multiple locations
  • Maintain IR skills in house – just cos you outsourced doesn’t mean you should stop learning about IR
• Single employee poss with designated alternatives should be in-charge or IR
• What other groups need to be involved in IR? Management, IT Support, legal, HR, PR, Facilities management?
• Recommendations for building a IR Handling capability
  • Establish a formal incident response capability
  • Create an incident response policy – whats considered an incident? organisation structure, define roles and responsibilities, requirements for reporting incidents
  • Develop and incident response plan based in the incident response policy – Short and long term goals, metrics to measure program, training requirements, requirements for incident handlers
  • Develop incident response procedures – based on the plan and policy. Detailed steps for responding to an incident
  • Establish policies and procedures regarding incident related information sharing – dealing with media, police etc
  • Provide pertinent information on incidents to the appropriate organisations – FSA, EU etc
  • Consider the relevant factors when selecting an incident response team model – advantages and disadvantages of each possible team and staffing model
  • Select people with appropriate skills for the IR Team – not only tech skills, but team work and communication skills
  • Identify other groups within the organisation that may need to participate – management, legal etc
  • Determine which services the team should offer – which additional stuff do they do? Intrusion detection? educating users?
• Incident response life-cycle
  • Preparation
    • Prevent incidents by making sure everything secure. Prep mobiles, x2 computers, software, manuals that might be needed aka Jump Kit. Risk assessments, Host and network security, malware prevention, user training
  • Detection and Analysis
    • Attack vectors, USB, web, email etc.
    • Signs of incident fall into two categories
      • i) Precursors and ii) Indicators.
        • Precursor – might happen in the future.
        • Indicator – happening now or already happened.
        • Precursor evidence, web logs, threat, new exploit. Indicator evidence, Alert, AV software going mad, system admin see files with unusual chars, multiple failed login attempts. Make incident analysis easier – Profile Networks and systems, understand normal behavior, create a log retention policy, perform even correlation, keep host clocks synced, maintain and use a knowledge base of info, Use Internet for research, Run packet sniffers, Filter the data, Seek assistance from others. Document the incident
        • Functional impact categories – none, low, medium, high
        • Information impact categories – none, privacy breach, proprietary breach, integrity loss
        • Recover-ability Effort categories – regular, supplements, extended, not recoverable
    • Containment, Eradication and Recovery
      • Create containment strategy for each major event type.
      • Delayed containment to observe is dangerous as attacker might do worse stuff
      • Don’t think that disconnecting from the network stops compromised host getting more damage
      • Evidence needs to be collect in accordance with laws to make it admissible
      • Better to get host snap shot as is before messing around with it
      • Stay focused on Incident Handling don’t waste time trying to detect who is doing it
      • Recovery – patches, reinstall OS, restore from backups.
      • Remediation steps should be prioritized.
    • Post incident Activity
      • Lessons learned meeting
      • Collect data on incident to make a reference for moving forward.
      • Evidence retention