Tenable Blog

Misconfiguration can Lead to Compromise

As a former full-time systems administrator, I understand the pain of managing and maintaining systems. A significant amount of testing is often required to ensure that you have the correct configuration settings, not just in terms of security, but also for system stability. Once you have the correct configuration it is difficult to maintain consistency across the environment on an ongoing basis (especially across hundreds, or even thousands, of disparate systems). This problem crosses all platforms and Unix/Linux and Windows administrators alike share the same challenges. Some examples include:

• Authentication/Logon services implementing the appropriate policies
• Ensuring all services are logging properly
• Permissions on existing users and running processes
• Various configuration settings associated with installed services (and typically specific to the service)

Tenable Network Security is currently seeking talented individuals to fill several roles within the company. Tenable Network Security is a privately held company founded in 2002 by security product innovators Ron Gula, Renaud Deraison and Jack Huffard. Together with Tenable CSO Marcus Ranum, they have developed a Unified Security Monitoring approach based on the award-winning Nessus scanner engine leveraged with several other enterprise vulnerability and log management products such as SecurityCenter, the Log Correlation Engine (LCE) and the Passive Vulnerability Scanner (PVS). In 2009, Tenable was named one of Deloitte’s 500 fastest growing technology companies. This blog provides a brief description of four technical positions that are open here at Tenable:

Vulnerability Research Engineer

This position is ideal for those who like to research and test software vulnerabilities. The results of your research will present themselves as Nessus and PVS plugins, which are small scripts that are able to detect vulnerabilities. In this role, you will accurately test for vulnerabilities by manually configuring vulnerable targets in a virtual environment, analyzing the system or application to reliably understand how the vulnerability is exploited and then developing a method to test for the vulnerability with credentialed or uncredentialed access. We are looking for people with strong programming skills (knowledge of a scripting language, regular expressions, functions and source code analysis), familiarity with system configurations in operating systems, applications or network devices and in-depth knowledge of TCP/IP protocols, Linux/Unix internals and Windows internals.

Lately I've been thinking a lot about the problem of software security - "lately" being the last 15 years of my life, give or take. It seems to be a topic that's perennially on the horizon, because only a few cutting-edge software companies take it seriously enough to engage in some kind of secure software development lifecycle. I think that we security practitioners have "screwed the pooch" with regards to software security - 'vulnerability researchers' have done a pretty fair job of convincing most vendors that it's useless to even try; whether you get targeted or not has more to do with whether you're unpopular or market-dominating than with whether your software is foundational. Where have we gone wrong? It's simple: we treated it as a security problem. It's also a reliability problem - a quality problem. We asked the users to demand security, but what they needed to be demanding about was software that worked. Not just sometimes, but all the time - even if someone is deliberately trying to make it crash.

Security In The Cloud Is Still Just Security

A recent paper published in the International Journal of Services and Standards titled "A 'cloud-free' security model for cloud computing", written by Manal M. Yunis, outlines six security considerations for cloud computing. Upon reading the six considerations, I can't help but think that they do not present new challenges but merely rehash old ones. Let’s take a look at each of the six common cloud computing security considerations in more detail:

1. Resource Sharing

"On shared services, there is the possibility that another user on the same system may gain access inadvertently or deliberately to one's data, with potential for identity theft, fraud, or industrial sabotage."

The real problem with resource sharing in the context of cloud computing is that software logically separates one system from the next, but not physically. You can think of it as a "virtual server rack"; whereas traditionally you would have a physically separate server from your neighbor, but in the "cloud”, software is used to separate systems. Unfortunately, software is prone to vulnerabilities that could be exploited and in this case lead to complete access to your server or system. A great example of this in action is the "Cloudburst" exploit from the researchers at Immunity, Inc. that allows an attacker in a guest operating system to break out and gain access to the host operating system.

The resource sharing via software problem is similar to VLANs on switches that are controlled by software, requiring you to carefully design a network and be certain your most critical assets are not on the same switch as something less critical. This is a risk-based decision, and must be constantly evaluated whether you are using a "cloud" provider or designing VLANs on a switch.