Transcript Network Incident Response

Network Incident Response
Information Security Incident Investigation
For
2010 NWACC Security Workshop
Craig Schiller, CISSP-ISSMP, ISSAP
Agenda
Introduction
Incident Response
Network Forensics & Incident
Response
2
Incident Response
Required by most security policies
Most require a formal Incident Response
plan
You should have several means of
discovering incidents
Network Forensics & Incident
Response
3
Incident Response
Who’s watching your network?
Network Forensics & Incident
Response
4
Incident Response
Incident reported
PII exposed
YES
PII Exposed
Workflow
Suspected
Disaster
YES
DR
WorkFlow
YES
DMCA
Workflow
YES
VIF/Bot
Workflow
YES
Investigation
Workflow
NO
Suspected
DMCA
Violation
NO
NO
Spamming /
compromised
Account
YES
Spamming
Account
Workflow
NO
NO
Preservation
Request
YES
Preservation
Request
Workflow
Investigation
Request
NO
NO
Access
Request
Suspected VIF/
Bot
YES
Access
Request
Workflow
Spearphishing
YES
Spearphishing
Workflow
YES
Compromised
Website
Workflow
NO
Compromised
Website
Network Forensics & Incident
Response
5
Incident Detection
A/V, Anti-Spam, Anti-Spyware
Host based
Security logs
RUBotted – Trend Micro
Enterprise Reporting
User Help Desk Tickets
Abuse notifications
Quasi-Intelligence Organizations
Monitoring & Analysis
Ourmon
Firewall & Router logs
IDS/IPS – Host and Network
Darknets, Honeypots
DNS
Server & Workstation Log analysis
Malware analysis (Sandbox)
Forensics
Network Forensics & Incident
Response
6
Investigative Process Model
Persuasion and Testimony
Assessment
Experiment
Fusion
Correlation
Validation
Reporting
Analysis
Organization and Search
Reduction (Filtering)
Harvesting
Examination
Recovery
Preservation
Case
Management
Steps
Identification or Seizure
Incident/Crime Scene Protocols
Assessment of Worth
Accusation or Incident Alert
Network Forensics & Incident
Response
7
Operation Aching Mules
Network Forensics & Incident
Response
8
Operation Aching Mules
NYPD detectives entered a Bronx bank in February to investigate a
suspicious $44,000 withdrawal. International investigation began in
Omaha, in May when fraudulent ACH payments were made to 46 bank
accounts
Cyber-attacks began in Eastern Europe, sending apparently-benign
email to computers at small businesses and municipalities in the US
Clicking on a link downloaded Zeus
The malware recorded their keystrokes as they logged into their
bank accounts online
Hackers made unauthorized transfers of thousands of dollars at a
time to receiving accounts controlled by the co-conspirators.
Once the victim/employee begins executing an online banking
transaction on behalf of his or her employer, ZeuS invisibly also
executes a fraudulent wire transfer, usually for $10,000 or less.
Network Forensics & Incident
Response
9
Operation Aching Mules
Money Mules
Receiving accounts were set up by a "money mule
organization" responsible for retrieving the proceeds of the
malware attacks and transporting or transferring the stolen
money overseas.
The money mule organization recruited individuals who had
entered the United States on student visas, provided them
with fake foreign passports, and instructed them to open
false-name accounts at U.S. banks.
Once these false-name accounts were successfully opened
and received the stolen funds from the accounts
compromised by the malware attacks, the "mules" were
instructed to transfer the proceeds to other accounts, most of
which were overseas, or to withdraw the proceeds and
transport them overseas as smuggled bulk cash.
Network Forensics & Incident
Response
10
Operation Aching Mules
U.S. authorities charged 92 Russians and Eastern Europeans
who allegedly opened U.S. bank accounts expressly to receive
cash transferred from hacked online banking accounts.
The defendants charged in Manhattan federal court include
managers of and recruiters for the money mule organization, an
individual who obtained the false foreign passports.
19 Eastern Europeans were arrested in the UK.
The Ukrainian SBU arrested 5 key subjects of the investigation.
$70M over the last four years.
Network Forensics & Incident
Response
11
VIF/BOT scenario
VIF/Bot
Workflow
Internet
Botnet Sensors
Botnet Sensors
Security Researcher
Wormwatch mailing list
131.252.x.x NERO says bad
131.252.x.x Acting Bad
131.252.x.x talking to bad
McAfee
Server
38.100.x.x McAfee says bad
Create Tracking Ticket
Block Network access
Identify location
Identify computer or user
Server Support
User Support
Network Team
User Reports
TAGs
Identify computer or user
Identify ServIer or webpage owner
Locate infected system
Retrieve computer
Identify compromised account
Identify system owner
Backup all files
Locate malware
Re-image computer
Perform quick forensics
Determine attack vector
Re-image computer
Security Team
Identify computer or user
Review quick forensics
Perform deep forensics
Ensure appropriate resources are working the incident
Identify useful intelligence markers
Network Forensics & Incident
Response
12
Incident Detection examples
Reports from Anti-Virus Enterprise server
1. today, Mcafee, 131.252.242.243, pri=hi, JS/Wonka [**] [1:3111116:1] Mcafee
http feed: :http://bluebookcarpices.com/ <http://pices.com/> (JS/Wonka) [**]
[Classification: access to a potentially vulnerable web application] [Priority: 2]
05/21-08:13:56.950979 131.252.242.243:52733 -> 216.240.128.250:80 TCP
TTL:63 TOS:0x0 ID:38398 IpLen:20 DgmLen:568 DF
***AP*** Seq: 0xD222814A Ack: 0x278524DD Win: 0xFFFF TcpLen: 32 TCP
Options (3) => NOP NOP TS: 345145726 2079777105
Reports from Intrusion Detection System (IDS)
2. today, zlob, 131.252.243.80, pri=hi
[**] [1:666666:1] zlob dns request [**]
[Classification: Potentially Bad Traffic] [Priority: 2]
05/21-09:50:22.532193 131.252.243.80:49190 -> 85.255.115.29:53 UDP
TTL:63 TOS:0x0 ID:3755 IpLen:20 DgmLen:73
Len: 45
Network Forensics & Incident
Response
13
Forensics/Internal Intel Gathering
•
Quick Forensics
• Process Explorer
• TCPView
• AutoRuns
• Process Monitor
•
Rpier – First Responder Tool
• Automated Forensics
• Consistent information gathered regardless of who runs it
• Sleuthing
• How did they get in?
• What does it do?
• What files are used?
• When did what happen?
• Malware Analysis
•
More Sleuthing
Network Forensics & Incident
Response
14
Security Event log
I checked and I didn’t see anything
Network Forensics & Incident
Response
15
Forensics/Intel Gathering example
Process
PID
CPU
Description
Company Name
System Idle Process 0
93.36
Interrupts
n/a
1.56
Hardware Interrupts
DPCs
n/a
Deferred Procedure Calls
System
4
0.39
smss.exe
508
Windows NT Session Manager
Microsoft Corporation
csrss.exe
620
Client Server Runtime Process Microsoft Corporation
winlogon.exe
884
Windows NT Logon Application Microsoft Corporation
services.exe
944
Services and Controller app
Microsoft Corporation
svchost.exe
1180
Generic Host Process for Win32 Services Microsoft
Corporation
wmiprvse.exe 3400
WMI
Microsoft Corporation
svchost.exe
1252
Generic Host Process for Win32 Services Microsoft
Corporation
svchost.exe
1312
Generic Host Process for PSXSS.EXE
896
Interix Subsystem Server
Microsoft Corporation
init
2156
Interix Utility
Microsoft Corporation
inetd
2432
Interix Utility
Microsoft Corporation
iexplorer.exe
3560
explorer.exe
8564
Windows Explorer
Microsoft Corporation
ccApp.exe
9208
Symantec User Session
Symantec Corporation
VPTray.exe
8636
Symantec AntiVirus Symantec Corporation
VPC32.exe
9524
Symantec AntiVirus Symantec Corporation
iexplorer.exe
6712
sqlmangr.exe
9904
SQL Server Service Manager
Microsoft Corporation
Network Forensics & Incident
Response
16
Forensics/Intel Gathering example
Network Forensics & Incident
Response
17
Forensics/Intel Gathering example
Network Forensics & Incident
Response
18
Forensics/Intel Gathering example
Strings in the file iexplorer.exe
Strings in memory
Network Forensics & Incident
Response
19
Analyzing the Malware
CWSandbox Analysis
Network Forensics & Incident
Response
20
Carsten Willem’s CWSandbox
Ubuntu
VMWare
XP Pro
Network Forensics & Incident
Response
21
The Future
Network Forensics & Incident
Response
22
Movie
BUM60.MOV
Network Forensics & Incident
Response
23
Spearphishing scenario
External Reporting
Create Tracking Ticket
Identify computer or user
Review quick forensics and perform deep forensics
Contact Anti-spearphishing
vendor
Contact phishing site hostt and
ISP
Contact Aggregating sites
Ensure appropriate resources are working the incident
Identify useful intelligence markers
Perform anti-spearphishing tasks
Network Forensics & Incident
Response
24
Spearphishing investigative model
Investigation Method Step
Spearphishing Response Scenario
Accusation or Incident Alert
Notify – Make it easy for detection and notification to occur.
Assessment of Worth
Prioritize this incident in relation to other work of the organization.
Incident/Crime Scene
Protocols
Begin the process of ensuring the admissibility of evidence
Detection
Identification or Seizure
Using the protocols established above, ensure that all potential network evidence is
identified and documented.
Analysis
Preservation
Document the incident and open an incident ticket – Notify wormwatch
Recovery
Identify and collect potential evidence from network and enterprise systems.
Harvesting
Use experience to examine the collected data and identify class characteristics that might
contribute to the investigation
Reduction
Use the output of the Harvesting step to extract phishing site specific network traffic
entries from evidence sources (firewall logs, tcpdump, Ourmon logs, Net Flow data, etc.)
Organization and Search
Use consistent naming schemes and folder hierarchies. Make it easier for the investigator
to find and identify data during the Analysis investigation step. Enable repeatability and
accuracy of subsequent analysis.
Analysis
Analyze the timeline (temporal analysis), the relationships between the phisher’s IP
addresses and other attacks (relational analysis), conditions or data that might tend to make
the incident possible or impossible (functional analysis). Analyze the IP addresses to ID
source. Determine why this victim was selected (Victimology).
Preparation
Network Forensics & Incident
Response
25
Spearphishing investigative model
Containment,
None
Triage – stop the bleeding. Identify the compromised account owner. Keep future
attempts using the attack vector from reaching their intended target. Feed the attackers
IP addresses to local detection software and networking. Contact IP related ISPs or host
organizations
Eradication
None
Search mail systems for other compromised accounts. Locate and re-image any system
that downloaded malware
Recovery
None
Recover the compromised account. Prevent the attackers from continuing to use the
compromised accounts. Return the users system to normal operation. Educate the users
on spearphisher techniques and how to recognize them
Post-Incident
Activity
Reporting
Contact Law Enforcement
Feed the attackers IP addresses to intelligence aggregation organizations
Persuasion and
Testimony
Prepare presentations and brief executive management. Give awareness presentations to
relevant stakeholders.
Network Forensics & Incident
Response
26
Spearphishing email
Network Forensics & Incident
Response
27
Recover userful information
You can extract the following information from the spearphishing email:
The from and reply-to email addresses.
The subject line and message ID
The URL of the phishing site
The originating IP address
The domain of the originating IP address
The domain of the phishing site
Network Forensics & Incident
Response
28
Spearphishing email
Return-Path: <[email protected]>
Received: from murder (beli.oit.pdx.edu [131.252.122.1])
by backend03.psumail.pdx.edu (Cyrus v2.2.12) with LMTPSA
(version=TLSv1/SSLv3 cipher=AES256-SHA bits=256/256 verify=YES);
Tue, 13 Jul 2010 09:40:08 -0700
X-Sieve: CMU Sieve 2.2
Received: from beli.oit.pdx.edu ([unix socket])
by psumail.pdx.edu (Cyrus v2.2.13) with LMTPA;
Tue, 13 Jul 2010 09:40:08 -0700
Received: from nithog.oit.pdx.edu (nithog.oit.pdx.edu [131.252.120.55])
by beli.oit.pdx.edu (8.14.1+/8.13.1) with ESMTP id o6DGe8L5014251
for <[email protected]>; Tue, 13 Jul 2010 09:40:08 -0700
Received: from gtwy.camden.k12.ga.us (mail.camden.k12.ga.us [168.11.97.73])
by nithog.oit.pdx.edu (8.14.1+/8.13.1) with ESMTP id o6DGe6Ow021644
for <[email protected]>; Tue, 13 Jul 2010 09:40:07 -0700
X-Authentication-Warning: nithog.oit.pdx.edu: Host mail.camden.k12.ga.us [168.11.97.73] claimed to be
gtwy.camden.k12.ga.us
Received: from gtwy.camden.k12.ga.us (unknown [127.0.0.1])
by IMSA (Postfix) with ESMTP id 62BD211014E;
Tue, 13 Jul 2010 12:40:05 -0400 (EDT)
Received: from exchange2.camden.k12.ga.us (unknown [168.11.97.41])
by gtwy.camden.k12.ga.us (Postfix) with ESMTP id DF3E711014B;
Tue, 13 Jul 2010 12:40:04 -0400 (EDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: Mailbox Quota
Date: Tue, 13 Jul 2010 12:40:03 -0400
Message-ID: <85A63B83E0776A4E8D5416E0A7E805490BDBAA2D@exchange2.camden.k12.ga.us>
From: "Sandra J. Deloach" <[email protected]>
To: undisclosed-recipients:;
Network Forensics & Incident
Response
29
Limit the damage
Block outbound traffic to IP address
Block by web filtering
DNS Cache Poisoning
Your DNS server could intercept and poison any responses to
systems that lookup either domain. By replacing the actual DNS
response with an address in your Darknet and instrumenting a
system with that address you could gain a warning every time
someone responded to the attack.
Network Forensics & Incident
Response
30
Spearphish Campaign spreadsheet
Network Forensics & Incident
Response
31
Phishing website
Network Forensics & Incident
Response
32
Gathering intelligence
100713-spearphishing-passwords.saz
Network Forensics & Incident
Response
33
Gathering intelligence
Network Forensics & Incident
Response
34
Gather Intelligence
Extracted passwords
Network Forensics & Incident
Response
35
Compromised Accounts (spammers)
Internet
E-mail server
Server Support
Maintain list of Bad actors
Monitor logins for bad actors
Monitor sent mail thresholds
Search for phish responders
Disable accounts
User Support
Look up contact info
Contact user
User Interaction
Change password
Clean Signatures
Request account re-enable
Security Team
Notify Server support about phishing responders
Confirm user account is supposed to be active
Network Forensics & Incident
Response
36
Search Engine Spam – Victimless crime?
Is it really victimless?
Cheat the poor and technology weak out of their hard-earned money
Operators of Search engine spam sites are linked to Child Porn
Reputational damage and DoS
Network Forensics & Incident
Response
37
Damage to Your University’s Reputation
Network Forensics & Incident
Response
38
Search Engine Spam
Google Alerts
Internet
External email notice
Security Team
Ensure appropriate resources are working the incident
Process Google Alert
Identify useful intelligence markers
Analyze Compromised Web Site
Contact ISP and/or website owner and linked pages
Create Tracking Ticket
Share with aggregators
ID website owner/developer
Wormwatch mailing list
Analyze Malware
Network Team
Block Network access
Server Support
TAGs
Identify ServIer or webpage owner
Send malware to Security Team
Locate infected system
Identify compromised account
Mitigate vulnerability
Identify system owner
Locate malware
Shutdown Webpage access
Mitigate vulnerability
Determine attack vector
Collect and Analyze logs
Restore Webpage
Determine exploited vulnerability
Clear the Google cache
Work with Server Support
Website Owner
Limit damage
Find Root cause
Mitigate vulnerability
Restore Webpage & ask to restore access
Keep Security Team informed on status
Network Forensics & Incident
Response
39
Search Engine Spam & Clicks 4 Hire
Use Google to search for Clicks-4-Hire relays and search engine spam
site:yoursite.com -pdf -ppt -doc phentermine OR viagra OR cialis OR vioxx OR oxycontin OR levitra OR ambien
OR xanax OR paxil OR "slot-machine" OR "texas-holdem"
Network Forensics & Incident
Response
40
Google site search results
Network Forensics & Incident
Response
41
Google Alerts
[email protected]
Network Forensics & Incident
Response
42
Google Alerts Results
Network Forensics & Incident
Response
43
An owned webpage
Network Forensics & Incident
Response
44
Browser Intelligence gathering
Network Forensics & Incident
Response
45
Links to this web page
Network Forensics & Incident
Response
46
Fiddler sleuthing
Network Forensics & Incident
Response
47
Base64 Encoding
<?php
eval(base64_decode("ZXJyb3JfcmVwb3J0aW5nKDApOw0KJGJvdF9saXN0ID
0gYXJyYXkoIjguNi40OCIsIjYyLjE3Mi4xOTkiLCI2Mi4yNy41OSIsIjYzLjE2My4xM
DIiLCI2NC4xNTcuMTM3IiwiNjQuMTU3LjEzOCIsIjY0LjIzMy4xNzMiLCI2NC42O
C44MCIsIjY0LjY4LjgxIiwiNjQuNjguODIiLCI2NC42OC44MyIsIjY0LjY4Ljg0IiwiNj
QuNjguOD
Network Forensics & Incident
Response
48
Base64 Encoding
Network Forensics & Incident
Response
49
Base64 Encoding
if (preg_match('/live|msn|yahoo|google|ask|aol/',
$_SERVER["HTTP_REFERER"])) {
$tabs = array
('viagra','cialis','levitra','propecia','prozac','xenical','soma','zoloft','tamiflu','sildenafil'
,'tadalafil','vardenafil','finasteride','hoodia','acomplia','phentermi
ne','adipex','tramadol','ultram','xanax','valium','ambien','ativan','vicodin','hoodia','ac
omplia');
$niche='unknown';
foreach($tabs as $tab)
{
if(preg_match("/$tab/", $_SERVER["HTTP_REFERER"]))
Network Forensics & Incident
Response
50
302 Error hijacking
If the source of the highlighted URL differs from the source when you
browse directly to the same page, then the spammers may be hijacking
your Google response.
Google hijacking presents a serious challenge to your eradication efforts
as Google has not provided a process for dealing with these incidents.
See the web page (http://www.loriswebs.com/find-hijacker.html) for more
information about 302 errors and Google hijacking. She also has
directions for reporting 302 error hi-jacking located here
(http://www.loriswebs.com/report-302redirect.html).
This process attempts to address the hi-jacking by approaching the ISP or
hosting service, reporting the incident as a terms of service violation. It’s
the best you can do until Google addresses the issue of de-coupling sites
that shouldn’t be able to influence the search engine results about your
sites.
Network Forensics & Incident
Response
51
Search Engine Spam removal
1. Info-Security/Website owner monitors Google alerts
2. Info-Security/Webserver Administration locates the web server
administrator and create a ticket in the appropriate help desk ticket queue.
The organizational communications office should be cc’d in the ticket.
3. Unix/other webserver administrator resets permissions so they are no
longer www/world-writable then captures and deletes offending files
4. Unix/other webserver administrator attempts to locate and mitigate the
initial attack vector
5. Unix/other admin clears google cache
6. Unix/other admin moves the help desk ticket back to the security-requests
queue
7. Info-Security/Webserver Administration notifies the site owner (see below
for text) and BCCs [email protected]
8. Info-Security closes the ticket
Network Forensics & Incident
Response
52
Compromised Website
Google Alerts
External email notice
Internet
Botnet Sensors
(Ourmon, FireEye, Snort)
Security Team
Security Researcher
Wormwatch mailing list
Ensure appropriate resources are working the incident
Process Google Alert
131.252.x.x NERO says bad
Identify useful intelligence markers
Analyze Compromised Web Site
131.252.x.x Acting Bad
Contact target ISP and/or website owner & linked pages
Create Tracking Ticket
131.252.x.x talking to bad
Share with aggregators
ID website owner/developer
38.100.x.x Extternal source says bad
Wormwatch mailing list
Analyze Malware
User Support
Server Support
User
Interaction
TAGs
Route HelpDesk tickets to Security
Identify ServIer or webpage owner
Locate infected system
Route Tickets to Server, TAG or
Identify compromised account
Identify system owner
Website Owner
Locate malware
Re-image computer
Determine attack vector
Website Owner
Limit damage
Find Root cause
Mitigate vulnerability
Restore Webpage & ask to restore access
Keep Security Team informed on status
Network Forensics & Incident
Response
53
Uploading fake pictures
Network Forensics & Incident
Response
54
Php url includes
Network Forensics & Incident
Response
55
Mod-Sec SQL Injection
--346e283e-A--[04/Aug/2008:02:30:00 --0700] @7eQMYP8ehcAAE5qKi4AAAAR
87.118.116.150 47075 131.252.122.155 80
--346e283e-B--GET
/shesheet/wordpress/index.php?cat=%2527+UNION+SELECT+CONCAT(666,CH
AR(58),user_pass,CHAR(58),666,CHAR(58))+FROM+wp_users+where+id=1/*
HTTP/1.0Accept: */*User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows 98;
DigExt)Host: www.wrc.pdx.eduConnection: close
--346e283e-F--HTTP/1.0 200 OKX-Powered-By: PHP/5.2.5X-Pingback:
http://www.wrc.pdx.edu/shesheet/wordpress/xmlrpc.phpConnection:
closeContent-Type: text/html; charset=UTF-8
--346e283e-H--Message: Warning. Pattern match
"(?:\\b(?:(?:s(?:elect\\b(?:.{1,100}?\\b(?:(?:length|count|top)\\b.{1,100}?\\bfrom|fro
m\\b.{1,100}?\\bwhere)|.*?\\b(?:d(?:ump\\b.*\\bfrom|ata_type)|(?:to_(?:numbe|cha)
|inst)r))|p_(?:(?:addextendedpro|sqlexe)c|(?:oacreat|prepar)e|execute(?:sql)?|mak
ewebt ..." at ARGS:cat. [id "950001"] [msg "SQL Injection Attack. Matched
signature <union select>"] [severity "CRITICAL"]Stopwatch: 1217842199892017
888678 (5475 6478 -)Producer: ModSecurity v2.1.5 (Apache 2.x)Server:
Apache/2.2.8 (OpenPKG/CURRENT)--346e283e-Z-Network Forensics & Incident
Response
56
DMCA
DMCA complaint
Internet
Horde
Abuse Imap Folder
Email to [email protected]
From copyright owner
From consortium rep. owner
Settlement bids
Organized crime
Network Team
User Reports
Dean of Students
Student Legal
Extract DMCA complaints
Process AUP violation
Create Tracking Ticket
Communicate with user
Identify computer or user
Issue Sanctions
Email and mail user
Inform NTS that sanctions have been satisfied
Counsel student of legal aspects
User Support
Refer “It wasn’t me” claims
Sign form when complete
Coordinate strategy with DoS & CISO
Receive user responses
Forward responses to NTS
If no response or 2nd violation
Block Network access
File AUP violation with Dean of Students
Security Team
Investigate “It wasn’t me” claims
Investigate questionable DMCA complaints
Give DMCA formal sanction presentation
Coordinate strategy with SLMS & Dean of Students
Sign form when complete
Network Forensics & Incident
Response
57
DMCA Investigative process
Investigation
Method Step
DMCA Violations Response Scenario
Accusation
or Incident
Alert
Notify – Most notifications are sent to your abuse email address. Final stages (subpoenas) may be sent via
snail mail. Notifications that skip the “Take-Down” notice stage should be vetted. Seek legal counsel’s advice
about forwarding suspect notices
Assessment
of Worth
You are legally obligated to forward DMCA notices to the intended recipient in a timely manner. Failure to do
so could cost “Safe Harbor” status and could result in your organization being made a party to the resulting
lawsuits. You should only investigate the claim if a user disputes the allegation.
Incident/Cri
me Scene
Protocols
Begin the process of ensuring the admissibility of evidence. Designate an organization and an individual to be
responsible for keeping all DMCA documentation. All copies of notices and responses from the suspect
should be retained. Any analysis performed related to the case should be identified and preserved with the
other case documentation.
Detection
Identification
or Seizure
Using the protocols established above, ensure that all potential network evidence is identified and
documented. Ensure that the IP to dhcp mapping is captured in a timely manner since it is dynamic and dhcp
logs may not last forever.
Analysis
Preservation
Document the incident Open Incident Ticket – Use special DMCA queue for all DMCA related tickets
Recovery
Identify and collect potential evidence from network and enterprise systems. These notices sometimes come
months after the actual event. If user disputes the claim, and the logs still exist, gather them from firewalls,
switches, Ourmon, or dhcp. If too much time has passed your may have to rely on the suspect’s computer.
The suspect may be hostile to your investigation, even if innocent. They may ask you to investigate while
attempting to obscure the evidence of the incident.
Harvesting
Use experience to examine the collected data and identify class characteristics that might contribute to the
investigation. In DMCA cases you are primarily performing functional analysis. You are looking for evidence
that would include or exclude the user’s computer from the alleged act (such as right or wrong Mac address,
presence or absence of network traffic supporting the allegation, etc.)
Preparation
Network Forensics & Incident
Response
58
DMCA Investigative process
Reduction
Use the output of the Harvesting step to extract allegation specific network traffic entries from evidence
sources (firewall logs, tcpdump, Ourmon logs, Net Flow data, etc.). From the suspect’s computer you
might extract firewall logs, Internet history, Internet browser caches, temporary Internet files.
Organization
and Search
Use consistent naming schemes and folder hierarchies. Make it easier for the investigator to find and
identify data during the Analysis investigation step. Enable repeatability and accuracy of subsequent
analysis.
Analysis
Locating the user’s identity will involve relational analysis For LAN connections your network team will
examine relationships between the IP address, MAC address and a time frame, between the MAC address,
the dhcp server, and the switch; between the switch, the MAC address, and the switch port; between the
switch port and data jack; between the data jack and a physical location; and between the physical room
and the people associated with that room. Authenticated wireless connections at Portland State tie the
userid to an IP address at a particular time. If the user disputes the copyright owner’s claims then you will
perform temporal analysis to group all activities that were recorded during the time of the alleged incident.
You would then use the results of temporal analysis to perform functional analysis, in which you determine
if the available evidence tends to support claim of the copyright holder or not. If not, then you should
determine if the evidence points to another suspect or if there is no data related to the incident. If this is the
case consider and investigate the potential that the notice was fraudulent. Determine why this victim was
selected (Victimology).
Containment
,
None
Triage – Your organization is obligated by DMCA to prevent the recurrence of this kind of event. Most
organizations shut off internet access if the suspect is notified three times. Portland State performs this
action on the second notices. If the suspect is a student, the Dean of Students is notified. In order to regain
network access, the student must attend briefings by Student Legal and Mediation Services and by IT. The
Dean of Students can take other punitive actions if there are further incidents, such as Loss of Network
privileges for a year, or fines of up to $200.
Eradication
None
Subjects are directed to remove all copyrighted material that was identified in the take-down notice.
Network Forensics & Incident
Response
59
DMCA Investigative process
Recovery
None
Subjects are directed to respond to the notice in which they acknowledge having received the notice, that
they understand the DMCA policy, and that they will comply with it in the future. They are instructed to
take down the intellectual property that was identified in the notice. The subject is not required address
guilt or innocence. Once they have followed the instructions then their network access is restored. Users
who receive two or more notices are required to attend a DMCA awareness briefing.
Post-Incident
Activity
Reporting
Annually, the numbers of notices received and presentations given should be reported to management.
Subpoenas, notices of intent to file a subpoena, and settlement offer letters should be reported to General
Counsel
Persuasion
and
Testimony
Prepare presentations and brief executive management. Give awareness presentations to relevant
stakeholders. Prepare pamphlets, informational websites, flyers, etc to reduce the rate of DMCA incidents.
Network Forensics & Incident
Response
60
DMCA Workflow
Network Forensics & Incident
Response
61
PII Suspected Incident
• Is it an incident?
• Incidents require mitigation
• Incidents may or may not require notification
• Is it a breach?
• Breaches require mitigation
• Breaches require notification
All breaches are incidents but not all incidents are breaches
Network Forensics & Incident
Response
62
What is a Breach?
A (reportable) breach is the unauthorized acquisition, access,
use, or disclosure of PII in a manner not permitted by law or
regulation and which compromises the security and privacy of
the PII.
Paraphrased from a PHI breach definition
by Pepper Hamilton, LLP
We are using the term breach to describe all incidents that
legally require notification to damaged parties.
Network Forensics & Incident
Response
63
Relevant Law or Regulation
FERPA: protection of student data
FACTA Red Flag Rules: finance
Payment Card Industry Data Security Standard: credit cards
Gramm-Leach-Bliley (GLB) Act: financial consumers
USA Patriot Act: data preservation and wiretapping requests
Student and Exchange Visitor Information System (SEVIS): international students
Higher Education Opportunity Act: record keeping, business processes, and reporting
Health Insurance Portability and Accountability Act (HIPPA): health records
HITECH Act – Private Health Information, breach notification and enforcement
Digital Millennium Copyright Act (DMCA): protection of digital media
Electronic discovery (E-discovery): also Rule 37 of the Federal Rules of Civil
Procedure
Jeanne Clery Disclosure of Campus Security Policy and Campus Crime Statistics Act
(Clery Act): campus crime
State law – e.g. Oregon Identity Theft Protection Act
Personally Identifiable Information breach notification
State law regarding disclosure of Faculty/Staff records
PCI Standards– credit card and bank account information
VISA PA-DSS Best Practices and Validated Applications list
Others? Information covered by NDAs, Information protected by export law
Network Forensics & Incident
Response
64
Breach or Incident?
Two methods for Determining if a breach occurred
• By Definition
• By Risk of Harm Analysis
• How do you prove a negative?
Network Forensics & Incident
Response
65
What if there is no known Harm?
A compromise of the security and privacy of personal
private information must pose a significant risk of financial,
reputational, or other harm to the individual.
Use a risk assessment to determine if harm exists.
Pepper Hamilton LLP Webinar
Not all disclosures will be breaches - it must cross the harm
threshold.
Overcoming access controls does not constitute a breach by itself.
It must lead to a use and disclosure of PPI that is not permitted by
law or regulation and it must also cross the “harm threshold.”
Network Forensics & Incident
Response
66
Risk of Harm Questions
Were the recipients obligated (by policy or regulation) to protect
privacy and security of the information?
Can the impact of the disclosure be mitigated?
Pre-existing NDAs or other measure which assure no
further disclosure
Was it returned before improper use could occur?
Did forensics investigation find any evidence of improper
use, discovery, or distribution?
What was disclosed and how much?
Network Forensics & Incident
Response
67
No Breach?
A Breach has not Occurred if:
PII is not stored in the cloud
PII is “Secured” (encrypted*)
There is Little Risk of Harm
Pepper Hamilton, LLP
* some states also exempt encoded data
Network Forensics & Incident
Response
68
Activity: Putting it in to practice
Questions:
Is this a breach or incident?
What process did you use to make your decision?
Who needs to be notified? How?
What mitigation may be necessary?
Network Forensics & Incident
Response
69
Scenarios
Suspected incidents
• A former student reports to you that, using
Google, he has found his SSN on one of your
systems.
• A professor reports to you that his laptop was
stolen and in it he maintained a list of student
names and Student-ID numbers.
• A professor discovers that he can see other
employee’s home directories.
• A staff person discovers advising files of current
and former students available to view by all
authenticated users on web accessible storage
service
• A website hosted in the cloud is de-faced.
Network Forensics & Incident
Response
70
SSN found via Google
One of your former student reports to you that, using Google, he
has found his SSN on one of your systems.
•
•
•
•
Data, when stored (2004), was not considered sensitive
Some data was not PII but was still sensitive
Data was stored on a Listserv which Google crawled
IN 2005-2007, some instances were removed from the Listserv
• But not from Google’s cache of the webpage!
Network Forensics & Incident
Response
71
SSN Breach-Response
Discovery
•
•
Searched for other, similar PII data
Determine where other instances may have been cached (Internet Time Machine, Google,
etc.)
Short-term mitigation
•
•
•
Known PII Data was taken down
Google’s cache was flushed
Listserv was reconfigured to change all lists to private
Notification
•
Met with General Counsel and HR
• Determined this was a breach (by definition and risk of harm analysis)
• Briefed executive level
• Drafted a letter to send to the potential victims
• For sensitive data not covered by law or regulation, the business owner was given the
option to notify or not (subject to executive override)
Long-term Mitigation
•
•
Reviewed lists and deleted all lists that haven’t had activity in 2 years (timebomb of unnecessary liability)
Changed our process to make private the default listserv setting
Awareness
•
•
Discussed posting practices with listserv owner
Documented and Responded to users questions from the notification
Network Forensics & Incident
Response
72
Student ID
One of your professors reports to you that his laptop was
stolen and in it he maintained a list of student names and
Student-ID numbers.
Is it a breach by definition?
According to the Dec 2008 FERPA revision, it depends.
Network Forensics & Incident
Response
73
Student ID
“we modified the rule to allow student ID numbers to be
disclosed as directory information if they qualify as electronic
identifiers”
“The regulations will allow an educational agency or institution
to disclose as directory information a student’s ID number,
user ID or other electronic identifier so long as the identifier
functions like a name; that is, it cannot be used without a PIN,
password, or some other authentication factor to gain access
to education records. This change will impose no costs and
will provide benefits in the form of regulatory relief
allowing agencies and institutions to use directory
services in electronic communications systems without
incurring the administrative costs associated with
obtaining student consent for these disclosures.”
Network Forensics & Incident
Response
74
Student ID
"Directory Information", data that can be made public without
*student* permission. Each college must decide, within certain
limits, what it considers Directory Information, and must publish
the list. Typically this includes things like name, phone number,
address, graduation year, and major. According to FERPA
Regulations, Directory Information is "information contained in
an education record of a *student* that would not generally be
considered harmful or an invasion of privacy if disclosed".
Steven Worona
In order to treat the student id as directory information, each
college must officially declare it to be so and publish the new list
of directory information.
Network Forensics & Incident
Response
75
Exception
However, parents and eligible students can opt out of directory
information disclosures; those that do will not be able to
participate in student services that are delivered in this manner.
Which means you may have a student id related breach for a
few students even after declaring student identification to be
directory information.
Network Forensics & Incident
Response
76
Student ID Breach-Response
Discovery
•
Interviewed the Professor, determined there was only one instance of the lost data
Short-term mitigation
•
None
Notification
•
Met with General Counsel, Admissions, Records, and Registration (ARR) and HR
•
Determined this was a breach (by definition)
•
Briefed executive level
•
Drafted a letter to send to the potential victims, by the Professor’s department
Long-term Mitigation
•
Pursue including student-id as directory information
Awareness
•
Gave presentations about student-ID as directory information.
•
Began discussions with General Counsel and ARR
Network Forensics & Incident
Response
77
Small Private College with Law School
An Information Technology staff person discovered advising
files of 14 current and former students available to view by
all authenticated users (only) on our web accessible
storage service (Xythos). The files contained high school
transcripts and College application materials for our first
year advising program. These files contained personally
identifying information (SSN and birthdate).
Upon finding this information available, the IT staff person
immediately made a “copy” of the environment for
forensics purposes and then removed the permissions from
the files to protect that sensitive information. It was
determined that the files were accessible to all
authenticated users (and not the general public) for one
week. We were not able to determine if the files had been
viewed by anyone during that time period.
Network Forensics & Incident
Response
78
Small Private College with Law School
General Counsel advised that we notify the affected 14
individuals per the Oregon notification legislation. The
notification happened on September 2 through email and
certified postal mail, and offered a year of credit monitoring
(for which no one took us up on). Post incident: We
immediately suspended the first year advising application
utilizing the web storage service until the sensitive
information could be redacted from the scanned images.
Going forward all personally identifying information will be
redacted upon scanning.
Network Forensics & Incident
Response
79
College with Law School Response
Discovery
•
IT staff member discovered sensitive files for 14 students were viewable by any
authenticated user
Short-term mitigation
•
•
•
•
Copy of the environment made for forensics
Removed permissions from the sensitive files
Analyzed exposure (1 week), unable to determine if anyone viewed the files
Suspended the application from using the web storage service until the sensitive
information could be redacted from the scanned images
Notification
•
•
•
•
Can’t determine risk of harm
Met with General Counsel, determined this was a breach
Notified users via email and postal mail.
Offered 1 year of credit monitoring
Long-term Mitigation
•
Implement process to redact PII upon scanning.
Awareness
• Additional training may be indicated
Network Forensics & Incident
Response
80
Missing Access Control
A University professor discovers that he can see other
employee’s home directories.
Network Forensics & Incident
Response
81
Access Controls
Your staff discovers that six days ago the ACLs on your staff
directories/folders were unintentionally modified for a
vendor.
•
•
•
•
Inheritance was turned off, which changed all lower level
effective permissions.
Directories normally protected by restrictive ACLs were
modified to permit read-only access by anyone with an
active account.
Some of the folders definitely contain PII.
Audit trail object access was not enabled.
Network Forensics & Incident
Response
82
Access Controls
Ran Spider (from Cornell University) to identify PII at risk
•
One month to scan 10 volumes on the file server.
•
Identified all files accessed during the exposure period.
This significantly reduced the number of files at risk as
70.8% of all files were not accessed during the
exposure period.
Is this a breach or an incident?
Regardless we need to mitigate the situation
Network Forensics & Incident
Response
83
Access Control Incident-Response
Discovery
• Reported by University staff
• Root cause was analyzed
• Used Spider to scan affected volumes for PII
Short-term mitigation
•
•
•
Inheritance and permissions were fixed.
Access dates for all files on affected volumes were analyzed to determine scope of risk
All affected PII were identified.
Notification
•
•
•
•
Met with General Counsel, CIO,
contacted Oregon Division of Finance and Corporate Securities
Determined this was not a breach (by risk of harm analysis)
Sent email to users with PII
Long-term Mitigation
•
•
•
•
Legacy PII discovery effort
Provide secure enterprise storage for future PII.
Establish enterprise PKI for encryption infrastructure
Publish procedures requiring the use of encryption.
Awareness
• Presentations to HR admins, Executives admins, staff
• Presentations to technical admin about plans and timetables
Network Forensics & Incident
Response
84
Website in the Cloud De-faced
A website of yours that is hosted in a cloud is
defaced. Parts of this website can access
sensitive data that is also stored in the Cloud.
Network Forensics & Incident
Response
85
Website in the Cloud De-faced
In January 2010, shortly after President Obama
finished his State of the Union address, the
webpages of 49 Congressional members were
defaced. All of the webpages were managed by
GovTrends. GovTrends ironically had the
phrase “You get what you pay for” on their website.
In August 2009, 18 Congressional member
websites, also managed by GovTrends, were
defaced.
Network Forensics & Incident
Response
86
Website in the Cloud De-faced
Following the August attack, Representative B
sent a letter to the CAO (Chief Administrative
Officer) of the House, asking for actual details of
the attack and a plan for notification of these
incidents in the future.
Rep. B’s office contacted GovTrends and
requested copies of the appropriate logs.
GovTrends redirected him to HRIS. HRIS
claimed they do not investigate or prosecute
since there is no way to track down the criminals
responsible for this act.
Network Forensics & Incident
Response
87
Website in the Cloud De-faced
At a Cloud Law Summit Microsoft's head of
legal, Dervish Tayyip, said the company would
not provide financial guarantees against dataprotection issues on cloud contracts.
"We're not an insurance company. What is
important is that customers understand the
[cloud] offerings are standardised — they are
what they are. If the offering does not meet
customer needs, maybe the cloud is not a
realistic offering."
Cloud providers shrug off liability for security
By Tom Espiner, ZDNet UK, 12 February, 2010 13:30
Network Forensics & Incident
Response
88
Cloud Incident Response
Discovery
•
Prevented by Vendor refusal to cooperate
Short-term mitigation
•
Undetermined - experts claim vendors explanation makes no sense
Notification
•
Can’t determine risk of harm.
Long-term Mitigation
•
Nothing in the press about it.
Awareness
•
Articles on the web
Network Forensics & Incident
Response
89
Breach Response for Clouds
Unlike in-house repositories of information, you cannot assume that you have the right and the authorization to
investigate breaches in Clouds
You must ensure that your contract with the Cloud vendor permits you this capability.
If regulation requires that you protect your data from the Cloud provider then you must encrypt it and ensure
that the contract does not contain a provision which would permit the vendor from investigating your content.
If the data that you store in the cloud includes FERPA protected data, then the cloud provider must agree to act
as a FERPA agent for the university and to protect it as such.
Your contract should bind the cloud vendor to meet any regulatory and legal requirements that you are required
to meet.
Be aware that Law Enforcement may approach your Cloud vendor and demand access to your data even if
you have legal reservations about the legality of their request.
Surrendering your data to a third party weakens your position that the data is valuable unless you have taken
measures to affirm it’s value despite the transfer. These measures might include encrypting the data or
contractually binding the cloud vendor to protect the data in accordance with its value or sensitivity.
Your contract should explicitly grant your security and administrators the rights that you require regarding
monitoring and investigations.
For any Cloud user interface, the user should be informed that they should have no expectation of privacy
except that required by explicit law or regulation. They should have the user agree that use of the Cloud
constitutes consent to monitoring. This would need to be spelled out contractually with your Cloud vendor.
Network Forensics & Incident
Response
90
Breach Prevention for Clouds
You can avoid a breach in the cloud by requiring all data in the cloud to be encrypted.
You encrypt the data before storing it
You contract the Cloud provider to encrypt your data
Full Cloud encryption
Individually accountable encryption with a corporate escrow
Must gather assurances that the Cloud hosts have sufficient security (SAAP)
SAS-70
Must gather assurances that the Cloud application has sufficient security (SAAI)
Systrust or SAS-70
Must gather assurances that the Cloud based web application has sufficient security (SAAS)
Webtrust, SAS-70, vulnerability assessments or penetration
Network Forensics & Incident
Response
91
Example Incident/Breach Response Plan
Review the exposed material and determine the scope and nature of the incident.
Number of unique disclosures or opportunities for disclosure
To the best of our ability determine if there is any evidence that the exposed information was
accessed.
Take actions to limit or eliminate the exposure
Arrange a meeting with General Counsel, CIO, and the list owner.
Describe the incident, disclosures and the data found during the review.
Determine whether the disclosure (or potential disclosure) meets the criteria in the FERPA,
GLBA, FISMA, HIPAA, PCI standards, state law or regulation such as the Oregon ID Theft
Protection Act.
If yes,
If no clear evidence of disclosure, determine potential risk of harm
Draft and send a response to the individual that identified the disclosure
Draft a response to the individuals whose personally identifying information was
exposed.
Determine the cause of the exposure.
Determine permanent solution and implement.
Network Forensics & Incident
Response
92
Next Steps?
Gather info about
pockets of legacy
PII
Design Solutions
for PII Challenges
Acquire PII Search
Tools
Create PII
Awareness
campaign
Establish a PII
Incident Response
team
Search for legacy
PII
Secure known
legacy PII
Create Awareness
campaign for PII
removal
Determine Breach
thresholds and
Risk of Harm
criteria
Develop PII
template reponse
letters to reporting
individual
Develop PII
template reponse
letters to the
harmed individuals
Develop staff
communications
for departmental
involvement
Create strategy for
searching PII at
home
Create Awareness
campaign for PII
removal at home
Design Monitoring
strategy
Monitor for new PII
Sustaining
operations
Develop Reporting
and record
keeping process
Network Forensics & Incident
Response
93
Design solutions for PII challenges
•
•
•
•
Whole disk encryption (pgpdisk)
Enterprise supported file encryption (a PKI solution)
Secure file server (Truecrypt)
Personal file encryption (Winzip )
• Require network storage
• Segregate workstations that work with PII
•
No use of home computers.
•
Convert home computer to secure dumb workstation
•
Provide secure laptops for remote use
•
No dual use workstations for sensitive data
• Search all servers, data bases, workstations for PII
• Create strategy to let users search for PII on existing home systems.
• Data Loss Prevention systems (Discovery, Prevention of loss, Protection of the
data, Monitoring of PII use)
Network Forensics & Incident
Response
94
Remaining Issues
How do different states' breach notification laws apply to
Educause member institutions?
What is the threshold for victim notification? AG
notification?
Is a breach insurance policy a good strategy?
Should Educause/CIOs pursue agreements for credit
monitoring, post-breach forensics, or other services?
Should Encryption be required?
Network Forensics & Incident
Response
95
Questions
Questions or Discussions
Craig A Schiller, CISSP-ISSMP, ISSAP
Chief Information Security Officer
Portland State University
503.725.9107
Network Forensics & Incident
Response
96
Step1: Accusation or Incident Alert
Taking Notice of Suspicious Incidents
Circumstances that get the process started
Self-initiated incidents: “look for
circumstances”
Directed incidents – respond to calls
or alerts
What effect will this have on the evidence
should this turn out to be “something”?
Network Forensics & Incident
Response
97
Step 2: Assessment
Has a incident, breach, or crime occurred?
Triage – limited resources
Look for elements of a specific crime
Physical or serious financial injury?
Can problem be contained/eliminated
quickly?
Extenuating circumstances?
Notification required or desired?
Continue investigation or stop here?
Network Forensics & Incident
Response
98
Step 3a: Incident/Crime Scene Protocols
Secure the Scene
Electronic evidence is fragile and easily
changed
Keep scene from changing on purpose or
accidentally
Technical Working Group for Electronic Crime
Scene Investigation Guide for First
Responders:
www.ncjrs.org/pdffiles1/nij/187736.pdf
Network Forensics & Incident
Response
99
Step 3b: Incident/Crime Scene Protocols
Document the Scene
Retain and document
the state of the
scene – need a
standard,
documented
protocol
Network Forensics & Incident
Response
100
Step 4 - Identification or Seizure
Electronic Evidence
Recognition and identification of the evidence.
Documentation of the crime scene.
Collection and preservation of the evidence.
Packaging and transportation of the evidence.
Network Forensics & Incident
Response
101
Ways in Which Electronic Devices May be Evidence
"We see criminals use computers in one of
three ways: First, computers are
sometimes targeted for theft or
destruction of their stored data…
Second, computers are used as tools to
facilitate traditional offenses… Third,
computers are used to store evidence."
Janet Reno, U.S. Attorney General, Oct 28, 1996
Network Forensics & Incident
Response
102
Recognizing Electronic Evidence – User Created Files
Address books
E-mail files
Audio/video files
Image/graphics files
Calendars
Internet bookmarks
or favorites
Database files
Spreadsheet files
Documents or text
files
Network Forensics & Incident
Response
103
Recognizing Electronic Evidence –
Computer Created Files
Backup files
Log files
Configuration files
Printer spool files
Cookies
Swap files
Hidden files
System files
History files
Temporary files
Network Forensics & Incident
Response
104
Recognizing Electronic Evidence –
Other Evidentiary Artifacts
Bad clusters
Computer date, time,
and password
Deleted files
Free space
Hidden partitions
Lost clusters
Metadata
Other partitions
Reserved areas
Slack space
Software registration
information
System areas
Unallocated space
Network Forensics & Incident
Response
105
Recognizing Electronic Evidence –
PDAs, E-Organizers, Mobile Phones
Address book
Calendars
Appointment info
Documents
E-mail
Handwriting
Passwords
Phone book
Text messages
Voice messages
Network Forensics & Incident
Response
106
Recognizing Electronic Evidence –
Printers, Scanners, FAXes and Copiers
“tool marks”
Buffers
Network Ids
Usage log
Proof of capability
Network Forensics & Incident
Response
107
Recognizing Electronic Evidence –
Components
Network cards
MAC address
CPU
CPU serial number on
newer Intel chips
Cables and connectors
Missing device?
Network Forensics & Incident
Response
108
Recognizing Electronic Evidence –
Other Devices to be Concerned With
Smart Cards
Dongles
Answering Mach.
Caller ID info
Deleted Messages
Last number called
Phone numbers &
names
Tapes
Digital Cameras
Images
Removable cartridges
Sound
Time and date stamp
Video
Memory Cards
Network Forensics & Incident
Response
109
Search for Evidence
Locard's Principle of Exchange when any two objects come into
contact, there is always
transference of material from
each object onto the other
What are you adding to the scene?
Network Forensics & Incident
Response
110
More Seizure and Identification
Can’t seize everything
– make informed, reasoned decisions
about what to seize
– normally guided by search warrant
Document everything
Chain of custody
Authenticity
Later identification
Network Forensics & Incident
Response
111
Seizure - 1
Identify and remove all persons from the area –
document their location at the time of entry – do
not let anyone touch anything!
Interview (if possible) owners/users of electronic
devices – try to get
passwords and user names
documentation
network topography
encryption keys
location of offsite storage
Network Forensics & Incident
Response
112
Seizure - 2
Formulate a systematic search plan
Document physical scene (power status,
location of mouse, keyboard, monitor,
etc.) – look for stickies!
Photograph scene to create visual record
Photograph monitor screen – may require
videotaping
Note peripherals and devices can contain
latent prints – wear gloves!
Network Forensics & Incident
Response
113
Seizure - 3
Do not alter the condition of an
electronic device – if it is off, leave it
off!
Identify cables (phone lines, network
lines, printers, etc.) - document, label
and disconnect each cable from the
wall if possible
You need to make a decision about
volatile data (RAM, cache, etc.)
Network Forensics & Incident
Response
114
Seizure - 4
Transport hardware to evidence storage
facility – or alternatively, do forensic
analysis on site
Keep computer components away from
magnetic items – radio modem in the
back of a patrol car
Remember batteries can fail – make sure
new ones are inserted as soon as
practical
Network Forensics & Incident
Response
115
Step 5: Preservation
Create an exact duplicate of electronic
storage devices and keep the original
safely stored
Will have to provide copy of all exhibits
to defense for examination
Work on duplicate in case your
examination damages the contents
What does it mean to have an “exact
duplicate”?
Network Forensics & Incident
Response
116
Step 6: Recovery
Extract deleted and encrypted files
Recover all unavailable data whether or
not it is related to the case – usually
not done manually
Especially note what has been deleted
and when
Network Forensics & Incident
Response
117
Step 7: Harvesting
Organize the contents of the storage device
Gather metadata
Catalog what you have
Applications, data, images, documents, etc.
Network Forensics & Incident
Response
118
Step 8: Reduction
Separate good from bad - Eliminate objects
that are not related to the investigation
Commercial clipart, standard operating system
DLLs, computer games, etc.
Smallest set of digital information with
highest value for proving allegations
Beware of deleting exculpatory data!
NIST National Software Reference Library
www.itl.nist.gov/div897/docs/nsrl.html
Network Forensics & Incident
Response
119
Step 9: Organization and Search
Physically organize the reduced set
Make sure every file is indexed so it can be
found on the original hard drive
Inverted links are helpful
Network Forensics & Incident
Response
120
Step 10: Analysis
Review file contents within the context of the
assertions to be proven
Try to refute the assertions as well – look for
exculpatory evidence
Validate your findings
Network Forensics & Incident
Response
121
Step 11: Reporting
A detailed record of:
what you found
how you found it
where it can be found on the original disk
significance of what you found
Network Forensics & Incident
Response
122
Step 12: Persuasion & Testifying
Present your findings to the triers-of-fact
Convey technical issues to laypeople in a
clear manner
Network Forensics & Incident
Response
123