Home      Themenübersicht / Sitemap      Notizen      Webmaster      

Aus den sehr empfehlenswerten Secorvo Security News - Ausgabe Januar 2014:

Skurrile Welt

Es ist schon eine eigenartige Entwicklung, an die wir uns in den vergangenen Jahrzehnten gewöhnt haben.

Inzwischen erfahren wir fast täglich in den Nachrichten von erfolgreichen Angriffen auf IT-Systeme. Der ebenso vorhersehbare (wie wirkungslose) politische Reflex: ein Sicherheitsgesetz, das Unternehmen verpflichten soll, Vorfälle zu melden. Dabei dürfte in den weitaus meisten Fällen mindestens ein sicherheitsrelevanter Fehler in einer genutzten Software mitursächlich gewesen sein. Die Adressaten der Vorwürfe und politischen Maßnahmen sowie die Leidtragenden der wirtschaftlichen Folgen sind jedoch in der Regel die Opfer: nicht der Hersteller der fehlerhaften Software steht am Pranger, sondern der Anwender – und sei es, weil er ein Update nicht eingespielt hat.

In anderen Branchen wäre so etwas unvorstellbar: Würde man den Fahrer eines Autos nach einem Achsbruch verurteilen, weil er nicht umgehend auf eine fehlerärmere Achse des Herstellers „upgedatet“ hat? Ihm zum direkten Schaden auch noch den des Reputationsverlusts auferlegen, anstatt den Achshersteller beim Namen zu nennen – und ihn mit Schadensersatzforderungen zu konfrontieren?

Während Verbraucherrechte ständig ausgeweitet werden stiehlt sich die Software-Branche bei Sicherheitsmängeln ihrer Produkte seit Jahren aus der Verantwortung.

Die Wurzel des Übels liegt allerdings tiefer. Dem Berufsstand des Software- und Webanwendungsentwicklers liegt bis heute keine einheitliche Berufsqualifikation zu Grunde. In der Praxis dominieren nicht selten branchenfremde Quereinsteiger, und in den existie- renden Berufsausbildungen spielen Sicherheitsaspekte bei der Soft- ware-Architektur und der Kodierung nicht einmal eine Nebenrolle.

Wenn wir sichere Software wollen, brauchen wir entsprechend qualifizierte Entwickler – und Zertifikate. Damit könnte sich „Software made in Germany“ sogar zu einem Qualitätssiegel entwickeln. Bis dahin ist es allerdings noch ein steiniger Weg

 

Lausige Software

Letzte Änderungen: Feb. 2014

Zu einem verwandten Thema, hier ein neuer Artikel zu den dümmsten Ideen der Computer-Sicherheit.

 

Der Wahn nach Features

Philipp Schaumann, Christian Reiser, Sommer 2004

Im Original veröffentlicht in der Computerwelt Österreich, Frühjahr 2004

Die Frage „Warum kann eine Frau nicht so sein wie ein Mann?“, die sich Mr. Henry Higgins im Musical My Fair Lady stellt, macht unser Leben spannend. Die Frage „Warum kann ein Computer nicht so bedienungsfreundlich, zuverlässig und sicher sein wie eine Stereoanlage“ aber macht unser Leben sicher nicht spannend sondern nur schwer.

Vor 25 Jahren haben Branchenkollegen ihren Kunden erzählt, dass Computer irgendwann einmal so leicht zu bedienen sein würden, wie Telefone. Auch wenn sie es wahrscheinlich nicht so gemeint haben, sie hatten recht. Zumindest Mobiltelefone sind mittlerweile so kompliziert wie Computer.

Link-Konventionen:
Fette Links öffnen ein fremde Seite in einem neuen Fenster
Blau hinterlegte Links bleiben auf der sicherheitskultur.at

Doch wie entsteht dieser Trend, dass elektronische Geräte im Allgemeinen und Computer im Besonderen immer komplizierter zu bedienen sind, statt dass sie benutzerfreundlicher werden?

Zu einem gewissen Teil sind wir alle schuld; alle, die einen Computer nutzen, und sich über die Jahre mit schlechter Software abgefunden haben. Es gab Zeiten, wo wir es akzeptiert haben, dass sich unser Computer mindestens einmal täglich mit der himmlischen Farbe Blau am Bildschirm verabschiedet hat. Und wir haben uns auch damit abgefunden, dass wir für die Installation neuer Software auf unserem Privat-PC einen "Wissenden" aus dem Bekanntenkreis mit einem Essen oder Bier bezahlen mussten, weil ein Normalsterblicher dazu oft nicht in der Lage ist.

