Sicherheitskonto

Sehe ich ebenfalls so.

Aber mal zurück zum Sicherheitskonto: wie rainmaker schon sagte - Abstraktion - auch das Sicherheitskonto ist eine.
Das ist kein Zähler der bei null anfängt und sich Punktemäßig aufbaut.

Punkte auf dem Sicherheitskonto heißt doch eigentlich nur, dass das System festgestellt hat, dass ihm Rechenzeit fehlt, es aber nicht weiß, wieso. Daher sind die ersten Maßnahmen ja auch Sonden und Aufspürprogramme, die Verdachtsweise mal losgeschickt werden.
Wenn sich die Fehler und Fehlzeiten häufen, erhärtet sich ja auch der Verdacht, das da wer am werkeln ist und schickt die nächsten Programme und so fort...
Irgendwo in den Sicherheitsrichtlinien steht dann drin, bei soundsovielen Fehlern und Fehlzeiten tue dies und das. (OK ich vereinfache zwar auch ein wenig, aber es deckt sich mit den Matrix-Quellen, oder?)
Irgendwo in dem verflixten Host werden dieser Fehler registriert. und da will ich eigentlich hin.

"Machnog-Morb" schrieb:

Irgendwo in dem verflixten Host werden dieser Fehler registriert. und da will ich eigentlich hin.

Da wäre eine Systemoperation wie z. B. 'Sicherheitskonto analysieren' recht. Durchzuführen auf Kontrolle. Müsste allerdings schon etwas schwieriger sein, als die normalen Operationen.

Oder stellst Du Dir da eher sowas wie Datei lokalisieren/entschlüsseln/editieren vor?

Das kompilieren des BS muß sich erstens nicht auf das gesamte BS beziehen. Und das Online Austauschen von BS Bestandteilen sollte ein Host eigentlich können.

Auch das Brenne eine ensprechenden Chip und den Online austausch stellt kein Problem dar. Die Sicherheitsrichtlinen können innerhalb von Minuten ausgetauscht werden und doch kann es nur durch manuellen Eingriff im RZ geschehen. Damit sollte ein Online-User keine Chance haben die Sicherheitsrichtlinien zu modifizieren.

Die Fehler werden im Hauptspeicher des Host registriert. Nach eine Shutdown sollte alle Sicherheitskonten die nicht vom Netzwerk (LTG usw.) geliefert werden gelöscht worden sein. Die Aktionen des Host basieren dann nicht auf Dateien (die veränderte werden könnten) sondern auf Speicherinhalt (was viel schwieriger, und evtl. hardwaretechnisch abgekapselt ist). Nur zu Protokollzwecken wird der Host die Daten in Dateien schreiben, und das evtl. auch in reine "Write Once" Speicherbereiche.

Hmm... dann wirds tatsächlich schwierig.
DARKWATER : Sicherheitskonto analysieren gibt es und liefert die Höhe des eigenen Kontos.
Ich hatte mir tatsächlich sowas wie Datei lokalisieren vorgestellt, da ich angenommen hatte, es würde irgendwo in einer Datei gespeichert.

"rainmaker" schrieb:

Das kompilieren des BS muß sich erstens nicht auf das gesamte BS beziehen. Und das Online Austauschen von BS Bestandteilen sollte ein Host eigentlich können.

Nein, muss es nicht. Nichtsdestotrotz braucht es Zeit. Testen sollte man es auch - wer spielt sich schon eine frisch kompilierte Version auf, wenn man im Netzwerk sensible Daten hat?
Entwickler kompilieren und Admins administrieren das Netzwerk. Selbst wenn eine Firma ihre OS selber schreibt, wäre es nicht unbedingt vernünftig 'live' irgendwelche ungetesteten Änderungen am System durchzuführen. Davon abgesehen muss ich dann davon ausgehen, dass mindestens ein Entwickler mit Durchblick mit allen relevanten Quellen zur Hand ständig neben dem genervten Admin sitzt anstatt in der Entwicklungsabteilung zu arbeiten, für den Fall, das er mal was kompilieren muss.

Ich sage das jetzt, weil ich der Meinung bin, dass so eine Lösung in der Praxis nur sehr beschränkt durchführbar, wenngleich auch nicht unmöglich ist.

