goldene regeln der it-sicherheit bei der …...gute fehlerbehandlung (fail securely) es lassen sich...
Post on 28-Jul-2020
0 Views
Preview:
TRANSCRIPT
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)
OWASP
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
Ü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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„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
10 Goldene Regeln für Auftraggeber
Rollenspezifische Regeln
10 Goldene Regeln für Entwickler
Einleitung und Motivation
OWASP
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
Sichere Einstellungen
Sichere VoreinstellungenAlle Benutzerkennungen, Passwörter undVerschlüsselungsschlüssel änderbar!Machen Sie es einfach!Sicherheitsdokumentation
OWASP
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
10 Goldene Regeln für Entwickler
10 Goldene Regeln für Auftraggeber
Rollenspezifische Regeln
Einleitung und Motivation
OWASP
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„10 Goldene Regeln der IT-Sicherheit“(2 von 4)
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„10 Goldene Regeln der IT-Sicherheit“(3 von 4)
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
„10 Goldene Regeln der IT-Sicherheit“(4 von 4)
Gesamtübersicht aller „10 Goldenen Regeln“ für alle Rollen
Ausführliches Detaildokument auf der Secologic-Seite
Secologic
10 Goldene Regeln für Auftraggeber
Rollenspezifische Regeln
10 Goldene Regeln für Entwickler
Einleitung und Motivation
OWASP
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
OWASP Germany 2008 ConferenceGoldene Regeln der IT-Sicherheit bei der Beauftragung und Erstellung von SoftwareDr. Boris Hemkemeier, Patrick Hildenbrand, Tom Schröer
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
top related