Sicherheit in der IT und ihre Anerkennung

[Marscel]

Als vielseitig einsetzbarer Vollblut-Softwareentwickler bin ich seit kurzem echt entsetzt. Alleine in den letzten 2 Jahren habe ich Sicherheits-Dinge gesehen und entdeckt, anfänglich kopfschüttelnd, jetzt schon so, dass es mich schlechter einschlafen lässt.

Ich würde nie als Security-Consultant und dergleichen hausieren gehen, von Kryptographie weiß ich, dass das ein Job für ein ganz paar wenige ist, die den wissenschaftlichen Background haben. Andererseits halte ich mich für sehr bewusst, was man zwischen C bis Web-Code alles falsch machen, wie man es ausnutzen und was man dagegen tun kann, wie man Infrastrukturen absichert. Das können viel zu wenige Entwickler wie mir scheint, auch nach sehr viel mehr Dienstjahren und Gehalt. Was man dagegen machen kann, ich weiß es nicht.

Manchmal bin ich neugierig: Bei Bauchgefühl spiele ich mal an der URL herum, probiere Standardpasswörter aus, teste Admins und Entwickler auf ihre üblichen Verdächtigen, oder tippe einfach mal Garbage oder Randwerte in irgendwelche Inputs ein. Es fliegt dabei so unglaublich viel um die Ohren, gerade bei Invidiualanfertigungen oder Billigkomponenten.

Auf einmal sitze ich auf Wissen, total unabhängig voneinander, mit dem könnte jemand mit destruktiven Absichten morgen betroffene Klein- bis Mittelstandsunternehmen faktisch dicht machen und Jobs vernichten. Oder dieses Wissen geschickt verwerten. Ich kann den potentiellen Schaden z.T. genau beziffern. Und es geht dabei stets um Unternehmen/Produkte, die mich persönlich gar nicht betreffen und nur durch Spielereien wie genannt aufgefallen sind.

Aus der Erfahrung in jüngeren Jahren, als man noch lieb und unschuldig war, weiß ich, dass in solchen Fällen Betriebsverantwortliche meist gar keinen echten Draht dazu hatten, was genau eigentlich das Problem ist und was das Ausmaß sein könnte; man hat eine nette Notiz zukommen lassen und gesagt, dass das jemand beheben sollte. Von IT-Menschen kam hingegen tendenziell Trotz und Verachtung zurück, ich erinnere mich nur einmal an Dank. Irgendwann kamen sogar mal wüste Drohungen zurück.

Auf der anderen Seite, wo ich nun selbst ein Unternehmen habe und Verantwortung aufbringen muss, kann ich es nicht verstehen, wie unglaublich fahrlässig und schlampig nach wie vor damit umgegangen wird. Und viel mehr frage ich mich: Warum sollte ich irgendwas berichten, wenn es mich selbst nicht betrifft? Mittlerweile werden zwar Bounties bezahlt, aber nicht von Unternehmen, für die Software nur Mittel zum Zweck ist. Für sowas hätte man kein Geld - und wohl offenbar auch niemanden um das zu fixen, die Erfahrung der ersten Verwertungsversuche. Einerseits will ich angesichts des Schadenspotenial nichts for free herausgeben, sondern wenigstens einen Finderlohnanteil dafür - einschließlich Hinweis, wie man damit umzugehen hat -, andererseits hätte es ein aufrichtiger Mitarbeiter oder Kunde auch kaum verdient, Opfer von Kriminalität zu werden.

Denn: Wenn nun der Zugriff aus Fernasien kommt, und davon muss man ausgehen, dann wird die Hütte brennen. Oder der Konkurrent davonziehen. Auf der einen Seite könnte ich sowas verhindern, auf der anderen Seite hilft das keinem Beteiligten irgendein Problembewusstsein dafür aufzubauen, entsprechende Lücken ernstzunehmen, und der Weißweste ordentlich dafür zu danken. Ich rechne sogar mittlerweile damit, unter Generalverdacht gestellt zu werden zu allem, was seitens der Software im Fortlaufen schief geht, wenn ich einmal namentlich darauf hinweisen würde. Nicht dass ein kleiner Knall vielleicht Wirkung zeigen würde, aber sowas geht zu schnell in straf- und zivilrechtliche Probleme für mich selbst.

