A comprehensive design provides solutions to the problem addressed by the product, and also takes into consideration the effects of the innovation. The security of an application is also created and enhanced by a comprehensive design.

Once an organization discards the idea of security as a feature, it becomes apparent that secu rity needs consideration early. While each organization might have different methods of designing a product or application, the following approach is useful to assure a high level of security in a design. The design phase analyzed from three viewpoints:

· Global

· Organizational

· Component

The global viewpoint is the highest view of the system; it identifies the needs addressed by the application and its feature set. The organizational viewpoint highlights the individual components that make up the application. The component viewpoint goes to the next level of granularity, by examining the explicit details of each component and its implementation. The incremental approach used here allows for a deeper and more comprehensive analysis that also provides an easily understood process flow. This helps managers and developers put the appropriate procedures into place to ensure the consideration of security in their application.

The Global Viewpoint

Many applications arise from an unfulfilled need or the inadequacy of current solutions. A good design identifies the following security concerns:

· Security issues related to existing solutions to the problem or the need being solved

· The application's response to those security issues

· The potential security vulnerabilities that exist in the innovations being made

A global analysis provides information that an attacker would otherwise find after the application is released. At this phase, a security architecture should be defined for the application. This architecture formalizes the level of security needed in an application. It helps establish the application's security scope by identifying the relationship of the application to its surroundings and the level of security provided by them. A security architecture also highlights the need for, and amount of, independent security that an application must provide, as well as the features required.

A global analysis and establishment of a security architecture are done via the incremental categorization of the modules, components, interfaces and methods used in the application. Their location and relationship to each other and their exposure to external applications, users and interfaces are important points.

The global viewpoint of an application initially presents the proverbial "black box"—the only details known are those seen by outsiders. These external features and functional requirements are then separated into modules for security analysis.

Searching vendor advisories, newsgroups, mailing lists, and online forums for disclosed vulnerabilities in competing or similar applications is a good way to learn about some of the major security issues related to the application. It also helps point out ineffective solutions to vulnerabilities found in similar applications.

Case Study, Phase I

This hypothetical example is a case study for the development of an Internet commerce application. This service allows users to connect from their browsers to make online purchases.

The first level in the design of this application is the definition of its capabilities, independent of the implementation methods used. These features might include the following:

· The selection of an appropriate operating system to host the applications

· Database access for storage of private and public information

· Web serving

· Connectivity of these parts using custom-developed applications

· Connectivity to financial institutions for the transactions

From the global viewpoint, a designer discerns the security features required for each component of these functions.

The database stores private information on many different users, including passwords, credit card numbers, and contact information. In order to protect this information, the database should have security components that support restrictions to objects and perhaps their encryption.

The Web server should support secure communications with the Secure Sockets Layer (SSL) protocol, and some method of interfacing with external applications and the database. This could be via Java servlets and applets, or CGI programs.

Network communications are an inherent part of this system. The Web server and database server software probably run on separate machines, hence a means to secure the network communication between them is required.

The last component to be considered is the actual connection to the organization that authorizes the transactions. This could be a bank or credit card company that authorizes the expenditures by users. Connections are likely accomplished with a modem or other piece of telecommunications equipment that interacts with the financial organization and performs the validation. These connections require high security, in order to avoid access by unauthorized users.

These insights are gleaned from knowledge of the field, analysis of competing products, and familiarity with customer requirements. At this point, diligent research needs to be done to document past and current security vulnerabilities in related products. The resulting list should identify the risk areas that need addressing. Security features missing from the initial requirements list are often identified through this analysis, another of its benefits.

In our Internet commerce example, researchers found the following vulnerabilities in comparable products:

· Databases had no protection schemes, resulting in the exposure of private customer information.

· The Web server had holes that allowed the execution of arbitrary code on the system. The server's default configuration also allowed directory traversal, which allows external users to access many private files and directories on the system.

· The CGI applications used to communicate with the database had vulnerabilities that allowed remote attackers to impersonate other customers.

The research also indicates that data protection, buffer overflows, default configuration, and input validation issues need to be avoided because these vulnerabilities occurred frequently with similar applications. It also showed that vendors have added security features and patches that will protect against these problems. This makes authentication and access control important requirements, along with network security.

