Components of a Security Architecture

A comprehensive security architecture is best achieved through an increasingly granular approach that begins from an external viewpoint and progresses through the details of the implementation. The following components organize the information needed for the creation of an application's security architecture:

· Risk assessment and response

· Security requirements

· Design phase security

· Implementation phase security

Set the Stage for Security

Risk assessment is an important process in the development of any product or application. The creation of an application begins with the spark of an idea. It is likely that this application idea solves a problem, or provides new usefulness or innovation that was previously done ineffectively or inefficiently, or not done at all, by existing applications. While analysis is done to determine the shortcomings in function of the older applications, security considerations are often forgotten. The tendency to focus strictly on the functionality an application provides and the benefits to the explicit dilemma it solves increases the potential for security risk. It is extremely important to solve the security problems of an application, as well as the functional problems.

Therefore, the first stage in the creation of an application's security architecture is to document the risks inherent in existing applications that are to be replaced by the new creation. Developers should also note risks related to an application with which the new program will interact. The new application often faces all of the security issues that similar applications face, as well as new issues that arise from innovation.

Assessing the security risks of an application requires some diligence on the part of the application designers; if the designers have any level of security experience, the effort to assess risks quickly becomes smaller. The most basic research that identifies the security issues with related applications involves a search through the archives of vendor-specific support issues. The Web sites of these organizations generally have special areas and forums that announce the availability of patches to security problems in their applications. This research gives a sense of the common issues faced by the new application and the functionality it provides. Further research in security-specific forums provides more technical detail regarding the natures of the problems, as well as a broader sense of the security issues related to a specific application area.

As vulnerabilities in the pertinent technical areas are researched, it is important to document them. Creating a list of security risks and vulnerabilities helps establish a scope for the application under development, by determining which issues are likely to affect the new development.

The known vulnerabilities of an existing application can provide hints toward the presence or lack of a security architecture in its design. The vulnerabilities can often be categorized as implementation flaws, design flaws, and functional flaws. Implementation flaws relate to the actual code used to make the application; they provide only a small amount of insight to the security architecture. Design and functional flaws reflect the thought and effort put into the design of the application. An application with a security architecture highlights and strengthens the functionality by making security awareness an inherent part of it. Shortcomings in design and function leave holes in the thoroughness of functionality, often creating security risks.

Consider the Functionality Not Provided

Strong designs recognize the functionality provided, as well as that which is not provided. The most basic level of functionality possible is defining what an application does. This is done under a completely positive view because it outlines only what an application does under the most pristine circumstances. It naively assumes that the world is perfect and that nothing bad will ever happen when the application is running. This means that all inputs will be completely understandable and fit the expected input "mold"—for example, "All usernames will be alphanumeric values of a determined length and no user will, accidentally or otherwise, enter a character that is not either a number or letter." This view also assumes that all network connections would be from known clients, and that these clients would all communicate with the proper protocol—for example, "All clients connecting to the application will adhere to the known messaging sequence required to perform the defined communication." Finally, it assumes that all interaction with the operating system occurs in a sterile environment that the application expects—for example, "Each and every file that is modified always exists and is correctly formatted." Obviously, this is not necessarily the case and cannot be expected. Unfortunately, many applications rarely make it beyond this level of design. A comprehensive design takes into consideration the imperfections in the real world. A design of this nature recognizes that establishing rules and schemes provides reliability.

Considering both positive and negative scenarios for an application's operation is vital when creating an application. The negative view defines the reaction to unknown input, invalid syntax and communications, and anomalous conditions that might occur. The application needs to respond properly to events that are not expected or defined. The table below compares a basic design versus a more comprehensive design and the effects each has on user input, file access, and client connections.

The degree to which designers and developers formulate answers to negative results plays a significant factor in the reliability and security of an application. While it is often difficult and infeasible to explicitly handle every known exception, general rules can easily be created to handle undesired events. These three examples present extremely simple scenarios that might seem unrealistic, but all have occurred more than once in many applications.

Come Here for Guaranteed Security

This discussion would be incomplete without mention of third-party organizations, whether commercial or public domain, that provide security software, development kits, and hardware to enhance the security of applications. Many of these commercial organizations present their products as providing "guaranteed" security.

However, there is no hardware or software substitute for a well-thought-out design. Often, managers, designers, and developers are led to believe that the addition of some complex and expensive security components offered by a commercial security organization provides "guaranteed" security. This is simply untrue; "guaranteed" security is a fallacy. This concept preys on victims who understand security as a feature or component that can be plugged in for immediate security satisfaction.

Few applications are devoid of security components, but it is not sufficient to simply incorporate the most commonly known components in order to render a design or implementation secure. The inclusion of security components without consideration for their use does not enhance the security of an application and can, in fact, hinder it. The products offered by security companies are very valuable and useful when used properly, but they cannot guarantee the security of an application. The inclusion of third-party security technologies should be examined for usefulness and value, given the security requirements that are established for the application.