Back to the main page

Mailing List Logs for ShadowRN

Message no. 1
From: Number Ten Ox <number_10_ox@**********.COM>
Subject: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 08:43:01 -0800
My group just switched to VR 2.0. The group's decker, running a somewhat
upgraded Transys Cyberknight (aka a renamed Renraku Kraftwerk-8) and a
bunch of utilities that range from 6-8 (his Detection Factor is 7) went up
against a set of randomly-generated Orange-Average systems....

... and got his head handed to him on a platter.

This is not necessarily bad, I now know what sorts of systems to give him,
but in the process of angsting over the two pieces of ICE currently stuck
fast to his ass, he happened to ask "Is there any way to reduce the
security tally?"

Which is the question I now take to the list. Is there a way to do it?
Do you think there should be?


===
--Number 10, aka Aneirin Two-Tails.




_________________________________________________________
DO YOU YAHOO!?
Get your free @*****.com address at http://mail.yahoo.com
Message no. 2
From: Sean McCrohan <mccrohan@*****.OIT.GATECH.EDU>
Subject: Re: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 12:00:00 -0500
Quoting Number Ten Ox (number_10_ox@**********.COM):
> This is not necessarily bad, I now know what sorts of systems to give him,
> but in the process of angsting over the two pieces of ICE currently stuck
> fast to his ass, he happened to ask "Is there any way to reduce the
> security tally?"
>
> Which is the question I now take to the list. Is there a way to do it?
> Do you think there should be?

I think it should depend on the security level of the machine you're
attacking. Reseting the tally on a Green host probably isn't too tough - it's
stored on the system somewhere, and if you can find it, you can change it.
I'd say the equivilant current-day would be modifying system logs to cover
your tracks and make it look like everything was fine.
On a higher-security system, though...well, here's an example. At a
place I used to work as a system operator, the machines we really cared
about did two things every time they added something to a system log: they
wrote it to the local log file, and they sent it to a separate machine. That
machine just sat there and accepted log entries from all the important systems,
and scanned for certain 'problems'. I believe they also compared the two
copies on a regular basis. The log-collection machine accepted essentially
one-way connections from a specified list of hosts (the machines it was taking
logs from), and would allow interactive logins from the console or either of
two other machines. At that point, modifying the logs is WAY more trouble than
it's worth. There should be equivilant problems with resetting the security
tally on a high-security machine.

--Sean

--
Sean McCrohan (mccrohan@**.gatech.edu) | "He uses his folly as a stalking
Grad Student, Human-Computer Interaction | horse, and under the presentation
Georgia Institute of Technology | of that he shoots his wit."
http://www.lcc.gatech.edu/~smccrohan | _As You Like It_, Act 5 Sc 4
Message no. 3
From: David Buehrer <dbuehrer@******.CARL.ORG>
Subject: Re: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 10:05:23 -0700
For the mere cost of a Thaum, Number Ten Ox wrote:
/
[snip: converted to VR2]
/
/ ... and got his head handed to him on a platter.
/
/ This is not necessarily bad, I now know what sorts of systems to give him,
/ but in the process of angsting over the two pieces of ICE currently stuck
/ fast to his ass, he happened to ask "Is there any way to reduce the
/ security tally?"
/
/ Which is the question I now take to the list. Is there a way to do it?
/ Do you think there should be?

AFAIK, the only way to reduce the security tally is to leave the host
alone for awhile. I'm thinking that if you gain control of the host
you can reduce the tally, but I'm not sure about that.

IMHO those should be the only methods available for reducing the
security tally.

The other option is to not increase the tally in the first place :)

-David B.
--
"Earn what you have been given."
--
email: dbuehrer@******.carl.org
http://www.geocities.com/TimesSquare/1068/homepage.htm
Message no. 4
From: Starjammer <starjammer@**********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 13:35:29 -0500
At 08:43 AM 1/19/99 -0800, Number Ten Ox wrote:
>
>This is not necessarily bad, I now know what sorts of systems to give him,
>but in the process of angsting over the two pieces of ICE currently stuck
>fast to his ass, he happened to ask "Is there any way to reduce the
>security tally?"
>
>Which is the question I now take to the list. Is there a way to do it?
>Do you think there should be?

The only recorded way is to leave the system and let the tally decline
slowly. As to reducing it manually...

