The Eternal Push and Pull: Striking a Balance between Endpoint Protection and Employee Privacy
At Bamboo we’re constantly aware of the push and pull nature between privacy and security, and often it comes to the fore in processes such as incident response or considerations around data lakes and operational data. In the last few weeks though, we’ve seen a great deal of discussion around Data Leak Prevention (DLP) and endpoint protection, and the clash it has against employee privacy – particularly when Bring Your Own Device (BYOD) is involved.
In particular, we are seeing challenges in terms of data visibility to administrative staff members when it comes to employees. And sure, there are allowances in privacy law for security measures, but how much is too much, and what can be done about it?
Note on language: When it comes to technical policies, such as the policy rules that are set within security platforms, I have named these “rules” instead of “policies”, so as not to confuse them with the physical policies that a business drafts as their internal regulations and governance.
Case 1: Employees using their work email address as a (very) personal mailbox.
Email protection is a necessity in every organization. It’s an ingress and egress point for loads of company and personal data. When certain types of information are included in an email, it gets flagged and raised with administrators, as was the case of an employee sending off a personal financial application from their company mailbox.
This personal application set off an alert which copied the entire email (including the attachment) that the user had sent to the security administrator. Information such as the individual’s salary information, SIN number, and bank statements were included. This exposed their data to the administrator and made for an uncomfortable and embarrassing situation for parties on both sides.
What to do:
In this case, on a regular basis, the company provides notice and reminds its employees that all mailboxes are subject to monitoring and protection, and various policies and agreements with the employees made it abundantly clear that they should not be using their mailboxes for personal use (such as this).
That said, after this incident, additional controls were put in place to limit what administrators were exposed to by tailoring alerts and preventing the full copy of the mail from being sent to administrators. The admin team could now investigate on a case-by-case basis, and only open the mail if needed, instead of being included immediately.
Case 2: URL monitoring for browsing history on company owned hardware and BYOD.
Monitoring the activities of your staff on their browsers and having a record of all sites they visit is a delicate balance to strike at the best of times. Logging online activities allows for loads of inferences about sensitive information such as political leaning, trade union membership, health information and others. On company hardware, it’s easier to justify this kind of monitoring (but still not wonderful), but on personal devices used by your staff, it becomes very difficult to justify.
What makes this tricky is that the security platforms available nudge you in the direction of enabling this monitoring for everyone without much explanation of the depth of it, and if you’re not actively watching what features you are turning on/off, you may find yourself monitoring more than you bargained for. When presented with a data subject access request, you will need to show these histories, and that could result in a lot of unhappy people if this is not clear and transparent.
What to do:
Firstly, have separate rules and groups for your BYOD users, and your users of company-owned devices. This allows you to have separate policies and govern what your (and your employees’) acceptable levels of monitoring are. A reasonable approach may be to passively monitor URLs on company-owned devices to refer back to them when warnings and alerts are raised, while BYOD simply receives a block for banned websites during working hours, without reporting on them. This puts protection on both sides with differing degrees of privacy, taking into account the personal nature of BYOD.
Case 3: Out of the box reporting functionality that reports more than necessary.
In addition to the protections that come “out of the box” in many solutions, there are also reports. Again, the providers of security platforms want you to use their features, so there are many bells and whistles trying to get you to enable the latest and greatest parts of the platform to gain more insight. Sure, from a purely security perspective, these insights are great to have, but they can get invasive and allow you to infer sensitive information when viewed with other information available. Some default reporting [SB1] in Microsoft’s security platform (Defender) that may be invasive when enabling monitoring features includes:
Volume of data transferred by a specific user.
Users accessing personal webmail.
Users with filesharing applications outside of company mandated ones.
Social network use.
Browsing activity.
Leaderboards of “top users” for different metrics.
Listing of all local software on the device (almost unavoidable in any configuration).
What to do:
Again, have separate rules for your BYOD and company-owned devices as a starting point, and work from there. Review (with the privacy team) the types of reporting you are looking to pull from your systems and the purpose for doing so, and enable or disable functionality accordingly. You want consider the reasons why you are reporting, and turn off the collection of information that does not suit your use case, acceptable risk levels, or cultural adoption and monitoring strategies.
Case 4: Shadow IT versus BYOD.
Shadow IT is a significant challenge in any organization and it is something that should be monitored– particularly on corporate devices. It is the proliferation of cloud services that are not sanctioned by the company, but users or teams could sign up for; most regularly cloud services of some kind. Monitoring this on company-owned devices is definitely a requirement and should certainly be done.
It becomes hazy, however, when you start to monitor a personal device and could add significant overhead on management from your security team for sifting out what is personal and what is company Shadow IT.
What to do:
You need to incorporate robust terms around Shadow IT for your BYOD policies, and in addition to these terms you need to have a defined vendor request process allowing for staff to request tools that they require in an easy way. This ties in to your vendor management process and speaks to having a risk based approach for assessment of vendors. You need to be able to streamline the onboarding of new tools, or roll-out of alternatives to effectively avoid Shadow IT creeping in on personal devices where you cannot automate monitoring.
In closing.
There’s no easy way strike the balance, but there are multiple safety nets and controls you can use within your space to ensure a fair and transparent process with your employees and security teams.
Policies like Employee Electronic Monitoring policies allow for transparency with staff so that they know what is monitored. Bring Your Own Device and Acceptable Use policies set the ground rules of what they should and shouldn’t do in the environment.
Following on from that, start with a clean slate of security protections, and consider which automated rules you’re going to apply to different groups of employees, and more importantly, identify WHY you are applying them. If you can justify the why and it’s within reason, you’ll have a much easier time going forward for both security administration and staff alike. From a privacy point of view, this can (and should) involve a privacy impact assessment of the solution to be implemented and how it will affect the rights of your employees, in conjunction with the needs and wants of your security team.
