Post AWl6bAO2cPXMJ5eVmq by mjg59@nondeterministic.computer
(DIR) More posts by mjg59@nondeterministic.computer
(DIR) Post #AWkyhzcwDpUZKWMemm by mjg59@nondeterministic.computer
2023-06-16T18:05:24Z
0 likes, 0 repeats
Hot take: your desire to run your choice of OS on your work laptop does not trump my desire to ensure the safety of data belonging to our users
(DIR) Post #AWkypVsIiwfbN78VQe by mjg59@nondeterministic.computer
2023-06-16T18:07:06Z
0 likes, 0 repeats
Making sure that code is developed on and managed from machines where we have reasonable confidence about the security posture is Good, Actually
(DIR) Post #AWkz7x8o5U1X9IeKLQ by mjg59@nondeterministic.computer
2023-06-16T18:09:42Z
0 likes, 0 repeats
@littlefox if your employer can't support an OS that allows you to work effectively then it's time to find another employer, just as in any other case where employer policies interfere with your ability to do work
(DIR) Post #AWkzJ0AbANTJjDkvjs by gregersn@snabelen.no
2023-06-16T18:12:04Z
0 likes, 0 repeats
@mjg59 Question: Do you here mean data as in the code being developed, or is it a matter of the data the code will be handling?
(DIR) Post #AWkzRJcOk2iGMZiu4O by mjg59@nondeterministic.computer
2023-06-16T18:12:49Z
0 likes, 0 repeats
@littlefox if the default is just to allow anything then you end up with someone insisting on Windows XP and then their prod creds getting stolen and now you're going to have a bad day
(DIR) Post #AWkzRP8UEALrTXm6HQ by mjg59@nondeterministic.computer
2023-06-16T18:13:45Z
0 likes, 0 repeats
@littlefox And if instead you want IT to support managing an additional range of special-cased OSes then you may improve some developer efficiency but at a significant cost to IT and security efficiency
(DIR) Post #AWkzjFb6QiPL6ZfZR2 by mjg59@nondeterministic.computer
2023-06-16T18:14:59Z
0 likes, 0 repeats
@gregersn I personally prioritise the data it's consuming over the code itself (I'm basically fine with a company burning, but not fine with user data leaking)
(DIR) Post #AWl0E4cFJDny1Vty1w by tschuy@towns.gay
2023-06-16T18:22:18Z
0 likes, 0 repeats
@mjg59 @littlefox also, I I don't know all the tooling out there, but when I was doing infra at my last job I saw what the tools IT was using on Mac and Windows offered on Linux and I can say with full certainty that allowing me to use Linux was allowing me to get away with a vastly inferior level of mandated security. There simply isn't the security ecosystem out there that there is for more common OSes.
(DIR) Post #AWl0TkzE3fjRmG82nQ by TalesFromTheArmchair@hachyderm.io
2023-06-16T18:25:16Z
0 likes, 0 repeats
@mjg59 @littlefox Which is usually the right answer, though. Surely the workflow should be "work out what OS your developers need in order to be effective, then hire IT people capable of supporting that OS", and not "work out what OS your existing IT people are capable of supporting, then tell your developers to use it"?
(DIR) Post #AWl0dL6BACEqNpwz6O by mjg59@nondeterministic.computer
2023-06-16T18:26:35Z
0 likes, 0 repeats
@littlefox I'm enthusiastic about the goal being to find a way that lets developers work effectively without compromising on security (there's no point in security if nobody can do their job!), but the solution can't be for developers to assert they have the right to choose an arbitrary os
(DIR) Post #AWl0n2LXjqdF7WlEzQ by mjg59@nondeterministic.computer
2023-06-16T18:28:29Z
0 likes, 0 repeats
@TalesFromTheArmchair @littlefox If I have 15 different developers wanting to run 15 different BSD varients, the answer isn't to hire enough IT staff to manage 15 different BSD varients
(DIR) Post #AWl0ymvAunhOkr1ybI by gregersn@snabelen.no
2023-06-16T18:30:41Z
0 likes, 0 repeats
@mjg59 Oh, yeah, I agree. My question was related more to the fact that in good development practice, I would think that most developers really shouldn't have access to the actual user data to begin with. At least not from their regular workstations. And the code that will be consuming the data later needs to be reviewed before being deployed. And with that I would think that for most of the developers, if the workstation is an open door, it should not affect user data.
(DIR) Post #AWl1Ds560qCB6NrbNI by mjg59@nondeterministic.computer
2023-06-16T18:33:56Z
0 likes, 0 repeats
@gregersn human review generally assumes good intent. I have no faith that reviewers who don't have an *extremely* strong security background would stand any chance of spotting a sufficiently subtle back door
(DIR) Post #AWl1XXI11bq2PSHdFg by keithp@fosstodon.org
2023-06-16T18:37:15Z
0 likes, 0 repeats
@mjg59 But, people in charge of security are never responsible for delays introduced by security leading to people routing around it to hit schedules.Enforcing security with threats of dire consequences puts people in an unwinnable situation -- either get fired for security violations or get fired for failing to meet deliverables.
(DIR) Post #AWl1lJ1uq4OMEpJpiq by gregersn@snabelen.no
2023-06-16T18:37:55Z
0 likes, 0 repeats
@mjg59 I see, that's interesting. I must admit that I do not have any security background, so I would not know how something like a backdoor could be subtle. But I do review my own code as it is in a MR/PR, and I hope and believe I would have picked up if it had parts I didn't recognize. Just as an assurance, I do not work with code that touches user data.
(DIR) Post #AWl220Sz6u1VaUwZ6m by mjg59@nondeterministic.computer
2023-06-16T18:42:28Z
0 likes, 0 repeats
@keithp yeah "Security says no" is a toxic (and common) scenario, and all restrictions need to exist for transparent and justifiable reasons, and shouldn't be imposed without discussion with everyone affected. But the flip side of that is that time taken to work with security in finding solutions needs to be factored into project planning - if company culture doesn't allow this, the culture is broken
(DIR) Post #AWl2BXdj8smJ4xVzP6 by mjg59@nondeterministic.computer
2023-06-16T18:43:49Z
0 likes, 0 repeats
@keithp (and I prefer solutions where it's simply impossible to do the insecure thing, so users don't have to worry about violating policies)
(DIR) Post #AWl2VCMrwMbMtg0Ero by keithp@fosstodon.org
2023-06-16T18:48:04Z
0 likes, 0 repeats
@mjg59 But security isn't ever accountable for product schedules, so "time to work with security" is an unbounded entry on any product schedule. Far easier to just "encourage" people to route around the blockage. There's always a way to do things insecurely that will be faster than the right way.
(DIR) Post #AWl2fdDKyuPh3TWGKu by ozdreaming@infosec.exchange
2023-06-16T18:48:53Z
0 likes, 0 repeats
@mjg59 @littlefox I know you're referring to software development settings. Other workplaces present different challenges. For me (working in healthcare and primary education settings, with a distant background in corporate infosec), it's common to feel that I'm better able to protect sensitive data than my employer, whose IT systems are often overseen by an overworked operations manager who's struggling to keep the lights and HVAC running, as well as manage a coterie of aging servers and desktops. But except when invited, I rarely deviate from the work systems I'm given, since I don't want the liability I'd assume in going my own way, even if I'd be more efficient (and even if my employer wouldn't care). The employer "owns" their policies and their consequences.
(DIR) Post #AWl3qSVXEChgzNl32W by mjg59@nondeterministic.computer
2023-06-16T19:02:56Z
0 likes, 0 repeats
@keithp and development is rarely accountable for the risks associated with compromise of user data, even in situations where that potentially leads to actual dead people and existential threat for the company. If developers are encouraged to work around security then company culture is fucked and needs fixing
(DIR) Post #AWl40eXrKO5PDbhpPE by coldclimate@hachyderm.io
2023-06-16T19:03:09Z
0 likes, 0 repeats
@mjg59 strong agree
(DIR) Post #AWl4pgpIbc1v3wCQrY by bea@infosec.exchange
2023-06-16T19:14:08Z
0 likes, 0 repeats
@mjg59 good luck with this fight. You have my sympathies.
(DIR) Post #AWl65exxOFEXsdQbU8 by valpackett@blahaj.zone
2023-06-16T19:26:23.314Z
0 likes, 0 repeats
@mjg59@nondeterministic.computer hot take: put the user data back on the users' own storage, return to monke, make good old actual software instead of services
(DIR) Post #AWl65fiObaNeCf9grw by mjg59@nondeterministic.computer
2023-06-16T19:28:13Z
0 likes, 0 repeats
@valpackett not sure that asking users to take responsibility for the security of all their sensitive material is a net improvement
(DIR) Post #AWl6b88111WtIo8gWu by valpackett@blahaj.zone
2023-06-16T19:30:26.134Z
0 likes, 0 repeats
@mjg59@nondeterministic.computer but it's so great from the "blast radius" point of view isn't it? breaking in to a client device is an attack against one person, breaking in to a server is an attack against millions at once, poof, everyone is fucked in an instant – that's way too scary!
(DIR) Post #AWl6bAO2cPXMJ5eVmq by mjg59@nondeterministic.computer
2023-06-16T19:33:51Z
0 likes, 0 repeats
@valpackett but it's not breaking into one client device, because nobody wants email that's only accessible from one device. And nobody wants to maintain a server themselves, so it's some sort of appliance. And if there's a vuln in that appliance, everyone using that appliance gets popped. So, do you trust the developers of that appliance to be better at security?
(DIR) Post #AWlD98y8zlzPTs7kX2 by alwayscurious@infosec.exchange
2023-06-16T20:46:16Z
0 likes, 0 repeats
@mjg59 @gregersn I’m _much_ less concerned about code leaking than about malware getting signed and/or pushed to production.
(DIR) Post #AWlDVmmfe32nKrYPZY by iw@mast.hpc.social
2023-06-16T20:51:19Z
0 likes, 0 repeats
@mjg59 Hot take: Intel, Qualcomm, Apple, Microsoft & AMD security processors do not belong in personal cpu's/apu's and should not be controllable by government or corporate for their own will over the owner's.
(DIR) Post #AWlDkwAv0lNSnz7XEW by alwayscurious@infosec.exchange
2023-06-16T20:53:04Z
0 likes, 0 repeats
@mjg59 I agree, but I also find it telling that organizations like Let’s Encrypt and Mullivad use Qubes OS, despite its lack of remote attestation.
(DIR) Post #AWlEJRMZYsejNY1Xrk by mjg59@nondeterministic.computer
2023-06-16T20:58:46Z
0 likes, 0 repeats
@iw that's cool, they're entirely under owner control
(DIR) Post #AWlFEPvRZxCbQVVGaG by josh@social.joshtriplett.org
2023-06-16T19:45:57.819902Z
0 likes, 0 repeats
This seems like a scenario where the very common middle ground is incredibly awful."IT is not competent enough to enforce security restrictions" has serious problems, but people can get work done in that environment."IT is competent enough to enforce security restrictions and both willing and able to take responsibility for making them reasonable and dealing with any issues that arise" has a different set of potential problems, but can work."IT is competent enough to enforce security restrictions but is not willing or able to take responsibility for the consequences of their restrictions" creates a horrible environment that developers should run away from very fast.People in scenario 1 are in a local maximum, and aren't confident (and often have ample evidence to the contrary) that they'll get to scenario 2 rather than 3, so they fight both 2 and 3 tooth-and-nail. And it seems like very few companies reach 2, far more end up at 3, and the ones in 3 think they're in 2 and blame the developers for not accepting it.
(DIR) Post #AWlFEQthxtPMRPhOW8 by alwayscurious@infosec.exchange
2023-06-16T21:08:41Z
0 likes, 0 repeats
@josh @keithp @mjg59 What kind of users one has is incredibly important, IMO.One can impose a vast array of restrictions on non-technical employees without significantly interfering with their productivity. Developers, however, cannot do their job without privileged access to their development environments. Applying policies meant for non-technical users to developers is a recipe for disaster.In my experience, the only reasonable solution is to isolate sensitive data (such as customer data and signing keys) and integrity-critical data (such as source code) from dangerous workloads (such as email and web browsing) via virtualization. The security boundary becomes the entire VM, not the unsecurable workload running within it. Qubes OS makes this much easier.
(DIR) Post #AWlFERgH3KFws2QBDU by mjg59@nondeterministic.computer
2023-06-16T21:10:08Z
0 likes, 0 repeats
@alwayscurious @josh @keithp Based on experience, Qubes is too much of a productivity impediment for even security engineers
(DIR) Post #AWlFRWAPgVeWY4kgeO by alwayscurious@infosec.exchange
2023-06-16T21:13:01Z
0 likes, 0 repeats
@mjg59 @josh @keithp Why is that? Personally I consider this a bug, and I imagine the rest of the Qubes devs would also rather this not be the case.
(DIR) Post #AWlFxcOk3LXN8mlEGW by mjg59@nondeterministic.computer
2023-06-16T21:18:33Z
0 likes, 0 repeats
@alwayscurious @josh @keithp this was an exercise that was carried out with the devs - I don't have access to the writeup any more, sadly
(DIR) Post #AWlGC5TijJV9NyzN3o by alwayscurious@infosec.exchange
2023-06-16T21:21:14Z
0 likes, 0 repeats
@mjg59 @josh @keithp how long ago was it? If you mean the Qubes devs, then hopefully some changes have been made based on that.
(DIR) Post #AWlLdiyKV70ZSlItV2 by dalias@hachyderm.io
2023-06-16T22:22:18Z
0 likes, 0 repeats
@mjg59 Completely agree but also unclear why/in what context anyone's work laptop would have access to data belonging to your users.
(DIR) Post #AWlvNTVDqRjbCZEwL2 by isotopp@chaos.social
2023-06-17T05:02:51Z
0 likes, 0 repeats
@mjg59 The answer to that hot take is me, on my previous employers job, taking every bit of endpoint"security" software to gain local root through its privileges.Took about an afternoon of work for each, and the exploit was usually stable across the fleet.The desire of IT too manage my work laptop is securing and endangering the laptop in precisely equal parts
(DIR) Post #AWm1As91Vz97aVELtQ by waldi@chaos.social
2023-06-17T06:07:51Z
0 likes, 0 repeats
@mjg59 Sure.And then there are the special cases. Due to something like that, I recently told my employer that I won’t be able to do the work he gives me any longer. That is going to be fun and pissed customer.
(DIR) Post #AWmy7lEOelyuZbWp9M by nf3xn@mastodon.social
2023-06-17T17:08:19Z
0 likes, 0 repeats
@mjg59 💯 it should go without saying that staff do not get a say at all on what goes on a company device. That does not mean feedback is not welcome or that we do not need to try help. It is possible to design so that it really doesn't matter that much what is on the device but that really depends on the nature of the organization. E.g. we have remote contractors 'coding thru a keyhole' from BYOD macbooks (they whinge about not being able to copy and paste locally &c. but y'know TOUGH).
(DIR) Post #AWn5LtDKTNtV44iHs8 by aes@toot.community
2023-06-17T18:28:51Z
0 likes, 0 repeats
@mjg59 No problem, I'll just work somewhere else. (I'm not kidding, it's why I fired my last employer)Security always say they don't want to be the guys that always say no, ...and then they do. (Really, how about PR review that just screens for the most egregious? Raising the bar to some modest subtlety seems quite cost effective)If my choice of OS in any way risks customer data, it's already long past time to run for the hills, because security fell down on the job a long, long time ago.
(DIR) Post #AWn6SvmlPVL71OD1Jg by nirvdrum@ruby.social
2023-06-17T18:41:41Z
0 likes, 0 repeats
@mjg59 @littlefox It's reasonable to have restrictions. Something no longer receiving vendor security updates should be easy to deny. On the other hand, prohibiting any Linux distribution because it's easier to lock down macOS or Chromebooks sounds like security prioritized its own efficiency over the rest of the company's. I care a lot about proper handling of user data, but also firmly believe internal support groups should try to enable valid use cases, not be a barrier by citing security.
(DIR) Post #AWpC14GVHHGDFm8WI4 by mav@hackers.town
2023-06-18T18:53:05Z
0 likes, 0 repeats
@mjg59 while I agree, there are far too many places for which this means "use Windows or find another job"