Member Spotlight

What does it takes to pioneer Threat Modeling in various industries? What are the lessons learned? We’re excited to invite Luis Servín to share his story. As a cybersecurity architect expert based in Germany, over the last 10+ years, he helped implement Threat Modeling from aerospace to automotive manufacturing.

As a Threat Modeling enthusiast and veteran, he joined our Spring 2023 Hackathon to gain fresh perspectives. The team he led is one of the finalists. During our virtual interview, Luis shared his threat modeling journey - the proud moments and the challenges. He also shared his take on the hackathon and what he’s looking to “threat model” next!

Tell us about yourself and your threat modeling career

What’s your role, and where are you based?

I’m the Platform Security Lead at Hapag Lloyd, based in Hamburg, Germany.

When and how did you begin your threat modeling journey?

I began threat modeling in 2011-2012 as a consultant for onboard systems for an aerospace corporation. From 2013 until 2020, I had the privilege of introducing threat modeling as a practice at an automotive manufacturer (OEM). I helped create the training, the deliverables’ format, and the career path for Information Security Architects at this company.

What obstacles have you experienced as you blazed the trail and introduced threat modeling at the automotive manufacturer company?

It was sometimes difficult to get into the flow when introducing threat modeling across the aisle from IT, such as into the R&D and factory environments.

There are so many differences in how the systems operate, the protocols used, and the legacy accrued over decades. It was so different that you constantly have the “imposter syndrome.” At some point, you realize that all systems have similar objectives: send/receive messages and operate based on them. Using basic secure design principles like those from Salzer & Schroeder and the IEEE top 10 secure design principles provide you with a great tool to identify potential vulnerabilities, and then the attacks and threats are easier to identify. Of course, you also need to read previous art in attacking these systems.

When I started trying to apply this to vehicle onboard systems there weren’t that many resources. Charlie Miller and Chris Valasek were starting to gain notoriety at Black Hat with their, by now, very well-known research leading to remotely controlling a Jeep.

The “not invented here” syndrome was also something we needed to work around. When experts in a field are confronted with other expertise, they try to reach for whatever they can recognize and try to apply it. We had long discussions on the theory around the method for threat modeling, but couldn’t get started with threat modeling until all the theoretical questions were cleared. Once we started, there were requests to provide exhaustive lists to run down and check for every possible attack.

The lessons learned from several years of creating the report format, training, and rating methodology helped to bootstrap the process, but it was not easy.

What accomplishment are you most proud of at this point in your threat modeling career?

I’m very proud of introducing threat modeling to a global company, training hundreds of colleagues over the years, and traveling to exciting locations for the training. I’m also very proud to have been the lead cybersecurity architect at this automotive company and pioneer in threat factory shopfloor systems (OT), helping create the methodology for the R&D engineers to introduce threat modeling to automotive systems and components. Some of the first threat models I created in workshops with the experts taught them how to do it as well.

Share your hackathon experience with us

What drew you to participate in the Spring 2023 hackathon?

I love threat modeling. I think it’s a nice opportunity to meet other people doing the same activity and learn from how they are doing it.

What does your team look like, and how did you work together?

Since I didn’t enroll with anyone I knew, I was assigned to a team and got to know new people. We used the messaging feature in the Threat Modeling Connect community to stay in touch. And we collaborated through Google Docs to create the deliverable together. The diagram was created with graphviz and maintained as a text file with “.gv” termination and the image created from that text representation. We kept the source file in GitHub, where everyone on the team could access it.

Everyone contributed the best they could. The document structure was there one day, then a table with findings appeared. Then we started discussing some of the findings and polishing them for the deliverable.

I proposed using “Gherkin” as the description template for the findings. Gherkin is usually associated with the BDD (behavior-driven development) movement. It sets clear expectations on what needs to be there, which action will be taken and the expected outcome. In that sense, it’s a great match for threat modeling. As an example, you create one scenario as:

GIVEN vulnerability, other preconditions
WHEN bad actor does this bad thing
THEN we expect this to happen
AND also this
AND this

I “translated” all the scenarios that the team had created into Gherkin and tried a very simple rating for the vulnerability. Rather than DREAD, which is dreadful, we decided to use a “Bug Bar” with low, medium, high, critical as possible values. This allowed us to concentrate in writing great findings and spend less time rating the findings.

What were some challenges you faced? How did you overcome them?

The biggest challenge was keeping the motivation up for the length of the competition. During the first week, all were active, but as the days passed, the participation declined.

A second challenge was discussing what a threat was vs. what a vulnerability was—then creating a coherent story around the vulnerability type and the attack applied by a threat abusing it.

Going from here

What are your top 3 takeaways about threat modeling from this hackathon?

• I hadn’t yet consciously realized that using inductive and deductive reasoning when threat modeling a system is possible. I’m definitely more of an “inductive” type of person and prefer to understand with diagrams how the system was architected. The use case was more for a “deductive” kind of person, where technology choices were thrown into the mix and descriptions were made, but no diagrams were presented.
• DFD Diagrams don’t have to use the “standard” circle, arrow, or parallel line format. As long as they are consistent, it is possible to draw them differently and provide more information for human analysis.
• Working across time zones with people of all ranges of skill levels takes work.

What do you plan to threat model next?

I would like to work on “threat modeling katas” and make them available online for anyone interested. I will present at the open security summit on April 19th on this topic. Register for free or watch the session if you’re interested. A kata is an exercise done in martial arts to create muscle memory. The idea of architecture katas for software design comes from Neal Ford. There is also a good GitHub repository of architectural katas, and from there, I will take one and threat model it. The summit is very participative and, as such, a perfect training ground to ask questions and help reach an objective, in this case, a threat model.

I am professionally starting a new phase in my career. I hope to have a chance to threat model marine systems while at Hapag Lloyd.

‍