MBSE for Electronic Voting System Security – Part 5 (Rhapsody)

MBSE for Electronic Voting System Security – Part 5 (Rhapsody)
September 11, 2018
Blog

The careful modeling of the system described in the first four parts of this series requires a great deal of effort by multiple contributors, but one of the benefits is that it enables us to investigate the security vulnerabilities of the system in a complete and systematic fashion. FMEA stands for Failure Mode Effect and Analysis. It is a standard systems engineering approach to identifying the failure modes of a system, in this case failure modes that lead to system vulnerabilities. It also includes processes to eliminate or mitigate those failure modes and we need a way of tracking those efforts.

rhapsody-1

Figure 1 Electronic Voting Security Model FMEA Table (Rhapsody)

Rhapsody offers a special profile (DependabilityProfile) for failure analysis. In Figure 1, we show failure modes in a tabular format. The SystemFunction column contains the element of the model, either structural or behavioral, that may be vulnerable. The Cause column contains possible failure modes, vulnerabilities or more generally things that might go wrong. The last column shows the final effect of failure, or what is the impact.

Because we have created a very complete model of the system, it is straightforward for us to generate this table in a systematic fashion. We go through the model we have created, for example, starting with the sequence diagram for setting up the election in the upper right inset in Figure 2. The first task or message is transferring the DREs. What can go wrong? There are a couple of different possibilities. One, the DREs can get lost. Two, the DREs could be tampered with during transport between controlled environments. Then we can go to the next message, Create Ballot Template. What can go wrong there? In this case, someone could create an erroneous ballot. We go through the process step-by-step.

Figure 2 Rhapsody FMEA Table, Model Elements appear as FMEA Items

Deciding what the failure modes are is not automatic; the model does not do it for us. It requires subject matter expertise. Everyone who has worked in the field of Model-Based Systems Engineering understands that modeling does not replace subject matter expertise or engineering judgement; it enhances them. It makes subject matter expertise more accessible and engineering judgement more efficient. But by going through a process like this, we can generate these tables and we can do so in a very traceable fashion, identifying each item, the potential failure modes and the effects of those failures.

We can do the same thing with the software functions and hardware components. The lower right inset in Figure 2 shows our “test and validate the DRE software” activity, discussed in Part 4 of this series. The first action is to write the ballot test template to the internal RAM. It becomes the next row of the FMEA table. We identify a potential failure mode, creating an erroneous ballot, and its final impact. We can continue this process for the sequence diagrams, the activity diagram, the structural diagrams. We can go through each, item by item, and create a full list of failure modes. We can check that the final effect of failure items trace back to the misuse cases we considered back at the beginning, which helps double-check that all the effects of failure have been considered in our FMEA analysis.

The next part of the project is to fix the system by identifying and implementing a solution for each of the failure modes. Given how many potential failure modes have been generated, managing that project is a major challenge. It is similar to bug tracking and fixing in software development and we use JIRA from Atlassian in a similar way. We use Syndeia’s drag and drop interface to create and connect a JIRA issue for each failure mode in the SysML model. The issue now becomes directly accessible from the SysML element by right-clicking an Open Command and opens in the JIRA web interface, as illustrated in Figure 3. In the JIRA web browser, we can see the status of the issue, who is responsible, what is the schedule and what is the log of recent activities. Syndeia can identify which of the issues have been updated since the last check. This same information is available to any project member working from the FMEA table.

Figure 3  Rhapsody FMEA Table, Failure Modes connected to JIRA Issues via Syndeia

The final part of this series, which will complete both the Rhapsody and MagicDraw model discussions, will show how graph technology enables efficient exploration of the large models we have the potential to create. Efficient pattern matching queries find connections between SysML blocks, requirements, issues, failure modes and other model elements that enable us to identify extended chains of causation and emergent behaviors.  Download links to the SysML models in MagicDraw and IBM Rational Rhapsody will be provided.

Related Posts:

About Author

Dirk Zwemer

Dr. Dirk Zwemer (dirk.zwemer@intercax.com) is COO and Co-founder of Intercax LLC (Atlanta, GA), a supplier of MBE engineering software platforms like Syndeia and ParaMagic. He is an active teacher and consultant in the field and holds Level 4 Model Builder-Advanced certification as an OMG System Modeling Professional.