Impact of Digital Forensics Training on Computer Incident Response Techniques

Transcription

1 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

2 Introduction Valorie J. King, PhD Cybersecurity / Information Assurance Program at UMUC Course Chair Cybersecurity Courses Digital Forensics Courses

3 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.

4 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

5 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)

6 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

7 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

8 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

9 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

10 The Culprits Software Engineers Hardware Operators

11 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

12 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

13 What have we learned about Incident Response? FAST FORWARD 30+ YEARS

14 We do things differently now

15 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

16 Hands-on Project Scenario Key employee resigned unexpectedly (by voic ) Contract with security incident reporting clauses & requirements Resignation of key personnel is a reportable security incident

17 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

18 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 (saved as text and as eml) Documents Zip Archives User Registry Files

19 Chain of Custody

20 Sample Chain of Custody

21 Forensic Tools Encase Forensic Toolkit FTK FTK Image Password Recovery Toolkit (PRTK) Registry Viewer WinHex (Specialist)

22 Forensic Tools

23 Forensic Tools

24 Basic Analysis Techniques

25 Basic Analysis Techniques Examine deleted files & folders

26 Analysis Techniques Indicator that Linux was used to delete folders & files

27 Analysis Techniques

28 Contraband Found

29 User Profile Analysis

30 Short Cut Files (System Usage)

31 Short Cut Files (System Usage)

32 Registry Analysis (System Usage)

33 Registry Entries = Attribution (?)

34 Registry Keys hold Internet Usage Information

35 Registry Keys (Internet Traces)

36 Registry = When (?)

37 Keyword Searching (WinHex)

38 Keyword Search Results

39 Deeper Analysis

40 Deeper Analysis

41 Deeper Analysis

42 Deeper Analysis

43 Exporting to Excel for Analysis

44 WHO DID WHAT TO WHOM?

45 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

46 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

47 SUMMARY

48 Incident Response Timelines Procedures Methods Personnel Tools

49 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.