Messenger v5 Data Security Summary

Applicability

This document applies to Groupcall Messenger v5, for all supported MIS systems.

Version Information

Date Author Notes
1 11/09/2012 Tim Verlander
2 24/09/12 Tim Verlander Changes highlighted by technical review
3 05/10/12 Stuart Abrahams Clarifications, ‘real-time’ data requests

What is Groupcall Messenger?

Groupcall Messenger is used by over 2,500 Primary and Secondary schools and provides an easy-to-use solution for parental communication. The system gives schools the ability to send text messages (SMS), emails and automated voice calls to the mobile phones and landlines of parents, staff and key contacts.

To provide an accurate list of school contacts at any time Groupcall Messenger v5 integrates with the schools Management Information System (MIS) and maintains a secure copy of essential school data within the Groupcall Messenger v5 web platform.

Document Aims

This document explains the selection, safeguarding, and security of data stored in the Groupcall Messenger v5 platform in full technical detail.  If you require a simpler document then please see our Messenger Data Sharing Agreement which provides sufficient detail to make an informed consent regarding an organisation’s use of Groupcall Messenger v5.

Overview of Data Movement in Groupcall Messenger

The diagram[1] below details the movement and storage of data within Groupcall Messenger, further explanation is provided below.

[1] Twitter logo used within permissions defined at https://twitter.com/logo


Protection of Data in Flight – MIS Data

Importing data into Messenger v5 varies by MIS and upload route;


Protection of Data in Flight – Messages

Delivery of directed messages and responses

For the following methods of communication Messenger v5 uses industry standard systems to achieve message delivery.

  • SMS (text) messages
    • Broadcast
    • Open response
    • Closed response
    • Voice messages
    • Emails

All messages, of any type, will be temporarily queued in Messenger v5 then forwarded and queued at one or more of our partner delivery companies for delivery into the appropriate delivery network (e.g. mobile phone network for SMS).  This means that the content of the message, and any response to it, will be queued and forwarded by a number of different systems as would any message not originating from Messenger v5, hence the same risks apply as for any other message sent by these methods.

SMS, Voice and Email are generally accepted not to be secure forms of communication, both in terms of interception and recipient verification.  For this reason, Groupcall does not encourage the transmission of any sensitive information via these methods.  Messenger v5 cannot determine whether messages contain any personal information and responsibility for message content must rest with the end user.

Message responses – i.e. replies returned by recipients of closed or open response messages –are queued and forwarded through the message delivery networks then pushed to Messenger v5 by our partner delivery companies.  These messages are queued in Messenger v5 briefly before the response is associated to the outgoing message.

Delivery of broadcast messages

For the following methods of communication Messenger v5 uses the publicly available API integration for each specific system listed:

  • Twitter

In order to achieve API integration with these systems it is necessary to store API credentials into Messenger v5 and these are stored in the same way as Cloud hosted MIS credentials.  When connecting to the API to publish broadcast messages in this way Messenger v5 uses SSL encryption to verify the destination system prior to transmitting both the credentials and the broadcast message.

Clearly anything published in such a manner is deemed to be in the public domain and hence Groupcall strongly discourages the publication of anything but generic information (such as school closures) using this method.  Messenger v5 cannot determine whether messages contain any personal information and responsibility for message content must rest with the end user.

Protection of Data in Flight – Attendance Writeback

For selected MIS products Messenger v5 can allow authorised users to update attendance marks for students.  For example if a teacher records an Unknown Absence in the MIS during electronic registration the school may then text the parental contacts to investigate further; during the process a parent may reply that the student is ill and has gone to the doctors.  As a matter of convenience, Messenger v5 allows authorised users to then read such responses and record attendance mark changes within Messenger v5 to reflect the actual absence reason.  In this example an authorised user in Messenger v5 may elect to update the Unknown Absence mark to an Illness mark, and this would then be updated in the MIS for historic record and for extraction by any other system that reads MIS data.

This functionality is supported only on selected MIS products; specific products that Messenger v5 can write back to are listed in the sub-sections below.

