Goldene Regeln der IT-Sicherheit bei der …...Gute Fehlerbehandlung (Fail securely) Es lassen sich...

Copyright © Commerzbank and SAPPermission is granted to copy, distribute and/or modify this documentunder the terms of the CC Attribution-Share Alike 2.5 license (OWASPWebsite license)

The OWASP Foundation

OWASP

http://www.owasp.org

http://www.owasp.org/index.php/GermanyOWASP Germany 2008 Conference

Frankfurt, 25.11.08

Goldene Regeln der IT-Sicherheitbei der Beauftragung undErstellung von Software

Dr. Boris Hemkemeier, CommerzbankPatrick Hildenbrand, SAPTom Schröer, SAP

Secologic

Einleitung und Motivation

Rollenspezifische Regeln

10 Goldene Regeln für Entwickler

10 Goldene Regeln für Auftraggeber

OWASP

OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer

Dieser Vortrag und das dazugehörige White-Paper wurdenvon der Commerzbank AG und der SAP AG im Rahmen desSecologic Forschungsprojektes erstellt, (Laufzeit 2005 -2007), nähere Informationen unter www.secologic.de.

Wir bedanken uns beim Bundesministerium für Wirtschaftund Technologie für die Förderung dieses Projektes.Die Verwendung der Inhalte dieser Folien ist unter Verweisauf die Urheber ausdrücklich erwünscht.

Secologic Projektkonsortium

SAP AG Commerzbank AGEurosec GmbH TU Hamburg

Die Autoren des Whitepapers sind

Dr. Kai Buchholz-Stepputtis (Commerzbank) Tom Schröer (SAP)

Dr. Boris Hemkemeier (Commerzbank) Rosemaria Giesecke (SAP)

http://www.secologic.de/

OWASP


Übersicht Projektergebnisse Secologic

Ergebnisse zu Themen rund umdas Thema Anwendungssicherheit.

Unterschiedliche DetailstufenÜberblickAnleitungenSchulungsunterlagenImplementierung einer Reiheprototypischer LösungenLernanwendung SecologicTrain

UnterschiedlicheDarstellungsformen

WissenschaftlicheVeröffentlichungenPragmatische Lösungsansätze

Vergleich von verschiedenenLösung eines Geschäftsszenariosim Web-Services

ErgebnisstrukturSicherheit im Softwarelebenszyklus

Goldene Regeln und organisatorischeMaßnahmen

Sicherheit in ApplikationenProgrammiersprachen

PHP, Java, C/C++, Javascript, Web-Services

Angriffe und LösungenSession Management, XSS, SQL Injection,Cross Site Request Forgery/SessionRiding/Session Hijacking

SicherheitstestsVergleich von TestwerkzeugenPenetrationstests, Testen von Web

Services

OWASP


Warum „10 Goldene Regeln“ (allgemein) ?

Allgemeine Zielstellung „Goldener Regeln“:„Goldene Regeln“ („Golden Rules“) sollen kurz und verständlichauf die wichtigsten Kernpunkte hinweisenZahl „10“ als guter, gerade noch „verdaulicher“ AnsatzBeginn mit solchen „Best Practices“ kann manchmal mehrbewirkenals mehrere „Festmeter“ an DokumentenNach erster Sensibilisierung und „Awareness“ sind weitereVertiefungen und Konkretisierungen immer noch möglichOft ist eine solche erste Sensibilisierung mit handlichen kurzenRegelnsogar der beste erste SchrittDas gilt je nach Zielgruppe auch für IT-Sicherheit

OWASP


„10 Goldene Regeln“ auch für IT-Sicherheit ?

IT-Sicherheit wird oft schwarz/weiß (unsicher/sicher) betrachtet,das trifft in der Praxis aber in der Regel nicht zuAuch bei IT-Sicherheit sind „Best Practices“ und „GoldeneRegeln“ als erster Ansatz aber sinnvollOhnehin unterliegen nicht alle Anwendungen immer denallerhöchsten Sicherheitsanforderungen

„Best Practices“ machen Sinn auch für „Hochsicherheits-Produzenten“wie renommierte Banken oder Softwarehersteller ;-)Hier folgt dann immer auch Vertiefung und Detailarbeit, dafürgibt es dann aber entsprechende SpezialistenAber auch hier gibt es Klientel, denen die Thematik am bestenzunächst mit verständlichen Regeln nähergebracht werden kann

OWASP


