nCircle blog states that they think Microsoft's security initiatives are a joke

I was surprised this morning to come across a blog post over at nCircle where they were attacking Microsoft's security initiatives. It was rather interesting to me because I was agreeing that I don't believe its right to have Windows Media Player installed on a Windows server. Quite frankly, a lot of the accessories shouldn't be needed on a main server. But what got me was that we were comparing a product that was written 4 or 5 years ago, BEFORE the security initiatives really were occuring on the Redmond campus. As a follow up, another employee at nCircle tried to balance the discussion with another post about why Microsoft has the right approach to security. In it, there were a few counterpoints, but not enough clarity to the work that Microsoft is REALLY doing behind the scenes as it relates to building a safe and secure platform for consumers and businesses alike. I decided to respond in the comments, and then decided I may as well report it here so I got a record of it, in case it disappears off of nCircle. The following was my response to the original post:

What can I say? You're right that in an optimal situation there wouldn't be a media player installed on a server. However, using your logic, why would you allow an attack vector of untrusted code from a foreign device execute either? You need to turn off the USB ports. There are always going to be tradeoffs that need to be made for function. What makes sense to your corporate security policy may not make sense in mine.

Look, security is about risk mitigation, and not risk avoidance. If you aren't applying the proper information security principles and practices to your organization, it doesn't matter if media player is installed or not. The administrator shouldn't be playing music or browsing from a server period. And that is a weakness in the human factor, not the technology.