Der "Wissende" aus dem Bekanntenkreis hat sich längst damit abgefunden, dass er sich mit seiner Hilfestellung bei den Freunden und Bekannten auf ein sehr gewagtes Spiel einlässt. Wir haben uns nämlich auch damit abgefunden, dass bei der Installation neuer Software plötzlich ganz andere Programm-Pakete nicht mehr funktionieren oder ihre Parameter verstellt sind. So öffnet nach der Installation eines neuen Webbrowsers manchmal die Musikdatei nun in einem anderen Programm als dem gewohnten. Das ist etwa so, als würde beim Auto der Einbau eines Autoradios die Einspritzpumpen des Motors verstellen.

Auch die Chefs großer Firmen haben ihren Teil zu dieser Situation beigetragen. Sie haben sich nämlich schon längst damit abgefunden, dass sie viel Geld für Help-Desk und Benutzer-Support ausgeben oder ihre Mitarbeiter viel unproduktive Arbeit mit den Computern haben.

Aber wieso hat die Software-Industrie dem nicht entgegengewirkt? Wieso hätte sie sollen? Über Jahrzehnte war es immer nur wichtig, möglichst schnell am Markt zu sein und möglichst viele neue Features anzubieten. Egal, ob die Produkte zuverlässig funktioniert haben und egal, wie leicht Benutzer damit umgehen konnten. Außerdem ist es für Software-Entwickler viel spannender, neue Funktionalität zu bauen, als bestehende Systeme stabil, sicher und benutzerfreundlich zu machen.

Wahrscheinlich gehören Sie zu dem sehr hohen Prozentsatz an Computerbenutzern, die für ihre Texte WinWord verwenden. Aber auch wenn sie schon zu den wenigen gehören, die eine Alternative, wie zum Beispiel StarOffice oder OpenOffice, einsetzen, so gilt das selbe: Wie viele Features ihres Textverarbeitungsprogrammes verwenden sie und wie viele kennen sie überhaupt? Der durchschnittliche Anwender nutzt 15% der Features, die restlichen 85% bezahlt er nur.

Wie wäre es zur Abwechslung mit einem Mobiltelefon, mit dem man nur telefonieren und vielleicht noch SMS empfangen und schicken kann? Das müsste extrem leicht zu bedienen sein, und auch noch viel weniger kosten. So etwas können Sie aber nirgends kaufen, angeblich weil es keiner verlangt.

Wie wäre es zur Abwechslung mit einem Gerät, mit dem man ausschließlich Mails lesen und schreiben kann? So etwas gibt es. Über ein eingebautes Handy werden Mails geholt und versendet, aber man kann nicht damit telefonieren. Es ist ja Blackberry, das Gerät, das nur für E-Mails da ist, und nicht einmal für Viren. Interesse?

Konsumenten sind mächtig und wir sind alle Konsumenten von Software, egal ob zu Hause für den Privat-PC, oder im kleinen oder großen Unternehmen. Nur wenn wir benutzerfreundliche, zuverlässige und sichere Software verlangen, werden wir sie auch irgendwann bekommen - hoffentlich.

 

 

2016: Unterstützung für die Idee der Haftung für Software-Fehler auch von Expertenseite: ENISA-Chef fordert Produkthaftung für Hard- und Software

 

Wie erzeugt man Qualitäts-Software?

1. Sichere Programmiersprachen

Dass das Programmieren so schrecklich kompliziert sei ist ein schwaches Argument für schlechte Software. Fehler wie Buffer Overflow, das häufigste Sicherheitsproblem, sind absolut vermeidbar. Wir müssen nur endlich aufhören, Sprachen zu benutzen, die keine Überprüfung auf Bufferlänge, strenge Überprüfung der Typen von Variablen oder unstrukturiertes Programmieren erlauben.

2. Fehlerarmut und Sicherheit als Designkriterien

Das nächste Problem ist, dass bei der Software-Entwicklung die Konzepte für fehlerarme und sichere Software nicht berücksichtigt werden. Bei einem Software-Projekt muss Sicherheit und Qualität von Anfang an im Design eingeplant werden.

3. Weg vom einsamen Programmierer

Eine der Techniken ist Peer-Review und Code Walkthru. D.h. zwei Kollegen sitzen zusammen und der eine erklärt dem anderen Zeile um Zeile sein Programm. Das bringt ganz viel an Verbesserungen (oft sieht man beim Erklären selbst sofort, welche falschen Überlegungen man angestellt hat).

Andere Techniken der Programmentwicklung sind "Team Software Process" (TSP) und "Personal Software Process" (PSP). In Tests wurde gezeigt, dass solche Programmiertechniken, speziell die Abkehr vom Konzept des einsamen Programmierers, der mit koffeinhaltigen Getränken und Pizza in langen Nächten die Programme erstellt, den oben erwähnten Faktor 10 in Bezug auf Fehlerarmut erreichen können.

4. Sinnvolles und effektives Testen

Nur ganz wenige Firmen haben ein vernünftiges System, um Software zu testen. Meistens läuft es immer noch so, dass der Programmierer selbst sein Programm testet und der ist derjenige, der dafür am schlechtesten ist. Er testet nämlich genau die Programmteile, mit denen er sich am meisten beschäftigt hat und vermeidet die etwas dunkleren Pfade in seinem Programmdschungel, denn da fürchtet selbst er sich. Das sind aber später oft genau die Pfade auf denen die Anwender wandeln und in jede Fallgrube hineintappen werden.

