Is Cloud Security Keeping You Awake at Night?


Cloud security is an important and trending topic, especially in light of recent security attacks such as Heartbleed and the iCloud social engineering hacks that exposed celebrity photos. Though these breaches may reside at different levels of the stack, they all can contribute to shaky confidence in cloud computing and fuel the naysayers. Cloud security concerns, real or “perceived,” are often the biggest hurdles that service providers face when presenting cloud solutions to their SMB and enterprise clients. The irony is that on-premise solutions could actually be more dangerous than cloud environments.

Perception vs. Reality

No solution is without security concerns but the majority of your vulnerabilities are not in the cloud. You are more likely to be negatively impacted by a rogue employee than a trusted cloud hosting provider (CHP):

  • Physical theft, employee mistakes (such as lost devices), and insider threats were responsible for 42.7% of 2013’s data breaches in the US, according to Privacy Rights Clearinghouse.
  • An enterprise data center (EDC) is four times more likely to suffer a malware or bot attack than a cloud hosting provider, as cited in a recent LA Times article.

OrionVM has effectively addressed cloud security hurdles with a wide range of enterprise clients from government agencies and tier 1 telcos to big pharma and publicly traded SaaS organizations. After years of working through the rigorous compliance requirements these customers demand, OrionVM has honed a set of best practices and internal procedures to successfully support high-traffic, mission-critical public, private, and hybrid cloud deployments.

More Stable = More Secure

Additionally, OrionVM’s fully redundant Cloud 2.0 architecture enables rapid fail-over of servers in the event of an outage, thereby delivering greater platform stability and performance than the offerings of other legacy Cloud 1.0 systems. Unfortunately, due to numerous breaches and outages, Cloud 1.0 providers have set the expectation bar too low in terms of what workloads many clients will trust with a CHP.

Obviously, security is a multi-faceted discussion when it comes to the cloud, because there are various points of vulnerability impacted by a company’s own policies, as well as the applications built on top of a cloud provider’s infrastructure. That being said, a prudent approach starts from the ground up. At OrionVM, security is a top priority across every level of our platform stack. We recently published our security statement and have included it again here:

OrionVM Security Statement Overview

Physical Access

Our entire cloud infrastructure, including servers and networking, resides in Tier 3 data centers in Australia and the United States. These data centers require stringent security measures, including full registration of parties prior to access.

We also enforce our own security procedures. Only senior management and operations staff are registered for access to the data centers and internal documentation around the location and configuration of hardware. We perform police background checks on all employees and mandate a clean criminal record before employment. We’ve also informed data center security to contact us for confirmation before giving access to anyone claiming to be an OrionVM employee.

All our racks are locked and have strict access controls. All premises have CCTV recording, including the data centers and our corporate offices. Both are protected with biometric scanners and at least two locked doors. We also mandate all employees use full drive encryption on their workstations, use automatic security updates, and security requirements are routinely audited.

Under no circumstances do we allow third-party access to any of our facilities.

Logical Infrastructure

Our architecture was developed from the ground up with security in mind. We use the Xen hypervisor with a proven security track record.

We operate segregated networks for command and control, storage, and customer traffic. These are air-gapped networks running on different switches. For example, storage runs on InfiniBand and customer traffic runs on a secure, encrypted Ethernet network. These are not connected to prevent customer traffic from leaking into internal networks and also to secure our command and control channels.

All access to our internal network is performed over a certificate-based VPN with strict access controls, and only Tier 3 engineering staff has access to this network. All external communications are performed over SSL encrypted connections. Plain text passwords are never stored; OrionVM encrypts and salts all credentials.

We have strict access control systems to ensure that all customer data is contained within their user account and that it isn’t able to be mounted by any other user.

As an infrastructure provider, we allow partners to encrypt their instance storage if they require.

Access Policy

As a company policy, we do not mount instance partitions in storage devices. This means that we cannot perform certain management services for customers, but we believe that this is the only acceptable position.

When partners create Linux instances, root accounts must be protected with a password before in-band access with SSH can be gained. Windows Server instances are provisioned with temporary, high entropy pseudo-random passwords that Windows requires changing upon first successful login. In both these cases, we are either never privy or cannot know the passwords used by partners or customers.

As an alternative, our administrative panel allows partners to import public SSH keys into instances using our internal context system upon provisioning. This ensures that customers never have to submit passwords to us.

Network Segregation

Our platform segregates networks, customer accounts and instances. That said, customers attempting unauthorized or illegal access to networks, instances, or customer accounts will not be tolerated and will result in account termination. This includes interfering with or circumventing security measures.

These conditions are clearly defined in our Terms of Use, which all partners agree to abide by upon deployment of the platform.

For clarification or further details, please don’t hesitate to contact our support team at



The security question has many dimensions to consider and some experts have suggested it is useful for organizations to view themselves as if in a continual state of breach. No SLA or policy is a substitute for the constant vigilance and review necessary to ensure the integrity of any enterprise infrastructure and operations. New technologies are making this vigilance easier to accomplish with less resources and far greater accuracy and detection. Also helpful in this conversation is to distinguish between a true vulnerability and a loss of direct control (which typically occurs when shifting from on-premises and internally managed hosting deployments to a public or externally managed cloud solution). More often, what presents itself as a perceived “security liability” stems more from internal IT’s psychological reluctance to “let go of control” than from an actual flaw or fundamental limitation in cloud infrastructure. The fact is that the cloud is more secure than you may think, and with the aid of next-gen cloud platforms like OrionVM, service providers now are able to make smoother, structurally sound and sustainable transitions to the cloud.

1 reply

Trackbacks & Pingbacks

  1. […] layers individually to determine the proper division of responsibility. In our recent blogpost we discussed security and the misguided notion that on-premise solutions are inherently safer. The […]

Comments are closed.