Hack me if you can - Sicherheit in Web-Anwendungen

Web-Anwendungen sind unter ständigem Beschuss. Sie sind Einfallstore für Angriffe aus dem offenen Netz. Was kann getan werden, um frühzeitig und effektiv Sicherheit in die Anwendung zu bringen? Wie kann eine dynamische Abwehr proaktiv helfen?
Hierzu wird Euch Bernhard Hirschmann (IT Consultant mit Schwerpunkt IT Security) einen Einblick geben und steht Euch für Fragen gern zu Verfügung!

Das Meetup fand statt am 15. November 2018 bei EXXETA in Stuttgart.

Transcript

1. eXXchange IT Stuttgart Hack me if you can Sicherheit in Web-Anwendungen 15. November 2018 powered by EXXETA
2. Agenda Warum das alles? Wie man hackt Wie man sich schützt Wie man sich wehrt
3. Viele Web-Anwendungen haben massive Schwachstellen Auswirkung Vorbeugung Ursache • Wissen aufbauen • Angriffe kennen • Präventionen kennen • Abwehrmaßnahmen nutzen • Sicherheitslücken • Diebstahl von Daten • Kompromittierung • Verlust des Vertrauens • Termindruck • Stress • Unwissenheit
4. Onlineshop der CSU Oktober 2018 - Landtagswahl in Bayern • Magento Onlineshop – veraltet und ungepatcht • Einbruch Brute Force oder Sicherheitslücke • XSS eingeschleust • Stiehlt beim Bezahlvorgang persönliche Daten • Willem de Groot: • über 40.000 Magento Shops weltweit betroffen
5. freie-waehler-bayern.de 14. Oktober 2018 - Landtagswahl in Bayern • Freie Wähler gehören zu den Gewinnern • Ansturm auf deren Webseite • CMS kollabiert - DB-Connections gehen aus • Fehlerseite bringt Debug-Informationen • User + Passwort der DB-Verbindung • Credentials des DB Account • auch für das CMS Typo3 gültig
7. • 3 gravierende Fehler: • Veraltete, ungepatchte Software • PHP, Typo3, MySQL • Debugmodus aktiv bei Typo3 • Verwenden der gleichen Credentials für CMS und DB • Möglichkeiten für Angreifer: • Auslesen aller Inhalte, Benutzerdaten und Passwort-Hashes möglich • Ebenso Modifikation dieser Daten • Einschleusen von Schadcode, Trackern, Trojanern, ... • Website Defacements freie-waehler-bayern.de 14. Oktober 2018 - Landtagswahl in Bayern
8. Gestohlene Datensätze Quelle: https://www.heise.de/security/meldung/Hacker-kopieren-Nutzer-Daten-von-Mitfahrgelegenheit-de-und-Mitfahrzentrale-de-3507285.html mitfahrzentrale.de @ Hack des Cloud-Dienstes Comuto Daten AES verschlüsselt Key mit abgelegt In DB 638.000 IBAN-Nummern 101.000 E-Mail 15.000 Mobilnr.
9. Hoch- sicherheitsnetz der Bundesregierung Russische Hackergruppe Snake Angriff über Fachhochschule des Bundes Spionagesoftware Uroburos Kommunikation über Outlook @ Quelle: http://www.heise.de Gestohlene Datensätze Bundeshack - Auswärtiges Amt
10. Ziele 1. Hacken ist oft erschreckend leicht 2. Viel Schutzmaßnahmen sind leicht 3. Welche Maßnahmen gibt es? 4. Was kann man für Abwehr tun? Warum sind wir heute hier?
11. Hacken ist illegal! Gefängnisstrafe droht! Hackerparagraph (§ 202a Abs. 1 StGB) : "Wer unbefugt sich oder einem anderen Zugang zu Daten, die nicht für ihn bestimmt und die gegen unberechtigten Zugang besonders gesichert sind, unter Überwindung der Zugangssicherung verschafft, wird mit Freiheitsstrafe bis zu drei Jahren oder mit Geldstrafe bestraft“ à Nur im Auftrag hacken, mit schriftlicher Genehmigung „Out of Jail Card“
12. 1. Phase Footprinting 2. Phase Scanning 3. Phase Enumeration • Passives Vorgehen • Analysieren • Informationen sammeln • Aktives Vorgehen • Analyse-Proxy • Spidering • Vulnerability-Scan • Automatisierte Test: • Brute Forcing • Credentials • Fuzzing • geheime Pfade • versteckte URLs • Parameter 4. Phase Pentesting • Manuelles Vertiefen • gefundene Lücken bearbeiten • weitere Schwachstellen suchen • Nächste Schicht knacken Wie hackt man? Die 4 Phasen eines strategischen Angriffs
13. Phase 1: Footprinting Vorgehensweise Ergebnis Strategie Anwendung nach Schwachstellen prüfen • Detaillierte Informationen • des System • der verwendeten Komponenten • Versionsnummern und Patchlevel der Komponenten • Infos zu beteiligten Entitäten • Anwendung durchklicken • Googeln nach Infos • Details über Organisation • Fehler provozieren • Details aus Fehlermeldungen • Analyse Quellcode • Passives Vorgehen • Analysieren • Informationen sammeln
14. Phase 2: Scanning Vorgehensweise Ergebnis Strategie Automatische Analyse • Liste von Schwachstellen • in Anwendung • in eingesetzten 3rd Party Libs • Frameworks • Server-Komponenten • ... • Proxy untersucht Traffic und zeigt bekannte Schwachstellen • Spidering • vollständige Sitemap • Vulnerability-Scan • testet automatisiert nach bekannten Schwachstellen • Aktives Vorgehen • Automatisierte Tools einsetzen
15. Phase 3: Enumeration Vorgehensweise Ergebnis Strategie Anwendung in die Mangel nehmen • Zugang zur Anwendung • Transparenz der Funktionen und Bereiche • Automatisierte Test • Brute Forcing • Credentials • Fuzzing • geheime Pfade • versteckte URLs • Parameter • Knacken von Zugangsdaten • Durchprobieren aller Möglichkeiten
16. Phase 4: Pentesting Vorgehensweise Ergebnis Strategie Anwendung nach Schwachstellen prüfen • Kontrolle über die Anwendung • Schwachstellen • offenlegen • beweisen • dokumentieren • Gefundene Schwachstellen prüfen • Zugang zur Anwendung verschaffen • Privilegien maximieren • So viel Funktionen und Daten wie möglich erbeuten • Weitere Schwachstellen suchen • Manuelles Vertiefen • „Die letzte Meile zu Fuß“
17. 1. Phase Footprinting 2. Phase Scanning 3. Phase Enumeration • Passives Vorgehen • Analysieren • Informationen sammeln • Aktives Vorgehen • Analyse-Proxy • Spidering • Vulnerability-Scan • Automatisierte Test: • Brute Forcing • Credentials • Fuzzing • geheime Pfade • versteckte URLs • Parameter 4. Phase Pentesting • Manuelles Vertiefen • gefundene Lücken bearbeiten • weitere Schwachstellen suchen • Nächste Schicht knacken Wie hackt man? Die 4 Phasen eines strategischen Angriffs
18. Bekannte Schwachstellen sind katalogisiert • Common Vulnerabilities and Exposures, cve.mitre.org • “A list of entries – each containing an identification number, a description, and at least one public reference – for publicly known cybersecurity vulnerabilities.“ • DB mit bekannten Schwachstellen • detaillierte Beschreibung • oft mit Proof-of-Concept in GitHub • Vulnerability-Scanner benennen Findings meist mit CVE-Nummer Beispiel: • CVE-2016-10524 • Schwachstelle in „i18n-node-angular“
20. Schwachstellen eingeteilt in Kategorien • cwe.mitre.org • Kategorien von Schwachstellen • Dadurch besseres Verständnis • Schwachstellen sind leichter einzuordnen Common Weakness Enumeration A Community-Developed List of Software Weakness Types
22. Angriffsmuster CAPEC (Common Attack Pattern Enumeration and Classification) Katalogisiert nach: • Angriffs-Mechanismus, z.B. • Missbrauch existierender Funktionalitäten • Manipulation von Daten • Injizieren von unerwarteten Eingaben • Angriffs-Domäne, z.B. • Brute Forcing • Authentication Abuse • Privilege Abuse • Flooding • File Manipulation • Man-in-the-Middle
25. Fertige Angriffsvektoren verwenden: Exploits Exploit – (englisch to exploit ‚ausnutzen‘) • Programm zum Ausnutzen einer Sicherheits-Schwachstelle • Exploits teilweise frei verfügbar für ältere Schwachstellen • mit Premium-Account auch für neuere Schwachstellen • Zero-Day-Exploits bezeichnen Exploits für Schwachstellen, für die es noch keine Patches gibt • Datenbank für Exploits: exploit-db.com
26. Angriffsvektoren anwenden Exploit-Frameworks Frameworks um Exploits auszuführen • Metasploit von Rapid7 • Canvas von Immunity • Core Impact von Core Security
27. Angriffsvektoren anwenden Exploit-Framework Metasploit Vorgehensweise beim Angriff mit Metasploit 1. Exploit auswählen und konfigurieren 2. Optionale Verwundbarkeitsprüfung 3. Payload wählen und konfigurieren: • Client-Programm Meterpreter • VNC-Server • Shell 4. Ausführung des Exploits 5. Weiteres Vordringen auf dem Zielsystem • Nach einem erfolgreichen Angriff lassen sich mittels Payload weitere Aktionen auf dem Zielrechner ausführen.
29. Metasploit
30. Metasploit
31. Prozess-Übersicht des Angriffs Vulnerability Scan • Scan der Anwendung mit Vulnerability- Scanner • Scannt öffentlich bekannte Schwachstellen Schwachstellen identifiziert • Schwachstellen im Coding • Ungepatchte Sicherheitslücken • CVE-Einträge der Schwachstellen Exploit-DB • Findings analysieren und bewerten • Exploit-DB nach CVE-Eintrag durchsuchen Metasploit • verfügbare Exploits wählen • Payload konfigurieren • Zielsystem • Callback-Adresse • Ports • etc. Angriff • Schwachstelle ausnutzen • Anwendung mit Exploit angreifen • Payload ausführen • Shell-Zugriff • Daten stehlen • Trojaner platzieren
32. Nachteil der heutigen Situation • Hacken wird immer leichter – viel automatisiert und verfügbar Vorteil der heutigen Situation • Wenn Angriffe allgemein bekannt: • man kann sich... • Informieren • Präventionsmaßnahmen treffen • Härten durch automatisierte Tests • Monitoring und Reaktion Wie kann man sich vor einem Angriff schützen?
33. Wie kann man sich vor einem Angriff schützen? Security Strategie entwickeln Maßnahmen • Secure Coding der Anwendung • Robuste Authentisierung • Durchdachte Autorisierung • Verschlüsselung der Daten • Sicherer Transport
34. Quelle: https://www.rachaelandtom.info/photos/picture/1351-kurios119
35. Daten verschlüsseln Schlüssel sicher aufbewahren und verwalten Benutzerzugriffe verwalten Stark Verschlüsseln bei • Übertagung • Austausch • Speicherung Damit ein Angriff sinnlos oder zu aufwändig wird. Prozess für Schlüsselverwaltung festlegen: • Limitieren • Regelmäßiges Aus- wechseln • Vergabe Schlüssel müssen geheim sein und bleiben. Festlegen wer Zugriff auf Daten hat • Verifikations-Prozess • Zugriffs-Level • Starke Authentifizierung • Kommunikation mit Benutzergruppen Secure Coding Vermeiden gängiger Sicherheitslücken in der Anwendung. Alle anderen Maßnahmen können darüber ausgehebelt werden. Sicherheits-Maßnahmen
37. Security-Patterns Empfohlene und erprobte Vorgehensweisen Unsecurity-Patterns SP falsch angewendet oder missinterpretiert Risiken werden dadurch größer, anstatt kleiner Gefahr für Sicherheit Standardisierung der sicheren Entwicklung Secure Development Herauskristallisiert: Security-Patterns Falsch angewendet: Unsecurity-Patterns
38. Komplexe Schwachstellen – große Angriffsfläche Benutzerverwaltung Session Management Je nach angebundenen Systemen unterschiedlich Leicht zu schützende Schwachstellen XSS Input-Filterung Output-Escaping SQL-Injection PreparedStatements Herauskristallisiert: Security-Patterns • Man fühlt sich sicher • Schein kann trügen Sicherheitsmaßnahmen zur Prävention von Angriffen Security-Patterns Falsch angewendet: Unsecurity-Patterns
39. Security-Patterns Pattern Umsetzung Problematik Passwörter speichern Unsicher • MD5, SHA-1, SHA-2 • schnell und teilweise unsicher Sicher • PBKDF2 • bcrypt • scrypt • Argon2 • PW-Hash speichern • nicht zurückrechenbar • Wahl für Hash-Algorithmus • einfach • sicher • langsam • hoher Widerstand gegen Brute-Force-Angriff • PWs müssen verifiziert werden • oft in Anwendung, anstatt AD • PW nicht im Klartext Antipattern: • PW verschlüsseln • unsicher • unnötig
40. Security-Patterns Iterationen anpassen Migration bei Änderungen Eigenschaften Passwörter speichern – der Hash-Algorithmus PBKDF2 Veränderter Hash • Benutzer zeitnah umstellen bei Login • Nicht umgestellte Benutzer nach Übergangszeit sperren • Endloses Speichern unsicherer Hashes ist Risiko • Rainbow-Table • Deshalb unsichere Hashes löschen Achtung Falle: • Interationen bei schnellerer Hardware erhöhen • Widerstand erhalten • Hash ändert sich • Verfügbar in plain Java • Einfach einsetzbar • 1000 ~ Iterationen • 512 ~ Hash-Länge byte[] hash(char[] password, byte[] salt) throws Exception { SecretKeyFactory skf = SecretKeyFactory.getInstance(“PBKDF2WithHmacSHA1“); PBEKeySpec spec = new PBEKeySpec(password, salt, 10000, 512); return skf.generateSecret(spec).getEncoded(); }
41. Security-Patterns Spring-Security Komplexität Eigenschaften Passwörter speichern – der Hash-Algorithmus bcrypt Konstruktor-Argument • 10 ~ Komplexität der Berechnung • 10 ist Default • Werte von 4 bis 31 möglich • Komplexität steigt dabei exponentiell an • Unterstützung out-of-the-box • Bean mit @Configuration annotiere Konfig-Klasse • Ebenfalls guter Widerstand • Implementierung in vielen Sprachen • Externe Library @Bean public PasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(10); }
42. Security-Patterns Pattern Umsetzung Problematik Sichere Datenübertragung HSTS bei Spring Security automatisch aktiv Ansonsten: HSTS-Servlet-Filter: HTTP • unsicher • Daten ungesichtert auf Transport • können mitgelesen werden Mischform HTTP/HTTPS • unsicher • Integrität des Login- Formulars • Ausspähen der Session-ID HTTPS-Everywhere • Erzwingen mit HSTS • HTTP Strict Transport Security Header • Http-Response-Header • Wirksamer Schutz gegen Man In The Middle-Angriffe • Kompatible Browser verwenden immer https • Anwender kann Zertifikatsfehler im Browser nicht mehr ignorieren public void doFilter( ServletRequest req, ServletResponse res, FilterChain filterChain) throws Exception { response.addHeader(“Strict-Transport-Security“, “max-age=31536000; includeSubDomains“); filterChain.doFilter(req, response); }
43. Security-Patterns Angriffe Prävention Problematik Session-ID nach Login ändern Spring Security oder: request.changeSessionId() • Session-ID wird nach 1. Request vergeben • Vor Login wertlos für Angreifer • Danach wertvoll • Mit Benutzer verknüpft • Wer ID kennt, kann mit den Privilegien des Nutzers arbeiten • Daten ausspähen • Transaktionen tätigen • Session Fixation • Angreifer schiebt Opfer bekannte Session-ID unter • Session Hijacking • Stehlen der Session-ID • M-i-t-M bei HTTP • XSS @WebServlet public class LoginServlet extends HttpServlet { protected void doPost(HttpServletRequest req, HttpServletResponse res) throws ServletException { request.changeSessionId(); } }
44. Folge den Daten Benutzereingaben im Browser Interagieren mit Entitäten Trust Boundaries Übergang von nicht- vertrauenswürdig nach vertrauenswürdig Erfassen aller externer Entitäten, damit sie im Threat Model berücksichtigt werden können • IAM • Service-API • WebServer • Messaging Queue • DB Filterung: Benutzereingaben à vertrauenswürdige Daten Transformation: Internet à Intranet Angreifer suchen vergessene Entitäten, die ungeschützt und angreifbar sind Ergebnis: vollständiges Threat Model als Basis für Implementierung Viele Bedrohungen sind damit bekannt • XSS • Injection • Eingabevalidierung • spezif. Bedrohungen Threat Modelling - Bedrohungsanalyse Threat Modelling Durch Bedrohungsanalyse zu Sicherheitsmaßnahmen
47. DevOps Zyklus Dev Ops Sec agil dynamisch Wasserfall 100 10 1
48. SecDevOps Zyklus SecDev Ops Continuous Security Testing
49. Recherche & Analyse Richtlinien aufstellen Sensibilisierung & Schulung Integration Build-Prozess Evaluierung
50. Beschreibung der Maßnahme: Verhindere das Injizieren von Schadcode Secure Coding Integration im Projekt Risiko: A1:2017 Verwundbarkeit: CWE-20 Angriff: CAPEC-66 Wodurch testbar? FindSecBugs
51. Beschreibung Risiko Verwundbarkeit/S chwachstelle Angriffe Testbar durch Verhindere das Injizieren von Schadcode A1 - OWASP Top-10 2017 WASC-20 CWE-20 CWE-89 WASC-19 CAPEC-66 FindSecBugs
52. Beschreibung Risiko Verwundbarkeit/S chwachstelle Angriffe Testbar durch Verhindere das Injizieren von Schadcode A1 - OWASP Top-10 2017 WASC-20 CWE-20 CWE-89 WASC-19 CAPEC-66 FindSecBugs Verwende keine hartcodierten Passwörter A2 - OWASP Top-10 2017 CWE-798 CWE-259 CWE-321 CAPEC-190 FindSecBugs Verwende sicheres Session-Management A2 - OWASP Top-10 2017 CWE-613 CWE-614 WASC-47 CAPEC-21 web.xml Check Verwende keine vorhersagbaren Zufallszahlen- Generatoren A2 - OWASP Top-10 2017 CWE-6 CWE-330 CAPEC-21 CAPEC-112 WASC-11 FindSecBugs Verhindere den unerlaubten Zugriff auf Dateien durch Pfad-Manipulationen A5 - OWASP Top-10 2017 CWE-22 WASC-33 CAPEC-126 FindSecBugs Vermeide die Anzeige von technischen Fehlermeldungen A6 - OWASP Top-10 2017 CWE-209 WACS-14 CAPEC-54 web.xml Check Verwende keine schwachen Krypto-Algorithmen A3 - OWASP Top-10 2017 CWE-326 CWE-327 CWE-261 CAPEC-55 CAPEC-112 FindSecBugs Verwende sichere Deserialisierung A8 - OWASP Top-10 2017 CWE-502 CAPEC-586 FindSecBugs Verwende keine 3rd-Party Libraries mit bekannten Verwundbarkeiten A9 - OWASP Top-10 2017 Diverse: Injection, Broken Access Control, XSS, etc. Entsprechend den Verwundbarkeiten Dependency Check Retire.js Verwende Monitoring für sicherheitsrelevante Ereignisse A10 - OWASP Top-10 2017 CWE-778 AppSensor
53. Secure-Coding Richtlinien umsetzen Auswirkung Vorbeugung Ursache Beispiel 1: Verhindere das Injizieren von Schadcode in SQL-Befehle • Sämtliche Benutzereingaben prüfen und filtern • Verwendung von Prepared Statements • Verwendung von Hibernate Criteria • Ausführung unberechtigter Abfragen • Manipulation von Daten • Ungeprüfte Übernahme von Benutzereingaben in SQL-Abfragen
54. Secure-Coding Richtlinien umsetzen Auswirkung Vorbeugung Ursache Beispiel 2: Verwende keine 3rd-Party Libraries mit bekannten Verwundbarkeiten • Regelmäßig alle Jars auf Schwachstellen prüfen • JavaScript-Bibliotheken auf Schwachstellen prüfen • Updates und Fixes einspielen Anwendung je nach Schwachstelle angreifbar Schwachstellen in 3rd-Party Libraries beliebte Angriffspunkte
55. https://www.owasp.org/index.php/OWASP_Proactive_Controls OWASP Top 10 Proactive Controls 2018 10 Maßnahmen für Basis-Sicherheit 1. Define Security Requirements 2. Leverage Security Frameworks and Libraries 3. Secure Database Access 4. Encode and Escape Data 5. Validate All Inputs 6. Implement Digital Identity 7. Enforce Access Controls 8. Protect Data Everywhere 9. Implement Security Logging and Monitoring 10. Handle All Errors and Exceptions
57. SecDevOps Tools (1) Statische Codeanalyse SpotBugs-Plugin für Java Integration: Command Line Interface, Ant, Maven Eclipse, IntelliJ, Android Studio Jenkins, Sonar Qube http://find-sec-bugs.github.io FindSecBugs
59. SecDevOps Tools (2) • Findet Schwachstellen in eingesetzten 3rd-Party-Libs • Report mit Findings • Referenzen zu weiteren Informationen OWASP Dependency Check
60. SecDevOps Tools (2) Integration: Command Line Interface Ant, Maven, Gradle Jenkins, SonarQube https://www.owasp.org/index.php/OWASP_Dependency_Check OWASP Dependency Check
62. SecDevOps Tools (3) Findet bekannte, verwundbare JavaScript Libs Integration: Command Line Interface, Plugins für: Grunt, Chrome, Firefox, Burp-Suite, OWASP ZAP https://retirejs.github.io/retire.js/ Retire.js
63. Retire.js – hier als Firefox-Plugin Quelle: https://addons.mozilla.org/de/firefox/addon/retire-js/
64. Verteidigungsmaßnahmen
65. Warnungen und Fehler erzeugen keine oder unklare Protokollmeldungen Anwendung wird nicht auf verdächtige Aktivitäten hin überwacht Ereignisse werden nicht protokolliert: Logins, fehlgeschlagene Authentifizierung Kritische Aktionen Auswirkungen von unzureichendem Logging und Monitoring Protokolle werden nur lokal gespeichert und nicht ausgewertet Angemessene Alarmierungsschwellen und Eskalationsprozesse sind weder vorhanden noch wirksam Penetrationstests und Scans mit DAST-Tools (z.B. OWASP ZAP) lösen keine Alerts aus Anwendung kann keine aktive Angriffe in Echtzeit erkennen, eskalieren oder alarmieren
67. • Realität: schlechte oder keine Security-Logs • Angriffe werden nicht erkannt Logging und Monitoring Kompromittierte User-Accounts finden Auf Ereignisse reagieren Missbrauch von Berechtigungen erkennen Angriffe erkennen
68. Zentrales Logging Log-Analyse Autorisierter Zugriff Keine sensiblen Infos Vertrauens- würdige Daten Kontext Angemessene Vorhaltezeit Universelles Format Integrität Überwachung Alarmierung Notfallplan Anforderungen an Logging und Monitoring
69. Unzureichendes Logging und Monitoring Prävention 2: Fehlende Anleitung, was und wie man protokolliert • Security Protection System – auf Anwendungs-Level Logging und Monitoring www.appsensor.org • Zentrales Monitoring • Dynamische Abwehr • Ergänzung zu bestehendem Systemen
70. Unzureichendes Logging und Monitoring Prävention 2: Fehlende Anleitung, was und wie man protokolliert Bsp-Policy: Tool: OWASP AppSensor Logging und Monitoring www.appsensor.org if ( isUserAuthorized( account ) ) { // present/view account } else { //new code for appsensor appSensor.addEvent( logged_in_user, “INSUFFICIENT_AUTHORIZATION” ) } 3 falsche Login-Events in 5 Minuten für 1 User à blockiere den Account An Erkennungspunkten: Events an AppSensor senden Individuell über AppSensor API, durch AOP oder über externe Tools
71. Unzureichendes Logging und Monitoring Prävention 2: Fehlende Anleitung, was und wie man protokolliert Dashboard • Events • Indikatoren • Detections • Responses • Trends AppSensor Logging und Monitoring www.appsensor.org
72. • Sicherheit in Web-Anwendungen sehr wichtig - Hacken ist oft einfach - Security Patterns helfen • Maßnahmen in alle Schichten integrieren - Verschlüsseln, Schlüssel sicher aufbewahren, Zugriffe verwalten - Secure Coding, Security Patterns - Monitoring und Abwehrmaßnahmen • SecDevOps bringt Sicherheit in den Prozess - Tools helfen bei Entwicklung und beim Build - FindSecBugs, Dependency Check, Retire.js - Maßnahmenkatalog für mehr Sicherheit in der Anwendung Zusammenfassung
73. www.EXXETA.com WIR VERBINDEN WELTEN www.EXXETA.com www.EXXETA.com
74. Sprachen Deutsch Englisch Langjährige Erfahrung in den Bereichen Konzeption und Entwicklung von Applikationen, Web-Plattformen und deren Architekturen. Das Thema Security interessiert ihn schon seit Beginn seiner Tätigkeiten in der IT, weshalb er sich auf Sicherheit in Web-Anwendungen spezialisiert hat. Security-Consulting Solution-Architect Business-Consulting • Security Analysen und Consulting • Sichere Software Architekturen • Secure Coding Schulungen Tätigkeiten Beratungskompetenz 1995-2000 Informatik-Studium Seit 2000 Java-Entwickler Seit 2002 Architektur-Erfahrung Seit 2004 Technical Lead Seit 2006 Team Lead Maintenance Seit 2012 Secure Coding Seit 2015 Certified Ethical Hacker Seit 2017 Certified Security Analyst Biographie Bernhard Hirschmann Enterprise Security Consulting Auszüge von Projekten • Creditreform: Security-Analysen, -Consulting und Secure Coding Schulung und -Unterstützung • Mercedes-Me Portal – Remote Control Vehicle Services • Mercedes-Benz Vehicle-Suite: Car-Konfigurator, Händlersuche, Dialogsystem • Daimler Fleet-Management: xFleet Firmenwagen Bestellsystem • Porsche Partner Network • Software Architekt (ISAQB Foundation Level) • Certified Security Analyst (ECSAv9 EC-Council) • Certified Ethical Hacker (CEHv8 EC-Council) Zertifizierungen