Planning Application Security

The Internet is an established vehicle for personal, communal, and commercial interactions. All forms of information from personal e-mails to high-value financial transactions are dispatched over the Internet. It is a known fact that information constitutes what is arguably the most valuable asset of an individual or an organization. Protecting these assets is almost as important as the tasks or business they are intended for.

System security is an extremely sought after "ingredient" in any mission-critical enterprise application, almost at par with the coveted application feature-list. Security is also very unique in that it is one of the most pervasive components in an application. This implies that security isn't necessarily limited to a particular part of a system, such as its presentation, business logic, database, servers, or networks, but in fact applies to all aspects of the system. It is therefore crucial that any design or analysis of a system take a holistic approach to addressing security rather than that of a modular one. Though security may be realized differently in various parts of the system, all security operations must seamlessly tie together in order to achieve a manageable and secure system. Securing an enterprise application, a complex task in many regards follows three basic tenets (outlined in this section and the next).

Tenet I: "It is a doctrine of war not to assume the enemy will not come, but rather to rely on one's readiness to meet him; not to presume that he will not attack, but rather to make one's self invincible." (Sun Tzu, "The Art of War")

Security in electronic commerce is vital for every business application. It is foolhardy to assume that information sent and received over the Internet will not be listened to, intercepted, or manipulated in any way, shape, or form. Instead it is always considered prudent when security requirements and security limitations of the data and operations of an enterprise application are thoroughly understood and communicated to the appropriate stakeholders.

Identifying Security Requirements

It is very important that all enterprise applications, internal or external, client-facing or back-office enabling, must go through constant "security preparedness" analysis during their entire project life cycle. These reviews and analyses allow stakeholders to become aware of the capabilities and vulnerabilities of the system. These reviews are not necessarily meant to build a "perfect" defense but rather to increase one's preparedness by determining the following:

• Risk estimation A deterministic estimation of the system's overall security scope (intranet, extranet, Internet, protected back-end, and so on) and specific measures taken to ensure against relevant attack scenarios provide an accurate picture of the system's risk exposure. An untainted declaration of known security limitations and vulnerabilities provides stakeholders with information necessary for making an informed decision on the acceptability of the system given the sensitivity of data and operations involved.

• Damage estimations Damage estimations provide the "silent" scenarios wherein damage (financial, political, opportunity, and so on) caused by a breach in the system is summarized and estimated. This information is critical to allow organizations to be prepared for eventual fallouts (financial, legal, public, and so on) if and when their systems are compromised.

• Security breach identification and recovery procedures Recovery procedures provide organizations with guidelines on how to identify and recover from a security breach quickly and effectively. These procedures must also provide a recovery process detailing the manner in which to recover from the identified breach in the shortest possible period of time. This may include creating a patch, and subsequently testing and deploying it in the production environment. Severe, unexpected compromises in system security may require that the system (or part of it) be taken offline.

• Evolutionary requirements From a security perspective, it is important to understand the evolution of the enterprise application or system being built. Major security concerns that may need to be addressed for an evolving application include the following:

  • Communication scope (intranet, extranet, Internet) and encryption requirements

  • Establishing partnerships, trust relationships, and identities

  • Authorization requirements

  • Resource protection and access control

It is essential that an application's security design is adequately flexible and extensible in order to incorporate demands made during "foreseeable" future evolutions of the application. This will increase the trust level placed in the system, ensuring that it can effectively meet the security demands made by an ever-changing environment of trusted relationships.

Tenet II: "There are no invincible countries, no foolproof defenses and no impregnable fortifications. Those who passively wait to be attacked are vulnerable." (Sun Tzu, "The Art of War")

The term "secure" is a relative concept and hence the notion of "perfect security" is non-existent. Instead it is more practical to investigate what constitutes a "secure-enough" environment for the enterprise system being built. The following aspects (among others) must be taken into account when providing such an environment:

• Resources Building a secure-enough system has a lot to do with resources and often comes with a price. In order to be secure enough, it is necessary to stay one step ahead of the resources committed toward malicious acts. It requires a talented and seasoned skill set, top-notch hardware (often required to overcome security-related performance bottlenecks), and people knowledgable about existing security processes within an organization. Such resources are either expensive and/or difficult to find.

• Risk exposure The scope or exposure (intranet, extranet, Internet, and so on) of the system being built is an important factor in building a secure-enough environment. Standard technologies (such as SSL, digital signatures, shared-key encryption, public key infrastructure, and so on) can be selected once basic scope requirements have been identified.

• Trust A notable limitation, but yet an ever-present component of anything related to securing a system is trust. No matter what the nature of defense, or the amount of resources committed to designing and installing secure technologies, there are certain entities that must be trusted.

