JACADIS Thought

“Virtually” out of sight

I had the privilege recently to speak with Michele Masterson of CRN regarding server virtualization and security. My contribution to the article is below. It was extracted from several paragraphs I sent to Michelle via email:

"At a high level, I am seeing our clients adopt virtualization to decrease their investment in hardware, as well as the maintenance involved in multiple physical platforms," Herring said. "This makes great sense. But the ease with which new guests operating systems can be created presents security challenges. Out of sight is out of mind. If it's high on people's adoption list, it's also high on the adversary's list to decompose, analyze and identify ways to attack."

Speaking with Michele was wonderful and the final product was a great read. On a personal note, it was an honor being mentioned alongside Ivan Arce of Core Security and Neil McDonald of Gartner. After reading my comments, I felt some additional clarification was necessary, specifically, regarding the "out of sight is out of mind…" statement. In my email, the "out of sight" sentence was followed by:

"[Out of sight is out of mind], and we've found guest operating systems that were rapidly created for testing purposes and then forgotten. These hosts are un-patched and ripe for exploit…These aren't virtualization weaknesses, but issues that find their roots in poor change management/control processes and patch management deficiencies…"

The key take away in this comment is not that virtual servers and their guests are out of sight, but that the ease with which a new guest OS can be provisioned and live on the network creates a weakness. It is no different than how easily a $30 access point can be connected to a corporate network and quickly creating convenient access for employees and wireless intruders alike. Both the new guest OS and the access point must be secured and managed to ensure they do not expose the organization to threats. To illustrate: in a recent assessment at a large state agency, system administrators were baffled by several hosts that were flagged by Qualys for having many remotely exploitable weaknesses. No one recognized the host IP address or the machine name. Finally, one staff member connected to the host, recognized the installed software, and recalled creating the hosts for testing. You see, many months before, several guests were created for a pilot project on one of the many virtual servers. Using the virtual server was cost effective and easy to setup. So easy, in fact, normal deployment processes were not followed. A VM weakness? No -- a process weakness. One that led to the guest OSes being "out of sight" until they were scanned by Qualys.

I closed my email with this final thought:

"As a security professional involved in penetration testing, hypervisor technology is just another attack vector to explore when it's discovered. At the end of the day though, it's the operating system that has more vulnerabilities and available exploits. I do expect the number of exploits that target this rise. It's a compelling technology with many advantages. If it's high on people's adoption list, it's also high on the adversary's list to decompose, analyze, and identify ways to attack."

So what are your virtualization security concerns? I'd love to hear what others are seeing. Drop me a note at sherring AT Jacadis DOT com.

Si

Web Application Russian Roulette

While at a client site recently, I was asked how to make a web application secure. When I asked what steps they were currently taking, the developer just shrugged his shoulder and said, "We really don't do anything." So I asked him if he liked to play Russian roulette... with a fully loaded gun. He grimaced. I told him that was his exposure if he didn't do anything. Needless to say he was all ears when I told him what he must do to build a secure web app.

During the planning and development phases, you should at the very least address these topics:

• Identify regulatory and compliance assumptions and risks and develop alternatives.
• Consider your data classification and the sensitivity of the data being collected, stored and transmitted. More sensitive? Then take proper steps to protect it.
• Prepare a System Boundary Document. This will help identify where you need extra security controls. It can also serve as an input to your Threat Modeling document.
• Prepare Misuse Cases. Opposite of use cases, this should identify how a system behaves when you are attacked, when the system doesn’t work as planned.
• Develop strategies to address data backup, data transmission, data storage, authentication, session management, and error handling.
• Identify trust boundaries, trust levels, entitlements, and encryption requirements.
• Become a student of the OWASP guidelines. OWASP is an open community that seeks to improve the security of application software.

Also, make sure you don’t forget the importance of testing and implementation by following these steps:

• Review infrastructure security best practices before you perform a penetration test. You’ll feel silly if the “red team” breaches your application in minutes because of simple oversight!
• Perform a secure code review and then test for vulnerabilities with a scanner like Acunetix WVS.
• Test your password strength. This is the front door to your application and you need to make sure it is secure.
• Finally, ensure that infrastructure security best practices are properly deployed in your production environment. Enforce least privilege, favor simplicity over complexity, deny by default, and isolate sensitive systems from untrusted networks.

Of course this is just a cursory overview of what you should be doing. With the proliferation of automated attacks that target applications running on or exposed to the Internet, it is imperative that you build security into your web application design at the beginning, not the end. Otherwise you'll be playing application "Russian Roulette."

Matthew Hexter, PMP