Wie Normen entstehen und Standards gesetzt werden

Immer mehr werden Vorgänge in Wirtschaft und Technik neben Gesetzen auch von Normen und Standards, also von Formen technischer Regulierung bestimmt. Insbesondere in der IT, in der IT-Sicherheit aber auch im Bereich Softwarequalität sind Normen und Standards sowie der Nachweis über Verständnis und Beherrschung ihrer Inhalte von wesentlicher Bedeutung für geschäftlichen Erfolg und berufliche Qualifikation. Zeit also, sich das Zustandekommen dieser Normen und Standards mal genauer anzusehen.

Am einfachsten ist es, wenn Gesetze und Verordnungen dafür ursächlich sind, wie z.B. das Bundesdatenschutzgesetz oder die Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen (GDPdU). Denn diese lassen sich meist als Volltext im Internet finden, so dass ihr Inhalt rasch nachgeschlagen werden kann. Seiten wie z.B. www.gesetze-im-internet.de des Bundesjustizministeriums sind da recht nützlich. Da die meisten Gerichte mittlerweile ihre Entscheidungen ins Internet stellen, ist auch die aktuelle Rechtsprechung zu diesen Gesetzen gut recherchierbar. Juristen sind zudem oftmals auch publikationsfreudige Fachartikelschreiber und Blogger, so dass sich auch fachliche Kommentierungen zu Gesetzen und Urteilen im Web finden lassen.

Ganz anders bei wichtigen Industrienormen und fast allen Dokumenten technischer Regulierung. Wer z.B. nachschlagen will, was die ISO 9000 zum Qualitätsmanagement aussagt, nach welchen Standards Produkte zertifiziert oder Bilanzen geprüft werden, kommt an die Texte der Normen nicht so ohne weiteres heran.

Denn diese werden nahezu ausschließlich durch privatrechtliche Organisationen wie das Deutsche Institut für Normung (DIN), die International Organization for Standardization (ISO), das Institute of Electrical and Electronics Engineers (IEEE) oder ähnliche Einrichtungen, von denen es allein in Deutschland etwa 150 gibt. Finanziert werden diese durch Mitgliedsbeiträge von Firmen, die an einer Standardisierung von technischen Vorgehensweisen interessiert sind, da damit Rationalisierungs- und Wettbewerbsvorteile verbunden sein können. Sowie aus den urheberrechtlichen  Lizenzerträgen der Texte und Dokumente, in denen die jeweiligen Standards abgedruckt und kommentiert werden.

Man kann davon ausgehen, dass Prüfgesellschaften und Unternehmen, in denen viel mit Standards gearbeitet wird, diese regelmäßig zur internen Verwendung nachkaufen. In Deutschland hat sich hier z.B. der Beuth-Verlag hervorgetan. Man kann dort einzelne Normtexte für recht happige Preise als PDF kaufen (z.B. die ISO 9000:2005, Qualitätsmanagementsysteme – Grundlagen und Begriffe mit ca. 40 Seiten für gute 140 €). Oder ganze Normenpakete mit Mengenrabatt bzw. als „Normenflatrate“ beim Erwerb von Perinorm, einer ziemlich umfassenden Normendatenbank für die eine vierstellige Summe pro Jahreslizenz und Nutzer fällig wird.

Schon der Einblick in die fertige Norm ist also kompliziert und teuer. Wie aber kommen die Normen zustande? Normen sind in aller Regel freiwillige Übereinkünfte derjenigen, die sie ausformulieren. Verbindlichkeit erlangen sie erst dadurch, dass sich hinreichend viele Unternehmen daran halten, dies auch von Lieferanten und Geschäftspartnern fordern und sich durch entsprechende Zertifizierungen belegen lassen. In ihnen kommen die Regeln und der Stand der zugrunde liegenden Technik zum Ausdruck. Normen und Standards entstehen innerhalb der Normungsinstitutionen durch Prozesse der konsensualen Beratung und Einigung innerhalb von Expertengremien. Bereits bestehende Normen werden in der Regel alle 3-5 Jahre überarbeitet, um sie dem technischen und methodischen Fortschritt anzupassen. In diese Gremien entsenden die Mitgliedsunternehmen und berufsständische Organisationen Fachleute aus ihren Reihen und lassen dort neben fachlichen auch Unternehmensinteressen vertreten. Der Lobbyismus ist also schon ins Verfahren „eingebaut“, so dass es sehr selten zu externer Lobbyarbeit zum Zwecke der Beeinflussung eines laufenden Normungsprozesses kommt. Wobei es dafür auf deutscher Ebene sogar eine eigene Norm gibt (die DIN 820-4), welche den Normungsprozess am DIN-Institut beschreibt.

