usefulfor.com/security security dojo

9Jul/080

middleware and me (part 2)

hack-fu by: rux0r

In the last article (middleware and me (part-1)) we looked at the concept of Middleware security and why it is often a neglected area. In this article we are moving on to look in detail at the security features that can be employed to protect this type of software. For the purposes of these discussions we are going to be focussing on the IBM Websphere MQ product, hopefully in the future I will be able to contrast these discussions against the security controls employed by a number of other messaging technologies.

If you are going to understand how to secure an installation of Websphere MQ it is important to think about the risks it can expose. Often it is used in critical applications and therefore any vulnerabilities in the technology can be mapped directly to the business risk. In this discussion we are going to focus on our fictional company of Widget Corp. They make widgets which are low cost fixings used for a number of different purposes by a wide range of different customers.

The company is formed of several individual business units and has decided to use Websphere MQ in its manufacturing process. The typical business process flow of an individual business unit is as follows: -

A diagram that shows the different processes inside the company, from the customer to the shipping department

For more information about the fictional Widget Corp please refer to the Websphere MQ Security White Paper (mirror #1, mirror #2).).

Given the importance of this process the greatest risks to the business in order of significance are as follows: -

  • Loss of Availability – With a low cost and therefore profit per unit it is vital that the number of widgets that are produced is maximised. The transfer of messages from the customers to the manufacturing plant is what keeps this process moving and therefore any unavailability in the system means loss of manufacturing time. In addition, if customers do not receive their orders on time they will take their business elsewhere.
  • Damage to Integrity – Customers want their orders when they are promised to them but they also want the correct order to arrive. If the integrity of the message data is affected then orders might not be manufactured, may be delivered to the wrong customer or may contain errors. In any of these situations a customer will not be happy and will turn to an alternative supplier.
  • Breach of Confidentiality – The messages being transferred across the business contain a large amount of information that would either be of interest to a competitor or would disclose information about the customer. If this data were obtained it could be used either for competitive advantage or for use in negative publicity against the company. This could result in damage to the brand or more effective competition from other companies in the industry.
  • Lack of Accountability – When facing an audit it is vital that the company be able to demonstrate how its business process is transparent and can not be used for illegitimate purposes. Failure to be able to demonstrate this could result in fines or other action being taken if the company is suspected of engaging in such activities.

These risks highlight how the security of the Middleware used by Widget Corp is of critical importance to its ongoing success. These risks can be directly mapped to a number of common security requirements and are common across all technologies and products. If you are examining a technology with such a close match to a fundamental business process it is important not to shy away from the importance of understanding the actual requirements for security controls. A mapping of the top three of the previously highlighted business risks against common security requirements is pictured here.

The diagram shows the relationship between business risk (confidentiality, integrity and availability) and security requirements (transport level security, authentication and authorisation)

When using the Websphere MQ product there are a number of security features that can be used to meet these security requirements. An understanding of the relationship between these requirements and the features is critical and can be observed here: -

The diagram shows the relationship between security requirements (transport level security, authentication and authorisation) and Websphere MQ security feautures (SSL and TLS, MCAUSER and Security Exits)

As can be observed in the diagram there are three primary security features that are available within Websphere MQ when considering network based access to the software. Each of these features is described briefly with respect to its functionality and the potential impact on the system if it is not used: -

  • SSL and TLS Encryption – A wide range of ciphers can be configured to protect any communication of Websphere MQ data across a network including enforcing a requirement for a system to present a client certificate at connection time. The use of a given cipher or client certificate controls can be tested for on a channel by channel basis and the error codes that are returned enable the status to be accurately determined. Failure to use these controls could result in traffic sniffing attacks being a viable method for compromising data confidentiality and integrity.
  • MCAUSER – Each channel can be protected with a user context under which the messaging transactions take place. This can be reviewed by investigating channel settings using Inquire commands which are standard Websphere MQ operations. If MCAUSERs are not defined it could enable a user to access objects for which they have not been granted authorisation to do so.
  • Security Exit – An external application can be defined which MQ hands off the responsibility of user authentication to and can enforce both user and IP addresses restrictions. If an exit has been configured for a channel Websphere MQ it will indicate this when attempting to connect. If a security exit is not defined for a channel it means that no user authentication can occur, system authentication can still occur using SSL but this has no direct mapping to user based access control on the Websphere MQ system itself.

When examining the technology it is important that the role of each of these be understood, how their presence can be tested for and in which circumstances they are required. Given that these security controls are available it could be assumed that they are always utilised. However, this is a false assumption and often one if not all of these features are either not used or not used with appropriate coverage. Therefore, on the majority of installations there are plenty of security vulnerabilities just waiting to be discovered by someone who looks in sufficient detail.

This article has provided a basic overview of the mapping between risk and security controls associated with the Websphere MQ product and the features that can be enabled. For more information about these have a read of the white paper discussed earlier. Next time I will begin to discuss how a security assessment from the perspective of a penetration tester can be mapped out and will examine some new features of dradis that can help this to be achieved.

Popularity: 8% [?]

Share and Enjoy:
  • Digg
  • del.icio.us
  • Slashdot
  • Technorati
  • Meneame
  • Twitter
Filed under: hack-fu Leave a comment
Comments (0) Trackbacks (0)

No comments yet.


Leave a comment


No trackbacks yet.

Popular Posts

Categories

Archive