Malware Attacking SCADA Systems - from USB Device

A really interesting article that I think we should all be aware of -Microsoft Investigating Windows Zero Day Trojan brings to light an even bigger threat to our overall ecosystem and economy from Cyber Terrorism.

For those that may not be aware of the importance of SCADA systems - you may want to recall the brown out a few years ago that took out the electrical grid from Ohio to New York. Many do not know that it was believed to be caused by a virus that was infecting the reporting system. These systems power nuclear plants, electrical grids, oil pipelines, etc.

This article brings to light very clearly that as a Global economy we have to think about the technologies we put in place and their impact. These types of viruses should not only be a concern for USB devices on SCADA systems but also those embarking on their Journey into client virtualization.

Why worry? Virtualization exponentially increases the threat of security risks to companies and our underlying infrastructure. How? VM sprawl and undetected/unregistered virtual applications that have security holes in their virtual operating systems. While SCADA systems are pretty locked down - if a USB device can communicate with the rootkit of the underlying operating system what about virtual operating systems that can go undetected by traditional inventory programs?

For VMs in the wild - they may not have inventory installed or be accessible on the client systems (not like VSphere in the datacenter) when the VMs are offline. Application virtualization poses an even greater threat here.

Typically inventory searches the registry for key elements that identify there is an application installed and Patch Management tools will apply the patch to the underlying OS. But if the OS is virtual unless it is specifically integrated or programmed to do so - the traditional tools will not see the virtual OS or be able to patch it. If the person using the virtual application has administrative rights to their machine - then the virus can continue to exploit the vulnerability within the virtual operating system and pass through to the underlying PC.

What are ways around this?

1. Lock down the PC - disallow administrative rights. This is hard to do of course for some organizations as many legacy applications still require administrative rights to function.
   
   
2. Register Virtual Application - ensure the virtual application allows you to register it with the underlying Operating system (For example with ThinApp they use ThinReg). Do not use technology from vendors that do not provide some mechanism for alerting the physical system that the application is there.
   
   
3. Ask you Inventory & Patch Management Vendors if they support that application type - some vendors do have integration with traditional tools such as SCCM, or BMC. Tools like BMC Bladelogic for Clients (Marimba) have the ability to provide inventory for applications deployed through their system. This is useful to at least provide base inventory when there is no clear out of the box integration. I would also recommend requesting support from the Systems Management Patch Vendors to provide some type of hook into these solutions to quickly patch them without repackaging. This last part is one of the biggest inhibitors to broad scale adoption of application virtualization beyond just a handful of applications.
   
   
4. Create Process with Service Level Agreements to patch the Virtual OS - Many companies I have worked with over the years have set SLAs to quickly apply patches to their many computers out there. How do they do it across dozens of virtual applications? It depends on the architecture of the virtual application. Make sure you work with your Vendors Services team to create a Disaster Recovery plan for Zero Day viruses such as this to ensure the Virtual OS receive the same patches on a monthly basis as part of your overall patch process.
   
   
5. Only run virtual applications in User Mode - When possible eliminate the administrative rights. Most of the SCADA systems are pretty locked down. What makes the USB trojan even more worrisome. Companies that are choosing to leverage application virtualization should take their overall imaging and rights management process to the next level. Now that you have technology that can lock down access rights - use it.
   

Some virtualization vendors will claim anti-injection etc. Which is great but you are only as strong as your weakest link. It is important to really think through the security ramifications prior to deploying virtualization technology (Virtual Machines or Applications) on clients. Make sure they fit into your existing SLAs and don't put your company at risk.

Regards,
Jeanne Morain
jmorain@yahoo.com

Multiple Versions if IE Not Supported - What it means for Application Virtualization

Lack of Support for Running Multiple IEs Impact on Application Virtualization

Background
One of the benefits that Application Virtualization provides is enabling customers to migrate legacy applications across operating systems without impacting the end user or incurring significant costs in testing and rewriting the application to be compatible with the new version of the OS. This has become particularly important for those that believe XP Mode (lack of interaction between applications on the new OS) will not be sufficient enough to enable Win 7 Migrations (as many skipped moving to Vista).

Microsoft has stated they will not support multiple versions of Internet Explorer on the Same OS - particularly when used with application virtualization. - http://support.microsoft.com/kb/2020599/

