The world is not only getting smaller, it’s getting faster. CEOs everywhere are singularly focused on business agility, innovation and competitive advantage to drive growth and profit. And they’re looking to the office of the CIO for help. I don’t care what business you’re in; technology is the new battleground—and it’s the key to winning the war. Read more >

This week a vulnerability in a foundational piece of software (the C language library used by Linux operating systems) was announced (CVE-2015-0235). It affects a particular function in the ‘glibc’ library file that has the potential to be remotely exploited if very precise (but uncommon) conditions exist on any of your externally, world-facing servers. The discoverers (Qualys) have taken to calling it the GHOST vulnerability as a contraction-of-sorts of the affected family of software functions: gethostbyname(). Read more >

There have been lots of discussions during the past year about the security of Docker containers, but a majority of them seem to have been focused on just one aspect of containers: isolation. Kernel namespaces (process isolation), control groups (resource isolation) and traditional virtualization comparisons (hypervisor isolation) have been hot topics this past year and all discuss different aspects of the same core concept of isolation. Putting all your eggs in one basket has never been a good idea, and security professionals shouldn’t let a hyper focus on isolation create a distraction from security basics.

On Monday, December 15th, SC Magazine reported a story about a plugin vulnerability for WordPress that has compromised over 100,000 sites.

The plugin, ThemePunch’s Slider Revolution, is a premium WordPress plugin that has also been incorporated into many other commercially available WordPress themes. Users of these themes might not even realize they are running the plugin, because it was included with the theme they’ve chosen and, according to the authors of the plugin, the user must rely on the individual theme’s vendors to provide the necessary updates to the latest version of their code, instead of just getting it directly from ThemePunch. This requirement makes it a little more complicated than your average vulnerability remediation.

Let’s face it- nobody’s production environment is completely pristine and secure. Ideally, we try to embrace security as a cultural component or state of mind, and we create processes to cover our asse(t)s and hope that we don’t hobble our productivity in the process. Security Automation (SA) and Software-Defined Security (SDSec) are the new hotness, but what do those buzzwords mean to the people who have to translate a broad concept into a process that makes them more effective? To help us illustrate the practical application of these broad and somewhat abstract terms we’ll draw parallels with older and more established concepts. Within the IT and infrastructure management disciplines there exists the concept of Network Access Control, or NAC. One of NAC’s purposes is to validate that the connecting host complies with the company’s security policy before being admitted to the network. Translating that concept to the cloud, we’ll introduce the concept of Application Membership Control with CloudPassage Halo by automating the admission of workloads into a tightly-controlled application environment, but only if they’re compliant with your configuration policies.

We’re not going to rehash the minute details of CVE-2014-3566, otherwise known as POODLE. If you’ve found your way here, you’re likely looking for a method to reliably detect and remediate.

Background: POODLE affects the Secure Sockets Layer (SSL) protocol version 3. The danger is that an attacker who can manipulate network traffic and intercept packets from an SSLv3-encrypted datastream can potentially determine the repeated contents of the datastream (like a session key in a cookie).

As of Friday, Red Hat, Ubuntu, Amazon and other vendors have released updates to address the CVE-2014-6271 vulnerability, also known as “Shellshock”. This vulnerability allows remote attackers to execute arbitrary code on servers from a variety of vectors and affects a substantial number of servers running on the Internet. As of Friday, Sept 26th at 11:30am PDT, all CloudPassage production systems have been patched and are no longer susceptible to Shellshock.

If you are a Halo user, you can quickly find out which of your servers have this vulnerability present using the newly-released Reports page in your Halo portal, or using the Halo API.

Using the Halo UI to find vulnerable servers

First, since this is a recently-released vulnerability, you’ll want to run a fresh scan on your servers from the snapshot page. Select all of your servers and click “Launch scan” from the Actions menu. Your scan should be completed within a few minutes.

Once you have run your scans, navigate to the Reports page.

Search by CVE Reference Number - From the Search Criteria selector on the top right, enter CVE-2014-6271, and click submit. You’ll get a list of servers that found that vulnerability on their latest software scan.

You can export these results as a PDF report or to a CSV file using the buttons on the top right of the search results. For more information about how to use the Reports page, please see our documentation.

Note: This call will only return active servers by default – to get servers in a different state like “deactivated”, specify the state (/v1/servers?state=deactivated&cve=CVE-2014-6271)

Your list of servers will be returned in JSON format. If you’d prefer the list of servers in CSV format, simply append .csv to “servers”:

GET https://api.cloudpassage.com/v1/servers.csv?cve=CVE-2014-6271

For more information about what filters are available for the servers endpoint, please see our API Documentation. If you have used the script on github to find vulnerable CVEs on your servers, you can still use that as well.

Today’s public cloud infrastructure is built on elasticity as a core value proposition which brings incredible benefits of being dynamic. However, failure is inevitable, occurs regularly, and often in unpredictable ways. To use a clichéd saying, the computing forecast for tomorrow is “cloudy with a chance of failure.”

In the face of such inevitable and unpredictable failure, how can you write a reliable program that provides the high level of availability your users want?

The good news is that the cloud service providers have done a very good job at providing a framework that enables us to design around such failures and create highly available and resilient applications in the cloud.

Obviously, we still have to design and write our programs to make use of it all.

In this blog, we will look at two things – how we made our Halo event connector highly available and techniques we have used for achieving high throughputs to enable the connector to handle volumes of events generated by large customer deployments. Read more >