On June 24, 2014, a former editor of a now-defunct British tabloid newspaper (some will disagree with the use of the prefix “news”) was found guilty of phone hacking. Phone hacking is the practice of intercepting and listening to a phone’s voicemail messages without the owner’s knowledge or permission.
Attending Gigaom Structure was an exercise in getting fire-hosed with the leading edge innovation that public cloud providers are bringing to their customers worldwide. These innovations not only will have a profound effect on public cloud computing, but also will ultimately impact data center architectures, costs, and benefits worldwide.
There has been quite a bit written about Code Spaces and how unauthorized access to its ITaaS console granted enough permissions to delete everything out of Amazon, including backups. There are lessons here not only for tenants, but also for those vendors who create ITaaS consoles, such as VMware (vCHS, vCD, vCAC, vCenter, Orchestrator, etc.), Virtustream (xStream), OpenStack, and many others. These consoles need better controls and security so that such behavior is prevented, logged, and monitored, and the proper authorities are informed. Now, we may think this is a cloud-only attack, but we use these tools within our own environments day in and day out. For anyone using virtualization, private, or hybrid cloud consoles and automation tools, it is time to take a good long look at role-based access controls (RBAC). The steps we discussed at the end of my other lessons article still apply. Continue reading Protecting ITaaS Consoles
It was all over the web on June 18: Code Spaces went off the air, as we discussed during the Virtualization Security Podcast on 6/19. The reasons are fairly normal in the world of IT and the cloud. They were hacked. Not by subverting the Amazon cloud, but in ways considered more traditional—even mundane. An account password was discovered, either by hacking using one of the seven SSL attacks that exist today or by guessing with the help of inside knowledge gained through social engineering. However the account was hacked, the damage was total. While we may all ask why Code Spaces was attacked, we may never know the answer. Nevertheless, in general such attacks are all about the Benjamins. What lessons can we learn about this attack? How can we improve our usage of clouds to protect our own data, systems, and more from similar attacks? Continue reading Lessons We Can Learn from the Code Spaces Attack
During the last two Virtualization Security Podcasts, the panel discussed backups as well as scripting related to backups and in general. We went further to discuss the security implications surrounding backups, including whether or not a recovery is required when a site is hacked. The latter raises an important question: what constitutes a disaster that requires recovery? Is recovery needed only for catastrophic failure (which TVP has experienced)? Is it required in response to malfeasance from a disgruntled employee? To an external cyber-attack? Do you classify cyber-attacks as disasters requiring restoration from known-good sources and restoration of data from a backup, or do you use some other means to recover?
Secure multi-tenancy is not just about ensuring security and segregation between tenants. It is also about limiting, auditing, and tracking the activities of a cloud service provider within a tenancy or that touches upon more than one tenant, which of course includes any activity that occurs within the hypervisor, storage, or other layers of the cloud. In the past, I referred to this as the delegate user problem. We were joined by Skyfence (now Imperva) on the April 24 Virtualization Security Podcast to discuss its transparent gateway solution for cloud access, and I had another thought on usage. Perhaps now we can solve the delegate user problem. Continue reading Securing Clouds from Service Providers