[21:45] heyas [22:16] hey [22:16] sorry I'm running late [22:16] Action: Dymaxion calls brenda [22:25] Hi! [22:25] hey [22:25] Sorry about the wait -- I'm having an attack of the fumblefingers [22:26] No problem -- I stayed at work way later than I should have. [22:26] What's our agenda tonight? [22:28] apparently we don't know [22:29] Action: Dymaxion grins. [22:29] i think we are supposed to work on docs [22:29] Well, we still need to .. [22:29] yeah [22:29] but i want to talk about theory [22:29] ok [22:29] we need ara to show up & keep us in line [22:29] i need to go write some docs anyway before I'll have much to talk about [22:30] someone should respond to mike's email too -- I can do it if you want. [22:30] Action: asparagi gets mail so she will know what Dym is talking about [22:31] so, it has come to my attention that Trike has a number of deficiencies [22:31] yes? [22:32] specifically, you have to be able to nail down what the heck it is you are analyzing before it will really work [22:32] now, you will say, of course you have to do that [22:33] but, we are supposed to be all flexible, i.e. start at the beginnning & update as you go [22:33] Action: Dymaxion nods [22:33] i think we are not doing very well on that score [22:33] but that doesn't work right now -- things are very crystaline, and break when things they depend on change [22:33] yeah [22:33] yah [22:33] so. [22:34] i don't know the answer, but can we fix it by friday pretty please? ;) [22:34] I think if we add undo and copy/paste, we'll have the framework to leave snippets of obsoleted stuff laying around, which will go a long way to fixing that -- things go into the trash heap instead of just disappearing. [22:34] Action: Dymaxion grins. [22:34] mmm, yah, that would help [22:35] i think we should think about adding in some explicit fuzz [22:35] e.g. Admin creates Blog Entry when *fuzz here* [22:35] still not perfect; I think some of this is inherent in the structures we're modeling with and may go away a bit as out model becomes more sophisticated [22:35] I like that idea a lot [22:36] or in a DFD.. this part is nailed, then it connects to *fuzz* [22:36] yeah [22:36] that way we could at least cover the parts we know [22:37] so, next failure: hardware assets don't work. [22:37] this is sort of like physical assets don't work [22:37] as we start to get smarter, we may be able to make sets of conjectures about the fuzz -- basically, here are the different things that could be generated, depending on property foo of this fuzz. [22:37] Oh? [22:37] what, exactly, would it mean to create a hardware asset? [22:38] they're kind of all there already. [22:38] well, what does it represent? [22:38] and say you are using pins [22:38] as your assets [22:38] you could say read & update are pretty good, but create and delete are, um, poor [22:39] an entity in the DFD which has business rules about it? [22:39] Action: asparagi imagines someone wielding the great wire cutters in the sky, via the network [22:39] Action: Dymaxion grins. [22:39] Action: Dymaxion cackles. [22:40] not exactly. there's some data stored on the pin [22:40] Yeah -- setting actions to N/A will help with that a little bit [22:40] yeah [22:40] i think we should go straight to v2 [22:40] i think it is our only hope [22:41] hrm. [22:41] there's another area for improvement which i can't describe very well [22:41] give it a shot? [22:41] you know how the stubs are supposed to plunk together to make an overall attack graph? [22:42] we are still somehow confusing steps in an attack with attack chaining [22:42] we should separate them [22:42] yeah, except we sort of shove some handwaving between them to give a pretense of intention falling through [22:42] like what? [22:43] Action: asparagi is fuzzy [22:43] i don't know [22:43] they seem hard to separate [22:44] which do? [22:44] i mean, any AND in the attack tree seems like chaining to me [22:44] sorry, static on the mind meld channel [22:44] how so? [22:45] intention, attack chaining and task breakdown [22:45] those are all in the graph structure, sort of undifferentiated-like [22:45] yeah [22:46] well, if i have to snoop the network AND decrypt the traffic, isn't that chaining those 2 attacks? [22:46] so we need to differentiate the structures that transfer that meaning -- capabilities are what chain, intentions are in the stubs, and tasks are the actual trees [22:46] yeah, I totally get it now. [22:46] i still don't :) [22:46] Action: Dymaxion . o O ( we need a sound effects channel for the mind meld device ) [22:47] It's all about the type of the nodes in the attack graph [22:47] can you go into that structure differentiation thing more? [22:47] we're representing three high level categories of objects in a single graph [22:47] intents, capabilities, and attacks [22:48] capabilities can appear as either "provides #X" or "requires #X" -- both ends of chaining points for attacks, basically. [22:48] the actual attacks are the breakdowns of a specific attack task. [22:48] ugg, sorry guys [22:49] hey! [22:49] I was sitting here waiting and must have fallen asleep :/ [22:49] each of these types of graph node has slightly different semantics as far as what it can do, how it interacts, etc., and not having those pulled out makes things really muddy. [22:49] Hey! [22:49] aww [22:50] we're in the middle of a deeply theoretical discussion about the attack graph -- grab the mind meld device & hang on for a wild ride! [22:50] Action: Dymaxion grins. [22:51] oki, I'll read the backlog and try to keep up :) [22:51] so, yeah. I definitely agree that that needs to change too. [22:52] so, Paul, i don't see how would know what data to put in which kind of node, or what the structure would look like [22:52] e.g. intents sounds like attack goal [22:52] er? [22:52] "see how would" [22:52] why wouldn't that be a capability? [22:52] missing I [22:52] ah [22:52] "see how I would" [22:52] yeah [22:52] hrm. [22:52] I and space are right next to each other on my keyboard [22:52] like everything else [22:53] I guess I have a gut feeling about it, but I'm not sure how to convey that [22:53] Action: Dymaxion nods. [22:53] especially x and lf [22:54] So, capabilities represent specific technical things; they exist only in the DFD domain [22:54] hmm [22:55] do they have to involve DFD elements? [22:55] attacks are things which sometimes could be represented as capabilities, or are sometimes really inseperable parts of getting a single capability; there's a bit of "how much do we want to model" fuzz there, I think [22:55] or portions of DFD elements, actions on them, things like that. [22:56] "the ability to take some action within the domain of the implementation" [22:57] e.g. i was thinking that paper somebody sent me which did attack chaining for escalation of privilege on windows myriad privilege thingummies could plug right in, with each of those privileges being a capability in our model [22:57] maybe i didn't tell anyone else about that paper yet [22:57] it was cool [22:58] so, it seems like one possibility is that we get rid of the attacks entirely & call it all capabilities [22:58] do we still need the attacks? [22:58] yeah, I read it [22:59] hrm [22:59] I think so [22:59] attacks represent (if nothing else) the steps to exercise a capability [22:59] there will always be some steps there. [22:59] And probably multiple ways of exercising any capability [23:00] oooh [23:00] There's something else in there, too -- we have high level intents and various lower level intents, but there's glue between them [23:00] dunno what you call that [23:00] are you saying "here's capability A, here's capability B, attacks are how you use them to get capability C"? [23:01] yes [23:01] in that case, capabilities could be nodes in the graph, and attacks could be edges [23:01] or maybe edge traversal algorithms/mechanisms [23:01] you'll have little attack treelets with required capabilities as their children and yielded capabilities as their parents [23:02] there's a couple of levels of graphs [23:02] if you look at the capability graph, each edge is an attack tree, not just a single edge [23:02] what's in the tree? [23:03] i think i want to argue that ORs are different edges [23:03] the ways of traversing from a to b [23:03] yeah [23:03] and ANDs should be achieved by chaining [23:03] leaving us with no attack tree, just an attack [23:03] hrm [23:04] what about multi-step attacks? [23:04] well, the question is, why is it mult-step? [23:04] does it mean we missed a capability? [23:05] I think what your suggesting will lead to too many capabilites; we want to be able to represent fairly complex attaks without needing a lot of noise caps that are just intermediate steps [23:05] presumably you have something after step 1 that makes it possible to go onto step 2 [23:05] I don't think that missing a capability is necessarily a bad thing [23:05] YEAH [23:05] er, yeah [23:05] i think we need an enormous library of attack graphs so we can look at it for examples [23:06] hrm [23:06] I wonder who has one [23:06] or so i can put it in my report on friday :) [23:06] so then we should come up with a way of generating them? [23:06] yah. [23:06] to use as test cases [23:06] oh yet [23:06] er, oh yes [23:07] yah, i think if we had a big set of test data we could more easily figure out where we are falling down in general [23:07] hmhmhm...I wonder if work would mind if I threat modelled my projects? [23:07] :P that would give us 19 graphs [23:07] somehow i doubt they would [23:07] Action: Dymaxion nods [23:07] but they would mind if you gave the data to Us [23:07] yeah, exactly [23:08] i think you should do a few anyway, because then you can tell us what 4th thing we have mixed into the mud in our attack graph [23:08] hehe :) [23:09] ok, so Dym, go back to the part with intent. [23:09] actually, I bet I could put together 30 or so, if I did projects I've completed + the ones in my queue [23:09] Action: Dymaxion grins [23:09] So, we have high level intents, known as threats [23:09] unless you are, as i suspect, looking for the motherlode of attack graph data [23:10] We think we have a handle on lower level intents, the goals for each specific element [23:10] (yeah, I'm doing that too... no luck yet. :-) ) [23:10] well, i thought those were capabilities [23:10] http://www.cs.cmu.edu/afs/cs/project/calder/www/sp02.html [23:11] http://www.cs.cmu.edu/afs/cs/project/calder/www/tr02-109.html [23:11] that should go straight into the bibliography [23:12] well, i'm gonna read them first, but yeah [23:12] no, stick them in first [23:13] then make notes after you've read them [23:13] so, no; I'm distinguishing between capabilities, which are things that you can perform in the implementation, and intents, things which you'd like to accomplish as an attacker [23:13] ok [23:13] maybe we should draft those people, too, if the papers are as good as their abstracts [23:14] Action: Dymaxion grins [23:14] Dymaxion: that sounds like a good differentiation [23:14] not all capabilities of an app will be a threat [23:14] but certain capabilities could combine to become one [23:15] here we get back to ye olde philosophy. why do we care what an attacker wants? we are defense. we care only what will hurt us. if attackers want to dance around throwing punches at thin air, what do we care? [23:16] sorry, let me rephrase that [23:16] intents are things we'd like to prevent [23:16] high level intents are threats [23:16] asparagi: from a management pov, if I can give a tool to my business peoples and they can do some entry as to what they're app _does_ then the business is better off [23:16] that that's documented [23:16] low level ones are specific ways rules, states, DFD elements, etc., can fail [23:16] and then from there, you can look at the capabilities and determine what _is_ threatening [23:17] otherwise you might miss things [23:18] ara: i agree, i think that is taking a defensive position [23:18] dym: ok, that rephrase helped [23:18] :D then I'm confused [23:18] I thought I was agreeing w/ dym and you disagreed [23:18] but then you agreed with me! [23:18] papers added [23:19] Action: ar4chne tries to find the mind meld device and pokes herself in the eye looking [23:19] ow! [23:19] aww [23:19] well, after i understood what dym was saying i agreed with dym too :) [23:19] gotcha ;) [23:19] Action: Dymaxion replaces the mindmeld device with a nerf version [23:19] Action: asparagi laughs [23:19] Action: ar4chne giggles [23:19] mind meld for dummies (tm) [23:20] careful, I may have to actually make one. :-) [23:20] i want to repeat back the idea i think dym is talking about, to confirm i get it [23:21] intents are the roots of attack trees (no graph) [23:22] yes [23:22] an attack tree is an edge in the capability graph, with a certain set of required & resulting capabilities [23:22] there is deliberate fuzz in attack trees, so that we don't have to get as formal as capabilities when we model [23:23] i'm done. [23:23] yes [23:23] did i miss anything? [23:23] yes [23:24] intents and form higher level trees; capability graphs and attack trees plug into those as you get lower down. [23:25] hmm. i think i agree with you, but i don't like ih [23:26] it's ugly [23:26] we need to figure out what is and what it means; it might get less ugly then. [23:26] it seems like this is the definitional use of attack trees. i.e. "this is the definition of DoS" [23:27] i think intent-glue is definition (of that intent) [23:27] Then again, I think out intentions will get finer grained with business rules, so there well be much much less need for intent-glue -- I think 2.0 might solve this problem. [23:27] yes [23:27] ahhhh [23:27] so, about 2.0. [23:28] are we ready for that yet? ;) [23:28] yeah [23:28] Ok, so, I'd like to get one more feature into 1.o before we ditch it, at least. [23:28] Namely, XML import. [23:29] We need to get the DFD library working at some point anyway, and I think it won't take too much time past that to make that work. [23:29] that seems reasonable [23:29] That'll give us a much more credible 1.0 to have sitting out there lonely while we work on 2.0 for however long. [23:29] http://csdl2.computer.org/persagen/DLAbsToc.jsp?resourcePath=/dl/proceedings/&toc=comp/proceedings/vizsec/2005/2782/00/2782toc.xml&DOI=10.1109/VIZSEC.2005.14 [23:29] and yes, it is a no-op after the XSD thing works to do output [23:30] wow, what nice mail from Mike! [23:30] i mean, he used it & it more-or-less worked & stuff [23:30] yeah -- I've been meaning to respond, haven't had time [23:30] yup [23:30] i blame you guys [23:30] Action: Dymaxion grins. [23:30] i was just going to dink around writing exploratory code forever [23:31] and never release it at al [23:31] er, all [23:31] http://doi.ieeecomputersociety.org/10.1109/CSFW.2002.1021806 [23:31] http://doi.ieeecomputersociety.org/10.1109/ITCC.2004.1286496 [23:33] Action: asparagi feels lost [23:34] http://www.cs.nott.ac.uk/~gxt/ # specifically the section on situation calculus at the end [23:34] sorry, just google trolling on attack graphs [23:34] I'd like to add dd's drop down color change ability to 1.0 as well [23:34] maybe before we do 2.0 we should go read a bunch of papers [23:34] the clicking really does suck [23:34] ar: yeah [23:34] ar: and it's fast [23:34] i still don't like that mechanism [23:34] asp: yes [23:35] what about pie menus for that? [23:35] That would work well; I'd be down with it. [23:35] pie menus? [23:35] I think we should leave the details for now, though -- add in a menu so there's something a bit more straightforward and get onto 2.0 [23:35] nooo! [23:35] ;) [23:36] Action: Dymaxion grins [23:36] ar: http://www.piemenus.com/ [23:36] let us not slip further towards standard, evil interfaces [23:36] our current position is bad enough [23:36] how is a menu of colors a standard, evil interface? [23:36] it's logical [23:36] i think the compromises we have made so far are pretty good [23:37] I think we should fix it for 2.0 if we still have a that sort of interface [23:37] it requires much more aiming [23:37] and is therefore slower [23:37] hmm [23:37] do you think we could make all the menus everywhere go away for 2.0? [23:38] :/ you don't think having a menu system out of a game is going to make us seem a bit cartoonish? [23:38] i think we are a bit cartoonish already [23:38] and the pie menu's in the sims were annoying at times [23:38] a good pie menu system is actually really easy to use [23:38] the idea didn't start with gaming, ppl are just more accepting of new ui in games [23:39] alias wavefront uses them everywhere... so do a few other really heavy duty software packages [23:39] the mouse gestures stuff that's become popular is effectively pie menus without the UI [23:40] basically, what i don't like about rectangular menus for the colors is that i feel like i am going to spend a lot of time looking for & attempting to click on some particular item [23:40] anyway, I'd be in favor of one more 1.0 release that fixes up some low hanging fruit bugs and makes things more usable. [23:41] If there are features that we're going to need to write for 2.0 which can be adapted for 1.0 very easily, I'm cool with putting those in there too [23:41] with a pie menu it could be one fluid gesture with a much bigger, more random access space to aim for [23:42] well, at one point we had ideas like: we are going to need DFDs in both systems, so we could do the UI for that & put it in 1 before doing the 2-specific stuff [23:43] Action: asparagi is afraid pie menus drove ara into silence [23:43] I think I sort of still buy that, although I'm worried about spending too much time trying to figure out how to hook DFDs up to stuff in 1.0 [23:44] mmm, with intent-glue? [23:44] hmmm...I think I'd be more interested in getting the functionality there as quick and easy as possible [23:44] Yeah [23:44] Action: asparagi sighs [23:44] and adding more complex ui stuff once things actually sort of work [23:44] you are right, of course [23:44] ...and that's why it's called trike. [23:44] Action: Dymaxion grins. [23:44] but i don't like it... :) [23:45] Action: asparagi snorts [23:45] http://64.233.179.104/search?q=cache:GpJBrzAIY5UJ:csis.gmu.edu/faculty/jajodia-vizsec-2004.pdf+attack+graphs&hl=en&gl=us&ct=clnk&cd=36 [23:46] i want a couple little usability things myself.. [23:47] like what? [23:47] ability to change names of threats [23:47] http://www2.laas.fr/IFIPWG/Workshops&Meetings/44/W1/02-Hollingworth.pdf [Towards Threat, Attack, and Vulnerability Taxonomies] [23:47] N/A and unspecified in the intended actions grid [23:48] after that i want to rip out our old, useless risk model & put in the new one [23:48] so maybe we should chat about what should go into 1.1.3? [23:48] but that's more than a little usability thing :) [23:48] ok. [23:49] i guess we should [23:49] Action: Dymaxion nods [23:49] seems like pretty minimal stuff so far...and if it'll help with our productivity then that would be cool [23:49] yeah [23:49] and then get into the fun stuff :) [23:49] Action: Dymaxion grins. [23:49] :) [23:49] Action: asparagi needs more fun [23:50] Action: ar4chne dances around in a silly hat [23:50] Action: Dymaxion giggles [23:50] better? [23:50] Action: asparagi laughs [23:50] much [23:50] ^^ good [23:50] now if only i had attack graphs for my enormous threat model [23:50] what do you need to gen the attack graphs? [23:51] well, really i need a bunch of stubs and a data model for the DFD [23:51] Action: Dymaxion nods [23:51] too big to do by hand? [23:52] and then i need to punch in some data about the intended actions & the way the DFD implements them [23:52] there are 13 assets [23:52] hehe [23:52] yeah, you lose. [23:52] Action: Dymaxion was dieing with 7x7 [23:52] there are only 3 actors, but it turns out they matter less [23:53] in terms of attack graph complexity [23:53] Action: Dymaxion nods [23:53] yeah [23:53] hmmm...it's 10 [23:53] so i might have a data model for the dfd [23:53] (not to be a wet blanket) [23:53] rules complexity is also a huge ballon factor, when you get there [23:53] but i never tested it [23:53] but you were so tired earlier aspa [23:53] do you need to go to sleep? [23:54] yes, but i have to put this report out on friday, so i'm not going to [23:54] I think we can probably come up with a 1.1.3 list via email [23:54] attack graphs are always better when you invent them when you're really tired [23:54] ;) [23:54] hrm...you'll think a lot better once you rest [23:54] Action: Dymaxion grins. [23:54] ;P [23:54] alright, well, I'm going to crash anyway [23:55] ok [23:55] Shall I start a 1.1.3 wishlist on email? [23:55] good night! [23:55] I don't think I'm contribing a lot [23:55] you go [23:55] and I have an 8am meeting tomorrow :/ [23:55] 'night [23:55] aww [23:55] laters [23:55] this is important.. we are reconfiguring the mind meld device so it works for you too [23:56] it just takes a while [23:56] see you later! [23:56] dym, will you be online for a bit, or are you off to bed as well? [23:56] yeah, I'll be up [23:57] k, i'll hang out here for a bit [23:57] i've been feeling starved for theory/idea-bouncing recently [23:57] Action: Dymaxion nods [23:57] it's hard to get attack graphs generated without it [23:57] yeah [23:57] no good theory partners at work? [23:58] not yet [23:58] everybody's too busy [00:00] --- Thu Feb 23 2006 [00:01] Action: Dymaxion nods [00:01] yeah... I still haven't even found time to give all the guys at work a trike demo [00:16] Ok, I've got a basic start of a 1.2.0 (xml format will change, probably) feature list together [00:17] you go [00:18] you can now change the names of threats. as long as you want them to change to "String Morph". [00:18] lol [00:19] hey, at least no one will be able to tell that sorting by exposure is meaningless [00:19] ;) [00:21] Action: Dymaxion grins. [00:21] So, do we want to touch the risk model for the last 1x release? [00:24] i dunno [00:24] Action: Dymaxion fires it off without that in it [00:24] the right way to do it is to skim response planning [00:24] er? [00:25] well, when calculating the response cost, you want to know which line items contribute [00:26] because then when threat A immediately leads to threats B & C, you only count cleanup action 1 once, even though it is required for both B & C according to your incident response plan [00:26] so you need an interface for that [00:26] Action: Dymaxion nods [00:27] i fixed the naming bug [00:29] yay! [00:30] That sounds like that's going to be a pretty heavyweight change. [00:30] yes, i think fixing the risk model will be pretty heavyweight [00:31] Given that the set of types of contributing line items is likely to change violently, I vote we hold off on that; it's heavyweight new functionality which won't port well. [00:31] yah [00:31] well, actually i think it will port well [00:31] but the interface probably won't [00:31] just the data model [00:31] hrm [00:31] ok [00:32] how hard will it be to put a quick and dirty UI on it? [00:32] If the data model will port, I'm much more willing to consider it, you know? [00:32] i don't know. let's do a quick & dirty data model & then see [00:32] That's the code that I care about [00:32] ok, that sounds reasonable. [00:33] it kind of depends on whether the data model lends itself to easy presentation or not [00:33] i have some notes in my palm pilot [00:33] i might ask toby [00:33] Action: Dymaxion nods [00:33] what he thinks of it as a model [00:34] and maybe a couple other people from work [00:34] yeah, I'd like to hear some feedback from him, as he was pretty critical (for good reason) of our previous risk model. [00:34] So, to go tangential for a second [00:34] Action: asparagi zooms off into the outer reaches of the concept sphere [00:35] It occurs to me that different parties can have different recovery costs; i.e., the risk model for a customer and a merchant for the same system would look very different. [00:35] yes, yes indeedy [00:35] that is a thing i like about the new model [00:35] While I'm not sure that we need to explicitly support having multiple overlapped risk models, it pleases me that our theory is now capable of understanding them. [00:36] In fact, I really really like that idea, and think that we maybe should implement it, even if it's not a high priority [00:36] It shouldn't be too much extra work, and I think it could be really useful some times. [00:36] we always sort of knew the asset value depended on "to whom", now we express it well [00:37] I like things that encourage risk analysis for the risk footprint to people other than $MegaCorp [00:41] well, one way to implement it might be to put the risk stuff in a separate file [00:42] i.e. here's the threat model, here's your risk model [00:42] I don't think we want to do that because then you run into versioning issues [00:42]