Natural History Museum IT sinks its teeth into security alert overload

Despite limited security resources, the Natural History Museum’s two-person IT security team has found a way to better triage alerts.

The Natural History Museum is a prime example of a large public sector organisation that faces a vast array of cybersecurity challenges with a significantly smaller security team and budget compared to those in the private sector. Astute investment that optimises cybersecurity processes therefore takes on huge significance for the museum’s two-man IT security team, led by Chris Sleep.

World renowned for its enormous collections including fossils, artifacts, and preserved specimens, the Natural History Museum is one of the most popular tourist attractions in the UK, attracting millions of visitors every year (the COVID-19 pandemic notwithstanding). Whilst it is very much less synonymous with issues of cybersecurity, Sleep tells CSO how, until recently, the museum was facing a deluge of alerts from disparate security tools, displayed independently, without intelligence that correlated and joined up data across screens. This was compounding the diverse, complex cybersecurity challenges the museum is regularly exposed to.

Natural History Museum’s cybersecurity challenges

“When people look at us as an organisation, the public face you see is the fantastic building and collections, but around a third of our staff are scientists and research scientists,” says Sleep. “They are generating vast amounts of research data, digitising specimens and moving terabytes up to petabytes of data around—that side of things generates just as much of a security challenge as the public-facing issues.”

nhm image 2 Natural History Museum

Then there’s engagement with visitors, the museum’s website, fundraising, and more that come into play. The museum depends on CRM systems that contain sensitive personal information. “Personal information is absolutely one of our crown jewels and that’s one area we have very strong security oversight of,” says Sleep. “Like everyone, we’re using cloud services and scaling up both our research side and public presentation. We need to maintain compliance and all the while ensure we prevent ransomware from targeting our vast amounts of sensitive data. All of these things are significant challenges that the museum faces.”

Sleep explains that, upon this backdrop, the museum’s cybersecurity operations were alert-centric in nature, with the small team responding on an alert-by-alert basis and having to manually determine whether the alert in question relates to any others being produced from adjacent tools within the security stack. This gave rise to the need for investment in an analysis tool that, without breaking the bank, could intelligently and automatically investigate and triage security alerts in such a way that would allow Sleep and his colleague to determine what is being attacked, to what level, where to prioritise resources and raise flags as to whether additional layers are required to defend systems against the types of attacks they receive.

The museum opted for a SaaS-based product, SOC.OS. “We’d done proof-of-concepts with various SOC/SIEM technologies, things like Splunk—fantastic tools, but the costs were not so fantastic and nowhere near realistic for us as an organisation to even start down that road.” Going down the open-source route was also not an option for the museum, Sleep says. “That is time and resource intensive, too, and it doesn’t have the intelligence layers on top.”

Power of alert identification and prioritisation

Having been in place at the museum for more than a year, the SOC.OS tool identifies patterns of related behaviour across alerts and groups these into unique clusters (representing unique cyber cases and incidents), before attributing a priority score to each one. Whilst alert volume has remained consistent pre- and post-implementation, Sleep explains that his team no longer suffers from thousands of non-essential alerts across various systems muddying the picture. “That helps me prioritise where our resources go in terms of hardening and maintenance. It also gives me a big picture oversight that I can use to engage with the service owners of some of those systems (we don’t directly manage all of them), to make sure they’re fully aware of the situation. On that front, it also gives me evidence to use to argue for configuration changes devices which the service owners would previously step around.”

Another key benefit is the amount of time Sleep has saved, which he says equated to around a couple of hours each per day sifting the raw alerts, interrupted when the team picked up pertinent alerts to drill down into. “This has come significantly down over time to the point where now (albeit lockdown reducing some visibility) we can run through the triage list at a very high level in a few minutes, with about 30 minutes to review daily.”

That extra time has allowed Sleep to focus on other cybersecurity-related issues at the museum, including awareness training, working on policies, and liaising on projects and with other technical teams.

Sleep points out that SOC.OS does not operate as a traditional SOC/SIEM as it doesn’t use raw event data. It does, however, take the “shedload of alerts” the museum faces and helps to being those together into one place. “It puts those together, applies layers to highlight patterns across systems and helps us to understand what we need to look at first,” he says. If, for example, the museum’s protective email services are raising alerts about attacks coming in, the platform will triage and assess against alerts from disparate platforms such as malware or network detection, bringing those into clusters based upon multi-systems alerts.

No policy changes were required in the implementation of the platform, with process deviations the most notable shifts: “Moving from reviewing alerts across the range of endpoints to now reviewing a pre-triaged set of alerts, investigating those deeply via whichever source they came from, and only checking the raw source alerts for oddities not otherwise surfaced as a background task,” says Sleep.

“When you’ve got a small team and limited budget, you’ve got to look at what you can effectively do and who are going to be good choices to work with that will help you deliver the rest in a way that you can sustainably do it. Some of the tools you have in place may be able to scale up, but some may only be able to scale up if you put an awful lot of time or money into them."

The main hurdle in the process for Sleep revolved around gauging the value of some of the alert sources and making sure that SOC.OS is effectively tuned so that noise is filtered out, he adds. “For example, our firewall throws out a great number of alerts, but the majority of which are pre-actioned, so don’t need attention. The sheer volume of those and how to get that under control was one of the early challenges. Understanding the alert sources and your environment, particularly high value services and devices, is key from the start.”

Copyright © 2021 IDG Communications, Inc.

Microsoft's very bad year for security: A timeline