Sunday, 22 September 2013

Security Radar Graphs - Capturing SOA security requirements

Securing an SOA is a complicated business. It isn't a single concept but various moving parts such as: encryption, authentication, and non-repudiation. Not only is there no "one size fits all", but this multi-dimensional nature means there isn’t even a single sliding scale for low, medium and high security. One service might need transport encryption (e.g. SSL) and non-repudiation but have no need for encryption at rest behind the firewall; another requires encryption end-to-end including at rest, but not need non-repudiation - neither is more secure, merely differently secure. In an SOA some security requirements will be enterprise wide (e.g. perimeter security), whilst others will vary on a service by service basis (e.g. authentication/encryption levels). This quickly becomes a complex picture.

Aside from the wasted expense, applying unnecessary security can reduce flexibility, increase complexity, and deny the benefits of the cloud. Obviously business requirements come first (it's why we're here after all), and tight budgets mean security needs to be targeted to where it's really needed. In this security vs flexibility consideration, one final aspect is worth considering: how does security affect SOA benefits? There's one obvious example, message level encryption can reduce the ability of intermediaries to validate messages, so the ESB or XML firewall can't stop invalid messages. Here a security option can directly impact a non-security aspect of the solution.

It's obvious that defining SOA security is complicated to say the least. This was a challenge we had whilst discussing security requirements recently. The solution we found was a radar graph showing options which looked a bit like this:

Looking at the graph:
  • The three axes above the horizontal (Network filtering, Network separation, Security location) will usually be determined for the architecture as a whole.
  • The two horizontal axes (policy separation, data at rest) could be decided on a service by service basis but will likely have wider impacts if security is increased (i.e. introducing central policy management will require new products, masking audit logs will potentially impact all services if a common logger is used.
  • The three axes below the horizontal can be determined on a service by service basis and as such can be included in the service NFR template.

In a future post I'll discuss the impact of the various options on each axis in terms of cost, flexibility and any other knock on effects.

No comments:

Post a Comment