The Contact Group - Looked After Call & GDPR Non-Compliance

[aidan_edutech]

Hi all,

 

Wonder if someone can help me with this. As background, we are a small managed service provider working out of Herefordshire with about 40 primary/secondaries on our books.

 

Our Local Authority has engaged with The Contact Group to provide a Virtual School for LAC children within our county and a number of our managed schools have their data extractor installed on their on-premise SIMS servers. SIMS is managed by a 3rd party company and not by ourselves.

 

Prior to May 2018 we were auditing our schools to ensure everything we knew about was in its proper place for GDPR and we came across an issue with the Contact Group data extractor. The log files for the data extractor on the SIMS server (c:\program files (x86)\Contact Group\Data Extractor\Logs were flagging up personal data. When we checked the logs, it seems that the data extractor was logging in plain text, the names, addresses and parent/foster carer names and contact details of all the LAC within the school. That is, all the data that was used to populate the Virtual School was recorded in plain text in the log files.

 

This was of a major concern to us as the SIMS server has shared access between us, the company that manage SIMS, Capita to need to remote in from time to time and also every other Tom, Dick and Harry it seems that need to drop another data extractor on the SIMS server from time to time. We always install these ourselves wherever possible but we are not always told this is going on.

 

Ordinarily, this data would be protected from within SIMS itself to which we don't have access and neither do many other 3rd parties but as soon as it is moved out of SIMS and dropped into plain text on the SIMS Server system drive then it becomes much more visible. Technically, it also contravened the then Data Protection Act in terms of processing personal data, you must ensure that you leave it as secure as you found it.

 

We raised this with The Contact Group, who after some persistence, agreed that it needed to be addressed and that they would removed personal information from the logfiles as it should not be required for telemetry troubleshooting. I also asked for logging of personal data to be moved to the cloud alongside the virtual school application (for auditing of personal data collection) and a number of other changes that I do not need to go into here. I was told that this would be carried out and we would be told when this work was finished. Despite being cc'ed in on every email, our Local Authority Head of Virtual School was silent in all regards.

 

I did not hear anything back so we have checked again. The data extractor has been updated and although the majority of personal data does not now appear in the logs, the full name of the LAC subject still appears in plain text. They have now also put in a log rotation to delete old logs (prior to May some of our school accumulated nearly 2 years of this data) but there are still logs for the last 5 days visible.

 

My question is simply should I accept this as a solution or push it back?

 

EDIT: The reality is that anybody using the Looked After Call solution would be affected in the same way so asking should I accept it is a closed question. The Contact Group have other hosted solutions/services but they all use the same extractor so there may be other information in the logs for these also but I only know of Looked After Call. I would be interested to know if anyone else has found personal data recorded in their data extractor logs.

Edited October 15, 2018 by aidan_edutech

[djrscally]

I think that at this point this is probably more the school's problem than Contact Group's. The excess of data in logging is daft and you're right to call them on it, but exposing some personal data in logs for a limited time is probably legit and the fact that personal data is available in plain text on a server is not a breach of data protection principles provided only people authorised to see that data can access it. If anyone connecting to the server can access anything on it (and particularly if the account that's running a particular processor's software can access data they shouldn't) then that's a problem with their user and process controls.

 

This was of a major concern to us as the SIMS server has shared access between us, the company that manage SIMS, Capita to need to remote in from time to time and also every other Tom, Dick and Harry it seems that need to drop another data extractor on the SIMS server from time to time. We always install these ourselves wherever possible but we are not always told this is going on.

 

I think that the schools ought to be setting up their server such that Tom's programs, Dick's programs and Harry's programs have their own user account to runas, and that those accounts should not have access to the directories of the other people's programs.

[box_l]

djrascally

 

Can you suggest a way that a user sufficiently powerful enough to be able to install software on a server, would be able to be prevented from seeing the contents of (c:\program files (x86)\Contact Group\Data Extractor\Logs), or similar path, without breaking their software?

 