Generally the answer should be no. The tally sort of represents all the
cumulative little system errors and glitches that start mounting up from
the decker mucking about with the system (crashed software, reallocated
system resources, CPU slowdown due to the decker's pirate utilities
running, and so forth). There's really no way to correct those without
administrative access to the host machine, and if you've got that then
you're not decking the machine anyway. :) On top of that, in order to
reduce some of those factors you'd have to do some decidedly unhealthy
things, like reinitializing crashed IC programs. Not good.

As a rule of thumb, any system above Green is probably going to have system
monitors that the decker can't circumvent from the inside of that host.
Any system of any level where an administrator is actively monitoring
(either jacked in or through monitoring programs) is also going to be
almost impossible to reset without getting caught.

Bear in mind that the admin doesn't have to be staring at a screen, either.
For example, my former employer had a diagnostic program that listed
downed machines or connections on an internal-use web page and also sent
messages to alphanumeric pagers carried by two of the NOC people. Certain
key log entries also triggered pager messages. So even that creampuff
Green system could have its very own decker on call once the tally hits
high enough, and if the system admin is paranoid and/or anal enough then
the step of alerting system deckers could be very low on the tally sheet.



--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 5
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 16:37:59 -0600
:This is not necessarily bad, I now know what sorts of systems to give
him,
:but in the process of angsting over the two pieces of ICE currently stuck
:fast to his ass, he happened to ask "Is there any way to reduce the
:security tally?"
:
:Which is the question I now take to the list. Is there a way to do it?

