I was reading through a paper ISF wrote on the security implications of a Service Oriented Architecture and was thinking about whether this is really that difference from the “non-Service-Oriented-Architecture”. Let’s have a brief look at that:
What is SOA?
I do not want to elaborate on this as I guess most of you know it already. I would just like to give you some links that could be interesting if you want to freshen-up your brain: SOA and Enterprise Applications and SOA FAQ.
What remains the same?
I am convinced that quite some challenges we have without SOA will remain and not change with SOA:
-
Security is not involved in the application development process or is involved but much too late to have an impact.
-
Design is made without having security in mind.
-
The implementation is done without security in mind.
-
People care about functionality, not about security
-
The development time is “too short to care about security”
What is new?
The points above are not new but they might have a different impact in a SOA architecture. The architecture itself is much more complex than it ever was before. I guess that no matter how hard you try, there will be the point you will lose control over which application really uses which service in your environment – at least if it reasonably complex. So, a security vulnerability in one service will have an impact on quite some applications and you might not even know on which ones (unless you switch the service off until people complain). This is not new as we have the same problem with standard components but complexity increases. On the other side, fixing the vulnerability is much easier as there might be just one version of the service out there.
Additionally interoperability is key, so are the standards. This in one of the reasons, why we are pushing for these standards to hard. This might make it much easier to handle security on the interface-level if you are able to influence the design and development of your services.
Last but not least, you will be relying your services on services for third-parties which you might not “only” buy but use as managed service. So the code, the service even the data is not under your control anymore. If we look at the incidents that were in the press over the last few months, these are mainly data losses because of either hacked DBs or lost DVDs/Notebooks. How secure is your provider then? Can you trust them? And, well, there are the SQL Injection Attacks people talk of so widely. How secure are the services you either offer publically or your vendor offers you from such attacks?
What can you do?
I would love to present a silver bullet here – unfortunately I do not have any. But I am convinced that there are a few fundamental things you could/should do:
-
Do the normal things right: Make sure that you have good, sound, state-of-the-art, business-oriented security processes in place that are supported by your management. The stress in this statement to me is on “business-oriented” and “supported by your management”!
-
Make sure you understand SOA and the corresponding standards. There is actually a good overview of the Web-Service-related standards.
-
Make sure that you do a proper due diligence with the third-party service provider. Do this at least as soon as you give them some sensitive data. We use a process we call Application Threat Modeling internally and you might be interested in learning more about this.
-
Define fundamental principles which are pragmatic and make sense in your environment. The projects have to be able to implement them! A good start for the development process is the Security Development Lifecycle.
-
The point which raises usually the highest level of controversy is when I come to the metrics for the architects and the security people. I am convinced that we have to force these people (I am one of them) to be more business-oriented. At the end of the day we are here to enable the business (within an acceptable risk level). So, I want you to think about measuring your architects and security people on the successful implementation of the architecture and the security principles in the projects. How often do you succeed and how often do you fail? This usually causes quite some discussions as these roles often are like “high-priests”: They do something incredible important but somewhere up in the clouds. We all want them to have an impact and at the end of the day we need to have an impact to the business. If we align our architecture with the business and the acceptable risk level we will be able to push it through – or where necessary escalate it to the management. And this is not theory. I have seen that working!
What is your view on this? Does this make sense?
Roger
No related posts.
