In this third post in the voter registration database auditing series, Solutions Architect John Dziurłaj talks about the data in the voter registration database and identifying what's critical.

In part one of this voter registration database (VRDB) auditing series, I briefly touched on the importance of identifying what should comprise the audit trail, without going into many specifics. In part two, I discussed the methods of performing a voter registration database audit. In this entry, I’ll take a deeper dive into what data is stored stored in VRDBs, identifying critical fields, and the importance of metadata.

What changed?

We should focus on data points that, if manipulated, could affect election outcomes. The following table describes some of the key data points often stored in voter registration databases:

You are encouraged to identify these data points in your own database and consider including them in your audit trail. This list isn’t exhaustive and there may be data points that are both specific and helpful to your own election audits.

There are legitimate reasons for data points in the above table to change, of course, the obvious examples being name change and address change. Voter identifiers are usually fixed upon issuance—think social security numbers and to a lesser extent driver's license numbers—but even these can be transcribed incorrectly. As per Hanlon’s razor, it is not always correct to attribute to malfeasance what can easily be explained by human error.

Importance of Metadata

Metadata is “data about data.” In auditing, it becomes as important—if not more important—than the data itself. Metadata can help confirm, or call into question the legitimacy of records within our system.

When did the change occur?

It’s important to include timestamps with every change in our audit trail. Elections are by their very nature calendar-based. There are deadlines for nearly everything, including:

• Finalization of polling locations;
• Voter registration;
• Early ballot requests; and,
• Cutoffs for performing list maintenance under the NVRA.

By being aware of these “data freeze” points, we can tune our tools to alert us of changes that fall outside the allowed window. These changes could be subject to additional scrutiny. Additionally, for offices that have regular business hours, we can look for changes outside the business window.

Who made the change, where?

“Who” doesn’t have to correspond to a person, it could be a non-person entity (NPE), such as the name of a computer, the name of an application, an IP or hardware address, a named account, or all of the above. Capturing this information allows us to detect behavior that is out of the ordinary, such as an account using privileges that aren’t typical for their day to day tasks.

How was the change made?

Changes can be executed against a VRDB in different ways. For example, a database administrator (DBA) might execute a batch job by logging directly into the database. That type of privileged access can have a drastic impact if VRDB modifications are improperly performed. An election clerk will often use a front end application that restricts the scope and type of changes that can be performed. Knowing how a change was made can help us identify unauthorized activity.

This is especially true if the change was made as part of an unauthorized data breach, as an attacker may have used a “back door” or gone around the system entirely. A common approach is for an attacker to bypass the database altogether, and exploit vulnerabilities within the technologies that the database depends on. This underlines the importance of taking a holistic approach to security and auditing through the use of dedicated cybersecurity tools such as vulnerability scanners and security information and event management (SIEM) systems. There may not be ways to directly record the “how” in your audit logs, but it can frequently be inferred via thorough analysis. Prevention and detection go together, hand-in-hand.

Parting thoughts

The reality is that we can only audit using the data we collect. That means we have to identify the data that we have, and the importance our organization attaches to it. The simple exercise of considering our organization’s crown jewels is a great starting point. By planning ahead, we can ensure that our audit trails will provide us with the best data for analysis down the road. In future posts, we’ll put our audit trail to work by using different techniques to perform research on database activity. Happy (audit) trails!