Der nächste Schritt ist dann unabhängiges Testen und zwar am besten von Anwendern, die das Programm so nutzen, wie das ein Buchhalter wirklich tut, nicht so, wie ein Programmierer glaubt, dass ein Buchhalter das Programm benutzen wird. Dabei unterscheiden manche Firmen zwischen "White Hat"- und "Black Hat"-Testen. Die eine Gruppe hat vollen Zugang zur Design-Dokumentation, die andere weiß nur, wie das Programm zu bedienen ist. Jede Gruppe findet andere Fehler.

Man weiß heute, wie man durch andere Programmier- und Test-Techniken die Fehlerhäufigkeit um einen weiteren Faktor 10 drücken könnte (dann wären wir schon bei einem Faktor 100).

Mehr Details finden sich weiter unten im Joel Test

Haftung und Gewährleistung für Software !

Im Original veröffentlicht in der Computerwelt Österreich, Sommer 2004

Philipp Schaumann, Christian Reiser

Computerwelt, 3.4.2025: Software-Unternehmen zu 150.000,- Schadenersatz verurteilt. - Produktionsausfall von 5 Tagen aufgrund von Daten-Beschädigung durch diese Software.
Kann das auch heute schon passieren? Leider nein!

Die Anwender von Software, insbesondere Firmen, haben sich längst daran gewöhnt, dass jede Software Fehler hat, und dass diese Fehler auch sicherheitskritisch sein können. Laut dem Computer Emergency Response Team (CERT) steigen die Sicherheitsprobleme aufgrund von fehlerhafter Software exponentiell. Und die Zeit zwischen der Entdeckung eines Sicherheitsproblems und entsprechenden Angriffstools wird immer kürzer.

Die Software-Industrie bietet zur Fehlerbehebung immer wieder so genannte Patches an. Das sind Software-Teile, die die bestehenden Fehler ausbessern sollen. Leider sind auch diese Patches nicht immer fehlerfrei oder haben unbekannte Nebeneffekte. Daher müssen vor einer an sich schon zeitaufwändigen Installation der Patches diese erst auf Testsystemen ausprobiert werden. Diese Aufwände werden bei der Betrachtung einer Total Cost of Ownership (TCO) fast nie berücksichtigt.

Berechnet man die Kosten von Software, so sind neben dem Anschaffungspreis noch folgende Komponenten zu betrachten:

  • Kosten des Wartungsvertrages
  • Kosten der Administration und des Einspielens von Patches
  • Kosten des Testsystems und der Tests von Patches
  • Kosten von Rollout-Software wie zum Beispiel SMS oder onCommand
  • Kosten der Stillstände aufgrund von Fehlersuche und Fehlerbehebung
  • Diverse Folgekosten

Betrachtet man die damit verbundenen Summen, könnte fehlerarme Software gern in der Anschaffung teurer sein.

Aus den Reihen der Software-Industrie hört man immer wieder, dass Haftung für Software oder durch Software verursachte Schäden nicht möglich sei, weil es unmöglich sei, fehlerfreie Software zu erstellen. Es ist wahrscheinlich auch richtig, dass gänzlich fehlerfreie Software nicht möglich ist, aber ebenso wenig ist es möglich, ein fehlerfreies Flugzeug zu bauen. Aber die Flugzeug- und auch die Automobilindustrie testen ihre Produkte so gut, dass die Versicherungen sie mit einer akzeptablen Prämie gegen die Haftungsschäden und die Kosten von Rückrufaktionen versichern. Davon ist die Softwareindustrie weit weg, warum eigentlich?

Warum ist Software so oft fehlerhaft?

Software wird von Menschen geschrieben, und natürlich ist irren menschlich. Allerdings sind Mechanismen bekannt, wie diese menschlichen Irrtümer verringert und zum größten Teil verhindert werden können.

Zunächst ist es für ein Team von Programmierern sehr hilfreich, wenn sie von Anfang an wissen, was sie programmieren sollen, das heißt, dass sie eine eindeutige und während der Zeit der Entwicklung unveränderte Spezifikation haben. Alle späteren Änderungen bringen zusätzliche Fehlerquellen.

Aber es gibt auch andere Hilfsmittel für die Erstellung von fehlerarmer Software. Allein die Auswahl der richtigen Programmiersprache kann den Fehleranteil um einen Faktor 10 verringern. Zum Beispiel durch Sprachen, die strukturierte Programmierung fordern, und die Konsistenz von Datenstrukturen überprüfen.

