Teachers installing software....

[Koldov]

It has become apparent that for all my efforts in locking down the teacher's laptops, I must have made some glaring errors.

 

Yesterday I had one come back for a 'warranty repair', it was actually 'user damage' in my opinion, but that's for another thread another time.

 

I normally take this opportunity to peruse the laptop and make sure everything is in order and it is updated and run a virus scan etc...

 

I have found Roblox installed on it and some obvious signs that the teacher has let their own child use it (again, another thread for another time).

 

My question is, that I was of the opinion that with a general %appdata% SRP in place for the usual suspects (.exe etc) and them being 'Standard Users' that they couldn't install anything, but now I come to think of it the Business Manager installed Zoom on his and some others have installed Chrome on theirs, so how do I lock this down?

 

I seem to remember asking a similar question a long time ago (and I forget the actual context), but is it that it installs to a user instead of Program Files?

 

This is obviously something I should know and I kind of feel a bit silly asking, but any help is appreciated...

[paulkerton]

It's been a while since I was involved with Windows 10 installs, but I think you need AppLocker for this.

 

https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview

[3s-gtech]

A lot of modern software, like Teams, Chrome etc can install itself into AppData. I have used a mixture of SRP and Applocker to stop this, while FSRM catches and stops any .exe downloads in the first place (obviously, that's no use on local storage alone).

 

You have a separate issue if their child has used it, and I'd be asking for SLT support to reinforce this one. If you can find where Roblox is installed, you can probably nip this in the bud entirely.

[jthompson]

Is your SRP operating as a blacklist or as a whitelist? If it's the former, it's worth taking the time to rework it as a whitelist instead. That is, block everything by default, and add rules for the things that you know you want them to be able to run.

 

Edit: we're just using SRP here and are successfully preventing user isntallations of things like Zoom, Teams, DropBox, etc.

Edited November 13, 2020 by jthompson

[mavhc]

SRP will stop it, just only allow c:\program files, (x86)\ and windows\ to start with, then see what breaks.

[kennysarmy]

Is it not helpful for the teachers to be able to install software?

 

Surely with good AV and other protection it should be fine?

 

Do we really need to be preventing the odd bit of occasional other use by teacher's kids? Is that likely to do any harm?

 

A happier workforce is a more productive workforce, no?

 

Just playing devils advocate.

[3s-gtech]

Ransomware/malware can use this avenue to run. If the logged on user can execute it, and your connected drives aren't sufficiently protected, you could well end up with a major issue on your hands.

[Sheridan]

We use Applocker here and its usually pretty effective, and make any local accounts just members of the 'Users' group

 

I don't think its reasonable to allow your kids to use your work issued laptop - it happens here all the time, which is why we see damaged keys, spilled drinks, scratches marks on devices. I'd play the other devils advocate and say if a teacher wants their own kid something to play games then buy them their own device.

[Jcx500]

We use applocker here, alongside are AUP which outlines conditions of taking the laptop home etc

[LeMarchand]

Is it not helpful for the teachers to be able to install software?

 

Surely with good AV and other protection it should be fine?

 

Do we really need to be preventing the odd bit of occasional other use by teacher's kids? Is that likely to do any harm?

 

A happier workforce is a more productive workforce, no?

 

Just playing devils advocate.

 

Might be better these days, but last time I saw it allowed all sorts of rubbish/malware got installed. I'd also argue that kid use = games = shortened lifespan of machine, especially the keyboard.

 

As for happiness, that never seems to apply to us. (I may be feeling a bit cheesed off today!)

[synaesthesia]

Is it not helpful for the teachers to be able to install software?

 

Surely with good AV and other protection it should be fine?

 

Do we really need to be preventing the odd bit of occasional other use by teacher's kids? Is that likely to do any harm?

 

A happier workforce is a more productive workforce, no?

 

Just playing devils advocate.

 

It isn't their device. Whilst in the hands of a 3rd party, it is far more likely to be damaged or incur problems. It isn't therefore just protecting the school, it's data and the physical laptop, it's protecting that member of staff from embarrassment and a large bill.

[LeMarchand]

Also teachers seem to have a somewhat lax view of licensing.

[Koldov]

Unfortunately I'm playing catch-up here, everything was set-up before I started and seemed to be working OK, fortunately most teachers just seem to 'know' they can't/shouldn't install anything, but there is always that 'one'.

 

I don't want this thread to get into whether they should or shouldn't be allowed, as I'm firmly in the camp they shouldn't and that's that.

 

From what I can see:

 

FSRM is set on the server to cover mainly Cryptolocker for the shared drives (plus executables and system files).

 

SRP is in a GPO for the Default Domain Policy and is set:

 

 

 

You can see how old it is from the references to XP...

[jthompson]

A lot of modern software, like Teams, Chrome etc can install itself into AppData.

 

This is such a bugbear. AppData was presumably intended to be for storing user-specific data. The executables should all still live in Program Files after having bee put there by an admin. The Teams app is I think one of the worst examples in this regard: requires installation by each user and runs executables out of AppData. From MS themselves, no less.

[jthompson]

Unfortunately I'm playing catch-up here, everything was set-up before I started and seemed to be working OK, fortunately most teachers just seem to 'know' they can't/shouldn't install anything, but there is always that 'one'.

 

I don't want this thread to get into whether they should or shouldn't be allowed, as I'm firmly in the camp they shouldn't and that's that.

 

From what I can see:

 

FSRM is set on the server to cover mainly Cryptolocker for the shared drives (plus executables and system files).

 

SRP is in a GPO for the Default Domain Policy and is set:

 

[ATTACH=CONFIG]59782[/ATTACH]

 

[ATTACH=CONFIG]59783[/ATTACH]

 

You can see how old it is from the references to XP...

 

Yeah, you want to work on replacing all of that with an SRP that blocks by default, then add path rules for stuff that you know will need to be run legitimately. You'll also want to remove .lnk from the list of executables. You're best creating a new GPO from scratch and then linking that to your computer OUs when it's ready.

[Andrew_C]

Kids using staff laptops = NOPE

 

Teachers installing software = more nuanced. Zoom for example. You might not want your lessons delivered using it; Trinity Cambridge Uni are using Zoom this year for interviews, and insisting that candidates have an inkable device. Thus teachers should be holding practise interviews using Zoom to give their pupils the best chance of shining. (I know this is a very specific example, but don't be too dogmatic would be my plea)

[mavhc]

Just make sure you have a way of easily installing random pieces of software when required. https://github.com/mavhc/choco-school

[chazzy2501]

I don't mind teachers installing from the M$ store. They are vetted and can update without permissions. Appdata installs allow Teams to be installed without needing me. I'm not sure how vulnerable a PC is in this config though. This is the M$ default so I (assume) it's ok.

 

The pupil PCs however are not allowed to execute outside of the programfiles.

[jthompson]

Yup. Rule with an iron fist in a velvet glove. Take a whitelisting approach and be open to requests from staff. Staff abiding by your AUP won't necessarily mitigate against a website that's delivering malware.

[3s-gtech]

On the subject of Teams, I make the assumption that it's the heavy relation to Chrome that guided this thinking.

 

I have a specific exception in SRP and Applocker for the Teams install, and I deploy it using robocopy from a share (as staff can't run an installation .exe from their Downloads folder). Scruffy but works.

 

I'd say that allowing software to install to AppData potentially leaves that user wide open. Plenty of malware will search there as a possible install location.

[infosecpartners]

limit administrative privileges and optimally include an agent to monitor system processes and alert on suspect activity (DLP and EDR solutions would work well here)

[TechMonkey]

Yup. Rule with an iron fist in a velvet glove. Take a whitelisting approach and be open to requests from staff. Staff abiding by your AUP won't necessarily mitigate against a website that's delivering malware.

 

This. I tell all users that they can not install software as it means anything could be installed and they would be gutted if their device was out of action. But let us know if you need something and we try and have it done within 3-5 days. Be up front and it puts the onus on them to plan. In emergencies, with a lot of teeth sucking, we have been known to do a days turn around and even a couple of hours turnaround. But they need to know that is an exceptional case and doing a favour, not the norm and any future request of that nature will not necessarily get the same response.

 

Its been very rare that I have refused to install something and when I have it is very obvious why.

[mavhc]

Staff get emails, emails are the main source of ransomware.

[Sheridan]

This. I tell all users that they can not install software as it means anything could be installed and they would be gutted if their device was out of action. But let us know if you need something and we try and have it done within 3-5 days. Be up front and it puts the onus on them to plan. In emergencies, with a lot of teeth sucking, we have been known to do a days turn around and even a couple of hours turnaround. But they need to know that is an exceptional case and doing a favour, not the norm and any future request of that nature will not necessarily get the same response.

 

Its been very rare that I have refused to install something and when I have it is very obvious why.

 

Same here - we will generally install anything as long as its reasonable, licensed and we get some warning! We also install teamviewer on laptops so we can remotely 'install as admin' if someone is isolating or similar.

[TechMonkey]

Staff get emails, emails are the main source of ransomware.

 

Well not really but hey ho.