30 Copyright © 2009 Open Geospatial Consortium, Inc.
9 Security Discussion for the Sensor Web Services as defined by the Baseline
9.1 The Services Baseline
The objectives of the OGC Sensor Web Enablement SWE Initiative are outlined in [69] and [70] as to
―… encompass specifications for interfaces, protocols and encodings that enable discovery, tasking and access of sensors, acquisition of sensor data, and discovery
and access of sensor- processing services.‖ [70]. The baseline documents for the Sensor
Web to be considered within this Engineering Report are: Service - Standards
Sensor Planning Service SPS, version 1.0, OGC 07-014r3 Sensor Observation Service SOS, version 1.0, OGC 06-009r6
Service - Best Practices Document Sensor Alert Service SAS, version 0.9, OGC 06-028r3
Language - Standard SensorML, version 1.0.1, OGC 07-122r2
OM, version 1.0, OGC 07-022r1 TML, version 1.0, OGC 06-010r6
9.2 Communication Patterns applicable to the Baseline
The most important aspect from this ER’s perspective is that none of these documents addresses security issues such as possible attacks and their outreach. In order to find the
existing vulnerabilities, see the potential attacks and understand the impact of exercised attacks, the following sections outline the services interfaces and the exchanged
information under the security focus.
But before we do this, we like to give a short introduction into the two communication patterns and their security implications important for this ER:
The requestresponse communication pattern is described in [71] section S003 RequestResponse, such that
―Two parties wish to conduct electronic business by the exchange of business documents. The sending party packages one or more documents
into a request message, which is then sent to the receiving party. The receiving party then processes the message c
ontents and responds to the sending party.‖ [71]. The document further states that it is implementation specificdependent if this communication pattern
can be considered synchronous or asynchronous. A synchronous implementation would be based on HTTP, where the same communication channel is used for exchanging
request and response. However, SOAP over HTTP could allow an asynchronous implementation, depending on the processing logic of the receiver. If the receiving
service queues incoming messages for further processing, the client service might only
Copyright © 2009 Open Geospatial Consortium, Inc. 31
receive a confirmation about this as a synchronous result of the request. After processing is finished, the service could send the response to the client. But this obviously requires
the client to provide a network endpoint to establish a communication. The latter implementation also requires the use of unique message IDs that are protected towards
integrity, so that the calling and responding service can reference the request and the response, not exchanged within the same communication.
The notification communication pattern is described in [71] section 3.24 S200 Event notification, such that
―An application subscribes to notifications of certain named events from an event source. When such events occur, notifications are sent back to the
originating application first party notification or to another application third party notification.‖ [71]. This pattern actually requires a subscription of the receiver to the
sensor of the event that can be implemented according to the requestresponse communication pattern. The actual notification can according to [71] be implemented
according to the ―fire-and-forget to multiple receivers scenario‖ also described in [71],
section S002. This scenario does not guarantee the delivery to the sender, as it is implemented without acknowledgment from the receiver to the sender. The
implementation can be based on any distribution technology. One popular implementation is XMPP, but also SOAP-enabled event receiver services are possible, so
long the implementation manages to send notifications to subscribed receivers only.
9.3 Interface Summary for Baseline Services