("Hallo, ist hier Microsoft? Ja, genau, der Internet Explorer. Ich hab da ne kleine Änderung im Sinn und wollte Fragen, ob sie mir den vielleicht neu kompilieren könnten. Die Grundeinstellungen für die Sicherheit muss verbessert werden, ok? Wir haben da gerade so einen Hacker in unserem System, und es wäre mir recht, wenn er bis zur Mittagspause draussen ist. Sie können mir ja den neuen IExplorer übers Netz rüberschicken und gleich automatisch installieren, dann brauche ich das nicht mehr machen. Testen? Nö, brauchen wir nicht. Wir vertrauen ihnen und ihren kompetenten Entwicklern völlig. ")

"rainmaker" schrieb:

Auch das Brenne eine ensprechenden Chip und den Online austausch stellt kein Problem dar.

Das Problem liegt - wie schon gesagt - nicht beim Brennen oder beim Austauschen. Das das funktioniert, daran zweifelt keiner. Die Fragen lauten:
Wie schnell funktioniert es, wenn es darauf ankommt?
Von wo funktioniert es, wenn es darauf ankommt? (Admin ist unflexibel, da trotz Berechtigung keine Änderungen vornehmen kann, solange er sich nicht im RZ befindet....)

"rainmaker" schrieb:

Die Sicherheitsrichtlinen können innerhalb von Minuten ausgetauscht werden und doch kann es nur durch manuellen Eingriff im RZ geschehen.

Minuten sind in der Matrix ziemlich lange. Bis Du als Admin Deinen Chip gebrannt und ausgetauscht hast, wäre ich als Eindringling u. U. schon zehnmal über alle Berge - mit nem grossen Haufen Dateien unter den Armen.
Aber in einem hast Du Recht: Dieses System schliesst das Editieren der Sicherheitsrichtlinien durch Dritte effektiv aus, solange sich kein Eindringling tatsächlich in der Rechenzentrale befindet.

"rainmaker" schrieb:

Die Fehler werden im Hauptspeicher des Host registriert. Nach eine Shutdown sollte alle Sicherheitskonten die nicht vom Netzwerk (LTG usw.) geliefert werden gelöscht worden sein.

Genauso wie sämtliche Sicherheitsschwellen, Aufrufe von IC- und Sondenprogrammen, etc.

"rainmaker" schrieb:

Die Aktionen des Host basieren dann nicht auf Dateien (die veränderte werden könnten) sondern auf Speicherinhalt (was viel schwieriger, und evtl. hardwaretechnisch abgekapselt ist). Nur zu Protokollzwecken wird der Host die Daten in Dateien schreiben, und das evtl. auch in reine "Write Once" Speicherbereiche.

Es ist nicht soooo schwierig, den Inhalt des Arbeitsspeichers zu manipulieren bzw. auf dessen Inhalt zuzugreifen. Und wie Du schon sagtest: Einmal Strom weg, schon sind auch alle Infos im Hauptspeicher weg. Wollte ich Dein System lahmlegen, würde ich kurz den Speicher überlaufen lassen bzw. den Strom kurz kappen, und schon wären alle Richtlinien beim Teufel. Da sie ja nirgends gesichert wurden, und der Hauptspeicher ja unabhängig von irgendwelchen Dateien sein soll, wäre das mein Freischein für den Host, solange bis irgendein gnädiger Admin die Richtlinien wieder festlegt.

P.S.: Entschuldige meine Penetranz, rainmaker. Ich weiss, ich kann ganz schön auf die Nerven gehen. Aber bei Leuten wie Dir, die genauso gern recht haben wie ich, kann ich nie widerstehen... :wink:

Jetzt habe ich aber mal ne Frage an Dich: Jedes Deck hat aktiven Speicher, aber bei einem Host steht nirgends so eine Angabe. Vielleicht einfach aus dem Grund, weil man annimmt, dass solche Hosts in dieser Zeit immer genügend aktiven Speicher besitzen.
Is aber blöd, denn sobald man anfangen wollte, an diesem rumzufingern, weiss man nicht, wo man anfangen müsste.

