Security Radar Graphs (2) - Implications of security requirements

As seen in the last post, radar graphs are a useful way of capturing the security requirements of a service or set of services. As promised, this second part both defines what is meant by the different levels on each axis and notes some basic considerations which need to be made when making a selection for any given aspect of SOA security.

To recap, the radar graph in question looks a little like this:

So if we take each axis in turn are the descriptions and the considerations which they warrant. Sorry the formatting is a bit ugly - Blogger doesn't seem to support tables very well.

Network Filtering

The level to which your network security filters who can get access to your SOA.

• None: Anyone on the internet can access services
• No reduction in traffic by the network layer, this increases the need to carefully consider network separation to prevent common attacks.
• Firewall: Partners access services over the internet - restricted by firewall settings (e.g. IP filtering)
• IP spoofing is possible. 
• Cloud partners can often change IP addresses - can be difficult to maintain an accurate white-list and a given IP range can't be guaranteed to be that of a trusted partner. 
• Multiple potential consumers exist within the partner network (in the partner IP range). These consumers are indistinguishable based on IP address. 
• Therefore... whilst more secure than "None", network separation and/or authentication are still important.
• VPN/Leased Line: Selected partners can access services via a secured channel
• Some external providers (especially cloud providers) may not accommodate such a channel 
• This potentially exposes the core network outside of the data centre - consider the importance of firewall rules to restrict the services that can be accessed (e.g. just the ESB) as well as authZ/authN.
• Closed Network: No off site access to services
• No benefits of partnerships, outsourcing, cloud technology etc 
• Whilst secure, this may not be a possibility given other these considerations

Network Separation

The level to which your network security isolates your SOA from external access.

• None/Reverse Proxy: Basic reverse proxy (not XML aware gateway) is used to separate consumers from the ESB. This sort of proxy may be able to provide SSL but not WS-Security. It cannot detect attacks SOA specific types of attacks (e.g. XML injection)
• The whole ESB must be considered externally facing (whatever network filtering determines 'external' is). 
• If network filtering is 'none' (i.e. open to the internet) this approach is woefully inadequate, if the only external access is via a VPN from a trusted partner then this may be acceptable.
• Second ESB: Have an 'externally facing' ESB (behind the reverse proxy) before messages get to the internal ESB (e.g. this MSDN pattern)
• This can mitigate against certain problems (e.g. DoS attacks impacting the internal ESB), and can provide a layer of separation. 
• It won't guard against attacks as thoroughly as an XML Gateway. 
• Will likely require more custom code/detailed config to detect attacks than a COTS XML gateway would do as a mater of course. 
• As with 'None/Reverse Proxy', the nature of the network filtering will influence the applicability of this solution.
• This solution also necessitates additional services to pass traffic from outside to the internal ESB - thus additional config/maintenance and licensing costs to implement the 2nd ESB.
• XML Gateway: Buy a COTS XML gateway specifically designed for exposing services to the internet (e.g. Vordel/Oracle API Gateway, IBM DataPower, Cisco ACE). This is significantly more powerful than a reverse proxy because it's XML aware, and has inbuilt security and threat detection
• Initial cost outlay can be high, although the ease of configuration vs a second 'external ESB' can balance this a bit.
• The hardening of such devices is more expertly developed and tested than custom config/code so is not only better able to detect complex attacks but also gives better peace of mind.
• These devices can offer additional benefits in terms of security policy management (see below).

Security Location

Where in the architecture security is enforced.

