Managing Network Security

Technical Protection for the Joint Venture

by Fred Cohen



Series Introduction

Over the last several years, computing has changed to an almost purely networked environment, but the technical aspects of information protection have not kept up. As a result, the success of information security programs has increasingly become a function of our ability to make prudent management decisions about organizational activities. Managing Network Security takes a management view of protection and seeks to reconcile the need for security with the limitations of technology.



Introduction:

In today's enterprise computing environment, there is increasing need and pressure to form temporary collaborative computing environments wherein a limited portion of the expertise available in two or more companies is joined for the purposes of some project. As a further complication, the joint venturers are often competitors in closely related fields. In this environment, there is a substantial need for rapidly deplyed collaborative computing environments that are mutually secure and yet permit authorized sharing.

Many companies have been so pressed to provide adequate cooperation that they have cut corners in terms of security and simply interlinked the partner internal networks, but this leaves a gaping hole in which the team mebers can intentionally or accidentally harm each other. An example of accidental harm that may result in substantial liability is the exploitaiton of one partner's network by a third party attacker to break into the other partner's systems. It seems clear that it is in the best interest of both parties to secure both their network and that of their partner.

Many companies have tried to create internal enclaves in which team members can use select services, but again this creates many difficulties. For example, within the enclave, which may be at the other partner's site, you may not be able to access your corporate email. The goal of the joint venture is to take full advantage of each partner's assets in order to produce the result, and any inhibition of this capability is a potential blockade to your success. Furthermore, users whose job is to get the joint venture to work are rarely willing to sacrifice much effort in order to accomplish desired security.

Last week, I was at a client's site (the client is also a regular reader of this series) discussing this very problem, and I thought it would be beneficial to discuss some of the solutions we discussed.


The styles of collaboration:

There are several distinct styles of collaboration in widespread use. They are, to a first approximation:

Each analogy has it's place in today's information technology. The embassy is typical of joint ventures where your experts go to their site to help work on a mutual problem requiring your confidential tools. The enclave is typical of joint ventures that take on a life of their own. The enclosure is typical of a remote maintenance situation where you have the vendor maintain a software package from afar. Each is widely experienced, has unique challenges, and requires a solution that can be put in place for any desired period of time.


Insiders Don't Need To Get Around Controls:

They have access anyway! I have seen many occasions where the first suggestion out of someone's mouth is to set up a sepcial set of access controls for the insider who is working in an embassy or enclave. The notion is that we will allow our partner or our people to use the facilities, but provide access controls so that they can only use the authorized parts of our environment for their joint effort.

The real problems with any such solution are numerous, but they boil down to only two major areas of concern. The legitimate employee needs unfettered access to do their job, while trying to protect each asset required to do the job so that the outside can enter but go nowhere else is too expensive and contrary to normal work methods to be effective in most current environments. In either case, they are adding unnecessary barriers to productivity.

Perhaps the most important thing to notice is that the insider has access to the inside information. If you create enough impediments to getting their job done, they will start to feel like an outsider, they will be tempted to break the rules so they can get the job done, and they will become disgruntled. All of these are bad things that we don't want to have happen.


Removing the Barriers to Productivity:

I have a standard joke about a new business I am trying to start. The business is to be named something like 'unfettered results' and our business saying is 'removing the barriers to productivity'. Our stated goal is to remove all those access controls, passwords, and other things that get in the way of productivity. Computer security? It gets in the way. Access controls? Another barrier. Badges? Just so much more paperwork. It's a very fun game to play, and the freightening thing is, almost everyone in business starts to salivate when you tell them that you can improve their productivity and lower their costs by simply removing these barriers. Nobody ever seems to mention anything about risks.

So there you have it. The real objective of business is to be productive, and anything that gets in the way is a barrier to success. The real objective of information protection in a business environment is to prevent harm at no cost without creating any barriers to productivity.


Without Physical Security There Is No Security:

Somewhere along the line, I inevitably have to give them the bad news. I could probably make a fortune by not telling them this part, but for some reason I figure I have to - and it always gets in the way of completely unfettered access. I tell them, that you cannot have effective information protection without effective physical protection.

The conversation usually starts with an architecture I approve of and goes something like this:

A discussion then follows about how we might put in a special sensor and a special key and lock system and so on and so forth, and every time, we eventually get down to having the employee who is working with the partner play an active role in security. The response is always something like You can't expect our people to do that! I tell them that we could emplant a device in the employees body that makes the authentication transparent and automatic, but so far, none of them have been willing to go that far. We talk about biometrics, but few of them are willing to require a thumb print for access, and even if they do, they always want to have one authentication and then unlimited use. But the employee doesn't ever sign off in these systems and they have to sleep some time. (This last point has occasionally met with resistence - the part about not forcing employees to work 24 hours a day, 7 days a week.)

