What if you learned that your closest competitor had an indirect network connection to your company? Would you be worried? If you outsource any aspect of your company's functions, and that outsourcing vendor has your competitor as a customer, an indirect link could exist.
In today's world, we have already become familiar with other ways in which network boundaries have been made fuzzy: remote access from home users; back-end access from customer-facing web servers; out-of-band maintenance access for hardware vendors, and so on. Now there is outsourcing.
Depending on the nature of the contract, in an outsourcing situation, sensitive customer information is likely to be shared. In extreme cases, such as outsourced system administration, all of a company's resources may be exposed to all of the outsourcing vendor's employees. So how serious are the risks of outsourcing security, and what steps should you take to minimize those risks?
Friends and enemies
"A friend of my friend is a friend of mine" is an old concept. In security, this is called "transitive trust," but it's not always a good thing. If A trusts B, and B trusts C, can A trust C? The answer is yes – to a point. For individuals, trust can be desirable. For an organization, trust is a business risk taken in the hope of some benefit, such as less expensive customer support or simplified payroll processing. The trick is to maximize the business capabilities, while minimizing the risks.
As mentioned above, outsourcing companies are unlikely to support only one customer. If your outsourcing vendor has a network connection to your company as well as to other companies, does a path exist from the networks of the other companies into yours? What is done to ensure that an attacker cannot hop directly or indirectly from another customer on to your network?
You should ask your vendor what it has done to protect you from indirect attacks, but no matter how comforting the answer, due diligence demands that you take responsibility for your own protection. Even a claim that each network connection to each customer is completely isolated from the rest should be examined carefully. More often than not, that just means there is no advertised routing between the networks.
While that's a good thing, it doesn't mean an attacker cannot attack your company by first establishing a beachhead on the vendor's network. A good security design assumes the worst will happen and tries to minimize the damage when the attack finally comes.
A bridge too far
Unfortunately, the outsourcing vendor is likely to need remote access to at least some of your customer data. In the case of outsourced system administration, the vendor might not require specific access to customer data, but preventing that access may be difficult or impossible, since the vendor will have administrative privileges on your network.
Risk mitigation strategies for any kind of outsourcing partnership start with network segregation and path security. Path security is relatively straightforward. Encrypt all protocols, if possible. If not, encrypt at least those protocols that might cross untrusted network paths such as the internet.
Because of the difficulty of firewalling encrypted tunneling protocols such as IPsec, carefully chosen application-level encryption may be preferable. What constitutes a "trusted path" should be based on the sensitivity level of the transiting data, as well as the impact to the company in the event that the path is compromised.
In a "simple" outsourcing situation, such as a customer-support arrangement, network segregation is typically accomplished with the creation of a partitioned network area (a DMZ) which acts as a middle ground for the sharing of information with the outsourcing vendor. The partitioned segment should be firewalled in both directions on all network interfaces. This means that only required services should be exposed.
If possible, permitted network services should be chosen, based in part on their security attributes. For example, an architecture that only allows you to initiate connections from the corporate network into the partitioned network is preferable to one that forces you to leave holes open through the firewall.
The keys to the kingdom
One of the more intractable outsourcing relationships is when one organization manages another's internal systems. There may be many good business reasons for doing this, but those benefits must be considered alongside the risks. Even if there is little reason to mistrust the outsourcing provider or its staff, no company can guarantee that it is immune from rogue employees or outside attackers using its network as a stepping stone.
Currently, this risk can be somewhat mitigated with the use of restricted shells or utilities (for example Sudo and its ilk) that limit what user accounts can do. However, it is extremely difficult to give an administrator meaningful privileges without also allowing unintended and perhaps harmful behavior.
For example, Solaris 10's method of system virtualization and partitioning, as well as other developments in hardened versions of Linux may help mitigate this type of risk, but it is unlikely that they will be a panacea.
Remember this is only a partial solution that may buy time for automated log analysis of the remote activities to detect and alert on any malfeasance.
The simple life
When designing your outsourcing communications infrastructure, try to choose simple protocols and well-known applications. While many web applications can no longer be called "simple," at least their problems are well-known and can be mitigated. Often, the confidence you place in a protocol is based more on experience than any formal assessment.
This aspect of security is still an art, not a science. The choice between plain text and encrypted protocols is an interesting one. Good, well-designed encryption can solve the eavesdropping problem, but this also defeats some of your own security mechanisms. IPsec, for example, creates a tunnel that protects all IP traffic in both directions, but neither firewalls nor intrusion detection systems can see inside the tunnel to block unwanted access. As always, try to understand the relevant protocols and weigh the risks against the benefits.
No soup for you
The "principle of least privilege" grants only the minimal set of privileges to accomplish the necessary task. Vendors should not be allowed to execute privileged commands or to operate systems in a privileged mode (using an administrative account, say). When circumstances dictate the need for exceptions to this, ensure that both network- and host-level access is tightly constrained.
Often, it is just a matter of awareness. Your financial systems are protected from your HR systems, and both are protected from your desktop systems. You similarly need to evaluate the trust that you are placing in your outsourcing partner, understand what information and assets they will have access to, and remain vigilant with respect to changes.
How secure is your vendor?
This is a complicated, but crucial, question. For example, does your vendor undergo regular third-party audits? Will it allow you to see the unedited results? There are contractual issues, too. Does your outsourcing partner accept any responsibility if its systems or access is used to attack your systems? Risks that cannot be controlled technically must be handled contractually.
And remember, even if you can't control it, you can log it. Good logging can save a company money and perhaps even public humiliation. Imagine the situation where a company knows that some of its customer data was compromised, but can't say whether it was one customer or 100,000 customers. With laws like the new California Senate Bill 1386, which requires customer notification of privacy breaches, good logging could mean the difference between notifying a few of your customers and notifying them all.
Partners based abroad
Outsourcing partners that are located in foreign countries or employ foreign staff may introduce unique risks. Some countries do not have enforceable security laws on their statute books. Others have histories of rampant industrial espionage. It would be foolhardy to fail to weigh political considerations either when choosing an outsourcing partner, or, once chosen, when deciding how much to spend on the security of the architecture. It is simply another risk to factor into the equation.
Putting it into context
It is important to put the security problems of outsourcing in a larger context. Companies have been allowing vendors into their networks for almost as long as there have been networks. While this access has typically been temporary, with temporary passwords that are quickly changed after the work is done, many of the risks are similar, although perhaps not to the same degree.
In addition, if you use software that was written by others, you have essentially entered into a relationship of deep trust with the software vendor. If you run a Microsoft OS or application, or a Linux OS application, you are trusting everyone involved in the development and maintenance of that product, including even the systems administrators who managed the hosts where the source code was kept. What prevents a rogue employee of a software company from writing code that sends your password files to a website located in a country without a U.S. extradition treaty?
We threw absolute security out of the window a long, long time ago. Outsourcing issues are just the latest in an apparently endless string of challenges to the data we are charged with protecting. We must analyze these new risks and weigh them against the cost of keeping the tasks in-house.
Dorian Deane and Benny Jones are both CISSPs and work in security for a large telecommunications company
