Designing and Implementing Secure Web Services

{LANG_NAVORIGIN} Web Security
Steve Purser 03/02/2005

3. Risk analysis and requirements

Although business involvement is important in the deployment of most new systems, this is even more true of web-based systems associated with a high level of risk. From an IT Security perspective, the first activity in any potential deployment of a new system is often the initial risk analysis. The goal of this risk analysis is to identify the key risks associated with the target system, to agree with the appropriate business line(s) the mitigating security services and to define and agree with the business the acceptable level of residual risk [5]. The residual risk is the risk, which is not mitigated, and which must therefore be accepted by the business owners. Once completed, this risk analysis is put under change control and updated throughout the lifecycle of the project. In practice, a correctly performed initial risk analysis will identify most key risks and updates will be rare (although as the project progresses, it is usually possible to gain a greater understanding of the risks initially identified, by placing these in the context of the developing system). Typically, the output of the initial risk analysis will be sufficiently accurate to provide a ball park figure for the cost of implementing the chosen security services and can be used to refine any existing cost benefit analysis.

Given that this risk analysis is usually carried out at the beginning of the project lifecycle (when there are typically a lot of unknown factors affecting both the implementation project and the resulting system), Fast Risk Analysis is often a more productive approach than an in-depth study of potential risks. Fast Risk Analysis techniques aim to identify the most important risk scenarios and to characterise each scenario using semi-quantitative measures of probability and impact (usually HIGH, MEDIUM and LOW). In performing such an analysis, it is recommended that any security mechanisms already deployed (such as Firewalls, virus control frameworks, etc.) be ignored, as any existing mechanism, which adds value, should be derived by the process. Taking the opposite approach and starting with an existing set of security services, may involve assumptions which turn out to be false at a later date.

Such an analysis is useful for identifying the key risks that the target system needs to mitigate. It is important however not to forget that certain risks are introduced as a result of implementing a new system. For instance, the risk of an attacker penetrating the network boundary may be offset by identifying Firewalls and Network Intrusion Detection Systems (NIDS) as mitigating services, but using such services might have a negative impact on performance and throughput, which is a risk in itself – particularly for systems that are associated with critical deadlines.

Where web applications are concerned, particular attention should be given to such secondary risks, as they give rise to important requirements. Hence, a decision to deploy smart cards to store private keys at the client-side is associated with a secondary risk of failing to provide adequate logistics and support. Mitigating actions might include a commercial agreement with a third-party to support smart card readers throughout the world and/or contractual limitations on the degree of liability in the event of a problem with smart cards or readers. Even better might be the provision of a backup storage mechanism based on PKCS#12 files [6] or Personal Security Environment (PSE) standards.

During the security requirements phase, business representatives should work together with the IT Security unit and the implementation team to ensure that the initial risk analysis is correctly translated into a set of clearly defined security requirements. This may involve working with other teams, such as the Legal Department or the Compliance Officer (to check that security requirements are consistent with legal and regulatory restrictions) and customer support teams (to ensure that security procedures can be correctly integrated with customer support functions). The security requirements are extremely important as they usually drive the security acceptance criteria and hence form the basis for accepting the resulting system.

4. Design considerations

The security design is the bridge between the requirements and the detailed implementation model. As such, it should be possible to map design decisions back to the underlying requirements. Such a mapping will not necessarily be simple, as some of the design decisions will be more global in nature and will not necessarily reflect specific requirements. Nevertheless, some degree of formality is desirable and, at a minimum, it should be possible to map identified security services and procedures back to the initial risk analysis and security requirements. This also has the advantage that the resulting deliverable can later be used to support the definition of acceptance tests. It is essential that the design be signed off by all concerned parties and that any change in risk arising out of the design process be accepted by the appropriate business line.

In line with the discussion of section 2, we will look at design issues under several headings:

• Global design considerations.
• Architectural considerations.
• Design issues relating to the user interface.
• Design issues relating to the server-side components.
• Process design.

Global design considerations
Perhaps the most important global design principle is to ensure that technical design and process design are seen as two parts of the same solution and the design is not carried out asynchronously. Unfortunately, it is not uncommon to discover procedural weaknesses due to the fact that critical administration procedures are designed after agreeing on a particular technical design.

