Lesson 6Basics
ofIncident Response
UTSA IS 6353 Security Incident Response
Overview
•Hacker Lexicon•Incident Response
UTSA IS 6353 Security Incident Response
Hacker Lexicon
• Rootkit - a collection of tools an intruder loads onto a compromised computer
• Usually Consists of:– trojanized utilities– network sniffers– log-cleaning scripts
UTSA IS 6353 Security Incident Response
Root Kits
• Three primary types:– traditional– loadable kernel modules (LKMs) for
Unix/Linux– kernel -level rootkit for Windows
• Hundreds of Root-kits in existence– Hackers sites contain “click and choose
smorgasbord” (KNOW THY ENEMY)
UTSA IS 6353 Security Incident Response
Basic RootKit Functionality
• Maintain Access
• Attack other Systems
• Destroy Evidence
UTSA IS 6353 Security Incident Response
Traditional Rootkit Tools
• Backdoors - programs that listen on TCP/UDP ports that allow intruder stealthy access
• Log wipers - utility which erases log files to hide signs of intruders presence
• Packet sniffers - software designed to monitor network traffic to capture packets of interest
• Internet Relay Chat (IRC) utilities for comms• DDOS agents - S/W that sends UDP/ICMP
floods
UTSA IS 6353 Security Incident Response
LKM Rootkits
• Most rootkits used against Unix/Linux systems are Loadable Kernel Modules (LKMs)
• Kernel is transparently modified:– Execute Redirection: remaps system utility calls
– Remote execution: commands transmitted via the net
– Promiscuous mode hiding: hides sniffers
– Task hacking: changing the user id (UID), effective user id (EUID), and file system user id (FSUID) of any process
UTSA IS 6353 Security Incident Response
LKM Rootkits
• Kernel is transparently modified (contd):– Real-time process hiding -sending the following:
“kill -31 process id” allows kernel to suppress all info about the given process
– Kernel Module Hiding: LKMs can actually mask their own presence (stealthy LKMs)
UTSA IS 6353 Security Incident Response
WINDOWS Rootkits
• Contains:– Kernel Mode Device Driver: “_root_.sys”
– Launcher program: “deploy.exe”
• Capabilities:– Back doors
– Hide files: files with _root_ will be hidden from “dir”
– Hide processes and registry entries
– Keystroke Intercept
UTSA IS 6353 Security Incident Response
Incident Response Overview
• Goals• Methodology• Preparation• Detection• Initial Response• Strategy Formulation• Investigation• Monitoring• Recovery• Reporting
UTSA IS 6353 Security Incident Response
What is an Incident?
Incident - an event in an information
system/network
Time based security: Protection time >> detection time + reaction time
Some say its all about vulnerability management
UTSA IS 6353 Security Incident Response
SANS/FBI Top 20 List
20 MOST CRITICAL INTERNET VULNERABILITIES
UP TO 800 POSSIBLE
SANS Institute 20 Most Critical Internet Security Vulnerabilities
UTSA IS 6353 Security Incident Response
General Vulnerabilities
1. Default installs of OSs and applications
2. Weak or non-existent passwords
3. Incomplete or non-existent backups
4. Large number of open ports
5. Lack of packet filtering
6. Incomplete or non-existent logging
7. Vulnerable CGI programs
Source: The SANS Institute
UTSA IS 6353 Security Incident Response
Windows Vulnerabilities
8. Unicode Vulnerability
9. ISAPI Extension Buffer Overflows
10. MS Remote Data Services Exploit
11. NETBIOS – Unprotected Windows
Networking Shares
12. Leakage via Null Session Connections
13. Weak Hashing in SAM (Lan Manager
Hash)Source: The SANS Institute
UTSA IS 6353 Security Incident Response
Unix Vulnerabilities14. Buffer Overflows in Remote
Procedure Call Services
15. Sendmail Vulnerabilities
16. Bind Weaknesses
17. R Commands
18. LPD – Remote Print Protocol Daemon
19. Sadmind and Mountd
20. Default SNMP StringsSource: The SANS Institute
UTSA IS 6353 Security Incident Response
Home User Guidelines
• Use strong passwords (alpha-numeric, over 8 characters)
• Make regular backups of critical data• Use virus protection software• Use a firewall as a gatekeeper between your
computer and the Internet• Do not leave computers online• Do not open attachments from strangers
Source: FBI
UTSA IS 6353 Security Incident Response
The Worst Can Happen
"Don't look at the past and assume that's the future. Look at the enemy's strengths
and your vulnerability. You've got to realize that the worst case does sometimes
happen."-Richard Clarke
Special Advisor for Cybersecurity
UTSA IS 6353 Security Incident Response
Goals of Incident Response
• Confirm or dispel incident
• Promote accurate info accumulation
• Establish controls for evidence
• Protects privacy rights
• Minimize disruption to operations
• Allow for legal/civil recriminations
• Provide accurate reports/recommendations
UTSA IS 6353 Security Incident Response
Incident Response Methodology
• Pre-incident preparation
• Detection• Initial Response• Strategy formulation• Duplication• Investigation
• Security measure implementation
• Network monitoring• Recovery• Reporting• Follow-up
UTSA IS 6353 Security Incident Response
7 Components of Incident Response
Pre-Incident Preparation
Detectionof
Incidents
InitialResponse
FormulateResponseStrategy
DataCollection
DataAnalysis
Reporting
Investigate the Incident
ResolutionRecovery
Implement Security Measures
Page 15, Fig 2-1, Mandia 2nd Edition
UTSA IS 6353 Security Incident Response
Detection
Firewall Logs
IDS Logs
Suspicious User
Sys Admin
DETECT
NotificationChecklist
Completed
ResponseTeam
Activated
UTSA IS 6353 Security Incident Response
Initial Critical Details
• Current time and date
• Who/what is reporting the incident
• Nature of the incident
• When the incident occurred
• Hardware/software involved
• Point of contact for involved personnel
UTSA IS 6353 Security Incident Response
INITIAL RESPONSE
Details from notification checklist
Prepared response team
I RN EI ST PI OA NL S E
Verifiedinformation
about the incident
Success
FailureHow muchinfo is enough?
UTSA IS 6353 Security Incident Response
Response Strategy Formulation
FormulateResponseStrategy
MgtApproved
Action Plan
Verifiedinformation about
the incident
ResponsePosture
Goal: determine most appropriate response strategy
UTSA IS 6353 Security Incident Response
Factors for Strategy
• How critical are the impacted systems?
• Data sensitivity
• Who are the perpetrators?
• Does the incident have publicity
• Level of access to the hacker
• Apparent skill of the attacker
• How much downtime can be tolerated
• Overall dollar loss involved
UTSA IS 6353 Security Incident Response
Common Incidents
• Denial of Service Attack
• Unauthorized Use
• Vandalism
• Information Theft
• Computer Intrusion
Type of incident + response likely outcome
Management Support
network downtimeuser downtimelegal liabilitypublcitytheft of intellectual property
UTSA IS 6353 Security Incident Response
Investigation Stage
Live System
Network Logs
Forensic Duplicate
Investigation InvestigativeReport
UTSA IS 6353 Security Incident Response
Security Measure Implementation Stage
Verified Info
Network Logs
Response Posture
ImplementingSecurity
RemediesMonitor
Isolateand Contain
Prevent Same Exposure! Fishbowling the attacker
UTSA IS 6353 Security Incident Response
Recovery/Reporting Process
Conclusions
Successful containment
Recovery
backupshardening
user educationCOOP
Report
Support Criminal ActionsLessons LearnedPrevent Repeats
UTSA IS 6353 Security Incident Response
What Will You Do?• We Need a Initial Response that:
– Supports the Goals of Computer Security
– Supports the Business Practices
– Supports Administrative and Legal Policy
– Is Forensically Sound
– Is Simple and Efficient (KISS)
– Provides an Accurate Snapshot for Decision Makers
– Supports Civil, Administrative, or Criminal Action.
UTSA IS 6353 Security Incident Response
Common Mistakes
• Failure to Document Findings Appropriately.
• Failure to Notify or Provide Accurate Information to Decision Makers.
• Failure to Record and Control Access to Digital Evidence.
• Wait Too Long Before Reporting.• Underestimating the Scope of Evidence
that may be found.
UTSA IS 6353 Security Incident Response
Common Mistakes
• Technical Blunders:– Altering Time/Date Stamps on Evidence
Systems– “Killing” Rogue Processes– Patching the System– Not Recording the Steps Taken on the
System– Not Acting Passively