Hacker News Reader

Comment by biztos | Hacker News Reader

I think this is the correct advice, but keep in mind that procuring the laptop might be a difficult thing for them to do bureaucratically. On the other hand, you renting a laptop and charging them for it, would be pretty simple, presumably your contract covers expenses and all you'd need is an OK from the manager.

I worked for a big company that had various spyware thingies installed on all the company laptops, but they let you use your personal mobile devices for work (including iPad which was pretty nice) -- and wanted you to install their preferred spyware on it. I didn't do that but I expected they would eventually tell me to do it or stop using my personal iPad.

It seems like now that it's technically feasible, big corporate IT managers want their spyware of choice running everywhere. Someday you will have an arm full of Apple Watches, one for each client. You should embrace this future and price it in.

View on HN

Arguably, the new laptop being difficult to procure is a feature, not a bug. It serves as a deterrent to installing that agent, if it's easier to just make an exception.

Or they reimburse the consultant when they procure their own dedicated laptop for the client's work.

And hey, when the gig is over you got a new laptop that just needs to be formatted and it's all yours!

At my agency we have a client that always ships us locked down laptops (healthcare space so understandable). Thing is this client, while very good at getting the laptops out to you, is horrible at actually getting them back and pretty much lets you keep them....I have 4 Macbook Pro's sitting on a shelf behind me, all from this client.

Are they all still locked to an MDM profile, if so while they're yours, at any point you could lose access to them and that sucks. There's a ton of laptops that have been up on Ebay that ended up having mdm. We bought a few on accident for our non-profit. Fortunately we were able to find the original owners and they were gracious to remove them. We were also lucky they hadn't been disabled. Thing is most people don't realize that when you restore / setup that laptop it will pull that profile regardless of how you wipe or clear it.

TLDR; Make sure MDM profiles are gone and the laptops are cleared before doing anything personal :D

woo... linux and windows don't have that, at least not windows yet. you never know.... they might make uefi behind a subscription making mdm thing over to windows/linux side

Used to work in Healthcare, we'd use Computrace which operated at the motherboard firmware level. It can remotely brick a device and also automatically manage installing additional payloads in Windows once an internet connection was formed.

Doesn't this put you in a position of potential liability, if, say, someone breaks into your home/agency, steals those 4 laptops, and leaks personal healthcare data off them?

Plus the 25% management fee on top of the price :-)

It also creates friction for the client, making it less likely that you get paid.

Wouldn't the source of the friction be them asking to install spyware on your personal machine?

There are multiple points of friction in this scenario. Their asking you to install spyware is friction for you, your asking them to buy a laptop is friction for them.

Charge them for laptop rental. As another poster said. If you have other clients you are betraying their trust by installing the spyware.

> You should embrace this future and price it in.

Should we though? what you and the parent outline is a most sensible way of accommodating it while minimising invasion of privacy, however I question the underlying reasoning, and therefore whether or not we should encourage it. What perceived gains are to be had beyond merely box checking for accreditations? and in those cases why is it part of those accreditations, what is the intended effect? I can think of a few but they are all flawed or attempting to enforce something impossible:

