0

Looking for some guidance on an internal discussion we're having.

We have a .Net developer that is requesting all development systems with Visual Studio installed don't have .Net updates installed. The reasoning is that it breaks Visual Studio and things (I'm not clear on exactly what things) go 'missing' or no longer work.

Some examples of the patches they're keen to avoid:

  • Security Update for Microsoft .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 for x64 (KB3127222)
  • Security Update for Microsoft .NET Framework 3.5 on Windows 8.1 and Windows Server 2012 R2 for x64-based Systems (KB3072307)
  • 2017-09 Security and Quality Rollup for .NET Framework 3.5, 4.5.2, 4.6, 4.6.1, 4.6.2, 4.7 on Windows 8.1 and Server 2012 R2 for x64 (KB4041085)

I haven't had much luck finding specific guidance around development systems, so some advice would be appreciated.

Improve this question
4
  • "specific guidance around development systems," - It is unknown on how your "development systems" are integrated or separated in your infrastructure. What harm can be done if these systems are compromised, how easy could they get compromised, what do these systems have access too, ... . For example having unpatched systems in an isolated network which is used only for development without access to critical systems or data means a different risk than having these in the normal production network. – Steffen Ullrich Dec 9 '20 at 8:42
  • Usually, if you just use visual studio, Microsoft updates it if a .Net patch interferes with its operations (they use it internally after all and are the owner of both products). – LvB Dec 9 '20 at 9:11
  • 2
    I do not buy it, security updates do not break .net framework behavior. I have had VS 2008, 2010 and 2012 in the same machine fully updated and had no problem at all in any of the projects – bradbury9 Dec 9 '20 at 11:50
  • at some point you've got to bite the bullet... this developer is pushing things down the road until they run out of road. It's a very bad idea not to install security patches/updates. Now .NET version "updates" are another thing completely... it's just as bad sometimes to be an early adopter. (for instance moving from an older .NET core major version to a new one.... I always wait a bit until they fix the early bugs...) – pcalkins Jan 8 at 19:50
0

  • If you need to run permanently unpatched/outdated systems for any reason, at least create isolated/firewalled subnets and restrict access of these systems to other systems and information to mitigate a possible infection and restrict the use of network service on these machines.

  • that would include limiting the code stored on the machines to the information absolutely needed.

Which brings us to why we would have these:

  • The customer asks us for it

  • The usecase requires it (e.g. we need to test against an unpatched system, since the system it will be deployed on is isolated and wont receive updated not relevant to specific issues)

  • It really breaks something

A final remark:

Sometimes registry settings may be changed, and in most cases Windows allows to do an specific activation of non-secure features (i think windows 10 would still be able to talk to an early smb server if you deactivate enough stuff). In my opinion it is much better to try to achieve the required functionality by patching completely and having a setup script/ .reg file explicitly addressing the "things" which are broken by the patch/update. This also enables a much better documentation and reproducability of what is actually going on (will take more resources, though).

If you visual studio installation is so brittle that it if broken by upgrading, there is a problem.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.