Man könnte, wie durchaus branchenüblich zw. Großkonzernen, eine Frist setzen bis man entsprechende Lücke selbst veröffentlicht. Aber ob damit irgendwem geholfen ist? Ich rede nicht von Heapspraying bei Halbmond am Polarkreis, sondern Scriptkidde-artigen Problemen und Unternehmern, die vermutlich nicht den Hauch eines Plans haben.

Diese Thema schneidet stark IT-Sicherheit i.A., das Dilemma als soziale Angelegenheit, aber auch konkret technische Angelegenheiten. Mich würden Beobachtungen und Erfahrungen von Entwicklern/Admins interessieren, die schon ähnliches gefunden haben und trotz der üblen Lage nicht ernst genommen werden.

[Morale]

Sicherheit kostet.
Sicherheit bringt erstmal keinen Mehrwert.
Wenn wir die Gefahr nicht sehen, sieht sie uns auch nicht.
Im Zweifelsfall will uns eh keiner was, wir sind doch kein Mrd. Unternehmen.

So meine Erfahrung.

[del_4901]

Gute Quallitaet taucht bei vielen im Projektmanagement einfach nicht als Metrik auf. Wenn der eine Typ einfach Quantitativ mehr eincheckt aber 10 Andere hinterher die Bugs fixen, taucht es nicht einmal in dessen Zeitmetrik auf. Es wird halt oft nur bis zum checkin geplant.
Wenn die Wasserkoepfe bei mir antanzen und wieder mal eine Aufwandsabschaetzung von mir haben wollen bin ich ganz ehrlich und sage dass ich keine Ahnung hab, wenn ich noch keine Ahnung hab, und ich mich erst reinarbeiten muss.
Wenn mir dann manchmal eine laecherlich kurze Aufwandsabschaetzung gegeben wird, dann mach ich schon das Maul auf und wann ich denn das ganze noch testen soll, und wer hinter mir aufraeumt wenn ich husch husch machen soll. Dann werden die Meissten ganz still.
Am Ende merkt man dann aber auch die Quallitaet, da muss man aber manchmal wirklich stark bleiben, und sich nicht so einfach einlullen lassen.

[The Nemesis]

Firmen investieren erst in Sicherheit, wenn das Kind bereits einmal in den Brunnen gefallen ist. Ganz selten hat man mal Verantwortliche, denen das Thema wichtig ist und die dann auch Geld in die Hand nehmen.
Du siehst m.E. ganz richtig, dass bei Hinweisen for free auch überhaupt kein Sicherheitsbewusstsein aufgebaut wird.
Das Thema ist _jedem_ mit etwas Hirnschmalz bewusst, es gibt da niemanden Unschuldiges in den verantwortlichen Positionen, du musst dir da gar keine Schuldgefühle einreden.

[RattuS]

Ich habe genau die selben Erfahrungen gemacht und stimme meinen Vorrednern zu. Besonders bei prototypischer Projektplanung heißt es oftmals "mach schnell, scheiß auf Sicherheit, es soll ja nur demonstrieren, was es kann" - und daraus wird dann später das finale Produkt, allerdings ohne das "um die Sicherheit kümmere ich mich später". Mach' ich später, mach' ich nie.

Ich bin jedenfalls ein aufrichtiger Kämpfer an der "Security matters"-Front und lass mir nicht verbieten, sicherheitsrelevante Entwicklung durchzuführen. Das gilt natürlich nicht nur für Daten, die den Betrieb selbst angehen, sondern auch verarbeitete Daten von Endverbrauchern.

Dazu folgende Anekdote (selbst erlebt):