If the file concerned was tucked away in userspace or encrypted, then this may be possible.

 

I think this is poor design of the software myself.

 

Regards

 

BoX

[djrscally]

djrascally

 

Can you suggest a way that a user sufficiently powerful enough to be able to install software on a server, would be able to be prevented from seeing the contents of (c:\program files (x86)\Contact Group\Data Extractor\Logs), or similar path, without breaking their software?

 

If the file concerned was tucked away in userspace or encrypted, then this may be possible.

 

I think this is poor design of the software myself.

 

Regards

 

BoX

 

I was more thinking a different user for running than installation.

[aidan_edutech]

Thanks for your reply.

 

I think that at this point this is probably more the school's problem than Contact Group's. The excess of data in logging is daft and you're right to call them on it, but exposing some personal data in logs for a limited time is probably legit and the fact that personal data is available in plain text on a server is not a breach of data protection principles provided only people authorised to see that data can access it.

 

And there in lies the problem. Whilst that data is still retained within the SIMS SQL Database, I don't have authorised access to it and neither does anyone in my company as we don't manage the SIMS installation and as such we don't even have a SIMS login or a SQL login. By placing it in plain text on a server I manage not only do I now have access to it but technically, as the server administrator, I am now responsible for it and could be held accountable for its loss.

 

Looked After Children are those unfortunate individuals who have been separated from their families, made a ward of court and placed with foster families/social care in other Counties for their own protection. As such there are staff within the school itself who do not know who these children are as this information is generally divulged on a need to know basis. Personally, I think it ranks right up there as some of the most sensitive data a school can handle.

 

The point I was angling at was that this is squarely a data processing issue. The school have given The Contact Group permission to extract that information. In that data processing, The Contact Group have removed the personal information from the existing security within which the school has stored the data and the stored personal data in plain text on the server itself. The consequence is that the personal data is now available to people who NEITHER party has intended to give access to and was carried out within the data processing of The Contact Group.

 

Personally, I thought this was a straight GDPR fail in terms of data confidentiality as within the data processing itself, you should not be able to take personal data that is only available to a certain set people and then make it available to people who are nothing to do with the data processing process.

 

Also the point about the logs which The Contact Group also missed is that the same names appear in all the logs and will do for their duration at that school. This makes rotating the logs pretty pointless as whether you have access to 500 log files with same personal data in it or just 5 with the same data in it is just as bad. The log itself is there for a limited time but the personal data itself is in every log file until that child leaves which could be up to 2 years.

 

I feel quite strongly about this as it is a company selling themselves as being secure and 'data centric' yet this is just sloppy and easy to fix. Perhaps if this was just staff salaries being leaked then I wouldn't be quite so narky about it but this is data from some of the most vulnerable children in our society.

[djrscally]

And there in lies the problem. Whilst that data is still retained within the SIMS SQL Database, I don't have authorised access to it and neither does anyone in my company as we don't manage the SIMS installation and as such we don't even have a SIMS login or a SQL login. By placing it in plain text on a server I manage not only do I now have access to it but technically, as the server administrator, I am now responsible for it and could be held accountable for its loss.

 

Oh sorry I misread you, but you're saying that YOU are unauthorised? I thought your point was the other services on the server could have access to the data. Mind you; if you're an administrator on the server, I think you have access to the SIMS data anyway via methods like this: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/connect-to-sql-server-when-system-administrators-are-locked-out?view=sql-server-2017

 

If you're an administrator on the server, you surely have access to everything on it. Isn't your agreement with the controllers written in a way that accounts for that?

 

Looked After Children are those unfortunate individuals who have been separated from their families, made a ward of court and placed with foster families/social care in other Counties for their own protection. As such there are staff within the school itself who do not know who these children are as this information is generally divulged on a need to know basis. Personally, I think it ranks right up there as some of the most sensitive data a school can handle.

 

Just wanted to add; fully agreed.

Edited October 16, 2018 by djrscally

[localzuk]

