• NIST Publication 800-61
– Computer Security Incident Handling
• Computer Security Incidence
– Denial of Service
– Malicious Code
– Unauthorized Access
– Inappropriate Usage

• State of Management commitment
• Purpose & objective of the policy
• Scope
– Who does it apply to
– Under what circumstances
• What is a computer incident
• Organizational structure
– Roles and responsibilities
– Who can confiscate/disconnect equipment
– Who/what can be monitored
– What kind of reporting is required

• Prioritization of incidents
• Performance measurements
• Reporting and contact info

• Dealing with the media can be tricky
– How much info to give out
– How to answer questions
– How to disseminate info
• Press release
• News conference
• Hold mock interviews to hone skills. Practice answering questions like:
– Who attacked you?
– When did it happen?
– How did they do it?
– How wide spread?
– Did this happen because you have poor security practices?
– Who is affected?
– How much $$$
– Etc…

• Who should we contact?
– FBI
– District attorney offices
– State law enforcement
– Local (County) law
– Only contact one to prevent jurisdiction conflicts
• Become familiar with law enforcement personal before an incident
• Learn how the various entities want incidents reported
• Find out what evidence needs to be collected
• Determine a primary point of contact in your organization

• You will be relying on outside parties to help you. You should contribute to help others
• CERT Coordination Center
– Run by Carnegie Mellon
– Provides an incident reporting system
• Information Sharing and Analysis Center (IT-
ISAC)
– Keeps a alert system about the number of attacks
• Forum of Incidence Response and Security
(FIRST)
– Shares information among incidence teams

• Your ISP
• Owner of the attacking address
– Caution, you might be contacting the hacker’
• Software vendors
• Affected External Parties
– How do you handle someone who calls to tell you your system is attacking them?
– How do you contact someone who’s social security number was compromised?
– Contact to these parties should happen BEFORE the media hears of it

• Central
– One team is responsible for incidences in the entire organization
• Good for smaller or geographically dense organizations
• Distributed
– Several teams, each responsible for there unit or geographic area
– Good for large orgs.
– Must have a central team to coordinate common attacks
• The need to communicate between teams is essential
• Coordinated
– A distributed team, but the central team provides guidance and advice, but does not have authority over the teams

• Employees
– All incident work is done in house
• Partial Outsourced
– Part of the incident teams work is outsourced
– Most common:
• IDS systems monitoring
– They are most likely more skilled (they look at reports all day long)
– 24/7
– If an incident is noted, the incent is handed back to the inside team
• On call contractors
– If an incident is discovered, outside contractors assist in the handling
• Fully Outsourced
– Mostly used for smaller companies with not enough employees to specialize in Incident handling.

• Management
• Information Security
– Most likely found the incident
– May be needed to alter security settings (IE firewall rules)
• Telecommunications
• IT Support
– Have the best know how about the systems
– Know the day to day running of the organization
• Legal Department
– Rules
– Legal ramifications
– Right to privacy
– Evidence collection
– Persecution
– Law suits

• Public affairs
• Human resources
• Business Continuity
– Minimize business impact of an incident
– Alter business plans and projections based on an incident
• Physical Security
– Getting access to a workstation in a locked office

• Advisory Role
– Monitor current threats and incidents
– Relay important info to the rest of the organization
• Vulnerability assessment
– Scan, probe, penetrate
• Intrusion Detection
• Education and Awareness
– Good passwords
– Educate employee to notify them of unusual activity
– Train technical staff about vulnerabilities and how to protect against them

• Tools and Resources needed:
– Communications
• Outside contact list
• On-call list
• Incident report mechanisms – forms, emails, anonymous reporting
• Pagers/Cell phones of team members
• Encryption software – Used to communicate between team members (pgp)
• War Room
• Secure storage

• Tools and Resources needed:
– Hardware and Software
• Forensic workstations
• Backup devices
• Spare workstations and network equipment
– Used to try out malicious code
– Restore backups
• Blank media (cd-r, dvd-r, usb memory sticks)
• Portable printer
• Packet sniffers / Protocol analyzers
• Forensic software
• CDs, usb, and floppies with trusted applications
• Evidence gathering accessories
– Notebooks
– Cameras
– Audio recorders
– Chain of custody forms
– Evidence tags

• Tools and Resources needed:
– Analysis Resources
• Port lists
– What ports should be open on what machines
• Documentation
• Network diagrams
– What servers, switches, routers, firewalls, etc
– What server does email, web, dns, etc and where are they located
• Baselines
– What is normal activity
• Hashes
– A collection of hashes of critical applications
– Eases detection of infected systems

Incident Life Cycle – Detection and
Analysis
• Detection
– Software Alerts
• IDS
• Antivirus
• File Integrity
• 3 rd party monitoring – probe various services to make sure they are up
– Logs
• OS
• Application
• Network device
– Publicly available info
• Info on new vulnerabilities
• Info of incidents at related organizations
– People
• Internal users
• Outside users

Incident Life Cycle – Detection and
Analysis
• Analysis
– Understand Normal behavior
– Centralized logging
• Have devices and software send their logs to a central location or server
– Log Retention policy
• How long do we keep logs? Archive them?
– Event correlation
• Events can be caught on several logs
• Extract log entries across multiple logs can provide valuable info about the event
– Clock synchronization
• Logs are almost impossible to correlate if there are different times stamps
– Use ntp

