This presentation explores a 2024 supply chain cyberattack on Unix systems to install a backdoor. By modeling the attack’s social engineering phases as control loops, vulnerabilities in Unix’s supply chain were exposed. The analysis shows how standards from Unix distributors like Debian could prevent coercive tactics, such as bullying contributors into unsafe actions. Insights and an attack timeline are presented to encourage STAMP adoption in the open-source security.

This talk uses a Google Maps incident to contrast the traditional Root Cause Analysis (RCA) with a CAST analysis, demonstrating how CAST enabled us to move beyond root causes and drives more robust engineering solutions.

This talk presents a new design framework that provides a process for using the results of an STPA analysis of the system (performed early in the design lifecycle) to make the design decisions needed to create a system architecture. These design decisions include deriving system requirements, identifying system functions, and allocating those functions to system elements to create the system architecture. Examples from an air traffic control case study are used to demonstrate that an STPA-informed architecture development process can help systems engineers to make more safety-informed design decisions and allow them to design safety into a system's architecture from the beginning.

• FSQ Experts applied STPA within the Helios project, a research initiative for an electric cargo bicycle with a novel “Follow-Me” autonomous mode.
• STPA helped surface hazards such as the bike following the wrong person, losing cargo on sharp turns, or stopping without reason.
• STPA highlighted critical socio-technical interaction gaps not typically addressed by conventional methods.
• A team with limited prior STPA-experience successfully conducted the analysis, however, fragmented execution raised effort and complexity.
• STPA proved valuable for identifying mission-level and human-interaction risks.

• SMS-based MFA, despite its well-known limitations and vulnerabilities, remains a widely used security layer across industries.
• One of the potential challenges in SMS-based MFA is user-system interaction that can trigger hazardous states, such as account lockouts that lead to operational losses.
• By applying STPA, we can analyse common user errors that contribute to these losses.
• The outcomes of this analysis can be used to configure the system to tolerate benign mistakes, reduce false positives, and strengthen resilience without sacrificing usability.

Discussion of questions and comments submitted live by attendees. This is your chance to ask any of the presenters or MIT your challenging questions. Get expert answers on controversial topics, what to do about a challenging pitfall, or any other topic.

• Traditional SRE practices focus on component failures, but STPA addresses system-level losses arising from component interactions.
• A Google Maps Routing outage case study is presented, where the root cause was a system design flaw, not a component failure.
• By applying STPA, a total of seven design flaws were identified and corrected before the system was built, preventing potential outages and service disruptions.
• STPA is a valuable tool for proactive system safety and reliability, enabling engineers to identify and mitigate potential hazards early in the development process.

This talk presents lessons learned from running STPA on program management for a specific program at Google.
• STPA clarifies program goals and identifies unclear or unassigned program actor responsibilities.
• STPA shifts mindsets to enable program improvement and optimization, generating valuable insights beyond simply identifying issues that need to be fixed.
• STPA can generate useful results with minimal time investment (45 hours total) and a small team (3 people).

• This presentation outlines an Airbus Protect study evaluating STPA's effectiveness on the AIDA (Aircraft Inspection by Drone Assistant) system , assessing the methodology's tangible outputs and challenges.
• The analysis identified 85 Unsafe Control Actions (UCAs) and 327 loss scenarios , revealing critical design flaws such as a missing validation interlock in the control desk and the drone's lack of software for updating stored data.
• We conclude that STPA effectively identifies risks from human factors and complex interactions. This study helped us understand the time investment required and necessitation of close collaboration between safety and design teams to implement STPA.

This 18-month study, funded by the Department for Transport (DfT), United Kingdom, forms part of the regulator’s Future of Flight programme. This work, applying STPA, has assessed the safety of future eVTOL aircraft operations in UK airspace and identified 50+ high-priority areas to develop regulations.

In 2024, regulator SMEs from FAA, EASA, ICAO, NASA, and ANAC teamed up to study STPA for regulatory applicability. Can STPA close critical regulatory gaps and reveal hazards missed by current practices? The SMEs applied STPA to real-world systems already certified through standard methods. Catastrophic design flaws were found by STPA, including conditions for dual engine shutdowns without any component failure. Could STPA have caught the 737 MAX issues? Could it safeguard future technologies like eVTOL and AI? This study gives surprising insights and new questions for the future of aviation safety oversight.

Discussion of questions and comments submitted live by attendees. This is your chance to ask any of the presenters or MIT your challenging questions. Get expert answers on controversial topics, what to do about a challenging pitfall, or any other topic.

