@TildalWave @theXs actually in this case, it is much much easier having gone through it with somebody. It is really an excercise in structured creativity...
@theXs good luck, and do let me know if you get stuck...
@theXs I assume you've read all the common literature on TMing... you've tried STRIDE-per-element?
Strictly speaking, the diagram should never have that, even if the "process" is a manual one. Though I guess in the case of the trusted admin, it is true that he can directly access the data store...
I usually go with one of two directions on those cases:
either force a process in there - eg the RDBMS, etc.
or ignore it.
the reason I accept the "ignore it" policy, regarding admins, is that their process is not really part of the application you're modeling.
the dba will always have direct access to the database, the sysadmin will always have direct access to the filesystem. For the most part, these things are irrelevant.
Mmmh, okay - then I need to reconsider my approach. Since it's part of a scientific work I would need to "proof" my approach
I think Michael Howard considered the "powers" of the admins which you mentioned above and modeled them as "interactors" with the application which don't need to follow usual processes
@AviD you're saying that I have three different approaches which I could apply right now (1) Model a "read log" process between admin and data store (2) don't model the admin at all (3) keep it as it is ?
@theXs that's true, but he also tends to deal with systems that do need to protect against sysadmins. I tend to take a more pragmatic approach.
@theXs pretty much, yeah. technically, (1) would be the most "pure" from both sides - you're modeling all possible interactors, but your DFD is still valid.
whereas (2) and (3) each fall on one of those, respectively.
as far as (2) goes, it all comes back to scoping. Very important to get that right - and usually, for typical web apps, you want to scope almost all infrastructure out of your system ("almost" except for the basics, such as DMZ, etc... )
@theXs I meant that (2) is not modeling all interactors, and (3) is not a valid DFD.
but even for (2), as I said the correct solution is not to ignore them, but to explicitly define them outside the scope.
@AviD I think I'm going with door (1) :), want to get the dfd correct and valid. Now that leads me to another question .. If the admin reads the Logfiles out of a "Log Component" Process can I declare the dataflows as out of scope?
@theXs ah, its usually at that point when I point out that logs shouldnt be write-only - and that they will need to develop some form of controlled UI to enable authorized admins to red, view, search etc the log data.
because obviously, directly accessing the raw log files is just plain ridiculous, right?? ;-)
darn it ... It's just as you said: my threat model would be a lot better if I would have an experienced senior consultant who is analyzing my threat model
so you suggest that I should follow approach (2) and employ those hints in my threat model
I mean, that would be the easiest way to approach that problem ... but it would invalidate the threat model too ( creation of data sinks )
I got lucky, I went through a couple of these during my stint at Microsoft, with some pretty edge case systems... Some really really smart people there, I picked it up quick after that.
what do you mean with "you can force the data back out through the application - I usually use another level 1 (or is it level 2?) diagram, jsut to split it out."
I'm thinking about modeling it like it's shown in the image above ... the log component read/writes into the log
hmm, this might just be personal preference - but I always put the external entities along the sides (or top, or bottom, dont matter) - because they are external, and you want to focus on the system (which should be in the middle).
this also helps for trust boundaries, and also as a visual guide - forcing your eye to focus on the system, and the interactions, not the external actors.
in this diagram, its hard to tell what is the actual system, and what is not.
by "force the data back out" I meant to add another dataflow, from the datasource to the appserver (?), and back to the user, even if this interface does not exist.
then you can both mark the lack of viewer as a threat, but also model the threats of a likely implementation of the viewer.
remember, when lacking details, you can make any assumption you want - as long as its explicit. (and makes probabilistic sense, of course).
it really is art-like, though, contrary to what I've been saying - and all the books - there really are no hard and fast rules that you can specifically follow.
it's two parts structure, two parts imagination, and 3 parts experience.
or maybe I have the amounts wrong... that always happens to me when I'm baking.
@RoryAlsop It's pretty good, once you manage to get over the fact it's with new actors (they do their job pretty good IMO). So, you're preparing to watch the new one (Into Darkness)?
