Security Challenges in Distributed Component Environments


Traditionally, computer security has worked effectively in systems in which sensitive data can be isolated and protected in a central repository. Distributed components have exactly the opposite philosophy by making distributed data widely accessible across large networks. Simply put, the more accessible data is, the harder it is to protect. Ordinarily, it’s a good idea to keep your crown jewels locked up in a vault. Distributed components encourage you to pass them around to all your friends for safekeeping.

The traditional notion of computer security is embodied in the concept of a trusted computing base (TCB), as shown in Figure 17.1[1]. The TCB consists of the hardware and software mechanisms that are responsible for enforcing the security policy, which defines when a user may access a resource. The TCB must be:

click to expand
Figure 17.1: Traditional trusted computing base (TCB).

  • Always invoked (nonbypassable)

  • Small enough to be thoroughly analyzed

  • Tamper-proof[1]

The TCB is usually implemented within an operating system that is under strict configuration control. This architecture permits very tight security because the TCB is the mediator through which all user accesses to resources must pass. Everything within the TCB is trusted to enforce the security policy; everything outside of the TCB is untrusted.

Distributed component systems, on the other hand, have the more complex security architecture, as shown in Figure 17.2[1]. Security functionality (the shaded areas of the diagram) in component systems is distributed throughout the architecture rather than residing in a central TCB. Because distributed component systems are frequently heterogeneous, security may be implemented differently on different platforms. Security might be enforced by the application components, middleware, operating system, hardware, or any combination of these. Some platforms may contain a great deal of code that is trusted to enforce the security policy, whereas other platforms may have very little.

click to expand
Figure 17.2: Distributed component security architecture.

Distributing security in this manner means that a particular distributed application may be secure, but that fact is hard to confirm. In a distributed component system, the combination of all of this trusted code together theoretically embodies a distributed TCB. But is this really a distributed TCB? Probably not. It may be tamperproof and always invoked, but it may not be small enough to be easy to analyze. That’s a concern, because if you can’t analyze the system, you can’t be at all certain that your valuable data is being protected.

Some security traditionalists believe that it is not possible to build highly secure distributed component systems. There is a question, though, of whether a TCB model is even appropriate for distributed component environments. Although TCBs are great for enforcing security, they aren’t sufficiently flexible to support component-based systems.

The flexibility and openness of distributed component systems make security administration a real challenge. Systems managers with experience administering security in Unix or Windows NT environments know how difficult it is to get it right. Many security attacks on these systems are not due to obscure security vulnerabilities, but to inadvertent administrative errors, or “leaving the barn door open.”

Several other characteristics of distributed component systems also complicate security enforcement. The systems are:

Dynamic: Component systems are designed to be dynamic, allowing new application components to be created on the fly. Components can play both client and server roles, and can interact in multiple and unpredictable ways. This means that security policies must also be dynamic, adding complexity.

Exposed: Many distributed component systems are designed to work over the Internet or large intranets. Data going over networks is subject to packet-sniffing interception.

Layered: Systems consist of many security layers (applications, middleware, operating system, hardware, and network) that must fit together.

Multienterprise: Distributed component computing allows the sharing of information among enterprises. Enterprise security policies will be different (for example, between a hospital and a bank), which means that data sharing requires translations between enterprise policies[1].

Configuring and administering security for distributed component systems is potentially far more complex than for a traditional system. Without special tools, security has to be administered manually for each layer independently, leaving room for mistakes and inconsistencies. For instance, an application may correctly confirm that a loan officer is authorized to access a record before allowing changes. However, if supporting operating system calls have not been set up with complementary file permissions, access protection is not complete. The challenge is to create an environment in which the complexity is minimized, ensuring that security administration is enforced automatically and consistently.




Electronic Commerce (Networking Serie 2003)
Electronic Commerce (Charles River Media Networking/Security)
ISBN: 1584500646
EAN: 2147483647
Year: 2004
Pages: 260
Authors: Pete Loshin

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net