 System Alert, is there a trade off? |
  |
 Dec 16 2005, 01:01 AM
Post
#1
|
|
|
Neophyte Runner  Group: Members Posts: 2,086 Joined: 26-February 02 Member No.: 364  |
Per the rules mechanics, when a system goes on Alert, it gets a +4 bonus to Firewall, seemingly for free. However, unlike in previous editions, there doesn't seem to be any kind of penalty or performance hit when the system goes on alert.
Sure, the firewall's doing a lot more scrutinizing of activity going on in the node (which is what the +4 represents), but a rating 2 firewall is the same as a rating 6 firewall to legitimate users of the node with proper passcodes. It'll cheerfully accept the passcode and let them go about their business. Is there some drawback to Alert status that I'm missing somewhere, tucked away in some corner of the book by the editor's rather unique orginizational layout? |
 |
 
|
|
Dec 16 2005, 04:07 AM
Post
#2
|
|
|
Moving Target Group: Members Posts: 753 Joined: 31-October 03 Member No.: 5,780 |
Err, no drawback, unless you're the snoop. the idea is the system was just informed that something twitchy is going on. THerefore, anything it might just skim over it now examines with a fine tooth virtual comb. Since the computer is so bloody fast in the first place, there's little difference.
Of course, that makes you wonder why people just don't leave the system on that way all the time. My guess is 2 things: 1) Alert is a reactive action - it only kicks in when something informs it there's illegal activity (or potential anyways). So the machine goes into alert and does a thorough scan of the initial area and spreads out. 2) Alert is active, but EXTREMELY thorough, to the point that anything inside is constantly being prodded by it, and therefore it'll bug the hell out of users if you don't shut it off. I'll have to read up on it later and see if I can spot some other/better reasons. |
|
|
|
|
Dec 16 2005, 01:02 PM
Post
#3
|
|
|
Great Dragon Group: Members Posts: 5,486 Joined: 17-March 05 From: Michigan Member No.: 7,180 |
M yguess would be that when its in "normal" mode, its jsut as alert and active, but spreading itself so thin looking at everything. When something trips an alarm, so to speak, it is able to focus its attention on that problem, and gain a big bonus.
However, as far as I can tell, if one user trips the alarm, the firewall rating goes up for everyone on the node - so that's not really how its working, I suppose. |
|
|
|
|
Dec 16 2005, 02:40 PM
Post
#4
|
|
|
Target Group: Members Posts: 51 Joined: 15-December 05 Member No.: 8,074 |
Well, I think that it should probably ding users for action times when they're in AR-mode, but when you're in full immersion it seems negligible. What it would be doing to a legitimate user would be prompting constantly for a password (probably every few minutes), forcing everyone to log out and back in, or closing non-system-critical connections.
...at least that's what an alert SHOULD be doing. It comes down to how you play it. |
|
|
|
|
Dec 16 2005, 02:53 PM
Post
#5
|
|
|
Shooting Target Group: Members Posts: 1,651 Joined: 23-September 05 From: Marietta, GA Member No.: 7,773 |
Sure, but then why not rig your comm to be on alert 24/7?
I'd prefer it if it lost a point or two in Response, or somethin'. |
|
|
|
|
Dec 16 2005, 02:57 PM
Post
#6
|
|
|
Target Group: Members Posts: 51 Joined: 15-December 05 Member No.: 8,074 |
It's the inconvenience of it. Having every legitimate user being constantly probed and searched by IC is the reason why - though I believe the number of "Searching" IC should be proportional to the size of the node and should generally be enough to ding it for Response by at least one.
|
|
|
|
|
Dec 16 2005, 05:53 PM
Post
#7
|
|
|
Target Group: Members Posts: 29 Joined: 21-October 05 Member No.: 7,871 |
It seems to boil down to 'they want hackers to be afraid of setting off an alert, but didn't want to make the mechanics complex by making you recalculate system settings during an alert'. Maybe a system on alert has a really obnoxious alarm buzz that discourages people from just leaving things on permanent alert. Personally, I prefer the system alert modifier being aimed solely at the person who set it off, that seems a bit less magical than the system suddenly having a better firewall against everything.
|
|
|
|
|
Dec 16 2005, 10:54 PM
Post
#8
|
|
|
Great Dragon Group: Members Posts: 7,089 Joined: 4-October 05 Member No.: 7,813 |
i would count it as a program running for the node, personally.
|
|
|
|
|
Dec 16 2005, 10:59 PM
Post
#9
|
|
|
Moving Target Group: Members Posts: 600 Joined: 31-August 05 Member No.: 7,659 |
------------------
A node on alert receives a Firewall bonus of +4 against the intruder that triggered the alert. Th is applies to all tests made by or against the node’s Firewall. ------------------ It's only against the intruder that triggered the alert, not everyone in the node. So you can't run it all the time. |
|
|
|
|
Dec 18 2005, 05:32 AM
Post
#10
|
|||
|
Neophyte Runner Group: Members Posts: 2,086 Joined: 26-February 02 Member No.: 364 |
Bingo. That's the bit I was looking for. I was still thinking in terms of old editions, where security tallys and alerts were systemwide (and it was never really well defined on how to handle more than one decker in the same system). Though this raises some questions: In both types of Breaking In tests (Hacking on the Fly and Probing the Target) it's possible to fail to break in, and to trigger an alert at the same time. Does the +4 to firewall apply if you're just an attempted intruder trying repeatedly to break into the system, and not a successful intruder that's already penetrated? And if it does apply, is it global against anyone who tries an intrusion after the system has been placed on alert, or is it the system able to differentiate a specific intruder that hasn't even gotten inside the system? I see a couple possible scenarios:
Right now, I'm leaning towards Scenario #3, but I have reservations about the node being able to single out a specific intruder before the intruder's inside. I can buy that the firewall would be able to single out anomalous system events as being the work of one particular intruder, when the intruder's actually inside the system, but until they're inside, the firewall only has limited information to work with. I suppose it could identify the code signature of the specific version of Exploit program you're using for the attempt, but then how do you handle a situation where one character has cracked the exploit program so that every hacker on the team is essentially running the same version? Does the whole team suddenly find it harder to break in, just because the first guy got detected on the way in? It could also identify intrusion attempts by access ID, but hackers can generate a new one of those simply by spoofing their datatrail. If you're attempting a break in, flub and get detected, should it be as easy as spoofing your datatrail to be able to avoid having to face an alert status firewall on your re-attempt? I suppose it could be a combination of the two. Change out your Exploit program to another version, and spoof your datatrail, and the node doesn't recognize you as the same intruder who failed to get in a few seconds ago. I'd like to be able to give high firewall systems a chance to flag you as an the same intruder if one of the identifying factors remains the same between break in attempts, but I'm not sure how I'd model this. |
||
|
|
|
||
|
Dec 19 2005, 08:27 AM
Post
#11
|
|||
|
Neophyte Runner Group: Members Posts: 2,086 Joined: 26-February 02 Member No.: 364 |
Ok, I've had a chance to mull it over a bit and I think I know how I want to handle it. (Note this is strictly houserule territory.) When you trigger an alert while failing an intrusion attempt, the node's Firewall does its best to single out any re-attempted intrusion activities from all the other data going in and out of the node. However, since the Firewall is working with a more limited set of information for these "outside the perimeter" alerts, compared to an alert where the intruder has actually made it inside the Node, the process of identifying a particular intruder is modified somewhat. In particular, there are two pieces of identifying information that the Firewall watches for to try to catch a re-attempt: Access ID, and the code signature of the particular version of the Exploit program you were using. If you reattempt the intrusion with both of those same identifying factors in place, you count as a identified intruder and face the full scrutiny of the Alerted Firewall. +4 to the Firewall for both the Exploit test for breaking in, and the Firewall's free shot at detecting you. If you do manage to break in on your subsequent attempt, your status as identified intruder carries over to your activities inside the node, whether or not the Firewall passes its free detection test. If you can mange to load a different copy of Exploit, and successfully redirect your data trail, then the Firewall no longer recognizes you as the identified intruder and your re-attempt goes against base Firewall rating. The Firewall's not watching closely at your new vector of attack, its scrutiny is focused elsewhere, at the original datatrail, and looking for more attacks from the same exploit program. The same goes for some other independent hacker who's trying to break in after your initial failed attempt but before your alert is cleared. If your second intrusion attempt succeeds without triggering a second alert, then you're free to roam the node while facing a base Firewall rating, these are not the droids you are looking for and you don't need to see my ID, move along. Of course, once you're inside, you still have to deal with the secondary effects of the Alert that you triggered on the initial failed attempt. IC may have been activated, White Hat Security Hackers may be roaming the system, etc. If you can only change one of the identifying factors before reattempting the intrusion, then the Firewall gets to make it's free detection test first, at Firewall rating +2, before you make your exploit test. If your re-attempt is detected, then you're identified as the intruder and make your exploit test against the full +4 alerted Firewall. If you're not detected, then you make your exploit test against base firewall, and if you get in, you're treated as an undetected intruder in an alerted system. There's an interesting twist here: if you have multiple hackers on a team, who are all sharing the same version of the Exploit program then if the first team member to break in flubs the first attempt, setting off an Alert, then every member of the team who is using that version of Exploit to try to get in gets the same "Scanned by the Firewall at +2 first" treatment. (This'd also apply if somehow a second person sharing the same Access ID were to try to break in after the initial alert, though this is not likely to happen since those are usually chosen at random when spoofing the datatrail.) |
||
|
|
|
||
|
|
Lo-Fi Version | Time is now: 18th April 2024 - 04:08 AM |
Topps, Inc has sole ownership of the names, logo, artwork, marks, photographs, sounds, audio, video and/or any proprietary material used in connection with the game Shadowrun. Topps, Inc has granted permission to the Dumpshock Forums to use such names, logos, artwork, marks and/or any proprietary materials for promotional and informational purposes on its website but does not endorse, and is not affiliated with the Dumpshock Forums in any official capacity whatsoever.