Was denkst Du? Kann man den Zugriff auf den Hauptspeicher und damit auf die Sicherheitsrichtlinien und -konten mit einer oder mehreren Systemoperationen bewältigen? Wenn ja, auf welches Subsystem würde das ganze dann am besten gehen? Welche Risiken würde sowas für beide Seiten mit sich bringen, mal abgesehen von der Erhöhung des Sicherheitskontos? (Das ja sowieso keine Rolle mehr spielt, sollte der Angriff auf den Speicher erfolgreich sein, trotzdem bräuchten die Kon-Typen noch ein Ass im Ärmel...)

@ Machnog Morb

Irgendwo sollte man diesen Schotter manipulieren können, zumindest in vernünftig abgesteckten Grenzen innerhalb des SR-Regelsystems, da gebe ich Dir ganz recht.

Um eiin BS zu kompilieren brauche ich keinen begnadeten Entwickler. Und einfache (vom echten Entwickler vorgesehene) Änderungen in einem Quellcode zu bewerkstelligen, sollte für einen Ausgebildete Host-Admin kein Problem darstellen. Es geht ja nicht darum das gesamte BS umzustrukturieren, sondern eher darum, Änderungen an sicherheitskritischen Daten, die i.A. nur selten verändert werden müssen.

Wie schnell werden den bei Dir die Sicherheitsschwellen geändert. Ich habe noch von keinem Host gehört wo soetwas Situtationsbedingt online durch die Host-Betreung verändert wurde. Auch kenne ich kein RZ wo nicht twentyfour-seven Betreung der Host herscht.

Natürlich kannst Du den Host Crashen um dein Konto zu löschen, die Frage ist nur wie schnell ist der Host wieder da, Strom kappen wird auch schwierig (dagegen ist so ein Host normalerweise sehr gut abgesichert) und natürlich kickst Du Dich mit der geschichte selber aus dem Host raus. Genauso ist es möglich, das der Systemstatus beim Wiederanlauf des Hosts aus den sonst nur schreibenden Logs geladen wird ... auch wird ein Host danach meist mit aktiven Alarm hochgefahren und ein Sicherheitsdecker wird sich den Host nach einem (vom Betreiber) ungeplanten Shutdown auch genau anschauen.

Ich gehe davon aus, das ein Host genügen Speicher hat ... zumindest für alle userspezifischen belange. Im Grunde genommen könnte es wie bei Decks auch Regeln zum Bau/Kauf eines Hosts geben, aber wer braucht die wirklich? Sollte es jemals dazu kommen das jemand einen Host kaufen will, dann muß man halt improvisieren.

Ich denke, das man die Sicherheitskonten regeltechnisch nicht direkt manipulieren kann. Alle Manipulationen die machbar sind, sind schon indirekt abgebildet (z.B. durch das Schleicherprogramm oder durch die Sleaze Option bei Angriffsutilities).

Den Hauptspeicher kann man natürlich manipulieren, wie bringt man sonst ICE zum Abstürzen oder startet unautorisierte Programme. Es ist nur so, so ein Host muß nicht zwangsläufig eine Hauptspeicher besitzen. Er kann sein BS von der restlichen Software abtrennne, den HS des BS speziell (auch Hardware mäßig) schützen und so ein Übergriffe oder Manipulation von andern Programmen auf seinem HS (oder Teile seines HS) zu unterbinden.

"rainmaker" schrieb:

Um eiin BS zu kompilieren brauche ich keinen begnadeten Entwickler. Und einfache (vom echten Entwickler vorgesehene) Änderungen in einem Quellcode zu bewerkstelligen, sollte für einen Ausgebildete Host-Admin kein Problem darstellen.

Ich gebe Dir ja recht: Es ist kein Mega-Hexenwerk, mehr eine Frage der Organisation. In der Entwicklungsabteilung sitzen Leute, die genau das machen - entwickeln. Die Sysadmins sind auch eingestellt, um das System zu administrieren. Zwei völlig verschiedene Aufgaben. Natürlich könnte der eine evtl. auch eingeschränkt die Aufgaben der anderen übernehmen, aber das ist nicht die Regel.

