Risk Overview of GA
IVK, similar to other companies purchasing Google Analytics, faces the risk of failures through market changes and internal misuse. An example of a market change is the increasingly popular option to disable cookies on a web browser (cookies are the means of tracking GA heavily relies on). IVK could also experience risks on an internal level with examples being as simple as maintenance failures from legacy coding.
Cookies are text files stored in a web server that contain a name-value and retrievable information for web servers to use in the future (Mazerick, 2013). Image 1 shows and example of the process of an initial visiting user that has cookies enables. Image 2 shows an example of a returning user’s data from previous visits is transformed into recommendations for future actions. These updated cookies create conveniences such as shopping cart memory and the potential preferred videos generated on YouTube for returning users. IVK’s implementation of GA hinges greatly on customers enabling cookies so their actions can be traced. However, even the strongest of tracking mechanisms are under attack. The public is becoming aware of data exposure through canvas fingerprinting and cookie syncing (Kirk, 2014). Canvas fingerprinting extracts data, named fingerprints, from individual computers that can be identified and stored for future use. Individuals are also exposed and risk potential security breaches through cookie syncing which is the idea of companies merging data bases to combine databases on individuals. Those who choose to disable cookies in light of these market level issues will interrupt GA’s tracking and could cause use failures for GA at IVK.
On the internal side however, IVK may risk actual revenue loss if GA regularly maintained. For example, studies show legacy code errors have led to hundreds of thousands of dollars of lost revenue potential (Critchlow, 2010). In this case, ecommerce retailers failed to realize certain browsers alerted customers of potential security issues that were not actually threatening (Image 3). The security message alerted because an outdated piece of coding was used throughout the entire ecommerce website rather than having a different piece of coding for the secured transaction page. The fix took approximately 5 minutes and the firm saw direct revenue increases upwards of $150,000 (Image 4).
Therefore, the major risks IVK will face when implementing GA is the environment they are operating in and the way they are using GA. This will require frequent monitoring of how consumers views of cookies and ensuring security so they feel safe receiving loans online from IVK. Equally important, IVK will need to focus on how GA is changing year over year and ensure those changes are consistent with GA’s use on IVK’s website.
Image 1
Image 2
Image 3
Image 4
Privacy Concerns with Google Analytics
In order to understand privacy concerns for Google Analytics, one must first understand how the program uses cookies. According to Google’s privacy policy, GA users can use first party cookies. The aforementioned first party cookies allow GA to track user preferences with websites by sending a message to a website after using a browser (Oyhe, 2011). This allows GA to track information like language preferences for accessing a website and conversion rates for adopting or using aspects of a website (Types of Cookies Used by Google, n.d). GA has the ability to distinguish between the types of technology used to access it. Hence, the technology can track cookies via personal computers and mobile devices such as smart phones and tablets (Google Privacy Policy, 2015). In order to protect the privacy of sensitive information for customers, Google products don’t track information in sensitive categories, including race, religion, sexual orientation, or health (Google Privacy Policy, 2015). Thus, sensitive demographic information isn’t accessed through these cookies. However, GA does this without tracking personalized data about a user through the cookie (Types of Cookies Used by Google, n.d.). Additionally, the GA system for developing cookies allows the program to track an individual cookie for up to 2 years (Google Developers, 2015). Needless to say, this tracking method is not without its concerns for customers.
Despite the fact Google Analytics doesn’t record the person identification information, Google Analytics has been embroiled in controversy concerning the privacy. As referenced earlier, customers are increasingly wary of being tracked online by browsers and are choosing applications like Ghostery or using browser settings to delete cookies or prevent them from being tracked (Greiger, 2011). Customers increasingly rejecting the idea of being part of someone’s advertising experiment, and are disabling cookies through their browsers and technology.
On the other hand, tracking user use through cookies has been proscribed limits in certain parts of the world. In 2011, the European Union enacted the Privacy and Electronic Communications Regulations (PECR) or the “EU Cookie” law that makes setting cookies without legal consent in the 27 member EU nations illegal(Clifton, 2011). This has been implemented in various ways amongst member nations. The U.K. allows websites to inform users about cookies determine whether or not they are willing to be tracked (Schneider, 2014). The following infographic (figure 3) illustrates this policy. Germany has implemented the policy through the Telemedia Act, which allows internet users to decline participation on websites that store cookies or IP addresses (German Cookie Law,2015). Therefore, companies implementing GA internationally should acquaint themselves with local laws concerning cookies.
Figure 3 http://www.stateofdigital.com/remarketing-with-google-analytics-adwords/
GA Security Risk Assessment – Technical & Behavioral Perspective
Before implementing GA, it is important to understand the potential weaknesses that can compromise the security of an organization’s information assets. An organization must first recognize the potential entry points and the vulnerabilities that may exist in order to further improve security (Gallaugher, 2014). GA collects data simply through three different types of sources: the HTTP request of the user, browser & system information and first-party cookies (Google Developers, 2015). All these sources are executed through JavaScript via Google Analytics Tracking Code (GATC) (Google Developers, 2015). GA utilizes JavaScript through browsers enhancing data collection and enabling more functionalities on web pages. This may bring the users with cross-site scripting (XSS) vulnerabilities. Any hijacked JavaScript can be used to steal the cookie history information, users data, and may manipulate the Document Object Model (DOM) system of the page that user is on. By leveraging XSS, attackers may have abused JavaScript in many ways, including “keylogging, phishing and identity theft” (Acunetix, n.d.). However, the security risk associated with hijacked JavaScript is very unlikely. First, there has not been any evidence found of sites being hacked because they used GA. Also, it is nearly impossible to disable JavaScript on websites. Regardless what other third party analytics product that is being used, and if it requires linking the tracking script to webpages, all of which stem for the potential of script to be hijacked. If GA users are concerned with the potential issues relating to JavaScript, then they can use the alternative “async tracking system” that Google provided as another option to track users visit (Google Developers, 2015).
Image 6 http://heartbleed.com/
Another technical vulnerability that GA users might possibly be facing is from bugs like Heartbleed (see image 1). Heartbleed was first found in December 2011 and has been vulnerable to various OpenSSL versions (The Heartbleed Bug, 2014). OpenSSL is a type of software which is made freely available by engineers and often open for new modifications or redistribution (Gallaugher, 2014). It is an encryption protocol used to secure the internet (The Heartbleed Bug, 2014). Heartbleed is simply a result of human error in the encryption process. This allows possible cyber- crime attacks. The victims may have exposed their sensitive account information, such as passwords over the internet. There is also no way to detect such attacks (The Heartbleed Bug, 2014). Google uses OpenSSL encryption for their products (O’Connor, 2014). This leaves GA vulnerable to security risk. However, Google’s quick response in assessing new vulnerability and applying appropriate patches may lower the risk of cyberattacks. Mathew O’Connor (2014), a Google’s product manager, posted on Google’s online security blog, indicated in responding to Heatbleed discovered in the OpenSSL, new patches were applied on most of Google’s key products, which includes GA, on April 9, 2014. This is only two days after the official OpenSSL 1.0.1g released date (The Heartbleed Bug, 2014). Google encourages users to report suspicious threats so that they “fix software flaws before they are exploited” (O’Connor, 2014). Also, in effort to prevent future security breaches, in addition to regular updates, Google also pays bounty to “bug hunters” to search for potential security holes or bugs. Google will reward the programmer depending on the severity of the finding (Google, n.d.). Simply, IT security isn’t perfect and it is everyone’s responsibility to protect.
From a behavior perspective, GA users might be under the risk of cyberthreats. Security breach could happen when the Google employees share the user’s data information to others. GA users relies heavily on creditability and accountability of this third party web-analytic tool, which opens up the opportunity of one being a cyberthreat. Steven Prokesch (2014), a contributor for Harvard Business Review, wrote that organizations facing cyberattacks often from the help of insiders – “employees, contract workers, suppliers, distributors, and others who have legitimate access to an organization’s cyberassets.” Because Google categorized clients’ data as “confidential information,” a set of control and procedure will need to be followed if an employee is asking for access to client’s data (Google Analytics, n.d.). This definitely will lower the risk of the data being stolen or sold to rivals. In addition, Google’s data centers and its unique shared data infrastructure which makes it more difficult for hackers to steal customers’ information (Google Analytics, n.d.). On the other hand, if the data-sharing settings has been turned on, GA users actually may have a higher chance of getting a possible security attack if their password was stolen or misused. GA users are required to own a google analytic account. This account could be linked to other google accounts, such as Gmail. So, if the setting is off, only GA account is used. Also, if a GA user’s password was stolen, the hacker’s ability of getting the users’ overall valuable data is actually very limited. According to Lorrie Faith Cranor’s research on real passwords, users tend to use short and easy to remember passwords (Cranor, 2014). Therefore, this is important for the GA account administrators to have a stronger password and manage the data-sharing settings accordingly in order to avoid possible security attacks in future.
Acunetix. (n.d.). What is Cross-site Scripting and how can you fix it? Retrieved from https://www.acunetix.com/websitesecurity/cross-site-scripting/
Cranor, L. (2014, March). What’s wrong with your pa$$w0rd? TED. Retrieved from http://www.ted.com/talks/lorrie_faith_cranor_what_s_wrong_with_your_pa_w0rd?language=en
Critchlow, T. (2010, July 13). Using The Wrong Tracking Code Can Cost You $500k a Year. Retrieved November 5, 2015, from http://analytics.blogspot.com/2010/07/using-wrong-tracking-code-can-cost-you.html
Gallaugher, J. (2014). Information systems: A manager’s guide to harnessing technology (2.0). Washington, DC: Flat World Knowledge.
German Cookie Law (2015) Cookie Collective Retrieved November 03, 2015
Google. (August 19, 2015) Google Privacy Policy Retrieved November 03, 2015
Google. (n.d.). Program Rules – Application Security – Google. Retrieved from https://www.google.com/about/appsecurity/reward-program/
Google. (n.d.) Types of Cookies Used by Google Retrieved November 03, 2015
Google Analytics Help. (n.d.). Safeguarding your data. Retrieved from https://support.google.com/analytics#topic=3544906
Google Developers. (July 15, 2015) Google Analytics Usage on Websites Retrieved November 03, 2015
No comments:
Post a Comment