In today’s software-driven world, the integrity of software assets isn’t just a regulatory and compliance requirement, it’s critical for maintaining trust and avoiding irreparable damage to your brand and reputation. We found that Compliance, Software Chain of custody and in-App Security as well as API Security are seen as an overburdened bureaucracy. But they have to be part of your software value stream. So the question is, how they can be so lean, automated and optimized that they can contribute actual value inside your DevSecOps Approach?

Target Audience: Architects, Developers
Prerequisites: Project development experience
Level: Advanced

Extended Abstract
In today’s software-driven world, the integrity of software assets isn’t just a regulatory and compliance requirement, it’s critical for maintaining trust and avoiding irreparable damage to your brand and reputation.
The same also applies to Quality, In-App Security, and API Security in a more and more digitized world.
In a lot of case studies, we found that Compliance, Software Chain of custody and in-App Security as well as API Security are seen as an overburdened bureaucracy. But in all cases, they have to be part of your software value stream.
So the question is, how they can be so lean, automated, and optimized that they can contribute actual value inside your DevSecOps Approach? In the lecture we provide some key insight in how to solve that dilemma and integrate them into your day-to-day work.

How do you do DevSecOps in practice? What are relevant tools and practices? Based on his work as a consultant and as a member of the advisory board that publishes the Thoughtworks Technology Radar Erik will give an overview of tools and practices that have proven themselves in real-world use. And because security is now relevant at each step of the process, the scope of the talk is broad. It includes architecture, the software supply chain, fitness functions and how to implement them in a build pipeline, as well as runtime monitoring.

Target Audience: Architects, Developers, Ops
Prerequisites: Knowledge of continuous delivery and DevOps
Level: Advanced

Extended Abstract

Closer collaboration between developers and operations people brought businesses many benefits. It is also fair to say, though, that it created new headaches. Some practices, especially continuous deployments, forced us to rethink the traditional security sandwich, with conceptual work up-front and a pen test at the end. It was easy to sneak a “Sec” into DevOps, it was reasonably obvious to call for security to be “shifted-left”, but in practice this raised even more questions.

Based on his experience working as a consultant Erik will address these quesions. He will discuss practices like container security scanning, binary attestation, and chaos engineering, alongside examples of concrete tooling supporting these practices. In addition Erik will show how the concept of fitness functions, which have become popular in evolutionary approaches architecture, can be applied in the security domain.

Im Web lauert eine Vielzahl von Sicherheitsgefahren. Deshalb sollten ein paar grundlegende Vorkehrungen getroffen werden: Angefangen bei der richtigen TLS-Konfiguration, über Schutzmaßnahmen wie dem Einrichten einer Content-Security-Policy und dem Überprüfen nachgeladener Ressourcen mittels Subresource Integrity, bis hin zur Absicherung von Cookies sowie dem Schicken oder Vermeiden bestimmter HTTP-Header. Welche grundlegenden Maßnahmen es zu beachten gilt und wie man diese umsetzt, erfahren Sie in diesem Vortrag.

Zielpublikum: Architekt:innen, Entwickler:innen
Voraussetzungen: Basiskenntnisse Web-Entwicklung
Schwierigkeitsgrad: Anfänger

Um in verteilten Anwendungslandschaften den Überblick zu behalten, gibt es schon seit einiger Zeit unterschiedliche Ansätze, um Daten wie Metriken, Traces und Logs zentralisiert zu analysieren. Die Uneinheitlichkeit machte es bislang aufwendig, wirklich alle Komponenten einfach zu berücksichtigen. Im Jahr 2019 wurde unter dem Dach der Cloud Native Computing Foundation (CNCF) OpenTelemetry als herstellerneutrales, quelloffenes Ökosystem mit dem Ziel geschaffen, die Erfassung und Übertragung von Telemetriedaten zu standardisieren.

Zielpublikum: Architects, Developers, Process Owners, DevOps, Decision Makers
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
In dieser Session werden die Spezifikation von OpenTelemetry und deren Bestandteile kurz vorgestellt. Es wird gezeigt, wie eine Integration bei Java-Anwendungen und die Verknüpfung mit gängigen Bibliotheken (Drop-In Instrumentation) erfolgt, so dass sich am Ende ein Business-Prozess bzw. die Anfrage eines Nutzers systemübergreifend verfolgen lässt. Die Beispiele lassen sich auf die z. Zt. zehn weiteren unterstützten Programmiersprachen übertragen. Zuletzt wird auf die Interaktion mit Cloud-Infrastruktur eingegangen, da OpenTelemetry sich insbesondere auf cloud-native Anwendungen fokussiert.

