Trusting Software for install not necessarily GDPR

[bjohnny42]

So I'm not sure if this is the correct forum for this message, but I'm wrestling with a few questions and thought i'd canvas some opinion.

 

Before we install any software on the windows network, chromebooks, iPads, Windows PCs we ask for those requesting the software to fill out a form. The starting point for this being GDPR thoughts. What data are you thinking of putting in there, how do they store the data, where is it stored etc. Just a confirmation that isn't too much to ask is it? Our data protection officer would then read their privacy policies etc and ask the company questions based on these and ask for clarification, before we then approve that service, or approve it with caveats. This often takes quite a bit of time to process correctly.

 

Now that is all well and good if a piece of software or service you are looking to subscribe to is expecting this.

 

But what about the software which isn't going to deal with data in the traditional sense. BUT as something is now being installed on a system it then does start to have access to data.

A PST combiner for example. How do you know which one to trust and install and which one not to?

If you are working on a Chromebook and we are requested to install an extension it then asks for permission to access your google drive.. Ooo quite a bit of data there i expect. What is it going to do with your google drive. Same for an extension that asks for access to your email.

A python environment install.

Something to connect to control a microbit

Basically, how do we know the software we are installing is doing what it says it's going to do and nothing more?

 

Upto now we are basing our choices around the reputation of the writers of the software so a "created in my garage over the weekend" piece of freeware probably won't get installed, but a piece of open source with millions of downloads probably will, as would something from Microsoft, Apple, Adobe etc though the recent supply chain attacks make me question this as they may be as problematic as something else.

 

Does anyone out there have any thoughts on what they do to check or test? We aren't in a world where we can't trust everyone all the time to do the right thing.

 

Or do we say, to heck with it. Let's just install anything anyone asks, if we can get it working move onto something else.

[psydii]

ALl new software and services are reviewed through a GDPR lens here before any technical review takes place.

 

If the software or service has a privacy notice, start there. If it does not, yet has a cloud component, then don't use it as you already know that they will not have built it to comply with GDPR. If there is not a privacy notice and the software appears to run local only, reach out to the developer. If you still have concerns that it *might* exfiltrate data without permission - deny the request - or fire up the monitoring tools (Fiddler/Wireshark and Procmon) in a test environment and see what it really does.

 

I wear the onsite Data Protection hat and the IT Manager hat - so all new software and services cross my desk before being approved for use / install, all new applications get a DPIA. Often I have to give a hard "no" before i get very far into reviewing, but equally often I can bounce my concern to the DPO (outsourced) who will do the heavy lifting regarding reviewing policies and talking with the developer. DPIA's are signed off by the DPO (or sometimes get sent back for more work/denied.)

 

It is all about managing risk. Generally these days its not much about local apps, and much more about 3rd party services that want to connect to 365 or Workplace. These all have privacy notices that can be reviewed. But generally if they want to connect and maintain access to OneDrive/ Google Drive/email, they get declined either by me or the DPO, even the ones based in the EU/UK, unless they have additional protections around staffing/safeguarding or preventing their staff from viewing our personal data.

[GrumbleDook]

Also remember that it is not the privacy policy/notice you are looking for, but a Data Processing Agreement. It may be in the PN or in a contract/terms of service … but a PN is often more about what the company will need to run as a business … not what they process on your behalf.

[enjay]

all new software and services cross my desk before being approved for use / install

 

Are you sure? How do you know departments aren't spending their budget on subscription access to web services? What about free products which require student information, such as Plickers? Our finance team are pretty good at flagging spending requests to me, although sometimes they don't spot that an order relates to an online service, but I find it very difficult to regulate the use of free services.

[psydii]

Are you sure? How do you know departments aren't spending their budget on subscription access to web services? What about free products which require student information, such as Plickers? Our finance team are pretty good at flagging spending requests to me, although sometimes they don't spot that an order relates to an online service, but I find it very difficult to regulate the use of free services.

 

Because they are required to by policy, they have annual GDPR refresher training, and they are reminded twice during the year and like you, finance check in with me.

 

 

Also nothing can authenticate through 365/Google without Global Admin consent and we have Sophos / Defender looking out for data exfiltration - we occasionally catch student data trying to leave via email, so we have technological tools in place too.

 

 

Is it 100%? I doubt it, but it the DPO feels its a good enough effort. We even review our DPIAs.

[enjay]

nothing can authenticate through 365/Google without Global Admin consent

 

Ooh, that's interesting. How did you set that up?

 

we have Sophos / Defender looking out for data exfiltration

 

Doesn't that generate a lot of false positives to wade through every time someone pastes a class list into a SharePoint document?

[GrumbleDook]

Ooh, that's interesting. How did you set that up?

 

Turn off the use of GWfE and M365 for authentication against 'third parties', unless you add them to an authorised list.

https://www.mydataprotection.world/blog/data-protection/looking-at-a-least-access-approach-from-both-a-data-protection-and-safeguarding-point-of-view/ gives my thoughts on it and a link at the bottom to a supporting guide.

[jthompson]

Regarding having Google APIs operating on an allowlist basis, I'd previously assumed that that couldn't be applied to the basic sign-in scope, just the beefier API scopes covering apps, but I now see that the sign-in scope (i.e. the "Sign in with Google" mechanic that websites might offer) can actually be set to allowlist posture as well. I think I must have missed when that was updated.

 

It's also annoying that new API scopes for Workspace apps default to unrestricted. The recent migration from Hangouts to Chat left the Chat API unrestricted, for instance. Had a similar thing with Classroom API in the past as well. It definitely seems like you have to review all these settings regularly to combat Google's penchant for very permissive defaults.