Kunden-Datenbank mit verschlüsselten Passwörtern (SHA2/512-Hash + Salt)
Idiot: "Warum können wir die Passwörter nicht lesen? Wir müssen die Passwörter der Kunden kennen, damit der Support am Telefon bei vergessenem Passwort aushelfen kann. Das muss geändert werden."
Ich: "Auf kein Fall. Das verstößt gegen meine beruflichen Grundsätze. <Vortrag über Datensicherheit> Das mache ich nicht so."
Ich wurde dann von diesem Projekt abgezogen und ein Kollege sollte sich dem Problem annehmen. Aber dem kam nicht einmal ein asymmetrischer Ansatz (wie RSA/AES) in den Sinn, sondern er hat die Passwörter am Ende dann einfach Base64 kodiert und dem "Idiot" gezeigt, der das Problem dann als gelöst ansah. ;D
Und der Kollege so: "Die Passwörter stehen nun nicht mehr im Klartext in der Datenbank." :facepalm: :facepalm: :facepalm:

[HajottV]

Hi Marscel,

Dein Text könnte von mir sein. Gerade in der Kryptografie erlebt man so viele Dinge, wo man am Liebsten lachend in die Kreissäge laufen möchte.

Meiner Meinung nach liegt das am Dunning-Kruger-Effekt (http://de.wikipedia.org/wiki/Dunning-Kruger-Effekt): Die meisten Informatiker haben (traurig aber wahr) von Security nicht die leiseste Ahnung und können deswegen den Grad ihrer Inkompetenz nicht erkennen.

Ich habe mich im Studium mit Kryptographie beschäftigt (war Teil meiner Diplomprüfung in theoretischer Informatik), und ich habe die "Kryptografie"-Vorlesung als Hiwi (Kleingruppenübung) betreut, was mich in dem Thema sooooo viel kompetenter macht als meine Kollegen. Defacto ist es aber so, dass ich damit nur qualifiziert weiß, dass ich nichts zu dem Thema weiß. Wenn ich also irgendetwas da mache, dann setze ich die best-practices 1-zu-1 um und weiche nicht einen Nanometer davon ab.

Wenn ich sehe, was meine Kollegen da zum Teil machen, dann rollen sich mir die Zehennägel auf: RSA wird dazu benutzt, um den AES Schlüssel zu kodieren (soweit so gut), aber dann hat der Kollege es nicht auf die Reihe bekommen, auch noch den IV zu kodieren und nutzt daher ECB. :crazy:

Ich wette 100€ darauf, dass meine Kollegen bis heute nicht überprüft haben, ob der alte Webserver gegenüber Heartbleed verwundbar ist. Der neue (meiner) ist es nicht - das habe ich an dem Tag sichergestellt, als die heise-Meldung kam.

Leider ist es wahnsinnig schwierig, jemanden von Dunning-Krugeritis zu heilen.

Daher ist mein Idealismus inzwischen teilweise abgewetzt, weil ich es leid war, ständig den Don Quijote zu spielen. D.h. ich versuche nur noch die neue Software sauber zu halten, da aber konsequent. Bei dem ganzen Legacy-Zeug ist es mir egal: wenn das Ding 1000 Angriffsvektoren hat, dann ist es wurscht, ob noch ein weiterer hinzukommt. Security nachträglich ranzuflanschen hat noch nie funktioniert. Entweder ist sie Teil der Grundkonzeptes, oder sie ist nicht-existent.

[nalye]

Aber dem kam nicht einmal ein asymmetrischer Ansatz (wie RSA/AES) in den Sinn
AES ist symmetrisch (Blockchiffre) ;)

[Exxtreme]

Problem ist halt meistens, dass sich Sicherheit konträr zum Komfort verhält. Das merke ich auch immer wieder beim Mimimi, dass das Einloggen per VPN ins Firmennetzwerk ja soooo umständlich ist und dass das bestimmt vieeeel einfacher geht. Klar wenn ich den SBS per Portforwarding direkt ans Internet klemme dann ja. Nur was dann passiert ... will ich nicht wissen.

[Ectoplasma]

Das merke ich auch immer wieder beim Mimimi, dass das Einloggen per VPN ins Firmennetzwerk ja soooo umständlich ist und dass das bestimmt vieeeel einfacher geht.

Naja, viele Kunden haben eben so gar keinen Plan von Informatik. Die sagen sich: "Wieso so umständlich, der Server weiss doch, dass ich es bin". *gg*

