In conjunction with identifying related security risks known to a specific application or application genre, developers must assess the security requirements for their application. This analysis should arrive at a balanced measurement of the level of security required for an application. It does not have to ponder the extremes of the security spectrum. Given the understanding that true and guaranteed security is nonexistent, protecting against known risks and minimizing the number of successful attacks and their effects is generally an acceptable level of security. Those involved with the development cycle of the application should determine their own "acceptable" security level, by examining the known risks, the goals of the application, and the methods used to implement the desired security level.

To arrive at security requirements, managers and developers can find it useful to concentrate on the following, commonly known risk areas:

· User authentication and access control

· Data storage of confidential information

· Security in external network communications

· Security of entry points for external applications and the operating system

From these four general areas application designers and developers can identify a minimal set of important features to analyze. Depending on the functionality of the application, some risk areas are more pertinent than others.

To Secure or Not to Secure

The addition of security to an application affects an application in several ways. It immediately becomes more complex, as the code path takes a new turn to accommodate the security methods. The performance of an application might be hindered, especially with the addition of encryption operations. These operations are CPU intensive due to the complex algorithms involved. The efficiency of an application can also be sacrificed if security is applied in areas where it provides few benefits. This can occur if security methods are blindly applied to all components of an application without thought as to their requirements. The following sections provide a reasonable starting point to determine a basic level of security requirements.

Tip

It is a good practice to consider the security required for each module or component within an application. Resist the urge to apply blanket security methods across multiple modules or components. Instead, determine the most suitable level of security for each.

Assessing Authentication and Access Control Requirements

User authentication is often handled by the operating system on which the application runs, but several classes of application might need to deal with authentication on its own. Embedded applications, applications that function independently of the operating system, and distributed Web applications often need to accommodate some level of user authentication and access control. Common examples of applications that require these security methods are Internet commerce (e-commerce) applications, wherein users make purchases via a Web site, or customer database access. In both cases, the possibility for many different users or groups of users to use the system requires stringent control of accessible data. The applications need methods to allow separate users to access the systems via a login method; they also need restrictions regarding the individual users'respective financial data.

To determine the authentication and access control requirements, designers should examine the interactions within the application and with the world that surrounds it. This includes the methods by which users access the application—sitting directly at a terminal or accessing from the network are two methods that might require different authentication schemes. An application that is accessed only while sitting at the desktop can effectively be secured via the authentication methods of the operating system on which it runs. Network applications that are accessed by multiple users simultaneously, or through which users access data from common databases, provide strong impetus for access control and authentication. The level of granularity and flexibility of the access control and authentication capabilities provided by the operating system help determine if proprietary methods should be developed. Standalone or embedded applications are often developed from scratch and therefore require their own specialized methods.

Requirements for Data Storage

Data storage reflects the method used to store private and sensitive information. This includes the correct use of the file protection methods of the underlying operating system (such as re stricted file permissions) and stronger methods of protecting individual data elements (such as encryption). In many cases, the use of operating system permission methods is sufficient to provide the required degree of security. Encryption can be used to protect extremely sensitive data, such as user credentials and credit information.

The level to which the application needs to store data, and the nature of that data drive the requirements for data storage security. The storage of sensitive information is often the gating factor in determining if high security encryption is needed. User credentials, such as passwords, addresses, phone numbers, and financial data, should be considered sensitive and also treated with high security. Configuration information can often be secured sufficiently with standard file permission methods.

When forming the requirements for data storage, designers might be tempted to standardize on one level of security. For instance, if a password is stored in a configuration file along with other non-sensitive information, the temptation might be strong to use encryption on the entire file as a blanket security method. To determine data storage requirements, examine the needs of all components involved. In this example, applying encryption to nonsensitive data might be considered inefficient due to the computational expense of the encryption operations, as well as the lack of granular control of the other information in the file. A single element cannot be accessed easily if the entire file is encrypted. The complexity involved to access other elements is then increased dramatically.

Network and Entry Point Security Requirements

Applications communicate to users, the operating system, and other applications through entry points. These might be on the same machine as the application or across a network; often, they are on both. The methods for providing entry points to the application and support for network communication are often one and the same; therefore, they are grouped together here.

Security of network communications is best addressed by examining the content of the messages being sent. Applications that utilize network communication for informational messaging or passing static data might not require any stronger reliability than the protocol supports. Again, as in the case of Internet commerce, an application that sends and receives sensitive user information likely warrants the addition of a higher security method. Entry points also determine security requirements for applications that communicate in a networked environment.

The entry points to an application require a high level of analysis because they encompass and provide the network communication functionality. Others also interact with the application through the entry points. These functional areas can be protected via a combination of available operating system methods and the defined access control and authentication schemes used within the application. Analysis of the interactions that an application has with the outside world allows the designers to determine the most suitable level of security needed. These interactions and subsequent entry points are categorized as

· Network interaction

· Interaction with other applications

· Interaction with its respective operating system

These categories are well-known functional areas, and designers probably already know if their application interacts in any of these manners. The next step is to consider each area's security.

Network, Application, and System Interactions

The popularity of the Internet gives rise to many new applications that interact with other components within local systems and with remote systems. Applications that function independently of other applications and interact only with themselves obviously do not require networking risk analysis.

Network interaction can be present at several levels. An application can be completely client/ server–oriented, for use on remote systems spread across the Internet. The need for security in these applications becomes considerably more complex than it is in standalone applications.

Several dependencies should be discerned. The level to which the developers wish to provide security mechanisms in the application should be considered. The designers might decide not to provide any internal security mechanisms. The security of the networked application then relies on the security of the networks on which it runs and communicates; the network topol ogy and firewall determine the maximum level of security that an application can experience. The designer might choose to eschew dependencies and provide the highest degree of security possible within the application. These are the two extremes—most applications fall somewhere in the middle.

