Abgefischte WoW-Rollenspieler

Teilnehmer des beliebten Online-Rollenspiels World of Warcraft entwickeln sich zunehmend zu einer interessanten Zielgruppe für Phishing-Attacken. Schließlich lassen sich die Zugangsdaten zu WoW-Konten von Spielern ebenso weiterverkaufen wie seltene und daher wertvolle Gegenstände im Besitz der Spieleravatare.

Kürzlich erreichte eine Phishing-Mail die Spielergemeinde, die den Anschein hatte, als dass sie vom Betreiber Blizzard Entertainment verschickt wurde und in der es um die freiwillige Teilnahme an einem Test neuer Spielfunktionen ging. Konkret wurde ein neues spieltechnisch verbessertes Reittier versprochen (exotische Reittiere sind in WoW ein zum Teil recht wertvoller und schwer zu erlangender Besitz).

Wer an dem Test teilnehmen wollte, hätte einen Link anzuklicken und sich mit seinen Spielerdaten auf einer Website anzumelden, die auch den Begriff „worldofwarcraft“ mit im Namen trug.

So berichteten es kürzlich die Malware-Experten bei Sophos, die den Hergang der Phishing-Attacke analysierten.

Generell sollte man Mails, die einem besondere Spielvorteile wie mehr Gold, bessere Waffen, besondere Zauber oder sonst etwas Interessantes versprechen, sehr skeptisch begegnen. Insbesondere wenn die versprochenen Dinge nichts kosten und den Login mit eigenen Account-Informationen auf einer unbekannten Website erfordern.

Außerdem darf davon ausgegangen werden, dass Blizzard Entertainment Tests von professionellen Testern durchführen lässt und öffentliche Betatests von Spielfunktionen auf seiner Website ankündigt.

Gutes Lizenzmanagement wird für Unternehmen zunehmend wichtiger

Immer mehr Unternehmen schaffen neue Positionen für Lizenzmanager. Deren Aufgabe ist es, den allgemeinen Wildwuchs an Software-Lizenzen im Unternehmen einzudämmen und sicherzustellen, Dass ein Unternehmen weder über- noch unterlizenziert ist. D.h. dass zu jedem benutzten Softwareprodukt die richtige Lizenz und der benötigten Menge erworben wird.

Überlizenzierung bedeutet, dass mehr Lizenzen gekauft wurden, als Software eingesetzt wird. Das ist z.B. bei falsch dimensionierten Volumenslizenzprogrammen oft der Fall und kann rasch teuer werden.

Ebenso kritisch ist Unterlizenzierung zu sehen. Das kann ebenfalls teuer werden, wenn ein Softwarehersteller zu unpassendsten Zeit Überprüfungen im Unternehmen durchführt (das Recht dazu behalten sich Anbieter oft im Kleingedruckten ihrer Lizenzverträge vor) oder schlicht Druck ausübt bzw. hart an Betrug und Schutzgelderpressung grenzende Geschäftsmodelle verfolgt.

Hinzu kommt die, durch das recht verwerterfreundlich gestaltete Urheberrecht ermöglichte enorme Vielfalt an Lizenzmodellen. Da lizenziert ein Hersteller nach Nutzern, der nächste nach Installationen, ein anderer nach Prozessoren im Rechner und wieder einer anderer nach Berechtigungsgruppen. Standardisierte, einheitliche Lizenzen haben sich nur im Open-Source-Bereich mit der GPL und Creative Commons durchgesetzt.

Auch können Schäden, die einem Unternehmen durch Falschlizenzierung entstehen, zur persönlichen Haftung der Geschäftsführer und Vorstände aufgrund verletzter kaufmännischer Sorgfaltspflichten führen – wenn dem nicht durch ein funktionierendes Lizenzmanagement vorgebeugt wird.

Das Thema Dokumentation des Lizenzbestandes ist zudem revisionsrelevant und wird zudem durch allesamt erst in den letzten Jahren neu erwachsene Pflichten wie SOX-Compliance oder Bewertungsvorschriften immaterieller Wirtschaftsgüter (zu denen die Lizenzen zählen) mit tangiert.

