Incident Response

1
Incident Response and Forensics
Brian H. Karney CISSP GSI Sr. Security
Engineering Brian.karney_at_encase.com July 10, 2003
2
Agenda

• Overview
• Planning, Policies, Procedures
• Technology
• Resources
• Questions
• Demo

3
Incident Response Systems
The Statistics

• 65 of attacks succeed
• Source DISA
• CSI/FBI 2003 Computer Crime and Security Survey
  Source Computer Security Institute
• Largest dollar loss reported
• 70,195,900 Theft of IP
• Likely Source of Attacks
• 2002
• Hacker 82
• Disgruntled Employee 75
• 2003
• Hacker 82
• Disgruntled Employee 77
• 93 of all information produced is digital
• Source UC Berkeley Study

4
Definition of an Incident

• "A computer security incident, ..., is any
  adverse event whereby some aspect of computer
  security could be threatened loss of data
  confidentiality, disruption of data or system
  integrity, or disruption or denial of
  availability." Wack 1991

5
Categories of Incidents

• Compromise of integrity
• Such as when a virus infects a program or the
  discovery of a serious system vulnerability.
• Denial of service
• Such as when an attacker has disabled a system or
  a network worm has saturated network bandwidth.
• Misuse
• Such as when an intruder (or insider) makes
  unauthorized use of an account or information.
• Damage
• Such as when a virus destroys data.
• Intrusions
• Such as when an intruder penetrates system
  security.
• Schultz Jr. et al. 1990

6
Incident Response Challenges
The Threats

• Internal
• Hacking tools
• Unauthorized applications
• Unauthorized communications
• Counterfeiting/ fraud
• Rogue servers
• Wrongful Termination

• Mishandling and theft of IP
• Theft of client information
• Sexual harassment
• Possession of Inappropriate Images
• Computer file deletion/destruction

• External
• Unauthorized users/ intruders
• Vandalism
• DoS attacks
• IP piracy

7
Incident Response
The Liabilities

• Liability To Customers/ Compromise of
  Information
• Liability to Regulators
• Mandated Incident Response Process
• Internal Controls Due Diligence
• Liability to Shareholders
• Loss of IP, Internal Fraud
• Uncontained Security Incident
• Downstream Liability
• Destruction of Evidence

8
Incident Response Systems
Mandated Incident Response Plans

• FTC Safeguards Rule
• Requires covered entities to maintain information
  security program that includes Detecting,
  Preventing and Responding to Attacks, Intrusions,
  or Other Systems Failures. (16 CFR Part
  314.4(b)(3))

• Office of Comptroller of the Currency (OCC)
• Requires subject banking institutions to
  implement
• Response programs that specify actions to be
  taken when the bank suspects or detects that
  unauthorized individuals have gained access to
  customer information systems, including
  appropriate reports to regulatory and law
  enforcement agencies. (12 CFR Part 30, Appendix
  B, III(C)(g)).

• Health Insurance Security Standards (HIPAA
  Requirements)
• Requires subject health care institutions to
• Identify and respond to suspected or known
  security incidents mitigate, to the extent
  practicable, harmful effects of security
  incidents that are known to the covered entity
  and document security incidents and their
  outcomes. (45 CFR Part 164.308(a)(6))

9
Incident Response Systems
The Legislation

• California, SB 1386/ Civil Code 1798.82
• Mandates full disclosure to California Residents
  of any compromised customer data
• Law is Triggered Upon an Computer Security
  Incident
• Identifying and Documenting What Happened
  Determines Compliance
• Delayed Disclosure Allowed For Referral to Law
  Enforcement or Reasonable Internal Investigation

• Sarbanes-Oxley Act of 2002
• -Severe liability for destruction of
  electronic records -- up to 25 million fines, 20
  year prison terms -Important Due Diligence
  Mechanism For Internal Controls

• NASD Rule of Conduct 3110
• Brokers/Dealers must retain all
  emails/communications with customers

• ISO 17799
• Outlines Comprehensive Incident Response and
  Internal Investigation Procedures
• Detailed Provisions on Computer Evidence
  Preservation and Handling

10
Real World IR Examples

• Computer Intrusion
• System compromised (configuration, vulnerability)
• Web Defacement
• Virus or worm outbreak
• Identification of unauthorized applications
• Encryption and stegonagraphy tools
• Hacker discovery tools
• Denial-of-service attack
• Theft of intellectual property
• Unauthorized use of systems by employees or
  external entities
• Gambling or Pornography sites
• Launching ground for attacks
• Internal External policy compliance
• Pending government legislation (GLBA, HIPPA, CA
  SB 1386, S-O)
• Corporate usage policy enforcement and
  containment
• Employees spreading rumors- bad mouthing company
  (??)

11
Problems with Incident Response Today

• Systems are taken off-line impacting services
• If remote, IR team travels to location
• IR investigations which span different time zones
• hard to construct accurate timeline
• prone to human error
• Use of disjointed tools
• time consuming
• large margin of error
• Various system and media types
• NTFS, Ext 2/3, Reiser, FAT, HFS
• Compound File types
• Extremely Large Hard Disks
• External Media
• Encrypted File Systems

