Dec 18, 2015 Lessons from the Clinton Campaign’s Data Breach
Right now, a storm is growing more intense around the Sanders and Clinton presidential campaigns—a storm stemming from a data breach.
Both campaigns use a system called VoteBuilder to store crucial information about voter preferences and patterns. A “firewall” is supposed to keep each campaign’s proprietary information invisible to the other. This system is made available by the Democratic National Committee (DNC) and was created and is maintained by a firm called NGP VAN.
Due to a software bug, the other day each campaign had access to the other side’s proprietary data for a short time. And a member of Sanders’ campaign has been accused of peeking. As NGP VAN has stated:
“On Wednesday morning, there was a release of VAN code. Unfortunately, it contained a bug. For a brief window, the voter data that is always searchable across campaigns in VoteBuilder included client scores it should not have, on a specific part of the VAN system. So for voters that a user already had access to, that user was able to search by and view (but not export or save or act on) some attributes that came from another campaign.”
Risky Architecture May be the Ultimate Culprit
Details of this incident currently are becoming known to the public. And the event’s fallout is far from clear at this time. However the situation plays out, it holds potentially valuable lessons regarding privacy and data security.
Without knowing specifics of the bug or the system’s architecture, it is worth noting that the breach may stem from one of the most common architectural errors.
Often, when a user is able to access data they do not have rights to, it is because the system is configured to store all data in a single database. Think of two bottles of soda, stored in the same fridge. You are given a straw that is stuck in your bottle of soda—and you are supposed to drink from that. Then—uh-oh—up strolls a software bug that hands you the end of the wrong straw.
A More Thoughtful Approach
When different organizations (or various units of a single firm) share a database but access must be restricted to members of each organization, a shrewder approach is to store each organization’s set of data in its own database, with its own group of usernames and passwords. You can’t inadvertently be given the wrong straw by some bug—because the two bottles of soda are in different refrigerators. In fact, it would take a significant amount of hacking for you to access information stored in a separate database. This approach need not necessarily add cost to the project if the databases sit on the same server.
A range of other security steps that provide additional layers of protection for sensitive data will be incorporated into a thoughtfully architected system. To set up an informal chat about the approaches that can help prevent a similar breach at your organization, just drop us a line.