Data Encryption Software: DMASA Database Leaked In South Africa.

Direct Marketing Association of SA (South Africa, aka DMASA) has admitted that a “Do Not Contact” list (DNC) has been leaked, which is more than possible when it gets passed around each month via email, in spreadsheet format.  Clearly this is not a case where the use of full disk encryption like AlertBoot would have been helpful (unless they decided to save the information to a USB thumbdrive and sent it via post); however, I wanted to comment on it because of everything that DMASA did right.

DMASA’s Leak, but They’re Not Responsible?

According to an article at, there are 389 members who receive DMASA’s DNC.  These members cross-reference their own records with DMASA’s list, ensuring that they’re not violating the Consumer Protection Act by calling someone who’s on the list.

This list, a database in spreadsheet format, contains “identity numbers, contact details and addresses,” which is pretty much what one needs for ID theft and fraud, according to a quoted expert.

DMASA has been quick to point out that they’re not the ones who’ve leaked the database.  As proof they’ve presented a “forward-tracking report” that shows the protected databases for April and May have been forwarded to members only.  The passwords for accessing the database have also been sent, separately, to members only.

Of course, this doesn’t prevent someone from copying the data and forwarding it to non-members, or even forwarding the protected file along with the password, which I’ll come back to in a minute.

DMASA may have an ace up its sleeve:

the DMASA can track down a member that leaks the registry because each of the 389 lists is seeded with false information. If the database had been leaked, it would have been by a member…

Excellent!  And yet, it also has it shortcomings.

At the end of the day, DMASA seems to be right in that they’re not responsible for the leak.  I’m not sure what South Africa’s laws are regarding data breaches, so it could be that they’re responsible for the data regardless of who caused the breach, but DMASA has pretty good case that they weren’t the ones that leaked the DNC.  Unless….

Quis Custodiet Ipsos Custodes?

Or, who will guard the guard themselves?  DMASA has a pretty good strategy going: not only are their files protected (I’m assuming they must have used encryption software for files, based on how they seemed to have put a lot of thought into data security), they’ve figured out a way to find who’s responsible if something happens.  Yet, I question whether this will work, and whether DMASA can be truly absolved from the incident.

While DMASA has done right by sending a protected file and its password in separate emails, this is no guarantee that DMASA’s own people are not responsible for the breach.  What if someone at DMASA:

  • Copied the file and the password to a portable storage device?  This won’t show up on the email tracking report.

  • Saved the file as an unprotected file, renamed it, and emailed it?  If the tracking report filters according to a file name, it would also not show up.

  • Modified the data (e.g., added 5 random digits in front of the actual data), saved it, and emailed it?  Filters for patterns of numbers wouldn’t pick it up, and getting rid of those extra digits later is a cinch.

Of course, one should observe that the recipients of the files can do the same.  Hopefully, the false data will lead to the person responsible.  However, even that poses problems.  The problem with fake data is that it’s easily traceable if you know what you’re looking for.

For example, let’s say that fake identity numbers were created to look like the real thing (after all, it makes no sense to use real identity numbers as fake data).   Most “identity” numbers — be it SSNs, medical insurance numbers, credit card numbers, etc — have a structure to them.  That’s why credit cards also come with an expiration date and a security code.  SSNs?  Not so much.

South African’s identity numbers derive from an algorithm, like most if not all countries (otherwise, sites like these wouldn’t exist), so it’s a matter of running all IDs in the DMASA database via such a service and picking the ones that are invalid.

The perpetrator forwards only the valid ones, and presto! we have no idea who’s responsible.

You’ve got to hand it to DMASA, though: they did all that they could (and probably more; I’m pretty sure there’s stuff they’re not revealing in order to figure out the person responsible).  And, yet, they had a breach.  In the majority of such cases, the problem lies with the custodes, the people who are charged with making sure there isn’t a breach.

People have to understand that data security is ultimately a trade-off and that there cannot be 100% security.  They key is to ensure that an operation, business or otherwise, can continue while significantly reducing the chances of a data breach, which DMASA seems to have done.

Related Articles and Sites:

Comments (0)

Let us know what you think