„10 Goldene Regeln der IT-Sicherheit“

Inhaltlicher Schwerpunkt des Secologic Projektes:Entwicklung sicherer SoftwareErster Ansatz im Secologic Projekt:„10 Goldene Regeln der IT-Sicherheit“ für EntwicklerAusgangsbasis:

Verschiedene „Top Ten“ Ansätze für „Software Coding“Ansätze z.T. heterogen, überwiegend auch englischsprachigZ.T. eher an „Top Ten Vulnerabilities“ orientiert oder zu umfangreich(lesenswert hier aber auf alle Fälle „OWASP Top Ten“ und „OWASPGuide“)

Erste Zielstellung dazu im Secologic Projekt:Deutschsprachige KonsolidierungSchwerpunkt auf lösungsorientierte „Goldene Regeln“ als „BestPractices“

Secologic





OWASP


Misstrauen Sie jeder (Benutzer-) Eingabe

Jede Eingabe kann unerwartet sein. Eingaben können nicht nur vomGUI kommen – sondern auch aus Dateien und Serviceaufrufen. Einblindes Vertrauen ist heute die häufigste Sicherheitsschwachstelle inApplikationen.Ablauf für die Prüfung

Alles in eine kanonische Form bringenBekannte Angriffe filtern (Blacklist) (wichtiger Schritt, aber nichtausreichend!)Nur erwartete Eingaben annehmen (Whitelist)

GrundregelnAlle Eingaben prüfenAlle Steuerzeichen erkennenAm Server prüfen

OWASP


„Minimale Rechte-Prinzip“

Zu viele Rechte sind ein SicherheitsrisikoBenutzern stets nur die Berechtigungen geben, die sie zurErfüllung ihrer Aufgabe wirklich brauchenBerechtigungen nicht hart codieren, sondern konfigurierbarmachenGibt es unterschiedliche Adminstrationsaufgaben?„Minimale Rechte-Prinzip“ gilt auch für:

Technische BenutzerBetriebssystem- /DatenbankbenutzerZugriffsberechtigungen im Dateisystem

Vorsicht auch, wenn auf Daten oder Funktionen über mehrereWege zugegriffen werden kann

OWASP


Keine unnötige Veröffentlichung voninternen Daten!

Achten Sie darauf, wer welche Daten zu sehenbekommt.Auch Stellen außerhalb derAnwendungsfunktionen berücksichtigen wie :

Fehlermeldungen mit zu vielen SysteminternasCookies und URLsstandardmäßig aktivierte Debug-FunktionenSysteminformationen, PatchstandLogdateien

OWASP


Nutzen Sie die Erfahrung von anderen (do’sund dont’s)

Andere Entwicklungsprojekte haben schon eine ganzeReihe Erfahrungen gemacht.Viele dieser Erfahrungen sind schon von Teamkollegenoder andern Mitarbeitern gemacht worden.Weitere sind käuflich erhältlich oder sogar frei verfügbar.

Nutzen Sie diese Erfahrungen und machen Sie nicht diegleichen Fehler, die andere schon gemacht haben.

Es gilt:Erfinden Sie Schwachstellen nicht neuEntwickeln Sie keine eigenen Sicherheitsfunktionen

OWASP


Sichere Einstellungen

Sichere VoreinstellungenAlle Benutzerkennungen, Passwörter undVerschlüsselungsschlüssel änderbar!Machen Sie es einfach!Sicherheitsdokumentation

OWASP


Niemals „Security by Obscurity“ und niemals„Hintertüren“

„Security by Obscurity“Vertrauen Sie niemals darauf, dass Ihre Software nichtangreifbar ist nur weil der Quellcode bzw. dieSicherheitsmechanismen unbekannt sindSoftware muss auch dann noch gut sein, wenn der Quellcodebekannt würdeProblem: „obskure“ Lösungen sind häufig auch intern nichtdokumentiertBsp.: Selbstgeschriebene Verschlüsselungsverfahren

Keine „Hintertüren“versteckte Funktionalitätenversteckte oder undokumentierte Parameterundokumentierte Aufrufe über Benutzereingaben

OWASP


Gute Fehlerbehandlung (Fail securely)

Es lassen sich nicht alle möglichen Situationeneiner komplexen Anwendungslandschaftvorhersehen oder testen.Darum wird es im Betrieb Fehlersituationengeben. Stellen sie sich auf diese Situationen ein.Stellen Sie vor allem sicher, dass die Anwendungim Fehlerfall in einen sicheren Zustand übergeht(oder ihn behält) und nicht "unsicher" wird.

