METODOLOGÍA DEL ESTUDIO

Information security challenges outlined in Chapter 2 are as follows:

 SOA depends on the network to transfer massages between service providers and service consumers. Without good management of risk and security management, SOA may introduce a security risk in the

56

 SOA makes use of service-orientation design principles when developing services. These design principles often make it difficult to attain information security in the traditional sense, and additional information security measures are needed to achieve information security (Kanneganti &

Chodavarapu, 2008).

 According to Gardiner (2008), 57% of participants in a survey conducted by Computer Associates (CA) were not planning to implement SOA because of information security issues and concerns.

 If a service is exposed over the Internet, which is outside the organisational firewall, an attacker can take down the service with exploits such as denial of service attacks, by taking advantage of XML weaknesses (Gardiner, 2008).

Gardiner (2008) argues that organisations need to control access to services by legitimate users, who must have correct application entitlements or roles.

Furthermore, information security should be enforced to ensure that message requests from service consumers are examined, and service consumers are authorised and entitled to perform the specified request (Gardiner, 2008).

There are a number of information security concerns that need to be addressed for SOA applications. According to Kanneganti and Chodavarapu (2008), information security concerns can be classified into two groups, functional and nonfuncitonal aspects of security. Functional aspects of information security include:

 Identification and authentication: verifying identity of users.

 Authorisation: ensuring service consumers have a right to perform actions they requested.

57

 Confidentiality: protection of information in the transport medium.

 Non-repudiation: gathering of audit information on the transactional path.

 Integrity: ensuring that the transported information is not tampered with.

 Protection against attacks: ensuring attackers do not have access to applications and information transported between those applications.

 Privacy: ensuring that applications and services do not violate the privacy or service consumers or application users.

Kanneganti and Chodavarapu (2008) argue that nonfunctional aspects of security do not relate to security, but they ensure that security solutions works well in an organisation. Nonfunctional aspects of security include:

 Interoperability: a concern that is specific to SOA, and it ensures that the security solution does not break the compatibility of services.

 Manageability: ensures that the security solution protects all services within an SOA environment, regardless of how different they are.

 Ease of development: this concern ensures that the security solution does not add a level of complexity within an SOA environment. Kanneganti and Chodavarapu (2008) argue that complexity of the security solution reduces its adoption.

The following section outlines functional concerns of security in detail, each linked to information security services defined in section 4.3.2.

4.4.1.1 Identification and authentication

The objective of identification and authentication is to ensure that the application system is accessed by legitimate users only (Von Solms & Eloff, 2004). Legitimate users are those who passed the identification and authentication process.

Identification and authentication in traditional applications is often performed in an application (Kanneganti & Chodavarapu, 2008). This means, as in Figure 2.1, the modelled application should have a copy of all the users with access to the

58

system. If username and password are used, an application should have a list of usernames and related passwords in storage. Most of the organisations have directory servers for validation of users within organisations.

Authentication and identification in an SOA environment is different from the traditional approach. In an SOA environment, a service can be consumed in different ways. Identification and authentication within an organisation may not be difficult because an organisational user repository can be used. An identification challenge might arise when services are consumed by other services within a different domain or by a third party, as it may be difficult to retrieve identification credentials. Furthermore, identification and authentication challenges may arise when a third party application consumes organisational service.

For example, in Figure 4.3 (above), before Calvin uses the loan application system, he must be identified and authenticated. Calvin has to provide his user ID, which is used for identification. Calvin‟s user ID is searched against a list of identifications stored in a user repository. If the user ID is not found, Calvin is denied access to the system. Therefore he is not able to send the payment information to the bank. If Calvin‟s user ID is found, he can then proceed to the authentication validation process. Authentication ensures that Calvin is whoever he claims to be. Calvin has to provide his password, which is compared against the provided user ID. If the password matches the user ID in a directory server, Calvin can then gain access into the loan application system. Considering Figure 4.3 (above), identification and authentication challenges may arise when a payment service from Bank A sends information to payload service from Company A. There might be no credentials sent to that payload service, which can be used for identification and authentication. Furthermore, there is no user or credential repository that can be used to identify or authenticate any service consumer that invokes payload the service.

4.4.1.2 Authorisation

Section 4.3.2.2 defines authorisation as an information security service, which ensures that authenticated users can only access the application functionality

59

assigned to them. Authorisation can only be enforced if the user passed the identification and authentication phase. In most cases, authorisation is based on roles assigned to the user. For example, the administrator may have access to all the functionality within an application, whereas the guest may have access to some part of the application.