Hilfsmittel der Lizenzverwaltung ist ein funktionierendes Software Asset Management (SAM), also eine möglichst tagesaktuelle Bestandsverwaltung von Softwareprodukten und dazugehörigen Lizenzen, so dass ein Soll/Ist- Abgleich durchgeführt werden kann.  Dieses Monitoring erfordert aber im Prinzip eine dauerhafte und automatisierte Überwachungs- und Inventarisierungsmöglichkeit aller auf einen beliebigen Firmenrechner installierten Programme sowie ggf. eine Verknüpfung mit Personen. So wünschenswert das aus der Sicht der IT-Sicherheit sein mag, so problematisch ist es aus Sicht des Datenschutzes. Auch kann die dabei bewegte Datenmenge beträchtlich sein und entsprechend ausgestattete Datenbankserver erforderlich machen.

Mit dem Einsatz einer SAM-Software ist es jedoch noch nicht getan. Lizenzmanagement ist eine Funktion, die sowohl bei der Produktauswahl und der Softwarebeschaffung, als auch beim Vertragsmanagement (nicht jedes Lizenzmodell kann in jeder Lizenzmanagementsoftware abgebildet werden) sowie auch im Systembetrieb (Anbindung des Lizenzmanagements an die zentrale CMDB und die Inventarisierungssysteme) mit zu beteiligen und zu berücksichtigen ist.

Insgesamt ist das Handling der betrieblichen Lizenzvielfalt ein nicht zu unterschätzender Komplexitäts- und Kostentreiber. Das erfordert kluges Lizenzmanagement, um die damit verbundenen Kosten in Grenzen zu halten.

Das „Security by Design“-Prinzip

Eine der grundlegenden Erkenntnisse das Qualitätsmanagements besteht darin, dass es besser ist Qualität gleich mit einzubauen als sie nachträglich „reinzuprüfen“. Also qualitätssichernde Vorgehensweisen und Praktiken zum verbindlichen  Bestandteil des Produktionsprozesses werden zu lassen.

Die zunehmende Bedeutung von Vorgehensmodellen, Reifegradmodellen und Standards in der Softwareentwicklung macht deutlich, dass die Industrialisierung der Softwareentwicklung auch zur Übernahme qualitätssichernder Konzepte und Methoden führt.

Das Thema „Security by Design“ wurde in den letzten Jahren maßgeblich von Microsoft durch die Entwicklung des Security Development Lifecycle (SDL) vorangetrieben und von zahlreichen anderen Softwareherstellern in der ein oder anderen Form übernommen.

Gängige Instrumente der Software-Qualitätssicherung wie das Testen entsprechender Features, Code-Review oder auch Penetration Tests fertiger Produkte mit sicherheitsrelevanten Eigenschaften erwiesen sich zunehmend als unzureichend, da sie nur punktuell prüfen, anstatt den ganzen Prozess der Entwicklung qualitätssichernd zu begleiten.

Abhilfe schaffen da lebenszyklusorientierte Ansätze wie der SDL bzw. das „Security by Design“-Prinzip, durch die Sicherheit bereits als explizite Anforderung definiert und im weiteren Entwicklungsprozess implementiert und verifiziert wird.

Security by Design bzw. SDL ist dabei keine Technik, sondern eine Sicherheitsmaßnahme, die den Entwicklungsprozess kontinuierlich begleitet. Die Maßnahmen sollen eine integrierte und nachhaltige Sicherheit der entwickelten Softwareprodukte zur Folge haben.

Generell umfasst SDL Sicherheitsmaßnahmen, die den Softwareentwicklungsprozess ergänzen und gewährleisten, dass Sicherheit im notwendigen Umfang berücksichtigt und integriert wird, unabhängig davon, mit welchen Vorgehensweisen und Werkzeugen gearbeitet wird. Die Sicherheitsmaßnahmen lassen sich immer parallel zu den Entwicklungsschritten ausführen.

Ein voll implementierter „Security by Design“-Entwicklungsprozess ist allerdings – ähnlich wie ein umfangreiches Testmanagement – recht aufwändig. Wie man den umfangreichen Microsoft-Ansatz auch auf kleinere Entwicklungsteams und Unternehmen herunterbrechen kann, schildert ein Fachartikel auf Heise Developer.