Das ist auch einer der Gründe, warum das Wort "Sicherheit", niemals in einer Spezifikation auftaucht. Es ist einfach kein Thema.

[_CaBaL_]

Usability über Security ist immer das gleiche :freak:

Was ich manchmal an Anfragen kriegen, warum das nicht anders gemacht wird... erschreckend

[Marscel]

Über Security vs. Usability-Sachen will ich hier gar nicht so sehr reden, auch wenn es oft kein wenig unwichtiger wäre.

Eben vielmehr darüber, wie das Verpflichtungsgefühl bei anderen Entwicklern, wie überhaupt die Sachkenntnislage ist, wie sehr die lieben Projektmanager und Geschäftsführer überhaupt ein Bewusstein dafür haben, wie viel Zeit sie bereit sind dafür einzuräumen.

Bei der aktuellen Plötzlich-und-Unerwartet-Aktion habe ich in den zwei verfügbaren Tagen vermutlich ein Drittel der Zeit für Integritäts-Sicherheit aufgewendet, mich vergewissert, dass ich bei HMAC auf dem aktuellen Stand bin und für so viele Aspekte Tests geschrieben, dass ich ein gutes Gefühl dabei habe. Angesichts der Anforderungen hatte ich andere Programmierer hier vor Augen, die nicht ansatzweise das nötige Bewusstsein/Kenntnisse dafür an den Tag gelegt hätten. Nicht, dass ich irgendeinen der Kunden irgendetwas in Sachen Exploitability-Kenntnis in geringster Weise zuschreiben würde, aber ich hätte das nicht anders für mich persönlich verantworten können, wo es um bezifferbares Schadenspotential geht.

Was und warum ich das genau gemacht habe, das versteht außer mir und einem anderen keiner so ganz. Und wirklich Zeit eingeräumt bekommen hätte ich dafür auch nicht. Ich muss mich ja schon äußerst dankbar fühlen, dass mit meinem Einstieg endlich SSL-Sockets und SSH-Tunnel für Plaintextprotokolle mit kritischen Daten durchgesetzt werden konnten, womit man konkurrierenden Anbietern schon voraus ist. Aber auch das kann man faktisch kaum einem brauchbar als wichtig verticken. Ein Zertifikat kostet? Och nöö. Der Browser meckert? Der soll nicht nerven.

[Terrarist]

Wieso nicht Open Source und neue Geschäftsstrategien entwickeln? Oder Schiss in der Öffentlichkeit für iese Codequalität Prügel zu kassieren? :D

[Marscel]

Habe ich, aber aktuell nicht / mache ich / Nein: Weil ich derjenige bin, der Phantasien über Auspeitschen derjenigen bekomme, die grob nachlässig bis gleichgültig beim Thema Sicherheit arbeiten.

[Monger]

Über Security vs. Usability-Sachen will ich hier gar nicht so sehr reden, auch wenn es oft kein wenig unwichtiger wäre.

Eben vielmehr darüber, wie das Verpflichtungsgefühl bei anderen Entwicklern, wie überhaupt die Sachkenntnislage ist, wie sehr die lieben Projektmanager und Geschäftsführer überhaupt ein Bewusstein dafür haben, wie viel Zeit sie bereit sind dafür einzuräumen.

Ich oute mich mal als eben genau einer der Entwickler die mit Security bis zum heutigen Tag nichts ernsthaft am Hut hatten. Es spielt im Alltag einfach keine Rolle: hin und wieder holt man sich mal einen "Security" Experten, hier und da spuckt die Codeanalyse mal Hinweise auf Verstöße aus... alle sind sich einig dass Security wichtig ist, aber so wirklich verstehen tut es keiner.

Ich sehe da drei unterschiedliche Effekte am Werk, alle mit unterschiedlichen Ursachen:

