The UK Government’s initiative to prescribe a security standard to any organization accessing the Government Connect Secure Extranet is a move designed to keep government organisations one step ahead of the inexorable increase in security threats. There have been too many high profile data thefts and losses by Government organizations, highlighting both the risk to, and the importance of, ICT Security and the governance of citizens’ data.
The result is the Government Connect Secure Extranet (GCSx). HM Government has mandated the way in which public authorities and government departments can securely transfer data between each other.
So, for example, how does a local authority needing Housing Benefits data access the Department for Works and Pensions (DWP) database? Via the GCSx of course!
Similarly, Job Centre Plus communications with local authorities will only accept communications via the GCSx, and likewise, communications with the Police and the NHS will only be provided through this connection.
The concept is a “community of trust” and the GCSx is one of a number of secure Government extranets, including GSx, GSi and GCJx. See our Glossary of Terms at the end for details of these other networks.
So how does a district council access the GCSx? Via a secure connection, the security of which is governed by the Code of Connection, or ‘CoCo’.
The GCSx CoCo
In England and Wales it is referred to as the GCSX Code of Connection (CoCo). In Scotland it is referred to as the GSX Code of Connection (CoCo).
Through GCSx, local authorities can connect to the Government Secure Extranet (GSX) and Intranet(GSI), the National Health Service (NHS), Criminal Justice Extranet (CJX), and the Police National Network (PNN).
The Code of Connection takes into consideration how best to protect the “community of trust” taking into account all potential threats, including:
Attack from the GCSx itself
Attack from the Internet
Mobile data theft and loss
Attack from the internal user
Code of Connection (CoCo) for the Government Secure Intranet (GSI) and GCSx, Memorandum Number 22. According to CESG Infosec Memorandum Number 22, protective monitoring has traditionally been the most underrated and least effectively used security measure.
The scope of the GCSx Code of Connection can be summarised as follows
Physical Security and Access Control, restrict and control access to the GCSx, including use of Firewalls, Intrusion Protection technology and with particular focus on Mobile/Remote Worker security.
Policies and Procedures, in particular Change Management Processes, approvals and documentation.
Configuration ‘hardening’, to ensure that known threats and vulnerabilities are eliminated from all systems, with a zealous patch management process combined with anti-virus technology, regularly tested and verified as secure.
Strong Monitoring for security incidents and events, with all event logs being retained for 6 months
In fact, the scope of the standard is quite similar in respect of its approach and its measures to the PCI DSS (The Payment Card Industry Data Security Standard), which is another security standard all local authorities will now be familiar with. The PCI DSS is concerned with the secure governance of Payment Card data, and any ‘card merchant’ ie an organisation handling payment card transactions, such as a District council collecting Council Tax, must comply with the details of the security standard.
Therefore it makes sense to consider measures for CoCo compliance in the context as PCI DSS, since the same technology that helps deliver CoCo compliance should be relevant for PCI DSS.
Is there a way to automate and simplify compliance?
Configuration Change Tracking – once your firewalls, servers, switches, routers etc are all in a compliant state you need to ensure they remain so. The only way to do this is to routinely verify the configuration settings have not changed because unplanned, undocumented changes will always be made while somebody has the admin rights to do so! We will alert when any unplanned changes are detected to the firewall, and any other network device within your ‘Compliant Infrastructure’
Planned Change Audit Trail – when changes do need to be made to a device then you need to ensure that changes are approved and documented – ideally, you need an automated solution that make this straightforward, reconciling all changes made with the RFC or Change Approval record
Device ‘Hardening’ to be enforced and audited – The best solutions available today provide automated templates for a hardened configuration for servers and desktops and network devices to show where work is needed to get compliant, thereafter tracking all planned and unplanned changes that affect the hardened status of your infrastructure. Specifically, the state of the art in compliance auditing technology covers registry keys and values, file integrity, service and process are whitelisting/blacklisting, user accounts, and installed software.
Incident Response – All event logs from all devices must be analyzed and correlated and escalated appropriately. Event log messages must be stored in a secure, integrity-assured repository for the required retention period for any governance policy.
Audit Logs – it is a mandatory requirement that Event Log messages are gathered from all devices. The best solutions available provide correlation of events with security event signature identification and powerful ‘mining’ and analysis capabilities. This provides a complete ‘compliance safety net’ to ensure, for example to name just a few, virus updates complete successfully, host intrusion protection is enabled at all times, firewall rules are not changed, user accounts, rights and permissions are not changed without permission.