What is Cloud?. Defining a nebulous term | by Teri Radichel | Cloud Security

Defining a nebulous term

This is a bonus topic as I’m working through this series on Automating Cybersecurity Metrics and reading other cybersecurity material simultaneously.

I have run across a number of interesting definitions of cloud over the years and just recently read one again which prompted me to write this post. It’s just a random blog due to reading something that triggered these thoughts. Although I put most of this in my book at the bottom of my post and in my classes, I decided to make this public to help people understand what cloud is — based on where it originates — for anyone new to the topic.

The evolution of “Cloud”

Cloud is many things to many people. Some people say cloud is “somebody else’s server.” I do not share that view and it will be evident why through the stories I tell you below. NIST has a definition of cloud computing that is pretty close to my own, but not exactly. That definition is too narrow in some scenarios and does not align exactly to all cloud providers.

I would like to offer my own definition of cloud, presented through personal stories and observations in telecom, server and application hosting, and software development for over 25+ years.

To understand “cloud” it helps to understand how the concept of clouds came about. How did we get from pre-cloud to where we are now? Understanding the transition helps distinguish cloud from “somebody else’s server” or a definition that is too rigid because it aligns with a particular vendor’s implementation.

To understand the evolution of cloud, what it is, and why it exists, it also helps to have a background and understanding of the following:

Telecommunications and networking
Data centers, colocation, dedicated, and managed hosting
Software architecture, design, and programming
Horizontal vs. vertical scaling
Distributed system architectures
Managing deployments of hardware, networking, systems, and software
Economies of scale
Business contracts, including intellectual property and liability
Risk management
Business Missions and Objectives (The reason a business exists)

Understanding challenges in the above areas helps us understand cloud and why it exists. I’m not going to write about all of those topics specifically, but my stories basically cover the concepts and why they matter without directly explaining each of the above.

I also want to avoid using overly wordy definitions and meanings that muddy the water when it comes to cloud security. The only reason I care about the definition of cloud is if that helps us understand what we need to do secure it and how to do it properly as technologies change over time.

Additionally, it bothers me when people incorrectly state that the cloud is not secure compared to other options. As with everything in security: it depends. Inaccurate definitions can complicate security matters and place unnecessary limitations on implementations or give way to decisions that grant excessive permissions that lead to data breaches.

So what is cloud?

Let’s start with the first time I heard cloud in a technical context.

Clouds in Telecom

My first job out of college involved working initially as a temp but that quickly evolved to IT consultant and later with training and experience, a telecommunications analyst. I worked with somewhat new-ish technologies at the time. Access and Visual Basic were all the rage. Cell phones, video conferences facilitated with a mux that never worked worked without complications, ISDN lines, and PBXs that didn’t integrate with anything. The Internet was not really used at work. E-commerce didn’t exist. I punched down wires once. I wasn’t really into it. I worked more on the logical side of things, managing projects, budgets, tracking equipment and wires, and resolving a myriad of telecom billing problems.

That was about the time frame relay “clouds” came about. This story is in my book at the bottom of the post, but basically I worked at an oil company when they had dedicated lines between refineries and the corporate office called T1s. Then our AT&T rep came in trying to convince my boss to use this thing called Frame Relay with logical separation — not physical wires. My boss wasn’t too keen on it at the time. But eventually people found ways to share physical connections with logical separation. Frame Relay was the pre-cursor to MPLS lines if you are familiar. Now people are moving towards SD-WAN.

Picture from Wikipedia: https://en.wikipedia.org/wiki/Frame_Relay

And as I wrote I left telecom due to some unpleasant experiences and because I loved programming. I wanted to build things. My mind operates better in the logical than physical space. But that experience helped me understand the idea of separating implementations from physical wires and logical segregation of customer data.

For all the security people who were afraid of clouds when they came out, I argued that they were already using this concept. It comes down to trust and contracts. Letting go may have some benefits. You may be able to shift liability by way of your contract to a third-party, but talk to your lawyer about that — and I mean a person who has a law degree not someone speaking definitively in a security class or on social media.

In order to feel more secure about sending data over these shared connections, people created mechanisms for encrypting the data as it passed over the wire. In fact, e-commerce was never supposed to be a thing because banks would never take the risk of sending credit card data over the Internet.

But somehow we figured out a way to secure and manage those transactions with a reasonable amount of risk that banks could afford. And traditionally, banks have some of the best security compared to other companies — but that is all relative and not always true for every bank.

Sharing a Physical Building and Networking Infrastructure (Co-Location)

