1. 1 Next Generation Kernel Activity Monitoring Edward Balas, Indiana University Michael Davis, Savid Technologies IU Partners in Crime: Camilo Viecco Gregory Travis

2. 2 Agenda  Introduction to Kernel based activity monitoring (Sebek as context)  Performance evaluation  A possible solution  Revaluate performance  Roadmap

3. 3 Kernel based Activity Monitoring Motivation  Goal is to observe activity while minimizing disruptions.  Network data analysis is no longer sufficient Intruders started using session encryption  Desire to study intra-system behavior Process vs User behavior

4. 4 Kernel Activity Monitoring Basics  Basic tasks Observe system call activity Record Data Export Data

5. 5 Kernel Activity Monitoring Basics II  Try to make it hard to detect Fail, Try, Fail… Notice that nobody bothers looking  Implemented as Loadable Module or kernel patch  Lets not call it a Rootkit, but a system enhancement.

6. 6 Sebek as Kernel Activity Monitor  Linux developed by Balas  Win32 developed by Davis  Latest versions collect Keystrokes / read data Process heritage Files opened by a process Sockets opened by a process  GenIII Honeynet design based in part on this type of data.

7. 7 Illustration of Data’s Value

8. 8 Illustration of Data’s value

9. 9 Sebek as Firehose  Sebek defies one of the claimed values of honeynets “They only collect data of value”  Rudimentary of control on what it collects Makes more analysis work Limits use in operations Provides potential for detection

10. 10 Delay imposed by Sebek  Micro RDTSC based, Macro “dd” based  1 bytes Reads from /dev/zero 1,000,000 times  Linux 2.6 Sebek

11. 11 Quantity of “uninteresting” data  Per hour record generation rates: Idle Keystroke only ~5,212 Idle Full Read ~98,000 Slowly surfing porn w/ Full Read ~750,000

12. 12 What is the problem?  Delay could be used as basis for detection Create per CPU profiles determine if test data exceeds delay threshold Generalize distribution and look for deviations in curve shape  Unintended data capture/sensitive data  Data Volume

13. 13 Obvious Solution: don’t record uninteresting  Depending on use case, a prior sense of what is of interest is present Is /dev/zero ever of interest? If we are watching for remote connections, do we care about unrelated local activity  Recall that recent version of Sebek records process tree, sockets and file activity…  Applicable for any Kernel-based Activity Monitoring

14. 14 Filtering approach  Make it feel like firewall filters  Make decisions based on Process name Socket parameters File names User names  Use process tree to make filters dynamic

15. 15 Example: Monitor a remote user  Action=keystrokes user=ebalas sock=(proto=tcp local_port=22) opt=(follow_child_proc ) Keystroke monitor ebalas when he logs in remotely via ssh. Also monitor any processes decendant from the process that serviced the socket.

16. 16 More Examples  action=ignore file=(name=/var strict inc_subdirs) Ignore any activity associated with files in the /var sub directory  action=keystrokes user=bob file(name=/var/sekrit/squirel.txt opt=(follow_child_proc) Silly honeytoken.

17. 17 Okam prototype  Other Kernel Activity Monitor(OKAM)  Based on Sebek  Binary flags are added to inode and process data structure to control if we record.  Tagging occurs when A process forks File is opened Socket activity is observed

18. 18 Filtered Performance  Volume of data at idle reduced dramatically  Performance when not recording similar to stock  Depends on good filter selection for improvement but control is good.

19. 19 Future Direction  Benchmark other monitored system calls  Explore HTB / fair queuing as a way to prevent local process level logging Dos.  Release Okam or integrate into Sebek? Trademarks,Copyright Oh my! Hopefully have something out in May