Recently, Andy Williamson talked about adopting the Common Technology Services (CTS) secure email guidance in his post ‘Securing email for the Scottish public sector’. Here, I’m going to share more detail about how we implemented the secure email guidance from a local authority perspective. I hope the lessons we learned will benefit any organisation adopting this standard.
A bit about us
Fife Council is the third largest authority in Scotland with 18,000 employees over 500 sites. In common with other local authorities, we currently use email via the Public Services Network (PSN) in order to communicate securely with the NHS, police, local authorities and central government.
GDS has published communications regarding the expiry of the Government Secure Intranet Convergence Framework (GCF), which explained that there would be alternative methods of securing government email. The intention is to give organisations more choice to deliver secure email, either by enhancing existing infrastructure or to allow the adoption of cloud email. As a security and compliance lead, I was curious to see how this would be achieved.
I read the secure email guidance document with great interest, noting the familiar technologies and some that were new to me. After discussion with my colleagues within the Scottish Local Authority Security Group (SLAISG), it was clear that we needed to explore what this guidance meant for local authorities and the wider public sector.
Sometimes, the best way to explore something is to do your own tests, so with the support of CTS, we implemented the guidance in Fife.
Implementing the guidance
We found the secure email guidance to be clear, logically structured and easy to follow. However, if you are like us there will be some technologies that are relatively unfamiliar. The good news is that this piece of work can be implemented one step at a time, rather than as a “big bang” complex change. Happily, there were clear security benefits as we completed each step.
The guidance supports the adoption of cloud-based email services in line with the government’s renewed commitment to ‘cloud first’. Local authorities are not mandated to use cloud services and many organisations, including Fife, currently host their email service on premise. This wasn’t a barrier, as the guidance is equally applicable to on-premise email services, enabling organisations to migrate to the cloud when they are ready.
It’s all in the preparation
Before we started rolling up our sleeves, raising change requests for the configuration changes and implementing the guidance, there were some up-front tasks to perform.
First, we requested access to the Domain information tool. This tool walked us through the tasks to complete and let us test as we went along. You can request access to the tool by emailing contact.cts@digital.cabinet-office.gov.uk
Next was to identify and procure a Domain-based Message Authentication, Reporting & Conformance (DMARC) reporting service. From the guidance, it was clear that enabling DMARC would generate a lot of XML reports.
While organisations may be fluent in XML and wish to analyse these reports manually, we decided to use dmarcian-eu (a cloud-based service) to turn these reports into a meaningful dashboard. There are a number of DMARC reporting services available on the Digital Marketplace, ranging in cost, so be sure to engage with your procurement team if you think you’ll need one.
We identified and briefed staff in each of the important areas to make sure they were ready to complete a series of controlled changes. They included:
- the owner and administrator of the email service
- the administrator of the email gateway (if different from the email service) - in some organisations they could sit alongside other DMZ/Firewall components, or in a cloud-based email filtering service
- the Domain Name System (DNS) owner (we host our own DNS, but some organisations may have hosted DNS)
- the team responsible for buying and managing security certificates
By this point, we were ready to go.
One change at a time
So what was our experience of each of the technologies and our experience of their implementation? I won’t replicate the detailed information from the secure email guidance, but will describe the high-level tasks and provide some hints and tips.
At each step in the process, you can validate changes using the domain information tool, which also shows you the work that still needs to be done.
Encryption
Enabling Transport Layer Security (TLS) was the easiest change to make and yet the most beneficial to the organisation. We:
- requested certificates for the email servers.
- loaded the certificates on the email gateways and enabled TLS
- enabled opportunistic TLS
The result of this simple change was that 93% of all our organisation’s email became transport layer encrypted overnight. A surprising demonstration of how prevalent TLS is across email platforms.
With confidence that TLS was working correctly, we could switch to using mandatory TLS for organisations that support it. These can readily be identified from the whitelists published via the domain monitoring tool.
Anti-spoofing
To stop phishing and spoofing on our domain we first enabled Sender Policy Framework (SPF): a list of valid sources for your domain’s email published via a DNS record. This should contain all of the systems sending email on your organisation’s behalf.
Clearly, your main email gateways will be in there, but you should also consider systems such as:
- a hosted web server that sends emails to customers
- cloud-based service providers , such as payroll, pensions or other systems
- cloud-based mailing list providers sending mailshots to customers for events
Making sure your SPF record is as accurate as possible will pay dividends when it comes to analysing DMARC reports in the next step.
DMARC lets you set a policy and get reports back on where your email comes from.
Being relatively unfamiliar with DMARC prior to reading the guidance, I was fascinated to find that it would give us visibility of emails claiming to come from our domain that had in fact been spoofed by potentially malicious senders. This reporting happens despite the fact that the email does not touch our infrastructure at any point.
With our reporting service in place we were ready to enable DMARC. This required a DNS change to add a DMARC record to track email in a monitoring mode (p=none):
v=DMARC1;p=none;sp=none;fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@fife.gov.uk,mailto:mxb71w0c@ag.dmarcian-eu.com;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk,mailto:dmarc@fife.gov.uk
Starting in monitoring mode gave us visibility of email claiming to come from our domain, without the risk of blocking legitimate email. After a few days, we started to receive reports from larger email providers like Gmail and Outlook.com highlighting emails that failed the check. Having a DMARC reporting service was invaluable in presenting the information clearly in a dashboard view.
The vast majority of non-compliant emails identified in the report were relatively benign spam, however, we did find some instances of legitimate email from a hosted mailing list provider used by our organisation. This gave us the choice to either change the way we use this provider or to add them to the SPF list to allow them to continue to send email on behalf of our organisation.
Looking at the DMARC DNS record in detail there are two types of reports that you should be aware off. The guidance gives the following template:
v=DMARC1;p=none;sp=none;fo=1;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@yourdomain.gov.uk;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk
Aggregate reports ( rua ) provide summary reports. These do not include the contents of the email or the sender email address. Useful for statistics and high-level reporting, not so good if you want to track back the email to its purpose.
Forensic Reports ( ruf ) provide detailed forensics for non-compliant messages. These contain the entire content of the email, including attachments, only the recipient email is redacted. If your SPF record is accurate you should not have a valid email within forensics report, however, you should consider the privacy risk if you expect to capture some legitimate email. The content of these emails are shared with any email recipient stated in your DMARC record with a ruf entry, this could include GDS, your DMARC reporting tool, or your own organisation’s reporting email recipient.
Once you are happy that your SPF record correctly reflects valid senders for your domain the DNS DMARC record can be updated to start instructing recipients to quarantine non-compliant email. This can be phased in on a percentage basis (for example pct=5 for 5%) to reduce risk as detailed in the guidance:
v=DMARC1;p=quarantine;sp=quarantine;fo=1;pct=5;rua=mailto:dmarc-rua@dmarc.service.gov.uk,mailto:dmarc@fife.gov.uk,mailto:mxb71w0c@ag.dmarcian-eu.com;ruf=mailto:dmarc-ruf@dmarc.service.gov.uk,mailto:dmarc@fife.gov.uk
Domain Keys Identified Message (DKIM) is digital signing to verify the email source and protect from tampering in transit and needs three steps to implement:
- generate a public and private key pair with a length of at least 1024 bit but under 2048 bit. We used the openssl command line tool to do this, but some services may generate the key for you
- publish a DKIM DNS record with your public key
- configure your email gateway to add signatures to your outbound email
We apply the DKIM signatures on our email filtering service - Clearswift - as the last step before the email goes out. Any footers or re-writes after this point will break the DKIM signing.
Assessment
After completing this work you’ll be in a position to have your service assessed by CTS to provide assurance that it is correctly configured and secure. This is carried out by completing an online assessment form, which is similar to the PSN Code of Connection (PSN CoCo) with a specific focus on email configuration.
Like a PSN CoCo there is an obligation that your SIRO or Chief Executive will authorise this submission by means of a validation email. You will need to make sure that they are briefed around the security controls in place and are ready to respond.
In the end...
We implemented the guidance by configuring existing platforms, with no capital expenditure. This was done through a series of small changes without any disruption to the organisation. The end results are that the majority of emails to partners, third sector and citizens are encrypted in transit, with anti-spoofing protection, and assurance that email from our domain has not been tampered with in transit.
The guidance provides organisations the opportunity to adopt cloud-based services and the ability to securely deliver email outside the GSi network. However, I don’t want to sell it short. It’s not just about GCSX/GSi domain names but about current security best practice to secure information and protect the reputation of your organisation when sending emails.
Andy Williamson’s post highlighted that technical security is only part of the solution. The majority of emails to partner organisations will have governance arrangements in place, with handling guidance and assurance around the security of the receiving infrastructure. For recipients of sensitive information where there is less assurance in their technical security such as citizens, foster carers and volunteers there may still be a requirement for additional security controls or handling guidance.
I hope this reassures you that the guidance can be implemented with minimal effort while using existing skills and technologies. In signing off I’d like to give my thanks to Nick Woodcraft from the CTS team for the reassurance and guidance during the planning and implementation, and of course all of the staff at Fife Council involved in implementing the changes.
Next steps
If you are using the secure email guidance, or planning to soon, we’d love to hear from you. Contact CTS and we'll get in touch.
Martin Kotlewski is Lead Officer for Security & Compliance from Fife Council
3 comments
Comment by Paul Bargewell posted on
Very interesting and useful.
We currently have SPF and DKIM capabilities on our Email solution. Adding the DMARC DNS shouldn't be an issue. But sending out DMARC reports isn't something we have locally.
Getting reports back via a third party like dmarcian may lighten the load in terms of understanding our own reports, but adding the sending out of reports for others may be something we struggle with.
Comment by Martin Kotlewski posted on
Hi Paul,
Sending DMARC reports for others would be a very neighbourly thing to do, although there is no requirement in the guidance to do so. Our gateway product does not currently have this capability, but I intend to raise a feature request with our supplier.
This would help report on inter community emails that perhaps never make it out to the big DMARC reporting providers like Google, Microsoft and Yahoo.
Comment by Norman Kurzman posted on
Very Interesting to see what can be achieved on a relatively small budget. Good to see Fife leading the way.