Initially when computers came about companies hosted their servers in their offices. Even I, when I started my first business, hosted our mail server in my condominium. I hired some guys that had a T1 to their basement and ran a small ISP (internet service provider) for their neighbors. This was not unheard of back at that time but it was not super common either!

At some point, we hired a company who hosted one of our servers in their office and the rest in a rack at a co-location facility. We had them move the one in the office to a data center when we decided to take over our own server management. Somehow that server ended up with tin foil in the machine and it wiped out the hard drive.

The guy who moved the server claimed he didn’t do it. No chain of custody existed in that scenario since I had originally had two other guys give me the server to give to that company, and I didn’t think to open the box and look for a ball of tin foil. Who put it in there? I couldn’t really prove it either way. I didn’t know anything about chain of custody at the time, not that it would have mattered. I didn’t expect anyone to put tin foil in my server just because I no longer required their services.

At this point you may get an idea why I am not interested in managing hardware anymore. That and I single-handedly fried three drives — with sparks and smoke — by wiring them backwards back when you could do such things. Don’t ask me to manage your hardware.

Pretty soon, companies started achieving economies of scale by moving their servers to shared facilities, except for some highly security-conscious organizations like banks. They might still run their own data center. Most other companies offloaded at least some of the networking to a company that provided racks with internet connections. You could bring your devices in and plug them into the networking provided by the rack.

The companies may or may not reboot your servers for you if they went down. Whether you wanted them to do that or not depended on if you wanted that company to have physical access to your servers and how much you wanted to pay them. Hence, more than once I found myself driving to the data center in the middle of the night to scan my hand on a biometric reader and push a button.

That is another reason I am not interested in managing hardware.

A company that focused on managing data centers could split the time between their employees who specialize in those areas more efficiently. The company could negotiate better deals with telecommunications companies because they had a lot more volume than a single company alone. These companies could allow small companies like mine to get a half-rack in a co-location facility instead of having to try to host servers in someone’s basement or office. My company could never afford to set up all that infrastructure, but I could rent a piece of it.

Ditching Hardware Management (Dedicated Hosting)

Next comes ditching the purchase and management of physical hardware. I no longer wanted to build custom servers (a thing back in the day) and lug them to my colocation facility. I did not want to go to the physical data center and configure my own load balancer, database servers, and web servers in person.

I wanted to have someone else manage the physical hardware and be able to manage that server remotely. However, I wanted the server to be all mine. I didn’t want anyone else to touch or reboot my hardware. I was literally renting a specific server in a specific data center with this option. I was completely responsible for the operating system and all the software on the server.

What the company provided to me was to provision the specific hardware on which my software resided and to plug the network cable in for me. I had to handle software patches and everything unrelated to the physical hardware itself. I had to manage my own backups and firewall. I still had to handle reboots but I could do that remotely.

Getting Some Help With Server Management (Managed Hosting)

At some point I wanted to stop worrying about rebooting my server when I was on a long flight. Invariably things go down at the worst possible time, like when you’re driving from San Diego to Seattle on Highway 101 and you’re on that one curve somewhere around Hearst Castle and you have no Internet connection. (Is that fixed yet? I haven’t been back in a while.)

I eventually opted to use managed hosting. I used a company that would handle rebooting your server for you if they noticed it went down, provided a managed firewall, backups, and some other functions that I really did not enjoy doing myself. I selected a company that another company bigger than mine was using. I didn’t know how to do a security assessment at the time, nor would my company have been big enough most likely to get the information I would seek based on what I know today.

I experienced the data breach that got me into security at this point, which I wrote about here:

Sharing a Server

After my first data breach, which involved an email compromise and a ton of spam which I investigated incessantly for a while, I moved my email to a shared email service. I figured that this way my customers would have to complain to them, not me. It didn’t work out as planned. I now had to still deal with customer complaints, but I didn’t have access to the logs to fix the problem. I moved to multiple different email providers before landing on Postini to help cut down on spam, a company later purchased by Google and incorporated into Gmail.

Sometime after that, AWS became a thing, but I didn’t trust it based on the traffic I saw coming from AWS that was hitting my servers. Whomever was generating the traffic might end up on the same physical server with my e-commerce websites and I had no way to see what they were doing on the server. I was investigating all my traffic at the time and writing about it in this blog:

AWS had not yet published details about how they segregate virtual hosts on physical servers. Later they did. I was prompted to revisit AWS when I heard the CIA was a customer. I ended up reading all 70 white papers available at the time. Now there are too many to read, and unfortunately they don’t always clearly define security controls as nicely as they did in the past (though I have seen some recent improvements). It is important for customers to continue to ask for clear documentation on cloud security controls for any platform as a whole and each service you use within a cloud provider platform.

