Wednesday

Reception area — Registration
Dragefjellet — Welcome from the organizers
Dragefjellet

 Keynote: Embodied vulnerabilities – Why I am hacking my own heart

Marie Moe

Gradually we are all becoming more and more dependent on connected technology. We will be able to live longer with an increased quality of life due to medical devices and sensors integrated into our bodies, and connected to the cloud. However, our dependence on technology grows faster than our ability to secure it, and a security failure of a medical device may cause patient harm and have fatal consequences. Medical errors are often associated with human errors, but patient safety is also threatened by security failures of medical devices. Loss of availability or integrity of patient data may indirectly cause patient harm, due to wrong diagnosis or treatment decisions based on incorrect data.

However, there are no good statistics on the number of deaths caused by medical device security failures. Medical devices are collecting personal data on a big scale without any transparency on how the data is collected and how the information security and privacy of patient information is ensured by the medical device manufacturers. Additionally, patients are in many cases deprived from access to their own data generated by sensors and devices implanted in their body. The medical devices appear as “black boxes” with little information about their data collection capabilities and implementation of security and privacy features. Dr. Marie Moe is a security researcher living with a vulnerable medical implant, a pacemaker that generates every single beat of her heart. She started a hacking project investigating the cyber security of her personal critical infrastructure, and tells her story to create awareness and to inspire others to do more research on the security of connected medical implants.

Downstairs — Coffee break
Restaurant — Lunch
Galgebakken
Tårnplass
Dragefjellet
Muséplass
Teatergaten
Sydneshaugen
Hødden
Kjellersmauet
Downstairs — Coffee break
Galgebakken
Tårnplass
Dragefjellet
Muséplass
Teatergaten
Sydneshaugen
Hødden
Kjellersmauet
Grand Selskapslokaler(map ) — Conference dinner

Thursday

Reception area — Registration
Tårnplass
Dragefjellet
Muséplass
Teatergaten
Sydneshaugen
Hødden
Kjellersmauet
Downstairs — Coffee break
Tårnplass
Dragefjellet
Muséplass
Teatergaten
Sydneshaugen
Hødden
Kjellersmauet
Restaurant — Lunch
Dragefjellet — Introduction to open spaces
Dragefjellet and more — Open spaces 1
Dragefjellet and more — Open spaces 2
Downstairs — Coffee break
Tårnplass
How NSD and immutability enabled microdata.no - a revolutionary platform for research on register data
Ørnulf Risnes

Norway has a large number of registers on individuals that have been established for administrative and statistical purposes. These registers represent a unique and valuable resource for research on welfare and society.

Traditionally, getting approvals to do research on these data has been complicated and time-consuming.

The new platform microdata.no reduces approval time from 9 months to 0 days, and makes these valuable data available for a much wider community of researchers.

Microdata.no was released in 2018 after a 5 year collaboration project between NSD and Statistics Norway (SSB). Researchers analyze data through a privacy-preserving web-IDE inspired by Jupyter notebooks and other widely used statistical tools.

The platform is built with ClojureScript, Clojure, Node, Python, Go and Datomic - and immutability is the cornerstone of the architecture.

In this short talk, we will demonstrate how NSD designed microdata.no around immutable data structures, and how this design decision enabled the development of a novel and globally unique platform for safe research on personal data.

We will discuss how we designed and implemented a new domain specific language (DSL) for analyses of temporal register data, how we execute the DSL with functional reactive programming, and how we use immutable data structures and databases to enforce complete statelessness and simplicity throughout the platform.

Tårnplass
Dragefjellet
Muséplass
Hødden
Downstairs — Coffee break
Tårnplass
Dragefjellet
Muséplass
How to not be the smartest person in the room and still be respected
Lauren Goldstein

