Rational Survivability

Security is NOT the Primary Limiting Factor Inhibiting SOA's Growth

Peter Schoof over at eBizQ's Twenty-Four Seven Security makes a couple of very interesting assertions regarding the lack of growth of Service Oriented Architecture (SOA.) 

I haven't seen much discussion in the blogosphere about the security challenges that arise from loosely coupled service orientated systems, but that will soon change. As more and more companies move towards open applications ala SOA, data is also opened up to a whole new series of exploits and vulnerabilities.

I will agree that SOA provides some very interesting security challenges that, much like many emerging technologies, are attempted at being solved by having security bolted on instead of baked in.    I'd also agree that SOA will manifest new attack surfaces and potential vulnerabilities; it already has. 

Interestingly, the market for SOA security solutions came out of the gate strong, looked hot in the midst of consolidation and M&A madness, but then stumbled as the adoption of SOA (or specifically SOA security) did not support this nascent market kindly.  It has, in fact, become a feature, not a market. 

As to there not being much discussion in the blogosphere surrounding SOA, perhaps Peter missed Gunnar Peterson, Lori MacVittie, Arnon Rotem-Gal-Oz, or even Me.  Obviously Joe McKendrick has been blogging about SOA and security for some time also since he's the person moderating the webinar that Peter is referring to in his full post.

At this point, security is the primary limiting factor inhibiting SOA's growth. In order to counteract that, "Enterprises need to apply non-invasive, externalized security policy enforcement mechanisms consistently throughout their SOA ecosystems, while also centrally managing security policy."

<Cough!> Um, no.  Firstly, please shoot the marketing drone that wrote that.

Secondly, and most important, the primary limiting factor inhibiting SOA's growth is gross sum of: the definition of SOA, the state (mess) of Enterprise Architecture, operationalizing SOA and message buses, the business case, business value, complexity, and the cost center.  Security's in there somewhere, but it's far from being THE primary limiting factor, Peter.

I'm all for trying to raise the flag regarding SOA and the need for security, but please don't play pin the tail on the donkey with security as the Ass...you're only going to look like one.

/Hoff

I see your "More on Data Centralization" & Raise You One "Need to Conduct Business..."

Bejtlich continues to make excellent points regarding his view on centralizing data within an enterprise.  He cites the increase in litigation regarding inadequate eDiscovery investment and the increasing pressures amassed from compliance.

All good points, but I'd like to bring the discussion back to the point I was trying to make initially and here's the perfect perch from which to do it.  Richard wrote:

Christopher Christofer Hoff used the term "agile" several times in his good blog post. I think "agile" is going to be thrown out the window when corporate management is staring at $50,000 per day fines for not being able to produce relevant documents during ediscovery. When a company loses a multi-million dollar lawsuits because the judge issued an adverse inference jury instruction, I guarantee data will be centralized from then forward. "

...how about when a company loses the ability to efficiently and effectively conduct business because they spend so much money and time on "insurance policies" against which a balanced view of risk has not been applied?  Oh, wait.  That's called "information security." ;)

Fear.  Uncertainty.  Doubt.  Compliance.  Ugh.  Rinse, later, repeat.

I'm not taking what you're proposing lightly, Richard, but the notion of agility, time to market, cost transformation and enhancing customer experience are being tossed out with the bathwater here. 

Believe it or not, we have to actually have a sustainable business in order to "secure" it. 

It's fine to be advocating Google Gears and all these other Web 2.0 applications and systems. There's one force in the universe that can slap all that down, and that's corporate lawyers. If you disagree, whom do you think has a greater influence on the CEO: the CTO or the corporate lawyer? When the lawyer is backed by stories of lost cases, fines, and maybe jail time, what hope does a CTO with plans for "agility" have?

But going back to one of your own mantras, if you bake security into your processes and SDLC in the first place, then the CEO/CTO/CIO and legal counsel will already have assessed the position the company has and balance the risk scorecard to ensure that they have exercised the appropriate due care in the first place. 

The uncertainty and horrors associated with the threat of punitive legal impacts have, are, and will always be there...and they will continue to be exploited by those in the security industry to buy more stuff and justify a paycheck.

Given the business we're in, it's not a surprise that the perspective presented is very, very siloed and focused on the potential "security" outcomes of what happens if we don't start centralizing data now; everything looks like a nail when you're a hammer.

