Forum Systems, Inc. - Enterprise Security Requirements

Enterprise Security Requirements

As with so many information technology decisions, the best approach to selecting the optimal Web services security solution is to assess the needs to be met and then to identify a solution that best fits those needs, precisely and affordably. Enterprises should be wary of investing in generic, one-size-fits-all security solutions or solving a security challenge with a battery of costly and complex products. Such over-engineered solutions are difficult to maintain and may create their own set of vulnerabilities if features are neglected or poorly understood. Malicious users can take advantage of underutilized functions and turn the organization's investment against itself.

For more information:

Forums Adaptive Approach to Web Services Secrutiy White Paper

1. Consumers and Consumer/Producers Security Requirements

Consumer

Consumer/Producer

Example

	A traveler who uses a Web browser to access a Web service reporting weather conditions at an airport.
	A portfolio management program that uses Web services to receive continuously updated stock quotes

	A logistics management solution that provides information to shippers and that issues requests to check weather conditions, calculate tariffs, and schedule shipments.
	A portfolio management program that uses Web services to receive continuously updated stock quotes and that executes trades automatically based on defined criteria.

Security Requirements

	Producer authentication (verifying the authenticity of the producer and the producer's response). This can be performed on a server or service level. SSL digital server certificates are widely deployed for servers and would be ideal authentication mechanism as no addition client infrastructure is needed.
	Protection against malware and other malicious payloads from producers.
	Protection against external reference attacks.

	Authentication (verifying the authenticity of other producers as well as consumers). This can be performed as a service or by a dedicated server. Digital certificates can be used for the clients and/or servers. However, deploying digital certificate technology to clients is a complex undertaking (be it for SSL client authentication or digital signatures on each request). Traditional authentication using HTTP Basic Authentication or other non-PKI tokens may be another effective alternative.
	Authorization (verifying the rights of consumers and producers). Access control mechanisms have to be in place at the service and message levels in order to securely accept requests.
	Protection against malware and other malicious payloads.
	Protection against attacks to the Web service, including external reference attacks and other sophisticated denial of Web services threats such as probing attacks.
	Protection against threats that target the back-office business processes and IT infrastructure.

2. Security Requirements and Limitations for Web Services Entities

Entity

Security Requirements and Limitations

Machine
Network device, consumer device, embedded device

	Limited by the platform characteristics such as memory and processing power
	Less frequent access to "firmware" upgrades
	Need to consider encryption capabilities and limitations
	High urgency for filtering and anti-virus capabilities.

Software application
Stand-alone application, such as a back-office system

	Lots of flexibility
	Can be customized for Public Key Infrastructure
	Need to consider exposed interfaces
	May have to work on "behalf of" consumer devices and as such has to be able to function as an authentication or authorization as a "proxy"

Software agent
Software that works on behalf of a human being to manage a workflow

	More flexible than machines, such as consumer devices
	May require non-repudiation technology such as digital signatures

Person
Person who initiates a workflow or transaction

	Authentication mechanisms should not be complex - e.g. digital signatures, passwords - must be deployed with "ease of use" in mind
	May requires non-repudiation in the case of high value workflows
	User interface must not be cumbersome or awkward.

Web service
Business API or business process that is not associated with any one application; can be dynamically created and instantiated on demand.

	Requirements can vary greatly and the risk profile and deployment architecture needs to be considered (see additional Application Model guidelines)
	If the transaction is long running and sensitive, may require persistent security measures such as data transactions
	Auditing and logging

3. Comparing Security Requirements for Web Services Relationships

One to One

One to Many

Many to Many

Example

Two partners exchanging information between them; the partner network consists only of these two nodes.

A central office communicating with branch offices.

Trading networks, such as supply chains, in which orders may pass from one office to another and an initial transaction (e.g., an order for an aircraft engine) may spawn multiple supporting transactions (orders to individual parts, orders for shipping containers, and so on).

Security Requirements

	Because only two parties are involved, it's easier to standardize on authentication and encryption technology. Also, it's easier to detect unauthorized users and network addresses. OpenPGP, secure FTP as well as Virtual Private Networks can be deployed without the scalability concerns that arise with adding new participants.
	Because data is not traversing multiple hops, and both end parties are trusted, SSL is one of the most viable security options for confidentiality.

	Platform requirements from the nodes will be a limiting factor in selecting a security solution.
	The central node must be configured to handle higher volumes of traffic.
	Data confidentiality may become important if traffic is crossing public spaces on its way to an endpoint.
	Auditing and logging

	Security technology must accommodate a broad range of platforms.
	Security solution must be able to handle high volumes of traffic.
	Because transactions may span multiple nodes, SSL may not provide adequate security and other message-level security mechanisms need to be considered such as Security Assertion Markup Language.
	Data encryption is recommended.
	Auditing and logging

4. Comparing Security Requirements for Transaction Profiles

Long running

Short lived

Composite

Example

A purchase request may last days, weeks, or months while the order is being fulfilled. During this time, data such as bills of materials, specifications, and financial data may need to be protected.

A simple transaction such as a price request or a query about order status.

A business process that comprises a mixture of long-running and short-lived transactions.

Security Requirements

	Data encryption to ensure that content is not intercepted or corrupted during the lifespan of the transaction.
	Integrity maybe needed using persistent techniques such as XML signatures
	If rights and conditions need to be assigned across multiple tier channels of distribution, then the downstream tights can be assigned and enforced using XML

	Data encryption may not be required, if the data itself is short-lived (e.g., a stock quote).
	Traditional mechanisms such as SSL and HTTP Basic Authentication are usually sufficient

	Will require a flexible security solution that applies authentication and authorization more than likely using a federated approach such as SAML.
	If standards such as OASIS WSBPEL (Web Services Business Process Execution Language) are used then security will have to be customized even further.
	Requires the ability to select or negotiate the security based on the characteristics of a particular transaction, stringent security measures should not be applied to transactions that would not benefit from them. WS-SecureConversation and Liberty Alliance may be important.

5. Comparing Security Requirements for Web Services Maturity Levels

Discovery, Description and Integration

Dynamic Web Services

Collaboration and Orchestration

Federation

Description

This is standards-based business automation that uses the basic building blocks of Web services, such as UDDI, XML, and WSDL, for information sharing and business transactions. Consumers can make requests to producers and receive responses.

	Web services can reach one another and construct new services as needed.
	The business process itself is built on Web services.

Multiple business processes can interoperate through Web services.

	A business can participate in processes managed by other companies and tied together with SAML and federated identity standards.
	Organizations and services are autonomous but work together.
	The services infrastructure supports complex transactions.

Security Requirements

	Begin with threat containment
	Access control from traditional identity management and access control systems used by ERP and other business applications

	Threat containment
	May benefit from more sophisticated trust management solutions such as SAML.

	May make use of open standards-based OLTP Web services technology.
	Requires standards-based solutions for collaboration, such as: SAML, WS-Trust, Digital Signatures, XML Encryption

	Decentralized trust management what works with organizations and standards that promote them such as Liberty and .Net Passport
	Liberty Alliance
	WS-SecureConversation