We have to quit throwing Pizza Boxes at the Security Problem!

The majority of my discussions to date have focused on discussions with SOA Appliance vendors and their approach to providing SOA Security.  Gary provides a completely different perspective on SOA Security because he comes from a software security background and has written several books on this specific topic.  I talked to Gary about the need for the Architect to design security into their SOA architecture and for developer’s to code security into their software rather than abdicating this responsibility and expecting hardware vendors and the networking people to continue to through pizza boxes at the security problem.  I think Gary provides an interesting perspective and that everyone should consider this in their future efforts to architect, design, and deploy SOA Security solutions.

About Gary McGraw

Gary McGraw is Cigital’s Chief Technology Officer and in this role, he researches software security and sets the technical vision in the area of Software Quality Management.  He has co-authored five best-selling books and numerous articles on software security.

I recently had a chance to get Gary’s views on SOA Security: 

In the past I have focused most of my discussions on SOA Security primarily to hardware vendors - SOA Appliance vendors such as IBM Datapower, Reactivity, Layer 7, etc.  I have read a few of your articles and purchased you book Software Security which I look forward to reading.  I am interested in getting your perspective on SOA Security.

McGraw: Actually I have a different background than most security people because I’m a software guy.  I have been doing software and software architectures for many, many years and have been consulting with lots of people who build software about these sorts of things.  I approach SOA as a guy who knows a lot about software architecture and someone who helped start the field of software security.

What is your background in SOA?

McGraw: Well I think SOA is frankly just a repackaging of stuff that we are already well familiar with.  So I don’t find it earth shatteringly new.  The only thing that is interesting is the cultural phenomenon.  It appears to be new, so the marketing people have done their little hype thing and it worked this time.

Don’t you think from a security perspective, there are a lot of fundamental differences when we’re talking about message level security associated with SOA versus transport level security associated with other types of architecture?

McGraw: Yes there is some critical stuff.  The main thing that vendors of SOA products and even the SOA security expert people that I’ve come across (although I haven’t a heard the one guy that you mentioned) is that they are mistaking security features for security.  And unfortunately the mere addition of security features, even if you do them better than you might do them if they were distributed, doesn’t make architecture secure.  Does that make sense to you?

Yes.

McGraw: So let me go into that in a little more detail.  A lot of people want to talk about things like authentication, or encrypting traffic, or access control, data security, data in transit, data at rest security - all that stuff amounts to a bunch of security features which are important.  It’s good that you can think about those when you’re doing your SOA stuff.  The real problem is that in order for a piece of software or software systems to be secure you have to watch out for defects in the way you designed and implemented the system.  So attackers don’t actually go after security features like cryptography, instead they go after problems in the design or problems in the implementation that probably didn’t have anything to do with security.  They just made the thing vulnerable.  And so I have spent a lot of time in the standard issue software security world which is growing by leaps and bounds by the way.  I’ve been explaining this to all the developers and architects that do normal software development.  And I think they are beginning to understand because when you first talk to a developer they say “oh ya I understand security just use SSL and everything is fine”.  Then you say while attackers actually go after to things like a buffer overflow right there which has nothing to do with your security features.  Then they say “ya ya ya”.  Or maybe they attack the way you do error handling which is highly distributed in your object-oriented system and it needs classes here and “they go right”.  They have come to understand that, but I don’t think SOA vendors understand yet, so we need to get that point across to them.

How do you propose to approach this?  Do you start with a security framework no matter what type of architecture is being implemented, even SOA?

McGraw: Yes that’s right, I think there’s a number of best practices that can be applied even when you’re doing SOA stuff.  I find SOA is a huge opportunity to actually do things right from a security perspective.  Not because we can marshal the right features.  But because when you’re re-architecting or re-factoring to build your SOA design, you can figure out what is going to be centralized, and how things are going to interact with central services.  You can at that point, think about flaws or architectural risks that you may have had in your system, and you can now address then through better design.  SOA presents an opportunity to rethink the way you are doing architecture and do it in a better way.  Does that make sense to you?

Yes.

McGraw: For that reason, I’m pretty optimistic about it.  The reason I’m pessimistic about it is because I think it is pretty clear that the vendors don’t really understand what security is.  And that is not a surprising thing either because it’s something that I’ve been dealing with for 10 years.  It is just as important that we all understand we can’t solve the security problem by sticking a pizza box on the rack over here to handle some authentic or some sort of application layer firewall, whatever the hell that is.

Do you think security can be handled through hardware?