Traditional applications have their own authorisation model, such as Role-Based Access Control (RBAC), or Access Control List (ACL) (Kanneganti et al., 2008).

Roles and rules used to indicate access to application functionality are normally built within an application or stored in a directory server.

In SOA applications, a single request of functionality may use multiple services.

Therefore access rules for all the service should be checked before the request is made. A concern about this is that third party application or services outside of the organisation might not have those rules, which pose an authorisation challenge. If access rules are coded in a service, services may not be reusable, which compromises SOA principles. Any other authorisation approach should address this issue.

In an SOA based application, modelled in Figure 4.3, authorisation challenges may arise when Bank A sends a message to Company A. The message from Bank A indicates whether or not it received and accepted payment information.

The response would then update Company A‟s data storage. However, there might be no credentials in a message from Bank A, which can be used to check if payload service is authorised to update Company A‟ data storage. Therefore, authorising the payment service from Bank A is a challenge.

4.4.1.3 Confidentiality

Section 1 of this chapter defined confidentiality as an information security service that is responsible for the security of information transported over the wire from one application to the other. Once confidential information is disclosed to unauthorised parties, an organisation may lose its public respect, or affected parties might pose legal action against the organisation (Stoneburner, Goguen, &

60

Feringa, 2002). Encryption is a standard method used to protect information transported across networks (Kanneganti et al., 2008).

To ensure confidentiality, traditional application implements a secure channel for transportation of information using Secure Sockets Layer (SSL) (Kanneganti et al., 2008). Information transported through SSL is encrypted, and it is good enough for traditional applications.

SOA applications may use SSL, but it is not sufficient (Kanneganti et al., 2008).

For example, in Figure 4.3, information from Bank A may be transferred over SSL, but once it reaches Company A, it is decrypted and no longer secured, which enables interceptors and administrators at Company A to clearly read the messages.

Confidentiality challenges arise when information is transported outside of the organisational boundaries, where it would be less secure (Buecker, Ashley, Borret, Lu, Muppidi, & Readshaw, 2007). In Figure 4.3, information sent from Company A to Bank A is not encrypted. Therefore, unauthorised parties may have access to it and manipulate it, which may put Capital Solution in danger.

4.4.1.4 Integrity

Integrity is defined as an information security service that ensures that only authorised parties can modify the information (Von Solms & Eloff, 2004). Integrity of information is lost if there are changes made to information intentionally or unintentionally. Once information integrity is lost, an organisation may continue to use corrupt information, which may lead to fraud or wrong decision-making (Stoneburner et al., 2002).

Traditional applications rely on SSL to enforce information integrity. However, in SOA applications, SSL is not an ideal solution in a transaction whereby multiple services are involved (Kanneganti et al., 2008).

61

In Figure 4.3, Calvin is the only legitimate user to update, delete or create the contents of the information in the loan payment process. Anyone besides Calvin is not authorised to change the contents of the message. One section of Figure 4.3 models Calvin sending the payment information to the bank. The payment information consists of ID numbers, account numbers and the amounts that must be paid to the applicants. Integrity challenges may arise when unauthorised parties such as hackers get hold of the transported information. They may change the ID and account number so that the money is deposited into their accounts.

4.4.1.5 Non-repudiation/Auditing

Section 4.3.2.5 defines non-repudiation as the information security service responsible for ensuring that parties involved in a transaction do not deny their actions at the later stage.

As with integrity, traditional applications rely on SSL to enforce non-repudiation (Kanneganti et al., 2008). SOA applications should not rely on SSL to enforce non-repudiation since non-repudiation is associated with information integrity, and SSL is not an appropriate technique to enforce integrity. According to Buecker et al. (2007), one challenge faced in an SOA environment is providing access to audit information across an SOA environment. In SOA applications, audit information is required from the start of the transaction to the end (Buecker et al., 2007).

In Figure 4.3, the enforced non-repudiation information security service should ensure that Calvin does not deny that he is the one who sent the payment information to the bank. The bank should also be accountable for participating in the transaction. If the wrong information is sent to the bank by any employee, there must be proof of a transaction and a person responsible for the transaction must be identified.

This section outlines the concerns of information security within SOA. It is clear that traditional approaches to information security do not always apply to SOA applications (Kanneganti & Chodavarapu, 2008). This section also outlines

62

security challenges for functional aspects, such as identification, authentication, confidentiality, integrity and non-repudiation. These security challenges motivate the importance of information security within an SOA environment. Therefore, it is important to look at possible solutions to apply information security within an SOA environment.

The following section discusses new security approaches for SOA applications.