IP Sec or Application Security

IP ESP and AH are applicable between two IP addresses. If you do not want to apply IPsec to all of the traffic running through your firewall, consider application-level cryptography. A number of alternatives are available. If your application runs on TCP/IP sockets, you can use SSL libraries available from Security Dynamics, Inc. Kerberos V5 and DCE both ship with Generic Security Services API (GSS-API), which is a set of library routines that provide application level security services including authentication, message integrity, and privacy. Finally, if you are writing applications on NT, the Microsoft Crypto API services are the best choice.

You should know that a number of vendors have signed up to support the Common Data Security Architecture (CDSA) initially proposed by Intel. The idea behind CDSA is to deliver a set of neutral security APIs that can be used for authentication, privacy, integrity, and nonrepudiation. The goal is to make available to vendors only one set of programming APIs that insulates developers from details of the underlying security implementation.

How Complex Is Your Network Security?

In Chapter 1, “Intrusion Detection and the Classic Security Model,” you were introduced to the idea that security models are implemented in software to provide services for enforcing a security policy. Regardless of how complex a particular solution might be, you eventually can identify the subjects and objects and how the reference monitor makes access control decisions. If multiple security models are in use at your site, each model is responsible for controlling security for a specific set of subjects and objects.

Network security is complex because so many different security models are in operation at any single moment. Traditional operating system network services work with familiar concepts such as users and groups. For example, the network applications FTP and Telnet use the operating system authentication subsystem before allowing access to a system. Not all popular network services follow this pattern. Web servers that run HTTP protocols over TCP/IP introduce their own notions of user, group, file system, and access control. Other client-server applications increase complexity by bringing along additional security models, including database management systems frequently used for critical business processes.

When you write a home-grown client-server application at your site, chances are that you will be crossing a number of security boundaries. Client and server programs have a security context meaningful to the operating system. They are associated with UIDs and GIDs, are stored as files in the file system, and are regulated by access control rules for IPC or sockets. As soon as you start worrying about how clients and servers communicate securely across a network, it’s likely that another security context is introduced, such as the cryptographic framework you instrument your applications to use. The more back-end business systems the applications interface with, the higher the probability that a number of security models will be active.

A good example of this is the typical Web e-commerce application. To begin with, end users connecting to your site probably have an X.509 certificate signed by an authoritative source. The public key and private key associated with this certificate are used for secure connections to your site. The software products that generated the certificate constitute one security domain. On your end, the Web server is running on an operating system. That would be two new security contexts, one for the operating system and one for the Web server as described. The Web server probably has some client code that connects through a firewall to the back end business databases. Depending on how picky you want to be, that is either one or two new security models. The database manager definitely implements its own reference monitor, and the firewall also introduces a security model, although it overlaps some with the operating system’s model.

When a hacker or a security expert looks at this kind of setup, they think “Wow, look at all the places someone can screw up security!” The first problem is that so many different models have to be administered. Users and groups must be managed, access control rules set up and modified, and client-server security established. To a hacker, this setup is just more opportunities for someone to configure the security policy incorrectly. Next, at each security model boundary, something interesting happens. Requests by subjects from one model are satisfied by subjects in another model acting with on behalf of semantics. If the mapping between the boundaries is well defined, no security leaks will exist. One frequently seen fiasco includes a database gateway application running on a Web server in which the gateway is given unlimited access to the back end database.