Understanding Relational Security

Information security involves numerous chains and relationships. It is rare to have a security situation handed to us in a nice little box, isolated from the rest of the world. Any given object will almost always have a series of relationships with other networks, applications, events, etc., which will prove to be of great significance to our security considerations. The security of any object is dependent on the security of its related objects, and if we fail to see these relationships, we will be unable to properly address security. I call this relational security.

A server, for example, may be considered safe because it is not connected to the Internet. It is, however, accessible by the administrator's home computer through a dial-up session. The administrator's system itself is connected to the Internet through a DSL connection. Thus, by following this chain of relationships, the server is actually connected to the Internet (see Figure 5.11).

Figure 5.11. Security Relationships.

Following such chains can point out where systems and networks that are considered to be safe are, in reality, vulnerable. Such relationships are commonly exploited by hackers and eventually lead to the compromise of many organizations. Here we will take a look at some of the most frequent problematic chains, including:

• Vulnerability inheritance

• Chained values and risks

• Chained trusts

Vulnerability Inheritance

Probably the most vital and yet most neglected security relationship is that of vulnerability inheritance. The level of vulnerability within any object should be considered in relation to the vulnerability of its related objects. A file share between a secure system and a vulnerable system greatly diminishes the security of the secure system. If the secure system is accessible in any way from the vulnerable system, then, to some degree, it will inherit those vulnerabilities. This is especially true when considering chained paths of entry and chained trusts.

Chained Paths of Entry

Everything in this world is connected in some way or another. We could, for example, draw a physical path between any two locations and any two objects. A castle treasury exists on the same physical ground as the thief desiring access to it. The two are connected by the air, by the earth, by the empty space between them, and by their common relation with the guards and night janitors. In security, we work to recognize and remove or defend such relationships.

In the Information Age, most computers and devices are connected to each other. If any computer is connected to a network or phone line, then we could literally follow a path of wires leading from the inside of my laptop to the inside of that computer. Even if some systems are not connected, we could draw a logical map connecting my laptop to another computer, and then from there to an unconnected computer via exchanged CDs and floppy disks.

Good hackers are continually thinking in terms of such chains. They take an object and think of everything that it is connected to: the Internet, the local network, the phone system, employees, a floppy disk, a printer port, anything. Given so many possible connections, a hacker will simply evaluate the easiest and quickest method of gaining access. Most often, a hacker does not even have to look for such relatioZnships since they simply stumble onto them while exploring an environment.

Modern worms are great at exploiting simple paths of entry. A Web server on the Internet is infected through an infected home user's client. Another client accessing that Web server is infected through the Web browser application when accessing a Web page. A partner is infected though an infected email sent from that client. The partner's boss's PC is infected via an open file share to the partner. The partner's boss's home system is infected by copying some files onto a floppy and taking them home. Then, the boss logs on to the Internet and it starts all over again.

The basic point is that a distinct relationship exists between the majority of computers in the world, including systems that are not even connected to the Internet. Consider all theses common paths of entry that chain systems together:

• Direct or dial-up Internet connection

• Email, instant messaging, and other forms of networked communications

• Partner and vendor network connections

• Modems, remote access, and VPN connections

• Removable media like floppy disks, CDs, DVDs, and zip disks

• Employees that work with multiple systems

• New computers and equipment configured outside the local environment

Any object that has one of these possible paths (which just about every computer system does) is accessible indirectly by all of them. And such chains are not limited to systems or networks. Applications commonly consist of modules that are chained together, some directly accessible and some hidden in code. Many hackers spend a great deal of time exploiting a common application module and then search for all the applications that have integrated that module.

With this concept in mind, it is important to expand our scope of entry points beyond those that are obvious. A firewalled Internet connection does little if home VPN users do not have adequate protection on their PCs. When considering the security of an environment, or any situation, it is a good idea to draw a map of all significant and likely chained access points. Never consider any system safe simply because it does not connect directly to the Internet.