McGraw: Absolutely not.  In fact, I know that it can’t!

That is interesting, since there are a lot of hardware SOA appliance vendors out there “hawking their wares”?

McGraw: I know, and they’re making stuff up!  So it is important that we get some security people to say “hey wait a minute.  You vendors are doing the same thing you did over here and it didn’t work over here either – Why do you think it’s going to work now?”

There are many SOA Appliance Vendors offering security solutions for SOA.  What do you think about their approach to security?

McGraw:  The problem is when you get a standard issue network security guy to be your security guy.  They really don’t understand software architecture at all, nor do they understand what an attacker’s really attacking.  They are good at trying to put something like a filter usually, between the bad people out there, and the broken thing they just built right here.  My whole perspective is let’s stop building the broken thing, we can still use filters.  There is no reason why we shouldn’t do that.  But we can’t expect to solve the problem with filters alone, especially when we’re setting out to distribute our architecture in a greater fashion than we have in the past.

I think there seems to be a real chasm between software architects and the networking people in general.

McGraw:  Absolutely.  In fact they don’t understand each other and they tend to not like each other.

I think of a SOA Network Architect is actually an oxymoron because most of the network guys have no comprehension of what is going on with SOA architecture side of things?

McGraw:  Well you’re right, their approach to security seems to be to liberally sprinkle firewalls all over the network architecture.  So when I go to somebody and I say let me look at the architecture from a SOA perspective, I don’t want to see their network map.  I want to see what components are where and what kind of services are being called, what kind of API are exposed and what kind of playback and man-in-the-middle attacks can be carried out against these services and think about it from a “software behavior perspective” more than a let me “block packets from here to there perspective”.

In the future it will be essential to communicate more and more metadata

McGraw:  Yes I think you are right.  So here’s the important thing to do while you are doing that, which is great thing and I have nothing against that idea.  Don’t forget there are also bad people that might want to take advantage of that needed metadata.  My point is that while you’re busy refactoring don’t forget to put on your black hat and think like a bad guy for awhile, because that will help a lot.

I talked to one vendor and he talked about the idea that we need to drive the responsibility of security down to the software developers.  Do you agree with this approach?

McGraw:  Of course I wrote a book called Building Secure Software in the year 2000 which was the first book in the world about that topic.  And my new book which is called Software Security came out in February is about how to do that.  So I like to see those lessons applied to SOA architecture.  I would love to see SOA architects read things like that, so they get a clue about what kind of assurance activities you should do while you are architecting your SOA.

This responsibility needs to be driven down from the architect to the developer since it not clear how these services will be used. 

McGraw:  That’s exactly right. It is an important point to be made.  There are two kinds of problems in software errors that get attacked.  One kind is bugs, like I said the buffer overflow before; that is an implementation level problem.  The other is flaws, design level problems and if you look historically at what has caused software vulnerability you find out that it’s 50-50 among those two things.  So you have to address both.  The cool thing is, if while we’re re-factoring and working on the SOA stuff we can address those flaws and then we are going to make some great forward progress.

Do you think that the average developer is capable of understanding security requirements and developing software that is to be secure?

McGraw:  Yes I do.  I’m actually very optimistic about that.  I think we have made a great deal of progress in the last 5 years; we have a long ways to go.  I think most developers are really smart people and if we give them right tools and we give them a little bit of a clue, they are going to kick this things butt.

My concern from a business perspective is that security is this “black hole” where we never can get past in order to delivery true business value?

McGraw:  The answer to that is to really think carefully about the business proposition and your business context.  And in fact most hard core security people talk about security as a risk management exercise.  The question is how do you measure impact and of course, the answer is you have to measure impact with reference to what you’re trying to accomplish on the business side.  So you can have too much security, and you can have not enough security.  And the whole balancing act is about what I am trying to get done and who is going to attack me, and if they were successful what would happen to my business.  Then it will tell you how much to spend and how much to worry about security.  And the people that are doing a great job at that of course are the credit card guys, the financial services guys, people that we have been working with for many years.  By the way they are all making a great deal of effort on trying to train their developers to do a better job from a security perspective.  That is another reason I’m optimistic about the field.

I think that is a good approach to do security in software and is better than continuing to throw boxes at the problem which is only a temporary solution?

McGraw:  Think about one of those boxes, think about these Layer 7 guys, the application firewall appliances.  The whole issue with those is that you have to set them up to do the filtering.  They may learn how to do filtering by watching traffic go by and you certainly hope that no attacks occur during training.  But who is in the best position to explain how a given piece of software should behave, and what kind of input it should take other than the guy who wrote the dang thing.  So what happens when operations people approach the software pile is they can’t get into it and change it, so they just try to slap something in front of it.  On the other hand, if we get into it [software] we can do a better job.