The core design should make maximum use of accepted, open standards, as interoperability is critical to success in Internet environments. Unfortunately, there are a large number of such standards and even this constraint is not strong enough (consider for instance the large number of standards in the area of cryptography and cryptographic protocols). Whereas some standards are virtually unavoidable, others can be selected based on the value they add for the problem at hand. Hence, the more important Internet Request For Comments (RFC) documents (see references [7,8] for an introduction) fall into the first category, whereas the applicability of standards such as the Public Key Cryptography Standards (PKCS) [9], particular American National Standards Institute (ANSI) standards [10] or National Institute of Science and Technologies (NIST) guidelines [11] will likely depend on the operating environment. The best approach is to select a set of consistent standards and to stick to it.

Other factors being equal, the final design should favour simplicity. In general, a more complex design results in a more complex implementation, which complicates both testing and problem solving in the live environment. Where complexity is unavoidable, particular attention needs to be paid to documentation throughout the software lifecycle. For instance, dependencies on particular browser security settings and interoperability requirements with perimeter security devices should be clearly flagged to the end user. Ideally, documentation for end users should cover all security aspects with which such users may be confronted and, for more complex implementations, it is worth considering developing a series of targeted documents rather than a single document containing everything. Such an approach helps customers distribute technical information to the correct recipients within the enterprise.

For most web applications it is a good idea to build scalability and flexibility in from the design phase. Scalability and flexibility are measures of how easy a system can adapt to changes in the external environment (the word system here denotes both technical and procedural components). Scalability refers to the ability of a system to cope with increased volumes and flexibility refers to the ease with which functional changes can be made [12]. At the architectural level, security services should be cooperative – that is, they should be designed to reinforce each other, rather than getting in each other’s way. Similarly, the E2E security model should aim to provide defence in depth by putting several obstacles in the way of an attacker.

Finally, the overall design should represent a balance between the practical advantages of certain security services and the corresponding cost of implementation. True non-repudiation services for example are implemented using complex security protocols. Part of the security lies in the cryptography and part lies in the protocol. To be reliable, these mechanisms must be supported by logs, which may need to be cryptographically protected themselves (think of deleting signed messages from logs for example). Note that even when such a system has been successfully constructed, it may have no legal value – but this is another discussion.

Architectural design considerations
When designing security mechanisms for distributed applications it is necessary to take an architectural view of the system and to resist the temptation to consider the system as a disconnected set of components. In other words, it is important to ensure that the security model is consistent when analyzed from an End-to-End (E2E) perspective. Note that even defining the end point can be tricky if the web application is to offer services to a wide range of different institutions – if the client workstation is the end point at the customer site for instance, secure protocols will need to function correctly through proxy servers, firewalls and other intermediate devices.

Failure to analyse the security of the system from an E2E perspective may result in weaknesses at the interfaces between its different components. Indeed, we most expect to find weaknesses at the interfaces between different technologies, as it is here where different security subsystems need to co-operate with each other and current levels of standardisation in this area are low. Those organizations that have designed and implemented a security architecture will be in a strong position to deliver standard security services using the established infrastructure. Such an approach helps to decrease time to market without compromising on security functionality.

In order to derive an architectural view of the system security requirements it helps to map the initial risk analysis and security requirements onto the proposed architectural solution. This will result in a set of risks and security requirements for each identified component (client workstation, network, gateway, server etc) and will identify which services need to be distributed over several components and which services are localised. Because securing high-risk web applications to run over the Internet usually involves deploying cryptographic network security mechanisms, it is useful to look at two examples in this area of how an architectural design results in a more secure system.

For example, such systems normally have demanding requirements concerning data and session integrity. For the type of system we are considering, the threat to data integrity might be HIGH on the client workstation and the Wide Area Network (WAN), MEDIUM on the organizations gateway components, and LOW on the application server and internal networks. This suggests an integrity protection mechanism such as a Message Authentication Code (MAC) or digital signature spanning all components between the client and application server. Conversely, the threat of system penetration may be assumed to be significantly higher on the client workstation than on other components due to the fact that this component of the system is out of the control of the organization - this would then be modeled as a localized risk.

As a second example, we will look at the problems associated with implementing the standard Secure Sockets Layer (SSL) protocol directly to the desktop in corporate environments. Here, it is important to understand that most large enterprises implement proxy servers for Internet access, which means that individual users will access the web application through such a server and not directly. In many cases, there will be no requirement to implement SSL to the desktop, in which case a secure SSL session can be established between the web server and the appropriate proxy server. However, where it is important to authenticate and track actions of individuals within the corporate environment, such a requirement can occur. To handle these different requirements, proxy servers can handle SSL connections in two ways [13,14]:

