[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