Since trusted entities are critical links in determining the overall strength of a defense, it is crucial that usage of such trusted technologies or relationships, their capabilities, and the processes that manage them are clearly documented and communicated to the parties concerned. For example, SSL, a technology that is often used for mission-critical Internet applications forms the basis of trust for all secure communications.

Tenet III: "If you know your enemy and know yourself, you will not be defeated in a hundred battles." (Sun Tzu, "The Art of War")

An important aspect of designing secure-enough systems involves a good understanding of possible attack scenarios and how those malicious acts, if committed, may exploit the system. This critical and strategic observation consists of two fundamental aspects :

• Internal and external system boundaries There are many interaction points in an application. Some interactions points in the system are externally facing (that is, interact with computing services or users outside the organization that owns the system) and some are internal. Each such interaction point must clearly be documented from a security standpoint, including its relevance to the system, its sensitivity, and most importantly the processes put in place that manage them.

• Assailants and attacks A thorough profile of possible malicious acts that target internal and external interaction points as well as the assailants that orchestrate them is needed. Such profiles detail, among other things, an assailant's capabilities, resources, and their ability to inflict damage using information appropriated through unauthorized means. As stated previously in Tenet II, securing "everything" from "everyone" is an impossible task. Thus, such profiles, examined in the context of the sensitivity of operations involved, help determine whether the measures taken to protect the system are sufficient.

Functional Classification of Application Security

Security-related issues cover a wide range of subject matter from network hacking and denial-of-service attacks to managing a user's network identity. Covering all such aspects in detail would require its own book and is not the goal of this chapter. This section provides a perspective on how application security can be functionally classified under distinct areas of responsibilities. Security at the application layer can be logically partitioned into three primary areas of responsibility, or zones, each handling a specific set of tasks that contribute to the overall security of the system. These three zones (shown in Figure 3-2) are as follows:

• Channel security

• Network identity management

• Authentication and authorization

Figure 3-2: Application security zones

Note

These zones are logical partitions based on areas of responsibility and are not related to the physical infrastructure in which they are deployed.

The rest of this section provides a high-level overview of each zone, following which we discuss technologies applicable to these zones.

Channel Security

Channel security addresses how the communication between various entities on the Internet takes place. The most commonly used technology is Secure Sockets Layer (or SSL), which preserves confidentiality and integrity of data between communicating endpoints. Certificates are also used as part of SSL communication to establish the identity of the communicating endpoints on either end of a secure channel. Message security addresses the mechanisms that may be applied to discrete pieces of information or documents that are passed between communicating endpoints. In order to preserve data integrity, authenticity, and non-repudiation of the information exchanged, digital signatures (discussed further in the section "Digital Signatures") are used.

The following table provides a summary of the various technologies employed in this zone and their use.

Mechanism	Channel Security	Channel Message Security
Confidentiality	SSL, TLS
Data integrity		Message transformation algorithms and message-digests
Authentication	Client-and server-side certificates for transport-level encryption
Data origin authentication		Certificates used for digital signature verification
Non-repudiation		Digital signatures

Network Identity Management

As more and more people, communities, and businesses use the Internet as their primary means of interaction, the notion of an identity (just as in real life) becomes a crucial part of online communication. Simply put, an identity consists of a set of attributes that uniquely defines who you are as a system user and how you are represented in various system interactions. Albeit, the concept of a user identity may sound simple, however, defining and establishing identities for sophisticated multiuser enterprise applications is a task much easier said than done. Couple that with the possibility that identities may need to be "portable" in order to be shared among various networked services and you have a complex problem at hand. Today, a person's Internet identity is strewn across various entities connected to the Internet including portals, business services, organizations, and so on. This fragmentation of information results in "closed," inextensible and isolated relationships.