In der Regel erreicht eine Norm daher meist erst mit Erscheinen entsprechender Fachliteratur und Fortbildungsangeboten einen größeren Bekanntheitsgrad. Ihre frühzeitige Beherrschung kann daher einen beträchtlichen Wettbewerbsvorteil darstellen und als Nachweis fachlicher Professionalität gelten. Deutlich sichtbar ist das z.B. bei Angeboten zur zertifizierbaren IT-Sicherheit nach ISO 27.000, zum Qualitätsmanagement nach ISO 9.000 oder zum Servicemanagement von Organisationen nach ISO 20.000 (aufgebaut nach den ITIL-Büchern, welche ebenfalls zum Standard wurden). Auch Vorgehensmodelle wie das V-Modell XT im Bereich der Softwareentwicklung, Prince2 im Projektmanagement oder Reifegrademodelle wie CMMI für Prozesse  sind letztlich Standards, die meistens anhand der Sekundärliteratur oder im Rahmen betrieblicher Fortbildungen erschlossen werden.

Nichtsdestotrotz werden Normen und Standards insbesondere für im IT-Bereich tätige Menschen immer wichtiger. Gerade bei Themen wie der IT-Sicherheit und zunehmend auch in der Softwarequalität geht ohne fundiertes Verständnis der einschlägigen Normen und Standards fast nichts mehr. Die privatrechtliche Normung ist in Teilen bereits deutlich umfänglicher als das deutsche Steuer- oder Arbeitsrecht. Und sie gilt weltweit. Daher werden auch Forderungen nach einem transparenten Zustandekommen von Normen sowie einem möglichst freien und niedrigschwelligen Zugang zu den Normtexten zum Zwecke der Information und Meinungsbildung an Bedeutung gewinnen.

Sicheres Programmieren lernen – Der Weg zu guter Software

Sichere Software gewinnt zunehmend an Bedeutung. Sicher im Sinne von „extrem schwer angreifbar“ (Security) ebenso wie im Sinne von „extrem zuverlässig“ (Safety). Das macht es erforderlich, Sicherheitsaspekte bereits in den Entwicklungsprozess der Software zu integrieren, anstatt die Sicherheit erst nachträglich „reinzupatchen“.

Um Abhilfe zu schaffen, haben sich zahlreiche Unternehmen in einem Verein – dem International Secure Software Engineering Council (ISSECO) – zusammengeschlossen. Und dort einen zertifizierbaren Standard für sichere Softwareentwicklung entwickelt.

Will man das Problem der Sicherheitslücken und Qualitätsmängel in Softwareprodukten an der Wurzel packen, muss das Thema Sicherheit in den Entwicklungsprozess integriert werden, um so frühzeitig der Entstehung von Sicherheitslücken entgegenzuwirken.

Das hierfür notwendige Wissen zur Vermeidung von Sicherheitslücken ist jedoch bis heute nur ein Randthema in der Ausbildung von Softwareentwicklern. Auch wenn Fachverbände wie der Arbeitskreis Software-Qualität und -Fortbildung oder die Gesellschaft für Informatik hier bereits seit längerem Verbesserungen anmahnen. Zudem lässt die zunehmende Komplexität von Softwareprodukten erwarten, dass das Ausmaß der Bedrohungen durch Sicherheitslücken und Qualitätsmängeln in den kommenden Jahren weiter zunehmen wird.

Der ISSECO hat daher einen Standard sowie ein Fortbildungscurriculum (ISSECO Certified Professional for Secure Software Engineering – CPSSE) entwickelt, um diese Lücke zu schließen. Das Thema Sicherheit soll dadurch zum selbstverständlichen Bestandteil jedes Softwareentwicklungsprozesses werden. Dieser internationale Zertifizierungsstandard für sichere Softwareentwicklung soll in der Softwareindustrie etabliert werden, um den Anwendern Sicherheit bei der Verwendung von Softwareprodukten zu garantieren und so auch verlorenes Vertrauen in die Softwarequalität zurück zu gewinnen.

Inhalte des Curriculums zur sicheren Softwareentwicklung sind Themen wie die Angreiferperspektive sowie die Kundenperspektive auf Software, Thread Modeling, Methoden sicherer Softwareentwicklung und Lebenszyklusmodelle für Software, Anforderungsanalyse, sicheres Design von Software, sicheres Testen, sicherer Rollout, Reaktion auf Angriffe und Qualitätsmängel sowie Sicherheit mit Metriken transparent machen. Dies wird entlang der Etappen des Softwareentwicklungsprozesses verdeutlicht:
•    Requirements Engineering
•    Design und Spezifikation
•    Programmierung und Test
•    Evaluierung, Distribution & Maintenance

Erste Schulungsangebote zum CPSSE werden derzeit am deutschen Markt etabliert. Zielgruppen sind Anforderungsanalysten, Softwarearchitekten, Designer, Entwickler, Softwarequalitätsmanager, Softwaretester, Projektmanager – kurz alle, die entscheidend an der Entwicklung von guter Software beteiligt sind.

Wenn sich Ideen wie der CPSSE im Markt durchsetzen, kann dies ein wichtiger Schritt zu sicherer und qualitativ hochwertigerer Software sein.

Schufa-Auskunft für den Chef – ist das legal?