12
Problems with Incident Response today (cont)

• Volatile Information lost if system shutdown
• Foreign language support
• Hard to determine scope of compromise
• Restoration of systems and services
• Resource intensive (people and technology)
• Chain of custody and evidence handling
• Containment of potential compromise
• Controlling release of information about
  compromise

13
Typical/Traditional Incident Response Process

• Picture or process

14
Incident Response Planning
15
Goals of Incident Response

• Confirm whether an incident occurred
• Provide accurate, relevant, and timely
  information
• Implement controls to Maintain Chain of Custody
• Protect individual rights established by policy
  and law
• Minimize downtime to business and network
  services
• Enable legal and law enforcement to prosecute
  malicious entities
• Provide recommendations to Sr. Management
• Understand correct priorities

16
Incident Response is Mission Critical

• IR planning is about risk reduction and
  mitigation, and needs to be seen as such by top
  management
• It is not just a plan for technical staff to
  chase hackers and viruses, even though much of
  the work involved will have to be
  technology-oriented

17
Types of Contingency Plans
http//csrc.nist.gov/publications/drafts/ITconting
ency-planning-guideline.pdf
18
Incident Response Planning

• Develop Framework
• Mission Statement
• Objective
• Analyze business operations
• Escalation categories and plans
• Develop Team
• Scope of operations
• Structure and core members
• Roles and responsibilities
• Communications Plan
• Notify who when?
• 911 email account
• Policies and Procedures
• Daily operations
• Incident response
• Incident recovery

19
Incident Response Organization Services
Special permission to reproduce Incident
Handling Lifecycle diagram and CSIRT Service
Diagram, (c) 2003 by Carnegie Mellon
University, is granted by the Software
Engineering Institute.
20
IR Organization

• Technical Specialists An understanding of the
  production aspects of the technology relevant to
  the Investigation
• Information Security Specialists Data and
  systems protection
• Auditors and Fraud Examiners Compliance and
  fraud
• Corporate Security Investigations and Physical
  security
• Human Resources Personnel and labor issues
• Business Continuity Specialists System and data
  recovery
• Legal Specialists Protecting the organizations
  intellectual property
• Corporate Public Relations Press and media
  interaction
• Executive Management Key decision-makers

21
Effective IR Plan includes

• Periodic Review of Documentation
• Update as new personnel, technology, and
  business processes are added.
• Training
• Organization, Information security skills,
  crisis, forensic investigation skills,
  communication.
• Funding
• Budget, additional equipment, staff salaries,
  training.
• Exercise
• Validate and refine process and procedures
  regularly

22
Incident Categories
23
Roles of IR Team

• Determine if an event is an incident
• Determine incident cause and advise management on
  the action required
• If required, activate the support team
• Manage the investigation and report process
• Call external agencies as necessary

24
Incident Response Lifecycle
Special permission to reproduce Incident
Handling Lifecycle diagram and CSIRT Service
Diagram, (c) 2003 by Carnegie Mellon
University, is granted by the Software
Engineering Institute.
25
Incident Related contacts

• These are the contacts that a CSIRT will need
  when handling a specific incident. upper
  management (managers, department/division/bureau
  heads)
• sponsors
• other departments
• technical (system and network) administrators
• security officer
• legal counsel or legal compliance department
• internal audit department
• risk management group
• network operation center
• network information center

26
Non Incident Related Contacts Planning

• These are contacts used to provide background
  information for (or about) the team,
• obtaining input from domain experts.
  (constituency) site security contacts
• other constituency site contacts (like
  management, physical security, human resources)
• sites external to constituency
• Internet service providers
• other CSIRTs
• law enforcement, legal counsel
• vendors
• experts
• media

27
Incident Response Organization Services

• Proactive services
• Designed to improve the infrastructure and
  security processes of the constituency before any
  incident or event occurs or is detected. The main
  goals are to avoid incidents and to reduce their
  impact and scope when they do occur.
• Announcements
• Technology Watch
• Security Audits or Assessments
• Configuration and Maintenance of Security Tools,
  Applications,
• Infrastructures, and Services
• Development of Security Tools
• Intrusion Detection Services
• Security-Related Information Dissemination

28
Incident Response Organization Services

• Reactive services
• These services are triggered by an event or
  request, such as a report of a compromised host,
  wide-spreading malicious code, software
  vulnerability, or something that was identified
  by an intrusion detection or logging system.
• Alerts and Warnings
• Incident Handling
• Incident analysis.
• Forensic evidence collection
• Tracking or tracing
• Incident response15 on site.
• Incident response support.
• Incident response coordination.
• Vulnerability Handling
• Artifact Handling

29
Incident Response Technology
30
Enterprise Security Timeline
Incident Responseand Forensics
31
Incident Response System
Incident Responseand Forensics

• Business continues un-interrupted
• Evidence preserved quickly
• Reach well-informed decisions sooner
• Reach geographically dispersed systems
• Investigate on a need-to-know basis
• Follow a repeatable forensic methodology

32
Incident Response System Requirements

• Bypass Windows security layers to access the
  physical drive.