Applications can also use network facilities for localized communication that is not destined to go beyond the confines of the system on which it runs. Consideration should be given to the nature of this communication in order to determine if the implementation creates unnecessary risk.

The need for interaction between applications or with the operating system does not imply a requirement for network communication. Designers should investigate the implementation methods that provide the required functionality. Applications often use sockets-based communication methods to provide these entry points because they are fast and easily implemented. The use of sockets can provide more functionality than is needed, however. Applications that need to communicate only with other applications on the local system or with their own operating systems have many communication methods at their disposal, such as non-Internet sockets and IPC mechanisms.

Commonly, UNIX systems use socket communications because of their ease of use and plethora of documentation. UNIX supports several flavors of sockets-based communication, two of which are the popular IP socket and UNIX domain sockets.

IP sockets, as the name implies, use the IP protocol for communication, and support remote network communication, which allows local and remote processes to communicate with the application. Many applications that communicate only with processes on a local system and that do not require network communication capabilities use IP sockets as a standard interface. IP sockets are not ideal in this situation because they automatically provide access to local and remote clients.

Domain sockets use an internal UNIX protocol for communication and do not support network communication; they do provide a connection-oriented communications channel. Domain sockets have their share of risks if used improperly. UNIX domain sockets support the passing of file descriptors as well as informational data. This means that pointers or handles to other parts of the system can be passed from one application to another. This functionality is available only in UNIX domain sockets. If this capability is not desired or warranted, diversion from sockets-based communication to another IPC mechanism might be a better choice.

Considering the kind of information sent to and from the application helps define the requirements for its communication method. Designers should evaluate the interaction capabilities of the application before incorporating a standard function. In this example, the application using IP sockets is at risk because it allows remote systems to connect to the application when they should not be allowed. A better design documents the requirement for interaction with only local applications. This comprehensive requirement leads the developer to use something other than IP sockets.

Operating System Interactions

Interaction with the operating system often creates another level of security issues. Many levels of interaction can occur with an operating system—network interaction, Inter-Process Commu nication, and the manipulation of files have already been mentioned. Two other types of interaction also require attention: The execution of external programs and the use of system and other externally defined calls are common sources of exploitation. Important issues such as permissions, authentication, access control, and input validation should be considered in conjunction with operating system interactions.

System calls and external applications present a high degree of risk when used improperly because of their natures. These functions often exist in libraries that are used by many applications simultaneously and that often provide direct access to operating system components and resources. Exploitation of a single application through these functions can affect several applications and the system.

System calls provide access to many general-purpose and system-specific functionalities. They allow an application to interact with specific hardware components as well as kernel-level functionality. The safety of the operating system and components needs to be considered when using system calls. If an application ties together user or network data with the operating system via system calls, designers must minimize exposure to dangerous, unexpected, and improper data.

The execution of external applications is another common, unsecured interaction. Developers often design an application to call upon other applications by various methods. There are sev eral reasons a developer might want to do this, such as to differentiate between functions or to establish environmental control. Calling other applications also allows developers to use existing functionality and to expedite the application's implementation.

There is an inherent danger in calling another program from within an application—the external program can rarely be trusted. The application exists in a dynamic environment where it is possible to modify or replace any program. The problem lies in the methods used to call the application. UNIX-based systems often support functions called system() and exec(), which pass the supplied parameters as a string to the execution of the standard UNIX shell and subprocess, respectively. The system() call returns to the calling program when complete, but exec() terminates the running program and replaces it with the called program. Windows- based systems have the exec() call that allows the execution of other programs. Unlike UNIX, the Windows version of exec() runs the specified program in a subprocess, and the calling function does not terminate. Without input validation, attackers can put shell meta-characters into the input stream, forcing the shell to run possibly harmful commands and parameters. The use of these functions is generally frowned upon, and effort should be made to avoid their use because they allow the execution of untrusted and uncontrolled applications. Alternatively, designers can incorporate the required functionality directly into an application. The use of freely available, open-source software greatly decreases the effort needed to do so.

Many operating systems also allow functionality to run at different privilege levels. UNIX has its "root" privileges, Windows has "Administrator" and "SYSTEM" privileges. These special accounts can perform administrative tasks and have more interaction with the operating system and its services than other accounts do. Programs can be written to elevate privilege levels when specialized functionality is needed. An application and the operating system on which it runs can be compromised if privileges are not carefully controlled.

The model of least privilege suggests that an application should run with the minimum set of privileges needed to perform most functions. Functionality that requires higher privileges should be isolated into its own module, however that is defined—as a process, a class, an application, or even another system. Even then, that set of functionality should also run at the least privileged level until those elevated privileges are required. At that time, higher privileges should be obtained and, upon completion of the functionality, privileges should be returned to the minimum level.

Note

Meta-characters are characters that take on special meaning in a given context. For example, within the standard UNIX shell, the semicolon (;) is a command separator, that is, many commands can be put on a single line when a semicolon is between them. The pipe (|) character sends terminal output to whatever follows the pipe, allowing the output from one program to be fed into another.

Conclusion

Some application developers choose to forget or ignore security within their applications and put themselves at the mercy of the customer's network or operating system and its security features. Using this blanket security model shuns the responsibility to provide secure applications to the public. The security philosophy purports a strong and comprehensive security ideology that assumes nothing about the security of components external to the application. An application should always be as secure as it can be with respect to itself and the external components with which it interacts. The level of follow-through is left to the discretion of the designer or developer, however