Der heute häufigste Fehler ist der so genannte Buffer-Overflow. Es gibt aber Programmiersprachen, in denen solche Buffer-Overflows nicht möglich sind. Auch der Mechanismus des "strong typing" hilft, indem überprüft wird, dass jedem Speicherplatz nur Werte aus dem für ihn gültigen Wertebereich zugeordnet werden. Und saubere Strukturen in den Programmen erleichtern deren Verständlichkeit und verhindern Denkfehler.

Da sich nie alle Fehler verhindern lassen, müssen die restlichen durch Testen gesucht und möglichst viele der Fehler gefunden werden. Dazu ist gründliches und gut organisiertes Testen nötig. Das heißt aber, dass jemand anderes als der Programmierer selbst testen muss. Im Kasten werden verschiedene Testmethoden beschrieben.

Das Problem ist aber viel grundlegender. In der Regel werden Konventionalstrafen auf verspätete Auslieferung von Programmen gesetzt, oder die Zeit zum Markt als wichtigstes Kriterium gesehen. Es lässt sich aber jedes Programm in beliebig kurzer Zeit schreiben, einzig die Qualität und Sicherheit wird reduziert. Es ist daher essentiell, dass die Software-Qualität zum Abnahme-Kriterium wird.

Eine alte Ingenieursweisheit lautet: "Möchten Sie das Produkt billig, schnell oder gut. Bitte wählen sie höchstens 2 der Kriterien".

Aber wieso sollten Software-Firmen mehr Aufwand in die Fehlersuche stecken, der Kunde macht es sowieso gratis.

Was kann der Software-Benutzer machen?

Eigentlich sollten die Benutzer von Software mit der derzeitigen Situation ausreichenden Leidensdruck haben, um die Auswahl ihrer Software nach Qualitätskriterien zu treffen. Die folgenden Schritte helfen dem Softwarekunden, zu qualitativ hochwertiger Software zu kommen:

  • Bei Programmieraufträgen von vornherein genau definieren, welche Funktionalität erfüllt werden muss.
  • Bei der Auswahl der Software beziehungsweise bei Ausschreibungen die Qualität als Kriterium definieren.
  • Schon bei der Spezifikation auch eine Testspezifikation und einen Testplan erstellen.
  • Den Aufwand (Geld und Zeit) für Tests einplanen.
  • Die Durchführung der Tests (eventuell von jemand Unabhängigen) als Abnahmekriterium aufnehmen.
  • Konventionalstrafen aushandeln für mangelnde Qualität.
  • Realistischen Zeitplan aufstellen.
  • Anwender in Abnahme- und Qualitäts-Tests einbeziehen.
  • Unabhängige Tests der Sicherheitskriterien.

International gibt es erste Ansätze in Richtung Haftung für Software, speziell bei Regierungsprojekten in den USA. Da können Erfahrungen gesammelt werden, die hoffentlich irgendwann in ein Gewährleistungs- und Haftungsgesetz für Software führen. Es gibt ähnliche Vorschläge, über Haftung auch die Probleme im Bereich Phishing, bzw. den in den USA schlimmen "Identity Theft" anzugehen. In den USA ist es möglich, Kredite im Namen anderer Personen aufzunehmen, wenn ich deren "Social Security Number" kenne, die Sozialversicherungsnummer. Hintergrund ist, dass die USA ja außer dem Führerschein derzeit (noch) keine Ausweispapiere mit Lichtbild kennen. Und einen gültigen Führerschein bekomme ich mittels einer leicht fälschbaren Geburtsurkunde (leicht mit Textverarbeitung zu erstellen).

copyright natürlich bei userfriendly.org

Hier noch ein interessanter Link zur Website von Bruce Schneier. Er schreibt hier über die spezielle Problematik von Softwarefehlern in Wahlcomputern und hier noch ein Artikel aus news.com zum Thema Haftung und weitere Artikel zum Thema Haftung auf dieser Website.

 

Humoriges zum Thema "lausige Software" in einer ganz alten legendären EDV/IT-Persiflage: Real Programmers Don't Use Pascal (Pascal ist eine Programmiersprache, die dafür entwickelt worden war, dass weniger fehlerhaft programmiert wurde, nicht so schlampig wie heute fast überall mit der Programmiersprache C). Die deutsche Version heißt Echte Programierer meiden PASCAL (PDF, 220 KB).

 

Aktualisierung August 2010:
Ein interessanter Artikel mit einigen guten Punkten: Understanding the market for buggy software.

 

Aktualisierung Aug. 2011:
Ein interessanter Artikel So sue me: are lawyers really the key to computer security? sieht Licht am Ende des Tunnels: in den USA stellt die FTC (Federal Trade Comission, die Behörde gegen den unlauteren Wettbewerb) eine wichtige Kraft in diesem Bereich dar, da sie (korrterweise) davon ausgeht, dass das Ausliefern von noch-fehlerhafter Software einen Wettbewerbsvorteil verschaffen kann, weil sichere Software immer teurer sein wird. Sie bestraft derzeit Unternehmen sehr kräftig wenn deren Software oder deren IT-Infrastruktur zu unsicher war und die Sicherheitsverletzungen geführt hat. Sie macht z.B. Auflagen wie Security Audits durch unabhängige Firmen für die nächsten 20 Jahre, ein recht kostspielige Aktion.

