Who sets the audit standards?

I found this article on the RSA Security Blog. It is the first of three-part series, so it is mainly focused on the background of auditing and accounting. It's an interesting read, I'm sure the next two parts will be equally informative.

Who Sets the Audit Standards? Part 1 of 3

Security Audit Time

Today's the day. We're having an external security auditor come in to take a look at one the networks I work with. I'm not expecting any earth-shattering revelations, but, having dealt with this firm before, they usually come back with some interesting suggestions. If that is the case today, I will share the love.

Book Review - Protect Your Windows Network: From Perimeter to Data

This is my first book review in what I hope will be a series of reviews of security-relevant publications. I aim to write at least one of these per month.

Protect Your Windows Network: From Perimeter to Data
by Jesper M. Johansson and Steve Riley
Addison-Wesley Microsoft Technology Series (2005)

As the title should tell you, this is an unabashedly Windows-oriented book. It's no surprise, considering the authors are both employees of Microsoft. Jesper Johansson is the Senior Program Manager for Security Policy, and Steve Riley is the Senior Program Manager in the Security Business and Technology unit. Both authors are extremely knowledgeable, and participate in speaking engagements around the world on a regular basis.

Microsoft-centric view aside, I deal primarily with Windows-based networks, so I found this book to be extremely informative in my security continuing education. The authors attempt to cover a great deal of ground, so by necessity, some areas are covered in more depth than others. The areas covered are divided into 6 parts: "Introduction and Fundamentals," "Policies, Procedures, and User Awareness," "Physical and Perimeter Security: The First Line of Defense," Protecting Your Network Inside the Perimeter," "Protecting Hosts," and "Protecting Applications."

The book is filled with practical, common sense analysis of security, both with respect to genuinely securing systems, and avoiding practices of "Security Theater." Each chapter ends with a section entitled "What You Should Do Today," reinforcing the action items suggested throughout the chapter. The book also includes a CD containing a few helpful tools. These include a password generator, a HOSTS file that blocks known spyware sites, and a script to revoke SQL Server PUBLIC permissions.

The writing style is at times humorous, and very down-to-earth. This book is valuable both as a casual read, and a comprehensive reference for securing networks. I highly recommend it to anyone in the Information Security field, as well as anyone looking for a place to start educating themselves about network security.

Password Policies

Do you have a password policy for your organization? You probably should. I have read a lot about password policies in recent weeks, and there seems to be some controversy about the best approach to take. Here's my method for the madness. Keep in mind that this is just the best I have been able to come up with so far. As Bill Gates recently mentioned, passwords may be on the way out. Barring the premature demise of the password, these recommendations are subject to change:

Password Complexity - I use Group Policy to enforce complexity requirements, which by Microsoft's standards is to include 3 out of the 4 possible types of characters (lowercase letters, capital letters, numbers, and symbols).

Password length - Again, a Group Policy setting. I am currently allowing a minimum of 8 characters. The longer the password, the harder it is to crack. One other detail: all Windows server operating systems, by default, generate LM hashes for all passwords 14 characters or shorter. LM hashes are relatively weak, and should be disabled (another Group Policy setting) if possible. Another easy way to avoid LM hashes is to use a password of 15 characters or more. I couldn't quite get that one approved, but I tried.

Account lockout settings - This is a tricky one. I have heard arguments going both ways on this one, but most accounts would consider this to be Security Theater. If you enable account lockout policies, you are most likely attempting to avoid having a malicious individual from attempting to "guess," or bruteforce, an account password. On the surface, it sounds like configuring that account to be locked out after a handful of failed attempts would be a good idea. There are two problems with that approach. The first is an administrative issue. As soon as you enable that lockout feature, you will have users calling you (or your helpdesk) complaining that they have locked out their account because they forgot they had CAPS lock on or some similar issue. Secondly, it would seem trivially simple for a malicious user to effectively cause a denial-of-service attack by typing in the wrong password to an account multiple times in order to lock it out. Imagine you enabled this feature throughout your domain, and someone managed to lock out a service account, or all the domain or enterprise admin accounts! Sounds kind of risky to me.

Best practices - While all of these options I have mentioned have involved technical controls, meaning you are using settings in Active Directory to mandate certain password conditions, there are other steps that you should take that are not always as simple as a setting in Group Policy. For instance, tell your users to avoid using dictionary words in their passwords. Even with complex passwords of sufficient length, dictionary attacks can be fairly effective. Another idea is not necessarily to avoid those dictionary words, but to use more than one. I think the idea of a passphrase instead of a password seems like a pretty effective technique. For instance, the passphrase "My dog's name is Max" is an extremely strong password. It has capital and lowercase letters, it has special characters, it is 20 characters long, and it is extremely easy to remember (provided you actually have a dog, and have named him accordingly). Easy to remember is a good approach for your users, so you won't have to deal with passwords written on a Post-It note under their keyboard.

Security Live CDs

In case you've never used them, Live CDs are a useful tool for many reasons. They can be used to evaluate operating systems, such as a Linux distribution. They also serve as an interesting tool for those in the security field. There are Live CDs for penetration testing, forensic analysis, and other security testing.

Darknet has posted a list of the 10 Best Security Live CD Distros. I have personal experience with a few of these, including Auditor and Helix. I intend to check out the rest. I suggest you do the same.

Anyone have any experience with these Live CDs that they would like to share?

NORAD orders Web deletion of transcript

This seems somewhat foolish. For some reason, the Defense Department thought that the transcript of a public hearing should be pulled from a government website. The speculation is that this transcript was deemed a security risk due to the fact that it might have revealed sensitive information. Later in the article, it is mentioned that the article might have been pulled due to the criticism of the government, as opposed to an attempt to hide a security risk. Oh, that makes me feel so much better.