Im Wesentlichen wird dazu der SDL-Prozess auf seine fünf essenziellen Schritte Managementunterstützung sicherstellen, Awareness und Schulung, Risikoanalysen, sichere Programmierung anwenden, Test und Review reduziert.

Sichere Programmierung anwenden meint damit Schritte, die in eigentlich jeder Programmiersprache nachvollzogen werden können und durch die sich Software-Schwachstellen wie SQL-Injection, Cross-Site Scripting oder Fehler in der Zugriffskontrolle merklich reduzieren lassen:

1. Prüfung von Ein- und Ausgaben vor ihrer Weiterverarbeitung.
2. Authentisierung und Zugriffskontrollen.
3. Korrektes Handhaben und Schutz von sensitiven Informationen und Daten.
4. Befolgen des “Least Privilege”-Prinzips, das die geringstmöglichen Privilegien zur Umsetzung einer Handlung vergibt oder benötigt.
5. Verhindern von Informationspreisgaben.

Ähnliche, aber generellere Ansätze der Qualitätssteigerung während der Entwicklung verfolgt auch das Clean Code Development (CCD).

Hinzu kommt „nachfolgende Qualitätssicherung“ durch Sicherheitstests der fertigen Anwendung. Dadurch wird weiterhin geprüft, ob die Vorgaben zur sicheren Programmierung eingehalten wurden, um zu gewährleisten, dass keine Fehler, speziell keine sicherheitsrelevanten, implementiert wurden. Beispielsweise durch Prüfung des Quellcodes (Code-Review). Es lassen sich nicht nur Konventionen und Qualität prüfen, sondern Entwickler können konkret nach Sicherheitslücken suchen, sie dokumentieren und beheben.

Um einen SDL und damit „Security by Design“ einzuführen oder weiter auszubauen, lassen sich spezielle sicherheitsbezogene Vorgehensmodelle einsetzen. So weist Niklaus Schild in dem bereits erwähnten Heise-Artikel auf die Ansätze des Building Security In Maturity Model (BSIMM, Reifegradmodell für zwölf Praktiken, wie sie sich in der sicheren Softwareentwicklung anwenden lassen) sowie des Software Assurance Maturity Model (SAMM, Reifegrade und zusätzliche Beschreibungen und Empfehlungen für eine Umsetzung und Weiterentwicklung) hin.

Database Attack Detection – Das Kondom für die Unternehmensdatenbank

Datenbanken in Unternehmen sind attraktive Angriffsziele für professionelle Datenräuber. Die in ihnen enthaltenen Informationen lassen sich nicht nur an Wettbewerber verkaufen. Sie sind auch für Phishing und Pharming von Interesse, da man mit genauerer Kenntnis über Unternehmensinterna stark personalisierte Phishing-Mails generieren kann.

Mit konventionellen Schutzansätzen wie Zugriffs- und Rechtekonzepten oder Datenverschlüsselung auf Feldebene kommt man rasch an Grenzen, wenn  z.B. die (relativ hochprivilegiert auf die Daten zugreifende) webbasierte Client-Applikation per SQL-Injection oder Cross-Site-Scripting angegriffen wird. Oder ein Innentäter mit entsprechenden Berechtigungen tätig wird. Klassische Möglichkeiten, eine Datenbank mit systemeigenen Mitteln zu schützen, können vor allem durch Schwachstellen in den Applikationen umgangen werden, welche die Datenbank nutzen.

Auf dieses Problem wies Oliver Karow kürzlich in der Fachzeitschrift „IT-Sicherheit“ (2/2009) sowie bereits 2007 auf Computerworld.ch hin.

Mit Database Attack Detection wird seit einiger Zeit ein neuer und zusätzlicher Schutz für die Unternehmensdatenbanken empfohlen. Oft greifen nur wenige, meist größere Systeme auf die Datenbank zu. Etwa ein CRM-System, das ERP-System und ein SAP-HR-Modul sowie eine Onlineshop-Bestellabwicklung. Die von diesen Applikationen verwendeten SQL-Zugriffe bilden meist nur einen kleinen Teil der Möglichkeiten von SQL ab und sind leicht typisierbar, da sie nur eine begrenzte Anzahl von verschiedenen SQL-Befehlen verwenden.

