Following a long running period of playing around with the various security tools and features in Windows, I thought that I'd share some of my findings made over this time. Hopefully, this might help those of us "locked in" to using the Windows family in protecting our machines a little bit better than they are normally. :-)
The things detailed here have been tested and applied on a machine running Windows XP Pro SP2, but should hopefully be supported in all versions of Windows 2000, XP and Vista.

0x01. Who this guide is for:
Most articles in 2600 seem - To my eye - To be written mainly for those lucky enough to be able to understand and use Linux without experiencing serious implosion of the brain. Sadly, some of us are classic victims of vendor lock-in and - Try as we might - Find that the only kind of OS we can efficiently use is one of the Microsoft Windows family of operating systems. This article is primarily aimed at general users of Windows, and concentrates mainly on applying secure practices in Windows XP...But the methods and practices used here should also be adaptable for use in Windows Vista and other operating systems, both by Microsoft and other producers.

This article has been written so that it can be used easily by those without much computer know-how (Such as the less computer-savvy friends of regular readers) and as a result a lot of the wording may appear very simple and newbie-friendly to more experienced readers...So please accept my apologies in advance if this article appears a little too simple or long-winded for your liking! :-)
If You("Experienced user")=True Then
  Goto 0x07 or INT 21h
End If

0x02. Security in Windows - A brief intro:
With the exception of Windows CE and ME, the Windows operating system has been based on NT technology from Windows 2000 onwards. One of the major benefits of this change has been a switch-over from using the FAT filesystem - Which has been in use since 1980CE, and has no support for user accounts and file security - To the NTFS filesystem, which supports user accounts and allows for user-specific access control to individual files and folders.

In short, this means that any user on a Windows 98/ME machine can install programs and make changes to the operating system without needing administrative privileges, whereas users on Windows 2000/XP/Vista computers - Who don't have the administrator privilege - Cannot generally make any changes except from creating and changing files inside their own document folders. In addition, the same security measures also mean that User A cannot read or change User B's files unless User A has administrative privileges, or User B has specifically allowed User A access to those files.

0x03. A hypothetical case-study:
Let's take the Doe family - John and Jane Doe, and their three children; Claire, Mark and David. They bought their home PC from a major computer store about two years ago which came with Windows XP Home edition. John uses the computer for editing sensitive work documents that include private financial and client data. Jane runs a business from home and uses the computer to keep track of business finances, word processing, client management and online banking. The children mainly use the computer for surfing the Internet and using various instant messaging applications, although Claire also manages an ever increasing music library using iTunes, Mark creates and edits music using several studio packages, and David plays just about any half interesting game that can be freely downloaded from the Internet.

When they set up their computer, the Doe family simply plugged it in and turned it on, gave no thought to computer and user management, and created user accounts for everyone using the Windows default settings - Unwittingly giving all five users full administrative privileges, and allowing anyone logged in to the machine to install programs and change any aspect of the operating system.

At this stage, everyone has become extremely annoyed with the computer. Over time it has gradually slowed down and become increasingly unreliable. Their anti-virus programmes (Of which they have several) continually warn of viruses and trojans that keep appearing over and over, and nothing they try seems to get rid of them. They can't seem to figure out how all of these viruses/trojans keep making their way through the firewall and installing themselves onto the computer. In addition, unusual transactions from foreign countries have recently started appearing on Jane's business account with an ever increasing frequency.

0x04. Spotting the security flaws:
Anyone with an eye for computer security will immediately spot several major mistakes in the way that the system has been set up and managed. Giving all users of the computer administrative privileges is a major error in any circumstances - Especially when some of those users are children. As any parent will readily testify, children love playing computer games...And when a certain game has become a craze amongst students at the childs' school, the first thing he or she will do upon coming home is to download and install the game so that they can play it with their friends and compete for the highest score. Very rarely will a child think to run a virus/trojan/malware scan over the game before installing it (They may think that it's safe just because it came from a website) and if the game comes with malware attached - As so many "free" games and applications do - Then it'll be installed along with the game (Remember: The child's account has admin rights) and gain full access to everything on the system.
In this case, a firewall (Or even 1,000 firewalls) would be completely useless in preventing the application from arriving on the computer in question because the initial connection to the download site was made by the user. Although a firewall might warn the user that the application is trying to communicate with the Internet when it's run, many users will allow such communications as a reflex action - Especially if the game (Or whatever application) is known to make use of some kind of online functionality.

Likewise, giving ANY regularly used account administrative rights is an unwise practice for a computer in a home or general office environment as it would allow any potentially malicious code (Say, ActiveX controls in a web page) full reign of the system and all of the data held upon it...And it takes only a momentary lapse in security - Or a single webpage - For malicious code to arrive and execute on the computer in question.
For general computer use, the best practice [In my personal opinion] is for every user of the system to have a restrictive user account that can only make changes to the users own document folders, and to have a single administrator account that is password protected and is only ever used for system maintenance purposes and the installation of known, trusted applications...Similar to the best practice often applied on Linux machines concerning use of the "root" account.

