comStar Firewall alert - PhaseThrough

filled with a high-rating Data Bomb, archived with strong IC, or
anything else a spider can invent. The node can also use Stealth
on itself, masking its true Matrix attributes, running programs,
or other pieces of information normally garnered by a Matrix
Perception Test.
When a node is using a decoy, the gamemaster should roll an
Opposed Test, per the normal Matrix Perception Test rules involving
Stealth (p. 217, SR4). If the observer gains no net hits, she
instead receives one piece of fictional information that the Stealth
program is configured to give. This technique may only be used
with files and nodes.
Decoys can be especially effective when used with a honeypot.
Honeypot
A honeypot is a file or node that appears to be valuable to
an attacker, but in fact is a trap set to lure intruders. All of the
personnel that have genuine access to the system are aware of the
honeypot’s true nature, and are instructed to leave it alone. This
means that any icon that attempts to access the honeypot is likely
to be an intruder.
Honeypots are usually implemented in two ways, either as a
decoy masquerading as an important file or node, or a ruse that appears
to be a weak spot in the system’s security. A decoy is usually
only visible to security or admin accounts and encrypted, attached
to a Data Bomb, or otherwise protected by security measures reserved
for important files and nodes, to support the deception. As
a ruse, they honeypot has low security and is used either as an indicator
or a diversion into a non-critical node designated for such
uses, often filled with IC or spiders. In either case, the honeypot is
often placed where a hacker can find it.
Honeypots are often used in conjunction with patrolling
IC that are scripted to watch for icons accessing the honeypot. A
more advanced form of this strategy uses several honeypots that
all appear identical to the actual important node or file, forcing an
intruder to guess which is truly valuable and which is a trap.
Layered access
A spider can use an “onionskin” approach to security. In this
method, the network is configured to have multiple gateways, each
leading to the next. Unless the attacker can access the target node
directly, she will be forced to work her way into a desired target
one node at a time, slowing the attack and giving the system a
chance to defend itself.
Limiting account privileges
Employees at a secure physical facility are not allowed to be
in areas to which they do not require access as part of their jobs.
Likewise, users in a secure system should not have access to actions
that are not critical to their performance. A simple way to do this is
to deny lower account levels the ability to do certain things, such
as see some or all of the files or subscriptions in the node, making
or accepting commcalls, running certain programs, etc.
Likewise, accounts are often watched and/or restricted in
terms of how many connections may be logged into them at a
particular time. In this setup, the system assumes that if two
or more entities are logged in under the same account, one of
them is a hacker. This security feature is tempered by the fact
Unwired
that many users run autonomous agents, and these agents usually
have access to their accounts. Nevertheless, some spiders
configure their systems to automatically refuse any account
login after the first, to closely scrutinize multiple logins, or at
least limit simultaneous logins to a small amount in order to
deter bots and malware.
passkey checking
A system that uses a passkey system will initiate an alert
when the access log shows the activities of a user that does not
have a proper passkey, usually (System) Combat Turns after the
start of the hacker’s intrusion. For many governments, corporations,
and other entities that have spent serious budget on a
passkey system, this is not soon enough. Adding patrolling IC
or spiders, specifically Analyzing icons for the proper passkey,
is good for shortening intrusion times to a few seconds, if that.
See Passkeys, p. 64.
protected access Log
The access log does not offer much in the way of protection
for a node, but it can help track down intruders after the fact.
Disallowing the ability to see, read, or edit the access log to accounts
below admin will help protect it against hackers. Another
possibility is to Encrypt the log, if the node has the processing
power to spare; this will only slow an attacker, however.
Yet another possible but unwieldy solution is to store the access
log in another node. This requires a dedicated link and node
access on the other node, but might confuse an intruder enough
to keep the data that the system collects about him.
rebooting
Shutting down a device and allowing it to reboot will
remove an intruder from a node with a Complex Action. In
fact, it will remove all users from the system at the end of the
Combat Turn in which the Reboot was initiated. The system
then begins to start up again the following Combat Turn (see
Reboot, p. 221, SR4).
However, it is not always feasible to reboot a node, even
for a few seconds. Marketing computers, security control
nodes, medical mainframes, Matrix traffic hubs, corporate
work servers, and military analysis devices are all machines
that have critical applications that require the system remain
up and running.
A system can be set to automatically reboot when an active
alert is initiated, whether it be by the Firewall, IC, or a user
with appropriate account access. This is not always desirable,
and many systems leave the decision to reboot in the hands of
a spider. High-priority nodes disable the rebooting option completely,
and can only be rebooted by physically disconnecting the
power from the hardware.
remote Spider
Having a spider on-site ensures that a system has a living person
available and (usually) in the node, ready to handle security
breaches. However, many spiders choose to work remotely. This
allows them to confront intruders without the vulnerabilities that
can be associated with an opponent in one’s node of residence (for
example, if an intruder successfully hacks into a node and gains
Simon Wentworth (order #1132857) 9
73
systeM security . . . . . . . . . . . . . . . . . . . . . . . . . . . . .