At this point, the designer knows of vulnerabilities associated with the application, the methods by which other organizations respond to them, and a set of important security features that form the basis of a security architecture. The security architecture develops further in the next phase of design.

The Organizational Viewpoint

Security is not an exact science; its needs are specific to each application and environment. Therefore, it is not sufficient to look at security from only the global view. Although an otherwise well-designed application might exist independently of all other applications on the system, the interaction of all components in that application might pose security threats. The organizational viewpoint identifies the individual elements or groups of elements that form the entire application, their functions, and their relationships with each other. An element could be a function, a class, a process, or a set of these elements that are grouped by their relationship to the application.

An application is typically made of several functional modules, such as the user interface, networking or communication components, or data storage and retrieval tools.

While a module might seem reasonably secure, its relationship with the other components might be executed insecurely. Similar to the analysis of the interactions of the application, organizational level analysis takes the functional requirements and determines the architecture used. The functional requirements allow the designer to identify a set of components and methods that provide the functionality; an analysis of the security between them as they interact yields the safest choices for inclusion with the application.

The incremental identification, organization, and categorization of each component in the application continues in this phase. A logical place to begin—and particularly suspect in terms of security—are the edges of a module. The edges are the entry or exit points where data crosses the boundaries between modules. For example, data crosses boundaries between modules during these functions:

· Passing of data as parameters

· Setting global variables

· Manipulating shared memory

· Writing data to files

· Sending data across a communication channel such as the network

· Receiving user input

Case Study, Phase II

In the organizational phase of designing the sample Internet commerce application, each application component—the Web server, the database server and the associated applications—is categorized into its functional module for further analysis.

The database server has a storage component, an authentication and access control component, and a communication component. The Web server has the Web serving component, an external programming model, and secure client communication and secure database communication components. Interactions between these components form a definable path, with several points where security must be strong. Following an interaction between the Web server and the customer, a client Web browser transmits sensitive data to the Web server. This data is then passed to the custom application that interacts with the database and the financial institution. Following the data path through the application, a developer can observe points of vulnerability in the client communication, the Web server application interaction, the communication from the Web server to the database, and the interaction between them.

The security requirements begin to take shape. The application must address these risk areas and provide security in these forms:

· Secure communication to the client Web browser in the form of encrypted network communication, authentication of users, and access control mechanisms on their information.

· Safe interaction between the Web browser and the e-commerce application to ensure the safety of the system

· Application integrity of the commerce program

· Secure communications with the database

· Security of database objects

From these requirements, an architecture begins to take shape. The use of SSL on the Web server protects the server-to-browser communications. The application will have its own authentication mechanism that allows clients to sign in safely. Data validation and protection mechanisms will also be implemented in an organized fashion that uses only the minimum required privilege to operate. Functionality will be incorporated into the application for object protection and encryption on the database server. The actual implementation details will be developed in the final component phase.

Pertinent security methods will rise to the surface when the following questions are asked in the organizational phase:

· How will we protect information passed?

· What are the effects if one module passes spurious data to another?

· Have the constraints of the data been defined?

· Is there a preferred method of passing data that lends itself to increased security?

· Which components, applications, and users need access to the data? What kind of access is required—read-only or both read and write capabilities?

The Component Viewpoint

The final viewpoint from which design analysis occurs is the dissection of the individual components within an application. The smallest design and implementation details can introduce obvious and obscure security problems that are difficult to find post-release. Poor implementation can also undo the effort put into the security of a design.

Some of the precautions suggested here fall into what are considered good coding practices and are not necessarily security specific, but they do have an effect on the security of an application.

The security architecture that is defined for an application will mandate that there be a series of checks and balances to which the application must conform. These checks and balances will provide a high degree of assurance that an application acts in a uniform manner in the event of unexpected data or information.

The component view examines each piece that forms a module. (Modules, in turn, form the application.) These components should be analyzed for their individual security features and the interactions with other components within that module. Starting points when examining programmatic issues within a module are

· Return values

· Precedence and prerequisites

· Data validation

· Identified response and recovery

· Permissions and privilege