Die Schufa sammelt und aggregiert zahlreiche Finanzdaten von Unternehmen und Verbrauchern. Über eine Schufa-Auskunft lässt sich u.a. ein Überblick über vorhandene Bankkonten, Kreditkarten und Handyverträge, laufende Kreditverpflichtungen aber auch Negativeinträge wie Informationen über nicht vertragsgemäße Abwicklungen von Geschäften (Mahnbescheide, geplatzte Schecks, Kreditprobleme) und Daten aus öffentlichen Verzeichnissen und amtlichen Bekanntmachungen wie z.B. den Schuldner- und Insolvenzverzeichnissen der Amtsgerichte gewinnen.

Daher gibt es Unternehmen, die im Rahmen ihres Risikomanagements von ihren Angestellten neben einem polizeilichen Führungszeugnis auch eine jährlich erneut vorzulegende Schufa-Selbstauskunft haben wollen. Bankgeheimnis hin oder her.

Doch ist das legal?

Schließlich darf ein Arbeitgeber gemäß § 32 BDSG personenbezogene Daten eines Beschäftigten nur für Zwecke des Beschäftigungsverhältnisses erheben und nutzen. Und auch das nur dann, wenn es erforderlich ist. Reine Neugier oder Nützlichkeitserwägungen reichen also nicht. Und Schufa-Auskünfte enthalten außer Namen, Adresse und Kontonummer nichts, was für Zwecke des Beschäftigungsverhältnisses wirklich erforderlich ist.

Besonderes Interesse am Finanzstatus ihrer Beschäftigten haben Unternehmen des Wach- und Sicherheitsgewerbes. Dort will man – wohl auch angesichts branchenüblich magerer Entlohnung – sichergehen, dass die Fahrer von Geldtransporten eine finanziell gesehen einwandfreie Lebensführung aufweisen. Dazu nahm die Bundesvereinigung Deutscher Geld- und Wertdienste (BDGW), ein Arbeitgeberverband im Sicherheitsgewerbe im Rahmen eines satzungsgemäß für die Verbandsmitglieder verbindlichen jährlich erneut durchzuführenden „Sicherheitschecks“ die Anforderung auf, von Bewerbern Schufa-Selbstauskünfte einzufordern:

Der „klassische“ Sicherheits-Check 1 befasst sich vor allem mit baulich-technischen und personellen Anforderungen sowie der ordnungsgemäßen Durchführung von Geld- und Werttransporten. Überprüfungsschwerpunkte fangen bereits bei den Einstellungsvoraussetzungen für das Personal an. Hier werden wesentlich höhere Maßstäbe angelegt als in den meisten anderen Branchen. Die Vorlage eines polizeilichen Führungszeugnisses, eine ärztlich bestätigte physische und psychische Tauglichkeit, eine persönliche und eine Schufa-Selbstauskunft sowie eine Verschwiegenheitserklärung sind nur einige der Punkte, die von den Bewerbern verlangt werden.

(Quelle: BDGW-Imagebroschüre, PDF 1,2 MB)

Dumm nur, das so eine Klausel rechtlich gesehen die Verbindlichkeit eines Wunsches besitzt. Und in den Unternehmen, in denen ein Betriebsrat existiert, dieser diese Praxis unterbinden kann. Worauf kürzlich die Gewerkschaft Verdi in ihrem Brancheninfodienst „Sicherheitsnadel“ im Rahmen einer ausführlichen juristischen Stellungnahme hinwies.

Arbeitgeber müssen Gesetze einhalten. Da hat ihnen auch kein Betriebsrat dreinzureden. Mitbestimmung gibt es nur da, wo der Gesetzgeber dafür Spielräume gelassen oder explizit Mitbestimmungsrechte eingeräumt hat.

Verbandssatzungen sind aber keine Gesetze. Und sie dürfen auch kein gesetzeswidriges Verhalten zur Norm für die Verbandsmitglieder erheben (legt man das streng aus, könnte ein Verband deswegen sogar verboten werden). Durch sie werden zudem nur die Verbandsmitglieder zu etwas verpflichtet, nicht deren Beschäftigte.

Das Gleiche gilt auch für Verträge aller Art, wie z.B. Versicherungsverträge auf die sich in solchen Fällen auch gern mal bezogen wird. Ein Blick ins BGB zeigt in § 134 dass Verträge, deren Inhalt gegen Gesetze verstößt, nichtig sind.

(interessanter Nebenaspekt: Wie kann man aus einer potentiell nichtigen Versicherungspolice im Schadensfall Leistungen einfordern?)

Hin und wieder müssen ausgerechnet beufsgenossenschaftliche Unfallverhütungsvorschriften wie die für Wach- und Sicherungsdienste relevante Vorschrift BGV C7 „Besondere Bestimmungen für Geldtransporte“, herhalten, um einen gesetzesgleichen Anspruch auf das Einfordern von Schufa-Auskünften abzuleiten.  Eine Durchführungsanweisung zum § 24 (Eignung des Personals) könnte tatsächlich dahingehend ausgelegt werden:

