Schools make use of a variety of third-party solutions with these solutions increasingly involving both the software and the hosting of the solution; The days of all third-party solutions being hosted on school servers in a school server room are fast disappearing. School data is more and more stored in third party solutions, with data ranging from simply a list of email usernames and passwords to much more significant and sensitive records which might include medical information, financial information, etc with the school frequently being the data controller and the third party the data processor. As such, ultimately, the security of the data is the responsibility of the school, yet these third-party solutions are increasingly seeing data breaches.
So, what might this look like when a third party suffers a data breach, such as a ransomware cyber incident?
The first few days
It is likely the third party might first attribute issues to common or garden IT issues and outages before they realise, they are suffering a cyber incident such as ransomware. So, to start with you might get simple “we are investigating an IT issue” messages in reply to tickets logged. At this point it is important to realise, even if they are now aware of the cyber nature of the incident, they are likely to be limited on what they will be able to tell schools due to legal risk, cyber risk of tipping off the cyber criminals and due to fear of providing information which might later turn out to be incorrect. There is also the need to prioritise managing the incident rather than seeking to manage communications with those schools affected. As such for the first few days you should expect to hear little useful information, with this being potentially very frustrating.
Issue identified
There will then become a point where the issue will be identified. So, you might be told that a ransomware incident took place on a given date and that specific actions were taken however as before you will get little other information. If you are hoping to know what ransomware strain was used, how it entered the systems, what specific actions were taken, which schools were impacted, etc, you will be waiting a long time. You will get enough information to be considered informed but little beyond this.
It is now a school cyber incident, and the appropriate senior staff need to be made aware, although there is relatively little detail available which can be shared. Ideally at this point you will know what data is stored by the impacted third-party solution however if you do not, the first step will be to establish the extent and type of data potentially affected and therefore the risk to the school. It is also at this point good to consider the comms side of things and what message you might want to send out to your various stakeholder groups dependent on the, yet undetermined, impact of the incident. For schools it is about a reasonable measure of preparedness rather than rushing to share; Its that balance between pushing out comms too early, where you don’t know much or where what you know may later prove to be incorrect, or leaving it too late and being accused of not sharing information early enough; There is no “perfect” solution to this, it is simply a risk based judgement call based on the incomplete information available at the time.
At this point, now we know that there is a cyber incident and the possible data and school impact, it may be necessary to consider an initial report to regulatory authorities such as the Information Commissioners Office (ICO) as well as to the NSCS and Action Fraud, plus it may also be worth raising with insurers. In terms of the ICO, a quick phone call for advice to their helpline is an easy step which can be taken at this point and may both yield helpful next steps as well as evidencing an attempt to take reasonable measures in response to the incident.
The first two weeks
We now move on to the forensic analysis as hopefully your third-party vendor gets an outside cyber expert to pore of their systems, the activity logs, etc to give them a clear (or as clear as possible) picture as to the events and what data might have been accessed or exfiltrated. Again, information is likely to be slow in being shared, again due to the perceived risks to the third party. It may be that they have nothing to offer beyond that which has already been shared.
Again, it’s back to risk-based decision making in relation to comms. What needs to be shared, with who and when? This will very much be determined by the nature of the incident itself with a major incident where data has been exposed needing urgent communications whereas an incident which resulted in IT outage, but no data loss may not. My key advice here is to ensure logs of activity and decision making are kept so these can be used in later review. Knowing who contacted who, when they contacted them and the reasoning behind decisions can be very valuable in establishing the reasonableness of actions taken should the context of the incident change or should new information become available.
Wash up
There will then be a point where the third party will consider the incident closed and where update pages, etc, put in place in relation to the incident may stop being updated or may even be removed. At this point there should be some summary as to learnings from the incident and about future changes in processes, security measures, etc. if you don’t receive such an “after action” report then it is important to press on this matter. You are unlikely to receive much specific detail on the incident however you should at least receive a broad description of the issue plus some evidence of planned measures to prevent reoccurrence, and therefore some reassurance that things have been learning and that actions are being taken.
Conclusions
“Hope for the best but prepare for the worst”
For me the key thing is to prepare for these kinds of incidents in advance, and not just in terms of IT support staff, but in terms of the wider staff body. A desktop exercise where a virtual scenario is played out is the easiest way to achieve this, with SLT and other key staff involved. At the end of such an exercise all need to be clear that, in the event of a serious incident, although we want quick resolutions these are often impossible or inadvisable, with police, insurers, regulatory bodies and cyber security experts all likely to contribute their views on what should happen and when. Constant phoning IT for updates is only likely to slow the process down. We need to all be ready and aware of the likely slow nature associated with painstaking initial investigation and even more painstaking, or is that painful, recovery operations. We also need to be clear what things may or may not be possible as we seek to return to “normal” following an IT incident.
That said, we also need to be proactive in identifying data which might potentially be impacted, preparing communications, preparing contingency measures and otherwise being as prepared to deal with the incident as best as is reasonably possible.
As technology becomes more and more important to the operation of our schools, I suspect we need to spend more and more time on preparing for the eventuality where it goes wrong, with cyber incidents being an increasingly likely source of this eventuality.
Technology and Learning