136 Copyright © 2009 Open Geospatial Consortium, Inc.
13 Recommendations
As a result of this work, mainly based on the evaluation of vulnerabilities and potential attacks for the current OGC Sensor Web Services specifications, we like to give
recommendations for implementing a Secure Sensor Web.
First of all we like to point out that it is important to implement all relevant requirements and not just one. For example, when implementing access control but the communication
is not secured, an attacker could steal security context information such a a session token or an identity token which would most likely cause the access control system to grant
requests, based on the stolen security context information.
Of course, it is not easy to say in general which requirements are to be implemented and in which way as this depend on many factors: i The architecture itself and which
services are deployed in which security domain, ii is there direct trust relationship between security domains, iii which informationobservation shall the system deal with
and is it classified, etc. One dominant questions is ―Do I have to use WS-Security with SOAP or can I do HTTP+TLS‖? This mainly depends on the architecture and the
orchestration of services. But as a rule of thumb, it is a good idea to use WS-Security and SOAP, even though the other variant using HTTP+TLS might also be applicable.
We like to point out the following recommendations knowing that there will always exist specific cases where these recommendations might not represent the most elegant
solution. However, the list of recommendation can be understood as a framework for securing the Sensor Web.
13.1 Use Message Level Security
W think, that the sufficient and relevant level of ensurance for implementing all relevant security requirements as outlined in earlier sections of this ER can only be undertaken by
leveraging message level security. The alternative – network level based implementation
– is difficult to achieve as it very much depends on underlying network administration. And, because the joining and leaving of parties in a Secure Sensor Web can much easier
be reflected and administrated based on security implementation on message level. The last argument for message level security is that the continuous protection of information
exchanged among services provided by different organizations is to be ensured, independent of different network segments that are potentially owned and administrated
by different parties using their own policies and service chains that might be required.
Independent of implementing security requirements such as Integrity, Confidentiality and Authenticity requires the existence of a Public Key Infrastructure PKI. Even integrity
and confidentiality could be guaranteed without a PKI, it is recommended to use X.509 certificates.
Copyright © 2009 Open Geospatial Consortium, Inc. 137
For the implementation of trusted Audit and Alarms, it is also relevant to have a PKI in place and trusted third parties that undertake and guarantee the correctness and
confidentiality of audit information.
13.2 Services shall support SOAP and WS-Security
In simple architectures that are based on transparent chaining, only direct communication links exist between the client and many services. Here, the use of HTTPS can be
leveraged in order to secure the communication and the security context information that is exchanged between the client and the secured service.
But in a more generic architecture, where a translucent or even opaque chaning of services shall be possible, the use of SOAP based interfaces leveraging WS-Securtiy for
securing the communication is recommended. Depending on the security model that is to be supported, X.509 certificates or other types of tokens must be created. This requires
naturally the existing of the associated infrastructure.
13.3 Describe security constraints for the service using WS-PolicySecurePolicy
