SAP Infotag: Security / Erlebe-Software 07-2014

copyright by mindsquare GmbH

| We love IT!

02.10.2014 Seite 1Wir sind mindsquare – We love IT!

Sicherheit im

eigenen Hausmindsquare Infoveranstaltung

Ingo Biermann


Security für Business-Systeme

Ist Sicherheit im Bereich der Geschäftssysteme

überhaupt ein Thema?

Seite 202.10.2014 mindsquare – We love IT!


Woher kam die Fehleinschätzung?

„Unser ERP ist nur intern verfügbar.“

„Hacker kennen sich mit SAP gar nicht aus.“

„Sicherheit ist Sache des Lieferanten.“

„Wir haben ein Berechtigungskonzept.“



Mythos 1: Nur intern verfügbar

Unser SAP System ist nur intern im Haus zugreifbar.

Wie soll ein Angreifer überhaupt drankommen?

Das galt früher einmal, heute:

Webserver stehen im Internet

Online Datenaustausch mit Geschäftspartnern

Serviceverbindung zur SAP

Clients der Anwender sind mit dem Internet verbunden



Mythos 2: Hacker kennen sich damit nicht aus

Hacker-Kids bedrohen nur die populäre Software:

Windows, Handys, usw.

Gilt nicht im kommerziellen Umfeld:

Motivation für Angriffe: Was kostet mich das und was

gibt es zu gewinnen?

Bei Know How Abfluss sind 70% sogenannte

Innentäter*


*Quelle: Bundesamt für den Verfassungsschutz, 2010


Mythos 2: Hacker kennen sich damit nicht aus

Hacker-Kids bedrohen nur die populäre Software:

Windows, Handys, usw.



Mythos 3: Sicherheit ist Sache des Lieferanten

Um die Sicherheit der SAP Systeme

kümmert sich SAP

Security Patches der SAP werden in der Regel nicht

vollständig und sofort eingespielt

Jeder SAP Kunde hat mehr oder

weniger große Teile

Eigenentwicklungen im System

Am Ende ist das Unternehmen

verantwortlich, das den Code

ausführt



Mythos 4: Rollen und Berechtigungen reichen aus

Wir haben ein Berechtigungskonzept!

Hervorragend! Darüber hinaus gilt:

im Bereich Eigenentwicklung

müssen Berechtigungen explizit geprüft werden

Entwickler

machen Fehler



Sicherheit im eigenen Haus

Die einfachen Dinge

richtig machen!



Typische Architektur

von SAP Anwendungen:

Jede dieser Ebenen ist

für die Sicherheit

relevant.

Das eigene Haus

Access Layer

Applikations UI

Services

Standard Business Logik

Datenbank



Die häufigsten Schwachstellen im ABAP Coding

ABAP Command Injection

OS Command Injection

Native SQL Injection

Improper Authorization

Directory Traversal

Direct Database Modifications

Cross-Client Database Access

Open SQL Injection

Generic Module Execution

Cross-Site Scripting

Obscure ABAP Code

Dazu SAP Notes: 1520356, 887168, 944279, 822881, 1497003


Quelle: http://www.bizec.org/wiki/BIZEC_APP11


Problemklassen

Einfacher gesagt:

Es gibt zwei entscheidende Problemklassen:

1. fehlende oder fehlerhafte Berechtigungsprüfungen

2. Injection Probleme



Fehlende oder fehlerhafte Berechtigungsprüfung

Es liegt in der Verantwortung des Entwicklers, die

Berechtigungsprüfung auszuführen.

Ein Beispiel:

Der Befehl CALL TRANSACTION führt eine Transaktion

aus. Ohne Berechtigungsprüfung.

Die Prüfung mit AUTHORITY_CHECK_TCODE ist dem

Entwickler überlassen.




Fehlende oder fehlerhafte Berechtigungsprüfung


Authority Check



ABAP Authority Check

Berechtigungsprüfung mit dem ABAP Mechanismus

Authority Check.

keine eigene Berechtigungsprüfung If sy-uname eq 'SNOWDEN'