I see SOA happening in three phases.  The third phase is a longer-term vision of SOA, where you expose services to third parties, and they can use UDDI to discover services.  Do you think we can manage security in that type of environment where third party participants are unknown?

McGraw:  The discovery thing.  Let me give you the example of back in the JAVA days.  Do you remember hearing about JINI?  I was talking to Ken Arnold when he was busy trying to invent JINI.  He said JINI is really cool.  You have a device and you want to print something out and you can discover the printer over there and JINI allows you to print to the printer.  So here’s what I do as a bad guy.  I go into a corporate office where all the C level executives are and I set my little device up as the printer that prints confidential information.  Just print to me and I broadcast that as my service than I just wait for people to send the important documents to me.  He just looked at me and said “My God, you are just evil”.  And I said “no I am a security guy” and I know you have to think about these things.

Is that the kind of perspective, you have to have when you’re a security guy?

McGraw:  So if you think about UDDI, it’s great that you can discover services out there.  But who else can discover them, and what are they doing with them to make your life difficult.  What if they are just lying, and if I am just publishing a pretend service and you attach to it and you send me all of your data.

Do you think that third phase will ever happen from a security point of view?

McGraw:  I think we need to think properly about bad people while we build these systems.  Because we are so excited and optimistic about all the good stuff sometimes we forget that there are these bad people who break the rules.  And we can’t do that.

Will we ever see discovery?

McGraw: I think it could happen, but it has to happen carefully.

Can you tell me about your company?

McGraw:  My Company is called Cigital, and we have about a hundred people.  And we provide services in software behavior.  We do a lot of software architecture, and in fact helped some of our customers that bought pieces of SOA gear, figure it out what to do with architecture to take advantage of some of the things.  We have worked with the Systinet guys in particular in Boston.  As software behavior specialist we worry about things like performance, reliability, and safety, and of course, security.  And security may be the most interesting aspect of software behavior because it involves being able to think like a bad guy, knowing what attacks really look like, and understanding that we have to build our systems to be secure instead of just a throwing pizza boxes at them and those sorts of things.  We help large organizations get a handle on these problems, often through really large-scale initiatives.  Lately we’ve been helping big financial houses with tens of thousands of developers get a handle on software security for their development organization, so they know how to do code review properly, what kind of tools to use, so they know how to approach architectural risk analysis so when they are factoring they do a better job.  That is the kind of stuff we do for a living.  It is very exciting.

Do you typically get involved at the front end of SOA developments?

McGraw:  We get involved all over the place.  More than half the time of course people call us up and say we have built this big thing.  Is it secure?  And we go WOW it sure would have been better if we had design it.  But we can help you with that.

Many organizations have built web services and started exposing them externally without any thought to security.

McGraw:  And of course, security is kind of like quality.  It’s better to start early and think about it while you’re building something than it is try to make something high-quality when you’re done building it.

The financial services industry is probably the biggest opportunity as far as security?

McGraw: That’s right, and that’s followed by the embedded device guy people who build cell phones and PDA’s.  And that is followed by people who build consumer facing things like run hotel chains, sell sugar water, and build gaming systems.  All those sorts of people are our customers

You provided me a very different perspective of things since I have been talking to networking appliance vendors and it is good to get a different perspective on things.

McGraw:  Hopefully it’s helpful, and all I can ask for is HELP!  So spread the word for god’s sake we have a lot of reeducation to do.

Anything you want to add about security and its application to the SOA world.

McGraw:  Only that note of optimism which I expressed before.  I am pleased with the whole SOA explosion.  And I hope it provides people and an opportunity to rethink security at the architectural level, which is fantastic, because opportunities to do that are few and far between and if we can ride that re-architecting wave properly we should end up with systems that are designed better.  That would be great!

------

I had a good time talking to Gary, and now when I get involved in security I will be sure to put my black hat on and to think like a “bad guy”.  

You can check out Gary’s books at www.cigital.com/~gem/books/

Also Gary recently published an article on SOA Security that is interesting – Software Security and SOA: Danger, Will Robinson!  www.cigital.com/papers/download/bsi12-soa.doc.pdf

And for more information on Cigital products and services at www.cigital.com .

 ___________________________________________________

>> Back to Main Page

Gary E. Smith
SOA Security Architect