Copyright © 2009 Open Geospatial Consortium, Inc. 25
A possible countermeasure is to do a good sanity check on the SQL statement dispatching it to the database.
7.3.2 Example Attacks applicable to XMPP Servers
The Sensor Alert Service SAS is leveraging XMPP with Multi User Chat MUC rooms to notify subscribed users about alerts. It is therefore relevant for this ER to also take a
look at attacks, specific to XMPP servers. For this ER, we will only look at the potential attacks that can occur on the application level and those specific to our scenarios. In
particular we assume that the communication between the sender
’ and receiver’ client and the associated XMPP servers is secure. However, it is important to differentiate
between an architecture, where the receiver’s XMPP server can be trusted or not.
1 Effect of stolen Multi User Chat room id
This attack assumes that the adversary is in the possession of a valid chat room id and can spoof the client’s identity to gain access to the chat room. For the Sensor Alert Service no
authentication is used. It is therefore sufficient for the adversary to read the SAS response on a subscribe operation to connect to the MUC room.
After gaining access to the multi user chat room, the adversary can see other subscribed clients for this alert and can of course read all alerts in that chat room and he can also
flood the channel that might result in the fact that alerts are not being delivered caused by the lack of available bandwith if these functions for the MUC are not disabled by the
creator of the channel or the XMPP server. In order to prevent the adversary to spy out other subscribers, appropriate privacy settings need to be set. Because it can be assumed
that the provided multi-user-
chats applicable to SWE are not moderated, a ―client dropped‖ criteria reflecting the maximum throughput can be set. The original intension
was to prevent spamming over XMPP channels. Another effect of the stolen id is that the adversary can record all alerts that are broadcasted by the SAS on that channel. The
security features of TLS and SASL that are already included in the XMPP protocol do not prevent this. In order to ensure that the adversary cannot tape alerts by simply
connecting to an alert channel can be mitigated by using MUC with authentication. In order to obey to the requirement that classified alerts need to be confidential to users of a
particular clearance, authentication alone is not sufficient.
2 High jacking the receiver’s untrusted XMPP server
For the scenario, where communication takes place between a trusted and a temporary trusted domain, the risk exists that the administrator of the temporary trusted domain has
bad ―friends‖. The high jacking of the XMPP server causes a lot of trouble. We assume that the intent for high jacking was not to shutdown communication as that would exploit
the attack. Instead we assume that the adversary likes to take advantage by taping alerts and spying on other clients subscriptions. In contrast to the previous attack where the
adversary could only spy on presence information in that one channel, now the adversary has access to the presence information of all clients connected to the XMPP server. In
order to prevent the taping of alerts, individual message confidentiality can be applied by
26 Copyright © 2009 Open Geospatial Consortium, Inc.
the sender. But because the adversary can potentially record a large amount of alerts, cryptographic strength needs to be ensured.
8 The Approach for Securing the OGC Sensor Web Services
In order to propose a security architecture for the OGC Sensor Web Services to make them usable in the intelligence domain, it is important that the result can pass evaluation
criteria similar to those outlined in ISO 15408 Common Criteria. The challenge for this ER is that those evaluation criteria for the OGC Sensor Web Services does not exist, but
still a security architecture is to be proposed in such a way that it is likely to pass evaluation tests created in the future. In order to proceed in this direction, it is important
to define a firm set of requirements, as outlines in TCSEC and ISO 10181 and propose standards based implementations, as we see this as the most promising way forward.
Looking at the challenge from Mars, it is important that the end user of the Sensor Web Services can have assured confidence in the architecture in such a way that
sensor tasking and configuration of alerts can be trusted, hence not modified by any unauthorized user, and
all alerts from a SAS and observation notifications from a SOS show up at the end user’s client, and
that the end user can trust the incoming alerts to get the attention and become an important part of decisions that might have huge impact.
Zooming in and looking at the challenge from Moon unveils the fact that the system is distributed, based on SOA and is cross security domains. This makes it important that the
end user can actually apply trust verification methods to information either received by request or via a notification. In order to achieve that, trusted authentication services are
required that issue identity credentials and allow secure verification. In addition, it is important that the information is protected towards integrity; all the way from the
originator to the ultimate receiver. In a Service Oriented Architecture, it might happen that the information is forwarded processed by many intermediate services, perhaps
providing additional pieces of information. But still the integrity of certain parts of a message needs to be guaranteed. This can be compared to the statement in the ISO
standard that the distributed aspect of the system shall not make any difference to applying security to a single system. Applying message level security can assure the
integrity of the information and its authenticated origin and in addition provide flexible protection towards confidentiality. However, the entire system is only useful, if the
services and the communication is available whenever needed. This requires countermeasures for denial of service attacks.
Zooming in and looking at the challenge from a technology point of view, the implementation of message level security fits very good to Web Services, as they
exchange XML structures messages. WS-Security and related standards build the foundation to do so. It supports that integrity and confidentiality of classified information
assets can be assured, but also involves extremely complex configuration of different security services and the secure distribution of X.509 certificates, definition of access
rights to prevent unauthorized disclosure. All so much more complicated than the simple
Copyright © 2009 Open Geospatial Consortium, Inc. 27
deployment of a Virtual Private Network VPN or leveraging SSLTLS connections. But for the Secure Sensor Web architecture, it is important to ensure the flexibility of
applications to use any service of a trusted federation in any orchestration. This makes the roll-out of a virtual network almost impossible; and in use cases where no direct trust
relationship exists between the communication partners, the roll-out of a VPN is probably not possible. With Web Services, trust between these entities can be brokered using
Secure Token Services for example. Also, it is important to distinguish between the identity of communication end-points such as security gateway that is being used for
establishing a SSL or TLS connection and the actual identity of the end-users, which execute the services and which exchange the information. It is also important to notice
that the mutual authentication on a SSL connection only lives as long as the session lasts, but according to the requirements from the TCSEC, we need to ensure persistent
authenticity, integrity and confidentiality. Using a SSL or TLS communication would protect the information only as long as it is in the secure pipe, but would be unveiled
immediately afterwards. Thinking of a sequence of services, all intermediate services would have to be trusted by all partners, as they see all information in the clear. This also
does not seem to be feasible for the context of this ER.
In summary, the flexibility of message level security can be leveraged to individually implement all mandatory requirements for implementing a Secure Sensor Web. However,
many different aspects of attacks and vulnerabilities need to be investigated to ensure that the overall system, based on OGC Sensor Web Service instances can be trusted and pass
evaluation.
As the SAS leverages XMPP for the notification of alerts it is also essential to apply security measures to that protocol, as it might transport alerts of different classification
levels inside the same MUC. The vulnerabilities and potential attacks on XMPP to get unauthorized access to the alerts read, modify or even delete them are aspects for the
evaluation. Looking at the list of extension available for XMPP XEPs, it becomes clear that the concept of message level security can also be leveraged with XMPP. This would
provide a seamless security model that where easy to implement and evaluated as the security concepts are the same for OGC Sensor Web Services and XMPP.
During the next sections of this ER, we will evaluate for each OGC Web Service the interface vulnerabilities and the possible attacks as well as their outreach if exercised,
based on the Internet Threat Model. Then, we will introduce concepts for securing the service interfaces to meet the outlined requirements, using existing standards and
technologies. We will also introduce concepts for ensuring authenticity, confidentiality and integrity of the service requests and responses. To be comprehensive, we will
introduce known vulnerabilities in standards used to make the reader aware of potential pit-falls. For example, the W3C released a XML Digital Best Practices Draft Paper on
November 14, 2008 talking about the danger in using certain transform algorithms.
8.1 The Foundation of Message-Level-Security