Bisher habe ich noch nie gesehen, dass jemand im laufenden Betrieb Teile des OS austauscht, nachdem er sie durchkompiliert hat. Es mag möglich sein, aber es ist ein Risiko. Es gibt immer tausend Gründe, warum ein Programm nicht so funzt, wie es funzen soll, und deswegen gibt es so gut wie niemanden, der seinen Entwicklern (oder seinen Admins, was ja noch schlimmer wäre...) die Erlaubnis geben würde, ein Modul zu verändern, zu kompilieren und gleich wieder ohne vorherige Tests und Absicherungen einzubinden.

Ich meine, schliesslich hängen da Aber-Millionen an so nem beschissenen Renraku-Host, da geht man doch kein Risiko ein, indem man irgend einen Admin (...der ja eigentlich weniger entwickelt, als das System administriert...) mal schnell Änderungen machen lasst, die unter Umständen Auswirkungen auf das ganze System haben.

"rainmaker" schrieb:

Wie schnell werden den bei Dir die Sicherheitsschwellen geändert. Ich habe noch von keinem Host gehört wo soetwas Situtationsbedingt online durch die Host-Betreung verändert wurde. Auch kenne ich kein RZ wo nicht twentyfour-seven Betreung der Host herscht.

Es ist eine Frage der Flexibilität. Ein Admin mit Macht und Verantwortung muss jederzeit Zugriff auf sicherheitsrelevante Einstellungen haben. So wie ein Admin heute jederzeit an die Einstellungen seiner Firewall und seiner Admin- und Remotetoolz rankönnen muss.
Und: Es ist kein Nachteil, sondern eher ein Vorteil, wenn man schnell angemessen und flexibel reagieren kann. z. B. regeln das die Hauptstellen der Banken das auf diese Weise, genauso wie einige Softwareschmieden. Aber in erster Linie fahren diese Schiene die Webhoster und -provider: Sie müssen jederzeit sicherstellen können, dass Probleme in den Ansätzen bereits erkannt und ausgemerzt werden können. Die haben keine Zeit, ne halbe Stunde zu warten, bis sich die Kundendaten auf ihren Servern verabschieden, bzw. zu sehen, wie Kundensites nicht verfügbar sind, und die Konventionalstrafen in horrende Höhen steigen.

Und ja: In grösseren Rechenzentren sollte immer jemand zugegen sein, der auf evtl. Störungen und Notfälle reagiert. Deswegen hat immer ein Admin da zu sein, und das ist ja gut so. Umgekehrt bringt es recht wenig, wenn ein Admin da ist, der auf einen Notfall reagieren könnte, der aber ne Viertelstunde benötigt, um Einstellungen zu ändern. Man braucht sich hier nicht Sorgen um Flexibilität machen, wenn man schon vom System her in Sachen Reaktion und Flexibilität keine Wunder erwarten darf.

"rainmaker" schrieb:

... auch wird ein Host danach meist mit aktiven Alarm hochgefahren und ein Sicherheitsdecker wird sich den Host nach einem (vom Betreiber) ungeplanten Shutdown auch genau anschauen.

Da hast Du wohl recht. Andererseits hiess es auch vorher, dass die Daten bez. Sicherheitskonto von Icons nur im Hauptspeicher liegen. Wenn es ein Log-File gibt, von dem nachher wieder rekonstruiert wird, dann kann man theoretisch dieses File verändern, und sich nach einem evtl. Crash mit den - nennen wir sie mal "benutzerdefinierten" - neuen Einstellungen wiederzufinden.
Was alles andere angeht, hast Du absolut recht. Ein Systemabsturz ist schon etwas, was die Admins zum Grübeln bringen sollte. Es wäre ein armseliger Haufen, wenn sie nach so einem Vorteil nicht versuchen würden, hinter den Crash zu kommen.

"rainmaker" schrieb:

Ich gehe davon aus, das ein Host genügen Speicher hat ... zumindest für alle userspezifischen belange.

Dann sind wir schon zwei... :wink:

"rainmaker" schrieb:

Im Grunde genommen könnte es wie bei Decks auch Regeln zum Bau/Kauf eines Hosts geben, aber wer braucht die wirklich? Sollte es jemals dazu kommen das jemand einen Host kaufen will, dann muß man halt improvisieren.

Hmm. Denke ich auch. Es wäre nur mal interessant gewesen, die unterschiedlichen Hosts mal miteinander zu vergleichen. Zur Unterscheidung gibt es leider nur Farben und Zahlencodes.