Weitere SAP API nutzen

immer explizit programmieren

alle Felder füllen (Pattern nutzen)

Das Wichtigste: Die Rückgabe

auch prüfen!



SQL Injection



SQL Injection



Robustheit der Anwendung

Diese Probleme lassen sich auf das Prinzip der

Robustheit zurückführen.

Robustheit im Allgemeinen heißt

Fehler müssen richtig behandelt werden.

dazu gehört auch die Prüfung von Berechtigungen

Änderungen im Umfeld nicht berücksichtigt

sich nicht darauf verlassen, das Daten immer den Gut-Fall

wiederspiegeln



Robustheit der Anwendung

Robuste Anwendungsentwicklung:

Zusatzaufwand beim Design

Zusatzaufwand bei der Entwicklung

Zusatzaufwand beim Testen

Aufwand zahlt sich aus „on the long run“

Nicht nur aus Sicherheitsgründen

auch bzgl. Datenqualität

Aufräumarbeiten in den Daten sind extrem aufwändig



Die einfachen Dinge richtig machen

Grundsätze für die robuste Entwicklung

Durchgehende Fehlerbehandlung. Auch im Batch.

sy-subrc immer prüfen, genau wie andere Rückgabewerte und

Exceptions auch

Variablen initialisieren

Eingaben validieren, bevor sie verwendet werden

Keine hart codierte Abhängigkeiten und Voraussetzungen

Alles testbar machen

Jeder Codeteil wird durchlaufen

systematische Testfälle

automatisierte Tests



Werkzeuge für Code Qualität

Die Werkzeuge dafür sind

Entwicklungsrichtlinien und Checklisten

Changemanagement Prozesse: Testmanagement, Code Reviews

Automatische Codeprüfung

Syntax Checker > SLIN > SAP Code Inspektor

Eigene Erweiterung des Code Inspectors

umfangreiche kommerzielle Tools zur Codeanalyse



Die Umsetzung

Code Qualität wird im Entwicklungsprozess angelegt

Die Einführung kann nur schrittweise erfolgen:

Definition von Zielen und der Roadmap

Schulung und Know How Aufbau bei Entwicklern

Einphasen in den Entwicklungsprozess für Neuentwicklungen

Aufräumarbeiten im bestehenden Coding

Kontinuierliche Prüfung

Get Clean Stay Clean






für die Sicherheit

relevant.

Das eigene Haus

Access Layer

Applikations UI

Services


Datenbank



Know the link!



Webbasiertes UI

Webapplikationen haben ein neues Angriffsfeld

eröffnet und weiten sich immer weiter aus.

SAP Web Dynpro, SAP BSP, SAP UI5 Anwendungen

sind per URL aufrufbar.




Kiss of Death für Java Web Dynpro




Webbasiertes UI

Webapplikationen haben ein neues Angriffsfeld

eröffnet und weiten sich immer weiter aus.

SAP Web Dynpro, SAP BSP, SAP UI5 Anwendungen

sind per URL aufrufbar.

„Security by obscurity“

ist hier kein valides Konzept.



Berechtigungsprüfung bei Web Dynpro ABAP

ABAP GUI Transaktionen sind durch die S_TCODE

Berechtigung geschützt.

Für Web Dynpro Applikationen gilt das per Default nicht.

Aufruf des ersten Bildes ist möglich.




Web Dynpro ABAP Beispiel


Berechtigungsprüfung bei Web Dynpro ABAP

Eigene Berechtigungsprüfung einbauen

S_START für Web Dynpro aktivieren (ab Basis

Releases 7.03 and 7.30).

Bitte vorher die Rollen entsprechend anpassen!



SAP Screen Personas


[bild]


SAP Screen Personas

Macht SAP GUI Transaktionen webfähig und individuell gestaltbar

Verringerung der Komplexität

Verbesserung der Übersichtlichkeit

Teilautomatisierung von Abläufen

ohne Programmierung

ideal für den Rollout auf neue Benutzergruppen und Gelegenheits-

User

Mit aktueller SAP Business Suite kostenlos verwendbar



SAP Screen Personas

Was bedeutet das für die Sicherheit?

Bei einer neuen Oberfläche mit Web Dynpro oder SAP UI5 werden

die Berechtigungsprüfungen des Servicelayers verwendet und die

Oberfläche neu geschrieben

Screen Personas verändert nur das Erscheinungsbild

Berechtigungsprüfungen und Eingabeprüfungen der bestehenden

GUI Implementierung bleiben aktiv

Informieren Sie sich über unsere Lösung: SAP endlich

benutzerfreundlicher mit SAP Screen Personas

http://erlebe-software.de/solutions/sap-screen-personas


http://erlebe-software.de/solutions/sap-screen-personas





für die Sicherheit

relevant.

Das eigene Haus

Access Layer

Applikations UI

Services


Datenbank



Portal und NWBC als L-Shape Technologie

Auf der obersten Ebene definieren Portal und NWBC

den Einstiegspunkt für die Anwender

single Point of access

role based access

single sign on



Single Sign On Architektur

In einer Portallandschaft spielt das zentrale System ein

besondere Rolle

wegen des SSO ist es die einzige Autorität für Authentifizierung

wegen der fehlenden Datenhoheit gar keine Autorität für

Autorisierung

Portalberechtigungen sind keine Berechtigungen



Beispiel: Universal Worklist

Die UWL führt Workflow-Aufgaben aus verschiedenen

Systemen zusammen.

Jedes Backendsystem muss beim Serviceaufruf testen,

ob und was der Anwender sehen darf.

Jedes Applikations-UI muss prüfen, ob der Anwender eine

Aktion durchführen darf.




Beispiel Universal Worklist


Single Sign On Architektur

Warum ist SSO trotzdem ein Sicherheitsgewinn?

Usability bringt auch Sicherheit

Nur ein Passwort

oder mit PKI gar kein Passwort

Anwender nutzen weniger einfache Passworte und nicht überall

das Gleiche

Passwort wird nur einmal übertragen

Zentrale Möglichkeit zum Sperren



Die einfachen Dinge falsch machen…

Beispiel:

Wer Usermanagement-Berechtigungen im zentralen

System hat, kann sich lokale User anlegen.

Damit ist SSO in weitere Systeme möglich

Identitätsklau





SAP Portal

SAP WebFlow Connector Non-SAP-UWL-Connector




SAP Portal

SAP WebFlow Connector Non-SAP-UWL-Connector

Wer bist du?

Was darfst du?





für die Sicherheit

relevant.

Das eigene Haus

Access Layer

Applikations UI

Services


Datenbank



Sicherheit im eigenen Haus

Die einfachen Dinge

richtig machen!



Fazit

Die einfachen Dinge richtig machen

Code Quality im Entwicklungsprozess verankern

SAP Berechtigungsmechanismen nutzen

User Interface Technologien nicht vergessen

SSO Infrastruktur aufbauen



Custom Solutions – Ihre Lösung!

Nur Sie wissen mit welcher passgenauen Erweiterung

Sie Ihr SAP noch besser machen können.

Wir sind Ihr Dienstleister für diese neue SAP Applikation.

Von der Idee bis zum erfolgreichen Go Live:

Schon in der Ideenphase unterstützen wir Sie

bei der Definition der Anforderungen

Die Konzeption und Umsetzung erfolgt durch unsere SAP Experten

Sie erhalten die Komplettlösung – Ihr Projekt machen wir zu

unserem Projekt

Mit professionellem Projektmanagement

sicheren wir den Projekterfolg

Seite 4802.10.2014 Wir sind mindsquare – we love IT!


Auf unserer Fachbereichsseite finden Sie

unser Angebot, viel Know How und Artikel

von unserem Team: http://erlebe-software.de

Seite 49

Ihr Ansprechpartner

Ingo BiermannSenior SAP Consultant

Fachbereichsleiter

[email protected]

Wir sind mindsquare – we love IT!02.10.2014