p. 213. System (Software)

What, exactly, is the difference? And how would one go about converting an Agent into IC?

Hmmm, that confuses the hell out of me then. Doesn't that mean that a node is NEVER degraded? If neither IC, agents, or hackers degrade a node with their programs, then what is the rule for? The rule must just be for commlinks and one spawn server on the system? So a company can save a ton of money by buying one high-system server that spawns all its IC/agents and all other nodes have System 1?

That's what I've always thought, but people keep telling me they are different ... without actually explaining that difference.

So the OP is right, you can have hundreds of agents running on a few commlinks in your pockets and destroy any system you unleash your horde on without ever degrading it?

Sounds like you don't need to spawn ("load") your agents from your commlink at all. It sounds like you can spawn your agent on any other node (including pocketfuls of commlinks and nodes within the network you're hacking into) and the agent uses THAT spawn node for degradation purposes. You or your agent are never limited by the node you are attacking/visiting/playing in. Nodes that you are working in NEVER degrade. ONLY nodes you or your agent spawn from degrade.

Therefore, pocketfuls of commlinks filled with hundreds of agents can all be unleashed on a network at the same time and slaughter everything inside without ever degrading the target network nodes at all.

Am I wrong anywhere above? Should I head to the nearest commlink store and fill my van so I can take over the world?

Then what was meant by the statement about IC* not degrading the system they were running on, and therefore be more useful for Commlink defense? Does IC degrade its host system (or indeed the node it is running on and/or affecting), or does it get a 'free pass'?

*Yes, I do know that Agents and IC are the same thing.

I'm of view agents can be run on Node A and be present in Node B (but then you knew that, Ravor).

There are two issues around this view. The first is why I think that and the second is how I make that balanced.

My reasons for thinking this are as follows:

My initial reading of the wordig of the RAW suggested it and repeated readings appear to allow it by making distinctions for running agents on other nodes and because of how you can carry agents with you

It makes sense that if the software running a persona operates on your own hardware (commlink, terminal, whatever) whilst you travel from Node to Node, then there is no reason why an agent cannot do the same. After all, they can interpret the same data that your persona does, transmitting and receiving the same signals. I'm hard put to find a solid reason why an agent could not do this in any setting where a matrix user's persona could do this.

The fact that agents can explicitly accompany your persona whilst running on your own commlink certainly shows that in principle it works.

There is nothing in the rules that prevents an agent from operating in multiple nodes. Doing this in combination with forcing agents to run on the node they are visiting will cause your 4th Edition rule book to weep blood. Which while good for freaking people out, makes the pages all gummy and hard to turn.

If this is forbidden, then it makes roving IC, as suggested in the rule book problematic as you essentially have a wandering performance hit on your office systems and a wily hacker can jump the IC whilst it's inspecting the Response 1 toilet paper ordering sub-system.

My considerations on the implications in game are as follows:

It is acceptable to have the corp system have an "IC Node" from which IC runs and I occasionally use this in some of the systems that I have done. However, there are disadvantages. If you have any sort of network or subscription problem, say someone turns on a jammer in your wireless office, your security on the node their supposed to be protecting vanishes with a scream of static. But there are more types of network problem than deliberate on-site sabotage. It's a risk. It requires more expense in setting up a second system somewhere on which to run the IC. It creates a single point of vulnerability if this approach is used generally, whereby a hacker with a modicum of inside knowledge can knock out IC across the system. And if you have any sort of system problems, say you need to restart nodes, then without the security software actually being on the system it's supposed to be protecting, you can find yourself suddenly without protection.

Now these are not show-stoppers. As I've said, I use this approach some times. But if you don't need to do this, then why would you take the additional risks and costs? For many scenarios, making sure that the node you want to protect has the capability to run its own security software is the better and cheaper option. Basically, the GM has lots of justification for not taking this approach and if you do take this approach it introduces some new tactical options for hackers in your game, which is a good thing.