1) Features >> Quality > Security. Viele Projekte beginnen in einem Schwebezustand, wo sie sich ihre Daseinsberechtigung erstmal mit minimalsten Mitteln erstreiten müssen. Zeit und Geld für Qualität und Sicherheit hinzulegen, für ein Produkt von dem man selber eigentlich zu 70% erwartet dass es nie erscheinen wird - das wirkt wie Verschwendung.
Viele Projekte sind sich ihrer selbst so unsicher, dass sie kaum weiter als "feature-complete" denken. Das schlägt sich dann auch in der Weiterbildung und Auswahl an Mitarbeitern nieder: Im Pilotprojekt sitzen regelmäßig nur "Anpacker", Leute die schnell irgendwas lauffähiges zeigen können. Wir nennen solche Leute gehässigerweise "Demo-Entwickler".

2) Hilflosigkeit. Security ist ein Cross-Cutting Concern so wie Logging. Schon alleine zwei Teams an einen Tisch und sich auf eine gemeinsame Logging Strategie einigen zu wollen, führt regelmäßig zu wilden Diskussionen und bösem Blut.
Mein Verdacht ist, dass zumindest bei uns diese Grundsatzdiskussionen entstehen, weil die Architekten immer noch ein sehr starres, monolithisches Verständnis von Architektur haben. Logging o.ä. wird dort nicht etwa an einer Stelle implementiert, sondern an ALLEN Stellen die loggen wollen (die Imkehrung des DRY Prinzips). Security ist da auch etwas was immer und immer wieder an der spezifischen Stelle implementiert wird, statt z.B. Authentifizierung als Service rauszuziehen. Das macht es quasi unmöglich, das Fachwissen an einer Stelle zu konzentrieren.

3) Mystik. Was unsere "Security Experten" machen, hat meiner Meinung nach oft mehr mit Schamanismus zu tun als mit Sicherheit. Äußert sich z.B. darin, dass Aspekte einer Software aufwändig verschlüsselt werden, der Schlüssel aber untrennbar von der Installation ist. Was nützt mir ein Sicherheitsschloss, wenn ich den Schlüssel nur unter der Türmatte deponieren darf?
Unser Security Experte empfiehlt, zentrale Komponenten von C# auf C++ umzuschreiben, weil es für C++ angeblich kein Reverse Engineering gibt. Security by Obscurity. Dieses gefährliche Halbwissen wirkt als Beruhigungspille super. Alle fühlen sich sicherer danach, und sobald man selber kein Problem mehr sieht, werden Angreifer das schon auch nicht tun.

Mein Eindruck ist, dass Security viel zu oft nur so verstanden wird, dass man halt die Mauern seiner Trutzburg höher zieht und die Tore mit zusätzlichen Holzplanken verstärkt. Es wird selten hinterfragt, warum der Angreifer ausgerechnet zu einem selbst will, und ob eine vollgestopfte Schatzkammer nicht automatisch Begehrlichkeiten weckt.

Mit anderen Worten: muss die eigene Anwendung wirklich so viel wissen? Ein Angreifer kann nur erfahren was die Anwendung selber weiß. Brauche ich wirklich elevierte Rechte? Muss ich unbedingt über Netzwerkports kommunizieren? Wie kann ich Passwörter zur Authentifizierung benutzen, ohne sie mir selbst merken zu müssen?

Dieses selbstkritische Verständnis, dass man Angreifern oft damit die Tür öffnet indem man selber sich wie einer verhält, das wird oft ungern gehört. Die eigene produzierte Software hat ganz automatisch immer eine höhere Legitimation als die der Konkurrenz. Man gehört ja zu den "Guten", der Kunde kann einem ruhig vertrauen dass man verantwortungsvoll mit seinen Daten umgeht.

Security ist in meinen Augen daher letztendlich ein zutiefst menschliches Problem. Wenn man außer bei wenigen Leuchttürmen Security wirklich in der Entwicklungskultur verankern will, muss man diese erstmal auf den Kopf stellen. Das ist ein schmerzhafter Prozess, noch viel mehr als beim Thema allgemeine Produktqualität.

[Demirug]

Unser Security Experte empfiehlt, zentrale Komponenten von C# auf C++ umzuschreiben, weil es für C++ angeblich kein Reverse Engineering gibt.