Although this practice would not defeat all forms of malware, it should make it much harder for a malicious application to gain full control of the system and access every file on the machine. In general practice, this means that malware arriving and successfully installing itself under a child's user account can only access and manipulate data in the childs' document folders, and should only be able to monitor whatever that child is doing - As opposed to monitoring every keystroke and mouse click of every user of the machine. Remember that when an application is run, it is run under the same privileges and restrictions as the user who started it...And therefore, an application running under a restricted user account should not be able to make changes to the operating system, or access any other users files.

0x05. A clean, more secure installation:
John Doe (Remember the hypothetical case-study above) has had enough of the constant virus and malware alerts, abysmal machine and Internet performance, and the continual errors that he and his family keep encountering. Enlisting the help and advice of a computer-literate friend (Let's call him Bob), he decides to go for a full format and reinstallation of his system. Under Bobs supervision, he carefully backs-up user files on the machine (Taking Bobs advice to avoid unrecognised EXE, COM, MSI, and VBS files in the children's accounts), unplugs the Ethernet cable from the back of the computer, and reboots the machine with the Windows XP CD-ROM inserted. After rebooting, he performs a full NTFS format of the HDD, and Windows XP begins installing as normal.

After the usual succession of reboots, progress bars, language/network related prompts, setting a very strong password for the "Administrator" account, and on-screen messages of how "superior" Windows XP is, he comes to the Windows XP first-run screen (Or "Out of Box Experience", as Microsoft call it) and proceeds to work through the screens for setting up his computer. Upon arriving at the page where the user enters names for accounts that will use the machine, Bob tells him to stop entering account names as there is a problem with this page: All accounts created here will be given administrative rights by default, and it's very difficult (If not downright impossible) to change them to limited accounts later on. Instead, Bob advises creating a single account called "SuperUser" that can be used to create general user accounts, and for system administration at a later date.

After even more waiting around whilst Windows gets it's first-run act together, John is finally logged in as "SuperUser" and gets a default Windows desktop. Before doing anything else, Bob shows him how to turn on the Windows firewall (My Computer > Network Connections > Right-click the Internet connection > Select "Properties" > Click the "Advanced" tab > Check the box and click "Apply") and set it up with the "Don't allow exceptions" rule. John then reconnects his Ethernet cable, activates Windows over the Internet, and updates his machine using Windows Update. Now his machine has been fully updated with the latest security patches, and the most up-to-date settings for default users have been applied.

After updating Windows with the latest security patches and making a "Clean start" system restore point (Start > Programs > Accessories > System Tools > System Restore) he proceeds to the "User Accounts" control panel to create logons for himself, his wife, and kids. Before doing anything else though, he sets a suitably strong password for the "SuperUser" account so that only authorised users (Himself and Bob in this case) can perform system-wide changes and application installations. After this, he creates new accounts for everyone and ensures that everyone - Himself included - Has a "Restricted" account that will not be able to change anything that would affect the system. Additionally, he turns off the "Fast user switching" feature (User account control panel > Change how users log on and off) to reduce the chance of a malicious application running under a restricted user account managing to "jump" over to the SuperUser account if both are logged in at the same time.

Finally - After reinstalling Windows, activating the Windows firewall, creating restricted accounts for all users, performing fresh installs of security software and firewalls, and restoring backed-up user data - He tests his restricted account by logging on and trying to install an application...Finding to his satisfaction that the install program quits with an "Access denied - User has no administrative privileges" error.

0x06. Dealing with troublesome applications:
A year after reinstalling his system in this way, everyone is still happy with how well it's working. Although the system does slow down every so often thanks to the large number of system services installed (Security software, iTunes, and several cellphone application suites), the number of malware and virus alerts has remained very low - Such alerts often being traced to game install packages downloaded by the children, that would be checked and verified by John first before installation via the SuperUser account if that application was considered safe.