On the subject of Agent Swarmsp

There are two points to consider here. One is to consider the effect of an agent swarm on the victim. Firstly, with every additional agent, you decrease your chances of escaping undetected. Remember that every single one of those is a potential clue to who is out there hacking the network. If one is discovered, that's generally a bad thing when you're dealing with parties much richer and more powerful than yourself. Secondly, much information only has value so long as the person you took it from doesn't know that you have it. The agent swarm approach for this is worse than going solo. Thirdly, and probably most importantly, there are super-methods that corps can use to deal with intruders, which they are far more likely to use in the case of mass agent attacks. You can reboot nodes, sever connections and even shut-down for the afternoon whilst Renraku sub-contractors go through Matrix logs and find where all these data trails led back to. You'll be very, very pissed, but in the face of such a massive and well-funded attempt to get some information, it's a plausible response. In any case, the hacker returns home with nothing to show for it, but having tipped off the opposition.

The other point to consider is the expense of using agent swarms. It's a non-trivial expense for hackers and for the corporate world, which it was suggested would have them all over the place, it's a woeful waste of resources. The reason is because the aggressor can choose the point of attack. The corp is in the nature of defending the land and requires (in principle) vaster numbers of soldiers to defend that terrain. Far better to have good scouts travelling the land, who can signal the elite cavalry as needed.

I didn't mean to imply that you said it, although upon looking at my post again I can understand it being taken that way. It was Buster that said ...

The toilet paper node was a humerous example of the principle that the effectiveness of your IC will vary wildly if you ruled that it could not run on a remote node. This is a weakness because it gives an intruding hacker an advantage she can exploit. As regards checkpoints, I don't design systems that are dependent on this principle because it leaves you wide open to internal betrayal, physical intrusions (human or micro-drone) and even limits your options in terms of granting access to discrete sections of your system. Customers may have access to the "customer zone." Is that located inside or outside of your checkpoint system? Problems either way. Your first response will likely be "have multiple check points." That is what having IC distributed through your system is. I do use checkpoints (you can look at my example matrix sites document on my site, if you wish), but there are good reasons for having IC elsewhere and for having it roaming.

Other than the difficulty of getting Admin access, not much. I have already listed a couple of actions that can be taken to sever the remote IC and suggested that there were others such as this (along with other negatives). The way that you phrase this point makes me think you are arguing with my position that remote IC is the way to do things. You have imagined that position. I said that I use this technique some times, mainly for roving IC. It is one part of a security solution that a GM can use. And it's good to introduce more tactical options like this from the point of view of the game.

There are a couple of things in there. Firstly, 50-100 nodes all running IC is going to cost a lot of money, and that is wasteful. I can make systems with a fraction of that resource that are close to unhackable for anyone but the very experienced and well-funded hacker. Please don't make the mistake of thinking that every corp is Evo's head office, or a lab guarding hyper-advanced technology. For the majority of companies, plowing vastly more than is necessary into security costs is bad management.

Secondly, there is the realism aspect. Although the rules don't forbid it, many things break down if you take them to extremes, I think many GMs, myself included, would think that have 100 agents inspecting every persona that logged on in a single node would be problematic. I would guess that it would require greater infrastructure to handle, by that point.

Also, realistically, the majority of corps aren't going to pay a programmer to write an agent program and then replicate it 100 times. Leaving aside any GM judgements on whether a successful exploit against one type of program has knock on effects on an identical copy of that program, there are serious issues to consider. In order to support the 'write once, use infinite' cost saving technique, we've got to be talking about all the software that is necessary. So it's not just the IC, but at the minimum Analyze programs as well. So you have people spend a year writing this software. Who maintains it as exploits are discovered, who updates it as technology moves on? Who supports it when there are problems, what happens when you're programmer moves on to other projects of companies? Who will you pass the buck to when you have a security failure and the shareholders are baying at your heals? There are good solid reasons why a manager picks up the commlink and calls Renraku Matrix Security division for their Small Corp package deal.

