Most network operators have their hopes pinned on 5G and IoT, and it’s already clear that a lot of these hopes will be dashed simply because both concepts have been over-hyped. Now, to make matters worse, there’s a growing concern that the implementation of 5G, and support for IoT applications, may have created a significant vulnerability. Even before this story came out, some technologists in the operator community were cautiously sharing their own fears of problems.
One of the network issues we usually ignore is that, in IP networks, the devices are part of the network and exposed as addressed elements, almost like users are. Not only that, it’s often possible to send messages to these network devices. Fortunately, this issue surfaced decades ago and operators have taken steps to ensure that network devices are difficult to attack.
When 5G and Network Functions Virtualization (NFV) came along, they introduced the need to host network functions on a resource pool. That means that the resource pool and functions now generate a potentially wider attack surface, and this is particularly true when function-authoring isn’t highly proceduralized to prevent the introduction of malware or simple vulnerabilities.
At one level, this problem seems related to the problems associated with any componentized application, in the cloud or in the data center, but there is a special problem with network functions because a security fault could expose the network and its users and not just a single application or single user. Cloud providers face a similar risk; if their own infrastructure can be attacked then it might be possible for a badly behaved user to cross over into the infrastructure, and from there obtain information from other users in what they believe to be private application components and databases. However, cloud providers understand the risk and how to manage it, and network operators aren’t sure they do.
Over the last six months, about a third of network operators have commented to me on this problem, and indicated that they’re working out how to audit for risks and how to address them. Obviously this means that they don’t believe they’re completely in control at this point.
Security risks can also be created when network assets are exposed via APIs, either to support partnerships with higher-level service providers as some operators are already planning to do, or to expose them to users and developers. This challenge isn’t unique to IoT, but because IoT has been an ongoing revenue target for many operators, more has been done in the space than in other potential API-based applications.
APIs represent places where a third-party application can call on network facilities, which means that they could be exploited to do something evil if the APIs aren’t fully secured and protected against vulnerabilities that could generate exploits. Many operators will admit that they are used to operating within their own little world, and that the notion of exposing network features in any way is a new one. One operator said that they found eleven potential exploits in their IoT API set when an audit was done. Fortunately there was no indication any were actually exploited.
Even if we dismiss malware and exploits for the moment, there’s still the pedestrian problem of things like denial of service attacks. Offer an API through which any sort of message can be introduced, and you offer a portal through which network traffic and “feature load” can be introduced. Another operator found that their event portal could be used to introduce enough traffic to swamp their IoT servers, for example. Metering of portals through which traffic can be passed is critical.
With the risks associated with hosted functions and APIs so clear, you’d wonder why there haven’t been any widely publicized problems, or any concerted attention given to the potential for those problems to arise. Part of the reason is that operators tend to think of hosted functions and APIs in service terms, and don’t see them the way that cloud providers look at their own business. You need a resource pool to host something, and that pool should be secured as a resource pool rather than per-application. Otherwise, the security is unlikely to be effective. You need APIs to be viewed as invitations to the party, and guests (as we all know) can misbehave once admitted.
It doesn’t help that application security is still a work in progress. You can almost bet that, about every six months, there will be a new security announcement, and that it will purport to be an essential advance in security practices and levels. Operators aren’t used to this sort of moving-target situation, and each new layer of security features adds complexity, to the point where some experts argue that we’re making things less secure rather than more secure when all the operations issues are considered.
Then there’s the big question, which is whether application security measures are suitable for hosted-function security within networks. Interestingly, virtual networking came along (Nicira, now part of VMware) as a means of reliably separating tenants in multi-tenant virtualized infrastructure. Virtual networking is widely used by cloud providers, but you don’t hear much (if anything) about it in network operator applications. The standards bodies have not only failed to consider it explicitly, they’ve also failed to discuss issues of address space usage, management, and assignment. All these things are critical in multi-tenant infrastructure.
As for API security, there is no question that things like IoT APIs increase the attack surface, but this is very similar to the risk that any interface poses for an operator. You can limit DDoS attacks by isolating the originating port, and you could surely do that with APIs as well. The real risk is the APIs that might expose composable features aimed at those who build OTT services, such as proposed by AT&T. Low-level features are low-level because they’re tied more directly to network behavior than customer interfaces, even IoT service interfaces, would likely ever be.
What operators really need to be doing here is opening some discussion, in some formal sense and in an established standards body, to address this question of hosting and API security for network operators. What vendors, particularly virtual network vendors, need to be doing is promoting their own solutions to the problem. That would not only raise awareness, it would introduce some strategies to be tested in the broad market, where the final validation of a solution will always have to be provided.
