While in Melbourne enduring the antipodean version of Cisco Live!, The Register's networking desk met veep and CTO Bret Hartman. Here's what he told us about network security, a field he feels is basically doomed. Forever.
Hartman: Part of my job is to think about just that question … it's my job to try to anticipate technology directions, where we should be investing, what customers need.
To your point it's an awesome time to be a security professional. Guaranteed job security. My son wants to be in software, I tell him to get in security, like all kids he wants to write games.
There's a fundamental issue … we as human beings get excited about technologies because they enable all these new and exciting things – wearables, connected homes, all information available, all the time, everywhere. We take that for granted.
As a security person, I recognise that there's a lot of risks. And the risks and the challenges just keep getting bigger.
I've been in this line of work for 30 plus years … people ask me, is it ever going to get any better? I don't really think so.
From the standpoint of the threats to the connectivity – it's not a solvable problem. So the question is “what can we do … to at least have those risks so we can all live our lives as private citizens?”
Given the basic premise that this is a fundamentally intractable problem, and it always has been.
It's all about how do you manage risk so we can get on with our lives.
Hartman: That's inevitable because of complexity. The chance of any of those platforms being secure is zero. There's inherent flaws in pretty much everything out there.
It's just going to happen, just inevitable. You have to start with the assumption that … the software environment is fundamentally vulnerable, and what do we do about it?
Hartman: Open source gets taken for granted – it's free, it works. There's a very big distinction between the functionality of a piece of software, that it works, and the security and trustworthiness.
The functionality of OpenSSL is awesome. It worked, it provided the communication … but there happened to be a few extra features that people didn't know about.
Hartman: That's really impossible. The world is impossible, there's too much legacy software.
You have to say the world is in the state it is – now what?
The “now what?” is a more positive, because you can do quite a bit. If you can have a trustworthy environment even if there are some untrustworthy components in that environment, that's the fundamental problem solved.
Hartman: The more that the IETF does that, it gets in the right direction. But at the same time, you're fighting entropy. There's the natural chaotic state of the universe.
Where the network plays an important piece – where Cisco's role is – we have technology that we can provide to watch over and monitor those untrustworthy components.
You can have inherently insecure components, but because our devices can see the traffic to and from those compromised environments, we can say “this has been compromised, shut it down”.
So if you think of the world of security where you have this massive number of endpoints, and that keeps growing – if you can't rely on the endpoints, you really have no choice but to rely on the network infrastructure to do its best to protect us from all those endpoints.
Hartman: No, we really haven't. That is why I'm at Cisco is that I believe that as the world becomes a more and more connected place year after year, that the only way to reduce the risk so that we can get on with our lives is to rely on that network to help me manage that risk.
To look at behaviour, to look at endpoints – do I trust them? Are they doing things that may be malicious? That may indicate that they've been compromised in some way?
And then do the right thing: isolate, lock it.
Year after year, the network plays a more central role in that game – in the arms race of the attackers and the defenders, the attackers are destroying as many endpoints as they can, and the network plays a more and more important role in being able to defend against those attacks.
Then on the other hand, NFV has as one of its characteristics, that instead of my broadband router being my firewall and being hopeless, I make that device as dumb as possible the protection into the hands of someone who might know how to manage it.
How long does it take to get through that transition?
Hartman: It's certainly in progress today. That transition will never end, I don't believe. It's certainly never going to be the case that all those workloads will move purely to the service providers.
From a security perspective the question becomes “what's better for that enterprise?” Is it better from a risk standpoint – better off with my own infrastructure that I can control, than if I have a third party doing it?
All enterprise are eagerly looking for ways to outsource security, look for ways to manage security on their behalf.
That guaranteed job security – there's such a demand for cyber-security experts and so few, so if you can rely on a third party that does, you're better off.
That accelerates that transition … Cisco have our own managed security services, and we leverage the visibility that we have across all those customers, all that intelligence.
So one of the things that we have that a typical enterprise can't see – if one bank gets attacked there's a good chance that other banks will get attacked.
That helps that transition to functions in the network – as well as saving money and agility, if I believe that the service provider can do a better job.
Hartman: In enterprises – different levels, different standards of what their comfortable with. Some CSOs want to take control, others say “our posture isn't that great – let's shift some of the responsiblity and liability to a third party”.
It's inevitable that more and more of that workload will move to the service provider.
We can do mathematically secure kernels. Do we have the chance to “do it right”?
Hartman: It's been around for a long time, the idea of the inherently trustworthy kernel.
Linux would be awesome … might be a step in the right direction compared to some of the things I've seen.
The problem is that in so many use-cases around the IoT, the things already exist, it's too late. You can't just start from a clean slate.
They're designed … typically security is very low on the priority list. They're designed for flexibility, they're designed for remote upgrades – things that make them less secure.
And some environments, they may be very difficult to access. You can't physically change or upgrade them.
And they're designed much more for availability and reliability than they are for security.
For all those reasons, I'm not optimistic to expect that as the generations of all these things mature, that we can expect them to be inherently secure. Not even a significant subset.
Even things like “do they have enough computational power to do encryption? Can they store a certificate?” There are internet-addressable light bulbs … the answer is no.
The smaller the things get, the less likely it is that they'll be secure, the more that I have to rely on the rest of that infrastructure.
I definitely think – I'm pretty confident that in terms of trends, it will be towards less security in those things, not more.
You can work in that universe of untrustworthy things.
Hartman: And I do think that's … back to focussing on network devices like that – we have a much better chance of improving the security of those devices.
Even in the consumer space, getting that management out of the hands of the consumer, and do it in the cloud. The Meraki product line is that model – simple, click to provision.
Which again goes right back to: the only way to do that is a very network-centric approach to the network.
It's a constant thing, but where is the baseline that says “we are confident, not that the point product is secure” – what is the architectural consideration that makes us say “the system can be considered as is available now”.
Hartman: It's a pretty simple concept. Back in the day, when we thought we could demonstrate and do some kind of a priori analysis of the system. You would do it, deploy it and never change it again.
That model doesn't work.
The view of trustworthiness as a dynamic property of a system, that's changing all the time – there's no notion of static trustworthiness of anything.
Certainly not of an architecture, because the architecture keeps changing – you add components.
So the concept of trustworthiness is to get evidence of that system, on an ongoing basis – a constant stream of evidence that I can look at, that I can validate for me that I'm confident that it's working well enough.
It's a constant stream of evidence rather than an a priori “secure it, you're done” – that's why so much of the security world today is around behavioural notions of security.
The whole industry has shifted away from virus signatures and all that, to behaviour, and that's why. All notions of getting telemetry, we have a lot of it – Cisco has millions of sensors pulling at that telemetry, and we're looking for behaviour.
We look for anomalous behaviour, signs of malware, signs of control. So the secret sauce is in those models, the models of what we look for in terms of behaviour, is based on our knowledge of what the attackers are doing.
The thing about those attackers is that we know they will change – it's the arms race, we have that basic behavioural model, but it keeps evolving as the attackers keep changing.
That's the world of security today. To maintain the trust is to have the right models, that are current, and watch as best we can the threat landscape.
Hartman: “Low and slow” attacks are very difficult. The odds are – that part of the attack would be very difficult to detect, because you're trying to define that slow rate with all the background noise.
But that's not the entire attack – there's the attack chain, that attackers go through a whole set of steps before you get to that point.
Things like initial surveillance, the social engineering … there's a basic set of techniques that any attacker uses, so what you have to do is when you look at suspicious behaviour, cover the entire spectrum.
Then the idea is that if you have enough of the analytical techniques across the entire chain, it makes it really difficult for the attacker to evade all of them.
So – the exfiltration might be able to get out if they're not really anxious to get all the data, and wait a long time, but if I can see them elsewhere – bingo.
That's what we do. The thing about analytics is multiple orthogonal approaches to look at behaviour, to make it extremely difficult for that attacker to hide against all of them.
I'll never believe that any one approach will work. If I cover enough of those, it's going to be really hard. That's the game of security today. ®