[tapg] Security Policy
Martin Schitter
ms at mur.at
Di Apr 15 15:38:10 CEST 2014
geschätzte mur.at-professionalisten!
ich verspüre zwar einiges mitleid mit euch, wenn ihr da momentan mit
diesen geschichten unnötige arbeit aufgeladen bekommt -- es gibt ja
wirklich wichtigeres und nützlicheres zu tun! --, aber ich bin auch
nicht ganz zufrieden damit, wie man das alles von mur.at aus nach außen
kommuniziert.
was mir dran am wichtigsten ist, betrifft die frage, ob man hier
wirklich nur ganz 'technokratisch' jenen bereinigungsschritten folgt,
die auch andere ISPs durchziehen, oder ob man wirklich was daraus lernt?
will sagen, die ganze geschichte zeigt uns doch wunderbar, dass
kryptografie alleine überhaupt nicht genügt, sondern eher die
angriffsvektoren sehr stark focusiert. gewählt werden dabei ständig
ansätze, die außerhalb der eigentlichen reflexion liegen bzw. niemandem
auf den ersten blick ins auge stechen. im falle der verschiedenen
openssl-kompromitierungen warene es noch reine software fehler, aber das
ganze lässt sich im zusammenspiel mit verbreiteter hardware noch vil
komplizierter gestalten. es erscheint mir daher wesentlich vernünftiger,
diese prinzipielle verwundbarkeit vielmehr zur kenntnis zu nehmen --
ungefähr so, wie unfälle in kernkraftwerken nicht wirklich durch
technischen vorsichtsmaßnahmen völlig in den griff zu bekommen sind --
und statt dessen die frage der technikgläubigkeit, blindes vertrauen in
immer koplexere lösungswerzeuge und die gar zu einfach umlegung sozialer
mechanismen auf eine technische antworten zu thematisieren.
aber, damit mag ich in meinen erwartungen und forderungen vielleicht
wieder ein wenig zu sehr über das ziel hinausschießen. bleiben wir also
vielleicht besser auf der ebene der ganz realen technischen
sicherheitsinfrastruktur, die man sich angesichts solcher bedrohungen
unbedingt erwarten würde:
* die einzigen akteure im netz, die spuren von heartbleed-angriffen
eindeutig identifizieren und rekonstruieren konnten, haben das an hand
von network-traffic-analysen geschafft. ich glaube, dass dieser ebene
immer mehr bedeutung zukommt. gute angriffe und sicherheitslücken
entdeckt man kaum mehr in den logfiles, sondern nur in beobachtenden
systemen, die völlig unabhängig davon arbeiten. gibt's also mittlerweile
bereits snort od.ä. bei mur.at? wenn nicht, wofür es auch seine guten
gründe geben dürfte, sollte man das auch ganz offen kommunzieren, damit
die user sich sich zumindest nichts falsches von den hiesigen
beschränkten möglichkeiten erwarten.
* ein wirkliches problem an sicherheitslücken, die vor allem
zugangsdaten und passwörter erspähen, liegt auch darin, dass die
entsprechenden verwaltungsstrukturen immer zentralistischer bzw. größer
werden. leider betrifft das nicht nur die ganz großen global player,
sondern durchaus auch ganz kleine amateur-mitspieler wie mur.at. es ist
einfach die 'rationalisierung' von authentifizierungsmechanismen, die
das ganze derart fatal werden lässt. wenn man hier wirklich was ändern
will, muss man vermutlich auch bewusst einen schritt weg von
personengebunden accounts, hin zu kleineren rollenbasierten
authentifizeriungsmechanismen gehen. noch wichtiger dürfte aber eine
eingrenzung der tatsächlichen technischen wirkungsräume sein, damit
entsprechende kompromitierung wenigstens vernünftig nachvollzogen und
rekonstruriert werden kann. um kleine nginx basieren container u.ä.
fürhrt also wirklich kein weg herum(!). alles andere ist unter den
gegenwärtigen verhältnissen meiner ansicht nach bereits fast schon als
fahrläsig, zumindest aber nicht mehr vorbildlich einzustufen.
ich lass mich darüber derart kritisch aus, weil ich wirklich den
eindruck habe, dass heartbleed und co. für einfache nutzer der hiesigen
sytsteme keinen wirklich großen handlungsbedarf mit sich bringen.
wirklich herausfordernd bzw. als neuerliche warnung zu verstehen sind
sind sie dagegen für infrastrukturbetreiber, die mit ihrer
moedellierenden technischen wahl der mittel in wahrheit den useren fast
jede entscheidung faktisch abnehmen/vorgeben, darüber hinaus aber auch
eine nicht zu unterschätzende rolle als multiplikatoren entsprechenden
wissens bilden. und in diesem sinne finde ich es schon ziemlich traurig,
wo da mur.at herumgrundelt.
um es an drei beispielen konreter festzumachen:
1.
Am 2014-04-15 13:39, schrieb renatn:
> mmmh, einfach umformulieren, zb
> Passwörter sollten (oder dürfen) unter keinen Umständen an Dritte weitergegeben werden.
was bedeutet das im zusammenhang mit einem smartphone bzw. irgendwelchen
cloudservices, die vermittelnd mail abholen und verwalten?
angesichts der tatsache, dass die herkunft jener 18 mil. gehackter
accounts weiterhin sehr nebulös erscheint, lässt sich diese frage eben
vermulich kaum mehr ganz so einfach abhandeln oder fassen.
es könnte also tatsächlich notwenig sein mail-zugriff von anderen
services bzw. authentifizierungsebenen zu trennen, oder aber den usern
die möglichkeit einzuräumen für derartge besonders fragliche anwendungen
weniger mächtige spezielle passwörter zu generieren, so wie das viele
von uns mit zur spam-vermeidung mit '+'-anschiften bei e_mail-angaben
machen. aber, dass sind nur ad hoc vorschläge, um die richtung grob zu
skizzieren.
2.
Am 2014-04-14 21:46, schrieb Jogi Hofmüller - NOC:> Liebe Leute,
> Weil einige meinten,wir sollten das auch weitergeben (haben wir ja eh,
> aber egal): im PDF vom BKA ist ein Link zur Überprüfung, ob die eigene
> E-Mail-Adresse vom Identitätsdiebstahl betroffen ist. Der Link:
> https://www.sicherheitstest.bsi.de/
das ist zwar sicher sehr lieb gemeint -- ich gehöre ja schließlich auch
zu denen, die das entsprechende attachment ganz bewusst nicht geöffnet
haben -- aber, wie verträgt es sich mit dem problem digitaler
fingerprints, vor denen im rahmen der snowden-veröffentlichen erst
kürzlich recht nachdrücklich gewarnt wurde? wollen wir wirklich
massenhaft unsere maschinen mitsammt der zugehörigen anschrift
polizeilich registrieren lassen?
3.
Am 2014-04-10 22:41, schrieb Jogi Hofmüller:
> Reini hat mich drauf Aufmerksam gemacht, dass der Bug - nicht wie ich
> ursprünglich schrieb seit ein paar Monaten - seit 2 Jahren im Umlauf
> ist.
mittlerweile wissen wir wohl alle ein bisserl mehr über die
tatsächlichen hintergründe dieser lücke. die ganze aufregung darum ist
wohl auch nur deshalb so groß, weil offenbar beteiligte akteure bereit
waren, die 'eigene sicherheit' bzw. nationale interessen aufs spiel zu
setzten, um sich in anderen fragen einen vorteil/-sprung zu verschaffen
-- sollten alternativere mittel wie pgp/gpg ähnliche schwächen zeigen
(was man sinnvollerweise annehmen sollte!), würde man wahrscheinlich
ganz ruhig darüber hinwegschreiten. wirklich verwundern sollte es uns
jedenfalls nicht. es spiegelt nur einen ziemlich traurigen verfall
wieder, den wir ohnehin alle seit jahren beobachten können. ich erwarte
mir also von niemanden mehr große wunder, wenn es um tatsächlich
glaubwürdige lösungsansätze und alternativen geht, aber ich würde mir
zumindest doch wünschen, dass man in kritischen gesellschaftspolitisch
relevanten nischen bzw. freiräumen der kreativen reflexion, die dinge
nicht ganz so leichfertig und ausschließlich nur nach technokratischzen
gesichtspunkten bzw. gar zu vereinfachten mustern des
verlautbarungsjournalismus und der sofortigen dementis tatsächlich
verantwortlicher zu kommunizieren versucht. da ist es vielleicht fast
besser, wenn man nicht gar zu viel auflebens darum macht, und die
einzelnen user selbst ein kritisches bild von der sache bilden lässt.
alles liebe!
und bitte akzeptiert meine etwas abgehobenen ansprüche, auch wenn ich
momentan nicht in eurer haut stecken möchte, um all diesen widerlichen
militär-müll ganz pragmatisch abzuarbeiten.
martin
Mehr Informationen über die Mailingliste Tapg