However, you still didn't address the other two critical points I made previously:

1. The underlying technology associated with decentralization of data and applications is at complete odds with the "curl up in a fetal position and wait for the sky to fall" approach
2. The only reason we have security in the first place is to ensure survivability and availability of service -- and make sure that we stay in business.  That isn't really a technical issue at all, it's a business one.  I find it interesting that you referenced this issue as the CTO's problem and not the CIO.

As to your last point, I'm convinced that GE -- with the resources, money and time it has to bear on a problem -- can centralize its data and resources...they can probably get cold fusion out of a tuna fish can and a blow pop, but for the rest of us on planet Earth, we're going to have to struggle along trying to cram all the 'agility' and enablement we've just spent the last 10 years giving to users back into the compliance bottle.

/Hoff

I want to have Gunnar Peterson's Baby (His SOA posts are the schizzle!)

I really look forward to reading Gunnar Peterson's blog.  He's got a fantastic writing style and communicates in an extremely effective form about one of my favorite topics SOA and security. His insightful posts really get to the point in a witty and meaningful way.  I'm going to try to make one of the OWASP meetings he is presenting at soon.

Gunnar made a fantastic post commenting on Arnon Rotem-Gal-Oz's writings on Service Firewall Patterns, but within the context of this discussion, his comments regarding the misalignment of developers, network folks, security practitioners and enterprise architects is well said:

One of my issues with common practice of enterprise architecture is that they frequently do not deep dive into security issues, instead focusing scalability, detailed software design, and so on. But here is the thing - the security people don't know enough about software design, and the software people don't know enough about security to really help out.

Sadly, this is very true.  It goes back to the same line of commentary I've also made in this regard.  The complexity of security is rising unchecked and all the policy in the world isn't going to help when the infrastructure is not capable of solving the problem and neither are the people who administer it.

Add to this the reality that many security mechanisms cannot make a business case as a one off project, but need to be part of core infrastructure to be economic, and wel[l], you get the situation we have today.

Exactly.  While this may not have been Gunnar's intention, this description of why embedding security functionality into the "network" and expecting packet jockeys to apply a level of expertise they don't have to solving security problems "in the network" as a result of economic cram-down is going to fail.

The architects define the "what", and unless security is one of those whats, it is not feasible to make the case for many specialized security services at a project by project level. This is why, enterprise architects that enable increased integration within and across enterprises, must also invest time and resources in revamping security services that enable this to be done in a reliable fashion.

...but sadly to Gunnar's point above, just as security people don't know enough about software design and software people don't know enough about security, enterprise architects often don't know what they don't know about networking or security.  The problem is systemic and even with the best intentions in mind, an architect rarely gets the opportunity to ensure that after the blueprints are handed down, that the "goals" for security are realized in an operational model consistent with the desired outcome.

I'm going to post separately on Rotem-Gal-Oz's Service Firewall Pattern shortly as there are tremendous synergies between what he suggests we should do and, strangely, the exact model we use to provide a security service layer (in virtualized gateway form) to provide this very thing.

/Hoff

Breaking News: SOA, Web services security hinge on XML gateways!

Bloody Hell!

The article below is dated today, but perhaps this was just the TechTarget AutoBlogCronPoster gone awry from 2004? 

Besides the fact that this revelation garners another vote for the RationalSecurity "Captain Obvious" (see right) award, the simple fact that XML gateways as a stand-alone market are being highlighted here is laughable -- especially since the article clearly shows the XML Security Gateways are being consolidated and bundled with application delivery controllers and WAF solutions by vendors such as IBM and Cisco.

XML is, and will be everywhere.  SOA/Web Services is only one element in a greater ecosystem impacted by XML.

Of course the functionality provided by XML security gateways are critical to the secure deployment of SOA environments; they should be considered table stakes, just like secure coding...but of course we know how consistently-applied compensating controls are painted onto network and application architectures. 

The dirty little secret is that while they are very useful and ultimately an excellent tool in the arsenal, these solutions are disruptive, difficult to configure and maintain, performance pigs and add complexity to an already complex model.  In many cases, asking a security team to manage this sort of problem introduces more operational risk than it mitigates. 

Can you imagine security, network and developers actually having to talk to one another?!  *gasp*

Here is the link to the entire story.  I've snipped pieces out for relevant mockery.

