Incident Handling and Computer Forensics

Incident Handling and Computer Forensics

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

Incident Policy & Procedures • 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

Incident Policy & Procedures • Prioritization of incidents • Performance measurements • Reporting and contact info

Sharing with Outside Parties

Media • 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…

Law Enforcement • 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

Incident Reporting Organizations • 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 (ITISAC) – Keeps a alert system about the number of attacks • Forum of Incidence Response and Security (FIRST) – Shares information among incidence teams

Other Outside Entities • 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 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

Incident Team Structure • 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

Incident Team Staffing Models • 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.

Inside Contacts • 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

Inside Contacts • 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

Incident Team Services • 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

Incident Life Cycle

Incident Life Cycle - Preparation • 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

Incident Life Cycle - Preparation • 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

Incident Life Cycle - Preparation • 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 Criticality of Resource Likely future impact High (Internet Medium (Sys Admin Low (user connectivity, Public workstation, file workstations) web server, firewall, and print servers, customer data) application data) Root access 15 min 30 min 1 hour Unauthorized data modification 15 min 30 min 2 hour Unauthorized userlevel access 30 min 2 hour 4 hours Un authorized access to sensitive data 15 min 1 hour Service unavailable 30 min 2 hours 4 hours Annoyance 30 min Local IT staff 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

Incident Life Cycle – Post Incident Activities • Lessons learned • Policy updates • Pursue legal action