Going green and staying secure

It's all about the details

In this developerWorks article, understand the benefits and risks of telecommuting. Learn how to create secure mashup applications for business users, and be sure you know the important questions to ask service providers to help ensure a secure and reliable environment.


Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson is a systems architect and engineer. Her areas of interest include enterprise-wide systems, middleware technologies, database technologies, cloud computing, threshold policies, industries, network management, security, RFID technologies, presentation management, and project management.

developerWorks Contributing author

30 June 2009

Also available in Chinese Japanese


In the effort to "go green," companies are working with new strategies in their businesses. Some are working to reduce traffic and office space energy usage by encouraging telecommuting. Others are looking to reduce system resource requirements by using "mashup" applications or outsourced hosting. As resources spread further away from the central control of the enterprise, risk containment becomes more challenging. Security procedures become more vital, and each component needs a little more scrutiny.

In this article we will look at some of the key players in this greener environment and specific areas of risk that should be addressed. We'll examine telecommuting, mashup applications, and application hosting.


Telecommuting is becoming a popular response to office expenses. Employees benefit from telecommuting by losing the daily drive, gaining some flexibility in their schedule, and having literally all of the comforts of home. There are green benefits to telecommuting as well. It reduces road traffic and associated issues. It reduces the industrial sprawl office spaces and the associated resources of heating, cooling, and cleaning up after office staff.

However, telecommuting enhances certain security issues by placing workers outside of the enterprise environment. Suddenly, data that was secure within a locked and guarded complex is out in the uncontrolled environment of people's homes. This doesn't mean that telecommuting is dangerous and to be avoided. It simply means that employees who telecommute need to be aware of the dangers and provided with the policies and procedures to work safely from the outside.

Most enterprises are already comfortable with using VPN connections with their users to get to back-end data. However, telecommuters have a greater need for different collaboration tools, such as instant messaging and remote meeting facilities. Are the tools that your employees are using secured and private to your environment, or are they using public tools that communicate openly across the Internet?

You can provide secured instant messaging facilities with commercial tools, such as IBM Lotus® Sametime, or open source tools such as Jabber. Other collaborative tools, such as wikis and virtual meeting facilities, may also be needed to help remote workers communicate effectively. You may choose to provide these in-house through your VPN or to outsource them, but you should examine the security implications and make sure that you are not inadvertently broadcasting confidential information.

Another weak link in the telecommuting chain can be the users' laptops. Do you have policies about the use of power-on passwords? What about rules of what data users may store on their laptop? Do your applications leave unsecured caches of confidential data on a local machine? Have you provided options for users to encrypt data on their local systems? Some commercial e-mail systems, such as Lotus Notes, provide means for automatically encrypting local e-mail. Many others work with external systems, such as the open-source GPG, to encrypt e-mail. There are many strategies, both commercial and open source, for providing encrypted drive space.

The key is to have clear policies and guidance for telecommuters about securing confidential data. They should clearly understand their role in the security chain and be provided with support, in tools and education.

Mashup security risks

Mashups can be a great resource-saving technique to build more robust applications using available resource rather than trying to construct your own. Mashups integrate information from multiple sources, such as Web sites, enterprise databases, or e-mails, to create one unified view. They are often written using Ajax, integrating data from internal and external sources. The developer can mash information together with, say, Google Maps, to support routing and customer analysis applications, helping non-technical users gain insight into complex situations.

However, mashups come with their own kinds of risk. Do you know the source of the data that you are using? Is it accurate? Is it legal? What happens when you invoke callback functions defined by other applications? Are you inadvertently sharing confidential data with third parties? This is not intended to scare you away from mashup applications, but these issues should be considered and tested when developing them for the enterprise.

For example, developers found problems with MySpace APIs that had been deprecated instead of deleted. Mashup applications that used these APIs were vulnerable to hackers who exploited the deprecated APIs.

Secure mashups

So, how do you keep mashups secure? Keep an eye on the news about exploits with resources that you use. Exploits of facilities like Google Maps are generally made public when they are discovered. Find the reporting resources for exploits and keep an eye on them. Sites such as Security Focus (see Resources) collect information on a number of exploits and vulnerabilities and are worth watching.

An emerging approach to protecting against vulnerabilities is smarter tools which have awareness of dangerous resources and techniques. Research will point you to several approaches, but here we will look at IBM Research's WebSphere® sMash, a development and execution platform for building dynamic Web applications. It is based on the Project Zero incubation project and is available as a free download for limited deployment across multiple platforms.

WebSphere sMash uses Web 2.0 technologies, combining PHP scripting, REST, and Dojo in an integrated runtime and tooling package. Its PHP 5.2 or later runtime is implemented in Java™. PHP programmers can make use of Java libraries, while Java programmers get access to PHP applications and libraries that they can mash up with Java and Groovy code.

WebSphere sMash helps protect against malicious code by implementing system-level authentication and authorization. Using a facility called Active Content Filtering (ACF), application developers define security rules that determine which resources are protected, by what means they are protected, and what users and groups are allowed to access those resources. Specifically, ACF is designed to help protect against Cross Site Request Forgery (CSRF) and Cross-Site Scripting (XSS). In CSRF attacks, unauthorized commands are transmitted from a user that the Web site trusts. XSS exploits the trust a user has for a Web application. For example, a user clicks on a link to open a Web application containing malicious JavaScript to hijack that user's session.