OWASP


Denken Sie an Nachvollziehbarkeit (Trace,Audit, Logs)

Protokollieren Sie alles, was in der Anwendung ansicherheitskritischen Ereignissen auftritt. Das sind zum Beispiel:

Serverstarts und –stoppswesentliche Konfigurationsänderungenunberechtigte ZugriffsversucheZugriff auf besonders sensible Datenalle Änderungen in der Benutzer- und Berechtigungsverwaltung

Denken Sie auch an die Archivierung dieser Daten. Protokolle, dieschon nach kurzer Zeit überschrieben werden, können danach nichtmehr nachvollzogen werden.Denken Sie daran, dass in Protokollen vertrauliche Daten stehenkönnen und implementieren Sie Zugriffsberechtigungen.

OWASP


Machen Sie Code-Reviews

Planen Sie als Entwicklungsschritt Code-Reviews durcheinen Kollegen fest ein. Diese Code-Reviews haben 2wesentliche Vorteile:Es gibt eine 2. Meinung zur vorgeschlagenen Lösung. OhneVorprägung durch sehr intensive Vorüberlegungen kann ein„unabhängiger“ Kollegen Sicherheitsschwachstellen häufigeinfacher finden.Die Qualität des Codes verbessert sich nach und nach, weil jederEntwickler weiß, dass:

sein Code die Reviews durch andere „überleben“ muss undjeder aus den Fehlern von Kollegen lernt und darum nach und nachnachvollziehbareren Code schreibt.

OWASP


Rechnen Sie mit Schwachstellen: sehen SiePatches vor

Es können auch nach Auslieferung der Softwareneue Bedrohungsszenarien auftreten.Es sollte für den Kunden ein nutzerfreundlichesEinspielen eines Patches ermöglicht werden.Zudem sollte der Kunde feststellen können, ob erden notwendigen Patch schon eingespielt hat.

Secologic





OWASP


„10 Goldene Regeln der IT-Sicherheit“

Erster Schritt im Secologic Projekt:„Zehn Goldene Regeln der IT-Sicherheit“ für EntwicklerSiehe auch eben gehaltener Präsentationsteil

Weitere Praxiserfahrung aber:Entwickler handeln nur im Rahmen der Vorgaben einerProjektleitung, die ihrerseits wiederum im Auftrag einesAuftraggebers tätig istFazit: Die eigentlichen Hebel für sichere Software liegenwoanders

Außerdem weitere Zielstellung im Secologic ProjektNutzen möglichst auch für MittelstandNutzen möglichst auch dort, wo nicht per se fundiertesKnowhow bzgl.IT-Sicherheit vorausgesetzt werden kann

OWASP


„10 Goldene Regeln der IT-Sicherheit“(1 von 4)

Exemplarischer Entwicklungsprozeß:

Keine Präjudizierung für bestimmtes Entwicklungsparadigma,Betrachtung hier vielmehr:Welche Rollen gibt es typischerweise im Softwareerstellungsprozeß ?Nebenthesen und Erfahrungen

Je früher Sicherheit im üblichen Erstellungsprozeß integriert ist, desto besserOptimalerweise ist IT-Sicherheit kein “losgelöster”, “isolierter” ProzeßOptimalerweise existieren in allen Teilprozessen geeignete Sicherheitspakete

Realisierung(Test)

Betrieb(Wartung)

Fachkonzept Design Integration(Test)Spezifikation

OWASP



Welche Rollen gibt es immer, unabhängig vomjeweiligen Entwicklungs-Paradigma oder konkretenErstellungsprozeß:

Rolle IT-EntwicklerRolle IT-ProjektleiterRolle Auftraggeber

Welche Rollen kann es je nach Projektvolumen undKomplexität zusätzlich geben:

Rolle IT-ArchitektRolle „Tester“Ggf. weitere Rollen

OWASP



Lösungsansatz:Rollenspezifische Ausgestaltung der „Goldenen Regelnder IT-Sicherheit“Ausgangsbasis:

Im Prinzip kaum Quellen für solche rollenspezifische „Bestpractices“Nutzen auch für Mittelstand und Non-IT-SicherheitsexpertendenkbarFazit: Tatsächlicher Mehrwert generierbar

Vorteil:Ganzheitliche Betrachtung, nicht nur Fokussierung auf „Coding“Jeder benötigt nur die für seine Rolle zugeschnittenen Regeln