Bei der Eignungsbeurteilung (des Bewerbers für den Wachdienst) ist insbesondere auch auf Unbescholtenheit sowie eine geordnete Lebensführung zu achten, z.B. durch die unbeschränkte Auskunft nach § 41 Abs. 1 Nr. 9 Bundeszentralregistergesetz (BZRG), polizeiliches Führungszeugnis, die aktuelle Schufa-Selbstauskunft.

Allerdings sind auch Durchführungsanweisungen nicht mehr als unverbindliche Handlungsempfehlungen und können gesetzliche Vorschriften wie das Bundesdatenschutzgesetz nicht außer Kraft setzen. Im Gegenteil: Es ist anzunehmen, dass solche Handlungsempfehlungen als Folge von Gesetzesänderungen und Rechtsprechung früher oder später geräuschlos korrigiert werden. Zum auch hier die Schufa-Auskunft nicht als Norm sondern als mögliches Beispiel zu deren Erfüllung genannt wird.

Die Tücke beim Umgang mit Rechtsquellen steckt demnach häufig in den Details, welche gelesen und auch verstanden werden wollen.

So kam auch Arbeitsrechtler Tobias Wolters in der „Sicherheitsnadel“ (Ausgabe 12, S. 7) zu dem Fazit, dass das Einfordern von Schufa-Auskünften von Beschäftigten oder Bewerbern zwar mit unter die Mitbestimmung des Betriebsrats fällt, da es um Fragen des Ordnungsverhaltens der Arbeitnehmer geht. Dieser aber keine entsprechende Betriebsvereinbarung abschließen kann, da auch Betriebsvereinbarungen (ähnlich wie Verträge) nichts Gesetzeswidriges enthalten dürfen.

Er empfiehlt daher das Thema Schufa-Auskünfte aus entsprechenden Verbandssatzungen, Versicherungsverträgen und Anmerkungen zu berufsgenossenschaftlichen Regeln komplett zu streichen.

Wer einmal seine eigene Schufa-Auskunft prüfen will, kann das unter www.meineschufa.de tun. Wer mehr über Scoring-Methoden generell erfahren will, dem bietet die Schufa unter www.scoring-wissen.de eine Einführung in das Thema an.

Microsoft stellt Prüftools für Security-Tester bereit

Microsoft ist bereits seit längerem bestrebt, sich bzgl. Sicherheit und Softwarequalität seiner Produkte als führend zu positionieren. Daher hat die Firma u.a. das Vorgehensmodell des „Security Development Lifecycle (SDL)“ entwickelt, um Entwicklern bei der weiteren Verbesserung der Qualität sicherheitsbezogener Eigenschaften ihrer Software für die Windows-Plattform zu unterstützen.

Der Microsoft Bin Scope Binary Analyzer überprüft binären Code darauf, ob alle empfohlenen und notwendigen Security Flags, Schutzmechanismen und Kontrollen vorhanden sind. Das stellt sicher, dass in Anwendungen nicht durch gängige Sicherheitsfehler beim Coding Schwachstellen und Sicherheitslücken implementiert werden.

Der Microsoft MiniFuzz File Fuzzer ist eine Lösung für Tester, die unerwartete Verhaltensweisen ihrer Anwendungen eingrenzen wollen. Der Fuzzer automatisiert Sicherheitsüberprüfungen und testet den Code mit zufällig erzeugten Eingabedaten um das Verhalten der Applikation bei deren Verarbeitung zu prüfen. Auf diesem Wege wird bereits sehr früh im Entwicklungsprozess festgestellt, ob etwa Programmabstürze als Sicherheitsrisiken untersucht werden müssen.

„SDL hat sich seit seiner Einführung als effizienter Prozess zur Steigerung der Softwarequalität bewährt“, so Prof. Dr. Sachar Paulus, Vorstandsvorsitzender der ISSECO (International Secure Software Engineering Council e.V.). „Dank der guten Methodologie und einfachen Umsetzbarkeit hat sich SDL mittlerweile bei vielen Entwicklern etabliert. Die beiden neuen Tools sind weitere Bausteine hin zu einer besseren, sichereren Softwareentwicklung“.

Hinzu kommen weitere Hilfen für Entwickler wie z.B. das SDL Process Template für Visual Studio Team System, das SDL Threat Modeling Tool, FxCop (ein Tool zur Analyse von.NET-Assemblies) sowie einige weitere Werkzeuge für die statische Codeanalyse mit Microsoft-Entwicklungsumgebungen.

Alle Tools können bei Microsoft im SDL Tools Repository kostenlos heruntergeladen werden.

Der Security Development Lifecycle ist ein Kernelement der Trustworthy Computing Initiative von Microsoft zur Verbesserung der Sicherheitseigenschaften seiner Produkte. Der Prozess wurde zunächst geschaffen, um firmenintern sichere Anwendungen zu liefern und Attacken besser widerstehen zu können. Jedes Produkt von Microsoft, das mit dem Internet kommuniziert oder für den Unternehmenseinsatz konzipiert ist, muss Angaben von Microsoft gemäß den SDL-Prozess durchlaufen.

