5.1 Security Is Everybody's Problem

Before diving into the discussion of good and bad practices, let's explore this intertwining of application and operational environments. Why are these two aspects of security so closely tied to one another? After all, many modern client-server applications provide a single interface to the applications. What's wrong with authenticating users via that network path, and treating the security of the underlying operating system as completely separate?

Let's take a lesson from modern military doctrine. Direct, head-on attacks against an adversary have been proven time and again to be futile. They are really a last resort. Likewise, monolithic defense mechanisms inevitably yield to dedicated, well-equipped, and persistent adversaries. Thus, it stands to reason that someone attacking your applications would investigate multiple paths of attack and then carefully select the path of least resistance. The chances of that path's being the one you'd prefer—the direct network access to your application—are slim. To put it another way, it's at least likely that your applications will be attacked through paths that you may not initially anticipate. Your job is to ensure that all of the potential paths to your application are equally secured.

What other paths would there be, other than the direct network interface, you ask? Read on...

In the various security assessments we've performed over the years, we've found that there is almost always some means of remote connectivity allowing the administrative staff to perform day-to-day operational tasks on the operating systems supporting the various applications. (In Unix, this might mean that you have remote access to a command shell—perhaps via ssh or, heaven forbid, telnet; under the Windows 98/ME family, it could be an MS-DOS window, or a command prompt window on a Windows 2000/XP system.) While such operations are generally performed from a management console, production application server environments are rarely protected from network connections originating elsewhere within the enterprise. Sure, such administrative access is often necessary (or at least a matter of real practical convenience); but almost invariably it turns out that the application developers never consider the security implications of this access when they design their applications. Of course, they concentrate their security design efforts on the direct user interface to the applications, and more often than not, the security of the administrative access mechanisms are far less secure.

This is bad, very bad! One ramification of this all-too-common arrangement is that someone with bad intentions can attempt to connect to these operating system environments from systems outside of the data center environment where the servers reside. If the attacker succeeds in finding a path affording less resistance than the application interface itself—for example, an administrative login, made possible by a poorly chosen password—he can often achieve complete control, at the operating system level, of the computer on which the application software executes, without ever having to address the application's principal interface. Figure 5-1 shows graphically how an attacker can circumvent application security simply by going around the application interface and hitting directly at the network level.

Figure 5-1. Circumventing application security and attacking through the network

Not likely, you say? We've seen this scenario play out all too realistically more often than we care to remember. No problem, you say, because your application is adequately protected? Hah! At this point, the attacker can cause all kinds of problems for our business application, ranging from unauthorized disclosure of sensitive data through complete denial of service to the legitimate users of the application. This all can occur even if the attacker never has direct access to the application itself!

Even if the attacker has only user-level access to the operating system, the situation can be dire! Why? Because one seemingly trivial error in the file access controls protecting your application, its configuration information, or any associated data can enable the attacker to cause great harm to the assets the application controls.