Jump to content

Wie sieht das durchschnittliche IT Konzept einer durchschnittlichen Firma aus


Tr1n
 Share

Recommended Posts

Bei einer Teamworkprobe von so vielen Skriptkids erreichen die vermutlich sehr schnell das von GOD gesetzte Limit und fliegen hockkant aus dem Gitter. Innerhalb eines Host sehe ich eine sehr hohe Chance, dass der eine oder andere seine Probe verhaut und damit der Host alarmiert wird.

Link to comment
Share on other sites

Noch ein Beispiel Host:

 

GridGuide Seattle

 

GridGuide ist ein Verkehrskontroll- und Navigationssystem, das in vielen Megaplexen in Amerika verwendet wird. Da GridGuide ein beliebtes Ziel für Matrixvandalismus und Hackerangriffen ist, entschied sich der GridGuide Betreiber für ein aus zwei Hosts bestehendes System. Der Haupthost für die physischen Komponenten von GridGuide ist vom Host für die Verarbeitung der Verkehrsdaten und der Verwaltung getrennt, sodass beide Hosts auf ihre speziellen Aufgaben designt werden konnten. Während der Haupthost für die physischen Komponenten auf die Sicherheit spezialisiert ist (Verkehrskollaps und Unfälle mit Personenschäden aufgrund versagens der GridGuide Sicherheit sind äußerst schlecht fürs Geschäft), ist der Host für Verwaltung und Verkehrsmanagment auf die Rechenpower spezialisiert, die das verarbeiten der vielen Daten der Verkehrsüberwachung in Echtzeit erfordert.

 

Host für Verwaltung und Verkehrsmanagment

 

Design:

  • ???

Hoststufe: 7

 

Standardkonfiguration: Angriff 8. Schleicher 7, Datenverarbeitung 9, Firewall 10

 

Sicherheitsprotokoll:

  • Patrouillen-IC ist permanent aktiv. Das System wird ständig durch 1 Sicherheitsspinne überwacht. Wenn ein Alarm ausgelöst wurde, startet der Host IC in der folgenden Reihenfolge: Marker, Wirbel, Aufspüren, Störer, Leuchtspur und Absturz. Falls das Marker- oder Wirbel-IC lahmgelegt werden, startet der Host sie stets zuerst neu, bevor er die Liste weiter abarbeitet.  1W6 Kampfrunden nach Auslösen eines Alarms trifft eine weitere Sicherheitsspinne ein.

 

Nutzen:

  • Verwaltungs- und Personaldaten, in den Datenbanken finden sich gespeicherte Routen aller Fahrzeuge, die GridGuide benutzten (Matrixsuche nach Dateien), aktuelle Standorte aller Fahrzeuge, die gerade GridGuide nutzen (Matrixwahrnehmung/Icon aufspüren)

 

 

Host für physische Komponenten (Kameras usw.)

 

Design:

  • ???

Hoststufe: 9

 

Standardkonfiguration: Angriff 11. Schleicher 10, Datenverarbeitung 9, Firewall 12

 

Sicherheitsprotokoll:

  • Patrouillen-IC ist permanent aktiv. Das System wird ständig durch 1 Sicherheitsspinne überwacht. Wenn ein Alarm ausgelöst wurde, startet der Host IC in der folgenden Reihenfolge: Marker, Wirbel, Killer, Säure und Blaster. Falls das Marker- oder Wirbel-IC lahmgelegt werden, startet der Host sie stets zuerst neu, bevor er die Liste weiter abarbeitet. Wenn ein Eindringling ein einzelnes IC lahmlegt oder der Alarm über 4 Kampfrunden hinweg ausgelöst bleibt, loggen sich gleich zwei Sicherheits-Troubleshooter in das System ein, um den Angreifer zum Neustart zu zwingen (oder zu töten).

Nutzen:

  • Zugriff auf die Kameras der Verkehrsüberwachung (Übertragung abfangen), Zugriff auf Ampelanlagen (Gerät steuern/Befehl vortäuschen), (Direktverbindungen zu Ampeln/Kameras herstellen: Wartungsklappe unzugänglich in mehreren Metern Höhe - Verkleidung öffnen: Ausgedehnte Probe auf Schlosser + GES (6), 1 KR).

 

 

Für das Matrixdesign der beiden Hosts habe ich gerade keine Ideen... wenn euch was einfällt, dann her damit. Werde ich dann einfügen.

Außerdem fehlt mir der Betreiber Konzern des GridGuide Seattle. Weiß jemand was?

Edited by Corpheus
Link to comment
Share on other sites

  • 2 weeks later...

