Designing and Implementing Secure Web Services

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

7. Administration and monitoring

Although administering and monitoring are activities that occur at the end of the system lifecycle, they need to be planned for at an early stage. Indeed, as such activities are ongoing, requirements for extra resources are likely to have a big impact on the business case. Worse still, if requirements are not flagged up front, it may not be possible to secure these resources later on, which could compromise the whole setup.

Ideally, administration procedures will be closely aligned with those in existence for other applications. Where the security model is based on the use of certificates for example, it should not be difficult to re-use existing procedures for certificate management (although some modifications may be necessary to reflect differences in risk when compared with other applications). Using common procedures minimises the need for special training and permits economies of scale.

Obviously, administration procedures should be coherent when viewed as a whole. In particular, the goals of the procedures associated with the web service in question should be compatible with those used to administer the underlying architecture. Hence, it may not make a lot of sense to impose severe technical constraints and procedures on the application if the administration of the underlying operating system is lax.

Last but not least, administration procedures should be operationally realistic. It is good to have procedures for regularly analyzing the content of security logs, but this is only useful if the person analysing the logs has the ability to recognize the signs of a problem. Unfortunately, it can be quite challenging to understand certain technical logs, which implies that a skilled resource will be carrying out the analysis. Skilled resources however are not usually over keen to perform this kind of work and may easily become bored. This in turn can lead to oversights and mistakes and renders the whole process inefficient. A creative approach can go some way to resolving these issues. This might involve technical measures such as using intelligent filtering rules and automatic comparison with previous logs or procedural changes, such as rotating the log analysis task within the team to avoid boredom [12].

8. Conclusions

There are many advantages in using web protocols and a browser-based interface to implement highly secure services over the Internet. However, offering such services to corporate customers presents a series of challenges to the service provider. At the customer site, secure web services must be capable of operating smoothly in the presence of established security infrastructure, such as proxy servers and firewalls. Additionally, the installation and day-to-day use of specialised equipment, such as smart card readers, should not place unreasonable demands on the end user. At the provider site, it may not be trivial to smoothly integrate security software and hardware into the existing security infrastructure and the processes required to support the new service can easily become costly and arduous.

The initial risk analysis exercise should clearly identify the key risks to be mitigated, together with the residual risk that remains once all technical counter-measures and procedures have been implemented. This risk analysis should also take account of secondary risks – those risks that arise as a result of the risk mitigation actions. The residual risk should be signed-off by the appropriate business line, who will then work with the IT security unit to transform this analysis into a set of security requirements.

It is useful to think of design criteria in several areas. Global design criteria relate to the system as a whole and relate to fundamental issues, such as design complexity and the degree to which the final system needs to be flexible and scalable. Architectural design criteria aim to ensure that security services are deployed in an effective and efficient way when viewed from an E2E perspective. Examples were discussed that illustrated why it is important to have a sound architectural view of the proposed security solution and where problems can occur if this is not the case. User interface security design considerations include whether to use a thin-client or a fat-client, the use of verification software and how cryptographic key storage will be achieved. Server side considerations on the other hand are largely concerned with integration and interoperability. Finally, it is critically important to consider process design and technical design as two complementary halves of the same solution.

During the implementation phase, the IT security unit assists the implementation team by providing expertise and guidance. Where packages are being acquired, this might involve completing the security section of the RFP. Alternatively, for a development initiative it might involve helping developers come up to speed with security toolkits and helping the team quickly resolve any problems. The IT security unit will also play a big role in designing the testing strategy for security-related functionality and may also be involved in test design.

The extent to which the deployment exercise is successful will depend on a number of factors, including the degree to which the strategy responds to customer demand, whether or not distribution logistics are under control, how training will be handled, the underlying customer support process and the amount of planning that has preceded the exercise.

About the Author

Steve Purser is Director ICSD Cross-Border Security Design and Administration at Clearstream Services, Luxembourg. Steve is also a founder Member of the “Club de Sécurité des Systèmes Informatiques au Luxembourg (CLUSSIL)” and author of “A Practical Guide to Managing Information Security” (Artech House, 2004).

References

[1] William Stallings, “Network Security Essentials (International Edition)”, Pearson US Imports & PHIPEs (2002).

[2] Charlie Kaufman, Radia Perlman, Mike Speciner, “Network Security: Private Communication in a Public World”, Prentice Haall PTR (2002).

[3] Stephen Thomas, “SSL and TLS Essentials: Securing The Web”, John Wiley & sons Inc (2000).

[4] Steve Purser, “A simple Graphical Tool for Modelling Trust”, Computers & Security, Vol. 20., No. 6 (2001).

[5] Steve Purser, “A Pragmatic Approach to Managing Information Security”, Artech House (2004), pp. 27-30, 241-248.

[6] RSA Laboratories, “PKCS#12: Personal Information Exchange Syntax Standard”, http://www.rsasecurity.com/rsalabs/node.asp?id=2138

[7] J. Postel, “RFC 1539 – The Tao of IETF – A Guide For New Attendees of the Internet Engineering Task Force” (1989)

[8] G. Malkin, “RFC 1111 – Request For Comments on Request For Comments: Instructions to RFC Authors” (1993).

[9] RSA Laboratories, “Public Key Cryptography Standards (PKCS)”, http://www.rsasecurity.com/rsalabs/node.asp?id=2124

[10] The American National Standards Institute (ANSI), http://www.ansi.org/

[11] The National Institute of Science and Technology (NIST), Computer Security Resource Center (CSRC), http://csrc.nist.gov/

[12] Steve Purser, “A Pragmatic Approach to Managing Information Security”, Artech House (2004), pp. 13-14, 155-179.

[13] A. Luotonen, “Tunnelling TCP Based Protocols Through Web Proxy Servers”, draft-luotonen-web-proxy-tunnelling-01, http://www21.ocn.ne.jp/~k-west/SSLandTLS/draft-luotonen-web-proxy-tunneling-01.txt

[14] R. Khare, S. Lawrence, “RFC 2817 – Upgrading To TLS Within HTTP/1.1”

[15] B. Schneier, Crypto-Gram Newsletter, May 15 2002.
















Your IP address will be sent with this e-mail

From e-mail to e-mail