However, there is one problem: David - Having recently found a strong addiction to World of Warcraft (WoW) - Is requesting that his user account be made into an Administrator's account. The reason that he's asking for this is because WoW is frequently updated with new patches and software updates, and although David can run the game fine under a restricted account, the game needs to be run under "SuperUser" every time it is updated (It normally runs under David's account, and thus only has read permissions for the WoW program folder)...And John's busy schedule often means that he can't always be there to update the game as soon as a new patch is applied. Noting that the majority of malware and virus alerts on the system are traced to files stored in David's account, John is rightly against the idea of giving Davids account administrative rights. He consults Bob for advice on how to work around the problem without placing the system at risk of attack from malware or other nasties.

Now Bob knows that every file and folder on an NTFS drive has an Access Control List (Or ACL) attached to it, and it is this list that controls which users can access, create, or change that file. Noting that David is the only family member who uses WoW, he logs in as "SuperUser", opens the command prompt (Start > Run > Type "command.com" and hit [Enter]), changes to the "Program Files" folder (Type "CD \Progra~1" [Enter] - The "Progra~1" is a DOS short-path, and should be valid on WinXP and Vista PCs), and checks the ACL for the World of Warcraft folder by typing "cacls Worldo~1" [Enter]. This shows a list of which users have access to the WoW folder; All users can read it, but only administrators can change the data in there. Typing "cacls /?" will display a brief guide to using the command.

The next step is best done only by experienced computer users: Bob decides to give David full access rights to the World of Warcraft folder, and uses the command "cacls Worldo~1 /T /E /C /G David:F". After verifying the output (Which gave David full read/write/modify/execute rights to the WoW program folder and every file and folder below it), Bob logs out of "SuperUser" and asks David to log in, try running WoW, and to see if the changes to the ACL were successful. David tries some functions that would result in data being changed on the HDD (Performing a WoW update, taking in-game screenshots, and setting up character macros are three such tests that can be performed) and finds that - Unlike before - The in-game screenshots and character macros have been saved to the WoW program folders successfully.
As a precaution, Bob also adds a shortcut to Davids startup folder (Start > Programs > Startup) that fires up the antivirus program and performs a full scan on the WoW folder to make sure that no malware infections in the WoW folder go undetected before WoW itself is run.

Another approach to solving this problem - Useful if WoW (Or whatever application) is accessed by multiple users - Is to create a new restricted user account specifically for that program, give the account read/write or full access to the relevant folder using CACLS, and changing the application shortcuts to make sure that the program is run under the application-specific account (Right-click the shortcut > Select "Properties" > Click the "Advanced" button under the "Shortcut" tab > Select "Run As" or "Run with different credentials") insted of the current user's account. An additional benefit to this approach - Assuming that the "Protect my files, folders and settings" option is checked - Is that anything running under that account (Say, malware that piggy-backs off of a legitimate application) will be denied access to user files or folders by Windows - Although this technique would inhibit legitimate read/write operations to user files if it was applied to a program that uses them, such as Microsoft Word.

Following Bobs simple modification to the WoW folder ACL, David has been able to play and update World of Warcraft himself, without needing John or Bob to log in under the "SuperUser" account...Which has saved David a lot of inconvenience and waiting around, and John no longer has to deal with continual requests and SMS messages asking him to come home and update WoW as soon as he can! :-)

0x07. Windows security and best-practice summary:
Now I can see that this article has run very long...Much longer than I'd initially hoped - Although the "blow by blow" guide and explanations are necessary if the article is to be understood by general computer users, to whom this article is also aimed. For those who have lost all track of what I am saying thanks to the sheer volume of text above, here is a brief "bullet-point" summary of the article:

• Windows 2000, XP and Vista all use the more secure NTFS filesystem by default, and this makes it easier to control which users can do what. If you're still using Windows 98 or ME (Or - Horror of horrors - Windows 95!) with FAT filesystems, consider upgrading your operating system as quickly as possible. This also applies to Windows 2000/XP computers upgraded from Windows 95/98/ME that are still using a FAT filesystem on the hard drive insted of NTFS.
   
• Firewalls may prevent trojans or other malware from sending data (Keylogging info etc) to external servers, but they won't stop viruses or malware from arriving on a machine if a user unknowingly downloaded it in the first place. Most firewalls allow known web browsers (IE and Firefox, to name but a few) to always connect to the Internet, effectively throwing open the door for malicious data to come through if the user opens the connection in the first place.
   
• Viruses, trojans and malware can only run with the same privileges as the current user, at least until they are run under an account with admin rights. Therefore, if the current user account is a restricted one, any malware programs running under it will only be able to change data under the user's own data folders and "Shared documents", and will have a great degree of difficulty installing themselves as a system-wide application or service.
   
• When using Windows 2000, XP or Vista, the best practice is to make all user accounts (I.E: The one that you use to log on to Windows) restricted ones, and only use accounts with Admin privileges for system maintenance. This is especially important where accounts used by children or teenagers are concerned. On the same token, one should always be *very* careful when logging onto an account with administrative rights, and make sure that you don't run anything that is potentially unsafe. Do a cold boot (Shutdown, wait a minute, then power up again) if you consider it necessary.
   
• Windows 2000 and XP users beware: User accounts created using the initial Windows welcome and setup screens are given administrative privileges by default, and it's very hard to change them to restricted accounts later on. Just create a single "SuperUser" account (Or use whatever name ye wish) to get past the setup screens, and create restricted accounts later on. This might not apply to Vista users, but ye should double-check this by looking carefully at the user accounts control panel all the same.
   
• If a program needs to update itself on a regular basis by writing updated files to it's own folders (Or otherwise changing itself), consider modifying the file/folder ACL using the CACLS command, insted of automatically giving the user of that program administrative rights to the whole system.
   
• If several users all make use of a regularly updated program, consider creating a restricted user account especially for that program and configure access rights and restrictions for that account, ensuring that the account itself can only change the program (And directly associated files) that it has been created for. Remember to set the program to always run under that special account, instead of having it run as the current user.

Shouts to:

• Whoever came up with the User/Group/Other permission system in Linux, from which the initial principles in this article are derived.
• A family from Guildford - The inspiration for the case-study above, and indeed the article itself. :-)