Tom Köhler, Direktor Strategie Informationssicherheit Kommunikation bei Microsoft Deutschland hierzu: „Wir schützen damit unsere Plattform. Dazu gehört nicht nur, dass wir unsere eigenen Betriebssysteme und Anwendungen immer sicherer machen, sondern auch Partner und andere Anbieter dabei unterstützen. Gerade Anwendungen von Drittanbietern stehen immer mehr im Zentrum der Attacken durch Schadsoftware. Jeder Entwickler, ob Freiberufler, Microsoft Partner oder Firmenentwickler muss bereits im Designprozess darauf achten, dass seine Anwendungen in der Praxis sicher funktionieren. SDL hilft dabei“.

Kein Zweifel – der Security Development Lifecycle Prozess dürfte für Entwickler auf der Windows-Plattform zunehmend an Bedeutung gewinnen.

Neue ISO-Norm 38500 betont die Verantwortung der Geschäftsführung in der IT

Schon seit Jahren kann man es beobachten: Die technischen, organisatorischen und geschäftlich bedingten Herausforderungen in der IT steigen langsam aber kontinuierlich an. Da sind insbesondere rein managerial tätige Mitarbeiter zunehmend mit Komplexität und Umfang der Probleme überfordert.

Das ist deutlich am Drang hin zu Outsourcing, Outtasking, Offshoring, Rightsizing, Shared-Services, Virtualisierung, Cloud-Computing und allem anderen zu erkennen, dass die Auslagerung und Fremdvergabe von IT-Leistungen ermöglichen und beschleunigen soll. Weg mit den Problemen, weg mit der Verantwortung dafür und runter mit den Kosten.

Allerdings macht der Gesetzgeber zunehmend klar, dass Verantwortung und Sorgfaltspflichten nicht delegiert werden können. Was externe Dienstleister verbocken bleibt haftungsrechtlich am Auftraggeber hängen. Auf den Dienstleister verweisen und sich auf Unwissenheit, Dummheit und eine bequeme passive Kundenposition zurückzuziehen, wird im Zweifel vor Gericht nicht akzeptiert.

Das macht auch eine erst 2008 rundeerneuerte ISO-Norm, die ISO/IEC 38500:2008 „Corporate Governance of Information Technology“ deutlich. Sie definiert und beschreibt, wie Unternehmen eine auf Best Practices basierende IT-Governance aufbauen können. Gute IT-Governance ist eine Voraussetzung dafür, IT-Probleme, Komplexität und Kosten grundsätzlich in den Griff zu bekommen. Es ist absehbar, dass von IT-Dienstleistern aber auch von Auftraggebern bald entsprechende Vorleistungen in Form von zertifizierbaren Organisationsstrukturen als Vorbedingung für Aufträge gefordert werden dürften.

„Angesichts der bestehenden Frameworks wie ITIL, COBIT und anderer, die alle die Ausrichtung der IT an den Geschäftszielen zum Ziel haben, wirkt der Ruf nach einem neuen Regelwerk auf den ersten Blick verwunderlich“, erläutert so Dr. Gisela Böndgen, Business Consultant beim Beratungshaus Serview. „Was aber, wenn die Geschäftsstrategie und -ziele gar nicht bekannt sind und wenn keine klaren Vorgaben aus den Chefetagen vorliegen“, fragt sie.

Und das dürfte in vielen Unternehmen der Fall sein. Man ist schon froh die technischen Aspekte geregelt zu bekommen, ohne das die Kosten aus dem Ruder laufen.  Kommen dann aber noch organisatorische und rechtliche Themen mit hinzu, ist rasch ein Punkt erreicht, an dem den Geschäftsführungen und ihren internen „Beauftragten für alles“ das Know-how und die Ressourcen ausgehen.

Vor allem aber soll der neue Standard den vielen Auslegungen und Missverständnissen bei der Gestaltung der Corporate Governance ein Ende bereiten. „Das unterschiedliche Verständnis behindert den Erfolg vieler Unternehmungen, deshalb bedarf es verbindlicher Klarheiten, damit die Unternehmen einen höheren Mehrwert aus ihren IT-Investitionen ziehen und die Risiken besser managen können“ so Böndgen weiter.

Die ISO 38500 definiert sechs Grundprinzipien zur Gestaltung der Corporate Governance:

1. Verantwortung (Responsibility): Das Topmanagement sollte die IT-Belange des Unternehmens angemessen wahrnehmen.
2. Strategie (Strategy): Die unternehmensstrategische Planung muss mit Blick auf die IT-Potenziale erweitert und angepasst sowie die IT-Strategie aus den Unternehmensstrategien hergeleitet werden.
3. Beschaffung (Acquisition): Die Gestaltung der IT-Budgets muss sich im Rahmen transparenter Entscheidungsprozesse konsequent am tatsächlichen Bedarf anstatt an politisch gesetzten Größen orientieren.
4. Leistung (Performance): Die IT-Services und –Produkte sind gemäß den konkreten Anforderungen der Fach- und Organisationsbereiche des Unternehmens zu gestalten.
5. Regelkonformität (Conformance): Die IT hat allen rechtlichen Vorgaben, Normen, internen Standards etc. zu entsprechen.
6. Faktor Mensch (Human behaviour): Die IT-Konzepte müssen den Bedürfnissen der internen und externen IT-Nutzern hohe Aufmerksamkeit beimessen.

