31 ms·

We're trying to do much of what you mention here. It ain't easy. Here's some of my thoughts, as one of the people in Development trying to achieve it. The app

We're trying to do much of what you mention here. It ain't easy. Here's some of my thoughts, as one of the people in Development trying to achieve it. The app whitelist impairs my efficiency, and honestly takes a fair amount of fun out of work. I can no longer use many of the tools that help me, and instead am confined into the corporate-approved structure. This is both a productivity issue and a job satisfaction issue. Trying to separate our development workstations, and dev environment overall, from the rest of the sordid mess, is extraordinarily difficult. We're trying to do similar what you recommend, with developer VMs running in our internal ESX cluster. However, that technology conflicts with Microsoft's Hyper-V (we're a MS shop). We're trying to get to Docker/k8s, but we can't run Docker inside a VM that runs in ESX. So we're trying to offload the actual execution of the system, even for local testing, into DevSpaces. But there's a lot to figure out, and DevSpaces is a young product. Further, private AKS environments are a new thing in Azure, and we've a couple of times now run into roadblocks with MS's own growing pains. Your "upvote" system seems to have merit, but with, I dunno, 50 or 60 devs, spread across several teams focused on different tech, it doesn't seem like it would scale well. Coming up with the right mix of apps, and convincing our Risk team, is very difficult. Especially when so much of their pushback seems confusing (like, DBeaver was denied as a FOSS product, but approved when we paid for the Enterprise version).

staticassertion 6y ago
> I can no longer use many of the tools that help me, and instead am confined into the corporate-approved structure. This is both a productivity issue and a job satisfaction issue. Out of curiosity, like what? > Trying to separate Yeah, like I said, starting early is going to make things much easier. If you're trying to get to this place later on, it's just wayyyyyy harder and most orgs can't get there. This is often the case with security - if you build your code, infra, policy, etc, with security in mind from day 1 it's 1000s of times simpler than doing it even just a few years later. > Coming up with the right mix of apps, and convincing our Risk team, is very difficult. Oh yeah, a risk team can be the real killer. That's why upvote is nice - security only gets involved if something is flagged. But if your risk team isn't willing to work with you that's a problem, and it sounds like yours isn't doing the work consistently. To me, approval should be easy. Even if a malicious app is approved that's often still a huge win - the attacker can't use many of the tools and techniques they're used to. Obviously you want to avoid that compromise too, but it isn't the whole entire goal. We whitelist some vendors entirely. Our app whitelist request form is: * What risks are there with this extension/ app? * Is there another approved app that can do this, and if so, why do we need this one? * How will this app help you? What is it for? That first question is really important because people usually have a decent understanding of what the app should/ shouldn't be doing, or if the risk should be trivial. It's all about spreading the assessment out.

staticassertion 6y ago

> I can no longer use many of the tools that help me, and instead am confined into the corporate-approved structure. This is both a productivity issue and a job satisfaction issue. Out of curiosity, like what? > Trying to separate Yeah, like I said, starting early is going to make things much easier. If you're trying to get to this place later on, it's just wayyyyyy harder and most orgs can't get there. This is often the case with security - if you build your code, infra, policy, etc, with security in mind from day 1 it's 1000s of times simpler than doing it even just a few years later. > Coming up with the right mix of apps, and convincing our Risk team, is very difficult. Oh yeah, a risk team can be the real killer. That's why upvote is nice - security only gets involved if something is flagged. But if your risk team isn't willing to work with you that's a problem, and it sounds like yours isn't doing the work consistently. To me, approval should be easy. Even if a malicious app is approved that's often still a huge win - the attacker can't use many of the tools and techniques they're used to. Obviously you want to avoid that compromise too, but it isn't the whole entire goal. We whitelist some vendors entirely. Our app whitelist request form is: * What risks are there with this extension/ app? * Is there another approved app that can do this, and if so, why do we need this one? * How will this app help you? What is it for? That first question is really important because people usually have a decent understanding of what the app should/ shouldn't be doing, or if the risk should be trivial. It's all about spreading the assessment out.