Home > Analytics > What Are the Security Risks of Analytics and Other Platforms?

What Are the Security Risks of Analytics and Other Platforms?

What Are the Security Risks of Analytics and Other Platforms?


For the very first time, the average person needs to worry about the security of their information as data breaches become more commonplace; especially as many people are unaware why their information is valuable in the first place.

Why do Google, Amazon, and Apple, for example, care what sites you visit and who you interact with online?

Computers Are Very Good at Finding Trends

Using people’s habits as data points, companies are able to paint a picture of the “average” consumer. Known as “Big Data” this practice can be extremely profitable for companies. Website owners place small bits of code on web pages known as “tracking cookies” to keep track of your every click as you navigate the internet.

Screenshot of cookies on Google UK search page

This data is available both to the website owner and to the provider of the analytics “platform”. These tracking cookies can extrapolate not only information from the site they run from, but in certain situations, other sites you visit as well. If accessed by criminals, this same data can aid them in identity theft, blackmail, and corporate espionage.

There Are A Lot of Ways Data Can Be Leaked

Sometimes the party responsible for the leak is clear-cut, and sometimes not. In a recent opinion piece, Josephine Wolff dissects “due diligence”, and posits that a company is only responsible for making decisions that reasonably ensure they meet their obligations.

Attacking a company’s database systems is one of the most common ways attackers can get access to information they shouldn’t have. Through methods such as SQL injection (tricking a database into doing something it shouldn’t) or buffer overflow attacks (crafting malicious requests that cause computers to malfunction in predictable ways), attackers can compromise vulnerable systems.

It’s the company’s responsibility to follow good software practices, as well as keep their systems up to date. In addition, companies with whom you have user accounts should be employing database hashing, salting, and peppering (techniques based on mathematics which make data useless to an attacker for the purposes of signing into your account as you).

Unfortunately, there isn’t a great way to know if a particular web application employs these techniques. The best defense an individual has is to use a different password on every website, making it so that if their account is compromised, at least an attacker won’t be able to move laterally and compromise other services they use. People put a lot of implicit trust in big companies, but nobody is immune to cyber-attack.

Malware living on a user’s computer can intercept information as it travels to its destination. This is another common vector by which data leaks occur. Even if the information is encrypted in-flight via SSL/TLS, because the endpoint is responsible for doing the encryption, malware living here can potentially get access to information before it’s sent or written to the destination. Companies don’t have control over personal devices, so the responsibility is largely on the end user. Running endpoint anti-virus and taking on-screen instructions with a grain of salt can prevent these sorts of attacks.

Determining Compliance

Depending on the industry and location a business is operating in, different, and sometimes competing, data stewardship obligations are imposed. If you’re in the EU, or have even the potential to have clients who are, you are subject to the GDPR. This is ground-breaking legislation in a global sort of way.

Previously, different pockets of industries might be subject to regulations. HIPAA and HITECH impose privacy standards on the ways the healthcare industry in the US must handle information while PCI effects, globally, those who process credit card transactions. GDPR is different in that every EU citizen, from the moment of birth, has certain rights over their own data and how you can process it.

What Are the Penalties for Non-Compliance?

Violation of these rules is meant to be expensive, but nobody knows yet exactly how expensive it is going to be. The EU now has the right to impose financial penalties, and collect them through the legal system, if they determine data hasn’t been handled in a way compliant with the act. Only time will tell how aggressive the EU will be in pursuing violations that occur in jurisdictions outside of their own.

For example, the GDPR mandates opt-in consent; so a person needs to agree to what you’re going to do with their data upfront. Furthermore, a person can ask for a temporary cessation of activities relating to their data; in this case, businesses are both obligated to cease operations on the data but also be able to resume them later. These regulations make a lot of intuitive sense, but that doesn’t mean they make sense from a technical standpoint.

What Data Are You Even Sharing?

Perhaps the very most complicated consideration is the data a business doesn’t realize they’re sharing. With enough technical abstraction, it is absurd to make the argument that a business has the capability to understand in-depth every data-driven action taken once web analytics are considered. Implemented by way of small snippets of third-party JavaScript that runs on the client’s browser served from your website, analytics provide webmasters with the means to make data-driven decisions.

Popular choices include Google Analytics, Kissmetrics, and Microsoft Azure Analytics. They clue webmasters into demographic information. Who viewed the site, from where, and at what time? Even so much as an IP address recorded in a database along with a person’s name is specific enough for the GDPR to kick in, despite the fact that IP addresses are often not unique.

Using a data analytics platform is a choice but it’s often not presented like one. In all sorts of websites aimed for non-technical users, it’s simply dictated by a checkbox (often even checked by default). The savvy consumer needs to realize the potential implications of hosting these tracking cookies.

Thankfully, analytics providers worth their salt are aware of the challenges faced when providing their services. The burden of the administrator turns from technical to process-oriented. To be even remotely possible, we as an industry must make a shift towards better planning and better communication. The savviest Webmasters and Systems Administrators will start conversations, pose questions, and be open to new ways of doing things. They must think about these compliance requirements not as shackles constraining them, but as a roadmap for what products, vendors, and policies to suggest and implement. Data stewardship needs to be built into the initial requirements gathering for every project, and the cost of not doing so can open up a company to needless risk.

Residual Risk

Still, this doesn’t absolve a company from all risk. Web Browsers work by honoring something known as the “Same-origin policy” – any browser’s storage on your local system includes secrets identifying you to a website. The reason google.com can’t steal your access to Microsoft.com is solely because your web browser only allows the specific site that writes a value, to read it back later. This is what makes third-party JavaScript such a glaring problem.

By allowing it to run on your site, that party, and any party they implicitly trust, can read the authentication tokens your site or application stores. The JavaScript, by way of an HTTP POST request, can send that information anywhere it wants.

Tips of the Trade

While there is no silver bullet that protects web administrators from business risk, good website hygiene becomes even more important. Every common web-based attack can be a potential means of leaking data to unknown parties. Defense-in-depth and knowing how your organization mitigates possible attacks is critical for success.

For example, something called “CORS” (a technical control included in your markup allowing another domain to violate the same-origin policy) is crucial when trying to prevent inadvertent data leakage. Some well-meaning administrators, stumped by the same-origin policy allow access to the wildcard character (*), thereby leaving themselves exposed.

Another trick of the trade is preventing against “clickjacking” attacks. In this type of attack, a malicious actor uses iframes to present your content as if it were their own. By embedding your site, the attacker has full access to anything entered, and anything presented. It is considered a best practice to set the Content-Security-Policy:frame-ancestors header to none. This informs a client’s browser that the content is not supposed to be embedded elsewhere, protecting your users. To the average user, the best protection against this sort of attack is to make sure the URL in the top bar matches the site you’re expecting to visit. Don’t blindly trust links embedded in webpages or even on search engines.

Finally, one of the most powerful tools in limiting damage is good old-fashioned network segmentation. Back in the day, when servers were mostly physical, the DMZ was ubiquitous. Two firewalls, ideally from different vendors, and databases for applications living alongside the application instead of in a centralized manager were very common. While terrible for scalability, that paradigm did a great job of limiting the amount of data an attacker could glean during a data breach.

Now, many companies have moved towards centralized database server. “Having all your eggs in one basket” can be a perfectly safe thing to do, but savvy decision makers should look into encrypting sensitive fields in their databases (which, after the GDPR includes names, IP addresses, and email addresses) and choosing technologies wherever possible that authenticate users all the way to the database instead of letting the web application broker access with a highly privileged database account.





Source link