Partner access: Balancing security and availability
While working on a draft policy for remote access company systems, an article hit my inbox. The title by Joel Dubin is titled Partner access: Balancing security and availability.
This paragraph makes the reader believe that the biggest problems accompanied with remote access are technical in nature. I cannot disagree more. The technology to provide an acceptably secure remote access method is available in the form of VPN technology, and may companies augment it with strong two-factor (often token-based) authentication. Especially when monitoring procedures are in place and the token is not given to the vendor directly, but is only released after a phone call, VPN connections can be made relatively secure.
The article goes on and later states:
What I am missing in this paragraph is the relative importance of the data that is being accessed. That may be implied in the type of data (first factor), but in my opinion, it is the single-most important one. All the others are merely a way to assess the level of importance of that data for the organization.
Fortunately, the author shares this view:
After this observation, the author goes into more detail about different technical methods to establish a VPN connection, and the benefits and drawbacks of some of then. Sadly, the article wraps up with a view that I do not share:
I would have much preferred a different ending: Allowing partners access to a company's internal systems should always be subject to an assessment: which systems will the partner need to access, how important are these systems (and the data contained in them) for the organization, and do the risks of allowing outside parties to interact with these systems outweigh the added benefit that is gained from granting such access. Once these questions have been answered, it can be decided in which way the partner's access be controlled and monitored most effectively. Finally, partner access to a company's internal systems (either from a remote location, or supervised on-site) should be subject to re-evaluation at regular intervals.
In reality, secure partner access is just an extension of existing access management for mobile and remote employees -- but with a few twists. Employees are already enrolled in the organization's directory service, whether Active Directory, LDAP or some other system. They're company insiders who are already part of the network, not outsiders from another network with a different IT security set up.
This paragraph makes the reader believe that the biggest problems accompanied with remote access are technical in nature. I cannot disagree more. The technology to provide an acceptably secure remote access method is available in the form of VPN technology, and may companies augment it with strong two-factor (often token-based) authentication. Especially when monitoring procedures are in place and the token is not given to the vendor directly, but is only released after a phone call, VPN connections can be made relatively secure.
The article goes on and later states:
It depends on three factors: the type and amount of data the partner needs to access, the number of users the vendor needs to access that data and the risk level of the third party.
What I am missing in this paragraph is the relative importance of the data that is being accessed. That may be implied in the type of data (first factor), but in my opinion, it is the single-most important one. All the others are merely a way to assess the level of importance of that data for the organization.
Fortunately, the author shares this view:
Before considering these factors though, it should be made clear that the decision ultimately should be driven by business requirements, not security requirements. Security requirements should be dictated by the business need, not the other way around. There is no one-size-fits-all approach to secure partner access. If the business needs it, then design the right level of security to be wrapped around it based on a thorough risk assessment of corporate partners.
After this observation, the author goes into more detail about different technical methods to establish a VPN connection, and the benefits and drawbacks of some of then. Sadly, the article wraps up with a view that I do not share:
From this perspective, secure partner access is no different than regular employee access. It's nothing more than creative use of VPNs, dedicated connections, IP filtering and encrypted connections.
I would have much preferred a different ending: Allowing partners access to a company's internal systems should always be subject to an assessment: which systems will the partner need to access, how important are these systems (and the data contained in them) for the organization, and do the risks of allowing outside parties to interact with these systems outweigh the added benefit that is gained from granting such access. Once these questions have been answered, it can be decided in which way the partner's access be controlled and monitored most effectively. Finally, partner access to a company's internal systems (either from a remote location, or supervised on-site) should be subject to re-evaluation at regular intervals.