Jede SQL-Anfrage, die außerhalb dieser Grenzen legitimer und üblicher Anfragen liegt, kann als verdächtig angesehen und weiter geprüft werden. Bei der Database Attack Detection wird daher jeder einzelne SQL-Befehl, der an eine Datenbank geschickt wird, auf potentiell gefährlichen Code hin untersucht. Im Prinzip also ein zusätzlicher unabhängiger SQL-Interpreter, der im SQL-Code nach ungewöhnlichen Codefragmenten sucht. Beispielsweise wenn der Onlineshop als Folge einer SQL-Injection nach Personalstammdaten fragt, was im Verlauf einer regulären Bestellabwicklung nicht vorgesehen ist.

Damit diese Untersuchung in Echtzeit oder Quasi-Echtzeit erfolgen kann, wird eine Kopie sämtlicher Datenanfragen an das Database Attack Detection-System weitergegeben. Dieses nimmt die Unterscheidung zwischen legitimen und bösartigen Anfragen durch Formen des maschinellen Lernens wie Real-World-Training vor und laufende Konditionierung während des Einsatzes vor. Ähnlich wie es z.B. auch Bayes-Filter bei der Spambekämpfung tun.

Tritt ein Alarmfall ein, können dann vorgesehene Gegenmaßnahmen ergriffen werden. Beispielweise eine verzögerte Bearbeitung nachdem ein Systemadministrator die Anfrage geprüft hat. Oder ein Transaktionsabbruch mit oder ohne Fehlermeldung.

So erhalten neben Rechnern (Virenschutz), Netzen (Intrusion Detection / Prevention Systeme), Mailserver (Spamfilter) und Internet-Gateways (Content Filter) jetzt auch Datenbanken ihr spezielles „Datenschutz- und Sicherheitskondom“.

Firefox – Der Sicherheitsvorsprung schwindet

Vor einigen Jahren wurde es noch als Geheimtipp unter Sicherheitsexperten gehandelt: Wer im Internet sicher sein will, der sollte als Browser Firefox statt Internet Explorer einsetzen. Doch die Zeiten ändern sich. Neue Schadprogramme finden auch durch die alternativen Browser ihren Weg auf den PC – der Vorteil der alternativen und quelloffenen Browser nimmt ab.

Zu diesem Ergebnis kam das deutsche Sicherheitsnetz, ein Verein der es sich zu Ziel gesetzt hat, die Sicherheit der Internetnutzung in Deutschland zu erhöhen.

Man hatte von Mai bis Juni 2009 etwa 5.600 Rechner untersucht und kam dabei zum Ergebnis, dass alternative Browser wie Firefox oder Opera praktisch ebenso angreifbar sind, wie der dafür oft kritisierte Internet Explorer von Microsoft.

In der Untersuchung des deutschen Sicherheitsnetzes ließen sich im Durchschnitt 54 % aller getesteten Browser angreifen. Die Unterschiede zwischen dem Internet Explorer (53 %) und Firefox (55 %) waren dabei marginal. Am schlechtesten hat in dieser Untersuchung der schon angejahrte Netscape-Browser abgeschnitten (80 % Angreifbarkeit). Der erste Platz ging an Google-Chrome (46 % Angreifbarkeit), wobei dies mehr auf seine noch relative Neuheit als besseren Sicherheitseigenschaften zurückführbar sein dürfte.

Untersucht wurden typische Schwachstellen die direkt auf den Browser zurückgehen (veraltete Browser-Versionen, bekannte Browser-Bugs) sowie bekannte Fehler in installierten Plugins und Mediakomponenten (PDF, Java, Flash, Shockwave, Quicktime und Media-Player). Der Online-Test steht in einer leicht reduzierten Fassung auch heute noch unter www.desine.de jedermann kostenlos zur Verfügung.

Ursache für die zunehmende generelle Verwundbarkeit der Browser ist dabei neben den zunehmenden Nutzungsanteilen von Browsern wie Firefox hauptsächlich ein weiterer Angriffsweg, der zunehmend an Bedeutung gewinnt: Multimediadateien und kommerzielle Plugins zu deren Wiedergabe. Sie werden auf allen Browsern in etwa gleich verarbeitet, was den Angreifern einer viel größere potentielle Verbreitungsmöglichkeit ihrer Exploits ermöglicht.