Return values are indicators of success or failure within a function. Components of an individual module are made of functions, which interoperate and have established relationships that allow the program to perform properly. Developers should also understand what it means when a function fails, and should react appropriately to that failure. A complete understanding of these relationships allows a developer to understand the dependencies between functionalities. Based on these dependencies, components within a module can be organized to enhance reliability and security.

Data is dynamic in any application—it travels between functions and modules, and to separate applications, altering the execution of the initial application as it does so. With the identification of the modules that form an application, and the components that subsequently form those modules, the path of data through an entire application can be traced. The entry points between modules and functions are the pivotal elements that affect the success or failure of the application, therefore validating data at these points is vital. Working hand-in-hand with validation is a defined response to invalid data and anomalous conditions. Many applications fail to formulate a recovery mechanism in the event of unexpected events; this often results in unstable applications that crash at the earliest sign of imperfect data.

Knowledge of the permissions and privileges required for the components to function provides important information for the application designers. Following the model of least privilege is a good design practice; it recommends the isolation and limitation of privilege in a running application. In most cases, high privilege levels are needed very infrequently and only in isolated instances. Many applications that require elevated privileges for a small portion of functionality commit the entire application to that higher privilege level for its entire existence. This creates a hazardous environment wherein each vulnerability that is found exists in this privileged mode.

Privilege refers primarily to the several levels of authority on an operating system. At each higher level of privilege, authorized users have access to progressively more resources in the system, such as memory, other applications, hardware devices, and data. The root user in UNIX, the administrator, and the SYSTEM special account in Windows exemplify the highest level of privilege. There are often various degrees of access that provide granular access control, also. Granular access control allows definable access and rejection methods for the application. Files, network traffic, users, and objects can be bound to a set of explicit permissions that allow or disallow access to them.

Case Study, Phase III

The component phase analysis of our Internet commerce application looks at the individual components used in the application and their security. Entering this stage, designers should have a sense of the complete data path and the relationships between modules. The next granular step establishes the basis for the application's implementation. The goals of this analysis are to determine the privileges of the various components, a sense of organization that will be used during the implementation, and knowledge of how the implementation will occur. Here, previously determined requirements are translated into detailed implementation methods.

Designers choose a Web server and a database server at this point, based on the established requirements. In our example, an Apache Web server was chosen because it can be made to support SSL communications and has a well-documented method to interact with external applications. An Oracle database server was chosen because it provides the flexibility, scalability, and security required in the database, and also because it supports Java-based interaction. Java was chosen as the language and extension for implementing the actual Internet commerce software because it operates with the Web and database servers and supports a strong, configurable security model.

The Web server and database server are then designed by determining the most secure methods for the following components:

· Server default configuration

· Security configuration of the underlying operating system

· Privileges required to interoperate with the Java applications

· Access control components

The commerce software is organized to provide these components:

· Privilege requirements to perform its functions

· The Web server interaction and communication entry points

· User authentication and access control methods

· Session security methods to prevent impersonation of users

· The database server interaction and communication entry points

Based on this analysis and organization, it is determined that the only portion of the system that requires elevated operating system privileges is the commerce application. It also needs an internal set of privilege levels to enforce user access control and authentication. The default configurations enable only the functionality needed for operation of the system, and each operating system is security-hardened with the same minimalist approach.

The commerce application is where the majority of the security components exist. It has the responsibility of validating user credentials, setting permissions on database objects, keeping track of each user session, and having the actual intelligence required to keep the system functioning.

The commerce application needs elevated privileges only when controlling Web and database server startup and shutdown. The most secure method to perform these actions is determined to be a separate controller process that increases its privileges at the time it performs a startup or shutdown action; it then relinquishes its privileges until the next request. The controller process communicates only with the commerce application and uses authenticated messages to initiate the startup or shutdown of the system.

The commerce application will also encrypt private information before storing it in the database in order to protect user credentials and financial information. In the event of anomalous and error conditions such as invalid input data, user authentication failures, and failed communications, the design calls for a reporting system that can log this information and respond appropriately to the events.

System implementation rises naturally from the continuous analysis provided in the preceding global, organizational, and component analysis phases. The developers use the guides and procedures in place to help them write the code that maintains the high security standard established.