In addition to trying to offload email to some other company, I started to think about how much more efficient I could be if I offered my e-commerce services to customers in a different way. I was developing individual web sites for each customer and hosting that web site on a single or shared server. But each individual web site was custom and completely created and managed as a stand-alone web site from top to bottom. This included the content management system where customers would update the content on their web site through a user interface.

It became obvious to me that if customers would allow me to write one set of software for all the customers that would let each of them manage their own website, I could do a lot more work for each customer for less money. I could also charge customers less because they wouldn’t each have to get their own dedicated server or servers, which at the time for the size I was using cost hundreds of dollars per month each.

What if I could just write a content management system (CMS), a term that came about later, that allowed each customer to login and only see their own data? I could also create new features and functions for all customers at the same time so they would all get improvements faster and for a lower cost.

Most customers who knew anything about websites refused to use any software that wasn’t hosted on their own systems. They wanted complete control of the software. In the case of a website in the days of the e-commerce VC (venture capital) rage, everyone wanted to make sure they owned their IP (intellectual property). No, everyone must have their own software in case they wanted to sell the company, went the thinking.

However, I had a few customers that trusted me and let me do this. They cared more about their own operations than selling their websites because they were not VC-backed tech companies. I created software with a shared content management system and later a CMS that would work with ANY web design. If you’ve ever been constricted by a CMS or tried to build such a thing you know that it is not an easy feat. I also incorporated automated SEO into my platform — another thing that was new at the time.

Back then, no such shared platforms like this existed. Yahoo e-commerce sites came later. SalesForce was introduced shortly after I started creating my platform. The concept of putting data into a shared software platform was just starting to be accepted when I worked on a contract gig at Real Networks. I remember my manager saying that they were only using Google Analytics because Real Network owned their own data via the contract.

Deployment Efficiencies and Complexities

Later, Real Networks wanted to hire me but I moved on, shying away from a particular project I was not keen to be a part of but didn’t want to explain to people why it wasn’t going to work. At the time, I was still hosting my software platform on the side through my own company and working on random projects for different companies.

Through the process of working for various companies I got to experience many different forms of deployment — from my manager randomly changing code on an e-commerce platform the day before I was about to leave (and I asked to leave a day early and told IT and HR what he was doing so I wouldn’t get blamed for it) to rigid processes where one person was the bottleneck for an entire company.

I’ve seen the good, the bad, and the ugly. I’ve seen the security implications of an ill-managed deployment process and the inefficiencies that arise from a draconian process. The latter always gets killed when the developers complain to senior leadership that they cannot do their jobs or deploy that shiny new feature or system the business owners want.

How can we address the problem with the slow manual review that turns into a completely frustrating bottleneck and the need for speed that leads to a haphazardly deployed system and the resulting disaster?

Automation.

By moving the management of the underlying hardware systems to software, we can deploy more quickly — with appropriate controls — if done correctly.

That is what my latest blog series is all about. Automating all the things, but in a way that doesn’t introduce excessive risk.

And that is what some cloud platforms can offer that will be hard to replicate in your on-premises environment or data center (in a timely manner for a reasonable amount of cost). Instead of driving to the data center with your new custom built server, you configure your server using software. That software-driven deployment process automates the process of giving you a virtualized server.

Not only can the software deploy your system architecture components, you can bake security controls into the process to prevent unauthorized changes and mistakes. Only those things that are too complex for automation or don’t follow the standard deployment path require manual review. And as I told my DevOps team, if people are complaining, we probably are doing it wrong, or our developers don’t understand why the control exists. In either case, we have to fix the problem.

Distributed Architectures

Since the system implementation is no longer coupled with a single piece of hardware, now your systems can be more resilient. The automation allows your system hosted on a virtual server to keep running should the underlying hardware fail.

Hopefully you understand by now that now that the cloud is not someone else’s computer.

Clouds can run software independent of hardware. If the architecture is designed accordingly, your system can expand it’s ability to handle additional load during busy times and contract when you are not in need of as much capacity. The software is written so that it can expand horizontally and is not constricted by the amount of servers you have physically procured (though there may still be some limitations on a cloud platform as I wrote about here.)

I remember having to architect around a physical limitation in server space for a tax system with regulations mandating the storage of data for a specific period of time. Cloud platforms allow for expandable storage that can grow with your needs.

You may need to purchase certain quantities of storage like you do on Google Drive but you don’t need to provision additional hardware. If you use AWS S3 you only pay for what you need, but the service is designed for applications more than it is for humans working with files. Instead of worrying about how many servers you need to buy you can focus on automated archiving to save money and security controls to protect the data in transit, at rest, and maybe even in memory.

