1 Raindrop

Gunnar Peterson's loosely coupled thoughts on distributed systems, security, and software that runs on them.

Recent Posts

  • Security Champions Guide to Web Application Security
  • Security > 140 Conversation with Pamela Dingle on Identity
  • 6 Things I Learned from Robert Garigue
  • The Curious Case of API Security
  • Security Capability Engineering
  • Ought implies can
  • Security > 140 Chat with T. Rob Wyatt on MQ and Middleware Security
  • Privilege User Management Bubble?
  • The part where security products solve the problem
  • Four Often Overlooked Factors to Give Your Security Team a Fighting Chance

Blogroll

  • Adding Simplicity - An Engineering Mantra
  • Adventures of an Eternal Optimist
  • Andy Steingruebl
  • Andy Thurai
  • Anton Chuvakin
  • Beyond the Beyond
  • cat slave diary
  • Ceci n'est pas un Bob
  • ConnectID
  • Cryptosmith
  • Emergent Chaos: Musings from Adam Shostack on security, privacy, and economics
  • Enterprise Integration Patterns: Gregor's Ramblings
  • Financial Cryptography
  • infosec daily: blogs
  • Jack Daniel
  • James Kobielus
  • James McGovern
  • John Hagel
  • Justice League [Cigital]
  • Kim Cameron's Identity Weblog
  • Krypted - Charles Edge's Notes from the Field
  • Lenny Zeltser
  • Light Blue Touchpaper
  • Mark O'Neill
  • Off by On
  • ongoing
  • Patrick Harding
  • Perilocity
  • Pushing String
  • Rational Survivability
  • rdist: setuid just for you
  • RedMonk
  • RiskAnalys.is
  • Rudy Rucker
  • Software For All Seasons
  • Spire Security Viewpoint
  • TaoSecurity
  • The New School of Information Security
  • Windley's Technometria
  • zenpundit
Blog powered by Typepad

Web services security training in NYC

If your company is doing SOAP, Web services, SOA, Rest or XML, and you are looking for ideas on how build security into the system, come to NYC in March. I am teaching Web services security in NYC on March 10, 11, all the details are here. This is a public version of the training session that I do for companies and conferences, and you can read reviews here.

January 09, 2008 in Security, SOAP, Web Services | Permalink | Comments (0)

You Got Chocolate in My Peanut Butter! Rilke weighs in on Rest and SOAP

Rilke Rest and SOAP are supposed to be about interoperability, it is fascinating that they are at each other's throats. I don't see the same level of malice from Rest or SOAP towards say J2EE or Corba. Wonder why this is? Either way it is ironic that proponents of interoperability technologies would want to vanquish each other. Rilke [1] says we need to let go of irony, and not be governed by it. So too must we let go of SOAP v REST. They actually can play nicely *together*, Mark O’Neill gave a good “real world” Web services security talk last week at OWASP (at eBay where I believe these two *do* play nicely together in actual fact), in the case studies section he describes some security considerations for SOAP-Rest integration

The simple fact is that you may need/want to rely on Rest on the edge, but you may also want to leverage SOAP's security mechanisms as you get closer to your enterprise foo (ERP, CRM, etc.). From a security perspective it is hard to do much useful without authentication and integrity, so an STS plays an important role. The example below shows one way, this is similar to the approach that Ping Identity uses in their Ping Federate Web Services.
Reeses
You got Rest in my SOAP, oh wait, it can work together...and thither irony never descends.

[1] Rainer Maria Rilke:
Irony: Do not let yourself be governed by it, especially not in uncreative moments. In creative moments try to make use of it as one more means of grasping life. Cleanly used, it too is clean, and one need not be ashamed of it; and if you feel you are getting too familiar with it, if you fear this growing intimacy with it, then turn to great and serious objects, before which it becomes small and helpless. Seek the depth of things: thither irony never descends—and when you come thus close to the edge of greatness, test out at the same time whether this ironic attitude springs from a necessity of your nature. For under the influence of serious things either it will fall from you (if it is something fortuitous), or else it will (if it really innately belongs to you) strengthen into a stern instrument and take its place in the series of tools with which you will have to shape your art.

Letters to a Young Poet
(translated by M. D. Herter)

November 21, 2007 in REST, Security, SOAP, Web Services | Permalink | Comments (1)

Two States

James Clark, Technical Lead of the original XML Working Group, neatly summarizes why defense in depth is mandatory not optional in Web services, be they Rest, SOAP, whatever:

XML is fundamentally not OO: XML is all about separating data from processing, whereas OO is all about combining data and processing. Functional programming is a much better fit for XML: the problem is making it usable by the average programmer, for whom the functional programming mindset is very foreign.

The lack of tooling for secure coding is a real problem, the WS-Security people are ahead here for sure, but there is a lot that needs to be done in all camps. Bottom line: We need a defense in depth security model that composes elements of both the security of the processing state (service security if you will) and the data itself (for example message level security), or as some great American Poets called Pavement put it:

two states
we want two states
north and south
two, two states
forty million daggers ...
two states
we want two states
there's no culture
there's no spies
forty million daggers ...

**************************************************

Upcoming public SOA, Web Services, and XML Security training by Gunnar Peterson, Arctec Group
--- NYC (April 19), Unatek Web Services (May), OWASP App Sec Europe (May), Helsinki (June), DC/Baltimore (July 19).

April 09, 2007 in Defense in Depth, REST, Security, SOAP, Web Services, XML | Permalink | Comments (1)

Rise and Fall of CORBA

This article has some good content on what emerging technologies like SOAP may learn from past successes and failures, but it appears to be more commercially motivated than anything else. The usual suspects (complexity, bloated specs, lack of features, and Microsoft) are rounded up as conspiring to constrain CORBA's growth. Of course, the reality is that CORBA serves lots of mission critical functions today.