And there in lies the problem. Whilst that data is still retained within the SIMS SQL Database, I don't have authorised access to it and neither does anyone in my company as we don't manage the SIMS installation and as such we don't even have a SIMS login or a SQL login. By placing it in plain text on a server I manage not only do I now have access to it but technically, as the server administrator, I am now responsible for it and could be held accountable for its loss.

 

If you have access to the server, you technically have access to the database - you can recover passwords etc and gain access. The SIMS database isn't encrypted.

The point I was angling at was that this is squarely a data processing issue. The school have given The Contact Group permission to extract that information. In that data processing, The Contact Group have removed the personal information from the existing security within which the school has stored the data and the stored personal data in plain text on the server itself. The consequence is that the personal data is now available to people who NEITHER party has intended to give access to and was carried out within the data processing of The Contact Group.

 

It is never solely a data processing issue - it is always a mix of access control, data processing and procedural issues. If you give access to third parties to install their own bits of software, then IMO, you have created just as much an issue as the log files. The only people allowed on the server are those we give permission to access it.

 

However, yes, logs should not contain PII. There's no need for that. At worst, put a UID for that user in there, so to someone looking they won't know who it is without further access to data.

[aidan_edutech]

They have a contract with a separate company for the management of SIMS. We provide a virtual server to host the platform but do not manage the SIMS installation itself or its attached SQL database. We provide a flat server and they do the rest.

 

Granted we could take access as administrators but we have no interest in supporting SIMS or being responsible for it. Clear lines of demarcation is how IT support companies work together. They know we can own their installation anytime we want, but we don't and neither would we and they need to know that we won't and demonstrate that we haven't. Just because you might be trusted to manage somebodies gardens, it does not automatically give you the right to invite your mates round there for a BBQ.

[djrscally]

They have a contract with a separate company for the management of SIMS. We provide a virtual server to host the platform but do not manage the SIMS installation itself or its attached SQL database. We provide a flat server and they do the rest.

 

Granted we could take access as administrators but we have no interest in supporting SIMS or being responsible for it. Clear lines of demarcation is how IT support companies work together. They know we can own their installation anytime we want, but we don't and neither would we and they need to know that we won't and demonstrate that we haven't. Just because you might be trusted to manage somebodies gardens, it does not automatically give you the right to invite your mates round there for a BBQ.

 

It doesn't matter whether you WILL. It matters whether you CAN. If you're the server administrators then your data processing agreement with the controller needs to cover ALL the data that touches that server at any point ever, and your potential access to it is not unauthorised. Now if you actually went and read it, for no good reason, that's possibly a different matter. Just like you can potentially read the SIMS data but won't because you're all upstanding people.

 

If you want to be really diligent about it, go back to the "separate accounts for each supplier's program" thing and have all their stuff run from C:\users\supplier instead of Program Files. Limit your staff's logins to the server so they don't have access to those folders unless they need to elevate to Administrator for some reason. This really only changes the perception though IMO.

 

EDIT:

 

Also:

 

also every other Tom, Dick and Harry it seems that need to drop another data extractor on the SIMS server from time to time. We always install these ourselves wherever possible but we are not always told this is going on.

 

You mean they can just rdp to the server and install something?

Edited October 16, 2018 by djrscally

[localzuk]

It doesn't matter whether you WILL. It matters whether you CAN. If you're the server administrators then your data processing agreement with the controller needs to cover ALL the data that touches that server at any point ever, and your potential access to it is not unauthorised.

Indeed. This is exactly why we asked a nursery who uses our network to get their own storage solution for their data, simply because we don't want or need any access to their data. It puts an extra burden on us to deal with that I am not willing to have at present.

[aidan_edutech]

Thank you both for your replies and what I take from this is that the personal data should not be stored in the logs. I will go back to Contact Group and highlight this as an issue.

 