Der Artikel verweist auch auf derzeit noch laufende Schadenersatzprozesse, z.B. gegen Sony oder gegen Dropbox. Auch das kann teuer werden. Ziel muss sein, die Entwicklung von unsicherer Software kostspielig zu machen.

 

Aktualisierung Okt. 2012:
Die NY Times weißt auf Probleme bei den elektronischen Krankenakten in den USA hin: The Ups and Downs of Electronic Medical Records. Die Systeme sind geprägt von Inkompatibilitäten und es kommt dadurch manchmal zu Behandlungsfehlern. Speziell problematisch ist eine übliche Klausel in den Verträgen mit den Software-Lieferanten, die diese von jeglichen Haftungen ausschließt und verhindert, dass die Krankenhäuser über solche Fehler öffentlich reden dürfen.

 

 

 

Sichere Software beginnt mit der Programmier-Ausbildung

Es finden sich jetzt (2008, 2009) immer mehr Initiativen, die versuchen, das Ausbildungsdefizit bei der Programmierung anzugehen. Dazu hier einige Bemerkungen und Ressourcen.

 

Aktualisierung Nov. 2007:
Auf einer Microsoft Veranstaltung habe ich ein interessantes Buch bekommen: 750 Seiten, "Writing Secure Code", mit einem Coverspruch von Bill Gates "Required reading at Microsoft". Vom ersten Durchschauen her scheint es ein sehr gutes Buch zu sein, die ersten 120 Seiten mehr theoretisch über Dinge wie Threat Modelling, denn 440 Seiten Secure Coding Practices, mit vielen Programmbeispielen, in denen alle wichtigen Themen wie Buffer Overrun, Fehler beim Einsatz von Cryptographie, Input Checking, Datenbankfehlnutzungen, Internationalisierungsfehler, aber auch MS spezifische Probleme wie ActiveX, DCOM und .NET ausführlich behandelt werden. Der Rest ist dann über Testen in Bezug auf Sicherheit. So ein Buch sollte Lehrbuch an den Programmierschulen, FHs und Unis sein.

Weitere Infos zu sehr guten Initiativen von Microsoft weiter unten.

 

Aktualisierung Jan. 2009:
Das SANS Institute veröffentlicht TOP 25 Most Dangerous Programming Errors, zusammengestellt von einem hochkarätigen Team von Software-Experten. Ziel ist, dass diese typischen Programmierfehler bei der Ausbildung stärker berücksichtigt werden und automatisierte Tools entwickelt werden die sich auf genau diese Programmierfehler konzentrieren. Im Bereich .NET Entwicklung gibt es dazu z.B. den FxCop.

Kurze Zeit später, eine sehr gute Replik zu "top nn Buglisten": Software [In]security: Top 11 Reasons Why Top 10 (or Top 25) Lists Don’t Work . Die Argumente klingen eigentlich alle recht einleuchtend, z.B. 50% der Verwundbarkeiten sind Design-Fehler, nicht Programmierfehler, Bugs sind nichts, was man Managern vermitteln kann. Manager verstehen (maximal) Risiken, aber nicht Details wie SQL-Injektion. Dieser kurze Text ist sehr lesenwert.

 

 

 

Die Entwicklung von Qualitätssoftware - The Joel Test

Stand: Dezember 2004