In diesem Vortrag berichtet die SüdLeasing - eine 100%ige Tochter einer Landesbank - von ihrem Weg von der “Legacy-IT” zur modernen cloud-basierten Umgebung. Aufgrund der Sensitivität der Daten lag von der ersten Sekunde ein besonderer Fokus auf dem Thema Cloud Security.
Business Continuity und Disaster Recovery wurden voll automatisiert mit Hilfe von Terraform, Access Control Lists und Microsoft Azure aufgebaut.

Zielpublikum: Architekt:innen, Entwickler:innen, Manager
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Extended Abstract
Die Digitalisierung traditioneller Unternehmen und damit meist zwingend verbundene Modernisierung der IT macht auch vor dem Sektor der Finanzdienstleister nicht Halt.
In diesem Vortrag berichtet die SüdLeasing - eine 100%ige Tochter einer Landesbank - von ihrem Weg von der “Legacy-IT” zur modernen cloud-basierten Umgebung. Aufgrund der Sensitivität der Daten lag von der ersten Sekunde ein besonderer Fokus auf dem Thema Cloud Security.
Hier berichten Tamira Horn und Thorsten Jakoby von der Reise eines BaFin regulierten Finanzdienstleisters in die Cloud. Statt "das sichern wir durch eine Firewall und Netzwerke", wurden Multi-Tenant-Zero-Trust-Architekturen aufgebaut.
Business Continuity und Disaster Recovery wurden voll automatisiert mit Hilfe von Terraform, Access Control Lists und Microsoft Azure aufgebaut.
Wir zeigen mit Beispielen und Demos, wie wir es technisch umgesetzt haben, nicht das Rechenzentrum in die Cloud zu migrieren, sondern eine sichere und flexible Plattform zu designen, um uns auf den Weg in die Cloud vorzubereiten.

"Ursache war menschliches Versagen" hört man oft, wenn etwas schiefgeht. Aber was bedeutet das? Hat der Bediener geschlafen? War er vielleicht überfordert mit dem System? Muss und kann man den Menschen besser ausbilden oder auswählen? Ist "die Organisation" schuld? Oder war das System unglücklich designt? Muss man Systeme anders gestalten? Gibt es so etwas wie ein 100 % sicheres System? Was sind überhaupt Systeme? Nur technisches Gerät? Oder auch komplexe Gebilde wie Software oder die Gesellschaft? Fragen über Fragen. Im Vortrag Ideen für Antworten.

Zielpublikum: Jeder, der sich für technische Systeme (auch) jenseits der Software interessiert
Voraussetzungen: Keine
Schwierigkeitsgrad: Anfänger

Machine Learning appears to have made impressive progress on many tasks from image classification to autonomous vehicle control and more. ML has become so popular that its application, though often poorly understood and partially motivated by hype, is exploding. This is not necessarily a good thing. Systematic risk is invoked by adopting ML in a haphazard fashion. Understanding and categorizing security engineering risks introduced by ML at design level is critical. This talk focuses on results of an architectural risk analysis of ML systems.

Target Audience: Architects, Technical Leads, and Developers and Security Engineers of ML Systems
Prerequisites: Risk Managers, Software Security Professionals, ML Practitioners, everyone who is confronted by ML
Level: Advanced

Extended Abstract
Machine Learning appears to have made impressive progress on many tasks including image classification, machine translation, autonomous vehicle control, playing complex games including chess, Go, and Atari video games, and more. This has led to much breathless popular press coverage of Artificial Intelligence, and has elevated deep learning to an almost magical status in the eyes of the public. ML, especially of the deep learning sort, is not magic, however. ML has become so popular that its application, though often poorly understood and partially motivated by hype, is exploding. In my view, this is not necessarily a good thing. I am concerned with the systematic risk invoked by adopting ML in a haphazard fashion. Our research at the Berryville Institute of Machine Learning (BIIML) is focused on understanding and categorizing security engineering risks introduced by ML at the design level. Though the idea of addressing security risk in ML is not a new one, most previous work has focused on either particular attacks against running ML systems (a kind of dynamic analysis) or on operational security issues surrounding ML. This talk focuses on the results of an architectural risk analysis (sometimes called a threat model) of ML systems in general. A list of the top five (of 78 known) ML security risks will be presented.