SMS - Must have one published and stick to it in operations. The organizations culture is the safety culture - leaders have to walk the walk. STAMP systems thinking can only happen in a culture that nurtures honest reporting.

• A gap exists between certification and operation of the S92A and other rotorcraft.
• Flawed mental models have led rotorcraft to be regularly operated in environments for which they were not originally certified for.
• Unsafe regulatory/OEM decisions have created these flawed mental models in pilots.
• CAST can be applied to uncover accident causal factors at the regulatory level.

• Content of SAE J3307 STPA Standard for All Industries
• Task Force membership skill sets
• Keeping Task Force members engaged in effort
• Navigating the SAE hierarchy
• Issues experiences along the way and some solutions

We will walk through the analysis of an airline incident, showing the results from typical root cause methods compared to the insights from CAST.
• See how to reveal additional causes and systemic factors by using CAST
• See how recommendations can be improved by using CAST to model the system and organizational structures that shape behavior
• Learn practical lessons for applying CAST in airline operations

• AI systems have the potential to benefit society. But they also present novel risks.
• We applied CAST to nearly 100 recorded incidents involving AI systems.
• Losses were varied, and ranged from loss of life/property to loss of freedom.
• CAST is an effective technique for identifying recommendations to mitigate AI risks based on these incidents.

Discussion of questions and comments submitted live by attendees. This is your chance to ask any of the presenters or MIT your challenging questions. Get expert answers on controversial topics, what to do about a challenging pitfall, or any other topic.

Key Insights:
Systemic design flaws, not individual errors, are the root causes of many incidents. CAST can help shift the focus from blaming individuals to understanding and addressing systemic issues, which is crucial for preventing recurring failures.
The absence of feedback loops and role clarity significantly contributes to failures.
Incorporating CAST into routine safety evaluations can identify and address systemic vulnerabilities early.

• Apply STPA to CHAPS, the UK’s high-value payment system.
• The analysis identified 3 losses and 4 hazards in CHAPS.
• A control structure was created to illustrate and 15 UCAs were identified based on that.
• For every UCA, 1 or 2 scenarios were identified.
• Mitigations for operational and liquidity risks were introduced.

• Integration of STPA in current System Safety Engineering processes using Model-Based Safety Analysis (MBSA).
• Translation of STPA's loss scenarios into a formal language (AltaRica).
• Direct simulation of Loss Scenarios in an MBSA environment.
• Knowledge-based approach, allowing a full traceability between STPA and MBSA.
• Application to a drone system assisting the pilot in pre-flight aircraft inspection.

Summary of ICAO's exploratory application of STPA to the Advanced Air Mobility (AAM) ecosystem, conducted through moderated workshops with aviation safety experts.
Initial evaluation of STPA methodology to AAM through three structured workshops,
Demonstrating its effectiveness for analyzing complex, emerging aviation systems with multiple stakeholders and evolving operational concepts
Identified key success factors including skilled facilitation, finding the appropriate abstraction levels, and iterative approaches for analyzing incompletely defined AAM ecosystem.
Evaluation conducted under the auspices of the ICAO Advanced Air Mobility Study Group and the Safety Risk Management Working Grou

• STPA provided a comprehensive analysis of Autonomous Collision Avoidance Systems (ACAS), identifying operational contextual factors and unsafe conditions.
• It included interdependencies between system components, communication pathways, cybersecurity aspects and environmental factors often overlooked in traditional methods.
• STPA revealed loss scenarios caused by UCAs or in case of control actions be improperly executed or not executed, associating causal factors and constraints.
• The analysis covered autonomous decision-making, improved coordination protocols, and system resilience to external disruptions.
• STPA’s findings delivered actionable recommendations for the ACAS operation.

At the 2024 MIT STAMP Workshop, we introduced MicroSTAMP, "towards" a free and open-source STPA-compliant tool, supporting steps 1-3 of STPA through a microservices-based architecture. In this talk, we will demonstrate the complete tool, now providing support for all STPA steps. We have implemented step 4 and enhanced the tool based on the feedback received. The microservices approach ensures the tool's modularity, allowing independent or integrated use of each step and enabling it to adapt to the specific needs of different stakeholders. MicroSTAMP streamlines STPA analyses, addressing the time and resource challenges faced by safety analysts.

• Overview of applying STPA guidelines to analyze sociotechnical harms in AI systems via three case studies
• Three main insights from applying STPA to the three case studies
• Key lessons learned and challenges faced in implementing STPA for this purpose

Discussion of questions and comments submitted live by attendees. This is your chance to ask any of the presenters or MIT your challenging questions. Get expert answers on controversial topics, what to do about a challenging pitfall, or any other topic.