 Hello, everyone. Thank you so much for joining us. My name is Terenceedin. I'm the lead cybersecurity architect in the UK government's cabinet office. I'm going to spend a few minutes talking about some of the vulnerabilities we've discovered in official government domains and how we communicate those risks to domain owners. So, this is it. This is what I'm talking about. The United Kingdom operates in the .uk country code top level domain and the UK government are the sole operator of the .gov.uk domain namespace. When a user sees .gov.uk in the address bar of a website or in an email, they should be reassured that what they are seeing is official. If there is a vulnerability in any part of that domain space, a malicious user can cause significant harm to people and long lasting damage to the state's reputation. So, how do we protect these domain names? Well, first things first. There are hundreds and thousands of .gov.uk domains and back in the day when the web was new, everyone got a domain name because it was fun. We didn't really know what we were going to do with them. We didn't know where it was going, but we now have all of these domains. And now, UK government domains sit behind billions of transactions a year. They process revenues and benefits and identity documents and law enforcement and military operations. And these domain names have been great for government efficiency and for trust. But lots of people don't realize how business critical they are and some government bodies don't know how to effectively protect them. There is loads of good advice on how to protect your website and your emails from cyber attack, but a domain attack is different. With a domain attack, a malicious user can take complete control of a government agency's entire digital presence. That's why we refer sometimes to government domains as critical national infrastructure. CNI. So, what does that mean? Well, with CNI, we usually think of things like power stations and transport hubs and we publish big scary documents like this because if someone were to launch an attack on, say, an oil refinery, it could cause environmental and economic damage. Well, the same is true if there is an attack on the domain name system. And that's why we need to treat digital vulnerabilities as seriously as we take vulnerabilities in physical security. So, the damage that a malicious actor can do if they steal a .gov.uk domain name is limited only by their imagination. It's not just the direct damage. If people lose trust in digital government, they might abandon government digital services entirely like, for example, Universal Credit. Users who aren't able to trust a website might start physically going to job centres or calling them on the phone which could overwhelm those scarce resources. Or they might not be able to claim the benefits that they're entitled to at all. A serious attack could cause widespread public unrest and potentially a national emergency. So, let's look at some of the interesting vulnerabilities we find and how we communicate those risks with domain holders. Here is a list of all the registrars that are currently available to register .gov.uk domain. And, yeah, there are a lot. I think over 300 different registrars. And how do government departments make sure that they're with the right registrar for them? Because a registrar has complete control over the domain. And what does the domain holder know about the registrar? Do they vet their staff? Do they understand who owns them? Do they understand their operating model, whether they make money? One vulnerability class we're looking at is how we monitor changes to DNS so we can detect if a change has been authorised or whether it has come from a malicious insider. So, we have a complex set of heuristics to detect insider threats and whether they have introduced information into DNS, which is unwanted. It can be incredibly difficult to spot if a change to a domain is legitimate, it might be a simple typo, or it might be the start of an attack. With thousands and thousands of domains receiving regular updates, we're also looking at what sort of machine learning we can apply to help separate the signal from the noise. C names are brilliant. They're a fundamental feature of the modern web. They allow you to redirect part of your domain to a third party. For example, you might have reports.whatever.gov.uk and that might point at a cloud provider, like in this example, Amazon's AWS. But when you do that, you're giving that cloud provider a little bit of your domain. What happens if that service stops? If a user decides to delete the cloud service but doesn't stop the C name redirection, that's a vulnerability. We call this a dangling C name because the C name is not pointing to a valid target anymore. In this example, a malicious user might spot that the C name isn't working and then register that dangler themselves. They now have control of that part of the .gov.uk domain name space. And with even a little bit of that space, hijackers could host bad content. They could send emails impersonating .gov.uk services. They could use it for further attacks on a network because they will look like insiders because they now have control of a .gov.uk domain name or because someone forgot to delete a C name. We see these attacks all the time in the public sector and the private sector. Some are benign and some can be quite serious. Here's one which happened to us recently. UK Department for Transport caught inadvertently serving pornographic content to site visitors. In many ways, this was the least worst scenario. This was embarrassing but it wasn't malicious. A dedicated attacker could have phished users, got login details to critical systems, asked the public for their financial information. We spotted this very quickly and it was taken down very quickly but it was certainly embarrassing. Name servers are another fundamental feature of DNS. Name servers hold all your DNS records. They tell people where your website is, where your email servers are, all sorts of other important things. But one interesting vulnerability we often see is name server records with typos. They point to domains that don't exist. But if the domain doesn't exist because of a typo, what happens if a malicious user registers that domain name? This happens. It allows a malicious user to completely take over a legitimate .gov.uk domain. This is worse than a C name hijack because you could lose your entire digital service or have your traffic intercepted without even knowing. Of course, even if a .gov.uk domain name is pointing to correct name servers, there is quite a bit of difficulty in auditing those name servers to make sure the supplier hasn't forgotten to patch it or worse, forgotten to renew their domain name. The log4j vulnerability here, everyone particularly hard and it presented a real problem for us. We have a vast digital estate, a large portion of which might have been vulnerable and might be prone to attack. It was impossible, functionally impossible, to contact every single domain owner and then to talk them through how to protect themselves. It would have been costly and impractical for each of them to use a different service to scan themselves. So we built a mass scanner in a weekend and used that to probe for vulnerabilities in our own infrastructure. And that meant we could send targeted communications because humans get alert fatigue. If we alerted people who weren't vulnerable, it would have wasted their time and it would have made them less likely to pay attention to our next alert. We see a bewildering range of vulnerabilities. Some are really simple to describe and others are not. Some have an immediate impact and it's clear that they need to be fixed straight away. Others are slow burners. They don't have an obvious route to exploitation and it can be difficult convincing people that this is something they need to take seriously and they need to fix. So this is a summary of the situation. It is almost certain that someone malicious out there has the capability to identify domain name vulnerabilities in bulk. And if they have, we wouldn't see just one domain attack. We would see a wave of attacks all at once across the entire public sector. We won't know about every attack. If someone quietly hijacks a name server and starts intercepting emails, we might be none the wiser. It could render us unable to collect taxes, pay benefits or fulfill our treaty obligations. Given the reliance on the internet for so much of our daily lives, this could be catastrophic. And even if we did recover, how would we get people to trust us again? That's the bad news. What about the good news? Well, the good news is our team of experts is really good. It is a fairly regular occurrence to learn one morning that we found a brand new problem with the public sector domain that is potentially catastrophic and that it is fixed quickly. And you can see here just a few examples of the damage we've averted over the past few years. Now, our team don't have access to every public sector body's IT system. So a lot of our work is outreach, finding the right people, persuading them that we are who we say we are and that they have a problem, that they need to take it seriously and hand-holding them through a fix. And I think that's the core problem we have, both as a team and as part of the wider community. How do we communicate risk? Well, the first step is, how do you find the right person to contact? Now, I know what you're thinking. You just look at the who is records. Every domain name has metadata associated with it, which tells you who the owner is. We open up a terminal, we type in this example.gov.uk and it spits out the answer. But sadly, it isn't that simple. Because, well, if we confide the owner on who is, that means other people confide the owner on who is. So let's take this entirely fictional example. Putting personal details in who is records leaves the organization open to social engineering attacks. Right here, we can see the name of the person who manages this website. And we can see their address. And we can see their phone number and their email address. All of these are potential vectors for social engineering. The mobile number here is vulnerable to a sim swap attack. An email address, well, this means that we can send spearfishing emails because we know the user's name. Oh, look, they haven't used a .gov.uk email address. They're using what looks like a personal one. Maybe it doesn't have 2FA on it. Maybe they've reused their password. This is the problem that we are facing. So we now insist that, for example, all email addresses in who is are role-based, for example, domains at. And that way, hopefully, they will survive staff changes. And maybe it will go to a distribution list. We want to make sure that phone numbers should be landlines because they are less likely to be at risk of things like sim swap attacks. And we don't want people's personal names in there because, again, it provides a vector for phishing. The other problem is, not every government website, not every government domain has a dedicated IT staff. We have domains for giant government departments, sure, but also tiny ones as well, for example. Now, look, as far as I am aware, Downton Abbey is fictional. I'm sorry to break it to you. But it does represent sort of small village or parish, which is quite likely to have a .gov, .uk domain name. And that will be used mostly for information for local residents, for people to contact their local elected officials and things like that. It is often the place that people turn to for local information, but small local organisations often don't have dedicated IT staff. And they certainly don't have big budgets for 24-7 threat monitoring. So we have an issue. Who in Downton Abbey would we contact? Who is responsible for the domain name? Who do we tell? It might be a parish clerk who could also be responsible for dozens of other organisations. Should we contact the web hosting provider? Well, small organisations often don't have the budget for 24-7 support from their hosting provider. Maybe we should contact an elected official, but do they have the passwords for the domains? It's really complicated. And then once you do find the right person, how technical are they? With the big departments, we can use things like sticks and taxi, but the big departments probably already have extensive security monitoring. How do we communicate with someone who isn't very technical, what the problem is, how urgently they need to take it, and how to fix it? We can't really send CVE numbers. I mean, we could, but they look pretty scary to normal people, and they often have a lot of technical information that doesn't necessarily help people fix their infrastructure. How do we strike the right balance between instilling a sense of urgency but preventing panic? So this is what we're spending a lot of time doing, working out how we communicate vulnerabilities in a humane fashion. We have a responsibility to keep the .gov.uk domain name space safe for everyone, and that means not just finding vulnerabilities, but helping people fix them. So those are some of the issues we face. I hope you found it interesting. If you have any questions about our work or about domain security more generally, then please email us at support at domains.gov.uk. Thank you so much for attending, and I look forward to taking some of your questions. Thank you.