Ausschlaggebend dafür ist der Umstand, dass alle Browser-Hersteller auf die gleichen (kommerziellen) Plugins und Multimediaerweiterungen setzen. Damit erben die Browser-Hersteller auch automatisch die Sicherheitsprobleme der Multimedia- und Plugin-Produzenten. Die Sicherheitslücken von Adobe (PDF, Flash) und Apple (Quicktime) werden so automatisch zu den Sicherheitslücken der diversen Browser. Deren eigene Vorteile durch eine grundsätzlich sicherheitsorientiertere Entwicklungsphilosophie relativieren sich so durch die importierten Probleme anderer Softwarekomponenten.

Das zeigt ein generelles Problem von Komponentensoftware aus mehreren Quellen auf: Die sicherheitstechnische Gesamtstärke entspricht der des schwächsten Gliedes im System.

Hacking at Random 2009

Heute geht in den Niederlanden das viertägige Hacker-Sommerfestival „Hacking at Random“ (HAR) zuende. Es war bereits vor Wochen ausverkauft. Auch aus Deutschland nahmen viele Hacker, Netzaktivisten und digital Natives daran teil.

Zumal eines der Kernthemen dieses Jahr der digitale Selbstschutz vor Privacy-Gefahren durch Staat und Wirtschaft war. Dazu wurden Projekte wie die „Surveillance Self-Defense“ der Electronic Frontier Foundation (EFF), das Portal für geleakte Geheimdokumente aller Art Wikileaks aber auch selbstgebaute Geräte zum Detektieren von RFID-Lauschern oder eine Demonstration des CCC, wie sich NEDAP-Wahlcomputer anhand kompromittierender Abstrahlung ausspähen lassen. Denn auch Wahlcomputer senden elektromagnetische Strahlen aus, die mit einer entsprechenden Antenne noch aus einigen Metern Entfernung gemessen werden können. Offen ist allerdings noch, welche Informationen sich aus diesen Daten gewinnen lassen.

Auch Methoden zur Umsetzung sowie zur Umgehung von Internetzensur waren ein heiß diskutiertes Thema auf der HAR. Ebenso wie „traditionelle“ Themen aus dem Umfeld der IT-Sicherheit und des kreativen Umgangs mit Technik.

Natürlich durften auch echte Hacker-Wettbewerbe nicht fehlen, bei denen zu diesem Zweck speziell vorbereitete Systeme gehackt werden mussten.

Fast alles was auf der HAR vorgetragen wurde kann im HAR-Wiki nachgelesen oder heruntergeladen werden. Schließlich sollen solche Informationen ja im Sinne der Veranstalter möglichst frei fließen …

Neues Blog zur Softwarequalität gestartet!

Nachdem ich schon Mitte 2008 zu den Themen IT-Sicherheit, IT-Recht, Datenschutz & Compliance auf itsicherheit.wordpress.com blogge, habe ich beschlossen, Beiträge zum Thema Softwarequalität künftig verstärkt in meinem neuen Blog softwarequalitatet.wordpress.com, dem Blog zu Softwaretest, Testmethoden, Testmanagement und Teststandards zu veröffentlichen.

Was dabei einen Bezug zum Thema IT-Sicherheit oder Softwarequalität generell hat, erscheint parallel auch hier. Beiträge zu Themen wie Softwaretest, Testmethoden, Testmanagement, Teststandards ohne Bezug zur IT-Sicherheit werden künftig ausschließlich auf softwarequalitatet.wordpress.com erscheinen.

Beginnen werde ich damit, meinen Artikelbestand zur Softwarequalität in diesem Blog auch dort einzustellen.

Viel Spaß beim Lesen meiner Artikel!

Clean Code Development – ein Weg zu besserer Software?

Software besser zu machen, d.h. insbesondere ihre Qualität, Zuverlässigkeit, Fehlerfreiheit und Sicherheit zu steigern, ist mittlerweile ein Trendthema geworden. Bislang ging man dabei den Weg, über Vorgehens- und Reifegradmodelle zur Softwareentwicklung den Entwicklungsprozess zu verbessern. Softwareentwicklung also zunehmend durch Standardisierung zur Ingenieursdisziplin (Engineering) zu machen. In dieselbe Richtung gehen auch agile Methoden wie SCRUM oder XP, die auf die Verbesserung der Projekt- und Arbeitsorganisation der Softwareentwicklung abzielen.