Isn't it better to have an open forum where vulnerabilities such as this can be brought to light? If we pretend there's no problem, how can a solution be found? This applies as much to Homeland Security as it does to application security. I'm all for responsible disclosure on the part of vulnerability researchers, but if an application vendor is not addressing the problem in a timely manner, how is this serving their customers?

Microsoft Security Bulletin Advance Notification

It's that time again...

On Tuesday, March 14th, Microsoft will be releasing one "Important" security update for Windows, one "Critical" security update for Office, an updated Malicious Software Removal Tool, and one non-security High-Priority update.

As usual, any Critical updates are highly encouraged to be installed as soon as possible, within reason. What do I mean by "within reason?" That depends on who you are.

For home users, I would suggest waiting a few days to see if there are any reports of major issues. Of course, if you consider yourself a "power user," you can probably take care of yourself, and don't need my advice on patching.

If you are a small to medium sized business (or the IT staff of one), try to find a few non-mission critical machines to get the updates installed on as quickly as possible, and monitor the results. Then, wait a day or two to see if there is any "buzz" about potential issues. If there is not, patch away, keeping an eye out for potential issues that you may be the first to experience.

If you are a large business, you probably already have detailed patching procedures in place, so you don't need me to tell you what to do.

Personally, with the decreasing window between a vulnerability being announced and an exploit being released, I start to feel very nervous if I don't have most of my critical machines patched within a week of Microsoft's release date.

Check out Microsoft's Advance Notification here.

-JB

P.S. - For small and medium businesses that are not using a patch management product, a great one for the money (since it's FREE) is Microsoft's Windows Server Update Services (WSUS). I will go into more detail on this one, as well as other patch management options, in a future post.

Running as Limited User - the Easy Way

One of the prime examples of a best practice that is often ignored is the principle of least privilege. Sure, everyone knows that the temp working in Customer Service shouldn't have access to the Finance Department's file share, but beyond simple file permissions, many users are allowed to run as a local administrator on their systems. In general, this is a very bad idea, not just because of the damage that can be caused by the user, but because a large majority of spyware and adware infections could be prevented if the user didn't have admin access to the system at the time of the infection attempt.

While having all users operate in a limited account at all times is the ideal, unfortunately it is not the reality for many companies. There are many applications (Quickbooks, for one), that are not able to function when running as a limited user. Not to knock Quickbooks' design team, because I'm not a software engineer, but in general, this inability to run as a limited user is the result of poor software design. And I don't mean to single them out, because there are many products that have this problem. Sometimes there are workarounds that will allow the application to run in spite of the limited privileges, but other times that is not possible.

Mark Russinovich, over on his blog, has put forth another interesting option that deserves consideration. On a system that cannot be operated using a limited user account, Mark proposes using a limited account for applications that are prone to compromise, such as web browsers and email clients.

-JB

Security Theater Examples

While I intend for this blog to include more than just issues related to security theater, in honor of the title, I want to mention a few examples of security practices that are more image than substance.

Security through obscurity
While there is some value to the concept "if attackers can't see me, they won't know I'm there to be attacked," it is misleading to think that any method used to hide a system, or traffic, or whatever else you are trying to hide, will provide any real protection. Take disabling the SSID broadcast in a wireless network, for example. While this may prevent some novices from finding you, any war driver who spends 15 minutes of their time reading up on wireless networks will be able to get that information using simple utilities.

I have a firewall, so I'm protected
Don't get me wrong, firewalls are pretty much essential in most networks (actually, I can't think of any exceptions at the moment, but I try to avoid generalizations). The misconception is that the perimeter firewall is the single device needed to protect your network. There are a lot of attack vectors out there, and not all of them involve Internet traffic coming into your network. Heck, not all of them even originate outside of your network. What about the user that brings in a laptop loaded with all kinds of viruses, spyware, and P2P applications, and attaches it to your network? Obviously, there are other methods of protection, including antivirus/antispyware software, IDS/IPS, email security products, network and remote access quarantine products, patch management, etc. I intend to go into greater depth on each of these options soon.

[Insert Product Here] will solve all our problems
Not to mislead you with the products I mentioned in the last category, most methods used to mitigate risk should start as a policy, not necessarily a product. Certainly, protection may be provided by a new security product, but only if it is implemented in a way that is consistent with the overall security posture of an organization. If you expect to just drop a security appliance onto your network and be instantly more secure, you will probably be disappointed.

The OSI model only has 7 layers
People who deal with security often focus on securing only the first 7 layers of the OSI model. They tend to forget about the 8th layer - people. If you aren't educating your users, and taking their actions into account when designing your security solutions, you are destined for failure. Also, expecting your systems to "catch" all user-created problems is underestimating your users. They are notorious for (intentionally or unintentionally) finding ways around your carefully crafted controls. Whether their intent is malicious, such as finding a way to steal sensitive data, or they are merely trying to open that funny email attachment that a "friend" sent them, the actions of users cannot always be anticipated. While you can design controls to catch the malicious users, you should also focus on educating the more "innocent" offenders.

That should do it for now. There are many more examples of Security Theater, so this may become a regular series of articles.

-JB

Welcome to the Security Theater of the Absurd

Welcome! As an experienced network engineer who began specializing in the security field a while back, it has become apparent that there is often a big disparity between "Security Theater" (a term coined by Bruce Schneier in his book Beyond Fear) and what I'm going to call "Security Reality." I intend to highlight both sides of the coin on this blog, and hopefully the contrast between the two should be both educational and informative.

-JB