Whenever outsiders -- partners or vendors -- are granted access to corporate systems, another wrinkle is added...
to the already complicated paradigm that is enterprise identity and access management. An organization needs to make sure outsiders have access to key systems and data so business runs smoothly and profitably. But, at the same time, care must be taken to ensure unwanted or hostile intruders aren't gaining malicious access into corporate systems.
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.
So, how should an organization ensure secure access for partners and vendors, some of whom work so tightly within a company that they may almost be considered employees? Should their networks be treated as hostile connections that need to be strictly filtered, or should they be added to the standard directory service and treated like regular employees?
The answer lies somewhere between these two extremes. 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.
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.
Secure partner access approaches
There are many approaches to providing secure access to partners and vendors, from simple firewall rule exceptions to encrypted T1 lines and SSL VPN extranets. Here are some ways to choose the best method for securing access from partners and then best practices for implementing that solution.
The first step is to conduct a thorough risk assessment of the potential partner or vendor needing system access. This means assessing the third party the way you would assess your own company -- against your IT security policy. The obvious things to check are their security policies, access management systems, physical and personnel security, firewalls and security of IT infrastructure. This may require a visit to the partner's site to do a follow-up walkthrough.
This may seem burdensome, but remember, your security is linked to that of your partner. If there's a breach at your partner, and it involves your company's data, guess whose name gets in the headlines? The public -- and possibly lawyers -- don't distinguish between a company and its partner in such cases.
Next, review the risk assessment in light of the access required. These are the key questions:
- What type(s) of data does the partner need to access?
- Where does that data reside and on which systems?
- Which systems does the partner need to access and for what purpose?
- How often do they need access? Is it just for quarterly access to update software, for example, or daily access to update customer data feeds?
Partner access scenarios
The best way to illustrate best practices for secure partner access is through some examples. Here are five scenarios in order of ascending risk: a marketing company that needs access to analyze demographic data; a software vendor that needs to send periodic updates to update their software on a corporate system; a supplier that needs access to ship products; an offshore application development center and a contracted call center that needs full access to the customer database.
The marketing company analyzing demographic data is an example of a low-risk situation. Demographic data can't be tied to individual customers, so it can't be used for identity theft. Such data is usually used for market research or sales models. The best approach here, especially if the number of users at the vendor is small -- say, a few dozen -- is to provide limited VPN access. With SSL VPNs, like those offered by Aventail Corp., Juniper Networks Inc. and Cisco Systems Inc., the users are only allowed access to selected systems and data. In addition, access by SSL VPNs can be finely tuned by type of user and application.
A key difference between SSL VPNs and IPSec VPNs, the other type of VPN, is that an SSL VPN connects an individual user to a specific application, while an IPSec VPN connects a workstation to a network. SSL VPNs are Web-based, so they can be accessed from any browser, which means any desktop. IPSec VPNs can also be tuned to restrict users to specific applications and systems, but they offer more unrestricted access not required by users like those in our marketing company scenario.
Another popular product, similar to an SSL VPN, is Citrix Systems Inc.'s NetScaler, which also provides restricted access for remote users to specific applications through a Web browser. Both SSL VPNs and Citrix mesh well with Active Directory, allowing users from partners and vendors to be added with appropriate restrictions.
The third scenario, a supplier integrated into your company, hikes up the risk a notch. The supplier may need access to your inventory systems, but obviously not to customer data. This may lower the risk of identity theft, but not of physical theft. The best option may be an extranet with a secure connection, such as through an SSL VPN. IP filtering or firewall rules should also be used to prevent access of the extranet from a site other than the vendor's. Otherwise, a malicious employee at the vendor could access the site from their home and conduct unauthorized transactions, at the least.
The fourth scenario is similar to the third in that offshore developers, like suppliers, need access only to specific systems; in this case, development environments and application code. But the developers may be halfway around the world in India or China. This means that they have to connect from their own far-flung networks. The connections to your network should be through a segregated network segment on its own firewalls.
As for the fifth scenario, a third-party call center, the connection -- whether through regular TCP/IP or a T1 line -- should be both dedicated and encrypted. In this high-risk situation, where employees of a third party are dipping directly into your sensitive customer data, a multi-layered approach should be used. An SSL VPN combined with IP filtering and firewall rules limit access from the vendor. Two-factor authentication with one-time password (OTP) tokens is a thought, but the high turnover at many call centers makes this option a management nightmare. The options, of course, also depend on the type of application call center employees need to access, whether it's a mainframe green screen or Web-based, for example. Either way, VPN options, both SSL and IPSec, are available.
Finally, as with access for your own employees, all vendor and partner access needs to be logged, audited and regularly pruned to remove inactive users. 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.
About the author:
Joel Dubin, CISSP, is an independent computer security consultant. He is a Microsoft MVP, specializing in web and application security, and the author of The Little Black Book of Computer Security available on Amazon. He hosts a regular radio show on computer security on WIIT in Chicago and runs The IT Security Guy blog at http://www.theitsecurityguy.com.