Diese sechs Prinzipien sind dabei nicht als unverbindliche Leitbildfloskeln zu verstehen. Sondern als Programmüberschriften, die mit entsprechenden unternehmensspezifischen Maßnahmen realisiert werden müssen.

Jedem dieser sechs Prinzipien sind in der Norm drei Funktionen zugeordnet, die insgesamt eine Matrix mit 18 Leistungsfeldern der Unternehmens-IT bilden:

•    Bewertung: Kontinuierliche Beurteilung des IT-Einsatzes im laufenden Betrieb.
•    Leitung: Steuerung einer bedarfsgerechten Ausrichtung der IT-Maßnahmen am Geschäft des Unternehmens (business alignment).
•    Kontrolle: Systematische Überwachung von Regelkonformität (compliance) und Leistungsfähigkeit der IT mit Hilfe von geeigneten Werkzeugen und Verfahren.

Der Standard soll dabei helfen, die IT Prozesse so einzurichten, dass alle internen und externen Regelwerke – wie zum Beispiel Richtlinien, Gesetze und Verträge – eingehalten werden können. Er zielt dabei nicht auf eine bestimmte Art oder Größe von Organisationen ab, sondern soll von Unternehmen, Behörden oder Non-Profit-Organisationen gleichermaßen eingesetzt werden können. Dabei wird „Control Objectives for IT“ (COBiT) als Referenz für die Richtlinien, Prozesse und Controls, welche für Aufbau und Umsetzung eines Governance Management Systems zu implementieren sind, empfohlen – so die Unternehmensberatung Serview, einer der Treiber des Themas in Deutschland auf seiner Unternehmenshomepage.

Und das ist ein Punkt an dem insbesondere IT-Sicherheitsbeauftragte, Datenschützer und Betriebsräte ebenso wie Projektleiter und Methodenspezialisten aufmerken sollten. Denn die ISO 38500 sowie das COBiT-Framework oder auch das ITIL-System beschreiben letztlich Verfahren zur Etablierung, Ausrichtung und Steuerung von informationstechnischen Prozessen, in denen es auch um Fragen der Compliance, der IT-Sicherheit und des Datenschutzes gehen kann. Und nicht zuletzt um die eingangs erwähnte Frage, was intern mit eigenen Beschäftigten getan wird. Und was an Externe und Dienstleister abgegeben werden soll.

Neues Hoeren-Skript zum Internetrecht

Der bekannte IT-Rechtsexperte Thomas Hoeren, Professor am Institut für Informations-, Telekommunikations- und Medienrecht der Universität Münsterund Richter am Oberlandesgericht Düsseldorf, hat eine neue Fassung des Skripts Internetrecht vorgelegt. Die neue Ausgabe liegt auf den Seiten des Instituts für Informations-, Telekommunikations- und Medienrecht der Universität Münster zum kostenfreien Download als PDF-Datei (3,2 MB) bereit.

Obwohl „Skript“ für dieses umfassende, gut 550 Seiten starke Standardwerk zum deutschen IT- und Internetrecht eigentlich heftig untertrieben ist.

Thomas Hoeren gab kürzlich der ZEIT ein Interview, in dem er die überkommenen Strukturen des deutschen Urheberrechts sowie die fragwürdige Praxis des sogenannten „fliegenden Gerichtsstands“ kritisierte und sich zu Ideen wie der Kulturflatrate äußerte.

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.

Nepper, Schlepper und Bauernfänger in der Softwareindustrie

Das verworrene deutsche Urheberrecht bietet Abzockern und Gaunern immer wieder neue Geschäftsmodelle. Das gilt nicht nur für die Rotlichtviertel von Abmahnbetrügern sondern zeigt sich zunehmend auch in den gläsernen Bürotürmen großer Softwarehersteller, wie die Wirtschaftswoche berichtet.

Denn die Wirtschaftskrise macht sich auch in den Umsätzen der Softwarehersteller bemerkbar. IT-Projekte werden verschoben oder gekürzt, so manches an sich unnötige Programm abgeschafft, die Notwendigkeit hoher laufender Supportgebühren bei oft mäßiger Gegenleistung zunehmend kritisch hinterfragt.

Aus anderen Lebensbereichen sind wir es zudem gewöhnt, dass Produkte grundsätzlich zu funktionieren haben. Der „Support“ heißt dort Nachbesserung und ist keine extra abrechenbare Dienstleistung sondern eine Ausbesserung von Mängeln auf Kosten des Händlers oder Herstellers.