"rainmaker" schrieb:

Ich denke, das man die Sicherheitskonten regeltechnisch nicht direkt manipulieren kann. Alle Manipulationen die machbar sind, sind schon indirekt abgebildet (z.B. durch das Schleicherprogramm oder durch die Sleaze Option bei Angriffsutilities).

Also, ich bin zwar - wenn man es vom technischen Standpunkt aus betrachtet - immer noch davon überzeugt, dass es gehen sollte/müsste/könnte.
Aber als SL betrachtet geht es hier ja eindeutig ums Spielgleichgewicht, sonst könnte ja jeder Decker als erstes den Host ausknipsen, bzw. seine Sicherheitskonten nach Belieben editieren.
(Viel sinnvoller fände ich sowieso, sich selbst als autorisiertes Icon zu registrieren, und dann eine Weile später wieder ins System zu gehen. Ist viel entspannter...)

"rainmaker" schrieb:

Es ist nur so, so ein Host muß nicht zwangsläufig eine Hauptspeicher besitzen.

Das ist sehr mutig. Jedes System besitzt Speicher, ob der jetzt gekapselt, direkt integriert, ausgelagert oder gesichert ist. Selbst wenn sich der Speicher physikalisch auf einem anderen Kontinent befindet, besteht immer noch eine Verbindung zum BS, wie sollte es auch sonst funktionieren?

"rainmaker" schrieb:

Er kann sein BS von der restlichen Software abtrennne, den HS des BS speziell (auch Hardware mäßig) schützen und so ein Übergriffe oder Manipulation von andern Programmen auf seinem HS (oder Teile seines HS) zu unterbinden.

Jau, das ist möglich, und in vielen Fällen auch sehr nützlich. Was ich vorher eigentlich zum Ausdruck bringen wollte ist folgendes: Jedes System ist angreifbar, und keine Hauptspeicher-Lösung kann mit 100%iger Sicherheit garantieren, dass nicht doch durch irgendwelche Lücken Manipulationen vorgenommen werden.

Aber man kann das Risiko so gut wie möglich minimieren, das hattest Du wohl auch im Sinn.

Zitat

(Viel sinnvoller fände ich sowieso, sich selbst als autorisiertes Icon zu registrieren, und dann eine Weile später wieder ins System zu gehen. Ist viel entspannter...)

Du bist da zum Glück nicht der erste, der es so versucht. Dafür gibt es ein Bestätigen-Utility.

Zitat

Bisher habe ich noch nie gesehen, dass jemand im laufenden Betrieb Teile des OS austauscht, nachdem er sie durchkompiliert hat. Es mag möglich sein, aber es ist ein Risiko. Es gibt immer tausend Gründe, warum ein Programm nicht so funzt, wie es funzen soll, und deswegen gibt es so gut wie niemanden, der seinen Entwicklern (oder seinen Admins, was ja noch schlimmer wäre...) die Erlaubnis geben würde, ein Modul zu verändern, zu kompilieren und gleich wieder ohne vorherige Tests und Absicherungen einzubinden.

Ich gehe davon aus das der Admin nur die fest im BS einkompilieten Sicherheitseinstellungen verändert. Er macht an Änderungen nichts anders, als wenn er Einstellungen an einer Datei ändert. Das Ergebnis im laufenden Betrieb ist kein anderen nur der Weg. Natürlich sollten man sich bei Änderungen an Hosteinstellungen möglichst 100% sicher sein, egal ob durch Ändern eine Konfigkuration in Dateien oder im Quellcode.

Um das mal mit heutigen mitteln zu vergleichen:
Entweder der Admin ändert in einer INI-Datei eine Parameter, oder er tauscht den Werte einer Konstantvariablen im Quellcode aus. Beides kann die gleichen Auswirkungen auf den Hostbetrieb haben.

Zitat

Wenn es ein Log-File gibt, von dem nachher wieder rekonstruiert wird, dann kann man theoretisch dieses File verändern

