QUOTE (Heath Robinson @ Mar 30 2010, 06:17 PM)

Tymeaus:
Look, you totally misunderstood my point about subscriptions and cameras. In order to use the cameras you need to have them subscribed on your node, right? Well, if you are using the Security node to monitor the cameras, then those cameras need to be subscribed on the security node. Your model involves the following chain of subscriptions:
An -> Bm -> C -> D
However, to have camera data accessible in D you need a subscription from D to An (D -> An). Then you can trace the subscription back to D and avoid the chain entirely. Your "chain" involves having no capacity to use your resources.
Just a note... Cameras do not need a Subscription to communicate with the Sub-Node... though in my typical configurations, they tend to use one so that the Communications can be encrypted...
And Now:
Except that the "Chain," as you call it, forces you to travel from Node D (the Security Node) to Node C (Subnode Control for West Wing Surveillance Systems) to Node B (Subnode Control for West Wing Optical Systems) and Finally to Node A (Camera Xy)... you cannot pass from Node A to D directly... EVER... you MUST go Through each Sub-Node in the series to get there... and yes, you would have to indeed Hack your way in... that is the only method of accessing for someone that is not native to the system...
As the Security Spiders... they would have access to all of these Nodes, and may move to them (through the architecture) at will... and signals have the capability to move back through the system in the same format... from A to B to C to D... note, hoewever, that the Architecture DOES NOT ALLOW movement straight from A to D... this is NOT how this particular system architecture was designed...
QUOTE
Let's just discuss for a moment what your second chain design involves. A subscription can be mined for information only (since the Trace User action only gives you information on where a subscription originates, and Matrix Perception tells you what a node has subscriptions to). Having a subscription to a node does not give someone in your node special powers (it doesn't even let them use actions that require a subscription to the target since they have to have the subscription), right? So you need Information and the Log On action to get to Node N (since Log On does not need a subscription). Your chain is therefore based on occluding the existence of nodes beyond the next in the chain.
Once you know that node C or D exists, however, you must be able always use Log On to get to them. But, like I said, a subscription gives people in the node that the subscription is on have no special powers, so it must be that only the Information gives them the ability to use the Log On action to get to the next node. Since Info + Log On lets you access a node, Log On always being available, the only thing that prevents you from accessing node X is Info. If you can get the Info for node D, then you can access it.
This is where you are misisng the boat, in my opinion... YOU assume that once you are aware that Node C or D exists, you should be able to go Directly there from any node in the system... You would assume wrong, if the architecture mandates that you pass through each and every node between A and D however... as a Security Spider on the system in Question, I would have permissions to do so, and will not be impeded by the intervening Nodes, however, as the Hacker, you will not have those luxuries, and at that point you would still have to pass the Nodes in series... and to pass from Node to Node on the system, you would have to hack new access permissions for each node that you passed through, and suffer any of the impediments placed within your path of movement. Of course, if you have a legitimate user's account codes, this would be completely unnecessary.
QUOTE
The Log On action, sure, has to be taken by a user of a node, but the Subscriptions are held on the node itself. Nothing stops a user from using Log On with one of the Personas a node can generate and then just leaving everything as is and walking away. It creates a Subscription that hangs around - how else do you have your devices slaved 24/7?
Except to log on, you would have to Hack the access... which is the point here... you must HACK into the node just to Log On... as for subscriptions just hanging around, they don't... If you have an Icon in teh Node, teh subscription stays active... this is in no way a description of a Hardware connectivity, as the hardware is always active on a wired connection as long as there is power...
And as a point, Cameras do not need Subscriptions to the node, as all Audio/Visual communication is handled by Data Request (not Data Subscription), unless it is an encrypted communications link... as it is hardwired, it does not need to be encrypted as long as both ends of the node are encrypted (you cannot "Intercept" a Wired Communication easily... and if you choose to go this route, you may have found a possible vulnerability in the system)... For clarity's sake, however, even my hardwired connections on a system design would be encrypted (Thus a Dedicated Subscription)...
Don't Foget... Slaving is a Network Protocol, used to protect your outer "hubs" more easily... it is an option, but not necessary for the examples I was using... I was discussing a Layered Defense, which Slaving is not inherently a part of (Though it could be)... and in fact, you could slave all of your camera's to a subnode... I do not like that tactice much as it removes a line of defense, but it is more cost efficient, and as such, many systems will probably be set up in this manner...
QUOTE
Your previous attempt at a chain design failed because having an Account on a Passive node gets you Access to the node. You can Hack an Account for yourself, so the Hacker can get Access by... Hacking. Gee, that'll hold them off! (Should I really have to remind you why you failed previously?)
First... whoever stated the node was passive?
AND as you noted... YOU MUST HACK THAT NODE TO DO SO... and this can be planned for, and defenses put in place, such that it is not a guaranteed result... Forcing the Intruder to go through the motions of Decrypt, Scan, Defuse, Hack, Log On (for each and every node in the system; Yes this is an Extremem Example, but a possibly valid one in my opinion) gives the System Spiders Time... and that is what the Hacker must fear the most... the more time that it takes to penetrate a system, the more likely he will be discovered... discovery possibly leads to a more complicated mission at the least and a dead Hacker/Intrusion Team if they are really unlucky...
QUOTE
You have not detailed one working Daisy Chain. Looking at the things written in the "Tips and Tricks" section, I can find nothing that looks like a rule, and nothing that looks like it interfaces with any existing rules. The very title, to me, implies some exploration of the higher level ramifications of the rules - but rules relating to the implications of network topology on matrix actions, I cannot find anywhere.
I feel that it works for what I am doing, obviously you disagree... I find that the Section on
System Design and
Building a System provides enough guidelines to design a functional system... it can give you something simple to something so complex that it is ridiculous (read Nanotech Passkeys and DNA Biometric Verification)... you should be able to build any system you desire using those guidelines and the examples of systems laid out in teh example section thereafter.
The suggestions in the section are very relevant to the discussion though... they tell you how to set such things up in practice, and even give you some examples to back those ideas up... looks like rules to me... To write a book that could cover all of the "Rules" as you say, would take far more pages to produce than the entire line of books that have already been printed to date for SR4... And since there are an unlimited number of system configurations that could be produced, it is a somewhat useless task, as you would never complete such a document... For Me, the few examples in the books provide more than enough "examples" of their intent that I do not need detailed instructions...
QUOTE
I refuse to answer the text that accuses me of hubris except to note that you misunderstand my interpretation. Information control becomes a vital part of running a secured site, and the first step a hacker takes towards a hack is to do legwork on their target to get get the location of the target node. Script Kiddies don't do legwork
But you see, I do not think that I misunderstood your points... I just do not agree with your interpretation of the more than ample text that is available in the currently published books... Yes, Information control is the first line in a long line of defenses... but it is not everything... and all the research in the world is not going to give you the location to the Zero Zone, Racoon City like, Research Facility's Node... since that Node is NOT accessible from any where except from inside the facility. No amount of Legwork will aid you at that point...
And I bet Some Script Kiddie Shadowrunners do research, it is just that their research may not include the things that a Professional Hacker will think tend to about... it is a matter of Scale at that point...
The system architecture I have described is not (for obvious reasons) complete in its entirety, as it would consume much more space than has already been dedicated to the discussion... But I will stand by the use of Chokepoints to control how you would access a system... No matter how you describe it, if the system is designed to chokepoint users into a regimented access route, you cannot circumvent that route with a "Mystical Magic Teleport" that does not exist...
Now, I can see the possibility of an Admin Access System Map (much like what they had in 2nd Edition) that would allow you to move to any node within the system architecture, but in my opinion... that would ONLY be accessible from certain nodes, and only by specific individuals with the appropriate access... Useful (for the Company), but potentially exploitable, if you know about it and have the mojo to use it...
I will admit that you have provided some points that make me think a bit, however, and I thank you for that... they will do nothing but aid me in my attempt to design better systems.
*My Eyes just Crossed*... Hopefully I made at least a little sense there...
Keep the Faith