What is Cloud?

Cloud is a platform that allows you to operate software in a way that is separated from the physical hardware and networking generally to innovate and operate faster in a company’s own business domain. A cloud may provide economies of scale, better performance, resiliency, additional security, and cost savings, depending on the particular organization and the management of the cloud platform.

The hardware and software are generally operated by a third party, but not always. The system management is driven by software, which can deploy compute, network, and application resources independently of the hardware in most cases. Because the systems are not tied to physical hardware, they can scale more easily. Because customers can share software components, networking, and hardware, the cloud may result in cost savings or more efficient use of available hardware and network capacity.

IF designed correctly a cloud can help implement more granular zero-trust security controls and segregation of duties. A public cloud does introduce the risk of a third-party having access to your data, and that risk must be properly addressed.

A cloud is not someone else’s computer. It is shared infrastructure and applications on which a company can operate more efficiently compared to maintaining all of that itself in many cases — so a company can focus on it’s own business domain.

Different kinds of clouds

Just as with the examples above there are varying degrees to how much of the software on a cloud platform that you manage and control. I’m not a fan of unnecessary categories but the concept that not all platforms labeled “cloud” offer the same types of services is helpful. In the same way different types of companies hosting your applications provide varying levels of control in my examples above, different types of cloud providers give you more or less control over what you can change on their “cloud” platforms.

IAAS (Infrastructure as a Service): Think of IAAS as a virtual data center. Instead of renting a physical server at a data center or a colocation rack, you’re implementing a software-defined data center, including virtual servers and networking that you use to deploy your applications.

PAAS (Platform as a Service): You might not control as much of the underlying virtual hardware and networking, but you can drop in your code, manage your database settings, and create an application on a PAAS platform.

SAAS (Software as a Service): You don’t write an application or configure virtual hardware or networking. You log into a UI and perform some business function. In my case, I offered my customers a SAAS e-commerce system above. It was a shared platform where they could manage their website but they didn’t do any programming, hardware, or network configuration. They simply entered the data they wanted to show up on their web site into the content management system and pushed a button to publish it.

I don’t really like trying to stuff every cloud provider into one of the above categories because it really doesn’t matter. All of the above types of cloud really offer a software platform to manage your infrastructure, applications, or data. I would probably break clouds down that way instead. In some you manage infrastructure like virtual servers and networking. In some clouds, you build and manage your own applications by writing your own software within their platform but you don’t deal with servers or networking. In some you only manage your data. Some clouds have a mix of those features, rather than one or the other.

There is often a fuzzy line on where IAAS ends and PAAS begins, such as with PAAS type platforms where you specify network configurations. Is AWS Lambda PAAS, because you’re just dropping in code? But you can control the networking. Is SalesForce a SAAS? Because customers just login and enter data. But wait, they added APIs. I also developed software that automatically recorded data from LiveChat into a SalesForce system using SalesForce programmatic options. So is SalesForce a PAAS?

Who cares and more importantly, why?

What matters is not the category into which a particular cloud company falls for us to secure our data in a cloud platform. What we need to know:

How does the cloud provider secure our data?
What security controls are available that we need to manage ourselves?
What is the best architecture or configuration to use that facilitates both business operations and minimizes security risks?
How does our contact enforce the above and what liability exists for our company in the event of a data breach or security incident?

I think I basically wrote a lot of the above information in my book below and you’d get the same definition in the basic cloud class I’ve taught in the past. However, I think many people are beyond the definition of “what is cloud” and so I tend to focus more now on “how to secure your clouds” — whatever type of clouds they may be.

Follow for updates.

Teri Radichel

If you liked this story ~ clap, follow, tip, buy me a coffee, or hire me 🙂

Medium: Teri Radichel
Email List: Teri Radichel
Twitter: @teriradichel
Twitter (company): @2ndSightLab
Mastodon: @[email protected]
Post: @teriradichel
Facebook: 2nd Sight Lab
Slideshare: Presentations by Teri Radichel 
Speakerdeck: Presentations by Teri Radichel
Books: Teri Radichel on Amazon
Recognition: SANS Difference Makers Award, AWS Hero, IANS Faculty
Certifications: SANS
Education: BA Business, Master of Sofware Engineering, Master of Infosec
How I got into security: Woman in tech
Buy me a coffee: Teri Radichel
Company (Penetration Tests, Assessments, Training): 2nd Sight Lab
Request services via LinkedIn: Teri Radichel or IANS Research