[21:28] 'lo [21:32] Action: ar4chne waves [21:32] heya! [21:32] well, i guess i'm 4:22 late [21:33] do we have a Dym? [21:33] haven't seen him yet [21:34] well, e better show up & grab the mind meld device -- it's going to be a wild ride tonight [21:34] so, are we supposed to be doing v1 or v2 tonight? [21:34] no idea ^^ [21:35] well, you know i always want to do v2. you are our voice of reason :) [21:35] haha, I think that works [21:36] so, i believe that i broke attack graphs six ways to sunday. [21:37] oh? [21:37] yah [21:38] the problem is, they were never a very efficient way to generate the lower-level stuff, just all these layers of cruft in the middle [21:38] and then i applied them to a problem which has requirements at a very high level, and components that are in scope at a very low level [21:39] I'm hre [21:39] here, even [21:39] there is a big gap in the middle, in my problem, which is out of scope. that is inherent in the nature of the problem [21:39] Action: Dymaxion catches up [21:40] so the cruft in the middle, which was useless and annoying to start with, goes through this region of fuzz in the middle and either (a) becomes enormous or (b) causes one to miss things [21:41] i believe that in this kind of problem, possibly in all kinds of problems, an attack graph is not an efficient tool [21:41] Action: Dymaxion nods [21:43] i wanted to go back & look at the irc logs from the other night when we were talking about different kinds of links in the attack graph [21:43] but they aren't up [21:44] Action: Dymaxion nods. [21:44] oh, gimme a sec [21:44] is it there now? [21:45] yes. [21:45] yes, is is :) [21:45] ^^ [21:46] ok. so, the capabilities are fine [21:46] task breakdown is not. [21:47] how so? [21:47] well, that's how we have been generating the graphs that have gotten us into trouble [21:47] Action: Dymaxion nods [21:47] i mean, what if a capability transition had to be linear? [21:48] how so? [21:48] and i still don't understand intent, really. i think it might be a red herring. [21:49] well, you start with capability a, and you do steps 1-5 in order, and you end up with capability c [21:49] no ors, no ands [21:49] yeah [21:51] the question is, if we had requirements-level threats, just like we do now, and instead of generating attack stubs hanging off of them, we created a set of sets of capabilities that would directly enable that threat, [21:52] And then we'd have, seperately, sets of steps with some starting and ending sets of capabilities. [21:52] Hrm. [21:52] and then we created a bunch of linear capability transitions based on the implementation, would we be doing as well as we would with a graph, but without all the steps? [21:52] obviously we need a capability inferencer [21:52] yeah, but we knew that [21:52] hrm. [21:53] i'm not sure how it does for dos [21:53] Are steps *only* ever linear? [21:53] we almost need capability removing steps [21:53] It does DoS just as well as it does Elv, I think. [21:53] i dunno, i haven't slept in a long time [21:54] so, how do you know what sets of capabilities implement a threat? [21:54] you look at the implementation [21:54] the threats are still requirements-bashd [21:54] yeah, I get that part [21:54] How do we not miss the weird ass capability over in left field that lets you do something evil? [21:55] (I don't think we handle this well right now either, but) [21:55] but then you take the thing the use flows turned into, and select minimum sets of capabilities that enable the threat. [21:56] Hrm. [21:56] Ok [21:56] e.g. this asset passes over this data flow, so maybe i say to elv read, you must be able to read this network connection [21:56] in some ways it's exactly the same [21:56] that gets us the set of capabilities which directly interact with the threat/action for the treat, which is all we can get now [21:57] and if the capability over in the corner can do something weird, either we get it via chaining, or we didn't model the use flows right and we should have gotten it to start with. [21:57] it's just that you no longer have to spend hours editing the connective tissue in the middle of the attack graph [21:57] ok, I'll buy that. [21:57] yeah [21:57] yup [21:57] So, do we need to capture why a capability enables a threat? [21:57] or we don't understand the atomic capabilities inherent in the implementation [21:58] naw, just ask the engine [21:58] it should be able to spit out any number of chains [21:58] no, I mean a top level capability; one we selected directly from the use flow [21:58] oh [21:59] well, we could certainly do so [21:59] Can we do so in a strong manner? [21:59] ie, something semi-formal? [21:59] Or is it just going to be an annotation? [21:59] i am imagining tracing the dfd to get the use flows, then basically tracing the use flows to get the capabilities [22:00] well, we might be able to automate [22:00] (which isn't necessarily bad, it just may imply different things) [22:00] yeah, that sounds like a good model [22:01] the thing is, we have moved the hard problem to (a) the inferencer and (b) selecting the atomic capabilities [22:01] yeah [22:01] and maybe (c) defining why these capabilities are needed to do this action [22:01] I definitely like the inferencer part; the other two worry me a little bit. [22:01] OTOH, I think I like it overall better than what we have now. [22:02] so, ask me about the capability chain things [22:02] We're going to need a concise definition of why attack trees aren't good enough/don't work -- right now that's the one point of commonality, at least in terminology, that we have with other threat modeling implementations [22:02] (something which does make it suspicious) [22:03] What about them? [22:03] oh right [22:03] they are traces through the use flows! in the flow chart part we talked about last time [22:03] maybe [22:04] i think we might achieve magic if we defined intended actions using the use flows somehow [22:04] need a better word than capability chain -- that describes the high level capability graph to me [22:04] asp: well, we certainly annotate intended actions onto the use flow [22:04] the use flows and capabilities might be closely related [22:05] Action: Dymaxion nods [22:05] steph, are you still hanging on back there? [22:05] yeah; I think use flow requirements are really just capabilities [22:05] yah, i don't know what to call the capability transitions [22:05] yeah, still here [22:06] I was just going to suggest exactly taht [22:06] what do you think? [22:07] Action: asparagi pokes the mind meld device [22:08] the mind meld device jiggles and glows softly [22:09] ok, i know this line of thought goes further, but i am too tired to chase it now [22:09] anybody else have anything? [22:10] so, defining capability transitions is going to be interesting... I think we may want to actually support branching at least as we implement it [22:11] i was sort of thinking they might just need names [22:11] ie; these first three steps don't get you anything on their own, but depending on which step you take next, you get one of four different resulting capability sets [22:11] That too [22:11] hmm [22:11] that could be [22:12] i don't know how that would work [22:12] I'm worried about how we'll figure out what the possible capability transitions for an application are; I guess that comes down to security knowledge and technology-specific libraries, maybe. [22:13] hmm [22:13] well, this last project i did, a bunch ran after me & bit me on the leg [22:13] Well, effectively what you're saying is that if you have the initial required set of capabilities, you can get any of the resulting sets; these may be mutually exclusive or may not be, depending on the set of steps along the way. [22:13] Action: Dymaxion grins. [22:13] Yeah -- I think 95% of them will be easy to find. [22:13] but i guess that doesn't mean they all dir [22:14] That isn't the part I'm worried about. [22:14] ok, so we need a way to tell whether we found all the capabilities [22:14] yeah [22:15] That's a good start [22:15] i think intended actions are capabilities [22:15] did you say that already? [22:15] The capability to perform this action? [22:15] I think that's too high level [22:15] pretty much [22:15] I think that "the capability to enter this use flow" [22:15] might be useful, though [22:15] it would make chaining really really nice [22:16] Maybe intended actions are sets of capabilities... that doesn't bother me. [22:16] hmm [22:17] i think we need to try this approach [22:17] yeah [22:17] unless we can think of some other ways to do away with the attack graph [22:17] this sounds like our best option right now; I think we should try it. [22:17] i don't want to construct, format, or see another attack graph ever again [22:18] Action: Dymaxion grins. [22:18] I'm with you there. [22:18] maybe when i'm 80 they will fill me with nostalgia and i will want to pet them [22:18] hah! [22:18] Action: Dymaxion grins. [22:19] God, I hope by the time I'm 80 I'll have better things to fill me with nostalgia. :-) [22:19] nice attack graph. aren't you fierce! sit! stay! [22:19] lol [22:20] okay. so basically after this project i just did, i think i don't need trike in it's current form at all. it no longer does anything i'm interested in [22:20] Yeah, pretty much. [22:20] i am unlikely to use it, even if we fix the little issues [22:21] but ara wanted to do a 1.2.0a [22:21] I may use it for requirements level work, but not for anything deeper than that; I still find working at that level occasionally useful. [22:21] ara? it's safe to come out now... [22:21] if you guys really think that there's no reason to do another v1, then we shouldn't [22:21] I think a 1.2.0a would not be a bad thing for use to do as a project [22:22] yeah, i guess i might use the grid [22:22] We have a little bit of name recognition, and v2 will be more likely to be adopted/looked at if v1 doesn't disappear completely [22:23] well, one reason to do another v1 is probably to give people an alternative while they wait god knows how long for v2 [22:23] yeah [22:23] that's sort of what I mean [22:23] that was my arguement last week :P [22:23] Action: asparagi sighs [22:24] yah, you are pretty much always right [22:24] Action: asparagi sighs [22:24] Action: Dymaxion grins. [22:24] okay, okay [22:24] haha, sorry aspa [22:24] We'll knock it out quickly -- there isn't too much to do. [22:25] what needs to go in? paul sent out that list [22:25] Action: asparagi goes to get the list [22:26] I think I still stand by that as a good target [22:26] that's a pretty good list [22:26] does it include mike's requests? [22:26] DFD drawing is a little crunchy, so that'll be fun, and that's directly 2.0 relevant [22:26] yes [22:27] let's add rule performance problems [22:27] ok... that would be nice to have [22:27] and i think we should add renaming actions [22:27] and I think a little experience working on performance problems would be good for us in the future [22:27] ok [22:27] on a per-asset basis? [22:28] e.g. "update" -> "set" [22:28] yah [22:28] cool [22:29] what about our open bugs? did they get triaged as part of making this list, too? [22:29] not really [22:29] I did look at them [22:29] (are you taking notes?) [22:29] basically, the bar I care about is that anything which is open now which will still be a problem in 2.0 should get fixed [22:29] ok. then maybe we should take a quick pass at that [22:29] yeah [22:30] yah, that makes sense [22:30] so, about the DFD part [22:30] Beyond that, if it has a really big effect in using the system and isn't on the list, we should definitely look at it. [22:31] some kind of diagram editing would not be bad, for usability & experience [22:31] but are we sure that's the one we want? [22:31] DFDs? [22:31] e.g. maybe we should reopen the UML thing [22:31] Hrm. [22:31] yah.. [22:32] or we could punt, doing no diagrams at all for v1 [22:33] ara? [22:33] I dunno... I'm inclined to go with DFDs right now because a) we have most of a data model, b) it's what we've been talking about as far as the v1 methodology goes, and c) if we don't like it when we get to v2, I don't think the time we've spent getting a drawing system working will be wasted, and that we'll be able to switch it around pretty quickly. [22:33] I think we should revisit that decision for v2, although UML is pretty heavyweight if you aren't using it otherwise [22:34] yes? [22:34] ok, that's fair [22:34] what do you think about 1.2.0 features? [22:35] I think everything sounds fine [22:35] Action: asparagi is shamelessly trying to rope ara into being more opinionated :) [22:35] Action: Dymaxion grins. [22:35] hehe [22:35] I have opinions, it's just I don't feel I'm equipped right now to provide a lot of valid input [22:36] part of me thinks maybe I could work on v1 while you guys work on v2 methodology [22:36] well, you usually turn out to be right [22:36] whoa [22:36] that's a pretty fascinating idea [22:37] like, you guys do v1 stuff that'd roll into v2 [22:37] but I could do bug fixes, etc [22:37] and other things [22:37] like captain integration? :) [22:37] hehe, yeah :P [22:37] well, really inter-operation is what i mean [22:38] yeah, import and export [22:38] That sounds like a really cool idea to me [22:39] it only sounds cool to me if you don't want to get wrapped up in v2 theory. [22:39] honestly, you guys are talking a bit above me [22:39] and I think getting familiar w/ v1 will be helpful to further the mind meld [22:39] if it's just that the mind meld isn't working right yet,... [22:39] hmm, that's true [22:41] so, wanna play triage? [22:41] absolutely [22:41] ar: I hope so... I want you to catch up so you're more comfortable working on the methodology stuff [22:41] http://bugs.octotrike.org/bugs/bugs/ListIssues/sortorder-urgency?Filterlogic=block&saved_filter=&f-statuses=on+hold&f-statuses=rejected&f-statuses=completed&f-fromname=&f-email=&filteroptions=1&ListIssues%3Amethod=Apply+filter+settings&page=ListIssues [22:41] yeah [22:42] yah, i think you will have a bunch of valuable input once you are up to speed [22:42] First two are already included; do we want to do 3? [22:42] oh. yah. it was biting me [22:43] ok [22:44] Next three are all UI issues; are any of them going to survive into v2? [22:44] no. no grid, no trees [22:45] ok; two actors having the same name -- can we just stop that from being allowed? [22:45] It's nasty when you do it, but not worth fixing beyond that. [22:46] i move that we do the same thing as last time & keep the bug tracking system as our list of in features/checklist for release [22:46] yes, we could do that [22:47] file export & maxpath will still be an issue [22:47] Action: Dymaxion nods [22:48] do we want to tackle no good in-place feedback? [22:48] UI feedback is something that will still be a problem in 2, but I think we should wait until then so we know better what we want from it [22:48] k [22:49] 2nd text clause irrelevane [22:49] undo? [22:49] undo is going to be big [22:49] maybe we should just build undo into 2 from the start [22:49] Hrm. [22:49] it feels tentacly [22:49] You may be right... it's going to be a huge change [22:49] oh! [22:49] yeah [22:49] no! [22:50] it's not tentacly [22:50] remember when i broke everything to make the actions work right? [22:51] Action: Dymaxion nods [22:51] i think i made undo much easier. we only want to undo things from the ui, and almost all ui actions flow through one set of classes already [22:51] ok, cool [22:51] so, 1 or 2 [22:51] ? [22:51] Hrm. [22:51] You know, I'm going to say 1, tentatively. [22:51] does the evil empire have it? [22:52] Action: asparagi says, looking for market share [22:52] I think it's going to be big and it will take a while to get right, but I think it would be really nice for v1, and it will be easier to do on a simpler data model [22:52] probably, yeah [22:53] losing manually created information... still a problem in 2 [22:53] possibly related to undo [22:53] yeah [22:53] versioning isn't even on this list, but it's also related [22:53] naw, that would be annoying to use. [22:53] wow, there's a can of worms [22:53] versioning? [22:53] yah [22:55] actually, we won't have data to lose in v2 for a while. [22:55] It's another big feature, probably about the same size as undo [22:56] yeah [22:56] oh, nevermind, we probably will [22:56] we will still generate threats, & the mapping of actions to capabilities might be like that [22:57] yeah [22:57] it should happen less often, though, which is good [22:57] well, let's go on a brief tangent [22:57] (until we get a risk model, but) [22:57] what is v2 going to be like? [22:58] Well, barring other plans, I'm assuming we'll stick with the same general UI [22:58] are we going to go straight for the intelligent paper metaphor? [22:58] Hrm. [22:58] I was assuming not; that may be worth revisiting [22:58] we will need a data model, not a flat list of assets & actors [22:58] Yeah [22:59] we need rules diagrams, not a rules tree [22:59] A data model builder thingy, a rules builder thingy, a dfd builder thingy [22:59] all of which are diagrammatic [22:59] yup [23:00] huh [23:00] We're going to need something to define use flows, and something else to define capability transitions (although I think those may look very similar) [23:00] Also both probably diagrammatic. [23:00] i couldn't tell you about the capability transitions [23:00] When we get a risk model, we'll probably just be adding values to all the other diagrams [23:01] that's a wild-assed guess, which will probably be wrong. :-) [23:01] well, threat-wise i think we have one [23:01] We're going to want some kind of query thingy, so we can ask our interesting questions. [23:01] it is more spreadsheet like than anything else [23:01] oh, yes. definitely [23:02] it is lame to have to write code to get answers [23:02] oh, the risk model for the threats, you mean? [23:02] yep [23:02] yeah -- I'm imagining some kind of search window with a bunch of dropdowns, for lack of a better idea; hopefully we'll improve on that, though [23:02] although i guess i'm not sure what a threat looks like anymore [23:03] Raaaaaaar! [23:03] Like that [23:03] Only hairier [23:03] Action: asparagi laughs hysterically [23:03] Action: asparagi can't stop laughing [23:04] Action: Dymaxion grins. [23:04] people are always so worried about how to identify them, and all this time has been wasted [23:04] if only they knew [23:04] Action: Dymaxion grins. [23:06] ok. so that sounds fine. in a primarily diagrammatic interface like that, where does the now-obsolete data show up in the UI to potentially be retrieved? [23:06] Probably in a big bucket full of blocks of diagrams [23:06] so basically, the trash [23:07] Possibly as part of a design history slider/tree thing which we have in lieu of undo [23:07] right [23:07] well, it would implement undo, it just might look different [23:07] yeah [23:08] ok, it sounds like we should address losing manual info in v1 [23:10] Ok [23:10] Do we want to do versioning? [23:11] ugh [23:11] i don't know how [23:11] Well, if we do a design history style undo, it's half done [23:11] We need some kind of merge thingy, but that's it. [23:12] why wouldn't i just use external functionality, e.g. svn? [23:13] Because that doesn't solve the merge problem, which is the hard part [23:13] We're effectively a binary format, as far as something like SVN is concerned [23:13] Action: asparagi doesn't want to solve the merge part, either [23:13] Action: Dymaxion grins. [23:14] Also, having versioning gets us a big part of the way to solving the multi-organization threat model problem. [23:14] ok. let's put it on the list & do some research [23:14] e.g. maybe someone already has an obj vers lib [23:15] While we're on big hairy features, multi-user interaction [23:15] yeah [23:15] I don't know if that part will be the hard bit -- I think it's going to be dealing with the cascading changes and manually created info that are going to be hard for merge. [23:15] I was thinking of rejecting " Risks for external asset should be immune from grid reset" [23:15] yeah? [23:16] check the comment [23:16] http://bugs.octotrike.org/bugs/0084 [23:16] multi-user interaction [23:17] yeah [23:17] let's leave it out for v1 but do at beginning of v2 [23:17] hrm, ok [23:18] i know it's not parallel, but i think it is the most correct thing to do (84) [23:18] yeah -- I'm fine with that. [23:20] want to quit early tonight? [23:21] you getting tired? [23:21] yah [23:21] ok... I'm kinda beat too. [23:21] Go get some sleep. :-) [23:21] it's hard to stay awake when no one is talking [23:22] ar, is that ok with you? [23:22] sorry [23:22] sorry? [23:22] For not talking more. :-) [23:22] oh [23:22] 'scoo [23:23] i made some of the notes we need in the bugs, but not all [23:23] i guess i'm going to bed [23:23] ok [23:23] g'night [23:23] I've got notes of what we added that I'll send to list momentarily [23:23] 'night [23:23] :) [23:23] gnite! [23:24] bye, ara! [00:00] --- Thu Mar 2 2006