Not that I know of. You can log out, the re-connect, giving you a NEW
securty tally, but the system may still be on alert (se "host reset
times")

:Do you think there should be?


A long discusion some time ago on this list made it seem
technologically infeasable to have any sort of security tally that offered
real security and was still resetable from inside that system. So no, it
should proably not be allowed to be reduced, except possibally if you can
directly manipulate the hardware of the system.


One conclusion I came to about the VR2.0 / SR3 decking system is that
you should always design your deck so that your detection factor is as
high as it can possibally be. This is obvious, because it is the most
often "targeted" attribute of your deck, and it will let you get more
done.
Your decker could get up to a detection of 10 with his MPCP8 deck, if
he had masking 8, sleaze 8, and ran in stealth mode.


Mongoose
Message no. 6
From: Bob Tockley <zzdeden@*******.COM.AU>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 08:50:11 +1000
>This is not necessarily bad, I now know what sorts of systems to give him,
>but in the process of angsting over the two pieces of ICE currently stuck
>fast to his ass, he happened to ask "Is there any way to reduce the
>security tally?"


Erm... there is a way to reset the security - sit there and perform Null
Ops until it slowly downgrades and resets itself (you aren't really
touching the system resources so I figure it'll start reseting). Sure this
doesn't exactly bode well for deckers mid-run, but it's a real life-saver
if the decker is prepared to spend his time cracking a particularly tough
Host. Looking at the novels, for example, you see that most of the good
deckers start decking the system hours if not days before the run is going
down, seeding it with passwords, user lists, backdoors, etc etc etc. If
your deckers are in any way professional, they'll be breaking into the
systems they need to and leaving behind a bunch of stuff to give them fast
and easy access days ahead of time. A nice little side effect of this is
that the decker can then run overwatch without tying up a lot of the
gamemaster's time - since he'll most likely have user, superuser, or
supervisor-level access and have found any hidden SANs and the like.

(>)ARKHAM
"Pop-quiz hotshot: Five hundred Storm Troopers on jetpacks fly down from
the hole in the ceiling. What do you do? WHAT DO YOU DO?!?!"
Message no. 7
From: Zebulin Magby <zebulingod@*******.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Tue, 19 Jan 1999 16:17:16 PST
Bob Tockley <zzdeden@*******.COM.AU> wrote:

>
>Erm... there is a way to reset the security - sit there and perform
Null
>Ops until it slowly downgrades and resets itself (you aren't really
>touching the system resources so I figure it'll start reseting). Sure
this
>doesn't exactly bode well for deckers mid-run, but it's a real
life-saver
>if the decker is prepared to spend his time cracking a particularly
tough
>Host.
>
I don't think this will work, since even Null Ops are a cause for system
tests. <EGMG> I mean, with a decker just sitting there taking up space
and CPU cycles, sooner or later someone's gonna notice, right?

Zebulin


.sig deleted to conserve electrons


______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
Message no. 8
From: Bob Tockley <zzdeden@*******.COM.AU>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 10:17:33 +1000
>I don't think this will work, since even Null Ops are a cause for system
>tests. <EGMG> I mean, with a decker just sitting there taking up space
>and CPU cycles, sooner or later someone's gonna notice, right?

The point of the test in a Null Op is to hide your presence. If you just
sat there and didn't bother, then I'd agree with you. Otherwise, well... I
guess it comes down to interpretation of the rules.... again. <sigh>

(>)ARKHAM
"The truth - It had to happen. It might as well have been me."
Message no. 9
From: Ulrich Haupt <sandman@****.UNI-OLDENBURG.DE>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 10:59:05 +0100
Starjammer wrote:

>
> The only recorded way is to leave the system and let the tally decline
> slowly. As to reducing it manually...

<snip big part of answer>

To ask a related question:
Would the tally reduce if the decker stays quietly in the system?

And - how long can a decker stay in a system without being spotted
if he does no action if he is just sitting around?

I suppose it depends on the system (big surprise :-). In a
green system
like the local library it should be no problem but in the
Renraku system
I'd make it much harder as a GM.

BTW who be the one looking for you? Always a decker or could
it be an ice?

Whats your opinion?


Sandman
Message no. 10
From: Gurth <gurth@******.NL>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 11:42:07 +0100
According to Number Ten Ox, at 8:43 on 19 Jan 99, the word on
the street was...

> This is not necessarily bad, I now know what sorts of systems to give him,
> but in the process of angsting over the two pieces of ICE currently stuck
> fast to his ass, he happened to ask "Is there any way to reduce the
> security tally?"
>
> Which is the question I now take to the list. Is there a way to do it?
> Do you think there should be?

I don't think you can, BTB, reduce your security tally -- but note that
I'm not 100% sure of this since I haven't actually used the rules all that
much. (As I'm now playing a decker, hopefully that will change when
someone else gets to GM in my group, but I digress...)

As for it being possible, I think it should be -- I'd make it a Control
test using the Read/Write utility, with the security tally being lowered
by an amount equal to the decker's net successes. Note that the security
tally does not increase if the decker has any net successes, else the
operation would be pointless -- you'd get situations where the decker
rolls 5 successes, the system gets 2, and the security tally gets adjusted
up by 2... Of course, if the decker get no net successes the tally goes up
as normal.

You may want the decker to perform a Locate File operation to find out
where the host actually stores its security tally.

--
Gurth@******.nl - http://www.xs4all.nl/~gurth/index.html
And that's as far as the conversation went.
-> NERPS Project Leader * ShadowRN GridSec * Unofficial Shadowrun Guru <-
->The Plastic Warriors Page: http://shadowrun.html.com/plasticwarriors/<-
-> The New Character Mortuary: http://www.electricferret.com/mortuary/ <-

GC3.1: GAT/! d-(dpu) s:- !a>? C+(++)@ U P L E? W(++) N o? K- w+ O V? PS+
PE Y PGP- t(+) 5++ X++ R+++>$ tv+(++) b++@ DI? D+ G(++) e h! !r(---) y?
Incubated into the First Church of the Sqooshy Ball, 21-05-1998
Message no. 11
From: Starjammer <starjammer@**********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 11:18:33 -0500
At 10:59 AM 1/20/99 +0100, Ulrich Haupt wrote:
>>
>> The only recorded way is to leave the system and let the tally decline
>> slowly. As to reducing it manually...
>
><snip big part of answer>
>
>To ask a related question:
>Would the tally reduce if the decker stays quietly in the system?
>
>And - how long can a decker stay in a system without being spotted
>if he does no action if he is just sitting around?

I would again say no. Maybe you could get away with it on a modern
computer server if nobody checked who was online and noticed an anomaly,
but not in the Matrix of 2060. Why? Because according to the SR source
material your Persona is running part of its code on the host machine.
That's eating system resources, and that draws attention.

How long before detection depends on the paranoia or anal tendencies or
even the boredom level of the system managers. You'd be amazed how many
problems will get caught if someone just gets bored and takes an idle look
at the system monitors. "Hey! What the hell is that process, and who's
running it?" And, of course, in the event of any noticeable system
slowdown the first thing the sysadmins do is look for runaway or
unauthorized processes running on the machine.

>I suppose it depends on the system (big surprise :-). In a
>green system
>like the local library it should be no problem but in the
>Renraku system
>I'd make it much harder as a GM.

Good rule of thumb.

>BTW who be the one looking for you? Always a decker or could
>it be an ice?
>
>Whats your opinion?

In 2060 system monitoring would probably be a more automated process, which
is why most tallies have deckers coming into the game so late in the run;
the system will try to correct itself before calling for human help. In
the early stages, it's probably going to be IC, and IC should be fairly
predictable. It's the system deckers that are the wild cards.

Most sysadmins of my experience think of their machines like their own
small children: They love them when they're good, get angry at them when
they're bad, tend them attentively when they're sick, rejoice when they get
well, play with them every chance they get, and get killing mad when
someone else slots around with them. Oh, and they know instinctively when
something's wrong, because their familiarity with the system lets them spot
minute differences in behavior. So to my mind the biggest danger any
pirate decker can face isn't IC, it's getting caught by a system decker
who's working or playing in the system.

Here's a thought: Give each host an Admin Rating that represents the
supervision it has. Each time the decker's tally trips another trigger
step on the system, make an Admin test with a TN equal to (Decker's Current
Detection Factor - # of trigger steps tripped). If the test succeeds, a
sysadmin has noticed an anomaly and will start monitoring the system. The
next time a trigger step happens, a decker will enter the system and start
investigating without knowing what's wrong. If/when the invading decker
triggers an Active Alert, the investigating decker will locate the intruder
in no more than 1-3 turns.

It's harsh, but it reflects the reality of how most sysadmins babysit their
machines. Bear in mind that a large corporate system won't necessarily
have a huge Admin rating, nor will a small system necessarily have a small
one. A corp system may have dozens of system deckers on 24 hour call, but
it also has lots of stuff happening on it, which means lots of little
problems that crop up. And wage-slave deckers don't always have the same
intensity as those who do it out of love for the job. OTOH, that little
Green host library system may have a fanatical computer-geek admin who
spends every waking moment jacked in and has a dozen redundant system
alarms to alert him when the tiniest thing goes wrong. YMMV.


--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 12
From: Ulrich Haupt <sandman@****.UNI-OLDENBURG.DE>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 18:21:39 +0100
Starjammer wrote:

<snip my first question>

> I would again say no. Maybe you could get away with it on a modern
> computer server if nobody checked who was online and noticed an anomaly,
> but not in the Matrix of 2060. Why? Because according to the SR source
> material your Persona is running part of its code on the host machine.
> That's eating system resources, and that draws attention.
As far as I know a SR host cost 2+Meganuyen which tells me
that it must be
used by hundreds or even thousands of people. An icon which
does nothing
doesn't need much system resources. I always think that a
decker camouflages
his action by being 'invisible' or by being something other
''Hey - I'm a
M$Word'53 program and I need my lunchtime!''
So I don't think that resources are really the point.


> How long before detection depends on the paranoia or anal tendencies or
> even the boredom level of the system managers. You'd be amazed how many
> problems will get caught if someone just gets bored and takes an idle look
> at the system monitors. "Hey! What the hell is that process, and who's
> running it?" And, of course, in the event of any noticeable system
> slowdown the first thing the sysadmins do is look for runaway or
> unauthorized processes running on the machine.
As I said I don't think that you can spot one process
between thousand of others,
but who tells that decking into a system starts only one
process and not 300?
So this point is up to imagination.

<snip
> >BTW who be the one looking for you? Always a decker or could
> >it be an ice?
> >
> >Whats your opinion?
>
> In 2060 system monitoring would probably be a more automated process, which
> is why most tallies have deckers coming into the game so late in the run;
> the system will try to correct itself before calling for human help. In
> the early stages, it's probably going to be IC, and IC should be fairly
> predictable. It's the system deckers that are the wild cards.

That's what I thought, too!


> Most sysadmins of my experience think of their machines like their own
> small children: They love them when they're good, get angry at them when
> they're bad, tend them attentively when they're sick, rejoice when they get
> well, play with them every chance they get, and get killing mad when
> someone else slots around with them. Oh, and they know instinctively when
> something's wrong, because their familiarity with the system lets them spot
> minute differences in behavior.
That's a good point! ;-)
<snip>

> Here's a thought: Give each host an Admin Rating that represents the
> supervision it has. Each time the decker's tally trips another trigger

<snip suggestion>
I think I like this one. It opens a possibility for the GM
to surprise the
PC decker and gives more room for roleplaying rather than
just decking. The
personality of the Admin becomes important.

> It's harsh, but it reflects the reality of how most sysadmins babysit their
> machines. Bear in mind that a large corporate system won't necessarily
> have a huge Admin rating, nor will a small system necessarily have a small
> one. A corp system may have dozens of system deckers on 24 hour call, but
> it also has lots of stuff happening on it, which means lots of little
> problems that crop up. And wage-slave deckers don't always have the same
> intensity as those who do it out of love for the job. OTOH, that little
> Green host library system may have a fanatical computer-geek admin who
Now that's a really good point!!!
I must admit that I always thougt just of the machine(host)
and not of the people
running it!
Now the little systems may become a better threat.

> spends every waking moment jacked in and has a dozen redundant system
> alarms to alert him when the tiniest thing goes wrong. YMMV.
>
> --
> Starjammer - starjammer@**********.com - Marietta, GA

Another question:
Are there more GM that introduced host-communities into the game?
By host-communities I mean one (physical) host shared by a
lot of companies
which need a host of a rating higher than one but cannot
afford it?
A 'village host' can be an example in which a whole
villages' merchants and
services share one host.

Sandman
Message no. 13
From: Starjammer <starjammer@**********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 13:31:47 -0500
At 06:21 PM 1/20/99 +0100, Ulrich Haupt wrote:
>Starjammer wrote:

>As far as I know a SR host cost 2+Meganuyen which tells me
>that it must be
>used by hundreds or even thousands of people. An icon which
>does nothing
>doesn't need much system resources. I always think that a
>decker camouflages
>his action by being 'invisible' or by being something other
>''Hey - I'm a
>M$Word'53 program and I need my lunchtime!''
>So I don't think that resources are really the point.

It's harder to spoof computer operations than most fiction lets on. Not
impossible, but hard. The bottom line is that for your desired outcome to
happen properly, certain things have to be left alone. For example, you
could forge the IP address header on the data packets of a transmission to
avoid tracing, but then the computer at the other end wouldn't be able to
route the datastream back to you. That eliminates almost any meaningful
communication between the two systems. Sure, you can ping-bomb something
to death, but you can't hack it that way.

>As I said I don't think that you can spot one process
>between thousand of others,
>but who tells that decking into a system starts only one
>process and not 300?
>So this point is up to imagination.

Well, here's my personal experience. When we'd get a system slowdown at
work, someone would run the "top" program. In Unix that simply reports the
20 or so processes that are using the most system resources at the moment
along with their particulars. Anyone who knows his business knows what
processes should be in that list and what they should look like. Anything
that shouldn't be there (like an unauthorized program) stands out like a
sore thumb.

It depends on the system you're maintaining, really. An R&D mainframe
running a bunch of hacked-together testing programs is going to be a lot
more unpredictable than, say, an e-mail server.

>Another question:
>Are there more GM that introduced host-communities into the game?
>By host-communities I mean one (physical) host shared by a
>lot of companies
>which need a host of a rating higher than one but cannot
>afford it?
>A 'village host' can be an example in which a whole
>villages' merchants and
>services share one host.

Bear in mind that Matrix reality doesn't correspond directly to computer
network reality. For instance, in RL most ISPs use something called
Virtual Web Hosting. Each web customer is given their own domain name,
their own URL, even their own IP address, but their web site actually runs
on a web server with dozens or hundreds of others. So far as that IP
address is concerned, however, it's the only thing running on that machine.

Matrix hosting can work the same way. You go to a SAN in an LTG, enter a
system, and wander around the host doing your thing. For the purposes of
the host and the virtual environment, you have no clue what machine you're
talking to, or what else is running on it. That same machine could be
running hosts whose virtual addresses are located in entirely different
LTGs or even RTGs.

Trust me, this works. The company I used to work for provided ISP
back-room and technical support services for nearly 20 regional ISPs across
the country with a total of almost 17,000 customers on the same servers,
and very few people ever caught on that they weren't working with a company
two miles up the road.


--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 14
From: Mark A Shieh <SHODAN+@***.EDU>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 13:31:15 -0500
Zebulin Magby <zebulingod@*******.COM> writes:
> Bob Tockley <zzdeden@*******.COM.AU> wrote:
> >Erm... there is a way to reset the security - sit there and perform
> Null
> >Ops until it slowly downgrades and resets itself (you aren't really
> >touching the system resources so I figure it'll start reseting). Sure
> this
> >doesn't exactly bode well for deckers mid-run, but it's a real
> life-saver
> >if the decker is prepared to spend his time cracking a particularly
> tough
> >Host.
> >
> I don't think this will work, since even Null Ops are a cause for system
> tests. <EGMG> I mean, with a decker just sitting there taking up space
> and CPU cycles, sooner or later someone's gonna notice, right?

Yeah, I always found that a bit odd. On a similar vein, a
faster decker will have to perform more null ops per turn than a
slower decker, since he gets an action more often. :)
We ran into this a while back, and decided that holding your
action indefinitely meant you didn't hog cycles performing a null op,
giving a solution that's in the vanilla rules. A bit weird, but I
guess it's like performing a sleep rather than waiting for input in a
loop.

Mark
Message no. 15
From: Bob Tockley <zzdeden@*******.COM.AU>
Subject: Re: VR 2.0 and security tallies.
Date: Thu, 21 Jan 1999 09:00:48 +1000
>In 2060 system monitoring would probably be a more automated process, which
>is why most tallies have deckers coming into the game so late in the run;
>the system will try to correct itself before calling for human help. In
>the early stages, it's probably going to be IC, and IC should be fairly
>predictable. It's the system deckers that are the wild cards.
>
>Most sysadmins of my experience think of their machines like their own
>small children: They love them when they're good, get angry at them when
>they're bad, tend them attentively when they're sick, rejoice when they get
>well, play with them every chance they get, and get killing mad when
>someone else slots around with them. Oh, and they know instinctively when
>something's wrong, because their familiarity with the system lets them spot
>minute differences in behavior. So to my mind the biggest danger any
>pirate decker can face isn't IC, it's getting caught by a system decker
>who's working or playing in the system.
>
>Here's a thought: Give each host an Admin Rating that represents the
>supervision it has. Each time the decker's tally trips another trigger
>step on the system, make an Admin test with a TN equal to (Decker's Current
>Detection Factor - # of trigger steps tripped). If the test succeeds, a
>sysadmin has noticed an anomaly and will start monitoring the system. The
>next time a trigger step happens, a decker will enter the system and start
>investigating without knowing what's wrong. If/when the invading decker
>triggers an Active Alert, the investigating decker will locate the intruder
>in no more than 1-3 turns.
>
>It's harsh, but it reflects the reality of how most sysadmins babysit their
>machines. Bear in mind that a large corporate system won't necessarily
>have a huge Admin rating, nor will a small system necessarily have a small
>one. A corp system may have dozens of system deckers on 24 hour call, but
>it also has lots of stuff happening on it, which means lots of little
>problems that crop up. And wage-slave deckers don't always have the same
>intensity as those who do it out of love for the job. OTOH, that little
>Green host library system may have a fanatical computer-geek admin who
>spends every waking moment jacked in and has a dozen redundant system
>alarms to alert him when the tiniest thing goes wrong. YMMV.

The way I see it, you don't need to add any more mechanics to the VR2
system (at least in this area). I figure that a decker simply hanging
around in a system without doing anything does not use enough of the system
resources to be picked up - especially if he's performing Null Operations
to hide his presence.

Look at it like this: the system admin and security systems are
constantly sweeping the system for intruders and/or illegal operations. If
they detect something suspicious the Security Tally goes up and there is
the chance that IC or a security decker moves to investigate. A decker not
doing anything would be able to avoid casual scans from the security
systems of the Host without too much difficulty and performs Null
Operations to do so. If the Host security does well against him in the
opposed roll of the Null Operation test, he has not masked himself
effectively and some clue to his existance becomes apparent to the security
system - which may then activate IC or whatever to counter the perceived
threat. If the system administrator is particularly paranoid, he may then
despatch a decker or two to investigate. Otherwise, well... the decker
sits there undetected.


(>)ARKHAM
"Smile. Then you can be just like me.... insincere."
Message no. 16
From: Bob Tockley <zzdeden@*******.COM.AU>
Subject: Re: VR 2.0 and security tallies.
Date: Thu, 21 Jan 1999 09:12:05 +1000
> Yeah, I always found that a bit odd. On a similar vein, a
>faster decker will have to perform more null ops per turn than a
>slower decker, since he gets an action more often. :)
> We ran into this a while back, and decided that holding your
>action indefinitely meant you didn't hog cycles performing a null op,
>giving a solution that's in the vanilla rules. A bit weird, but I
>guess it's like performing a sleep rather than waiting for input in a
>loop.


I don't know about the faster decker having to perform more Null Operations
than a slower decker. If you look at VR2.0s description, the Gamemaster
_may_ require a decker to perform Null Operations and generally only one
Null Operation is needed for the entire duration of the action, modified by
an amount based on how long he's doing nothing. The only way your fast
deckers would be making more Null Operations than your slow deckers would
be if you were making them perform one each and every action they were
waiting - which is obviously a waste of time, given that the rules are
written differently.

(>)ARKHAM
"Smile. Then you can be just like me.... insincere."
Message no. 17
From: Sean McCrohan <mccrohan@*****.OIT.GATECH.EDU>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 21:32:22 -0500
Quoting Bob Tockley (zzdeden@*******.COM.AU):
> The way I see it, you don't need to add any more mechanics to the VR2
> system (at least in this area). I figure that a decker simply hanging
> around in a system without doing anything does not use enough of the system
> resources to be picked up - especially if he's performing Null Operations
> to hide his presence.

First - next time, you might want to just quote PART of the post
you're replying to. I was grateful this time, since I hadn't read that one the
first time, but still...it was long.
Second...well, it really depends on the type of system you're in. On
some systems, just the presence of an open interactive connection could be
enough to make someone suspicious. Sometimes, just BEING there is 'doing
something'. Of course, if you can disguise yourself as something that ought
to be there, you're good to go. But that could be tough if it's a data
warehouse that normally only gets interactive connections from admins. You'd
need to be sneaky. (Realistically, you'd probably never log into a machine
like that in the first place - you'd send it fraudulent requests for data,
instead, from some machine that DOES handle users and normally works with
the data server. The problem then is that it's awfully hard for you to
avoid leaving a record of someone accessing the data...)

--Sean
--
Sean McCrohan (mccrohan@**.gatech.edu) | "He uses his folly as a stalking
Grad Student, Human-Computer Interaction | horse, and under the presentation
Georgia Institute of Technology | of that he shoots his wit."
http://www.lcc.gatech.edu/~smccrohan | _As You Like It_, Act 5 Sc 4
Message no. 18
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 21:48:30 -0600
:> Here's a thought: Give each host an Admin Rating that represents the
:> supervision it has. Each time the decker's tally trips another trigger

That is EXACTLY what the security rating represents; the admin (and
his assitantce programs) monitoring the system, plugging holes, and
triggering counter defences. Why add a double whamy? (Cripes, security
sheaves are nasty as is!)



:I must admit that I always thougt just of the machine(host)
:and not of the people
:running it!

That's just a problem in your thinking. If you want a quirky
sys-admin who goes in himself instead of using IC, put a decker apearance
low in the securty sheave. But a green system is a green system partly
becasue it is poorly monitored (low secuty level) and doesn't respond
quickly to intrusion (larger increment between security triggers), not
just because it has low processing power.

Mongoose
Message no. 19
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 22:02:58 -0600
:And - how long can a decker stay in a system without being spotted
:if he does no action if he is just sitting around?
:
:I suppose it depends on the system (big surprise :-). In a
:green system
:like the local library it should be no problem but in the
:Renraku system
:I'd make it much harder as a GM.

The rules already do that pretty nicley, no?


:BTW who be the one looking for you? Always a decker or could
:it be an ice?

The SYSTEM is looking for you (and other unwanted behavior)- its the
one that performs the securtity test against your detection factor, which
limits how well your Null Op test works. The system in this case would be
the admins and thier automated routines analyzing sytem performance, logs,
and all those other things.
The system (and / or admin) then takes measures to ivestigate or
correct the problem, in the form of appropriate IC, or sometimes a
"system" decker is alerted.

Mongoose
Message no. 20
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Wed, 20 Jan 1999 21:39:29 -0600
:I don't know about the faster decker having to perform more Null
Operations
:than a slower decker. If you look at VR2.0s description, the Gamemaster
:_may_ require a decker to perform Null Operations and generally only one
:Null Operation is needed for the entire duration of the action, modified
by
:an amount based on how long he's doing nothing.

Since longer periods of "null" time raise the TN, you could also have
the Decker roll a Null Op test and use that to determine how long is
needed until the next test, by figuring out the longest period the roll
was good for. For example, if the system got two successes Vs. deception
rating, and the Null Op test TN was 4, rolling a 10, 8, 5, 5, 4, 2, 1
would be good for a 1 hour "null" (you'd need 2 tens to last 12 hrs, since
the system got 2 successes, but your 2 7+ rolls buys you an hour).
Any result from the increased securtiy tally would occur at some
(random) period inside that interval, before the next test was needed.
Note that we don't usually bother with initiative when all the tests
are still just system ops (and maybe probe IC), since it generally has no
effect on the outcome (If you need to know when something finishes VS
"real-time", it might). Initiative is rolled when IC decides to attack-
that way, a fast Decker gets time to see the IC and do something, making
all his tres pricey speed somewhat worth it.

Mongoose
Message no. 21
From: Starjammer <starjammer@**********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Thu, 21 Jan 1999 00:09:30 -0500
At 10:02 PM 1/20/99 -0600, Mongoose wrote:
>
>:BTW who be the one looking for you? Always a decker or could
>:it be an ice?
>
> The SYSTEM is looking for you (and other unwanted behavior)- its the
>one that performs the securtity test against your detection factor, which
>limits how well your Null Op test works. The system in this case would be
>the admins and thier automated routines analyzing sytem performance, logs,
>and all those other things.
> The system (and / or admin) then takes measures to ivestigate or
>correct the problem, in the form of appropriate IC, or sometimes a
>"system" decker is alerted.

That's exactly why I suggested the Admin rating. As it is, the only way an
external decker becomes involved is when the system tells them to. That's
not the way it is in real life. I know, I've been there. Admins get
involved with their systems, and part of their job is to spot a problem
before it becomes a problem. Such a rating helps determine when a random
factor enters the equation outside the host's security plan.


--
Starjammer - starjammer@**********.com - Marietta, GA

"I must not fear. Fear is the mind-killer. Fear is the little-death
that brings total obliteration. I will face my fear. I will permit it
to pass over me and through me. And when it has gone past I will turn
the inner eye to see its path. Where the fear has gone there will be
nothing. Only I will remain."
-- Bene Gesserit Litany Against Fear, Frank Herbert, Dune
Message no. 22
From: Mongoose <m0ng005e@*********.COM>
Subject: Re: VR 2.0 and security tallies.
Date: Thu, 21 Jan 1999 20:04:57 -0600
From: Starjammer <starjammer@**********.COM>


:At 10:02 PM 1/20/99 -0600, Mongoose wrote:
:>
:>:BTW who be the one looking for you? Always a decker or could
:>:it be an ice?
:>
:> The SYSTEM is looking for you (and other unwanted behavior)- its the
:>one that performs the securtity test against your detection factor,
which
:>limits how well your Null Op test works. The system in this case would
be
:>the admins and thier automated routines analyzing sytem performance,
logs,
:>and all those other things.
:> The system (and / or admin) then takes measures to ivestigate or
:>correct the problem, in the form of appropriate IC, or sometimes a
:>"system" decker is alerted.
:
:That's exactly why I suggested the Admin rating. As it is, the only way
an
:external decker becomes involved is when the system tells them to.
That's
:not the way it is in real life. I know, I've been there. Admins get
:involved with their systems, and part of their job is to spot a problem
:before it becomes a problem. Such a rating helps determine when a random
:factor enters the equation outside the host's security plan.


My point being, those deckers that get involved probably ARE the
admins. A decking run can last less than 30 seconds- who else would get
involved that fast?
For your random factor, I think the security sheave should serve. Its
not random to the GM, but the PLAYER has no idea what will happen next.
The only time it wouldn't be a suprise is when a decker revisits a system-
in which case, you should probably slightly alter the list, if you want to
reflect sys-admin involvement in security.
Besides, deckers really are not all that great at finding intruding
deckers. Its a "needle in a haystack" problem ; which of the thousands of
visitors should they analyze? That is exactly what the Admin uses
security*- rating and IC for, and why the first few triggers usually
result in probes. I think an admin who tried to keep feelers out for
intruders all through his system would suffer from info-overload. Your
comparisons to real life are probably moot, since computers today do not
apoximate the capabilities of cyberdecks and IC- they couldn't even
survive the crash virus, but matrix systems can (hell, IC is based off its
routines...)
The basic result of your suggestion sounds like simply (on random
occasions) drastically lowering the security tally at which a decker
appears, or making one of the triggers something like "roll d6- 1-4, probe
: 5, decker : 6, both".

Mongoose

Further Reading

If you enjoyed reading about VR 2.0 and security tallies., you may also be interested in:

Disclaimer

These messages were posted a long time ago on a mailing list far, far away. The copyright to their contents probably lies with the original authors of the individual messages, but since they were published in an electronic forum that anyone could subscribe to, and the logs were available to subscribers and most likely non-subscribers as well, it's felt that re-publishing them here is a kind of public service.

Thwap!