OWASP



Gesamtübersicht aller „10 Goldenen Regeln“ für alle Rollen

Ausführliches Detaildokument auf der Secologic-Seite

http://www.secologic.org/downloads/software/070205_10GoldenRules_SAP_CoBa_V1.pdf

Secologic





OWASP


Regel 1: „Denken Sie an geschäftlicheKonsequenzen von IT-Sicherheitsfragen“

Entscheidender Maßstab sind geschäftliche AnforderungenWesentliche Sicherheitsanforderungen z.B. Vertraulichkeit und IntegritätTypische und geeignete Fragestellungen:

„Was wäre wenn ?“„Welcher Schaden könnte eintreten wenn ?“

Monetäre Konsequenzen bei Verletzung der Sicherheitsziele, z.B.:Betroffene Informationen, mögliche Szenarien und BedrohungenEventuelle Geschädigte, „Nutznießer“ und „Interessenten“

Beispiele:„Was wäre wenn“ der Konkurrenz die Einkaufskonditionen bekannt wären ?Ab welcher Zeit kann der Ausfall des Systems unternehmenskritisch werden?

OWASP


Regel 2: „Berücksichtigen Sie gesetzlicheund regulatorische Anforderungen“

An Gesetzen und Regularien „kommt man nicht vorbei“Einige einschlägige Gesetze und Regularien

National: HGB, BDSG, GdPdU, KontraG, GoB, IDW, KWG, ....International: EU-Richtlinien, SOX, ....

Beispiele für gesetzliche und regulatorische Anforderungen:Aufzeichnungs- und AufbewahrungspflichtenDatenschutzbestimmungenEinschränkung bei Einsatz bestimmter Technologien (z.B.Verschlüsselung)Spezielle Anforderungen zuständiger AufsichtsbehördenSpezielle Vorgaben bei Outsourcing (z.B. Banken KWG 25a)

Allgemein:Im Zweifel unbedingt juristische Expertise hinzuziehen

OWASP


Regel 3: „Definieren Sie fachlicheZuständigkeiten, Rollen und Prozesse“

Die Software soll letztlich Ihre Geschäftsprozesseunterstützen

Für Ihre eigenen Prozesse müssen Sie aber selber sorgen, dieSoftware kann und soll Sie dabei aber unterstützenSie kennen Ihre Zuständigkeiten, Rollen und Prozesse am bestenDie IT kann daraus Nutzer- und Berechtigungs- undRollenkonzepte ableiten:

„Need to know“-PrinzipUnterschiedliche RollenUnterschiedliche Rechte, z.B. keine, lesend, schreibend, ...

Beispiele für ggf. getrennte fachliche Rollen:Auftragserfassung, -genehmigung, -freigabe, Inkasso, Kontrolle

OWASP


Regel 4: Berücksichtigen Sie auchAnforderungen an die Nachvollziehbarkeit

Nachvollziehbarkeit ist auch ein SicherheitszielFragestellung: Inwieweit müssen Daten, Zugriffe, Ergebnisseund Einzelschritte aus der Vergangenheit nachvollziehbar seinBeispiele für entsprechende Fragestellungen:

„Wer hatte vor 7 Monaten mit welchen Rechten Zugriff auf dieAuftragsdaten und wer hat was genau am Tag xy gemacht“Rechtliche Anforderungen an die Nachvollziehbarkeit bestimmterSachverhalte und Informationen, z.B. bilanzrelevante Daten (vgl.auch Regel 2)Nachvollziehbarkeit von Zugriffen auf personenbezogene DatenAufbewahrungsfristen

Die IT kann daraus ein Logging- und Archivierungskonzeptableiten

OWASP


Regel 5: Verfügbarkeit und BusinessContinuity können spezielleSicherheitsanforderungen sein

Zwei grundsätzliche Arten von SicherheitsgefährdungenTemporäre „Nicht-Verfügbarkeit“

„Wie lange kann ein Unternehmen temporär ohne gewisse Anwendungenoder Informationen seinen entsprechenden Geschäftsbetrieb aufrechterhalten

Schlußfolgerungen für IT z.B.:Wiederanlaufzeiten, Availabilitykonzept, USV, Wartungs- undSupportverträge

Totalverlust, KatastrophenfallTotalverlust bestimmter Daten kann Existenz des Unternehmens gefährden

Schlußfolgerungen für IT z.B.:Backup-Konzept, Datenlagerung, ggf. gar Notfalllokation

