 Diese Situation kennt wahrscheinlich jeder von euch irgendwo her, vielleicht auch nur aus einem Albträum. Das Projekt läuft schon und irgendwann braucht man noch Sicherheit obendrauf. Mein Hintergrund, ich habe jetzt schon die 13, 14 Jahre hauptsächlich oder viel mit C verbracht. Ich habe eine Antivirus-Software geschrieben. Heißt, in diesem Fall ist sogar String-Processing in C und direkt Malwert durchschieben. Das ist so ziemlich das Schlimmste, was man machen kann, was Risiko angeht. Defensives Programmieren ist ein Survival-Instinct, der man entwickelt. Was ist auch noch reinkommt? Ich habe einen Second-Hand-Psychologie-Studium durch meine Frau. Hauptthema bei ihr ist Persuasion. Das ist ein bisschen dieses Überzeugen, zum Beispiel Leute aufhören zu rauchen. Es gibt ganz viele psychologische Effekte, die da versorgen, dass man eigentlich gerade das falsche tut, weitere auch und zum Beispiel. Das kombiniert sich sehr gut mit dem, was ich beobachtet habe, wenn es darum geht, Security irgendwo einzuführen oder irgendwo zu haben. Normalerweise hat man so ein bisschen diese Motivation im Team. Teilweise von außen, teilweise intrinsisch im Team. Lass uns das Ding sicher machen. Es kann auch sein, dass irgendjemand weiter oben mal ein Artikel gelesen hat, dass es immer doch plötzlich wichtig ist. Oder es zum Beispiel eine ähnliche Software erwischt hat. Was ich heute präsentiere, sind eigentlich relativ Basic-Technologien, die sich aber sehr gut eignen, um sie einzuführen, so getting started. Darum wollen wahrscheinlich euch die Technologien, die ich jetzt gleich präsentiere, gar nicht so überraschen. Vielleicht aber in der Kombination, wozu man sie verwendet. Bisher, also ich persönlich habe mit Antivirus Software Bold On Security gemacht, die packt man nachträglich auf ein System drauf. Ein System, das vielleicht nicht so schön designed und programmiert ist. Man versucht halt nachträglich irgendwas zu retten, weil man das anders nicht machen kann. Dafür ist es sehr gut. Was wir aber hoffentlich machen können, ist, wenn wir selber in einem Projekt sind, Security by Design. Das heißt, wir haben Einfluss auf das Design der Software und auf den Code und können die Sicherheit ein bisschen besser grundlegend sicherstellen. Es gibt in der Firma, beim normalen Projekt, relativ viele Ebenen, die mit Sicherheit mitspielen. Management muss ein paar wichtige Richtungen und Entscheidungen setzen, damit Security überhaupt möglich ist in der Firma. Das hängt von Incentives ab. Wenn man nur Druck hat und schnell releasen muss und darf nix kosten, dann hat man da Wicus Link, dann war das mit Management nix. Software Design, Coding, Compiling, Testing, das so die Hierarchie wie es sonst mit dem Projekt weiterläuft. Das Releasing und auch nachträglichen Supporten von der Software ist genauso wichtig, wie gesagt Wicus Link. In dem Vortrag, da haben wir es auch so angekündigt, lege ich mal ein bisschen den Schwerpunkt auf Scouting, sonst wird es ein bisschen langer Vortrag. Und alles, was so ein bisschen drum herum berührt wird, wie das Design, Compiling, Testing, da kommen auch noch ein paar Sachen mit rein. Was ich gleich versuche, zusammenzubasteln, ist einmal die psychologische Schiene, was passiert in den Leuten, in dem Team, wenn man versucht, irgendwas mit Security zu machen, neue Technologien einzuführen, und dann auch technische Tricks, die sich dazu eignen, das zu machen, ohne jetzt in psychologische Barrieren zu stoßen. So, ich habe mal eine Worst Case-Situation zusammengefranktensteint. Ihr und euer Team sind zusammen verantwortlich für ein Softwareprojekt. Bisher ist noch keine Security da, hat bisher noch keinen richtig interessiert. Das heißt, das Projekt ist schon irgendwo in der Mitte, vielleicht sogar schon mal eine Version released. Ressourcen sind eh keine da. Und plötzlich ändert sich ein bisschen was in den Entscheidungen. Und Security wird dann doch mal wichtig. Was wichtig ist für mich jetzt ist eigentlich, dass es gewollt ist. Etwas irgendwo reintragen, wo es eh keiner will, ist Kampf gegen Gewinnten, kann man eh nicht machen. Ein bisschen zwei Schienen vom Problem. Das eine ist ein Technologieproblem. Das Projekt läuft ja eigentlich schon. Ich habe es ja jetzt möglichst schlimm gemacht gerade in diesem Beispiel. Und jetzt muss man nachträglich noch irgendwie Security einführen. Hätte man natürlich besser vorher im Design und Planung gemacht, aber zu spät. Es gibt kein richtig ernsthaftes Commitment. Wie gesagt, Worst Case-Szenario. Es wurden nicht nochmal zwei Leute eingestellt, die sich wirklich damit auskennen oder externen. Ressourcen macht man halt so nebenher. Und die Skills sind noch gar nicht so wirklich da im Team. Worst Case-Szenario. Und jetzt machen wir noch in diesem Beispiel das ganze CNC, damit es auch eine hohe Fallhöhe hat. Andere Sprachen haben auch ihre Eigenheiten. Es gibt relativ wenig solide Sprachen. Das andere was es dann kommt, was ihr vielleicht auch mal alle beobachtet habt, sind so psychologische Verteidigungsmechanismen. Die sind ganz normal in einem Mensch. Also jeder hat diese Verteidigungsmechanismen. Und die haben eure Vorfahren dazu gebracht, Kinder zu zeugen. Und nicht vorher irgendwie gefressen zu werden von irgendwas. Die sind ganz normal, die sind prinzipiell auch ganz gut. In unserer modernen Umgebung mit dem New-Cycle und allem, sind die aber total hinterlich. Was zum Beispiel ganz kritisch ist, sind diese Lead-Hacker-Talks. Die sind cool. Die haben aber diesen Nachteil, dass man in diesen Talks, die ich total liebe, immer Dinge vorgestellt kriegt, die total high-tech sind. Sonst wäre es kein Talk. Und dann geht sofort das Paranoia-Level hoch. Und oh mein Gott, gegen genau das muss ich jetzt die Software verteidigen. Wahrscheinlich gar nicht, aber falsche Annahme. New-Cycles, die bringen immer das Neueste und Heißeste. Auch da, das ist nicht zwingend das, gegen den man sich zuerst verteidigen muss, was Software angeht. Und noch irgendwas, was so psychologische Verteidigungsmechanismen total triggert, ist Veränderung. Also was Neues einführen, was Neue machen, vor allem wenn der Druck ist. Wenn diese Dinge passieren und es gibt keine realistische Lösung für, dann triggert was Komisches im Gehirn. Wir nehmen nämlich den Leuten die Selbstwirksamkeitserwartung, Self-Effektasie. Das heißt, es gibt dann einen Punkt, wo die Leute sagen, ich kann jetzt eh nichts machen. Und dann weg. Ich glaube, sowas haben wir in der Gesellschaft ein bisschen mit Snowden beobachtet, wo es um Privacy ging. Und dann kam News, News, News, News, News. Relativ wenig Lösungsvorschläge, die die Leute umsetzen konnten. Und dann kam irgendwann dieses NSA, ich kann eh nichts machen. Das ist dann so ein Close-Down, da rauszukommen, ist wahrscheinlich gar nicht mehr so einfach. Es gibt aber noch so ein paar Good News. Und das ist das, was man sich immer wieder bewusst machen muss und auch den Leuten um einen herum. Es gibt Möglichkeiten, relativ viele und viele davon sind sogar ganz einfaches, ordentliches Engineering und Programmieren. Das bringt uns schon ziemlich viel. Also eigentlich, wenn wir noch testbarem Code zielen und einfach mal zuverlässigen Code, soliden Code, dann nicht einfach nur aus irgendwelchen Gründen plötzlich crasht, dann hat man als Nebeneffekt schon einiges in Security erreicht. Also das sind jetzt die Good News, die muss man mal gerade zacken lassen, damit das diese Selbstverrückungsverwaltung ein bisschen zunimmt. Und die erste langweilige Sache, das sind eigentlich Asserts in C, die müsste es auch in anderen Sprachen geben. Ich weiß jetzt nicht, welche Projekte ihr habt. Guck mal nach. Der Trick bei Assert ist ein bisschen, es macht Release-Code nicht kaputt. Die Asserts sind nur in der Deback-Version aktiv. Das heißt, es wird ziemlich das erste, was man einführen kann, ohne Risiko. Also es gibt null Risiko. Ein Asserts sorgt dafür, dass das Programm abbricht, wenn eine Bedingung nicht gegeben ist. Das nützt man jetzt nicht um Parameter zu testen, normalen Code mit Asserts-Testmenut-Dinge, die definitiv nie passieren kann. Keiner erwartet, dass das Ding jemals passiert. Es wird passieren. Und der Code stirbt dann genau da, das Programm bricht genau da, wo es dann passiert und die Back nicht ewig Dingen hinterher. Das Coole daran ist, dass die Leute anfangen, die Backtime zu sparen. Das heißt, die Ressourcen wurden im Team dann ein bisschen frei. Man kann es einführen ohne Risiko. Es ist gar nicht so viel Aufwand. Und wir kriegen jetzt ein paar Ressourcen. Auch etwas, der kann praktisch jeder mitmachen, jeder so, der gerade in den Code reingreift. Und paar Zellen ändert. Er kann nach gleichem Assert von in die Funktion reinschreiben. So klassische Dinge sind man null Punkte abzufragen. Komische Größen, die definitiv immer größer als null sein müssen. Später können wir die nochmal brauchen. In einer Kombination mit etwas anderem Wort, die noch relativ cool. Was jetzt auch noch relativ wichtig ist für ein bisschen riskant Reaktionen nachher, ist, dass man automatisierte Tests hat. Wie gesagt, Leute, das gesamte Team hat den Auftragen, gute Software zu programmieren, jetzt Risiken einzugehen, alles umzuschmeißen. Und dann hat man einfach über Wochen hin, die Software, die gar nicht mehr funktioniert, will keinen vernünftigen Engineer eingehen, also macht man es besser nicht. Für einen guten automatisierten Integrations-Tests hat man auch wieder so dieses Risiko minimiert. Hat auch den Vorteil, dass man ressourcenfrei macht. Man kann öfters testen, weil sie automatisch laufen, das kann man praktisch einmal nächtlich machen. Und auch das wird nachher nochmal ganz brauchbar werden, das ist damit eine andere Technologie. Was so ein bisschen die dritte Stufe ist, Klang und GCC haben jetzt ziemlich gut zugelegt, was Compiler-Technologien angeht, und zwar prinzip statisch und vor allem dynamische Analyse. Ich habe sofort zehn Jahre viel mit Valgrint gemacht. Das war sehr cool und ist sehr cool. Das Assan wird das wahrscheinlich jetzt gerade ausradieren, weil es halt auch direkt in Compiler ist. Für die, die es noch nicht kennen, diese Technologie sorgt dafür, dass Memory-Zugriff überwacht werden. Mit Valgrint muss man auch nicht mal neu kompalieren, sondern einfach sein normales Programm. Und wenn irgendwie ein komischer Memory-Zugriff ist, auf der Overflow, daneben gegriffene Zeiger, Doppelfrie, dieses ganze Zeug, wird das es finden. Wir haben mit dem automatischen Test natürlich ein gutes Test-Set, wo man das mitlaufen lassen kann. Diese Valgrint und Assan, die sorgen ein bisschen dafür, dass das Programm auch langsamer läuft. Das will man also nicht im Release haben, um ein kompaliertes Programm zusammen mit den automatischen Tests laufen zu lassen. Wird wahrscheinlich einige Backs nach oben spülen, die ihr bisher noch nicht gesehen habt. Falls ihr irgendwelche Exoten-Compiler habt, versucht es mal trotzdem mit diesem GCC oder Klang zu kompalieren. Valgrint ist auch eine Linungs-Only-Sache. Also es hat sich bei mir schon klont, ein Projekt Großplattform zu machen, nur um Valgrint zu haben, zum Profilen und Testen. Durch die Asserts freigeschalten wurde, wir haben ja damit für die Funktionen Contracts definiert, wie die aufgerufen wurden. Dieser bräuchte darf der Null sein oder nicht. Mit Unitests können wir feststellen, dass diese Contracts einkalten worden, auch wenn die Programme selber geändert worden ist, die Funktion. Das nagelt uns jetzt diese Funktionen fest, im nächsten Schritt. Hier kann es leider sein, darum ist es auch ein bisschen später, dass man den Code umbauen muss. Für Unitests muss man den ganzen Code in kleine Module aufteilen. Mit einem normal geschriebenen Spaghetti-Code funktionieren die gar nicht so gut. Was auch ein wichtiger Nebeneffekt ist, wenn man ein großes Projekt hat, mit mehreren Teams, das verhindert, dass ein Team versehentlich eine Library umbaut und vergisst so die API-Updates durchzureichen. Hier ist es der erste Punkt, wo Refactoring wirklich nötig ist. Da ist ein bisschen Risiko drin, mit den anderen Dingen, die wir vorher gemacht haben, haben wir das jetzt aber abgesichert und minimiert. In der Hoffnung, dass wir damit, auch bei den Leuten im Team, jetzt noch nicht so diese Panik triggern. Jetzt wird es ein bisschen riskanter. Compiler mitigations, das sind so das nächste. Da ist ein bisschen schwierig, und die Security-Leuten nicht alle mögen diese mitigations. Problem hier ist, viel zu viele Leute verlassen sich darauf. Anstatt versuchen, die Probleme wirklich zu beheben, kompariert man diese mitigations rein und hofft dann, dass das Problem behebt. Ich kann es jetzt nicht genau sagen, ich war mal an einem Chromium-Projekt mit dran beteiligt, also Chromium-Projekt, die haben diese mitigations auch nicht für alle Dateien aktiviert. Teilweise haben die Nebenwirkungen, was Laufzeit und so angeht. Das heißt, hier, wenn ihr die aktiviert nacheinander, wollt ihr wahrscheinlich bei den normalen Tests auch definitiv mitstoppen, wie lange die Tests brauchen, wie effizient das Programm ist. Die können schon Nebenwirkungen haben. Also hier sehr vorsichtig vorgehen, ich würde sie auf jeden Fall wenn möglich einbauen. Das ist etwas, sobald die Tests stehen, ist es dann auch kein großes Risiko mehr. Ressourcentechnisch dürfte es im normalen Projekt relativ freundlich sein. Das heißt, im Team kann man das einfach mal reinnehmen. Wie gesagt, hier drunter steht es auch, anlockt bei Tests, nur durch die Tests ist es jetzt möglich. Es gibt relativ viele Bücher die man hier hinten ein paar verlinkt. Vor allem zum C natürlich, die Standardprobleme. Da ist auch wieder ein psychologisches Problem, kommen wir gleich zu. Das Defensive programmieren ist relativ gut dokumentiert. Viele Leute in der Security-Szene sind auch für 100% Schutz. Das heißt, die raten sogar von String N-Copy ab. String N-Copy hat ein kleines Problem. Das sorgt zwar dafür, dass das String N-Copy beitsrüber kopiert. Es kann aber passieren, dass das Ding nicht 0 Terminate ist, das String N-Copy und danach der nächste Befehl einfach knallt. String L-Copy, das hat BSD angeführt, macht es richtig. Wenn ihr nur String N-Copy habt als Ersatz für String Copy, nehmt das auf jeden Fall, selbst wenn es nicht 100% perfekt ist. Aber besser ist besser. String L-Copy wäre besser und Zweifelsfall selbst implementieren. Und Freunde, geht mal nicht davon aus, dass ASAN und Co. alles findet. Es lohnt sich auch durch die Codes durchzugucken. Das ist jetzt das erste, was richtig viel Ressourcen fressen wird. Da haben wir den Code aufräumen. Also, das String N-Copy, okay, das sind ein paar Krebs. Mit ein bisschen Glück haben die vorigen Schritte dafür gesorgt, dass die Ressourcen frei sind. Dass der Druck so ein bisschen vom Team runter ist. Also, vor allem Zeitdruck und auch der psychologische Druck. Die Leute wollen die Software ausliefern. Das ist der Job. Wegen, dass die Unitests im Team drin sind und auch gut verstanden, kann man schon wieder einen nächsten schönen Schritt machen. Man kann, falls das Projekt externe Libraries hat, kann man die Unitesten. Und zwar insbesondere die Schnittstelle, die man benutzt. Die Technologie Unitests ist dann hoffentlich im Team auch schon Gewohnheit, also, die es sitzt. Sitzt. Die Unitests von externe Libraries hat man dann wieder ein bisschen Sicherheit gewonnen. Für die nächste Kombi von Schritten kommt gleich. Vorher noch als weitere Bauteil Fussing. Ich habe oft beobachtet, dass Leute, die jetzt nicht so auf FECA-Kongressen rumhängen, von Fussing noch nicht so wirklich viel gehört haben. Obwohl es eigentlich eine sehr coole Testtechnologie ist. Also es muss es auch als cool, aber gar nicht so komplex einführen. Und die beste Erklärung, die ich jetzt bisher gefunden habe, die bei Leuten funktioniert ist, dass es ein Test-Tool ist, also ein Betonung auf Test-Tool, dass automatisch unerwartete Fehler findet. Mit allem anderen, dass wir bisher hatten, findet man erwartete Fehler. Also man hat bei Unitests schon ein bisschen mitgedacht, welche Fehler jetzt kommen könnten. Das erfindet die Unerwarteten. Man hört Fehler hauptsächlich in Dataprocessingzeug. Dataprocessing, also wenn Puffer irgendwie überlaufen, ist natürlich das, wo Secure die Probleme herkommen. Aber eigentlich ist es ein Test-Tool. Man muss es einfach ein bisschen als normaler verkaufen, als es ist. Und glaube ich, die Leute verstehen relativ schnell, was es bringen kann. Sobald euer Code irgendwelche Daten verarbeitet, ob es Fotos sind, Coalcodes, Strings, nutzt irgendwas wie Fussing. Und das Beste, um so was einzuführen, was ich bisher gesehen habe, ist ein simpler Fusser. Irgendwas, das nur ein paar Strings generiert und Richtung diesem Ding schmeißt, dem Source Code. Die sind vielleicht nicht so effizient, wie jetzt AFL oder diese ganzen abgefräßten Dinger, aber sind einfacher zu verstehen. Fusser kann man danach immer noch komplizierter machen. Was geht zuerst mal darum? Konzept zeigen, die ersten Fehler finden, die Leute damit warm machen. Und hier ist auch dieses, also wirklich das Ding zeigen, ganz wichtig für psychologische Schranken. Jetzt haben wir langsam so ein bisschen die Bausteile, so langsam Schritt für Schritt aufgebaut, für ein paar, extremer ist jetzt falsch, aber ein bisschen fortgeschrittener ist. Mit dem Fusser und den Unitests kann man relativ simpel oder kann man jetzt sicher, zuverlässig externe Leibkris fassen. Und danach, falls die Baxan behoben sind, ohne dass man riskiert, dass die geänderten externe Leibkris das eigene Programm kaputt machen, weil plötzlich API anders ist, die neue Version reinnehmen. Dass die Idee bis zu diesem Punkt ist, im Prinzip, so eine kleine Treppe zu bauen mit Technologien, die sich gegenseitig machen, die neue Thematiken einführen und den Leuten relativ einfach machen, sich darauf psychologisch einzustellen, ohne zu viel Änderung auf einmal zu bringen. Weil es gibt zwar einige psychologischen Tricks, die nötig sind, wenn man neue Technologien irgendwo nutzt. Diese Komfortzone, die jeder hat, die auch jedem wichtig ist, wo sich auch jeder mal hinten wieder psychologisch zurückziehen muss, kann man erweitern, damit die Leute besser werden oder dass man auch ein bisschen wachsen kann. Aber in kleinen Schritten und in realistischen Schritten, gleich mit irgendwie den schrägsten Sachen anfangen, wird die Leute verprellen. Diese Selbstwirksamkeit ist wieder auch sehr wichtig, den Leuten den Tools in die Hand zu geben, um jetzt auf diese Betrugung, oh mein Gott, unsere Software könnte geheckt werden, zu reagieren. Wenn man einfach nur in den Raum schreit, oh mein Gott, die werden geheckt, dann ist ziemlich schnell noch zwei, drei Wochen, wenn man das macht, ist kein positiver Response mehr möglich. Wichtig ist, dass die Leute wissen, man kann was tun und es wird einen positiven Effekt haben. Das sind diese beiden Punkte, die die Leute überzeugen können und mitnehmen. Und am besten ist, wenn man denen was vorlegt, dass das zeigt, also Software laufen lassen, die das Ding fast schneller findet, oder Asserts, die sind noch einfacher, die die Fehler einfach noch umspülen und wenn sie es sogar selber mitmachen können. Und mit Security nicht so das Furcht-Level nach oben treiben, sondern ruhig und kontrolliert daran gehen. Wichtiges psychologisches Schritt ist noch, möglichst alle mitnehmen. Es wird ein, zwei Leute geben, die gar nicht wollen, kann passieren. Im Zweifelsfall, die man ruhen lassen, vielleicht sind die gerade in einem anderen Stress-Level. Was ich auch gut beobachtet habe, ist noch ein Rumpelstilzien-Effekt. Menschen, also wir führen wahrscheinlich dann auch neue Konzepte im Team ein, die Leute drum herum nicht gesehen haben vorher, Menschen können Dinge besser einordnen, wenn sie einen Namen dafür haben und ein Konzept. Das ist in diesem Märchen Rumpelstilzien sogar irgendwie mit eingebaut, indem der Dämon Rumpelstilzchen dann seine Kraft füllt, als der Name raus ist. Deswegen entweder bekannte Konzepte einführen mit ordentlichem Namen oder vielleicht sogar bei einer coole Tools-Schreib, die euch helfen, das Ding sicherer zu machen, zusammen mit den Leuten Namen vergeben. Wenn in eurem Team dann der Code eine höhere Qualitätstufe erreicht hat und das irgendwie nachweisbar ist, gar nicht auch präsentieren, das sorgt auch wieder psychologisch dafür, dass man sich damit identifiziert und ein gewisses Commitment erzeugt. Nach, wenn alles gut läuft, könnte der, könnte das Projekt, könnte das Projekt dann zu einem Punkt ankommen, wo der Code selber nicht mehr der schwächste Punkt ist, wiegeslink, in der ganzen Security-Kette und ihr viele Attacken, wahrscheinlich sogar die Gebräuchelisten, die draußen vom Mal verwendet wurden, abwehren könnt. Wichtiger ist aber, dass sich was bewegt hat. Dass die Leute, dass dieses Projekt jetzt nicht mehr so in diesem Loch feststeckt und dass jemand nicht da und die Leute über Security jammern, aber das ist ein großer Baugest, den man gar nicht erst angegangen ist. Das Team hat was gelernt und vor allem, ich habe es vor allem Tools vorgestellt, die Tools waren das nächste Projekt mitgenommen. Das nächste Projekt, das gestartet wird, wird mit den Leuten, mit dem Wissen und den Tools, die dann rumliegen, gleich auf einem höheren Level anfangen können. Es gibt es noch unglaublich viele Bücher, die speziell Design-Probleme angehen, für Web-Applikationen, für Web-Design-Probleme für was auch immer, wäre jetzt wahrscheinlich ein guter Punkt, so was dann einzuführen. Im nächsten Projekt, gleich an der Designphase ein bisschen was zu machen. Es gibt ein guter Satz technischer Bücher, das Lustige ist das, wahrscheinlich hilfreichste, Driving Technical Change, wo verschiedene Typen von Personen in einem Projekt beschrieben werden, wie man die auch überzeugen könnte. Ein klassisches Buch, relativ dünn, Building Secure Software, klassisch deswegen, weil es von 2001 ist, ist nicht so einschüchternd, wenn man das auf dem Schreibtisch liegen hat für die Kollegen, die jetzt nicht so viel lesen, aber wie gesagt, ist ein bisschen älter. Neue Versionen wurde zwar versprochen, aber ich weiß nicht, ob die irgendwann kommt. Secure Coding in C und C++ geht wirklich in die Basics rein, das ist für die, die wirklich gange viel ernsthaft mitbeschäftigen wollen, aber wahrscheinlich für ein Team, dass sich auch mit anderen Dingen thematisch beschäftigt ist, so was wie das zum Cookbook, wahrscheinlich hilfreicher, dass denn das Dritte ist, das ist wirklich hands on, ich habe dieses Problem, ich gehe so und so daran und so ein Programm ist sicher. Also, guckt auch mal genau, was für Typen von Leuten ihr euch umhaben, welche Art von Problemen. Ich hoffe, da ist jetzt ein Buch dabei, das hilft. Gut. Ich bin ein bisschen schneller als geplant, bin ganz für Fragen da und ja, mach mal Fragenrunde. Hat irgendjemand Fragen, die ich beantworten kann. Ich würde das Ding, die Präsentation nachher mal online stellen, ich glaube, die ist dann mitverlinkt. Sonst bin ich auf jeden Fall noch heute da und morgen. Genau, und das ist aufgezeichnet, hoffe ich mal. Ja, moment. Die Frage war jetzt grad, ob sich das lohnt, nur für Wellgrind ein Programm auf Linung zu portieren. Genau, und du hast impliziert, dass ich für Windows entwickelt habe. Du hast nur kein Mikrofon, da muss ich jetzt grad mal sagen. Nee, das war ein Programm, da habe ich ein Viren-Scanner geschrieben für Palmo-Symnion und Windows CE. Und den habe ich dann parallel auf Linung portiert, damit ich das mit Wellgrind noch fragen kann. Ich habe versucht, meine ganzen Erfahrungen ein bisschen in den Struktur zu bringen. Ich weiß, dass ich selbst noch ganz viel lernen kann und auch nur ein gewisses Maßnahmenprojekt-Erfahrung habe. 15 Jahre, keine Ahnung. Und ihr sicher noch irgendwas anders beobachtet habt. Ich wäre sehr dankbar, wenn ihr irgendwas für mich habt und nach dem Vortrag mal zu mir kommt, auf ein Bier. Ich bin jetzt tendenziell beim Waffle Operations Center dahinten und bin auf jeden Fall bis morgen Abend noch da. Falls es irgendwelche komplexen psychologischen Fragen gibt, morgen Abend kommt meine Frau und hat dann wirklich die tiefsten Theorien. Ich bin da eher so Handwerker. Gut, danke euch.