Trustworthy computing: non-SDL view


Take notice: My new feed address is now Please re-subscribe.

Well, finally it is my time to scold Microsoft. I’m not a fun of this type of self-promotion, still I believe that the only way to move forward is to receive, process and answer some constructive criticism. So let’s begin:
Several years ago Microsoft announced its widely-known Trustworthy Computing initiative (actually they just celebrated its 10 years). I probably don’t have to remind you the goals and means for the initiative to you, they all can be found without any problems. Anyway, this letter doesn’t pretend to be some kind of thorough analysis after which I will exclaim “MS lies!” On the contrary, it is more about just trying to show that in my humble opinion something in current approach to security can be improved.
I am an IT Pro with 10+ years of experience, and this fact definitely affects how I see the World, security and Microsoft’s products regarding both of them. My recent impression of Trustworthy Computing is like that:
“SDL! SDL this! SDL that! SDL is everything and everywhere!”
Don’t get me wrong, SDL is great even from the perspective of a systems administrator who almost cannot write code. Seriously, I have the feeling that Microsoft’s code itself has become much more secure over the past years. Most of the recent vulnerabilities need me to turn off some safeguards (like DEP or UAC) or to not configure any of them in extremely hazardous environment (not turning off Server service on an Internet-facing computer). As a consequence I feel much safer than, say, 10 years ago with the products I use. Still there are some features in recent situation development that make me believe that the current SDL lacks something vital. One may ask “what exactly do you mean?” Well, it is testing in the environments, which are built according security best practices and creating not only the code which is not vulnerable, but also which provides features to implement the controls recommended by the best practices and can deliver this features without failing. Everything, literally everything starting with smart card authentication and finishing with separation of duties or delegation of access has to be incorporated into the products to build somewhat secure environment. You cannot feel secure if those who make your backups are able to restore them and configure the way they are being created, or if you have to give SQL farm administrator permissions to someone who is to make some basic job. During past several years I have been witnessing some events which made me think that those matters haven’t been in focus for some PGs at least for several years if not at all. To be not accused of making this up I’ll give you some examples from my own experience and observations.
1) When MS SharePoint Server 2007 was just released, we tried to install it in the company I worked for. Our policies required using of Constrained Kerberos Delegation, publishing of any web application through ISA server SSL bridging and all that stuff including smart card authentication. Sound requirements, aren’t they? Unfortunately, the product obviously wasn’t tested with such constraints. We stepped into multiple problems, which were solved throughout the flow of several MS Support cases. Fortunately all of them were a success. At the very least we received workarounds For example, indexing didn’t work on SSL site, and if you first created SSL site on port 443 and then extended it to the 80th port (which was to be crawled by MOSS), then indexing worked fine, but search didn’t return result. The correct sequence was to install site on the 80th port and then extend it to the 443rd. Not a big deal, one may say, but this could be detected by automatic testing in the relevant environment (BTW, this behavior was told to be in place by-design and was fixed in the following SPs 😉 ).
2) The second case which is relatively close to the SharePoint is from the people who created WebDAV. The technology is very useful, though it was again, never tested in a secure environment. Publish it through the ISA Server, require users to use their smart cards to get access to the WebDAV resource and… voila! There are your problems.
3) Smart card support really seems to be the weak point for the developers. We absolutely love to use UC products of Microsoft: Exchange and OCS/Lync. But can you use Outlook and Communicator to authenticate by certificate? Hell, no! Build a VPN channel (or DA), and then use it if you want secure communications.
4) Data Protection Manager. It is our beloved one. Being as simple yet powerful as it is, it is just charming. Still, three major releases later we didn’t have any duty separation. If I am a local administrator I can backup, restore and configure everything. If I am not a local administrator, I can almost nothing. There are some valuable exceptions, but not all we need. The latest release has RBAC in it as it was promised by PG, still, 5 years without it sucked.
5) A problem with the SQL server. In order to receive highly available solution some can use SQL Server Mirroring technology. It is great and has really saved our applications many times. But when we stepped over the boundary where we had to implement RBAC for administrative tasks we run into the following problem. Running ALTER DATABASE for any database which is in the recovery mode while having permissions lesser then administrator causes crashing of the process and dumping it into the file by default. The operation described above is very often used with a mirrored database, for example to mirror it. Again the bug was admitted but we were proposed using the administrator’s permission for the job as a workaround. The bug will be fixed in the next release they said. This bug can be costly, at least it is for us (BTW, technically it can cause DOS for the SQL server as dumps can be very large and be created very fast)
All the bugs above could have been found by testing against the environment built in accordance with the security best practices. Those features which are just absent (not bugs) could be introduced much earlier if someone really thought of secure deployment for them. Unfortunately all the examples above show that the job hasn’t been done. I would like to think that those are only individual mistakes, but if only one man (me) ran into so many of them, then I am afraid they are just the consequence of the lack of integrity in the approach of PGs to the trustworthy computing.