Sophos Endpoint Security and Visual Studio

Anyone?

Hello Aarongu,

what is both the 'on-access scanning' and Windows exclusions areas?

Did you already use some other AV before (as you didn't mention this)? Naturally scanning is not "free" so you can expect some overhead, I wouldn't unconditionally call this an issue though. If CPU% is higher then there have been idle cycles before and higher isn't necessarily a sign of contention.

Indisputably compile time will increase when scanning is done, the question is how it compares to before and what quantity considerable is. I never refrain from mentioning that the users' attitude to AV plays an important part and biases perception. I had more than one case where exclusions were an absolute necessity at first. Last was some client/server application where the developers claimed that scanning (especially on the server) was causing the abysmal performance. In cooperation with the project manager we added some exclusions - on both server and clients - and all was well. Subsequently we quietly removed them, first from the clients and then also from the server, and (not so) surprisingly didn't hear any complaints. I should add that the developers also made some changes - but only for feature improvements and not to, perish the thought!, amend some unlucky design decisions (which didn't go too well with scanning) we had pointed out. Just an aside ...

Application development is a special case and might to some extent be impacted. Where did you get the list of exclusions from - which apparently doesn't have the desired effect? Did you approach this systematically or just start off with the exclusions? I'd compare performance with and without the exclusions (please note that usually only infectable files are scanned and only once per session - if they haven't changed they are not rescanned but just verified). I'd also assess the performance with on-access completely turned off. You won't get the same performance as without scanning - measuring the actual impact of the various settings and scenarios might help mitigating the effect though.

Christian

Hi Christian, 

We were using CA and then MSE before moving on to Sophos. Both of these AV providers were incredibly CPU hungry so we moved to Sophos, we advertised a lower use of CPU.

In the 'Sophos Enterprise Console' when specifying the policies for a group of PC's you can specify exclusions. The 'Anti-virus and HIPS' policy allows for an admin to specify what extensions they do not want Sophos to scan. There are several tabs such as 'Extensions', 'Windows Exclusions', 'Mac Exclusions' etc. etc. In both the Extensions and Windows Exclusions areas of this policy, I have specified certain file types that should not be scanned. For the most part these are working but we are still seeing an increase in CPU usage that is hampering the developers system's. 

I accept the fact that AV is going to cause an increase on CPU, this is only naturally. However, I expected that listing files to be excluded would limit the amount of scanning that is performed on the developers machines. What I want to find out, is if there are specific file types that you could recommend that would limit the impact of the AV on machines that are running Visual Studio?

Just as a note, yes we have tested disabling 'on-access' scanning but that didn't have an impact on the increase in CPU when compiling a program in Visual Studio. Disabling 'on-access' scanning is also not really something we want to do because it severely reduces our protection levels.

Thanks, 

Aaron

Hello Aaron,

in both the Extensions and Windows Exclusions

I see - forgot the excluded extensions (you get the same result with a Windows wildcard *.ext exclusion but the excluded extension is not as obvious - and note that the exclusions also apply to DLP). I suggest you also look at the On-Access Extensions tab in the client GUI (when no exclusions are set in the SEC policy) - it shows the the extensions to be scanned and the ones you specified might not be on the list anyway (thus they only give the filter driver a little bit more to do).

A few words on scanning - this is not some kind of fixed overhead when a file is accessed. I've mentioned that a file is not rescanned. Dunno the exact order but when a file is intercepted its attributes (and potential exclusions) first determine whether it is scanned at all. A "fingerprint" is taken so that a file already encountered is not scanned more than once. The true filetype is determined (the START command will attempt to start a program regardless of its name or extension - give it a try), a cursory scan is done (e.g. to verify the integrity of a signed file) and if necessary a deeper scan is performed.

If the results are (almost) the same with or without the exclusions then the cycles are apparently spent dealing with something else.

yes we have tested disabling 'on-access' scanning but that didn't have an impact on the increase in CPU

I'm not sure I understand you correctly - there is a significant increase in CPU (compared to Sophos not installed) even with On-Access completely off? Do you have HIPS (behavior monitoring) turned on?

Christian

Hi Christian, 

We have specified all our exclusions in the '*.ext' format and we believe that these are working correctly. What we are trying to find out is, are there any general exlusions that we should be adding to our list that specifically relate to Visual Studio. 

Our issue is that the CPU % increases dramatically when a program is being compiled, I know that the AV must perform some kind of action whilst the compiling is happening but the development team believe that the CPU usage should not be as high as it is.

We have not turned off On-Access scanning or HIPS because it defeats the point of having an AV program installed on the machines. 

Hello Aaron,

we have not turned off On-Access scanning or HIPS because it defeats the point of having an AV program

this is prudent and I didn't (and would not) suggest this as solution. I don't have detailed knowledge of Visual Studio but IMO usually you should neither need extension-based exclusions nor general exclusions - especially the latter can "backfire" when they are applied to common libraries and auxiliary files. If they turn out to be necessary then ideally exclusions should only be made for files to which users have only read access.

the CPU usage should not be as high as it is

This is why I suggested turning off the various components (and also compare it to the numbers without Sophos installed). I'm sure there would be a knowledgebase article if general recommendations could be made. As mentioned a high CPU usage by itself is not bad (indeed, back in the old days of the mainframe dinosaurs any value below 100% meant either oversized hardware or wasted cycles because of a badly tuned system), especially if the machine has "nothing else to do" - more important is the effect on elapsed time. Static scanning should only have a significant impact if very many small files or a number of files which require deeper scanning are accessed. Even then a subsequent run should perform noticeably better.

Again, high CPU and whining fans are not the main criterion (as long as there is no contention for this resource - unfortunately this is not as simple to see as one might wish). If turning off on-access makes a significant difference then likely "much of something" is scanned you didn't associate with VS/VB. You'd have to find out what it is and whether it can safely be excluded. If it's HIPS then the compiler apparently "does things" which keep HIPS busy - might be necessary to engage Support.

If no single setting makes a significant difference - well, then it's time to take a closer look at the actual numbers.

Christian

I am having the same issue with Visual Studio .. not sure if it's happening only on Windows 10?

It's very slow ...

Thi sis a work around in case VS doesn't open 

https://developercommunity.visualstudio.com/content/problem/97594/visual-studio-2017-ide-fails-to-start-after-instal.html