Shaheen N Abdul Jabbar

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

With all the bells and whistles from SaaS providers, should we adopt SaaS as a Strategy for our software application needs?

In my previous blog, I pointed out the difference between ASP and SaaS. However, it would help to step back a little and give some background. SaaS is a delivery model in which a commercial software vendor builds the software application, host it at an environment that it comfortable with and expose its services to its customers through web-based interfaces. The interface could be browser based or through web-services.

SaaS is one of the three types of cloud computing services available in the market today. Platform-as-a-Service (PaaS) and Infrastructure-as-a-Service (IaaS) being the others.

Examples of SaaS include Salesforce.com CRM and Google Apps. http://www.saas-showplace.com gives a list of SaaS providers.

Unlike Application Service Provider (ASP)s, SaaS accommodates multiple tenants. The exposed services are common to all its users and is centrally managed, maintained and supported by the provider. Since the service is exposed through the web, it can be utilized by anyone across the globe. Once a user signs up with the provider, all services are available immediately and there is no wait for customization. An amateur user goes through the same training and orientation as an advanced user since the exposed service is the common to all type of users. The user is charged on a as-use basis instead of a fixed monthly charge.

Since the solution is centrally managed, the service level agreements (SLA) would be common to all and may not be flexible at all. Except for the data or information of the user, everything else belongs to the provider. So is the performance of the application too. User data or information is at a location of provider’s discretion and at their mercy. Since the software is built for SaaS model on the web, it may not be available to purchase from a retailer. This prevents the user to independently try out the software or host the software application elsewhere.

Since the software application is completely accessed over the web, it is also exposed to the threats that any other service on the web is exposed. Malicious code attacks and denial of service attacks are some to name.

User need to be concerned about the confidentiality and integrity of data or information that is passed on to the provider. This includes intellectual and confidential information. Sometimes part of the provider operation may be outsourced to another provider that the user may not be aware of. The provider need to ensure that user data or information should neither be accessed by unauthorized personnel nor by other users of the service.

User need to ensure that the data or information that they pass on to the provider is hosted in a compliant jurisdiction. Data originating from certain countries like China cannot be hosted in another country due to legal restrictions. Certain types of data, for example Personal Identifiable Information (PII), are subject to local regulations which prevent it to be hosted in another country. A good example is Canadian Privacy Regulation (PIPEDA). There are others subject to regulations such as HIPAA and GLBA.

User should ensure that there are proper security controls in place at the provider that is compliant with security policies and standards of the user. User should be given the right to audit and monitor the provider periodically.

There should be proper understanding of reporting any issues and their ownership of issues in case of a security incident. User should also consider what happens if the contract with the provider is terminated. Providers may not be able to give back the data in the same model that is expected by the user.

Before signing up with a provider, user may need to verify how resilient the provider is, their security posture, customer support, track record and reputation.

So can we sign up for SaaS? It all depends on the classification and business criticality of data or information that will be passed on to the SaaS provider. If we are subject to laws and regulations that prevent data leaving from our perimeter, then SaaS is not a solution. However, there are other types of information that can very well be managed by a SaaS provider and should be passed on to them so that we can reduce our operational cost.