Es gibt hardwaretechnische Möglichkeiten Daten zu schreiben, die nachträglich nicht mehr veränderbar sind ... Du kannst zwar die Daten lesen aber online nicht mehr verändern. (Unpraktisch, aber ein anschaulicher Vergleich: die Log-Daten werden sofort auf Papier ausgedruckt und beim Hochfahren per OCR eingelesen ...!)

"rainmaker" schrieb:

Ich gehe davon aus das der Admin nur die fest im BS einkompilieten Sicherheitseinstellungen verändert.

Um das mal mit heutigen mitteln zu vergleichen:
Entweder der Admin ändert in einer INI-Datei eine Parameter, oder er tauscht den Werte einer Konstantvariablen im Quellcode aus. Beides kann die gleichen Auswirkungen auf den Hostbetrieb haben.

Ok, gefressen. So meintest Du das...

Ist meiner Meinung nach nicht die eleganteste Methode, und diese Unflexibilität kann meiner Meinung nach auch ein grosser Nachteil sein.

Auf der einen Seite toll, da man jetzt annehmen darf, dass sich ein Angreifer erst den Quelltext in Originalform samt der korrekten Compiler-Einstellungen schnappen muss, bevor er evtl. gefälschte Einstellungen ins System schleusen kann.
Auf der einen Seite steht - wie vorher - das Argument, dass man als Admin halt auf jeden Mist der im eigenen Netzwerk passiert so schnell wie möglich reagieren können muss. Und da ist die Zeit zum Kompilieren und Einbinden schon zu lange. Allerdings ist man relativ schnell fertig, wenn man - wie Du schon sagst - genau weiss, an welchen STellen man was ändern muss.

Allerdings kommt die Geschwindigkeit hier mit der Routine, also ware es besser, wenn man so etwas regelmässig übt, bzw. durch entsprechende Angriffe bereits Erfahrung hat.

"rainmaker" schrieb:

Es gibt hardwaretechnische Möglichkeiten Daten zu schreiben, die nachträglich nicht mehr veränderbar sind ... Du kannst zwar die Daten lesen aber online nicht mehr verändern. (Unpraktisch, aber ein anschaulicher Vergleich: die Log-Daten werden sofort auf Papier ausgedruckt und beim Hochfahren per OCR eingelesen ...!)

Du meinst damit, dass zur Manipulation der betroffenen Log-Datei ein Hardwarebasierter Austausch nötig wäre, sprich:
Man müsste jetzt um das System zu täuschen physikalisch im RZ sein, um manuell die Hardware-geschützte Komponente durch eine gefälschte auszutauschen. (Is allerdings ungleich mehr Arbeit für den armen Runner...)

Siehst Du, jetzt verstehen wir uns. :wink:

Die Informationen über ein Sicherheitskonto müssen nicht an einer Stelle liegen. Es könnte sich um über viele Register, Speicherauszüge und Dateien versträute Informationen handeln, die in sich konsistent sein sollten (Inkonsistenzen erhöhen das Sicherheitskonto selber noch weiter), vergleichbar mit den Informationen einer SIN, die auch nicht durch einfaches änderen einer Datei im Netz verändert werden kann.

Zitat

Das Sicherheitskonto ist ganz sicher kein Wert der in irgendeiner Datei liegt und drauf wartet vom nächstem Decker editiert zu werden.

Das Sicherheitskonto muß ein im Host abgelegter Wert sein.

Zitat

Es schwirren im System eine Menge Sonden-IC herrum die ununterbrochen auf bestimmte Arten von Auffälligkeiten checken.

IC passen da nicht wirklich als Erklärung, da sie regeltechnisch abgehandelt sind. Insbesondere eine Menge Sonden-IC würden in dem Zusammenhang Decking schlicht unmöglich machen.