ORLANDO, Fla. -- Enterprises are moving forward with service oriented architecture (SOA) projects to reduce complexity and increase flexibility between systems and applications, but some security pros fear they're being left behind and must scramble to learn new ways to protect those systems from Web-based attacks.

<snip>

"Most network firewalls aren't designed to handle the latest Web services standards, resulting in new avenues of attack for digital miscreants, said Tim Bond, a senior security engineer at webMethods Inc. In his presentation at the Infosec World Conference and Expo, Bond said a growing number of vendors are selling XML security gateways, appliances that can be plugged into a network and act as an intermediary, decrypting and encrypting Web services data to determine the authenticity and lock out attackers.

"It's not just passing a message through, it's actually taking action," Bond said. "It needs to be customized for each deployment, but it can be very effective in protecting from many attacks."

Bond said that most SOA layouts further expose applications by placing them just behind an outer layer of defense, rather than placing them within the inner walls of a company's security defenses along with other critical applications and systems. Those applications are vulnerable, because they're being exposed to partners, customer relationship management and supply chain management systems. Attackers can scan Web services description language (WSDL) -- the XML language used in Web service calls -- to find out where vulnerabilities lie, Bond said.

<snip>

A whole market has grown around protecting WSDL, Bond said. Canada-based Layer 7 Technologies Inc. and UK-based Vordel are producing gateway appliances to protect XML and SOAP language in Web service calls. Reactivity, which was recently acquired by Cisco Systems Inc. and DataPower, now a division of IBM, also address Web services security.

Transaction values will be much higher and traditional SSL, security communications protocol for point-to-point communications, won't be enough to protect transactions, Bond said.

<snip>

In addition to SQL-injection attacks, XML is potentially vulnerable to schema poisoning -- a method of attack in which the XML schema can be manipulated to alter processing information. A sophisticated attacker can also conduct an XML routing detour, redirecting sensitive data within the XML path, Bond said.

Security becomes complicated with distributed systems in an SOA environment, said Dindo Roberts, an application security manager at New York City-based MetLife Inc. Web services with active interfaces allow the usage of applications that were previously restricted to using conventional custom authentication. Security pros need new methods, such as an XML security gateway to protect those applications, Roberts said.

<snip>

Chuck Norris Can't Kill SOA

As a reprise to the cartoon published earlier today, here's all you ever need to know about SOA; well, a few things actually.  The entire list is here. 

• SOA is the only thing Chuck Norris can't kill.


• SOA invented the internet, and the internet was invented for SOA.


• SOA is not complex. You are just dumb.


• In the last year, SOA increased Turkey's GDP by a factor of 10.


• One person successfully described SOA completely, and immediately died.


• Another person successfully described SOA completely, and was immediately outsourced.


• Larry Ellison once died in a terrible accident, but was quickly given SOA. He came back to life, built a multibillion dollar software company, and now flies fighter jets.


• Guns don't kill people, the SOA WS-* stack kills people.


• SOA can write and compile itself.


• SOA is an anagram for OSA, which means female bear in spanish. It is a well-known fact in the spanish-speaking world that female bears are able to model business processes and optimize reusable IT assets better than any other hibernating animal.


• SOA is so great 10 facts aren't enough.


• SOA is the mistress to all CIOs.


• SOA is just one letter away from SOB. On purpose.


• If a tree falls in the forest, SOA knows about it.


• If you google 'SAP' and 'Chuck Norris', the top site is SOA Facts.


• SOA is being used in the developing world to solve hunger. Entire populations will be fed on future business value.

...now you know.

Web 2.0 can't be protected by Web 1.0 Security Models when Attackers are at Attacker 3.0...

Gunnar Peterson (1 Raindrop blog) continues to highlight the issues of implementing security models which are not keeping pace with the technology they are deployed to protect.  Notice I didn't say "designed" to protect.

Specifically, in his latest entry titled "Understand Web 2.0 Security Issues - As Easy as 2, 1, 3" he articulates (once again) the folly of the security problem that we cannot solve because we simply refuse to learn from our mistakes and proactively address security before it becomes a problem:

"So let's do the math, we have rich Web 2.0 and its rich UI and lots of disparate data and links, we are protecting these brand new 2007-built apps with a Web 1.0 security model that was invented in 1995. This would not be a bad thing at all if the attacker community had learned nothing in the last 12 years, alas they have already upgraded to attacker 3.0, and so can use Web 2.0 to both attack and distribute attacks.