Incident Life Cycle – Detection and
Analysis
• Analysis
– Maintain a knowledge base of info
• Links to malicious code and hoax info – antivirus vendors
• Links to lists of black listed spam sites
• Links and manuals explaining the various codes associated with error messages
– Use google, yahoo, etc…
– Run packet sniffers
– Filter data if the quantity of events is to large
– Experience
– Diagnostic matrix for the less experienced

Incident Life Cycle – Detection and
Analysis
• Documentation
– As soon as a event is suspected, start a log.
• Document events as they are found
• Phone conversations
• File changes
– Time stamp and sign every entry
– Can be used in a court of law
– Work in teams of 2.
• One performs the work
• One logs the work
– Put the log into a database or some where other team members can get to
• You can’t work 24/7
• Vacations, sick time, even death
• Need to be able to allow other to start where you left off

Incident Life Cycle – Detection and
Analysis
• Prioritization
– If many events happen in quick succession you need to prioritize them
• Current and Potential effect
– An root compromise on one system, can they get to others
– A worm on a few computers may spread to the entire org
• Criticality of the affected system
– Is it a business critical web server, email, fileserver…
– Service level agreements
• Maximum time to restore key resources
• Maximum time to react to events

Current Impact or
Likely future impact
Root access
Criticality of Resource
High (Internet connectivity, Public web server, firewall, customer data)
15 min
Unauthorized data modification
Unauthorized userlevel access
15 min
30 min
Un authorized access to sensitive data
15 min
Service unavailable 30 min
Annoyance 30 min
Medium (Sys Admin workstation, file and print servers, application data)
30 min
30 min
2 hour
1 hour
2 hours
Local IT staff
Low (user workstations)
1 hour
2 hour
4 hours
1 hour
4 hours
Local IT stall

Incident Life Cycle – Detection and
Analysis
• Notification
– CIO
– Head of information security
– Other incident teams
– System owner
– Human resources (if it involves employees)
– Public affairs (if it might generate publicity)
– Legal dept

Incident Life Cycle – Containment,
Eradication and Recovery
• Containment Strategy
– Method
• Shut down
• Disconnect from the network (wired or wireless)
• Segment the network
• Disable functions
• Block hosts or ports at the perimeter
• Rebuild or clean

Incident Life Cycle – Containment,
Eradication and Recovery
• Containment Strategy
– Considerations
• Potential damage to and theft of resources
• Need for evidence preservation
• Service availability
• Time needed to implement the strategy
• Effectiveness of the strategy
• Duration of the solution
– Emergency work around (several hours)
– Temporary work around (several weeks)

Incident Life Cycle – Containment,
Eradication and Recovery
• Evidence Gathering and Handling
– Primary reason is to resolve the incidence
– May also be needed for legal reasons
– Needs to be handled according to procedures that meet applicable laws and regulations
• Log of the evidence including:
– Identifying info (location, serial number, model number, hostname, MAC address, IP address, etc…)
– Name, title, phone or each person who collected data
– Time and date of each collection
– Location of where the evidence is stored – must be a secured location
• Evidence must be accounted for at all times
• Chain of custody

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Network Traffic
• sniffers

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Memory
• Plug in media with trusted software (usb, cd, network share)
• Execute shell from trusted media (cmd.exe, bash, etc)
• Dump memory to a file (not on the suspected equipment!)
– Unix: cat /dev/memory > file
– Windows: mdd –o file
» Mantech Physical Memory Dump
» http://sourceforge.net/projects/mdd/
• Windows Forensic Toolkit
– www.accessdata.com
• Eject media, hash the extracted file, copy the file to write once media (cd), hash copy and compare.
• Copy again, hash compare.
• Enter first copy into evidence (recording hash on the evidence tag)

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Hard Drive
• Consider
– Volume of storage
– Drive configuration
– Is the machine mission critical
• Do a graceful shutdown
• Remove hard drive, connect to a work station with a write blocker
• Hash original
• Duplicate
– Hardware duplication is best
» www.ics-iq.com
– Software
» Linux: dd
» Encase: www.guidancesoftware.com
» Windows: Forensic Toolkit

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Hard Drive
• Duplicate
– Or reboot the compromised system with helix linux ( www.efense.com/products.php
). Good when the system uses software RAID or LVM
• Rehash the original to verify nothing was changed
• Hash duplicate and compare to verify that the copy is the same
• Enter the original and hash into evidence

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Data Analysis
• Verify Hash
• Undelete or recover files
• Index identifiable words into a database and search
– Strings
• Hash individual files
– NIST has a database of hashes of compromised files
– www.nsrl.nist.gov
• File signature analysis
– Is the file what the extension say it is?
• Key word search
– Pwdump –outputs hashes of windows passwords
– Sysinternals
– Dameware: www.dameware.com

Incident Life Cycle – Containment,
Eradication and Recovery
• Volatile Evidence (in order of volatility)
– Data Analysis
• AV Scan
– Multiple AV software brands
– www.virustotal.com/
• Method
– Find a bad file
– Search for other files with the same date and time
– Look in the same directory
– Check event logs for that date/time
– Search registry for file name
– Repeat with any new files found

• Lessons learned
• Policy updates
• Pursue legal action