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 >
Predictions are a dangerous thing. Because even fantastically smart people can be fantastically wrong. To wit:
“There is not the slightest indication nuclear energy will ever be obtainable.” —Albert Einstein
“Television won’t last.” —Darryl Zanuck
“There’s no chance the iPhone is going to get any significant market share.” —Steve Ballmer
And yet predictions are also a safe thing. Because even when you are dead wrong in public, almost nobody remembers. (Which is why your local weatherperson still has a job.)
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.
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.
A serious vulnerability, CVE-2014-6271, being variably referred to as Shellshock or Shellshocked, was just reported in the Bourne-Again Shell (bash) that affects most *NIX-based systems. Because the bash shell is so prevalent on *NIX systems, the vulnerability can be leveraged in many different ways to allow unauthorized access and modification of computers remotely. See the NIST vulnerability summary to learn more about this vulnerability and the systems it affects.
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.
Using the Halo API to find vulnerable servers
Again, since this is a recently-released vulnerability, you’ll want to run a fresh scan on your servers from the snapshot page, or run the script to launch new scans across all servers posted on GitHub.
Once your scans have completed, make this simple call:
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”:
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 >