• They can bridge the SSL session on behalf of the user, which results in a secure connection between the proxy server and the web server.
• They can tunnel the SSL session, which results in a secure session between the client workstation and the web server.

These two modes of operation are illustrated in figure 1 and figure 2 below.


Figure 1: Bridged SSL


Figure 2: Tunnelled SSL

It is important to realize that the design chosen has an impact on the client-side code. If the tunnelled mode of operation is required for instance, the client will need to test for the existence of a proxy server by retrieving information stored within the browser settings and initiate the appropriate version of the protocol handshake (which involves sending a special packet, known as a ‘CONNECT SSL’ packet in this case) [13]. Furthermore, if the proxy server requires users to authenticate before permitting outbound connections, the client side code will have to be capable of supporting this authentication step.

These short examples should illustrate the importance of an appropriate architectural design and give a flavor of the problems that can arise when such a design is not appropriate.

User interface security design considerations
One of the most difficult aspects of developing secure customer facing systems is dealing with the variety of approaches to security at the customer site. One way of minimizing the impact here is to ensure that the security requirements and design of the target system do not make any assumptions about customer sites and therefore offer flexibility in configuring the security component. Unfortunately, this results in extra work as it becomes necessary to cater for the most demanding, whilst offering the possibility to downgrade security to suit the requirements of customers prepared to take more risk.

One of the main design decisions in this area is whether to use a thick client or a thin client. Advantages of thick clients include the fact that customers are more likely to feel comfortable installing software from a CD, that such software can generally execute unimpeded once installed and there is no need to keep the code compact (as it is not being transferred over a network connection). Disadvantages include the requirement for an efficient software distribution mechanism to support the rollout process, the fact that it is difficult to introduce changes quickly to client side code and a relatively high cost.

The opposite is true of thin clients. Customers may be wary accepting mobile code on the desktop even when it is digitally signed and, when installed, the software will be subject to restrictions imposed by the appropriate mobile code policy file. This latter restriction can become extremely important if mobile code is being used to access external devices (e.g. a java applet using a PKCS#11 interface to access a smart card – here it may be necessary to provide client-side policy statements to ensure that the applet can access the device). Mobile code must be kept reasonably compact so as to achieve reasonable download times (the fact that no assumptions are being made about the client-side environment means that we have to cater for slow connections). On the plus side however, mobile code can be quickly changed at the central site and be operational as of the next login. A big cost advantage is that it does not require any special logistics for distribution - although associated software, such as virtual machines, plug-ins or specific drivers might do.

One useful trick when designing client-side interfaces is to include verification software into the user interface. The goal of such software is to verify the configuration of the browser (and potentially the underlying operating system) and to report any problems directly to the user. Where thin clients are being used and software is downloaded from the web server, such software should be cryptographically signed so that the customer can verify the origin before allowing it to execute. Such an approach can considerably speed up deployment and reduce the pressure on customer help desks from customers that are having problems in initializing the system.

Cryptographic key storage presents particular problems at the client-side, as we can make no assumptions about client-side security. According to Kerckhoffs’ principle the effective level of security offered by any cryptographic system systems is determined by the extent to which the underlying cryptographic secret (‘private’ or ‘secret’ key) is protected [15]. Client-side approaches to protecting cryptographic keys include software vaults, smart cards and dongles. There is usually a requirement for the user to introduce a secret (typically a PIN code or a password) to unlock the client-side key. External smart card readers equipped with PIN-pads provide one example of how this secret can be supplied to the device in a secure fashion (see figure 1).


Figure 3: Smart cards for client-side key storage

Here, the essential point is that the PIN is never visible to the operating system of the client device and cannot therefore be sniffed - there is a trusted path between the PIN-pad and the smart card. However, in line with the principle that we cannot make assumptions about client-side security, it is important to allow for a reserve key storage mechanism even if most customers state a preference for a highly-secure storage device. This may be required for several reasons:

• The customer security policy may forbid externally connected devices.
• There may be compatibility issues with the hardware and software used by the end-user.
• External devices limit mobility as there is usually a requirement to install driver software on the client system.
• The cost may be prohibitive.

In these cases, use of standards-based software key storage, such as PKCS#12 files, may be an acceptable alternative to using tamper resistant equipment.














Your IP address will be sent with this e-mail

From e-mail to e-mail