Security OF the Cloud vs. Security IN the Cloud

It’s been another fun day of “blame the cloud” around the media universe, and only very few of those media groups are smart enough to understand what they’re actually looking at.  Word has spread that a hacker, or group of hackers, was able to crack user accounts in Apple’s iCloud and gain access to intimate photos of various celebrities.

The headline of the Washington Post indicates that this raises “more questions around the security of the cloud”.  What the Washington Post doesn’t get is that it’s not the security OF the cloud, it’s the security IN the cloud.  According to most reports, it seems that hackers were able to gather email addresses and passwords, or use tricks to leverage the email addresses in enabling the hacker to reset the passwords.  Another apparent way in was through hacking a service of Apple’s that helped open up a door to the user data on iCloud.

Let’s be very clear that none of these methods means that “the cloud” was compromised.  Whether your data is in a cloud, on a server under your desk, or in your corporate datacenter, if a malicious user gains access to your user name and/or password, they’re going to be able to exploit your account(s).  If a user gains access to a service such as “Find My iPhone” that has connectivity to your data, but has a security flaw, they’ll be able to exploit that.  Again, this has no bearing on where your data rests, cloud or otherwise.  A key sentence from this story by DataCenter Knowledge?:  “Cloud … is only as safe as the services that rest upon [it].”

Cloud infrastructure operates mainly with a shared responsibility model.  This means that the cloud provider is generally responsible for the security of its systems up to the servers on which your data resides. However, beyond that, from the operating system on up, the user or company is responsible for that security.  As an example, an infrastructure (cloud) provider such as Amazon Web Services will provide the servers on which you can run your website or host your files. It, generally, isn’t responsible for what you use that server for. If you don’t bother to (or don’t know to) put in the necessary security firewalls on that server to limit access, you’re running the risk of your data being available.  If you don’t bother to (or don’t know to) limit access to certain ports for traffic to your server, you’re opening major holes for exploitation.  That’s not a fault of the cloud provider, that’s user error.

Cloud and application providers have taken steps over the years to try and increase security not only of their own infrastructure and data, but to help users protect themselves.  Some of these methods include multi-factor authentication (MFA) and rotating passwords.  It also includes some services in which you have to rotate passwords on a regular basis, without using previous ones again.  While seemingly inconvenient to the end user, it provides an important step in trying to stay ahead of the game.  Users should take advantage of these components. 

I suggest, and adhere to when offered to me, utilizing MFA for all accounts.  For those unfamiliar with MFA, examples include setting your email provider or Twitter accounts to text you a code that you enter before you can log into an account.  Despite the overly ominous headline, this article from Entrepreneur offers the same advice:  take advantage of MFA.

The breach of iCloud is not a testament to cloud security.  It is more a testament to vulnerabilities of the applications or end user that has access to data stored on the cloud.  It is incumbent on us to take advantage of the security measures offered so we can all do our part.

Matt Jordan is the Cloud Services Manager for JHC Technology. He can be reached at mjordan(at)jhctechology.com, @matt_jhc, or connect with him on LinkedIn.

When Public Cloud Isn’t Public

One of the key misnomers in cloud technology today is the idea of “public cloud”.  In our work with clients, and especially when discussing Infrastructure as a Service providers such as Amazon Web Services, we invariably have to walk some potential clients off the “public cloud” ledge.  Companies such as AWS are immediately labeled “public” simply because the public can access it.

In fact, we recently worked with a client that asked if AWS could meet the NIST definition of “private cloud.”  The answer is emphatically yes.  NIST defines private cloud as:

[C]loud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises.
– NIST Publication 800-145, The NIST Definition of Cloud Computing, at pg. 3.

It is a simple two-sentence definition, so let us look at what is there and why AWS can qualify as a private cloud.  Quite simply, the use of the AWS Virtual Private Cloud provides the exclusivity that is required for private cloud status.  Per the AWS web site, VPC:

…lets you provision a logically isolated section of the Amazon Web Services (AWS) Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over your virtual networking environment, including selection of your own IP address range, creation of subnets, and configuration of route tables and network gateways.

The client, of course, does not directly own the physical AWS hardware but the logical isolation afforded by the use of VPC allows the deployed AWS infrastructure to be exclusive to the client.

The second sentence’s key component is that the term “combination”.  In the case of the Federal Government, the combination is key.  As we encourage all of our clients to do, they should own their own account, meaning the Government owns the AWS infrastructure (above the hypervisor), manages that infrastructure, and operates the infrastructure.  If it chooses, a third party provider, such as JHC, can also handle the management and operation – the “third-party” NIST identifies.

At the end of the day, cloud knowledge continues to filter down, and we are always happy to provide as much of it as we can.  I hope that we will quickly dispel the misnomer of AWS and others as public clouds simply because the public can use the infrastructure.  Once deployed correctly, AWS and others transition directly into private clouds.

Matt Jordan is the Cloud Services Manager for JHC Technology. He can be reached at mjordan(at)jhctechology.com, @matt_jhc, or connect with him on LinkedIn.

 

 

 

AWS and Azure Pushing The Pace

Gartner Magic Quadrant for Infrastructure as a Service Cloud

During the past few years, Amazon Web Services has been the dominant player in the cloud infrastructure space, with very little in the way of significant competition. However, a quick spin around the interwebs has shown that status is starting to face some competition. At JHC we’ve been deploying solutions on AWS – from small scale to large scale – for more than four years. During that time, we’ve also kept an eye on Microsoft Azure, a platform JHC principals considered a few years ago for a key project.

As Microsoft moves rapidly forward in its cloud efforts, it’s becoming a bigger player in the space, and certainly a strong alternative to industry-leading AWS. Just recently, in fact, a customer requested that JHC use Azure to host its new global web site and we were happy to oblige. JHC is a Microsoft Certified Partner and Microsoft has always been a key point in our solutions, AWS or otherwise. We use Microsoft products internally and for our clients, hosting solutions for SharePoint 2007, 2010, and 2013 on AWS. We also have a hybrid Office 365 and AWS solution that also works well for our customers.

It all puts us in a great position as the latest Gartner Magic Quadrant report for Cloud Infrastructure as a Service came out, positioning both AWS and Azure in the Leaders quadrant. We’re thrilled at the continued success of both and look forward to leveraging AWS and Azure infrastructure to provide innovative and secure solutions for ourselves and our clients moving forward.

Matt Jordan is the Cloud Services Manager for JHC Technology. He can be reached at mjordan(at)jhctechology.com,　@matt_jhc, or　connect with him on LinkedIn.