Shaheen N Abdul Jabbar

Archive for October, 2009

Where do you put vulnerability assessment (VA) scanners in a very distributed network? Consider a scenario where a company has presence in North America, Europe and South Asia. As part of its annual penetration testing environment, the company wants to conduct vulnerability assessment at all its demilitarized zones (DMZ). North America may have DMZs in Delaware and Texas, Europe may have only one DMZ in London while South Asia may have in Bangalore, Calcutta and Hyderabad.

There are some architects who believe that the VA scanners should be caged within each DMZ while others who think a VA scanner can be placed anywhere other than the untrusted zone and a firewall rule that allows only the VA scanner access all of the DMZs. While there are benefits for both extremes, we need to prepare a strategy balancing cost and benefits. The time constraint does not permit to conduct the VA scan in phases (DMZ by DMZ).

There are four options:

1. A Scanner  Per DMZ

Here a scanner is placed in each of the DMZ of the corporate. From a security risk perspective, this is the best strategy. However, is it cost effective? It may not be.

2. A Scanner in one DMZ Per Site

How about placing a scanner at one of the DMZ for each site? This will reduce the cost the scanner. However firewalls made need to be open between neighbouring DMZs so that scanner have access to all the DMZ in a site. It’s fine as long as the rest of the DMZs trust the DMZ where the scanner is located. There is always the risk of a hacker compromising the scanner and getting access to neighbouring DMZ. However there is no need to open traffic to the trusted zones.

3. A Scanner in Trusted Zone Per Site

Another way is to put the scanner in the trusted zone of each site and open the firewall for the scanner to each DMZ in the site. A hacker need to compromise the DMZ and need access to the trusted zone before messing up with the scanner. It’s as good as compromising other systems in the trusted zone. Here is no need to open traffic between the DMZs.

4. A Scanner in the Corporate Network Cloud

What about having just one scanner in the corporate network cloud and it accessing all of the DMZs? If the sites are located very far, there could be latency issues as well as issues with the performance of the scanner itself. If the scanner gets compromised, then a hacker may be able to get access to all of the DMZs but not beyond that.

Bruce Schneier

by Bruce Schneier

In computer security, a lot of effort is spent on the authentication problem.  Whether it’s passwords, secure tokens, secret questions, image mnemonics, or something else, engineers are continually coming up with more complicated — and hopefully more secure — ways for you to prove you are who you say you are over the Internet.

This is important stuff, as anyone with an online bank account or remote corporate network knows.  But a lot less thought and work have gone into the other end of the problem: how do you tell the system on the other end of the line that you’re no longer there?  How do you unauthenticate yourself?

My home computer requires me to log out or turn my computer off when I want to unauthenticate.  This works for me because I know enough to do it, but lots of people just leave their computer on and running when they walk away.  As a result, many office computers are left logged in when people go to lunch, or when they go home for the night.  This, obviously, is a security vulnerability.

The most common way to combat this is by having the system time out.  I could have my computer log me out automatically after a certain period of inactivity – five minutes, for example.  Getting it right requires some fine tuning, though.  Log the person out too quickly, and he gets annoyed; wait too long before logging him out, and the system could be vulnerable during that time.  My corporate e-mail server logs me out after 10 minutes or so, and I regularly get annoyed at my corporate e-mail system.

Some systems have experimented with a token: a USB authentication token that has to be plugged in for the computer to operate, or an RFID token that logs people out automatically when the token moves more than a certain distance from the computer.  Of course, people will be prone to just leave the token plugged in to their computer all the time; but if you attach it to their car keys or the badge they have to wear at all times when walking around the office, the risk is minimized.

That’s expensive, though.  A research project used a Bluetooth device, like a cellphone, and measured its proximity to a computer.  The system could be programmed to lock the computer if the Bluetooth device moved out of range.

Some systems log people out after every transaction.  This wouldn’t work for computers, but it can work for ATMs.  The machine spits my card out before it gives me my cash, or just requires a card swipe, and makes sure I take it out of the machine.  If I want to perform another transaction, I have to reinsert my card and enter my PIN a second time.

There’s a physical analogue that everyone can explain: door locks.  Does your door lock behind you when you close the door, or does it remain unlocked until you lock it?  The first instance is a system that automatically logs you out, and the second requires you to log out manually.  Both types of locks are sold and used, and which one you choose depends on both how you use the door and who you expect to try to break in.

Designing systems for usability is hard, especially when security is involved.  Almost by definition, making something secure makes it less usable. Choosing an unauthentication method depends a lot on how the system is used as well as the threat model.  You have to balance increasing security with pissing the users off, and getting that balance right takes time and testing, and is much more an art than a science.

Automatic logout:
http://www.schneier.com/blog/archives/2009/06/protecting_agai.html

Proximity logout:
http://www.matthew.ath.cx/projects/bluemon/

This essay originally appeared on ThreatPost.
http://threatpost.com/blogs/difficulty-un-authentication-128