Welcome to TechNet Blogs Sign in | Join | Help

Today was my last "normal" day at Microsoft. (That's with a grain of salt - an exceptional company has few normal days). Tomorrow I just have the exit interview early and then I will be unemployed for a few days. I wonder when I am officially not an employee any more?

In case you had not seen it, I got a new blog a while ago. The plan is to continue what I have been doing on this one over there. Right now, there are only a few posts in it, but that will change soon.

Leaving Microsoft, and particularly the great people I have worked with here will be hard. These have been great years and the company has made huge strides. I am really looking forward to Windows Vista. There are so many important behind-the-scenes security features and the changes to the development process are unlike anything the software industry has ever done; certainly unlike anything Microsoft was doing when I started.

Go forth and do good, and I will see you on the new blog, and maybe at some event in the future.

Thanks!

Today the plans for what I am doing before I leave changed, again, but not as drastically as last time. It turns out that I am going to TechEd Japan after all. I will be delivering the "Is That App Really Safe" and "Baking Security Into The Development Lifecycle" presentations.

I am really looking forward to getting to do one last event as a Microsoft employee. Let's make sure this is a good one!

Some of Microsoft's amazing Most Valuable Professionals (MVP) made me a blog on a new site they call msinfluentials.com. I can't thank Susan, Nick, Vlad, Chad, and Wayne enough. You guys are truly special and exemplify all the best things about the MVP program.

Until I leave Microsoft on September 1 content generation on the new blog will probably be a bit light, and I have not quite finished configuring everything yet. You can still contact me through that blog though, now and after I leave, and I will write there as circumstances allow.

I have unfortunately been prevented from speaking at TechEd in New Zealand, Australia, and Japan; the final events I was planning to speak at before I leave Microsoft on September 1. I cannot express how terrible I feel about this. The hope was that these events were supposed to be an opportunity to celebrate the past and the future before I move on. The only thing I can say is that I hope to see everyone at some other event in the future.

Sorry.

Last week a new security problem was announced in the Intel Centrino wireless drivers. It appears to affect the 2200BG and 2915ABG wireless hardware. These are extremely common components that are shipped in many laptops. You would do well to check whether yours or the ones you support have this hardware. The easiest way to check is to double-click the wireless icon in the system tray and then click Properties.

There is information on the web site for how to identify the drivers as well. Systems with these drivers would have entries under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ with the name of the driver. That could be used to search large numbers of systems.

Updated drivers are available from the Intel page that announces the problem: http://support.intel.com/support/wireless/wlan/sb/CS-023065.htm.

Blake Handler sent me a link to his blog post about free Windows software a couple of days ago. It is a very cool list that shows a lot of free things published by Microsoft. Check it out at: http://bhandler.spaces.live.com/blog/cns!70F64BC910C9F7F3!1231.entry?_c=BlogPart.

Note that for some reason the Live blogs put you at the bottom of the post instead of the top when you click it. Scroll to the top to see the list.

This is an excerpt from a mail I sent out internally today:

The sands of time seem finally to have run their course. On September 1 I will not only celebrate the 5-year anniversary of my time here at Microsoft but also my departure from the company. On September 5 I start a new job as Principal Security Program Manager at Amazon.com.

This was a very difficult decision for me and has taken a long time to make. All in all, I have had a great five years to look back at. So much has changed in security at the company since I came here. It has been a remarkable ride to see the turn-around and having been able to play part of if for this long. The hardest part of this transition will be not being part of this ride any longer and not being able to work with all the great people I have worked with here.

I will not be leaving Seattle, nor security. I will have a new blog by the time I leave. The exact location will be announced in here as well as on the Protect Your Windows Network site: http://www.protectyourwindowsnetwork.com once I get it set up.

A while ago I once again got frustrated by LMCompatibilityLevel and the amount of confusion that is out there about it. There was also an intriguing thing in the SAMBA documentation that they (incorrectly) called "NTLM2 Session Response" that needed figured out. The results are in the latest issue of TechNet Magazine.

One additional thing deserves mention. Roger Grimes contacted me after he saw the article and asked why the Cain tool shows an MD4 hash and an NT hash, when I claim the NT hash is actually an MD4 hash. He then proceeded to answer his own question because I couldn't think of why. What Cain calls an MD4 hash appears to be an MD4 hash of the entire string, including the NULL terminator. The NT hash that is used in Windows is, as I mention somewhat obscurely in the article, a hash of the Unicode password string (in fact, it is even called the UnicodePwd in Active Directory, as I pointed out in the book among other places), but it does not include the NULL terminator. It just never occurred to me that Cain might display an MD4 hash that does. Thanks Roger for figuring that out.

I've been trying to come up with a list of attributes that a security solution needs to have to be complete and sufficient. The idea is to develop a set of attributes that can be used when analyzing security to see if it fulfills the needs of the situation. Obviously, risk management is the most important aspect of security analysis, but if we can distil a complex design into a small set of attributes that appropriate solutions generally would have then we could use that to analyze how good our solution is. This would be helpful when analyzing security solutions, be they security features in an operating system, an architectural design of a network, a physical security infrastructure, or any other type of security solution. The attributes also need to be a parsimonious set. Attributes of a solution need to be less complicated than the solution itself to be useful for analysis, otherwise why abstract the solution into its attributes?

I wrote these down a while ago and have been hoping I could refine them by doing what I always do - mull them over mentally for a while. However, I can't seem to come up with anything better, so I thought I would open up the thinking to the community and see if anyone else has any better ideas.

  1. Comprehensive - The solution needs to cover the security issues it purports to resolve. It does not need to cover all security problems, but in conjunction with all the other solutions it should contribute to solving the problem. If the solution leaves holes uncovered something else must be available to address those holes.
  2. Comprehensible - The person intended to use the feature or implement the solution should be able to understand how it works, how to implement it, and how to address common problems.
  3. Adaptable - The solution should be flexible enough to work in several environments with differing risk management strategies. A solution that is not appropriate for all environments should not be mandated for all environments. It should be adaptable for each environment.
  4. Centrally manageable - A solution should be manageable centrally. Essentially, all configuration, enforcement, and reporting, should be centralizable.
  5. Enforceable - A solution must be enforceable. A solution that can be turned off or disabled by those who should be protected by or against is unacceptable. If a solution is accidentally disabled in violation of a policy it needs to be turned back on automatically.
  6. Reportable - It should be possible to generate compliance reports about all aspects of a solution. At a minimum reports should contain the status of the solution in all places where it should be applied. Variance reports, showing out of compliance areas, are also important.

In a very interesting twist Microsoft today announced the acquisition of Winternals and Sysinternals. This is really interesting news and I am glad to see Mark Russinovich and Bryce Cogswell getting to have more of an impact on the Windows product.

Just in case your are of the vulnerability counting type, you may be interested in an analysis posted by my friend Jeff Jones in his blog. Jeff has done some pretty amazingly detailed analysis of the number of vulnerabilities in each of several products.

Many of the attendees from the recently concluded Security Summit series in the U.S. have been asking for the slides. Since we will be doing web casts of the presentations we are not making the slides availble. What many people want though are simply the resources listed in the slides. To attempt to achieve at least some level of satisfaction with this dillemma I thought I would put all the resources in a blog post. Here are the ones from my sessions:

Windows Vista Security Keynote

  • Windows Vista TechNet Site
    http://www.microsoft.com/technet/windowsvista
  • There are a number of Windows Vista web casts available on that site, including one by Austin Wilson which presents much of the same material I presented

Incident Response

Server and Domain Isolation

Webcasts
There are several webcasts that are already up. Here they are:

I may as well point out that there are also lots of web casts from TechEd US 2006. Those are of course unrelated to the security summits, but may still be of interest. I have one in there on Windows Vista from this year and a couple of older ones.

Again, I really apologize for not being able to send out the presentations.

I couldn't tell you how many times I have either had the question "how do I turn off User Account Control" or heard the statement "boy, I sure hate all those annoying user account control popups in Vista."

Yeah, security sucks, it gets in the way of doing things, some bad, some good, but that's a fact of life. The other fact is that User Account Control (UAC) is one of the most important ways that we hope to protect people in Windows Vista. I have many times told the story about how Steve (Riley) and I were at an event when he gets a call from his wife asking for help with her computer. Apparently it was getting all sorts of popups, ads, and other weirdness; clear signs of spyware. He stated that he'd fix it when he got home. When he did he downloaded and ran all kinds of cleaners, and then called me with the astonishing results. The computer had about 168 separate pieces of spyware. So I went and ran the same cleaners on the computer in our kitchen, the one most of the family uses. On that one we found exactly zero problems. The difference? Steve is a nice guy, so he gives his wife administrative access to her computer and everything installed nicely, including the spyware. I am, well, there is a term for it, but it is not suitable for electrons, so none of my users ran as an administrator. The result, nothing installed, including the spyware. This experience obviously does not guarantee that just by running as a normal user you will not get spyware, but it will make it more difficult to get it, and it will make it easier to clean off.

The problem is that without considerable savvy, or lots of time spent in Aaron Margosis' blog, the vast majority of people today can't run as a non-admin user. The reason is all the apps that require administrative privileges. To solve that problem, we can do a couple of things. We can try to plead with the app vendors to fix their stuff, and you know how well that has worked in the past. We can stop buying these defective apps, and you know how well that has worked in the past. And, we can build a technology that allows most people to do most of the things they need to do to run the computer on a daily basis as a non-administrator. That technology is called User Account Control.

Windows Vista includes a number of features that work as part of, or in conjunction with, UAC to meet three important goals. The first is that these features allow a lot of applications that did not previously run as a non-administrator to do so. This is done by virtualizing key operating system locations, such as the Windows directory and Program Files. UAC also changes the privileges required for many common tasks, such as changing the time zone, power settings and even installing approved devices and ActiveX controls, so those tasks can be performed by ordinary users. This allows users to run as non-privileged users while allowing many scenarios and applications that did not work that way under Windows XP to still work. The second promise is to create an easy elevation path for applications that really do require administrative privileges, while still allowing even users who are administrators to run as non-administrators most of the time. This means that even for users who are in the administrators group, applications like Internet Explorer and the mail client do not actually have administrative privileges all the time, reducing the damage attacks against those applications can inflict. Finally, UAC allows us to quickly spot all the broken apps out there so that we can either shim them to run as non-admins or get them fixed. This latter is at the same time the most subtle and arguably most important of the things UAC does. It is also in many cases the most obvious, and the reason many people want to turn UAC off. By doing so, they allow applications with fundamental design flaws to still work, reducing the pressure to actually fix those applications so they work as non-privileged users, as most of them should.

None of that will work unless people use the feature. To do all those things we need your help, yes, yours, as a beta tester of Windows Vista. Unless we get feedback on what works and what does not we can't fix it. If you disable critical technologies that we are trying to get to work, we can't fix them. That means that, yes, some things will be annoying and not work quite right in the final release, unless people work with us to fix them. Going out with statements like "this is the worst feature ever and I already disabled it and will never re-enable it" based on unfinished beta code is simply silly. Why not instead realize that allowing people to run as a non-admin is one of the most important things that can be done when it comes to protecting your system, and that it won't happen if the only people trying to get it done are a few program managers at Microsoft. Work with us on this one and help us build a great, usable, and useful UAC. If you find prompts that are absolutely egregious and need to go, send us feedback on that. We need to know. If you can't find any other way to submit it, send me a comment on the blog and I will get it filed.

Disabling UAC also removes many other protections. For instance, if you set the "User Account Control: Run all administrators in Admin Approval Mode" security policy item to disabled you actually remove all of the benefits of the integrity controls and the restricted security tokens from your administrative account. That means that Internet Explorer, for instance, will run as a full administrator, just like it does under Windows XP. By extension, it means that any missed click or accidental navigation could completely compromise your system, just like under Windows XP. If you have to disable UAC temporarily, for example while you are building out the system and you can't stand all the prompts, do not turn off Admin Approval mode. Instead, change the behavior of the elevation prompt for administrators in Admin Approval mode to not prompt. That way you at least leave Internet Explorer protected with a low integrity token.

Once the OS is released, if you absolutely can't stand a security feature that is designed to protect you, by all means, turn it off. For now though, realize that this is beta code. It is not quite done yet, and it won't be quite right unless we get help from the people entrusted with pre-release copies of the operating system.

To learn more about UAC, check out the UAC team blog. A lot of questions and concerns about UAC are probably already addressed there.

As my family keeps reminding me, I'm not much of a people person. It could just be that I am projecting myself onto others, but I am pretty sure that much of the IT industry is like me, which raises a number of serious security problems. If you are interested in reading about them, I have an article in the July issue of TechNet Magazine about this issue. If you just want to argue about and/or discuss it, we can do that here.

Last week I visited a customer and was greeted by two people who introduced themselves, respectively, as the "Chief Information Security Officer" and the "Chief IT Security Officer." Yes, they had two separate functions for this, one to secure information, and one to secure IT. This immediately seemed like something that would be logical for many organizations. The threats to the infrastructure are obviously different to the threats to the information itself, especially when your business is based on providing one or both to customers.

This stirred me to think more about something I have been mentioning in many of my recent presentations: where does Infosec (both IT and Information for ease of discussion) belong organizationally? When I spoke to a bank recently I asked them where Risk Management sits organizationally and they mentioned there was a VP in charge of that, but that Infosec was sitting in the IT department.

I am not sure I have the right answer about how to structure organizations, but I am pretty certain that putting Infosec under IT causes certain problems. As far back as the Fundamental Tradeoffs article, and even further, I have made the argument that security and IT management are fundamentally two different disciplines. IT management has as a primary objective to make the technology work, to be transparent to people, to ensure the information is simply there when users want to use it. All of those can be summed up in the phrase "to stop the phone from ringing." Any IT manager knows that he phone usually does not ring when things are working; it only rings when something is broken.

Security is, obviously, about restricting access to things. As far as the business is concerned, Infosec provides no intrinsic value. Spending money on Infosec is done to ensure that nothing happens. Success is measured by the absence of events, which could of course be because the efforts of the Infosec folks were successful, or simply because there were no events at all; or possibly because we failed to notice. IT at least provides a valuable business function that is tangible in its absence. The absence of any benefits from the spend on Infosec may be attributed to something extrinsic to the Infosec group; and the benefits are extremely difficult to quantify a priori

This inherent conflict of objectives has been acknowledged before, most famously in the "Confidentiality/Availability/Integrity" triad. However, I would argue that the "Availability" dimension was added by IT management, not by the security folks, because it goes entirely counter to the other two dimensions. Those other two dimensions are best achieved by reducing availability, first to illegitimate users, and then to legitimate users to avoid a spill-over of information to the illegitimate ones. In fact, the CIA triad reflects the historical perception that Infosec somehow belongs in IT. I don't think that is correct, at least not any longer, but maybe it never were.

So why am I writing this? I am writing it because I would like to stir some debate about where Infosec belongs. I think it should sit wherever Risk Management sits (which of course means the organization needs a Risk Management group to start with). The whole purpose of Infosec is risk management. The group that has risk management as its responsibility has oversight ability, it has the skills to assess and quantify risk, and it has a mandate to influence other groups. That group also does not have to be restricted by pecuniary and functional concerns that restrict the service delivery organizations. Infosec obviously needs a deep relationship with IT, but also with other groups. I have seen far too many organizations that have caved to the pressures of service delivery or inaccurate vendor claims and implemented extremely bad security architectures. Invariably, the Infosec folks at the table were too few, too restricted by the organizational structure, too confined in a career dependent on service delivery and not security, and too worried about rocking the boat politically to put a stop to the problems.

Freeing Infosec from IT would allow IT to focus on delivering IT services, and it would allow Infosec to make itself heard and not be voted down by a much larger service delivery constituency in the mainstream IT group.

 

 

More Posts Next page »
 
Page view tracker