The right to update attendance is individually assigned to users within Messenger v5 and any organisation may choose to assign, or not to assign, that right to any or all of their users in accordance with that organisations own operating policies.

Writeback of changed attendance marks – Cloud hosted MIS products

For selected cloud-based MIS products Messenger v5 writes directly back to the MIS using the same secure and authenticated cloud-to-cloud transfer method as used to obtain the school data initially.

Currently this feature is not supported on any cloud-based MIS products.

Writeback of changed attendance marks – school hosted MIS products

For selected school-based MIS products Messenger v5 queues a writeback request in Messenger v5 and then sends notification to the school Xporter using a separate platform called Groupcall Dashboard.  The Groupcall Dashboard platform is used to monitor and manage Xporter installations globally and to send them repair instructions.  The writeback notification is then picked up by the school Xporter installation typically within 5 – 10 minutes of being queued. The details of what to write back are not passed via the Groupcall Dashboard platform, just that there is something to do.

The Xporter installation then connects to the Messenger v5 platform using SSL to pick up details of the writeback records waiting, identifying itself with its API Key.  A typical writeback request will consist of non-personal information, such as:

  • The School MIS record ID for the learner
  • The mark to be written back
  • The time-point of the mark, e.g. Date and Session

The Groupcall Dashboard platform is deployed into the Microsoft Windows Azure Cloud Platform in the same fashion as Messenger v5 and is hence subject to the same stringent security considerations.

Currently this feature is supported on the following school-based MIS products:

  • Capita SIMS .net

Writeback of changed attendance marks – SIF-enabled data sources

Messenger v5 transmits SIF_Update events to the ZIS using the same SSL protection mechanisms as for SIF_Request messages.  These update events contain:

  • SIF identifiers for the learner and for the attendance period/session
  • The mark to be written back, encoded into the SIF schema
  • The time-point of the mark, e.g. Date and Session or Date and Time.

The ACL configuration at the ZIS will allow or disallow the SIF update event to be transmitted back to the source agent.

‘Real-Time’ School Data Requests

Messenger v5 supports real-time contact and attendance requests for a range of MIS products.  These requests can be initiated via the Messenger v5 user interface by authorised logged in users, and the incoming data response is processed in the same way as a normal scheduled import/upload of data.

Cloud-hosted MIS products

Messenger v5 will schedule an immediate synchronisation with the Cloud-hosted MIS.  Depending on platform workload and MIS responsiveness this will take an amount of time to process before refreshed data is shown to the user logged into Messenger v5.

You should be aware that some MIS products apply a low priority to daytime data requests and/or return ‘cached’ data from earlier in the day.

School-hosted MIS products

As with data writeback, a request will be queued for the school in Groupcall Dashboard.  When the Xporter installation in the school picks up this action,  typically within 5 – 10 minutes of being queued, the Xporter installation will run the Messenger v5 extract after any current extractions complete and will upload after it completes running the Messenger v5 extract.  This means it may take 30 minutes or more for new data to appear in Messenger v5.

Manually integrated MIS products

Manually integrated customers are free to upload new CSV data extracted from their MIS at any time.

SIF enabled data sources

For SIF enabled data sources Messenger v5 will queue SIF_Request for the necessary data objects to the ZIS Zone URL.  When the provider agent responds to these requests they will be imported into Messenger v5.

Protection of Data During Use

Messenger v5 uses a web-based user interface that protects data and guards against unauthorised access in the following ways:

  • Industry standard SSL encryption secures and verifies the website.
    • Use of SSL encryption instructs the users browser not to cache pages.
    • Use of SSL encryption prevents proxy servers caching meaningful content.
  • Users must use individually accountable usernames and passwords to log in.
  • Users can be deactivated at any time.
  • Users are constrained to access only the schools they are associated with.
  • Users are not automatically generated, they must be explicitly and individually created.
  • Users can be constrained by assignment of rights, including the right to send messages.
  • Users can have their data view limited to only a subset of that available for their school(s).
  • The forgotten password procedure contacts the user directly and does not release any password information.
  • Messenger v5 does not have any API to allow extraction of personal information.