• Perimeter: Security is only applied at the perimeter, internal traffic is considered 'trusted'.
• Only protects against external threats, despite research suggesting 70% of breaches are internal. 
• In an increasingly interconnected service oriented world, is this internal/external split an oversimplification - can we keep thinking in these terms?
• ESB: Security is applied to consumers of ESB services, but no security exists between the ESB and back-end systems
• Is there anything to stop consumers going direct to a back-end service if only the ESB services are secured (e.g. internal firewalls)? If not this may not be good enough.
• Endpoint (trusting): Services on the ESB and back-end services are secured, however back-end services only validate that their consumer is the ESB, and trust the ESB to perform downstream validation.
• This is a generally good model so long as the answers to the following questions are 'yes':
  
  1. Do system/data owners trust the ESB development and security governance structures?
  2. Does this trust delegation meet the audit requirements for back end services (the back-end system doesn't need to record the ultimate consumer)?
  3. Are services accessed only via ESB and not directly?
• Endpoint (aware): Services on both the ESB and back-end are secured, and validate the ultimate consumer. The ESB merely mediates the connection but doesn't break the security chain.
• Must be done carefully to maintain SOA decoupling principles - if back-end systems are aware of which systems are accessing them it makes change more difficult and blows a hole in the idea of fully decoupled systems. So long as this is done with some thought it's not a big problem (e.g. by separating security from service configuration and with appropriate governance).
• Endpoint security might not be an option for many legacy systems and certainly not distributed policy based endpoint security. This is especially true if the ESB is connecting via an adaptor rather than by calling a web/rest service.
• Even if this possible, systems may require re-engineering to achieve this.

Policy Separation

The level of separation between security policies and service implementation.

• None: Security hard coded into service endpoint
• A reasonably bright 6 year old should be able to point out why this is a bad idea so I'm not going to say much about it. Unless it's impossible to avoid, this a bad option.
• Config: Security in service but separated into configuration rather than code - can be changed without redeployment
• This is more sensible, and is often the way that policy is applied. It makes ongoing maintenance a bit more difficult than with a central policy, but there may be any number of good reasons to do this:
• Technology doesn't support central security policy.
• There isn't the desire to pay for a central management.
• There isn't sufficient governance to drive a more joined up approach, each service developer has to do the best they can (not a perfect reason obviously).
• Central Policy:  A policy is configured and maintained at a central policy server location and disseminated to endpoints automatically
• The nirvana of policy administration is having all policy regardless of what/where it's applied stored in a central security policy server. 
• Obviously there are cost implications and many existing services/technologies may not support this (as ever legacy is a big challenge). 
• This is interesting and complex enough to write whole books about - here we'll just say it's nice if you can do it.

Authentication - System

The way a service identifies which consumer is invoking it.

• None: Anyone can consume service
• Even if service has no security requirements this makes it difficult to enforce governance (i.e. registration) and keep track of consumers. This governance answer can alternatively be addressed with a UDDI registry but if that's not your approach then authentication can be useful to ensure you've not got any unknown consumers. 
• If you don't know who is consuming a service how can you know when it can be switched off?
• Transport: The transport medium confirms consumer identity (e.g. mutual SSL certificates)
• This can be more difficult to manage and change than credential based authentication. 
• It can also be harder to handle multiple 'hops' across intermediates whilst still keeping track of the originator's identity.
• Credential: A credential embedded in the message identifies the consumer
• Credentials can authenticate the sender however this relies on the message being secure to ensure the message isn't altered, and to ensure the credentials aren't captured and used to send future messages. 
• Unless the network is completely secure (if there is such a thing) this requires a level of encryption (see 'Data in flight').
• Digital Signature: The message is hashed and digitally signed
• Signatures can prove not only the identity of the sender, but also confirm that the message has not been altered in flight. This can also useful if the message is sent over an insecure medium as the credentials cannot be read and replayed.
• As with message level encryption (below), if the credentials have to be passed downstream then the message cannot be altered. This makes the decoupling (type mapping) benefits of SOA more difficult to realise.
• On one hand keys can be a little more difficult to manage than credentials, then again given their asymmetric nature they can be distributed easily and securely because only the public key needs to be sent from the consumer to the provider and can be done so without any concern about interception.

Authentication - User

The way a service identifies what end-user has caused the service to be invoked.

• None: No end user identification or user involvement
• For example a system calls a service based on a timer.
• Trust: User is validated by the consuming system and any authN/authZ in the middleware is based purely on that system (see Authentication - system)
• Can the end-system be trusted to restrict access? If so the service can delegate this responsibility and merely authenticate that the consumer is a trusted system.
• This assumes that audit requirements in the back-end system do not require knowledge of end user. If the service is performing an update this might not be true.
• Corporate: Access is controlled based on credentials held in an organisation's user list (e.g. against corporate Active Directory)
• Partner: Access is controlled based on credentials for internal users or partners users (e.g. against Active Directory Federation Services)
• Do both partner organisations have federated AD?
• Global: Access is controlled based on global user Ids / social sign-on e.g. For self service user accounts for websites
• Much more complex identify management suites required - although it's hard to imagine when this sort of end user account would be trusted within the SOA rather than used at a web/mobile gateway and trusted.

Data in flight

The protection given to data whilst in transit between consumer and provider or vis-versa.

• None: Unencrypted
• Is any data sensitive? 
• Is it on a trusted network (e.g. internal data centre, not the internet)
• Transport Encryption: Encrypted transport e.g. HTTPS or queue encryption.
• At any point where the transport terminated this terminating system (e.g. ESB/proxy/gateway) must be trusted. Support staff can review this information, the system may log this in plain text. If the intermediaries are trusted this maybe sufficient.
• Partial Message Encryption: Key message elements are encrypted e.g. XML Encryption of payment details.
• Where intermediates are not trusted this is a great solution. There are no problems with intermediaries, and it makes the whole question of masking (see 'Data at rest') far easier if any messages logged by the middleware are logged as encrypted messages.
• There are downsides however: 
• Once encrypted, the data in the message cannot be validated by the middleware. This reduces some of the benefits of the middleware in stopping potentially poor data 'at the front door'. 
• This can also introduce security problems of its own, as the perimeter security cannot be as thoroughly applied to encrypted messages. For example an encrypted message (or encrypted element) can't be scanned - e.g. for SQL injection, XML explosion attacks.
• Full Message Encryption: The whole message is encrypted.
• The same as the above but the downsides are exacerbated.

Data at rest

The protection given to data when not in transit over the network.

• None: Data at rest within the architecture is not protected
• This is fairly common from what I've seen - data at rest is stored within the core of the network and not encrypted although obviously it's protected by the OS/network security.
• Masking: Data is masked when written to intermediate storage e.g. ESB logs
• One of the key considerations which needs to be made for each service is can data be logged to audit/exception logs? If not how do we implement field level masking? Are only some fields masked or do we mask all body data? 
• How does this impact the ability of support teams debugging?
• Encrypted:  Data is encrypted as it's written either in part (field level encryption) or at the level of complete message or even complete database encryption.
• Is logging done to a DB or file system? Does the FS/DB support encryption? Are messages already encrypted? How frequently do these need to be retrieved? Can the support staff easily decrypt to be able to fix issues?

Right that's all for now - sorry that turned into a longer post than I'd expected when I started thinking about this topic. Any thoughts, omissions etc feel free to add them in the comments below.