Mit Clean Code Development (CCD) wurde zum Jahresanfang nun eine Initiative gestartet, die auf das eigentliche Herzstück der Softwareentwicklung abzielt: den Softwareentwickler.

Basierend auf den Arbeiten von Robert C. Martin, die dieser in seinem Buch „Clean Code“ veröffentlichte, befasst sich CCD mit Praktiken wie Codeoptimierung (Refactoring), Entwurfsmuster (Patterns) sowie Testen und Techniken zur Erstellung sauberen Quellcodes. Sozusagen die Rückführung der Softwareentwicklung auf gute handwerkliche Arbeit, durch die sich der Profi vom Amateur und Bastler unterscheidet.

Für Code als Quelltext und strukturiertem Ausdruck der Funktionalität sowie als kleinsten gemeinsamen Nenner zwischen Softwareentwicklern aller Art beschreibt Clean Code eine Menge von Prinzipien und Best Practices als kleinsten gemeinsamen Nenner.

Dazu gehört u.a. ein aus Prinzipien und Praktiken guter handwerklicher Arbeit bestehendes CDD-Wertesystem. Sowie eine Einteilung in aufeinander aufbauender Grade fortschreitender Professionalisierung, die sich mit Themen wie Automatisierung von Abläufen, Testen, Testautomation, projektbegleitende Qualitätssicherung sowie Steigerung der Produktivität als Entwickler auseinandersetzen.

Ralf Westphal, Mitbegründer der „Clean Code Development“-Initiative in einem Interview mit Heise Developer:

Mir ging es darum, Unternehmen bewusst zu machen, wie viel Geld sie mit schlechter Softwarequalität „verbrennen“ – selbst wenn die Umsätze sie irgendwie gerade noch tragen. Die Idee stieß bei Stefan auf offene Ohren, und so sahen wir das Buch “Clean Code” als pragmatischen Ausgangspunkt für mehr Bewusstsein hinsichtlich innerer Softwarequalität. Denn um die geht es uns. Wir machen keine Aussage zu äußerer Qualität, die zum Beispiel mit Funktionen, Usability oder Skalierbarkeit zu tun hat. Uns geht es um Wartbarkeit – auch wenn wir den Begriff unglücklich finden. Sehr viele Projekte stecken in einem Wartungsalbtraum. Aus dem wollen wir sie wecken. Andere Projekte bewegen sich darauf zu. Denen wollen wir zeigen, dass der Albtraum vermeidbar ist.

Dort weist er auch auf die Lücken bisheriger Ansätze zur Qualitätssicherung in der Softwareentwicklung hin:

Schließlich ist Softwarequalität das Thema von Verbänden und Normen. Da kann man sich ISO-zertifizieren lassen oder sich auf ein CMMI-Level heben. Das ist alles schön und gut. Nur sehen wir nicht, dass diese Initiativen auf breiter Front Erfolg haben. Der Entwickler einer Branchensoftware in einem 5-Mann-Team hat davon sogar wahrscheinlich nicht einmal gehört. Ganz zu schweigen davon, dass seine kleine Softwareschmiede eine Zertifizierung wegen der hohen Kosten nicht durchlaufen würde. Die „große“, „formale“, „offizielle“ Softwarequalität lässt also eine sehr große Zahl von Projekten außen vor, weil sie bürokratisch und teuer ist.

Mit Clean Code Developer wollten wir daher eine Lücke schließen, die wir in unserer Arbeit in vielen Projekten gesehen haben. Es geht uns „nur“ um eine ganz pragmatische und vor allem innere Softwarequalität, die sich mit etwas gutem Willen und ein paar Werkzeugen in jedem Projekt herstellen lässt. Von anderen Initiativen unterscheiden wir uns also schon einmal durch unseren Fokus.

