Sunday, August 29, 2010

Startups@Ease Now Supports 64-bit Windows

I have re-written the code for Startups@Ease and now it supports both 32-bit and 64-bit operating systems using the same executable.
The tool is automatically compatible with Windows XP 32-bit, Vista 32-bit, 7 32-bit, server 2003 32-bit, server 2008 32-bit, Vista 64-bit, 7 64-bit and server 2008 64-bit.
As for Windows XP 64-bit and server 2003 64-bit, you will need to download and install this hotfix before running this tool. The hotfix would allow 32-bit applications to access the 64-bit locations native to the operating system. Without the hotfix, the tool will not function properly.

Friday, August 20, 2010

Startups@Ease has Been Released

I finally launched a freeware tool called Startups@Ease that I have been developing in the past few months. The program is mainly designed to help non-geeks to manage unwanted startups in their computers. When executed, the program searches for unnecessary startups and then displays them as a series of questions and (yes/no) answers to the user. These questions are phrased such a way that non-technically sophisticated users can understand and be able to make a judgment whether they actually need the unnecessary startups or not. The tool does NOT delete or uninstall any of your programs. All of the startup programs that appear in the Q&A wizard can be accessed either through the start menu or from the control panel. In addition, the tool automatically creates backups of any programs it has disabled from startups.

The tool is available here: http://www.startupsatease.com

To use the program, click the begin button as in the image
below:

Saturday, August 7, 2010

Is an Account Lockout Policy Really Worth It

I strongly agree with Jesper Johansson and Steve Riley with their point of view on account lockouts in which they have mentioned in the book that they have published many years ago, Protect Your Windows Network: From Perimeter to Data. Here is a transcript of what they have written in page 344:

The authors consider that account lockout not only provides no positive security value, but actually decreases security. As we showed earlier, only really poor passwords can be guessed successfully. Thus, the real problem if a guessing attack succeeds is really poor passwords not lack of account lockout. Turning on account lockout does not make the passwords any stronger, and a sophisticated attacker will tailor the attack to work around any account lockout settings. Hence the claim that it provides no security value.

Worse than not doing any good, however, is the fact that account lockout is harmful. It can obviously be used by an attacker in a very easy denial-of-service attack to lock out every single account on the system, rendering the system unusable. Now consider if this were to happen to your Web server it would not be much of a "server" any longer. Moreover, it is highly likely that the account lockout settings are tripped accidentally. For example, almost all vulnerability scanners will trip account lockout settings, resulting in entire data centers being disabled. Finally, even if there is a timeout to the lockout, users will generally call the help desk when their account no longer works.
....
The authors then continue to describe the futility of account lockouts from a risk management point of view. Even though, the reasons that they have provided more than 5 years ago are fairly convincing, today there is a far more important reason why you need to disable account lockout across your network. A large amount of malware today perform dictionary attacks to break account passwords. The most notorious among them, is the conficker worm which has affected tens of millions of computer last year and is still a problematic infection today.

Earlier last year, I was called to assist in an emergency downadup outbreak at a financial institute. What was found is that despite only less than 4% of the machines were affected, it was these 4% that caused a major downtime to the whole business and thousands of employees were not able to get any work done because they cannot log on their machines. The reason was very simple, these small percentage of downadup-ridden machines tried to guess the passwords of every other machine across the network. The institute had to disable the account lockout policy
in order for the business to start functioning again and employees getting back to work. Thanks to account lockout, the institute suffered financially more from this harmful policy more then the mere existence of the malware itself.

I greatly advise that the risk management team of every company that has a windows network to revisit the account lockout policy. Instead, I do recommend that failed logon attempts are logged and a warning message such as an email is sent to notify network administrators after a certain amount of failed logons have been attempted.