Eventually, they give in. If we are to have security, we need to have some physical security. If we can't secure the room, we have to secure the critical pieces of technology. Physical security requires some ability for our people to get access and their people to be refused unless our people are watching. That means physical identification that's hard enough to defeat, and that means - you guessed it - a barrier to productivity.


The Embassy, the Enclave, and the Enclosure:

Once we have declared defeat and realize that we are going to have to have a barrier to productivity, the question is: 'How high?' The answer has everything to do with risk management, but you don't need to do a full fledged risk management every time you make a decision about partnering. Instead, we have some stock solutions rigged for the three most common situations.

The Embassy

In the embassy, the stock solution includes two LANs and an intervening trusted system.

The way the embassy works is that our users can place information on the file server from their systems for use by our partners and they can place files there for our use. Our people can use our tools on these shared files and their people can use their tools on the shared files, but we cannot use their tools and they cannot use our tools In this way, our people control what information is given to the partners and theycontrol what information is given to our people, but neither gains access to the others' systems.

In order to provide additional assurance, a range of technologies can be applied to assure physical security of our embassy when our people are not present, and technical safeguards can be used to detect tampering with physical connections or the devices we chose to locate in the embassy. Our people have unfettered access and total control over what is shared from our viewpoint and their people have similar controls from their side of the gateway. If more than two parties are involved, a file server with an appropriate number of interfaces and an appropriate number of embassies can be located in close proximity.

The Enclave

The enclave works just like the embassy, except that each team is in charge of its own physical security. This is a somewhat more risk circumstance in that we cannot easily attribute break-ins to the host organization, but it is otherwise equivalent.

In the enclave, the parties join forces to rent some space in neutral territory. They take joint responsibility for the overall physical security, but each takes their own precaustions as they see fit for protection of their own assets. In the enclave, each of the member organizations has its own embassy, and to the extent appropriate, these embassies communicate back to the member organizations. When sharing is desired within the embasy, a file sharing device such as the one defined for the embassy is chosen.

An alternative architecture for the enclave, and one that is often preferrred by the participants, is a joint development LAN in which all of the collaborative work is done. This LAN is considered to be in a demilitarized zone (DMZ) between the two parties and is used for things that are part of the joint venture and not otherwise proprietary to the parties. In some cases, the DMZ may even be connected to the Internet or other networks as needed to get the most work done in the least amount of time. One of the principals of the DMZ is that it limits the loss of each party to the total investment in the joint part of the enclave. As such, it may be a good business decision to make this area as wide open as possible and to take the "run faster" approach to succeess in this limited domain.

In the DMZ model, each participant wishing to have communications back into their own infrastructure for their own uses, may do so at their own risk. This is normally done through the use of a file server or similar but more limited transfer mechanism, as in the embassy.

The Enclosure

In the enclosure situation, a very different approach is normally desired. Since the foreigner is granted access to a system in your trusted enclosure, it is impossible to prevent them from directly affecting information you use. The risk in this case is somewhat higher, so this situation is only used in circumstances where there is a trusted third party performing limited tasks. An example might be remote access for systems service or support. The risks here are high, so it is important to have a proper contractual relationship, it is helpful to have deep pockets on the visiting partner's side, and it is critical to keep accurate records of all activities.

A typical way to provide for effective protection in the enclosure case is to allow remote access through a dial-up line or leased line over an encrypted modem, or over the Internet using an encrypted IP tunnel that is permitted to access only the specific ports on the specific machines that require access in order to allow the business function to proceed. While this provides a connection, it is not the end of the protection effort.


Limitations:

Each of these technical solutions provides some added protection while permitting joint efforts to proceed largely unimpeded, but they all have a common vulnerability that seems to be the most common vulnerability we find in all systems today. The limitation is that we cannot effectively limit content, and it is the same issue that largely underlies the virus problem, the major unsolvable problem with firewalls, the major unsolvable problem with intrusion detection systems, and the major benefit of general purpose computing. It is Turing capability that brings us the nearly unlimited flexibility of modern computers and Turing capability that limits our ability to assure their proper functioning. This two edged sword can be largely mitigated by careful design, careful procedures, training, awareness, and so forth, but it can never be completely eliminated if we want the benefits of general purpose computing and sharing.


Summary and Conclusions:

Businesses sharing information need fast, simple, and effective ways to allow for sharing with partners while providing a reasonable level of protection against the risks of sharing. Three common modes of interaction are the embasy, the enclave, and the enclosure.

While none of thes solutions are ideal, in the sense that they are all vulnerable to content-based attacks and all limit the free flow of information to some extent, they provide a tradeoff that allows more information to flow more rapidly than many of the available alternatives, while producing about the same level of risk as exists from current Internet firewalls and similar security mechanisms.


About The Author:

Fred Cohen is a Principal Member of Technical Staff at Sandia National Laboratories and a Managing Director of Fred Cohen and Associates in Livermore California, an executive consulting and education group specializing information protection. He can be reached by sending email to fred at all.net or visiting /