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 may exist.
We are already familiar with other ways in which the boundaries of our network become 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, sensitive customer information may need to be shared. At the very least, customer lists are involved, which can be a valuable resource to a competitor. 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. This article discusses outsourcing security risks and makes recommendations on how 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," and it's not always a good thing. If A trusts B, and B trusts C, does A trust C? Unfortunately, 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. Since no trust comes without risk, a minimization of trust allows a business to enjoy the benefit of the outsourcing relationship without necessarily incurring the full extent of the risks. The trick, as always, 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 other companies, does a path exist from the other companies' networks into yours? Even if the vendor has a secured, private connection to each of his customers, that only secures the communications path. What is done to ensure that an attacker cannot hop directly or indirectly from another customer onto your network? You should ask your vendor what they have 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 simply means there is no advertised routing between the networks. While that's a good thing, it doesn't mean an attacker cannot attack your own 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 may 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 this 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 which may cross untrusted network paths such as the Internet. Because of the difficulty of firewalling encrypted tunnelling protocols such as IPsec, carefully chosen application-level encryption tends to 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. Some VPN technologies, such as Frame Relay and MPLS do not employ encryption natively. If the privacy offered by these technologies is considered to be insufficient, consider encryption above and beyond the packet-labelling security of these technologies.
In a "simple" outsourcing situation, such as a customer support arrangement, network segregation is typically accomplished with the creation of a partitioned network area (i.e. a DMZ) which acts as a middle ground for sharing of information with the outsourcing vendor. The partitioned segment should be firewalled in both directions on all network interfaces. Only those services which are required by the outsourcing arrangement should be permitted. If possible, permitted network services should be chosen based at least in part on their security attributes. For example, an architecture that allows you to only 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 company manages another company'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. In the most straightforward case, in which a company opens a hole in their firewall for a vendor to access systems in need of outside support, that vendor now has access to areas of your internal network that are not further protected by internal firewalls. Internal authentication systems are likely to be insufficient because the vendor is now in the perfect position to harvest passwords.
Currently, this risk can be somewhat mitigated with the use of restricted shells or utilities (sudo, etc.) 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. (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.) Be aware that this is only a partial solution which may buy time for automated log analysis of the remote activities to detect and alert on any malfeasance. And, yes, for this kind of outsourced relationship, extensive logging should be a given. This is one aspect of the "principle of least privilege," discussed later.
The simple life
When designing the outsourcing communications infrastructure, try to choose simple, well-known protocols and applications. Unfortunately, "simple" and "well-known" often conflict with one another. We tend to recommend web-based applications because they and the underlying protocols (SSL over HTTP) are fairly well-known and thus have well-known problems that can be dealt with, but web applications rarely fit into the "simple" category. Some SQL protocols (MySQL, for example) certainly meet the simplicity requirement at the network protocol level, but you can still get yourself into major trouble at the query language level--accidentally allowing any sort of query from the Internet via a naïve web interface, for example. RPC-dependent communications require a port-mapper and typically involve a wide range of unpredictable ports. This level of complexity is generally avoided where ever trust boundaries are crossed, such as the interface between your network and the outsourcing vendor. This aspect of security is still an art, not a science.
Other complex protocols tend to have a reputation for being risky. Network file-sharing protocols such as SMB and NFS tend to be dangerous for a variety of reasons. SMB ports are used to access services not related to file-sharing, so it's better to keep these ports closed. Protocols that, once established, are bidirectional can also be dangerous. Note that IPsec (ESP mode) is, ironically, a bidirectional protocol in the extreme: the tunnel allows all IP traffic in both directions and neither firewalls nor intrusion detection systems can see inside the tunnel to block unwanted access. TFTP, (Trivial File Transfer Protocol), isn't quite as simple as its name implies. It is difficult to firewall and does not use authentication. The point here is simply that you should understand the protocols that you allow and block everything else.
And, to reiterate, all remote access should be tracked. Suffice it to say that enough information should be captured to give a good chance of noticing a determined attack or successful compromise as well as support forensic investigations after successful attacks. Good logging can save a company a lot of money and perhaps even public humiliation. Imagine a situation where a company knows that some of its customer data was compromised but they can't say whether it was one customer or 100,000 customers. With laws like the new California Senate Bill 1386 which require customer notification of privacy breaches, good logging could mean the difference between notifying one customer versus notifying 100,000 customers.
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 (e.g. using an administrative account). When circumstances dictate the need for exceptions to this, ensure that privileges are tightly constrained.
- Grant the minimum set of privileges needed.
- Grant them only to specific individuals. Do not allow shared accounts.
- Track all access and changes to privileges.
- Remove privileges promptly when they are no longer needed.
- Automate privilege expiry, if possible.
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. Does your outsourcing partner accept any responsibility if their systems or their access is used to attack your systems? Any risks that cannot be controlled technically must be handled contractually. Remember, your ability to comply with regulations as well as honor your privacy policy is at stake. See the sidebar for a brief discussion of some questions to ask your outsourcing partner.
Congratulations, you have reached the 8th layer
Outsourcing partners that are located in foreign countries or use foreign staff may introduce unique risks. Some countries do not have enforceable security laws on the books. In other countries, anti-American (or insert your country here) sentiment may be high. Other countries have histories of rampant industrial espionage. In this global economy, it is tempting to throw up one's hands and decide that the problem is no longer worth worrying about. As strong as that temptation may be, it would be foolhardy to fail to weigh such 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 in 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 access with temporary passwords that are quickly changed after the work is done, many of the risks are similar, though perhaps not to the same degree. Also, if you use software 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 or 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 web site located in a country without a US extradition treaty?
And then there's paycheck processing, something that is outsourced nearly universally. We threw absolute security out the window a long, long time ago. Outsourcing issues are just the latest wrinkle in an apparently endless string of challenges to the data we are charged with protecting. As always, we must analyze these new risks and weigh them against the cost of keeping the tasks in-house.
Ask the right questions
Though it is unlikely that any outsourcing company is going to give detailed answers to security-related questions, the questions need to be asked. And, simply asking the questions may raise the awareness of the vendor. This non-inclusive list will get you--and them--started.
- What prevents a rogue employee from damaging your customers' systems or networks?
- How are connections to customer networks isolated?
- Are proprietary protocols used, and if so, how are they secured?
- Does the outsourcing vendor's firewall prevent all but those allowed protocols to leave their network? In other words, do they use a "default deny" firewall policy?
- What kind of network connection is required? (Internet access? Frame Relay? MPLS? · How is the transmission path encrypted? What sort of encryption? DES is generally considered too weak. 40-bit keys may be too short.
- What procedures are in place to protect customer systems after a support employee leaves? (Good answer: "We change all passwords immediately." Better answer: "We use one-time password tokens and they are deactivated immediately.")
Each company considering outsourcing a portion of its business will probably have special questions of its own. NOTE: No matter what their answers are, your company must also have answers for these questions. One company cannot rely on the security of another company outside its control. Besides, due diligence demands defence in depth.
Dorian Deane and Benny Jones are both CISSPs and work in security for a large telecommunications firm.
