Impact of Digital Forensics Training on Computer Incident Response Techniques Valorie J. King, PhD Collegiate Associate Professor University of Maryland University College Presentation to AFCEA June 25, 2014
Introduction Valorie J. King, PhD Email: valorie.king@faculty.umuc.edu Cybersecurity / Information Assurance Program at UMUC Course Chair Cybersecurity Courses Digital Forensics Courses
Synopsis This scenario driven case will start with a review of the handling of an actual computer incident for a mission critical system that had a required Mean Time To Restart of five minutes. The presenter will then conduct a walk through of incident response techniques using digital forensics methods and tools for a similar but hypothetical incident. Throughout the demonstration, the presenter will highlight critical points where an incident responder s actions could adversely impact the identification, extraction, preservation, and interpretation of digital information during a computer incident response investigation.
The System Secure Environment / Classified Mission Real-time Operating System Custom Software w/ OS modifications Hot Swap Computers (A & B) Operator Console Disk Farm (300 MB per hard drive) High Speed Custom Processing Hardware Installed in computer back plane
The Incident Actually, a series of incidents having increasing frequency over a 12 month period My involvement Began approximately 6 months after first incident Onsite Support Engineer (Software) Initial tasking write SW to recover data from hard disk(s) after system crash Impossible to complete due to software architecture (register pointer to linked list overwritten by HW interrupt vector)
The Investigation Phase I Read Custom Software (Code & Design Documents) Analyze Memory Dump Tapes Search for evidence of causation Phase II (permission was very hard to get!) Analyze Operator and Maintenance Documentation Observe Operations from OPS Floor Phase III Implemented new Incident Response Procedures Analyze Operator Captured Register Values & PC
Incident Response Procedure New Incident Response Procedure Written by SW Engineer Operations resisted additional record keeping requirements Additional Information in Operator Log Reports Date/Time of HW Maintenance Date/Time of Incidents + System ID (A or B) Document Control # for Dump Tape Added later: HALT address (PC) & Register Values
Analysis of Incident Reports Patterns / Trends: none found UNTIL operators started recording Register Values at time of halt (obtained through front panel) Eureka Moment: Register Values including PC were static Halt location was inside memory allocated to Hardware Interrupt Driver for operator console Error causing halt: Keyboard input error
The Causes Operator Console ADM-3a terminal device Integrated Display & Keyboard Serial Device Incorrect Error Handling Custom Driver Software SW Engineer coded in a halt instead of ignoring the error
The Culprits Software Engineers Hardware Operators
The Outcome(s) Halt instruction replaced with return from interrupt No attribution / responsibility could be assigned (despite the coder s name being present in the comments for the HALT code). Operators unhappy at blame for food caused hardware failure. Bottom Line: Unhappy customer, Unhappy managers
The What If? What if the halt instruction had been deliberately placed in the code? Forensic Issues Loose configuration control on software Inconsistent recording of site info (operator logs) No chain of custody on dump tapes (evidence) No forensic training for incident responders
What have we learned about Incident Response? FAST FORWARD 30+ YEARS
We do things differently now http://csrc.nist.gov/publications/nistpubs/800-86/sp800-86.pdf
Educating Incident Responders apply rules and guidelines as they pertain to the acquisition, handling, and storage of digital artifacts establish a digital forensic workstation for the purpose of collecting and analyzing data select and apply the most appropriate methodology to extract data based on circumstances and reassemble artifacts from data fragments analyze and interpret data collected and report outcomes in accordance with incident response handling guidelines
Hands-on Project Scenario Key employee resigned unexpectedly (by voicemail) Contract with security incident reporting clauses & requirements Resignation of key personnel is a reportable security incident
Hands-on Project Scenario Initial Investigation Office search turned up one USB Employee s company laptop -- missing Employee s workstation -- missing sent to IT service center earlier in the week to be wiped and reimaged due to infection by a particularly nasty rootkit Phase I: Threshold Assessment of USB Phase II: Full Assessment of files from workstation
Hands-On Incident Response Project Forensic Images provided to students USB from employee s office Windows 7 Workstation Files from IT Service Center s Backup/Restore (USB) User Profile (Folders & Files) Internet Explorer Cache Files Email (saved as text and as eml) Documents Zip Archives User Registry Files
Chain of Custody
Sample Chain of Custody
Forensic Tools Encase Forensic Toolkit FTK FTK Image Password Recovery Toolkit (PRTK) Registry Viewer WinHex (Specialist)
Forensic Tools
Forensic Tools
Basic Analysis Techniques
Basic Analysis Techniques Examine deleted files & folders
Analysis Techniques Indicator that Linux was used to delete folders & files
Analysis Techniques
Contraband Found
User Profile Analysis
Short Cut Files (System Usage)
Short Cut Files (System Usage)
Registry Analysis (System Usage)
Registry Entries = Attribution (?)
Registry Keys hold Internet Usage Information
Registry Keys (Internet Traces)
Registry = When (?)
Keyword Searching (WinHex)
Keyword Search Results
Deeper Analysis
Deeper Analysis
Deeper Analysis
Deeper Analysis
Exporting to Excel for Analysis
WHO DID WHAT TO WHOM?
Presumption of Innocence Attribution is difficult to prove An account login does not establish responsibility Insider Threat External Threat Data can be faked Inconsistencies are important cues / clues
Finding Inconsistencies Anomalies Analysis What should NOT be in the files Meta data for versions / dates that do not fit the timeline Fonts that do not belong Timeline Analysis NTFS Logical Sequence Numbers Files created on HD after last shutdown
SUMMARY
Incident Response Timelines Procedures Methods Personnel Tools
Bottom Line If you do not collect the forensic image at the time of the incident, you will not have reliable and trustworthy data for later analysis and determination of who did what to whom. If you do not have trained personnel with access to appropriate tools, the after-action review will not have the data necessary to make informed decisions and respond appropriately to threats. Presumption of Innocence is not optional.