Mg, Regelhopper.
Dan streich eben das Wort Sonden-IC nd ersetz es durch niedere Überwachungsprogramme. Sowas wie ein besserer Taskmanager vielleicht. Programme die den RAM durchchecken, oder gant einfach die Tatsache, dass eien Fehlermeldung erzeugt wurde.
Kein Decker is perfekt, irgendwan WIRD er eine Systemmeldung erzeugen. Verschiedene Vorfälle erzeugen dann eben verschiedene REaktionen im System.
Es kann also durchaus sein, dass irgendwo im Host gespeichert ist, auf welche Sicherheitssituation wie reagiert wird, das wurde hier ja schon zu Genüge diskutiert
Wobei ich hier sehr für die Not-Readable Disks bin, die man doch innerhalb vonein paar Sekunden austauschen kann. Und ein paar Sekunden sind nicht zuviel, wenn man die Grundeinstellungen des Systems ändern will. Und es ist ja nicht so, als ob das Systemin dieser Zeit schutzlos wäre. Meistens würde das Ding wohl nach einem Systemcrash ausgetauscht werden.
Ja es gibt eine Systemoperation um sein Sicherheitskonto zu analysieren. Unter dieser einen Operation verbergen sich aber eine Menge Abfragen, Analysen und gesunder Metamenschenverstand, durch den man abschätzen kann, wieviel Staub man schon aufgewirbelt hat.
Eine Änderung des Sicherheitskontos: "No way!"
Eine Änderung der Systemparameter eines Hosts/Gitters/usw: Verdammt schwierig - ich würd die Runner in den Konzern eindringen lassen dafür.

lg
Karlotius

Zitat

Es kann also durchaus sein, dass irgendwo im Host gespeichert ist, auf welche Sicherheitssituation wie reagiert wird, das wurde hier ja schon zu Genüge diskutiert
Wobei ich hier sehr für die Not-Readable Disks bin, die man doch innerhalb vonein paar Sekunden austauschen kann.

Not-Readable?

Zitat

Ja es gibt eine Systemoperation um sein Sicherheitskonto zu analysieren. Unter dieser einen Operation verbergen sich aber eine Menge Abfragen, Analysen und gesunder Metamenschenverstand, durch den man abschätzen kann, wieviel Staub man schon aufgewirbelt hat.
Eine Änderung des Sicherheitskontos: "No way!"

Warum nicht? Erstens muß das Konto letztendlich ein fester Wert sein. Zweitens muß er irgendwo auf dem Host liegen. Drittens muß er änderbar sein (writable). Viertens muß er lesbar sein (readable) sonst könnte der Host nix damit anfangen.

Wie löse ich das also halbwegs sinnvoll auf? Erstmal mache ich es so schwierig wie möglich, den Wert zu finden, indem ich ihm wechselnde Systemadressen verpasse. Als nächstes definiere ich das System als solches als readonly (damit hat sich das auch mit dem ändern von Systemstufen), ebenso die Systemsteuerung. In diese Systemsteuerung verankere ich einen Zeitintervall, in dem der Wert des Kontos maximal um 1 abgesenkt werden darf (das erklärt auch ganz hübsch, warum es so lange dauert, bis das Konto nach dem Ausloggen des Deckers noch besteht). Ändert sich das Konto schneller nach unten Aktiver Alarm, alles verfügbare IC in Marsch gesetzt, Shutdown einleiten.

Maske und (in Verbindung mit dem Schleicher) der Entdeckungsfaktor sorgen dafür, daß der Wert des Sicherheitskontos langsamer steigt, indem sie dem System vorgaukeln, der Decker ist a) gar nicht da oder b) jemand ganz anderes.

Elegantes Ausloggen ist zum einen dazu da, Kopfschmerzen zu verhindern, zum anderen entfernt es die Datenspur - also die Spur zwischen Auslog-Punkt und Jackpoint.
Eine tatsächliche Verwischung/Beseitigung aller Spuren kann diese Operation entgegen der Beschreibung nicht leisten, denn dann könnte der Host dem Decker später nicht ein noch nicht auf Null gesunkenes Konto wieder zuweisen.

"Gast" schrieb:

Steigt das Sicherheitskonto langsamer, oder wird die Steigerung im Hintergrund rückgängig gemacht?

Es steigt langsamer. Würde es im Hintergrund rückgängig gemacht, würde zwischenzeitlich IC getriggert.

Zitat

Anders ausgedrückt: Das Matrixsystem klappt in sich zusammen, wenn ein Decker sein Sicherheitskonto einfach runtersetzen kann.

Weißt du, wieviele Nulloperationen ich einen Decker würfeln lasse, während er versucht, im vorgesehenen Zeitintervall sein SK runterzuschrauben, falls er seine Suche nach diesem zufälligerweise lebend abgeschlossen haben sollte?