1. Preventing leaking code/IP (But if you can't trust them they could just as easily take a picture of the screen, capture the HDMI, copy the drive, even log their own keyboard... there are always side channels unless you physically control the environment).

2. Preventing them from doing something malicious... But if they are writing code for you and they are untrustworthy, isn't it already game over?

3. Bean counting, monitoring time spent at keyboard etc - which we all know is not an accurate metric of productivity for cognitive work.

4. Similarly to #1 and #2, unintentional breach or security issues, i.e you trust the person but not their device or their ability to secure their own device - In which case spyware seems wholly inadequate to cope with this situation, if you are serious about this, you should be controlling the hardware and OS (which lots of orgs with highly sensitive info do).

In all these cases spyware is futile. Am I missing something?

Enforcing/auditing sane security settings on the device.

Very much required for compliance, zero trust, protection of IP, and foundational to a reasonable security plan.

I think I added #4 after your comment. Which is essentially my response. It seems like a very weak measure, at the cost of privacy considering it's the worker's personal device... If our solution is to require separate devices anyway, then spyware seems like a waste of time, they should be providing secured hardware/OS.

On second thought, this _is_ the answer... they are making a compromise on security, it's an economic decision. Maybe it makes sense from a business perspective: check some boxes, get a bit of security (not much) for almost nothing - but as you can probably tell, I think it's both pretentious and disrespectful.

Yes, it's definitely a economic decision. They're going to run this type of software on their own fleet and want it on everything connecting to the network. If you're willing to run it on your own device that saves them the hardware cost.

That said, a lot of users _want_ to use their own devices (maybe they have better equipment, maybe it's less locked down, maybe they don't want duplicates). It's not sane for the business to allow a device that is more likely to be compromised and/or have poor security hygiene on the network.

I'm a fan of privacy but... At least on my team, we're definitely not spying on you, we're making sure you have a password, encryption, antivirus, and updates installed before you can connect to resources. It's shocking how many people don't have authentication enabled and run as root, if they have a choice, on their home system. That said - we could flip switches and do a lot more spying if it was mandated :/

Why don’t you write an opensource “agent” then, with no remote code execution capability? I doubt people would mind running some opensource bash script that hardens their devices.

Anything but this, and it’s clear you’re just evil.

The ship has totally sailed on whether it's a best practice to instrument machines employees use to conduct work, in the name of compliance and security. That's an utterly standard control, and unless you have a remarkably potent new argument against doing so, arguing that companies shouldn't do this sort of thing is kind of uninteresting. If anything, the prevailing sentiment (for better or worse, mostly worse) is that companies should be doing more of this, not less.

> procuring the laptop might be a difficult thing for them to do bureaucratically

Not if they are at the point where they need SOC2 cert, and where they install agents on their employees computers (and want to extend that to their suppliers).

My company is going through our SOC2 audit. We do not have such software and everyone is remote. I call BS as to the justification. This smells like a desire for corporate monitoring.

Definitely.

My point is that if/when you get to need a SOC2 certification, you put the resources towards this, and you definitely have the financial/org means to procure hardware to suppliers if required.

A lot of it comes down to the agency thats doing your audit. Its supposed to be a fair process, but just like PCI compliance, there's a huge amount of variability. Most auditing houses are going to be pushing 'solutions' to problems they find so they can milk the company out of more money. Its all snake oil.

SOC2 isn’t prescriptive. SOC2 is just a certification that you are following your own internal policies.

If the company made the mistake of creating a policy that they use this software as one of their controls, then the auditor will ding them if they don’t use it.

It’s an absurd system.

Reminds me when I was doing PCI compliance.

A PCI question asks if all outbound traffic is explicitly authorized. I took that to mean getting a list of all the IPs for the APIs of services we hit, and even constructed that entire list except for one, the payment processor itself.

The payment processor did not have any stable IPs, and could not give me a list. Their official solution was to have our policy be that we explicitly allow _all_ outbound traffic.

If such an option is allowed by PCI, what is even the point of making it a requirement?

The point, with a TON of these certifications/auditing/whatever, is usually "Are you aware of risk X/Y/Z and are you either mitigating it or accepting it?" In this case, you are now aware that all outbound traffic is allowed, and you are accepting that risk as a risk of doing business with that payment processor.

As Vendan said, the point is to get explicit acknowledgement that you're aware of something and have either mitigated it or accepted it. Which sounds kind of dumb, like ISO9000 certification, where the joke is "it doesn't matter how bad our processes are as long as we write them down!"

I made that joke to a VP once, and he brightened up and said "Yes! Exactly! Because until you're actually following explicit processes, you don't even know what you're doing wrong, in order to fix it!"

So I'm a lot less cynical about auditing certifications like this now.

> If such an option is allowed by PCI, what is even the point of making it a requirement?

The point of all those certifications (I took companies through the processes required for PCI, SOC2, and ISO27001 ) is security theater, a path in the back for the execs, the ability to have "I'm not to blame, I have this cert" in case of some shit happening, and the ability for sales to throw TLAs to prospects to show how Seriously(tm) the company takes security. Oh, and to check boxes to be able to transact with some large corporations.

There are plenty of stories of highly certified companies that were deeply penetrated and exposed, and all their security theater did not help.

It's an extremely low bar for cluefulness. There is space between the bar and the ground, but most serious going concerns clear it easily unless they screw up the compliance process and make things hard for themselves.

The problem isn't these low bars, but rather the market for services to "help" people clear them, and the widespread perception that the bars are higher than they actually are.

Yes and no. SOC2 doesn't say you need to install an agent, and may not be explicitly prescriptive about whether computers that have access to production data or systems need encrypted drives, screenlocks, etc. But a non-hack SOC2 auditor is going to expect you to have some reasonable policy and controls in that area. So yeah, the main thrust of SOC2 is "are you following your own internal policies", but the auditors are also expected to hold you to some minimal standards on your policies (or ask you to provide a good explanation why they shouldn't apply in your case). You definitely would't want to tie yourself to a particular agent in your policy, but the auditors will want to see some kind of policy and then require evidence for that, either from something like an agent or screenshots/etc.

