May 30, 2006
Have you ever had one of those days?
Oh man... sometimes you just want to grab a keyboard and smack yourself up side the head.
Ok, so time for a little secret.... I'm human. And I can be dumb at times. Not "doh.. I am so smart, 's-m-r-t' smart" kinda dumb. Actual "Dana you should know better" dumb.
Recently found a bug I had in an failure code path which in all accounts, was missed in testing. During a database insertion, I would validate the data. Makes sense, always good to validate the data. One problem. One of the validation checks is to escape single quotes. Ya, except I forgot to call that validation against one of the fields. *sigh* But that wasn't the dumb-dumb part.
What compounded this problem was the fact that this was all done in a database transaction. On failure I would call a rollback, like all good database insertions should. Now for the dumb part... the audit log for this failure... was being inserted into the database in the same bloody transaction. ARGGGGGGGGG. So even though I thought I was being smart in putting the audit log in the failure code path, on a rollback the failed event wasn't inserted into the audit log table at all. No wonder no one caught this.
Gosh I feel dumb. I think I will go crawl into a hole for a bit while the scolding and heckling commenses. I should know better than this.
Moral of the story: ALWAYS test all failure code paths, and make sure code coverage can prove you are going down that tree.
May 25, 2006
Vista Beta 2 Security Advancements
Some of the features include:
Lots of stuff in the security arena going on in Beta 2. Check out the document for more details.
May 24, 2006
SBS Devs: Server Core + ISA 2007 = Kick ass SMB Firewall
Here is a thought for the SBS devs on campus. I just fell in love with the thought of Longhorn Server Core. For those of you that don't know, it is basically a minimal install of Windows Server WITHOUT the UI, and without the shiny client apps. God forbid... its a SERVER OS performing SERVER functions without the fluff. Thats right. No media player on a server. Cmd line at its best. Want UI? Use an MMC snapin. Thats what the technology is for!
With Longhorn Server Core you can make the system perform one of the following roles:
There is talk they will add a web server role to support IIS7. Right now there is no managed code support, so no ASP.NET support. Apparently its in the works though.
I have another role suggestion. Firewall. There is always discussion in the SBS community about moving the ISA firewall off of SBS, decoupling the functionality and letting us move the license to another machine. Maybe its a pipe dream. But this would be an OPPORTUNE time to do something about it. In Cougar, wouldn't it be nice if another CD shipped which was Server Core with ISA 2007 (we aren't ever getting ISA 2006) preinstalled... with hooks in the SBS Management Console to admin the new member server through MMC? You wouldn't even need as much power on the Core server as it would be designed to ONLY function as the role of Firewall/Proxy for the business. We would finally have ISA off of the SBS box, and performing the firewalling task without interrupting the rest of the network.
Just a thought.
You have the technology. You just need to make the business case. Here's one. Invest in making that work, and then offer it in cheap external device. :) Don't want to be a hardware vendor? Find one of your partners to do it. I'd buy it if it was around the same price as a Sonicwall TZ170 or a Watchguard Firebox.
May 23, 2006
LUA with UAC vs Least Privilege
So today I was talking with Eric about my previous post Microsoft... Eat your own UAC dogfood already!, when he asked me if running as an admin on Vista with LUA enabled count as least privilege in my mind. (I am paraphrasing... pipe up if I misunderstood the question Eric). It was a good question, and I thought it might be good to blog about the differences, especially as it relates to the security decisions that occur in Vista with the two scenarios. You see, they are actually different.
To me, least privilege means that you are given the privileges to accomplish your task/role/job. Nothing more. That's the whole point of the LEAST part. It is giving enough privilege to accomplish what you are deemed responsible to accomplish, and prevents you from doing things you aren't. When least privilege is rolled out properly, users won't even know they are using least privilege unless they do something they aren't supposed to do on the system. And that is the appropriate time to educate them on why they were not authorized to perform that function in the first place.
In Vista, LUA is Microsoft's first REAL attempt to minimize the required privileges to accomplish basic tasks in the system. Through UAC, a normal user cannot elevate their privileges without providing another credential. Today, we do that with runas or "Run with different credentials" or use some deep API to provide a secondary login to the security context we want. In Vista you get a new dialog prompt on a separate, secure desktop. That dialog will normally look and act different if you are a limited user or an admin.
If you are running as an administrator and make a request for a privileged operation, you get a dialog which offers you to make a security decision. It will ask you to make a decision to "Permit" or "Deny" the privilege elevation. If you are unsure, even though the default is now set to "Deny" (a good default choice), chances are you will just hit Permit. Why? How DARE a computer stop you from doing something. Problem is, there is no security challenge. I can't STOP you from hitting Permit. And with what we are seeing in the field, click fatigue has people just hitting Permit all the time. Not so good.
Now enter in a normal/limited user. That same action will show a different dialog box. It will require you to enter in the credentials of someone with authority to have the privilege. Oh no! You have to type a password in again. Fair enough complaint. But I would prefer to have to reenter a credential than simply cache it like OSX does... which leaves a possible attack vector if hostile code can wait for the elevation before running. Of course, Microsoft could make it easier by storing the credential in DPAPI and calling it up in the secure desktop.(Ya some work would be required to make that work properly... it's just a thought).
The point is that it is an entirely different chain of security decisions. As an administrator running UAC, you aren't challenged for your credentials when you need it most. When you run with a limited/normal user account... you are.
And that, to me, this is the difference between LUA with UAC and least privilege. A normal user can't do things they aren't supposed to do without making a concious security decision authorized by someone with required privilege. When logged in as administrator, you can. And knowing the weakest link in security is the human factor... a user running as administrator on a Vista machine is more likely to make a bad security decision than a normal user in this manner. And worst yet, people will associate the decision as a user problem! "You clicked on the dialog sir... you allowed it". UAC shouldn't absolve a software vendor of liability when it comes to privileges. They simply shouldn't need the privilege in the first place!
Just my opinion anyways. Fire away. Feel free to add your own comments if you think I am wrong.
Microsoft... Eat your own UAC dogfood already!
According to an article on ZDNet, Microsoft is CONSIDERING using UAC for their employees.
"We haven't made that final determination yet. We would like to absolutely look at scenarios where we can look at elements of User Access Control -- that is the feature in Vista -- so that we can start moving in that direction," said Estberg.
Why haven't you made a final determination? On the CORPORATE net, this should be a no brainer. EVERYONE should be running with least privilege (Yes, that means Bill and Steve too). Those secondary dev machines... ok maybe think twice. But put them on their own private network! Or use Virtual Server. Yes, some software will break. But then you can turn to those 3rd party vendors and get them TO FIX THEIR BLOODLY POORLY DESIGNED SOFTWARE, or at the very least, fix UAC so its not a pain for most users as we are seeing in the field.
It drives me bonkers that people think you cannot install software with a limited account. I do it all the time. I just point the install to c:\documents and settings\dana.DOMAIN\program files (a directory I created) and install it there. If the app requires privileged registry or file access, I weigh the risks accordingly and decide if I need to give permission, or scrap the app. If I need permission, I request it (of myself... I don't have a large IT team to do it for me). But I am making a concious risk decision when I do that.
To be fair, I REALLY like Estberg's attitude towards security accountability.
When asked about the one thing he would change about Microsoft's internal IT systems, Estberg said: "The thing that I would most like to change is driving awareness of security accountability across individuals in the company."
Imagine if, with the return of towels at Microsoft, that there was a 3 strike firing policy if you installed administrative installed malware on your desktop. (Yes that is extreme). I bet MORE people would be willing to give UAC a try then.
UAC has the potential of making a huge impact on safer computing in the Windows world. But only if its used properly. It will eliminate entire attack vectors, and make the attackers go back to the drawing board. If someone like Microsoft cannot even demand it of themselves, how will others embrace it? Eating one's own dogfood is NOT about taking a taste. Its about making 3 square meals of the thing and seeing how your palette REALLY likes it. How much more effective will the UAC rollout be if they find the right balance between automated security decisions and the hated dialog prompting? Thats a HUGE potential opportunity being squandered away.
Microsoft... eat your own dogfood. If it tastes THAT bad, then maybe you have a bigger problem to address than the Vista release date.
May 16, 2006
Moving to automated behavioral classification for malware detection
These days I am jealous of some of the neat security research being done over on the Microsoft campus. Although I don't have any plans to ever work there, there are a few teams that are doing some interesting stuff I wish I could be part of... if nothing more but to learn.
Today I saw a great blog post by Tony Lee, a virus researcher on the Microsoft Antimalware team. Apparently one of the growing challenges Microsoft is facing today is the large number of active malware samples, totaling in the order of tens of thousands, and increasing rapidly that his team has to sift through. The traditional manual analysis process they are using is not adequate in dealing with malware of this order of magnitude, and they are thinking about new ways to automate this process.
Tony and Jigar J. Mody (a colleague on the anti-malware team) wrote and presented a paper on "Behavioral Classification" in which they dive into tackling the challenge of the classifcation process. I was quite engaged as I read through it, as they have approached it in an interesting manner.
When it comes to this sort of analysis, in the past it has been perceived that human heuristics will always trump automated methods because the attack vectors can easily change. However, what Microsoft is seeing is that the classification can be weighed in such a manner that by using runtime events and machine learning, classification is indeed possible with automation. Some of their initial research shows up to 84% success rate. Of course, what wasn't detailed is if the failure rate is in misclassifcation, or if they are not being able to classify it at all.
It will be interesting to see where they go with this. As more hostile code is created, developing an automated classification process that can leverage behaviorial learning capabilities will be critical for malware intelligence and defense.
Interesting stuff. You should check out their paper on the topic.
The Silver Bullet Security Podcast
Got an email last night from Gary McGraw letting me know that he has started a new podcast called the "The Silver Bullet Security Podcast". I listened to his first episode this morning, and its pretty good. He interviews Avi Rubin, professor of computer science and technical director of the information security institute at Johns Hopkins University.
You should go give it a try. It's pretty good.
My only comment to you Gary. Get your show up on iTunes. I sync every morning to my security podcasts, and would love to add you to the iTunes Podcast feed.
May 14, 2006
Introduction to ISA 2004
So this weekend I was invited down to the Microsoft campus in Redmond to present on an 'Introduction to ISA 2004' for the PacWest SBS UG meeting, which involved user groups from Seattle, Portland and Vancouver. (I think.. my apologies if I missed a group or two)
As promised, here is a copy of my slidedeck.
I also said I would comment on the myth that ISA sucks if you have remote management cards. You know, those out-of-band management cards like the "HP Remote Insight Lights-Out". It is true that if the SBS box fails and ISA isn't available that it could be impossible to access the card's IP address. After all ISA is down, and nothing will go through it. That's the whole point of it failing closed. That's not a bad thing.
This is one of the few times I would recommend one of those $50 Linksys/Cisco NAT devices with simple ingress filtering. You simply set it up to block ALL access except FROM a trusted IP (ie: Your office) and allow it to simply access the remote card. You could use a simple cross over cable on the LAN side of the device directly to the remote card. WALLA. Problem solved. Secure access to the OOB management card, and still utilize the benefits of ISA server.
Please consider it. Don't through away ISA over something that can be solved for less that $50 and 10 minutes of your time.
Thanks to Steve Banks and Mike Iem for asking me to come down and talk about security and how it relates to ISA. I hope you guys learned something, and above all... had fun. It was a beautiful Saturday and I appreciate you decided to stick around and listen to my drivel when you could have been cruising around in the west coast sunshine.
May 02, 2006
Good security decisions keeps slipping in Vista
I'm a big fan of Vista. I see a lot of potential in the new features and function as it relates to security. I love UAC, even though it has a ways to go with its popup dialogs that are annoying many a beta tester. But this post isn't about talking about the goodness of Vista. I want to take a moment to just point out that everything isn't all rosey in the Vista security camp. Much like many security decisions of the past, good security decisions are getting trumped by poor human interaction. And it's really too bad.
People are demanding that UAC be turned off. I just shake my head. The benefits vs the draw backs of a few extra dialog prompts just aren't being seen by the end users. They don't realize just how much safer least privilege really is. Paul Thurrott does a good job to berate the Vista security features in a post about the very subject. Worse yet, Bruce Schneier supports Paul's conclusions, and I think it was best said when Bruce stated that:
Warning dialog boxes are only effective if the user has the ability to make intelligent decisions about the warnings. If the user cannot do that, they're just annoyances. And they're annoyances that don't improve security.
UAC isn't the only problem. Many readers know I spend a lot of time writing secure code. Not just security-related code, but code designed to be safer and more secure. One of the benefits of languages like C# and Java is the fact that its type safe. This is just fancy words for meaning that programmers can't as easily treat a value as a type to which it does not belong. We see a lot of vulnerabilities in the past that relate to the fact the programming language used was not type safe (aka C, C++ etc) and the programmers used it incorrectly, opening us up to new risk. When friends and colleagues of mine continue to see this in the field we shake our heads. Heck, Gary even wrote a good article on the topic in which he points out that Microsoft missed an opportunity with Vista to more enforce type safety. He has a really good point when he says:
I asked Butler why it was that Longhorn (Vista's codename at the time) was not built out of a type-safe language like those available for the .NET framework. He shook his head in dismay and decried the fact that we had let another great opportunity to make a huge impact on computer security pass us by. He said that opportunities like this come only once every decade or so in his experience and that he had seen four attempts to cause widescale adoption of type-safe languages founder on the rocks throughout his career.
The problem, it turns out, is that the .NET builders did not give much thought to providing many of the essential basic building blocks that operating systems construction crews need for their work. Interpreted code has some minor performance issues as well (note that there are many ways to overcome this often overly shrill critique). But the main problem was that the Microsoft OS guys are big C++ users. Getting them to switch over to C# was for these reasons not in the cards.
For those of you that don't know, Gary is referring to Butler Lampson, a legendary scientist, and he has done plenty of great pontificating about security, privacy, software, and technology. Like many superior computer scientists, Butler now works for Microsoft Research.
So we lose out on that opportunity with Vista. We will have to wait another 5 to 10 years for Microsoft's next real advancements to hopefully take advantage of type safety. By then most of the old gear head C coders will have retired or moved on, and C# will be more heavily adopted in the company. Hopefully. Who knows.
Today I heard on Cnet that Microsoft is dropping token support from Vista. Even in the face of Steve Riley coming to the community and asking what we want out of two factor authentication, and Bill Gates predicted death to passwords with the integration of SecurID in Windows for Vista, they have decided to drop it. That's really too bad. The thought of built in one time passwords with two factor authentication really appealed to me.
As Vista continues to be delayed time and time again, we continue to see things get dropped. Now, I respect that security decisions at Microsoft are not easy, and at times its easier to pull them. But it sure makes it difficult to make decisions on the future of security on Windows when Microsoft keeps moving the goal posts around. We can look at the history of the TCPA/NGSCB soap opera on that one.
Maybe a better idea would be to leave those type of things alone and let ISVs take care of that. Instead of running to try to add all these into Windows it would be better to make more generic systems that other vendors with expertise can hook into. Make the GINA (Graphical Identification and Authentication) hooks easier and let RSA, CryptoCard, Authenix etc build their own support in. And then have Microsoft certify and support it with strong Microsoft logo programs. Quit fighting with Windows Defender and work WITH security ISVs who have expertise in the field and use their common body of knowledge to apply directly into the Vista system instead of re-inventing the wheel.
A year ago if you asked me I would have given Microsoft an A on its report card for its secure software development lifecycle. But as we see the Vista shipping deadlines come and go, I start to wonder. What else is going to be cut before the shipping date? Just where will the security lie by the time Vista goes GOLD RTM. I really hope they don't do anything drastic like turn off UAC or minimize its effectiveness becauses users demand it. Security will always have compromises, but we need to make sure we don't sacrifice good security decisions to appease the user. We need to think more critically and find ways to simplify the process so the user can benefit from the security decisions without being heavily taxed in having to make the decisions themselves. UAC was not designed to absolve Microsoft from bad security decisions (ie: "Well you clicked ok to install that hostile code"), but to notify the users that a privilege operation is about to take place. Problem is, too much of that and the user will gloss over and just stop reading. I think Microsoft is going to need to keep working on that in the coming months to find the right balance.
In the meantime, here is a tip for the Vista users out there right now. If you feel compelled to turn off UAC, DON'T! That's a bad security decision if you ask me. Instead set the "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" policy to "No Prompt". In this way, when a privileged operation is required it will elevate as required. However, all other apps will run with standard user privileges, and you can turn on auditing to monitor the system a bit better. It's like turning UAC off, but better. Remember though, you are losing the benefit of being notified/prompted when a privileged operation occurs. Of course, I would recommend above all things to try running with a limited user account and NOT an admin account, and live with the UAC dialogs. After you use Vista for a while you will notice when a prompt will be required (you will see the security shield beside the function), and can decide if you really need that privilege or not.
Lets all hope that by the time Vista ships, that more security functionality doesn't slip out of the system. If anything, that some of this stuff comes back in. Or that a more clear path is available to understand where ISVs can add value without stepping on Microsoft's toes.
Why Apple marketing is WAY better than Microsoft's
Although I am not the biggest Apple user in the world, I have to admit that I believe that their marketing guys are WAY better than the Microsoft marketing guys. Want proof?
Check out the Apple - Get a Mac campaign.
Years ago my favorite Apple ads were these ones:
Of course the REAL funny thing is that Apple now runs on an intel processor. LOL
May 01, 2006
Understanding the value of Vista's Firewall and outbound filtering
Jesper has an interesting blog post discussing what he thinks is the best new security feature in Vista... the Windows Firewall. I am more inclined to say I like UAC better, but thats just me.
Anyways, besides the excellent breakdown on the benefits of the new Vista firewall, Jesper has some discussion on outbound filtering offered by the new firewall, and that it is disabled by default (which is actually incorrect, see his post for more details). This is quite topical to me as we have been discussing this in some detail on a few security lists I am on.
In my opinion, the key take away from Jesper's post is this...
Protection belongs on the asset you are trying to protect, not the one you are trying to protect against!
However, I have to disagree with one part of Jesper's position in regards to this. When the asset you are protecting against comes from another asset you have control to, providing as many layers of defense as possible to assist in the least privilege stance of the asset is helpful in diagnosing and tracking down security violations. In other words, if you have the ability to control outbound filtering, the benefits do exist in applying them to control network packet flow.
If we look back in history to worms like SQL Slammer, we KNOW that those machines are NOT configured to offer outbound SQL connections. So why let it? Instead of allowing all outbound connections and hoping to trap it at the perimeter (which typically is just as poorly configured for outbound connections), why not provide least privilege at the network level and not ALLOW outbound connections in that manner from subjects like this to objects we don't know about. The result would be the significant reduction in the propogation of such hostile code against such attack vectors.
Jesper points out that it would be easy to circumvent much of this. Well yes, if you expect your firewall to act at the TDI layer, its easy to get around. But if you constrain it down at the NDIS layer with deep policy to control the machine to only send out packets to services you wish it to access (following least privilege here and only offering network access to resources needed to perform the task of the machine), you have a much more finite network flow of data. Of course as Jesper kinda eludes to... if the user is logged on as an administrator its a pretty moot point since they can turn off the firewall anyways.
I you want to learn more about the Vista firewall, I highly recommend you check out Jesper's post. It's a great read.
The "Power User" account isn't a good security compromise for running as a limited user on Windows
I've said it before and have been criticized. The Windows Power User is just NOT an acceptable account for least privilege. It is far too easy to elevate privileges to gain Administrative rights on the system. I have even shown this live during a presentation at a security conference. And still many disagreed with me. I can never figure that out.
But not Mark Russinovich. Mark has done an EXCELLENT job in investigating this and showing how simple it really is, all while creating a new Sysinternals tool to help in the investigation. On his blog today he posted about "The Power in Power Users". I think his conclusions are worth repeating here:
The bottom line is that while Microsoft could fix the vulnerabilities I found in my investigation, they can’t prevent third-party applications from introducing new ones while at the same time preserving the ability of Power Users to install applications and ActiveX controls. The lesson is that as an IT administrator you shouldn’t fool yourself into thinking that the Power Users group is a secure compromise on the way to running as limited user.
One thing worth mentioning and eluded to in Mark's post is the fact that in Vista, this attack vector has been plugged. Power Users rights are managed differently with UAC; they are treated as limited users from the get go. Then again, so is the Administrator account.