Replies: 1 comment
-
|
Yes, indeed you (almost) always get some transfer in both directions. While we are documenting data flows and not directly IP/TCP/UDP packets, I follow the same conventions: the direction is from the client (initiating the data flow) to the server. In the rare cases when both can be source/initiator and destination/listener, or when the system vendor was unable to specify the direction and I did not have the opportunity to start a packet capture yet, I add both object aliases as sources and as destinations of the same data flow. The intent was at some point to be able to generate or verify firewall rules based on the documented flows. Not sure if it will really happen though (I have not yet found a way to identify which flows should be visible by a given firewall), but that would require the same directionality. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I think that most dataflows are dialogs and find it sometimes hard to decide which side sends and which receives.
For example : getting E-Mails from a server vie IMAP : The bulk of the data (the mails) go from server to client, but the client controls the transmission with IMAP commands and initiates it.
Or a web interface for a process is a free dialog between server an client.
Are there some hints or soft rules how to model that in the 'best' way ?
Beta Was this translation helpful? Give feedback.
All reactions