1 Raindrop

Build Security In to your SOA

Thomas Erl posted the Top 8 SOA Adoption Pitfalls, and, hey wouldn't ya know, security checks in at 7:

#7 Not Planning for Web Services Security Organizations tend to start small when first building SOA with Web services. The extent to which Web services technology grows within a given environment is typically related to the comfort level developers and architects have with the overall technology framework. Once services begin to take on greater amounts of processing responsibility, the need for message-level security measures as well as security controls that apply to shared services begin to arise. The WS-Security framework establishes an accepted security model supported by a family of specifications that end up infiltrating service-oriented application and enterprise architectures on many levels.

Hmmm...infiltrating...I like that. Let me infilitrate your car with airbags and ABS.

Even if your vendor platform does not yet provide adequate support for WS-Security, and even if your current SSL-based implementation is meeting immediate requirements, it is advisable to pay close attention to the changes that are ahead. Proceeding without taking WS-Security (and its emerging extensions) into account will inevitably lead to expensive retrofitting and redevelopment. This impact will be amplified when organizations begin to grow their service inventory and decide to only then apply the appropriate security

So if I turn this "Not Planning for Web Services Security" around can I say we should Build Security In to our Web Services? It is hard to retrofit security, and not that hard to build it in in the first place. You don't have to go back and restest and redeploy all your transactions for example. WS-Security (and SAML) is a good place to start, then move on to WS-Trust, XACML, et. al. It is still surprising when you talk to vendors, like ESB vendors, who should be in prime position to take advantage of WS-Trust yet they really don't even have it on their roadmap yet, in some cases.

Security is part of the friction that comes with integration. As mentioned in Only Sustainable Edge, the real trick in integration is making sure that the friction is productive friction and not dysfunctional friction, Web Services security standards give a clear path to that, because they deliver interoperable message level security which the industry has heretofore lacked. So systems may emerge from a Web Services integration with security domains that can compose together instead of representing abritrary boundaries because of technical constraints.

Bulletproofing your SOA

Andrew Nash of Reactivity has an article on Bulletproofing your SOA, hat tip Gary Smith. SOA is about integration, so lots of viewpoints must be considered. Andrew Nash poses the following questions from the following perspectives:

The infrastructure we create to enable SOA should be considered by participants in the SOA development process from architects (“Where can I offload supporting services?”) to developers (“Who is taking care of policy implementation for me including privacy and security?”) through operations and security staff (“What policy settings are implemented in the infrastructure that allow me to make adjustments without involving the development folks?”)

The five key areas to address in the article are:

1. simulating the production environment in development.

2. articulate policies for consumers and providers and make trade-offs regarding compatibility, security and throughput

3. creating a suite of test messages for both the service customer and the service provider

4. exercise each consumer and provider separately to evaluate every policy and potential exception that may be encountered in production

5. virtualization and configuration must be verified as cost-effective and scalable

These rules ring true, and illustrate where projects go awry, as always it pays to look at security issues from both the service requester and service provider viewpoint. I particularly liked the section on executing tests which has a summary list of test cases:

Validation of acceptable and rejected authentication methods

Correct mapping of identities and translation of credentials

Can bilateral handshakes be handled efficiently?

Schema validation

Authorization – are trusted identities granted correct access to services?

Content-based routing: testing for a different routes and correct invocation of service choices

Message transformation

Protocol mediation

Firing malicious content at the service; what happens if there is bad, mal-formed content in the XML?

There is a lot of work to be done by gateways. People like to bash them, but if you don't have one you end up having to code a lot of stuff by hand, and expose your services to a lot more risk. So the question really becomes - do you invest in building a framework of patterns to handle all of these services or do you identify best of breed players to help to fill these gaps.

Combining risk and effectiveness assessment to make risk management decisions

More from MetriCon, check out Bryan Ware's presentation The hard choices are deciding between projects within a sector and between # 2 and # 3.

Risk	High	2 Discount for low effectiveness	1 Best investments
	Low	4. Apply minimal funding	3. Incentivize high effectiveness
		Low	High
		Effectiveness

This ties to Fred Cohen's work on medium assurance problems.

MetriCon software security metrics track

We just completed the software security metrics track at MetriCon 1.0. The slide decks from the track are here. We followed Steve Bellovin's talk which recapitulated a number of issues he described in IEEE S&P article on what he terms the infeasibility of security metrics. I will blog more about this in the future, the IEEE S&P article followed my article on Introduction to Identity Risk Metrics in the same issue. Steve is looking for a way to use metrics to measure the strength of the system, which we do not have yet. But it does not mean that metrics are useless for security or for risk. At a more granular level, we can use metrics to illustrate parts of the security equation, like availability, integrity, authentication, and so on, even if we do not have the uber way to roll all these things up yet. Also, there is another pattern that is not much used fast and cheap metrics. Would you rather spend a billion to build a rocket launch to a planet or just take $1,000 sensor disks and fling them at a planet and see if some gas or chemical exists?

The first talk in the track was Brian Chess who discussed his and Katrina Tsipenyuk's work on using Fortify to generate software metrics over time. Their proposed metrics looks at false positives and false negatives and gives a scoring trend. The main thing I liked was how they showed two distinct views over their raw datasets (effectively scoring) for auditors as well as developers where each group cares about different things.

Then we had Pratyusa Manadhata who explored his work on attack surface metrics. In this case the attack surface metric decouples security metrics for channel, data, and methods. This makes a many sided view and is particularly useful for technologies like web services where these services are decoupled logically and at runtime.

Jeremy "Just Do It" Epstein talked about a vastly underdiscussed area - Good Enough Metrics. His presentation contains a list of specific examples that are cheap and easy to get today that you can use to get started with software security metrics. He differentiated between standardized and non standard risks, and he has an interesting formula that has a union of security/insecurity x popularity x ubiquity.

Thomas Heyman and Christophe Huygens gave an interesting presentation on early work on using patterns for richer metrics. What is so valuable about this approach is that patterns allow for the metric to capture contextual structure and behavior, and that is so critical to security.

Lastly, Pravir Chandra examined the interesection of remediation and complexity using field experience from Secure Software. In other words, can I correlate from a set of vulns and bugs back to the complexity of the code under development.

Risk Management culture

Blogging from MetriCon. Yesterday, Dan Geer shared this table on risk management cultures: Pathologic, Bureaucratic, and Generative. Working as a consultant, I get to work with companies of all sorts...

Pathologic	Bureaucratic	Generative
Don’t want to know	May not find out	Actively seek
Messengers “shot”	Heard if they arrive	Messengers rewarded
Responsibility shirked	Compartmentalized	Responsibility shared
Failure punished	Local repairs only	Failures beget reforms
Ideas discouraged	Ideas beget problems	Ideas welcomed

from: Reason J: _Managing the Risks of Organizational Accidents_, Ashgate Publishing Limited,
1997.