Mobile Device Vulnerabilities |
|
This paper will examine the risks and possible remediation techniques for organizations deploying mobile applications to support critical business functions. This look at two dimensions of the problems, the first being the application, in this Microsoft O365 and the mobile platform strategy of bring your own device (BYOD). Each one in isolation has risks, but this paper will look at the intersection of both together.
|
Executive Summary
Many of us (Gen-Xer’s and Baby Boomers) likely remember the days of our Blackberry mobile device. This was generally company issued, secure, connected to our networks and of course the wonderful hard-key QWERTY keyboard. A lot has changed in the last five years; if one performs a Google search on “Blackberry failure”, as of this writing over 500,000 results are returned. There is no shortage on opinions to the reasons why Blackberry went from selling 50 million phones per year with an estimated worldwide share of 20% in 2012 to 0.0% in 2017 (Wehner, 2017).
One fact we all know is the introduction of the Apple iPhone in 2007. The iPhone was predominately for personal use, business users continued to use the blackberry with its proprietary OS and keyboard. However, as the personal user enjoyed the apps, touchscreen and intuitive UI from the iPhone, pressure was being applied to IT departments at the enterprise to extend the use of the preferred device for use at work. In October 2008, the first device using the open Android OS was introduced. This further amplified the pressure for IT departments to allow employees to use their own devices at work to perform mobile tasks like email, meetings, checking flights, reviewing documents, etc. BYOD has been characterized as a feature of the "consumer enterprise" in which enterprises blend with consumers. This is a role reversal in that businesses used to be the driving force behind consumer technology innovations and trends. The idea was initially rejected due to security concerns but more and more companies are now looking to incorporate BYOD policies, with 95% of respondents to a BYOD survey by Cisco saying they either already supported BYOD or were at least considering supporting it (Cisco, 2012).
Coincidentally, during the same time period of BYOD entering the enterprise, there was another major disruption to IT departments and specifically to their existing security practices. This being the migration from applications consumed on-premise to the cloud as a service; or Software-as-a-Service (SaaS). Several large business application companies have pioneered this move like Salesforce.com, but in the early stages this was limited to only a focused constituency in the enterprise (sales reps for e.g.). Unlike Salesforce.com, Microsoft Office products (Outlook, Excel, Word, etc) are used by nearly everyone in the company. Very recently Microsoft has announced they are now moving their entire suite to be consumed in the cloud, known as O365.
Between the shift to BYOD and SaaS, the enterprise will now have mass consumption of applications and data moving through a third party in the cloud in addition to their own networks. The threat vectors, attack surface and overall risk have completely changed and many organizations may not be adequately prepared to protect themselves.
Many of us (Gen-Xer’s and Baby Boomers) likely remember the days of our Blackberry mobile device. This was generally company issued, secure, connected to our networks and of course the wonderful hard-key QWERTY keyboard. A lot has changed in the last five years; if one performs a Google search on “Blackberry failure”, as of this writing over 500,000 results are returned. There is no shortage on opinions to the reasons why Blackberry went from selling 50 million phones per year with an estimated worldwide share of 20% in 2012 to 0.0% in 2017 (Wehner, 2017).
One fact we all know is the introduction of the Apple iPhone in 2007. The iPhone was predominately for personal use, business users continued to use the blackberry with its proprietary OS and keyboard. However, as the personal user enjoyed the apps, touchscreen and intuitive UI from the iPhone, pressure was being applied to IT departments at the enterprise to extend the use of the preferred device for use at work. In October 2008, the first device using the open Android OS was introduced. This further amplified the pressure for IT departments to allow employees to use their own devices at work to perform mobile tasks like email, meetings, checking flights, reviewing documents, etc. BYOD has been characterized as a feature of the "consumer enterprise" in which enterprises blend with consumers. This is a role reversal in that businesses used to be the driving force behind consumer technology innovations and trends. The idea was initially rejected due to security concerns but more and more companies are now looking to incorporate BYOD policies, with 95% of respondents to a BYOD survey by Cisco saying they either already supported BYOD or were at least considering supporting it (Cisco, 2012).
Coincidentally, during the same time period of BYOD entering the enterprise, there was another major disruption to IT departments and specifically to their existing security practices. This being the migration from applications consumed on-premise to the cloud as a service; or Software-as-a-Service (SaaS). Several large business application companies have pioneered this move like Salesforce.com, but in the early stages this was limited to only a focused constituency in the enterprise (sales reps for e.g.). Unlike Salesforce.com, Microsoft Office products (Outlook, Excel, Word, etc) are used by nearly everyone in the company. Very recently Microsoft has announced they are now moving their entire suite to be consumed in the cloud, known as O365.
Between the shift to BYOD and SaaS, the enterprise will now have mass consumption of applications and data moving through a third party in the cloud in addition to their own networks. The threat vectors, attack surface and overall risk have completely changed and many organizations may not be adequately prepared to protect themselves.
Employee Mobile Device Vulnerabilities and types of Attacks
The threat and attack vectors for mobile devices are largely composed of re-targeted versions of attacks aimed at other endpoint devices. These risks can be categorized into five areas (O’Leary, 2016).
Physical Access – The best intrusion detection systems and ant-malware software is completely useless to a bad guy who has physical access to the device. Experienced malicious actors can easily hack into a mobile device’s password and gain access to a host of company data, including the Virtual Private Network (VPN) which typically would grant access (based on user access controls) to corporate resources beyond what’s available on the client device like human resources data, financial and sales reports, New product information announcement and pricing tables. This could also provide the malicious actor to password keychains which would provide even greater access. Additionally, this could allow the bad guy the option to install a backdoor to gain access to all the systems at will. All would compromise the Confidentiality, Integrity and Authenticity of the security of the company.
Malicious code – For mobile devices, this is a new method of attack versus the malware that many of us are familiar within desktop environments. The term “malvertising” is used predominately in Android devices as they represent the majority of the mobile OS systems in use and it’s open, making it easy for malicious actors to develop malicious code. The attack vector uses the SMS (text msg) as a vehicle to spread a Trojan horse throughout the network. This is a social engineering attack, but very effective as most employees, particularly those who travel are in a hurry and it would be easy for at least one of them to click on an infected text message and activate the virus.
Device attacks - Attacks targeted at the device itself are similar to the PC attacks of the past. Browser-based attacks, buffer overflow exploitations and other attacks are possible. The short message service (SMS) and multimedia message service (MMS) offered on mobile devices afford additional avenues to hackers. Device attacks are typically designed to either gain control of the device and access data, or to attempt a distributed denial of service (DDoS).
Communication Interception - Wi-Fi-enabled smartphones are susceptible to the same attacks that affect other Wi-Fi-capable devices. The technology to hack into wireless networks is readily available, and much of it is accessible online, making Wi-Fi hacking and man-in-the-middle (MITM) attacks easy to perform. Cellular data transmission can also be intercepted and decrypted. Hackers can exploit weaknesses in these Wi-Fi and cellular data protocols to eavesdrop on data transmission, or to hijack users’ sessions for online services, including web-based email. For companies with workers who use free Wi-Fi hot spot services, the stakes are high. While losing a personal social networking login may be inconvenient, people logging on to enterprise systems may be giving hackers access to an entire corporate database (O’Leary, 2016).
Insider Threats
Mobile devices can also facilitate threats from employees and other insiders. Malicious insiders can use a smartphone to misuse or misappropriate data by downloading large amounts of corporate information to the device’s secure digital (SD) flash memory card, or by using the device to transmit data via email services to external accounts, circumventing even robust monitoring technologies such as data loss prevention (DLP). The downloading of applications can also lead to unintentional threats. Most people download applications from app stores and use mobile applications that can access enterprise assets without any idea of who developed the application, how good it is, or whether there is a threat vector through the application right back to the corporate network. The misuse of personal cloud services through mobile applications is another issue; when used to convey enterprise data, these applications can lead to data leaks that the organization remains entirely unaware of.
The threat and attack vectors for mobile devices are largely composed of re-targeted versions of attacks aimed at other endpoint devices. These risks can be categorized into five areas (O’Leary, 2016).
Physical Access – The best intrusion detection systems and ant-malware software is completely useless to a bad guy who has physical access to the device. Experienced malicious actors can easily hack into a mobile device’s password and gain access to a host of company data, including the Virtual Private Network (VPN) which typically would grant access (based on user access controls) to corporate resources beyond what’s available on the client device like human resources data, financial and sales reports, New product information announcement and pricing tables. This could also provide the malicious actor to password keychains which would provide even greater access. Additionally, this could allow the bad guy the option to install a backdoor to gain access to all the systems at will. All would compromise the Confidentiality, Integrity and Authenticity of the security of the company.
Malicious code – For mobile devices, this is a new method of attack versus the malware that many of us are familiar within desktop environments. The term “malvertising” is used predominately in Android devices as they represent the majority of the mobile OS systems in use and it’s open, making it easy for malicious actors to develop malicious code. The attack vector uses the SMS (text msg) as a vehicle to spread a Trojan horse throughout the network. This is a social engineering attack, but very effective as most employees, particularly those who travel are in a hurry and it would be easy for at least one of them to click on an infected text message and activate the virus.
Device attacks - Attacks targeted at the device itself are similar to the PC attacks of the past. Browser-based attacks, buffer overflow exploitations and other attacks are possible. The short message service (SMS) and multimedia message service (MMS) offered on mobile devices afford additional avenues to hackers. Device attacks are typically designed to either gain control of the device and access data, or to attempt a distributed denial of service (DDoS).
Communication Interception - Wi-Fi-enabled smartphones are susceptible to the same attacks that affect other Wi-Fi-capable devices. The technology to hack into wireless networks is readily available, and much of it is accessible online, making Wi-Fi hacking and man-in-the-middle (MITM) attacks easy to perform. Cellular data transmission can also be intercepted and decrypted. Hackers can exploit weaknesses in these Wi-Fi and cellular data protocols to eavesdrop on data transmission, or to hijack users’ sessions for online services, including web-based email. For companies with workers who use free Wi-Fi hot spot services, the stakes are high. While losing a personal social networking login may be inconvenient, people logging on to enterprise systems may be giving hackers access to an entire corporate database (O’Leary, 2016).
Insider Threats
Mobile devices can also facilitate threats from employees and other insiders. Malicious insiders can use a smartphone to misuse or misappropriate data by downloading large amounts of corporate information to the device’s secure digital (SD) flash memory card, or by using the device to transmit data via email services to external accounts, circumventing even robust monitoring technologies such as data loss prevention (DLP). The downloading of applications can also lead to unintentional threats. Most people download applications from app stores and use mobile applications that can access enterprise assets without any idea of who developed the application, how good it is, or whether there is a threat vector through the application right back to the corporate network. The misuse of personal cloud services through mobile applications is another issue; when used to convey enterprise data, these applications can lead to data leaks that the organization remains entirely unaware of.
Types of Attacks on the Cloud (O365)
The previous section examined several vulnerabilities and types of attacks for employee mobile devices, but what about the applications? And specifically applications that are hosted by a third party? Are these safe and if not, what types of vulnerabilities and attacks exist?
The following is a detailed example of a cross site scripting (XSS) vulnerability that was discovered while secure testing O365 before release to the employees at this firm. In this example, the tester noted that this was a new vulnerability in wave 15, and was not in Wave 14. If it was in Wave 14, they would have discovered it then. The point here, multi-tenant cloud environments are updated by the software vendor and can easily persist a vulnerability to every one of their subscribers – simultaneously. By contrast, this is less likely to happen in an on-premise environment, as each customer of the software has complete control over the testing and release of new versions published by the vendor.
The following was provided by a tester and is referenced from his blog (Byrne, 2014). The Office 365 web portal is just like any other web application and even uses the jQuery library. This made it relatively easy to craft an XSS string that loaded a JavaScript file from a remote web server and execute its contents.
By default, a normal “non-administrative” user can change their own Display Name within Outlook Web Access, the Office 365 webmail application.
The previous section examined several vulnerabilities and types of attacks for employee mobile devices, but what about the applications? And specifically applications that are hosted by a third party? Are these safe and if not, what types of vulnerabilities and attacks exist?
The following is a detailed example of a cross site scripting (XSS) vulnerability that was discovered while secure testing O365 before release to the employees at this firm. In this example, the tester noted that this was a new vulnerability in wave 15, and was not in Wave 14. If it was in Wave 14, they would have discovered it then. The point here, multi-tenant cloud environments are updated by the software vendor and can easily persist a vulnerability to every one of their subscribers – simultaneously. By contrast, this is less likely to happen in an on-premise environment, as each customer of the software has complete control over the testing and release of new versions published by the vendor.
The following was provided by a tester and is referenced from his blog (Byrne, 2014). The Office 365 web portal is just like any other web application and even uses the jQuery library. This made it relatively easy to craft an XSS string that loaded a JavaScript file from a remote web server and execute its contents.
By default, a normal “non-administrative” user can change their own Display Name within Outlook Web Access, the Office 365 webmail application.
The attacker logs in to webmail as a standard user and replaced his display name with the following string of characters.
The jQuery getScript function which loads the malicious JavaScript file and executes a function called c. In this example, the file is from the local machine, but it could just as easily be hosted on any web server anywhere in the world. Now that the display name contains the payload, the next steps is just to wait for an Administrator to log into the web portal to do some Business As Usual user administration. The Administrator doesn’t have to click any links for the payload to be executed, they merely have to load up the user administration page. Most Office 365 user administration is done via this portal, so it will not take too long before an Administrator logs in.
Admin Users Management showing Payload
The first component, loaded as function c, creates a new Global Administrator user within the company’s Office 365 environment. In this example the user is called “Hacker Admin”, but it could just as easily called something a little less obvious and would unlikely be detected in the Active Directory of a company with 10,000 employees.
The function appends an iFrame which is zero pixels wide and zero pixels high to the Office 365 administration web page. It is effectively invisible to the Administrator whose account is being attacked. Inside this iFrame we load up the Create User page and use jQuery to fill in all the form fields, select the type of Administrative account we wish and request that the initial password be sent to my email address.
Within seconds of this function being executed, the attacker receives an automated email from Office 365 telling me the username and password of my newly created administrator account. He can now log in to Office 365 using this account and run amok. The second part of the tester’s payload, loads as function d, basically covers the attacker’s tracks. It loads another zero by zero pixel iFrame but instead modifies the user account to change the display name back to its original value. By the time the administrator sees the XSS payload, it’s too late and it has already been executed. If the administrator refreshes the administration page or clicks on the user account to investigate further, the display name will appear normally. Most Windows Administrators would put it down to “internet gremlins” and pretend they didn’t see it.
It is important to highlight this example as it shows that a cloud based application from a prominent vendor is still vulnerable to attacks and as mentioned earlier, the attack surface is significantly larger than on-premise due to the fact that it’s multi-tenant environment.
The first component, loaded as function c, creates a new Global Administrator user within the company’s Office 365 environment. In this example the user is called “Hacker Admin”, but it could just as easily called something a little less obvious and would unlikely be detected in the Active Directory of a company with 10,000 employees.
The function appends an iFrame which is zero pixels wide and zero pixels high to the Office 365 administration web page. It is effectively invisible to the Administrator whose account is being attacked. Inside this iFrame we load up the Create User page and use jQuery to fill in all the form fields, select the type of Administrative account we wish and request that the initial password be sent to my email address.
Within seconds of this function being executed, the attacker receives an automated email from Office 365 telling me the username and password of my newly created administrator account. He can now log in to Office 365 using this account and run amok. The second part of the tester’s payload, loads as function d, basically covers the attacker’s tracks. It loads another zero by zero pixel iFrame but instead modifies the user account to change the display name back to its original value. By the time the administrator sees the XSS payload, it’s too late and it has already been executed. If the administrator refreshes the administration page or clicks on the user account to investigate further, the display name will appear normally. Most Windows Administrators would put it down to “internet gremlins” and pretend they didn’t see it.
It is important to highlight this example as it shows that a cloud based application from a prominent vendor is still vulnerable to attacks and as mentioned earlier, the attack surface is significantly larger than on-premise due to the fact that it’s multi-tenant environment.
Implications to the Employer Network
Many mobile devices, particularly those that are personally owned (BYOD), are not necessarily trustworthy. Current mobile devices lack the root of trust features that are increasingly built into laptops and other types of hosts. There is also frequent jailbreaking and rooting of mobile devices, which means that the built-in restrictions on security, operating system use, and so on have been bypassed. Organizations should assume that all phones are un-trusted unless the organization has properly secured them before user access is granted and monitors them continuously while in use with enterprise applications or data. Traditionally an employee had a single desktop PC or laptop on the network and probably an IP desk phone. If the employee called IT for support, it was likely straightforward to locate that user’s device on the network and troubleshoot the issue.
With BYOD adoption, each employee is likely to have three, four, or more devices connected to the network simultaneously. Many of the devices will have multiple modes, able to transition from wired Ethernet to Wi-Fi to 3G/4G mobile networks, moving in and out of these different connectivity modes during a session. It is critical for IT to have tools that provide visibility of all the devices on the corporate network and beyond (Keyes, 2014).
Techniques and Recommendations to Mitigate the Attack Vectors
Given the inherent risk of both BYOD and SaaS offerings, how should companies protect their data and ensure confidentiality, integrity and authentication in this new environment? There are several possible mitigation strategies related to the use of un-trusted mobile devices. In this section two classes of recommendations are explored: policy based and technical. For policy based recommendations, one option is to restrict or prohibit the use of BYOD devices, thus favoring organization-issued devices.
Another effective technique is to fully secure each organization-issued phone before allowing it to be used; this gets the phone in as trusted a state as possible when initially deployed, and deviations from this secure state can be monitored and addressed. There are also broad technical solutions for achieving the degrees of trust, such as running the organization's software in a secure, isolated sandbox on the phone, or using device integrity scanning applications.
Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and personally owned mobile devices by enterprise users. This section provides an overview of the current state of these technologies, focusing on the technologies' components, architectures, and capabilities. Below is a diagram that illustrates a typical architecture used to support BYOD and mobile devices used in the enterprise.
Figure 1 – Mobility Security Architecture (Presidio, 2017)
Many mobile devices, particularly those that are personally owned (BYOD), are not necessarily trustworthy. Current mobile devices lack the root of trust features that are increasingly built into laptops and other types of hosts. There is also frequent jailbreaking and rooting of mobile devices, which means that the built-in restrictions on security, operating system use, and so on have been bypassed. Organizations should assume that all phones are un-trusted unless the organization has properly secured them before user access is granted and monitors them continuously while in use with enterprise applications or data. Traditionally an employee had a single desktop PC or laptop on the network and probably an IP desk phone. If the employee called IT for support, it was likely straightforward to locate that user’s device on the network and troubleshoot the issue.
With BYOD adoption, each employee is likely to have three, four, or more devices connected to the network simultaneously. Many of the devices will have multiple modes, able to transition from wired Ethernet to Wi-Fi to 3G/4G mobile networks, moving in and out of these different connectivity modes during a session. It is critical for IT to have tools that provide visibility of all the devices on the corporate network and beyond (Keyes, 2014).
Techniques and Recommendations to Mitigate the Attack Vectors
Given the inherent risk of both BYOD and SaaS offerings, how should companies protect their data and ensure confidentiality, integrity and authentication in this new environment? There are several possible mitigation strategies related to the use of un-trusted mobile devices. In this section two classes of recommendations are explored: policy based and technical. For policy based recommendations, one option is to restrict or prohibit the use of BYOD devices, thus favoring organization-issued devices.
Another effective technique is to fully secure each organization-issued phone before allowing it to be used; this gets the phone in as trusted a state as possible when initially deployed, and deviations from this secure state can be monitored and addressed. There are also broad technical solutions for achieving the degrees of trust, such as running the organization's software in a secure, isolated sandbox on the phone, or using device integrity scanning applications.
Centralized mobile device management technologies are a growing solution for controlling the use of both organization-issued and personally owned mobile devices by enterprise users. This section provides an overview of the current state of these technologies, focusing on the technologies' components, architectures, and capabilities. Below is a diagram that illustrates a typical architecture used to support BYOD and mobile devices used in the enterprise.
Figure 1 – Mobility Security Architecture (Presidio, 2017)
Security best practice within corporate environments to manage mobile devices is the deployment of a Mobile Device Management (MDM) system. These systems are used within the corporate environment to administer the devices and some of the typical functionality include:
MDM systems typically involve an agent on the mobile devices, a server component used by administrative personnel within the enterprise enclave, and an intermediary service operated by the platform vendor. The on-device agent may be a hidden part of the mobile OS itself, or it may take the form of a 3rd party app distributed through online app repositories which is permitted to conduct its management activities. Highlighted a few of the key capabilities of MDM capabilities.
Concluding Remarks
Ideally, the enterprise would use a combination of techniques to mitigate overall risk of BYOD and SaaS. This would include technologies like MDM solutions, policies and extensive testing of both the BYOD application releases as well as releases of O365. Taking this layered approach and not relying on a single method will likely reduce the overall security risk of BYOD and SaaS.
- Over the air distribution of applications
- Data and configuration settings (all devices)
- Bring Your Own Device (BYOD) support
MDM systems typically involve an agent on the mobile devices, a server component used by administrative personnel within the enterprise enclave, and an intermediary service operated by the platform vendor. The on-device agent may be a hidden part of the mobile OS itself, or it may take the form of a 3rd party app distributed through online app repositories which is permitted to conduct its management activities. Highlighted a few of the key capabilities of MDM capabilities.
- Data-at-Rest Protection - Mobile device platforms offer a passcode lock feature, which is used to prevent unauthorized access to the device and also to generate a key to encrypt data stored on it, guarding against improper disclosure of confidential information if the device is lost or stolen.
- Application Policies - MDM systems allow administrators to create policies that govern which apps are installed on the managed devices. Depending on the features of the MDM system and the underlying OS, a variety of policies can be supported.
- Remote Wipe - MDM systems also provides the ability for administrators to remotely erase a device. This is another countermeasure against the risk of sensitive data being improperly disclosed, but its effectiveness depends on the device being accessible via the network after it is lost. The time the device is known to have been lost to the time the user reports it is crucial as an adversary can compromise the device in short order by disabling the remote wipe feature.
- Detection of User-initiated Platform Modification - MDM products can perform limited inspections of the underlying mobile OS to detect the artifacts of user‑installed “jailbreak” or “root” tools. Since MDM agents typically run with limited privileges, they stand little chance of detecting sophisticated malicious software, but they can sometimes detect user misbehavior that significantly weakens the mobile device’s security posture.
- Wi-Fi and Cellular Network Restrictions - In addition to using a VPN, preventing a device from connecting to insecure networks is another means of protecting sensitive network communications. Some mobile OS may allow MDM policy to restrict which Wi-Fi networks, or which Access Point Names for cellular networks, a device can connect to. For enterprise‑controlled devices, the ability to specify a whitelist for Wi-Fi networks remains highly desirable, despite potential incompatibility with the BYOD scenario.
Concluding Remarks
Ideally, the enterprise would use a combination of techniques to mitigate overall risk of BYOD and SaaS. This would include technologies like MDM solutions, policies and extensive testing of both the BYOD application releases as well as releases of O365. Taking this layered approach and not relying on a single method will likely reduce the overall security risk of BYOD and SaaS.
References
Byrne, A. (2014, January 15). The Office 365 blog for IT pros in the know. Retrieved April 09,
2017, from https://www.cogmotive.com/blog/office-365-tips/vulnerability-in-office-365-allows-unauthorised-administrator-access
Cisco Bring Your Own Device (BYOD) CVD Important
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/BYOD_Design_Guide.html. (2014, April 21). Retrieved April 09, 2017, from http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/byoddg.html
Cisco Study: IT Saying Yes To BYOD. (2012, May 16). Retrieved April 09, 2017, from
https://newsroom.cisco.com/press-release-content?articleId=854754
Ellis, L. (2012). BYOD: From company-issued to employee owned devices. Telecom, Media &
High Tech Extranet, 20, 3-5. Retrieved April 9, 2017.
Keyes, J. (2014). BYOD: Mobile Devices Threats and Vulnerabilities. Retrieved April 09, 2017,
from http://www.ittoday.info/ITPerformanceImprovement/Articles/2014-07Keyes2.html
O'Leary, D. (2016, June 3). Mobile Device Security in the Workplace: 5 Key Risks and a Surprising
Challenge. Retrieved April 09, 2017, from http://focus.forsythe.com/articles/55/Mobile-Device-Security-in-the-Workplace-5-Key-Risks-and-a-Surprising-Challenge
Wehner, M. (2017, February 15). RIP: BlackBerry’s worldwide smartphone market share hits
0%. Retrieved April 09, 2017, from http://bgr.com/2017/02/15/is-blackberry-dead-market-share-2017/
Byrne, A. (2014, January 15). The Office 365 blog for IT pros in the know. Retrieved April 09,
2017, from https://www.cogmotive.com/blog/office-365-tips/vulnerability-in-office-365-allows-unauthorised-administrator-access
Cisco Bring Your Own Device (BYOD) CVD Important
http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/BYOD_Design_Guide.html. (2014, April 21). Retrieved April 09, 2017, from http://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Borderless_Networks/Unified_Access/byoddg.html
Cisco Study: IT Saying Yes To BYOD. (2012, May 16). Retrieved April 09, 2017, from
https://newsroom.cisco.com/press-release-content?articleId=854754
Ellis, L. (2012). BYOD: From company-issued to employee owned devices. Telecom, Media &
High Tech Extranet, 20, 3-5. Retrieved April 9, 2017.
Keyes, J. (2014). BYOD: Mobile Devices Threats and Vulnerabilities. Retrieved April 09, 2017,
from http://www.ittoday.info/ITPerformanceImprovement/Articles/2014-07Keyes2.html
O'Leary, D. (2016, June 3). Mobile Device Security in the Workplace: 5 Key Risks and a Surprising
Challenge. Retrieved April 09, 2017, from http://focus.forsythe.com/articles/55/Mobile-Device-Security-in-the-Workplace-5-Key-Risks-and-a-Surprising-Challenge
Wehner, M. (2017, February 15). RIP: BlackBerry’s worldwide smartphone market share hits
0%. Retrieved April 09, 2017, from http://bgr.com/2017/02/15/is-blackberry-dead-market-share-2017/