There are distinct differences between Unix and MS Windows security philosophies. Two design policies serve as apt examples of those differences.
One of the key differences between the Unix approach to system security and the MS Windows approach is that significant security characteristics of Unix systems are a consequence of good architectural design. Many of these same characteristics, when there is any attempt at all to incorporate them into MS Windows, are implemented as features on top of the OS instead of designed into the system architecture.
For instance, privilege separation in Microsoft Windows has long been a problem for Windows security. Some privilege separation does exist in MS Windows at the architectural level, but it is only a half-hearted implementation, dependent upon user-level features behaving well and being used as intended.
Modularity within the system is another example of architectural security in Unix, but lacking in MS Windows. There are applications that tie into every major part of the MS Windows system in such a promiscuous fashion that something as apparently trivial as a browser exploit can actually reach into kernel space, and from there affect the entire system. The same kind of close coupling between parts of the system does not exist in the base system of Unix.
The importance of privilege separation
Some might complain that all the information you want to protect on your system is stored where your user account can access it, so that privilege separation does not really help security much. These people fail to grasp the full extent of what security benefits you gain from separation of privileges, however. Privilege separation does more than prevent infections and intrusions from gaining access to root privileges.
Malware that makes its way to the system via the network is hindered by the fact that server processes typically run under specialized user accounts on Unix systems. This means that getting in through some network port usually gets the intruder no further than the affected service. This is even true of many services that are started from a normal user account, because those services are typically configured to switch user account "owners" when they start to take advantage of the benefits of privilege separation.
Many tools of malicious security hackers require administrative access to work effectively for them. Keyloggers are one of the major bogeymen of MS Windows security, but they require access to administrator-level components of the system to operate effectively on Unix. This means that a keylogger inserted into the system via some unprivileged user account does not have the access it needs to do its job.
Other security threats, such as rootkits, trojan horses, and botnet clients, also require root access on a Unix system to work. On MS Windows, the lack of rigorous privilege separation short-circuits this defense against malware.
User control and automatic execution
Microsoft Windows is well known for its tendency toward virus and worm infections. This is in large part because of the fact that MS Windows tries too hard to do everything for the user. Arbitrary malware often automatically executes when effectively unrelated tasks are performed. When opening what appears to be a Microsoft Word document, but is, in fact, a cleverly designed malware executable, MS Windows will helpfully redirect the execution of the file from Word to what is actually needed to execute the file.
By contrast, Unix systems do not do this sort of thing by default. It is more normal on Unix systems to execute a program with the file in question as an argument to the program execution. Thus, if you try to execute a cleverly disguised piece of malware pretending to be an OpenOffice.org document using OO.o to do so, the operating system will not just automatically ditch OO.o and execute the file by whatever means seems appropriate. Instead, the word processor will just fail to properly open the file, because it is not the right type of file for that application.
Other examples of unwarranted automatic execution in MS Windows include AutoRun. As detailed in U.S. military compromised by removable media malware, the United States Department of Defense was compromised by malware carried on removable media that was automatically executed every time the media was read by an MS Windows computer. While it is possible to turn off AutoRun functionality, it is not always easy, and that functionality should not be the default anyway. Even worse, Windows Update has been known to surreptitiously reactivate capabilities like AutoRun.
A difference in philosophy
These differences in the design and relative security of Unix and Microsoft OSs illustrate a distinct difference in philosophy between them. Unfortunately, the difference appears to be that where Unix has a philosophy of security built into the fundamental design of the system by default, MS Windows has a philosophy of "Who cares about security?"
MS Windows is not alone, however. Certain variants of Unix-like systems appear to be headed down that road as well. While Linux distributions like Ubuntu seem to run afoul of the common negative correlation between security and popularity just like MS Windows, they still have a ways to go to achieve the same level of blatant disregard for security. Part of the reason for this is the Unix-like foundations of the system.
Sadly, it seems all too likely that gap will be bridged in time.