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.

Amazon Web Services VPN Gateway

I ran into an interesting conflict last week with AWS VPN (Virtual Private Network) Gateway.  I know there is a limitation with your AWS account that you are not allowed to have multiple customer gateways within a region having the same IP address. This would be an extremely nice feature because we would be able to connect multiple VPCs (Virtual Private Cloud) inside the same region to a single VPN device outside of AWS.  There are a lot of use cases for being able to have multiple VPCs within a region have a VPN connect to a single customer gateway device:

• Logical separation of Development and Production environments
• Logical separation of data at different classification levels for industry compliance and regulatory restrictions.
• Customer segregation

Based on this information, I thought I would be clever to create two customer gateways within the same region, but have them separated by two AWS accounts. I was able to successfully create the customer gateway and perform the VPN connection in the first AWS account.  I then went into the second AWS account and was able to create the customer gateway successfully; however, when I went to create the VPN connection I received a conflict error with the customer gateway.  Come to find out, regardless of AWS account separation you cannot successfully create VPN connections with AWS VPN gateway if the customer gateway address is being used somewhere else within a single AWS Region. 

The way to work around this issue is to separate VPCs and customer gateways across different AWS regions regardless if you have one or multiple AWS accounts.

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas(at)jhctechnology.com,@JHC_JamesHirmas, or connect with him on LinkedIn.

JHC Integrates AWS CloudTrail

JHC Technology has integrated Amazon Web Services' CloudTrail as a best practice for all our AWS solutions.  AWS CloudTrail is a fully managed web service that provides increased visibility into a customer's cloud solution and user activity by recording the API calls on that customer's account.  JHC utilizes CloudTrail to perform the following services in order to provide enhanced security for our AWS customers:

·        CloudTrail is the first service activated on new AWS accounts to ensure every API call is captured from the onset of the account.

·        JHC configures CloudTrail to capture both regional and Global API calls while preventing duplicate global events in the logs.

·        JHC deploys custom Identity and Access Management (IAM) permission policies on CloudTrail to prevent unauthorized access to logs.

·        JHC Enables versioning and logging on CloudTrail S3 buckets for added protection.

·        JHC deploys and configures Splunk Enterprise Instance inside customer's Virtual Private Cloud (VPC) and integrates Splunk with CloudTrail in order to gain additional insight into security related activities.

·        JHC creates custom notifications on CloudTrail S3 bucket to immediately notify customers when objects stored are lost.

 

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas (at)jhctechnology.com, @JHC_JamesHirmas, or connect with him on LinkedIn.

JHC to be Panelist at NIST Industry Day - Dec. 16, 2013

Craig Atkinson, JHC's Chief Technical Officer has been selected to be one of the panelists that will be presenting during this year's NIST Industry Day. The event expects to attract 600 registrants from around the DC Metro area seeking to learn more about the challenges of Cloud computing in the Federal Government.

The industry day will focus on the challenges that the Federal Government is experiencing when it comes to the disruptive technology, specifically around procuring Cloud services and infrastructure. As the landscape for procuring computing power is being transformed by Cloud computing, the industry day will attempt to address the changes in the market that can assist the Government in transforming the way it procures Cloud computing moving forward. The industry day also promises to touch base on the capabilities available in the commercial market space in regards to Cloud web hosting and content management.

JHC Technology will also have a booth set up where you can stop by, meet our team and learn more about what we have cooking in the Cloud today.

The Industry Day will be held at the NIST location at 100 Bureau Drive, Building 101, Gaithersburg, MD 20899 on Monday, December 16th. To register, visit https://www-s.nist.gov/CRS/conf_disclosure.cfm?conf_id=6571

Hybrid Cloud Solutions: Amazon Web Service (AWS) and Microsoft Office 365

Can Microsoft Office 365 and Amazon Web Services (AWS) work together?  The answer to this cloud riddle is YES.  

There seems to be an overall confusion between what these Cloud venders provide as services.  To be clear, Amazon Web Services is an Infrastructure as a Service (IaaS) provider and Microsoft Office 365 is a Software as a Service (SaaS).  

In enterprise deployments of Office 365, many organizations have requirements to manage and synchronize user profiles to Office 365, restrict user access, provide secure mobile access, and advanced Exchange/Lync/SharePoint management (Remote PowerShell and management consoles).  

In order to satisfy these requirements, organizations will need to deploy the following components within their controlled environment:

• Mobile Management Solution (Blackberry Enterprise Server 10)
• Active Directory Federation Services (ADFS) internal and proxy
• Exchange and Lync Management Console
• Remote PowerShell for SharePoint, Exchange, Lync, and other Office 365 components

Some of our clients have elected to move these components into their own Virtual Private Cloud (VPC) within Amazon Web Services (AWS) so that they can take advantage of the power of AWS (Elastic, Pay as you go model, network, high availability, etc…) and remove their dependencies on managing their own data centers. Once these components have been deployed they can be configured to integrate/communicate with Office 365 Exchange, SharePoint, Lync, and other Office 365 components.

JHC Technology has also designed and implemented virtual application and desktop technology to run on Amazon Web Services.  We are able to deploy the Microsoft Outlook virtual application as well as other office products on AWS and connect them to Office 365.  In this scenario, users are able to connect to an AWS region and access Outlook either via virtual desktop or virtual application from any device and pull down their Office 365 exchange mail securely.

Organizations should not be tied down to use only one cloud model (IaaS vs SaaS). They should look at their overall requirements and choose an architecture that is flexible enough to expand for future requirements.

James Hirmas is the CEO for JHC Technology.  He can be reached at jhirmas(at)jhctechnology.com,@JHC_JamesHirmas, or connect with him on LinkedIn.

Cloud Isn’t All or Nothing

One of the misconceptions that I run into as I visit potential clients is the amount of access a company like ours has when performing a cloud project for a company or individual.  Invariably, at some point, the question of data visibility comes to the forefront.  It usually goes something like this:  “So are you going to be able to see everything, because we can’t have that!”

The answer to this question is the same as many other answers we give when it relates to highly malleable cloud projects:  “It depends.”

Cloud isn’t an all or nothing endeavor.  Your data doesn’t have anything to do with our work, and whether we get to see the data is totally up to you.  I look at it this way:  A cloud provider, such as AWS, can come to the site at which you’re building your dream home.  AWS will put a Home Depot on the site and then leave.  AWS doesn’t tell you how to build your home, what boards to use, or whether that joint requires a nail or a screw.  All they do is keep the Home Depot stocked.  JHC handles the architecture and deployment, and we know all the best practices when it comes to using the material.  But that’s where it ends.  We can build your house without ever knowing what will go in it.

Your data is the same way.  We don’t need to see it and building your cloud environment isn’t dependent on having any access to it at all.

We are doing one project with a global organization in which we have full control of the cloud infrastructure we are deploying.  This infrastructure is being deployed in an AWS Virtual Private Cloud (VPC).  As part of the creation of the VPC, our client’s requirement was that the VPC only allows access from a specific set of IP addresses.  As it stands, that IP range is limited only to our client’s development servers.  What that means is while we can deploy a server into the AWS VPC, we can’t even verify its operation beyond the fact that the server is running.  We have no access to ping the server or remote into it.  The only access comes from the client’s on-premises machines.

Testing the capabilities of the cloud can provide tremendous insight for an organization.  Many times, involving an outside consultant with cloud experience is also the wise step.  But, don’t fret that you’ll need to give the ol’ “Keys to the Kingdom,” to your consultant.  You can build and test all sorts of services without exposing your data outside your organization.

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.