Chained Privileges

When a subject is granted access to an object, that object now shares some degree of risk with the subject. The risk, however, goes far beyond the trust extended to that individual or system. To determine what level of risk we are really dealing with, we must look at the chain of access behind the scenes. Consideration should not only be given to the subject to which we are granting access, but also to the other subjects that have access to that subject. If X grants access to Y, and Y is accessible by Z, then X is somewhat accessible by Z as well.

We could, for example, trust John with access to our treasure chamber and give him the only key. John, however, is accessible by a great many people. His wife will have access to the key if she so desires it, as well as his children and his best friend. John could get mugged on his way into work and thus a mugger would have access. When we give John access, we are giving some degree of access to all of these people.

Similarly, an application that creates and runs an administrator-level process on a server has complete access to the system. This might be considered acceptable because the process is running for a benefit. However, by granting such a high level of privilege to the process, we have also granted privilege to everything with access to that process. When a hacker determines how to access the process through an exploit, he or she may be able to operate with administrative privileges.

Chained access is a big problem within modern organizations, especially with more and more ways to conveniently access systems. Home-based VPN connections are giant issues for corporations because the home system is also accessible by the employee's children, family, friends, and is most often connected to the Internet. Such relationships must be considered whenever making a security decision.

Chained Values and Risks

Relationships are also important to consider when thinking in terms of values and risks. I will not spend a great deal of time discussing this here; we have a whole section on risk coming up. However, when determining where risks exist and what degree of risk is within each object, we must think in terms of relationships. A simple example would be a server room. When determining the degree in which we need to protect the server room and what risk this server room's loss would pose to us, we obviously need to think beyond the value of the room's construction. The room itself may hold minor value to us; whereas the room has many related objects that could suffer should the roof fall in. The room may have servers, routers, WAN links, and people within it; all of these come into consideration when we think to secure the room. This is true for all of objects, as we will see later.

Chaining Trusts

"Trust" is one of those words that should instantly make one think of vulnerabilities and exposure. Of course, we must extend some level of trust to the world around us or nothing will ever get accomplished. It is also true that many day-to-day activities can be handled much easier when we are able to trust someone or something. With every degree of trust, however, there is a degree of exposure that must be considered. Unfortunately, such exposures are often hidden in what I like to call a chain of trust.

When receiving a file through an email from an old friend, there is little concern that he or she would desire to infect our system with a virus, or send us malicious code of any kind. The immediate response is to run the executable he/she sent without question because we trust that individual to not have any motivation to try and attack our system. It is not, however, the trust of that friend with which we must concern ourselves. The fact is that when we trust our friend with this file, we also trust a great many other people with whom we have no formal relationship. We trust, for example, the person who sent him/her that file in the first place to not have put a virus on it. We are also trusting all the applications that our friend has executed since he or she installed the system, because any one of them could have infected this file with a virus. Thus, we are trusting a great many people, applications, and events that could potentially lead us to installing a virus on our system.

Trust in Networking

Most organizations have a lack of concern when attaching their own networks to the networks of trusted partners and vendors. The security concerns of the Internet seem far too obvious, while the concerns of hooking up the network of a local supplier are minimal. Similar to the file sent by the old friend, however, the trust extends far beyond our partner. Any given partner will probably have other connections into other networks as well. They may, for example, have a connection to the Internet, in addition to connections to other partners, customers, and vendors. Are we willing to trust all of these connections as well? Before any foreign networks are connected, it is important to think about the potential chains involved. As a general rule, no external entities should share connections with a local organization unless filtered through a security device.

Many years ago, I was working with a client in the research industry who connected a network to a trusted vendor. This connection had no firewall, only very basic router filtering. After performing an audit, it was discovered that this vendor had similar connections to every major competitor of my client. On top of that, this vendor had an Internet connection without firewall protection! Thus, my client was unknowingly connected to the Internet and all their major competitors without even using a firewall.