EvoSec 2025W Lecture 11: Difference between revisions
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
==Discussion Questions== | |||
* What is "sequence-based system call monitoring"? | |||
* How did system-call monitoring "evolve"? Specifically, to what extent did its "fitness" improve? | |||
==Notes== | |||
<pre> | <pre> | ||
Lecture 11 | Lecture 11 |
Latest revision as of 15:20, 25 February 2025
Discussion Questions
- What is "sequence-based system call monitoring"?
- How did system-call monitoring "evolve"? Specifically, to what extent did its "fitness" improve?
Notes
Lecture 11 ---------- For Thursday - I'll set up an assignment for submitting PDFs for slides (1-3 slides at most), this is optional - whatever you present is not binding, you can change it! - this is a participation grade, so it is a grade for effort Questions - where is tech like that described in today's papers being used? - how close is it? - how about, trying to detect attackers when we don't know exactly how they will attack - so, catching novel attacks as well as regular ones Candidates - anomaly-based network monitoring - not common - spam detection - but you have examples of spam and ham (regular msgs) - and still doesn't work great against novel spam - ML applied to malware detection - but that isn't real time and is mostly focused on classifying samples There isn't much! Note that this work is not obscure - the "evolution of system call monitoring" was an invited paper - sense of self received a "test of time" award at IEEE SSP All of you: WHY? - too many false positives - takes too long to create "normal" databases? - mimicry attacks are too easy? - normal can change - cost - graduated responses are not useful in fast computers - logistical difficulty in replacing current systems - lacks scalability - not enough work done to make it commercially viable - not adaptable/robust enough to justify changes - industry cannot sell it - too many false positives, waste of employee time - lacks adaptability, unable to adapt to changes over time - frequency of re-training or learning - experimental environment is complex, situation different for different OSs - local, system specific means it cannot scale/extend to other systems None of the above is true - the basic tech works, and plenty of scope for improvement! But what did the evolution paper say? - different methods for monitoring system calls - but they are all much slower, and almost no gain in accuracy - applied to other systems - but barely followed up on - bit of work on use in real time, automated response - but that's basically my work HUGE amounts of follow-up work, almost no progress Do you disagree? I changed much of my focus to theory because I couldn't understand what was happening What would you like to learn more about? - other systems I've built - limitations of past systems I've built - more alife, evolutionary systems - game theory in security - anomaly detection evasion techniques (mimicry attacks) - how to apply these ideas to crytography? - more bio-inspired systems - practical implementations of adaptive security, why aren't we doing this? - system call monitoring using arguments - defense mechanisms to address evolving threats - human interactions with autonomous security systems - programming language vuln detection - specific attack mechanisms to be addressed - new immune system security research - evolution of cloud security systems - diversity, selection?