OWASP


Regel 6: Die Sicherheitsanforderungensollten bekannt, vereinbart und fixiert sein

Gerade bei Sicherheitsanforderungen gibt es oft MißverständnissseIm Prinzip zählen im Endeffekt nur klare Vereinbarungen

Häufig anzutreffende Ausgangssituation:Die Umsetzung gewisser Sicherheitsanforderungen bzw. –eigenschaften wirdoft „stillschweigend“ angenommen bzw. vorausgesetztWoher soll aber IT-Spezialisten per se die fachliche Bedeutung gewisserDaten klar sein ?

Schlußfolgerungen:Auch Sicherheitsanforderungen müssen explizit benannt und definiertwerdenKlärung je früher desto besserFixierung in Fachkonzept, Pflichten- oder LastenheftKlärungsprozeß führt auch zu realistischen Sicherheitsanforderungen

OWASP


Regel 7: Erfüllung derSicherheitsanforderungen sollteabnahmerelevant sein

Schriftlich formulierte Abnahmekriterien auch für SicherheitDefinition für nicht sicherheitstechnisch versierten Auftraggeber oftschwierig, mögliche konkrete Abnahmekriterien aber z.B.:

Eigene Prüfungen und Tests (soweit möglich, z.B. Rollenkonzept)Vorlage und Abnahme von Testfällen, Prüfung der ErfüllungEinbeziehung externer Kriterien, z.B. „Top Ten“ von OWASP

Ggf. unabhängige Prüfung bei sicherheitskritischen Anwendungen,Grundsätze und Empfehlungen dazu:

Nicht nur „Hacking“ sondern „White Box“-Vorgehen incl. ReviewAngekündigt und im Einklang mit dem ursprünglichen Auftragnehmer

OWASP


Regel 8: Beachten Sie Restrisiken undtreffen Sie ggf. Vorkehrungen

100%ige Sicherheit nicht erreichbar und alsZielvorstellung auch nicht wirtschaftlich

Betrachtung und Analyse der wesentlichen RestrisikenEs existieren auch bewusst in Kauf genommene RestrisikenPräferiert: Aufstellung von vorneherein vereinbart

Alternative Überlegungen für Vorkehrungen bei EintrittGgf. alternative nicht IT-technische Maßnahmen (z.B. Papier-Backup)Technische Maßnahmen im späteren laufenden Betrieb (z.B.Security Patches)Organisatorische Maßnahmen bei Eintritt eines der Risiken

OWASP


Regel 9: Bedenken Sie auch Ihre eigenenProzesse, organisatorischen Maßnahmen undLeute

Nicht alle Sicherheitsmaßnahmen sind Sache der ITBeispiel:

Sicherheitstechnisch ausgeklügeltes Berechtigungskonzept implementiertVergaben im späteren Betrieb aber quasi „auf Zuruf“ und ohne Überprüfung

Erforderliche eigene Maßnahmen:Geregeltes (aber auch „lebbares“) Antrags- und GenehmigungsverfahrenRegelungen für Zuständigkeitswechsel, Austritt, Löschung

Allgemein:Sicherheit läßt sich nur aufrecht erhalten, wenn sie tatsächlich „gelebt“ wird(Voraussetzung: auch „gelebt“ werden kann)Usability versus SicherheitSchulungsmaßnahmen, Sensibilisierung, „Awareness“

OWASP


Regel 10: Alles kann sich ändern, seien Siedarauf vorbereitet

Veränderungen während oder vor allem auch nach Projektablauf

Treffen Sie Regelungen für erst später offensichtlich gewordene MängelSicherheits-Updates bei Anwendung, aber auch bei StandardkomponentenNachbesserungspflichten, Wartungs- und Supportverträge„Service Level Agreements“, insbesondere auch bei externem Betrieb

Halten Sie sich auf dem Laufenden, verschiedene Einflußgrößen könnenzu Neubewertungen (ggf. Folgebeauftragungen) führen, z.B.:

Neue fachliche Gegebenheiten, Neubewertung der SicherheitsanforderungenNeue oder veränderte gesetzliche Vorgaben

Goldene Regeln der IT-Sicherheit bei der …...Gute Fehlerbehandlung (Fail securely) Es lassen sich...

Documents

Transcript of Goldene Regeln der IT-Sicherheit bei der …...Gute Fehlerbehandlung (Fail securely) Es lassen sich...