More importantly: once you start using agents as a control, your auditor is very much going to expect you to be consistent about it; that's essentially the core thing SOC2 measures, is consistent enforcement of a documented policy. The whole point is not making random exceptions.

The same thing happened in the early days of ISO 9000

ISO9000: We make a piece of shit product, but it's a very well documented piece of shit product.

My company didn't need endpoint monitoring for SOC2, but does need it for ISO27001

You're mostly wrong here. First: many, many companies install agents as one of their SOC2-stated controls. More importantly: depending on where they are in their SOC2 process --- ie, if they've already had their Type 1 --- they may essentially be required to keep instrumenting machines: once you state a control, it's a mess to get rid of it. You can't just decide to make a random exception for a noisy contractor.

As others have said this area of SOC2 is often about "are you actually following the policies you've set" rather than "you have to do things this way" – most of our staff have company owned devices with MDM and an agent which mainly tracks installed applications versions, that Disk Encryption is turned on, and the OS patch level.

But there are a couple of our contractors that rejected this for exactly this reason (they had other clients). For one of them, we just bought him a laptop that he does all our work on (it cost less than 1 day of his time, so it was a no brainer), and the other, we realized we didn't have to as long as he did periodic (documented) reporting of screenshots of his OS version being up to date, Disk Encryption enabled, and screen saver settings are appropriate. And they legally attest that they make a best faith effort to delete any sensitive data off their laptops (if they ever download it).

We've talked to a couple of auditors and that seems to be sufficient and pragmatic as it accomplishes the same goal.

This.

Every company I’ve ever worked at, and that includes very large ones, will have legal, HR, and finance tell you at some point that “you must do X”. Sometimes X is no big deal and you do it. Sometimes it’s hard, and you ask the business to fund it or remove the requirement. Sometimes it’s nonsensical in your context and at that point the job becomes understanding why X is a requirement and how you can satisfy that requirement in some more pragmatic way.

At the end of the day, these functions are there to support the business.

I had an employer that, once or twice a year would send out mandatory agreements we were "required" to sign-- under threat of dismissal. (I don't think this was legal at all).

One day they sent out a particularly onerous "agreement" that said that we agreed not to use a phone while driving a car and doing so would be cause for termination etc.

I went down to HR and asked them if they were really trying to regulate what I was doing in my personal vehicle with my personal phone and they replied "No, its only meant for when you're in a company vehicle or using a company phone."

But the agreement itself clearly stated any phone any car.

The workaround I came up with was this-- a friend of mine and I swapped forms, and signed each others names. HR had their illegal, unenforceable agreement, and life moved on.

I got my "revenge" 6 months or so later. HR was frantically calling me for some reason-- I was stuck on the freeway as is our custom in Orange County. I ignored them for something like two hours, and explained that "I was stuck in traffic and as they were no doubt aware, we are prohibited by company policy from using our phones while operating a vehicle."

The HR gal was visibly pissed off, but to be fair, I could have been fired for answering that phone call.

You're in the US --- California, to boot. I'm not sure what you accomplished by making the agreement "unenforceable", as your employer does not need to secure your agreement to terminate you for virtually any reason. Discovering that you text and drive in your spare time, off hours, is something they'll likely have no trouble firing you for, unless you have an employee contract that somehow gives you tenure except for for-cause hiring (almost nobody has one of those).

Perhaps I didn't explain myself well.

I am not a lawyer, obviously, but what I meant was, threatening someone to sign a legal document can't be legal, even if its your employer.

Sure it can? All sorts of jobs are contingent on signing contracts (NDAs, acceptable use policies, background check authorizations). Why would you think it wouldn't be legal? The "threat" is simply to stop employing you, which your employed (in the US) has an almost absolute right to do anyways.

Where's the line then? What could they "force" me to sign and what couldn't they, in your opinion?

Also as a freelancer you may end up with a farm of a dozen single purpose laptops....

All rented out? Seems like an easy win on the PaaS market (and make enough profit on them).

Just remember to put some customized adhesives telling what laptop is rented to what customer.

Sure but I think most corporate spyware prevents things like mining software, cause get real thats all it will be rented for.

> I think this is the correct advice, but keep in mind that procuring the laptop might be a difficult thing for them to do bureaucratically

That's not OP's problem.

It is if OP loses work because of it.

> Someday you will have an arm full of Apple Watches, one for each client.

Noooo. Armfuls of watches are just for hilarious movies and such. It's not supposed to have a corporate elementttt. The cyberpunk vibes are too much with this.

Reply on news.ycombinator.com