Having worked in project management, I can tell you that the last thing you want to be doing when you run a small land-trading corporation is fiddling around with managing your in-house software development.

Well I felt that I addressed this, but you obviously don't, so I'll expand. If you use an agent swarm, there are two issues. Firstly, as a GM, I might have an issue with identical pieces of software being able to contribute meaninfully to a teamwork test. It's not like lots of people pusing on a door at the same time, it's like looking the same information up in ten different copies of a dictionary. They all hold the same ideas and information. But if you want a concrete RAW problem with agent swarms, and what I brought up last time, there is the statistical inevitability that if you use a swarm, then you will be noticed. I think you are suggesting that all these agents can support a primary hacker somehow, without actually participating in the hack itself and thus exposing themselves. I don't think that's supportable in either rules of fluff.

And once noticed, there are some really hard-hitting options that the defending node can take to deal with you. It's one of the few things that Ravor and I agree on, so it must be true. I've already given a solid list of reasons why it's important to remain undetected in my previous post. I wont repeat them here unless you think that remaining undetected is not important.

Your time scales are off. The rules for rebooting nodes (if that's the approach you wanted to take) are on pg. 223 of the BBB. It can be done in a couple of combat turns, started during the initial agent swarm's exploit test (and would be), and unless the agent's are starting off hacking the Vital Data Node, which in any system I designed, they would not be, then all they're going to do is get three seconds playing around in a checkpoint node if they're lucky.

As to logs and datatrails, you realise that each agent must spoof the data trail separately? And that each data trail can be tracked separately for a chance to succeed?

Well, I was talking about corporate systems in general. Commlinks are much harder to secure. This doesn't really relate to what I was saying, but as you asked for one, the following is pretty good, I think.

This should stand up to most attacks. A professional hacker, with veteran skills (4) and above average programs (4), will be detected most of the time:

Average 3 turns to hack on the fly. Average 1.3 turns for node to notice intruder (round up to 2). If the hacker isn't noticed on turn 2, then she will almost certainly be noticed on round three when she finally gets enough successes to gain public level access. I think almost certainly, it would be set to require security level access to get in, though. Some people don't make use of the access level rules in this way, so I leave the example as it is, but in, I think, most people's games, the odds of getting in undetected would be even shorter. This will also boost things up the level where elite hackers with top-grade programs routinely get noticed.

The response on noticing an attacker is customisable, but I would recommend turning off wireless connectivity. If the intruder actually gets inside, this will definitely be the response. Possibly causing dumpshock.

The reason for first considering Hacking on the Fly is that with a commlink, there are many reasons why it will be difficult to sit there hacking it for six or seven hours. It will go into and out of wireless areas, be turned on or off, perhaps. connect to systems that have their own security systems which watch for rogue connections (I think that as the system is all sixes, it's reasonable to make assumptions about the owner's lifestyle and job). At any rate, allowing a hacker to probe a wandering commlink for that length of time is definitely at the whim of the GM. Allowing it though, we get the hacker gaining access in about six hours, with the commlink getting a 50:50 chance of detecting the intrusion attempt.

So far, security has been pretty good, though obviously a concerted attack can get in. Any persona that does get in, will be subjected to detection attempts by the IC. Each of them has around a 65% chance of detecting the intruder (ties go in the hacker's favour because net hits are required on the perception roll). Cumulatively, that leaves the hacker only a 20% chance of going unnoticed. 10% if you factor in the chance of being unnoticed on gaining entrance, which you should.

So by this point, 9/10 hackers have been noticed and the commlink turns off wireless activity whilst Mr. Powerful Executive is alerted. Swtiching modes is a Free Action, so this ought to include severing wireless connections. Bang - hack over.

For those hackers that are in undetected and want to try and get data from the commlink, but this requires dealing with the Data Bomb. They'll have to detect it first. That's likely, because I elected to put a second IC program on there, rather than a Stealth program to hide the databomb. On reflection, it might have been better to do this and leave the system at 6 as well, but I can't be bothered re-working the example at this point. The hacker will have a 75% chance of detecting the bomb, followed by around a 45% chance of defusing it. In retrospect, it definitely would have been better to scrap the extra IC and beef up the databomb and stealth it. Oh well.

To summarise, in order to get any data from the commlink, the hacker must either:
Succeed at a long shot to hack on the fly, followed by chances of success of 10% followed by 75% followed by 45%

or if able to spend six or seven hours maintaining a connection to the commlink:

Succeed at 50% chance, followed by 20% followed by 75% followed by 45%. Total: 3% chance of professional, well-equipped hacker gaining access. I negelected to use hot sim, which improves all these odds, but we're still doing well.

As I said, I was talking about corporate networks, not commlinks. But as you asked for one, there you go. If you expand on the PAN, supplementing with another commlink which is wired to the first, then you can make things far more secure, but I don't like doing that because it's inelegant and doesn't suit the intent of the flavour or the rules.

Don't hate me, blue margaritas make a guy say stupid things.

You're just as vulnerable to physical intrusions if you have roaming IC instead. All they have to do is cut the connections to the IC that roams. Unless the needed node has its own IC which it can run (1 or 2 at most) then its defenseless.
Customer zone would be the checkpoint. They're authorized users, so they aren't hassled. If they do something disallowed, the IC crashes them. Just don't give your IC blackout/hammer and you're good.

Getting admin access isn't too terribly difficult. Remote IC IS the way to do things, if you make it a house rule. Theres a reason it doesn't work in RAW, and that is because then you can easily get a few dozen IC on any system with no impact to it. I'll reiterate, remote IC is not RAW.

Not really. Most anything with a wireless connection is rating 3. That means it can run a rating 3 IC, with attack and analyze. And there you go. Run a few hundred/thousand of those (Seriously, how many keyboards, monitors, printers, anything electronical are there in an office?) And have them all rove around the whole system even. No matter what, they'll be a few dozen in any given node.

Realism aspect? You mean, like how its realistic for a program to cause a strain on the processor running it? Not on the one its data is housed on?

Fine, its a shady corp, the buy one agent, and copy it a few hundred thousand times.

Teamwork tests, all the agents - 1 make a teamwork test which gives a dicepool bonus to the one with the best dicepool. That ONE makes the actual exploit test, opposed by the firewall, and the system gets its analyze against it. Maybe theres code in the agents about different methods to utilize if there are multiple personas working on a single problem. You won't be noticed, because the first one gets in, and since hes likely to act before the system (since runners would have him be rating 6) then he can get in, edit in all the other agents as valid users, delete all log files, turn logs off, and turn ic and analyzing off. Before hes detected as an invalid user. Then he edits himself a valid account too, and relogs on though that. They move on to the next node. No detection.

Yeah, like severing connections. That really hurts those agents it does.... Again, you're assuming you detect the agents. Theres only one you can analyze against to see them, and hes coming in with admin access in one go. His first action is command and turn off IC and the systems analyzing. Second, edit to delete logs. Third, edit to create admin accounts for all other agents and himself. Fourth, log in using his now valid admin account.

IF the node detects it, then yes, it can reboot and kick the agents off. If only corp security notices it because they suddenly can't log in, they have to run downstairs, and hit the physical switch, or hack their way back into their own server. Either way, the agents probably have enough time to take 2 combat turns per server to parade through the system.

If you're running a track program while its active. If you're analyzing it after they're gone, the analyzers are looking at the log files, which, if you turn off and delete, there are none. Ergo, no tracking.

Yup, tis scary when we agree isn't it?

Yeah I know, but thanks anyway.

Not quite the killer defense that I was expecting though.