[11:58] Action: asparagi opens a bag of cereal more vigorously intended, spewing corn flakes all over the van [11:58] anybody up? [12:40] Action: Dymaxion is, but is about to run off to get breakfast [20:40] whew. i just sent Goran a several-page plan for making Flow more available in Squeak [20:40] we really want this if we are going to do a Trike server & client. [20:41] should be interesting to hear what he says. i forget what time it is in Sweden. [20:42] cool! [20:43] it's going to be kind of a lot of work [20:43] it's 6:45am on monday there [20:43] oh, excellent [20:43] so in just a few hours, he should get in to work [20:43] Action: asparagi is impatient [20:45] Action: Dymaxion grins. [20:45] actually, I'm wrong... more like 3:45am [20:47] oh [20:47] oh well [20:49] Action: asparagi is having a hard time getting excited by ui quirks documentation & would rather work on attack chaining [20:49] i wrote some of it, does that count? [20:50] Action: Dymaxion grins. [20:50] It's a start. :-) [20:50] I still need to start writing my part too, so I don't have room to talk. [21:40] y'know, i don't really want to do any release planning just yet [21:40] i admit it, i just want to hack around & have fun for a little bit [21:40] Action: Dymaxion grins. [21:40] ok [21:40] as soon as we have a plan, it becomes much more like work [21:40] yeah [21:41] i think i will actually get more done that way [21:41] we should talk about what we want to hack on next, but we definitely don't need a plan right now. [21:41] plus there are a bunch of avenues to explore right now [21:41] Action: Dymaxion nods [21:41] like connectors [21:41] yeah [21:41] and that graph library [21:41] mmm [21:41] and the client-server thing [21:42] and the xsd library so our xml support gets better [21:42] yeah [21:42] and of course engine support for use flows, and entity modeling, and business rules [21:42] I almost tackled the revision to exposure while you were in sacramento, just to see if I could, but I didn't have time. [21:42] it wouldn't be bad to just wander around a little & see what works [21:42] oh yeah, that too [21:43] that opens up a huge can of worms [21:43] like really it's tied into disaster response planning [21:43] Action: Dymaxion grins. [21:43] yeah [21:43] Action: asparagi smells scone creep [21:43] er, scope creep [21:44] i wonder what creeping scones smell like.,. [21:44] Action: Dymaxion has a mental image of fresh-baked goodness scurrying around on little currant legs. [21:44] Action: asparagi nickers [21:44] er, snickers [21:45] or perhaps they're like snails, only with butter. [21:45] i think i'm having some kind of freudian typing experience, indicating i'm hungry and [21:45] horsing around? [21:45] Action: Dymaxion grins. [21:46] Action: Dymaxion dirves into copyright law. [21:46] dives, even. [21:46] oh, i did that a little earlier [21:46] we are all co-owners [21:47] if one co-owner acts without the consent of others, the others are entitled to an equal share of the profits [21:47] there can't be copyright infringement, because it is the owner's own copyright [21:47] this from copyright.gov [21:49] ah, ok [22:02] so, the current attack stubs aren't really working for me [22:02] in general, or just because we don't have tool support? [22:03] neither; the specific content in the tool seems wrong [22:03] i know it seemed really good at toorcon after i had been up all night [22:05] yeah [22:05] what specifically? [22:09] well, pop open blog & go to cannot delete external asset [22:10] i checked this & it matches the attack stubs [22:10] but where is "if an action can occur only once, do it first"? [22:11] i guess maybe that's under take an intended action which changes a condition [22:11] hang on just a sec, gotta start laundry [22:11] but there's nothing that seems to hook down to prerequisite states, for example [22:11] 'scoo [22:12] i mean, basically we can hang attacks off assets, states, directly enforced rules, and DFD elements [22:13] i don't think those 4 things are adequately represented in the current threat stubs [22:13] (and of course i want to use them tomorrow ;) ) [22:15] ok, back [22:16] yes, I agree. [22:16] well, s/states/state machine/ [22:16] s/DFD elements/DFD/ [22:16] Are the attack stubs in the tool currently the set of attack stubs which we'd defined as text? [22:16] yeah [22:16] yes [22:17] i verified them [22:17] hrm. [22:17] at least they're the same as the ones in SVN [22:17] (there were line ending problems in that file; lemme check it in -- now it only has indentation problems) [22:18] Action: Dymaxion grins. [22:20] Error: Can't open file '/home/trikesvn/svn/db/current': Permission denied [22:20] or not [22:20] suck [22:20] i bet it was dave [22:20] ;) [22:20] Action: Dymaxion grins. [22:20] Action: Dymaxion tries to read the rest of that article and fails. [22:21] stupid paywalled libraries [22:21] so about the stubs.. [22:22] yeah [22:22] it seems like the top level for an asset attack (threat) should go [22:23] attack state machine [22:23] attack enforcement of directly-enforced rule [22:23] #action #asset directly on DFD [22:24] this is for elv, right? [22:24] hmm [22:24] good point [22:25] i guess a thing i don't like about even what i just listed is that it needs to be a partition of the threat [22:26] and those definitely aren't [22:26] what it really is is a listing of the high-level breakdowns we've chosen to describe the action in question [22:26] yeah [22:27] so after that i think we could come up with & argue for a partition, but at the top level of an asset attack, we have bupkis [22:27] math is hard [22:27] I think we need capabilities to adequately describe what it means to be able to implement a threat; that will let us chain attacks properly at the top level. [22:28] how does that turn into a partition? [22:28] Also, we need to understand that there are a whole bunch of granularity levels in elevation of privilege [22:28] http://www.cs.princeton.edu/~sudhakar/papers/winval.pdf [22:28] so, if implementing a threat implies a set of capabilities and our lower level model of what actions will lead to what capabilities is good (which I think it will be), then we get a partitioning. [22:28] speaking of capability chaining [22:29] Wim sent me that [22:29] elevation of privilege "despite rules" has another partitioning -- what rules you're violating. [22:29] i'm just afraid that our analysis of what set of capabilities could implement the threat could be wrong [22:30] i mean, how do we know it's right? [22:31] that paper makes me think we should have plug-in modules with predefined capabilities for specific systems [22:31] since different ones break it down differently [22:31] hrm [22:32] I think we have to (somehow) try to keep a certain degree of universality, or at least cross-compatibility, or we're never going to be able to model non-trivial systems. [22:32] i guess we could argue that what set of capabilities is required to perform the action is part of the initial system analysis, so we're allowed to insist that people get it right for the results to be right [22:33] just like if the intended actions are wrong, the threats are wrong [22:33] yeah [22:33] oh, I think I see what you were asking. [22:33] Hrm. [22:33] well, real non-trivial systems are in fact not very cross-compatible [22:33] So, we can figure out what set of capabilities is required for every intended action; that's part of the analysis process. [22:34] so that puts us a big part of the way there, and we are allowed to rely on that being correct. [22:36] so, suppose we have capabilities [22:36] it seems like we still need the dfd [22:36] of course [22:36] do we still need the state machine? [22:37] we need the dfd to understand what the potential cabapility set is [22:37] yes; some are capabilities will relate to state elements, I think. [22:37] it is insufficient for that purpose [22:37] and presumably we still need some reference to directly-enforced rules [22:37] yeah [22:38] so it seems like we will just add another category for "attack capabilities" [22:38] and it still won't be a partition at the top level [22:38] asp: of course; figuring out the capability set is (I think, unfortunately) an analyst-involved action once the DFD is defined [22:38] no, it is. [22:39] see, what I (think I may be, actually) saying is that capabilities will subsume all the other elements. [22:39] the DFD is absolutely insufficient to determine what capabilities are needed [22:39] I'm not sure if I actually agree with it, stated that way, but that's were that train of thought was going. [22:39] yes; it's necessary, but not sufficient. [22:40] oh, i misunderstood what "no, it is." applied to [22:40] ah, yeah [22:41] yah, it seemed like subsuming was where we wanted to go with it, it just feels fuzzy right now [22:41] so, basically, in order to determine the partition of a threat into ways in which that threat can be implemented, we need to find a boolean tree of capabilities which allow an attacker to complete that action. [22:42] that seems self-evident, I think. [22:42] i mean, if we have capabilities that are "get the system into state X" then we've added a capability model thing without getting rid of the state machine thing [22:42] yes [22:42] hmm [22:43] I don't think that's necessarily a bad thing -- we need capabilities to be glue; if they simplify the model in other ways, that's good, but we don't necessarily require them to. [22:43] i think the boolean tree of capabilities would be just the same as me thinking the stub through without capabilities [22:43] There's another partitioning that got lost, though. [22:43] which one is that? [22:44] We need to split "accomplish action despite rules" into some set of subthreats that state which set of rules is being ignored, because they all have unique attack trees. [22:44] we have one attack tree for each element of the powerset of rules for an action. [22:44] we haven't done that because the rule model is fundamentally flawed [22:44] We should eventually be able to generate them all automatically, but. [22:44] it will fix itself with the new model [22:45] yeah -- this is a place where that's hurting us [22:45] yes [22:45] i don't really want to work on v1 anymore [22:45] but maybe i will change my mind tomorrow [22:45] I'm not saying we should try to fix it here, but we need to be aware of that, because it interacts weirdly with the whole capability thing [22:45] Action: Dymaxion nods. [22:45] i know we've had this conversation before.. [22:46] we've got a useable v1 out... I guess maybe we should have it again next week. [22:46] well, maybe we should just think about in the new rule system, what the roots are [22:46] and how to partition those [22:47] if the answer is this hard, we're probably not framing the question right [22:47] I'm still really not sure... I think they'll be easier to partition, but I'm not sure if we have actions, so I'm not sure how to create threats. [22:47] I think the system changes so that a threat is a violation of a business rule of the system. [22:47] i don't think we have actions in at all the same way as we did before [22:47] yes [22:47] and because business rules specify both being able to do something and not being able to do something, the distinction between elv and dos gets fuzzier. [22:48] i agree, and that seems so simple & beautiful it cannot be ignored [22:48] Action: Dymaxion nods. [22:49] feh [22:49] all this work, and we have nothing, really [22:49] At which point, we look at the required set of capabilities for taking an action, and maybe the required set of capabilities for implementing a rule, and chain off of those into the DFD [22:49] use flows become rule flows; the set of DFD interactions involved in a rule. [22:49] hardly [22:50] we understand the problem and we have a place to start [22:50] trust me, that's huge. [22:50] i don't think we understand the problem [22:50] we might [22:50] And we're building a research system and we haven't thrown everything out yet -- it has to happen sooner or later [22:50] but we don't know yet [22:50] there is that [22:50] well, ok; we understand a whole lot more of the problem than we did when we started [22:52] so, is there any reason to believe that the attack stubs in v1 are fixable? [22:52] hrm, [22:52] I'm not sure [22:53] if there isn't, i'll stop trying & work on graph integration or something [22:53] i feel like the rule part you brought up is soluble [22:53] I definitely don't have an idea of how to fix them right now. [22:53] Oh yeah, that definitely is, I just wanted to make sure we were explicitly aware of it. [22:54] is the only unsoluble problem we are currently aware of the top level attacks under the threats? [22:54] yes [22:54] I think the only way to fix them is to manually come up with a better partitioning. [22:54] FWIW, I think DoS is much worse than Elv, based on my experience working through them. [22:54] i certainly can't think of an automatic way to do it [22:55] yah, DoS is what started me off on this [22:55] Action: Dymaxion nods [22:55] heh [22:55] the chocolate says: [22:55] "Don't think about it so much." [22:55] the DoS ones really suck... I couldn't figure out a way to write decent intermediate rules to bridge them over to lower levels at all [22:55] hah! [22:55] Action: Dymaxion grins. [22:56] the amoroso solution to create a partition would be Foo or NOT Foo [22:57] yeah, i feel like the old DoS stubs were actually better [22:57] that's certainly a definite partition [22:57] Action: Dymaxion nods [22:57] i wonder if i can find them somewhere [22:57] yeah, it just moves the problem down a level [22:57] That actually might not be a bad place to start; if we create an amoroso style partition that we're confident is a true partition, maybe we could simplify from it. [22:57] i mean, i guess one partition might be [22:58] do this at the moment the action happens [22:58] Action: Dymaxion nods [22:58] do this before the action happens [22:58] do this after the action happens [22:58] yeah [22:58] that's pretty amoroso-style [22:59] that seems a lot tighter... maybe we need to just go through the existing ones and redo them more carefully. [22:59] in the end it's all going to get back to DFD elements, so we could also partition by DFD element & move the other categories lower [22:59] it won't necessarily *fix* them, but it's definitely enough of a (potential) qualitative improvment to maybe be worth doing. [22:59] how so? [23:00] well, if it's not on a DFD element somehow, you can't attack it [23:00] all the state machine things, for example, eventually have to be tweaked in some way on some particular DFD element [23:01] yeah [23:01] so, time or location [23:01] any other dimensions we could partition on? [23:02] i guess we already partitioned on what [23:03] i fear partitioning on who is an enormous error we have already watched everyone else get tripped up on [23:03] yes [23:03] how is a bit tricky, but probably capability-like [23:03] is rule a true partition here? [23:04] not clear [23:04] i think when we have ross method we can treat it that way [23:04] Action: Dymaxion nods [23:04] we are asking the analyst to define a partition using this language [23:05] but for now it doesn't seem like a reliable choice [23:05] yeah [23:05] seems like we will end up using both time & location, at different levels [23:06] I guess I was thinking of it as a potential partition because rules carry (will carry, whatever) information about where and when they're enforced. [23:06] so which should we put top? [23:06] oh, that's _interesting_ [23:06] see, that's why I though that partition was interesting [23:07] i think we should do before, at, after as the top partition [23:07] (well, the second partition, under rules) [23:08] then under that it should be location [23:08] because it'll be easier to trace out that way [23:08] Action: Dymaxion nods. [23:08] That seems reasonable. [23:08] i want ross method _now_ [23:08] I'm going to have to see an attack tree here to really grok this. [23:09] i'll send you one in a little bit [23:09] I've been reading the book... it's a bit overwhelming how big it is and how much meaning there is in the system. [23:09] yeah [23:09] but i feel like these partitions would be peachy [23:10] we'd hang one off every chevron or bicycle seat [23:10] Action: Dymaxion nods [23:10] i think that will make the state machine be absorbed into the rules [23:10] yeah, it definitely will [23:26] so, um [23:27] it seems like if the actions really are CRUD, location-wise they must always occur on a data store [23:27] yes [23:27] sometimes more than one, but yes [23:27] well, really actions that can occur on a data store are CRUD [23:28] actions that can occur on a data flow are send & receive [23:28] actions that can occur in a process are ...? [23:28] hrm [23:28] invoke? stop? modify? [23:28] seems like a little process flow chart [23:29] i mean, processes are the only places that can make decisions [23:29] yeah -- that's modify, basically. [23:29] (modify what it does) [23:29] all state transitions have to occur in a process [23:29] as do all rule enforcement [23:30] what about transitions that don't happen until the state containing element is written to a data store? [23:30] I agree re: rule enforcement. [23:30] hmm [23:31] really the only thing a process does is make decisions [23:31] yeah [23:32] sorry, I was thinking about "actions on a process" not "actions by a proccess" above. [23:32] i don't know when to say a state transition has occurred [23:32] oh [23:32] i hadn't even noticed, i am still mudding around :) [23:32] I would say that a state transition has occured whenever what will check that state later would be satisfied that the state was in effect. [23:33] so really what we need is not a state machine, but a little control flow thing inside each process, for how it decides [23:33] that seems like the best definition to me. [23:33] danger will robinson [23:33] yeah, it sounds good to me too [23:33] yeah, yeah [23:33] Action: Dymaxion grins. [23:33] we are now approaching formal methods [23:33] but is it any worse than a state machine and some rules, really? [23:33] no, that *is* a formal method [23:34] Action: asparagi sighs [23:34] sort of -- we allowed ourselves some critical fuzziness there. [23:34] of course, that fuzziness had problems, but [23:34] well, the fuzz is not working too well [23:34] yeah. [23:34] I think we need to figure out where else it can god [23:34] maybe we need to ditch the fuzz [23:34] er, go [23:34] arm the criminals! [23:34] hehe [23:34] er, sorry [23:35] arm the bears! [23:35] Action: asparagi laughs [23:35] we don't have to go into a lot of detail with the flow chart [23:36] I might buy that, yeah -- again, I guess I'd have to see one, you know? [23:36] we could use ross method for the rule definition & the flow chart/decision tree for the implementation [23:36] I'm not sure what you're looking at right now. [23:36] Action: Dymaxion nods. [23:36] actually i'm looking at blog [23:36] oh, I mean in terms of the flow chart density [23:37] mostly i'm thinking about stuff because someone used the word "haphazard" to refer to my analysis in a meeting on friday [23:37] i can see how he got there [23:37] Action: Dymaxion nods [23:37] i don't agree, but is there a grain of truth? [23:37] yeah [23:38] definitely, right now. [23:38] mostly he got there because i ran out of time to complete the analysis he was looking at, and i didn't work on it in a very predictable order [23:38] so it looked a lot more haphazard than it is [23:38] but still [23:39] now all the haphazard anything is irritating to me [23:39] Action: Dymaxion nods. [23:42] did we ever do up a set of DFDs for Blog? [23:42] that aren't 0wned? [23:42] just the ones for that talk [23:46] the toorcon talk? [23:46] yeah [23:47] oh my [23:47] those are pretty comprehensive [23:48] aha! [23:49] and the use flow has everything i would need in the flow chart [23:49] cool [23:49] Action: asparagi cackles maniacally [23:49] what level of detail are you interested in? [23:49] now, we shall take over the world! [23:50] basically, what's in the use flow now is exactly the level of detail i care about [23:50] ok, cool. [23:50] That's very convenient. [23:50] And removes my removing-fuzz fears quite nicely. [23:50] i mean, really what i want to call out is that the process is the thing that controls what happens in the use flow [23:50] gotcha [23:51] i think this explains my ongoing discomfort about the use flows [23:51] they seemed sort of ... out of control somehow [23:51] i don't know [23:51] it's just an alternate way to present the same data [23:51] yeah? [23:51] ok [23:53] so what needs to be covered in a process flow chart, should we choose that representation, is an input spot for all inputs to the process, an output spot for all outputs to the process, and just enough detail in between to explain which inputs could lead to which outputs [23:54] so we mark all important decisions, and there's a window of opportunity between the decision & the results getting stored in a data store [23:58] that sounds reasonable [23:58] i think what i really like about this representation over use flows is that it can be seen as an expansion of detail in the DFD. it isn't a flat trace through the DFD [23:58] we need to distinguish not just outputs but outcomes [23:58] yeah [23:58] i feel like putting it in, then traversing it auoomatically will be easier [23:59] I guess I think we may need both [23:59] yeah... [23:59] yeah -- we may be able to derive all the information in a use flow from that model, which is fine [23:59] well, the use flows could be completely automatically generated as a different view on the whole diagram [23:59] heh [23:59] I think I personally find benefit from seeing things in use flow form [23:59] yeah [23:59] Action: Dymaxion grins. [23:59] yes, that makes sents [23:59] wow [00:00] --- Mon Feb 13 2006 [00:00] in fact, one could even call them a query against the threat model [00:00] interesting to accidentally get a homonym typo [00:00] a very interesting theory [00:00] yes, indeedy [00:00] heh [00:00] er, query, not theory [00:00] Action: Dymaxion grins. [00:00] a query which is very useful for writing a particular attack tree [00:00] BTW, we just found a fresh tofu factory on 12th which makes really wonderful fresh tofu -- you should stop in there next time you're up here. [00:01] so re: outcomes, it seems like outputs are the only outcomes that matter, yes? [00:01] yeah, exactly [00:01] sort of. [00:01] since they are the only way to transmit data outside the process [00:01] and only data stores can store data [00:01] So, the condition I'm thinking of is when the choice a process makes effects the structure of the use flow; I think that's an important distinction. [00:01] yes, absolutely [00:02] but it does it by sending different outputs [00:02] beyond that, I agree with you. [00:02] yeah [00:02] well, sort of [00:02] it's like a process is a circle around a flow chart [00:02] not just different output values, though; possibly different output channels as well [00:02] yes [00:02] every line that crosses the circle is important [00:02] I like that metaphor a lot, in fact [00:02] yeah [00:03] we just hook those lines into the rest of the dfd [00:03] so it really is like zooming into the process [00:04] yeah [00:04] that would express where the output goes as well as what it is -- does that work for you? [00:04] ooh, I like this [00:04] yeah [00:04] so _then_, tracing through by time is really easy [00:04] and location, grouped by time, is really easy [00:05] so all the partitions are easy [00:05] (down to that level anyway) [00:05] yeah [00:05] and we can way better see alternate paths to the same action [00:05] and we also have more meaning of "subvert this process", which was clear as mud before [00:05] yes, indeedy [00:06] mud mud mud [00:06] nobody else but the rose bush knows [00:06] Action: Dymaxion grins. [00:06] i hope nobody reads these logs [00:08] Action: Dymaxion grins. [00:08] what, you don't want people to see sausage^Wlaws^Wtheory being made? [00:09] Action: asparagi laughs [00:11] login is a lot better this way too [00:12] yeah? [00:14] yah [00:14] lemme send you something inna minute [00:14] ok [00:26] I like that paper from wim a lot; I need to digest it a bit more and chase some references, I think. [00:27] I don't believe that what they say there implies that our capabilitities will necessarily be platform-specific, although I do believe that there will be capabilitiess specific to a modelled system. [00:28]