Bring Your Own Disaster
Sep. 18th, 2022 11:40 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59After my last post, someone suggested that having employers be able to restrict keys to machines they control is a bad thing. So here's why I think Bring Your Own Device (BYOD) scenarios are bad not only for employers, but also for users.
There's obvious mutual appeal to having developers use their own hardware rather than rely on employer-provided hardware. The user gets to use hardware they're familiar with, and which matches their ergonomic desires. The employer gets to save on the money required to buy new hardware for the employee. From this perspective, there's a clear win-win outcome.
But once you start thinking about security, it gets more complicated. If I, as an employer, want to ensure that any systems that can access my resources meet a certain security baseline (eg, I don't want my developers using unpatched Windows ME), I need some of my own software installed on there. And that software doesn't magically go away when the user is doing their own thing. If a user lends their machine to their partner, is the partner fully informed about what level of access I have? Are they going to feel that their privacy has been violated if they find out afterwards?
But it's not just about monitoring. If an employee's machine is compromised and the compromise is detected, what happens next? If the employer owns the system then it's easy - you pick up the device for forensic analysis and give the employee a new machine to use while that's going on. If the employee owns the system, they're probably not going to be super enthusiastic about handing over a machine that also contains a bunch of their personal data. In much of the world the law is probably on their side, and even if it isn't then telling the employee that they have a choice between handing over their laptop or getting fired probably isn't going to end well.
But obviously this is all predicated on the idea that an employer needs visibility into what's happening on systems that have access to their systems, or which are used to develop code that they'll be deploying. And I think it's fair to say that not everyone needs that! But if you hold any sort of personal data (including passwords) for any external users, I really do think you need to protect against compromised employee machines, and that does mean having some degree of insight into what's happening on those machines. If you don't want to deal with the complicated consequences of allowing employees to use their own hardware, it's rational to ensure that only employer-owned hardware can be used.
But what about the employers that don't currently need that? If there's no plausible future where you'll host user data, or where you'll sell products to others who'll host user data, then sure! But if that might happen in future (even if it doesn't right now), what's your transition plan? How are you going to deal with employees who are happily using their personal systems right now? At what point are you going to buy new laptops for everyone? BYOD might work for you now, but will it always?
And if your employer insists on employees using their own hardware, those employees should ask what happens in the event of a security breach. Whose responsibility is it to ensure that hardware is kept up to date? Is there an expectation that security can insist on the hardware being handed over for investigation? What information about the employee's use of their own hardware is going to be logged, who has access to those logs, and how long are those logs going to be kept for? If those questions can't be answered in a reasonable way, it's a huge red flag. You shouldn't have to give up your privacy and (potentially) your hardware for a job.
Using technical mechanisms to ensure that employees only use employer-provided hardware is understandably icky, but it's something that allows employers to impose appropriate security policies without violating employee privacy.
There's obvious mutual appeal to having developers use their own hardware rather than rely on employer-provided hardware. The user gets to use hardware they're familiar with, and which matches their ergonomic desires. The employer gets to save on the money required to buy new hardware for the employee. From this perspective, there's a clear win-win outcome.
But once you start thinking about security, it gets more complicated. If I, as an employer, want to ensure that any systems that can access my resources meet a certain security baseline (eg, I don't want my developers using unpatched Windows ME), I need some of my own software installed on there. And that software doesn't magically go away when the user is doing their own thing. If a user lends their machine to their partner, is the partner fully informed about what level of access I have? Are they going to feel that their privacy has been violated if they find out afterwards?
But it's not just about monitoring. If an employee's machine is compromised and the compromise is detected, what happens next? If the employer owns the system then it's easy - you pick up the device for forensic analysis and give the employee a new machine to use while that's going on. If the employee owns the system, they're probably not going to be super enthusiastic about handing over a machine that also contains a bunch of their personal data. In much of the world the law is probably on their side, and even if it isn't then telling the employee that they have a choice between handing over their laptop or getting fired probably isn't going to end well.
But obviously this is all predicated on the idea that an employer needs visibility into what's happening on systems that have access to their systems, or which are used to develop code that they'll be deploying. And I think it's fair to say that not everyone needs that! But if you hold any sort of personal data (including passwords) for any external users, I really do think you need to protect against compromised employee machines, and that does mean having some degree of insight into what's happening on those machines. If you don't want to deal with the complicated consequences of allowing employees to use their own hardware, it's rational to ensure that only employer-owned hardware can be used.
But what about the employers that don't currently need that? If there's no plausible future where you'll host user data, or where you'll sell products to others who'll host user data, then sure! But if that might happen in future (even if it doesn't right now), what's your transition plan? How are you going to deal with employees who are happily using their personal systems right now? At what point are you going to buy new laptops for everyone? BYOD might work for you now, but will it always?
And if your employer insists on employees using their own hardware, those employees should ask what happens in the event of a security breach. Whose responsibility is it to ensure that hardware is kept up to date? Is there an expectation that security can insist on the hardware being handed over for investigation? What information about the employee's use of their own hardware is going to be logged, who has access to those logs, and how long are those logs going to be kept for? If those questions can't be answered in a reasonable way, it's a huge red flag. You shouldn't have to give up your privacy and (potentially) your hardware for a job.
Using technical mechanisms to ensure that employees only use employer-provided hardware is understandably icky, but it's something that allows employers to impose appropriate security policies without violating employee privacy.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
no subject
Date: 2022-09-19 09:44 am (UTC)no subject
Date: 2022-09-21 01:19 pm (UTC)Maintaining isolation of user data
Date: 2022-09-19 10:07 am (UTC)Does it suffice to make sure that, for instance, all code that gets deployed in production must go through a repository whose controls require review by a separate person, and then someone triggers an *automated* deploy to production systems which requires keys that only exist within the automation?
I've seen many writeups about fragments of architectures with controls like that. Do you know of *full* documentation of an architecture like that, that handles user data with appropriate care while applying the controls *between* developers and production, rather than on developer systems?
Re: Maintaining isolation of user data
Date: 2022-09-19 10:14 am (UTC)What about multiple parties?
Date: 2022-09-19 01:30 pm (UTC)The employer -> employee case naturally makes sense to have employer-provided hardware, but there are many cases where this is more complex or even falls down due to the different relationship between the "user" and the "service provider":
Using technical mechanisms to control key use in these cases is much more problematic, given the devices are likely not owned or controlled by the "service provider" (especially when the user is stuck between an OS which wants one thing, and a provider which wants another).
Re: What about multiple parties?
Date: 2022-09-19 02:15 pm (UTC)Yes. And the company pays for it one way or the other, either as a line item for the contractor's onboarding, or in the cost of the contract.
> Does every student/visitor/collaborator need to be provided their own device?
If the student/visitor/collaborator is doing something like working on personally identifiable information that belongs to the university, almost certainly. But in general I don't think that the school/student relationship usually matches the company/employee relationship Matthew is posting about.
For exam proctoring: they should be providing a secure chromebook or equivalent for the purpose instead of installing spyware on the student's own computer.
This also applies to mobile devices.
Date: 2022-09-19 02:08 pm (UTC)A previous company had that policy, but it doesn't seem to be common, and I have declined to set up company mail on my own device since then, because having your personal phone remote reset by the company tends to smart.
Re: This also applies to mobile devices.
Date: 2022-10-01 11:45 pm (UTC)Re: This also applies to mobile devices.
Date: 2022-10-02 12:08 am (UTC)That is, a company that is going to remote-reset a mobile device when terminating an employee is extremely unlikely to be take this employee-friendly approach.
Re: This also applies to mobile devices.
Date: 2022-10-02 12:41 am (UTC)Well, that is the point: The employer cannot remote-reset the devices used to access and/or store the e-mail because they do not even know which devices those are, let alone have any kind of access to them. And that is the way it should be.
Re: This also applies to mobile devices.
Date: 2022-10-02 01:00 am (UTC)Whether that's the way it should be or not is irrelevant. Any consistent IT policy that includes the former will be forced to prohibit the latter. If you want contacts outside or inside the company to send you personal mail, give them your personal email address.
Re: This also applies to mobile devices.
Date: 2022-10-02 01:16 am (UTC)Well, as an employee, you should never accept or sign such a policy. In fact, remote-resetting employee-owned devices should be illegal (and in Europe, it probably is). And there is no way I am going to install any kind of spyware with such a backdoor on my devices (mobile or not), nor am I going to use a device that has such a thing out of the box (my PinePhone sure does not).
Re: This also applies to mobile devices.
Date: 2022-10-02 08:14 am (UTC)Don't let the company own your mobile. But don't expect to be able to finagle a way around it.
no subject
Date: 2022-09-19 04:43 pm (UTC)Bring your own OS
Date: 2022-09-19 05:10 pm (UTC)no subject
Date: 2022-09-19 07:02 pm (UTC)1. Occasionally checking mail/calendar/chat (all browser-based) from a personal device
2. Using an existing personal-use device for employer work
3. Using a spare device, with no personal data, for employer work
The first situation isn't even called "BYOD" any more, although I think it used to be.
The second situation sounds like trouble, and I don't understand people who want that.
But I'm in the situation of wanting to do the third -- I have a spare Thinkpad that's in great shape but that I don't use at all; I'd much prefer to use that for work than for anything that IT is currently capable of procuring for me. (They have very limited vendor agreements.) There's no personal info on it at all, as it has been wiped, and it would be wiped again on termination. However, IT is allergic to this idea.
It's possible I'm just weird in being in this situation, but I have trouble believing there are *that* few software developers with spare computers and preferences about them.
no subject
Date: 2022-09-19 08:23 pm (UTC)Situation 2
Date: 2022-10-01 11:55 pm (UTC)Because they have one fixed desktop computer on their one desk on which they do everything, work or not?
Because they do work and non-work activities in rapid succession, or even (at least in some cases) simultaneously (e.g., quickly checking personal mail while their code is compiling (https://xkcd.com/303/))?
Because they have more than one employer and do not want to end up with 3+ computers?
There are plenty of situations in which having to switch to a different computer for work is unhelpful. (In case you wonder: some of them affect me personally, some do not.)
Re: Situation 2
Date: 2022-10-02 04:33 pm (UTC)You're picturing an employer sending someone a desktop computer that they will use for full-time working from home?
This one's actually plausible, although I usually think of people picking up their smartphone to do the personal stuff.
This sounds like a contractor, who would be working from their *own* computer... not one managed by the employers.
Re: Situation 2
Date: 2022-10-03 08:55 pm (UTC)No, I am talking about someone using their own desktop computer instead of a company-provided notebook (which is actually something I do).
See the original post:
And as for:
That is exactly my point. (But you do not have to be a contractor to want to use your own computer for work. I am not.)
The third is a bit risky.
Date: 2022-10-02 12:14 am (UTC)Re: The third is a bit risky.
Date: 2022-10-02 03:56 pm (UTC)Re: The third is a bit risky.
Date: 2022-10-02 05:53 pm (UTC)no subject
Date: 2022-09-19 08:03 pm (UTC)Assume compromise in either case
Date: 2022-09-20 04:45 pm (UTC)then create your mitigation strategies accordingly. With that approach, it doesn't
really matter if it's an uncontrolled device on the other side.
Re: Assume compromise in either case
Date: 2022-09-20 06:14 pm (UTC)no subject
Date: 2022-09-21 02:09 pm (UTC)If employer A detects a security problem somewhere on its network, is employer B notified? And what else happens: does the housemate who works for B suddenly lose access, because employer A has the physical device and is scanning it for malware? Is B going to get enough information to protect itself, or is Alice just told to bring her machine to IT, she'll get it back in a few days and is on vacation until then?
Similarly, is the simple fact that each company can demand physical access to the machine a security problem for the other?
Along similar lines, it's a lot easier to require each employee to have their own device rather than share with someone else who lives there, than to be sure nobody will give access to a visiting friend or relative who wants to check their email, or check in for their flight home, because people don't always think in computer security terms. We think of being able to trust people in terms of deliberate harm, or avoiding risks that we're aware of, but "I can trust my brother" can mean I'm sure he wouldn't steal from me, or otherwise try to harm me--not that he won't do something risky, or that could endanger me, without realizing it or because we have different levels of risk tolerance.
no subject
Date: 2022-09-21 06:33 pm (UTC)So guess what was required to fix a recurring problem? I'm certain there was an IP collision with our corporate network in both ip4 and ip6. I disabled ip6 on the laptop, but on the home router I had to switch some of them from 10.x.x.x space to 192.168.x.x instead. Some isps were configuring home routers in that larger "business" address space. Making this change always fixed the random outage issues that some people would experience inconsistently. I never had anyone already in 192.168.x.x space show the problem. In this case, "Business B" was the isp itself, and their standards interfered with our own.
no subject
Date: 2022-09-21 06:27 pm (UTC)no subject
Date: 2022-09-21 10:35 pm (UTC)Reasons I use only one device
Date: 2022-09-22 07:04 am (UTC)I totally agree with the downsides listed by the post as well as the different comments. However there are several reasons why I still stick with using one device only. I would be very interested in suggestions on how to avoid these problems or contain the downsides:
Using a separate device for each context does not scale. I am involved in several contexts: My main job, my side-job, a volunteer project, my home/family. Trying to separate data for all of these means I'd need 4 devices.
I really like working in the environment I am familiar with and have configured according to my personal preferences. Even for the simple case of Work/Private separation, I would need to maintain 2 identical base systems. Repeating each config and fixing each problem twice. I don't think this is a good use of my time.
My work is very flexible, so time-wise there is no hard separation between work and private. I regularly spend a few hours at home for work or a few hours at work for private/volunteer tasks. (e.g. because a meeting is scheduled in a slot that otherwise belongs to the "other" context). So separating devices would mean carrying two devices all the time.
easy solution
Date: 2022-09-24 11:24 pm (UTC)This device can be used with your device or optional with company PCs.
It has also the advantage of not carrying a laptop to your work/home and if you change your job, you can easily separate company data from private data.
Reply from the "someone" cited in the post
Date: 2022-10-01 11:28 pm (UTC)Obviously, I do not consider that acceptable at all, either. I also consider it unacceptable when proprietary game developers do that against cheating, and I consider it just as unacceptable when employers do it in the name of "security". I am not going to install this kind of spyware on my computer.
(By the way, that kind of "checking" spyware cannot even necessarily be relied on, because some of that spyware can be circumvented, e.g., the OpenConnect client can fake Cisco's "security check" software and make the server believe that you are running the expected Windows setup. And needless to say, I consider it a good thing that OpenConnect can do that. Though thankfully I do not need such hacks because my employer uses the FOSS
ocserv.)Here in Austria, since last year when a new home office law was passed, that is actually not allowed (at least for employees working from home), in the sense that employers are now disallowed from requiring employees to use their own hardware. The employers have to offer providing company-owned hardware for employees. But, at least as far as the government is concerned, the employees are not required to accept that offer. If both sides are happy with BYOD, the law does not prevent that.
At the company I work for, this has always been the policy: If you need a company notebook, you will get one, but if you prefer to use your own computer (or even a computer owned by a third party such as the university with which we cooperate), that is fine too. I actually use a desktop tower most of the time, not a notebook. (And both the desktop tower and the notebook are owned by me.)
Device separation
Date: 2023-01-08 09:45 am (UTC)Thinking about Android, where I have two profiles - Personal and Work. While my employer can monitor / reset / wipe Work profile, they have almost zero access to my Personal profile. Sounds like win-win for me and employer? The only restriction that company force is to have strong passwords on Android device itself. Over the weekend / holiday I have an option to "pause" work profile which in fact will temporarily disable all the communication between my Work profile and employer.
Second very common option is utilizing VDI. Where employee can use whatever equipment (and whatever OS installed). But in order to get access to corporate resources one need first to connect to the VDI (providing passwords, OTP/MFA, etc). In such scenario data is not leaked to personal equipment outside of VDI - any copy/paste functionality are usually tightly controlled. I know that utilizing VDI will not work for everyone.