The lack of features section contains this:

CORBA provides quite rich functionality, but fails to provide(....):

Security. CORBA's unencrypted traffic is subject to eavesdropping and man-in-the-middle attacks, and it requires a port to be opened in the corporate firewall for each service. This conflicts with the reality of corporate security policies. (Incidentally, this shortcoming of CORBA was a major factor in the rise of SOAP. Not having to open a port in the corporate firewall and sending everything via port 80 was seen as a major advantage, despite the naïvete of that idea.) The OMG made several attempts at specifying security and firewall traversal for CORBA, but they were abandoned as a result of technical shortcomings and lack of interest from firewall vendors.

Now I am not a "let the network firewall solve all your app security problems" guy, but I am sure it will come as quite a surprise to pundits like Schneier ("SOAP is designed as firewall friendly protocol, this is like a skull friendly bullet"), et. al. that SOAP's ability to traverse firewalls is actually a boon for security. Schneier circa 2000:

That's right. Those pesky firewalls prevent applications from sending commands to each other, so SOAP lets vendors hide those commands as HTTP so the firewall won't notice.

Let's continue the DCOM example. So what if DCOM runs over a firewall?

DCOM is Microsoft's main protocol for inter-application communication. It's not just used by programs that are intended to be servers; it's used for all sorts of desktop communication and remote access. The result is that an average machine has dozens of programs using DCOM. Mine shows 48, ranging from "Microsoft PowerPoint Presentation" to "logagent" and including the catchily named "{000C101C-0000-0000-C000-000000000046}"; you may be able to list yours by bringing up a Command Prompt and typing "dcomcnfg".

Now, there are lots and lots of ways to secure DCOM applications, so maybe all of those applications are happily responding only to authenticated requests from the local machine. On the other hand, there are lots and lots of ways to make DCOM applications insecure, so maybe one of them is just waiting for somebody to send it an entirely unauthenticated request to overwrite selected files on my hard disk.

Firewalls have good reasons for blocking protocols like DCOM coming from untrusted sources. Protocols that sneak them through are not what's wanted.

SOAP was also not generally seen, at the time the ACM article refers to, as an improvement over DCOM and CORBA security, quite the opposite. So anyway, SOAP is not the death of distributed security either or even the death of firewalls, and I think WS-*, SAML, et. al. contain some valuable improvements for security but these nothing to do with firewalls, and I have not seen security as a reason for organizations moving to SOAP Web Services and away from CORBA. And in either case, the tricky bits like IAM and input validation remain.

July 20, 2006 in CORBA, Security, SOAP, Software Architecture | Permalink | Comments (0)

Secure Your SOA: Web Services and XML Security at OWASP Europe

4/30 is the last chance for early registration for OWASP Europe. I will be teaching a one day class on Web Services and XML security -- the class focuses on the risks inherent in this programming model, what the standards are, how to use them, and where you still need to use custom code and configs to deal with the security issues. This is a variation of the classes that I provide for customers onsite

April 17, 2006 in Computer Security, Deperimeterization, OWASP, REST, SAML, SDLC, Security, Security Architecture, SOA, SOAP, Software Architecture, Web Services, XML | Permalink | Comments (0)

REST v SOAP debate impact on security services architecture

Mark O'Neill's RSA Presentation on Security for REST Web Services makes an important point for security architects who are dealing with developing security services for budding SOA initiatives - how will your security services (which rely on WS-* functions and SOAP) be able to deal in a RESTful web services paradigm? This is not a trivial question because while enterprise architects may design and purchase solutions that rely and mandate the former, developers can easily circumvent with a HTTP Get. Part of this gets back to a framework versus roll your own debate that I blogged awhile back.

Security architects cannot afford to take enterprise architect's whiteboard and Visios mandating a WS-* (or any technology) world at face value instead they must engage developers, BAs and other stakeholders to deal with the reality of runtime as opposed to policy and design time. XML in and XML out may be the design, but the runtime reality could well be HTTP Get in and XML Out under REST rendering the shiny new XML security based solution blind to large amounts of traffic.

Maximum flexibility to deal with different tactical deployment realities is an important property in security tools, not just compliance with Visio drawings. The ability to enable security protocols in integration scenarios composed of hetergeneous technologies and usage paradigms yields the widest risk management coverage. In this case it pays for security architects to be the fox not the hedgehog.

This is also why I think STS technology will be very successful, because the security protcols that STS and WS-Trust integrate: SAML, X.509, Kerberos, are generally putting arbitrary boundaries around technical domains while the business reality is the opposite - more integration not less. Protocols which continue to enforce isolation ultimately fail when their subjective, isolated concepts meets up with the integration objectives reality rendering the system as a whole less secure.

March 16, 2006 in Computer Security, Deperimeterization, REST, Risk Management, Security, Security Architecture, SOA, SOAP, Software Architecture, SOS, Web Services | Permalink | Comments (0)

My Photo

SOS: Service Oriented Security

  • The Curious Case of API Security
  • Getting OWASP Top Ten Right with Dynamic Authorization
  • Top 10 API Security Considerations
  • Mobile AppSec Triathlon
  • Measure Your Margin of Safety
  • Top 10 Security Considerations for Internet of Things
  • Security Checklists
  • Cloud Security: The Federated Identity Factor
  • Dark Reading IAM
  • API Gateway Secuirty
  • Directions in Incident Detection and Response
  • Security > 140
  • Open Group Security Architecture
  • Reference Monitor for the Internet of Things
  • Don't Trust. And Verify.

Archives

  • November 2015
  • October 2015
  • September 2015
  • August 2015
  • July 2015
  • June 2015
  • May 2015
  • April 2015
  • March 2015
  • February 2015

More...

Subscribe to this blog's feed