2.0 functionality, 1.0 security, 3.0 attackers. this cannot stand."

A-Friggin'-Men.  Problem is, unless we reboot the entire human race (or at least developers and security folk) it's going to take a severe meltdown to initiate change.

Oh, and BTW, just because it bugged me when Thomas Ptacek bawked while asking what I meant in a presentation of mine where I said:

"What happens when we hit Web3.0 and we’re still only at Security 2.4beta11?"

...and he asked:

What does this even mean?

...the answer is simple: Please see Gunnar's post above.  It's written much better, but i trust this is all cleared up now?

Good News! SOA Will Make Your Life Easier...and Easier to Secure!

I read ZDNet's coverage of the Wharton Technology Conference in Philadelphia by Larry Dignan and was astounded by what Larry reported was said in regards to comments made by TD Ameritrade's Chief Security Officer, Bill Edwards.

I'm not trying to pick on Mr. Edwards as I have never met the man, but his comments regarding SOA left me disillusioned about how security and emerging technologies are approached in what continues to be a purely reactive, naive and disconnected manner.

Specifically, SOA is not exactly "new."  The evolution of technology, maturing of standards, proliferation of Web 2.0 and massive deployments of SOA's in some of the world's largest companies shouldn't come as a surprise to anyone...even in the risk averse financial services sector.  That being said, SOA is disruptive and innovative and needs to be approached both strategically as well as tactically.

As a former CISO of a $25 Billion financial services firm, I was embroiled in our first SOA deployments 2.5 years ago.  It's blood and guts.  It involves dealing with the business, business partners, IT and development staffs in ways you never have.  It takes communication, education, expertise and business acumen.  It's not something you wait to be dragged into.

The notion that a security team would be "dragged" into SOA rather than embrace and approach it proactively and from the perspective of a thought leader and collaborative contributor astounds me.

That said, here's what I had a problem with:

TD Ameritrade Chief Security Officer Bill Edwards figures that he's going to be pulled onto the service oriented architecture (SOA) bandwagon soon. He might as well use it to enhance security.

"When the architects approached me about SOA my first reaction was 'no you can't do that,'" said Edwards, who spoke at a financial services online fraud panel at Wharton Technology Conference in Philadelphia on Friday. "But then I realized I'm going to be dragged along with SOA anyway so I should use it to rebuild security from the ground up. I know it's coming so my team got friendly with the architecture group."

What disturbs me is that SOA represents potentially monumental impact to business, technology and security and instead of embracing (see below) this in a proactive manner, the ad hoc formation of a "strategic" response is "...if you can't beat 'em, join 'em" and perhaps leverage this to fix problems that weren't fixed prior.

Paying for sins of the past with currency of the future and confusion in the present isn't exactly showing alignment to the business as an enabler.  But that's just me.

It's clear that the first reaction of saying "no, you can't do that" is so incredibly typical and representative of the security industry in general; fear what you don't understand and can it. I can't imagine how making decisions on risk without an effective model is doing the business justice.

Realizing that this is a train on the tracks that can't be ducked and that he's going to be "dragged along with SOA" and that something must be done to head off disaster at the pass (or at least get more budget,) I'm having trouble reconciling this:

"SOA is going to be embraced by security. I don't know if the industry is ready for security on SOA, but I'm looking forward to it as it will make my job easier," he said. "SOA allows you to get granular on security and focus on specific modules."

I am really having trouble understanding whether this is a statement or a question, but I just cannot comprehend how much sense that last sentence fails to make. 

You're not embracing SOA when you describe being "dragged into it" and your first reaction is "no." Further, if you're deploying SOA and you're not baking in security, you should be fired.

Secondly, Explain to me how SOA is going to make security (his job) easier?  Because you can get "granular on security?"  Huh?  SOA is complex.  If you don't have your "stuff" together in the first place, it's only going to make your life more difficult.

I'm sorry for this reading like I'm a grumpy bastard (I am) and that I'm singling out Mr. Edwards (he chose to be on a panel) but this just doesn't jive.

My advice to Mr. Edwards and anyone else looking for the right approach to take with SOA and security is to read Gunnar Peterson's blog or some more of his work.
 

/Hoff