WavebreakmediaMicro - Fotolia
Perimeterless security --sometimes referred to as borderless security --is one of the hottest topics in the security market. Everyone seems to be in favor of it, but the concept as it is being discussed is one of the most dangerous security practices we've had in decades. If you're planning for a perimeterless security approach, you need to understand the danger.
The basic problem with a perimeterless security model is that it's hard to define a policy by saying something is missing. You have to look at what's there instead. The implication of perimeterless security, however, is that employees and BYOD combine with the cloud to erase the notion of the need for data centers, repositories and core applications. Not true.
The changes touted by proponents of a borderless future add up to what could be called workflow security. The idea is that, because work now moves among mobile workers who could be anywhere and applications that could be hosted anywhere, no place can be identified as the border. Also not true.
There's a border between things that must be secured and things that could threaten them, just as there has always been. It's just that, in a virtual world, the border itself is virtual.
We all know virtualization substitutes an abstract resource for a real one. That substitution model also works for users. A mobile user is effectively accessing a virtual on-ramp to a business application or database, using the public internet to provide the connection. If the same virtual substitution model applies to users and resources, then the borderless security challenge can be managed by a common set of practices and tools.
How to secure APIs
Let's start on the resource side where virtualization is best understood. Because the real machine could be anywhere, it's hard to apply the traditional security model that would be located at the border of the data center. Instead, you have to secure the abstraction of the real machine. All virtualization depends on APIs referenced by applications and users for processing or obtaining information. The security border isn't lost; it's simply drawn at the APIs.
API security is a two-step process. First, you have to secure access to the API itself to prevent unauthorized use of the service, application or information resource it represents. Second, you have to secure the connection between the API and the resource itself. Keeping the API-to-resource connection within a private subnetwork that permits only specific connections is the solution to the second part. The techniques for this are widely understood, as they are subsets of the old border security model.
To secure the API connection, the following three methods can be used individually or in combination with each other:
- Connection security. Whatever information and processes might be available, they are available through the network. If the network had the identity of every user, every resource and a map of what connections were permitted, then a major security loophole would be closed. APIs protected by network connection control can be hacked only by someone with proper credentials, and the security tool can journal all access to permit forensic examination of intrusions. Some software-defined WAN products offer this kind of zero-trust connection security and other mechanisms, such as firewalls and access control policies, that can add it to other types of networks.
- End-to-end encryption. If all traffic to a given API requires a security or encryption key and if key distribution is strictly controlled, access to the API is protected. Secure key distribution isn't a complete security barrier if the distribution process is flawed, but there's an ample library of best practices for users to draw on here. Encryption also prevents security faults arising from the interception of access credentials or the direct interception of sensitive material.
- API and service discovery security. The newest and most promising tool is API and service discovery security. An API is typically a service gateway, a means of accessing a process or resource. Since the API itself is the portal to resources, applying security measures to its accessibility secures the virtual border. In modern software, the concept of late or dynamic binding of users to resources is increasingly accepted. This concept requires an API or service be discovered, meaning access to it is obtained from a registry. If that registry access is secure, the API or service is secure and so is the border it creates.
Virtual borders are still borders
Most of the debate on high-level security architectures has come out of the cloud, specifically out of hybrid cloud. A typical hybrid cloud model divides applications into a front-end portion that performs largely presentation functions and a back end that actually handles the transaction processing. The cloud also encourages enterprises to enable components of both the front- and back-end processes to scale across the cloud boundary as conditions mandate. This shift has created the notion of perimeterless security, but what we really have is a virtual border.
Work passes between the cloud and transactional APIs that form the logical, virtual on-ramp to the real business applications, where access to processes and data must be secured. The geographic location of these APIs may shift, but they were and are the essential security border. We can secure them by securing the workflows at the connection level and through encryption, and we can secure the APIs themselves. Those are the same options we've had all along; it's just the mechanism of exercise that's changing.
To fail to recognize a border where security requirements change is to ignore the reality of workflows, hybrid cloud and scalable applications. Perhaps the border or perimeter analogy has misled us; it confined security thinking to facility boundaries at the moment enterprises were launching virtualization commitments that erased those boundaries. Don't let terminology contaminate your security plans. You'll always have borders.