Joel Spolski schreibt regelmäßig über Probleme der Software-Entwicklung. Hier ein Link zu seinem Joel Test (englisch), der dazu dienen soll, die Qualität eines Software-Entwicklungsteams zu testen. Er hat dabei in sehr schöner Form seine 12 Hauptregeln für Software-Entwicklung zusammengestellt, Regeln, die ich gern unterschreibe.

  • 1. Benutzt des Team eine Source Control Software, z.B. cvs ?
  • 2. Kann ein „build“ in einem einzigen Schritt durchgeführt werden ? (jeder zusätzlich nötige Schritt ist eine weitere Fehlerquelle)
  • 3. Werden „builds“ täglich durchgeführt ? (Fehler sollten so früh wie möglich entdeckt werden)
  • 4. Gibt es eine Bug-Datenbank ?

    Wie reproduziere ich den Fehler?

    Wie sollte sich das Programm verhalten, wie verhält es sich wirklich?

    Wer ist verantwortlich dafür, den Fehler zu beheben?

    Was ist der Status des Fehlers?

  • 5. Werden alle Fehler behoben, bevor weiterprogrammiert wird?

    Frühe Fehlerbehebung ist billiger

    Vermeidung von Folgefehlern, weil andere auf dem falschen Verhalten aufsetzen

    Der Projektfortschritt ist nur dann abzuschätzen, wenn ich nicht einen back-log von unbekannten Fehlern habe, deren Behebungsaufwand weitgehend unbestimmt ist

  • 6. Wird der Projektfortschritt penibel verfolgt?

    Tricks dazu auf Projekt-Schedule

    Erlaubt z.B. frühzeitige Entscheidungen, welche Feature bei Zeitknappheit weggelassen werden

  • 7. Gibt es immer schriftliche Spezifikationen?

    in diesem Stadium ist das Beheben von Fehlern am einfachsten

    Tricks dazu auf Progamm-Spezifikationen

  • 8. Haben die Entwickler eine ruhige, ungestörte Arbeitsumgebung?

  • 9. Wird in vernünftige Werkzeuge investiert ?

    große Bildschirme für viele offene Fenster !!

    gute Debugging-Software

    vernünftig schnelle Rechner für Compilierungen

    keine Belästigungen bez. „zu viel Plattenplatz verbraucht“

    „Bestechung“ durch „coole“ Technologie

  • 10. Gibt es spezielle Tester?

    Selbst-testen ist die unproduktivste Art der Fehlersuche

  • 11. Ist Programmieren Teil des Job-Interviews?

    Tipps dazu Job Interviews

  • 12. Gibt es „Usability Tests“ mit absoluten Laien?

    ein gutes User Interface entsteht durch Feedback der User

    eine intuitive Nutzung der Software vermeidet viele der Benutzerfehler
    („Nein, das ist kein Bug, das ist ein Benutzerfehler“ - oder doch ?!?)

    Gute Tipps dazu UI Design

 

Ergänzungen von Philipp Schaumann:
Bei Microsoft hat sich in den letzten 5-7 Jahren auf dem Gebiet der Softwaresicherheit und -qualität einiges getan. Sie haben eine ganze Reihe von führenden Wissenschaftlern auf diesem Gebiet eingestellt und alle Programmierer mussten durch eine zusätzliche Ausbildung, die wohl recht gut ist. Jetzt wurde wieder (April 2007) die aktualisierte Version seines erstmals Ende 2004 vorgestellten Leitfadens "Trustworthy Computing Security Development Lifecycle" auf seinen Seiten verfügbar gemacht. Hier eine zusammenfassende Bewertung des Microsoft SDL process.

Auch in einer Information-Security Policy sollte (falls für das Unternehmen relevant) ein Kapitel zu Software-Entwicklung und Quellcode-Verwaltung sein.

Ein Link zu einem sehr interessanten 103-Seiten Dokument zu Aspekten der Fehlersuche und (vor allem) Fehlerbehebung - Bug Advocacy von Cem Kaner (pdf, 740 KB). Es ist so etwas wie ein "Guerilla-Handbuch für Software-Tester", wie bringe ich als Tester den Programmierer dazu, den von mir gefundenen Bug wirklich ernst zu nehmen und zu beheben?

Aktualisierung Dez. 2006:
Die Initiative "Deutschland sicher in Netz", DSIN, bietet u.a. auch eine recht gute Anleitung für sicheres Programmieren.

Aktualisierung Mai 2008:
Nachdem Tausende von Websites über SQL-Injektion mit Schadsoftware infiziert sind, die diese dann an ihre Besucher weiterverteilen, weist Microsoft auf ihre Best Practise Dokumente zur Webprogrammierung hin. Sehr empfehlenswert für Entwickler von Websites.

Aktualisierung Dez. 2008:
Ein sehr hilfreiches Dokument für alle, die sichere Software entwickeln (lassen müssen) ist Fundamental Practises for Secure Software Development der Organisation SafeCode (pdf). Es enthält jede Menge Tipps (genereller Art, nicht auf programmier-technischer Ebene) und viele Links zu Ressourcen und Tools, z.B. für Code Quality Checking, etc.

Aktualisierung Feb. 2010:
Microsoft hat jetzt als Ergänzung zu ihrem SDL Prozessen eine Simplified Implementation of the Microsoft SDL herausgebracht und damit den Lesestoff auf 18 Seiten reduziert, damit die Hemmschwelle zu besserer Programmierung gesenkt wird. Sehr lobenswert.

Aktualisierung Okt. 2012:
Microsoft hat eine hilfreiche Anleitung verfasst zur Security Usability bei Sicherheitsabfragen: Microsoft's NEAT und SPRUCE.

 

 

 

Im Original veröffentlicht in der Computerwelt Österreich

Augen zu und durch

Autor: Johannes Bergsmann

Als EDV-Sachverständiger muss ich bei der Erstellung von IT-Project-Reviews und Gutachten immer wieder feststellen, dass im begleitenden Qualitätsmanagement und besonders in der Anfangsphase eines Projekts schwerwiegende Fehler gemacht werden. Sehr oft sind Spezifikationen vorhanden, die diese Bezeichnung nicht verdienen oder inkonsistent und unklar verfasst sind. Und das ist vielfach der Grund, warum es im Projekt in späteren Phasen zu massiven Problemen kommt. Viele Projektverantwortliche auf Auftraggeberseite handeln in frühen Phasen nach dem Motto »Augen zu und durch!«. In späteren Phasen kommt dann das böse Erwachen!

