Data is simultaneously an advantage and a risk for any organization. Horror stories about colossal data breaches make headlines faster than murders and can cause significant drops in market value, loads of negative publicity, and considerable distrust in the company.
Some of the biggest scandals involving compromised data were the attack on Yahoo in 2013 (3 billion user accounts compromised), Mariott’s ongoing data breach between 2014 and 2018 affecting 500 million customers, and the more recent Sephora problem in South East Asia with unknown magnitude.
No organization is safe; there is no magic formula to ensure 100% data protection. Yet, since the advantages outweigh the disadvantages, data-rich Business Intelligence and CRM systems are here to stay, and organizations need to find reasonable ways of ensuring their security.
Here are a few implications to consider when thinking about data security management at scale.
Identify Vulnerabilities
A rule of thumb is that any data flow is vulnerable by definition, as it can be hijacked and used as a loophole into the system. Even just reading information from a database or being able to copy it to an outside repository is a significant concern. Successful exploits can modify, delete, or create new records. While some attacks require human consent, others are more subversive.
One of the easiest ways to secure your data systems against such problems is to keep the software updated as soon as a new version is released. Compared to content management systems, for example, most versions for Business Intelligence suites don’t necessarily offer new features but patch observed vulnerabilities, making the systems safer.
Encrypt Communications
Data encryption incurs more costs and requires additional resources, but it is money well spent. Business Intelligence tools are primary targets for hackers, since this is where competitive advantages reside, and controlling data would mean controlling an entire company.
Without going paranoid, you should always consider the possibility of the man-in-the-middle attack, which means that any communication segment could be intercepted by hackers and deciphered. Once on the server, data is not safe in plain text; it is best to keep it encrypted at all times and protected by two-factor authentication.
An additional protection layer would be to segment the data storage and distribute it over several servers, with some redundancy to protect yourself from any central attack. Your data should be like a puzzle that only you have the map to put together.
Securing BYOD Policies
Another reason to enforce end-to-end encryption is the growing trend of installing Business Intelligence tools on employee’s own devices, such as smartphones and tablets. These are frequently used in unsecured contexts such as public Wi-Fi networks and thus can expose corporate data to theft opportunities.
Set Permissions and Hierarchies
Since knowledge is power, it needs to be restricted by roles. Always create a set of permission rules for each user in your organization or design user groups with specified rights. Make sure each user has enough permissions to do their daily tasks without external input yet with enough restrictions in place to protect sensitive information.
It is also a wise idea to track changes to each file and have a log showing the authors of such changes. Also, you can restrict access to sensitive data to your institutional network based on IP, although this could be challenging for organizations allowing employee mobility.
An innovative way of restricting access is using image recognition technology to grant permissions based on biometrics like retina or fingerprint scanning or even face recognition. This is an idea derived and used by law enforcement to scan crowds for suspects.
One last tip: for sensitive data, ensure there are at least two managers who can grant access in case something goes wrong as this will save you considerable efforts in the long run.
Password Protection and Access Control
While essential, the problem of setting strong passwords and keeping them private is the primary failure point of most Business Intelligence systems. One human error can compromise your entire network faster than any hacker attack.
Consider Tarpitting
Tarpitting is a method of deliberately slowing down the server when it detects an abnormal volume of operations, like in the case of spam mail. This buys the organization time to detect the attack and potentially discourages the attacker.
Cloud-ready?
Business Intelligence solutions and the cloud are complementary technologies that work seamlessly together.
If you are keeping your Business Intelligence data in the cloud, your service provider is responsible for the security of the entrusted information. This is why you need to choose a reputable service, like those offered by industry giants: Amazon, Google, or IBM, among others. They have the necessary infrastructure, know-how, and financial resources to ensure state-of-the-art security with minimal downtime. Keep in mind that having an on-premises server means being exposed to the same risks but with far higher costs to get the same level of protection.
Use Business Intelligence for Security
Last but not least, you can use a Business Intelligence system itself to enhance the security of your company’s data. Create a “security view” in your Business Intelligence dashboard and look at the number of e-mails sent, the size of uploaded/downloaded data, and the locations of the IPs accessing data. Of course, if this is too much trouble for your in-house team, you can always find external help.
Business Intelligence and Security: A checklist
There are three levels of security for a Business Intelligence tool, and each of them should be of a world-class quality.
At the process level, you need to use the DREAD risk assessment model to scan for vulnerabilities and run external penetration tests. When it comes to system/object level, be sure to ask for integrations with your current systems and a clear user hierarchy. Finally, at the data level, ask for row-level security to protect your internal data assets.
Comments on this publication