Unit-Tests, Integrationstests und Co. machen es möglich, zu überprüfen, ob entwickelte Software den funktionalen Anforderungen entspricht. Durch die zunehmende Vernetzung von Softwaresystemen und die Auslagerung von Anwendungen in die Cloud und das Internet werden aber auch Security-Anforderungen immer relevanter. Traditionelle Qualitätssicherungsmethoden laufen hier oft ins Leere. Wenn überhaupt, wird meist nur am Ende stichprobenartig getestet, ob eine Software sicher ist. Fallen Sicherheitsmängel erst so spät auf, sind sie in der Regel aber nur schwierig zu beheben, und schlimmstenfalls müssen sogar ganze Anwendungsteile neu entwickelt werden. Deshalb ist es sinnvoll, IT-Sicherheit möglichst früh im Entwicklungsprozess zu berücksichtigen, um teure Schwachstellen zu vermeiden. Aber wie können Sicherheitsrisiken frühzeitig ermittelt und bei der agilen Entwicklung berücksichtigt werden? Eine Lösung ist ein Security-Aware-Development, bei dem IT-Sicherheitsanforderungen fest in den agilen Entwicklungsprozess integriert werden.

1. carsten.cordes@hec.de
@badagent86
IT-Sicherheit und agile
Entwicklung – geht das? Sicher!

2. Wer bin ich?
M.Sc. Carsten Cordes
carsten.cordes@hec.de
• (früher mal) Duales Studium in der Bank
• Danach Informatikstudium in Oldenburg
• Gewinner der Cyber-Security-Challenge
Deutschland
• Penetrationstester
• Speaker auf it-sa, CeBIT, JAX und basta
• Leidenschaftlicher Softwareentwickler &
Hacker

3. Wir schreiben das Jahr 2017…
… und das Internet ist kein Neuland mehr.
Quelle: http://www.internetlivestats.com

4. Smart-Home
Smart-Cars
Internet-of-Things
Connected-Cars
Smart-Factory
Smart-Grid Industrie 4.0
Smart-Meters
Smart-Ecosystems
Die digitale Revolution hält Einzug…

5. DevOps
Frontend
Qualitätssicherung
Backend
Requirements
Architektur
BDD
TDD
Cucumber
Selenium
Jira
Confluence
Ansible
Docker
Microservices
Angular
Cloud
Spring
DDD
WildFly
Jenkins
TypeScript
REST
JSON
…und mit ihr steigt die Komplexität.

6. Was sind die Folgen?

7. TODO: Neue Folien einfügen!
Nicht vergessen!!!!
Es passieren
Fehler!

8. Was gibt es für Sicherheitslücken?

