Shaheen N Abdul Jabbar

Archive for the ‘Architecture’ Category

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.

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.

With cloud computing being the buzz word in the IT industry and SaaS being the early adopted model of the cloud computing world, people keep on asking what’s the difference between SaaS and ASP.

Saas is Software-as-a- Service and ASP is Application Service Provider.

Though some in the industry say SaaS is a subset of ASP and is one of the ASP delivery model, others say they are completely different.

Here is what I think from a user or customer’s perspective -

ASP

1. Single-tenant approach
2. Customized solution for each user
3. User has authority on the solution hosted by the vendor and can demand the type of service required.
4. User data could be hosted at any jurisdiction per user’s requirement
5. SLA is unique to user
6. Cost is based on user’s unique needs
7. Monthly subscription on an as-used basis
8. Borrowed (third party) software used
9. User has the luxury to pull out of the ASP, buy the software from a third party retailer and host it somewhere else
10. Once signed up, the vendor may take long time to customize
11. Each user requires customized training and orientation which makes its usability cumbersome
12. Solution need not be internet based

SaaS

1. Multi-tenant approach
2. Same features and functionality to all users
3. Solution is centrally managed, maintained and supported by provider. User is at the mercy of the provider and cannot demand any individual changes
4. User data is hosted at a jurisdiction that the provider is comfortable
5. Service Level Agreements (SLA) common to all
6. Comparatively minimized cost than ASP
7. Monthly subscription on an as-used basis
8. Custom built software that is not available anywhere else is used
9. User is unable to buy the software from a third party retailer and is limited to the SaaS vendor always
10. Once signed up, the service is available immediately
11. All users go through the same training and orientation making it easy to use
12. Solution is always internet based

With all these sweet things that we hear about SaaS, should we look forward for “SaaS as a Strategy”? Not necessarily it depends on the type of application and the jurisdiction of the origin of data.