EvoSec 2025W Lecture 11 - Revision history

Soma at 15:20, 25 February 2025

2025-02-25T15:20:27Z

← Older revision		Revision as of 15:20, 25 February 2025
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

Soma at 17:20, 12 February 2025

2025-02-12T17:20:05Z

← Older revision	Revision as of 17:20, 12 February 2025
Line 1:	Line 1:
		<pre>
		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?
		</pre>

Soma: Blanked the page

2025-02-06T17:58:36Z

Blanked the page

← Older revision		Revision as of 17:58, 6 February 2025
Line 1:		Line 1:
	~~<pre>~~
	~~Lecture 9~~
	~~---------~~

	~~What is entropy? (G1)~~
	~~- least diverse -> least entropy~~

	~~So maybe increasing entropy (disorder) would increase security?~~
	~~- multiple kinds of software, hosts, etc~~

	~~But that seems chaotic and thus insecure?~~

	~~Entropy on a specific graph~~
	~~- hosts can have some number of vulns~~
	~~- edges represent the vulns a host has~~
	~~- cannot remove all edges by assumption - hosts always have some~~
	~~- increase entropy -> more disorder in edges~~

	~~Adding new kinds of systems => increase the space of vulnerabilities~~
	~~- attack surface goes up!~~

	~~If diversity is the answer, what is the question?~~
	~~- consider for Thursday~~
	~~</pre>~~

Soma: Created page with "

 Lecture 9 ---------  What is entropy? (G1)  - least diverse -> least entropy  So maybe increasing entropy (disorder) would increase security?  - multiple kinds of software, hosts, etc  But that seems chaotic and thus insecure?  Entropy on a specific graph  - hosts can have some number of vulns  - edges represent the vulns a host has  - cannot remove all edges by assumption - hosts always have some  - increase entropy -> more disorder in edges  Adding new kinds of s..."

2025-02-06T17:58:14Z

Created page with "<pre> Lecture 9 --------- What is entropy? (G1) - least diverse -> least entropy So maybe increasing entropy (disorder) would increase security? - multiple kinds of software, hosts, etc But that seems chaotic and thus insecure? Entropy on a specific graph - hosts can have some number of vulns - edges represent the vulns a host has - cannot remove all edges by assumption - hosts always have some - increase entropy -> more disorder in edges Adding new kinds of s..."

New page

<pre>
Lecture 9
---------

What is entropy? (G1)
- least diverse -> least entropy

So maybe increasing entropy (disorder) would increase security?
- multiple kinds of software, hosts, etc

But that seems chaotic and thus insecure?

Entropy on a specific graph
- hosts can have some number of vulns
- edges represent the vulns a host has
- cannot remove all edges by assumption - hosts always have some
- increase entropy -> more disorder in edges

Adding new kinds of systems => increase the space of vulnerabilities
- attack surface goes up!

If diversity is the answer, what is the question?
- consider for Thursday
</pre>