Darüber hinaus legen wir Wert auf die Didaktik. Denn der schönste Fokus nützt nichts, wenn sich das Ziel nicht erreichen lässt. Clean Code Developer unterscheidet sich unserer Meinung nach daher von anderen Initiativen durch sein Stufenkonzept. Wir haben den „Lernstoff“ von vornherein eingeteilt, sodass ein klarer Weg hindurch sichtbar ist. Wir holen die Entwickler bei ihrer Überlastung ab und zeigen ihnen, wie sie in kleinen Schritten – definiert in den CCD-Graden – zu einer Veränderung ihrer Haltung und damit zu höherer Codequalität kommen.

Es bleibt abzuwarten, ob und wie sich CCD weiter entwickeln wird. Zumindest dort wo heute bereits mit agilen Methoden, d.h. sehr am einzelnen Entwickler orientiert gearbeitet wird, dürften CCD-Ansätze eine weitere methodische Ergänzung darstellen.

Insbesondere aber wer die Entwicklung von Software neu erlernt oder Entwicklungsprojekte häufiger auf Codeebene zu prüfen hat, täte gut daran sich mit den Überlegungen des Clean Code Development zu befassen.

Safety – Der Weg zur sicheren Software

Wann  ist Software bzgl. der  Eigenschaften Zuverlässigkeit, Verfügbarkeit, Gebrauchstauglichkeit, Wartbarkeit und  Sicherheit als sicher zu bezeichnen? Und wie kann man das messen und prüfen?

Mit diesen Fragen beschäftigt sich Software Safety, ein Themenfeld, welches sich inhaltlich zwischen Softwarequalität und IR-Sicherheit ansiedeln lässt.

Insbesondere Bereiche, in denen Software umfangreiche sicherheitsrelevante Aufgaben erfüllen soll, in denen hohe sicherheitstechnische Auflagen bestehen (Luftfahrt, Medizintechnik) oder in denen es um Menschenleben geht, erfordern Software mit deutlich höherem funktionalem Zuverlässigkeitsniveau (Reliability, Availability, Maintainability, Safety – RAMS) als normal üblich. Oft ist auch gefordert, Software für solche Einsatzfelder fail-safe zu entwickeln, d.h. dass  im Fehlerfall möglichst geringer Schaden entsteht (auch: Fehlertoleranz, Ausfallsicherheit). Dies geschieht neben dem gezielten Einbau von Redundanz durch das möglichst vollständige Vorhersehen und Testen aller denkbaren Fehler durch entsprechend anspruchsvoll und aufwendig konzipierte Testprojekte. Dazu werden systematisch Fehler unterstellt und danach versucht, deren Auswirkungen so ungefährlich wie möglich zu gestalten. Auch dem Benutzer wird zunächst Fehlverhalten unterstellt, mit dem das System klarkommen muss (z.B. durch Filterung und Plausibilitätsprüfung von Eingaben).

Zum Thema Safety-Eigenschaften und funktionaler Sicherheit haben sich bereits nationale und internationale Standards und Normen (IEC 61508, IEC 61511 und weitere) entwickelt, hauptsächlich aus dem Maschinen- und Anlagenbau, deren Umsetzung als Teil der Entwicklungs- und Qualitätssicherungsprozesse Sicherheit, Qualität und Zuverlässigkeit der Softwareprodukte gewährleisten soll.

Was aber in der produzierenden Industrie schon seit langem Standard ist, wird in die Entwicklung und Qualitätssicherung bei Software vielerorts erst noch Eingang finden müssen. Wobei bei der Adaption und Integration entsprechender Prozesse die bereits bestehenden Industriestandards Orientierung geben können.

Die Beurteilung sicherheitsrelevanter Software spielt auch bei der Prüfung der funktionalen Sicherheit entsprechender Produkte eine ständig wachsende Rolle und hat daher Prüfgesellschaften ein weiteres Geschäftsfeld eröffnet.

Die Safety-Anforderungen an Softwarekomponenten als Teil von sicherheitsgerichteten Steuerungssystemen sind durch die zunehmende Verlagerung der Sicherheitsfunktionalität in die Software drastisch gestiegen. Die Struktur der Software sowie Maßnahmen und Techniken in der Software, die zur Vermeidung und Beherrschung von Fehlern und Ausfällen führen, sind ein fester Bestandteil entsprechender Prüfungen, z.B. nach IEC 61511-1 (funktionale Sicherheit –  u.a. Anforderungen an Systeme, Software und Hardware) geworden.