Das ist nicht dein Ernst? Ich sage nur mal IDAPro. Klar man muss Assembler lesen können aber das ist nun wirklich nicht das große Problem. Ich habe damit schon selbst C/C++code analysiert weil ich Informationen brauchte die nicht öffentlich zugänglich waren.

Ich hoffe mal euer Security Experte ist nicht für Systeme zuständig die mit persönlichen Informationen zu tun haben.

[RattuS]

Klar man muss Assembler lesen können aber das ist nun wirklich nicht das große Problem.
Genau dieses Thema hat Monger ja angesprochen. Ein größeres Hinderniss wird oftmals schon als ausreichende Schutzmaßnahme angesehen. Und zugegebenermaßen trifft das auch für die meiste Software zu. Reflection von .NET Assemblies ist nun mal erheblich leichter zu analysieren als ASM. Natürlich sind solche Maßnahmen nicht zielführend, wenn man sich vor der weltweiten Elite schützen muss, aber zum Absichern gegen das naive Reverse Engineering der unmittelbaren Feinde genügt es doch oder? "Solange es Schlösser gibt, gibt es Schlossknacker." Sicherheit ist nun mal relativ.

Ich bin auch kein Krypto-Experte, aber wie im Eingangsbeitrag beschrieben geht es ja auch viel mehr um das generelle Verständnis für Sicherheit - ein Gefühl dafür zu haben, was eine tatsächlich ausnutzbare Angriffsfläche ist. Es den Angreifern deutlich schwerer zu machen, ist also zumindest ein Anfang. Ob man allerdings allein deswegen Komponenten umschreiben sollte...

[Marscel]

Unser Security Experte empfiehlt, zentrale Komponenten von C# auf C++ umzuschreiben, weil es für C++ angeblich kein Reverse Engineering gibt. Security by Obscurity.

Was ist das denn für ein Scharlatan? Vielleicht sollte ich mich doch Security-Expert nennen, geschützt ist der Begriff ja nicht. Vermutlich gehts hier aber auch um DRM, wie sich das liest.

Das allerbilligste Prinzip: Input ist immer böse. Wenn ich mir meine gefundenen Lücken angucke, wenn man sich vermutlich die Hälfte aller Security Advisories durchliest, dann wäre das alles mit diesem einfachen Grundsatz vermutlich nie passiert. Das kann doch keinem Entwickler zu schwierig oder zu lebensfern sein.

[Monger]

Natürlich sind solche Maßnahmen nicht zielführend, wenn man sich vor der weltweiten Elite schützen muss, aber zum Absichern gegen das naive Reverse Engineering der unmittelbaren Feinde genügt es doch oder? "Solange es Schlösser gibt, gibt es Schlossknacker." Sicherheit ist nun mal relativ.

Es gibt viele Sicherheitsstrategien. "Ein bisschen sicherer" halte ich oft für trügerisch - eben gerade weil man den Angreifer nicht kennt.

Um mal bei der Analogie zu bleiben: das beste Schloss ist wertlos, wenn man den Schlüssel unbewacht rumliegen lässt. Oder neben der supergesicherten Tür ein offenes Fenster ist. Manchmal ist es besser die Tür komplett auszuhängen, damit die Wache wenigstens einen Überblick über den gesamten Gang hat, und Türen in wenig benutzten Gängen komplett zuzumauern.

Wie gesagt: ich sehe die Tendenz bei Security, dass man gerne in Mauern und Türen denkt, und weniger in Begriffen wie Überwachung (aka Transparenz und Standardisierung). Wenn es nur einen einzigen Spezialisten gibt, der alle paar Monate mal im Tresorraum nachschaut ob da vielleicht gebuddelt wurde, dann hilft das halt auch nicht.

Was ist das denn für ein Scharlatan? Vielleicht sollte ich mich doch Security-Expert nennen, geschützt ist der Begriff ja nicht. Vermutlich gehts hier aber auch um DRM, wie sich das liest.

Ja, DRM spielt da eine ganz entscheidende Rolle. DRM und Security wird hier leider oft synonym betrachtet, obwohl das ja wie in diesem Fall eher das Gegenteil bedeutet.