Every interaction is a product of the protected agent and some other agent, yes? Every potential interaction represented by an edge – attack surface an isolating graph cut in this graph? Either way, the graph view is just a first bid for something geometric-flavored.
-
-
Replying to @michiexile @mathpunk and
Yah. I'm trying to work out how you characterise "interaction that shouldn't have happened, but did."
1 reply 0 retweets 2 likes -
Replying to @maradydd @michiexile and
The attack surface is a subset of the "possible interaction surface" which also contains the "acceptable interaction surface". In the graph framework they are all cuts. When adding features the graph becomes more dense; what can be said about |AS|/|PIS| and |AIS|/|PIS| growth?
3 replies 0 retweets 4 likes -
Replying to @anderssandberg @maradydd and
I think
@anderssandberg captures one of the things me and@maradydd were bouncing on here: I'm talking about an abstract graph of «all possible interactions», not just «all foreseen interactions»… Not practical in terms of defense, but maybe in terms of first definitions?1 reply 0 retweets 1 like -
Replying to @michiexile @anderssandberg and
I'm just going to be a broken record and point out that if you have a grammar of the language in which agents communicate, and a state machine characterising state transitions on accepted messages, there's your acceptable interaction surface cut (some assembly required)
3 replies 0 retweets 2 likes -
Replying to @maradydd @michiexile and
or multiple state machines, I suppose that works too I suppose it's also time to fire up the
@perrymetzger signal1 reply 0 retweets 1 like -
Replying to @maradydd @michiexile and
There may be ways to characterize the notion of attack surface more formally, but I'm pretty distracted currently by questions of how to defend better. That said, the question of what we've meant by "attack surface" all this time is interesting.
1 reply 0 retweets 0 likes -
Replying to @perrymetzger @michiexile and
It's the very thing we're defending, isn't it?
1 reply 0 retweets 0 likes -
Replying to @maradydd @perrymetzger and
There is the very thing we're defending (usually information or a functionality), but there is also the things that if compromised make the VTWD vulnerable. These TTiCMtVCs have their own things that can make them vulnerable. Attack surface: closure of all these things?
1 reply 0 retweets 2 likes -
Replying to @anderssandberg @perrymetzger and
Meanwhile, on a rather smaller scale, looks like some neighbours at Columbia have been enumerating points on the parser differential attack surfaces of SSL/TLS implementations (specifically, *just* hostname verification) http://www.cs.columbia.edu/~suman/docs/hvlearn.pdf …
2 replies 6 retweets 16 likes
oh interesting that reminds me of my idea of doing this to parser generators, which I should probably realize some time
-
-
-
Replying to @edefic @allgebrah and
Ooh. I’m just figuring out Klee, all this stuff is wild.
1 reply 0 retweets 3 likes - 7 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.