Although you cannot easily remove things like media player, you can just as easily prevent Media Player from running with restriction policies. This is a configuration issue, not an installation one. (I will conceed that media player shouldn't be installed at all on a server, but thats only a small point to a larger issue here)

I beg to differ that Microsoft's security initiative is a joke. You are commenting on an operating system that was written over 4/5 years ago (remember that Windows Server 2003 codebase was feature completed before 2003), before Microsoft really had a chance to apply security to their software development lifecycle. I've blogged about this before (http://silverstr.ufies.org/blog/archives/000808.html), but let me list a few of the initiatives they are doing that is helping to make for a safer computing environment for us all:

1. They have created better error-reporting software. They have found that the top 20% of their errors make up 80% of the problems. Knowing this and capitalizing allows Microsoft to significantly prioritize and reduce bugs that matter the most.
   
2. They have created better developer tools to help write more secure software, with release of tools like prefix, prefast, AppVerifier and FxCop.
   
3. They halted product development for a period of time and retrained their developers to code more securely. This is an ongoing initiative that helps everyone who touches the master sources.
   
4. They audited as much product source code as humanly possible and now have a dedicated lead security person for each component of the Windows source code to watch over code quality as it relates to security. Previously they had a clean up crew come in after the fact and try to sanitize the master sources.
   
5. Microsoft has begun to provide more secure defaults when shipping new product. As a clear example we have seen the launch of Windows Server 2003 with a lessened attack surface than previous versions of their server product.
   
6. Microsoft now provides better tools such as the Microsoft Baseline Security Analyzer to analyze and audit patch management as it relates to security bugs in a proactive manner.
   
7. After major security incidents (like MSBlaster and MyDoom) Microsoft has released tools to help respond and fix possible vulnerable and compromised machines. Although these are not timely enough (IMHO), it’s still good to see.
   
8. Microsoft has provided a more definitive patch management cycle to address "patch hell" until their newer products get released that have a significantly lessened attack surface, and have better code quality.
   
9. Microsoft provides better integrated firewalling with their Internet Connection Firewall (ICF), released with the latest service pack for XP. Ok this item isn't about secure coding... but more about "secure by default" mentality.
   
10. Microsoft is being more open about the entire security process. And not just for PR purposes. More articles, documentation and transparent communication are now available through MSDN, Microsoft employee blogs, and Microsoft's Security webcasts.

Microsoft is far from perfect. But they are making significant changes to address their lax posture over the last decade as it relates to security. And the lessons they are learning are now impacting 3rd party applications which goes even further to protect us all. In the security software engineering field, a LOT of Microsoft's experiences are making headway into designing more secure software. From threat modeling to least privilege token control, Microsoft is being open and letting people understand how to write more defensive code in the Windows world.

Vista is the first real product that we will see where these initiatives have been applied. It will be only then when we can really understand if their security initiatives are a joke or not. I already see things like the UAC subsystem that makes it much easier to run with least privilege in the system. Far nicer than how sudo works or the hacked sudo Apple uses in OSX. We are seeing redirectors and virtualization to transparently deal with non-compliant software. The inclusion of Windows Defender and a proper two way firewall goes a long way to battle hostile code and control network communications effectively.

It's easy to hate Microsoft. It's far more difficult to acknowledge the great work they ARE doing because its so easy to criticize their older work. Lets take the bias and hatred out and worry about protecting our clients. You know, the ones who are mostly using Windows, if we like it or not.

Groan. Wanna learn how to break into Vegas?

OK, so I normally groan at the technical inconsistencies when I watch movies that include hacking. Heck, even in the Matrix I groaned when I watched Trinity use nmap. And lets not even discuss Harrision Ford as a CSO of a bank in "Firewall".

Anyways, today I am groaning for a different reason. And that's due to cheesy acting, not bad tech. And that's ok.

There is a really funny movie on MSDN TV this week called "The Code Room: Breaking Into Vegas". In it, they show attack and defense of the online casino app at the "Plaza Hotel".

It's actually done pretty well. They show real world attack vectors like SQL injection and session hijacking and discuss how to mitigate against it.

I had a real chuckle when Frank was holding his Threat Modeling book and going on about enumerating the threats by analyzing the current codebase. Oh you didn't know? The cast is full of security engineering geeks that we all know and love.

Well worth the 30 minutes, if nothing more to get a chuckle. And hopefully... some of you may learn a thing or two.

Microsoft releases new tool to counteract cross-site scripting attacks

Dan's recent post reminded me that Microsoft has been doing some interesting work lately in the field of Anti-XSS. They have even released a new tool today called the Microsoft Anti-Cross Site Scripting Library V1.0 which can be used to provide comprehensive protection to web-based applications against cross-site scripting.

For more information, head over to Dan's blog and read his commentary about it.

Microsoft releases DACL guidance for developers of Window services

Microsoft has recently released a KB article on Best practices and guidance for writers of service discretionary access control lists that I think developers of services on Windows should really read.

In the article Microsoft shows how to successfully apply DACLs to make services more secure for our workstations and servers, and offers guidance on how to assess the security of your application. A majority of the information surrounds around understanding and interpreting SDDL (Security Descriptor Definition Language), something I fear too many developers don't properly understand.

I would also recommend that you check out the MSDN hub on Service Security and Access Rights. There you can get a better feeling for how the Windows security model enables controlled access to service objects and the service control manager (SCM).

Happy reading!

UPDATE: Alun reminded me in the comments that he wrote a pretty good post on how to read SDDL a few weeks back. You can check it out here.

How to fix LUA bugs

Aaron has started a series on how to fix LUA bugs. If you read his article on “What is a "LUA Bug"? (And what isn't a LUA bug?)" and want to learn how to fix your code, this is a good place to start.

Happy Valentines

What the heck are you doing reading your rss feeds on Valentines Day? Go spend time with your significant other.

Coming honey...

Proof that LUA makes you safer

I was reading a post over at AdminFoo today when Bryan showed an interesting graphic taken from eWeek Magazine that shows how effective LUA really is in the midst of all the current forms of malware and spyware in the field these days. I thought I would post it for my readers to check out.

This is pretty compelling evidence that by using least privilege you can significantly reduce the risk to your computing environments by eliminating the ability for malware to take hold on your system. Take another look at Bryan's post to also get some insight on the original article, and some recommendations he has on how you can use tools like Supsu for LUA now.

And of course, you HAVE read "Applying the Principle of Least Privilege to User Accounts on Windows XP" published by the Microsoft Solutions for Security and Compliance group (MSSC) haven't you?

Outlook 2003 - How it misses the boat when it comes to multi-domain productivity

So after two hours of google searching hell, I have come to the conclusion Microsoft TOTALLY missed the boat with Outlook 2003. I happen to have accounts on TWO Small Business Server 2003 networks, both running Exchange. Currently I use Outlook Web Access for both accounts, and today decided I would start using Outlook over HTTPS so I could tap into Business Contact Manager.

One problem. Outlook isn't capable of CONNECTING to two Exchange servers at the same time. ARGGGGGGGGGGGGGGGG!

Microsoft, you missed the boat here. Why is it I can use Outlook Express to connect to multiple S/IMAP servers without issue, but using your own technology I can't access more than one of your other servers running your own technology. This seems really nuts to me. You mean to tell me NONE of your enterprise customers don't have more than one exchange account?

I was thinking about moving to Windows Mail as I am starting to prep to move to Vista for my day use machine, but heck... it won't help me either. *sigh* I will say though, it looks like Vista might take care of my Calendar hell. We will have to see.

So now I am back to having to use OWA. Man you missed the boat on productivity on this one Microsoft. I hope something changes in the next version of Outlook.

Caveat Lector: Authentication, the Forgotten, Should-be Predominant

Over at windowsecurity.com there is an article today on Caveat Lector: Authentication, the Forgotten, Should-be Predominant. In it, the author discusses the concept of integrity preservation, through the use of Message Authentication Code (MAC). The article defines what it is, what it does, and why it's vital in the majority of cases, although often overlooked in most of them.

It's a pretty good read. It's rare these days that I come across articles where the author gets it that when designing secure channels of communication that you need BOTH confidentiality and integrity. And I think his final word sums it up for me... "If you find yourself habitually applying authentication wherever encryption exists, then hats off to you." I'll add that if you don't, perhaps you need to go read the article.

Happy reading.