Zunehmend lassen die Softwarehäuser – insbesondere die „Big Names“ wie Micosoft, Oracle, Citrix oder SAP – durch Wirtschaftsprüfer und IT-Revisoren prüfen, ob die Unternehmen auch genügend Lizenzen haben. Dagegen wäre an sich nichts zu sagen. Allerdings gibt es keine typisierten Lizenzverträge. Während in ganz Deutschland einheitlich geregelt ist, was z.B. ein Mietvertrag ist, kann jeder Softwarehersteller nach Lust und Laune lizenzieren was und wie er will. Da zählt der eine Nutzer, der nächste Rechner, der übernächste Prozessoren und noch einer Sitzungen als Grundlage für den zu erwerbenden Lizenzbedarf. Hinzu kommen Softwarelizenzverträge, die den Umfang von Fachbüchern erreichen und ohne juristische Risikoanalyse auch von versierten IT-Leitern nicht mehr verstanden werden. Und in die bewusst „Fallen“ eingebaut wurden.

Das dahinterstehende Geschäftsmodell beschreibt Thomas Stölzel von der Wirtschaftswoche so:

In jüngster Zeit nehmen jedoch Brancheninsidern zufolge Fälle rasant zu, in denen die Softwareanbieter weit darüber hinausgehen. Dax-Konzerne und große Mittelständler klagen, dass Programmlieferanten wie Oracle und Microsoft sie teilweise zu Unrecht unter Druck setzen. Der Vorwurf: Manche Anbieter bezichtigen ihre Kunden auf Basis schwammig formulierter Verträge dramatischer Lizenzverstöße, fordern Entschädigung in Millionenhöhe, drohen gar, die Nutzung der für die Kunden oft lebenswichtigen Programme zu untersagen. Dann bieten sie ihnen einen harmloseren, aber teuren Ausweg an: mehr Lizenzen oder Wartungsverträge kaufen – auch wenn die zum Teil gar nicht benötigt werden.

…

Vor allem Hersteller, deren Neugeschäft in der Krise schwächelt, wollen sich zum Ausgleich an ihren Bestandskunden schadlos halten. Viele verdanken der Verkaufstaktik mittlerweile erhebliche Teile ihrer Einnahmen.

…

Die Softwareverkäufer werfen den Kunden Urheberrechtsverstöße vor und konstruieren ein so wirkungsvolles Bedrohungsszenario, dass die Unternehmen zwangsläufig einknicken: Im schlimmsten Fall könnten die Fließbänder Monate lang stillstehen. Oder eine Bank stünde ohne funktionierendes Handelssystem da.

…

Die Softwareanbieter bauen gefährliche Klauseln in ihre oft romandicken Verträge ein. So heißt es in den Wälzern des US-Anbieters Attachmate: Wenn der Kunde gegen eine Vertragsbedingung verstoße, könne der Lizenzgeber verlangen, dass er „alle Kopien der Software zerstört“. Um IT-Chefs zum Schwitzen zu bringen, reicht mitunter eine unbegründete Forderung: Allein die Möglichkeit, dass der Anbieter eine einstweilige Verfügung erwirkt, die die Nutzung verbietet, bedroht den Betrieb. Der Richter muss dafür die Gegenseite nicht anhören.

Das Modell basiert also auf einer Kombination aus Erpressung, juristischer Repression sowie Kriminalisierung und zieht darauf ab, aus den betroffenen Unternehmen Zahlungen herauszuholen, die sie unter normalen Umständen nicht leisten würden. „In der jetzigen gesamtwirtschaftlichen Lage kommt uns das alles sehr ungelegen“, so der Lizenzmanager eines süddeutschen Konzerns.

Insbesondere monopolisisch auftretende Anbieter, deren Produkte den Branchenstandard bilden, sind da in einer komfortablen Situation. Sowie solche, deren beim Kunden eingeführte Produkte nicht kurzfristig ersetzt oder ausgetauscht werden können.

Doch der Machtmissbrauch durch die großen Hersteller und Lizenzraubritter hat auch Folgen. Zunehmend schlagen die CIOs zurück, indem sie Produkte von Lizenzraubrittern austauschen, Knebel-Suppportverträge nicht mehr verlängern, verstärkt auf Anbieterunabhängigkeit achten und zunehmend quelloffene sowie lizenzkostenfreie Software einsetzen.

Vorbild ist da die bayerische Landeshauptstadt München. Sie stellt im Rahmen ihres LiMux-Projektes über einen längeren Zeitraum hinweg ca. 14.000 Arbeitsplatzrechner sowie ihre Server-Infrastruktur auf Linux um. Die Zahl an kommerziellen Anwendungen, von denen jede eine eigene Lizenzbürokratie samt juristischer Risikoeinschätzung und Folgeaufwänden für das Lizenzmanagement mit ins Unternehmen einschleppt, wurde so bereits drastisch reduziert.

Revisionssicheres Testen von Software

Regulatorische Auflagen wie Basel II, Solvency II oder EuroSOX fordern von Unternehmen zunehmend (IT-)Systeme und Verfahren zur Kontrolle von Risiken zu etablieren. Dabei wird meist auch verlangt, alle Veränderungen an diesen Systemen revisionssicher zu protokollieren und zu dokumentieren. Das bringt neue Anforderungen für das Testen solcher Systeme mit sich, da auch Durchführung und Ergebnisse von (funktionalen) Softwaretests durch dazu autorisierte Personen entsprechend zu protokollieren und zu dokumentieren sind.