Federated network identity is the key to addressing the issue of identity fragmentation, and in doing so, it enables businesses to realize new opportunities and explore revenue potential in relatively new economies of scale. In this world of identity federation, a user's online identity, personal profile, interests, preferences, purchase history, and so on, can be administered securely by the user and privately shared with trusted organizations of the user's choosing. The natural means to realizing this goal will first involve the establishment of a standardized method to create, disseminate, and manage simple federated identities across multiple identity management systems (a.k.a. identity providers) based on commonly deployed technologies. Project Liberty (http://www.projectlibery.org), an alliance consisting of a broad spectrum of industries, envisions such a world in which businesses and their users can engage in virtually any type of interaction without compromising the privacy and security of their identity. An overview of the Liberty 1.1 architecture, and the vendors implementing this specification, is provided in section "Liberty Architecture."

The network identity management zone is the basis for conducting most system transactions. It is this zone that determines who you are and defines what you can do. The identity of a user must therefore be established in this zone before any application services can be accessed, and thus it is crucial that mechanisms used in this zone are protected, isolated, and managed by clearly defined processes. The network identity zone is often a cornerstone for sophisticated identity-related operations. For example, during user logon

• The user submits his/her credentials via a secure channel for authentication.

• User authentication is performed by retrieving the user credentials stored within the identity zone and validating it against the one submitted by the user.

It is therefore obvious that a breach in the network identity zone may prove fatal in that the system will be unable to distinguish a valid user from a malicious one.

Authentication and Authorization

The authentication and authorization zone have two main functions in the system—the first being that of establishing the authenticity of user credentials (authentication) and the second, "translating" a user's identity into permissible actions (authorization). The authentication and authorization zone is more a "gatekeeper" to system resources and data rather than an "administrator" to the information used to access its protected assets. This zone consists of polices, rules, and processes that protect resources and ensure that system operations are executed securely in a manageable and consistent manner. Authentication and authorization functionality are complex and nontrivial but are unarguably a crucial component in almost all enterprise applications. They often are combined with network identity solutions and offered as a centralized, integratable service to allow for improved manageability. It is thus recommended that functions of this zone be designed and built based on established standards to increase extensibility and preserve vendor neutrality. One such technology is Java Authentication and Authorization Service (JAAS), which is discussed in the section "Java Authentication and Authorization Service".

Authentication is a relatively simple process since the tasks involved are few and bounded. After all, only a finite set of credentials (for example, username and password) are validated to establish user identity. Thus the authentication module need only be designed to handle those specific types of credentials.

Authorization, in contrast, requires a completely different approach. This is because authorization in general is involved in a significantly larger number of transactions whose design is closely tied to business processes and regulations. This, however, does not imply that the entire authorization process must be designed and built from scratch for each application. The authorization process, though different in each application, does have a common set of fundamental concepts such as roles, actions, permissions, rules, access control lists, and so on. In fact, well-designed authorization frameworks contain both infrastructure-and application-specific components. The main goal of such frameworks is to minimize tight coupling between the authorization process and the application. For example, in order to grant access to a protected resource to users of role "myRole," one should ideally require simple modification to policy files rather than a change to the application.

Introduction to Single Sign-On A popular and widely implemented extension to the authentication process is single sign-on (SSO). A technical overview of the single sign-on process, its motivations, and issues is provided in the "Single Sign-On" section. Single sign-on defines a series of interactions that occur between trusted systems in order to sign on an authenticated user without his/her direct involvement to one or more systems. The following steps detail the SSO process:

1. Two systems, A and B, establish trust that allows them to share user identity information. This implies (among other things) that any user identity information originating from A or B and destined for B or A, respectively, is considered to be trustworthy, valid, and secure.

2. User identity is first established at one trusted source (say A) using a standard sign-on process involving a direct user challenge.

3. User then attempts to access a service hosted in system B from A.

4. System A forwards the user's identity to system B on behalf of the user.

5. Since system B trusts system A (step 1), system B accepts user identity information sent by system A.

6. System B validates and establishes the user's identity in its system without explicitly challenging the user and provides access to the requested service.

7. User has thus single signed-on to system B as the user was challenged only once to provide his/her credentials (at system A in step 2).

The crux of the interactions that occur within this zone are defined by the metadata and schemas (discussed in the "Single Sign-On" section) conveyed as part of these interactions. Metadata and schemas generically refer to the identity information, and the formats in which they are exchanged between the various systems participating in single sign-on operations. The main classes of information exchanged include account/identity, authentication context, and participant metadata, which are explained here:

• Account/identity This is simply the user's account/identity information accessed through a handle (refer to the section "Single Sign-On and Identity Federation"). The comprehensive list of attributes in a user's account/identity is application specific.

• Authentication context Many mechanisms and techniques are available to authenticate users into a system. Different parties may choose different technologies and follow different processes, and may be bound by myriad legal obligations regarding how they authenticate their users. The choices made in this area will largely be driven by the requirements of each party, the nature of the service, the sensitivity of information exchanged, financial constraints, and risk tolerance. Additionally, if a service is to trust the user authentication data it receives from an external source, the service may wish to know the technologies, protocols, and processes that were employed by that source to obtain the data. The authentication context provides a means for the exchange of such information.

• Provider metadata In order for identity sources and target services to communicate, they must have obtained metadata about each other. Such metadata primarily aid in establishing trust and operational agreements between the two communicating parties.