As mashups become more popular, we will likely see a number of other strategies and tools to make them more secure.

Some examples of existing mashup applications include Jibes' application to read a customer Excel sheet and integrate it with an ERP system; and ZSL's Enterprise 2.0 SocNet to promote collaboration, knowledge sharing, and interaction among employees. ZSL has extended this tool as service-oriented cloud computing services, now available as Collaboration as a Service (CaaS), also known as Collaboration in Cloud (CiC).

You should set your own security criteria for using these and other mashup resources.


Finally we talk a little about outsourcing. You can save a great deal of energy and resource by remote hosting of systems and applications. However, you are again placing resources outside of the "safe zone" of your enterprise. How do you protect yourself against security and downtime issues when working with an outside company? You ask the right questions and get solid agreements up front.

It's what you know

Any outsourcing should come with a clear and detailed Service Level Agreement (SLA). An SLA is a formal contract between a service provider and a client, guaranteeing quantifiable network performance at defined levels. A service provider may be an internal IT organization, an application service provider (ASP), a network service provider (NSP), an Internet service provider (ISP), a managed service provider (MSP), or any other type of service provider.

An SLA can be either very general or extremely detailed and generally includes the steps that should be taken by the service provider and the client in the event of failure. The service provider guarantees that the services it provides will be available for a certain percentage of time (for example, 99.9%).

The provider can also do four things: First, he can impose limits on maximum and average response Web application server times. Second, he can impose the maximum times the content can be accessed or the resources can be shared. Third, he can impose limits on the maximum number of users that can be served simultaneously. Fourth, he can notify the client of SLA downtime or before changes to network interfaces take place.

If the provider fails to meet defined performance levels over the course of specified time periods, the client obtains rights and remedies. These rights, remedies, and exceptions vary from one SLA to another. The client also may agree to accept specified exceptions to the general terms of the agreement.

Ask questions

The problem is that the provider may not do what you, as a developer or deployer, want him or her to do. You should make informed decisions about where he will host and what his vulnerabilities will be. You may choose to take on risk or responsibility for some of these things that the provider does not. You as the developer should be aware of the risks and how you can cover yourself for what your provider does not do, such as applying security controls to mitigate risks. Ask questions. If the provider does not give you the answers you want, make the preparations to provide security for your mashup and other types of Web applications.

The following table lists some sample questions you should ask your service provider.

Table 1. Sample questions
StatefulnessDoes the server respond correctly in the subsequent states? How complex is the hierarchy of states to accomplish a task?
Access controlCan an unauthorized user successfully access a control that only the administrators are authorized to use?
Response timeIs the application service taking too long to respond (for example, more than 10 seconds)? Is slow response time due to excessive packet loss?
Time-outWhat happens when the service times out? Will it stall the system? Will it rollback to a previous state?
VersioningCan a new build break an existing application's functions?
Resource sharingWhat happens when the resources become idle? Can they be shared at any given time?

After you get the answers, determine which security controls the provider cannot provide to mitigate the high and medium risks to more acceptable levels. The costs must not exceed the benefits of a security control. If the costs are high, you may need to change the security control for less money. After you apply security controls, you may have remaining risks, also known as residual risks. You may need to change security controls or update the application to reduce the number of residual high risks.

Protecting virtualized environments

Security professionals and developers should be concerned how virtualized environments running Web applications will function and deliver on the SLAs that were enforced before moving to virtualization. How will the virtual machines on the telecommuter's computer and on the back-end systems get protected from malicious behavior that may have impact on guaranteed uptime availability?

Consider programs such as VMware's VMSafe to better integrate security into virtualized environments. IBM is a member of this program, and like many security firms, it plans to use or has used VMware APIs to tap into the hypervisor and produce products designed to harden it and improve uptime availability.

VMSafe is a set of APIs that permit to attain a level of visibility into VMware's hypervisor. The APIs let security vendors develop tools to lock viruses, monitor network traffic, build firewalls to integrate with virtual machines, and even patch management and perform vulnerability assessments. VMSafe overcomes some of the problems with virtual shields running as virtual appliances, such as partial integration with an existing security monitoring system. IBM researchers are developing new security technologies to protect the hypervisor and monitor communications between virtual environments.


Companies are under a lot of pressure to reduce resources, both for business and environmental reasons. Don't increase your risk by overlooking the implementation details. Make sure that your telecommuters have a clear understanding of their security responsibilities and provide them with, or guide them to, the necessary tools to handle confidential information securely. Be aware of the vulnerabilities in mashup applications, and look for emerging answers to help protect you from unauthorized data and malicious code. Finally, be smart when looking for outsourced hosting and application providers. Ask the right questions, and get a solid agreement that protects your interests and those of your customers.

Attention to the details will help you move confidently, and relatively safely, into the next wave of how we use technology to do business.



Get products and technologies


developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Web development on developerWorks

Zone=Web development
ArticleTitle=Going green and staying secure