Se ha denunciado esta presentación.
Utilizamos tu perfil de LinkedIn y tus datos de actividad para personalizar los anuncios y mostrarte publicidad más relevante. Puedes cambiar tus preferencias de publicidad en cualquier momento.

An academic's view to incident response

228 visualizaciones

Publicado el

A timely reaction to security incidents is without doubts important. And while the techniques of digital forensics can come pretty close to perfect for single-host systems with small hard drive capacity, things can get easily messy with 10+ systems, a mixture of operating systems & mobile devices of various brands, or gigabit network traffic that is partly encrypted.

This talk contains two parts. For one, the do's and don’ts for incident response from a forensic examiner’s point of view. Is it better to pull the plug, or gracefully shut the machine down, how to capture network traffic, and what to do if the machine is still running and you’d like to image the RAM. In particular, I’ll present a few methods how to capture network traffic for small networks that don’t have a dedicated monitoring port available, and what to do with them. Secondly, a list of things that went wrong when reality kicked in and good intentions do more harm than good. This will include the problems of tool dependency for specific tasks, free log aggregation using graylog and why there is no such thing a s a free lunch, GRR and the riddle for the perfect toolchain.
#NetworkSecurity #Science

Publicado en: Ciencias
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

An academic's view to incident response

  1. 1. An academic’s view to incident response Martin Schmiedecker, fr333k
  2. 2. Overview Challenges Do’s and Don’ts What can I do to be prepared? peekaTorrent 2/64
  3. 3. Martin who? $whoami: • Martin Schmiedecker • researcher at SBA Research, Vienna • digital forensics! • online privacy & network security • @Fr333k 3/64
  4. 4. Goals of this talk • introduction to incident response • (past &) current challenges • talk about things that work • also, how things can blow up in your face 4/64
  5. 5. What is Incident Response? Companies fail to detect intrusions: • Ashley Madison • Hacking Team • RSA • Google, Operation Aurora • (Stuxnet) 5/64
  6. 6. What is Incident Response? 6/64
  7. 7. What is Incident Response? Things like: • something happened, no clue what exactly • got an alert from some box • this is weird ... 7/64
  8. 8. What is Incident Response Goals: • react to security-related events • containment, prevention Ideally: • Live forensics under time preassure • move faster than the attacker • remotely, without the need to physically get there 8/64
  9. 9. What is Incident Response Goals: • react to security-related events • containment, prevention Ideally: • Live forensics under time preassure • move faster than the attacker • remotely, without the need to physically get there 8/64
  10. 10. What is Incident Response 9/64
  11. 11. Context of Academia
  12. 12. Academia 10/64
  13. 13. Academia 11/64
  14. 14. Academia Science vs. engineering: • reviewers in tough position • where does one start, the other stop? • is scientificly published engineering a thing? 12/64
  15. 15. Academia Question the security narratives: • evidence-based1 science? • plenty of FUD! • fast field! but: • creativity! • independence! 1 See also Hanno’s excellent talk on this topic at 33c3 13/64
  16. 16. Academia Question the security narratives: • evidence-based1 science? • plenty of FUD! • fast field! but: • creativity! • independence! 1 See also Hanno’s excellent talk on this topic at 33c3 13/64
  17. 17. Academia 14/64
  18. 18. Academia Standards and references: • RFC 3227: Guidelines for Evidence Collection and Archiving • NIST SP 800-86: Guide to Integrating Forensic Techniques into Incident Response • things like “Order of Volatilty’, write blocker, ... 15/64
  19. 19. Challenges
  20. 20. Challenges 16/64
  21. 21. Challenges Paper from 2010 by Simson Garfinkel: • “Golden Age of Digital Forensics” ended • has been: rather simple challenges • RAM, networks possible • focus on office and multimedia files 17/64
  22. 22. Challenges Observed upcoming issues: • flash storage • lack of time (== storage sizes) • cloud • encryption • multiple devices • broader diversity 18/64
  23. 23. Challenges Still a problem: • storage capacity! • hash, copy, hash & hash • $$$: special hardware for that • takes ages • esp. on slow interfaces 19/64
  24. 24. Challenges 20/64
  25. 25. Challenges Engineering efforts: • data de-duplication (NSRL RDS) • identify file fragments, 2015 [1] • “sifting collectors”, 2015 [2] • specific access optimizations, 2016 [3] 21/64
  26. 26. Challenges Is not inspecting everything really an option? • probably not! 22/64
  27. 27. Challenges Encryption: • “Properly implemented strong crypto systems are one of the few things that you can rely on.” • usage is increasing • both on devices and on the wire 23/64
  28. 28. Challenges Still: • can be bypassed • can be fingerprintied • also, traffic analysis2 2 Recent Cisco Whitepaper on “Encrypted Traffic Analysis” 24/64
  29. 29. Challenges Heterogeneity: • long tail is problematic • rest is for the commercial world 25/64
  30. 30. Challenges Cloud Forensics is a lie! 26/64
  31. 31. Challenges Cloud Forensics is either: • remote access for IaaS, or • funky, non-publicly described API for SaaS But: • both usable • APIs need fidelling • commercial tools available 27/64
  32. 32. Challenges Cloud Forensics is either: • remote access for IaaS, or • funky, non-publicly described API for SaaS But: • both usable • APIs need fidelling • commercial tools available 27/64
  33. 33. Challenges GDPR: • May 2018! • will be interesting! • valid consent, right of erasure & access, ... • in particular for larger companies 28/64
  34. 34. Do’s and Don’ts
  35. 35. Incident Response 29/64
  36. 36. Incident Response 30/64
  37. 37. Incident Response Why RAM? • RAM has all the juicy stuff • processes, network connections, ... • non-reproducible! • volatility is great! 31/64
  38. 38. Incident Response Afterwards: • inspect machine • e.g. Sysinternal Tools • however, your milage may vary • avoid file writes! 32/64
  39. 39. Incident Response 33/64
  40. 40. Incident Response 34/64
  41. 41. Incident Response 35/64
  42. 42. Incident Response Best-case: • one machine • no lateral movement • contained in time 36/64
  43. 43. Incident Response Reality is different! • 1TB of RAM? • entire networks? VLANs? • 10G+ network links? • terabytes of storage? 37/64
  44. 44. Incident Response How to get a RAM image: • Windows: FTK Imager, WinPmem, Redline, Deft Linux, ... • Linux: LiME • Mac OS: OSXPmem • all above: Rekall (GRR) • Android: LiME (adb) • iOS: WTF? 38/64
  45. 45. 39/64
  46. 46. What can I do to be prepared?
  47. 47. 40/64
  48. 48. 41/64
  49. 49. Logging Logs help tremendously! • both network and operation system • log remotely & aggregate! • even netflow information can help • still somewhat tedious 42/64
  50. 50. Logging Network: • funky hardware can do mirroring • doable on a budget, too • store as pcap or pipe into Security Onion • use stenographer from Google for 10+G 43/64
  51. 51. 44/64
  52. 52. 45/64
  53. 53. Logging Details matter: • where to place the tap? • trunks? external towards the modem? • trying to find a balance ... 46/64
  54. 54. Logging System logs: • ELK stack: Logstash, Kibana • graylog • OSSEC • Windows Event Collector • Splunk • ... 47/64
  55. 55. 48/64
  56. 56. Remote Remote: • physical access not always possible Google GRR: • built for incident response! • simple questions: PowerShell? Linux Subsystem? 49/64
  57. 57. Remote GRR deployment: • most logic is server-side • server generates executables with config • client simply runs it, done • easy with Puppet or others • offline clients run tasks asap when online 50/64
  58. 58. Remote GRR Pros: • web GUI • scales very well • allegedly large setups with 100,000+ client machines • configuration & roll-out easy • long-term supported project Cons: • privacy and legal implications 51/64
  59. 59. Remote GRR Pros: • web GUI • scales very well • allegedly large setups with 100,000+ client machines • configuration & roll-out easy • long-term supported project Cons: • privacy and legal implications 51/64
  60. 60. Remote GRR RAM capabilities: • remote acquisition of RAM • use volatility on live RAM • = really, really cool! 52/64
  61. 61. Remote flow: • basic work unit in GRR, asynchronous • used for client data acquisition • can use e.g. OS API, or Sleuth Kit for file access • written in Python, stored on server 53/64
  62. 62. Remote Hunting: • run flows on entire or partial fleets • also on offline machines, once back • or any subset e.g., all machines running Windows • scaleable! • clients check for new flows every 10 mins 54/64
  63. 63. peekaTorrent
  64. 64. peekaTorrent General idea: • identify file(-fragments) of no interest • leverage publicly shared hash values • more granular than files, but less than sectors 55/64
  65. 65. Soooo much Data We’d like to ignore: 56/64
  66. 66. peekaTorrent Our approach: • it’s all in the .torrent • copyright-free! • torrent it, check it, done! • toolchain: bulk extrator & hashdb • published last year at DFRWS 2016 [4] 57/64
  67. 67. peekaTorrent 58/64
  68. 68. peekaTorrent BitTorrent uses chunking: • all files are concatenated • then split in chunks (=pieces) • most often 256kb, (observed 16kb-16mb) • depending on implementation and user preference 59/64
  69. 69. peekaTorrent Benefits: • find deleted & even partially overwritten files • fast! Really fast! • less false-positives • hashdb files can be easily shared 60/64
  70. 70. peekaTorrent Collected data, 1/2: • in total: 2.65 million torrent files • crawling Piratebay & KAT • multiple data dumps • 3.3 billion unique chunk hashes • up to 2.6 PB of data 61/64
  71. 71. peekaTorrent Collected data, 2/2: • in total: 4.68 million torrent files • using 2 months of DHT crawling • really efficient • 4.5 billion unique chunk hashes • up to 6.5 PB of data 62/64
  72. 72. Sharing is Caring 63/64
  73. 73. Thx for the attention!
  74. 74. Questions? 64/64
  75. 75. [1] Simson L Garfinkel and Michael McCarrin. Hash-based carving: Searching media for complete files and file fragments with sector hashing and hashdb. Digital Investigation, 14:S95–S105, 2015. [2] Jonathan Grier and Golden G Richard. Rapid forensic imaging of large disks with sifting collectors. Digital Investigation, 14:S34–S44, 2015. [3] M Guido, J Buttner, and J Grover. Rapid differential forensic imaging of mobile devices. Digital Investigation, 18:S46–S54, 2016. [4] Edgar Weippl Sebastian Neuner, Martin Schmiedecker. Peekatorrent: Leveraging p2p hash values for digital forensics. 64/64
  76. 76. Digital Investigations, 18(7):149–156, 2016. 64/64

×