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
- Attack vectors are
- 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
- i) Precursors and ii) Indicators.
- 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
- Preparation
Summary
Article Name
NIST 800-61 r2 Incident Handling
Description
Synopsis deconstruction of the NIST 800-61 r2 document on Incident Handling.
Author
Mark WH
Publisher Name
OIC Solutions