It doesn't matter whether you WILL. It matters whether you CAN. If you're the server administrators then your data processing agreement with the controller needs to cover ALL the data that touches that server at any point ever, and your potential access to it is not unauthorised. Now if you actually went and read it, for no good reason, that's possibly a different matter. Just like you can potentially read the SIMS data but won't because you're all upstanding people.

Agreed. Our DP agreement covers this and states we are jointly responsible (with the company that manage SIMS) for the security of the SIMS server itself (we are liable for all other servers on the network) but not for the data contained within the SIMS installation or the SQL database which is covered under a DP agreement with that company. The DP agreement is not an issue here, the fact that there is personal data from SIMS being stored/leaked in plain text into an area on the server which is not designated as secure and by a 3rd party data processor however, is an issue.

 

If you want to be really diligent about it, go back to the "separate accounts for each supplier's program" thing and have all their stuff run from C:\users\supplier instead of Program Files. Limit your staff's logins to the server so they don't have access to those folders unless they need to elevate to Administrator for some reason. This really only changes the perception though IMO.

 

That's just a faff and to replicate it across 40 sites is not only impractical but a waste of effort as you are simply treating the symptom of the issue and not the issue itself which is the leaking of SIMS personal data out to the data extractor logs on the system drive. The problem is still there, you are just trying to manoeuvre around it. Being diligent in this regard would be to approach the offending data processor and tell them to anonymise their telemetry logs and hopefully fix the issue for all their clients.

 

You mean they can just rdp to the server and install something?

 

No, not at all. But as we don't manage the SIMS installation, the company that do manage it have a requirement to allow 3rd parties on it (Tribal, Wonde, Capita etc) (via Rescue or GoTo Meeting etc) in order at perform maintenance and data collection tasks. They have their own credentials for that server (only!) and manage their own remote access. We don't monitor/record these remote interactions (verbose logging on all server logs which are syslog archived and server explicitly identified and monitored in firewall) and therefore cannot guarantee what 3rd party engineers are doing on that server. That is the responsibility of the company that manage the SIMS installation as the work is carried out under their credentials and within the remit of their DP agreement with the school.

 

What we should be able to guarantee though is that no highly sensitive personal data is stored on that system drive (the area we are responsible for) that other people may access either deliberately or by accident.

[sluggster66]

Has the school raised it with their DPO?

 

They should be able to lean on the company for you.

[djrscally]

Forgot to reply before, sorry.I think everything about this scenario sounds like a nightmare to be honest.

Thank you both for your replies and what I take from this is that the personal data should not be stored in the logs. I will go back to Contact Group and highlight this as an issue.That's just a faff and to replicate it across 40 sites is not only impractical but a waste of effort as you are simply treating the symptom of the issue and not the issue itself which is the leaking of SIMS personal data out to the data extractor logs on the system drive. The problem is still there, you are just trying to manoeuvre around it. Being diligent in this regard would be to approach the offending data processor and tell them to anonymise their telemetry logs and hopefully fix the issue for all their clients.

You are right of course that generally speaking software running in a production environment should not expose PII in the logs. I guess the reason I'm saying I'd approach this differently is that in my experience, lots of 3rd party software like this places personal data on disk in some fashion. For example, Groupcall's Xporter has a ton of services running through it to push data into various applications after taking it from our MIS: all of those put PII of some description into .xml files on our server. So, you might have a bigger problem than some software negligently dropping out data in logs; some of those extractors might be doing it deliberately, particularly with Wonde involved given their software is a competitor to Groupcall's Xporter and presumably works similarly.

Agreed. Our DP agreement covers this and states we are jointly responsible (with the company that manage SIMS) for the security of the SIMS server itself (we are liable for all other servers on the network) but *not for the data contained within the SIMS installation or the SQL database which is covered under a DP agreement with that company*. The DP agreement is not an issue here, the fact that there is personal data from SIMS being stored/leaked in plain text into an area on the server which is not designated as secure and by a 3rd party data processor however, is an issue.

I would really really think about this one again. Given you have access to that data, I'd say you need to formally count as a data processor for it.