9. CWE/SANS Top 25
Improper Neutralization
of Special Elements
used in an SQL
Command ('SQL
Injection')
Improper Neutralization
of Special Elements
used in an OS
Command ('OS
Command Injection')
Improper Neutralization
of Input During Web
Page Generation
('Cross-site Scripting')
Missing Authentication
for Critical Function
Missing Authorization
Use of Hard-coded
Credentials
Missing Encryption of
Sensitive Data
Unrestricted Upload of
File with Dangerous
Type
Reliance on Untrusted
Inputs in a Security
Decision
Execution with
Unnecessary Privileges
Cross-Site Request
Forgery (CSRF)
Improper Limitation of a
Pathname to a
Restricted Directory
('Path Traversal')
Download of Code
Without Integrity Check
Incorrect Authorization
Inclusion of
Functionality from
Untrusted Control
Sphere
Incorrect Permission
Assignment for Critical
Resource
Use of Potentially
Dangerous Function
Use of a Broken or
Risky Cryptographic
Algorithm
Incorrect Calculation of
Buffer Size
Improper Restriction of
Excessive
Authentication Attempts
URL Redirection to
Untrusted Site ('Open
Redirect')
Uncontrolled Format
String
Integer Overflow or
Wraparound
Use of a One-Way
Hash without a Salt

10. OWASP Top 10 (2013)
Injection
Broken
Authentication
and Session
Management
Cross-Site
Scripting (XSS)
Insecure Direct
Object
References
Security
Misconfiguration
Sensitive Data
Exposure
Missing
Function Level
Access Control
Cross-Site
Request
Forgery (CSRF)
Using
Components
with Known
Vulnerabilities
Unvalidated
Redirects and
Forwards

11. OWASP Top 10 (2017)
Injection
Broken
Authentication
Sensitive Data
Exposure
XML External
Entities (XXE)
Broken Access
Control
Security
Misconfiguration
Cross-Site-
Scripting (XSS)
Insecure
Deserialization
Using
Components
with Known
Vulnerabilities
Insufficient
Logging and
Monitoring

12. Beispiel: Buffer Overflow
void input_line()
{
char line[1000];
// gets is vulnerable to buffer overflows
if (gets(line))
parse_line(line);
}

13. Beispiel: SQL-Injection
// Get the login credentials
String username = request.getParameter("user");
String password = request.getParameter("pass");
// SQL query vulnerable to SQL injection
String query = "select info from Users where user = '"+ username
+"' and password='" + password +"'";
// Execute the SQL statement
rs = stmt.executeQuery(query);

14. Beispiel: Java Deserialization of untrusted Data
# Read data from Request
InputStream is = request.getInputStream();
#Serialize Object from Data.
ObjectInputStream ois = new ObjectInputStream(is);
AcmeObject acme = (AcmeObject)ois.readObject();

15. Sind solche Sicherheitslücken noch aktuell?
Quellen: https://blogs.cisco.com/security/shadow-brokers, https://www.exploit-db.com

16. Aber das sind Einzelfälle, oder?

17. • 27 Jahre alt
• Seit 3 Monaten im Unternehmen
• Hochmotiviert, sehr engagiert
• Informatikstudium
• Soll ASP.net Anwendung
mitentwickeln
• Gute Kenntnisse in Java
• Bisher wenig in C#/.net
entwickelt
Albert Anfänger

18. Wie geht denn eine
Passwort-Vergessen-
Funktion in ASP.net?

22. https://laurent22.github.io/so-injections/

23. Warum passieren immer noch solche Fehler?

24. 1. Entwicklern fehlt das Bewusstsein

25. 1. Anforderungen an die Software nicht schriftlich festhalten. Somit kann man auch gar
nicht in die Verlegenheit kommen, Sicherheitsanforderungen definieren zu müssen.
2. Tests sind etwas für Weicheier. Ohne Sicherheitsanforderungen braucht man
Sicherheit ohnehin nicht zu testen. Sie ist schließlich kein zwingender Bestandteil einer
Software.
3. Code-Review ist viel zu aufwendig und kostet nur Arbeitszeit. Echte Männer und
Frauen schreiben sofort guten und sicheren Code. Alle anderen sind einfach unfähig.
4. Penetration Tests sind zu teuer. Wer schon einmal einen in Auftrag gegeben hat, weiß
das. Software reift ohnehin beim Kunden. Die Penetration Tests übernehmen somit die
Angreifer kostenlos.
5. Weiterbildungen im Bereich sicherer Softwareentwicklung braucht niemand. Know-how
hat man, oder man hat es nicht. Basta.
Wie man unsichere Software schreibt …
Quellen: Patrick Sauer, https://security.sauer.ninja/informationssicherheit/wie-man-unsichere-software-schreibt/

26. 2. Kunden fehlt die Bewusstsein
Wir haben keine Daten!
Wir sind kein Ziel!
Ist sowieso nur eine interne Anwendung!

27. „Wir wollen kein HTTPS für unsere Seite,
weil die Zertifikate zu teuer sind!“
(Kunde eines ~200 PT WebApp-Projektes)

28. 3. Zeit-/Budgetdruck!
Keine Code-Reviews
Keine Sicherheitstests
Keine Sicherheitsanforderungen

30. 4. Oft liegt der Fokus auf anderen
Themen!
Usability
Design
Funktionalität

31. 5. Es fehlt dediziertes Security-
Knowhow!

32. Ist Sicherheit überhaupt wichtig für uns?

33. Rechtliche Aspekte
• ISO 27001 wird für viele Unternehmen Pflicht -> Unsere Kunden!
– Bisher vor allem kritische Infrastruktur, wird sich weiter ausweiten
– Kernthema „Sicherheit“ bei der Auswahl der Dienstleister
• Softwarehersteller haften zukünftig u.U. bei unzureichenden
Sicherheitsvorkehrungen für Sicherheitslücken (Vgl. NJW 2017, 1841)
– Bei Sicherheitslücken müssen zeitnah Patches bereitgestellt werden (in
Zeitraum analog zu „Gewährleistung“)
– Softwarehersteller müssen Maßnahmen ergreifen, um Sicherheitslücken
zu vermeiden und überhaupt erst zu suchen

34. „Über alle Branchen hinweg sehen 59 Prozent
der Betriebe die IT-Sicherheit als größtes
Hemmnis für die Digitalisierung in ihrem
Unternehmen an.“ Quelle: IHK-Unternehmensbarometer zur Digitalisierung (2014)

35. Quellen: golem.de, heise.de

36. Aber wie bekomme ich meine Anwendung
denn nun sicher?

37. „Sicherheit ist kein wundersamer Feenstaub, den
Sie auf Ihr Produkt streuen können, nachdem es
programmiert wurde.”
(Paul Vixie, CEO Farsight Security) …
Also: ab wann sollte man an Sicherheit denken?
Direkt bei Projektbeginn

38. Security Developement Lifecycle (SDL)
Quelle: Microsoft
Leider Wasserfall 

39. Security Developement Lifecycle (SDL) - Agil
Quelle: Microsoft
One-Time practices
Every-sprint practices
Bucket practices
Aufstellen von Security Requirements
Security/Privacy
Risikobewertung
Analyse/Reduktion
der Angriffsfläche
Aufstellen Incident
Response Plan
Threat Modeling
Statische Softwareanalyse
Security Review
Verwedung anerkannter Tools
Aufstellen von Design
Requirements
Unsichere Funktionen vermeiden
Quality Bars/Bug Bars erstellen
Dynamische Softwareanalyse
Review und Überarbeitung der Angriffsfläche
Fuzz-Testing

40. SDL ist sehr schwergewichtig 
Alternative?

41. „Security-Aware-Development“ (SAD)
Sicherheitsaspekte werden über den ganzen
Entwicklungszyklus überprüft.

42. Ziele und Inhalte von SAD
• SAD ist ein Framework zur Entwicklung sicherer Software
• SAD ist an den Microsoft SDL angelehnt
• Sicherheitsaspekte werden über den ganzen Entwicklungszyklus
überprüft.
• Individuelle Ausgestaltung ist projektspezifisch
• Sicherheitsaspekte müssen regelmäßig überprüft und angepasst
werden
42

43. Wichtige Aspekte im SAD
Identifikation
von Sicherheits-
aspekten
Aufnahme von
Security in die
DoD
Reviews durch
Security-
Beauftragten
Durchführung
von
automatischen
Security-Tests
Durchführung
von Pentests
Review der
Sicherheits-
aspekteFestlegung von
Coding-
Guidelines
Projektstart Kontinuierlich Regelmäßig
Überprüfung
durch statische
Analysen

44. Projektstart
Identifikation
von Sicherheits-
aspekten
Aufnahme von
Security in die
DoD
Festlegung von
Coding-
Guidelines

45. Identifikation von
Sicherheitsaspekten:Threat-Modeling
1. Assets identifizieren
• Worauf hat es ein Angreifer
abgesehen?
2. Bedrohungen identifizieren
• klassisches Threatmodeling
• „Threatstorming“
3. Bedrohungen bewerten
• Eintrittswahrsch. * Schaden
• Risk Estimation Mapping
4. Maßnahmen finden
• Möglichst messbar
• Toolunterstützung prüfen
• Kosten / Nutzen prüfen

46. Aufnahme von
Security in die
DoD
Wurden die Coding-
Guidelines eingehalten?
Erkennt die Codeanalyse
keine Probleme?
Wurde ein Code-Review
durchgeführt?

47. Festlegung
auf „sichere“
Frameworks
Wird das Framework noch
aktiv weiterentwickelt?
Wie schnell wird auf
Schwachstellen reagiert?
Wer kontrolliert den Code
des Frameworks?
Wie verbreitet ist das
Framework?

48. <plugin>
<groupId>org.owasp</groupId>
<artifactId>dependency-check-maven</artifactId>
<version>3.0.2</version>
<executions>
<execution>
<goals>
<goal>check</goal>
</goals>
</execution>
</executions>
</plugin>
In Jenkins als Plugin… …oder in Maven
Festlegung auf „sichere“ Frameworks
z.B. OWASP Dependency Check
https://www.owasp.org/index.php/OWASP_Dependency_Check

49. ProjektstartKontinuierlich
Reviews durch
Security-
Beauftragten
Durchführung
von
automatischen
Security-Tests
Überprüfung
durch statische
Analysen

50. Statische Softwareanalyse!
grep graudit
FindSecurityBugs Taint-Analyse

51. Beispiel: grep

52. Beispiel: grep

53. Beispiel: GRAUDIT
GREP on Steroids
Quelle: https://github.com/wireghoul/graudit

54. Beispiel: GRAUDIT

55. Beispiel: FindSecurityBugs
Ein Plugin für FindBugs
Quelle: http://find-sec-bugs.github.io/

56. Beispiel: FindSecurityBugs

57. Beispiel: FindSecurityBugs

58. Beispiel: FindSecurityBugs

59. Beispiel: TAINT Analyse
Quelle: https://github.com/wireghoul/graudit

60. Taint-Analyse
// Get the login credentials
String username = request.getParameter("user");
String password = request.getParameter("pass");
// SQL query vulnerable to SQL injection
String query = "select info from Users where user = '"+ username
+"' and password='" + password +"'";
// Execute the SQL statement
rs = stmt.executeQuery(query);
Source
Sink
Taint-Analyse

61. Taint-Analyse
// Get the login credentials
String username = request.getParameter("user");
String password = request.getParameter("pass");
username = remove_bad_chars(username);
password = remove_bad_chars(password);
// SQL query vulnerable to SQL injection
String query = "select info from Users where user = '"+ username
+"' and password='" + password +"'";
// Execute the SQL statement
rs = stmt.executeQuery(query);
Taint-Analyse
„Sanitization“

62. Taint-Analyse: GRAUDIT

63. Automatische Schwachstellenscans

64. Inhaltliche Schwachstellen
• Tests müssen Anwendungsspezifisch entwickelt werden
• Unit-Tests
• Testautomatisierung
– UI-Automation Frameworks für Rich-Client-Anwendungen
– Selenium für Webbasierte Anwendungen
• Manuelle Tests
Idealerweise im Rahmen der Qualitätssicherung
64

65. Sicherheitsszenarien in BDD
Scenario: Users with incorrect passwords should not be able to login
Given I am on the login page
And I enter incorrent credentials
Then I am redirected to the startpage
Scenario: Users with correct passwords should be able to login
Given I am on the login page
And I enter correct credentials
Then I am logged in
• Inhaltlicher Test der Anwendungslogik über Testfälle /
Testautomatisierung:
Bsp.: Login

66. Technische Schwachstellen
• Lassen sich nur schwer mit „normalen“ Tests abbilden
• Vor allem für Webanwendungen interessant
• Schwachstellenscanner
– Mit Vorsicht verwenden, kann Betrieb der Anwendung stören
• Intercepting Proxies (BurpSuite, OWASP ZAP)
– HTTP(S)-Datenverkehr wird aufgezeichnet und kann gezielt oder
automatisch auf Schwachstellen untersucht werden
• Komplexe Protokolle: Untersuchung mit Wireshark, ggf. Custom-Tools
66

67. OWASP ZAP
Quelle: https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

68. OWASP ZAP (Scanner)
POST /wp-login.php HTTP/1.1
User-Agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:48.0)
Gecko/20100101 Firefox/48.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
cookie: wordpress_test_cookie=WP+Cookie+check
Connection: close
Upgrade-Insecure-Requests: 1
Content-Type: application/x-www-form-urlencoded
Content-Length: 103
log=admin&pwd=admin&wp-submit=Log+In&redirect_to=wp-admin&testcookie=1

69. Umsetzung mit ZAP-API
And the SQL-Injection policy is enabled
And the attack strength is set to High
And the alert threshold is set to Low
ZAP-API (rest)

70. BDD+ +
Testen von Sicherheitsszenarien
Cucumber
Python behave
Codeception
Kontinuierliche Durchführung der Tests z.B. im
Rahmen der CI-Umgebung

71. KontinuierlichRegelmäßig
Durchführung
von Pentests Review der
Sicherheits-
aspekte

72. „Improving the Security of Your Site by
Breaking Into it”
(Dan Farmer & Wietse Venema, 1993)
Penetrationstests

73. Ablauf eines (WebApp-)Pentests
Information-
sammlung

74. Informationssammlung
Serverversion?
Versteckte Pfade/Verzeichnisse?
Interessante Code-Kommentare?
Request/Response-Aufbau?
Anwendungsfunktion?
Weitere Einstiegspunkte (API, …)?
Ziel: Grobes Verständnis - was tut die Anwendung, wie und womit?
Programmiersprache?

75. Und natürlich… Durchklicken!

76. Ablauf eines (WebApp-)Pentests
Information-
sammlung
Test der
Konfiguration
Test der
Authentifizierung
Test der
Autorisierung
Test des
Session-
Managements

77. Ablauf eines (WebApp-)Pentests
Information-
sammlung
Test der
Konfiguration
Test der
Authentifizierung
Test der
Autorisierung
Test des
Session-
Managements
Test der Input-
validierung

78. Test der Input-Validierung
Cross-Site-Scripting?
SQL-Injection?LDAP-Injection?
XML-Injection?
Code-Injection?
Command-Injection?
File-Inclusion?

79. Ablauf eines (WebApp-)Pentests
Information-
sammlung
Test der
Konfiguration
Test der
Authentifizierung
Test der
Autorisierung
Test des
Session-
Managements
Test der Input-
validierung
Test der
Kryptographie
Test der
Geschäftslogik

80. täglich
Product
Backlog
Product
Backlog
Sprint
Backlog
Product
Backlog
Product
Backlog
Product
Backlog
Product
Backlog
Product
Backlog
Product
Backlog
Product
1 Woche – 1 Monat
Definition von
Sicherheits-
aspekten
Statische
Analyse
Automatische
Sicherheitstests
Pentest
Wie sieht jetzt ein ideales SAD aus?
Schwachstellen-
scans

81. Carsten Cordes
carsten.cordes@hec.de
@badagent86
Falls noch etwas unklar geblieben ist…
Jetzt ist die Chance für Fragen!