Designing and Implementing Secure Web Services

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

5. Implementation and testing

Typically, the IT security unit will be the major driving force behind the initial risk assessment, the requirements and the design phase. This is not to say that the security officer takes the decisions in these areas, but he/she is usually the person working behind the scenes to ensure that the approach to security is proactive and that any decisions in these areas are taken by the right people, suitably informed.

Once it comes to implementation however, control passes almost entirely to the project team and the main activity of the IT security unit is to support this team by providing expertise and guidance as required. The degree to which the security design is successfully implemented will depend largely upon how well IT security is integrated into the development or acquisition process and it is extremely important here to offer strong support for the methodology adopted by the project team. Imposing methods that are not compatible with the usual methodology for acquiring or developing new products often leads to confrontation and uncomfortable compromise.

Where packages are being acquired, the IT security unit should assist the project team in refining high-level requirements and design elements to the level of detail required by the Request For Proposal (RFP) or comparative study. Where development is to be carried out in-house, the unit should be able to help the project team identify any security trade-offs required as a result of development issues. In both cases, implementation teams will almost certainly require proactive support wherever specialized material, such as smart cards or HSMs is being used. For those organizations that choose to build the security functionality into the application itself, rather than simply have the application use a secure connectivity solution, the IT security unit may have to support the use of cryptographic toolkits. Although such an approach is capable of achieving a higher level of security, this is likely to be quite time consuming. Indeed, it is to be expected that the project team will need extensive guidance, not only on the underlying principles, but also on how to handle particular implementation issues.

The translation of security requirements into acceptance criteria and acceptance test scenarios should be business driven, but requires close collaboration with the IT Security unit and the implementation team. It is a good idea to develop a test strategy before starting to define individual test scenarios and this strategy should reflect the issues outlined in previous sections. Where web applications are concerned, penetration testing and tests involving a representative set of customers are worth a special mention. Penetration tests essentially seek to ensure that the central site cannot be compromised as a result of a vulnerability in the system or in the way that the system integrates into the IT infrastructure of the provider. A documented, successful penetration test can be useful in convincing potential customers that the system has been correctly secured. Tests involving representative customers on the other hand, aim to identify potential issues at the customer site and to ensure that these issues are resolved. This is where unwarranted assumptions about the customer site are most likely to come to light.

Throughout the development and acquisition process, the business should be made aware of issues having a functional impact or requiring a modification of the risk analysis and the way of dealing with these issues should be mutually agreed. Obviously, this dialogue needs to avoid technical complexity and concentrate on functional issues.

6. Deployment

As with any new application, it is critical to manage the deployment phase correctly, as this is the first point of contact for the majority of customers. A deployment that does not proceed smoothly may negatively influence the opinion of the customer for some time. Key activities during the rollout process include:

• Defining the deployment strategy.
• Defining how software (and potentially hardware) will be distributed.
• Preparing customer organizations to deal with configuration issues.
• Training end-users to use the security functionality.
• Training in-house staff to administer the system.
• Verifying and distributing documentation.
• Providing the necessary support functions.
• Planning and execution.

In order to be correctly prepared, work on the deployment strategy should begin as soon as possible and the overall approach should be modified as the implementation proceeds. This strategy should take into account all the different aspects of the rollout process including the logistics of distributing software and hardware, possible impact on the technical infrastructure and procedures of the end user, training requirements and how the deployment will be supported.

When dealing with commercial customers, it is almost inevitable that there will be a need for software or hardware distribution of some kind. Using a thin client, where the software is downloaded at connection set-up can minimize the effort involved, but even thin clients require supporting software. Whenever additional software such as plug-ins and drivers are required, the customer should have an easy method of obtaining and installing the correct version. In many cases, it will be possible to direct customers towards a web site where the software can be downloaded (but note that the download mechanism may not be secure in this case – a fact that could compromise an otherwise highly-secure system). In others, service providers may opt to reach an agreement with the companies providing the support software and bundle this into the standard distribution. Unfortunately, the distribution logistics become much more complicated if secure storage devices are being used at the client side. This too has an impact at the customer side, as many departments may be involved in this exercise. For instance, acquiring devices may involve purchasing and logistics units, installation may involve the IT department and end-users of the system need to be trained to use them correctly.

The latter point is important because modern security mechanisms do not necessarily function in the same manner as their classical counterparts. An example is provided by a system that uses an authentication mechanism based on cryptographic challenge-response. Typically, the end user will be issued with a password or Personal Identification Number (PIN) to unlock the private key, which is used in the authentication process. If a distributed administration model is used, where organizations are responsible for administering their own users, passwords will be issued at the customer site and not centrally. Users should therefore be aware of the fact that this particular password is unlocking a local file (or providing access to a local device) and is not the basis of the authentication with the target system. More generally, users will be required to understand the basics of how the security system works in order to avoid inappropriate behavior. For example, an end-user who generates and uses an electronic signature outside the scope of the application for which the corresponding certificate was issued (if this is possible), may well render the organization liable for any consequences.

To respond to these and similar issues it is useful to establish contact with someone within the customer organization (typically the security officer) who understands the risks associated with conveying highly sensitive information over potentially hostile networks and how these risks are mitigated by the application. This in turn allows the organization to define how it will configure the security subsystem to reflect its own requirements. By ensuring that the design of the application does not make assumptions about the approach to security at the local site, it should be possible to configure the resulting system so as to be compatible with the requirements of the latter.

This whole process is greatly facilitated by good, targeted documentation. If the documentation is well-presented, not too lengthy and informative, there is a good chance that it will be read, which should decrease the amount of direct support that needs to be given in order to get customers operational. Where certificates are being used, it is a good idea to check that the technical documentation is consistent with the Certificate Practice Statement (CPS) and Certificate Policy (CP) and that all these documents are in line with the contractual documentation.

As for traditional applications, customer support requirements will depend on a variety of factors including the type of customer, typical working hours, working language and geographical distribution. It is common to distinguish between first-line support staff, who are used to dealing with customers and have the necessary appreciation of the business and language skills, and second-line support staff, who provide in-depth technical support.

Finally, once a position has been adopted with respect to each of the above points, the rollout process has to be planned. Perhaps the best approach here is to be conservative – a customer will usually welcome an early deployment, whereas few customers will appreciate a late one.














Your IP address will be sent with this e-mail

From e-mail to e-mail