Track: Track+
- Mittwoch
06.10. - Donnerstag
07.10.
Wie entwickelt man sichere Software, die gängigen Compliance-Anforderungen entspricht? Threat Modeling ist ein etablierter Ansatz, der sich dies auf die Fahnen geschrieben hat. Leider wird er in der Praxis immer noch zu oft stiefmütterlich behandelt. Wir wollen zeigen, wie Threat Modeling auch agile Entwicklungsteams in ihrer Arbeit unterstützen kann, um aus unverständlichen Security-Anforderungen nachvollziehbare und planbare Eigenschaften zu machen, die die Qualität des Produkts verbessern.
Threat Modeling ist ein etablierter Ansatz, um sichere Software zu entwickeln, die gängigen Compliance-Anforderungen entspricht. Doch wie lässt sich dieser Ansatz in den Projektalltag integrieren und erfolgreich umsetzen? Unser Kollege Dr. Stephan Groß stellt gemeinsam mit weiteren Fachkollegen konkrete Herausforderungen aus unseren Projekten vor und berichtet von den Erfahrungen zu Threat Modeling in agilen Entwicklungsteams. Gemeinsam mit Ihnen diskutieren wir dann über konkrete Aspekte des Themas und schauen aus unterschiedlichen Blickwinkeln auf mögliche Lösungsansätze und Best Practices.
Die Transformation zum Anbieter von digitalen Services stellt Unternehmen vor besondere Herausforderungen.
Neue Denkmuster, Führungsmodelle, Technologien, Architekturen, Kulturmuster, Prozesse, Team-Topologien usw. müssen parallel zur Sicherung des Bestandsgeschäfts etabliert werden.
Während dieser Reise werden häufig Strategien und Taktiken von erfolgreich(er)en Wettbewerbern und Technologie-Marktschreiern kopiert, ohne den Kontext der individuellen Problemstellung sauber einfließen zu lassen.
In diesem Vortrag wird ein Weg gezeigt, wie man ohne „Cargo-Kult“ kollaborativ mit unterschiedlichsten Stakeholdern die Reise in die Zukunft strategisch planen und operationalisieren kann.
Konkret wird auf die Zusammenhänge zwischen Conway’s Law, Alberto Brandolini’s Event-Storming, Team Topologies von Mathew Skelton und Manuel Pais und Wardley Maps von Simon Wardley eingegangen und diskutiert, welche Personen und Rollen es am Spieltisch braucht, um mit diesen Methoden erfolgreich Gläserrücken spielen zu können.
Michael Heiß ist als Berater mit Fokus auf Cloud- und DevOps Transformationen bei Kunden der ARS Computer und Consulting GmbH tätig. Neben seinen technologischen Steckenpferden (Cloud-native Plattformen und Architekturen, API Economy) hat er einen sehr starken Fokus auf die Ausrichtung von Technologieentscheidungen an Veränderungsziele hinsichtlich Organisation, Prozess, Arbeitskultur und Kompetenzen.
Mit dem Aufkommen von Microservice-Architekturen und DevOps Prozessen werden grosse zentrale Security Gateway Installationen zunehmend in Frage gestellt. Die notwendige Koordination zwischen Anwendungsverantwortlichen, Administratoren, Entwicklern und dem Security Team führt zu Effizienzverlusten und Frustration. Besser wäre es, wenn Security-Aufgaben nahe bei den zu schützenden Services mittels sogenannter Microgateways erledigt würden. DevOps-Teams könnten die Verantwortung für die Sicherheit ihrer Services von der ersten Minute an bis in die Produktion übernehmen (Shift Left). Der Vortrag beleuchtet technische und organisatorische Herausforderungen rund um den Einsatz von Microgateways. Zudem wird in einer Demo gezeigt, wie Microgateways konkret genutzt werden können, um existierende Services zu schützen.
Zielpublikum:
DeOps Enginers, DevSecOps Verantwortliche, Kubernetes Admins, Architekten
Vortrag Teilen
Damit eine Microservices-Architektur erfolgreich sein kann, ist es elementar wichtig, die richtigen Grenzen zwischen den Microservices zu ziehen. Aber wo sind die richtigen Grenzen? Ich möchte ein Werkzeug präsentieren, das uns hilft, diese Frage zu beantworten.
Domain Storytelling heißt, dass wir unsere Anwender uns Geschichten über ihre Domäne erzählen lssen. Während wir zuhören, zeichnen wir die Domain Stories vor den Augen der Fachexperten mit einer Bildsprache auf. Dadurch können alle Beteiligten unmittelbar sehen, ob sie richtig verstanden wurde. Schon nach wenigen Domain Stories verstehen wir die Sprache unser Anwender und finden unterschiedliche Bereiche in unser Fachlichkeit. Jeder dieser Bereiche (eine sog. Subdomain) ist ein guter Kandidat dafür, ein Microservice in unser Architektur zu werden.
In diesem Vortrag zeige ich, wie man Subdomänen findet und welche Heuristiken uns dabei helfen.
Vortrag Teilen