Wenn ich in Gesprächen mit meinen Kunden die Mängel in den Spezifikationen aufzeige, kommen oft die Fragen: »Warum hat sich denn keiner diese Spezifikation vorher kritisch angesehen? Hat das denn keiner bemerkt?«. Und spätestens da taucht die Frage auf, wer denn diese Spezifikationen testet. Meine Erfahrung: Es gibt zwar in vielen IT-Unternehmen und auch Auftraggeber-Organisationen klare Regelungen für die Freigabe von Dokumenten (z.B. ISO 9000). Doch die Prüfer unterschreiben vielfach, ohne sich mit den Inhalten selbst auseinander gesetzt zu haben. Kaum eine Software-Spezifikation wird einem intensiven und strukturierten Review unterzogen!!

Dabei könnten durch Reviews, die in frühen Phasen des Projekts durch einen qualifizierten Reviewer durchgeführt werden, sehr viele Probleme und auch Zusatzkosten im Projekt vermieden werden.

Die durch Fehlersuche und Fehlerbehebung entstehenden Kosten innerhalb der Entwicklung werden mittlerweile auf 30-50% der Gesamtkosten geschätzt. Mehrere Untersuchungen zeigen auch auf, dass die Ursache für mehr als die Hälfte aller Fehler in Software-Projekten im Bereich der Spezifikation liegt! Der überwiegende Teil dieser Fehler in der Spezifikationsphase wird jedoch erst in der Abnahme oder Betriebsphase gefunden. Dadurch sind diese Fehler meist auch die Teuersten. Es ist notwendig, auf Methoden zu setzen, die helfen, diese Fehler zu vermeiden oder zu reduzieren. Spezifikations-Reviews sind eine geeignete Methode, um auch schon in sehr frühen Phasen der Software-Entwicklung die Spezifikationen einer kritischen Prüfung und Beurteilung zu unterziehen.

Eine Faustregel der Software-Entwicklung besagt, dass man sich für jeden Euro, der in der Spezifikations-Phase investiert wird, 10 Euro an zusätzlichen, nicht notwendigen Projektkosten erspart.

Ergänzung April 2008:
Hier ein Link zu interessanten Studien zu den Themen Softwareentwicklung, Software-Projekte und Entwicklungstools

 

 

 

Netter Text von Joel Spolsky, hier der Gesamttext

Satire: Custom-developed Software

    "Custom development is that murky world where a customer tells you what to build, and you say, 'are you sure?' and they say yes,
    and you make an absolutely beautiful spec, and say, 'is this what you want?' and they say yes,
    and you make them sign the spec in indelible ink, nay, blood, and they do,
    and then you build that thing they signed off on, promptly, precisely and exactly,
    and they see it and they are horrified and shocked,
    and you spend the rest of the week reading up on whether your E&O insurance is going to cover the legal fees for the lawsuit you've gotten yourself into or merely the settlement cost.
    Or, if you're really lucky, the customer will smile wanly and put your code in a drawer and never use it again and never call you back."

Hier mein Kommentar: ein sehr bekanntes Problem, das eine ganze Reihe von Ursachen hat. U.a. die Schwierigkeiten der Kommunikation zwischen den Entwicklern und den Anwendern.

  • Haben die Anwender/der Kunde der die Spezifikationen mit "Blut" unterschrieben hat wirklich verstanden, was sie da bestellt haben?

  • Hat der Kunde die Möglichkeit gehabt, an einem Prototypen/Mock-up zu testen, ob die Software den gewohnten Arbeitsweisen der Mitarbeiter gerecht wird?

  • Hat der Entwickler wirklich verstanden, was der Kunde an Anforderungen in die Spezifikationen hineingeschrieben hat?

  • Hat es wenigstens Screen-Mock-Ups oder Workflow-Ablauf-Diagramme gegeben, und zwar in einer Form, die beide Parteien verstanden haben?