As designers, especially in the enterprise software field, it’s common for us to start on new projects with no prior domain knowledge. Working in a highly technical field, it is almost a guarantee that learning a new domain is going to be extremely complicated with a steep learning curve. Not only do we need to start designing for this project immediately, but as part of our jobs we need to coordinate on the project and discuss our work with a myriad of people, such as developers and project managers. A lot of the time, these people hold more subject knowledge than we may have, and this often results in designers feeling scared to speak up in group discussions, thinking we might embarrass ourselves or sound stupid by saying the wrong thing. In this talk, I will discuss how instead of being intimidated by subject matter experts in this situation, designers can re-position their own idea of how to feel like a smart and qualified person in the room. By coming to the table ready to ask questions and not being afraid to share our own point of view, we can show that we are just as able to as anyone to provide great contributions, regardless of our experience in a specific technical domain. Designers may feel like they’re not the “smartest”, or most knowledgeable person in the room, but we still play a vital role on our team and business. By learning how to navigate these types of uncomfortable situations, designers can be stronger contributors than ever.

Muséplass
Hødden
Nøsteboden (map ) — Speaker's dinner

Friday

Reception area — Registration
Galgebakken
Learning by failing to grow quality - Root Cause Analysis in practice.
Kate Balcerzak and Bart Szulc

Do you have this feeling certain features will yet again start failing in upcoming release? When you catch a bug, does it seem like a deja vu? Incidents happen. Most of us think of them as materialised risks, but they also can be considered as opportunity. Opportunity to learn and improve. Would you be interested to learn how to draw conclusions from failures, propose corrective and preventive actions, and with them improve your development process and grow quality mindset in your team? This is a workshop for you.

 

We are all agile nowadays, thus we all strive to self improve iteration over iteration. Regular retrospectives help flush out issues with delivery process, compare current iteration with previous, identify things need addressing, areas worth investing in to increase velocity.

 

However, what happens when we catch a bug? Do we sit together as a team to identify what went wrong as we would normally do seeing a drop in our velocity in current sprint? I don’t think so. Most likely team will fix the bug and move on with feature development. Probably new regression tests will be added to prevent the bug from happening in future.

 

Regression doesn’t prevent bugs from happening. It helps with catching recurring symptoms of deeper problems, before they reach our customer and our users. Tests alone don’t address root causes. We’re like doctors prescribing yet another drugs. Not spending enough time on doing patient interview to find problems with lifestyle. Missing nutrients in our team diet.

 

You will learn how to spot and prevent sources of bugs. We’ll walk you through Root Cause Analysis process on a real life incident you can relate to. Help you understand all vital parts of such analysis, and show you how you can conduct similar process next time you catch a bug.

 

During workshop you will learn:

  • techniques helping build context in which incident happened,
  • how to build timeline and why it’s important to have one,
  • how to identify causal factors and how they differ from root cause,
  • techniques helping figure out root cause,
  • what are preventive and corrective actions,
  • how root cause analysis can not only help prevent bugs from recurring but improve your testing skills.

 

Key takeaways:

- what is root cause analysis

- what are causal factors and how they are different from root causes

- techniques helping identify root cause, propose preventive and corrective actions

- how being better in identifying root causes can help you become better tester by focusing your attention on most likely broken parts of your system

Galgebakken
Dragefjellet
Muséplass
Teatergaten
Strangehagen
Hødden
Downstairs — Coffee break
Galgebakken
Learning by failing to grow quality - Root Cause Analysis in practice.
Kate Balcerzak and Bart Szulc

Do you have this feeling certain features will yet again start failing in upcoming release? When you catch a bug, does it seem like a deja vu? Incidents happen. Most of us think of them as materialised risks, but they also can be considered as opportunity. Opportunity to learn and improve. Would you be interested to learn how to draw conclusions from failures, propose corrective and preventive actions, and with them improve your development process and grow quality mindset in your team? This is a workshop for you.

 

We are all agile nowadays, thus we all strive to self improve iteration over iteration. Regular retrospectives help flush out issues with delivery process, compare current iteration with previous, identify things need addressing, areas worth investing in to increase velocity.

 

However, what happens when we catch a bug? Do we sit together as a team to identify what went wrong as we would normally do seeing a drop in our velocity in current sprint? I don’t think so. Most likely team will fix the bug and move on with feature development. Probably new regression tests will be added to prevent the bug from happening in future.

 

Regression doesn’t prevent bugs from happening. It helps with catching recurring symptoms of deeper problems, before they reach our customer and our users. Tests alone don’t address root causes. We’re like doctors prescribing yet another drugs. Not spending enough time on doing patient interview to find problems with lifestyle. Missing nutrients in our team diet.

 

