Slashdot Mirror

← Back to Stories (view on slashdot.org)

Security Community Reacts to Microsoft Announcement

Posted by Hemos on from the hope-against-hope dept.

A number of readers have collected stories concerning the change of focus by Bill Gates to security. Bruce Schneier and Adam Shostack have written a piece, while Crag Mundie of MSFT has also chimed in, along with some commentary from ZD folks. SecurityFocus has other words, as does InfoWarrior.

2 of 471 comments (clear)

  1. Cringely, too by what_the_heck · · Score: 5, Informative

    Cringley has a good piece up on this as well.

  2. SOAP and the MSFT way by BlackStar · · Score: 5, Informative
    There is a side thread in progress that touches on how SOAP is addressed in the article. I think SOAP deserves a lot more attention, especially as it affects MSFT, and the new .NET initiative.

    SOAP is designed to use HTTP/HTTPS as the most common implementation of transport and protocol underneath. Schnier and Shostack touch on how poor a decision this is. I think this goes a lot further than many developers and companies are realizing.

    You just removed your firewall.

    The idea of SOAP is to allow IT services to be exposed as remotely addressable and usable procedures. Essentially with every web service or SOAP receiver, you have written a brand new server that parses XML protocol messages to decide on action. Thus every web service you create may have overrun, DoS and other exploits inherent in it, in your code, as you are executing paths based on a message from the outside. Just like a web server, ftp server or any other available server.

    So now, everyone has to become better at security, to the point that the web services are safe. Ideally they should all run within a sandbox environment with restricted permissions, but considering SOAP authentication is based on HTTP authentication, the models may or may not match up properly.

    Most importantly is that the SOAP specification team, including MSFT and the .NET portions pertaining to web services have basically increased the difficulty of every network administrator's job by stuffing all this over port 80.

    Now if there is a vulnerability in a web service, the network admin has to take out port 80, probably taking down the web service, the web server, and who knows what else that's been tunnelled through there. They can't simply block a set port. UDDI could have advertised a port for the service as well, and stateful inspection could be implemented at some level on each service port to increase security and leverage off of the firewalls. Instead, a rat's nest of information is getting funnelled through http/https. The firewalls aren't designed for this, and the inspection task is only going to get more difficult as SOAP grows in popularity.

    MSFT is always looking at first to market, and I can almost assure you that for that reason, SOAP was designed around port 80 and into the web server engines. I can also say with a fair bit of confidence that the first time MSFT gets beat to market due to a security review, that the security priority is going to get thrown right out the window of the executive windows at Microsoft if it causes the stock to slip.