If you’re searching for a metaphor that helps describe some of the challenges facing digital security managers in large and complex modern businesses, a decommissioned battleship that fought in the Second World War might not be the first idea to leap to mind. But since it was the venue for a RANT Events dinner-table discussion, hosted by SentinelOne, HMS Belfast provided an unavoidable temptation to veteran security architect Chris Joyce.
“HMS Belfast came into service in 1938, and was refitted four times,” the newly installed head of information-security architecture at the Adecco Group said during a lively discussion on technology consolidation. “When it came into service it had torpedo tubes on both sides, but they didn’t survive past 1942 because everything else had got better. It spent over 30 years, going through the Second World War, the Korean War, a whole range of conflicts. And as the threats changed, they had to respond to that.”
Joyce’s point was well made. All that ultimately separates digital security teams from the crews of ships like HMS Belfast is the different physical nature of the tasks they have to perform: the overarching concept is the same. The technology they use must adapt to changing requirements, and systems built to last decades have to be flexible enough to accommodate new subsystems capable of tackling new threats that did not exist – and perhaps could not even be foreseen – when work began on the design and construction of the whole.
For a company like SentinelOne, understanding that user mindset – the hows, whys and whens of security-technology development and deployment – is critical. The opportunity to engage with a high-level group of expert decision-makers was one the company were keen to make the most of.
“I find that there is a bit of a disconnect in terms of how we as vendors and suppliers build technology and how we take that to market and deliver on consolidation, and how people who are purchasing the technology [find] how, in reality, it really works,” SentinelOne senior system engineer Elliott Went said. “You guys have challenges whether it be political, technical or social, with the skillsets you have. Whatever it is, there are disconnects between what we’re selling, what you’re purchasing, how we’re developing and how you guys are actually operating. I want to try and bridge that gap a little bit.”
Defining the Requirement
From the buyer side, the challenges begin at the earliest stage. Defining the requirement is one thing – accepting that compromises need to start being made at even that stage can be the first difficulty that may need to be negotiated.
“You want a house, you’ve got this much money and you want it with this many bedrooms, and you want a garden, and you decide this is what you want: what you don’t do is go and find the best plumber and the best garden designer and the best bedroom designer and the best kitchen designer and let them all loose,” Joyce said. “Because what you end up with is a house that is horrible and doesn’t work and is not what you wanted in the first place, and is probably going to cost you a lot more than you actually wanted to spend.”
Pursuing the analogy further, Joyce suggested that the best intentions of developers and subsystem suppliers will almost inevitably fail to account for what happens when the systems get into the hands of the end user. Perfection may be the aim, but it will never be reached – and with users forced to find workarounds, new solutions get added on top of older underlying systems – and for every problem they solve, another set of challenges get introduced into the corporate network.
“The technologies that we’re using have a history and a legacy,” he said. “Somebody decided at some point in time way back in the past – which is 18 months ago in security – that we’ve assessed things, and this is what we’re going to use for endpoint security, and that gets rolled out. But then there’s another project that comes on and this is what we’re going to use for secure web browsing, and this is what we’re going to use for remote access. And all of this builds up over time.”
Squaring that circle requires careful thought by the end user before they even begin to look for a product or a vendor.
“The way to approach it is always going to be, what’s the outcome? Which is easier said than done,” Went said. “If you can work from an outcomes-based approach – what are you trying to achieve? – that will tell you where you need to go, and what the next step is going to be. That will inform that decision.”
Collaboration and Honesty
There are logical ways in which companies and their security-technology suppliers can work together to minimise the challenges of integration, interoperability and over-abundance of different tools and workflows. But they require a willingness to share the kinds of information that might be considered sensitive – both on users, whose leaders may well prefer that outside entities were not read in to the company’s risk profiles, and on vendors, whose leaderships will generally prefer to tell customers what they think those customers want to hear than to open the books on the progress of ongoing development work. If the technical experts on each side can talk directly to each other, many pitfalls could be avoided.
“If you’re trying to make a decision on a technology that’s right for what you’re trying to achieve, just do a bit of diligence on the history of that technology’s development and get product management involved,” Went said. “Product management aren’t going to lie to you. They’re not going to give you a roadmap they can’t deliver on, because if in six months they don’t deliver on it, you can just turn around and say, ‘I’m not going to renew my one-year contract’.”
The reasons why some companies might not be keen for customers’ security experts to talk to their product-development teams will usually be commercial rather than technical.
“Vendors or product suppliers either acquire technologies because it makes sense to their solutions or they acquire them because they’re going after market share,” Went said. “It’s either a business decision where they shoehorn technology in to tick the box and get the market share, or it is fundamentally a design principle that allows them to get to that point of development, which is still part of that innovation. If you get product managers involved [in pre-sale discussions] you can say, ‘Show me what you’re delivering over six, 12, 24 months; show me the strategy.’ Are they just going to market to bump up their share price, or are they actually developing a technology which is designed to meet outcomes?”
Embrace the Pain
Bringing these threads together will not be easy or straightforward, though. As one of the experts around the table explained, the customer who seeks what is considered to be the best solution may well do all their due diligence and talk to the right people in the vendor organisations, but still end up with a system that doesn’t do exactly what they need. Sometimes, the quest for perfection may get in the way of deploying a solution that works.
“I don’t think people know what they need,” they said. “They might know what they want, which is the best of everything – but what they might need is good enough here, good enough here. Sometimes, good enough means you have to be the best – but if you don’t know what’s good enough for you, then you’re going to be buying everything left, right, and centre and finding out they don’t tesselate, and the cracks between them leave you exposed. And you’re a gazillion bucks in the hole with no return on investment and you’re up in front of the board asking for another 20 million dollars and they go, ‘What have you done with the last lot?'”
Went suggested that, as well as the burden needing to be borne in part by vendors who have to allow themselves to be candid with customers about product-development progress, so users perhaps are going to have to bite a few bullets too.
“You’re delivering a security function, [so] look at the functions you have that you’re delivering,” he said. “Everyone’s going to have different functions in their own business – work backwards from there. Which ones are the most important? You’re going to have to be ruthless. There’s going to be pain. You might be lucky that you have a security leader, a CISO or someone like that, who’s willing to say, ‘We’re going to try and do the best we can with the functions we’re delivering right now, but we’re going to take a step back and maybe have to rip out some, maybe sell some – maybe fire some people.’ That takes a lot of disruption and it takes someone to really be willing to take that step. But the function, the processes you’re delivering on – that’s where you’ve got to start.”