• Perform forensic level discovery of live system
  without modifying target.
• Ability to locate, preview, and acquire all data
  on the drive, regardless of whether it is
  deleted, fragmented, damaged, or encrypted.
• To identify data by file type content with
  powerful key word and hash set searches.
• To Simultaneous acquire multiple running systems.
• To auto-decode files
• To search and view Unicode (Multi-Language) data

33
Incident Response System
34
Where do I begin to look? (system)

• File System Artifacts
• File Permissions
• Time stamps
• Deleted files
• Hidden Log files
• Operating System Logs (event logs)
• Application Logs (ERP, web, ftp,
  peer-to-peer,mail, database, etc)
• Back Door Accounts (new administrator accts,
  escalated privileges)
• Deviations from Trusted Baseline
• MD5 Hashes
• File Signature analysis
• Keywords in (Slack space, Logical file space,
  compound docs, Unicode)
• Volatile data
• Dynamic Registry
• RAM
• Network session
• Running processes

35
Where else do I look? Network Evidence?

• Upstream ISPs, Business Suppliers
• Router logs and configurations
• Switches (logs and configs)
• Firewalls (logs and configs)
• Network and Host Based Intrusion Detection (logs
  and configs)
• Security Event Managers (logs and configs)
• Sniffers (trace files, packet captures)

36
High Risk and Liability
37
An Enterprise Incident Response System

• Immediately connect

• Review, analyze and
• acquire any data
• deleted or hidden

• See what was
• modified

• Reduce service disruptions

• Look for malware or
• backdoors

• Analyze attack for
• vulnerabilities

• Maximizes perimeter defenses

Anywhere anytime investigations for the
Enterprise
38
Forensic Analysis Identify Threats Before
Damage
Internal threats identified
Group audits for information risk identification
are routine
39
Incident Response System Enterprise Response,
Analysis and Discovery (ERAD)

• Incident Response
• Immediate incident analysis for optimal
  corrective action

• Forensic Analysis
• Verify user/system compliance to internal
  security policies
• Verify corporate compliance to legislated
  policies

• Forensic Discovery
• Internal Discovery
• Enterprise wide investigations of internal issues
• eDiscovery
• Enterprise wide discover for litigation

40
Incident Response Resources

• Incident Response, Electronic Discovery, and
  Computer Forensics
• www.incident-response.org
• Security Focus
• www.securityfocus.com
• The Federal Computer Incident Response Center
  (FedCIRC)
• www.fedcirc.gov
• The Canadian Office of Critical Infrastructure
  Protection and Emergency Preparedness
• www.ocipep.gc.ca
• Incident Handling Links Documents (75 links)
• http//www.honeypots.net/incidents/links
• SEI Handbook for Computer Security Incident
  Response Teams
• http//www.sei.cmu.edu/pub/documents/98.reports/p
  df/98hb001.pdf
• CERT/CC Computer Security Incident Response
• http//www.cert.org/csirts/
• CERT/CC Responding to Intrusions
• http//www.cert.org/security-improvement/modules/
  m06.html
• AuCERT Forming an Incident Response Team
• http//www.auscert.org.au/render.html?it2252cid
  1920
• SANS S.C.O.R.E

41
Incident Response Resources (cont)

• SANS Reading Room Incident Handling
• http//www.sans.org/rr/incident/
• SANS Forum Incident Handling and Hacker Exploits
  Forum
• http//forum.sans.org/discus/messages/79/79.html?1
  047450013
• NIST SP 800-3 Establishing a Computer Security
  Incident Response Capability
• http//csrc.nist.gov/publications/nistpubs/800-3/8
  00-3.pdf
• CIAC Incident Reporting Procedures
• http//www.ciac.org/ciac/CIAC_incident_reporting_p
  rocs.html
• FIRST Forum of Incident Response and Security
  Teams
• http//www.first.org/
• IETF RFC 2196 - The Site Security Handbook
  (Chapter 5)
• http//www.ietf.org/rfc/rfc2196.txt?number2196
• IETF RFC 2350 - Expectations for Computer
  Security Incident Response
• http//www.ietf.org/rfc/rfc2350.txt
• CIO CyberThreat Response and Reporting
  Guideline
• http//www.cio.com/research/security/incident_resp
  onse.pdf
• ISS Computer Security Incident Response
  Planning
• http//documents.iss.net/whitepapers/csirplanning.
  pdf
• Incident Response Managing Security at Microsoft
  

42
About Guidance Software

• Founded 1997
• Pioneer of investigation software EnCase
• Largest provider of computer and enterprise
  investigations solutions and training
• Over 8,000 copies of EnCase sold and over 3,000
  trained per year
• Worldwide clients
• All major government agencies
• Over 90 of US and UK police agencies
• 32 of the Fortune 50
• Headquartered in Pasadena, CA
• Training facilities in Pasadena, CA Sterling, VA
  Liverpool, UK
• Worldwide resellers and training partners
• Recent Validation of EnCase
• State v. Cook 2002-Ohio-4812, 2002 WL 31045293,
  Court Expressly Recognizes Validity of EnCase

43
Questions ?