You will learn how to spot and prevent sources of bugs. We’ll walk you through Root Cause Analysis process on a real life incident you can relate to. Help you understand all vital parts of such analysis, and show you how you can conduct similar process next time you catch a bug.

 

During workshop you will learn:

  • techniques helping build context in which incident happened,
  • how to build timeline and why it’s important to have one,
  • how to identify causal factors and how they differ from root cause,
  • techniques helping figure out root cause,
  • what are preventive and corrective actions,
  • how root cause analysis can not only help prevent bugs from recurring but improve your testing skills.

 

Key takeaways:

- what is root cause analysis

- what are causal factors and how they are different from root causes

- techniques helping identify root cause, propose preventive and corrective actions

- how being better in identifying root causes can help you become better tester by focusing your attention on most likely broken parts of your system

Galgebakken
Dragefjellet
Muséplass
Teatergaten
Strangehagen
Hødden
Restaurant — Lunch
Galgebakken
Tårnplass
Dragefjellet
Coaching superpowers: exquisite discovery and resonating with customer needs
Richard Cornelius and Martin Burns

Summary:

A workshop that is designed to be very hands-on and suitable for anyone and everyone who wants to get answers to problems and not just coaches.

Clean Language sounds easy in theory, but it is hard work to get it working and sounding natural. This workshop uses Mike Burrows 15-Minute FOTO exercise as a basis https://www.agendashift.com/15-minute-foto , enabling participants to take turns and practice in a safe non-live environment.

This is a very practical session enabling participants to discover their own solutions and real options.

 

Detailed description:

A learning workshop that is designed to be heavily hands-on and suitable for anyone and everyone who wants to get answers to problems and not just coaches.

When trying to discover solutions to a client’s needs it’s very easy to go into consultancy or teaching mode. Often these are not necessary or even desirable as the client is likely to have far more context-based knowledge and so it’s important to use this intrinsic knowledge as much as possible. Clean Language (CL) is very good at preventing these personal opinions and ‘helpful’ suggestions and this session aims to provide enough real practice so that participants overcome any initial apprehension, leaving confident and able to use in a work environment.

This workshop uses Mike Burrows 15-Minute FOTO exercise as a basis, enabling participants to take turns and practice in small groups and in a safe non-live environment. It is a very practical session with the expectation that participants will discover their own solutions and real options that they can then explore further and put into practice after they leave.

It is organised around the participants learning for themselves and as such designed to be slide presentation free, instead each person will leave with their own simple reminder.

The primary focus will be to allow participants adequate time to be comfortable using Clean Language and depending on the speed of the participants, we would then like to expand further on their outcomes previously generated. Showing a simple method for prioritisation and discovering how to use these options as a basis for an experiment, taking the hypothetical idea into a real-world solution.

Dragefjellet
Muséplass
Teatergaten
Strangehagen
Protection Poker
Martin Gilje Jaatun

Software security is about creating software that keeps performing as intended even when exposed to an active attacker. However, it is impossible to prevent all security flaws and vulnerabilities, since you will always have limited resources, in terms of time, money, and/or expertise. It is thus most important to prevent, detect and remove flaws and vulnerabilities with high risk, i.e., those that can easily be exploited by attackers, and that may impact important assets. Protection Poker is a tool for risk estimation to be used as part of the sprint planning meeting, in order to identify the features in the current sprint that represent the highest security risk, and that thus may need additional attention to software security and/or functional security requirements. An important side-effect of playing Protection Poker is a general raising of security awareness within the development team.

 

Protection Poker is meant to played by the whole team, and for each feature at least two rounds will be played: Once to determine the value of each asset the feature/requirement "touches", and once to determine the exposure of the feature. We define exposure as the extent to which the feature (when implemented) increases the attack surface of the system, what type of assets are made available through the feature, and to what extent it requires special competence to exploit the feature.

 

This talk will explain the basics of Protection Poker, and explain how it can be played. Participants will then get a chance to play Protection Poker themselves, on an artificial case. Protection poker cards will be provided for all participants.

 

More information can be found at https://www.sintef.no/protection-poker

Strangehagen
Hødden
Downstairs — Coffee break
Dragefjellet — See you next year