The VMware ecosystem has become huge and now encompasses a daunting number of platforms that you don’t even think about, including many in the IoT world. But now, all of these devices have to talk to each other in order to get along, and they do that with Application Program Interfaces (API). Are APIs all secure? If not, rogue processes can slurp off huge volumes of information and port it all off silently. Clearly, APIs are a point of heavy security focus, or should be. But all too commonly API security is something of an afterthought.
VMworld highlights all the ways in which you can move not only volumes of data (see also my previous piece about the lack of data visibility), but entirely different types of information between systems. For example, virtualized technology is being used to control industrial equipment gateways to keep cranes from colliding with other equipment – in real time – or to at least alert operators that doom may be impending.
As the ecosystem becomes larger, there must be a common way in which various machines can request – and sometimes direct – other machines to get or act on information. This is done through an interface designed to be simple for machines to efficiently speak to each other.
"The problem is that the API is often the last item that gets built into a software application."
The problem is that the API is often the last item that gets built into a software application, if at all. It’s easy to see why, as the rush to market – as well as stopping the engineering cash bleed – is the primary imperative in many software projects, and then, oh by the way, we need an API.
While the API is one of the last features to get any serious attention, it is often one of the first used to bolt all the interoperable systems together. This means securing the API was almost certainly not a top priority. It also means that once a series of machines start interacting with each other, it’s very difficult (and often unrewarding) to update that interface, for fear that it will stop communications altogether, or at least break badly.
So while there may be some code review, especially on the core aspects of the program that’s being built, it’s a much more nuanced understanding of the interaction between your program and lots of others who might interact with its information.
It’s somewhat redeeming that many API’s simply produce a small subset of information via read-only interfaces, but sometimes it’s necessary to have API’s control a machine directly. Obviously, this opens a software ecosystem up to new potential threats, which can be hard to contain without significant security experience.
Most projects build an API based on a given set of requirements at that time. But as the needs change, use cases grow, and security becomes more of a factor. So it becomes increasingly difficult to really think holistically about API security, especially if it stands to break lots of other things.
But here we are at VMworld, while we’re thrilled that more and more machines and doodads seem to be talking, we hope that security is in the conversation. Do we always know what the API’s are spewing out? Penetration testing the API layer would seem to be a natural step in development, and while it may not always happen, yet as the perimeter becomes less defined, making sure the API is only sharing information it’s supposed to becomes a more daunting problem. Hopefully, however, more effort will start to be directed towards the API layer, so that everyone can be sure the API isn’t suddenly behaving badly, or doing things no one knows about until it’s too late.
