How Desjardins could have prevented the data breach of 3 million members

June 20th, 2019 was a sad day in Montreal and maybe across Canada. The personal information of more than 2.9 million Desjardins members was compromised. An employee, who was fired, leaked the data to individuals outside the organization, according to the credit union.

Desjardins is not giving out any information about the employee that was fired nor telling us what position this employee had. Let's explore the IT positions that normally have access to such sensitive data and how we can restrict their access.

Some of the data that was compromised include:

1. First and last names
2. Date of birth <- Outch
3. Social insurance numbers (SIN) <- Outch
4. Address
5. Phone numbers
6. Email address
7. Details about banking habits
8. Desjardins products

Passwords, security questions, and personal identification numbers were not compromised.

My technical assumptions:

1. The information was stored in a database (DB).
2. The SIN and DOB information were both stored in clear text in the DB columns.
3. The database is not running Oracle nor SQL because those 2 are easy to secure, so probably an old version of Sybase DB like version 15 that does not support encryption.
4. The operating system running the DB is UNIX based.
5. The malicious employee had root and SSH access the UNIX system.
6. The malicious employee had admin access to the DB.
7. The malicious employee created a DB dump file and stole it via a USB key.

What teams have access to such sensitive information?

1. The database administrators: They use tools to manage the databases remotely and must not have access SSH access to the UNIX server hosting their DB. They must hide sensitive data either by encrypting the columns or encrypting the whole DB whenever possible to protect it from the UNIX sysadmins and backup admins. Encryption adds an overhead and adds a performance tax, thats why a decision has be made on whether the business wants more performance more security, or a mix of both.
2. UNIX sysadmins: They have full root access to the operating system therefore they must not have any access to the Database. Their role is to lock down the server so no one else has access to it. They must also encrypt the drive where the DB resides if the DB is not encrypted to prevent data breaches in the case of a hard drive or server theft.
3. Backup admins: If the database is not encrypted, the backup admin can simply restore a copy of the DB and have full access to the information. The backup admin role is to ensure that no one (including third party) can restore the tapes without the encryption key. That's why it's important to encrypt data before putting them on backup tapes/drives.
4. Application developers: This person does not typically have full access the DB nor to the server, but he or she is able to run a queries to extract data from the DB. This persons role is to secure the application. The DBA can limit the developers access. The developer can also protect the data by encrypting it directly from the application before storing in the DB.
5. The internal users: The application user normally has a very limited access to the application that makes the queries to the DB. In general the application is web based and uses HTTPS to encrypt information in transit (client-server communication).

How to prevent employees or hackers from stealing information?

There is always more than 1 team/employee that have access to sensitive information in large organizations. That's why the IT Governance team must enforce Separation of Duty (SoD). Separation of duties, also known as Segregation of Duties, is the concept of having more than one person required to complete a critical enterprise task. The best practice is to require a minimum of 1 employee from 2 different teams working together to complete the task. From a business perspective, this is a control intended to prevent fraud and error. In other words, it's an internal security control that helps the organization manage risk more effectively in order to lower the probabilities of having a data breach from either internal or external threats.

In conclusion, no system can ever be 100 percent secure but there are many different strategies that can be used to protect data based on budget, time constrains, and application limitations. In most cases, information can be protected and encrypted both at rest and in transit.

Liked this article? Please leave your feedback and lets connect on LinkedIn: