I was thinking of ways to secure my characters PAN, and I wondered if I had managed a fairly secure system (I'm AFB, so may be forgetting something obvious):
1) Commlink is encrypted with Strong Encryption (1 hour to 1 day, doesn't really matter).
2) User/Security accounts are disabled (i.e. they have no rights/abilities on the node, even if they do logon).
3) Anytime an Admin account logs on, an alert is triggered.
4) ARC: Wait 1 turn, log off user. If cannot log off user, shutdown (or scramble spyder, IC, etc.)
What I envisioned is the following:
Hacker breaks in with User rights. Finds he can't do anything.
Breaks in with Admin account. Alert is triggered. He has 1 combat turn to deactivate the alert, but the node itself is encrypted. Unless he has the encryption key, he cannot deactivate the account. And it would take too long to Decrypt the node.
Now, this assumes the hacker comes in on an Admin account (which I suppose is debatable...perhaps they just come in with admin rights, in which case swap out "Admin account logs on" to "Subscription established".
Full Version: Node Defense
Set a Pavlov data bomb on your commlink's node itself, and run an Agent/IC on the inside to have it routinely check on the data bomb. Have said Agent/IC initiate an alert once the data bomb is no longer present (a.k.a., disarmed).
There was This Trick I came up with a while ago.
I do not believe your node setup would work, because hacking an account on a node does -not- give you a preexisting account. It gives you access with roughly equivalent rights/privileges, depending on how deeply you've worked your way into the node via Exploit. The node wouldn't necessarily see an Admin account log on - that's what the Firewall+analyze roll is.
You may want to look at Slaving. It does something roughly similiar.
I do not believe your node setup would work, because hacking an account on a node does -not- give you a preexisting account. It gives you access with roughly equivalent rights/privileges, depending on how deeply you've worked your way into the node via Exploit. The node wouldn't necessarily see an Admin account log on - that's what the Firewall+analyze roll is.
You may want to look at Slaving. It does something roughly similiar.
In my opinion you cannot do it such as outlined, at least if you want to have some use of the comlink yourself.
The matrix rules are an abstract model of computer security systems.
If you are always using the admin account yourself, that is a security risk in itself (think windows98 or similiar) and should make it easier to get the admin account for example. The way a hacker gets into the system is a rather abstract, because really there are a lot of thinkable ways (the corebook mentions different examples if memory serves). If you always have an alert when admin logs on (even if that was posible to setup, which it isnt with rules as written) what use is the alert really ? in a physical example that would be the same as everytime someone entered the building an alarm was startet ! not usefull.
If you do not already have it, get a decoy comlink and have your real one in hidden mode (essential for a shadowrunner).
An alert can (normally) only have one reaction. Shutdown is probably easiest/cheapest. Scramble if you are a hacker yourself.
The matrix rules are an abstract model of computer security systems.
If you are always using the admin account yourself, that is a security risk in itself (think windows98 or similiar) and should make it easier to get the admin account for example. The way a hacker gets into the system is a rather abstract, because really there are a lot of thinkable ways (the corebook mentions different examples if memory serves). If you always have an alert when admin logs on (even if that was posible to setup, which it isnt with rules as written) what use is the alert really ? in a physical example that would be the same as everytime someone entered the building an alarm was startet ! not usefull.
If you do not already have it, get a decoy comlink and have your real one in hidden mode (essential for a shadowrunner).
An alert can (normally) only have one reaction. Shutdown is probably easiest/cheapest. Scramble if you are a hacker yourself.
QUOTE (Eratosthenes @ Apr 22 2010, 09:43 AM) 
I was thinking of ways to secure my characters PAN, and I wondered if I had managed a fairly secure system (I'm AFB, so may be forgetting something obvious):
1) Commlink is encrypted with Strong Encryption (1 hour to 1 day, doesn't really matter).
2) User/Security accounts are disabled (i.e. they have no rights/abilities on the node, even if they do logon).
3) Anytime an Admin account logs on, an alert is triggered.
4) ARC: Wait 1 turn, log off user. If cannot log off user, shutdown (or scramble spyder, IC, etc.)
What I envisioned is the following:
Hacker breaks in with User rights. Finds he can't do anything.
Breaks in with Admin account. Alert is triggered. He has 1 combat turn to deactivate the alert, but the node itself is encrypted. Unless he has the encryption key, he cannot deactivate the account. And it would take too long to Decrypt the node.
Now, this assumes the hacker comes in on an Admin account (which I suppose is debatable...perhaps they just come in with admin rights, in which case swap out "Admin account logs on" to "Subscription established".
1) Commlink is encrypted with Strong Encryption (1 hour to 1 day, doesn't really matter).
2) User/Security accounts are disabled (i.e. they have no rights/abilities on the node, even if they do logon).
3) Anytime an Admin account logs on, an alert is triggered.
4) ARC: Wait 1 turn, log off user. If cannot log off user, shutdown (or scramble spyder, IC, etc.)
What I envisioned is the following:
Hacker breaks in with User rights. Finds he can't do anything.
Breaks in with Admin account. Alert is triggered. He has 1 combat turn to deactivate the alert, but the node itself is encrypted. Unless he has the encryption key, he cannot deactivate the account. And it would take too long to Decrypt the node.
Now, this assumes the hacker comes in on an Admin account (which I suppose is debatable...perhaps they just come in with admin rights, in which case swap out "Admin account logs on" to "Subscription established".
The biggest problem I see is your Encryption Scheme (Strong Enc ryption), Account Priveleges, and your ARC setup...
If you only allow Admin Access to do anything, then that is what you must log on as...
First... You cannot hack the node unless the node has been decrypted... for a regular user, this is not a problem, as you have the keys...
You cannot access an encrypted node until you have decrypted it, so no hacking ino the node with any access prior to this step. See page 66 of Unwired for more details...
As you are set up, an Alert will be automatically initiated when even you log on... yes, you can stop the alarm in a pass (as it is your system), but so can anyone else with a single pass, so your alert would really accomplish anything, your alert is canceled and then they have the run of your System... Placing Patrolling IC is a good idea.
IF the system could not log you off (For some reason the alert is not canceled) then you enter a reboot phase, at which point, you will not have any access to your device until the boot cycle completes, including your Strong Encryption interval... the system is not available until your system completes the Strong Encryption at startup...
As a result you will either have 2 actions occurring...
1. You wll be in a perpetual reboot phase, as your device struggles to keep people out of the system or
2. You will have let everyone have access to all of your pertinant details, if they have the ability to enter your node with Admin rights, then they are going to run rampant with the ARC setup you have...
The best idea above is to have a Pavlov Data Bomb on your node and the IC/Agent to watch for the absense of that... this will alert you (or whomever/whatever) and will give you other ptions... Ideally, they will not ntoice the databomb and take damage upon entering the node...
Keep the Faith
QUOTE (Tymeaus Jalynsfein @ Apr 22 2010, 04:53 PM)
First... You cannot hack the node unless the node has been decrypted... for a regular user, this is not a problem, as you have the keys...
You cannot access an encrypted node until you have decrypted it, so no hacking ino the node with any access prior to this step. See page 66 of Unwired for more details...
You cannot access an encrypted node until you have decrypted it, so no hacking ino the node with any access prior to this step. See page 66 of Unwired for more details...
That's an interesting point. It was my understanding (and I could be wrong), that an encrypted node could be logged into/subscribed to, but would need to be decrypted in order for the person to actually do anything in the node (either via having the key, or using Decrypt).
So in this instance, they'd log on/subscribe, find they have to decrypt, but as it is Strong Encryption, they won't be able to deactivate the alert in time.
If it works as you surmise, then yea, it wouldn't really work. Though of course the Strong Encryption would still prevent most from bothering him, in a tactical situation (i.e. firefight, no one's going to be decrypting it before the fight's over).
As for only allowing Admin account status to be able to do anything, it was originally intended for my character's PAN, and as he wasn't expecting anyone else to be accessing his PAN legitimately, he'd only need the one account type. For a corp node, the other user status's would have to be revisited.
The idea behind an alert always being triggered would be akin to a home burglar system that beeps incessantly until you enter the code at the control panel. If you don't, it calls the police (logs the subscriber off/shuts down the node).
Yes, the rebooting would be an issue (as it would need to be re-encrypted), but at least it would dump whomever was online, and they'd have to get back in. Perhaps shutting down wouldn't be an appropriate response (instead just keep trying to kick them off).
QUOTE (Eratosthenes @ Apr 22 2010, 03:13 PM)
That's an interesting point. It was my understanding (and I could be wrong), that an encrypted node could be logged into/subscribed to, but would need to be decrypted in order for the person to actually do anything in the node (either via having the key, or using Decrypt).
So in this instance, they'd log on/subscribe, find they have to decrypt, but as it is Strong Encryption, they won't be able to deactivate the alert in time.
If it works as you surmise, then yea, it wouldn't really work. Though of course the Strong Encryption would still prevent most from bothering him, in a tactical situation (i.e. firefight, no one's going to be decrypting it before the fight's over).
As for only allowing Admin account status to be able to do anything, it was originally intended for my character's PAN, and as he wasn't expecting anyone else to be accessing his PAN legitimately, he'd only need the one account type. For a corp node, the other user status's would have to be revisited.
The idea behind an alert always being triggered would be akin to a home burglar system that beeps incessantly until you enter the code at the control panel. If you don't, it calls the police (logs the subscriber off/shuts down the node).
Yes, the rebooting would be an issue (as it would need to be re-encrypted), but at least it would dump whomever was online, and they'd have to get back in. Perhaps shutting down wouldn't be an appropriate response (instead just keep trying to kick them off).
So in this instance, they'd log on/subscribe, find they have to decrypt, but as it is Strong Encryption, they won't be able to deactivate the alert in time.
If it works as you surmise, then yea, it wouldn't really work. Though of course the Strong Encryption would still prevent most from bothering him, in a tactical situation (i.e. firefight, no one's going to be decrypting it before the fight's over).
As for only allowing Admin account status to be able to do anything, it was originally intended for my character's PAN, and as he wasn't expecting anyone else to be accessing his PAN legitimately, he'd only need the one account type. For a corp node, the other user status's would have to be revisited.
The idea behind an alert always being triggered would be akin to a home burglar system that beeps incessantly until you enter the code at the control panel. If you don't, it calls the police (logs the subscriber off/shuts down the node).
Yes, the rebooting would be an issue (as it would need to be re-encrypted), but at least it would dump whomever was online, and they'd have to get back in. Perhaps shutting down wouldn't be an appropriate response (instead just keep trying to kick them off).
Yeah... the Encryption comes first, then the hack... which limits some of the functionality of what you were going for, but not much...
As for the alert upon login, I see the point, however, anyone triggering the alert will just turn it off (they have admin access already), they would have the same steps as you would, and since it is just a matrix test to turn the alert off, it is no treally all that effective as a hinderance... in addition, the alert is not notifying anyone, just attempting to log them off... so when it happens, you will still be unaware of the intrusion...
Keep the Faith
I still wonder why a node only gets *1* action when an alert is triggered. You'd think a script of 'call the spyder', 'launch defensive IC', and 'Log the bugger off' would be simple enough for a node with the computing and memory to track water molecules around a whale...
Maybe it is to not turn the node into an actual active participant. (and instead it is program, like an ICE, that handles the responce)
Anyways you can have a scriptet ICE that is called on alert (I think unwired has rules about scriptet ICE), but of course you would have to pay for the ICE (and any programs once more), which is not so cheap...
Anyways you can have a scriptet ICE that is called on alert (I think unwired has rules about scriptet ICE), but of course you would have to pay for the ICE (and any programs once more), which is not so cheap...
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.