Partner access: Balancing security and
availability
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 thoroughrisk 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 andSSL VPN extranets. Here are some ways to choose the best method for securing access from partners and then best practices for implementing that solution.
There are many approaches to providing secure access to partners and vendors, from simple firewall rule exceptions to encrypted T1 lines andSSL 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 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 second scenario, a software vendor needing access to send
periodic updates, can be handled a few different ways. The update can be
retrieved from the vendor's Web site rather than granting the vendor system
access. Other possibilities, particularly for upgrades to mainframe software,
include encrypted batch feeds or the use of a secure file transfer product like Connect:Direct from Sterling Commerce. The
Sterling line of products can also be used for regularly transferring other
types of files securely to partners and vendors.
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.
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 athttp://www.theitsecurityguy.com.
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 athttp://www.theitsecurityguy.com.
I am thankful to this blog giving unique and helpful knowledge about this topic. Vonex NBN
ReplyDelete