Software Safety und funktionale Sicherheit dürfte daher als Thema sowohl für Softwaretester, Qualitätsmanager als auch für IT-Sicherheitsbeauftragte zunehmend an Bedeutung gewinnen. Und auch in IT-Sicherheitsmanagement (ITSM) und bei Thema Risikomanagement in der IT werden Safety-Kriterien ihren Platz finden.

Wie wird man eigentlich IT-Sicherheitsexperte?

Das ist eine berechtigte Frage, zumal IT-Sicherheitsexperte kein geregelter Beruf ist und es von daher auch kein klares Berufsbild gibt. Aufgrund dieser Unverbindlichkeit fühlt sich „irgendwie“ auch niemand für die Ausbildung dieser Leute zuständig, weshalb sie auch relativ knapp sind, obwohl an IT-Fachleuten an sich kein Mangel besteht.

Ein Weg führt über die Belegung entsprechender Fächer und Kurse während eines IT-bezogenen Studiums. Zunehmend bieten Informatik-Fakultäten auch „akademisches Hackertraining“, d.h. Seminare an, in denen Techniken des Angriffs und der Abwehr von Attacken auf Computersysteme vermittelt werden.

Viele derzeit am Markt tätige IT-Sicherheitsexperten haben sich dagegen ihr Know-how studien- und berufsbegleitend mit sehr viel autodidaktischer Praxis angeeignet – als Hacker, Coder und Hardwarebastler. Wobei das früher ungefährlicher war als heute. Denn was vor einigen Jahren noch als jugendlicher Spaß galt, ist heute dank „Hackerparagraph“ und anderer entsprechender Strafnormen bereits eine potentielle Straftat deren Aburteilung das sichere Ende in der IT-Branche bedeuten kann.

Das kürzlich überarbeitete und auf 14 Spezialistenprofile halbierte sog. „arbeitsprozessorientierte“ (APO) IT-Weiterbildungssystem enthält ebenfalls zwei Profile (den Security Technician und den IT Security Coordinator) mit Schwerpunkt IT-Sicherheit. Das von Gewerkschaften, Arbeitgeberverbänden und der Fraunhofer-Gesellschaft entwickelte IT-Weiterbildungssystem funktioniert allerdings nur, wenn Unternehmen bereit sind, selbst und über längere Zeit beträchtlich in die Fortbildung ihres Personals zu investieren. Weshalb es in der Praxis auch eine nur geringe Bedeutung erlangt hat.

Daneben kann  man inzwischen sogar per Fernstudium an der privaten isits AG International School of IT Security den „Master in Applied IT Security“ (master of science) erwerben, wenn man bereit ist, dafür etwa 17.000 € auszugeben und berufsbegleitend einige Jahre Zeit aufzubringen.

Für den grundsätzlichen Einstieg ins Thema kann man aber auch ein Angebot der Fernuni Hagen, den Kurs „IT-Sicherheit Konzepte, Standards, Verfahren und Anwendungen“ belegen. Er wird einem als DVD zugeschickt und bietet die Möglichkeit der Prüfung zur Erlangung eines Zertifikates.

Und natürlich gibt es eine Fülle von Hersteller- und Verbandszertifikaten mit sehr unterschiedlichen, meist auf bestimmte Technologien und Verfahren zugeschnittenen Inhalten. Ebenso Kurzschulungen und Kongresse im Tagesbereich, meist zu irgendeinem operativen Teilaspekt aktueller Sicherheitsprobleme in Unternehmen.

Beginnen kann man allerdings auch mit (möglichst aktiver) praktischer Mitarbeit in Organisationen wie dem Chaos Computer Club, dessen Vereinsorgan „Die Datenschleuder“ auch als PDF heruntergeladen werden kann.

Alles in allem gibt es sehr vielfältige Möglichkeiten des Einstiegs in das Thema der IT-Sicherheit. Wobei ich eine der wichtigsten noch gar nicht erwähnt habe: Das Thema fällt einem „artverwandt“ beschäftigten ITler (Systemadministration, Softwareentwicklung, Softwarequalität etc.) im Unternehmen zu und er arbeitet sich irgendwie rein, bis er einen entsprechenden Grad von Expertise erreicht hat. So dürfte es in der Praxis häufig laufen.