Ich hoffe meien Gedanken passen hierhin.

Gestern beim Spielen kam uns folgende Frage, warum sollte eine Firma die Waffen der eigenen Sicherheitskräfte nicht slaven? Die Kapazität für Slaves scheint ja unbegrenzt zu sein. Dass man einen Kaffeautomaten in der Lobby nicht unbedingt slaven möchte, da er eine unnötige Schwachstelle ist, halte ich für wahrscheinlich., aber gerade die Waffen gehören ja mit zum Schutz der Einrichtung. Wir haben uns dann gefragt, wie Slaves überhaupt in einem Host registriert werden. Soweit ich weiß gibt es da keine offiziellen Regeln. Ich bin dann auf den Gedanken gekommen, dass dies ja eigentlich über das Fundament passieren müsste, genauer über den Knoten "Slavesteuerung". Demnach wäre es ja eigentlich erst ab einer bestimmten größe sinnvoll Waffen zu slaven, da der Aufwand viel zu hoch ist.

Übersehe ich etwas oder habe ich mich gar irgendwo verlaufen?

Link to comment
Share on other sites

Dann würde tatsächlich nichts dagegen sprechen Waffen zu slaven, was das Decken im Kampf ab einer gewissen Hoststufe extrem schwierig macht. Schade, dass macht einen Kampfdecker für mich irgendwie zu unattraktiv.

 

Gibt es dafür irgendwo Stellen in den Regelwerken und seien es auch nur Fluffstellen?

Link to comment
Share on other sites

Wobei die Waffe einer Wache nicht die unsicherste Stelle eines WAN aus Slaves ist. Allerdings kann sie ein_e geschickte_r Taschendieb_in sie trotzdem mopsen und zwecks Direktverbindung weiterreichen. :)

 

Ich finde, es ist tendentiell keine schlechte Idee, aber vielleicht will eine Firma nicht, dass im Falle einer korrumpierten Matrixsicherheit die Waffen der realen Sicherheit alle angreifbar sind. Daher schätze ich, dass es keine allgemeine Praxis ist.

Link to comment
Share on other sites

Zentrale Sicherheits-PANs ... eine interessante Idee.

 

Die PANs sind jedoch limitiert, was ab einer entsprechenden "Menge" zu slavenden Geräten den Overhead des Managements einfach uninteressant gegenüber einem Host macht.

 

Zudem wiegt der Vorteil von IC und Spinnen einfach gegenüber einem relativ nackten Master-Kommlink.

Edited by Masaru
Link to comment
Share on other sites

So ein Sicherheitskonzept muss und sollte sich ja nicht nur auf die Matrix begrenzen. Man denke da nur an socialengeneering. Ich kann mir vorstellen, dass es eine gut gesicherte Waffen bzw Rüstungskammer gibt, wo die Sicherheitsleute nach ihrer Schicht die Waffen abgeben müssen. Die Waffen wären so nur in der Anlage und insgesamt denke ich, dass es einen besseren Schutz bietet. Aber eigentlich will ich das nicht, denn ich finde es sehr interessant, dass ein Decker nicht nur gegen Ganger im Kampf helfen kann. :D

Link to comment
Share on other sites

Die PANs sind jedoch limitiert, was ab einer entsprechenden "Menge" zu slavenden Geräten den Overhead des Managements einfach uninteressant gegenüber einem Host macht.

Ist eine Frage des Konzeptes: Ein gutes Kommlink kann sicherlich die Waffen eines Einsatzteams schützen.

Die Sache mit den unbegrenzten Slaves eines Konzernhosts sehe ich eher als "praktisch unbegrenzt": Für Spielzwecke muss der SL nicht nachrechnen, ob der Host diese Kamera noch slaven kann, wenn er will, kann er das. Aber am Ende ist die Überwachung eines Slaves ein Stück Rechenleistung, das gebunden wird. Ingame würde ich sagen, dass es schon Grenzen gibt, bei kleinen Hosts eher als bei großen, aber wenn die alle Labor-, Fabrik. sonstige Großgeräte geslaved haben, dann geht irgendwann die Performance des Hosts runter - nichts, was sich in spieltechnischen Werten ausdrückt, aber etwas, dass man im Fluff schon merkt. Also wird alles entslaved, das nicht zwingend geslaved sein muss. Ist insofern keine HausREGEL, weil es nicht regeltechnisches abbildet, sondern Fluff statt crunch abdeckt. Wenn das jemand als "Das ist dann aber Hausregel, mimimi!" deklariert, soll er halt.

Link to comment
Share on other sites

 Share

×
×
  • Create New...