So viele Möglichkeiten zur Miss-Kommunikation. :-(

 

 

 

Weitere Informationen

An anderer Stelle mehr zum Thema Sicherheit von Webservern.

Aktualisierung Juli 2008: Einige interessante Ressourcen zum Thema sichere Programmierung.

Aktualisierung März 2007: SANS hat ein neues Programm zur Zertifizierung der Sicherheitsskills von Software Entwicklung aufgesetzt - das Software Security Institute. Das ist ein sehr guter Schritt in die richtige Richtung, noch besser wäre allerdings, wenn Sicherheitsfragen und die Techniken zur Entwicklung sicherer Software ein integraler Bestandteil jeder Programmierausbildung wären. Die Kosten für die Zertifizierung sind mit 400 US$ durchaus erträglich.

Hier ein Artikel zu Fuzzing, der automatisierten Technik, mit der heute die Angreifer die vielen Verwundbarkeiten in der Software finden können.

Und noch was von den Angreifern (Nov. 2007): ein Artikel in DarkReading erklärt, wie man den Browsing für Angriffe verwenden kann, bzw. welche Browser-Plugins der Software-Tester oder der Sicherheitsspezialist verwenden sollte, um zu sehen, welche Daten eine Web-Anwendung wirklich mit dem Browser austauscht. Speziell wenn es um AJAX-Anwendungen geht, so ist ohne solche Hilfsmittel kaum noch zu erkennen, was wirklich an Daten ausgetauscht wird.

Diese Geschichte aus dem Jahre 2005 ist eine gute Illustration der Forderungen eines NSA Mitarbeiters auf einer Sicherheitskonferenz, nämlich, dass er Assurance von den Sicherheitsprodukten erwartet (PDF, englisch). Was er damit meint, ist, dass ein Sicherheitsprodukt (und eigentlich jede kommerzielle Software) nicht nur die Funktionalität bieten sollte, die der Hersteller propagiert, sondern auch dagegen gefeit sein muss, dass ein böswilliger Angreifer nicht andere, nicht erwünschte Funktionalitäten (d.h. "bugs") für seine bösen Zwecke missbrauchen kann. Zu diesem Zweck müssen diese bösen Intentionen bereits im Design-Prozess, bei der Entwicklung selbst und vor allem beim Testen bereits einkalkuliert werden. Dies geschieht ganz offensichtlich nicht, siehe oben.

Hier ist ein Link zu einem sehr guten Text: Some thoughts on security after ten years of qmail 1.0 (pdf), in dem viele Prinzipien der Entwicklung von sicherer Software sehr kompakt dargestellt werden.

In meinen Notizen berichte ich über eine dramatisches Beispiel für schlechte Webprogrammierung: eine Behörde nutzt die vollständigen SQL-commands als URLs.

Ein sehr empfehlenswertes Buch und vollständig online verfügbar: David A. Wheeler - Secure Programming for Linux and Unix HOWTO. Und hier ein kurzer Überblick über die zur Zeit effektivsten Methoden zur sicheren Entwicklung von Software (pdf).

Wenn es um Web Applikationen geht, so ist OWASP eine Autorität und eine Fundgrube für hilfreiche Informationen. Z.B. der OWASP Testing Guide (pdf, 350 Seiten Testfälle, detailliert ausgeführt, inkl. AJAX).

Für Entwickler, die noch nicht so ganz mit den verschiedenen Angriffen vertraut sind, sind die OWASP Top Ten sehr zu empfehlen. Die Dokumentation enthält nicht nur einen Überblick über die wichtigsten Angriffe und Programmierfehler, sondern verweist auch auf entsprechende Resourcen, mit deren Hilfe Tester und Entwickler diese Schwachstellen vermeiden können.

Aktualisierung Juli 2011:

Software on the Witness Stand: What Should It Take for Us to Trust It?. Bei dieser Studie geht es darum, dass Software genutzt wird um Beweise zu erzeugen, und dass die möglichen Fehler oft nicht hinterfragt werden können, sondern dass oft von einer Objektivität des technisch erzeugten Beweises ausgegangen wird. Hier die PPT-Version des Artikels.

Ein gutes Beispiel für diese Fehlannahme ist der in dem Artikel nur beiläufig erwähnte Fall der Dräger Alcotest-Geräte aus 2009. Ein Amerikaner hat erzwungen dass man ihm den Quellcode vorlegt. Und der was dann atemberaubend: Der Mittelwert aus vielen Messungen wird gebildet in dem der 1. und der 2. Wert addiert wird, dann durch 2 geteilt, dann der 3. Wert dazu addiert, wieder durch 2, usw. Dabei wird nicht der Mittelwert über die Messreihe gebildet, sondern es werden nur die letzten paar Werte berücksichtig. Solch offensichtliche Fehler können sich in Software verstecken, die vom Gericht als objektiv herangezogen werden. Mehr zum Alkotest.

Interessant zu diesem Thema sind auch die monatlichen Zusammenfassungen der eklatentesten Computerfehler in Forum On Risks To The Public In Computers And Related Systems.

 


Philipp Schaumann, http://sicherheitskultur.at/

Home

 

Copyright-Hinweis:
Das Copyright des Materials auf diesen Webseiten liegt, falls kein anderer Autor genannt wird, bei Philipp Schaumann. Creative Commons License
Diese Texte sind lizensiert unter der Create Commons Attribution-Noncommercial-Share Alike 2.0 Austria Lizenz. Natürlich gelten auch die Regeln des Fair Use und über Ausnahmen bzgl. der Lizenz kann jederzeit mit den Autoren gesprochen werden.