Testing-Tools sowie Testmanagement werden dadurch compliance-relevant.

Konkret geht es in der Praxis dann meist darum, Echtheit, Integrität und Vertraulichkeit aller im Testverlauf anfallenden Informationen auch über längere Zeiträume hinweg sicherstellen und Prüfern gegenüber nachweisen zu können. Dabei spielen Verfahren zur revisionssicheren Langzeitarchivierung von Daten, Verschlüsselung mit starker Kryptografie, Signierung mit qualifizierten elektronischen Signaturen sowie der Aufbau (oder das Mieten) entsprechender Trust-Center-Architekturen eine Rolle. Ebenso Versionierung und nachvollziehbare Ergebnissicherung jedes Teilschrittes, durch den sich etwas ändert.

Testen entsprechender Softwareprodukte wird dadurch organisatorisch anspruchsvoller und aufwendiger. Dazu werden auch entsprechend weiter reichende Funktionalitäten in den Testwerkzeugen und Frameworks benötigt, worauf Anbieter entsprechender Software bereits mit neuen Produkten reagiert haben.

Desweiteren macht es Sinn, dort wo häufiger getestet werden muss oder das Testen von compliance-relevanten Softwareprodukten ansteht, ein echtes Test-Center als Dienstleistungseinheit im Unternehmen zu etablieren und so die Qualitätssicherung aus dem Entwicklungsprozess herauszulösen. Dies kann auch ein Beitrag zur weiteren Professionalisierung und Systematisierung der Softwarequalitätssicherung sein.

Daher bieten auf Softwaretest und Testmanagement spezialisierte Unternehmen das Test-Center zunehmend aus Outsourcing-Dienstleistung für Dritte an. Denn viele compliance-relevante Branchenanwendungen werden  von kleineren oder mittleren, stark produktbezogenen Firmen entwickelt, die sich den Aufbau einer solchen Infrastruktur nicht leisten können oder wollen.

ICANN-Sicherheitsexperten kritisieren DNS-Manipulationen durch Provider

Wer hat das nicht schon erlebt: Man vertippt sich bei einer Internet-Adresse und bekommt eine DNS-Fehlermeldung „Adresse konnte nicht gefunden werden“ im Browser angezeigt. Daraus lässt sich meist sofort erkennen, dass man Mist eingetippt hat. Es ist aber auch möglich, dass stattdessen eine Werbeseite voller Links vom Provider eingeblendet wird. Diese – bei existierenden, aber noch frei verfügbaren Domains schon übliche – Praxis greift zunehmend auch bei der Beantwortung von DNS-Adressfehlern um sich. Diese Linkseiten werden von manchen Registraren und vermehrt auch von Internetzugangsprovidern wie etwa T-Online zwischengeschaltet. So lassen sich Kunden auf ein eigenes Portal locken und Traffic für Werbezwecke generieren. Diese Unsitte ist auch als „Wildcarding“ bekannt.

Durch solche „Umleitungen“ werden allerdings Kernfunktionen des DNS sowie viele klassische Dienste gestört. So werden beispielsweise nicht zustellbare E-Mails nicht mehr zurückgesandt, so dass ein Mailversender nichts von der Unzustellbarkeit erfährt. Dadurch wird auf Dauer das Vertrauen ins Internet und seine Dienste untergraben. Zudem werden so auch mögliche Schlupflöcher für neue Angriffe auf IT-Infrastrukturen eröffnet.

Ram Mohan, CTO von Afilias, stellte kürzlich bei einer Konferenz der ICANN in Sydney einen Bericht (PDF, 45 KB) des Sicherheitsausschuss der ICANN vor, in dem er diese Praxis der DNS-Manipulation kritisiert.

Darin fordert er auch, dass die ICANN bei der Einführung neuer Internet-Adresszonen (TLDs) dieser Praxis einen Riegel vorschiebt. Auch bei bestehenden TLD-Registries sollten derartige Verbote die Regel werden, so der Bericht.

Die ICANN könne die Einhaltung von Standards nicht erzwingen, das könnten nur lokale Regulierer, sagte Jaap Akkerhuis, Mitglied im Sicherheitsausschuss. Eine Telefongesellschaft könne auch nicht in Eigenregie Rufnummern umleiten, ähnlich hätte es seiner Meinung nach auch bei IP-Adressen zu sein. Allerdings kann die ICANN diesen lokalen Regulierern und Providern durchaus Vorgaben machen. Die Diskussion über das Problem ist jedenfalls in den zuständigen Fachausschüssen der ICANN angekommen.

Das Thema ist heikel, da in den ICANN-Fachremien bereits seit langem kontrovers über die Einführung neuer TLD’s diskutiert wird und zahlreiche Interessensgruppen dabei im Spiel sind.