Recently I took the opportunity of the INCOSE International Symposium being in Washington DC to consider how modern approaches to Systems Engineering might impact an issue with political and social implications, specifically electronic voting system (EVS) security. It’s impossible to open the newspaper or turn on the TV without hearing something about election security issues. In our home state of Georgia, we’ve recently moved to replace all of our electronic voting machines with similar machines that produce a paper trail. We are also investigating a possible penetration or attempted penetration of our state voter registration database. And of course, the constant stream of stories about national elections being potentially influenced by foreign actors.

What I want to do in a series of blog posts is describe how Model-based systems engineering (MBSE) can have an impact in this area. For us at Intercax, the core concept of MBSE is the ability to create a single unified digital model of our system in order to be able to, in this case, explore the security implications for such a system. I will provide some evidence in these presentations of three propositions.

• MBSE provides a clear and self-consistent specification of EVS requirements, hardware, software, process and logistics, all the primary aspects of the system itself.
• Using this clear specification, MBSE allows for the systematic definition of failure modes for security analysis.
• MBSE provides a framework for connecting multiple models in different software tools and building a unified roadmap of the system data, which allows the investigators looking for security vulnerabilities to explore the system more efficiently and find unexpected chains of causation more clearly.

Figure 1 Total System Model Architecture

The overall architecture of the example is shown in Figure 1. We’re going to model system architecture in SysML, specifically IBM Rational Rhapsody and let it interact with additional tools that are part of our development process: a requirements management tool (IBM DOORS NG); mechanical & electrical CAD tools (NX, a mechanical CAD tool from Siemens); software configuration with GitHub, and issue management with JIRA. We will be using an interoperability platform from Intercax called Syndeia as a means for connecting and querying this combination of tools as an integrated system model. Now the specific combination of tools used here is not unique. A parallel blog series is being published using Cameo System Modeler and Jama Connect. Both Rhapsody and MagicDraw SysML models will be published in the final installments of the blog series.

Figure 2 Composition of System Domain

We begin with an initial description of the system domain we’re trying to model in Figure 2. The system of interest from our point of view is the Electronic Voting System. It consists of three levels in our example. The county level is the highest level here, but we could easily extend the approach to higher levels. The county level has multiple county officials and a county central server. It also has multiple precincts where the actual voting takes place, each with multiple precinct officials as users and one precinct central computer. Each precinct also has a set of voting machines Direct Recording Electric Machines (DRE), standalone electronic voting machines that individual voters will come and cast their ballot on. The SysML Use Case diagram in captures the system’s objectives.

• A voter basically wants to cast a ballot and have it recorded correctly.
• A precinct official has a number of different responsibilities; they have to authenticate voters who come to the precinct, they have to test and validate the voting machines, the DREs, and they have to verify the final vote totals that are transmitted from their precinct.
• At the county level, there additional responsibilities, preparing ballots, maintaining the DREs and other equipment, and tabulating the results.

Figure 3 EVS Use Case diagram

Figure 4 (Mis)Use Cases

These are the high-level objectives of the system as it is supposed to work, but there is a user, in some senses, of the system that we also have to consider and are particularly focused on in this series. That is a Bad Actor, somebody who wants to interfere with the proper operation of the system. We can think of them as having use cases (or it might be more appropriate to call them misuse cases). For example, the Bad Actor shown in Figure 4 might want to able to Steal Votes (delete, change or add votes to those produced by the regular voters). This could be done potentially at the individual voting machine or DRE level, the precinct level, or the county level. We also have to consider other scenarios that are preventing voting. By selectively preventing voting in particular districts or precincts, it might be possible to steer the results of the election to some desired outcome that didn’t represent the true consensus of the community. Preventing voting can include denying service, again at the individual voting machine level, the precinct level or the county level, preventing people from actually casting their votes. There is also a somewhat subtler scenario in which votes that have been cast are invalidated by tampering or even appearing to tamper with the voting system in some fashion. All of these are potential effects of security failures or vulnerabilities within the system.

In the next post, we will look at managing requirements in DOORS NG and Rhapsody simultaneously using Syndeia, the MBSE interoperability platform from Intercax.

Related Posts:

• MBSE for Electronic Voting System Security (Rhapsody) – Part 1 (this post)
• MBSE for Electronic Voting System Security (Rhapsody) – Part 2 
• MBSE for Electronic Voting System Security (Rhapsody) – Part 3 
• MBSE for Electronic Voting System Security (Rhapsody) – Part 4
• MBSE for Electronic Voting System Security (Rhapsody) – Part 5 
• MBSE for Electronic Voting System Security (Rhapsody) – Part 6

Tweet