What does that Mean for Application Virtualization?
The actual magnitude of impact really depends on the architecture that the solution uses. There are several different architectural approaches to application virtualization. Depending on the approach - this could be a significant risk for customers beyond the intentional virtualization of Internet Explorer.

There are essentially 4 types of architectures that exist currently in this market.

1) File redirection - The files are redirected to a different portion of the OS but are still technically installed on the machine.

2) Agent Based Virtualization (Agent installed in OS) - agent is installed in the Operating System and redirects calls to isolated applications. The agent needs to be sequenced etc to determine how much memory consumption and other system resources to allocate based on precedence.

3) Agentless Virtualization - The file system and code to run the application is embedded within the virtual application. The Virtual Operating System is contained within the Application to provide everything the application needs to run independant of a full OS (registry keys, specific components) and communicates with underlying OS.

4) Virtual Client/Agent Hybrid - The fourth architecture is based off of a virtual client that leverages some form of file system and manages all the components independently. It combines the approach of having the agent (without installing it in the OS) and the virtual OS.

How does this translate to impacting product support?
For most application virtualization solutions it literally means that only 1 copy (ideally the one that is shipped as part of the OS) is supported. We all know this is not realistic or possible particularly when newer versions of IE may break mission critical applications.

One would either have to uninstall the version of IE that comes with the OS and use only a single version of the virtual IE across platforms. There is still quite a bit of benefit in this approach. The biggest benefit is reducing costs across migrations from one OS to the other but also being able to support multiple OS with the same version of IE without having to do a significant amoutn of regression testing. It would be equivalent to what is done in most IT shops today for physically installed IE - say when IE 7 came out but many still used 6.

Now it does also lend the ability to run a side by side pilot of a beta version. Meaning that for a small group during the pilot phase - although there would not be broad based support chances are the benefits of having existing pilot users have access to the current version while the new version is being tested is more valuable and less risky then trying to not allow them access. However, the key thing here is nothing installed means nothing to back out and less corruption issues with the base OS.

Architectural Risk
Although the architectures that fall in the 3 & 4 category (Agentless and Hybrid) have the biggest benefit to customers in terms of portability and reduced risks from not having anything installed on the endpoint - there are some significant risks and considerations that come into play with this approach given Microsoft's support policy.

For products like ThinApp that have written their own virtual operating system - the risks are far less. The reason being is according to the written statement is 1 version of IE per operating system. Although I am not a lawyer - having done EULAs in Product Management for a little under 15 years - I do know there is some leaway in language. Microsoft specific support policy states only 1 version of IE per OS. Now given a product like ThinApp that has it's own virtual OS one could say that the virtual IE is running on it's own OS (VOS). The likelihood of having significant impact on the underlying OS would not be as great depending on how the package is created to interacted with the base OS. Remember - for critical applications it is in YOUR best interest as the customer to check with your OS vendor on what their policy is - I can not speak for either Microsoft or VMware on this one.

Then what is the big deal? Hidden Risks
Certain Application Virtualization solutions actually use IE as their virtual file system in lieu of writing their own. That means that with each application - one is running an instance of IE on the base OS. The support policy would extend beyond just intentionally virtualizing IE to migrate to a new OS but would apply to all applications that are being virtualized.

What should a customer do?
Ask the vendors you are considering about their architectural approach so you can make an informed decision as to whether or not this is an issue for your organization. ie)Is it a critical application that has key MS components or is manufactured by MS (like Outlook or Office) that you must have support for or is it a home grown solution based off of Java or some other component that does not require any support from Microsoft.

Either way it is better to understand the pros and cons of ALL the architectural approaches prior to deciding which application virtualization solution to use. Although a few are close - there is not one single solution that has actually achieved the Nirvana that many customers asked for in order to obtain the true Universal Client.

Leap with caution as the technology and market matures to understand what should and shouldn't be done versus can/can't. Remember just because you can do something - doen't mean you should. I have seen some questions on applicability of Application Virtualization - I am a firm believer that it is required to unchain applications from the OS and achieve the True Universal Client. But like all technologies just needs time.

Stay Tuned - next week regarding Implementation Considerations and Hurdles when deploying Application Virtualization within the Enterprise.

Regards,
Jeanne

Questions? Need tips or advice on your App Virtualization or VDI deployment with your current architecture - contact me at: jmorain@yahoo.com