Designing and Implementing Secure Web Services
{LANG_NAVORIGIN} Web Security
Steve Purser
03/02/2005
Server-side security design considerations
The security design of the server-side components is typically dominated by issues related to integration and interoperability.
Where integration is concerned, server-side components should be integrated into the existing security architecture. If there is no architecture as such, these components should integrate cleanly with the security infrastructure that does exist. As an example, integrating a system developed using COM+ technology and running on windows platforms into an environment that is exclusively UNIX based is likely to present several issues. In this particular case, it may be necessary to update vulnerability scanners to cover a new operating system, new network protocols may be required (such as NBT protocols), new software might be required to implement secure protocols, such as SSH, new security baselines will have to be developed and procedures will have to be adapted. On top of all this, staff will require training to administer the new technology.
Interoperability problems occur for a variety of reasons and are particularly common when dealing with server-side cryptographic equipment. Hardware Security Modules (HSM) for instance may offer limited possibilities for integration with other software components. Web server software might support a PKCS#11 interface for certain versions of HSM software, but not for others. When support is provided, it may only be partial – continuing with the example of the PKCS#11 interface, the basic cryptographic operations may be supported, but there might be limited support for some of the ancillary functions. Similarly, there may be limitations at the network level, such as support for the SCSI interface but not for an Ethernet interface – this is an important consideration if there is a requirement for an HSM to support several systems.
If in doubt, this is one area where it is worth looking for existing implementations and trying to arrange a site visit with the aim of identifying problem areas and solutions. Site visits are useful to distinguish between what is possible in theory and what is practically achievable.
Process design considerations
Process design is important because once the system has been implemented, it needs to be administered and maintained and badly designed procedures can have a big impact on the real Return On Investment (ROI) of the initiative. Inefficient procedures result in unnecessary costs and may also result in delays when serving customers. Ineffective procedures on the other hand can result in unforeseen security exposures. It is therefore worthwhile taking the time to carefully design the process side of the service.
As a first example of where a good process design can make a big difference to the operating model, consider the issue of user administration. In traditional systems, the user account details are maintained at the server side in a central database of some kind. Where X.509 certificates are used as the basis of the authentication, there is a possibility to offload much of this administration to a security officer at the customer site. This gives more control to customers and decreases the amount of administration that needs to happen at the central site. One way of achieving this is to ask customers to delegate local security administrators and to provide them with tools for generating and managing public key pairs and associated user profiles for their organization. The site security administrators are then registered with the central system via a registration process. Once these administrators have been successfully registered however, and their certificates are in the LDAP directory of the web service provider, they can generate and assign key pairs to internal users and register the corresponding public certificates with the central site by signing a certificate request message (such as a PKCS#10 message).
The system initialization process provides a second example in this area. Here, the problem to be solved is “how do we authenticate for the first time a new user, with whom we currently have no secure established secure channel?” This inevitably involves using one or more out-of-band channels to send an initial authentication secret to the end user (note that if a distributed administration model has been selected, as in the above example, this end user will be an administrator). Good registration procedures foresee the necessary background checks and use established communications channels effectively. As registration procedures can be quite onerous, a bad design can result in considerable operational inefficiency.
Last but not least, the impact of new server components on the administration overhead should be taken into consideration as from the design phase. Components that can be smoothly integrated into an existing architecture are less likely to require big changes to existing procedures than components based on new technologies or concepts. This in turn promotes standardisation and can result in considerable economies of scale if planned that way from the start.
Quite often, the high-level design contains enough information to identify the skill sets and estimate the administration workload that will be required to support the final system. This information, which should be checked as the implementation proceeds, can then be used to prepare for the rollout process and to identify future budgetary requirements.
E-Mail Link
Your IP address will be sent with this e-mail