Protection of Data in Storage

Messenger v5 uses Microsoft Windows Azure SQL storage, located in the Europe North territory and protected by international statute.  The following are the most frequent discussion points centring on use of Windows Azure as a service delivery platform.

What provisions are in place to protect data from unauthorised access in Azure?

Windows Azure is subject to an extensive array of physical, logical and procedural measures to protect the security, confidentiality and integrity of data.  More information is available via the Windows Azure Trust Centre (see below) but the highlights are:

  • Edge packet filtering[1] and firewalling[2] protects our virtual machine instances
  • Developer access requires mutual SSL authentication using client-specific certificates[3]
  • Limited physical access to datacentres, and strict physical disk disposal policies[4]
  • Automated and integrated security patch management[5]

Are these measures independently verified?

  • Microsoft carries out regular penetration testing to identify security flaws[6]
  • Please see the ISO27001 certification for Windows Azure[7]
  • Please see the Cloud Security Alliance STAR submission for Windows Azure[8]

Is data encrypted in storage?

Both personal information and metadata are stored in Azure SQL unencrypted.  While at first glance this may seem inconsiderate to data security there is a sound rationale for this approach.

  • Encrypting data stored in the platform would indicate an absence of trust in the Windows Azure platform.  This is not the case and Groupcall have deemed the platform to meet/exceed an adequate level of data security for the purposes of Messenger v5.  This assessment takes into account the information provided in this document and further detail from Microsoft provided documentation.

Encrypting data does not significantly reduce the risk of exposure.  In order for Messenger v5 to display contacts, deliver messages and provide history and search functionality it would be necessary for data to be decrypted when required.  If Groupcall Messenger v5 or Windows Azure were compromised then the code to achieve this decryption would also be compromised and data would effectively be unprotected despite being encrypted.

Updates to Groupcall Messenger V5

The Messenger v5 platform consists of a number of distinct components, including Messenger v5 itself, our interfaces with external systems (MIS, message delivery partners, etc), Groupcall Xporter and the Groupcall Xporter data extraction scripts for each supported MIS.

Groupcall periodically releases updates of Messenger v5 to introduce new features and to resolve identified bugs.  Groupcall takes a number of measures to validate releases of Messenger v5 before they are promoted into live; these measures begin before development and include:

  • Technical design discussion for both new features and bug fixes
  • Peer review of application code
  • Testing of new features against our local platform and then our staging platform
  • Regression testing existing features against our local platform and then our staging platform
  • Integration testing against live builds of other Groupcall Messenger v5 components

To carry out this testing we carry out the following phases in succession:

  • We test on our local platforms using sample data
  • We publish our code into Windows Azure in a staging area and test using demonstration accounts in our live datastore that are populated with sample data.

Once we are satisfied with testing and integration we ‘swap’ live and staging over so that staging becomes live.  This also means that we have the previously live code in staging, and allows us to swap back promptly if any issues are identified after cutover.  This previously live application version is then typically discarded within 48 hours of promotion unless there is reason to retain for rollback purposes for longer.

A similar testing process is applied for changes to Groupcall Xporter and Groupcall Xporter data extraction scripts for each supported MIS

  • Testing against sample MIS data
  • Piloting with a small number of consenting live schools
  • Release of update to the Xporter estate

Microsoft Windows Azure

If there are any clarifications required regarding information in this document then the below documentation provided by Microsoft will undoubtedly add clarity.

Windows Azure Security Overview

This whitepaper covers the vast majority of questions asked about the security of the Windows Azure platform.

Windows Azure Trust Centre

This website details all aspects of security, privacy and independent verification that affect the Windows Azure platform.

Global Foundation Services

This website explains more about the operation and delivery of Windows Azure datacentres.

Need more?

If you are an existing Messenger v5 customer then please contact Groupcall Support with any further questions.  If you are a prospective customer then please contact Groupcall Sales.

Print Friendly